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