[04:49] <pitti> Good morning
[04:56] <pitti> rbasak: FYI, new apache seems to cause some regressions: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apache2
[06:34] <pitti> rbasak: it seems to break redmine too: https://jenkins.qa.ubuntu.com/job/vivid-adt-redmine/6
[07:57] <dholbach> good morning
[08:58]  * smb notes that it looks like some google API shutdown may have broken current xul-ext-lightning (at least all my gcalendars stopped working as of yesterday which seems to match some info on the lightning support page)
[09:59] <seb128> wgrant, hey, any news on the vivid translations opening?
[10:58] <xnox> jdstrand: anything i can do to progress bug #1388889 ?
[11:11] <ypwong> cjwatson, hey, could you suggest who is the best one to give some hints on bug 1330410 ?
[11:18] <cjwatson> ypwong: I don't know, sorry
[11:20] <cjwatson> ypwong: I mean it's probably me but I'm not at all sure I have time in the remaining few weeks I have on Foundations.  Ask slangasek, and maybe he'll bounce it back to me or maybe he can find somebody else?
[11:25] <ypwong> cjwatson, okay, I will try to rebuild the package in a utopic chroot and see if I can reproduce it
[12:20] <ogra_> pitti, so i'm playing with this emergency remount stuff in adbd (by echoing u into systq-trigger) ... sadly i notice that the process issuing the reboot alredy dropped privs ... which means it runs as phablet ... do you thinkit would be overly evil to have /proc/sysrq-trigger owned by the phablet group ?
[12:25] <tkamppeter> I need some help for Python. I want to switch system-config-printer to use Python3. Problem is that on a system with both Python2 and Python3 iot always builds for Python2. Is there a way to force building for Python3?
[12:26] <doko> tkamppeter, wasn't that already switched? I remember some discussion with pitti
[12:29] <didrocks> mvo: small question regarding bug #1387090, did you get a tmpfs ro mount for /etc/machine-id once you reboot with your workaround to truncate the file?
[12:33] <tkamppeter> doko, sorry I mean hplip, not s-c-p.
[12:33] <doko> ahh
[12:34] <doko> tkamppeter, do you have a test package?
[12:34] <tkamppeter> doko, the problem is that there is no appropriate option in the ./configure script, like "--with-python3" or similar.
[12:35] <doko> tkamppeter, should I look at the current package in vivid then?
[12:35] <mardy> tedg: hi! I've started using the launcher for the helper: http://bazaar.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/click-plugins/view/head:/online-accounts-service/ui-proxy.cpp#L274
[12:36] <mardy> tedg: how can I monitor the new process, and be notified when it ends?
[12:38] <tkamppeter> doko, I can send my test package, packaging is as the current one, but the upstream source I got as a beta version from HP, which cannot be published. The beta version is language-wise converted to be Python3 compatible, so that it works on Python3-only systems using Python3, but on systems with both it seems always to default to using the system default.
[12:40] <doko> tkamppeter, try PYTHON=python3. it is using AC_ARG_VAR to get this value
[12:43] <tkamppeter> doko, thanks, will try.
[12:43] <tkamppeter> doko, and how do I get the PYTHON_DEFAULT_VERSION and PYTHON_SITENAME variables correct?
[12:46] <doko> $ py3versions -dv
[12:46] <doko> 3.4
[12:46] <doko> tkamppeter, ^^^
[12:47] <tkamppeter> doko, thanks.
[12:55] <mvo> didrocks: yeah, I get a new mount with a valid machine-id
[12:56] <tkamppeter> doko, I get
[12:56] <tkamppeter> dpkg-gencontrol: warning: Depends field of package hplip-gui: unknown substitution variable ${python3:Depends}
[12:56] <tkamppeter> what do I need to change for this?
[12:57] <doko> tkamppeter, sorry, this is too unspecific
[13:01] <didrocks> mvo: but this mount is using tmpfs, right?
[13:02] <tkamppeter> doko, thank you very much. Now I can build the package as native Python3 package, hp-systray and hp-setup work as Python3 programs.
[13:04] <mvo> didrocks: yeah
[13:05] <didrocks> mvo: ok, the behavior is coherent with what I see at least, thanks!
[13:16] <mvo> didrocks: yw
[13:18] <tkamppeter> doko, what do I have to install so that
[13:18] <tkamppeter> from dbus.mainloop.qt import DBusQtMainLoop
[13:18] <tkamppeter> works under Python3?
[13:19] <doko> tkamppeter, what did you install for Python2?
[13:22] <tkamppeter> doko, should be python-qt4-dbus.
[13:25] <tkamppeter> cjwatson, jtaylor, ScottK: Do you know which package I have to install to get the module "dbus.mainloop.qt" in Python 3?
[13:30] <cjwatson> tkamppeter: python3-dbus.mainloop.qt - could you please use apt-cache search before asking?
[13:40] <tkamppeter> cjwatson, have found it out by myself, googling.
[13:43] <tkamppeter> doko, seems that now everything is working.
[13:50] <jdstrand> xnox: no, it is in ok shape, I just need to find a bit of time to do it (it is on my list)
[14:03] <tedg> mardy, You need to register an observer: http://bazaar.launchpad.net/~indicator-applet-developers/ubuntu-app-launch/trunk.15.04/view/head:/libubuntu-app-launch/ubuntu-app-launch.h#L471
[14:03] <xnox> jdstrand: kk. It's just ideally i would like it in by alpha 1 (~3 weeks) such that both canonical and intel QA can verify and test it on wide variety of hardware and finallise before feature freeze whether or not we will be installing it by default.
[14:04] <xnox> the current plan is that it will be wonderful with no regressions or bugs(tm)
[14:04] <rbasak> pitti: I'm on it. There's at least one bug to do with ordering of module configuration which causes things to fail.
[14:04] <pitti> rbasak: ah, cheers
[14:08] <asac> anyone knows if i can hook a trigger to bip that does something if i get a highlight?
[14:10] <pitti> I don't think so, it's mostly just a relay/logging thing; seems easier to make your IRC client act on hilight?
[14:15] <ogra_> asac, yes, you can write a client :P
[14:16] <ogra_> (which can be as much as a scrip wrapper around nc or telnet that attaches in parallel to your bip)
[14:20] <asac> hmm. ok
[14:20] <asac> will come back :)
[14:20] <xnox> mdeslaur: congrats on owning 30% of changes to mountall in 2014 so far. I believe this makes you the new maintainer of mountall. =)
[14:25] <pitti> hopefully not for very long any more :)
[14:30] <caribou> what's the best way to upgrade from Utopic to the dev release ? do-release-upgrade -d ?
[14:32] <mdeslaur> xnox: I get a blanket exception from owning anything since I'm on the security team :)
[14:33] <mdeslaur> xnox: nice try though :)
[14:33] <xnox> mdeslaur: damn, i should have been in the security team.
[14:33] <mdeslaur> hehehe
[14:33] <pitti> caribou: TBH I always just s/utopic/vivid/ in /etc/apt/sources.list and "apt upgrade"
[14:33] <pitti> caribou: I think do-release-upgrade -d needs mvo or some other wizard to create some vivid meta-files first, but it doesn't hurt to try of course
[14:37] <mvo> pitti: I thought I did that
[14:37] <mvo> caribou: I think that should work
[14:38] <pitti> mvo: ah, great
[14:38]  * xnox used do-release-upgrade to get vivid
[14:38] <caribou> pitti: the only time I did that was when I started with Canonical; completely hosed my laptop & had to reinstall but it was on stable release
[14:38] <mvo> caribou: *ick*
[14:39] <caribou> mvo: pitti: back on Natty
[14:39] <sladen> perhaps it was when the bootload changed to UUID etc
[14:40] <caribou> sladen: wasn't a boot issue, but looked like many packages never upgraded correctly; I was left with a bootable laptop but no GUI
[14:43] <mardy> tedg: thanks
[14:44] <mardy> jdstrand: hi! I'm working on confining the account plugins; I'm still unsure about the apparmor implications of it
[14:45] <mardy> jdstrand: I guess that account plugins will have to ship an apparmor policy file?
[14:49] <rbasak> stgraber: feature request. lxc-stop -k should be default on ephemeral containers. Not doing so doesn't make any sense, right?
[14:55] <jdstrand> mardy: hi! before I answer that, how will you be handling the profile attachment?
[14:55]  * jdstrand suggests aa_change_onexec
[14:57] <jdstrand> (man 2 aa_change_onexec)
[15:06] <Saviq> ogra_, hey, have there been plans to unify terminal sessions between touch and desktop? (i.e. getting the upstart env etc.)
[15:06] <Saviq> it's currently so confusing when you switch between the two...
[15:06] <ogra_> Saviq, not yet, once we use proper sessions perhaps ...
[15:07] <Saviq> ogra_, "proper session"?
[15:07] <ogra_> lightdm greeter and all that
[15:08] <Saviq> we are using lightdm sessions already, are we not? just no greeter, but that == autologin?
[15:08] <ogra_> oh, wait you said terminal sessions ... :)
[15:10] <ogra_> well ... we do our best to cheat adbd into behaving as much as a real session (by forcing the upstart env and dbus envs into it on "adb shell") the prob is that adb simply behaves more like a serial terminal than a login tty
[15:13] <rbasak> mvo: around? I have dpkg-query when called from within a postinst behaving differently between sid and Vivid, even though dpkg is merged and up to date in Vivid.
[15:14] <mvo> rbasak: what is the difference?
[15:14] <rbasak> I'm just trying to find the code for your online now.
[15:15] <rbasak> mvo: the code is http://anonscm.debian.org/cgit/pkg-apache/apache2.git/diff/debian/debhelper/apache2-maintscript-helper?id=804b53b7d5901e47c2751cdf78908ccd9c594c5b
[15:15] <rbasak> mvo: "dpkg-query -f '${Status}' -W apache2|grep -q installed" doesn't work in Ubuntu, but does in Debian, it seems.
[15:15] <rbasak> mvo: I know it's dubious, but it's hard for me to submit a bug in Debian if it works there :)
[15:15] <rbasak> mvo: (note that this line is called from inside the postinst of a module package)
[15:16] <rbasak> So in Ubuntu, apache2 is configured before libapache2-mod-passenger, but libapache2-mod-passenger runs that code and thinks that apache2 isn't configured yet.
[15:17] <rbasak> I modified the binary package to add "set -x" to verify it's definitely this line that's behaving differently.
[15:17] <rbasak> I can reproduce using a direct dpkg call.
[15:17] <slangasek> xnox: what's the process for translating between boost1.55 and boost-mpi-source1.55?  There's a Debian merge to merge in and I'm averse to manual busywork ;)
[15:17] <rbasak> (installing both apache2 and libapache2-mod-passenger in the same call)
[15:24] <rbasak> mvo: ^^
[15:42] <mvo> rbasak: sorry, I'm a bit slow today, lots of stuff going on. so it might be that dpkg behaves the same but the different order of install might cause the difference in the output (or am I misreading what you wrote earlier?)
[15:47] <xnox> slangasek: i believe i got it to the point of rename boost1.55 src package & run debian/rules clean and it should do everything.
[15:47] <slangasek> xnox: ah, I like that answer, thanks :)
[15:47]  * xnox looks at changes.
[15:47] <rbasak> mvo: I accounted for the difference in order of install by calling dpkg directly with just the two packages involved, and got the same behaviour with the same configuration order.
[15:48] <xnox> slangasek: is merge actually needed? i thought we had that all applied in ubuntu already...
[15:48] <rbasak> mvo: I filed https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1393832 to track this as the explanation is a little complicated
[15:49] <xnox> slangasek: if that's not enough diff boost1.55 / boost-mpi-source1.55 - i think there are two variables in the debian/rules as well or maybe not.
[15:49] <xnox> slangasek: ah, you do want the ppc64 patch i guess.
[15:49] <slangasek> pitti: the hard-coding of paths for all commands in systemd units is hateful and wrong (and, I assert, contrary to Debian policy).  Is there a way to make this more robust?  Could we have systemd use a default path, as a distro patch if necessary?
[15:50] <slangasek> xnox: I want it to not be on my list of pending merges, whether there's anything new in Debian's version :)
[15:50] <mvo> rbasak: yeah, makes sense to file a bug
[15:50] <xnox> slangasek: lolz. ok.
[15:51] <xnox> slangasek: if grab-merge works with proxies i can do it ;-)
[15:51] <slangasek> xnox: and then you would be TIL, that would be great!
[15:51] <slangasek> ;)
[15:51] <xnox> slangasek: also it would be helpful to get https://code.launchpad.net/~xnox/launchpadlib/proxy/+merge/241176 in as well
[15:51] <xnox> without that, my hands are tied.
[15:51] <cjwatson> grab-merge is basically a fancy wget
[15:51] <xnox> hm. barry wants tests =)
[15:52]  * xnox ponders what to test in launchpadlib proxy test thing.
[15:52]  * xnox can do auto-pkg-tests cause there is proxy support there.
[15:52] <barry> xnox: :)
[15:53] <xnox> barry: would auto-pkg-tests do, or do you want unit tests?
[15:54] <xnox> proxy support is there, i only add auto-detection logic - hence i should be testing the autodetection logic?!
[15:54] <barry> xnox: dep-8 would be cool
[15:59] <rbasak> So I've filed a bug to track the issue that is preventing proposed migration.
[16:00] <rbasak> Is there any way to get that to the update_excuses page, so others can follow it?
[16:00] <rbasak> block-proposed tag, even though it isn't really for that?
[16:00] <rbasak> OTOH, maybe it does make sense, since even if the dep8 tests happen to pass, we probably still don't want to introduce the regression that the bug represents.
[16:00] <rbasak> Any opinions? Would this be abusing the tag?
[16:03] <cjwatson> Seems reasonable enough to me.
[16:03] <rbasak> Oh, one catch.
[16:03] <rbasak> It has a dpkg task. I don't want to block dpkg migration
[16:04] <rbasak> So I'd better not I guess (or delete the task).
[16:19] <pitti> slangasek: ah yeah, I'd like that too; I see little point in not using $PATH
[16:20] <slangasek> pitti: what do you think is the right way to do it?  I'm looking at a dry-run conversion of an upstart job, and was pondering EnvironmentFile=/etc/environment
[16:38] <pitti> slangasek: that would certainly work for ubuntu only units, although it's a bit ugly; but certainly more explicit than an ubuntu-only path (as these units wouldn't apply to Debian)
[16:40] <pitti> slangasek: so if we can get agreement in Debian to add a patch to support $PATH resolution of Exec=, we can at least share stuff that way
[16:41] <pitti> slangasek: does that actually work? it's not immediately clear that EnvironmentFile= is already taken into account for the Exec= binary?
[16:47] <stgraber> rbasak: so you may still want a clean shutdown if you've got a shared database or something with it as bind-mount. Also we've got semi-persistent ephemeral containers (with --keep) which you wouldn't want to kill but instead shutdown cleanly
[16:48] <didrocks> pitti: slangasek: from my tests last week that doesn't work (I tried this as well), The Environment* are only for the process env, not the systemd wrapper when executing it
[16:50] <rbasak> stgraber: fair enough I guess. I'll just have to get used to -k then.
[16:50] <rbasak> As well as -n -n -n -n :-)
[16:51] <stgraber> rbasak: :)
[16:56] <slangasek> pitti, didrocks: right - I didn't test this, was just wondering if it worked.  Obviously we wouldn't really like to have to set this in each unit anyway
[17:13] <doko> RAOF, https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1389493 please check if an empty jar helps
[17:51] <bdmurray> pitti: systemd no longer seems to produce a libudev1-dbgsym package. Do you know why?
[19:46] <bdmurray> pitti: also any news on bug 1370230?
[19:48] <Noskcaj> Laney, IS there anything in particular i should be doing for my MOTU application or do i just wait
[19:54] <Laney> Noskcaj: I pinged the others to reply with any questions
[19:55] <Noskcaj> ok
[19:56] <Laney> If we don't hear back in the next day or so we should up the pressure
[22:19] <mdeslaur> slangasek: I've figured out bug 1384502, but I'd like your opinion whether that's an upstart issue, or just needs the rpcbind package to be modified...
[22:26] <mdeslaur> slangasek: argh, I added my comment to the wrong bug, one sec
[22:26] <slangasek> mdeslaur: hmm.  1) the portmap event was meant to be for backwards-compatibility only, and nfs-utils should be fixed to not rely on it; 2) yes I think it's an upstart bug
[22:34] <mdeslaur> slangasek: thanks, I've added that to bug 1391296
[22:37] <slangasek> mdeslaur: cheers
[22:40] <wgrant> Pici: Hmm, did you approve some vivid templates?
[22:40] <wgrant> Oops
[22:40] <wgrant> pitti: ^^