[00:17] <supercool> I am trying to make a shared folder persistent as https://gist.github.com/estorgio/1d679f962e8209f8a9232f7593683265
[00:17] <supercool> The item 2 Add the following line to fstab (separated by tabs) and press Ctrl+O to Save.
[00:18] <supercool> As shared /home/<username>/shared vboxsf defaults 0 0
[00:18] <supercool> Is blocking the boot process
[00:18] <supercool> Any ideas what could be happening?
[00:20] <sarnold> supercool: sagrawal-idrc's comments seem likely to be in the right direction
[00:24] <supercool> sarnold: alright, checking it.
[07:57] <lordievader> Good morning
[08:03] <jamespage> coreycb, sahid: reminder to us all - when removing py2 support, remember to drop all maintainer scripts that deal with alternatives only.
[08:10] <sahid> jamespage: ack
[09:25] <friendlyguy> hi i am trying to get ubuntu 18.04.2 LTS to resolve .local hostnames
[09:41] <friendlyguy> its just ignoring my dns settings from netplan
[09:41] <friendlyguy> how can i make sure the nameservers i set in the netplan config are actually being used?
[09:42] <friendlyguy> netplan --debug apply show the correct nameservers
[09:43] <friendlyguy> but i cant resolv hostnames that have a .local domain
[09:43] <blackflow> btw, .local shouldn't be used outside of mDNS. iirc resolved would refuse resolving those
[09:46] <friendlyguy> well, not an option to change that
[09:47] <friendlyguy> i need to fix the server so its asking the dns server for those hostnames
[09:47] <blackflow> then you shouldn't be using systemd-resolved, if you're going against the standards and specs.
[09:47] <friendlyguy> i think its very common to have .local domains in ad
[09:49] <blackflow> .local is reserved for mDNS via RFC <number forgotten> so whoever is using .local for regular DNS is doing it wrong, "common" or not.
[09:49] <blackflow> your options are either to employ mDNS in your network for .local, or don't use systemd-resolved.
[09:51] <friendlyguy> okay, what do i need to do to remove systemd-resolved?
[09:53] <blackflow> stop the service, disable it, mask it. set up resolv.conf manually for your upstream resolver. unlink it first, as it's a symlink into /run/...
[09:54] <blackflow> oh also, iirc you shouldn't then use DNS config in netplan. I think that thing only talks to resolved. I'm not using netplan anywhere, so I can't test for you.
[09:54] <friendlyguy> what do you mean by "mask it"
[09:55] <friendlyguy> i disabled and removed the service, i removed the resolv.conf symlink
[09:55] <blackflow> `systemctl mask systemd-resolved.service`
[09:55] <blackflow> if you just disable it, other processes like netplan, NM, ...   can start it
[09:56] <friendlyguy> ah. thanks for explaining that
[09:56] <friendlyguy> i did it and saw a symlink to /dev/null was created
[09:58] <blackflow> right.
[10:01] <friendlyguy> okay, this looks much better
[10:01] <friendlyguy> ping to host works, ping to host.local works
[10:01] <friendlyguy> btw. interesting to read: https://en.wikipedia.org/wiki/.local
[10:02] <friendlyguy> there are examples for the "confusing" recommendations microsoft gave its customers
[10:02] <friendlyguy> i know plenty of HUGE (80000 servers+) domains that are on .local
[10:04] <blackflow> nothing wrong with .local if it's done via mDNS tho
[10:05] <friendlyguy> well, they are not :)
[10:08] <blackflow> gtg, good luck.
[11:38] <jamespage> coreycb: yuck - https://launchpadlibrarian.net/427745205/buildlog_ubuntu-eoan-amd64.python-oslo.log_3.44.0-0ubuntu3_BUILDING.txt.gz
[11:38] <jamespage> oslo.config -> oslo.log -> oslo.config
[11:49] <jamespage> nicely wedged
[12:06] <coreycb> jamespage: thanks for fixing that
[12:29] <Koopz> https://gist.github.com/Koopzington/dacef5d2b76890a5d2f6c386e9bf9124 would you say that HDD needs to be replaced after spamming syslog with those messages for about a week?
[12:32] <jamespage> coreycb: not fixed yet - trying to figure out how to unpick
=== jhona-aima1 is now known as jhona-aima
=== jhona-aima1 is now known as jhona-aima
=== jhona-aima1 is now known as jhona-aima
[13:48] <rbasak> ahasenack, bryce, paride, rafaeldtinoco: I just noticed that if we mark a bug Won't Fix and the reporter responds, that won't reappear for triage.
[13:48] <rbasak> I can fix this easily enough, but the question is: exactly which statuses, if any, should we exclude for retriage?
[13:49] <rbasak> For example: do we want a comment on a bug where are tasks are marked "Fix Released" to reappear for triage?
[13:49] <rafaeldtinoco> rbasak: well, won't fix sounds appropriate to revisit (maybe by another person)
[13:49] <rbasak> rafaeldtinoco: right - so I think we should at least add "Won't Fix" to the list of "bugs that reappear for triage if there is activity"
[13:49] <rafaeldtinoco> rbasak: fix committed could appear again (for proposed migrations check)
[13:50] <rafaeldtinoco> it would remind us to check regressions during triage (? makes sense ?)
[13:50] <rbasak> Proposed migration isn't really part of our triage process - we check the excuses list separately to make sure we cover that.
[13:50] <paride> rbasak, we recently discussed this for the curtin/cloud-init triage and agreed to look only at active bugs with the following statuses:
[13:50] <rafaeldtinoco> alright
[13:51] <rbasak> For triage purposes what I want to make sure is that we don't miss useful community communication by accident.
[13:51] <rafaeldtinoco> makes sense
[13:51] <paride> New Incomplete Confirmed Triaged In Progress
[13:52] <paride> so no wontfix, with the idea that the bug reporter should set the status back to New if they want to reopen the discussion
[13:52] <rafaeldtinoco> paride: should we leave a msg warning about that ?
[13:52] <rafaeldtinoco> i wouldn't know :\
[13:52] <rbasak> paride: I noticed through bug 1832110, where I explicitly asked the reporter to do that but they didn't. I'm not sure how I could have made it clearer.
[13:52] <ubottu> bug 1832110 in openssh (Ubuntu) "Resource Sharing with multiple sshd services" [Undecided,Won't fix] https://launchpad.net/bugs/1832110
[13:53] <rafaeldtinoco> reporter might be afraid of changing that after a maintainer/core dev changes it to wontfix.. i would give the argument but not change the flag
[13:55] <paride> rafaeldtinoco, I think that most of the time we explicitly tell the reporter to change the status back to New if they think the issue is not actually solved -- at least I do, and I mostly took rbasak's replies as my reference :)
[13:57] <rbasak> Perhaps, if we always do that (I do, and it sounds like paride does), then we can accept that the kind of occurrence in this bug today will get missed, and that's OK.
[13:57] <rafaeldtinoco> yep, if explicitly said, i would
[13:58] <rafaeldtinoco> "could you double check because of X, Y, z" -> change back to new.. sounds okay
[13:59] <blackflow> Koopz: I definitely would, yes. Also check its S.M.A.R.T attributes log, via smartmontools.
[14:01] <paride> rafaeldtinoco, that's what I'd personally stick to, but I don't oppose adding wontfix to the list of statuses we watch, unless it adds too much noise
[14:02] <bryce> rbasak, due to all these considerations, I've generally avoided applying wontfix to bugs except in extreme cases where I know there's going to be more feedback but the decision is final.  So I generally would agree with paride that it should be omitted.  It depends a lot though on the team's policy for when wontfix is applied; if it's done more liberally then revisiting may make sense
[14:04] <bryce> and yes, people tend to be very reticent about changing bug states or tags, even when you invite them to
[14:05] <coreycb> jamespage: any luck with oslo.log? i'm not clear on how they are wedged. looking now
[14:06] <jamespage> coreycb: no been re-doing some upstream reviews for neutron
[14:07] <jamespage> coreycb: python3-oslo.log in proposed fails to install; I tried to update to fix that but oslo.log->oslo.config->oslo.log (which fails to install from proposed)
[14:07] <jamespage> coreycb: if we can quickest solution might be to get python-oslo.log removed from proposed
[14:08] <coreycb> jamespage: ok i think i'll put that request in. and it seems like the new version with your updates should work.
[14:08] <rbasak> bryce: I tend to Won't Fix more liberally, because I feel that anything else perpetuates the expectation that the work in in some queue somewhere waiting to be done, when in fact we have no intention of doing anything.
[14:08] <rafaeldtinoco> Warning /!\ the following status changes are restricted to members of UbuntuBugControl or package maintainers:
[14:08] <rafaeldtinoco> Moving from Won't Fix.
[14:08] <rafaeldtinoco> does a regular user can change from won't fix ?
[14:09] <rafaeldtinoco> (ubuntu wiki bugs/bug statuses)
[14:09] <rbasak> rafaeldtinoco: good point. I thought they could because I've seen enough status fights over Won't Fix. But perhaps not everyone.
[14:09] <rbasak> In that case perhaps we should add this status to the search list.
[14:09] <rbasak> cpaelzer: you weren't hear earlier - please see above discussion
[14:09] <rbasak> here
[14:10] <rbasak> I swear I have a "typing part" of my brain now that hears words sans grammar.
[14:12] <rbasak> Going back to the above discussion, I don't think bugs should ever be considered to be in a "terminal state" as it were.
[14:12] <rbasak> It should always be possible for them to be "rescued" from that by an interested community member who can provide an appropriate justification
[14:12] <rbasak> However the bug status does set expectations conclusively, and I'd like to retain the ability for us to do that.
[14:13] <rbasak> (without eliminating the possibility of discussion of changing our minds)
[14:13] <rafaeldtinoco> rbasak: like rescuing wont fix for newer releases (after years)
[14:13] <rafaeldtinoco> instead of opening new ones (and having history)
[14:14] <rbasak> Yes, if it's truly the same issue and not a new one.
[14:14] <rafaeldtinoco> yep
[14:14] <rbasak> (which is subjective of course)
[14:14] <TJ-> ^^^ had one of those today from 2009 !
[14:14] <rafaeldtinoco> TJ-: yep, i proposed a merge to CTDB (from 2011)
[14:14] <rafaeldtinoco> i mean, can happen!
[14:14] <TJ-> I asked the user to start a new bug but left a comment on the original
[14:15] <rbasak> I think it's fine to leave that choice up to whoever is driving the bug.
[14:16] <TJ-> rbasak: I think it's as you said; if W.F. is not used liberally to close off things prematurely, then additional comments (often arguments ad-nausium) don't need to be seen
[14:17] <cpaelzer> yep, all is a case-by-case decision - but we should not filter them out in e.g. triage
[14:17] <cpaelzer> rbasak: do we filter them atm?
[14:17] <TJ-> Bug Squad can always change status if its glaringly wrong too
[14:18] <rbasak> cpaelzer: accidentally we do, yes. I can provide a PR to fix easily - I just need to know which statuses we want to appear in triage. Am I right in thinking that you're advocating "all of them"?
[14:19] <bryce> rbasak, part of my opinions were shaped working on X.org bugs, where a given bug could have scores or hundreds of commenters who think they have the same issue but aren't even on the same video driver ;-)  Setting a bug to wontfix could really bring the rats out of the woodwork sometimes.
[14:21] <bryce> rbasak, long ago ctrl-alt-backspace used to be a shortcut to terminate the X session, and when I disabled it by default in the distro it generated a lot of discussion that ended with wontfixes.  ;-)
[14:21] <rbasak> bryce: yeah - I call those "pileon" bugs. Where people think they have the same bug because they share some common symptom. Impossible to "fix" because the same symptoms can be caused by multiple root causes, and it is sometimes impossible to eliminate all of them (especially when some root causes are user misconfigurations rather than bugs, but others were actually bugs that got fixed)
[14:24] <bryce> rbasak, yeah I called them me-too storms.  Got a lot of them for video driver bugs, where each was specific to a given piece of hw but had the same general symptoms (e.g. black screen of death) so whatever one got best billing in google got all the subscribers, regardless of drivers
=== cpaelzer__ is now known as cpaelzer
[14:29] <cpaelzer> rbasak: never the less I think for server bugs we better should see them (and quickly call them done) than missing them
[14:29] <cpaelzer> we do not have a lot of those "me too" bugs
[14:31] <bryce> yeah server is in a much better situation.  Reporters also seem to be more technically inclined which is nice.
[14:35] <rafaeldtinoco> well, the burden of reading 1 or 2 last comments to figure out we should keep it as a wontfix, or call it done, is not big.. and possibly reporter would get very satisfied with one last comment or confirmation.. so +1 on what cpaelzer said
[14:37] <hggdh> rbasak, rafaeldtinoco: you could get the server team added to BugControl -- this would give all in the team the ability to set/reset status
[14:38] <cpaelzer> hggdh: youmean https://launchpad.net/~ubuntu-bugcontrol?
[14:38] <hggdh> cpaelzer: yes
[14:39] <cpaelzer> yeah rbasak, bryc, andreas and myself likely are in there by being core-dev's
[14:39] <rafaeldtinoco> "The Bug Control team is a subset of the Bug Squad and has the ability to set the Importance of bug reports regarding Ubuntu."
[14:39] <cpaelzer> thanks for the hint
[14:39] <rafaeldtinoco> fits the description =)
[14:39] <cpaelzer> https://launchpad.net/~canonical-server already is a member
[14:40] <ahasenack> note that ubuntu-server is an open team iirc
[14:40] <rbasak> hggdh: yes we already have that
[14:40] <cpaelzer> yeah that would be open, but the one I posted is not
[14:40] <cpaelzer> and it already is in there
[14:40] <rbasak> via ~canonical-server
[14:40] <ahasenack> is tinoco in there?
[14:40] <cpaelzer> and rafaeldtinocois a member
[14:40] <hggdh> so rafael is not a member of this team?
[14:40] <rafaeldtinoco> ahasenack: im here
[14:40] <hggdh> oops
[14:40] <rafaeldtinoco> ah nm
[14:40] <rafaeldtinoco> lol
[14:40] <ahasenack> ¯\_(ツ)_/¯
[14:40] <rbasak> hggdh: the question about not being able to change from Won't Fix to New is about community contributors, eg. if they want reconsideration of that status.
[14:41] <hggdh> rbasak: oh, OK. Yes, only BugControl (and drivers) can move from terminal status.
[14:42] <hggdh> our experience with having all changing status was... rather bad, with people randomly changing status
[14:42] <ahasenack> rafaeldtinoco: ubuntu-fan is green, should migrate any moment
[14:42] <rafaeldtinoco> \o/
[14:42] <ahasenack> I'm not stalking it specifically, I'm looking for my munin retry ;)
[14:42] <ahasenack> but you know, it's one big page
[14:42] <rafaeldtinoco> O.o
[14:43] <rafaeldtinoco> ahasenack: on the ctdb merge, ill go ahead and merge those 2 patches (non upstream)
[14:43] <rafaeldtinoco> i think it will be better to maintain if needed, when you merge samba again
[14:43] <ahasenack> yep
[14:44] <ahasenack> and I also don't think we need that huge description about versions < 4.10, which doesn't matter for eoan
[14:44] <ahasenack> the fix is simple, it's about using the correct service names
[14:44] <ahasenack> when samba gets updated, the patch will be refreshed or removed, just business as usual
[14:44] <rafaeldtinoco> k
[17:38] <bryce> I'm noticing there are two "styles" of lxc, one provided by the lxd-client, another from lxc-utils.  I've got both installed (i.e. lxc list and sudo lxc-ls produce different container listings).  I prefer the former, but I've only gotten autopkgtest to work with the latter.
[17:39] <bryce> I notice there's also an actual 'lxc' installable package from universe, although I haven't tried it
[17:40] <bryce> `autopkgtest <whatever>.dsc -- lxc -sed <container>` seems to expect lxc-utils.  Is there a way to make it use lxd-client instead?
[17:40] <bryce> ahasenack, are you using lxc with autopkgtest runs?  How are you doing it?
[17:41] <ahasenack> bryce: so
[17:41] <ahasenack> bryce: short answer: yes
[17:41] <ahasenack> but let's qualify "lxc"
[17:42] <ahasenack> there is old style lxc, the lxc-something commands (like lxc-ls), and that is the only one in debian afaik
[17:42] <ahasenack> and there is lxd, where the daemon is lxd, but the command line is just lxc (no dash to a subcommand)
[17:42] <ahasenack> I'm using lxd then
[17:42] <ahasenack> and I also use qemu, depending on the test
[17:43] <ahasenack> you should not use lxc-ls & friends, that is old and done
[17:43] <ahasenack> you'll notice there is autopkgtest-build-lxc (don't use this)
[17:43] <ahasenack> and autopkgtest-build-lxd (that's the one)
[17:43] <bryce> ok
[17:44] <ahasenack> likewise, there is autopkgtest-virt-lxc
[17:44] <ahasenack> and autopkgtest-virt-lxd
[17:44] <ahasenack> the latter is used when you specify autopkgtest .... -- lxd <imagename>
[17:45] <ahasenack> bryce: lxd in later ubuntu releases (don't remember since when right now) is only available as a snap
[17:46] <ahasenack> there is a wrapper deb package, but it will install the snap in postinst
[17:46] <bryce> ahasenack, aha  autopkgtest .... -- lxd  seems to be working and looks like what I'm after, thanks!
[17:46] <ahasenack> cool!
[19:44] <bryce> ahasenack, zookeeper has the same problem with adduser as the other thing
[19:44] <bryce> adduser: Warning: The home directory `/var/lib/zookeeper' does not belong to the user you are currently creating.
[19:47] <bryce> --> https://bugs.launchpad.net/ubuntu/+source/zookeeper/+bug/1832400
[19:47] <ubottu> Launchpad bug 1832400 in zookeeper (Ubuntu) "Warning on adduser that home dir doesn't belong to zookeeper user" [Undecided,New]
[20:00] <sdeziel> cyphermox: I'm setting up a sit tunnel with HE using netplan and following https://netplan.io/examples#connecting-an-ip-tunnel. I tried to skip the 'local' param as I do on ifupdown setups but netplan doesn't let me. This can be annoying for setup where the IPv4 is dynamic in nature. Should I fill a bug or am I doing something stupid here?
[20:14] <ahasenack> bryce: is it really just a warning, in terms of exit codes?
[20:18] <cyphermox> sdeziel: please file a bug. AFAIK this is a limitation of networkd we need to deal with
[20:24] <sdeziel> cyphermox: thx
[20:34] <bryce> ahasenack, seems to be.  found there was another zookeeper bug reported years ago suggesting the same things we found
[20:38] <sdeziel> cyphermox: https://bugs.launchpad.net/ubuntu/+source/plan/+bug/1832404
[20:38] <ubottu> Launchpad bug 1832404 in plan (Ubuntu) "sit tunnel should not require the local param" [Undecided,New]
[20:39] <ahasenack> bryce: did you get a set -x run yet in autopkgtest?
[20:46] <bryce> ahasenack, I'm poking around inside the container trying to see how to trigger it to start building the .dsc
[20:47] <ahasenack> bryce: which container? The one spawned by autopkgtest?
[20:47] <bryce> yeah
[20:47] <bryce> seems to not have javahelper installed
[20:47] <ahasenack> it's in a stopped state because the test failed, and you logged in?
[20:47] <bryce>  dpkg-source --before-build src
[20:47] <bryce> dpkg-checkbuilddeps: error: Unmet build dependencies: javahelper
[20:47] <bryce> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
[20:47] <bryce> dpkg-buildpackage: warning: (Use -d flag to override.)
[20:47] <bryce> root@autopkgtest-lxd-zgynnm:/tmp/autopkgtest.5vcQz7/build.xKm/src# apt-get install javahelper
[20:47] <bryce> + apt-get install javahelper
[20:47] <ahasenack> (the test run is stopped, not the container)
[20:47] <bryce> Reading package lists... Done
[20:48] <bryce> Building dependency tree
[20:48] <bryce> Reading state information... Done
[20:48] <bryce> E: Unable to locate package javahelper
[20:48] <bryce> r
[20:48] <bryce> looks like it stopped before it got to the test, like around line 757 on http://paste.ubuntu.com/p/QJ92bP6Bn9/
[20:48] <ahasenack> is it the right ubuntu relesae?
[20:49] <ahasenack> I see the same error as before, the postinst failing at the bottom of the paste
[20:50] <bryce> javahelper is a universe package so needed to enable that
[20:50] <ahasenack> 757 says Setting up javahelper (0.72.1~18.04.1) ...
[20:50] <ahasenack> I don't see an error around line 757
[20:50] <ahasenack> I suggested the -x to see what exactly failed in the postinst in line 1718
[20:51] <bryce> ahasenack, oh I meant, that's how far along it got before it logged me in
[21:04] <Ussat> I present to you:  Linux Ubuntu-1804LE 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:27:02 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
[21:04] <Ussat> \o./
[21:21] <ahasenack> Ussat: new box?
[21:49] <Ussat> I am doing a POC with IBM......Thats a POwer8 box running Ubuntu
[21:50] <Ussat> We are debating and testing, might move all our *nix off of esxi on to Power Hardware
[21:50] <Ussat> I am running the POC
[21:50] <Ussat> the test lab is in NY, I am in Iowa :)
[22:05] <sarnold> Ussat: woo, shiny :)
[22:06] <Ussat> Been struggling with rsct and dlparing, have an email to a IBM dev out
[22:07] <Ussat> Have it working with RHEL and Cent...its close w/Ubunnntu...but just not there yet...we will see what tomorrow brings
[22:08] <sarnold> "did you mean .. despairing .. ?"  :)
[22:08] <Ussat> heh
[22:32] <bjonnh> I'm trying to automate installs of ubuntu server using virt-install
[22:32] <bjonnh> virt-install --name test_vm --vcpus 2 --ram 256 --location http://archive.ubuntu.com/ubuntu/dists/disco/main/installer-amd64/ --disk vm.qcow2,bus=virtio,cache=none,size=5 --graphics none --console pty,target_type=serial --extra-args 'console=ttyS0,115200n8 serial' --network user,model=virtio
[22:32] <bjonnh> when I do that I get a --[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--
[22:35] <bjonnh> (tried without virtio as well)
[22:42] <bjonnh> (my purpose here is to provision VMs on a libvirt enabled server)
[22:43] <Ussat> \o/ dynamic LPARS workiong, was missing dynamicrm_2.0.1-3_ppc64el.deb