| === fenris is now known as Guest99083 | ||
| === Guest99083 is now known as ejat | ||
| === fenris is now known as Guest72215 | ||
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| davidcalle | didrocks, lp:unity-lens-videos is now lp:unity-lens-video, the change has just been applied on the whole project | 09:43 |
|---|---|---|
| Mirv | davidcalle: cool, finally no mismatch between the names! :) | 09:44 |
| didrocks | davidcalle: \o/ thanks a lot :) | 09:47 |
| mhr3 | didrocks, why wasn't the pkg renamed instead? it's not like the lens searched for a single video :P | 10:36 |
| didrocks | mhr3: I agree, but renaming a source package is way more complex | 10:37 |
| === mmrazik is now known as mmrazik|lunch | ||
| === _salem is now known as salem_ | ||
| conscioususer | mpt: hi, you around | 12:17 |
| conscioususer | mpt: I'd like your advice wrt to my "add acount" wizard | 12:17 |
| mpt | conscioususer, always | 12:17 |
| conscioususer | mpt: :) | 12:18 |
| conscioususer | mpt: the first time the user starts an app and receives the wizard, I was wondering what to do when he cancels the wizard | 12:18 |
| conscioususer | whether to quit the app or proceed to the main window anyway | 12:19 |
| conscioususer | mpt: I considered not popping the wizard directly, but showing a welcome message on the main window with a button to open it | 12:21 |
| mpt | conscioususer, I would exit it. | 12:21 |
| mpt | conscioususer, I briefly wrote up a first-run assistant for Empathy, though it was never implemented. <https://live.gnome.org/Empathy/WelcomeToEmpathy> | 12:21 |
| conscioususer | mpt: that makes sense for me too, but iirc I never found an app that does that | 12:22 |
| mpt | conscioususer, Adium and Apple Mail both do that iirc | 12:22 |
| conscioususer | mpt: would I close it directly or show a confirmation dialog? | 12:23 |
| conscioususer | mpt: (a dialog that obviously wouldn't be shown in subsequent usage of the wizard) | 12:23 |
| mpt | conscioususer, it depends how much state would be lost. And that doesn't change regardless of whether it's the first time you're using it or a subsequent time. | 12:24 |
| mpt | i.e. how much stuff you've entered that would be discarded | 12:24 |
| mpt | For a Twitter account at least, there's very little state, so probably not | 12:24 |
| conscioususer | mpt: no important loss at all, actually, I was worried if it would be clear enough that the app exited, as other popular apps wouldn't | 12:25 |
| mpt | conscioususer, other popular apps such as? | 12:25 |
| conscioususer | mpt: empathy now, iirc | 12:26 |
| mpt | pfft | 12:26 |
| conscioususer | mpt: also, thunderbird | 12:26 |
| mpt | conscioususer, I think that's only because there's a non-assistant way of adding a Thunderbird account | 12:26 |
| mpt | which some people prefer | 12:26 |
| conscioususer | mpt: hmm | 12:27 |
| conscioususer | mpt: so in my case, cancel would simply close the window and that's it? | 12:27 |
| mpt | I think so | 12:27 |
| conscioususer | mpt: ok, since you are advising what my opinion was leaning towards to already, it's an easy call :) | 12:29 |
| conscioususer | mpt: sounds easy enough to implement too | 12:29 |
| mpt | :) | 12:29 |
| conscioususer | mpt: thanks | 12:29 |
| === mmrazik|lunch is now known as mmrazik | ||
| === dandrader is now known as dandrader|afk | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| didrocks | Mirv: sil2100: can you please have a look at https://code.launchpad.net/~didrocks/bamf/dailybootstrap/+merge/134297? | 14:19 |
| didrocks | shouldn't be long to approve/review :p | 14:19 |
| popey | didrocks, blimey, even _I_ could approve that ;) | 14:27 |
| didrocks | popey: be my guest! :) | 14:31 |
| popey | odd, i couldn't type a + sign in the comment field! | 14:32 |
| popey | i had to copy and paste one in. | 14:33 |
| Laney | should I make packaging and code changes in the same commit? | 14:33 |
| Laney | (unity-lens-music) | 14:33 |
| didrocks | Laney: well, can be two commits, but one merge request | 14:34 |
| didrocks | it's a matter of taste I guess | 14:34 |
| Laney | it will be one MP, yes | 14:34 |
| Laney | I don't really get the convention about what's documented in d/changelog either | 14:34 |
| didrocks | Laney: all things that have a bug attached + packaging change | 14:35 |
| Laney | like there's an unreleased ubuntu2 there now | 14:35 |
| Laney | but I'm making upstream changes so surely they would only go in a new upstream release | 14:35 |
| didrocks | Laney: what do you try to do exactly? | 14:36 |
| Laney | gstreamer 1 port | 14:36 |
| didrocks | Laney: do you need to upload it right away? can it wait like a few days? | 14:36 |
| didrocks | Laney: if so, you can just merge that upstream | 14:36 |
| Laney | yeah I expect it to wait | 14:37 |
| didrocks | Laney: ok, so don't update debian/changelog if you don't have packaging change | 14:37 |
| didrocks | Laney: just make the upstream change | 14:37 |
| didrocks | if you link to a bug report, the changelog will be populated automatically | 14:37 |
| Laney | I need to change the build-deps though | 14:37 |
| didrocks | with your name :) | 14:37 |
| Laney | not sure if there is a bug | 14:37 |
| didrocks | ah, yeah, list the build-dep change then :) | 14:37 |
| Laney | ok, cool | 14:38 |
| Laney | thanks | 14:38 |
| didrocks | yw :) | 14:38 |
| Laney | is there a PPA I can depend on to test build? | 14:44 |
| Laney | the requirements have been bumped to beyond what's in raring apparently | 14:44 |
| didrocks | Laney: oh yes, it's in unity-team/staging | 14:45 |
| didrocks | for nux 4 :) | 14:45 |
| Laney | check | 14:45 |
| didrocks | popey: to exercise your "+" key: https://code.launchpad.net/~didrocks/dee/dailybootstrap/+merge/134299 :) | 14:52 |
| popey | hah | 14:54 |
| popey | pfft, works now! | 14:55 |
| mterry | didrocks, hello! | 14:55 |
| popey | maybe i should use a french keyboard layout :) | 14:55 |
| didrocks | hey mterry! | 14:55 |
| didrocks | popey: heh, I'm sure it's the cause | 14:55 |
| mterry | didrocks, so for -c4, I have a bamf branch, but I had wanted to talk to you first about it. | 14:56 |
| didrocks | mterry: ah? | 14:56 |
| mterry | didrocks, so when you do need to add a new symbol to the .symbol file (as bamf needs to), you need to provide a version | 14:56 |
| didrocks | yep | 14:56 |
| mterry | didrocks, for my branch, I just bumped the version in debian/changelog to what I imagine the next upstream version will be and used that in the .symbols file | 14:57 |
| mterry | didrocks, how will that work for autolanding? How does a person know what the next version will be? | 14:57 |
| didrocks | mterry: basically, I propose that we do: | 14:57 |
| didrocks | <currentupstreamversion>dailyyy.mm.(dd+1) | 14:58 |
| didrocks | as it will be released at the earliest the day after | 14:58 |
| didrocks | mterry: does it make sense? | 14:59 |
| mterry | It's tough though because it may be incorrect (may take longer to land). But I suppose that will just mean it will be slightly unnecessarily tight. Which isn't a problem per se | 14:59 |
| mterry | Or wait. No, it will mean it thinks a version that doesn't have the symbol will satisfy | 14:59 |
| mterry | Which isn't true | 14:59 |
| didrocks | mterry: right, it may be incorrect, but in this case, there will be no release between <currentupstreamversion>dailyyy.mm.dd and <currentupstreamversion>dailyyy.mm.(dd+correct_day) | 15:00 |
| mterry | It will be loose | 15:00 |
| didrocks | counting on the fact it's merged the day you propose it | 15:00 |
| mterry | didrocks, you don't think I could propose merge A, then someone else lands merge B, then it takes several days to land my A? | 15:00 |
| didrocks | mterry: yeah, that's a valid point | 15:01 |
| didrocks | mterry: TBH, as we ship only one version on the distro, it's not a real issue, people upgrade | 15:01 |
| didrocks | but we can write guidance for this case | 15:01 |
| didrocks | like when reviewing a symbol change, ensuring dd is the correct day | 15:01 |
| mterry | didrocks, we could do something like adding a version like 0.4.3-0ubuntu0replacemeplease and have the autolander fix it up? | 15:02 |
| didrocks | mterry: that's another solution, totally possible | 15:02 |
| didrocks | fginther: thoughts? ^ | 15:02 |
| didrocks | mterry: like the autolander making a diff | 15:02 |
| didrocks | and if there is a + in symbol files | 15:03 |
| didrocks | replacing with the current day + 1 | 15:03 |
| mterry | yar sure | 15:03 |
| didrocks | mmrazik: can you invite my @gmail to the hangout? I need to use my android device for it | 15:04 |
| didrocks | as it's broken on raring right now | 15:04 |
| mmrazik | didrocks: ok | 15:04 |
| didrocks | thanks :) | 15:04 |
| mmrazik | didrocks: can you private msg your private gmail address? | 15:04 |
| didrocks | done ;) | 15:05 |
| didrocks | mterry: oh, on bootstrapping, did you see my bamf/dee/libunity branches? | 15:05 |
| mterry | didrocks, yeah. You want me to approve them? They seem pretty innocuous. That's part of getting the autolanding changelog writing to work? | 15:06 |
| mterry | didrocks, just filed bamf c4 merge | 15:07 |
| didrocks | mterry: be back after the hangout and will explain it in great length | 15:09 |
| Squarism | Isnt there a setting in 12.04 where ALT+TAB -> Desktop doenst minimize all windows on all screens? | 15:10 |
| Trevinho | didrocks, mterry I think these could clash lp:~mterry/bamf/c4 lp:~didrocks/bamf/dailybootstrap | 15:23 |
| mterry | Oh, probably. I can rebase mine on top of didrocks's | 15:23 |
| Trevinho | mterry: yes, thanks... so I'll do with mine too | 15:24 |
| Trevinho | (I'm bumping the whoule bamf to 0.4 for r) | 15:24 |
| Trevinho | mterry: ping me once you've done please | 15:25 |
| mterry | Trevinho, done. I guess you can change my 0.3.5 changes to 0.4, since 0.3.5 was never released | 15:26 |
| didrocks | mterry: so… | 15:38 |
| didrocks | mterry: that would be good if you can approve them. yeah, it's about bootstrapping with the "rev" after which looking for bugs to collect | 15:38 |
| didrocks | mterry: so, I set it just after your "inline packaging merge" and have to manually list those before there are not in raring (like in libunity) | 15:39 |
| mterry | didrocks, ah so from now on, no more manual changelog entries? | 15:39 |
| didrocks | mterry: apart for packaging change | 15:39 |
| didrocks | well, it can be automated if you have a bug linked :) | 15:39 |
| mterry | didrocks, it's only automatic if a bug is linked? OK. Otherwise a branch without a bug should add a changelog entry? | 15:40 |
| mterry | (isn't there a commit message we could use in such cases?) | 15:40 |
| didrocks | mterry: should or not, I don't think we want to get all commit messages in | 15:40 |
| didrocks | we can in the future, it's not a big change to what we have today ;) | 15:41 |
| mterry | sure | 15:41 |
| Trevinho | didrocks: as I told you some time ago, I'd like to get rid of the libbamf-0/libbamf-3 thing... The only project depending on libbamf0 (ginn) is already using libbamf3 in trunk, so I'm in the process of removing the gtk2 dependencies in the bamf code. | 15:43 |
| didrocks | mterry: do you want me to help doing some others? I think the bootstrapping is quite quick to do, maybe for all but compiz and unity which will take some time | 15:43 |
| didrocks | Trevinho: ok, please update the packaging or ask us if you need help for it :) | 15:44 |
| didrocks | like mterry or I | 15:44 |
| Trevinho | didrocks: however the strange thing is that both libbamf3 and libbamf0 never have been different on dependency.. I mean, both have always been gtk-free from dependency point of view... | 15:44 |
| Trevinho | so I never saw the point of having this difference | 15:45 |
| Trevinho | (only the daemon can be built using gtk2 or gtk3, but in the archives we only have the gtk3 daemon) | 15:45 |
| didrocks | Trevinho: hum, I don't remember per say, maybe there had been a gtk dep and it's been removed | 15:45 |
| Trevinho | didrocks: yes, sure.. but I've some packaging background I hope it's still enough :) | 15:45 |
| Trevinho | didrocks: mh, I don't know... I never saw them, but probably there was... | 15:46 |
| didrocks | Trevinho: we'll review anyway :) | 15:46 |
| Trevinho | didrocks: however... It would be also nice to change the packaging name, even if I think that this could lead to a lot more troubles | 15:46 |
| didrocks | Trevinho: it does, why do you want to rename it? | 15:46 |
| Trevinho | well... I don't see the point of having a library called libbamf3 when the "3" is really irrelevant as it is not related to the gtk version | 15:47 |
| Trevinho | but... I know it's just a thing it's better to keep | 15:47 |
| mterry | didrocks, (got back from afk) OK, you want me to go through and bootstrap the non-compiz/unity ones? | 15:48 |
| didrocks | mterry: do you have time for it? (I didn't ask to not do the compiz/unity, just saying it's the longer one, the others should be quick) | 15:48 |
| didrocks | I can take some if needed | 15:48 |
| mterry | didrocks, I can add them to the list, sure | 15:49 |
| didrocks | mterry: ok, thanks :) | 15:50 |
| didrocks | mterry: so the rev to list is the rev where you merged the packages in, to be clear | 15:50 |
| didrocks | and then, we need to look for bugs that were not fixed in distro already until the previous release | 15:50 |
| mterry | didrocks, the inline branches? OK | 15:50 |
| mterry | didrocks, just things with bugs attached, eh? | 15:50 |
| didrocks | yep :) | 15:50 |
| didrocks | mterry: my plan was first to list just the rev of the previous release | 15:51 |
| didrocks | mterry: but as you merged the packaging branch in the trunk, it was listing every bugs since the beginning :) | 15:51 |
| fginther | didrocks, mterry, regarding having the autolander fix up the symbol revisions... It should work | 15:53 |
| fginther | would it just add the current package version as the replacement: 0.4.3-0ubuntu0replacemeplease -> 0.4.3bzr498pkg0quantal18? | 15:55 |
| didrocks | fginther: mterry: I'm wondering if finally, it shouldn't just be the "daily release" doing it? | 15:57 |
| didrocks | like my script, as we know the day of the release, it will make more sense | 15:58 |
| mterry | didrocks, that could work too | 15:58 |
| didrocks | fginther: don't bother, I'm adding that | 16:00 |
| didrocks | mterry: now, let's see if we can just add "replaceme" :) | 16:00 |
| mterry | didrocks, you forgot the 'please' ;) | 16:01 |
| mterry | so rude | 16:01 |
| didrocks | mterry: heh, ok, adding in the spec :p | 16:01 |
| mterry | hah | 16:02 |
| mterry | Reminds me of how the Debian bts uses 'thanks' as a stop-marker for commands to the bot | 16:02 |
| didrocks | it likes the please! :) | 16:05 |
| didrocks | so I can definitively do that | 16:05 |
| didrocks | fginther: so merge proposal with only changelog and symbols should get the pass-through I guess :p | 16:06 |
| fginther | didrocks, wouldn't you want a new package built if the symbols were updated? | 16:09 |
| didrocks | fginther: it's only for listing the dep. They won't be exact *in the ppa*, but I think people are using dist-upgrade | 16:10 |
| Trevinho | didrocks: https://code.launchpad.net/~3v1n0/bamf/bump-to-0.4/+merge/134322 | 16:10 |
| fginther | didrocks, ok | 16:11 |
| Trevinho | mterry: thanks for review, fixed... | 16:18 |
| cariveri | hey there. Im new to the unity src code and could use a little help. | 16:24 |
| cariveri | anesm | 16:24 |
| cariveri | Trevinho: excuse me, who should I ask about the Launcher's code? - the data model is not quit clear ot me. | 16:27 |
| bregma | cariveri, just go ahead and ask questions, there's a few folks who can probably answer | 16:31 |
| didrocks | alesage: hey, any progress on merging https://code.launchpad.net/~mathieu-tl/indicator-messages/inline/+merge/134100? | 16:35 |
| alesage | didrocks, I think you're suggesting that I run a red light :) | 16:36 |
| didrocks | alesage: red light? | 16:36 |
| didrocks | which one? | 16:36 |
| alesage | didrocks, I don't wish to stir up controversy but have we decided, after all, for inline packaging for indicators? | 16:37 |
| === dandrader|afk is now known as dandrader | ||
| didrocks | alesage: no, the stackholders of the indicators stack (larsu and charles) agrees with inline packaging | 16:37 |
| didrocks | we decided from the meeting that the stackholders decide, the other won't have automated daily push to ubuntu and will deal with that themselves | 16:38 |
| larsu | alesage, I can vouch for the correctness of what didrocks says ;) | 16:38 |
| alesage | didrocks in that case, is it possible to clean up this MP, e.g. to make a graceful merge of the existing packaging-branch history? | 16:39 |
| alesage | or is that not technically possible, in your opinion? | 16:39 |
| cyphermox | it's done | 16:39 |
| cyphermox | alesage: I updated the branch, the MR should be listing "new" commits in grey | 16:39 |
| didrocks | alesage: same request for indicator-sound: https://code.launchpad.net/~mathieu-tl/indicator-sound/inline/+merge/134163 | 16:41 |
| alesage | cyphermox, didrocks, larsu ok--I suppose I'm the gatekeeper as the Jenkins representative | 16:42 |
| cariveri | alright. where in the code is the loop over desktopfiles to load them in the launcherBar? | 16:43 |
| didrocks | alesage: exactly ;) | 16:43 |
| alesage | and I for one welcome our new robotic-butler overlords | 16:43 |
| alesage | didrocks, see a mail from mmrazik this A.M.--our Jenkins is being migrated, should be up RSN | 16:43 |
| larsu | alesage, yup. I can merge it into trunk, but we need to sync so that the jenkins stuff is ready | 16:44 |
| didrocks | alesage: sure, please keep us in touch | 16:44 |
| alesage | actually I do have to make a configuration change if we're going to move to inline (removing our former packaging branches from config) | 16:44 |
| didrocks | alesage: I'm just approving in the comment, don't approve the whole status so that you can do the necessary work and approve it | 16:44 |
| alesage | yes didrocks larsu, I'll update you | 16:44 |
| didrocks | alesage: right, fginther is an expert at that now if you need more help I guess :) | 16:45 |
| didrocks | (he did for a bunch of projects ;)) | 16:45 |
| alesage | ok thx didrocks | 16:45 |
| larsu | thanks alesage | 16:46 |
| didrocks | thanks alesage ;) | 16:46 |
| cariveri | hey. can anyone explain me the data model of the desktopfiles in the unityshell/src ? I expected Launcher to hold all info from the desktopfile and one LauncherIcon. | 16:51 |
| Trevinho | cariveri: hi, I was out sorry... | 18:35 |
| Trevinho | cariveri: I wrote the model, yes... | 18:36 |
| Trevinho | what's up? | 18:36 |
| Trevinho | cariveri: the launcher loads the icons through BAMF (see LauncherController), each icon takes most of data from bamf, that is the component that examine the .desktop files and exposes the informations to all its clients | 18:38 |
| MCR1 | Hi :) | 18:50 |
| MCR1 | Trevinho: If you have a minute: https://code.launchpad.net/~mc-return/unity/unity.merge-minor-possible-speed-improvement/+merge/133435 and https://code.launchpad.net/~mc-return/unity/unity.merge-fix-member-variables-not-initialized-in-their-constructors/+merge/133520 need approval :) | 18:51 |
| === dandrader_ is now known as dandrader|afl | ||
| === dandrader|afl is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dpb_ is now known as Guest75682 | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!