[02:02] <aeoril> Hello! I am interested in becoming an Ubuntu developer - not apps, but Ubuntu itself
[02:03] <aeoril> I have bought the book "Tanenbaum, Andrew S.; Bos, Herbert (2014-04-02). Modern Operating Systems (4th Edition). Prentice Hall. Kindle Edition." to start learning OS theory
[02:04] <aeoril> but it has lots of typos and I am not sure of how accurate it is.  I am interested in low-level stuff, like kernel, module, vm, etc.
[02:06] <aeoril> What are good resources to get a background in theory to work my way into this type of development?  I have a background in C programming in embedded real time systems and simulation systems, as well as dabbling in Unix/Linux drivers, modules, etc.
[02:07] <aeoril> kernel, module, drivers, vms, etc*
[02:24] <aeoril> Note that I am currently reading the Ubuntu documentation on development (based on the link in the topic of this channel).  My question above is more geared toward theory, architecture and design of operating systems such as one might get in a computer science curriculum
[03:24] <hyperair> what's the equivalent for udisksctl power-off -b /dev/sdb on a machine without udisks?
[03:25] <hyperair> none of the /sbin/eject modes seem to do the right thing
[05:16] <pitti> Good morning
[05:17] <pitti> hyperair: correct, ther is no equivalent; eject is the closest thing to it
[05:50] <RAOF> pitti: Is a vivid machine booted with systemd expected to be able to shutdown at the moment?
[05:58] <pitti> RAOF: yes, of course
[05:59] <RAOF> In a related query, what are the interesting logs when it doesn't? :)
[06:00] <pitti> RAOF: /usr/share/doc/systemd/README.Debian has a section "Debugging boot/shutdown problems"
[06:00] <RAOF> Also, systemd dramatically regresses boot speed for me, because it seems to want to write 0s to my 8GB swapfile in /var/cache/swapfile each boot. But that's a simple bug report.
[06:00] <RAOF> pitti: Ta.
[06:00] <pitti> RAOF: i. e. enable the debugging shell, shut down, then switch to it, and see which job is hanging
[06:10] <hyperair> pitti: ugh really
[06:10] <pitti> hyperair: why "ugh"?
[06:11] <hyperair> pitti: because there's no proper eject tool aside from udisks?
[06:11] <hyperair> someone was asking on ##linux about usb_modeswitch
[06:11] <pitti> eject works fine
[06:11] <hyperair> and i was trying to get him to manually eject it, but there wasn't udisks so...
[06:11] <pitti> the "power down the host controller" of udisks does even more, but it's more like a goodie than a required thing
[06:11] <hyperair> hmm
[06:11] <pitti> e. g. for ipods and stuff which still warn if you merely eject
[06:12] <hyperair> kinda odd that we don't have an actual mass-storage eject tool though
[06:12] <hyperair> you'd think that eject would get that functionality
[06:12] <hyperair> instead of just doing a cdrom eject
[06:12] <pitti> what's missing in eject?
[06:12] <pitti> it doesn't just cd-rom eject
[06:12] <pitti> it also disconnects USB sticks, SD cards and the like, but just the medium
[06:12] <hyperair> oh yeah it does a scsi eject, which for some reason isn't the right kind of eject either
[06:12] <pitti> not the usb host controller
[06:13] <hyperair> it doesn't actually do a usb disconnect, does it?
[06:13] <pitti> usb-modeswitch is a special case for 3G sticks and the like
[06:13] <hyperair> yeah it is
[06:13] <hyperair> except sometimes it doesn't work, and all that's needed is a simple udisksctl power-off
[06:13] <pitti> eject doesn't do an USB disconnect, no (as I said); it merely ejects the medium
[06:13] <hyperair> that's the thing. i was kinda hoping for the usb disconnect stuff
[06:14] <hyperair> seems to be the kind of eject that usb devices actually expect
[06:14] <pitti> most of them don't
[06:15] <pitti> ipods are pretty much the only one I know
[06:15] <pitti> (bbl)
[06:15] <hyperair> hmm okay
[07:01] <darkxst> apw, what is the status of bug 1410480? this completely breaks installing via ubiquity  on Ubuntu GNOME and probably most other flavours
[07:01] <darkxst> and its alpha2 this week as well
[07:02] <pitti> yes, it's not flavor specific, happens for ubuntu as well
[07:03] <darkxst> pitti, how did it get though the automated tests then?
[07:04] <darkxst> hmm ubiquity autopilot tests havent run in 6weeks?
[07:05] <pitti> apparently yes, then
[07:49] <dholbach> good morning
[08:03] <maclin> Hi,  Ubuntu Installer Team,  could someone help to review the merge request: https://code.launchpad.net/~maclin.jun/ubiquity/fix_1304410/+merge/246064
[08:11] <ngaio> is it reasonable to assume Ubuntu vivid will feature QT 5.4?
[08:20] <LocutusOfBorg1> hi people!
[08:23] <Unit193> Howdy.
[08:54] <LocutusOfBorg1> hi folks, quick question: I'm trying to fix 1411507
[08:54] <LocutusOfBorg1> the problem: now the version in trusty is 4.3.10-1
[08:55] <LocutusOfBorg1> since I'm the maintainer I'm preparing the debdiff with 4.3.10-1ubuntu1 rather than ubuntu0.1 as suffix
[08:55] <LocutusOfBorg1> is that ok?
[09:17] <dholbach> @pilot in
[09:29] <ochosi> dholbach: in case you'll be reviewing xdg-utils MRs and you have any questions just lemme know!
[09:30] <dholbach> ochosi, there is nothing for xdg-utils on http://reqorts.qa.ubuntu.com/reports/sponsoring/?
[09:30] <ochosi> oh, i guess i need to subscribe ubuntu-sponsors on https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/xdg-utils/vivid/+activereviews
[09:31] <dholbach> no, that shouldn't be necessary - that's just for bug reports
[09:31] <dholbach> let me see
[09:31] <pitti> it's already approved, maybe that's why?
[09:32] <dholbach> yes, but it wasn't landed
[09:32] <dholbach> seb128,  can you comment on https://code.launchpad.net/~ochosi/ubuntu/vivid/xdg-utils/drop_xserver_patch/+merge/246101?
[09:32] <dholbach> https://code.launchpad.net/~thad-fisch/ubuntu/vivid/xdg-utils/lp1363540/+merge/246820 was approved by ochosi (who doesn't have upload rights)
[09:32] <seb128> dholbach, I already did?
[09:32] <dholbach> seb128, it wasn't landed AFAICS
[09:32] <seb128> dholbach, no, just approved
[09:32] <dholbach> right
[09:33] <dholbach> that got it off the sponsoring list
[09:33] <seb128> feel free to upload it
[09:33] <seb128> I just didn't get to it yet
[09:33] <seb128> what, approving?
[09:33] <dholbach> I wasn't complaining
[09:33] <dholbach> yes
[09:33] <seb128> why?
[09:33] <seb128> the intend was to say "it's ready to be sponsored"
[09:33] <dholbach> I tried to point out a workflow issue
[09:33] <seb128> to "it has been uploaded"
[09:33] <seb128> thanks for that
[09:33] <seb128> I though that only "merged" would get it out of the list
[09:34] <dholbach> right
[09:34] <dholbach> I'll take a look at the sponsoring script and see what the result would look like if we had "approved" MPs on there too
[09:35] <seb128> thanks
[09:35]  * ochosi apologizes if he has caused any sort of inconvenience here
[09:35] <seb128> sorry for the mistake, and thanks for pointing it out
[09:35] <seb128> ochosi, no, not at all
[09:35] <dholbach> no worries
[09:35] <seb128> I just assumed that if I reviewed without having the slot for actual upload it would still be useful
[09:35] <seb128> I didn't get that it would get it out of the list
[09:38] <ochosi> actually that's good to know
[09:38] <ochosi> i'll keep that in mind too
[09:38] <ochosi> i obviously made a similar mistake (even without having upload rights, i thought reviewing/commenting the code/MR would be useful)
[09:39] <dholbach> I'll play around with the sponsoring script now and let you know if the world breaks, if we add 'Approved' MPs as well.
[09:39] <dholbach> ochosi, no, I think it's great that you added your support for it
[09:40] <ochosi> oh ok, so just to get the most out of this: was it ok (procedure-wise) to come here and ask the current pilot? or what could i have done differently not to disrupt your workflow
[09:45] <dholbach> ochosi, yes, that was perfectly fine :)
[09:46] <dholbach> ochosi, I didn't expect the MP to fall off the radar when seb and you set it to 'Approved'
[09:46] <dholbach> so I'm just checking if there's a good way to fix the sponsoring overview :)
[09:46] <ochosi> sounds good :)
[09:46] <Laney> There's probably loads of approved-not-merged UDD branches
[09:47] <dholbach> Laney, yes, probably
[10:14] <dholbach> seb128, Laney, http://paste.ubuntu.com/9783833/ changed our list from 57 to 69 requests, with no xdg-utils MPs among them.......
[10:14] <dholbach> hum
[10:15] <apw> darkxst, still broken at the moment, working on it
[10:16] <seb128> dholbach, seems like a managable difference, do you know why xdg is missing still?
[10:16] <dholbach> no, no idea
[10:17] <dholbach> Laney, seb128, could it be that "review requested from <ubuntu-branches or something>" is missing on both xdg-utils MPs?
[10:18] <dholbach> like on https://code.launchpad.net/~xnox/upstart/systemd-local-bridge/+merge/246772 for example
[10:18] <seb128> could be
[10:18] <seb128> shouldn't that be added by default though?
[10:18] <dholbach> yeah
[10:18] <Laney> I think that a person takes over a team's review when they perform it
[10:18] <seb128> or is that because ochosi added me specifically for review?
[10:19] <Laney> maybe
[10:19] <Laney> ?
[10:19] <seb128> oh?
[10:19] <dholbach> ochosi, do you remember if you changed something in the "reviewer" settings or requested a particular review from somebody?
[10:19] <dholbach> Laney, I always thought that it was added
[10:19] <ochosi> dholbach: yes, because i had worked with seb128 on xdg-utils merges before, i specifically requested his review
[10:20] <dholbach> let me see what happens if I can add jodh to xnox' MP
[10:20] <ochosi> and it's possible that brainwash (aka thaddäus tintentfisch) directly requested my review
[10:20] <seb128> ochosi, but did you remove the team from reviewers?
[10:20] <ochosi> seb128: no, not actively/willingly
[10:20] <seb128> k
[10:20] <Laney> for example https://code.launchpad.net/~laney/ubuntu-system-settings/as-activation/+merge/225953
[10:20] <dholbach> Laney, seb128: looks like it's added and not replacing ubuntu-branches: https://code.launchpad.net/~xnox/upstart/systemd-local-bridge/+merge/246772
[10:20] <Laney> there's no team review
[10:21] <Laney> but I wouldn't have requested seb128 explicitly there
[10:21] <dholbach> Laney, maybe because it's not source package branch?
[10:21] <dholbach> s/not/no
[10:21] <Laney> doubt it
[10:21] <Laney> one sec
[10:21] <seb128> dholbach, I think what Laney is saying is that if a member of the team does a review and set approve, launchpad considers the review done and replace the team by the reviewer
[10:22] <seb128> Laney, something like that?
[10:22] <dholbach> ahh ok
[10:22] <Laney> ya
[10:22] <dholbach> which.... for https://code.launchpad.net/~thad-fisch/ubuntu/vivid/xdg-utils/lp1363540/+merge/246820 wouldn't quite explain it
[10:22] <dholbach> it's even still in "Needs review"
[10:22] <Laney> if you're looking for all MPs which ubuntu-branches has a requested review on then that won't be returned
[10:22] <Laney> is that what the queue is doing?
[10:23] <dholbach> Laney, yes - I think that's the only way how we can get a list of MPs
[10:23] <seb128> dholbach, Laney, one other possibility is that when you file a mp and directly put the reviewer on the filing page, then it leads to not have the default reviewers added
[10:23] <seb128> rather than filing and adding a reviewer then
[10:24] <dholbach> might be, yes
[10:24] <Laney> https://code.launchpad.net/~laney/ubuntu/vivid/0ad/test/+merge/246873
[10:24] <Laney> review that please
[10:25]  * seb128 tries
[10:25] <seb128> ja
[10:25] <seb128> that replaced the team
[10:25] <seb128> Laney, also, https://code.launchpad.net/~seb128/gallery-app/some-translations-tweaks/+merge/246874
[10:26] <seb128> that's buggy but I picked one of my vcs and mp it selecting you as reviewer in the optional entry on the mp filing page
[10:26] <seb128> the team is not there, only you
[10:26] <Laney> that replaces the default
[10:26] <Laney> it's probably by design there
[10:26] <Guest67718> That's correct.
[10:27] <seb128> right
[10:27] <xnox> dholbach: ubuntu-branches is default, at proposal time one can choose someone else to review (in that case ubuntu-branches is removed)
[10:27] <wgrant> It's rather odd, but that's the way it is.
[10:27] <seb128> which I guess is what happened on those xdg-utils reviews
[10:27] <xnox> dholbach: i typically keep ubuntu-branches and add extra people, that I would like to notify
[10:27] <ochosi> so, i should have not requested a reviewer when filing the MR but instead added one on top of the default?
[10:27] <seb128> ochosi, correct
[10:27] <xnox> dholbach: however, i have the benefit of knowing plenty of relevant people to notify.
[10:27] <ochosi> ok, good to know
[10:27] <Guest24387> The field on the MP form replaces the default reviewer, and once a team member reviews it the team request is replaced with a review from that person.
[10:27] <dholbach> hum, so we don't have a good way of finding MPs which have had ubuntu-branches removed :)
[10:27] <seb128> ochosi, yeah, some of us learnt something today ;-)
[10:28] <xnox> dholbach: apart from iterating across all open MPs..... not really
[10:28] <ochosi> seb128: hehe, indeed. i'll see that knowledge gets passed on in the xubuntu team
[10:28] <Laney> Is there an API way to find all ubuntu-branches MPs which are 'Needs Review'?
[10:28] <seb128> ochosi, thanks
[10:28] <dholbach> Laney, yes, that's what we're using
[10:28] <wgrant_> Laney: ubuntu-branches in which sense?
[10:28] <Laney> As target
[10:28] <wgrant_> As branch owner, or as reviewer?
[10:28] <Laney> that's what lp:ubuntu/... is an alias too, right?
[10:28] <Laney> to
[10:29] <xnox> pitti: i'm failing to create or start ubuntu-emulator on vivid, with a vivid image.
[10:29] <xnox> am I missing something obvious?
[10:29] <xnox> https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1412261
[10:29] <xnox> "Can't create tempfile to create emulator instance"
[10:29] <xnox> $ sudo ubuntu-emulator create --arch armhf --channel ubuntu-touch/devel-proposed --revision 68 vivid2
[10:30] <pitti> xnox: oh, it's been ages since I tried armhf; it's utterly slow, I only use i386 (the defualt)
[10:31] <xnox> pitti: i386 also fails
[10:31]  * xnox ponders if i need to create a magic directory somewhere for it to work.
[10:36] <pitti> xnox: creating one again
[10:36] <pitti> it was working just fine until Friday, for months anyway; but maybe something broke over the weekend
[10:37] <pitti> xnox: do you have a full /tmp/ or anything like thatZ?
[10:50] <LocutusOfBorg1> dholbach, pitti do you have time for a virtualbox/trusty review?
[10:50] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1411507
[10:50] <LocutusOfBorg1> I fixed the bug ;)
[10:51] <dholbach> I'll check it out in a bit
[10:51] <LocutusOfBorg1> oh and BTW I added some packages here https://bugs.launchpad.net/ubuntu/+source/poedit/+bug/1408285
[10:52] <LocutusOfBorg1> (kbuild is still being worked in debian by me)
[10:52] <dholbach> hum... ok
[10:52] <dholbach> ubuntu-sponsors is not subscribed, let me re-add it
[11:06] <LocutusOfBorg1> thanks! :)
[11:54] <LocutusOfBorg1> dholbach, did you test virtualbox? :)
[11:54] <dholbach> LocutusOfBorg1, it's taking a bit longer to set up everything with trusty
[11:54] <dholbach> are you in a hurry?
[11:56] <LocutusOfBorg1> nope, just wonderinf if you were taking a look or not, sorry but I'm currently working on other 10 packages, and I forgot really soon things :)
[11:56] <dholbach> sure, take your time
[11:56] <LocutusOfBorg1> so can I forget about that bug, right? (until I get some mails)
[11:57] <dholbach> yes
[11:58] <LocutusOfBorg1> wonderful thanks
[11:59] <LocutusOfBorg1> do you think 3.18 will be backported to trusty too? just to cherry-pick something more, to step ahead the next build failure :)
[12:05] <apw> LocutusOfBorg1, v3.18 likely will not be backported to trusty, there will be an lts-vivid with whatever vivid has at release
[12:06] <apw> (which is looking currently like it would be v3.19)
[12:06] <LocutusOfBorg1> so apw the answer was "yes", but the question was "wrong" :)
[12:07] <LocutusOfBorg1> I mean, somebody will have that kernel and the build failure with virtualbox then
[12:07] <apw> LocutusOfBorg1, heh, very likely yes in the future, cirtainly i do already :)
[12:08] <LocutusOfBorg1> do you have any ppa for it? this way I can proactively fix also that build failure :)
[12:09] <dholbach> LocutusOfBorg1, so I created a trusty chroot, updated to the latest, installed virtualbox and linux-generic-lts-utopic (which has 3.16), but I don't see the issue happening......
[12:10] <dholbach> did you try this too?
[12:11] <LocutusOfBorg1> dholbach, nope I have a real machine and a virtualbox machine
[12:11] <LocutusOfBorg1> I tried and it failed
[12:11] <LocutusOfBorg1> chroot might not be enough ( pitti has something to say about the topic :p )
[12:11] <dholbach> ok... how do you reproduce the issue?
[12:11] <LocutusOfBorg1> try uname -a in the chroot, you will likely have the "host" kernel
[12:12] <pitti> of course, chroots don't have their own kernel; but you can install various linux-headers-* packages to build against
[12:12] <LocutusOfBorg1> I install trusty in a VM, update the kernel, reboot with the new one and install
[12:12] <LocutusOfBorg1> I found that having a VM, was easiest for testing and reproducing the issue ;)
[12:13] <LocutusOfBorg1> pitti, I tried also this solution, but for some reasons I didn't investigate virtualbox-dkms was picking the wrong kernel
[12:13] <LocutusOfBorg1> maybe because it does an "uname -a" to know the version to build modules against?
[12:13] <dholbach> ah ok
[12:13] <pitti> yeah, probably
[12:14] <LocutusOfBorg1> I think you can force the version somewhere, but again, I didn't investigate since setting up a VM takes less time :)
[12:14] <pitti> it might only build against the current kernel, not all instlaled linux-header-* ones
[12:14] <LocutusOfBorg1> and I think makes me more confident about the issue
[12:18] <apw> LocutusOfBorg1, dkms should build against the kernel version of the headers/image you are installing, not the runnnig kernel
[12:18] <apw> LocutusOfBorg1, that is passed into the dkms incantation, and dkms packages themsleves should not be using uname to work out the version to use
[12:20] <apw> LocutusOfBorg1, or is this on upgrade of the dkms package itself
[12:20] <LocutusOfBorg1> apw, yes, but "uname -a" was just a guess, I don't know what are they actually using, so your solution might be perfectly correct
[12:21] <apw> dholbach, you do need to install the dkms package before the headers to get the right version build
[12:21] <LocutusOfBorg1> nope apw I'm talking about virtualbox-guest-dkms
[12:21] <LocutusOfBorg1> not dkms itself
[12:21] <apw> in a chroot context
[12:21] <LocutusOfBorg1> wonderful apw :)
[12:21] <tseliot> apw, LocutusOfBorg1: if dkms packages call the right DKMS template (/usr/lib/dkms/common.postinst), they will pick up the correct kernel version
[12:22] <tseliot> even in a chroot
[12:22] <tseliot> (nvidia and fglrx do this in their postinst scripts)
[12:23] <apw> tseliot, so they would, that is a postinst and 3/4
[12:24] <tseliot> apw: I'm not sure I follow you
[12:24] <apw> (oh i was just agreeing and saying, "man that is a long postinst fragment"
[12:25] <tseliot> apw: hah, thanks, I worked on it myself :)
[12:25] <apw> tseliot, i noticed :)
[12:28] <apw> darkxst, ok ... i've just uploaded a casper change to move to proper overlay, which should avoid the overlayfs issue which is breaking live boot
[12:29] <apw> darkxst, i am still working the original issue in the kernel
[12:38] <sitter> cyphermox: upstream plasma-networkmanager dev asks when we are going to land networkmanager 1.0. will it be 15.04 or 15.10?
[12:54] <mlankhorst> do I need a MIR for clang? because the llvm source package is already in main..
[12:58] <seb128> mlankhorst, if it's a binary from a source already in main, no
[12:59] <mlankhorst> ok
[13:04] <rsalveti> pitti: I'm getting a race when starting whoopsie on latest ubuntu-touch image (vivid)
[13:04] <rsalveti> pitti: seems it's not started by the upstart job
[13:04] <rsalveti> removed the start line from the upstart job and it still got started, which would explain the race
[13:05] <pitti> rsalveti: so there's something else that runs "start whoopsie"?
[13:05] <pitti> or service whoopsie start or whatever
[13:05] <rsalveti> pitti: from ps it's not running with -f, just get /usr/bin/whoopsie
[13:05] <rsalveti> wonder if https://launchpadlibrarian.net/195012178/whoopsie_0.2.43_0.2.44.diff.gz made any difference
[13:05] <rsalveti> right
[13:05] <pitti> rsalveti: oh, it could actually do
[13:06] <ogra_> pitti, seb128 suggested there would perhaps be some dbus activation
[13:06] <pitti> rsalveti: I uploaded that as I started the emulator and saw the error message from init-d-script
[13:06] <seb128> ogra_, in fact not likely, just checked
[13:06] <ogra_> ah, k
[13:06] <pitti> rsalveti: no, whoopsie doesn't listen on dbus
[13:06] <ogra_> just wanted to carry the info along
[13:06] <pitti> rsalveti: so something indeed starts the init.d script
[13:06] <rsalveti> pitti: hm, what was the emulator error?
[13:06] <seb128> whoopsie-preference is the one which has a dbus service
[13:06] <rsalveti> pitti: yeah
[13:07] <pitti> rsalveti: I just saw init-d-script complaining about a malformed $DAEMON
[13:07] <rsalveti> oh, ok
[13:07] <pitti> but not what tried to start it
[13:07] <rsalveti> so you fixed the script and that caused the race
[13:07] <pitti> rsalveti: so, we've had the broken init.d script for ages, and indeed it's not supposed to be started in the first place
[13:07] <rsalveti> right
[13:08] <pitti> the phone does have the LSB hook to divert calling /etc/init.d/whoopsie to upstart, which makes this thing even weirder
[13:08] <pitti> /lib/lsb/init-functions.d/01-upstart-lsb
[13:09] <pitti> so, we can certainly "break" the init.d script again, or even drop it, but this might happen to other init.d scripts too
[13:09] <rsalveti> yeah
[13:09] <pitti> rsalveti: initially I thought this was just a side effect of running with systemd (which I did on Friday), I wasn't aware it also happens under upstart
[13:12] <rsalveti> maybe something is broken with that LSB hook
[13:12] <rsalveti> but guess that would cause some other bad side effects
[13:12] <pitti> yeah, it would mean that other init.d scripts woudl run too
[13:13] <pitti> I can't imagine something specifically calling the whoopsie init.d hook outside the boot process itself
[13:13] <pitti> i. e. /etc/rc2.d/*
[13:13] <pitti> s/hook/script/
[13:13] <xnox> and whoopsie-preferences does not start whoopsie?
[13:23] <shadeslayer> mvo: pitti could one of you approve https://code.launchpad.net/~rohangarg/synaptic/bug1375786/+merge/244005
[13:23] <shadeslayer> been over a month
[13:24] <rsalveti> pitti: added a debug line in /lib/lsb/init-functions.d/01-upstart-lsb and it didn't check for the whoopsie job (it did for quite a few others)
[13:25] <mvo> shadeslayer: ups, sorry, let me merge/upload
[13:26] <shadeslayer> mvo: thanks alot, can we also get a SRU fix for Utopic?
[13:26] <shadeslayer> would be supremely awesome
[13:27] <shadeslayer> mvo: tbh I'm not entirely sure if we need 2 desktop files
[13:27] <shadeslayer> http://paste.ubuntu.com/9785018/ < diff between the 2 desktop files
[13:27] <shadeslayer> not sure what X-KDE-SubstituteUID is
[13:28] <mvo> shadeslayer: I think that had the effect to start it with sudo, but I have little knowledge of kde, so if kde can use the normal file, that would rock
[13:28] <shadeslayer> mvo: we do have a pkexec helper
[13:29] <shadeslayer> mvo: just a sec, just let me use the normal file and see what happens
[13:30] <mvo> shadeslayer: ok
[13:31] <dholbach> LocutusOfBorg1, I'll change the version number to 4.3.10-dfsg-1ubuntu1, ok?
[13:31] <dholbach> apart from that it looks good to me
[13:32] <shadeslayer> mvo: yeah , I'd just nuke the kde desktop file, the regular one works in Plasma 5 on vivid
[13:35] <mvo> cool, I will push that to vivid
[13:36] <shadeslayer> mvo: thoughts about what to do for utopic ? just use the synaptic-pkexec patch?
[13:38] <shadeslayer> ( Also, just throwing it out there, you probably want to remove the NotShownIn line in the regular desktop file )
[13:38] <mvo> shadeslayer: if someone could test if dropping the synaptic-kde.desktop file (and removing the "not-show-in=kde" works for utopic as well I would prefer to also drop the file there
[13:38] <mvo> shadeslayer: http://bazaar.launchpad.net/~synaptic-developers/synaptic/trunk/revision/2167 :)
[13:39] <shadeslayer> mvo: I can do that
[13:40] <mvo> shadeslayer: great, please let me know and I can do the SRU
[13:40] <shadeslayer> awesome, give me 20 mins
[13:43] <Riddell> armhf builders all broken?
[13:44] <shadeslayer> Riddell: seems to be working fine https://launchpad.net/ubuntu/+source/kio-extras/4:5.1.95-0ubuntu3/+build/6731015
[13:45] <Riddell> ooh they just caught up, good good
[13:45] <cjwatson> Riddell: There was a power issue earlier that took them all out, but they've been back for most of an hour now.
[13:45] <shadeslayer> cjwatson: did someone trip over a power strip :P
[13:45] <cjwatson> shadeslayer: Not as far as I know :-P
[13:46] <rbasak> I think they're all in one chassis, aren't they?
[13:46] <rbasak> No need for a power strip :-)
[13:46] <cjwatson> There was some scheduled power maintenance but then some systems weren't quite as dual-power as one might hope.
[13:47] <cjwatson> And yes, the LP non-virt ARM builders are all in one chassis.
[13:48] <shadeslayer> curious, does anyone know how to pass a env var to the schroot setup scripts? I have a script that needs to read a env var that Jenkins sets
[13:51] <svenx> shadeslayer: schroot(1) explains it in its ENVIRONMENT section (bottom)
[13:51] <svenx> ref environment-filter
[13:51] <shadeslayer> svenx: isn't that explcitly to filter out env variables
[13:51] <shadeslayer> I want to whitelist something
[13:52] <svenx> hm, true
[13:52] <svenx> the text is ambiguous
[13:52] <shadeslayer> quite :)
[13:54] <svenx> related: https://bugs.debian.org/666274
[13:54] <svenx> "Arbitrary options may now be set in a chroot definition in schroot.conf.  These options are also set in the environment when running setup scripts, making this a simple means by which setup scripts may be customised without writing code."
[13:58] <xnox> cjwatson: i'm not going into the datacentre this time around.... i did leave a note that most things are single-power.
[14:01] <shadeslayer> svenx: aha figured it out
[14:01] <shadeslayer> thx
[14:01] <shadeslayer> this is awesome :3
[14:04] <ngaio> hi everyone! Is it safe to assume that Qt 5.4 is a certainty for inclusion in Vivid?
[14:08] <pitti> rsalveti: ok, that indicates that something was calling it as /etc/init.d/whoopsie instead of /etc/rc2.d/S??whoopsie
[14:12] <dholbach> @pilot out
[14:39] <shadeslayer> mvo:  seems to work in utopic as well
[14:39] <shadeslayer> plz go ahead and nuke it
[14:41] <cyphermox> sitter: I am landing 0.9.10 today; will get started on 1.0 right after that's done
[14:44] <sitter> cyphermox: awesome. do you think 1.0 is going to make it into 15.04?
[14:47] <sturmflut-work> If anybody has ideas about https://sturmflut.github.io/linux/ubuntu/2015/01/17/unprivileged-icmp-sockets-on-linux/ or https://sturmflut.github.io/linux/wireless/2015/01/19/designing-a-wifi-analyzer-app-for-ubuntu-touch/, please do let me hear them
[14:47] <sturmflut-work> Would be nice to know that I am completely wrong and there are other solutions
[14:48] <cyphermox> sitter: yes
[14:48] <sitter> cyphermox: groovy, thanks for the info :)
[15:06]  * xnox ponders to switch to CIRC irc client
[15:08] <didrocks> xnox: hey! so, on your email about systemd local bridge… I guess you will have to create virtual units for value then. (that's what I told you on the hangout on Friday, that I doubted * would work)
[15:09] <xnox> didrocks: correct, if there are virtual values in fact. cause in other places it seems like a forward-looking glob rather than a required one.
[15:10] <xnox> didrocks: but that means someone needs data/values for those, and then in the hw-override tarball or the android config do
[15:10] <didrocks> xnox: yeah, it doesn't reevaluate
[15:10] <xnox> postinst
[15:10] <xnox> systemctl enable android-container@foo.bar=val1.target
[15:10] <xnox> systemctl enable android-container@foo.bar=val2.target
[15:10] <xnox> systemctl enable android-container@foo.bar=val3.target
[15:10] <xnox> as needed.
[15:10] <didrocks> yeah :/
[15:10] <xnox> .... adn then template the job as well....
[15:11] <didrocks> (btw, I would prefer android-property, as the property is accessible outside the container… but it's just a matter of taste ;))
[15:11] <didrocks> yeah, quite tricky…
[15:11] <xnox> i guess one only needs systemctl enable adb@val1.target, which should have wanted by = android-container@foo.bar=%i.target
[15:12] <xnox> didrocks: "android-container" is a configurable string. In the upstart job it was "upstart-local-bridge --event android-container"
[15:12] <didrocks> ah ok, it's the parameter :)
[15:12] <xnox> didrocks: we can totally change the systemd unit to do "--event android-property"
[15:12] <didrocks> well, just a suggestion, but great it's easy to change
[15:12] <xnox> which in systemd world means "the name of the template target"
[15:12] <didrocks> yeah
[15:13] <xnox> didrocks: however ogra_ didn't get back to me with names of targets. And i don't have all the phones to check / test these.
[15:13] <xnox> didrocks: unless come CI thing has a dump of all the "getprops"
[15:13] <xnox> s/come/some/
[15:13] <didrocks> xnox: actually, we can go the other way around, units knows what property they expect
[15:14] <didrocks> and so, you scan the .service with WantedBy=
[15:14] <didrocks> and only expose/enable them dynamically?
[15:14] <didrocks> that would avoid creating tons of unwanted unit properties…
[15:15]  * didrocks tries to create a WantedBy= on unexisting target
[15:15] <xnox> didrocks: if the wanted by has the full name of the target, that one gets enabled, yes.
[15:15] <xnox> didrocks: that's how it currently works, it's just one cannot have a glob in it.
[15:15] <xnox> like what's currently used in upstart: maybe with, maybe without reason.
[15:16] <xnox> adbd.service should list all the wantedby's it wants to trigger on. If we need globbing, then I guess the upstart-local-bridge can
[15:16] <xnox> instead of activating: a-c@a.b.c.d=foo1.target
[15:16] <xnox> activate:
[15:17] <xnox> a-c@a.b.c.d=foo1.target a-c@a.b.c.d=foo.target a-c@a.b.c.d=.target a-c@a.b.c.target a-c@a.b.target a-c@a=foo1.target
[15:17] <xnox> but imho that's ugly.
[15:17] <didrocks> yeah, it is :/
[15:19] <xnox> i think it would be ok for, e.g. adbd.service if it needs "a-c@propery=adb[0-9]*.target" to make itself adbd@.service "WantedBy = a-c@property=adb%i.target" and do systemctl enable adbd@`seq 0 100`.service
[15:20] <xnox> templated instance .service <- 1 to 1 -> templated property instances
[15:20] <didrocks> xnox: I don't get why you don't rather do that:
[15:21] <xnox> ?
[15:21] <didrocks> adb.service -> WantedBy=a-c@adb.target
[15:21] <didrocks> then, the bridge look at the target in systemd memory
[15:21] <didrocks> sorry WantedBy=a-c@property=adb.target
[15:21] <xnox> and do the globbing on the bridge?
[15:21] <didrocks> get that it needs to fetch and monitor "property"
[15:21] <didrocks> yeah
[15:22] <didrocks> and so, create that target/start/stop it as needed
[15:22] <didrocks> that way, you only create the targets that are needed on the system
[15:22] <xnox> i'm ok to implement that, however i would adb.service then list:
[15:22]  * xnox has no systemd-escape on this machine
[15:22] <didrocks> don't worry ;)
[15:22] <didrocks> I know about it
[15:23] <xnox> WantedBy=a-c@property=adb*.target
[15:23] <xnox> where * is the systemd-escaped code.
[15:23] <didrocks> and you escape the *
[15:23] <didrocks> yeah
[15:23] <xnox> then the bridge can tell appart what should and shouldn't be globbed
[15:23] <didrocks> right
[15:23] <xnox> and it will start a-c@property=adb*.target & a-c@property=adb75.target
[15:23] <didrocks> and create and start the target
[15:24] <xnox> .... stars escaped.
[15:24] <didrocks> which will then bring the unit
[15:24] <didrocks> (sure)
[15:24] <xnox> yeah, the whole thing.
[15:24] <didrocks> not sure if the API is good to list WantedBy targets
[15:24]  * didrocks looks at what status says
[15:24] <didrocks>    Loaded: not-found (Reason: No such file or directory)
[15:24] <didrocks>    Active: inactive (dead)
[15:25] <LocutusOfBorg1> thanks dholbach
[15:25] <LocutusOfBorg1> :)
[15:25] <didrocks> not sure, status doesn't know about it even if I enabled a unit which WantedBy= against it
[15:25] <dholbach> anytime
[15:25] <xnox> didrocks: correct.
[15:25] <xnox> didrocks: that's fine.
[15:25] <xnox> didrocks: as it's not loaded, start & stop the .target, then status will know about it.
[15:26] <didrocks> xnox: right, but how would you detect those patterns then?
[15:26] <xnox> didrocks: wantedby installs a file on disk, it's static and evaluated on the the instance start.
[15:26] <didrocks> xnox: you don't want to scan /etc/systemd/system/*target.d? :)
[15:26] <xnox> didrocks: i would have hoped systemd dbus api exposes wantedby's of the units themself.
[15:27] <xnox> didrocks: a-c@property=adb*.target
[15:27] <didrocks> xnox: yeah, I hope as well. I can just tell you status (which is talking through the dbus api to systemd) doesn't know :/
[15:27] <xnox> didrocks: readonly as WantedBy = ['multi-user.target'];
[15:28] <xnox> didrocks: so with d-feet  / gdbus one can query iterate all units (e.g. adbd.service) and check theirs wantedby=a-c@
[15:28] <xnox> we do parsing of all jobs a lot in bridges.
[15:28] <didrocks> xnox: oh, we have the WantedBy fields over dbus for each units?
[15:28] <xnox> e.g. upstart-systemd-bridge & upstart-file-bridge iterates through all units and caches their start on / stop on.
[15:28] <didrocks> yeah, sounds good :)
[15:28] <xnox> to do things with file & socket events.
[15:28] <xnox> similar thing will be here.
[15:28] <didrocks> yeah
[15:29] <xnox> also will subscribe to NewUnit signal.
[15:29] <didrocks> and I guess on the android side, you have an event in the container when a property changes?
[15:29] <xnox> didrocks: there is no events  inside the android container.
[15:30] <didrocks> how do you track changes then?
[15:30] <didrocks> like I'm enabling developer mode
[15:30] <xnox> setprop -> changes shared bionic memory, we have a property-watcher daemon (bionic binary) running under android-init, that thing writes key=value pairs into the socket.
[15:31] <xnox> the socket is the one created by the upstart-local-bridge, and bind-mounted into the lxc container by lxc-android-config
[15:31] <xnox> and that's how propery changes arrive at upstart-local-bridge.
[15:31] <didrocks> ahah, tricky ;)
[15:31] <xnox> didrocks: upstart-local-bridge only listens to the container.
[15:31] <xnox> didrocks: as it's entirely android thing.
[15:32] <xnox> didrocks: ideally, we'd make systemd bionic aware and memory map android properities and expose them as native conditions.....
[15:32] <xnox> but my left half of the brain says that's crazy
[15:32] <didrocks> xnox: I guess for the transition period, reusing the local bridge is what makes more sense
[15:32] <didrocks> xnox: so, I guess we are mostly set on the solution in the least intrusive way? do you need any help on this?
[15:33] <didrocks> no hurry anyway, as Touch on systemd isn't for this cycle anyway (activation of it, we can have it nicely running in advance though :p)
[15:33] <xnox> didrocks: non-globbing bridge is in silo 0001, however i need it tested on the phone/emulator "does not explode under upstart, may do nothing under systemd"
[15:33] <xnox> didrocks: before i land it.
[15:34] <xnox> and emulator is not giving me any joy at the moment
[15:34] <didrocks> xnox: yeah, I saw that, works nicely (amd64) here, freshly created on Friday
[15:35] <xnox> didrocks: do you mind dist-upgrade with silo 1, and boot with upstart / boot with android? and verify that it generally works?
[15:36] <xnox> and e.g. you can see event with upstart-monitor when you do setprop under upstart
[15:36] <xnox> and target under systemd?
[15:36] <didrocks> xnox: can do in ~20 minutes, finishing up some plymouth stuff first
[15:36] <didrocks> will get back to you then :)
[16:18] <sturmflut-work> I'm on 15.04 and at random times a day a popup will appear, requesting me to enter my password to change my user data. The "Details" section states "Action: org.freedesktop.accounts.change-own-user-data" and "Vendor:". I have now idea where this comes from, and if I just cancel it nothing happens. Any ideas?
[16:19] <sturmflut-work> Couldn't find a matching bug report, but it seems to be the same issue as mentioned in http://askubuntu.com/questions/562355/seemingly-random-authentication-is-required-to-change-your-own-user-data
[16:22] <didrocks> xnox: after a "sudo setprop persist.sys.usb.config mtp", I see no new target with systemctl
[16:29] <xnox> didrocks: can you do that from inside android container?
[16:30] <xnox> didrocks: or for example boot emulator with upstart and "--debug" on the kernel command line and check that android events are generated with upstart
[16:30] <xnox> didrocks: are there any targets generated at all? systemctl status android-container@*.target ?
[16:30] <xnox> didrocks: possibly property watcher only works from container....
[16:31] <xnox> didrocks: i know that you can do $ socat - UNIX-CONNECT:/dev/socket/* persist.sys.usb.config=mtp
[16:31] <xnox> didrocks: maybe things explicitely echo stuff into the socket inside the android container.
[16:34] <mvo> shadeslayer: thanks,  I am very busy right now, would you mind reminding me again tomorrow if I haven't acted on this by then? sorry, work is very busy right now
[16:34] <shadeslayer> mvo: sure, I understand, it'd just be nice to have it fixed soonish, one of our downstreams has a release soon and would be nice to get it in
[16:36] <didrocks> xnox: actually, the bridge isn't started… what is supposed to start it? I don't see any upstart job doing that
[16:36] <pitti> apw: oh, "overlay" != "overlayfs" :) thanks for the casper fix/workaround!
[16:36] <pitti> apw: that avoids the weird char dev issue on renaming?
[16:36] <mvo> shadeslayer: yeah, if someone could prepare the sru diff (should be really) easy that would make it much simpler for me, a review/dput is quick for me
[16:37] <shadeslayer> mvo: sure, I can do that
[16:37] <apw> pitti, yes it should avoid it for new overlays such as those which the installer makes
[16:38] <apw> pitti, i am working on, actually testing the heck out of, a fix for the V1 support separatly from that
[16:38] <pitti> apw, the rescuer of alpha-2!
[16:39] <apw> pitti, the breaker of perhaps :)
[16:39] <apw> pitti, dunno if someone can respin something to test it sooner than tonight
[16:39] <mvo> shadeslayer: \o/
[16:39] <pitti> apw: heh -- I hope that overlay isn't an entirely new thing, but just the evolution of overlayfs?
[16:39] <xnox> didrocks: there are systemd unit and upstart job in lxc-android-config package
[16:39] <pitti> apw: the release team should be able to
[16:40] <didrocks> xnox: hum, I didn't see the upstart job, looking
[16:40] <xnox> didrocks: there is no stock upstart-job, as the user configures their own job with the required socket path & event name.
[16:40] <didrocks> xnox: I did the systemd unit in lxc-android-config, and I only started the container, (to mirror the upstart one)
[16:41] <xnox>  /etc/init/upstart-local-bridge.conf
[16:41] <xnox> and i don't see unit one sec.
[16:41] <apw> pitti, ack, have asked on #u-release ... it seems prudent to get ahead
[16:41] <pitti> apw: yes, absolutely
[16:42] <pitti> apw: it could in theory be hacked into break=casper-top, but that quickly gets tiresome
[16:42] <xnox> didrocks: and i did not upload lxc-android-config 0.215 well that's a fail.
[16:42] <didrocks> xnox: :)
[16:42] <xnox> didrocks: no idea where that upload is at now though.
[16:42] <xnox> didrocks: cause e.g. one needs upstart-bin to have local-bridge binary
[16:43] <pitti> stgraber: you are TIL for ifupdown; do you plan to merge it?
[16:43] <pitti> stgraber: if not, I'll upload it soon to provide the static-network-up counterpart for systemd
[16:43] <didrocks> xnox: works with the daemon started manually
[16:44] <pitti> stgraber: (i. e. I'll add those as a network-online.target dependency)
[16:44] <xnox> didrocks: systemd or upstart or both?
[16:44] <stgraber> pitti: merging it is on my todo but not extremely high on it at the moment
[16:44] <didrocks> xnox: systemd only for now
[16:44] <xnox> didrocks: that's cool.
[16:44] <didrocks> xnox: how do I try the upstart ones? I'm not as upstart-savy than systemd :)
[16:44] <didrocks> as you create an event
[16:45] <xnox> didrocks: sudo upstart-monitor; trigger the same way you triggered for systemd -> should see things from upstart-monitor stdou
[16:45] <xnox> didrocks: sudo upstart-monitor; trigger the same way you triggered for systemd -> should see things from upstart-monitor stdout
[16:45] <didrocks> ok :) uno memento!
[16:46] <xnox> however i think it's fine to let upstart in, and then i'll upload fixed up lxc-android-config
[16:46] <xnox> i don't have it locally anymore, so i'll have recreate
[16:47] <didrocks> xnox: hum, upstart-monitor is a gtk app?
[16:48] <didrocks> ah, it's telling it's fallbacking to cli
[16:48] <didrocks> but traceback :p
[16:48] <didrocks>     class UpstartEventsGui(Gtk.Window):
[16:48] <didrocks> NameError: name 'Gtk' is not defined
[16:48]  * didrocks edits to avoid the traceback
[16:48] <xnox> didrocks: sudo upstart-monitor -n
[16:48] <xnox> for the non-gui version
[16:49] <xnox> sorry forgot.
[16:49] <didrocks> xnox: yeah, it's puzzling that it's telling that it's fallbacking though :)
[16:49] <didrocks> even with -n, traceback
[16:49] <didrocks> so really an issue with the app/
[16:49]  * didrocks fires vi
[16:50] <xnox> didrocks: yeah..... =/
[16:51] <shadeslayer> mvo: https://launchpadlibrarian.net/195323505/patch
[16:54] <didrocks> xnox: hum, interesting, can't import Glib, despite having gir1.2-glib-2.0 installed on the phone
[16:55] <xnox> didrocks: apt-get install python -gi
[16:55] <xnox> didrocks: apt-get install python-gi
[16:55] <xnox> no?
[16:56] <didrocks> xnox: not that, you are trying to import Gtk first
[16:56] <didrocks> then, it bails out
[16:56] <didrocks> and so don't import the rest :p
[16:56]  * didrocks will do some patches to upstart-monitor :)
[16:56] <xnox> didrocks: option easier = boot emulator with "--debug" on the kernel command line
[16:56] <didrocks> xnox: too late, running ;)
[16:56] <xnox> didrocks: that your emulator console will be full of upstart events.
[16:56] <xnox> didrocks: than your emulator console will be full of upstart events.
[16:59] <didrocks> xnox: 2015-01-19 16:59:14.398513android-container SOCKET_TYPE='unix' SOCKET_VARIANT='named' CLIENT_UID='0' CLIENT_GID='0' CLIENT_PID='17531' SOCKET_PATH='/dev/socket/upstart-text-bridge' persist.sys.usb.config='mtp'
[16:59] <didrocks> \o/
[16:59] <xnox> cool.
[16:59] <didrocks> (needed to use socat, for some reason, couldn't lxc-attach to the container)
[17:00] <didrocks> xnox: so, seems to be good from my limited testing
[17:00] <xnox> didrocks: lxc-attach does not quite work on the android container - it's rootfs is unpacked into private tmpfs, which one cannot get into.
[17:00] <xnox> didrocks: so now i need to figure out which buttons to push for release.
[17:00] <didrocks> xnox: yeah, when I saw the "couldn't access to <mount point>", I reckoned that was the case :)
[17:00] <didrocks> xnox: ahah, I guess the publish one ;)
[17:00] <didrocks> or ask on #ubuntu-ci-eng
[17:01] <didrocks> xnox: so, filtering and globbing for the longer term solution, but seems like a nice step forward!
[17:01] <xnox> didrocks: well if https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/75/ fails then i'll ask stuff
[17:02] <xnox> Finished: SUCCESS
[17:02] <didrocks> sweet
[17:02] <xnox> looking good http://people.canonical.com/~platform/citrain_dashboard//#?distro=ubuntu&q=landing-001
[17:04]  * didrocks waves good evening
[17:10] <xnox> slangasek: looks like you are admin of ~ci-train-ppa-service can I get added to that team, such that I can dput packages into silos that are assigned to me?
[17:25] <LocutusOfBorg1> mdeslaur, hi, do you plan to merge openssl?
[17:25] <LocutusOfBorg1> I think we can almost drop all, since debian merged some ubuntu stuff
[17:38] <mdeslaur> LocutusOfBorg1: no, I'm waiting for when W opens
[17:39] <mdeslaur> LocutusOfBorg1: there are regressions and big changes in the current debian versions that I don't want for V
[17:39] <LocutusOfBorg1> ack, thanks for the reply! so I won't touch anything
[17:39] <LocutusOfBorg1> wonderful :)
[17:59] <apw> pitti, ok, a respin looks good, booted and installed ok here, so i think we are good should there be a milestone
[18:41] <Laney> cjwatson / someone else: could you moderate my mail to u-d-a please? The one with the correct subject line spelling, not the other one. :)
[18:41] <Laney> Oh right, I can cancel it can't I
[19:09] <rsalveti> xnox: hey, mind updating lp:ubuntu/upstart with the content from the latest version that got uploaded?
[19:09] <rsalveti> seem to be https://code.launchpad.net/~xnox/upstart/systemd-local-bridge/+merge/246772, but there is a conflict in there
[19:34] <asac> cjwatson: do you know if its normal that sshd doesnt start if one of the host keys referenced in /etc/ssh/sshd+_config is not avail?
[19:34] <asac> wonder because seems we gen these ed2... keys in openssh serer
[19:34] <asac> but seems that cloud-init doesnt generate them :/
[19:34] <asac> e.g. in code they only generate three
[19:35] <asac> so wonder how noone coudl have noticed and suspect there is a flag i am missing that will make sshd start ignoring that missing key
[19:35] <asac> seems you landed that key in trusty a year ago :)
[19:35] <asac> anyone else? :)
[19:36] <asac> kirkland: you around?
[20:46] <cjwatson> asac: not at a proper computer right now, but from what I can make out from browsing sshd.c on my phone, that should result in an error being logged but the server otherwise continuing to start up fine, as long as you have *some* protocol-2-suitable host key available.  this is not behaviour governed by any flag as far as I can see.  I would need to see logs to tell you any more.
[20:47] <cjwatson> Laney: done