[00:08] nacc: we should add that to the list of tests then. [00:08] nacc: I reviewed the MP. I'm happy to take further changes on if you like. [00:08] nacc: in the meantime, it's probably good that we've both touched this code now :) [00:25] rbasak: yep, just was an fyi on that particular case :) [00:25] rbasak: i'll work on fixing up my patchset and getting those tests to all pass [00:25] rbasak: i agree with your sentiments in the MP [00:25] rbasak: i'm EOD -- i'll work on it tmrw, and then i'm going to pivot to documentation [00:25] nacc: thanks. [00:26] 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] That would fix your problem case I think? [00:26] rbasak: yeah, probably an exact match is better, good call [00:26] rbasak: i forgot we have that in this context :) [00:26] :) [00:27] 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] 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] (sanity check) [00:29] rbasak: in any case, will work on it tmrw [00:29] nacc: agreed [00:30] nacc: might be an idea to reduce before and after to the max before going this deep though. [00:31] rbasak: true, that's a good point, we just need the 'nearest' neighbors, really, right? [00:32] Now I'm not so sure! [00:32] I was only thinking about one series in each direction, and taking the max of all of the pockets. [00:32] But of course there are multiple series in each direction. I hadn't considered that. [00:37] rbasak: and once one goes EOL, it might not get updates, but another one might :) [00:37] so you need nearest active series, i think [00:37] or something :) [00:37] I'll think about it. Or we'll see when we hit an edge case :) [00:48] 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] https://paste.ubuntu.com/25173905/ [00:51] is there anything in dmesg that says why it was kicked out or not allowed back in? [00:56] it hasn't been part of the raid array since may, so I don't have logs from then [01:00] sarnold, https://paste.ubuntu.com/25180682/ [02:51] IS anybody around or is it sleepy time where you are... ? [02:55] it's been long enough tha it probably doesn't hurt to reask your question [06:37] Good morning === JanC_ is now known as JanC [08:17] 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 [08:17] Launchpad bug 1706875 in libvirt (Ubuntu) "libvirt's apparmor profile denies access to /tmp and snapshots failed" [Undecided,New] === gheorghe_ is now known as gheorghe [09:06] zioproto: ok [10:05] Hello all need help regarding kernel panic in 14.04 issue - http://imgur.com/a/3oKAQ [10:13] zioproto: is you libvirt issue on trusty via Mitaka UCA resolved by the version in -proposed (1.3.1-1ubuntu10.11~cloud0) [10:15] zioproto: actually https://bugs.launchpad.net/qemu/+bug/1626972 is pertinent here [10:15] Launchpad bug 1626972 in Ubuntu Cloud Archive mitaka "QEMU memfd_create fallback mechanism change for security drivers" [Undecided,Fix committed] [10:17] is there a way to work around apt-get install -f without installing new kernel versions? [10:18] zioproto: see comments - I've just released the qemu fixes to the mitaka uca -updates pocket [10:54] jamespage: I will try 1.3.1-1ubuntu10.11~cloud0 and give you feedback, thanks ! [10:54] zioproto: make sure you pickup qemu as well - that's where the actual fix is [14:18] 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] 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] hi [14:28] who here knows mongo? [14:28] I am stuck with it :D [14:29] some silly mistakes hehe [14:29] while trying yo initiate replica set [14:46] they most likely have their own irc channel [14:47] hehehe: ^ [14:49] only 1 dude there knows stuff [14:49] and he is busy :D [14:50] 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] mzaza: also check /var/log/auth.log on the server that authentication takes place on. [15:15] 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] mzaza: meaning? [15:17] tomreyn: I don't know :D that what I get when trying to connect using the new jailed user :D [15:17] After adding the public key in the authorized_keys file [15:17] and the client says what? [15:18] permission denied (public key) [15:19] maybe you placed the authorized key file outside the jail? [15:20] maybe when you jailed the user you also changed its home directory. [15:23] show 'getent passwd hazem' and 'ls -la $(getent passwd hazem | cut -d: -f6)/.ssh' [15:50] 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] anyone interested in discussing this, or should I just go straight to opening a bug report? [15:51] this only affects php-imagick, not the command line [15:51] semiosis: it would be good to file a bug, please subscribe me (nacc) [15:52] will do. thanks nacc [15:52] semiosis: this on 16.04? [15:52] yes [15:52] semiosis: is it something taht works again if you go back to 5.7? [15:53] the archive didn't have ubuntu5.7, only ubuntu5. i downgraded to that and we're back in business [15:53] semiosis: ok, so file the bug against imagemagick (not php-imagick) [15:53] semiosis: do you have a testcase? [15:53] semiosis: if possible, put that in the bug too [15:53] 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] i will make a testcase for the bug report [15:56] semiosis: thanks [16:44] nacc: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1707015 [16:44] Launchpad bug 1707015 in imagemagick (Ubuntu) "image composite functions not working in php" [Undecided,New] === mzaza is now known as Guest33158 [16:56] semiosis: thanks [16:59] ls [16:59] wops === pavlushka_ is now known as pavlushka [18:28] wops [18:28] hops [18:29] thanks for ever until a day you will guys [18:33] ? [20:51] ahasenack: bug updated [20:51] * ahasenack reloads [20:51] ahasenack: you think I should tag it? [20:51] 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] ok [20:52] ah, changelog is 2 already [20:52] I'll just tag it v2~pre1, since I'm a bit tired of deleting tags. :) [20:53] dpb1: I haven't read the whole bug yet, so version 2 will be in trusty, what will the > trusty versions be? [20:53] i guess they will follow the conventions [20:53] * ahasenack bring up the versioning cheat sheet [20:53] 2.0 2.0ubuntu0.1 [20:54] ahasenack: in this case, you need to read the bug [20:54] so 2ubuntu0.16.04.1 for xenial I suppose [20:54] since the same version will be in all of them [20:54] ok [20:54] ahasenack: an AA is being requested to do a "pocket copy" from trusty forward [20:55] whatever that means [20:56] right [20:58] 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] https://paste.ubuntu.com/25173905/ [20:59] https://paste.ubuntu.com/25180682 [21:00] fluvvell: if you add it back post-reboot with mdadm (I presume it's md0), that works? [21:00] but on reboot it's gone again? [21:01] I've tried to re-add, which responds with not possible [21:01] or should I add it as if it never (as in --re-add) [21:04] 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] fluvvell: now that you actually provided output, answering your questions should be a lot easier. :) [21:56] i assume sdc2 is the missing raid device in md0? [21:57] *only* if so, try this: mdadm /dev/md0 --add /dev/sdc2 [21:58] if this won't work, do this first: mdadm --zero-superblock /dev/sdc2 [21:58] ... then add it again [22:01] rbasak: fyi, there is a nice launchpad API 'isSourceUploadAllowed' for a per-series query of person/srcpkg upload permissons [22:01] Nice [22:17] sorry, left the office to a callout. tomreyn, yes sdc2 is the missing one [22:18] fluvvell: that's fine, so you know how to proceed ;) [22:19] yes, thanks - I had been leaning towards the --add, but I've not considered the zero-superblock before. [22:20] this can be necessary when things get out of sync / configurations have changed. [22:22] --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] if they are not, --add is the way to go [22:24] * 'Events:' numbers === JanC_ is now known as JanC === dcmorton_ is now known as dcmorton === med_ is now known as Guest13936 === sarnold_ is now known as sarnold === clvx is now known as Guest93189 [23:15] rbasak: we should sync tmrw. I think the abstraction in versioning.py is incorrect for doing the SRU checks we want [23:33] rbasak: i just pusehd a new branch, i don't love it, but it does pass tests, please take a look if you can === CodeMouse92 is now known as CodeMouse92__