| === 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 support | 08:01 |
| stevenm_ | Which makes me wonder if there was a reason for that | 08:01 |
| stevenm_ | I'm going to guess https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/ and AppIndicators are one and the same thing | 08:17 |
| 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:43 |
| stevenm_ | I'm kiiiinda following then | 09: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 |
| stevenm_ | https://extensions.gnome.org/extension/615/appindicator-support/ | 09:51 |
| juliank | stevenm_: it's packaged as gnome-shell-extension-appindicator | 10:00 |
| juliank | stevenm_: The freedesktop spec is an attempt to standardize the kde extensino | 10:01 |
| juliank | I don't think it took off :) | 10:01 |
| 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:04 |
| seb128 | stevenm_, rather a compatible implementation to be used on another desktop | 10:06 |
| stevenm_ | https://launchpadlibrarian.net/414463585/keepass2-plugin-ubuntu_0.7.0_source.changes | 10:07 |
| 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 place | 10:08 |
| stevenm_ | I have asked the author here though... https://github.com/dlech/Keebuntu/issues/71 | 10:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| juliank | it implemented the spec for you, and handled fallback to old systray stuff | 10: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 confused | 10:14 |
| stevenm_ | ok so ayatana is a continuation of that library only | 10:25 |
| 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:16 |
| 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:18 |
| 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:19 |
| === Wryhder is now known as Lucas_Gray | ||
| 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:35 |
| ubottu | bug 1864223 in shim (Ubuntu Focal) "shim 15+1552672080.a4a1fbe-0ubuntu1 fails to load fwupd" [Undecided,Fix committed] https://launchpad.net/bugs/1864223 | 11:35 |
| juliank | You need to have a Linux Firmware Updater entry in your UEFI | 11:36 |
| 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:37 |
| juliank | (and there's no interaction with other parts that was causing the regression :D) | 11:38 |
| 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:53 |
| 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:54 |
| juliank | this has been discussed before, and the summary was that the libgcc-s1 rename does not work like that | 12:56 |
| juliank | e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964477 | 12:57 |
| ubottu | Debian bug 964477 in libgcc1 "Implicit conflict between libgcc1 and libgcc-s1 prevents upgrade" [Important,Open] | 12:57 |
| juliank | which fails one level earlier | 12:58 |
| juliank | though maybe it's a different issue | 12:59 |
| xnox | related | 13:00 |
| xnox | juliank: are "solutions" in message #41 actually sane? | 13:00 |
| xnox | given that libgcc-s1 provides libgcc1 | 13:01 |
| xnox | slyon: openvswitch built fine on riscv64, retrying netplan.io build. | 13:01 |
| 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:02 |
| 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 |
| ubottu | Debian bug 964477 in libgcc1 "Implicit conflict between libgcc1 and libgcc-s1 prevents upgrade" [Important,Open] | 13:03 |
| juliank | I don't know | 13:03 |
| 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:04 |
| 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:05 |
| juliank | xnox: Doesn't help with the immediate configure issue though | 13:06 |
| doko | juliank, xnox: I'm fine with any patch that doesn't ask about the removal of essential packages ... | 13:09 |
| * juliank hates xenial | 13: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 |
| LocutusOfBorg | seb128, sure! | 13:13 |
| seb128 | LocutusOfBorg, thanks! | 13:13 |
| LocutusOfBorg | seb128, when ding poppler, please have a look at this https://bugs.debian.org/969537 | 13:14 |
| ubottu | Debian bug 969537 in elpa-pdf-tools-server "elpa-pdf-tools-server: broken when compiled against libpoppler102" [Grave,Fixed] | 13:14 |
| seb128 | LocutusOfBorg, ack, I've the merge ready for upload but I wanted the libffi transition to be through before uploading | 13:14 |
| 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:04 |
| 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:05 |
| Odd_Bloke | (s/dual-boot/dual-phase boot/) | 15:09 |
| 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:13 |
| 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:14 |
| 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:15 |
| xnox | https://github.com/systemd/systemd/pull/16371 | 15:16 |
| xnox | at the moment that is only available in groovy. | 15:16 |
| 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:20 |
| 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:21 |
| xnox | but i am sceptical that that is true, given once unit is loaded, that command would want to trigger daemon-reload too. | 15:22 |
| Odd_Bloke | xnox: You mean it would just need a change in systemd unit files, rather than a backport of systemd C code? | 15:26 |
| 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:28 |
| 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:29 |
| cpaelzer | I don't know when/if the openstack Team planned to upload the new OVS | 15:30 |
| cpaelzer | s/you'd/you've/ | 15:31 |
| xnox | "You mean it would just need a change in systemd unit files, rather than a backport of systemd C code?" => yes. | 15:37 |
| rbasak | !dmb-ping | 19:01 |
| ubottu | ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping | 19:01 |
| rafaeldtinoco | rbasak: im out today (holiday here) wont be able to make it | 19:01 |
| teward | rbasak: sorry i had no internet | 21:13 |
| 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:14 |
| xnox | but it only takes 12h in debian or so | 22:15 |
| 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:16 |
| * 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:17 |
| 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 | 22:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!