[00:13] <bryceh> and maybe make the X logs in /var/log/lightdm readable by non-root
[01:45] <RAOF> Sweetshark: What architectures have you tested libreoffice on?
[03:59] <cyphermox> RAOF: had any btrfs-related issues lately?
[03:59] <cyphermox> I think it ate my data on one computer; I keep getting a kernel panic and fsck won't fix it ;)
[03:59] <RAOF> cyphermox: My filesystem no longer mounts :)
[03:59] <cyphermox> oh yay
[04:00] <cyphermox> exactly what I'm seeing
[04:00] <RAOF> On one system.
[04:00] <cyphermox> a spinning disk or SSD?
[04:00] <RAOF> The purpose of btrfs is to remind people that déjà dup has a “daily” option :)
[04:00] <RAOF> SSD.
[04:00] <cyphermox> ok
[04:01] <RAOF> My *other* btrfs filesystems haven't had (any new) problems.
[04:01] <cyphermox> remove_from_bitmap explodes, it seems
[04:01]  * cyphermox wishes for the best for the laptop
[04:01] <RAOF> This is actually a psuedo-laptop; it's my ivybridge SDP.
[04:01] <cyphermox> ok
[04:01] <cyphermox> it's my new tower.
[04:04]  * RAOF will bitch more fully once he's got a btrfs image of the dead filesystem and has posted to the mailing list.
[04:04] <cyphermox> k
[06:13] <BigWhale> Good Morning.
[07:16] <ricotz> seb128, morning, just a note for the nautilus problem, did you consider 05_desktop_menu_export.patch might trigger this?
[07:16] <seb128> hey ricotz, yes I did but nautilus didn't change and downgrading gtk makes the pb go awya
[07:16] <seb128> hey desktopers
[07:17] <didrocks> salut seb128 :)
[07:17] <ricotz> seb128, ok, right
[07:17] <RAOF> Yo seb128
[07:17] <seb128> hey didrocks, RAOF, how areyou
[07:17] <seb128> ?
[07:17] <didrocks> seb128: meeting report reminder!
[07:17] <didrocks> seb128: I'm fine, thanks, yourself?
[07:18] <seb128> didrocks, thanks, I'm good!
[07:23] <pitti> Good morning
[07:24] <didrocks> guten morgen pitti
[07:24] <pitti> seb128: g-i-theme> right
[07:24] <pitti> seb128: we could also consider dropping the split now that we have bigger images
[07:24] <seb128> pitti, hey, welcome back! had a good w.e?
[07:25] <seb128> pitti, thanks for your sms btw ;-)
[07:31] <Sweetshark> RAOF: amd64
[07:32] <Sweetshark> morning all
[07:34] <didrocks> hey Sweetshark
[07:34] <didrocks> Sweetshark: so still as well on this C++11 fun? :)
[07:35] <Sweetshark> didrocks: on the days at work an in the nights in my nightmares ...
[07:40] <pitti> seb128: it was great, indeed
[07:40] <pitti> seb128: we had some nice time with my family, and now I'm visiting a friend of mine
[07:40] <pitti> he became PhD yesterday and defended his thesis
[07:40] <seb128> nice
[08:54] <chrisccoulson> good morning everyone
[09:00] <didrocks> hey mr Coulson, how are you? ;)
[09:06] <didrocks> do anyone knows what launches gsettings-schema-convert at session startup?
[09:06] <didrocks> I just noted it's in python, so I think I won't use a similar code for our desktop migration tool
[09:07] <didrocks> ah, it's in fact -data-convert
[09:07] <didrocks> so ok, all C ;)
[09:57] <Sweetshark> didrocks: http://gcc.gnu.org/ml/gcc/2012-07/msg00024.html \o/
[09:59] <didrocks> Sweetshark: good, that was my discussion with the gcc guys, that it was a mistake :)
[10:18] <mpt> "Replace your changes in '/etc/gnome/defaults.list' with a later version of the configuration file?"
[10:18]  * mpt hunts for the "I Don't Know" button
[10:23] <xclaesse> seb128, out of curiosity: any progress for EDS 3.5 in Quantal?
[10:32] <ricotz> cyphermox, ^ ;)
[10:54] <pitti> seb128: meh, this jockey DBus crash is a mystery to me; we have filtered out this exception since precise
[10:55] <pitti> and stopped getting dupes ever since to LP
[11:10] <topyli> mpt: iirc it says "if you don't know, say yes" :)
[11:26] <mpt> topyli, true, but not really good enough :-]
[11:27] <topyli> it's debconf legacy
[11:28] <topyli> don't you dare touch debconf legacy! the force might disrupted become
[11:28] <pitti> it's actually not debconf, but dpkg conffiles
[11:31] <mpt> Yeah, if it was debconf I would have redesigned it already
[11:33] <Laney> If you're getting spurious conffile prompts (for files you haven't modified), then it's a bug in the package.
[11:37] <topyli> good point
[12:17] <chrisccoulson> w00t, just got a new ubuntu mouse mat
[12:30] <didrocks> heh :)
[13:07] <seb128> hum, I totally forgot to reply to backlog after lunch
[13:08] <bcurtiswx> good morning
[13:10] <seb128> pitti, hum, but whoopsie said it was reported 117 times today, but in fact the exception is different, the signature matching is not clever enough to match that
[13:10] <seb128> pitti, those have
[13:10] <seb128> "File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
[13:10] <seb128>     message, timeout)
[13:10] <seb128> DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.68 was not provided by any .service files"
[13:10] <pitti> ah, ServiceUnknown - that's indeed a different one (but equally useless by itself)
[13:12] <seb128> pitti, i.e https://errors.ubuntu.com/oops/0001b602-9b7c-11e1-98aa-e4115b0f8a4a
[13:14] <seb128> pitti, ok, so those bugs stacktrace match https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/881992
[13:14] <ubot2> Ubuntu bug 881992 in jockey "jockey-text crashed with DBusException in call_blocking(): org.freedesktop.DBus.Error.ServiceUnknown: The name :1.75 was not provided by any .service files" [Medium,Confirmed]
[13:15] <pitti> seb128: not quite
[13:15] <pitti> seb128: but close enough, I guess
[13:16] <seb128> hum, indeed, not quite the same stacktrace
[13:16] <pitti> https://bugs.launchpad.net/ubuntu/+source/jockey/+bugs?field.searchtext=org.freedesktop.DBus.Error.ServiceUnknown
[13:17] <seb128> I hate all those dbus timeout or service issues bugs in python processes
[13:17] <pitti> right, these are just equally useless
[13:17] <pitti> unless d-bus activation itself is buggy
[13:18] <pitti> duped the other two to 881992
[13:18] <seb128> thanks
[13:19] <pitti> I wonder if these are from a live environment
[13:19] <pitti> or something which could cause activation to take more than the timeout
[13:19] <seb128> pitti, some are ... you think it's too slow and goes to timeout?
[13:19] <pitti> I don't know really
[13:19] <seb128> like that bug states "Using live install from USB on an Asus EEE 1015px netbook with Windows 7 starter installed"
[13:19] <pitti> the error message tells me no reason at all, just that activation failed
[13:20] <pitti> but judging by https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=org.freedesktop.DBus.Error.ServiceUnknown I'm not alone with this
[13:20] <seb128> right, same issue that didrocks is getting with oneconf bugs
[13:20] <pitti> where "I" == jockey
[13:21] <pitti> so I don't think it's a specific bug in jockey
[13:21] <seb128> no
[13:21] <seb128> well as you said the error is useless as well
[13:21] <pitti> so we could certainly ignore those in apport
[13:21] <didrocks> +1 on hating this :)
[13:21] <seb128> you could have a real bug which makes the service hang
[13:21] <pitti> almost useless, yes
[13:21] <pitti> but the S/N ratio is ridiculously low
[13:21] <pitti> so if we want to filter it out, WFM
[13:23] <seb128> pitti, can we figure a way to get a status dump from the service in those cases?
[13:23] <pitti> seb128: what kind of status?
[13:23] <pitti> pidof perhaps
[13:23] <seb128> pitti, knowing if the service is running, hanging, using cpu, failing to start...
[13:24] <seb128> if it's installed
[13:24] <seb128> pitti, we either find a way to make those bugs useful or ignore them
[13:24] <pitti> yes, I think that's a good idea
[13:24] <seb128> the issue is that I'm concerned we do filter out some valid bugs affecting the service side by just dropping those reports
[13:24] <seb128> pitti, I will open a bug on apport for discussion, ok?
[13:24] <pitti> woudl you mind filing a bug about this with your ideas?
[13:25] <pitti> seb128: merci beaucoup
[13:25] <seb128> pitti, danke schön ;-)
[13:25] <pitti> seb128: yes, we could then file bugs for "nonexisting", "not responding", or "not running"
[13:25] <pitti> where the first and last would be actually useful
[13:26] <pitti> I'm debugging a race condition in udisks today (all day already, ugh), will look at this later in the week
[13:26] <seb128> right
[13:26] <seb128> pitti, no hurry, thanks
[13:26] <seb128> one another class of bugs I hate is "DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /tmp/dbus-gja1frOF6L: Connection refused"
[13:27] <pitti> seb128: for the "not responding" case we could use the machinery being developed by ev for hanging apps
[13:27] <seb128> oh yeah, good idea
[13:27] <pitti> but I need to think about this, we can't ask the user about that
[13:33] <tkamppeter> pitti, hi
[13:34] <pitti> hey tkamppeter
[13:34] <tkamppeter> pitti, it is about bug 1020480
[13:34] <ubot2> Launchpad bug 1020480 in cups "package cups-bsd 1.5.3-0ubuntu1 failed to install/upgrade: il sottoprocesso vecchio script di pre-removal ha restituito lo stato di errore 127" [Medium,Triaged] https://launchpad.net/bugs/1020480
[13:35] <tkamppeter> pitti, the update fails because the update-inetd executable is missing for the prerm script. I have checked and cups-bsd already depends on update-inetd. Is a stronger dependency needed here?
[13:37] <pitti> tkamppeter: hm, no off-hand idea about this, I'm afraid; Depends should be fine
[13:39] <pitti> tkamppeter: perhaps you can ask the guy about "which update-inetd" and whether update-inetd is installed?
[13:42] <desrt> good morning everyone
[13:42] <desrt> didrocks: i notice you have an item marked 'DONE' in daily blames.  is that actually setup with QA now?
[13:43] <tkamppeter> pitti, thank you, done.
[13:44] <didrocks> desrt: there are some unit python tests (as well as a bunch of other tests) and jibel is deploying them this week
[13:44] <desrt> sweet
[13:44] <desrt> i'll be happy to finally have those online
[13:45] <didrocks> desrt: basically, I'm getting your output, revamping it a little bit to be python unittest like :)
[13:46] <didrocks> desrt: oh, and incoming unity release doesn't write to dconf at all, even on first logging
[13:46] <desrt> sweetness
[13:46] <didrocks> login*
[13:46] <didrocks> even :)
[13:47] <desrt> i wonder if we still have that weird issue on the guest session
[13:47] <seb128> didrocks, pitti: bug #1020572
[13:47] <ubot2> Launchpad bug 1020572 in apport "Deal better with DbusException errors" [Undecided,New] https://launchpad.net/bugs/1020572
[13:47] <seb128> desrt, good morning ;-)
[13:48] <didrocks> seb128: sweet, thanks!
[13:48] <didrocks> desrt: which issue?
[13:48] <desrt> seb128: hey :)
[13:48] <cyphermox> xclaesse: EDS 3.5: working on getting it to -proposed now
[13:49] <desrt> didrocks: i think the setting to disable the lock in the screensaver gets written to gconf on guest session login and then the gsettings migration reads it from gconf and writes it to dconf
[13:49] <pitti> seb128: thanks
[13:49] <desrt> it's a bit ridiculous :)
[13:49] <xclaesse> cyphermox, cool :)
[13:49] <didrocks> desrt: oh right, let's see how it goes :)
[13:49] <desrt> didrocks: now that i think about it, though, it may simply not be possible to do this in a substantially better way
[13:49] <desrt> ie: even if we get rid of the ridiculous gconf stuff, it's still a write to dconf
[13:50] <cyphermox> xclaesse: sorry, I was hoping to get to coordinate an upload of thunderbird w/ chrisccoulson too for this, but couldn't discuss it with him on Friday :)
[13:50] <didrocks> desrt: indeed, still a write to it :/
[13:50] <desrt> i don't care too much about that, though
[13:50] <desrt> guest sessions are not normal
[13:50] <desrt> and this is one case where doing that write really does make sense in a weird way
[13:50] <xclaesse> cyphermox, how is thunderbird related to EDS?
[13:50] <didrocks> the test is running on a normal fresh user session :)
[13:51] <desrt> didrocks: one other thing: were you going to be the one looking into using dconf profiles as a more flexible alternative to gsettings schema overrides?
[13:51] <desrt> (i recall this now becuase it is a way we could get the guest session to work, but i doubt that it is worth it)
[13:51] <cyphermox> xclaesse: thunderbird builds a binary that depends on some eds libraries, and to avoid breaking things I'd like to be able to land things in -proposed first then copy to -release when things are ready and pretty stable
[13:52] <didrocks> desrt: hum, I don't remember about that. I expressde interest in the past about per session dconf profile, but we don't really need it anymore, at least, for now
[13:52] <desrt> didrocks: the idea was so that we could have a more-upstream-like gnome session
[13:52] <desrt> without the overrides
[13:52] <cyphermox> xclaesse: for thunderbird, it's addressbook integration
[13:52] <xclaesse> cyphermox, ah ok, good :)
[13:53] <xclaesse> cyphermox, there is folks using new EDS as well
[13:53] <didrocks> ah, no, you didn't discuss that with me, but I can get what you mean :)
[13:53] <cyphermox> xclaesse: indeed, so kenvandine was very much looking forward to it ;)
[13:53] <didrocks> hum, not sure it worthes it now TBH, apart if we really have overriden settings not compatible at all with other non default cases
[13:53] <xclaesse> cyphermox, dunno if EDS 3.4 is parallel installable with 3.5...
[13:54] <cyphermox> xclaesse: that's why we need to go through -proposed; or more exactly why it would be better, to avoid having uninstallable binaries
[13:55] <xclaesse> ok I see :)
[13:55] <xclaesse> thanks
[13:55] <cyphermox> as soon as I figure out why sbuild disappeared from my system I'll do one last build test for eds and upload somewhere
[13:55] <kenvandine> cyphermox, :)
[13:57] <cyphermox> I was having issues with one of the addressbook tests failing to build because it didn't have -fPIC
[14:00] <desrt> didrocks: it was an idea we wanted to implement at UDS.  i just don't remember who took the item :)
[14:01] <desrt> it could have been robert
[14:01] <seb128> dobey, hey, could somebody from u1 look at trapping the error from bug #937132 for the next sso SRU?
[14:01] <ubot2> Launchpad bug 937132 in ubuntu-sso-client "ubuntu-sso-login crashed with RuntimeError in /usr/lib/python2.7/dist-packages/gi/overrides/Gdk.py: Gdk couldn't be initialized" [High,Confirmed] https://launchpad.net/bugs/937132
[14:02] <didrocks> desrt: won't it be a perf regression? I mean, you have to open multiple files instead of just two (the system one and the user one). Maybe negligeable, but still :)
[14:02] <desrt> didrocks: pretty small indeed
[14:03] <desrt> dconf lookups are ~hashtable speed
[14:03] <desrt> also: this other database would never be written to.  lovely :)
[14:03] <cyphermox> seb128: fyi, going to go mobile this afternoon to try and debug WPA enterprise auth issues; which require me to go to my university, so I'm likely to be offline for a little while during the time wifi is being debugged ;)
[14:03] <didrocks> indeed :)
[14:03] <seb128> cyphermox, ok, no worry, good luck with the debugging!
[14:03] <cyphermox> yeah :/
[14:04] <cyphermox> not sure how luck will play, seems to be something funky in how wpasupplicant speaks to openssl, and generally black magic
[14:04] <seb128> cyphermox, don't forgot the file up https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-07-03 with what you did or topic if you a minute before going ;-)
[14:04] <cyphermox> seb128: I'll only be leaving in a couple of hours, after lunch and all
[14:04] <seb128> ok
[14:04] <cyphermox> trying to finish up eds first :)
[14:05] <seb128> cool
[14:05] <mdeslaur> cyphermox: oh, what issues are those? Maybe it's related to broken openssl tls 1.1 in precise?
[14:05] <dobey> seb128: any idea why that one is happening? i started looking at it, but the correct fix requires a fairly large bit of refactoring unfortunately.
[14:06] <cyphermox> mdeslaur: somewhat related to tls 1.1 yes
[14:06] <cyphermox> mdeslaur: fortunately there is possibly an easy workaround for wpasupplicant which I can apply without breaking too many things; SSL_NO_OP_TICKET might help a lot
[14:06] <mdeslaur> cyphermox: ok, then it's a known openssl issue that I will fix soon....see #1018998
[14:06] <seb128> dobey, I would say it's noise, but if we could trap it in a try: catch: to avoid spamming users with whoopsie system errors dialogs...
[14:06] <cyphermox> mdeslaur: the issue is tentatively caused by the Session Ticket extension in TLS
[14:07] <mdeslaur> cyphermox: ah, ok, possibly unrelated then
[14:07] <seb128> dobey, by experience those are happening at session closing or for people who try to run the said command over an ssh or a vt
[14:07] <cyphermox> mdeslaur: well, kind of related. TLS is painful for everyone ;)
[14:07] <mdeslaur> hehe
[14:08] <cyphermox> ohh; actually it might be very very relevant
[14:08] <dobey> seb128: right. would just like to know what people are doing exactly, to get that
[14:08] <dobey> seb128: hard to write tests when i have no idea why things are happening :)
[14:09] <cyphermox> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/969343
[14:09] <ubot2> Ubuntu bug 969343 in oem-priority "Unable to connect to WPA enterprise wireless" [High,In progress]
[14:09] <dobey> seb128: also, is there any way to see a report for a specific version on e.u.c? one of the issues lists "latest seen" version as being the version the issue should have been fixed in
[14:09] <dobey> which is of course, odd
[14:10] <seb128> dobey, no, it's a known issue and being worked
[14:10] <seb128> dobey, it's on ev's list
[14:10] <dobey> ok
[14:10] <seb128> dobey, that can happen because current whoopsie report the installed version at issue time, not the running version
[14:10] <dobey> ah ok
[14:10] <seb128> dobey, so if users upgraded and didn't restart and the process hit the bug you will get the wrong version reported...
[14:11] <mdeslaur> cyphermox: ah! yes, that could definitely be related...just rebuilding wpasupplicant with the release version of openssl in precise should solve the issue
[14:11] <mdeslaur> cyphermox: or, wait a couple of days until I push an openssl update to -proposed
[14:11] <cyphermox> mdeslaur: what do you mean rebuilding?
[14:11] <mdeslaur> cyphermox: no change rebuild
[14:12] <cyphermox> rebuilding shouldn't be necessary here, just starting a new wpasupplicant process should be sufficient no?
[14:12] <dobey> seb128: or if the crash already happened in precise, and then they didn't report the issue until after an upgrade to quantal that was happening during the user's session where the crash happened?
[14:12] <mdeslaur> cyphermox: no because wpasupplicant was built with openssl 1.0.0, so it disables tls v1.1 by mistake
[14:12] <mdeslaur> cyphermox: "Any package in the repo that got compiled on oneiric, or on precise before 2012-03-24 02:03:49 EDT got compiled with SSL_OP_ALL set to 0x80000FFFL, and is telling openssl on precise to disable tls v1.1."
[14:13] <cyphermox> ah, interesting
[14:13] <cyphermox> but then SSL_OP_NO_TICKET couldn't possibly fix anything
[14:13] <cyphermox> ... because TLS 1.1 is already disabled, so its extensions should also be ;)
[14:14] <seb128> dobey, no, versions are collected at the incident time
[14:14] <seb128> dobey, not at the report time
[14:14] <cyphermox> mdeslaur: anyway, I'll test just rebuilding it; I much rather if that fixes things than crippling wpa supplicant and EAP-FAST support
[14:15] <mdeslaur> cyphermox: I would start by simply rebuilding it and seeing if that solves it...the problem could be completely unrelated to the openssl issue though, but you'll see right away
[14:15] <dobey> seb128: ok, something is weird then, because the ubuntuone-installer issue shows the quantal version as the last seen, which has the fix for the issue :-/
[14:15] <cyphermox> mdeslaur: right
[14:18] <mpt> "Python (v2.7) requires to install plugins to play media files of the following type: text/html decoder" -- yeah, like that's ever going to work
[14:19] <seb128> dobey, well, maybe somebody was running the installer and upgrading at the same time
[14:21] <dobey> seb128: maybe
[14:25] <seb128> dobey, speaking of which, when do you plan to SRU that one? ;-)
[14:34] <dobey> seb128: not sure, it needs a bit more work, as failing apt updates from PPAs and such breaks it now
[14:35] <dobey> brb
[15:16] <didrocks> desrt: hey, I see not anymore /etc/dconf/profiles or whatever, is it intended?
[15:16] <desrt> didrocks: you'd be amazed how often i get this question :)
[15:17] <desrt> didrocks: i'm a young-earth creationist
[15:17] <didrocks> heh :)
[15:17] <desrt> i believe that files in /etc need to be created
[15:17] <desrt> and that they were not simply caused to exist from nothing
[15:18] <desrt> the default configuration is emptiness
[15:18] <desrt> some intelligent creator needs to come along to change that
[15:18] <seb128> desrt, what is we got only dumb creators?
[15:18] <seb128> if
[15:18] <didrocks> that's a valid point seb128 :)
[15:19] <didrocks> desrt: as a reminder, those profiles are stacked dconf databases, right? reading from bottom to top?
[15:19] <desrt> didrocks: or top to bottom, depending on perspective
[15:19] <desrt> the one on the top is the one that gets checked 'first'
[15:19] <desrt> ie: if you have the same setting in two databases the the first one wins
[15:19] <didrocks> and the one where writing will happen?
[15:19] <cyphermox> what's everyone's feeling re: the "Sent from Ubuntu" signature patch in Evolution?
[15:20] <didrocks> cyphermox: we can kill it
[15:20] <Laney> destroy it
[15:20] <seb128> cyphermox, kill
[15:20] <cyphermox> I'd be inclined to drop it or just merge it into the Evolution autogenerated one
[15:20] <didrocks> was an awesome hack, I liked it though, but well ;)
[15:20] <desrt> didrocks: the writing always happens in the first one
[15:20] <desrt> didrocks: it's the only way it makes sense, if you consider it
[15:21] <desrt> didrocks: if the writing happens to the bottom one and the first one has a key then you will never see the new value that you wrote
[15:21] <cyphermox> dropping it is; but if someone screams let me know and I have an idea how to fix it
[15:21] <didrocks> desrt: agreed, but prefer double checking. And so, how does this play with ${XDG_CONFIG_DIR}/dconf/user? :)
[15:21] <desrt> it does not?
[15:22] <didrocks> ah, so you are not looking for this env variable?
[15:22] <seb128> cyphermox, there will be no screaming don't worry
[15:22] <desrt> no
[15:22] <didrocks> mterry tried to trick me!
[15:22] <desrt> /etc is hardcoded, i think
[15:22] <didrocks> it's a shame :)
[15:22] <pitti> hm, very confusing; since today's upgrades, terminal windows gradually shrink themselves vertically over time
[15:22] <desrt> and there is no expansion done on variable names in the file
[15:22] <kenvandine> pitti, that sounds like fun
[15:22] <desrt> pitti: that sounds like compiz :D
[15:22] <pitti> hey kenvandine, how are you?
[15:22] <kenvandine> good
[15:23] <desrt> pitti: and almost certainly something to do with the grid sizing constraints...
[15:23] <mterry> didrocks, what did I lie about?
[15:23] <kenvandine> my terminals aren't shrinking yet, so better than you i guess :)
[15:23] <pitti> mterry: hey Mike, good morning
[15:23] <mterry> pitti, hello!
[15:23] <pitti> mterry: very happy to see the u-m autopkgtest :)
[15:23] <didrocks> desrt: ok, so the only env variable you are using is ${XDG_DATA_DIRS}/glib-2.0/schemas/gschemas.compiled, right?
[15:23] <mterry> pitti, yeah.  :) still needs more tests, but it's a start
[15:23] <desrt> didrocks: yes.  gsettings consults the XDG_DATA_DIRS
[15:24] <didrocks> mterry: XDG_CONFIG_DIR is not used for values checking, the magic happens in /etc/dconf/profile
[15:24] <desrt> didrocks: incidentally, i feel quite strongly about the way that gsettings uses paths
[15:24] <pitti> mterry: it failed, it's at least missing a python-mock dep and apparently something else
[15:24] <mterry> desrt, oh it doesn't use CONFIG_DIR ?  Well, it at least uses HOME I believe
[15:24] <desrt> didrocks: but i'm not as totally convinced about dconf
[15:24] <didrocks> desrt: ah?
[15:24] <mterry> desrt, I know I've been able to fake it to use a different location
[15:24] <pitti> desrt: ah, blaming compiz then :)
[15:24] <desrt> mterry: you can set DCONF_PROFILE=(absolute path)
[15:24] <didrocks> pitti: no compiz update from today, juts to say ;)
[15:25] <desrt> in that case it will skip looking in /etc
[15:25] <mterry> desrt, yar, but without doing that I've gotten it to use a custom database path
[15:25] <mterry> pretty sure it was just CONFIG_DIR
[15:25] <desrt> XDG_CONFIG_DIR, you mean?
[15:25] <mterry> yeah
[15:25] <desrt> i avoided using that because the default value is /etc/xdg/
[15:25] <desrt> which i consider to be just plain stupid
[15:25] <mterry> desrt, oh shit, sorry.  XDG_CONFIG_HOME?
[15:25] <mterry> The user's one
[15:25] <desrt> oh yes.  that works of course.
[15:26] <mterry> didrocks, ^ sorry, XDG_CONFIG_HOME, not _DIR
[15:26] <didrocks> ahah :)
[15:26] <desrt> that will put the user's database into a different directory
[15:26] <didrocks> so, reiterating my question
[15:26] <didrocks> desrt: I guess XDG_CONFIG_HOME is set "on top of the stack" compared to /etc/dconf/profile ?
[15:27] <mterry> pitti, :(  OK.  So I ran the tests using adt-run locally.  Is there a good way to run them in a closer environment to jenkins to hit such issues?
[15:27] <didrocks> on top meaning "where you will write"?
[15:27] <desrt> didrocks: it depends on how you setup the profile
[15:27] <pitti> mterry: I set up a kvm instance which is pretty close to jenkins'
[15:27] <pitti> mterry: hang on
[15:27] <desrt> didrocks: probably you want to do this: create a dconf profile called "unity" (ie: file in /etc/dconf/profile/unity)
[15:27] <desrt> put in it these two lines (in order):
[15:27] <desrt> user-db:user
[15:27] <desrt> system-db:unity
[15:28] <desrt> then create /etc/dconf/db/unity.d/ and put some keyfiles there
[15:28] <desrt> then 'dconf update'
[15:28] <desrt> then when you set DCONF_PROFILE=unity it will read the values from the /etc/dconf/db/unity if the user has not set their own values
[15:28] <pitti> mterry: http://jblablog.wordpress.com/2012/06/19/local-ubuntu-vm-provisioning-with-cloud-init/
[15:28] <pitti> mterry: basically, it's a standard server cloud image which I start with -snapshot
[15:28] <didrocks> desrt: user-db is matching the XDG_CONFIG_HOME value?
[15:29] <desrt> didrocks: yes
[15:29] <didrocks> desrt: do you have a doc for this profile or are there only those 2 keywords? (user-db and system-db)
[15:29] <desrt> user-db:x corresponds to a file in $XDG_CONFIG_HOME/dconf/x
[15:29] <desrt> didrocks: https://live.gnome.org/dconf/SystemAdministrators
[15:29] <didrocks> desrt: perfect, that will avoid me bothering you more! :)
[15:29] <didrocks> desrt: seems straightforward, thanks!
[15:30] <pitti> mterry: a pbuilder login might suffice as well, though
[15:30] <mterry> pitti, ah nice.  I was hoping for a one liner, but I'll take what I can get.  dep8 will be tough for people to adopt without being able to easily test
[15:30] <mterry> pitti, you don't get X with that though
[15:30] <pitti> mterry: for your case, anyway; I need an actual vm for some of the stuff I'm testing (like udisks)
[15:30] <pitti> mterry: jenkins VM are not running X
[15:30] <pitti> mterry: you need to use xvfb-run if you do
[15:31] <mterry> pitti, oh really?  I thought we had that available.  OK.  Hmm..  I think one of the u-m tests briefly displays a window
[15:31] <mterry> pitti, well that's good then.  I know pbuilder  :)
[15:36] <pitti> desrt: ah, I did get a new compiz this morning; it also seems to hang every hour, very annoying :(
[15:36] <pitti> popey: ^ am I the only one seeing this?
[15:36] <popey> news to me
[15:37] <popey> pitti, what chipset?
[15:37] <pitti> popey: Intel Arrandale
[15:38] <popey> pitti, what version do you have now?
[15:38] <pitti> popey: 1:0.9.8+bzr3249-0ubuntu2
[15:39] <popey> pitti, anything that triggers it?
[15:40]  * popey is running it here on intel sandybridge and has had no lockups
[15:40] <pitti> popey: hard to say; I have worked on udisks test suite all day, which causes quite a bit of load
[15:40] <pitti> I'll watch it more closely
[15:41] <pitti> I also got a new kernel and other stuff, all updates since Friday
[15:41] <popey> i have had my hang recently when doing vast IO on quantal
[15:41] <popey> *my laptop
[15:41] <dobey> yay a new image got built today. wonder if works any better on my system
[15:49] <chrisccoulson> we need something like this for when launchpad is offline: http://hardhat.mozilla.net/en-US/bugzilla.html
[15:54] <didrocks> chrisccoulson: heh, unfortunately, the down time is really small now :)
[15:57] <seb128> didrocks, chrisccoulson, kenvandine, tkamppeter, Laney, mlankhorst, mterry, cyphermox, Ursinha: ups, we are bit past meeting time ... did anyone had a topic to discuss (none on the wiki)?
[15:58] <didrocks> seb128: didn't you want to discuss about WI status?
[15:58] <chrisccoulson> Nothing to discuss, but I might add some stuff to the wiki in a bit
[15:59] <seb128> didrocks, good point
[15:59] <kenvandine> nope
[15:59] <seb128> not so much needed to discuss as a team
[15:59] <seb128> I've tried to talk directly to people about their items
[15:59] <didrocks> will you get killed on Friday? Should we find a backup or a volonteer to go to the meeting? :)
[16:00] <seb128> didrocks, chrisccoulson, kenvandine, tkamppeter, Laney, mlankhorst, mterry, cyphermox, Ursinha, bryceh, RAOF, TheMuso: please make sure to update your workitems regularly and start considering to drop some feature work if you are behind
[16:00] <seb128> http://status.ubuntu.com/ubuntu-quantal/canonical-desktop-team-quantal-alpha-3
[16:00] <seb128> doesn't look good :p
[16:00] <kenvandine> indeed
[16:00] <kenvandine> i'll review them
[16:00] <Ursinha> seb128, ack
[16:01] <mterry> seb128, pre-emptively drop feature work?  I have some stuff I know I probably won't get to, but I was going to wait until post FF to officially drop them from WI.  Should I just do it now?
[16:01] <Laney> Well, I'm a bit concerned about g-s-d/g-c-c lagging
[16:02] <didrocks> Laney: gsettings compiz is coming
[16:02] <seb128> mterry, if we will not get to it yes, I started dropping some of stuff or talking to people about dropping early
[16:02] <didrocks> Laney: Normally this week, ask popey for the status
[16:02] <seb128> Laney, right, me as well
[16:02] <Laney> didrocks: we don't need to block the updates on that though, do we?
[16:02] <seb128> Laney, as didrocks says, that's blocked on compiz and should be unblocked withing a week
[16:02] <didrocks> Laney: we do
[16:03] <didrocks> Laney: the patches are intrusive, (reverting gsettings)
[16:03] <didrocks> so not easy to update them
[16:03] <didrocks> knowing it's to drop them anyway afterwards
[16:03] <didrocks> so better to update and drop the patch at the same time
[16:03] <didrocks> but for that, we need compiz understanding gsettings
[16:04] <Laney> well I did actually do the 3.5.4 update the other day but it didn't work properly
[16:05] <Laney> aha
[16:05] <Laney> the patches are already dropped in bzr
[16:07] <seb128> right
[16:07] <seb128> the vcs is ready for the new compiz
[16:07] <seb128> what didn't work properly?
[16:07] <seb128> we should get g-s-d and g-c-c in a state where they work properly
[16:07] <seb128> out of keybindings changes
[16:07] <seb128> which will come with compiz
[16:08] <Laney> hum, let me see, I posted it on the bug
[16:08] <Laney> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1008840/comments/5
[16:08] <ubot2> Ubuntu bug 1008840 in gnome-settings-daemon "Update to 3.5.4" [Wishlist,Triaged]
[16:09] <seb128> shrug
[16:09] <seb128> the keyboard stuff is going to be a pain
[16:09] <seb128> not speaking about the keybindings
[16:09] <seb128> but rather their refactoring to use ibus
[16:09] <seb128> we will probably need to rewrite our indicator patch
[16:09] <Laney> who maintains that?
[16:10] <seb128> Laney, that? the keyboard indicator?
[16:10] <Laney> oh, thought you were referring to the patch I referenced there
[16:10] <Laney> but yes, that also
[16:10] <seb128> same story
[16:10] <seb128> it got done by dx by then and we "maintain" it
[16:12] <Laney> ok
[16:18] <seb128> ok, I guess that was all for the meeting, thanks guys ;-)
[16:18] <mlankhorst> seb128: hey ok, I'll update, still getting the work done that I want to get done though, :)
[16:19] <seb128> Laney, let's try to get those updates in the ubuntu-desktop ppa for extra testing
[16:19] <seb128> mlankhorst, hey, good, thanks ;-)
[16:19] <mlankhorst> it's just this item taking slightly longer.. [mlankhorst] make sure dmabuf synching framework is suitable for i915/nouveau: INPROGRESS
[17:07] <didrocks> good night everyone :)
[18:17] <desrt> seb128: you're on ecryptfs, right?
[18:24] <cyphermox> kenvandine: is folks ready?
[18:25] <desrt> anyone here has an ecryptfs home directory?
[18:25] <desrt> if so, please run this and share the output: strace -e trace=statfs df ~
[18:26] <kenvandine> cyphermox, not yet, but it can be very soon :)
[18:26] <kenvandine> cyphermox, eds in -proposed?
[18:29] <cyphermox> kenvandine: not yet, but it can be very soon ;)
[18:29] <cyphermox> I'm finishing up building evo locally; then I'll upload to my PPA just to be sure
[18:29] <kenvandine> haha
[18:30] <cyphermox> evolution-exchange will go much quicker
[18:30] <kenvandine> cyphermox, ok, just let me know when eds makes it
[18:30] <cyphermox> but at least eds, gtkhtml, evo will be ready
[18:30] <cyphermox> sure
[18:30] <kenvandine> i can have folks done quickly
[18:30] <cyphermox> it's a matter of minutes
[18:30] <kenvandine> cool
[18:30] <kenvandine> folks will be a soname change and stuff
[18:31] <kenvandine> so more than just a rebuild
[18:31] <kenvandine> i want to build it :)
[18:31] <cyphermox> chrisccoulson wants to upload thunderbird tomorrow maybe; so if it could all be in proposed by then we could promote everything tomorrow
[18:31] <kenvandine> wfm
[18:31] <cyphermox> the most annoying ones are really eds, evo, gtkhtml, gnome-contacts and folks afaict
[18:32] <kenvandine> i'll do gnome-contacts too
[18:32] <cyphermox> ok
[18:32] <kenvandine> i am knee deep in gnome-contacts right now :)
[18:32] <cyphermox> depends on folks, right?
[18:32] <kenvandine> yes
[18:32] <cyphermox> cool
[18:32] <cyphermox> kenvandine: fyi: http://people.ubuntu.com/~mathieu-tl/transitions/
[18:33] <kenvandine> SWEET
[18:33] <kenvandine> i should set that up for when i do libindicator or dbusmenu transitions :)
[18:33] <cyphermox> ah, the indicators is what I was forgetting
[18:33] <Streamstormer> desrt, http://paste.ubuntuusers.de/raw/409427/
[18:33] <cyphermox> kenvandine: normally should take into account -proposed too; but I update the files manually
[18:34] <kenvandine> cyphermox, i can do indicator-datetime as well
[18:34] <Streamstormer> desrt, in precise
[18:34] <kenvandine> unless you have that already
[18:34] <Streamstormer> desrt, *on precise
[18:34] <cyphermox> not started yet, but you don't have to take everything ;)
[18:34] <desrt> Streamstormer: i was more interested in the output of strace :)
[18:35] <kenvandine> cyphermox, you can do it :)
[18:36] <desrt> Streamstormer: ie: the contents of the statfs() line
[18:36] <Streamstormer> desrt, ? But this is the output?? There is nothing else..
[18:37] <desrt> Streamstormer: strace didn't produce any output?  very odd...
[18:49] <Streamstormer> desrt, No statfs() output on quantal too..
[18:49] <desrt> that's very odd.  i get statfs output here.
[18:49] <desrt> what command are you typing?
[18:51] <Streamstormer> desrt, strace -e trace=statfs df ~
[18:51] <desrt> i wonder why that works fo rme
[18:51] <desrt> also on precise...
[18:51] <desrt> maybe try like this: strace df ~ 2>&1 | grep statfs
[18:52] <desrt> i'd say that the different may be because of ecryptfs but in theory the statfs syscall is how it determines what fs type you have in the first place
[18:52] <Streamstormer> desrt, \o/
[18:52] <Streamstormer> desrt, statfs64("/home/benedikt", 84, {f_type=0xf15f, f_bsize=4096, f_blocks=130988792, f_bfree=63308642, f_bavail=56751830, f_files=32784384, f_ffree=32461997, f_fsid={1353147257, 1045600430}, f_namelen=143, f_frsize=4096}) = 0
[18:52] <desrt> ahh... are you on i386?
[18:53] <Streamstormer> desrt, yes
[18:53] <desrt> that certainly explains it
[18:53] <desrt> thanks :)
[18:53] <Streamstormer> desrt, np :)
[18:53] <desrt> #define ECRYPTFS_SUPER_MAGIC    0xf15f
[18:53] <desrt> hm.  fascinating.
[18:58]  * desrt would have expected a single magic number for all FUSE-based filesystems
[19:54] <kenvandine> cyphermox, there is an eds 3.5.3.1 which contains the fixes libfolks needs
[19:54] <cyphermox> great
[19:54] <cyphermox> yeah I had to play around with evo 3.5.3.1 already
[19:55] <kenvandine> cyphermox, folks won't build with 3.5.3, so good.. you're going to be upload 3.5.3.1 then?
[19:56] <cyphermox> yes
[19:56] <kenvandine> awesome
[19:56] <kenvandine> thx
[19:56] <cyphermox> it's not that much more work once the heavy lifting is done
[19:56]  * cyphermox is downloading the tarball now
[19:56] <kenvandine> i tried to build against what you have in your ppa
[19:56] <cyphermox> oh cool
[19:56] <kenvandine> won't though :)
[19:57] <cyphermox> I think all I have to do is update the tarball now, so I'll push it again in a minute
[19:58] <kenvandine> thx
[19:58] <kenvandine> if you can do a push of your packaging branch somewhere too i can kick off a local build as well
[19:59] <cyphermox> ahh it's all there already
[19:59] <cyphermox> lp:~mathieu-tl/evolution-data-server/release-3.5.3
[19:59] <cyphermox> I'm updating it with the changelog change to 3.5.3.1 now
[20:00] <cyphermox> I've been pushing everything to LP quickly for fear of a filesystem crash
[20:03] <kenvandine> great
[20:04] <kenvandine> hummm... my wife just reminded me tomorrow is a holiday
[20:04] <cyphermox> kenvandine: yeah
[20:05] <cyphermox> kenvandine: do you have your stuff in a branch, I'll gladly carry on
[20:05] <kenvandine> cyphermox, not yet
[20:05] <kenvandine> cyphermox, if i can't finish it i'll point you at it
[20:05] <kenvandine> thx!
[20:06] <cyphermox> ah crap, gnome-keyring had evo fail :/
[20:10] <cyphermox> I suck; missing build-dep
[20:10] <dobey> kenvandine: heh, did you forget to take tomorrow off?
[20:15] <kenvandine> dobey, almost!
[20:15] <kenvandine> dobey, i've missed several holidays... just forget :)
[20:16] <dobey> heh
[20:16] <cyphermox> kenvandine: evolution-data-server 3.5.3.1 just uploaded to my ppa
[20:16] <kenvandine> cyphermox, cool
[20:45] <kenvandine> cyphermox, libedataserver1.2-dev needs to depend on libgnome-keyring-dev too
[20:46] <cyphermox> right, that's why evolution ftbfs
[20:46] <kenvandine> breaks things that build deps on eds
[20:53] <kenvandine> cyphermox, i have folks and empathy prepared
[20:54] <kenvandine> cyphermox, in fact, i can go ahead and upload them to -proposed and they'll depwait
[20:59] <cyphermox> kenvandine: cool; if that's all that was missing I'll upload e-d-s as soon as it's done building here again
[21:00] <kenvandine> cyphermox, that's it :)
[21:00] <kenvandine> just get that depends fixed
[21:00] <kenvandine> assuming you did
[21:01] <cyphermox> yup, building in the ppa now
[21:01] <cyphermox> I gave infinity a head's up about the uploads
[21:01] <kenvandine> awesome
[21:01] <kenvandine> i'll upload
[21:02] <cyphermox> ok
[21:03] <cyphermox> still hacking at evolution though, there's a segfault in /usr/lib/evolution/evolution-source-registry
[21:20] <kenvandine> cyphermox, folks and empathy uploaded and will depwait
[21:21] <kenvandine> cyphermox, i didn't get to gnome-contacts, can you do that?
[21:21] <cyphermox> thanks
[21:21] <cyphermox> yes, I'll take care of it
[21:21] <cyphermox> after dinner actually
[21:21] <cyphermox> thanks to mbarnes the evo issue got figured out; e-d-s needs to building without -Bsymbolic-functions
[21:22] <kenvandine> cyphermox, cool... thanks!
[21:22] <kenvandine> i need to head out
[21:23] <cyphermox> ok
[21:24] <seb128> cyphermox, do you know how to strip that out?
[21:24] <cyphermox> not really ;)
[21:25] <seb128> cyphermox, look to gnome-bluetooth as an example
[21:25] <cyphermox> ah, thanks
[21:25] <seb128> LDFLAGS=$(shell echo $$LDFLAGS | sed -e 's/-Wl,-Bsymbolic-functions//')
[21:25] <seb128> export LDFLAGS
[21:25] <seb128> cyphermox, in the rules
[21:25] <cyphermox> yeah
[21:25] <cyphermox> I thought there was a less hackish way :)
[21:25] <seb128> sorry I didn't see that you had that issue earlier
[21:25] <cyphermox> seb128: I only just found out
[21:25] <seb128> I read about that some days ago
[21:26] <seb128> ok, so you didn't lost too much time, good
[21:26] <seb128> fta run into it some days ago
[21:26] <cyphermox> I would never have been able to tell that that crash was caused by that flag
[21:26] <seb128> he was speaking about it on #evolution with mbarnes
[21:26] <cyphermox> ahah :)
[21:26] <seb128> they are easy to reconize once you saw one
[21:26] <seb128> the gtype warnings
[21:26] <cyphermox> ah ok
[21:26] <seb128> I guess you got some of those?
[21:26] <cyphermox> yeah, then cool
[21:27] <cyphermox> seemed unusual but I don't know enough about what that flag does to figure out the link anwyay
[21:28] <cyphermox> even then, I couldn't find what brings those in, if it's hardening flags, or default gcc flags, or what
[21:29] <cyphermox> oh, but of course I looked at the wrong places
[21:30] <seb128> cyphermox, it's in the default gcc flags
[21:30] <seb128> cyphermox, the issues is usually when a symbol is defined in 2 objects
[21:30] <cyphermox> seb128: yeah, I think my grep-fu failed me this time
[21:30] <seb128> like the bin and a .so
[21:30] <cyphermox> I was looking at gcc -dumpspecs
[21:33] <seb128> cyphermox, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=6cfa8efd447bcad22c67ab98a566811b62ea6765
[21:33] <seb128> that's a recent example with a bit of explanation with the fix
[21:34] <cyphermox> right
[21:34] <seb128> cyphermox, basically with the flag the objects get duplicated in each binary and you hit a conflict due to the double definition
[21:40] <cyphermox> bbl
[22:53] <jasoncwarner_> robert_ancell bryceh RAOF TheMuso meeting report reminder https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-07-03 please update and add agenda items.
[22:55] <TheMuso> Yep done.
[22:55] <TheMuso> Nothing from me.
[22:59] <jasoncwarner_> thanks, TheMuso
[23:08] <bryceh> no agenda items from me; taken care of via yesterday's email to list
[23:13] <robert_ancell> none from me
[23:26] <RAOF> Nor from me.