| tsimonq2 | @pilot in | 01:05 |
|---|---|---|
| === udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots: tsimonq2 | ||
| tsimonq2 | This is more of an experiment for now, but I'm following what cyphermox set out in his email: https://lists.ubuntu.com/archives/ubuntu-devel/2018-September/040501.html | 01:05 |
| tsimonq2 | Maybe the bot can eventually be updated to distinguish +1 vanguards vs Patch Pilots but I'll also be looking at the sponsorship queue. | 01:06 |
| tsimonq2 | Ah, I see not much SRU processing lately but it's understandable given the state of the development cycle... | 01:08 |
| sarnold | woah a patch pilot | 01:08 |
| sarnold | this takes me back :) | 01:08 |
| tsimonq2 | Yeah, hehe | 01:09 |
| tsimonq2 | sarnold: If you're around, how's this apparmor profile look? bug 1788102 | 01:21 |
| ubottu | bug 1788102 in ntpsec (Ubuntu) "ntpsec's ntpd fails to write ntp.drift file because of apparmor" [Undecided,Confirmed] https://launchpad.net/bugs/1788102 | 01:21 |
| tsimonq2 | I don't personally know enough about apparmor so your opinion on it either way would be welcome. | 01:21 |
| sarnold | tsimonq2: lgtm, richard's usually on the ball | 01:21 |
| tsimonq2 | Cool. | 01:22 |
| tsimonq2 | sarnold: Uploaded to the queue, thanks! | 01:25 |
| sarnold | tsimonq2: woot, thanks :) | 01:25 |
| === giraffe is now known as Guest86558 | ||
| tsimonq2 | @pilot out | 02:05 |
| === udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots: | ||
| tsimonq2 | https://lists.ubuntu.com/archives/ubuntu-release/2018-October/004611.html | 02:05 |
| === zhongjun2_ is now known as zhongjun2 | ||
| cyphermox | tsimonq2: I did ask how we could update the bot code to distinguish (or replace, since patch pilot is largely a dead thing) | 04:15 |
| tsimonq2 | cyphermox: I don't even know where the code is for it. :/ | 04:15 |
| === lan3y is now known as Laney | ||
| === _hc is now known as M_hc_[m] | ||
| === M_hc_[m] is now known as M_hc[m] | ||
| coreycb | doko: i know python3.7 will be the default in the next ubuntu release, but out of curiosity will it also have python3.6 available? | 12:18 |
| xnox | coreycb, no, the plan is python3.7 only | 12:21 |
| xnox | coreycb, for 19.04 that is. | 12:21 |
| coreycb | xnox: ok thanks, and yes 19.04 is what I was curious about | 12:22 |
| coreycb | xnox: just formulating an email upstream | 12:22 |
| xnox | coreycb, does that have some implications? as in, why are you asking? =) | 12:22 |
| coreycb | xnox: well i'm going to try to enable py37 tests upstream. there might be some push back because not not all tests are passing yet from recent py36 enablement. | 12:24 |
| coreycb | xnox: looks fairly trivial to enable, but a decent amount of busy work across many projects. getting fixes may be another story. hopefully i can convince them it needs to be enabled and get community focus on fixes soon. | 12:25 |
| === cpaelzer_ is now known as cpaelzer | ||
| rbasak | juliank: thank you for the version regression report. I wonder if we could perhaps add this to the pending sru report? Or should it be separate? | 12:51 |
| juliank | rbasak: I don't think it's something to consider in the SRU reporting. It also applies to security updates, and for those, there sometimes are valid reasons to temporarily have the new release in a stable release first | 12:52 |
| juliank | but not sure | 12:54 |
| xnox | well, a new archive report to be run and published on ~ubuntu-archive | 12:55 |
| rbasak | I just wondered about when someone will look. | 12:55 |
| xnox | juliank, you do know ubuntu-archive-tools repository? | 12:56 |
| rbasak | If left to the AAs then I suppose they have their own separate reports to check for all the other wrong things too | 12:56 |
| juliank | xnox: yes | 12:56 |
| xnox | add it there =) | 12:56 |
| juliank | I think optimally it should also query security thing and check if any CVEs are fixed in older releases, but not in newer. | 12:56 |
| juliank | xnox: I will soon | 12:57 |
| juliank | rbasak: I'm not sure if there's anything actionable for the SRU team except for not releasing an SRU until it has a higher version number in later releases | 12:57 |
| rbasak | juliank: it might be useful to block releasing to updates (from proposed). | 12:58 |
| juliank | Maybe britney could check that automatically | 12:58 |
| rbasak | I know I've accepted from the queue into proposed before with the caveat of "not in updates until fixed in <future>" | 12:58 |
| rbasak | There is talk of having britney do the release to updates, for all the extra britney checking too. | 12:59 |
| xnox | it's not actually something we'd want to block on. | 12:59 |
| xnox | it is legit for something to be good in one release, and stuck in proposed in another, as long as we sort it out eventually. | 13:00 |
| xnox | a separate report for now, would be good enough. | 13:00 |
| rbasak | xnox: I'm talking about something different - when the fix isn't in a future release (not even proposed), but the SRU is uploaded to a previous release. | 13:00 |
| juliank | the problem if the versioning in an SRU is wrong though, and it's in proposed, is that you can't go back to an older version number AFAIUI | 13:01 |
| xnox | rbasak, which is nothing to do with this report.... cause it acts on what's accepted, not what's proposed. | 13:01 |
| juliank | i.e. I upload -ubuntu0.1 to bionic, then -ubuntu0.16.04.1 to xenial | 13:01 |
| juliank | I'd have to upload -ubuntu0.0.16.04.1 to xenial to fix the mess I created | 13:02 |
| rbasak | Oh, I see. | 13:02 |
| juliank | xnox: It does show you if the new release has a proposed one though | 13:02 |
| juliank | i.e. those would be greyed out a bit | 13:02 |
| juliank | in html | 13:02 |
| xnox | but like it doesn't look at the queue | 13:02 |
| juliank | yeah | 13:03 |
| tsimonq2 | rbasak: Britney doing the release to updates> Oooh, I'm curious about that. Autopkgtests and all? Or just a seven day aging period plus bug tags being in order? Is there discussion about this somewhere that I could read up on? :) | 13:05 |
| rbasak | tsimonq2: AFAIK, it's just something people have mentioned should happen. I don't know that anyone's working on it, and so I don't believe there are any other details. | 13:07 |
| xnox | tsimonq2, it is running, and does report adt regressions, but i don't think we actually use "unblock" to release sru | 13:08 |
| tsimonq2 | That would be cool. | 13:08 |
| rbasak | Hmm. On the lines of something being in development -proposed, I have a case where something is in development unapproved but with an SRU ready to go. | 13:16 |
| rbasak | I presume that's OK as well, but it'd be nice to see it in cosmic-proposed since then it's "guaranteed" to land. | 13:17 |
| rbasak | I wonder if block-proposed and an accept is appropriate? | 13:17 |
| rbasak | Or easier if a release team member could review systemd unapproved in Cosmic please? | 13:18 |
| rbasak | xnox: do you have a git tree or similar for systemd anywhere? Trying to match up pieces of your delta with the changelog. | 13:31 |
| rbasak | xnox: on that point, given you don't mention the patch names in the changelog, it'd be nice if you used Bug-Ubuntu dep3 headers to help match things up. | 13:31 |
| xnox | rbasak, no, we don't use dep3 headers, we use git-buildpackage quilt to manage them | 13:36 |
| xnox | the git is at | 13:36 |
| xnox | rbasak, https://code.launchpad.net/~ubuntu-core-dev/+git/systemd | 13:37 |
| xnox | and it is indeed broken by change by commit, and changelog is git-dch managed too | 13:37 |
| rbasak | xnox: thanks! Just as I've finished breaking down your upload manually :-/ | 13:37 |
| rbasak | I'm not sure that's a reason to not have dep3 headers though | 13:38 |
| xnox | (the no-dep3 thing kind of comes from debian.... cause their patchset is large, and then we add things ontop and interweb upstream cherrypicks) | 13:38 |
| rbasak | You can add dep3 to patches that you add though, surely? | 13:38 |
| xnox | rbasak, well there are topics, so upstream cherrypicks are first, then debian topic debian-specific-patches and then debian topic UBUNTU- prefix is ubuntu-specific stuff | 13:39 |
| rbasak | eg. debian/patches/core-move-enforcement-of-the-start-limit-into-per-unit-type-code-again.patch has one, just with no Bug-Ubuntu. | 13:39 |
| xnox | but gbp pq import/export doesn't process those | 13:39 |
| xnox | and they don't end up in the changelog | 13:39 |
| xnox | LP: # -> do | 13:39 |
| xnox | cause gbp pq, tries to ensure that patches are `git am`ble & `git format-patch`able & dpkg `quilt-applicable` | 13:40 |
| xnox | rbasak, if gbp pq gains dep3 support, that would be nice. | 13:40 |
| rbasak | Yes but AIUI none of that prevents you from adding Bug-Ubuntu dep3 headers | 13:40 |
| rbasak | Put it in the commit message and it'll end up in the quilt patch, no? | 13:41 |
| xnox | i'd still have to put in LP: #, as well | 13:41 |
| rbasak | Yes you would. | 13:41 |
| rbasak | As you would when adding dep3 headers and not using git. | 13:41 |
| xnox | have you heard of DRY?! =) | 13:41 |
| rbasak | All I'm saying is it makes it difficult to review. | 13:41 |
| xnox | LP: # urls are clickable on all ubuntu terminals | 13:41 |
| rbasak | dep3 solves the problem, allowing reviewers to match things up. | 13:42 |
| xnox | do you not use gnome-terminal? | 13:42 |
| rbasak | An LP reference in the changelog doesn't tell me what the corresponding quilt patch is. | 13:42 |
| xnox | i'm not sure how dep3 helps here | 13:42 |
| rbasak | Some people put the quilt patch name in the changelog entries. You do not, which is fine, but then I'd like dep3 to help me match things up. | 13:42 |
| xnox | yeah cause that is only visible in the git repo | 13:42 |
| rbasak | Which I didn't have before, and Vcs-Git doesn't point to it. | 13:43 |
| rbasak | In any case, AIUI, uploads are expected to follow convention and stand on their own without VCS. | 13:43 |
| xnox | sure | 13:43 |
| sforshee | LocutusOfBorg: it turns out that the upstream vboxvideo does not have dependencies on vboxguest like I thought, so we can just disable it | 13:44 |
| sforshee | I've sent patches to start using the dkms drivers again - https://lists.ubuntu.com/archives/kernel-team/2018-October/095882.html | 13:44 |
| sforshee | Odd_Bloke: ^ | 13:44 |
| xnox | cause like our ./debian/git-cherry-pick script which we use for cherrypicking things from upstream, and injecting it in the right place in the quilt stacks doesn't autogenerate stanzas either | 13:45 |
| xnox | as we use plain `git cherry-pick` there | 13:45 |
| * xnox ponders if that can grow "better" referencing integration | 13:45 | |
| rbasak | I don't think it's OK to blame your tooling. As we established, it's trivial for you to add dep3 in your commit messages like everyone else does. | 13:45 |
| rbasak | (AFAIK, everyone else using dep3 currently writes them by hand) | 13:46 |
| xnox | rbasak, the only patch with dep3 i see, was actually contributed to the upload and was not done by me. and doesn't actually follow systemd packaging conventions. | 13:48 |
| xnox | but i tend to take contributions as is, if they apply correctly and work correctly, cause i value their contibutions to systemd packaging. | 13:49 |
| xnox | thus dep3 header in that one patch is exception, in systemd, rather than the norm. | 13:49 |
| rbasak | xnox: my request still stands. Please use dep3 headers when uploading SRUs, since it makes reviewing easier. | 13:52 |
| LocutusOfBorg | sforshee, did you take vboxvideo from which package? | 13:56 |
| LocutusOfBorg | I added a kernel 4.18 patch in 5.2.18 | 13:56 |
| xnox | https://git.launchpad.net/~ubuntu-core-dev/+git/systemd/commit/?id=6a8b3e99b74704b66a5f9422a828f58f532ac3af https://git.launchpad.net/~ubuntu-core-dev/+git/systemd/commit/?id=cc8f39042c5b47bc853b7450f3fe80467dd5897c https://git.launchpad.net/~ubuntu-core-dev/+git/systemd/commit/?id=fd832930ef280c9a4a9dda2440d5a46a6fdb6232 | 13:59 |
| Odd_Bloke | sforshee: \o/ | 14:01 |
| Odd_Bloke | sforshee: When might I expect to see that land? | 14:02 |
| sforshee | LocutusOfBorg: using the upstream vboxvideo still, as in bionic | 14:05 |
| sforshee | Odd_Bloke: can't say for sure, but we'll have to upload it very soon to be in the release | 14:06 |
| sforshee | LocutusOfBorg: I updated the drivers from 5.2.18-dfsg-2 in those patches | 14:07 |
| LocutusOfBorg | ack | 14:11 |
| Odd_Bloke | sforshee: Cool, thanks! | 14:15 |
| rbasak | xnox: the AutomountResult enum in src/core/automount.h doesn't form part of any ABI does it? | 14:56 |
| rbasak | (or API even) | 14:56 |
| rbasak | xnox: same question with {busname,mount,path,service,socket,swap,timer,unit} - it's all the same pattern. | 14:57 |
| xnox | rbasak, internally they are enums/states et.al. externally they are all encoded/decoded/shown as a single string. | 14:58 |
| rbasak | OK, thanks. As long as the numbers are internal :) | 14:59 |
| xnox | rbasak, as per their abi stability guides, they are free to remove/add/change those strings. but it is guaranteed to remain a string. | 14:59 |
| rbasak | Thanks. Handy for you to know the answer without me having to dig :) | 14:59 |
| xnox | the abi is like `is-failed` which knows which strings are "bad" and which ones are "good" | 14:59 |
| xnox | for every unit type. | 14:59 |
| xnox | it's meant to be informational | 15:00 |
| cyphermox | tsimonq2: thanks for looking at slideshow :) | 15:09 |
| tsimonq2 | cyphermox: No problem. :) | 15:10 |
| dgadomski | mwhudson: hi, could you please also release the fix for bug #1749289 to xenial? | 15:40 |
| ubottu | bug 1749289 in ubiquity (Ubuntu Xenial) "Installer stops after pressing Cancel on Select a language screen during OEM install" [Undecided,Confirmed] https://launchpad.net/bugs/1749289 | 15:40 |
| === slangasek is now known as vorlon | ||
| === vorlon is now known as slangasek | ||
| === slangasek is now known as vorlon | ||
| ogra | vorlon, identity crisis ? | 15:50 |
| vorlon | stuck settings in the client that I'm trying to shake loose | 15:50 |
| rbasak | Would it be acceptable in Ubuntu for a package to dynamically add an extra binary package not listed in debian/control through debian/rules? The reason is that I want to keep in sync with Debian but build an extra split out binary package to stay in universe. | 15:55 |
| rbasak | (in Debian this wouldn't happen so I don't think there's an issue there) | 15:55 |
| tsimonq2 | Why is it not possible to list it in debian/control? | 15:56 |
| rbasak | Because it wouldn't be appropriate to build the binary package on Debian. | 15:56 |
| sarnold | wouldn't taht just turn into a delta in debian/rules? | 15:56 |
| rbasak | Yes it would. | 15:56 |
| rbasak | But we do that already in other places, using dpkg-vendor | 15:57 |
| tsimonq2 | Ohh, I catch your drift. | 15:57 |
| rbasak | Means that Debian and Ubuntu build from the same source, which is convenient. Saves doing merges etc. | 15:57 |
| tsimonq2 | That personally sounds doable but I guess I'd defer to an archive admin. :) | 15:57 |
| sarnold | I dislike it, but not enough to be annoying about it. :) | 15:58 |
| tsimonq2 | ^ | 15:58 |
| rbasak | ISTR someone saying that Debian disallowed this. But it might be OK for Ubuntu. The only reason to do this is caused by Ubuntu's main/universe distinction. | 15:58 |
| rbasak | I think the alternatives is for sarnold to +1 our MIR from a security perspective, or to keep doing package merges forever. | 15:59 |
| sarnold | heh, which one? :) | 15:59 |
| rbasak | bug 1781529 | 15:59 |
| ubottu | bug 1781529 in mecab (Ubuntu) "[MIR] mecab" [High,New] https://launchpad.net/bugs/1781529 | 15:59 |
| tsimonq2 | As someone once said, "Policy is your friend. Trust the Policy. Love the Policy. Obey the Policy." so I guess I'd be curious to say if Policy has a specific rule around it. :) | 15:59 |
| sarnold | aha, dunno if I can get there today or not. I didn't sleep well last night :/ | 15:59 |
| rbasak | I'll finish writing my reply. My question was prompted in writing a reply :) | 15:59 |
| sarnold | haha :) | 15:59 |
| tsimonq2 | rbasak: Oh, I just recalled that dbgsym packages aren't mentioned in d/control. | 16:00 |
| tsimonq2 | So while they're "special" packages, it should mean that it's permissible under policy. | 16:01 |
| rbasak | Reply written in the bug. | 16:01 |
| rbasak | vorlon or infinity: ^ please could you tell me if this is acceptable? See bug 1781529 comment 7. | 16:01 |
| ubottu | bug 1781529 in mecab (Ubuntu) "[MIR] mecab" [High,New] https://launchpad.net/bugs/1781529 | 16:01 |
| tsimonq2 | infinity: ^ (since, if I recall correctly, he only gets pings if the message starts with his name.) | 16:02 |
| sarnold | rbasak: very nice reply, thanks :) | 16:03 |
| rbasak | sarnold: thanks. Over to you I guess? If you want to nack the MIR on security grounds, that's fine - we'll find some way, and if we can't, we'll either continue merging or continue without mecab support. | 16:06 |
| vorlon | rbasak: binary packages produced by a source package are expected to be listed in the debian/control shipped in the source package | 16:40 |
| rbasak | vorlon: "expected", or "must"? I'm aware of the expectedness; that's why I'm asking :) | 16:41 |
| vorlon | rbasak: must | 16:41 |
| rbasak | OK, thanks | 16:41 |
| vorlon | it's bad to have packages listed in debian/control that you never build, but that's less bad than building packages you don't list in debian/control; the latter breaks cross-references in the indices | 16:42 |
| rbasak | I could list it in debian/control and then never build it, but then I'd be foisting that on Debian, which seems inappropriate. | 16:43 |
| xnox | vorlon, nvidia-* packages currently shadow each other ;-) | 16:48 |
| vorlon | xnox: yes; which is permitted for the same reason it's permitted for gccs, you shouldn't have to reupload the old package in order for a new package to take over its binaries | 16:49 |
| === dannf` is now known as dannf | ||
| vorlon | mdeslaur: why did woff2 have a no-change rebuild in bionic-security? should we copy it forward to cosmic? (cf juliank's post) | 17:25 |
| juliank | vorlon: he did upload 1.0.2-1build1 to cosmic a few hours or so ago | 17:27 |
| vorlon | ah, well then | 17:27 |
| vorlon | still wondering what the no-change rebuild was for :) | 17:27 |
| juliank | Yeah, it would have been useful to have "for ..." in the changelog | 17:28 |
| sarnold | iirc it was so that we could do a security update on webkit2gtk https://launchpad.net/ubuntu/+source/webkit2gtk/+changelog | 17:30 |
| jbicha | vorlon: we moved woff2 to main | 17:34 |
| vorlon | ah | 17:34 |
| vorlon | moving to main does not require a rebuild, only a pocket copy | 17:35 |
| jbicha | ok, good to know. We don't do it very often :) | 17:35 |
| mdeslaur | vorlon: if you only do a pocket copy, you break ubuntu-support-status | 17:36 |
| vorlon | oh? | 17:36 |
| vorlon | ok | 17:36 |
| mdeslaur | since the installed package on people's systems still comes from universe | 17:36 |
| jbicha | vorlon: if you have time, brotli binaries need to be moved to main in xenial too LP: #1795077 | 17:37 |
| ubottu | Launchpad bug 1795077 in brotli (Ubuntu Xenial) "Backport brotli 1.0.3 to Ubuntu 16.04 LTS" [Medium,Fix committed] https://launchpad.net/bugs/1795077 | 17:37 |
| jbicha | and woff2 (SRU wasn't accepted yet) LP: #1795094 | 17:37 |
| ubottu | Launchpad bug 1795094 in woff2 (Ubuntu Xenial) "Backport woff2 to Ubuntu 16.04 LTS" [Medium,In progress] https://launchpad.net/bugs/1795094 | 17:37 |
| sarnold | jbicha: do we really? I thought webkit2gtk added new toolchain dependencies that meant we can't support it in trusty any longer? | 17:38 |
| jbicha | sarnold: we never announced that webkit2gtk/xenial was unsupported so maybe… | 17:38 |
| jbicha | latest webkit requires gcc6 and no one's volunteered to backport that to xenial yet | 17:41 |
| jbicha | https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement | 17:42 |
| mdeslaur | it's a bit more complicated than that...we can't just backport gcc6 | 17:43 |
| mdeslaur | the stdlibc++ library on xenial is provided by gcc5 | 17:43 |
| jbicha | I admit I don't know what that library means | 17:44 |
| rbasak | coreycb: would you prefer me to wait for neutron in bug 1795424 before reviewing? Or are you happy with releasing bits at a time? | 17:50 |
| ubottu | bug 1795424 in nova (Ubuntu Bionic) "[SRU] queens stable releases" [High,Fix committed] https://launchpad.net/bugs/1795424 | 17:50 |
| rbasak | coreycb: or, given they all get tested together, maybe it's better to wait in the general case? | 17:51 |
| coreycb | rbasak: thanks for taking a look. i'd really like to include neutron as it has some critical bug fixes. | 17:52 |
| coreycb | rbasak: it's all regression tested, i think we can mark the remaining neutron bug as verification-done since it passed regression testing. | 17:53 |
| rbasak | coreycb: there's still two more days left to age for neutron | 17:53 |
| coreycb | rbasak: ah, right. well i think you can hold off and we can get those all released together fri or mon. | 17:55 |
| rbasak | OK, thanks. | 17:55 |
| coreycb | rbasak: thanks | 17:55 |
| rbasak | coreycb: it'll be Mon. We generally don't release on Fridays. | 17:55 |
| coreycb | rbasak: ok makes sense | 17:55 |
| rbasak | juliank: I appreciate the impact statement in bug 1796081 :) | 17:56 |
| ubottu | bug 1796081 in dpkg (Ubuntu Bionic) "dpkg frontend locking" [Undecided,In progress] https://launchpad.net/bugs/1796081 | 17:56 |
| === vorlon is now known as slangasek | ||
| === slangasek is now known as vorlon | ||
| vorlon | jbicha: brotli overrides done | 18:03 |
| jbicha | thanks | 18:04 |
| mwhudson | dgadomski: oh i didn't realize it affected xenial too | 20:51 |
| mwhudson | dgadomski: is it in git for xenial yet? | 20:51 |
| xnox | libtool: compile: mpicxx -DHAVE_CONFIG_H -I. -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include -I../.. -g -O2 -DNDEBUG -DZDOT_RETURN -c _hrr_c0_66.cc -o _hrr_c0_66.o | 21:18 |
| xnox | virtual memory exhausted: Cannot allocate memory | 21:18 |
| xnox | but builds fine in debian.... compiler bug? PIE or some such making it explode? | 21:18 |
| xnox | mwhudson, vorlon, doko - any suggestions on where to go from here? | 21:19 |
| mwhudson | !? | 21:19 |
| mwhudson | xnox: package, architecture, etc? | 21:19 |
| xnox | bagel, all arches | 21:19 |
| xnox | cosmic | 21:19 |
| xnox | did --no-parallel build in xnox/nonvirt ppa and also fails on all arches | 21:20 |
| mwhudson | huh | 21:20 |
| vorlon | yeah, virtual memory exhausted would seem to imply you're out of address space rather than out of physical memory | 21:20 |
| mwhudson | sounds compiler bug-like to me | 21:21 |
| vorlon | and the compiler in question is... mpicxx? | 21:21 |
| mwhudson | what is mpicxx? mpi as in the multi process thing? | 21:21 |
| mwhudson | yes, seems so | 21:21 |
| xnox | yeah, openmpi implementation c++ compiler.... | 21:21 |
| mwhudson | xnox: tried locally? | 21:22 |
| mwhudson | it's a different version of libmpich-dev, 3.3~b2-6 vs 3.3~b2-7build1 | 21:24 |
| xnox | mwhudson, well can't remember now. rerunning build in unstable chroot; then will rerun build in our chroot; then will see if libmpich-dev makes a difference. | 21:24 |
| mwhudson | changes between the versions are trival so it would only be if mpicxx built with gcc-8 is broken or some such fun | 21:25 |
| === vorlon is now known as slangasek | ||
| === slangasek is now known as vorlon | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!