[00:01] <doko> tumbleweed, jtaylor, barry, pitti: migration of python-numpy is needed for the python3.4 removal. any ideas?
[00:03]  * tumbleweed looks
[00:05] <barry> numpy itself is failing, but maybe that's shallow
[00:05] <barry> (failing on py27?)
[00:15] <jtaylor> doko: whats blocking it?
[00:15] <jtaylor> oh the failure itself is simple
[00:15] <jtaylor> too bad morph doesn't care about adt tests :(
[00:16] <jtaylor> df70490874e33e1fad18720f5c74fb5e319c9e06 is the fix
[00:16] <jtaylor> fwiw scipy will fail with that numpy but an upload for that is waiting on a sphinx update
[00:17] <jtaylor> should be done soon
[00:19] <doko> jtaylor, well, then why does he add these?
[00:19] <jtaylor> doko: I added them
[00:19] <doko> bad jtaylor ;-P
[00:51] <tsimonq2> ok, so I really don't know who to contact so I came here. I was looking at FTBFS and I noticed hplip was failing builds. So I peeked at the logs and it had a dependency error of cups that was already in the repos. On my machine, the build was successful. Where should I file a bug? Who should I report it to?
[00:52] <tsimonq2> and it builds successfully upstream
[00:52] <tsimonq2> hplip is in main
[00:53] <tsimonq2> should this go in #ubuntu+1-maint?
[01:20] <cjwatson> tsimonq2: Probably fixed by the recent promotion of liblouis-bin to main.  I've retried the failed builds.
[01:21] <tsimonq2> cjwatson: ok thanks
[01:22]  * tsimonq2 watches the builds :D
[01:58] <Pharaoh_Atem> woo!
[01:58] <Pharaoh_Atem> I've finally made progress on the apache configs for php7.0
[02:27] <tsimonq2> can this bug be attached to apt in FTBFS? thanks! https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923
[02:28] <tarpman> mdeslaur: don't suppose you would have any insight into bug 1537762...? bit short on details unfortunately
[02:34] <sarnold> tarpman: it reminds me a little of https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1534230  -- the openssl s_client and openssl x509 advice there may help debug that
[02:34] <sarnold> pity these bugs elide the useful details; it'd take one of us a few seconds to check.. oh well.
[02:35] <tarpman> to be fair, slapd's logging of tls errors leaves something (a lot) to be desired... I have a wishlist bug for that around here somewhere :)
[02:35] <sarnold> hehe :)
[02:35] <tarpman> yeah, that definitely looks relevant. thanks, posting the link now (unless you beat me to it)
[02:36] <sarnold> go ahead
[02:36] <tarpman> I always have to /whois you to remind myself you're not my former coworker with the same first initial last name :P
[02:37] <sarnold> the guy who's been stealing my username!
[02:37] <tarpman> heh, I don't think he IRCs...
[03:02] <tsimonq2> I looked into devscripts on FTBFS, it seems like there is no longer a dependency problem but a build problem. Can someone please do a build to confirm this and to get bugs filed? Thanks!
[03:05] <tsimonq2> It also seems like this is a problem on our part, since Debian's autobuilders succeed: https://buildd.debian.org/status/fetch.php?pkg=devscripts&arch=i386&ver=2.15.10&stamp=1451535039
[03:26] <tsimonq2> looking at FTBFS again, can graphite2 be rebuilt? I might have some local problems but I know the dependency problems are fixed...
[05:48] <cpaelzer> good morning
[06:41] <pitti> Good morning
[06:48] <lathiat> morning
[06:49] <pitti> hey lathiat, good morning!
[06:58] <pitti> doko: looking at the regessions; I uploaded the fix for numexpr
[07:20] <pitti> doko: the "Specified path is invalid." warning in python-numpy is real, and does not happen with 1.8.2
[07:28] <pitti> doko: it tries to os.path.isdir('') which is the value of runtime_library_dirs which gets initialized to []
[07:30] <pitti> doko: this whole system_info code is new in 1.10 apparently
[07:30] <pitti> doko: I mean the part with the default_runtime_dirs, there's a few other default_*_dirs already
[08:53] <LocutusOfBorg> hi cjwatson a question wrt iulib
[08:53] <LocutusOfBorg> can I steal your merge? if so, can we fakesync it?
[08:53] <LocutusOfBorg> not sure what does it mean :)
[09:53] <henrix> pitti: may i have some tests lxc tests re-run please: run-autopkgtest -s trusty -a ppc64el --trigger linux-meta/3.13.0.77.83 lxc
[09:56] <pitti> henrix: started
[09:57] <henrix> pitti: awesome, thanks!
[10:48] <pitti> mdeslaur: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5 apparently regresses php-crypt-gpg and php-horde-icalendar, can you please have a look? (the other regressions are already overridden)
[10:50] <doko> that blocks the python3.4 removal
[10:56] <pitti> cjwatson: do you know a trick how to get the -images tarball from https://launchpad.net/~pitti/+archive/ubuntu/sru-test/+build/8897111 ?
[10:56] <pitti> or do PPAs simply not do that?
[11:21] <jamespage> cking, are the zfs package bits aiming for main inclusion for 16.04? I was pondering enabling support in ceph for zfs but would need libzfslinux-dev in main for that
[11:23] <cking> jamespage, we hoping to get it into main, I've filed a MIR, so it's Work-in-Progress
[11:25] <mitya57> pitti, can you please make qbzr autopkgtest not blocking pygments migration? It's not a regression, but rather something seasonal (https://bugs.debian.org/776188#10)
[11:26] <mitya57> (and I've just fixed sphinx which was a real regression)
[11:30] <Laney> mitya57: wtf at that
[11:30] <Laney> but can't it be fixed?
[11:31] <mitya57> I quickly looked at it, and didn't see an easy way to fix it.
[11:31] <mitya57> And I don't have much time today to dig into that code.
[11:33] <henrix> pitti: can i also have this please? run-autopkgtest -s wily -a armhf --trigger linux-meta/4.2.0.27.30 flashcache
[11:45] <pitti> henrix: done
[11:49] <henrix> pitti: thanks
[11:56] <pitti> mitya57: "the tests
[11:56] <pitti> fail on months containing J, that is Januarys, Junes and Julys"
[11:56] <pitti> !
[11:57] <pitti> mitya57: it's not nearly as good as the infamous "OpenOffice does not print on Tuesdays" bug, but still fun :)
[11:57] <mitya57> :)
[11:59] <pitti> mitya57: but the sphinx regression is really recent (it started failing on the new pygments), so that needs looking into
[11:59] <mitya57> pitti, I've uploaded new sphinx fixing the issue
[12:00] <pitti> mitya57: ah great! I hinted qbzr
[12:00] <mitya57> Thanks!
[12:04] <mdeslaur> pitti: yes, I'll look today (php5 migration failure)
[12:04] <pitti> mdeslaur: thanks
[12:13] <pitti> cjwatson: unping; the build log plus local build are sufficient
[13:20] <cjwatson> LocutusOfBorg: Feel free to steal my iulib merge, don't mind what you do with it after that
[13:21] <quadrisp1o> pitti, no need to say that I trust you, so next time on libmtp you want to fix something, just fix it :)
[13:21] <pitti> quadrisp1o: ok :)
[13:21] <quadrisp1o> feel free to add yourself to Uploaders
[13:22] <pitti> quadrisp1o: we don't need an upload just for this, but good to know that we don't have a permanent delta because of this now
[13:23] <cjwatson> pitti: I don't think you can get the tarball as such, but it's unpacked and published to your PPA in the usual place - http://ppa.launchpad.net/pitti/sru-test/ubuntu/dists/trusty/main/installer-amd64/20101020ubuntu318.34/images/
[13:23] <pitti> cjwatson: oh! I guess that was too obvious, thanks!
[13:30] <tjaalton> doko: hi, llvm 3.8-rc1 got released, do you know if sylvestre plans to work on it soon?
[13:31] <doko> tjaalton, no
[13:31] <tjaalton> doko: ok, I'll ask him
[13:31] <doko> ta
[13:31] <LocutusOfBorg> cjwatson, question: the delta is now dropped, unfortunately the version naming is strange 0.4+is+0.3-3ubuntu2
[13:31] <LocutusOfBorg> so I don't think I can sync
[13:32] <LocutusOfBorg> do you have any advice? just rename the last entry and upload?
[13:34] <pitti> apw: do you still remember what we meant in bug 1497291?
[13:34] <tjaalton> doko: turns out it's already uploaded to experimental, but in NEW
[13:34] <cjwatson> LocutusOfBorg: I would probably apply the same changes so that it's effectively in sync and call it 0.4+is+0.3-3ubuntu3; not much else we can do until the version in Debian increases to something past ours
[13:35] <LocutusOfBorg> thanks, I was wondering about epoch in debian and sync :)
[13:35] <LocutusOfBorg> anyhow, I just changed the last changelog entry and uploaded
[13:35] <LocutusOfBorg> thanks
[13:36] <apw> pitti, i am reading that as when running a test for foo which triggers linux-keystone that it triggers tests for all of foo's architectures not all of linux-keystones'
[13:36] <rbasak> LocutusOfBorg: an epoch would be permenant. At least this way the mess is temporary.
[13:36] <apw> pitti, but ... it is rather vague
[13:36] <LocutusOfBorg> rbasak, sure, I really don't like epoch too
[13:36]  * LocutusOfBorg never bumped an epoch
[13:38] <pitti> apw: hm, I thought that got fixed a long time ago already
[13:40] <apw> pitti, may well so
[13:40] <pitti> apw: the bug says that http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#linux-meta-keystone was wrong, but it currently looks right, doesn't it?
[13:40] <apw> pitti, yep looks right.  i'd be inclined to call it fixed as we'll never know anyhow now :)(
[13:40] <apw> :)
[13:40] <pitti> apw: ack
[13:46] <LocutusOfBorg> question, an ubuntu delta about renaming library for gcc5 transition ( pitti ), can be dropped after wily?
[13:46] <LocutusOfBorg> package: libclaw
[13:47] <pitti> LocutusOfBorg: no, after xenial only, as we need to support trusty → xenial upgrades
[13:47] <LocutusOfBorg> if not: can I steal your merge?
[13:47] <pitti> LocutusOfBorg: please do steal, thanks!
[13:47] <LocutusOfBorg> :D
[13:47] <LocutusOfBorg> thanks to you
[13:48]  * tsimonq2 wonders if he should repost wht he said yesterday, following up on some FTBFS issues...
[13:48] <pitti> apw: FYI, we have a slight technical hitch (aka "we kill all instances"): http://paste.ubuntu.com/14671742/
[13:49] <apw> pitti, that doesn't look good
[13:49] <apw> pitti, any idea what is triggering that ?
[13:49] <pitti> Laney: let's move here, to have everyone on the same channel
[13:49] <pitti> apw: I figure apt pinning + dist-upgrade again, let me check
[13:50] <apw> pitti, oh it might not be a real issue, one we are generating in the test environment
[13:50] <LocutusOfBorg> pitti, it can be syncd
[13:50] <LocutusOfBorg> I missed that debian renamed the library too
[13:50] <pitti> LocutusOfBorg: heh, they better did; nice
[13:51] <LocutusOfBorg> I was looking at the latest changelog entry, missing the previous one
[13:51] <LocutusOfBorg> and complaining about "why the hell the patch doesn't apply", when I discovered it was already there :p
[13:51] <pitti> LocutusOfBorg: someone (you?) already synced
[13:51] <LocutusOfBorg> me
[13:52] <tsimonq2> After using an schroot, is there anything I have to do to clean it?
[13:52] <LocutusOfBorg> as you have noted, I'm merging all the libpng-dev packages from debian
[13:52] <tsimonq2> For building a package
[13:54] <pitti> apw, Laney: yep, --apt-pocket=proposed=src:init-system-helpers does that; yay apt pinning being too clumsy :/
[13:54] <pitti> I'll disable it for a moment, let the i-s-h tests  run, and re-enable it
[13:55] <LocutusOfBorg> mterry, can I steal your xaos merge?
[13:55] <cjwatson> LocutusOfBorg: doesn't need an epoch; the version in experimental is already greater than what we have, so we should be fine when it gets to unstable
[13:55] <LocutusOfBorg> cjwatson, yes, sure
[13:55] <LocutusOfBorg> BTW the revert was back to oneiric
[13:55] <LocutusOfBorg> when a reverse-dependency that now disappeared was needing the old version
[13:56] <LocutusOfBorg> so I presume without it, we might also push experimental to unstable and force-sync
[13:56] <LocutusOfBorg> but I prefer to concentrate to fixing libpng
[13:56] <mterry> LocutusOfBorg, sure thanks
[13:57] <apw> pitti, phew (in a way)
[13:57] <pitti> dear apt: pinning priority of 800 does not mean "OMG stay away from it like the plague!"
[13:58] <pitti> Laney: so *now* it will test everything with kernel 4.4 too (without apt pinning, I mean) :)
[13:59] <Laney> pitti: heh
[14:00] <Laney> pitti: there's a forced lockstep upgrade of i-s-h and sysvinit-utils
[14:00] <LocutusOfBorg> xaos can be syncd
[14:00] <Laney> I guess this explodes apt
[14:00] <pitti> Laney: right
[14:01] <pitti> Laney: well, it's fine without pinning, but if you say "prefer the i-s-h binaries from -proposed" it doesn't grok that it should use proposed for the necessary dependencies too
[14:01] <pitti> Laney: it seems like it's either "ish binary deps are completely satisfiable in -release" or "I refuse"
[14:01] <apw> pitti, i thought that when things failed with pinning it fell back to enabling -proposed en-toto ?
[14:01] <pitti> apw: yes, but that's the early dist-upgrade
[14:02] <apw> oh heh only there, ok
[14:02] <pitti> way before installing the test deps
[14:02] <pitti> and it doesn't technically fail
[14:02] <pitti> it "just" removes openss..
[14:02] <pitti> h
[14:03] <apw> pitti, hehe that must be a little bit disruptive to results gathering :)
[14:03] <pitti> since apt pinning is so completely useless for every nontrivial case, I wonder if there's a different approach that we can take
[14:04] <apw> pitti, we know the versions of them don't we, can we not install foo=version
[14:04] <pitti> perhaps, first install everything from -release, *then* add -proposed apt source, and install everything again
[14:04] <pitti> then it should not upgrade stuff unless dependencies mandate it
[14:04] <apw> that sounds feasable
[14:04] <pitti> I don't want to rewrite apt's resolver, no
[14:05] <pitti> just make it less greedy with picking stuff from -proposed, or alternatively fix the apt pinning to actually fall back from 900 -proposed to 800 -release
[14:05]  * apw doesn't even want to look at apt's resolver :)
[14:05] <pitti> that sounds like a nice thing to look at tomorrow morning in the train
[14:06] <tsimonq2> in FTBFS, libsecret is failing due to gjs not being in main but Universe, and there is no Mir bug filed...should *I* file one, not being the maintainer?
[14:06] <apw> i think upgrade from !-proposed, install triggers, add -proposed, install triggers would do pretty well, and better than it does now
[14:07] <apw> pitti, and remember thats not -release but -updates in the older releases
[14:07] <pitti> yeah, but same thing in this context
[14:08] <Laney> I guess that would improve things, yeah
[14:08] <tsimonq2> same situation with appstream-glib depending on libgcab-dev...
[14:08] <pitti> apw: so in the second step we would iterate over all binaries of the triggers, check if they are instaslled, and if so, apt-get install them again
[14:08] <Laney> The other thing is to move testing to another phase after _output
[14:08] <pitti> (as we don't want to blindly install all binaries of the trigger -- that might not even be possible)
[14:08] <Laney> and do it per transaction
[14:09] <pitti> I wonder how that  would fail with library transitions
[14:09] <apw> pitti, yeah good point
[14:09] <pitti> and for binNEW, or even source NEW, etc. (the trigger might not even *be* in teh release yeat)
[14:09] <pitti> yet
[14:09] <pitti> so, it's not going to become any easier (the contrary), just perhaps more useful
[14:10] <Laney> (Then you test the set of things you're trying to migrate)
[14:10] <pitti> Laney: "move testing to another phase after _output" → can't parse, sorry
[14:10] <Laney> excuses -> output -> test -> migrate
[14:10] <Laney> i.e. test things after they become a candidatge
[14:11] <pitti> Laney: ah, to avoid running into uninstallability
[14:11] <Laney> because britney has then worked out the transactions already
[14:11] <Laney> and those are the units of migration
[14:11] <pitti> interesting idea
[14:11] <Laney> so you'd make a fake Packages file or something which represents those
[14:32] <pitti> Laney: or we could pin all binaries involved in that transaction
[14:33] <pitti> Laney: which should work again, as that ought to be a closed set
[14:33] <pitti> Laney: sounds elegant, but we would then start depending on being able to download update_output.txt from everywhere
[14:33] <pitti> and more importantly, depending on that it is actually current
[15:05] <LocutusOfBorg> sarnold, can I sync flogwatch? your security update seems icluded in the debian version (new release)
[15:22] <Laney> pitti: Hm? I imagine you'd feed the requests from britney still, just at a later phase
[15:22] <Laney> pitti: can't use update_output now as the packages we're testing aren't candidates yet so they don't appear there
[15:23] <pitti> Laney: oh right, you mean britney will forward the set of packages as test parameter, so that the worker can just add them to --apt-pocket=proposed=src:a,src:b, etc.
[15:24] <pitti> so, this is quite a heavy piece of reengineering, but sounds interesting indeed
[15:24] <Laney> pitti: I would ditch the pinning and just make a fake release as this is more robust
[15:25] <Laney> but it might work either way
[15:25] <Laney> definitely a lot of reworking
[15:26] <pitti> Laney: oh, you mean: apt-get update, create fake _Packages from the complete proposed_Packages and the sources we want, and replace -proposed apt source withthat
[15:26] <pitti> that doesn't work, as dependencies from the ones "we want" might also just be in -proposed
[15:26] <Laney> pitti: britney is saying that it wants to remove the -release package and all its binaries and put the -proposed one(s) and all its binaries in
[15:26] <pitti> so for that we need the britney "give me the complet set" features
[15:26] <Laney> yes
[15:26] <pitti> Laney: but once we have that, apt pinning works equally well :)
[15:26] <Laney> that's what update_output knows
[15:28] <Laney> pitti: I don't think that's the most important part of the proposal, so whichever way you like
[15:28] <Laney> The other way feels more like "this is the state we are trying to mutate -release into" to me
[15:29] <Laney> no possibility of an unclean environment
[15:29] <Laney> but, doesn't matter that much
[15:29]  * Laney goes to write weekly report
[15:33] <LocutusOfBorg> mitya57, can you please merge tracker from debian?
[15:52] <mitya57> LocutusOfBorg, sure
[15:58] <smoser> hey, do we have a plan for signed firefox addons ?
[15:59] <smoser> just upgraded and see that 'Uubntu Online Accounts', 'Unity Desktop Integration', 'Unity Websites integration' have all been disabled.
[15:59] <smoser> in addition to pentadactyl which i actually care about (https://github.com/5digits/dactyl/issues/99)
[16:04] <mitya57> LocutusOfBorg, done
[16:06] <LocutusOfBorg> mitya57, <3
[16:19] <smoser> barry, we are close https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1538198
[16:19] <smoser> no real digging yet as to what is getting the remaining bits pulled in.
[16:21] <barry> smoser: cool, thanks.  i'm subscribed now.
[16:27] <slangasek> pitti: hi, re: bug #1537211, your changelog makes it sound like you're dropping the attachment of /var/log/udev rather than replacing it with attaching the udevadm info output?
[16:28] <pitti> slangasek: attaching udevadm dump already has happened for a long time (UdevDb: field)
[16:34] <slangasek> pitti: hah ok
[16:34] <slangasek> pitti: thanks :)
[17:47] <smoser> lamont, around ?
[17:47] <smoser> you're postfix maintainer... postfix seems to be what is pulling in python in cloud image http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/cloud-image.depends
[17:47] <lamont> smoser: sigh
[17:47] <smoser> https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1538198
[17:47] <lamont> otp
[17:47] <smoser> its Recommends.
[17:48] <smoser> i'll poke a bit, but if you know why, and if we could do anything, that'd be good.
[18:13] <lamont> smoser: looks like https://bugs.launchpad.net/bugs/1538198 and some scripts that need to be taught about python3, and a change in Recommends
[18:13] <lamont> bah
[18:13] <lamont> smoser: rather, * Recommend: python for postfix-add-* scripts. <-- that change
[18:14] <lamont> so postfix-add-* scripts need to learn about pytho3n
[18:14] <smoser> lamont, yeah. see bug, i posted a hack/quick 10 minute try
[18:14] <lamont> I expect to have some time on the plane this weekend, which is doubtlessly not soon enough for your happiness.
[18:15] <smoser> well, thats fine with me. we're down to just that in the image to my knowledge.
[18:15] <lamont> oh, cool
[18:15]  * lamont adds it to his plane-fun
[18:15] <lamont> though, tbf, it's more airport-fun, I plan to sleep on at least the first leg
[18:15] <smoser> if you want, you can give my patch a try. i just verified running 'python3 <path>.py' worked for everything.
[18:16] <lamont> smoser: uh... you do the ubuntu1 version and I'll merge it upstream?
[18:16] <lamont> bounus if the hacked file runs under both :D
[18:17] <smoser> well, want to test it . i just verrified compiles
[18:17] <smoser> SHIP IT!
[18:23] <rbasak> I think "mk-sbuild sid" may be broken on Xenial. Not confirmed fresh yet. /dev/null inside the chroot ends up 644. Anyone else seen this?
[18:24] <rbasak> "mk-sbuild xenial" is fine.
[18:34] <mdeslaur> xnox: did you get nodejs to build on s390x?
[18:37] <smoser> lamont, anoterh patch there now. this one passes pylint's checker
[18:39] <lamont> heh
[18:39] <lamont> thanks
[18:40] <lamont> I wonder, does launchpad bugs have anything like debian's bts (cli) for offline bug processing and perusal?  thinking "wut? no..."
[18:42] <rbasak> Launchpad has an API, so you could write a CLI I guess, if nobody's done that.
[18:42] <rbasak> You can change bug statuses via email.
[18:43] <lamont> rbasak: the question was one of totally not wanting to write it, just wanting to be able to read the bug while wifi-disconneted. :/
[18:43] <lamont> so no worries, I guess
[18:44] <mdeslaur> lamont: what's this "offline" thing you talk about?
[18:44] <lamont> mdeslaur: sometimes, it's my life. :(
[18:45] <rbasak> mdeslaur: says the security guy :-P
[18:45] <lamont> rbasak: to the security guy :D
[18:47] <mdeslaur> you don't get security updates when you're offline! :P
[18:47] <rbasak> Tell me that when you show me a CVE that affects my offline single-user machine :)
[18:48]  * rbasak half expects one to exist
[18:48] <Odd_Bloke> CVE-2016-0123: rbasak left his front door unlocked
[18:52] <lamont> lol
[18:55] <mdeslaur> hehehe
[19:15] <tedg> hallyn: So if I add a dep on libpam-cgm, should that be a "libpam-cgm | libpam-cgfs" ?
[19:17] <hallyn> tedg: or rather libpam-cgfs | libpam-cgm
[19:18] <tedg> K
[19:26] <rbasak> It's debootstrap that's broken I think. It now creates /dev/null as 644 because it runs mknod directly and doesn't set permissions.
[19:26]  * rbasak files a bug.
[19:27] <sarnold> maybe try with umask 0 to see if that unblocks you?
[19:49] <rbasak> sarnold: I'm just reverting the upstream commit that caused the regression - http://anonscm.debian.org/cgit/d-i/debootstrap.git/commit/?id=5518b79792dd93a416464c0744b87eb1a32ff770
[19:49] <rbasak> I just patched the functions file in reverse, and I think I'm good for now.
[19:54] <sarnold> rbasak: hah, nice fix..
[20:14] <Pharaoh_Atem> rbasak: so I've got a question
[20:15] <rbasak> Pharaoh_Atem: o/
[20:15] <rbasak> Sure
[20:15] <Pharaoh_Atem> I've got working dep8 tests for php7.0 now
[20:15] <rbasak> \o/
[20:15] <Pharaoh_Atem> and I've even added an fpm one
[20:15] <Pharaoh_Atem> but my problem is how to handle adding the php-fpm httpd config to the php package
[20:15] <Pharaoh_Atem> because right now, the php package does not provide one
[20:15] <nacc> Pharaoh_Atem: heya!
[20:15] <Pharaoh_Atem> nacc: yo!
[20:16] <Pharaoh_Atem> I saw your post on LP
[20:16] <rbasak> If I understand you correctly, you can just drop it into the test
[20:16] <rbasak> You don't need the package to provide one specifically; the test can have a local copy of what it needs.
[20:16] <Pharaoh_Atem> well, the config doesn't exist _at all_ in the php package, so there's no a2enconf or whatever for making php-fpm receive httpd input
[20:17] <rbasak> You have some way of making it work, right?
[20:17] <rbasak> If you can script that way, then the test is just that script.
[20:17] <Pharaoh_Atem> I wrote a config file and dropped it onto my local xenial install
[20:17] <Pharaoh_Atem> but it might make sense to actually provide it as something people could use, too
[20:17] <rbasak> Sure
[20:17] <Pharaoh_Atem> that's what I need your advice on
[20:17] <Pharaoh_Atem> I don't know how to go about this
[20:18] <rbasak> Until it provides it, you can write the test as you like. Either "cat > /foo <<EOT\nconfig_here\nEOT" within the script, or ship the file in debian/tests/foo.conf and have the script copy it in.
[20:18] <Pharaoh_Atem> ah
[20:18] <Pharaoh_Atem> well, then, I guess I'll do that
[20:18] <Pharaoh_Atem> I'll prepare a git patch for you in a bit
[20:18] <rbasak> The test should declare "needs-root breaks-testbed" and the dep8 runner will do the right thing.
[20:18] <rbasak> (revert the VM or container before running the next test, etc)
[20:18] <Pharaoh_Atem> ah
[20:19] <rbasak> If it makes sense for the package to ship some configs, then that'd probably be best to send in a patch to Ondrej, and coordinate with him on what he thinks is suitable, etc.
[20:51] <ximion1> robert_ancell: you really want to MIR AppStream itself: https://packages.debian.org/source/sid/appstream
[20:52] <robert_ancell> ximion1, ta, will do that one too
[20:52] <ximion1> if Protobuf and Qt5Core are in main for Ubuntu, it should have no dependencies on stuff which isn't already there
[20:52] <ximion1> let me know if if you need any help :)
[21:07] <juliank> Meanwhile APT 1.2/1.2.1 and squashfs-tools are still in depwait due to lz4 MIR bug 1531923
[21:50] <xnox> mdeslaur, nope. it's strange it build on debian but not on ubuntu. Even if I, e.g. disable pie too. And i don't see anything obvious. I shall engage upstream on that.
[21:50] <xnox> mdeslaur, well porters in question.