| === zyga is now known as zyga-afk | ||
| sil2100 | Hi | 07:14 |
|---|---|---|
| * sil2100 looks at unity trunk | 07:16 | |
| sil2100 | I think we're ready for freeze | 07:17 |
| sil2100 | didrocks: can I ask for a unity stack freeze? I would need the following trunks frozen: unity, nux, bamf, dee, libunity, unity-lens-video, unity-lens-music, unity-lens-files, unity-lens-applications | 07:18 |
| sil2100 | didrocks: whenever you're ready | 07:18 |
| sil2100 | didrocks: (and hi! btw.) | 07:19 |
| didrocks | sil2100: hey | 07:19 |
| didrocks | sil2100: sure, doing :) | 07:19 |
| sil2100 | I will then proceed to some testing | 07:19 |
| didrocks | sil2100: done | 07:20 |
| didrocks | sil2100: all unity 6 stack is frozen | 07:20 |
| didrocks | unity 5 can still build as usual | 07:20 |
| sil2100 | didrocks: thanks! | 07:21 |
| didrocks | hw :) | 07:21 |
| sil2100 | You have the power | 07:21 |
| didrocks | I do \o/ | 07:21 |
| MCR1 | Hi :) Does compiz version 1:0-9-8+bzr3249+bzr3278ubuntu0+3273 mean that all revisions up to r3278 are integrated ? | 07:26 |
| didrocks | MCR1: yeah | 07:48 |
| didrocks | kind of confusing naming, I know :) | 07:48 |
| MCR1 | didrocks: thx 4 the info, but bad news regarding bug 1012956 | 07:52 |
| ubot5 | Launchpad bug 1012956 in Compiz "It is possible for a dock shadow to be painted even if the dock window isn't painted" [Medium,Fix committed] https://launchpad.net/bugs/1012956 | 07:52 |
| didrocks | meaning, it's not fixed? | 07:52 |
| MCR1 | sry, bug 1011120 | 07:53 |
| ubot5 | Launchpad bug 1011120 in unity (Ubuntu) "Desktop Cube: Unity's top panel shadow gets deformed also and rendered on the desktop cube instead of sticking with the top panel when the cube gets activated" [Undecided,Confirmed] https://launchpad.net/bugs/1011120 | 07:53 |
| MCR1 | this is not fixed yet unfortunately | 07:53 |
| didrocks | :( | 07:54 |
| MCR1 | I am excited to test Unity r2470, because with a 3rd monitor performance here slowed down to a crawl - all animations get slomo... | 08:02 |
| didrocks | MCR1: should have an unity 6 release soon, isn't it sil2100? ;) | 08:02 |
| MCR1 | wow, cool. I am a bit worried about 51 branches waiting to merge to lp:unity though ;) | 08:04 |
| didrocks | I'm as well | 08:06 |
| didrocks | it's popey's team job to push them to get them reviewed now :) | 08:07 |
| Mirv | ok, compiz bzr3278 should be good for a snapshot release to quantal according to upstream. I'll start preparing that. | 08:08 |
| didrocks | Mirv: great! ;) | 08:09 |
| MCR1 | Mirv: Stack Window Switcher 8-) | 08:10 |
| mhr3_ | Mirv, sil2100, you realize there's plugin abi break with latest compiz? | 08:12 |
| Mirv | mhr3_: now I do, I only just started looking at it | 08:14 |
| Mirv | and the delta between 3248 and 3278 | 08:14 |
| MCR1 | hmm, the screenshot plug-in is now completely broken ? Can someone confirm ? | 08:15 |
| MCR1 | sry, wrong observation - gnome-screenshot was not installed here... | 08:17 |
| === Guest59153 is now known as kklimonda | ||
| sil2100 | didrocks: now that I think of it... hm, should I also bump the nux_abi_version? | 08:42 |
| sil2100 | Since Jay removed some functions from the headers | 08:42 |
| didrocks | sil2100: well, he did it for the nux 3 ABI, right? | 08:43 |
| didrocks | sil2100: it's not the same that the one in the distro | 08:43 |
| sil2100 | didrocks: he did a bump nux_api_version bump to 3.0, but nux_abi_version stayed the same | 08:44 |
| didrocks | sil2100: it should have been bumped then | 08:46 |
| sil2100 | I'll bump it now | 08:47 |
| didrocks | sil2100: ping me so that I ack the MR | 08:50 |
| sil2100 | didrocks: I can upload directly to trunk, since I anyway need to tag it as 3.0 and do a Release 3.0 commit | 08:52 |
| didrocks | sil2100: please don't | 08:52 |
| didrocks | sil2100: let the automerger doing the rebuild of packaging | 08:52 |
| didrocks | and then rebuild of unity | 08:52 |
| sil2100 | So, I should do a MRQ for the "Releasing 3.0" commit? | 08:53 |
| didrocks | no | 08:54 |
| didrocks | you should just do a MR for the "bump ABI…" | 08:54 |
| sil2100 | didrocks: lp:~sil2100/nux/3.0_abi_bump | 08:56 |
| sil2100 | didrocks: requesting merge now | 08:56 |
| sil2100 | https://code.launchpad.net/~sil2100/nux/3.0_abi_bump/+merge/113352 | 08:57 |
| didrocks | sil2100: I'm rejecting it, it's not necessary | 08:58 |
| sil2100 | didrocks: where and how will we do the Releasing 3.0 commit now? Since the version got bumped already in the Jay's merge, while we still need someplace to place the tag? | 08:59 |
| didrocks | why did you answer 10:44:22 sil2100 | didrocks: he did a bump nux_api_version bump to 3.0, but nux_abi_version stayed the same | 08:59 |
| didrocks | that's not true | 08:59 |
| sil2100 | It's not? | 08:59 |
| didrocks | the current ABI in the distro is Provides: libnux-abiversion-20120411.01 | 08:59 |
| didrocks | sil2100: how did you check it? | 08:59 |
| sil2100 | Ah, shit... | 09:00 |
| sil2100 | Sorry about that | 09:00 |
| didrocks | so, how did you check it? :) | 09:00 |
| sil2100 | I checked the current branch, and just saw that the date is 2-months old | 09:00 |
| didrocks | it's not 2 month old | 09:00 |
| didrocks | m4_define([nux_abi_version], [20120525.01]) | 09:01 |
| sil2100 | 1 month old ;) | 09:01 |
| didrocks | even not 2 weeks old | 09:01 |
| didrocks | what did you check? | 09:01 |
| didrocks | seems it's not the right string you checked | 09:01 |
| didrocks | and 20120525.01 != 20120411.01 (previous version in the distro), so we are fine | 09:02 |
| didrocks | but I want to understand what you did check | 09:02 |
| sil2100 | We now have 20120703 and its 20120524 <- so it's over 1 month old, so I thought that it didn't get bumped | 09:02 |
| sil2100 | I just checked trunk, not the MRQ | 09:02 |
| sil2100 | My mistake | 09:02 |
| didrocks | hum, trunk contains 20120525.01 already | 09:02 |
| sil2100 | Yes | 09:02 |
| didrocks | so, it's 2 weeks old, nothing different between the trunk and the MRQ | 09:03 |
| didrocks | as the MRQ diff is built upon trunk | 09:03 |
| sil2100 | And I only checked trunk, saw 0524 and thought 'hm, it's too old, since the MRQ was probably submitted not THAT long ago' | 09:03 |
| didrocks | also, the current version in the distro is not 20120703 | 09:03 |
| didrocks | but 20120411.01 | 09:03 |
| sil2100 | I know, damn, you just don't understand my reasoning here | 09:03 |
| sil2100 | I just checked trunk and thought that the ABI version was 'too old for the 3.0 switch', since I didn't know that it was bumped at all | 09:04 |
| sil2100 | Ah, nevermind | 09:04 |
| sil2100 | It was my mistake anyway | 09:04 |
| didrocks | sil2100: so please don't juts think, but *check* | 09:04 |
| sil2100 | Will do | 09:04 |
| didrocks | thanks | 09:04 |
| sil2100 | didrocks: so how should we add the "Releasing 3.0" commit in nux now? | 09:05 |
| sil2100 | didrocks: since the version bump has been made already | 09:05 |
| didrocks | sil2100: when everything is validated, this is a direct push to trunk | 09:05 |
| didrocks | sil2100: but only do that when we upload the release | 09:05 |
| didrocks | that, it's validated and such | 09:05 |
| sil2100 | k | 09:05 |
| didrocks | that's why I normally use the package in the ppa for testing | 09:05 |
| didrocks | and don't do a release | 09:05 |
| didrocks | but you do it as you want :) | 09:06 |
| didrocks | just be aware that you will have to redo everything if trunk isn't releasable | 09:06 |
| sil2100 | didrocks: during testing, should we test the new release on packages from quantal or quantal-proposed? | 10:13 |
| didrocks | sil2100: quantal should be enough TBH, we don't have really impacting libraries in quantal-proposed right now | 10:14 |
| === mmrazik is now known as mmrazik|lucnh | ||
| sil2100 | Trevinho: you around? | 10:55 |
| Trevinho | sil2100: yep | 10:55 |
| === MacSlow is now known as MacSlow|lunch | ||
| marco | Hi! Where is the list of icons in the launcher stored? | 11:30 |
| === Trevinho is now known as Trevinho|lunch | ||
| sil2100 | hmmm, strange | 11:54 |
| === zyga is now known as zyga-afk | ||
| === zyga-afk is now known as zyga | ||
| MCR1 | Could someone please comment on bug 1019453 :) | 12:30 |
| ubot5 | Launchpad bug 1019453 in unity (Ubuntu) "Unity Launcher Regression: Autohide Option makes the launcher not being used anymore, add Intellihide mode like all other docks/launchers have" [Wishlist,Incomplete] https://launchpad.net/bugs/1019453 | 12:30 |
| MCR1 | IMHO the launcher should not autohide once it is revealed until the pointer leaves the launcher (does not hover over the launcher area)... | 12:31 |
| sil2100 | didrocks: *sighs* we'll have to release a new tarball for bamf probably | 12:32 |
| didrocks | sil2100: hum, why? | 12:32 |
| didrocks | MCR1: please do not open a bug for that | 12:33 |
| didrocks | MCR1: first, because it's surely a duplicate | 12:33 |
| didrocks | MCR1: second because those discussions should go to the unity design ML | 12:33 |
| didrocks | MCR1: a bug tracker is not a forum | 12:33 |
| sil2100 | didrocks: well, I could hm, try working this out through distropatches, but - one moment, since this story is quite long: | 12:33 |
| MCR1 | didrocks: I did not find anything regarding point 1 - it is clearly a bug | 12:33 |
| didrocks | sil2100: I'm hearing what seems to be a fun story :) | 12:33 |
| didrocks | MCR1: it's not, it's a design decision | 12:34 |
| didrocks | and you are calling for people commenting | 12:34 |
| MCR1 | didrocks: & there have been endless discussions about dodge, but not intellihide | 12:34 |
| didrocks | MCR1: dodge is intellihide | 12:34 |
| sil2100 | didrocks: so, it seems bamf has some broken make dist scripts, and during creation of tarballs some files get in which shouldn't | 12:34 |
| MCR1 | no, dodge is window-dodge, intellihide is active-window dodge | 12:34 |
| sil2100 | didrocks: for instance, auto-generated files like bamf-marshal.{c,h} get inside, although these should be generated at build time | 12:35 |
| didrocks | MCR1: it's still called dodge in the code | 12:35 |
| didrocks | MCR1: I know it, I wrote it | 12:35 |
| MCR1 | Every good launcher/dock has such an option, which feels quite different than normal dodge | 12:35 |
| didrocks | MCR1: what we called intellihide for us, and in the ccsm option is the window-dodge | 12:35 |
| sil2100 | didrocks: if that wasn't enough, each tarball also has Makefile.in's included, which are generated from Makefile.am - and if there's a change in Makefile.am, it's not being changed in the respective Makefile.in from the previous tarball | 12:36 |
| didrocks | MCR1: and I don't care about that discussion, it should be discussed on the design ML, as told | 12:36 |
| seb128 | MCR1, I can't confirm the issue there, the launcher doesn't hide while mouseovered | 12:36 |
| sil2100 | didrocks: so currently we have a situation that some symbols in trunk got hidden (made private) - and had their names changed, but the Makefile.in's still generate invalid marshal files | 12:37 |
| seb128 | didrocks, is it supposed to hide while the cursor is still over it by design? | 12:37 |
| didrocks | seb128: no, this is separeted, i'm answering about the 2. | 12:37 |
| === dandrader_ is now known as dandrader|afk | ||
| didrocks | 1. seems a bug, but not reproducible to me | 12:37 |
| seb128 | didrocks, ok, same here, thanks | 12:37 |
| MCR1 | didrocks: okay, I already joined the mailinglist, I will discuss it there | 12:37 |
| didrocks | MCR1: thanks :) | 12:38 |
| didrocks | MCR1: can you give more info about 1.? | 12:38 |
| seb128 | MCR1, the bug can't be confirmed by anyone it seems | 12:38 |
| didrocks | do you trigger anything specific to have it hidden with the mouse over? | 12:38 |
| sil2100 | didrocks: e.g. even if I remove from the packaging branch bamf-marshal.{c,h} files, still invalif functions get generated in the new bamf-marshal due to Makefile.in's having the old function names, since bamf trunk only has Makefile.am's and changes those only there | 12:38 |
| sil2100 | didrocks: anyway... should I still distro patch it ;)? | 12:38 |
| didrocks | sil2100: no, do a release, and hide the symbols then in the debian/libbamf*symbols | 12:39 |
| sil2100 | (to do that I would have to remove some files from the distro branch and modify some Makefile.in's) | 12:39 |
| didrocks | sil2100: or ask mhr3_ to do it, he loves that:) | 12:39 |
| sil2100 | didrocks: doing releases ;) ? | 12:39 |
| didrocks | yeah | 12:39 |
| didrocks | he's in the tarball business | 12:39 |
| sil2100 | mhr3_: my man! | 12:39 |
| didrocks | not making a lot money of it, but still enjoying it :) | 12:39 |
| MCR1 | didrocks, seb128 - strange, I can reproduce 1 every time | 12:40 |
| sil2100 | mhr3_: Michal, my man! Hope you're not too busy? | 12:40 |
| seb128 | MCR1, do you use unity 3d or 2d? | 12:40 |
| MCR1 | I did not change any Unity settings - 3d | 12:40 |
| sil2100 | mhr3_: I've got a mission of great importance ;) | 12:40 |
| didrocks | MCR1: do you move the mouse? | 12:40 |
| didrocks | MCR1: like, press super | 12:40 |
| didrocks | put the mouse over the launcher and move it | 12:41 |
| didrocks | then release super | 12:41 |
| MCR1 | didrocks: In that case the launcher stays visible | 12:42 |
| didrocks | MCR1: so, what is exactly your test case to have it hidden? | 12:42 |
| MCR1 | didrocks: reveal it with the mouse by pushing to the left edge - once it revealed stop moving the mouse to the left or move it 1 or 2 pixels to the right -> the launcher will hide | 12:43 |
| MCR1 | although the mousepointer hovers over it | 12:44 |
| didrocks | MCR1: yeah, in fact, this is an artefact of another behavior | 12:44 |
| didrocks | MCR1: like put the mouse in the launcher area (hidden) | 12:45 |
| didrocks | press super | 12:45 |
| didrocks | release super | 12:45 |
| MCR1 | it feels very wrong | 12:45 |
| didrocks | the launcher will hide | 12:45 |
| didrocks | this is because you didn't the mouse | 12:45 |
| didrocks | so you don't want it to stuck | 12:45 |
| didrocks | but I agree, in your case, it should staty | 12:45 |
| didrocks | stay | 12:45 |
| MCR1 | IMHO the launcher should never autohide if the mousepointer hovers it | 12:45 |
| didrocks | MCR1: it needs for the case I describe | 12:45 |
| didrocks | like you pressed super by error | 12:45 |
| didrocks | you don't want it to stick | 12:46 |
| didrocks | or you pressed super + 3 | 12:46 |
| didrocks | to switch to another application | 12:46 |
| seb128 | hum | 12:46 |
| didrocks | you dont' want it to stick as well, because the mouse was in the wrong area | 12:46 |
| didrocks | but in your case, it's a bug | 12:46 |
| didrocks | if it's been revealed by the mouse | 12:46 |
| didrocks | it should stay | 12:46 |
| MCR1 | yeah | 12:46 |
| didrocks | MCR1: mind updating the bug report with the details? | 12:46 |
| seb128 | didrocks, can you confirm the bug? I can't here | 12:46 |
| didrocks | ah, I didn't try | 12:46 |
| didrocks | one sec :) | 12:46 |
| seb128 | like pushing to reveal, move a bit, stop moving? | 12:47 |
| === _salem is now known as salem_ | ||
| didrocks | seb128: no, it's pushing to reveal, don't move | 12:47 |
| MCR1 | didrocks: no, ofc not, but the details are already there | 12:47 |
| seb128 | didrocks, same, doesn't hide for me | 12:47 |
| didrocks | yeah, same for me :/ | 12:47 |
| seb128 | didrocks, but MCR1 said he moves some pixels | 12:47 |
| seb128 | but in any case no way to reproduce it here | 12:47 |
| MCR1 | I do not need to move the mousepointer | 12:47 |
| seb128 | it will need debugging by somebody having the bug | 12:47 |
| didrocks | yep | 12:48 |
| didrocks | if anything, it can be because of this code | 12:48 |
| didrocks | but I can't reproduce this | 12:48 |
| didrocks | IIRC, there was a protection for this particular case in fact | 12:48 |
| MCR1 | strange, I experience this behavior for a long time now | 12:48 |
| seb128 | what input device do you use? | 12:48 |
| didrocks | MCR1: did you change the "push to reveal" sensitivity? | 12:49 |
| MCR1 | not that I know | 12:49 |
| MCR1 | (although I probably have already changed every CCSM setting ;)) | 12:49 |
| seb128 | try in a guest session? | 12:49 |
| MCR1 | ok will do | 12:50 |
| MCR1 | c y | 12:50 |
| didrocks | seb128: my only bet is that the sensitivity is low as so the mouse "doesn't mouse enough" | 12:51 |
| seb128 | could be yeah... | 12:51 |
| didrocks | move* | 12:51 |
| seb128 | having "always on" by default was a good choice ;-) | 12:51 |
| JohnLea | seb128, MCR1, didrocks; hyia, a bit late to the conversation, but is bug #745707 relevant to this conversation? | 12:52 |
| ubot5 | Launchpad bug 745707 in unity (Ubuntu) "Launcher - Launcher should never autohide when the cursor is positioned over the Launcher (e.g. When a spread ends)" [Medium,Confirmed] https://launchpad.net/bugs/745707 | 12:52 |
| didrocks | seb128: I have autohide by default and happy with it :) | 12:52 |
| seb128 | hehe | 12:52 |
| didrocks | JohnLea: well a bit, but nobody reproduced 1. | 12:52 |
| didrocks | JohnLea: 2. is the intellihide discussion and should happen on the design ML :) | 12:52 |
| sil2100 | mhr3_: piing | 12:53 |
| MCR1 | back... | 12:53 |
| MCR1 | Strange, the problem does NOT show in the guest session | 12:53 |
| MCR1 | Maybe it is because of my dualscreen config | 12:53 |
| MCR1 | I am just using the launcher on the primary monitor | 12:54 |
| JohnLea | didrocks; you mean nobody managed to reproduce the issue in bug #745707, or something else? | 12:54 |
| ubot5 | Launchpad bug 745707 in unity (Ubuntu) "Launcher - Launcher should never autohide when the cursor is positioned over the Launcher (e.g. When a spread ends)" [Medium,Confirmed] https://launchpad.net/bugs/745707 | 12:54 |
| didrocks | JohnLea: right, nobody did | 12:54 |
| MCR1 | :-[ | 12:54 |
| MCR1 | I can make a video if you do not believe that it is happening here | 12:55 |
| JohnLea | didrocks; I have just reproduced the issue described in that bug, I'll attach a screencast | 12:55 |
| didrocks | MCR1: it's not that we don't believe it, it's just that if we can't reproduce, we can't fix it :) | 12:55 |
| MCR1 | sure | 12:55 |
| didrocks | MCR1: but it seems it's a particular settings, right? | 12:56 |
| didrocks | as you don't have it on a guest session | 12:56 |
| didrocks | MCR1: gnome-control-center background | 12:56 |
| didrocks | MCR1: behavior | 12:56 |
| didrocks | is the sensitivity to the default? | 12:57 |
| jaytaoko1 | sil2100: didrocks: hello | 12:57 |
| didrocks | hey jaytaoko1 | 12:57 |
| sil2100 | jaytaoko1: hi! | 12:58 |
| c10ud | hey didrocks, hello, could you ask Unity Merger to spin a new Unity package for Precise? | 12:59 |
| sil2100 | brb | 12:59 |
| didrocks | c10ud: no, we only publish for quantal now | 12:59 |
| didrocks | c10ud: we can't build on precise because of boost | 13:00 |
| c10ud | ew, so no more updates for lts? | 13:00 |
| didrocks | c10ud: well, this trunk :) | 13:00 |
| didrocks | not what's for SRU | 13:00 |
| didrocks | the SRU ppa is unity-team/sru | 13:00 |
| didrocks | and there you have unity 5.0 builds for precise ;) | 13:01 |
| jaytaoko1 | didrocks: is the freeze in effect? | 13:01 |
| didrocks | (/!\ the transition between trunk and the sru ppa is not supported) | 13:01 |
| didrocks | jaytaoko1: yeah, sil2100 asked me to do it this morning | 13:01 |
| c10ud | yep, it's just i wanted to try a modification that landed today in trunk...building locally from source is quite frustrating :p | 13:01 |
| didrocks | but it seems no email was sent to confirm it | 13:01 |
| didrocks | c10ud: so no, no trunk for precise :) | 13:02 |
| c10ud | ok thanks | 13:02 |
| didrocks | yw, and sorry ;) | 13:02 |
| jaytaoko1 | sil2100: how is the release going? | 13:02 |
| MCR1 | didrocks: sensitivity is default, this are the other settings: http://imagebin.org/219424 | 13:03 |
| sil2100 | jaytaoko1: slowly, I had some packaging/build problems with other packages - but nux and unity went in fine | 13:03 |
| c10ud | no problem..anyway unity being locked to version 5 for precise (5yrs lts) is just weird, i must say (!) | 13:04 |
| jaytaoko1 | sil2100: cool | 13:04 |
| didrocks | MCR1: you have other sensitivy settings, I don't know the default by heart, try to reset all the "Launcher Reveal/Edge/Pressure Decay" ones | 13:05 |
| mhr3_ | sup sil2100, you're quite lucky at pinging me during my lunch :P | 13:05 |
| didrocks | c10ud: why? | 13:05 |
| didrocks | c10ud: we never deliver new versions on stable release | 13:05 |
| didrocks | c10ud: firefox is a special case | 13:05 |
| didrocks | c10ud: we only provide stable release update, based on the version it as | 13:06 |
| didrocks | has* | 13:06 |
| didrocks | but don't add new features and so on | 13:06 |
| didrocks | this is how you get stability :) | 13:06 |
| c10ud | i thought unity fast and in-house development deserved a special place, but this is only my unexpressed though ofc | 13:06 |
| didrocks | c10ud: well, it's like any other software | 13:07 |
| c10ud | stability.. and bugs :p | 13:07 |
| didrocks | c10ud: there are new build-dependencies | 13:07 |
| didrocks | c10ud: we fixes bugs | 13:07 |
| didrocks | backporting them will mean backporting crackful version untested | 13:07 |
| didrocks | if you want the latest, use the latest available release :) | 13:07 |
| didrocks | if you want stability, bug fixes, and support, use the LTS, but versions are frozen | 13:08 |
| didrocks | nothing changed here from the past 8 years :) | 13:08 |
| c10ud | i know, but consider this: the bug i'm interested in is poor performance with video (probably because of unity) | 13:08 |
| c10ud | unless someone backports patches, i'm doomed | 13:08 |
| didrocks | c10ud: we backported some poor performance fixes | 13:08 |
| didrocks | and SRU them | 13:08 |
| didrocks | we might SRU more, once sil2100 has finished with the release | 13:08 |
| didrocks | if they are not risky | 13:09 |
| didrocks | meaning, can bring more pain than benefit for all our users | 13:09 |
| c10ud | yea i get it | 13:09 |
| c10ud | it's just you mentioned "boost" and i thought "wtf" | 13:09 |
| MCR1 | didrocks: All settings are default, except panel opacity, my guess is that this is a multimonitor issue once again - I will try to reproduce it in a guest session | 13:09 |
| didrocks | c10ud: all the fixes that landed in precise-updates since the release were done in unity 6 first, and then backported to unity 5. | 13:09 |
| didrocks | c10ud: it's a library ;) | 13:10 |
| MCR1 | brb | 13:10 |
| c10ud | you must admit it's not gobject | 13:10 |
| c10ud | low level libraries don't change _that_ often, this is what i mean | 13:11 |
| c10ud | and not being able to build unity-trunk in precise out of the box is..weird | 13:11 |
| c10ud | anyway, not complaining here, just throwing thoughts | 13:11 |
| didrocks | c10ud: I don't get you | 13:12 |
| didrocks | c10ud: we are using features of the newer boost right now | 13:12 |
| didrocks | 1.49 | 13:12 |
| didrocks | which isn't available in precise | 13:12 |
| didrocks | and soon, some 4.7 gcc specifics | 13:12 |
| seb128 | depends on the new nux as well | 13:12 |
| didrocks | so yeah, as those are not available in precise, and that we are targetting quantal, we build them on quantal :) | 13:12 |
| didrocks | yeah, not sure we want people to handle the nux and compiz transitions | 13:13 |
| c10ud | in my small yard (software) i tend to keep some backward compatibility | 13:14 |
| c10ud | here you break 2 months after latest os release | 13:14 |
| didrocks | well, we build for our targeted platform | 13:15 |
| didrocks | and use the latest optimization possible for this platform | 13:15 |
| didrocks | we don't really support people running newer version on older platform, and especially as it's untested, this can created more issues than it fixes them | 13:15 |
| didrocks | but you really want, you can do a backport through ubuntu-backport | 13:16 |
| didrocks | but the pile of dependencies to backport might be huge | 13:16 |
| c10ud | well, i get is a choice, and mantaining stuff can be a PITA, it's just... 2 months | 13:16 |
| c10ud | and unity seems pretty self contained | 13:16 |
| didrocks | c10ud: there is not a lot of manpower though, we would love to support and bring backward compatibility :) | 13:16 |
| didrocks | c10ud: if it's an area you are interested in, you are welcome to contribute there! | 13:17 |
| c10ud | heh i know | 13:17 |
| c10ud | anyway end of story is: this hard dep on new boost stops even setting up a personal ppa | 13:18 |
| c10ud | unless you backport boost and then gcc47 (?) | 13:18 |
| didrocks | c10ud: yeah, that's what I meant by "welcome to contribute" :) | 13:18 |
| c10ud | weird stuff, but no problem accepting it ;) | 13:18 |
| === Trevinho|lunch is now known as Trevinho | ||
| MCR1 | didrocks: I am unable to reproduce the launcher problem in the guest session, but I'll find out what is causing it sooner or later ;) | 13:28 |
| didrocks | MCR1: keep us in touch! | 13:30 |
| MCR1 | sure | 13:30 |
| === MacSlow|lunch is now known as MacSlow | ||
| === dandrader|afk is now known as dandrader | ||
| sil2100 | didrocks: hmm | 13:40 |
| sil2100 | didrocks: I've got another 'sticky-situation' ;) | 13:40 |
| sil2100 | didrocks: since ulm fails building a package due to test/assertions.vapi missing in the tarball | 13:41 |
| didrocks | sil2100: water helps with sticky! :) | 13:41 |
| didrocks | oh, who did that? | 13:41 |
| didrocks | bad bad upstream | 13:41 |
| sil2100 | didrocks: now we have 2 options of fixing this (besides rolling-out a new tarball) | 13:41 |
| * didrocks runs :) | 13:41 | |
| didrocks | sil2100: you will have to roll a new tarball | 13:41 |
| didrocks | I want upstream tarballs being cleaned | 13:41 |
| sil2100 | ...ok, this basically answers my question ;p | 13:41 |
| sil2100 | mhr3_: can you fix that in trunk and roll out a new tarball of ulm as well? ;) | 13:42 |
| didrocks | who accepted this merge request, that's intolerable! | 13:45 |
| * didrocks whistles :p | 13:45 | |
| mhr3_ | didrocks, i call it automake bug, they changed the behaviour | 13:50 |
| mhr3_ | and worst of all, distcheck passed | 13:51 |
| didrocks | mhr3_: wow? so not me to be blamed so much :) | 13:51 |
| didrocks | (I was totally ironic as it was my merge being the cause) | 13:51 |
| mhr3_ | didrocks, well you of course as well, you didn't add the vapi to extra_dist in the first place :P | 13:51 |
| didrocks | mhr3_: what automake did change? | 13:51 |
| didrocks | ah, so you did that, make dist-check passed then | 13:52 |
| didrocks | but it's not disted? | 13:52 |
| mhr3_ | didrocks, apparently the stamp files are no longer dist-ed, which means valac needs to be invoked, even though the generated c files are there | 13:52 |
| mhr3_ | but it still puzzles me how come that distcheck passed | 13:53 |
| didrocks | mhr3_: so no more forced to patch the .c files \O/ | 13:53 |
| mhr3_ | didrocks, i'm not keen on doing a new tarball afterall it's just make check that fails | 13:53 |
| mhr3_ | and fixable with simple touch :P | 13:53 |
| didrocks | mhr3_: well, this is a backportable commit | 13:54 |
| mhr3_ | i'll add it to release notes though | 13:54 |
| didrocks | sil2100: FYI ^ | 13:54 |
| sil2100 | ...so can I just do the debian/rules touch hack? | 13:54 |
| sil2100 | ;) | 13:55 |
| didrocks | sil2100: yeah, but document it so that we remove it for next release | 13:55 |
| didrocks | in debian/changelog | 13:55 |
| didrocks | and add a // TOREMOVE | 13:55 |
| sil2100 | didrocks: ACK! | 13:55 |
| sil2100 | So now just BAMF remains... | 13:56 |
| didrocks | Mirv: what's happening on compiz side? | 13:56 |
| mhr3_ | wait wth, the tarball does have the stamp file | 13:57 |
| sil2100 | Well, it only works when I add the touch directly | 13:57 |
| sil2100 | Trevinho: how's the tarball-creation going? Any luck? | 14:00 |
| Trevinho | sil2100: it doesn't do make dist here... :o | 14:00 |
| Trevinho | libtool: link: cannot find the library `../../../lib/libbamf/libbamf3.la' or unhandled argument `../../../lib/libbamf/libbamf3.la | 14:00 |
| Trevinho | sil2100: ah, ok... found | 14:01 |
| sil2100 | Trevinho: you probably need to call make first? hm, it seems a bit broken? | 14:01 |
| mhr3_ | Trevinho, i was going to do it, but since you're at it :P | 14:01 |
| Trevinho | sil2100: yes... that's the issue | 14:01 |
| Trevinho | mhr3_: you know what... ? I probably can't upload to lp as I don't have the rights on the project... | 14:02 |
| mhr3_ | Trevinho, don't do just dist, ever! always distcheck | 14:02 |
| didrocks | that's usual in dx project | 14:02 |
| sil2100 | mhr3_: could you then do it? You're more PRO in it than me and Trevinho - we apparently suck in creating tarballs :( | 14:02 |
| didrocks | you need to call make before distcheck | 14:02 |
| didrocks | Trevinho: ^ | 14:02 |
| Trevinho | mhr3_: yes, I did distcheck | 14:02 |
| mhr3_ | didrocks, you mean gtk-doc using project :P | 14:02 |
| didrocks | unity used to be that way | 14:02 |
| didrocks | mhr3_: yeah ;) | 14:02 |
| didrocks | mhr3_: I shortcuted it | 14:02 |
| mhr3_ | Trevinho, ./autogen --enable-gtk-doc && make && make distcheck | 14:03 |
| didrocks | mhr3_: but I think in that case, we should really make distcheck dep on make :) | 14:03 |
| Trevinho | sil2100: I'm happy to do that... I mean, I'd like to then in future, so... I need to learn that once for all... | 14:03 |
| didrocks | mhr3_: it's a long old 2 years old discussion in fact :p | 14:03 |
| mhr3_ | didrocks, imo they should fix gtk-doc :) | 14:03 |
| sil2100 | Trevinho: ok ;) If only you're free and eager, thanks! | 14:03 |
| didrocks | mhr3_: heh ;) | 14:03 |
| mhr3_ | Trevinho, so should i do it? | 14:03 |
| mhr3_ | that reminds me, i have one hanging patch in gtk-doc | 14:04 |
| Trevinho | mhr3_: if I can't upload... I think you should... | 14:04 |
| mhr3_ | k, on it | 14:04 |
| didrocks | mhr3_: you are taking a 10% charge, right? :) | 14:04 |
| Trevinho | mhr3_: but I'll push the change on bzr... | 14:04 |
| Trevinho | :P | 14:04 |
| Trevinho | mhr3_: I've just pushed bamf 2.2 on trunk... so grab that and do the tarball ;) | 14:06 |
| Trevinho | mhr3_: actually it's "BAMF 'no-more-evil-numbers' 0.2.2"... | 14:06 |
| mhr3_ | didrocks, while you're being evil, can you check which the last merge in bamf failed? the log doesn't really say anything useful | 14:07 |
| mhr3_ | w/which/why/ | 14:07 |
| sil2100 | ah, the thing I pointed out yesterday? | 14:08 |
| mhr3_ | Trevinho, we can't do 0.2.2, that's older than the last release | 14:08 |
| Mirv | didrocks: compiz built, and one unity built against it, unity binaries published 5 min ago and seem to be working | 14:08 |
| Mirv | https://launchpad.net/~timo-jyrinki/+archive/prerelease | 14:08 |
| mhr3_ | kinda 118 > 2 :) | 14:08 |
| Trevinho | mhr3_: damn... | 14:08 |
| didrocks | Mirv: sweet! is the gsettings migration done as well? | 14:09 |
| Trevinho | mhr3_: probably I'm still sleeping.. | 14:09 |
| mhr3_ | Trevinho, as i said, let's merge the interesting things next week and do 0.3, or 6.0 or whatever | 14:09 |
| Mirv | didrocks: I'm not sure how to test it, but yes flags enabled and schema files part of the gnome package :) | 14:09 |
| sil2100 | \o/ | 14:09 |
| didrocks | Mirv: switch the default profile to it | 14:09 |
| didrocks | Mirv: the ubuntu one | 14:09 |
| didrocks | you can choose the backend there | 14:09 |
| Trevinho | mhr3_: ok, do yuou fix it? | 14:09 |
| didrocks | gconf -> gsettings | 14:10 |
| mhr3_ | Trevinho, sure | 14:10 |
| Mirv | didrocks: ah right, the profile... sure, I'll do that | 14:10 |
| didrocks | mhr3_: seems a test doesn't start the service? | 14:10 |
| didrocks | mhr3_: doesn't really help, indeed :/ | 14:10 |
| didrocks | mhr3_: org.a11y.Bus, do you really use this during your tests? | 14:11 |
| mhr3_ | didrocks, i think that's unrelated | 14:11 |
| mhr3_ | unless it isn't :D | 14:11 |
| mhr3_ | didrocks, if you scroll up there's a similar failure and doesn't break stuff | 14:12 |
| didrocks | mhr3_: you're right | 14:12 |
| didrocks | mhr3_: if this fails again, I can set -x the script to see where it fails | 14:13 |
| mhr3_ | didrocks, well i already re-approved it, so feel free to [UNBLOCK] | 14:13 |
| mhr3_ | (i'm doing the tarball now anyway from current trunk | 14:14 |
| didrocks | mhr3_: let's wait for you pushing the released version | 14:14 |
| didrocks | mhr3_: and that the tests happens | 14:14 |
| didrocks | then, we'll look at it | 14:14 |
| mhr3_ | will be up in 2minutes | 14:14 |
| mhr3_ | this non-silent-rules build is awful :P | 14:14 |
| didrocks | mhr3_: agreed | 14:15 |
| didrocks | but better to see what's wrong :) | 14:16 |
| mhr3_ | hahaha, people subscribed to lp:bamf will get a "1 revision removed from the branch" email :P | 14:18 |
| mhr3_ | that's how evil i am | 14:19 |
| sil2100 | :E | 14:20 |
| sil2100 | Mu haha | 14:20 |
| sil2100 | Evil mhr3_ ;) | 14:20 |
| mhr3_ | sil2100, https://launchpad.net/bamf/0.2/0.2.120/+download/bamf-0.2.120.tar.gz | 14:20 |
| sil2100 | mhr3_: \o/ | 14:20 |
| sil2100 | Thanks | 14:20 |
| === zyga is now known as zyga-food | ||
| === dandrader is now known as dandrader|afk | ||
| c10ud | didrocks, i dl'd lp:nux and lp:unity then stole sil2100's debian directories and built packages here on precise | 14:42 |
| c10ud | question is were you lying or did i miss something? | 14:42 |
| c10ud | (note: unity --version still says 5.12 though) | 14:42 |
| c10ud | (i'm trying to see if src code has the wrong number) | 14:43 |
| didrocks | c10ud: you don't run the same code with the older boost version | 14:43 |
| didrocks | c10ud: and I told than gcc4.7 switch is coming soon | 14:43 |
| didrocks | not yet there | 14:43 |
| c10ud | didrocks, but packages built and i'm running them (?) | 14:43 |
| didrocks | c10ud: yeah, but you are using a different code path :) | 14:44 |
| didrocks | the precise one | 14:44 |
| c10ud | i branched lp:unity | 14:44 |
| c10ud | i got only the debian folders from sil2100 | 14:45 |
| c10ud | (i think they were for quantal) | 14:45 |
| didrocks | I'm surprised it built with the debian folders from sil2100, boost 1.49 is in precise? | 14:46 |
| didrocks | oh no, I build-dep on boost-dev | 14:46 |
| didrocks | forgot about that changed :) | 14:46 |
| didrocks | so you are building with boost 1.46, not 1.49 | 14:46 |
| didrocks | (I was depending on hardcoded boost version before quantal) | 14:47 |
| c10ud | i am asking because unity --version still says 5.12 and i cannot grep for the relevant part of the code | 14:47 |
| c10ud | so i'm still not really sure on what's going on, but branches log seem correct so as packages | 14:48 |
| c10ud | and yes, i'm building with stock libraries | 14:48 |
| c10ud | except for nux | 14:48 |
| didrocks | c10ud: don't trust unity --version, it's not updated until we really do a release :) | 14:49 |
| didrocks | so you are using it, but with older boost | 14:49 |
| c10ud | ok then, i guess trunk on precise is still possible then (?) | 14:49 |
| didrocks | c10ud: not sure how this will behave, you may experiment some crash due to this version of boost | 14:49 |
| c10ud | also i don't find an unity commit where this boost break is explicited | 14:49 |
| didrocks | as, especially in compiz, we had to update for newer boost | 14:49 |
| didrocks | c10ud: no, in unity, you have updates for gcc 4.7 mostly, but that should be backward compatible | 14:50 |
| c10ud | still running stock's compiz btw | 14:50 |
| didrocks | c10ud: hum, I was thinking you took all of it, you miss important speed improvment thens | 14:50 |
| didrocks | then | 14:50 |
| didrocks | but anyway, as told, we are backporting most of the fixes to precise | 14:51 |
| didrocks | including speed improvments | 14:51 |
| c10ud | yea my worry was that also building from src wasn't enough | 14:53 |
| c10ud | but seems like it's not the case | 14:53 |
| c10ud | ..since you were lying (mileage may vary here, if i get some hard crash, eheh) :p | 14:53 |
| c10ud | so it's ok | 14:53 |
| c10ud | i'll see what happens with compiz then | 14:54 |
| didrocks | c10ud: thanks for the "lying", but if you get crashes, don't complain :p | 14:54 |
| didrocks | c10ud: you are not on the same stack than the one we test | 14:54 |
| sil2100 | didrocks: I have need for advice! When we merge in a new upstream release and in this release no bugs are fixed, but just 'new features' - what should I write in the changelog below "New upstream release" ;p? | 14:54 |
| didrocks | sil2100: what example do you have? | 14:55 |
| c10ud | i can take the risk, i won't complain ;) | 14:55 |
| sil2100 | https://code.launchpad.net/~unity-team/libunity/trunk <- | 14:55 |
| sil2100 | libunity! | 14:55 |
| sil2100 | trunk = no bugfixes | 14:55 |
| didrocks | sil2100: you can include the commit messages or summarize manually the new features | 14:56 |
| didrocks | don't make one message per commit | 14:56 |
| sil2100 | didrocks: ah, ok, sounds reasonable | 14:56 |
| sil2100 | Thank you | 14:56 |
| didrocks | yw :) | 14:56 |
| davidcalle | mhr3_, since a few days on Precise, deesequencemodel.set_schema_full ('ssss') fails with a TypeError "take exactly 3 arguments (2 given)". Same code still works fine on Quantal. | 15:39 |
| davidcalle | mhr3_, any idea? | 15:39 |
| sil2100 | didrocks: ok, we're currently doing all the autopilot tests, manual-tests, checkbox tests etc. for the new release test builds | 15:42 |
| sil2100 | (on my PPA) | 15:42 |
| didrocks | sil2100: sweet, good luck! :) | 15:42 |
| didrocks | sil2100: you know that the staging ppa was for that in fact? (testing easily from a ppa before doing the release) | 15:42 |
| sil2100 | didrocks: but I already pushed all the packaging branches for you to review - all besides unity, since I didn't want to commit without the big list of bugs in the changelog (didn't add that yet) | 15:42 |
| sil2100 | didrocks: *shocked* ugh | 15:43 |
| sil2100 | didrocks: well, I created my own one, ppa:sil2100/prerelease | 15:43 |
| sil2100 | Since I didn't know, duh | 15:43 |
| didrocks | hum | 15:43 |
| didrocks | you didn't know about the staging ppa? | 15:43 |
| didrocks | (the one built automatically from every commit?) | 15:43 |
| sil2100 | I knew, but didn't know I could push there | 15:43 |
| didrocks | no | 15:43 |
| didrocks | I mean, what I did on the past | 15:43 |
| didrocks | (the workflow I described during the sprint) | 15:44 |
| didrocks | using the staging ppa, get testing from those packages | 15:44 |
| didrocks | then, when/if all is ok | 15:44 |
| didrocks | doing the release | 15:44 |
| didrocks | not doing it backward | 15:44 |
| didrocks | but we'll see, I hope you won't have to do the release again :) | 15:44 |
| sil2100 | I hope so too, but actually - as I said - we already tested the 6.0.0 unity package with nux 3.0 - just a bit older snapshot | 15:45 |
| sil2100 | Since we couldn't really test the most recent one without a freeze | 15:45 |
| didrocks | I don't see why it forced you to do a release instead of testing from the staging ppa :) | 15:45 |
| didrocks | but let's see how it goes | 15:45 |
| mhr3_ | davidcalle, i guess you want .set_schema("s", "s", "s") | 15:45 |
| didrocks | I'm sure you will change your workflow back to using the staging ppa if you need to redo the releases :) | 15:46 |
| sil2100 | For now both unity and nux arent yet released - the tarballs can be changed if tests fail ;) | 15:46 |
| didrocks | yeah, it's just much more extra work :) | 15:47 |
| davidcalle | mhr3_, ok but it worked last week and still does on Quantal, which is a bit odd. | 15:47 |
| didrocks | sil2100: and if there is something in bamf, you have to redo/rerelease and you did release a non functional one | 15:47 |
| sil2100 | Probably... well, you can't expect a newbie to remember everything you say to him once during a sprint! ;) | 15:47 |
| didrocks | this is why I don't understand why you did it this way :) | 15:47 |
| sil2100 | Especially when he was doing some work during lectures as well ;p | 15:47 |
| didrocks | yeah, but since Monday I'm telling you to use the staging ppa to test :) | 15:47 |
| didrocks | again, let's see for next one | 15:48 |
| mhr3_ | davidcalle, then something is broken, set_schema_full expects an array | 15:48 |
| mhr3_ | or well, list/tuple in python | 15:48 |
| mhr3_ | maybe they're actually hiding the length param now | 15:49 |
| mhr3_ | anyway, ^^ is the compatible way | 15:49 |
| davidcalle | mhr3_, I'm testing and it indeed works with an array on both, fine with me. Thanks :) | 15:49 |
| didrocks | sil2100: btw, this was the link (I hoped you took notes during the lectures) about the release process: it's explaining about staging vs doing the release: https://wiki.ubuntu.com/Unity/ReleaseProcess | 15:50 |
| sil2100 | didrocks: I was trying to, but not everything got noted down | 15:51 |
| didrocks | sil2100: please bookmark it then :) | 15:52 |
| sil2100 | didrocks: will do! :) | 15:53 |
| MCR1 | smspillaz: Are you here ? | 15:53 |
| didrocks | great :) | 15:53 |
| davidcalle | mhr3_, oh no wait : Quantal: TypeError: set_schema_full() takes exactly 2 arguments (5 given). The two errors are different on Precise and Quantal : Precise takes 3 args, Quantal takes 2 | 15:54 |
| sil2100 | didrocks: can I paste some branch links for you on priv to look at? Just to see if there aren't any visible mistakes I made in packaging | 15:54 |
| didrocks | sil2100: sure | 15:54 |
| sil2100 | didrocks: I say 'on priv' since it's like 7 branches, not to spam here | 15:54 |
| mhr3_ | davidcalle, set_schema(), not full | 15:57 |
| mhr3_ | but still, if they broke pygi, we'll need to fix the overrides | 15:57 |
| MCR1 | Can someone confirm that the mousebinding to maximize a window is gone, or is it just me again (CCSM->General Options->Key bindings->Maximize Window) ? | 15:58 |
| MCR1 | I used to maximize windows with Alt+Right Mousebutton, but that possibility seems to be gone... | 15:59 |
| davidcalle | mhr3_, yep, I'm trying with set_schema http://paste.ubuntu.com/1074988/ | 15:59 |
| mhr3_ | that's pretty nasty break, bad pygi! | 16:00 |
| mhr3_ | the syntax will be nicer now, but basically they broke every app that passes arrays via gi | 16:01 |
| davidcalle | mhr3_, just to be clear, when I say Precise and Quantal, what I truly mean is : rev 368 on Precise and 371 on Quantal | 16:02 |
| davidcalle | mhr3_, the set_schema_full('sssss') syntax works fine on 371. | 16:03 |
| mhr3_ | it's not about dee really | 16:04 |
| davidcalle | mhr3_, oh ok | 16:06 |
| sil2100 | davidcalle: you have a moment! | 16:18 |
| sil2100 | ? | 16:18 |
| sil2100 | davidcalle: I need this https://code.launchpad.net/~sil2100/unity-lens-videos/path_change/+merge/113426 <- merged into trunk as soon as possible | 16:18 |
| davidcalle | sil2100, seen it, I'm pushing in two minutes | 16:20 |
| sil2100 | davidcalle: thank you! | 16:21 |
| davidcalle | sil2100, it's in, yw ;) | 16:23 |
| === fenris is now known as Guest37369 | ||
| sil2100 | Ok everyone, it's time for me to cool down a bit, see you tomorrow for some more hot-and-spicy release action | 16:49 |
| sil2100 | Thank you for your cooperation <o | 16:49 |
| didrocks | see you sil2100 :) | 16:50 |
| popey | Anyone else noticed that you now have to double click twice to switch workspaces in the workspace switcher? | 16:59 |
| popey | (in quantal) | 16:59 |
| popey | well, you can gat that down to 3 clicks, click once on a workspace, then double click it to switch | 17:00 |
| === zyga-food is now known as zyga-afk | ||
| davmor2 | popey: 1 and then a double click here | 17:01 |
| popey | that needs a bug report | 17:01 |
| davmor2 | popey: there is no orange surround either | 17:01 |
| popey | no, it highlights in another way | 17:02 |
| popey | when you single click | 17:02 |
| popey | feel free to file a bug, I'll confirm :D | 17:02 |
| popey | (for the too many clicks thing) | 17:02 |
| MCR1 | you can switch workspaces with the right mousebutton now also (1 click then) | 17:03 |
| popey | golly | 17:03 |
| davmor2 | oh you can too | 17:03 |
| popey | thanks MCR1 | 17:03 |
| MCR1 | and a bug is fixed, so you can drag windows easier (it was not possible to drag them on the title bar) | 17:04 |
| popey | in unity 6, alt+f1 highlights bfb but keyboard navigation wont go down beyond nautilus | 17:05 |
| popey | might be a VM thing? | 17:05 |
| === dandrader|afk is now known as dandrader | ||
| smspillaz | MCR1: sporadically here, kidnda travelling all over the place | 19:26 |
| MCR1 | smspillaz: Hi. Nevermind, my problem has solved itself ;) Great job on Compiz btw., but I still hope we can get those "lost" plug-ins and especially animations back someday :) | 19:38 |
| MCR1 | smspillaz: Great to see you and Daniel optimizing and improving Compiz so much - I already was quite worried as I followed development on git, which was cooling down a lot. Compiz deserves at least one commit per day ;) | 19:40 |
| smspillaz | we moved to bzr a long time ago | 19:42 |
| smspillaz | well | 19:42 |
| smspillaz | I moved it to bzr because I was asked to -.0 | 19:42 |
| smspillaz | MCR1: I think we will merge in the other plugins once the work with gles2 and gsettings lands ... at the moment I can't really have any distractions | 19:43 |
| smspillaz | (as I was just given a very insane delivery timeline) | 19:43 |
| MCR1 | smspillaz: I did not get that move and it was not announced anywhere... | 19:43 |
| MCR1 | smspillaz: Sure. Take your time | 19:43 |
| smspillaz | MCR1: there are merge reviews up about it | 19:44 |
| smspillaz | MCR1: yeah ... I wasn't exactly around a lot | 19:44 |
| smspillaz | kept a low profile for a bit | 19:44 |
| MCR1 | everyone needs some time-out sometimes ;) | 19:44 |
| MCR1 | I would like to help more, but I still need to learn much, so I do what I can for now ;) | 19:45 |
| smspillaz | sure | 19:45 |
| MCR1 | at least it should help a bit if I do the conversion and prepare the merges | 19:45 |
| smspillaz | indeed | 19:46 |
| MCR1 | smspillaz: Once I get more understanding in how everything works, builds and merges together with Unity I will try to fix bugs also, for now I am keeping reporting them ;) | 19:49 |
| MCR1 | smspillaz: So please do not take my multiple bug reports filed against Compiz personally ;) | 19:50 |
| smspillaz | MCR1: of course not | 19:51 |
| MCR1 | ok. :) | 19:51 |
| smspillaz | I just might be a bit slow getting to some of the plugin merges over the next couple of weeks, is all | 19:51 |
| MCR1 | sure, no problem at all - I am happy if you get to those *some* day, even if it is months from now | 19:52 |
| smspillaz | :) | 19:52 |
| === dandrader is now known as dandrader|afk | ||
| htorque | hi all! i have a java application that rapidly opens and closes windows and from time to time the launchers connected to those windows get stuck (even when the application is shut down). is there anything i can do to prevent that from happening? | 20:49 |
| popey | htorque, how do you mean get stuck? | 20:53 |
| htorque | i got a launcher in the launcher bar for an application that does no longer exist. | 20:53 |
| popey | for a window that no longer exists? | 20:53 |
| htorque | yes | 20:54 |
| popey | is the application in the archive? | 20:54 |
| htorque | no, unfortunately not. | 20:54 |
| popey | and is the issue easily reproducable? | 20:54 |
| htorque | yes. | 20:54 |
| htorque | maybe i can write a short example that reproduces the issue and then report a bug? | 20:55 |
| popey | htorque, that would be great, I'd file the bug against bamf | 20:55 |
| popey | (at a guess from what you describe) | 20:55 |
| htorque | yeah, that was my guess too. :-) | 20:55 |
| popey | feel free to ping me when you've done it and I'll take a look | 20:55 |
| htorque | thanks, will do. | 20:56 |
| === dandrader|afk is now known as dandrader | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!