[00:18] <teward> so, stupid question but where are the autopkgtests stored
[00:18] <Alessandro_> Hello. I'm having some issues using MariaDB on Ubuntu 16.04. I install it with "apt-get install mariadb-server mariadb-client". When I run "mysql -uroot", however, I get "Access denied for user 'root'@'localhost'". I then run mysql_safe_installation and set a password for the root user, and I still get the same error over and over again when logging in with "mysql -uroot -p" and typing the correct password. any hint?
[00:19] <nacc> teward: how do you mean?
[00:19] <teward> nacc: well, trying to ID what's going on with nginx
[00:19] <nacc> teward: the tests themselves are in d/t/control
[00:19] <teward> there's two regressions in diaspora-installer but that's something on their side not nginx
[00:19] <teward> ah OK
[00:19] <teward> nacc: looks like i never had to touch them before :p
[00:19] <teward> i see some nginx fails today, gotta see what that's about :P
[00:22] <teward> oh hm, ssl curves
[00:22] <teward> *checks Zesty*
[00:24] <teward> nacc: any idea how to check what ECDH curves are supported on Zesty?
[00:24] <nacc> teward: i have no idea what that acronym is :)
[00:25] <teward> i'll ask OpenSSL then
[00:26] <Alessandro_> teward: try "openssl -v" IIRC
[00:27] <trippeh_> for curves, openssl ecparam -list_curves
[00:28] <teward> well I know what I have to do.  I have to drop a curve...
[00:28] <teward> who do i prod to change what is acceptable or not for a given test?
[00:28] <teward> autopkgtest* on the migration tracking system?
[00:29] <nacc> teward: you update the test
[00:29] <nacc> teward: wait, what do you mean 'acceptable'? all tests have to pass
[00:30] <teward> nacc:  I.E. "always failed" or 'Ignored once"
[00:30] <nacc> teward: that's the release team, i believe
[00:30] <teward> OK
[00:31] <teward> i'm going to have to drop a test since we don't support the curve... or mark "always failed"... might be easier to drop that curve from the test.
[00:32] <nacc> teward: always failed is typically not set -- it's something autopkgtest runner recognizes
[00:32] <teward> mmm
[00:32] <nacc> teward: 'failure ignored' is what gets set
[00:32] <teward> nacc: That's probably what's going to have to be set to get nginx out of proposed, but for more than just nginx.  I need to check with Debian in the interim
[00:32] <nacc> teward: so this is a nginx test?
[00:33] <teward> because i think they added a curve we don't support that got in from Experimental
[00:33] <teward> nacc: well...
[00:33] <teward> nacc: two problems:
[00:33] <teward> (1) NGINX tests fail with Regression, I think it's because there's a curve added to the tests
[00:33] <nacc> teward: it might be apporpirate to add delta is some test depends ona  feature we odn't support
[00:33] <teward> (2) a *different* autopkgtest errors out
[00:33] <teward> but *not* because of nginx
[00:33] <nacc> teward: let me look
[00:33] <teward> nacc: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nginx
[00:34] <teward> diaspora-installer is the only other one I am not looking into but those errors look like it's a repository problem *not* related ot nginx
[00:34] <nacc> teward: ack, so you're saying we should skip the ec-x25519 test on ubuntu?
[00:34] <teward> nacc: i'm saying "probably", but I need to figure out its origin
[00:34] <teward> first
[00:34] <nacc> teward: that should be done via a delta to the src package that either comments out (i prefer this but it's up to you, i think) or deletes it from d/t/control
[00:35] <teward> nacc: I want to figure out if it's from Debian Exp. or not first
[00:35] <nacc> teward: ack
[00:35] <teward> that said I need a Debian image too to test
[00:35] <nacc> teward: i'm looking at the other one
[00:35] <nacc> teward: lxc launch images:debian/sid/amd64
[00:35] <teward> if it works in Debian but not Ubuntu, then it's a delta that we can comment out for the test
[00:35] <teward> nacc:  already ahead of you
[00:35] <nacc> teward: and/or check ci.debian.net
[00:35] <teward> but i'm installing the ubuntu-server image in an lxc container.
[00:35] <teward> or rather, installing that metapackage
[00:36] <teward> so i have a 'standard' set of crap lol
[00:36] <nacc> https://ci.debian.net/packages/n/nginx/unstable/amd64/
[00:36] <nacc> seems rather green
[00:36] <teward> nacc:  yeah but i want to make sure that this test is 'new'
[00:36] <teward> and if it's not 'new' then poke the Security team for a check on OpenSSL in Ubuntu to see if they dropped the curve or something
[00:37] <teward> being thorough
[00:37] <nacc> teward: http://autopkgtest.ubuntu.com/packages/nginx/zesty/amd64 fwiw as well
[00:38] <nacc> teward: that test wasn't present in the last upload to z-p, it seems
[00:38] <nacc> teward: it is present in debian
[00:38] <teward> nacc: the 'last upload' to z-p was a half-merge
[00:38] <teward> it was HTTP/2 fixes ahead of the actual merge from Debian
[00:38] <teward> the 'latest' that got run had to wait for Perl to get out first
[00:38] <teward> then it ran the autopkgtsts
[00:38] <nacc> ack
[00:39] <teward> so these are "new" tests that are originated from Debian since.. what, 1.10.0, so the Xenial cycle?
[00:39] <teward> yeah I dont' see that curve in the OpenSSL curve lists
[00:39] <teward> for Ubuntu anyways
[00:39] <teward> gonna check that list vs. Debian and if the list is different then ignroe the check here in ubuntu by commenting out as part of the Delta
[00:40] <trippeh_> our openssl is too old :)
[00:40] <teward> :P
[00:41] <teward> i'm almost certain it is
[00:41] <teward> yay Debain container time to update you :p
[00:43] <teward> s/Debain/Debian/
[00:43] <teward> *notes to update his autocorrect*
[00:45] <nacc> teward: i retriggered those two diaspora failures, i think they are going further, but we'll see
[00:46] <teward> OK
[00:46] <teward> nacc: thanks.
[00:46] <teward> huh interesting I don't see that SSL curve in Unstable either o.O
[00:46] <teward> ECDH*
[00:47] <teward> confirmed the core issue
[00:47] <teward> # nginx -T
[00:47] <teward> nginx: [emerg] Unknown curve name "X25519" (SSL:)
[00:47] <teward> nginx: configuration file /etc/nginx/nginx.conf test failed
[00:47] <teward> in Zesty
[00:47] <teward> but works fine in Unstable
[00:47] <teward> so that's just a curve we don't accept.
[00:47] <teward> s/accept/have/
[00:47] <trippeh_> maybe it doesnt list these newfangled non-ECDH curves in ecparam
[00:48] <teward> trippeh_: it might not
[00:48] <trippeh_> it is new in openssl 1.1 fwiw
[00:48] <teward> ah, that would explain that
[00:48] <nacc> teward: yeah, i think those two diaspora failures will clear on their own now
[00:48] <teward> we don't roll 1.1 yet I don't think
[00:49] <teward> nacc: OK.  I'm going to go and say "We don't support this curve, because OpenSSL is older than 1.1.0"; how did you suggest I go about 'dropping' the test?
[00:49] <nacc> teward: no, 1.0.2g on zesty
[00:49] <nacc> teward: add a delta, each test is a stanza in d/t/control
[00:49] <teward> yes but define "delta" as in drop the test or comment out the entire test?
[00:49] <nacc> teward: and then i'd say in the changelog entry (so we know for merges) that once we are at openssl 1.1.0 we can drop it
[00:50] <nacc> teward: totally up to you
[00:50] <nacc> teward: if we did everything with an SCM, then i'd say delete it, but it's a little more self-documenting if commented out
[00:50] <teward> nacc: I actually have a copy of the packaging in a GitLab instance of my own, so it's sorta version controlled.
[00:51] <nacc> teward: and since you are the maintainer, i think that's ok then to just drop it and you'd know
[00:51] <teward> nacc: yep, well I'm just going to remove it from d/t/control but leave the test "in there"
[00:51] <nacc> teward: if someone were to come along and do teh team workflow to re-merge it, it'd also be obvious what corresponds to what, i think
[00:51] <teward> and comment accordingly.
[00:51] <nacc> teward: yeah exactly
[00:51] <teward> nacc: indeed.  Though the team tends to poke me for testing first lol
[00:51] <nacc> teward: :)
[00:53] <trippeh_> "Unknown error executing apt-key" - thanks, apt-get
[00:54] <nacc> heh
[00:56] <teward> oops i forgot to put bugfix-only in the changelog fff
[00:56] <teward> 'accepted' oh cool.
[00:58] <teward> nacc: I could probably alter the test to try and test the OpenSSL version first.  But I'm lazy :P
[00:58] <teward> I'll just yell at Debian for making me increase the delta :P
[00:58] <teward> again.
[00:58] <teward> nacc: looks like the diaspora-installer tests didn't blow up this time heh
[00:59] <teward> since now it's not erroring on the gems xD
[01:00] <teward> nacc: what do I need to do if I want to set up autopkgtests for a PPA build before I upload something, say on a local test instance?
[01:00] <teward> if you know :)
[01:11] <trippeh_> ah lol, since I was chrooting from a EL7 install, PATH lacked /bin ...
[01:11] <trippeh_> "wait! no grep!??"
[01:12] <nacc> teward: you can run an autopkgtest against a specific PPA build, one sec
[01:12] <nacc> teward: https://wiki.ubuntu.com/ProposedMigration "Testing aginsta a PPA"
[01:16] <teward> nacc: yeah, trying to see where it reports that
[01:17] <teward> nacc: apparently I'm "not authorized" to see the report.  or it hasn't run yet, I don't see it queued either.
[01:23] <nacc> teward: i can run it for you probably
[01:23] <nacc> teward: if you have the ppa set up
[01:24] <nacc> teward: and diaspora passed now (excuses is still pending an update)
[01:26] <teward> nacc:  it'll likely rerun and/or explode
[01:26] <teward> nacc: i was able to *request* the build against the nginx stable PPA.  I can't see if it's pending or not
[01:26] <teward> that's all.
[01:26] <teward> It didn't say I didn't have privs. to request.
[01:26] <teward> probably since i'm the admin for that 'group' PPA :P
[01:28] <nacc> teward: oh you'd see it running in the autopkgtest running page
[01:28] <nacc> https://autopkgtest.ubuntu.com/running
[01:29] <nacc> teward: so you uploaded a new version, anyways, right?
[01:29] <nacc> as i see tests running for ubuntu3
[01:47] <teward> nacc: yes.
[01:47] <teward> nacc: -1ubuntu3 has a fix for the autopkgtests.
[01:47] <teward> and was already accepted somehow.
[01:47] <teward> it'll probably *still* need pushed by the release team
[01:49] <teward> nacc: can you check if there's nginx tests against 1.10.3-1+zesty0 or similar in a PPA?
[01:49] <teward> being run now
[01:49] <teward> I expect that to blow up actually lol
[01:50] <teward> (in a PPA)
[01:50] <teward> 1.10.3-0+zesty0 actually heh
[01:50] <teward> blah i'm tired
[01:51] <nacc> teward: no, there's only feature freeze on, so it shouldn't need any help in this case
[01:51] <teward> OK
[01:51] <nacc> teward: and yes, i now see the zesty0 running
[01:51] <nacc> against your ppa
[01:51] <nacc> http://autopkgtest.ubuntu.com/running#pkg-nginx
[01:52] <teward> cool.
[01:59] <teward> nacc: yep i see it working thanks
[02:00] <nacc> teward: the only annoyance is you can't see the logs fully until the test finishes and copies over
[02:00] <nacc> teward: which is quite a bit slower than the normal autopkgtests i've found
[02:15] <teward> nacc: Indeed, though my PPA update workflows are not ones I regularly need to poke so :P
[02:15] <teward> (nor do I need rapid testing)
[02:16] <teward> nacc: looks like commenting out that autopkgtest solved the failures for nginx, let's just hope diaspora doesn't blow up in our face again :P
[02:16] <teward> wth 'nova' regression
[02:17] <teward> nacc: can you see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/n/nova/20170228_013617_86af9@/log.gz and tell me what's dead here?
[02:17] <teward> it *looks* to me like it's an openscsi / erlang issue
[02:18] <teward> not even sure *why* nova is triggered by the nginx test though
[02:44] <nacc> teward: i'd guess not your issue
[02:44] <nacc> teward: i'll retry it
[02:45] <nacc> teward: although i agree, i don't know why nova ran
[02:46] <nacc> teward: in fact, i don't see anything installed from -proposed at all except
[03:31] <teward> nacc: I think you trailed off...
[03:31] <teward> [2017-02-27 21:46:23] <nacc> teward: in fact, i don't see anything installed from -proposed at all except ...
[03:47] <teward> nacc: ^.^ nginx has finally left -proposed and landed in Zesty
[03:47] <teward> I can rest easy!
[04:14] <teward> Server Team: I can safely say that the NGINX merge has been completed.  Starting with Zesty, we now have ***dynamic module support***
[04:14] <teward> future merges should not be as hellish anymore :)
[04:15] <teward> (cc rbasak, jgrimm, sarnold because reasons, anyone else who cares) ^
[04:19] <sarnold> teward: nice :D now to relax! :D
[04:20] <teward> sarnold: truth!
[07:00] <frickler> jamespage: did you take a look at building kraken yet? (ceph-11.2.0) would it still seem feasible to get it into zesty?
[08:20] <jamespage> frickler: I did take a peek but then discussed with sage; we don't normally drop the interim releases into Ubuntu
[08:20] <jamespage> frickler: so next drop with be luminous in the spring - probably for 17.10
[09:01] <frickler> jamespage: o.k., thx for the info
[09:05] <DK2> after installing a server with 2 TB disks i get "cannot get disk parameters" when booting the hard drive
[09:06] <DK2> the installation seems to be fine when checking via a live cd
[09:06] <DK2> what could be the cause for it?
[09:06] <DK2> does the server does not see the drives?
[09:17] <DK2> figured it out, the bootvolume was not set
[09:18] <sarnold> where did you set it?
[09:30] <zioproto> hello there. I would like to make a refresh of the nova package
[09:30] <zioproto> this is different from when I just add a patch in debian/patches
[09:30] <zioproto> there is a standard procedure to refresh the upstream version ?
[09:42] <lordievader> Good morning.
[09:51] <sarnold> zioproto: usually along the lines of: download the new tarball, verify sigs; unpack tarball; rm -rf newtarball/debian/; cp -a oldtarball/debian/ newtarball/debian/ ; rename the tarball to have the .orig.tar.gz name; edit the newtarball/debian/changelog file, add a new entry with new version number, description of what patches remain; fiddle quilt patches from debian/patches/ as needed
[09:54] <zioproto> sarnold, ok, so I have to wait the nova folks to create the tarball. I though I could import a git commit from the nova repo
[09:57] <sarnold> zioproto: well there's a whole 'git build package' thing going with some way to treat upstream gits as tarballs without the tarballs.. all I know is the ancient stuff :)
[10:49] <rbasak> teward: thank you!
[11:43] <maswan> Hm. Upgrading our storage servers to xenial we saw a large performance degradation on our hp hw raids (hpsa), anyone else with similar observations? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1668557
[12:03] <cpaelzer> maswan: from 3.18.18 to 3.18.21 is already a good narrow diff to look for
[12:03] <cpaelzer> maswan: you said simple dd test is driving this
[12:03] <maswan> yup
[12:03] <maswan> or, well, my collegue across the corridor
[12:03] <cpaelzer> maswan: could you provide the exact command and (to start) an output of "iostat -xtdk 5" that was running over the time
[12:04] <maswan> sure
[12:06] <maswan> ok if I limit iostat to just the relevant device?
[12:06] <cpaelzer> maswan: sure
[12:06] <maswan> (lvm for OS stuff, so lots of dm-*)
[12:06] <cpaelzer> it is just a start to get a feeling where we should go to
[12:06] <cpaelzer> if you write only to a single device, just that
[12:07] <cpaelzer> if you write to an LVM or such just the related devices to your workload
[12:07] <cpaelzer> like top lvm, and the PVs that matter
[12:07] <maswan> no, we write to xfs on /dev/sdb
[12:07] <maswan> for data
[12:08] <maswan> lvm for OS on /dev/sda (different slice, hpssacli output is already attached)
[12:08] <cpaelzer> I'm still reading through the attachments
[12:08]  * maswan nods
[12:08] <maswan> soon you'll get another. :)
[12:09] <cpaelzer> perfect would be to get the iostat for just the two god/bad kernels that are close
[12:12] <maswan> bad case is in, rebooting for good old kernel. :)
[12:14] <maswan> hm. one case we haven't tried so far in pinning the blame is dd:ing directly to the block device.
[12:15] <cpaelzer> maswan: raw access and/or an alternative fs (like ext4) can be worth a shot for sure
[12:15] <maswan> let me get iostat for the fast case first though
[12:15] <cpaelzer> absolutely
[12:15] <maswan> hm. do you want iostat for the first-good mainline kernel too?
[12:16] <cpaelzer> as I read the bug I thought that comparing 3.18.21-031821.201509020527 vs 3.18.22-031822.201510031227 should be best right?
[12:16] <maswan> yes
[12:16] <cpaelzer> that is minimal delta in terms of patches
[12:16] <maswan> Will do that, just ran it on whatever it was booted on first.
[12:16] <cpaelzer> so I'd compare those until we have a reason to look further
[12:16] <maswan> and then thought harder of what would be best for comparison. :)
[12:16] <cpaelzer> to pick those two will avoid us seeing a lot of "other" noise in logs
[12:24] <maswan> ho hum
[12:24] <maswan> hp servers are slow to boot
[12:24] <patdk-lap> slow is an understatement
[12:25] <maswan> I heard quite a bit of grumbling yesterday when Nikke was bisecting kernel versions and had to wait for a reboot between each test
[12:29] <maswan> There, iostat and command line output from the last fast and first slow 3.18.2* kernels
[12:30]  * cpaelzer reading
[12:31] <maswan> and on the slow kernel, pretty much identical performance for dd if=/dev/zero of=/dev/sdb bs=256k, possibly slightly slower
[12:36] <cpaelzer> it seems it no more recognized this as a raid
[12:37] <cpaelzer> so the block device layer is holding back requests to merge them
[12:37] <cpaelzer> maswan: you see write reqeust merges per sec ~500
[12:37] <cpaelzer> maswan: and due to that ~8x bigger write requests
[12:37] <cpaelzer> maswan: which in your case sucks, as the raid below will split it along its stripe size again
[12:37] <cpaelzer> or would have handled all of them in cache already
[12:38] <maswan> cpaelzer: that could indeed explain the suckage
[12:38] <cpaelzer> maswan: you also see that while rq-size is x8 the write await is x60
[12:38] <cpaelzer> so you can be happy that it is "only" 1/2 instead of 1/7.5 speed
[12:38] <cpaelzer> now lets start to look for changes
[12:39]  * cpaelzer reading diffs
[12:39] <maswan> thanks
[12:39] <cpaelzer> maswan: IIRC somewhere in /sys there were attrivutes for the devices that flag such things (spinning, cached, ...)
[12:39] <cpaelzer> maswan: while I look for code if you could look in ...
[12:39]  * cpaelzer is searching
[12:42] <cpaelzer> maswan: get that for both kernels booted on your device (sdb?)
[12:42] <cpaelzer> $ for i in /sys/class/block/sda/queue/iosched/* /sys/class/block/sda/queue/*; do echo $i $(cat $i); done
[12:43] <cpaelzer> there should be no diff between stable kernels, if there is that is another indicator where to look
[12:46] <maswan> yup, working on it
[12:46] <maswan> aka waiting for reboot
[12:48] <cpaelzer> maswan: also you go through page cache with your test (intentionally?) - once time permits you could try if all is the same with oflag=direct
[12:48] <cpaelzer> yet the request merging is a hotter lead which should be pursued first
[12:48] <cpaelzer> OTOH the reboots seems to be what slows you down, so we might collect what we can do each cycle
[12:48] <maswan> well, the first test of dd into a file on xfs is very close to the production case
[12:49] <maswan> which is taking large files from network onto disk (and then spooling them to tape, or the other way around)
[12:49] <maswan> before ingest rate it could handle was line speed 10GE
[12:50] <cpaelzer> ok, if close to the real cae lets stick to that for now
[12:50] <maswan> well, single file all zeros is already a simplifcation of it. but sure, I can try some oflag=direct while I'm booted anyway. :)
[12:52] <maswan> only diff is max_sectors_kb, 4096->512
[12:52] <maswan> attaching fastmode output to the bug now
[12:52] <cpaelzer> but well that is it maswan
[12:53] <cpaelzer> that is the critical value
[12:53]  * maswan nods
[12:54] <cpaelzer> and the size close to 8k is in 512b sectors to 4096 (kb) matches the 8*512
[12:54] <maswan> so probably no need for more narrow dd test cases
[12:54] <cpaelzer> maswan: exactly
[12:54] <cpaelzer> maswan: I still struggle to see the patch that causes it, but there is a workaround for you to test
[12:54] <cpaelzer> maswan: boot the slow kernel and set 512 into that calue
[12:54] <cpaelzer> hmm
[12:54] <cpaelzer> was that a writable one
[12:54] <cpaelzer> uh it might not be
[12:55] <maswan> seems to be writeable
[12:55] <maswan> lets see
[12:56] <cpaelzer> maswan: if you are tuning later for raids you might also consider setting /sys/class/block/sdb/queue/rotational to 0
[12:57] <cpaelzer> locality with so many disks is kind of inexistant
[12:57] <cpaelzer> but one change at a time
[12:57] <cpaelzer> let me know if setting the smaller max_sectors_kb helped
[13:01] <cpaelzer> maswan: I think I found the change http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=20d74bf29cfae86649bf1ec75038c79a9bc5010f
[13:02] <cpaelzer> it is correct to "fix" it, yet in your case with the drives very likely not having 4k formatting and the strip-size/offset being different it comes to the need of tuning that now
[13:02] <cpaelzer> maswan: let me know how setting 512 worked for you
[13:04] <maswan> cpaelzer: yup, that does indeed make stuff fast on the newer kernel
[13:04] <cpaelzer> yeah
[13:05] <cpaelzer> maswan: for more tuning, have you tried the rotational=0 as well?
[13:06] <cpaelzer> maswan: TL;DR IMHO the controller always announces 4k, instead of being smart and on a certain raid setup drop to the stripe or sector size
[13:06] <cpaelzer> maswan: newer linux "fixes" now pick these values up correctly which makes it slower for you :-/
[13:06] <cpaelzer> maswan: interested in the rotational flag
[13:06] <maswan> rotational=0 makes very little difference
[13:07] <cpaelzer> it should save cpu time
[13:07] <maswan> maybe 5-10% for kb=512
[13:07] <cpaelzer> I come from mainframes, every cycle is expensive :-)
[13:07] <cpaelzer> Or make it green, save energy :-)
[13:08] <cpaelzer> maswan: there are other cases where reverting that fix is no option, are you good setting that value as a tuning in your setup?
[13:08] <cpaelzer> maswan: if so I'd close the bug report with that stated
[13:09] <maswan> We're good with setting that in our setup, maybe hpsa authors should be prodded that they shouldn't advertise larger blocks to the kernel than they can (reasonably) handle?
[13:10] <cpaelzer> maswan: as I said they correctly say what they "can" handle, but an option to "advertise what is smart instead of what we can"might be worth
[13:10] <cpaelzer> maswan: if you have contacts at least ask them
[13:10] <maswan> not really
[13:11] <maswan> hm. I guess they might be reading linux-raid though, I'm a long time lurker in there
[13:11] <maswan> Please close it with as much info you can think of on the causes etc
[13:13] <cpaelzer> maswan: done
[13:13] <cpaelzer> maswan: you might use the bug as link in your post
[13:14] <maswan> Yeah, that was my intention
[13:14] <cpaelzer> maswan: I'd be pleased if you could set my user to cc, email is in the launchpad account I posted to the bug
[13:14] <maswan> Sure!
[13:16]  * cpaelzer is happy that his 12 year old thesis knowledge still applies to todays real world cases :-)
[13:16] <zioproto> zul, hello there, are you refreshing some nova stuff today ?
[13:25] <maswan> hm. cc:ing a googled-up hpsa driver contact address too
[13:32] <zioproto> guys, looking at the repo git://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/nova how do you do a commit like 8de3da59a8a8c68f76cea78e5319ad18cf8c2531 ? Do you use a tool like git-dsc-commit ?
[13:33] <zioproto> when I refresh the nova tag
[13:33] <zioproto> should I git checkout in detached head the current latest tag, then make a new commit, and tag it ?
[13:33] <zioproto> then I can merge that new tag into stable/mitaka
[13:33] <zioproto> is that the idea ?
[13:36] <zioproto> I think basak told me this in the past, where are the logs of this IRC channel ?
[13:38] <Slashman> hello, I have "/usr/lib/accountsservice/accounts-daemon" at 100% CPU (on one thread), anyway to understand why? (ubuntu xenial)
[13:46] <cpaelzer> Slashman: you might start it with --debug --replace to get a log what it is doing - although I don't know how disruptive that might be
[13:46] <cpaelzer> Slashman: eventually it is supposed to implement a dbus service, so maybe some dbus monotoring might do it as well
[13:46] <cpaelzer> Slashman: but my dbus-foo isn't good enough to guide you n that
[13:47] <Slashman> cpaelzer: this server has only one main service : proftpd, I guess that is somewhat related
[13:55] <jamespage> zioproto: the tool you are looking for is gbp import-orig
[13:56] <jamespage> that allows you to import a new upstream release
[13:57] <zioproto> I managed to do it with git
[13:57] <zioproto> I just added the git remote of the upstream
[13:57] <zioproto> and I did
[13:57] <zioproto> git checkout tagname -- .
[13:57] <zioproto> then I had to commit manually
[13:57] <zioproto> when you do the merge of the new tag into the stable/mitaka ... I should just discard the changes to the .gitignore and to the .gitreview, right ?
[13:58] <zioproto> Basically I am trying to create a commit like this one 6de2684e69b8945042c32d185307f10fcf50b24e
[14:01] <maswan> cpaelzer: Btw, Nikke is not quite agreeing that this isn't a hpsa driver bug, giving crappy performance by default.
[14:01] <maswan> but I guess that's more useful in a discussion with upstreams
[14:04] <zioproto> coreycb, is there already a LP bug for the new nova release ? https://review.openstack.org/#/c/438570/
[14:06] <coreycb> zioproto, hello I would guess so. zul is working on stable point releases this week, so he would know better than me.
[14:07] <zioproto> zul, we have a race between ubuntu making the SRU packages and nova pushing his 13.1.3 tag :)
[14:07] <zioproto> please make sure ubuntu packages will be at 13.1.3
[14:14] <zioproto> uhm, I am not sure how to update the pristine-tar branch
[14:18] <FrEaKmAn_> hi all.. I have a simple webpage in folder owned by root:www-data... I created new user test and added this user to www-data group
[14:18] <FrEaKmAn_> but that user still cannot write to that folder... any ideas?
[14:18] <FrEaKmAn_> I logged out, restarted everything...
[14:22] <zioproto> ok I did something like pristine-tar commit ../nova_13.1.3.orig.tar.gz 13.1.3
[14:57] <zioproto> ahhhhh
[14:57] <zioproto> I restarted from scratch
[14:57] <zioproto> gbp import-orig --upstream-version=13.1.3 --debian-branch=stable/mitaka --merge --pristine-tar ../nova_13.1.3.orig.tar.gz
[14:59] <Slashman> cpaelzer: looks like my issue is the same as https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1316830
[15:08] <zioproto> guys is this something valid in Xenial ? 'add-apt-repository -s ppa:ubuntu-cloud-archive/tools'
[15:09] <zioproto> I dont see any xenial here: http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/dists/
[15:14] <SmOkE_RU> Âñåì ïðâèåò, êòî ìîæåò ïîìî÷ü ñ ïîñòôèêñîì?
[15:14] <zioproto> jamespage, http://paste.openstack.org/show/600790/ ?
[15:20] <SmOkE_RU> Кто-то с постфиксом может помочь?
[15:22] <zioproto> SmOkE_RU, если вы можете говорить по-английски, я могу помочь вам с постфиксе
[15:22] <zioproto> (google translate)
[15:22] <SmOkE_RU> zioproto i think i can)
[15:23] <zioproto> so just ask your question in English, it will be easier to get an answer :)
[15:24] <SmOkE_RU> zioproto i am install postfix for forum phpBB, and cant send emails, in terminal postfix sends mails
[15:26] <zioproto> are you sure phpBB is using postfix to send the mails ?
[15:26] <zioproto> sometimes php programs call their out php mta functions
[15:27] <SmOkE_RU> zioproto yes, phpbb use postfix, i see it in logs
[15:28] <zioproto> what do you see in the postfix logs ?
[15:28] <zioproto> if you do 'mailq' you see messages in the queue ?
[15:30] <SmOkE_RU> can we go private?
[15:32] <zioproto> better here
[15:32] <zioproto> so it is a easy problem
[15:32] <zioproto> postfix is running with SSL
[15:32] <zioproto> and probably the phpBB is not
[15:32] <zioproto> do you need encryption between phpBB and postfix ?
[15:33] <zioproto> just configure postfix to work without SSL if they are talking on localhost on the same serer
[15:33] <zioproto> server
[15:34] <SmOkE_RU> hm
[15:34] <SmOkE_RU> zioproto in main.cf i need disable ssl, right?
[15:35] <zioproto> yes, I dont know the extact line to change, but should be easy
[15:36] <zioproto> anyone that had built a openstack cloud archive package for xenial can look at this build log ? https://www.dropbox.com/s/40ps3wf849z3b2d/nova_13.1.2-0ubuntu2_amd64-20170228-1528.build?dl=0
[15:36] <SmOkE_RU> zioproto, ok i disable ssl, now phpbb in error says: SMTP-server not supported auth
[15:37] <zioproto> ok, there is an authentication problem
[15:37] <zioproto> just tell postfix to accept mail from localhost
[15:38] <zioproto> I think it is in main.cf write mynetworks = 127.0.0.0/8
[15:38] <SmOkE_RU> zioproto mydestination = localhost - already set
[15:38] <zioproto> what about mynetworks ?
[15:38] <SmOkE_RU> zioproto, mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
[15:39] <zioproto> from the log do you see what is the address that phpBB uses to connect to postfix ?
[15:40] <SmOkE_RU> zioproto, Feb 28 18:39:12 truecm postfix/smtpd[8037]: lost connection after EHLO from localhost[127.0.0.1]
[15:41] <zioproto> I think phpBB is trying to use a name and password even if it is not needed
[15:41] <zioproto> check the config
[15:41] <zioproto> make sure is not trying to use a name and passwd
[15:41] <SmOkE_RU> zioproto method of auth PLAIN or LOGIN? for phpbb
[15:42] <zioproto> I have no idea
[15:42] <SmOkE_RU> :LD
[15:42] <zioproto> you need to read the docs for phpbb
[15:45] <SmOkE_RU> zioproto i dont know how, but it works :D
[15:46] <SmOkE_RU> zioproto in phpbb i see error, but i recerve test email :D
[15:48] <zioproto> great
[15:50] <nacc> teward: err, sorry about that :) -- should have ^W one more time :)
[15:50] <SmOkE_RU> zioproto thanks for help :)
[16:00] <zioproto> no problem !
[16:05] <zioproto> I have no idea when I try to build nova, the build process tries to do 'add-apt-repository -y ppa:ubuntu-cloud-archive/mitaka-staging'
[16:11] <zioproto> coreycb, jamespage I found a problem with sbuild-mitaka
[16:11] <zioproto> when buidling from xenial
[16:11] <zioproto> --chroot-setup-commands="add-apt-repository -y ppa:ubuntu-cloud-archive/${release}-staging"
[16:11] <zioproto> this repo does not work for mitaka
[16:18] <frickler> zul: two more bugs we noticed when upgrading from Mitaka to Newton: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1668676 https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1668578, hope you can integrate that into https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1664306
[16:32] <zioproto> coreycb, I dont get how to build mitaka packages for Xenial. Looking at http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/dists/ and http://ppa.launchpad.net/ubuntu-cloud-archive/newton-staging/ubuntu/dists/ looks like there is not a Openstack release supporting both trusty and xenial. This breaks the logic in the scripts sbuild-mitaka
[16:35] <coreycb> zioproto, for mitaka you sould just use plain old sbuild
[16:35] <coreycb> zioproto, for xenial-mitaka, that is
[16:36] <zioproto> coreycb, how I complete this string ? add-apt-repository -y ppa:ubuntu-cloud-archive/${release}-staging"
[16:36] <zioproto> what ppa works for xenial mitaka ?
[16:36] <zioproto> If I remove it completely I get other build errors
[16:37] <zioproto> just give me please a sbuild command string that is known to work to build xenial mitaka, so I can build nova and then go on and test the nova release refresh :)
[16:38] <coreycb> zioproto, https://wiki.ubuntu.com/OpenStack/CorePackages
[16:38] <coreycb> zioproto, try using gbp
[16:39] <coreycb> zioproto, are you using our git repo for nova?
[16:39] <zioproto> debcheckout --git-track='*' nova
[16:40] <zioproto> clones git://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/nova
[16:40] <zioproto> cd nova ; git checkout stable/mitaka
[16:40] <zioproto> gbp buildpackage -S -us -uc
[16:40] <zioproto> I miss the right sbuild command to point to my dsc file
[16:40] <coreycb> zioproto, and what sbuild commands?
[16:40] <zioproto> that is in ../build-area
[16:41] <zioproto> if I remove adding the ppa
[16:41] <zioproto> the build fails
[16:41] <zioproto> wanna see the log ?
[16:41] <coreycb> zioproto, sure but let me see the sbuild commands first please
[16:41] <coreycb> zioproto, you don't need to do anything to the sbuild chroot
[16:42] <coreycb> zioproto, so you shouldn't be using a ppa or anything
[16:44] <zioproto> so usually I use the sbuild-mitaka
[16:44] <zioproto> http://paste.openstack.org/show/600803/
[16:44] <zioproto> I tried removing line 28
[16:45] <coreycb> zioproto, sbuild-mitaka is only for trusty
[16:46] <coreycb> zioproto, all you need for xenial is 'sbuild -A -d xenial-amd64 ../build-area/nova*.dsc'
[16:46] <zioproto> sbuild -d xenial-amd64 -A ../build-area/nova_13.1.2-0ubuntu2.dsc
[16:46] <zioproto> ok I am trying this one
[16:47] <teward> nacc: it happens :)
[16:47] <teward> nacc: GOOD news is it's out of proposed and into Zesty now so yay.  so i can rest nwo xD
[16:47] <teward> now*
[16:48] <nacc> teward: nice :)
[16:48] <zioproto> ok it looks like it is working
[16:48] <zioproto> coreycb, thanks !
[16:48] <teward> nacc: turns out that we were right to disable the test - Debian did the same for backports this time round.
[16:48] <coreycb> zioproto, yay :)
[16:48] <nacc> teward: awesome, that's good
[16:49] <teward> nacc: oh how I love the evils of 'merging from scratch' :P
[16:49] <teward> though it was necessary due to the severity of how out of sync we were :P
[17:00] <zioproto> bye everyone, see you tomorrow !
[17:15] <rbasak> nacc: ping
[17:19] <nacc> rbasak: pong
[17:19] <rbasak> nacc: IRC? Hangout?
[17:19] <nacc> rbasak: IRC is fine
[17:19] <rbasak> I'm not sure I understood the context.
[17:19] <nacc> rbasak: so for the importer -- i did a quick check
[17:19] <nacc> rbasak: of the ones that failed to import, about 3 or 4 do work now, so it could be network issues, etc.
[17:19] <nacc> rbasak: not 100% on those (yet)
[17:20] <nacc> rbasak: but for the rest that still fail, it's all the FF issue for the -devel branches
[17:20] <rbasak> OK
[17:20] <nacc> rbasak: are you ok with me implementing the merge idea?
[17:20] <nacc> rbasak: that is, the -devel branches stay FF by merging the new commit and the old head?
[17:21] <rbasak> Yes, but I think we need to be consistent. So we should bump the -devel branch on every version, not just at the end.
[17:21] <rbasak> I don't know if that'd be quite a big refactoring?
[17:21] <rbasak> But otherwise the data structure obtained would be dependent on timing of imports, which I think would be bad.
[17:22] <nacc> so the -devel branch would become quite a bit 'noisier', but would be be correct
[17:22] <nacc> it will also slow it down a bit, if it has to do the check for every pocket on every import
[17:22] <rbasak> Yeah
[17:22] <rbasak> If refactoring, please take my refactoring branch first.
[17:24] <rbasak> nacc: it's just a local and inexpensive check though, no?
[17:24] <nacc> it's not entirely inexpensive, it has to look at each head in a given series and decide which is 'latest'
[17:25] <nacc> refactored, i might be able to restrict it to the affected series, so it might not be a big deal
[17:27] <rbasak> OK
[17:30] <nacc> rbasak: the only other concenr is the abvoe chagne means existing imports are 'incorrect' or would differ from from-scratch imports
[17:31] <nacc> rbasak: i think that's unavoidable for now, though
[17:31] <rbasak> Agreed on both.
[17:31] <nacc> rbasak: ack, thanks!
[17:31] <rbasak> Incidentally, I had a thought related to this.
[17:31] <nacc> sure
[17:32] <rbasak> Adopting upload tags (or not) also mutates the commit hashes.
[17:32] <rbasak> And upload tags may arrive late, in which case they won't be adopted.
[17:32] <rbasak> So perhaps we could use "git notes" to add a note to tell us whether a particular upload tag has been seen or not, and whether it was adopted or not.
[17:32] <nacc> yes, i think we discussed this at the sprint
[17:32] <nacc> sure
[17:33] <rbasak> Then the importer could run in a mode where it only adopts upload tags that were previously adopted.
[17:33] <rbasak> And then third parties have the option of not mutating things.
[17:33] <nacc> we also discusssed *always* taking the upload tag, but there might be a diff between it an and the import tag (as opposed to ignoring them now)
[17:33] <nacc> true
[17:33] <teward> rbasak: not sure if you saw my highlight from last night, nginx merge is completed, and now out of zesty-proposed and in zesty proper.
[17:33] <teward> after fixing one of the autopkgtests heh
[17:34] <rbasak> teward: I did. I thought I replied. But if not, thank you!
[17:34] <nacc> rbasak: let's hold off on that for now, if taht's ok with you? we can talk about it next week. I'll file it as a bug if it's not already
[17:34] <rbasak> nacc: sure. Not suggesting we have to do that now.
[17:34] <teward> rbasak: you may have but it gets buried under the cruft i see here - limited RAM on my system running my boucer
[17:34] <rbasak> Just thought I'd mention it while we were talking about mutations.
[17:34] <teward> < 128MB, so I have very low scrollback limits :)
[17:34] <nacc> rbasak: ack
[17:35] <teward> rbasak: I'll update the package page I created for the triage stuff to indicate "New Features as of Zesty:" section.  And some "Runtime Notes" about the fPIE/fPIC impact on 32bit systems
[17:35] <teward> which is noticeable but not insane
[17:36] <nacc> teward: do we want 'new features' in the release notes?
[17:37] <teward> nacc: We're going to have a good sized blurb for Zesty about the release notes
[17:37] <teward> because we have dynamic module support now
[17:38] <teward> and a reorg of the packages because of binary changes, etc.
[17:38] <teward> as for "new" features, the big one's dynamic module support, but we can have "More Details" on the ServerTeam/Nginx page.
[17:38] <teward> since that's now a thing :P
[17:38] <teward> the big one's going to be fPIE/fPIC and "Performance Notes"
[17:39] <nacc> teward: sounds good :)
[17:39] <teward> because with just fPIE there's not a huge performance hit, with fPIE+fPIC which is needed this time around, we have a higher impact this time around
[17:39] <teward> (though we've been rolling fPIE since Trusty I think, so that impact is already known.  No, I don't have exact benchmarks unfortunately.)
[20:22] <teward> rbasak: nacc: https://wiki.ubuntu.com/ServerTeam/NGINX/ZestyZapus - Thoughts?
[20:26] <fullstop> Hi all.  Is there something different with 16.04 where it fills up /boot with kernels automatically?  I don't have unattended upgrades enabled, but it seems to be doing it anyway.
[20:28] <fullstop> it appears that unattended upgrades for security related things was somehow enabled.
[20:36] <scottjl> fullstop: look at /etc/apt/apt.conf.d/50unattended-upgrades and see what's been uncommented
[20:36] <scottjl> by default kernels aren't upgraded though
[20:36] <fullstop> yes, I see why it's doing it..
[20:36] <fullstop> but I have no idea how this was set.
[20:37] <scottjl> someone/something changed it.
[20:37] <fullstop> and it's enabled on all the 16.04 servers we have here.
[20:37] <scottjl> puppet?
[20:37] <scottjl> salt?
[20:37] <fullstop> but none of the 14.04 or 12.04 (which are slated for retirement)
[20:37] <fullstop> salt
[20:37] <fullstop> but the same states are used on all.
[20:37] <scottjl> none of my 16.04 servers are like that in a fresh setup
[20:38] <scottjl> check your salt config then?
[20:38] <scottjl> that's not standard 16.04 behavior
[20:38] <fullstop> let me find some non-salt ones.
[20:38] <sarnold> I thought we made that the default for 16.04?
[20:38] <scottjl> kernel upgrades? not automatic. unless it's new with 16.04.02?
[20:39] <scottjl> well at least. mine aren't doing it (thank god)
[20:39] <fullstop> all of mine are
[20:39] <fullstop> even non-salt
[20:40] <fullstop> this kind of sucks because /boot has run out of space on many of them.
[20:43] <rbasak> unattended-upgrades is enabled by default since 16.04 I think.
[20:43] <rbasak> But if it causes /boot to fill up, that's bad and we need to fix that.
[20:43] <rbasak> teward: looks good!
[20:44] <fullstop>  /boot is pretty small with the default settings.  It can hold just a few kernels before getting plugged up, which prevents apt from really working at all until you manually get involved and clean it up.
[20:45] <fullstop> If the server were restarted before it filled, I'm still not certain that old kernels would be purged.
[20:45] <teward> rbasak: thanks, feel free to improve :)
[20:45] <scottjl> i gave up making /boot a separate partition years ago. it's just part of /
[20:45] <sarnold> /etc/apt/apt.conf.d/01autoremove-kernels and /etc/kernel/postinst.d/apt-auto-removal comments claim it can save upwards of four kernels
[20:47] <sarnold> funny enough my laptop appears to have six kernels, ~300 megs of /boot and my server seven, for ~385 megs of /boot
[20:47] <fullstop> sarnold: surely your laptop has been rebooted recently.  When are the old ones to be removed?
[20:48] <sarnold> fullstop: you're right, rebooted 46 days ago
[20:48] <fullstop> I'm only at 40. ;-)
[20:48] <fullstop> but, shhh, the laptop is arch.
[20:53] <nacc> teward: +1 looks good
[20:54] <teward> :)
[20:54] <sarnold> man I can't figure out when APT::NeverAutoRemove actually works :/
[20:55] <sarnold> C++ is just so alien tome
[20:55] <teward> heh
[20:55] <fullstop> that makes sense if it's "alien tome" or "alien to me"
[20:55] <sarnold> hehe so it does :)
[22:13] <ZoomZoomZoom> Hi! Is anyone running qbittorrent-nox behind reverse proxy? I can't get it to work with lighttpd 1.4.35
[22:58] <compdoc> when I ssh into my servers, they have often say they need a restart. do you think its sets to auto install security updates? how would I disable that?
[22:58] <compdoc> -have
[22:59] <sarnold> why?
[22:59] <sarnold> I think the way to disable it is via editing /etc/apt/apt.conf.d/50unattended-upgrades
[23:08] <rbasak> Or remove the unattended-upgrades package.
[23:09] <sarnold> there's too many intersecting and interacting pieces :)
[23:09] <compdoc> when I log in and see it in that state, it makes me wonder if I forgot to restart it the last upgrade. I upgrade them on a regular basis and just dont like seeing it in that state. and dont like stuff installed until I am there to make sure it goes well
[23:10] <sarnold> you can always check uptime output to see how long it's been since the last reboot
[23:11] <compdoc> too late