[09:40] <cpaelzer> of the ppc64el builders there are a few listed as cleaning for >10 hours https://launchpad.net/builders
[09:40] <cpaelzer> do those need a bump?
[09:48] <Laney> cpaelzer: I dunno what the threshold is, but that's usually a #launchpad question / action
[10:09] <cjwatson> cpaelzer: stabbing them
[10:09] <cjwatson> cpaelzer: but we have alerts for when it gets too bad anyway
[10:12] <rbasak> I'm basing some packaging on Focal so that it can be snapped with a core20 base. On the packaging end, I found that dh_bash-completion doesn't seem to use the dh sequencer, in Focal at least. Where should it sit in the sequence? Inserting it into override_dh_auto_install seems to work. Is that appropriate? Digging into a couple of existing source packages wasn't much help to me; I've not been able to
[10:12] <rbasak> find an example.
[10:24] <cpaelzer> rbasak: dh --with bash-completion $@ ?
[10:25] <cpaelzer> found in many packges, so it does not seem to be a one-off way to do it https://codesearch.debian.net/search?q=--with+bash-completion&literal=1
[10:25] <rbasak> That didn't work for me :-/
[10:25] <rbasak> I wondered if it was maybe post-Focal?
[10:26] <cpaelzer> The package I checked first started to use it in Fri Aug 21 12:18:36 2015 +0200
[10:26] <cpaelzer> which seems very much before focal to me
[10:26] <cpaelzer> was initramfs-tools
[10:26] <cpaelzer> not sure if this is a good example, it just was my first hit
[10:27] <rbasak> When I tried, various dh helpers were being called with (IIRC) -O--with-bash-completion or something like that
[10:27] <rbasak> But dh_bash-completion itself didn't get run
[10:27] <rbasak> Hmm
[10:27] <rbasak> Maybe I added a hyphen when I shouldn't have done
[10:28] <rbasak> --with-bash-completion
[10:28] <rbasak> I think maybe that was it
[10:28] <rbasak> Thanks :)
[10:28]  * rbasak tries
[10:28] <cpaelzer> let me know if it worked rbasak
[10:29] <cpaelzer> and thanks cjwatson for stabbing the ppc64 builders
[10:35] <rbasak> It did work cpaelzer, thanks!
[10:35] <rbasak>         dh $@ --with bash-completion,python3 --buildsystem=pybuild
[10:36] <cpaelzer> \o/
[10:36] <rbasak> It turns out that --with-bash-completion is wrong but silently accepted
[10:37]  * rbasak should have known better, but in his defence, it's been a while :)
[11:59] <Laney> seb128: slyon: I will add a hint for netplan.io now, but I would appreciate it if this regression could still be investigated, it might be finding a bug (at least a test bug) on ppc64el
[12:01] <seb128> Laney, thx!
[12:11] <Laney> Filed https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1916888
[13:01] <slyon> Thanks Laney, I'm currently working on a fix
[13:24] <Laney> slyon: toll!
[13:25] <slyon> ;D
[15:03] <seb128> are autopkgtests not being picked up today?
[15:03] <seb128> there doesn't seem to be a backlog on hirsute/i386 yet https://autopkgtest.ubuntu.com/packages/libt/libthai/hirsute/i386 hasn't picked the upload done this morning
[15:04] <seb128> ok, I just had to ask for it to show up on active list now...
[15:06] <seb128> hum,  not i386 though?
[15:11] <RikMills> seb128: 14:41:45+0000] - Requesting wikidiff2 autopkgtest on amd64 to verify libthai/0.1.28-3ubuntu1
[15:12] <RikMills> 14:41:45+0000] - Requesting libthai autopkgtest on i386 to verify libthai/0.1.28-3ubuntu1
[15:13] <RikMills> possible the are no no-mans-land of having just run, but not in results yet
[15:13] <JawnSmith> Is any core dev available to restart the samba autopkgtest that is blocking acl on s390x?
[15:15] <leftyfb> It seems the latest python2.7 deps for xenial are missing from the repo's. https://p.mort.coffee/OFSO
[15:15] <ginggs> JawnSmith: .
[15:17] <JawnSmith> ginggs: Thanks!
[15:17] <seb128> RikMills, thx, I always have difficulties to figure out the status of a request
[15:18] <RikMills> leftyfb: the update was only released 1 hr ago so could be slow mirror sync?
[15:18] <leftyfb> RikMills: https://launchpad.net/ubuntu/xenial/amd64/python2.7-minimal  looks like they were deleted?
[15:18] <Laney> seb128: it seems to be there now
[15:19] <Laney> the status is that it gets requested at the next proposed-migration run after it got built
[15:19] <Laney> if you just miss the previous one then it could be some time
[15:19] <seb128> seems the proposed-migrations have been taking 3h+ today
[15:19] <Laney> not just today
[15:19] <seb128> :(
[15:19] <Laney> rbalin_t is working on a speedup there
[15:19] <seb128> great
[15:19] <RikMills> leftyfb: 'broken security update' lovely!
[15:20] <leftyfb> RikMills: can we get the index updated so people's updates and build farms aren't broken while it's being resolved?
[15:21] <RikMills> cjwatson: ^ ?
[15:22] <Laney> leftyfb: there's not really a distinction; reverting the security update will make that happen automatically and as fast as possible
[15:22] <leftyfb> Laney: over an hour from the update being deleted?
[15:23] <Laney> I don't know when it was deleted, but deleting it causes the indexes to be republished and it can't be done as a separate step, that's all I'm saying
[15:25] <leftyfb> Laney: according to the link I posted above, they were deleted at 9:10AM EST.
[15:26] <leftyfb> Laney: if the indexs take an over an hour to get republished, then it would be nice to get confirmation on that. Otherwise, something as part of that process seems to be broken currently and should be addressed
[15:31] <cjwatson> I'm working on it, leave me to it please
[15:32] <cjwatson> The trade-off here is that some temporary index breakage is better than having people install a broken update
[15:32] <RikMills> ok. sorry to bother you
[15:32] <RikMills> ^ leftyfb
[15:32] <cjwatson> But it's underway
[15:33]  * RikMills goes back to pondering flatpak tests
[15:34] <ogra> package them as a snap 😉
[15:35] <RikMills> eep!
[15:38] <leftyfb> thank you folks. Sorry to bother, but I saw the reports coming from multiple communities all at once, figured it was about to blow up
[15:58] <cjwatson> leftyfb: indexes should be updated now, subject to mirror propagation times
[16:00] <cjwatson> Just checked all of {xenial,bionic}-{security,updates} on archive.ubuntu.com from outside the datacentre and they look right
[16:03] <cjwatson> Apologies for the disruption
[16:05] <leftyfb> cjwatson: out of curiosity, was there an issue with the updated indexes or do they actually take over an hour to update?
[16:05] <cjwatson> leftyfb: There was an issue because of some unfortunate timing
[16:05] <leftyfb> cjwatson: cool. Thanks for the immediate attention and quick fix
[16:06] <cjwatson> leftyfb: We deleted the broken update from -security quite quickly, but there's a cron job that propagates security updates to -updates and that interfered unexpectedly, which meant everything took longer; we temporarily shut down mirror triggering to minimize the risk of the broken update being re-published while we sorted all that out
[16:07] <cjwatson> (since a broken python2.7 could cause quite a lot of chaos)
[16:07] <leftyfb> ah, that makes sense
[16:07] <Slashman> cjwatson: thanks for the update, do you have an ETA?
[16:08] <leftyfb> Slashman: the main repos have been resolved.
[16:08] <cjwatson> Slashman: at least archive.ubuntu.com already looks fixed, so my ETA is negative :_)
[16:09] <Slashman> hm, I still have the issue on "security.ubuntu.com" 2001:67c:1562::15
[16:09] <cjwatson> let me check that
[16:10] <cjwatson> while I do, can you confirm that you've done an apt update very recently?
[16:10] <Slashman> yes, I'm actully trying to do a "do-release-upgrade" from 16.04 to 18.04
[16:11] <Slashman> I'll try to force Ipv4 usage, maybe "security.ubuntu.com" will then be resolved to a different server
[16:11] <cjwatson> 2001:67c:1562::15 looks right to me
[16:12] <cjwatson> oh wait, maybe not
[16:12] <Slashman> https://paste.ubuntu.com/p/9s4cfDW3Fz/
[16:13] <cjwatson> getting our sysadmins to check mirroring there now
[16:13] <Slashman> seems to work over IPv4
[16:13] <cjwatson> I doubt IPv4/v6 is the issue, more likely inconsistent state across multiple machines
[16:13] <cjwatson> or conceivably an HTTP proxy in the way
[16:13] <Slashman> I guess so, but switching to IPv4 may have switched machine
[16:14] <cjwatson> indeed
[16:15] <Slashman> at least I'm not stuck anymore, thanks!
[16:15] <cjwatson> I think you may just have caught it in the middle of a somewhat late update
[16:15] <cjwatson> that machine looks fine now
[16:15] <cjwatson> but we're checking others
[16:16] <seb128> hum<EMAIL_ADDRESS>[16:16] <seb128> autopkgtest [14:06:42]: test unittest.sh: [-----------------------
[16:16] <seb128> make: i686-linux-gnu-gcc: No such file or directory
[16:16] <seb128> i686-linux-gnu-gcc    -c -o parseargs.o parseargs.c
[16:16] <Slashman> thank you for your hard work
[16:16] <seb128> should i686-linux-gnu-gcc be available as a command?
[16:16] <cjwatson> $ for x in <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS>; do curl -s --resolve "security.ubuntu.com:$x:80" http://security.ubuntu.com/ubuntu/dists/bionic-security/main/binary-amd64/Packages.gz | zcat | grep-dctrl -nsVersion -XP python2.7; done
[16:16] <cjwatson> $ for x in 2001:67c:1562::15 2001:67c:1360:8001::23 2001:67c:1360:8001::24 2001:67c:1562::18; do curl -s --resolve "security.ubuntu.com:[$x]:80" http://security.ubuntu.com/ubuntu/dists/bionic-security/main/binary-amd64/Packages.gz | zcat | grep-dctrl -nsVersion -XP python2.7; done
[16:17] <cjwatson> both of those show 2.7.17-1~18.04ubuntu1.2 across the board
[16:17] <cjwatson> it's always much rougher when we have to abruptly go backwards, we don't do it very often
[16:20] <sdeziel> when I run those for loops, I see both 2.7.17-1~18.04ubuntu1.2 and 1.3
[16:20] <cjwatson> sdeziel: is there an HTTP proxy between you and security.u.c?
[16:20] <sdeziel> cjwatson: no
[16:21] <cjwatson> oh, but *I* have an HTTP proxy in the way
[16:21] <cjwatson> *facepalm*
[16:21] <cjwatson> yes, I see it now
[16:26] <sdeziel> shows all 1.2 now
[16:31] <cjwatson> Yep, I think everything has caught up now and I've unconfused myself about how I was holding curl wrongly
[16:31] <cjwatson> (everything on security.u.c anyway)
[16:34] <cjwatson> and archive.u.c
[16:41] <sdeziel> thanks (TIL about curl's --resolve feature so thanks!)
[16:42] <cjwatson> It's very handy, but I was running it on an old machine which was lacking some features
[16:42] <cjwatson> Especially re v6
[16:49] <stgraber> ah yeah, I love --resolve, been using it quite heavily when you want to check that all servers in a RR setup are up to date
[20:26] <seb128> vorlon, hey, I tried your suggestion for libinih but it failed<EMAIL_ADDRESS>... I'm unsure to understand why because the same gcc variant seems to work for other packages, do you have any idea maybe?
[20:26] <seb128> make: i686-linux-gnu-gcc: No such file or directory
[21:50] <vorlon> seb128: hmmm doh, I actually reproduced that locally but assumed it was an error in my setup.  I don't know what's different about libinih debian/test/control that's causing the cross-detection to fail and not pull in crossbuild-essential-i386
[21:51] <vorlon> seb128: it's *supposed* to get pulled in whenever @builddeps@ is listed in debian/tests/control, and we are doing a cross-test
[21:56] <vorlon> seb128: ah - apparently what I implemented pulls in crossbuild-essential-i386 only if 'build-essential' is explicitly listed as a test dep; this seems to be a bug in my autopkgtest implementation, since @builddeps@ does imply build-essential:native but does not cause crossbuild-essential-i386 to be pulled in
[21:57] <vorlon> seb128: so, can be worked around by adding build-essential to the test deps, but ultimately I should fix the autopkgtest implementation
[22:09] <seb128> vorlon, thanks!


[06:22] <didrocks> good morning
[06:49] <pitti> Good morning
[06:52] <didrocks> hey pitti, how was FOSDEM?
[06:56] <robru> pitti, didrocks: good evening! ;-)
[06:57] <didrocks> robru: hey! how are you? :)
[06:57] <pitti> didrocks: I met quite a few of the GNOME guys again, and also, surprisingly, mdz
[06:57] <robru> didrocks, not bad... you?
[06:57] <didrocks> pitti: oh nice! :)
[06:57] <didrocks> robru: I'm good, muscles are painful, and a week of emails backlog, but good otherwise! :)
[06:57] <robru> didrocks, oh yes! how was skiing?
[06:57] <didrocks> robru: before you're going to a well deserve bed, do you have time to discuss about two things?
[06:57] <pitti> didrocks: ^ good to hear!
[06:58] <pitti> didrocks: did you get your brain to "switch off" and relax a bit?
[06:58] <robru> didrocks, I always have time to discuss things ;-)
[06:58] <pitti> hey robru
[06:58] <didrocks> robru: was excellent! the weather wasn't that great, but we had all kind of snow
[06:58] <didrocks> fresh
[06:58] <didrocks> hard
[06:58] <didrocks> :)
[06:58] <didrocks> pitti: yeah, this time, really succeed in doing it :)
[06:58] <didrocks> thanks ;)
[06:58] <didrocks> robru: so, two things:
[06:58] <didrocks> - libunity-webapps FTBFS apparently in the latest daily
[06:59] <didrocks> (on all archs)
[06:59] <didrocks> is it known and upstream pinged about it? (not sure if it happened just this week-end)
[06:59] <didrocks> not at that level of emails yet :)
[06:59] <didrocks> - was there any progress on the webcredentials integration tests?
[06:59] <robru> didrocks, ah yeah, I just saw those emails. frankly I wasn't aware that I was responsible for libunity-webapps ;-)
[06:59] <didrocks> robru: webcreds and webapps stack are for you and ken :)
[07:00] <robru> didrocks, yeah, but so many packages, I can't remember all their names ;-)
[07:00] <didrocks> robru: you can look at the stack view FYI for that: https://jenkins.qa.ubuntu.com/view/cu2d/view/WebApps%20Head/
[07:01] <didrocks> (see the build step failed because of libunity-webapps)
[07:03] <didrocks> robru: ok, I'll take care of pinging them today so that it's fixed, just keep an eye on that in the future
[07:03] <didrocks> robru: on the webcred tests? :)
[07:03] <robru> didrocks, ok, I guess I will ping #webapps in the morning. I am not really familiar with this error in the FTBFS log
[07:04] <robru> didrocks, no, haven't heard anything about those tests unfortunately. Last time I assigned them a bug saying "please write a test suite", all I got out of it was that they started running xmllint on it, then they closed the bug as fixed :-/
[07:05] <didrocks> robru: thanks for looking, for the integration tests, we had an agreement with them to write them, you need to push/track them FYI to do it
[07:05] <didrocks> robru: do you need any help? that can wait for your morning to make things clear
[07:05] <robru> didrocks, yeah, maybe if you could write up a longer email with a bit more details, I'll find it in the morning ;-)
[07:05] <didrocks> robru: but you really need to push them, otherwise, that's violating our release criterias and we can't release packages to ubuntu
[07:06] <didrocks> robru: write up about what? We just agreed that we will have by this week some integration tests to run with autopilot :)
[07:06] <didrocks> robru: let's chat about this with them in your morning
[07:07] <robru> didrocks, so ken and I had started this wiki page to track the progress of which packages have tests and so on... it may be slightly out of date by now: https://wiki.ubuntu.com/WebApps/Packages if you have a minute, can you maybe confirm which ones are missing? or is that my job? ;-)
[07:07] <didrocks> robru: you mean packages? IIRC, ken sent the list of all packages after UDS :)
[07:08] <didrocks> the list sounds good though, but yeah, libunity-webapps is missing
[07:08] <didrocks> robru: just to be clear, you need to lead them to write tests, telling them we can't release in ubuntu if it doesn't met your quality criterias
[07:08] <didrocks> (and you don't have to write them yourself)
[07:09] <didrocks> sorry if I wasn't clear when telling what our subteam is supposed to do :)
[07:09] <robru> didrocks, no, I know, I couldn't do it even if I wanted to because I have very little insight into each of these codebases... ;-)
[07:09] <didrocks> so a little bit less friends hacking, more on tracking upstream :)
[07:09] <robru> didrocks, oh, but friends is so close to done! we need to finish this week ;-)
[07:09] <didrocks> robru: we are really late on what I planned for autolanding on webapps and wecreds, I hope we can get back on track though :/
[07:10] <robru> didrocks, ok
[07:10] <didrocks> thanks robru :)
[07:15] <robru> pitti, did you get a chance to look at that dbus async callback code I sent you? or did I overwhelm you with undocumented code? ;-)
[07:17] <pitti> robru: I just didn't get to that yet; last week was the sprint, this weekend FOSDEM, now I need to catch up with stuff
[07:17] <robru> pitti, haha, ok. I suspect dbusmock doesn't fit my needs in this case anyway; so it's not a high priority for you to look at if you're busy.
[07:19] <robru> pitti, so far what I've done is to literally copy & paste the dbus interface definition into a new class, but then replace the method bodies with stub code that doesn't do anything. then I wrote a nice little test case that imports both the real and the fake dbus interfaces and compares them to make sure both that the same methods are present, and that the methods have the same call signatures. so that way we can be confident that
[07:19] <robru> our mocked dbus API is identical to the real one. and it works great, callbacks and all.
[07:31] <pitti> robru: right, that sounds fine; as I said, you can define mocked methods in the normal Python way, and do anything you like there
[07:31] <pitti> robru: AddMethod() is more or less just a convenience, and adds logging
[07:31] <pitti> but if you don't need logging, or call it yourself, defining methods on your own is fine
[07:32] <robru> pitti, yeah, but the added methods don't support async callbacks as far as I can see. what I meant was that I stopped using dbusmock entirely, and simply defined a whole new class that defines the same dbus API that I'm trying to test against, but does so in a way that is more complete than dbusmock is able to achieve.
[07:33] <pitti> robru: hm, that's odd; if python-dbus supports async callbacks, so should dbusmock; it's just an autogenerated python-dbus server, after all
[07:33] <pitti> robru: but anyway, if you found something that works for you, great!
[07:33] <pitti> robru: I'll get to your mail, to see the details
[07:34] <robru> pitti, yeah, no worries. like I said, low priority.
[07:34] <robru> just happened to be on my mind tonight ;-)
[08:37] <Laney> hey
[08:38] <didrocks> hey Laney, how are you?
[08:40] <Laney> didrocks: good thank you, and yourself?
[08:40] <didrocks> I'm great, thanks!
[08:41] <Laney> \o/
[08:42] <Laney> hope you had a relaxing week off
[08:44] <didrocks> Laney: yeah, was really great! bad weather, but I tested all kind of snow state :)
[08:44] <Laney> great
[08:44] <Laney> I should try skiing one day
[08:44] <didrocks> it's really changing your normal environment, great for cutting mentally from work :)
[08:45] <robru> didrocks, don't you do enough testing at work? ;-)
[08:45] <didrocks> robru: ahah, I needed to apply tests everywhere! :-)
[08:45] <didrocks> just fall down once in a week, so I didn't taste the snow that much :-)
[08:46] <robru> didrocks, so just now I wrote some basic QML app. nothing exciting, just a button that changes color when you click it. but i'm impressed with qml overall. can't wait to start seeing qml apps that are so awesome that I would install and run them as desktop apps ;-)
[08:47] <didrocks> robru: yeah, I can't wait for it too! :-) A lot has to be done in layouting and resolution independance, but it's quite exciting!
[08:48] <robru> didrocks, what's wrong with resolution independance? The currency conversion tutorial already explained "units.gu" gives you device-independant pixel sizes ;-
[08:48] <robru> ;-)
[08:48] <didrocks> robru: you mean, the one built as part of ubuntu sdk? :)
[08:48] <didrocks> robru: I'm sure we'll have issue with retina-like display and so on :)
[08:49] <didrocks> new challenges :)
[08:49] <robru> didrocks, http://developer.ubuntu.com/api/ubuntu-12.10/qml/mobile/resolution-independence.html they talk about retina displays... the only challenge it seems is if your app uses bitmaps.
[08:49] <robru> all icons should be vectors anyway. so problem solved ;-)
[08:50] <didrocks> robru: oh nice, I looked at an earlier version when the conversion wasn't supporting this
[08:51] <didrocks> robru: oh, not related, did you have any questions on the daily landing that you noted as I asked for? I want to wrap up the blog post serie with a FAQ
[08:51] <robru> didrocks, oh god... ;-) I am really overwhelmed with that jenkins stuff. so many layers upon layers of pages on that site. unfortunately I can't think of any single question...
[08:52] <didrocks> robru: where my blog post serie clear enough?
[08:52] <robru> didrocks, yeah, what you did say was clear. but the jenkins website is just like this endless maze... most of the time I can't find the pages that you screenshotted in your blog post.
[08:53] <didrocks> robru: I tried to give links though, if any are missing, just ping me :)
[08:53] <robru> didrocks, ok.
[08:54] <robru> didrocks, I'll have to review it and get back to you... but it's too late for work right now, I am just surfing reddit ;-)
[08:55] <didrocks> robru: heh, indeed ;) I hope we can sync back tomorrow on the webcreds integration tests ;)
[08:56] <robru> yeah.
[08:56] <seb128> hey desktopers
[08:57] <didrocks> salut seb128
[08:57] <seb128> didrocks, lut, welcome back!
[08:58] <didrocks> thanks a lot :-)
[08:59] <robru> hey seb128
[08:59] <robru> good weekend?
[09:00] <seb128> robru, hey, excellent thanks, you?
[09:00] <robru> seb128, not bad... got some work done... ;-)
[09:01] <seb128> robru, that's not what the w.e is for :p
[09:01] <robru> seb128, but I love my work so much ;-)
[09:01] <seb128> hehe, I know what you mean ;-)
[09:02] <robru> seb128, but that's not all I did. gf and I went on a double-date with another couple. that was nice.
[09:02] <pitti> bonjour seb128! ça va?
[09:02] <seb128> robru, great ;-)
[09:03] <seb128> pitti, salut, ca va bien, et toi ?
[09:03] <seb128> pitti, comment était le fosdem ?
[09:03] <pitti> seb128: je vais bien! mon premiér FOSDEM était bon
[09:04] <pitti> seb128: j'ai recontré beaucoup de amis, comme desrt, mdz, ou mbiebl
[09:05] <seb128> pitti, ah, même mdz ?
[09:06] <pitti> seb128: les présentations étaient intéressantes aussi, mais recontrer des personnes est plus important
[09:06] <seb128> oui
[09:06] <seb128> trop de monde au fosdem
[09:06] <pitti> seb128: oui, c'etait une grande surprise
[09:06] <seb128> tu peux pas passer des heures avec tout le monde
[09:55] <chrisccoulson> good morning everyone
[10:01] <Laney> is there a gsettings key or something that enables/disables nautilus background rendering or some way a user might have disabled it?
[10:01] <Laney> someone in #ubuntu-uk just reported no background on raring and re-enabling the gsd plugin got it back
[10:01] <seb128> chrisccoulson, hey, had a good w.e ?
[10:01] <seb128> Laney, what session is that?
[10:01] <chrisccoulson> seb128, yeah, not too bad thanks. how about you?
[10:02] <seb128> chrisccoulson, good, thank you ;-)
[10:02] <Laney> he said it happened on unity and shell
[10:02] <seb128> Laney, did he turn off nautilus' handling of the desktop?
[10:02] <Laney> i don't know, that's my question
[10:02] <Laney> how do you do that ;-)
[10:02] <mlankhorst> morning
[10:02]  * mlankhorst is in no way hangover
[10:03] <mlankhorst> Obviously!
[10:03] <SuperMatt> hihi
[10:03] <Laney> seb128: SuperMatt is the guy who had the issue
[10:03] <SuperMatt> o/
[10:04] <seb128> SuperMatt, hey
[10:05] <SuperMatt> hullo
[10:06] <seb128> SuperMatt, 30s I'm checking something
[10:07] <SuperMatt> righto
[10:07] <seb128> SuperMatt, do you have ubuntu-gnome-default-settings installed?
[10:07] <SuperMatt> good question
[10:08] <SuperMatt> no, it seems I do not
[10:08] <seb128> ok, so that's not it
[10:08] <SuperMatt> cool
[10:08] <seb128> SuperMatt, do you have a nautilus*desktop in ~/.local/share/applications?
[10:08] <mlankhorst> in autopkgtest, what should happen if the sole purpose of a package is being the testsuite, like xorg-integration-tests or piglit?
[10:09] <SuperMatt> nope
[10:10] <seb128> SuperMatt, gsettuings get org.gnome.desktop.background draw-background
[10:11] <SuperMatt> true
[10:11] <Laney> aha
[10:11] <Laney> try that but with show-desktop-icons
[10:11] <SuperMatt> false
[10:11]  * Laney nods
[10:11] <Laney> set it to true and the other key I asked you to change back to false please
[10:12] <Laney> just to check
[10:12] <Laney> AutostartCondition=GSettings org.gnome.desktop.background show-desktop-icons
[10:12] <SuperMatt> where do I jam that?
[10:12] <seb128> gsettings set org.gnome.desktop.background show-desktop-icons true
[10:12] <Laney> I was just pasting that for evidence
[10:13] <SuperMatt> ok
[10:13] <Laney> and gsettings set org.gnome.settings-daemon.plugins.background active false
[10:13] <seb128> that one doesn't matter much
[10:13] <seb128> we turned g-s-d background off by default
[10:13] <Laney> I got him to set it true in #-uk
[10:13] <seb128> which is likely to bite users who turned nautilus icons drawing off
[10:13] <seb128> ok
[10:14] <Laney> should we get rid of that condition?
[10:14] <SuperMatt> ok, I have icons on, and draw background off
[10:14] <SuperMatt> log out and back in again?
[10:14] <seb128> SuperMatt, either that or just nautilus --quit and restart nautilus
[10:15] <Laney> anyway I reproduced that here
[10:15] <SuperMatt> well my background is still there
[10:15] <seb128> well, that's expected, if nothing draws the background it will be empty
[10:15] <Laney> you'll have to log out to restart gsd and get the plugin disabled
[10:15] <SuperMatt> lemme log out and back in again
[10:16] <SuperMatt> I still has background!
[10:16] <seb128> good
[10:16] <SuperMatt> so I need to have my desktop icons
[10:17] <seb128> so either you or a package you installed desactivated desktop icons
[10:17] <SuperMatt> which is OK, I'll just move stuff
[10:17] <seb128> well, you don't
[10:17] <seb128> the idea is that if you know enough to go in gsettings turn off desktop icons you can turn on g-s-d background rendering in there as well
[10:17] <SuperMatt> I see
[10:17] <seb128> we just turned off a feature that was duplicated and using resources for no good reason for most users
[10:18] <SuperMatt> gotcha
[10:18] <Laney> well, I don't think you'd know that the two features were linked
[10:18] <Laney> it's called "show-desktop-icons" not "handle-desktop"
[10:19] <SuperMatt> mmhmm
[10:19] <SuperMatt> thanks for the help guys
[10:19] <Laney> np
[10:20] <seb128> Laney, I wonder if we should rather check for draw-background
[10:20] <seb128> in the .desktop
[10:20] <Laney> seems to make sense
[10:20] <seb128> SuperMatt, yw, sorry that the change bite you
[10:21] <SuperMatt> I might stay around in this channel, I normally run +1 on multiple machines with different setups, so I normally come across problems pretty quickly
[10:21] <seb128> SuperMatt, feel free, this channel tends to be a friendly place ;-)
[10:21] <SuperMatt> cool cool
[10:22]  * Laney recruits SuperMatt for some packaging
[10:22] <SuperMatt> I would *love* to get involved more
[10:22] <seb128> Laney, he said yes, he said yes, don't let him run away! :p
[10:22] <Laney> muhahaha
[10:22] <Laney> well, here's one fix to get started with ;-)
[10:23] <SuperMatt> o_O
[10:23] <Laney> nah I'll fix that in bzr now
[10:24] <SuperMatt> I can only do stuff in evenings, mind :P
[10:24] <SuperMatt> now if you'll excuse me, I need to stare at a client email to try to work out what they want from me
[10:24] <Laney> slow git.g.o is slow
[10:47] <Laney> I can't see that draw-background actually does anything
[10:53] <seb128> Laney, I think we did check for the icon one for a reason... ;-)
[10:54] <Laney> seems so :P
[10:54] <bdrung> tjaalton: libgtk-3-0 -> libxkbcommon -> xkb-data
[10:54] <bdrung> now i can install libgtk-3-0:i386 again
[11:00] <Laney> ah, it is marked as deprecated in gsettings-desktop-schemas git
[11:29] <tkamppeter> pitti, hi
[11:30] <davmor2> hey guys I have the sync menu in place on first opening it, it the edge was off the screen is there some sort of detection that should happen?
[11:30] <seb128> it's an unity bug, not specific to that menu
[11:31] <seb128> sometimes it gets the placement wrong when the menu geometry changes when the menu is opening
[11:31] <davmor2> seb128: thanks
[12:47] <seb128> pitti, hey
[12:48] <seb128> pitti, so I want to look at updating gtk to the new serie ... do you know if there is a way I can get all our autopkgtests, from gtk users, run against a candidate version if I put it in a ppa?
[12:48] <pitti> seb128: quoi de neuf?
[12:48] <pitti> seb128: ah, I'm glad you asked
[12:48] <seb128> ;-)
[12:48] <pitti> seb128: jibel and I recently discussed running our autopkgtests against PPAs, for exactly those purposes
[12:49] <seb128> great
[12:49] <seb128> I want to avoid having some unity test failing because I upload GTK, otherwise didrocks will (rightfully) hunt me down
[12:49] <pitti> seb128: we do it for, I think, the mozilla PPA, but we can certainly enable it for the ~ubuntu-desktop PPA as well; jibel, que penses-tu?
[12:50] <pitti> seb128: what I did so far was to upload it to -proposed and ask Laney, infinity, cjwatson or another ~u-release member to put a block on it
[12:50] <pitti> then wait/fix until every was green
[12:50] <pitti> and in the worst case we can remove it from -proposed again
[12:50] <Laney> what does that do to versioning?
[12:51] <seb128> pitti, can I reupload a 3.6 something to proposed ever if we do that?
[12:51] <pitti> seb128: except that unity doesn't have autopkgtests
[12:51] <Laney> does launchpad forget that it's seen a higher one so you can continue with the normal scheme?
[12:51] <seb128> if 3.7 turns out to be a fail
[12:51] <pitti> Laney, seb128: you can't upload that same version again
[12:51] <pitti> but you can upload a lower version; assuming that nobody actually _uses_ proposed in apt
[12:51] <pitti> (if you do, you really get to keep both halves)
[12:51] <seb128> will launchpad accept versions to go backward?
[12:51] <pitti> yes
[12:52] <seb128> hum, k
[12:52] <pitti> well, if it got removed from the pocket in between
[12:52] <pitti> (which we would)
[12:52] <seb128> it feels like a stretched proposed use though
[12:52] <pitti> yes, I agree
[12:52] <pitti> using a PPA would be better
[12:52] <seb128> I think I will work on the update, put it in the desktop team ppa
[12:52] <chrisccoulson> seb128, we run autopkgtests from my PPA's already :P
[12:52] <pitti> seb128: but still, as unity doesn't have autopkgtest that still wouldn't quite do what you want
[12:52] <seb128> then ping you guys to see what sort of testing we can get for it
[12:53] <chrisccoulson> oh, pitti already mentioned that ;)
[12:53] <seb128> pitti, well, I wanted extra testing, having the autopkgtests run will be a first good step
[12:53] <seb128> then I will need to talk to Didier about how we get unity testsuit run with that new gtk
[12:53] <pitti> seb128: yeah, so I say, put it into the u-desktop PPA and we'll ask jibel to add that
[12:54] <seb128> pitti, sounds like a plan, danke! ;-)
[13:05] <seb128> ricotz, ^ btw
[13:05] <seb128> pitti, ok, so apparently they broke theming again, *shrug*
[13:06] <jibel> seb128, as pitti said it's what we do for firefox trunk. The main difference with autopkgtest against -proposed is that PPAs are added manually.
[13:06] <jibel> seb128, So give me the names of the PPAs and packages in these PPAs you want to run autopkgtest against and I'll add them.
[13:06] <ricotz> seb128, what am i looking at?
[13:07] <seb128> jibel, ok, thanks
[13:07] <seb128> ricotz, discussion about updating GTK in raring :p
[13:07] <ricotz> seb128, ah ok ;)
[13:10] <seb128> ricotz, but seeing that you just mentioned it breaks themes I'm less sure about it
[13:17] <ricotz> seb128, maybe Cimi can fix it fast ;)
[13:17] <seb128> yeah
[13:17] <seb128> ricotz, so you haven't been running the new gtk?
[13:17] <seb128> ricotz, do you know how is the feedback from the new pango from people running it?
[13:18] <ricotz> seb128, i am using Adwaita
[13:18] <seb128> oh ok, makes sense ;-)
[13:18] <ricotz> seb128, everybody who is using gnome3-staging will get the new pango
[13:19] <ricotz> seb128, and yea, of course i am running the git snapshot myself here ;)
[13:19] <seb128> did you get any feedback from bugs or regressions from the new version?
[13:19] <ricotz> seb128, the only thing was the inkscape freeze reported to me, which got fixed upstream
[13:20] <seb128> ok
[13:20] <ricotz> seb128, a greater installation-issue is the missing multiarch support of graphite2
[13:20] <seb128> shrug, so to update gtk we will need to: fix our themes, get harfbuzz MIRed/promoted, update pango, then update gtk
[13:21] <cyphermox> good morning!
[13:21] <ricotz> which debian added as depend and breaks the multiarch install of harfbuzz
[13:21] <ricotz> seb128, yes, and atk and gdk-pixbuf
[13:21] <cyphermox> hey ricotz; btw, for NM it's in progress -- just needs to go through my usual local 1 week of testing as I get things up to date ;)
[13:22] <cyphermox> I'll be ready to upload later today after i fix up nm-applet
[13:22] <ricotz> cyphermox, great, is it a snapshot or the <IP_ADDRESS>5 release?
[13:22] <cyphermox> yeah
[13:22] <cyphermox> just past <IP_ADDRESS>5
[13:22] <cyphermox> we're about to release 0.9.8 too
[13:22] <ricotz> ok
[13:22] <cyphermox> 0.9.8 is what we'll ship in raring, I think
[13:23] <ricotz> cyphermox, my snapshot runs fine here so far
[13:23] <cyphermox> yeah, it's safe
[13:23] <ricotz> good :)
[13:24] <ricotz> seb128, btw, i think someone is willing to work on mimicking the logind1 dbus interface
[13:25] <ricotz> can't remember his nick right now, was in #gnome-hackers
[13:26] <seb128> ricotz, it would be useful if you found the name back ;-)
[13:26] <seb128> ricotz, slangasek is still looking at if we can adapt logind to work on top of upstart
[13:27] <seb128> would be easier than "mimicking"
[13:28] <seb128> ricotz, hum, graphite2 would need to be promoted as well? that gtk update start sounding like  a pile of work
[13:28] <ricotz> seb128, i see, is there a log of #gnome-hackers somewhere?
[13:29] <ricotz> seb128, this graphite dep isnt really needed, and was just introduced by debian
[13:29] <ricotz> nothing depends on those added harfbuzz symbols afaik
[13:30] <ricotz> so it could be just dropped to avoid this mir
[13:31] <seb128> ok, great
[13:31] <seb128> ricotz, thanks
[13:33] <didrocks> seb128: hunt you down… to death! :)
[13:33] <seb128> hiiiii
[13:33] <didrocks> scary isn't it? :)
[13:33] <seb128> it is!
[13:33] <seb128> see, I'm right to be careful and not break stuff :p
[13:33] <didrocks> heh
[13:57] <tkamppeter> pitti, I have a PackageKit problem: The background D-Bus daemon scp-dbus-service is not able to install a driver via PackageKit.
[13:58] <pitti> tkamppeter: oh, it doesn't run as root?
[13:58] <pitti> that's an user daemon?
[13:58] <ogra> tkamppeter, https://launchpad.net/ubuntu/raring/+source/ubuntu-settings/12.10.7 see the changelog
[14:00] <tkamppeter> pitti, yes, a user daemon, the installayion process should ask for the password, triggered by PolicyKit.
[14:13] <tkamppeter> pitti, ogra, I have got it installing now, once running on the original desktop and not SSHed in and second, installing gir1.2-packagekitglib-1.0.\
[15:10] <chrisccoulson> hah, i've just read ogra's response to the troll on ubuntu-devel
[15:10] <chrisccoulson> isn't that list moderated? i wonder who approved the original mail?
[15:11] <pitti> I mean, what did he even complain about? two more sprints like that, and memory usage will be 0
[15:11] <ogra> it shold be ... though if he's a member of the list ....
[15:13] <tkamppeter> pitti, ogra, thanks for your help, I have driver auto download out of scp-dbus-service working now.
[15:13] <ogra> awesome !
[15:13] <pitti> tkamppeter: didn't do anything -- great!
[15:15] <ricotz> seb128, regarding logind, it is "sobhan" in #gnome-hackers
[15:16] <seb128> ricotz, ok, thanks
[15:35] <seb128> hum, I'm pondering settings an haskell->null filter on my raring-changes folder ;-)
[15:35] <ogra> ++
[15:35] <Laney> :(
[15:35] <ogra> i just started marking all mails from Laney as read automatically
[15:35] <ogra> thats a smaller procmail filter
[15:36] <Laney> it... is?!?!?!?
[15:36] <ogra> heh, nah, and i'm lying
[15:36] <seb128> we should have a way to make those stack of rebuilt not spam -changes ;-)
[15:36] <ogra> yeah
[15:36]  * ogra looks at Riddell and his langpacks
[15:37] <tkamppeter> Someone knows how I can make windows opened out of the Python D-Bus user daemon scp-dbus-service appearing on top of the already existing windows on the desktop and not behind them?
[15:38] <Laney> hmm
[15:38] <Laney> I might be able to use archive.copyPackage/s/ which IIRC doesn't mail the list
[15:39] <Laney> currently I just have a script that pexpects syncpackage one by one ...
[15:46] <chrisccoulson> seb128, just stop reading -changes ;)
[15:47] <Laney> we need the archive border force to keep us all safe
[15:47] <chrisccoulson> heh
[15:48] <mterry> robru, heyo.  I have a deja-dup review for ya.  It's not urgent, but if you happen to have time in the next couple days
[15:48] <ogra> the border force wont prevent me from looking over the fence !!!!
[15:48] <seb128> Laney, ideally askell would stop changing in a way that forces us to rebuild half the archive every month ;-)
[15:48] <Laney> hahaha
[15:49]  * Laney refuses to rise to that trolling
[15:49]  * ogra files a removal bug for haskell
[15:49] <Laney> and that
[15:49] <ogra> ("as approved by seb128 on IRC")
[15:49] <Laney> someone needs to figure out how to implement shared library support for ghc and then implement it
[15:49] <Laney> if we all donate, say, £2k, we should be able to contract someone to do it
[15:49] <Laney> you in?
[15:50]  * ogra has only about £20 in his wallet, sorry
[15:51] <Laney> :P
[15:52] <jcastro> seb128: ! Is this a typo? lightdm from 25.7M to .6?
[15:52] <ogra> jcastro, nope
[15:52] <seb128> jcastro, no
[15:52] <jcastro> hah, awesome
[15:53] <ogra> for me it was actually closer to 30M before
[15:53] <seb128> jcastro, lightdm is not heavy, it was just using lot of ram because the whole process was under locked memory
[15:53] <jcastro> I don't typically care about my dm's memory consumption, it's just the change looked to drastic I didn't believe it.
[16:00] <seb128> jcastro, it's just how awesome mterry is ;-)
[16:00] <mterry> seb128, jcastro: well, I made that mlockall change originally, so....
[16:00] <Laney> speedup loop?
[16:00] <mterry> :)
[16:03] <jcastro> is it safe to assume I'll get that extra 200M back on the desktop session or does it work out differently?
[16:06] <mterry> jcastro, should be same benefits
[16:07] <jcastro> nice, that along with the raring dash improvements should make for a real snappy experience, well done!
[16:08] <mterry> jcastro, cruft creeps in over time really easily unless we are watching for it
[16:11] <ogra> jcastro, if by 13.04 release you only see 200M freed up we didnt do oiur job well ... i would hope we end up with ~250-300M for an idle desktop in the end
[16:12] <ogra> once all these service that can be started dynamially are actually off by default you should see another massive drop
[16:12] <ogra> (please fill in chars as appropriate ... )
[16:12]  * jcastro nods
[16:14]  * ogra wants to be able to run unity 13.04 on his ac100 (tegra2 512M RAM)
[16:14] <ogra> if it runs there, it will run everywhere
[16:16]  * xnox too
[16:25] <GunnarHj> charles: Hi Charles, waiting for your response to https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/138607
[16:29]  * mterry works on dropping old bluetooth indicator
[16:30] <didrocks> I would have loved the new one having tests though :/
[16:30] <mterry> didrocks, yeah, part of a larger indicator problem
[16:30] <didrocks> right, but some at least have unit tests :)
[16:31] <mterry> didrocks, speaking of...
[16:35] <tkamppeter> pitti, seb128, someone of you knows how I can make windows opened out of the Python D-Bus user daemon scp-dbus-service appearing on top of the already existing windows on the desktop and not behind them?
[16:35] <pitti> tkamppeter: that's under control of the window manager usually
[16:35] <pitti> for a few days now Unity seems to often place them in the background, which is rather annoying
[16:36] <pitti> I have the same prob with apport popups and e. g. devhelp when I launch it with Win+2
[16:36] <pitti> need to run out, bbl
[16:36] <pitti> tkamppeter: in short: don't worry about it for the first cut
[16:36] <tkamppeter> pitti, so it is a bug of Unity, thanks.
[17:35] <robru> mterry, hey, sorry. do you have another one, or are you talking about the last one that I forgot about from a couple days ago?
[17:36] <mterry> robru, the last one
[17:51]  * mterry goes to lunch
[17:57] <didrocks> robru: hey, can you join #ubuntu-unity? it's where the discussions happen :)
[17:57] <ogra> secret cabal !
[18:05] <didrocks> ogra: secretly public yeah! :)
[18:07]  * didrocks waves good evening
[18:53] <robru> mterry, just approved your mp
[18:54] <mterry> robru, awesome, thanks
[18:54] <robru> mterry, also emailed you some chat logs you missed from lunch break, as per didrocks' request.
[18:54] <mterry> robru, yeah, got that.  Thanks man
[18:55] <robru> mterry, no worries
[19:12] <attente> is there a nice way to tell unity-panel-service to die?
[19:13] <larsu> attente, killall unity-panel-servie
[19:13] <larsu> with a c, even
[19:13] <larsu> attente, or do you want it to stay dead?
[19:14] <attente> larsu, i'm not sure that's nice enough
[19:14] <attente> it's running in a valgrind instance
[19:14] <attente> so it needs to terminate of its own volition somehow...
[19:15] <larsu> I don't think there's a way to do that. Except sending SIGTERM :)
[19:15] <larsu> what are you trying to achieve?
[19:16] <attente> ah, that did the trick, thanks: )
[19:18] <attente> just trying to run memcheck
[19:38] <cyphermox> Laney: poke
[19:38] <cyphermox> Laney: for that screen corruption was it also just the rotation thing that was exploding in all kinds of ways?
[19:55] <robert_ancell> seb128, hey
[20:04] <seb128> oh, a robert_ancell saying hey, that's new!
[20:04] <seb128> robert_ancell, hey ;-)
[20:04] <robert_ancell> seb128, new job and all!
[20:05] <seb128> robert_ancell, I see, a brand new man!
[20:05] <robert_ancell> seb128, I was going to ask about dropping the gnome-bluetooth indicator patch - any plans on that or shall I leave it to you?
[20:06] <seb128> robert_ancell, https://launchpad.net/ubuntu/+source/gnome-bluetooth/3.6.1-0ubuntu2 ? ;-)
[20:06] <robert_ancell> ah, I looked for that. I've lost all my desktop-fu
[20:07] <seb128> robert_ancell, I did that today, thanks to mterry for getting the review/promotion to main sorted out the day I filed the bug
[20:09] <seb128> robert_ancell, didrocks complained about the lack of tests for it btw ;-)
[20:09] <robert_ancell> seb128, yeah, I don't know how to write indicator tests. It's already hard enough writing the indicators
[20:09] <seb128> right, that's what I replied as well
[20:09]  * mterry shakes his fist
[20:10] <seb128> none of the indicators seem to be well tested/that stack seems to be missing a test framework
[20:10] <mterry> Yeah, we need some autopilot tests I think.  But I've never done that before, so can't advise how easy it is
[20:10] <mterry> seb128, we just stole the panel autopilot tests from unity for now.  But that doesn't exercise the full range of indicator features
[21:16] <robert_ancell> seb128, https://code.launchpad.net/~robert-ancell/unity/bluetooth-indicator-position/+merge/146519
[21:19] <seb128> robert_ancell, thanks, approved (don't forget to put a commit message or the merger will fail the merge (did that for this one))
[21:20] <robert_ancell> seb128, doesn't it auto-merge it now?
[21:20] <seb128> robert_ancell, it does, but merge will fail on a "need a commit message" if you don't set one
[21:20] <dobey> anyone want to sponsor https://code.launchpad.net/~dobey/ubuntu/raring/tomboy/no-more-u1/+merge/146512 for me? :)
[21:21] <robert_ancell> seb128, I set the standard -m "Place new bluetooth indicator in correct location" - do I need to do something else?
[21:21] <seb128> dobey, will you keep support for the feature if I refuse? ;-)
[21:21] <dobey> no
[21:21] <seb128> bah, will sponsor then
[21:21] <dobey> but i will gladly point all the people who get errors when it goes away, to you :)
[21:21] <seb128> robert_ancell, yes, see e.g https://code.launchpad.net/~dobey/ubuntu/raring/tomboy/no-more-u1/+merge/146512
[21:21] <seb128> robert_ancell, you have "Set commit message"
[21:22] <seb128> robert_ancell, or https://code.launchpad.net/~robert-ancell/unity/bluetooth-indicator-position/+merge/146519 you have both description of the change and commit message
[21:22] <seb128> robert_ancell, the "commit message" section is under the expendable section when you submit the mr
[21:23] <robert_ancell> seb128, oh. It's filled out now - did you do that?
[21:23] <seb128> robru, it's a bit confusing, the idea is that a mr can have a stack of commits and that the commit message is a summary of what the merge is about
[21:23] <dobey> seb128: after that lands in raring, i'll start proposing all the branches to do the same thing in SRUs for current releases as well :)
[21:23] <robert_ancell> seb128, I guess it's the message you set when you do the merge manually
[21:23] <seb128> robert_ancell, yes, "(did that for this one)" as I wrote ;-)
[21:24] <robert_ancell> ah
[21:24] <seb128> dobey, :-(
[21:58] <Laney> dobey: woah, u1 is removing that altogether now?
[22:00] <dobey> Laney: yeah, announcement was posted today. server side will be going down at beginning of march
[22:01] <Laney> ah, a timely Rainy annoucement
[22:17] <Laney> cyphermox: hmm, I can't understand what you're asking me I'm afraid :(
[22:18] <Laney> it didn't work either when I went to portrait
[22:32] <bryce> robert_ancell, heya, do you still cover lightdm related issues, or is that handed off to someone else?
[22:40] <robert_ancell> bryce, yes I am, but unity-greeter remains in desktop/dx
[22:41] <bryce> robert_ancell, ok, yeah this is foundation level stuff
[22:42] <bryce> robert_ancell, we've been getting scattered X crash reports that appear to be race conditions with X getting started up before DRM has been initialized
[22:42] <bryce> bug 1037518 and bug 1115177 are recent examples
[22:42] <ubot2> Launchpad bug 1037518 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT - FatalError (f=f@entry=0x7f41e2f9a9e2 "no screens found")" [High,Triaged] https://launchpad.net/bugs/1037518
[22:42] <ubot2> Launchpad bug 1115177 in xorg-server (Ubuntu) "X fails to start - [drm] failed to set drm interface version" [High,Triaged] https://launchpad.net/bugs/1115177
[22:42] <robert_ancell> bryce, yeah, that's kind of outside my knowledge - I just wait for upstart to kick lightdm and it should only do that when DRM is ready
[22:43] <robert_ancell> bryce, but if there's a better method then I can modify lightdm to do a better job
[22:43] <bryce> robert_ancell, ah ok, thanks.
[22:43] <Darxus> RAOF: It has been suggested that this article ( http://www.omgubuntu.co.uk/2013/02/canonical-working-on-new-display-server ) could be based on bad information, and that the last canonical person to post to the wayland list might know better.  Any chance you (or anybody else here) can say if ubuntu is planning on their own non-wayland display server?
[22:43] <bryce> robert_ancell, I can keep digging.  Happen to know who I should talk to next?  slangasek or apw maybe?
[22:44] <robert_ancell> bryce, I don't unfortunately. We had these issues with nvidia but no-one seems to know well enough why it occurs.  A number of people tried to find the solution but the only one that was found to work reliably was sleep 1
[22:44] <bryce> robert_ancellafk, ok thanks.   I'll chat with apw next.
[23:29] <antarus> Anyone know if it is possible to display notifications at login time (like in the unity-greeter, before the user has logged in?)
[23:30] <antarus> For instaince, there are reboot notifications that we display using the freedesktop notification spec
[23:30] <antarus> but they do not display until the user has logged in