[02:28] <micahg> Unit193: /usr/lib/firefox-*/omni.ja?
[02:29] <Unit193> Thanks, that{ll give me a starting place too
[02:39]  * Unit193 is an idiot, yep
[16:20] <FernandoMiguel> oi
[16:27] <gnomefreak> anyone know if lightning is workiing with thunderbird-trunk? version 10.0?
[16:29] <gnomefreak> also it seems tb is refusing to accept my passwords again. i double checked all of them and re entered them still no luck. last time i changed profiles and same issue. i havent used tb in a while do to this problem
[16:31] <micahg> gnomefreak: trunk is 12, you'd need lightning 1.4 or something, for 10, 1.2b2 should work
[16:33] <gnomefreak> micahg: ok i dont see a 1.4 only 1.2b2 as latest on http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/ but thanks. im updating tb now
[16:34] <gnomefreak> ok thats odd. if you go to thunderbird->help>about it shows 10 but policy shows i have 12
[16:35] <gnomefreak> ok i found why
[16:37] <gnomefreak> ok trunk build excepted all but 1 password


[06:20] <didrocks> good morning
[06:50] <pitti> hey didrocks, ca va?
[06:50] <didrocks> guten morgen pitti
[06:50] <didrocks> ça va bien, et toi? :)
[06:50] <pitti> je vais bien, merci!
[06:51] <pitti> some friends of us visited us over the weekend, was nice; we walked a looooot :)
[06:51] <didrocks> oh great :)
[06:51] <didrocks> I didn't get a really relaxing week-end as at the ubuntu-fr booth for 2 days, but next one will be a tireless-free one :)
[07:06] <glatzor> morning pitti
[07:07] <pitti> hey glatzor, guten Morgen!
[07:08] <glatzor> pitti, could you help me on a gobject problem: I want to to build the sphinx documentation of aptdaemon, but it fails with a failed import: from ._gi import _API, Repository. To reproduce just run python setup.py build_sphinx
[07:10] <pitti> glatzor: will try in a sec
[07:11] <pitti> error: invalid command 'build_sphinx'
[07:11] <pitti> oh, I still have my pkcompat-enhancements branch here, hang on
[07:13] <pitti> glatzor: hm, pulled trunk, still says that ^
[07:14] <glatzor> pitti you need to install python-sphinx
[07:14] <pitti> oh, silly me; doing
[07:14] <pitti> build succeeded, 29 warnings.
[07:15] <pitti> glatzor: right, I get the exception as well
[07:15] <pitti> glatzor: apparetnly it tries to import the old static "gobject", too, as the error says
[07:15] <pitti> ImportError: could not import gobject (error was: ImportError('When using gi.repository you must not import static modules like "gobject". Please change all occurrences of "import gobject" to "from gi.repository import GObject".',))
[07:18] <pitti> glatzor: my usual trick for this is to add raise ImportError("not static!") to /usr/lib/python2.7/dist-packages/gobject/constants.py
[07:18] <pitti> to get an exception at the time when the static module is imported
[07:18] <pitti> apparently it's done in __import__(self.modname), it probably takes that from the aptdaemon source?
[07:19] <pitti> glatzor: there are several imports of "gobject" in the source left, indeed
[07:19] <pitti> ./aptdaemon/client.py:    import gobject as GObject
[07:19] <pitti> and presumably from the old gtkwidgets.py
[07:20] <pitti> glatzor: with this trick I only have one error left: http://paste.ubuntu.com/1022653/
[07:21] <pitti> glatzor: which applies to "gtkwidgets" indeed; not much we can do about that, I'm afraid; I think it's okay to skip that old module from the docs, though?
[07:23] <glatzor> pitti, thanks that seems to be the trick. I just removed the old sources. I missed the import gobject warning although reading the error log several times ...
[07:23] <pitti> glatzor: gtkwidgets are gone now? \o/
[07:23] <glatzor> no just from the documentation :)
[07:23] <pitti> ah, good
[07:24] <pitti> glatzor: python-aptdaemon.gtkwidgets seems to have zero reverse dependencies left
[07:24] <pitti> python-aptdaemon-gtk still has two
[07:25] <Sweetshark> moin
[07:28] <pitti> hey Sweetshark, wie gehts?
[07:35] <Sweetshark> pitti: good, I had be to a party weekend in Schwerin. It had been really interesting: Schwerin is just an 1 hour drive from hamburg and its an different world altogether.
[07:39] <pitti> Sweetshark: indeed; we drove through on a bicycle tour a few years back
[07:47] <Sweetshark> pitti: also culture is different. and it is the capitol of McPomm with mere 100000 inhabitants. That drew a few snide remarks from Hamburg guys/gals ...
[07:51]  * pitti objects to "Mc" Pomm
[07:52] <Sweetshark> pitti: still, not being derogative: it is just different. Some are happy with the way things worked there and like the way life is. while other do not, esp. some of those would loudly claim to love it -- qui s'excuse, s'accuse.
[07:53] <Sweetshark> McPomm is how Mecklenburg expatriates in Hamburg call their home. And there are a lot of them.
[07:53] <pitti> wow, I didn't know that
[08:04] <Laney> morning
[08:06] <seb128> hey
[08:07] <RAOF> seb128: Good morning!
[08:07] <seb128> RAOF, hey, how are you?
[08:07] <RAOF> I'm the all-singing all-dancing compositor master!
[08:08] <RAOF> Also, I'm fine.
[08:08] <RAOF> ;)
[08:10] <pitti> bonjour seb128, hey RAOF
[08:10] <pitti> RAOF: nice, making progress with the system compositor?
[08:10] <seb128> RAOF, hehe, did you get something working?
[08:11] <RAOF> seb128: For sufficiently loose definitions of "working"
[08:11] <seb128> pitti, hey our qa friend, how are you? ;-)
[08:11] <RAOF> ie: the *compositor* (probably) works, but there aren't any clients that support it :)
[08:11] <pitti> seb128: I'm great, thanks! we had a nice weekend, some friends came to visit
[08:11]  * RAOF heads to pilates.
[08:12] <didrocks> salut seb128, Laney, RAOF!
[08:13] <seb128> lut didrocks
[08:13] <Laney> hola!
[08:13] <Laney> cómo estás?
[08:15] <Sweetshark> We should add a splash screen with RAOF singing and dancing on opening a unity3D session ...
[08:15] <seb128> Laney, hey, how are you?
[08:15] <seb128> hey Sweetshark
[08:15] <pitti> hey Laney
[08:15] <Laney> we had a wet weekend but there were some celebrations for the jubilee :-)
[08:15] <seb128> Laney, I saw your unity ftfbs bug, did you talk to didrocks about it? the dx guys have been looking at it for some days
[08:16] <Laney> didrocks already saw it
[08:16] <Laney> and rejected :P
[08:16] <didrocks> and already rejected the branches ;)
[08:16] <seb128> ok
[08:16] <Laney> I never saw that segfault though, strange
[08:16] <seb128> Laney, I need to reply at your email :-(
[08:16] <Laney> heheh
[08:16] <didrocks> Laney: reliable for me, between 0 and 2s after looging
[08:16] <didrocks> logging*
[08:16] <Laney> oh well, no worries if it's being worked
[08:16] <seb128> Laney, if we had waited on the q build to work those bug fixes would still not have been uploaded to the lts proposed
[08:17] <seb128> Laney, thanks for assuming we were ignoring issues :p
[08:17]  * Sweetshark doesnt like his precise notebook sometimes hanging on "checking battery state" during boot.
[08:18] <seb128> Sweetshark, don't pay attention to the message, that's likely not where it's hanging
[08:19] <Laney> ah, didn't mean to accuse, just saw those examples
[08:19] <Laney> maybe something else can be done there
[08:20] <Sweetshark> seb128: right, I even got a vt by ctrl-alt-F2, pstree showed lightdm running happily (even though I didnt saw anything of that). /etc/init.d/lightdm restart then gave me an X.
[08:21] <Sweetshark> s/didnt saw/didnt see/
[08:22] <seb128> Sweetshark, it does it only sometimes?
[08:22] <Sweetshark> seb128: yep.
[08:23] <seb128> Laney, well, the "It's not clear to me what we can do about people not test-building their uploads", I did the unity upload and I did test build and run it so it's a bit offensive
[08:24] <seb128> Laney, it just happens that I'm still on precise
[08:24] <seb128> Laney, where the build works
[08:25] <Sweetshark> it started a few days ago. Possible changes a) a recent softwate update b) I ran the notebook with battery pack and DVD-drive removed for the first time around that time too.
[08:25] <Sweetshark> seb128: ^
[08:25] <seb128> Sweetshark, I don't think we had any recent update that should impact on the boot sequence
[08:26] <Sweetshark> seb128: maybe its just this screen handover to X stuff?
[08:26] <seb128> could be
[08:28] <Sweetshark> nvidia-drivers do not work since ~January on oneiric on this machine. Nouveau and intel mostly work.
[08:28] <Sweetshark> so the X stuff is somewhat tricky on this machine anyway.
[08:40] <dupondje> Something changed with gnome-shell recently ? Having a really annoying issue, which I can't seem to solve, and occuring more frequently now
[08:40] <dupondje> If I login to the gnome-shell, it fails to load completely
[08:40] <dupondje> no errors, nothing :s
[08:45] <seb128> dupondje, precise,
[08:45] <seb128> ?
[08:46] <seb128> Sweetshark, could be bug #969489
[08:46] <ubot2`> Launchpad bug 969489 in lightdm "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489
[08:47] <seb128> Sweetshark, see comment #19
[08:48] <dupondje> seb128: precise indeed
[08:49] <dupondje> had it once a week or so before
[08:49] <dupondje> since last week, almost every startup :s
[08:49] <dupondje> quite annoying :)
[08:49] <seb128> dupondje, dunno, I don't think many people here are using g-s, maybe ask jbicha when he's around ... did you try to look to .xsession-errors when that happens?
[08:49] <Sweetshark> seb128: could be. Also added a SSD recently so maybe I am just booting too fast
[08:49] <seb128> Sweetshark, can you try to change suggested in comment 19?
[08:50] <dupondje> seb128: no errors in .xsession-errors. Can fix it with just going to other console, kill -9 gnome-shell, and then it runs fine.
[08:51] <Sweetshark> seb128: yes, will do. I would need some reboot to see if things get better.
[08:51] <seb128> Sweetshark, just change it and see how it goes in the next weeks?
[08:52] <Sweetshark> seb128: yes
[08:57] <Sweetshark> lightdm has too many files called lightdm.conf
[08:58] <didrocks> changing machine enables to make test suite less machine-dependant :)
[08:59] <didrocks> just 3 remaining issues, all were due to the same logo-thingy
[09:21]  * mvo lols@weboob-qt - there is dating website optimizer in there
[09:25] <ogra_> speeding up speed-dating ?
[10:02] <seb128> pitti, do you know if there is a blueprint somewhere about the new media size and what images we are aiming at having for q?
[10:03] <pitti> seb128: no, I don't think it was discussed at UDS
[10:03] <seb128> pitti, not sure if there was a proper UDS session about that
[10:03] <seb128> ok
[10:03] <seb128> pitti, thanks
[10:03] <pitti> this mostly happened at "on the floor" discussions with Rick and Steve, AFAIR
[10:04] <seb128> pitti, the floor discussions are biting back :p
[10:04] <seb128> i.e no proper record of the plan or anything it seems
[10:04] <pitti> seb128: well, Rick already announced it by mail beforehand
[10:04] <pitti> "we will reduce our image count to 1"
[10:05] <seb128> pitti, right, but there is no proper place to check what is required before i.e we can drop alternate
[10:05] <pitti> I think that part (teach ubiquity about LVM etc.) should have a BP
[10:05] <seb128> pitti, don't worry, I was just checking there is nothing I didn't find before registering a blueprint
[10:06] <pitti> seb128: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-ubiquity-lvm-luks
[10:06] <seb128> pitti, thanks
[11:15] <didrocks> mvo: just fixed the crash on linuxmint and other derivatives in software-center (on the oneconf side)
[11:15] <didrocks> will spam a little bit less errors.ubuntu.com
[11:16] <didrocks> the tests were the most difficult to write due to potential races :)
[11:17] <didrocks> this could have never worked, which means that elementary, linuxmint, and other derivatives never tested installing anything on a configuration or that they didn't care to get an apport crash at each package installation…
[11:28] <soren> didrocks: "installing on a configuration"? What does that mean?
[11:29] <didrocks> soren: I eat some words: "on a configuration different from an ubuntu one"
[11:29] <ogra_> hmm, does it really make sense to have mint and frineds on erros.u.c ?
[11:30] <ogra_> given that mint suporesses many SRUs and security updates it wouldnt stop reporting, even if a fix was uploaded in ubuntu
[11:30] <seb128> ogra_, not sure, it's probably a "how do you filter them out"
[11:30] <seb128> ogra_, mint is mostly stock ubuntu with a few of their packages added
[11:31] <ogra_> yeah, finding a fiter thats a common denominator between all derivatives might be hard
[11:31] <ogra_> seb128, and with things like xorg, compiz, kernel and grub blocked from updates in their hacked update manager
[11:32] <seb128> right, well that's not something different on the packages content
[11:32] <ogra_> ask mdeslaur, i think he was the one who did an analysis of that bit
[11:32] <seb128> not sure if they change their lsb infos, I guess they do
[11:32] <ogra_> no, its not, but they wont get fixes we upload
[11:32] <ogra_> which means whoopsie will go on collecting issues
[11:33] <seb128> well, whoopsie collects the version where it happens
[11:33] <seb128> so you can filter out old versions
[11:33] <ogra_> ah, yeah
[11:33] <seb128> but yeah, we should filter them out, that's just a missing feature
[11:33] <ogra_> right
[11:33]  * ogra_ will bring that up in the next foundations meeting
[11:37] <mvo> didrocks: very nice, thanks, I have a look in  a bit
[11:37] <mvo> didrocks: I assume you submited a MP?
[11:38] <didrocks> mvo: sorry, I wasn't clear, I succeed in making that on the OneConf side only, so you don't have to review anything, it was more a FYI :)
[11:39] <mvo> didrocks: ah, even better \o/
[11:40] <didrocks> alf_: hey, around?
[11:43] <jbicha> dupondje: yeah I run gshell half the time, but I don't really use precise and haven't seen that bug
[11:43] <jbicha> good morning
[11:49] <mdeslaur> seb128: yes, they do change their lsb infos
[11:54] <didrocks> ogra_: do you have more time now to get some build time on an armel machine?
[11:55] <didrocks> ogra_: would be nice to be able to fix this compiz issue without me doing 10 uploads
[12:02] <ogra_> didrocks, i'm on it
[12:02] <didrocks> ogra_: thanks :)
[12:35] <dupondje> hi jbicha, weird, having it alot last week :(
[13:04] <dobey> Laney: so basically, you generally never need to vote on your own merge proposals, and only really need to resubmit them if there are very large/differeng changes from the original proposal :)
[13:04] <pitti> glatzor: for the install_signature MP, do you want to wait for your python-apt MP to get the AptAuth bits merged?
[13:05] <didrocks> micahg: hey, around?
[13:39] <Laney> dobey: I see, thanks for the education
[13:40] <dobey> sure
[13:53] <micahg> didrocks: now I am
[13:58] <ogra_> didrocks, still fails :(
[13:59] <seb128> cyphermox, hey
[13:59] <seb128> cyphermox, could you look at https://code.launchpad.net/~penguin359/ubuntu/precise/network-manager/fix-for-1005091-precise/+merge/107545 ?
[14:00] <cyphermox> yes, working on it
[14:00] <ogra_> didrocks, trying with s/-Werror // now
[14:00] <cyphermox> seb128: I thought I had already commented on it though
[14:01] <seb128> cyphermox, you maybe commented on the bug? I was looking at the sponsoring queue and it has the mr
[14:01] <cyphermox> nah, it's because there are multiple merge requests
[14:01] <seb128> cyphermox, yeah, just saw that
[14:02] <cyphermox> wtf
[14:03] <cyphermox> seb128: ETOOMANY
[14:03] <seb128> hehe
[14:03] <cyphermox> ;)
[14:03] <glatzor> pitti, I don't want to block you. I will merge the changes after the python3 port is done. but in the meantime you could carry the changes as a patch (they don't work with python3 yet)
[14:04] <glatzor> pitti, so there isn't any basic objection against your changes.
[14:04] <pitti> glatzor: it's not that urgent; not sure when cyphermox wants to start with writing the UI side, but once he does, I can hand him some local branches to run against
[14:04] <pitti> cyphermox: ^ FYI
[14:04] <glatzor> pitti, hopefully I will get the python3 upload ready today or tomorrow
[14:04] <pitti> glatzor: cool, thank you!
[14:04] <cyphermox> pitti, glatzor: cool, thanks
[14:05] <Sweetshark> seb128: any news on the 3.5.4 SRU? I applied for MRE in the meantime (no reply yet), but still ...
[14:05] <seb128> Sweetshark, slangasek confirmed that the SRU team will not accept it until the TB approve the MRE
[14:06] <desrt> good morning, developers of the ubuntu desktop.  i hope you are all well.
[14:06] <didrocks> ogra_: still fail, like, more error?
[14:06] <ogra_> same error
[14:06] <didrocks> how did you fix it? added the virtual?
[14:06] <ogra_> i used your patch
[14:06] <didrocks> virtual keyword on the destructor
[14:07] <glatzor> pitti, I still see this message in the build log: "g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting". Do you have got any idea what is happening?
[14:07] <didrocks> ogra_: hum, I didn't send a patch, just the branch with compiz vanilla as I was thinking you were handling the gcc4.7 fixes :)
[14:07] <didrocks> ogra_: anyway, -Werror will be fine for now
[14:07] <didrocks> micahg: small question on the chromium build: I have no webgl support (no acceleration on the browser), my intel card is pretty descent, any idea?
[14:07] <ogra_> didrocks, you gave me a tree that has sed parsing CFLAGS and CXXFLAGS
[14:08] <pitti> glatzor: I haven't seen this before, no; I can vaguely remember a pygobject bug about gio being broken for async operations, though
[14:08] <ogra_> for gles arches
[14:08] <didrocks> ogra_: oh right
[14:08] <ogra_> thats what i tried building
[14:08] <Sweetshark> seb128: uploading libreoffice_3.4.5+really3.4.4-0ubuntu1 right now, btw ...
[14:08] <ogra_> but i think what you drop isnt enough
[14:08] <seb128> Sweetshark, ok
[14:08] <didrocks> ogra_: yeah, seems so
[14:08] <glatzor> pitti, I only see those when building on launchpad
[14:08] <pitti> glatzor: might be gnome bug 671139
[14:08] <ogra_> sadly Werror still shows up everywhere in the flags
[14:08] <ubot2`> Gnome bug 671139 in introspection "need (transfer async) for io stream buffers" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=671139
[14:09] <micahg> didrocks: not offhand
[14:09] <didrocks> micahg: from the google help, it seems they require mesa 7.9, but it's fine, isn't it?
[14:09] <didrocks> micahg: I had it for a while, but not since last week
[14:09] <micahg> it should be
[14:10] <micahg> didrocks: which build are you running?
[14:10] <seb128> didrocks, webgl is a configure flag in webkit, not sure if that's the case for chromium as well
[14:11] <ogra_> didrocks, it seems like cmake/CompizCommon.cmake has Werror hardcoded
[14:11] <didrocks> micahg: the one we have in quantal
[14:11] <seb128> didrocks, we didn't turn it on for the standalone webkit yet
[14:11] <pitti> glatzor: does that break the build?
[14:11] <pitti> glatzor: we still have a lot of buildds on hardy kernels, some on lucid
[14:11] <didrocks> seb128: it's built with it, but I have to use --ignore-gpu-blacklist
[14:11] <glatzor> mvo, pitti  I think have to admit that I cannot get the test suite of aptdaemon running on the build bot.
[14:11] <pitti> glatzor: glib acts up a lot on those old kernels
[14:11] <micahg> didrocks: hrm, maybe there's some bad detection logic there, or the GPU is blacklisted for some other reason
[14:11] <didrocks> seb128: I notice, some of my animations for the quickly html template are pretty slow to render :)
[14:12] <glatzor> pitti, now the packagekit tests fail again without any changes to them .... https://launchpadlibrarian.net/106846697/buildlog_ubuntu-quantal-i386.aptdaemon_0.43%2Bbzr830-0~ppa1_FAILEDTOBUILD.txt.gz
[14:12] <didrocks> micahg: who should I talk to?
[14:12] <didrocks> ogra_: argh, feel free to patch it then :/
[14:12] <ogra_> hmpf, k
[14:12]  * micahg would suggest checking for a bug on crbug.com
[14:13] <didrocks> ok, will have a look then
[14:13]  * ogra_ tries something different
[14:14] <pitti> glatzor: so that happens consistently on the buildds, or sometimes on the buildds, and never locally?
[14:15] <glatzor> pitti,  the test suits runs without any errors on my local system (in quantal and wheezy). in the build before another test was failing but the once reported to be failed in 830~ppa1 had been successfull.
[14:16] <pitti> glatzor: so either a race condition, or it depends on which particular buildd you catch?
[14:16] <glatzor> pitti, so I re-uploaded the same source now with an increased version number only to try another buildd
[14:16] <glatzor> pitti, I haven't yet looked at the names of the buildds
[14:25] <ogra_> didrocks, hacked the cmake file directly for this testbuild, seems with that Werror is gone now, will report back if it survives  the build now
[14:25] <didrocks> ogra_: excellent, thanks! :)
[14:25] <ogra_> well, but thats indeed not the right thing to do for a general upload
[14:33] <ogra_> didrocks, ok, survived ... i'm at 53% now (it used to die at 51)
[14:34] <ogra_> but i'm not sure how we should hack the file properly without affecting all builds
[14:35] <didrocks> ogra_: \o/
[14:35] <didrocks> ogra_: hum, I would say "don't worry for now" as the next version of compiz we will push will have the patch merged
[14:35] <didrocks> ogra_: so at some point, the real gcc4.7 fixes for the armel part will be neede
[14:35] <didrocks> needed*
[14:35] <ogra_> didrocks, well, i need a working binary "yesterday"
[14:36] <ogra_> compiz ftbfs makes all arm image builds fail
[14:36] <ogra_> which isnt so good for A1
[14:36] <ogra_> :)
[14:37] <didrocks> ogra_: indeed, so just push that version
[14:37] <ogra_> with the manually hacked cmake ?
[14:37] <ogra_> k
[14:37] <didrocks> ogra_: yep, sounds good to me ;)
[14:38] <ogra_> sigh ... though that will be really hard ... the gles patch will fail to apply then since it touches the same file to set the gles options ... i wonder if we shouldnt just disable the gles patch :)
[14:39]  * ogra_ tries that with another testbuild
[14:40] <didrocks> ogra_: at this point, just do whatever is best for you :)
[14:40] <didrocks> (sorry, in a hangout)
[14:40] <ogra_> heh, indeed
[14:45] <didrocks> as you told me there is no driver ready yet for armel, the damage seems to be very low :)
[14:46] <ogra_> well, we dont care about armel ... but yeah, there is no driver for armhf yet :P
[14:46]  * ogra_ will waer an "armel is dead" T-shirt every day at the next UDS to get that change across :)
[14:46] <ogra_> *wear
[14:50] <ogra_> GAH !
[14:50] <ogra_> without the gles patch it indeed tries to build crap like cube and dies there
[14:51]  * ogra_ curses, i'm supposed to work on totally different things today, sigh
[15:08] <seb128> mvo, hey, do you really need sponsoring for https://code.launchpad.net/~mvo/software-properties/fix-policykit-prompt-on-startup/+merge/104655 ? ;-)
[15:27] <mvo> seb128: code review I think or did someone do that?
[15:27] <seb128> mvo, oh ok, you do code review for those ... it's showing on the sponsoring queue, I was trying to help dholbach with the "there are over 100 items on the queue"
[15:31] <mvo> seb128: well, its not required, it just would be nice
[15:32] <seb128> mvo, ok, I guess it can stay on the sponsoring queue until that happens ;-)
[15:33] <glatzor> pitti, it was really a buildd issue. on mercury all builds fine
[15:33] <glatzor> yeah!
[15:33] <pitti> glatzor: I blame the hardy kernel then :)
[15:33] <pitti> good night everyone!
[15:34] <glatzor> mvo, pitti, you can now use ppa:aptdaemon-developers/python3 to port your software.
[15:34] <glatzor> pitti, good evening martin!
[15:35] <mvo> glatzor: awsome, when can I upload?
[15:42] <pitti> glatzor: \o/
[21:27] <sgringwe> jasoncwarner_, ping
[22:32] <sgringwe> jasoncwarner_, ping
[23:24] <nsbig> Where do I download the shared library (.so) files for PAM? I tried 'sudo apt-get install pam-modules' and it installs, but pam_access.so is missing.
[23:29] <RAOF> nsbig: This isn't a support channel, but pam-modules (at least in Quantal, and I see no reason why this would have changed) is the package which contains pam_access.so.
[23:34] <nsbig> libpam-modules is the package.
[23:40] <RAOF> Yeah, that one.


[00:05] <guiverc> I'm having trouble "Lubuntu checklist install - full disk, ENCRYPTion, UEFI, NO internet"; thumb-drive has been tested twice good, but still "Installation failed. Bad unsquash configuration. The sources's filesystem "/cdrom/casper/filesystem.unsquashfs" does not exist" is this known?
[00:07] <guiverc> s/.unsquashfs/.squashfs/ ^
[00:13] <kc2bez> I don't think it was known guiverc but I am not sure if I tested for that either.
[00:13] <guiverc> "Installation failed. Bad unsquash configuration. The source filesystem "/cdrom/casper/filesystem.squashfs" does not exist"
[00:15] <guiverc> I didn't find anything on lp .. I'll file & look at lp report..  Thanks kc2bez
[00:16] <kc2bez> Out of curiosity which daily was the last one you tried before this one?
[00:18] <guiverc> 20191007 (no issues) - I added a ISO field to https://phab.lubuntu.me/w/release-team/testing-checklist/ so I can record there  -- today I'm sing 2019-10-08 freshly downloaded
[00:19] <guiverc> s/sing/using/ ^  (it's a bit cool)
[00:20] <kc2bez> Ok good to know. Thanks.
[00:23] <guiverc> lp 1847378   ^
[00:40] <kc2bez> It looks like all efi installs fail. I tried with internet and unencrypted. BIOS install worked in VBOX
[00:40] <kc2bez> @tsimonq2 wxl Check above ^^
 Find where the squashfs is
[00:45] <kc2bez> It looks like it is where it is supposed to be. `/cdrom/casper/`
[00:50] <kc2bez> http://paste.ubuntu.com/p/qjrRgHn2YQ/
[01:02] <guiverc> kc2bez, sorry I walked dog & disappeared, I had two passes listed on checklist (https://phab.lubuntu.me/w/release-team/testing-checklist/) using 20191007 ISO done yesterday
 Does it work in the Beta?
[01:14] <guiverc> tsimonq2, it'll take me awhile to download & test beta.. but franksmcb listed EFI as tested on http://iso.qa.ubuntu.com/qatracker/milestones/406/builds/200084/testcases/1701/results   (beta) - want me to download/test?
[01:14] <kc2bez> I should have it pulled down in a couple of minutes
[01:20] <kc2bez> @tsimonq2 it looks like artwork failed to build, somewhere  in all the commotion debian/lubuntu-artwork.install changes got dropped. Take a look here https://phab.lubuntu.me/D47?id=149#change-Pqx5HNNamdwy
[01:20] -lugito:#lubuntu-devel- Error: D47?id=149#change-Pqx5HNNamdwy is an invalid task reference.
[01:22] <kc2bez> LUKS on EFI in VBOX works for the beta.
 lxqt-globalkeys landed, please upgrade and test @The_LoudSpeaker
 lxqt-globalkeys-l10n/eoan,eoan 0.14.1+git20190923-0ubuntu1 all [upgradable from: 0.14.1-0ubuntu4]
 On it.
[01:37] <kc2bez> Ok weird, 3 out of 10 times the daily has stuff in /cdrom/casper/
[01:43] <kc2bez> It looks like having a luks partition on the installed system seems to make the live iso fail. If the installer fails you reboot it will work the next time around. I will test the same on the beta now.
[01:44] <guiverc> I rebooted sony thing (used in my testing) & now it's installed - fitting with the 3 out of .. of kc2bez  (/cdrom/ directory was populated this boot I noted)
[01:44] <guiverc> (still using latest ISO 20191008)
[01:45] <guiverc> installed/installing ^
[01:48] <kc2bez> It looks like the beta is having no issues with the installed system being luks. I will test it again to make sure.
[01:57] <kc2bez> I'm not having any issues with the beta release, only the daily.
[02:08] -lugito:#lubuntu-devel- [rMANUAL736b4f5c961d: Add DNS 1 field] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL736b4f5c961d
[02:10] -lugito:#lubuntu-devel- [rMANUALc4f57fa83442: Add DNS(2)] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALc4f57fa83442
[02:14] -lugito:#lubuntu-devel- [rMANUALf33e2df5214f: Add MAC Address field] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALf33e2df5214f
[02:44] <kc2bez> @tsimonq2 wxl 3 diffs up for review. https://phab.lubuntu.me/D50 https://phab.lubuntu.me/D51 https://phab.lubuntu.me/D52
[02:44] -lugito:#lubuntu-devel- [Needs Review] Package Calamares for new upstream release: https://phab.lubuntu.me/D50
[02:44] -lugito:#lubuntu-devel- [Needs Review] Calamares is not capitalized: https://phab.lubuntu.me/D51
[02:44] -lugito:#lubuntu-devel- [Needs Review] Add wallpapers to lubuntu-artwork.install: https://phab.lubuntu.me/D52
[02:45]  * kc2bez sleeps now
[02:46] <guiverc> sleep well kc2bez, thanks for all your hard work today (& every day)
[07:27] <guiverc> VLC is working in Kubuntu live; still not in Lubuntu  :(
[07:28] <RikMills> the fixed kernel is not in Eoan yet. I fudged a fix for kubuntu
[07:29] <guiverc> that makes me feel better... thanks RikMills
 lubuntu-artwork failed to build: https://launchpadlibrarian.net/445881802/buildlog_ubuntu-eoan-amd64.lubuntu-artwork_19.10.2_BUILDING.txt.gz
 New wallpapers were not added to .install file
 @RikMills [New wallpapers were not added to .install file], I pushed a diff in phab before I went to bed that should fix that.
 @kc2bez [I pushed a diff in phab before I went to bed that should fix that.], I don't see one. Link?
 https://phab.lubuntu.me/D52
[08:24] -lugito:#lubuntu-devel- [Needs Review] Add wallpapers to lubuntu-artwork.install: https://phab.lubuntu.me/D52
 Oh, a diff for review. I thought you meant a commit direct to the repo.
 I forget that a lot of you are doing it like that
 Yes, for review in phab not to the repo.
 :)
 @The_LoudSpeaker lxqt-globalkeys working ok in my tests
 lxqt-globalkeys/eoan,now 0.14.1+git20190923-0ubuntu1 amd64 [installed]
 @kc2bez I'll merge and upload all of your diffs in about 45 mins, unless you can get to it first
 @HMollerCl [@The_LoudSpeaker lxqt-globalkeys working ok in my tests], All clear?
 yes
 Sweet
 @tsimonq2 [@kc2bez I'll merge and upload all of your diffs in about 45 mins, unless you can …], I am tied up for a bit so please go ahead. I appreciate it.
 @kc2bez [I am tied up for a bit so please go ahead. I appreciate it.], Thanks for your work
 ("nice one" is an Ubuntu Desktop-ism)
[17:02] <wxl> sorry for being quiet ya'll. what did i miss?
[19:58] -lugito:#lubuntu-devel- [rCALAPACKAGINGc2221d578729: Package Calamares for new upstream release] tsimonq2 (Simon Quigley) committed: https://phab.lubuntu.me/rCALAPACKAGINGc2221d578729
[20:00] -lugito:#lubuntu-devel- [rCALASETTINGSa45f0163460c: Calamares is not capitalized] tsimonq2 (Simon Quigley) committed: https://phab.lubuntu.me/rCALASETTINGSa45f0163460c
[20:02] -lugito:#lubuntu-devel- [rCALASETTINGSd34d3ac983ee: Depend on a versioned Calamares to ensure that this package and Calamares…] tsimonq2 (Simon Quigley) committed: https://phab.lubuntu.me/rCALASETTINGSd34d3ac983ee
[20:03] -lugito:#lubuntu-devel- [rART803eeff97030: Add wallpapers to lubuntu-artwork.install] tsimonq2 (Simon Quigley) committed: https://phab.lubuntu.me/rART803eeff97030
[20:03] <wxl> ^ re: that change of the log files, we'll need to rewrite the apport hook
[20:06] -lugito:#lubuntu-devel- [rNMTRAYPACKAGING5040504b2c6d: Fix FTBS of nm-tray] tsimonq2 (Simon Quigley) committed: https://phab.lubuntu.me/rNMTRAYPACKAGING5040504b2c6d
[20:09] -queuebot:#lubuntu-devel- Unapproved: calamares-settings-ubuntu (eoan-proposed/universe) [1:19.10.6 => 1:19.10.7] (lubuntu)
[20:09] -queuebot:#lubuntu-devel- Unapproved: calamares (eoan-proposed/universe) [3.2.12-0ubuntu1 => 3.2.14-0ubuntu1] (lubuntu)
[20:09] -queuebot:#lubuntu-devel- Unapproved: lubuntu-artwork (eoan-proposed/universe) [19.10.2 => 19.10.3] (lubuntu)
[20:10] -queuebot:#lubuntu-devel- Unapproved: nm-tray (eoan-proposed/universe) [0.4.3-0ubuntu1 => 0.4.3-0ubuntu2] (lubuntu)
[20:18] -queuebot:#lubuntu-devel- Unapproved: accepted lubuntu-artwork [source] (eoan-proposed) [19.10.3]
[20:34] <wxl> https://phab.lubuntu.me/source/calamares/browse/ubuntu%252Feoan/debian/patches/apport-package-hook.patch$55
[20:34] <wxl> ^ @kc2bez
[20:34] <tsimonq2> wxl: Funny, Cala was just accepted.
 ahh poo, I missed that apologies
[20:37] <tsimonq2> If that's critical for this cycle, it needs to be fixed ASAP.
[20:37] <tsimonq2> wxl, @kc2bez: ^
[20:40] -queuebot:#lubuntu-devel- New binary: lubuntu-artwork [amd64] (eoan-proposed/universe) [19.10.3] (lubuntu)
[20:40] <wxl> it's critical only in the sense that if we get bugs against cala, it's not going to pull the log in which is going to be a big PITA for triage
 currently mobile so it will be a bit if you need me to do it.
[20:47] <wxl> i'm kind of under the gun here at work (and in life in general)
 I understand that feeling. I will … try to get to it as soon as possible
[20:50] -queuebot:#lubuntu-devel- New: accepted lubuntu-artwork [amd64] (eoan-proposed) [19.10.3]
[21:18] -lugito:#lubuntu-devel- [rMANUAL926966f4fff1: Minor reword] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL926966f4fff1
[21:19] <wxl> i thought that said minor reward
[21:19] -lugito:#lubuntu-devel- [rMANUALb510016d07fe: Minor reword saying over 100 percent volume] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALb510016d07fe
[22:30] <kc2bez> wxl: @tsimonq2 https://phab.lubuntu.me/D54 is up
[22:30] -lugito:#lubuntu-devel- [Needs Review] Refresh apport-hook patch: https://phab.lubuntu.me/D54
[23:03] <wxl> lgtm @kc2bez ship it
 +1 JFDI
 Please upload
[23:11] <kc2bez> Ok. On it.
[23:12] -lugito:#lubuntu-devel- [rCALAPACKAGING24f981053cda: Refresh apport-hook patch] kc2bez (Dan Simmons) committed: https://phab.lubuntu.me/rCALAPACKAGING24f981053cda
[23:18] -queuebot:#lubuntu-devel- Unapproved: calamares (eoan-proposed/universe) [3.2.14-0ubuntu1 => 3.2.14-0ubuntu2] (lubuntu)
[23:30] -lugito:#lubuntu-devel- [rMANUAL2b3f679cbc74: Specify what kind of input] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL2b3f679cbc74
[23:32] -lugito:#lubuntu-devel- [rMANUAL2171261eeeea: Fix capitilization again] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL2171261eeeea
 @tsimonq2 wxl I noticed there's still a 'weblate' container... do we mind me blasting that with the proverbial nuke and setting up clean?
 asking on Noumeno's behalf :P
[23:46] <wxl> @teward001 i think the general consensus was that we should just hand the keys to the Global Team and let them have at it. so carte blanche for them :)
 wxl: the question was whether i nuke it or not
 but if nobody uses the weblate now I'll initiate orbital strikes :P
 i have to deploy a new firewall tomorrow at home first - i need DHCP-PD for my IPv6 delegations to work so i have to redo that side of my network as a result
 until then though
 bleh
 (after i'll deploy weblate)
[23:47] <wxl> @teward001 exterminate
 @wxl [<wxl> @teward001 i think the general consensus was that we should just hand the …], Then we will fill it with content. ;)


[00:07] <rbasak> jamespage: may I have your opinion on bug 1411030 please? I'm not sure an SRU is appropriate, unless there is a special need here?
[00:09] <YamakasY> ok, I can telnet to a webserver on 443 but not curl on it
[08:39] <lordievader> Good morning.
[10:06] <jamespage> zul, coreycb: bumping eventlent to 0.16.1 - new base for kilo-2
[10:09] <ktosiek> I see a strange behaviour in DNS name resolving: I want to resolve a subdomain (say, api.blah.com). host api.blah.com says "connection timed out". host -r -a api.blah.com tells me there are 2 NS records for blah.com, and show A records for those NSes in ;; ADDITIONAL SECTION
[10:09] <ktosiek> first of those IPs does, in fact, time out. But the second works
[10:09] <ktosiek> shouldn't the resolver fall through to the second one?
[10:11] <ktosiek> oh, and "dig api.blah.com" works instantly
[10:12] <ktosiek> wait, no, dig only gives me an empty result
[10:12] <ktosiek> dang it
[12:35] <coreycb> jamespage, thanks
[13:05] <coreycb> jamespage, zul:  can one of you take a look at this?  https://code.launchpad.net/~corey.bryant/ubuntu/vivid/pylibmc/enable-tests/+merge/249108
[13:17] <coreycb> zul, jamespage : and this too please: https://code.launchpad.net/~corey.bryant/ubuntu/vivid/python-nose-exclude/enable-tests/+merge/249194
[13:23] <rbasak> jamespage: opinion on bug 1411030 please?
[13:23] <rbasak> https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1411030
[13:23] <rbasak> Ceph/Apache related
[13:38] <jamespage> rbasak, hmm
[13:38] <rbasak> jamespage: will need TB approval I presume. But is this something we want to pursue?
[13:45] <jamespage> rbasak, I was aware to the switch upstream between fastcgi mods
[13:45] <jamespage> rbasak, but not of this specific requirement
[13:46] <rbasak> jamespage: other options are to require trusty-backports and put a newer Apache there, or to make users use Utopic or later, or to wait until the next LTS. I'm not sure I understand the background of which of these might be acceptable.
[13:46] <rbasak> jamespage: for example, could we make the Trusty ceph charm pull from backports?
[13:47] <jamespage> rbasak, the trouble is that upstream target 14.04 as a supported release
[13:47] <jamespage> I can understand they don't want to hold and apache fork over and above ubuntus
[13:48] <rbasak> This is where I get frustrated and rant again.
[13:48] <rbasak> They target 14.04 because it's stable, but they want to change it?
[13:48] <jamespage> rbasak, welcome to my world :-)
[13:48] <rbasak> Instead of forking, they could use trusty-backports instead.
[13:48] <coreycb> zul, jamespage: this needs a look too please: https://code.launchpad.net/~corey.bryant/ubuntu/vivid/python-elasticsearch/enable-tests/+merge/249195
[13:48] <rbasak> That should be a better option than forking in all circumstances I think.
[13:50] <rbasak> jamespage: on another note, I see that corosync migrated to vivid earlier. Is there any further testing you think we need to do?
[13:56] <coreycb> zul, jamespage: can we bump python-django to 1.7?
[13:56] <zul> ooo
[13:56] <jamespage> coreycb, zul: I did take a peek at that
[13:56] <jamespage> I think there was a requirement for a new MIR
[13:56] <jamespage> but I had an outstanding question on how we deal with pypy related packages
[13:57] <coreycb> jamespage, it's already in main, it would need a new MIR?
[13:57] <jamespage> coreycb, new dep
[13:57] <coreycb> ok
[13:58] <jamespage> python-sqlparse
[13:58] <jamespage> I have the merge from debian locally - but I ran out of time to look at the deps
[14:01] <zul> jamespage:  newer python-migrates need that as well btw
[14:39] <coreycb> zul, jamespage: good assumption that python-pip does not belong in main?
[14:39] <zul> coreycb:  hehe...yes
[14:40] <coreycb> zul, yeah, sphinxcontrib-pecanwsme has it in it's build-depends for some reason
[15:16] <jamespage> coreycb, hey - re pylibmc
[15:16] <jamespage> so - you need to run 'update-maintainer'
[15:16] <jamespage> and I'd not wrap and sort on this one
[15:16] <jamespage> it will make merging from debian harder in the future
[15:17] <coreycb> jamespage, ok
[15:17] <jamespage> coreycb, commented on MP as well
[15:20] <jamespage> coreycb, you may want to try pylibmc in a PPA - I think it needs a running memcached to work properly (tests_
[15:27] <coreycb> jamespage, ok
[15:39] <coreycb> jamespage, yeah so pylibmc tests fail in ppa build but not in my local builds
[15:49] <coreycb> jamespage, I think that must  be a false positive
[15:50] <jamespage> coreycb, do you have memcached running locally?
[15:51] <coreycb> jamespage, no and I'm running in pbuilder chroot but it doesn't actually have any test output other than "ran 21 tests ... OK"
[15:51] <jamespage> coreycb, hmm
[15:53] <jamespage> coreycb, I get
[15:53] <jamespage> Ran 21 tests in 4.066s
[15:53] <jamespage> FAILED (errors=11, failures=6)
[15:54] <coreycb> weird..
[17:21] <coreycb> zul, jamespage: I think this got lost in the shuffle, needed for juno - https://code.launchpad.net/~corey.bryant/ubuntu/utopic/python-eventlet/0.13.0-1ubuntu3.1/+merge/248960
[17:31] <jamespage> coreycb, already uploaded
[17:52] <coreycb> jamespage, thanks!
[20:02] <baggar11> Anyone know how to get the fileinfo php extension installed on 14.04?
[20:26] <Sling> baggar11: how have you tried to install it?
[20:30] <SG-PXE> would anyone be able to help me with a PXE question? i want to install ubuntu via PXE using a downloaded local CD, currently the PXE goes out on the internet and pulls from the archive site
[20:32] <Sling> baggar11: looks like this package is about 9 years old, I would strongly recommend not using it
[20:32] <Sling> its removed from current php for a reason :)
[20:33] <sarnold> hmmm, the php 'file' repository is practically the 'file' upstream these days
[20:40] <xibalba> this message is presented to me upon login: /dev/xvda1 should be checked for errors : I dont have console access to this box, how can i force a fsck on bootup?
[20:41] <Sling> xibalba: sixth field in each fstab line
[20:41] <Sling> see man fstab
[20:41] <xibalba> i found touch /forcefsck
[20:42] <xibalba> 6th field is 0
[20:42] <xibalba> i forgot what column that is
[20:43] <Sling> so give the partition you want to check a '2' so its checked, the root filesystem probably has '1'
[20:43] <Sling> this determines the order of checking
[20:43] <Sling> (1 for first one, 2 for all others)
[20:43] <Sling> 0 means never check during boot
[20:43] <xibalba> ah thats right
[20:44] <xibalba> interesting someone mentions the shutdown -F command but i didn't find it in the man page
[20:44] <Sling> as usual more than 1 road to rome :)
[20:45] <Sling> but the fstab method is pretty generic
[20:45] <xibalba> that reminded me of the road map to moscow i was looking at the other week
[20:45] <xibalba> doing a screen grab for iit
[20:47] <xibalba> http://puu.sh/fKcmz/44957686b0.png
[20:47] <Sling> :-)
[20:48] <xibalba> all roads lead to a meglomanianc named putin
[21:56] <baggar11> Sling: got any ideas on how to get the extension enabled?
[21:57] <Sling> baggar11: nope, tried for a few mins, it wont even compile manually
[21:57] <Sling> why do you want it in the first place?
[21:57] <baggar11> https://github.com/snipe/snipe-it
[22:12] <SG-PXE> would anyone be able to help me with a PXE question? i want to install ubuntu via PXE using a downloaded local CD, currently the PXE goes out on the internet and pulls from the archive site
[22:53] <YamakasY> hi guys, I have unmet dependencies when I want to install openjdk-8 using the ppa
[22:53] <YamakasY> I didn't had that yesteday
[22:53] <YamakasY> *yesterday
[22:58] <teward> !ppa | YamakasY
[22:58] <teward> keep that in mind
[22:58] <teward> (also, 'ppa' is ambiguous - you don't specify the PPA you use)
[22:59] <YamakasY> yes but for openjdk8 you need it
[22:59] <YamakasY> I don't have restricted in my repo's
[22:59] <YamakasY> I might need that
[23:00] <sarnold> why not just apt-get update && apt-get -u dist-upgrade && apt-get install openjdk-8 ?
[23:00] <YamakasY> mhh I hav restricted
[23:00] <YamakasY> because it can't ?
[23:00] <YamakasY> 8 is not in the default repo's of 14.04
[23:01] <sarnold> I thought you said you added someone's ppa with an openjdk-8 package?
[23:01] <YamakasY> yap
[23:01] <YamakasY> but I get unmet dependencies, yesterday I didn't
[23:03] <YamakasY> so I wonder
[23:05] <YamakasY> is there a recommended ppa for openjdk-8 ?
[23:06] <YamakasY> I now use ppa:openjdk-r/ppa
[23:09] <YamakasY> this is what I get:  openjdk-8-jre-headless : Depends: libnss3-1d (>= 3.12.9+ckbi-1.82-0ubuntu4) but it is not going to be installed
[23:12] <YamakasY> I hate this, why is Ubuntu so far behind with java every time
[23:12] <jpds> YamakasY: Because Oracle refuse to allow others to redistribute java?
[23:13] <sarnold> YamakasY: wow, that doesn't look like it's been updated since september. there've been dozens of security issues found in java since then...
[23:13] <sarnold> https://launchpad.net/~openjdk-r/+archive/ubuntu/ppa
[23:14] <YamakasY> jpds: yeah oracle sucks
[23:14] <YamakasY> sarnold: mhh
[23:14] <YamakasY> ok need to to find a better ppa!
[23:16] <YamakasY> sarnold: all are do damn old
[23:16] <sarnold> YamakasY: you might have to deal with oracle's downloads directly on this one
[23:17] <YamakasY> sarnold: no found one
[23:17] <YamakasY> I want puppet :D
[23:18] <sarnold> YamakasY: http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html
[23:21] <budman> Any helpers in? Ive got an odd issue, ubuntu 12.04 or 14.04, install docker, run some containers and then reboot... The boxes hang on press s to skip or m for manual to mount /sys/fs/cgroup (then it repeats with other mounts including root etc..) eventually boots but everything is read only mode. I can livecd boot and mount the drive no issue read/write...
[23:21] <budman> what am I missing ;)
[23:23] <YamakasY> ok, this one works :D
[23:23] <YamakasY> happy installing
[23:29] <bdx> smoser: Are you around?
[23:56] <YamakasY> why does ubuntu messes up from time to time with filling up /boot with kernels


[00:08] <racarr> Nothing quite seems to destroy my focus like a cyclic dependency
[00:09] <racarr> problem...
[00:09] <racarr> when thinking in circles becomes shockingly literal :(
[02:11] <racarr> I guess the gmail migration worked because I just started getting work emails on my phone
[02:11] <racarr> *gulp*
[03:19] <kgunn> racarr: dont work all night 8am call w greyback
[07:35] <hikiko>  /j #eclipse
[07:35] <hikiko> sorry :p
[08:37] <alf__> alan_g: @fix-bug-1108715, I propose that we sent an email to the list to alert people about the name change (I have been bitten by this in the past)
[08:37] <alan_g> alf__: good idea.
[08:38] <alan_g> "the list" == mir-devel?
[08:38] <alf__> alan_g: that would be my choice
[08:45] <alan_g> alf__: looks like jenkins is going to avoid confusion - it is flaky again. :(
[09:18] <alan_g> alf__: did you see the email? (I thought I'd opted out of gmail, but I've not seen any email since the migration.)
[09:19] <alf__> alan_g: Yes (the fix-bug-1108715 email). I opted out, too.
[09:37] <alan_g> alf__: I guess opting out worked for you. My account was migrated anyway.
[09:50] <alan_g> alf__: there a couple of racarr's MPs that (to me) look fit to land - do you want to check them first?
[09:51] <alf__> alan_g: I will take a quick look. If everything is ok I will top approve.
[10:51] <alf__> hikiko: basically you will build an SDL client platform and an (unused for now) GBM client platform
[10:52] <alf__> hikiko: oops, you will build an SDL *server* platform
[10:52] <hikiko> yes that's what O a, doing
[10:52] <hikiko> I am*
[10:52] <hikiko> and it works
[10:52] <hikiko> the prob is
[10:52] <hikiko> in the client
[10:52] <hikiko> where I have to do the same
[10:52] <hikiko> and I wonder
[10:52] <hikiko> if I have to implement an sdl_client_platform
[10:52] <hikiko> and use the gbm for buffers
[10:53] <hikiko> as I do in the server
[10:53] <hikiko> or
[10:53] <hikiko> use the gbm as it is
[10:53] <hikiko> (add the sdl platform only in CMakeLists as you suggested)
[10:53] <hikiko> I think I ll try first what you suggest
[10:53] <hikiko> which is the simplest
[10:54] <hikiko> and if it doesn't work i will do a dummy implementation
[10:54] <hikiko> just to have the client compiling without the vt complains :)
[10:55] <alf__> hikiko: It's possible that you will be able to just use the gbm platform, but that's for the future. For now just try to compile the gbm client platform (check libraries/includes).
[10:55] <alf__> hikiko: Can you pastebin the build errors you are getting?
[10:56] <hikiko> if i don't change anything at the client
[10:56] <hikiko> i don't get any build errors
[10:56] <hikiko> but I have runtime errors
[10:57] <hikiko> wait a moment because now I have changed the branch
[11:01] <hikiko> alf__, I'll try what you said and if I get any build errors I will paste you the output I ll ping you later :)
[11:06] <alf__> hikiko: sure, thanks
[11:08] <alf__> hikiko: also ensure that you are using the right (the ones you build in the tree) render_to_fb and libmirserver, and not the ones in the system path e.g. /usr/(local/)...
[11:09] <alf__> hikiko: if it is a runtime error you are getting, it maybe that you are using a libmirserver that still uses a gbm server platform
[11:11] <hikiko> yes, that's what I told you that was happening initially, I was using the gbm_platform when I compiled the gbm client library,
[11:12] <hikiko> I implemented an sdl dummy client platform
[11:12] <hikiko> because there's a function that returns
[11:12] <hikiko> which platform to use
[11:13] <hikiko> anyway, let me try and I ll come back to you later
[11:20] <alf__> hikiko: There may be a misunderstanding here. The client platform shouldn't be a problem at runtime in any case (libmirclient is not used by render_to_fb). I am saying that you should check that at runtime you are using a *libmirserver.so* built with the right *server* platform (i.e. the one you built in your sdl tree)
[11:21] <hikiko> oh
[11:21] <hikiko> I see
[11:21] <hikiko> hmmm and if not then how can i change this?
[13:08] <alf__> status: Investigated stress test crash, proposed fix+test MP
[14:49] <racarr> Morning
[14:49] <alan_g> Afternoon
[15:06] <racarr> kgunn: I there a hangout?
[15:06] <racarr> I joined the one in the calendar but no one is there
[15:06] <kgunn> https://plus.google.com/hangouts/_/e1a9426c9efc173c7ab60b17323aafbf56b9ae06
[15:06] <kgunn> kdub: ^
[15:19] <racarr> alan_g|tea: Have a few minutes?
[15:20] <alan_g> racarr: sure. What's up?
[15:21] <racarr> alan_g: I have been working on this branch...
[15:22] <racarr> step 1. Move input fds to ms::Surfaces, refactor a bunch of the input classes in this process.
[15:23] <racarr> 2. Port InputDispatcher to use an InputTargetEnumerator (rather than this setInputWindows stuff copying the stack)
[15:23] <racarr> I guess, the thought is. It's a huge branch, and I feel like you will end up reviewing it since you have seen the most of the input stuff
[15:24] <racarr> do you want one giant diff or should I split it in to sequenced branches, even if they don't necesarily make sense by themselves (like there is no acceptance test motivating 1)
[15:25] <alan_g> I guess the two steps are likely easier follow.
[15:26] <racarr> ok
[15:28] <racarr> alan_g:
[15:28] <racarr> Want to talk about options too?
[15:30] <alan_g> racarr: real options? http://www.infoq.com/articles/real-options-enhance-agility
[15:34] <racarr> alan_g: Let me learn :p just a sec
[15:34] <alan_g> racarr: sorry, didn't mean to distract you. What do you want to talk about?
[15:35] <racarr> alan_g: Haha no, interesting. In the language of that article I would call what I am talking about settings
[15:35] <racarr> or something instead
[15:35] <racarr> alan_g: There are lots of little input setting, like
[15:36] <racarr> various mouse acceleration coeffecients, key repeat rate,
[15:36] <racarr> key layout, etc
[15:36] <racarr> that I want to expose. But I don't want
[15:36] <racarr> well. I think they will be a lot of noise in default_server_configuration.cpp
[15:37] <racarr> and it doesn't really seem like they belong in --help
[15:37] <racarr> so I am trying to figure out how to add some hierarchy to the option system
[15:38] <alan_g> racarr: It's been a while since I looked at the boost.Options docs. I don't remember much hierarchy
[15:39] <racarr> alan_g: There isn't any really
[15:39] <alan_g> racarr: do you need them on the command-line or would having them only in env or config file be OK?
[15:40] <racarr> alan_g: I think env and config file only is perhaps preferable
[15:40] <racarr> so I thought of trying to use another instance of program options
[15:40] <alan_g> racarr: that's supported by the boost stuff (but we don't use it yet)
[15:40] <racarr> but there is lots of coupling with DefaultServerConfiguration
[15:40] <racarr> alan_g: Well the thing is I don't want to shove them all in the main
[15:40] <racarr> options lists.
[15:41] <racarr> because right now, say maybe there are 5 or 6 of them
[15:41] <racarr> but I think it could quickly get out of control
[15:42] <alan_g> so you think it is time to do something cleverer?
[15:43] <racarr> I think so?
[15:43] <alan_g> Well the "simplest thing that might work" is just to add them to what we have. We can rework after.
[15:43] <racarr> maybe its not, maybe its enough to have like, mir::DefaultServerConfiguration::the_input_options, that calls something like mi::create_options and then uses the same parse enviroment as in DefaultServerConfiguration
[15:44] <racarr> Mm. That's true
[15:44] <racarr> maybe I should just do that
[15:44] <racarr> the only two I really care about is key repeat and pointer acceleration
[15:46] <alan_g> racarr: you can also do stuff like --input-params key-repeat=2,pointer-acceleration=100,...
[15:47]  * kdub likes that a bit better than secret config files
[15:49] <racarr> hmm
[15:49] <racarr> Seems like it's time to write a scheme interpreter
[15:50] <racarr> --input-params (defun key-repeat-function keycode....
[15:50] <racarr> :p
[15:50] <racarr> hmm that is kind of nice.
[15:50] <racarr> your suggestion not the scheme
[15:50] <alan_g> racarr: I don't see 5 or 6 more command line parameters as a problem
[15:50] <racarr> Ok :)
[15:50] <kdub> i don't mind that either
[15:52] <alan_g> kdub is in a good mood today.
[15:52] <kdub> very agreeable :)
[15:53] <racarr> XD
[17:03]  * kdub goes to work on client swapinterval0
[17:42] <racarr> so um
[17:42] <racarr> should new files
[17:42] <racarr> in 3rd_party/android-input (this question is already sounding incorrect...)
[17:42] <racarr> use mir style or android style?
[17:47] <kdub> i'd guess android, but then again
[17:48] <kdub> we've effectively forked it, so if we're transitioning everything gradually to mir style then...
[17:48] <racarr> the thing is this is a new interface to be
[17:48] <racarr> implemented by something in mir::input
[17:48] <racarr> so if I use the style it's forEach instead of for_each lol
[17:49] <racarr> kdub: Yeah that's kind of what I was thinking
[18:02] <tvoss> racarr, +1 on mir style
[18:04] <racarr> class SurfaceStack : public compositor::Renderables, public input::InputTargets
[18:04] <racarr> the tldr version of mir
[18:04] <racarr> XD
[18:13] <racarr> tvoss: Android license or GPL/LGPL?
[18:14] <racarr> I think android license...?
[18:14] <racarr> its not particularly important because it's an interface with one method, but I guess we will have to answer this at some point
[18:17] <kdub> i thought apache on most of it
[18:18] <racarr> mm but for new files
[18:18] <tvoss> racarr, ack, make it LGPL I would think ... but will check back on that
[18:18] <racarr> apache or
[18:18] <racarr> LGPL
[18:22] <tvoss> hmmm
[18:22] <racarr> It's a little hard to answer I think because
[18:22] <racarr> adding new files to 3rd_party/something
[18:23] <racarr> is a bit of a contradiction
[18:23] <tvoss> racarr, exactly
[18:25] <racarr> It would be good to talk about the long term trajectory for the input stack
[18:25] <racarr> removing setInputWindows (and then perhaps InputWindowHandle) in this way
[18:26] <racarr> it's easier to start sucking the large android side components
[18:26] <racarr> in to smaller mir side components
[18:27] <racarr> i.e. in this case, the InputDispatcher had a hidden responsibility (track and enumerate the list of input targets), so this gets sucked over to mir side. Next perhaps, you move over another responsibility (select target from list of targets) and farm this out to the shell
[18:28] <racarr> I don't know if this is what we want to do, or if we want to keep it in it's little bubble
[18:28] <racarr> and over what timescales, etc.
[18:30] <kdub> racarr, maybe we should set up a meeting to talk about it... i'm sure a lot of people would be interested
[18:30] <racarr> kdub: Hmm sounds like a good idea.
[19:08] <thomi> morning
[19:09] <kgunn> thomi!
[19:09] <thomi> o/
[19:10] <thomi> what's up in your kneck of the woods kgunn?
[19:11] <kgunn> success building phablet from scratch (which i'm sure is nothing to most people)
[19:11] <kgunn> thomi: btw, have you heard from robert A ?
[19:12] <thomi> kgunn: nope, what would I be hearing from him about?
[19:12] <kgunn> thomi: baby
[19:12] <thomi> ahhh, no
[19:12] <thomi> I haven't heard anything, sorry :)
[19:12] <kgunn> hope all is ok
[19:12] <kgunn> alf had a fix for stress test
[19:12] <thomi> sweet - any idea if it landed?
[19:13] <kgunn> i think he had you on for review :)
[19:13] <thomi> ahh sweet
[19:13] <kgunn> https://code.launchpad.net/~afrantzis/mir/fix-stress-test-crash-1183327
[19:13] <thomi> I'll take a look
[19:16] <racarr> lunch time!
[20:11] <kgunn> racarr: kdub ...i think i just merged the upstream hybris changes for n7, built an image & its actually working!
[20:11] <kgunn> hell might have frozen over...need to check :)
[20:14] <kgunn> kdub: before i proceed further are the instructions for android mir still good?
[20:14] <kdub> kgunn, should be :)
[20:14] <kdub> i might give it a try too
[20:14] <kdub> not really sure of the hwc situation on that device
[20:15] <kgunn> mmm, well, its a ics based device
[20:15] <kgunn> but ics was first rev...and jb definitely cleaned up some "back doors"
[20:16] <kdub> either way, back-up gpu composition (hwc-less fallback) worked fine when i tried it in... febuary?
[20:16] <kgunn> kdub: to be sure i half way understood it :_
[20:16] <kgunn> :)
[20:16] <kgunn> was the "nvidia_hack"
[20:16] <kgunn> the thing that you were toggling ?
[20:17] <kdub> kgunn, no
[20:17] <kgunn> hmmm
[20:18] <kdub> kgunn, its a bit deceptive... things will work until you try to have ipc clients
[20:18] <kgunn> ah
[20:18] <kgunn> so best test, load mir and see
[20:18] <kdub> yeah
[20:55] <racarr> I couldnt make in process
[20:55] <racarr> clients work
[20:56] <racarr> on 7 that is
[22:12] <bschaefer> Hmm getting a pure function call when trying to release the mir connection? Stacktrace: http://paste.ubuntu.com/5695233/
[22:12] <bschaefer> and code doing the releasing...: http://paste.ubuntu.com/5695235/
[22:30] <kgunn> kdub: wrt instructions...the cross-compile says to add ppa to get armhf....but those all fail
[22:30] <kgunn> kdub: ...and i already have a build branch of the image i'm running
[22:31] <kgunn> kdub: ring any bell?
[22:32] <kgunn> e.g. are you still relying on that package pull...or are you using armhf libs some other way
[22:51] <kdub> kgunn, still relying on the package pull
[22:51] <kdub> kgunn, you can cross compile normally from within a chroot
[22:51] <kdub> the cross compile script is just the sane way for a development work-cycle
[22:51] <kgunn> kdub: right...looking now
[22:52] <kgunn> kdub: but what's weird...if you go here http://us.archive.ubuntu.com/ubuntu/dists/quantal/universe/
[22:53] <kgunn> there's no armhf...not sure how that's working for you
[22:54] <kdub> we're on raring
[22:54] <kdub> saucy probably works too
[22:54] <kdub> kgunn, are you trying to cross compile, or compile within a chroot?
[22:54] <kgunn> yeah...sorry i was poking around
[22:54] <kgunn> cross compile
[22:55] <kgunn> i know we're on raring, i was poking around to see if they had been there on quantal or something
[22:55] <kgunn> ......arg....nvmd, found 'em
[23:02] <kdub> cool
[23:05] <kdub> hmm, cant ping launchpad
[23:06] <racarr> Whee. RUN      ] TestClientInput.multiple_clients_receive_motion_inside_windows
[23:06] <racarr> [       OK ] TestClientInput.multiple_clients_receive_motion_inside_windows (18 ms)
[23:06] <racarr> and they dn't talk back about it either :D
[23:12] <racarr> ugh
[23:12] <racarr> there is a race condition in the acceptance test (or perhaps in the actual code XD)
[23:13] <racarr> sometimes the hover exit event (this test drags the mouse over the boundary between two surfaces)
[23:13] <racarr> doesn't get emitted
[23:19] <kgunn> kdub: i feel stupid...i was confused b/c by output failures coming from regular repo's....
[23:20] <kgunn> since you add armhf to dpkg config
[23:20] <kgunn> it looks for them too there i guess....
[23:20] <kgunn> but it found the ports just fine
[23:20] <kdub> kgunn, cool :)
[23:22] <kgunn> kdub: check my head tho....so i was going to take the hybris i built & plop it into the dir where mir is looking (replacing whatever i just downloaded)
[23:22] <kgunn> in theory should work right?
[23:22] <kdub> kgunn, at link time on the host, as long as they have the same symbols, it doesn't matter
[23:23] <kdub> at runtime, the right library has to be installed into the linker search path
[23:23] <kdub> so short answer... yes :)
[23:23] <kgunn> :) right but i might not need to
[23:23] <kgunn> i get it