=== juliank is now known as Guest54477
=== juliank_ is now known as juliank
=== beisner- is now known as beisner
=== mfisch is now known as Guest89657
=== Guest89657 is now known as mfisch
[05:31] <cpaelzer> good morning
[05:41] <pitti> juliank: the libgcrypt20 libs and its deps libgpg-error0 and libc6 don't have any conflicts/breaks
[05:42] <pitti> Unit193: yes, but as I said with sysv init scripts there is no generic fix as the scripts don't declare how they behave
[05:42] <pitti> Good morning
=== athairus is now known as afkthairus
[07:51] <Mirv> flexiondotorg: mate-menu and mate-session-manager in unapproved queue now
[08:31] <andrewsh> hello guys
[08:32] <andrewsh> how do NMUs and sponsored uploads work in Ubuntu?
[08:32] <andrewsh> in other words,
[08:33] <andrewsh> if the maintainer isn't responsive, and I have a bug to fix, and a patch fixing the bug, and a bzr branch with that fix and a bunch of packaging improvements, and it's a Ubuntu-only package (not in Debian), who should I prod to get that uploaded?
[08:34] <dholbach> andrewsh, subscribe the 'ubuntu-sponsors' team to the bug report
[08:34] <dholbach> and thanks for fixing it!
[08:42] <andrewsh> dholbach: okay, I did. also, is creating something like this the right thing? https://code.launchpad.net/~andrew.sh/adium-theme-ubuntu/adium-theme-ubuntu-lp1235472/+merge/291487
[08:44] <andrewsh> oops, it seems I proposed the merge to a wrong repository
[08:45] <cjwatson> Often better to just attach a patch.
[08:46] <cjwatson> The bzr import infrastructure is creaky and failing and due for replacement.
[08:47] <andrewsh> cjwatson: I attached patches, but there are more changes in the branch
[08:48] <andrewsh> as I fixed up the packaging too (so I could build my own package version locally)
[08:49] <cjwatson> andrewsh: My advice stands :)
[08:50] <cjwatson> You can always attach a debdiff against the previous source
[08:50] <cjwatson> Then you also won't get confused about which branch to merge into (since there really isn't a correct target branch now)
[08:52] <andrewsh> ha
[08:52] <mwhudson> if you want to work in a vcs locally, you can always gbp import-dsc to make a git repo to play around in
[08:55] <Laney> infinity: merci for the glib2.0 fix
[08:56] <Laney> Guess I should have downloaded an lp chroot eh
[08:56] <infinity> Laney: It's not the chroot that needed fixing, it's the base system.
[08:56] <infinity> Laney: As in, the machine running sbuild.
[08:57] <Laney> oh, wat
[08:57] <infinity> Laney: Turns out that systemd without libpam-systemd ends up putting everything in one tiny little cgroup of doom, and you can fork bomb yourself into oblivion with zero effort.
[08:57] <andrewsh> mwhudson: which is nearly what I did initially (I just did git add . & git commit)
[08:57] <andrewsh> &&, even
[08:57] <infinity> (Awesome design)
[08:58] <mwhudson> andrewsh: ah yep, that works too i guess :)
[08:59] <smb> cjwatson, Do we already have a bug report for Ubuntu about needing changes in (backported, too) apt-cacher-ng to handle by-index?
[09:00] <cjwatson> smb: It's already fixed in xenial.  I'm not aware of a bug about SRUs.
[09:00] <cjwatson> (by-hash, not by-index, BTW)
[09:01] <smb> cjwatson, sorry confused the terms. So I probably need to open one as well
[09:01] <smb> Since the proxy likely runs on not Xenial
[09:03] <cjwatson> smb: Makes sense.
[09:03] <cjwatson> I had enough to do, but feel free :)
=== vrruiz_ is now known as rvr
[09:12] <pitti> smb: add SRU tasks, please don't open new bugs specifcially for SRUs
=== pavlushka is now known as pavlushka-
[09:13] <andrewsh> cjwatson: well, I did as you suggested :)
[09:13] <andrewsh> I hope that fix still can get into the release
[09:14]  * andrewsh is very afraid of jumping in right before the release after having to argue with jcristau in Debian :)
[09:14] <smb> pitti, how to do that if the problem has already been fixed in Xenial?
[09:19] <infinity> pitti: There wasn't an LP bug for https://launchpad.net/ubuntu/+source/apt-cacher-ng/0.8.9-1ubuntu1
[09:19] <infinity> smb: Just go ahead and file one.
[09:19] <pitti> ah, it was a Debian bug, ok
[09:19] <smb> bug 1568754
[09:20] <ubottu> bug 1568754 in apt-cacher-ng (Ubuntu) "Backport request to support by-hash in apt-cacher-ng" [Undecided,New] https://launchpad.net/bugs/1568754
[09:20] <infinity> smb: s/backport/SRU/
[09:21] <infinity> Oh, you do mention the SRU later.
[09:21] <smb> infinity, bah actually I had thought I removed that part before
[09:21] <smb> I fixed it now
[09:22] <infinity> smb: There, accepted your tasks and linked the xenial fix.
[09:23] <smb> infinity, ack, thanks
[09:23]  * infinity goes to get some sleep; it's going to be a long week.
[09:24] <alkisg> pitti: hi, could I please ping you again about LP: #1487679? It appears to be Ubuntu specific, not solvable from the nbd-client side, as *any* sysvinit service (not only rcS ones) that has *only* the "Required-Start: $network" header, creates a dependency cycle.
[09:24] <alkisg> I think the Ubuntu-specific network-manager patches are to blame for this.
[09:24] <ubottu> Launchpad bug 1487679 in nbd (Ubuntu) "Breaking ordering cycle by deleting job nbd-client.service/start" [Undecided,Triaged] https://launchpad.net/bugs/1487679
[09:25] <pitti> alkisg: our nbd package is unmodified, so Debian's is in rcS too
[09:25] <alkisg> pitti: yes, and it works fine in debian
[09:25] <alkisg> It doesn't create a cycle
[09:25] <pitti> well, I doubt that
[09:25] <alkisg> I tried in Stretch and I saw no complains
[09:26] <alkisg> But even if I remove the rcS bit from its headers, I still get a dependency cycle in ubuntu
[09:26] <alkisg> So I think that this issues is different from the one you have in mind
[09:27] <pitti> the difference might be that in Debian NetworkManager-wait-online.service is not enabled by default
[09:27] <pitti> so NetworkManager does not block network-online.target
[09:27] <alkisg> Let me try to disable that in Ubuntu...
[09:27] <alkisg> systemctl disable?
[09:27] <pitti> well, this isn't a solution
[09:28] <alkisg> Just to see if it's a symptom
[09:28] <pitti> if you use NM, then NM-wait-online must be enabled, otherwise the whole idea of network-online.target breaks
[09:28] <alkisg> In comment #8, I mention the 2 lines that are different in ubuntu vs debian, that I applied to debian and caused the issue there too
=== pavlushka- is now known as pavlushka
[09:28] <alkisg> -After=network-pre.target dbus.service, +Wants=network.target, +Before=network.target
[09:32]  * pitti followed up to the bug
[09:32] <alkisg> Ty!
[09:37] <rbasak> xnox: any progress with the rsyslog FTBFS please?
[09:37]  * rbasak is trying to get all libmysqlclient18 rdepends rebuilt for src:mysql-5.6 removal.
[09:49] <infinity> rbasak: I fixed it with the same thing that fixed glib2.0 ... You're welcome.
[09:49] <rbasak> Thanks!
[09:56] <pitti> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html should really show when a newer version is sitting in -proposed
[10:22] <cpaelzer> rbasak: I've a few dpdk fixes piling up - personally I'd like to wait until upstream settled on a "final" fix (preliminary available)
[10:23] <cpaelzer> rbasak: looking at the Final Freeze I wonder if it would be recommended to prep and do the upload in the state as is
[10:23] <cpaelzer> rbasak: and only SRU in case it changes or any follow-on issues are identified?
[10:24] <xnox> pitti, cyphermox - is it normal for dbus messages from networkmanager to/from dnsmaq to be rejected? bug #1568787
[10:24] <ubottu> bug 1568787 in network-manager (Ubuntu) "resolveconf does not reliable receive nameserver information from network manager" [Undecided,New] https://launchpad.net/bugs/1568787
[10:31] <pitti> xnox: not sure if it's "normal", but I think we've had these for quite some time
[10:33] <xnox> pitti, my problem is that every once and a while i loose nameserver resolution and I am struggling to debug it. E.g. i am connected to wifi & vpn, all via network-manager yet my nameserver settings do not appear to be in the dnsmasq that is running on 127.0.1.1 and then i am at a loss.
[10:34] <seb128> speaking about n-m, cyphermox I guess you saw that the update is blocked on proposed due to autopkgtest issues?
[10:34] <xnox> no actual config files in /run/NetworkManager that are helpful.
[10:34] <xnox> i wonder if new NM is better.
[10:35] <infinity> xnox: Did you catch my ping in backscroll about s390x booting degraded because cpacfstatsd.service fails?
[10:35] <xnox> infinity, i have not. and that's not nice indeed.
[10:36] <xnox> infinity, i'll take a look now.
[10:37] <infinity> xnox: We might also want to look at breaking up s390-tools even further.  Or something.  It's trying to pull stuff into minimal that really doesn't seem minimal (perl, sg3-utils...)
[10:38] <infinity> xnox: But I'll talk to you about that after I've slept.
[10:39] <infinity> libfuse2 ... Why does s390-tools want fuse? :P
[10:39]  * infinity goes to bed.
[10:47] <cpaelzer> to infinity 's dreams - I think they fuse-mount their dumps via zgetdump -m
=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
=== _salem is now known as salem_
[12:26] <tjaalton> any idea why zsh in xenial tab-completes usb-media like "/media/tjaalton/Ubuntu$'\001'6.04\ LTS\ amd64"?
[12:29] <tjaalton> hm, it's just for umount
[12:47] <smb> mvo, Bothering you because your name is somehow attached to the whole thing. I think I saw this in other places but cannot remember where. Right now there seems to be a common behaviour in Xenial that one does an apt-get update and gets a "AppStream cache update completed, but some metadata was ignored due to errors." Do you know whether some fix is already on its way?
[12:49] <smb> And could it be that this is about trying to get dep11/Components-<arch>.yml but only having a dep11/Components-<arch>.yml.gz in the archive
[12:51] <mvo> smb: unfortunately I don't know the answer to this, I would have to dig, but maybe Laney knows, he was working on this particular integration
[12:51] <Laney> https://github.com/ximion/appstream/issues/32
[12:53] <smb> Laney, Hm... yes that one. Guess that means no fix yet. Not sure this helps but I see some messages when having apt-cacher-ng in the pipeline which look like its probably missing the compressed Components
[12:54] <smb> At least there are unsuccessful attempts to access the *.yml uncompressed file variant
[12:54] <Laney> That would be a different problem
[12:56] <Laney> the message on that bug report comes after an apt update
[12:56] <smb> Yes, I get the same on the Xenial side
[12:56] <smb> But let me re-try with the appstreamcli cmd
[12:58] <smb> ... after upgrading the rest. have not done so since last friday
[12:58] <ximion> Laney: the bug above ^ will not have any huge consequences (like fw updates being ignored), but it still is a bug - basically, the quick validation is a bit too strict here
[12:58] <ximion> will fix that today
[13:06] <smb> Laney, Hm, ok the errors about the uncompressed files are gone now and the appstream problem is the same as reported (some component check in some firmware)
[13:06] <Laney> smb: k, should be fixed soon then
[13:07] <smb> Laney, ack and luckily (for me) not needing further changes to old apt-cacher-ng versions
[13:14] <cyphermox> xnox: I don't see these rejections.
[13:15] <cyphermox> seb128: I know, I was looking yesterday. I'm trying to figure out whether it's expected -- I think it is, there's a small change in the MAC address
[13:15] <seb128> cyphermox, k, good, let me know if I can help with anything
[13:15] <xnox> cyphermox, interesting, so it's me.
[13:19] <cyphermox> xnox: as I told Tony on Friday, you may need to tick "Use only for the resources on its network" checkbox for IPv6 in the VPN config if you find that you only lose DNS if you're connecting to VPN on wifi
[13:23] <xnox> hm, interesting
[13:23] <xnox> looking at my configs I already ignore ipv6 on the vpn connection
=== jgrimm-afk is now known as jgrimm
=== cmagina_ is now known as cmagina
[14:28] <dasjoe> cking: hi, I'm running into issues with 16.04 on a ZFS rpool. As you may be aware I am following rlaager's guide with some minor modifications, as of now grub-probe can not detect / to be ZFS. Do you have any suggestions?
[14:30] <cking> urm, well, last time I tried it, I got it to work, so I'm not sure.  what differences are you making when folloing his notes?
[14:31] <dasjoe> cking: I'm using less datasets than he is, but this rpool setup has worked well for a few months by now. I just ran a generic upgrade through aptitude which segfaulted, followed by two "apt-get dist-upgrade" to get to a consistent state
[14:32] <cking> hmm. I  don't know off the top of my head, the only way is for me to follow his notes and see what's up
[14:33] <dasjoe> Log started: 2016-04-11  16:22:39 ← starting from "Log started: 2016-04-11  16:22:39" is what aptitude logged
[14:34] <dasjoe> cking: nevermind, I think. aptitude just removed the kernel, due to it not being configured correctly. I'll reinstall the kernel and grub should understand ZFS again
[14:35] <cking> heh. that could be a reason why it's not working :-/
[14:36] <dasjoe> cking: nope, still stuck here: http://paste.debian.net/432172/
[14:38] <dasjoe> cking: "chmod -x zz-update-grub" let me finish configuring the kernel, but grub-probe tells me "grub-probe: error: unknown filesystem."
[14:39] <dasjoe> cking: I have to go now, I'll be back later (hopefully)
[14:39] <cking> ok, I'll try and find some time to see if I can reproduce this
=== Chipaca` is now known as Chipaca
[15:05] <sil2100> infinity: hey! DMB meeting - will you be able to attend?
[15:15] <smoser> infinity, is there a bug for hwe-x installer kernel/initramfs ? if not, do you want one ? i'm getting asked about maas image information for trusty + hwe-x and i depend on that.
[15:18] <cyphermox> smoser: what is the bug?
[15:20] <smoser> https://bugs.launchpad.net/maas-images/+bug/1568918
[15:20] <ubottu> Launchpad bug 1568918 in livecd-rootfs (Ubuntu Trusty) "Add support for lts-xenial kernel flavours in trusty " [Undecided,Confirmed]
[15:22] <smoser> cyphermox, ^ the bug is just lack of such things.
[15:22] <cyphermox> ah
[15:39] <seb128> Mirv, congrats ;-)
[15:40] <Mirv> thank you seb128 :)
[15:53] <ginggs> could someone have a look at autopkgtest for paraview please? it says 'test in progress' for s390x, but I suspect that to be a lie
[16:40]  * smoser wants to publicly thank cjwatson, mvo (and all others who were involved) for the slaughter of hash sum mismatch errors
[16:41] <smoser> http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-errors.html
[16:41] <alkisg> +1 from me for the very nice blog entry :)
=== afkthairus is now known as athairus
[17:59] <dasjoe> cking: grub-probe seems to successfully query "zpool status", see its strace -f: http://paste.ubuntu.com/15764929/
[18:04] <smoser> ogra_, around ?
[18:04] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1563296
[18:04] <ubottu> Launchpad bug 1563296 in cloud-init (Ubuntu) "support cloud-init networking with snappy" [Medium,Confirmed]
[18:04] <smoser> you opened that bug for cloud-init breaking snappy system boot.
[18:05] <smoser> now i think the reverse is happening.
[18:05] <smoser> on apt based system, i *think* that ubuntu-snappy (or ubuntu-snappy-cli) is writing in /etc/network/interfaces.d/eth0 and wreaking havoc
[18:06] <infinity> mvo: ^
[18:20] <ogra_> smoser, yo
[18:21] <ogra_> smoser, infinity, that got fixed by moving the seed to ubuntu-snappy-cli
[18:22] <ogra_> ubuntu-snappy ships the firestboot systemd job that sets up the interfaces file from snappy config data
[18:22] <ogra_> firstboot
[18:22] <ogra_> the seed got changed to only use the -cli package now
[18:22] <smoser> ogra_, ok. that makes me much happier.
[18:23] <ogra_> not sure all changes are in the archive yet ... i know mvo wanted to land something today
[18:23] <ogra_> but it is being handled if it isnt fixed yet
[18:24] <smoser> seed still shows ubuntu-snappy
[18:24] <smoser> ogra_, is there a bug ?
[18:24] <smoser> if not, i'll file one and make the changes in the seed right now.
[18:24] <smoser> i'd rather not wait a day and a set of images if i dont have to
[18:24] <ogra_> not sure, mvo worked on it (and spent actually some full workdays and the weekend on it)
[18:24] <smoser> :-(
[18:24] <ogra_> i thought it was ready for landing today
[18:25] <smoser> well.. id ont want to step on toes.
[18:25] <ogra_> (and i thought the seed change had already landed ... )
[18:25] <smoser> well, http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/view/head:/cloud-image
[18:25] <ogra_> the solution is that desktop installs shouldnt have any snappy systemd units though ...
[18:25] <smoser> definitely says ubuntu-snappy
[18:26] <smoser> gah
[18:26] <ogra_> ah, not sure he looked at the cloud seed ...
[18:26] <smoser> ogra_, i'll take it from here.
[18:26] <smoser> thank you for your help.
[18:26]  * ogra_ checks the desktop seed
[18:27] <ogra_> yeah, server and desktop both have -cli already
[18:27] <ogra_> so adjust cloud to that and you shoould be fine
[18:27] <smoser> hm..
[18:27]  * smoser wonders if we want to recommend only
[18:28] <ogra_> up to you :)
[18:28] <ogra_> deskto only recommends ... server depends
[18:38] <infinity> smoser: I think recommends is probably the right answer for this cycle, since we're not including any snaps by default, and users might want to reclaim the space.  Promoting that to a depends by 18.04 would probably be The Right Thing, if we're also snapping in the default install(s).
[18:39] <smoser> infinity, i think so to.
=== padv_ is now known as padv
[18:44] <smoser> infinity, ok. pushed that change. and the ubuntu-snappy to ubuntu-snappy-cli
[18:45] <smoser> should we re-build ubuntu-meta ?
[18:45] <infinity> smoser: I'll grab that.
[18:45] <smoser> thank you.
[19:49] <mvo> infinity: yes, that is fixed, we want to land a new upload tonight that fixes this even harder
[20:06] <infinity> mvo: I'm all for fixing harder. ;)
[20:17] <smoser> hey.
[20:18] <smoser> slangasek, wrt bug 1505839 ... the 'esc' is much nicer.
[20:18] <ubottu> bug 1505839 in debian-installer (Ubuntu) "Unable to install from text mode interface" [High,Triaged] https://launchpad.net/bugs/1505839
[20:18] <smoser> compared to backspacing N times to get rid of stuff through the F6
[20:24] <F4S4K4N> I'm looking into possible porting Ubuntu to another ISA, is there a place documenting the build procedure from scratch more or less?
[20:32] <F4S4K4N> Or should i just look at the packages in a minimal install, build those from the ubuntu repo, install them and go from there?
[21:05] <cyphermox> pitti: roaksoax_ found an issue with the ifname code in systemd, at least specifically for the USB devices (where the MAC is encoded in the name)
[21:06] <cyphermox> pitti: the name come to a length of 15 characters, and IFNAMSIZ is 16; so you can't use labels, since that would get you past the limit of IFNAMSIZ
[21:06] <slangasek> smoser: so... sure, I understand "nicer", but o_O that people are relying on this particular interface which I didn't know was there despite having tested Ubuntu images for nigh on a decade.  What do you have that relies on this interface? Is it just this third-party "cloud image creation" tool?
[21:06] <cyphermox> that can be verified by running ifup on an enx device
[21:07] <smoser> slangasek, well. yeah, to my knowledge its just 'packer'. although if i were automating installation of ubuntu from cd and i'd seen that that worked, i'd have done the same.
[21:08] <slangasek> smoser: sure, I understand; it's still unsupported from my POV and not something I want us to commit to fixing
[21:08] <smoser> my first thought was basically the same as yours
[21:08] <smoser> i dont know how you decide if something is "supported" or not
[21:08] <smoser> nothing that i'm aware of describes F6 as a 'supported' intereface.
[21:08] <slangasek> smoser: it's not part of the install experience that we validate
[21:09] <smoser> and to my knowledge, i dont know that we have any automated test that woudl test F6^H^H^H^H^H either
[21:09] <smoser> this is clearly an unintended bug. rather than just a changed interface.
[21:10] <rbasak> IMHO a new release is a good time to change an interface.
[21:10] <smoser> i looked quickly at both diffeernces in the isolinux/ dir on thte cds and in syslinux source and didn't see anything obvious between 15.05 and 15.10
[21:11] <smoser> rbasak, its not an interface.
[21:11] <cyphermox> slangasek: smoser: fwiw I may be testing the wrong thing but esc, esc, enter does get me a command-line interface without issues here, it doesn't just switch back to the gfx
[21:11] <smoser> changing an interface by design and unintentionally regressing are differen things.
[21:11] <smoser> this is the latter.
[21:11] <rbasak> https://xkcd.com/1172/
[21:11] <cyphermox> scratch that
[21:11] <smoser> cyphermox, it does in deed
[21:11] <smoser> yeah. and then try to do something :)
[21:11] <cjwatson> I imagine it's a bug in gfxboot-theme-ubuntu FWIW
[21:11] <slangasek> cyphermox: the issue reported is that trying to boot by typing a boot command there doesn't work
[21:11] <rbasak> If it was never intended, and we accidentally break it in a new release, then that's fine.
[21:11] <cjwatson> ... happy debugging
[21:11] <cyphermox> yeah, I saw
[21:12] <smoser> *nothing* works . not even 'help'
[21:12] <slangasek> smoser: I am not disputing that it is a bug; I am disputing that it is a bug that we care about
[21:12] <rbasak> Especially if there's some way to provide the behaviour they're after.
[21:12] <cjwatson> quite possibly prompted by new syslinux, but still
[21:12] <smoser> cjwatson, but we didnt'g et a new syslinux
[21:12] <cjwatson> we did, just not a very much newer one
[21:12] <teward> nacc: i was actually going to poke you about 7.0.5 since I saw a notice on it
[21:12] <smoser> see my last comment there. it was broken between 3:6.03+dfsg-5ubuntu1 and 3:6.03+dfsg-8ubuntu2
[21:13] <cjwatson> yes I saw that
[21:13] <smoser> right.
[21:13] <rbasak> And provided that we aren't interested in supporting that use case.
[21:13] <cjwatson> but if you have not read gfxboot-theme-ubuntu's code you can have no conception of how delicate and weird it is
[21:13] <nacc> teward: yeah, i talked to ondrej about it, he didn't think it was worth doing another FFe -- but im also planning on filing a dotrelease update request for php7
[21:13] <teward> nacc: though, as a security person, I'd still say 7.0.5 vs. 7.0.4, to keep updated (but as long as you and ondrej are on the same page, and things're backported where necessary, all's good)
[21:13] <cjwatson> it is totally plausible that sneezing on syslinux could have broken something
[21:13] <teward> nacc: makes sense.
[21:13] <smoser> look at the changes though http://paste.ubuntu.com/15767880/
[21:14] <rbasak> Perhaps the act of rebuilding it changed something?
[21:14] <cjwatson> it's entirely believable.  somebody is going to have to don the waders and debug gfxboot
[21:14] <cjwatson> could actually be in gfxboot rather than gfxboot-theme-ubuntu I suppose
[21:15] <cjwatson> I notice gfxboot didn't change at all; perhaps it needs a rebuild or something
[21:15] <smoser> i'm sypathetic to slagaseks' point of view, because i can definitely see myself arguing that. indeed i *did* argue it when i first read thsi bug.
[21:15] <cjwatson> speaking as somebody who has debugged this stuff in the past (and is not going to do it now :-) ), I have no idea how long it would take to track this down
[21:16] <smoser> but this is much more something that should work then something that worked by happenstance. and i'm weary of saying anything inadvertantly broken between a release that wasnt documented as "will work" is thus up for calling unsupported.
[21:16] <cjwatson> if I had been asked to estimate this while on foundations I would have said anything from a day to a week
[21:16] <cjwatson> I would agree that it's a bug but I don't suppose foundations has a whole lot of time to spare before 16.04
[21:16] <smoser> :-(
[21:16] <cyphermox> this is going to be "fun"
[21:17] <rbasak> Is there a different way to cover their use case instead?
[21:17] <smoser> well, yes.
[21:17] <smoser> a.) cloud image
[21:17] <smoser> b.) netboot cd
[21:17] <smoser> c.) F6 + 47 (not 48) backspaces
[21:18] <rbasak> None of those seem particularly great :(
[21:18] <smoser> (the number is wrong, but the the piont is that you have to get the number right, and if we say that is the supported interface, then we have to keep the number right)
[21:18] <smoser> actually, i think a and b are valid
[21:18] <smoser> c seems like crap to as a workaround.
[21:18] <rbasak> Simulating keypresses is pretty broken though.
[21:19] <smoser> yeah. thats why netboot cd is valid
[21:19] <smoser> you dont. you get kernel, you pass it cmdline you want.
[21:19] <smoser> i have to run
[21:19] <rbasak> Me too
[21:19] <smoser> thanks you all for discussion.
[21:20] <nacc> slangasek: can you point me again to the dotrelease SRU documentation? I had it open before but seem to have lost it
[21:21] <slangasek> nacc: do you mean https://wiki.ubuntu.com/StableReleaseUpdates?
[21:23] <nacc> slangasek: maybe, you had referred me at some point to documentation when we discussed php7.0 having dotrelease updates
[21:23] <slangasek> nacc: probably the subsection of that page about micro release exceptions
[21:24] <nacc> slangasek: thanks, will review
=== JanC_ is now known as JanC
[23:18] <mvo> infinity: new snappy is upload under the new "snapd" source package name. it would be wonderful to get a review from the release team for this (and ubuntu-core-launcher, ubuntu-core-config, initramfs-tools-ubuntu-core but all of those are small). thanks a bunch !