[01:48] Does gnome-shell not work with lightdm? I've been running gdm, so hadn't noticed. What's the interface that it's looking for? [02:01] AfC, well, I am currently running g-s with lightdm on ubuntu no problems, but the newest g-s (3.5.5 I think?) landed a tremendous amount of changes where they start using gdm to handle their screen lock. Presumably this is to allow people to switch users when the screen is locked, without having to duplicate a huge amount of user-switching code from gdm in the screen locker. it's just unfortunate that GNOME are insisting on gdm [02:01] instead of choosing something more universally interoperable like lightdm. IMHO GNOME and KDE and everything else should just adopt lightdm as standard. [02:16] robru: "x should just adopt y" when y is years newer than x and x is a part of the X project doesn't really fly as a compelling argument for the X people. [02:17] robru: I do know the GNOME people are trying really hard to get the login screen and lock screen integrated; from a user experience perspective they are the same thing, but technically they are at opposite ends of the stack. Makes it tough [02:18] robru: I'm glad to see them being innovative, though; this one has been begging for a change for a long time [02:18] AfC, hey man, GNOME and KDE managed to unify on DBus (dropping corba and dcop in the process), so one can hope that there might be other cases of unification going on on the desktop ;-) [02:18] robru: right: that was both sides consciously making a decision to work together in co-operation. That's different that an upstart coming along saying "I'm better, use me instead" [02:19] AfC, so how do we convince them to consciously decide to work together? [02:19] ;-) [02:19] robru: it may well be better, but that's besides the point. [02:19] AfC, I'm not actually bothered which is better, I just like lightdm because it's not tied to any one system. [02:20] The Canonical engineers decided they wanted to do something that the GDM codebase couldn't support; the GDM developers have been doing what they do for a long time and have a reasonably good idea of how to set up the pre-conditions for the window manager to take over. [02:20] AfC: as far as I know, all DMs used to work for any desktop environment so this is a change [02:21] you could use kdm to log into gnome or any other combination [02:21] jbicha: I always thought that was silly; In Gentoo if I was running KDE I'd use kdm; if GNOME gdm. There are significant environment assumptions, and it was obvious the idea of supporting foreign desktops was unrealistic because the subsequent code would rely on those assumptions [02:21] [without realizing it] [02:22] it's ridiculous to have to change your login manager just because you want to try a different desktop [02:22] {shrug} I have to reinstall the entire system if I want to try fedora. So not "rediculous" at all [02:22] AfC: that's what kvm/virtualbox are for... [02:23] jbicha: [not saying you're wrong or that it wouldn't be nice to have, just that in practice I've never observed zero coupling between dm and wm [02:24] * micahg has used xdm, lightdm, kdm, and gdm with various desktops in the past without issue [02:24] AfC: the problem is that I have Unity installed and want to install gnome-shell; there's no easy way to make gnome-shell depend on a user actually using gdm as default [02:25] we could hack lightdm to blacklist gnome-shell but that's still going to confuse people when it worked just fine in 12.04 [02:26] I think robert_ancell is right that ideally, gnome-shell should fallback if gdm (or a gdm-like dm) isn't being used [02:56] HOW IS IT 10 PM? I have been working for 15 hours. [03:00] g'night ;-) [04:52] does anyone else have a problem with skype on quantal? [04:52] I get a complete laptop lockup when using skype video [04:52] can't switch to a VT [04:52] nothing [04:52] hard reset needed [05:04] thumper: Works for me. What video card? [05:05] Mobile Intel® GM45 Express Chipset [05:07] bonjour [05:07] smspillaz: I added some more concrete information to bug 1042041; seems I can reproduce this fairly reliably now with every startup [05:07] Launchpad bug 1042041 in compiz "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,Confirmed] https://launchpad.net/bugs/1042041 [05:08] thumper: Huh. Works with my sandybridge. Fun. I don't suppose it generates an apport log? [05:09] RAOF: nope [05:09] Of course not. :( [06:35] Hello [07:08] good morning everyone === larsu_ is now known as larsu [07:29] ogra_: there would be one ARM build of compiz to try out: http://people.canonical.com/~tjyrinki/compiz/compiz-0.9.8.0-armhf.tar [07:35] yay, rain! === chrisccoulson_ is now known as chrisccoulson [08:00] hey desktopers [08:02] pitti: thanks, I'll get on ot it soon [08:09] hey smspillaz, pitti [08:12] hi seb128, how are you? [08:14] chrisccoulson, hey, still no rain? ;-) [08:14] chrisccoulson, I'm good thanks, how are you? [08:14] seb128, yeah, it's raining today. but my 3G is working too ;) [08:14] hehe [08:14] does the phone quality goes down with the rain as well? [08:15] seb128, it's difficult to tell. we've got a cordless handset which does noise reduction [08:15] chrisccoulson, nice to see firefox 15 already in precise-securityr! [08:15] but there is a bit of noise when it rains [08:15] k [08:15] i need to go out and get myself a cheap corded handset at some point [08:15] i'm not even sure you can buy them anymore, can you? ;) [08:28] seems it started with the last update, debian/patches/git_scale_click.patch [08:29] weird, that's a trivial patch in the slider callback [08:29] * larsu is afraid this channel will be French-only soon [08:29] larsu, that's the plan, duolingo your french back! ;-) [08:29] he folks, who is our intel graphics driver person? [08:29] larsu: tu vas apprendre le français :) [08:29] thumper, not an assigned person, RAOF is probably eod at this point, try tjaalton [08:29] pitti, are you sure that's the problem? I get "invalid cast from `GtkImage' to `U1MusicStore'" right before the rhythmbox segv [08:29] thumper, or #ubuntu-x [08:29] larsu: no, I'm not [08:29] larsu: currently fixing the apport hook, then I can report it [08:30] larsu, pitti: I'm pretty sure it's the u1-rb-store update from yesterday [08:30] pitti, cool, me too :) [08:30] pitti, try uninstalling the store? [08:30] seb128: sounds likely, yes [08:30] pitti, I'm not learning french on duolingo yet. Will be next, after I master Spanish. *cough* [08:30] * pitti purges unity-scope-musicstores along [08:30] larsu, you need to sort out your priorities! [08:30] seb128: c'est ça! [08:31] pitti, merci larsu [08:32] rb apport hook fix committed to bzr, FYI [08:32] pitti, what was the issue? [08:32] - report.add_package_info("rhythmbox-ubuntuone-music-store") [08:32] + report.add_package_info("rhythmbox-ubuntuone") [08:32] :) [08:32] haha === tkamppeter_ is now known as tkamppeter [08:51] resurrected bug 691736 [08:51] Launchpad bug 691736 in libindicate "Can not take screenshot while indicators are open" [Undecided,Confirmed] https://launchpad.net/bugs/691736 [08:51] reproducible in precise & quantal [08:52] I hate it when people reopen fixed bugs [08:52] new ones are better :) [08:52] but that may just be me [08:52] xnox, it's a duplicate of an ancient ancient ancient bug [08:53] seb128, ping [08:53] seb128: not sub 100k? [08:53] ritz, hi [08:53] thumper, sub 11k :p [08:53] seb128 hi, wrt https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/734428 . Is it possible to push this for oneiric and precise ? [08:53] Ubuntu bug 734428 in df-libreoffice "[Upstream] Wrong automatic text color "dark grey" with black background (dup-of: 628105)" [Medium,Confirmed] [08:53] wow [08:53] Ubuntu bug 628105 in df-libreoffice "[Upstream] Text not black in LibreOffice" [Medium,Confirmed] [08:53] thumper, xnox: bug #10905 [08:53] Launchpad bug 10905 in unity "Keyboard shortcuts, window management - Can't use any global keyboard shortcuts or hotkeys when applet/menu is open" [Undecided,Confirmed] https://launchpad.net/bugs/10905 [08:54] seb128: omg =) [08:54] thumper, xnox: it's a xorg limitation [08:54] menus need to do grabs to work [08:54] that's stupid [08:54] which block keybindings [08:55] ritz, I doubt we will do any other oneiric libreoffice upload ... can you ask to Sweetshark for precise,quantal? [08:55] seb128, thanks, will do [08:55] Sweetshark, ^^^ [08:56] ritz, he's our lo maintainer and the one who commited that patch upstream [08:56] hmmm, [08:57] sweet [08:57] ogra_, hey [08:59] ogra_, can you get https://launchpad.net/~unity-team/+archive/release/+files/compiz_0.9.8.0-0ubuntu1%7Etest2.dsc copied to your arm ppa? hopefully it restores armel gles builds [09:04] pitti, chrisccoulson, larsu, others: did you also get whoopsie errors about the photo lens today when using the dash? [09:04] do you have the photo lens installed? (I just realized we didn't seed it yet) [09:04] seb128, /me doesn't have a photo lens [09:04] no whoopsie report in /var/crash [09:04] ignore that question :p [09:05] nobody has it installed, that's probably why we didn't see lot of reports [09:05] thanks [09:05] seb128: je ne ai pas un lens de photos [09:05] seb128: should I install it? [09:05] ritz: might get backported to quantal, but I am currently stuffed with work. as for precise: once it it in quantal and somebody (ricotz usually) does a backport. [09:06] seb128: "je n'ai pas ..", almost :) [09:06] hmmm [09:06] pitti, ;-) [09:06] seb128: can it search through tags? [09:06] pitti, no need to, it will be seeded soon, it's waiting on security review for the MIR [09:09] Sweetshark, hi, i will try to get to it at some point, having 12.04.1 out makes it not that important to do lucid/natty/oneiric though [09:09] pitti, not at this point, davidcalle says he didn't find a python3 exif parser he can use [09:09] err, no exif? [09:09] that doesn't sound very useful [09:10] seb128: do lenses need to be written in python? [09:10] pitti, the lens does collect,browse your g+,picasa,facebook,etc photos [09:10] pitti, but tags and events. Exif is here for Flickr and Picasa. [09:10] pitti, no they don't, the files,app,etc are written in vala [09:10] pitti, it's up to the lens writer to pick the language [09:11] ah, so maybe vala and libgexiv2-dev might work? [09:11] merci [09:11] pitti, well, the photo lens is already written in python... [09:12] davidcalle, you should call to robru [09:14] davidcalle, he's into photos and works on a python geotagging app, he added introspection to gexiv2 (the lib used by shotwell for exiv) that landed upstream [09:14] nice! [09:14] davidcalle, I think you should be able to just use those bindings, we should have a look to make that land in quantal [09:14] seb128, ooh, that would be nice! [09:14] I was just searching for "gir exiv" and didn't find anything [09:14] pitti, https://github.com/robru/gexiv2 [09:16] pitti, davidcalle: http://git.yorba.org/cgit.cgi/gexiv2/commit/?id=b8da1516e83f3e9200157277785c655b6815edf9 [09:16] in fact [09:16] davidcalle, I will get you that in quantal so you can use it [09:17] seb128, that would be great, ty! [09:17] yw! [09:55] hmmm, going to attempt to switch back to my home connection again, now it's not raining ;) [09:59] did llvmpipe / compiz landed? The daily quantal image works really, really well in the VM! [09:59] or did KVM somehow gain 3D acceleration (very much doubt that) [10:00] xnox: compiz was fixed to avoid teh screen corruption under llvmpipe [10:01] ah awesome =) [10:01] xnox: well, "really well", it's rather slow [10:01] but at least it's usable [10:01] I always give my VMs 2048MB of RAM and it's faster than unity-2d for some things I do [10:02] e.g. dash responsiveness === MacSlow is now known as MacSlow|lunch [11:12] seb128, i copied it, but it still wants to only build for x86 machines ... [11:12] * ogra_ pulls the source to take a look [11:13] ogra_, do you know why? I'm sure I'm overlooking something stupid :-( [11:13] no, but i'm pullinbg the package right now, let me take a look [11:13] ogra_, there is a bug in the .install Mirv was supposed to fix like 3 hours ago, not sure what's happening there [11:14] Mirv, still on that .install fix? [11:14] 3 -> 1 [11:14] seb128, well, looks more like the PPA doesnt understand the control file or so [11:14] it doesnt even list any arm in the build attempts of the PPA UI [11:15] ogra_, is that a PaS stuff? or whatever is called the override that define archs for a source? [11:15] shouldnt [11:15] but who knows what went wrong during the DC move :) [11:15] do you have other sources building on arm? [11:16] or did you just get arm turned off for that ppa? [11:17] seb128: wasn't that <1h ago ;) running a build to check that it builds with those plugins disabled, but how'd you handle the fact that they would still build on x86? [11:17] hmm, quite a lot of Arch: all binaries in there :) [11:17] ah 3->1 [11:18] compiz itself is arch:all ? [11:18] ogra_: compiz is just a meta-package [11:18] ah, k [11:18] well, the "any" ones should be picked up ... [11:19] so these would be the plugins not to try to install on arm: http://pastebin.ubuntu.com/1173645/ [11:20] and I'm running one such build atm [11:23] seb128, so i see that there were arm builds for quantal in that PPA, but not actually after the DC move ... i'll bug IS [11:39] seb128, yeah, was a PPA issue ... starting over now [11:44] ogra_, great [11:44] Mirv, yeah, sorry I though we figured out that issue earlier in the day :p [11:44] hmm, but it seem to not be able to re-copy it [11:44] sigh [11:45] ogra_, well, the .install is buggy anyway... [11:45] if i had built it locally i would have been done now :/ [11:45] ogra_, do you know how to do arch specific .installs? [11:47] seb128, i think i didnt that in precise in compiz-plugins-main ... let me look [11:47] ogra_, thanks [11:47] debian/compiz-plugins-main.install.armhf ... debian/compiz-plugins-main.install.armel [11:48] Mirv, ^ [11:48] just add an arch suffix [11:48] dh_install should cope [11:48] ogra_, I guess that's used instead of the .install on those arches? [11:48] but the .install is still used otherwise? [11:48] * ogra_ checks the manpage ... its a while ago :) [11:50] hmm [11:50] you could bump compat to 9, and make install file an executable which produces required output when run [11:50] then you have environment variables and you can do stuff like [11:51] find & grep -v out what you don't want on armel/armhf, but keep the rest [11:51] on all other arches [11:51] well, the arch suffix works but i cant seem to find docs about it [11:51] well for me, it's the first time I hear about it. [11:51] somewhere in the "Black Magic" section of debhelper manpage? [11:52] xnox, the "easy" way is to list the common files in the .install and add a cp for the extra ones in the rules for !arm* [11:52] but that breaks things like dh_install --list-missing [11:53] yeah =/, or instead rm after dh_install [11:53] seb128, well, given it will just cost us an extra upload to check and given that its unlikely to break x86, lets just do it and check [11:54] looking at https://launchpadlibrarian.net/100425594/compiz-plugins-main_1%3A0.9.7.0~bzr19-0ubuntu8_1%3A0.9.7.0~bzr19-0ubuntu9.diff.gz the install.$arch files dont have any extra hacks in the build system [11:55] so we'll see if .install is still used on arm arches [11:55] ogra_: yeah it does do that, see pkgfile function in /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm [11:55] awesome [11:55] seb128, so it shouldnt cause any probs [11:56] looks like that works for all debhelper files [11:56] no idea about compat levels though.... probably since beginning of time? [11:56] that is interesting to know! [11:56] ogra_: that's totally new to me, nice if that works. I now put such a thing in one PPA, sources at http://people.canonical.com/~tjyrinki/compiz/compiz-arm-test4.tar [11:56] no compat checks there [11:56] yeah. Definately should be documented. [11:56] Laney, but bad that its not documented, i dotn even know how i got to use it anymore :) [11:56] heh [11:56] file a joeyh bug [11:57] * xnox ponders if git blame says ogra_ committed that to debhelper [11:57] oh no, it is documented [11:57] where?! [11:57] In some rare cases, you may want to have different versions of these files for different architectures or OSes. If files named [11:57] "Launchpad encountered an internal error during the following operation: copying a package. It was logged with id OOPS-fb7f4c65721e6b180a344c8e4be802ae. Sorry for the inconvenience." [11:57] debhelper(7) [11:57] https://lp-oops.canonical.com/oops.py/?oopsid=fb7f4c65721e6b180a344c8e4be802ae [11:57] lovely [11:57] debian/package.foo.ARCH or debian/package.foo.OS exist, where ARCH and OS are the same as the output of "dpkg-architecture [11:57] -qDEB_HOST_ARCH" / "dpkg-architecture -qDEB_HOST_ARCH_OS", then they will be used in preference to other, more general files. [11:57] ah, but finally it builds [11:57] seb128 / ogra_: or lp:~timo-jyrinki/compiz/gles_arm_install_fix [11:58] let's see if it finishes [11:58] * xnox FTRTFM - Fail To Read The Fine Manual [12:02] nice that the feature is generic, ie any file can be appended with .ARCH [12:04] that same diff above also has code to add this support to quilt patches btw [12:04] thats actually something non-std i hacked in [12:21] Mirv, ping me once you uploaded it and i'll copy it over to the arm builder [12:21] (looks good btw) [12:32] ogra_: in ppa:unity-team/release again [12:32] building on arm as well already [12:34] uh, how ? [12:34] I managed to do one build run with cut down .install that naturally failed on amd64/i386, but I got the following on ARM: dh_install: usr/share/cmake-2.8/Modules/FindOpenGLES2.cmake exists in debian/tmp but is not installed to anywhere [12:34] oh, you mean locally ? [12:34] ogra_: I've access to one PPA that has it [12:34] but that should be covered by compiz-dev.install, so I'm puzzled [12:34] oh, ok, could you just copy the resulting binaries into the unity ppa then ? [12:34] ogra_: see above, still not there although got past the plugins [12:35] i have a working qunatal GLES setup with the PPA in the souces and can just quickly test once its ready [12:35] *quantal too [12:36] I'm now running a build on a local arm machine as well, it's annoying one can't login to nearly-build sources at the PPA:s... [12:36] (obvious, but annoying;) [12:36] Mirv, maybe the fact that there is a .armel you need one for each .install [12:37] Mirv, like trying to copy compiz-dev.install to compiz-dev.install.armel etc? [12:37] seb128: ouch.. messy, but maybe has to be done then. would explain the issue. [12:38] that's a bit weird though, I would expect it just use the normal one if it doesn't find a specific for the arch [12:38] Laney, xnox: ^ what is your understanding? [12:39] yeah I think that is what happens [12:39] it's not surprising that fail-missing fails if you aren't installing all of the files [12:39] Laney, well I would assume that compiz-dev.install is used if there is no compiz-dev.install.armel [12:39] it's a bit stupid to have to dup all the .installs [12:39] yes [12:39] that's what I'm saying happens [12:40] hum? [12:40] but it doesn't install that file any more? [12:40] seems not from the issue Mirv described [12:40] usr/share/cmake-2.8/Modules/FindOpenGLES2.cmake this one [12:40] right [12:40] it's listed in compiz-dev.install [12:40] wouldn't it have been removed from compiz-dev.install to the arch specific one? [12:40] so why is dh_install --fail-missing stopping on it? [12:41] Laney, that's the diff: http://bazaar.launchpad.net/~timo-jyrinki/compiz/gles_arm_install_fix/revision/3283 [12:46] one sec, X just restarted [12:46] hmm, actually that build log I copy-pasted from was the one where I just cut away stuff from the compiz-gnome.install === MacSlow|lunch is now known as MacSlow [12:47] either way, I don't understand why that'd happen, but let's see if the test4 build has the same failure [12:51] Mirv, on what archs did test3 failed? [12:55] it finished on the x86 arches at least [12:59] seb128, Hello, I have merge proposal ready for review for nux and unity in precise, a rename of libutouch-geis to libgeis. However, the renamed libgeis is still in the precise upload queue. Is there anything I can do proactively to get the MPs reviewed, or am I just blocked until the uploads make it into the archive? [13:00] fginther, hey, we should get the lib first in the archive I think ... do you have a bug open to track those changes with the ubuntu-release team subscribed? that will probably need to go through them [13:01] seb128: the test3 I had failed on all, but on amd64/i386 obviously because I removed the plugins that those archs still had (I just wanted to test arm build first before this .ARCH proposal came) [13:02] Mirv, ok, where are testing now? [13:03] hiya [13:03] did you see the news on vmware rewriting bosh in go and redesigning it to be just like juju? [13:03] heh, ww [13:04] seb128, Yes, LP: #1037621 with the SRU team subscribed [13:05] sabdfl, hey, how are you? I didn't read that yet, juju ftw! ;-) [13:05] fginther, looking [13:06] fginther, precise was frozen for some time due to 12.04.1 so it's not surprising that didn't get traction recently [13:06] fginther, try maybe mentioning it on #ubuntu-release? [13:06] seb128, thank you! [13:06] seb128: so test4 i386/amd64 finished already, arm build on-going in a separate ppa [13:07] hey seb128, yeah, pretty funny [13:07] and juju's looking better and better [13:08] great ;-) [13:10] Mirv, yep, test2 just failed in the canonical-arm-dev PPA on armhf too :) [13:10] funny that you cant delete packages from a PPA if tehy are still building ... [13:11] ogra/seb: ok just in that the test4 failed on arm for the same FindOpenGLES2.cmake complaint as on test3, while the amd64/i386 finished succesfully. there is yet another build ongoing with all .install files having the .armel/.armhf variant.. [13:11] but there is something fishy, since the test3 didn't have any variants, just one that was suited for arm specifically [13:11] ogra_, is there any way you could do a local build and look at that? [13:11] and compiz-gnome shouldn't affect compiz-dev.. [13:12] seb128, well, i can try at least :) [13:12] got a link to this PPA build? [13:12] test4/arm [13:12] ogra_: yes, please, you most probably have better ARM hardware that I'm now (barely) running the build on :) https://launchpad.net/~unity-team/+archive/release/+files/compiz_0.9.8.0-0ubuntu1%7Etest4.dsc [13:12] Laney: ^ [13:13] Mirv, yep, my mx6 will build in half the time than a panda [13:13] Mirv, the bug log he meant I guess [13:13] well, I want to see the diff and the build log where it fails [13:13] but it doesnt have a build env atm so it might take just as long with setting it up :) [13:14] I would have a look, but setting my pandaboard to build compiz and starting I would be done tomorrow [13:14] Laney: I can't link to it directly but here's the end part of the log: http://pastebin.ubuntu.com/1173775/ [13:15] Mirv: and which package is it supposed to be installed into? [13:15] seb128, well, slangasek wants me to do a hangout session for setting up your panda :) [13:15] you should attend ;) [13:15] yeah, for sure [13:15] heh [13:15] does unity work again yet? :P [13:15] Laney, compiz-dev [13:16] Laney, on panda ? [13:16] yeah [13:16] Laney, on arm? that's what we are trying to solve here with that compiz build :p [13:16] no, thats why we are trying to build compiz right now :) [13:16] hence my skin in the game here ;-) [13:16] i'm just done with the driver, GLES should work OOTB with our next panda image [13:17] erm, [13:17] now just the desktop is missing ;) [13:17] so the .install has this: [13:17] debian/tmp/usr/share/cmake*/FindOpenGLES2.cmake [13:17] dh_install: usr/share/cmake-2.8/Modules/FindOpenGLES2.cmake exists in debian/tmp but is not installed to anywhere [13:17] from the build log [13:17] hi! where's the right place to ask about the Ubuntu wallpaper? I would like to update the LDM (ltsp login manager) login theme for this cycle and ui freeze is upon us :) [13:18] Laney, ogra_, Mirv: oh, it's the rules [13:18] ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH), $(gles2_architectures))) [13:18] ... [13:19] ... cp cmake/FindOpenGLES2.cmake ... [13:19] else [13:19] no that [13:19] fi [13:19] "cp cmake/FindOpenGLES2.cmake debian/tmp" [13:19] is only done in the non gles case in the rules [13:19] so move that line to .install.armhf [13:19] debian/tmp/usr/share/cmake*/FindOpenGLES2.cmake [13:20] i mean [13:20] (and .armel indeed) [13:20] ogra_, no, the .install are fine, I think the rules is the issue, though I'm unsure why it special case gles for that cp [13:21] well. let me drop these lines ad do a test build [13:22] seb128, hmm, do we actually build GLES on x86 too ? [13:23] (i think its needed for poulsbo support) [13:23] s/do we/should we/ [13:23] ogra_, no, duflu said we should only enable it on arches that don't support GL [13:24] * ogra_ has no idea if poulsbo can do GL though :) [13:24] seb128: ... [13:24] but yeah, understood [13:25] I don't see it [13:26] it looks like it is only done in the gles case (the first branch) [13:26] line 56? [13:26] Laney, right, I'm trying to understand why [13:26] but how is it that the file is already included in compiz-dev? [13:27] so it seems to me like the .install is wrong as I pointed [13:27] indeed it probably isn't harmful to just install the .cmake file all of the time? [13:27] ah.. compiz-dev has without the /Modules/ and on GLES architecture it copies it also to under there? [13:27] right [13:28] but you can't have it in compiz-dev.install as it wont be there on non-GLES architectures [13:28] why not just have the cp put it in place right away? [13:28] ++ [13:28] thats what i just did [13:28] yeah, I don't know the history behind that hack [13:28] (in my local copy) [13:28] but that seems fine to me [13:28] still installing build-deps here though [13:28] well it already _is_ there on non-GLES architectures, the copy of the same file just isn't under /Modules/, and I have no idea why eg. the FindCompiz.cmake is already duplicated [13:29] Mirv, just drop the && cp cmake/FindOpenGLES2.cmake ...? [13:29] like keep the second case for all arches? [13:29] * ogra_ just added an if test -e ....;then cp ... fi ... to rules [13:30] seb128: in other words remove the whole if clause? [13:30] ogra_, Laney: ^ what do you think? [13:30] does cmake expect it in /Modules/? [13:30] dunno [13:31] I've no clue about cmake [13:31] I would either copy it straight there in the first branch [13:31] or get rid of the if and make all arches have it in /Modules/ [13:31] straight there → debian/compiz-dev/.../Modules/ [13:31] well, the make install seems to installs it already? [13:31] the file is there on i386,amd64 [13:32] since the .install works [13:32] just drop the gles2_architectures case of that if and always do what was done on non gles arches? [13:33] it doesn't explain why it's clearly aimed for that there is both cmake*/FindOpenGLES2.cmake and cmake*/Modules/FindOpenGLES2.cmake, and why there already is cmake*/FindCompiz.cmake and cmake*/Modules/FindCompiz.cmake (copy of the same file) in compiz-dev [13:33] since I don't understand, I'd create compiz-dev.install.arm{hf,el} adding the extra copy... [13:33] doing that just for one file seems to be overkill [13:33] Mirv, yes, please do that and let sort it out with duflu,sam after those release landed [13:34] wait for ogra_ to verify his fix since it sounds right [13:34] ok [13:34] ogra_, can you pastebin the diff of your fix? [13:34] sure [13:36] seb128, http://paste.ubuntu.com/1173816/ somethin like that [13:37] ogra_: it doesn't solve the actual install phase problem where the .install doesn't (yet) have double FindOpenGLES2.cmake files? [13:37] ogra_, you duplicate the "cp cmake/FindCompiz.cmake ..." there? [13:37] mine looks like this http://paste.ubuntu.com/1173819/ [13:38] oh, right [13:38]