[00:10] <slangasek> hallyn: any reason that your debdiff is calling dpkg-maintscript-helper directly, instead of using debian/qemu-system-x86.maintscript?
[00:36] <hallyn> slangasek: yes.  ignorance
[00:37] <slangasek> ;)
[00:37] <hallyn> so that will expand into all the preinst/postinst/potsrms as needed?  neat
[00:41] <hallyn> the package.maintscript is not descirbed in dpkg-maintscript-helper manpage
[00:44] <slangasek> hallyn: yeah, it's part of debhelper's support for dpkg-maintscript-helper, rather than part of the dpkg interface itself
[00:44] <slangasek> hallyn: documented in dh_installdeb(1)
[00:45] <cjwatson> Though as a result of a conversation at DebConf there's now a bug requesting a cross-reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759754
[00:50] <hallyn> oh cool, thanks
[02:02] <hallyn> infinity: hm.  qemu's debian/rules just does "        dh_installinit -pqemu-system-x86 --no-restart-on-upgrade --error-handler=true --name=qemu-kvm
[02:02] <hallyn> i.e. it's not doing --upstart-only
[02:03] <hallyn> but ther eis no compatiability script being created.
[02:03] <infinity> hallyn: COmpat scripts don't happen anymore.
[02:03] <infinity> hallyn: And because --name doesn't match the init script, only the upstart job is copied.
[02:04] <infinity> hallyn: For other reasons (upstart not running it twice), they should have the same name anyway, and if they did, it would magically DTRT.
[02:04] <hallyn> ok, so i'm plannin to rename the sysvinit script, but fo rmy education,
[02:04] <hallyn> if the package name was the upstart job name, then it would create the upstart job?  no you say no more compat scripts
[02:04] <blkperl> slangasek: sigh... still seeing failures my earlier optimism was wrong
[02:05] <blkperl> slangasek: maybe you were right and its a different issue
[02:05] <hallyn> ok.  np.  we'll use the sysvinit script anyway.  thanks.
[02:05] <infinity> hallyn: If the package name and the init script name and the upstart job name were all meant to be the same, then you'd skip --name
[02:05] <infinity> hallyn: If the package is mismatched (which is fine), then the upstart job and init script should match each other and you need --name
[02:05] <hallyn> why no more compat scripts?
[02:06] <infinity> hallyn: Because compat scripts are entirely incompatible with other init systems?
[02:06] <hallyn> oh, yeah, that
[02:06] <hallyn> makes sense
[02:06] <hallyn> thanks
[03:37] <pitti> bdmurray: yeah, that was quite expected, as before it barely installed anything new (for a well-filled sandbox)
[03:45] <pitti> bdmurray: I replied to the bug with an initial idea which I think should boost the performance quite a bit
[03:45] <pitti> bdmurray: I think ATM we don't have really useful numbers to measure the slowdown though (I think we should compare times with cache but empty sandbox, see bug)
[03:46] <pitti> Good morning
[04:06] <ScottK> mitya57: I can't get the pastebin to load.
[04:09] <Unit193> Finally loads for me now.
[06:09] <pitti> slangasek: still awake? do you know the recommended way to check whether upstart is running? I don't see a socket in /run (checking for such is simple and fast)
[06:10] <pitti> context: bug 1370329; I'm trying to teach systemd's reboot etc. to fall back to something that works under upstart
[06:10] <pitti> "telinit 0/6" works fine, but I'd rather guard that with a check if we are actually running upstart
[06:36] <mitya57> ScottK: how about without /plain? http://paste.ubuntu.com/8358366/
[06:37] <ScottK> mitya57: Works.  Thanks.
[06:38] <mitya57> Thanks to you. Btw I'm really impressed by how quickly ftpmasters processed -2 in Debian.
[06:38] <mbiebl> pitti: couldn't upstart provide /dev/initctl, then it should just work(tm)
[06:39] <ScottK> mitya57: Thanks for your contribution to Ubuntu.
[06:39] <pitti> mbiebl: I don't know how much effort that would be; I'm currently working on a fallback to connect to the upstart socket
[06:39] <ScottK> (uploaded)
[06:47] <dholbach> good morning
[06:54] <infinity> pitti: Our usual check is to parse $(initctl version)
[06:54] <infinity> pitti: (see the libc6 postinst, etc)
[06:54] <pitti> infinity: yeah, I was wondering if there was something a bit less expensive
[06:55] <infinity> pitti: If there was, I'd be using it. :/
[06:55] <pitti> infinity: I think checking if one can connect to unix:abstract=/com/ubuntu/upstart is fine?
[06:55] <pitti> it's unfortunately an abstract socket, not an unix socket
[06:55] <infinity> pitti: That assumes dbus?
[06:56] <infinity> Perfectly viable to have upstart booting your system but no dbus running (or even installed).
[06:56] <pitti> well, that's upstart's private d-bus socket (not the system dbus one)
[06:56] <pitti> AFAICS that's upstart's one and only way to talk to it aside from the system bus
[06:56] <pitti> i. e. it's "the" upstart socket
[06:57] <pitti> unless I missed anything (I grepped upstart for other connections this morning)
[07:36] <mlankhorst> weird, is anyone else having problems with youtube on precise?
[07:36] <mlankhorst> chromium browser works, firefox fails
[07:37] <pitti> mbiebl, jodh, slangasek: fugly, but at least works: http://paste.ubuntu.com/8363393/
[07:37] <pitti> I checked telinit's implementation, and it's much more than just one or two d-bus calls, so this calls telinit instead of reimplementing it
[07:38] <pitti> mbiebl: do you want this in master (i. e. for Debian) too, or aren't you concerned much about booting upstart in Debian?
[07:39] <mlankhorst> oh nm, looks like an extension issue
[08:09] <ypwong> cjwatson, hi, ubuntu kylin team is considering to remove wubi.exe from the image, is it possible?
[09:36] <cjwatson> ypwong: sure, file a bug on ubuntu-cdimage and I can take care of it
[09:36] <ypwong> cjwatson, thanks! will do.
[12:36] <caribou> cjwatson: FYI, I just SRUed a fix for bug #1073108 on grub2
[12:37] <caribou> cjwatson: in case you want to have a look. This is why I pinged you a few days back but I found the fix
[12:40] <cjwatson> caribou: ah, sure, that makes sense
[12:40] <cjwatson> caribou: you need sponsorship for that?
[12:40] <caribou> cjwatson: yes
[12:41] <caribou> cjwatson: the fix is already in Trusty & Utopic. I'm doing the SRU for Precise
[12:41] <cjwatson> Yeah
[12:41] <cjwatson> I remember it
[12:44] <cjwatson> caribou: sponsored, thanks.  will need another SRU team member to review
[12:44] <caribou> cjwatson: thank you ! the SRU team is subscribed as well
[12:58] <flexiondotorg> slangasek, Was just discussing the following with popey - https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1343841
[12:58] <flexiondotorg> slangasek, popey Suggested I bring it to you attention.
[12:59] <flexiondotorg> The boot logo is displayed when booting the live media but the installed system doesn't display anything during the boot.
[13:01] <flexiondotorg> slangasek, This can be reproduced with Ubuntu daily-live, is there anything useful I can run to add to the bug report?
[13:06] <smoser> can i get an archive admin to NACK the trusty-proposed upload for cloud-init please ?
[13:06] <smoser> stgraber, ?
[13:13] <stgraber> smoser: always happy to reject uploads :)
[13:13] <stgraber> smoser: there you go
[13:14] <smoser> thanks stgraber
[13:17] <shadeslayer> stgraber: is there a way to allow lxc to mount procfs?
[13:18] <stgraber> shadeslayer: turn off apparmor or use a custom apparmor profile allowing mounting proc
[13:18] <shadeslayer> hmm
[13:18] <stgraber> shadeslayer: the main reason why we deny mount of proc is that apparmor can only filter access based on paths, so if you can mount procfs somewhere else, then the new mount won't have any protection and you can easily use that to escape the container.
[13:19] <stgraber> shadeslayer: note that this isn't a problem with unprivileged containers, so if running unprivileged, lxc.aa_profile=unconfined is actually safe
[13:19] <shadeslayer> I see
[13:47] <rbasak> infinity: ping (again)
[14:31] <caribou> stgraber: have you heard of any issue with debian sid container recently ?
[14:53] <stgraber> caribou: yeah, there are a few issues apparently, one is the apt config, I think we've got a pull request for that. The other may be related to systemd assuming it's been switched to it.
[14:55] <caribou> stgraber: yeah, looks like systemd is there for something : http://pastebin.ubuntu.com/8365367/
[15:02] <bdmurray> pitti: the apport-retrace options I used included --sandbox-dir and -C
[15:02] <pitti> bdmurray: good mornhing
[15:02] <pitti> bdmurray: right; I was wondering about a comparison with empty sandbox-dir; as with a filled (but old) one we'd compare "broken" against "correct", so not that useful for optimization
[15:03] <pitti> bdmurray: I have an idea how to speed it up, I was just wondering how to measure it
[15:04] <bdmurray> pitti: got it
[15:06] <slangasek> flexiondotorg: the apport information from the person who submitted it shows a system with only VESA in /proc/fb, which does not give the full graphical boot splash experience; but that's in VirtualBox, so is also not relevant to the original submitter's claim that it's broken on an HP laptop
[15:07] <slangasek> flexiondotorg: so there is still not anything actionable here for plymouth
[15:07] <slangasek> flexiondotorg: if you can reproduce this problem on real hardware, that's interesting to have apport data for
[15:08] <flexiondotorg> slangasek, I can reproduce. What do you need.
[15:08] <slangasek> flexiondotorg: well, I think you should file a new bug against plymouth with 'ubuntu-bug plymouth'
[15:08] <slangasek> (because your problem may be different than the original submitter's)
[15:09] <flexiondotorg> slangasek, Also there are several bug reports that look related.
[15:09] <flexiondotorg> * [LP #1343841](https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1343841)
[15:09] <flexiondotorg>     * [LP #1356513](https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1356513)
[15:09] <flexiondotorg>     * [LP #1368414](https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1368414)
[15:09] <slangasek> pitti: why open a dbus connection to the abstract socket, instead of just connect() ?  The latter should suffice for confirming upstart is running
[15:09] <flexiondotorg> slangasek, When I run up Ubuntu daily-live on real hardware what apport incantations do you want me to invoke?
[15:10] <slangasek> flexiondotorg: 'ubuntu-bug plymouth'
[15:11] <flexiondotorg> slangasek, Once I have created a bug. I have other people experiencing the same issue on possibly different hardware. How should they then submit their apport feedback to my bug report?
[15:11] <slangasek> flexiondotorg: they should file their own bugs, *not* pile on to the same bug report
[15:11] <flexiondotorg> slangasek, Perfect. Thanks.
[15:11] <slangasek> flexiondotorg: however, now that I'm thinking about it, I'm not sure we fixed it yet so that the plymouth apport hook is back in the right place
[15:11] <slangasek> flexiondotorg: so give me a minute to look at this
[15:12] <pitti> slangasek: ah, if upstart won't get confused by that, that's certainly simpler
[15:12] <pitti> slangasek: I do something similar in postgres, and the server then always complains about an aborted connection
[15:12] <flexiondotorg> slangasek, Sure thing. Ping me when you want me file a bug.
[15:12] <slangasek> pitti: upstart may complain as a low-severity warning, but so what :)
[15:12] <pitti> slangasek: *nod*
[15:15] <flexiondotorg> slangasek, Are you aware full disk encryption is broken in 14.10 because Plymouth won't accept the passphrase?
[15:16] <slangasek> flexiondotorg: no, I'm not aware of that, because I am using it every time I reboot
[15:16] <flexiondotorg> OK, I'll re-do my test install and file a bug.
[15:22] <smoser> hey. i'd like to declare names for network interfaces.  i have only mac address.
[15:22] <smoser>   /etc/udev/rules.d/70-persistent-net.rules says i can edit it if i change only the name
[15:23] <smoser> but i would not be able to render something exactly like that as i do not have all the necessary ATTR
[15:23] <smoser> so my question is where can/should i write a udev rule like:
[15:24] <smoser>  SUBSYSTEM=="net", "ACTION=="add", DRIVERS="?*", ATTR{address}=="$MAC_ADDRESS", NAME="eth0"
[15:24] <smoser> such that /lib/udev/write_net_rules would not overwrite it
[15:31] <pitti> smoser: write_net_rules won't touch the file if it already exists
[15:32] <pitti> smoser: so either just write your adjustments there, or make it an empty file and put your's into a different one (not sure why you'd want this, but it's an option)
[15:33] <pitti> smoser: ah sorry, I probably misremember that, so ignore this
[15:34] <pitti> I haven't actually seen it updating an existing file, but I don't see where in the code this would be enforced; presumably if you hotplug a new interface it would get added there
[15:48] <flexiondotorg> slangasek, I've just tested full disk encryption and you are quite correct it does indeed work.
[15:51] <smoser> pitti, right. if it doenst update the file on hotplug, then it only serves for interfaces available the first time it ever arn
[16:04] <slangasek> flexiondotorg: ok.  So I've just uploaded plymouth 0.9.0-0ubuntu4, which reintroduces the apport hook; if you can upgrade to that version of plymouth and then run 'ubuntu-bug plymouth', that's what will get us the needed info
[16:05] <flexiondotorg> slangasek, Sure.
[16:09] <doko> cjwatson, is it ok to remove the ps3 packages in the seeds?
[16:14] <cjwatson> doko: yeah probably
[16:17] <cjwatson> jamespage: would you mind merging kombu?  needed for new celery version I synced into -proposed, which in turn is needed to fix a build failure
[16:18] <doko> done
[16:20] <jamespage> cjwatson, yes ok
[16:22] <cjwatson> ta
[16:29] <cjwatson> sbeattie: could you merge hardening-wrapper?  it would fix a build failure
[16:29] <cjwatson> (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752717)
[16:46] <sbeattie> cjwatson: yeah, thanks.
[16:52] <smoser> cjwatson, you still around ?
[16:53] <smoser> utlemming and i are getting bothered on bug 1336855 . and admittedly it is a painful issue.
[16:53] <cjwatson> smoser: just go ahead with your workaround and assume I'll sort it out later if it breaks something I care about
[16:54] <cjwatson> I have no time for anything else at the moment
[16:54] <smoser> ok. i would *love* to have it sorted correctly in grub.
[16:54] <smoser> but "need fix now".
[16:54] <smoser> thanks
[20:45] <flexiondotorg> slangasek, I've just installed Ubuntu daily-live from today.
[20:47] <flexiondotorg> slangasek, First boot, got the Unity greeter and switch to tty2 and did apt-get update/upgrade which pulled in the new plymouth build you created plus some Qt5 stuff.
[20:48] <flexiondotorg> Switched back to Unity greeter and rebooted. Still no boot logo in Plymouth but the bigger issue is that now there is no Unity greeter at all.
[20:49] <flexiondotorg> slangasek, Do you still want me to riase the plymouth bug given this other change?
[20:50] <slangasek> flexiondotorg: well, that's interesting
[20:50] <slangasek> flexiondotorg: so you get no graphical login screen at all?
[20:50] <flexiondotorg> Just restarted lightdm and Unity greter has loaded.
[20:50] <slangasek> ah
[20:50] <slangasek> so if you have that working, I'd say it's ok to file a plymouth bug
[20:50] <flexiondotorg> Want me to login first or switch to a vt and file the bug?
[20:52] <flexiondotorg> slangasek, Do you also want a photo of the "no boot logo" screen for Plymouth?
[20:52] <flexiondotorg> I've rebooted and this time Unity greeter has loaded without issue.
[20:52] <slangasek> flexiondotorg: probably easiest to file the bug from a GUI login.  Photo - will the photo show anything interesting? :)
[20:53] <flexiondotorg> slangasek, Photo would be of my cruty old Thinkpad T43p with a blakc screen 😉
[20:53] <slangasek> yeah, I know what black looks like
[20:54] <slangasek> no need for a photo ;)
[20:54] <flexiondotorg> What about the nice purple border? Can you image that too? 😃
[20:54] <flexiondotorg> s/image/imagine/
[20:54] <cjwatson> that part is a grub bug that I've been meaning to get round to fixing
[20:54] <cjwatson> but I can see it here so don't need details
[20:55] <flexiondotorg> Yeah, I saw the GRUB bug.
[20:55] <cjwatson> slightly busy with ... everything else
[21:04] <flexiondotorg> slangasek, https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1370707
[21:04] <flexiondotorg> Do you want me to subscribe any groups to that report?
[22:01] <slangasek> flexiondotorg: cheers - that should give me a starting point
[22:17] <flexiondotorg> slangasek, You're welcome.