[01:45] <DalekSec> apw: There's a typo in the linux-image-${version}-generic depends, linux-initramfs-tools → linux-initramfs-tool
[08:14] <apw> DalekSec, hmm
[11:02] <DalekSec> apw: Understandable mixup, considering the description and title of the bug have that same typo.
[11:03] <DalekSec> However, check on a real Debian system and see that linux-image-3.16.0-4-686-pae, dracut, cryptsetup, etc, etc have it.
[11:05] <apw> DalekSec, what was the bug number ?
[11:06] <DalekSec> 1109029
[11:06] <DalekSec> apw: Thanks for taking a look at the silly thing.
[11:07] <apw> bah, well thats trash isn't it
[11:08] <DalekSec> Pretty much, aye.  And if I were to nitpick, d/changelog has a typo, but that hardly matters. :P
[11:09] <apw> these being  virtual packages and therefore not apt-cache able isn't helping any either
[11:10] <DalekSec> No, that's pretty useless too.
[11:11] <apw> and worse there even is a linux-initramfs-tools virtual package _as_well_ who provides that, damn you tools
[11:12] <DalekSec> Whaaat? >_<
[11:12] <apw> clearly whoever asked for it isn't testing either, if its taken 4 months for anyone to notice, sigh
[11:12] <apw> N: Can't select versions from package 'linux-initramfs-tools' as it is purely virtual
[11:13] <apw> N: Can't select versions from package 'linux-initramfs-tool' as it is purely virtual
[11:13] <apw> not that it seems east to find out who is offering the former
[11:13] <DalekSec> Well, to be fair it's pretty hard considering the troubles with plymouth and all.  In order to test again, I had to rebuild kbd, plymouth, console-setup, watershed, and a few more.
[11:13] <DalekSec> Maybe just the kernel?
[11:15] <apw> the kernel seems an odd thing to offer that
[11:15] <apw> and i don't recall ours doing so
[11:15] <DalekSec> lists/us.archive.ubuntu.com_ubuntu_dists_wily_main_binary-i386_Package seems to think just the kernel that depends on it.
[11:16] <apw> as in the kenrle consuming it, is making it ?
[11:17] <DalekSec> I'd believe so, http://packages.ubuntu.com/wily/linux-initramfs-tool vs http://packages.ubuntu.com/wily/linux-initramfs-tools ?
[11:18] <DalekSec> (vs https://packages.debian.org/sid/linux-initramfs-tool )
[11:19] <apw> bah, this bug needs fixing
[11:20] <DalekSec> (Ah!  apparmor, that was the other one!)
[11:22] <DalekSec> Got the description too, just to be clearer.
[11:25] <apw> ok filed another bug to fix it in the kernel
[11:26] <DalekSec> Great thanks, and sorry.
[11:31] <apw> DalekSec, i assume you are testing in wily by now
[11:31] <DalekSec> apw: Wily FDE, just to make it fun (or because I'm a masochist)
[11:32] <apw> great, then that is applied to wily for the next upload
[11:33] <infinity> apw: "N: Can't select versions from package 'linux-initramfs-tools' as it is purely virtual" is because the kernel depended on it, nothing provides it.
[11:33] <infinity> apw: (A bit confusing, I know)
[11:34] <apw> then again it also says that for linux-initramfs-tool which two things do provide
[11:34] <infinity> apw: Right.
[11:34] <apw> hopeless tools :/
[11:34] <infinity> apw: The "pure virtual" message is just poorly worded.  It really means "some packages reference this name, but no package is called that".
[11:34] <DalekSec> infinity: Can I bug you later about adding that alt dep? :P
[11:35] <infinity> DalekSec: To...?
[11:36] <DalekSec> infinity: Pinged sbea ttie about apparmor, but there's kbd too that should be an otherwise no-change.  While console-setup works, that actually has some initramfs config.
[11:36] <infinity> DalekSec: To be perfectly honest, while I can go and add the alt dep here and there where it's needed, I also have zero urge to support such configurations.  Unlike Debian, Ubuntu isn't about "give people 100 choices and make sure they all work".
[11:36] <DalekSec> Sure, understandable.  I'm just trying to get it to an installable state.
[11:36] <apw> most of those would come to us for free if debian was fixed
[11:37] <infinity> DalekSec: I get that.  I'm just saying that might be counter-productive.
[11:37] <infinity> DalekSec: Cause then all of us have to field bug reports from people "trying dracut" and booting slightly differently.
[11:37] <DalekSec> infinity: Yeah, thought of that.  It is a very valid concern.
[11:37] <infinity> DalekSec: It's disingenuous to say "don't worry, this is a minor change that's zero effort", cause it *will* generate work.
[11:38] <infinity> I'm reminded of the flood of bug reports we had on trusty and utopic with people booting with init=/lib/systemd/systemd
[11:38] <infinity> Which were a royal pain to weed out.
[11:39] <infinity> But at least that was a change we were planning to make.
[11:39] <infinity> We have no intention of switching to dracut.
[11:39] <DalekSec> infinity: FWIW, ubuntu-minimal still depends on initramfs-tools.
[11:39] <ogra_> because it is an essential bit of any ubuntu system ? 
[11:39] <infinity> DalekSec: You say that like people don't remove minimal when they want to play. :)
[11:40] <DalekSec> ...I did not do that, nooo. :3
[11:40] <DalekSec> ogra_: Right, but maybe I'm giving people too much credit by thinking they'll go "Hey, this sounds important, maybe I shouldn't."
[11:40] <infinity> DalekSec: Anyhow, it's just something to consider.  Maybe adding something to apport to report on the provider of /usr/sbin/update-initramfs would be enough to bin any such bug reports as suspicious.
[11:41] <ogra_> DalekSec, well, and you shouldnt :) 
[11:41] <infinity> ogra_: Well, he's fully aware of what he's doing, so that's fine.
[11:41] <ogra_> infinity, he ... yes :) 
[11:41] <infinity> My concern is people who read a blog post, or are systemd fanboys who hear "dracut == systemd" and decide they have to switch to be hip and cool...
[11:41] <infinity> Those people will generate a ton of noise.
[11:42] <ogra_> "someone" isnt ... and should be alerted if ubuntu-minimal wants to be removed :) 
[11:42] <infinity> I fear the day when everyone thinks they should switch from grub to gummiboot and file bugs on us after breaking that...
[11:42] <DalekSec> Well, can one really say that?  I'm just rebuilding console-setup, dracut, watershed, kbd, plymouth, and apparmor (and yes, only installed to a VM so far, for sanity.)
[11:42] <ogra_> lol, well, we will have switched x86 to uboot by then
[11:43] <infinity> ogra_: Eh?
[11:43]  * ogra_ grins
[11:43] <infinity> ogra_: Not sure how uboot relates. :P
[11:43] <ogra_> they would need to use ugummiboot then ;) 
[11:43] <infinity> ogra_: You're aware that systemd pulled in gummiboot into their tree and is pushing it as the One True Bootloader to go with all their other One True Userspace bits.
[11:43] <ogra_> insane
[11:44] <infinity> Yeah.  If systemd was just an init system, I'd be much happier with them. :/
[11:44] <DalekSec> ^ and it might actually be likeable as they could focus on fixing bugs more.
[11:46] <ogra_> well, even widespread bootloaders still have tons of bugs ... its just one more potentially broken thing 
[11:47] <DalekSec> But better to have more testing and integration than fringe and barely tested.
[11:48] <infinity> Anyhow, back to work with me.
[11:48] <DalekSec> Awwh, oh well. :P
[11:50] <ogra_> well, i cant imagine a better tested bootloader on arm than uboot for example ... 
[11:50] <ogra_> i know there are some grub ports for 32bit arm ... but nobody ever used them in a serious env 
[11:51] <ogra_> whyy would i switch any of my devices to a new thing thats less tested and less established
[13:41] <jdstrand> ogasawara, sforshee: fyi, 4.1.0-1.1~rc2-generic fixes bug #1473560 for me (and I commented in the bug). Thanks a lot! :)
[13:42] <ogasawara> jdstrand: sweet, thanks for testing
[13:42] <jdstrand> It was absolutely my pleasure. I like having working hardware :)
[13:45] <ogasawara> sforshee: and thanks for the heavy lifting there
[13:47] <sforshee> ogasawara: np, it was pretty easy once I found out there was already a fix upstream
[14:17] <infinity> ogra_: Oh hey, you might know the answer to this.  Do we still attempt to support any devices with kernels older than 3.4?
[14:17] <ogra_> not older i think 
[14:17] <infinity> ogra_: Aurelien is pushing to bump the glibc MIN_VERSION to 3.2.0 in Debian, which I think is sane for us to follow suit on in Ubuntu, but I'm worried someone will whine about it breaking on an ancient Android kernel of doom.
[14:17] <ogra_> but the phones have 3.4 kernels 
[14:18] <ogra_> i think 3.2 should be fine ... 
[14:18] <ogra_> for safety reasons you should ask john-mcalleele
[14:18] <infinity> ogra_: We used to have some 3.0.0 device (original nexus7 maybe?), but perhaps everyone stopped caring?
[14:19] <ogra_> that was the original galaxy nexus ... but thats dead
[14:26] <apw> grouper or something
[14:27] <ogra_> no, maguro i think 
[14:27] <infinity> I vaguely recall removing that from the archive.
[14:27] <infinity> I should double-check, though.
[14:27] <ogra_> i think grouper was actually 3.2 ... ICBW though
[14:31] <infinity> 3.1 maybe?
[14:31] <infinity> It was something weird.
[14:31] <infinity> Yeah, 3.1 .. And I removed it in vivid.  \o/
[14:31] <infinity> And maguro has been gone since utopic.
[14:31] <infinity> So, yay.
[14:33] <ogra_> yeah
[16:27] <arges> apw: how does debian.master/config/annotations work? I did an updateconfig after adding a config option and one of the enforced CONFIG options doesn't seem to want to be set. 
[16:28] <arges> this is for ppc64el/powerpc64
[16:28] <apw> define didn't want to be set, and which one
[16:28] <arges> apw: CONFIG_PPC_POWERNV_RTAS doesn't get set to 'y' when adding a patch for OPAL_PRD MTD_POWERNV_FLASH
[16:29] <arges> bug 1464560 fwiw
[16:29] <apw> what ENFORCED means is, when building the config for a build if that value does not match annotations fail the build
[16:29] <apw> it doesn't make it set or anything
[16:29] <apw> and doesn't make it set if the config is internally inconsistant
[16:29] <arges> so i'm not seeing an error, it seems to complete just fine and then unset that CONFIG
[16:29] <apw> so you set it =y by hand, and then fdr updateconfigs and it is now of ?
[16:29] <apw> off?
[16:30] <arges> apw: yea setting it manually and updateconfigs turn it back off
[16:30] <apw> that is unrelated to the enfocer then, that is to do with the config not being compatible with it being on
[16:30] <arges> apw: "powerpc/powernv: Remove powernv RTAS support" <-- this patch may be the reason : )
[16:30] <apw> heh
[16:31] <arges> apw: so if we have a patch that removes support should I update that file to not enforce that?
[16:31] <arges> (hopefully i'm not breaking something in which that was enforvced in the first place)
[16:33] <arges> apw: yea looks like it never worked in the first place. I'll just update the file and config.