=== Elimin8r is now known as Elimin8er
=== _salem is now known as salem_
=== salem_ is now known as _salem
[09:41] <doko> xnox, so for  #793222 I think I should at least break libboost-date-time1.55.0 unconditionally, not sure for the other libs. could you have a look at https://codesearch.debian.net/results/catch.*%3A%3Afailure%20package%3Aboost1.55/page_0 ?
[10:47] <xpheres> hello
[10:48] <xpheres> if anyone has an ubuntu touch device I will be happy if you write in reviews that my app actually works: https://uappexplorer.com/app/analyticaltranslatordemo.xpheresdev
[11:45] <Laney> doko: trying a build with new dh-python
[11:46] <Laney> but pyside does some renaming action itself
[11:47] <doko> Laney, see my fixes for newt and comedilib
[11:48] <doko> or let dh-python do the work
[11:54] <Laney> looks like it just renames stuff so that dh-python will pick it up
[11:54] <Laney> will check on the test build later
[11:57] <doko> thanks
[13:42] <xnox> doko: what do you mean break boost1.55? boost 1.55 should remain on 98 abi, otherwise it will be nuts....
[13:43] <xnox> doko: boost1.58 is with C++11 abi and should be peachy, no?
[13:44] <doko> xnox, please read the bug report, that's about not being able to catch an exception
[13:45] <doko> so with libstdc++6 5.2.1-12, this may get broken in boost1.55
[13:48] <xnox> doko: i'd rather have broken parts of boost1.55 and deal with that. i only see like 20 packages using boost-date-time
[13:48] <doko> xnox, so I'll add the breaks?
[13:48] <xnox> yes.
[13:49] <doko> but just for the datetime package?
[13:51] <xnox> doko: yes.
[13:52] <xnox> doko: i don't see for other libraries to be affected.
[13:52] <xnox> from codesearch.
[13:52] <xnox> (there is like tests and examples)
[15:08] <sforshee> hallyn: overlay is the upstream fstype, overlayfs is the legacy fstype in wily. As far as mount options go, the same code is used for both fstypes - if you supply upperdir then you also need workdir. I don't know how it worked in the past though.
[16:08] <hallyn> sforshee: as i said above, 'overlay' is not supporting unpriv mounts now, 'overlayfs' still does.
[16:08] <hallyn> 'overlay' used to, so it's a functionality regression
[16:08] <hallyn> sorry, heading out right now
[17:10] <teward> rbasak: infinity: so, i discovered something on the Apache package, they actually install to /usr/share and then have a postinst script that copies files around
[17:10] <teward> (it's their solution to the /usr/share/... being written to by package managers problem...)
[17:10] <teward> it's an interesting solution...
[17:11] <teward> (for the default site)
[17:14] <teward> ... and it's a solution i could adapt for nginx... with some work and testing, of course
[18:58] <infinity> teward: Pretty sure I suggested that very same thing for nginx.
[18:59] <teward> infinity: i didn't see that, sorry, but i wanted to check the logic :)
[18:59]  * teward yawns
[18:59] <teward> the side effect of bad-sleeping during the week: things're missed
[18:59] <infinity> teward: With a caveat that it should only do so on new installs, and only if /var/www/html is empty (so you don't stomp over another webserver or user content)
[18:59] <teward> right
[18:59] <teward> infinity: there's checks for that too
[18:59] <teward> in the apache implementation
[18:59] <infinity> I would assume so, yes.
[18:59] <teward> but my current focus is a trusty bug that should've been sqashed and i was too lazy to squish
[18:59] <infinity> So, it probably should just do the same thing and be done with it.
[19:00] <teward> right, that's my thoughts
[19:00] <teward> can never have enough testing though
[22:27] <ari-tczew> cjwatson: I've got an odd problem with builders. The package subtitleeditor has been built fine on PPA, but in wily-proposed got FTBFS. Could you check that?
[22:27] <ari-tczew> PPA: https://launchpad.net/~ari-tczew/+archive/ubuntu/testing/+build/7725896
[22:27] <ari-tczew> wily: https://launchpad.net/ubuntu/+source/subtitleeditor/0.52.1-1
[22:37] <slangasek> ari-tczew: check the versions of the build-dependencies that were installed in the ppa, vs. the ones used in the archive?
[22:43] <ari-tczew> slangasek: there is no build-depends installed in ppa
[22:55] <slangasek> ari-tczew: that is categorically false
[22:55] <slangasek> ari-tczew: what I mean is that you have build logs, which show you which versions of the build dependencies were installed and used for each build
[23:02] <ari-tczew> slangasek: why versions should be different? PPA takes B-D from -proposed, doesn't it?
[23:05] <slangasek> ari-tczew: a) that's a configurable setting, so not necessarily; b) the ppa build and the archive build didn't happen simultaneously so the contents may have changed in between
[23:09] <ari-tczew> slangasek: the first what I pointed out is a count of build-depends. ppa gets only 13 packages, archive build gets 22, but I guess it doesn't matter
[23:11] <ari-tczew> slangasek: can be it a problem related to gcc 5 ?
[23:11] <slangasek> gcc5 has not landed in the archive
[23:15] <teward> slangasek: that's still in testing first, right, before it lands?  What was the timeline on gcc5 landing, out of curiosity?  (I probably need to make sure nginx builds there)
[23:16] <slangasek> teward: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-July/001143.html
[23:51] <infinity> ari-tczew: Your PPA isn't configured with -proposed enabled, so it's not surprising that the results differ from an archive build.
[23:56] <ari-tczew> infinity: I had no idea there is a way to configure it... thanks
[23:56] <ari-tczew> Primary dependency added: Primary Archive for Ubuntu - PROPOSED