[00:50] <mwhudson> ubuntu-archive (is that the right group?) could someone upscore https://launchpad.net/~canonical-foundations/+snap/subiquity/+build/1375605 slightly, i want the build to complete before I EOD
[02:12] -queuebot:#ubuntu-release- Unapproved: makedumpfile (bionic-proposed/main) [1:1.6.5-1ubuntu1~18.04.5 => 1:1.6.5-1ubuntu1~18.04.6] (core)
[02:12] -queuebot:#ubuntu-release- Unapproved: makedumpfile (groovy-proposed/main) [1:1.6.7-4ubuntu1 => 1:1.6.7-4ubuntu1.1] (core)
[02:12] -queuebot:#ubuntu-release- Unapproved: makedumpfile (focal-proposed/main) [1:1.6.7-1ubuntu2.1 => 1:1.6.7-1ubuntu2.2] (core)
[02:26] <ddstreet> oops, i missed that someone already sponsored makedumpfile. can someone reject my newer makedumpfile uploads from the b/f/g queues? they should be identical to dannf previous uploads from a few hours ago
[06:13] -queuebot:#ubuntu-release- Unapproved: open-iscsi (focal-proposed/main) [2.0.874-7.1ubuntu6.1 => 2.0.874-7.1ubuntu6.2] (ubuntu-desktop, ubuntu-server)
[06:13] -queuebot:#ubuntu-release- Unapproved: open-iscsi (groovy-proposed/main) [2.1.1-1ubuntu2 => 2.1.1-1ubuntu2.1] (ubuntu-desktop, ubuntu-server)
[06:36] <tjaalton> doko: this is what I get when building llvm locally https://pastebin.com/vDkiMsq3
[06:36] <tjaalton> is my chroot busted?
[06:36] -queuebot:#ubuntu-release- Unapproved: rejected makedumpfile [source] (bionic-proposed) [1:1.6.5-1ubuntu1~18.04.6]
[06:37] -queuebot:#ubuntu-release- Unapproved: rejected makedumpfile [source] (focal-proposed) [1:1.6.7-1ubuntu2.2]
[06:37] -queuebot:#ubuntu-release- Unapproved: rejected makedumpfile [source] (groovy-proposed) [1:1.6.7-4ubuntu1.1]
[06:57] <tjaalton> meh, seems it didn't like parallel=20
[07:20] -queuebot:#ubuntu-release- Unapproved: elfutils (hirsute-proposed/main) [0.183-6 => 0.183-7] (core, i386-whitelist) (sync)
[07:40] -queuebot:#ubuntu-release- Unapproved: gcc-9 (hirsute-proposed/universe) [9.3.0-23ubuntu1 => 9.3.0-23ubuntu2] (i386-whitelist)
[07:41] -queuebot:#ubuntu-release- Unapproved: accepted elfutils [sync] (hirsute-proposed) [0.183-7]
[07:42] <doko> I didn't see these errors yet
[07:42] -queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [source] (hirsute-proposed) [9.3.0-23ubuntu2]
[07:50] <tjaalton> I don't get it, only parallel=1 doesn't fail
[07:50] <tjaalton> looks like migrating to llvm-12 needs an sru now anyway
[08:16] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (hirsute-proposed) [4-0ubuntu3]
[08:59] <RikMills> sil2100: I think I found the reason for the KDE ubiquity wifi crash. I am just not sure if reverting the change that appeared to cause it might crash the UI in other places
[09:28] <sil2100> RikMills: what commit is that?
[09:29] <RikMills> sil2100: https://git.launchpad.net/ubiquity/commit/?id=0ffb72be73e22d201e40e153eea0c678d70a4532
[09:29] <ubot3> Commit 0ffb72b in ubiquity "Update from sip4 to sip from PyQt5"
[09:29] <RikMills> the sip.enableautoconversion(QtCore.QVariant, False) part
[09:30] <RikMills> as our crash is: TypeError: unhashable type: 'QVariant'
[09:31] <RikMills> sil2100: may also be the cause of LP: #1916331
[09:31] <ubot3> Launchpad bug 1916331 in ubiquity (Ubuntu Hirsute) "Cannot Select TimeZone at Install Time (Kubuntu)" [High, Confirmed] https://launchpad.net/bugs/1916331
[09:31] <RikMills> as this is in the logs of that one: https://irc-attachments.kde.org/tw91cuWe/file_41777.jpg
[09:32] <RikMills> sil2100: what I don't know is the side effect of toggling to True
[09:33] <RikMills> or whether we need to inline conversions on case by case
[09:34] <RikMills> gotta go run some chores. will be back about lunchtime
[09:43] <sil2100> I don't know these parts, but reading around it seems that someone said the disabled autoconversion is the same as in v1, which I see was being used there previously
[09:53] -queuebot:#ubuntu-release- Unapproved: indicator-power (hirsute-proposed/universe) [12.10.6+17.10.20170829.1-0ubuntu6 => 12.10.6+17.10.20170829.1-0ubuntu7] (ubuntu-budgie)
[09:53] <xnox> RikMills:  sil2100: reading https://doc.bccnsoft.com/docs/PyQt5/pyqt_qvariant.html under python3 there should be no QVariant at all.
[09:53] <xnox> in python3
[09:55] <xnox> An invalid QVariant is automatically converted to None and vice versa.
[09:55] <xnox> PyQt5 does not support the QPyNullVariant class.
[09:55] <xnox> and i thought in python None is not-hashable.
[09:55] -queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (hirsute-proposed/main) [165 => 166] (ubuntu-desktop)
[09:56] <xnox> and i'm wrong, None got hashed as a dictionary key just fine.
[09:57] <xnox> RikMills:  i would be up for dropping `sip.enableautoconversion(QtCore.QVariant, False)` and see what happens. As normal native types in python3 sounds like the future.
[10:08] <sil2100> Laney: hey! Can you take a look at ubiquity-slideshow-ubuntu ? It's a fix for xubuntu translations that got lost as they're not hosted  via LP
[10:09] <Laney> okey dokey
[10:10] <Laney> ✅
[10:10] <Laney> sil2100: might want to document that 😬
[10:11] -queuebot:#ubuntu-release- Unapproved: accepted indicator-power [source] (hirsute-proposed) [12.10.6+17.10.20170829.1-0ubuntu7]
[10:11] -queuebot:#ubuntu-release- Unapproved: software-properties (hirsute-proposed/main) [0.99.8 => 0.99.10] (core)
[10:11] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (hirsute-proposed) [166]
[10:16] <sil2100> Yeah, on it now!
[10:19] <sil2100> Done
[10:19] <sil2100> Also, langpacks incoming
[10:20] <sil2100> I'll batch-accept them once they're all uploaded
[10:20] <xnox> jibel: didrocks: see above discussion about QVariant stuff. Does it make sense to not have the enableautoconversion thing? or without it something else breaks in ubiquity?
[10:21] <jibel> xnox, it's worth testing without it, I don't recall if it broke anything
[10:25] <sil2100> Good that we're not trying such things one day before release
[10:40] <RikMills> xnox: I tried commenting out the lines in place on a live session, and it seemed to fix the wifi. though applying that to a ubiquity PPA upload, debuild failed to build a source package
[10:44] <RikMills> ubiquity/frontend/kde_ui.py:38: 'PyQt5.sip' imported but unused
[10:57] <RikMills> jibel: setting to 'True' also seems to fix the timezone selection issue
[10:57] <RikMills> question is, does every other part of the installer GUI remain non crashy
[11:09] <RikMills> one successful install completed for guided whole disk
[11:18] -queuebot:#ubuntu-release- Unapproved: adsys (hirsute-proposed/universe) [0.4 => 0.5] (no packageset)
[11:19] -queuebot:#ubuntu-release- Unapproved: accepted adsys [source] (hirsute-proposed) [0.5]
[11:27] <RikMills> sil2100: do you have thoughts on QA and timing for a fixed ubiquity KDE if this continues to look ok?
[11:28] <RikMills> I am guessing a late friday PM ubiquity upload is fairly horrifying
[11:28] -queuebot:#ubuntu-release- Unapproved: xubuntu-meta (hirsute-proposed/universe) [2.236 => 2.237] (xubuntu)
[11:34] <sil2100> RikMills: well, if we decide that we want to risk doing this change, I prefer it landing today as early as possible so that we have it tested throughout the weekend and before we spin our RCs
[11:35] <bluesabre> Laney: the above xubuntu-meta addresses an issue where gnome-software gets replaced with snap-store, patched similarly to how ubuntu budgie solved it previously. If you can accept it, I'd appreciate it. :)
[11:35] <sil2100> Since I'd say it's still fine to 'revert' this on Monday if we notice it actually broke something else, but later than that it's all too risky
[11:35] <sil2100> o/ Accepting langpacks in a batch
[11:35] <sil2100> xnox: reviewed your livecd-rootfs change o/
[11:37] <RikMills> lvm install went ok
[11:37] <Laney> ubiquity after final freeze, some things never change eh
[11:37] <Laney> bluesabre: righto
[11:42] <RikMills> sil2100: ok. I'll run through a few more obvious tests, then perhaps we can go ahead
[11:57] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (hirsute-proposed) [0.99.10]
[11:57] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-meta [source] (hirsute-proposed) [2.237]
[12:11] -queuebot:#ubuntu-release- Unapproved: rejected v4l2loopback [source] (focal-proposed) [0.12.5-1ubuntu1.20.04.1]
[12:22] <RikMills> sil2100: https://code.launchpad.net/~rikmills/ubiquity/+git/ubiquity/+merge/401297
[12:24] <RikMills> done 5 installs of various types. not been able to crash one yet, and have twiddled buttons/menus/checkboxes etc to try
[12:43] <RikMills> xnox: we can also lose the whole of this 'if'? https://git.launchpad.net/ubiquity/tree/ubiquity/frontend/kde_components/nmwidgets.py#n30
[12:43] <xnox> RikMills:  yes.
[12:44] <xnox> RikMills:  in general deleting lines of code is always preferred =)
[12:44] <xnox> a lot less confusing code overall.
[12:44] -queuebot:#ubuntu-release- Unapproved: gdm3 (hirsute-proposed/main) [3.38.2.1-2ubuntu1 => 3.38.2.1-3ubuntu1] (desktop-core)
[12:45] <RikMills> I think we need 'rm -rf' in the root of the ubiquity source to be honest... ;)
[12:45] <xnox> RikMills:  that's the plan => https://github.com/canonical/ubuntu-desktop-installer
[12:46] <RikMills> I would love to know if flavours will be able to theme that
[12:46] <RikMills> not re-works it as the KDE ubi frontend was
[12:47] <RikMills> just theme to fit better
[12:49] <xnox> RikMills: no idea. hopefully there is a way to fork the snap; stage most of it; and then add/change theming bits. But i have no idea how flutter works.
[12:49] <xnox> RikMills: I would want to avoid the monstrosity of ubiquity-dm which has support for every DE under the moon, and is very fragile, since it breaks everytime any of the DEs change things a bit.
[12:50] <xnox> and hence is exposed to all the changes =/
[12:50] <cjwatson> Oh, I'm glad somebody's working on that
[12:50] <xnox> =))))))))))))))))))))
[12:50] <cjwatson> (Extra-glad I'm not involved)
[12:50] <xnox> i have ideas, that i'm shouting, whilst siting in my arm chair.
[12:50] <xnox> i'm also very glad to not be involved =)
[12:51]  * xnox moving to kernel team anyway
[12:52] <RikMills> sil2100: I am building a new deb to sanity check. then will re-do a MP
[13:07] <sil2100> \o/
[13:08] <sil2100> RikMills: thanks
[13:15] <paride> sil2100, hi! A question: should the .OVERSIZE files be removed automatically from cdimage when the image they refer to is not oversize anymore?
[13:15] <paride> Look at http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/ we have hirsute-live-server-s390x.OVERSIZED
[13:16] <paride> as for some reason the *previous* hirsute-live-server-s390x image was oversize (> ~1.2GB), but now the ISO is back to 794GB
[13:16] <paride> but the OVERSIZE file is still there
[13:18] <xnox> what is the limit? is it _still_ oversize?
[13:21] <sil2100> I think it's 1.3GB for server right now
[13:22] <sil2100> Might be that those are not cleared, let me check the logic for that and remove those markers
[13:26] <paride> sil2100, for some reason the 20210415 s390x live-server image was oversize
[13:26] <paride> 1.3GB instead of the usual ~800MB
[13:27] <paride> it's back to normal now, but the OVERSIZED file is still there
[13:48] <RikMills> sil2100: https://code.launchpad.net/~rikmills/ubiquity/+git/ubiquity/+merge/401307
[13:52] <sil2100> RikMills: looks good, can we get that released?
[13:53] <RikMills> sil2100: I think so. my tests with the previous MP are still valid I think
[13:54] <sil2100> Can someone do the merging/sponsoring? I can then do the queue review part
[13:54] <RikMills> and 2 quick ones seem to be fine with the new ones
[13:58] -queuebot:#ubuntu-release- Unapproved: u-boot (hirsute-proposed/main) [2021.01+dfsg-3ubuntu6 => 2021.01+dfsg-3ubuntu7] (core)
[13:58] <xnox> sil2100:  it seems that even with good kernel unleashed images fail to boot off sdcard. However, if I apply all the unmatched patches when building unleashed platform it works correctly. This makes the unleashed codebase look more or less stock as upstream; and only unmatched platform having all the patches applied. This matches what upstream meta-sifive layer does too (they only apply
[13:58] <xnox> unmatched patches, when building unmatched)
[13:58] <xnox> sil2100:  this means unleashed will use more or less stock upstream u-boot.
[13:58] <xnox> sil2100:  i did local build of that, flashed it to an image; and succesfully deployed it using testflinger.
[13:59] <xnox> sil2100:  the change i'm introducing is only for the unleashed platform, all other u-boot targets remain the same.
[14:01] <sil2100> Love it! Good that it's only for the unmatched target though, but still, lovely to have a new u-boot after final freeze ;) Looking at it now
[14:02] <sil2100> Holy shit it's hacky
[14:02] <sil2100> xnox: ok, this is not super relevant right now, but does `quilt pop <patch name>` work properly when the patch is not the last one that's applied?
[14:03] <sil2100> Does `quilt push -a` then apply it at the right time and space?
[14:04] <sil2100> I must say that's the first time I see any package doing something like this conditionally in debian/rules, makes me shiver a bit
[14:18] <sil2100> Ah, it's very very tricky, like, we need to keep track of this since all the patches operate in series, so if we add some necessary patches later on we need to make sure it's not unapplied
[14:18] <sil2100> eh
[14:18] <sil2100> EH
[14:19] <sil2100> It's terrible and terrifying
[14:19] <Laney> it means pop up to this patch
[14:19] <Laney> yeah, not nice
[14:20] <sil2100> I see this also unapplies 'ubuntu-hardening-limit-keynames-to-keydir.patch', which seems not pi specific as the other patches
[14:21] <sil2100> apw: hey, can I get some context on this u-boot patch of yours? I'd like to know if it's relevant on all the u-boot targets ^
[14:22] <waveform> yes, that patch isn't pi specific -- it predates the pi patches by some way (I recall it from the last merge)
[14:23] <sil2100> Since if it's relevant to all arches, I wouldn't want riscv unleashed to be suddenly vulnerable to some attack because of that
[14:23] <sil2100> (while others still being patched)
[14:23] <waveform> (and has required some modification over the last couple of merges as the SSL licensing situation changed)
[14:24] <sil2100> xnox: ^
[14:24] <waveform> I'm pretty sure it's *not* relevant to the pi platform (which doesn't have any form of cryptography in the boot sequence -- at least that we use) but which platforms it *is* still relevant for, I'm not sure
[14:25] <waveform> let me just refresh my memory...
[14:26] <waveform> oh that's right - it's the bit that enables FIT signatures]
[14:27] <sil2100> RikMills: ok, since no one else is willing, I'm merging the ubiquity change and prepping a release
[14:28] <Laney> I thought x_nox was doing that since it was approved, sorry
[14:28] <Laney> can do the Q review
[14:29] <sil2100> xnox went MIA!
[14:30] <waveform> sil2100, from a rough grep I'd guess that it's relevant to the imx6 platform (which has FIT_SIGNATURE=y), not pi, and not riscv (neither has FIT_SIGNATURE enabled) -- there's quite a lot of other boards with FIT_SIGNATURE enabled but imx6 is the only one that's jumping out at me as something we support
[14:31] <jibel> sil2100, could you release https://bazaar.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html/revision/894 ?
[14:31] <jibel> seb128, ^ FYI
[14:31] <sil2100> jibel: sure o/
[14:32] <sil2100> hm, I uploaded ubiquity and it went nowhere
[14:32] <sil2100> ;)
[14:38] <sil2100> Poking around to see if it's just me or if it's some outage
[14:40] <sil2100> jibel: sponsored
[14:40] <sil2100> Uploads should arrive in the queue soon
[14:40] <Laney> looks like upload processing is off
[14:40] <sil2100> Yeah, it's been switched on again
[14:40]  * Laney spying in the logs
[14:40] -queuebot:#ubuntu-release- Unapproved: ubiquity (hirsute-proposed/main) [21.04.16 => 21.04.17] (desktop-core)
[14:40] <sil2100> (per is outage)
[14:41] <Laney> k00l
[14:41] -queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (hirsute-proposed/main) [165 => 167] (ubuntu-desktop)
[14:41] <sil2100> waveform: hm hm, so are we certain it's not relevant to platforms like riscv then?
[14:41] <sil2100> If it's FIT specific then I guess we're good
[14:42] <xnox> sil2100: all patches that are unapplied are irrelevant to unleashed/riscv64. They are for Pi, or things that have FIT signed images, or for platforms we no longer support. None of that is used on riscvt64.
[14:43] <Laney> I think you at the very least should have a comment in the series file explaining that things after that point may be unapplied
[14:43] <xnox> sil2100:  the ubuntu-hardening-limit-keynames-to-keydir.patch is only applied to tools
[14:43] <xnox> sil2100:  none of the platforms, build tools......
[14:43] <xnox> sil2100:  tools build still has that patch applied.
[14:44] <xnox> sil2100:  i'm only unapplying patches for platform bootloader build.
[14:44] <xnox> sil2100:  if it makes it nicer, i can reorder patches such that all the riscv64 ones are on top.
[14:44] <sil2100> That's the confirmation I needed! Since it had changes in the lib/ directory, wasn't sure if that's not used somewhre besides tools
[14:44] <xnox> a better solution is to figure out what in that riscv64 patch stack breaks unleashed and fix it to still work properly.
[14:45] <sil2100> Yep
[14:45] <xnox> sil2100:  that's still userspace tools only; not bootloader.
[14:45] <sil2100> Accepting it as is then
[14:45]  * Laney shrugs
[14:45] <xnox> sil2100:  and i shall debug it futher to fix it properly for upstream.
[14:45] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (hirsute-proposed) [21.04.17]
[14:46] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (hirsute-proposed) [167]
[14:46] <sil2100> xnox: thanks, I'd really not want to have this in HH+1
[14:46] <sil2100> As it makes me feel like shivering!
[14:46] -queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (hirsute-proposed) [2021.01+dfsg-3ubuntu7]
[14:46] <Laney> no comment it is!
[15:09] <bdmurray> sil2100: Is someone doing the merging / sponsoring of ubiquity or should I?
[15:10] <sil2100> I did that
[15:10] <Laney> bdmurray: it's done
[15:10] <sil2100> And Laney did the apppppproval
[15:10] <bdmurray> Oh, the MP is open
[15:11] <sil2100> Is it?
[15:11] <sil2100> hm hm
[15:11] <sil2100> I git pulled it
[15:11] <sil2100> Ah
[15:11] <sil2100> git push
[15:11] <bdmurray> Push it
[15:11] <Laney> 😅
[15:12] <sil2100> Done!
[15:18] <bdmurray> Laney, sil2100 - robie reminded me yesterday of the devel-unapproved trello board.
[15:20] <Laney> bdmurray: oh yeah
[15:33] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (groovy-proposed) [1:20.10.15]
[15:51] <sil2100> waveform: oh, just a quick touch base - did you land all the needed changes in ubuntu-settings?
[15:52] <sil2100> (for the ethernet USB renaming on pi's?)
[15:57] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (focal-proposed) [1:20.04.32]
[15:57] <bdmurray> sil2100: I think I accepted that yesterday afternoon
[15:58] <bdmurray> bug 1922266
[15:58] <ubot3> Bug 1922266 in ubuntu-settings (Ubuntu Hirsute) "eth0 interface name change fails on Pi 3/3+" [Undecided, Fix Released] https://launchpad.net/bugs/1922266
[16:02] <Laney> indeed i saw that go by
[16:18] <waveform> sil2100, yup - everything needed in ubuntu-settings is landed (I still need to figure out the usb-eth issue on the 3A+ but that'll just have to wait - it's addon hardware anyway, so not critical)
[16:48] <vorlon> https://people.canonical.com/~ubuntu-archive/priority-mismatches.html shows perl things as needing to be promoted, but I'm not sure why; the only thing that would appear to pull perl up to standard is perl-modules-5.32 which itself should not be.  So I'm trying to demote perl-modules-5.32 now to optional, and see what the report shows after
[16:48] <vorlon> (mentioning here because if I've got it wrong, it could have an impact on debootstrap for image builds)
[16:48] <vorlon> well - it's only standard so actually not
[16:49] <vorlon> but even so
[16:51] <vorlon> tseliot: hi, I don't remember if I filed a bug about it, but I think I at least asked on IRC a while ago about nvidia-settings being the only package built on i386 that's uninstallable; any chance of this being fixed soon?  (possibly too late for hirsute now, but worth a try) https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute_uninst.txt
[17:51] <RikMills> sil2100: did you mean that 1st RCs won't be spun until after the weekend?
[18:57] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (hirsute-proposed/main) [1:21.04.9 => 1:21.04.10] (core)
[19:06] <dbungert> bdmurray: for release-upgrader, changelog mentions updating translations, but the only changes there seem to be an increment of POT-Creation-Date, is that expected?
[19:11] <bdmurray> dbungert: yes, the pre-build script runs merge-po unconditionally
[19:12] <JawnSmith> Is there an LP bug for why we're updating the mirrors in u-r-u?
[19:13] <bdmurray> No, launchpad maintains a list of official mirrors of the ubuntu archive and u-r-u ships it.
[19:13] <JawnSmith> then the change LGTM
[19:13] <bdmurray> https://launchpad.net/ubuntu/+archivemirrors
[19:14] <dbungert> same, ship it
[19:14] <bdmurray> Updating the mirror list is also part of the pre-build script and we do that for point releases too.
[19:15] <bdmurray> Thanks!
[19:15] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (hirsute-proposed) [1:21.04.10]
[19:17] <bdmurray> For reference https://wiki.ubuntu.com/PointReleaseProcess says "Check to see if ubuntu-release-upgrader have been uploaded recently. If not, upload a new version after running pre-build.sh as that generates the updated lists of mirrors."
[19:18] <JawnSmith> thanks for the info!
[20:06] <vorlon> ugh it's mailcap (split out from mime-support) pulling in full perl >_<
[20:06] <vorlon> so, let's look at culling that
[20:44] -queuebot:#ubuntu-release- Unapproved: ddtp-translations (groovy-proposed/universe) [20201019.1 => 20210416.1] (no packageset)
[20:50] <vorlon> sil2100, bdmurray: I'd like to swap mime-support out of ubuntu-standard in favor of media-types; mime-support has been split upstream in Debian, and at the same time the mailcap portion has been fixed to properly depend on perl, which was a missing dependency before
[20:50] <vorlon> sil2100, bdmurray: I think anything that requires mailcap should depend on it explicitly, so we'd be ok to demote mailcap + mime-support and leave media-types in standard
[20:55] <bdmurray> vorlon: So the thing that could go wrong here is packages might fail to work if they have an undeclared dep on mailcap?
[21:29] -queuebot:#ubuntu-release- Unapproved: update-manager (hirsute-proposed/main) [1:21.04.8 => 1:21.04.9] (core)
[21:52] <vorlon> bdmurray: yes
[21:54] -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (hirsute-proposed/main) [1.467 => 1.468] (core)
[21:55] <vorlon> bdmurray: ^^
[21:56] <vorlon> bdmurray: by Debian Policy, any packages using mailcap were already supposed to depend on it
[21:58] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.43]
[22:08] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (hirsute-proposed) [1.468]
[23:07] -queuebot:#ubuntu-release- Unapproved: update-manager (hirsute-proposed/main) [1:21.04.8 => 1:21.04.10] (core)
[23:30] -queuebot:#ubuntu-release- Unapproved: update-manager (groovy-proposed/main) [1:20.10.5 => 1:20.10.6] (core)