[01:24] <X-Rob> tomreyn: They're not meant to be secure. They're also not meant to be exposed to the internet, either.
[04:58] <Hackerpcs> I'm having an "issue" with an smb share. I record internet radio with vlc (cron, cvlc) and I play it with VLC over smb in Windows 7. The problem is the time doesn't refresh so when it reaches the end of the duration it read when it was opened, it stops. I found that if I try to copy the file in Windows, the duration gets updated. When I recorded it on Windows 7 and streamed to Windows 7, the
[04:58] <Hackerpcs> duration was updated. Anyone know if there's something to make the duration get updated every second?
[05:19] <cpaelzer> good morning
[06:41] <jamespage> cpaelzer: morning
[06:42] <jamespage> hurrah for endian-ness bugs! - https://launchpad.net/~james-page/+archive/ubuntu/rocky/+packages
[06:44] <cpaelzer> hi jamespage
[06:44] <cpaelzer> grml
[06:45] <cpaelzer> jamespage: are you sure this is endieness
[06:45] <cpaelzer> endian-ness
[06:45] <cpaelzer> gcc: error: unrecognized command line option '-Wthread-safety'; did you mean '-fthread-jumps'
[06:45] <cpaelzer> to me that appears different options on different platforms?
[06:45] <cpaelzer> I have read the log for 3 seconds now, maybe I should spend more
[06:46] <cpaelzer> that could as well be a normal config prompt
[06:46]  * cpaelzer is reading
[06:48] <cpaelzer> or is it tests 805/810/814?
[06:49] <jamespage> its the test failures
[06:50] <cpaelzer> didn't you in the past just mask them and report to upstream plus arch owner?
[08:35] <jamespage> cpaelzer: I have yes and will probably do that - I've already mail dev upstream
[08:46] <cpaelzer> rbasak: isn't bug 1787727 just a copy and paste of the message the maintainer scripts print?
[08:46] <cpaelzer> what else would you suggest than an too unfriendly "please read what is written"?
[08:47] <cpaelzer> dpkg histroy suggests switches between myslq/maridb are the trigger
[08:50] <cpaelzer> I tried to kindly explain, if your think there is more to be added let me knwo
[08:52] <cpaelzer> rbasak: also FYI I was afraid to accidentially cancel the process of the importer so I detached from the screen and will only check the log if there is any reason to do so
[08:52] <cpaelzer> rbasak: or did you check on a regular base without a ping to do so?
[08:53] <jamespage> cpaelzer: now I just need to figure out why ${python3:Depends} ends up subbbed in python:any
[08:53]  * jamespage scratches his head
[08:55] <rbasak> cpaelzer: your bug response seems reasonble.
[08:55] <rbasak> cpaelzer: I don't check the importer without a ping.
[08:55] <cpaelzer> jamespage: the third b is the reason :-)
[08:56] <jamespage> oh probably
[08:57] <cpaelzer> 3 vs not 3
[08:57] <cpaelzer> ?
[08:58] <cpaelzer> jamespage: did you push to the pgk git already?
[08:58] <jamespage> cpaelzer: not yet - I know that the py3 issue is tho
[09:24] <jamespage> cpaelzer: I'm right with my we need rdma-core in UCA for the new dpdk mellanox support
[09:30] <cpaelzer> jamespage: I think only if you want/need to go further than Bionic
[09:30] <cpaelzer> Bionic had 17.1 I think
[09:30] <cpaelzer> which could be recent enough
[09:31] <cpaelzer> newer DPDK need newer rdma-core, but I thought 17.11.3 was not yet one of those
[09:31] <cpaelzer> jamespage: lets disambiguise a bit here
[09:31] <cpaelzer> the DPDK in Cosmic and Bionic atm (without UCA) are virtually identical
[09:32] <cpaelzer> as since Bionic we have a MRE to drive back stable releases
[09:32] <cpaelzer> and Cosmic not picking a newer one for openvswitch not being compatible
[09:32] <cpaelzer> that said implies that the rdma-core in Bionic is fine for the 17.11.3
[09:32] <jamespage> yeah this was for xenial
[09:32] <cpaelzer> uh
[09:32] <cpaelzer> ok so you are not thinking about the cosmic->bionic route
[09:32] <cpaelzer> but bionic->xenial
[09:33] <cpaelzer> yeah there you'll need it
[09:33] <jamespage> cpaelzer: no - if the rdma-core in bionic is good enough, we'll skip it for the Rocky UCA
[09:33] <cpaelzer> yep, as rocky is only for 18.04
[09:33] <cpaelzer> down the road I assume in DD release we will pick up a newer DPDK, needing a newer RDMA code and then for UCA-S* you'll need it
[09:33] <cpaelzer> but not atm
[09:34] <jamespage> yeah we do things on an as-needed bases
[09:34] <jamespage> is
[09:35] <cpaelzer> all your base belong to us anyway
[09:40] <jamespage> :)
[11:01] <RoyK> cpaelzer: all your base *are* belong to us ;)
[11:02] <RoyK> cpaelzer: https://www.youtube.com/watch?v=8fvTxv46ano
[11:10] <cpaelzer> you are right RoyK
[11:11] <cpaelzer> I'll use 2*are next time to be ok on average
[11:11] <RoyK> lol
[12:42] <boxrick> Within the pre-seed is it possible to output some form of debug mid run ? Either to a console or similar?
[12:42] <boxrick> Alt + f4 scrolls back quite quickly
[13:35] <RoyK> boxrick: guess netconsole might be an idea
[13:35] <rbasak> ahasenack: pmdk/ndctl for Bionic uploaded. Now it's in NEW. I've also pushed upload tags.
[13:35] <ahasenack> rbasak: thanks
[13:37] <ahasenack> rbasak: can you check this commit? The multiple changes to d/changelog look odd: https://git.launchpad.net/ubuntu/+source/talloc/commit/?id=85882c4aa32823d0e3d2a1d4be27ab3991b5662a
[13:38] <rbasak> I suspect a previous merge missed out the merged changelog
[13:38] <rbasak> Oh
[13:38] <rbasak> I see
[13:38] <rbasak> It was previously in sync
[13:39] <rbasak> Wait let me get my story straight
[13:40] <rbasak> Nothing special happened here.
[13:41] <rbasak> The importer parented against 2.1.11-2, which is the second changelog entry. So this upload is "derived" from that, which is why the importer used it, which is the intended current algorithm.
[13:41] <rbasak> A consequence is that you see older Ubuntu changelog entries being added, because that's the diff to its "Debian" parent.
[13:42] <rbasak> The "Ubuntu" parent isn't considered any more (if it ever was?) by the importer algorithm.
[13:42] <rbasak> (I think it was, but we intentionally changed that around Nov last year)
[13:43] <rbasak> nacc: ^ this is an interesting case to me. I don't know if it's obvious and we agreed it would happen. Do you think it's fine?
[14:00] <rbasak> I suppose it's essentially equivalent to our regular package merge workflow, but with all commits squashed together because rich history wasn't supplied.
[14:07] <ahasenack> rbasak: I saw it while preparing a new debian merge, and deconstructing the changelog bits
[14:08] <ahasenack> (or reconstructing? I can never differentiate them. The first rebase)
[14:09] <ahasenack> rbasak: interesting, d/control still had the debian maintainers
[14:09] <ahasenack> probably just a mistake
[14:22] <jottr> Hi all. How do I make sure, that any user (even ubuntu-user) are required to enter a password when running `sudo`.
[14:26] <sdeziel> jottr: you'd need to audit your sudoers rules in /etc/sudoers and /etc/sudoers.d/*
[14:27] <jottr> sdeziel: Ah /etc/sudoers.d/* I didn't check. Thanks for pointing that out.
[14:28] <sdeziel> np
[14:52] <ahasenack> rbasak: cpaelzer: quick review for a small delta? This will unblock ldb in cosmic-migration: https://code.launchpad.net/~ahasenack/ubuntu/+source/talloc/+git/talloc/+merge/353503
[14:53] <rbasak> Looking
[14:53] <ahasenack> cpaelzer: man, I keep forgetting to switch target series to cosmic in bileto :/
[14:53] <rbasak> ahasenack: a package merge review is non-trivial for me because of the mechnical checks that we don't have full automation for yet :-/
[14:53] <ahasenack> why is zesty and yakkety still in that list anyway? :)
[14:54] <rbasak> But I'll look anyway
[14:54] <ahasenack> the delta is one commit
[14:54] <ahasenack> should help
[15:00] <rbasak> ahasenack: +1. I think you want sponsorship?
[15:00] <ahasenack> rbasak: yes please
[15:02] <rbasak> Done
[15:02] <ahasenack> \o/
[15:04] <ahasenack> kstenerud_: so, what happens now with that postfix mp,
[15:04] <ahasenack> kstenerud_: your changes are being sponsored by cpaelzer, meaning he will do the upload for you
[15:04] <ahasenack> kstenerud_: it will go into an unapproved pocket, waiting for a member of the sru team to look at it
[15:04] <ahasenack> this person will look at the changes, at the bug, see if the sru template is in good shape
[15:05] <ahasenack> decide based on that if this is worth an update to the stable release or not
[15:07] <ahasenack> kstenerud_: so now we wait for that one. Watch your inbox :)
[15:30] <ahasenack> kstenerud: that ssh bug, check my comment #3
[15:30] <ahasenack> kstenerud: and feel free to double check what I said, that it's fixed >= artful
[15:30] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1771340 ftr
[16:05] <nacc> rbasak: will read it back in a bit, otp
[16:07] <kstenerud> andreas: So for the openssh bug I've found the commit in artful that fixes the issue. It also has a bunch of other modifications. Do we want to just fix this one issue and make no other modifications? Or would a cherry-pick work here?
[16:13] <nacc> rbasak: what's the exact question?
[16:13] <nacc> rbasak: that commit looks completely correct to me? It was an Ubuntu merge done by doko without git-ubuntu
[16:13] <nacc> ahasenack: --^ ?
[16:22] <rbasak> nacc: it was a little surprising to me to see multiple changelog hunks in the "git log" for that commit.
[16:22] <rbasak> nacc: however I acknowledge that it is currently by design.
[16:22] <rbasak> nacc: so if you think it's fine, it's fine :)
[16:23] <rbasak> I suppose it's because we pick the changelog parent now and it isn't a merge commit against the Ubuntu publication parent.
[16:23] <rbasak> You'll probably tell me that that's what you expect because we deliberately made that change. If so, it's fine :)
[16:26] <nacc> rbasak: right we eliminted the publishing parent. there is now only some subset of changelog or upload parent.
[16:26] <nacc> rbasak: so it's no different than the merge-changelogs step being folded into the actual content
[16:26] <nacc> afaict
[16:30] <dpb1> rbasak: do you know the answer to kstenerud's question?
[16:30] <dpb1> rbasak: btw, thought you were flying today!?
[16:30] <nacc> dpb1: re: the openssh fix?
[16:31] <dpb1> nacc: yes
[16:31] <nacc> kstenerud: you should fix one issue with the one commit :)
[16:31] <nacc> kstenerud: it's probably certain you wouldn't cherry-pick across the releases
[16:31] <nacc> unless the thing you're cherry-picking is the bit you did in the other release yourself :)
[16:31] <dpb1> thx
[16:32] <kstenerud> nacc: OK, so I'd make my own patch to this version, right? Not grab a newer version from debian?
[16:32] <nacc> kstenerud: this is fix for bionic?
[16:32] <kstenerud> xenial
[16:32] <nacc> kstenerud: yeah, in that case, you'd not be merging, you'd be taking an isolating fix and backporting
[16:32] <dpb1> kstenerud: we don't tend to put back new versions to stable releases unless there is a very good reason.
[16:32] <nacc> kstenerud: ah ok, xenial and bionic are effectively the same thing
[16:33] <nacc> kstenerud: have you read the SRU page?
[16:33] <nacc> basically, the SRU requirements are much higher than in the development release :)
[16:33] <dpb1> kstenerud: there are some packages that are exceptions to that for various reasons, but the promise of ubuntu is that we keep things stable once released.
[16:35] <kstenerud> OK. So in this case the bug is that breaking the config and then reloading the service doesn't spit out an error, which makes the server unrechable if you log out afterwards without checking dmesg. Is that considered high impact?
[16:40] <dpb1> kstenerud: is it fixed in artful+?
[16:40] <dpb1> (bionic really)
[16:41] <kstenerud> dpb1: yes, it's fixed in artful onwards
[16:41] <dpb1> kstenerud: if the description on the bug is acurate, I think doing a service reload and the service silently not running is pretty bad.
[16:41] <rbasak> Was there still a question for me?
[16:41] <dpb1> it takes action by the user, but it's not crazy
[16:41] <dpb1> rbasak: no
[16:41] <rbasak> OK :)
[16:41] <dpb1> rbasak: well yes
[16:42] <dpb1> 16:30:46         dpb1 | rbasak: btw, thought you were flying today!?
[16:42] <rbasak> Oh
[16:42] <dpb1> :)
[16:42] <rbasak> Actually it was yesterday, but the weather was poor so we cancelled.
[16:42] <dpb1> what about today?
[16:42] <rbasak> Not enough aircraft availability :(
[16:42] <dpb1> ahh
[16:42] <rbasak> They're quite booked up usually and I need three consecutive slots, so it's awkward
[16:43] <rbasak> I've rebooked for after Brussels.
[16:44] <rbasak> Also one of their aircraft isn't suitable because it doesn't have an upgraded radio yet, so I can't talk to one particular air traffic service that I need to for my test (but otherwise it isn't strictly necessary, so they've put off an upgrade until the next major service)
[16:44] <dpb1> kstenerud: first up, we should fix the bug up to be accurate then.
[16:44] <rbasak> There's this big worldwide aviation radio upgrade thing going on - splitting every existing channel into three to create more space.
[16:45] <dpb1> kstenerud: it's fix-released in artful+, and we want it back to at least xenial
[16:45] <kstenerud> OK I'll get on it
[16:45] <dpb1> ahasenack: is that what you would normally do? ^
[16:45] <dpb1> add tasks, etc?
[16:47] <ahasenack> I would first get a branch
[16:47] <ahasenack> test it
[16:47] <ahasenack> make sure I have the right fix
[16:47] <ahasenack> then update the bug with the sru template
[16:47] <ahasenack> then make the MP
[16:47] <ahasenack> sometimes the MP first, bug template after, but close together
[16:48] <dpb1> OK
[16:55] <Ussat> any fix for thsi bug:  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1504659
[16:56] <ahasenack> trying: talloc
[16:56] <ahasenack> accepted: talloc
[16:56] <ahasenack> \o/
[16:59] <ahasenack> rbasak: do you know if a dependency-wait error is retried automatically? https://launchpad.net/ubuntu/+source/ldb/2:1.4.0+really1.3.5-1/+build/15263978
[16:59] <ahasenack> the required package is in cosmic-proposed already
[16:59] <ahasenack> I don't see a "retry" button/link there
[17:02] <nacc> ahasenack: it is not
[17:02] <nacc> (iirc)
[17:02] <nacc> i can see a retry
[17:03] <ahasenack> nacc: can you click that for me for all arches in https://launchpad.net/ubuntu/+source/ldb/2:1.4.0+really1.3.5-1 please?
[17:08] <nacc> ahasenack: ack
[17:08] <ahasenack> nacc: thx!
[17:09] <nacc> ahasenack: done, yw
[17:09]  * ahasenack sees the spinning iso icon
[17:16] <ahasenack> kstenerud: regarding debian patches, remember that changes to any file inside debian/ itself won't use a debian patch
[17:16] <ahasenack> debian patches are only for changes done to the upstream source code
[17:27] <ahasenack> build failure on the "funny" arches, :(
[17:27] <ahasenack> (ldb)
[17:32] <ahasenack> hah
[17:32] <ahasenack> ldb (2:1.4.0+really1.3.5-2) unstable; urgency=high
[17:32] <ahasenack>   * Add patch from upstream to fix FTBFS on some arches (arm64, armhf, mips,
[17:32] <ahasenack>     mipsel, s390x, ...)
[17:36] <kstenerud> ahasenack: so since this change modifies debian/systemd/ssh.service, I don't use a patch?
[17:36] <kstenerud> Do I just modify the file directly in the commit?
[17:36] <ahasenack> correct
[17:51] <nacc> kstenerud: in case it helps, do you understand why that's the case? :)
[17:53] <kstenerud> nacc: I'm guessing because anything inside the debian dir is exempt?
[17:53] <nacc> kstenerud: specifically, the way the source package is distributed is two tarballs, one is the orig tarball of the upstream. This is effectively not modified (except in cases of dfsg - Debian Free Software Guidelines) from upstream. Then there is a tarball of the debian directory separately.
[17:54] <nacc> (this is for 3.0 - quilt format, at least, which is quite common)
[17:54] <nacc> so since the orig tarball is unmodified, changes to it are carried as quilt patchs in the debian tarball; while changes to the debian path itself can be stored in the debian tarball normally
[17:55] <nacc> kstenerud: it's worth reading `man dpkg-source` a few times to catch up on terms there
[17:56] <kstenerud> ah ok :)
[17:56] <nacc> the debian manual also has some good guidance there
[17:57] <nacc> kstenerud: hopefully it's clear, but i'm not trying to just point what you don't know; but i found it eventually much easier to know why things were being donne the way they were, even if it took me a year to understand it fully :)
[18:21] <kstenerud> ahasenack: I hit a snag making the PPA for a fix. I used dput to upload the new openssh code, but now when I add the repo I get an error on apt update:
[18:21] <kstenerud> E: The repository 'http://ppa.launchpad.net/kstenerud/sshd-reload-1771340/ubuntu xenial Release' does not have a Release file.
[18:22] <ahasenack> kstenerud: a) check that the package built; b) check that you had "xenial" and not "cosmic" or something else in the d/changelog line with the version
[18:23] <ahasenack> kstenerud: looking at https://launchpad.net/~kstenerud/+archive/ubuntu/sshd-reload-1771340/+packages, it's still building
[18:44] <dpb1> ahhhh, ppa building / published
[18:44] <dpb1> :)
[19:01]  * dpb1 notes the current 'building' icon with 'published' status. :)
[19:45] <madLyfe> anyone setup plex server on ubuntu server before?
[20:02] <dpb1> y
[20:06] <Ussat> Yes
[20:35] <nacc> madLyfe: it's typically better in all ubuntu* support channels to not use polls :)
[20:35] <nacc> madLyfe: someone has almost always done what you are about to ask if someone has done.
[20:35] <nacc> madLyfe: instead, if you have a problem with it, ask your specific problem. If you are looking for a guide, ask for a guide.
[20:36] <nacc> madLyfe: saves your time and ours as volunteers.
[20:41] <madLyfe> I'm sorry about that nacc had is kind of spinning trying to decide what to use for my setup here
[20:42] <madLyfe> and I'm on phone right now while setting up a new server box in the basement. where all servers belong! I'll be back to the chat in a few.
[20:42] <nacc> madLyfe: understood -- just trying to help you ask better questions :)
[20:44] <madLyfe> I need a nacc IRL..
[20:45] <nacc> madLyfe: well i mean, i am real :)
[20:45] <madLyfe> you know, to be a better overall human
[20:45] <madLyfe> 😁
[20:46] <nacc> lol
[20:46] <nacc> well, that's on you ;)
[21:03] <madLyfe> so here is my situation and why it involves ubuntu:
[21:04] <madLyfe> https://www.irccloud.com/pastebin/gdtxNXbs/
[21:05] <madLyfe> thats kind of an explanation of the situation..
[21:06] <madLyfe> so ive given in to using a nix software raid. i just wasnt sure what route to take. something like FreeNAS/OpenMediaVault or just use ubuntu.
[21:07] <madLyfe> i am going to take the two 1tb drives and put them on an abandoned box utilizing a 16gb sandisk usb drive for the os and use ubuntu server. well thats as far as i am currently.
[21:08] <madLyfe> im not sure if this is the route you guys would have taken for such a thing but there are so many options.
[21:12] <coreycb> jamespage: tobias-urdin: i'm not sure what the problem is with openstack-dashboard. i think i'll have to bisect through the rocky updates to see when it worked last.
[21:13] <sdeziel> sigh, pastebin service that require Javascript  are... annoying ;)
[21:14] <sdeziel> madLyfe: if you go with Ubuntu, I'd suggest you give a try to zfs instead of mdadm
[21:14] <coreycb> jamespage: tobias-urdin: i'm not getting a response from the server and debug's not helping. also installing heat-dashboard seems to mess up the /usr/share/openstack-dashboard/openstack_dashboard alternative but that's a separate issue.
[21:18] <evit> I'm setting up automatic updates. If I don't specify Unattended-Upgrade::Automatic-Reboot-Time does it reboot immediately?
[21:21] <ahasenack> evit: yes
[21:21] <ahasenack> the comment above that setting in 50unattended-upgrades says so, at least
[21:21] <evit> ahasenack, great thank you. I was unclear on it
[21:23] <madLyfe> sdeziel: someone said nfs or something like that?
[21:23] <madLyfe> i just tried 'sudo parted -ls | nc termbin.com 9999' and it tossed errors
[21:24] <sdeziel> madLyfe: I'm suggesting to look at zfs to handle the FS as well as the RAID1 part which would remove the need from using mdadm raid
[21:24] <madLyfe> https://paste.fedoraproject.org/paste/fCORU~TBtFWBGZ860hEnnw
[21:25] <madLyfe> sorry, nfsd is what they said to use.
[21:27] <sdeziel> madLyfe: nfs is meant to export a FS to remote machines, which is not what I'm talking about
[21:28] <madLyfe> well i need to be able to access this via win 10
[21:32] <ahasenack> kstenerud: now, on https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1771340
[21:32] <ahasenack> kstenerud: you will see a "xenial task"
[21:33] <ahasenack> it's another line below the one with the package name
[21:33] <ahasenack> kstenerud: since this is fixed >= artful, and more importantly, in the current development release,
[21:33] <ahasenack> kstenerud: we will mark the "main" task, the one with no ubuntu release qualification, as fix released. That represents the development release
[21:33] <sdeziel> madLyfe: sorry, I may be confusing you. What I meant was just to advise you to look into zfs for the local filesystem and RAID portion of this server if you were to chose Ubuntu as the base OS
[21:34] <ahasenack> kstenerud: the xenial task, that's the one you are working on. You should mark that as in progress, and assign it to you
[21:35] <sdeziel> madLyfe: I mentioned zfs because it is one of the key advantage offered by Ubuntu from the selection of OS you provided (FreeNAS has it too)
[21:36] <madLyfe> sdeziel: i have already installed the OS on the thumb drive. not sure what it installs with by default.
[21:37] <kstenerud> ahasenack: ok done
[21:37] <sdeziel> madLyfe: the ZFS part would not be for the thumb drive but for the bulk data storage, the RAID1 array
[21:38] <ahasenack> cool
[21:44] <kstenerud> ahasenack: I don't see any inline comments
[21:45] <ahasenack> kstenerud: scroll down to the diff
[21:45] <dpb1> heh
[21:45] <ahasenack> or, click on "show diff comments" in the box surrounding my comment
[21:45] <ahasenack> on the far right
[21:46] <kstenerud> ok
[21:46] <ahasenack> (but that will just scroll down for you afaik)
[21:46] <dpb1> that interface isn't great
[21:58] <ahasenack> kstenerud: there is one comment I added after, it's the indentation of the changelog line
[21:59] <kstenerud> ahasenack: ok, pushed with a new commit
[22:00] <ahasenack> kstenerud: and I added one more comment :)
[22:01] <kstenerud> ah right :)
[22:11] <ahasenack> kstenerud: looks good, =1
[22:11] <ahasenack> +1
[22:11] <ahasenack> kstenerud: since it's a package that needs a core developer to sponsor, my +1 is not final, someone else will have to look at it tomorrow
[22:11] <kstenerud> ok no problem
[22:11] <ahasenack> kstenerud: I'd suggest to add to the description (or amend it) the link to the debian salsa commit with that change
[22:12] <ahasenack> because it's very localized there, and clear
[22:12] <ahasenack> kstenerud: which introduces you to salsa (the site)
[22:12] <ahasenack> kstenerud: that's where debian moved all their packaging repositories, or well, most of them. Some packages are not there yet
[22:12] <ahasenack> it's a gitlab site
[22:13] <kstenerud> how do I get a salsa commit link?
[22:13] <ahasenack> kstenerud: sometimes, as part of fixing something in ubuntu, we make a pull request (merge request in salsa lingo) there to fix it in debian too
[22:14] <ahasenack> kstenerud: I just went to salsa.debian.org, searched for openssh, then cloned it, and used git log (locally) and searched for the bug
[22:14] <ahasenack> that gave me the commit
[22:15] <kstenerud> umm... which one? The debian ssh maintainers?
[22:15] <ahasenack> yes
[22:15] <ahasenack> the more "official looking" one :)
[22:15] <ahasenack> I pasted the link in one of my review comments, but go ahead and try from scratch
[22:17] <kstenerud> ok added
[22:17] <madLyfe> sdeziel: i also just want to be sure that if i use zfs raid 1 that i would be able to take that raid array to a different system/hardware and have zfs pick it back up. like say if i moved to freenas zfs.
[22:17] <ahasenack> kstenerud: excellent
[22:18] <kstenerud> OK, gotta go pick up a canonical package in town
[22:18] <ahasenack> cool
[22:18] <sdeziel> madLyfe: yes, you can bring the array (or only one drive for that matter) to another machine. Plugging it to freenas should work as ZFS uses compatibility levels so presumably it would still work there
[22:18] <ahasenack> and I'm eod
[22:19] <ahasenack> kstenerud: see you tomorrow
[22:19] <kstenerud> l8r!
[22:19] <madLyfe> sdeziel: tyvm
[22:19] <sdeziel> madLyfe: the "transplant to freenas" part would need a little research if it's really something you want to do. Otherwise you can zfs send | zfs receive between Ubuntu and FreeNAS
[22:29] <madLyfe> im saying like, if my os drive was to go away, would the 2 disk raid array be just fine? can put it elsewhere?
[22:30] <sarnold> you might be restricted in your choices of "elsewhere"
[22:30] <sarnold> but between smartos / omnios / fbsd / proxmox / various linux distros / you'll probably be fine
[22:30] <madLyfe> k
[22:31] <mason> You'd need a subset of properties that work everywhere FWIW.
[22:31] <madLyfe> what does that mean?
[22:31] <mason> Features. https://bpaste.net/show/bb4bbdc9867e
[22:31] <madLyfe> also, why would this happen? https://paste.fedoraproject.org/paste/sWmWASPo7whE64IVf6GiFQ
[22:32] <mason> That was accurate as of Ubuntu Xenial and FreeBSD 10 or early 11.
[22:32] <sarnold> madLyfe: http://open-zfs.org/wiki/Feature_Flags
[22:32] <mason> Ugh, their paste requires JavaScript?!?
[22:33] <sarnold> madLyfe: because you only directed stdout to nc --> http://termbin.com/t2j7
[22:33] <madLyfe> mine or sarnolds?
[22:33] <sarnold> madLyfe: stderr still went to the terminal
[22:34] <madLyfe> what should it have been?
[22:34] <sarnold> well that's fine ifyou know what that means :) heh
[22:35] <madLyfe> sadly no. but the termbin is still correct? i mean it looks correct to me
[22:37] <madLyfe> also its odd that it didnt work the first time. i also had it not work the first time from a live usb boot with kubuntu.
[22:38] <mason> Hrm. I just told NetPlan to use NetworkManager as its global renderer and I said "netplan apply" but... nothing's changed.
[22:39] <mason> Does "netplan apply" not handle a renderer change?
[22:40] <mason> And why is there no netplan(8)?
[22:43] <mason> Restarting did the trick, but I have to have missed something to get it to reconfigure without a reboot.
[22:56] <nacc> mason: i think there's also a #netplan, but i might be wrong
[22:57] <mason> nacc: That rings a bell. I'll explore later I guess.
[23:03] <dpb1> huh... I guess it's in 5
[23:04] <dpb1> filing a bug would be fine (netplan.io)
[23:07] <mason> dpb1: For me? And we're running 4, and this exists in 5?
[23:08] <mason> I see netplan 0.36.3
[23:08] <mason> looking
[23:08] <sarnold> mason: I think dpb1 meant netplan(5)
[23:08] <mason> Ah.
[23:08] <sarnold> as opposed to netplkan(7(
[23:08] <sarnold> gah
[23:08] <sarnold> I can haz nap?
[23:08] <mason> dpb1: Yes, netplan(5) exists, but there's a netplan(8) command with no man page.
[23:08] <mason> net-q'plah!
[23:08] <sarnold> lol
[23:09] <mason> dpb1: netplan(8) would document the binary, where 5 is for file formats.