[00:14] Hm. Is anyone looking at the juju-core autopkgtest failure on i386? [00:16] uhm [00:16] teward: UHM [00:16] has anyone looked at the Perl pkgtest failures? [00:16] * tsimonq2 runs [00:16] because that's holding up nginx merge. [00:16] rbasak: sarnold: jgrimm: powersj: ^ ping because relevant to what we're all looking at recently. [00:18] wow that perl sure blocks a lot [00:20] yeah [00:20] it's pretty ugly [00:20] well it's blocking the nginx merge [00:20] and 99% of EVERYTHING [00:21] and ***NOBODY*** has looked at it? [00:21] slangasek: ^ do you know if someone's driving the Perl stuff please? [00:23] oh dear he's not here. [00:23] this is... kinda a critical thing. [00:23] looking at libgnupg-interface-perl, i bet it's a change in behavior for gpg2 [00:23] gnupg2, rather [00:23] teward: Then #ubuntu-release? [00:23] gpg: can't connect to the agent: File name too long [00:23] o_O [00:24] tsimonq2: ? [00:24] teward: "this is... kinda a critical thing." [00:24] tsimonq2: this is the proper channel for this discussion [00:24] slangasek may be away right now, but *someone* will have to look at it [00:24] Fair enough [00:24] esp. if we want pretty much anything to move out of proposed [00:24] * tsimonq2 backs away [00:25] and for devscripts, i suspect maybe also [00:25] debsign: gpg error occurred! Aborting [00:26] oh other way around, that's expected, but it's succeeding instead :) [00:29] blocking 25 packages... that's not 99% of everything [00:29] slangasek: i overemphasized, but i'm tired [00:29] blah [00:29] ohai slangasek :) [00:29] 7 hrs rest in the past 48h :P [00:30] why is nginx blocked by it? is there a perl ABI change? [00:31] slangasek: autopkgtest hangup prevents migration -> zesty from proposed [00:31] the hangup on Perl [00:31] Depends: nginx perl (not considered) [00:31] no, that's not autopkgtest-related [00:31] slangasek: *and* we have dynamically compiled modules that *might* depend on perl ABI changes, if there's anything. [00:31] slangasek: from what I can tell there isn't any issue, but I can't build against proposed right now [00:31] I can *try* the merge [00:32] but it'll be stuck in proposed unless someone overrides [00:32] actually, what *is* the perl changes [00:32] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nginx shows that the new nginx package depends on the new perl; I'm asking why [00:32] slangasek: no clue? [00:33] slangasek: ideally it wouldn't affect anything [00:33] though, with Perl, we have 5.4.1~rc1 to 5.4.1-1, so not sure if that's an ABI change [00:33] (not sure how to check from my phone, which is how I'm IRCing right now) [00:33] well, this doesn't take any special release team knowledge to figure out :) and you'll want to know what the story is, because if there's a perl ABI transition, none of its revdeps are going anywhere anytime soon [00:34] slangasek: i'm not the one who pinged you :P [00:34] I pinged rbasak who then poked. [00:34] unless Proposed was used to build nginx's perl components, of which there *are* some, it shouldn't need to stay held up [00:34] slangasek: btw how'd you come to the conclusion that nginx required the new perl? the .dsc doesn't mention anything perl beyond "Build-Depends: .. libperl-dev .." [00:34] sarnold: update-excuses [00:34] precisely [00:35] that's the thing though; I can't find why or where it would depend upon a new perl vs last year's perl.. [00:35] ah that's why... [00:35] libnginx-mod-http-perl [00:36] which is an upstream module. [00:36] I don't think it wouldn't be able to depend upon a new perl, if the ABI hasn't changed [00:36] but if the ABI has, then all 25 pkgs are screwed until eternity [00:36] and nginx merge will be pushed off to next cycle [00:36] nginx-extras wants to pull in the new perl; but I don't yet see why [00:37] i'm not sure either [00:37] unless proposed somehow leaked into the build env? [00:37] proposed is always part of the build env [00:37] by design [00:38] i know why [00:38] hang on [00:38] dep: perl (>= 5.22.2-1) [x32] [00:38] Larry Wall's Practical Extraction and Report Language [00:38] dep: perl (>= 5.22.2-1+b1) [hurd-i386] [00:38] dep: perl (>= 5.24.1-1) [not hurd-i386, x32] [00:38] oops WOT post. [00:39] slangasek: ^ Debian version string changes, apparently, but that shouldn't have been reflected in the one in proposed [00:39] teward: how exactly is this holding up the nginx merge? [00:39] slangasek: well, if I merge from Debian, it *wants* the new version in the deps [00:39] and will dep fail otherwise [00:39] if I downgrade the deps, that's just adding to the delta [00:39] there is already a version of nginx in -proposed that wants it [00:39] slangasek: and i'm not sure *why* [00:40] because that *packaging* hasn't changed since the last Zesty upload, which was a security fix IIRC [00:40] ok, but why does any of this prevent you from doing the merge and uploading it to -proposed? [00:40] slangasek: i'm not concerned about UPLOADING to proposed [00:40] I'm concerned about it getting into the repo before FF [00:40] that's not how it works [00:40] * teward sighs [00:40] then i need sleep [00:40] because my brain's not working [00:41] (and that's probably the core issue) [00:41] a) -proposed is part of "the repo" b) packages that are uploaded before FF will be shepherded into zesty [00:41] slangasek: see nobody told me that part [00:41] ever [00:41] rbasak: ^ should've :P [00:43] ok. So I suspect what's going on is an adverse interaction with dh_perl, which may not be constructing the right dependency (5.24.1~ vs. 5.24.1) [00:43] hmmm except it specifically lists 5.24.1-1 [00:44] slangasek: which it *shouldn't*, unless something odd happened. I can forcibly change the Perl version for the merge, if necessary. [00:44] s/forcibly/probably forcibly/ [00:44] no, that's not necessary at all [00:44] * infinity scans backscroll a bit. [00:44] I'm only trying to understand if there's a toolchain bug here that we need to fix [00:45] * teward yawns, and goes to get another venti latte with an extra shot of espresso [00:45] FWIW, the gnupg2 "file name too long" failures should only be happening in containers, and it's a known issue we can pass for. [00:45] but I think the right answer is that you should ignore this, do whatever nginx merge is appropriate for 17.04, and let the perl transition shake itself our [00:45] out [00:45] infinity: ok, good to know, i think that's at least one perl 'regression' then [00:46] slangasek: OK, i'm sending a note to the Server list for a call for testing, I have the merge already built in the PPA so I know it builds with non-proposed, and is decent enough to iron out upgrade/install failure cases, of wich more will be fixed if they crop up [00:46] i'll upload tomorrow if nothing major blows up in *my* tests. === tgm4883_ is now known as tgm4883 [00:47] which are queued to autorun on containers in about 6 hours. [00:47] nacc: devscripts looks like the test keyring was made with gpg1, and the testbed has gpg2, so the autoupgrade of the keyring blows up the expected output. Easy fix. [00:48] infinity: ack, seems right [00:49] libembperl-perl looks like a legit failure someone should drill down into. [00:49] And that's the whole list. [00:49] So, gnupg-in-container things we can skip, devscripts should get a testsuite fix, libembperl-perl needs a closer look. [00:50] That doesn't seem terribly sky-is-falling, rant-inducing emergency OMG. [00:50] infinity: And that's what happens when sleep deprivation is a thing. [00:50] ^ [00:50] bed time now for me heh [00:50] good night. [00:51] teward: Night, sleep well. :) [00:51] six minutes after a new coffee? :) [00:51] and gnupg-in-container thing can be skipped by explicitly declaring the test not-for-container [00:51] (which is not how it's spelled, but anyway) [00:52] slangasek: Maaaaybe, but I'd rather tempfail them in hints for now on container arches and look at if we can fix the infra problem that causes it. [00:52] slangasek: It *is* fundamentally a bug, just one that doesn't matter to most people in practice. [00:53] Not super picky on that, though. And it'll "go away" when we use VMs on all arches. [00:54] confirmed that dh_perl is outputting 5.24.1-1 as minver [00:54] for the perl package === monk is now known as Guest63787 [00:57] That's not wrong. [00:57] sure it is [00:57] -1 is wrong [00:57] Well, it might be wrong to include the Debian revision, but this *is* technically a new upstream version. [00:57] and not using ~ is arbitrary [00:57] (and wrong in this case) [00:58] If it was just 5.24.1 the migration would still be held up. [00:58] dh_perl is encoding assumptions about the versioning of the perl package which the perl maintainers are not consistent with [00:58] Which would be correct, IMO. [00:58] held up how? [00:58] The current version in release is an older upstream version. [00:58] ah, you mean if it was 5.24.1 instead of 5.24.1-1 - yes [00:59] So, I agree that having the Debian revision there isn't right, but it's also not the cause of the migration block. [00:59] but it's still encoding an arbitrary lower bound with no upper bound [00:59] which appears to be nonsense [01:31] He never answered my question as to why he thinks it needs to be in base-files. :/ === mbarnett_ is now known as mbarnett === DrKranz is now known as DktrKranz === dasjoe_ is now known as dasjoe === tumbleweed_ is now known as tumbleweed === andyrock_ is now known as andyrock === ulkesh_ is now known as ulkesh [06:33] good morning === caribou_ is now known as caribou === enyc_ is now known as enic === enic is now known as enyc === marcusto_ is now known as marcustomlinson === shadeslayer_ is now known as shadeslayer === sergiusens_ is now known as sergiusens === _salem is now known as salem_ [12:07] cpaelzer: nice work on the pg-repack regression! [12:08] cpaelzer: so seems this doesn't need to block the update but the test can be fixed out of band? [12:46] pitti: if the SRU team is willing to move the MRE on with this understood but not yet fixed yes [12:46] pitti: I already have the debdiff for the SRU on the bug as well [12:46] pitti: for pg-repack I mean [12:48] pitti: I think if you could ack that "this doesn't seem to block the update" then I might be able to work with rbasak who is on SRU duty today to move things forward [12:49] pitti: oh I see you already did state that 31 minutes ago - thanks [12:50] rbasak: do you think you would have some of your SRU time today to help me upload and SRU check these things? [12:51] cpaelzer: I'm prioritising FF today and tomorrow, sorry. === coreycb` is now known as coreycb [12:52] rbasak: fair focus [12:52] rbasak: that might be true for most SRU Team activity thse days [12:52] rbasak: what do you think of a session on Friday if nobody else moved it forwards until then? [12:54] cpaelzer: maybe, but it depends on what else I need to do on Friday because I deferred things because of FF :-/ [12:55] rbasak: ok for me, I'll take the maybe and poll you then if still needed === freyes__ is now known as freyes === alan_g is now known as alan_g|lunch [13:14] pitti: if you want and can still move some bits of the MRE process forward please feel free to do so [13:14] pitti: I'm now blocked by lacking upload rights for the moment [13:15] pitti: in any case nacc can later on do the uploads into unapproved [13:15] pitti: nacc: and fromt here it is SRU team anyway [13:15] cpaelzer: oh, I thought bileto could land that for you? [13:15] pitti: it can land it for people with upload rights [13:15] pitti: = not me yet [13:15] if a properly privileged person hits publish it might work [13:16] as you know I'm already preparing a PPU and probably even an MOTU application for all the pg-* tools and more [13:16] but not ready yet [13:17] cpaelzer: trying, clicked publish on the trusty one [13:18] * pitti polls https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 [13:19] I see the matching ping in ubuntu-ci-eng [13:19] pitti: does that land in unapproved or does it bypass that? [13:20] I think unapproved; at least I saw a lot of bileto-origin srus there [13:20] ah, there it goes! https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 [13:20] good [13:20] thank you [13:21] I was afraid it might a whole to bypass of SRU Team [13:22] cpaelzer: I just can't use the sru-* tools in a chrot, launchpadlib says httplib2.ServerNotFoundError: Unable to find the server at api.launchpad.net [13:23] so, I'm happy to accept and just update the bug manually, without the boilerplate (which is fine, it's a "synthetic" bug anyway) [13:23] ok, thank you for your help [13:27] cpaelzer: ok, all set; I can't yet run copy-packages/sru-release (for the same reason), I suppose I'll need to figure out why this is broken [13:27] (it's my actual ubuntu partition, but chrooted into -- so I don't think it's missing packages) [13:28] pitti: ok, at least it is now one step further and ready for the SRU Team - thanks [13:28] cpaelzer: not the SRU team actually -- we need to wait for distro-CI, please verify that the tests turn out as expected, then mark v-done [13:28] oh you even got them to proposed I see [13:28] then we can copy to -updates [13:28] will do so [13:29] bileto is quite convenient for sponsoring! [13:29] * pitti hands a cookie to robru [13:45] pitti: Stupid question, but are you sure your chroot has a valid resolv.conf and/or nsswitch.conf compared to the host? [13:46] infinity: actually that's a very good question! [13:46] I don't have it at all; must have been a leftover from some resolved experiments (NSS would already resolve, no need for the file) [13:46] (Arguably the best thing about having a local resolver, so all your chroots can have localhost in resolv.conf without needing a smarter tool like schroot to manage it) [13:47] ah, no, I did have a file, but it points to /etc/resolv.conf -> ../run/resolvconf/resolv.conf === alan_g|lunch is now known as alan_g [13:48] Which is probably broken or missing? [13:48] yeah, chroot :) [13:48] 127.0.0.1 to the rescue, if you have a listening resolver. [13:48] et voilà, it works, thanks! [13:49] update-excuses now completely hangs my Firefox :-/ [13:49] My plan is working. [13:50] 10.61M. [13:50] It's my UDDoS on the Ubuntu development community. [13:50] NDDos? [13:50] oh dear, how many packages did you upload [13:50] links works. links FTW. [13:51] pitti: None, I've just been too busy to fix the ones sitting there. [13:51] Migrating perl will help a bit. [13:51] Which just needs someone to find a few minutes to unwing libemb-perl or whatever it is. [13:51] The rest of the failures are false positives. [13:52] False negatives. [13:52] False fails? [13:52] Whatever. [13:52] BROKEN TESTS. [13:52] post-factual tests! [13:53] Oh dear. [13:53] || true [13:53] alterative truth :) [13:53] If American politics bleeds over the border much more than it already has, I'm moving to Germany. [13:54] alternatively you could build a wall on the south border [13:54] I never thought I'd be able to unironically use the sentence "I'm moving to Germany to escape fascism", but here we are. [13:54] seems to be fashinable [13:54] +o [13:54] jbicha: haha, good one [13:55] infinity: I thought sanity levels in Canada were quite high still? [13:55] pitti: Can I apply for political asylum on the grounds that being near the US makes me feel icky? [13:55] you'd get my vote [13:56] no objections from me :) [13:56] but i'd suggest to wait til after the election in sept. ;) [13:56] pitti: Yes and no. I think the "average Canadian" is significantly less nutty butters than what's been happening to the "average American", but our right wing has been winging it up pretty well. And even have a Trumpalike running for party lead of the Conservatives. [13:57] pitti: And the Facebooks are full of Canadians who think the Republicans are god's gift and really want us to have our very own Tea Party. [13:57] infinity: you won't be save from that in .de either .. AfD *cough* [13:57] yeah [13:57] pitti: But AfD doesn't hold any meaningful power, right? [13:58] they wont get over 10.-15% but still [13:58] definitely got worse over the recent times [13:58] infinity: ... yet [13:58] pitti: The Cons are the official opposition here, and formed the government for a decade before that. If they do the same grass-roots buggery the Republicans do, it would be the same story here as it was there. [13:59] * pitti seriously hopes it won't ever get to that point [13:59] pitti: As in, I'm not talking about a fringe group, I'm talking about old guard being infiltrated by fringe (much like the Tea Party tore up what was left of the Republicans) [13:59] I still can't believe that it will take more than a year or two until Trump fans finally recognize the big scam and turn away [13:59] You say that, but... [14:00] If the last few weeks weren't enough, nor the campaign for a year before that, there's some obvious cognitive dissonance that just can't wash off. [14:00] yeah, hopeless optimism [14:00] Plus, the US has *massive* single-issue voter problems. [14:01] On certain single issues that most of the rest of the western world considers settled and behind us (like abortion). [14:01] we actually have some hope in recruiting to $work based on recent political outcomes in U[KS], we'll see how it goes when we have a couple of sysadmin positions out in a month or two [14:01] . o O { or treating women as humans .. } [14:01] Sure, there are pro-life folks in every western country, but most of them realise it's decided, it's done, and it ain't being reversed. American conservatives hold out hope with every election that if they elect just the right awful people, yay, no more abortion. [14:02] And maybe that's one area where Canada remains saner. [14:02] When we progress, we tend to refuse to look back. [14:02] * mdeslaur gets more popcorn [14:03] Even my hardline right-wing religious parents are like "yep, gay people can get married now, the people decided, the courts backed it up, we're done arguing, the end". [14:03] there is always a chance they go back to dark ages though ... see poland ... EU doesnt protect you from that [14:03] infinity: Harper's science policy was not exactly according to this though, had a few extended collegues in that area that got screwed by that [14:04] maswan: Harper certainly had his regressive moments. Most (but not all) of them were firmly smacked down by our courts, though, which is comforting. [14:04] They've just about started to attend our common confeerences again [14:04] well, no democratic institution can "protect" folks from voting for the right thing, by definition :) [14:04] err, "wrong" thing obviously [14:04] maswan: That said, he looked like a downright hippie compared to the current GOP. [14:04] infinity: yup [14:05] pitti, in an adt run... how do i know what package is intended to be tested? i know you told me this once... ie, if B depends on A and A changes, so dep8 tests run for B, how can I know 'A' ? [14:06] smoser: it's the "trigger" you see on the autopkgtest.u.c. history, or the top-level package on excuses.html [14:06] smoser: if you only have the log, search for --env=ADT_TEST_TRIGGERS= === alai` is now known as alai [14:22] pitti, thanks. [14:26] seb128: Hi, sorry to bother you again, but it looks like libertine is still stuck in proposed. [14:27] ChrisTownsend: Fixing. [14:27] infinity: Thank you! [14:29] ChrisTownsend: Should sort itself out in an hour or so. [14:29] ChrisTownsend, I promoted the python package earlier [14:29] (or less) [14:29] maybe something else was needed [14:29] seb128: Yeah, you missed one. [14:29] k [14:29] infinity, thanks for fixing [14:29] need to hit it with a bigger stick [14:29] infinity: seb128: Ok guys, thanks for your help! [14:53] pitti, sorry to keep pestering you. will ADT_TEST_TRIGGERS ever be more than one package ? [14:56] smoser: not from britney, but it can be from manual retries [14:56] so what is the format then ? space delimited or something ? [14:56] and potentially in the future once britney gets better about grouping packages [14:56] smoser: yes, the env variable is space delimited [16:52] cjwatson_: damn this grub bug - i cloned one of the raid disks with dd, checked that the clone exhibits the same problem, then put it in another machine. Now it passes grub, but drops to busybox saying it can't find root. mdadm doesn't want to bring up the md devices, saying the sd devices are busy [16:52] also 'mdadm: CREATE group disk not found' whatever that means === JanC_ is now known as JanC [17:03] tjaalton: nice work on the dogtag-pki stuff, thanks for the prompt turnaround! [17:03] tjaalton: i'll keep an eye on excuses [17:04] nice [17:04] I had that on my radar somewhere [17:04] Laney: :) [17:04] hope it fixes the tests :-) [17:04] it's blocking a surprising amount of stuff given that I'd never heard of it :P [17:05] Laney: we kicked tomcat8.5 out of z-p and updated dogtag-pki, which should resolve the testing issues (technically only by the former, but the latter fixes FTBFS in new versions) [17:07] nacc: Roger, that's good to know, thanks! [17:27] doh, the s390x autopkgtest workers had been taken out due to a networking glitch [17:27] sorry 'bout that [17:32] nacc: looks like it built at least :) [17:36] Laney: yeah :) [17:36] err, tjaalton --^ :) [18:41] xnox: friendly reminder https://irclogs.ubuntu.com/2017/02/12/%23ubuntu-devel.html#t03:06 [18:45] xnox: sorry meant that to go elsewhere [18:45] cyphermox: friendly reminder https://irclogs.ubuntu.com/2017/02/12/%23ubuntu-devel.html#t03:06 [18:48] wxl: didn't we say fixing just the bug for that SRU was better? [18:48] cyphermox: that's sort of the message i'm getting. just confirming. if so i should be able to fix this really simply. === jdstrand_ is now known as jdstrand [18:48] cyphermox: this is my first ever SRU so forgive me :) [18:49] no worries [18:49] so, in theory it should be pretty simple to fix yeah, just ping me when you have a debdiff you want me to sponsor [18:49] cyphermox: excellent. i'll have something done right quick :) [19:03] <_hc> I'm an upstream dev and Debian packager for fdroidserver (among many other things), and I wanted to know the process for updating that package in 16.04 LTS. I've been searching around, but no luck. The update is already in Debian/stretch [19:03] !sru | _hc [19:03] _hc: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [19:03] _hc: but that would only be for bugfixes noramlly [19:05] might make for a backport though, but not sure what the backlog is for the backports team [19:05] (probably huge) [19:54] jgrimm: just glancing at the other test failures for python-boto, it seems like it's getting 'wrong' http response codes (403 instead of 404, e.g.) [19:54] jgrimm: seems like a auth issue somewhere for all of them, actually [19:54] jgrimm: "The security token included in the request is invalid" [19:55] nacc, cool. i'll dig into it. [19:55] jgrimm: and Token: None === manjo` is now known as manjo [21:23] slangasek: could you take a look at something, when you have a moment? heimdal is FTBFS on 17.04, and I'm not sure how it is supposed to work. I filed an upstream bug with no response at: https://github.com/heimdal/heimdal/issues/241 [21:24] slangasek: but i'm confused how this would work on non-64bit archs (where it does not FTBFS) [21:33] nacc: huh, so this is a different problem than the previous heimdal FTBFS issues, which IIRC were on 32-bit? :) === cjwatson_ is now known as cjwatson [21:34] nacc: 'ldd ./lib/krb5/.libs/test_rfc3961' doesn't tell the whole story; the wrapper script created for the test sets the LD_LIBRARY_PATH [21:35] nacc: it's not obvious to me why the behavior would be different across archs [21:40] slangasek: yeah, i'm spinning up an i386 env to debug it live to see if the path order is different there [21:41] slangasek: and yeah, seems to be different :) [21:42] slangasek: that 32-bit fix got merged upstream, btw [21:43] slangasek: also, it seems like debian is not showing the same problem, on any archs [21:51] nacc: oh - libsqlite3-dev is shipping a .la file that points at libdir? that would seem to be the trigger... is that new? for a long time we've tended to strip .la files out of the .debs [21:51] so maybe this is a change that happened more recently than the last time heimdal built in Debian [21:51] slangasek: ah that could be -- i'll dig into that [21:52] hmm the .la file is also there in libsqlite3-dev in yakkety [21:52] so I don't know [21:53] nacc: the other thing might be that Debian doesn't hit it because the system libhcrypto4-heimdal isn't installed in the build chroots? === salem_ is now known as _salem [22:18] slangasek: ack, i'll check on that [22:24] slangasek: good catch, the ppc64el build of heimdal in debian does not have libhcrypto4-heimdal installed: https://buildd.debian.org/status/fetch.php?pkg=heimdal&arch=ppc64el&ver=7.1.0%2Bdfsg-9&stamp=1483969232&raw=0 [22:45] nacc: so, why is it there on the launchpad buildds? It really seems to me that it shouldn't be [22:49] slangasek: urgh, so on i386, `./test_rfc3961 --version` passes (which is what is failing on amd64 technically) but then actually running the test also emits the relocation error after finishing the test (successfully) [22:50] slangasek: so i think it's technically busted on i386, but the behavior is different enough that it's being considered successful :/ [22:50] slangasek: is it relevant that `seeded-in-ubuntu` is indicating heimdal is seeded? [22:50] slangasek: not sure what is the base of the launchpad buildd's [22:51] slangasek: but agreed, it seems like heimdal packages are installed already, as the first log entries include upgrading them all [22:52] nacc: random guess: apt-transport-https -> libcurl3-gnutls -> libldap-2.4-2 -> libgssapi3-heimdal -> various heimdal libs [22:52] not sure what's responsible for apt-transport-https though, my own chroots don't have it [22:53] it's recommended by apt-transport-tor and ubuntu-standard [22:56] apt-transport-https has been explicitly added to LP build chroots for long enough that I can't discern a rationale [22:56] ah [22:56] cjwatson: ok :) [22:56] though I don't know how much resemblance infinity's current chroot-building code bears to the script in puppet [22:57] my guess would be that it's to make private PPA builds work [22:57] because the base URL for those on production is https [22:58] that would make sense [22:58] nacc: ironically enough, in the past there was a bug in src:openldap packaging that was hidden by heimdal pulling libldap into build environments... :) [22:58] heh [23:01] I believe that buildd chroots are basically debootstrap --variant=buildd + pkgbinarymangler + pkg-create-dbgsym + apt-transport-https [23:03] dirmngr -> libldap-2.4-2 -> libgssapi3-heimdal as well [23:03] ow [23:04] i just today created a zesty-i386 schroot and looking at the log, the first thing 01launchpad-chroot does is instlal the heimdal packages among others [23:04] http://paste.ubuntu.com/24003706/ [23:17] cjwatson: Speaking of which, is there something tracking effort for LP/etc for supporting debhelper based dbgsyms? [23:18] slangasek: so i'm not entirely sure how to fix this -- that is, I understand that it's maybe non-ideal for heimdal to already be installed, but it does go back to the libsqlite3.la file (i think) as to why the order matters [23:19] slangasek: in z-p, libsqlite3-dev definitely contains a libsqlite3.la file [23:20] slangasek: ah but nm, as you said, was also there in y [23:20] Unit193: the LP side is done AFAIK: https://bugs.launchpad.net/launchpad-buildd/+bug/1623256 [23:20] Launchpad bug 1623256 in debhelper (Ubuntu) "adjust the way to create dbgsym packages like Debian does" [Undecided,In progress] [23:20] Unit193: well, except that the extension still needs to differ [23:21] Unit193: but the buildd change there *should* be enough to allow refactoring the rest of it [23:21] Oh bah. OK, thanks for the update. [23:31] slangasek: ok, the exec. summary is that heimdal FTBFS if libheimdal* are installed (aiui) -- because the system-libheimdal files will get seen before the build-local ones and they will fail to properly load. Is it possible to specify an anti-build-depends? :) [23:32] slangasek: would 'Build-Conflicts' be appropriate here? [23:32] Who's doing patch pilot? [23:32] (for today) [23:32] >___> ... <___< [23:33] nacc: it would be a correct declaration, but I don't know if launchpad would be accommodating ;) [23:33] slangasek: :) [23:33] use the calendar [23:33] (it *should*, but you'll need to test) [23:33] slangasek: ack, i'll try that locally first [23:35] nacc: the only things that would make it not work would be things specific to the launchpad builder config [23:35] so I don't think a local test helps much; try a ppa instead [23:35] slangasek: ack [23:35] wxl: I'm seeing if they'll step forward :P === mwhudson_ is now known as mwhudson [23:43] slangasek: sigh, not trivial (local test did help for that :) -- heimdal b-d on libldap2-dev => libldap-2.4-2 => libgssapi3-heimdal and the same chain as above. So tarpman maybe you can help me understand why we have a different dependency chain in Ubuntu. Is this because we have gssapi enabled by default on Ubuntu only? === mwhudson is now known as Guest32650 [23:45] nacc: correct [23:45] nacc: via likewise-open [23:46] tarpman: right [23:46] tarpman: so any idea on how to disentangle this so we can build heimdal? :) [23:46] nacc: off the top of my head, nothing better than 'fix heimdal' :S [23:46] the gssapi thing is nasty, but I wasn't planning to revisit it sooner than the next ABI bump (i.e. 2.5) [23:47] "nasty" is the wrong word, but you get my fridt [23:47] drift [23:47] tarpman: yeah === mwhudson_ is now known as mwhudson [23:48] tarpman: i'm just trying to think of what the 'sane' fix would be -- we could post-process the LD_LIBRARY_PATH so the system path is at the end but that seems gross and fragile [23:48] tarpman: or even 'a' sane fix :) [23:50] I don't even want to know why the 32-bit builds passed, do I [23:52] tarpman: afaict, they technically shouldn't have [23:52] tarpman: the relocation error emitted on amd64 (at least), is emitted on i386 too, just not when you run ./test_rfc3916 --version :/ [23:52] tarpman: and for some reason, on 32-bit, it's not causing the testcase to fail (I'm guessing they do some post-process grepping for determining success and aren't checking the return code from the test itself) [23:53] tarpman: so yeah, probably didn't want to know :) [23:54] nacc: sorry, I don't have time right now to look in enough detail to contribute. will try to look after work [23:54] tarpman: totally fine! [23:54] tarpman: thanks for responding at all :) [23:54] * tarpman peanut gallery