[05:11] <pitti> infinity: whoops :) will look
[10:03] <pitti> infinity: uploaded autopkgtest 5.0.2 to debian, I'll sync as soon as it gets imported. also, thanks to whoever added the britney "your package is stuck" email notifications!
[11:22] <LocutusOfBorg> thanks ginggs :)
[11:23] <ginggs> LocutusOfBorg: r-cran-curl?
[11:23] <LocutusOfBorg> yep
[11:23] <ginggs> LocutusOfBorg: np :)
[11:30] <dupondje> Somebody already working on upgrading wpa? :) seems a hype atm ;)
[11:30] <rbasak> cpaelzer: I just remembered: https://jira.mariadb.org/browse/MDEV-13412 is possibly relevant to the MariaDB failure too.
[11:37] <cpaelzer> rbasak: I see an issue more local to mariadb
[11:38] <cpaelzer> rbasak: the test case only fails with the new mariadb upload
[11:38] <cpaelzer> rbasak: 10.1.25-1 is good, but 10.1.28-1 is bad
[11:38] <cpaelzer> rbasak: was 10.1.25-1 built before gcc7 - do you happen to know?
[11:39] <cpaelzer> let me check dates
[11:41] <cpaelzer> already pulls in gcc7 on the old build
[11:41] <cpaelzer> so no new optimization as we assumed before
[11:41] <rbasak> Interesting
[11:44] <cpaelzer> also since the .28 is 14 houts old a rebuild won't be much different
[11:45] <cpaelzer> still I have one ongoing atm
[11:45] <cpaelzer> just to be sure
[11:48] <cpaelzer> rbasak: this is fixed in 10.1.29 according to the ticket you linked before
[11:49] <cpaelzer> rbasak: would need to do a test build with that
[11:49] <cpaelzer> is that released already?
[11:49] <rbasak> I don't see it in Debian
[11:49] <cpaelzer> maybe just the fix of the issue added on .28
[11:49] <cpaelzer> yeah me neither, can add the change on top (at least for a crappy test build)
[11:50] <cpaelzer> looking for the actual fix now
[11:59] <cpaelzer> rbasak: I find no reference to the bug in the mariadb sources, nor on this jira page
[12:00] <cpaelzer> rbasak: do you know how they usually hide ... umm manage bugs to find it (the commit that fixed it)
[12:02] <rbasak> cpaelzer: no, I couldn't find it.
[12:05] <cpaelzer> I foudn it in the 10.0 branch
[12:05] <cpaelzer> but takes time to consider that for 10.1 or if it is applicable to our case at all
[12:06] <cpaelzer> rbasak: https://github.com/MariaDB/server/commit/6454d4e17727b6c786fbb953f4cc05c8cd739e83
[12:06] <cpaelzer> that is the one I found so far
[12:07] <rbasak> cpaelzer: I think that's the upstream workaround for the pcre3 bug fixed in my upload.
[12:07] <rbasak> They patch their embedded version
[12:07] <cpaelzer> but it is directed at the "new" error message
[12:08] <cpaelzer> at least according to the logs in the bug tracker
[12:08] <rbasak> And I think they might try to not use the system version if the bug exists
[12:09] <cpaelzer> yeah it seems they fix their internal which means this isn't directly applicable for us :-/
[12:09] <cpaelzer> nor will we get more help as for upstream it is considered fixed
[12:30] <cpaelzer> rbasak: it seems to me that along the initial fix tests were changed, you picked the pcre fix that was included into the pcre3 package
[12:30] <cpaelzer> rbasak: but now on the re-patch I linked before where they detect if the lib is broken look at the tests
[12:30] <cpaelzer> rbasak: they change the counts, but not back to the values we have
[12:31] <cpaelzer> that means considering that the pcre3 upload you had made the "fix" available  = __attribute__((noinline,noclone))
[12:31] <cpaelzer> that matches your fix and is from their last commit
[12:31] <cpaelzer> shouldn't we take the portion that adapts the test to match that change
[12:31] <cpaelzer> I'll try that in my test env before packaging it all up just to fail
[12:32] <cpaelzer> rbasak: do you have a pointer to the change you made to pcre to be sure?
[12:33] <rbasak> cpaelzer: https://launchpad.net/ubuntu/+source/pcre3/2:8.39-5ubuntu1
[12:34] <rbasak> cpaelzer: the failure we're seeing now seems like an exception happening before the test failure though? Or do I understand that part wrong?
[12:35] <cpaelzer> rbasak: the failure now mostly is that the test works but is expected to fail
[12:35] <rbasak> Ah
[12:35] <cpaelzer> it runs like recurse(133) and expects it to fail
[12:35] <rbasak> I misunderstood that. Thanks
[12:35] <cpaelzer> the first fix was to bump 133 to a huge number
[12:35] <cpaelzer> failing, done
[12:35] <cpaelzer> but that didn't always work as a constant is so ... constant
[12:36] <cpaelzer> now the newer fix changes back these values, but not to where they were
[12:36] <cpaelzer> upstream went 133 -> 400 -> 250
[12:36] <cpaelzer> we are still at 133
[12:36] <cpaelzer> but since you ported the pcre3 change I wonder if making these numbers match would be required
[12:36] <cpaelzer> and OTOH there is a part of the change in pcre which you did not port - was that intentional?
[12:37] <cpaelzer> around: SET(PCRE_NO_RECURSE "${WIN32}" CACHE BOOL
[12:37] <cpaelzer> rbasak: ^^ ?
[12:37] <rbasak> Half intentional - I picked the patch from https://bugs.exim.org/show_bug.cgi?id=2173
[12:38] <cpaelzer> rbasak: this part is "missing" then in comparison
[12:38] <cpaelzer> https://github.com/MariaDB/server/commit/6454d4e17727b6c786fbb953f4cc05c8cd739e83#diff-9a9ad0af0c4fff92c9d7311d8762dd7e
[12:39] <cpaelzer> which has a great on = off = on logic twist
[12:39] <cpaelzer> asuuming that ${WIN32} is off for our builds we would set NO_RECURES off now (with the change), which means we would recurse
[12:40] <rbasak> Is that suitable for the global src:pcre3?
[12:40] <cpaelzer> it before was on in the mariadb local pcre
[12:40] <cpaelzer> I don't think so, but am not the expert
[12:40] <cpaelzer> I would want to check how our pcre3 is
[12:40] <cpaelzer> it might be off anyway or so
[12:41] <cpaelzer> we have default off
[12:41] <cpaelzer> and it is in the build logs
[12:41] <cpaelzer> ...
[12:43] <cpaelzer> of course everything is slightly different in that pcre3
[12:43] <cpaelzer> but I found Use stack recursion ............. : yes on x86
[12:43] <cpaelzer> s390x as well
[12:43] <cpaelzer> so our recursion is ON which matches NO_RECURSE Off
[12:44] <cpaelzer> so we should be on the same level as the internal pcre fix inside mariadb
[12:44] <cpaelzer> changing the test numbers for a test now
[12:45] <cpaelzer> I love invert_do_not_skip_not_thing = false code
[12:51] <cpaelzer> rbasak: it is not as easy as that :-/
[12:52] <cpaelzer> probably because of the different pcre versions behaving differently the test adaption would need to be different as well
[12:56] <rbasak> :(
[12:56] <zyga-ubuntu> ha
[13:01] <cpaelzer> rbasak: since the try to fix failed I documented the testbed and made it availabel to you
[13:01] <cpaelzer> rbasak: the last trello card update has all you need
[13:02] <cpaelzer> rbasak: and as a side note - this is a "regression" because these tests didn't exist before the .28 upload
[13:02] <cpaelzer> rbasak: so it is in fact much more a new test which just not works on s390x
[13:03] <cpaelzer> I wonder if in that POV we should mask just that test on just that arch instead of overriding it in a-proposed to migrate
[13:03] <rbasak> That sounds reasonable
[13:03] <cpaelzer> the automation for the dep8 already has a skip function
[13:03] <cpaelzer> we could if arch then add one more
[13:08] <rbasak> Yes I believe that's possible
[13:08] <rbasak> And I think the release team are happy to take merge proposals for that
[13:08] <rbasak> Or just ask them here I guess.
[13:08] <cpaelzer> oh, you mean in the overrides
[13:09] <cpaelzer> rbasak: I was talking about encoding that int he dep8 test to retain the coverage of all the other tests
[13:09] <rbasak> Oh, I see.
[13:09] <rbasak> That sounds better
[13:09] <rbasak> As long as we know to lose it in the future I guess, but the presence of a delta will tell us that.
[13:09] <cpaelzer> rbasak: I'll file a bug as reference, copy over some of our data we have, and provide a fix
[13:10] <cpaelzer> rbasak: I'd ping you then so you can take a look
[13:10] <cpaelzer> unfortunately mariadb isn't imported to the version in propsed it seems
[13:10] <rbasak> I can run an import if you like?
[13:10] <rbasak> It might take a while
[13:10] <cpaelzer> rbasak: you likely have the command closer than I have, that would be nice to run that
[13:10] <rbasak> It should be current in Debian VCS though
[13:10] <rbasak> OK I'll run it now
[13:11] <cpaelzer> I could look at my qemu issue until you ping
[13:29] <rbasak> cpaelzer: it's importing.
[13:29] <rbasak> (still)
[13:29] <rbasak> cpaelzer: but also you could use https://anonscm.debian.org/git/pkg-mysql/mariadb-10.1.git if you like.
[13:29] <rbasak> Since it's in sync with Debian currently, it should match exactly.
[13:37] <dupondje> cyphermox: already upgrading WPA ? :)
[13:38] <cpaelzer> rbasak: yeah, I'd want your eyes/comments and if possible ondreys anyway
[13:38] <cpaelzer> so doing on the alioth is probably the bets
[13:38] <cyphermox> dupondje: hum, wat?
[13:44] <dupondje> cyphermox: https://lists.debian.org/debian-security-announce/2017/msg00261.html guess Ubuntu needs to follow :)
[14:07] <cpaelzer> rbasak: there is now a bug for the mariadb dep8 issue as well as a fix suggestion linked
[14:07] <cpaelzer> rbasak: I subscribed you and ondrey for your comments on the suggestion
[14:08] <cpaelzer> rbasak: never the less the test env still exists if you want to take a look yourself again
[14:08] <cpaelzer> rbasak: or if any of the discussion needs a check while I'm not around
[14:35] <seb128> bdmurray, hey, thanks for unblocking bug #1716357, I think the rule doesn't make sense though and I was trying to get a conversation going about it rather than making you do the work :-/
[14:35] <seb128> bdmurray, it's likely that the zesty SRU is just never going to be verified and going to suck in proposed while zesty get deprecated, that feels like a waste of work
[14:47] <rbasak> cpaelzer: many thanks for your help!
[14:47] <bdmurray> seb128: In this specific instance it was a regression from a security fix though so think it needs fixing regardless. However, I see your point about it possibly sitting in zesty unverified.
[14:49] <seb128> bdmurray, k, fair enough, I would have agreed with that more if the update was recent, but it has been half a cycle ago so users either don't mind about the issue or workarounded it or moved to some less buggy system by now
[14:49] <seb128> anyway, topic closed I guess
[14:49] <seb128> thanks for unblocked the fix!
[14:51] <bdmurray> Oh, I didn't notice how old it was.
[14:53] <cpaelzer> rbasak: I just now pushed the qemu fix I worked on, not sure I can complete the percona today
[14:54] <cpaelzer> rbasak: more likely start picking off of my triage duty and to that tmrw morning
[14:54] <cpaelzer> rbasak: ok?
[14:54] <rbasak> cpaelzer: that's fine.
[14:54] <rbasak> Thanks again for your time
[15:26] <dupondje> https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1723909 strange nobody seems to pick this up ...
[15:30] <sdeziel> dupondje: looks like the security team is aware and already at work, see https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-13077.html
[15:30] <mdeslaur> dupondje, sdeziel: I'm publishing updates now
[15:31] <sdeziel> mdeslaur: thanks
[15:40] <dupondje> mdeslaur: nice!
[15:41] <dupondje> who takes care of artful btw?
[15:44] <jbicha> dupondje: it's already uploaded for artful but it needs to be manually accepted by Release Team because of Final Freeze
[15:44] <jbicha> https://launchpad.net/ubuntu/artful/+queue?queue_state=1
[15:45] <dupondje> ah! thx
[16:03] <jamespage> bdmurray: I know I could land this myself but could you do a quick sanity review for me - https://code.launchpad.net/~james-page/merge-o-matic/ubuntu-opnestack/+merge/332297
[16:03] <jamespage> pls :-)
[16:10] <bdmurray> jamespage: approved
[16:15] <jamespage> bdmurray: ta
[16:27] <jamespage> bdmurray: you don't happen to know whether that's an automatic deploy? or do I need to go poke someone to get things updated?
[16:31] <bdmurray> jamespage: I do know and you need to poke someone like me
[16:31]  * jamespage pokes bdmurray
[16:31] <jamespage> bdmurray: please could you put my changes live :)
[16:34] <bdmurray> jamespage: it runs at 05,35 so might appear soon
[16:35] <jamespage> bdmurray: thanks!
[16:48] <bdmurray> I've an 17.04 laptop which I upgraded to 17.10 with an external display connected and now I have to login using the laptop display not the external one. Is that a known issue?
[16:49] <jibel> bdmurray, it's similar to bug 1723025
[16:50] <jibel> bdmurray, in my case the machine turns the internal display off.
[16:50] <jibel> so I don't see the login
[16:50] <bdmurray> Ah, I can see it on the internal display just the behavior is different from the previous release
[16:51] <jibel> Trevinho, ^
[16:51] <jibel> bdmurray, can you file a bug against gdm3
[16:52] <bdmurray> jibel: Of course
[16:52] <jibel> thanks
[17:04] <bdmurray> jibel: 1724017
[17:05] <bdmurray> jibel: bug 1724017
[17:05] <jibel> bdmurray, thanks.
[19:19] <coreycb> doko: I still can't reproduced the swift FTBFS for artful amd64. I'm not sure what I'm missing.
[19:27] <codepython777> One of my usb devices has stopped showing up in dmesg/lsusb - it still works - any ideas what might be happening? (Its a FTDI device - which I have a udev rule for)
[19:39] <nacc> codepython777: do you mean to be asking that in #ubuntu?
[19:52] <codepython777> nacc: will do, thanks