naccrbasak: what is "Orchestra"?00:09
naccappears to be a precise-only thing? predecessor to maas?00:09
mwhudsonwas that the old name for juju?00:12
naccmwhudson: hrm, could be :)00:12
mwhudsoner, no, i think that was ensemble00:12
mwhudsonah no, i think orchestra became maas00:13
mwhudsonoh no, i don't know ;-)00:13
* mwhudson gets back to work00:13
=== roaksoax_ is now known as roaksoax
rbasaknacc, mwhudson: yeah, Ensemble got renamed to Juju, and Orchestra was superseded by MAAS, IIRC.00:38
naccrbasak: ack, makes sense, thanks00:38
rbasakPeople used to confuse Ensemble and Orchestra quite a bit.00:38
=== ljp is now known as lpotter
=== salem_ is now known as _salem
=== zsombi_ is now known as zsombi
pittiGood morning07:17
pittijuliank: heh, thanks for pointing out; noted07:18
pittiinfinity: right, I added a WI to add Test-Depends:; I'll do this after the britney Merge From Hell07:19
pittiinfinity: heh, three trailing dots don't work any more07:21
juliankpitti: 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
juliankubuntu1 breaks the APT test suite...07:26
pittijuliank: if dpkg migrated, then the apt autopkgtest will run against htat07:27
pittiit doesn't remember an "original env" and tries to reconstruct it with earlier package versions07:27
pittithat would be fairly pointless, a lot of work, and totally not robust07:27
juliankpitti: Oh, I misread the logs.07:27
juliankOK, that's great then07:28
pittitinoco, infinity, xnox: aupkg01 ( is still AWOL; can you please revive it? http://autopkgtest.ubuntu.com/running.shtml has a desperately long s390x queue.. :(07:36
juliankpitti: 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
pittijuliank: it didn't fail, it'll retry again in a bit07:40
pittijuliank: the workers are hammered right now, so clouds run out of space07:40
juliankI can believe that07:41
juliankDamnit, the apt autopkgtests are failing07:44
pittithey've been failing for a while07:44
pitti(in y)07:44
juliankpitti: Yeah, but those were weird.07:44
juliankMaybe it's still a cause of the dpkg thing07:44
juliankWe'll see once dpkg has migrated...07:44
juliankNot so sure about test-apt-tagfile-fields-order07:45
juliankYep, it's a "real" problem. We don't know the Testsuite-Triggers source field yet -> that fails the test07:51
juliankI failed to notice that because I only upgraded dpkg, not libdpkg-perl07:52
juliankBut that only means we have no specified order that field when sorting07:52
juliankThe apport tests fail with the new apt which now raises E:The repository 'http://ddebs.ubuntu.com trusty Release' is not signed.08:02
pittiI'll look into that08:03
juliankLog https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/a/apport/20160708_072803@/log.gz08:04
* juliank wonders why the python-apt tests fail08:04
xnoxdoko, ha ha ha ha =)08:31
xnoxtold you germany will play wales for the third place ;-)08:31
pittithere actually is no game for the third place08:32
infinitypitti: Any thoughts on my libnss-resolve bug?08:42
pittiinfinity: 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 it08:44
pittias three dots don't work, there is no systematic "ignore trailing dots", so this just sounds like a too lax trailing dot check08:44
infinitypitti: 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:45
infinitypitti: Anyhow, it was mostly a question of "should I just ignore the glibc failures for now, or can we fix it soon?"08:46
pittithis doesn't look intended08:46
pittiinfinity: 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
pittiinfinity: but  glibc built, didn't it? i. e. is that actually blocking you?08:47
infinitypitti: Actually, wait.  Why is libnss-resolve in my autopkgtst chroot in the first place?08:47
infinitypitti: glibc built, sure, cause libnss-resolve isn't in buildd chroots.  It's the autopkgtests that fail. :P08:47
pittiit's certainly not in build chroots, yes; but we do install it by default now, because servers08:47
infinitypitti: Sure, but autopkgtests are supposed to test against a minimal base, I thought?08:48
infinityOr do we test against standard intentionally?08:48
pittiinfinity: more or less; it's a cloud image with the most obvious crap purged, but it's certainly far from minimal08:48
infinitypitti: Hrm.  Kay.  Perhaps we can impove on that $later, but today, I'll just ignore that failure.08:49
pittibut actually, testing stuff with the low-level plumbing things we install by default actually seems better08:49
pittiinfinity: yeah, no problem with hinting over that one, as we understand what it is08:49
infinitypitti: 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
pittialso, queues are still uber-full anyway (particularly s390x)08:49
infinitypitti: But yes, maybe minimal+standard is the better baseline, since that08:50
infinity's what we consider "Ubuntu".08:50
rbasakpitti: why not start with debootstrap + tasks instead of cloud images - stuff?08:51
pittirbasak: the cloud images are all that I have in scalingstack08:51
pittiI create my own images from those plus http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed which purges a lot away08:52
pittirbasak: minimal deboostrap-like images are being used with lxc/lxd, thouhg (on armhf/s390x)08:52
rbasakpitti: could you access the (original) core tarballs for example?08:53
pittirbasak: no -- they aren't bootable at all08:53
pittiyou need a kernel, grub, cloud-init, etc.08:53
pittiI don't want to get into the business of building cloud images from scratch08:53
pittialso, that'd be too synthetic -- we want to test stuff in an env whose base/plumbing bits are what we actually ship08:54
rbasakIt just feels fragile to take the cloud images and then strip stuff away, that's all.08:55
pittiwell, having all this non-standard stuff installed breaks stuff (lvm2, command-not-found, lxc, etc.); but Priority: standard" should stay IMHO08:56
pittiwe don't have lean cloud images, we just have those chubby ones which are optimized for human usage, not for actual cloud "cattle" usage08:57
pittibut I've given up on this :)08:57
rbasakI believe the decision is to prefer to have a single image suitable for both uses.08:57
rbasakSo not too chubby, not too lean.08:57
pittiyes, which I heavily disagree with, but as I said I've given up on this08:58
rbasakRather than confusing things by having two sets.08:58
rbasakBut unfortunately that makes them unsuitable for the autopkgtest case.08:58
pittiwe penalize millions of cloud instances/users for that, but *shrug*08:58
rbasakCloud users generally don't have to download an image. The cloud provider already hosts them.08:58
rbasakAnd disk space is usually not the bottleneck.08:59
pittiit's disk space (density), download and upgrade time08:59
pittiplus excess runtime (having mdadm/lvm2 in the boot path, apt-xapian-index daily cron jobs, etc.)09:00
pittiplus, as we also advertise them for lxd, it actually *is* download time too09:01
rbasakIf it's a choice of penalising that or penalising developers for not having stuff available, I'd prefer the former.09:02
rbasakIn the case of lxd, I *want* this stuff in the images.09:02
pittiright, and that's what I disagree with -- most cloud images are not being used in an interactive way09:02
rbasakTrue, but most engineering time on images is spent in an interactive way.09:02
pittiand 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 themselves09:03
rbasakAnd it is engineering time that is the most expensive.09:03
rbasakThat would slow down every image boot.09:03
rbasakFinally, after my engineering, I want to deploy the same environment without changing it.09:03
pittithe "classical human server" use case isn't that you re-create them often09:03
pittithis was supposed to replace the ubuntu server image09:03
pittiwell, I made my point, let's agree to disagree09:04
pittiyou won't convince me, and after discussing it several times I accept that I won't convince you09:04
LaneyI was thinking about something like this the other day09:05
rbasakI used to work on a deployment that was "lean". I replaced it in the end.09:05
rbasakIt's too painful to deal with operational issues when nothing is available.09:05
LaneyMaybe super minimal is even an anti-goal09:05
Laneyin the real world people run with all sorts of crud installed, and things should still work09:05
pittirbasak: installing iscsi, lvm2, mdadm, and apt-xapian-index into every LXD container is not "lean" or even useful, it's just bloat09:06
pittino developer will ever need that09:06
Laneyor handle gracefully their lack of working09:06
rbasakWhen 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
rbasakEven 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:07
ppisati_doko: wasn't there a way to switch toolchain (or in my case cross-toolchain)?09:09
rbasakMaybe 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
ppisati_doko: the kernel i'm working on, doesn't compile with gcc-5 but it does with gcc-4.709:09
ppisati_doko: i installed the gcc-cross-...armhf-4.709:09
dokodepends on the package you want to build ...09:09
ppisati_doko: kernel09:10
dokobut CC=... CXX=... should work09:10
ppisati_doko: nope, because you pass09:10
ppisati_doko: export CROSS_COMPILE=arm-linux-gnueabihf-09:10
ppisati_doko: and /usr/bin/arm-linux-gnueabihf-gcc -> arm-linux-gnueabihf-gcc-509:10
dokoppisati_, I don't build kernels, maybe apw can help?09:10
LocutusOfBorgppisati_, I usually end up in doing some symlinks09:11
LocutusOfBorgI agree with you09:11
ppisati_doko: it's not a building problem, it's 'how do i make toolchain X the default toolchain'09:12
ppisati_yeah, but i've a vague memory09:12
LocutusOfBorgthe problem is that there isn't an "append" variable09:12
ppisati_of script that you could run09:12
LocutusOfBorgI mean, $CROSS_COMPILEgcc$CROSS_SUFFIX might be a nice idea09:12
ppisati_and it would switch from toolchain-X to -Y09:12
ppisati_LocutusOfBorg: right09:12
LocutusOfBorgppisati_, BTW there are trivial fixes for gcc 5 and kernel09:12
LocutusOfBorgI ended up in adding them09:13
infinitypitti: You can probably replace that hardcoded list of packages in the "bloat removal" with "apt-get purge server^"09:13
LocutusOfBorgI'm pretty sure you are referring to the failures related to inline09:13
ppisati_LocutusOfBorg: yep, but sometimes kernle's vendor X require only that toolchain Y, so i can't easily switch09:13
LocutusOfBorgI suggest you a CROSS_SUFFIX feature request ;)09:13
LocutusOfBorgI'll use it too ;)09:13
dokoppisati_, I don't support making random toolchains the default. best thing then to create your own bin dir with new symlinks09:14
LocutusOfBorgexactly what I did09:16
infinityppisati_: What's wrong with patching the Makefile for CC = gcc-4.7?09:16
LocutusOfBorginfinity, no09:16
infinityLocutusOfBorg: Because?09:16
LocutusOfBorgcross compiling works differently09:16
LocutusOfBorgthey use something like09:16
pittiinfinity: nice, I'll try that09:16
infinityLocutusOfBorg: I know how cross works.09:16
LocutusOfBorgCC=$CROSS_COMPILE-gcc :)09:16
infinityLocutusOfBorg: Fine, s/gcc/gcc-4.7/09:16
infinityLocutusOfBorg: If it needs 4.7, it needs it natively and cross, so it should be reflected in the Makefile, not the environment.09:17
LocutusOfBorgso, better is to s/gcc/GCC$CROSS_SUFFIX idea I told him :)09:17
LocutusOfBorgthis might be upstreamable09:17
infinityNo.  CROSS_SUFFIX is wrong.09:17
LocutusOfBorgcalling it GCC_VERSION?09:17
infinityThese kernels need 4.7 for native *and* cross.09:17
infinityAnd none of this needs to be upstreamed in his case.09:18
LocutusOfBorgI had the use case of a kernel that was segfaulting when built with 4.7, and not with gcc-4.309:18
LocutusOfBorgI would have used the feature09:18
LocutusOfBorgsometimes you have to test different cross compilers, not just always the same09:19
LocutusOfBorgbut I agree with your solution :)09:19
infinityBut if you know you need 4.3, you change the Makefile.  Why is that hard to grasp?09:19
LocutusOfBorgbecause 4.3 disappeared from the main repo :)09:19
LocutusOfBorgso, sometimes people needs to move on09:19
LocutusOfBorgand try newer toolchains :)09:20
infinityThen the software becomes FTBFS.09:20
infinityUntil the Makefile changes.09:20
infinityThat's fine.09:20
LocutusOfBorgyes, and I usually fix the FTBFS09:20
infinityYou don't claim "any gcc will work" when that's known to be untrue.09:20
LocutusOfBorgbut in the meanwhile, the software might not FTBFS but misbehave09:20
LocutusOfBorgso, having a CROSS_COMPILE=arm-foo- GCC_VERSION=4.7 make09:21
LocutusOfBorgis trivial and a nice way for testing different toolchains09:21
LocutusOfBorgbut ECHAN09:21
infinitydoko: Well, I fixed *a* bug in the cross-toolchain-base debian/rules, but it wasn't *the* bug.  Back to investigating, I guess.09:21
LocutusOfBorgBTW the sed should be propagated in many places, e.g. gcc, ld, ar, as, nm in tools/* and so on09:22
ppisati_i really didn't want to change symlinks, but it seems it's the only way09:22
infinityppisati_: Err, wat?  We have lots of kernels in the archive that build with non-default GCC.09:23
infinityppisati_: It's trivial, and doesn't require mangling symlinks.09:23
ppisati_infinity: if i'm on a xenial box the default is gcc-5 but i want to use different one09:24
infinityppisati_: Yes, so change it in the Makefile.09:24
ppisati_infinity: no, because i don't want to enforce a version09:24
infinityppisati_: But... You do.09:24
ppisati_infinity: people should be able to pass it via the CROSS_COMPILE stuff09:24
ppisati_infinity: no i don't09:24
infinityppisati_: If you don't want to enforce a version, why are you changing the version?09:24
infinityppisati_: That makes zero sense.09:25
mptbdmurray, 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
infinitympt: How is that a bug?09:26
ppisati_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 it09:26
ppisati_infinity: what does it do?09:26
ppisati_infinity: does it patch the makefile locally himself?09:27
infinityppisati_: It fails until they alter the Makefile.  Sure.  *shrug*09:27
mptinfinity, because the list header says “Error reports sent from this system” and they aren’t09:27
michael-vbsladen: it never hurts to check an updated software version, but I admit I also looked at the changelog and had my doubts.09:27
infinitympt: Oh, I was thinking of a different UI elsewhere.  Nevermind.09:27
LocutusOfBorgppisati_, this is why I'm thinking about a GCC_VERSION suffix variable09:28
LocutusOfBorgyou can just export it, with the correct value09:28
LocutusOfBorgI have collagues with older ubuntu, some others with debian09:28
infinityppisati_: 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
LocutusOfBorgI face similar issues on a daily basis09:28
LocutusOfBorginfinity, it doesn't really scale09:28
infinityppisati_: 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
LocutusOfBorgnope, it doesn't build with gcc>=509:29
LocutusOfBorgthis doesn't mean it only works with 4.709:29
LocutusOfBorgwhat I do in my company is to build yocto cross-toolhchains09:29
infinityLocutusOfBorg: I'm assuming 4.7 because he's not using 4.9. :P09:29
LocutusOfBorgand give them to my colleagues09:29
infinityAs for "scaling", neither do magic environment variables.09:30
infinityAnd they lead to completely unreproducible build environments.09:30
LocutusOfBorgactually they mostly do the trick09:30
LocutusOfBorg+1 for the second sentence09:30
LocutusOfBorgactually sometimes an use case is to test different environments :)09:30
infinityAnyhow, linux-goldfish has "CC              = $(CROSS_COMPILE)gcc-4.709:30
infinityI'm curious why that's not doable for ppisati_'s other kernel.09:31
LocutusOfBorgthis fix is good for ubuntu, but e.g. won't be good anymore on the next ubuntu09:31
infinityIt's intentionally not good for the next Ubuntu.09:31
infinityIt's set to 4.7 because that's the compiler that works to build that kernel.09:31
infinityIf all GCCs worked, it wouldn't have the version appended.09:32
infinityBut I'm done talking in circles.09:32
apwinfinity, right we would expect him to do that linux-goldfish thing ... ppisati_ ^09:43
ogra_eventually the phone guys need to lift the emulator to android 5 ...09:48
ogra_which should hopefully come with a newer kernel09:48
ogra_you shoudl poke them ;)09:48
infinityogra_: Not actually the concern here, but agreed, if you mean Android 6... Or 7. ;)09:49
ogra_well, whatever the latest phones are on (iirc thats still 5)09:50
infinitypitti: 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
pittiinfinity: yes, see my ping from yesterday and from this morning09:50
pittione machine is down09:50
ogra_on a sidenote, the emulator hasnt worked for the last three OTAs or so09:50
infinityogra_: My Nexus 5 is on Android 6.0.1.  7.x comes out this fall.09:51
pittiwhich is half of our capacity09:51
pittiinfinity: normally s390x is the fastest one :09:51
infinityogra_: Unless you meant the current Ubuntu phones.09:51
ogra_infinity, yes, and victors team just works on porting hybris to 6 i think :)09:51
infinityogra_: In which case, that should be upgraded some day too. :P09:51
ogra_infinity, indeed i do ... i'm talking about the emulator and your gcc issue :)09:51
infinityxnox: Can you rescue pitti's lost s390x z/VM?09:51
xnoxinfinity, let me see09:52
infinityogra_: 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
ogra_which will move the gcc issue magically to a newer version (and bite again in a year or so :) )09:53
xnoxpitti, do you remeber the login name for the z/vm?09:54
xnoxfound it09:55
pittixnox: yes, aka
infinityThe new Bond villain.09:55
xnoxpitti, infinity: AUPKG01 is booting09:57
infinityxnox: Ta.09:58
pittixnox: cheers09:58
xnoxpitti, do i need to revive AUPKG02 too?09:58
pittixnox: no, that's fine09:58
pittixnox: we installed crashdump on those back then09:59
infinityxnox: Lunch?10:00
* infinity heads down from the lab.10:00
pittixnox: where would they be? (the crash dumps)10:00
pittithere's just a /var/crash/kexec_cmd10:00
mptbdmurray, reported bug 160017810:28
ubottuError: Launchpad bug 1600178 could not be found10:28
LocutusOfBorgAdri2000, libfilezilla didn't have a soname bump10:51
ubottuDebian bug 830474 in filezilla "filezilla: Version 3.19 must depend on libfilezilla 0.5.3" [Normal,Open]10:51
LocutusOfBorgdamn, please bother upstream about that10:51
infinityLocutusOfBorg: Added symbols aren't ABI breaks.11:02
infinityLocutusOfBorg: Looks more like the shlibs need bumping (or a proper symbols file needs to be added).11:03
LocutusOfBorginfinity, yes, indeed11:41
LocutusOfBorgI didn't see any ABI breakage when sponsoring11:42
LocutusOfBorgand indeed I missed to check new symbols on filezilla11:42
infinityBut yeah, that library could do with a symbols file.11:43
LocutusOfBorgno, I mean, I didn't check if the new filezilla was using new symbols from libfilezilla11:43
infinitySure, but you shouldn't have to, if the lib is properly packaged. :)11:43
LocutusOfBorgI leave the task to Adri2000 :)11:44
=== rbern_ is now known as rbern
=== hikiko is now known as hikiko|ln
alexbligh1On 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
alexbligh1s/with systemd/with systemd on 16.04/12:14
sladenalexbligh1: presumably an issue in the way that bind9 is wrapped/packaged.  Can you get a bug into launchpad/debbugs with as many details as possible12:17
alexbligh1sladen, sure. Just checking it wasn't me being dumb.12:17
sladenalexbligh1: yeah, even in the worst case, it should allow others to find the discussion (and then it won't feel so dumb :)12:18
alexbligh1sladen, 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
ubottuLaunchpad bug 1600210 in nbd (Ubuntu) "bind9 RESOLVCONF does not work" [Undecided,New]12:24
sladenalexbligh1: 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
ubottuDebian bug 744304 in bind9 "bind9-resolvconf.service immediately stopped after starting" [Important,Open]12:28
=== _salem is now known as salem_
alexbligh1sladen, hmm, that service is showing as disabled.12:32
alexbligh1sladen, ok, with a bit of poking around, and applying the fix in that bug, I got it to work - thanks!12:51
=== hikiko|ln is now known as hikiko
rbasakalexbligh1: thank you for the report. I've marked it for assignment soon (I generally trust your reports to be high quality)13:00
* ogra_ shakes his head ... 13:06
ogra_weird times where s3390x, ppc64el and arm64 are always buildingimages faster than any x86 arch13:06
pitticjwatson: 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
infinityogra_: Not so werid for the first two.13:12
infinitypitti: Not for backward compat reasons, just unimplemented features.13:12
sladenkudos to both alexbligh1 and rbasak !13:12
cyphermoxgood morning!13:22
alexbligh1rbasak, sladen thanks!13:23
=== dpm is now known as dpm-bbiab
=== marga_ is now known as marga
cjwatsonpitti: 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" link13:58
pitticjwatson: thanks14:07
=== dpm-bbiab is now known as dpm
pittiinfinity: good timing -- we actually did get a new perl right after glibc :)14:23
highvoltagewin 3014:29
marlincIs there anything I can do against gbp buildpackage running the tests as root in the chroot?14:49
rbasakUse a container perhaps?14:51
rbasakI'd like to see a schroot driver that uses lxd.14:51
dobeydoesn't it use fakeroot?14:53
dobeyor is it not using pbuilder/sbuild, which i thought dropped privs to do the actual build?14:54
marlincI'm actually unsure. This is the first time packaging something14:54
marlincI noticed that the tests are failing as Apache (its part of the tests) does not allow the WSGI module to run as root14:54
dobeynot sure, as i've not used gbp before14:55
marlincInteresting, all of the files in the chroot are owned by the pbuilder user but it appears the Makefile is being run as root14:57
marlincActually, wait14:58
cjwatsonmarlinc: 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:20
rbasakWhat I said makes no sense, sorry.15:22
rbasakI was thinking of other things, not being root.15:22
pittimarlinc: in some of my packages I run "env -u LD_PRELOAD make" in override_dh_auto_test: for that15:31
pittiunfortunately dh_auto_test runs in the fakeroot part by default15:31
pittimarlinc: err, "make check" of course, not just "make"15:31
cjwatsonpitti: err, it does?15:32
pittiapparently so15:33
cjwatson/usr/bin/dh seems quite clear that it runs in the build part15:33
infinityYeah, it shouldn't run in the binary bit.15:33
cjwatsonI think you have some other subtle bug if it's running under fakeroot; it doesn't by default15:33
cjwatsonI suspect marlinc may have a simpler problem if this is their first package though15:34
marlincIt  was running as root because I was being dropped into a shell which was root15:34
infinityNote auto_test between build and testroot.15:34
marlincI switched to the pbuilder user and then it ran15:34
cjwatsonmarlinc: ah, even simpler, I guess.15:34
marlincNow 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 102415:35
pittimaybe that got fixed in the meantime, but I had to add this hack to more than just one override_dh_auto_test in the past15:35
pittiI'll try dropping them, thanks for pointing out15:35
infinitymarlinc: So, you have a schrödintest that wants to run both as root and not root?15:37
cjwatsonmarlinc: I think you'll have to arrange to run it on some other (preferably non-fixed) port somehow.15:37
cjwatsonIt's not totally uncommon for tests to be somewhat badly written until packagers get to them and fix them up. :-)15:38
marlincI guess so yes... I'm talking with the developer of the project. There's probably something the Fedora packaging thing does15:38
marlincThey themselves run the tests as non root as wel15:38
cjwatsonYeah, most distros build packages as non-root.15:39
tdaitxslangasek, 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
ubottuLaunchpad 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/155095016:03
ubottuLaunchpad 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/160026916:04
tdaitxProvides: java-sdk, java2-sdk, java5-sdk, java6-sdk,16:04
tdaitx  java7-sdk, java8-sdk, java-compiler16:04
tdaitxslangasek, 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:05
tdaitxnote: openjdk-9 is available for both xenial and yakkety in universe16:07
infinitytdaitx: Things are supposed to depend on default-jre as a preferred alternative, but I suppose we can't control random packages in PPAs.16:08
infinitytdaitx: The file overlap bug should be fixed regardless.16:09
tdaitxinfinity, that package depends on java-sdk, it can't depend on a jre16:09
infinitytdaitx: Well, default-jdk then. :P16:10
tdaitxinfinity, ugh, of course16:10
tdaitxmy bad16:10
* tdaitx needs more coffee16:10
infinitytdaitx: 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
tdaitxinfinity, I agree16:11
infinityAnd 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:14
marlinccjwatson, I was told that they were using some kind of wrapper that allows those things to run as root. Some kind of virtual network stack16:15
marlincAh libsocket_wrapper16:15
cjwatsonyou could certainly LD_PRELOAD a thing that fakes up the socketry16:15
cjwatsonand I see libsocket-wrapper is even packaged for us as well; looks plausible.16:16
marlincAh, they do that already16:16
cjwatsonmaybe you just need to build-depend on it.16:16
cjwatsonright, so that suggests you want to Build-Depends: libsocket-wrapper, libnss-wrapper16:17
cjwatsonthough it would appear to fail right now if they're unavailable?16:17
cjwatsonoh, no, only if specifically requested16:17
cjwatsonso yeah, build-depends ought to improve your life.16:18
marlincJust added them, lets see what happens16:19
rbasakinfinity: stepping on a UK power plug is worse. The way they're designed the prongs stick up :-/16:26
infinityrbasak: My shattered kneecap will send your punctured sole a get well soon card.16:27
cjwatsonIRTA soul16:28
cjwatsonWhich made the comment considerably more goth.16:28
tdaitxinfinity, thanks for the help, and I wish your kneecap a good recovery16:28
rbasakI did that too :)16:29
infinitycjwatson: *smirk*16:29
infinityPunctured Soul isn't a bad band name.16:30
naccrbasak: it might be a bug (in debian too), due to 0014-force_libmysqlclient_r.patch16:31
naccrbasak: well will be one in debian16:31
infinityAhh, did _r finally go away?16:33
rbasakAh yes, that'll be it. Thanks.16:33
rbasak_r was a symlink in 5.6. It's gone in 5.7.16:34
infinityAbout time.16:34
naccrbasak: can you file a debian bug? i'm guessing we'll need 16.04 and 16.10 bug tasks? I can also file it16:34
rbasaknacc: will do.16:34
naccrbasak: although debian hasn't gone 5.7 fully, right? so they might need some twiddling16:34
infinitynacc: If, as rbasak says, it's a symlink in 5.6, backing out the patch now won't hurt.16:34
rbasakThat's a point. It's not strictly a bug in Debian yet. It will be soon.16:34
rbasakBut yes, the patch won't hurt.16:35
naccinfinity: yeah16:35
rbasakIIRC it's a symlink. I'm told by upstream that it's definitely unnecessary to use _r in 5.6 however.16:35
rbasakUpstreams may have a little more trouble if they want to maintain build compatibility against older versions.16:35
naccrbasak: 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
naccdigging a bit further to see if i can extract what gets configured16:35
rbasaknacc: 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:36
naccrbasak: sure, np, i'll keep digging on this, thanks for bringing to my attention16:37
mitya57slangasek, hi, you said that you triggered a no-proposed retest of python-cryptography, but there's no difference17:54
mitya57It's now the only blocker for sphinx migration17:54
slangasekmitya57: 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
slangasekmitya57: 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 bad17:56
mitya57Actually I still don't understand what's wrong with that cffi-backend dependency (because of which python-cryptography itself can't migrate)17:59
jbichais python-crypto related to the versioned provides issue mentioned at https://lists.ubuntu.com/archives/ubuntu-release/2016-July/003798.html ?18:16
mitya57jbicha, looks like it is, thanks!18:24
mitya57(though python-crypto ≠ python-cryptography)18:24
=== NCommander is now known as mcasadevall
=== mcasadevall is now known as NCommander
nacc_rbasak: practical question for you, there's a bug filed in debian to update to 2.6.11, and i'm finding htat the 2.6.6 packaged in yakkety, while significantly better, is hitting a number of bugs i know are fixed in 2.6.11. I'm backporting those fixes to my PPA for testing, but I wonder how/when we decide to pick up a new upstream ahead of Debian? `uscan` with the current package sees the new upstream20:15
marlinccjwatson, how can I check if OpenLDAP has a particular backend compiled in?20:23
marlinc#    --enable-mdb         enable mdb database backend no|yes|mod [yes]20:25
marlincI guess that means that it is20:25
jrwrenunless configure is invoked with --disable-mdb in debian/rules20:28
tarpmanmarlinc: if you're looking at the openldap package in ubuntu, the relevant configure.options line is --enable-backend=mod - we build all the optional backends as loadable modules20:29
marlincAh mm okay20:29
marlincI can't find any mdb package. I'm actually unsure what that backend is but it is required by unit tests run by Ipsilon which I'm trying to package20:30
tarpmanmarlinc: no idea what Ipsilon is. are you looking for openldap's mdb backend, or the lmdb library itself? that's in a separate library package, src:lmdb20:34
marlincThe mdb backend20:35
tarpmanmarlinc: or do you mean ipsilon needs to configure and run a slapd instance20:35
marlincIpsilon is a web identify provider for SAML, OpenID, etc20:35
marlincNo, it just uses it in the unit tests to check whether it can work with a LDAP server as backend20:35
marlincAnd its unit tests set up a OpenLDAP server using the mdb backend20:35
marlinctarpman, https://pagure.io/ipsilon/blob/master/f/tests/slapd.conf#_1620:36
tarpmanyeah, looking at that20:36
tarpmanthat slapd.conf is assuming the redhat/fedora openldap package layout20:37
tarpmanwe have /etc/ldap, not /etc/openldap20:37
marlincYea, I fixed most of that already20:37
tarpmanand you'll need to load the back_mdb module; redhat have linked it right into slapd20:37
marlincAh, so its loadable?20:37
marlincInteresting, let me see how I can do that20:37
tarpmanadd 'moduleload back_mdb' somewhere near the top20:37
marlincLets try that20:38
tarpmanbefore any of the database or access definitions20:38
slangaseknacc_: regarding pulling a new upstream version before Debian, this is OK to do whenever you think it's justified in terms of Ubuntu's quality; the one caveat I have is that if upstream doesn't provide a release tarball that can be imported byte-for-byte, we can get into trouble later with syncing/merging when Debian ends up with a different tarball than we do20:38
marlincI thought I had to install a separate package for that20:39
tarpmanno, all the core plugins (backends/overlays) are included in the slapd package20:40
marlincLets see what the tests do now ;)20:40
marlincThanks a lot20:40
marlincThe slapd based tests now succeed, thanks!20:44
nacc_slangasek: ok, it shoudl be identical in this case21:03
nacc_slangasek: (using uscan for obtaining it in both cases)21:03
nacc_slangasek: i'm filing bugs against the debian version of cobbler too, but honestly, i'm hopefuly they'll just update too and we can sync21:04
nacc_slangasek: thanks for the clarification!21:04
slangaseknacc_: uscan can get fancy - if it's only downloading a fixed tarball, perfect.  If it's repacking things for you under the hood, not so perfect ;)21:04
nacc_slangasek: right, i'll double-check that, thanks for the reminder21:04
nacc_slangasek: that would normally be seen with a 'repack=' in debian/watch, right?21:06
nacc_slangasek: i'll also of course check the orig.tar.gz it produced21:07
Unit193That's interesting, it's 'dfsg' but nothing in d/copyright, no get-orig-source, and of course no watch magic..21:09
nacc_Unit193: you're referring to cobbler? yeah, i was seeing the same thing :)21:09
Unit193(Figured I'd take a quick look.)21:10
nacc_also i dont' see how they can claim that it works for openstack in debian (from the original packaging bug). I've found at least two basic issues that prevent it from working at all :)21:10
nacc_Unit193: thanks for taking a look and confirming what i was seeing!21:11
Unit193nacc_: Sure, didn't do much.  And of course d/changelog has nothing so one would have to actually diff, wow..21:12
nacc_Unit193: it might just be the jquery bits21:13
rbasaknacc_: we can go ahead of Debian any time we like. The only real criteria is that we're prepared to look after it that way until we're in sync again.21:14
rbasakIt's nice to send them patches, of course, but it's not unusual for them to take time to pick that up and update when we want it sooner.21:14
nacc_rbasak: yep, i'm hoping that debian will respond to the bug already filed there, but then again there hasn't been much movement on cobbler since 2.6.6 was pacakged (afaict). I'm happy to watch cobbler in ubuntu, but 2.6.11 is a big improvement in a lot of ways (especially for IBM's hardware, as that was why i was working on it :)21:15
marlincSomeone with experience with characters and newlines not appearing in a terminal?21:15
marlincroot@marlinc-laptop:/tmp/buildd/ipsilon-1.2.0# bash: aaaaaaaa: command not found21:15
marlincIt happens every so often21:15
rbasaknacc_: the risk is that if Debian is taking a while now, that may be an indication that you're looking after it for a long time before you can sync again.21:16
rbasaknacc_: from a Canonical perspective I think we can spend time on returning it back to Debian, but I'm not sure that time spent maintaining it ahead of Debian is justified.21:16
nacc_rbasak: yep, it's a tough balance21:20
nacc_rbasak: but even the debian package as-is needs fixes (which i'm working my way through)21:20
nacc_rbasak: most of which are fixed upstream already21:20
nacc_rbasak: i would almost be willing to do this as a contribution to Ubuntu, rather than anything to do with Canonical, as what's shipped now is bad and i'm tired of telling users to build from source because debian & ubuntu have old/bad packages :)21:21
rbasaknacc_: you're welcome to do that :)21:38
marlincAre non build dependencies also being installed when building a package?21:38
nacc_marlinc: not sure i fully understand your question -- but i believe only the listed build-dependencies are installed to build a package; are you seeing a different behavior?21:56
marlincI was just wondering21:56
marlincI thought that it might actually install all dependencies for the package in the build environment21:57
nacc_marlinc: it would depend on what 'it' is in your sentence; but i don't think that's generally true21:58
Unit193nacc_: And yeah, that's never fun, nor when upstream does it because of getting bugs that've been long fixed. :/21:59
nacc_Unit193: yep22:00
marlincNvm nacc_22:13
marlincDoes anyone know  of a particular way to run tests as a non root user? I'm using pbuilder using gbp buildpackage to build the package22:15
marlincActually, let me check how the Makefile gets executed because its running as non root already but I'm getting a few permission errors22:17
marlincMm actually, no22:17
marlincuid=0(root) gid=0(root) groups=0(root),1234(pbuilder)22:17
nacc_marlinc: do you mean the debian/tests tests?22:18
marlincNo, debian/rules is running the tests in the Makefile. (By default it appears)22:19
nacc_marlinc: oh you mean during the build?22:20
nacc_marlinc: i've not used pbuilder, but sbuild should dtrt, in my experience (and it doesn't build as root)22:21
marlincThe Makefile is being run by root which in turn causes the unit tests to be run by root as well22:21
marlincMm okay22:21
nacc_marlinc: builds should not be run as root generally (afaik)22:21
Unit193nacc_: The build is run under fakeroot either way, sooo.22:21
marlincAh Unit193 that could be it22:22
nacc_Unit193: ah22:22
marlincThen I guess I will have to find a way to run a particular part without fakeroot?22:22
marlincIn this case a Apache module that is used in the tests is not willing to run as 'root'22:23
nacc_marlinc: what package is this? your own?22:24
marlincI'm trying to build a Debian package for Ipsilon22:24
marlincThere's not package out for Debian yet22:24
sarnoldtry prepending LD_PRELOAD=""  or "unset -v LD_PRELOAD" or something similar22:24
sarnold(keeping in mind that every single line in a Makefile is run in its own shell)22:25
Unit193https://wiki.debian.org/FakeRoot and yeah, don't think in pbuilder that'd be enough, though?22:26
marlincIt appears I have to su to $BUILDUSERID?22:26
marlincThat environment variable is not set however22:27
sarnoldUnit193: I suspect the pbuilder just runs something like "fakeroot make ..." and lets LD_PRELOAD propogate through all child processes; if you unset LD_PRELOAD before running a command in the middle, that should stop it..22:28
marlincIt appears to be doing this22:29
marlincmake: 'build' is up to date.22:29
marlinc fakeroot debian/rules binary22:29
marlincLet me see22:29
marlincSetting LD_PRELOAD="" in the Makefile appears to work22:35
marlincI see, dh_auto_build runs make -j1 which then starts the tests etc22:36
cjwatsonmarlinc: If pbuilder is running the build target under fakeroot, it's buggy IMO.  Only the binary target should be run under fakeroot.23:27
cjwatsonmarlinc: I don't think you should have to work around foolish tools running the build target under fakeroot.23:28
marlincI'm not sure what's up but the Makefile gets run from the binary target as far as I can see23:28
marlinccjwatson, do you know of a Python application that uses setup.py that I can look at as a reference?23:35
marlincopenstack-dashboard doesn't use setup.py unfortunately23:36
cjwatsonmarlinc: Perhaps you could pastebin your current debian/rules23:36
cjwatsonmarlinc: and do you have a build log?23:37
cjwatsonmarlinc: germinate is the first thing that comes to mind that meets your stated requirements, but it may be a bit overcomplicated.23:37
cjwatsonmarlinc: you need to be more specific about what you mean by "the Makefile gets run from the binary target" - "make" will likely be run both from (indirectly) build and binary, with different arguments (make vs. make install, say)23:38
marlinccjwatson, just leave the root issue for now I guess. :)23:38
cjwatsonmarlinc: I don't think you will be better off trying to sweep this under the carpet and ignoring it23:39
marlincI'm not planning on ignoring it23:39
Unit193Disclaimer: I don't know pbuilder internals, though would presume it's not doing stupid things.23:40
cjwatsonmarlinc: you're describing a behaviour which is alien to me (from 15+ years of building Debian-format packages), and my instinct is that this kind of thing is better off investigated early23:40
cjwatsonas otherwise you can end up wasting your time on knock-on effects23:40
marlincOkay, well lets start the build23:40
cjwatsonmarlinc: it's also weird that you're having to explicitly log into the chroot and su and stuff23:41
cjwatsonmarlinc: I thought you were meant to use pdebuild or whatever it is and have that do the whole thing for you23:41
cjwatson(I use sbuild, but the principle should be the same)23:41
marlincI only had to because the tests were failing because of the root issue. Setting LD_PRELOAD="" worked around the issue23:41
marlincLet me remove the statements and see where it goes wrong23:42
marlincI'll Gist the output23:42
* cjwatson -> children's bedtime23:43

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!