[01:45] apw: There's a typo in the linux-image-${version}-generic depends, linux-initramfs-tools → linux-initramfs-tool [08:14] DalekSec, hmm [11:02] apw: Understandable mixup, considering the description and title of the bug have that same typo. [11:03] 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] DalekSec, what was the bug number ? [11:06] 1109029 [11:06] apw: Thanks for taking a look at the silly thing. [11:07] bah, well thats trash isn't it [11:08] Pretty much, aye. And if I were to nitpick, d/changelog has a typo, but that hardly matters. :P [11:09] these being virtual packages and therefore not apt-cache able isn't helping any either [11:10] No, that's pretty useless too. [11:11] and worse there even is a linux-initramfs-tools virtual package _as_well_ who provides that, damn you tools [11:12] Whaaat? >_< [11:12] clearly whoever asked for it isn't testing either, if its taken 4 months for anyone to notice, sigh [11:12] N: Can't select versions from package 'linux-initramfs-tools' as it is purely virtual [11:13] N: Can't select versions from package 'linux-initramfs-tool' as it is purely virtual [11:13] not that it seems east to find out who is offering the former [11:13] 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] Maybe just the kernel? [11:15] the kernel seems an odd thing to offer that [11:15] and i don't recall ours doing so [11:15] lists/us.archive.ubuntu.com_ubuntu_dists_wily_main_binary-i386_Package seems to think just the kernel that depends on it. [11:16] as in the kenrle consuming it, is making it ? [11:17] I'd believe so, http://packages.ubuntu.com/wily/linux-initramfs-tool vs http://packages.ubuntu.com/wily/linux-initramfs-tools ? [11:18] (vs https://packages.debian.org/sid/linux-initramfs-tool ) [11:19] bah, this bug needs fixing [11:20] (Ah! apparmor, that was the other one!) [11:22] Got the description too, just to be clearer. [11:25] ok filed another bug to fix it in the kernel [11:26] Great thanks, and sorry. [11:31] DalekSec, i assume you are testing in wily by now [11:31] apw: Wily FDE, just to make it fun (or because I'm a masochist) [11:32] great, then that is applied to wily for the next upload [11:33] 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] apw: (A bit confusing, I know) [11:34] then again it also says that for linux-initramfs-tool which two things do provide [11:34] apw: Right. [11:34] hopeless tools :/ [11:34] 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] infinity: Can I bug you later about adding that alt dep? :P [11:35] DalekSec: To...? [11:36] 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] 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] Sure, understandable. I'm just trying to get it to an installable state. [11:36] most of those would come to us for free if debian was fixed [11:37] DalekSec: I get that. I'm just saying that might be counter-productive. [11:37] DalekSec: Cause then all of us have to field bug reports from people "trying dracut" and booting slightly differently. [11:37] infinity: Yeah, thought of that. It is a very valid concern. [11:37] 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] 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] Which were a royal pain to weed out. === swordsma- is now known as swordsmanz [11:39] But at least that was a change we were planning to make. [11:39] We have no intention of switching to dracut. [11:39] infinity: FWIW, ubuntu-minimal still depends on initramfs-tools. [11:39] because it is an essential bit of any ubuntu system ? [11:39] DalekSec: You say that like people don't remove minimal when they want to play. :) [11:40] ...I did not do that, nooo. :3 [11:40] 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] 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] DalekSec, well, and you shouldnt :) [11:41] ogra_: Well, he's fully aware of what he's doing, so that's fine. [11:41] infinity, he ... yes :) [11:41] 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] Those people will generate a ton of noise. [11:42] "someone" isnt ... and should be alerted if ubuntu-minimal wants to be removed :) [11:42] I fear the day when everyone thinks they should switch from grub to gummiboot and file bugs on us after breaking that... [11:42] 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] lol, well, we will have switched x86 to uboot by then [11:43] ogra_: Eh? [11:43] * ogra_ grins [11:43] ogra_: Not sure how uboot relates. :P [11:43] they would need to use ugummiboot then ;) [11:43] 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] insane [11:44] Yeah. If systemd was just an init system, I'd be much happier with them. :/ [11:44] ^ and it might actually be likeable as they could focus on fixing bugs more. [11:46] well, even widespread bootloaders still have tons of bugs ... its just one more potentially broken thing [11:47] But better to have more testing and integration than fringe and barely tested. [11:48] Anyhow, back to work with me. [11:48] Awwh, oh well. :P [11:50] well, i cant imagine a better tested bootloader on arm than uboot for example ... [11:50] i know there are some grub ports for 32bit arm ... but nobody ever used them in a serious env [11:51] whyy would i switch any of my devices to a new thing thats less tested and less established [13:41] 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:41] bug 1473560 in linux (Ubuntu) "microphone regression on 4.1" [Medium,In progress] https://launchpad.net/bugs/1473560 [13:42] jdstrand: sweet, thanks for testing [13:42] It was absolutely my pleasure. I like having working hardware :) [13:45] sforshee: and thanks for the heavy lifting there === __bjf is now known as bjf [13:47] ogasawara: np, it was pretty easy once I found out there was already a fix upstream [14:17] 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] not older i think [14:17] 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] but the phones have 3.4 kernels [14:18] i think 3.2 should be fine ... [14:18] for safety reasons you should ask john-mcalleele [14:18] ogra_: We used to have some 3.0.0 device (original nexus7 maybe?), but perhaps everyone stopped caring? [14:19] that was the original galaxy nexus ... but thats dead [14:26] grouper or something [14:27] no, maguro i think [14:27] I vaguely recall removing that from the archive. [14:27] I should double-check, though. [14:27] i think grouper was actually 3.2 ... ICBW though [14:31] 3.1 maybe? [14:31] It was something weird. [14:31] Yeah, 3.1 .. And I removed it in vivid. \o/ [14:31] And maguro has been gone since utopic. [14:31] So, yay. [14:33] yeah === bjf is now known as _jfb === _jfb is now known as _fjb [16:27] 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] this is for ppc64el/powerpc64 [16:28] define didn't want to be set, and which one [16:28] apw: CONFIG_PPC_POWERNV_RTAS doesn't get set to 'y' when adding a patch for OPAL_PRD MTD_POWERNV_FLASH [16:29] bug 1464560 fwiw [16:29] bug 1464560 in linux (Ubuntu) "Backport request: include PRD support for OpenPower kernels" [High,In progress] https://launchpad.net/bugs/1464560 [16:29] what ENFORCED means is, when building the config for a build if that value does not match annotations fail the build [16:29] it doesn't make it set or anything [16:29] and doesn't make it set if the config is internally inconsistant [16:29] so i'm not seeing an error, it seems to complete just fine and then unset that CONFIG [16:29] so you set it =y by hand, and then fdr updateconfigs and it is now of ? [16:29] off? [16:30] apw: yea setting it manually and updateconfigs turn it back off [16:30] that is unrelated to the enfocer then, that is to do with the config not being compatible with it being on [16:30] apw: "powerpc/powernv: Remove powernv RTAS support" <-- this patch may be the reason : ) [16:30] heh [16:31] apw: so if we have a patch that removes support should I update that file to not enforce that? [16:31] (hopefully i'm not breaking something in which that was enforvced in the first place) [16:33] apw: yea looks like it never worked in the first place. I'll just update the file and config. === davmor2_ is now known as davmor2 === _fjb is now known as bjf