=== ebarretto_ is now known as ebarretto
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/07:59
stevenm_I noticed a package the other day which mentioned in their changelog they'd dropped their "Application Indicator" plugin support08:01
stevenm_Which makes me wonder if there was a reason for that08:01
stevenm_I'm going to guess https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/ and AppIndicators are one and the same thing08:17
juliankstevenm_: I believe we use the org.kde ones, instead of org.freedesktop09:43
juliankstevenm_: So yes that thing, just replace freedesktop with kde everywhere basically09:43
stevenm_I'm kiiiinda following then09:48
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:50
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
juliankstevenm_: it's packaged as gnome-shell-extension-appindicator10:00
juliankstevenm_: The freedesktop spec is an attempt to standardize the kde extensino10:01
juliankI don't think it took off :)10:01
stevenm_ah i see so the org.kde version came first10:04
stevenm_and appindicators was just a Canonical-branded name for something that already existed?10:04
seb128stevenm_, rather a compatible implementation to be used on another desktop10:06
stevenm_"Drop Application Indicator plugin"10:07
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 place10:08
stevenm_I have asked the author here though... https://github.com/dlech/Keebuntu/issues/7110:08
stevenm_but I thought I'd try to some research to unpick the terminology a bit first.10:09
juliankthere's still keepass2-plugin-status-notifier10:09
stevenm_juliank, I think that's what he's referring to when he says dropping appindicator support10:10
stevenm_as of 0.7.x onwards anyway10:10
stevenm_as 0.6.1 works fine10:10
julianklibappindicator is dead10:11
julianksort of10:11
stevenm_oh lord, so the spec's not dead but the implementation is10:11
julianklibappindicator is replaced by libayatana-appindicator10:11
juliankbut in the case of your app10:11
juliankit directly implements status notifier spec now10:12
stevenm_what do you by "directly" - how is it any different to before?10:12
juliankYou don't need the library to implement the spec10:12
stevenm_right so did libappindicator act as some kind of go-between between apps and the proper org.kde spec?10:12
juliankit implemented the spec for you, and handled fallback to old systray stuff10:13
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 confused10:14
stevenm_ok so ayatana is a continuation of that library only10:25
seb128juliank, 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 unsupported11:16
juliankseb128: I thought a migration is going on11:18
juliankseb128: because libappindicator is not really maintained anymore11:18
seb128juliank, not in Ubuntu at least11:18
juliankseb128: Debian and Ubuntu MATE are pushing it is what I heard11:19
seb128a guy did an hostile fork and declared his is the actively maintained version11:19
juliankseb128: I know Debian is migrating, and I recall discussions in Ubuntu context11:19
seb128right, but Ubuntu itself isn't which is what I was pointing out11:19
=== Wryhder is now known as Lucas_Gray
juliankPeople who have focal, bionic, and xenial installed on a device with fwupd support11:35
juliankcan you install shim and shim-signed from proposed and check that bug 1864223 is not happening11:35
ubottubug 1864223 in shim (Ubuntu Focal) "shim 15+1552672080.a4a1fbe-0ubuntu1 fails to load fwupd" [Undecided,Fix committed] https://launchpad.net/bugs/186422311:35
juliankYou need to have a Linux Firmware Updater entry in your UEFI11:36
juliankOtherwise I'm just going to mark this as verified for all releases, as the binaries are the same for all of them anyway11:37
juliank(and there's no interaction with other parts that was causing the regression :D)11:38
xnoxjuliank:  can immediate-configuration take :native arg for the package name?12:53
xnoxseems 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
juliankxnox: it's on/off, not a list of names12:54
juliankthis has been discussed before, and the summary was that the libgcc-s1 rename does not work like that12:56
julianke.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96447712:57
ubottuDebian bug 964477 in libgcc1 "Implicit conflict between libgcc1 and libgcc-s1 prevents upgrade" [Important,Open]12:57
juliankwhich fails one level earlier12:58
juliankthough maybe it's a different issue12:59
xnoxjuliank:  are "solutions" in message #41 actually sane?13:00
xnoxgiven that libgcc-s1 provides libgcc113:01
xnoxslyon:  openvswitch built fine on riscv64, retrying netplan.io build.13:01
xnoxslyon:  however it fails on amd64,arm64,ppc64le har har13:02
juliankxnox: I trust david's opinion on that13:02
xnoxmaybe i should have copied it, instead of uploading fresh. that way existing binaries would have been used on other arches.13:03
juliankxnox: AFAICT; he actually tested those13:03
xnoxjuliank:  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
ubottuDebian bug 964477 in libgcc1 "Implicit conflict between libgcc1 and libgcc-s1 prevents upgrade" [Important,Open]13:03
juliankI don't know13:03
juliankit'S the important question13:04
juliankdoko wanted to avoid the breaks for fear of breaking stuff iirc, but not having the breaks actually breaks stuff13:04
seb128LocutusOfBorg, hey, do you think you could merge gst-plugins-good/bad1.0? you did the previous merge and they are needed for the new gstreamer13:05
juliankxnox: Doesn't help with the immediate configure issue though13:06
dokojuliank, xnox: I'm fine with any patch that doesn't ask about the removal of essential packages ...13:09
* juliank hates xenial13:10
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:11
LocutusOfBorgseb128, sure!13:13
seb128LocutusOfBorg, thanks!13:13
LocutusOfBorgseb128, when ding poppler, please have a look at this https://bugs.debian.org/96953713:14
ubottuDebian bug 969537 in elpa-pdf-tools-server "elpa-pdf-tools-server: broken when compiled against libpoppler102" [Grave,Fixed]13:14
seb128LocutusOfBorg, ack, I've the merge ready for upload but I wanted the libffi transition to be through before uploading13:14
xnoxcpaelzer:  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:04
xnoxcpaelzer: you will be uploading new dpdk soon right? so I should not have been touching openvswitch?15:05
Odd_Blokexnox: 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:05
Odd_Bloke(s/dual-boot/dual-phase boot/)15:09
xnoxOdd_Bloke:  yes, so, systemd in groovy supports loading some units, there were previously not found.15:13
xnoxOdd_Bloke:  yes, so, systemd in groovy supports loading some units, that there were previously not found.15:13
xnoxOdd_Bloke:  and it should be merging them into the current transaction.15:13
xnoxOdd_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_Blokexnox: So lazy-loading of a sort?15:14
xnoxOdd_Bloke:  https://github.com/CanonicalLtd/netplan/pull/15715:15
xnoxOdd_Bloke:  yes, but for only a specific subset of units.15:15
xnoxcore: refresh unit cache when building a transaction if UNIT_NOT_FOUND15:15
xnoxat the moment that is only available in groovy.15:16
Odd_BlokeAh, OK, so that netplan fix isn't backportable either.15:20
xnoxOdd_Bloke:  not without a backport of https://github.com/systemd/systemd/pull/1637115:20
xnoxthere are cross-projects deps either way.15:20
xnoxcloud-init & netplan => multi-transaction boot15:20
xnoxsystemd & netplan => lazy load netplan.target15:21
xnoxthere might be a way to achieve lazy-load netplan.target15:21
xnoxwith "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:21
xnoxbut i am sceptical that that is true, given once unit is loaded, that command would want to trigger daemon-reload too.15:22
Odd_Blokexnox: You mean it would just need a change in systemd unit files, rather than a backport of systemd C code?15:26
cpaelzerxnox: a new dpdk will come as soon as 19.11.4 is released15:28
cpaelzerxnox: the builds you'd seen where related to help upstream to not break itself15:28
cpaelzerxnox: there is also a OVS 2.13.1 in the making by the openstack team15:28
cpaelzerxnox: I verified it will build against the new DPDK15:29
cpaelzerI've not looked at risk for that thou15:29
cpaelzerxnox: risc seems happy with it https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4252/+build/1992148415:29
cpaelzerI don't know when/if the openstack Team planned to upload the new OVS15:30
xnox"You mean it would just need a change in systemd unit files, rather than a backport of systemd C code?" => yes.15:37
ubottuddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping19:01
rafaeldtinocorbasak: im out today (holiday here) wont be able to make it19:01
tewardrbasak: sorry i had no internet21:13
xnoxmwhudson:  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
xnoxdid we do something to our llvm to like enable optimizations that are disabled in debian or vice versa?22:14
mwhudsonxnox: it seems to take 12 hours longer each time we build it22:14
xnoxbut it only takes 12h in debian or so22:15
xnoxllvm itself takes 17h, even if one bootstraps that 3 times over, it should be just be 51h22:16
mwhudsonit takes about that on arm64 too22:16
mwhudsonxnox: is it all that's holding up libffi now?22:16
xnoxhm both s390x arm64 are in --max-parallel=222:16
* xnox wonders if we should add armhf there too22:17
mwhudsonoh so it might be in swap death?22:17
mwhudsonbut surely we don't have swap on buildds22:17
xnoxthey are overcommitted VMs22:17
xnoxwhich is effectively the same, no?22:17
mwhudsonyeah i guess so22:17
mwhudsonget someone in ~IS to run vmstat on the host or something22:18
mwhudsoni guess?22:18
xnoxlet me add armhf to --max-parallel=2 and throw that into a separate bileto ppa22:18

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!