[00:37] <RAOF> mvo: Hey there! Are you aware of the autopkgtest failures blocking snapd 2.32.5 from migrating to -updates?
=== tjaalton_ is now known as tjaalton
[08:52] <cpaelzer> doko: I'd be impressed, but if there is any chance you remember why seabios carries this since vivid
[08:53] <cpaelzer> "* Build with -fgnu89-inline for GCC 5 (doko)"
[08:53] <cpaelzer> what I wonder is was that just an FTBFS (then we can drop) or soemthing else?
[10:42] <doko> cpaelzer: most likely, change of the inline sementics with c99, afaik
[10:42] <doko> or was it c11?
[10:48] <cpaelzer> doko: no c11, but ok
[10:48] <cpaelzer> I checked the build and the result LGTM
[10:48] <cpaelzer> I'll drop the delta this cycle then
[10:49] <cpaelzer> thanks for confirming that it most likely was just an FTBFS
=== alan_g_ is now known as alan_g
[12:06] <jbicha> LocutusOfBorg: does https://github.com/ubuntu/gnome-shell-extension-appindicator support libayatana-appindicator ?
[12:16] <LocutusOfBorg> jbicha, ayatana is a drop-in replacement
[12:16] <LocutusOfBorg> just need to tweak the include file and link a different library name
[12:16] <LocutusOfBorg> this is what I get with all the patches
[12:16] <LocutusOfBorg> anyway, #debian-devel and sunveawer (IIRC) will help you with a patch if you need one
[12:17] <LocutusOfBorg> but again, I'm trying to get ayatana into main
[12:17] <LocutusOfBorg> I don't care right now about what in universe still don't use it
[12:17] <jbicha> gnome-shell-extension-appindicator is in main and it's very important that it works :)
=== rsalveti is now known as rsalveti__
=== rsalveti__ is now known as rsalveti
=== lionel_ is now known as lionel
=== maclin1 is now known as maclin
[16:24] <jbicha> slangasek or anyone from TB: could you handle bug 1769694?
[16:24] <ubottu> bug 1769694 in ubuntu-community "Please update DMB members" [Undecided,New] https://launchpad.net/bugs/1769694
[16:35] <Laney> is there something special that you need to do to move from a M-A same package to an arch: all transitional?
[16:35] <Laney> https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1768541
[16:35] <ubottu> Launchpad bug 1768541 in gnome-keyring (Ubuntu) "package libp11-kit-gnome-keyring 3.20.1-1ubuntu1 failed to install/upgrade: libp11-kit-gnome-keyring:all 3.28.0.2-1ubuntu1 (Multi-Arch: no) is not co-installable with libp11-kit-gnome-keyring which has multiple installed instances" [Undecided,Confirmed]
[16:36] <Laney> I can't make it happen but evidently there is some problem here
[16:36] <Laney> not sure making it MA: foreign per my latest suggestion is right
[17:15] <infinity> Laney: You can't move from MA:same to arch:all.
[17:15] <infinity> Laney: You need to use an MA:same transitional as well.
[17:17] <infinity> Laney: arch:all by definition can only have one version/copy installed, so your transitional upgrades on the primary arch, and ends up conflicting out any other arch versions of the old package.
[17:18] <infinity> Laney: Ran into this same issue with e2fslibs when Ted tried to do what you did.  Went very poorly until I fixed it. :P
[17:43] <Laney> infinity: I didn't do it, I'm just trying to clean up the mess
[17:44] <Laney> But thanks
[17:44] <infinity> Laney: Righto.
[17:44] <infinity> Laney: I copy-and-pasted the above to the bug as well.
[17:44] <Laney> ta
[17:45] <infinity> Laney: Thankfully, the fix is trivial.
[17:45] <Laney> Yeah, looks fine.
[17:46] <Laney> I never managed to reproduce it though when installing multiple arches and dist-upgrading
[17:46] <Laney> Probably need something that depends on it on both arches, or something like that
[17:52] <Laney> hmm, this is part of the delta
[17:53] <Laney> I suppose the transitional can be dropped entirely in cosmic
[17:58] <infinity> Laney: Fix in bionic and drop in cosmic sounds lovely indeed.
[17:59] <infinity> Laney: And yes, it only explodes if something else deps on it.  Which is why it was so trivial to reproduce in e2fsprogs/e2fslibs.
[17:59] <Laney> Trying to get a reproducer.
[17:59] <Laney> Now I'm yak shaving because I have about 1 byte free and can't start a new container.
[18:02] <Laney> (big SSDs are cheap these days, yes?)
[18:03] <infinity> Cheap, ish.
[18:03] <infinity> Well, and big, ish.
[19:01] <nacc> can anyone explain to me why the 'unstable' link here is the 'stable' version per rmadison? https://ci.debian.net/packages/p/php-horde-activesync/
[19:06] <infinity> nacc: Because the last time it was tested in "unstable" was 2017-03-17
[19:06] <ginggs> nacc: i asked in #debci, but it looks to me like it stopped testing unstable in march
[19:06] <elbrus> nacc: click on the link an you see that the package hasn't been tested
[19:06] <infinity> nacc: Debian recently rejiggered how and when they run autopkgtests (moving/moved to britney triggers now), and I suspect the results pages need some love.
[19:06] <elbrus> like ginggs says
[19:06] <elbrus> that happens sometimes
[19:06] <elbrus> I don't know why yet
[19:07]  * elbrus will trigger a new one, usually debci-batch will pick it up again
[19:08] <nacc> elbrus: infinity: ginggs thanks! i have stuff i need to send to Debian that will fix most of the php* stuff for phpunit6 compt
[19:08] <nacc> but was a bit confused by that output :)
[19:09] <elbrus> nacc: next time feel free to join #debci on oftc with your questions regarding ci.d.n
[19:09]  * elbrus wasn't reading here
[19:10] <nacc> elbrus: sorry about that, will do :)
[19:10] <nacc> elbrus: was a more casual, 'does infinity know what's going on and is he listening' kind of thing :)
[19:13] <infinity> nacc: Turns out I only sort of know what's going on, elbrus is definitely more authoritative on Debian's debci instance. :)
[19:14] <nacc> infinity: heh