=== utlemming_away is now known as utlemming
[02:11] <micahg> robert_ancell: hi, I just wanted to let you know that I was already working on the merge of lintian in case you added it to your list
[02:12] <robert_ancell> micahg, no, wasn't doing any merging. Just sick of lintian whining at me that wily didn't exist :)
[02:12] <micahg> ok, thanks
=== mnepton is now known as mneptok
[03:45] <pitti> Good morning
[03:50] <pitti> jamespage: python-swiftclient in -proposed seems to have dropped its autopkgtest, why?
[03:50] <pitti> (nothing in the changelog)
[06:32] <infinity> pitti: Bah.  My systemd update was missing a piece.  Just noticed on a fresh install.
[06:33] <pitti> infinity: ah, from initramfs? or udeb?
[06:34] <infinity> pitti: udeb is fine, initramfs, however, needs 70-persistent copied or I just renamed everyone. :P
[06:34] <pitti> oh, whoops :)
[06:34] <infinity> La la la.
[06:34] <pitti> infinity: why does this need to happen in initramfs in the first place?
[06:34] <pitti> we never did, AFAICS, and let udevtrigger sort it out?
[06:35] <pitti> it seems okay to do it in initramfs as well, but that's entirely new
[06:35] <infinity> pitti: It needs to match in initramfs and the real system, if you want people to have a hope of consistency.
[06:36] <infinity> pitti: I guess I could see the inverse argument for initramfs not doing either method and people just hoping that eth0 is a thing.
[06:36] <pitti> infinity: but it never did so far, if we never copied 70-persistent to initramfs
[06:37] <infinity> pitti: So, we can either back out my bits entirely, or I need to copy 70-persistent, but the current state is broken.
[06:37] <infinity> pitti: I was going to go for the copying, so it's consistent at both points in the boot.
[06:38] <pitti> infinity: right; as I said, I think it's fine to copy 70-persistent too, but having non-kernel interface names in initramfs apparently has never bothered anyone so far
[06:38] <infinity> pitti: Yeah, it's not bothered anyone before, I imagine, because it mostly matched the running system, except for weird cases where people intentionally rename out of detection order.
[06:38] <infinity> pitti: And, honestly, very few people make use of initramfs networking features.
[06:39] <pitti> right
[06:39] <pitti> just about the only thing I can think of is open-iscsi
[06:39] <infinity> Anyhow, I think it's probably sane to just make them match.
[06:39] <infinity> So, I'll do that.
[06:39] <pitti> agreed
[06:43] <infinity> pitti: Good thing I installed from vivid and upgraded instead of using a wily daily...
[06:45] <infinity> pitti: Tested and uploaded.
[06:46] <infinity> ... and confused by the lack of gpg agent in my fresh install.
[06:46] <pitti> infinity: oh, you too? I have that too since today
[06:46] <pitti> i. e. probalby since yesterday's dist-upgrade
[06:47] <infinity> Ahh, so it's new, not something I did wrong.
[06:47] <infinity> That's comforting.
[06:49] <infinity> pitti: Going to blame the gnome-keyring merge.
[06:50] <infinity> pitti: Which has "disable gpg agent" in the changelog, so seems like a good thing to blame.
[06:51] <pitti> wut?
[06:51] <pitti> * Disable gpg agent as it is incomplete and incompatible with many uses of
[06:51] <pitti>     GnuPG 2.x. (Closes: #760102).
[06:51] <infinity> pitti: Evidently, we're meant to use pinentry-* now, but not sure how that works...
[06:51] <pitti> ah, but we still use gpg 1
[06:52] <infinity> pitti: Or maybe we're supposed to switch to GPG2 as well. :P
[06:52] <pitti> pinentry-gnome3 I suppose
[06:52] <pitti> yeah, at some point we should I guess
[06:52] <infinity> pinentry-gnome3 is installed.  Can't see that it does anything.
[06:52] <pitti> we've been holding back on that because there only used to be pinentry-gtk2
[06:52] <pitti> but apparently now we have a GTK 3 variant
[06:53] <infinity> Yeah.  I guess maybe I need GPG2 to make this work.
[06:53] <pitti> I suppose .. right, that
[06:53] <infinity> And we need to sort out dependencies a bit for non-gtk3 flavours.
[06:53]  * infinity installs gnupg2 to see what happens.
[06:54] <infinity> Hrm.  Not much without also renaming its binary, I guess.
[06:54] <infinity> Ahh, or debsign -pgpg2
[06:55] <pitti> infinity: works here
[06:55] <pitti> infinity: i. e. I installed gnupg2, restarted my session, now I get an (admittedly rather bare-bones) dialog
[06:55] <pitti> I just tested gpg -c foo.txt
[06:57] <infinity> pitti: Oh, cute, it works with both versions, but only if gpg2 is installed?  That doesn't make much sense.
[06:57] <infinity> Maybe it's cause gnupg2 pulled in gnupg-agent.
[06:57] <pitti> yeah
[06:59] <infinity> Yeahp, that does it.
[06:59] <infinity> Looks like a transition is in order anyway at some point soon.  Should probably discuss that a bit before we jfdi.
[07:00] <dholbach> good morning
[07:01] <infinity> pitti: Anyhow, if you could commit my systemd one-liner to Debian git, that'd be snazzy.
[07:01] <infinity> pitti: I left them all on one line in the hook, despite them being out of order that way, so it's less noise if we decide it's dumb and back it out later. :P
[07:03] <pitti> infinity: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=b8fdd6f8f
[07:04] <infinity> pitti: Ta.
[07:05] <infinity> I wonder why pinentry-gnome3 isn't named gtk3... The deps seem mostly harmless and non-gnome.
[07:05]  * infinity shrugs.
[07:05] <pitti> seb128 just appeared, maybe he can give us some insights :)
[07:05] <pitti> seb128: we want our GPG keyring agent back! :-)
[07:06] <pitti> seb128: installing gnupg2 apparently helps, but it doesn't happen on upgrade
[07:07] <infinity> So, gnome-keyring depends on pinentry-gtk3, that's probably going to need relaxing for other flavours.  Maybe.  And we'll need some seeding around the place to pull in the right agents and pinentries.
[07:07] <seb128> pitti, it's a Laney transition, https://lists.ubuntu.com/archives/ubuntu-desktop/2015-July/004671.html
[07:08] <seb128> why would that depends be an issue for flavors?
[07:09] <seb128> those we us *gnome*-keyring already have gtk3
[07:09] <seb128> we->who
[07:09] <infinity> Literally everyone seems to have gnome-keyring seeded right now, though that may be a transient dep and a mistake.
[07:10] <infinity> Nope, this was true in vivid too.
[07:11] <infinity> gnome-keyring doesn't actually seem to contain GUI components of its own, so any pinentry backend will do.
[07:12] <infinity> Which makes it suitable for all desktops.
[07:12] <infinity> Indeed, kubuntu ships gnome-keyring and pinentry-qt4, but now they'll get -gnome3 as well.
[07:13] <infinity> Laney: You probably want to s/pinentry-gnome3/pinenty/ on that gnome-keyring dep, and then seed the appropriate one for each desktop.
[07:14] <infinity> Laney: And it looks like we also want gnupg-agent seeded.
=== zyga_ is now known as zyga
[08:55] <Mirv> doko: did you change anything regarding the 016 PPA other than uploaded qca2? weirdly, the qtdeclarative-gles which built just fine 1h ago now failed to resolve dependencies when rebuilding it (no changes, just correct version number). there were no other finished builds in between.
[08:56] <infinity> pitti: In the shiny new autopkgtest infra, do you plan to make arch builds individually addressable?
[08:56] <infinity> pitti: I always feel bad every time an arch fails and I retry all of them to fix it.
[08:56] <pitti> infinity: you mean only re-run one arch?
[08:56] <infinity> pitti: Yeah.
[08:56] <pitti> infinity: yes, it only works that way
[08:57] <infinity> pitti: Oh, good.
[08:57] <pitti> we can do some helper scripts to retry all of them, of course
[08:57] <infinity> pitti: I see zero need for such a helper. :P
[08:57] <pitti> I don't yet have helper scripts, though; we'll create them as we need
[08:57] <doko> Mirv, no, just qca2. yesterday, I uploaded the GCC 5.2 rc2, but that shouldn't change anything
[08:57] <pitti> infinity: the stuff auto-retries "tmpfail" results up to three times, btw; that should also help
[08:57] <infinity> pitti: In all my years, I've never thought "man, it sucks when I have to retry a build on 6 arches in LP", but I sure would hate it if retrying on one built them all.
[08:58] <pitti> infinity: where tmpfail == testbed failure (nova hiccups, apt-get update checksum fail, etc.)
[08:58] <doko> Mirv, seb128: when trying to build qtwebkit-source (qt4), the build fails, there doesn't seem to be a b-d on libjavascriptcoregtk-1.0-dev. is this expected?
[08:58] <infinity> pitti: That should help a bit indeed.  I guess it depends on where we see weird failures.
[08:58] <pitti> infinity: we could also add retry-once-on-regression, I figure
[08:58] <pitti> but I don't have that yet; I want to see infra problems exposed for now
[08:59] <infinity> pitti: Yeah, let's not paper over problems we don't have just yet.
[08:59] <Mirv> doko: ok, I'm very puzzled now but I'll try to reproduce it in chroot or something
[09:00] <infinity> pitti: I was just reminded of my complaint due to the broken infra issues that killed i386 for dbus and open-iscsi just now (both retried and succeeded now)
[09:00] <infinity> pitti: So, y'know, was just a drive-by whine. :)
[09:00] <doko> Mirv, you uploaded to trusty ... ;-P
[09:00] <pitti> infinity: .. which seems settled for now?
[09:00] <Mirv> doko: I'm not familiar with qt4's webkit, but if it's any same as qt 5 then it probably bundles its own javascriptcore fork
[09:00] <infinity> pitti: Well, they worked on the second try, so "yes".
[09:00] <pitti> infinity: there is one AMQP queue per release and arch, so we can retry tests on that granularity
[09:01] <Mirv> doko: ahhahah...
[09:01] <pitti> infinity: I mean settled wrt. the new stuff
[09:01] <Mirv> doko: thanks ...
[09:01] <infinity> pitti: Oh, yeah.  New stuff having a granularity of DAS seems just fine by me.
[09:01] <pitti> infinity: I'm unsure whether I should block the rollout of this (run cloud stuff on the side) on re-review of slangasek; I'll ask him this evening
[09:01] <infinity> pitti: (DistroArchSeries in LP talk, if that was gibberish to you)
[09:01] <doko> cjwatson, could you get the haskell component mismatches under control?
[09:01] <pitti> infinity: nah, I figured :)
[09:03] <infinity> pitti: And note, it really should have the "distro" component of that DAS, so we can later reuse and abuse this infra for PPAs and derived distros.
[09:03] <infinity> pitti: But I'm guessing it's lightweight and hackable enough that you can extend it later.
[09:04] <pitti> infinity: yes, no problem; but I plan on adding PPA support as arguments of a release/arch/package test request
[09:04] <pitti> infinity: as PPAs are orthogonal to selecting a distro name
[09:05] <infinity> pitti: Quite, they're an archive.
[09:05] <pitti> infinity: my selfish motivation is to move my manual daily-ish systemd upstream CI test to that cloud thing ASAP :)
[09:06] <infinity> pitti: If you hack in archive support, derived distros are simple too.  Would be nice if it could map 1:1 to LP's view of distro archives, but that's probably not hard.
[09:07] <pitti> infinity: shouldn't be, as long as we have some available cloud image to run tests in
[09:07] <infinity> pitti: (For instance, PPAs can exist for both ~user/ppaname/ubuntu and ~user/ppaname/ubuntu-rtm)
[09:07] <pitti> the only exercise is to map something like "trusty-amd64" to an image
[09:08] <pitti> PPAs will always be added/dist-upgraded on the fly per-test, so they are easier
[09:08] <infinity> pitti: Cloud images could be tougher.  Hrm.  The only tarballs we guarantee to have for derived distro are lp-buildd chroots.  But, it's a mostly moot point for now as we don't have any active derived distros we care about anymore.
[09:08] <pitti> infinity: we could always set up a vmdebootstrap daily cron job
[09:08] <pitti> as long as that distro is buildable out of debootstrap (which really ought to be a given -- if not, go away)
[09:09] <pitti> in fact I'd like to do that for at least Debian sid
[09:09] <infinity> pitti: Heh.  Well, we'll cross that bridge if we're ever forced onto it.  Was more making sure the infra was flexible enough to do it, not that we dotted all the Ts and crossed the Is.
[09:09] <pitti> I locally run it occasionaly, but nicer to have some machine do it for me
[09:09] <pitti> running a test on Debian is certainly something that interests me, and I do it locally all the time
[09:10] <pitti> (with vmdebootstrap image)
[09:10] <infinity> pitti: There are a lot of things I'd like to do with Debian in Canonical infra...
[09:10] <infinity> pitti: Like provide PPAs.
[09:10] <infinity> pitti: Which we should have done years ago.
[09:10] <infinity> pitti: But now that Debian's supposedly planning their own version, perhaps it's too late to be good citizens and do so.
[09:13] <doko> Mirv, Riddel, ScottK: qca2 in debian b-d's on qtbase5-dev, while in Ubuntu it b-d's on libqt4-dev. any reason for that?
[09:15] <doko> ahh, Debian's version has additional qt5 packages
[09:17] <Mirv> doko: it looks to me that sitter might have accidentally dropped qtbase5-dev from  2.1.0-0ubuntu2  upload, it was there in ubuntu1 but I don't see a mention in changelog about dropping it
[09:17] <Mirv> oh, not accidentally, 2.1.0-0ubuntu1 was stuck in proposed, so probably on purpose
[09:20] <sitter> qca2 is qt4, qca2-qt5 is qt5. I am not sure why it would depend on qtbase5 in debian
[09:21] <doko> ahh, Debian builds from one source
[09:21] <sitter> that would explain it I guess
[09:21] <sitter> there was some upstream tension over supporting qt5 in the same (upstream) source tarball which is why we ended up with two source packages
[09:22] <doko> Mirv, sitter: is there a short doc how to use the pkg-kde-tools to update the qt/kde symbols files?
[09:23] <Mirv> doko: http://pkg-kde.alioth.debian.org/symbolfiles.html . I do for example pkgkde-symbolshelper patch -p libqt5concurrent5 -v 5.4.2 < concatenated_all_buildlogs and review the result
[09:23] <sitter> doko: http://pkg-kde.alioth.debian.org/symbolfiles.html look for 'pkgkde-symbolshelper batchpatch'
[09:26] <sitter> there's also this bugger which supposedly automatically gathers up all logs from launchpad and patches them in http://paste.ubuntu.com/8573918/
[10:33] <cjwatson> doko: No, I can't, sorry.  Last I checked Haskell was entirely in universe, so if it's in c-m it's due to something I didn't touch, and somebody who cares about *that* should disentangle it.  Looks like maybe ffms2 started build-depending on pandoc?
[10:35] <cjwatson> doko: Simplest change would be to find another markdown processor that's a bit more main-friendly to implement https://anonscm.debian.org/cgit/pkg-multimedia/ffms2.git/commit/?id=1c0216de2945a955480e6dd84a2f05729936691e (since that can't just be reverted if the upstream doc format changed), I guess.  I don't actually mind if Haskell ends up in main, but I suspect something where you may have to rebuild all reverse-dependencies when ...
[10:36] <cjwatson> ... applying a code change may be hard to get past the security team.
[10:38] <infinity> *cough*Go*cough*
[10:41] <mitya57> cjwatson, python3 -m markdown <foo.mkd >foo.html
[10:41] <mitya57> main-friendly :)
[10:42] <cjwatson> Which is fine by me, but somebody will have to test that for ffms2 - I'm not going to have time
[10:46] <mitya57> Will need a tiny bit of patching
[10:55] <mitya57> cjwatson, doko: http://people.ubuntu.com/~mitya57/tmp/pymkd.diff, after that
[10:55] <mitya57> sed s/---/-/g doc/ffms2-api.md | python3 -m markdown -x fenced_code -x headerid >doc/ffms2-api.html
[10:56] <mitya57> Can upload that if you want
[10:56] <cjwatson> It's fine by me
[10:57] <cjwatson> Thanks
[10:57] <mitya57> So doing that
[11:11] <infinity> mitya57: If the implication there is that the upstream docs aren't 100% correct markdown, could you push a patch upstream too?
[11:11] <infinity> mitya57: (Or is that a bug/misfeature in the py3 md parser?)
[11:11] <mitya57> Doing that already :)
[11:12] <cjwatson> python-markdown's docs say that it adheres a bit more strictly to the markdown spec on list formatting than other formatters do, and that they consider this a bug in *other* formatters.
[11:13] <infinity> Of course they do.
[11:13] <infinity> I would expect nothing less from the people who brought me PEP-8.
=== Ionic is now known as Guest99726
[11:14] <cjwatson> But you're not bitter.
[11:14] <infinity> Not even a little.
[11:15] <mitya57> Actually pandoc (which is used in Debian) behaves the same as Python-Markdown
[11:15] <mitya57> http://johnmacfarlane.net/babelmark2/?text=-+Item+1%0A++-+Item+2%0A++-+Item+3%0A-+Item+4
[11:16] <cjwatson> Odd, so why didn't that fail before?
[11:17] <cjwatson> Oh, I guess it kind of did.  Just more warnings or something?
[11:18] <mitya57> No, it just rendered it as a single list, not as list + sublist
[11:19] <mitya57> Oh, python-markdown is in main while python3-markdown isn't
[11:20] <mitya57> So let's pull the latter too :)
[11:20] <infinity> mitya57: If they're from the same source, that's a no-op.
[11:20] <mitya57> Yes
[11:20] <infinity> Fixing now.
[11:21] <mitya57> Uploaded & submitted upstream as https://github.com/FFMS/ffms2/pull/222
[11:23] <infinity> mitya57: Promoted.  I'm sure your upload will beat the promotion, so you might need to retry if it doesn't dep-wait properly.
[11:24] <mitya57> Huh, the pandoc doesn't even render lists correctly
[11:24] <mitya57> And codeblocks
[11:25]  * mitya57 files a Debian bug
[11:25] <mitya57> amd64 and i386 already built, the others will hopefully build too
[11:26] <infinity> mitya57: Oh, that's cause ffms2 is in universe.
[11:26] <infinity> I assume c-m exploded cause something else is trying to pull it in.
[11:26] <mitya57> :-/
[11:26] <infinity> x264, looks like.
[11:26] <mitya57> Anyway I fixed the docs because pandoc was broken :)
[11:26] <infinity> Heh.
[11:26] <infinity> Sounds sensible to me.
[11:28] <infinity> stgraber: We still have ltsp wanting mate-desktop.  Wasn't someone going to fix that?
[11:28] <ogra_> to what ?
[11:29] <ogra_> (Unity7 isnt really remote friendly)
[11:29] <infinity> ogra_: To whatever it was before the merge from Debian? :P
[11:30] <mitya57> If you think you need MATE, then you need GNOME Flashback :)
[11:30] <infinity> -  gnome-session | x-session-manager | x-window-manager,
[11:30] <infinity> +  mate-desktop-environment | gnome-session | x-session-manager | x-window-manager,
[11:30] <ogra_> not sure what was used before ... i just know that Unity doesnt work inless yyou use some costly protocol like VNC
[11:30] <infinity> That shows up in a couple of places.  Probably just needs the prefs inverted and we're good.
[11:31] <infinity> I would have done it myself, but given that I literally never use LTSP, I thought it saner to leave it to people who know what it'll do if I "fix" it.
[11:31]  * ogra_ thinks stgraber's plan was to actually leave all maintenance to debian nowadays ... without ubuntu delta ... 
[11:31] <infinity> ogra_: Well, he still has a delta, so that's not working out.
[11:31] <ogra_> oh ?
[11:31] <infinity> ogra_: But, if that's the plan, it should probably drop out of main.  Which I'd be fine with too.
[11:32] <ogra_> why would you drop it from main ?
[11:32] <infinity> ogra_: To avoid pulling MATE in.  Or whatever other random deps Debian adds.
[11:33] <ogra_> ah ... well, i guess that should be fixed :)
[11:35] <mitya57> infinity, another solution which doesn't require delta will be killing mate dependency in debian as well
[11:35] <ogra_> or just re-ordering
[11:36] <infinity> The Debian order seems deliberate, from the changelog.  THey want to prefere mate.
[11:36] <infinity> Which is fine.
[11:36] <infinity> But doesn't work for us.
[11:36] <infinity> But I'm not sure why it's even *in* our supported seed anyway.
[11:36] <infinity> I still assume that's just from way back when all flavours were in main.
[11:36] <infinity> And that hasn't been a reality for years.
[11:37] <Guest99726> mitya57: GNOME flashback didn't work a while ago because it was checking for extensions (or rather versions) NX cannot provide currently - I've heard of the newest GNOME version working again, but haven't checked myself
[11:38] <ogra_> infinity, well, we developed it (mainly) ... it is a part of edubuntu (which falls under your last statement)
[11:38] <infinity> ogra_: Sure, but we clearly don't put much effort into supporting it any more, so "we developed it" doesn't matter.  We developed a lot of stuff that's not supported.
[11:38] <Guest99726> (might be working "just fine" over VNC though, but that's not all the technology out there)
[11:38] <mitya57> Guest99726, it was a problem not in gnome-flashback, but in gnome-session, is fixed now
[11:39] <mitya57> There may be problems with gnome-shell, but flashback should work
[11:39] <Guest99726> okay
[12:46] <shadeslayer> chrisccoulson: no firefox update for precise?
=== _salem is now known as salem_
[13:04] <mdeslaur> shadeslayer: I'm sure chrisccoulson would welcome some help to fix bug 1471949
[13:05] <wgrant> chrisccoulson: It seems you dropped my arm64 build fix in your recent wily firefox upload.
[13:06] <infinity> chrisccoulson: (which should also have ended up in all the stable branches too, but I didn't commit to anything but wily, sorry)
[13:24] <roaksoax> infinity: howdy!! I just uploaded MAAS 1.7.6 for SRU to resolve bug #1413388 found after upgrades to 1.7.5 in -proposed. Anychance you can process it today? Thanks!
[13:33] <infinity> roaksoax: Why are the SRU versions higher than the wily version?
[13:34] <infinity> roaksoax: Oh, you literally just uploaded the matching wily one.  Okay.
[13:43] <larryone> Hi,  the Amazon AMIs for vivid are still labeled as DEVEL - is that intentional?
[13:43] <larryone> are there any vivid AMIs that are production ready?
[13:44] <infinity> utlemming: ^
[13:47] <larryone> (looking at http://cloud-images.ubuntu.com/locator/ec2/, the dropdown for Version refers to 15.04 DEVEL only)
[13:47] <roaksoax> infinity: indeed :) I uploaded wily first though, I guess it takes more time to show up provided it has to build and all
[13:48] <roaksoax> infinity: and thank you!
[13:49] <infinity> larryone: That's probably just a display bug, those should have been marked stable when vivid released.
[13:49] <infinity> larryone: But Odd_Bloke or utlemming can confirm and fix.
[13:49] <larryone> infinity, yea, just looking now under http://cloud-images.ubuntu.com/releases/15.04/release-20150707/
[13:49] <larryone> looks like I can fire away with it
[14:02] <rbasak> pitti: any thoughts on having apport and/or dh_installinit provide the failure output swallowed by systemd automatically, without having each maintainer write an apport hook? Seems like something that could be done automatically. Eg. teward's diff at http://launchpadlibrarian.net/211346485/nginx_1.6.2-5ubuntu3_1.6.2-5ubuntu3.1.diff.gz
[14:04] <pitti> rbasak: err yes, absolutely; that should really not be in a specific package
[14:04] <pitti> rbasak: but rather in /usr/share/apport/general-hooks/ubuntu.py or even generic.py
[14:05] <pitti> that's actually nice
[14:05] <pitti> I've been annoyed for years by the tons of "postinst failed with exit code 1" bug reports which didn't otherwise have any useful log
[14:05] <pitti> with systemd we finally have some generic way of extracting information at least
[14:06] <rbasak> Well, the init.d error output served me well in the past
[14:06] <rbasak> But I think systemd swallows that now
[14:07] <pitti> well, invoke-rc.d should at least say something like "foo failed to start"
[14:07] <pitti> (not that this would be much helpful, of course)
[14:07] <rbasak> Right
[14:07] <rbasak> The only other pain point in the past was if a daemon logged to its own logfile and not to stderr, or after forking, so the init.d script didn't pass it through, but in general the apport hooks should pick up that logfile anyway
[14:07] <stgraber> infinity: hey, so vagrantc was supposed to get this sorted out in Debian, let me check what's going on and at least just do it in Ubuntu instead
[14:08] <pitti> rbasak: right, but I thought your goal was to avoid having to create individual package hooks for that?
[14:08] <rbasak> pitti: isn't that unavoidable if a daemon insists on writing to its own logfile only?
[14:09] <rbasak> Or can systemd pick that up somehow?
[14:09] <pitti> rbasak: ah, of course
[14:09] <pitti> but then the journal should at least say "pid 123 died with SIGSEGV" or so
[14:09] <teward> i was pinged xD
[14:10] <rbasak> "pid 123 exited with status 1"
[14:10] <rbasak> :)
[14:10] <pitti> so for stuff not just logging to the journal we of course still need per-package hooks
[14:10] <pitti> but at least for the journalling ones we could generalize
[14:10] <rbasak> Yep. No need to block teward's SRU for that though I hope.
[14:11] <pitti> and we already have everything of level "warning" and above in bug reports
[14:11] <teward> rbasak: already poked infinity and it was 'accepted
[14:11] <pitti> just not info etc.
[14:11] <teward> rbasak: [2015-07-13 09:58:42] -queuebot/#ubuntu-release- Unapproved: accepted nginx [source] (vivid-proposed) [1.6.2-5ubuntu3.1]  <--
[14:11] <pitti> so in theory the JournalErrors.txt should have most errors already
[14:11] <teward> pitti: https://launchpadlibrarian.net/208651217/JournalErrors.txt  <-- see https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1463383
[14:11] <rbasak> Doesn't that assume that every daemon is logging in a way that ends up in the journal with appropriate levels?
[14:11] <stgraber> infinity: manually applying the change vagrantc said he'd push to Debian and uploading that to wily
[14:11] <teward> pitti: that's why i wrote the hooks i needed in there
[14:12] <rbasak> I don't think either of those are true
[14:12] <teward> pitti: as it stands systemd is swallowing the failure reasons
[14:12] <teward> whether that's the nginx start script or systemd I am not sure which is swallowing
[14:12] <teward> but it's not putting usable info into that errors page
[14:12] <teward> s/page/file/
[14:12] <pitti> hm, is nginx of Type=forking?
[14:12] <rbasak> I don't think that "more journald support" is the right answer here. We should arrange to just provide stderr in the case of simple failures.
[14:13] <pitti> well, stderr is exactly what goes into the journal :)
[14:13] <pitti> (and stdout too)
[14:13] <teward> i'll have to check the type, it might be forking...
[14:13] <rbasak> But not in the bug
[14:13] <rbasak> (AIUI?)
[14:14] <teward> pitti: yes it's type forking
[14:14] <pitti> Type=forking
[14:14] <pitti> ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
[14:14] <pitti> err yes
[14:14] <pitti> that eloquently avoids all logging of course :)
[14:14]  * teward grumbles
[14:14] <pitti> this is just wrong -- start-stop-daemon should never be used in a unit
[14:14] <teward> pitti: Debian doesn't know how to do it then
[14:14] <teward> :p
[14:14] <pitti> yeah, this is waaay to complicated
[14:15] <pitti> teward: ok, now I understand your frustration :)
[14:15] <teward> pitti: i internalize most of that ranting.  or go to the gun range to vent it.  but in either case, yes, frustration!
[14:15] <teward> pitti: IMO the package hooks I did for nginx for Vivid and Wily are just a workaround to the core issue
[14:16] <teward> but solve the failure to get usable bug info on the postinstall script failure
[14:16] <pitti> yeah, that unit should be fixed properly
[14:16] <teward> at least for the flurry of bugs we've seen currently
[14:16] <teward> (which rbasak is well familiar with xD)
[14:16] <pitti> teward: yes, your hook looks fine as a workaround for at least vivid
[14:16] <pitti> ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
[14:16] <pitti> ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
[14:16] <pitti> ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
[14:17] <pitti> this just can't be right
[14:17] <pitti> why does this have to be called twice?
[14:17] <teward> pitti: and Wily, for now, as I put the hooks there too
[14:17] <teward> (they landed in Wily first)
[14:18] <pitti> (bbl)
[14:23] <shadeslayer> mdeslaur: oh wow that looks mental
[14:24] <mdeslaur> shadeslayer: yeah :)
[14:38] <doko> jamespage, ping on debian #778058
[14:38] <jamespage> doko, sorry
[14:39] <jamespage> doko, oh - I'm going to get that removed
[14:39] <jamespage> doko, along with percona-xtradb-cluster-5.5
[14:40] <jamespage> we don't have those in Ubuntu any longer, and upstream can't commit the time to maitaining them in Debian
[14:40] <doko> ok, thanks
[14:41] <doko> jamespage, also, who should sort the ruby component mismatches? server (-> puppet), or foundations? it won't be me this time
[14:47] <jamespage> doko, I'll have to pass that over to rbasak and smoser :(
[14:50] <smoser> pitti, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1473527
[14:50] <smoser> does my guess make any sense there? is there some reason that a program with StandardOutput=journal+console should not open /dev/console ?
[14:50] <smoser> (other than it not making a lot of sense... the wierd thing is that it is only transient failure)
[14:51] <pitti> smoser: I can't answer that off the top of my head, need to investigate
[14:51] <smoser> doko, i hope that'd be rbasak i guess.
[14:51] <pitti> smoser: with the tee'ing to journal+console it might be that /dev/console is already opened/busy?
[14:56] <smoser> pitti, that does make sense. but you'd think it would fail all the time then.
[14:56] <smoser> i guess systemd must be reading output from program, then opening /dev/console and closing /dev/console for each time it writes or something.
[14:57] <smoser> meaning i only race on it.
[14:59] <pitti> right; I remember some pull request which had to be reworked because "don't keep /dev/console open all the time, only when you need it"
[14:59] <pitti> supposedly because of that
[14:59] <pitti> but as I said, I don't have firm knowledge about this, need to investigate
[15:00] <infinity> Time for an ubuntu-cloud plymouth theme that cloud-init can write pretty progress to? :)
[15:01] <ogra_> lol
[15:01] <infinity> (not being entirely facetious; that's the whole point of plymouth is multiplexing console I/O)
[15:13] <smoser> pitti, thanks.
[15:13] <smoser> you'd think /dev/console can be opened multipel times.
[15:14] <smoser> otherwise i'd expect really arbitrary failures in a lot of places... anywhere that writes to /dev/console  to sometimes fail.
[15:15] <smoser> and also that breaks my plan for fixing this, which was to have cloud-init not do StandardOutput=journal+console, but rather to just itself parse /proc/cmdline and figure out what the right console targets are and writing there directly.
[15:15] <smoser> as that would then be a race condition.
[15:15] <smoser> it sure would be nice to have a way to write to all 'console=' items that was safe to use.
=== ubott2 is now known as ubottu
=== ming is now known as Guest86022
=== Malsasa_ is now known as Malsasa
[15:48] <doko> W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/wily-proposed/main/i18n/Translation-en  Hash Sum mismatch
[15:48] <doko> W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/wily-proposed/universe/i18n/Translation-en  Hash Sum mismatch
[15:48] <doko> can't get a clear apt-get update ...
[15:48] <teward> shoutout to pitti for the excellent guidance on apport package hooks.
[15:49] <teward> rbasak: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1474039  <-- evidence that the package hooks add in the information that's missing (it's not a real bug, but i had forced a test case to prove it xD)
[15:49] <ubottu> Launchpad bug 1474039 in nginx (Ubuntu) "(Test Case Evidence for #1472683) package nginx-full 1.6.2-5ubuntu3.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Low,Invalid]
=== Ionic is now known as Guest32033
[17:11] <larryone> infinity, thanks for you're advice from earlier, now up and running in our test environment with 15.04
[17:12] <larryone> our first systemd machine =0)
[17:16] <teward> infinity: with regards to the changes to make the net ifnames be the systemd version that 15.10 is moving towards, first-glance looks like it'll work.  we'll see after we go through installation if it stays that way.  (ens## is the numbering pattern it's using, lets see if all works)
[17:36] <teward> infinity: confirmed that the changes you made for the ifname stuff is working - upon install the primary interface is configured as it should be and network access is confirmed
=== dpm is now known as dpm-afk
=== Guest32033 is now known as Ionic
[18:50] <smoser> infinity, would you care to take a look at https://bugs.launchpad.net/ubuntu/+bug/1474090
[18:50] <ubottu> Launchpad bug 1474090 in Ubuntu "ppc64 cloud images boot only once" [Undecided,New]
=== alvesadrian is now known as adrian
[21:57] <yofel> cyphermox: hi, did you make any progress with updating the packagesets?
[22:03] <SpamapS> cjwatson: Interesting grub question for you: Is there any good reason grub shouldn't be able to detect and work with a 1.8TiB root partition with no /boot? Part 2: is there any bad reason it doesn't work like that now?
=== gammax90 is now known as gammax
[22:59] <Daviey> SpamapS: MBR or GPT?
[23:09] <cjwatson> SpamapS: No /boot would probably require some customisations to various GRUB defaults involving /boot/grub.  It should be workable but may require runtime tweaks.
=== salem_ is now known as _salem
[23:55] <cyphermox> yofel: oops.
[23:55] <cyphermox> will re-run, perhaps here it will work faster