[02:31] <tsimonq2> rbasak: Could you please look at bug 1710993? It's a high (if not critical) priority regression with known fixes already uploaded to the queues, and it affects anybody running Lubuntu 16.04 LTS. (You probably remember the discussion...)
[02:31] <ubottu> bug 1710993 in lubuntu-meta (Ubuntu Xenial) "PulseAudio requirement breaks Firefox on ALSA-only systems after 55.0.1 update" [Critical,Fix committed] https://launchpad.net/bugs/1710993
[02:34] <tsimonq2> rbasak: I vigorously tested all three of the uploads listed before uploading them, on several computers, and poked around a lot. They do not show any signs of regressions for me. But I guess it'll at least be another week because nobody on the SRU Team reviewed indicator-sound-gtk2 that's been sitting in the queue for over a month at this point...
[02:38] <tsimonq2> (not only do these uploads work fine with the testing I have done, these exact updates are in every stable Lubuntu release from 16.10 and on)
[05:56] <niceprogrammer> why dont you guys offer onions for updates like debain?
[05:56] <niceprogrammer> debian
[07:35] <v3n0m> hey
[07:35] <v3n0m> Ubuntu 17.10 is having a slow boot time.
[08:00] <abeato> seb128, hi, I am taking a look at bug #1693756 . I saw you objected to the patch that bumped libqmi version. Alex answered to that comment #14, which is your position on this changes at the moment?
[08:00] <ubottu> bug 1693756 in OEM Priority Project "[Xenial][ DW5816e] to support qmi over mbim which needed for FCC authentication." [Critical,Triaged] https://launchpad.net/bugs/1693756
[08:09] <seb128> abeato, hey, there is a long email discussion about that one and it seems a never ending story :-/
[08:09] <seb128> abeato, my opinion is that somebody should talk to the SRU team, I suggested what I though was needed to have a good chance to see a SRU be accepted but I'm not part of the SRU team so just guessing for them
[08:09] <seb128> abeato, it's quite a big change for a SRU and we would need regression testing on hardware that works today
[08:10] <seb128> imho
[08:10] <abeato> seb128, yeah, agreed
[08:10] <abeato> seb128, who would be the best person to ask for help to SRU? cyphermox?
[08:12] <seb128> abeato, he would be a good person to ask about modemmanager but he's not in the SRU team, see https://launchpad.net/~ubuntu-sru/+members#active
[08:13] <abeato> ah, ok
=== inaddy is now known as tinoco
=== sil2100_ is now known as sil2100
[09:29] <jamespage> xnox: morning - are you aware of anything s390x ish in artful that might make STP convergence take longer?  I'm seeing a new test failure on this arch for the 2.8.0 openvswitch packages in archive.
[09:30] <jamespage> if I increased the time warping in the test by 30 seconds, I get the right result which indicates that the STP convergence is taking 60 vs 30 seconds on other archs...
[09:30] <jamespage> its a bit of a head scratcher
[09:32] <xnox> jamespage, hm, in artful we did switch from isc-dhcp/ifupdown to systemd/netplan (for dhclient too) we did have STP code there as well.
[09:32] <xnox> let me see.
[09:33] <jamespage> xnox: I would expect that to impact on all architectures
[09:33] <xnox> right
[09:33] <jamespage> might not be directly related to STP - ovs is running in dummy mode so its all userspace testing AFAICT
[09:33] <jamespage> it might be the time/warp function is borked on s390x compared to other archs
[09:34] <xnox> jamespage, time/warp? it is not possible to change time on s390x
[09:34] <jamespage> xnox: its a testing hack in ovs itself
[09:35] <jamespage> it basically fast forwards time for the daemon so that things that take time to converge don't cause long test times
[09:46] <xnox> jamespage, not sure. looking at the kernel code there is nothing s390x special.
[09:46] <jamespage> xnox: hmm no
[09:46] <xnox> there is stuff about spawning userspace /sbin/bridge-stp -> which we don't have at all on any architecture?
[09:46] <xnox> jamespage, the bit of "daemon fast forwards time" i'm interested to check how that is done, and if that is at all available on s390x / done right on big endian.
[09:48] <jamespage> xnox: https://github.com/openvswitch/ovs/blob/master/lib/timeval.c
[09:54] <jamespage> xnox: odd its not 2.8.0 specific - I see the same with 2.7.1 on xenial
[09:54]  * jamespage thinks some more
[09:55] <xnox> jamespage, it would be interesting to test, via the ctl/api commands if this timewarping actually works on s390x =/
[09:55] <xnox> it seems like it should be.
[09:56] <jamespage> xnox: I can give you a script
[09:56] <xnox> but on the other hand, it is not allowed/possible to change hardware clocks on s390x.
[09:56] <jamespage> xnox: http://paste.ubuntu.com/25764879/
[09:56] <xnox> but i'm not sure about the details as to what exactly is not allowed.
[09:56] <jamespage> xnox: time/warp is a userspace sim of time change I think
[09:59] <xnox> true
[11:01] <rbasak> tsimonq2: around? I commented on the bug.
[11:02] <rbasak> tsimonq2: since it's possible you might want to put the Breaks in indicator-sound-gtk2, I don't want to accept it as-is without your comment.
[11:02] <rbasak> tsimonq2: if you do, then it'll want adding to lubuntu-default-settings too I guess?
[11:05] <rbasak> tsimonq2: aside from that your upload for indicator-sound-gtk2 looks fine. Though I feel that the changelog message should probably mention the reason for the upload (Lubuntu's move to pulseaudio), I won't block on that.
[11:06] <rbasak> tsimonq2: let me know what you want to do please.
=== Guest6836 is now known as pfsmorigo
=== pfsmorigo is now known as Guest62312
[12:40] <tsimonq2> rbasak? :)
[12:40] <tsimonq2> (does not seem to be in the chan...)
[13:20] <cpaelzer> powersj: smoser: cyphermox: slangasek: can we reboot diamond to be on a kernel with working kvm?
[13:20] <cpaelzer> kernel team fixed it a while ago, but it needs the reboot to pick it up
[13:22] <smoser> cpaelzer: its fine with me.
[13:22] <smoser> i'd do a 'ps' and a'who' and go for it
[13:22] <smoser> are other people seeing has sum msimatch ?
[13:23] <smoser> http://paste.ubuntu.com/25765854/
[13:25] <cpaelzer> smoser: yeah I who'd already which brough cyphermox on this list
[13:25] <cpaelzer> translating the nic for mario ...
[13:25] <infinity> smoser: Nope.  Looks like you have an angry proxy.
[13:26] <infinity> smoser: Or a bitflip in your download.
[13:26] <cpaelzer> Mmike: ^^ are you ok rebooting diamond as well ?
[13:26] <cpaelzer> smoser: seen no mismatch in the last ~2 weeks or so
[13:26] <cjwatson> $ curl -s http://us.archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-dbg_2.26-0ubuntu2_amd64.deb | sha256sum
[13:26] <cjwatson> 62aa80bdb27569a65b85ed19f21663fae456df5dd2d3108c3dd84afd19817b53  -
[13:26] <cjwatson> Yeah, I'd check for proxies on your network path.
[13:26] <cpaelzer> same sum as cjwatson here
[13:27] <Unit193> Same here as well.
[13:27] <infinity> He's getting the right file length, so a bitflip seems plausible.
[13:27] <cjwatson> You could try wget --no-cache -O /dev/null http://us.archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-dbg_2.26-0ubuntu2_amd64.deb   to see if that clears it.
[13:27] <Mmike> cpaelzer, ack
[13:27] <smoser> yeah. proxy ticked off. through the proxy i get different than not through it :-(
[13:27] <smoser> wonder how that happened.
[13:30] <cyphermox> cpaelzer: go for it.
[13:44] <powersj> cpaelzer: go for it as well
[13:59] <cpaelzer> powersj: cyphermox: slangasek: Mmike: smoser: done and up on 4.4.0-96-generic now
[13:59] <cpaelzer> kvm guests working again, happy testing
[14:00] <cpaelzer> I always wonder how "sudo ppc64_cpu  --smt=off" can take 8 seconds - maybe this goes to IBM india for sombody to ack and change a license code in the FW
[14:00] <Mmike> cpaelzer, thnx!
[14:01] <smoser> cpaelzer: fwiw, something left dpkg in a bad state
[14:01] <smoser> i'm running dpkg --configure -a now
[14:01] <smoser> then apt-get autoremove
[14:01] <smoser> then i'm going to upgrade
[14:01] <smoser> 0 upgraded, 0 newly installed, 37 to remove and 70 not upgraded.
[14:01] <smoser> After this operation, 3,048 MB disk space will be freed.
[14:02] <smoser> Do you want to continue? [Y/n]
[14:02] <smoser> y
[14:02] <smoser> Y
[14:02] <smoser> :)
[14:02] <smoser> 3G of old kernels
[14:12] <cpaelzer> smoser: before I rebooted there was a apt daily hanging
[14:13] <cpaelzer> maybe that was shutdown by the reboot in just the "right" moment
[14:13] <smoser> cpaelzer: well, all up to date now.
[14:14] <cpaelzer> thanks smoser
=== mhall119_ is now known as mhall119
[14:50] <tsimonq2> rbasak: Breaks might be a good idea... but if any one lands before the other, as long as they all land within an hour or two it'll be fine
[14:50] <tsimonq2> (well, within a few hours of each other)
[14:52] <tsimonq2> rbasak: If you'd prefer Breaks I can upload some new packages in 6 or 7 hours
[14:52] <tsimonq2> But yeah, good point.
[14:56] <rbasak> tsimonq2: it can break if you have a user with the security pocket enabled but not updates for example.
[14:56] <rbasak> Because security will base upon updates.
[14:57] <rbasak> So if there's a security update for one of those things (say indicator-gtk-whatever), and a user hasn't seen (and won't see) the update to lubuntu-meta, then the indicator will switch to pavucontrol even though pulseaudio isn't installed.
[14:58] <rbasak> With a Breaks, apt will notice and either want to remove lubuntu-meta or refuse to update indicator-gtk-whatever. I don't know which - I'd need to test.
[14:58] <rbasak> For security that might be worse of course. But apt is simply maintaining integrity according to what we declared (if we do).
[14:59] <rbasak> One would hope that the security team would notice, but this would be very unusual so they might well not.
[14:59] <rbasak> Adjusting and maintaining dependency changes in stable releases is hard :-/
[15:00] <rbasak> tsimonq2: anyway, that's the potential consequence. I don't have a strong opinion here especially as the potential breakage isn't severe and is recoverable.
[15:01] <rbasak> tsimonq2: if you want me to accept the current indicator-sound-gtk2 in the queue, I'd be happy to - just give me a +1 after you've considered the above please.
[15:01] <rbasak> Since I think this should be your decision.
[15:21] <tsimonq2> rbasak: Since I've been the one doing Lubuntu security updates for Universe packages, I'm willing to deal with the consequences if needed. +1, please accept.
[15:47] <niedbalski> rbasak, any chance that you can review https://code.launchpad.net/~paelzer/ubuntu/+source/percona-xtradb-cluster-5.6/+git/percona-xtradb-cluster-5.6/+merge/332357 ? LGTM.
[15:56] <rbasak> niedbalski, cpaelzer: sorry, I don't think I'm going to be able to get to it. cpaelzer is a core dev - please could you sponsor if you're happy, without me?
[15:56] <niedbalski> rbasak, thank you for all your effort on this bug.
[15:56] <rbasak> You're welcome.
[15:57] <rbasak> I have a pile of things blocked on me right now, and the advice is to delegate more. So I'm trying :)
=== Guest62312 is now known as pfsmorigo
=== pfsmorigo is now known as Guest62789
[17:22] <v3n0m> Ubuntu 17.10 very slow boot time
[17:29] <nacc> v3n0m: #ubuntu+1
[18:52] <ignoo> Hello,running ubuntu GNOME 16.04, have some issues with ubuntu Artful Aardvark: https://pastebin.com/BgBHExes ; Thank you for your Support.
=== JanC_ is now known as JanC
[19:37] <mitya57> Does anyone know if we want to follow Debian and switch to OpenSSL 1.1 for 18.04?
[19:37] <mitya57> xnox, ^^
[19:37] <mdeslaur> depends if everything has 1.1 support
[19:38] <mdeslaur> we don't want to support two different openssl versions for 5 years
[19:38] <mitya57> I was wondering if we should aim at Qt 5.9 (LTS) or Qt 5.10 (which has OpenSSL 1.1 support)
[19:38] <tsimonq2> The only downside I can see to doing that is that Qt 5.10 and on is needed and we'd (I wear {L,K}ubuntu hats when I say this) like to ship with Qt 5.9 in the LTS.
[19:38] <tsimonq2> Yeah.
[19:38] <mdeslaur> and 1.0.2 will be supported for longer than 1.1 by upstream
[19:39] <tsimonq2> I'm also curious to see what the decision will be.
[19:41] <tsimonq2> Another thing to consider (I *think*, could be incorrect) is that Qt 4 might not have OpenSSL 1.1 support. So while I would certainly like to reduce the number of rdeps on src:qt4-x11 over time, I don't know if thast can be done in time for the LTS.
[19:41] <tsimonq2> Although in a perfect world I wouldn't mind if we could just kill Qt 4 already,,,
[19:41] <tsimonq2> s/,,,/.../
[19:41] <mdeslaur> worst case, openssl 1.0.2 can be in universe...but it would be a shame to have a crypto library being used that nobody is maintaining
[19:42] <tsimonq2> True.
[19:43] <tsimonq2> Regardless, Clever Cat might be a good cycle to tackle that in.
[19:43]  * tsimonq2 shrugs
[19:43] <mitya57> tsimonq2, for Qt 4 there is a patch in Debian BTS, not tested yet
[19:43] <tsimonq2> mitya57: Hmmm, ok.
[19:44] <mitya57> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828522#211
[19:44] <ubottu> Debian bug 828522 in src:qt4-x11 "qt4-x11: FTBFS with openssl 1.1.0" [Important,Open]
[19:44]  * mitya57 afk for some time
[19:46] <tsimonq2> (iirc xnox does that sort of thing, I'm curious to see what he says)
[19:47] <wxl> tsimonq2: . is a regex metacharacter. you'd need to escape that. ;)
[19:48] <tsimonq2> wxl: True, but I'm assuming that IRC is somehow intelligent enough to interpret that. :P
[19:49] <wxl> tsimonq2: remember that you're subtly training people how to use sed and find and replace in vim ;)
[19:49] <tsimonq2> wxl: :%s/,,.
[19:49] <tsimonq2> grr
[19:50] <tsimonq2> :%s/,,,/\.\.\./
[19:50] <tsimonq2> That should work.
[19:50] <wxl> ;)
[19:50] <tsimonq2> :)
[19:50] <lamont> tsimonq2: on the right hand side, it doesn't need to be escaped.
[19:50] <sarnold> no need to escape dots on the replacement side. also it's vim, regex stuff doesn't work right there anyway.
[19:51] <wxl> aw dang, i lose!
[19:51] <mdeslaur> nerds
[19:52] <wxl> i resemble that remark
[19:52] <tsimonq2> hehehehehe
[19:52] <tsimonq2> lamont: And wait, you're right... I forgot what "." meant for a second there. :P
[19:53] <tsimonq2> Makes sense.
=== catbus is now known as catbus-afk
=== tkamppeter__ is now known as tkamppeter
[20:59] <infinity0> LocutusOfBorg: as a hint for sagemath, i think it needs cython 0.26
=== catbus-afk is now known as catbus
=== elky is now known as el
[23:04] <xnox> mitya57, tsimonq2 - ubuntu ships with openssl 1.0.1 so we are not affected.
[23:04] <xnox> mitya57, we have not made decisions about that.
[23:04] <xnox> mitya57, i really really really want to drop qt4 from the archive regardless.
[23:04] <xnox> failing that, i want it in universe built against libressl but generally off my lawn.
[23:05] <xnox> mitya57, we are monitoring the situation.....
[23:17] <tsimonq2> Ok
[23:17] <tsimonq2> xnox: I'm with you irt Qt 4 :)
[23:18] <tsimonq2> The next KDE Applications release that Kubuntu puts in the archive finally makes KDE 4 unsupported.
[23:18] <tsimonq2> So that'll be a major relief.
[23:18] <tsimonq2> xnox: Otherwise, if you feel inclined: https://wiki.debian.org/Qt4Removal
=== enick_852 is now known as RAOF