/srv/irclogs.ubuntu.com/2015/07/13/#ubuntu-devel.txt

=== utlemming_away is now known as utlemming
micahgrobert_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 list02:11
robert_ancellmicahg, no, wasn't doing any merging. Just sick of lintian whining at me that wily didn't exist :)02:12
micahgok, thanks02:12
=== mnepton is now known as mneptok
pittiGood morning03:45
pittijamespage: python-swiftclient in -proposed seems to have dropped its autopkgtest, why?03:50
pitti(nothing in the changelog)03:50
infinitypitti: Bah.  My systemd update was missing a piece.  Just noticed on a fresh install.06:32
pittiinfinity: ah, from initramfs? or udeb?06:33
infinitypitti: udeb is fine, initramfs, however, needs 70-persistent copied or I just renamed everyone. :P06:34
pittioh, whoops :)06:34
infinityLa la la.06:34
pittiinfinity: why does this need to happen in initramfs in the first place?06:34
pittiwe never did, AFAICS, and let udevtrigger sort it out?06:34
pittiit seems okay to do it in initramfs as well, but that's entirely new06:35
infinitypitti: It needs to match in initramfs and the real system, if you want people to have a hope of consistency.06:35
infinitypitti: 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
pittiinfinity: but it never did so far, if we never copied 70-persistent to initramfs06:36
infinitypitti: So, we can either back out my bits entirely, or I need to copy 70-persistent, but the current state is broken.06:37
infinitypitti: I was going to go for the copying, so it's consistent at both points in the boot.06:37
pittiinfinity: 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 far06:38
infinitypitti: 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
infinitypitti: And, honestly, very few people make use of initramfs networking features.06:38
pittiright06:39
pittijust about the only thing I can think of is open-iscsi06:39
infinityAnyhow, I think it's probably sane to just make them match.06:39
infinitySo, I'll do that.06:39
pittiagreed06:39
infinitypitti: Good thing I installed from vivid and upgraded instead of using a wily daily...06:43
infinitypitti: Tested and uploaded.06:45
infinity... and confused by the lack of gpg agent in my fresh install.06:46
pittiinfinity: oh, you too? I have that too since today06:46
pittii. e. probalby since yesterday's dist-upgrade06:46
infinityAhh, so it's new, not something I did wrong.06:47
infinityThat's comforting.06:47
infinitypitti: Going to blame the gnome-keyring merge.06:49
infinitypitti: Which has "disable gpg agent" in the changelog, so seems like a good thing to blame.06:50
pittiwut?06:51
pitti* Disable gpg agent as it is incomplete and incompatible with many uses of06:51
pitti    GnuPG 2.x. (Closes: #760102).06:51
infinitypitti: Evidently, we're meant to use pinentry-* now, but not sure how that works...06:51
pittiah, but we still use gpg 106:51
infinitypitti: Or maybe we're supposed to switch to GPG2 as well. :P06:52
pittipinentry-gnome3 I suppose06:52
pittiyeah, at some point we should I guess06:52
infinitypinentry-gnome3 is installed.  Can't see that it does anything.06:52
pittiwe've been holding back on that because there only used to be pinentry-gtk206:52
pittibut apparently now we have a GTK 3 variant06:52
infinityYeah.  I guess maybe I need GPG2 to make this work.06:53
pittiI suppose .. right, that06:53
infinityAnd we need to sort out dependencies a bit for non-gtk3 flavours.06:53
* infinity installs gnupg2 to see what happens.06:53
infinityHrm.  Not much without also renaming its binary, I guess.06:54
infinityAhh, or debsign -pgpg206:54
pittiinfinity: works here06:55
pittiinfinity: i. e. I installed gnupg2, restarted my session, now I get an (admittedly rather bare-bones) dialog06:55
pittiI just tested gpg -c foo.txt06:55
infinitypitti: Oh, cute, it works with both versions, but only if gpg2 is installed?  That doesn't make much sense.06:57
infinityMaybe it's cause gnupg2 pulled in gnupg-agent.06:57
pittiyeah06:57
infinityYeahp, that does it.06:59
infinityLooks like a transition is in order anyway at some point soon.  Should probably discuss that a bit before we jfdi.06:59
dholbachgood morning07:00
infinitypitti: Anyhow, if you could commit my systemd one-liner to Debian git, that'd be snazzy.07:01
infinitypitti: 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. :P07:01
pittiinfinity: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=b8fdd6f8f07:03
infinitypitti: Ta.07:04
infinityI wonder why pinentry-gnome3 isn't named gtk3... The deps seem mostly harmless and non-gnome.07:05
* infinity shrugs.07:05
pittiseb128 just appeared, maybe he can give us some insights :)07:05
pittiseb128: we want our GPG keyring agent back! :-)07:05
pittiseb128: installing gnupg2 apparently helps, but it doesn't happen on upgrade07:06
infinitySo, 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
seb128pitti, it's a Laney transition, https://lists.ubuntu.com/archives/ubuntu-desktop/2015-July/004671.html07:07
seb128why would that depends be an issue for flavors?07:08
seb128those we us *gnome*-keyring already have gtk307:09
seb128we->who07:09
infinityLiterally everyone seems to have gnome-keyring seeded right now, though that may be a transient dep and a mistake.07:09
infinityNope, this was true in vivid too.07:10
infinitygnome-keyring doesn't actually seem to contain GUI components of its own, so any pinentry backend will do.07:11
infinityWhich makes it suitable for all desktops.07:12
infinityIndeed, kubuntu ships gnome-keyring and pinentry-qt4, but now they'll get -gnome3 as well.07:12
infinityLaney: You probably want to s/pinentry-gnome3/pinenty/ on that gnome-keyring dep, and then seed the appropriate one for each desktop.07:13
infinityLaney: And it looks like we also want gnupg-agent seeded.07:14
=== zyga_ is now known as zyga
Mirvdoko: 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:55
infinitypitti: In the shiny new autopkgtest infra, do you plan to make arch builds individually addressable?08:56
infinitypitti: I always feel bad every time an arch fails and I retry all of them to fix it.08:56
pittiinfinity: you mean only re-run one arch?08:56
infinitypitti: Yeah.08:56
pittiinfinity: yes, it only works that way08:56
infinitypitti: Oh, good.08:57
pittiwe can do some helper scripts to retry all of them, of course08:57
infinitypitti: I see zero need for such a helper. :P08:57
pittiI don't yet have helper scripts, though; we'll create them as we need08:57
dokoMirv, no, just qca2. yesterday, I uploaded the GCC 5.2 rc2, but that shouldn't change anything08:57
pittiinfinity: the stuff auto-retries "tmpfail" results up to three times, btw; that should also help08:57
infinitypitti: 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:57
pittiinfinity: where tmpfail == testbed failure (nova hiccups, apt-get update checksum fail, etc.)08:58
dokoMirv, 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
infinitypitti: That should help a bit indeed.  I guess it depends on where we see weird failures.08:58
pittiinfinity: we could also add retry-once-on-regression, I figure08:58
pittibut I don't have that yet; I want to see infra problems exposed for now08:58
infinitypitti: Yeah, let's not paper over problems we don't have just yet.08:59
Mirvdoko: ok, I'm very puzzled now but I'll try to reproduce it in chroot or something08:59
infinitypitti: 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
infinitypitti: So, y'know, was just a drive-by whine. :)09:00
dokoMirv, you uploaded to trusty ... ;-P09:00
pittiinfinity: .. which seems settled for now?09:00
Mirvdoko: I'm not familiar with qt4's webkit, but if it's any same as qt 5 then it probably bundles its own javascriptcore fork09:00
infinitypitti: Well, they worked on the second try, so "yes".09:00
pittiinfinity: there is one AMQP queue per release and arch, so we can retry tests on that granularity09:00
Mirvdoko: ahhahah...09:01
pittiinfinity: I mean settled wrt. the new stuff09:01
Mirvdoko: thanks ...09:01
infinitypitti: Oh, yeah.  New stuff having a granularity of DAS seems just fine by me.09:01
pittiinfinity: 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 evening09:01
infinitypitti: (DistroArchSeries in LP talk, if that was gibberish to you)09:01
dokocjwatson, could you get the haskell component mismatches under control?09:01
pittiinfinity: nah, I figured :)09:01
infinitypitti: 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
infinitypitti: But I'm guessing it's lightweight and hackable enough that you can extend it later.09:03
pittiinfinity: yes, no problem; but I plan on adding PPA support as arguments of a release/arch/package test request09:04
pittiinfinity: as PPAs are orthogonal to selecting a distro name09:04
infinitypitti: Quite, they're an archive.09:05
pittiinfinity: my selfish motivation is to move my manual daily-ish systemd upstream CI test to that cloud thing ASAP :)09:05
infinitypitti: 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:06
pittiinfinity: shouldn't be, as long as we have some available cloud image to run tests in09:07
infinitypitti: (For instance, PPAs can exist for both ~user/ppaname/ubuntu and ~user/ppaname/ubuntu-rtm)09:07
pittithe only exercise is to map something like "trusty-amd64" to an image09:07
pittiPPAs will always be added/dist-upgraded on the fly per-test, so they are easier09:08
infinitypitti: 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
pittiinfinity: we could always set up a vmdebootstrap daily cron job09:08
pittias long as that distro is buildable out of debootstrap (which really ought to be a given -- if not, go away)09:08
pittiin fact I'd like to do that for at least Debian sid09:09
infinitypitti: 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
pittiI locally run it occasionaly, but nicer to have some machine do it for me09:09
pittirunning a test on Debian is certainly something that interests me, and I do it locally all the time09:09
pitti(with vmdebootstrap image)09:10
infinitypitti: There are a lot of things I'd like to do with Debian in Canonical infra...09:10
infinitypitti: Like provide PPAs.09:10
infinitypitti: Which we should have done years ago.09:10
infinitypitti: But now that Debian's supposedly planning their own version, perhaps it's too late to be good citizens and do so.09:10
dokoMirv, 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:13
dokoahh, Debian's version has additional qt5 packages09:15
Mirvdoko: 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 it09:17
Mirvoh, not accidentally, 2.1.0-0ubuntu1 was stuck in proposed, so probably on purpose09:17
sitterqca2 is qt4, qca2-qt5 is qt5. I am not sure why it would depend on qtbase5 in debian09:20
dokoahh, Debian builds from one source09:21
sitterthat would explain it I guess09:21
sitterthere was some upstream tension over supporting qt5 in the same (upstream) source tarball which is why we ended up with two source packages09:21
dokoMirv, sitter: is there a short doc how to use the pkg-kde-tools to update the qt/kde symbols files?09:22
Mirvdoko: 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 result09:23
sitterdoko: http://pkg-kde.alioth.debian.org/symbolfiles.html look for 'pkgkde-symbolshelper batchpatch'09:23
sitterthere's also this bugger which supposedly automatically gathers up all logs from launchpad and patches them in http://paste.ubuntu.com/8573918/09:26
cjwatsondoko: 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:33
cjwatsondoko: 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:35
cjwatson... applying a code change may be hard to get past the security team.10:36
infinity*cough*Go*cough*10:38
mitya57cjwatson, python3 -m markdown <foo.mkd >foo.html10:41
mitya57main-friendly :)10:41
cjwatsonWhich is fine by me, but somebody will have to test that for ffms2 - I'm not going to have time10:42
mitya57Will need a tiny bit of patching10:46
mitya57cjwatson, doko: http://people.ubuntu.com/~mitya57/tmp/pymkd.diff, after that10:55
mitya57sed s/---/-/g doc/ffms2-api.md | python3 -m markdown -x fenced_code -x headerid >doc/ffms2-api.html10:55
mitya57Can upload that if you want10:56
cjwatsonIt's fine by me10:56
cjwatsonThanks10:57
mitya57So doing that10:57
infinitymitya57: If the implication there is that the upstream docs aren't 100% correct markdown, could you push a patch upstream too?11:11
infinitymitya57: (Or is that a bug/misfeature in the py3 md parser?)11:11
mitya57Doing that already :)11:11
cjwatsonpython-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:12
infinityOf course they do.11:13
infinityI would expect nothing less from the people who brought me PEP-8.11:13
=== Ionic is now known as Guest99726
cjwatsonBut you're not bitter.11:14
infinityNot even a little.11:14
mitya57Actually pandoc (which is used in Debian) behaves the same as Python-Markdown11:15
mitya57http://johnmacfarlane.net/babelmark2/?text=-+Item+1%0A++-+Item+2%0A++-+Item+3%0A-+Item+411:15
cjwatsonOdd, so why didn't that fail before?11:16
cjwatsonOh, I guess it kind of did.  Just more warnings or something?11:17
mitya57No, it just rendered it as a single list, not as list + sublist11:18
mitya57Oh, python-markdown is in main while python3-markdown isn't11:19
mitya57So let's pull the latter too :)11:20
infinitymitya57: If they're from the same source, that's a no-op.11:20
mitya57Yes11:20
infinityFixing now.11:20
mitya57Uploaded & submitted upstream as https://github.com/FFMS/ffms2/pull/22211:21
infinitymitya57: Promoted.  I'm sure your upload will beat the promotion, so you might need to retry if it doesn't dep-wait properly.11:23
mitya57Huh, the pandoc doesn't even render lists correctly11:24
mitya57And codeblocks11:24
* mitya57 files a Debian bug11:25
mitya57amd64 and i386 already built, the others will hopefully build too11:25
infinitymitya57: Oh, that's cause ffms2 is in universe.11:26
infinityI assume c-m exploded cause something else is trying to pull it in.11:26
mitya57:-/11:26
infinityx264, looks like.11:26
mitya57Anyway I fixed the docs because pandoc was broken :)11:26
infinityHeh.11:26
infinitySounds sensible to me.11:26
infinitystgraber: We still have ltsp wanting mate-desktop.  Wasn't someone going to fix that?11:28
ogra_to what ?11:28
ogra_(Unity7 isnt really remote friendly)11:29
infinityogra_: To whatever it was before the merge from Debian? :P11:29
mitya57If 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 VNC11:30
infinityThat shows up in a couple of places.  Probably just needs the prefs inverted and we're good.11:30
infinityI 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
infinityogra_: Well, he still has a delta, so that's not working out.11:31
ogra_oh ?11:31
infinityogra_: But, if that's the plan, it should probably drop out of main.  Which I'd be fine with too.11:31
ogra_why would you drop it from main ?11:32
infinityogra_: To avoid pulling MATE in.  Or whatever other random deps Debian adds.11:32
ogra_ah ... well, i guess that should be fixed :)11:33
mitya57infinity, another solution which doesn't require delta will be killing mate dependency in debian as well11:35
ogra_or just re-ordering11:35
infinityThe Debian order seems deliberate, from the changelog.  THey want to prefere mate.11:36
infinityWhich is fine.11:36
infinityBut doesn't work for us.11:36
infinityBut I'm not sure why it's even *in* our supported seed anyway.11:36
infinityI still assume that's just from way back when all flavours were in main.11:36
infinityAnd that hasn't been a reality for years.11:36
Guest99726mitya57: 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 myself11:37
ogra_infinity, well, we developed it (mainly) ... it is a part of edubuntu (which falls under your last statement)11:38
infinityogra_: 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
mitya57Guest99726, it was a problem not in gnome-flashback, but in gnome-session, is fixed now11:38
mitya57There may be problems with gnome-shell, but flashback should work11:39
Guest99726okay11:39
shadeslayerchrisccoulson: no firefox update for precise?12:46
=== _salem is now known as salem_
mdeslaurshadeslayer: I'm sure chrisccoulson would welcome some help to fix bug 147194913:04
wgrantchrisccoulson: It seems you dropped my arm64 build fix in your recent wily firefox upload.13:05
infinitychrisccoulson: (which should also have ended up in all the stable branches too, but I didn't commit to anything but wily, sorry)13:06
roaksoaxinfinity: 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:24
infinityroaksoax: Why are the SRU versions higher than the wily version?13:33
infinityroaksoax: Oh, you literally just uploaded the matching wily one.  Okay.13:34
larryoneHi,  the Amazon AMIs for vivid are still labeled as DEVEL - is that intentional?13:43
larryoneare there any vivid AMIs that are production ready?13:43
infinityutlemming: ^13:44
larryone(looking at http://cloud-images.ubuntu.com/locator/ec2/, the dropdown for Version refers to 15.04 DEVEL only)13:47
roaksoaxinfinity: indeed :) I uploaded wily first though, I guess it takes more time to show up provided it has to build and all13:47
roaksoaxinfinity: and thank you!13:48
infinitylarryone: That's probably just a display bug, those should have been marked stable when vivid released.13:49
infinitylarryone: But Odd_Bloke or utlemming can confirm and fix.13:49
larryoneinfinity, yea, just looking now under http://cloud-images.ubuntu.com/releases/15.04/release-20150707/13:49
larryonelooks like I can fire away with it13:49
rbasakpitti: 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.gz14:02
pittirbasak: err yes, absolutely; that should really not be in a specific package14:04
pittirbasak: but rather in /usr/share/apport/general-hooks/ubuntu.py or even generic.py14:04
pittithat's actually nice14:05
pittiI've been annoyed for years by the tons of "postinst failed with exit code 1" bug reports which didn't otherwise have any useful log14:05
pittiwith systemd we finally have some generic way of extracting information at least14:05
rbasakWell, the init.d error output served me well in the past14:06
rbasakBut I think systemd swallows that now14:06
pittiwell, 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
rbasakRight14:07
rbasakThe 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 anyway14:07
stgraberinfinity: 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 instead14:07
pittirbasak: right, but I thought your goal was to avoid having to create individual package hooks for that?14:08
rbasakpitti: isn't that unavoidable if a daemon insists on writing to its own logfile only?14:08
rbasakOr can systemd pick that up somehow?14:09
pittirbasak: ah, of course14:09
pittibut then the journal should at least say "pid 123 died with SIGSEGV" or so14:09
tewardi was pinged xD14:09
rbasak"pid 123 exited with status 1"14:10
rbasak:)14:10
pittiso for stuff not just logging to the journal we of course still need per-package hooks14:10
pittibut at least for the journalling ones we could generalize14:10
rbasakYep. No need to block teward's SRU for that though I hope.14:10
pittiand we already have everything of level "warning" and above in bug reports14:11
tewardrbasak: already poked infinity and it was 'accepted14:11
pittijust not info etc.14:11
tewardrbasak: [2015-07-13 09:58:42] -queuebot/#ubuntu-release- Unapproved: accepted nginx [source] (vivid-proposed) [1.6.2-5ubuntu3.1]  <--14:11
pittiso in theory the JournalErrors.txt should have most errors already14:11
tewardpitti: https://launchpadlibrarian.net/208651217/JournalErrors.txt  <-- see https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/146338314:11
rbasakDoesn't that assume that every daemon is logging in a way that ends up in the journal with appropriate levels?14:11
stgraberinfinity: manually applying the change vagrantc said he'd push to Debian and uploading that to wily14:11
tewardpitti: that's why i wrote the hooks i needed in there14:11
rbasakI don't think either of those are true14:12
tewardpitti: as it stands systemd is swallowing the failure reasons14:12
tewardwhether that's the nginx start script or systemd I am not sure which is swallowing14:12
tewardbut it's not putting usable info into that errors page14:12
tewards/page/file/14:12
pittihm, is nginx of Type=forking?14:12
rbasakI 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:12
pittiwell, stderr is exactly what goes into the journal :)14:13
pitti(and stdout too)14:13
tewardi'll have to check the type, it might be forking...14:13
rbasakBut not in the bug14:13
rbasak(AIUI?)14:13
tewardpitti: yes it's type forking14:14
pittiType=forking14:14
pittiExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid14:14
pittierr yes14:14
pittithat eloquently avoids all logging of course :)14:14
* teward grumbles14:14
pittithis is just wrong -- start-stop-daemon should never be used in a unit14:14
tewardpitti: Debian doesn't know how to do it then14:14
teward:p14:14
pittiyeah, this is waaay to complicated14:14
pittiteward: ok, now I understand your frustration :)14:15
tewardpitti: i internalize most of that ranting.  or go to the gun range to vent it.  but in either case, yes, frustration!14:15
tewardpitti: IMO the package hooks I did for nginx for Vivid and Wily are just a workaround to the core issue14:15
tewardbut solve the failure to get usable bug info on the postinstall script failure14:16
pittiyeah, that unit should be fixed properly14:16
tewardat least for the flurry of bugs we've seen currently14:16
teward(which rbasak is well familiar with xD)14:16
pittiteward: yes, your hook looks fine as a workaround for at least vivid14:16
pittiExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'14:16
pittiExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'14:16
pittiExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload14:16
pittithis just can't be right14:17
pittiwhy does this have to be called twice?14:17
tewardpitti: and Wily, for now, as I put the hooks there too14:17
teward(they landed in Wily first)14:17
pitti(bbl)14:18
shadeslayermdeslaur: oh wow that looks mental14:23
mdeslaurshadeslayer: yeah :)14:24
dokojamespage, ping on debian #77805814:38
jamespagedoko, sorry14:38
jamespagedoko, oh - I'm going to get that removed14:39
jamespagedoko, along with percona-xtradb-cluster-5.514:39
jamespagewe don't have those in Ubuntu any longer, and upstream can't commit the time to maitaining them in Debian14:40
dokook, thanks14:40
dokojamespage, also, who should sort the ruby component mismatches? server (-> puppet), or foundations? it won't be me this time14:41
jamespagedoko, I'll have to pass that over to rbasak and smoser :(14:47
smoserpitti, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/147352714:50
smoserdoes 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:50
pittismoser: I can't answer that off the top of my head, need to investigate14:51
smoserdoko, i hope that'd be rbasak i guess.14:51
pittismoser: with the tee'ing to journal+console it might be that /dev/console is already opened/busy?14:51
smoserpitti, that does make sense. but you'd think it would fail all the time then.14:56
smoseri guess systemd must be reading output from program, then opening /dev/console and closing /dev/console for each time it writes or something.14:56
smosermeaning i only race on it.14:57
pittiright; 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
pittisupposedly because of that14:59
pittibut as I said, I don't have firm knowledge about this, need to investigate14:59
infinityTime for an ubuntu-cloud plymouth theme that cloud-init can write pretty progress to? :)15:00
ogra_lol15:01
infinity(not being entirely facetious; that's the whole point of plymouth is multiplexing console I/O)15:01
smoserpitti, thanks.15:13
smoseryou'd think /dev/console can be opened multipel times.15:13
smoserotherwise i'd expect really arbitrary failures in a lot of places... anywhere that writes to /dev/console  to sometimes fail.15:14
smoserand 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
smoseras that would then be a race condition.15:15
smoserit sure would be nice to have a way to write to all 'console=' items that was safe to use.15:15
=== ubott2 is now known as ubottu
=== ming is now known as Guest86022
=== Malsasa_ is now known as Malsasa
dokoW: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/wily-proposed/main/i18n/Translation-en  Hash Sum mismatch15:48
dokoW: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/wily-proposed/universe/i18n/Translation-en  Hash Sum mismatch15:48
dokocan't get a clear apt-get update ...15:48
tewardshoutout to pitti for the excellent guidance on apport package hooks.15:48
tewardrbasak: 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
ubottuLaunchpad 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]15:49
=== Ionic is now known as Guest32033
larryoneinfinity, thanks for you're advice from earlier, now up and running in our test environment with 15.0417:11
larryoneour first systemd machine =0)17:12
tewardinfinity: 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:16
tewardinfinity: 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 confirmed17:36
=== dpm is now known as dpm-afk
=== Guest32033 is now known as Ionic
smoserinfinity, would you care to take a look at https://bugs.launchpad.net/ubuntu/+bug/147409018:50
ubottuLaunchpad bug 1474090 in Ubuntu "ppc64 cloud images boot only once" [Undecided,New]18:50
=== alvesadrian is now known as adrian
yofelcyphermox: hi, did you make any progress with updating the packagesets?21:57
SpamapScjwatson: 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?22:03
=== gammax90 is now known as gammax
DavieySpamapS: MBR or GPT?22:59
cjwatsonSpamapS: No /boot would probably require some customisations to various GRUB defaults involving /boot/grub.  It should be workable but may require runtime tweaks.23:09
=== salem_ is now known as _salem
cyphermoxyofel: oops.23:55
cyphermoxwill re-run, perhaps here it will work faster23:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!