[00:41] <lifeless> hey, how does rickspencers script detect 'canonical staff' ?
[01:11] <RAOF> Bah.  Why is squid-deb-proxy failing to start :?
[01:28] <lifeless> RAOF: anything in cache.log ?
[01:28] <RAOF> lifeless: No errors; just a list of Making directories
[01:29] <lifeless> that should only have happened the once (for squid -z)
[01:29] <RAOF> And, indeed, that's timestamped 2012/02/02, which was the last time I tried to fix this by blowing away all the directories :)
[01:31] <RAOF> Nothing seems amiss in either access.log.1 nor store.log.1, either.  Although there doesn't appear to be an access.log nor a store.log, which suggests that squid is dying before writing them?
[01:43] <RAOF> Hm.  squid3 itself is perfectly happy to start; there's clearly something wrong with the squid-deb-proxy config.
[01:44] <lifeless> RAOF: squid3 -k parse -f <whatever>
[01:45] <RAOF> Aha!  mirror-dstdomain.acl is bungled, apparently.
[01:47] <RAOF> AHA!
[01:48] <RAOF> It doesn't like ddebs.ubuntu.com to be duplicated in the allowed domains.
[01:49] <RAOF> It would be slightly nicer if this error made it *anywhere*; as far as I can tell the only thing that hits the logs is “[33760.219160] init: squid-deb-proxy main process (20601) terminated with status 1”
[01:52] <lifeless> can't write to cache.log until you know where cache.log will be
[01:52] <lifeless> so it goes to std* until that point in the config
[01:52] <lifeless> (process, not parsing - its a two stage thingy)
[01:53] <lifeless> anyhow, that's probably a change for strictness
[01:58] <broder> is upstart's job logging still turned off? if squid is spewing to std*, there might be something there
[02:01] <broder> (maybe check /var/log/upstart?)
[02:01] <RAOF> Empty
[02:01] <broder> oh well
[05:11] <pitti> Good morning
[05:55] <BigWhale> Good Morning.
[05:56] <RAOF> Boo, hiss.  Why isn't dbus-test-runner in Debian :(
[05:58] <RAOF> BigWhale: Good morning!
[05:58] <BigWhale> Hey RAOF. :)
[05:59] <micahg> RAOF: you can fix that ;)
[06:00] <RAOF> Not before I get at least DM.
[06:01] <micahg> raoF: I think we have plenty of sponsors around
[06:02] <RAOF> We do, I just find it quite demotivating to have to get sponsorship.
[06:02] <RAOF> I don't think Debian sponsorship works as well as our processes.
[06:03] <broder> RAOF: it works pretty well when you just pick one person and harass them :)
[06:03] <RAOF> :)
[06:03] <micahg> raoF: join pkg-utopia?
[06:03] <micahg> team based sponsorship seems to work pretty well
[06:04] <RAOF> Yeah, it does.  What's pkg-utopia about?
[06:04] <micahg> http://qa.debian.org/developer.php?login=pkg-utopia-maintainers@lists.alioth.debian.org
[06:09] <RAOF> Speaking of sponsorship - pitti, could I get colord (0.1.16-2) up again?  This time with significantly more installability!
[06:10] <pitti> RAOF: sure, doing
[06:10] <RAOF> (Note to self: not only check that purging and reinstalling works, but also that installing in a clean chroot works!)
[06:20] <robert_ancell> pitti, perhaps you can help me with this one - do you know why using a GLib main loops stops signal handlers working? http://paste.ubuntu.com/827320/
[06:20] <robert_ancell> they revert to the KeyboardInterrupt exception
[06:21] <pitti> hmm, not off the back of my head
[06:23] <broder> robert_ancell: the behavior you describe is exactly what pygobject's wrapper around GMainLoop sets up
[06:23] <robert_ancell> pitti, alternatively do you know if you can access g_unix_signal_add from python via gia?
[06:23] <robert_ancell> gir?
[06:24] <broder> robert_ancell: it opens a pipe and passes it to PySignal_SetWakeupFd, which has a byte written to it any time the process receives a signal
[06:25] <broder> (and a GSource watches the other end of the fd, and fairly blindly raises a KeyboardInterrupt when something gets written to it)
[06:25] <broder> it's all in gi/_glib/pygmainloop.c in the pygobject source
[06:25] <broder> my guess would be that PySignal_SetWakeupFd is a heavier hammer than is actually necessary, but i don't know
[06:27] <robert_ancell> broder, thanks.  I have something similar for lightdm, but this is a small program and it seems overkill to do that :(
[06:28] <broder> robert_ancell: if, uh, you use Gtk.Main() instead of GLib.MainLoop().run(), you can avoid this pygobject "feature" :)
[06:29] <broder> (unless that's been fixed - there's an open bug asking for Gtk.Main() to throw KeyboardInterrupt like GLib.MainLoop does)
[06:29] <robert_ancell> that seems like the wrong way around - you probably don't care too much about signals when using GTK+, but you do when you're running from a plain main loop
[06:29] <robert_ancell> :0
[06:29] <pitti> robert_ancell: sorry, no; g_unix_signal_add doesn't seem to be in any GIR
[06:31] <smspillaz> hey hey didrocks
[06:31] <didrocks> hey smspillaz :)
[06:31] <broder> robert_ancell: right. my point is that, at present, GLib.MainLoop asserts that it wants to be in charge of all signals while Gtk.Main does not, so if you want to claim some signals, Gtk.Main allows that while GLib.MainLoop does not
[06:32] <robert_ancell> broder, so it's impossible to handle signals when using GLib.MainLoop?
[06:32] <didrocks> good morning robert_ancell :)
[06:32] <robert_ancell> didrocks, hey
[06:33] <didrocks> robert_ancell: btw, the ubuntu-desktop merger machine is already ready for 3 weeks now, we just need to talk about how it works :)
[06:34] <robert_ancell> didrocks, cool, have to tackle that one next week
[06:34] <didrocks> robert_ancell: exccellent :)
[06:35] <broder> robert_ancell: right. PySignal_SetWakeupFd bypasses the signal module's mechanism for recording that a signal was received so that it can call the handler once it has an opportunity to reacquire the GIL and so forth
[06:35] <broder> so GLib.MainLoop's code gets called any time that the signal module would otherwise call a signal handler
[06:36] <robert_ancell> i see
[06:39] <robert_ancell> oh well, have to tackle that next week.  Thanks broder, pitti
[08:24] <didrocks> oh, interesting: gzip-file-is-not-multi-arch-same-safe lintian warning
[08:31] <sil2100> didrocks: it seems yesterday my unityshell doesn't start at all - is there some easy way I could enable some debugging in both unityshell and compiz to find out what's going on when the plugin is loaded?
[08:31] <didrocks> sil2100: hey
[08:31] <didrocks> sil2100: when all plugins are loaded
[08:31] <didrocks> do you see "unityshell" as being one of them?
[08:32] <sil2100> didrocks: should compiz print that out during start?
[08:32] <didrocks> sil2100: compiz prints the plugins that are loaded (in the previous versions at least) at start, yeah
[08:32] <didrocks> maybe you need --debug now
[08:32] <didrocks> (to first ensure it tries to load it :))
[08:36] <sil2100> hm, it doesn't seem to list the plugins that its loading
[08:36] <didrocks> pitti: hey! I'm getting a gzip-file-is-not-multi-arch-same-safe lintian warning. (yeah, see how gzip on multiarch is a hot topic!). I thought the option to use -n for gzip was made on the platform, isn't it? should I override it manually in my package?
[08:36] <sil2100> With --debug I only get a list of failed stat() operations on .so's from .compiz-1/plugins
[08:36] <didrocks> sil2100: you shouldn't have any in ~/.compiz-1
[08:37] <didrocks> sil2100: remove that dir
[08:37] <didrocks> seems you have a local build
[08:39] <sil2100> didrocks: I think he's also looking for them in the global directory too
[08:39] <sil2100> Since I remember once getting a stat() error of a not found library in /usr/lib/compiz/ or something, when I forgot installing one package
[08:39] <didrocks> sil2100: yeah, but you maybe have a locally installed unityshell plugin which override the system one
[08:40] <sil2100> didrocks: I removed .compiz-1, but it didn't seem to have a plugins directory at all
[08:41] <didrocks> sil2100: I think you should see with smspillaz then if the debug messages are not around anymore
[08:41] <sil2100> Ok, will do!
[08:41] <didrocks> thanks :)
[08:41] <dpm> good morning desktop folk!. After the last dist-upgrade it seems the indicator menus don't follow the theme. They appear in the standard grey gtk3 theme instead of them being black as usual. I've already logged out and back into the session, but that did not seem to solve it. Any ideas?
[08:44] <pitti> sounds like a regression from the new GTK
[08:44] <pitti> seb128 is not online yet, I wonder whether he gets that, too
[08:44] <pitti> looks fine here, but I'm using Radiance
[08:45] <didrocks> pitti: snif, ignoring me? :)
[08:45]  * pitti hugs didrocks, why?
[08:45] <pitti> oohh
[08:45]  * didrocks hugs pitti back :)
[08:45] <pitti> sorry, didn't see your ping
[08:45] <didrocks> no worry, just jocking :)
[08:45] <pitti> didrocks: is that for buildinfo sor somethign?
[08:46] <didrocks> pitti: yeah, local build of bamf
[08:46] <pitti> didrocks: that's one known case which we don't need to worry about, pkgbinarymangler removes them
[08:46] <pitti> .buildinfo files are rather useless anyway
[08:46] <pitti> and yes, they would cause multi-arch problems
[08:46] <didrocks> pitti: great! ok, I won't add the override then
[08:46] <didrocks> yeah, I heard about some gzip fun you had :)
[08:47] <pitti> that's unrelated, t hough
[08:47] <didrocks> it's only timestamp in that case, not content, isn't it?
[08:48] <didrocks> dpm: pitti: I saw that kenvandine uploaded light-themes
[08:48] <didrocks> dpm: pitti: the according fix for it is coming with the new unity release
[08:48] <pitti> didrocks: not sure, but buildinfo files sound like they could potentially differ between arches, too
[08:48] <pitti> didrocks: ok, which is planned today, right?
[08:49] <didrocks> which is even happening… now! :)
[08:49]  * dpm hugs didrocks ;)
[08:49] <dpm> thanks guys
[08:49]  * didrocks hugs dpm
[08:49] <didrocks> dpm: tell me if it doesn't fix it for you
[08:49] <didrocks> dpm: just to confirm, you didn't installed the unity-team ppa for 5.2, isn't it?
[08:50] <dpm> didrocks, no, I'm on standard packages from the archive
[08:50] <didrocks> yeah, so makes totally sense :)
[08:50] <didrocks> dpm: tell me once you get the new unity that it actually fixes it for you
[08:50] <dpm> sure I'll let you know if it's fixed once I update unity
[08:51] <didrocks> great :)
[08:57] <seb128> hey
[08:58] <pitti> hey seb128
[08:59] <seb128> hey pitti, wie gehts?
[08:59] <pitti> seb128: gut, danke!
[08:59] <pitti> seb128: und Dir?
[08:59] <seb128> pitti, zehr gut, danke!
[09:00] <seb128> pitti, nice work on the language selector stack, impressive changelogs
[09:00] <pitti> heh, thanks
[09:00] <pitti> seb128: I blogged about the new PK/aptdaemon API
[09:00] <seb128> though the number of changes we have to accountsservice start to scare me a bit :p
[09:00] <pitti> yes, this stuff needs desperate cleaning
[09:00] <pitti> our shell scripts there are hackish
[09:00] <didrocks> salut seb128, ça va ?
[09:01] <pitti> but I'm more concerned about the lack of any feedback on the upstream bugs, for the API changes
[09:01] <seb128> lut didrocks, nickel, et toi?
[09:01] <didrocks> seb128: ça va :)
[09:01] <seb128> pitti, I guess somebody should direct ping them on IRC
[09:01] <pitti> yes, Gunnar was meaning to
[09:05] <chrisccoulson_> good morning everyone
[09:05] <chrisccoulson_> gah @ bug 925907
[09:05] <pitti> didrocks: so that should fix the two light-themes bugs that jibel just assigned to us?
[09:05] <ubot2`> Launchpad bug 925907 in light-themes "12.04 thunderbird colour theme is unreadable" [High,Triaged] https://launchpad.net/bugs/925907
[09:06] <pitti> hey chrisccoulson_
[09:06] <seb128> pitti, I reassigned them to Cimi
[09:06] <pitti> really, can we please avoid this kind of premature upload?
[09:06] <didrocks> seb128: isn't Cimi's bug without the new unity?
[09:06] <seb128> pitti, talk to ken, he's the one who did the snapshot and upload
[09:06] <chrisccoulson_> hey pitti, how are you?
[09:06] <seb128> didrocks, I doubt it, at least not this tb bug
[09:07] <pitti> chrisccoulson_: quite fine, thanks!
[09:07] <didrocks> seb128: no, I'm speaking about the indicator one
[09:07] <seb128> didrocks, the fix is in unity 5.2
[09:07] <pitti> seb128: sounds like a good case for a revert -- three major bugs in one day; want me to uplaod a revert?
[09:07] <didrocks> yeah, that's what I meant :)
[09:07] <seb128> pitti, no please
[09:07] <seb128> pitti, we knew that some issues would be there until unity 5.2 would be uploaded this morning
[09:08] <seb128> pitti, revert will create other bugs with the new gtk
[09:08] <seb128> like the icons having a square solid background and some menus issue as well
[09:09] <seb128> pitti, do you confirm the slider bug with unity 5.2?
[09:10] <pitti> hm, not in my current session; let me start a guest session, I didn't restart since this morning's dist-upgrade
[09:10] <seb128> pitti, ok, so what didrocks said, part of the issue will be fixed with unity 5.2
[09:11] <pitti> seb128: yes, confirmed
[09:11] <seb128> the indicators issue
[09:11] <seb128> we need the new theme for the new gtk so revert is not a good idea
[09:11] <pitti> mvo: guten Morgen
[09:11] <seb128> the tb issue is lack of testing and will need to be fixed today though
[09:11] <pitti> mvo: would you mind doing a s-c-aptdaemon-plugins upload? I can't push to bzr, so I didn't yet
[09:12] <pitti> ugh @ http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[09:12] <pitti> poor armel buildds :/
[09:13] <mvo> pitti: sure, doing that now
[09:13] <pitti> mvo: danke
[09:17] <chrisccoulson> seb128, pitti, so i guess from the scrollback that thunderbird isn't the only thing broken b the light-themes update?
[09:17] <chrisccoulson> i haven't updated it yet
[09:17] <chrisccoulson> but the screenshot looks pretty unusable ;)
[09:17] <seb128> chrisccoulson, sort of, the unity issue is known and fixed in 5.2 which is about to be uploaded
[09:18] <seb128> to be fair one part of the issue is that gtk3 keep changing theming details this cycle which break the theme, we needed an update for the new gtk
[09:18] <chrisccoulson> seb128, right. but thunderbird is using gtk2 :)
[09:19] <seb128> right, should be easy to figure what changed there, I guess most of theming work is for gtk3
[09:22] <seb128> chrisccoulson, tb is fine for me but I use the light theme, let me try with the default one
[09:24] <seb128> yeah, I can confirm the issue
[09:24] <seb128> well it's not a stopper, you can read stuff when you mouseover, still should be fixed today, I will ping Cimi when he gets online
[09:25] <chrisccoulson> and it didn't break the tabs in firefox too?
[09:25] <chrisccoulson> actually, 'i'm upgrading now
[09:25] <chrisccoulson> lets have a bit of breakage for a chance :)
[09:25] <chrisccoulson> **change
[09:26] <chrisccoulson> hmmm, you can tell i really need coffee this morning
[09:26] <seb128> could be that it did, who use tabs? ;-)
[09:26] <chrisccoulson> lol
[09:26] <seb128> joke aside I never opened tabs in tb out of mistakes ;-)
[09:31] <chrisccoulson> i can't believe jo has taken the car to go out, leaving me in a house with no coffee
[09:43] <pitti> chrisccoulson: are you guys freezing to death ATM, too? -14 celsius here for several days now..
[09:44] <chrisccoulson> pitti - yeah, it's certainly colder this week than it has been at any other point during this winter, and people are talking about the cold a lot, but it feels quite normal for this time of year here :)
[09:45] <chrisccoulson> -14 is pretty cold though ;)
[09:45] <chrisccoulson> oh, i think it was -9 here last night, which is a bit colder than average
[09:46] <chrisccoulson> i quite like the cold. it's refreshing :)
[09:48] <chrisccoulson> w00t, just upgraded to thunderbird 13, unlucky for some ;)
[09:50] <chrisccoulson> lol @ mark's reply on bug 820034 ;)
[09:50] <ubot2`> Launchpad bug 820034 in ubuntu-font-family-sources "Expansion: Miscellaneous Symbols and Pictographs U+1F4A9" [Wishlist,Confirmed] https://launchpad.net/bugs/820034
[09:53] <chrisccoulson> seb128, b'ah, the light-themes update has broken the awesomebar styling :(
[09:54] <chrisccoulson> which i had actually fixed in firefox a couple of weeks ago to make it not suck with ambiance ;)
[09:56] <seb128> chrisccoulson, well you are lucky, Cimi is online now
[09:56] <seb128> chrisccoulson, so just ping him to complain ;-)
[09:56] <seb128> he just reassigned the slider bug to ido
[09:56] <seb128> lol
[09:57] <seb128> chrisccoulson, he also reassigned the tb bug to tb and invalidating the light-theme part of the bug :p
[09:59] <jincreator> pitti: Hi. Did you see my comment in https://bugs.launchpad.net/bugs/916847 ?
[09:59] <ubot2`> Launchpad bug 916847 in ttf-unfonts "Please merge fonts-unfonts-core, fonts-unfonts-extra from (universe) from Debian unstable (main) " [Undecided,In progress]
[10:02] <chrisccoulson> seb128, oh, it's funny how thunderbird is to blame when i didn't change anything in it yesterday ;)
[10:03] <seb128> chrisccoulson, yeah, I found as well ;-)
[10:19] <pitti> jincreator: yes, we need to make them as small as possible; if the package baloons from 7.5 MB to 19, we just can't fit it on the CD any more and have to drop it from the default install
[10:20] <didrocks> just trying logout/login, bbiab
[10:20] <pitti> jincreator: if you install with network, they will be installed for Korean users, but they wouldn't be on the live system any more, or for non-network installs, so not really ideal
[10:25] <jincreator> pitti: Well, but ttf-unfonts-core(fonts-unfonts-core) doesn't ship with Cd and default font is fonts-nanum.
[10:25] <jincreator> Cd->CD
[10:27] <jincreator> pitti: Because fonts-nanum is at live system, unfonts and its related packages can install with network, I think.
[10:31] <seb128> didrocks, gnome-classic as a session is an Ubuntuism right?
[10:32] <didrocks> seb128: indeed
[10:32] <didrocks> it's compiz + gnome-panel
[10:32] <seb128> didrocks, thanks
[10:32] <didrocks> yw :)
[10:44] <ricotz> seb128, hello, you forgot to actually add libelf-dev to glib
[10:44] <seb128> ricotz, arg
[10:45] <seb128> ricotz, what difference does it make? is that only for the gresource utility?
[10:45] <ricotz> yes, it wont support reading elfs
[10:45] <ricotz> like mentioned in the changelog ;)
[10:45] <seb128> ok, that's fine
[10:45] <seb128> it's only a play tool, that can wait the next upload
[10:46] <seb128> that doesn't make any difference for applications or users
[10:46] <chrisccoulson> isn't the plural of "elf" "elves"? ;)
[10:46] <seb128> sorry about that, I'm fixing it in the vcs now, I will just not do another upload only for it
[10:46] <ricotz> seb128, as long no app depends on it to resolve some information on this way
[10:46] <seb128> ricotz, I go sidetracked by the gzip stuff and finished by dropping the old changelogs rather than using your workaround
[10:47] <seb128> ricotz, well, we will probably have a glib upload next week, I think precise users are fine for the w.e ;-)
[10:47] <ricotz> yeah, dropping them was better
[10:47] <ricotz> right ;)
[10:47] <didrocks> unity 5.2 is released *phew*
[10:48] <seb128> didrocks, \o/
[10:48] <chrisccoulson> nice :)
[10:48] <pitti> jincreator: hm, indeed; they are on xubuntu and edubuntu, but that shouldn't hurt them much
[10:48] <seb128> ricotz, btw if you were doing merge requests, I could just bzr merge and we would avoid such errors :p
[10:49] <ricotz> hehe (or forget about them)
[10:49] <seb128> I'm lazy enough that I would not forget about the useful ones ;-)
[10:49] <seb128> I don't like to redo work manually :p
[10:50] <ricotz> patch -R -p0 < diff seemed easy enough
[10:50] <seb128> if you have a diff yes
[10:50] <seb128> but you don't provide that
[10:51] <ricotz> i gave you the link
[10:51] <ricotz> twice ;)
[10:51] <seb128> right, which had stuff like changing -c4 -c1 as well
[10:51] <seb128> or dropping some of our patches
[10:51] <seb128> or changing build-depends and break revisions
[10:51] <seb128> i.e I couldn't apply it, I had to cherry pick the actual fixes
[10:52] <ricotz> http://people.ubuntu.com/~ricotz/glib.diff
[10:52] <ricotz> this is the one i gave you
[10:52] <ricotz> looks pretty clean to me
[10:52] <seb128> ah that one, yeah, there was some weird reshuffling in the .install, the rules hack was not good and it was reversed
[10:53] <seb128> but otherwise it was ok ;-)
[10:53] <seb128> well anyway fixing the vcs, thanks
[10:54] <tkamppeter> pitti, hi
[10:54] <pitti> hello tkamppeter
[10:57] <tkamppeter> pitti, it is about bug 911436 and bug 925227. A problem in p11-kit causes a lot of crashes, mainly in CUPS and the bugs are accumulating duplicates.
[10:57] <ubot2`> Launchpad bug 911436 in p11-kit "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436
[10:57] <ubot2`> Launchpad bug 925227 in cups "package cups 1.5.0-16 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Invalid] https://launchpad.net/bugs/925227
[10:57] <pitti> tkamppeter: yes, I noticed
[10:57] <pitti> tkamppeter: I just replied to the second bug
[10:58] <tkamppeter> pitti, is someone maintaining the p11 stuff?
[10:58] <pitti> it's assigned to foundations, but no progress on it yet
[10:59] <tkamppeter> pitti, I have rasied the first bug to "Critical".
[10:59] <pitti> chrisccoulson: ah, so bug 805136 got marked as fixed upstream, but it looks it was mainly tested on windows; do you know whether that fix applies to linux as well?
[10:59] <ubot2`> Launchpad bug 805136 in thunderbird "accounts window doesn't fit on screen and no scrollbar to show hidden fields" [Medium,Fix released] https://launchpad.net/bugs/805136
[11:01] <chrisccoulson> pitti - yeah, it's got scrollbars and is resizeable on the current nightly build here
[11:01] <pitti> sweet, thanks
[11:02] <chrisccoulson> oh, it landed in september. i wonder which release that's in now
[11:02] <chrisccoulson> it should be in thunderbird 9 then
[11:08] <jincreator> pitti: I didn't know that these distros are not maintained by same ubuntu-seeds. If than, should I report bug to request change default fonts?
[11:09] <pitti> jincreator: for xubuntu, yes; edubuntu pulls in pretty much all lang support, they have a DVD and can affort it
[11:10] <pitti> chrisccoulson: hm, we do have that
[11:12]  * pitti hugs didrocks
[11:13]  * didrocks hugs pitti back :)
[11:13] <didrocks> (sorry, will be hard to reach my number of closed bugs now!) :)
[11:13] <jincreator> pitti: OK. Then I'll report bug and if Xubuntu developers change it, I'll submit comment at my merge request bug.
[11:16] <pitti> didrocks: http://reports.qa.ubuntu.com/reports/bug-fixing/precise-fixes-report.html
[11:16] <pitti> and I had almost got you!
[11:16] <pitti> just one more to go
[11:16] <pitti> jincreator: thanks; but I think that merge is fine now anyway
[11:16] <seb128> pitti, that was before he added an another hundred to his counter? ;-)
[11:16] <pitti> seb128: before
[11:16] <jincreator> pitti: Ah, great.
[11:16] <didrocks> pitti: toooooo late! :)
[11:17] <pitti> jincreator: so, if anyone wants to sponsor this, I left an "OK" comment
[11:17] <pitti> jincreator: otherwise I'll look into it on Monday (need to run in a few mins)
[11:17] <pitti> seb128, didrocks: I'll spend the afternoon in a train, working offline; do you still need me to do anything in the next few mins?
[11:17]  * didrocks thinks that mvo's results are quite disappointing, he doesn't whip the crack enough to get his bug fix counter at the top :)
[11:18] <jincreator> pitti: I see.
[11:18] <didrocks> pitti: all sounds safe and good! :) Enjoy your travel
[11:18] <seb128> pitti, I think we are fine, is there anything we should watch for?
[11:18] <seb128> pitti, have a good w.e!
[11:18] <pitti> seb128: noting in particular from my side
[11:18] <seb128> ok, great
[11:18] <pitti> we don't have a release meeting today
[11:18] <seb128> see you on monday then ;-)
[11:18] <pitti> didrocks: thanks
[11:18] <pitti> seb128: merci
[11:18] <pitti> enjoy the weekend, y'all :0
[11:19] <didrocks> have a good week-end pitti :)
[11:19] <seb128> danke
[11:19] <pitti> finally have some time to work on that "report disk wakeup culprits" program
[11:19] <didrocks> oh great :)
[11:20] <pitti> seb128: I looked at bug 890592, but not very successfully so far; need to debug that harder, kernel is not giving me cookies :(
[11:20] <ubot2`> Launchpad bug 890592 in udev "Ejecting a CD or DVD manually does not unmount it" [High,In progress] https://launchpad.net/bugs/890592
[11:20] <seb128> pitti, I noticed your comment, thanks for looking at it
[11:20] <seb128> pitti, good that you get it as well at least, it will make debugging easier ;-)
[11:21] <seb128> it's quite disturbing to be still able to browse a CD in nautilus, i.e enter dirs and everything when the CD has been ejected and is on your desk
[11:22] <pitti> I can easily fix this part
[11:22] <pitti> and already did so locally
[11:23] <pitti> but now the eject button doesn't work at all any more
[11:23] <pitti> i. e. you need to use the nautilus one
[11:23] <pitti> that's the kernel part
[11:24] <didrocks> sil2100: keep me up to date on the compiz progress, will be nice to push to a ppa for user testing
[11:24] <seb128> pitti, ok
[11:24] <didrocks> sil2100: also, I think that now unity 5.2 is ready, your team needs to bump unity in the hud ppa
[11:25] <didrocks> (this is something to see with gord to take his latest code)
[11:25] <gord> ah yes
[11:29] <gord> didrocks, sil2100 - will wait for later today, hud branch dep's on another branch that conflicts with trunk. need to wait for the americans to awaken
[11:29] <didrocks> gord: let's wait on the us then! :)
[11:29]  * pitti waves good bye, enjoy the weekend everyone!
[11:30] <didrocks> see you pitti :)
[11:30] <seb128> pitti, have fun, see you
[11:31] <sil2100> didrocks: working on it, it seems I was missing some patches to make unity and upstream compiz work
[11:31] <sil2100> didrocks: it's rebuilding now
[12:01]  * sil2100 sighs
[12:08] <sil2100> Could anyone take a look ;)?
[12:09] <sil2100> http://paste.ubuntu.com/827533
[12:09] <sil2100> stdout and stderr from my 'buggy' unity compiz session
[12:09] <sil2100> The panel, launcher and dash are there, but I can't see any graphics
[12:10] <sil2100> Instead, I get black rectangles everywhere, blinking from time to time
[12:10] <sil2100> During moving windows it's the same - and it only happens with the unityshell plugin enabled
[12:49] <sil2100> didrocks, smspillaz ;)? ^
[12:50] <didrocks> sil2100: i think you should see that directly with upstream, so sam :)
[13:05] <Beret> hi all
[13:06] <Beret> are the depends for unity currently broken?
[13:06] <didrocks> Beret: bamf FTBFS
[13:06] <didrocks> Beret: because of the new glib, just fixed it
[13:07] <seb128> didrocks, not because of glib, don't blame glib for use of outdated apis in dx code ;-)
[13:07] <didrocks> yeah, it's all dbo's fault! :)
[13:10] <ockham> hi; this merge request is already approved, but doesn't seem to have been merged yet:
[13:11] <ockham> https://code.launchpad.net/~jconti/indicator-applet/gnome3/+merge/80877
[13:11] <ockham> it would be great to have it in precise...
[13:11] <ockham> anyone know why that hasn't been done yet?
[13:11] <seb128> ockham, it will be in precise don't worry, they just go busy and didn't roll tarballs for a while
[13:11] <ockham> seb128: great to hear!
[13:11] <seb128> that's starting again, we got a new libdbusmenu and indicator stack being uploaded
[13:14] <cjwatson> hey, I'm trying to fix bug 925427, and am stuck on a stupid problem: I can't get GTK to hide the contents of a widget without causing its container to want to resize
[13:14] <ubot2`> Launchpad bug 925427 in ubiquity ""Ready when you are" message is misleading and incorrect" [Medium,Confirmed] https://launchpad.net/bugs/925427
[13:14] <cjwatson> is there some way I can get a widget to just not display anything, but keep its existing size?
[13:15] <cjwatson> this is frustrating since I'm sure it should be easy, I just can't find it
[13:17] <cjwatson> or maybe I want to freeze the container's size allocation or something
[13:20] <seb128> cjwatson, hum, not sure how to do that, you might have a better chance to get a reply on #gtk+ or #gnome-hackers on irc.gnome.org
[13:20] <Beret> didrocks, sweet thanks
[13:20] <seb128> try the gtk channel you usually have a good chance to get a reply there
[13:20] <cjwatson> fair enough, thanks
[13:20] <cjwatson> I have one last idea I'll try first :)
[13:21] <cjwatson> (temporarily set the container's size request to its current allocation)
[13:23] <ockham> cjwatson: if you succeed, can you post a link to a vcs commit or whatever to let others see how you did it?
[13:23] <cjwatson> sure
[13:34] <cjwatson> bingo!  cardboard programmer strikes again
[13:35] <cjwatson> seb128,ockham: there's some more work to do before I commit this (notably, I now need to do the same for KDE), but it's essentially http://paste.ubuntu.com/827602/
[13:36] <seb128> cjwatson, ok, seems to make sense, thanks ;-)
[13:37] <mdeslaur> heh, "cardboard programmer"...first time I've heard that :)
[13:38] <cjwatson> jodh used the term "confessional debugging" to me yesterday which is a synonym but I hadn't heard that one either ...
[13:38] <mdeslaur> hehe, good one too :)
[13:39] <seb128> chrisccoulson, can I get your opinion on something? ;-)
[13:39] <seb128> chrisccoulson, http://git.gnome.org/browse/gnome-desktop/commit/?id=a81bd53c44a0785373ba9fba543556e3c4e12431 do you see that as an api change?
[13:40] <sil2100> didrocks: I'll put those packages I compiled up somewhere
[13:40] <didrocks> sil2100: are they working?
[13:40] <seb128> chrisccoulson, do you think it will make g-s-d bug if we take that without updating gsd?
[13:40] <sil2100> didrocks: well... ;) Not on my desktop, that's why I would like to see if it's the same on other platforms
[13:40] <sil2100> Since it seems to be a driver issue
[13:41] <chrisccoulson> seb128, it should be fine if we drop our patch from g-s-d
[13:41] <didrocks> sil2100: you can maybe see with your fellows on your team then, to see if it works? :)
[13:42] <chrisccoulson> seb128, yeah, we should drop this one if we take the new gnome-desktop: http://bazaar.launchpad.net/~ubuntu-desktop/gnome-settings-daemon/ubuntu/view/head:/debian/patches/46_share_rr_screen.patch
[13:42] <seb128> chrisccoulson, I'm pondering backporting the work federico did to improve dock stations support in the xrandr code, but first we would need to update gnome-desktop, so trying to figure in what order we should do things
[13:43] <seb128> chrisccoulson, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=6e17bc786f55f283f2c721249197e7740174fd43 has "This requires gnome-desktop 3.3.4 or later, as the semantics of gnome_rr_screen_new() are slightly different there - now it returns a singleton instead of a new object every time."
[13:43] <seb128> I was wondering if we would have issues without that
[13:43] <sil2100> didrocks: will do so ;)
[13:44] <seb128> chrisccoulson, right, that patch is to drop for sure, I'm trying to figure what will happen to g-s-d without the patch and the new gnome-desktop
[13:44] <seb128> I guess I should just try ;-)
[13:44] <chrisccoulson> seb128, oh, the relevant part of http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=6e17bc786f55f283f2c721249197e7740174fd43 is the bit which drops the change that is equivalent to our patch
[13:45] <chrisccoulson> it seems that rodrigo committed our change upstream
[13:45] <chrisccoulson> and this commit reverts it for the new gnome-desktop
[13:45] <chrisccoulson> so, i think we should be fine
[13:45] <didrocks> sil2100: excellent, let's cross fingers then :)
[13:45] <seb128> chrisccoulson, oh, I see, http://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/xrandr/gsd-xrandr-manager.c?id=4cb1515ebaa635e7686d153eba977a206b256514
[13:46] <seb128> chrisccoulson, thanks
[13:55] <Beret> didrocks, still get - http://paste.ubuntu.com/827617/
[13:55] <didrocks> Beret: you will need to dist-upgrade
[13:55] <Beret> didrocks, that was from a dist-upgrade
[13:55] <didrocks> Beret: but again, new unity is not built yet
[13:55] <Beret> oh ok
[13:57] <didrocks> Beret: get apt-get update and apt-cache policy at some point will tell you that unity 5.2 is available
[14:05] <Beret> didrocks, oh ok, thanks, I was under the impression it was built already
[14:05] <Beret> 's all good
[14:10] <GunnarHj> Current unity dependency issue:
[14:10] <GunnarHj> ~$ sudo apt-get install ubuntu-desktop
[14:10] <GunnarHj> Reading package lists... Done
[14:10] <GunnarHj> Building dependency tree
[14:10] <GunnarHj> Reading state information... Done
[14:10] <GunnarHj> Some packages could not be installed. This may mean that you have
[14:10] <GunnarHj> requested an impossible situation or if you are using the unstable
[14:10] <GunnarHj> distribution that some required packages have not yet been created
[14:10] <GunnarHj> or been moved out of Incoming.
[14:10] <GunnarHj> The following information may help to resolve the situation:
[14:10] <GunnarHj> The following packages have unmet dependencies.
[14:10] <GunnarHj>  ubuntu-desktop : Depends: unity but it is not going to be installed
[14:10] <GunnarHj> E: Unable to correct problems, you have held broken packages.
[14:16] <didrocks> desrt: hey, are you around?
[14:16] <didrocks> GunnarHj: not an issue, you get nux installed, but unity is not yet published
[14:16] <didrocks> and there is an ABI break
[14:16] <seb128> GunnarHj, it's a transition, you need to wait for unity to build
[14:17] <GunnarHj> didrocks, seb128: Ok, thanks for letting me know. Just wanted to mention it in case ... :)
[14:17] <didrocks> no worry, should be published soon :)
[14:20]  * kenvandine installs thunderbird
[14:35] <desrt> didrocks: yup
[14:36] <desrt> good morning, everyone
[14:36] <didrocks> desrt: good morning!
[14:36] <didrocks> desrt: remember this discussion about the "default" value?
[14:36] <desrt> yesish :)
[14:36] <desrt> the one about indicating on a slider, etc?
[14:36] <didrocks> yeah
[14:37] <desrt> how can i help you?
[14:37] <desrt> seb128: poke
[14:37] <didrocks> so basically, I tried that: http://pastebin.ubuntu.com/827651/
[14:37] <seb128> desrt, hi
[14:37] <desrt> seb128: remember how i asked you to package the beta automake?
[14:38] <seb128> desrt, yes?
[14:38] <didrocks> unfortunatly, it seems that default_gtk_theme doesn't really contain the default
[14:38] <seb128> desrt, I hate you for that :p
[14:38] <didrocks> but the current selection
[14:38] <desrt> seb128: why?
[14:38] <seb128> desrt, I've just waster 1 hour try to debug why the current debian version I upload to precise fail in the testsuit
[14:38] <desrt> seb128: doko hit you over the head for the NMU?
[14:38] <desrt> oh.
[14:38] <seb128> it hits Makefile.am: required file `./NEWS' not found
[14:38] <seb128> and exit 1
[14:39] <desrt> shouldn't uloading a debian src package direct to precise cause no trouble at all?
[14:39] <seb128> desrt, it should, dunno why the testsuit work for them and not for us
[14:39] <desrt> huh
[14:39] <desrt> sorry :)
[14:39] <seb128> desrt, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3183452 is your new version as well
[14:39] <seb128> let's see if that one builds
[14:39] <desrt> didrocks: so one note: g_settings_revert() here is probably not doing what you think
[14:40] <seb128> desrt, debian has 1.11.2 not 1.11.3
[14:40] <desrt> seb128: ya.  1.11.3 only came out 2 days ago
[14:40] <didrocks> desrt: oh?
[14:40] <desrt> (ie: no point in trying to package the beta anymore)
[14:40] <desrt> didrocks: once a gsettings object is delayed, it is delayed forever
[14:40] <desrt> didrocks: lemme try this code locally
[14:40] <desrt> it 'looks fine'
[14:40] <didrocks> interesting :)
[14:40] <desrt> other than the revert thing
[14:41] <seb128> desrt, hum, so you don't need 1.11.3?
[14:41] <seb128> desrt, I though you wanted the new version
[14:42] <desrt> seb128: no.  1.11.3 is the one i want.
[14:42] <seb128> desrt, well anyway it's uploaded
[14:42] <desrt> 1.11.2b was a beta release for 1.11.3
[14:42] <desrt> seb128: nice :)
[14:42] <seb128> desrt, it's the one in https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3183452
[14:43] <desrt> seb128: thanks very much.  i'll test that as soon as it is built.
[14:43] <seb128> desrt, it will not build, seems it has the same issue :-(
[14:43]  * desrt just got a similar email this morning from someone else: http://koji.fedoraproject.org/koji/taskinfo?taskID=3758796
[14:43] <seb128> Makefile.am: required file `./ChangeLog' not found
[14:43] <seb128> Makefile.am: installing `./COPYING' using GNU General Public License v3 file
[14:43] <seb128> Makefile.am:     Consider adding the COPYING file to the version control system
[14:43] <seb128> Makefile.am:     for your code, to avoid questions about which license your project uses.
[14:43] <seb128> Makefile.am:1: installing `./texinfo.tex'
[14:43] <seb128> + exit_status=1
[14:43] <desrt> 'touch'? :)
[14:44] <seb128> desrt, well it's the test suit, I need to understand how it creates the test subdirs and why it's working in Debian
[14:45] <desrt> seb128: if it's too much hassle, i don't blame you if you want to give up
[14:46] <desrt> this is really not your responsibility at all
[14:46] <seb128> desrt, well I've synced the current version to precise and we will need to sort it anyway, the previous version was failed to build as well it seems, so probably something else changed
[14:46] <desrt> i've been in touch with the debian maintainer.  he's pretty responsive and promised me some speedy packaging when it came out
[14:46] <desrt> so i'll ping him back
[14:47] <seb128> desrt, don't worry one way or another I need to fill my friday afternoon ;-)
[14:47] <desrt> nice canadian guy :)
[14:47] <desrt> after that, once debian has it updated, i feel i have better grounds to harass doko
[14:48] <seb128> desrt, hum, if you email him can you drop a "btw the current version failed to build in Ubuntu: https://launchpadlibrarian.net/91800731/buildlog_ubuntu-precise-i386.automake1.11_1%3A1.11.2-1ubuntu1_FAILEDTOBUILD.txt.gz, do you have a clue about what could be wrong"?
[14:48] <desrt> seb128: i don't want to tell him i'm involved with ubuntu.  he may stop responding to my mails :p
[14:48] <seb128> desrt, lol
[14:48] <desrt> (actually, i already sent the mail so it's just too late) :p
[14:50] <desrt> didrocks: huh
[14:50] <desrt> didrocks: i suspect you have found a bug
[14:51] <didrocks> \o/
[14:52] <desrt> i get to avoid working on the hud for another day!
[14:52] <desrt> \o/
[14:52]  * desrt checks to make sure olli is not around
[14:53] <didrocks> desrt: ahah, "emergency fix for desktop?" :)
[14:53] <desrt> yes.  highly critical issue, clearly.
[14:53] <desrt> no.. but seriously... i can't imagine this takes more than half an hour to track down
[14:53] <desrt> hopefully it's something easy to fix
[14:58] <didrocks> great :-)
[15:01] <desrt> ya.  it's a dconf bug with an obvious (but slightly tricky) fix
[15:01] <desrt> i'm surprised you're the first person to notice this
[15:03] <didrocks> yeah, as you were telling that it's a quite well known trick :)
[15:04] <dobey> didrocks: http://pastebin.ubuntu.com/827689/
[15:04] <dobey> didrocks: what's up with upgrading nux removing unity? :)
[15:05] <didrocks> dobey: nux has an ABI break, apt-cache policy unity should show you you don't have 5.2
[15:05] <dobey> indeed
[15:05] <didrocks> it's published now, so should be soon available
[15:06] <desrt> didrocks: http://git.gnome.org/browse/dconf/commit/?id=33f32ba175c6192d500ed7081d3cf973e724379a
[15:06] <dobey> oh looks like it's available now
[15:06] <didrocks> ah :)
[15:06] <desrt> damn.  that only took 15 minutes.
[15:06] <didrocks> desrt: what, even not half an hour? :)
[15:06] <dobey> it wasn't 10 minutes ago when i last did apt-get update
[15:07] <didrocks> desrt: ok, I see that you need to know the layering level of dconf for it :)
[15:07] <desrt> ya.. as i said, tricky
[15:07] <desrt> but obviously trivial
[15:07] <desrt> anyway.. next release will be on feb 6
[15:08] <desrt> so you can wait for that or you can vendorpatch until then
[15:12]  * desrt thinks that package build priority should be related to historical time-to-build
[15:12] <desrt> 'oh?  you did a dconf upload?  well, that won't take long at all.... here... go first."
[15:13] <desrt> "oh... your name is Sweetshark?  i think i have a free slot next week..."
[15:15] <cjwatson> desrt: well volunteered to work on the LP build scheduler
[15:16] <desrt> :)
[15:18] <didrocks> desrt: I think this can wait anyway :)
[15:38] <seb128> desrt, ok, it's your day
[15:40] <desrt> seb128: sup?
[15:40] <didrocks> second bug? :)
[15:40] <desrt> didrocks: by that measure, every day is my day :)
[15:40] <seb128> desrt, https://launchpad.net/ubuntu/+source/intltool/0.50.0-0ubuntu3
[15:40] <didrocks> desrt: heh :)
[15:40] <desrt> seb128: damn.  i just filed a new bug against intltool :)
[15:41] <desrt> seb128: thanks :)
[15:41] <seb128> desrt, and I hate automake, the tests behave different when ran manually, the test which failed on the buildd works for me, I retried and it's ok now on the buildds
[15:41] <desrt> seb128: must be the old kernel version or something ;)
[15:41] <seb128> desrt, seems it was a random error, looks like you will get your deb in a bit
[15:41] <seb128> desrt, ;-)
[15:41] <seb128> desrt, automake takes longer to build that glib and gtk together
[15:42] <desrt> seb128: it's all tests...
[15:42] <seb128> well it takes like 15 seconds to build but it tests for 45 minutes
[15:42] <seb128> desrt, yeah, their tests are taking ages
[15:42]  * desrt needs to keep up the pressure on danilo
[15:42] <seb128> I've a new respect for automake, we might not like it but I didn't know it was that much test covered :p
[15:43] <desrt> seb128: you merely have to justify that by telling yourself that they must be really really really bad at writing testcases :p
[15:44] <seb128> desrt, I think your bug is a dup of https://bugs.launchpad.net/intltool/+bug/903340
[15:44] <seb128> desrt, https://code.launchpad.net/~hiberis/intltool/bug-903340/+merge/89088
[15:44] <ubot2`> Launchpad bug 903340 in gentoo "intltool.m4 should use --no-translations only if >=intltool-0.50.0 is detected" [Medium,Won't fix]
[15:44] <desrt> ah yes.  probably.
[15:44] <desrt> uh.  wontfix?
[15:45] <seb128> desrt, the gentoo line
[15:45] <dobey> eh
[15:45] <seb128> desrt, launchpad can be confusing like that :p
[15:45] <dobey> oh hmm
[15:45] <pgraner> didrocks, are you seeing compiz and unity-panel service segfaults on the new packages today?
[15:45] <seb128> pgraner, no, stacktrace? can you pastebin your .xsession-errors?
[15:46] <desrt> seb128: i believe my bug stands
[15:46] <didrocks> pgraner: I got not issue in the user testing as well
[15:46] <desrt> the bug danilo marked as wontfix is only 1 of my 3 suggested solutions
[15:46] <didrocks> and nothing relevant on lanchpad
[15:46] <seb128> desrt, it seem a similar issue, though the solutions suggested are different
[15:46] <didrocks> launchpad*
[15:46] <seb128> didrocks, I bet you a beer that it's partial upgrades somewhat :p
[15:46] <didrocks> yeah :)
[15:47] <didrocks> like no unity-services
[15:47]  * desrt will fight with him about it :)
[15:47] <didrocks> pgraner: apt-cache policy unity-services
[15:49] <pgraner> seb128, didrocks: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/926137
[15:49] <ubot2`> pgraner: Error: <Bugtracker.plugin.Launchpad instance at 0xa5ae8cc> bug 926137 not found
[15:50] <didrocks> pgraner: waow, the stacktace looks weird
[15:50] <didrocks> let's wait for the retracer
[15:50] <didrocks> pgraner: do you have that constantly?
[15:50] <seb128> didrocks, it retraced and failed
[15:51] <didrocks> oh right, second comment
[15:51] <pgraner> pgraner@beavis:~$ apt-cache policy unity-services
[15:51] <pgraner> unity-services:
[15:51] <pgraner>   Installed: 5.2.0-0ubuntu1
[15:51] <pgraner>   Candidate: 5.2.0-0ubuntu1
[15:51] <pgraner>   Version table:
[15:51] <pgraner>  *** 5.2.0-0ubuntu1 0
[15:51] <pgraner>         500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
[15:51] <pgraner>         100 /var/lib/dpkg/status
[15:51] <didrocks> ok, sounds fine…
[15:51] <seb128> didrocks, side effect of having ddebs out of soyuz, it takes some hours to get the new ddebds
[15:52] <seb128> didrocks, pgraner: sees to be 916228
[15:52] <seb128> seems
[15:52] <seb128> not new in 5.2 and quite some duplicates
[15:52] <didrocks> indeed
[15:53] <seb128> somebody should hit on dx for having ignored it for 5.2
[15:53] <didrocks> I'll add it as critical on unity distro priority
[15:53] <didrocks> as it seems they don't look at milestones
[15:53] <pgraner> seb128, yea by box is borked had to move to laptop
[15:54] <didrocks> pgraner: you didn't get it at all with 5.0 before?
[15:54] <seb128> pgraner, does it happen all the time?
[15:54] <pgraner> didrocks, everytime, I had filed a compiz bug with stacktrace  but its not in lp now
[15:54] <didrocks> pgraner: ok, I've added it as critical on the unity distro priority list
[15:55] <didrocks> pgraner: I'll make sure Tim is aware of it
[15:55] <didrocks> (and eventually distro-patch is)
[15:56] <pgraner> didrocks, refiling the compiz one now
[15:56] <didrocks> pgraner: yes please (I have good feeling it's due to nux or unity as compiz didn't change)
[15:56] <seb128> pgraner, you can try your luck on #ubuntu-unity to see if anyone is wanting to look at the issue
[15:56] <seb128> pgraner, it's not a new bug, it's opened for some time and was milestoned but they ignored it so far, maybe you can provide them useful infos since you get the issue
[15:57] <pgraner> didrocks, its nux ... bug #926149
[15:57] <seb128> pgraner, 916228 is the bug you hit
[15:58] <pgraner> seb128, sure just tell me, hell I'll give em' remote access to the box
[15:58] <didrocks> pgraner: is 926149 a typo? I don't find it or lost access :)
[15:58] <seb128> pgraner, well, it's really a dx issue, try #ubuntu-unity
[15:58] <seb128> didrocks, it's probably not retraced yet
[15:59] <didrocks> right, the team shouldn't be subscribed to it yet
[15:59] <seb128> didrocks, the new apport bugs are private for us until retracing
[15:59] <pgraner> didrocks, yep thats the correct number
[15:59] <didrocks> pgraner: for your first bug, I flagged it for 5.2, and set it as high (then Tim set it as critical)
[15:59] <didrocks> shame that it was ignored
[15:59] <seb128> pgraner, can you go on #ubuntu-unity and ask them if you can help providing infos for 916228
[15:59] <didrocks> seb128: understood!
[15:59] <seb128> ?
[15:59] <seb128> or DBO maybe can help you
[15:59] <pgraner> seb128, sure thing
[16:00] <seb128> but better on #ubuntu-unity anyway
[16:00] <seb128> we only do the packaging, that issue is in the unity code
[16:07] <seb128> tjaalton, hey
[16:07] <seb128> tjaalton, did you forget to push your totem upload to the vcs? it's still UNRELEASED there, you should copy the upload changelog, debcommit -r and push ;-)
[16:10] <tjaalton> seb128: what about now?
[16:11] <seb128> tjaalton, thanks ;-)
[16:11] <tjaalton> probably just forgot the second push, did it now and it seemed to do "something" :)
[16:11] <seb128> tjaalton, it's all good now
[16:11] <tjaalton> great
[16:38] <desrt> seb128: so... how do you feel about orlando in september?
[16:38] <seb128> desrt, ?
[16:38] <desrt> http://www.suse.com/events/susecon/
[16:38] <seb128> lol
[16:38] <desrt> http://en.opensuse.org/SUSECon_Planning
[16:39] <desrt> i'm actually seriously considering going
[16:39] <desrt> i think we should send a large contingent :)
[16:39] <desrt> "uh.  hi.  this is an _ubuntu_ hotel."
[16:39] <seb128> ;-)
[16:39] <jbicha> Linux for Humans not Lizards!
[16:39] <seb128> desrt, it's a short fly for you, I don't consider crossing the ocean just to troll vuntz :p
[16:40]  * desrt would go great distances to troll vuntz
[16:40] <seb128> hehe
[16:40] <desrt> didrocks: you in? :)
[16:41] <seb128> desrt, I'm sure vuntz likes this hotel and remember fondly his UDS there :p
[16:42] <didrocks> desrt: yeah, I'm here :)
[16:42] <desrt> seb128: the first part is probably true. ;)
[16:42] <didrocks> ah
[16:42] <didrocks> oh well, I'm in for sure!
[16:42] <desrt> didrocks: seriously?
[16:42] <desrt> because i'd seriously do this
[16:42] <didrocks> ahah ;)
[16:43] <didrocks> trolling vuntz at any cost!
[16:43] <desrt> it's not just about vuntz, you know
[16:44] <desrt> lizards are people too
[16:46]  * didrocks still remind every that he's sharing his bed with a Novell's lizard because Julie likes it :)
[16:47] <kenvandine> haha
[16:47]  * desrt has such a lizard, but avoids sleeping with it
[16:47] <sil2100> didrocks, smspillaz: just a quick question
[16:47] <sil2100> For the packages I was to prepare, what version of libnux should I use?
[16:48] <didrocks> sil2100: hum, you mean, unity in general,
[16:48] <didrocks> sil2100: you should just take the version in the distro
[16:48] <didrocks> of unity
[16:48] <didrocks> reapply my changes
[16:48] <didrocks> and build from that
[16:49] <didrocks> desrt: I'm sure it was a vuntz evil plan when he gave me one at guadec!
[16:49] <sil2100> Since I'm trying to make someone from my team install my packages, but it seems he has a too 'recent' libnux2.0-0, which makes installing my unity packages impossible
[16:49] <didrocks> sil2100: is he on precise?
[16:50] <sil2100> didrocks: yes, and he seems to have a newer libnux2.0-0 - in version 2.2-0ubuntu1
[16:50] <didrocks> sil2100: yeah, that's why you should build with my latest unity branch
[16:50] <sil2100> While I have (and the packages I built require) libnux2.0-0 in version 2.2-0ubuntu2
[16:50] <didrocks> sil2100: lp:~ubuntu-desktop/unity/unbuntu
[16:50] <didrocks> ubuntu*
[16:51] <sil2100> But wait, I think I did
[16:51] <didrocks> then takes the branch with my changes I pointed to you (the sed change in debian/rules)
[16:51] <didrocks> and apply it on top of this branch
[16:52] <sil2100> hmmm, ok
[16:52]  * sil2100 got a bit lost in all the packages, patches and versions
[16:53] <sil2100> One moment then ;) Thanks
[16:57] <desrt> didrocks: https://bugzilla.gnome.org/show_bug.cgi?id=669324
[16:57] <ubot2`> Gnome bug 669324 in gsettings "API for getting 'reset' GSettings value" [Normal,New]
[16:58] <desrt> didrocks: basically a bug talking about the reasons for not wanting that API.  i welcome your thoughts.
[16:58] <didrocks> desrt: oh sure, sorry, kind of pingy machine right now, but I'm opening the tab :)
[16:59] <desrt> no worries.
[17:23] <popey> cjwatson: is it expected behaviour during 12.04 install to 'wipe swap space for security' even on a brand new laptop which only ever had windows 7 on it?
[17:35] <seb128> does somebody understand what's going on there?
[17:35] <seb128> http://paste.ubuntu.com/827823/
[17:35] <seb128> desrt, ^ maybe you? ;-)
[17:35] <seb128> it's basically filesystem stuff but I don't get it, it's a file it would let me rm
[17:36] <desrt> seb128: i assume you are 'user' here
[17:36] <cjwatson> popey: yes, if you're using encrypted swap
[17:36] <seb128> I start thinking it's a libc, coreutils bug or something
[17:36] <seb128> yes
[17:37] <cjwatson> or rather an encrypted home directory or whatever it is
[17:37] <desrt> seb128: there's no good reason for why that should be happening
[17:37] <seb128> desrt, I can't recreate the issue myself by creating a dir and file with the same permission
[17:37] <desrt> seb128: it looks like a weird filesystem issue
[17:37] <seb128> desrt, that's the automake testsuit issue
[17:37] <desrt> or maybe apparmor is doing something
[17:37] <desrt> wtf
[17:38] <seb128> yes, wtf
[17:38] <desrt> all you need for 'rm' is write access to the directory
[17:38] <seb128> I don't get it
[17:38] <apw> desrt, it worked for me
[17:38] <seb128> and I can't recreate it manually
[17:38] <desrt> seb128: there's something weird going on on the builders
[17:38] <desrt> (as usual)
[17:38] <seb128> somewhat the automake script is creating it in a weird way
[17:38] <seb128> desrt, no, I get it on my disk
[17:38] <desrt> oh
[17:38] <seb128> it's my box
[17:38] <desrt> weird!!
[17:38] <seb128> yes...
[17:38] <seb128> I can cp the dir around and it's still buggy
[17:39] <desrt> but when you create it yourself, not
[17:39] <seb128> but if I tar and untar it the untarred dir works
[17:39] <desrt> maybe ACL?
[17:39] <seb128> acl?
[17:39] <desrt> access control lists
[17:39] <seb128> right, but how do I check that?
[17:40] <desrt> lsattr might be a place to start?
[17:40] <seb128> thanks I was trying to remember that command :p
[17:40]  * desrt knows so very little about this stuff
[17:40] <seb128> $ lsattr bug
[17:40] <seb128> -------------e- bug/file2
[17:40] <desrt> ya.  that's normal.
[17:40] <desrt> check the dir?
[17:40] <seb128> bug is the dir
[17:40] <desrt> ya.  what's the dir say?
[17:40] <desrt> lsattr -d bug
[17:41] <seb128> $ lsattr -d bug
[17:41] <seb128> -------------e- bug
[17:41] <desrt> seb128: and what happens if you use 'tar' to do the copy?
[17:41] <desrt> and can you send me the result?
[17:41] <seb128> desrt, <seb128> but if I tar and untar it the untarred dir works
[17:41] <desrt> crap!
[17:41] <seb128> desrt, I tried, that "fixes" it
[17:41] <apw> seb128, where did this come from this directory ?
[17:41] <desrt> seb128: can you paste the result of 'strace rm -rf bug' ?
[17:41] <apw> seb128, and have you checked dmesg
[17:42]  * desrt wants to see the unlink() call failing
[17:42] <seb128> apw, the dir comes from the automake1.11 test suit
[17:42] <seb128> a make distdir test case
[17:42] <seb128> the same testsuit works on debian
[17:42] <apw> an strace sounds good here, pls pastebin it
[17:42] <seb128> apw, nothing weird in dmesg
[17:43] <desrt> seb128: sounds like apparmor, then?
[17:43] <seb128> apw, well "dmesg" is useless, it's spammed by tons of
[17:43] <seb128> [31734.002164] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
[17:43] <sil2100> aarghh
[17:43] <desrt> oh.
[17:43] <sil2100> (don't mind me)
[17:43] <apw> seb128, is bug in the ecryptfs ?
[17:43] <desrt> this is on a cryptfs homedir?
[17:43] <seb128> desrt, that's just spam, nothing to do with this bug, buildds don't use ecryptfs
[17:43] <jdstrand> grep DEN /var/log/kern.log
[17:43] <desrt> k...
[17:43] <jdstrand> that doesn't sound like apparmor
[17:43] <seb128> apw, no, the build fails on buildds
[17:44] <popey> cjwatson: oh, encrypted home implies encrypted swap? makes sense ☺
[17:44] <jdstrand> we don't profile the shell or 'rm'
[17:44] <apw> but right now, is this bug directory in there now
[17:44] <seb128> http://paste.ubuntu.com/827834/
[17:44] <seb128> that's the strace
[17:45] <apw> seb128,what filesystem type is 'bug' in
[17:45] <seb128> apw, ext4
[17:45] <cjwatson> popey: yep
[17:45] <apw> seb128, no overlays or anything
[17:45] <jdstrand> sounds like ecryptfs too
[17:46] <seb128> right, my user dir is ecryptfs, but the same test fails on the builders
[17:46] <seb128> let me try to get out of the ecryptfs for debugging
[17:46] <jdstrand> weird
[17:46] <apw> seb128, so this isn't ext4 at all then ?
[17:46] <apw> seb128, so we may have a different local reason for failure here
[17:46] <desrt> seb128: can you try on your local machine inside of a native ext4 fs?
[17:46] <apw> can you confirm whether you get an new ecryptfs report for each rm ?
[17:46] <desrt> or on a tmpfs, even?
[17:47] <apw> as the error there means you have a broken encrypted file on disk, often a 0 length file in the underlying fs
[17:48] <desrt> seb128: also... buy a thinkpad :)
[17:48] <seb128> sorry guys, trying to get the issue out of ecryptfs
[17:49] <seb128> apw, no, I don't get new ecryptfs error every time I try to rm it
[17:52] <seb128> http://paste.ubuntu.com/827844/
[17:52] <seb128> that's in my /tmp
[17:53] <seb128> i.e out of my user ecryptfs dir
[17:53] <desrt> seb128: okay.  next show us a strace of you cping the file
[17:53] <jdstrand> seb128: your lsattr output is interesting
[17:53] <desrt> strace cp -a bug /tmp
[17:53] <jdstrand> the 'e' is not normal. I don't think tar will preserve extended attributes
[17:53] <seb128> desrt, http://paste.ubuntu.com/827847/
[17:53] <desrt> this is getting awesome
[17:54] <jdstrand> man chattr tells me that 'e' is 'extent format'
[17:54] <desrt> fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x04\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = 0
[17:54] <desrt> hum!!
[17:54] <seb128> jdstrand, hum
[17:54] <desrt> seb128: apt-get install attr
[17:55] <desrt> seb128: and run getfattr -d on some things
[17:56] <desrt> seb128: this is almost certainly some posix acl thing after all
[17:57] <jdstrand> seb128: actually, that might be a flase alarm
[17:57] <seb128> desrt, getfattr -d outputs nothing
[17:57] <jdstrand> seb128: looks like 'e' is used when it is on ecryptfs
[17:57] <desrt> seb128: even on the file in /tmp ?
[17:57] <desrt> after copying...
[17:58] <seb128> $ getfattr -d /tmp/unity_support_test.0
[17:58] <seb128> $
[17:58] <desrt> this is very annoying!!
[17:58] <desrt> seb128: i guess root can delete it anyway, right?
[17:58] <seb128> desrt, yes
[17:59] <desrt> seb128: it strikes me as a bit odd...
[17:59] <desrt> because clearly fsetxattr is being called here
[17:59] <seb128> desrt, I will try to get a sharable testcase
[17:59] <seb128> well you can apt-get source automake1.11 and build it if you want
[17:59] <desrt> seb128: try with -m -
[17:59] <desrt> to fgetattr
[17:59] <desrt> or getfattr (dumb command name)
[18:00] <kenvandine> :-D
[18:00] <desrt> seb128: looks like the default behaviour is to filter out 'system' items from the output of -d
[18:01] <desrt> seb128: looks like there is also a getfacl command
[18:01] <seb128> still no output
[18:01] <seb128> do you get output from it?
[18:02] <desrt> seb128: i get nothing from it, but my filesystem isn't filled with evil files :)
[18:02] <seb128> $ getfacl file3
[18:02] <seb128> # file: file3
[18:02] <seb128> # owner: seb128
[18:02] <seb128> # group: seb128
[18:02] <seb128> user::r--
[18:02] <seb128> group::r--
[18:02] <seb128> other::r--
[18:02] <seb128> $ rm file3
[18:02] <seb128> rm: remove write-protected regular empty file `file3'? y
[18:02] <seb128> rm: cannot remove `file3': Permission denied
[18:02] <desrt> behold.  totally normal.
[18:04] <desrt> seb128: this is amazing...
[18:05] <desrt> seb128: what if you copy without -a ?
[18:05]  * desrt would be very surprised if the problem still happened in that case
[18:06] <seb128> desrt, wait, I'm very confused now, I will redo a proper build in /tmp to be sure to have nothing weird from my ecryptfs
[18:06] <desrt> seb128: it shouldn't matter
[18:06] <desrt> seb128: if there is no acl being copied to /tmp then i can't imagine what the issue would be
[18:06] <desrt> seb128: but yes.  please try that :)
[18:07] <stgraber> seb128: you tried lsattr on it already I guess? (should be -------------e- if nothing special)
[18:07] <seb128> stgraber, yes
[18:09]  * didrocks waves good evening and good week-end!
[18:09] <seb128> 'night didrocks
[18:09] <desrt> didrocks: good night
[18:09] <didrocks> merci seb128, toi aussi! You too desrt :)
[18:10] <seb128> desrt, seems it doesn't bug the same way out of my user dir
[18:10] <desrt> seb128: add to it the fact that debian seems fine...
[18:10] <desrt> and fedora too
[18:11] <desrt> i wonder if the builders have some weird ecrypt-like issue
[18:11] <desrt> maybe linux containers or something, causing trouble?
[18:11] <seb128> desrt, well I would assume the debian buildders have similar containers and automake built on our builders before
[18:12] <desrt> seb128: you said 2.11.2b had the same problem, right?
[18:12] <seb128> desrt, that's 1.11.2 we are talking about
[18:12] <desrt> well, afaik nobody actually packaged 1.11.2?
[18:12] <seb128> desrt, it's the version debian has and that I synced today and that failed to build
[18:13] <desrt> right.  okay.
[18:13] <seb128> desrt, .3 was for the ppa but it hits similar issues
[18:13] <desrt> .2 must be recently packaged
[18:13] <seb128> desrt, 2012-01-15
[18:14] <desrt> i'm guessing that was in response to my ping to the maintainer asking about packaging .3 when it comes out
[18:14] <desrt> "oh.. i didn't even do .2... let's do that now"
[18:14] <desrt> seb128: did you consider trying a build of .1 on your machine?
[18:14] <desrt> or on the builders?
[18:14] <seb128> desrt, yes, .1 failed the same way on my machine
[18:14] <desrt> because... like... it could be automake that changed, between .1 and .2
[18:14] <desrt> or it could be something else
[18:14] <desrt> ah
[18:15] <seb128> but I start thinking my issue is ecryptfs related
[18:15] <desrt> so that's very interesting
[18:15] <desrt> well... maybe not
[18:15] <desrt> .1 used to work on the builders, and presumably used to work on ecryptfs (let's assume)
[18:15] <desrt> now it doesn't
[18:15] <desrt> the builders and you don't share a kernel, but they do share a userspace
[18:16] <desrt> i wonder if something in precise like glibc or libacl or something like that have some weird issue that is causing troubles
[18:17] <desrt> can you try submitting .1 to the builders?
[18:17] <desrt> under precise
[18:17] <seb128> desrt, yes, will do that
[18:18] <desrt> looks like doko may end up with some work to do after all ;)
[18:18] <seb128> I also started a build on a porter box to make sure it's not ecryptfs
[18:18] <seb128> ;-)
[18:18] <desrt> seb128: does the plain upstream tarball cause the issue?
[18:18] <seb128> desrt, if you don't need to much cpu for your work you can just apt-get source automake1.11 cd here and debuild it
[18:18] <desrt> okay.  i'll do that.
[18:19] <desrt> i have an encrypted filesystem... but not a bad one :)
[18:19] <seb128> desrt, it's distdir.test fail fails there when doing the make check-TESTS
[18:20]  * desrt is on acloca17
[18:20] <seb128> desrt, yeah, it can take a while
[18:21] <mdeslaur> seb128: do you need to do something special to get the user wallpapers in lightdm?
[18:21] <seb128> desrt, you can try to stop it and just run ./distdir.test
[18:21] <seb128> in tests
[18:22] <seb128> mdeslaur, define user, it doesn't work with wallpapers stored in your user dir atm and you need to change the background in the control center
[18:22] <seb128> mdeslaur, lightdm only has the path to the image, if it's in an user dir it can't read that doesn't work
[18:24] <mdeslaur> seb128: ah, ok, cool
[18:24] <seb128> desrt, that specific issue is ecryptfs for sure then
[18:25] <seb128> I don't need a full build
[18:25] <seb128> - apt-get source automake1.11
[18:25] <seb128> cd automake1.11-1.11.1
[18:25] <seb128> ./configure && make
[18:25] <seb128> cd tests
[18:25] <seb128> ./distdir.test
[18:25] <seb128>  
[18:25] <seb128> it breaks in my user dir
[18:25] <seb128> works in tmp
[18:25] <seb128> let's see what the build on the porter box do
[18:26] <desrt> i just don't understand how you can copy the file from your userdir to tmp and still have the problem
[18:26] <seb128> I guess the buildds issue is different from mine
[18:26] <desrt> yet supposedly there are no extended attributes or anything
[18:26] <desrt> seb128: did you look at the log?
[18:26] <desrt> like... does it fail the same test in the same way?
[18:26] <desrt> or just.... some issue?
[18:27] <seb128> $ rm -rf /tmp/some/file
[18:27] <seb128> rm: cannot remove `/tmp/some/file': Permission denied
[18:27] <seb128> $
[18:27] <seb128> yet ...
[18:27] <seb128> desrt, the log has no details, it has a line PASS: or FAIL: <testname> for each test
[18:27] <seb128> so I just know it failed
[18:27] <desrt> same test, tho
[18:27] <seb128> yes
[18:28] <seb128> in 800 tests
[18:28] <desrt> a mystery!
[18:28] <seb128> one fail and it's the same one
[18:28] <desrt> PASS: distdir.test
[18:29] <desrt> seb128: get a thinkpad :p
[18:29] <seb128> desrt, lol
[18:34] <seb128> desrt, ok, thanks for the help
[18:35] <desrt> seb128: i'm the one that gave you the problem in the first place
[18:35] <desrt> really, doko should be thanking me ;)
[18:35] <seb128> desrt, the retry failed on another test so I think the buildd issue is a different one
[18:35] <seb128> desrt, and my local build issue is an ecryptfs issue for sure
[18:36] <seb128> desrt, I will upload a package with verbose output for the buildd issue
[18:36] <desrt> seb128: cool
[18:36] <desrt> maybe it was just ETOOMANYTESTS
[18:36] <seb128> I should give it to chrisccoulson
[18:36] <seb128> he's used to those :p
[18:37] <chrisccoulson> wassup?
[18:37] <seb128> he got lot of fun firefox testsuit issues
[18:37] <seb128> chrisccoulson, https://launchpadlibrarian.net/91811783/buildlog_ubuntu-precise-i386.automake1.11_1%3A1.11.2-1ubuntu1_FAILEDTOBUILD.txt.gz
[18:37] <seb128> chrisccoulson, want some testsuit fixing fun :p
[18:37] <chrisccoulson> "la la la la la"
[18:37]  * chrisccoulson puts fingers in ears
[18:37] <chrisccoulson> :)
[18:37] <seb128> chrisccoulson, I just wasted an hour to notice that my local issue is due to ecryptfs
[18:38] <seb128> chrisccoulson, it won't let me delete a file
[18:38] <chrisccoulson> that sucks ;)
[18:38] <seb128> empty file in a read only dir, which is fine out of ecryptfs
[18:38] <seb128> indeed!
[18:40] <desrt> seb128: btw: debian maintainer says he will get around to having .3 in debian unstable over the weekend
[18:42] <seb128> desrt, excellent, I can probably sync that on monday then ;-)
[18:43] <desrt> seb128: assuming you can figure out the builder issues
[18:43] <desrt> seb128: got a link to the .1 upload?
[18:43]  * desrt is curious how that will end
[18:46] <seb128> desrt, not yet, I will let you know the details when I'm done with it
[19:03] <kenvandine> seb128, i uploaded g-c-c to the ubuntu-desktop ppa
[19:03] <kenvandine> let the carnage begin :)
[19:08] <desrt> oh.  party time.
[19:08] <desrt> smspillaz: paying attention? :)
[19:08]  * kenvandine heads to lunch, bbiab
[19:08] <desrt> oh
[19:08] <desrt> that's 3.2
[19:08] <desrt> kenvandine: where's the carnage?
[19:10] <jbicha> desrt: I know, I was disappointed too ;)
[19:10] <kenvandine> new sound settings panel for control-center
[19:10] <kenvandine> in the ubuntu-desktop ppa
[19:10] <desrt> that's not carnage
[19:10] <desrt> that's merely sad
[19:11]  * desrt disappears for now
[19:20] <dobey> why is unity-greeter reading my user settings?
[19:24] <jbicha> dobey: which settings? reading your wallpaper is a feature now
[19:24] <dobey> the wallpaper
[19:24] <dobey> i'll file a bug
[19:25] <jbicha> but that's not a bug
[19:25] <dobey> it's a security/privacy issue, and it's a misfeature.
[19:29] <jbicha> dobey: you probably should read bug 844081
[19:29] <ubot2`> Launchpad bug 844081 in accountsservice "Unity Greeter - Background of the Unity Greeter should reflect the background chosen by the user that is currently selected" [Wishlist,Confirmed] https://launchpad.net/bugs/844081
[19:33] <dobey> i should probably file a bug, because any bug with 44 comments and which is considered fixed released (which is technically true, because the bug isn't a bug, but a work statement, and the work was completed).
[19:37] <jbicha> dobey: comment 19 might be what you want but it looks like sabdfl doesn't like the idea
[19:39] <dobey> not really
[19:41] <mdeslaur> dobey: why is that a security/privacy issue? if you don't want local users to read your wallpaper, set appropriate permissions on the file...
[19:41] <jbicha> you could then use a .gschema.override to make it system-wide by default? or how about #6
[19:41] <dobey> one thing i do want, is rationale from design for having such a "feature" in the first place. "it would be nice" or "we should do it" are not rational reasons to implement it.
[19:42] <jbicha> how about "it looks cool" and makes the computer "more personalized"
[19:43] <dobey> mdeslaur: ~/.config/dconf is only readable by me.
[19:43] <dobey> jbicha: no
[19:43] <jbicha> I am a bit skeptical of it being a privacy issue, it's not like it's showing stuff from hidden directories in ~/Pictures
[19:43] <dobey> jbicha: well, not unless it's set as your background anyway
[19:43] <jbicha> then it's not very private, is it? ;)
[19:44] <dobey> sure, unless you are choosing to set it as your greeter background as well
[19:44] <dobey> which i haven't done
[19:45] <dobey> also, it's not clear how it technically works (i haven't looked at the code yet). but it's either doing evil and reading my stuff somehow, despite the fact it shouldn't be allowed to, or it's copying my data somewhere it shouldn't be.
[19:45] <mdeslaur> dobey: when you change backgrounds, the filename gets sent to AccountsService which stores it in /var/lib/AccountsService
[19:46] <dobey> yeah it shouldn't do that
[19:47] <mdeslaur> I'm sorry, I don't quite understand...your background is also displayed when your screen is locked, and is usually in a file located in your home directory which is readable by other users
[19:48] <dobey> mdeslaur: and i think displaying the background on the screen unlock is also a problem
[19:49] <dobey> but at least the screen lock isn't copying my *user* settings to a systemwide location for peruse later by some other tool that's not the user
[19:51] <dobey> if it were opt *in* that would be different
[19:51] <seb128> desrt, https://bugs.launchpad.net/ecryptfs/+bug/926292 for the record
[19:51] <ubot2`> Launchpad bug 926292 in linux "automake distdir.test fails because of an EPERM error" [Medium,Confirmed]
[19:54] <seb128> dobey, that's copying nothing, that's putting a filename in a database, if you userdir or the directory of the image is not readable by the greeter user no background is being displayed
[19:54] <seb128> dobey, if the file you use is wordreadable it's that you don't care so much about it being private
[19:55] <dobey> seb128: my DCONF directory is not readable by the greeter. it is copying a value out of one database which is not readable, into another which is
[19:55] <seb128> dobey, it's copying a filename and no it's not copying it, the control center is setting it in another database
[19:56] <seb128> dobey, no copy is done
[19:56] <seb128> you just a tool which is writting setting in accountsservice
[19:56] <seb128> if you don't like it don't use the tool
[19:56] <dobey> seb128: fine, it's piped to N places, which don't have the same read permissions, and violates the default permissions
[19:56] <dobey> don't use what tool?
[19:56] <seb128> dobey, indeed, don't use it if you don't like it
[19:56] <dobey> don't use what?
[19:57] <seb128> dobey, it's also writing your locale and keymap in that same public database
[19:57] <seb128> dobey, gnome-control-center
[19:57] <dobey> i should go buy macos then?
[19:57] <mdeslaur> and user icon
[19:57] <seb128> and username
[19:57] <seb128> dobey, if you think macos is giving better control and a better view of what the os is doing from your datas sure
[19:57] <dobey> sigh
[19:58] <seb128> why not? nobody force you to use open tools, you are fine to use closed source and trust apple
[19:58] <seb128> who knows they might collect your background image over the internet without telling you ;-)
[19:59] <seb128> dobey, it's only the path to a file, it's not even datas or content, what's the big deal?
[19:59] <dobey> for all i know, accountsservice is doing that
[19:59] <seb128> dobey, well you know little, at least you can read the source in this case ;-)
[19:59] <dobey> i'd have to read the code and watch the tcp traffic to determine it's not
[20:00] <dobey> the big deal is it's broken
[20:00] <seb128> dobey, so you assume people mean bad by default there?
[20:00] <seb128> how so?
[20:00] <dobey> no, i don't assume people mean bad. i don't assume anything.
[20:02] <dobey> well, what if my background is a 32x32 image which is tiled? what if it's a small image that's centered? what about the background colors and gradient? opacity? and it makes non-plain backgrounds look like crap with the greeter's overlay having all the white dots
[20:03] <dobey> and it's the first setting. if it's ok to have a copy of that setting somewhere, when is it not ok to write a copy of a setting to that world readable database?
[20:03] <dobey> i never explicitly chose to have my configuration written there. i chose to have my configuration written in XDG_CONFIG_HOME which is set to ~/.config/; and which is not world-readable
[20:04] <seb128> dobey, you don't have your configuration there, you have a filename
[20:04] <dobey> seb128: how did it get there?
[20:04] <seb128> dobey, do you have issues with having your locale and keyboard layout there?
[20:05] <dobey> i changed some configuration and it was placed in 2 places. one which is not world readable, and one which is.
[20:05] <dobey> seb128: yes
[20:05] <seb128> dobey, the same way that your icon, keymap, locale, etc get there for yers
[20:05] <seb128> years
[20:05] <dobey> now that i know they are being written there, i have a problem with them being written there
[20:05] <dobey> years?
[20:05] <seb128> yes
[20:05] <dobey> accountsservice is not "years" old
[20:05] <seb128> the login screen has access to your keymap and locale for years
[20:06] <seb128> right, before there was a copy of .dmrc in /var
[20:06] <seb128> which is an user config with your session, locale, keymap etc
[20:06] <dobey> you mean when i choose the session/keymap/locale *in* the dm?
[20:06] <seb128> how do you think gdm was getting your locale,keyboard infos?
[20:06] <seb128> the user session stuff update the same config
[20:07] <dobey> if i choose something in the *DM* it's not a user config
[20:07] <seb128> the dm doesn't always have access to your user dir to write those
[20:07] <dobey> and really it should store it via some pam thing in that case
[20:08] <seb128> same problem
[20:08] <mdeslaur> your user image icon has been copied system wide for years
[20:08] <seb128> if you user dir is encrypted how can the login screen get your keymap right?
[20:08] <mdeslaur> dobey: please file a bug, a bug discussion would be better
[20:08] <dobey> the user face avatar thing i don't care about. it's something that was always explicitly specified as being the thing that appears in the login screen.
[20:09] <dobey> seb128: keymap really should be stored via pam
[20:09] <dobey> anyway, yes i will file a bug
[20:11] <seb128> dobey, there is already a bug
[20:11] <seb128> dobey, it will be dupped
[20:11] <seb128> dobey, it's wontfix in any case
[20:11] <mdeslaur> so, by default, when you select a  background in gnome-control-center, it copies it with a hashed name into your .config directory. That directory is only readable by you by default, and the original filename is mangled.
[20:11] <dobey> yes
[20:12] <seb128> that seems like a "make things not working"
[20:12] <seb128> I will object to that
[20:12] <dobey> make things not working?
[20:12] <mdeslaur> seb128: object to what? that's the current behaviour
[20:12] <seb128> what you suggest is broken yes
[20:12] <dobey> i haven't suggested anything exactly
[20:12] <seb128> mdeslaur, no, the current behaviour doesn't require access to your userdir
[20:12] <dobey> seb128: and what mdeslaur just said, is how dconf works
[20:13] <mdeslaur> seb128: when you select a custom image in gnome-control-center, currently, that's what happens
[20:13] <seb128> I've picked an image from the default system set for my ecryptfs user and it's reflected on the login screen
[20:13] <mdeslaur> seb128: if you select from the default system images, it gets displayed on the login screen
[20:13] <seb128> right
[20:13] <seb128> which seems the correct behaviour to me
[20:14] <mdeslaur> this isn't exactly a privacy leak, it will only show what your preference of filtered system images are, not some random pr0n from your home directory
[20:14] <seb128> right ;-)
[20:14] <seb128> I'm fine with that
[20:14] <mdeslaur> yes, me too
[20:14] <seb128> I just don't get what dobey wants to open a bug about
[20:14] <seb128> I think the current behaviour is fine
[20:14] <seb128> if you select a system image it's not private
[20:14] <seb128> if you select a personal photo it is
[20:15] <seb128> that seems sane enough
[20:15] <mdeslaur> seems sane to me
[20:17] <dobey> not entirely true
[20:18] <seb128> dobey, what is not true?
[20:19] <seb128> dobey, well read the discussion on the bug pointed before before opening a new one in any case, also note that nobody force you to use the default config or greeter
[20:21] <dobey> so it looks like gnome-control-center copies the background into a hashed name in the XDG_CACHE_HOME folder; and this filename gets written to accountsservice, when it's not a system background
[20:22] <seb128> right
[20:22] <seb128> that directory is only readable by your user
[20:23] <dobey> yes, but it shouldn't write the path to the system in that case either
[20:23] <dobey> and even if it didn't do that, it doesn't resolve all of the other problems with the "feature"
[20:24] <RainCT> hey seb128, still working?
[20:24] <seb128> not sure what's the intend there but I think if the original file is world readable the greeter should reflect it
[20:24] <seb128> RainCT, hey, sort of, rather IRC arguing than "working" ;-)
[20:24] <seb128> dobey, what problems?
[20:25] <RainCT> seb128: Heh. I've got a Nautilus patch for you :). But I guess having it reviewed by someone first wouldn't hurt, so I'll bug you on Monday about it :P
[20:25] <seb128> RainCT, ok ;-)
[20:25] <dobey> the dot overlay, tile/zoom/color options missing (which would increase privacy concern if they were also copied); and *WHY* having this "feature" is even a good idea
[20:38] <rye> hello, bug #926152 - adding ppa is broken now
[20:40] <mdeslaur> rye: argh, thanks
[20:43] <rye> mdeslaur, it was unassigned and it looks i can't add my own ppa :)
[20:44] <mdeslaur> rye: I broke it :)
[20:46] <rye> ah
[21:09] <mdeslaur> rye: fix uploaded, thanks
[21:12] <rye> mdeslaur, wow, thank _you_!
[21:43] <dobey> kenvandine: are there any special requirements under the new upstream-is-canonical upload stuff, for when a package adds new binary packages?
[21:43] <kenvandine> nothing new
[21:43] <dobey> so i should just upload it and poke someone to approve it?
[21:43] <kenvandine> it'll still go to binNEW
[21:43] <kenvandine> yeah
[21:44] <dobey> alright, cool