[02:53] <vipzrx> hello
[03:25] <vipzrx> hello ,everyone
[06:31] <Noskcaj> if kirkland or andreseal is online, get them to ping me please
[11:37] <jamespage> jodh, around? have you seen upstart doing something like this before: http://paste.ubuntu.com/5683425/
[11:47] <cjohnston> cjwatson: I believe /7
[11:48] <cjohnston> sorry. I believe I have an email pending on ubuntu-devel.. when you get a chance, could you please ack it
[11:53] <cjwatson> cjohnston: done
[11:53] <cjohnston> ty cjwatson
[12:51] <jodh> jamespage: it looks correct based on what the somewhat elaborate .confs specify. I've never used ceph though :)
[12:52] <jamespage> jodh, the ceph processes are OK - I just wondered why there are not proc 1 owned (the sh wrapper is)
[12:53] <jamespage> i.e. init -> sh -> ceph-mon for example
[12:53] <jodh> jamespage: because the job doesn't specify "exec" in the script stanza so upstart spawns ad shell to run what is in that stanza.
[12:53] <jamespage> jodh, "exec /usr/bin/ceph-mon --cluster="${cluster:-ceph}" -i "$id" -f"
[12:53] <jamespage> looks OK to me
[12:55] <jamespage> jodh, full listing - http://paste.ubuntu.com/5683597/
[12:55] <cjwatson> ${cluster:-ceph} requires a shell to evaluate it
[12:55] <jodh> jamespage: ah - well, upstart cleverly detects that the exec line specifies shell syntax, and so passes the arguments through /bin/sh for you (otherwise, it wouldn't work :)
[12:55] <cjwatson> See init(5) - "Any special characters, e.g. quotes or `$' specified will result in the entire command being passed to a shell for expansion."
[12:55] <jamespage> cjwatson, jodh: ah! right - I thought it might be something like that
[12:55] <jamespage> thanks
[12:56] <jodh> jamespage: in your case, "$" is used, which causes the shell to be spawned.
[14:27] <cjwatson> Any MIR folks want to have a look at graphite2?  It's a bit inconvenient for texlive to be uninstallable in saucy-proposed.
[14:29] <infinity> cjwatson: It has no bug filed.
[14:30] <infinity> cjwatson: (Also, I'm about to go nap, yay long weekend, but if someone like jdstrand or mterry doesn't beat me to it, I'll look at it when I wake up)
[14:30] <ogra_> oh, canada too ?
[14:31] <cjwatson> Yeah, I was tracking down the version of texlive-bin that introduced the build-dep before filing a bug
[14:31] <cjwatson> But it's not in the changelog so that's involving a bit of downloading
[14:31] <infinity> Hrm.  If graphite2 is a simple evolution of silgraphite2.0, you can just promote it without an MIR.  You might want to poke the sources and see if it's just a renaming of the upstream project.
[14:31] <cjwatson> Oh, hadn't twigged to silgraphite2.0
[14:32] <cjwatson> I'll see if the build-dep changes bear that out
[14:33] <cjwatson> Looks like libgraphite-dev (>= 1:2.3.1) -> libgraphite2-dev
[14:34] <cjwatson> -  --with-system-graphite  use installed silgraphite headers and library
[14:34] <cjwatson> +  --with-system-graphite2 use installed graphite2 headers and library
[14:34] <infinity> cjwatson: Yeah, I was more curious if it really is basically just a new version of the same source.
[14:34] <infinity> Or if it's an entirely new and differently sketchy version of a similar library.
[14:35] <cjwatson> Also would be nice if we could only have one in main
[14:36] <infinity> Yeah, that's probably easily solved.  libgraphite3 has almost no rdeps.
[14:37] <cjwatson> Hmm.  If it's the same thing, it's laid out very differently.
[14:37] <infinity> *&%! tarball-in-tarball packaging of silgraphite2.0 makes diffing a bit of a pain. :P
[14:37]  * infinity unpacks.
[14:37] <cjwatson> Though graphite2's debian/copyright says http://sf.net/projects/silgraphite
[14:38] <cjwatson> Which says "Graphite2, a new version of the Graphite engine"
[14:38] <tumbleweed> tarball-in-tarball isn't dead yet? :/
[14:39] <tumbleweed> infinity: are there any significant differences between PPA and primary archive chroots / environment? I'm trying to figure out why pypy PPA builds are hanging on a particular test
[14:39] <infinity> cjwatson: The layout's completely different, but if the upstream's the same, I'm all for screaming "la la la", and swapping them.
[14:39] <cjwatson> There seems to be a kind of spiritual ancestry here but I'm getting more of a rewrite-from-scratch sense
[14:39] <infinity> cjwatson: texlive is the only thing in main that depends on it.
[14:41] <infinity> tumbleweed: The chroots are identical, installed packages could differ if you haven't let your PPA depend on -proposed (it's a twiddle), and kernels could be different (virtual PPAs are hardy kernels on Xen, non-virt builders are precise kernels on bare metal)
[14:41] <cjwatson> http://projects.palaso.org/projects/graphitedev/wiki
[14:41] <cjwatson> Oh, I guess c-m-proposed doesn't want to drop silgraphite2.0 yet because binary deps aren't yet up to date
[14:41] <tumbleweed> infinity: ok, that gives me some things to play with. thanks
[14:42] <cjwatson> infinity: OK, sounds like "swap it", then - I'll make that happen today
[14:43] <cjwatson> I have a bit of a chain of stuff on top of this.
[14:43] <infinity> cjwatson: Bonus points if we could ditch the old one entirely, but who knows if pango-graphite is ported.
[14:44] <cjwatson> infinity: Probably have to wait for Debian there
[14:45] <infinity> cjwatson: We didn't end up breaking the world with a tex transition this time at least, I hope?  Just this component oops?
[14:45]  * infinity has nightmares about having to rebootstrap tex* crap yet again.
[14:45] <cjwatson> Hope not, but can't tell yet.
[14:46] <cjwatson> texlive-bin doesn't seem to have tight build-deps.
[14:46] <infinity> Well, the killer used to be that we carried a delta on exactly one tex* package, and if we let autosync sync the rest, it would skew and none of it would build anymore.
[14:46] <cjwatson> Or indeed to build-dep on anything texish.
[14:47] <cjwatson> I *think* we got rid of that delta ...
[14:47] <cjwatson> Wasn't that tex-common?
[14:47] <infinity> Yeah, that delta was in texlive-bin, I think.
[14:48] <cjwatson> I've spent the best part of a day cleaning up bits in -proposed.  I should probably do some actual work at some point ...
[14:48] <infinity> Heh.  At least it was your work day.
[14:48] <cjwatson> https://launchpad.net/builders/ - are the armhf builders a bit sad?
[14:48] <cjwatson> 47 minute queue, allegedly 7 builders idle.  I suspect porkies.
[14:48] <infinity> cjwatson: They lost track of a PDU that happened to be the only way to stab a bunch of the Pandas, so as they've been dying for other reasons, they've been unrecoverable.
[14:49] <infinity> I'm told this is in progress.
[14:49] <cjwatson> Oh dear
[14:49] <infinity> The idle buildds are suspicious, though.
[14:49] <cjwatson> Yeah, sounds more like buildd-manager fail.
[14:49] <infinity> That could be a Network Event causing a mass Right to Choose exercise.
[14:51] <NikTh> Hello everybody.
[14:52] <infinity> Anyhow, I'm going to go enjoy my freedom to not be tied to a laptop for a day.
[14:52] <NikTh> QUESTION: Do I have to do something special in order for debuild to sign a .dsc file when I want to upload a custom kernel on a PPA of mine ?
[14:53] <infinity> NikTh: Just run "debsign foo.changes" on the changes file that you plan to upload.
[14:53] <NikTh> I uploaded without problems a custom package of unity-tweak-tool in my PPA ..
[14:54] <NikTh> But I'm not able to debuild correctly a custom kernel. Deubild does not product a .dsc file (only source.changes is not enough)
[14:55] <NikTh> infinity: Thanks I will try that immediately
[14:56] <NikTh> I will describe here step by step what I'm doing right now.. (anyone who wants to help.. welcome)
[14:56] <NikTh> 1) I'm downloading the source code of linux-image-3.8.0-21-generic
[14:58] <NikTh> I'm patching the kernel.. "patch -p1 < ~/foo.patch
[14:59] <NikTh> 3) Now editing the changelog file (dch -i)
[15:00] <NikTh> Ok, what is the next command ?
[15:01] <NikTh> debuild -S -sd -k<keyid> , is that correct ?
[15:06] <NikTh> The results are "Successfully signed changes file" (but not .dsc file created)
[15:15] <cjwatson> NikTh: You're making life hard for yourself by passing -sd.  Why?
[15:16] <cjwatson> I never use -sd.
[15:16] <cjwatson> NikTh: But as for the rest of it, debuild -S should be sufficient to create a .dsc.  Post the whole output on a pastebin.
[15:17] <NikTh> cjwatson: because the source code already exist in Ubuntu repositories. Despite that I used debuild -S -k (without -sd) but the results were the same.
[15:18] <infinity> NikTh: Also, due to the hilarious way the kernel is packaged, dch -i won't do what you think it will.
[15:18] <infinity> NikTh: It's going to update debian/changelog, and then when the clean target runs, debian.master/changelog will get copied over debian/changelog. :P
[15:20] <NikTh> Full terminal results here: http://pastebin.com/mKbn2ggu
[15:21] <NikTh> Yes, yes, yes you have right about this infinity . Overrides my debian/changelog. But how can I fix that ? So I told before that MY source.changes file is exactly the same as the original :P  LoL
[15:22] <infinity> NikTh: "dpkg-source: info: building linux in linux_3.8.0-21.32.dsc"
[15:22] <infinity> NikTh: It built just fine, just with the old changelog.
[15:22] <NikTh> Hahahaha
[15:22] <infinity> NikTh: So, do your 'dch -i', then "cp debian/changelog debian.master/changelog", then do your debuild.
[15:23] <NikTh> hmm.. lets see
[15:23] <cjwatson> NikTh: already exists> -sd is not as necessary for that as you think it is.
[15:25] <NikTh> cjwatson: I've read the instructions here> https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage (see the "options when building" paragraph)
[15:25] <cjwatson> -sd only makes any difference if you are packaging a *new upstream version* and have some specific reason not to include the upstream tarball in the upload.  Which is basically never the case - I haven't needed -sd in 14 years of development.
[15:25] <cjwatson> Yeah, that advice is, well, maybe not wrong as such but pointless.
[15:26] <cjwatson> You can quote me on that.
[15:26] <cjwatson> Anyway, it's not actually the problem here, just a confusing red herring.
[15:27] <cjwatson> -sa *is* sometimes needed because, unlike Debian, our versioning for new upstream versions isn't nearly-always predictable by dpkg-genchanges.
[15:27] <NikTh> Thanks cjwatson . I have no reason to doubt about your development skills. I'm a newbie in ubuntu-devel and just followed the instructions there :-)
[15:28] <cjwatson> Yeah, I appreciate that it's often easiest to just follow the docs.  I didn't realise we were recommending -sd to people.
[15:31] <NikTh> OK, now I did what infinity suggested (cp debian/changelog ...etc) . What is the most correct command for debuild ? debuild -S -k<keyid> (correct cjwatson ? )
[15:32] <cjwatson> Yep, that should be fine.  You can put DEBSIGN_KEYID=<keyid> in ~/.devscripts so you don't have to type it all the time.
[15:32] <cjwatson> So most of the time for ordinary uploads I just use 'debuild -S'.
[15:32] <NikTh> Thanks !
[15:34] <iBelieve> I sent a message to the ubuntu-devel mailing list about a week ago with an idea for Click Packages, but I don't think it ever got posted (I checked the archives, and it isn't in there). Is there a way to see if it got sent to the list, or should I just resend it?
[15:35] <cjwatson> it's probably in the mod queue
[15:35] <cjwatson> I've flushed the remaining click-package-related things out of there now
[15:38] <iBelieve> cjwatson, thanks, that is what I thought, but it just seemed a long time
[15:38] <cjwatson> yours was in there
[15:39] <iBelieve> cjwatson, good, that's nice to know that it actually did send.
[15:40] <NikTh> Victory !!!
[15:40] <NikTh> infinity, cjwatson  !! Thanks a lot. :-)
[15:40] <rbasak> infinity: I've redone the facter merge and included SRU debdiffs for precise, quantal and raring in bug 1173265 - also including a fixes for bug 1170325. Could you have a look when you get in, please?
[15:42] <infinity> rbasak: Long weekend here (I'm both asleep and not at my computer, and possibly also partying and drunk right now), but if you poke me tomorrow, I'd be happy to review and sponsor the lot. :)
[15:47] <rbasak> infinity: will do - thanks!
[15:50] <NikTh> And the e-mail just arrived " Accepted: " :-) :-)
[16:40] <sil2100> Hello, is there anyone from the SRU team here right now?
[16:50] <zequence> I'd like some help with targetting this bug to releases quantal and precise https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1163638, anyone?
[16:52] <bdmurray> kirkland: do you have any plans to SRU bug 1173209?  If not I'll work on it today.
[16:52] <kirkland> bdmurray: go for it
[16:52] <kirkland> bdmurray: I'll verify it for you, if you like
[16:52] <bdmurray> kirkland: I'll let you know thanks
[16:53] <kirkland> bdmurray: thank you!
[17:25] <psusi> shouldn't /etc/os-release identify the specific ubuntu flavor installed?  i.e. Ubuntu Studio or kubuntu?
[17:26] <Riddell> psusi: they're all the same os
[17:30] <psusi> hrm... I guess so..
[17:57] <iBelieve> I've reinstalled Ubuntu several times for various reasons (switching derivatives, etc) so now I have 3 OpenPGP keys (a new one and 2 old ones). Do I need the old ones, or can I delete them?
[17:57] <iBelieve> ^^ OpenPGP keys in my Launchpad account.
[18:12] <tumbleweed> iBelieve: if you aren't going to be signing things with the old ones, you don't need them
[18:14] <iBelieve> tumbleweed, since I don't have them on my computer, no I won't be. Will deleting them affect things that I've already signed, like the Code of Conduct or projects I've contributed to?
[18:14] <tumbleweed> no
[18:15] <tumbleweed> in future, I recommend revoking keys before you lose control of them (or just back them up)
[18:17] <iBelieve> tumbleweed, Okay, thanks for the help and advice.
[18:27] <stgraber> @pilot in
[18:50] <lifeless> barry: so, you suggested we could arrange a chat about image upgrades
[18:50] <barry> lifeless: yep.  stgraber ^^
[18:52] <stgraber> yep, can definitely find some time this week. Today's a public holiday here though so trying to minimize work-related time ;)
[18:53] <lifeless> fair enough
[18:53] <lifeless> what tz's are you both in?
[18:55] <stgraber> we're both on EDT (US/Canada eastern)
[18:56] <lifeless> stgraber: current local time for you?
[18:56] <stgraber> 3pm
[18:59] <lifeless> how about my thursday, your wednesday, at your 1600 ?
[19:01] <barry> lifeless: that would work for me
[19:02] <lifeless> I'd only have 30-45m then, but that's enough to have a solid chat.
[19:02] <stgraber> works for me
[19:04] <slangasek> stgraber: this is officially my worst dpkg hack ever (ifupdown)
[19:04]  * Laney is excited to see it
[19:05] <stgraber> slangasek: haha, yeah, I figured it'd have to be pretty ugly after I read your comment on the cause of the problem ;)
[19:06] <slangasek> Laney: uploaded, enjoy ;P
[19:07] <slangasek> (tested for precise conffile state -> 0.7.5ubuntu4; precise conffile state -> 0.7.5ubuntu3 w/ "no" response -> 0.7.5ubuntu4; precise conffile state -> 0.7.5ubuntu3 w/ "yes" response -> 0.7.5ubuntu4; raring conffile state -> 0.7.5ubuntu3 -> 0.7.5ubuntu4; raring conffile state -> 0.7.5ubuntu4)
[19:08] <slangasek> the only case this doesn't test for is the possibility that in the *next* version of ifupdown the user installs, the md5sum of the conffile changes again
[19:08] <slangasek> in that case, we probably get another conffile prompt :/
[19:09] <slangasek> (only for the precise -> 0.7.5ubuntu4 -> somethingelse case, fwiw)
[19:12] <slangasek> stgraber: ^^ so that means that if you have any reason to change /etc/init.d/networking for saucy+1, we'll need some additional maintainer script handling at that point ;)
[19:13] <stgraber> slangasek: I don't plan on changing it myself, can't speak for Andrew though, he loves changing things ;)
[19:14] <slangasek> stgraber: yeah ;)  but if you *merge* a change, too :)
[19:17] <lifeless> stgraber: whats your ubuntu email ?
[19:17] <stgraber> lifeless: stgraber@ubuntu.com
[19:19] <lifeless> stgraber: barry: invity thing sent
[19:20] <barry> lifeless: cool
[19:21] <catbus1> Anyone know when kernel freeze will be for 12.04.3? No such info on https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
[19:27] <mlankhorst> catbus1: raring kernel is used
[19:30] <catbus1> mlankhorst: the kernel freeze date for LTS point release is for new hardware support, right? raring kernel is already frozen, only critical patches/fixes can go in as SRU.
[20:53] <cjwatson> Laney: Could you merge (ish) the new fonts-dejavu package from Debian?  It's needed to make texlive-fonts-extra installable again.
[20:54] <cjwatson> And you're touched-it-last and ttf-dejavu
[20:54] <cjwatson> s/and/on/  # how did that happen?
[20:54] <geser> spell-checker? :)
[20:54] <cjwatson> Evil things (so no)
[21:14] <mwhudson> doko__: hey, are you around?
[21:48] <Laney> cjwatson: a renamed source package?
[21:48] <Laney> I'm sure I can manage that
[21:50] <cjwatson> Yep, the usual ttf -> fonts dance.  Thanks