pitti | infinity: whoops :) will look | 05:11 |
---|---|---|
=== pfsmorigo is now known as Guest85097 | ||
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! | 10:03 |
=== pfsmorigo is now known as Guest96954 | ||
LocutusOfBorg | thanks ginggs :) | 11:22 |
ginggs | LocutusOfBorg: r-cran-curl? | 11:23 |
LocutusOfBorg | yep | 11:23 |
ginggs | LocutusOfBorg: np :) | 11:23 |
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:30 |
=== pfsmorigo is now known as Guest29661 | ||
cpaelzer | rbasak: I see an issue more local to mariadb | 11:37 |
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:38 |
cpaelzer | let me check dates | 11:39 |
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:41 |
cpaelzer | also since the .28 is 14 houts old a rebuild won't be much different | 11:44 |
cpaelzer | still I have one ongoing atm | 11:45 |
cpaelzer | just to be sure | 11:45 |
cpaelzer | rbasak: this is fixed in 10.1.29 according to the ticket you linked before | 11:48 |
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:49 |
cpaelzer | looking for the actual fix now | 11:50 |
cpaelzer | rbasak: I find no reference to the bug in the mariadb sources, nor on this jira page | 11:59 |
cpaelzer | rbasak: do you know how they usually hide ... umm manage bugs to find it (the commit that fixed it) | 12:00 |
rbasak | cpaelzer: no, I couldn't find it. | 12:02 |
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:05 |
cpaelzer | rbasak: https://github.com/MariaDB/server/commit/6454d4e17727b6c786fbb953f4cc05c8cd739e83 | 12:06 |
cpaelzer | that is the one I found so far | 12:06 |
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:07 |
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:08 |
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:09 |
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:30 |
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:31 |
cpaelzer | rbasak: do you have a pointer to the change you made to pcre to be sure? | 12:32 |
rbasak | cpaelzer: https://launchpad.net/ubuntu/+source/pcre3/2:8.39-5ubuntu1 | 12:33 |
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:34 |
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:35 |
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:36 |
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:37 |
ubottu | bugs.exim.org bug 2173 in Code "stack frame size detection is broken" [Bug,Resolved: wontfix] | 12:37 |
cpaelzer | rbasak: this part is "missing" then in comparison | 12:38 |
cpaelzer | https://github.com/MariaDB/server/commit/6454d4e17727b6c786fbb953f4cc05c8cd739e83#diff-9a9ad0af0c4fff92c9d7311d8762dd7e | 12:38 |
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:39 |
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:40 |
cpaelzer | we have default off | 12:41 |
cpaelzer | and it is in the build logs | 12:41 |
cpaelzer | ... | 12:41 |
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:43 |
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:44 |
cpaelzer | I love invert_do_not_skip_not_thing = false code | 12:45 |
cpaelzer | rbasak: it is not as easy as that :-/ | 12:51 |
cpaelzer | probably because of the different pcre versions behaving differently the test adaption would need to be different as well | 12:52 |
rbasak | :( | 12:56 |
zyga-ubuntu | ha | 12:56 |
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:01 |
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:02 |
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:03 |
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:08 |
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:09 |
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:10 |
cpaelzer | I could look at my qemu issue until you ping | 13:11 |
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:29 |
dupondje | cyphermox: already upgrading WPA ? :) | 13:37 |
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:38 |
=== pfsmorigo is now known as Guest88437 | ||
dupondje | cyphermox: https://lists.debian.org/debian-security-announce/2017/msg00261.html guess Ubuntu needs to follow :) | 13:44 |
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:07 |
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:08 |
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 |
ubottu | 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 |
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:35 |
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:47 |
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:49 |
bdmurray | Oh, I didn't notice how old it was. | 14:51 |
cpaelzer | rbasak: I just now pushed the qemu fix I worked on, not sure I can complete the percona today | 14:53 |
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 | 14:54 |
dupondje | https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1723909 strange nobody seems to pick this up ... | 15:26 |
ubottu | Launchpad bug 1723909 in wpa (Ubuntu) "[security] WPA2: Many vulnerabilities discovered" [Undecided,Confirmed] | 15:26 |
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 |
ubottu | ** <A HREF="https://cve.mitre.org/about/faqs.html#reserved_signify_in_cve_id">RESERVED</A> ** 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 |
mdeslaur | dupondje, sdeziel: I'm publishing updates now | 15:30 |
sdeziel | mdeslaur: thanks | 15:31 |
dupondje | mdeslaur: nice! | 15:40 |
=== jbicha_ is now known as jbicha | ||
dupondje | who takes care of artful btw? | 15:41 |
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:44 |
dupondje | ah! thx | 15:45 |
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:03 |
bdmurray | jamespage: approved | 16:10 |
jamespage | bdmurray: ta | 16:15 |
=== pfsmorigo is now known as Guest87922 | ||
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:27 |
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:31 |
bdmurray | jamespage: it runs at 05,35 so might appear soon | 16:34 |
jamespage | bdmurray: thanks! | 16:35 |
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:48 |
jibel | bdmurray, it's similar to bug 1723025 | 16:49 |
ubottu | bug 1723025 in gdm3 (Ubuntu) "no login screen when booting with an external monitor attached" [Undecided,New] https://launchpad.net/bugs/1723025 | 16:49 |
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:50 |
jibel | Trevinho, ^ | 16:51 |
jibel | bdmurray, can you file a bug against gdm3 | 16:51 |
bdmurray | jibel: Of course | 16:52 |
jibel | thanks | 16:52 |
bdmurray | jibel: 1724017 | 17:04 |
bdmurray | jibel: bug 1724017 | 17:05 |
ubottu | bug 1724017 in gdm3 (Ubuntu) "Cannot login using external display" [Undecided,New] https://launchpad.net/bugs/1724017 | 17:05 |
jibel | bdmurray, thanks. | 17:05 |
coreycb | doko: I still can't reproduced the swift FTBFS for artful amd64. I'm not sure what I'm missing. | 19:19 |
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:27 |
nacc | codepython777: do you mean to be asking that in #ubuntu? | 19:39 |
codepython777 | nacc: will do, thanks | 19:52 |
=== 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 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!