[02:02] Hello! I am interested in becoming an Ubuntu developer - not apps, but Ubuntu itself [02:03] 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] 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] 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] kernel, module, drivers, vms, etc* [02:24] 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] what's the equivalent for udisksctl power-off -b /dev/sdb on a machine without udisks? [03:25] none of the /sbin/eject modes seem to do the right thing === freeflyi_ is now known as freeflying [05:16] Good morning [05:17] hyperair: correct, ther is no equivalent; eject is the closest thing to it [05:50] pitti: Is a vivid machine booted with systemd expected to be able to shutdown at the moment? [05:58] RAOF: yes, of course [05:59] In a related query, what are the interesting logs when it doesn't? :) [06:00] RAOF: /usr/share/doc/systemd/README.Debian has a section "Debugging boot/shutdown problems" [06:00] 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] pitti: Ta. [06:00] RAOF: i. e. enable the debugging shell, shut down, then switch to it, and see which job is hanging [06:10] pitti: ugh really [06:10] hyperair: why "ugh"? [06:11] pitti: because there's no proper eject tool aside from udisks? [06:11] someone was asking on ##linux about usb_modeswitch [06:11] eject works fine [06:11] and i was trying to get him to manually eject it, but there wasn't udisks so... [06:11] the "power down the host controller" of udisks does even more, but it's more like a goodie than a required thing [06:11] hmm [06:11] e. g. for ipods and stuff which still warn if you merely eject [06:12] kinda odd that we don't have an actual mass-storage eject tool though [06:12] you'd think that eject would get that functionality [06:12] instead of just doing a cdrom eject [06:12] what's missing in eject? [06:12] it doesn't just cd-rom eject [06:12] it also disconnects USB sticks, SD cards and the like, but just the medium [06:12] oh yeah it does a scsi eject, which for some reason isn't the right kind of eject either [06:12] not the usb host controller [06:13] it doesn't actually do a usb disconnect, does it? [06:13] usb-modeswitch is a special case for 3G sticks and the like [06:13] yeah it is [06:13] except sometimes it doesn't work, and all that's needed is a simple udisksctl power-off [06:13] eject doesn't do an USB disconnect, no (as I said); it merely ejects the medium [06:13] that's the thing. i was kinda hoping for the usb disconnect stuff [06:14] seems to be the kind of eject that usb devices actually expect [06:14] most of them don't [06:15] ipods are pretty much the only one I know [06:15] (bbl) [06:15] hmm okay [07:01] apw, what is the status of bug 1410480? this completely breaks installing via ubiquity on Ubuntu GNOME and probably most other flavours [07:01] bug 1410480 in linux (Ubuntu) "overlayfs v1: renaming existing file uses chardev whiteout (should be symlink)" [High,In progress] https://launchpad.net/bugs/1410480 [07:01] and its alpha2 this week as well [07:02] yes, it's not flavor specific, happens for ubuntu as well [07:03] pitti, how did it get though the automated tests then? [07:04] hmm ubiquity autopilot tests havent run in 6weeks? [07:05] apparently yes, then === seb128_ is now known as seb128 === kickinz1|afk is now known as kickinz1 [07:49] good morning [08:03] 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] is it reasonable to assume Ubuntu vivid will feature QT 5.4? [08:20] hi people! [08:23] Howdy. [08:54] hi folks, quick question: I'm trying to fix 1411507 [08:54] the problem: now the version in trusty is 4.3.10-1 [08:55] since I'm the maintainer I'm preparing the debdiff with 4.3.10-1ubuntu1 rather than ubuntu0.1 as suffix [08:55] is that ok? === mthaddon` is now known as mthaddon [09:17] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [09:29] dholbach: in case you'll be reviewing xdg-utils MRs and you have any questions just lemme know! [09:30] ochosi, there is nothing for xdg-utils on http://reqorts.qa.ubuntu.com/reports/sponsoring/? [09:30] oh, i guess i need to subscribe ubuntu-sponsors on https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/xdg-utils/vivid/+activereviews [09:31] no, that shouldn't be necessary - that's just for bug reports [09:31] let me see [09:31] it's already approved, maybe that's why? [09:32] yes, but it wasn't landed [09:32] seb128, can you comment on https://code.launchpad.net/~ochosi/ubuntu/vivid/xdg-utils/drop_xserver_patch/+merge/246101? [09:32] 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] dholbach, I already did? [09:32] seb128, it wasn't landed AFAICS [09:32] dholbach, no, just approved [09:32] right [09:33] that got it off the sponsoring list [09:33] feel free to upload it [09:33] I just didn't get to it yet [09:33] what, approving? [09:33] I wasn't complaining [09:33] yes [09:33] why? [09:33] the intend was to say "it's ready to be sponsored" [09:33] I tried to point out a workflow issue [09:33] to "it has been uploaded" [09:33] thanks for that [09:33] I though that only "merged" would get it out of the list [09:34] right [09:34] 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] thanks [09:35] * ochosi apologizes if he has caused any sort of inconvenience here [09:35] sorry for the mistake, and thanks for pointing it out [09:35] ochosi, no, not at all [09:35] no worries [09:35] I just assumed that if I reviewed without having the slot for actual upload it would still be useful [09:35] I didn't get that it would get it out of the list [09:38] actually that's good to know [09:38] i'll keep that in mind too [09:38] i obviously made a similar mistake (even without having upload rights, i thought reviewing/commenting the code/MR would be useful) [09:39] 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] ochosi, no, I think it's great that you added your support for it [09:40] 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] ochosi, yes, that was perfectly fine :) [09:46] ochosi, I didn't expect the MP to fall off the radar when seb and you set it to 'Approved' [09:46] so I'm just checking if there's a good way to fix the sponsoring overview :) [09:46] sounds good :) [09:46] There's probably loads of approved-not-merged UDD branches [09:47] Laney, yes, probably [10:14] seb128, Laney, http://paste.ubuntu.com/9783833/ changed our list from 57 to 69 requests, with no xdg-utils MPs among them....... [10:14] hum [10:15] darkxst, still broken at the moment, working on it [10:16] dholbach, seems like a managable difference, do you know why xdg is missing still? [10:16] no, no idea [10:17] Laney, seb128, could it be that "review requested from " is missing on both xdg-utils MPs? [10:18] like on https://code.launchpad.net/~xnox/upstart/systemd-local-bridge/+merge/246772 for example [10:18] could be [10:18] shouldn't that be added by default though? [10:18] yeah [10:18] I think that a person takes over a team's review when they perform it [10:18] or is that because ochosi added me specifically for review? [10:19] maybe [10:19] ? [10:19] oh? [10:19] ochosi, do you remember if you changed something in the "reviewer" settings or requested a particular review from somebody? [10:19] Laney, I always thought that it was added [10:19] dholbach: yes, because i had worked with seb128 on xdg-utils merges before, i specifically requested his review [10:20] let me see what happens if I can add jodh to xnox' MP [10:20] and it's possible that brainwash (aka thaddäus tintentfisch) directly requested my review [10:20] ochosi, but did you remove the team from reviewers? [10:20] seb128: no, not actively/willingly [10:20] k [10:20] for example https://code.launchpad.net/~laney/ubuntu-system-settings/as-activation/+merge/225953 [10:20] 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] there's no team review [10:21] but I wouldn't have requested seb128 explicitly there [10:21] Laney, maybe because it's not source package branch? [10:21] s/not/no [10:21] doubt it [10:21] one sec [10:21] 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] Laney, something like that? [10:22] ahh ok [10:22] ya [10:22] which.... for https://code.launchpad.net/~thad-fisch/ubuntu/vivid/xdg-utils/lp1363540/+merge/246820 wouldn't quite explain it [10:22] it's even still in "Needs review" [10:22] if you're looking for all MPs which ubuntu-branches has a requested review on then that won't be returned [10:22] is that what the queue is doing? [10:23] Laney, yes - I think that's the only way how we can get a list of MPs [10:23] 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] rather than filing and adding a reviewer then [10:24] might be, yes [10:24] https://code.launchpad.net/~laney/ubuntu/vivid/0ad/test/+merge/246873 [10:24] review that please [10:25] * seb128 tries [10:25] ja [10:25] that replaced the team [10:25] Laney, also, https://code.launchpad.net/~seb128/gallery-app/some-translations-tweaks/+merge/246874 [10:26] 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] the team is not there, only you [10:26] that replaces the default [10:26] it's probably by design there [10:26] That's correct. === Guest67718 is now known as wgrant [10:27] right [10:27] dholbach: ubuntu-branches is default, at proposal time one can choose someone else to review (in that case ubuntu-branches is removed) [10:27] It's rather odd, but that's the way it is. [10:27] which I guess is what happened on those xdg-utils reviews [10:27] dholbach: i typically keep ubuntu-branches and add extra people, that I would like to notify [10:27] so, i should have not requested a reviewer when filing the MR but instead added one on top of the default? === wgrant is now known as Guest24387 [10:27] ochosi, correct [10:27] dholbach: however, i have the benefit of knowing plenty of relevant people to notify. [10:27] ok, good to know [10:27] 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] hum, so we don't have a good way of finding MPs which have had ubuntu-branches removed :) [10:27] ochosi, yeah, some of us learnt something today ;-) === Guest24387 is now known as wgrant_ [10:28] dholbach: apart from iterating across all open MPs..... not really [10:28] seb128: hehe, indeed. i'll see that knowledge gets passed on in the xubuntu team [10:28] Is there an API way to find all ubuntu-branches MPs which are 'Needs Review'? [10:28] ochosi, thanks [10:28] Laney, yes, that's what we're using [10:28] Laney: ubuntu-branches in which sense? [10:28] As target [10:28] As branch owner, or as reviewer? [10:28] that's what lp:ubuntu/... is an alias too, right? [10:28] to [10:29] pitti: i'm failing to create or start ubuntu-emulator on vivid, with a vivid image. [10:29] am I missing something obvious? [10:29] https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1412261 [10:29] Launchpad bug 1412261 in goget-ubuntu-touch (Ubuntu) "can't create emulator instance on vivid" [Undecided,New] [10:29] "Can't create tempfile to create emulator instance" [10:29] $ sudo ubuntu-emulator create --arch armhf --channel ubuntu-touch/devel-proposed --revision 68 vivid2 [10:30] xnox: oh, it's been ages since I tried armhf; it's utterly slow, I only use i386 (the defualt) [10:31] pitti: i386 also fails [10:31] * xnox ponders if i need to create a magic directory somewhere for it to work. [10:36] xnox: creating one again [10:36] it was working just fine until Friday, for months anyway; but maybe something broke over the weekend [10:37] xnox: do you have a full /tmp/ or anything like thatZ? === wgrant_ is now known as wgrant [10:50] dholbach, pitti do you have time for a virtualbox/trusty review? [10:50] https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1411507 [10:50] Launchpad bug 1411507 in virtualbox (Ubuntu) "virtualbox-guest-dkms 4.3.10-dfsg-1: virtualbox-guest kernel module failed to build [error: 'generic_file_aio_read' undeclared here (not in a function)]" [Undecided,New] [10:50] I fixed the bug ;) [10:51] I'll check it out in a bit [10:51] oh and BTW I added some packages here https://bugs.launchpad.net/ubuntu/+source/poedit/+bug/1408285 [10:51] Launchpad bug 1408285 in kbuild (Ubuntu) "Please sync kbuild, virtualbox and virtualbox-guest-additions-iso from debian/experimental" [Undecided,Incomplete] [10:52] (kbuild is still being worked in debian by me) [10:52] hum... ok [10:52] ubuntu-sponsors is not subscribed, let me re-add it [11:06] thanks! :) === _salem is now known as salem_ === jpds_ is now known as jpds === kickinz1 is now known as kickinz1|afk [11:54] dholbach, did you test virtualbox? :) [11:54] LocutusOfBorg1, it's taking a bit longer to set up everything with trusty [11:54] are you in a hurry? [11:56] 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] sure, take your time [11:56] so can I forget about that bug, right? (until I get some mails) [11:57] yes [11:58] wonderful thanks [11:59] 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] LocutusOfBorg1, v3.18 likely will not be backported to trusty, there will be an lts-vivid with whatever vivid has at release [12:06] (which is looking currently like it would be v3.19) [12:06] so apw the answer was "yes", but the question was "wrong" :) [12:07] I mean, somebody will have that kernel and the build failure with virtualbox then [12:07] LocutusOfBorg1, heh, very likely yes in the future, cirtainly i do already :) [12:08] do you have any ppa for it? this way I can proactively fix also that build failure :) [12:09] 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] did you try this too? [12:11] dholbach, nope I have a real machine and a virtualbox machine [12:11] I tried and it failed [12:11] chroot might not be enough ( pitti has something to say about the topic :p ) === MacSlow is now known as MacSlow|lunch [12:11] ok... how do you reproduce the issue? [12:11] try uname -a in the chroot, you will likely have the "host" kernel [12:12] of course, chroots don't have their own kernel; but you can install various linux-headers-* packages to build against [12:12] I install trusty in a VM, update the kernel, reboot with the new one and install [12:12] I found that having a VM, was easiest for testing and reproducing the issue ;) [12:13] pitti, I tried also this solution, but for some reasons I didn't investigate virtualbox-dkms was picking the wrong kernel [12:13] maybe because it does an "uname -a" to know the version to build modules against? [12:13] ah ok [12:13] yeah, probably [12:14] I think you can force the version somewhere, but again, I didn't investigate since setting up a VM takes less time :) [12:14] it might only build against the current kernel, not all instlaled linux-header-* ones [12:14] and I think makes me more confident about the issue [12:18] LocutusOfBorg1, dkms should build against the kernel version of the headers/image you are installing, not the runnnig kernel [12:18] 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] LocutusOfBorg1, or is this on upgrade of the dkms package itself [12:20] 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] dholbach, you do need to install the dkms package before the headers to get the right version build [12:21] nope apw I'm talking about virtualbox-guest-dkms [12:21] not dkms itself [12:21] in a chroot context [12:21] wonderful apw :) [12:21] 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] even in a chroot [12:22] (nvidia and fglrx do this in their postinst scripts) [12:23] tseliot, so they would, that is a postinst and 3/4 [12:24] apw: I'm not sure I follow you [12:24] (oh i was just agreeing and saying, "man that is a long postinst fragment" [12:25] apw: hah, thanks, I worked on it myself :) [12:25] tseliot, i noticed :) [12:28] 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] darkxst, i am still working the original issue in the kernel [12:38] cyphermox: upstream plasma-networkmanager dev asks when we are going to land networkmanager 1.0. will it be 15.04 or 15.10? === Malsasa_ is now known as Malsasa [12:54] do I need a MIR for clang? because the llvm source package is already in main.. [12:58] mlankhorst, if it's a binary from a source already in main, no [12:59] ok === kickinz1|afk is now known as kickinz1 [13:04] pitti: I'm getting a race when starting whoopsie on latest ubuntu-touch image (vivid) [13:04] pitti: seems it's not started by the upstart job [13:04] removed the start line from the upstart job and it still got started, which would explain the race [13:05] rsalveti: so there's something else that runs "start whoopsie"? [13:05] or service whoopsie start or whatever [13:05] pitti: from ps it's not running with -f, just get /usr/bin/whoopsie [13:05] wonder if https://launchpadlibrarian.net/195012178/whoopsie_0.2.43_0.2.44.diff.gz made any difference [13:05] right [13:05] rsalveti: oh, it could actually do [13:06] pitti, seb128 suggested there would perhaps be some dbus activation [13:06] rsalveti: I uploaded that as I started the emulator and saw the error message from init-d-script [13:06] ogra_, in fact not likely, just checked [13:06] ah, k [13:06] rsalveti: no, whoopsie doesn't listen on dbus [13:06] just wanted to carry the info along [13:06] rsalveti: so something indeed starts the init.d script [13:06] pitti: hm, what was the emulator error? [13:06] whoopsie-preference is the one which has a dbus service [13:06] pitti: yeah [13:07] rsalveti: I just saw init-d-script complaining about a malformed $DAEMON [13:07] oh, ok [13:07] but not what tried to start it [13:07] so you fixed the script and that caused the race [13:07] 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] right [13:08] the phone does have the LSB hook to divert calling /etc/init.d/whoopsie to upstart, which makes this thing even weirder [13:08] /lib/lsb/init-functions.d/01-upstart-lsb [13:09] 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] yeah [13:09] 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] maybe something is broken with that LSB hook [13:12] but guess that would cause some other bad side effects [13:12] yeah, it would mean that other init.d scripts woudl run too [13:13] I can't imagine something specifically calling the whoopsie init.d hook outside the boot process itself [13:13] i. e. /etc/rc2.d/* [13:13] s/hook/script/ [13:13] and whoopsie-preferences does not start whoopsie? [13:23] mvo: pitti could one of you approve https://code.launchpad.net/~rohangarg/synaptic/bug1375786/+merge/244005 [13:23] been over a month [13:24] 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] shadeslayer: ups, sorry, let me merge/upload [13:26] mvo: thanks alot, can we also get a SRU fix for Utopic? [13:26] would be supremely awesome [13:27] mvo: tbh I'm not entirely sure if we need 2 desktop files [13:27] http://paste.ubuntu.com/9785018/ < diff between the 2 desktop files [13:27] not sure what X-KDE-SubstituteUID is [13:28] 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] mvo: we do have a pkexec helper [13:29] mvo: just a sec, just let me use the normal file and see what happens [13:30] shadeslayer: ok [13:31] LocutusOfBorg1, I'll change the version number to 4.3.10-dfsg-1ubuntu1, ok? [13:31] apart from that it looks good to me [13:32] mvo: yeah , I'd just nuke the kde desktop file, the regular one works in Plasma 5 on vivid [13:35] cool, I will push that to vivid [13:36] mvo: thoughts about what to do for utopic ? just use the synaptic-pkexec patch? [13:38] ( Also, just throwing it out there, you probably want to remove the NotShownIn line in the regular desktop file ) [13:38] 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] shadeslayer: http://bazaar.launchpad.net/~synaptic-developers/synaptic/trunk/revision/2167 :) [13:39] mvo: I can do that [13:40] shadeslayer: great, please let me know and I can do the SRU [13:40] awesome, give me 20 mins [13:43] armhf builders all broken? [13:44] Riddell: seems to be working fine https://launchpad.net/ubuntu/+source/kio-extras/4:5.1.95-0ubuntu3/+build/6731015 [13:45] ooh they just caught up, good good [13:45] 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] cjwatson: did someone trip over a power strip :P [13:45] shadeslayer: Not as far as I know :-P [13:46] I think they're all in one chassis, aren't they? [13:46] No need for a power strip :-) [13:46] There was some scheduled power maintenance but then some systems weren't quite as dual-power as one might hope. === Malsasa_ is now known as Malsasa [13:47] And yes, the LP non-virt ARM builders are all in one chassis. [13:48] 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] shadeslayer: schroot(1) explains it in its ENVIRONMENT section (bottom) [13:51] ref environment-filter [13:51] svenx: isn't that explcitly to filter out env variables [13:51] I want to whitelist something [13:52] hm, true [13:52] the text is ambiguous [13:52] quite :) [13:54] related: https://bugs.debian.org/666274 [13:54] Debian bug 666274 in schroot "schroot complains about unknow source-root-groups config entry" [Minor,Fixed] [13:54] "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." === MacSlow|lunch is now known as MacSlow [13:58] cjwatson: i'm not going into the datacentre this time around.... i did leave a note that most things are single-power. [14:01] svenx: aha figured it out [14:01] thx [14:01] this is awesome :3 [14:04] hi everyone! Is it safe to assume that Qt 5.4 is a certainty for inclusion in Vivid? [14:08] rsalveti: ok, that indicates that something was calling it as /etc/init.d/whoopsie instead of /etc/rc2.d/S??whoopsie [14:12] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr [14:39] mvo: seems to work in utopic as well [14:39] plz go ahead and nuke it [14:41] sitter: I am landing 0.9.10 today; will get started on 1.0 right after that's done [14:44] cyphermox: awesome. do you think 1.0 is going to make it into 15.04? [14:47] 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] Would be nice to know that I am completely wrong and there are other solutions [14:48] sitter: yes [14:48] cyphermox: groovy, thanks for the info :) [15:06] * xnox ponders to switch to CIRC irc client [15:08] 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] 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] didrocks: but that means someone needs data/values for those, and then in the hw-override tarball or the android config do [15:10] xnox: yeah, it doesn't reevaluate [15:10] postinst [15:10] systemctl enable android-container@foo.bar=val1.target [15:10] systemctl enable android-container@foo.bar=val2.target [15:10] systemctl enable android-container@foo.bar=val3.target [15:10] as needed. [15:10] yeah :/ [15:10] .... adn then template the job as well.... [15:11] (btw, I would prefer android-property, as the property is accessible outside the container… but it's just a matter of taste ;)) [15:11] yeah, quite tricky… [15:11] i guess one only needs systemctl enable adb@val1.target, which should have wanted by = android-container@foo.bar=%i.target [15:12] didrocks: "android-container" is a configurable string. In the upstart job it was "upstart-local-bridge --event android-container" [15:12] ah ok, it's the parameter :) [15:12] didrocks: we can totally change the systemd unit to do "--event android-property" [15:12] well, just a suggestion, but great it's easy to change [15:12] which in systemd world means "the name of the template target" [15:12] yeah [15:13] 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] didrocks: unless come CI thing has a dump of all the "getprops" [15:13] s/come/some/ [15:13] xnox: actually, we can go the other way around, units knows what property they expect [15:14] and so, you scan the .service with WantedBy= [15:14] and only expose/enable them dynamically? [15:14] that would avoid creating tons of unwanted unit properties… [15:15] * didrocks tries to create a WantedBy= on unexisting target [15:15] didrocks: if the wanted by has the full name of the target, that one gets enabled, yes. [15:15] didrocks: that's how it currently works, it's just one cannot have a glob in it. [15:15] like what's currently used in upstart: maybe with, maybe without reason. [15:16] 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] instead of activating: a-c@a.b.c.d=foo1.target [15:16] activate: [15:17] 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] but imho that's ugly. [15:17] yeah, it is :/ [15:19] 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] templated instance .service <- 1 to 1 -> templated property instances [15:20] xnox: I don't get why you don't rather do that: [15:21] ? [15:21] adb.service -> WantedBy=a-c@adb.target [15:21] then, the bridge look at the target in systemd memory [15:21] sorry WantedBy=a-c@property=adb.target [15:21]