[02:27] <robert_ancell> TheMuso, hey, there is a new version of the lcms library (lcms2) which is parallel installable with the old version (<2).  As far as I can tell there will be no more development on <2 (i.e. it is not a stable branch, but allows you to run your old software and gradually port it).  Question is: Do I make a new source package for lcms2 or just add a new changelog entry in the existing lcms one?
[02:31] <RAOF> I guess the answer would be the same as the answer to the question “are you ever going to need to patch lcms1”?  Is it just an soname bump, or a parallel development tree, etc?
[02:32] <TheMuso> RAOF: Agreed. Also I wonder what Debian is doing.
[02:32] <TheMuso> Yes, squeeze has frozen etc.
[02:34] <robert_ancell> I sent the proposed package to Debian, but I guess they wont be using it if they are frozen
[02:34] <robert_ancell> RAOF, I think the answer is "no, and all packages should migrate to lcms2"
[02:35] <RAOF> Is there an API break?
[02:35] <RAOF> Is the lcms → lcms2 transition just a rebuild?
[02:35] <robert_ancell> RAOF, not sure, but it doesn't matter as you will have to explicitly relink against the new one anyway
[02:36] <robert_ancell> The library has changed from lcms.so to lcms2.so
[02:39] <RAOF> Ah.  So I'd guess there's an API change, and it's not a simple rebuild with a different -l flag.  That sounds more like you want a different source package; liblcms sounds like it'll be hanging around long enough that you could reasonably expect to want an upload.
[02:39] <TheMuso> Are they plugins, or a shared lib? If a lib, then the soname is wrong.
[02:41] <robert_ancell> TheMuso, a lib, what is wrong with the soname?
[02:41] <RAOF> It should probably be liblcms.so.2
[02:42] <TheMuso> afaik sonames should be something like libname.so.nub
[02:42] <TheMuso> s/nub/num
[02:42] <TheMuso> RAOF: yeah
[02:42] <robert_ancell> No, the renamed the source package to lcms2
[02:49] <RAOF> It sounds more like it wants to be a new source package, starting with “initial upload to $DISTRO”.
[02:55] <TheMuso> yep
[06:51] <pitti> Good morning
[06:54] <TheMuso> Hey pitti.
[06:56] <pitti> hey TheMuso, had a nice weekend?
[06:56] <TheMuso> pitti: Certainly did thanks. Yourself?
[06:56] <pitti> quiet, but nice; thanks
[06:56] <TheMuso> Quiet is good.
[07:34] <didrocks> good morning
[07:35] <pitti> bonjour didrocks
[07:36] <didrocks> Guten Morgen pitti, how was your week-end?
[07:37] <pitti> didrocks: quiet on Saturday (was raining cats and dogs), so I did some household cleanup; we went hiking yesterday, so very nice; how was your's?
[07:39] <didrocks> pitti: very sunny and nice in the Alps. Went to a traditional restaurant and some walking in the mountains. Just feel a little bit cold sometimes compared to Paris (< 20°C)
[08:15] <didrocks> robert_ancell: hey, I see you are doing a lot of remerge on debian, can you have a look this week-end at gnome-shell? It's currently broken because of new mutter
[08:16] <robert_ancell> didrocks, can do
[08:16] <didrocks> robert_ancell: bug #614359 should give you all the info :)
[08:16] <ubot2> Launchpad bug 614359 in gnome-shell (Ubuntu) "undefined symbol: mutter_plugin_effect_completed (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/614359
[08:16] <didrocks> robert_ancell: thanks!
[08:16] <didrocks> robert_ancell: basically, mutter broke the API without bumping the soname, it affected us at unity, and gnome-shell had the same issue
[08:17] <robert_ancell> didrocks, ok, will look at it tomorrow
[08:17] <didrocks> robert_ancell: great! thanks a bunch!
[08:44] <kiwinote> mvo: hi
[08:44] <mvo> hey kiwinote
[08:44] <kiwinote> mvo: are you still working on the deb-files branch, or are you done making changes?
[08:45] <mvo> kiwinote: I'm not fully done, I can resume now. did you had a chnce to look over the other bits I put in? I think the deb file stuff is done, but the apturl links need a little bit of attention still
[08:47] <kiwinote> mvo: yep, I took a look at what you had changed. There are a few little sidecases which need fixing, but it looks good elsewise.
[08:48] <kiwinote> mvo: if you aren't working on it atm, then i'll fix a few little things first, otherwise I'll wait until you're done and fix them later
[08:48] <mvo> kiwinote: thanks for the review, I can merge them back if you put them into your branch
[08:48] <mvo> kiwinote: then please fix them now, we are not in a rush :)
[08:48] <mvo> eh, I'm not :)
[08:48] <kiwinote> mvo: sure, I'll let you know when they're done ;)
[08:49]  * mvo nods
[08:50] <seb128> hey
[08:50] <didrocks> salut seb128, ça va ? :)
[08:50] <seb128> lut didrocks
[08:50] <pitti> hey seb128, hello mvo
[08:50] <seb128> ouais et toi?
[08:50] <seb128> hey pitti, mvo
[08:51] <seb128> wie gets?
[08:51] <didrocks> seb128: ça va bien, merci :)
[08:51] <mvo> hey pitti, seb128
[08:54] <alf__> slomo: Hi! Did you get a chance to take a look at the proposed cairo packaging changes (debian #587771)?
[08:54] <ubot2> Debian bug 587771 in cairo "Package cairo-perf utilities" [Wishlist,Open] http://bugs.debian.org/587771
[09:14] <kiwinote> mvo: for error checking/setting of deb files your branch gets the failure_string from python-apt. Do we want that, or do we want to be able to set custom error messages which are more consistent with the rest of s-c like my branch did? (I don't mind which one you want, I just wanted to verify your decision)
[09:16] <seb128> bah, hundredpapercut start being annoying, broken changes get uploaded and people have no consideration for translations
[09:19] <huats> morning
[09:19] <seb128> lut huats
[09:19] <huats> How are you seb128 ?
[09:20] <seb128> I'm fine I think, what about you? ;-)
[09:20] <huats> good too !
[09:21] <huats> last week before 1 week of holidays :D
[09:21] <mvo> kiwinote: I think it would be great to re-use the ones from python-apt to have one a single string that needs to get translated etc. if they are too technical then that is a valid point and we should reconsider. in this case it would be nice to make python-apt return error enums so that we don't have a dupe the check() function from p-apt inside s-c
[09:21] <mvo> kiwinote: I hope we can make the ones in python-apt good enough for showing in s-c without loosing too much technical information
[09:23] <kiwinote> mvo: yes, it is indeed a good point not to duplicate stuff from python-apt. I'll check with mpt how technical or non-technical he wants the error messages to be in s-c.
[09:24] <mvo> thanks kiwinote
[09:24] <mvo> kiwinote: I guess its ok if deb installing is a tad more technical, but I will leave it to mpt to comment
[09:24] <kiwinote> mvo: ok, thanks
[09:28] <mpt> hi kiwinote
[09:28] <kiwinote> mpt: there is a bit above here about the failure strings for installing deb-files in s-c
[09:29] <kiwinote> mpt: the question is whether the failure strings from python-apt can be used or if they are too technical
[09:30] <kiwinote> mpt: the python-apt messages can be found at http://bazaar.launchpad.net/~mvo/python-apt/debian-sid-mirrored/annotate/head:/apt/debfile.py by searching for '_failure_string'
[09:31] <mpt> kiwinote, well, "Conflicts with a exisiting pkg!" isn't quite up to scratch :-)
[09:32] <mpt> kiwinote, when and where would these be shown?
[09:33] <kiwinote> mpt: they are shown in the summary line of the appdetailsview when someone opens a deb file with s-c when the deb-file can not be installed
[09:37] <kiwinote> mpt: individual strings can be rephrased in python-apt. The main thing is how much detail we want to show in s-c. Eg if the deb-file conflicts with pkgs already installed then python-apt will (and should) display the list of pkgs which it conflicts with. Do we want that much detail in s-c, or does less detail suffice?
[09:37] <mpt> kiwinote, in the summary line? Why wouldn't you be showing the summary of the package there?
[09:39] <kiwinote> mpt: if there is a better place for errors, then please let me know. I had put it there originally because the software can't be installed if there are errors which makes the summary/description/screenshot irrelevant, so atm we only display icon title and summary if there is an error and the rest is hidden
[09:41] <mpt> hmmmmmmmmmmm
[09:44] <mpt> kiwinote, I suggest putting the error message where the description would be instead.
[09:44] <mpt> And each of those will need tidying up.
[09:44] <kiwinote> mpt: and hiding the pkgstatusbar?
[09:44] <mpt> "This package cannot be installed because _______."
[09:45] <mpt> kiwinote, I don't know what "pkgstatusbar" maps to in the spec. The installed state bar?
[09:46] <kiwinote> mpt: yep, the coloured bar with the install/remove button in it
[09:47] <kiwinote> mpt: we can easily have a red coloured bar there, it just looks a bit odd if there is no text or button to go in it
[09:50] <mpt> Probably leave it there but make "Install" insensitive
[09:50] <mpt> bbiab
[09:50] <seb128> vish, starting changing descriptions over debian seems over the hundredpapercut line, can we stop that?
[09:51] <seb128> we can't start creating delta for such changes
[09:51] <kiwinote> mpt: ok, I'll do that then and see what it looks like
[09:51] <seb128> vish, changing desktop descriptions in universe is also not going to work, can you revert that change?
[09:51] <kiwinote> mpt: thanks
[09:52] <seb128> vish, that breaks every non english locale without a way to translate it
[09:54] <dpm> seb128, I wasn't aware of that. Is that happening in app-install-data, or on the ddtp descriptions?
[09:54] <vish> seb128: which one?
[09:55] <seb128> dpm, what is happening?
[09:56] <seb128> vish, the something-sdl
[09:56] <vish> ah..
[09:56] <seb128> vish, you changed a desktop Comment
[09:56] <seb128> the package being in universe there is no langpack
[09:56] <seb128> you just break all translations by doing that
[09:56] <vish> seb128: the change in the control file is ok? only need to revert the .desktop change?
[09:56] <seb128> we can argue over that
[09:57] <seb128> I think starting to change descriptions in the source this way is wrong
[09:57] <seb128> you are creating delta over debian and a need to merge every change where we were in sync
[09:57] <seb128> we don't have the manpower to start merging packages just for descriptions changes
[09:57] <vish> hmm..
[09:58] <seb128> if we think descriptions are not worded as they should we need an overlay layer
[09:58] <seb128> ie something we can change in launchpad of software-center
[09:58] <kiwinote> mpt: just a quick question: For non existent pkgs you had designed a 'Not Found' screen. Do you want that to stay the same, or do you want to display a coloured bar and then have the error message in the description field there as well?
[09:58] <seb128> we can't start creating diff to improve translations
[09:58] <seb128> ups
[09:58] <seb128> translations -> descriptions
[09:59] <seb128> it's going to cost hundred of work hours every cycle which we don't have
[09:59] <seb128> it's going to lead to outdated packages, conflict with debian, bugs, conflicts with upstream, etc
[09:59] <vish> seb128: the changes have been sent to debian ,and changed in debian too
[09:59] <vish> seb128: some are still waiting in debian for a response
[09:59] <seb128> no they have no been changed in debian
[09:59] <seb128> we have an 0ubuntu1 version now
[09:59] <seb128> which means we will never get debian updates in automatic way again
[10:00] <seb128> it will require somebody to spend time tracking it and merging it every single time debian do a change now
[10:00] <mpt> kiwinote, I think the "Not Found" screen shouldn't have an installed state bar, because it's not a package.
[10:01] <kiwinote> mpt: ok, then i'll change some of the internal code to deal with two different sorts of errors ;)
[10:02] <vish> seb128: ex: debian bug 590238 , this was fixed , some havent even responded like the pidgin one.. what should we do?
[10:02] <ubot2> Debian bug 590238 in xchat-gnome "xchat-gnome: Package description could have information about program use" [Minor,Open] http://bugs.debian.org/590238
[10:02] <vish> err , fix committed in debian too
[10:03] <seb128> vish, wait for them to upload and sync?
[10:03] <seb128> vish, well for things where we ubuntu changes already it's not so an issue
[10:03] <vish> seb128: pidgin has been waiting for 2yrs! :s
[10:04] <seb128> vish, well as said if we think the descriptions quality is not matching our standard we need to figure a way to sort it which doesn't imply patching every debian source
[10:05] <vish> right ..
[10:06] <vish> mvo: any ideas^ ?
[10:07] <seb128> mvo, mpt: weren't some discussion during the years about fetching descriptions from launchpad or something?
[10:07] <seb128> ie having a way to rewrite the packages descriptions without having to do source changes
[10:07] <mvo> seb128, vish: so ideally we would get "overwrite" support for this from LP
[10:07] <mvo> but its not there yet
[10:07] <mvo> (and maybe some time to come :/)
[10:08] <seb128> I though that was the plan
[10:08] <seb128> but yeah, launchpad changes can take time
[10:08] <mvo> I think for high profile apps like xchat it does make sense to go and patch them even if it means that we have the burden of merging
[10:08] <seb128> right
[10:08] <mvo> I guess a alternative idea would be to (ab)use the Translations-en file
[10:08] <seb128> but seems we start having uploads for random universe games and small packages
[10:09] <mvo> it can be done today but the LP support for finding packages in the huge template is not great
[10:09] <mvo> there is a open spec for imporving that so that the description.pot lives alongside the normal template in LP so that its triviial and find and tranlsate
[10:10] <mvo> that spec is open since ~1y or so (maybe more)
[10:12] <seb128> hum
[10:13] <seb128> brb gdm testing
[10:25] <seb128> re
[10:27] <Laney> vish: for now, for non high-profile packages I suggest you send the fixes to Debian and not seek to diverge in Ubuntu for that
[10:27] <Laney> it's the right place to make these changes anyway
[10:28] <vish> Laney: as i mentioned earlier, fixes are being send to debian
[10:28] <vish> sent*
[10:29] <vish> Laney: is debian in freeze now?
[10:31] <Laney> yes
[10:32] <Laney> I know they are being sent there, but it's not worth an upload in ubuntu for it
[10:32] <Laney> we should get it back through syncs
[10:33] <vish> Laney: yup, sounds sensible.. when maintainers dont respond how should we proceed?
[10:35] <Laney> if they make uploads without responding to your patches then you should raise it again
[10:35] <Laney> if there aren't any uploads then … there's not much you can do
[10:37] <vish> yeah , thats where it gets confusing , whether the maintainer is MIA or just doesnt want to change it..
[10:40] <vish> seb128: what about mvo's idea? [ using translations-en ] how do we do that ? is that acceptable?
[10:42] <seb128> vish, I'm not sure how we do that but as said before as long as you don't create delta over debian which creates extra work for everybody I'm fine with it
[10:43] <seb128> pitti, do you have any opinion on bug #605685?
[10:43] <ubot2> Launchpad bug 605685 in ubuntu "Sync isc-dhcp 4.1.1-P1-9 (universe) from Debian unstable (main) (affects: 1) (heat: 10)" [Wishlist,New] https://launchpad.net/bugs/605685
[10:44] <pitti> seb128: I didn't test it, so I don't
[10:44] <pitti> seb128: but Mathieu mentioned that he wants the transitional packages removed
[10:44] <seb128> pitti, no, he said that's an option
[10:44] <pitti> also, we have some Ubuntu modifictions to dhcp3 which would need to be ported
[10:44] <pitti> so it would be a merge either way
[10:44] <vish> cool!
[10:45] <seb128> pitti, I'm rather unsure if we should go for the new dhcp this cycle
[10:46] <pitti> seb128: didn't we talk about this the other day? I thought it was required for something in NM
[10:47] <seb128> pitti, right, just reading through the dhcp3 changelog the number of changes we have there is non trivial to port to the new version
[10:48] <seb128> ok, let's try to get the new one without the transitional binaries in and port changes and see where we can get
[10:54] <pitti> seb128: but what's the purpose of that then?
[10:54] <seb128> "that"?
[10:54] <pitti> we certainly don't want a second version in main which we didn't test and apply our changes to?
[10:56] <seb128> pitti, I'm trying to see how we move that forward but seems nobody is actively working on that part of the stack
[10:56] <seb128> hey rickspencer3
[10:56] <rickspencer3> hi seb128
[10:57] <pitti> hey rickspencer3, had nice holidays?
[10:57] <rickspencer3> pitti, indeed
[10:57] <rickspencer3> felt like much longer than 1 week
[10:57] <rickspencer3> (which I think is a good sign)
[10:57] <seb128> rickspencer3, on east cost time or up really early?
[10:57] <seb128> rickspencer3, ;-)
[10:57] <rickspencer3> seb128, east coast!
[10:58] <rickspencer3> for today and tomorrow
[10:58] <seb128> rickspencer3, so you managed to not work during the week? ;-)
[10:58] <seb128> ok
[10:58] <didrocks> hey rickspencer3 :-)
[10:58] <rickspencer3> hi didrocks
[11:27] <seb128> didrocks, you can drop your connman workitem for beta it will not be default
[11:27] <didrocks> seb128: sure, doing it now
[11:28] <seb128> thanks
[11:29] <hyperair> hmm? connman won't be default?
[11:29] <hyperair> in that case, will network-manager get indicator support?
[11:30] <didrocks> yw
[11:34] <seb128> no and no
[11:37] <pitti> chrisccoulson: do you happen to know if chromium supports system-wide preferences? like /etc/chromium/config/ or similar?
[11:38] <devildante> hi all :)
[11:39] <chrisccoulson> pitti - i don't think so, but i'm not entirely sure
[11:39] <pitti> I am grepping the source, but I can't find it
[11:39] <didrocks> pitti: chrisccoulson: they were some initial support added last month. I didn't check again though
[11:42] <pitti> it seems rather weird to patch and rebuild chromium just to change the behavior for a particular mime type
[11:42] <pitti> apparently in ./chrome/common/chrome_paths_*
[12:03] <rickspencer3> d'ooooh
[12:04] <rickspencer3> seb128, it turns out I'm on holiday until Thursday!
[12:04] <rickspencer3> what a dope I am
[12:04]  * TheMuso waves to rickspencer3.
[12:04] <TheMuso> And everyone else.
[12:04] <rickspencer3> hi TheMuso
[12:07] <didrocks> hey TheMuso
[12:07] <didrocks> rickspencer3: go back to enjoy your holidays so! ;)
[12:08] <rickspencer3> didrocks, well, I have a few things to do .. but yeah
[12:08] <rickspencer3> I'll limit my time at work, for sure
[12:09] <nigelb> rickspencer3: holidays = you're not at work.  Not that you're at work only for 8 hours unlike the usual 24 x 7 :p
[12:10] <rickspencer3> hehe
[12:10] <rickspencer3> I don't work that much
[12:11] <nigelb> I may be exaggerating but you get the point :D
[12:14] <didrocks> (I think we should face the reality: rickspencer3 misses us ;))
[12:14] <rickspencer3> didrocks, yeah
[12:15] <rickspencer3> plus there are new people!
[12:15] <rickspencer3> I wanted to meet them today
[12:15] <didrocks> :)
[12:19] <kiwinote> mvo: I've pushed mpt's changes of the error position to my branch along with a few small fixes to deb-file handling in general.
[12:20] <mvo> kiwinote: nice, thanks. I will remerge
[12:20] <kiwinote> mvo: I'll take a look at rephrasing some of the python-apt error messages now
[12:21] <seb128> rickspencer3, lol
[12:21] <seb128> rickspencer3, go back to enjoy your holidays then ;-)
[12:21] <rickspencer3> seb128, I am such a dolt
[13:00] <seb128> re
[13:13] <mpt> mvo, hi, software-center won't start for me: http://paste.ubuntu.com/475425/
[13:14] <kiwinote> mpt: any comments on http://paste.ubuntu.com/475424/ ?
[13:15] <mpt> kiwinote, not perfect, but a great improvement
[13:16] <mpt> kiwinote, for Breaks/Conflicts, why aren't we offering to simultaneously remove the thing that it breaks or conflicts with?
[13:16] <mvo> mpt: thanks, I have a look
[13:18] <kiwinote> mvo: ^ is that something that python-apt can do, or would that involve using error codes and putting that functionality in s-c itself?
[13:23] <mvo> kiwinote: it does involve code as it requires a user decision
[13:24] <kiwinote> mvo: yeah, I was wondering more if it was within the scope of python-apt, or not really
[13:24] <mpt> kiwinote, don't worry about it then, it's something that (maybe) should be implemented later for Breaks/Conflicts in general, not for .debs in particular
[13:24] <mvo> mpt: s-c should be fixed, but the commit is still in place
[13:24] <mvo> mpt: now its there r996
[13:24] <mvo> mpt: that should have read "still in progress"
[13:25] <mvo> kiwinote: hm, not really
[13:26] <kiwinote> mpt: are the string changes worth pushing, or would you have some time this week to make them perfect?
[13:26] <mvo> kiwinote: I mean, it does not fit that well into python-apt itself, we should make it trivial to support this strategy, but outside of p-apt itself
[13:26] <mpt> mvo, yep, it works, thank you
[13:26] <mvo> mpt: I agree with that, especailly for debs its potentially dangerous to support removing already existing stuff from the archive to essily
[13:26] <mvo> mpt: cheers
[13:28] <mpt> mvo, staging.launchpad.net is up, but I get nothing to purchase. Could this be the problem, or is it unrelated? 'File "./data/update-software-center-agent", line 36, in <module>      from softwarecenter.enums import *      ImportError: No module named softwarecenter.enums'
[13:29] <mvo> mpt: did you do "export PYTHONPATH=." before starting s-c ?
[13:29] <mvo> mpt: there is a issue with the sc.staging.ubuntu.com currently (in addition to this error)
[13:29] <mpt> mvo, I did not
[13:30] <mvo> mpt: please try that
[13:30] <mvo> mpt: I should update the README or add a README.bzr or something like that
[13:31] <mpt> mvo, doing that removes that error
[13:34] <mvo> mpt: great, thanks
[13:38] <TheMuso> y/c
[13:39] <mvo> kiwinote: merged your changes, they look good. unfortunately merging into trunk gives me a bunch of conflicts. could you have a look please ?
[13:40] <kiwinote> mvo: merging mvo/deb-files into trunk?
[13:42] <mvo> kiwinote: yep
[13:42] <mvo> kiwinote: I mean, if you merge trunk into your deb-files branch, you should see the conflicts
[13:43] <kiwinote> mvo: sure, I'll fix them. (all the buy-something stuff landed in trunk after my last merge)
[13:43] <mvo> kiwinote: yeah, a lot of churn (again :/)
[13:43] <mvo> kiwinote: but that is the last big branch that is in the queue
[13:43] <mvo> kiwinote: I mean, that was the last big one
[13:43] <mvo> kiwinote: other than the deb-files one :)
[13:43] <kiwinote> mvo: there were no more apturl changes you wanted to make?
[13:44] <mvo> kiwinote: let me check again, but it should not interfere with fixing the conflicts
[13:45] <kiwinote> mvo: indeed, I'll let you know when I'm done ;)
[13:45] <mvo> kiwinote: many thanks!
[14:02] <cyphermox> seb128, re: isc-dhcp; I agree, I think it would be best to get isc-dhcp without the transitional binaries in asap, then work on the actual switch in maverick+1
[14:03] <seb128> hey cyphermox
[14:03] <cyphermox> hi ;)
[14:03] <seb128> cyphermox, we can still try to switch this cycle I guess but seems porting the changes will be quite some work
[14:04] <cyphermox> yes, and isc-dhcp will require a MIR, and there might be other packages that require fixes, etc... lots of work IMO
[14:08] <cyphermox> seb128, looking at the changes in dhcp3, yes, it will require quite some work :)
[14:09] <seb128> cyphermox, ok, so let's get isc-dhcp in an work on getting it in shape this cycle
[14:10] <cyphermox> seb128, ok, I'll re-work my bzr branch to remove the transitional binaries from the latest version in unstable. Is a sync still the right process for this?
[14:13] <seb128> cyphermox, no, a sync is if there is no change, if you have changes it's a normal upload we need
[14:13] <cyphermox> seb128, I guess what I mean is, should I open a new bug?
[14:13] <seb128> desrt, no
[14:13] <seb128> ups
[14:13] <seb128> desrt, hey
[14:13] <seb128> cyphermox, no
[14:14] <desrt> seb128: hello
[14:14] <seb128> cyphermox, let's use the same one, I've unsubscribed ubuntu-archive now
[14:14] <desrt> what did i screw up now? :)
[14:14] <seb128> desrt, dconf 0.5 doesn't build with gir if libdconf0 is not installed
[14:15] <desrt> are you using --as-needed?
[14:15] <seb128> no
[14:15] <desrt> vuntz reported some issue related to that
[14:15] <desrt> hmm.
[14:15] <seb128> I just think it's not trying to use the source version
[14:15] <desrt> are you using 0.9.3 gobject-introspection?
[14:15] <desrt> or did you reduce the dependency?
[14:16] <seb128> we reduced the dependency
[14:16] <desrt> don't :)
[14:16] <seb128> and dropped the --no-libtool
[14:16] <desrt> that's what broke it
[14:16] <seb128> ok
[14:16] <vuntz> desrt: you broke things again!
[14:16]  * vuntz hugs desrt 
[14:16] <desrt> 0.9.3 + --no-libtool is required to add the rpath properly
[14:16] <seb128> I will just drop the gir for now
[14:16] <desrt> otherwise it won't work
[14:16] <desrt> vuntz: :)
[14:16] <seb128> gir is a mess anyway
[14:17] <seb128> and there are ongoing discussion now to not support python2 and gtk2
[14:17] <seb128> but only python3 and gtk3
[14:17] <desrt> good times
[14:21] <desrt> seb128: to be honest, you don't miss much by not having .gir for dconf
[14:21] <seb128> right
[14:21] <desrt> did the new vala get released while i was sleeping? :p
[14:22] <seb128> desrt, btw, https://bugs.edge.launchpad.net/ubuntu/+source/d-conf
[14:22] <seb128> desrt, yes
[14:22] <desrt> if so, you may want to save your time
[14:22] <desrt> i'm going to do 0.5.1 then
[14:22] <seb128> I've uploaded the version without gir for now
[14:22] <seb128> we didn't update vala yet
[14:22] <seb128> and dconf was broken due to the glib update
[14:22] <desrt> those old double frees are old, i think :)
[14:23] <seb128> the other one is with 0.5
[14:23] <desrt> ya
[14:23] <desrt> nice trace :p
[14:23] <seb128> it has not been retraced yet
[14:24] <desrt> if i wait for a while will it improve?
[14:24] <seb128> yes
[14:24] <desrt> nice
[14:24] <desrt> tedg: good morning
[14:24] <tedg> Good morning desrt
[14:24] <seb128> urg
[14:25] <seb128> pitti, have you seen "Corrupt duplicate db:[(u'*** in database main ***\nOn page 1129 at right child: invalid page number 1171',)]" errors before?
[14:25] <seb128> pitti, it's from the amd64 retracer
[14:25] <seb128> hey tedg
[14:25] <tedg> I've not been able to upgrade to Maverick all weekend... something about X dependencies.  Is that known?  (trying again now)
[14:26] <tedg> Morning seb128
[14:26] <seb128> tedg, not know there no
[14:27] <pitti> seb128: I did; I tried to fix it, but apparently it didn't work
[14:27] <pitti> (by dumping and recreating the DB)
[14:27] <tedg> Hmm, yeah.  Still failing.  It's a fight between xserver-xorg-video-nouvea and xorg-video-abi-7.0
[14:28] <seb128> pitti, :-(
[14:33] <desrt> seb128: how do i know when 'retrace' is done?
[14:35] <seb128> desrt, the tag apport-retracing-needed will be dropped
[14:35] <desrt> i guess subscribers get an email?
[14:35] <seb128> yes
[14:35] <desrt> cool
[14:35] <seb128> you will get the stacktrace added by the retracer by email
[14:36] <seb128> "need-amd64-retrace" is the tag
[14:36] <seb128> to be exact ;-)
[14:37] <seb128> desrt, http://launchpadlibrarian.net/53329301/buildlog_ubuntu-maverick-i386.d-conf_0.5-1ubuntu2_FAILEDTOBUILD.txt.gz
[14:38] <seb128> desrt, is that a bug of yours? ;-)
[14:38] <desrt> looks like you tried to autogen dconf without introspection installed
[14:38] <seb128> why do I need it?
[14:38] <desrt> you need it for autogen
[14:38] <desrt> ./configure is fine without it
[14:38] <seb128> bah
[14:39] <desrt> aclocal needs to be able to find the m4
[14:39] <seb128> stupid thing
[14:39] <seb128> you should ship the macros you need ;-)
[14:39] <desrt> maybe...
[14:39] <desrt> why did you autogen it?
[14:39] <seb128> because we run autoreconf at build time now
[14:40] <desrt> odd.
[14:40] <seb128> why odd?
[14:40] <seb128> that makes easier applying changes to makefile.am or configure.ac when we need to
[14:40] <desrt> right
[14:40] <desrt> i was asking because i thought maybe you did a little bit of that or something
[14:40] <desrt> anyway
[14:40] <pitti> but it underlines the argument against it: "you don't upload what you have tested"
[14:40] <desrt> i'll look into disting the introspection m4 for 0.5.1
[14:40] <seb128> desrt, thanks
[14:41] <desrt> or listen to pitti :)
[14:41] <pitti> well, autoreconf should still work somehow :)
[14:42] <desrt> it would work if you build-depends on (any) version of introspection
[14:42] <seb128> right
[14:48] <seb128> pitti, do you plan to merge dbus on debian btw? if you don't I might have a try to it
[14:52] <pitti> seb128: Keybuk claimed it, so I didn't touch it
[14:52] <seb128> pitti, did he?
[14:53] <seb128> pitti, when I asked him at the sprint he said he had no plan to work on updating dbus
[14:53] <pitti> https://merges.ubuntu.com/main.html said "Scott claims"
[14:53] <seb128> hum, k
[14:53] <pitti> of course now I can't prove it because it seems to be down :/
[14:53] <pitti> so, go ahead :)
[14:53] <seb128> anyway he will not do it apparently
[14:54] <seb128> ok, I will give it a go
[14:54] <seb128> let's see if I manage to break dbus ;-)
[14:54]  * pitti hugs seb128
[14:54] <seb128> you don't have any special way to maintain it or merge on Debian?
[14:54]  * seb128 hugs pitti
[14:54] <pitti> no, I don't; no revision control or anything
[14:54] <seb128> ok
[15:08] <ronoc> bl8: do you have package ready for maverick with your implementation of mpris2
[15:17] <ronoc> bl8: scratch that - doing the dist-upgrade now
[15:44] <kiwinote> mvo: the branch should now merge cleanly
[16:33] <ara> Hello desktop team!
[16:34] <ara> As you may know, I have started a testing project for the desktop
[16:34] <ara> it would be great if you could join the team and the mailing list and interact with the testers
[16:34] <ara> Information is here: https://wiki.ubuntu.com/Testing/DesktopTestingProgram
[16:36] <seb128> hello ara
[16:36] <seb128> ara, how are you?
[16:37] <ara> hey seb128!
[16:37] <ara> seb128, I am doing good, thanks. Starting a cold but, I'll survive
[16:37] <ara> seb128, how are you?
[16:37] <seb128> I'm fine, thanks
[16:38] <seb128> ara, nice to see that testing team being set ;-)
[16:38] <ara> seb128, yes, let's see how it goes
[16:38] <seb128> ara, do you plan to use the list to discuss bugs?
[16:39] <ara> seb128, yes, to discuss anything related to that program
[16:39] <seb128> ok
[16:39] <ara> bugs, but also testcases, or problems that people may face
[16:39] <seb128> I'm not sure I will have lot of time to do testing but I will watch what's going on
[16:39] <ara> questions right now are basic
[16:39] <ara> seb128, of course! I want you to watch and reply to questions if you have time
[16:40] <seb128> I can probably do a bit of that
[16:40] <seb128> if we have several desktopers watching and doing some replies that should be ok
[16:40] <seb128> let's see how it goes ;-)
[16:42] <ara> seb128, thanks!
[16:51] <devildante> ara: this looks neat, I'll be testing this :-)
[16:52] <mvo> kiwinote: nice, thanks
[16:55] <ara> devildante, thanks :)
[16:58] <devildante> ara: np :)
[18:04] <pitti> Good night everyone
[18:04] <devildante> goodbye, pitti :)
[18:04] <didrocks> have a good night pitti
[18:08] <Chipaca> mvo: ping
[18:15] <Chipaca> mvo: when you have a minute or thirty we can go over the usc and the ussoc
[18:26] <vish> kenvandine: hi , for Bug #531811  no need for the icon , and just make history more transparent..
[18:26] <ubot2> Launchpad bug 531811 in adium-theme-ubuntu (Ubuntu) (and 2 other projects) "History shown in Empathy chat window should be different from new messages (affects: 3) (dups: 1) (heat: 26)" [Low,Triaged] https://launchpad.net/bugs/531811
[18:26] <vish> an extra icon just makes it more noisy..
[18:32] <devildante> hi vish :)
[18:33] <vish> err , just read my earlier sentence it was half complete! :s
[18:33] <vish> *we can just make history more transparent
[18:34] <vish> devildante: hey
[18:42] <kpettit> My desktop gets some mini freezing/slowdowns that slows the mouse up and keeps keyboard from typing.
[18:43] <kpettit> It's only for a second or so here and there, but it's happening all the time and very annoying to deal with throughout the day.
[18:43] <kpettit> I have plenty of resources, Xeon processor 4GB ram and 64bit kernel.
[18:43] <kenvandine> vish, ok
[18:44] <kpettit> I monitor system resources and nothing is even approaching max.  I have a Drobo SATA drive attached, it seems to stick/slow as things access it.
[18:44] <kpettit> Any ideas how I can prevent sticking on the desktop like that?
[18:44] <vish> kenvandine: thanks. :)
[18:53] <didrocks> enough for today, have a good night!
[18:53] <mvo> Chipaca: hey, thanks but it will have to wait until tomorrow, I'm about to leave for the evening
[18:54] <mvo> Chipaca: if you want, send me a quick summary mail :) I will read it first thing in the morning
[19:27] <micahg> anyone else have an out of date cache issue on Lucid after the update-manager update today?  says package info last updated 104 days ago
[23:36] <TheMuso> Good morning.