[00:29] <nacc> rbasak: ok, frustrating time beating my head against the pristine-tar stuff. I think it's going to be a lot of pain to write what `gbp import-orig --pristine-tar` does with all the corner cases, without basically copying all of their code. I've spent (I think) far too much time on it already. I think I see what the problem is with `gbp-import-orig`'s pristine-tar support for multiple tarballs
[00:33] <tomreyn> is anyone around here aware of an openjdk 8 PPA for 14.04? i can't seem to find any that's just half way current. and some java applications now switch to that as a minimal requirement, citing 'java 7 is EOL'. https://issues.jenkins-ci.org/browse/JENKINS-27624
[00:41] <tomreyn> many web sites point to matthias kloses' PPA at https://launchpad.net/~openjdk-r/+archive/ubuntu/ppa?field.series_filter=trusty but his package is 8 months old
[05:17] <RoyK> tomreyn: 16.04 is current now, with java 8 and 9 - guess an upgrade to that should be the simple way
[05:18] <RoyK> 16.04.2, that is - ubuntu is usually quite stable at .1 LTS releases, .2 should be even better
[05:20] <cpaelzer> good morning
[06:17] <lordievader> Good morning
[11:53] <ahasenack> rbasak: hey, 'morning/afternoon
[11:53] <ahasenack> rbasak: remember that bind9 merge, where I split out a test hunk from a patch into its own patch?
[11:54] <ahasenack> rbasak: turns out debian, in one of the other patches, did decide to grab test changes too
[11:54] <ahasenack> rbasak: so that now conflicts :/
[11:54] <ahasenack> rbasak: I'm thinking to just drop the new patch about tests, so we are fully in sync with debian, and whenever debian updates the upstream version, the test changes will be there
[11:54] <ahasenack> we don't run the tests as far as I can see: not in debian/rules, nor as DEP8 tests (there are none)
[11:55] <cpaelzer> not at all?
[11:55] <cpaelzer> interesting
[11:55] <cpaelzer> where did they add the test then?
[11:56] <cpaelzer> so TL;DR Debian took test and fix - just in two parts and you now drop all of our delta which was test+fix in one
[11:56] <cpaelzer> sounds right
[11:56] <cpaelzer> yet I wonder about the not running test - can you point me to a hunk in your repo with the test in a patch or so?
[11:59] <cpaelzer> ahasenack: you didn't upload any bind9 to https://code.launchpad.net/~ahasenack/+git yet
[11:59] <cpaelzer> ahasenack: if you would I could try to think with you
[11:59] <cpaelzer> where the test might be used (or not)
[11:59] <ahasenack> ok, 1sec
[12:00] <fallentree> ahasenack: hey, remember when I asked yesterday if there's a bind9 vuln pending? kinda had a premonition :)
[12:01] <ahasenack> oh gosh
[12:01] <ahasenack> is it public, or embargoed still?
[12:02] <ahasenack> cpaelzer: pushing, almost done
[12:02] <ahasenack> checking which other tags I have to push as well
[12:02] <fallentree> ahasenack: CVE-2017-3142 and -3143? public.
[12:02] <cpaelzer> for now I'm likely happy with logical
[12:04] <cpaelzer> seems reserved but still hidden https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-3143
[12:04] <ahasenack> cpaelzer: I pushed to https://code.launchpad.net/~ahasenack/ubuntu/+source/bind9/+git/bind9/+ref/bind9-merge-1%9.10.3.dfsg.P4-12.3 but lp doesn't like that link
[12:04] <ahasenack> the % perhaps
[12:05] <cpaelzer> https://git.launchpad.net/~ahasenack/ubuntu/+source/bind9
[12:05] <cpaelzer> works
[12:05] <ahasenack> yeah
[12:05] <ahasenack> cpaelzer: so
[12:05] <cpaelzer> which patch contained the test so that one can see it?
[12:05] <ahasenack> quilt push -a
[12:05] <ahasenack> patch that fails straight from debian: cve-2017-3137-2
[12:05] <ahasenack> it changes a test file
[12:05] <ahasenack> the other patch is
[12:06] <ahasenack> 8864-regression.patch
[12:06] <ahasenack> debian's doesn't have test changes, ours did. So I moved our test changes to 8864-regression-test.patch
[12:06] <ahasenack> and now these two are conflicting because of the context. It's a simple conflict
[12:06] <ahasenack> the file is example.db
[12:07] <ahasenack> if we remove our 8864-regression-test.patch, then we are in sync with debian and all patches apply
[12:07] <fallentree> which begs the question, why aren't these fixes synced up? committed to debian first, so they're cleanly downstreamed to ubuntu?
[12:07] <ahasenack> different decisions by different security teams
[12:08] <ahasenack> we have some odd hunks in our CVE patches, like copyright year changes
[12:08] <ahasenack> certainly not security related
[12:08] <ahasenack> just to give an example
[12:08] <fallentree> yes, but why? in which case, isn't it easier (and therefore better) for Ubuntu to just use sources directly from ISC?
[12:08] <ahasenack> I'm not privy how the patches are distributed to the linux distros
[12:08] <ahasenack> and isc's bug tracker is private
[12:09] <ahasenack> I assume they hand out a commit hash, and each team picks it up from there
[12:09] <ahasenack> or maybe not even that
[12:09] <ahasenack> this 8864 patch in particular was a nightmare, it had TWO regressions
[12:09] <ahasenack> CVE-2017-3137 also had regressions. Ubuntu has one big patch file, debian has 3 for the same issue
[12:10] <ahasenack> we are talking about security patches 30kbytes big :/
[12:11] <ahasenack> 31337: fix foo
[12:12] <ahasenack> 31337-2: reimplement fix
[12:12] <ahasenack> ops, number is 3137
[12:12] <ahasenack> 3137-3: fix regresion in fix
[12:12] <fallentree> the company I work for uses sources directly from ISC. No patching or backporting, we just download and compile new source. As ISC is maintaining versions in a LTS style, recompiling upstream directly brings only bug/security fixes.
[12:12] <ahasenack> yeah, if we upgraded the version most of these patches would be gone, but we follow debian
[12:13] <fallentree> perhaps it'd be time to re-evaluate "following debian" as closely.
[12:13] <ahasenack> depends on the package
[12:13] <ahasenack> and the time of the year (i.e. close to a release or not)
[12:13] <fallentree> the regressions introduced by trying to backport patches upon patches are really a bad thing.
[12:14] <cpaelzer> ahasenack: I agree I only see it built but not used (the tests)
[12:14] <ahasenack> cpaelzer: and the README hints that it is a bit complicated to run them
[12:14] <ahasenack> you have to prepare a network, with a specific CIDR
[12:15] <cpaelzer> which might be the reason they are not part of build/dep8 tests
[12:15] <ahasenack> exactly
[12:16] <cpaelzer> didn't find a reference in the qa tests either - most of the time they add explicit tests per CVE
[12:17] <ahasenack> you mean our secteam's automated tests?
[12:17] <cpaelzer> yes
[12:17] <ahasenack> ok, I hadn't checked that
[13:29] <ahasenack> mdeslaur: hi, general question about the bind9 cve patches
[13:30] <ahasenack> mdeslaur: for some of them, you guys pulled in test cases together with the actual security fix
[13:30] <ahasenack> mdeslaur: but ubuntu doesn't run these tests, right?
[13:30] <ahasenack> or do you do a manual run somehow before the packages are released?
[14:00] <ahasenack> rbasak: I ended up moving our regression test patches (new relative to Debian) to the end of the d/p/series (and refreshed them a bit), so we can still apply all the debian patches
[14:16] <rbasak> ahasenack: sounds good. Thanks!
[14:19] <friendlyguy> hi there. i am using landscape to manage a few virtual machines. i am wondering if there is a possibility within landscape to autoremove old kernels from boot?
[14:20] <friendlyguy> just configure the vms with: Unattended-Upgrade::Remove-Unused-Dependencies "true" or is there some checkbox i could enable for the upgrade profile?
[14:23] <friendlyguy> read: something like a checkbox. so that it would automatically enable it on all upgrade targets?
[14:23] <friendlyguy> would be neat to configure this centrally from landscape rather than setting it on every vm
[14:28] <ahasenack> friendlyguy: nope, that feature has been requested though
[14:28] <ahasenack> let me see if I can find the bug
[14:29] <ahasenack> friendlyguy: there is a bug, but it's private: #1208393
[14:29] <ahasenack> but it's exactly about that: adding some sort of autoremove call
[14:35] <friendlyguy> yup, would be neat :)
[14:36] <friendlyguy> i thought maybe i didnt search for the right things, but i came up empty handed for this one
[14:39] <friendlyguy> thanks for your help!
[15:03] <zul> jamespage: do you need someone to review your vif changes?
[15:04] <jamespage> I'd like 2 x +2's before landing please
[15:04] <jamespage> zul: ^^ and I need to think through if upgraders are impacted
[15:04] <zul> ok ill try to find some time to review it
[15:20] <jamespage> zul: ta
[15:30] <mdeslaur> ahasenack: we do run the test cases before we release the security updates
[16:13] <dprophit> The #courier channel is dead. Anyone have any experience with maildrop filters?
[16:41] <ahasenack> mdeslaur: the upstream, in-source test cases? Or your own?
[17:16] <sbeattie> ahasenack: both. for bind9, we do manually run the the upstream, in-source test cases, thanks to mdeslaur's helpful documentation.
[17:16] <ahasenack> sbeattie: I'd like to run them, do you have something written down?
[18:03] <sarnold> ahasenack: https://git.launchpad.net/qa-regression-testing/tree/build_testing/bind9/bind9-testing.txt
[18:03] <ahasenack> thx
[18:11] <jbraz> Hello. I have installed 16.04.2 server and was wanting to install openstack.  I follow the directions from ubuntu site for conjure up to us snap install conjure up --classic but I get   a failure for conjure-up not found...
[18:11] <stokachu> jbraz: try hash -r
[18:11] <stokachu> then see if `which conjure-up` shows up in /snap/bin
[18:14] <j-braz> Ok sorry got disconnected
[18:14] <sarnold> j-braz: < stokachu> jbraz: try hash -r < stokachu> then see if `which conjure-up` shows up in /snap/bin
[18:17] <j-braz> root@jupiter:~# hash -r
[18:17] <j-braz> root@jupiter:~# which conjure-up
[18:18] <stokachu> j-braz: sounds like your $PATH is missing snap directories
[18:18] <stokachu> and you should be running conjure-up as non root
[18:18] <sarnold> does df show the snaps mounted?
[18:18] <j-braz> Hang on I it found one in /usr/bin
[18:19] <j-braz> .  /usr/bin/conjure-up
[18:19] <stokachu> hmm thats an olddd version
[18:19] <stokachu> just type /snap/bin/conjure-up -h
[18:19] <sarnold> you might want to apt-get purge conjure-up to remove the packaged version
[18:20] <stokachu> j-braz: ^ yes please do
[18:20] <j-braz> Ok..
[18:21] <j-braz> Ok now which conjure-up returns nothing
[18:21] <stokachu> j-braz: does /snap/bin/conjure-up exist?
[18:22] <j-braz> No snap folder is empty
[18:23] <j-braz> Snap version 2.25 series 16
[18:25] <stokachu> what does snap list show
[18:26] <j-braz> root@jupiter:/snap# snap list
[18:26] <j-braz> No snaps are installed yet. Try "snap install hello-world".
[18:30] <j-braz> I can't find any info online about it.
[18:30] <sarnold> j-braz :(
[18:30] <sarnold> j-braz: you could try in #snappy -- I don't know if they do user support in irc or prefer their forums
[18:31] <j-braz> I didn't know snappy was related.. thanks.
[18:31] <stokachu> so what does snap install conjure-up --classic give you
[18:34] <j-braz> error: cannot install "conjure-up": snap not found
[18:35] <stokachu> well...
[18:36] <stokachu> j-braz: https://gist.github.com/battlemidget/1a513e3a6ae59f368a3e73856094eb3d
[18:36] <stokachu> so im not really sure why you can't see them
[18:36] <stokachu> oh
[18:36] <stokachu> what architecture are you on?
[18:36] <stokachu> if it's not x86_64, ppc64, arm64 then you wont be able to install it
[18:37] <j-braz> 4x quad core and Opteron 8360SE
[18:38] <j-braz> Oh
[18:38] <sarnold> sigh I wish amd had something like ARK
[18:39] <j-braz> So I have no options?
[18:39] <sarnold> that's probably compatible
[18:39] <dpb1> ya, should be fine
[18:39] <dpb1> j-braz: snap find conjure-up shows... ?
[18:41] <j-braz> Nothing. If I do  snap find with no parameters it list 4 packages.. Docker, LXD, NEXTCLOUD, HUGO
[18:42] <stokachu> j-braz: whats `uname -a` show
[18:42] <dpb1> j-braz: can you pastebin: dpkg -l |grep snap
[18:42] <j-braz> Also I should mention it's a fresh install. Only added xubuntu desktop
[18:42] <stokachu> dpb1: mine first
[18:42] <dpb1> NO NO NO, me me me
[18:42] <stokachu> lol
[18:42] <dpb1> :)
[18:42] <j-braz> Lol
[18:43] <j-braz> root@jupiter:/snap# uname -a                          Linux jupiter 4.4.0-83-generic #106-Ubuntu SMP Mon Jun 26 17:54:25 UTC 2017 i686 athlon i686 GNU/Linux
[18:43] <stokachu> well that would be why
[18:43] <stokachu> you got yourself an x86 installation
[18:44] <dpb1> stokachu: 64-bit only?
[18:44] <j-braz> What? I swear I thought I downloaded 64.. I'm sorry guys.. thanks.
[18:44] <stokachu> j-braz: np :)
[18:45] <stokachu> dpb1: x86_64, arm64, ppc64
[18:45] <stokachu> so yes
[18:45]  * dpb1 nods
[18:45] <dpb1> til
[18:46] <sarnold> stokachu: ha :) nicely done
[18:46] <stokachu> :) ty
[20:07] <pmatulis> what is a decent household file sharing solution these days? i'd rather avoid Samba (based on bad memories from 2.x days)
[20:08] <pmatulis> ('buntu-only clients)
[20:10] <Poster> samba has come a long way, but if you wish to avoid it, something like NFS or webdav comes to mind
[20:12] <pmatulis> Poster, thanks
[20:38] <dasjoe> I'd stick with samba
[20:40] <Poster> Yeah if you look at where the Linux kernel was at version 2.x and where it is now at 4.x, a lot has changed
[21:16] <pmatulis> ok
[21:22] <pmatulis> i'm looking at FreeNAS, which can use Samba. not sure if i should just install Ubuntu + Samba. right now i have just Ubuntu clients. i need to also buy hardware
[21:25] <pmatulis> there's a lot of tech in FreeNAS. i could use it as a source of education for my two sons
[21:26] <dpb1> freenas is cool.  I just use ubuntu, since I don't really need the higher level interface
[21:27] <pmatulis> yeah, i appreciate 'simple' too
[21:28] <dpb1> same.  freenas is certainly a good option.  I'm not going to disparage it.
[21:29] <pmatulis> and FreeBSD, well, it's been a while. staying with Ubuntu everywhere would make things easy
[21:29] <dpb1> now that ubuntu has ZFS as well...
[21:29] <pmatulis> yeah
[22:31] <gheorghe_> ubuntu is doing some wonderful things that always amaze me
[22:32] <gheorghe_> but anyway i need to sleep gn