[07:12] <oSoMoN> good morning desktoppers
[07:20] <duflu> Morning oSoMoN
[07:23] <oSoMoN> hey duflu
[07:39] <didrocks> good morning
[07:47] <tjaalton> duflu: should i965-va-driver be installed by default in bionic?
[07:47] <duflu> tjaalton, yes it's required...
[07:47] <tjaalton> well it's not here
[07:48] <tjaalton> just installed bionic the other day
[07:48] <duflu> tjaalton, but it comes from ubuntu-restricted-addons
[07:48] <tjaalton> ah
[07:48] <duflu> So many installs might be missing it initially
[07:48] <duflu> tjaalton, I was about to attempt bisecting Mesa... unless you're more practiced at at
[07:48] <duflu> at it
[07:49] <tjaalton> would be better to test 18.0.0-rc1 first
[07:49] <duflu> tjaalton, sounds optimistic :)
[07:49] <tjaalton> we'll get rcN in a week or two
[07:49] <tjaalton> in bionic
[07:50] <tjaalton> is that corruption bug hw specific?
[07:50] <tjaalton> seems fine on kbl
[07:51] <tjaalton> though the video clip probably matters too..
[07:53] <tjaalton> yeah
[07:54] <tjaalton> reproduced the bug now
[07:54] <tjaalton> all I see is some static
[07:55] <duflu> I fear we might end up blaming clutter-gst-3.0 for "always having done it wrong". But at least bisecting where the problem started in Mesa will be useful
[07:57] <tjaalton> I have 18.0.0-rc2 on a ppa but it's built against libglvnd, so I'll test that combo first
[07:58] <tjaalton> broken
[07:59] <tjaalton> now this machine is tainted, going back is painful :)
[07:59] <tjaalton> so I'll grab another one
[08:10] <duflu> tjaalton, OK I've got my Mesa bisection groove on
[08:10] <duflu> Give me a while
[08:47] <willcooke> morning gang
[08:58] <duflu> Morning willcooke
[08:59] <duflu> tjaalton, bisection complete. See the upstream bug. Looks very easy to revert
[08:59] <didrocks> morning willcooke
[08:59] <tjaalton> getting mesa through -proposed is anything bug
[08:59] <tjaalton> but
[09:00] <duflu> Yeah fair enough
[09:00] <duflu> And morning didrocks
[09:00] <didrocks> hey duflu
[09:00] <tjaalton> I'll see that it's fixed in 18, once we roll out glvnd
[09:04]  * oSoMoN does the little ifinallymanagedtobuildalibreoffice6snap dance
[09:06] <oSoMoN> on to testing it actually works
[09:06] <duflu> tjaalton, would it be correct to assume a single patch update is too much trouble?
[09:06] <tjaalton> duflu: it's the racy/broken autopkgtests that need hand-holding
[09:07] <duflu> tjaalton, OK. No problem... I'll leave it with you and upstream
[09:07] <tjaalton> I'll push 18.0.0-rc3 to proposed early next week
[09:11] <seb128> good morning desktopers
[09:11] <willcooke> hey seb128
[09:11] <seb128> hey willcooke, how are things in the u.k today?
[09:11] <willcooke> bit chilly, little bit of snow, but the sun is coming out
[09:12] <willcooke> andyrock, bug #1637984 - verification done on artful and xenial
[09:12] <willcooke> thanks for fixing it!
[09:12] <duflu> Morning seb128
[09:13] <seb128> hey duflu
[09:13] <seb128> willcooke, thanks for testing the SRU :)
[09:13] <seb128> and yeah, good work andyrock
[09:13] <duflu> seb128, the totem bug has been bisected in Mesa. Looks easy and justifiable to undo
[09:13] <seb128> way to get things done properly, he worked through several iterations with upstream until they were happy, fixing tests issues not related to his changes on the way
[09:17] <duflu> willcooke, remind me - did we have any conversation that might have touched on this? https://trello.com/c/ptr7qnhJ
[09:18] <willcooke> duflu, we kinda did.  It needed doing but no one had time to work on it so it got pushed to the bottom of the heap
[09:18] <willcooke> oh
[09:18] <seb128> duflu, good, that makes more sense than being totem itself
[09:18] <duflu> willcooke, OK. Was there a card/bug for it before today?
[09:18] <willcooke> right, was just going to say, I think I misread it
[09:18] <seb128> duflu, willcooke, https://trello.com/c/9GI3EFh2/122-bug1686081-if-synaptics-is-installed-gnome-mouse-touchpad-settings-doesnt-work
[09:18] <willcooke> There was one about U7 needing fixes
[09:19] <willcooke> thanks seb128
[09:19] <seb128> np
[09:19] <duflu> seb128, wouldn't that entail more work? We could resolve the main issue by automatically removing synaptics on upgrade
[09:20] <oSoMoN> good morning seb128
[09:20] <seb128> lut oSoMoN
[09:20] <seb128> duflu, doing what is more work?
[09:21] <duflu> seb128, making gnome-control-centre support synaptics would be extra unnecessary work, compared to just removing the synaptics package as part of the upgrade process
[09:21] <seb128> duflu, did anyone suggest doing that?
[09:22] <duflu> seb128, yes that's the problem discovered in today's bug. The whole panel doesn't work because he upgraded from an older series where synaptics was installed
[09:22] <seb128> duflu, the suggested fix was to make unity-control-center work with libinput so synaptic can be made to be forced removed without creating issues if you have GNOME & Unity both installed
[09:23] <duflu> So upgraders don't get the control panel
[09:23] <seb128> duflu, that's https://trello.com/c/X7gznOHG/132-libinput-support-for-unity-7
[09:23] <duflu> seb128, OK so that's a completely different issue
[09:23] <seb128> well, it's the same
[09:23] <seb128> we need to remove synaptic
[09:23] <seb128> but doing that creates issues for unity
[09:23] <didrocks> duflu: you still have unity (and such unity-control-center) installed on upgrade
[09:23] <seb128> which is why we couldn't do it
[09:23] <didrocks> so*
[09:24] <duflu> didrocks, Ah yes. OK
[09:27] <seb128> I think we are going to need to force remove it and the unity guys are going to need to fix it
[09:27] <seb128> duflu, I think you wanted to keep the option to let users install synaptic instead of libinput though ... does it still stand with the recent improvements?
[09:28] <didrocks> seb128: +1, maybe post that on the community hub on their unity topic as a head's up?
[09:29] <seb128> didrocks, yeah, I was thinking the same, I'm going to do that now
[09:34] <duflu> seb128, the reasons for reverting from libinput to synaptics are *mostly* gone. Not completely
[09:36] <duflu> It might also be easy to copy 'synclient' code into a patch against gnome-control-centre.
[09:36] <seb128> upstream is not going to want that so it would be a distro patch
[09:36] <seb128> and doesn't seem a good use of our resources to maintain that
[09:37] <seb128> we pretty much have agreement than libinput is the way to go so we should better focus on making that good enough
[09:39] <duflu> seb128, I think the argument against doing Unity work on it is at least as strong. Unity7 is legacy _and_ at least Unity7 users have a command line tool (synclient). If they really prefer Unity7 strongly and don't switch often then just reinstall synaptics
[09:41] <seb128> right, we (as our team) don't plan to do that work
[09:41] <seb128> the community people who picked up unity might though
[09:41] <seb128> up to them
[09:43] <duflu> seb128, what we could upstream is a change to gnome-control-centre to detect if libinput is not in use... maybe. And add a message to the control panel
[09:44] <duflu> Although presently it only talks gsettings or whatever. So looking for a real backend might be going too far
[09:44] <seb128> that would be useful
[09:45] <seb128> but if we remove synaptic on updates it shouldn't be a common situation
[09:45] <duflu> Although it does conditionally show/hide touchpad settings already. There is some detection there
[09:46] <seb128> right
[09:46] <duflu> seb128, yeah removing it on upgrade would probably create the fewest bug reports
[09:46] <seb128> I'm unsure if we should conflict to avoid people installing it and then getting their g-c-c that stops working
[09:46]  * duflu is assuming more people don't complain about libinput's performance
[09:47] <seb128> but at the same time we know by experience that if we do that some people are going to copy an "apt install ...synaptic" line from the internet
[09:47] <seb128> not read the apt text
[09:47] <seb128> and say yes to uninstall GNOME
[09:47] <seb128> or g-c-c
[09:47] <seb128> and then not understand why they GNOME session went away
[09:47] <didrocks> hum, good point…
[09:47] <duflu> seb128, conflicts result in questions during upgrade right? (I forget, it's been so long)
[09:48] <didrocks> should we just do that via do-release-upgrade thus?
[09:48] <seb128> didrocks, that would be my preference
[09:48] <didrocks> sounds good to me
[09:48] <seb128> not ideal because then some people might install it for unity or because they read on a forum it solves their libinput issue
[09:48] <seb128> and then have g-c-c to bug
[09:48] <didrocks> yeah…
[09:48] <duflu> seb128, wouldn't conflicting packages then prevent people from having both installed later?
[09:48] <seb128> maybe we should add a warning to the panel saying so
[09:49] <didrocks> seb128: I guess that worthes it, shouldn't be complex
[09:49]  * seb128 adds to trello
[09:49] <didrocks> I'm happy to deal with that later on (just testing a file on disk)
[09:49] <andyrock> seb128 willcooke thanks!
[09:49] <didrocks> can be a bug fix anyway
[09:49] <seb128> didrocks, thx
[09:49] <seb128> good morning andyrock :) how are you doing today?
[09:49] <andyrock> and good morning all!
[09:52] <andyrock> seb128 fine fine
[09:52] <andyrock> I'm planning to ask upstream if they are willing to accept an Ubuntu sso goa provider
[09:53] <seb128> nice
[09:57] <seb128> didrocks, duflu, the other way that would be robust would be to have the conflict and delete synaptic from the archive so it's not an apt away, but I don't know if some users still need synaptic for valid reason and if that's unnice to the unity people
[09:58] <duflu> seb128, certainly it's very useful. And the only input stack that is easily configurable on the command line.
[09:58] <duflu> libinput isn't there yet
[09:58] <didrocks> seb128: yeah, also others DE might require synaptic as well?
[09:59] <seb128> didrocks, I think tjaalton said unity was the only remaining one
[09:59] <tjaalton> only unity is unable to configure libinput
[09:59] <didrocks> oh, interesting
[09:59] <didrocks> well, maybe try to convince the community unity people doing this work and remove from the archive :)
[10:00] <tjaalton> good luck with that :)
[10:01] <didrocks> well, they decided to take the maintenance over, so, this isn't a free "there is nothing to do, easy" :p
[10:02] <tjaalton> yeah, but after trying to make it happen for ~2y(?) while unity was the thing and it didn't, now there's maybe a month or two to make the same :)
[10:02]  * duflu switches to chef mode
[10:02] <duflu> Later
[10:02] <tjaalton> of course can just drop the driver and say "live with it, or adapt"
[10:03] <didrocks> duflu: enjoy cooking :)
[10:03] <seb128> duflu, enjoy your evening!
[10:03] <seb128> tjaalton, right, that's what I was wondering but duflu believes it's still useful to have and cover cases that libinput doesn't
[10:06] <tjaalton> right, it's not much of a maintenance burden
[10:08] <seb128> https://trello.com/c/ptr7qnhJ/211-bug1733032-touchpad-settings-dont-work-after-upgrading-to-1710-because-xserver-xorg-input-synaptics-is-still-installed updated for those interested
[10:08] <seb128> it has a summary of what was discussed here
[10:09] <tjaalton> I have a desktop that I just upgraded to bionic where it doesn't have any settings for the mouse :)
[10:09] <tjaalton> which is weird
[10:09] <seb128> right, we need to solve that
[10:09] <tjaalton> well, just for the left/right button, but no speed adjust
[10:09] <seb128> is that because synaptic is still installed after upgrade?
[10:10] <seb128> or another issue?
[10:10] <tjaalton> something else
[10:10] <seb128> :/
[10:10] <tjaalton> synaptics isn't installed
[10:10] <seb128> it probably doesn't detect your touchapd as one
[10:10] <seb128> like it thinks it's a mouse or something
[10:10] <tjaalton> a fresh install on a laptop has it right
[10:10] <seb128> we had a few such reports in the past
[10:10] <tjaalton> it's a desktop
[10:10] <seb128> oh
[10:11] <tjaalton> the keyboard has a nipple mouse
[10:11] <seb128> same, maybe it doesn't detect the right device
[10:11] <tjaalton> could be
[10:11] <seb128> feel free to open a bug
[10:11] <seb128> maybe upstream as well if you can
[10:11] <tjaalton> against?
[10:11] <seb128> gnome-control-center
[10:11] <tjaalton> ok
[10:11] <seb128> thx
[10:11] <seb128> k, I need to step out for a bit, some errands and early lunch
[10:11] <seb128> bbl
[10:12] <GunnarHj> Hi seb128! As a result of the util-linux upload, autopkgtest for open-iscsi failed (time out) for amd64. Maybe restart that test again?
[10:12] <didrocks> see you later seb128
[10:12] <GunnarHj> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#util-linux
[10:15] <seb128> GunnarHj, done
[10:15] <seb128> thx for keeping an eye on those
[10:15] <GunnarHj> seb128: N.p. I was the noise maker. :)
[10:22] <tjaalton> filed bug 1748152
[10:22] <tjaalton> hm, changed the headline
[10:27] <oSoMoN> chrisccoulson, is publishing chromium-browser 64.0.3282.140 from the stage PPA on your list?
[10:28] <chrisccoulson> oSoMoN, it can be added to my list with a bribe
[10:28] <chrisccoulson> (j/k) ;)
[10:57] <andyrock> seb128: upstream agreed to have an UbuntuSSO provider in goa (a provider talking with snapd and not with the online server)
[10:57] <andyrock> we need to maintain it of course
[11:51] <andyrock> seb128: we might need an UbuntuOne icon for goa
[11:52] <andyrock> should I ask the community to create one?
[11:58] <willcooke> andyrock, I think we already have one
[11:58] <willcooke> well, not for goa
[11:58] <willcooke> Robert uses it in G-Software
[11:58] <andyrock> not sure that's going to be ok
[11:59] <andyrock> we need a squared one
[11:59] <willcooke> ah right
[11:59] <andyrock> http://www.softicons.com/social-media-icons/alike-icons-by-bokehlicia/ubuntu-one-icon
[11:59] <andyrock> something like this
[11:59] <andyrock> but with the proper licence
[11:59] <andyrock> *license
[12:03] <willcooke> andyrock, can we just cut the u1 part from the logo and use that?  What size does it need to be?
[12:04] <andyrock> 96x96
[12:05] <andyrock> they I can rescale them to all the other needed sizes
[12:05] <andyrock> having a pure squared one will feel more gnome-ish
[12:05] <willcooke> andyrock, oki, lemme see what I can do.  Asking in #design for a high res icon that I can trim
[12:06] <andyrock> willcooke: https://www.howtogeek.com/wp-content/uploads/2017/01/ximg_588a65fed1ffc.png.pagespeed.gp+jp+jw+pj+js+rj+rp+rw+ri+cp+md.ic.pht2CIym-v.png
[12:07] <andyrock> something that looks like these icons
[12:13] <willcooke> andyrock, do they add the border automatically?
[12:13] <andyrock> nope
[12:14] <willcooke> kk
[12:27] <willcooke> andyrock, dont suppose you've found any design guidelines for those icons?
[12:28] <willcooke> I've made something that looks "ok"
[12:28] <andyrock> nice :D
[12:28] <andyrock> well I didn't had time
[12:28] <andyrock> I had to "ok to go" from upstream today
[12:29] <andyrock> if we don't upstream this we can't use goa
[12:29] <andyrock> not easily at least
[12:30] <seb128> andyrock, good news!
[12:30] <seb128> andyrock, where did you discuss that? IRC? bug?
[12:31] <andyrock> seb128: I discuessed with rishi privately
[12:31] <seb128> k, cool
[12:33] <willcooke> andyrock, https://imgur.com/a/Rgyx9  (it's a screenshot because otherwise you cant see the drop shadow properly) - WDYT?  (cc seb128_)
[12:33] <andyrock> kk for me
[12:33] <andyrock> thanks
[12:34] <seb128> willcooke, looks good to my non-designer eyes
[12:34] <willcooke> :) "that'll do"
[12:34] <willcooke> wfm
[12:34] <seb128> :-)
[12:34] <willcooke> :)
[12:34] <andyrock> seb128: willcooke https://pastebin.canonical.com/209555/
[12:34] <willcooke> oki, andyrock I will send you the xcf so you can fiddle if you like
[12:36] <seb128> andyrock, thx
[12:36] <andyrock> i'm preparing a ppa with the patched goa
[12:36] <willcooke> hmm, it might need more of a border, hold on
[12:36] <andyrock> I'm just having some troubles with quilt and images
[12:37] <jbicha> andyrock: btw, Canonical pastebin isn't public
[12:37] <jbicha> oh maybe that was intentionally private anyway
[12:37] <andyrock> jbicha: i didn't feel confident sharing a private conversation with asking rishi
[12:37] <andyrock> :D
[12:37] <andyrock> *without
[12:37] <jbicha> ok, that's fine :)
[12:38] <andyrock> if you're interested I can send you the logs
[12:39] <jbicha> no need, I'm not closely following GOA stuff :)
[12:39] <andyrock> kk
[12:39] <andyrock> seb128: with quilt I'm getting this for images
[12:39] <jbicha> sorry about the noise
[12:39] <andyrock> https://www.irccloud.com/pastebin/qoTmVu04/
[12:40] <seb128> andyrock, you can't include binaries in a diff ... how did you include those?
[12:40] <jbicha> it might be possible with git
[12:41] <andyrock> ah so I don't include them in the quilt patch but just in the debdiff
[12:41] <seb128> no
[12:41] <andyrock> hmmm
[12:41] <seb128> andyrock, what is in debian/source/format?
[12:42] <seb128> is that a 3.0 (quilt)?
[12:42] <jbicha> like on Tuesday, I experimented with cherry-picking this patch using git-buildpackage and it seemed to work. I had to add the patch filename to debian/source/include-binaries though
[12:42] <andyrock> 3.0 (quilt)
[12:42] <jbicha> https://git.gnome.org/browse/swell-foop/commit/?id=17791c375
[12:42] <seb128> andyrock, right, then you can add the image to debian/
[12:42] <seb128> and list it in debian/source/include-binaries
[12:42] <jbicha> and conveniently enough, Ubuntu 18.04's GOA is synced with Debian which does use git…
[12:42] <seb128> like you add a line "debian/icon.png" to that file
[12:43] <andyrock> jbicha: yeah I'm using salsa for this
[12:43] <jbicha> andyrock: is this only for 18.04?
[12:43] <andyrock> jbicha: yep
[12:44] <andyrock> so I switch to the 3.26.2-2 branch
[12:45] <andyrock> then "gbp pq  import"
[12:45] <andyrock> then cherry-picks
[12:45] <andyrock> then "gbp pq export"
[12:45] <andyrock> but I can some noise with binaries
[12:45] <andyrock> I'll try with debian/source/include-binaries
[12:46] <jbicha> what's the exact error you got?
[12:46] <andyrock> no error just weird chars in the quilt patch
[12:47] <andyrock> I cannot even pastebin them
[12:47] <jbicha> yes, it will look funny because it's a binary diff, but I think if you add the patch filename to debian/source/include-binaries it will work
[13:01] <willcooke> giiiiiiiiiiiiiiiiiiiiiiiiiiiiiimp
[13:01] <willcooke> why are you so hard to us
[13:01] <willcooke> e
[13:05] <seb128> would be nice to have a simple "paint"
[13:17] <seb128> GunnarHj, util-linux retry worked, it migrated
[13:17] <GunnarHj> seb128: Great!
[13:18] <GunnarHj> seb128: I've played with pkgbinarymangler. If we skip the md5sums verifications in test/run for now, it builds on bionic. Would that be an acceptable workaround for now?
[13:19] <seb128> GunnarHj, it would be better to fix it, that's on my list for today
[13:20] <GunnarHj> seb128: Absolutely. I have a patch ready if you give up. ;)
[13:27] <seb128> GunnarHj, can you share it in any case so I see how you worked around it?
[13:28] <GunnarHj> seb128: Sure, then I'll submit it on the bug report.
[13:29] <seb128> thanks
[13:33] <GunnarHj> seb128: https://bugs.launchpad.net/ubuntu/+source/pkgbinarymangler/+bug/1688994/comments/10
[13:42] <andyrock> jbicha: for debian/source/include-binaries to work, the new icons have to be in debian/* ?
[13:44] <jbicha> no, the patch itself is a "binary", so just add the patch file name (debian/patches/0001_make-it-more-awesome.patch) to debian/source/include-binaries
[13:46] <andyrock> ahh
[13:46] <andyrock> thanks
[14:21] <willcooke> you know how it's super-click instead of alt-click to drag a window around by the middle, is that a Wayland thing or a gnome-shell thing?
[14:22] <jbicha> willcooke: it's a GNOME default. You can change it back to Alt in GNOME Tweaks > Windows > Window Action Key
[14:24] <willcooke> thanks jbicha
[14:25] <willcooke> I saw talk of it the other day in here, did we decide to change it to alt-click?
[14:25] <willcooke> Cos I /think/ we should.  It's been that way for ever, and I only discovered it because I read it in here
[14:26] <mvo> hm, since my upgrade to bionic my mouse is unbearable fast. is there something to tweak this?
[14:27] <jbicha> willcooke: but why are you familiar with it? is it more important to maintain compatibility with how things used to work in GNOME 2 or do things more logically for now?
[14:28] <seb128> willcooke, is that https://community.ubuntu.com/t/ubuntu-18-04-move-window-without-tilebar-by-press-and-hold-alt-click-inside-window/3801/4 ?
[14:29] <willcooke> jbicha, fair question, but I think even Motif did it that way (alt-click), so I do wonder if we should stick with alt
[14:29] <seb128> willcooke, the issues from understand are that 1- other actions use super so it would be consitent, 2- alt is used by some apps and claiming it for shell actions creates conflicts and make some actions impossible to do in those apps
[14:29] <seb128> willcooke, e.g https://blender.stackexchange.com/questions/24473/alt-click-is-not-selecting-edge-loops-in-linux
[14:29] <willcooke> ah, yes that's where I saw it
[14:30] <willcooke> kk, then I think we need to socialise it a bit more.  I can do that.
[14:30] <seb128> history/habits has values
[14:30] <seb128> but sometime it's worth forcing users to adapt their habits
[14:30] <seb128> right
[14:30] <kenvandine> and the nice shortcuts overlay will help :)
[14:31] <seb128> hey kenvandine!
[14:31] <seb128> right
[14:31] <seb128> but that's not for this cycle
[14:31] <kenvandine> yeah
[14:31] <kenvandine> this is yet another case for why we need that overlay
[14:36] <seb128> andyrock, this time you can move the disks card to done :)
[15:36] <oSoMoN> https://forum.snapcraft.io/t/call-for-testing-libreoffice-6-0-0/3917
[15:38] <oSoMoN> and https://plus.google.com/+OlivierTilloy/posts/ADH83TytCab
[15:38] <seb128> oSoMoN, woooot
[15:41] <kenvandine> oSoMoN, woot
[15:42] <oSoMoN> I wish I'd had it ready *before* FOSDEM, but better late than never…
[15:42]  * ricotz feels pressured now ;)
[15:55] <jbicha> seb128: I think I'll upload adwaita-icon-theme 3.27.90 to bionic now https://git.gnome.org/browse/adwaita-icon-theme/tree/NEWS
[15:55] <seb128> oSoMoN, yeah, it's not late after :)
[16:06] <seb128> jbicha, sounds fine to me
[17:24] <willcooke> nice work oSoMoN
[17:37] <willcooke> didrocks, re: dock.  Say I have two terminal windows open and I switch between them via the dock.  The most recently used one is always at the top right?  Personally I find that very confusing, sometimes the terminal that I want is the top one, and sometimes its the bottom one.  Would it be possible to fix it (probably as an option? :( )  so that the windows are always the same place in the stack?
[17:37] <jbicha> jibel: could you forward your nm-config-connectivity change to Debian? I mentioned it to mbiebl earlier and he didn't seem to understand why it was needed
[17:42] <jbicha> oh nice, Khurshid is working on getting GOA working in unity-control-center (see the Community Hub)
[17:57] <didrocks> willcooke: hum, I need to look at the code, I find the current (stack order) making more sense to me
[17:57] <didrocks> willcooke: but it doesn't prevent to open a bug upstream
[17:58]  * didrocks finally started to get some reviews on G-S, but on styling and naming, so doing the changes (but profound changes incoming I guess)
[18:15] <willcooke> didrocks, ack, thanks
[18:19] <doko> oSoMoN: libreoffice is now blocking migrations. will you upload 6 before the weekend, or could you fix the current build?
[18:23] <willcooke> night all
[18:38] <doko> oSoMoN: never mind, upload building with the internal liborcus
[18:43] <oSoMoN> doko, ack, that's good news because I have other urgent work before EOW
[18:57] <doko> oSoMoN: crap, now fails with another error:
[18:57] <doko> In file included from /usr/include/glm/gtx/norm.hpp:18:0,
[18:57] <doko>                  from /<<PKGBUILDDIR>>/vcl/inc/opengl/VertexUtils.hxx:16,
[18:57] <doko>                  from /<<PKGBUILDDIR>>/vcl/opengl/gdiimpl.cxx:39:
[18:57] <doko> /usr/include/glm/gtx/quaternion.hpp:23:3: error: #error "GLM: GLM_GTX_quaternion is an experimental extension and may change in the future. Use #define GLM_ENABLE_EXPERIMENTAL before including it, if you really want to use it."
[18:57] <doko>  # error "GLM: GLM_GTX_quaternion is an experimental extension and may change in the future. Use #define GLM_ENABLE_EXPERIMENTAL before including it, if you really want to use it."
[18:57] <doko>    ^~~~~
[18:57] <doko> In file included from /<<PKGBUILDDIR>>/vcl/inc/opengl/VertexUtils.hxx:16:0,
[18:57] <doko>                  from /<<PKGBUILDDIR>>/vcl/opengl/gdiimpl.cxx:39:
[18:57] <doko> /usr/include/glm/gtx/norm.hpp:21:3: error: #error "GLM: GLM_GTX_norm is an experimental extension and may change in the future. Use #define GLM_ENABLE_EXPERIMENTAL before including it, if you really want to use it."
[18:57] <doko>  # error "GLM: GLM_GTX_norm is an experimental extension and may change in the future. Use #define GLM_ENABLE_EXPERIMENTAL before including it, if you really want to use it."
[18:57] <doko>    ^~~~~
[18:57] <doko> there is a reason why you should keep packages buildable ...
[19:00] <oSoMoN> doko, that's already fixed in the 6.0 branch
[19:00] <oSoMoN> https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?id=25c4af24b858087b3bd375ce8fad847b1affd484
[19:02] <doko> oSoMoN: I assume it's not yet ready for upload?
[19:02] <seb128> doko, "keep packages buildable", that's a joke right? the package are kept buildable, it's just that when things keep changing and create issues it takes time to keep up
[19:02] <jbicha> obviously LibreOffice built fine a week ago
[19:03] <doko> no, a week ago, it wasn't building
[19:03] <seb128> if there something buggy there is to upload a new version without handling fixing rdepends
[19:03] <jbicha> https://launchpad.net/ubuntu/+source/libreoffice/1:5.4.4-0ubuntu2
[19:03] <doko> seb128: no, it's not a joke. it's real life
[19:03] <seb128> new version of glm
[19:03] <doko> I didn't upload
[19:03] <seb128> right, neither did o_SoMoN
[19:04] <doko> so do we have magic dwarfs and elfs fixing build failures?
[19:04] <seb128> your complain is that whoever synced glm didn't handle the transition
[19:05] <doko> jbicha: ^^^
[19:05] <seb128> doko, stop that, this glm update was done a week ago
[19:05] <seb128> doko, libreoffice is already fixed in the vcs
[19:05] <seb128> so it has been actively handled
[19:05] <doko> seb128: it doesn't help if it's not uploaded. you know the current transition mess
[19:05] <seb128> it's just that updates sometime take more than a day
[19:05] <doko> sure, a day would be fine ...
[19:06] <seb128> right, well talk to whoever starts those stack of transitions
[19:06] <seb128> not to those who are victim of the mess
[19:07] <seb128> transitons could be better prepared upfront
[19:07] <doko> seb128: YOU ARE WRONG. most of of the unrelated ones are imported from debian. you are responsible for these as I am
[19:08] <seb128> doko, well maybe we should delete some stuff from proposed
[19:08] <seb128> and do transitions one by one
[19:08] <seb128> stopping the autoimporter for a while
[19:08] <seb128> there are way to deal better with those
[19:08] <jbicha> liborcus and libixion are tied to the LibreOffice version, if we're not ready for LO 6 yet, then we don't need those new versions yet either
[19:08] <doko> seb128: go ahead and propose that, and DRIVE that. in Oct/Nov I did that.
[19:09] <seb128> doko, I've other things to work on and the situation doesn't bother me
[19:09] <seb128> but I sympathize with you trying to sort that out
[19:09] <doko> sure, until everything gets fucked up
[19:10] <seb128> we could flush proposed
[19:10] <seb128> and start reuploading in wanted order
[19:10] <jbicha> oSoMoN: could doko upload https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/?h=ubuntu-bionic-6.0 now?
[19:10] <seb128> if really needed
[19:10] <seb128> shrug
[19:10] <doko> I'm uploading a build with internal glm for now
[19:10] <seb128> jbicha, could be delete you glm update from proposed?
[19:10] <seb128> be->we
[19:11] <doko> no, reverting would be worse I assume
[19:11] <seb128> why was that transition even started if the proposed situation is that complex?
[19:11] <seb128> the way out is usually not to pile more
[19:11] <jbicha> glm wasn't supposed to be a "transition"
[19:11] <oSoMoN> is the world gonna stop spinning if we wait until Monday and do a proper, clean and tested upload of 6.0 ? I have other urgent things to work on tomorrow
[19:12] <seb128> oSoMoN, we don't upload something we are not confident with, if you say it should wait on monday then that's what we do
[19:12] <doko> now uploaded lo again. let's see what else breaks
[19:12] <jbicha> I don't need the new glm. I just cherry-picked it from the merge queue
[19:13] <doko> jbicha, seb128: in general, please watch your uploads/syncs until they reach the release pocket. you may want to search update_excuses for "Debian GNOME"
[19:14] <seb128> doko, I personally do
[19:15] <doko> please tell your team, manager and community ;p
[19:15] <seb128> k
[19:16] <jbicha> I do spend a lot of time working on excuses
[19:16] <doko> and it was 80% of my work time for the last two weeks :-/
[19:17] <jbicha> I leave the hard ones for you ;)
[19:19] <jbicha> like all of the remaining Debian GNOME ones are hard ones :(
[19:19] <doko> I appreciate your work on removals. so maybe be more aggressive about these
[19:21] <jbicha> I mean they're hard ones
[19:22] <jbicha> I could be agressive and ignore failing build tests since upstream doesn't care as much about if they pass everywhere…
[19:22] <jbicha> the tracker one is really annoying since they added broken tests in a point release
[19:28] <doko> no new build failure for lo yet ... https://launchpad.net/ubuntu/+source/libreoffice/1:5.4.4-0ubuntu5
[22:05] <gsilvapt> jibel, you around?