[08:41] <doko> coreycb: yes, but the MIRs for the other two packages are missing
[08:48] <doko> Laney, seb128: update-notifier now depends on sugar, pulling in Python2 to main again
[08:48] <doko> I didn't track what changed
[08:56] <seb128> doko, is that because notification-daemon got deleted on i386 and it's finding it as an alternative stll existing?
[08:57] <seb128> doko, can we remove update-notifier/i386?
[09:10] <doko> seb128: I'm not familar with the i386 removals, or is this somewhere documented?
[09:11] <seb128> doko, I will check with Steve if there is a reason update-notifier wasn't removed (yet)
[09:11] <seb128> but my guess is that i386 is the issue there
[09:14] <seb128> tjaalton, hey, happy monday. Did you&vorlon reach an agreement on what to do with xorg-server/i386? it's still showing on the proposed migration blockeds items
[09:15] <Laney> seb128: doko: it looks like there's a chain from flashplugin-downloader
[09:16] <seb128> Laney, can't we delete that as well?
[09:16] <Laney> that is in the seed
[09:16] <Laney> https://people.canonical.com/~ubuntu-archive/germinate-output/i386.focal/all
[09:16] <seb128> ah
[09:16] <seb128> but I meant on i386
[09:16] <seb128> ignore that
[09:19] <tjaalton> seb128: yes, libdmx & libxres is needed on i386
[09:20] <tjaalton> didn't happen yet though
[09:20] <seb128> tjaalton, so what needs to happen? restoring back of libdmx1?
[09:20] <tjaalton> too many packages build-depend on xvfb, and i386 builds can't use nocheck
[09:21] <tjaalton> restoring them, yes
[09:21] <seb128> thx
=== Foxtrot is now known as Guest6307
[10:16] <Laney> seb128: just looked at update-notifier, those deps already have <!s390x> so perhaps we could add i386 to that
[10:18] <rbasak> Subject:  Your December issue of Packaging Technology Today has arrived!
[10:18] <rbasak> o_O
[10:27] <seb128> Laney, right, if we keep the i386 binaries I guess that makes sense
[10:34] <Laney> k, feel free to pursue any other option if you like it more
[10:37] <xnox> rbasak:  "dear editor, my name is robbie and carboard boxes and a bit of wrapping paper do not make a great .deb package!!! I know better!"
[10:38] <rbasak> "What you need are Santa's little debhelpers!"
=== zyga-laptop is now known as zyga-holidays
[13:10] <coreycb> doko: I've updated the MIR bug for the other packages
=== ricab is now known as ricab|lunch
=== cpaelzer__ is now known as cpaelzer
[14:19] <cpaelzer> thanks coreycb I was taking a look ath these MIRs but really it comes down to ask doko if this really becomes obsolte when python3.8 becomes the default
[14:19] <cpaelzer> doko: how willt hat work in python then?
[14:19] <cpaelzer> will src:python-importlib-metadata be removed and src:python3.8 starts to build that binary?
[14:20] <cpaelzer> even if that would be the case the same isn't true for zipp and itertools
[14:20] <cpaelzer> so will then python3.8 grow these dependencies?
[14:21] <cpaelzer> I'm wondering because I'd want to avoid doing a review and pushign it onto securities queue (which might take until 3.8 is the default) - to then throw away that work
[14:21] <doko> cpaelzer: no, my understand is that those will only be needed for Python2
[14:21] <doko> ding ...
[14:21] <cpaelzer> doko: but there is a "python3-importlib-metadata"
[14:22] <cpaelzer> would that grow a conflicts with python3.8 then?
[14:24] <cpaelzer> doko: I don't see it in libpython3.8-stdlib - is that were it would end up?
[14:25] <doko> cpaelzer: that's a backport to 3.7, not needed for 3.8 (hopefully)
[14:25] <cpaelzer> so the src:python-importlib-metadata would drop python3-importlib-metadata then
[14:25] <cpaelzer> because python3.8 libpython3.8-stdlib would contian it then?
[14:25] <doko> that's what I remember when looking at this, yes
[14:26] <cpaelzer> ok, so will then libpython3.8-stdlib get the dependency to e.g. python3-zipp that today is in python3-importlib-metadata?
[14:26] <doko> no
[14:26] <cpaelzer> or will all of that go into python3.8 stdlib?
[14:27] <cpaelzer> libpython3.8-minimal:amd64: /usr/lib/python3.8/importlib/metadata.py
[14:27] <cpaelzer> ok at least I found it within python3.8 now
[14:27] <cpaelzer> coreycb: ^^
[14:29] <cpaelzer> ok, so when python3.8 is the default kombu can drop the dependency to python3-importlib-metadata as it will be fulfilled with libpython3.8-minimal
[14:30] <cpaelzer> coreycb: even if I push through the MIR reviews from my quick view two will also need security review
[14:30] <cpaelzer> that will probably take until the same time that we need to see python3.8 as the default
[14:30] <cpaelzer> coreycb: so could we instead of pushing all these MIRs forward wait for 3.8 and then do this change in kombu?
[14:31] <doko> or we document that in the bug report, and only revisit that when we can't switch to 3.8, and pre-promote now
[14:31] <cpaelzer> doko: ^^ would that work in your opinion?
[14:31] <cpaelzer> doko: yeah that might be the best of both worlds
[14:31] <cpaelzer> getting things unblocked for now
[14:31] <doko> could you document that in the bug report?
[14:31] <cpaelzer> yes, but I'd at least want openstack to subscribe (for the interim time) to also feel responsible to get rid of it then ... :-)
[14:32] <cpaelzer> I'll ask james about the subscription and would document that in the bug then
[14:38] <doko> ok
[14:44] <coreycb> doko: cpaelzer: thanks sounds good
[14:57] <cpaelzer> doko: documented in 1851393 - could you do the interim pre-promotion?
[15:00] <cpaelzer> coreycb: ^^ FYI
[15:01] <rbasak> !dmb-ping
[15:01] <ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
=== ricab|lunch is now known as ricab
[15:45] <tomreyn> would it be ok to flag bugs which seem important enough to the general user base that they should be fixed for FF as "rls-ff-incoming"?
[15:46] <tomreyn> i'm just looking at bug 1466150 specifically
[15:46] <ubottu> bug 1466150 in grub-installer (Ubuntu) "grub-install breaks when ESP is on raid" [High,Triaged] https://launchpad.net/bugs/1466150
[15:48] <juliank> tomreyn: we already know about that one
[15:48] <juliank> you can see it's got an id- tag, so it kind of skipped rls-ff-incoming
[15:50] <tomreyn> juliank: yes i noticed it has an id assigned since 2018, it just looks like it might have been forgotten about, and i can never tell whether or not that's the case, or whether it's assigned to a (now) ex employee etc.
[15:50] <juliank> Well, it seems it was marked as done
[15:51] <tomreyn> maybe it is, and the bug report hasn't been updated. i have not tested it on anything recent.
[15:51] <tomreyn> marked as done internally, right?
[15:52] <juliank> xnox, cyphermox what's up wit hthat bug?
[15:53] <cyphermox> eep
[15:53] <juliank> I remember something about ESP on raid, but I don't know where
[15:53] <cyphermox> well, that might be perilous
[15:54] <juliank> Ah I think what I remembered was bugs about raid1 support in subiquity because I played with that
[15:54] <tomreyn> i think i also have a bug open about esp on raid against subiquity or curtin.
[15:55] <juliank> AFAIUI you cannot put ESP on RAID
[15:55] <juliank> which the last comment suggested :D
[15:55] <cyphermox> juliank: you certain could put ESP on RAID
[15:55] <cyphermox> the issue is what happens if your firmware decides it needs to write to it
[15:55] <juliank> cyphermox: I mean you could, but the firmware's allowed to write to it :D
[15:55] <juliank> yeah
[15:56] <juliank> I remember years ago when people asked me to implement this back when I maintained gummiboot in Debian
[15:57] <tomreyn> the clean solution is to have grub quit with an error of "it's not safe to write esp on raid", and have installers understand how to deal with this. the user friendly solution is to enable grub to install on mdadm raid-1 partitions with <=1.0 metadata, issuing a warning, and have installers handle this gracefully.
[15:57] <juliank> In any case, the bug got fairly confused
[15:58] <juliank> I think the correct solution would be to have it mount multiple ESPs and update them all
[15:58] <juliank> but I don't really know
[15:58] <juliank> "I'm having the same problem with a new Gentoo install, but with a twist."
[15:58] <juliank> wow, how's that relevant in an ubuntu bug?
[15:59] <tomreyn> it's not, also not a configuration that could work.
[15:59] <juliank> huh?
[15:59] <juliank> You partition each disk into two partitions
[15:59] <juliank> you raid the big one, and the small ones become ESPs
[16:00] <tomreyn> the gentoo person has lvm's raid supnm across two physical disks
[16:00] <tomreyn> s/supnm/spun/
[16:00] <tomreyn> and an esp LV on top
[16:00] <juliank> I do think the importance is weird, it should be wishlist
[16:01] <tomreyn> grub fails to handle it at all currentl,y that's abug IMO
[16:01] <juliank> IMO, it's about adding a feature to support updating multiple ESPs
[16:02] <tomreyn> enabling installation of esp on top of mdadm raid-1 is a feature request IMO, as would be grub supporting updating multiple ESPs.
[16:02] <juliank> I mean sure there could be a nice error message, but that does not help anyone, just breaks your upgrades
[16:02] <juliank> Right, but I don't think ESP on raid1 is something that should be supported, as it's not safe
[16:02] <tomreyn> the latter is non tricvial. you'd not just need to update multiple ESPs, but also manage multiple boot records in nvram
[16:04] <tomreyn> i like good error messages, since they tell me what i did wrong (or some software did wrong).
[16:04] <juliank> Sure
[16:04] <juliank> But it doesn't work
[16:05] <juliank> If you error out in grub update, you break the package management
[16:05] <tomreyn> i agree, it won't help those who already have such a setup
[16:05] <tomreyn> or are trying to install to it
[16:06] <juliank> But it takes a lot of effort to create a setup like that
[16:06] <juliank> it's not something you can do easily in a straightforward way with the installer
[16:08] <tomreyn> btw the subiquity bug report i recalled about is bug 1817066 (and its not mine)
[16:08] <ubottu> bug 1817066 in subiquity "support installing multiple ESPs" [High,Triaged] https://launchpad.net/bugs/1817066
[16:09] <tomreyn> so that's basically about what you had on your mind
[16:21] <juliank> ah yes
[16:21] <juliank> tomreyn: that's what I remember
[17:05] <CarlFK> how can I grab the text of an installer error from the text based installer?  this one:  http://archive.ubuntu.com/ubuntu/dists/eoan/main/installer-amd64/current/images/hd-media/boot.img.gz
[17:05] <juliank> CarlFK: Go to other tty and look at log?
[17:06] <juliank> CarlFK: please be aware that we're migrating away from d-i
[17:06] <juliank> or well, discontinuing it
[17:07] <juliank> starting with focal
[17:07] <CarlFK> oh my
[17:07] <CarlFK> will there be support for preeseed install ?
[17:08] <juliank> CarlFK: automated server installs are on the roadmap https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls
[17:09] <juliank> ubiquity, the desktop installer, I think does support preseeding to some extend, as it embeds parts of d-i
[17:14] <CarlFK> has anyone made a d-i preseed file to yml converter?
[17:15] <juliank> I don't think so, I'm not sure that would even work reasonably
[17:17] <CarlFK> hmm.. someone would need to maintain a map to translate keys and ... structure?  something.  seems like too much work.
[17:20] <CarlFK> is there any hint that Debian will do this too?
[18:04] <tomreyn> juliank: thanks for taking the time to discuss, i posted what i think we concluded (and more) to bug 1817068
[18:04] <ubottu> bug 1817068 in subiquity "Guided partitioning with multiple disks" [High,Triaged] https://launchpad.net/bugs/1817068
[21:03] <juliank> seb128: fyi: poppler should be fixed now in focal-proposed and eoan unapproved queue
[21:03] <seb128> juliank, great, thanks!
[21:03] <juliank> sorry for breaking it!
[22:46] <mwhudson> CarlFK: hi, i have no plans for a preseed -> yaml converter but maybe we could do something for simple cases
[22:46] <mwhudson> CarlFK: do you have an example of what you are using?
[22:51] <CarlFK> mwhudson: https://salsa.debian.org/debconf-video-team/ansible/blob/master/roles/tftp-server/files/d-i/xenial/preseed.cfg
[22:52] <CarlFK> mwhudson: I'm skeptical it is worth the effort just for this case
[22:53] <mwhudson> CarlFK: it's still interesting to see what people do
[22:54] <mwhudson> CarlFK: i think most of this preseed can be replaced with an empty file :)
[22:54] <mwhudson> d-i apt-setup/enable-source-repositories boolean true <- don't have a canned equivalent to that
[22:54] <CarlFK> mwhudson: I was thinking the yml might be pretty simple
[22:54] <mwhudson> CarlFK: certainly hope so
[22:56] <CarlFK> and it doesn't have to be exactly the same.  historically we had apps that installed cleanly on ubuntu but not debian, so some of us (me) would use ubuntu, but others would work out all the patches and what not to make things run on debian stable
[22:57] <CarlFK> now things are much better supported on both, so I look to ubuntu for hardware drivers that are harder to get onto a debian box
[22:58] <CarlFK> it would be great if the kernel arg shortcuts were supported
[22:59] <CarlFK> hmm, I have:  debconf/priority=high auto=true netcfg/dhcp_timeout=60 fb=false  hostname?=bare hw-detect/load_firmware=false
[22:59] <CarlFK> wait.. thats not normal.  whoops.
[23:00] <CarlFK> debconf/priority=high auto=true netcfg/dhcp_timeout=60 fb=false  hostname?=bare url=pc8.home hw-detect/load_firmware=false
[23:12] <mwhudson> CarlFK: you mean being able to override particular settings on the kernel command line?
[23:13] <CarlFK> mwhudson: mostly the ones that need to happen in order to get to the preseed file, like network and url=
[23:15] <CarlFK> mwhudson: if you want to dig into this and wonder where to start: https://github.com/CarlFK/veyepar/wiki/System-Stack#what-to-do-first
[23:16] <CarlFK> there is also PXE but that's more work so not a great "start here"
[23:16] <CarlFK> https://debconf-video-team.pages.debian.net/ansible/usb_install/usb_or_pxe.html