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:08 |
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:25 |
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:26 |
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:27 |
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:28 |
nacc | rbasak: in any case, will work on it tmrw | 00:29 |
rbasak | nacc: agreed | 00:29 |
rbasak | nacc: might be an idea to reduce before and after to the max before going this deep though. | 00:30 |
nacc | rbasak: true, that's a good point, we just need the 'nearest' neighbors, really, right? | 00:31 |
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:32 |
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:37 |
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:48 |
fluvvell | https://paste.ubuntu.com/25173905/ | 00:49 |
sarnold | is there anything in dmesg that says why it was kicked out or not allowed back in? | 00:51 |
fluvvell | it hasn't been part of the raid array since may, so I don't have logs from then | 00:56 |
fluvvell | sarnold, https://paste.ubuntu.com/25180682/ | 01:00 |
fluvvell | IS anybody around or is it sleepy time where you are... ? | 02:51 |
sarnold | it's been long enough tha it probably doesn't hurt to reask your question | 02:55 |
lordievader | Good morning | 06:37 |
=== JanC_ is now known as JanC | ||
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 | 08:17 |
ubottu | Launchpad bug 1706875 in libvirt (Ubuntu) "libvirt's apparmor profile denies access to /tmp and snapshots failed" [Undecided,New] | 08:17 |
=== gheorghe_ is now known as gheorghe | ||
jamespage | zioproto: ok | 09:06 |
BigBangUDR | Hello all need help regarding kernel panic in 14.04 issue - http://imgur.com/a/3oKAQ | 10:05 |
jamespage | zioproto: is you libvirt issue on trusty via Mitaka UCA resolved by the version in -proposed (1.3.1-1ubuntu10.11~cloud0) | 10:13 |
jamespage | zioproto: actually https://bugs.launchpad.net/qemu/+bug/1626972 is pertinent here | 10:15 |
ubottu | Launchpad bug 1626972 in Ubuntu Cloud Archive mitaka "QEMU memfd_create fallback mechanism change for security drivers" [Undecided,Fix committed] | 10:15 |
microwaved | is there a way to work around apt-get install -f without installing new kernel versions? | 10:17 |
jamespage | zioproto: see comments - I've just released the qemu fixes to the mitaka uca -updates pocket | 10:18 |
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 | 10:54 |
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:18 |
hehehe | hi | 14:28 |
hehehe | who here knows mongo? | 14:28 |
hehehe | I am stuck with it :D | 14:28 |
hehehe | some silly mistakes hehe | 14:29 |
hehehe | while trying yo initiate replica set | 14:29 |
tomreyn | they most likely have their own irc channel | 14:46 |
tomreyn | hehehe: ^ | 14:47 |
hehehe | only 1 dude there knows stuff | 14:49 |
hehehe | and he is busy :D | 14:49 |
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:50 |
tomreyn | mzaza: also check /var/log/auth.log on the server that authentication takes place on. | 14:52 |
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:15 |
tomreyn | mzaza: meaning? | 15:16 |
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:17 |
mzaza | permission denied (public key) | 15:18 |
tomreyn | maybe you placed the authorized key file outside the jail? | 15:19 |
tomreyn | maybe when you jailed the user you also changed its home directory. | 15:20 |
tomreyn | show 'getent passwd hazem' and 'ls -la $(getent passwd hazem | cut -d: -f6)/.ssh' | 15:23 |
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:50 |
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:51 |
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:52 |
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:53 |
nacc | semiosis: thanks | 15:56 |
semiosis | nacc: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1707015 | 16:44 |
ubottu | Launchpad bug 1707015 in imagemagick (Ubuntu) "image composite functions not working in php" [Undecided,New] | 16:44 |
=== mzaza is now known as Guest33158 | ||
nacc | semiosis: thanks | 16:56 |
Guest33158 | ls | 16:59 |
Guest33158 | wops | 16:59 |
=== pavlushka_ is now known as pavlushka | ||
Guest33158 | wops | 18:28 |
Guest33158 | hops | 18:28 |
Guest33158 | thanks for ever until a day you will guys | 18:29 |
tomreyn | ? | 18:33 |
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:51 |
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:52 |
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:53 |
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:54 |
ahasenack | whatever that means | 20:55 |
dpb1 | right | 20:56 |
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:58 |
fluvvell | https://paste.ubuntu.com/25180682 | 20:59 |
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:00 |
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:01 |
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:04 |
tomreyn | fluvvell: now that you actually provided output, answering your questions should be a lot easier. :) | 21:55 |
tomreyn | i assume sdc2 is the missing raid device in md0? | 21:56 |
tomreyn | *only* if so, try this: mdadm /dev/md0 --add /dev/sdc2 | 21:57 |
tomreyn | if this won't work, do this first: mdadm --zero-superblock /dev/sdc2 | 21:58 |
tomreyn | ... then add it again | 21:58 |
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:01 |
fluvvell | sorry, left the office to a callout. tomreyn, yes sdc2 is the missing one | 22:17 |
tomreyn | fluvvell: that's fine, so you know how to proceed ;) | 22:18 |
fluvvell | yes, thanks - I had been leaning towards the --add, but I've not considered the zero-superblock before. | 22:19 |
tomreyn | this can be necessary when things get out of sync / configurations have changed. | 22:20 |
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:22 |
tomreyn | if they are not, --add is the way to go | 22:23 |
tomreyn | * 'Events:' numbers | 22:24 |
=== 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 | ||
nacc | rbasak: we should sync tmrw. I think the abstraction in versioning.py is incorrect for doing the SRU checks we want | 23:15 |
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 | 23:33 |
=== CodeMouse92 is now known as CodeMouse92__ |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!