[00:08] <rbasak> nacc: we should add that to the list of tests then.
[00:08] <rbasak> nacc: I reviewed the MP. I'm happy to take further changes on if you like.
[00:08] <rbasak> nacc: in the meantime, it's probably good that we've both touched this code now :)
[00:25] <nacc> rbasak: yep, just was an fyi on that particular case :)
[00:25] <nacc> rbasak: i'll work on fixing up my patchset and getting those tests to all pass
[00:25] <nacc> rbasak: i agree with your sentiments in the MP
[00:25] <nacc> rbasak: i'm EOD -- i'll work on it tmrw, and then i'm going to pivot to documentation
[00:25] <rbasak> nacc: thanks.
[00:26] <rbasak> nacc: ack. For your startswith fix, without looking at it in too much detail, can we use an exact match against a decomposed bit instead?
[00:26] <rbasak> That would fix your problem case I think?
[00:26] <nacc> rbasak: yeah, probably an exact match is better, good call
[00:26] <nacc> rbasak: i forgot we have that in this context :)
[00:26] <rbasak> :)
[00:27] <nacc> rbasak: it feels like we really want to decompose the before/after series versions, and then see if a) any of them have the same decomposed prefix as we do
[00:28] <nacc> rbasak: and we probably should do some sort of internal check that our ordering stays correct (that a proposed new version is not before or after anything in before/after respectively
[00:28] <nacc> (sanity check)
[00:29] <nacc> rbasak: in any case, will work on it tmrw
[00:29] <rbasak> nacc: agreed
[00:30] <rbasak> nacc: might be an idea to reduce before and after to the max before going this deep though.
[00:31] <nacc> rbasak: true, that's a good point, we just need the 'nearest' neighbors, really, right?
[00:32] <rbasak> Now I'm not so sure!
[00:32] <rbasak> I was only thinking about one series in each direction, and taking the max of all of the pockets.
[00:32] <rbasak> But of course there are multiple series in each direction. I hadn't considered that.
[00:37] <nacc> rbasak: and once one goes EOL, it might not get updates, but another one might :)
[00:37] <nacc> so you need nearest active series, i think
[00:37] <nacc> or something :)
[00:37] <rbasak> I'll think about it. Or we'll see when we hit an edge case :)
[00:48] <fluvvell> I boot /dev/md0, but just noticed - [_U] - an element missing, tried to re-add with    mdadm --manage --re-add /dev/sdc2 and it said    "... is not possible"   - given that its my boot drive, is it because it is mounted?
[00:49] <fluvvell> https://paste.ubuntu.com/25173905/
[00:51] <sarnold> is there anything in dmesg that says why it was kicked out or not allowed back in?
[00:56] <fluvvell> it hasn't been part of the raid array since may, so I don't have logs from then
[01:00] <fluvvell> sarnold, https://paste.ubuntu.com/25180682/
[02:51] <fluvvell> IS anybody around or is it sleepy time where you are... ?
[02:55] <sarnold> it's been long enough tha it probably doesn't hurt to reask your question
[06:37] <lordievader> Good morning
[08:17] <zioproto> jamespage: I raised the bug against the libvirt package that we have been talking about yesterday: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1706875
[09:06] <jamespage> zioproto: ok
[10:05] <BigBangUDR> Hello all need help regarding kernel panic in 14.04 issue - http://imgur.com/a/3oKAQ
[10:13] <jamespage> zioproto: is you libvirt issue on trusty via Mitaka UCA resolved by the version in -proposed (1.3.1-1ubuntu10.11~cloud0)
[10:15] <jamespage> zioproto: actually https://bugs.launchpad.net/qemu/+bug/1626972 is pertinent here
[10:17] <microwaved> is there a way to work around apt-get install -f without installing new kernel versions?
[10:18] <jamespage> zioproto: see comments - I've just released the qemu fixes to the mitaka uca -updates pocket
[10:54] <zioproto> jamespage: I will try 1.3.1-1ubuntu10.11~cloud0 and give you feedback, thanks !
[10:54] <jamespage> zioproto: make sure you pickup qemu as well - that's where the actual fix is
[14:18] <mzaza> I have followed the following article https://www.howtoforge.com/restricting-users-to-sftp-plus-setting-up-chrooted-ssh-sftp-debian-squeeze, in creating a jailed SSH user. The user should be able to login to shell to run some php commands, the account is intended to be handed over to the developer. However I have an AWS server which logs in using a key file, I have followed the instructions and
[14:18] <mzaza> created the user hazem, however I'm unable to login using that user because login because I get public key denied. Any ideas?
[14:28] <hehehe> hi
[14:28] <hehehe> who here knows  mongo?
[14:28] <hehehe> I am stuck with it :D
[14:29] <hehehe> some silly mistakes hehe
[14:29] <hehehe> while trying yo initiate replica set
[14:46] <tomreyn> they most likely have their own irc channel
[14:47] <tomreyn> hehehe: ^
[14:49] <hehehe> only 1 dude there knows stuff
[14:49] <hehehe> and he is busy :D
[14:50] <tomreyn> mzaza: did you place the (AWS server) users' public SSH key in ~/.ssh/authorized_keys on the home directory of the user that will be authenticated against?
[14:52] <tomreyn> mzaza: also check /var/log/auth.log on the server that authentication takes place on.
[15:15] <mzaza> tomreyn: Jul 27 15:15:23 ip-172-31-30-64 sshd[9417]: Connection closed by 41.128.168.145 port 49374 [preauth]
[15:16] <tomreyn> mzaza: meaning?
[15:17] <mzaza> tomreyn: I don't know :D that what I get when trying to connect using the new jailed user :D
[15:17] <mzaza> After adding the public key in the authorized_keys file
[15:17] <tomreyn> and the client says what?
[15:18] <mzaza> permission denied (public key)
[15:19] <tomreyn> maybe you placed the authorized key file outside the jail?
[15:20] <tomreyn> maybe when you jailed the user you also changed its home directory.
[15:23] <tomreyn> show 'getent passwd hazem' and 'ls -la $(getent passwd hazem | cut -d: -f6)/.ssh'
[15:50] <semiosis> since upgrading imagick-common from 6.8.9.9-7ubuntu5.7 to 8:6.8.9.9-7ubuntu5.8 on july 25, the php imagick composite functions stopped working, they are effectively no-op (no error or exception, they just do nothing)
[15:50] <semiosis> anyone interested in discussing this, or should I just go straight to opening a bug report?
[15:51] <semiosis> this only affects php-imagick, not the command line
[15:51] <nacc> semiosis: it would be good to file a bug, please subscribe me (nacc)
[15:52] <semiosis> will do. thanks nacc
[15:52] <nacc> semiosis: this on 16.04?
[15:52] <semiosis> yes
[15:52] <nacc> semiosis: is it something taht works again if you go back to 5.7?
[15:53] <semiosis> the archive didn't have ubuntu5.7, only ubuntu5.  i downgraded to that and we're back in business
[15:53] <nacc> semiosis: ok, so file the bug against imagemagick (not php-imagick)
[15:53] <nacc> semiosis: do you have a testcase?
[15:53] <nacc> semiosis: if possible, put that in the bug too
[15:53] <semiosis> but our users started complaining on the 25th, and the dpkg log showed an automatic upgrade from 5.7 to 5.8 on that day
[15:53] <semiosis> i will make a testcase for the bug report
[15:56] <nacc> semiosis: thanks
[16:44] <semiosis> nacc: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1707015
[16:56] <nacc> semiosis: thanks
[16:59] <Guest33158> ls
[16:59] <Guest33158> wops
[18:28] <Guest33158> wops
[18:28] <Guest33158> hops
[18:29] <Guest33158> thanks for ever until a day you will guys
[18:33] <tomreyn> ?
[20:51] <dpb1> ahasenack: bug updated
[20:51]  * ahasenack reloads
[20:51] <dpb1> ahasenack: you think I should tag it?
[20:51] <ahasenack> dpb1: we need to make a release in github, right? It's a debian native package (i.e., it has debian/ in it)
[20:52] <dpb1> ok
[20:52] <ahasenack> ah, changelog is 2 already
[20:52] <dpb1> I'll just tag it v2~pre1, since I'm a bit tired of deleting tags. :)
[20:53] <ahasenack> dpb1: I haven't read the whole bug yet, so version 2 will be in trusty, what will the > trusty versions be?
[20:53] <ahasenack> i guess they will follow the conventions
[20:53]  * ahasenack bring up the versioning cheat sheet
[20:53] <ahasenack> 2.0                           2.0ubuntu0.1
[20:54] <dpb1> ahasenack: in this case, you need to read the bug
[20:54] <ahasenack> so 2ubuntu0.16.04.1 for xenial I suppose
[20:54] <ahasenack> since the same version will be in all of them
[20:54] <ahasenack> ok
[20:54] <dpb1> ahasenack: an AA is being requested to do a "pocket copy" from trusty forward
[20:55] <ahasenack> whatever that means
[20:56] <dpb1> right
[20:58] <fluvvell> I'll re-ask, I have a machine that is booting fine, runs raid 1, but the / array is only coming up with one of its two elements.
[20:58] <fluvvell> https://paste.ubuntu.com/25173905/
[20:59] <fluvvell> https://paste.ubuntu.com/25180682
[21:00] <ahasenack> fluvvell: if you add it back post-reboot with mdadm (I presume it's md0), that works?
[21:00] <ahasenack> but on reboot it's gone again?
[21:01] <fluvvell> I've tried to re-add, which responds with not possible
[21:01] <fluvvell> or should I add it as if it never    (as in --re-add)
[21:04] <fluvvell> OK, this may sound a dumb question, but I've not had to play with any of my servers raid arrays for a couple of years because they are so reliable. If its the md0 array, mounted on /, and the fact that its mounted, thats not whats causing the trouble ?  I've not rebooted as its high demand
[21:55] <tomreyn> fluvvell: now that you actually provided output, answering your questions should be a lot easier. :)
[21:56] <tomreyn> i assume sdc2 is the missing raid device in md0?
[21:57] <tomreyn> *only* if so, try this: mdadm /dev/md0 --add /dev/sdc2
[21:58] <tomreyn> if this won't work, do this first: mdadm --zero-superblock /dev/sdc2
[21:58] <tomreyn> ... then add it again
[22:01] <nacc> rbasak: fyi, there is a nice launchpad API 'isSourceUploadAllowed' for a per-series query of person/srcpkg upload permissons
[22:01] <rbasak> Nice
[22:17] <fluvvell> sorry, left the office to  a callout. tomreyn, yes sdc2 is the missing one
[22:18] <tomreyn> fluvvell: that's fine, so you know how to proceed ;)
[22:19] <fluvvell> yes, thanks - I had been leaning towards the --add, but I've not considered the zero-superblock before.
[22:20] <tomreyn> this can be necessary when things get out of sync / configurations have changed.
[22:22] <tomreyn> --re-add only works when there is a chance / it makes any sense to update a previous raid member device to the latest data. i.e. this only makes sense when the numbers provided in --examine output (for a given raid) are close
[22:23] <tomreyn> if they are not, --add is the way to go
[22:24] <tomreyn> * 'Events:' numbers
[23:15] <nacc> rbasak: we should sync tmrw. I think the abstraction in versioning.py is incorrect for doing the SRU checks we want
[23:33] <nacc> rbasak: i just pusehd a new branch, i don't love it, but it does pass tests, please take a look if you can