[00:29] 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] 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] 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] tomreyn: 16.04 is current now, with java 8 and 9 - guess an upgrade to that should be the simple way [05:18] 16.04.2, that is - ubuntu is usually quite stable at .1 LTS releases, .2 should be even better [05:20] good morning [06:17] Good morning [11:53] rbasak: hey, 'morning/afternoon [11:53] rbasak: remember that bind9 merge, where I split out a test hunk from a patch into its own patch? [11:54] rbasak: turns out debian, in one of the other patches, did decide to grab test changes too [11:54] rbasak: so that now conflicts :/ [11:54] 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] 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] not at all? [11:55] interesting [11:55] where did they add the test then? [11:56] 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] sounds right [11:56] 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] ahasenack: you didn't upload any bind9 to https://code.launchpad.net/~ahasenack/+git yet [11:59] ahasenack: if you would I could try to think with you [11:59] where the test might be used (or not) [11:59] ok, 1sec [12:00] ahasenack: hey, remember when I asked yesterday if there's a bind9 vuln pending? kinda had a premonition :) [12:01] oh gosh [12:01] is it public, or embargoed still? [12:02] cpaelzer: pushing, almost done [12:02] checking which other tags I have to push as well [12:02] ahasenack: CVE-2017-3142 and -3143? public. [12:02] for now I'm likely happy with logical [12:04] seems reserved but still hidden https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-3143 [12:04] 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] the % perhaps [12:05] https://git.launchpad.net/~ahasenack/ubuntu/+source/bind9 [12:05] works [12:05] yeah [12:05] cpaelzer: so [12:05] which patch contained the test so that one can see it? [12:05] quilt push -a [12:05] patch that fails straight from debian: cve-2017-3137-2 [12:05] it changes a test file [12:05] the other patch is [12:06] 8864-regression.patch [12:06] debian's doesn't have test changes, ours did. So I moved our test changes to 8864-regression-test.patch [12:06] and now these two are conflicting because of the context. It's a simple conflict [12:06] the file is example.db [12:07] if we remove our 8864-regression-test.patch, then we are in sync with debian and all patches apply [12:07] which begs the question, why aren't these fixes synced up? committed to debian first, so they're cleanly downstreamed to ubuntu? [12:07] different decisions by different security teams [12:08] we have some odd hunks in our CVE patches, like copyright year changes [12:08] certainly not security related [12:08] just to give an example [12:08] yes, but why? in which case, isn't it easier (and therefore better) for Ubuntu to just use sources directly from ISC? [12:08] I'm not privy how the patches are distributed to the linux distros [12:08] and isc's bug tracker is private [12:09] I assume they hand out a commit hash, and each team picks it up from there [12:09] or maybe not even that [12:09] this 8864 patch in particular was a nightmare, it had TWO regressions [12:09] CVE-2017-3137 also had regressions. Ubuntu has one big patch file, debian has 3 for the same issue [12:10] we are talking about security patches 30kbytes big :/ [12:11] 31337: fix foo [12:12] 31337-2: reimplement fix [12:12] ops, number is 3137 [12:12] 3137-3: fix regresion in fix [12:12] 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] yeah, if we upgraded the version most of these patches would be gone, but we follow debian [12:13] perhaps it'd be time to re-evaluate "following debian" as closely. [12:13] depends on the package [12:13] and the time of the year (i.e. close to a release or not) [12:13] the regressions introduced by trying to backport patches upon patches are really a bad thing. [12:14] ahasenack: I agree I only see it built but not used (the tests) [12:14] cpaelzer: and the README hints that it is a bit complicated to run them [12:14] you have to prepare a network, with a specific CIDR [12:15] which might be the reason they are not part of build/dep8 tests [12:15] exactly [12:16] didn't find a reference in the qa tests either - most of the time they add explicit tests per CVE [12:17] you mean our secteam's automated tests? [12:17] yes [12:17] ok, I hadn't checked that [13:29] mdeslaur: hi, general question about the bind9 cve patches [13:30] mdeslaur: for some of them, you guys pulled in test cases together with the actual security fix [13:30] mdeslaur: but ubuntu doesn't run these tests, right? [13:30] or do you do a manual run somehow before the packages are released? [14:00] 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] ahasenack: sounds good. Thanks! [14:19] 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] 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] read: something like a checkbox. so that it would automatically enable it on all upgrade targets? [14:23] would be neat to configure this centrally from landscape rather than setting it on every vm [14:28] friendlyguy: nope, that feature has been requested though [14:28] let me see if I can find the bug [14:29] friendlyguy: there is a bug, but it's private: #1208393 [14:29] but it's exactly about that: adding some sort of autoremove call [14:35] yup, would be neat :) [14:36] i thought maybe i didnt search for the right things, but i came up empty handed for this one [14:39] thanks for your help! [15:03] jamespage: do you need someone to review your vif changes? [15:04] I'd like 2 x +2's before landing please [15:04] zul: ^^ and I need to think through if upgraders are impacted [15:04] ok ill try to find some time to review it [15:20] zul: ta [15:30] ahasenack: we do run the test cases before we release the security updates [16:13] The #courier channel is dead. Anyone have any experience with maildrop filters? === efm__ is now known as efm [16:41] mdeslaur: the upstream, in-source test cases? Or your own? [17:16] ahasenack: both. for bind9, we do manually run the the upstream, in-source test cases, thanks to mdeslaur's helpful documentation. [17:16] sbeattie: I'd like to run them, do you have something written down? [18:03] ahasenack: https://git.launchpad.net/qa-regression-testing/tree/build_testing/bind9/bind9-testing.txt [18:03] thx [18:11] 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] jbraz: try hash -r [18:11] then see if `which conjure-up` shows up in /snap/bin [18:14] Ok sorry got disconnected [18:14] j-braz: < stokachu> jbraz: try hash -r < stokachu> then see if `which conjure-up` shows up in /snap/bin [18:17] root@jupiter:~# hash -r [18:17] root@jupiter:~# which conjure-up [18:18] j-braz: sounds like your $PATH is missing snap directories [18:18] and you should be running conjure-up as non root [18:18] does df show the snaps mounted? [18:18] Hang on I it found one in /usr/bin [18:19] . /usr/bin/conjure-up [18:19] hmm thats an olddd version [18:19] just type /snap/bin/conjure-up -h [18:19] you might want to apt-get purge conjure-up to remove the packaged version [18:20] j-braz: ^ yes please do [18:20] Ok.. [18:21] Ok now which conjure-up returns nothing [18:21] j-braz: does /snap/bin/conjure-up exist? [18:22] No snap folder is empty [18:23] Snap version 2.25 series 16 [18:25] what does snap list show [18:26] root@jupiter:/snap# snap list [18:26] No snaps are installed yet. Try "snap install hello-world". [18:30] I can't find any info online about it. [18:30] j-braz :( [18:30] j-braz: you could try in #snappy -- I don't know if they do user support in irc or prefer their forums [18:31] I didn't know snappy was related.. thanks. [18:31] so what does snap install conjure-up --classic give you [18:34] error: cannot install "conjure-up": snap not found [18:35] well... [18:36] j-braz: https://gist.github.com/battlemidget/1a513e3a6ae59f368a3e73856094eb3d [18:36] so im not really sure why you can't see them [18:36] oh [18:36] what architecture are you on? [18:36] if it's not x86_64, ppc64, arm64 then you wont be able to install it [18:37] 4x quad core and Opteron 8360SE [18:38] Oh [18:38] sigh I wish amd had something like ARK [18:39] So I have no options? [18:39] that's probably compatible [18:39] ya, should be fine [18:39] j-braz: snap find conjure-up shows... ? [18:41] Nothing. If I do snap find with no parameters it list 4 packages.. Docker, LXD, NEXTCLOUD, HUGO [18:42] j-braz: whats `uname -a` show [18:42] j-braz: can you pastebin: dpkg -l |grep snap [18:42] Also I should mention it's a fresh install. Only added xubuntu desktop [18:42] dpb1: mine first [18:42] NO NO NO, me me me [18:42] lol [18:42] :) [18:42] Lol [18:43] 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] well that would be why [18:43] you got yourself an x86 installation [18:44] stokachu: 64-bit only? [18:44] What? I swear I thought I downloaded 64.. I'm sorry guys.. thanks. [18:44] j-braz: np :) [18:45] dpb1: x86_64, arm64, ppc64 [18:45] so yes [18:45] * dpb1 nods [18:45] til [18:46] stokachu: ha :) nicely done [18:46] :) ty [20:07] 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] ('buntu-only clients) [20:10] samba has come a long way, but if you wish to avoid it, something like NFS or webdav comes to mind [20:12] Poster, thanks [20:38] I'd stick with samba [20:40] 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] ok [21:22] 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] there's a lot of tech in FreeNAS. i could use it as a source of education for my two sons [21:26] freenas is cool. I just use ubuntu, since I don't really need the higher level interface [21:27] yeah, i appreciate 'simple' too [21:28] same. freenas is certainly a good option. I'm not going to disparage it. [21:29] and FreeBSD, well, it's been a while. staying with Ubuntu everywhere would make things easy [21:29] now that ubuntu has ZFS as well... [21:29] yeah [22:31] ubuntu is doing some wonderful things that always amaze me [22:32] but anyway i need to sleep gn === JanC_ is now known as JanC === efm__ is now known as efm