| ZZambia_ | is anybody following the ubuntu touch development for MT6595 platforms, like Meizu MX4? | 00:18 |
|---|---|---|
| ZZambia_ | I would need some tech info, plz | 00:18 |
| pitti | Good morning | 05:47 |
| pitti | wgrant: no, I don't think I ever approved vivid templates, why? (just recently some RTM ones) | 05:48 |
| wgrant | pitti: Someone approved three, so there's some surgery required before I can open. But I should be able to get it done tomorrow. | 05:49 |
| pitti | wgrant: ah, thanks | 05:49 |
| pitti | wgrant: btw, can we move the RTM tarball generation? | 05:49 |
| wgrant | pitti: I was going to do that in the same step as changing the crontabs for vivid | 05:50 |
| wgrant | But that ended up blocked by the various issues. | 05:50 |
| wgrant | If I don't get it done tomorrow, I'll shift RTM anyway. | 05:50 |
| pitti | wgrant: cheers | 05:53 |
| Noskcaj | doko_, syncing libexplain should fix the ftbfs you introduced, it still ails on aarch64 though | 06:32 |
| === MasterPieceF is now known as MasterPiece | ||
| === zyga is now known as zyga-afk | ||
| dholbach | good morning | 07:46 |
| === doko_ is now known as doko | ||
| doko | Noskcaj, synced | 07:51 |
| Noskcaj | cool | 07:59 |
| ZZambia | is anybody following the ubuntu touch development for MT6595 platforms, like Meizu MX4? | 09:46 |
| ZZambia | I would need some tech info, plz | 09:46 |
| cjwatson | #ubuntu-touch would be more likely to know | 09:46 |
| cjwatson | (if anyone does) | 09:46 |
| === ara_ is now known as ara | ||
| davidcalle | doko, hello, I've been told this would be in your area of interest : https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/1394131 | 10:24 |
| ubottu | Launchpad bug 1394131 in bzr (Ubuntu) "UnicodeDecodeError on Vivid for non-ascii characters in config files" [Undecided,New] | 10:24 |
| === zyga-afk is now known as zyga | ||
| === _salem is now known as salem_ | ||
| pitti | jodh: I need to uplaod a packaging fix to upstart; there are some staged changes in bzr, do you see a reason to not upload them? | 11:40 |
| jodh | pitti: should just be that logrotate fix, so upload should be fine. | 11:42 |
| pitti | jodh: and Dmitry's upstart-sessions update (also looks ok) | 11:42 |
| pitti | jodh: ack, thanks | 11:43 |
| jodh | pitti: ah yes, that looks fine too. | 11:45 |
| GunnarHj | pitti: As regards bug #678421, is bash out of the question? | 11:48 |
| ubottu | bug 678421 in lightdm (Ubuntu Trusty) "Error message for a faulty ~/.profile script" [Low,In progress] https://launchpad.net/bugs/678421 | 11:48 |
| pitti | GunnarHj: no, not at all IMHO | 11:48 |
| pitti | GunnarHj: but your trap is also rather clever :) | 11:48 |
| pitti | jodh: I get FAIL: test_conf_preload.sh | 11:49 |
| pitti | jibel: ... when building locally in schroot; is that common/expected? | 11:49 |
| pitti | jodh: not otherwise very verbose (http://paste.ubuntu.com/9094158/) | 11:50 |
| pitti | jibel: sorry, that was meant for jodh | 11:50 |
| GunnarHj | pitti: Yeah, it gets it to ~/.xsession-errors, but doesn't alert the user via a dialog. What I found out about bash is that it automatically carries out syntax checks when sourcing, and it does so recursively. So switching to bash would allow for a really elegant solution. | 11:50 |
| pitti | GunnarHj: that, and some people (hello barry!) might also have bashisms in their scripts, too | 11:51 |
| GunnarHj | pitti: Right. | 11:51 |
| GunnarHj | pitti: Are you saying that you wouldn't object if I proposed a solution with /bin/bash in the shebang line? ;) | 11:53 |
| pitti | GunnarHj: exactly; as I said in teh bug and above, I think bash is fine | 11:54 |
| jodh | pitti: checking... | 11:54 |
| pitti | jodh: I pushed my packaging fix, but I wonder if that failure will also affect buildds | 11:54 |
| GunnarHj | pitti: Ok, thanks. Getting back with a MP then. | 11:54 |
| pitti | GunnarHj: cheers! | 11:55 |
| barry | pitti, GunnarHj: thanks! | 12:55 |
| jodh | pitti: I think the upstart failure is caused by a missing libtool binary (again). The binary seems to be in libtool-bin now. | 13:12 |
| cjwatson | jodh: You should never be using /usr/bin/libtool. Use the version that's generated as part of your build system. | 13:13 |
| cjwatson | Build-depending on libtool-bin would be the wrong fix. | 13:13 |
| cjwatson | jodh: I think you probably want something like http://paste.ubuntu.com/9095744/ | 13:14 |
| cjwatson | (untested) | 13:14 |
| jodh | cjwatson: thanks | 13:19 |
| pitti | jodh: re (sorry, was at lunch) -- so this is a proper failure then, not just on my setup? | 13:36 |
| jodh | pitti: correct, we've seen this libtool issue before but I didn't realise we shouldn't use the packaged version. I've tested + pushed a fix to lp:ubuntu/upstart if you want to retest then upload? | 13:48 |
| jodh | pitti: well, a proper failure, but not an upstart bug :) | 13:48 |
| pitti | jodh: ah, sure (oh, we use inline patching in the package?) | 13:49 |
| mardy | jdstrand: hi! About your question from yesterday, I'm using libubuntu-app-launcher to start the confined plugin | 13:56 |
| mardy | jdstrand: I didn't know about the aa_change* functions, it looks like I could have used those instead | 13:56 |
| pitti | xnox: are you already working on the lvm2 merge? I can give it an initial shot, and ask for more in-depth testing on u-devel@ otherwise | 13:57 |
| mardy | jdstrand: now the problem is that the plugin needs to connect to a unix socket, so that needs to be allowed by the policy (while if I used aa_change_profile() after connecting to it, I understand that changing the apparmor policy wouldn't have been necessary, right?) | 13:58 |
| jdstrand | mardy: I'm not sure if the policy would have to have changed there due to revalidation. perhaps sbeattie can comment | 14:00 |
| jdstrand | mardy: so, the confined plugin is running in its own process? | 14:01 |
| jdstrand | mardy: and this is a different security context from the app? who is using libubuntu-app-launcher? | 14:01 |
| mardy | jdstrand: the trusted helper (our background service, unconfined) uses libubuntu-app-launcher to start the confined plugin, which is its own process | 14:05 |
| mardy | jdstrand: to be clear, the process consists of a container we develop, which loads the plugin QML code | 14:06 |
| mardy | jdstrand: the security context is going to be different from that of the app | 14:06 |
| jdstrand | mardy: so the connection to a unix socket if for communication between the plugin and the trusted helper? | 14:07 |
| jdstrand | (as opposed to the app) | 14:07 |
| mardy | jdstrand: exactly | 14:07 |
| jdstrand | ok cool | 14:07 |
| jdstrand | so that all sounds like a fine design | 14:07 |
| jdstrand | mardy: remind me, what is the question from yesterday? | 14:07 |
| mardy | jdstrand: will account plugins have to declare an "apparmor" entry in the manifest file? | 14:08 |
| mardy | jdstrand: and how do we let them access the socket? | 14:09 |
| jdstrand | mardy: it depends on what you (as the signon developer) need them to do | 14:09 |
| jdstrand | mardy: actually, signon does not run as root | 14:10 |
| jdstrand | I was thinking we could have a sorta 'generic' profile that you could transition them to | 14:10 |
| jdstrand | while that profile would protect the system, etc, it would not isolate the plugins themselves | 14:10 |
| jdstrand | to isolate the plugins themselves, we'd need the profiles to be individually named (ie, declare an "apparmor" entry in the manifest) | 14:11 |
| jdstrand | so, we would create a separate template for them, like we did for push helpers | 14:11 |
| jdstrand | mardy: does tha make sense? | 14:12 |
| mardy | jdstrand: and then we combine the apparmor entry in the manifest with the generic plugin profile? | 14:12 |
| mardy | jdstrand: like we do the union of the two? | 14:12 |
| jdstrand | mardy: now, the template becomes the generic plugin profile, with a few plugin-specific bits sprinkled in | 14:13 |
| jdstrand | /wnow/no/ | 14:13 |
| jdstrand | meh | 14:13 |
| jdstrand | 'no' | 14:13 |
| jdstrand | :) | 14:13 |
| jdstrand | mardy: eg: /usr/share/apparmor/easyprof/templates/ubuntu/1.2/ubuntu-push-helper | 14:14 |
| jdstrand | mardy: except we call it 'ubuntu-qml-plugin' and use rules that are appropriate for it | 14:14 |
| mardy | jdstrand: I'm not sure I understand; so we have a template which just a few rules to allow connecting to the socket, and then we add any policy declared by the plugin in their manifest (like "accounts" and "network", typically)? | 14:14 |
| jdstrand | mardy: we tailor a template that will work for qml plugins in general, but use apparmor variables (like APP_PKGNAME, which is the click pkgname, or APP_APPNAME, which is the key in the hooks database) | 14:16 |
| jdstrand | for various paths so the plugins themselves are isolated | 14:17 |
| mardy | jdstrand: but will it be possible for the plugins to get more permissions? | 14:18 |
| mardy | jdstrand: I don't have any serious example in mind, but what if a hypothetical plugin wanted to use the location? | 14:18 |
| jdstrand | mardy: we can make that possible or we can make that not possible. what permissions are you thinking of? | 14:18 |
| jdstrand | mardy: the more direct answer is that policy groups are automatically supported | 14:19 |
| jdstrand | mardy: but the click-reviewers-tools can say certain ones are not allowed | 14:19 |
| mardy | jdstrand: ah, ok, that sounds perfect than | 14:19 |
| jdstrand | we would probably start by saying only networking is allowed, and anything else is flagged as 'unusual' | 14:20 |
| mardy | jdstrand: I would keep the template very minimal, and require plugins to explicitly require all their policies | 14:20 |
| jdstrand | that way we can get a feel for what people are doing | 14:20 |
| mardy | jdstrand: not all plugins even use network | 14:20 |
| jdstrand | that's fine | 14:20 |
| mardy | jdstrand: the only common thing is "accounts" | 14:20 |
| jdstrand | that's fine too | 14:20 |
| mardy | jdstrand: then many would use "network" and "webview", but I'd rather let them specify that explicitly | 14:21 |
| jdstrand | the click-reviewers-tools can make sure that if providing a qml plugin, the security policy must include accounts | 14:21 |
| jdstrand | networking is optional | 14:21 |
| mardy | jdstrand: right | 14:21 |
| jdstrand | everything else is 'unusual' for the time being | 14:21 |
| mardy | jdstrand: "webview" is not unusual, though | 14:21 |
| jdstrand | ok | 14:21 |
| jdstrand | that's fine too :) | 14:22 |
| jdstrand | point is, it is flexible | 14:22 |
| jdstrand | I'm happy to work with you on the policy, and I will update the click reviewers tools as appropriate | 14:22 |
| seb128 | wgrant, hey, is there any news of the vivid translations opening? | 14:34 |
| wgrant | seb128: Ran into some issues just before EOD yesterday, just catching up with the situation now. | 14:37 |
| seb128 | wgrant, ok | 14:38 |
| pitti | cjwatson: does it actually make sense to have initramfs-tools scripts in udebs? | 15:38 |
| bdmurray | pitti: I uploaded libnih on the 17th and amd64 ddebs made it but i386 didn't. Can you rescue them? | 15:38 |
| pitti | bdmurray: ah thanks, I will | 15:38 |
| cjwatson | pitti: example? | 15:39 |
| pitti | cjwatson: i. e. does d-i ever call update-initramfs (aside from in the target/ chroot) | 15:39 |
| cjwatson | pitti: No | 15:40 |
| pitti | cjwatson: current Ubuntu delta in lvm2 which I need to port over to a changed package structure | 15:40 |
| pitti | cjwatson: but this part doesn't seem to make sense to me, looks like cruft | 15:40 |
| cjwatson | pitti: you mean things like this? | 15:41 |
| cjwatson | +../../tree/dmsetup/usr/share/initramfs-tools /usr/share | 15:41 |
| pitti | cjwatson: right | 15:41 |
| cjwatson | pitti: yeah, I don't see any point in those, probably an accident somewhere along the way | 15:41 |
| pitti | cjwatson: dmsetup-udeb and lvm2-udeb ship those | 15:41 |
| pitti | cjwatson: ok, thanks for confirming; I adjusted the udev rules (as these do make sense in the udeb), and just drop the initramfs hooks/scripts | 15:42 |
| cjwatson | Sounds good | 15:42 |
| pitti | I now also have a vivid LVM install for testing | 15:43 |
| pitti | (i. e. utopic + dist-upgrade) | 15:43 |
| xnox | pitti: i thought we needed those, for something rather udev autodetection of hard-drives and things in the installer. | 16:03 |
| * xnox tries to remember. | 16:03 | |
| pitti | xnox: yes, of course we need the udev rules | 16:04 |
| pitti | xnox: but not the initramfs hooks/scripts in the udebs | 16:04 |
| xnox | yeah those do sound odd, cause installer's initramfs clearly doesn't need that. | 16:04 |
| pitti | right, I cleaned them up | 16:04 |
| pitti | I just finished the merging and got my first successful build \o/ testing it now | 16:04 |
| pitti | and lo and behold, still boots with both upstart and systemd | 16:10 |
| pitti | now I need to clean up some unnecessary systemd units (as we use udev 85-lvm2.rules) | 16:10 |
| pitti | xnox, kees: I sent a call for testing for new LVM to u-devel@; testing appreciated! | 16:42 |
| xnox | pitti: tah. | 16:44 |
| wgrant | pitti: We currently do precise, trusty, utopic and 14.09. vivid is now open and importing. I can move utopic to Tuesday, but what should we do about vivid? | 18:10 |
| wgrant | I guess we could just start doing things on Friday as well. No problem with that from my end. | 18:10 |
| wgrant | Monday: vivid, Tuesday: 14.09, Wednesday: precise, Thursday: trusty, Friday: utopic? | 18:11 |
| wgrant | Since I guess we want both vivid and 14.09 before Wednesday for images. | 18:11 |
| ogra_ | we dont currently do milestones for vivid | 18:11 |
| wgrant | Though we can potentially do more than one a day nowadays. | 18:11 |
| wgrant | Sure, but we will eventually. | 18:12 |
| wgrant | Anyway, I need to wander off for a few hours. | 18:12 |
| wgrant | pitti: Let me know what you think. | 18:12 |
| ogra_ | 14.09 now has a milestone process where we try to have the candidate image ready on wed. evemning EU TZ | 18:12 |
| wgrant | Right, that's why we're moving them to Tuesday. | 18:12 |
| pitti | wgrant: sounds perfect tome | 18:12 |
| ogra_ | (like ... now (or in about 2h at least)) | 18:12 |
| wgrant | pitti: 21:00 Tuesday works for 14.09? | 18:12 |
| pitti | wgrant: although we don't really need precise and utopic builds any more, there's releatively little interest in them | 18:13 |
| pitti | ogra_: when do you want to have the rtm packs again? (for freezes) | 18:13 |
| ogra_ | pitti, well, we are just preparing to build the final milestone right now | 18:13 |
| ogra_ | so generally before now ... :) | 18:14 |
| pitti | ogra_: ah good, so if new packs would be in RTM archive on Wednesday (our) mornings, does that fit? | 18:14 |
| ogra_ | tue. evening, wed. morning would be fine | 18:14 |
| pitti | wgrant: so, 21:00 Tue sounds great; I suppose I can kick off the source pkg build around Wed 03:00 then? | 18:14 |
| ogra_ | yeah, we usually call out the archive freeze after the landing meeting around 11am local time | 18:14 |
| pitti | src pkg preparing+upload+build is usually ~ 2 h | 18:15 |
| wgrant | pitti: Um maybe. We'll have to see how long it regularly takes at that time of day. | 18:15 |
| pitti | wgrant: ack, so let's start with that; if it takes too long, we can move it a tad earlier, but it should have enough reserve | 18:16 |
| * pitti waves good night then | 18:16 | |
| ChrisTownsend | In vivid, what is now responsible for setting the /dev/shm -> /run/shm symbolic link? It seems in past releases, it was done in initscripts.postinst, but that doesn't seem to be the case now. | 19:02 |
| ChrisTownsend | I ask, because unpacked images don't seem to have that link anymore. | 19:03 |
| infinity | ChrisTownsend: Should be done by /etc/init/mounted-dev.conf | 19:27 |
| infinity | ChrisTownsend: Unless you've switched to systemd, then I think the answer is that nothing does it currently. | 19:27 |
| infinity | ChrisTownsend: But an "unpacked image" won't have the link, it happens at boot. | 19:27 |
| ChrisTownsend | infinity: Well, here's the thing. I have an unpacked image that I then start in an LXC. That linked is created when using a Utopic image, but not with a Vivid image. Also, that upstart job doesn't run unless /dev is it's own mount point, right? | 19:29 |
| infinity | ChrisTownsend: Ahh, for what lxc is and isn't doing about that, probably a question for stgraber or hallyn. | 19:31 |
| infinity | Who are both at a sprint right now, I believe. | 19:31 |
| ChrisTownsend | infinity: Ok, thanks. I'll investigate some more for now. | 19:32 |
| * hallyn lays low | 19:50 | |
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| teward | not to be annoying, but is there anyone who can, say, take a peek at a merge debdiff and perhaps sponsor it in for vivid? | 21:00 |
| ChrisTownsend | infinity: Hey again, I downloaded the ubuntu-14.10-desktop-amd64.iso image and mounted the squashfs and sure enough, the /dev/shm -> /run/shm link is there already. I presume this is due to initscripts.postinst which sets this. However, on Vivid, initscripts.postinst does not set this link, so the squashfs does not have it. So something else is setting it on boot...maybe the mounted-dev upstart job, but I have | 21:21 |
| rbasak | Bits of Debian infrastructure down? Where's the appropriate status page/IRC channel for this stuff? Google doesn't seem to be getting me anywhere. | 21:55 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!