[00:09] rbasak: what is "Orchestra"? [00:09] appears to be a precise-only thing? predecessor to maas? [00:12] was that the old name for juju? [00:12] mwhudson: hrm, could be :) [00:12] er, no, i think that was ensemble [00:13] ah no, i think orchestra became maas [00:13] oh no, i don't know ;-) [00:13] * mwhudson gets back to work === roaksoax_ is now known as roaksoax [00:38] nacc, mwhudson: yeah, Ensemble got renamed to Juju, and Orchestra was superseded by MAAS, IIRC. [00:38] rbasak: ack, makes sense, thanks [00:38] People used to confuse Ensemble and Orchestra quite a bit. === ljp is now known as lpotter === salem_ is now known as _salem === zsombi_ is now known as zsombi [07:17] Good morning [07:18] juliank: heh, thanks for pointing out; noted [07:19] infinity: right, I added a WI to add Test-Depends:; I'll do this after the britney Merge From Hell [07:21] infinity: heh, three trailing dots don't work any more [07:26] pitti: If I retry an autopkgtest, it retries in the original environment. How will I be able to get the apt autopkgtest rerun against dpkg 1.18.9ubuntu2 once that migrated? [07:26] ubuntu1 breaks the APT test suite... [07:27] juliank: if dpkg migrated, then the apt autopkgtest will run against htat [07:27] it doesn't remember an "original env" and tries to reconstruct it with earlier package versions [07:27] that would be fairly pointless, a lot of work, and totally not robust [07:27] pitti: Oh, I misread the logs. [07:28] OK, that's great then [07:36] tinoco, infinity, xnox: aupkg01 (10.100.0.12) is still AWOL; can you please revive it? http://autopkgtest.ubuntu.com/running.shtml has a desperately long s390x queue.. :( [07:40] pitti: apt/yakkety failed (?) with ERROR: Quota exceeded for cores: Requested 1, but already used 30 of 30 cores (HTTP 413) (Request-ID: req-83a86408-bde2-48fc-bb3c-3cd951790006) [07:40] juliank: it didn't fail, it'll retry again in a bit [07:40] OK [07:40] juliank: the workers are hammered right now, so clouds run out of space [07:41] I can believe that [07:44] Damnit, the apt autopkgtests are failing [07:44] they've been failing for a while [07:44] (in y) [07:44] pitti: Yeah, but those were weird. [07:44] Maybe it's still a cause of the dpkg thing [07:44] We'll see once dpkg has migrated... [07:45] Not so sure about test-apt-tagfile-fields-order [07:51] Yep, it's a "real" problem. We don't know the Testsuite-Triggers source field yet -> that fails the test [07:52] I failed to notice that because I only upgraded dpkg, not libdpkg-perl [07:52] But that only means we have no specified order that field when sorting [08:02] The apport tests fail with the new apt which now raises E:The repository 'http://ddebs.ubuntu.com trusty Release' is not signed. [08:03] :( [08:03] I'll look into that [08:04] Log https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/a/apport/20160708_072803@/log.gz [08:04] * juliank wonders why the python-apt tests fail [08:31] doko, ha ha ha ha =) [08:31] told you germany will play wales for the third place ;-) [08:32] there actually is no game for the third place [08:42] pitti: Any thoughts on my libnss-resolve bug? [08:44] infinity: I don't know what the RFCs have to say about this, but I guess it's just a bug that needs fixing :) i. e. not much to think about it, just fwd it upstream and fix it [08:44] as three dots don't work, there is no systematic "ignore trailing dots", so this just sounds like a too lax trailing dot check [08:45] pitti: Any more trailing dots after the first are garbage. One could take the "strict in what you produce, liberal in what you accept" argument, but differing from the resolver we've used for decades is a fair argument for it being a bug. [08:46] agreed [08:46] pitti: Anyhow, it was mostly a question of "should I just ignore the glibc failures for now, or can we fix it soon?" [08:46] this doesn't look intended [08:47] infinity: shouldn't take that long; but it doesn't appear so urgent to me that I should drop my brain state from the britney merge and move to that immediately? [08:47] infinity: but glibc built, didn't it? i. e. is that actually blocking you? [08:47] pitti: Actually, wait. Why is libnss-resolve in my autopkgtst chroot in the first place? [08:47] pitti: glibc built, sure, cause libnss-resolve isn't in buildd chroots. It's the autopkgtests that fail. :P [08:47] it's certainly not in build chroots, yes; but we do install it by default now, because servers [08:48] pitti: Sure, but autopkgtests are supposed to test against a minimal base, I thought? [08:48] Or do we test against standard intentionally? [08:48] infinity: more or less; it's a cloud image with the most obvious crap purged, but it's certainly far from minimal [08:49] pitti: Hrm. Kay. Perhaps we can impove on that $later, but today, I'll just ignore that failure. [08:49] but actually, testing stuff with the low-level plumbing things we install by default actually seems better [08:49] infinity: yeah, no problem with hinting over that one, as we understand what it is [08:49] pitti: I'm going to make the buildd chroots auto-built daily soon, would be trivial to turn those into bootable cloud images, so you'd have the same level of minimalness. [08:49] also, queues are still uber-full anyway (particularly s390x) [08:50] pitti: But yes, maybe minimal+standard is the better baseline, since that [08:50] 's what we consider "Ubuntu". [08:51] pitti: why not start with debootstrap + tasks instead of cloud images - stuff? [08:51] rbasak: the cloud images are all that I have in scalingstack [08:52] I create my own images from those plus http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed which purges a lot away [08:52] rbasak: minimal deboostrap-like images are being used with lxc/lxd, thouhg (on armhf/s390x) [08:53] pitti: could you access the (original) core tarballs for example? [08:53] rbasak: no -- they aren't bootable at all [08:53] you need a kernel, grub, cloud-init, etc. [08:53] I don't want to get into the business of building cloud images from scratch [08:54] also, that'd be too synthetic -- we want to test stuff in an env whose base/plumbing bits are what we actually ship [08:55] It just feels fragile to take the cloud images and then strip stuff away, that's all. [08:56] well, having all this non-standard stuff installed breaks stuff (lvm2, command-not-found, lxc, etc.); but Priority: standard" should stay IMHO [08:57] we don't have lean cloud images, we just have those chubby ones which are optimized for human usage, not for actual cloud "cattle" usage [08:57] but I've given up on this :) [08:57] I believe the decision is to prefer to have a single image suitable for both uses. [08:57] So not too chubby, not too lean. [08:58] yes, which I heavily disagree with, but as I said I've given up on this [08:58] Rather than confusing things by having two sets. [08:58] But unfortunately that makes them unsuitable for the autopkgtest case. [08:58] we penalize millions of cloud instances/users for that, but *shrug* [08:58] Cloud users generally don't have to download an image. The cloud provider already hosts them. [08:59] And disk space is usually not the bottleneck. [08:59] it's disk space (density), download and upgrade time [09:00] plus excess runtime (having mdadm/lvm2 in the boot path, apt-xapian-index daily cron jobs, etc.) [09:01] plus, as we also advertise them for lxd, it actually *is* download time too [09:02] If it's a choice of penalising that or penalising developers for not having stuff available, I'd prefer the former. [09:02] In the case of lxd, I *want* this stuff in the images. [09:02] right, and that's what I disagree with -- most cloud images are not being used in an interactive way [09:02] True, but most engineering time on images is spent in an interactive way. [09:03] and for the few ones that are, adding a "Human-Comfy: yes" thingy to cloud-init would be better than asking everyone to trim their cattle images themselves [09:03] And it is engineering time that is the most expensive. [09:03] That would slow down every image boot. [09:03] Finally, after my engineering, I want to deploy the same environment without changing it. [09:03] the "classical human server" use case isn't that you re-create them often [09:03] this was supposed to replace the ubuntu server image [09:04] well, I made my point, let's agree to disagree [09:04] :) [09:04] you won't convince me, and after discussing it several times I accept that I won't convince you [09:05] I was thinking about something like this the other day [09:05] I used to work on a deployment that was "lean". I replaced it in the end. [09:05] It's too painful to deal with operational issues when nothing is available. [09:05] Maybe super minimal is even an anti-goal [09:05] in the real world people run with all sorts of crud installed, and things should still work [09:06] rbasak: installing iscsi, lvm2, mdadm, and apt-xapian-index into every LXD container is not "lean" or even useful, it's just bloat [09:06] no developer will ever need that [09:06] or handle gracefully their lack of working [09:07] When I move my lxd container test stuff into prod, I don't want to deal with bugs that occur because stuff behaves differently. [09:07] Even though the incidence rate is low, the overall cost is still lower than the extra cost of having lvm2 and iscsi in lxd images. [09:09] doko: wasn't there a way to switch toolchain (or in my case cross-toolchain)? [09:09] Maybe it makes a difference if I had 10,000 nodes. But in that case, I'm probably in a position to maintain a modded image well anyway. [09:09] doko: the kernel i'm working on, doesn't compile with gcc-5 but it does with gcc-4.7 [09:09] doko: i installed the gcc-cross-...armhf-4.7 [09:09] depends on the package you want to build ... [09:10] doko: kernel [09:10] but CC=... CXX=... should work [09:10] doko: nope, because you pass [09:10] doko: export CROSS_COMPILE=arm-linux-gnueabihf- [09:10] doko: and /usr/bin/arm-linux-gnueabihf-gcc -> arm-linux-gnueabihf-gcc-5 [09:10] ppisati_, I don't build kernels, maybe apw can help? [09:11] ppisati_, I usually end up in doing some symlinks [09:11] I agree with you [09:12] doko: it's not a building problem, it's 'how do i make toolchain X the default toolchain' [09:12] yeah, but i've a vague memory [09:12] the problem is that there isn't an "append" variable [09:12] of script that you could run [09:12] I mean, $CROSS_COMPILEgcc$CROSS_SUFFIX might be a nice idea [09:12] and it would switch from toolchain-X to -Y [09:12] LocutusOfBorg: right [09:12] ppisati_, BTW there are trivial fixes for gcc 5 and kernel [09:13] I ended up in adding them [09:13] pitti: You can probably replace that hardcoded list of packages in the "bloat removal" with "apt-get purge server^" [09:13] I'm pretty sure you are referring to the failures related to inline [09:13] LocutusOfBorg: yep, but sometimes kernle's vendor X require only that toolchain Y, so i can't easily switch [09:13] etcetc [09:13] I suggest you a CROSS_SUFFIX feature request ;) [09:13] I'll use it too ;) [09:14] ppisati_, I don't support making random toolchains the default. best thing then to create your own bin dir with new symlinks [09:16] exactly what I did [09:16] ppisati_: What's wrong with patching the Makefile for CC = gcc-4.7? [09:16] infinity, no [09:16] LocutusOfBorg: Because? [09:16] cross compiling works differently [09:16] they use something like [09:16] infinity: nice, I'll try that [09:16] LocutusOfBorg: I know how cross works. [09:16] CC=$CROSS_COMPILE-gcc :) [09:16] LocutusOfBorg: Fine, s/gcc/gcc-4.7/ [09:17] LocutusOfBorg: If it needs 4.7, it needs it natively and cross, so it should be reflected in the Makefile, not the environment. [09:17] so, better is to s/gcc/GCC$CROSS_SUFFIX idea I told him :) [09:17] this might be upstreamable [09:17] No. CROSS_SUFFIX is wrong. [09:17] calling it GCC_VERSION? [09:17] These kernels need 4.7 for native *and* cross. [09:18] And none of this needs to be upstreamed in his case. [09:18] I had the use case of a kernel that was segfaulting when built with 4.7, and not with gcc-4.3 [09:18] I would have used the feature [09:19] sometimes you have to test different cross compilers, not just always the same [09:19] but I agree with your solution :) [09:19] But if you know you need 4.3, you change the Makefile. Why is that hard to grasp? [09:19] because 4.3 disappeared from the main repo :) [09:19] so, sometimes people needs to move on [09:20] and try newer toolchains :) [09:20] Then the software becomes FTBFS. [09:20] Until the Makefile changes. [09:20] That's fine. [09:20] yes, and I usually fix the FTBFS [09:20] You don't claim "any gcc will work" when that's known to be untrue. [09:20] but in the meanwhile, the software might not FTBFS but misbehave [09:21] so, having a CROSS_COMPILE=arm-foo- GCC_VERSION=4.7 make [09:21] is trivial and a nice way for testing different toolchains [09:21] but ECHAN [09:21] doko: Well, I fixed *a* bug in the cross-toolchain-base debian/rules, but it wasn't *the* bug. Back to investigating, I guess. [09:22] BTW the sed should be propagated in many places, e.g. gcc, ld, ar, as, nm in tools/* and so on [09:22] i really didn't want to change symlinks, but it seems it's the only way [09:23] ppisati_: Err, wat? We have lots of kernels in the archive that build with non-default GCC. [09:23] ppisati_: It's trivial, and doesn't require mangling symlinks. [09:24] infinity: if i'm on a xenial box the default is gcc-5 but i want to use different one [09:24] ppisati_: Yes, so change it in the Makefile. [09:24] infinity: no, because i don't want to enforce a version [09:24] ppisati_: But... You do. [09:24] infinity: people should be able to pass it via the CROSS_COMPILE stuff [09:24] infinity: no i don't [09:24] ppisati_: If you don't want to enforce a version, why are you changing the version? [09:25] ppisati_: That makes zero sense. [09:26] bdmurray, hi, when I choose “Show Previous Reports” I see a list of error reports that definitely isn’t mine. What info should I provide in reporting this bug? [09:26] mpt: How is that a bug? [09:26] infinity: ok so, i patch to use X, then there's another guy with another distro or whatver and it doesn't have X, but has Y that can compile it [09:26] infinity: what does it do? [09:27] infinity: does it patch the makefile locally himself? [09:27] ppisati_: It fails until they alter the Makefile. Sure. *shrug* [09:27] infinity, because the list header says “Error reports sent from this system” and they aren’t [09:27] sladen: it never hurts to check an updated software version, but I admit I also looked at the changelog and had my doubts. [09:27] ... [09:27] mpt: Oh, I was thinking of a different UI elsewhere. Nevermind. [09:28] ppisati_, this is why I'm thinking about a GCC_VERSION suffix variable [09:28] you can just export it, with the correct value [09:28] I have collagues with older ubuntu, some others with debian [09:28] ppisati_: You could also write a Makefile that looks for existence of 4.7, then not. But why are you concerned about people compiling on RedHat? [09:28] I face similar issues on a daily basis [09:28] infinity, it doesn't really scale [09:29] ppisati_: If you know it only works with 4.7, I'm a big confused about why you'd care if it tries to compile with other versions. [09:29] nope, it doesn't build with gcc>=5 [09:29] this doesn't mean it only works with 4.7 [09:29] what I do in my company is to build yocto cross-toolhchains [09:29] LocutusOfBorg: I'm assuming 4.7 because he's not using 4.9. :P [09:29] and give them to my colleagues [09:30] As for "scaling", neither do magic environment variables. [09:30] And they lead to completely unreproducible build environments. [09:30] actually they mostly do the trick [09:30] +1 for the second sentence [09:30] actually sometimes an use case is to test different environments :) [09:30] Anyhow, linux-goldfish has "CC = $(CROSS_COMPILE)gcc-4.7 [09:31] I'm curious why that's not doable for ppisati_'s other kernel. [09:31] this fix is good for ubuntu, but e.g. won't be good anymore on the next ubuntu [09:31] It's intentionally not good for the next Ubuntu. [09:31] It's set to 4.7 because that's the compiler that works to build that kernel. [09:32] If all GCCs worked, it wouldn't have the version appended. [09:32] But I'm done talking in circles. [09:43] infinity, right we would expect him to do that linux-goldfish thing ... ppisati_ ^ [09:48] eventually the phone guys need to lift the emulator to android 5 ... [09:48] which should hopefully come with a newer kernel [09:48] you shoudl poke them ;) [09:49] ogra_: Not actually the concern here, but agreed, if you mean Android 6... Or 7. ;) [09:50] well, whatever the latest phones are on (iirc thats still 5) [09:50] pitti: Why are the s390x queues doing so badly? Did you lose a machine again? Or never find anyone to rescue your dead one? [09:50] infinity: yes, see my ping from yesterday and from this morning [09:50] one machine is down [09:50] on a sidenote, the emulator hasnt worked for the last three OTAs or so [09:51] ogra_: My Nexus 5 is on Android 6.0.1. 7.x comes out this fall. [09:51] which is half of our capacity [09:51] infinity: normally s390x is the fastest one : [09:51] ogra_: Unless you meant the current Ubuntu phones. [09:51] infinity, yes, and victors team just works on porting hybris to 6 i think :) [09:51] ogra_: In which case, that should be upgraded some day too. :P [09:51] infinity, indeed i do ... i'm talking about the emulator and your gcc issue :) [09:51] xnox: Can you rescue pitti's lost s390x z/VM? [09:52] infinity, let me see [09:52] ogra_: Right, the GCC issue wasn't actually in goldfish, I was just using it as an example of precedent. But totally agreed that we need to get with the program and move to a modern Android. [09:52] yep [09:53] which will move the gcc issue magically to a newer version (and bite again in a year or so :) ) [09:54] pitti, do you remeber the login name for the z/vm? [09:54] AUTOPKG01? [09:55] found it [09:55] xnox: yes, aka 10.100.0.12 [09:55] AUPKG01 [09:55] Goldpackage. [09:55] The new Bond villain. [09:57] pitti, infinity: AUPKG01 is booting [09:58] xnox: Ta. [09:58] xnox: cheers [09:58] pitti, do i need to revive AUPKG02 too? [09:58] xnox: no, that's fine [09:59] xnox: we installed crashdump on those back then [10:00] xnox: Lunch? [10:00] * infinity heads down from the lab. [10:00] xnox: where would they be? (the crash dumps) [10:00] there's just a /var/crash/kexec_cmd [10:28] bdmurray, reported bug 1600178 [10:28] Error: Launchpad bug 1600178 could not be found [10:51] Adri2000, libfilezilla didn't have a soname bump [10:51] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830474 [10:51] Debian bug 830474 in filezilla "filezilla: Version 3.19 must depend on libfilezilla 0.5.3" [Normal,Open] [10:51] damn, please bother upstream about that [11:02] LocutusOfBorg: Added symbols aren't ABI breaks. [11:03] LocutusOfBorg: Looks more like the shlibs need bumping (or a proper symbols file needs to be added). [11:41] infinity, yes, indeed [11:42] I didn't see any ABI breakage when sponsoring [11:42] and indeed I missed to check new symbols on filezilla [11:43] s/filezilla/libfilezilla/ [11:43] But yeah, that library could do with a symbols file. [11:43] no, I mean, I didn't check if the new filezilla was using new symbols from libfilezilla [11:43] Sure, but you shouldn't have to, if the lib is properly packaged. :) [11:44] I leave the task to Adri2000 :) === rbern_ is now known as rbern === hikiko is now known as hikiko|ln [12:14] On 14.04, /etc/default/bind9 has RESOLVCONF=yes|no to control whether bind9 modifies resolv.conf; as far as I can tell with systemd this doesn't work as systemd is used to start bind9 and doesn't run resolvconf. I'm new to systemd so am just looking in /lib/systemd/ (as well as observing the problem). Is this likely to be an issue with bind9 or is this my stupidity somewhere? [12:14] s/with systemd/with systemd on 16.04/ [12:17] alexbligh1: presumably an issue in the way that bind9 is wrapped/packaged. Can you get a bug into launchpad/debbugs with as many details as possible [12:17] sladen, sure. Just checking it wasn't me being dumb. [12:18] alexbligh1: yeah, even in the worst case, it should allow others to find the discussion (and then it won't feel so dumb :) [12:24] sladen, done - https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1600210 - but in general files in /etc/default should continue to work with systemd, yes? [12:24] Launchpad bug 1600210 in nbd (Ubuntu) "bind9 RESOLVCONF does not work" [Undecided,New] [12:28] alexbligh1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744304 may/may not give points. That is talking the interaction of systemd and the "bind9-resolvconf.service" (which might imply it is separate?) [12:28] Debian bug 744304 in bind9 "bind9-resolvconf.service immediately stopped after starting" [Important,Open] === _salem is now known as salem_ [12:32] sladen, hmm, that service is showing as disabled. [12:51] sladen, ok, with a bit of poking around, and applying the fix in that bug, I got it to work - thanks! === hikiko|ln is now known as hikiko [13:00] alexbligh1: thank you for the report. I've marked it for assignment soon (I generally trust your reports to be high quality) [13:06] * ogra_ shakes his head ... [13:06] weird times where s3390x, ppc64el and arm64 are always buildingimages faster than any x86 arch [13:12] cjwatson: is it intended that https://code.launchpad.net/~ubuntu-release/+git/britney2-ubuntu does not appear on https://code.launchpad.net/~ubuntu-release ? I. e. is the latter "only bzr" for some backwards compat reasons? [13:12] ogra_: Not so werid for the first two. [13:12] pitti: Not for backward compat reasons, just unimplemented features. [13:12] kudos to both alexbligh1 and rbasak ! [13:22] good morning! [13:23] rbasak, sladen thanks! === dpm is now known as dpm-bbiab === marga_ is now known as marga [13:58] pitti: There are various awkwardnesses when both bzr and git are involved somewhere; I don't think we'd claim that what we have now is the best UI. There's a "View Git repositories" link [14:07] cjwatson: thanks === dpm-bbiab is now known as dpm [14:23] infinity: good timing -- we actually did get a new perl right after glibc :) [14:29] win 30 [14:49] Is there anything I can do against gbp buildpackage running the tests as root in the chroot? [14:51] Use a container perhaps? [14:51] I'd like to see a schroot driver that uses lxd. [14:53] doesn't it use fakeroot? [14:54] or is it not using pbuilder/sbuild, which i thought dropped privs to do the actual build? [14:54] I'm actually unsure. This is the first time packaging something [14:54] I noticed that the tests are failing as Apache (its part of the tests) does not allow the WSGI module to run as root [14:55] not sure, as i've not used gbp before [14:57] Interesting, all of the files in the chroot are owned by the pbuilder user but it appears the Makefile is being run as root [14:58] Actually, wait [15:20] marlinc: If you're running tests from the wrong debian/rules target, it may be running them under fakeroot, which would cause the tests to see UID 0 even though they aren't actually running as root. [15:22] What I said makes no sense, sorry. [15:22] I was thinking of other things, not being root. [15:31] marlinc: in some of my packages I run "env -u LD_PRELOAD make" in override_dh_auto_test: for that [15:31] unfortunately dh_auto_test runs in the fakeroot part by default [15:31] marlinc: err, "make check" of course, not just "make" [15:32] pitti: err, it does? [15:33] apparently so [15:33] /usr/bin/dh seems quite clear that it runs in the build part [15:33] Yeah, it shouldn't run in the binary bit. [15:33] I think you have some other subtle bug if it's running under fakeroot; it doesn't by default [15:34] I suspect marlinc may have a simpler problem if this is their first package though [15:34] http://paste.ubuntu.com/18793505/ [15:34] It was running as root because I was being dropped into a shell which was root [15:34] Note auto_test between build and testroot. [15:34] I switched to the pbuilder user and then it ran [15:34] marlinc: ah, even simpler, I guess. [15:35] Now I'm running into another test that tries to run the Kerberos KDC but can't as it can't open 88 as lower than 1024 [15:35] maybe that got fixed in the meantime, but I had to add this hack to more than just one override_dh_auto_test in the past [15:35] I'll try dropping them, thanks for pointing out [15:37] https://pagure.io/ipsilon/blob/master/f/tests/helpers/common.py#_327 [15:37] marlinc: So, you have a schrödintest that wants to run both as root and not root? [15:37] marlinc: I think you'll have to arrange to run it on some other (preferably non-fixed) port somehow. [15:38] It's not totally uncommon for tests to be somewhat badly written until packagers get to them and fix them up. :-) [15:38] I guess so yes... I'm talking with the developer of the project. There's probably something the Fedora packaging thing does [15:38] They themselves run the tests as non root as wel [15:39] Brb [15:39] Yeah, most distros build packages as non-root. [16:03] slangasek, openjdk9 has been kind broken for a while (LP: #1550950), but as doko stated that since jdk9 has not been released yet this is not a problem and whoever wants can fix that... problem is I just got a new report (LP: #1600269) where jdk9 is being installed by default because due to openjdk-9-jdk's Provides: [16:03] Launchpad bug 1550950 in openjdk-9 (Ubuntu Xenial) "package openjdk-9-jdk 9~b102-1 failed to install/upgrade: trying to overwrite '/usr/lib/jvm/java-9-openjdk-amd64/include/linux/jawt_md.h', which is also in package openjdk-9-jdk-headless:amd64 9~b107-0ubuntu1" [Medium,Confirmed] https://launchpad.net/bugs/1550950 [16:04] Launchpad bug 1600269 in openjdk-9 (Ubuntu) "package openjdk-9-jdk (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/jvm/java-9-openjdk-amd64/include/linux/jawt_md.h', which is also in package openjdk-9-jdk-headless:amd64 9~b114-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/1600269 [16:04] Provides: java-sdk, java2-sdk, java5-sdk, java6-sdk, [16:04] java7-sdk, java8-sdk, java-compiler [16:05] slangasek, what would be the right approach? jdk9 is not ready, I don't think it should be replacing openjdk 8 in such a way... should we update/remove its Provides:? keep it on -proposed only? something else? [16:07] note: openjdk-9 is available for both xenial and yakkety in universe [16:08] tdaitx: Things are supposed to depend on default-jre as a preferred alternative, but I suppose we can't control random packages in PPAs. [16:09] tdaitx: The file overlap bug should be fixed regardless. [16:09] infinity, that package depends on java-sdk, it can't depend on a jre [16:10] tdaitx: Well, default-jdk then. :P [16:10] infinity, ugh, of course [16:10] my bad [16:10] * tdaitx needs more coffee [16:11] tdaitx: Anyhow, questions of crappy PPA packages aside, there's no excuse for uninstallable packages. "It's not done yet" would have been a great argument for not uploading it at all, but once it's in the archive, it should, y'know, install. [16:11] infinity, I agree [16:14] And there goes my kneecap. [16:14] * infinity just dropped the heaviest combination of objects known to man (a UK power plug with a ZA adapter attached to it) on his knee. [16:15] cjwatson, I was told that they were using some kind of wrapper that allows those things to run as root. Some kind of virtual network stack [16:15] Ah libsocket_wrapper [16:15] you could certainly LD_PRELOAD a thing that fakes up the socketry [16:16] and I see libsocket-wrapper is even packaged for us as well; looks plausible. [16:16] Ah, they do that already [16:16] maybe you just need to build-depend on it. [16:16] https://pagure.io/ipsilon/blob/master/f/tests/tests.py [16:17] right, so that suggests you want to Build-Depends: libsocket-wrapper, libnss-wrapper [16:17] though it would appear to fail right now if they're unavailable? [16:17] oh, no, only if specifically requested [16:18] so yeah, build-depends ought to improve your life. [16:19] Just added them, lets see what happens [16:26] infinity: stepping on a UK power plug is worse. The way they're designed the prongs stick up :-/ [16:27] rbasak: My shattered kneecap will send your punctured sole a get well soon card. [16:28] IRTA soul [16:28] Which made the comment considerably more goth. [16:28] infinity, thanks for the help, and I wish your kneecap a good recovery [16:29] I did that too :) [16:29] cjwatson: *smirk* [16:30] Punctured Soul isn't a bad band name. [16:31] rbasak: it might be a bug (in debian too), due to 0014-force_libmysqlclient_r.patch [16:31] rbasak: well will be one in debian [16:32] http://paste.ubuntu.com/18797503/ [16:33] Ahh, did _r finally go away? [16:33] Ah yes, that'll be it. Thanks. [16:34] _r was a symlink in 5.6. It's gone in 5.7. [16:34] About time. [16:34] rbasak: can you file a debian bug? i'm guessing we'll need 16.04 and 16.10 bug tasks? I can also file it [16:34] nacc: will do. [16:34] rbasak: although debian hasn't gone 5.7 fully, right? so they might need some twiddling [16:34] nacc: If, as rbasak says, it's a symlink in 5.6, backing out the patch now won't hurt. [16:34] That's a point. It's not strictly a bug in Debian yet. It will be soon. [16:35] But yes, the patch won't hurt. [16:35] infinity: yeah [16:35] IIRC it's a symlink. I'm told by upstream that it's definitely unnecessary to use _r in 5.6 however. [16:35] Upstreams may have a little more trouble if they want to maintain build compatibility against older versions. [16:35] rbasak: hrm, although if it's using `mysql_config`, --libs_r just aliases to --libs, it seems ('-L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -lrt -ldl') [16:35] digging a bit further to see if i can extract what gets configured [16:36] nacc: I'm racing through some testing to get some MySQL/MariaDB changes pushed before I finish in 20 minutes, so I'm going to ignore PHP for now and switch back to that. Thank you for your help. [16:37] rbasak: sure, np, i'll keep digging on this, thanks for bringing to my attention [17:54] slangasek, hi, you said that you triggered a no-proposed retest of python-cryptography, but there's no difference [17:54] It's now the only blocker for sphinx migration [17:56] mitya57: heh; I tried to trigger for the python-cryptography in yakkety, the tests unhelpfully ran for the version in proposed; so it doesn't actually give us a baseline result. http://autopkgtest.ubuntu.com/packages/p/python-cryptography/yakkety/amd64/ [17:56] mitya57: I'll run the tests locally to verify whether python-cryptography in yakkety is broken, and if I confirm that it is, I'll mark the test bad [17:57] Thanks! [17:59] Actually I still don't understand what's wrong with that cffi-backend dependency (because of which python-cryptography itself can't migrate) [18:16]