[00:07] <tgm4883> Can SRUs include the removal of features?
[00:30] <RAOF> tgm4883: Under extreme circumstances, yes.
[00:32] <tgm4883> RAOF: hmm, ok. I'll take a look at fixing this
[00:51] <mwhudson> sigh, michael wait for the accepted mail before going to lunch
[01:27] <noalternative> I am trying to compile fifth browser into a deb.  I am inexperienced, and I am trying to follow the hithear instructions & I am getting errors.  I have successfully compiled hithear, but I am trying to apply lessons to fifth browser.  Here are the hithear instruction.  I am at debuild -us -uc  https://wiki.debian.org/Packaging/Intro
[01:28] <noalternative> now the errors http://pastebin.com/Ph5QPcWX
[01:28] <sarnold> noalternative: your first message was cut off mid-way through the URL
[01:29] <sarnold> noalternative: what does 'file' report on the fifth_0.4.orig.tar.gz file?
[01:30] <noalternative> https://wiki.debian.org/Packaging/Intro?action=show&redirect=IntroDebianPackaging
[01:31] <noalternative> I am not sure what you mean.
[01:32] <noalternative> maybe I named it wrong?  I downloaded this from source forge, not github
[01:32] <noalternative> tried to rename the file according to instructions.
[01:32] <noalternative> https://sourceforge.net/projects/fifth-browser/files/v0.4/
[01:33] <noalternative> admttedly the original was not a tar.gz
[01:33] <noalternative> so I simply renamed it
[01:33] <noalternative> is that what your getting at?
[01:36] <noalternative> I just wanted to complie the browser for my personal use not as a package maintainer
[01:36] <tgm4883> noalternative: you can't just rename it
[01:36] <noalternative> ok
[01:36] <tgm4883> what was it previously?
[01:37] <noalternative> fifth-0.4.txz
[01:37] <sarnold> try something like fifth-_0.4_orig.tar.xz
[01:38] <tgm4883> sarnold: with the dash in there?
[01:38] <sarnold> I wanted to see what 'file' thought the file is. it might be empty. (that happens). it might be an HTML error page from some stupid download site. or, it might be an xz'd file rather than gzipped file :)
[01:38] <sarnold> tgm4883: nah, probaly better withuo the dash
[01:38] <sarnold> wow
[01:38] <sarnold> how long until tab-complete can just type my thinking for me.. not soon enough
[01:43] <noalternative> http://pastebin.com/KA1nVLzY
[01:44] <noalternative> It liked the original name I think.
[01:44] <tgm4883> noalternative: you should name it fifth_0.4.orig.tar.xz
[01:44] <sarnold> I detest the "rename the tarball" step. so. annoying.
[01:44] <tgm4883> I agree
[01:45] <sarnold> because I can never guess the name to use correctly on the first try, I always wind up having to copy-and-paste the demanded name from this error message :)
[01:46] <sarnold> (you've seen my typing, this shouldn't be a surprise :)
[01:52] <noalternative> We made some headway, but it ultimaely retruned errors.  I can't cut and paste all of it from my terminal because my terminal stops before the command was given.
[01:53] <noalternative> Is there a log I can paste?
[01:53] <noalternative> or maybe a specific part of the terminal like the part about errors.
[02:01] <noalternative> Here are errors from a file called fifth_0.4-1_amd64.build
[02:02] <noalternative> http://pastebin.com/TeCS4BWC
[03:51] <infinity> tgm4883: You absolutely can just rename orig tarballs.
[03:51] <tgm4883> infinity: you can just rename an orig tarball from a .tar.xz to .tar.gz?
[03:52] <infinity> tgm4883: Oh.  No.  I missed the context, I guess. ;)
[03:53] <tgm4883> infinity: hah yea, I didn't think you could do that. I guess I should have said can't just change the extension
[03:53] <tgm4883> although you kinda can, if you know what you're doing
[03:53] <infinity> tgm4883: Not in a way that keeps dpkg happy and the file unchanged. :P
[03:53] <infinity> Pick one.
[03:54] <tgm4883> infinity: well in this case, we had to change .txz to .tar.xz
[03:54] <infinity> 'tar xf' autoguesses these days, but dpkg-source ain't having none of that modern nonsense.
[03:54] <tgm4883> although maybe we didn't need to do that and just rename it to the proper format
[03:54] <infinity> tgm4883: Oh, sure, tgz == tar.gz, etc, though.
[03:55] <tgm4883> yep
[10:08] <Laney> Mirv: trying a test build of ffmpeg ...
[10:08] <Laney> cross your toes
[10:16]  * sil2100 crosses his toes too
[10:30]  * Mirv crorres toes and fingers
[10:34] <cjwatson> Mirv: so ... would you be sad if I just fixed that click test rather than approving your hack, given that I know how to do it and it's fairly easy having spotted the problem?
[10:42] <cjwatson> Mirv: https://code.launchpad.net/~cjwatson/click/new-debsig-policy-url/+merge/302652
[10:48] <Mirv> cjwatson: terrible! (thank you)
[10:49] <Mirv> replacing the silo MP with that
[10:49] <Laney> 'k, that built
[10:49]  * Laney copies
[10:50] <cjwatson> Mirv: thanks; I tested it enough locally that I think it's good
[10:50] <Mirv> Laney: \o/
[11:00] <Laney> gizza builder, launchpad
[11:39] <seb128> hum, does anyone has an idea what's wrong on bug #1611256?
[11:39] <seb128> xenial to yakkety upgrades are hitting that
[11:40] <seb128> "dpkg: dependency problems prevent processing triggers for gconf2:
[11:40] <seb128>  gconf2 depends on python3:any; however:
[11:40] <seb128>   Package python3 is not configured yet."
[11:56] <doko> apw, when do you plan to upload the updated kernel to y?
[11:58] <xnox> doko, in two weeks when he is back from vac?
[11:58] <xnox> =)
[11:58] <ogra_> they allowed him vac ?!?
[11:58] <ogra_> carzy kernel team ...
[11:58] <ogra_> *crazy too
[13:19] <doko> LocutusOfBorg, what are you saying in 1608129? build it once without the tests, and then reenable the tests?
[13:19] <LocutusOfBorg> or build-conflict with itself
[13:20] <LocutusOfBorg> your solution seems good too
[13:20] <LocutusOfBorg> BTW I already asked ginggs but you might want to upload this patch http://paste.ubuntu.com/23021246/
[13:24] <loladiro> Hi folks, hope this is the right channel. I’ve been looking for the `dash` debug symbol package, but been unable to find it. Any pointers?
[13:25] <xnox> loladiro, https://wiki.ubuntu.com/Debug%20Symbol%20Packages did not help?
[13:25] <loladiro> Nope, tried that, but neither dash-dbg nor dash-dbgsym seemed to exist
[13:29] <xnox> loladiro, yeah weird.
[13:29] <xnox> pitti would be the person to ask, but I don't see him online atm (holidays?!)
[13:29] <cjwatson> dash has a very old-fashioned debian/rules that doesn't use debhelper, so that'll be why
[13:30] <xnox> ah
[13:30] <xnox> tru, dh_strip is not called.
[13:30] <loladiro> So, no debug symbols for me then :(?
[13:30] <cjwatson> it should be pretty easy and quick to build locally
[13:30] <cjwatson> not a complex package
[13:30] <loladiro> Yeah, absolutely
[13:31] <loladiro> I’m not really interested in dash actually, but was just using it as a test case for some automation - guess I picked the wrong thing ;)
[13:32] <loladiro> Should I file some sort of bug report so this doesn’t get forgotten for future versions, or is this known and will be fixed anyway
[13:34] <cjwatson> I think it would be reasonable to file a bug asking for debug symbols (though a solution-neutral bug - it may be easier to just bodge the one or two necessary lines into debian/rules than to convert the whole thing to debhelper, as a downstream)
[13:34] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/dash/+filebug
[13:36] <LocutusOfBorg> I would open a bug in Debian
[13:37] <cjwatson> that's only a good idea if you can come up with a reasonable way to make it applicable to Debian
[13:38] <loladiro> Alright, bug filed. Appreciate the quick response folks.
[13:39] <cjwatson> http://debug.mirrors.debian.org/debian-debug/pool/main/d/dash/ similarly doesn't exist, so that may be such an argument
[13:55] <LocutusOfBorg> yes, the strip is done in a really obscure way
[13:55] <LocutusOfBorg> https://sources.debian.net/src/dash/0.5.8-2.3/debian/rules/
[13:55] <LocutusOfBorg> converting into some new format will fix the issue for both OS
[14:36]  * xnox moved IRC from a US vps to the one in docklands, so much better =)
[14:36] <xnox> http://memesvault.com/wp-content/uploads/Dog-Meme-Wow-Wallpaper-03.jpg
[14:47] <rbasak> stgraber: https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1612116
[14:48] <xnox> rbasak, whilst juju-2 is still saying that it may not be used for production use?!
[14:48] <xnox> how does one connect and/or deploy things with juju in yakkety then?
[14:49] <stgraber> xnox: I just commented in the bug that I don't think we should do this until Juju 2.0 is released and stable
[14:49]  * xnox hits F5
[15:02] <rbasak> xnox: don't ask me!
[15:38] <setuid> If I've pulled a package 'bar' with a BD on foo, which then uses 'import foo' in its code, but there's no RD on 'foo', removing 'foo' will break 'bar'. Does a BD incorporate foo.py into bar? Or did I just find a bug?
[15:49] <LocutusOfBorg> b-d don't incorporate runtime dependencies for python packages
[15:49] <LocutusOfBorg> usually they are listed in setup.py install_requires
[15:50] <LocutusOfBorg> and the parses and replaced with debian dependencies into python:Depends substvar that is evaluated during build by dh_python2 and replaces the dependencies with some runtime stuff
[15:50] <LocutusOfBorg> but if install_requires is not available... the maintainer has to list them in runtime-Depends
[15:51] <LocutusOfBorg> for libraries is easier
[15:51] <setuid> LocutusOfBorg, So sanity check this for me; python-keystone has a BD on python-ldappool, and keystone/core/core.py does an 'import ldappool', but installing python-keystone doesn't install python-ldappool
[15:52] <setuid> So installing python-ldappool on its own will satisfy that r-d, but will break when removed (no deps depend on it)
[15:52] <setuid> sorry, keystone/common/ldap/core.py
[15:52] <setuid> imports ldappool
[15:53] <setuid> there's a changelog entry showing the b-d being added, but they missed the r-d
[15:58] <mterry> seb128: can you reject a lightdm upload I just made to vivid accidentally?  Got my dput arguments in the wrong order and for some reason haven't disabled 'ubuntu' as the default location
[16:00] <mterry> Or any archive-admin I guess really  :)
[16:05] <infinity> mterry: Done.
[16:09] <mterry> infinity: thanks -- I've now fixed my dput too
[17:03] <LocutusOfBorg> setuid, you seems to be right, setup.py has no install_requires keyword, so the dependencies are not picked up (and nor explictly listed on Depends: of the runtime package)
[21:12] <ahoneybun> cyphermox: you work on the slideshow right?
[21:12] <ahoneybun> for the installer
[21:25] <cyphermox> ahoneybun: yes
[21:26] <ahoneybun> are the sizes in the slideshow.conf strict?
[21:26] <ahoneybun> like it HAS to be that size?
[21:27] <ahoneybun> reason I'm asking is because QtWebkit is broken in Qt4 or something and we are making our slideshow in qml
[21:27] <ahoneybun> not html
[21:39] <bdmurray> jbicha: for bug 1063019 you could use the Errors bucket for the crash as a test case
[22:09] <ahoneybun> heyo our installer slideshow is broken with 1 week before freeze
[22:09] <juliank> Would be nice if the apt 1.2.14 SRU in the queue would be processed at some point :)
[22:25] <bdmurray> juliank: which release is that for?
[22:25] <juliank> bdmurray: xenial, the 1.2.X series is the stable APT series for xenial
[22:32] <juliank> bdmurray: In case you're wondering: The release is from Jun 22; it was supposed to be synced a month ago or so, but getting the new APT with the same bugfixes into yakkety was a bit complicated, so it was delayed some time.
[22:33] <juliank> There will be a 1.2.15 update at some point in the future merging bugfixes from the 1.3~pre1, 1.3~pre2, 1.3~pre3, 1.3~rc1 releases; but not in the immediate future.
[22:33] <juliank> 1.2.14 basically  brings us up to 1.3~exp2 in terms of important bug fixes
[22:34] <juliank> oops, ~exp3
[22:35] <juliank> 1.2.15 will then fix the issues with ZFS module stuff not allowing you to autoremove kernels, amongst other things
[22:37] <juliank> (That will be an awful release to do, so many changes to look at and see what should be backported/cherry-picked)
[22:39] <juliank> Also need to wait for pitti so we can set up autopkgtests for that stuff before we upload it...
[22:57] <juliank> Oh dear, I also have to update the 1.0.9.8 series for Debian stable ...
[22:57] <jbicha> bdmurray: thanks, I see that there's a lot of errors on trusty for that gnome-contacts bug, so do you want to accept the sru for trusty too now (just uploaded)?
[23:08] <Term1nal> Question: https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5696.html
[23:08] <Term1nal> What does DNE stand for in that listing?
[23:09] <sarnold> Term1nal: does not exist
[23:09] <sarnold> Term1nal: it means that package doesn't exist in that release
[23:09] <Term1nal> Ah.
[23:10] <Term1nal> So... DNE is saying, what... patch not needed for that specific issue?
[23:10] <sarnold> right; for example, the linx-lts-trusty package doesn't exist in trusty, 16.04, 16.10, etc..
[23:12] <Term1nal> So is this page effectively saying that there's no fix needed for 16.04?
[23:12] <sarnold> Term1nal: the 'linux' package on 16.04 is marked 'needed'
[23:13] <Term1nal> ah
[23:13] <sarnold> Term1nal: the linux ones are far more complicated than the other packages.. you've got to know which source package generated the kernels you're using in order to really read the page
[23:13] <Term1nal> Can't wait until the DDoS kiddies figure out how to exploit this and sell it as a service O.O
[23:14] <sarnold> hey great business idea!
[23:14] <sarnold> I mean
[23:14] <Term1nal> :P
[23:14] <sarnold> yeah that'll be trouble...
[23:15] <Term1nal> I guess what I'm trying to figure out.. is a currently up-to-date patched 16.04 machine vulnerable to this CVE still or?
[23:15] <Term1nal> Cause, sure, it's fixed in 4.7 kernel. But obviously we're not using 4.7 out of the box.
[23:15] <sarnold> it's certainly forced to to think about TCP slightly differently; 2^32 gaurantees are ...  not impressive. with so many machines on the internet moving so many packets of data each second, 1/2^32 happens all the time..
[23:16] <sarnold> Term1nal: you're affected. We expect the fix to land around august 27
[23:16] <Term1nal> Neato, that's a nice specific timing.
[23:17] <sarnold> the kernel team works on a three-week cadence; patches in one portion, testing in another portion, publish on a date; it normally works out pretty predictably
[23:17] <Term1nal> Let's just hope PoCs aren't released before then and used to start the next poodlecorp
[23:20] <Term1nal> Odd though, isn't it typical to have these sorts of CVEs announced once a patch is ready to go?
[23:21] <sarnold> we do, we release USNs, e.g. http://www.ubuntu.com/usn/usn-3055-1/
[23:22] <sarnold> this issue came out at an inconvenient time to fit into the release that was released last week, so it's in the current cycle, which should be released in ~two weeks..
[23:23] <sarnold> we also mail our USNs to a moderate-traffic mail list https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce
[23:26] <Term1nal> I get those USNs through RSS
[23:30] <juliank> Hmm, I messed up the apt 1.3~rc1 a bit - I did not consider the ubuntu-specific config file in the packaging. I'll fix this tomorrow.
[23:31] <juliank> And what's going on with all those dlsym(acl_set_file): /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so: undefined symbol: acl_set_file?
[23:32] <juliank> Well, the config stuff kind of happens when you switch to a new build system and rewrite the packaging rules.
[23:43] <TheMuso> c
[23:43] <TheMuso> whoops
[23:53] <Term1nal> Oh, please package latest Golang toolchain for 16.04, thanks! <3
[23:53] <Term1nal> Have fun you hard workin' folks