[00:13] <c_korn> hello, can some opera user confirm bug 396081?
[00:18] <jkimball4> Can I get my account deleted, please?
[00:18] <jkimball4> I no longer use it.  Would like to get it closed.
[00:19] <Ursinha> jkimball4, you can disable it in your profile
[00:19] <jkimball4> Okay, i'll take a look.  I read that I had to get an admin to delete it.
[00:20] <mwhudson> if you can still access it, you can disable it yourself
[00:21] <jkimball4> Done and Done.  Thanks chaps
[00:27] <wgrant> Ampelbein: Security uploads don't show up because they are actually uploaded to the ~ubuntu-security P3A, which you can't see. They're then copied into Ubuntu, which doesn't generate an upload record yet.
[01:23] <thumper> mwhudson: the wine import...
[01:23] <thumper> mwhudson: was it started before our re-roll?
[01:24] <thumper> mwhudson: the start time of 47 hours ago seems too far back
[01:24] <thumper> finished 13 hours ago taking 34 hours
[01:27] <mwhudson> oh maybe
[01:28] <mwhudson> i think i approved it just after tom told us the rollout was complete
[01:28] <mwhudson> but maybe it was before indeed
[01:29] <mwhudson> i can check, i guess
[01:31] <mwhudson> thumper: yeah, no saved db for that import
[01:32] <mwhudson> thumper: i deleted the so far imported branch
[01:40] <wgrant> Is a branch disk size indicator going to be showing up at some point soon?
[01:41] <lifeless> Is there a bug open?
[01:41] <wgrant> I think so.
[01:41] <wgrant> I remember it being active recently.
[01:41] <wgrant> I'll see if I can track it down...
[01:42] <wgrant> Ah, yes, bug #350031
[01:42] <wgrant> Apparently mwhudson was working on it last month.
[01:46] <mwhudson> probably not super soon
[01:46] <mwhudson> although it's probably not that much work...
[02:50] <GatoLoko> hi
[02:53] <GatoLoko> launchpad is giving me an error message that seems like i'm a launchpad beta testes, but i'm not, is this something known?
[02:53] <micahg> GatoLoko: what is the error message?
[02:54] <GatoLoko> Our edge server has a lower timeout threshold than launchpad.net, so we can catch those before they hit a wider audience. As a member of the Launchpad Beta Testers team, you're more likely to experience them. If this is blocking your work, you can disable redirection.
[02:54] <micahg> ah
[02:54] <micahg> did you go to edge.launchapd.net?
[02:54] <micahg> *launchpad
[02:54] <GatoLoko> nop, i was trying to load https://launchpad.net/~locoteams
[02:54] <micahg> hmm
[02:55] <GatoLoko> opened a new tab on firefox, copypasted the url and there was a timeout error with that message
[02:55] <micahg> hmmm
[02:55] <micahg> I didn't get that timeout error but another one
[02:56] <GatoLoko> i even checked that i'm not a beta tester team member
[02:56] <GatoLoko> i though maybe there was an error and something/somebody added me to the team
[02:56] <GatoLoko> but i don't appear on the team member list
[02:58] <GatoLoko> reloading the same url works now, but it was weird
[02:58] <GatoLoko> xD
[02:58] <micahg> I don't know
[02:58] <micahg> anyone else have any ideas?
[03:26] <poolie> GatoLoko: what's your launchpad id? GatoLoko?
[03:26] <poolie> it does seem kind of slow at the moment
[03:27] <GatoLoko> https://launchpad.net/~gatoloko  <-- i'm this ugly guy
[03:27] <GatoLoko> xD
[03:28] <poolie> do you still have that tab with the erorr open?
[03:28] <poolie> if so, filea  bug with the screenshot
[03:29] <GatoLoko> i reloaded it a while ago and it worked
[03:29] <GatoLoko> if it happens again a will report it
[06:43] <cellofellow> is there an IDE with comprehensive LaunchPad integration? The bzr, the bugs, the blueprints, the branches, the whole nine yards?
[10:00] <nfilus> hello
[10:01] <nfilus> how can I speedup the review of uploaded messages.pot?
[10:24] <wi_nk> i haven't received my ubuntu cd. why? how can i know what happened to it
[10:47] <lamalex> Is there a way to be notified of all changes to blueprints like I am with bugmail?
[10:55] <intellectronica> lamalex: sort of. you can get changes for a specific blueprint, but you can't do that for all the blueprints in a project, like you can with bugs
[10:55] <lamalex> that's whack
[10:55]  * lamalex opens bug
[10:55] <lamalex> but searches first..
[10:55] <intellectronica> lamalex: patches welcome .... well, patches will be welcome shortly :)
[10:56] <lamalex> yah :)
[10:56] <lamalex> can't wait
[10:56] <lamalex> word on the street is some people at GNOME are thinking of moving from bugzilla
[10:56] <lamalex> some people have been talking to them about how awesome LP is at GCDS and a bunch of people are really hyped on it
[10:57] <mwhudson> cool :)
[10:57] <lamalex> I KNOW
[10:57] <mwhudson> still unlikely though
[10:57] <mwhudson> i'd say
[10:57] <lamalex> hey
[10:57] <lamalex> dont rain on my parade
[10:57] <mwhudson> :)
[10:57] <lamalex> let me dream
[10:57] <mwhudson> though if people get enthusiastic and fix blueprints for us, that would be awesome :)
[10:58]  * mwhudson wanders off
[10:58] <lamalex> whats the release date? late july?
[10:58] <mwhudson> yep
[10:59] <mwhudson> (barring technical glitches)
[11:00] <lamalex> radical
[11:00] <lamalex> although I'm /really/ bummed that codehosting will not be part of it
[11:01] <lamalex> that integration is one of the most excellent parts of the service, so I understand canonicals desire to protect it..
[12:22] <lamalex> Hi, I'm trying to upgrade our LP bzr repo's format to 1.6.1-rich-root
[12:22] <lamalex> I did the converstion locally and am trying to do bzr push --overwrite
[12:22] <lamalex> but it fails
[12:23] <lamalex> do I /need/ to do this over the network?
[13:00] <spiv> lamalex: yes, or at least remove the .bzr directory over sftp (the lftp client is good for that) and push --use-existing-dir
[13:01] <spiv> lamalex: --overwrite won't overwrite formats, it's purely about overwriting one history with another.
[13:41] <lamalex> spiv: ahh, wish I had known before I ran bzr check over the network
[13:48] <lamalex> spiv: how do i connect via sftp?
[13:48] <c_korn> hello, can some opera user confirm bug 396081?
[13:50] <persia> I'm encountering another Debian Developer complaining about bug #204980 for one of their maintained packages.  Does anyone know if this is scheduled to get work in the next few months?
[13:50] <barry> c_korn: i'm pulling down an updated opera now.  i'll give it a shot
[13:57] <barry> persia: i don't know for sure, but it may not be scheduled until after launchpad 3.0 is released
[13:58] <persia> barry, I guess my question is more: "Is it on the list of stuff to be scheduled?", rather than a specific timeframe.
[13:58] <persia> To put it differently, should I be advising complainants that they should just unsubscribe from the packages, or that they should try submitting a patch once the code is available.
[13:59] <barry> persia: it's definitely on our radar to give users more control over exactly what email they receive from launchpad
[13:59] <persia> OK.  I'll pass that along.  Thanks.
[14:00] <barry> np.  short term (i.e. next couple of months) it's best to unsubscribe
[14:00] <lamalex> anyone know how i can connect to bazaar.launchpad.net with sftp?
[14:01] <barry> abentley: ^^
[14:02] <barry> lamalex: i don't, but abentley might though he may not be actually online yet
[14:03] <persia> I've never done it, but I thought it was just sftp://bazaar.launchpad.net/foo
[14:06] <vila> Hi guys, I just created a PPA: https://edge.launchpad.net/~vila/+archive/ppa, uploaded a package, but when I try to install it, I get:
[14:06] <vila> WARNING: The following packages cannot be authenticated!
[14:06] <vila>   mydevtools
[14:06] <c_korn> barry: thanks for confirming
[14:06] <noodles775> vila: have you added your PPA's signing key for authentication?
[14:06] <barry> c_korn: np
[14:06] <vila> looking at http://ppa.launchpad.net/vila/ppa/ubuntu/dists/jaunty/ I see a Release file but no Release.gpg file, any hint ?
[14:07] <vila> PPA's key added and checked with sudo apt-key list
[14:07] <vila> sudo apt-get update ran too
[14:07] <barry> vila: take a look at this page: https://help.launchpad.net/Packaging/PPA
[14:08] <barry> vila: scroll down to the sections on adding the ppa keys
[14:08] <noodles775> Hmm... that's strange... (barry, afaiu vila has already done that?)
[14:08] <vila> scolling up the already opened page :)
[14:08] <james_w> yeah, he has added the key
[14:08] <barry> vila, noodles775 ah
[14:08] <james_w> (I've just been trying to debug it with him elsewhere)
[14:09] <barry> james_w: gotcha
[14:09] <noodles775> Hmm... so perhaps there's a delay publishing the signing key to the archive?
[14:09] <noodles775> cprov ^^^^
[14:09] <noodles775> (calling in the big-guns ;) )
[14:09] <vila> 5703355D is the key fwiw
[14:09] <barry> noodles775: :)
[14:09]  * cprov checks
[14:09] <vila> barry is not ? One more dream down the drain :-)
[14:10]  * vila hugs barry :)
[14:10]  * barry hugs vila and thanks him for boosting his ego :)
[14:12] <vila> Just for my own curiosity, should there be a Release.gpg at http://ppa.launchpad.net/vila/ppa/ubuntu/dists/jaunty/ or am I climbing the wrong tree ?
[14:12] <cprov> vila: the key generation took a little longer that it should -> https://edge.launchpad.net/~vila/+archive/ppa
[14:12] <cprov> vila: you have to modify your PPA to trigger the repository re-publication.
[14:13] <vila> what kind of modification ? Uploading a new package ?
[14:13] <cprov> vila: yes, the Release.gpg should be there.
[14:13] <noodles775> ah, so the packages were published *before* the key had been generated? That makes sense...
[14:13] <cprov> vila: deletion, copies, new upload
[14:13] <vila> cprov: ok
[14:19] <abentley> lamalex: Well, you launch and sftp client, and provide bazaar.launchpad.net as the hostname.
[14:19] <abentley> lamalex: hitchhiker, lftp and the commandline sftp client all seem to work.
[14:19] <lamalex> abentley: i can do tha tmuch, but how to i get to my projects directory?
[14:20] <abentley> lamalex: cd /~lamalex/project/branch
[14:20] <lamalex> it ust sits at [Connecting...]
[14:21] <abentley> lamalex: lftp?
[14:21] <cprov> vila: you've just won your signed PPA.
[14:21] <lamalex> abentley: yah
[14:21] <vila> cprov: seen that, was waiting for a successful install before reporting :)
[14:22] <vila> wow, the package has the ubuntu icon in front of it under synaptic ???
[14:22] <abentley> lamalex: Try starting it in the project directory: "lftp sftp://bazaar.launchpad.net/~lamalex/project/branch"
[14:23] <vila> cprov, james_w , barry , noodles775 : install successful, mission accomplished, thanks all, you resume you usual schedule
[14:23] <noodles775> yay... good to hear vila :)
[14:23] <cprov> vila: ehe, nice one!
[14:23] <barry> vila: i am the help contact today, so i am totally laser focused on your wishes and desires :)
[14:24] <abentley> lamalex: lftp does not default to sftp, so you must specify sftp:// when connecting.
[14:24] <lamalex> abentley: [Delaying before reconnect: 25]
[14:25] <abentley> lamalex: Does bzr work for you?
[14:25] <lamalex> abentley: yah
[14:26] <abentley> lamalex: That's output from "lftp sftp://bazaar.launchpad.net/~lamalex/project/branch" ?
[14:26] <vila> barry: hehe, ok, a quick question then: now that my immensely mature package has reached 2.0.0, can I just delete it in the PPA and start again with a modest 0.0.1 or is it too late ?   I don't know why lftp wouldn't work for you, but hitchhiker will work anywhere bzr does.
[14:27] <lamalex> abentley: lftp sftp://bazaar.launchpad.net/~do-plugins/do-plugins/trunk
[14:28] <lamalex> abentley: can you give me a link to hitchhiker?
[14:28] <lamalex> doesn't appear to be in the repo
[14:28] <vila> barry: ok, great. Have a nice help day !
[14:28] <abentley> lamalex: lp:hitchhiker
[14:28] <persia> vila, You can't.  versions must always increase, even after deletion.
[14:28] <lamalex> abentley: heh, too easy..
[14:28] <barry> vila: you too!
[14:28] <vila> persia: Thanks !
[14:29] <abentley> lamalex: btw, why do you want sftp access?
[14:29] <lamalex> abentley: i need to mv our .bzr directory
[14:30] <lamalex> So I can push one with an upgraded format
[14:30] <lamalex> /would/ have been faster than upgrading via the network
[14:30] <lamalex> but I spent so much time trying tofigure out how that idk if it was faster
[14:30] <abentley> lamalex: Upgrading via the network is done on the server side.
[14:31] <lamalex> so you think that would just be better?
[14:31] <abentley> lamalex: There are only a few permitted filenames: ".bzr" "backup.bzr" and ".bzr.backup", so you'll need to mv to one of those.
[14:32] <abentley> lamalex: Depending on the kind of upgrade, probably not.
[14:32] <lamalex> we're going to 1.6.1-rich-root
[14:34] <abentley> lamalex: from rich-root-pack, it might be faster to upgrade directly.  From pack-0.92, it definitely won't be.
[14:34] <lamalex> abentley: yah, i'ts an old format
[14:35] <lamalex> I think pushing from a locally upgraded repo would be faster
[14:40] <fta> could someone please tell me what's wrong with https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/1109028 ?
[14:41] <bigjools> fta: looks like it built twice and the second one failed to upload
[14:41] <barry> bigjools, fta from the log file: duplicate key value violates unique constraint "binarypackagerelease_binarypackagename_key
[14:41] <bigjools> yes
[14:42] <bigjools> now, to work out why
[14:42] <abentley> mthaddon: I need some help running down this bug: https://bugs.edge.launchpad.net/launchpad-code/+bug/384217
[14:42] <fta> barry, bigjools: how did that happen?
[14:43] <abentley> mthaddon: Do you know how to determine the branch id from its name?
[14:44] <bigjools> fta: it's probably a bug in the buildd manager and it got dispatched twice
[14:44] <bigjools> cprov can you confirm?
[14:47] <cprov> fta: let me check.
[14:50] <cprov> fta: the binaries seems to be correctly published, so it's probably a hiccup on the buildd-manager or in the script which takes builders in/out of the farm.
[14:50] <fta> nothing i should worry about then?
[14:51] <bigjools> no, it's built and published
[14:53] <fta> ok, thanks
[15:05] <lamalex> .. abentley  now im getting a crash when i push
[15:05] <abentley> lamalex: Please pastebin the crash.
[15:06] <lamalex> trace fills my entire buffer and then some
[15:06] <abentley> lamalex: Even part of a traceback will be helpful.
[15:07] <jpds> .26
[15:07] <jpds> Whoops, sorry.
[15:07] <lamalex> abentley: http://paste2.org/p/312578
[15:09] <abentley> lamalex: I suspect this is bzr trying to stack your branch on itself, because it's trunk.
[15:09] <lamalex> can i tell it not to stack?
[15:11] <abentley> lamalex: You can try doing "bzr init nosmart+bzr+ssh://bazaar.launchpad.net/~do-plugins/do-plugins/trunk".  If that doesn't try to stack, then you would be able to push.
[15:12] <lamalex> abentley: still use --use-existing-dir?
[15:12] <abentley> lamalex: No, you shouldn't need that.
[15:12] <lamalex> ok
[15:17] <lamalex> abentley: shouldthis be a fast operation?
[15:17] <abentley> lamalex: depends on the amount of data to be transferred.
[15:17] <abentley> lamalex: You're pushing from scratch, right?
[15:17] <lamalex> i mean the init
[15:18] <abentley> lamalex: yes, it should take a few seconds at most.
[15:18] <lamalex> init just crashed..
[15:18] <lamalex> same thing
[15:18] <lamalex> it's trying to stack
[15:19] <abentley> lamalex: So the most likely fix is to make this branch not the "development focus", push, and set it back.
[15:21] <lamalex> run init again?
[15:21] <nhandler> persia: Remember that LP Map issue? It is more interesting than I thought. Even some direct team members don't show up on the map. However, if you goto the /+map page, *all* members, direct and indirect, show up
[15:21] <nhandler> I'm creating the bug now
[15:22] <abentley> lamalex: no
[15:22] <abentley> lamalex: After you've make the branch not the developement focus, just push.
[15:23] <persia> nhandler, That's the optimisation I mentioned before.  It's intentional behaviour.  Check the old bugs, because I think it was previously discussed.
[15:23] <lamalex> abentley: still crashes
[15:24] <abentley> lamalex: does it say it's stacking when you push?
[15:24] <lamalex> it doesnt say anything, no
[15:24] <lamalex> but i ge the same "maximum recursion depth" error
[15:25] <nhandler> persia: I'm not seeing a bug about that filed against LP. Would it be filed against something else?
[15:26] <persia> nhandler, It could well be against launchpad-registry
[15:26] <persia> And it could be closed.
[15:26] <nhandler> I was looking at all bugs ever reported. I'll check -registry
[15:28] <abentley> lamalex: Did you delete the .bzr directory before pushing?
[15:28] <lamalex> abentley: in my tree?
[15:29] <lamalex> or on bazaar.launchpad.net
[15:29] <abentley> lamalex: on Launchpad.
[15:29] <lamalex> i moved it to bzr.backup
[15:29] <lamalex> it's not possible to rm a dir with hitchhiker apparently
[15:29] <abentley> lamalex: It's possible to rmtree a dir.
[15:29] <lamalex> ah, didnt see that command
[15:30] <nhandler> persia: Bug 314238, I guess I won't file a bug
[15:30] <abentley> lamalex: You need to delete the .bzr directory every time an attemp fails, or the half-built .bzr will frustrate further attemtps.
[15:31] <lamalex> abentley: k
[15:31] <lamalex> ughh its trying to stack against the development focus
[15:32] <abentley> lamalex: That's why you need to not have a development focus.
[15:35] <lamalex> abentley: how do i not set one?
[15:35] <lamalex> there's no blank option
[15:37] <abentley> lamalex: Go to the series which is your development focus, and set the branch name to blank.
[15:40] <lamalex> do /what/?
[15:40] <lamalex> ok, found it
[15:40] <lamalex> complicated
[15:44]  * lamalex hopes
[15:46] <lamalex> win!
[15:50] <lamalex> abentley: thanks a lot for your help
[15:50] <lamalex> seems to be working now
[15:50] <abentley> lamalex: I'm glad.  You're welcome.
[16:05] <mthaddon> abentley: did you still need help finding the branch id of a branch?
[16:06] <abentley> mthaddon: No, I was able to figure it out, thanks.
[16:06] <mthaddon> cool
[16:18] <fta> PPA exceeded its size limit (41398.00 of 40600.00 MiB).
[17:54] <mxpxpod> has launchpad resumed scanning release url patterns?
[18:20] <james_w> is the soyuz import from Debian running ok?
[18:21] <james_w> hmm, maybe it's a problem with Debian actually
[18:23] <james_w> the package is in the archive since the 7th, but LP is out of date
[18:23] <james_w> https://edge.launchpad.net/debian/+source/nagios-plugins
[18:24] <barry> bigjools: ^^
[19:57] <mtaylor> hey all... there's a "(community)" next to a reviewer's name on merge request review... what does it designate? It doesn't seem to be relevant to our project - or at least I don't know how any of us could be non-community
[20:01] <barry> mtaylor: do you have a link?
[20:01] <mtaylor> barry: https://code.edge.launchpad.net/~dshrews/drizzle/my_dir_removal/+merge/8426
[20:01] <mtaylor> barry: you'll notice both reviewers are marked as community
[20:04] <barry> mtaylor: that's pretty interesting!  i've never seen that before.  when the antipodeans wake up we can ask them.  in the meantime, let me check the code.
[20:05] <mtaylor> barry: silly people in other timezones...
[20:06] <barry> mtaylor: yeah!
[20:06] <mtaylor> barry: I'm glad that it hasn't been there for years and I'm just now noticing it at least. :)
[20:06] <barry> mtaylor: or as homer might say: stupid rotating earth!
[20:06] <mtaylor> doh
[20:06] <Ursinha> lol
[20:09] <barry> mtaylor: source to the rescue!  that tag means that the person reviewing it is not a member of the default branch reviewer team
[20:10] <barry> mtaylor: i.e. not a drizzle-developer
[20:10] <barry> mtaylor: indeed brian aker does not appear to be a member of that team
[20:11] <barry> afaict
[20:11] <barry> mtaylor: basically it means it's an "unofficial" review
[20:27] <mtaylor> barry: hrm. that's interesting. because both brian and jay are members of ~drizzle-developers (brian is the owner of the team, in fact)
[20:28] <mtaylor> barry: bug perhaps?
[20:29] <barry> mtaylor: i think so.  i could be reading the code wrong, but it might be a bug.  jml, mwhudson, thumper are any of you awake yet?
[20:29] <mtaylor> barry: makes sense if it's a team member/non-team-member thing
[20:31] <barry> mtaylor: yep, i think that's the basic intent.  i could be reading the team membership check wrong though.  those guys will be up and active in a few hours so we can ask them then
[20:34] <mtaylor> barry: awesome. thanks!
[20:45] <Kangarooo> drupal doesn't want to be translated? https://translations.launchpad.net/drupal
[20:47] <barry> Kangarooo: apparently not in launchpad at least
[20:48] <barry> Kangarooo: http://drupal.org/project/Translations
[20:48] <Kangarooo> ubuntu is working with it also..
[20:57] <MrKanister1> hi. I got a question regarding the python launchpad API
[20:58] <MrKanister1> oh...it's two questions :)
[20:58] <MrKanister1> 1. I heard about "launchpadlib" and "launchpadbugs" which should work quite different
[20:59] <MrKanister1> which of them can you recommend?
[20:59] <dpm> barry: can you give me a hand purging the mailing list for https://launchpad.net/~launchpad-translators-leaders? It's about what I was asking you last week regarding renaming the team
[21:00] <barry> dpm: done!
[21:00] <dpm> barry: awesome, thanks (I might ask you for another one in a few minutes)
[21:01] <barry> dpm: np
[21:01] <barry> MrKanister1: i'm not familiar with launchpadbugs
[21:02] <barry> MrKanister1: launchpadlib is the python binding we're supporting
[21:02] <MrKanister1> barry: I think launchpadbugs was created by Markus Korn and it integreates functions of it (found this: http://www.linux-archive.org/launchpad-user/140985-launchpad-api-testing.html)
[21:02] <jpds> MrKanister1: launchpadlib.
[21:03] <jpds> MrKanister1: I'm not sure what thekorn  is doing with it in the light of the API.
[21:04] <MrKanister1> barry, jpds: ok..thanks. Now, although digging through some pages of documentation, I don't know how to get for example the importance of a bug
[21:05] <dpm> hm, I'm trying to rename a team from 'launchpad-translators-leaders' to 'launchpad-translations-coordinators', but I get a "The name 'launchpad-translations-coordinators' has been blocked by the Launchpad administrators." error. Could anyone give me a hand on that?
[21:05] <MrKanister1> I make it to the point where I can do "bug = launchpad.bugs[1]" and can read out the title, etc, but I don't know how to get further
[21:05] <barry> dpm: you'll have to ask a losa or kiko-fud for that i think
[21:06] <barry> mthaddon, herb ^^
[21:06] <mthaddon> dpm: I can take care of that for you
[21:06] <dpm> thanks barry, thanks mthaddon
[21:06] <jpds> MrKanister1: http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/annotate/head%3A/requestsync#L364
[21:07] <mthaddon> dpm: can you file a quick question on LP with the request just so we can track it? https://answers.launchpad.net/launchpad/+addquestion
[21:08] <barry> MrKanister1: it may be that bug importance isn't exported yet
[21:08] <jpds> barry: 'tis.
[21:09] <barry> jpds: cool
[21:09] <MrKanister1> jpds: Thank you VERY much. I could not find any clue how to get information out of collections
[21:09] <dpm> mthaddon: done -> https://answers.edge.launchpad.net/launchpad/+question/76523
[21:09] <barry> jpds: oops, indeed.  i was looking at the wrong interface
[21:12] <jpds> MrKanister1: No problem. We make good use of the API in ubuntu-dev-tools :)
[21:12] <mthaddon> dpm: ok, that's done
[21:14] <MrKanister1> jpds: hm...maybe I should have looked in that package first...I had a look at the package "bughelpers", but it is entirely using "launchpadbugs" :/
[21:15] <jpds> MrKanister1: Yeah, we ported everything from that and screen-scrapping to the API a while back.
[21:15] <jpds> Does the trick and all.
[21:17] <MrKanister1> jpds: ok. I should investigate more time in that ... Python is great :). Thanks again for pointing me to right approach
[21:19] <dpm> mthaddon: thanks a lot!, I'd like to migrate the archive from the old list, could you help me with that? -> https://answers.edge.launchpad.net/launchpad/+question/76523
[21:19] <DanielSouza> I'm having problems importing code from a git repository
[21:19] <DanielSouza> https://code.launchpad.net/~vcs-imports/nationbuilder/trunk
[21:20] <DanielSouza> I think it is a bug of the importer script
[21:20] <mthaddon> dpm: I thought I'd checked that and there was no mailing list configured?
[21:21] <dpm> mthaddon: I had to deactivate the old one in order to rename the team. I've just applied for the new one.
[21:22] <mthaddon> barry: any ideas? I don't see any folder on forster's lists directory
[21:22] <mthaddon> barry: does the mailing list get purged when we rename?
[21:23] <barry> mthaddon: we had to purge it before we renamed it, but the old archive should still exist
[21:23] <barry> mthaddon: look in archives/listname.mbox
[21:23] <barry> er
[21:23] <barry> archives/private/listname.mbox
[21:24] <mthaddon> barry: ok, I see it - just rename it to the new team name?
[21:24] <barry> mthaddon: there should be a listname.mbox file in that directory (yep, it's repeated).  that will serve as the input to the mhonarc command you need to run to re-import
[21:24] <mthaddon> ok
[21:24] <barry> mthaddon: hang on, there's a wiki page about this
[21:24] <mthaddon> yeah, finding it now
[21:24] <DanielSouza> I'm having problems importing code from a git repository
[21:24] <DanielSouza> https://code.launchpad.net/~vcs-imports/nationbuilder/trunk
[21:24] <DanielSouza> I think it is a bug of the importer script
[21:25] <barry> DanielSouza: let me take a look
[21:25] <barry> mthaddon: ping me if you can't find it
[21:31] <mthaddon> dpm: ok, archives migrated - if you configure the mailing list now it should all just DTRT
[21:32] <mthaddon> dpm: let me know if you have any issues, as typically we import the archives after the list is created whereas here we've done it before
[21:32] <mthaddon> (can just redo if we need to)
[21:32] <DanielSouza> Also I my having problems with the translation been waiting review for days to be imported https://translations.launchpad.net/nationbuilder/+imports
[21:33]  * henninge looks at that
[21:33] <henninge> DanielSouza: are those files templates?
[21:34] <DanielSouza> what is the differnece?
[21:34] <dpm> mthaddon: awesome, thanks. Actually, the mailing list is pending approval. Is this an automatic process or does it have to be manually activated by someone?
[21:34] <DanielSouza> all files are separated branches of the translation
[21:35] <mthaddon> dpm: just approved
[21:35] <pace_t_zulu> hey guys... i'm trying to setup a launchpad project for packaging a project hosted elsewhere
[21:35] <dpm> mthaddon: thanks!
[21:35] <pace_t_zulu> the example i'm following is chromium-browser
[21:35] <mthaddon> dpm: hmm, looks like I'll need to reimport the archives - one sec
[21:36] <dpm> np
[21:36] <henninge> DanielSouza: you mean different translation domains, therefore different templates.
[21:36] <pace_t_zulu> i see that the trunk can be pulled from "lp:chromium-browser"
[21:36] <pace_t_zulu> i see that the trunk can be pulled from "lp:chromium-browser" ... how can that be achieved for another project?
[21:36] <henninge> DanielSouza: they should be named *.pot
[21:36] <DanielSouza> understood
[21:38] <henninge> DanielSouza: please read the relevant help pages
[21:38] <henninge> https://help.launchpad.net/Translations/YourProject
[21:38] <henninge> https://help.launchpad.net/Translations/ImportPolicy
[21:39] <mthaddon> dpm: ok, seems to be better now - https://lists.launchpad.net/launchpad-translations-coordinators/
[21:39] <henninge> https://help.launchpad.net/Translations/ImportingFromBazaarBranches
[21:39] <henninge> DanielSouza: ^ if that applies
[21:40] <henninge> DanielSouza: main problem I see with your templates is that they are all in the same directory
[21:40] <DanielSouza> i have only one source code branch, but i have 4 po files, what I do?
[21:40] <mthaddon> pace_t_zulu: assign the relevant branch as a development focus for the project
[21:40] <henninge> DanielSouza: that must be because you used 4 different translation domains in your source code.
[21:41] <pace_t_zulu> mthaddon: will it automatically get that new location... ie: "lp:myproject"
[21:41] <DanielSouza> translation domains = languages?
[21:41] <henninge> DanielSouza: it is easier to maintain if you only have one domain
[21:41] <henninge> no
[21:41] <mthaddon> pace_t_zulu: if you do that, yes
[21:41] <henninge> DanielSouza: you should familiarize yourself with gettext
[21:41] <DanielSouza> Im newbie on that, im not a developer, i converted those files from yaml files
[21:41] <pace_t_zulu> mthaddon: thank you
[21:42] <henninge> DanielSouza: RTFM still applies
[21:42] <mthaddon> pace_t_zulu: you can still reference it at the full location, lp:myproject is just a convenience shortcut for whatever is assigned development focus
[21:42] <pace_t_zulu> mthaddon: what about a vcs-import ... is it ill advised to used that as the "development focus" ?
[21:42] <henninge> DanielSouza: in short: you can group your translatable strings using translation domains.
[21:42] <pace_t_zulu> mthaddon: the codebase is managed by git at sourceforge right now
[21:43] <mthaddon> pace_t_zulu: er, not sure to be honest...
[21:43] <henninge> DanielSouza: but usually you use one translation domain per proejct/program
[21:43] <pace_t_zulu> mthaddon: i'll stick to having a launchpad based packaging right now... that's why i was looking at chromium-browser as my example
[21:43] <henninge> DanielSouza: that is easier to maintain, especially with Launchpad uploads.
[21:43] <dpm> mthaddon: it looks good! Now if I can still steal some more of your time, I'd like to do the same for another list (purge ML, rename team, migrate archive). Here's the initial purge request -> https://answers.edge.launchpad.net/launchpad/+question/76527
[21:44] <henninge> DanielSouza: You should talk to the developers then why they choose to use multiple translation domains.
[21:45] <mthaddon> dpm: you should be able to purge it as an admin of the team - let me know when you've done that and I'll do the rename for you
[21:45] <dpm> mthaddon: I thought it was the other way round - I can't do the purge, but I can do the rename
[21:46] <dpm> the last time barry had to do the purge for me
[21:46] <DanielSouza> henninge, i will try talk to then, but as everybody on the project are newbies with po files we dont to complicate it a lot
[21:46] <mthaddon> ah, okay
[21:47] <mthaddon> dpm: ok, purged - let me know if you can't rename
[21:47] <henninge> DanielSouza: then they need to use only one translation domain in their source code.
[21:47] <DanielSouza> we dont use po on the translation but yaml files
[21:48] <DanielSouza> and convert then with yml2po.sh and po2yml.sh
[21:49] <henninge> DanielSouza: ok, then check were those scripts get the 4 translation domains from. I don't know anything about yaml.
[21:49] <pace_t_zulu> mthaddon: thanks for your help
[21:50] <mthaddon> sure
[21:50] <DanielSouza> henninge, yaml is "YAML isnt Another Markup Language" its a markup language
[21:50] <Kangarooo> https://launchpad.net/~locoteams this is not loading.. 4 or 6 days ago first time I noticed that..
[21:51] <DanielSouza> henninge, this is the yaml files tree
[21:51] <DanielSouza> daniel@opensuse-n1:~/Desktop/nationbuilder/config> ls -r locales/
[21:51] <DanielSouza> notifications  menu  general  activities
[21:51] <DanielSouza> henninge, i tried to use the convertor to create a single pot file, but it failed
[21:52] <dpm> mthaddon: yes, I could rename. could you now please approve the new ML and migrate the archive? -> https://answers.edge.launchpad.net/launchpad/+question/76527
[21:54] <mthaddon> dpm: ok, should be all done now
[21:58] <dpm> mthaddon: brilliant, thanks a lot, Tom!
[21:58] <mthaddon> sure
[22:10] <henninge> DanielSouza: I have to go now. You will have to find somebody with experience in yml2po and acquaint yourself more with the matter to find out how to produce a single template. Upload that as a .pot file to have it approved.
[22:15] <DanielSouza> henninge thanks for all!
[22:16] <thumper> Ursinha: pig
[22:26] <barry> thumper: hey
[22:27] <thumper> barry: hey man
[22:27] <thumper> barry: what's up?
[22:27] <barry> thumper: mtaylor had a question a few hours ago about the (community) tag next to a person's name in a merge proposal
[22:28] <thumper> barry: heh
[22:28] <barry> thumper: what exactly does that mean?
[22:28] <thumper> barry: bug
[22:28] <barry> mtaylor: ^^ :)
[22:28] <thumper> barry: the idea is that if the review was done by a non-reviewer, it should show (community)
[22:28] <thumper> we have brought back the "anyone can review"
[22:28] <thumper> but wanted to somehow indicate reviews by people who are not on the review team
[22:28] <thumper> nor had been requested to review
[22:28] <barry> thumper: that's what i thought from looking at the code, but it looks like a person who is on the review team got that tag
[22:28] <Lumiere> how do you 'bzr upgrade' a branch on launchpad?
[22:29] <thumper> barry: that bit is the bug
[22:29] <thumper> barry: I believe abentley has landed the fix
[22:29] <thumper> but it hasn't rolled out yet
[22:29] <thumper> edge FTW
[22:29] <barry> thumper: super.  thanks for the confirmation!
[22:29] <thumper> np
[22:30] <barry> Lumiere: have you tried just doing it?  you might have to use an sftp url, but thumper or abentley would know for sure
[22:31] <Lumiere> got it
[22:31] <Lumiere> thank you
[22:32] <Lumiere> hopefully it won't fail
[22:41] <Ursinha> thumper, pig was funny :P
[22:42] <thumper> Ursinha: oops, sorry, ment ping
[22:42] <Ursinha> thumper, I know :)
[22:42] <Ursinha> thumper, what's up
[22:42] <thumper> Ursinha: the critical bug isn't really critical
[22:42] <thumper> just high
[22:42] <thumper> should be fixed with 1.17 release of bzr
[22:43] <Ursinha> thumper, hmm, I see
[22:43]  * Ursinha chases the bug no.
[22:47] <Ursinha> thumper, I'll change the status then
[22:47] <thumper> ta
[22:49] <Ursinha> bug 390563
[22:49] <Ursinha> meh
[22:51] <barry> okay folks.  i done my duty so i'll see y'all tomorrow
[22:51] <barry> happy launchpadding
[23:05] <kb9vqf> anyone here willing/able to increase PPA space?
[23:06] <kb9vqf> https://answers.launchpad.net/soyuz/+question/76526
[23:06] <kb9vqf> :)
[23:09] <mwhudson> willing, yes
[23:09] <mwhudson> able, no
[23:12] <BUGabundo> gmb: ping do you have a minute?
[23:18]  * kb9vqf kicks his PPA
[23:20] <maxb> kb9vqf: A temporary option for you might be to delete some superseded versions
[23:21] <maxb> until you can find an admin
[23:22] <kb9vqf> Yeah, In know...but that takes many hours as well
[23:23] <wgrant> I thought 'many' == 1 for deletions.
[23:25] <BUGabundo> one thing I never understood: if APT is able to store several versions of a package, why won't PPAs allow it too? tech prob?
[23:25] <wgrant> BUGabundo: Why would you want to?
[23:26] <wgrant> apt will always try to upgrade to the latest.
[23:26] <BUGabundo> I know
[23:26] <wgrant> So it doesn't really make sense to have anything but the latest, unless you keep reinstalling old ones by specifying a particular version.
[23:26] <BUGabundo> but one may want to downgrade
[23:26] <BUGabundo> and since PPAs superseed, one can't access via apt the older version
[23:27] <BUGabundo> while they still are lodge on LP
[23:27] <wgrant> Keeping old versions around automatically would eat lots of disk space.
[23:28] <wgrant> Allowing copying of old versions back in would be confusing.
[23:28] <BUGabundo> wgrant: never wanted to downgrade?
[23:28] <BUGabundo> I have. lots of times
[23:28] <wgrant> No. I just fix the bug.
[23:28] <BUGabundo> try to get NM packages by hand
[23:28] <BUGabundo> eheheheeheheheheheh
[23:28] <BUGabundo> wgrant: AAHHAHAHAHAAHAH
[23:29] <BUGabundo> not all bugs are fixed by newer versions
[23:29] <BUGabundo> at least not in a short time period
[23:35] <Lumiere> anyone who has access to bzr on lp?
[23:35] <Lumiere> cause I think that my bzr upgrade on lp:gasp-lessons crashed mid-stream
[23:38] <mtaylor> barry, thumper: cool. thanks
[23:38] <mtaylor> thumper: do you mean that I should see the fix in edge? or I should see the bug in edge?
[23:39] <thumper> mtaylor: you should see the fix in edge soon
[23:39] <thumper> mtaylor: the bug won't show on production right now
[23:39] <mtaylor> thumper: sweet. thanks
[23:40] <thumper> Lumiere: the LOSAs do
[23:41] <mthaddon> Lumiere: what do you need?
[23:44] <Lumiere> mthaddon: I had a bzr upgrade on lp:gasp-lessons fail midstream
[23:44] <Lumiere> and I can't run it again
[23:44] <mthaddon> Lumiere: what errror are you getting?
[23:45] <Lumiere> t
[23:45] <Lumiere> err /t
[23:46] <mthaddon> I'm not sure I'm following - can you paste the full output?
[23:46] <Lumiere> sec
[23:47] <Lumiere> http://paste.lisp.org/+1SAL
[23:47] <thumper> mthaddon: bzr moves the .bzr dir out of the way to backup.bzr
[23:47] <thumper> mthaddon: probably just needs backup.bzr moved to .bzr
[23:48] <Lumiere> and then if you could run the bzr upgrade it would be wonderful
[23:48] <mthaddon> thumper: yeah, that's what I thought, just wanted to check
[23:48] <Lumiere> I have been having issues with my network crapping out in the middle of that cast
[23:48] <thumper> Lumiere: it is normally easier to run upgrade on your local copy
[23:48] <Lumiere> thumper: the problem is getting the lp one upgraded too
[23:48] <mthaddon> thumper: http://paste.lisp.org/display/83325 - looks like a different error to me?
[23:48] <thumper> Lumiere: have you heard of hitchhiker?
[23:48] <Lumiere> no
[23:49] <Lumiere> I have a couple remote branches that are branch version 6,
[23:49] <Lumiere> but it didn't seem to upgrade that one
[23:49] <thumper> mthaddon: I'm guessing the the existing .bzr dir might not be complete
[23:50] <thumper> mthaddon: to be save move .bzr -> .bzr.old and backup.bzr -> .bzr
[23:50] <thumper> s/save/safe/
[23:50] <thumper> Lumiere: it is a bzr plugin that abentley wrote
[23:50] <Lumiere> thank you for the help, I am going to grab some food
[23:50] <thumper> allows extra hacking :)
[23:50] <Lumiere> ic
[23:51] <thumper> mthaddon: actually
[23:51] <thumper> mthaddon: you could just not move the backup.bzr back
[23:51] <thumper> which would leave a non-existant .bzr
[23:51] <mthaddon> thumper: just let me know - I see the folder here - so what should I do?
[23:51] <thumper> so a fresh push would mean Lumiere would not need to upgrade
[23:51] <thumper> mthaddon: move .bzr to .bzr.old
[23:52] <thumper> mthaddon: there shouldn't be a .bzr dir there now
[23:52] <mthaddon> thumper: isn't that going to flood subscribers?
[23:52] <thumper> mthaddon: shouldn't
[23:52] <thumper> mthaddon: as the database thinks it has a certain revision there already
[23:53] <mthaddon> thumper: seems like Lumiere has stepped away to grab some food so I don't think he can push if I do this
[23:53] <thumper> Lumiere: do a `bzr push --use-existing lp:gasp-lessons`
[23:53] <thumper> mthaddon: ok, wait till he is back
[23:54] <thumper> Lumiere: what version have you upgraded to locally?
[23:54] <mthaddon> thumper: bzr info seems okay on the branch - should I just try moving the old back and running bzr upgrade?
[23:55] <thumper> mthaddon: are you in the mirrored or hosted area?
[23:55] <mthaddon> push-branches
[23:55] <thumper> ok
[23:55] <thumper> that's right
[23:55] <thumper> mthaddon: we should make sure the versions are the same
[23:56] <thumper> going from knits -> packs can take a while, but he only has 74 revisions, so likely to be fast no matter what
[23:56] <mthaddon> maybe just remove backup.bzr and leave it to him?
[23:56] <thumper> there seems to be a concurrency issue


[00:00] <ali1234> currently appindicators are failing to add menu items correctly but removing works
[00:00] <ali1234> see bug 1203888
[00:01] <tedg> ali1234, I don't remember.  Does adding that on those fix it?
[00:03] <ali1234> well adding is what is broken, so i suspect removing the check like with remove would fix it... just about to try it
[01:06] <ali1234> well, this is certainly related - changing "child-added" to "something-else" causes the error message to change as expected. but changing it to "insert" to match the GTK3 case causes a segfault
[01:45] <ali1234> tedg: so it turns out the fix is to remove all the GTK3 tests from that file - they all apply only to the item insert cb
[01:46] <ali1234> and specifically the other two modify the argument list to the cb function - and calling it with the wrong set of arguments obviously caused the segfault
[08:47] <tsdgeos> mhr3: can you comment on https://code.launchpad.net/~aacid/unity8/lvwph_bad_header_position_1240118/+merge/193200 that it actually fixes the problem for you?
[08:52] <mhr3> tsdgeos, done
[08:54] <tsdgeos> tx
[08:56] <tsdgeos> mzanetti: so no landing of the packages we needed?
[08:57] <mzanetti> tsdgeos: hmm... seems so :/
[08:58] <tsdgeos> :(
[08:58] <tsdgeos> keep piling up! :D
[08:58] <tsdgeos> it's almost my full screen height of reviews now :D
[09:00] <tsdgeos> mzanetti: can you quick look at https://code.launchpad.net/~cimi/unity8/fix-1231731/+merge/191414 ? can i top approve?
[09:01] <mzanetti> tsdgeos: done
[09:01] <tsdgeos> tx
[09:02] <mzanetti> tsdgeos: a few days ago you asked me about the searchhistorymodel
[09:02] <tsdgeos> yep
[09:02] <mzanetti> tsdgeos: I see in nic's branch that there is one in Shell.qml
[09:02] <tsdgeos> yep
[09:03] <mzanetti> which doesn't seem to be used at all
[09:03] <tsdgeos> it's just unused as stands now
[09:03] <tsdgeos> yep
[09:03] <mzanetti> ok.
[09:03] <mzanetti> I'll note that down
[09:03] <tsdgeos> and every ScopeView ahs anthoer
[09:03] <tsdgeos> that is also unused as of now
[09:03] <mzanetti> yeah, now there is one in Dash.qml with makes it shared among all scopes
[09:03] <tsdgeos> just the ones in PageHeader are being used now
[09:03] <mzanetti> oh, another one?
[09:03] <mzanetti> yeah, the one in PageHeader is gone now
[09:04] <tsdgeos> ok
[09:04] <tsdgeos> yet another conflict for my tabbar branch :D
[09:04] <tsdgeos> need multi-rebasing :D
[09:04] <tsdgeos> or just wait some decent time for all the stuff to be merged in
[09:04] <mzanetti> yeah... I guess we should start rebasing stuff and create a chain of prerequisities
[09:05] <mzanetti> although that has potential to explode too
[09:07] <tsdgeos> yeah
[09:08] <tsdgeos> let's just let it explode organically
[09:09] <tsdgeos> oh man the new notify-osd killer code is annoying
[09:09] <tsdgeos> hmmm
[09:09] <tsdgeos> which actually means it's been released?
[09:10] <tsdgeos> the shell now kills my notify-osd
[09:10] <tsdgeos> and obviously it doesn't come back after killing the shell
[09:10] <tsdgeos> so i get some weird old kde notifications floating around :D
[09:10] <tsdgeos> mzanetti: was notify-osd the only thing we needed?
[09:11] <mzanetti> MacSlow: ^
[09:12] <mzanetti> I think yes
[09:12] <mzanetti> tsdgeos: well, its 2 of them
[09:12] <tsdgeos> so maybe we can trigger a single branch manually or something to see how it goes?
[09:12] <MacSlow> mzanetti, tsdgeos: that's what was supposed to happen
[09:12] <mzanetti> one moment
[09:13] <tsdgeos> MacSlow: i know, it's only annoying as a desktop user :D
[09:13] <MacSlow> tsdgeos, probably... :)
[09:14] <MacSlow> tsdgeos, but as I'm on unity (on the desktop) as soon as I quit my unity8-shell the next notification will trigger starting system-wide notify-osd again
[09:14] <MacSlow> tsdgeos, I assume you're running KDE
[09:15] <tsdgeos> MacSlow: nope at work-work time
[09:15] <tsdgeos> i'm running unity+apps
[09:15] <tsdgeos> most of the apps kdelibs-based
[09:15] <tsdgeos> and notify-osd doesn't restart here unless i manually start it
[09:20] <nic-doffay> mzanetti, ping
[09:20] <mzanetti> nic-doffay: hey
[09:20] <MacSlow> tsdgeos, I assume notify-osd doesn't get retriggered because of the KDE-based apps not using libnotify/protocol
[09:20] <tsdgeos> of course :D
[09:21] <tsdgeos> they just use the com.foo.notification  bla daemon if it's there
[09:21] <tsdgeos> and i guess it isn't
[09:21] <MacSlow> tsdgeos, still if it (notify-osd) runs, it's able to consume notifications triggered by KDE-apps?!
[09:21] <tsdgeos> MacSlow: sure
[09:22] <MacSlow> tsdgeos, but if you see knotify rendered notifications, that means you've some special service-file explicitly triggering that daemon instead of notify-osd?
[09:23] <MacSlow> tsdgeos, I'm just trying to reproduce it on my desktop here... pulling updates atm
[09:23] <tsdgeos> MacSlow: yeah, kdelibs may lift up it's own daemon for org.freedesktop.Notifications if it doesn't find anything there
[09:24] <tsdgeos> does anyone have a clue how to know which app is serving org.freedesktop.Notifications ?
[09:25] <tsdgeos> anyway not something to spend time on
[09:25] <MacSlow> tsdgeos, hm... but should not /usr/share/dbus-1/services/org.freedesktop.Notifications.service be controlling what daemon gets started?
[09:25] <tsdgeos> it's a very -dev specific usecase
[09:25] <tsdgeos> MacSlow: no clue :D
[09:26] <MacSlow> tsdgeos, that's how it works on my system... although I'm not familiar with the KDE-side of this... so no idea how that might inject yet another notification-daemon
[09:26] <MacSlow> tsdgeos, sorry
[09:26] <tsdgeos> as said
[09:27] <nic-doffay> mzanetti, still wondering how to make the search history persist between unity8 restarts. Any ideas?
[09:27] <MacSlow> tsdgeos, sure
[09:27] <tsdgeos> no need to spent time on this
[09:27] <tsdgeos> was just saying
[09:27] <mzanetti> nic-doffay: hmm... let me read the SearchHistoryModel code
[09:28] <tsdgeos> so
[09:28] <tsdgeos> back to test writing land
[09:28] <mzanetti> nic-doffay: 2 options: either you check out the LocalStorage qml plugin (I've never used it before) or you create a small QML plugin yourself which dumps stuff somewhere on disk
[09:28] <mzanetti> tsdgeos: any opinion? ^
[09:29] <tsdgeos> what would you guys go for a test that wants to check we can horizontally swipe the dash if it's scrolling verticallly? ultra scared of "not going to get this to happen at the right time" tbh
[09:30] <tsdgeos> mzanetti: i'd go for the "save it ourselves to disc"
[09:30] <mzanetti> tsdgeos: can we use 2 fingers?
[09:30] <mzanetti> +1 on the "our plugin"
[09:30] <tsdgeos> localstorage seems to much database-y for this usecase
[09:30] <tsdgeos> mzanetti: what do you mean 2 fingers?
[09:30] <mzanetti> nic-doffay: I can help you getting started with the QML plugin if you've never done that before
[09:30] <mzanetti> tsdgeos: let me test something
[09:31] <mzanetti> tsdgeos: is that fix already released?
[09:31] <tsdgeos> mzanetti: yep
[09:31] <tsdgeos> https://code.launchpad.net/~aacid/unity8/dash_disable_hswipe_on_vswipe/+merge/190576
[09:31] <mzanetti> hmm.. ok.
[09:31] <tsdgeos> just wanted to clear that list of bugs without test you created the other day
[09:31] <mzanetti> tsdgeos: well, in the launcher tests I flick it up/down
[09:31] <mzanetti> tsdgeos: if the list is long enough that lasts for 2 secs
[09:31] <tsdgeos> ok
[09:31] <mzanetti> which really should be enough for trying to swipe horizontally
[09:32] <tsdgeos> i guess i can try to have a long list
[09:32] <tsdgeos> let's go for a qml test then :D
[09:32] <mzanetti> definitely
[09:32] <nic-doffay> mzanetti, yeah if you don't mind.
[09:33] <mzanetti> nic-doffay: ok. so. I'd say you dump it into plugins/Unity/
[09:33] <mzanetti> nic-doffay: create a class, inheriting QObject called SearchHistoryModel
[09:34] <mzanetti> hook it up in plugin.cpp just like the others
[09:34] <mzanetti> and give it a function addQuery(const QString &query)
[09:35] <mzanetti> then you should be able to just drop Components/SearchHistoryModel.qml and wherever Unity 0.1 is imported it should just use the new cpp SearchHistoryModel instead
[09:35] <mzanetti> in there you can then easily write/read a file
[09:35] <tsdgeos> mzanetti: wouldn't it be easier to write only the dumper, not a whole model?
[09:35] <tsdgeos> otherwise it'll need to be a QAbstractItemModel and all that, no?
[09:36] <mzanetti> tsdgeos: yeah... was going to say. instead of QObject, make it QAbstractListModel
[09:36] <mzanetti> tsdgeos: hmm... you think we should have only a dumper?
[09:36] <mzanetti> tsdgeos: I guess this well be quite useful in the future, when we might want to filter stuff etc
[09:36] <tsdgeos> mzanetti: i think it'd be easier, i guess it depends if/when we want to sync the file to disk
[09:36] <mzanetti> also we need something like clear() and whatnot.
[09:37] <tsdgeos> mzanetti: ok, if you see us using more modellike stuff
[09:37] <mzanetti> I think implementing count() and data()  would be easier in the long run than keeping a qml ListModel and some file on disk in sync
[09:37] <tsdgeos> mzanetti: may as well use qstringlistmodel
[09:38] <mzanetti> right
[09:38] <tsdgeos> if all we want is a list of strings
[09:38] <mzanetti> nic-doffay: QStringListModel
[09:38] <tsdgeos> though QStringListModel is a bit silly doesn't have an insert
[09:38] <tsdgeos> so don't know :D
[09:38]  * tsdgeos stops suggesting/unsuggesting things
[09:38] <mzanetti> yeah, hence the addQuery() which then keeps it api compatible to the existing one
[09:39] <mzanetti> nic-doffay: is that good enough for a start?
[09:42] <nic-doffay> mzanetti, yeah that's cool.
[09:42] <nic-doffay> cheers
[09:44] <nic-doffay> mzanetti, so inherit from QStringListModel which will replace the current QML class?
[09:44] <mzanetti> nic-doffay: yep. class SearchHistoryModel: public QStringListModel
[09:45] <mzanetti> after you added "addQuery()" it should just work automagically to replace the qml one
[09:45] <nic-doffay> mzanetti, great. I wanted the break from QML too tbh!
[09:45] <mzanetti> cool
[10:16] <mzanetti> tsdgeos: fyi: notify-osd has been released. but I just realize that we probably need to upgrade the jenkins machines, otherwise the old one is still running
[10:16] <mzanetti> and I've no clue about the otto jenkins machines
[10:16] <tsdgeos> mzanetti: hmmm
[10:16] <mzanetti> but once fginther shows up I think we can have that
[10:16] <tsdgeos> ok
[10:17] <tsdgeos> i thought stuff was upgraded on each run?
[10:17] <tsdgeos> or only the stuff we depend on
[10:17] <tsdgeos> and not the base system?
[10:17] <mzanetti> tsdgeos: I don't think we upgrade the base system every time. would be a huge waste of time
[10:18] <tsdgeos> but a way we work against the current status of system libs :D
[10:18] <tsdgeos> but i can see why we don't do it
[10:18] <tsdgeos> anyway, good that we're one step closer!
[10:34] <Cimi> you guys have bugs for me?
[10:43] <tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/no_hswipe_if_vswipe_test/+merge/193401
[10:46] <Cimi> tsdgeos, and?
[10:46] <tsdgeos> review?
[10:46] <tsdgeos> :D
[10:46] <Cimi> tsdgeos, why this?
[10:46] <tsdgeos> why not?
[10:48] <tsdgeos> anyone knows how to know which "3 people" are affected by a bug when launchpad says "3 people affected by this bug"
[10:48] <tsdgeos> ?
[10:50]  * tsdgeos likes c++ chained constructors
[10:50] <tsdgeos> hurray for them
[10:50] <tsdgeos> \o/
[10:55] <tsdgeos> hmmm
[10:55] <tsdgeos> https://bugs.launchpad.net/unity8/+bug/1229652 is not *our* bug, no?
[10:55] <tsdgeos> we don't have those strings anywhere
[10:55] <tsdgeos> mhr3: ? ↑↑ ?
[10:59] <mhr3> tsdgeos, right
[10:59] <tsdgeos> mhr3: which projects do i reassign this to
[10:59] <tsdgeos> ?
[10:59] <mhr3> already done
[10:59] <tsdgeos> tx
[11:00] <tsdgeos> Cimi: if you're totally bored, can you try to reproduce the crash mentioned in https://bugs.launchpad.net/unity8/+bug/1240408 ?
[11:08] <Cimi> tsdgeos, nt that bored :D
[11:14] <tsdgeos> Cimi: ok, we ave around 155 bugs
[11:15] <tsdgeos> i'm sure you can find something, no?
[11:15] <Cimi> tsdgeos, not much on unassigned ones
[11:15] <Cimi> tsdgeos, I picked up a dozen already, fixed all
[11:15] <Cimi> tsdgeos, we need more bugs :)
[11:16] <Cimi> http://goo.gl/VDU0V4
[11:17] <tsdgeos> Cimi: that's the unassigned ones?
[11:17] <Cimi> y
[11:17] <Cimi> I'm looking if there's something for me
[11:18] <Cimi> might do this https://bugs.launchpad.net/unity8/+bug/1236280
[11:19] <Cimi> but probably requires a snapshot of the dash as a normal app?
[11:19] <tsdgeos> greyback: ↑↑↑
[11:21] <greyback> Cimi: yes it would. That can be done, but I believe I designed unity-mir to not make that easy
[11:23] <Cimi> preserving the scroll position is complicated also
[11:23] <Cimi> because I put that when you left swipe
[11:23] <Cimi> it switches to app scope
[11:23] <Cimi> so if the user starts a left swipe, cancels
[11:23] <Cimi> does a right swipe
[11:23] <Cimi> the dash will lose the original position
[11:25] <greyback> Cimi: yeah. that bug will require lots of changes everywhere
[11:26] <greyback> Cimi: since I'll be refactoring much of that window management code - and the right-edge switch-application animation will be changed, I don't think now is the good time to take that one on
[11:26] <Cimi> greyback, unless we store contentX of dashContentList and contentY of the dashContentList.currentItem
[11:27] <Cimi> greyback, basically when dash is no longer in focus, we save those
[11:28] <Cimi> greyback, when we go back to the dash, we reapply those
[11:29] <greyback> Cimi: hold on. You'd be taking a snapshot of the shell's surface and adding it to the list of application surfaces to switch through
[11:29] <Cimi> greyback, yes
[11:29] <greyback> Cimi: I don't see why you're changing contentX
[11:29] <Cimi> greyback, but as said, when you left swipe to reveal the dash
[11:30] <Cimi> greyback, we have to switch to app lens, contentY = 0
[11:30] <Cimi> greyback, by design
[11:30] <Cimi> greyback, so if the user is using camera
[11:30] <Cimi> greyback, starts swiping left
[11:31] <Cimi> greyback, (note that now the dash should be on the app lens)
[11:31] <Cimi> greyback, then changes his mind and remains on the camera app
[11:31] <Cimi> then after a while he right swipe and choose the dash
[11:31] <Cimi> greyback, the dash will be on the app lens because the previous left swipe changed that
[11:33] <Cimi> greyback, problem is, left swipe is an animation thus when the finger is a little bit after the launcher you should already start seeing the app lens appearing
[11:34] <Cimi> greyback, relevant code here https://code.launchpad.net/~cimi/unity8/fix-1231996/+merge/192372
[11:34] <Cimi> and bug https://bugs.launchpad.net/unity8/+bug/1231996
[11:35] <Cimi> only way I can see having both scenarios working at the same time is storing the position (contentX and Y) of the dash when you take its snapshot
[11:36] <greyback> Cimi: (aside: for the first MR, that commit message is not clear. It just says steps to repro a problem, not saying what the problem actually is, nor giving the solution the MR performs)
[11:37] <Cimi> greyback, no it says id
[11:37] <Cimi> *it
[11:37] <Cimi> greyback, it switches to app scope when dash swipe *is taking place*
[11:37] <greyback> Cimi: ah I get it, sorry
[11:38] <Cimi> np
[11:39] <greyback> Cimi: so, snapshots of shell surface are tricky. You know that when an application is on screen, the shell surface is always on top of it, but defines a big transparent rectangle that allows the application to be visible
[11:40] <Cimi> yeah got that
[11:40] <Cimi> so yeah it's difficult
[11:40] <greyback> Cimi: so the only time we can grab snapshot of whole dash, is when dash fully on screen.
[11:40] <Cimi> greyback, we should take the snapshot only when the shell is in focus
[11:41] <Cimi> greyback, snapshots of dash are taken only when no app is above it
[11:41] <greyback> Cimi: yep. Taking your problem case, and assuming snapshot of shell Home lens taken and available
[11:41] <Cimi> if you switch to an app, no more snapshots are taken
[11:41] <greyback> Cimi: in camera app, start a left swipe. You see Dash change to Apps lens. Then cancel that left swipe, to return to camera.
[11:42] <greyback> Cimi: in that case, dash is on apps lens. But our snapshot is of home lens.
[11:42] <Cimi> greyback, yes
[11:42] <greyback> and there's no way to grab snapshot of apps lens reliably in that case
[11:42] <Cimi> greyback, so if we stored contentX and Y
[11:42] <Cimi> greyback, when we right swipe we simply restore contentX and Y
[11:43] <greyback> it doesn't matter. User expects to return to apps lens. We cannot show them the home lens snapshot
[11:43] <Cimi> greyback, ok then, no problem exist
[11:43] <Cimi> greyback, problem is the snapshot
[11:43] <Cimi> I see this issue now
[11:43] <Cimi> greyback, we have hard time taking the screeenshot
[11:43] <greyback> Cimi: yep. the snapshot thing is a hack, and this exposes it's faults
[11:43] <greyback> its
[11:44] <Cimi> I thought we wanted to go back to home lens
[11:44] <greyback> so the work to use live surfaces, not screenshots, should fix this. But we're not there yet
[11:46] <mzanetti> greyback: hey
[11:46] <greyback> mzanetti: yo
[11:46] <mzanetti> greyback: veebers would need this to be landed asap: https://code.launchpad.net/~gerboland/unity-mir/crash-fix-on-IFA-removal/+merge/192352
[11:46] <mzanetti> greyback: it looks ok to me, but I don't feel confident enough with the surrounding code to just approve it
[11:47] <greyback> tsdgeos could you have a look, you know that code better
[11:47] <greyback> mzanetti: ^^
[11:48] <tsdgeos> sure
[11:48] <greyback> thanks
[11:51] <tsdgeos> greyback: why aren't you deleting the inputareas anymore?
[11:51] <Cimi> mzanetti, auto landing dance today?
[11:51] <Cimi> how many dancers will fall on the floor? :)
[11:51] <greyback> tsdgeos: I never was. The InputAreas are owned by the QML engine, I let it delete
[11:51] <mzanetti> Cimi: stuff is released. when fginther shows up we can hopefully upgrade the jenkins machines and are good to go
[11:52] <tsdgeos> greyback: oh right, it's commted...
[11:52] <mzanetti> Cimi: can you reproduce this? https://bugs.launchpad.net/unity8/+bug/1240408
[11:52] <Cimi> mzanetti, phone is dead now
[11:52] <Cimi> mzanetti, will try after it charges
[11:53] <mzanetti> ok
[11:54] <tsdgeos> greyback: code looks good, want me tro try it actually fixes the crash or has someone actually done that already?
[11:54] <tsdgeos> mzanetti: ↑ ?
[11:54] <mzanetti> Cimi: there is an issue with the UbuntuShape in the launcher. if you look very closely, the image size doesn't match with the shape's size. I haven't had the time to dig deeper why. if you want you can have a look at that too
[11:54] <mzanetti> tsdgeos: I haven't
[11:54] <Cimi> mzanetti, I know that
[11:54] <Cimi> mzanetti, designers are in oakland
[11:54] <greyback> tsdgeos: the bug report gives step by step instructions. Woudl do no harm to check
[11:54] <greyback> tsdgeos: sorry, the bug description
[11:55] <mzanetti> Cimi: not sure why designers would be needed there
[11:55] <tsdgeos> greyback: i know, i checked it crashes
[11:55] <Cimi> mzanetti, fix the asset?
[11:55] <tsdgeos> greyback: was asking if someone had checked it did not crash with the patch
[11:55] <tsdgeos> greyback: since noone has, i will
[11:55] <mzanetti> Cimi: there's no asset
[11:55] <Cimi> mzanetti, but I'll assign myself
[11:55] <Cimi> mzanetti, ok
[11:55] <Cimi> mzanetti, there was
[11:55] <mzanetti> Cimi: there is a branch which removes the white glow
[11:55] <mzanetti> use that one
[11:55] <greyback> tsdgeos: well I did, but I'm the author :)
[11:56] <tsdgeos> greyback: sure
[11:56] <Cimi> mzanetti, https://bugs.launchpad.net/unity8/+bug/1223795 ?
[11:56] <mzanetti> Cimi: https://code.launchpad.net/~mzanetti/unity8/launcher-small-tweaks/+merge/191380
[11:56] <mzanetti> Cimi: this one drops the highlight glow as jouni didn't want it at all
[11:56] <mzanetti> Cimi: still the shape doesn't really fit with the icon. no clue why yet
[11:56] <Cimi> mzanetti, ok it's a new bug
[11:57] <Cimi> mzanetti, will look into it
[11:57] <mzanetti> Cimi: btw.. feel free to review/approve that branch too
[11:58] <Cimi> mzanetti, https://bugs.launchpad.net/unity8/+bug/1223795
[11:59] <Cimi> #fail
[11:59] <mzanetti> Cimi: yeah... I'm afraid the UbuntuShape doesn't do it correctly.
[11:59] <Cimi> mzanetti, https://bugs.launchpad.net/unity8/+bug/1246688
[12:00] <mzanetti> yeah... I guess it's sort of the same as the other
[12:11] <tsdgeos> greyback: mzanetti: approved
[12:11] <mzanetti> tsdgeos: thanks
[12:11] <mzanetti> veebers: ^
[12:11] <greyback> thanks!
[12:25] <greyback> tsdgeos: ok, so built 5.2 in chroot, and all unity8 dependencies. It starts, but crashes here: http://pastebin.ubuntu.com/6335431/
[12:26] <greyback> just find it hard to believe launcherbackend doing something funny, that only 5.2 shows
[12:28] <tsdgeos> greyback: it's not a crash
[12:28] <tsdgeos> it's an assert
[12:28] <tsdgeos> QDBusArgument: read from a write-only object
[12:28] <greyback> sorry, yes
[12:28] <greyback> oh, probably fails as dbus not working inside the chroot
[12:29] <tsdgeos> hmmm
[12:30] <tsdgeos> greyback: i'd say something like that yeah
[12:30] <tsdgeos> QVariant variant = m_accounts->getUserProperty(m_user, "com.canonical.unity.AccountsService", "launcher-items");
[12:30] <tsdgeos> probably ends up with a "null" variant
[12:30] <tsdgeos> that with variant.value<QDBusArgument>()
[12:30] <tsdgeos> returns a "null" QDBusArgument
[12:30] <tsdgeos> and then we try to read from it
[12:30] <greyback> agreed
[12:30] <tsdgeos> and qt is unhappy
[12:31] <tsdgeos> still it's weird that is crashing instead of just saying "null"
[12:31] <tsdgeos> maybe crashes because you're on debug mode?
[12:33] <greyback> no idea
[12:33] <nic-doffay> mzanetti, Unable to assign SearchHistoryModel to QQuickListModel from QML.
[12:34] <nic-doffay> ever seen this? I can't find any info on it.
[12:34] <mzanetti> huh?
[12:34] <mzanetti> ah right
[12:34]  * mzanetti confused QQuickListModel with the launchers QuickListModel
[12:34] <mzanetti> nic-doffay: you forgot to qmlRegisterType it
[12:35] <nic-doffay> mzanetti, I def did.
[12:35] <mzanetti> did forget it or you did register it?
[12:35] <nic-doffay> mzanetti, here's the line I added: qmlRegisterType<SearchHistoryModel>(uri, 0, 1, "SearchHistoryModel");
[12:35] <mzanetti> that does look ok
[12:36] <mzanetti> nic-doffay: ah sure. unfortunately QStringListModel isn't a QQuickListModel
[12:36] <nic-doffay> mzanetti, where does QQuickListModel come into play though?
[12:37] <mzanetti> nic-doffay: I assume you didn't delete Components/SearchListModel.qml. And wherever you import Components before importing Unity it'll pick that one up which is in fact a QQuickListModel
[12:38] <nic-doffay> mzanetti, I deleted it.
[12:38] <greyback> gah qt docs URLs changed /again/
[12:39] <mzanetti> nic-doffay: still not working?
[12:39] <nic-doffay> mzanetti, well I deleted it from the start.
[12:39] <mzanetti> nic-doffay: I'd need to see code then
[12:39] <nic-doffay> mzanetti, let me go with a fresh build quickly
[12:48] <tsdgeos> greyback: yep
[12:48] <tsdgeos> #ifdef QT_DEBUG
[12:48] <tsdgeos>     qFatal("QDBusArgument: read from a write-only object");
[12:48] <tsdgeos> #else
[12:48] <tsdgeos>     qWarning("QDBusArgument: read from a write-only object");
[12:48] <tsdgeos> #endif
[12:48] <greyback> tsdgeos: aha
[12:49] <tsdgeos> greyback: that's pretty common in qt
[12:49] <tsdgeos> the debug mode is more crashy
[12:49] <tsdgeos> so you fix your crap
[12:49] <greyback> tsdgeos: anyway, I'm just using the fake modules for now.
[12:49] <mzanetti> wouldn't it b easier to just use qWarning and when wanted export QT_FATAL_WARNINGS=1 ?
[12:49] <greyback> tsdgeos: the good news: unity8 kinda works
[12:49] <greyback> tsdgeos: the bad news: lots of things are broken
[12:49] <tsdgeos> like?
[12:49] <greyback> and I'm getting scenegraph renderer crashes
[12:50] <tsdgeos> not good
[12:50] <greyback> tsdgeos: I swipe the greeter away, it disappears immediately, I see "QTransform::translate with NaN called" errors
[12:50] <greyback> hopefully a math problem on our end
[12:51] <tsdgeos> yep
[12:52] <greyback> the indicators Tabs thing crashes when I click on it, giving the SG renderer error
[12:52] <greyback> nothing at all shows in Dash
[12:52] <greyback> possibly due to that math bug again
[12:53] <tsdgeos> greyback: so the thing is, when do we want to tackle those?
[12:53] <tsdgeos> you do it now? or? who and when?
[12:53] <greyback> tsdgeos: well I think the sooner Qt bugs are reported, the better
[12:53] <tsdgeos> we should do before 5.2 is officially out in case it's a qt bug it can try to get fixed before .0
[12:53] <tsdgeos> and that said
[12:53] <tsdgeos> it's lunch time
[12:53] <tsdgeos> :D
[12:53] <greyback> especially if it's in renderer
[12:53] <greyback> right
[12:53] <greyback> also JS engine
[12:54] <greyback> lots of changes, we need to make sure we find the bugs that effect us now
[12:55] <nic-doffay> mzanetti, here's the code. I assumed I'd gotten rid of everything qml related by just deleting the file... lp:~nicolas-doffay/+junk/search-history-model
[12:56] <fginther> mzanetti, ping
[12:56] <mzanetti> fginther: hi
[12:56] <mzanetti> fginther: so. seems the packages have landed
[12:57] <fginther> mzanetti, good, sounds like you needed some jenkins updates:
[12:57] <fginther> ?
[12:57] <mzanetti> fginther: but as it's notify-osd I think we'd need to upgrade the otto machines because it won't be pulled in
[12:57] <mzanetti> just with our tests
[12:58] <mzanetti> fginther: notify-osd 0.9.35+14.04.20131030.1-0ubuntu1 is the required one
[13:00] <fginther> mzanetti, the most recent tests are using 0.9.35+13.10.20130917.1-0ubuntu1. I should be able to get it the test runner to pull in the updated package.
[13:01] <mzanetti> fginther: I had the de.archive.ubuntu.com mirror today, that didn't show it either. I switched to the main mirror and it appeared
[13:02] <fginther> mzanetti, I'm running a test here: http://<IP_ADDRESS>:8080/job/autopilot-testrunner-otto-trusty/240/console - it found the right version
[13:02] <mzanetti> nic-doffay: Dash/ScopeView.qml
[13:02] <mzanetti> nic-doffay: property ListModel searchHistory
[13:03] <fginther> mzanetti, If it works, I'll just need to update the cu2d-config to update the parent -ci/-autolanding jobs
[13:03] <mzanetti> nic-doffay: make it a property QtObject searchHistory
[13:03] <mzanetti> fginther: cool. seems we're getting close :)
[13:04] <nic-doffay> mzanetti, ah cool nice one
[13:04] <mzanetti> nic-doffay: FYI: "ListModel" in QML is actually the "QQuickListModel"
[13:04] <mzanetti> nic-doffay: as they did qmlRegisterType<QQuickListModel>(uri, 2, 0, "ListModel")
[13:05] <mzanetti> nic-doffay: the error messages print the C++ type which makes it confusing if you don't know that :/
[13:05] <nic-doffay> mzanetti, yeah I figured as much now!
[13:06] <fginther> mzanetti, tests passed
[13:06] <mzanetti> nic-doffay: actually better: make it "property SearchHistoryModel searchHistory"
[13:06] <mzanetti> fginther: \o/
[13:06] <mzanetti> fginther: that was fast btw
[13:07] <fginther> mzanetti, now let's see if we can do the same starting with unity-ci
[13:07] <mzanetti> yep :)
[13:08] <nic-doffay> mzanetti, that's what I've done everywhere where Unity 0.1 was included.
[13:08] <mzanetti> cool. so it's working now?
[13:09] <fginther> mzanetti, http://<IP_ADDRESS>:8080/job/unity8-ci/1535/ == build of lp:unity8 with the addition of notify-osd
[13:09] <nic-doffay> mzanetti, well empty string are just being passed into the addQuery.
[13:09] <nic-doffay> I'm unsure why.
[13:10] <nic-doffay> Ah wait it worked :)
[13:10] <nic-doffay> When I change scopes I see the search is printed.
[13:10] <mzanetti> fginther: ok. monitoring :)
[13:10] <nic-doffay> mzanetti, is that desired behaviour?
[13:10] <nic-doffay> Is the query added when you change scopes?
[13:10] <nic-doffay> I'm a bit unsure about how it's supposed to function.
[13:10] <mzanetti> nic-doffay: I assume that unfocuses the textfield which calls addQuery
[13:18]  * greyback bbiab
[14:28] <Saviq> tsdgeos, mzanetti re: bug #1240408 - doesn't crash for you when expanding the music category in Home?
[14:28] <mzanetti> Saviq: nope
[14:28] <mzanetti> Saviq: neither on phone nor on desktop
[14:29] <tsdgeos> all fine
[14:29] <tsdgeos> argably i only have 1 green day album in there
[14:29] <Saviq> I'll try and trim down my music collection
[14:29] <mzanetti> I have some more...
[14:29] <Saviq> tsdgeos, mzanetti I have some polish music - so utf characters, maybe related
[14:30] <Saviq> will try and get you more info
[14:30] <mzanetti> mhm. makes sense
[14:31] <mzanetti> tsdgeos: nic-doffay: standup
[14:31] <tsdgeos> Saviq: mzanetti was saying it may be the exceptions throw in the album thing
[14:31] <tsdgeos> mzanetti: going
[14:31] <Saviq> tsdgeos, yeah, could be
[14:31] <mzanetti> tsdgeos: I checked a bit more... I think we're catching stuff
[14:32] <mzanetti> but well... if the lower layers throw stuff you never know
[14:32] <greyback> dandrader: you got disconnected
[14:34] <greyback> MacSlow: https://en.wikipedia.org/wiki/Public_holidays_in_Germany
[14:36] <MacSlow> greyback, true... http://www.schulferien.org/Feiertage/Feiertage_Berlin.html
[14:36] <greyback> MacSlow: yeah :(
[14:37] <nic-doffay> mzanetti, whoa was reading doccs
[14:38] <greyback> nic-doffay: we hear you
[14:38] <nic-doffay> greyback, I can't hear anything.
[14:38] <greyback> nic-doffay: :( try re-connecting once more?
[14:38] <nic-doffay> greyback, yeah done now
[14:39] <nic-doffay> this is annoying.
[14:45] <mzanetti> tsdgeos: http://<IP_ADDRESS>:8080/job/unity8-ci/1535/
[14:45] <mzanetti> tsdgeos: this one needs to go green
[14:45] <mzanetti> so far it looks good: http://<IP_ADDRESS>:8080/job/unity8-ci/1535/console
[14:46] <tsdgeos> 1 hr 37 min?¿
[14:46] <tsdgeos> wasn't it a bit faster before?
[14:46] <tsdgeos> or that accounts for some time in which there were no free machines?
[14:46] <mzanetti> hmm... good point
[14:46] <tsdgeos> like
[14:46] <tsdgeos> http://<IP_ADDRESS>:8080/job/generic-mediumtests-runner-maguro/
[14:47] <mzanetti> yeah... I think that's it
[14:47] <mzanetti> because if a single job takes more than 60 mins it'll be killed
[14:47] <mzanetti> so everything above must be queue time
[14:49] <nic-doffay> mzanetti, would the best approach for this be to reset the StringList on the model each time a query is added? I can't really see a better of doing it right now.
[14:50] <mzanetti> nic-doffay: what exactly is the issue?
[14:54] <tsdgeos> mzanetti: there's no append to QStringListMode
[14:54] <tsdgeos> l
[14:54] <nic-doffay> mzanetti, ^
[14:55] <mzanetti> tsdgeos: well there must be something, no?
[14:55] <tsdgeos> mzanetti: not sure tbh
[14:55] <tsdgeos> let me check the code :D
[14:56] <mzanetti> tsdgeos: stringList() and setStringList()
[14:56] <nic-doffay> mzanetti, yeah that's all.
[14:56] <mzanetti> nic-doffay: setStringList(stringList() << newItem);
[14:57] <tsdgeos> nic-doffay: well you can call insertRows
[14:57] <tsdgeos> and then setData
[14:57] <mzanetti> tsdgeos: then you'd need also setdata
[14:57] <mzanetti> yeah... sucks
[14:57] <tsdgeos> sure :D
[14:57] <tsdgeos> it's how it is
[14:57] <nic-doffay> mzanetti, so that's how it is then.
[14:57] <tsdgeos> either that or you do your own model
[14:57] <mzanetti> is there a problem I don't see with this? setStringList(stringList() << newItem);
[14:58] <nic-doffay> mzanetti, there's not a problem. I just expected the class to have it's own append function is all.
[14:58] <tsdgeos> calls beginResetModel
[14:58] <tsdgeos> which may not be the most efficient thing ever
[14:58] <mzanetti> nic-doffay: yeah. the QStringListModel sucks a bit tbh
[14:59] <tsdgeos> who is consuming this?
[14:59] <mzanetti> nic-doffay: you could however, use QAbstractListModel.
[14:59] <tsdgeos> QuickRepeater?
[14:59] <tsdgeos> or?
[14:59] <mzanetti> tsdgeos: I think yeah. could also be a ListView tho
[14:59] <mzanetti> tsdgeos: if it has model in the name I'd prefer to correctly emit signals
[14:59] <nic-doffay> mzanetti, well in another case I'd say lets go for something else but this isn't called an awful lot.
[15:00] <tsdgeos> that's true
[15:00] <mzanetti> nic-doffay: you could take it as a learning opportunity tho
[15:00] <tsdgeos> no need to optimize
[15:00] <tsdgeos> but yeah let's do a simple qabstractlistmodel yourself
[15:00] <tsdgeos> and learn a bit about it
[15:00] <mzanetti> nic-doffay: QAbstractListModel is the most used class in Qt since QML arised
[15:00] <mzanetti> so knowing that one wouldn't hurt ;)
[15:01] <nic-doffay> tsdgeos, mzanetti you're right.
[15:01] <tsdgeos> you can get inspired by the code of QStringListModel and add the missing functionality
[15:02] <mzanetti> nic-doffay: also check out plugins/Unity/Launcher/quicklistmodel. that's roughly the same. a super simple QAbstractListModel
[15:03] <nic-doffay> mzanetti, cool will do.
[15:15] <mzanetti> tsdgeos: I added some tests here: https://code.launchpad.net/~unity-team/unity8/switching-previews/+merge/189556
[15:15] <mzanetti> tsdgeos: mind checking them and reapproving?
[15:15] <tsdgeos> on it
[15:20] <tsdgeos> mzanetti:  /// exposes the distance to the next row (only one row in carousel, so it's the topMargins
[15:20] <tsdgeos> missing ) somewhere
[15:21] <mzanetti> tsdgeos: ack, will fix
[15:21] <mzanetti> fginther: any idea whats happening here? http://<IP_ADDRESS>:8080/job/generic-mediumtests-runner-maguro/
[15:21] <tsdgeos> mzanetti: print("should map preview", rendererName);
[15:22] <fginther> mzanetti, all the maguros are stuck after flashing, someone has been asked to get them back online
[15:23] <mzanetti> tsdgeos: both fixed
[15:24] <tsdgeos> mzanetti: is it bzr being stupid here http://bazaar.launchpad.net/~unity-team/unity8/switching-previews/revision/483 ?
[15:24] <mzanetti> tsdgeos: no, it's me being stupid
[15:24] <tsdgeos> i mean r483 doesn't have all taht code, no?
[15:24] <tsdgeos> or?
[15:25] <mzanetti> tsdgeos: I started with a clean unity8 branch to enable the preview mocks
[15:25] <tsdgeos> ah
[15:25] <mzanetti> tsdgeos: then I figured that the switching previews had a failed test from a bad merge
[15:25] <mzanetti> tsdgeos: then I thought, ok, lets fix that one too
[15:25] <mzanetti> tsdgeos: merged everything in there and continued to work without committing
[15:25] <mzanetti> and at the end committed everything
[15:25] <mzanetti> :/
[15:29] <fginther> mzanetti, the devices are up again, jobs are running
[15:29] <mzanetti> cool, thanks
[15:32] <Saviq> mzanetti, fginther the fix for #1240408 should hopefully help our mako mediumtests
[15:32] <Saviq> fginther, could we update notify-osd on the trusty mediumtests, though?
[15:33] <fginther> Saviq, it was added for unity8 jobs, does it need to be added for everything?
[15:34] <Saviq> fginther, no, u8 is enough
[15:35] <Saviq> fginther, but at least http://<IP_ADDRESS>:8080/job/autopilot-testrunner-otto-trusty/236/ still suffered from old notify-osd
[15:35] <Saviq> ah, but http://<IP_ADDRESS>:8080/job/generic-mediumtests-trusty/254/ was fine
[15:35] <Saviq> cool
[15:35] <fginther> Saviq, http://<IP_ADDRESS>:8080/job/generic-mediumtests-trusty/250/ has the update
[15:35] <Saviq> fginther, yup, thanks
[15:42] <mzanetti> failure
[15:43] <mzanetti> http://nooooooooooooooo.com/
[15:45]  * dandrader hears a loud scream
[15:45] <dandrader> what, no autolanding yet?
[15:45] <mzanetti> Saviq: the fix for 1240408 ?
[15:45] <mzanetti> you sure about that?
[15:46] <mzanetti> there is one HUD test failing
[15:46] <mzanetti> on the phone
[15:46] <tsdgeos> autopilot?qml?
[15:46] <Saviq> mzanetti, it's random
[15:46] <Saviq> mzanetti, crash on startup
[15:46] <Cimi> mzanetti, we need the nooooooooo button on ubuntu touch
[15:46] <mzanetti> tsdgeos: AP
[15:46] <mzanetti> Cimi: yeah, thought the same
[15:46] <Saviq> mzanetti, if ap log says "could not find PID blah" or similar
[15:47] <mzanetti> Saviq: yep, that's it
[15:47] <Saviq> mzanetti, it usually means unity8 crashed on startup
[15:47] <mzanetti> so I guess we can fginther to reenable autolanding nevertheless?
[15:47] <Saviq> mzanetti, fginther let's not open the floodgates
[15:47] <mzanetti> huh?
[15:47] <Saviq> mzanetti, fginther can we enable the job but make it manual for now?
[15:48] <mzanetti> ah... yeah. makes sense
[15:48] <Saviq> mzanetti, without https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426 we'll be failing anyway
[15:48] <Cimi> mzanetti, we could add noooooo when an autopilot test fails
[15:48] <Cimi> mzanetti, that would be quite fun
[15:48] <fginther> Saviq, mzanetti, yes, I'll let you know when it's ready
[15:59] <greyback> mzanetti: got a sec?
[15:59] <mzanetti> greyback: sure
[15:59] <greyback> mzanetti: I want to understand exactly how we swipe away the greeter
[15:59] <greyback> mzanetti: in Greeter.qml, there's a DragHandle
[16:00] <mzanetti> greyback: yep
[16:00] <greyback> that DragHandle is the thing listening for mouse events to start a drag, yeah?
[16:00] <greyback> what I don't see is where DragHandle sets the x of the Greeter
[16:00] <mzanetti> greyback: one sec
[16:00] <mzanetti> greyback: what's the background for this?
[16:00] <greyback> mzanetti: the x is being set to NaN in Qty5.2
[16:00] <mzanetti> ah, ok
[16:01] <mzanetti> greyback: open Components/DragHandle.qml and check out the example
[16:02] <mzanetti> greyback: basically, DragHandle operates on it's parent if that's a Showable
[16:03] <greyback> mzanetti: aha, now I see it
[16:03] <greyback>                     step = hintingAnimation.targetValue - dragParent[targetProp];
[16:04] <greyback> mzanetti: thanks!
[16:04] <mzanetti> greyback: np
[16:25] <greyback> Hey folks, it's time for another round of "Know your EMCAScript" !!!
[16:26] <greyback> What should this print when I click: http://pastebin.ubuntu.com/6336469/
[16:28] <mzanetti> greyback: "Hi Gerry! You are Hi Gerry!" is what I would assume
[16:28] <mzanetti> greyback: but I wouldn't wonder if it says "Hi Gerry!  In 5.2 however I get, "Hi undefined! you are undefined!"
[16:29]  * mzanetti sees ubuntu core apps falling apart
[16:29] <greyback> we do something similar in DragHandle.qml, limitMovement(step) - causing 1 bug
[16:30] <nic-doffay> greyback, what changed?
[16:30] <mzanetti> greyback: undefined sounds weird tho
[16:30] <mzanetti> greyback: why is that?
[16:30] <greyback> nic-doffay: in Qt5.2, there's a completely new javascript interpretation engine
[16:31] <greyback> so bugs like this could exist
[16:31] <greyback> mzanetti: I dunno, smells like bug to me
[16:32] <mzanetti> greyback: is it the QtObject? try using an Item instead
[16:32] <mzanetti> hmm... no... doesn't make sense either
[16:32] <greyback> mzanetti: same with Item
[16:33] <mzanetti> greyback: however I read it, it doesn't make sense to me
[16:34] <greyback> mzanetti: yep, I think it's 5.2 bug
[16:45] <mzanetti> greyback: somehow I find it hard to believe that there's a bug like this and it only breaks the DragHandle
[16:45] <mzanetti> this feels like *everything* would fall apart
[16:51] <greyback> mzanetti: well, that's the first fix I've made :) And it's kinda bad to overwrite something set in a function argument, so I'd say we unconsciously avoid doing it
[16:56] <mzanetti> greyback: apart form that. any noticeable impact on performance?
[16:58] <greyback> mzanetti: hard to say, I'm running on my laptop. I'd need to gather numbers
[17:01] <Cimi> greyback, isn't 5.2 running faster?
[17:01] <mzanetti> Cimi: well, it's supposed to make property bindings like 4 times faster
[17:01] <greyback> Cimi: it should be. Just hard to tell by eye
[17:01] <mzanetti> Cimi: but in turn slow down imperative javascript quite a bit
[17:02] <mzanetti> which I think would improve situations on state changes and animations
[17:02] <greyback> and there are optimisations introduced by 5.2 which would helps some animations, the "*Animator" classes
[17:03] <greyback> will have to be used with care tho
[17:04] <Cimi> greyback, and new scene graph?
[17:05] <greyback> Cimi: yep, it will improve perf for various situations. Things like lists and grids will be faster
[17:05] <Cimi> greyback, btw we have plenty of time tomorrow to chat while the rest of our colleagues are on holiday -.-
[17:05] <greyback> Cimi: how true :)
[17:05] <mzanetti> muahaha
[17:05] <Saviq> fginther, can you have a look at http://<IP_ADDRESS>:8080/job/generic-mediumtests-runner-mako/2921/console
[17:06] <Saviq> yikes that's flaky :/
[17:14] <Cimi> mzanetti, the launcher bus is an asset
[17:14] <mzanetti> huh?
[17:14] <mzanetti> bus?
[17:14] <Cimi> hah
[17:14] <Cimi> bug
[17:14] <mzanetti> haha
[17:14] <mzanetti> ok
[17:15] <mzanetti> really
[17:15] <mzanetti> good catch then
[17:15] <Cimi> mzanetti, you men the weird effect at the bottom?
[17:15] <mzanetti> yeah
[17:15] <mzanetti> in the bottom corners mostly
[17:15] <Cimi> graphics/non-selected.sci
[17:15] <Cimi> I thought was it
[17:15] <greyback> mzanetti: question, what is "gridView.delegateCreation{Begin,End}" in ResponsiveGridView?
[17:16] <ali1234> tedg: what is up with the libdbusmenu tests? they take 20 minutes to run and seem to fail randomly
[17:16] <greyback> are they undocumented properties on a GridView?
[17:16] <mzanetti> greyback: that's albert's solution for the fact that we don't want to have the whole delegate created
[17:16] <mzanetti> greyback: i.e: you have the "recommended apps"
[17:16] <mzanetti> greyback: which is 5km long
[17:17] <greyback> mzanetti: ah yes, that thing
[17:17] <mzanetti> and this creationRange tells the containing gridview which delegates it needs to keep created
[17:17] <greyback> oh, we've a distro patch for it...
[17:17] <Saviq> GREEEEEN
[17:17] <Saviq> http://s-jenkins:8080/job/unity8-ci/
[17:17] <greyback> \o/
[17:18] <Saviq> https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426 please
[17:18] <mzanetti> http://www.hiyoooo.com/
[17:19] <mzanetti> Saviq: approved
[17:20] <Saviq> fginther, please ping when we can push that ↑
[17:23] <mzanetti> dafuq.. some halloween kids just were at the door. first time I see that in D
[17:27] <Cimi> mzanetti, I'd scare them :D
[17:27] <Cimi> mzanetti, show them a jenkins log!
[17:31] <mzanetti> lol
[17:35] <Saviq> Cimi, we've green logs now, so that's not gonna help ;)
[17:47] <fginther> Saviq, jenkins is ready, want me to trigger that build?
[17:47] <Saviq> fginther, I'll do
[17:47] <Saviq> fginther, I'll be going through our queue now
[17:48] <fginther> Saviq, ack, let me know when you're ready to enable automated merging again
[17:48] <Saviq> fginther, anything I should make sure of when triggering it? like putting notify-osd in the test_packages prop or something?
[17:48] <fginther> Saviq, the job configs are already set to use notify-osd. You just need to specify the merge_proposal, landing_candidate and candidate_revision
[17:49] <fginther> I see a green light on the last unity8-ci job. awesome
[17:52] <Saviq> fginther, local_archive_pocket? is it used at all?
[17:53] <Saviq> fginther, that looks sane http://s-jenkins:8080/job/unity8-autolanding/615/parameters/? ?
[17:54] <fginther> Saviq, looks good.
[17:55] <fginther> Saviq, the local_arhive* parameters are used, they don't need to be modified
[18:00] <nic-doffay> mzanetti, you there?
[18:15] <om26er> mzanetti, hey! do you think an autopilot test for this will be enough? https://code.launchpad.net/~om26er/unity8/close_preview_on_search/+merge/193467
[18:18] <thomi> om26er: it needs *at least* an autopilot test :)
[18:19] <om26er> thomi, right, I asked that in the description.
[18:19] <thomi> om26er: you asked it here as well :)
[18:20] <om26er> thomi, wow. i am distracted
[18:22] <om26er> thomi, can we  inquire from autopilot if the OSK is visible on screen ?
[18:22] <om26er> considering autopilot is typing with the maliit backend
[18:23] <thomi> om26er: yes, you can - but veebers is the person to ask about that
[18:23] <om26er> thomi, ok
[18:34] <ali1234> tedg: i am having difficulty building libdbusmenu because the tests fail, or simply hang forever
[18:51] <ali1234> (process:27013): LIBDBUSMENU-GLIB-WARNING **: Unable to get session bus: Error sending credentials: Error sending message: Operation not permitted
[18:52] <davmor2> who knew 900 app installs would cripple unity \o/
[18:52] <Mirv> Saviq: https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426 jenkins just failed again
[18:53] <greyback> davmor2: well done :)
[18:53] <davmor2> greyback: I think the application search times the dash out
[18:55] <greyback> davmor2: possible, yes. I didn't know we had 900 apps - they're not all click are they?
[18:55] <thomi> Hi guys - I wonder if someone could take a look at this? https://bugs.launchpad.net/unity8/+bug/1246574
[18:56] <thomi> this is a pretty critical bug for the QA team, since it's blocking AP 1.4 landing. We don't need it fixed, but it'd be good to have someone from the unity team at least look at it and comment on the bug
[18:56] <thomi> Saviq: ^^
[18:56] <davmor2> greyback: no this is the commercial apps for the desktop
[18:57] <greyback> davmor2: ahhh. Not good at all then
[18:57] <davmor2> greyback: I'm just getting to the end of the app migrations from raring to Saucy
[18:58] <davmor2> greyback: I don't know anybody who would install them all to be honest :)
[19:01] <greyback> thomi: it possible https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426 fixes that.
[19:04] <davmor2> greyback: ha interesting so it looks like it is only the initial opening of the dash where is says there is nothing to find and search finds nothing.  If you close it for a few seconds and then  reopen all the data is back phew :)
[19:16] <thomi> greyback: thanks
[19:30] <Mirv> Saviq: meanwhile on the desktop side, I'm getting the AP errors still. commented on the bug #1244549
[21:31] <Saviq> Mirv, see you published now? you need to upgrade notify-osd / unity-notifications in cu2d
[21:33] <Mirv> Saviq: you mean on the machines? the yesterday's update is in on those
[21:34] <Saviq> Mirv, got artifacts?
[21:35] <Mirv> Saviq: http://<IP_ADDRESS>:8080/job/autopilot-trusty-daily_release/305/label=qa-intel-4000/#showFailuresLink - note that I installed the notify-osd there inside lxc-container and stop/started the container, but I'm not 100% sure if that's all that's needed
[21:35] <Saviq> Mirv, http://<IP_ADDRESS>:8080/job/autopilot-trusty-daily_release/305/label=qa-intel-4000/artifact/results/autopilot/videos/unity8.shell.tests.test_notifications.EphemeralNotificationsTests.test_append_hint%20%28Desktop%20Nexus%204%29.ogv
[21:35] <Saviq> Mirv, notify-osd was running
[21:36] <Saviq> Mirv, means either notify-osd or unity-notifications weren't upgraded
[21:36] <Mirv> Saviq: notify-osd I updated manually, and unity-notifications gets installed during the test start (in the log)
[21:37] <Saviq> Mirv, not sure what I can say :/ it's working fine in mediumtests
[21:37] <Mirv> Saviq: but as said, I'm not the container expert so I'm not sure if I understand all the details needed
[21:37] <Saviq> Mirv, and we were getting the same failures before
[21:37] <Mirv> Saviq: we may also wait for the next daily container recreation
[21:37] <Saviq> Mirv, ok
[21:40] <Mirv> Saviq: any how unity8 with the setenv change now published
[21:40] <Saviq> Mirv, yup, saw that, thanks
[21:40] <Saviq> Mirv, merging the changelog now
[21:41] <Saviq> Mirv, not sure what happened here though https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426
[21:41] <Saviq> Mirv, did you merge manually?
[21:41] <Mirv> Saviq: no, as you see it got approved eventually
[21:42] <Saviq> Mirv, ah right, autolanding doesn't report completely when it merges
[21:42] <Mirv> Saviq: or hmm no real message, maybe it was plar_s doing magic when I asked him to tinker it and then he reported that it ran ok
[21:42] <Saviq> aaanyway
[21:42] <Saviq> it got in ;)
[21:42] <Saviq> and we need to fix flaky tests :)
[21:43] <Mirv> Saviq: so we have a real good chance of successful dashboard unity AP:s now? (minus possible flaky ones)
[21:43] <Mirv> I got all pass myself locally
[21:52] <Saviq> Mirv, on the phone it should be just fine again
[21:56] <Mirv> let's hope so. not sure who will kick the #10 image build
[23:11] <kgunn> Saviq: its been a while...what's the way to superuser on phablet?  su -u phablet -i ?
[23:12] <popey> kgunn: sudo -u phablet -i
[23:12] <kgunn> popey: ta