| Unit193 | nacc: If it helps, I pasted the log from pbuilder a few days ago, and unstable chroots work. | 00:01 |
|---|---|---|
| nacc | Unit193: ok, good to know | 00:02 |
| === maclin1 is now known as maclin | ||
| cpaelzer | still trying to wrap my head around this bug did we cahnge the default pic/pie behaviour with a recent (maybe gcc) update? | 06:58 |
| cpaelzer | I see some fallout due to "-fPIE -pie" being dropped and replaced by "-specs=/usr/share/dpkg/no-pie-compile.specs" | 06:59 |
| cpaelzer | at least that is how it seems so far, still debugging | 06:59 |
| cpaelzer | or any changes to what hardening=+all does maybe | 06:59 |
| cpaelzer | I thought that the move was still towards pie | 07:03 |
| cpaelzer | maybe this package drives dpkg/debhelper nuts t generate the wrong options | 07:04 |
| === maclin1 is now known as maclin | ||
| cpaelzer | ok down to two things "DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags --get CFLAGS" really looses -fPIE | 07:32 |
| cpaelzer | maybe assumed to be default without stated now? | 07:32 |
| cpaelzer | the other thing seems package specific and more debuggin | 07:32 |
| cpaelzer | g | 07:32 |
| infinity | cpaelzer: Yes, -fPIE is default on all arches. It's not "losing" PIE. | 08:02 |
| cpaelzer | thought so | 08:06 |
| cpaelzer | only the explicit arg is lost which was a red herring for a bit | 08:06 |
| cpaelzer | I found the issue deeper down due to no-pie-compile.specs now generated by hardening=+all,-pie | 08:06 |
| cpaelzer | in my case package A (net-snmp) sets -pie and pakage B (nut) collects the build options of A for plugin builds | 08:07 |
| cpaelzer | but they fail as they pass CFLAGs to all builds, but LDFLAGs only to some | 08:07 |
| infinity | cpaelzer: Ahh, yes. CFLAGS and LDFLAGS both need to be pulled from dpkg-buildflags if you're doing one. | 08:08 |
| cpaelzer | leading to binaries with no-pie-compile.specs but subsequent links without "no-pie-link.specs" | 08:08 |
| infinity | cpaelzer: Mismatching them will lead to a very bad time. | 08:08 |
| cpaelzer | exactly that I'm in | 08:08 |
| cpaelzer | need to fix the package as it is deep in the auto-generated makefiles, not broken on our side really - we are only the trigger by behaving slightly different | 08:09 |
| cpaelzer | IMHO it was "wrong" all the time just not breaking anything yet | 08:09 |
| cpaelzer | infinity: you'll love this quote "In any case, CFLAGS are only -I options, so there is no harm" | 08:09 |
| cpaelzer | from the broken makefile :-) | 08:09 |
| infinity | cpaelzer: Well, other option is to just explictly state "CFLAGS=$(dpkg-buildflags --get CFLAGS -fno-pie -no-pie)" and similar for LDFLAGS, if that's then being embedded in some pkgconfig file later or something. | 08:10 |
| infinity | cpaelzer: And yes, I've run into similarly broken makesfiles (both from upstreams, and broken debian/rules). I guess, to be fair, pie and pic are on a very short list of options where compiler and linker have to agree. | 08:11 |
| infinity | cpaelzer: So I don't mind educating people when they mess it up. The real annoyance is when they argue. :P | 08:11 |
| === maclin1 is now known as maclin | ||
| ginggs | tsimonq2: f.y.i. nodejs 6.11.2 is now in debian unstable and can be merged | 08:33 |
| tsimonq2 | ginggs: ack | 08:35 |
| tsimonq2 | ginggs: I'll have a patch for you as soon as I can, I need a sponsor ;) | 08:37 |
| ginggs | tsimonq2: i tested a merge of 6.10.2 some weeks ago in my PPA, if it helps - i'll happy to sponsor! | 08:41 |
| tsimonq2 | ginggs: Ok :D | 08:46 |
| tsimonq2 | ginggs: Let's see how the build goes: https://launchpad.net/~tsimonq2/+archive/ubuntu/universe-upload-testing/+packages | 08:49 |
| cpaelzer | can building with gcc7 affect the c++ symbols exported? | 09:02 |
| cpaelzer | I guess so | 09:02 |
| cpaelzer | but they are so unreadable ... | 09:02 |
| === maclin1 is now known as maclin | ||
| tsimonq2 | cpaelzer: Yep, sometimes there's optional templinst symbols that either appear or go "MISSING" | 09:07 |
| tsimonq2 | cpaelzer: Also, c++filt ftw | 09:07 |
| cpaelzer | yeah it already has a few templinst | 09:08 |
| cpaelzer | might just be more now or some not yet tracked | 09:08 |
| cpaelzer | OTOH what broufht me to look were the missing symbols as it broke the check | 09:08 |
| cpaelzer | and reading/checking if that might be an issue is next to impossible with the names they have | 09:10 |
| cpaelzer | newer came by c++filt | 09:10 |
| cpaelzer | need to take a look | 09:10 |
| cpaelzer | ah yeah looks good | 09:12 |
| cpaelzer | thanks tsimonq2 | 09:12 |
| === lexruee__ is now known as lexruee | ||
| tsimonq2 | cpaelzer: You're welcome, let me know if you need any assistance with symbols mangling (I've learned quite a bit from Qt packaging) :) | 09:13 |
| cpaelzer | tsimonq2: to me it appears they are rather trimmed than mangled-names - what do you think? http://paste.ubuntu.com/25324531/ | 09:15 |
| cpaelzer | at the same shlibs diff there are two new templates showing up - I'd almost think gcc7 outputs them slightly different so that they are now more "readable" | 09:16 |
| cpaelzer | but I'd loke to prove | 09:16 |
| tsimonq2 | cpaelzer: Could you get a paste of the new ones? | 09:17 |
| cpaelzer | already preparing | 09:17 |
| cpaelzer | http://paste.ubuntu.com/25324539/ | 09:17 |
| cpaelzer | those can at least be demangled - let me try the tool you recommended | 09:17 |
| cpaelzer | oh yeah | 09:17 |
| cpaelzer | that seems to match | 09:17 |
| cpaelzer | need to this more than with eyes on console now | 09:18 |
| cpaelzer | please let me know what you think tsimonq2 if that seems odd to you | 09:18 |
| tsimonq2 | cpaelzer: Yeah it does seem to match pretty well | 09:20 |
| cpaelzer | well then let me fix that and make them replace the old ones in-place | 09:22 |
| cpaelzer | thanks for your hint on c++filt | 09:22 |
| cpaelzer | that serves well as "prove" on the reason of the change | 09:22 |
| tsimonq2 | cpaelzer: I have this bookmarked and it might help in general with symbols :) https://pkg-kde.alioth.debian.org/symbolfiles.html | 09:23 |
| cpaelzer | I think I read that in the past when I had fun in dpdk with that | 09:23 |
| cpaelzer | thx | 09:23 |
| tsimonq2 | yw :) | 09:23 |
| === zyga-ubu1tu is now known as zyga-ubuntu | ||
| cpaelzer | slangasek: I saw your collectd upload broke on something around dpdk - let this be my problem, I'll ping you with a solution | 10:23 |
| ginggs | tsimonq2: for nodejs i think you might need debian/patches/fix_sslv3_test.patch from my PPA | 11:12 |
| LocutusOfBorg | acheronuk, do you plan to have a look at qtwebkit-opensource-src on i386/armhf? | 11:31 |
| LocutusOfBorg | some symbols sadness | 11:31 |
| LocutusOfBorg | I can do it, but I think I'll just make things worse, since I don't know how to deal with them :) | 11:31 |
| acheronuk | KDE stuff I am ok with. The qt packaging, I have only touched briefly on, and have not had much to do with this time. so tsimonq2 or mitya57 are the people I think | 11:33 |
| LocutusOfBorg | tsimonq2, is asleep :) | 11:34 |
| LocutusOfBorg | I see they are ~10 symbols changed, I think I can do it, but I don't know which tool they use to do the magick, I can do it manually but I'm not sure it is error-prone | 11:34 |
| acheronuk | bah. so much for his 'sleep is for the weak' :P | 11:35 |
| acheronuk | I guess still this? https://pkg-kde.alioth.debian.org/symbolfiles.html | 11:36 |
| acheronuk | 26 MB build log is killing my browser! | 11:40 |
| LocutusOfBorg | acheronuk, you can wget and tail -n 200 after gunzip | 11:45 |
| LocutusOfBorg | or I can give you the two patches | 11:45 |
| LocutusOfBorg | I'm trying the command right now | 11:46 |
| LocutusOfBorg | lets see | 11:46 |
| acheronuk | I'd rather not touch it myself and wait a few hrs | 11:47 |
| acheronuk | but if you think your result looks sane, then fair enough | 11:48 |
| LocutusOfBorg | pkgkde-symbolshelper patch -p libqt5webkit5 -v 5.9.1 < ../buildlog_ubuntu-artful-armhf.qtwebkit-opensource-src_5.9.1+dfsg-2_BUILDING.txt | 11:48 |
| LocutusOfBorg | this fails | 11:48 |
| LocutusOfBorg | fails in applying patches | 11:48 |
| acheronuk | I normally grab all the logs, even the passes and they help | 11:49 |
| LocutusOfBorg | I'll try the old fashioned manual way instead | 11:50 |
| acheronuk | then do 'pkgkde-symbolshelper batchpatch -v 5.9.1 ../buildlog_ubuntu-artful*' | 11:50 |
| LocutusOfBorg | ah ok | 11:51 |
| acheronuk | which compares and confirms, and makes exceptions etc on some arches, based on what happened overall | 11:51 |
| acheronuk | but think I only tried with Qt once ever | 11:51 |
| acheronuk | which has some extra stuff for marking private symbols at the least | 11:52 |
| === freyes__ is now known as freyes | ||
| * acheronuk is away for now | 11:55 | |
| LocutusOfBorg | tsimonq2, please do it, I'm lost | 12:02 |
| LocutusOfBorg | :) | 12:02 |
| cpaelzer | slangasek: I have a working fix complete, will report upstream and provide you with a debdiff so you can upload this fix to artful | 12:03 |
| cpaelzer | slangasek: I don't want to mess with your "potential" uploads you have in queue for that but I don't know of | 12:03 |
| cpaelzer | slangasek: just need to report and polish the patch headers to be correct | 12:03 |
| cpaelzer | slangasek: bug 1711120 is ready for you to pick the debdiff from if you agree with the solution | 12:45 |
| ubottu | bug 1711120 in collectd (Ubuntu) "dpdk subset fails to configure correctly on i386" [High,Triaged] https://launchpad.net/bugs/1711120 | 12:45 |
| xnox | bdmurray, do you remember where "incomplete language support" code lives? and which packages it installs, etc? i think i need to fix cjk languages to install qt4-fcaitx for us to drop qt4 from main. | 12:46 |
| xnox | bdmurray, or e.g. i could go easier route and make qt4 gui or some such pull in fcaitx as a recomends. | 12:46 |
| bdmurray | xnox: I think language-selector-gnome puts a file somewhere so update-notifier notifies you about the incomplete support | 14:43 |
| powersj | rbasak: nacc: when I run `apt show <package>` should the "Supported" field on an LTS always say 5y? | 15:11 |
| powersj | clear | 15:11 |
| powersj | woops lol | 15:11 |
| nacc | powersj: LP: #1574670 | 15:12 |
| ubottu | Launchpad bug 1574670 in update-manager (Ubuntu Xenial) "ubuntu-support-status returns inaccurate information" [High,Confirmed] https://launchpad.net/bugs/1574670 | 15:12 |
| nacc | powersj: for context, if i had to guess | 15:12 |
| nacc | slangasek: --^ is someone from foundations working that? | 15:13 |
| powersj | nacc: yeah someone filed LP: #1710721 looks to be similar | 15:14 |
| ubottu | Launchpad bug 1710721 in libsdl1.2 (Ubuntu) "This packages have the wrong timeframe set for the xenial LTS release" [Undecided,New] https://launchpad.net/bugs/1710721 | 15:14 |
| nacc | powersj: yeah, i'd dupe it | 15:18 |
| rharper | slangasek: hi, was looking at the artful cloud server images at the locales present, and I see both C.UTF-8 and en_US.UTF-8 present (http://paste.ubuntu.com/25326237/) ; if we already have the en_US.UTF-8 generated, is there a need for the C.UTF-8 as well? also, other than the directory presence (/usr/lib/locale/C.UTF8) is there a way to know if C.UTF8 is available? I though that localedef --list might show it, bu | 15:19 |
| rharper | t it doesn't | 15:19 |
| xnox | bdmurray, ack! thanks. | 15:31 |
| slangasek | cpaelzer: cool, thanks, the dpdk i386 failure was the last thing I hadn't figured out. I'll upload that straightaway! You've forwarded this to upstream? (Debian upstream or upstream upstream?) | 15:33 |
| slangasek | nacc: ubuntu-support-status returns inaccurate information because the metadata in the archive is incorrect; this is on infinity to solve | 15:36 |
| cpaelzer | slangasek: yes collectd upstream | 15:37 |
| cpaelzer | slangasek: the issue is in the branch | 15:37 |
| cpaelzer | linked | 15:37 |
| slangasek | rharper: C.UTF-8 is always available on Ubuntu and we should be using that intsead of en_US.UTF-8, and we should DROP en_US.UTF-8 as a default locale in artful and forward | 15:37 |
| cpaelzer | I'll make a note to check build and migration in a-p tomorrow | 15:37 |
| rharper | slangasek: yes, and shouldn't /etc/default/locale have LANG=C.UTF-8 or is that not the right thing to do ? | 15:38 |
| rharper | I do see that locale -a shows C.UTF-8 ; so we can always check for that; | 15:38 |
| slangasek | rharper: we do need to somewhere select C.UTF-8 as the runtime locale, yes | 15:39 |
| slangasek | rharper: /etc/default/locale is an appropriate place for it | 15:39 |
| rharper | IIUC, the locale-gen tooling would never generate a C.UTF-8 (it's part of glibc , i think) ? | 15:39 |
| nacc | slangasek: ok, are you ok if i put that comment in the bug? | 15:41 |
| slangasek | nacc: I'm certainly ok with it, it's not me you're pointing the finger at ;) | 15:50 |
| nacc | infinity: --^ :) | 15:51 |
| nacc | slangasek: ack | 15:51 |
| ricotz | hello, is there any chance to force firefox to the artful release pocket? https://launchpad.net/ubuntu/+source/firefox/54.0+build3-0ubuntu1 | 16:09 |
| nacc | ricotz: well, it failed to build on a few archs, it seems like? | 16:12 |
| nacc | chrisccoulson: --^ I assume is looking into it | 16:12 |
| ricotz | nacc, I know, and no, he is not looking into it | 16:13 |
| nacc | ricotz: i see | 16:13 |
| nacc | ricotz: is it a rustc issue? | 16:14 |
| ricotz | nacc, no | 16:15 |
| ricotz | several buildsystem and (smaller) source issues | 16:15 |
| ricotz | I am hoping firefox 56 will be in a better shape | 16:15 |
| chrisccoulson | it's the armhf failure that stops it from migrating. The other architectures aren't blocking it | 16:15 |
| nacc | chrisccoulson: ah ok | 16:15 |
| nacc | chrisccoulson: ah yes, i see that now | 16:15 |
| ricotz | chrisccoulson, is this already a webrtc failure there? | 16:16 |
| chrisccoulson | It's blocked on arm because it just crashes at startup, which causes the startup cache compilation to fail | 16:16 |
| nacc | heh, that message isn't too helpful | 16:16 |
| nacc | mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation | 16:16 |
| chrisccoulson | Firefox 55 doesn't build a startup cache, so it builds ok now. But it still crashes at startup | 16:16 |
| ricotz | chrisccoulson, still force it into release | 16:18 |
| ricotz | I guess having 50.1.0 on the iso is quite something | 16:19 |
| seb128 | ricotz, try arguing with infinity that having firefox outdated is a bigger issue than not having it working on armhf | 16:20 |
| seb128 | I tried that before | 16:20 |
| seb128 | he seems to disagree, so somebody needs to eventually fix firefox | 16:20 |
| ricotz | we can deal with those failures again with 55 / 56 | 16:20 |
| seb128 | as I said I'm not the one to convince | 16:21 |
| ricotz | seb128, you pinged him already ;) | 16:25 |
| seb128 | ricotz, right, and you think that's going to be enough to convince him? ;-) | 16:25 |
| ricotz | at least to read | 16:25 |
| seb128 | yeah, let's see | 16:25 |
| * rbalint looking for sponsor for LP: #1709726 | 16:37 | |
| ubottu | Launchpad bug 1709726 in akonadi (Ubuntu) "Breaks reverse build-dependencies by embedding build-time std exception header path" [Undecided,Confirmed] https://launchpad.net/bugs/1709726 | 16:37 |
| LocutusOfBorg | rbalint, thanks! | 16:43 |
| cpaelzer | slangasek: collectd complete, thanks for the upload | 17:40 |
| cpaelzer | slangasek: and on your Deb question - my co-maintainer on dpdk is watching the PR | 17:40 |
| cpaelzer | slangasek: since he has no FF ahead he can be more relaxed to pick the final fix without the extra hop including the suggestedone we did for now | 17:40 |
| slangasek | cpaelzer: excellent | 17:40 |
| rharper | slangasek: one follow-up; locale-gen --lang C.UTF-8 returns an Error, 'C.UTF-8' is not a supported language or locale; is that expected? and if someone in cloud-init passes us a locale: C.UTF-8 , currently we just call locale-gen ; so we'll need to fix that up if that's expected behavior of locale-gen | 17:42 |
| * tsimonq2 stretches | 18:01 | |
| tsimonq2 | LocutusOfBorg: ack, will do | 18:01 |
| slangasek | rharper: ah, I thought cloud-init was being fixed to not regenerate already-present locales? | 18:07 |
| slangasek | rharper: locale-gen doesn't support generating C.UTF-8 because it's always shipped in the glibc package | 18:07 |
| rharper | slangasek: is it possible to get those tools (locale-gen and update-locale) to not barf on it (even if it doesn't have to regenerate it) ? | 18:17 |
| === tkamppeter_ is now known as tkamppeter | ||
| rharper | slangasek: cloud-init currently reads the value (if present) in /etc/default/locale, checks if the value in the file matches what it's been told to configure (defaults currently to en_US.UTF-8, we're looking to change to C.UTF-8) and then we call update-locale to update the file; | 18:18 |
| slangasek | rharper: bug report on glibc? but again, I understood from dpb that cloud-init was being changed to avoid regenerating locales when it doesn't need to, which you know categorically you never need to regenerate C.UTF-8, so why are you trying | 18:18 |
| rharper | slangasek: C.UTF-8 stuff is new to me at least, we initially implemented not regenerating the default of en_US.UTF-8 if it was present in the /etc/default/locale file; that value is unset in images today, despite en_US.UTF-8 locale being generated and in the locale-archive file | 18:20 |
| slangasek | rharper: fwiw there was a mail thread about this back end of May that you were cc:ed on where I said C.UTF-8 was the right default for future releases | 18:21 |
| rharper | so, one fix is to have the image set LANG="en_US.UTF-8" in /etc/default/locale; that'll work with cloud-init trunk in artful; if we want to switch to defaulting to C.UTF-8 (which sounds fine to me); I wanted to know how to generate C.UTF-8 (turns out you dont' need to); We can make further changes to cloud-init to not call locale-gen/update-locale if we;ure using C.UTF-8; but was worried that if someone at runtime | 18:22 |
| rharper | were to run either of those tools with LANG=C.UTF-8 in /etc/default/locale; if that would complain | 18:22 |
| slangasek | rharper: so we need an image change to set up /etc/default/locale to a correct default | 18:22 |
| slangasek | is the behavior sane when the locale-gen and update-locale commands are absent? (minimal images) | 18:23 |
| rharper | behavior of what? cloud-init? currently none of the images set a value in /etc/default/locale; and cloud-init still defaults to en_US.UTF-8 (as of today, I'm working on a C.UTF-8 branch now) | 18:24 |
| rharper | if the images switch to setting C.UTF-8 in /etc/default/locale, and I land the C.UTF-8 cloud-init branch, it will skip calling locale-gen/update-locale | 18:24 |
| rharper | and it sounds like, in our path where we'd want to regenerate, we'd never attempt to call locale-regen/update-locale if the LANG value was C.UTF-8, since it's not something that can be regenerated | 18:25 |
| slangasek | rharper: behavior of cloud-init. Minimal images won't have the locales package installed; they don't currently set LANG=C.UTF-8 in /etc/default/locale but they should; if we do those things (including for minimal images on xenial), will cloud-init behave sanely? | 18:25 |
| rharper | slangasek: we'll need the current branch I'm working on to land for C.UTF-8 support; | 18:26 |
| rharper | I should have that up today as I now understand more about C.UTF-8 w.r.t regeneration (or the lack of a need to do so) | 18:26 |
| rharper | slangasek: it does seem odd though that, I cant say 'update-local --locale-file=/etc/default/local LANG=C.UTF-8' ; is there a reason why that shouldn't work ? | 18:27 |
| slangasek | rharper: this is literally the first time I have ever heard of the update-locale command | 18:28 |
| rharper | hehe, me too | 18:28 |
| rharper | I guess we can pass --no-checks | 18:37 |
| rharper | that seems reasonable; though I still feel like if it's a valid LANG setting, the tool's check should accept it | 18:37 |
| rharper | slangasek: is that worth a bug ? | 18:37 |
| slangasek | rharper: yes, I think so | 18:38 |
| rharper | ok | 18:38 |
| rharper | thanks for the help | 18:38 |
| ahasenack | acheronuk: hi, around? | 18:59 |
| ahasenack | LocutusOfBorg: hi, | 19:31 |
| ahasenack | LocutusOfBorg: I caught wind of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868473 | 19:31 |
| ubottu | Debian bug 868473 in dh-acc "dh-acc: Incorrect usage of doit (Dh_Lib)" [Serious,Open] | 19:31 |
| ahasenack | LocutusOfBorg: there is a dep8 test in qca2 that uses dh_acc, and which fails now because of the warning that dh_acc is sending to stderr | 19:32 |
| ahasenack | LocutusOfBorg: http://pastebin.ubuntu.com/25327602/ | 19:32 |
| ahasenack | LocutusOfBorg: you seem to have a patch, is it landing soon? | 19:33 |
| ahasenack | the trail is that my cyrus-sasl2 upload to artful is blocked on that qca2 test failure, and on a kdepim-runtime build failure | 19:33 |
| ahasenack | hm, looks like a new abi-compliance-checker that is in proposed fixes it | 19:45 |
| ahasenack | "test in progress" | 19:45 |
| * ahasenack checks again tomorrow | 19:45 | |
| tsimonq2 | rbasak: Ping, I don't know if you're in a US or UK timezone ;) | 19:51 |
| ahasenack | uk | 19:56 |
| tsimonq2 | ack | 19:56 |
| LocutusOfBorg | ahasenack, exaactly, proposed is the fix | 21:25 |
| ahasenack | nice, thanks | 21:25 |
| nacc | ahasenack: i can rerun your dep8 test with the appropriate srcpkg(s) from -proposed | 22:11 |
| nacc | ahasenack: if you tell me which ones | 22:11 |
| acheronuk | LocutusOfBorg: well, unless someone ignore those libkf5eventviews/4:16.12.3-0ubuntu1 and libkf5calendarsupport/4:16.12.3-0ubuntu1, then it will never get our of -proposed | 22:15 |
| acheronuk | those tests should never run. it's only a bug or glitch in britney that they are | 22:15 |
| acheronuk | ok. those are overridden now. if the armhf tests will just complete, might have a chance of fixed abi-compliance-checker making it to -release | 22:37 |
| Unit193 | nacc: Hiya! | 23:15 |
| nacc | Unit193: hey, let me spin a chroot as promised :) | 23:15 |
| Unit193 | No rush, but just wondered. Danke. | 23:16 |
| nacc | Unit193: what error do you get? | 23:38 |
| Unit193 | http://paste.openstack.org/show/cGj8uRFD3nm0PKN3D9T8/ | 23:51 |
| nacc | Unit193: what was the cmdline for that? | 23:53 |
| Unit193 | Basically: debootstrap --arch=i386 --include=apt --arch i386 --variant=buildd --force-check-gpg --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg artful /var/cache/pbuilder/build/6390 | 23:53 |
| Unit193 | nacc: I'm not sure if I should be annoyed or happy, it appears to be working now... | 23:58 |
| Unit193 | Thanks for fixing it! | 23:58 |
| nacc | heh | 23:58 |
| Unit193 | I'm sorry for wasting your time. | 23:58 |
| sarnold | it felt a bit like something that 'waiting' would fix, but i'm surprised it fixed so quickly :) | 23:59 |
| nacc | yeah, i wonder if it was just the gcc-7 transition/mirror latency/etc. | 23:59 |
| Unit193 | sarnold: I thought so too, but hit it sometime before Aug 13. | 23:59 |
| nacc | glad it works now, regardless | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!