=== keithzg__ is now known as keithzg_
[00:01]  * keithzg[m] has decided for the time being to use the workaround of enabling the livepatch service, although of course that won't help when there's things like the systemd vulnerability whose update came down today
[00:15] <wylel> keithzg[m]what happens when you bring the server back up?
[00:15] <wylel> works as intended?
[00:16] <keithzg[m]> wylel: Yup. I have to hold down the power button for a bit to force it off, but then it comes back up and reports as if it cleanly power cycled.
[00:17] <wylel> what output do you get when the reboot command happens, or just a black screen?
[00:18] <keithzg[m]> wylel: Just a black screen. A completely unlit screen, in fact; the monitor is not being told there's any signal.
[00:18] <keithzg[m]> That is to say, there's the standard stuff flashing by going for a reboot, but then an endless blankness.
[00:19] <wylel> is the server physically on at this time?
[00:19] <wylel> like after the monitor is getting no signal
[00:20] <keithzg[m]> wylel: Yes, in the sense that the power light is indicating its on, as are I believe the ethernet LEDs, and the fans are still running.
[01:25] <wylel> keithzg[m] that is strange, sounds like something is failing to tell it to start again, but there are no logs after the discs unmount
[01:26] <keithzg[m]> wylel: Yeah, 'tis why I only half-jokingly blame UEFI's eldritch horrors for this
[01:27] <wylel> I mean, its not out of the realm of possibility.
[01:27] <wylel> but then again, I feel it would also happen when booting
[01:28] <wylel> from an off state
[01:36] <keithzg[m]> One might think, which is why I'm not just solely blaming UEFI. But it could be as simple as there being some sort of bug in the ACPI (or whatever, but I assume this stuff still uses ACPI?) call the Ubuntu install is making to tell the motherboard firmware to reboot rather than poweroff.
[01:40] <keithzg[m]> Motherboard firmware is weird, oft-broken stuff. I'm sure it's at least partially due to the motherboard firmware, heh.
[03:57] <kolaman> hi all
[03:57] <kolaman> can we automate apt full-upgrade -y  ?
[03:57] <kolaman> we haev some ubuntu 16.x and some ubuntu 18.x
[03:58] <benharri> apt full-upgrade does not upgrade releases
[03:59] <kolaman> benharri: yes, I'm just upgrading packages not release . .
[03:59] <benharri> apt update && apt full-upgrade -y
[04:00] <kolaman> apt full-upgrade -y asks for yes/not/keep old etc questions. Can i bypass those ?
[04:00] <kolaman> benharri:
[04:00] <benharri> tha'ts what -y does
[04:01] <kolaman> benharri: unfortunately that is not true, I used apt full-upgrade -y
[04:01] <kolaman> and was asked qustions like where to install bootloader select drive or select both on safe side and a couple of other etc.
[04:02] <benharri> search for -y in man apt-get
[04:03] <kolaman> benharri: apt or apt-get ?
[04:03] <benharri> if you look at the manpage for apt, it directs you to apt-get
[04:03] <benharri> in the upgrade and full-upgrade sections
[04:03] <kolaman> great, but -y works fine in centos yum update -y but not here
[04:04] <benharri> not sure what you mean by fine
[04:05] <kolaman> by fine mean in centos /yum this -y switch works as desired (doesn't ask any question etc.) but for apt it asks for questions and doesn't bypass those
[04:08] <benharri> oh are you talking about the prompts that some packages show when there are conflicts?
[04:08] <kolaman> benharri: yes, I want to bypass those ..
[04:08] <benharri> i've never looked into that
[04:09] <kolaman> like select the best avaiable option (default one)
[04:09] <kolaman> have been searching throughout the day and not able to find anything better
[04:10] <benharri> after a quick google, i found this: https://stackoverflow.com/a/23048987
[04:11] <benharri> export DEBIAN_FRONTEND=noninteractive && sudo apt-get -q -y full-upgrade
=== lotuspsychje__ is now known as lotuspsychje
=== lotuspsychje__ is now known as lotuspsychje
=== AC3J_ is now known as AC3J
[11:17] <cpaelzer> rbasak: FYI I have heard but not known about the bug patterns
[11:17] <cpaelzer> rbasak: I'm trying to read about it let me know if you have a great link somewhere
[11:21] <cpaelzer> I think finding https://code.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns was the important step, I'm good now
[11:22] <rbasak> cpaelzer: there's a wiki page too
[11:22] <rbasak> cpaelzer: https://wiki.ubuntu.com/Apport/DeveloperHowTo#Bug_patterns
[11:23] <rbasak> cpaelzer: I wondered if an apport hook or a bug pattern would be better to solve this particular problem
[11:23] <cpaelzer> it is worth to read myself into it for a few minuntes to have an opinion about that decision
[11:24] <rbasak> cpaelzer: for example I think bug 1512344 is pointed to by a bug pattern rather than an apport hook
[11:24] <ubottu> bug 1512344 in nginx (Ubuntu) "[Master Bug] Package nginx-* failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (due to "Address in Use" issue)" [Undecided,Invalid] https://launchpad.net/bugs/1512344
[11:24] <rbasak> cpaelzer: sure :)
=== jdstrand_ is now known as jdstrand
[12:57] <ahasenack> rbasak: question about d/rules and dh,
[12:57] <ahasenack> rbasak: https://pastebin.ubuntu.com/p/x5KhhwryVj/
[12:58] <ahasenack> rbasak: the second dh statement in the %: target was not being run
[12:58] <ahasenack> I saw that the apt-hook binary was actually being built in the install target, as that had an override and called dh_auto_install twice: once for pybuild, once for makefile
[12:59] <ahasenack> the %: target is special in that regard I assume? Multiple dh invocations just don't work?
[12:59] <ahasenack> I "fixed" it with the pastebinned patch. Now the apt-hook is built at build time
[13:00] <ahasenack> is there another way to do this in "%:"? Or just by, for example, using just makefile, and have the makefile build the python module properly?
[13:03] <rbasak> ahasenack: I think running twice would fail horribly even if it did work, because you'll end up with the various debhelper commands running twice and not in the right order
[13:03] <ahasenack> true
[13:03] <rbasak> I'm not sure if there's a way to tell debhelper to use two different build systems
[13:04] <rbasak> So perhaps your override_dh_auto_build is the best way to do it.
[13:04] <rbasak> I don't see any problem with it in any case
[13:06] <ahasenack> right
[13:06] <ahasenack> thanks
[13:06] <ahasenack> and I just saw that this attempt at two build systems is messing up the clean target
[13:06] <ahasenack> the tarball has an empty __pycache__ dir in it
[13:06] <ahasenack> because of this
[13:07] <rbasak> Do you also need to override with override_dh_auto_clean?
[13:07] <rbasak> Though I normally wouldn't notice as I always use a clean build (eg. using sbuild)
[13:08] <ahasenack> yeah, I'm overriding dh_auto_clean now
[13:08] <ahasenack> it was calling setup.py clean, because dh was told pybuild is the buildsystem
[13:09] <ahasenack> but there is more cruft that needs to be cleaned
[13:09] <ahasenack> let's see if this works
[13:09] <ahasenack> funny that pybuild wasn't cleaning __pycache__: https://pastebin.ubuntu.com/p/6HJ9GZckNj/
[13:10] <ahasenack> that tarball it build in line 24 contains an empty __pycache__ dir
[13:11] <ahasenack> it's a native package, so it would just pack everything it found :(
[13:28] <DammitJim> I know 14 is eol this month
[13:28] <DammitJim> but is there a particular day? the 20? 28?
[13:29] <DammitJim> 30?
[13:44] <TJ-> There was an email notification recently about it
[13:45] <DammitJim> hhhmmmm
[13:45] <lotuspsychje> DammitJim: just dont wait till the end to upgrade, take measures
[13:45] <TJ-> ESM starts April 25th
[13:45] <TJ-> so presumably April 24th?
[13:46] <DammitJim> thanks
[13:46] <DammitJim> yeah, I've been working on it, but I have servers that depend on developers to update their stuff and I know they are going to ask me the specific date... I just need to upgrade 6 more servers out of about 200
[13:47] <TJ-> tell them April 15th!
[13:47] <TJ-> give yourself some breathing space :D
[13:47] <DammitJim> my date is actually the 10th
[13:47] <DammitJim> it's been the 10th since last year, but I even got confused one day thinking that was the actual EOS date :D
[13:48] <TJ-> I bet that gave you hot and cold sweats :)
[13:49] <DammitJim> I already have the hot/cold sweats because there are 6 servers we won't be upgrading. can't wait for the day when I turn those off
=== BrianBlaze420 is now known as brianblaze
=== cryptodan_d is now known as cryptodan
[16:53] <JamesBenson> Does anyone use 10G card: "NetXtreme II BCM57711 10-Gigabit PCIe"?
[16:54] <JamesBenson> ^ ...from Broadcom...
[17:05] <genii> JamesBenson: Perhaps a description of what issue regarding this adapter you are trying to resolve might be more useful for someone to assist
[17:06] <JamesBenson> genii: Sure, sorry, I'm trying to use these 10G cards as our backbone for some older servers, dell 11'th generation.  It seems I can SSH over them, copy files, etc. But ansible for example, doesn't seem to work over them.
[17:07] <JamesBenson> our end goal is to deploy openstack over them, previously using 1g connection.  No issues.  upgrade to 10g network issues.
[17:11] <codefriar> I've a dell r710 with 4x NetXtreme II BCM5709 Gigabit Ethernet (rev 20) - but the 18.04 lts installer can not seem to pull a dhcp address. 18.10, however CAN
[17:12] <JamesBenson> yeah, we have a bunch of the 710's using 16.04
[17:12] <JamesBenson> good to know about 18.04...
[17:29] <tomreyn> codefriar: which installers did you test?
[17:29] <codefriar> tomreyn the standard ubuntu-server installer you can download from ubuntu
[17:29] <tomreyn> 18.04.0?
[17:30] <tomreyn> .2 is out
[17:31] <sarnold> there's also two installers, the newer one and the debian-install one. there may or may not be differences in networking bringup
[17:32] <tomreyn> also, a bug report would be great to have if there's none, yet
[17:33] <tomreyn> codefriar: ^
[17:38] <codefriar> sarnold using the new one, i believe.
[18:56] <ahasenack> codefriar: 18.04.2 is probably using a newer kernel, that might help with your nic issues
[18:56] <ahasenack> the installer environment, I mean
[19:04] <shubjero> Hey there. I'm looking to do some Ubuntu 16.04 to 18.04 do-release-upgrade and I use a 3rd party repo for Ceph packages. I noticed that the do-release-upgrade wants to remove the ceph packages during the upgrade. Any way I can tell it not to do this? Ideally it should just choose the 18.04 ceph packages from the ceph repo.
[19:05] <sarnold> shubjero: does it appear to remove that repo entirely? or does it just not use those packages because version numbers are lower?
[19:06] <shubjero> Well. Ubuntu 18.04 is also packaging the same ceph version as the official ceph repo.
[19:06] <shubjero> For example, on 18.04 you can get Ceph 13.2.5 from the ubuntu repo OR the ceph repo.
[19:07] <shubjero> Our starting point is Ubuntu 16.04 with Ceph 13.2.5 from the ceph repo.
=== msmarcal is now known as msmarcal|eod