| Controlsfreek | I'm looking at Bug #1099815, which seems to be a bitesize bug. I'm completely new to unity/nux. Trying to figure out the lifecycle of LauncherOptions. Is there documentation on how the options get populated (aside from their default values in the constructor)? | 02:32 |
|---|---|---|
| ubot5 | bug 1099815 in unity (Ubuntu) "Launcher starts with default size then jumps to configured one on login" [Undecided,New] https://launchpad.net/bugs/1099815 | 02:32 |
| Controlsfreek | Was expecting to see a function that loads values from a config file of some sort... | 02:33 |
| Controlsfreek | A nudge in the right direction would be much appreciated! Thanks | 02:34 |
| jrr | how might I make the top menu bar only display on my primary screen? | 02:54 |
| popey | seb128: seems unity in ubuntu-desktop/daily-build is broken today? | 09:37 |
| popey | i get no launcher or panel | 09:37 |
| popey | (morning btw) ☺ | 09:37 |
| popey | segfault in libunityshell.so | 09:38 |
| popey | [ 96.792983] compiz[2973]: segfault at 70 ip 00007f86ac6c291a sp 00007fff37a906a0 error 4 in libunityshell.so[7f86ac4ea000+409000] | 09:38 |
| davidcalle | popey, I can confirm | 09:39 |
| popey | thanks davidcalle | 09:39 |
| sil2100 | huh | 09:39 |
| duflu | popey: CLI; way of the future [tm] | 09:39 |
| * popey gets his VT101 out | 09:39 | |
| seb128 | popey, hey, I'm not running the daily ppa but seems you got people to confirm | 09:40 |
| * davidcalle was running trunk via unity-team/staging when it happened yesterday afternoon | 09:42 | |
| popey | davidcalle: do we have a bug filed for it? | 09:42 |
| davidcalle | popey, I wasn't sure if it was a driver or Unity issue, since the move to SNA was done at the same time. No bug yet AFAIK. | 09:43 |
| popey | I'm on nVidia | 09:44 |
| davidcalle | Intel for me | 09:44 |
| sil2100 | So maybe the latest commit? | 09:45 |
| popey | sil2100: can you take a look pls? | 09:46 |
| sil2100 | popey: will do | 09:46 |
| popey | thanks | 09:46 |
| sil2100 | davidcalle: you're using staging, right? | 09:48 |
| davidcalle | sil2100, not anymore, but I was indeed | 09:48 |
| * popey purges the ppa until fixed | 09:49 | |
| sil2100 | popey: what version did you use that was segfaulting? | 09:54 |
| sil2100 | Was it 6.12.0daily13.01.21-0ubuntu1 for unity? | 09:54 |
| popey | one mo | 09:57 |
| popey | no | 09:58 |
| popey | looks like from http://paste.ubuntu.com/1558044 that I installed 13.01.22 atr ~09:30 today | 09:58 |
| sil2100 | Oh, ok, so what versions did you use that were crashing? from daily0build? | 09:58 |
| popey | oh, no, hang on | 09:58 |
| popey | yes, 22 at 9:30 | 09:59 |
| popey | if I'm reading that grep of /var/log/dpkg right | 09:59 |
| popey | so i updated at 9:30 (my time in the logs) and saw the issue at 09:37, yes looks like 13.01.22 | 09:59 |
| sil2100 | Ok, so hm, there's no compiz update this day | 10:01 |
| sil2100 | Thanks, looking further | 10:01 |
| seb128 | sil2100, the segfault is in unity | 10:01 |
| seb128 | so doesn't need to be a compiz update | 10:01 |
| sil2100 | popey: is it segfaulting every time? Since the difference between 21 and 22 is just one build-related commit | 10:02 |
| sil2100 | popey: did you try 21 yesterday without any problems? | 10:03 |
| popey | yes, 21 was fine | 10:03 |
| sil2100 | Actually, nux might also be involved | 10:03 |
| popey | i had 21 installed and running when 22 was installing | 10:03 |
| popey | ran all day with 21 running fine yesterday | 10:03 |
| sil2100 | If there are some new commits of course... | 10:03 |
| sil2100 | Ok, testing something | 10:05 |
| sil2100 | popey: ok, so, try updating nux as well | 10:10 |
| popey | to what? | 10:10 |
| sil2100 | popey: it seems that there was probably some inside ABI break in the last big commit and unity deps didn't get updated | 10:10 |
| sil2100 | popey: to the one in daily | 10:10 |
| sil2100 | popey: since from your logs I didn't see nux getting updated | 10:10 |
| popey | i specifically grepped for unity | 10:11 |
| sil2100 | So, nux was 22 as well? | 10:11 |
| sil2100 | Since I experienced a similar segfault when having upgraded unity and compiz without nux | 10:12 |
| popey | one mo.. | 10:12 |
| sil2100 | But this might be a different case | 10:12 |
| popey | sil2100: http://paste.ubuntu.com/1558124 | 10:12 |
| popey | thats the full log from 20th to now | 10:13 |
| sil2100 | Ok, so it was there, interesting | 10:14 |
| sil2100 | popey: is it possible for you to use latest unity but revert nux to the previous daily? (18) | 10:18 |
| rperier | what is the module used to ask the Launcher what is the running app ? BamfApplicationManager ? | 10:18 |
| rperier | hey btw | 10:18 |
| popey | lets see | 10:18 |
| popey | sil2100: http://paste.ubuntu.com/1558193 - that works | 10:24 |
| sil2100 | popey: ok, so as I thought, nux is the problem - and the reason why I don't get the crash is probably that I'm using staging right now | 10:25 |
| sil2100 | popey: and it seems that there might have been a difference in what was built before what | 10:26 |
| sil2100 | hah, indeed! | 10:27 |
| sil2100 | libnux-4.0-common amd64 4.0.0daily13.01.18-0ubuntu1 | 10:28 |
| sil2100 | So, the problem is: | 10:28 |
| sil2100 | unity in the daily PPA has been build with nux 4.0.0daily13.01.18-0ubuntu1, which is the old one, after which the 22nd nux has been built - and in nux there seems to be some ABI break that requires unity to be built with the latest nux to work | 10:29 |
| sil2100 | So, because unity was built using old nux, and the daily PPA has the new nux in it, which is not compatible with unity built with the old nux, there is a crash | 10:29 |
| sil2100 | In staging there is no such problem because nux has been built there 18 hours ago and unity 5 hours ago, so unity was built using latest nux | 10:30 |
| sil2100 | How to fix that? Nux probably needs an ABI bump first of all | 10:30 |
| MCR1 | Hi :) I can confirm staging is still working on raring and the Dash flies with the new blur 8-) | 10:31 |
| MCR1 | Quality of the blur has somewhat regressed, but functionality and speed are much more important for the Dash | 10:32 |
| MCR1 | it was quite unusable with free gallium-radeon driver at least... | 10:33 |
| sil2100 | popey: now, I don't really have a clue how to fix the daily PPA... | 10:39 |
| sil2100 | popey: since the broken packages are already there, not sure if I can push anything to that place | 10:40 |
| seb128 | sil2100, you should be able to land an unity rebuild no? | 10:40 |
| sil2100 | seb128: I don't think I have any permissions for that PPA | 10:41 |
| seb128 | sil2100, should it autoland rebuilds if there are new commits? | 10:44 |
| seb128 | where is didrocks today? | 10:44 |
| sil2100 | seb128: not entirely sure how daily works, but I think it's only rebuilding per-day | 10:44 |
| sil2100 | seb128: so, since the last build was 6 hours ago, I think it will rebuild tomorrow at soonest | 10:45 |
| sil2100 | seb128: not sure, I was hoping he'll be around ;p | 10:45 |
| seb128 | he might still be jetlagged | 10:45 |
| MCR1 | speaking of the devil ;) | 10:54 |
| sil2100 | didrocks: my man! | 10:55 |
| didrocks | hey sil2100 | 10:55 |
| sil2100 | didrocks: how are you? | 10:55 |
| didrocks | jetlag apparently | 10:56 |
| didrocks | awaken from 1am to 4am | 10:56 |
| sil2100 | For everyone interested: https://code.launchpad.net/~sil2100/nux/bump_abi/+merge/144270 | 10:57 |
| MCR1 | didrocks: Hi :) Do you know why Unity is recommending the package "hud", there is no such package anywhere ? Is this some kind of joke ? | 10:58 |
| didrocks | MCR1: this package will come soon | 10:58 |
| didrocks | why would we put joke in the packaging? | 10:59 |
| MCR1 | ah, ok | 10:59 |
| MCR1 | I do not know - I was just wondering | 10:59 |
| sil2100 | It's an easter egg | 10:59 |
| sil2100 | We're waiting for easter to release it | 10:59 |
| sil2100 | It hatches then | 10:59 |
| sil2100 | ;) | 10:59 |
| MCR1 | It sounds good: Unity recommends using the hud ;) | 10:59 |
| rperier | the bug 692444 is still valid and need to be fixed ? I see "confirmed->Fix committed" and "fix committed -> confirmed" a lot of times | 11:00 |
| ubot5 | bug 692444 in nautilus (Ubuntu) "Launcher - clicking trash or device icons multiple times opens multiple instances" [Undecided,In progress] https://launchpad.net/bugs/692444 | 11:00 |
| sil2100 | rperier: let me check, but from what I remember it's still an issue | 11:00 |
| MCR1 | yes it is | 11:00 |
| MCR1 | rperier: Still valid | 11:00 |
| luv | I am planning to alter my unity to show list of windows when i right click an icon in the launcher - that is i can switch to the window I want based on it's windows title without going through the spread | 11:04 |
| luv | saves time and all | 11:04 |
| rperier | ok, as the trash is "hardcoded" into launcher/TrashLauncherIcon.cpp and executes "xdg-open trash://" directly, we could ask bamf to focus the window with the title "trash" (or ask the launcher to focus the window), what do you thing ? There is a module to do that easily in unity ? or I need to use bamf directly ? | 11:04 |
| luv | anyone would be interested in the patch or should i not bother and just keep it to myself? | 11:04 |
| sil2100 | rperier: hm, I think the best person to ask is Trevinho ^ | 11:05 |
| rperier | Trevinho: ping | 11:05 |
| luv | or have a look at BamfLauncherIcon.cpp how it is done there | 11:05 |
| sil2100 | luv: I would be interested in such a patch - what I would recommend is to send this to the design team for comment | 11:05 |
| sil2100 | luv: for instance, you could file in a bug that's targetting unity as Wishlist and ayatana-design, attach the branch there and wait for comment from the design | 11:06 |
| luv | sil2100: well, i'm going to get it done anyone for myself so i dont really need design team's comments i know what i want ;-) | 11:06 |
| rperier | lunch time, bbl | 11:06 |
| luv | i will put the bug on my github and see you guys link when im done and then you can take it from there | 11:07 |
| sil2100 | luv: it's not about modifying your approach, but getting to know if the unity design team would find it useful | 11:07 |
| luv | sil2100: right, i will do that when im done | 11:07 |
| luv | a bit of sarcasm here ... do i have to be subtle about the idea and make it seem they actually came up with it to make them accept it ;-) | 11:08 |
| luv | s/bug/patch/ | 11:09 |
| luv | anyway, im not comfortable just filing a bug (and wishlist for that matter) because in my experience it always leads nowhere (no hard feelings, that's just how it is ... and I have been told bunch of times to use ML or IRC) | 11:11 |
| === _salem is now known as salem_ | ||
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| rperier | before trying to solve the above bug, I am trying to install unity-trunk from 12.10 in $HOME/staging (so I need bamf 0.4) . bamf from trunk tries to install Bamf-3.gir into /usr/share/gir-1.0 and does not respect the $PREFIX variable | 12:14 |
| Trevinho | rperier: I've already done some nautilus work to get that working properly | 12:25 |
| rperier | The problem is the trash launcher does not call nautilus directly but xdg-open | 12:26 |
| rperier | so as long as xdg-open is used from the trash launcher, the solution should work for all files managers compatibles with xdg-open and should not be specific to nautilus . Except if you plan to call "nautilus trash://" directly | 12:30 |
| rperier | imho | 12:30 |
| rperier | however, I am still a beginner, I could be wrong | 12:30 |
| Trevinho | rperier: well, caliing that is ok to me... Relying on windows name is not a proper solution, I'd prefer to fix nautilus since it's what we use | 12:34 |
| rperier | ok, so that's probably better for me to find another bug in this case, no ? (if the fix is in nautilus and not in unity...) | 12:36 |
| seb128 | Trevinho, what you mean "fix nautilus"? | 12:37 |
| === MacSlow is now known as MacSlow|lunch | ||
| didrocks | seb128: I think he meant "exposing the tabs through a dbus API" or something like that | 12:50 |
| didrocks | like location path… | 12:50 |
| seb128 | didrocks, oh, ok | 12:51 |
| rperier | Trevinho: If the problem is mostly on the nautilus side, does unity need to be fixed or not ? | 13:03 |
| === dandrader is now known as dandrader|lunch | ||
| rperier | well, I will find another bug, because apparently the previous one is still under discussion and I am probably not the good person to work on it ;) | 13:56 |
| rye | uhm, i can reproduce flickering in dash on my acer aspire one device | 14:00 |
| rye | ah, sorry, ubuntu-x, not here - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1100970 | 14:01 |
| ubot5 | Launchpad bug 1100970 in xserver-xorg-video-intel (Ubuntu) "transparent dash background flickers on intel graphics" [Undecided,Incomplete] | 14:01 |
| === MacSlow|lunch is now known as MacSlow | ||
| rye | however, it looks like dash blur "overlay" is rendered too low and too to the left here - https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1100970 - added unity task too | 14:15 |
| ubot5 | Launchpad bug 1100970 in xserver-xorg-video-intel (Ubuntu) "Dash background flickers and blur is misplaced on intel graphics" [Undecided,Confirmed] | 14:15 |
| didrocks | sil2100: if you bump abi, you need to have unity deps on the new nux version | 14:35 |
| didrocks | otherwise, in the ppa, unity will maybe still build against the previous nux | 14:36 |
| didrocks | mterry: nux is always breaking its ABI, we have something similar to compiz to handle that | 14:36 |
| didrocks | mterry: basically, this file is stripped down and generate a virtual provides: | 14:36 |
| didrocks | see Provides: libnux-abiversion-${nuxabiversion} | 14:36 |
| didrocks | and it's using that string in debian/rules to generate the right version | 14:37 |
| didrocks | then, when building against nux | 14:37 |
| mterry | didrocks, ah, OK thanks | 14:37 |
| didrocks | we have a similar thing in debian/rules to see against which nux we built against | 14:37 |
| didrocks | and dep against that | 14:37 |
| didrocks | not stellar, but no good other way when upstream keeps breaking the ABI | 14:37 |
| didrocks | mterry: however, as told to sil2100, to ensure next daily-build is working, we need to ensure unity build-dep until nux is built | 14:38 |
| didrocks | mterry: can you ensure we get that dummy merge bumping the version in? | 14:38 |
| mterry | didrocks, sure. sil2100 , have you started working on that? | 14:39 |
| sil2100 | didrocks: ok! | 14:45 |
| sil2100 | mterry: I'm working on it right now | 14:47 |
| didrocks | sweet | 14:47 |
| mterry | sil2100, alright, I'd be happy to do the review when you're done | 14:47 |
| sil2100 | didrocks: so a dummy empty merge is enough? | 14:56 |
| didrocks | sil2100: hum? no, you need to bump the build-dep for the next day ppa build | 14:57 |
| sil2100 | didrocks: ah, yes yes ;) I wasn't thinking when I was asking that it seems | 14:58 |
| didrocks | :) | 14:58 |
| didrocks | better to ask before anyway ;) | 14:58 |
| didrocks | ping me if you have issues to identify what versionning you should put here | 14:59 |
| didrocks | mterry: maybe you already know the rule btw ^ | 14:59 |
| mterry | didrocks, not off the top off my head. I imagine SONAME gets bumped and the day will be incremented | 15:00 |
| mterry | didrocks, so libnux-4.0-1 with a version of the next daily build? | 15:01 |
| didrocks | mterry: no, the binary packages statys the same (as we don't version ABI changes thanks to this provides:) | 15:04 |
| didrocks | let's see with which version numbers comes in in his MP and then we can discuss :) | 15:04 |
| sil2100 | My branch is open to discussion ;p | 15:06 |
| mterry | didrocks, oh I misunderstood how the magic happened then. You're saying the magic is on the consumer (unity) side? | 15:07 |
| didrocks | mterry: yeah, we need to tell unity to build after nux | 15:08 |
| didrocks | as both are built at the same time, uploaded to the ppa | 15:08 |
| didrocks | sil2100: ok, that was a nice try :) | 15:08 |
| didrocks | https://code.launchpad.net/~sil2100/unity/unity_bump_nux_deps/+merge/144324 | 15:08 |
| didrocks | sil2100: but in fact not! | 15:08 |
| sil2100 | ! | 15:09 |
| sil2100 | :) | 15:09 |
| didrocks | theorically it's fine, for the daily release :) | 15:09 |
| didrocks | BUT | 15:09 |
| didrocks | we need first to pass the jenkins merger | 15:09 |
| didrocks | which doesn't have this version | 15:09 |
| didrocks | so we'll get a rejection | 15:09 |
| sil2100 | uh, right | 15:09 |
| didrocks | so we need to use the version which corresponds to that change in the staging ppa | 15:09 |
| sil2100 | Well, I was thinking we could get this merge in tomorrow, but this would mean a one-day lag that's probably not necessary... | 15:09 |
| sil2100 | Oh, ok | 15:10 |
| sil2100 | Ah, indeed, since it's using daily + bzr revision | 15:10 |
| didrocks | sil2100: so, the version is not that important, bu you can put: 4.0.0daily13.01.18bzr752 | 15:10 |
| didrocks | even if it's not exact by one commit :) | 15:10 |
| didrocks | anyway, distro won't have that one | 15:11 |
| didrocks | it will get 4.0.0daily13.01.23 as you invocated | 15:11 |
| mterry | didrocks, I know why we need to bump unity, I meant the magic of calculating which version is which ABI is happening on the unity side? I guess I'm confused by what you said happened automatically when the ABI was bumped | 15:11 |
| didrocks | and 4.0.0daily13.01.18 < 4.0.0daily13.01.18bzr752 < 4.0.0daily13.01.23 | 15:11 |
| didrocks | so we are good | 15:11 |
| sil2100 | Yes, but I see compiz anyway has something like that, since they're compatible | 15:11 |
| didrocks | mterry: oh, that's separate, yeah, let's finish then and I'll reexplain :) | 15:11 |
| didrocks | that* | 15:11 |
| didrocks | sil2100: yeah, for compiz, it was a day when I just triggered a rebuild | 15:12 |
| didrocks | (of unity) | 15:12 |
| didrocks | sil2100: mterry: I'm still opened to the discussion on the fact we can avoid that btw | 15:12 |
| didrocks | like autobumping automatically everyday the build-dep on what's part of the stack | 15:12 |
| mterry | didrocks, but the daily build has 01.22 | 15:12 |
| mterry | didrocks, not .18 | 15:13 |
| didrocks | urgh? | 15:13 |
| didrocks | mterry: ah, daily ppa you mean | 15:13 |
| mterry | didrocks, yeah | 15:13 |
| didrocks | mterry: yeah, but this one was never published | 15:13 |
| mterry | didrocks, oh... | 15:13 |
| didrocks | it failed because of the ABI breakage | 15:13 |
| didrocks | mterry: https://jenkins.qa.ubuntu.com/view/cu2d/view/Unity%20Head/ | 15:13 |
| didrocks | see this beautiful red :) | 15:13 |
| mterry | didrocks, OK | 15:14 |
| mterry | didrocks, and if it had gotten released, the staging would have based its bzr suffixes on .22 anyway | 15:14 |
| didrocks | mterry: yep | 15:15 |
| didrocks | mterry: kenvandine: btw, I was thinking that we can have a google hangout on how to monitor those dailies now that they are working | 15:15 |
| kenvandine | didrocks, hey yeah we should | 15:15 |
| didrocks | I was thinking like in 45 minutes from now, but on Thursday | 15:15 |
| didrocks | does this work for you? | 15:15 |
| mterry | sure | 15:15 |
| kenvandine | wfm | 15:16 |
| didrocks | excellent | 15:16 |
| didrocks | let me try to schedule this on our calendars | 15:16 |
| didrocks | robru and cyphermox ok'ed that time | 15:16 |
| didrocks | mterry: kenvandine: I won't be around next week, so you will have to look closely to the releases ;) | 15:17 |
| didrocks | sil2100: btw, tell me once you did the change :) | 15:18 |
| didrocks | sil2100: approved | 15:25 |
| didrocks | mterry: FYI ^ | 15:25 |
| didrocks | mterry: so on the nux ABI thingy | 15:25 |
| didrocks | mterry: this string is used to generate a virtual package | 15:25 |
| mterry | cool | 15:25 |
| didrocks | libnux-core-<date> | 15:25 |
| didrocks | we extract the date from the file in debian/rules from nux | 15:26 |
| mterry | yup like libnux-abiversion-20121204 | 15:26 |
| mterry | ok | 15:26 |
| didrocks | and when generating with dh_gencontrol the control file, we inject it | 15:26 |
| mterry | but unity doesn't use it? | 15:26 |
| didrocks | yep :) | 15:26 |
| didrocks | unity uses it | 15:26 |
| didrocks | so this string ends up in a header | 15:26 |
| didrocks | that libnux-dev installs | 15:26 |
| sil2100 | didrocks: thank you! | 15:26 |
| didrocks | sil2100: yw, thank to you :) | 15:27 |
| didrocks | in unity debian/rules we do something similar | 15:27 |
| didrocks | NUX_ABIVERSION := $(shell sed -rn 's/^\#define[[:space:]]+NUX_ABIVERSION[[:space:]]+//p' /usr/include/Nux-4.0/Nux/ABI.h ) | 15:27 |
| mterry | k.. | 15:27 |
| didrocks | and in debian/control we dep on libnux-core-<date> | 15:27 |
| didrocks | that we inject with dh_gencontrol -- -Vcoreabiversion=$(CORE_ABIVERSION) -Vnuxabiversion=$(NUX_ABIVERSION) | 15:27 |
| didrocks | (coreabiversion is the misnamed compiz one) | 15:28 |
| MCR1 | \o/ seems we got a working Compiz Firepaint GLES port ! | 15:28 |
| didrocks | mterry: making more sense? | 15:28 |
| mterry | didrocks, so all consumers of nux have to do that? | 15:29 |
| didrocks | mterry: right, "all" being one… unity | 15:30 |
| mterry | didrocks, (and that would normally mean we don't have to manually bump unity's dep version like we just did -- but we had to because we used the new blur API?) | 15:30 |
| didrocks | mterry: all compiz consumers have the same thing too (it was the plugins before) | 15:30 |
| didrocks | mterry: yeah, theorically we don't need to bump it, but the new blur API forced us to | 15:30 |
| didrocks | mterry: I'm still open to a discussion on autobumping the build-dep automatically everyday for what is part of the stack | 15:31 |
| didrocks | it's theorically wrong, but TBH, should we really care? | 15:31 |
| mterry | didrocks, not sure. It's not like we make it possible to backport to previous releases anyway (i.e. we don't need the deps to be accurate to help other people doing a backport) | 15:32 |
| didrocks | mterry: yeah, the question is in practice, do we really backport only part of the stack? | 15:33 |
| mterry | didrocks, but that means that if part of the stack has a problem (like nux did), it will stop other parts of the stack | 15:33 |
| didrocks | mterry: most of the time, we need to backport everything within the stack | 15:33 |
| didrocks | mterry: I have no strong opinion TBH, if we have this kind of issues too often, I guess this is a possible workaround | 15:35 |
| === dandrader|lunch is now known as dandrader | ||
| === mmrazik is now known as mmrazik|afk | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| Trevinho | seb128: any idea why my compiz vsize/hsize parameters are set back to old default values when I change them from ccsm? bschaefer has the smae | 20:56 |
| Trevinho | same* | 20:57 |
| seb128 | Trevinho, no idea no | 21:23 |
| === salem_ is now known as _salem | ||
| === lborda_ is now known as lborda | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!