=== zyga is now known as zyga-afk [07:14] Hi [07:16] * sil2100 looks at unity trunk [07:17] I think we're ready for freeze [07:18] 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] didrocks: whenever you're ready [07:19] didrocks: (and hi! btw.) [07:19] sil2100: hey [07:19] sil2100: sure, doing :) [07:19] I will then proceed to some testing [07:20] sil2100: done [07:20] sil2100: all unity 6 stack is frozen [07:20] unity 5 can still build as usual [07:21] didrocks: thanks! [07:21] hw :) [07:21] You have the power [07:21] I do \o/ [07:26] Hi :) Does compiz version 1:0-9-8+bzr3249+bzr3278ubuntu0+3273 mean that all revisions up to r3278 are integrated ? [07:48] MCR1: yeah [07:48] kind of confusing naming, I know :) [07:52] didrocks: thx 4 the info, but bad news regarding bug 1012956 [07:52] 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] meaning, it's not fixed? [07:53] sry, bug 1011120 [07:53] 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] this is not fixed yet unfortunately [07:54] :( [08:02] 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] MCR1: should have an unity 6 release soon, isn't it sil2100? ;) [08:04] wow, cool. I am a bit worried about 51 branches waiting to merge to lp:unity though ;) [08:06] I'm as well [08:07] it's popey's team job to push them to get them reviewed now :) [08:08] ok, compiz bzr3278 should be good for a snapshot release to quantal according to upstream. I'll start preparing that. [08:09] Mirv: great! ;) [08:10] Mirv: Stack Window Switcher 8-) [08:12] Mirv, sil2100, you realize there's plugin abi break with latest compiz? [08:14] mhr3_: now I do, I only just started looking at it [08:14] and the delta between 3248 and 3278 [08:15] hmm, the screenshot plug-in is now completely broken ? Can someone confirm ? [08:17] sry, wrong observation - gnome-screenshot was not installed here... === Guest59153 is now known as kklimonda [08:42] didrocks: now that I think of it... hm, should I also bump the nux_abi_version? [08:42] Since Jay removed some functions from the headers [08:43] sil2100: well, he did it for the nux 3 ABI, right? [08:43] sil2100: it's not the same that the one in the distro [08:44] didrocks: he did a bump nux_api_version bump to 3.0, but nux_abi_version stayed the same [08:46] sil2100: it should have been bumped then [08:47] I'll bump it now [08:50] sil2100: ping me so that I ack the MR [08:52] 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] sil2100: please don't [08:52] sil2100: let the automerger doing the rebuild of packaging [08:52] and then rebuild of unity [08:53] So, I should do a MRQ for the "Releasing 3.0" commit? [08:54] no [08:54] you should just do a MR for the "bump ABI…" [08:56] didrocks: lp:~sil2100/nux/3.0_abi_bump [08:56] didrocks: requesting merge now [08:57] https://code.launchpad.net/~sil2100/nux/3.0_abi_bump/+merge/113352 [08:58] sil2100: I'm rejecting it, it's not necessary [08:59] 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] 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] that's not true [08:59] It's not? [08:59] the current ABI in the distro is Provides: libnux-abiversion-20120411.01 [08:59] sil2100: how did you check it? [09:00] Ah, shit... [09:00] Sorry about that [09:00] so, how did you check it? :) [09:00] I checked the current branch, and just saw that the date is 2-months old [09:00] it's not 2 month old [09:01] m4_define([nux_abi_version], [20120525.01]) [09:01] 1 month old ;) [09:01] even not 2 weeks old [09:01] what did you check? [09:01] seems it's not the right string you checked [09:02] and 20120525.01 != 20120411.01 (previous version in the distro), so we are fine [09:02] but I want to understand what you did check [09:02] 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] I just checked trunk, not the MRQ [09:02] My mistake [09:02] hum, trunk contains 20120525.01 already [09:02] Yes [09:03] so, it's 2 weeks old, nothing different between the trunk and the MRQ [09:03] as the MRQ diff is built upon trunk [09:03] 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] also, the current version in the distro is not 20120703 [09:03] but 20120411.01 [09:03] I know, damn, you just don't understand my reasoning here [09:04] 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] Ah, nevermind [09:04] It was my mistake anyway [09:04] sil2100: so please don't juts think, but *check* [09:04] Will do [09:04] thanks [09:05] didrocks: so how should we add the "Releasing 3.0" commit in nux now? [09:05] didrocks: since the version bump has been made already [09:05] sil2100: when everything is validated, this is a direct push to trunk [09:05] sil2100: but only do that when we upload the release [09:05] that, it's validated and such [09:05] k [09:05] that's why I normally use the package in the ppa for testing [09:05] and don't do a release [09:06] but you do it as you want :) [09:06] just be aware that you will have to redo everything if trunk isn't releasable [10:13] didrocks: during testing, should we test the new release on packages from quantal or quantal-proposed? [10:14] sil2100: quantal should be enough TBH, we don't have really impacting libraries in quantal-proposed right now === mmrazik is now known as mmrazik|lucnh [10:55] Trevinho: you around? [10:55] sil2100: yep === MacSlow is now known as MacSlow|lunch [11:30] Hi! Where is the list of icons in the launcher stored? === Trevinho is now known as Trevinho|lunch [11:54] hmmm, strange === zyga is now known as zyga-afk === zyga-afk is now known as zyga [12:30] Could someone please comment on bug 1019453 :) [12:30] 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:31] IMHO the launcher should not autohide once it is revealed until the pointer leaves the launcher (does not hover over the launcher area)... [12:32] didrocks: *sighs* we'll have to release a new tarball for bamf probably [12:32] sil2100: hum, why? [12:33] MCR1: please do not open a bug for that [12:33] MCR1: first, because it's surely a duplicate [12:33] MCR1: second because those discussions should go to the unity design ML [12:33] MCR1: a bug tracker is not a forum [12:33] didrocks: well, I could hm, try working this out through distropatches, but - one moment, since this story is quite long: [12:33] didrocks: I did not find anything regarding point 1 - it is clearly a bug [12:33] sil2100: I'm hearing what seems to be a fun story :) [12:34] MCR1: it's not, it's a design decision [12:34] and you are calling for people commenting [12:34] didrocks: & there have been endless discussions about dodge, but not intellihide [12:34] MCR1: dodge is intellihide [12:34] 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] no, dodge is window-dodge, intellihide is active-window dodge [12:35] didrocks: for instance, auto-generated files like bamf-marshal.{c,h} get inside, although these should be generated at build time [12:35] MCR1: it's still called dodge in the code [12:35] MCR1: I know it, I wrote it [12:35] Every good launcher/dock has such an option, which feels quite different than normal dodge [12:35] MCR1: what we called intellihide for us, and in the ccsm option is the window-dodge [12:36] 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] MCR1: and I don't care about that discussion, it should be discussed on the design ML, as told [12:36] MCR1, I can't confirm the issue there, the launcher doesn't hide while mouseovered [12:37] 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] didrocks, is it supposed to hide while the cursor is still over it by design? [12:37] seb128: no, this is separeted, i'm answering about the 2. === dandrader_ is now known as dandrader|afk [12:37] 1. seems a bug, but not reproducible to me [12:37] didrocks, ok, same here, thanks [12:37] didrocks: okay, I already joined the mailinglist, I will discuss it there [12:38] MCR1: thanks :) [12:38] MCR1: can you give more info about 1.? [12:38] MCR1, the bug can't be confirmed by anyone it seems [12:38] do you trigger anything specific to have it hidden with the mouse over? [12:38] 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] didrocks: anyway... should I still distro patch it ;)? [12:39] sil2100: no, do a release, and hide the symbols then in the debian/libbamf*symbols [12:39] (to do that I would have to remove some files from the distro branch and modify some Makefile.in's) [12:39] sil2100: or ask mhr3_ to do it, he loves that:) [12:39] didrocks: doing releases ;) ? [12:39] yeah [12:39] he's in the tarball business [12:39] mhr3_: my man! [12:39] not making a lot money of it, but still enjoying it :) [12:40] didrocks, seb128 - strange, I can reproduce 1 every time [12:40] mhr3_: Michal, my man! Hope you're not too busy? [12:40] MCR1, do you use unity 3d or 2d? [12:40] I did not change any Unity settings - 3d [12:40] mhr3_: I've got a mission of great importance ;) [12:40] MCR1: do you move the mouse? [12:40] MCR1: like, press super [12:41] put the mouse over the launcher and move it [12:41] then release super [12:42] didrocks: In that case the launcher stays visible [12:42] MCR1: so, what is exactly your test case to have it hidden? [12:43] 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:44] although the mousepointer hovers over it [12:44] MCR1: yeah, in fact, this is an artefact of another behavior [12:45] MCR1: like put the mouse in the launcher area (hidden) [12:45] press super [12:45] release super [12:45] it feels very wrong [12:45] the launcher will hide [12:45] this is because you didn't the mouse [12:45] so you don't want it to stuck [12:45] but I agree, in your case, it should staty [12:45] stay [12:45] IMHO the launcher should never autohide if the mousepointer hovers it [12:45] MCR1: it needs for the case I describe [12:45] like you pressed super by error [12:46] you don't want it to stick [12:46] or you pressed super + 3 [12:46] to switch to another application [12:46] hum [12:46] you dont' want it to stick as well, because the mouse was in the wrong area [12:46] but in your case, it's a bug [12:46] if it's been revealed by the mouse [12:46] it should stay [12:46] yeah [12:46] MCR1: mind updating the bug report with the details? [12:46] didrocks, can you confirm the bug? I can't here [12:46] ah, I didn't try [12:46] one sec :) [12:47] like pushing to reveal, move a bit, stop moving? === _salem is now known as salem_ [12:47] seb128: no, it's pushing to reveal, don't move [12:47] didrocks: no, ofc not, but the details are already there [12:47] didrocks, same, doesn't hide for me [12:47] yeah, same for me :/ [12:47] didrocks, but MCR1 said he moves some pixels [12:47] but in any case no way to reproduce it here [12:47] I do not need to move the mousepointer [12:47] it will need debugging by somebody having the bug [12:48] yep [12:48] if anything, it can be because of this code [12:48] but I can't reproduce this [12:48] IIRC, there was a protection for this particular case in fact [12:48] strange, I experience this behavior for a long time now [12:48] what input device do you use? [12:49] MCR1: did you change the "push to reveal" sensitivity? [12:49] not that I know [12:49] (although I probably have already changed every CCSM setting ;)) [12:49] try in a guest session? [12:50] ok will do [12:50] c y [12:51] seb128: my only bet is that the sensitivity is low as so the mouse "doesn't mouse enough" [12:51] could be yeah... [12:51] move* [12:51] having "always on" by default was a good choice ;-) [12:52] seb128, MCR1, didrocks; hyia, a bit late to the conversation, but is bug #745707 relevant to this conversation? [12:52] 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] seb128: I have autohide by default and happy with it :) [12:52] hehe [12:52] JohnLea: well a bit, but nobody reproduced 1. [12:52] JohnLea: 2. is the intellihide discussion and should happen on the design ML :) [12:53] mhr3_: piing [12:53] back... [12:53] Strange, the problem does NOT show in the guest session [12:53] Maybe it is because of my dualscreen config [12:54] I am just using the launcher on the primary monitor [12:54] didrocks; you mean nobody managed to reproduce the issue in bug #745707, or something else? [12:54] 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] JohnLea: right, nobody did [12:54] :-[ [12:55] I can make a video if you do not believe that it is happening here [12:55] didrocks; I have just reproduced the issue described in that bug, I'll attach a screencast [12:55] 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] sure [12:56] MCR1: but it seems it's a particular settings, right? [12:56] as you don't have it on a guest session [12:56] MCR1: gnome-control-center background [12:56] MCR1: behavior [12:57] is the sensitivity to the default? [12:57] sil2100: didrocks: hello [12:57] hey jaytaoko1 [12:58] jaytaoko1: hi! [12:59] hey didrocks, hello, could you ask Unity Merger to spin a new Unity package for Precise? [12:59] brb [12:59] c10ud: no, we only publish for quantal now [13:00] c10ud: we can't build on precise because of boost [13:00] ew, so no more updates for lts? [13:00] c10ud: well, this trunk :) [13:00] not what's for SRU [13:00] the SRU ppa is unity-team/sru [13:01] and there you have unity 5.0 builds for precise ;) [13:01] didrocks: is the freeze in effect? [13:01] (/!\ the transition between trunk and the sru ppa is not supported) [13:01] jaytaoko1: yeah, sil2100 asked me to do it this morning [13:01] 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] but it seems no email was sent to confirm it [13:02] c10ud: so no, no trunk for precise :) [13:02] ok thanks [13:02] yw, and sorry ;) [13:02] sil2100: how is the release going? [13:03] didrocks: sensitivity is default, this are the other settings: http://imagebin.org/219424 [13:03] jaytaoko1: slowly, I had some packaging/build problems with other packages - but nux and unity went in fine [13:04] no problem..anyway unity being locked to version 5 for precise (5yrs lts) is just weird, i must say (!) [13:04] sil2100: cool [13:05] 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] sup sil2100, you're quite lucky at pinging me during my lunch :P [13:05] c10ud: why? [13:05] c10ud: we never deliver new versions on stable release [13:05] c10ud: firefox is a special case [13:06] c10ud: we only provide stable release update, based on the version it as [13:06] has* [13:06] but don't add new features and so on [13:06] this is how you get stability :) [13:06] i thought unity fast and in-house development deserved a special place, but this is only my unexpressed though ofc [13:07] c10ud: well, it's like any other software [13:07] stability.. and bugs :p [13:07] c10ud: there are new build-dependencies [13:07] c10ud: we fixes bugs [13:07] backporting them will mean backporting crackful version untested [13:07] if you want the latest, use the latest available release :) [13:08] if you want stability, bug fixes, and support, use the LTS, but versions are frozen [13:08] nothing changed here from the past 8 years :) [13:08] i know, but consider this: the bug i'm interested in is poor performance with video (probably because of unity) [13:08] unless someone backports patches, i'm doomed [13:08] c10ud: we backported some poor performance fixes [13:08] and SRU them [13:08] we might SRU more, once sil2100 has finished with the release [13:09] if they are not risky [13:09] meaning, can bring more pain than benefit for all our users [13:09] yea i get it [13:09] it's just you mentioned "boost" and i thought "wtf" [13:09] 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] 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:10] c10ud: it's a library ;) [13:10] brb [13:10] you must admit it's not gobject [13:11] low level libraries don't change _that_ often, this is what i mean [13:11] and not being able to build unity-trunk in precise out of the box is..weird [13:11] anyway, not complaining here, just throwing thoughts [13:12] c10ud: I don't get you [13:12] c10ud: we are using features of the newer boost right now [13:12] 1.49 [13:12] which isn't available in precise [13:12] and soon, some 4.7 gcc specifics [13:12] depends on the new nux as well [13:12] so yeah, as those are not available in precise, and that we are targetting quantal, we build them on quantal :) [13:13] yeah, not sure we want people to handle the nux and compiz transitions [13:14] in my small yard (software) i tend to keep some backward compatibility [13:14] here you break 2 months after latest os release [13:15] well, we build for our targeted platform [13:15] and use the latest optimization possible for this platform [13:15] 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:16] but you really want, you can do a backport through ubuntu-backport [13:16] but the pile of dependencies to backport might be huge [13:16] well, i get is a choice, and mantaining stuff can be a PITA, it's just... 2 months [13:16] and unity seems pretty self contained [13:16] c10ud: there is not a lot of manpower though, we would love to support and bring backward compatibility :) [13:17] c10ud: if it's an area you are interested in, you are welcome to contribute there! [13:17] heh i know [13:18] anyway end of story is: this hard dep on new boost stops even setting up a personal ppa [13:18] unless you backport boost and then gcc47 (?) [13:18] c10ud: yeah, that's what I meant by "welcome to contribute" :) [13:18] weird stuff, but no problem accepting it ;) === Trevinho|lunch is now known as Trevinho [13:28] 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:30] MCR1: keep us in touch! [13:30] sure === MacSlow|lunch is now known as MacSlow === dandrader|afk is now known as dandrader [13:40] didrocks: hmm [13:40] didrocks: I've got another 'sticky-situation' ;) [13:41] didrocks: since ulm fails building a package due to test/assertions.vapi missing in the tarball [13:41] sil2100: water helps with sticky! :) [13:41] oh, who did that? [13:41] bad bad upstream [13:41] didrocks: now we have 2 options of fixing this (besides rolling-out a new tarball) [13:41] * didrocks runs :) [13:41] sil2100: you will have to roll a new tarball [13:41] I want upstream tarballs being cleaned [13:41] ...ok, this basically answers my question ;p [13:42] mhr3_: can you fix that in trunk and roll out a new tarball of ulm as well? ;) [13:45] who accepted this merge request, that's intolerable! [13:45] * didrocks whistles :p [13:50] didrocks, i call it automake bug, they changed the behaviour [13:51] and worst of all, distcheck passed [13:51] mhr3_: wow? so not me to be blamed so much :) [13:51] (I was totally ironic as it was my merge being the cause) [13:51] didrocks, well you of course as well, you didn't add the vapi to extra_dist in the first place :P [13:51] mhr3_: what automake did change? [13:52] ah, so you did that, make dist-check passed then [13:52] but it's not disted? [13:52] 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:53] but it still puzzles me how come that distcheck passed [13:53] mhr3_: so no more forced to patch the .c files \O/ [13:53] didrocks, i'm not keen on doing a new tarball afterall it's just make check that fails [13:53] and fixable with simple touch :P [13:54] mhr3_: well, this is a backportable commit [13:54] i'll add it to release notes though [13:54] sil2100: FYI ^ [13:54] ...so can I just do the debian/rules touch hack? [13:55] ;) [13:55] sil2100: yeah, but document it so that we remove it for next release [13:55] in debian/changelog [13:55] and add a // TOREMOVE [13:55] didrocks: ACK! [13:56] So now just BAMF remains... [13:56] Mirv: what's happening on compiz side? [13:57] wait wth, the tarball does have the stamp file [13:57] Well, it only works when I add the touch directly [14:00] Trevinho: how's the tarball-creation going? Any luck? [14:00] sil2100: it doesn't do make dist here... :o [14:00] libtool: link: cannot find the library `../../../lib/libbamf/libbamf3.la' or unhandled argument `../../../lib/libbamf/libbamf3.la [14:01] sil2100: ah, ok... found [14:01] Trevinho: you probably need to call make first? hm, it seems a bit broken? [14:01] Trevinho, i was going to do it, but since you're at it :P [14:01] sil2100: yes... that's the issue [14:02] mhr3_: you know what... ? I probably can't upload to lp as I don't have the rights on the project... [14:02] Trevinho, don't do just dist, ever! always distcheck [14:02] that's usual in dx project [14:02] mhr3_: could you then do it? You're more PRO in it than me and Trevinho - we apparently suck in creating tarballs :( [14:02] you need to call make before distcheck [14:02] Trevinho: ^ [14:02] mhr3_: yes, I did distcheck [14:02] didrocks, you mean gtk-doc using project :P [14:02] unity used to be that way [14:02] mhr3_: yeah ;) [14:02] mhr3_: I shortcuted it [14:03] Trevinho, ./autogen --enable-gtk-doc && make && make distcheck [14:03] mhr3_: but I think in that case, we should really make distcheck dep on make :) [14:03] 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] mhr3_: it's a long old 2 years old discussion in fact :p [14:03] didrocks, imo they should fix gtk-doc :) [14:03] Trevinho: ok ;) If only you're free and eager, thanks! [14:03] mhr3_: heh ;) [14:03] Trevinho, so should i do it? [14:04] that reminds me, i have one hanging patch in gtk-doc [14:04] mhr3_: if I can't upload... I think you should... [14:04] k, on it [14:04] mhr3_: you are taking a 10% charge, right? :) [14:04] mhr3_: but I'll push the change on bzr... [14:04] :P [14:06] mhr3_: I've just pushed bamf 2.2 on trunk... so grab that and do the tarball ;) [14:06]