[01:07] <smoser> bdrung, i think its generally more functional to give me straightforward access to all data.
[01:08] <bdrung> smoser: i would prefer to keep a simple, supportable API.
[01:08] <smoser> how is returning a dict of data not supportable?
[01:10] <smoser> many times i've wanted data in the form that my function gets it.
[01:11] <smoser> its very common to want a release adjective, its version, and whether or not its an lts.
[01:29] <smoser> oh, i see. you're thinking about api other than python.
[01:29] <smoser> :-(.
[01:39] <bdrung> smoser: in case we want to change the file format, the content of the dict could change. the question is: which attributes would we guarantee to be present?
[01:41] <smoser> which of the ones i have there would you imply would not be present?
[01:41] <smoser> i didn't expose anything not already exposed
[01:41] <smoser> other than more conveniently
[01:42] <bdrung> we export codename, fullname, and release
[01:43] <bdrung> and codename
[01:43] <bdrung> how about accepting "all" as result to return a dict with these values?
[01:44] <bdrung> smoser: and you probably want a function that can map a codename to this kind of dict
[01:44] <bdrung> i'll go to bed now. good night.
[06:21] <pitti> Good morning
[06:22] <RAOF> Morning pittmasterflash!
[06:25] <pitti> RAOF: Qapla', member of the Klingon home world!
[06:26] <pitti> RAOF: oh, and you misspelt Qo'noS as "Khronos", BTW :)
[06:26] <RAOF> :P
[07:00] <pitti> cjwatson, jibel: hmm, why did britney trigger the python-imaging test? the binaries are still in NEW, so there's no point in running them
[07:05] <jibel> pitti, I did manually
[07:05] <pitti> jibel: ah, ok; thanks
[07:06] <jibel> I was verifying publication to the public instance, which is broken for new jobs
[07:13] <pitti> rbasak: sorry, I forgot: what's the reason why adt-virt-lxc has an --ephemeral switch which isn't the default? (as AFAICS you really always want this)
[08:55] <pitti> rbasak: I'm changing some CLI in 2.5 anyway, so now would be a good time to drop --ephemeral and replace it with --clone?
[09:00] <Laney> seb128: great!
[09:02] <seb128> Laney, what was that about? ;-)
[09:03] <Laney> eds calendar reply
[09:12] <seb128> Laney, oh, right ;-)
[09:22] <mlankhorst> slangasek: I was viewing the HWE session, I like how the kernel people only think about the kernel in their suggestions and forget the whole reason is userspace, repeatedly. ;)
[09:22] <mlankhorst> anyway auto upgrading X.org is HARD
[09:22] <mlankhorst> kernel can simply depend on a newer package, userspace on the other hand
[09:25] <mlankhorst> it has to do a scary path where all the old packages need to be removed and the new packages need to be installed.
[09:33] <pitti> eek, lxc regression
[09:41] <pitti> stgraber: FYI, filed bug 1253573; downgrading lxc unbreaks it
[09:48] <tseliot> pitti: do you know if a versioned breaks/replaces would work with a virtual package?
[09:48] <pitti> tseliot: no, virtual packages don't have versions
[09:49] <pitti> and thus Breaks: don't make sense for them
[09:49] <pitti> usually you C:/R:/P: virtual-pkg
[09:49] <pitti> or depend on them; there's not much else that you can do with them
[09:49] <tseliot> pitti: I suspected that, thanks
[09:50] <tseliot> pitti: I need to provide an icon within nvidia-settings, the same icon  which the nvidia-driver currently install (well, they actually ship a link to the icon)
[09:51] <tseliot> and I'm trying to avoid to conflict/break all the nvidia packages in nvidia-settings
[10:14] <pitti> tseliot: and you can't just put that into a different icon path?
[10:16] <tseliot> pitti: true, that would make things so much easier. Thanks
[10:50] <cjwatson> xnox: :native> mail me a repro recipe maybe?  :native on those targets should work ...
[10:53] <xnox> cjwatson: ok.
[10:54] <mlankhorst> can we have multiple versions of the same package in the same pocket?
[10:58] <cjwatson> mlankhorst: Not really
[10:58] <cjwatson> Occasionally you get multiple versions of a source for short periods, but it's only ephemeral
[10:58] <cjwatson> You certainly can't assume that anything like that will stick around for any length of time.  Pick a different design
[11:00] <mlankhorst> I see no sane way of upgrading between lts stacks then :/
[11:01] <mlankhorst> unless we stuff it in backports
[11:01] <mlankhorst> but that's not enabled by default either
[11:39] <ogra_> cjwatson, hmm, that germinate output seems to not take into account that recommends are off in ubuntu-touch
[11:39] <ogra_> (unless i'm reading the "Why" column wrong)
[11:40] <ogra_> (looking at http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.trusty/touch)
[11:44] <speakman> Hi folks! Any ideas how to programmatically set the "master" volume in Ubuntu? I can't find any way using DBus. Are there other ways? (And no, not simulate media key presses)
[11:44] <cjwatson> ogra_: I've fixed your seed STRUCTURE file to declare that properly.
[11:44] <ogra_> hmm, i thought you had done that ages ago ?
[11:44] <cjwatson> No.
[11:44] <ogra_> no, actually i'm sure you have
[11:44] <ogra_> in raring
[11:45] <cjwatson> Not in the seeds, only in livecd-rootfs.
[11:45] <ogra_> oh
[12:01] <mlankhorst> cjwatson: well the recommended way to rename packages is to provide a transition package. I really see no way to force an upgrade without one though. :/
[12:02] <mlankhorst> and a manual upgrade wouldn't need a new package, they could just install xserver-xorg-lts-saucy manually when it becomes available
[13:56] <rbasak> pitti: --ephemeral breaks tar extraction in certain I/O load conditions due to overlayfs.
[13:56] <rbasak> pitti: example: reproduce with the php dep8 test.
[13:57] <rbasak> pitti: it reliably reproduces for me on an openstack instance.
[13:59] <pitti> rbasak: ah, too bad
[14:11] <pitti> rbasak: so you'd recommend to keep "clone" as the default for the time being?
[14:12] <rbasak> pitti: right
[14:15] <pitti> rbasak: that's unpacking the orig.tar?
[14:16] <pitti> rbasak: I am just running them through adt-virt-lxc --ephemeral adt and it's way past that
[14:16] <pitti> hm, but that's on trusty
[14:18] <pitti> rbasak: finished, worked fine; did you see these problems on your local system too, or is that an issue with lxc in kvm on hardware (as we have in cloud instances presumably)
[14:18] <rbasak> pitti: it's when adt-run copies things in and out of the container.
[14:19] <rbasak> pitti: my failure happens right near the end of the php5 test. I can try and reproduce and give you access to the instance if you want to follow it up?
[14:20] <pitti> rbasak: not interested/capable of debugging overlayfs kernel bugs; but would be interesting to determine in which environments they happen indeed
[14:33] <infinity> mlankhorst: Why do you want multiple versions of something in a pocket?
[14:34] <mlankhorst> upload a 0~~ version that's only selected by pinning the version :P
[14:34] <mlankhorst> as a transition package
[14:34] <speakman> Once again; Any ideas how to programmatically set the "master" volume in Ubuntu? I can't find any way using DBus. Are there other ways? (And no, not simulate media key presses)
[14:35] <mlankhorst> I played around a bit, apart from forcefully doing apt-get install xserver-xorg-lts-saucy I don't see how you can upgrade automatically
[14:35] <infinity> mlankhorst: But if installing xserver-xorg-lts-saucy works, then upgrading works.  I'm a bit confused here. :P
[14:36] <mlankhorst> infinity: yeah but it doesn't allow opt-in automatic opt-in upgrading on EOL
[14:36] <infinity> mlankhorst: The thing we were discussing in the session is that there should just a -latest type package that matches the icky-named eol-upgrade package in the kernel.
[14:37] <mlankhorst> oh is that all?
[14:37] <infinity> mlankhorst: So, said -latest package would be updated to point to -lts-trusty when it's available, and job's done.
[14:37] <infinity> mlankhorst: Not sure why that's impossible or even hard. :P
[14:37] <mlankhorst> infinity: but if you upgrade to lts-saucy and then the latest version is lts-trusty, strange things happens
[14:37] <infinity> ...
[14:37] <infinity> mlankhorst: wat?
[14:38] <mlankhorst> I mean if the package pointed to lts-saucy before, and now points to lts-trusty
[14:38] <infinity> mlankhorst: That's a non-problem.  If you have lts-saucy installed and you install lts-trusty, the upgrade works.  Why would a package yanking you around not work the same?
[14:39] <mlankhorst> because in case of the kernel the solution is to only install a new package, and keep the old
[14:39] <infinity> Sure, okay, it'll not work in update-manager without serious quirking, because it tries to remove a ton of packages.
[14:39] <infinity> It'll work fine in apt.
[14:39] <mlankhorst> in case of userspace, it has to remove the packages from some 40 source packages, then install from another 40-ish new ones
[14:40] <infinity> There's nothing stopping us fixing that in update-manager, though.
[14:40] <infinity> Since we know the name pattern of packages that are going to be swapped.
[14:40] <mlankhorst> infinity: it only works if you manually resolve it with apt-get install, dist-upgrade won't I think
[14:40] <infinity> Don't see why dist-upgrade wouldn't work.
[14:40] <infinity> Except that no one's ever tried it because we don't have that -latest meta.
[14:41] <mlankhorst> except that I was just testing that now
[14:41] <mlankhorst> hm *tries without breaks/replaces/conflicts in meta package*
[14:41] <stgraber> pitti: thanks
[14:41] <infinity> What would it have been breaking/replacing/conflicting?
[14:41] <stgraber> smoser, hallyn_: bug 1253573
[14:42] <mlankhorst> infinity: was trying it to nudge apt-get in the right direction
[14:45] <hallyn_> stgraber: groan
[14:45] <mlankhorst> infinity: anyway to test.. install the lts-raring stack from the main archive, and upgrade-to-lts-saucy 0.0 deb from https://mblankhorst.nl/etc/ -- after that enable ppa:canonical-x/x-staging and try to upgrade upgrade-to-lts-saucy
[14:45] <mlankhorst> I tried a few variations but none get the correct answer
[14:45] <stgraber> hallyn_: I checked and the hook didn't change with the latest upload, so it must be something else...
[14:45] <smoser> stgraber, you have any idea what would have done that ?
[14:46] <smoser> did the interface to clone hooks change?
[14:46] <smoser> the only way i can see that failing that way is if /etc didn't exist in the target (quite odd) or $root_d was set wrong which gets set with the value of "$LXC_ROOTFS_MOUNT"
[14:47] <BrotherBrick> hello, can someone help push a SRU (for Ogre on Saucy) through? I can confirm that it works for me: https://bugs.launchpad.net/ubuntu/+source/ogre-1.8/+bug/1250924
[14:47] <stgraber> smoser: nothing obvious at least...
[14:49] <stgraber> pitti: can you pastebin your /var/lib/lxc/<container>/config and /var/lib/lxc/<container>/fstab?
[14:50] <hallyn_> pitti: and contents of /var/lib/lxc/<container>/rootfs/etc - i.e. does hostname exist there
[14:50] <stgraber> smoser, hallyn_: oh, one thing I just saw now is that it's a regression from saucy's LXC (alpha1) vs trusty's LXC (alpha3), so not just between alpha2 and alpha3, so quite a few more things that could have gone wrong
[14:50] <hallyn_> oh nm my q
[14:50] <infinity> BrotherBrick: I'll sponsor that.
[14:51] <showard> thank you infinity
[14:52] <stgraber> hallyn_: anyway, reproduced here with a clean container on trusty
[14:52] <BrotherBrick> awesome, thanks infinity :)
[14:52] <BrotherBrick> and OpenMW thanks you
[14:52] <stgraber> hallyn_: lxc-create -t ubuntu-cloud -n p1 && lxc-clone -o p1 -n p2
[14:53] <hallyn_> stgraber: ditto
[14:53] <stgraber> hallyn_: well, with the missing -- -r saucy since trusty doesn't seem available yet for ubuntu-cloud
[14:53] <smoser> stgraber, apt-get install distro-info
[14:53] <stgraber> hallyn_: we probably ought to add an autopkgtest once we get that one solved, easy enough to test ;)
[14:54] <stgraber> smoser: ii  distro-info     0.11         amd64        provides information about the dist
[14:55] <hallyn_> stgraber: ok i think i know the problem
[14:56] <hallyn_> it's because i stopped mounting rootfs for the dir case.  had to be done for lxc-create, wasn't ready to do it for lxc-clone
[14:56] <hallyn_> (for unprivileged use)
[14:56] <hallyn_> well,
[14:56] <stgraber> ah, that'd explain it :)
[14:56] <hallyn_> ah here we go,
[14:56] <hallyn_>                 if (setenv("LXC_ROOTFS_MOUNT", conf->rootfs.mount, 1)) {
[14:57] <hallyn_> that should be using bdev->dest.
[14:57] <hallyn_> but i need to run to a session
[14:57] <stgraber> yeah, I'm sure pitti can wait a few more minutes :)
[14:57] <stgraber> hallyn_: send that to lxc-devel when you have a minute, I'll ack, push to master and cherry-pick in the Ubuntu package
[14:58] <hallyn_> stgraber: cool, thanks
[15:00] <pitti> stgraber: in case you still need it: http://paste.ubuntu.com/6453636/
[15:01] <pitti> $ sudo cat /var/lib/lxc/adt/rootfs/etc/hostname
[15:01] <pitti> adt
[15:01] <pitti> stgraber: ^ and that
[15:06] <hallyn_> stgraber: sent
[15:17] <mlankhorst> infinity: anyway you should have all the pieces to reproduce that lts-stack switching doesn't work :-)
[15:18] <infinity> mlankhorst: Yeah, I don't have the time to play with it right now, but I believe you that it might need some work. ;)
[15:18] <mlankhorst> ìt really needs transition packages to do a smooth upgrade :\
[15:20] <seb128> Laney, mardy: https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-10&id=e99485221e2786bda015c14cc7f2287fd223d8aa
[15:21] <Laney> neat
[15:21]  * Laney tries
[15:21] <seb128> I can try as well, once I'm not in hangouts anymore
[15:21] <seb128> I'm not sure how much the hangout would like me switching to another user session
[15:30] <Laney> seb128: works for me now!
[15:30] <seb128> Laney, \o/
[15:32] <mitya57> Can anybody please reject https://code.launchpad.net/~m-alaa8/ubuntu/saucy/pcmanfm/fix-for-993996/+merge/195625 (See the last two comments)?
[15:33] <Laney> done
[15:42] <rbasak> pitti: I've reproduced the issue. I can give you access to the instance if you like?
[15:42] <mitya57> Thanks Laney.
[15:49] <mitya57> Also, https://code.launchpad.net/~albertsmuktupavels/gnome-panel/lp-1199074/+merge/196032 — please reject (duplicate of 196031)
[16:00] <stgraber> pitti: LXC uploaded to the archive
[16:02] <pitti> rbasak: sorry, between UDS sessions
[16:02] <pitti> stgraber: merci!
[16:08] <Saviq> mardy, joining the app startup session? we could use some faces in the hangout ;)
[16:10] <lool> cjwatson, pmcgowan, sergiusens: Can you guys make the framework followup session?
[16:11] <sergiusens> lool, oh, look at the time
[16:11] <sergiusens> joining
[16:11] <pmcgowan> lool, ah, was going elsewhere but will go there instead
[16:12] <mardy> Saviq: one minute
[16:14] <cjwatson> lool: remind me when that was?
[16:14] <lool> cjwatson: now  :-)
[16:14] <cjwatson> lool: er, I could have sworn I looked at the calendar invite and it was next week
[16:14] <lool> cjwatson: I didnt send any calendar invite
[16:14] <cjwatson> lool: I'm sorry, I'm already one-and-a-half booked for this session :-(
[16:14] <cjwatson> I definitely need to be in the sru/webapp session
[16:15] <lool> understood
[16:15] <lool> maybe we should followup after vuds then
[16:15] <cjwatson> I thought you'd booked it for outside uds for some reason
[16:15] <cjwatson> can you carry on without me and I can review it later?
[16:29] <pitti> xnox: wrt. porting to py3, did you notice my review in https://code.launchpad.net/~xnox/system-service/python3/+merge/192805 ?
[16:30] <xnox> pitti: yes, i did notice, didn't have time yet to fix it up yet.
[16:30] <pitti> xnox: ok, thanks (no hurry, just wanted to make sure it didn't get lost)
[16:55] <pitti> barry: I updated python-gconf status in your doc
[16:57] <barry> pitti: thanks!
[16:57] <seb128> pitti, can you share the url of that document? /me is curious of what is still using python (I guess that's the topic?)
[16:57] <seb128> s-c-p u1 mostly I guess?
[16:57] <pitti> seb128: https://docs.google.com/spreadsheet/ccc?key=0AiT4gOXSkmapdGdFejk0MjFydUlNMDVoMXNRdGdkbFE#gid=0
[16:57] <seb128> danke
[16:58] <pitti> seb128: hplip, ubuntu1, software-center, etc.; still quite a bit
[16:58] <barry> i'm hoping to at least attack s-c
[16:58] <barry> since mvo did so much work to get it nearly there, and we have some experimental xapian support in upstream svn
[16:59] <seb128> what are yellow/blue?
[16:59] <mitya57> Why isn't that doc linked from the blueprint?
[16:59]  * mitya57 adds a link
[16:59] <barry> blue means canonical is upstream
[16:59] <barry> yellow means there's some hope :)
[17:00] <barry> e.g. upstream has support, maybe not officially released, or not packaged yet, etc.
[17:00] <seb128> ok
[17:00] <barry> mitya57: thanks.  it's linked from the wiki spec
[17:00] <seb128> is s-c really worth the effort?
[17:00] <seb128> I though it was going to be deprecated
[17:00] <barry> ralsina_: says it is not going away for 14.04
[17:01] <seb128> it's buggy like that (see e.u.c), if we spend efforts on it we should spend those fixing bugs
[17:01] <Laney> surely not for 14.04
[17:01] <seb128> well, it's not like we are going to get ride of python2 for 14.04
[17:01] <pitti> right, there's almost no hope for hplip, s-c-p, sso, and the like
[17:01] <barry> not entirely, no
[17:02] <seb128> so s-c seems like wasted effort/chances to destabilize it more
[17:02] <pitti> so keeping s-c as it is in 14.04 would be sensible
[17:02] <seb128> if it's not properly maintained/moving forward, we should just fixes the most important bugs for the LTS and minimize resources spent on it imho
[17:02] <pitti> if we have so much time to spend on py3, let's rather do it on the pieces that we keep :)
[17:02] <seb128> right
[17:03] <barry> if that's the case (which is fine, there's plenty of other work to do), then it'll mean we won't need to spend time on deps that only those pieces pull in
[17:05] <barry> seb128, pitti, Laney if you guys can review the list (look at applications and library tabs) and let me know what has no hope of porting or just isn't worth it and i'll mark them in the spreadsheet
[17:06] <seb128> barry, sure, seems like pitti got the ones I know about
[17:07] <Laney> not sure what the deal is on ibus
[17:08] <barry> seb128: thanks
[17:08] <seb128> Laney, not sure about ibus either...
[17:09] <Laney> mmm
[17:19] <zyga> jodh: is http://upstart.ubuntu.com/wiki/DBusInterface the best place to learn about dbus interface for upstart?
[17:47] <pitti> rickspencer3, jono: yes, we'll support direct Q->T upgrades
[17:48] <pitti> (that was just discussed an hour ago)
[17:49] <jono> thanks pitti
[17:59] <rickspencer3> thanks pitti
[18:05] <tkamppeter> Anyone from the design team here? I am starting a session about the mobile print dialog now.
[19:52] <jodh> zyga: currently, yes. it's on my todo to add a table to the cookbook...
[20:29] <Noskcaj> Is there a way to test if a package will build on ARM? Some GL changes to evas mean it can be synced if it build on ARM IIRC
[20:31] <ogra_> Noskcaj, you could use a PPA ... got to #launchpad and ask them to enable armhf for it
[20:31] <tumbleweed> Noskcaj: or create an arm schroot / pbuilder (using qemu-user-static)
[20:31] <Noskcaj> I'll do the first one
[20:45] <zyga> jodh: thanks
[21:27] <bdmurray> cyphermox: bug 1198315 is missing SRU information
[21:28] <cyphermox> oh, oops, quite right
[21:29] <cyphermox> bdmurray: actually, could you reject it, I have a patch that would be better than what I uploaded earlier
[21:31] <bdmurray> cyphermox: done
[21:31] <cyphermox> thanks
[22:38] <RAOF> slangasek: This is your UTC+11-morning last-night's vUDS reply message… No, we won't have a system compositor on the desktop by default for 14.04; only XMir or Unity8 would run under a system compositor, and we've stated we're not going to be defaulting to either of those for 14.04
[22:52] <bdmurray> bdrung: your upload of apt-mirror to the precise proposed queue does not reference bug 977278
[22:52] <bdrung> bdmurray: ups
[22:54] <bdrung> bdmurray: should i reupload it?
[22:54] <bdmurray> bdrung: that'd be great and if you let me know I'll approve it
[23:06] <bdrung> bdmurray: reuploaded
[23:29] <slangasek> RAOF: so, we wouldn't consider using the system compositor up to the greeter, e.g., and then stopping it in favor of X?
[23:30] <RAOF> You mean up to and including the greeter, right?
[23:31] <slangasek> RAOF: yeah
[23:31] <RAOF> That wouldn't solve the text-on-shutdown problem, and would require us to have nvidia and fglrx drivers that I hope we'll have but am not sure that we'll have...
[23:31] <slangasek> righto
[23:31] <RAOF> And I'm not sure how it'd interact with user switching; we'd need to bring the sc back up for the greeter, then tear it down again for X, etc?
[23:31] <RAOF> Hm, no, that bit would be fine.
[23:32] <RAOF> We'd just do the same VT dance we normally do.
[23:32] <RAOF> Hm.
[23:32]  * slangasek nods
[23:32] <RAOF> And that actually *would* solve the text-on-shutdown problem, assuming we did things in the right order...
[23:34] <RAOF> And we wouldn't actually stop the sc, we'd just VT switch from it, so the greeter could still be all up andn ready.
[23:35] <RAOF> slangasek: So, I think there are only two reasons why we wouldn't be able to have a sc - (a) do we have the manpower, and (b) will we get nvidia/fglrx Mir drivers?
[23:39] <sarnold> are there any concerns about multiple GUI contraptions taking up memory bandwidth and disk bandwidth when paging them in?
[23:40] <RAOF> The sc would be pretty small; probably on the order of X (which ends up being ~20MB), and we could make it even smaller if necessary.
[23:41] <sarnold> ah once they hit steady state tht's not so bad
[23:46] <slangasek> RAOF: <nod>


[01:00] <menn0> wallyworld: thanks for the review
[01:00] <wallyworld> menn0: no worries, might be worth an eyball from andrew also?
[01:01] <menn0> axw_: ^^ https://github.com/juju/juju/pull/7738 pls
[01:01] <menn0> wallyworld: I've got a monster ready for review once this one lands :)
[01:02] <wallyworld> i bet
[01:14] <axw_> menn0: looking
[01:23] <axw_> menn0: LGTM, thanks
[01:24] <axw> babbageclunk: in case you've not seen them, I have a couple of PRs up for review on 1.25-upgrade
[01:24] <babbageclunk> axw: oh sorry - looking at them now
[01:26] <axw> babbageclunk: I have some more changes in the works, which ~require me to make use of the juju2 tree. to build some of the juju2 packages, I have to kill some of the (unused) code as it doesn't all build with the dependencies required by juju1
[01:27] <babbageclunk> axw: Yeah, I had to make some small changes in juju2 to resolve version conflicts before too.
[01:29] <anastasiamac> axw: could u PTAL @ https://github.com/juju/juju/pull/7740 (state pwd reset in prep for token re-issuing)
[01:29] <axw> anastasiamac: okey dokey
[01:29] <anastasiamac> axw: \o/
[01:42] <babbageclunk> axw: both approved
[01:42] <axw> babbageclunk: thanks
[01:44] <axw> babbageclunk: by "to the description", you mean in the output displayed to the user?
[01:48] <babbageclunk> axw: oh, no - I meant on the PR. But actually, that might be good call too.
[01:48] <axw> babbageclunk: ah right, ok
[01:53] <thumper> wallyworld: https://github.com/juju/juju/pull/7742
[01:53] <wallyworld> looking
[02:01] <wallyworld> thumper: lgtm with a suggestion
[02:01] <thumper> wallyworld: ta
[02:03] <wallyworld> axw: small one. for some reason, the cloud city creds didn't work for me, with any azure region, not just the new ones https://github.com/juju/juju/pull/7743
[02:08] <axw> wallyworld: LGTM, thanks
[02:09] <wallyworld> ta
[02:36]  * babbageclunk goes for a run
[02:52] <thumper> wallyworld: are long running actions landed?
[02:52] <thumper> and are they 2.3?
[02:53] <wallyworld> thumper: no, there was disagreement about the spec/solution
[02:53] <wallyworld> so sort of put on hold
[02:53] <thumper> hmm...
[02:53] <thumper> disagreement between whom?
[02:53] <wallyworld> next thing was going to be action file i/o
[02:54] <wallyworld> disagreement internally - what stakeholders wanted was quite loosely defined
[03:09] <axw> babbageclunk: I know it doesn't matter too much, but the command name "verify-source" doesn't sit well with me. I'm thinking of renaming it, perhaps to "export-source". thoughts?
[03:10] <axw> babbageclunk: and I'm thinking of making it responsible for installing LXD on the LXC hosts...
[03:38] <wallyworld> i have 2 PRs that need reviewing if anyone is bored... https://github.com/juju/juju/pull/7741 https://github.com/juju/juju/pull/7744
[03:59] <menn0> babbageclunk, wallyworld: here's the big GetModel removal: https://github.com/juju/juju/pull/7745
[03:59] <menn0> +353, -473
[04:01] <babbageclunk> axw: I'm fine with that - the command predates me. Although I wasn't envisaging that we'd be exporting, saving the output, then importing - there are things like charms to think about too.
[04:01] <babbageclunk> menn0: ok, looking now
[04:04] <wallyworld> menn0: looking
[04:04] <menn0> thanks guys
[05:32] <axw> babbageclunk: ah ok. maybe we should just stop writing out the model description then
[05:33] <axw> babbageclunk: I'll leave it for now
[05:34] <babbageclunk> axw: yeah, it's useful for now, but I don't think we'd want it to be dumped for users. Maybe make it an option.
[06:05] <axw> babbageclunk: so I've put up https://github.com/juju/1.25-upgrade/pull/16, which augments the model description written by verify-source. the meat is in a function, so it should be reusable in the command used to import into the target controller
[06:16] <thumper> poo
[06:16] <thumper> I have an initialization loop
[06:16]  * thumper things how to unloop it
[06:17] <thumper> axw: I don't suppose you have 5 minutes?
[06:17] <axw> thumper: for you I might even have 6
[06:17] <thumper> :)
[06:18] <thumper> 1:1?
[06:18] <axw> thumper: ok, brt
[14:18] <mup> Bug #1710886 opened: juju 2.1 issues certificates with wrong DNS alternative names on juju upgrade. <juju-core:New> <https://launchpad.net/bugs/1710886>


[00:50] <xnox> Laney: did i break transition tracker or has it not updated yet?
[00:51] <xnox> (see my recent commits on +junk)
[05:04] <pitti> Good morning
[06:34] <tvoss_> doko, ping
[06:38] <tvoss_> cjwatson, you might know, too: which package contains the STL pretty printers for gdb?
[06:47] <tvoss_> doko, we are looking into getting pretty printers for the STL working and would need some help :)
[06:58] <pitti> RAOF: hey Chris, how are you?
[06:58] <pitti> RAOF: are you still doing SRU? it would be great if some SRU member could accept the postgresql uploads for all releases (it has an MRE, no packaginag changes, all auto-tested, so shoudl be easy)
[06:58] <pitti> people keep asking me for them..
[06:59] <RAOF> pitti: Sure.
[07:13] <dholbach> good morning
[07:16] <RAOF> pitti: 9.1 or 8.4?
[07:16] <RAOF> pitti: Or, I guess, both?
[07:16] <pitti> RAOF: both for precise, 9.1 for quantal/raring, 8.4 for lucid
[07:16]  * RAOF will deal with that after dinner, it seems.
[07:17] <rbasak> infinity: what do you think about an SRU for http://launchpadlibrarian.net/144462697/dpkg_1.16.10ubuntu2_1.16.10ubuntu3.diff.gz? We're backporting juju-core for the cloud archive, to build against a barely modified Precise, and so I we need to carry that dpkg patch - either in the cloud archive or as an SRU in precise-updates.
[07:18] <rbasak> I assumed we'd need to carry it but just noticed <IP_ADDRESS>ubuntu7.1 and wondered.
[07:18] <rbasak> (we'll probably need to carry it in the short term anyway, so we can have a working juju-core on Thursday)
[07:21] <pitti> RAOF: thanks (btw, no need to actually review the upstream diff that much)
[07:28] <pitti> slangasek, xnox: I tested automatic and manual partitioning with EFI in qemu, and manual partitioning on my workstation, and it has always worked, so it seems this bug either got fixed, or I can't reproduce it any more
[07:39] <soren> cjwatson: I'd never heard of RUNPATH before... Reading the docs about it, I'm a bit confused then RPATH would be preferable over over RUNPATH  (particularly since man ld-linux.so(8) explicitly says RPATH is deprecated).
[08:15] <Laney> xnox: looking
[08:15] <xnox> Laney: thanks.
[08:15] <Laney> woah
[08:16] <Laney> didn't expect you to be up
[08:16]  * xnox why not?
[08:16] <Laney> 14/10 01:50:54 <xnox>
[08:16] <xnox> oh that... =) well..... release week jibbies.
[08:17] <infinity> mlankhorst: xdiagnose could do without all the .git noise in the package.  Can you build it with '-i -I'?
[08:17] <mlankhorst> yeah just delete it, I'll ask for tjaalton to responsor, didn't notice it. :P
[08:19] <infinity> rbasak: I'd be happy to SRU that back ASAP.
[08:19] <infinity> rbasak: It's easy enough to validate and push through without a 10-day wait, IMO.
[08:20] <rbasak> infinity: thanks. I'll get on to it now then. What do you think about regressions for rebuilds of other armhf packages? I can't think of anything specific, but it does seem to have a rather large window.
[08:21] <infinity> rbasak: Hrm?  It shouldn't cause any regressions.
[08:21] <infinity> rbasak: I need to SRU to add ppc64el too, let me prep it.
[08:22] <rbasak> infinity: yeah I can't think of anything either. Just that it has the potential to impact many things.
[08:22] <rbasak> infinity: OK, I'll leave the patch/upload to you then? I'll do the bug paperwork.
[08:22] <infinity> rbasak: It shouldn't impact anything.  If things have the new ABI tags, they'd pass both tests, if they lack the new ABI tag, they'll fall through to the old test, if they lack both, they'll fail as always.
[08:23] <rbasak> Right.
[08:23] <infinity> rbasak: And yes, please SRUify the bug for me, that would be great.
[08:23] <Laney> xnox: It has the revision, waiting to see if it runs normally
[08:27] <caribou> I need advice from someone familiar with start-stop-daemon in init-scripts;
[08:27] <caribou> the stud init-script stop portion uses --pidfile (as the start section) which restricts the SIGKILL to the parent PID
[08:27] <caribou> if I understand it correctly
[08:28] <caribou> but STUD has children processes so when we do 'invoke-rc.d stud restart', the start comes in while the children still have the socket open and fails
[08:29] <caribou> bug 1123950
[08:30] <caribou> my question is : would it be a problem to remove the --pidfile from the 'start-stop-daemon --stop' while keeping it in use in the 'start-stop-daemon --start' section ?
[08:31] <caribou> the --pidfile in the start section is required so STUD can start multiple instances
[08:32] <xnox> Laney: looks good. Hm I wonder why it didn't update before? how often is it cronned for?
[08:32] <xnox> Laney: (after the move)
[08:33] <Laney> I found a missing occurence of arm64
[08:33] <Laney> (in the runner script)
[08:35] <rbasak> infinity: the bug is ready
[08:35] <rbasak> (bug 1187722)
[08:36] <cjwatson> tvoss_: I always assumed those were in the gdb package itself
[08:36] <cjwatson> soren: I think RUNPATH is generally better, it's just newer
[08:39] <infinity> rbasak: Cool, I'll upload today, and we co do a quick verification turnaround.
[08:39] <infinity> rbasak: Verifying my ppc64el change takes about half a second, so that won't hurt your chances. :)
[08:39] <rbasak> Thank you!
[08:39] <rbasak> jamespage: ^^ infinity will SRU the dpkg fix to Precise
[09:06] <xnox> Laney: ah, ok. and why is boost1.53 still there? i thought that should be auto-garbage collected (or is it removed only after X days of not being updated or some such?) /me's memory is fuzzy
[09:07] <Laney> xnox: 3 days
[09:07] <infinity> caribou: The point of pidfile is to limit the stopping to only the thing you started.  If children take a while to eff off, you might want to find a way around that...
[09:09] <caribou> infinity: yeah, I understood that, but in the case of stud, it loops through the whole set of parents to stop them anyway so I thought that stopping all procs at once would be acceptable
[09:10] <infinity> caribou: It loops through all the parents *it started*, I assume.  Not all the occurrenced of that process name on the host.  Subtle, but important, difference.
[09:10] <caribou> infinity: the alternative is to have stud manage the ramping of of his children when the parents is told to exit, which is what the Debian maintainer suggest
[09:10] <infinity> caribou: Having the parent not exit until all the children do is probably the right answer.
[09:11] <caribou> infinity: indeed; ok that answers my query; thanks
[09:12] <caribou> infinity: in the case of stud; it does stop --pidfile on all the stud configurations present in /etc/stud so that would be all of them anyway but it is indeed a better solution
[09:13] <infinity> caribou: That's not all of them on the system, that's all of them on that root.
[09:13] <infinity> caribou: Think chroots.
[09:14] <caribou> infinity: yup, true I have too much of a server centric view
[09:14] <caribou> infinity: and this is *exactly* the clarification I was after!
[09:14] <infinity> caribou: I have a server-centric view too, clearly just different types of servers. ;)
[09:16] <caribou> infinity: btw, we have a current workaround to add a "sleep 1" in the start sequence that seems to work; does that sound like a valid option for SRU up until we get the final fix from Debian ?
[09:16] <caribou> I have a debian bug opened on this one btw
[09:17] <infinity> caribou: A sleep is an icky but valid workaround, a second seems optimistic, if it could potentially be under load or running on a slow machine.
[09:17] <caribou> bug 1123950
[09:17] <caribou> infinity: ok, I'll look into it
[09:44] <infinity> rbasak: What was the bug number for that?  I didn't seem to mention it in my previous changelog entry (naughty me).
[09:47] <rbasak> infinity: bug 1187722
[09:56] <infinity> rbasak: http://paste.ubuntu.com/6235232/ <-- Sanity check.
[09:56]  * rbasak looks
[09:59] <rbasak> infinity: lgtm
[10:05] <infinity> rbasak: Alright, I'll do a quick test build and local test and then upload and see if I can find a fellow SRU member to review and let it in for me.
[10:10] <rbasak> infinity: FWIW, before I spoke to you earlier I verified that the patch applied against dpkg precise successfully builds saucy golang on precise. Just another (non-SRU-team, non-dpkg-uploader) data point.
[10:11] <infinity> rbasak: Shiny, it's uploaded.
[10:11] <infinity> cjwatson: Can I get you to do a quick SRU review of dpkg in precise-proposed?  We need to fasttrack this for server team stuff.
[10:19] <cjwatson> infinity: done
[10:19] <infinity> cjwatson: Danke.
[10:54] <infinity> rbasak: Once that builds, want to re-verify your bug with the archive binaries?  I'll verify my bug.
[10:55] <infinity> rbasak: Oh, look, it's already built and published, even.
[11:01] <rbasak> infinity: ack. Working on it.
[11:03] <wgrant> didrocks: Around? unity needs a trivial arm64-specific patch to build there (just extending the existing -fPIC that's conditional on amd64 and armhf to arm64). But it would need to be uploaded quickly.
[11:04] <wgrant> didrocks: Is it reasonably practical to get something like that in ASAP, or does the autolander make it awkward?
[11:04] <didrocks> wgrant: we can always fast-pass the merge in trunk
[11:04] <didrocks> wgrant: let me look at what's in trunk that was not released
[11:04] <wgrant> I'll pretend I know what that means.
[11:04] <infinity> Ideally very fast, I intend to lock down the archive for seeded uploads after I've had lunch.
[11:05] <infinity> But I'd like to see this fix in for kicks, if we can make it.
[11:05] <didrocks> wgrant: first, do you have a MP somewhere?
[11:05] <wgrant> No, I'm still downloading the branch
[11:05] <wgrant> if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86_64" OR ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l")
[11:05] <wgrant> is the line, needs to also match "aarch64"
[11:06] <didrocks> infinity: there are 2 commits in unity trunk that are not released yet, if I test that quickly, does the release team +1 for them?
[11:08] <infinity> didrocks: Toss me a quick diff somewhere?
[11:08] <infinity> didrocks: But if they're both bugfixes and obviously sane, I'm fine with that.
[11:09] <didrocks> infinity: http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3567 and http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3568
[11:10] <didrocks> they seem sane to me, I want to give them a 10 minutes poke first though
[11:10] <lool> didrocks, infinity: http://paste.ubuntu.com/6235437/
[11:10] <lool> debdiff
[11:13] <infinity> didrocks: Both those look fine to me.
[11:13] <didrocks> infinity: I'm currently testing, as soon as wgrant has the MP ready, I'll push that and run a build
[11:13] <infinity> didrocks: If those test fine, and you grab wgrant's change, we'll call that the final non-SRU upload for the release. :P
[11:13] <didrocks> infinity: \o/
[11:14] <cjwatson> infinity: (ubiquity, possibly)
[11:14] <wgrant> No changelog change required?
[11:14] <didrocks> oh no, wanted to be the latest!
[11:15] <didrocks> wgrant: no, just give a sane commit message :)
[11:15] <infinity> cjwatson: I meant the final non-sru unity upload.
[11:15] <infinity> cjwatson: I'm confident that we'll have installer uploads.
[11:15] <infinity> cjwatson: I have to do one or two myself still. :/
[11:16] <infinity> Okay, lunch.  Back in a bit.
[11:16] <cjwatson> ah right
[11:19] <wgrant> didrocks: https://code.launchpad.net/~wgrant/unity/arm64-pic/+merge/190919
[11:20] <didrocks> wgrant: pushing your change to trunk and then kicking a rebuild
[11:20] <didrocks> thanks :)
[11:20] <wgrant> Thank you :)
[11:22] <lool> didrocks: are you running the ci stuff?
[11:22] <lool> didrocks: can kick it if you like
[11:22] <didrocks> lool: already on the page
[11:22] <didrocks> (started)
[11:22] <lool> already merged I guess
[11:23] <didrocks> yep
[11:23] <lool> and cu2d building ok
[11:32] <doko> tvoss_, hi
[11:33] <tvoss_> doko, hey
[11:33] <doko> tvoss_, should be in the libstdc++6-4.8-dbg package
[11:33] <tvoss_> doko, those are all python2, and gdb is linked against python 3
[11:35] <doko> tvoss_, wait, I had a patch for that ...
[11:36] <tvoss_> doko, would be quite helpful :) plus: can we wire that up to our retracing infrastructure, too? Would love to have more readable stack traces
[12:16] <steveire> Is it known that clang++ doesn't work with the stl in 13.10?
[12:18] <steveire> http://pastebin.kde.org/pzd9fvzs2
[12:59] <tvoss> doko, did you have any luck digging up your patches?
[13:08] <sabdfl_> hi folks, quick q re whoopsie in syslog
[13:09] <sabdfl_> seems like I have a steady stream of debugging info there - whoopsie online / offline
[13:09] <sabdfl_> is that expected, or a bug? can we dial back on the chatter?
[13:17] <ev> sabdfl: yes, filed as https://bugs.launchpad.net/whoopsie/+bug/1239690
[13:35] <doko> tvoss, won't be for saucy
[13:36] <tvoss> doko, can you point me to the patch?
[13:37] <doko> tvoss, http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.8/debian/patches/libstdc%2B%2B-python3.diff?view=log
[13:39] <sabdfl> ack, thanks ev
[13:39] <rbasak> infinity: verification-done on bug 1187722. Thanks!
[13:56] <tedg> xnox, Hmm, did you push to this branch?  https://code.launchpad.net/~xnox/libdbusmenu/fix-arm64/+merge/190847
[13:56] <xnox> tedg: yes.
[13:56] <xnox> tedg: on behalf of doko (he didn't want to deal with branches/upstream merger / daily landing etc)
[13:57] <tedg> xnox, Hmm, seems LP doesn't think there's any diff...
[13:57] <xnox> tedg: i believe that's in the archive already thus, needs merge into upstream branches to unbreak integration.
[13:57] <xnox> tedg: LP sent me an OOPS via email failing to generate diff.
[13:57] <cjwatson> LP is on "updating diff" implying it oopsed
[13:57] <cjwatson> xnox: delete the branch and repush
[13:57] <cjwatson> (and probably re-MP)
[13:57] <xnox> cjwatson: ok.
[13:57] <cjwatson> that's usually the simplest way
[13:58] <xnox> hm, branch is updating as well.
[13:58] <cjwatson> might want to keep the MP window open in a tab :)
[13:58] <cjwatson> s/window //
[13:58] <cjwatson> xnox: same thing
[13:58] <xnox> ack.
[13:58] <cjwatson> rare on small branches, sadly pervasive on large ones like ... er, LP itself
[13:59] <cjwatson> so I've got used to it
[13:59] <xnox> ok. first time happening to me =)
[14:08] <xnox> tedg: https://code.launchpad.net/~xnox/libdbusmenu/fix-arm64/+merge/190967
[14:08] <xnox> tedg: better?
[14:09] <tedg> xnox, No hugs and kisses in the MR? ;-)
[14:09] <tedg> xnox, Thanks!  Approved.
[14:09] <xnox> =)
[14:10]  * xnox blows a kiss to PS jenkins integrator
[15:09] <psusi> anyone know how to translate a UTF-16 string into whatever the native C string format the process is using?
[15:20] <doko> tvoss, http://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=6980
[15:22] <xnox> psusi: libicu?
[15:23] <tvoss> slangasek, ping
[15:24] <pitti> psusi: wcrtomb() convers a wchar_t string to an UTF-8 char string; that might be what you want?
[15:24] <pitti> psusi: sorry, that's for an individual character; you probably want wcsrtombs()
[15:25] <psusi> pitti: I don't have a wchar_t, I have UTF-16
[15:26] <pitti> psusi: iconv_open("UTF-16", "UTF-8");
[15:26] <pitti> psusi: or use libicu (haven't tried that, though)
[15:26] <psusi> there's really nothing in the standard C library to do that?
[15:26] <psusi> I hate to add another dependency
[15:27] <cjwatson> libiconv is a bit fiddly but not hopelessly painful
[15:27] <cjwatson> If you're already using glibc, it's there
[15:27] <pitti> libiconv is reasonably close to glibc, isn't it?
[15:27] <psusi> ohh
[15:27] <cjwatson> It's built into glibc on GNUish systems
[15:27] <cjwatson> It's not in every libc
[15:27] <psusi> well here's the other thing... I don't know if I want to convert it to UTF-8... doesn't the locale determine the proper encoding, which may not be UTF-8?
[15:28] <cjwatson> nl_langinfo (CODESET)
[15:28] <pitti> yes, that's right; if you want to directly show that on stdout or so (most toolkits actually always expect UTF-8 as input regardless of the locale)
[15:28] <cjwatson> again somewhat libc-dependent, there are bits in e.g. gnulib to help
[15:29] <cjwatson> so with gnulib it's locale_charset ()
[15:29] <psusi> well parted right now is using the w*mb* family of functions and passes around char *
[15:29] <cjwatson> parted uses gnulib, so it wouldn't be particularly painful to add more modules from there
[15:29] <cjwatson> in fact you already have locale_charset
[15:30] <cjwatson> and for that matter all the iconv bits
[15:30] <doko> xnox, did you get feedback from ev about whoopsie's b-d on valgrind?
[15:30] <psusi> the problem seems to be that when it reads a UTF-16 string from the gpt, it discards the upper 8 bits and calls it a char *... for non ascii strings, that leaves it with bogus encodings when it tries to convert that to wchar_t from the locale encoding
[15:31] <cjwatson> if you have a known source encoding you should store it in that encoding if you need to round-trip, and iconv to the locale encoding for display
[15:31] <psusi> so I need a char * that instead has valid encodings in whatever the correct locale is
[15:31] <cjwatson> char * is just a sequence of 8-bit characters, it would depend on the function you're using to read into it what gets discarded, not on the type as such
[15:31] <xnox> doko: he is in front of me, and says he does not care for saucy about that =)
[15:32] <xnox> doko: since no-one will be using whoopsie for a while on arm64.
[15:32] <cjwatson> although for the case you're talking about I would be inclined to treat the GPT data as a byte array except when converting for display
[15:32] <psusi> right.. the function just has a loop assigning each 16 bit source char to an element in the char *, thus discarding the upper 8 bits
[15:32] <xnox> doko: i'll fix it in saucy? or do you want it for bragging points?
[15:32] <cjwatson> haha
[15:33] <cjwatson> yeah, that's not too smart
[15:33] <psusi> the name is displayed and I think also sometimes substitued into messages that are then translated with gettext
[15:33] <cjwatson> But surely the code itself gives you the answer
[15:33] <cjwatson>   char name[37];
[15:33] <cjwatson>   for (i = 0; i < 72 / sizeof (efi_char16_t); i++)
[15:33] <cjwatson>     gpt_part_data->name[i] =
[15:33] <cjwatson>       (efi_char16_t) PED_LE16_TO_CPU ((uint16_t) pte->PartitionName[i]);
[15:34] <cjwatson> rather suggests (reasonably) that name should be an array of efi_char16_t
[15:34] <psusi> so with the 8 high bits chooped off, it doesn't survive the trip through gettext to wchar_t and back to utf-8 for printing
[15:34] <psusi> cjwatson: sure, but then get_name and set_name only pass/excpect a char *
[15:34] <psusi> so it needs converted
[15:34] <cjwatson> either that, or, if it's more convenient for iconv, a byte array in whatever endianness is correct
[15:35] <cjwatson> psusi: right, get_name and set_name are to/from display clearly, and want converters at their borders
[15:35] <cjwatson> psusi: but I'd suggest that you should otherwise store in a fairly raw format, since otherwise you may introduce round-trip errors
[15:35] <doko> xnox, just did see avtivity-log-manager dep-waiting, but that's an ev package too. but well, with his new hat on ... ;)
[15:35] <psusi> aye
[15:36] <cjwatson> the user's encoding may not be able to represent all the characters in the label, for instance
[15:36] <psusi> right
[15:36] <cjwatson> iconv () takes pointers to char * buffers
[15:36] <cjwatson> which is fair enough, so that would suggest you just want to fix the loop there to be less rubbish
[15:37] <cjwatson> I can sort of see what it's trying to do in _partition_generate_part_entry
[15:37] <psusi> yea... fix the terrible loop, and convert in the get/set methods
[15:37] <cjwatson> You could instead do *((efi_char16_t) &gpt_part_data->name[i]) = ...
[15:38] <cjwatson> or something like that.  But I'm not sure that's the clearest option
[15:39] <cjwatson> actually i * 2 and bump the size of the array
[15:39] <cjwatson> you get the idea :)
[15:40] <doko> tvoss, http://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=6980
[15:41] <cjwatson> psusi: bug 1220165 is indeed weird, but reproducible every time here.  I wish we were using udev cookies in the right way
[15:42] <psusi> cjwatson: iirc, cookies are a device-mapper thing arent' they?
[15:42] <cjwatson> psusi: they're a fairly general concept that device-mapper happens to be one thing that implements
[15:42] <psusi> cjwatson: so who is adding the partition?  did we enable a partx rule or something?  a change event that makes someone else open the device shouldn't cause that...
[15:43] <cjwatson> I've seen buggy udev rules in the past that responded to change events that way
[15:43] <cjwatson> they're a proper nightmare to track down
[15:43] <psusi> what way?
[15:43] <cjwatson> by opening the device ...
[15:43] <psusi> sure, we have plenty of those
[15:43] <psusi> but they won't cause that error
[15:43] <cjwatson> oh I think I see what you mean
[15:43] <cjwatson> hmm
[15:44] <psusi> this has to be someone else actually ADDING the partition, after it has successfully been removed
[15:44] <cjwatson> I wish I could find a way to instrument this without it vanishing
[15:44] <psusi> can you set a kprobe on the blkpg stuff?
[15:44] <psusi> or trace
[15:45] <xnox> doko: pushed fix to lp:whoopsie, but infinity doesn't want it in, as it wasn't ev who proposed the fix =))))))
[15:45] <psusi> and besides partitioning tools, the only other thing I know of that adds partitions is partx
[15:45] <psusi> so unless someone added a udev rule to run partx -a...
[15:46] <cjwatson> there is /lib/udev/rules.d/95-partx.rules
[15:46] <cjwatson> kpartx sorry
[15:46] <cjwatson> (and a similar thing for dmraid but I doubt it's that)
[15:46] <psusi> right, those only apply to dm
[15:47] <cjwatson> the kpartx rules should also only be for dm-*
[15:47] <cjwatson> but, let me try removing them and seeing what happens
[15:48] <cjwatson> nope, not kpartx
[15:48] <psusi> blast... doesn't seem to be a kernel trace event in the partition add path
[15:48] <psusi> yea, kpartx just creates a new dm device anyhow, doesn't know about BLKPG
[15:49] <psusi> it's regular partx that does that
[15:49] <psusi> unless... someone is calling BLKRRPRT?
[15:51] <cjwatson> I could strace -f udevd; it'll probably make the bug vanish, but I could look for block ioctls
[15:51] <psusi> I'd say kprobe it at the source in the kernel... get exactly what you want without dragnetting and changing timing
[15:52] <psusi> just one printk in those two ioctls
[15:52] <cjwatson> psusi: I can't realistically install a new kernel; which existing trace event would you suggest?
[15:52] <cjwatson> (I've not used kprobes before - if you have a recipe I'd appreciate it)
[15:52] <psusi> I don't see an existing trace event... and I've not yet figured out how to use kprobes myself either
[15:53] <psusi> but supposedly it is fairly simple to add a printk somewhere, build and insert the module, and bam
[15:54] <psusi> where fairly simple is, as usual, once you climb the initial learning curve ;)
[15:54] <cjwatson> stracing udev didn't perturb the bug away, actually
[15:54] <cjwatson> but it also doesn't show any BLKPG* or BLKRRPART
[15:55] <psusi> it wouldn't be issued by udev directly but by something it executes
[15:55] <cjwatson> yes I used -f, of course
[15:55] <psusi> ahh, right
[15:55] <cjwatson> are you sure that a duplicate add is the only possible cause of EBUSY here?
[15:56] <psusi> only way I can see... you only get to the add call if the remove succeeds or fails with ENXIO
[15:56] <cjwatson> also happens if the add attempt overlaps an existing partition
[15:57] <psusi> i.e. the device was removed, or already does not exist
[15:57] <psusi> ohh, right
[15:57] <psusi> aha!
[15:57] <cjwatson> or if the partition number already exists, or if kzalloc fails
[15:58] <psusi> I bet it's overlapping
[15:58] <cjwatson> let me strace parted_server to see what it's doing
[15:59] <psusi> yea... didn't think of this when I made the patch to avoid removing and re-adding unmodified partitions
[16:00] <psusi> there's a higher numbered partition ( thus has not been removed yet ) that overlaps with the partition we are trying to add
[16:02] <psusi> yea... that loop needs to be split in two passes... first remove partitions that don't match the new table, then loop again adding the new ones after the first loop has already removed all of the modified old ones
[16:04] <psusi> so yea, it isn't a race at all ;)
[16:06] <cjwatson> 17:00 <cjwatson> psusi: hm, this is an "erase disk" install
[16:06] <cjwatson> 17:01 <cjwatson> psusi: but maybe some of the partitions happen to coincide in extent
[16:06] <cjwatson> psusi: yes, looking at the trace, there's an add with no matching remove
[16:06] <psusi> working up a patch now
[16:07] <cjwatson> what's the bug?  you're a little ahead of me here
[16:07] <cjwatson> in fact, it's attempting a resize, not an add
[16:07] <cjwatson> 4041  16:02:52.716798 ioctl(6, BLKPG, {0x3 /* BLKPG_??? */, flags=0, datalen=152, {start=1048576, length=52613349376, pno=1, devname="/dev/sda1", volname=""}}) = -1 EBUSY (Device or resource busy)
[16:07] <psusi> I guess you lagged out... I think there's an existing partition on the disk that we are wiping out and it overlaps the new partition we are trying to add
[16:08] <psusi> but it has a higher partition number than the one we are trying to add
[16:08] <cjwatson> 3 == BLKPG_RESIZE_PARTITION
[16:08] <cjwatson> just checking that theory against the logs
[16:08] <psusi> so it hasn't been removed yet
[16:08] <cjwatson> yeah, that's right
[16:08] <cjwatson> prior state:
[16:09] <cjwatson> 1   1048576-28468895231<PHONE_NUMBER>6     primary ext4
[16:09] <cjwatson> 6<PHONE_NUMBER>6-52615446527<PHONE_NUMBER>2     logical ext4
[16:09] <cjwatson> 5<PHONE_NUMBER>8-53686042623<PHONE_NUMBER>      logical linux-swap      /dev/sda5
[16:09] <cjwatson> desired state:
[16:09] <cjwatson> 1   1048576-52614397951<PHONE_NUMBER>6     primary ext4    /dev/sda1
[16:09] <cjwatson> 5<PHONE_NUMBER>8-53686042623<PHONE_NUMBER>      logical linux-swap      /dev/sda5
[16:09] <slangasek> tvoss: asynchronous pong
[16:09] <tvoss> slangasek, pong
[16:10] <tvoss> ah, sorry :)
[16:10] <tvoss> slangasek, wanted to check on the mem leak? was that fixed?
[16:12] <slangasek> tvoss: it is not fixed, we haven't root caused it yet; jodh has been working on it
[16:12] <slangasek> tvoss: please pick his brain about the progress :)
[16:12] <tvoss> slangasek, yup :)
[16:12] <tvoss> jodh, ^
[16:27] <cjwatson> psusi: more than happy to test things here BTW
[16:27] <cjwatson> since I have a nice 100% reproducer handy
[16:29] <psusi> cjwatson: about to email you the git patch
[16:29] <cjwatson> psusi: awesome
[16:37] <jodh> tvoss: still investigating I'm afraid: putting together a simple dbus server + client (without upstart and (with+without) nih) to try to simulate the problem.
[16:37] <jodh> tvoss: trigger it even.
[16:37] <tvoss> jodh, is there any way we can get valgrind results?
[16:38] <jodh> tvoss: there are valgrind logs on the bug if you're interested. However, neither I nor slangasek have been able to get it to show the leak.
[16:39] <psusi> cjwatson: patch sent... I haven't tested it though
[16:39] <tvoss> jodh, do you have a theory in which subcomponent the leak might occure?
[16:40] <jodh> tvoss: all our findings are on the bug. We believe the problem is in libdbus "somewhere". That's about as much detail as we've got so far.
[16:42] <psusi> off to lunch
[16:42] <cjwatson> psusi: OK, I'll look it over, thanks!
[16:50] <tvoss> jodh, looking, thx
[16:54] <jodh> tvoss: progress! see https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1235649/comments/59
[16:59] <tvoss> jodh, \o/
[17:01] <tvoss> jodh, might be an artifact of pool allocation, though
[17:01] <tvoss> jodh, a though: does nih replace libdbus memory allocation routines? I would think that it tries to force libdbus to allocate from a preallocated memory slice to avoid malloc at all cost
[17:03] <jodh> tvoss: no - nih does have its own alloc rouintes. But it just makes libdbus calls and is careful to document which nih routines return memory managed by dbus rather than nih.
[17:04] <tvoss> jodh, got a link to source?
[17:05] <jodh> tvoss: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/libnih/saucy/files/head:/nih/
[17:06] <infinity> sarnold: Any hope for bug #1220434?
[17:18] <DiegoTc> hi bkerensa
[17:18] <DiegoTc> hi lfaraone
[17:20] <apachelogger> pitti: http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/revision/446 it appears you'll also need to add kubuntu-debug-installer kubuntu-firefox-installer desktop-kubuntu-notification-helper desktop-kubuntu-web-shortcuts desktop-kubuntu-firefox-installer
[17:21] <apachelogger> or source package kubuntu-debug-installer kubuntu-firefox-installer kubuntu-web-shortcuts kubuntu-notification-helper
[17:22] <apachelogger> oh, template list is actualy  kubuntu-debug-installer kubuntu-firefox-installer desktop-kubuntu-notification-helper desktop-kubuntu-web-shortcuts desktop-kubuntu-firefox-installer notificationhelper kcm-notificationhelper
[17:30] <DiegoTc>  /join #ubuntu-locoteams
[19:10] <Riddell> apachelogger: I am not sure thy will need to be added to the language packsbeacuse they are in universe
[19:43] <tedg> ev, What's the LP project for the geoip data?
[19:51] <thad_> pitti: logind gets stuck in PrepareForSleep mode after suspend/hibernate, it happens occasionally, but I already saw it on two complete different machines. should I file a new lp report or continue commenting on this one bug 1234469 ?
[19:54] <pitti> thad_: I think that bug is the very issue, so continuing investigation there is fine
[19:56] <thad_> pitti: alright, guess I'll test kernel 3.10 and 3.12 to get some more information, not quite sure how to debug this systemd/logind "madness" :)
[19:57] <pitti> thad_: thanks; you can run logind in the foreground to see what it's doing, perhaps there's an error message somewhere
[19:59] <thad_> ok, hopefully I can gather some useful debugging information
[20:15] <psusi> so what if characters can't be reprepsented in your current code page?  it looks like iconv fails the conversion by default, or has an option to ignore... shouldn't you substitute a generic block like character like you get when you don't have the correct font installed?
[20:51] <cjwatson> psusi: sounds like you want //TRANSLIT
[20:51] <cjwatson> psusi: changing the default behaviour would break things that use iconv to tell whether something is valid text in a given encoding
[20:51] <psusi> cjwatson: the man page says it tries to use multiple similar characters, but isn't clear on what happens if it just plain won't work... like if you are using straight asci or latin1
[20:52] <cjwatson> You tend to get "?" for ASCII//TRANSLIT
[20:52] <psusi> ok... sounds good then, maybe I'll use that
[20:53] <psusi> cjwatson: that patch work out earlier?
[20:53] <cjwatson> Just testing it now following your clarification
[20:54] <cjwatson> That still fails, but a bit differently
[20:54] <cjwatson> Now fails to add (or resize?) /dev/sda5
[20:55] <psusi> what's sda5?
[20:55] <cjwatson> Which is odd since that should've been in the exact same position as before
[20:56] <cjwatson> Yeah, same before and after
[20:56] <cjwatson> 5<PHONE_NUMBER>8-53686042623<PHONE_NUMBER>      logical linux-swap      /dev/sda5
[20:57] <cjwatson> Oh, you have no handling in the add loop for same start/length before and after
[20:58] <psusi> doh!
[20:59] <cjwatson> so lift the start/length handling up out of the ifdef I guess
[20:59] <cjwatson> want me to just do the obvious fix?
[20:59] <psusi> sure
[21:00] <psusi> it's just slightly tricky because of the #ifdef for the resize
[21:00] <psusi> you want to handle unchanged partitions with or without the resize
[21:01] <psusi> bbl, heading home
[21:36] <cjwatson> psusi: This is looking better now - http://paste.ubuntu.com/6237966/
[21:36] <cjwatson> (My changes are around lines 81-105)
[21:38] <cjwatson> Seems to work, trying a resize
[21:43] <psusi> cjwatson, looks good
[21:43] <cjwatson> There's no single non-confusing view of this change, unfortunately, apart from looking at the patched source file
[21:44] <cjwatson> The patch is enough of a refactoring that it's difficult to read on its own, and a patch of the patch is even worse ...
[21:44] <cjwatson> psusi: Thanks very much for the help - I'll get this into Debian as well once I'm not in such a hurry
[21:45] <cjwatson> And have slept
[21:46] <psusi> hehe, yep


[00:00] <roaksoax> higgins: yes
[00:00] <roaksoax> err
[00:00] <roaksoax> sorry
[00:07] <catbus11> roaksoax: hi, is there documentation about how to build custom image to be imported to MAAS yet?
[10:10] <Mmike> Hello, lads. When I add images to maas, and then I PXE boot from that image, what is the default username/password that I can use to connect to PXEbooted image?
[10:30] <mup> Bug #1459607 was opened: Spurious test: maasserver.api.tests.test_node.TestNodeAPI.test_POST_commission_commissions_node <MAAS:In Progress by rvb> <https://launchpad.net/bugs/1459607>
[13:40] <mup> Bug #1459666 was opened: Wrong cursor when hovering over the "Add interface" button on the node details page <ui> <MAAS:Triaged by ricgard> <https://launchpad.net/bugs/1459666>
[14:40] <mup> Bug #1445070 changed: Edit Node pages shows root password in plaintext <ui> <MAAS:New> <https://launchpad.net/bugs/1445070>
[15:07] <mup> Bug #1442131 changed: 1.8b1 redundant owner column on devices page <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1442131>
[15:07] <mup> Bug #1459710 was opened: "Set zone" label oddly placed on node listing page <ui> <MAAS:Confirmed for ricgard> <MAAS 1.8:Confirmed for ricgard> <https://launchpad.net/bugs/1459710>
[15:37] <mup> Bug #1438109 changed: styling for sort on node listing doesn't yet match designs <ui> <ux> <MAAS:Invalid> <https://launchpad.net/bugs/1438109>
[17:52] <mup> Bug #1459762 was opened: hostname, architecture, disable_ipv4 can be permenantly changed by non-admin user <MAAS:New> <https://launchpad.net/bugs/1459762>
[17:58] <mup> Bug #1459762 changed: hostname, architecture, disable_ipv4 can be permenantly changed by non-admin user <MAAS:New> <https://launchpad.net/bugs/1459762>
[18:07] <mup> Bug #1459762 was opened: hostname, architecture, disable_ipv4 can be permenantly changed by non-admin user <MAAS:New> <https://launchpad.net/bugs/1459762>
[23:20] <mup> Bug #1459865 was opened: System cannot be enlisted with the ephemeral release images <oil> <MAAS:New> <maas-images:New> <https://launchpad.net/bugs/1459865>
[23:20] <mup> Bug #1459866 was opened: commissioning failing due to no-such-image in boot string <cpe-sa> <MAAS:New> <https://launchpad.net/bugs/1459866>
[23:59] <mup> Bug #1459876 was opened: MAAS image syncing does not seem to be deleting old images from DB <MAAS:New> <https://launchpad.net/bugs/1459876>


Forwarded from Lubuntu Announcements: *LXQt 1.4, *Arriving (https://lubuntu.me/jammy-backports-22-04-3-lxqt-1-4/) *at a Lubuntu Backports PPA Near You!*


[09:36] <cpaelzer> utkarsh2102: doko has asked if you could look at https://launchpad.net/ubuntu/+source/ruby2.7/2.7.2-4ubuntu1 ?
[09:37]  * doko is on leave ...
[10:03] <utkarsh2102> cpaelzer: absolutely, the arm64 failure I suppose?
[10:24] <utkarsh2102> ah, that and also regression on s390x: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby2.7
[10:27] <sil2100> cpaelzer: hey! I have been poked about a chrony ADT regression for s390x with the new dpkg - was wondering if maybe you or someone from the server team could take a look to see what could be happening there?
[10:45] <cpaelzer> sil2100: you are the second to ask, it seems to be LTO
[10:45] <cpaelzer> sil2100: and I'm already on it
[10:54] <sil2100> cpaelzer: excellent to hear!
[11:18] <cpaelzer> sil2100: this case is ugly, it tries to throw red herrings at me in every possible step *sigh*
[11:42] <cpaelzer> thanks for the bug filing sil2100
[11:42] <cpaelzer> you'll smile when you see al my updates that are incoming to that ... :-)
[11:54] <sil2100> cpaelzer: wow, thanks for the detailed investigation! ;)
[11:54] <sil2100> This is really a good read
[11:59] <cpaelzer> sil2100: if you could maybe have a look for silly mistakes on https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/400182 and ack it if ok ?
[11:59] <cpaelzer> I'll make cross arch build and cross arch test a requirement for uploading anyway - so consider that covered
[12:19] <utkarsh2102> doko: fwiw, this test in ruby-ferret is known to be problematic; we previously hit that on arm64 and it seems now on s390x but unfortunately, I can't seem to reproduce the failure (using canonistack VM); 7/7 passing, no failures :(
[12:20] <utkarsh2102> that said, c_paelzer has re-triggered the tests twice on my request. so let's see. (Ik you did already)
[12:33] <utkarsh2102> doko: passing both, yay! \o/
[12:44] <sil2100> cpaelzer: looking in a moment!
[13:45] <eoli3n_> is there a way to make sure that avahi-daemon can't run ? if i remove the package and hold it in my ansible playbook, it seems to come back as dep of another package. If i disable avahi-daemon.socket and avahi-daemon.service, reboot, it is still running...
[14:23] <rbasak> eoli3n_: https://askubuntu.com/a/816378/7808
[14:24] <rbasak> I think you want "mask" rather than "disable".
[14:25] <rbasak> You could also pin avahi-daemon to something negative in apt.
[14:25] <rbasak> But I would investigate why you need a package that depends on it first.
[15:05] <eoli3n_> thanks rbasak
[15:55] <eoli3n_> xnox i face this again : https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1882232
[15:56] <eoli3n_> with desktop iso live system, my ansible playbook hangs, then fail at the task of installing chromium-browser
[15:56] <eoli3n_> (just a sec for logs)
[15:57] <xnox> eoli3n_:  fun.
[15:57] <eoli3n_> not sure if i would use that word but... :)
[15:57] <xnox> eoli3n_:  where is your playbook running? cause i thought we fixed that, to detect that things are well not running.
[15:58] <eoli3n_> in a chroot
[15:58] <eoli3n_> i fixed that
[15:58] <eoli3n_> s/i/we
[15:58] <eoli3n_> s/we/you
[15:58] <eoli3n_> :)
[15:58] <xnox> eoli3n_:  however, since that was fixed, we did add preseeding support => so chroot has many snaps things prepopulated.
[15:58] <xnox> eoli3n_:  maybe open a new bug report? and say that this previous bug, has now regressed?
[15:59] <xnox> eoli3n_:  i can't remember what your desired end state was; and what was done to get there.
[15:59] <eoli3n_> i don't think that it has regressed
[15:59] <eoli3n_> because it is still working with kickstart
[15:59] <eoli3n_> and the netboot iso
[16:00] <eoli3n_> i just want to install chromium-browser with ansible in a chroot with a ubiquity late command
[16:00] <eoli3n_> success command*
[16:00] <xnox> and there is no way today to otherwise tell the installer "and please install these snaps"
[16:01] <xnox> cause in the future we'd need to grow that capability.
[16:01] <xnox> eoli3n_:  yeah, we did changes in focal, that may not result in that working anymore correctly..
[16:01] <xnox> let me open a new bug report about that.
[16:01] <eoli3n_> https://x0.at/BwI.txt
[16:01] <eoli3n_> but i don't get what difference between preseeding desktop main iso, and kickstarting netboot iso
[16:02] <xnox> lots
[16:02] <eoli3n_> oh ok
[16:02] <xnox> desktop already has some snaps in partially installed state
[16:02] <eoli3n_> but it should concern the package, and not the installer, doesn't it ?
[16:02] <xnox> where snapd is paused, at half-preseeded state.
[16:02] <eoli3n_> ok ok, you know better :)
[16:02] <xnox> with many snaps preinstalled.
[16:02] <xnox> the netboot.iso has no snaps.
[16:03] <xnox> opened https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1921405
[16:03] <eoli3n_> you can add the task log in the bug report if you want
[16:04] <eoli3n_> you're fast ! thanks again for your help
[16:38] <eoli3n_> shouldn't the installer create an efi entry in boot manager automatically ?
[17:11] <xnox> eoli3n_:  yes, no, maybe. it doesn't matter.
[17:11] <xnox> eoli3n_:  it can do it on first boot too.
[17:11] <xnox> eoli3n_:  also, who knows if your firmware honors it.
[17:11] <xnox> if you force it to always netboot, it may ignore BootNext / BootOrder.
[17:16] <eoli3n_> at the first boot, i get my firmware configuration screen, if i select my hard drive, then it "creates ubuntu entry" but it doesnt use grubx64.efi
[17:28] <xnox> why should it use grubx64.efi ?! =)
[17:28] <xnox> eoli3n:  also sounds like your firmware is buggy, if you want to select a hard drive => if you are in OVMF qemu KVM, did you set bootoder on your drives / network card?
[17:29] <xnox> we never boot with grub directly.
[17:29] <eoli3n_> the firmware is ipxe used by qemu as main one
[17:30] <eoli3n_> " if you are in OVMF qemu KVM, did you set bootoder on your drives / network card?" in the firmware ?
[17:30] <eoli3n_> nop
[17:31] <eoli3n_> problem is that i configured netplan to use networkd for "eth0" and i configured my cmdline in /etc/default/grub
[17:31] <eoli3n_> to use old dev names
[17:32] <eoli3n_> "18:29 xnox: we never boot with grub directly." I don't understand what you mean
[17:32] <eoli3n_> the firmware chainloads grub, then grub loads kernel and initramfs
[17:38] <xnox> false
[17:38] <xnox> firmware should chainload shim, which chainloads grub.
[17:38] <xnox> and shim can choose if it will boot fwupdate, fb, mm, or grub.
[17:39] <xnox> or even reset again.
[17:39] <xnox> eoli3n_:  if you configured things right, there shouln't be a problem. If there is a problem, maybe some of the config is missing.
[17:40] <xnox> eoli3n_:  and i would recommend you to _not_ force eth0 names. Becuase netplan & networked can match on all ethernet device irrespective of how they are named. And it is best to use stable names, rather than eth0.
[17:40] <xnox> eth0 breaks a lot.
[17:41] <eoli3n_> stable names on a host is not a stable name on 800 hosts
[17:42] <eoli3n_> but why not drop this and configure netplan without hard configure a net card
[17:44] <xnox> eoli3n:  that's the point. 800 hosts should have 800 different ethernet names, and that should be ok.
[17:44] <xnox> eoli3n_:  hi?
[17:44] <xnox> there are two of you and you had a netsplit?
[17:44] <xnox> eoli3n:  that's the point. 800 hosts should have 800 different ethernet names, and that should be ok.
[17:45] <xnox> for example, what's your kernel commandline? and did you specify your cmdline changes are `---` such that it gets copied into target too?
[17:46] <eoli3n_> xnox something strange happened here :)
[17:47] <eoli3n_> BOOT_IMAGE=/boot/vmlinuz-5.4.0-67-generic root=UUID=cfd0c620-61ab-4887-977c-5138febf933e ro net.ifnames=0 biosdevname=0 ipv6.disable=1 quiet splash
[17:47] <xnox> there are rolling restarts of freenode at the moment.
[17:48] <xnox> eoli3n_:  is that how you boot the installer, or how you boot the installed system?
[17:48] <xnox> eoli3n_:  looks ok.
[17:48] <eoli3n_> ah no
[17:48] <eoli3n_> that's how i boot my hosts
[17:48] <xnox> eoli3n_:  how do you boot the installer?
[17:48] <eoli3n_> on the first boot
[17:48] <eoli3n_> without this
[17:49] <eoli3n_> the unmatch is problematic i guess
[17:49] <xnox> without what?
[17:49] <eoli3n_> net.ifnames=0 biosdevname=0
[17:50] <eoli3n_> here my installer cmdline : imgargs vmlinuz initrd=initrd rootfstype=nfs netboot=nfs nfsroot=<IP_ADDRESS>:/exports/focal-desktop boot=casper ip=dhcp fsck.mode=skip automatic-ubiquity debian-installer/language=fr console-setup/layoutcode=fr console-setup/variantcode=oss url=http://<IP_ADDRESS>/preseed/fds/focal-efi.seed quiet
[17:50] <xnox> i expect you to boot the installer as " linux /boot/vmlinuz-xyz ip=dhcp <anything installer related> --- net.ifnames=0 biosdevname=0 ipv6.disable=1 quiet splash
[17:50] <xnox> "
[17:50] <eoli3n_> ah ok, but i don't get what it does
[17:50] <xnox> because then things after "---" will not only be active during the installation, but will also be copied into target's installed system.
[17:50] <eoli3n_> ok ! good to know
[17:50] <xnox> such that you don't need to manually configure custom kernel cmdline.
[17:51] <eoli3n_> where will it be written ?
[17:51] <eoli3n_> on the target ?
[17:51] <xnox> cause it's like "my systems need these kernel args and copy them into target too"
[17:51] <xnox> eoli3n_:  i think it like modifies /etc/defaut/grub* something
[17:51] <eoli3n_> that's what ansible does
[17:51] <eoli3n_> for me
[17:51] <eoli3n_> that's the strange part
[17:52] <eoli3n_> when i first boot the hard drive in qemu/kvm, then it "creates ubuntu entry" but i runs with shim file
[17:52] <eoli3n_> s/i/it
[17:52] <eoli3n_> so grub cannot append cmdline
[17:52] <eoli3n_> or i misunderstand something


[04:23] <hads> morning
[04:27] <ibeardslee> heh .. I need to set an alarm to remind myself to go home and stop waiting for the sun to disappear.
[18:06] <ibeardslee> morning
[20:42] <chilts> morning
[23:00] <hads> morning