=== jamesh_ is now known as jamesh
[07:25] <oSoMoN> good morning desktoppers
[07:28] <jibel> good morning oSoMoN
[07:29] <oSoMoN> salut jibel
[08:08] <seb128> good morning desktopers
[08:23] <alatiera> Are the 18.04 packages in freeze yet? Cause the rustc is kinda outdated
[08:26] <seb128> alatiera, hey, no there is no freeze yet, it's just a complex package to update
[08:27] <seb128> alatiera, https://launchpad.net/ubuntu/+source/rustc/1.23.0+dfsg1+llvm-0ubuntu2 ... 1.23 seems the current version from a google query, what newest one would you expect?
[08:27] <alatiera> seb128:  great, I am writing docs for librsvg and wouldn't want to point newcomers to use rustup instead of the system package
[08:28] <alatiera> 1.24 but it's like a week old, anything above 1.20 would be fine for my usecase
[08:28] <seb128> alatiera, it's blocked in bionic-proposed currently though
[08:30] <alatiera> I see, thanks alot!
[08:30] <seb128> it's not migrating because it didn't build on s390x
[08:30] <seb128> yw
[08:30] <seb128> which is weird, it's build-depending on itself it seems
[08:30] <seb128> well I guess chrisccoulson knows the situation better than me
[08:32] <oSoMoN> good morning seb128
[08:32] <seb128> lut oSoMoN , ça va ? bon w.e?
[08:38] <oSoMoN> seb128, pas mal, et toi?
[08:38] <seb128> bien! 3j de w.e et une journée de repos au spa :)
[08:40] <oSoMoN> sympa
[08:40] <oSoMoN> ça fait du bien j’imagine
[08:40] <seb128> oui :)
[08:44] <Nafallo> salut o/
[08:45] <oSoMoN> hey Nafallo
[09:03] <Laney> hi there
[09:05] <duflu> Hi Laney, oSoMoN, Nafallo, seb128, jibel, world
[09:06] <oSoMoN> hey Laney, duflu
[09:06] <Laney> hey duflu & oSoMoN
[09:06] <jibel> Hi duflu
[09:06] <Laney> moin jibel
[09:06] <jibel> and all
[09:06] <Laney> good weekends?
[09:06] <jibel> wet
[09:07] <jibel> but quiet and restful
[09:08] <seb128> hey everyone
[09:09] <seb128> Laney, good! spa on friday; nice weather (cold&sunny) on saturday/sunday so quite some walking around ... you?
[09:11] <Laney> hey seb128
[09:11]  * Laney is jealous of this spa experience
[09:11] <Laney> we went walking in the peak district
[09:12] <Laney> mostly inside a cloud
[09:12] <doko> oSoMoN: https://bugs.launchpad.net/ubuntu/+source/libepubgen/+bug/1749920
[09:12] <ubot5> Ubuntu bug 1749920 in libepubgen (Ubuntu) "[MIR] libepubgen" [Undecided,Incomplete]
[09:13] <Laney> although it did lift a bit once we got to the top on the first day
[09:13] <Laney> https://photos.google.com/share/AF1QipN7hT2C3HZMSSrXvCgfne8FNDnkXDzDLk5bMY5vFCpADMNMQ0pn5F7OavjmToJ1MQ/photo/AF1QipNyJT6IMAZfwLy21ADIxk_HCYaQstzwf8lGtIPH?key=V20tV0NOdXY2ZGwyaG1JZk5qd19JNHJKNl9uTU9R
[09:14] <seb128> doko, "no bug subscriber" as only feedback, does it mean it's good to be approved outside of that?
[09:15] <doko> seb128: no, looking there's more
[09:15] <seb128> k
[09:16] <doko> but I don't understand why even that one is missing
[09:20] <oSoMoN> I suppose it's fine if we subscribe ~libreoffice
[09:20] <oSoMoN> seb128, ^ ?
[09:20] <seb128> oSoMoN, wfm, dunno if that's a team doko is happy with though
[09:23] <seb128> speaking of MIR
[09:24] <seb128> doko, do you know what's the status of the libblockdev one? somebody posted a comment about a security review, is that an official MIR team bounce? should it be assigned to security team in that case? or is that a random non-MIR-member comment?.
[09:24] <doko> seb128, oSoMoN: is it the same as lo itself? e.g. https://launchpad.net/ubuntu/+source/libixion has both lo and desktop
[09:31] <oSoMoN> not sure about ~desktop-bugs, that's a lot of people potentially not interested in libreoffice and its deps
[09:31] <oSoMoN> seb128, wdyt?
[09:33] <seb128> oSoMoN, if ~libreoffice is an acceptable team then +1 for that one, otherwise we can do desktop, it's just to define assignment
[09:33] <oSoMoN> seb128, doko: I've subscribed ~libreoffice
[09:36] <seb128> thx
[09:37] <seb128> doko, do we need desktop as well?
[09:42] <oSoMoN> doko, is the lack of a symbols file a blocker?
[09:48] <chrisccoulson> alatiera, how come you wouldn't want to point people to use rustup? The rustc package in the archive is really only there for building distro packages. People hacking on rust code would probably be better off using the rust community's tools, like rustup
[09:49] <alatiera> chrisccoulson: indeed, I use it myself and prefer it but it's an extra tool newcomers would have to manager and can go wrong
[09:53] <seb128> pitti, hey. is python-dbusmock known to have issue with nm 1.10? or was https://github.com/martinpitt/python-dbusmock/issues/37 the first mention of it (it comes from autopkgtest errors since the update)
[09:59] <doko> oSoMoN: yes, I think we required those in the past. it shouldn't be that difficult
[10:00] <doko> seb128: could you point me to the list of subscribers which the desktop team is monitoring for bug reports?
[10:03] <oSoMoN> doko, ack. what's the preferred course of action here? submit improvements to debian and sync back, or do it in ubuntu first and submit changes to debian from there?
[10:03] <oSoMoN> the latter might be faster
[10:03] <seb128> doko, I'm not sure to understand the question, you want to know the team used for reports? it's desktop-packages
[10:05] <doko> I'm just saying that you should be sure which teams you use to monitor bug reports.
[10:11] <doko> seb128: "somebody posted a comment about a security review, is that an official MIR team bounce?" well I asked for a security review before. now assigned to the security team
[10:11] <seb128> doko, thanks, that was not obvious from the current comment/status
[10:12] <seb128> doko, right, desktop team uses ~desktop-packages, I don't  know how ~libreoffice is being used since I'm not working on that package
[10:14] <doko> well, but the whole point is that the team knows about these bugs
[10:16] <doko> seb128, jbicha: the s390 plugin should be packaged according to xnox, and symbols files should be added
[10:16] <doko> getting late lunch now ...
[10:16] <seb128> doko, enjoy
[10:17] <oSoMoN> enjoy
[10:17] <oSoMoN> at that time of the day that would be a late breakfast for me :)
[10:22] <doko> oSoMoN: I forgot, the lo uitest autopkg test fails
[10:22] <oSoMoN> doko, I know, I filed https://launchpad.net/bugs/1750335
[10:22] <ubot5> Ubuntu bug 1750335 in libreoffice (Ubuntu) "LO 6.0 autopkgtest failures (uicheck: test_text_direction)" [High,Confirmed]
[10:23] <pitti> seb128: it's the first time I hear about it; I just followed up to the issue; should be easy enough to fix
[10:24] <seb128> pitti, thx
[10:25] <seb128> pitti, just curious, on what n-m version are you? (or is fedora, since I guess that's what you use) is that issue somewhat specific to Ubuntu?
[10:25] <pitti> seb128: I'm on Fedora 27, NM is  at 1.8.6
[10:25] <seb128> oh ok
[10:25] <pitti> those were the days when I've always used the current devel series :)
[10:25] <seb128> no issue with that version then :)
[10:25] <seb128> hehe
[10:26] <pitti> rawhide isn't nearly as stable as ubuntu devel, so I'm using the current stable
[10:27] <pitti> https://apps.fedoraproject.org/packages/NetworkManager → rawhide indeed has 1.10
[10:27] <pitti> but nobody complained so far
[10:28] <pitti> hah, it failed to build
[10:31] <seb128> pitti, https://koji.fedoraproject.org/koji/buildinfo?buildID=1009625 worked though
[10:40] <duflu> seb128, I don't know yet. Will need to try bisecting bluez tomorrow. It also depends if upstream declares it a bug or a feature
[10:40] <seb128> duflu, what changed exactly?
[10:40] <seb128> or what is behaving differently?
[10:41] <duflu> seb128, they rewrote the "readline" line editing stuff used in bluetootctl and other interactive tools
[10:42] <duflu> Such a stupid problem to have. It has nothing to do with bluetooth really
[10:45] <seb128> right, well if it's a bug in their command line utilies which might create issues in scripts&such it's still a bug worth fixing
[10:46] <seb128> duflu, if we believe it's non important we can also skip that test result for now to get the new version in, would still be good to at least report upstream
[10:47] <duflu> seb128, yes already reported upstream. AFAICT python-dbusmock tests may be the only thing impacted
[10:48] <duflu> And that's another day I didn't get time to work on mutter
[10:49] <duflu> Night all
[10:49] <seb128> night duflu
[11:19] <Laney> seb128: kenvandine[m][m] (dunno if you'll see that): https://code.launchpad.net/~vorlon/livecd-rootfs/ubuntu-channels-for-snaps/+merge/337897 <- will need to publish gnome-calculator to a new channel once this is uploaded
[11:39] <seb128> Laney, thanks for the head up
[11:44] <Laney> np
[11:56] <jbicha> xnox: doko: enabling the s390 plugin causes libblockdev to FTBFS on s390x, that's why it's disabled
[11:56] <jbicha> good morning
[12:01] <gsilvapt> hello all
[12:01] <gsilvapt> jibel, you around=
[12:01] <gsilvapt> s/=/?
[12:02] <kenvandine[m][m]> Laney: yeah, we talked about it in the meeting on Friday.  I've published gnome-calculator to stable/ubuntu-18.04 and then closed the branch
[12:02] <kenvandine[m][m]> Per his request
[12:03] <Laney> kenvandine[m][m]: ok cool
[12:30] <seb128> hey jbicha
[12:30] <jbicha> hey
[12:30] <seb128> jbicha, are you looking at the autopkgtest issues from your uploads? like the n-m urfk one?
[12:30] <seb128> and the glib d-t-r one?
[12:31] <jbicha> what's urfk?
[12:32] <jbicha> basically no
[12:33] <jbicha> NM's autopkgtest issue might be relatively easy based on the comments from LP: #1734586
[12:33] <ubot5> Launchpad bug 1734586 in network-manager (Ubuntu) "Merge NetworkManager with Debian 1.10.0-1" [Wishlist,Fix committed] https://launchpad.net/bugs/1734586
[12:33] <seb128> jbicha, https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1734586/comments/6 the first part
[12:33] <seb128> right, which is why I was asking
[12:33] <seb128> the python-dbusmock part is being handled
[12:34] <jbicha> I've never worked on dbus-test-runner before so it would be cool if someone else could work on that
[12:34] <seb128> L_aney said he could have a look
[12:34] <jbicha> great
[12:34] <seb128> :)
[12:34] <seb128> jbicha, also what's the status of the gnome-desktop transition?
[12:34] <Laney> You don't need to have worked on dbus-test-runner
[12:34] <seb128> it's not clear to me from a quick look what is missing/blocking
[12:34] <jbicha> at least with the glib one, there was no easy way to know that a rdepends's autopkgtest would fail until we uploaded to Ubuntu and found out :(
[12:34] <Laney> Once you start looking at the failure it's clear what it is
[12:35] <jbicha> it's clear to Laney but not to the rest of us ;)
[12:36] <Laney> No, it'd be clear to you too
[12:36] <Laney> new glib:
[12:36] <Laney> root@autopkgtest-lxd-iiuugp:/tmp/autopkgtest.z8x60r/build.4XM/src/tests# dbus-run-session gdbus emit --session --object-path /test/dbustestrunner/signal --signal com.launchpad.dbustestrunner.signal
[12:36] <Laney> Error: Destination is not specified
[12:36] <Laney> root@autopkgtest-lxd-iiuugp:/tmp/autopkgtest.z8x60r/build.4XM/src/tests#
[12:36] <jbicha> I mean I did spend a couple minutes looking at it but I didn't understand what I was looking at
[12:36] <Laney> old glib:
[12:36] <Laney> laney@nightingale> gdbus emit --session --object-path /test/dbustestrunner/signal --signal com.launchpad.dbustestrunner.signal
[12:36] <Laney> laney@nightingale>                                                                                             ~
[12:38] <Laney> all I did was reproduce the failure and then look into what it was doing
[12:38] <seb128> jbicha, http://packaging.ubuntu.com/html/auto-pkg-test.html has details on how to try things locally
[12:38] <Laney> running smaller bits of it until I got to the issue
[12:38] <Laney> which is this regression in the gdbus tool
[12:39] <Laney> anyways, nearly there now
[12:40] <jbicha> seb128: if you're talking about the rdepends issue, it's not obvious (to me) what rdepends autopkgtests will be triggered
[12:41] <seb128> jbicha, no, I meant to reproduce a test failing and be able to look at the problem/debug
[12:41] <seb128> or did you mean the gnome-desktop question? ;)
[12:42] <jbicha> anyway, once glib is fixed, there's only one issue holding up the gnome-desktop3 transition.
[12:43] <seb128> are you sure?
[12:43] <seb128> which one?
[12:44] <jbicha> I'm rebuilding https://bileto.ubuntu.com/#/ticket/3138 (Unity) and if that works, I'm publishing it
[12:44] <seb128> I see at least gnome-control-center wanting network-manager to be cleared (not sure why)
[12:45] <xnox> jbicha, well typo, not in v2.14, but fixed in v2.13 so even earlier.
[12:45] <seb128> "Depends: gnome-control-center network-manager (not considered) "
[12:45] <jbicha> seb128: oh :(
[12:46] <jbicha> xnox: ?
[12:46] <seb128> xnox, hey, Chris mentioned that you might be interested in fixing cargo/rust on s390x rather than seing it removed on those arches, is that true?
[12:47] <xnox> seb128, i've asked chrisccoulson to fix cargo/rust on s390x; and there it seems strange that he saw bootstrap bugs on s390x on ubuntu, when it is fully bootstrapped to latest releases in Fedora and Suse.
[12:47] <jbicha> xnox: ok, I'll try re-enabling the s390 plugin for libblockdev, thanks
[12:47] <xnox> seb128, as far as I can tell, foundations does not maintain cargo/rust by mutual agreement.
[12:47] <seb128> xnox, nobody maintains those :)
[12:48] <xnox> seb128, why remove it, if it simply lacks a bootstrap?
[12:48] <seb128> xnox, is it?
[12:48] <xnox> seb128, as far as i can tell, it requires no fixing, just bootstrapping -> and like not deleting binaries and making it impossible to bootstrap again.
[12:48] <xnox> seb128, and by using PPAs, instead of the archive, we got ourselfs into the situation of expiring binaries.
[12:49] <xnox> BTW debian raised ISA instruction set to z196 and they will have it bootstrapped too, on s390x, soon.
[12:50] <seb128> xnox, chris said that cargo doesn't work properly on s390x and that rust will most probably not build
[12:51] <jbicha> oops, Unity still doesn't build
[12:51] <seb128> xnox, seems you guys disagree on what is needed then
[12:52] <xnox> rust built up to 1.23 at http://download.sinenomine.net/epel/epel-7/s390x/ and cargo up to 0.24.0
[12:52] <xnox> ditto in fedora
[12:52] <xnox> https://koji.fedoraproject.org/koji/buildinfo?buildID=1045427
[12:52] <xnox> https://koji.fedoraproject.org/koji/buildinfo?buildID=1025841
[12:52] <xnox> sorry second is bad link, this one is the right one https://koji.fedoraproject.org/koji/buildinfo?buildID=1026897
[12:53] <seb128> ok, good
[12:53] <seb128> can you help bootstrapping then?
[12:53] <xnox> all built on s390x.... if it works there, why does it not work for us? well, hard to test, since bootstrapping got dropped.
[12:54] <chrisccoulson> rust stopped building because of what looked like a cargo build, and unless something has changed very recently, our cargo build looks like it's broken on s390 (have a look at the test failures)
[12:54] <xnox> seb128, i am full for the current two week iteration, ping gaughen to schedule things into foundations trello?
[12:54] <chrisccoulson> err, cargo bug
[12:54] <xnox> chrisccoulson, well, i cannot rebuild cargo at all anymore, since the binaries in the PPAs have expired.
[12:55] <xnox> chrisccoulson, do you have a ppa per-release of rust/cargo, such that you have stashed builds of the last good cargo/rust 21? and you started to have failures with 22 and up?
[12:55] <xnox> chrisccoulson, since each subsequent one, requires previous one to build, you should always make a new PPA to stack each series. Or package each one as a new source/binary package names, such that binaries are not deleted...
[12:58] <xnox> from fedora build log, there are some test failures - but they are localhost networking and "assume building from git repository" assertion failures. I don't see any serious / arch specific failures. Most tests are passing.
[12:59] <seb128> gnome-session is also an issue for the gnome-desktop transition
[12:59] <seb128> gnome-session-bin/amd64 unsatisfiable Depends: libegl1
[13:00] <xnox> chrisccoulson, note creating PPAs with all architectures enabled, is completely self-service tick the boxes in settings now. As in, s390x is no longer restricted.
[13:00] <xnox> and then just need to setup build-dependencies between PPAs for each subsequent one to depend on the previous one.
[13:02] <jbicha> seb128: oh right, see https://irclogs.ubuntu.com/2018/02/16/%23ubuntu-desktop.html#t12:29
[13:03] <seb128> jbicha, there are no easy transitions in Ubuntu are they? ;)
[13:04] <jbicha> libgweather was ok, the gnome-desktop3 one was a lot more complicated than I hoped
[13:04] <jbicha> for instance, Unity built fine in my PPA but it failed to build with glib which was updated in the mean time
[13:05] <jbicha> that mesa transition was surprising too :)
[13:06] <seb128> the autopkgtest issues come as a surprise on top then :)
[13:07] <jbicha> and LibreOffice's autopktests are entangled with it too!
[13:07] <seb128> right, looks like oSoMoN is looking at those though
[13:08] <seb128> so yeah, that transition is probably to take the week
[13:08] <oSoMoN> I am
[13:08] <seb128> jbicha, can you look at doing the tweaks Brian suggested to the n-m autopkgtest?
[13:11] <jbicha> seb128: it may take me a few days for NM so anyone else is welcome to work on it earlier
[13:11] <xnox> chrisccoulson, do you have the LP bug # for the cargo issue? location of source packages / build records, and the last built s390x binaries?
[13:11] <seb128> jbicha, k, thx
[13:11] <jbicha> btw, I'm waiting for gnome-desktop3 to complete before starting https://people.canonical.com/~ubuntu-archive/transitions/html/evolution-data-server.html
[13:12] <jbicha> (but I may start it anyway next week because of Feature Freeze)
[13:13] <seb128> k
[13:13] <seb128> did you identify risky updates
[13:13] <seb128> we should build a list before the meeting so we know what we are going to discuss and can prepare
[13:15] <jbicha> seb128: do you want me to open a Community hub topic for it?
[13:15] <seb128> jbicha, that would be nice, thx
[16:03] <Trevinho> jbicha: I think the last mesa has some problems
[16:03] <Trevinho> we get this crash at the end of a test
[16:03] <Trevinho> https://www.irccloud.com/pastebin/ieALagQN/
[16:03] <jbicha> tjaalton: ^
[16:04] <jbicha> talking about the Unity FTBFS, right?
[16:17] <Trevinho> yeah...
[16:17] <Trevinho> or actually it's just nux doing things wrong
[17:00] <Trevinho> tjaalton: well, actually this is happening when doing a glXDestroyContext for a context that has never been free'd
[17:28] <Laney> biab
[17:51] <Trevinho> tjaalton: could be related https://bugzilla.redhat.com/show_bug.cgi?id=1526848 ?
[17:51] <ubot5> Error: Could not parse XML returned by bugzilla.redhat.com: HTTP Error 403: Forbidden (https://bugzilla.redhat.com/show_bug.cgi?id=1526848&ctype=xml)
[19:28] <popey> morning robert_ancell :)
[19:28] <robert_ancell> popey, hi
[19:30] <robert_ancell> kenvandine[m][m], who owns the hangout? I'm sitting on "requesting to join"
[19:32] <popey> robert_ancell: joining the meeting :)
[19:44] <seb128> robert_ancell, he might be off, today is an U.S holiday (president's day)
[20:32] <xnox> has something changed in colord packaging?
[20:32] <xnox> i'm getting this in systemd autopkgtests
[20:32] <xnox> Feb 19 17:08:36 autopkgtest systemd-udevd[385]: Error resolving group 'colord': Connection timed out
[20:32] <xnox> and that's relatively new.
[20:33] <xnox> Is something supposed to create colord group? and/or did it get dropped, but still referenced in udev rules?
[20:35] <robert_ancell> flexiondotorg, do you think you might have something like https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1648534 ?
[20:35] <ubot5> Ubuntu bug 1648534 in gnome-software (Ubuntu Xenial) "gnome-software crashed with SIGTRAP in g_wakeup_new from g_main_context_new from g_dbus_connection_send_message_with_reply_sync from g_dbus_connection_call_sync_internal from g_dbus_connection_call_sync" [Critical,Confirmed]
[20:35] <robert_ancell> Particularly comment 3
[20:36] <robert_ancell> or perhaps https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1659858
[20:36] <ubot5> Ubuntu bug 1659858 in gnome-software (Ubuntu) "gnome-software (5) g_wakeup_new → g_main_context_new → g_dbus_connection_send_message_with_reply_sync → g_dbus_connection_call_sync_internal → g_dbus_connection_call_with_unix_fd_list_sync" [High,Confirmed]
[20:41] <flexiondotorg> robert_ancell: I have a .crash in /var/crash but apport didn't want to upload because libssl was out of date.
[20:41] <flexiondotorg> I'm running 18.04 daily.
[20:42] <robert_ancell> flexiondotorg, if you could try checking the file descriptors if you think it's happening again that would be helpful
[20:43] <flexiondotorg> Sure thing.
[20:43] <flexiondotorg> I'll try and provoke it tomorrow.
[20:44] <ochosi> hey guys
[20:44] <ochosi> quick general question (from someone who has never submitted a new package before): is it too late to submit a new package (that is not in debian) to ubuntu?
[20:45] <ochosi> it's a fairly tiny a11y helper (just a few lines of C) that draws expanding circles where the mouse pointer is
[20:45] <ochosi> i'd like to get that included in xubuntu by default, because we've had that request a few times and our WM doesn't support it (and the maintainer of xfwm4 doesn't really want to have this kind of functionality in the window manager)
[20:46] <jbicha> ochosi: it's not too late. There are no guarantees it will make bionic, but for best results, get it in the new queue before Feature Freeze
[20:47] <ochosi> yeah, ofc
[20:47] <ochosi> the alternative is to push it to an existing xubuntu-maintained package
[20:47] <ochosi> there are probably some packages that would be okayish
[20:47] <ochosi> then again, maybe others want to use this too (lubuntu?)
[20:56] <robert_ancell> kenvandine[m][m], I forgot to ask, what was the conclusion on the gnome-software version in bionic? Should I take the work jbicha did in Debian and merge it into Ubuntu?
[21:09] <kenvandine[m][m]> robert_ancell: we're going to go with 3.28 for anything that doesn't require a transition
[21:10] <kenvandine[m][m]> So gnome-software should be safe
[21:12] <robert_ancell> kenvandine[m][m], ta