ZZambia_is anybody following the ubuntu touch development for MT6595 platforms, like Meizu MX4?00:18
ZZambia_I would need some tech info, plz00:18
pittiGood morning05:47
pittiwgrant: no, I don't think I ever approved vivid templates, why? (just recently some RTM ones)05:48
wgrantpitti: 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
pittiwgrant: ah, thanks05:49
pittiwgrant: btw, can we move the RTM tarball generation?05:49
wgrantpitti: I was going to do that in the same step as changing the crontabs for vivid05:50
wgrantBut that ended up blocked by the various issues.05:50
wgrantIf I don't get it done tomorrow, I'll shift RTM anyway.05:50
pittiwgrant: cheers05:53
Noskcajdoko_, syncing libexplain should fix the ftbfs you introduced, it still ails on aarch64 though06:32
=== MasterPieceF is now known as MasterPiece
=== zyga is now known as zyga-afk
dholbachgood morning07:46
=== doko_ is now known as doko
dokoNoskcaj, synced07:51
ZZambiais anybody following the ubuntu touch development for MT6595 platforms, like Meizu MX4?09:46
ZZambiaI would need some tech info, plz09:46
cjwatson#ubuntu-touch would be more likely to know09:46
cjwatson(if anyone does)09:46
=== ara_ is now known as ara
davidcalledoko, hello, I've been told this would be in your area of interest : https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/139413110:24
ubottuLaunchpad 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_
pittijodh: 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
jodhpitti: should just be that logrotate fix, so upload should be fine.11:42
pittijodh: and Dmitry's upstart-sessions update (also looks ok)11:42
pittijodh: ack, thanks11:43
jodhpitti: ah yes, that looks fine too.11:45
GunnarHjpitti: As regards bug #678421, is bash out of the question?11:48
ubottubug 678421 in lightdm (Ubuntu Trusty) "Error message for a faulty ~/.profile script" [Low,In progress] https://launchpad.net/bugs/67842111:48
pittiGunnarHj: no, not at all IMHO11:48
pittiGunnarHj: but your trap is also rather clever :)11:48
pittijodh: I get FAIL: test_conf_preload.sh11:49
pittijibel: ... when building locally in schroot; is that common/expected?11:49
pittijodh: not otherwise very verbose (http://paste.ubuntu.com/9094158/)11:50
pittijibel: sorry, that was meant for jodh11:50
GunnarHjpitti: 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
pittiGunnarHj: that, and some people (hello barry!) might also have bashisms in their scripts, too11:51
GunnarHjpitti: Right.11:51
GunnarHjpitti: Are you saying that you wouldn't object if I proposed a solution with /bin/bash in the shebang line? ;)11:53
pittiGunnarHj: exactly; as I said in teh bug and above, I think bash is fine11:54
jodhpitti: checking...11:54
pittijodh: I pushed my packaging fix, but I wonder if that failure will also affect buildds11:54
GunnarHjpitti: Ok, thanks. Getting back with a MP then.11:54
pittiGunnarHj: cheers!11:55
barrypitti, GunnarHj: thanks!12:55
jodhpitti: I think the upstart failure is caused by a missing libtool binary (again). The binary seems to be in libtool-bin now.13:12
cjwatsonjodh: You should never be using /usr/bin/libtool.  Use the version that's generated as part of your build system.13:13
cjwatsonBuild-depending on libtool-bin would be the wrong fix.13:13
cjwatsonjodh: I think you probably want something like http://paste.ubuntu.com/9095744/13:14
jodhcjwatson: thanks13:19
pittijodh: re (sorry, was at lunch) -- so this is a proper failure then, not just on my setup?13:36
jodhpitti: 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
jodhpitti: well, a proper failure, but not an upstart bug :)13:48
pittijodh: ah, sure (oh, we use inline patching in the package?)13:49
mardyjdstrand: hi! About your question from yesterday, I'm using libubuntu-app-launcher to start the confined plugin13:56
mardyjdstrand: I didn't know about the aa_change* functions, it looks like I could have used those instead13:56
pittixnox: 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@ otherwise13:57
mardyjdstrand: 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
jdstrandmardy: I'm not sure if the policy would have to have changed there due to revalidation. perhaps sbeattie can comment14:00
jdstrandmardy: so, the confined plugin is running in its own process?14:01
jdstrandmardy: and this is a different security context from the app? who is using libubuntu-app-launcher?14:01
mardyjdstrand: the trusted helper (our background service, unconfined) uses libubuntu-app-launcher to start the confined plugin, which is its own process14:05
mardyjdstrand: to be clear, the process consists of a container we develop, which loads the plugin QML code14:06
mardyjdstrand: the security context is going to be different from that of the app14:06
jdstrandmardy: 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
mardyjdstrand: exactly14:07
jdstrandok cool14:07
jdstrandso that all sounds like a fine design14:07
jdstrandmardy: remind me, what is the question from yesterday?14:07
mardyjdstrand: will account plugins have to declare an "apparmor" entry in the manifest file?14:08
mardyjdstrand: and how do we let them access the socket?14:09
jdstrandmardy: it depends on what you (as the signon developer) need them to do14:09
jdstrandmardy: actually, signon does not run as root14:10
jdstrandI was thinking we could have a sorta 'generic' profile that you could transition them to14:10
jdstrandwhile that profile would protect the system, etc, it would not isolate the plugins themselves14:10
jdstrandto isolate the plugins themselves, we'd need the profiles to be individually named (ie, declare an "apparmor" entry in the manifest)14:11
jdstrandso, we would create a separate template for them, like we did for push helpers14:11
jdstrandmardy: does tha make sense?14:12
mardyjdstrand: and then we combine the apparmor entry in the manifest with the generic plugin profile?14:12
mardyjdstrand: like we do the union of the two?14:12
jdstrandmardy: now, the template becomes the generic plugin profile, with a few plugin-specific bits sprinkled in14:13
jdstrandmardy: eg: /usr/share/apparmor/easyprof/templates/ubuntu/1.2/ubuntu-push-helper14:14
jdstrandmardy: except we call it 'ubuntu-qml-plugin' and use rules that are appropriate for it14:14
mardyjdstrand: 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
jdstrandmardy: 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
jdstrandfor various paths so the plugins themselves are isolated14:17
mardyjdstrand: but will it be possible for the plugins to get more permissions?14:18
mardyjdstrand: I don't have any serious example in mind, but what if a hypothetical plugin wanted to use the location?14:18
jdstrandmardy: we can make that possible or we can make that not possible. what permissions are you thinking of?14:18
jdstrandmardy: the more direct answer is that policy groups are automatically supported14:19
jdstrandmardy: but the click-reviewers-tools can say certain ones are not allowed14:19
mardyjdstrand: ah, ok, that sounds perfect than14:19
jdstrandwe would probably start by saying only networking is allowed, and anything else is flagged as 'unusual'14:20
mardyjdstrand: I would keep the template very minimal, and require plugins to explicitly require all their policies14:20
jdstrandthat way we can get a feel for what people are doing14:20
mardyjdstrand: not all plugins even use network14:20
jdstrandthat's fine14:20
mardyjdstrand: the only common thing is "accounts"14:20
jdstrandthat's fine too14:20
mardyjdstrand: then many would use "network" and "webview", but I'd rather let them specify that explicitly14:21
jdstrandthe click-reviewers-tools can make sure that if providing a qml plugin, the security policy must include accounts14:21
jdstrandnetworking is optional14:21
mardyjdstrand: right14:21
jdstrandeverything else is 'unusual' for the time being14:21
mardyjdstrand: "webview" is not unusual, though14:21
jdstrandthat's fine too :)14:22
jdstrandpoint is, it is flexible14:22
jdstrandI'm happy to work with you on the policy, and I will update the click reviewers tools as appropriate14:22
seb128wgrant, hey, is there any news of the vivid translations opening?14:34
wgrantseb128: Ran into some issues just before EOD yesterday, just catching up with the situation now.14:37
seb128wgrant, ok14:38
pitticjwatson: does it actually make sense to have initramfs-tools scripts in udebs?15:38
bdmurraypitti: I uploaded libnih on the 17th and amd64 ddebs made it but i386 didn't. Can you rescue them?15:38
pittibdmurray: ah thanks, I will15:38
cjwatsonpitti: example?15:39
pitticjwatson: i. e. does d-i ever call update-initramfs (aside from in the target/ chroot)15:39
cjwatsonpitti: No15:40
pitticjwatson: current Ubuntu delta in lvm2 which I need to port over to a changed package structure15:40
pitticjwatson: but this part doesn't seem to make sense to me, looks like cruft15:40
cjwatsonpitti: you mean things like this?15:41
cjwatson+../../tree/dmsetup/usr/share/initramfs-tools /usr/share15:41
pitticjwatson: right15:41
cjwatsonpitti: yeah, I don't see any point in those, probably an accident somewhere along the way15:41
pitticjwatson: dmsetup-udeb and lvm2-udeb ship those15:41
pitticjwatson: ok, thanks for confirming; I adjusted the udev rules (as these do make sense in the udeb), and just drop the initramfs hooks/scripts15:42
cjwatsonSounds good15:42
pittiI now also have a vivid LVM install for testing15:43
pitti(i. e. utopic + dist-upgrade)15:43
xnoxpitti: 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
pittixnox: yes, of course we need the udev rules16:04
pittixnox: but not the initramfs hooks/scripts in the udebs16:04
xnoxyeah those do sound odd, cause installer's initramfs clearly doesn't need that.16:04
pittiright, I cleaned them up16:04
pittiI just finished the merging and got my first successful build \o/ testing it now16:04
pittiand lo and behold, still boots with both upstart and systemd16:10
pittinow I need to clean up some unnecessary systemd units (as we use udev 85-lvm2.rules)16:10
pittixnox, kees: I sent a call for testing for new LVM to u-devel@; testing appreciated!16:42
xnoxpitti: tah.16:44
wgrantpitti: 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
wgrantI guess we could just start doing things on Friday as well. No problem with that from my end.18:10
wgrantMonday: vivid, Tuesday: 14.09, Wednesday: precise, Thursday: trusty, Friday: utopic?18:11
wgrantSince I guess we want both vivid and 14.09 before Wednesday for images.18:11
ogra_we dont currently do milestones for vivid18:11
wgrantThough we can potentially do more than one a day nowadays.18:11
wgrantSure, but we will eventually.18:12
wgrantAnyway, I need to wander off for a few hours.18:12
wgrantpitti: 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 TZ18:12
wgrantRight, that's why we're moving them to Tuesday.18:12
pittiwgrant: sounds perfect tome18:12
ogra_(like ... now  (or in about 2h at least))18:12
wgrantpitti: 21:00 Tuesday works for 14.09?18:12
pittiwgrant: although we don't really need precise and utopic builds any more, there's releatively little interest in them18:13
pittiogra_: 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 now18:13
ogra_so generally before now ... :)18:14
pittiogra_: 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 fine18:14
pittiwgrant: 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 time18:14
pittisrc pkg preparing+upload+build is usually ~ 2 h18:15
wgrantpitti: Um maybe. We'll have to see how long it regularly takes at that time of day.18:15
pittiwgrant: ack, so let's start with that; if it takes too long, we can move it a tad earlier, but it should have enough reserve18:16
* pitti waves good night then18:16
ChrisTownsendIn 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
ChrisTownsendI ask, because unpacked images don't seem to have that link anymore.19:03
infinityChrisTownsend: Should be done by /etc/init/mounted-dev.conf19:27
infinityChrisTownsend: Unless you've switched to systemd, then I think the answer is that nothing does it currently.19:27
infinityChrisTownsend: But an "unpacked image" won't have the link, it happens at boot.19:27
ChrisTownsendinfinity: 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
infinityChrisTownsend: Ahh, for what lxc is and isn't doing about that, probably a question for stgraber  or hallyn.19:31
infinityWho are both at a sprint right now, I believe.19:31
ChrisTownsendinfinity: Ok, thanks.  I'll investigate some more for now.19:32
* hallyn lays low19:50
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
tewardnot 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
ChrisTownsendinfinity: 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 have21:21
rbasakBits 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!