[00:12] <xnox> barry: nope.... it looks like a regression inside python3.4 to me.
[00:14] <xnox> barry: possibly related to http://bugs.python.org/issue11798 ?
[00:58] <xnox> stokachu: it's mostly harmless, in debian there must be matching init.d scripts for upstart jobs, it's not a requirement in ubuntu (as we've been using upstart for many releases by default now)
[00:58] <xnox> stokachu: however, if the package is in debian and should be usable with sysv-init, it's a serious bug that must be fixed.
[00:59] <stokachu> xnox: ah ok
[01:00] <stokachu> xnox: this is ubuntu only package so i just put a lintian override for it
[01:00] <xnox> stokachu: yeap.
[01:00] <stokachu> cool thanks man
[01:40] <infinity> stokachu: Needs more context, but I'm assuming it's including <linux/xattr.h> before <sys/xattr.h>
[01:40] <infinity> Err..
[01:40] <infinity> stgraber: ^
[01:40] <infinity> stokachu: Ignore me. :P
[01:45] <stgraber> infinity: yeah, it somehow is. I worked around by always adding an include of sys/xattr.h early enough in all failing files until it actually built... systemd never includes linux/xattr.h directly, but it indirectly does from somewhere (not exactly sure where though...)
[01:47] <infinity> stgraber: Hunting down where would be nice.  We obviously need to fix the conflict at the root (linux/glibc), but fixing underlying libraries to paper over it (like I did with libcap2) is still "saner" than patching applications a dozen times.
[01:48] <stgraber> infinity: yeah, I first thought it was libcap because there's a bug report about systemd failing to build on arch because of it, but then I noticed that you already fixed it...
[05:18] <pitti> xnox, barry: yeah, I usually -x that conversion, and just pick out the necessary bits; also, the gobject -> GI changes were incomplete
[05:18] <pitti> hallyn: yes, that error message happens all over the place, python3.4 regression
[05:19] <pitti> Good morning
[05:58] <darkxst> seeded-in-ubuntu working for anyone?
[05:58] <darkxst> IOError: [Errno socket error] [Errno -2] Name or service not known
[05:59] <Unit193> Works for me™
[06:00] <sarnold> wfm
[06:08] <Noskcaj> darkxst, broken here
[06:08]  * Noskcaj blames australia
[06:09] <darkxst> Noskcaj, or telstra?
[06:09] <sarnold> nono, blame canada
[06:09] <Noskcaj> probably telstra
[06:09] <Noskcaj> although i might (finally) get the nbn
[06:09] <Noskcaj> even if only in fixed wireless form
[06:17] <darkxst> apparently ubuntuwire.org is not listed in telstra DNS servers ...
[06:18] <Noskcaj> what about .com ?
[06:19] <darkxst> nope
[06:21] <Unit193> darkxst: dig @8.8.8.8
[06:21] <Unit193> If that works, switch to an OpenNIC DNS server.  Welp.
[06:22] <sarnold> or run your own recursor?
[06:23] <Unit193> I run bind9, it also serves OpenNIC domains. :D
[07:05] <dholbach> good morning
[07:24] <tvoss> good morning
[07:25] <tvoss> cjwatson, for benchmarking purposes (no load test, time series scenarios), what statistical tests for result checking do you usually use? I was thinking about something parametric like one-sample-t or a z test
[07:25] <tvoss> together with a previous check if variances are comparable
[07:25] <tvoss> cjwatson, do you have an opinion on that?
[08:00] <mardy> Laney: ping
[08:00] <mardy> (about newer syncevolution)
[08:23] <tseliot> slangasek: thanks
[09:08] <Laney> mardy: yeah?
[09:09] <Laney> We are past feature freeze now so if you want to sync that then you'll need to file an exception
[09:09] <mardy> Laney: so, upstream released SE 1.4
[09:10] <mardy> Laney: OK. Besides the bug, should I provide a branch with the debian packaging, or how does it work?
[09:10] <Laney> http://packages.qa.debian.org/s/syncevolution.html has it already
[09:11] <Laney> so, we'd probably just sync it from there
[09:11] <mardy> Laney: we need an extra parameter in debian/rules to enable the Online Accounts integration
[09:13] <Laney> okay, attach a diff on top of that package then
[09:13] <Laney> and preferably send Debian a bug report asking them to enable it
[09:13] <mardy> Laney: OK, will do, thanks
[09:13] <mardy> Laney: no, AFAIK, the OA packages are not in Debian
[09:14] <Laney> they have goa
[09:15] <mardy> Laney: doesn't help, we need libaccounts-glib and libsignon-glib
[09:19] <Laney> ya, the readme says it has GOA support though
[09:19] <Laney> one day I'll understand why we have this Ubuntu-only online accounts stack
[09:22] <seb128> Laney, it would be more fair to say "why GNOME is having their GNOME-only accounts stack"
[09:22] <mardy> Laney: it's a nice story, indeed. https://debarshiray.wordpress.com/2012/10/06/goa-why-it-is-the-way-it-is/
[09:23] <Laney> Not really, because "GNOME" isn't a distribution
[09:23] <seb128> Laney, the one we are using was used at Nokia, shipping on products, Intel still uses it/work on it, and I think KDE is standardizing on the same techs
[09:23] <seb128> Laney, well, KDE is not using goa
[09:25] <seb128> Laney, well, doesn't change the fact that the tech we use was there first and is used in more place that the one GNOME invented
[09:25] <mardy> Laney, seb128: Sailfish OS is also using our framework, and people from Elementary OS are working on it as well (I'm not sure whether they use it already)
[09:25] <seb128> it's somewhat baffling to me pointed out as the one who did their own stuff there
[09:25] <Laney> Dunno why nobody has brought it to Debian then
[09:26] <mardy> Laney: it's in fedora, curiously
[09:29] <seb128> yeah, it's even actively maintained in fedora it seems, http://pkgs.fedoraproject.org/cgit/libaccounts-glib.git/
[09:29] <seb128> they had an update yesterday
[10:00] <zequence> Hi. I got a package uploaded, ubuntustudio-live, but it's yet not accepted by the archive admins. How does that work? I got it in before feature freeze, and it's supposed to replace our current ubiquity package, ubuntustudio-live-settings. Need time to test it and fix any bugs
[10:16] <Riddell> zequence: I'll take a look
[10:19] <Riddell> zequence: how come it conflicts with ubiquity-slideshow-kubuntu et al and kubuntu-debug-installer ?
[10:19] <Riddell> zequence: how come it doesn't conflict with ubuntustudio-live-settings.
[11:51] <zequence> Riddell: I will remove ubuntustudio-live-settings once ubuntustudio-live is available
[11:52] <zequence> It's a part of the ubuntustudio-default-settings source
[11:53] <zequence> The conflicts I mostly copied from the edubuntu-live source, which I based it on. Might not be complete. edububuntu-live didn't conflict with everything else
[12:05] <Riddell> zequence: it seems to conflict on random packages like hal and also depend on random packages like ldap, I don't think this is what you want
[12:06] <Riddell> zequence: rejecting, please fix depends to be what it must have and conflicts to be what it can not work with
[12:29] <zequence> Riddell: Alright, thanks
[12:30] <ogra> xnox, i'm looking for an upstart specialist ...
[12:31]  * xnox franticly looks around....
[12:31] <xnox> ..
[12:31] <xnox> ogra: ok, what's up?
[12:31] <soren> xnox: Run away!
[12:31] <pitti> jodh was faster with the "need to run out" :)
[12:32] <ogra> xnox, i have something like "env FOO='' at the top of an upstart job ... then later i want to stuff the return of a getprop command into that var from pre-start ... export it to the exec stanza so that it ends up as options to the command i exec
[12:32] <ogra> it seems something like FOO=$(mycommand) doesn work in the pre-start script
[12:33] <ogra> is there any trick i could use to get the output of "mycommand" into the var ?
[12:34] <ogra> (i know i could split the job and export from the first one or echo into a file that i read later, but both feel really ugly)
[12:35] <xnox> ogra: no environment can be passed between stanzas. E.g. pre-start, post-start, pre-stop, pre-start, exec, script - all get fresh environment, and thus FOO=''
[12:35] <xnox> ogra: can you show me your full job?
[12:35] <ogra> right, but export should work around that, no ?
[12:36] <xnox> ogra: pre-start and exec are, well just like lines in a makefile all started in a separate shell.
[12:36] <ogra> xnox, well, its in the middle of a rewrite ... http://paste.ubuntu.com/7004801/
[12:36] <xnox> (well exec may start in shell, and may be execed directly)
[12:36] <ogra> what i get in the log is the "ril" i set at the top
[12:36] <ogra> but not the "stopped" that the getprop returns
[12:37] <xnox> ogra: merge pre-start and exec, into a single
[12:37] <xnox> script
[12:37] <ogra> uuh
[12:37] <xnox>      opt=$(get opts)
[12:37] <xnox>     ril $opt
[12:37] <xnox> end script
[12:37] <ogra> i thought exec should never live inside a script block ?
[12:37] <xnox> ogra: remove "exec".
[12:37] <ogra> slangasek once held me a lecture about that :)
[12:38] <ogra> ah !
[12:38] <ogra> heh, now *that* didnt strike me :P
[12:38] <xnox> ogra: is this system or user job?
[12:39] <ogra> system
[12:39] <ogra> its ofonos start job
[12:39] <xnox> ogra: with user jobs, you could do "initctl set-env OFONO_OPTS=ril"
[12:39] <ogra> we want to get the list of modules from the android side now ... they live in an android property
[12:39] <xnox> ogra: http://paste.ubuntu.com/7004817/
[12:40] <ogra> right, thats what we use in plenty of places
[12:40] <xnox> ogra: alternatively. you can start an instance.
[12:40] <ogra> by splitting the job, yeah
[12:40] <xnox> e.g. have ofono-boot.conf which is task and does "initctl start ofonod OPTS="stuff you got from prop""
[12:40] <xnox> (probably --no-wait as well
[12:40] <xnox> )
[12:40] <ogra> i think dropping the exec and firing everything from the script is the beast though
[12:41] <ogra> *best
[12:41] <xnox> ogra: do check that it gets the right pid...
[12:41] <ogra> yep, will do
[12:41] <ogra> thanks !!
[12:42] <ogra> root@ubuntu-phablet:/# tail -1 /var/log/upstart/ofono.log
[12:42] <ogra> stopped
[12:42] <ogra> yay
[12:43] <xnox> ogra: check "pgrep ofonod"
[12:43] <xnox> after stop
[12:43] <xnox> or compare status, with pgrep.
[12:44] <ogra> oot@ubuntu-phablet:/# initctl list |grep ofono
[12:44] <ogra> ofono start/running, process 1820
[12:44] <ogra> root@ubuntu-phablet:/# pgrep ofonod
[12:44] <ogra> 1820
[12:44] <ogra> looks fine
[12:44] <ogra> (though i dont actually start ofono atm)
[12:44] <ogra> (it is just the echo)
[12:45]  * ogra goes to test on an actual phone now 
[13:02] <cff> How can I purge Qt Edgers repo?
[13:03] <cff> I've tried with ppa:canonical-qt5-edgers/qt5-proper but it gives PPA to be removed: canonical-qt5-edgers qt5-proper Warning:  Could not find package list for PPA: canonical-qt5-edgers qt5-proper
[13:03] <cff> ppa-purge ppa:canonical-qt5-edgers/qt5-proper
[13:04] <zequence> Ridell: I made changes in dependencies and conflicts, to the best of my understanding. Would you be able to accept this version? lp:ubuntustudio-live
[13:05] <ogra> xnox, hmm, using the real ofonod on a phone doesnt give me the right pid if the command lives inside the script block
[13:07] <ogra> seems that only worked with the echo ... but not with a forked daemon :/
[13:09] <zequence> Riddell: (reposting, as I can't spell) I made changes in dependencies and conflicts, to the best of my understanding. Would you be able to accept this version? lp:ubuntustudio-live
[13:12] <Riddell> zequence: looking
[13:14] <Riddell> zequence: why does it conflict with other ubiquity slideshows and with mythbuntu-live-autostart ?
[13:15] <Riddell> zequence: lintian errors a-plenty http://paste.kde.org/pfq7goadb
[13:18] <zequence> Riddell: I guess the conflicts are more for testing, then otherwise. I saw that edubuntu-live had them, so I kept them. As for the lintian errors, I need to fix that, absolutely.
[13:19] <zequence> I'll need a day to go through that
[13:19] <zequence> Thanks for the help
[13:23] <xnox> zequence: Riddell: correct seeds should be used to seed new slideshow, and replace the other one.
[13:23] <xnox> zequence: using conflicts is abuse here, since everything depends on "provides" package (ubiquity-slideshow) and thus typically only one is pulled in anyway.
[13:24] <xnox> zequence: no slideshows should encode the names.... of all the other slideshows as that's a lot.
[13:24] <xnox> zequence: for testing you should do: $ apt-get install your-slideshow.deb ubiquity-frontend-[gtk|kde] ubiquity
[13:25] <xnox> zequence: if you do install ubiquity, it can pull in kde frontend with kubuntu slideshow by default without any hints =))))
[13:25] <xnox> zequence: is there a matching branch to adjust studio seeds to use new packages?
[13:25] <xnox> zequence: the two should go in together (-meta update + your new packages)
[13:26] <mpt> bdmurray, I guess the X axis for a graph showing any series should extend to whichever is later: the release date of that series, or (whichever is earlier: today, or EOL for the series)
[13:26] <zequence> xnox: I wanted to wait until all the packages were available. Then do the switch. If that meant one broken ISO build, I thought that would be fine, while adjusting it all.
[13:26] <xnox> thus a: Breaks: studio-meta (<< first-version-that-pulls-in-new-slideshows-et-al)
[13:26] <zequence> I don't have upload rights, so I need someone to help do the switch
[13:26] <zequence> I can only edit the seeds
[13:27] <xnox> zequence: no, just declare the above breaks, and your new packages can be staged in -proposed, and you can test them by dist-upgrading live cd.
[13:27] <xnox> zequence: onces you are happy, the whole lot can migrate to release. Thus both giving you test playground, and no broken cds.
[13:27] <xnox> zequence: well, you can work with Riddell or myself to stage the uploads correctly =)
[13:27] <zequence> xnox: Alright, thanks.
[13:27] <mpt> bdmurray, so for the 14.04 milestones to extend the default graph is a good thing, it shows the “flight path” for finalizing 14.04. Not so much if it’s a graph just showing 12.10 or whatever.
[13:32] <infinity> xnox: A Breaks really seems unnecessary.  Who upgrades the live set?
[13:44] <xnox> infinity: for britney to migrate them together?
[13:44] <xnox> infinity: of is that abusive as well?! =)
[13:45] <infinity> xnox: I don't see as it makes a massive difference in this case.  It's just control cruft.
[13:47] <mpt> bdmurray, I’ve added some details of the graph design for future reference. <https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=177&rev1=176>
[13:47] <infinity> (And it doesn't *actually* break that package, you're just abusing it to get both together, which is a non-issue for CD builds that always pull the latest anyway)
[13:47] <xnox> zequence: right, so tag bug block-proposed, upload the packages you need. From live cd upgrade and test them out. Once happy, remove the tag let all packages migrate and the cd after that, will be all beautiful.
[13:48] <xnox> zequence: where are your sponsorship / merge proposal requests?
[13:49] <zequence> xnox: bug 946591
[13:49] <mpt> bdmurray, to implement that exactly the error tracker would need to start knowing which milestone belongs to which Ubuntu version, so it can show only those milestones relevant to the currently shown versions.
[13:49] <zequence> It's an old bug, which I updated
[13:51] <xnox> zequence: ack. will look into it later.
[14:31] <ximion> hughsie: hi :) did you try libappstream yet?
[14:32] <ximion> wtf...
[14:33] <ximion> sorry for the noise... irc client issue
[15:18] <barry> dobey: i've seen this, but haven't had time to investigate yet.  thanks for pointing me to the bug
[15:33] <hallyn> pitti: thanks much for the bug reports on qemu-2.0!
[15:45] <slangasek> ogra, xnox: note that you can't use 'expect fork' if you are calling getprop for env setup, because getprop will fork
[15:46] <ogra> oh !
[15:46] <ogra> slangasek, thanks ...
[15:47] <xnox> slangasek: yeah, we got there, eventually. Also we agreed that android-event-bridge should just sent event when ril is ready, with all the right params in the event variable.
[15:47] <slangasek> ok :)
[15:47] <xnox> slangasek: and the ofono.conf job just use that var, or have a sensible fallback.
[15:58] <pitti> jodh: is there a way to disable e. g. /usr/share/upstart/sessions/update-notifier-crash.conf (file-triggered, so you can't just "stop" it) without removing/touching that file?
[15:58] <pitti> jodh: i. e. some counterpart to .override files in /etc/ for /etc/init?
[15:58] <pitti> perhaps in ~/.config or so?
[15:58] <pitti> there's a ~/.config/upstart/ which sounds promising
[15:58] <pitti> om26er: ^ FYI
[15:59] <jodh> pitti: yep - "echo manual >> /.config/upstart/update-notifier-crash.override"
[16:00] <xnox> pitti: user-session jobs, can be overridden in any XDG_CONFIG_DIRS/upstart and XDG_CONFIG_HOME/upstart.
[16:00] <pitti> jodh: splendid, thank you!
[16:00] <pitti> om26er: ^
[16:01] <xnox> pitti: documented in man 5 init, under user-session jobs.
[16:01] <om26er> pitti, so it will disable it instantly ? or the next run ?
[16:01] <jodh> om26er: it should of course be "echo manual >> ~/.config/upstart/update-notifier-crash.override" :)
[16:01] <pitti> om26er: should be instant
[16:01] <xnox> pitti: om26er: in essence, we take highest priority .conf, and .override from higher priority down to the one where .conf is.
[16:01] <pitti> om26er: well, there is no "run" really, it just will stop getting triggered
[16:02] <xnox> pitti: so, e.g. /etc/xdg/upstart/foo.conf, can override completed /usr/share/upstart/session/foo.conf, and user can further tweak it with ~/.config/upstart/foo.override.
[16:02] <jodh> om26er: well the override file you create will be applied instantly, but if that service is already running it won't be stoppe (hence really only applies to next session startup).
[16:03] <xnox> (and since desktop envrionments get their own XDG_CONFIG_DIR you can even override jobs on-per session types)
[16:03] <om26er> jodh, understood, thanks
[16:04] <pitti> jodh: it's a file trigger; so as soon as that override is in place, it should stop getting triggered, right? or does the session upstart only read ~/.config/upstart/ on startup? (I had expected an inotify watch)
[16:08] <jodh> pitti, om26er: ah - forgot that /usr/share/upstart/sessions/update-notifier-crash.conf uses the file bridge, so yes, the .override will apply immediately (ie no further crash files will cause that job to run).
[16:08] <om26er> jodh, ack
[16:41] <xnox> Laney: did you upload the gstreamer package split? as far I understand, nothing will change as long as the full-ugly one still depends on the two split ones. and we'll just need to change the touch-seed (when that's allowed to land) to land the switch and drop.
[16:41] <Laney> xnox: Nobody ever tested it
[16:41] <xnox> Laney: hm. ok. Let me hunt that down and report back to you.
[16:42] <Laney> I already asked rsalvet_i
[17:12] <pitti> stgraber: jodh and I are fighting with the sbuild autopkgtest in LXC
[17:12] <stgraber> pitti: ok, what's going on exactly?
[17:13] <pitti> stgraber: both with the standard lxc-container-default-with-mounting and with your magic custom lxc-adt profile it still fails on
[17:13] <pitti> W: Failure trying to run: chroot /tmp/adt-run.bnodMI/ubtree0t-build_procenv-testtmp/adttmp/schroot-trusty mount -t proc proc /proc
[17:13] <pitti> [77539.290066] type=1400 audit(1393521100.343:60): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-adt" name="/tmp/adt-run.bnodMI/ubtree0t-build_procenv-testtmp/adttmp/schroot-trusty/proc/" pid=18110 comm="mount" fstype="proc" srcname="proc" flags="ro"
[17:13] <pitti> stgraber: it only works when running with "unconfined"
[17:13] <pitti> stgraber: could we relax the AA profiles to allow mounting /proc?
[17:14] <pitti> stgraber: at least in the custom profile
[17:15] <stgraber> pitti: yeah, sounds like if you want this to pass, you'll need to allow add:
[17:15] <pitti> stgraber: oh, I see some /var/lib/lxc** in the profile
[17:15] <stgraber> mount options=(rw,bind),
[17:15] <stgraber> mount fstype=devpts,
[17:15] <stgraber> mount fstype=proc,
[17:15] <stgraber> mount fstype=sysfs,
[17:15] <pitti> stgraber: I have containers in /srv/lxc/
[17:15] <stgraber> pitti: those paths are relative to the container's rootfs, not your host. These entires are needed for LXC inside LXC.
[17:15] <pitti> ah
[17:16] <stgraber> pitti: add those 4 mount entries to the adt apparmor profile, reload apparmor and try again, that should help (makes the whole thing horribly unsafe, but we already agreed to ignore that ;))
[17:16] <pitti> stgraber: mounting /proc is unsafe?
[17:18] <pitti> stgraber: thanks, trying that
[17:19] <stgraber> pitti: mounting /proc somewhere other than /proc is unsafe because apparmor won't prevent writes to dangerous files
[17:20] <stgraber> pitti: so you can do "echo b > /tmp/proc/sysrq-trigger" for example, or set some of the hooks (crash handler for example), trigger them and run command as root on the host as a result.
[17:20] <pitti> stgraber: ah, I understand
[17:30] <bdmurray> pitti: can you have a look at bug 1283303?
[17:31] <pitti> bdmurray: queued, I'll check tomorrow
[17:33] <bdmurray> pitti: thanks
[17:35] <jtaylor> infinity: will we get updates from the 2.19 branch of glibc "automatically" or do I need to file a bug to get an issue fixed? (upstream #16623 is the context)
[17:35] <bdmurray> My wireless mouse (connected via bluetooth) repeatedly says it is at 0% but then I reconnect it and it is fine for some period of time, and the bluetooth applet says the status is Good now.  How can I dig into this?
[17:37] <infinity> jtaylor: I'll do some updates from the 2.19 master branch over the next month or two before final freeze.
[17:38] <infinity> jtaylor: Does this possibly also fix 16625?
[17:39] <jtaylor> infinity: I don't think so
[17:39] <infinity> A man can dream.
[17:39] <jtaylor> :)
[17:40] <infinity> jtaylor: Anyhow, I'll make sure at least that fix makes it into my next upload.
[17:40] <jtaylor> thx
[19:01] <arges> bdmurray: hey
[19:01] <bdmurray> arges: hi
[19:01] <arges> bdmurray: looking at the pending-sru queue now
[19:13] <cyphermox> bdmurray: see if upower has some kind of debugging there you could find how how it asks the mouse for battery
[19:22] <bdmurray> cyphermox: okay, thanks
[20:16] <Logan_> bdmurray: yeah so I apparently suck at SRUs
[20:16] <Logan_> what's the best way to push a fix to multiple stable releases, version-wise? :P
[20:17] <bdmurray> Logan_: well if I'd been on top of things we could of copied it from Precise to later releases
[20:17] <sarnold> Logan_: the security team has some version number examples here that might be uesful: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[20:18] <Logan_> sarnold: I pushed ubuntu0.1 to all four releases at once
[20:18] <bdmurray> Logan_: otherwise versioning like 0.12.04 and 0.12.10 would work as 10 > 04
[20:18] <Logan_> bdmurray: in the future, should I just push to, say, precise?
[20:18] <Logan_> and then have the SRU team copy up?
[20:19] <bdmurray> Logan_: no this is an exception because the version of d-rats was the same in all releases
[20:19] <Logan_> oh
[20:19] <Logan_> but, in that scenario, should I just push to the oldest?
[20:20] <bdmurray> its probably best to just use follow the security team recommendations
[20:20] <Logan_> I thought I was :(
[20:20] <bdmurray> so in this case 0.3.3-3ubuntu0.12.04.1
[20:20] <Logan_> ok
[20:21] <bdmurray> 0.3.3-3ubuntu0.12.10.1
[20:21] <bdmurray> etc...
[20:21] <infinity> Logan_: Uploading thr same to all won't work cause you'd get mismatched binary builds.
[20:21] <Logan_> gtocha
[20:21] <Logan_> infinity: oh right
[20:21] <Logan_> *gotcha
[20:21] <infinity> Logan_: In the rare case of "the same version is everywhere", then yes, if you upload to the oldest release, it can be copied.
[20:21] <Logan_> okay, cool
[20:22] <bdmurray> infinity: but not all SRU team members have the ability to copy though correct?
[20:22] <infinity> bdmurray: Don't see why not.
[20:23] <infinity> bdmurray: If you can copy from precise-proposed to precise-updates (which is what an sru release is), yo ushould be able to copy to quantal-updates too.
[20:23] <infinity> bdmurray: ACL checks don't care about the source, just the target.
[21:32] <_zap_> hi. i have a question about the efi boot process in ubuntu. there is a single grub efi binary in the ESP partition and another grub efi binary in the boot partition which contains the kernel. I appears that the ESP grub loads the boot partition grub but there is no config file for the ESP grub. so i am wondering how was the ESP grub built?