[00:09] <arooni> is there an ubuntu terminal that supports the OSC 52 ;; would allow set-clipborad in terminal
[00:21] <sarnold> probably xterm does; maybe urxvt ..
[00:27] <nacc> rbasak: not sure if you want to just land that fixlet, or try and build it locally to sanity check it is ok? I suppose in the edge channel it's ok to just land it
[00:28] <nacc> ahasenack: as to the error messages, remember when running from the snap it is only looking in the snap's env, so your system packages are irrelevant
[00:28] <nacc> ahasenack: it's just a generic message, which implies that it wasn't able to load pygit2 successfully
[00:28] <nacc> s/load/import/
[01:00] <xamithan> Just joined to grab topic links and say cheers it fixed my issue~
[06:01] <lordievader> Good morning
[09:12] <^kiokoman^> wellcome2
[09:12] <^kiokoman^> wrong chat sorry
[10:10] <rbasak> cpaelzer, ahasenack: git-ubuntu edge fixed I believe
[10:10] <cpaelzer> rbasak: rev 429 or newer?
[10:12] <cpaelzer> rbasak: yep working on 429 now
[10:12] <cpaelzer> thank
[10:12] <cpaelzer> s
[11:39] <DK2> hello, im trying to setup a hostroute on ubuntu 18.04
[11:39] <DK2> http://pastebin.centos.org/782911/
[11:40] <DK2> is the relevant snippet, however when trying to access the 10th subnet im getting no route to host
[11:40] <DK2> it works perfectly fine when i set a 192.168.0.0/24 ip on the server, however i need the ip to be 192.168.2.0/24
[11:40] <DK2> any ideas?
[11:42] <Ool> DK2: you need to have a gateway in the network
[11:42] <DK2> it is on-link
[11:42] <DK2> both subnet are in the same vlan
[11:43] <Ool> same vlan perhaps but not in the same network
[11:43] <DK2> but shouldnt hostroutes work for exactly cases like this?
[11:43] <Ool> how can you can to the 192.168.0.0/24 where is your gateway from 192.168.2.0/24 ?
[11:43] <Ool> how can you go *
[11:44] <DK2> there is no gateway, it should use 192.168.0.254
[11:48] <Ool> for me, or the dest is on the same network => no gateway, or is another network => gateway
[11:52] <DK2> https://netplan.io/examples#directly-connected-gateway
[12:05] <DK2> but doesnt seem to work
[12:17] <frickler> thedac: coreycb: any update on https://bugs.launchpad.net/bugs/1750121 ? my suspicion is that this is somehow dependent on your CI/charms setup
[13:12] <DK2> so, http://pastebin.centos.org/782951/
[13:12] <DK2> how can i add a second route here?
[13:12] <DK2> i also want 10.82.27.0/24 to go trough .254
[13:59] <sveinse> How strong is the recommendation to keep ubuntu-server on a server? I'd like to remove some of the packages this packages depends on a smaller server.
[14:07] <ahasenack> rbasak: I thought there was a way to pass extra arguments when using git-ubuntu build-source, like genchange's -v<version>, but I don't see that in the --help output. Is there a way?
[14:10] <ahasenack> ah, I think it's anything at the end that is not recognized as a git-ubuntu flag?
[14:10] <ahasenack>     if len(args.rem_args) != 0:
[14:10] <ahasenack>         logging.warning(
[14:10] <ahasenack>             "Appending specified flags (%s) to `dpkg-buildpackage %s`. "
[14:11]  * ahasenack tries that
[14:37] <runelind_q> I'm running 16.04.4.  Whenever I reboot after a kernel upgrade, I run apt autoremove, then it makes me reboot again :|
[14:37] <runelind_q> any way to get around that?
[14:45] <genii> Run the autoremove after the kernel upgrade but before rebooting the first time
[15:18] <runelind_q> good point
[15:50] <RoyK> runelind_q: seems like an apt bug if you ask me
[15:50] <runelind_q> I agree, it shouldn't need to happen.
[15:50] <runelind_q> there were bugs filed about it in 2015
[15:52] <RoyK> runelind_q: well, ubuntu doesn't really have a medal in bug fixing
[15:53] <runelind_q> why fix bugs when you can add more features? ;p
[16:09] <RoyK> runelind_q: exactly
[16:09] <RoyK> runelind_q: I don't use ubuntu much on servers anymore - I went back to debian
[16:10]  * RoyK knows he's swearing in church
[16:14] <nacc> ahasenack: -- ...
[16:14] <nacc> ahasenack: (cf. `git ubuntu build --help`)
[16:15] <runelind_q> I do feel like there are much more kernel security updates in Ubuntu compared to CentOS/RH, maybe they're just not fixing them ;p
[16:16] <nacc> ahasenack: i'm not sure if i've tested buildsource -- , tbh
[16:16] <nacc> ahasenack: but i think it does work, and needs a MP to add that to the help epilogue
[16:17] <RoyK> nacc: -- ... means "MS" ;)
[16:18] <nacc> RoyK: I don't know what you're talking about.
[16:18] <nacc> RoyK: you mean morse code?
[16:19] <RoyK> :)
[16:38] <nacc> rbasak: ok, looks like git-ubuntu.self-test now passes in edge?
[16:38] <nacc> ahasenack: --^ fyi
[16:52] <ahasenack> nacc: it worked (-- ...)
[16:57] <thedac> frickler: We still see that problem. By chance are you at the OpenStack Summit? I'd love to show you what we are seeing.
[16:58] <thedac> We are not doning anything special in our CI setup. And again the intial peering setup works. It is only after restarting the neutron-bgp-dragent that we see the error.
[17:00] <nacc> ahasenack: cool
[17:11] <frickler> thedac: yes, that's because the original bug also doesn't appear in the default initial setup. I only discovered it when setting up a second network node with another dr-agent
[17:11] <frickler> thedac: and no, I'm not at the summit
[17:12] <thedac> frickler: what info can I provide to move forward? I can tar up neutron.conf etc
[17:15] <frickler> thedac: a description how to reproduce would be good. or would there be a way to hold a failed CI node and let me debug it? like we could do on openstack CI? ;)
[17:17] <thedac> frickler: oK, I'll do a completely manual setup based on the testing documentation (what our CI automation is built on) and see there is any difference.
[17:17] <thedac> The CI env is inaccessible, unfortunately.
[17:18] <frickler> thedac: is the testing doc public?
[17:19] <thedac> frickler: yes, https://docs.openstack.org/neutron-dynamic-routing/latest/contributor/testing.html
[17:20] <thedac> Our CI scripting is almost exactly that ^^^
[17:20] <thedac> Only point to highlight is the neutron-bgp-dragent is on its own node.
[17:23] <frickler> thedac: ah, that's one of the things I asked on LP. you need to install the same pkg version of the bgp agent on the neutron server, because it serves the RPC call from there
[17:23] <frickler> my patch changes both sides and if they are not in sync, you get that error
[17:24] <thedac> frickler: they both have the same version of python-neutron-dynamic-routing
[17:29] <nacc> ahasenack: cool, can you file a bug that build-source's help doesn't mention it, and fix it? :)
[17:45] <frickler> thedac: hmm, o.k., so I guess it's best if you try to reproduce it manually. for me, the only attempt where I saw your error was when I upgraded from current pkgs to proposed and didn't restart neutron-server. maybe you could try that restart anyway, just to confirm that you don't have the same situation
[17:46] <thedac> frickler: ok, I'll do a few more tests and report back on the bug
[17:51] <Nik736> Hi guys, I am struggling with converting my network config to netplan, anyone around that could assist? Would appreciate it, thanks :) Old Config: https://pastebin.com/YjMRhhAa New Netplan Config that does not work: https://pastebin.com/2msq7hYV
[17:54] <ahasenack> rbasak: would you be interested in this mysql 18.04 bug https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1772337 that has apparmor DENIED messages in dmesg? (https://launchpadlibrarian.net/371151468/Dmesg.txt)
[18:16] <sarnold> name="/etc/my.cnf"
[18:16] <sarnold> first, that's a silly path mysql, and you should feel bad for using it.. second, that has the look of something that ought ot have been included in profiles ages ago..
[18:17] <teward> wait, that path looks wrong...
[18:17] <teward> shouldn't it be pulling from the mysql conf roots?
[18:17] <teward> (mysql i mean)
[18:18] <teward> ahasenack: rbasak: ^
[18:18] <ahasenack> apyes, it looks wrong, I commented as such in the bug
[18:18] <sarnold> that last line is a bit funny too, mysqld running with fsuid 1001??
[18:18] <ahasenack> it looks like a heavily modified install, even the initscript was changed
[18:19] <teward> sounds less like a package bug and more of a "PEBKAC User Error" bug
[18:19] <sarnold> wow
[18:21] <teward> is "This system is so heavily modified from the defaults it's not supportable by us" a viable response?  (Just saying)
[18:22] <teward> either of you know if it's possible to get details out of an autopkgtest run?
[18:22] <teward> beyond the logs that it gives normally
[18:22] <ahasenack> teward: a local run?
[18:23] <teward> ahasenack: no, autopkgtest.u.c
[18:23] <teward> but if i have to do a local run of this package I will be displeased
[18:23] <ahasenack> teward: there are artifacts you can download, but that's it
[18:23] <teward> searx breaks with the nginx upload, but the error is uwsgi-level
[18:23] <teward> ahasenack: where?
[18:24] <teward> found it nevermind
[18:24] <teward> grrr yeah the artifacts won't help me here...
[18:25] <teward> ahasenack: if I were to do a local run of this, I have two questions:
[18:25] <teward> (1) how would i do that, and
[18:25] <teward> (2) is there a way to get into the environment if it fails to actually get debugging info?
[18:25] <ahasenack> teward: http://autopkgtest.ubuntu.com/ and go find your package there
[18:25] <swein> on a 18.04 server install. When the ISO is booting some services take forever to start and hangs. Snap server, kernel message of scsi_eh blocked for 120 seconds
[18:25] <swein> anyone seen that
[18:25] <ahasenack> (it's not loading here, btw)
[18:25] <ahasenack> swein: the first time you boot it? And it's the "live server" install?
[18:25] <swein> ahasenack: yes liv eserver install and on first ISO boot
[18:25] <ahasenack> I haven't seen that, sorry
[18:25] <ahasenack> but scsi_eh blocked could be a hardware problem, everything ok with your disks?
[18:25] <teward> yay net lag >.<
[18:25] <ahasenack> teward: (2) not that I know of
[18:26] <ahasenack> teward: (1) is doable, is that in cosmic?
[18:26] <swein> nothing is connected to the megaraid sas controller, it's just plugged in
[18:26] <teward> ahasenack: yes, though my system here is Xenial
[18:26] <teward> ahasenack: TL;DR I need systemctl status -l output
[18:26] <ahasenack> teward: do you know if the test needs a vm, or if it can run in a container? What does d/t/control say?
[18:26] <teward> ahasenack: E: Unknown, not my package
[18:26] <teward> still digging
[18:26] <teward> ahasenack: if you want to help I'd gladly welcome it
[18:26] <ahasenack> which package is it?
[18:27] <teward> ahasenack: searx, its autopkgtests were triggered by NGINX uploads.
[18:27] <teward> somehow
[18:27] <ahasenack> sure, sounds more exciting than a pile of 10 apache bugs from 200x
[18:27] <teward> ahasenack: the nginx direct autopkgtests all succeed
[18:27] <teward> so it's not an nginx-level issue
[18:27] <teward> digging into the failed tests the error is in the uwsgi package when it tries to load
[18:27] <teward> and because of systemd its error message is suppressed saying "Run systemctl status uwsgi for details"
[18:28] <ahasenack> it's usual, I half lost my mind chasing down triggered tests when I uploaded snmp once
[18:28] <ahasenack> got all the way down to bind9 even
[18:28] <teward> heh
[18:28] <teward> well I value a second set of eyes
[18:28] <teward> actually oddly enough
[18:28] <ahasenack> ok, so isolation-container, looks like a lxd is fine
[18:28] <teward> it looks like the test has always-failed since 2018-05-05
[18:28] <ahasenack> I'll run the tests, but just so you know,
[18:29] <ahasenack> you would first run autopkgtest-build-lxd to prepare a lxd image for autopkgtest to use
[18:29] <ahasenack> and then autopkgtest -s -U /path/to/package (or package name) -- lxd <lxd-image-name>
[18:29] <ahasenack> more or less
[18:29] <ahasenack> going from memory
[18:29] <ahasenack> -s is for it to stop when it fails and give you a shell
[18:30] <ahasenack> -U is to run apt-upgrade, since the image you prepared earlier could have been prepared weeks ago
[18:30] <teward> ahasenack: indeed.  Though Xenial won't work for it.
[18:30] <teward> i'll need to use my bionic box
[18:30] <ahasenack> it should work on xenial
[18:30] <teward> those scripts don't exist in Xenial
[18:30] <ahasenack> it probably has the old name, that's all
[18:30] <ahasenack> adt<tab> I think
[18:30] <teward> there it is
[18:30] <ahasenack> don't ask
[18:30] <ahasenack> I wouldn't know why
[18:30] <teward> not going to :p
[18:31] <teward> heh lol
[18:31] <teward> ahasenack: doesn't work with snapped LXD 3.x
[18:31] <teward> apparently
[18:31] <ahasenack> the build-lxd one?
[18:31] <teward> mhm
[18:31] <teward> at least, not on Xenial
[18:31] <ahasenack> do you have a cosmic image already?
[18:32] <ahasenack> you need to give it the name of an image
[18:32] <teward> ahasenack: ah, well, there's no Cosmic images for me to pull
[18:32] <ahasenack> it will boot it, make modifications, and give you a new one
[18:32] <teward> i already tried
[18:32] <teward> so
[18:32] <ahasenack> lxc image copy ubuntu-daily:cosmic local:
[18:32] <ahasenack> try that
[18:32] <teward> *now* it works
[18:32] <teward> when was taht turned on?
[18:32] <teward> it didn't work last week o.O
[18:32] <ahasenack> yesterday I think
[18:32] <ahasenack> or fri
[18:33] <ahasenack> correct
[18:33] <teward> ah that explains it
[18:33] <teward> *waits for the image to copy down*
[18:34] <teward> (autopkgtests annoy me a little but meh)
[18:38] <teward> hmm i think my system derped, gonna reboot
[18:54] <teward> ahasenack: any idea how long it takes for autopkgtests to build the LXD?  Seems to be taking a while, even though I already copied down the image :/
[18:55] <teward> and as soon as I say that it completed :/
[18:55] <teward> *kicks self*
[18:56] <Blueking> what memory stick tool you use to format for dos boot to do bios upgrade ?
[19:00] <sarnold> last time I needed a dos boot disk I think I found a freedos image somewhere that worked
[19:01] <Blueking> hmm,, what format tool ? :P
[19:02] <sarnold> I just used dd to write the thing to a usb stick
[19:02] <sarnold> if you actually have to *format* something, maybe the mtools package can help
[19:02] <sarnold> I hope we still package it, any way ;)
[19:06] <ahasenack> teward: I reproduced the failure locally: https://pastebin.ubuntu.com/p/BZDCmwgcX4/
[19:06] <teward> ahasenack: it looks like it's a uwsgi failure
[19:06] <teward> not an nginx one
[19:07] <ahasenack> is libapache2-uwsgi involved?
[19:07] <teward> it shouldn't be
[19:07]  * ahasenack checks
[19:07] <teward> ahasenack: can you pull `systemctl -l status uwsgi`?
[19:07] <ahasenack> right, not installed
[19:07] <ahasenack> teward: https://pastebin.ubuntu.com/p/D3fk24tVwJ/
[19:07] <ahasenack> super helpful
[19:08] <teward> ahasenack: no, but that points at the issue not being an NGINX related issue
[19:08] <teward> and probably a package-level issue
[19:08] <teward> what's odd is it only fails on three archs
[19:09] <teward> ahasenack: it's interesting to note, too, that searx's autopkgtest has been failing for a while
[19:09] <teward> this is the first time it's on my radar though, the last time it worked was prior to may 5th
[19:11] <ahasenack> I have no idea how these things work
[19:16] <ahasenack> teward: I get a core dump, actually
[19:16] <ahasenack> ERROR: apport (pid 10684) Tue May 22 16:16:15 2018: apport: report /var/crash/_usr_bin_uwsgi-core.0.crash already exists and unseen, doing nothing to avoid disk usage DoS
[19:18] <teward> interesting.
[19:18] <teward> ahasenack: maybe this needs to be opened as a critical level bug against searx
[19:19] <ahasenack> searx or uwsgi?
[19:19] <teward> since the searx tests have failed for everything since may 5th
[19:19] <teward> ahasenack: searx
[19:19] <teward> unless uwsgi's autopkgtests also fail
[19:20] <teward> though i don't see any
[19:20] <teward> ahasenack: nginx wouldn't have any effect on uwsgi
[19:20] <ahasenack> well, what crashed was uwsgi
[19:20] <ahasenack> I'm checking with debug packages to see if the backtrace shows another library
[19:20] <teward> ack
[19:20] <teward> ahasenack: if we can rule out nginx as the cause, then I can rest easy, but I'll have to ask the release team to force ignore those tests for this run
[19:21] <ahasenack> hm, no debug packages for searx
[19:21] <teward> ahasenack: are there any for uwsgi?
[19:21] <ahasenack> yes, I installed them, but the backtrace is still invisible in the critical area
[19:21] <ahasenack> let me paste
[19:21] <teward> hmm
[19:21] <ahasenack> teward: https://pastebin.ubuntu.com/p/8DYQSxg93t/
[19:23] <teward> ahasenack: it sounds to me then like this is a searx bug
[19:23] <teward> let me check something
[19:23] <teward> i have an example uwsgi somewhere, and a container that i can test with heh
[19:24] <teward> ahasenack: if this simple 'hello world' uwsgi app works, then we can blame the searx package
[19:24] <teward> if it fails as well, then we can blame uwsgi
[19:24] <teward> either way, nginx is not an issue
[19:25] <ahasenack> teward: still, that was never enough of an excuse to not chase dep8 failures :)
[19:26] <ahasenack> it's all part of making ubuntu better :)
[19:26] <teward> indeed
[19:28] <teward> ahasenack: happen to have the old commands for adt to run autopkgtests in LXD?  Or should I get a Bionic environment sooner than later :P
[19:28] <ahasenack> try adt<tab><tab>
[19:28] <ahasenack> I think the arguments did not change
[19:29] <teward> dumps me this: https://paste.ubuntu.com/p/64TkTfWDC8/
[19:29] <teward> so adt isn't an app, but there's adt-sub apps so IDK
[19:32] <ahasenack> I'm almost thinking it's a permission problem
[19:32] <ahasenack> teward: right, so first adt-build-lxd
[19:32] <teward> ahasenack: i did
[19:32] <teward> it completed
[19:32] <ahasenack> I think it's just adt-build-lxd <your-cosmic-image>
[19:32] <ahasenack> then do lxc image list, see if you have an autopkgtest specific image now
[19:33] <teward> adt/ubuntu/cosmic/amd64 is there, yes
[19:33] <ahasenack> cool
[19:33] <ahasenack> now we want adt-run
[19:33] <ahasenack> I use:
[19:34] <ahasenack> -U -s -o ../dep8-output --apt-pocket=proposed source-package-name -- lxd adt/ubuntu/cosmic/amd64
[19:34] <ahasenack> try that
[19:34] <ahasenack> -U: upgrade
[19:34] <ahasenack> -s: stops on fail
[19:34] <ahasenack> -o: output report
[19:34] <ahasenack> --apt-pocket: tell it to use proposed, like ubuntu does
[19:34] <ahasenack> -- lxd: virt type
[19:34] <ahasenack> and the last is the lxd image to use
[19:34] <genii> <cough pastebin cough>
[19:34] <ahasenack> I was typing, not copying and pasting :)
[19:35] <ahasenack> loophole!
[19:35]  * genii eye-rolls
[19:35] <sarnold> haha
[19:37] <teward> ahasenack: worked with adt-run -U -s -u somefilepath --apt-pocket=proposed source-pkg-name --- lxd adt/ubuntu/cosmic/amd64
[19:37] <teward> triple dash o.O
[19:37] <ahasenack> oh, right
[19:37] <ahasenack> why not
[19:38] <ahasenack> "-u somefilepath" seems wrong, -u is for user
[19:38] <teward> typo
[19:38] <teward> -o
[19:38] <ahasenack> unless that changed between adt and what we have now
[19:38] <ahasenack> ok
[19:41] <teward> ahasenack: confirmed it's not an uwsgi segfault, a simple uwsgi app works
[19:41] <teward> so the issue is searx
[19:49] <teward> ahasenack: it looks like this was synced in from Debian directly
[19:49] <teward> what would you suggest for filing the bug against this?
[19:50] <ahasenack> did your test finish?
[19:50] <ahasenack> the adt one
[19:50] <ahasenack> I'm trying to start it manually in a terminal, to see when it segfaults, but am having a hard time with that
[19:50] <teward> actually looks like LXD exploded
[19:50] <teward> hang on
[19:51] <ahasenack> it's not a simple initscript
[19:51] <ahasenack> traced it to this
[19:51] <ahasenack> May 22 16:44:30 autopkgtest uwsgi[6741]: + start-stop-daemon --start --quiet --pidfile /run/uwsgi/app/searx/pid --exec /usr/bin/uwsgi -- --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/searx.ini --daemonize /var/log/uwsgi/app/searx.log
[19:51] <ahasenack> but that incurs in other errors
[19:57] <teward> ahasenack: running local test now, lxd decided to fubar initially
[19:58] <ahasenack> ok
[19:58] <teward> also troubleshooting some major chaos with a VPN tunnel at work so, split-attention
[19:59]  * ahasenack fetches a snack
[20:05] <teward> ahasenack: i think we have to contact the Debian people on that
[20:05] <teward> because why they do taht in the test
[20:06] <teward> instead of install uwsgi, drop it in the app area, and then call the uwsgi command which runs this as a daemon, (not sure if it can?) it is failing on that command
[20:06] <teward> which is unique to the test
[20:09] <teward> let me poke this a bit more
[20:10] <teward> ahhhhh interesting
[20:19] <ahasenack> back
[20:37] <teward> ahasenack: hmm i found something interesting
[20:37] <teward> i need to do some debugging thoguh
[20:38] <teward> ahasenack: i think i found the breakage
[20:38] <ahasenack> sounds good
[20:38] <ahasenack> do tell
[20:38] <teward> possibly.
[20:39] <teward> ahasenack: the problem is I can't find the explicit init.d to call
[20:39] <teward> but when I try and run uwsgi directly things're not being placed in there proper
[20:39] <teward> so it might not be the proper 'test'
[20:40] <teward> is there a way to see the CLI call made to execute uwsgi by systemd or start-stop-daemon?
[20:40] <ahasenack> I tried
[20:40] <ahasenack> closest I got was to insert a "set -x" in /etc/init.d/uwsgi just before the do_* call for start
[20:40] <ahasenack> and then follow in /var/log/syslog
[20:41] <ahasenack> I got to the start-stop-daemon line I pasted above, at 19:51:15 utc
[20:41] <ahasenack> but that line in itself didn't segfault
[20:42] <teward> hmm
[20:43] <teward> ahhh i think i know what's going on...
[20:43] <ahasenack> sounds even better
[20:45] <teward> ahasenack: i manually tried the same command to start uwsgi
[20:45] <teward> and found this in syslog: May 22 20:44:35 adt-virt-lxd-dxnxve systemd[1]: uwsgi.service: Failed to reset devices.list: Operation not permitted
[20:45] <ahasenack> I see that all the time in lxds
[20:45] <teward> and when it tries to start apport crash handler it fails too
[20:45] <teward> ahasenack: the problem is, that's the only 'error' i can see
[20:45] <teward> it doesn't actually start the process
[20:45] <teward> now, when I call the start-stop-daemon line directly?
[20:45] <teward> it errors with missing file/folder in the python app
[20:46] <teward> ahasenack: can we call the package broken and blacklist it?
[20:46] <teward> i don't think there's any rdeps
[20:46] <teward> and this is a 'new' package
[20:46] <teward> new as of Bionic
[20:46] <ahasenack> teward: I get this in a vm: https://pastebin.ubuntu.com/p/r7D9thcbwK/
[20:46] <teward> ahasenack: i got that too
[20:46] <teward> check /var/log/uwsgi/app/searx.log
[20:46] <teward> what do yo usee?
[20:46] <ahasenack> I have no clue how uwsgi is supposed to work
[20:47] <teward> ahasenack: neither do I, but if any of the python underneath fails to launch uwsgi itself explodes
[20:47] <teward> and that could trigger a segfault with a core dump
[20:47] <ahasenack> teward: I get this: https://pastebin.ubuntu.com/p/P34n2BVckK/
[20:47] <ahasenack> but note this is running as root, a normal user cannot create that log file
[20:47] <ahasenack> I was thinking that had something to do with it
[20:48] <teward> it could
[20:48] <ahasenack> whatever happened, those vars didn't get expanded looks like
[20:48] <teward> yeah it didn't
[20:48] <teward> which it wouldn't from a shell
[20:48] <ahasenack> I have /run/uwsgi/app/searx/ but it's empty
[20:49] <teward> well from a shell it drops you into it might not
[20:49] <ahasenack> deb-confnamespace comes from /usr/share/uwsgi/conf/default.ini
[20:50] <teward> and that's not being expanded, it seems, by uwsgi properly.
[20:54] <teward> aha
[20:54] <teward> ahasenack: ran the uwsgi command that should start uwsgi properly
[20:54] <teward> getting a permission denied on a bind
[20:55] <teward> underneath gdb
[20:55] <ahasenack> teward: it seems to be failing in debian too: https://ci.debian.net/packages/s/searx/
[20:55] <teward> ahasenack: should we raise a 'critical' or equivalent bug in Debian?
[20:55] <teward> because it's not fit to exist
[20:55] <teward> if autopkgtests are dying
[20:55] <teward> and it's going to block other things here in Ubuntu from migrating from proposed
[20:55] <teward> nginx included
[20:55] <ahasenack> I think a bug is ok. debian doesn't yet gate on dep8 tests like we do
[20:55] <teward> ahasenack: bug on it here?
[20:56] <teward> (Ubuntu)
[20:56] <ahasenack> I'd suggest a bug over there, and you can use that bug to ask an AA to let it pass for now
[20:56] <ahasenack> a bug here too also works, having both linked
[20:58] <teward> ahasenack: so, serious-level bug on Debian about autopkgtest failures which suggest the application doesn't work?
[20:58] <teward> 'cause that's where i'm at now
[20:59] <ahasenack> I don't know enough to say if the app doesn't work or not, but a segfault is bad
[20:59] <ahasenack> but I didn't check debian to see if it segfaults there too
[20:59] <teward> ahasenack: i'm inclined to open it here in Ubuntu and say it segfaults horribly
[20:59] <ahasenack> the fact that the test fails in the same place is suggestive, though
[20:59] <teward> and the autopkgtests make it fail horrible.
[20:59] <ahasenack> ok
[20:59] <ahasenack> do you have the crash file too?
[20:59] <ahasenack> in /var/crash?
[21:00] <teward> ahasenack: no but I have gdb trace when you have the application run under uwsgi directly
[21:00] <teward> so see if this works for you...
[21:01] <ahasenack> how did you run it?
[21:01] <teward> gdp --args "uwsgi -s 4000 --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/searx.ini"
[21:01] <teward> gdb*
[21:01] <teward> which has uwsgi directly run the application as configured on port 4000
[21:02] <teward> that gave a permission denied in gdb
[21:02] <teward> after dropping root privs to uid/gid 33
[21:02] <ahasenack> I start that as root and it exits after failing to write to that /run directory
[21:03] <teward> let me replicate again
[21:04] <yee__> dose anyone have a solution how to fix this problem? https://askubuntu.com/questions/1002933/vmware-dhcp-no-internet-access, same problem in here as well https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320
[21:05] <teward> ahasenack: i'm getting the 'no such file or directory' error myself... except when I set the env vars manually
[21:05] <teward> so...
[21:05] <ahasenack> which vars?
[21:06] <teward> UWSGI_DEB_CONFNAME and UWSGI_DEB_CONFNAMESPACE
[21:06] <teward> UWSGI_DEB_CONFNAME='searx', UWSGI_DEB_CONFNAMESPACE='app'
[21:06] <teward> which uwsgi conf says it uses to populate the 'fake' options
[21:07] <ahasenack> that's all way over my head :)
[21:07] <teward> the workers all segv
[21:07] <teward> *but* if I run the same command under gdb...
[21:07] <teward> oooh actually
[21:08] <teward> i don't get any usable traceback this time
[21:08] <teward> ahasenack: interesting to note though that i get all the segfault calls, and it constantly respawns
[21:08] <ahasenack> systemd would do that, but if you started it directly, I don't know what would do it then
[21:09] <teward> ahasenack: if I start uwsgi directly, I replicate the segfaults
[21:09] <teward> replicating what systemd does to populate those vars
[21:09] <teward> and it segfaults
[21:09] <teward> i'm going to open a critical bug here that has to do with the segv
[21:09] <teward> because both of us are getting crash dumps
[21:10] <teward> yep i get a crash dump for uwsgi as well
[21:10] <teward> in the autopkgtests area
[21:11] <ahasenack> cool, upload the crash dump too then
[21:13] <teward> ahasenack: do you think using 'Critical' as the bug importance would be a bad thing?
[21:13] <teward> this autopkgtest breaks a lot of things...
[21:14] <ahasenack> probably. I tend to reserve critical bugs sparingly
[21:14] <teward> well the package simply doesn't work
[21:14] <ahasenack> someone in #ubuntu-release can let it pass, but that's why having a bug is important, so when they add it to their script they can link to the bug
[21:14] <teward> indeed
[21:15] <ahasenack> also link to https://ci.debian.net/packages/s/searx/ saying it's failing there as well
[21:15] <teward> ahasenack: should I just upload the crash file direct or should I apport-collect the bug number?
[21:15] <ahasenack> try apport-bug first
[21:15] <ahasenack> it might pick up the crash file
[21:17] <Blueking> flashed bios... now I am missing interface em2   the other em1 are there
[21:17] <teward> ahasenack: nope, fails.
[21:17] <ahasenack> fails because no network?
[21:18] <teward> apport-bug says no pending crash reports
[21:18] <Blueking> shouldn't interface be visible with ifconfig -a ?
[21:18] <ahasenack> Blueking: probably, try also "ip -l" to be sure
[21:18] <teward> ahasenack: unless you know how I can put this crash right into the proper package
[21:18] <teward> because it's crashing uwsgi not searx so it'd pick up as an uwsgi bug
[21:19] <Blueking> another thing.. when I look into bios  bios tells me I can have 1,2,3 all cores enabled, I've set 'all'  but only 2 cores visible in ubuntu ?
[21:19] <ahasenack> teward: try https://pastebin.ubuntu.com/p/BQNwmkdC8y/
[21:19] <Blueking> ip -l
[21:19] <ahasenack> it's fine if it picks it up as a uwsgi bug, that can be changed
[21:19] <teward> mmkay.  though i already filed the searx bug
[21:19] <ahasenack> then just attach the crash file
[21:20] <ahasenack> Blueking: you checked by looking in /proc/cpuinfo or what?
[21:20] <Blueking> ahasenack yes
[21:20] <teward> aaand now I can't close out of this :/
[21:20] <Blueking> munin reports 2 core too
[21:21] <ahasenack> Blueking: counted "processor" lines?
[21:21] <Blueking> processor 0 processor 1
[21:22] <Blueking> Intel(R) Xeon(R) CPU E3-1230L v3 @ 1.80GHz
[21:22] <ahasenack> Blueking: check output of dmesg
[21:22] <ahasenack> there are many messages related to cpus and cores
[21:23] <ahasenack> look perhaps for "smpboot"
[21:23] <ahasenack> or "CPU"
[21:25] <Blueking> how I filter out cpu on dmesg ?
[21:26] <ahasenack> type dmesg|less
[21:26] <ahasenack> then use the "/" key and type CPU
[21:26] <ahasenack> "/" is to search
[21:26] <ahasenack> when done, use "q" to quit
[21:26] <Blueking> dmesg | cpu
[21:26] <ahasenack> "dmesg | less" means send the output of dmesg to the input of less
[21:26] <ahasenack> no
[21:26] <Blueking> like this ?
[21:26] <ahasenack> dmesg | less
[21:27] <ahasenack> dmesg and less are different programs
[21:27] <ahasenack> we are using | to connect them
[21:27] <Blueking> shorewall spams..
[21:27] <ahasenack> then you can use the arrow keys, page up/down keys, to navigate over the contents of dmesg
[21:27] <ahasenack> what's the first line you have?
[21:28] <ahasenack> it should be something like
[21:28] <ahasenack> [    0.000000] Linux version 4.15.0-22-generic (buildd@lgw01-amd64-013) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018 (Ubuntu 4.15.0-22.24-generic 4.15.17)
[21:31] <ahasenack> teward: I gotta go
[21:31] <ahasenack> see you tomorrow
[21:32] <teward> ahasenack: yep, no problem.
[21:32] <Blueking> ahasenack [    0.166957] x86: Booting SMP configuration:
[21:32] <Blueking> [    0.166962] .... node  #0, CPUs:      #1
[21:32] <Blueking> [    0.182986] x86: Booted up 1 node, 2 CPUs
[21:32] <teward> bugs're filed though you were pinged in another room
[21:33] <teward> !pastebin
[21:33] <ahasenack> teward: I subscribed to them
[21:33] <teward> Blueking: FYI, use a pastebin for multiline.  ahasenack is also having to leave right now.
[21:33] <teward> ahasenack: ack
[21:33] <teward> i also poked -release
[21:33] <teward> to see if they can handwave the failures for nginx
[21:33] <Blueking> :/
[21:33] <ahasenack> teward: someone can, might not even have to be an archive admin
[21:33] <ahasenack> I'm never sure about those permissions
[21:33] <teward> ahasenack: indeed, they'd [robably be in -release anyways
[21:33] <teward> or point me where I need to go
[21:33] <ahasenack> yep
[21:34] <teward> i know infinity and others have power :P
[21:34] <teward> anyways, i'm off myself
[21:34] <ahasenack> cya
[21:35] <nacc> Blueking: what is your question?
[21:35] <Blueking> nacc  my mobo's bios tells me I have 4 core  where I can define how many core that can be used 1,2,3 or all
[21:36] <Blueking> I've defined 'all'
[21:36] <Blueking> so why ubuntu only see 2 core ?
[21:38] <nacc> Blueking: what motherboard and cpu is it?
[21:38] <Blueking> nacc : [    0.162663] smpboot: CPU0: Intel(R) Xeon(R) CPU E3-1230L v3 @ 1.80GHz (fam: 06, model: 3c, stepping: 03)
[21:39] <Blueking> https://www.supermicro.com/products/motherboard/Xeon/C220/X10SLM_-F.cfm
[21:40] <nacc> Blueking: can you pastebin the output of `hwloc` ?
[21:40] <Blueking> hwloc not installed
[21:40] <nacc> Blueking: ok, install it :)
[21:41] <Blueking> no connection to net right now :/
[21:41] <Blueking> just updated bios and some issue with one of interfaces
[21:44] <Blueking> one got to do something after installing new bios ?
[21:44] <Blueking> on ubuntu
[21:45] <nacc> not usually
[21:53] <Blueking> nacc: in /dev I see i2c-0 i2c-1 i2c2... i2c-7     total eight.. are these about cores/threads ?
[21:54] <nacc> Blueking: no
[21:54] <nacc> Blueking: those are i2c devices https://en.wikipedia.org/wiki/I%C2%B2C
[21:54] <Blueking> ok
[22:10] <jose-phillips> hey any idea
[22:10] <nacc> jose-phillips: about what?
[22:11] <nacc> Blueking: it's relatively rare these days for Linux to not see all the resources on a system
[22:11] <jose-phillips> i have this sceneario
[22:11] <jose-phillips> im trying to setup a network where
[22:11] <jose-phillips> interface eno1 and eno2 are iscsi multipath
[22:12] <jose-phillips> and i need create a bonding to reach nfs of both interfaces
[22:12] <jose-phillips> if i leaave the ip configured on eno1 the bonding driver kill automatically the network on eno 1
[22:13] <jose-phillips> or at least i need one vlan interface that can choose use one interface or anther one
[22:13] <jose-phillips> using ububtu 18.04
[22:13] <jose-phillips> ubuntu server
[22:20] <jose-phillips> complicated eh..
[22:21] <nacc> "interface eno1 and eno2 are iscsi multipath" seems incorrect to me
[22:21] <nacc> iscsi is for disk storage
[22:21] <jose-phillips> i know
[22:21] <jose-phillips> the server is 100% diskless
[22:21] <sarnold> iirc you'd use corosync or pacemaker to do your interface failover
[22:23] <jose-phillips> so they depend to keep alive eno1 and eno2
[22:23] <jose-phillips> or at least eno1 or eno2
[22:23] <jose-phillips> now i need to set a extra interface that can manage anther subnet for nfs and should be active-backup
[22:23] <jose-phillips> in case the target can't be reached for example eno1
[22:24] <jose-phillips> use eno2
[22:24] <jose-phillips> with the same ip address
[22:24] <jose-phillips> bonding not work because when i do bond on the interface kill the interfaces that is using
[22:24] <jose-phillips> oto take it in the bond0 interface
[22:36] <Blueking> nacc ubuntu server back online
[22:37] <nacc> Blueking: cool
[22:38] <Blueking> hmm hwloc does what ?
[22:39] <nacc> Blueking: prints detailed info about the hardware topology
[22:40] <Blueking> installed hwloc   tries it  says no command ?
[22:40] <nacc> Blueking: sorry, try `lstopo`
[22:41] <Blueking> no cpu info there
[22:42] <Blueking> nacc http://paste.ubuntu.com/p/s9GXrnVwth/
[22:43] <Blueking> nacc http://paste.ubuntu.com/p/vSw2gghjr6/
[22:44] <Blueking> nacc http://paste.ubuntu.com/p/dTgxRCp5k3/
[22:47] <sarnold> xnox: hey any chance you still have access to the Better ARK? Blueking here's got a processor that shows up as 4c8t on ARK, but linux only ever sees two cores
[22:48] <Blueking> sarnold: supermicro mobo's bios I can define how many core to be active  1,2,3, all  this implies 4 core ?
[22:49] <sarnold> Blueking: what happens if you fiddle with that setting? :)
[22:49] <sarnold> set it to 1, boot, see what happens, set it to two, tec..
[22:49] <Blueking> tried set to 3 core no changes
[22:49] <Blueking> I can test 1 core
[23:00] <Blueking> 1 active core (bios)  ubuntu still replied 2 core
[23:04] <Blueking> any idea nacc sarnold ?
[23:04] <sarnold> no :(
[23:07] <Blueking> never seen more than 2 core on this xeon cpu...   could it be early versions of this cpu came out with only 2 core ?
[23:29] <JanC> Blueking: I looked into that yesterday, and this model is always 4-core as far as I could tell
[23:29] <JanC> there is a E3-1220 or something like that which only had 2 cores
[23:31] <JanC> maybe your BIOS is hacked and it hides 2 cores used by some bitcoin farm  ;-)
[23:32] <sarnold> I did vaguely consider it might be counterfeit cpu .. but does anyone do that any more?
[23:36] <JanC> I'm pretty sure these CPUs are too expensive to design a clone of for that to be lucrative
[23:37] <JanC> (or even something close enough that it isn't obvious)
[23:38] <JanC> if anything, a batch that got the wrong fuses blown and identifies incorrectly seems more likely then
[23:42] <sarnold> ahhh yes that's far more plausible
[23:42] <JanC> or just some bad firmware
[23:43] <JanC> I guess trying a firmware (UEFI) upgrade (if available) would be a good idea
[23:44] <sarnold> JanC: heh I think that was yesterday's project
[23:44] <Blueking> I'll post a question to shop where I bought mobo and cpu
[23:45] <JanC> Blueking: are you using an Ubuntu kernel?
[23:45] <JanC> or something you compiled yourself?
[23:45] <Blueking> ubuntu kernel
[23:47] <JanC> I suddenly wonder if Intel disabled cores to fix meltdown/spectre issues?  :P
[23:49] <sarnold> disabling HT was rumoured to help with something or other.. but cores? I think it'd take disabling all-but-one to make a difference
[23:49] <Blueking> just checked billing note from shop -> Intel Xeon Quad-Core E3-1230Lv3 1.8GHz 8MB, 25W, LGA1150
[23:49] <Blueking> bios says 1,2,3,all
[23:49] <JanC> sarnold: depending on how the cache is shared
[23:50] <Blueking> could it be bad connect between cpu and socket ?
[23:50] <JanC> I doubt it would work at all then
[23:51] <JanC> I wonder if you have accidentally set a kernel parameter or something
[23:51] <Blueking> I don't have experience to do so..
[23:51] <sarnold> ohho, what's /proc/cmdline look like?
[23:52] <Blueking> hmm /proc/cmdline ?
[23:52] <Blueking> I might have to test with windows OS ..
[23:52] <JanC> ?
[23:53] <Blueking> see if windows can access all 4 cores
[23:53] <JanC> is there anything unusual in /proc/cmdline ?
[23:54] <Blueking> http://paste.ubuntu.com/p/PMr3bYJcGy/
[23:54] <sarnold> that's /proc not /proc/cmdline :)
[23:55] <Blueking> http://paste.ubuntu.com/p/mh5T6PqVZP/
[23:55] <JanC> hm
[23:55] <Blueking> I uploaded new intel microcode recently
[23:58] <JanC> I wonder why this has intel_pstate=disable
[23:58] <sarnold> well, it was a good theory. bummer.
[23:58] <Blueking> something suspicious ?
[23:58] <JanC> not suspicious
[23:59] <Blueking> intel_pstate=disable ?