[03:56] <pitti> Bonjour
[03:57] <pitti> RAOF: btw, did you find a sponsor for colord?
[03:57] <RAOF> pitti: No, I haven't yet.
[03:57] <RAOF> I haven't been shopping around much, either, though.
[04:21] <pitti> RAOF: ooh, what do I see in my mailbox!
[04:21] <pitti> [rt.debian.org #4455] Resolved: Martin Pitt's new gpg key
[04:26] <RAOF> pitti: Yay!
[04:35] <pitti> RAOF: so, want me to upload colord?
[04:35] <RAOF> Yes please!
[04:37] <pitti> RAOF: oh, you didn't bump the glib build dep? >= 2.36.0 or so?
[04:37] <pitti> well, I guess not that important unless someone wants to backport
[04:47] <RAOF> pitti: Would you like me to bump that build-dep? It's simple enough to do so.
[04:47] <RAOF> Failing that, I'll do it after upload.
[04:47] <pitti> RAOF: well, if it messes up your dch -r/tagging etc., don't worry for now
[04:47] <pitti> RAOF: I'm currently running it through run-adt-test, just to confirm
[04:47] <RAOF> Ta.
[04:51] <pitti> ubtree0t-make-check  FAIL status: 2, stderr: make: *** No rule to make target `c...
[04:52] <pitti> meh
[04:52] <pitti> debian bug 711209 strikes again
[04:52] <ubot2`> Debian bug 711209 in autopkgtest "autopkgtest: build-needed restriction doesn't actually run tests in built tree" [Normal,Open] http://bugs.debian.org/711209
[04:52] <pitti> but that shouldn't happen when running from the archive
[04:52] <pitti> but the build worked fine at least
[04:54] <RAOF> That won't happen when running from the archive? Yay!
[04:57] <pitti> Uploading colord_1.0.1-1_amd64.changes: done.
[04:57]  * pitti feels the powah again!
[07:50] <seb128> good morning desktopers
[07:50] <pitti> good mooooorning, seb128!
[07:51] <seb128> pitti, good mooooorning freedom lover! ;-)
[07:51] <seb128> pitti, welcome back in the debian keyring!
[07:51] <pitti> seb128: merci beaucoup! the force is strong in me again!
[07:52] <seb128> ;-)
[08:01] <Laney> hey
[08:02] <seb128> Laney, good morning!
[08:03] <Laney> a fine day it is too
[08:04] <seb128> let's see, sky is blue and it's not rainy, so it's a good start ;-)
[08:04] <pitti> Laney: FYI, I re-tried glib autopkgtest this morning again, but it still fails
[08:04] <pitti> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-glib2.0/17/
[08:04] <Laney> pitti: I kind of expected it to
[08:04] <tvoss> infinity, ping
[08:04] <Laney> I'm about to finish packaging the test runner
[08:04] <pitti> it timed out
[08:04] <pitti> so some test was hanging
[08:05] <pitti> three apport .crashes on that, though
[08:05] <Laney> where's stdout from that test?
[08:05] <pitti> Laney: perhaps simply a case of some missing test depends?
[08:05] <pitti> Laney: it timed out, there is none :/
[08:05] <Laney> urgh
[08:05] <pitti> due do another autopkgtest bug
[08:05] <pitti> AttributeError: 'NoneType' object has no attribute 'stdin'
[08:05] <Laney> anyway, I might have set the environment up wrong
[08:06] <pitti> but I guesss you can reproduce this in "run-adt-test -sPk glib2.0"
[08:06] <Laney> oh, I don't know about this script
[08:06] <pitti> and then ssh in, and run it manually (without adt-run) to see what happens
[08:06] <Laney> I was monkeying aroudn with adt-run but I couldn't figure out how to make it not try to build the source
[08:07] <Laney> which is annoying
[08:07] <pitti> Laney: oh, you don't? http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
[08:07] <Laney> adt-run --some-options --- adt-virt-schroot saucy-amd64
[08:07] <pitti> Laney: adt-run --built-tree=. --no-built-binaries --- adt-virt-null
[08:07] <pitti> or schroot, yes
[08:07] <Laney> will that satisfy the test depends from apt?
[08:07] <pitti> yes
[08:07] <Laney> oh, cool!
[08:08] <Laney> anyway, packaging the test runner, modifying the autopkgtest to use that and then seeing what still fails
[08:08] <pitti> Laney: so you can also just do "run-adt-test -sPl" to log in, then apt-get source glib2.0, then run "adt-run --built-tree=. --no-built-binaries --- adt-virt-null"
[08:09] <Laney> great
[08:09] <pitti> Laney: "run-adt-test -sUl" is an effing fast and convenient way to get a throwaway VM in tmpfs, I use that often to debug apt problems or run NM tests, etc.
[08:09] <Laney> urk, fsck "Errors were found"
[08:09] <pitti> $ cat .adtrc
[08:09] <pitti> APTPROXY=http://10.0.2.2:3142
[08:10] <pitti> with that, it'll even use your local apt-cacher-ng, so installing stuff happens in the blink of an eye
[08:10] <Laney> ah, I'd want to make it use my local mirror
[08:10] <pitti> or that
[08:11] <pitti> Laney: there's no option for that ATM (feel free to propose one), for now you can just change it in ./bin/prepare-testbed
[08:11] <seb128> $ run-adt-test
[08:11] <seb128> run-adt-test : commande introuvable
[08:11] <seb128> pitti, do you have a wikipage/manpage about what is run-adt-test? ;-)
[08:11] <pitti> http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
[08:12] <pitti> bzr branch lp:auto-package-testing
[08:12] <seb128> danke
[08:12] <pitti> not packaged ATM; perhaps it should be at some point (ubuntu-dev-scripts or so)
[08:12] <pitti> seb128, Laney: oh, you need to run "prepare-testbed amd64" (or i386) once first, of course; all on that page
[08:13] <Laney> my first challenge is to figure out how to start a new package in pkg-gnome SVN
[08:14] <Laney> ah just one svn propset
[08:14] <seb128> Laney, checkout, mkdir, svn add?
[08:14] <Laney> I was just scared of getting the properties wrong because of their weird layout
[08:15] <infinity> tvoss: ?
[08:15] <tvoss> infinity, hey there, quick question if kubuntu-desktop is good to install on saucy, yet?
[08:15] <infinity> tvoss: You'd be better off asking Riddell or ScottK, but I think they got the world mostly under control.
[08:16] <tvoss> infinity, okay, thanks
[08:21] <tvoss> infinity, a manual install of kde-workspace fixed the issue, installing kubuntu-desktop now
[09:43] <Laney> SUMMARY: total: 196 passed: 196 skipped: 0 failed: 0
[09:43] <Laney> wee
[09:45] <Laney> pitti: seems to work if I use the proper runner :-)
[09:45] <pitti> Laney: nice!
[09:46] <Laney> just uploaded to debian NEW, will sync it over manually if needed at the next glib upload
[09:46] <Laney> SVN, CDBS, ... love pkg-gnome packaging
[09:51] <pitti> at some point we ought to at least move to dh7 IMHO
[09:51] <Laney> I remember that someone was working on git migration but it stalled
[09:52] <Laney> IIRC because the team wanted to migrate everything at once which is a lot of work
[10:29] <mlankhorst> didrocks: so now that unity landed, x1.14 time?
[10:29] <didrocks> mlankhorst: did you get any confirmation from the call for testing that it's ok?
[10:30] <mlankhorst> touch was broken, but it was already the case and even all the upstream bug fixes don't fix it yet. :(
[10:31] <didrocks> mlankhorst: multitouch was alredy broken? I think nobody is maintaining it anyway
[10:32] <didrocks> mlankhorst: but did you get people "acking" that barriers are still working, everything's fine?
[10:32] <darkxst> X 1.14 is working well here, no touch though
[10:32] <mlankhorst> whot is doing it upstream, I helped him with a lot of bugfixes but the hanging touch bug is still around..
[10:32] <didrocks> ok, I think the barriers are the most important one
[10:32]  * mlankhorst checks
[10:32] <darkxst> barriers work well on gnome-shell
[10:33] <Laney> "unity landed" -> only need X PPA?
[10:33] <mlankhorst> yeah
[10:33] <didrocks> darkxst: interested in the Unity experience TBH :p
[10:33] <Laney> ok, will check here then
[10:33] <Laney> I didn't really feel like enabling the daily ppa
[10:35] <darkxst> I figured that, but I don't use unity
[10:36]  * Laney reboots
[10:40] <Laney> I haz barriers
[10:42] <didrocks> Laney: hiding/showing the launcher then works? :)
[10:42] <Laney> yep
[10:43] <Laney> (as much as it ever did :P)
[10:43] <didrocks> great :)
[10:43] <Laney> mlankhorst: yeah, seems fine here on nvidia
[10:43] <didrocks> mlankhorst: let's plan doing the transition tomorrow then? we need to land unity at the same time with the patch, right?
[10:44] <mlankhorst> didrocks: I patched up unity in the ppa :)
[10:44] <didrocks> mlankhorst: yeah, so we need to land both at the same time
[10:44] <didrocks> mlankhorst: you are going to add a Breaks: unity (<< ) I guess?
[10:44] <didrocks> to ensure people don't get in a middle-transition state
[10:45] <mlankhorst> I don't think that's the correct way to do it here, it's a tad annoying due to updates
[10:45] <didrocks> why?
[10:45] <didrocks> the new Xorg will breaks unity without installing the updated version (at least, the barriers)
[10:47] <mlankhorst> the x server may not run on the same computer as the x client, I think in general having a breaks like that is a bad idea..
[10:48] <didrocks> mlankhorst: how do you want to handle the transition then and avoiding having people upgrading at the bad time?
[10:48] <mlankhorst> I depend on the new libxi/libxfixes in unity, that's the best I can do
[10:50] <didrocks> mlankhorst: but that doesn't make the other side, people upgrading xorg and having a broken unity?
[10:50] <Laney> wait
[10:50] <Laney> I just tried a few sessions and now my unity session didn't come up
[10:51] <Laney> [   739.512] (EE) NVIDIA(GPU-0): EVO Push buffer channel allocation failed
[10:51] <Laney> [   739.512] (EE)  *** Aborting ***
[10:51] <Laney> [   739.512] (EE) NVIDIA(GPU-0): Failed to allocate EVO core DMA push buffer
[10:51] <Laney> [   739.512] (EE)  *** Aborting ***
[10:51] <mlankhorst> congratulations, you probably found a bug in the nvidia driver, or the display part of your hardware hung
[10:52] <Laney> tell me how best to file a bug report ^_^
[10:52] <mlankhorst> tseliot would know
[10:54] <tseliot> Laney: can you try removing ~/.nvidia-settings-rc and restarting X, please?
[10:54] <Laney> tseliot: I don't have that file
[10:55] <mlankhorst> Laney: anything in dmesg?
[10:55] <Laney> [  640.929781] NVRM: GPU at 0000:01:00: GPU-ddd6c16b-fd05-a479-f9db-93c7aa8f9f3b
[10:55] <Laney> [  641.945261] current rate 0 is different from the runtime rate 48000
[10:55] <Laney> don't know what that one came from
[10:56] <tseliot> Laney: ok then please type: sudo nvidia-bug-report.sh and give me the nvidia-bug-report.log that you will find in your current directory
[10:56] <Laney> okies
[10:57] <Laney> tseliot: http://people.canonical.com/~laney/temp/nvidia-bug-report.log.gz
[10:57] <Laney> let me know if I can restart
[10:58] <Laney> Don't know if you read earlier but this is me running canonical-x/x-staging in saucy
[11:04] <Laney> tseliot: I'm restarting now. Don't want to wait any longer :P.
[11:04] <tseliot> Laney: I think I have all I need, thanks
[11:05] <Laney> cool
[11:12] <mlankhorst> ugh
[11:12] <mlankhorst> a config file left behind by unity-system-compositor caused lightdm to fail here, I wanted to blame xorg for that :P
[11:13] <tseliot> oops, I thought I had removed nvidia-310 and 313...
[11:14] <Laney> mlankhorst: not unity-greeter?
[11:14] <mlankhorst> nah, a mir branch
[11:14] <Laney> ah
[11:19] <tseliot> Laney: did the problem happen after a suspend/resume cycle?
[11:19] <Laney> no, not that boot
[11:19] <Laney> I'd changed session a few times
[11:20] <Laney> If you see something about suspend in those logs that was from the previous boot
[11:21] <seb128> Laney, mlankhorst: the lightdm conf file might end up being problematic since those are in /etc they are going to be left over when the package is removed but not purged
[11:21] <tseliot> Laney: maybe use this as your /etc/X11/xorg.conf and try to reproduce the issue: http://paste.ubuntu.com/5801225/
[11:21] <Laney> I did think of that
[11:22] <Laney> I'd add the Depends and then rm_conffile it but ...
[11:30] <Laney> tseliot: doing
[11:32] <Laney> tseliot: ok, I changed session a load of times with that config and didn't see it
[11:32] <Laney> don't know what that says :-)
[11:33] <tseliot> Laney: I think we've worked around the issue for now. If you manage to reproduce it again in the future, just let me know ;)
[12:13] <mlankhorst> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/
[12:13]  * mlankhorst does ceremonial dance
[12:14] <Laney> very nice
[12:26] <tvoss_> didrocks, ping
[12:26] <didrocks> tvoss_: pong
[12:28] <tvoss_> didrocks, hey there, so for some weird reason, my icons are taken from the wrong icon theme in Unity
[12:28] <didrocks> tvoss_: do you have any ppa? changed anything in g-c-c?
[12:29] <didrocks> tvoss_: maybe check first your theme in gnome-control-center, appearance capplet
[12:29] <tvoss_> didrocks, I have the system-compositor ppa
[12:30] <didrocks> tvoss_: I doubt you have other things in it :) you do have gnome-settings-daemon started? the theme itself is right?
[12:31] <tvoss_> didrocks, gnome-settings-daemon is running
[12:31] <didrocks> tvoss_: so, check the selected theme in g-c-c
[12:31] <tvoss_> didrocks, switching to high-contrast works, selecting ambiance or radiance does not
[12:32] <tvoss_> didrocks, except for the window decorations
[12:32] <didrocks> tvoss_: what do you mean, it's following the theme?
[12:33] <tvoss_> didrocks, ambiance window decoration works, but not the gtk theme
[12:33] <didrocks> so the windows content is gnome vanilla one?
[12:33] <mitya57> tvoss_: does  python3 -c "from gi.repository import Gtk; print(Gtk.Settings.get_default().get_property('gtk-icon-theme-name'))"  print the correct name?
[12:33] <didrocks> in the look
[12:34] <didrocks> mitya57: it seems it's not only the icon theme from his description
[12:34] <tvoss_> mitya57, says gnome
[12:34] <seb128> tvoss_, do you use a config that breaks xsettings support?
[12:34] <seb128> tvoss_, like does xmir support xsettings?
[12:35] <tvoss_> seb128,it's a vanilla xserver in that respect
[12:35] <tvoss_> seb128, why do we need xsettings still btw? I thought we would have removed that?
[12:35] <tvoss_> at least for unity
[12:35] <seb128> tvoss_, well, gtk uses those for e.g the theme
[12:36] <tvoss_> seb128, how can I check if that is actually all working correctly?
[12:36]  * mitya57 has a script for getting raw xsettings values somewhere
[12:37] <seb128> tvoss_, I don't think there is an easy way or a tool for that, let's see if mitya57 find his script
[12:37] <seb128> tvoss_, gsettings get org.gnome.desktop.interface icon-theme
[12:37] <seb128> or gtk-theme
[12:37] <seb128> does that return the right values?
[12:38] <tvoss_> seb128, ubuntu-mono-light
[12:39] <seb128> k, so that part is correct
[12:41] <seb128> tvoss_, you are under GNOME right, not KDE (I saw you were playing with KDE earlier)
[12:41] <mitya57> Found: http://paste.ubuntu.com/5801381 — but's that's a very ugly code, and it uses python-xpyb
[12:41] <tvoss_> seb128, I'm running unity7 right now
[12:42] <seb128> tvoss_, the way things usually work under GNOME is that gnome-settings-daemon reads that key and set the xsettings to the same value as the key and gtk picks that xsettings
[12:42] <tvoss_> seb128, that sounds weird, to say the least, but okay
[12:42] <seb128> tvoss_, if you changed session, are you sure that you don't have a leftover settings daemon from e.g KDE that stopped gnome-settings-daemon to take the ownership of those settings?
[12:42] <seb128> that happens sometimes
[12:43] <seb128> there can be only one setting daemon at the time, so if one is running g-s-d will bail out
[12:43] <mitya57> On Wayland Gtk just uses GSettings directly, I think we can make it do the same on Mir
[12:43] <seb128> mitya57, that seems better than what was suggested on https://bugs.freedesktop.org/show_bug.cgi?id=49021
[12:44] <ubot2`> Freedesktop bug 49021 in wayland "Ideas: A wayland settings protocol to tell clients about themes, fonts, etc." [Enhancement,New]
[12:44] <tvoss_> seb128 difficult to check, let me see if I can just start afresh
[12:44] <mitya57> seb128: but that will be Gtk-specific
[12:44] <tvoss_> mitya57, having settings separate from the display server in the session sounds like a good idea
[12:58] <tvoss_> seb128, does not help
[12:58] <tvoss_> seb128, @reboot
[13:01] <tvoss_> Trevinho, ping
[13:03] <seb128> tvoss_, still broken?
[13:03] <tvoss_> seb128, yup
[13:03] <tvoss_> seb128, how can I force an icon and gtk theme in unity?
[13:04] <seb128> tvoss_, do you have a ~/.config/gtk-3.0/settings.ini
[13:04] <seb128> tvoss_, if so what does it contain?
[13:05] <tvoss_> seb128, nope, no such file
[13:07] <seb128> tvoss_, can you "strace -f gtk3-demo 2>&1 | grep /home/tvoss > log" and pastebin/copy online, I wonder if KDE wrote some sort of config somewhere
[13:07] <seb128> tvoss_, like a gtkrc or settings.ini
[13:08] <seb128> tvoss_, gtk3-demo or another gtk program (the smaller the better)
[13:08] <seb128> e.g if you try on gedit you will have more noise
[13:08] <tvoss_> seb128, gtk3-demo is not in my path
[13:08] <seb128> eog
[13:08] <seb128> gtk3-demo is in gtk-3-examples that we don't install by default
[13:09] <tvoss_> seb128, http://pastebin.ubuntu.com/
[13:10] <seb128> tvoss_, otherwise, to confirm ...
[13:10] <seb128> gsettings get org.gnome.desktop.interface gtk-theme
[13:10] <seb128> returns the right theme?
[13:10] <tvoss_> http://pastebin.ubuntu.com/5801440/
[13:10] <tvoss_> seb128, yup
[13:10] <seb128> and you have light-themes installed?
[13:10] <seb128> tvoss_, [pid  6684] access("/home/tvoss/.config/gtk-3.0/settings.ini", F_OK <unfinished ...>
[13:10] <seb128> tvoss_, what is in this file?
[13:11] <seb128> tvoss_, strace seems to disagree with you that it doesn't exist...
[13:11] <seb128> tvoss_, it would ENOENT otherwise
[13:12] <tvoss_> seb128, ls -lha does not show it ... hmmm, asks for an rm -rf :-)?
[13:12] <seb128> tvoss_, is your theme working in a guest session or with another user?
[13:12] <tvoss_> seb128, need to check
[13:13] <seb128> tvoss_, that strace also end up on ibus stuff, I wonder if ibus screw up things...but I guess you didn't change anything ibus related recently?
[13:14] <tvoss_> seb128, noope
[13:16] <seb128> tvoss_, I'm a bit puzzled at this point :/ would be useful to try with another user to see if that's an user config issue or a system issue
[13:16] <tvoss_> seb128, ack
[13:20] <Trevinho> tvoss_ pong
[13:20] <seb128> Trevinho, wait for him to be back ;-)
[13:21] <seb128> Trevinho, hey btw
[13:21] <Trevinho> seb128: ah, in fact my tab was not autcompleting him, :)
[13:21] <seb128> Trevinho, for a good reason :p
[13:22] <Trevinho> seb128: :) hi to you too ;)
[13:22]  * Trevinho does the "g++4.8 faster compilation" dance
[13:24] <seb128> tvoss, wb
[13:25] <seb128> tvoss, gtk IIRC should do "user config -> xsettings -> default config (/etc/gtk-3.0/settings.ini)"
[13:25] <Trevinho> tvoss: pong²
[13:26] <seb128> tvoss, if you get a wrong theme it would suggest either a broken config got written somewhere (but I can't find it in your strace, though the fact it don't ENOINT on that .config/gtk-3.0/settings.ini puzzles me) or that the xsettings is set to the wrong value
[13:27] <tvoss> seb128, copied the default setting to my user directory, and restarting my session :)
[13:28] <tvoss> seb128, no luck
[13:29] <seb128> shrug
[13:29] <seb128> did you try with another user?
[13:29] <tvoss> seb128, yup
[13:29] <seb128> does it work?
[13:30] <Trevinho> tvoss: did you ping me before about this icon issue?
[13:30] <tvoss> Trevinho, yup
[13:30] <Trevinho> tvoss: mh, ok so I re-read what has been said
[13:30] <seb128> Trevinho, if you have any clue what could be wrong there, please help, I'm running out of ideas
[13:31] <seb128> tvoss, can you do a strace again but without grep, or grep on "themes" ... I wonder what theme it goes to read
[13:32] <Trevinho> seb128: oh, that seems weird...
[13:32] <Trevinho> mhhm
[13:33] <Trevinho> seb128: I probably didn't read all, but is he having theme issues also with other launched applications (a part from unity)?
[13:34] <seb128> Trevinho, that's a good question, I assumed that the theme was wrong for the session, but maybe that's a wrong assumption...
[13:35] <Trevinho> seb128: it's probably like that as the apps launched from unity should still use the same env, but it also seems something wrong on our themes configurations
[13:43] <seb128> tvoss_, is your issue specific to unity or happening in gtk apps as well?
[13:43] <tvoss_> seb128, gtk apps in general
[13:44] <seb128> Trevinho, ^
[13:44] <Trevinho> seb128: ok, so at least it's not unity fault..
[13:46] <tvoss_> seb128, grepping for themes gives: http://pastebin.ubuntu.com/5801517/
[13:47] <didrocks> hey kenvandine! thanks for publishing webcreds :)
[13:48] <didrocks> kenvandine: can you have a look (maybe with cyphermox as well) to other stacks and why they are not publishing? I'm doing Mir and can't get to those, sil2100 is on holidays today
[13:48] <kenvandine> sure
[13:50] <didrocks> thanks!
[13:51] <kenvandine> apps was blocked by webcred, i published it
[13:52] <kenvandine> media broke because of a chroot problem, handling that now
[13:52] <kenvandine> cyphermox, can you look at indicators and qa?
[13:55] <seb128> tvoss_, Trevinho: I'm starting thinking it's a problem on the machine/disk ... I don't understand why the access() calls to user files don't return ENOENT if the files don't exist
[14:17]  * didrocks waves good evening, have to leave for an early appointment
[14:47] <desrt> seb128: greetings
[14:47] <seb128> desrt, hey
[14:47] <desrt> seb128: did you do your accountsservice upload yet?
[14:47] <seb128> desrt, no, still fighting with the update
[14:47] <seb128> I hate that piece of code :/
[14:47] <desrt> seb128: can you please toss those patches in?
[14:48] <seb128> if I ever manage to get the update right, sure
[14:48] <desrt> thanks
[14:48] <desrt> anything i can help with?
[14:48] <seb128> hate hate hate how they pile hacks on hacks to filter users out
[14:48] <seb128> https://bugs.freedesktop.org/show_bug.cgi?id=48178
[14:48] <desrt> ya.....
[14:48] <ubot2`> Freedesktop bug 48178 in general "Add some users to the default blacklist" [Normal,Resolved: fixed]
[14:49] <desrt> to be fair, this is unix...
[14:49] <seb128> I'm updating our patch to revert to the old "filter on uid ranges"
[14:49] <seb128> I'm not sure what was wrong with that
[14:49] <seb128> they have "is there a valid shell" + "is there a hash at the right format" + "is the user is in the list"
[14:49] <seb128> and they stuff is still not good enough, I guess stuff like CouchDb listed
[14:50] <seb128> or "backup"
[14:50] <seb128> or "www-data"
[14:50] <desrt> sigh.
[14:50] <seb128> or "(dirmngr)"
[14:50] <desrt> the password hash check tripped me up the other day
[14:50] <desrt> since it filters some real human users who exist but do not yet have a valid password set
[14:51] <desrt> sad truth is that unix makes it very hard to tell the difference between accounts belonging to real people and system accounts
[14:51] <desrt> i wonder if we could make some simplifying assumptions for debian....
[14:51] <desrt> like just split at 1000 and hardcode the nobody account
[14:53] <desrt> i can't think of any exceptions to that rule...
[14:54] <seb128> desrt, well, we are using the uid range in Ubuntu and Debian (e.g as defined in /etc/login.defs)
[14:54] <desrt> so why not use _only_ that?
[14:54] <desrt> ie: nuke all other checks
[14:55] <seb128> that's what we do, I just gave a try to the new upstream way
[14:55] <seb128> and I'm rebasing the patch, which is a bit of a pain because they refactored a bit
[14:55] <desrt> UID_MIN                  1000
[14:55] <desrt> UID_MAX                 60000
[14:55] <seb128> but I'm getting there
[14:55] <desrt> i like it!
[14:55] <desrt> even properly excludes the nobody account, this way
[14:55] <seb128> which is what upstream was doing before http://cgit.freedesktop.org/accountsservice/commit/?id=ffbd85a5baee93af150fd575a44e7a7d81a13958
[14:55] <seb128> I never got why they changed it
[15:23] <seb128> desrt, people.canonical.com/~seb128/2001-filtering_out_users.patch
[15:23] <seb128> desrt, that's our current patch, just rebased on 0.6.34
[15:23] <seb128> desrt, if that helps you as a base
[15:24] <desrt> seb128: may help a bit for login.defs parsing, thanks
[15:24] <seb128> yw
[15:27] <seb128> desrt, ok, I got my update working... what patch did you want me to cherrypick on top?
[15:27] <desrt> https://bugs.freedesktop.org/show_bug.cgi?id=63733
[15:27] <ubot2`> Freedesktop bug 63733 in general "add support for extension interfaces" [Enhancement,New]
[15:28] <desrt> there are three patches at the bottom
[15:28] <desrt> the last one is strictly documentation
[15:28] <desrt> but you need the two before (comments 8 and 9)
[15:28] <desrt> comment 10 has zero effect on the installed package, so i wouldn't bother
[15:28] <seb128> ok
[15:37] <cyphermox> kenvandine: poke
[15:37] <kenvandine> cyphermox, prod
[15:37] <cyphermox> kenvandine: just to ack, I am looking at indicators and QA
[15:37] <kenvandine> thx
[15:37] <cyphermox> kenvandine: however, shouldn't this just get ignored:
[15:37] <cyphermox> /var/log/upstart/otto-setup.log: E: The following additional packages will be installed:
[15:37] <cyphermox> /var/log/upstart/otto-setup.log: +libglib2.0-0
[15:37] <cyphermox> /var/log/upstart/otto-setup.log: +libglib2.0-bin
[15:37] <cyphermox> ^^ I'm sure we don't really want to add these packages to the package list for QA :D
[15:38] <kenvandine> i would think so
[15:38] <kenvandine> kind of core packages :)
[15:39] <cyphermox> yeah
[15:39] <cyphermox> going to take a good look, that shouldn't be happening
[15:40] <cyphermox> ah, same thing for qa and indicators
[15:52] <cyphermox> kenvandine: unity same issue btw
[15:52] <cyphermox> looks like they probably mostly all failed because this showed up in upgrade :(
[15:53] <kenvandine> i don't think that is why media failed
[15:53] <kenvandine> apps just got blocked on webcred
[15:53] <kenvandine> media is failing autopilot tests
[15:54] <cyphermox> aye
[15:54] <cyphermox> but any new tests today, if one of the packages require glib, will fail with the same result
[15:54] <cyphermox> perhaps this is the kind of thing that really ought to be special cased
[15:55] <cyphermox> the issue is that there was a new glib that was uploaded, and is now available in the archive, since the image that is used to build the vms that run the tests was created
[15:56] <cyphermox> so running the same tests tomorrow we'd be fine
[15:58] <seb128> mterry, miiiiiike
[15:59] <Laney> (he only loves you for your team membership. RESIST.)
[15:59] <mterry> seb128, heyo?
[16:00] <seb128> mterry, howdy ... do you have a minute to discuss you pin patch to accountsservice?
[16:00] <seb128> mterry, it makes things double free and get unhappy when you try changing an user password
[16:00] <seb128> (I first though it was my update that was screwed but it happens in saucy as well)
[16:00] <mterry> seb128, aw crap.  I ran with it for a while, thought it was OK
[16:00] <seb128> mterry, can you have a look to user.c?
[16:01] <seb128> user_set_password () does
[16:01] <seb128>         daemon_local_check_auth (user->daemon,
[16:01] <seb128> ...
[16:01] <mterry> seb128, if it it's causing immediate problems, you can undo the patch, nothing depends on it yet, while I fix
[16:01] <seb128>                                  user_change_password_authorized_cb,
[16:01] <seb128> ...
[16:01] <seb128>                                  (GDestroyNotify)free_passwords);
[16:01] <seb128>  
[16:01] <seb128> or user_change_password_authorized_cb() ends on
[16:01] <seb128>  out:
[16:01] <seb128>         g_free (password_hint);
[16:01] <seb128>         g_free (password);
[16:01] <seb128>  
[16:02] <seb128> mterry, I guess if (GDestroyNotify)free_passwords does the cleaning we don't need the 2 g_free calls
[16:02] <mterry> seb128, OK, will look.
[16:02] <seb128> mterry, I just want sanity check from somebody else, I'm not sure to understand that code well from a quick look
[16:02] <mterry> seb128, how are you reproducing?  Is there a bug for it?
[16:03] <seb128> mterry, reproduce -> run "gnome-control-center user-accounts", click "unlock", click a password field from any user (I picked test users, not mines), enter a password, confirm it, click "change"
[16:03] <seb128> -> double_free
[16:03] <cyphermox> kenvandine: ok, seems like we should probably be able to just rerun the tests and they should pass, at least for indicators
[16:03] <cyphermox> kenvandine: I'll rerun that now, so we can see if it fixes the issue
[16:04] <mterry> seb128, that does seem like a double free
[16:04] <seb128> mterry, well double free from accounts-daemon, g-c-c hangs
[16:04] <seb128> mterry, http://paste.ubuntu.com/5801893/
[16:05] <mterry> seb128, huh.  I feel like I tested that, but clearly not with final patch's code.
[16:05] <seb128> mterry, you can confirm the bug?
[16:05] <seb128> mterry, ok, dropping the 2 frees after the out: fixes it...
[16:06] <seb128> mterry, I'm happy to just sneak that in my upload if you +1 it (should I check the code for other problems?)
[16:06] <mterry> seb128, hm, I don't get freeze in gcc
[16:06] <mterry> i didn't open from console though, let me see what that says
[16:06] <seb128> mterry, well, sudo /usr/lib/accountsservice/accounts-daemon --replace and look at what happen on this time
[16:06] <seb128> mterry, g-c-c doesn't freeze every time for me
[16:07] <mterry> seb128, that function got some last minute changes, which were from me, not the original patch author.  So that was my fault.  If that work flow works well for you now, that should be a sufficient check
[16:07] <seb128> I guess it depends if the daemon breaks before sending a reply
[16:07] <mterry> seb128, yup, I see crash too
[16:08] <mterry> seb128, dropping the frees should fix it, yeah
[16:08] <mterry> seb128, thanks for the catch
[16:08] <seb128> mterry, yw, thanks for confirming ... doing that in my upload
[16:10] <seb128> mterry, I see that the original patch was calling g_variant_unref as GDestroyNotify
[16:10] <seb128> mterry, so just destroying the variant and letting the callback free the 2 gchar *
[16:10] <mterry> seb128, doesn't the unref happen naturally?
[16:11] <mterry> oh, because we pass it
[16:11] <mterry> seb128, yup.   Just removing the g_free after the out: label should be fine
[16:11] <seb128> mterry, yep, thanks again!
[16:11]  * seb128 is happy, g-c-c works 
[16:13] <seb128> hum, no
[16:17] <seb128> mterry, that patch is buggy :/ do you use it for anything atm?
[16:17] <seb128> mterry, it doesn't segfault anymore but it doesn't actually change the password either...
[16:18] <mterry> seb128, disable for now until I can fix it.  It seemed to be working for me a while ago, but clearly my last minute fixes broke things and I didn't properly test them
[16:51] <desrt> seb128: did you do the upload yet?
[16:51] <seb128> desrt, no
[16:52] <desrt> seb128: maybe interesting to try with my new patch instead....
[16:52] <seb128> desrt, I can do that ;-)
[16:53] <desrt> seb128: ah.  didn't notice you're not in #gnome-hackers
[16:53] <desrt> see here https://bugs.freedesktop.org/show_bug.cgi?id=66214
[16:53] <ubot2`> Freedesktop bug 66214 in general "Clean up user classification logic" [Normal,New]
[16:53] <seb128> desrt, thanks
[17:39] <seb128> mterry, ok, I did some debugging, it fails to change the passwd for other users than the current one
[17:39] <seb128> mterry, I don't think it's the most frequent usecase, will keep the patch enable
[17:40] <mterry> seb128, OK.  Assign a bug to me, I can look at it
[17:40] <mterry> seb128, thanks for debugging a bit
[17:40] <seb128> mterry, I might finish debugging it later since I started, it's a problem in the pam helper
[17:40] <seb128> mterry, yw
[17:40] <mterry> k
[17:40] <seb128> mterry, I will assign to you with details if I need to move to something else
[17:40]  * mterry can't wait  :)
[17:46] <seb128> desrt, your uid filtering patch works fine \o/
[17:46] <desrt> cool
[17:46] <desrt> so i guess we can carry this one now instead
[17:46] <desrt> and maybe drop it when it goes upstream (in one form or another)
[17:46] <seb128> right, I swapped them and did a package test build
[17:46] <seb128> keeping it this way
[17:46] <desrt> i nixed most of the old patch you sent me... the error checking was not very good :/
[17:46] <seb128> the old patch was the old upstream code
[17:47] <desrt> like... it searched for "UID_MIN" in the login.defs file
[17:47] <seb128> it was mostly a revert of their recent work
[17:47] <desrt> which would find "SYS_UID_MIN" if that happened to come first :p
[17:47] <seb128> glad you cleaned it then ;-)
[17:57] <seb128> desrt, btw you will need to rebase one of your patches on the other one :p
[17:58] <desrt> Makefile conflict?
[17:58] <seb128> daemon.c conflict
[17:58] <desrt> weird
[17:58] <seb128> in daemon_init()
[17:58] <desrt> can you clean it up for now?
[17:58] <seb128> but as Makefile.am as well
[17:58] <seb128> desrt, yeah, I did
[17:58] <desrt> thanks
[17:59] <seb128> they just change code in the same area, so you will need to rebase depending which one goes in first
[18:51] <kenvandine> larsu, gsettings-qt adding to daily-release and fginther is setting up jenkins for autolanding and CI
[18:52] <larsu> kenvandine: \o/
[18:52] <larsu> awesome
[18:53] <fginther> kenvandine, larsu, it's ready now
[18:53] <kenvandine> awesome
[18:54] <kenvandine> larsu, ok, as of now no more pushing to trunk :)
[18:54] <larsu> kenvandine: I'll try :P
[18:55] <kenvandine> :)
[18:55] <kenvandine> larsu, also... i hear you're the guy to talk to about lp:indicator-messages/phablet?
[18:55] <kenvandine> basically, the inline replies like we can do for SMS
[18:56] <kenvandine> i need to add those for facebook and stuff
[18:57] <larsu> kenvandine: yes, the phablet libmessagingmenu has special API for that (which I don't like btw)
[18:57] <larsu> I'll be working on consolidating the branches next week
[18:57] <larsu> can you wait tht long or are you blocked on it?
[18:57] <kenvandine> is there any docs or a good example i can look at?
[18:57] <kenvandine> well, i can wait
[18:57] <larsu> no, I made that pretty ad-hoc last year to have something for the phone demo
[18:57] <kenvandine> but i would like to start hacking on it
[18:57] <kenvandine> i need to make it work like the demo did :)
[18:58] <larsu> basically I sat next to the only user of it: boiko (he wrote the phone app)
[18:58] <larsu> I'm still considering to change the API a bit before merging it
[18:58] <kenvandine> so maybe next week when you refactor that a bit... you can sit (virtually) next to me as the next consumer of it?
[18:58] <larsu> haha sure :D
[18:59] <larsu> basically you can now create a MessagingMenu.Message (in addition to sources)
[18:59] <kenvandine> ok, i'll bug you about that next week
[18:59] <larsu> ok let's do that, thanks :)
[18:59] <kenvandine> i want to add the entry from a python process
[19:00] <kenvandine> or probably the service written in vala
[19:00] <kenvandine> but then do qml for the interaction stuff
[19:00] <larsu> both will work, it's fully gobject-introspection
[19:00] <kenvandine> does that require me creating a new widget?
[19:00] <larsu> but no qml api yet
[19:00] <kenvandine> how does phone-app do it?
[19:00] <larsu> no, you can't put widgets into the panel
[19:00] <larsu> it doesn't, there's only the one widget
[19:00] <kenvandine> ah
[19:00] <larsu> "hero item"
[19:01] <larsu> or some such
[19:01] <kenvandine> that item can work for me :)
[19:01] <kenvandine> same concept
[19:01] <kenvandine> if i can tell it to do something different with the message
[19:01] <larsu> basically it's an image, title, text, and optionally some buttons and/or reply field
[19:01] <larsu> ya, we don't want apps to put stuff into the panel process
[19:01] <larsu> but if you need something special, we might be able to add it to the existing widget
[19:02] <kenvandine> i just need it to call a function in libfriends or qml-friends to do the actual reply
[19:02] <kenvandine> does that require changing the widget?
[19:02] <larsu> no, the widget can handle replies
[19:02] <larsu> you'll get a callback with the string
[19:03] <kenvandine> cool!
[19:03] <kenvandine> basically i need to make it work the way the demo content did before :)
[19:03]  * larsu thinks kenvandine is just realizing how little work he has to do for that
[19:03]  * kenvandine hopes so
[19:04] <kenvandine> larsu, ok, i'll bug you about that next week :)
[19:04] <larsu> looking forward to it!?
[19:04] <larsu> :P
[19:25] <kenvandine> larsu, https://code.launchpad.net/~ken-vandine/gsettings-qt/depends_for_tests/+merge/171644
[19:26] <kenvandine> larsu, easy review to fix the build before tonight's daily release run :)
[19:29] <larsu> kenvandine: approved. Let's see if the auto merger works
[19:30] <kenvandine> :-D
[19:35] <kenvandine> Laney, i'm looking forward to seeing your background panel with gsettings merged :)
[19:35] <kenvandine> larsu, merged!
[19:36] <Laney> kenvandine: Yeah! It needs error handling and ideally to react to changes in the key (how do I do that with gsettings-qt) first though?
[19:36] <Laney> oh and I expect it doesn't work on the device
[19:39] <larsu> Laney: qml doesn't do bidirectional binding unfortunately. So you need to bind a function to onClicked and set the key from js
[19:39] <larsu> works as expected, settings.keyName = value;
[19:40] <Laney> larsu: Not that; a signal when something else changes the key
[19:40] <Laney> like changed
[19:40] <larsu> Laney: you don't need that, the key is changed and gsettings-qt uses qml's native notification stuff
[19:41] <larsu> Checkbox { checked: settings.something } will do the right thing
[19:41] <Laney> hmm, didn't work naively but I'll check it, thanks
[19:42] <larsu> maybe a bug? Let me know if you can't get it to work
[19:45] <mfisch> Can anyone point me to what respawns indicator-sound? Doesn't seem to be dbus or upstart
[19:46] <mfisch> I want to run my own copy but respawns before I can start my copy
[19:47] <kenvandine> mfisch, there is a trick to that :)
[19:47] <kenvandine> tedg, can you tell him the magic?
[19:47] <kenvandine> i forget :)
[19:47] <larsu> mfisch: export INDICATOR_SERVICE_REPLACE_MODE=1
[19:47] <tedg> mfisch, Yeah, it's the panel service itself.  No worries, we're fixing it :-)
[19:48] <mfisch> larsu/tedg: thanks
[20:40] <seb128_> mterry, you are still there?
[20:40] <mterry> seb128, yup!
[20:41] <mterry> :-/
[20:41] <seb128_> seb128_, sorry, I'm on some unstable internet line again, might drop and come back
[20:41] <seb128_> doh
[20:41] <seb128_> mterry, ^
[20:41] <mterry> :)
[20:41] <seb128> ;-)
[20:41] <seb128> mterry, so I figured out the issue with accountsservice
[20:41] <mterry> k
[20:42] <seb128> mterry, the accountsservice code handle crypt()ed passwords
[20:42] <seb128> mterry, which usermod -p <passwd> handle
[20:43] <seb128> mterry, the pam helper though is going the pam stack that asks for a real passwd
[20:43] <seb128> which the code give the crypt()ed passwd to
[20:43] <mterry> Oh, hrm
[20:43] <seb128> so you end up with e.g "$6$1MSCIhEv2SC3ZrPZ$tjfGY3J2HKhuZh6073510/ebmi3YWMhlBPF2hWVUfuaeSrMK5/bFdFX9pwz44M03uP3EdsH5mHBrlTzn/A9Oy/"
[20:43] <seb128> set as password
[20:44] <seb128> (I tried, it works for login ;-)
[20:44] <mterry> You mean the historical SetPassword dbus call takes a crypted pass?
[20:44] <mterry> hm
[20:44]  * mdeslaur quickly looks up seb128's password in rainbow table
[20:45] <mterry> seb128, so maybe the SetPassword handler needs to use pre-patch method of setting the password via usermod.  And let new dbus call continue to do its fancy pam magic...  But we need to make sure to clear any pin that was previously set
[20:45] <mterry> (when old SetPassword is used)
[20:48] <seb128_> grrrr flacky internet
[20:48] <seb128_> mterry, dunno if my reply went through
[20:48] <seb128_>  mterry, yeah, the real password is given to crypt() that usermod -p understand
[20:48] <seb128_>  mterry, it avoids having to deal with clear passwords
[20:48] <seb128_>  so accountsservice pass the encrypted version of the password around
[20:48] <seb128_> the pam helper goes through normal pam prompts and want a clear password though
[20:49] <mterry> seb128_, yup, makes sense.  when I added back the SetPassword handler, I missed that detail
[20:49] <mterry> seb128_, we can manually delete the pin file
[20:49] <mterry> to clear it
[20:49] <mterry> while doing old logic to set crypted pass
[20:49] <seb128> mterry, well, at this point I will let you sor tit
[20:49] <mterry> seb128, OK!
[20:49] <seb128> do you want a bug report?
[20:49] <mterry> seb128, sure
[20:49] <seb128> k
[20:49] <mterry> seb128, sorry for trouble, and thanks for debugging it that far
[20:49] <seb128> no worry
[20:50] <seb128> sorry for dropping it to you there, but I'm not familiar enough with this code to change the logic and I don't want to spend more time on it
[20:50] <seb128> I've already spent a couple of hours today on it
[20:50] <seb128> need to move back to system settings tomorrow
[20:55] <seb128> mterry, https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1195021
[20:55] <ubot2`> Ubuntu bug 1195021 in accountsservice (Ubuntu) "the pam password helper and accountsservice disagree on the password format in use" [Undecided,New]
[21:02] <mterry> seb128, thanks!
[21:22] <thumper> morning
[22:18] <davman> dsf