[06:34] <didrocks> good morning
[06:49] <duflu> Morning didrocks
[07:03] <oSoMoN> good morning desktoppers
[07:03] <oSoMoN> and happy Friday!
[07:09] <didrocks> hey duflu, oSoMoN!
[07:09] <didrocks> happy Friday to you too :)
[07:09] <duflu> Morning oSoMoN
[07:09] <duflu> Happy Aus Music T-Shirt Day
[07:10] <oSoMoN> salut didrocks
[07:10] <oSoMoN> good afternoon duflu
[08:10] <doko> oSoMoN: chromium-next and chromium-dev builds are really monopolizing the arm buildds, with build times of more than 20h
[08:14] <duflu> I hear chromium builds are a hog on any hardware :/
[08:17] <doko> well, if you *know* that, why do you schedule these daily?
[08:30] <duflu> I only heard... I've never tried one myself
[08:36] <oSoMoN> doko, I know, and I don't schedule builds daily, only when upstream issues a channel update (and arm* queues are currently empty)
[08:38] <doko> and ~ubuntu-mozilla-daily/ubuntu/ppa is needed daily too? we have loong queues on these
[08:38] <oSoMoN> I wish chromium would build faster, that would make my life easier, but the reality is chromium build times have been steadily increasing, and it doesn't look like it's going to improve
[08:38] <ricotz> doko, those firefox-trunk builds are not daily either
[08:40] <ricotz> firefox doesn't take 20h by far though
[08:40] <doko> I very much doubt that these builds are needed on every release
[08:41] <ricotz> doko, while some people insist on firefox being buildable on all those archs and upstream don't care, build testing is required
[08:42] <ricotz> especially with all those rustc updates in play
[08:43] <doko> ricotz: that's bullshit. all these packages come with their own system libs packaged, so why do you need to test on four or five releases? and why do you need to do that daily?
[08:43] <doko> same for lo
[08:48] <oSoMoN> doko, we should be considerate with build resources of course, but what's wrong with using them when the queues are empty?
[08:49] <doko> oSoMoN: did you upload armhf/arm64 only? no? then you didn't look at the amd64/i386 queues
[08:49] <doko> and I saw these builds during test rebuilds in the past as well
[08:51] <ricotz> doko, as I said, mozilla doesn't care about those archs upstream in the way ubuntu builds them, so they need to be tested in some way
[08:52] <ricotz> also those are the last firefox 58 nightly builds while the merge to beta happened today, another reason to build them
[08:52] <doko> ricotz: i some way, but not in a way thinking that you have unlimited resources
[08:53] <ricotz> doko, libreoffice is only built for tagged releases which also are needed on all arch for the archive
[08:53] <doko> ricotz: why are these tests needed on all releases at the same time?
[08:54] <oSoMoN> doko, I did see the i386/amd64 queues, my builds are in the queue, so they're not stealing resources from other builds, they're just politely waiting in line (as for the builds during the test rebuilds that's my mistake, I already acknowledged it and it won't happen again)
[08:56] <ricotz> doko, because builds break randomly, especially as said with rustc toolchain changes (staged in https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/rust-updates/+packages)
[08:56] <oSoMoN> doko, that said if I ever push chromium builds at an untimely moment, feel free to cancel them (and notify me)
[08:56] <doko> ricotz: you don't build with different rust versions on different releases, do you?
[08:57] <ricotz> doko, no, but gcc is different
[08:57] <ricotz> (which you should know best)
[08:57] <doko> ricotz: how often do you find issues with gcc once you know it builds on one release?
[08:58] <ricotz> doko, currently arm builds are failing on gcc7 based releases
[08:58] <doko> yes, I know it's not that often that it rectifies throwing firefox builds everywhere
[08:59] <ricotz> sorry, I need to go
[09:07] <willcooke> morning all
[09:08] <oSoMoN> good morning willcooke
[09:10] <didrocks> hey willcooke
[09:11] <Laney> yo
[09:12] <oSoMoN> hey Laney
[09:13] <Laney> hey oSoMoN, happy friday!
[09:14] <duflu> Morning willcooke. Yo Laney
[09:15] <seb128> good morning desktopers
[09:15] <oSoMoN> salut seb128
[09:16] <seb128> lut oSoMoN, ça va ?
[09:16] <oSoMoN> très bien, et toi?
[09:16] <duflu> Morning seb128
[09:16] <seb128> ça va bien !
[09:16] <seb128> hey duflu
[09:18] <seb128> happy friday
[09:35] <didrocks> hey Laney, seb128, happy Friday
[09:36] <jamesh> hi everyone
[09:37] <duflu> Happy Ausmusic T-shirt day jamesh
[09:37] <jamesh> duflu: I'm wearing my Spiderbait t-shirt, as it happens :)
[09:37] <seb128> lut didrocks
[09:37] <seb128> hey jamesh
[09:38] <duflu> willcooke, do we want to revert to upstream (Gnome 3-style) header bars at the same time as removing the menu bar from totem?
[09:38] <duflu> Sounds like the same exercise, but different patch
[09:38] <willcooke> duflu, yeah I think so.  It will make the U7 experience a bit less good, but the GNOME exp. better IMO
[09:39] <duflu> willcooke, Yeah exactly
[09:39] <duflu> My U7 seems broken for additional reasons. Unsure if that's also true for clean installations
[09:41] <duflu> willcooke, umm that seems to remove 5 of 9 patches :D
[10:06] <doko> ricotz: now you know that the buildds are loaded, but you upload another bunch of bullds. 12 or 16. this is disgusting
[10:06] <doko> willcooke, seb128: ^^^ is this wanted behavior?
[10:08] <seb128> doko, builds of?
[10:09] <seb128> and why are the buildds loaded and how much of a problem is it?
[10:09] <doko> seb128: but we have opened the archive?
[10:09] <doko> please count ~mozillateam/ubuntu/firefox-next yourself
[10:12] <oSoMoN> LO 5.4.2 snap now in the stable channel
[10:18] <seb128> oSoMoN, well done!
[10:19] <oSoMoN> the feedback from various users has been very useful to highlight and address a bunch of issues
[10:20] <oSoMoN> those calls for testing really work 😃
[10:20] <Laney> ♥
[10:20] <Laney> hey didrocks
[10:21] <seb128> doko, so we have a bit of build backlog, is that such an issue?
[10:21] <seb128> oSoMoN, \o/
[10:22]  * duflu fades into the sunset
[10:32] <doko> well, why would you care about uninstallability on ppc64el/s390x because the binary all packages are not yet built. desktop doesn't care about these anyway. so go on ...
[10:39] <seb128> ?
[10:39] <seb128> doko, it's the opening of a new serie, it takes some time for things to settle down, I'm sure there is work you can do meanwhile?
[10:40] <seb128> it's friday, w.e is going to help with catchup
[10:40] <seb128> doko, maybe spending friday doing SRUs or bugs triage if you are blocked for work on the new serie?
[11:29] <seb128> andyrock, hey, does gnome bug #786906 sounds like something you think you could have a look to?
[11:30] <seb128> andyrock, if you are not too busy with livepatch and other things and feel like it's something you have an idea how you could go about debugging
[11:30] <seb128> andyrock, otherwise we maybe wait for Marco to be back :-)
[11:42] <seb128> oSoMoN, next time for libreoffice, if you have several new revisions included it's better to use -vv
[11:42] <seb128> ups
[11:42] <seb128> -v<previous_version_in_ubuntu>
[11:42] <seb128> so the .changes lists the several entries
[11:42] <seb128> which might include more descriptions and lp bugs to close
[11:42] <oSoMoN> seb128, ack
[11:42] <seb128> thanks
[11:45] <seb128> oSoMoN, libreoffice uploaded btw :-)
[11:47] <oSoMoN> seb128, thanks!
[11:48] <seb128> yw!
[13:13] <ricotz> doko, if you choose this way to approach me it won't help in any way, better try to estimate the buildtime invested in various unmaintained recipes or wild rebuilds/backports of various packages than to target me pushing essential packages like firefox betas or libreoffice releases
[14:09] <roasted> Is there a road map that Ubuntu (17.10) uses/will use to identify when upgrades to things will happen? Such as something like the upgrade from Gnome 3.26.1 to 3.26.2?
[14:16] <jbicha> roasted: someone needs to prepare SRUs is all
[14:16] <jbicha> is there a particular bugfix you're interested in?
[14:17] <roasted> jbicha: yeah - I need to dig through my notes to find the exact one, but it's regarding some sort of KDE protocol for title bars/window decorations.
[14:17] <roasted> jbicha: I just upgraded my Antergos laptop which pulled in 3.26.2 and I now have functionality back in MPV that I didn't have in 3.26.1
[14:17] <roasted> (in Wayland session)
[14:19] <jbicha> oh that's already in progress: LP: #1728421 just needs people to test the -proposed update and verify things still work
[14:19] <roasted> oh. if I enable proposed I assume I can pull it in?
[14:20] <jbicha> yes, but I suggest only picking specific updates from -proposed and turn it back off again
[14:20] <jbicha> this is everything that's in proposed: https://people.canonical.com/~ubuntu-archive/pending-sru.html
[14:21] <jbicha> the red gtk bug listed there is from an older SRU
[14:22] <roasted> so if I enable proposed which package would I individually bump to test this out?
[14:24] <roasted> I ask only because with the lack of Synaptic working in Wayland, searching and fiddling around is basically non-existent nowadays (at least in the capacity I used to handle things like this)
[14:26] <seb128> jbicha, the bug should probably be untagged or marked as done otherwise it's going to confuse the SRU team
[14:27] <jbicha> yes, it's on my todo list to clean it up
[14:29] <jbicha> roasted: apt list --upgradable | grep 3.22.25-0ubuntu0.1
[14:29] <roasted> and just bump the packages that result in the output?
[14:32] <roasted> well I bumped those packages that came out of the apt list
[14:32] <roasted> rebooted but I still don't have window decorations in MPV
[14:35] <jbicha> I'm pretty sure that KDE thing won't affect GNOME Shell anyway
[14:35] <roasted> oh. I understood it would...
[14:36] <roasted> whatever 3.26.2 brought in on my other system, it surely fixed it.
[14:37] <jbicha> I'm just going off my understanding of the commit description https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=f2adaba23
[14:39] <roasted> just checked and those packages from apt list are all on 3.22.25
[14:40] <roasted> hm, oh well
[14:40] <roasted> something to look forward to with 3.26.2 me thinks
[14:42] <jbicha> ask Arch/Antergos what they did differently
[14:42] <roasted> dumb question but is that to suggest that 3.22.25 is "basically" what will be 3.26.2 in Ubuntu 17.10?
[14:43] <jbicha> that's just the gtk3 library, there are many other parts to GNOME
[14:44] <roasted> this is a link I had in my notes
[14:44] <roasted> https://bugzilla.gnome.org/show_bug.cgi?id=773629
[14:46] <roasted> eh might be the wrong one now that I read backlog of this discussion with other MPV users
[14:46] <jbicha> that bug should have been fixed with GNOME 3.24
[14:46] <roasted> they confirmed the lack of titlebars in MPV should be fixed as per the KDE protocol thing being implemented.
[14:46] <roasted> so the EGL thing in that link I just posted was something different
[14:46] <roasted> had two conversations going on at once at that time so I must have misunderstood
[14:49] <ricotz> oSoMoN, could you check for locally pending libreoffice artful/bionic commits?
[14:50] <roasted> well, if that KDE protocol was meant to be in 3.22.25 and it's not here in the same working capacity as I'm seeing on arch with 3.26.2 gnome, I'll try to do some digging and see what's different.
[14:50] <oSoMoN> ricotz, I’ve got a bionic changelog entry update pending, let me push it now
[14:52] <oSoMoN> ricotz, done
[14:54] <ricotz> oSoMoN, thanks
[15:30] <roasted> jbicha: just to confirm some confusion in my mind, with using 3.22.25 am I effectively testing what *will be* gnome 3.26.2? Or is it possible gnome 3.26.2 still has differences to these gtk 3.22.25 packages I'm messing with?
[15:31] <jbicha> they are two separate things
[15:31] <roasted> just trying to understand the versioning differences with 3.22.25 in proposed versus 3.26.2 in its final state
[15:31] <jbicha> gtk3 is just one part of what GNOME is
[15:31] <roasted> so it stands to reason that these 3.22.25 packages I'm messing with won't do anything, and come the day 3.26.2 comes to Ubuntu I may still see success with window deco on these apps (MPV, etc)?
[15:31] <jbicha> roasted: this is GNOME 3.26.2: https://www.0d.be/debian/debian-gnome-3.26-status.html
[15:32] <jbicha> you'd also want to check mutter and gnome-shell but I didn't see anything in their git commit logs that sounded relevant to this
[15:33] <roasted> is there any timeline for 3.26.2 coming?
[15:33] <jbicha> roasted: you need to be more specific about what part of 3.26.2 you want
[15:34] <roasted> shell? I suppose?
[15:34] <roasted> I mean we're on 3.26.1 right now...
[15:34] <jbicha> I'm working on mutter 3.26.2, uploading to artful unapproved next week, so it might be in proposed by the end of next week
[15:34] <jbicha> no one is working on gnome-shell 3.26.2 yet
[15:35] <roasted> I would assume window decorations are more mutter-specific than gnome-shell-specific
[15:36] <roasted> mutter on Ubuntu is 3.26.1 while Antergos is 3.26.2, so perhaps that's it?
[15:56] <roasted> I'll have to keep an eye out for your mutter 3.26.2 update to proposed jbicha. I'll be sure to test it out once I can and see if that helps MPV (and other associated apps). Thanks for your insight.
[17:01] <whlai> Filesystem      Size  Used Avail Use% Mounted on
[17:02] <whlai> test
[17:03] <whlai> I have: /dev/sdb1  917G  870G 0 100% /home/robco/nextcloud-mount
[17:03] <whlai> Should have 40G available
[17:03] <whlai> Don't understand what's up here
[17:07] <whlai> why so quite?
[17:07] <oSoMoN> EOW here, have a great week-end everyone!
[17:08] <flocculant> whlai: this isn't a support channel - try #ubuntu, but that looks about right if 5% of space reserved as is default
[17:09] <whlai> thanks
[18:59]  * kenvandine has fully confined snaps for gnome-contacts and gnome-calendar now... using the new goa interface from jamesh and my new interfaces for contacts and calendar
[18:59] <kenvandine> woot
[19:00] <roasted> snap all the things
[19:01] <kenvandine> :)
[23:13] <roasted> jbicha: I rolled back every package I recently updated on my Antergos system and could not replicate the issue I A) once saw on Antergos and B) currently see on Ubuntu 17.10 regarding window decorations. I was hoping to find it and dig deeper for sake of what's about to go into proposed, but I'm not sure how else to test. Might just have to cross fingers with Mutter 3.26.2 and hope that was it (even tho rolling it back on my other system
[23:13] <roasted> didn't reintroduce the issue)
[23:27] <jbicha> roasted: what if Arch's mpv package itself changed?
[23:42] <roasted> jbicha: it's possible, though mpv is (for whatever it's worth) at v0.27 on both systems. The maintainer of the PPA for MPV made it sound like he was familiar with the issue and it was Gnome-specific.