[06:43] <cpaelzer> good morning
[07:14] <momken> hello
[07:14] <momken> I want to ask about "Ubuntu Make"
[07:15] <momken> I know I can install my ideas using ubuntu make
[07:15] <momken> But
[07:16] <momken> 1. What version will it install? Would it download the latest version from its site? (like from code.visualstudio.com or from jetbrains website)
[07:17] <momken> 2. Where will it install the ide?
[08:19] <pitti> jbicha: I can't any more, I left ~u-release
[09:36] <alkisg> Hi, suppose I'm both upstream and debian maintainer for software1.0, and debian is in freeze. At that point, I happen to release software2.0 upstream, and want to make it available for e.g. Ubuntu 17.04. Is it "proper" to upload this to e.g. debian experimental and sync to ubuntu from there, or is it considered as wasting debian server resources, and I'd need to upload it directly to Ubuntu?
[09:36] <pitti> alkisg: IMHO it's fine to upload to experimental and sync; some Debian users might want to use 2.0 too
[09:37] <pitti> it's very common to package newer versions in exp during freezes
[09:37] <alkisg> pitti: thank you, because we had an argument about that with the debian co-maintainer of those packages. Do you happen to have in mind some package that did that, so that I give it to him as an example?
[09:38] <pitti> alkisg: we have done, and will soon do that again for systemd
[09:39] <alkisg> Thanks a lot :)
[09:39] <pitti> alkisg: but, I don't think it's worth starting a fight over that -- if the Debian maintainer doesn't want that, just upload it to Ubuntu..
[09:40] <alkisg> I don't mind uploading to ubuntu, but the main argument is that he wants the whole debian/ dir to be frozen while debian is freezed; thus I would have to fork it to do an ubuntu release... :(
[09:40] <alkisg> (while most of the debian/ dir was written by me anyways...)
[09:45] <pitti> alkisg: that's what git branches are for..
[09:46] <pitti> alkisg: e. g. we'll (RSN) branch systemd's master as stretch and continue unstable uploads from there, and use master for packaging new versions and uploading to experimental
[09:46] <pitti> or use an experimental branch
[09:46] <pitti> (the former makes more sense IMHO, but both work and it's a matter of taste)
[09:46] <alkisg> " and use master for packaging new versions and uploading to experimental" ==> that's exactly what  I was suggesting, but he said, "no, master should be debian unstable, if you want daily builds or ubuntu releases, keep forking master whenever you need"
[09:47] <pitti> vim is better than emacs, obviously
[09:47] <alkisg> And I would hate to have to maintain a fork for software where I wrote both the code and the packaging... :(
[09:48] <pitti> it's not really much more work
[09:48] <alkisg> Yeah, it's amazing how strong opinions can come between developers for such small issues
[09:48] <pitti> after the release, rename master to stretch and rename experimental to master
[09:49] <pitti> (which I find stupid, and why I'd prefer using a stretch branch right away, but, bikeshed)
[09:50] <alkisg> Nah I think he'll just want to "backport" whatever changes I did to his "master" branch; and I'm afraid that he might leave some out, thus making a diff from debian to ubuntu, which is another thing I hate. Oh well we'll see. Thanks again for your input!
[11:50] <cult-> xnox: when it will be ok to set the label to verification-done ?
[11:50] <cult-> tag
=== hikiko is now known as hikiko|bbl
=== hikiko|bbl is now known as hikiko
=== juliank_ is now known as juliank
=== JanC is now known as Guest41946
=== JanC_ is now known as JanC
=== pitti` is now known as pitti
=== smb` is now known as smb
[20:20] <Saviq> robert_ancell, hey, about bug #1654365, what else can we do to track this down? I'm certain /etc/X11/Xsession.d is in effect as removing use-session-dbus from Xsession.options makes the problem go away
[20:20] <ubottu> bug 1654365 in ubuntu-touch-session (Ubuntu) "Session dbus lauched by /etc/X11/Xsession.d/75dbus_dbus-launch dies immediately" [Undecided,New] https://launchpad.net/bugs/1654365
[20:22] <robert_ancell> Saviq, I think you know more about this than I do. Have you asked desrt?
[20:24] <Saviq> robert_ancell, no, we got stuck at your feedback, thinking it's lightdm running the Xsession bits
[20:25] <Saviq> knowing who to talk to next is definitely helpful
[20:27] <robert_ancell> Saviq, I'm not sure who would know this best, but it probably would have been her or pitti
[20:27] <Saviq> ack, will talk to Allison tomorrow
[20:27] <Saviq> thanks
[20:27] <robert_ancell> Saviq, lightdm is launching the xsession bits, but it really has no idea what they do
[20:30] <Saviq> robert_ancell, didn't you say it shouldn't do that for Mir sessions?
[20:30] <robert_ancell> Saviq, it runs xsession regardless, with the convention being that xsession will change behaviour if appropriate if it needs to (i.e. it detects it's running in Mir instead of X)
[20:31] <Saviq> aha
[20:31] <robert_ancell> xsession is a horrible mess of old-fashioned scripts that have got more complex over the years. I'd love to get rid of this but it was too hard to do at the time.
[20:32] <Saviq> yeah I can relate
[20:33] <Saviq> so the question is, then, why is dbus-launch going away now
[20:33] <robert_ancell>  ¯\_(ツ)_/¯
[20:33] <robert_ancell> there be dragons
[20:35] <robert_ancell> Saviq, for completeness, what lightdm does is run the session command (got from the .desktop file) through /usr/sbin/lightdm-session. That's provided by the distro (i.e. debian/lightdm-session) in our case. That in turn runs the sysadmin provided scripts in Xsession.d
[20:36] <Saviq> ack, tx