[11:13] <mano_> hello, i have uploaded my pacakge to my ppa in launchpad,but it doesn't appear there?
[11:15] <geser> did you got a email that it got accepted or rejected?
[11:16] <geser> see also https://help.launchpad.net/Packaging/UploadErrors
[11:17] <wgrant> mano_: That usually means that you haven't signed the changes file with a key associated with your Launchpad account.
[11:21] <mano_> ok, the problem was in the KEY, now he is telling me  that my key is pending validation , who shall do that?
[11:23] <geser> you, if I'm not mistaken (I've registered my key long time ago) you should get an encrypted(?) mail from LP to the email address on your key
[11:24] <mano_> when verifying my key with the email the have been sent to me from launchpad, i got: There is 1 error.  Launchpad could not verify your signature: (7, 58, u'No data')
[11:24] <mano_> what shall i put in "Signed text: "?
[11:25] <wgrant> mano_: You need to decrypt the email with your key
[11:26] <wgrant> Or sign the provided text, if you have a signing-only key.
[11:31] <mano_> lets start from begian, i have  a Fingerprint and a Key type/ID in my email from launchpad, what shall i do now?
[11:43] <mano_> what i only need to know now is what shall i put in the "Signed text: " when importing the Openpgp key to launchpad?
[11:48] <wgrant> mano_: Does the page not say "Please paste a clear-signed copy of the following paragraph into the box beneath it."?
[11:50] <mano_> i did that already, but because it is saying after that: There is 1 error.  Launchpad could not verify your signature: (7, 58, u'No data')
[11:51] <mano_> i am asking :)
[11:51] <wgrant> mano_: You need to paste the entire signature, including the "BEGIN PGP SIGNED MESSAGE" and "END PGP SIGNATURE" lines.
[11:52] <mano_> here: There is 1 error.  Launchpad could not verify your signature: No signatures found
[11:52] <wgrant> How did you generate the signature?
[11:57] <mano_> how to make a secret key?
[11:57] <wgrant> Don't you already have one?
[11:57] <wgrant> You entered the fingerprint earlier.
[11:59] <wgrant> Have you been following https://help.launchpad.net/YourAccount/ImportingYourPGPKey?
[12:02] <mano_> ok, now i am at step 6, i have the email, there is a fingerprint and a key/id , and there is a link, what shall i do now?
[12:02] <wgrant> Click on the link.
[12:03] <mano_> ok
[12:03] <mano_> it open a page :"Confirm sign-only OpenPGP key"
[12:03] <mano_> there is a big box, what shall i put in it?
[12:04] <wgrant> The page tells you what to put it in, and there is a help link.
[12:04] <mano_> yes but i didn't understand from it, my english is bad,
[12:05] <wgrant> The help link has an example, showing the commands you need to enter and what things should look like.
[12:06] <wgrant> Click the blue "How do I do that?" link.
[12:06] <mano_> the "Copy the confirmation text from the Launchpad page" is that 'Please register ABCDEF... to the Launchpad user joe 2005-04-01 10:30:42 UTC'?
[12:07] <wgrant> Yes.
[12:07] <wgrant> Except with your fingerprint, username, and today's date.
[12:08] <wgrant> You'll see it in a paragraph under the help link.
[12:08] <mano_> ok i did that, now i am at help step 2, when using the command it give: gpg: no default secret key: secret key not available gpg: key: clearsign failed: secret key not available
[12:10] <wgrant> Use "gpg -u XXXXXXX --clearsign FILENAME", where XXXXXXXX is the key ID or email address corresponding to the fingerprint that you gave to Launchpad earlier.
[12:12] <mano_> i did that many times, bue as i said the command  give: gpg: no default secret key: secret key not available gpg: key: clearsign failed: secret key not available
[12:13] <wgrant> Does "gpg --list-secret-keys" show anything?
[12:13] <Mkaysi> How does one convert bug report as security issue?
[12:14] <Mkaysi> And is "makes anyone able to crash the computer anywhere" enough reason for security issue?
[12:14] <mano_> wgrant: yes i give me
[12:14] <mano_> it give me*
[12:15] <wgrant> mano_: Have you tried specifying that email address as the XXXXXXX in the command above?
[12:15] <wgrant> Mkaysi: You can click the edit icon to the right of the "This report is public" at the top right of the page.
[12:16] <wgrant> Mkaysi: There you can set whether the bug is public, private, a security vulnerability, etc.
[12:16] <Mkaysi> Oh, I didn't look there. Thanks :)
[12:16] <mano_> yes i di
[12:16] <mano_> i did*
[12:16] <Mkaysi> Oh and is answer to that second question "yes"?
[12:16] <wgrant> Mkaysi: Best to be safe.
[12:16] <Mkaysi> Do I take that as yes?
[12:17] <wgrant> Yes.
[12:17] <Mkaysi> Ok :)
[12:19] <wgrant> mano_: In the --list-secret-keys output you'll see a line like "sec    1234A/12345678". Take the 8 letters and numbers from after the /, and put them in place of the XXXXXXXX above.
[12:21] <mano_> so it last is shall be like that?' gpg --clearsign 12345678 'or what?
[12:21] <wgrant> mano_: gpg -u 12345678 --clearsign FILENAME
[12:21] <wgrant> Replacing 12345678 and FILENAME with the correct values, of course
[12:23] <mano_> ok, now he say: You need a passphrase to unlock the secret key for .....
[12:24] <wgrant> Enter the passphrase you entered when you created the key.
[12:24] <mano_> yesssssssssssssssss!!!
[12:24] <mano_> it worked! :D :D :D :D :D :d
[12:25] <wgrant> Great.
[12:28] <mano_> ok, now i have uploaded the package to the repo, but it is not showing there?
[12:31] <wgrant> mano_: It can take a few minutes to show up.
[12:33] <mano_> OK :D
[13:00] <mano_> back agian, i have uploaded a package to my ppa but it don'y appear in it
[13:10] <geser> still?
[13:11] <geser> have you checked if you have signed the _source.changes files with the right key (the one you just activated)?
[15:20] <mano> hello, when launchpad try to build my package it give me an error, after doing some commands on my computer i got this after using dpkg-buildpackage: error: debian/rules build gave error exit status 2
[16:36] <RobinJ1995> How do I create and maintain a PPA?
[16:36] <RobinJ1995> and what are its advantages over a classic debian repository?
[16:40] <dobey> integration with launchpad and ubuntu
[16:46] <RobinJ1995> dobey, what integration?
[16:46] <RobinJ1995> "Launchpad could not import your OpenPGP key"....
[16:58] <dobey> RobinJ1995: your key has to be on keyserver.ubuntu.com for lp to find it
[17:26] <RobinJ1995> dobey, what's with this encrypted email.... if there goal was to make it way too hard for the average user to perform, they've succeeded
[17:27] <RobinJ1995> honestly, what a mess
[17:29] <dobey> RobinJ1995: what encrypted email?
[17:32] <RobinJ1995> dobey, the one you get after importing your pgp key
[17:34] <RobinJ1995> security's fine by me, but they're really exagurating now
[17:34] <dobey> making sure you are you doesn't seem too difficult for the average user
[17:34] <RobinJ1995> it is in launchpad's way
[17:36] <RobinJ1995> The confirmation instructions have been
[17:36] <RobinJ1995> encrypted with the OpenPGP key you have attempted to register. << great... no what? i'm not going to download and setup a special mail client just because they need to use some way too complicated encryption technology
[17:37] <dobey> you're using a mail client that doesn't do pgp?
[17:37] <RobinJ1995> gmail
[17:38] <dobey> there's firefox extnsions to do encrypted mail on gmail
[17:38] <RobinJ1995> it also says that the project is discontinued and that it's likely not to work anymore
[18:09] <Mkaysi> Was there documentation about Launchpad email interface somewhere?
[18:10] <Mkaysi> RobinJ1995: I would suggest installing Thunderbird and Enigmail for easy encrypted message decryption if you don't want to use GPG directly.
[18:22] <RobinJ1995> Mkaysi, not going to install anything because their security is impssibly stupid
[18:23] <RobinJ1995> security? fine. this? nah, i'll stick with a normal debian repo
[18:50] <soren> I thought we didn't need GPG signatures when sending from gmail anymore?
[19:58] <dapal> would someone please remove en_GB and en_CA from wicd on LP? TIA
[20:23] <tbf> is there a good way for using code repositories at launchpad with git?
[20:24] <jelmer> tbf: you can have launchpad import git repositories into  bzr branches
[20:29] <tbf> jelmer, no. i really don't want to give up git
[20:30] <tbf> jelmer, actually canonical's tutorial quite nicely summarizes the reasons: http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html#design-differences
[20:33] <dapal> tbf: (..not leaving LP is the only reason why I'm using bzr instead of git for wicd)
[20:33] <dapal> really, I develop using git, then I do git → bzr locally, and push bzr over to LP
[20:33] <dapal> (and the git repo to github)
[20:33] <dapal> meh
[20:34] <tbf> dapal, sounds error prone. do you have tools supporting you?
[20:34] <dapal> tbf: git bzr
[20:34] <dapal> (and bzr-git)
[20:35] <dapal> tbf: honestly, one could also have a .bzr and a .git in the same directory. The .git would be listed in the .bzrignore, and the other way around for .bzr
[20:35] <dapal> but then, you have to double-commit each time
[20:35] <dapal> (yes, one could even write a wrapper to that, but sounds nasty at least)
[20:36] <tbf> dapal: well, guess you'd only have to update the .bzr folder when pushing changes
[20:36] <tbf> hmm... but keeping the .bzr folder and the .git folder at the same place sounds like an interesting approach to avoid some confusion
[20:36] <tbf> dapal, got something to play with
[20:37] <dapal> nice to hear^Wread :)
[20:37] <jelmer> tbf: there is an open bug about supporting git on launchpad
[20:38] <dapal> jelmer: do you know the bug number? I was looking for it, but google didn't help :/
[20:38] <tbf> jelmer, after all github, bitbucket, ... seem to make a few bugs with git. wondering why canonical doesn't want that money
[20:38] <dapal> jelmer: (I remember someone there [in the bugreport] saying "if you want, go patch there")
[20:39] <jelmer> dapal: bug 651844
[20:40] <dapal> thanks jelmer, but this wasn't the bug I remembered :D
[20:40] <dapal> seems nice though, a git-bzr proxy hosted at LP-level
[20:40] <dapal> so LP keeps bzr, while the world outside can use bzr/git
[20:40]  * dapal reads the report
[20:41] <jelmer> dapal: or perhaps you mean bug 648635?
[20:42] <dapal> jelmer: neither. I remember seeing a bug about "native" git hosting on LP
[20:42] <dapal> thanks for the pointers though!
[20:46] <jelmer> dapal: perhaps bug 292557 then ?
[20:46] <jelmer> I don't see any other (historical) bugs related to git
[20:47] <tbf> hmm?
[20:47] <dapal> jelmer: seems that one, thanks!
[20:47] <tbf>        git-remote-bzr - Git remote support for Bazaar repositories
[20:47] <tbf>        This command provides support for using bzr repositories as Git remotes, through the bzr-git plugin. At the moment it supports cloning from, fetching from and pushing into Bazaar repositories. Fetch support is still experimental, and may be slow.
[20:47] <tbf> dapal, have you tried this thing?
[20:47] <dapal> tbf: uh, no. I should :)
[20:48] <dapal> (maybe with some test project though, I don't want to break wicd for this)
[20:49] <jelmer> tbf, dapal: that is still experimental, it's not really ready for actual production use
[20:49] <tbf> jelmer, do you know what's missing?
[20:49] <tbf> actually this looks exactly like the tool for losing my griefs
[20:50] <tbf> ok, one i found:
[20:50] <tbf>  git branch -l
[20:50] <tbf> * (no branch)
[20:50] <tbf> :-)
[20:51] <jelmer> tbf: that's correct, there is just a HEAD branch
[20:56] <jelmer> tbf: wrt completeness, I mostly got git-remote-bzr working as a hack
[20:57] <jelmer> it works fine for basic operations, but can't handle a lot of (common) corner cases
[20:58] <tbf> jelmer, guess i am still going to test drive it.
[20:58] <tbf> jelmer, expect bug reports and patches.
[20:59] <tbf> (considering the idea itself has legs)
[20:59] <tbf> (s/considering/assuming/)
[21:02] <tbf> ok. "git clone bzr::lp:unity" fails...
[21:02] <tbf> bzrlib.errors.NoSuchFile: No such file: 'unityutils.h-20091217140958-pnjcwi4blgy8odsl-1'
[21:07] <jelmer> tbf: yep, that's one of the issues you can encounter
[21:09] <tbf> jelmer: "bzr fast-export | (cd /tmp/unity && git fast-import)" ?
[21:10] <tbf> ah. no. this needs a local bzr repo
[21:15] <jelmer> tbf: that also doesn't allow contributing back to bzr afaik
[21:15] <tbf> jelmer: still this maybe shows the algorithm needed for successfully importing a bzr repo
[21:16] <jelmer> tbf: how do you mean?
[21:17] <tbf> jelmer: apparently this fast import/export format somewhat works for converting repos
[21:18] <jelmer> tbf: for converting it works, but contributing back to bzr is harder I think
[21:18] <tbf> jelmer: so maybe this file format and the related tools show how to import bzr repos into git
[21:18] <tbf> 'k


[00:03] <holstein> awesome
[03:41] <grkblood13> how do i edit a single vob file with multiple chapters
[11:55] <paradoxuncreated> Does someone know packages for newer rtkernel than what is in the repository?
[17:44] <zorn^^> once i have the vst ardour version, how can i load a vst instrument?
[20:09] <paradoxuncreated> Does anyone feel like testing a mastering limiter plugin (first linux compile :))  http://www.paradoxuncreated.com/Pxu/amp.so
[20:24] <jussi01> paradoxuncreated: probably a good idea to provide the source to that if you can, makes it so much more trustable.
[20:24] <jussi01> paradoxuncreated: Unfortunately I cant do it here, as Ive only got my work machine
[20:27] <paradoxuncreated> https://sourceforge.net/projects/pxu/
[22:37] <torasuku> I can't burn an Ubuntu Studio DVD anytime soon, can I use the Ubuntu Live CD to install Ubuntu, and then install US repos?
[22:41] <holstein> hey torasuku
[22:42] <holstein> !vanilla
[22:42] <holstein> you just need a few metapackages from the standard repos
[22:42] <holstein> if you fire up synaptic
[22:43] <holstein> and search ubuntustudio
[22:43] <holstein> you can find the packages, with descriptions
[22:43] <holstein> or apt-cache search
[22:47] <torasuku> holstein, thank you very much! I bought DVD-Rs instead of +Rs so I can't burn the ISO file yet :[
[22:48] <holstein> i usually install that way
[22:48] <holstein> if you need the real time kernel
[22:48] <torasuku> What way?
[22:48] <holstein> there is a couple more things you need to do
[22:48] <holstein> torasuku: i do the vanilla upgrade, instead of installing ubuntustudio from the DVD
[22:49] <holstein> !grub2
[22:49] <holstein> you'll need to mess with grub2
[22:49] <holstein> to be able to see the grub menu
[22:49] <holstein> and choose the RT kernel
[22:49] <holstein> other than that, its very straight forward :)
[22:50] <torasuku> holstein, you mean change it to boot using the rt kernel instead of the regular one?
[22:50] <holstein> if you want to you can
[22:50] <holstein> i think the default behavior for grub2 is
[22:50] <holstein> for the menu to be hidden
[22:50] <holstein> SO, installing linux-rt
[22:51] <holstein> will install it
[22:51] <holstein> but, you'll still be booting into the generic one
[22:51] <torasuku> Right on, thank you very much, and I will be back in when I get vanilla Ubuntu installed.
[22:51] <holstein> cool


[08:32] -BottyMcBotFace:#ubuntu-news- ::Softpedia:: Debian Linux Was the Most Vulnerable Operating System in the Last 20 Years @ https://news.softpedia.com/news/debian-linux-was-the-most-vulnerable-operating-system-in-the-last-20-years-529387.shtml (by Bogdan Popa, Microsoft News Editor)
[15:00] -BottyMcBotFace:#ubuntu-news- ::Planet:: Dustin Kirkland: Working from Home -- Lessons Learned Over 20 Years and Shopping List @ http://blog.dustinkirkland.com/2020/03/working-from-home.html (by<EMAIL_ADDRESS>(Dustin Kirkland))
[19:55] <Bashing-om> UWN: Pulling "WIP" - only one minor edit to be made yet noted.
[20:18] <Bashing-om> UWN<EMAIL_ADDRESS>is away - doing the forum post next.
[20:18] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: New Version of gThumb Released with Misc Changes, New App Icon @ https://www.omgubuntu.co.uk/?p=165398 (by Joey Sneddon)
[20:26] <Bashing-om> UWN: Forum post done - no issues seen. Doing the re-directs.
[20:38] <Bashing-om> UWN: re-directs done: pending is the social medias.
[21:28] <guiverc> Bashing-om, okay to push 621 to fridge?
[21:29] <Bashing-om> guiverc: Glad you are awake :D .. Yup . push to the Fridge - I am not aware of any issues.
[21:31] <guiverc> http://fridge.ubuntu.com/2020/03/09/ubuntu-weekly-newsletter-issue-621/
[21:33] <Bashing-om> UWN: Fridge spot check checks good.
[21:33] <Bashing-om> guiverc: Clear now to wipe Gdoc ?
[21:35] <guiverc> yep..  tweet done
[21:43] <guiverc> fb post done too
[21:44] <Bashing-om> guiverc: Wiping Gdoc.
[21:49] <Bashing-om> And we do UWN622 :)
[21:57] -BottyMcBotFace:#ubuntu-news- ::Planet:: The Fridge: Ubuntu Weekly Newsletter Issue 621 @ http://fridge.ubuntu.com/2020/03/09/ubuntu-weekly-newsletter-issue-621/


[09:17] <Mirv> didrocks: wasn't it so that you rejected http://bazaar.launchpad.net/~compiz-team/compiz-core/0.9.7/revision/3111 from precise SRU in the summer, and thus it should be reverted in the 0.9.7 branch as well?
[09:17] <Mirv> I'm not sure if I remember right
[09:17] <Mirv> it's not very useful patch anyway for SRU
[09:17] <didrocks> Mirv: yeah, it's not really useful, if it's not in precise, you should revert it
[09:18] <Mirv> didrocks: thanks, doing that, and yes it's not yet in precise and now won't be
[09:18] <didrocks> thanks Mirv ;)
[09:44] <Squarism> i have this issue with unity on ubuntu 12.04 that i cant reassign "semi-maximize". Should i give up or IS there a solution, yet hard to find?
[09:47] <Squarism> please people.. gimme a hint atleast
[10:04] <philipballew> Squarism, hey
[10:05] <philipballew> If noone helps you here, askubuntu is good, or #ubuntu
[10:07] <Squarism> philipballew, thanx man
[10:09] <philipballew> Squarism, not a problem,
[14:11] <mpt> conscioususer, hi, what's up?
[14:17] <conscioususer> mpt: hi, I needed some guidelines on the sensitivity of menuitems, when the menubar is shared between different windows
[14:18] <conscioususer> https://wiki.ubuntu.com/MenuBar gives me some cases, but not all
[14:18] <mpt> conscioususer, I suggest you set up a parent model that makes sensitive the items that make sense regardless of which window is focused
[14:19] <mpt> Choosing some of those items might involve focusing, or even opening, a window that isn't focused right now
[14:19] <conscioususer> mpt: oh, that part is actually already coded, it's the "make sense" part I need to understand
[14:19] <mpt> conscioususer, what's the easiest way for me to see your current/intended menu structure?
[14:20] <mpt> daily PPA, branching trunk, or something else? (I'm running 12.10)
[14:20] <conscioususer> mpt: some cases are obvious.. quit is always sensitive, about too... preferences shouldn't be sensitive when you're on the preferences window
[14:20] <conscioususer> mpt: I have a branch suitable for 12.10, but the menus are actually incomplete... I thought I could start with some general guidelines
[14:21] <mpt> conscioususer, so Preferences would be sensitive normally, and the Preferences window would make it insensitive
[14:22] <conscioususer> mpt: it's cases like "refresh" that I'm not sure about... the effects are only visible on the main window, but I don't see why the user should be forbidden to do it from the settings window
[14:22] <mpt> conscioususer, yes, that's an example of an item that would focus the main window, and open it if it isn't open currently
[14:22] <conscioususer> mpt: and focus if it's open but not focused?
[14:23] <conscioususer> mpt: oh, sorry, that's what you saids
[14:23] <conscioususer> *said
[14:24] <conscioususer> mpt: what about "add account"? the whole process happens in a new window (wizard), but visually the effects will only be seen on the main one
[14:25] <conscioususer> mpt: "remove current account" depends on the account menubutton, which is on the main window, so I guess it must be insensitive on the prefs window
[14:25] <larsu> conscioususer, sorry if I'm ignorant, but shouldn't menu item sensitivity be correct automagically when you're using app. and win. actions properly?
[14:26] <conscioususer> mpt: yeah, and this is working, my questions to mpt are to decide which will be app and which will be win
[14:26] <conscioususer> larsu: ^
[14:27] <larsu> conscioususer, ah, go ahead then :)
[14:27] <mpt> conscioususer, correct. You might focus the main window after the Add Account process finishes. Not because the command is tied to the window, but just because that's the easiest way to show that the command succeeded.
[14:30] <conscioususer> mpt: hmm, ok, I think I can follow this to deduce the other ones
[14:31] <mpt> conscioususer, ok, let me know if you'd like me to review anything later on. :-)
[14:31] <conscioususer> mpt: sure will :)
[14:32] <conscioususer> mpt: thanks a lot :)
[14:32] <mpt> np
[14:32] <conscioususer> mpt: GMenu is really making my life easier on this one.
[14:33] <mpt> cool. :-) You can thank desrt
[14:35] <conscioususer> mpt: I thank him for that and also for some bugs he and larsu helped me with recently :)
[14:35] <conscioususer> mpt: btw, if you eventually have some time I'm interested on your opinion on this: https://lists.launchpad.net/unity-design/msg10086.html
[14:36] <larsu> conscioususer, ha, I asked the same thing on irc a while ago. It's a tricky situation unfortunately :/
[14:36] <mpt> conscioususer, an easy way to fix that is to stop showing the application name in the menu bar :-)
[14:38] <conscioususer> true, but then the whole name-becomes-window-buttons would have to be rethought
[14:40] <didrocks> mterry: hey, how are you?
[14:40] <mterry> didrocks, hello!
[14:40] <mterry> good
[14:41] <didrocks> mterry: I saw that in fact, for merging inline the packaging branch back to upstream, you did merge the branch itself, not just copy debian:c
[14:41] <didrocks> debian/ ?
[14:41] <conscioususer> mpt, larsu: I wonder if this might be the last drop that will make the design team give up on the titlebar-panel fusion? ;)
[14:41] <mterry> didrocks, yeah
[14:41] <didrocks> (this was not clear on the merge request with the diff)
[14:41] <didrocks> mterry: ok, this gives me some interesting challenge :)
[14:41] <didrocks> for the daily upload bits
[14:41] <mterry> didrocks, oh sorry  :-/  I thought keeping some history was valuable
[14:41] <didrocks> as it's walking up the tree since last release
[14:42] <didrocks> mterry: yeah, I got why it was important
[14:42] <mpt> conscioususer, the design team? ;-)
[14:42] <didrocks> mpt: but basically the first release of every component is closing "all the bugs" :p
[14:42] <larsu> conscioususer, I'd certainly welcome that... (even though I do like the general idea)
[14:42] <didrocks> mterry:
[14:42] <conscioususer> mpt: you know what I meant :P
[14:42] <didrocks> sorry mpt ;)
[14:42] <mterry> didrocks, all the bugs in the packaging branch?  :)  hmm
[14:43] <mterry> didrocks, blacklist those merges?
[14:43] <didrocks> mterry: yeah, and as with the debcommit, you get the upstream ones listed
[14:43] <mpt> didrocks, I think I'm missing some context
[14:43] <didrocks> mterry: well, not that easy
[14:43] <didrocks> mpt: I was talking to mterry, so m<tab> and you spoke last, sorry ;)
[14:43] <mpt> ah
[14:44] <didrocks> mterry: I would say, to avoid cripping all the upload, we can bootstrap by hand
[14:45] <conscioususer> mpt: larsu: I'm not worried about polly, as I won't use an appmenu, but we're about to see 90% of gnome apps present this issue :-/
[14:45] <mterry> didrocks, meaning what?
[14:45] <didrocks> mterry: listing the bug and make a MR with the magic stenza (which is needed anyway)
[14:46] <didrocks> mterry: will discuss about it when we can enable the project for daily upload
[14:47] <didrocks> mterry: not related, but I think you saw https://code.launchpad.net/~mterry/unity-lens-applications/sync-packaging/+merge/133401 ?
[14:47] <didrocks> (didn't have the time to look at it)
[14:48] <mterry> didrocks, yeah I saw, will go back to it
[14:48] <didrocks> thanks! :)
[14:50] <conscioususer> desrt: the GMenu XML parsing functions were dropped in Gio, but the docs on those were the only source I knew for the DTD... where I can find the DTD now?
[14:51] <desrt> conscioususer: i don't know.
[14:52] <desrt> i guess the gtkbuilder one didn't get updated?
[14:52] <desrt> ....i guess gtkbuilder doesn't even _have_ one?
[14:52] <desrt> hrmph.
[14:53] <conscioususer> desrt: I noticed some things changed... for example, I can't seem to use the less verbose mode anymore
[14:53] <mterry> didrocks, what things are using /usr/lib/nux/unity_support_test nowadays?
[14:53] <desrt> less-verbose mode of what?
[14:55] <conscioususer> desrt: according to http://developer.gnome.org/gio/2.31/gio-GMenu-Markup.html, I can set menuitem attributes using XML attributes instead of full-fledged <attribute> tags.. but in 12.10 (Gio 2.32) trying to do this gives me an error
[14:56] <desrt> ya.  we dropped that
[14:56] <desrt> it was leading to problems
[14:56] <desrt> two problems, specifically:
[14:56] <desrt> 1) it was unclear how we would support that for non-strings
[14:56] <desrt> <item target='5' target:type='i'/> ?
[14:56] <desrt> ugly...
[14:57] <desrt> 2) it was unclear how we would support translation for that
[14:57] <desrt> <item label='File' label-is-translatable='yes'> ?
[14:57] <desrt> ugly...
[14:57] <desrt> so we had a system that only really worked for string-typed values that were not translatable
[14:57] <desrt> which was approximately nothing at all
[14:57] <desrt> so it got nixed
[14:58] <conscioususer> ah, makes sense
[14:58] <didrocks> mterry: compiz itself is using it
[14:58] <conscioususer> desrt: ok, so I guess the XML string example in http://developer.gnome.org/gtk3/unstable/GtkApplication.html tells me pretty much everything I need to know?
[14:59] <desrt> i admit that some things would be nice as direct attributes... like 'action'
[14:59] <desrt> since it's always a non-translatable string
[14:59] <didrocks> mterry: it needs to be unfortunately in a separate process
[14:59] <didrocks> otherwise you can't reinitialize opengl forcing llvmpipe
[14:59] <desrt> conscioususer: crikey....
[14:59] <desrt> conscioususer: it kinda scares me that blotpad gets included wholesale into the docs
[15:00] <conscioususer> desrt: well, that kinda helped me :)
[15:00] <desrt> conscioususer: well,it should
[15:00] <desrt> bloatpad is supposed to be a demo of all of the major features of GtkApplication
[15:00] <desrt> it's just kinda.... big :)
[15:00] <desrt> for a code sniplet
[15:00] <mterry> didrocks, yar.  Only compiz?  (Branch to move to dh9 will bring multiarch to nux, so I'm thinking of adding a toolsdir variable to the .pc file, but I need to know who else needs to look for that var)
[15:03] <didrocks> mterry: yeah, only compiz + the source_xorg.py package hook
[15:04] <didrocks> mterry: it seems that it's been added to other hooks as well
[15:04] <didrocks> like graphic driver ones
[15:04] <conscioususer> desrt: agree, sometimes it's hard to find something specific... well, GtkApp *does* have a ton of different features
[15:04] <mterry> didrocks, do you have a way to find out which by any chance?
[15:05] <desrt> conscioususer: it will have more soon :)
[15:05] <conscioususer> desrt: cool, I look forward to that... as long as they work on GC-languages :P
[15:06] <didrocks> mterry: I don't really know, I only did the xorg one :) I found the nvidia ones by grepping in  /usr/share/apport/package-hooks/ evn if I don't use it. Maybe some are installed by default?
[15:06] <mterry> k
[15:55] <didrocks> fginther: can you have a look at https://code.launchpad.net/~didrocks/bamf/rev/+merge/134052 please?
[15:58] <fginther> didrocks, lookinv
[15:58] <fginther> looking
[16:18] <ricotz> didrocks, hi, i doubt this compiles
[16:18] <didrocks> ricotz: ?
[16:19] <ricotz> 1878	- if (!bamf_view_user_visible (BAMF_VIEW (window)))
[16:19] <ricotz> 1879	+ if (!bamf_view_is_user_visible (BAMF_VIEW (window)))
[16:19] <ricotz> this isnt part of 0.3 irc
[16:19] <didrocks> ricotz: I don't care about the content, this was a test, see the comment on other merge request
[16:19] <ricotz> ah sorry
[16:19] <ricotz> i thought this transition is going to 0.3 too
[16:23] <didrocks> no worry :)
[16:25] <fginther> didrocks, I may be missing some context, are you really trying to merge that MP into lp:bamf/0.3?
[16:26] <fginther> lp:bamf/0.3 is still merging with unity-merger
[16:28] <didrocks> fginther: I don't
[16:28] <didrocks> fginther: just look at the comment
[16:28] <didrocks> fginther: it's for the next daily workflow
[16:28] <didrocks> fginther: so basically, there is changelog change only
[16:29] <fginther> didrocks, ok, so you want to push a release instead of an automatic build to staging ppa
[16:37] <didrocks> fginther: not a real push
[16:37] <didrocks> fginther: this can go to the traditional merge circuit
[16:37] <didrocks> fginther: so doing bzr lp-propose <branch> --approved
[16:37] <didrocks> fginther: but if I do that, there is no "approved revision"
[16:38] <didrocks> like, you see the approval, but not the rev
[16:38] <didrocks> is that an issue for you?
[16:39] <fginther> didrocks, thanks you, it's starting to make sense now.
[16:42] <fginther> didrocks,  I think I understand better now. I'll need to investigate the launchpad API a bit to make sure we can correctly identify the merge proposal
[16:42] <didrocks> fginther: thanks :)
[16:42] <didrocks> mterry: kenvandine: cyphermox: hey, so… looking at this autolanding thing, it seems that some package (not mine, you ken! :p) doesn't have source package name == upstream project name
[16:43] <didrocks> this gives a bunch of configuration nightmare that I want to avoid
[16:43] <didrocks> do you think you can review each stack and ensure it's fine?
[16:43] <kenvandine> yeah
[16:43] <seb128> didrocks, #ubuntu-desktop dude :p
[16:43] <kenvandine> which package is that?
[16:44] <mterry> didrocks, sure
[16:44] <didrocks> kenvandine: unity-lens-video! :-)
[16:44] <mterry> didrocks, I assume you prefer to rename the package in Ubuntu?
[16:44] <didrocks> mterry: also, on the lens land, most of them finishes with a s
[16:44] <kenvandine> ugh
[16:45] <didrocks> mterry: I don't really mind, as long as it's consistent :)
[16:45] <didrocks> like all lenses finishing with a s
[16:45] <mterry> didrocks, hmmm.  renaming LP projects is way easier.  :)
[16:45] <didrocks> but of course, no shoppings
[16:45] <didrocks> mterry: does it work?
[16:45] <didrocks> mterry: I looked at it
[16:45] <didrocks> and it doesn't seem to be possible?
[16:45] <didrocks> kenvandine: I want videos! :-)
[16:45] <mterry> didrocks, I think you have to ask LP admin to do it
[16:45] <didrocks> mterry: oh oh
[16:46] <didrocks> mterry: that can be interesting
[16:46] <didrocks> kenvandine: what do you think? ^
[16:46] <didrocks> if LP renaming is an option, let's go for it
[16:46] <kenvandine> i'd prefer that
[16:47] <kenvandine> davidcalle, ^^
[16:47] <mterry> didrocks, for some of them anyway.  Like, the unity-lens-gdocs is upstream unity-scope-gdocs, so obviously we want to fix the scope mistake, and that's going to be in LP
[16:47] <didrocks> mterry: kenvandine: cyphermox: each one taking care of their stack? :)
[16:47] <didrocks> mterry: agreed
[16:47] <mterry> didrocks, that will still cause you configuration pain, I suppose, as all your scripts have to change to point
[16:47] <davidcalle> kenvandine, I can't see what you are pointing to :)
[16:47] <cyphermox> didrocks: ack
[16:48] <didrocks> mterry: well, it's still better to just have one parameter than two, so I'll take care of that ;-)
[16:48] <kenvandine> davidcalle, we are talking about making the source package name and lp project match for the videos lens
[16:48] <fginther> kenvandine, mterry, cyphermox: if the LP branch names change, please let me know so that I can update the automerger jobs
[16:49] <davidcalle> kenvandine, ok.
[16:49] <cyphermox> fginther: ok
[16:51] <davidcalle> kenvandine, do you want me to poke a lp admin or will it be faster if it comes from your side?
[16:51] <kenvandine> i doubt it matters
[16:51] <kenvandine> it's your project though
[16:51] <kenvandine> so i would feel better if you did
[16:52] <davidcalle> kenvandine, ok
[16:52] <kenvandine> davidcalle,
[16:52] <kenvandine> davidcalle, thanks!
[16:52] <davidcalle> kenvandine, np!
[17:09] <didrocks> kenvandine: mterry: so cyphermox came with setting -c4 by default
[17:09] <didrocks> kenvandine: mterry: I think it's a nice idea (I have it for years on my desktop), next time we touch the packaging of any lib, what do you think about setting DPKG_GENSYMBOLS_CHECK_LEVEL=4 in the rules?
[17:09] <didrocks> that avoid the dh_makeshlibs override
[17:09] <didrocks> and force the value
[17:09] <cyphermox> didrocks: really, if it's done for the merges, it's more like belt + suspenders
[17:10] <didrocks> cyphermox: I'm all for suspenders :)
[17:11] <mterry> didrocks, OK
[17:12] <didrocks> mterry: I think though that we shouldn't activate that on the C++ projects, pitti and I spent a lot of time of trying to have symbols tracking on them and we never succeeded as we discussed at Copenhaguen
[17:12] <mterry> didrocks, oh god no.  I hate symbols & c++
[17:12] <cyphermox> bah, then maybe just forget about it and have everything pretty much the same
[17:13] <didrocks> mterry: we all do! :-) everytime I'm reading http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ and forget about those sneaky details…
[17:13] <didrocks> cyphermox: we just can't have symbols file in c++ project, but I guess that's fine
[17:14] <didrocks> thanks mterry, cyphermox, kenvandine :)
[17:14] <cyphermox> didrocks: it doesn't fail the build though :(
[17:15] <didrocks> cyphermox: hum, are you sure? you have a diff and it doesn't?
[17:15] <didrocks> cyphermox: it did a lot for me
[17:15] <didrocks> with the env var?
[17:15] <cyphermox> yeah, I commented one out and bzr bd didn't fail
[17:15] <didrocks> cyphermox: do you have an url handy? I can try it
[17:16] <kenvandine> i think that is intended to not fail the build
[17:16] <didrocks> kenvandine: with 4, it should and it does here ;)
[17:16] <kenvandine> ok
[17:16] <didrocks> (it's in my system env and not stripped by debuild)
[17:17] <kenvandine> what level shouldn't fail it?
[17:17] <didrocks> 0
[17:17] <kenvandine> i seem to recall folks setting that to 4 to short circuit the check
[17:18] <didrocks> kenvandine: man dpkg-gensymbols
[17:18] <didrocks> -c[0-4]
[17:19] <kenvandine> i guess i might have had the order backwards :)
[17:19] <didrocks> yeah ;)
[17:19] <didrocks> kenvandine: the merger always did export 0
[17:19] <didrocks> because I didn't wanted it to fail
[17:19] <didrocks> as the packaging was separated
[17:19] <didrocks> (it sedded beautifully the debian/rules file)
[17:20] <didrocks> cyphermox: do you have a link of what you are trying so that I can give it a shot?
[17:20] <cyphermox> didrocks: lp:~mathieu-tl/indicator-messages/inline
[17:20] <didrocks> thanks :)
[17:20] <cyphermox> comment out one symbol from libmessaging-menu0.symbols and run bzr bd
[17:20] <didrocks> doing :)
[17:21] <didrocks> cyphermox: oh
[17:21] <didrocks> you need to export it
[17:21] <didrocks> export DPKG_GENSYMBOLS_CHECK_LEVEL=4
[17:21] <didrocks> because it's a subprocess
[17:21] <didrocks> (dpkg-gensymbols)
[17:21] <cyphermox> of course
[17:21] <cyphermox> I suck
[17:21] <cyphermox> :)
[17:21]  * cyphermox facepalm
[17:21] <didrocks> no, you just got trapped :p
[17:22] <cyphermox> no, that's just being dumb, I know about this ;)
[17:22] <didrocks> well, no worry anyway, I was just surprised that it didn't work :)
[17:23] <didrocks> I confirm that bzr bd isn't happy after that!
[17:23] <cyphermox> well, I also was suprised ;)
[17:23] <cyphermox> of course that works now
[17:23] <cyphermox> well, the MR is updated
[17:24] <didrocks> cyphermox: looking!
[17:34] <didrocks> cyphermox: even my pbuilder is happy. Good work! :)
[17:35] <didrocks> fginther: https://code.launchpad.net/~mathieu-tl/indicator-messages/inline/+merge/134100 is ready for inline packaging landing
[17:38] <fginther> alesage, I may need your help with ^^ indicator-messages MP
[17:45] <alesage> didrocks, fginther I confess that I'm surprised by this proposal, thought we resolved to leave indicators-stack packaging "out of line"; tedg and kenvandine wishing to review?
[17:47] <tedg> Also confused why you'd drop all the history of the other bazaar branch.
[17:48] <tedg> cyphermox, ^
[17:49] <cyphermox> tedg: I'm not sure how I could keep it. It's not hugely relevant for the packaging branch though, because the history is in debian/changelog
[17:49] <cyphermox> or what branch history do you mean, actually?
[17:49] <tedg> cyphermox, It is, because debian/changelog doesn't really have information for things like bzr blame.  It's really an incomplete history for user consumption.
[17:50] <cyphermox> no
[17:50] <cyphermox> debian/changelog contains the history of who changed what
[17:50] <tedg> cyphermox, I mean start with "bzr merge lp:~ubuntu-desktop/indicator-messages/ubuntu" instead of "cp"
[17:50] <tedg> cyphermox, not really, I edit that file all the time :-)
[17:50] <cyphermox> right, but when you edit it, you should have your name on top or on the trailer line
[17:51] <cyphermox> e.g. using dch
[17:51] <cyphermox> tedg: those branches don't have ancestry
[17:51] <tedg> cyphermox, And when I delete a revsion in the middle because it isn't relevant?
[17:51] <tedg> cyphermox, Yes, they do.  They're properly build bzr build-deb branches.
[17:51] <cyphermox> what do you mean delete a revision?
[17:51] <tedg> Not some importer stuff.
[17:52] <tedg> cyphermox, Edit the file, select those lines.    Distro doesn't care about all the PPA trial version or anything else.
[17:53] <cyphermox> ubuntu-desktop/indicator-messages/ubuntu was a full branch, not a merge-mode branch, it possibly did have ancestry, but when I initially tried to merge it basically blew up in my face
[17:53] <cyphermox> tedg: but you could just as well include it
[17:53] <tedg> If you only look at it from the "one archive" perspective you don't, but that's a limited perspective.
[17:55] <cyphermox> anyway, whatever, I don't feel strongly for one way or the other. I don't think the history for that was very relevant
[17:55] <cyphermox> (because what we care about was already in changelog)
[17:57] <tedg> I would say all history is important, it's what defines us :-)
[17:57] <tedg> And, at a practical level.  It makes your branch conflict with any other.
[17:57] <tedg> Because now you've created new file IDs
[17:57] <tedg> For the same files.
[17:58] <cyphermox> tedg: there are no same files
[17:58] <cyphermox> it's adding debian/
[17:58] <cyphermox> that's really it
[17:59] <tedg> cyphermox, We have many packaging branches.  Now all of those (which have a debian dir) conflict with yours.
[17:59] <cyphermox> just retesting, merging lp:~ubuntu-desktop/indicator-messages/ubuntu into lp:indicator-messages reverts a bunch of changes done upstream
[17:59] <cyphermox> tedg: what do you mean many packaging branches?
[18:00] <cyphermox> the goal is to take the packaging and fold it upstream, I'm not sure what else needs to be done. all the other branches should IMO just go
[18:00] <tedg> https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu
[18:00] <tedg> https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.4
[18:00] <tedg> https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.3
[18:00] <tedg> https://code.launchpad.net/~ken-vandine/indicator-messages/lucid
[18:00] <tedg> https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.1
[18:00] <tedg> https://code.launchpad.net/~indicator-applet-developers/indicator-messages/ubuntu.0.2
[18:01] <tedg> All of those are comparable, because they use the same file IDs.
[18:02] <cyphermox> that's fine, but those should just go. they are still useful historically prior to a possible merge of my work, but past that the "upstream" packaging is what we want to use
[18:02] <cyphermox> anyway, let's bring that up to didrocks to decide
[18:02]  * cyphermox will head back to NM for the time being
[18:03] <cyphermox> also, if you know how to cleanly just merge the *right* packaging branch, which should be ~ubuntu-desktop/indicator-messages/ubuntu into lp:indicator-messages (for example), then please teach me :)
[18:04] <cyphermox> (by cleanly I mean without messing around with all the non-debian/ changes we clearly don't want)
[18:05] <tedg> cyphermox, They're probably there because of distro patching.  You can just bzr revert all of those.
[18:05] <tedg> cyphermox, Then you keep with the upstream branch.
[18:05] <tedg> Well, I guess I'm not allowed to use the term "upstream" anymore.
[18:06] <cyphermox> well, yes you are :)
[18:06] <tedg> "The version with the changelog that no one edits and is out of date"
[18:06] <cyphermox> tedg: that's what we want to change
[18:06] <tedg> bzr log > debian/changelog
[18:06] <cyphermox> tedg: or actually, that's what *will* change, because that will be the canonical changelog for the projet
[18:06] <cyphermox> oh god no
[18:07] <tedg> No, it won't be.  The Bazaar history always will be.
[18:07] <tedg> It's a nice try, but a failure waiting to happen :-)
[18:07] <cyphermox> there's a disconnect here
[18:07] <cyphermox> changelog is meant for the packaging changes, not upstream changes
[18:07] <tedg> Exactly, which is why they shouldn't be in the same branch.
[18:07] <cyphermox> (with the possible exception of key new features)
[18:08] <cyphermox> tedg: talk to didrocks, there were more than one discussions about this stuff at UDS, and the net result was to fold in debian/ to upstream packages to get easier daily uploads to the archive and help you guys with feedback
[18:09] <tedg> Not something we asked for or felt we needed.  But yes, didrocks decided to do that.
[18:09] <cyphermox> well, maybe not for indicators so much, but quick feedback on changes was something that unity would win on
[18:10] <cyphermox> I'm saying this, but I wasn't in *all* of the sessions about this :/
[18:10] <tedg> No, not really.  Because what will happen is the devs will stop committing to trunk.  They don't want quick feedback from users, they want to be able to discuss things amongst themselves first.
[18:11] <tedg> So "trunk" is the new packaging branch.  And "not trunk" is where work gets done.
[18:11] <cyphermox> not quite
[18:11] <cyphermox> trunk should be where stable stuff lands, and not trunk for unstable, possibly broken crack :)
[18:11] <cyphermox> e.g. trunk always builds and has as few regressions as possible
[18:12] <tedg> Sure, kinda like "releases" were before.
[18:12] <cyphermox> yeah
[18:12] <tedg> So anytime where a release would be made before, that's now a merge to "trunk"
[18:12] <cyphermox> with the difference of releasing just about every day to the archive
[18:12] <tedg> No, it'll only release when something is added, it won't get commits everyday.
[18:13] <tedg> There's no reason for devs to want to commit to it.  You just get yelled at by users.
[18:13] <cyphermox> tedg: basically, it will be the same CI as usual, except when this pass unit tests and some extra testing it will get automatically in archive
[18:13] <tedg> Kinda like "releases" in the past.
[18:13] <cyphermox> tedg: trunk it's meant for new crack until it's stabilized though, that's what was happening because (maybe) and why people were complaining
[18:14] <cyphermox> tedg: let's punt this to didrocks. I'm just the muscles for this one ;)
[18:15] <cyphermox> can't believe we're in such apparent disagreement right now though, I would have thought it would have been already discussed with you and more or less agreed to already, I'll ask him what's up
[18:16] <cyphermox> fginther: so you're holding off on that merge for now, right? :)
[18:16] <cyphermox> one more day won't hurt
[18:41] <fginther> cyphermox, yes, holding off for now
[19:36] <charon__> hi all!
[19:38] <charon__> I just tried to compile unity according to the manual on unity.ubuntu.com, however, cmake produces an error even before compilation starts. Maybe this manual needs fixing? I'm using ubuntu 12.04.
[19:50] <charon__> cmake complains "package 'unity-protocol-private' not found"
[19:50] <bschaefer> charles, you need to compile/install libunity or grab the stagging ppa
[19:50] <bschaefer> charles, opps! wrong person
[19:50] <bschaefer> charon__, ^
[19:51] <charles> :)
[19:52] <charon__> libunity-dev is installed. does this mean, the version is not compatible with the unity trunk?
[19:53] <bschaefer> charon__, yes, the unity-protocol-private was added later...(im not sure when), but it is in trunk libunity
[19:54] <charon__> what exactly is considered to be a package btw? is it some form of a c++ class?
[19:54] <bschaefer> umm im not sure what you are asking
[19:54] <charon__> the cmake script also complained that package zeitgeist was not available, so I installed libzeitgeist-dev and that error went away
[19:55]  * bschaefer also doesn't know much about packaging
[19:55] <charon__> I mean, obviously the package is part of libunity. Is this an API or what?
[19:56] <charon__> sorry for these questions, but i'm _really_ new to unity.
[19:57] <charon__> before also compiling libunity, maybe I should try to build unity 5.x, which is part of ubuntu 12.04.
[19:57] <bschaefer> hmm I would think it is just part of it
[19:58] <bschaefer> that should work for you
[19:58] <bschaefer> bzr branch lp:unity/5.0
[19:58] <charon__> thanks for that!
[19:59] <bschaefer> np! let me know if you run into any other compiling problems
[20:00] <charon__> still, the website (unity.ubuntu.com) needs fixing as it just doesn't work anymore. The manual states that it is meant for precise, which I'm using.
[20:01] <bschaefer> hmm I would think the current state of building unity would be with the current version...
[20:01]  * bschaefer goes to look at the site
[20:03] <charon__> compiling unity 5.0 seems to work
[20:03] <bschaefer> well you wont get trunk unity, you'll just get unity 5.0
[20:04] <charon__> that's fine. I need to fix a bug in unity 5.x ;)
[20:04] <bschaefer> perfect then :)
[20:23] <charon___> Hmm, not a good idea to run the freshly compiled unity with unity --replace. My display just got crazy with many graphics errors.
[20:26] <charon___> what is a good workflow for testing a freshly compiled unity?
[20:27] <bschaefer> 'unity' should work or using the standalone files
[20:27] <bschaefer> unity/build/dash/dash
[20:27] <charon___> (without crashing the running unity from the repository)
[20:27] <bschaefer> well running 'unity' kills compiz, then restarts compiz
[20:28] <bschaefer> what errors does it give you when you run unity?
[20:29] <charon___> Is it a good idea to use another user? For this user, a second instance of lightdm is started on alt-f8?
[20:29] <charon___> I then wouldn't care if something crashes.
[20:29] <bschaefer> hmm no, you should be fine just running 'unity'
[20:29] <charon___> the display becomes _very_ colored with a lot of pixel garbage.
[20:30] <charon___> so i can't say what it says ;)
[20:30] <bschaefer> try running 'unity' in a tty
[20:30] <bschaefer> alt-f1
[20:30] <charon___> ok.
[20:30] <bschaefer> then going back to f7
[20:31] <bschaefer> ctrl+alt...
[20:32] <charon___> I'm not a linux newbie ;)
[20:32] <bschaefer> :), the ... are for me forgetting the ctrl part haha
[20:33] <charon___> hmm, could be that it is working now. I used "unity-env" to get my staging branch, then "unity --replace"
[20:33] <bschaefer> because what should happen. Compiz is killed, then restarted with the unity you built...which then it should go and actually restart the unitshell plugin
[20:33] <bschaefer> hmm
[20:34] <bschaefer> and if it fails it would say Error to load unityshell...but im not sure what you are seeing, or if there are any errors
[20:35] <charon___> it now started without errors
[20:35] <charon___> I just have to check that it is the compiled binary from me and not the one from the repository.
[20:35] <charon___> (any idea how to do that?)
[20:36] <bschaefer> hmm a print statement :)
[20:36]  * bschaefer should know how though...
[20:37] <charon___> I could change the version in the source code
[20:38] <bschaefer> you could also check ~/.compiz-1/plugin
[20:38] <bschaefer> plugins*
[20:39] <bschaefer> if that is there, that is what compiz reads first
[20:39] <bschaefer> it is a good indicator you are running a compiled version.
[20:40] <charon___> yes, the directory exists and there are a couple of shared libraries in it.
[20:44] <charon___> i just compiled a new version, setting the version to 5.17.0 (in build/config.h). But typing unity --version still gives 5.16.0.
[20:45] <bschaefer> unity is just a python scrip in your /usr/bin
[20:45] <bschaefer> if you wen to build/bin/unity --version
[20:45] <bschaefer> it will give you the correct one
[20:50] <charon___> hmm, maybe I changed at the wrong position.
[20:51] <bschaefer> usually to be 100%, just add a printf in unity/dash/DashController.cpp under Show
[20:51] <bschaefer> then everytime you show the dash you get that print state ment haha
[20:51] <charon___> of found it
[20:51] <charon___> of=oh
[20:52] <bschaefer> cool
[20:52] <charon___> :)
[20:52] <charon___> UNITY_MINOR in CMakeLists.txt