=== pieq_ is now known as pieq
=== thegodfather is now known as fabbione
[08:47] <juliank> @pilot in
=== udevbot_ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Groovy | If you can't send messages here, authenticate to NickServ first | Patch Pilots: juliank
=== sem2peie- is now known as sem2peie
=== TheMaster is now known as Unit193
[16:22] <Laney> sil2100: any more thoughts on ubuntu-meta? I could drop restricted from the .cfg file which seems like it would work, not sure what implications that has ...
[16:22] <Laney> would *technically* work
[16:26] <jibel> sil2100, I'm reviewing your updated branch of ubiquity. Did you try to build the package? the testsuite is failing for me on hirsute
[16:30] <sil2100> jibel: eeek, sorry about that, yeah, so the updated one I didn't - since it was a one-liner I totally missed that
[16:30] <sil2100> Fixing
[16:30] <sil2100> Laney: hm, let me get back to you soon
[16:31] <sil2100> I'll let the package build finish before pushing the fix
[16:33] <Laney> k
[16:43] <sil2100> jibel: done
[16:43] <sil2100> jibel: thanks for taking a look!
[16:58] <sil2100> Laney: so this is quite the pickle, I mean, wouldn't removing 'restricted' from the .cfg mean that the next refresh wouldn't have the restricted deps anymore?
[16:59] <sil2100> I think this is something someone with more archive experience needs to look at, like vorlon - since I would really want to pull in the raspi restricted bits properly instead of once again installing them artificially in livecd-rootfs
[17:00] <Laney> sil2100: yes, that's the point, we can't have those deps
[17:00] <Laney> we didn't have them in groovy, they're only arriving now semi randomly because someone else did an update
[17:02] <vorlon> sil2100: Laney: removing 'restricted' from what .cfg, please?
[17:12] <Laney> vorlon: update.cfg in ubuntu-meta
[17:12] <Laney> basically we have component-mismatches now because of some stuff in restricted that's in one of the raspi seeds
[17:12] <Laney> and we were riffing on how to resolve that
[17:14] <vorlon> aha
[17:14] <vorlon> yeah
[17:18] <vorlon> well, first question, should we have linux-firmware-raspi2 in main, the way we do the intel/amd microcode
[17:23] <vorlon> second, uh, why does the raspi desktop seed diverge so much from the standard desktop seed
[17:23] <vorlon> ah desktop-minimal vs desktop
[17:23] <vorlon> wait no
[17:23] <vorlon> ok anyway
[17:24] <vorlon> it's certainly atypical for us to have a per-board metapackage as opposed to handling this all in livecd-rootfs
[17:24] <vorlon> and I don't like that the ubuntu-meta update.cfg now allows restricted packages to sneak in as dependencies on other archs
[17:24] <vorlon> I think that's fundamental
[17:24] <PatrickD31> Hi, having some issues installing 18.04 using MAAS, because apparently the package linux-generic-hwe-18.04 is no longer available... https://www.ubuntuupdates.org/package/core/bionic/main/updates/linux-generic-hwe-18.04
[17:26] <sladen> vorlon: on, oh that theme, to throw a spanner into the works---it is now possible to decrypt some/most of the P6-era intel microcode updates (and re-encrypt with a new key)
[17:27] <sladen> vorlon: perhaps freeness in Debian main would be the excuse to make some of that more public
[17:27] <vorlon> PatrickD31: this is related to a major dataloss regression that happened in the latest kernel update, there is currently no linux-meta package published in bionic-updates or bionic-security
[17:28] <vorlon> apw: ^^ is there an intent to restore the previously-published kernel back to bionic-{updates,security}?
[17:28] <vorlon> PatrickD31: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262 for details
[17:28] <ubottu> Launchpad bug 1907262 in linux (Ubuntu) "raid10: discard leads to corrupted file system" [Undecided,Confirmed]
[17:28] <jibel> sil2100, I was referring to MiscTests https://paste.ubuntu.com/p/YXtqdw5g7z/
[17:29] <vorlon> sladen: well, we already ship {intel,amd64}-microcode in main in Ubuntu; I'm just wondering whether the rationale there extends to the rpi firmware package
[17:29] <apw> vorlon, working on it now
[17:29] <vorlon> would require some digging
[17:29] <vorlon> apw: ok cheers
[17:31] <sil2100> jibel: oh, the package built fine here, hm hm
[17:32] <sil2100> Though I don't run hirsute
[17:33] <sil2100> THis doesn't seem related to my change, and as said it built fine locally - I can take a look at fixing the FTBFS but does it build fine on the master branch?
[17:33] <jibel> sil2100, i'll rebase your mp and try again
[17:33] <jibel> sil2100, yes master builds fine
[17:39] <PatrickD31> @apw Any ETA on when those packages will be back ?
[17:39] <udevbot_> Error: "apw" is not a valid command.
[17:39] <apw> PatrickD31, working on it now, so 'a couple of publisher runs' i would expect
=== ijohnson is now known as ijohnson|lunch
[18:19] <sil2100> vorlon: hm, ok, so I tried discussing this with multiple people on multiple occassions and I never got a 'no' for per-device seeds, since this is a problem I tried solving since a while
[18:20] <sil2100> vorlon: we want to have an option to be able to freely add and remove packages during upgrades for people using our raspi images, as per the problem we had previously - installing them via livecd-rootfs is not very flexible as they're basically unmanaged by any means
[18:20] <sil2100> Like this one time when we wanted to migrate raspi beta users from raspi-firmware to linux-firmware-raspi
[18:21] <sil2100> I was asking: is there a reason we don't want per-device seeds? Since the other way to do it would be creating a separate raspi-something package that would be the one managing raspi-specific deps, enabling us to add new packages when needed, remove some etc.
[18:21] <sil2100> But that's basically what we get now by having raspi specific seeds
[18:22] <sil2100> Anyway, not sure how to proceed here, I personally like the way of having raspi seeds, but I completely missed the whole situation that there is this main <-> restricted conflict
[18:23] <sil2100> So I'd be more inclined to maybe just get the raspi firmware bits pulled into main?
=== ijohnson|lunch is now known as ijohnson
[20:58] <juliank> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Groovy | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
[21:39] <doko> icey, jamespage: python3-ironic uses versioned shebangs, that's why it needs sourceful uploads in python3 transitions. please could you change that to unversioned shebangs?