[07:59] <stevenm_> Hey are "Indicator Applets" (aka "App Indicators) an entirely Ubuntu/Canonical concept... and whether it is or not... does it implement any kind of higher standard, e.g. does it implement this from freedesktop.org... https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/
[08:01] <stevenm_> I noticed a package the other day which mentioned in their changelog they'd dropped their "Application Indicator" plugin support
[08:01] <stevenm_> Which makes me wonder if there was a reason for that
[08:17] <stevenm_> I'm going to guess https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/ and AppIndicators are one and the same thing
[09:43] <juliank> stevenm_: I believe we use the org.kde ones, instead of org.freedesktop
[09:43] <juliank> stevenm_: So yes that thing, just replace freedesktop with kde everywhere basically
[09:48] <stevenm_> I'm kiiiinda following then
[09:50] <stevenm_> juliank, so the "Indicator Applets" (as e.g. GNOME 2.x / MATE would call them) basically implements org.kde.StatusNotifierItem (which is AKA... KStatusNotifierItem  and also AKA AppIndicators)... and that is itself a spec that maybe was inspired by the fdo version?
[09:51] <stevenm_> and presumably for all you regular users of the main version of Ubuntu... do you all use this?  (or does it come pre-installed?)
[09:51] <stevenm_> https://extensions.gnome.org/extension/615/appindicator-support/
[10:00] <juliank> stevenm_: it's packaged as gnome-shell-extension-appindicator
[10:01] <juliank> stevenm_: The freedesktop spec is an attempt to standardize the kde extensino
[10:01] <juliank> I don't think it took off :)
[10:04] <stevenm_> ah i see so the org.kde version came first
[10:04] <stevenm_> and appindicators was just a Canonical-branded name for something that already existed?
[10:06] <seb128> stevenm_, rather a compatible implementation to be used on another desktop
[10:07] <stevenm_> https://launchpadlibrarian.net/414463585/keepass2-plugin-ubuntu_0.7.0_source.changes
[10:07] <stevenm_> "Drop Application Indicator plugin"
[10:08] <stevenm_> can anyone think (I know you're not the authors, and neither am I)... why anyone might choose to drop support for it then?
[10:08] <stevenm_> at first I thought maybe they were going KDE/qt specific - but it would seem KDE originated the spec in the first place
[10:08] <stevenm_> I have asked the author here though... https://github.com/dlech/Keebuntu/issues/71
[10:09] <stevenm_> but I thought I'd try to some research to unpick the terminology a bit first.
[10:09] <juliank> there's still keepass2-plugin-status-notifier
[10:10] <stevenm_> juliank, I think that's what he's referring to when he says dropping appindicator support
[10:10] <stevenm_> as of 0.7.x onwards anyway
[10:10] <stevenm_> as 0.6.1 works fine
[10:10] <juliank> no
[10:11] <juliank> libappindicator is dead
[10:11] <juliank> sort of
[10:11] <stevenm_> oh lord, so the spec's not dead but the implementation is
[10:11] <juliank> no
[10:11] <juliank> libappindicator is replaced by libayatana-appindicator
[10:11] <juliank> but in the case of your app
[10:12] <juliank> it directly implements status notifier spec now
[10:12] <stevenm_> what do you by "directly" - how is it any different to before?
[10:12] <juliank> You don't need the library to implement the spec
[10:12] <stevenm_> right so did libappindicator act as some kind of go-between between apps and the proper org.kde spec?
[10:13] <juliank> it implemented the spec for you, and handled fallback to old systray stuff
[10:14] <stevenm_> so maybe I don't see it appear on my panel - is because the version of MATE in 18.04 - doesn't support this ayatana version of appindicator?!  so totally confused
[10:25] <stevenm_> ok so ayatana is a continuation of that library only
[11:16] <seb128> juliank, the statement you made before isn't really true in Ubuntu, libappindicator is still what install by default and recommend, the ayatana is in universe and unsupported
[11:18] <juliank> seb128: I thought a migration is going on
[11:18] <juliank> seb128: because libappindicator is not really maintained anymore
[11:18] <seb128> juliank, not in Ubuntu at least
[11:19] <juliank> seb128: Debian and Ubuntu MATE are pushing it is what I heard
[11:19] <seb128> a guy did an hostile fork and declared his is the actively maintained version
[11:19] <juliank> seb128: I know Debian is migrating, and I recall discussions in Ubuntu context
[11:19] <seb128> right, but Ubuntu itself isn't which is what I was pointing out
[11:35] <juliank> People who have focal, bionic, and xenial installed on a device with fwupd support
[11:35] <juliank> can you install shim and shim-signed from proposed and check that bug 1864223 is not happening
[11:36] <juliank> You need to have a Linux Firmware Updater entry in your UEFI
[11:37] <juliank> Otherwise I'm just going to mark this as verified for all releases, as the binaries are the same for all of them anyway
[11:38] <juliank> (and there's no interaction with other parts that was causing the regression :D)
[12:53] <xnox> juliank:  can immediate-configuration take :native arg for the package name?
[12:53] <xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/d/doxygen/20200907_092712_fa8f2@/log.gz
[12:54] <xnox> seems to indicate we fail at "immediate configuration" when we need to immediately configure _both_ libgcc-s1:amd64 libgcc-s1:i386, or like libc6:amd64 and libc6:i386.
[12:54] <juliank> xnox: it's on/off, not a list of names
[12:56] <juliank> this has been discussed before, and the summary was that the libgcc-s1 rename does not work like that
[12:57] <juliank> e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964477
[12:58] <juliank> which fails one level earlier
[12:59] <juliank> though maybe it's a different issue
[13:00] <xnox> related
[13:00] <xnox> juliank:  are "solutions" in message #41 actually sane?
[13:01] <xnox> given that libgcc-s1 provides libgcc1
[13:01] <xnox> slyon:  openvswitch built fine on riscv64, retrying netplan.io build.
[13:02] <xnox> slyon:  however it fails on amd64,arm64,ppc64le har har
[13:02] <slyon> thanks!
[13:02] <juliank> xnox: I trust david's opinion on that
[13:03] <xnox> maybe i should have copied it, instead of uploading fresh. that way existing binaries would have been used on other arches.
[13:03] <juliank> xnox: AFAICT; he actually tested those
[13:03] <xnox> cool.
[13:03] <xnox> juliank:  so what does doko think about implementing one of those three solutions from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964477#41 ?
[13:03] <juliank> I don't know
[13:04] <juliank> it'S the important question
[13:04] <juliank> doko wanted to avoid the breaks for fear of breaking stuff iirc, but not having the breaks actually breaks stuff
[13:05] <seb128> LocutusOfBorg, hey, do you think you could merge gst-plugins-good/bad1.0? you did the previous merge and they are needed for the new gstreamer
[13:06] <juliank> xnox: Doesn't help with the immediate configure issue though
[13:09] <doko> juliank, xnox: I'm fine with any patch that doesn't ask about the removal of essential packages ...
[13:10]  * juliank hates xenial
[13:11] <juliank> (it does not interact well with virtio-vga)
[13:11] <juliank> (like you need to resize twice to get it to display anything)
[13:13] <LocutusOfBorg> seb128, sure!
[13:13] <seb128> LocutusOfBorg, thanks!
[13:14] <LocutusOfBorg> seb128, when ding poppler, please have a look at this https://bugs.debian.org/969537
[13:14] <seb128> LocutusOfBorg, ack, I've the merge ready for upload but I wanted the libffi transition to be through before uploading
[15:04] <xnox> cpaelzer:  hm, i've tried to gain openvswitch binaries on riscv64 but that ftbfs with current dpdk. But i see you have a new dpdk on the go in bileto and with that openvswitch appears to build.
[15:05] <xnox> cpaelzer: you will be uploading new dpdk soon right? so I should not have been touching openvswitch?
[15:05] <Odd_Bloke> xnox: We were talking about systemd upstream support for "inflight transactions" being added (in the context of dual-boot for netplan/cloud-init interop); you didn't have time to explain your thoughts before, would you be able to expand on them now?
[15:09] <Odd_Bloke> (s/dual-boot/dual-phase boot/)
[15:13] <xnox> Odd_Bloke:  yes, so, systemd in groovy supports loading some units, there were previously not found.
[15:13] <xnox> Odd_Bloke:  yes, so, systemd in groovy supports loading some units, that there were previously not found.
[15:13] <xnox> Odd_Bloke:  and it should be merging them into the current transaction.
[15:14] <xnox> Odd_Bloke:  thus allowing to "slot-in" something that was not there before, and yet, be used with things like "After=" during initial boot.
[15:14] <Odd_Bloke> xnox: So lazy-loading of a sort?
[15:15] <xnox> Odd_Bloke:  https://github.com/CanonicalLtd/netplan/pull/157
[15:15] <xnox> Odd_Bloke:  yes, but for only a specific subset of units.
[15:15] <xnox> core: refresh unit cache when building a transaction if UNIT_NOT_FOUND
[15:16] <xnox> https://github.com/systemd/systemd/pull/16371
[15:16] <xnox> at the moment that is only available in groovy.
[15:20] <Odd_Bloke> Ah, OK, so that netplan fix isn't backportable either.
[15:20] <xnox> Odd_Bloke:  not without a backport of https://github.com/systemd/systemd/pull/16371
[15:20] <xnox> there are cross-projects deps either way.
[15:20] <xnox> cloud-init & netplan => multi-transaction boot
[15:21] <xnox> systemd & netplan => lazy load netplan.target
[15:21] <xnox> there might be a way to achieve lazy-load netplan.target
[15:21] <xnox> with "systemctl restart network.target" which shouldn't need a backport of systemd, just a change in either systemd or cloud-init to do that.
[15:22] <xnox> but i am sceptical that that is true, given once unit is loaded, that command would want to trigger daemon-reload too.
[15:26] <Odd_Bloke> xnox: You mean it would just need a change in systemd unit files, rather than a backport of systemd C code?
[15:28] <cpaelzer> xnox: a new dpdk will come as soon as 19.11.4 is released
[15:28] <cpaelzer> xnox: the builds you'd seen where related to help upstream to not break itself
[15:28] <cpaelzer> xnox: there is also a OVS 2.13.1 in the making by the openstack team
[15:29] <cpaelzer> xnox: I verified it will build against the new DPDK
[15:29] <cpaelzer> I've not looked at risk for that thou
[15:29] <cpaelzer> xnox: risc seems happy with it https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4252/+build/19921484
[15:30] <cpaelzer> I don't know when/if the openstack Team planned to upload the new OVS
[15:31] <cpaelzer> s/you'd/you've/
[15:37] <xnox> "You mean it would just need a change in systemd unit files, rather than a backport of systemd C code?" => yes.
[19:01] <rbasak> !dmb-ping
[19:01] <rafaeldtinoco> rbasak: im out today (holiday here) wont be able to make it
[21:13] <teward> rbasak: sorry i had no internet
[22:14] <xnox> mwhudson:  still confused by ghc. what did we do in ubuntu that it takes so much longer for us, than it does for debian.
[22:14] <xnox> did we do something to our llvm to like enable optimizations that are disabled in debian or vice versa?
[22:14] <mwhudson> xnox: it seems to take 12 hours longer each time we build it
[22:15] <xnox> but it only takes 12h in debian or so
[22:16] <mwhudson> huh
[22:16] <xnox> llvm itself takes 17h, even if one bootstraps that 3 times over, it should be just be 51h
[22:16] <mwhudson> it takes about that on arm64 too
[22:16] <mwhudson> xnox: is it all that's holding up libffi now?
[22:16] <xnox> yes
[22:16] <xnox> hm both s390x arm64 are in --max-parallel=2
[22:17]  * xnox wonders if we should add armhf there too
[22:17] <mwhudson> oh so it might be in swap death?
[22:17] <mwhudson> but surely we don't have swap on buildds
[22:17] <xnox> they are overcommitted VMs
[22:17] <xnox> which is effectively the same, no?
[22:17] <mwhudson> yeah i guess so
[22:18] <mwhudson> get someone in ~IS to run vmstat on the host or something
[22:18] <mwhudson> i guess?
[22:18] <xnox> let me add armhf to --max-parallel=2 and throw that into a separate bileto ppa