=== g2[ATL] is now known as g2 [06:41] good morning! [06:43] HI! [06:44] good morning! [06:48] pitti: hey there! :) [06:49] pitti: there were multiple comments wrt you in the PG community of late, btw... [06:49] pitti: I'll summarize them real quick, in case you're interested (it's ok if you are not, of course): [06:49] pitti: Why does purge remvoe the data directory too? Seems a bit dangerous, and a bug was filed about it. [06:50] *remove === JanC_ is now known as JanC [06:50] pitti: Why does a purge (or just remove?) stop *all* databases? That's *really* annoying when doing an upgrade. [06:51] as in you do an upgrade, and then want to remove the 'old' cluster after everything is happy, but that removal ends up shutting down the 'new' cluster. :( [06:52] … I think there were other things, but not remembering atm. :) [06:54] Snow-Man: well, it's a bit of a YAFIYGI thing IMHO -- "purge" means "leave nothing behind", unlike "remove".. [06:55] Snow-Man: removing the wrong cluster sounds like a major bug indeed, but I haven't heard from this at all [06:55] (unlike the "remove clusters on purge" question which comes up every now and then) [06:58] err, stopping, not removing [06:59] yea,it's just stopping [06:59] Snow-Man: the intention is certainly to only stop the clusters of the corresponding version [07:00] maybe that got broken with introducing the systemd services, IIRC it's still calling the init.d script with the version arg [07:04] that seems likely. [07:04] I'll talk to Myon about it [07:04] and the p-common scripts don't test package removal, so it could easily have slipped through [07:04] that's saying something -- "once you install PostgreSQL, you will never want to remove it again!" ☺ [07:05] hahaha [07:05] :D [07:06] ohhh [07:06] there was something else [07:06] something like, you need postgresql-common to get the PG userid [07:07] but, to have that, you need a PG server version installed [07:07] something awkward like that [07:08] hm, just -common ought to be enough [07:09] IIRC if you need users prior to package install can add them it would have to go to base-passwd package? [07:13] pitti: nah, it wasn't.. I don't remember why right now tho. [07:14] cpaelzer: right, but that should be very rare -- normally you'd use a Pre-Depends:, or even "more" normally you create needed system users in your own maintscript [07:14] pitti: of course, I just meant if it had to exist "prior" to any related package install [07:15] and if they need to share uid/gid across systems [07:15] right, those are the static gids (< 100) === giraffe is now known as Guest54596 === rumble is now known as grumble [11:06] jbicha, python-imagick merge? :) [11:07] s/python/php [11:09] cyphermox: Has anyone been looking at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1651716 this is still happening in Xubuntu land, as well as on Ubuntu zesty iso's [11:09] Launchpad bug 1651716 in ubiquity (Ubuntu) "17.04 boots direct to live desktop, no option to Try or Install" [Undecided,Confirmed] [11:25] I would even try a sync [11:53] Hi, could anyone please sponsor a patch for qemu in xenial? https://bugs.launchpad.net/ubuntu/xenial/+source/qemu/+bug/1656480 [11:53] Launchpad bug 1656480 in qemu (Ubuntu Xenial) "QEMU Does not Send L2 Broadcasts After Live Migration" [High,In progress] [11:57] Dmitrii-Sh: I can look at it later today [11:57] cpaelzer: thanks! === _salem is now known as salem_ === JanC_ is now known as JanC [13:33] LocutusOfBorg: feel free to sync it when it's available [13:37] ok ta === JanC_ is now known as JanC [14:18] Dmitrii-Sh: review done - looks all good [14:18] Dmitrii-Sh: not test building and running some tests on it [14:18] Dmitrii-Sh: but I'd expect it to be in the upload queue this evening [14:19] cpaelzer: thx [15:24] sigh jbicha missing dot :( === Wellark_ is now known as Wellark [16:05] forensics-all seems stuck in zesty proposed as it requires https://packages.debian.org/sid/rekall-core [16:05] is this syncable? [16:29] Hi, could anybody take a look at a debdiff for this one https://bugs.launchpad.net/ubuntu/+source/barbican/+bug/1570356 ? [16:29] Launchpad bug 1570356 in barbican (Ubuntu) "unable to load plugins in Centos" [High,Triaged] === scottt is now known as Guest69750 [16:32] Dmitrii-Sh: on the qemu one - tests still running but so far all green [16:33] Dmitrii-Sh: I'll collect the final all green and upload if so before going to bed today [16:33] cpaelzer: great, thx [16:34] infinity: could you review this one, please? https://github.com/snapcore/snapcraft/pull/1060 [16:37] elopio: So, I'm guessing snapcraft doesn't support building for multiple/cross arches on one host? [16:38] infinity: only for the kernel plugin, at the moment. [16:39] ok. filed https://bugs.launchpad.net/ubuntu/+source/forensics-all/+bug/1658728 [16:39] Launchpad bug 1658728 in forensics-all (Ubuntu) "version 1.5 in zesty proposed has unsatisfied depends on rekall-core" [Undecided,New] [16:43] elopio: Kay. So, I'm guessing you're avoiding just asking dpkg because you want something that works on all distros. You'll be grumpy when you realise that GCC triplets are different on RedHat. [16:45] elopio: Also, not sure why, in these scenarios, you care about kernel arch at all. [16:46] elopio: Unless you're using a mismatch later to trigger invoking subproccesses with linux32/linux64 or something. [16:46] infinity: yup, that will be sad. I'm not sure if snapcraft as a snap could bundle dpkg. [16:46] elopio: Which is easier to just hardcode "always assume armhf/i386/powerpc are linux32". [16:47] infinity: can you please comment that on the bug. I wanted to check with you if the approach was correct, but it seems it still needs some work. [16:47] s/bug/pr [16:47] elopio: I'll give it a more thorough look after I've woken up. Still working on that. [16:47] infinity: take your time :) [17:21] elopio: Added one comment. I realised my comment about the scenarios was bogus because that was the testsuite, not the actual code. [17:22] elopio: This will probably work on Most distros, but anything with a RedHat-derived toolchain will almost certainly not work without tweaking. [17:23] infinity: we intend to run snapcraft as a snap in other distros. So I think having gcc as a bundled would just work. But it's worth to be sure of that before we go too deep. [17:23] thanks for the review. [17:24] elopio: Bundling gcc with snapcraft sounds pretty gross, IMO. [17:24] elopio: Like, I get the whole snap concept, but there should be limits, one would think. :P [17:26] infinity: the alternative is not so bad either. Check if we are on redhat, and parse the gcc output differently, or something like that. [17:26] elopio: Though, I suppose the flip argument of that is that if the goal is to build things that definitely work on an ubuntu-core core snap, you need both gcc and libc-dev from Ubuntu (or, really, our who build-essential). But it would seem somewhat saner to have a build-essential snap that gets yanked in for such purposes. Or something. I dunno. *handwavy* [17:27] s/our who/our whole/ [17:28] I'm not sure what will be the approach. Just putting an # XXX comment to deal with that later generally works :) [17:28] * infinity chokes. [17:28] elopio: Good thing I don't know codebases with decade+ old XXX/FIXME comments. :) [20:24] my laptop still has the broken n-m on zesty, what was the quick'n'dirty way to fix dns? [21:09] tjaalton: the new n-m migrated out of proposed so one quick'n'dirty fix is to update your laptop :) === zbenjamin_ is now known as zbenjamin [21:47] Which might be tough without DNS. [22:02] oh, my DNS was broken with CNAMES in containers [22:06] tjaalton: install libnss-resolv...something or other :P [22:06] REALLY glad that's pretty much fixed for now === foxtrot is now known as texas === texas is now known as foxtrot