/srv/irclogs.ubuntu.com/2017/02/28/#ubuntu-server.txt

tewardso, stupid question but where are the autopkgtests stored00: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:18
naccteward: how do you mean?00:19
tewardnacc: well, trying to ID what's going on with nginx00:19
naccteward: the tests themselves are in d/t/control00:19
tewardthere's two regressions in diaspora-installer but that's something on their side not nginx00:19
tewardah OK00:19
tewardnacc: looks like i never had to touch them before :p00:19
tewardi see some nginx fails today, gotta see what that's about :P00:19
tewardoh hm, ssl curves00:22
teward*checks Zesty*00:22
tewardnacc: any idea how to check what ECDH curves are supported on Zesty?00:24
naccteward: i have no idea what that acronym is :)00:24
tewardi'll ask OpenSSL then00:25
Alessandro_teward: try "openssl -v" IIRC00:26
trippeh_for curves, openssl ecparam -list_curves00:27
tewardwell I know what I have to do.  I have to drop a curve...00:28
tewardwho do i prod to change what is acceptable or not for a given test?00:28
tewardautopkgtest* on the migration tracking system?00:28
naccteward: you update the test00:29
naccteward: wait, what do you mean 'acceptable'? all tests have to pass00:29
tewardnacc:  I.E. "always failed" or 'Ignored once"00:30
naccteward: that's the release team, i believe00:30
tewardOK00:30
tewardi'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:31
naccteward: always failed is typically not set -- it's something autopkgtest runner recognizes00:32
tewardmmm00:32
naccteward: 'failure ignored' is what gets set00:32
tewardnacc: 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 interim00:32
naccteward: so this is a nginx test?00:32
tewardbecause i think they added a curve we don't support that got in from Experimental00:33
tewardnacc: well...00:33
tewardnacc: two problems:00:33
teward(1) NGINX tests fail with Regression, I think it's because there's a curve added to the tests00:33
naccteward: it might be apporpirate to add delta is some test depends ona  feature we odn't support00:33
teward(2) a *different* autopkgtest errors out00:33
tewardbut *not* because of nginx00:33
naccteward: let me look00:33
tewardnacc: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nginx00:33
tewarddiaspora-installer is the only other one I am not looking into but those errors look like it's a repository problem *not* related ot nginx00:34
naccteward: ack, so you're saying we should skip the ec-x25519 test on ubuntu?00:34
tewardnacc: i'm saying "probably", but I need to figure out its origin00:34
tewardfirst00:34
naccteward: 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/control00:34
tewardnacc: I want to figure out if it's from Debian Exp. or not first00:35
naccteward: ack00:35
tewardthat said I need a Debian image too to test00:35
naccteward: i'm looking at the other one00:35
naccteward: lxc launch images:debian/sid/amd6400:35
tewardif it works in Debian but not Ubuntu, then it's a delta that we can comment out for the test00:35
tewardnacc:  already ahead of you00:35
naccteward: and/or check ci.debian.net00:35
tewardbut i'm installing the ubuntu-server image in an lxc container.00:35
tewardor rather, installing that metapackage00:35
tewardso i have a 'standard' set of crap lol00:36
nacchttps://ci.debian.net/packages/n/nginx/unstable/amd64/00:36
naccseems rather green00:36
tewardnacc:  yeah but i want to make sure that this test is 'new'00:36
tewardand 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 something00:36
tewardbeing thorough00:37
naccteward: http://autopkgtest.ubuntu.com/packages/nginx/zesty/amd64 fwiw as well00:37
naccteward: that test wasn't present in the last upload to z-p, it seems00:38
naccteward: it is present in debian00:38
tewardnacc: the 'last upload' to z-p was a half-merge00:38
tewardit was HTTP/2 fixes ahead of the actual merge from Debian00:38
tewardthe 'latest' that got run had to wait for Perl to get out first00:38
tewardthen it ran the autopkgtsts00:38
naccack00:38
tewardso these are "new" tests that are originated from Debian since.. what, 1.10.0, so the Xenial cycle?00:39
tewardyeah I dont' see that curve in the OpenSSL curve lists00:39
tewardfor Ubuntu anyways00:39
tewardgonna 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 Delta00:39
trippeh_our openssl is too old :)00:40
teward:P00:40
tewardi'm almost certain it is00:41
tewardyay Debain container time to update you :p00:41
tewards/Debain/Debian/00:43
teward*notes to update his autocorrect*00:43
naccteward: i retriggered those two diaspora failures, i think they are going further, but we'll see00:45
tewardOK00:46
tewardnacc: thanks.00:46
tewardhuh interesting I don't see that SSL curve in Unstable either o.O00:46
tewardECDH*00:46
tewardconfirmed the core issue00:47
teward# nginx -T00:47
tewardnginx: [emerg] Unknown curve name "X25519" (SSL:)00:47
tewardnginx: configuration file /etc/nginx/nginx.conf test failed00:47
tewardin Zesty00:47
tewardbut works fine in Unstable00:47
tewardso that's just a curve we don't accept.00:47
tewards/accept/have/00:47
trippeh_maybe it doesnt list these newfangled non-ECDH curves in ecparam00:47
tewardtrippeh_: it might not00:48
trippeh_it is new in openssl 1.1 fwiw00:48
tewardah, that would explain that00:48
naccteward: yeah, i think those two diaspora failures will clear on their own now00:48
tewardwe don't roll 1.1 yet I don't think00:48
tewardnacc: 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
naccteward: no, 1.0.2g on zesty00:49
naccteward: add a delta, each test is a stanza in d/t/control00:49
tewardyes but define "delta" as in drop the test or comment out the entire test?00:49
naccteward: 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 it00:49
naccteward: totally up to you00:50
naccteward: if we did everything with an SCM, then i'd say delete it, but it's a little more self-documenting if commented out00:50
tewardnacc: I actually have a copy of the packaging in a GitLab instance of my own, so it's sorta version controlled.00:50
naccteward: and since you are the maintainer, i think that's ok then to just drop it and you'd know00:51
tewardnacc: yep, well I'm just going to remove it from d/t/control but leave the test "in there"00:51
naccteward: 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 think00:51
tewardand comment accordingly.00:51
naccteward: yeah exactly00:51
tewardnacc: indeed.  Though the team tends to poke me for testing first lol00:51
naccteward: :)00:51
trippeh_"Unknown error executing apt-key" - thanks, apt-get00:53
naccheh00:54
tewardoops i forgot to put bugfix-only in the changelog fff00:56
teward'accepted' oh cool.00:56
tewardnacc: I could probably alter the test to try and test the OpenSSL version first.  But I'm lazy :P00:58
tewardI'll just yell at Debian for making me increase the delta :P00:58
tewardagain.00:58
tewardnacc: looks like the diaspora-installer tests didn't blow up this time heh00:58
tewardsince now it's not erroring on the gems xD00:59
tewardnacc: 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
tewardif you know :)01:00
trippeh_ah lol, since I was chrooting from a EL7 install, PATH lacked /bin ...01:11
trippeh_"wait! no grep!??"01:11
naccteward: you can run an autopkgtest against a specific PPA build, one sec01:12
naccteward: https://wiki.ubuntu.com/ProposedMigration "Testing aginsta a PPA"01:12
tewardnacc: yeah, trying to see where it reports that01:16
tewardnacc: apparently I'm "not authorized" to see the report.  or it hasn't run yet, I don't see it queued either.01:17
naccteward: i can run it for you probably01:23
naccteward: if you have the ppa set up01:23
naccteward: and diaspora passed now (excuses is still pending an update)01:24
tewardnacc:  it'll likely rerun and/or explode01:26
tewardnacc: i was able to *request* the build against the nginx stable PPA.  I can't see if it's pending or not01:26
tewardthat's all.01:26
tewardIt didn't say I didn't have privs. to request.01:26
tewardprobably since i'm the admin for that 'group' PPA :P01:26
naccteward: oh you'd see it running in the autopkgtest running page01:28
nacchttps://autopkgtest.ubuntu.com/running01:28
naccteward: so you uploaded a new version, anyways, right?01:29
naccas i see tests running for ubuntu301:29
tewardnacc: yes.01:47
tewardnacc: -1ubuntu3 has a fix for the autopkgtests.01:47
tewardand was already accepted somehow.01:47
tewardit'll probably *still* need pushed by the release team01:47
tewardnacc: can you check if there's nginx tests against 1.10.3-1+zesty0 or similar in a PPA?01:49
tewardbeing run now01:49
tewardI expect that to blow up actually lol01:49
teward(in a PPA)01:50
teward1.10.3-0+zesty0 actually heh01:50
tewardblah i'm tired01:50
naccteward: no, there's only feature freeze on, so it shouldn't need any help in this case01:51
tewardOK01:51
naccteward: and yes, i now see the zesty0 running01:51
naccagainst your ppa01:51
nacchttp://autopkgtest.ubuntu.com/running#pkg-nginx01:51
tewardcool.01:52
tewardnacc: yep i see it working thanks01:59
naccteward: the only annoyance is you can't see the logs fully until the test finishes and copies over02:00
naccteward: which is quite a bit slower than the normal autopkgtests i've found02:00
tewardnacc: Indeed, though my PPA update workflows are not ones I regularly need to poke so :P02:15
teward(nor do I need rapid testing)02:15
tewardnacc: looks like commenting out that autopkgtest solved the failures for nginx, let's just hope diaspora doesn't blow up in our face again :P02:16
tewardwth 'nova' regression02:16
tewardnacc: 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
tewardit *looks* to me like it's an openscsi / erlang issue02:17
tewardnot even sure *why* nova is triggered by the nginx test though02:18
naccteward: i'd guess not your issue02:44
naccteward: i'll retry it02:44
naccteward: although i agree, i don't know why nova ran02:45
naccteward: in fact, i don't see anything installed from -proposed at all except02:46
tewardnacc: 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:31
tewardnacc: ^.^ nginx has finally left -proposed and landed in Zesty03:47
tewardI can rest easy!03:47
tewardServer Team: I can safely say that the NGINX merge has been completed.  Starting with Zesty, we now have ***dynamic module support***04:14
tewardfuture merges should not be as hellish anymore :)04:14
teward(cc rbasak, jgrimm, sarnold because reasons, anyone else who cares) ^04:15
sarnoldteward: nice :D now to relax! :D04:19
tewardsarnold: truth!04:20
fricklerjamespage: did you take a look at building kraken yet? (ceph-11.2.0) would it still seem feasible to get it into zesty?07:00
=== caribou_ is now known as caribou
jamespagefrickler: I did take a peek but then discussed with sage; we don't normally drop the interim releases into Ubuntu08:20
jamespagefrickler: so next drop with be luminous in the spring - probably for 17.1008:20
=== disposable3 is now known as disposable2
fricklerjamespage: o.k., thx for the info09:01
DK2after installing a server with 2 TB disks i get "cannot get disk parameters" when booting the hard drive09:05
DK2the installation seems to be fine when checking via a live cd09:06
DK2what could be the cause for it?09:06
DK2does the server does not see the drives?09:06
=== tinwood_swap is now known as tinwood
DK2figured it out, the bootvolume was not set09:17
sarnoldwhere did you set it?09:18
=== JanC is now known as Guest13435
=== JanC_ is now known as JanC
zioprotohello there. I would like to make a refresh of the nova package09:30
zioprotothis is different from when I just add a patch in debian/patches09:30
zioprotothere is a standard procedure to refresh the upstream version ?09:30
lordievaderGood morning.09:42
sarnoldzioproto: 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 needed09:51
zioprotosarnold, ok, so I have to wait the nova folks to create the tarball. I though I could import a git commit from the nova repo09:54
sarnoldzioproto: 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 :)09:57
rbasakteward: thank you!10:49
maswanHm. 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/166855711:43
ubottuLaunchpad bug 1668557 in linux (Ubuntu) "Write performance regression severely affecting hpsa controllers" [Undecided,Confirmed]11:43
cpaelzermaswan: from 3.18.18 to 3.18.21 is already a good narrow diff to look for12:03
cpaelzermaswan: you said simple dd test is driving this12:03
maswanyup12:03
maswanor, well, my collegue across the corridor12:03
cpaelzermaswan: could you provide the exact command and (to start) an output of "iostat -xtdk 5" that was running over the time12:03
maswansure12:04
maswanok if I limit iostat to just the relevant device?12:06
cpaelzermaswan: sure12:06
maswan(lvm for OS stuff, so lots of dm-*)12:06
cpaelzerit is just a start to get a feeling where we should go to12:06
cpaelzerif you write only to a single device, just that12:06
cpaelzerif you write to an LVM or such just the related devices to your workload12:07
cpaelzerlike top lvm, and the PVs that matter12:07
maswanno, we write to xfs on /dev/sdb12:07
maswanfor data12:07
maswanlvm for OS on /dev/sda (different slice, hpssacli output is already attached)12:08
cpaelzerI'm still reading through the attachments12:08
* maswan nods12:08
maswansoon you'll get another. :)12:08
cpaelzerperfect would be to get the iostat for just the two god/bad kernels that are close12:09
maswanbad case is in, rebooting for good old kernel. :)12:12
maswanhm. one case we haven't tried so far in pinning the blame is dd:ing directly to the block device.12:14
cpaelzermaswan: raw access and/or an alternative fs (like ext4) can be worth a shot for sure12:15
maswanlet me get iostat for the fast case first though12:15
cpaelzerabsolutely12:15
maswanhm. do you want iostat for the first-good mainline kernel too?12:15
cpaelzeras 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
maswanyes12:16
cpaelzerthat is minimal delta in terms of patches12:16
maswanWill do that, just ran it on whatever it was booted on first.12:16
cpaelzerso I'd compare those until we have a reason to look further12:16
maswanand then thought harder of what would be best for comparison. :)12:16
cpaelzerto pick those two will avoid us seeing a lot of "other" noise in logs12:16
maswanho hum12:24
maswanhp servers are slow to boot12:24
patdk-lapslow is an understatement12:24
maswanI heard quite a bit of grumbling yesterday when Nikke was bisecting kernel versions and had to wait for a reboot between each test12:25
maswanThere, iostat and command line output from the last fast and first slow 3.18.2* kernels12:29
* cpaelzer reading12:30
maswanand on the slow kernel, pretty much identical performance for dd if=/dev/zero of=/dev/sdb bs=256k, possibly slightly slower12:31
cpaelzerit seems it no more recognized this as a raid12:36
cpaelzerso the block device layer is holding back requests to merge them12:37
cpaelzermaswan: you see write reqeust merges per sec ~50012:37
cpaelzermaswan: and due to that ~8x bigger write requests12:37
cpaelzermaswan: which in your case sucks, as the raid below will split it along its stripe size again12:37
cpaelzeror would have handled all of them in cache already12:37
maswancpaelzer: that could indeed explain the suckage12:38
cpaelzermaswan: you also see that while rq-size is x8 the write await is x6012:38
cpaelzerso you can be happy that it is "only" 1/2 instead of 1/7.5 speed12:38
cpaelzernow lets start to look for changes12:38
* cpaelzer reading diffs12:39
maswanthanks12:39
cpaelzermaswan: IIRC somewhere in /sys there were attrivutes for the devices that flag such things (spinning, cached, ...)12:39
cpaelzermaswan: while I look for code if you could look in ...12:39
* cpaelzer is searching12:39
cpaelzermaswan: 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); done12:42
cpaelzerthere should be no diff between stable kernels, if there is that is another indicator where to look12:43
maswanyup, working on it12:46
maswanaka waiting for reboot12:46
cpaelzermaswan: also you go through page cache with your test (intentionally?) - once time permits you could try if all is the same with oflag=direct12:48
cpaelzeryet the request merging is a hotter lead which should be pursued first12:48
cpaelzerOTOH the reboots seems to be what slows you down, so we might collect what we can do each cycle12:48
maswanwell, the first test of dd into a file on xfs is very close to the production case12:48
maswanwhich is taking large files from network onto disk (and then spooling them to tape, or the other way around)12:49
maswanbefore ingest rate it could handle was line speed 10GE12:49
cpaelzerok, if close to the real cae lets stick to that for now12:50
maswanwell, single file all zeros is already a simplifcation of it. but sure, I can try some oflag=direct while I'm booted anyway. :)12:50
maswanonly diff is max_sectors_kb, 4096->51212:52
maswanattaching fastmode output to the bug now12:52
cpaelzerbut well that is it maswan12:52
cpaelzerthat is the critical value12:53
* maswan nods12:53
cpaelzerand the size close to 8k is in 512b sectors to 4096 (kb) matches the 8*51212:54
maswanso probably no need for more narrow dd test cases12:54
cpaelzermaswan: exactly12:54
cpaelzermaswan: I still struggle to see the patch that causes it, but there is a workaround for you to test12:54
cpaelzermaswan: boot the slow kernel and set 512 into that calue12:54
cpaelzerhmm12:54
cpaelzerwas that a writable one12:54
cpaelzeruh it might not be12:54
maswanseems to be writeable12:55
maswanlets see12:55
cpaelzermaswan: if you are tuning later for raids you might also consider setting /sys/class/block/sdb/queue/rotational to 012:56
cpaelzerlocality with so many disks is kind of inexistant12:57
cpaelzerbut one change at a time12:57
cpaelzerlet me know if setting the smaller max_sectors_kb helped12:57
cpaelzermaswan: I think I found the change http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=20d74bf29cfae86649bf1ec75038c79a9bc5010f13:01
cpaelzerit 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 now13:02
cpaelzermaswan: let me know how setting 512 worked for you13:02
maswancpaelzer: yup, that does indeed make stuff fast on the newer kernel13:04
cpaelzeryeah13:04
cpaelzermaswan: for more tuning, have you tried the rotational=0 as well?13:05
cpaelzermaswan: TL;DR IMHO the controller always announces 4k, instead of being smart and on a certain raid setup drop to the stripe or sector size13:06
cpaelzermaswan: newer linux "fixes" now pick these values up correctly which makes it slower for you :-/13:06
cpaelzermaswan: interested in the rotational flag13:06
maswanrotational=0 makes very little difference13:06
cpaelzerit should save cpu time13:07
maswanmaybe 5-10% for kb=51213:07
cpaelzerI come from mainframes, every cycle is expensive :-)13:07
cpaelzerOr make it green, save energy :-)13:07
cpaelzermaswan: 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
cpaelzermaswan: if so I'd close the bug report with that stated13:08
maswanWe'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:09
cpaelzermaswan: 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 worth13:10
cpaelzermaswan: if you have contacts at least ask them13:10
maswannot really13:10
maswanhm. I guess they might be reading linux-raid though, I'm a long time lurker in there13:11
maswanPlease close it with as much info you can think of on the causes etc13:11
cpaelzermaswan: done13:13
cpaelzermaswan: you might use the bug as link in your post13:13
maswanYeah, that was my intention13:14
cpaelzermaswan: I'd be pleased if you could set my user to cc, email is in the launchpad account I posted to the bug13:14
maswanSure!13:14
* cpaelzer is happy that his 12 year old thesis knowledge still applies to todays real world cases :-)13:16
zioprotozul, hello there, are you refreshing some nova stuff today ?13:16
maswanhm. cc:ing a googled-up hpsa driver contact address too13:25
zioprotoguys, 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:32
zioprotowhen I refresh the nova tag13:33
zioprotoshould I git checkout in detached head the current latest tag, then make a new commit, and tag it ?13:33
zioprotothen I can merge that new tag into stable/mitaka13:33
zioprotois that the idea ?13:33
zioprotoI think basak told me this in the past, where are the logs of this IRC channel ?13:36
Slashmanhello, I have "/usr/lib/accountsservice/accounts-daemon" at 100% CPU (on one thread), anyway to understand why? (ubuntu xenial)13:38
cpaelzerSlashman: you might start it with --debug --replace to get a log what it is doing - although I don't know how disruptive that might be13:46
cpaelzerSlashman: eventually it is supposed to implement a dbus service, so maybe some dbus monotoring might do it as well13:46
cpaelzerSlashman: but my dbus-foo isn't good enough to guide you n that13:46
Slashmancpaelzer: this server has only one main service : proftpd, I guess that is somewhat related13:47
jamespagezioproto: the tool you are looking for is gbp import-orig13:55
jamespagethat allows you to import a new upstream release13:56
zioprotoI managed to do it with git13:57
zioprotoI just added the git remote of the upstream13:57
zioprotoand I did13:57
zioprotogit checkout tagname -- .13:57
zioprotothen I had to commit manually13:57
zioprotowhen 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:57
zioprotoBasically I am trying to create a commit like this one 6de2684e69b8945042c32d185307f10fcf50b24e13:58
maswancpaelzer: Btw, Nikke is not quite agreeing that this isn't a hpsa driver bug, giving crappy performance by default.14:01
maswanbut I guess that's more useful in a discussion with upstreams14:01
zioprotocoreycb, is there already a LP bug for the new nova release ? https://review.openstack.org/#/c/438570/14:04
coreycbzioproto, hello I would guess so. zul is working on stable point releases this week, so he would know better than me.14:06
zioprotozul, we have a race between ubuntu making the SRU packages and nova pushing his 13.1.3 tag :)14:07
zioprotoplease make sure ubuntu packages will be at 13.1.314:07
zioprotouhm, I am not sure how to update the pristine-tar branch14:14
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 group14:18
FrEaKmAn_but that user still cannot write to that folder... any ideas?14:18
FrEaKmAn_I logged out, restarted everything...14:18
zioprotook I did something like pristine-tar commit ../nova_13.1.3.orig.tar.gz 13.1.314:22
zioprotoahhhhh14:57
zioprotoI restarted from scratch14:57
zioprotogbp import-orig --upstream-version=13.1.3 --debian-branch=stable/mitaka --merge --pristine-tar ../nova_13.1.3.orig.tar.gz14:57
Slashmancpaelzer: looks like my issue is the same as https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/131683014:59
ubottuLaunchpad bug 1316830 in accountsservice (Ubuntu) "/usr/lib/accountsservice/accounts-daemon :: memory and CPU time leak" [High,Confirmed]14:59
zioprotoguys is this something valid in Xenial ? 'add-apt-repository -s ppa:ubuntu-cloud-archive/tools'15:08
zioprotoI dont see any xenial here: http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/dists/15:09
SmOkE_RUÂñåì ïðâèåò, êòî ìîæåò ïîìî÷ü ñ ïîñòôèêñîì?15:14
zioprotojamespage, http://paste.openstack.org/show/600790/ ?15:14
SmOkE_RUКто-то с постфиксом может помочь?15:20
zioprotoSmOkE_RU, если вы можете говорить по-английски, я могу помочь вам с постфиксе15:22
zioproto(google translate)15:22
SmOkE_RUzioproto i think i can)15:22
zioprotoso just ask your question in English, it will be easier to get an answer :)15:23
SmOkE_RUzioproto i am install postfix for forum phpBB, and cant send emails, in terminal postfix sends mails15:24
=== iliv_ is now known as iliv
zioprotoare you sure phpBB is using postfix to send the mails ?15:26
zioprotosometimes php programs call their out php mta functions15:26
SmOkE_RUzioproto yes, phpbb use postfix, i see it in logs15:27
zioprotowhat do you see in the postfix logs ?15:28
zioprotoif you do 'mailq' you see messages in the queue ?15:28
SmOkE_RUcan we go private?15:30
zioprotobetter here15:32
zioprotoso it is a easy problem15:32
zioprotopostfix is running with SSL15:32
zioprotoand probably the phpBB is not15:32
zioprotodo you need encryption between phpBB and postfix ?15:32
zioprotojust configure postfix to work without SSL if they are talking on localhost on the same serer15:33
zioprotoserver15:33
SmOkE_RUhm15:34
SmOkE_RUzioproto in main.cf i need disable ssl, right?15:34
zioprotoyes, I dont know the extact line to change, but should be easy15:35
zioprotoanyone 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=015:36
SmOkE_RUzioproto, ok i disable ssl, now phpbb in error says: SMTP-server not supported auth15:36
zioprotook, there is an authentication problem15:37
zioprotojust tell postfix to accept mail from localhost15:37
zioprotoI think it is in main.cf write mynetworks = 127.0.0.0/815:38
SmOkE_RUzioproto mydestination = localhost - already set15:38
zioprotowhat about mynetworks ?15:38
SmOkE_RUzioproto, mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/12815:38
zioprotofrom the log do you see what is the address that phpBB uses to connect to postfix ?15:39
SmOkE_RUzioproto, Feb 28 18:39:12 truecm postfix/smtpd[8037]: lost connection after EHLO from localhost[127.0.0.1]15:40
zioprotoI think phpBB is trying to use a name and password even if it is not needed15:41
zioprotocheck the config15:41
zioprotomake sure is not trying to use a name and passwd15:41
SmOkE_RUzioproto method of auth PLAIN or LOGIN? for phpbb15:41
zioprotoI have no idea15:42
SmOkE_RU:LD15:42
zioprotoyou need to read the docs for phpbb15:42
SmOkE_RUzioproto i dont know how, but it works :D15:45
SmOkE_RUzioproto in phpbb i see error, but i recerve test email :D15:46
zioprotogreat15:48
naccteward: err, sorry about that :) -- should have ^W one more time :)15:50
SmOkE_RUzioproto thanks for help :)15:50
zioprotono problem !16:00
zioprotoI 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:05
zioprotocoreycb, jamespage I found a problem with sbuild-mitaka16:11
zioprotowhen buidling from xenial16:11
zioproto--chroot-setup-commands="add-apt-repository -y ppa:ubuntu-cloud-archive/${release}-staging"16:11
zioprotothis repo does not work for mitaka16:11
fricklerzul: 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/166430616:18
ubottuLaunchpad bug 1668676 in nova (Ubuntu) "Newton package needs to bump dependency on python-rfc3986" [Undecided,New]16:18
ubottuLaunchpad bug 1668578 in neutron (Ubuntu) "Newton package needs to bump dependency on python-pecan" [Undecided,New]16:18
ubottuLaunchpad bug 1664306 in nova (Ubuntu Yakkety) "newton stable SRU releases" [Undecided,New]16:18
zioprotocoreycb, 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-mitaka16:32
coreycbzioproto, for mitaka you sould just use plain old sbuild16:35
coreycbzioproto, for xenial-mitaka, that is16:35
zioprotocoreycb, how I complete this string ? add-apt-repository -y ppa:ubuntu-cloud-archive/${release}-staging"16:36
zioprotowhat ppa works for xenial mitaka ?16:36
zioprotoIf I remove it completely I get other build errors16:36
zioprotojust 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:37
coreycbzioproto, https://wiki.ubuntu.com/OpenStack/CorePackages16:38
coreycbzioproto, try using gbp16:38
coreycbzioproto, are you using our git repo for nova?16:39
zioprotodebcheckout --git-track='*' nova16:39
zioprotoclones git://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/nova16:40
zioprotocd nova ; git checkout stable/mitaka16:40
zioprotogbp buildpackage -S -us -uc16:40
zioprotoI miss the right sbuild command to point to my dsc file16:40
coreycbzioproto, and what sbuild commands?16:40
zioprotothat is in ../build-area16:40
zioprotoif I remove adding the ppa16:41
zioprotothe build fails16:41
zioprotowanna see the log ?16:41
coreycbzioproto, sure but let me see the sbuild commands first please16:41
coreycbzioproto, you don't need to do anything to the sbuild chroot16:41
coreycbzioproto, so you shouldn't be using a ppa or anything16:42
zioprotoso usually I use the sbuild-mitaka16:44
zioprotohttp://paste.openstack.org/show/600803/16:44
zioprotoI tried removing line 2816:44
coreycbzioproto, sbuild-mitaka is only for trusty16:45
=== ashleyd is now known as ashd
coreycbzioproto, all you need for xenial is 'sbuild -A -d xenial-amd64 ../build-area/nova*.dsc'16:46
zioprotosbuild -d xenial-amd64 -A ../build-area/nova_13.1.2-0ubuntu2.dsc16:46
zioprotook I am trying this one16:46
tewardnacc: it happens :)16:47
tewardnacc: GOOD news is it's out of proposed and into Zesty now so yay.  so i can rest nwo xD16:47
tewardnow*16:47
naccteward: nice :)16:48
zioprotook it looks like it is working16:48
zioprotocoreycb, thanks !16:48
tewardnacc: turns out that we were right to disable the test - Debian did the same for backports this time round.16:48
coreycbzioproto, yay :)16:48
naccteward: awesome, that's good16:48
tewardnacc: oh how I love the evils of 'merging from scratch' :P16:49
tewardthough it was necessary due to the severity of how out of sync we were :P16:49
zioprotobye everyone, see you tomorrow !17:00
rbasaknacc: ping17:15
naccrbasak: pong17:19
rbasaknacc: IRC? Hangout?17:19
naccrbasak: IRC is fine17:19
rbasakI'm not sure I understood the context.17:19
naccrbasak: so for the importer -- i did a quick check17:19
naccrbasak: of the ones that failed to import, about 3 or 4 do work now, so it could be network issues, etc.17:19
naccrbasak: not 100% on those (yet)17:19
naccrbasak: but for the rest that still fail, it's all the FF issue for the -devel branches17:20
rbasakOK17:20
naccrbasak: are you ok with me implementing the merge idea?17:20
naccrbasak: that is, the -devel branches stay FF by merging the new commit and the old head?17:20
rbasakYes, 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
rbasakI don't know if that'd be quite a big refactoring?17:21
rbasakBut otherwise the data structure obtained would be dependent on timing of imports, which I think would be bad.17:21
naccso the -devel branch would become quite a bit 'noisier', but would be be correct17:22
naccit will also slow it down a bit, if it has to do the check for every pocket on every import17:22
rbasakYeah17:22
rbasakIf refactoring, please take my refactoring branch first.17:22
rbasaknacc: it's just a local and inexpensive check though, no?17:24
naccit's not entirely inexpensive, it has to look at each head in a given series and decide which is 'latest'17:24
naccrefactored, i might be able to restrict it to the affected series, so it might not be a big deal17:25
rbasakOK17:27
naccrbasak: the only other concenr is the abvoe chagne means existing imports are 'incorrect' or would differ from from-scratch imports17:30
naccrbasak: i think that's unavoidable for now, though17:31
rbasakAgreed on both.17:31
naccrbasak: ack, thanks!17:31
rbasakIncidentally, I had a thought related to this.17:31
naccsure17:31
rbasakAdopting upload tags (or not) also mutates the commit hashes.17:32
rbasakAnd upload tags may arrive late, in which case they won't be adopted.17:32
rbasakSo 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
naccyes, i think we discussed this at the sprint17:32
naccsure17:32
rbasakThen the importer could run in a mode where it only adopts upload tags that were previously adopted.17:33
rbasakAnd then third parties have the option of not mutating things.17:33
naccwe 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
nacctrue17:33
tewardrbasak: 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
tewardafter fixing one of the autopkgtests heh17:33
rbasakteward: I did. I thought I replied. But if not, thank you!17:34
naccrbasak: 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 already17:34
rbasaknacc: sure. Not suggesting we have to do that now.17:34
tewardrbasak: you may have but it gets buried under the cruft i see here - limited RAM on my system running my boucer17:34
rbasakJust thought I'd mention it while we were talking about mutations.17:34
teward< 128MB, so I have very low scrollback limits :)17:34
naccrbasak: ack17:34
tewardrbasak: 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 systems17:35
tewardwhich is noticeable but not insane17:35
naccteward: do we want 'new features' in the release notes?17:36
tewardnacc: We're going to have a good sized blurb for Zesty about the release notes17:37
tewardbecause we have dynamic module support now17:37
tewardand a reorg of the packages because of binary changes, etc.17:38
tewardas for "new" features, the big one's dynamic module support, but we can have "More Details" on the ServerTeam/Nginx page.17:38
tewardsince that's now a thing :P17:38
tewardthe big one's going to be fPIE/fPIC and "Performance Notes"17:38
naccteward: sounds good :)17:39
tewardbecause 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 around17: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.)17:39
=== Poster|y is now known as Poster
tewardrbasak: nacc: https://wiki.ubuntu.com/ServerTeam/NGINX/ZestyZapus - Thoughts?20:22
fullstopHi 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:26
fullstopit appears that unattended upgrades for security related things was somehow enabled.20:28
scottjlfullstop: look at /etc/apt/apt.conf.d/50unattended-upgrades and see what's been uncommented20:36
scottjlby default kernels aren't upgraded though20:36
fullstopyes, I see why it's doing it..20:36
fullstopbut I have no idea how this was set.20:36
scottjlsomeone/something changed it.20:37
fullstopand it's enabled on all the 16.04 servers we have here.20:37
scottjlpuppet?20:37
scottjlsalt?20:37
fullstopbut none of the 14.04 or 12.04 (which are slated for retirement)20:37
fullstopsalt20:37
fullstopbut the same states are used on all.20:37
scottjlnone of my 16.04 servers are like that in a fresh setup20:37
scottjlcheck your salt config then?20:38
scottjlthat's not standard 16.04 behavior20:38
fullstoplet me find some non-salt ones.20:38
sarnoldI thought we made that the default for 16.04?20:38
scottjlkernel upgrades? not automatic. unless it's new with 16.04.02?20:38
scottjlwell at least. mine aren't doing it (thank god)20:39
fullstopall of mine are20:39
fullstopeven non-salt20:39
fullstopthis kind of sucks because /boot has run out of space on many of them.20:40
rbasakunattended-upgrades is enabled by default since 16.04 I think.20:43
rbasakBut if it causes /boot to fill up, that's bad and we need to fix that.20:43
rbasakteward: looks good!20:43
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:44
fullstopIf the server were restarted before it filled, I'm still not certain that old kernels would be purged.20:45
tewardrbasak: thanks, feel free to improve :)20:45
scottjli 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 kernels20:45
sarnoldfunny enough my laptop appears to have six kernels, ~300 megs of /boot and my server seven, for ~385 megs of /boot20:47
fullstopsarnold: surely your laptop has been rebooted recently.  When are the old ones to be removed?20:47
sarnoldfullstop: you're right, rebooted 46 days ago20:48
fullstopI'm only at 40. ;-)20:48
fullstopbut, shhh, the laptop is arch.20:48
naccteward: +1 looks good20:53
teward:)20:54
sarnoldman I can't figure out when APT::NeverAutoRemove actually works :/20:54
sarnoldC++ is just so alien tome20:55
tewardheh20:55
fullstopthat makes sense if it's "alien tome" or "alien to me"20:55
sarnoldhehe so it does :)20:55
=== mwsb is now known as chu
ZoomZoomZoomHi! Is anyone running qbittorrent-nox behind reverse proxy? I can't get it to work with lighttpd 1.4.3522:13
compdocwhen 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-have22:58
sarnoldwhy?22:59
sarnoldI think the way to disable it is via editing /etc/apt/apt.conf.d/50unattended-upgrades22:59
rbasakOr remove the unattended-upgrades package.23:08
sarnoldthere's too many intersecting and interacting pieces :)23:09
compdocwhen 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 well23:09
sarnoldyou can always check uptime output to see how long it's been since the last reboot23:10
compdoctoo late23:11

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!