[07:16] <pitti> Good morning
[07:31] <Pharaoh_Atem> rbasak: ping
[07:47] <rbasak> Pharaoh_Atem: pong
[07:48] <Pharaoh_Atem> rbasak: so I'm trying to update the dep8 tests to be "unversioned"
[07:48] <pitti> utlemming: recent cloud images don't boot any more (i. e. ssh never comes online), apparently they dropped the ifnames=0 but still don't create a matching interfaces? known?
[07:48] <Pharaoh_Atem> but I'm not sure how to make it so that the files in tests/ are read and rewritten before being used to run tests
[07:49] <Pharaoh_Atem> rbasak: if you don't remember, this is for php7.0
[07:54] <rbasak> Pharaoh_Atem: I'm not sure I follow your question.
[07:54]  * rbasak looks up the email about this.
[07:55] <Pharaoh_Atem> I'm not sure I follow what ondrej is asking me to do, so I'm probably doing a terrible job asking
[07:55] <rbasak> I don't think what he's asking will work. Let me see if I can understand what he wants.
[07:58] <Pharaoh_Atem> rbasak: I spent the better part of the week trying to do what he asked
[07:58] <Pharaoh_Atem> things blow up
[07:58] <Pharaoh_Atem> a lot
[07:58] <Pharaoh_Atem> maybe I just suck at Debian packaging :/
[07:59]  * Pharaoh_Atem has @_@ status after all of this
[08:00] <Pharaoh_Atem> if this worked like how RPM'
[08:00] <Pharaoh_Atem> how RPM's %check section worked, then sure, I can see this working like he wants
[08:00]  * mgedmin discovers that when unattended-upgrades causes a reboot, all other cron.daily scripts are skipped that day
[08:00] <Pharaoh_Atem> mgedmin: isn't that fun?
[08:01] <Pharaoh_Atem> I've actually caused people to yell at me about that
[08:01] <Pharaoh_Atem> because apparently no one expects that
[08:01] <mgedmin> maybe I should report a bug
[08:02] <Pharaoh_Atem> rbasak: but RPM's %check section would also not satisfy the kind of tests this pulls off
[08:02] <Pharaoh_Atem> as what we're really doing is spinning up instances and configuring things and stuff
[08:02] <Pharaoh_Atem> this stuff is weird, and I'm not sure the tests will work like we want it to in an "unversioned" state
[08:03] <rbasak> mgedmin: please do!
[08:03] <rbasak> Pharaoh_Atem: I replied to Ondrej's email. I think it'd be better for the test to dynamically discover the package version using dpkg-parsechangelog, or for the package to provide some shell (not make) infrastructure to extract the right strings.
[08:05] <Pharaoh_Atem> rbasak: so... does dpkg-parsechangelog have an option to strip the release version from the field?
[08:05] <Pharaoh_Atem> it doesnt' seem like there is
[08:05] <Pharaoh_Atem> *doesn't
[08:06] <ginggs> morning pitti!  on update_excuses, suitesparse still lists julia 0.4.2-3, does something need to happen fo this to change to 0.4.3-1build1 ?
[08:06] <pitti> ginggs: yes, we need to bump the hint
[08:07] <dholbach> good morning
[08:07]  * mgedmin files https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1541730
[08:07] <pitti> ginggs: done
[08:07] <Pharaoh_Atem> rbasak: actually, I'm not exactly sure how to use dpkg-parsechangelog to do this
[08:08] <Pharaoh_Atem> from looking at the man page, it seems to indicate that it just spews the whole Package header
[08:08] <rbasak> Pharaoh_Atem: -S maybe?
[08:08] <Pharaoh_Atem> ah, yes, I see it
[08:08] <rbasak> Pharaoh_Atem: also probably some cut or awk or sed may be necessary
[08:08] <Pharaoh_Atem> yeah
[08:08] <Pharaoh_Atem> I can be reasonably certain that the first dash is the cutoff point
[08:09] <Pharaoh_Atem> unless there's more package name-version contorting that I don't know about that's allowed?
[08:09] <rbasak> Technically it's the final dash IIRC, but that won't matter unless upstream happen to use a dash.
[08:09] <ginggs> pitti: danke
[08:09] <rbasak> I wouldn't worry about it if it's awkward.
[08:09] <rbasak> There might be some tooling that I don't know about that might help here.
[08:10]  * Pharaoh_Atem misses having a separate Version and Release field
[08:10]  * Pharaoh_Atem pokes more dpkg manpages
[08:11] <Pharaoh_Atem> hmm, doesn't look like the dpkg-dev toolsuite has anything
[08:12] <mwhudson> Pharaoh_Atem: i find this sort of thing to be least horrible in perl, of all things
[08:12] <rbasak> Pharaoh_Atem: see /usr/share/dpkg/pkg-info.mk
[08:12] <rbasak> It has the right shell snippets
[08:13] <Pharaoh_Atem> you know things are bad when you resort to perl as the least horrible option :/
[08:14] <Pharaoh_Atem> rbasak: looks like DEB_VERSION_UPSTREAM is what I want, ne?
[08:17] <Pharaoh_Atem> rbasak: are these variables available inside the test environment, or should I just copypasta them into the tests?
[08:22] <rbasak> Pharaoh_Atem: I would copy and paste them. Ugly, but I'm not sure of any better way.
[08:22] <Pharaoh_Atem> yeah, that's what I think
[08:22] <rbasak> dpkg-parsechangelog and version strings are very well defined. So as long as the code is correct, it shouldn't ever change under our feet.
[08:22] <rbasak> Of course having the code in one place is good for bug fixes too.
[08:22] <rbasak> Though hopefully if it does wrong our tests will fail.
[08:24] <rbasak> rharper: while I remember, it might be worth checking with bdmurray that phased updates won't be impacted by the network-manager/libnl3 breaks SRU thing.
[08:25] <rharper> rbasak: yes, thanks!
[08:25] <rbasak> bdmurray: a newer libnl3 in trusty-proposed breaks network-manager in the release pocket due to a latent bug, for which we have a fix also for network-manager in trusty-proposed.
[08:25] <rbasak> We will have a newer libnl3 with breaks: network-manager (...) soon.
[08:25] <rbasak> Users need to not phase libnl3 before network-manager.
[08:26] <rbasak> Just want to check that the phasing will not be thrown by the breaks.
[08:31] <Pharaoh_Atem> rbasak: when the tests are running, do they have access to the changelog file that's above the tests/ folder?
[08:32] <rbasak> Pharaoh_Atem: yes. Tests are defined to have a $PWD of the top of the source tree.
[08:32] <rbasak> http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst is the spec
[08:34] <Pharaoh_Atem> so $PWD/debian/changelog is a valid path in tests?
[08:43] <pitti> https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html is the formatted variant for nicer reading
[08:44] <Pharaoh_Atem> hmm
[08:45] <Pharaoh_Atem> rbasak: oh crap, I just realized, this has to be rewritten into shell script
[08:45] <Pharaoh_Atem> I don't even know what some of this even DOES
[08:45] <Pharaoh_Atem> http://fpaste.org/318293/45457554/
[08:50] <Pharaoh_Atem> hmm
[08:50] <Pharaoh_Atem> maybe I can make this work
[08:54] <Pharaoh_Atem> rbasak: uhoh
[08:54] <Pharaoh_Atem> I can't update the control file reliably
[08:57] <Pharaoh_Atem> rbasak: I'm going to take a wild guess and say that control files are not shell scripts, nor can they be rewritten like this
[08:58] <rbasak> Pharaoh_Atem: ah, right. Yes - the control file will need to be version-agnostic. Is that possible?
[08:58] <Pharaoh_Atem> not with the way Debian is determined to package this
[08:59] <Pharaoh_Atem> each and every package name has the PHP version embedded in it
[08:59] <Pharaoh_Atem> consequently, my deps are versioned in the control file
[08:59] <Pharaoh_Atem> so... I'm screwed
[08:59] <Pharaoh_Atem> if it was just the php major version like before, it would be workable
[08:59] <Pharaoh_Atem> but it's the major plus the minor version now
[09:00] <Pharaoh_Atem> rbasak: I'm not sure it's even possible to do this
[09:01] <Pharaoh_Atem> unless the packages all have virtual Provides to major version only, I can't really do this
[09:01] <Pharaoh_Atem> but if they have that Provides, things get really screwy once there's more than one PHP stack installed
[09:01] <Pharaoh_Atem> that has the same major version
[09:02] <Pharaoh_Atem> actually, come to think of it, it would already be quite unpredictable with correctly handling it if neither were installed anyway
[09:20] <Pharaoh_Atem> rbasak: yeah, I don't know how to make these tests work the way ondrej wants them to
[09:31] <cpaelzer_> I'm looking for some advise on packaging debian/*README* files. I have a source package building various binary packages.
[09:32] <cpaelzer_> and the Readme covers a lot of cross package things, so it is not really applicable to split it into debian/packagename.README.debian
[09:32] <cpaelzer_> but on the other hand I want the information available for the user, no matter what package he installs
[09:33] <cpaelzer_> it is a bit controversial, ideas that we could come up so far are all unsatifying - e.g. like linking all debian/packagename.README.debians to just one file
[09:33] <cpaelzer_> that would provide the info whatever the user installs, but it doesn't feel right
[09:35] <pitti> utlemming: I filed bug 1541757 with details, not sure if that's the right project
[09:35] <pitti> (it's private)
[09:35] <cpaelzer_> on the other hand making the one package that brings this information a dependency just for the README file is even worse
[09:35] <cpaelzer_> however and hint is welcome if there is something else that would apply
[09:40] <Pharaoh_Atem> rbasak: I'm clearly too tired to be useful now
[09:41] <Pharaoh_Atem> I just mail-bombed you with my stupidity today :/
[09:43] <cpaelzer_> I might just bind it to the -doc package and be done with, probably cleaner than everything else we came up so far
[09:58] <Pharaoh_Atem> rbasak: I think I've about bought the farm today, so I'm going to go to sleep for a few hours
[09:59] <rbasak> Pharaoh_Atem: OK, no problem. Thank you for this work! I think we'll need to see what Ondrej thinks about your latest patch.
[09:59] <Pharaoh_Atem> I've not submitted a patch for the tests, because I don't really know how I'm going to make this work
[09:59] <rbasak> Oh, OK.
[10:00] <Pharaoh_Atem> but the two patches I sent in (after fixing the author field) basically fix php-cgi.conf and add php-fpm.conf
[10:00] <rbasak> I'm a bit tied up this week but we can look together on it soon.
[10:00] <Pharaoh_Atem> I hope so
[10:00] <Pharaoh_Atem> we're inching really close to that Feb 18 drop dead date
[10:01] <Pharaoh_Atem> rbasak: I'm thinking that we're most likely going to have to give up on the idea of a versionless set of tests
[10:01] <Pharaoh_Atem> it's getting messy to figure out how it would work correctly
[10:02] <Pharaoh_Atem> the php-fpm config file patch would be needed anyway
[10:02] <Pharaoh_Atem> since I'm adding a php-fpm test
[10:04] <Pharaoh_Atem> anyway, ttyl
[10:41] <LocutusOfBorg> hi Logan can you please merge cinnamon? :)
[10:41] <LocutusOfBorg> or alternatively, can I steal your merge?
[10:42] <LocutusOfBorg> pitti, ^^^ you are the last uploader (even if a no change rebuild shouldn't count as real upload to me :p )
[10:42] <pitti> LocutusOfBorg: please steal, thank you!
[10:42] <pitti> the whole Borg collective doing merges, awesome!
[10:42] <LocutusOfBorg> :D
[10:42] <LocutusOfBorg> are you aware of the package src:borgbackup?
[10:42] <pitti> "You will be merged. Delta is futile."
[10:43] <LocutusOfBorg> I'm maintaining it just for fun :D
[10:43] <LocutusOfBorg> loool
[10:43] <pitti> LocutusOfBorg: I suppose it uploads your entire HD into the hive^Wcloud ?
[10:44] <LocutusOfBorg> yes, but only in the alpha quadrant
[10:44] <LocutusOfBorg> :)
[10:44] <pitti> LocutusOfBorg: what? they are in the Delta quadrant
[10:44] <pitti> what if a fire breaks out in Alpha and kills all backups?
[10:46] <LocutusOfBorg> true, but they were in alpha too :)
[13:05] <cjwatson> pitti: so, I gather that I can retry autopkgtests in silos, but I'm not sure of the exact invocation.  Could you clue me in?
[13:05] <pitti> cjwatson: it's essentially the same, but with adding the two --ppa args; e. g.
[13:06] <pitti> run-autopkgtest -s xenial -a armhf --ppa ci-train-ppa-service/stable-phone-overlay --ppa ci-train-ppa-service/landing-042 --trigger pay-service/15.10+16.04.20160114-0ubuntu1 unity-scope-click
[13:06] <cjwatson> ah, good, that was my guess
[13:06] <cjwatson> but wanted to check
[13:06] <pitti> cjwatson: clicky-clicky implementation is being worked on
[13:06] <cjwatson> pitti: thanks
[13:06] <pitti> this mostly needs verifying the PPA args, packages in those, etc.
[13:25] <mterry> doko, oh huh, clang doesn't use the new ABI?  I guess that makes sense but hadn't thought about it.  Do they have plans for that?
[13:48] <doko> mterry, yes, but afaik it's not yet implemented
[13:50] <doko> mterry, we promoted llvm when clang was built from a separate source. so nobody looked yet at promoting clang
[13:53] <mterry> doko, makes sense
[14:01] <cyphermox> good morning
[14:01]  * mterry waves at cyphermox
[14:02] <seb128> hey mterry cyphermox
[14:03] <alexabreu> pitti, ping
[14:06] <pitti> alexabreu: hello
[14:06] <alexabreu> pitti, hi, do you think you could retry britney for silo 16? https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-016/excuses.html
[14:07] <pitti> alexabreu: kicked
[14:07] <alexabreu> pitti, thx !
[14:07] <pitti> cd
[14:53] <tjaalton> update_excuses still thinks ikiwiki-hosting and libalien-wxwidgets-perl tests are blocking llvm-3.8
[14:53] <tjaalton> doko: libclc builds with llvm-3.8 btw
[15:16] <ginggs> pitti, what else is needed for suitesparse to migrate - ignore the julia i386 regression?
[15:17] <pitti> ginggs: ah, I bumped julia, but this ran against the previous version; I'll re-add the hint
[15:17] <pitti> ginggs: but this had been a valid candidate for a long time, and it caused uninstallability
[15:17] <pitti> i. e. some transition still needed
[15:18] <pitti> ginggs: next cycle will have suitesparse as valid candidate again, and you can see it in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt again -- this tells you which other packages become uninstallable with that
[15:19] <ginggs> pitti: ok, will look
[15:20] <doko> ginggs, pitti: I assume this is all stuck in the openmpi/netcdf transitions
[15:21] <doko> tjaalton, sure 3.8 is better than 3.7, but the point is that we should use exactly one system compiler
[15:22] <ginggs> surprise openmpi transition... btw doko, is this needed? debian bug #813494
[15:23] <tjaalton> doko: understood, I'll try with g++
[15:27] <doko> ginggs, makes sense
[15:28] <tjaalton> doko: nope, needs llvm-config, and readme has "libclc is intended to be used with the Clang compiler's OpenCL frontend"
[15:32] <tjaalton> doko: oh I read your comment now.. didn't we settle on 3.8 to be the new default?
[15:33] <tjaalton> now that it's available mesa can move to it
[15:34] <doko> tjaalton, read backlog, it's still in -proposed
[15:35] <tjaalton> doko: I know, but once it's out :)
[15:36] <tjaalton> uh, and the comment was from mterry not you, damn :)
[15:52] <tjaalton> doko: ok now I see the clang problem, I thought 3.8 would support the libstdc++ abi.. so mesa can use 3.8 once it's out of proposed, but doesn't have to enable opencl yet
[15:59] <doko> sil2100, you merged ocaml, but didn't follow-up with the ocaml transition
[15:59] <sil2100> doko: when?
[15:59] <sil2100> doko: last time I touched ocaml was during xenial beginnings when I was doing the ocaml transition
[16:00] <sil2100> I didn't merge it recently, at least I don't recall doing that
[16:00] <doko> sil2100, I know ...
[16:09] <pitti> slangasek: /usr/lib/tmpfiles.d/{legacy,x11}.conf have some examples, like 'r! /fastboot'
[16:12] <pitti> slangasek: the '!' means to only run that at boot, not when you restart/upgrade things (see tmpfiles.d(5))
[16:14] <doko> who speaks ocaml? https://launchpad.net/ubuntu/+source/coq-float/1:8.4-5build2/+build/8964835
[16:23] <ackk> hi, I'm trying to configure APT methods (the http one specifically) to skip proxy config for a certain domain, I'm trying with "Acquire::https:Proxy::<domain>=DIRECT", but it doesn't seem to work. am I doing something wrong?
[16:23] <cjwatson> ackk: missing colon
[16:23] <cjwatson> ::Proxy not :Proxy
[16:24] <ackk> cjwatson, argh, I read that line a thousand times and didn't notice :/
[16:24] <ackk> cjwatson, thanks :)
[16:24] <cjwatson> also you said http in one place there and https in another
[16:25] <ackk> cjwatson, yeah I actually have that config for both
[16:34] <xnox> pitti, could you retrigger node-websocket-driver with nodejs 4.2.6~dfsg-1ubuntu4 as trigger on ppc64el?
[16:34] <xnox> it's a tmpfail.
[16:35] <xnox> somehow ppc64el failed / got stuck a bit on nodejs tests....
[16:38] <pitti> xnox: done
[16:51] <caribou> slangasek: regarding mstflint (which is in Universe btw) - would the mstflint-4 (from Xenial) be considered a new package ?
[16:52] <slangasek> caribou: yes
[16:53] <caribou> slangasek: so how does that happen in a stable release ?
[16:53] <caribou> or can it ?
[16:54] <slangasek> caribou: same as elsewhere, it just requires you to actively prod the SRU team about letting it in
[17:19] <bdmurray> seb128: I'm fairly certain those retrace failures you mentioned the other day are due to needing a new version of gdb on the retracers.
[17:19] <xnox> caribou, same way lts-yname-backport stacks happen. It land in new queue for -proposed, but then migrates to -updates. We totally have brand new source and binary packages in -updates =)
[17:24] <seb128> bdmurray, ah, nice finding ... can you get it updated?
[17:26] <bdmurray> seb128: its building in a PPA now, then need to submit RT etc...
[17:26] <seb128> thanks
[17:26] <seb128> is there anything we can do to see when that happens next time?
[17:26] <seb128> like do we have stat of numbers of retraces that fail to give useful stacktraces?
[17:27] <bdmurray> seb128: the fix for bug 1517257 should avoid the issue
[17:27] <seb128> great
[17:49] <doko> tjaalton, is the libclc MIR really needed until clang gets the compatibility with the new libstdc++ ABI?
[17:53] <xnox> pitti, hm. the nodejs re-trigger didn't work, has it? is there a way to retrigger harder? I guess the proposed migration output should have retry buttons for test in progress things too? or like for tmpfail stuff.
[17:53] <xnox> pitti, or just hint it? i'm sure that single node package on a single arch is fine. I can't wait to have nodejs available on s390x =)
[18:15] <tjaalton> doko: it was needed for opencl support in mesa
[18:16] <tjaalton> the clang compat requirement was new to me
[18:25] <doko> tjaalton, does mesa work with opencl?
[18:58] <tjaalton> doko: debian has it
[18:59] <tjaalton> since ~2y ago
[19:05] <tjaalton> (mesa-opencl-icd)
[19:11] <pitti> xnox: oh -- I triggered node-leveldown, not node-websocket-driver, sorry
[19:11] <pitti> poked
[19:16] <highvoltage> 0/win 15
[19:55] <cjwatson> Laney,juliank: all right, I spent all day on https://code.launchpad.net/~cjwatson/launchpad/uncompressed-indexes/+merge/285109 - once that's reviewed/merged/deployed, both DEP-11 and Contents should work properly
[19:56] <cjwatson> also makes xz indexes a bit easier to arrange for in the near future
[21:15] <juliank> cjwatson: Wonderful
[21:31] <pitti> Mirv, alex-abreu, cjwatson: FYI, https://requests.ci-train.staging.ubuntu.com/static/britney/xenial/landing-021/excuses.html → silo excuses now have retry links
[21:31] <pitti> (production will update in a bit)
[21:31] <alex-abreu> pitti, awesome ! no more bothering you :)
[21:32] <pitti> clicked on the i386 regression, queued on http://autopkgtest.ubuntu.com/running.shtml#pkg-qtcreator-plugin-ubuntu
[21:33] <alex-abreu> pitti, they only appear on *new* britney results
[21:34] <pitti> alex-abreu: the pages will all be regenerated, give it another 30 minns
[21:34] <alex-abreu> pitti, great thx
[22:00] <mwhudson> infinity: ping
[22:08] <infinity> mwhudson: gnop
[22:12] <mwhudson> infinity: have you had the chance to form an opinion on https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1536882 yet?
[22:14] <infinity> mwhudson: I've been decidedly opinion-free this week, trying (somewhat unsuccessfully) to avoid too much multitasking.
[22:15] <mwhudson> infinity: fair enough, can i schedule an opinion-forming slot?
[22:15] <mwhudson> infinity: it's not urgent, exactly, but at the same time i don't want it to sit there forever
[22:16] <mwhudson> and i asked slangasek who to bug and he said you :-)
[22:16] <infinity> Heh.
[22:16] <infinity> mwhudson: Maybe put something on my calendar for next week?
[22:17] <infinity> mwhudson: And we can actually have a chat about it.
[22:18] <mwhudson> infinity: done, feel free to move it around
[22:18] <mwhudson> although not too much earlier in the day pls
[22:18] <slangasek> y
[22:18] <cjwatson> pitti: excellent
[22:18] <infinity> mwhudson: My brain doesn't wake up until mid-afternoon, "earlier" isn't in my scheduling vocabulary.
[22:19] <mwhudson> infinity: execellent
[23:34] <pitti> cjwatson: oh, thanks for beating me to updating lupin (I have a half-written update here, but wanted to wait until systemd landed)
[23:35] <pitti> cjwatson: this isn't systemd specific FYI, it was done 4 years ago in Debian already (between sysvinit and util-linux)
[23:35] <pitti> cjwatson: but I thought we also need to consider the case if /etc/adjtime does not exist at all only has one or two lnies
[23:35] <pitti> lines
[23:36] <pitti> (that's the "half-written" part, too tired to figure this out today properly)
[23:37]  * pitti waves good night .. morning already, actually