[00:37] <robert_ancell> infinity, heh
[07:51] <rbasak> doko: reading your email I'm not sure I follow what you want me to do wrt. regular uploads. Are you saying to hold back on them, or upload them to the landing PPA instead?
[08:00] <doko> rbasak, your choice. however not everything can go straight into the archive (e.g. symbol file changes), so this has to go to the silo, and then you have to keep track of the archive and the ppa for follow-up uploads
[08:04] <dholbach> good morning
[08:21] <seb128> hum, no barry around
[08:21] <seb128> doko, slangasek, do you know if https://launchpad.net/ubuntu/+source/python3-defaults/3.4.3-4ubuntu1 is buggy?
[08:22] <seb128> it's in wily-proposed and seems to pull python3.5 in and create build issues
[08:22] <seb128> e.g https://launchpadlibrarian.net/212160353/buildlog_ubuntu-wily-amd64.ubuntu-make_0.9_BUILDING.txt.gz
[08:22] <seb128> does it mean that python3.5 transition is actually started in wily?
[08:23] <doko> seb128, welcome to the barry show. he choose to add it to supported and then go to vacation for two weeks
[08:23] <didrocks> doko: debian/rules is pretty standard, there is nothing forcing to use all python3 versions
[08:23] <seb128> should we revert that change?
[08:23] <didrocks> https://github.com/ubuntu/ubuntu-make/blob/master/debian/rules
[08:25] <doko> seb128, well, could you try to build python3-gi?
[08:26] <seb128> no change rebuild?
[08:26] <doko> yes
[08:26] <doko> and probably it's dependencies
[08:26] <seb128> but then what's next? it means actually starting that transition in the distro?
[08:26] <doko> and maybe set up a transition tracker for it
[08:26] <seb128> where barry email stated he wanted to do that in the ppa
[08:27] <seb128> well he started in a ppa
[08:27] <seb128> we might duplicate work there then
[08:27] <doko> this guy is not a distro guy :-/
[08:28] <doko> looking at this email
[08:35] <doko> seb128, didrocks: could you do the no change upload? I'll try to get some feedback until tonight. and maybe we should set up a transition tracker. is there still an old one available?
[08:35] <doko> Laney, ^^^
[08:35] <seb128> doko, well, we could, but as said isn't that effectively starting the transition which is already being prepared in the ppa?
[08:36] <seb128> in which case I feel like we might waste work redoing things that have been prepared by barry there
[08:36] <didrocks> doko: I'm unsure I want to start the transition before we know if that was intended, I can just change ubuntu-make to dep on python3 instead of python3-all for now instead
[08:37] <didrocks> especially if we start the transition without being prepared, then, everything will start to be blocked
[08:37] <doko> well, it apparently is intended. and creating the tracker doesn't hurt
[08:38] <doko> didrocks, no, adding a supported python version doesn't block anything
[08:38] <didrocks> doko: well, it did block my package for instance here
[08:39] <doko> I have enough to do with GCC 5 currently
[08:41] <didrocks> yeah, so I propose that we don't deal with it, I'm changing my build-dep for now
[08:41] <didrocks> and we don't start a transition nobody's present being able to handle
[08:49] <Laney> doko: like this http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/view/head:/monitor/old/python3.3-4.ben ?
[08:49] <Laney> didrocks: if you change X-Python3-Versions it builds BTW
[08:49] <Laney> : 3.4
[08:50] <didrocks> Laney: yeah, but I don't want to force on one particular version
[08:50] <didrocks> Laney: that's just a hassle with each update
[08:51] <didrocks> better to only dep on python3 instead of python3-all (see my upload)
[08:51] <Laney> what does changing the build-dep do?
[08:51] <didrocks> only using the default python3
[08:51] <Laney> then you have to do something when it changes default?
[08:51] <doko> Laney, yes, this one. no, has to be -all
[08:51] <didrocks> there is no (for now) C python module built
[08:51] <didrocks> Laney: just a rebuild to change the dep
[08:51] <didrocks> (a non change rebuild)
[08:55] <Laney> doko: What do you mean by "has to be -all"?
[08:55] <Laney> doko: do you mean in is_affected?
[08:58] <Laney> there's also http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/view/head:/monitor/old/python3.4_all_dev.ben
[09:02] <doko> Laney, yes this is the one I want
[09:02] <doko> the first step
[09:02] <Laney> do you want to create a branch that I can merge?
[10:06] <dholbach> If you can: please help with reviewing/sponsoring: http://reqorts.qa.ubuntu.com/reports/sponsoring/
[10:20] <hjd> From reading https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036106.html it looks like the armel architecture was removed in raring. So I guess that means that bug 635390 could be resolved as won't fix as suggested in the comment. (The package was removed completely for a couple of releases, and when it was reintroduced in trusty it seems to have built successfully on all architectures)
[10:30] <cjwatson> hjd: done
[10:32] <hjd> cjwatson: Thanks :)
[10:52] <doko> mvo, python-apt is broken with your new apt upload to the landing 16 ppa, please could you have a look?
[11:22] <mdeslaur> @pilot in
[11:33] <roaksoax> /win/win 3
[13:28] <hallyn> mbiebl: hi, is 'dh_installinit --no-restart-on-upgrade' supposed to work right with systemd?
[13:29] <hallyn> (the lxc systemd script is being called on package reinstall)
[13:49] <hallyn> stgraber: tyhicks: I think the lxc container shutdown on upgrade is just a systemd bug...
[13:49] <hallyn> (or dh_installinit, or whatever is responsible for doing that right)
[13:49] <hallyn> (or maybe our systemd script has a line in it overriding the --no-restart-on-upgrade, i have no idea)
[13:49] <hallyn> (and pitti's not around :)
[15:17] <mdeslaur> @pilot out
[15:17] <mdeslaur> meh
[15:53] <zbenjamin> xnox: ping
[15:53] <zbenjamin> xnox: i heard you worked on upstart ? didrocks thinks you might be able to give some pointers :D
[15:54] <zbenjamin> xnox: i try to prototype a preloader to boost application startup time. The problem is the preloaded process does not have the correct PID and Mir rejects my connection
[15:54] <zbenjamin> xnox: where would be the right place to hack that?
[15:58] <xnox> zbenjamin: well. what does preloader do? and how do you invoke it?
[15:58] <xnox> and do you start it via upstart?
[15:59] <xnox> zbenjamin: what's the output of `ps' for all processes -> pastebin.
[15:59] <xnox> zbenjamin: and the output of $ initctl status, for the job/process in question.
[16:00] <xnox> zbenjamin: in practice i bet the problem is that a fork/exec is done, and upstart didn't expect it.
[16:01] <zbenjamin> xnox: it works like that:   The applauncherd is a daemon that preforks one process that preinits commonly used libraries and QML components. At the time when i want to start a click app i put :   "/usr/bin/invoker --type=qt5 applicationBinary --arg1 --arg2"  into the desktop file
[16:02] <zbenjamin> xnox: the ual then executes the invoker with requests applauncherd to load the application binary into the preloaded process (using dlopen) which then becomed the application
[16:02] <zbenjamin> becomes
[16:02] <zbenjamin> xnox: to the PID of the app that connects to Mir is not expected at all
[16:02] <zbenjamin> s/to/so
[16:03] <zbenjamin> so i get ApplicationManager REJECTED connection from app with pid 20469 as it was not launched by upstart, and no desktop_file_hint is specified
[16:03] <zbenjamin> xnox: https://github.com/nemomobile/mapplauncherd
[16:08] <xnox> zbenjamin: so pid 20469 is e.g. a pid that applauncherd forked (where e.g. applauncherd is 20468 itself)
[16:09] <zbenjamin> xnox: yeah
[16:10] <xnox> zbenjamin: horum. I think you need to (a) somehow communicate to appluancherd who you are (as in which app you are launching, e.g. one way to do that is to pass all environment variables, e.g. UPSTAR_JOB et al)
[16:10] <zbenjamin> xnox: invoker forwards all env to the preforked process
[16:11] <xnox> zbenjamin: (b) you will have to do hack up Mir/Application Manager to query applauncherd children in case matches are not found for "normal executed apps"
[16:12] <zbenjamin> xnox: hm that sounds doable
[16:12] <xnox> however, you'd need jdstrand input on this. Cause it sounds like a massive security hole. Cause e.g. we can trust the upstart view of the world, but not so much dlopened/preloaded untrusted apps that can totally change their own environment and pretend to be somebody else =/
[16:13] <xnox> zbenjamin: what is this desktop_file_hint stuff? surely your post-loaded app should be able to tell mir who it is.
[16:14] <xnox> and/or applauncherd do it in a trusted way.
[16:14] <zbenjamin> xnox: this is just for profiling atm. I talked to jdstrand already and in case this would boost application startup significantly we can look at secutiry
[16:14] <zbenjamin> xnox: does not work with desktop_file_hint :(  tried that already
[16:14] <xnox> e.g. "yo, mir, i'm applaucherd, this pid will be this thing, until crashes.", "yo, mir, this pid is now nothing", "yo, mir, this pid is now calculator."
[16:15] <zbenjamin> xnox: well every app will have a new pid of course
[16:15] <xnox> or possibly invoker will have to do that.
[16:15] <zbenjamin> that can be done yeah
[16:15] <xnox> zbenjamin: right, but there is no mapping. Previously in normal world, we start upstart job instance per app.
[16:15] <xnox> and each job instance has pid and variables describing who it is.
[16:15] <zbenjamin> xnox: hmmm, well invoker lives as long as the app
[16:16] <xnox> zbenjamin: then invoker should be proxing calls to mir, no? can it open a socket to mir & pass it to the app?
[16:17] <zbenjamin> hm not sure about that
[16:17] <xnox> e.g. poor-mans nc -U ;-)
[16:18]  * ogra_ has seen rich men use nc !
[16:18] <zbenjamin> xnox: the question is more, how to get that into Qt
[16:19] <zbenjamin> and will it hurt performance
[16:19] <xnox> zbenjamin: code in invoker to open mir socket or whatever it is, and then bind another one for the app. Tell the loaded app to use that socket to talk to mir (i think it is environmental variable controllable) and then join the two - that is "into invoker socker, goes to mir socket" and vice versa.
[16:19] <zbenjamin> oh my :D
[16:20] <ogra_> always the trivial stuff :)
[16:21] <zbenjamin> ogra_: yeah thats way too easy ;)
[16:21] <xnox> zbenjamin: well, look into application manager code and how it queries things from upstart or what not. And/or why it rejects things. And e.g. tweak it to always accept things that look like from your prefork daemon.
[16:21] <xnox> or make it query the prefork daemon to validate things.
[16:22] <xnox> zbenjamin: got to go, hope this helps.
[16:22] <xnox> zbenjamin: i always thought we should support upstart to deserialise arbitrary json into it's state machine. then one would be able to forge stuff as one would like, but alas, we only do that for re-exec =(
[16:23] <zbenjamin> xnox: :/
[16:23] <zbenjamin> xnox: thanks for the hints
[16:23] <zbenjamin> xnox: need to run as well, i'll probably ping you again tomorrow ;)
[17:07] <bdmurray> Is there a way for me to rerun the wily-adt-apport test without uploading the package again?
[17:09] <Laney> bdmurray: log in on the 'private' link
[17:10] <Laney> bdmurray: then click http://d-jenkins.ubuntu-ci:8080/job/wily-adt-apport/ here
[17:10] <Laney> erm, 'build now' there
[17:11] <bdmurray> Laney: got it, thanks