[00:13] <silox> Hello, I wanted to see if anyone could verify that both Landscape (on premises install) and MAAS will both function on Ubuntu 18.04 LTS that's scheduled to be released tomorrow.  Any help would be appreciated as I'd like to use 18.04 for a Landscape/MAAS deployment for an entire datacenter.
[00:14] <sarnold> dpb1: ^^ is this one for you?
[00:14] <sarnold> silox: I'd certainly expect both to be supported eventually, if they aren't actually working tomorrow afternoon..
[01:08] <dpb1> o/
[01:08] <dpb1> maas is in the archive as 2.4.0~beta2
[01:08] <dpb1> it will get updates, but should be working as is right now
[01:09] <dpb1> that version can deploy ubuntu on day 0 (hopefully!) :)
[01:09] <dpb1> sorry, can deploy bionic on day 0
[01:10] <dpb1> landscape-client is at 18.01 in bionic, and is supported there
[01:10] <dpb1> the server is not yet released for bionic, but will be eventually
[01:10] <dpb1> silox: ^
[01:11] <sarnold> dpb1: wonderful :D thanks
[02:32] <Slade> nss-pam-ldapd  will pass the password in clear text unless ssl is used right?
[03:17] <nacc> rbasak: didn't get to update my MP today, will try tmrw
[03:18] <sdeziel> Slade: it depends, StartTLS can also be used. I'd use tcpdump to confirm/check
[03:19] <Slade> starttls would be the ssl/tls
[03:19] <sdeziel> StartTLS is a mechanism to upgrade from plaintext to SSL/TLS
[03:19] <sdeziel> using the same communication port
[03:20] <sdeziel> which is 389
[03:49] <Howie69> So, transitioning from running debian servers to ubuntu virtual servers..
[03:50] <Howie69> I am wondering if anyone has anything written up about the advantages/disadvantages and compatibility issues of using different vms, such as AWS vs. Google Cloud?
[03:51] <Howie69> Or knows of something I can read up on the subject because my google searches returned no results
[05:11] <sdeziel> Howie69: I don't know about Debian but with Ubuntu, you can install a kernel specifically tuned for each of those cloud providers
[05:12] <sdeziel> Howie69: for AWS, the package linux-aws is based on the 4.4 kernel and for Google Cloud, the package linux-gcp is based on the 4.13 kernel
[05:13] <Howie69> sdeziel: That's awesome
[05:18] <sdeziel> Howie69: good luck with the transition
[05:31] <cpaelzer> good morning
[05:45] <tactic>  Hi all. I'm having trouble with trying to install Ubuntu Server. Both 16.04 and 17.10 give me the same problem, namely, I see GRUB appear after the BIOS/UEFI loads, but when I click "Install Ubuntu", my screen goes black and doesn't come back.
[05:45] <tactic> I've done a bit of research and others have had similar issues, it seems, but the recommended advice (set the nomodeset kernel flag and remove the splash flag) doesn't seem to help
[06:04] <Howie69> tactic: The only times I have ever run into that problem is when I mistakenly downloaded the image for the wrong processor type
[06:04] <Howie69> like amd64 on a i586 machine
[06:19] <tactic> Howie69, yeah, I did check that, and I have amd64
[06:19] <tactic> and the corresponding iso
[06:19] <tactic> hmm
[06:19] <tactic> Maybe I'll try Ubuntu desktop, since that's what currently installed
[06:19] <Howie69> can you drop to a console and check the output?
[06:20] <Howie69> I think it's cntrl+F2
[06:20] <tactic> I'm not sure. I can check, but it might have to wait until tomorrow at this point.
[06:20] <tactic> but it's worth at ry
[06:52] <tactic> Howie69, yeah, the CTRL+ALT+F1,2,3, etc didn't seem to do anything different
[06:52] <tactic> unfortunately
[06:53] <tactic> I'm wondering if I need to do something silly like remove my graphics card to install it, or maybe install the SSD into another computer, install Ubuntu, then transfer it :X
[07:05] <Pjusur> Good morning, is it possible to set apparmor status in some config file? or do I have to use the aa-{{status}} command?
[08:28] <Neo4> hi
[08:28] <Neo4> I've create my first shell script https://gist.github.com/kselax/62da283900350b6b437e4ace76a2312a
[08:28] <Neo4> and I'm going to create script like tasksell
[08:29] <Neo4> when we run script there will show list of items something like:
[08:29] <Neo4> 1 install apache2
[08:29] <Neo4> 2 install php5.6
[08:29] <Neo4> 3 install phpmyadmin
[08:29] <Neo4> 4 install mysql
[08:29] <Neo4> etc
[08:30] <Neo4> it looks like useful
[08:30] <Neo4> before I though to learn this command and now thing had better write shell script where all will documented
[08:30] <Neo4> what do you think about this?
[08:31] <Neo4> it can streamline work, significantly reduce time
[08:31] <Neo4> for install server you don't need know all command
[08:32] <Neo4> and we can make if user input 101 we will show for him list of help where he will able to chose what help he what, for example
[08:33] <Neo4> for apache 2 we could have 1 install apache and not explicetly 101 will show our own help reference where user will know what files you need edit where they are places, how to crate virtual hosts etc
[08:33] <Neo4> now I all gathered in text files, but more easy put all to shell script
[08:34] <Neo4> it must be done yes?
[08:34] <Neo4> any cool linux administrator must write his own shell script that will increase his speed
[08:35] <Neo4> we mustn't learn anything
[09:10] <cpaelzer> Neo4: for commandline people either know the commands, or if they want to select tasks/packages acn use e.g. aptitude
[09:10] <cpaelzer> which gives them even curses UI
[09:11] <cpaelzer> Neo4: I don't want to stop your learning exercise but the proposed doesn't seem to be very useful to me
[09:12] <Neo4> cpaelzer: why? or you will use instruction always and copy past command or you copy shell file and install all needed app on your VPS very fast
[09:12] <cpaelzer> Neo4: and to encapsulate the admin knowledge post raw package install there are plenty of infrastructures that help you do so juju, puppet, chef, ansible to name a few
[09:13] <Neo4> I'd better write my own infrastructure for apps that I use
[09:13] <cpaelzer> feel free to do so
[09:13] <cpaelzer> I'm mentioning alternatives, not trying to convince you of anything
[09:13] <Neo4> cpaelzer: but this is really entrence, you don't need learn command and you will pawerful
[09:14] <Neo4> did once and use multiple times
[09:14] <Neo4> :)
[09:14] <Neo4> I'm doing now first version
[11:16] <Neo4> installer how it will be
[11:16] <Neo4> https://gist.github.com/kselax/d24bf3ef187d1adb126e9b81ae44d385
[11:16] <Neo4> make menu and select items
[11:17] <Neo4> for example I always forget how to generate IRS key, for this I can put there in menu item "generate irs key" and select that item next time
[11:17] <Neo4> shell script must save times
[13:14] <Maxel> is it a bad idea to kill and apt-get upgrade process? I was ssh'd into my server when my connection was interrupted
[13:15] <rbasak> It's not good, but usually recovery tends to work OK.
[13:16] <rbasak> dpkg and apt go to quite some trouble to make it OK.
[13:16] <rbasak> Some package maintainer scripts may be more fragile though.
[13:17] <sdeziel> Maxel: if you have an unreliable connection, you can run tmux on the destination to prevent dropping abruptly (next time)
[13:19] <Maxel> well I should be able to foreground the process right?
[13:21] <Ussat> or screen
[13:21] <Maxel> oh, apparently not... can't "reparent" an orphaned process
[13:23] <sdeziel> Maxel: no, you cannot indeed
[13:25] <rbasak> It's orphaned?
[13:25] <rbasak> Then it's dead.
[13:25] <Maxel> not sure which proc is actually the one to kill... I've got sudo apt-get upgrade, apt-get upgrade, and dpkg --status-fd 62 --configure
[13:25] <rbasak> Uh.
[13:25] <rbasak> No, I was thinking zombie. Never mind.
[13:25] <Maxel> that come up when ps aux | grep apt
[13:43] <Maxel> so I ended up killing the apt process and ran dpkg --configure -a to repair it. I got the same grub error where it couldn't install to certain devices, same as described in this post: https://askubuntu.com/questions/315207/grub-failed-to-install-to-the-following-devices-error-on-upgrade
[13:45] <sdeziel> Maxel: could you pastebin your lsblk output?
[13:46] <Maxel> http://paste.ubuntu.com/p/vZVxGzBcHM/
[13:48] <sdeziel> Maxel: OK so you should be trying to install grub only into /dev/sdb, is that what you tried?
[13:48] <Maxel> yeah, I turned it off for sda, sdb5 and dm-0
[13:49] <sdeziel> did you turn it off for sdb1 too?
[13:50] <dpb1> Maxel: and you should really use 'byobu' or 'tmux' when running on a remote system. :)
[13:50] <dpb1> (years of experience)
[13:51] <Maxel> sure, I'll look at the documentation and figure out how
[13:51] <dpb1> there is a small learning curve, but it's worth it
[13:55] <Maxel> any reason to use screen over tmux?
[13:55] <Maxel> as the backend
[13:56] <dpb1> tmux is modern
[13:56] <dpb1> screen is not
[13:56] <dpb1> you will find much more dev effort on tmux
[13:56] <dpb1> so, if you are starting out, I recommend that
[13:57] <Maxel> awesome, thanks for the info
[14:03] <jayjo> I have a server that has a memory leak somehwere and I can't use most commands available to track it down
[14:03] <jayjo> free & df -h both cannot allocate memory
[14:04] <dpb1> hah
[14:04] <jayjo> even trying to use sudo service `example` stop gets a `cannot allocate memory`
[14:04] <jayjo> It feels like I'm in trouble
[14:04] <dpb1> yuck
[14:04] <dpb1> can ps run?
[14:05] <jayjo> unfortunately, no
[14:05] <waveform> do you have physical access to the server?
[14:05] <jayjo> no, it's an an AWS instance
[14:06] <waveform> (magic sysrq's "t" might be useful)
[14:06] <waveform> ah, well forget that idea then
[14:06] <dpb1> jayjo: can you cat files?
[14:07] <jayjo> ha! no I can't! Would increasing the server size in the aws console help? It's already a moderate-to-large instance
[14:12] <jayjo> I've inreased the instance type for a little bit here so I can move around. What's the best way to track this down now that I have some memory to use bash?
[14:17] <jayjo> this is my system's df output: https://bpaste.net/show/a8bc95416513 - doesn't really look like a leak, right?
[14:18] <jayjo> sorry - du output
[14:33] <waveform> jayjo, that's looking at disk usage - would be more interesting to see what's eaten all the memory with ps
[14:37] <rbasak> nacc: how would you feel about a policy that all new deps added to snapcraft.yaml are hosted on people.c.c over an external URL?
[14:37] <rbasak> Where possible, at least.
[14:47] <dpb1> jayjo: so... I think you probably are left with just a reboot
[14:47] <dpb1> jayjo: unless you really really want to figure out what is going on
[14:47] <dpb1> jayjo: what's the memory of the instance (not disk space, ram)
[14:54] <gQuigs> I know it's hilariously late.. (but I didn't notice it before today) - but do we think nagios3 (having known CVEs) should really live in universe for 18.04? https://bugs.launchpad.net/ubuntu/+source/nagios3/+bug/1696252
[14:56] <gQuigs> (even if we can't bring icinga2 full yo main as a replacement in time)
[15:01] <mdeslaur> +1 on demoting nagios3
[15:02] <mdeslaur> rbasak: ^?
[15:02] <rbasak> dpb1: ^
[15:04] <sdeziel> will it be possible to have icinga2 promoted to main during the lifetime of 18.04 ?
[15:05] <rbasak> I'm not sure how a change of component works after the release pocket is frozen.
[15:06] <nacc> rbasak: i think that makes sense -- also a tarball at a fixed rev is a lot faster than git
[15:07] <nacc> sdeziel: it is possible, but not common (iirc)
[15:08] <nacc> gQuigs: mdeslaur: rbasak: that was something we had worked on last cycle, iirc
[15:22] <jbicha> speaking of hilariously late security-sensitive removals, the blocker for webkitgtk removal is gnucash but it's build tests fail on Ubuntu
[15:22] <jbicha> we could just ignore those build tests… :|
[15:22] <jbicha> bug 1758740
[15:25] <nacc> rbasak: when you have a moment for a git-ubuntu question, let me know
[15:30] <teward> busy day I take it.  :P
[15:34] <nacc> rbasak: simply re: your MP feedback, I think if MockError is raised and only MockError is handled, it doesn't hide a RuntimeError elsewhere. I checked by changing the mock's raised Exception to a RuntimeError and it failed.
[15:35] <rbasak> nacc: what I mean is that if MockError is derived from RuntimeError, and the code handles a RuntimeError, it'll accidentally handle the MockError when we wanted it passed through
[15:36] <teward> rbasak: nacc: sorry to interrupt but what language are you guys working with there?  Python?
[15:36] <rbasak> Python
[15:36] <gQuigs> jbicha: or remove gnucash :/
[15:36] <teward> if MockError is based on RuntimeError but your try/except only catches MockError it won't accidentally catch RuntimeError
[15:36] <teward> rbasak: ^
[15:36] <teward> the way Python error classes are, *every* error inherits Exception (RuntimeError does too!)
[15:37] <teward> but if MockError is its own defined error class and you only catch MockError RuntimeError is seen as a different 'class' of capture
[15:37] <teward> and excluded from MockError cathces
[15:37] <rbasak> teward: understood. I think you're missing context.
[15:37] <rbasak> We're injecting a MockError.
[15:37] <teward> i probably am.  (Would be glad to assist)
[15:37] <rbasak> The code under test could catch RuntimeError.
[15:37] <rbasak> We don't want the code under test to catch MockError.
[15:39] <teward> i'd love to see the code in question, but if you don't want it to catch as a RuntimeError then you may wish to declare MockError as inheriting a different error class (possibly just a bare Exception class)
[15:39] <teward> because you *are* actually correct now that I have context for understanding the issue at hand
[15:40] <teward> you *can* capture MockErrors as separate handling, but it's just 'more code' on the except.
[15:41] <teward> rbasak: (i assume that MockError's declaration inherits RuntimeError then?)
[15:41] <rbasak> teward: here it is: https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/343566
[15:42] <teward> rbasak: +1 for your comment 20 hours ago, it should have Exception or BaseException as its superclass
[15:42] <teward> nacc: ^
[15:42] <teward> rbasak: thanks for sharing so I can have context
[15:43] <rbasak> teward: np. Feel free to help us review any other git-ubuntu MPs :)
[15:43] <teward> i'll need the proverbial 'flamethrower' to burn things, but I'll also need to review the base codebase to catch up :)
[15:43] <teward> (also, unrelated: yay for Python!)
[15:47] <teward> rbasak: commented to +1 your suggestion and to confirm that the way MockError's been declared will cause issues for the reasons mentioned :)
[15:47] <teward> *starts reading the code to better grasp the evils of the code*
[15:49] <teward> (I do a lot of Python dev... I should devote my knowledge to these reviews heh)
[15:52] <teward> rbasak: the other more 'evil' way is to have a separate `except MockError:` before the RuntimeError catch... and just simply `pass` in that.  It's a nasty hackish fix but that'd be the 'other way' to do this
[15:54] <teward> rbasak: i think i'm missing bits, where's MockError get raised?
[15:55] <teward> or rather, defined.  (I can't type today)
[15:57] <rbasak> teward: we intend to define it in the test. But as that came from a review comment, I suspect it's not anywhere written yet.
[15:58] <teward> indeed.  two ways to do it, ultimately, but I think it'd be better to have its superclass as Exception rather than RuntimeError for the reasons you specified, and because if MockError is not in and of itself a RuntimeError for capture purposes it should not have RuntimeError as its superclass.
[15:58] <nacc> rbasak: oh of course, right
[15:59] <nacc> teward: thanks
[15:59] <teward> rbasak: since MockError doesn't exist in the codebase, though, then which superclass is used for MockError is a discussion for whatever MP suggests adding it.  (Just my two cents)
[16:00] <nacc> right, it's about to be in that MP based upon the current feedback
[16:00] <nacc> teward: so if you just tell me now, i'll do it :)
[16:01] <teward> nacc: I'd make MockError's superclass either Exception or BaseException, not RuntimeError, if you intend MockError to be handled separately from generic RuntimeErrors
[16:01] <teward> as rbasak suggested in the comments on the MP :)
[16:02] <nacc> right, but which of those?
[16:02] <teward> ... speaking of bad error class captures, I just made a folly on a program I have here at work heh.  *goes to fix*
[16:02] <nacc> teward: or how does one decide
[16:02] <teward> remind me: py2 or py3 codebase here?
[16:03] <teward> (I'm assumign Py3)
[16:04] <nacc> py3
[16:04] <teward> nacc: all error classes in Python ultimately inherit BaseException, which is the base class for all in=built exceptions, but it's not meant to be inherited for user-defined classes.  Exception is probably what you want to have the superclass of MockError be.
[16:04] <teward> (from https://docs.python.org/3/library/exceptions.html)
[16:04] <nacc> yep, that's wht i thought, just wanted to confirm
[16:04] <nacc> thanks teward !
[16:04] <teward> yep
[16:05] <rbasak> teward: thanks. That's exactly what I was wanting to look up.
[16:06] <teward> rbasak: i refer to this thing *regularly* with all the classes and python libs i have both open-source and closed-source proprietary here at work - i have that page open up pretty much all the time when working in Python :P
[16:06] <teward> you're welcome.
[16:25] <waveform> yup - BaseException has its uses as a base, but they're always the exception (sorry! ;) rather than the rule
[16:26] <waveform> (typically either used when the thing is "not really an error" or if it's something you really don't want to be caught, even by "except Exception:", like SystemExit)
[16:27] <teward> waveform: The Puns!  :P
[16:30] <rbasak> waveform, nacc: in this case, MockError sounds more like a BaseException thing to me.
[16:30] <rbasak> It's not really an error. It's an injected "what if an exception falls all the way through to the test" thing.
[16:31] <teward> rbasak: that's what Exception is for then.
[16:31] <teward> BaseException for all intents and purposes is the same as Exception in that BaseException has a superclass of Exception
[16:32] <waveform> erm, other way around :)
[16:32] <teward> you're right my apologies
[16:32] <teward> regardless, they do much of the same thing
[16:32] <rbasak> Perhaps it should be called MockException
[16:32] <rbasak> Derived from BaseException
[16:32] <rbasak> As it's not that we're even simulating an error.
[16:32] <rbasak> We're simulating something that flies through all exception handlers.
[16:33] <waveform> teward, indeed - but I could see rbasak's case here that really this ought to derive from BaseException as it's meant to test what happens when something falls through everything (as SystemExit is intended to, hence why it derives from BaseException rather than Exception)
[16:33] <waveform> https://docs.python.org/3/library/exceptions.html#exception-hierarchy
[16:33] <teward> *true*
[16:34] <rbasak> I'm sort of surprised that this isn't already a pattern handled by the mock module's documentation
[16:34] <teward> in either case it should inherit from *either* BaseException or Exception rather than RuntimeError (because of false-positive captures/)
[16:34] <teward> nacc: rbasak makes a good point for BaseException.  While I don't use it, Exception basically inherits BaseException, so you could use BaseException if you want.
[16:35] <teward> it's interesting that *warnings* are considered exceptions too heh
[16:35] <teward> but that's a different discussion :P
[16:35] <waveform> yeah - and they can  be raised as such depending on the configuration of the warnings sub-system, but typically they're suppressed
[16:35] <waveform> (but yes, definitely a different discussion!)
[16:36] <teward> waveform: normally I consider "Exception" as the "default superclass" for my custom exceptions, but it would depend on the specific cases in the program whether you inherit BaseException or Exception
[16:36] <teward> and if we're throwing a MockError we *probably* want that to be caught in a generic Exception capture.
[16:37] <teward> in which case you'd have Exception as the superclass
[16:37] <waveform> absolutely - if BaseException is used, one should generally "make the  case for it" (if only to one's self, but still)
[16:37] <teward> rbasak: do we want to treat Mock exceptions as globally-breaking Exceptions?
[16:37] <teward> or do you want them treated as 'Raised but ignored' exceptions
[16:38] <teward> if it's the former, then Exception should be the superclass; if the latter, then BaseException should be the superclass.
[16:38] <teward> ^ TL;DR for the discussion that waveform and I were just having
[16:38] <teward> nacc: ^ as well
[16:39] <rbasak> I'm not really trying to define a general mock exception class. Just one for this particular test case.
[16:39] <rbasak> We want to make sure that a close() method gets called when stuff fails.
[16:39] <teward> ack
[16:39] <rbasak> So we need to simulate a failure and make sure that the failure ripples all the way back up to the test.
[16:40] <nacc> ok, i've derived from Exception and will force push, rbasak --- you can do wht you want with it now :)
[16:40] <nacc> (if you're ok with force push)
[16:40] <rbasak> Force push is ifine
[16:40] <rbasak> Though I've convinced myself that BaseException is right now.
[16:40] <rbasak> But I don't care enough to make you change it or change it myself or anything.
[16:40] <rbasak> It'll be fine either way in practice.
[16:41] <nacc> done
[16:41] <nacc> right
[16:41] <teward> fun fact, they'll be caught either way by the default error interceptors in Python
[16:41] <teward> which explains why Exception is the user-defined-error inheritance suggestion in the docs :P
[16:41] <teward> either way, it won't be caught as a RuntimeError now :0
[16:41] <teward> :) *
[16:42] <nacc> rbasak: i think i covered all your cases
[16:42] <nacc> rbasak: how is your importer run going?
[16:42] <rbasak> It's still stuck. I was working on making the snap build work.
[16:43] <nacc> rbasak: ack
[16:43] <nacc> rbasak: and by stuck, you just mean working on the large packages
[16:43] <rbasak> I have a branch for it now. Just need to clean it up and file the MP. Probably tomorrow.
[16:43] <rbasak> Yeah
[16:43] <nacc> rbasak: does your branch do more than people.c.c/~racb ? (or the team or whatever)
[16:43] <rbasak> My intention: get that MP landed, stick it in edge (or beta), update the snap on the importer host, rerun the importer with a correct max-age argument.
[16:43] <rbasak> That should take up the new blacklist.
[16:44] <nacc> rbasak: yeah that seems reasonable
[16:44] <rbasak> nacc: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+ref/snap-vendoring-updates - will rebase.
[16:44] <rbasak> (for squashing)
[16:45] <nacc> rbasak: and i assume you've made sure the snap builds?
[16:46] <nacc> and passes self-test, i mean
[16:46] <rbasak> nacc: nearly. It failed ont he last iteration. I have a successful build and will check it tomorrow.
[16:48] <nacc> rbasak: ok
[18:45] <dpb1> ahasenack: I'm looking back for the previous ones in ubuntu-release
[18:45] <dpb1> ahasenack: I'm not sure
[18:46] <dpb1> ahasenack: looks like this
[18:46] <dpb1> Starting main-titmouse
[18:46] <dpb1> lmao
[18:46] <dpb1> Builds: Ubuntu Server Subiquity amd64 [Bionic Final] has been updated (20180425.1)
[18:46] <dpb1> ^
[18:47] <dpb1> ahasenack: and, looks like it was the last one of the sequence
[18:47] <ahasenack> that's from yesterday
[18:48] <dpb1> of course, but that is what it will look like when it's done
[18:49] <ahasenack> desktop is here? http://cdimage.ubuntu.com/ubuntu/daily-live/
[18:49] <dpb1> yes
[18:49] <ahasenack> it doesn't have an entry for today yet
[18:50] <ahasenack> -queuebot/#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic Final] has been updated (20180426) was already announced
[18:50] <ahasenack> there may be some lag
[18:50] <ahasenack> ah, showed up
[18:50] <dpb1> ahasenack: it's the launchpad really-really-published state
[18:50] <ahasenack> partially
[18:51] <ahasenack> http://cdimage.ubuntu.com/ubuntu/daily-live/20180426/ just metadata for now
[18:51] <dpb1> you just need to find the green gear somewhere
[19:21] <dpb1> ahasenack: I'm trying out the "alternate" server image
[19:23] <RoyK> the new installer sucks
[19:32] <dpb1> I quite like it.
[19:42] <RoyK> dpb1: did you try to install on raid/lvm/fde?
[19:44] <teward> wait there's a new installer on the server images?  *really*?
[19:45] <sarnold> I think there's three installers -- debian-installer, ubiquity, subiquity
[19:45] <sdeziel> RoyK: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#New_since_17.10-2 says that for those use cases, the old installer is needed
[19:46] <blackflow> sarnold: four if you count debootstrap (which technically is one) :)
[19:46] <sarnold> blackflow: oh right :D
[19:47] <RoyK> sdeziel: I know and that's a major flaw
[19:47] <RoyK> sdeziel: making a new installer just for it to be userfriendly or so, for a server installation, doesn't make sense
[19:49] <RoyK> sdeziel: the whole point of having different distro versions for desktop and server should be focus on what's needed - a "userfriendly" installer for server that doesn't allow you to do what's been there the last 10+ years, isn't friendly
[19:49] <sdeziel> RoyK: yeah, in our case, that means we won't use subiquity until it reaches feature parity with the alternate installer
[19:49] <dpb1> RoyK: well, if you want a serious discussion...
[19:50] <dpb1> RoyK: the underpinnings do support these things, and it's next up on the list to impliment, I suggest you check back at 18.10 on it.
[19:50] <sarnold> I think I even heard rumours it's intended to be supported by 18.04.1.
[19:51] <RoyK> sdeziel: do they really allow new "features" in an LTS? it's frozen
[19:51] <dpb1> it's built on curtin (the backend of maas), which supports all these things already, so it's *just* ui.  (joking on the *just*)
[19:51] <sdeziel> RoyK: I was hoping for 20.04 :)
[19:52] <RoyK> let's say 24.04
[19:52] <ahasenack> RoyK: what exactly is your point, if you still have the raid/lvm/fde options available in the other installer?
[19:52] <ahasenack> or just a critiscism about the new installer (which is fine)
[19:53] <ahasenack> (misspelled that probably)
[19:53] <RoyK> ahasenack: the problem is that a server installer that is so dumb you feel like installing windows 95 shouldn't be used on a server distro
[19:54] <ahasenack> RoyK: which one is that, the new or old one?
[19:54] <RoyK> the old one's fine
[19:54] <RoyK> the new one is shiny and "userfriendly", but doesn't give you much to choose from
[19:55] <ahasenack> that wasn't really the goal of the new one, not the main one at least
[19:55] <ahasenack> it's an attempt at unification
[19:55] <ahasenack> it uses the same installer that maas (maas.io) uses, and maas knows how to tweak almost all of its knobs already
[19:55] <RoyK> that doesn't matter when it can't work like the old one
[19:55] <ahasenack> it's getting there
[19:56] <RoyK> "getting there" for an LTS release?
[19:56] <ahasenack> maas can already drive it to create partitions, raids, btrfs, bcache
[19:56] <ahasenack> bonding
[19:56] <sarnold> ahasenack: zfs root? :D
[19:56] <ahasenack> no, it didn't reach feature parity for the lts
[19:56] <ahasenack> that's why the old installer is still there
[19:56] <ahasenack> sarnold: maybe, I hear things :)
[19:57] <RoyK> then perhaps the old installer should be the default for now?
[19:57] <ahasenack> so, the point it that the tech, the actual installer under the hood, can already do all that
[19:57] <ahasenack> the "frontend", if you will, not yet
[19:57] <ahasenack> RoyK: that's a matter of choice indeed, it could have been that way (new one be alternate, old one be default)
[19:57] <ahasenack> but the choice was made
[19:57] <sdeziel> supporting multiple installers is suboptimal, is this a temporary situation until subiquity gains feature parity?
[19:58] <RoyK> defaulting on an installer that can't do the old installer's job is quite far from optimal
[19:58] <RoyK> it's just crap
[19:59] <ahasenack> I can just describe how things are, sorry
[20:00] <nacc> sdeziel: yeah, i think so (long-term)
[20:00] <sdeziel> nacc: good cause more choices adds dimensions to the testing matrix :)
[20:00] <nacc> sdeziel: right
[20:01] <nacc> sdeziel: i say that unofficially though :)
[20:01] <axisys> having trouble with apt-get .. need some help
[20:01] <axisys> http://dpaste.com/2FNKS5B.txt
[20:02] <nacc> axisys: those don't appear to be ubuntu packages?
[20:02] <sdeziel> axisys: looks like you have held packages and you also seem to use a mix of packages for precise and trusty
[20:03] <nacc> axisys: as in those versions are not ubuntu package versions
[20:03] <axisys> lsb_release -a says Ubuntu 14.04.5 LTS
[20:04] <axisys> no not sure how precise is in there..
[20:04] <nacc> axisys: that doesn't tell us what repos you are using
[20:04] <nacc> apt-cache policy libpython2.7-stdlib
[20:05] <axisys> that was a PPA .. since I could get the latest python and it was failing
[20:05] <nacc> axisys: right ppa is not supported here
[20:05] <nacc> (or by ubuntu generally)
[20:05] <nacc> contact the ppa owner, axisys
[20:05] <axisys> I can remove it and then show the error again.. it was erroring out and PPA was added few mins ago.. let me remove that
[20:06] <axisys> nacc: wait.. I am not trying to get support for the PPA .. removing it .. give me 5 sec
[20:07] <dpb1> well, glad to see that we had a serious discussion
[20:07] <axisys> http://dpaste.com/2EM32AC.txt
[20:07] <sdeziel> using a PPA is like peeling the "warranty void sticker" :)
[20:07] <axisys> ok.. PPA is out
[20:08] <axisys> so I suppose run ``apt-get -f install'' ?
[20:08] <nacc> axisys: you needed to use ppa-purge
[20:09] <axisys> nacc: that won't work .. until apt-get is fixed
[20:09] <nacc> or use dpkg
[20:10] <axisys> I do not have the ppa-purge deb
[20:11] <sarnold> try apt-get install libpython2.7-minimal=2.7.6-8ubuntu0.4 libpython2.7-stdlib=2.7.6-8ubuntu0.4
[20:11] <dpb1> Also, just to clear up language.  there is no default.  both installers are offered and supported for 18.04.  I had that misunderstanding a while back and it helped me to clear it up.
[20:12] <axisys> sarnold: that installed
[20:13] <sarnold> axisys: alright see if apt is happier now
[20:13] <axisys> sarnold: yep.. pretty happy now
[20:13] <axisys> I got here when I was trying to install latest ansible with python
[20:13] <nacc> axisys: 'latest' from ubuntu?
[20:14] <axisys> nacc: with pip
[20:14] <nacc> axisys: ok, so that fails or something?
[20:14] <axisys> let me paste it
[20:14] <axisys> yes
[20:15] <axisys> http://dpaste.com/20N5HYR
[20:16] <nacc> axisys: that's not the ubuntu python
[20:16] <nacc> err not ubuntu pip
[20:16] <nacc>  /usr/local/...
[20:16] <axisys> /usr/lib/python2.7/dist-packages/pkg_resources.py
[20:16] <axisys> 3rd line
[20:18] <nacc> axisys: the bug is in your local pip
[20:18] <nacc> axisys: the backtrace, i mean
[20:18] <axisys> installing python-pip pkg
[20:20] <axisys> installed python-pip and next error http://dpaste.com/2KMZY13
[20:20] <nacc> axisys: you might also need python-contextlib?
[20:23] <axisys> python-contextlib2 is already the newest version.
[20:23] <nacc> axisys: this is trusty
[20:23] <nacc> ?
[20:23] <axisys> yes
[20:31] <nacc> axisys: trying to reproduce, sorry
[20:32] <nacc> axisys: contextlib imports fine by default in trusty
[20:32] <axisys> http://dpaste.com/3R05TZ1.txt
[20:33] <nacc> axisys: what is that?
[20:33] <axisys> OK. I am trying to install python-pip again
[20:33] <nacc> axisys: your python installation appears to be a bit fubar
[20:34] <nacc> axisys: you can try and resolve it for apt manually
[20:36] <axisys> ok back to pip
[20:36] <axisys> ImportError: No module named contextlib
[20:37] <nacc> axisys: same backtrace?
[20:40] <axisys> http://dpaste.com/29WA6JJ.txt
[20:40] <nacc> axisys: can you run `python -c import contextlib` ?
[20:42] <axisys> http://dpaste.com/2SA051G
[20:42] <axisys> syntax error
[20:42] <axisys> # python -m contextlib
[20:42] <axisys> /usr/bin/python: No module named contextlib
[20:42] <sarnold> add quotes around the "import contextlib"
[20:42] <axisys> python -c "import contextlib" gives same result
[20:43] <nacc> it works fine by default in trusty
[20:43] <nacc> axisys: fyi
[20:43] <axisys> # python --version
[20:43] <axisys> Python 2.7.6
[20:43] <axisys> I think this server is sick.. :-)
[20:44] <nacc> that's the correct trusty version
[20:45] <nacc> i'm testing in a lxd
[20:46] <axisys> when everything will be container all these will be just moot point..
[20:49] <nacc> axisys: `dpkg -S contextlib` ?
[20:52] <nacc> it should be from libpython2.7-stdlib
[21:11] <axisys> http://dpaste.com/2XBMM11.txt
[21:12] <nacc> axisys: apt-cache policy libpython2.7-stdlib
[21:12] <axisys> 2.7.6-8ubuntu0.4
[21:13] <axisys> http://dpaste.com/191G44R.txt
[21:14] <nacc> axisys: it seems misinstalled, as there should be a /usr/lib/python2.7/contextlib.py
[21:14] <nacc> i would try reinstalling it, if that file does not exist
[21:15] <axisys> libpython2.7-stdlib is already the newest version.
[21:17] <nacc> right, but it's not correclty installed
[21:17] <nacc> afaict
[21:17] <nacc> do you have the above file?
[21:17] <axisys> ok reinstalled
[21:17] <axisys> -rw-r--r-- 1 root root 4424 Nov 23 16:53 /usr/lib/python2.7/contextlib.py
[21:18] <nacc> try your commandn ow
[21:18] <axisys> pip install --upgrade pip worked this time.. no idea what convoluted path I took
[21:21] <nacc> axisys: your ppa i think busted things ... and then it didn't fix properly
[21:58] <dpb1> sforshee: thanks for the testing reports
[23:31] <teward> ... now if only the download server would actually speed up, maybe I could test-run this in VMware, on my KVM VPSes, etc.  :P
[23:31] <teward> (it'll run in VMware, no idea if it'll sanely run on KVM'd VPSes heheh)
[23:36] <dpb1> https://www.ubuntu.com/download/server
[23:36] <dpb1> 18.04 ^
[23:37] <teward> dpb1: i know.  it's downloading now.  But running at an abysmally slow rate.
[23:37] <dpb1> teward: torrent
[23:37] <teward> ... and I have a gig uplink so...
[23:37] <teward> dpb1: DHT activity == blacklist on my hyper-secure network :p
[23:37] <dpb1> teward: VPN
[23:37] <dpb1> :)
[23:38] <teward> my fault, but otherwise would be a "good to go" option.  That said, as soon as my local ISO mirror finishes its zsync I *should* be good to go :)
[23:38] <teward> (it's where I keep the Ubuntu ISOs, and its currently downloading Lubuntu, MATE, and Server ISOs)
[23:40] <teward> dpb1: waiting for my local mirror to finish its zsyncs should be satisfactory.  (NOte that Server, MATE, and Lubuntu are the priority order currently...)(
[23:40] <sarnold> I forgot to poke a hole through my nat for torrent.. I just went from ~14 peers to ~35 peers
[23:41] <sarnold> I think it's still going at about 2% of my actual bandwidth though. I had hoped fixing that would open the floodgates...
[23:43] <teward> sarnold: NAT is evil that way, isn't it :P
[23:43] <sarnold> yeah :/
[23:43] <teward> sarnold: except when it's supposed to be closed and locked down, *then* it's not evil, it's doing its job.
[23:43] <teward> :P
[23:44] <sarnold> teward: I have to admi a certain amount of "security blanket" feeling to NAT, indeed :)
[23:44] <dpb1> teward: but, just for anyone else.  really, the torrents came down in like seconds. :)
[23:44]  * dpb1 is continuing to seed
[23:46] <teward> dpb1: indeed.  'Course, the Server ISO just finished its ZSync so :)
[23:46] <dpb1> nice
[23:58] <teward> um, this may be a problem
[23:59] <teward> nevermind, it's my typing that failed.
[23:59] <sarnold> :)