| kyrofa | sarnold, alright, done, any chance you'd be willing to sponsor it for us? | 00:16 |
|---|---|---|
| sarnold | kyrofa: sorry, I'm not a coredev :( | 00:18 |
| Unit193 | python-pygraphviz is in universe. | 00:21 |
| sarnold | oh! so motu would suffice? | 00:22 |
| sarnold | (which, alas, I am also not, but that's probably a larger poool :) | 00:22 |
| Unit193 | Yes sir. | 00:23 |
| === pieq__ is now known as pieq | ||
| Unit193 | Is there anything preventing someone sync'ing libjson-c from experimental? | 04:42 |
| tsimonq2 | Unit193: . | 04:45 |
| tsimonq2 | When are you going to become a Core Developer, again? :P | 04:45 |
| Unit193 | Why would I? I like the fringe packages. :3 | 04:45 |
| tsimonq2 | ¯\_(ツ)_/¯ | 04:45 |
| Unit193 | (Read: I'm only looking into this because of 'sway') | 04:45 |
| tsimonq2 | OOOOOH | 04:45 |
| tsimonq2 | What's the progress on that? | 04:46 |
| tsimonq2 | A little birdie tells me someone is interested in starting an Ubuntu Sway flavor. | 04:46 |
| Unit193 | depwait on json-c .13 :P | 04:46 |
| tsimonq2 | :P | 04:46 |
| Unit193 | Urgh, not another... | 04:46 |
| wxl | your what hurts? | 04:46 |
| tsimonq2 | Unit193: Between Ubuntu Sway, Ubuntu Cinnamon, and Ubuntu Unity, I wonder if someone is already betting who actually pulls through first. :P | 04:49 |
| tsimonq2 | (All three of those are currently in some stage of "in the works.") | 04:49 |
| tsimonq2 | Now, if we had an active TB that could actually process a flavor application... | 04:49 |
| * tsimonq2 runs | 04:49 | |
| Unit193 | Who's behind them? | 04:50 |
| tsimonq2 | Unit193: Oh look, your binaries are in the NEW queue. | 04:50 |
| tsimonq2 | Ubuntu Unity has... Khurshid Alam? I'm not sure who else. Ubuntu Cinnamon is by someone I was told I should meet when I went to SELF but never got the chance to, so *shrug*. Ubuntu Sway is a few flavor folks. | 04:52 |
| * tsimonq2 glares at bashfulrobot | 04:53 | |
| tsimonq2 | :P | 04:53 |
| wxl | i'd be interested in trying a sway flavor actually | 04:54 |
| tsimonq2 | wxl: That makes four existing flavor people interested. | 04:55 |
| Unit193 | Right, so reading proposed migration output... | 04:55 |
| wxl | oh yeah and i'm starting a fbui flavor. | 04:55 |
| tsimonq2 | Unit193: Oh? | 04:55 |
| Unit193 | skipped: elogind (0, 5, 11) got: 7+0: a-1:a-4:a-0:i-0:p-0:s-2 * arm64: elogind, libelogind-dev, libelogind0, libpam-elogind | 04:56 |
| tsimonq2 | Actually, that's a good point that I should add to the wiki page. | 04:56 |
| Unit193 | Going to guess it's installability issues, which yeah that's sort of expected in Ubuntu since there's no systemd alternative. | 04:56 |
| tsimonq2 | Yeah, even on notest. | 04:57 |
| tsimonq2 | Hm. | 04:57 |
| Unit193 | Which if sway depends on that...Hrm! | 04:57 |
| tsimonq2 | Oh, well, I wonder why I thought that in the first place, since it wouldn't show as a candidate anyway if autopkgtests didn't pass. | 04:57 |
| tsimonq2 | Unit193: It does? | 04:57 |
| tsimonq2 | Wat? | 04:57 |
| Unit193 | - Make build-deps libsystemd-dev and libelogind-dev alternatives So we'll want the new sway, good. | 04:58 |
| tsimonq2 | * libelogind0 is ABI compatible with libsystemd0 so conflict, replace and | 04:58 |
| tsimonq2 | provide libsystemd0 (=${source:Upstream-Version}), and also install | 04:59 |
| tsimonq2 | Wait... wat? | 04:59 |
| tsimonq2 | libsystemd.so symlinks (Closes: #923244). | 04:59 |
| Unit193 | ...You understand the point of elogind, yes? | 04:59 |
| tsimonq2 | I actually don't. To Google I go. | 04:59 |
| Unit193 | To replace sytemd's logind, so one can have gnome or other such things on a sysvinit/openrc system. | 05:00 |
| tsimonq2 | Elogind has been developed for use in GuixSD, the OS distribution of GNU Guix. | 05:01 |
| tsimonq2 | Hmm. | 05:01 |
| tsimonq2 | Okay. | 05:01 |
| tsimonq2 | Unit193: So you're telling me that sway depends on this thing? | 05:01 |
| * wxl blinks | 05:02 | |
| tsimonq2 | Oh. | 05:02 |
| tsimonq2 | No, I'm glad it isn't. | 05:02 |
| tsimonq2 | I guess they just want it to work in Devuan? :P | 05:02 |
| Unit193 | https://sources.debian.org/src/sway/1.1.1-1/meson.build/#L55 well it *has* support. | 05:03 |
| tsimonq2 | I wonder what went through Drew's mind to do that. | 05:04 |
| Unit193 | Why not? | 05:04 |
| Unit193 | Seems like a good thing to do. | 05:05 |
| tsimonq2 | I'm just wondering why. :) | 05:05 |
| wxl | https://files.devuan.org/devuan_ascii/Release_notes.txt flavors are (consolekit + slim) + (XFCE|MATE) || (elogind + lightdm) + (Cinnamon|KDE|LXQt) | 05:06 |
| Unit193 | That's like wondering why one would support logind.. | 05:06 |
| wxl | almost exactly | 05:06 |
| Unit193 | Anyway, doesn't matter. Things are sync'd. | 05:06 |
| tsimonq2 | Ohhh, it just clicked to me that it's drop-in for their use case. | 05:07 |
| tsimonq2 | Okay, that's cool. | 05:07 |
| wxl | the sleeper has awakened | 05:07 |
| tsimonq2 | There, added update_output_notest.txt to ProposedMigration. | 05:12 |
| Unit193 | Wasn't there an openbox style Wayland compositor? | 05:26 |
| === mwhudson_ is now known as mwhudson | ||
| rbalint | seb128, i'm -1 about nagging uploaders about infra issues, too, but this is not the sru team's fault, the infra should retry automatically | 09:09 |
| seb128 | rbalint, right, fair enough | 09:10 |
| rbasak | seb128: I agree it's tedious to drive SRUs because of the false postiive autopkgtests | 09:52 |
| === ricab is now known as ricab|bbl | ||
| rbasak | seb128: but I don't think it makes sense for the process to require that the limited-in-size SRU team do that driving when any uploader can do it. It'd be more efficient if everyone pitched in. | 09:52 |
| rbasak | seb128: separately, if we can figure out how to reduce the false positives, that'd be good too :) | 09:53 |
| seb128 | rbasak, well, I know that some uploaders get confused on what to do when the test failures is an infra issue and just do nothing and then the SRU sits there for ages | 09:53 |
| seb128 | indeed | 09:53 |
| rbasak | sil2100, seb128: I suggest a tag that means "autopkgtest results have false positives" | 09:54 |
| rbasak | The notification could ask the uploader to tag if they've checked, and we could have the pending-sru report mark the autopkgtest faiilures green or something like that. | 09:55 |
| rbasak | Then uploaders will know what to do and the SRU team can focus on the ones that have been looked at first. | 09:55 |
| seb128 | yeah, that would be better/less confusing I think | 09:57 |
| sil2100 | rbasak: might be a possibility | 09:57 |
| sil2100 | Anyway, even without the bug notification, in most cases people would anyway 'be confused' if they checked the autopkgtest failures, which we expect them to do | 09:57 |
| Laney | That indicator-session case from yesterday passed once the kernel had fully published out, by the way. | 09:57 |
| sil2100 | As I said, nothing changed in the process or anything, we always expected people to look at autopkgtest results of their SRUs | 09:58 |
| rbasak | Yes - adding the notification hasn't made anything worse IMHO. | 09:58 |
| seb128 | Laney, you mean gnome-settings-daemon? | 09:58 |
| Laney | That was the trigger. | 09:58 |
| seb128 | ah, right | 09:58 |
| seb128 | crap, I did a test retry | 09:58 |
| seb128 | thx awesome bar to completing to the retry url for me :/ | 09:59 |
| === ricab|bbl is now known as ricab | ||
| ahasenack | xnox: I've been testing apache2 with client cert auth following the openssl 1.1.1 update | 12:19 |
| ahasenack | I don't have a conclusion yet, but I've been finding some things | 12:19 |
| ahasenack | for example, in disco, it doesn't even establish a connection, because browsers try tls 1.3, and that fails with this errror in the logs: | 12:19 |
| ahasenack | [Thu Jun 27 20:55:43.549681 2019] [ssl:error] [pid 2620:tid 140250923878144] [client 10.0.100.1:60000] AH10129: verify client post handshake, referer: https://bionic-apache-client-cert.lxd/ | 12:20 |
| ahasenack | [Thu Jun 27 20:55:43.549715 2019] [ssl:error] [pid 2620:tid 140250923878144] [client 10.0.100.1:60000] AH10158: cannot perform post-handshake authentication, referer: https://bionic-apache-client-cert.lxd/ | 12:20 |
| ahasenack | [Thu Jun 27 20:55:43.549732 2019] [ssl:error] [pid 2620:tid 140250923878144] SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received | 12:20 |
| rbasak | ahasenack: sounds like we should bump it to Critical? | 12:20 |
| ahasenack | I googled that extension, firefox seems to have it in some version, and chrome/chromium hasn't implemented it yet | 12:20 |
| ahasenack | rbasak: I just want to be sure my setup is ok first, client cert auth is messy to setup and prone to errors | 12:20 |
| ahasenack | I tried disco thinking it would be my good case, but it failed there too. I wanted to try xenial now | 12:21 |
| rbasak | Ah | 12:21 |
| rbasak | Somehow I missed that it was limited to client cert auth only, sorry. | 12:21 |
| maswan | we run on client cert auth all over at $work, and as of today everything is horribly slow :/ | 12:21 |
| ahasenack | on tls v1.2, bionic, I get the same error as reported in https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039 | 12:21 |
| ubottu | Launchpad bug 1833039 in openssl (Ubuntu) "18.04/Apache2: rejecting client initiated renegotiation due to openssl 1.1.1" [Undecided,Confirmed] | 12:21 |
| ahasenack | maswan: that's the bug above, a long timeout | 12:22 |
| ahasenack | rbasak: there is also something about mod reqtimeout, which we have set to 20s, I think the timeouts are related to that kicking in. I tried disabling it, but then the connection never times out | 12:22 |
| ahasenack | something else to investigate | 12:22 |
| maswan | yeah, our wiki maintainer already found that bug, and luckily it's almost weekend here and we hope for better times after the weekend. :) | 12:23 |
| ahasenack | the upstream commit pointed at in the bug talks about tls v1.3 only: mod_ssl: disable check for client initiated renegotiations with TLS 1.3. | 12:23 |
| ahasenack | but we are seeing the timeouts with 1.2 | 12:23 |
| ahasenack | I think there are many things going on and we need to separate them | 12:23 |
| ahasenack | first, I don't think apache in bionic has tls v1.3 support | 12:24 |
| maswan | hm. it's 1.2 here, at least when it finally manages to connect and load | 12:24 |
| paride | ahasenack, so in your setup it just fails, no long waits | 12:33 |
| ahasenack | not what I said | 12:33 |
| xnox | ahasenack: ouch | 12:33 |
| * paride re-reads | 12:33 | |
| ahasenack | in disco it fails, because tls 1.3 is negotiated, but apache complains the browser lacks a certain extension | 12:33 |
| ahasenack | I found bugs about that in firefox and chromium | 12:33 |
| ahasenack | in bionic I reproduce the timeout | 12:35 |
| ahasenack | and I think modrequesttimeout is playing a role here, maybe even helping, I'm not sure yet | 12:35 |
| paride | ahasenack, and in disco there is no fallback to tls1.2, if I get it right | 12:36 |
| ahasenack | for client cert auth, nope | 12:36 |
| ahasenack | the upstream bugs need a closer inspection (firefox, chromium). There was one for apache too, when it was thought it was an apache bug, but apparently that was closed as invalid (that one I didn't even skim yet) | 12:37 |
| paride | ahasenack, I wonder if changing the MinProtocol / MaxProtocol options in /etc/ssl/openssl.conf would have an effect in this case | 12:40 |
| ahasenack | apache has settings for that | 12:41 |
| ahasenack | I mean, if you are thinking about a workaround, it could be set in apache, if there is one | 12:42 |
| ahasenack | I'm not clear on the renegotiation feature, if it's allowed or not | 12:42 |
| ahasenack | openssl's s_client can trigger a renegotiation, via the R key after the connection is established, and it's refused all the time by the server | 12:42 |
| ahasenack | I'm not sure yet what's the expected behavior | 12:42 |
| ahasenack | these are my raw test setup instructions: http://paste.ubuntu.com/p/2fTg2yM2Ht/ | 12:45 |
| === ricab_ is now known as ricab | ||
| xnox | ahasenack: paride: so upstream have refactored SSLVerifyCLient processing inside location stanzas | 14:18 |
| xnox | ahasenack: paride: due to observed brokeness. | 14:18 |
| xnox | ahasenack: paride: i don't think that's in any release. | 14:19 |
| ahasenack | xnox: are you saying this in response to my comment about things working if I move that outside of a location block? | 14:19 |
| xnox | ahasenack: paride: shall we try capping apache2 to tlsv1.2 for now, across the board, until we can get new apache upstream release which is actually compatible and performance with tlsv1.3 | 14:19 |
| ahasenack | xnox: I don't think capping to 1.2 fixes it. That's in fact where I see the problem | 14:20 |
| xnox | ahasenack: yes, moving things outside of the block fixes things. but existing deployments will not change their apache config. | 14:20 |
| xnox | ahasenack: SIGH | 14:20 |
| ahasenack | tls 1.3 has another issue with browser support, that post-auth handshake situation | 14:20 |
| xnox | ahasenack: it seems like we are about to do a quite a fat apache2 update of core & mod_ssl then | 14:20 |
| ahasenack | that we can "fix" by capping to 1.2 | 14:20 |
| xnox | ahasenack: right, so capping would fix that bit only, but not everything. | 14:20 |
| ahasenack | the timeout is still there | 14:21 |
| xnox | yes, timeout / long delay got fixed in the refactor patch series | 14:21 |
| xnox | ahasenack: what about eoan? i guess it's also still broken? | 14:21 |
| ahasenack | xnox: in this bug the commenter says it's fixed: https://bz.apache.org/bugzilla/show_bug.cgi?id=62691#c5 | 14:21 |
| ubottu | bz.apache.org bug 62691 in mod_ssl "OpenSSL 1.1.1 and client-certificate renegotiation causes 1 minute delay" [Normal,Resolved: fixed] | 14:21 |
| xnox | yeap that. | 14:21 |
| ahasenack | the 1.3 patch is fully in 2.4.39 | 14:21 |
| ahasenack | which we don't have in eoan, because of the dbeian freeze | 14:22 |
| xnox | when i looked at backporting that, to bionic it looked akward. | 14:22 |
| ahasenack | I was just discussing this with the team this week, if we should go ahead of debian for some packages | 14:22 |
| xnox | ahasenack: it's not unusual for us to do that during a freeze. | 14:22 |
| xnox | ahasenack: and/or ask debian to upload things into experimental for us to merge/sync from | 14:22 |
| ahasenack | xnox: I haven't tried eoan. I stopped at disco while still trying to understand the issues at play, differenciating the timeout from the tls v1.3 post-auth handshake issue | 14:23 |
| ahasenack | disco+ can be tested if we disable tls 1.3 | 14:24 |
| ahasenack | I can do that | 14:24 |
| ahasenack | just need to be careful, I'm trying multiple things at the same time | 14:24 |
| ahasenack | and certificate auth quickly gets messy | 14:24 |
| xnox | indeed | 14:24 |
| paride | ahasenack, true; I'm trying to replicate your setup from the pastebin | 14:25 |
| ahasenack | yeah, it's a bit raw | 14:25 |
| ahasenack | the reqtimeout change, for example, | 14:25 |
| ahasenack | with that module disabled, the connection doesn't complete, it stays stuck | 14:26 |
| ahasenack | and I saw in another comment in one of these multiple bugs that 2.4.39 has an extra setting in that module specifically for ssl handshakes | 14:26 |
| ahasenack | which one user was hoping to use as a workaround | 14:26 |
| xnox | hmmmm | 14:27 |
| xnox | ahasenack: rebuild apache against openssl 1.0.2 | 14:27 |
| ahasenack | hmmm | 14:33 |
| ahasenack | not wanting to get hopes up | 14:33 |
| ahasenack | but I think I found a patch that worked | 14:33 |
| teward | xnox: fwiw | 14:33 |
| teward | https://bugs.launchpad.net/ubuntu/+source/kopano-webapp/+bug/1834052 | 14:33 |
| ubottu | Launchpad bug 1834052 in kopano-webapp (Ubuntu) "autopkgtest failures: Chromium-Related in Tests" [Medium,In progress] | 14:33 |
| teward | regarding the badtest | 14:33 |
| ahasenack | https://github.com/apache/httpd/commit/bbedd8b80e50647e09f2937455cc57565d94a844 | 14:33 |
| teward | xnox: just to mention i noticed the same problem when nginx got stuck as well | 14:34 |
| teward | i've asked in -release for it to either be ignored or badtested several times with E:NoResponse | 14:34 |
| ahasenack | yea, that patch worked | 14:37 |
| ahasenack | xnox: paride: https://github.com/apache/httpd/commit/bbedd8b80e50647e09f2937455cc57565d94a844 | 14:37 |
| ahasenack | I'll ask for people to test the ppa I have | 14:37 |
| ahasenack | https://launchpad.net/~ahasenack/+archive/ubuntu/apache2-client-cert-1833039 | 14:38 |
| paride | ahasenack, the description and comments sound very promising | 14:38 |
| ahasenack | it fixed my test case at least | 14:39 |
| ahasenack | tried multiple times: package from distro, fail/timeout; upgrade to ppa, works | 14:39 |
| xnox | ahasenack: that looks ok | 14:45 |
| xnox | ahasenack: but please test it in all apache mode. | 14:46 |
| ahasenack | which modes do you mean? | 14:46 |
| xnox | ahasenack: i.e. forking / threading / blocking / non-blocking "worker" engine stuff. => not sure about terminology, but does that make any sense at all? | 14:46 |
| ahasenack | ah, mpm | 14:46 |
| ahasenack | given the setup intructions I have, I could even add a dep8 test for this probably, but that would take more time | 14:47 |
| xnox | ahasenack: there are cases where unsetting auto_retry may result in things not consumed right (hang) if the app doesn't know how to handle the SSL read/write_more_wanted error codes. | 14:47 |
| ahasenack | well, that is committed upstream already | 14:47 |
| xnox | ahasenack: just restart the server locally with one vs the other engine. should be good enough. | 14:47 |
| ahasenack | I could check if there were follow-up commits | 14:47 |
| xnox | ahasenack: true, just thinking if it has more commit deps or follow-ups => yes that. | 14:48 |
| ahasenack | ok | 14:48 |
| xnox | (you are on track there) | 14:48 |
| ahasenack | maybe it's not even the auto-retry that fixed it, the other bit of that commit looks suspiscious | 14:49 |
| ahasenack | " For OpenSSL >=1.1.1, turn on client cert support " | 14:49 |
| ahasenack | the autoretry could be specific to tls v1.3 | 14:49 |
| ahasenack | anyway | 14:50 |
| teward | xnox: do we want to push any Ubuntu level changes to fix the tests in kopano-webapp so we don't need to badtest it? oSoMoN did some debugging and found it's specifically due to passing a log-path arg to chromedriver (and snap isolation being the problem) | 14:53 |
| teward | rather than just badtesting the tests | 14:53 |
| teward | at least, until Debian does something about the test ( oSoMoN made a Pull Req in Debian to fix the test, but Debian is frozen so...) | 14:53 |
| xnox | teward: if there is a fix, i'm happy to upload it into ubuntu. | 15:11 |
| xnox | teward: link? | 15:11 |
| teward | xnox: https://salsa.debian.org/giraffe-team/kopano-webapp/merge_requests/1/diffs | 15:12 |
| teward | it requires alteration to d/tests/test_webapp.py | 15:12 |
| teward | but just adjusting the service_args | 15:12 |
| teward | author is oSoMoN | 15:12 |
| xnox | ack | 15:12 |
| teward | xnox: I can push it in also (yay for coredev) but wanted to check BEFORE making any changes | 15:12 |
| xnox | ahasenack: yeah that other bit, is weird. | 15:12 |
| xnox | teward: it looks harmless, go for it. | 15:13 |
| teward | ack | 15:13 |
| teward | .. bleh where'd i put the code... | 15:13 |
| xnox | teward: as long as, like we don't collect the log from that path. Or like we assert on stderr and without the log, it will start producing stderr. | 15:13 |
| teward | ... oh that's right it was in my tmpfs *derp* | 15:13 |
| teward | xnox: AFAICT that's not even a retrievable artifact after autopkgtests have run | 15:13 |
| teward | my guess is it'll spit out to stdout/stderr | 15:13 |
| teward | but oSoMoN would have details there | 15:14 |
| Laney | test it yourself | 15:14 |
| teward | xnox: that is, however, the reason chromedriver is crashing | 15:14 |
| Laney | don't blindly upload | 15:14 |
| teward | Laney: i am testing it - slowly ;) | 15:14 |
| * teward is currently stuck in a "Downloading files" state | 15:14 | |
| * Laney sends some bandwidth over in the post | 15:19 | |
| Laney | would be good if the installing snap stage showed progress | 15:22 |
| teward | indeed | 15:23 |
| teward | Laney: i'm running the autopkgtest locally, it's slow only because of the Internet being stupid. | 15:23 |
| teward | it's the uplink speed here there's a lot of visitors on site too so it breaks things. and apparently my LXD image for Eoan autopkgtests is broken soooo..... i'mma have to rebuild it. | 15:25 |
| * teward rebuilds the LXD image | 15:25 | |
| * teward runs the autopkgtest | 15:27 | |
| Laney | you might have some trouble installing the snap there | 15:28 |
| Laney | (that's the armhf problem) | 15:28 |
| teward | Laney: amd64 can install it fine | 15:30 |
| teward | my infra's amd64 | 15:30 |
| teward | the amd64 failure is due to log-path and snap confining | 15:30 |
| Laney | it is not an arch problem, it is a VM vs LXD problem | 15:30 |
| teward | Laney: well SO FAR I haven't had the issue in my local snaps | 15:30 |
| teward | s/snaps/LXD tests | 15:30 |
| Laney | it's possible to have lxd containers which can install snaps, sure | 15:31 |
| Laney | the ones we have for autopkgtest can't, though | 15:31 |
| teward | right but i'm talking for my local tests, not the ones in use on the autopkgtest env. | 15:31 |
| teward | if we can pass the amd64/i386 tests we can badtest the armhf still | 15:31 |
| teward | THAT i already asked for :p | 15:31 |
| Laney | I said might | 15:31 |
| teward | and got E:NoReply in -release | 15:31 |
| Laney | and that badtest is already there | 15:32 |
| oSoMoN | teward, it's likely that without a --log-file parameter, the --verbose switch to chromedriver will make it write to stderr, but that should be fine because the autopkgtest already has the allow-stderr restriction | 15:34 |
| teward | oSoMoN: indeed. | 15:35 |
| oSoMoN | https://sites.google.com/a/chromium.org/chromedriver/logging confirms it will write to stderr | 15:35 |
| teward | i don't have a VM to autopkgtest with damn snaps. | 15:35 |
| teward | does autopkgtest have a vmware hook for creating VMs for testing? just curious | 15:36 |
| teward | i have VMware Workstation on this system which is why I ask :| | 15:36 |
| Laney | nein | 15:39 |
| teward | meh qemu it is then. | 15:40 |
| * teward installs into the system | 15:40 | |
| teward | at least i have a local archive mirror so it will do THAT part fast heh | 15:40 |
| Laney | teward: oSoMoN: It's still failing for me fwiw https://paste.ubuntu.com/p/GJJPNB3BwR/ | 15:48 |
| teward | Laney: *with* the patch? | 15:48 |
| Laney | yes | 15:48 |
| teward | oSoMoN: sounds like it's still fubar. | 15:48 |
| oSoMoN | meh | 15:49 |
| teward | still going to get my Eoan qemu autopkgtest env set up | 15:49 |
| Laney | sorry :( | 15:49 |
| teward | but it's slowwwwwwwwwww (56% of 500MB and I'm jacked right into the network) | 15:49 |
| oSoMoN | Laney, passing here, in an eoan amd64 VM | 15:57 |
| Laney | run it with autopkgtest, that's what I've been doing | 15:57 |
| oSoMoN | yes, I’ve run it with autopkgtest -B . -- null | 15:57 |
| oSoMoN | verified failing without the patch, and passing with it | 15:57 |
| Laney | ... | 15:58 |
| Laney | I mean it fails | 15:58 |
| Laney | try the qemu runner | 15:58 |
| Laney | autopkgtest --output-dir out2 --shell-fail --timeout-copy=6000 --apt-upgrade kopano-webapp_3.5.6+dfsg1-1ubuntu1.dsc -- qemu --ram-size=8192 ../reallytemp/autopkgtest-eoan-amd64.img | 15:58 |
| oSoMoN | gotta go now, family waiting for me, but please keep me posted (comments on the bug), thanks! | 15:59 |
| teward | Laney: i'll do so as soon as this thing finishes building the image. It's sit on libc6 triggers :| | 16:03 |
| === ShibaInu is now known as Shibe | ||
| LocutusOfBorg | hello xnox, can I fix borgbackup please? | 16:56 |
| ahasenack | xnox: confirmed disco works with client cert auth with no timeouts if I disable tlsv1.3 in the vhost (SSLProtocol all -SSLv3 -TLSv1.3). With TLSv1.3 I get | 17:03 |
| ahasenack | out of the box, I get https://pastebin.ubuntu.com/p/XdWq2xzq7Z/ (out of the box we have tlsv1.3 enabled) | 17:03 |
| ahasenack | so that will need a different fix, even if it's disabling tlsv1.3 | 17:03 |
| ahasenack | FF needs release 68 to work as far as I can tell, we are at 67 | 17:04 |
| === ricab is now known as ricab|bbl | ||
| === ricab|bbl is now known as ricab | ||
| === Wryhder is now known as Lucas_Gray | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!