[05:11] infinity: whoops :) will look === pfsmorigo is now known as Guest85097 [10:03] 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! === pfsmorigo is now known as Guest96954 [11:22] thanks ginggs :) [11:23] LocutusOfBorg: r-cran-curl? [11:23] yep [11:23] LocutusOfBorg: np :) [11:30] Somebody already working on upgrading wpa? :) seems a hype atm ;) [11:30] cpaelzer: I just remembered: https://jira.mariadb.org/browse/MDEV-13412 is possibly relevant to the MariaDB failure too. === pfsmorigo is now known as Guest29661 [11:37] rbasak: I see an issue more local to mariadb [11:38] rbasak: the test case only fails with the new mariadb upload [11:38] rbasak: 10.1.25-1 is good, but 10.1.28-1 is bad [11:38] rbasak: was 10.1.25-1 built before gcc7 - do you happen to know? [11:39] let me check dates [11:41] already pulls in gcc7 on the old build [11:41] so no new optimization as we assumed before [11:41] Interesting [11:44] also since the .28 is 14 houts old a rebuild won't be much different [11:45] still I have one ongoing atm [11:45] just to be sure [11:48] rbasak: this is fixed in 10.1.29 according to the ticket you linked before [11:49] rbasak: would need to do a test build with that [11:49] is that released already? [11:49] I don't see it in Debian [11:49] maybe just the fix of the issue added on .28 [11:49] yeah me neither, can add the change on top (at least for a crappy test build) [11:50] looking for the actual fix now [11:59] rbasak: I find no reference to the bug in the mariadb sources, nor on this jira page [12:00] rbasak: do you know how they usually hide ... umm manage bugs to find it (the commit that fixed it) [12:02] cpaelzer: no, I couldn't find it. [12:05] I foudn it in the 10.0 branch [12:05] but takes time to consider that for 10.1 or if it is applicable to our case at all [12:06] rbasak: https://github.com/MariaDB/server/commit/6454d4e17727b6c786fbb953f4cc05c8cd739e83 [12:06] that is the one I found so far [12:07] cpaelzer: I think that's the upstream workaround for the pcre3 bug fixed in my upload. [12:07] They patch their embedded version [12:07] but it is directed at the "new" error message [12:08] at least according to the logs in the bug tracker [12:08] And I think they might try to not use the system version if the bug exists [12:09] yeah it seems they fix their internal which means this isn't directly applicable for us :-/ [12:09] nor will we get more help as for upstream it is considered fixed [12:30] 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] rbasak: but now on the re-patch I linked before where they detect if the lib is broken look at the tests [12:30] rbasak: they change the counts, but not back to the values we have [12:31] that means considering that the pcre3 upload you had made the "fix" available = __attribute__((noinline,noclone)) [12:31] that matches your fix and is from their last commit [12:31] shouldn't we take the portion that adapts the test to match that change [12:31] I'll try that in my test env before packaging it all up just to fail [12:32] rbasak: do you have a pointer to the change you made to pcre to be sure? [12:33] cpaelzer: https://launchpad.net/ubuntu/+source/pcre3/2:8.39-5ubuntu1 [12:34] 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] rbasak: the failure now mostly is that the test works but is expected to fail [12:35] Ah [12:35] it runs like recurse(133) and expects it to fail [12:35] I misunderstood that. Thanks [12:35] the first fix was to bump 133 to a huge number [12:35] failing, done [12:35] but that didn't always work as a constant is so ... constant [12:36] now the newer fix changes back these values, but not to where they were [12:36] upstream went 133 -> 400 -> 250 [12:36] we are still at 133 [12:36] but since you ported the pcre3 change I wonder if making these numbers match would be required [12:36] and OTOH there is a part of the change in pcre which you did not port - was that intentional? [12:37] around: SET(PCRE_NO_RECURSE "${WIN32}" CACHE BOOL [12:37] rbasak: ^^ ? [12:37] Half intentional - I picked the patch from https://bugs.exim.org/show_bug.cgi?id=2173 [12:37] bugs.exim.org bug 2173 in Code "stack frame size detection is broken" [Bug,Resolved: wontfix] [12:38] rbasak: this part is "missing" then in comparison [12:38] https://github.com/MariaDB/server/commit/6454d4e17727b6c786fbb953f4cc05c8cd739e83#diff-9a9ad0af0c4fff92c9d7311d8762dd7e [12:39] which has a great on = off = on logic twist [12:39] 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] Is that suitable for the global src:pcre3? [12:40] it before was on in the mariadb local pcre [12:40] I don't think so, but am not the expert [12:40] I would want to check how our pcre3 is [12:40] it might be off anyway or so [12:41] we have default off [12:41] and it is in the build logs [12:41] ... [12:43] of course everything is slightly different in that pcre3 [12:43] but I found Use stack recursion ............. : yes on x86 [12:43] s390x as well [12:43] so our recursion is ON which matches NO_RECURSE Off [12:44] so we should be on the same level as the internal pcre fix inside mariadb [12:44] changing the test numbers for a test now [12:45] I love invert_do_not_skip_not_thing = false code [12:51] rbasak: it is not as easy as that :-/ [12:52] probably because of the different pcre versions behaving differently the test adaption would need to be different as well [12:56] :( [12:56] ha [13:01] rbasak: since the try to fix failed I documented the testbed and made it availabel to you [13:01] rbasak: the last trello card update has all you need [13:02] rbasak: and as a side note - this is a "regression" because these tests didn't exist before the .28 upload [13:02] rbasak: so it is in fact much more a new test which just not works on s390x [13:03] 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] That sounds reasonable [13:03] the automation for the dep8 already has a skip function [13:03] we could if arch then add one more [13:08] Yes I believe that's possible [13:08] And I think the release team are happy to take merge proposals for that [13:08] Or just ask them here I guess. [13:08] oh, you mean in the overrides [13:09] rbasak: I was talking about encoding that int he dep8 test to retain the coverage of all the other tests [13:09] Oh, I see. [13:09] That sounds better [13:09] 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] rbasak: I'll file a bug as reference, copy over some of our data we have, and provide a fix [13:10] rbasak: I'd ping you then so you can take a look [13:10] unfortunately mariadb isn't imported to the version in propsed it seems [13:10] I can run an import if you like? [13:10] It might take a while [13:10] rbasak: you likely have the command closer than I have, that would be nice to run that [13:10] It should be current in Debian VCS though [13:10] OK I'll run it now [13:11] I could look at my qemu issue until you ping [13:29] cpaelzer: it's importing. [13:29] (still) [13:29] cpaelzer: but also you could use https://anonscm.debian.org/git/pkg-mysql/mariadb-10.1.git if you like. [13:29] Since it's in sync with Debian currently, it should match exactly. [13:37] cyphermox: already upgrading WPA ? :) [13:38] rbasak: yeah, I'd want your eyes/comments and if possible ondreys anyway [13:38] so doing on the alioth is probably the bets [13:38] dupondje: hum, wat? === pfsmorigo is now known as Guest88437 [13:44] cyphermox: https://lists.debian.org/debian-security-announce/2017/msg00261.html guess Ubuntu needs to follow :) [14:07] rbasak: there is now a bug for the mariadb dep8 issue as well as a fix suggestion linked [14:07] rbasak: I subscribed you and ondrey for your comments on the suggestion [14:08] rbasak: never the less the test env still exists if you want to take a look yourself again [14:08] rbasak: or if any of the discussion needs a check while I'm not around [14:35] 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] bug 1716357 in evince (Ubuntu Zesty) "a typo in evince-previewer.desktop breaks /etc/mailcap" [Medium,Fix committed] https://launchpad.net/bugs/1716357 [14:35] 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] cpaelzer: many thanks for your help! [14:47] 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] 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] anyway, topic closed I guess [14:49] thanks for unblocked the fix! [14:51] Oh, I didn't notice how old it was. [14:53] rbasak: I just now pushed the qemu fix I worked on, not sure I can complete the percona today [14:54] rbasak: more likely start picking off of my triage duty and to that tmrw morning [14:54] rbasak: ok? [14:54] cpaelzer: that's fine. [14:54] Thanks again for your time [15:26] https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1723909 strange nobody seems to pick this up ... [15:26] Launchpad bug 1723909 in wpa (Ubuntu) "[security] WPA2: Many vulnerabilities discovered" [Undecided,Confirmed] [15:30] 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] ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13077) [15:30] dupondje, sdeziel: I'm publishing updates now [15:31] mdeslaur: thanks [15:40] mdeslaur: nice! === jbicha_ is now known as jbicha [15:41] who takes care of artful btw? [15:44] dupondje: it's already uploaded for artful but it needs to be manually accepted by Release Team because of Final Freeze [15:44] https://launchpad.net/ubuntu/artful/+queue?queue_state=1 [15:45] ah! thx [16:03] 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] pls :-) [16:10] jamespage: approved [16:15] bdmurray: ta === pfsmorigo is now known as Guest87922 [16:27] 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] jamespage: I do know and you need to poke someone like me [16:31] * jamespage pokes bdmurray [16:31] bdmurray: please could you put my changes live :) [16:34] jamespage: it runs at 05,35 so might appear soon [16:35] bdmurray: thanks! [16:48] 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] bdmurray, it's similar to bug 1723025 [16:49] bug 1723025 in gdm3 (Ubuntu) "no login screen when booting with an external monitor attached" [Undecided,New] https://launchpad.net/bugs/1723025 [16:50] bdmurray, in my case the machine turns the internal display off. [16:50] so I don't see the login [16:50] Ah, I can see it on the internal display just the behavior is different from the previous release [16:51] Trevinho, ^ [16:51] bdmurray, can you file a bug against gdm3 [16:52] jibel: Of course [16:52] thanks [17:04] jibel: 1724017 [17:05] jibel: bug 1724017 [17:05] bug 1724017 in gdm3 (Ubuntu) "Cannot login using external display" [Undecided,New] https://launchpad.net/bugs/1724017 [17:05] bdmurray, thanks. [19:19] doko: I still can't reproduced the swift FTBFS for artful amd64. I'm not sure what I'm missing. [19:27] 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] codepython777: do you mean to be asking that in #ubuntu? [19:52] nacc: will do, thanks === Pharaoh_Atem is now known as Conan_Kudo === Conan_Kudo is now known as Pharaoh_Atem === pfsmorigo is now known as Guest15151 === pfsmorigo is now known as Guest6836