[01:29] <duflu> xnox: (sorry I forgot to close IRC last night) Yes and no. I would like to drop as many patches as possible but other people told me those patches were still needed (for snappy). Sorry I don't remember more
[07:20] <oSoMoN> good morning desktoppers
[07:24] <didrocks> good morning
[07:26] <oSoMoN> salut didrocks
[07:29] <didrocks> salut oSoMoN
[07:47] <xnox> duflu, ack.
[07:47] <duflu> xnox, also please commit any changes to git first (I'm assuming you have permission): https://git.launchpad.net/~ubuntu-audio-dev/pulseaudio
[07:48] <doko> oSoMoN: lo needs a no-change rebuild for new liborcus. or do you want to upload a new version?
[07:48] <duflu> Indirectly.
[07:49] <duflu> Morning oSoMoN, didrocks
[07:50] <xnox> duflu, well, i do not care much about pulseaudio, i do care about whether or not trust-store is here to stay; and if it is here to stay, who will maintain it, as it FTBFS with new boost.
[07:50] <xnox> and trust-store has not had a release since 16.04.
[07:51] <duflu> xnox, fair enough. Yeah   \_(".)_/
[08:20] <didrocks> hey duflu, xnox!
[08:25] <andyrock> hey all!
[08:28] <didrocks> hey hey andyrock
[08:30] <duflu> Hey andyrock
[08:34] <willcooke> morning all
[08:38] <didrocks> morning willcooke
[08:40] <oSoMoN> doko, I'll be preparing a new version today, up to you if you want to upload a no-change rebuild in the meantime
[08:40] <oSoMoN> good morning duflu, andyrock, willcooke
[08:43] <didrocks> davidcalle: hey, I would like to have one or two tests in tutorial-deployment with the additional "Image" field (which is ommitted when empty, that's why the tests are still passing as expected) and so that we have some in the apis file as well. Do you want me to deal with it or you want to handle it?
[08:44] <doko> oSoMoN: no, waiting
[08:44] <davidcalle> didrocks: let me have a look :)
[08:44] <didrocks> davidcalle: tell me if you need any help, you will need to add the tests in two places: codelabs/ and apis/
[08:45] <didrocks> ./runtests to run all the tests! ofc ;)
[09:04] <Laney> sup
[09:04] <Laney> something weird is going on with my wired network, going to have to go look, brb!
[09:06] <willcooke> hi Laney, bye Laney
[09:11] <didrocks> see you soon Laney ;)
[09:20] <doko> is anyone from desktop at fosdem?
[09:24] <didrocks> seb, laney, marco, ken and I
[09:28] <seb128> good morning desktopers!
[09:32] <Laney>   hey seb128
[09:32] <Laney> how's it going?
[09:32] <Laney>             why all the sapces
[09:32] <willcooke>     morning seb128
[09:33] <seb128>      hey      hey      hey       willcooke     &   Laney
[09:33] <didrocks> re seb128
[10:05] <seb128> xnox, duflu, trust-store is not something needed but somebody needs to rewrite the pulseaudio/snappy patches in a way that drops that depends (the depends is not needed but the same patch adds apis that the snappy patch needs)
[10:06] <seb128> doko, didrocks, the list from didier + olivier at fosdem
[10:06] <didrocks> oh, sorry olivier ;)
[10:07] <seb128> :)
[10:07] <doko> are you at the beer event tomorrow?
[10:08] <xnox> seb128, ah, so there are things in snapd that call into things in pulseaudio which are mixed in with trust-store patches.... transitively. but it should be possible to keep APIs in pulseaudio, which are in use by snapd, without trust-store?!
[10:08]  * xnox hopes i got all of that right
[10:08] <seb128> xnox, that's my understanding of the situation
[10:08] <xnox> ack
[10:09] <xnox> seb128, if i poke more of this, might sync up in brussels about it.
[10:11] <czajkowski> aloha
[10:14] <seb128> xnox, I fwded you an email on the topic
[10:15] <seb128> xnox, https://git.launchpad.net/~ubuntu-audio-dev/pulseaudio/tree/debian/patches/0409-Trust-store-patch.patch?h=ubuntu and https://git.launchpad.net/~ubuntu-audio-dev/pulseaudio/tree/debian/patches/0700-modules-add-snappy-policy-module.patch?h=ubuntu
[10:16] <seb128> xnox, the snappy patch uses client->creds.pid for example which is added by the trust store patch
[10:32] <seb128> willcooke, https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/9#note_48971 might be interesting to you ... was the requirement to rotate them or to let the user cycle using arrows or such?
[10:35] <willcooke> seb128, unclear.  Spoke to Ev and he said that they only wanted the top three rotating, but that will likely change to be 5 and then 7 and then...
[10:36] <willcooke> but still not clear on *how* to rotate them, I'll look at that MR
[10:36] <seb128> willcooke, the number is orthogonal to "how"
[10:36] <seb128> right
[10:36] <seb128> thanks
[10:36] <willcooke> oh
[10:36] <willcooke> it's from Robert :)
[10:36] <seb128> right
[10:36] <seb128> see Alan's feedback
[10:37] <willcooke> right, yeah
[10:37]  * willcooke starts another thread.  I think that if the user had controls that would work, so that they could go backwards and forwards, but let's run it past mpt 
[10:38] <duflu> seb128, morning. Sorry am deep in mutter
[10:38] <duflu> And should have logged off a while ago
[10:39] <seb128> duflu, hey, no worry,g ood luck with that, and yeah you should enjoy your evening!
[10:39] <seb128> willcooke, thx
[10:39] <duflu> Random question: how do core files become crash files?
[10:39] <duflu> I just noticed that if Xwayland and gnome-shell crash at roughly the same time then you could be left with the core of one but not the other
[10:40] <duflu> ... which is potential explanation for why we can't figure out the gnome-shell #1 crasher
[10:40] <seb128> duflu, /proc/sys/kernel/core_pattern
[10:40] <seb128> that's set to apport
[10:40] <seb128> duflu, https://wiki.ubuntu.com/Apport#Crash_interception
[10:41] <duflu> seb128, interesting then... so why do I get the core files?
[10:41] <duflu> As someone else reported today
[10:41] <duflu> The core_pattern is set, but they're staying "core" files
[10:41] <duflu> Maybe it's racey?
[10:41] <seb128> good question, that I don't know
[10:41] <seb128> could be
[10:43]  * duflu adds another card to his literal desktop
[10:52] <willcooke> ooh, spam on the hub
[10:52] <willcooke> night duflu
[10:52] <duflu> Not yet
[10:52] <duflu> Which has double meaning. It's summer so the sun isn't down quite yet
[10:53] <willcooke> also in too deep to give up?
[11:01] <didrocks> davidcalle: thanks for the additional tests! Just released by tagging v1.3 (https://github.com/Ubuntu/tutorial-deployment/releases) and binaries were generated. Tell me if the shell caching scripts upgraded to latest, but we should all be fine.
[11:01] <didrocks> davidcalle: I suggest you update the example in https://github.com/canonical-websites/tutorials.ubuntu.com/blob/master/examples/example-tutorial.md as well
[11:01] <didrocks> so that people scaffolding from it have the image property
[11:01] <didrocks> but you don't really need me for this, nice work! :)
[11:02] <davidcalle> didrocks: generate is updating :)
[11:02] <didrocks> nice! :)
[11:03] <davidcalle> didrocks: thanks for the guidance and coping with my lack of go fu ;-)
[11:03] <didrocks> no worry! ;) happy that you got it easily
[11:08] <doko> chrisccoulson (and desktop): what's the story about firefox, thunderbird and rustc? firefox ftbfs on ppc64el, rustc on s390x. however I never the requests for package removals. that means that we don't have any recent versions in the development release until packages are shoved in via security updates
[11:09] <duflu> willcooke, ha. I beat sunset by 11 minutes
[11:09] <duflu> Night
[11:56] <jbicha> doko: firefox hasn't built on s390x for a long time and it's not a blocker for migration
[11:57] <jbicha> Firefox 56 didn't build on ppc64el but 57 did..
[11:59] <seb128> jbicha, hey
[11:59] <seb128> jbicha, did you get a reply from chrisccoulson about uploaded the current version to bionic?
[12:04] <doko> jbicha: yes, firefox on s390x is currently a non-issue. rustc not building on s390x is an issue
[12:31] <jbicha> seb128: firefox and thunderbird are now in bionic-proposed so I guess that counts as a reply ;)
[12:35] <xnox> doko, well, at this point s390x one clearly will need a fresh rebootstrap, thus it is best to RM rustc/s390x from bionic-release
[12:35] <xnox> doko, and let the rest of them migrate.
[12:36] <jbicha> didrocks: I replied to LP: #1709164 is it helpful for me to ping on IRC or are you subscribed to the MIR bugs?
[12:36] <ubot5> Launchpad bug 1709164 in bubblewrap (Ubuntu) "[MIR] bubblewrap" [Undecided,Confirmed] https://launchpad.net/bugs/1709164
[12:38] <xnox> rustc 1.20 did build
[12:42] <didrocks> jbicha: better to ping on IRC
[16:00] <ricotz> oSoMoN, hi
[16:02] <ricotz> I think you mentioned the libreoffice/kernel/java issue on i386 lately, afaik the current openjdk-9 package in bionic is suppose to fix that
[16:14] <oSoMoN> hey ricotz
[16:15] <oSoMoN> that's what I remember reading too, but when running autopkgtests with openjdk-9, LO couldn't locate the JVM
[16:15] <oSoMoN> I didn't take the time to investigate further, tbh
[16:16] <oSoMoN> openjdk-8 is still the default JDK, and it's in main (whereas 9 is in universe)
[16:17] <oSoMoN> ricotz, FYI I'm preparing the 5.4.4 SRU to artful (bug #1746757)
[16:17] <ubot5> bug 1746757 in libreoffice (Ubuntu) "[SRU] libreoffice 5.4.4 for artful" [Undecided,New] https://launchpad.net/bugs/1746757
[16:24] <ricotz> oSoMoN, I see, I assume you didn't pick up the java9 fixes, ignoring those failures is the way to go anyhow
[16:24] <ricotz> oSoMoN, please ignore the ppa spam ;)
[16:25] <oSoMoN> ricotz, from what I could tell the java9 fixes made their way upstream and were dropped, no?
[16:29] <ricotz> oSoMoN, hmm, if so I guess I missed that
[17:54] <ricotz> oSoMoN, better refer to https://launchpad.net/~libreoffice/+archive/ubuntu/ppa as a test for SRUs
[18:05] <Laney> righto, see some of you tomorrow
[18:05] <Laney> probably won't be on IRC very much
[18:08] <seb128> Laney, have a good trip, see you tomorrow evening ... at what time do you arrive?
[18:10] <Laney> seb128: early afternoon, about 14:00
[18:11] <seb128> oh ok, I'm probably going to arrive around dinner time so I catch you guys somewhere to eat or otherwise for the evening drinks
[18:13] <Laney> ok, safe travels!
[18:15] <seb128> you too!
[18:17] <seb128> oSoMoN, did you see the comment about chromium snap on https://forum.snapcraft.io/t/snaps-officially-supported-by-canonical/1719/3 ?
[18:18] <seb128> it feels like we are usually keeping that snap updated without too much delay and it's not really fair to pick on it
=== user8394 is now known as user8393
[18:45] <kenvandine> seb128, oSoMoN maintain that's really because the version in the stable channel lags?
[18:46] <seb128> does it lag?
[18:46] <kenvandine> not sure
[18:46] <kenvandine> 64 is in stable and 65 in the other channels
[18:46] <seb128> the minor versions are behind it seems
[18:47] <seb128> but like by a week
[18:47] <seb128> well at least looking at https://chromereleases.googleblog.com/ ... it's not obvious to see what versions are current
[18:49] <oSoMoN> seb128, as a matter of fact I promoted the latest stable release to the stable channel today, it had been in the candidate channel for 6 days
[18:50] <oSoMoN> so picking on the chromium snap today was bad timing :)
[18:50] <kenvandine> oSoMoN, ah, can you comment to that effect in the forum?
[18:50] <oSoMoN> yes, doing that now
[18:50] <seb128> oSoMoN, can you reply that on the forum?
[18:52] <kenvandine> chromium is one of our best maintained snaps!
[18:57] <oSoMoN> done
[18:57] <kenvandine> oSoMoN, thx!
[19:02] <oSoMoN> ricotz, thanks, I updated the description to point to the fresh PPA
[19:04] <willcooke> night all, safe travels to those travelling
[19:13] <GunnarHj> jbicha: Thanks for syncing ibus-libpinyin!