[02:08] <Mattman> hi peoples
[03:48] <Gleichsnerd> !help
[03:48] <Gleichsnerd> Gah, shoot. Nevermind.
[06:34] <micahg> Rhonda: did you test build ejabberd before syncing it?
[06:41]  * ajmitch syncs another package (yes, test-built locally)
[06:43]  * micahg hugs ajmitch
[06:43] <ajmitch> I've still got a lot of catching up to do :)
[06:45] <ajmitch> still a lot on http://qa.ubuntuwire.com/bugs/rcbugs/ to check over though
[06:48] <micahg> yeah, oneiric seems to still be the default there
[06:48] <ajmitch> shouldn't be, I changed it
[06:48]  * micahg was going to skim for new version RC bug fixes
[06:48] <micahg> ah, is fixed now, thanks
[06:48] <ajmitch> was a recent fix :)
[06:48] <ajmitch> smokeping needs a sync, open CVE
[06:49] <ajmitch> patiently waiting for pbuilder to process ftpmirror :)
[06:49]  * micahg test builds chromium in a clean chroot before uploading
[06:53]  * micahg plans to do another run through the upgrade-software-version bugs tomorrow night to see what can be updated quickly
[06:54] <ajmitch> I saw a merge of pbuilder waiting in ~ubuntu-sponsors
[07:17] <ajmitch> it's nice when a debian NMU references an LP bug as well, will a sync using syncpackage automatically close that?
[07:18] <micahg> I think so, although, I don't remember the final outcome of that discussion
[07:18] <ajmitch> I'll try it & see
[07:18] <ajmitch> it's bug 756657
[07:19] <broder> certainly old-style syncs would close those
[07:19] <ajmitch> right
[07:20]  * broder sighs. the sponsorship queue is still getting longer
[07:22] <ajmitch> broder: how long is it now?
[07:23] <broder> 63
[07:23] <broder> in fairness, 1/4 of those are just from today
[07:23] <ajmitch> people trying to get in before FF?
[07:23] <broder> seems likely
[07:24] <broder> and, let's see, only 14 of them are from before 2/1
[07:24] <ajmitch> so at least people aren't havng to wait very long
[07:25] <ajmitch> micahg: I see what you mean about ejabberd - I was looking at some other build fallout bugs from the erlang transition in debian, might be a little late to do that for precise :)
[07:27] <ajmitch> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653966 was the bug I was looking at - the removal of patches because of a newer erlang got me a bit worried about just syncing it
[07:33] <Rhonda> micahg: duh, the new erlang not in precise, right  %-/
[07:34] <Rhonda> micahg: So actually, it would need a sourceful upload with dropping the versioned b-d on erlang (reverting git commit c352294)
[07:35] <Rhonda> .. erlang transition in precise is out of scope, right? :)
[07:36] <ajmitch> Rhonda: I'm sure there's plenty of time to get it done :)
[07:36] <Rhonda> I am not that deeply involved in erlang besides ejabberd, and I am uncertain about the required impact
[07:37] <ajmitch> I think it has potential for a lot of small problems
[07:38] <ajmitch> http://lists.debian.org/debian-release/2011/12/msg00296.html doesn't look too bad though
[07:43] <Rhonda> ajmitch: jep, that fix is in ejabberd, and it got uploaded to unstable in debian in the meantime :)
[07:43]  * ajmitch would be more worried about couchdb
[07:43] <philipballew> Question: to package a deb for debian/Ubuntu, how much actual coding/programing is required? I have herd different things from different people.
[07:44] <ajmitch> philipballew: "it depends"
[07:44] <ajmitch> it's possible to package something with barely touching a thing
[07:45] <ajmitch> or you may have to end up digging into the code & writing patches to solve some problems
[07:45] <Rhonda> ajmitch: couchdb got binNMUed and I am not aware of any serious bugreports because of the transition
[07:45] <ajmitch> this is why you hear different things from different people, the packages are different :)
[07:46] <ajmitch> Rhonda: ubuntu's couchdb is still stuck at 1.0.1
[07:46] <ajmitch> debian has 1.1.1
[07:46] <Rhonda> right
[07:46] <Rhonda> well, I will do a sourceful upload for ejabberd then, dropping the version
[07:46] <broder> i'm pretty sure that our couchdb is just a little bit of conffile testing away from being at 1.1.1
[07:46] <ajmitch> ok :)
[07:46] <Rhonda> and when you decide to bring e15 into the boat, you always can issue a build1 package :)
[07:47] <ajmitch> broder: you've managed to dig through that MP?
[07:47] <broder> i did, and when all's said and done i'm actually satisfied with it
[07:47] <ajmitch> great
[07:48] <broder> except that jderose's updates move a conffile between packages, and i want somebody to test whether or not that's going to trigger a conffile conflict
[07:49] <philipballew> thank you
[07:49]  * ajmitch does not have a current precise VM for testing, but how bad can it break my laptop? :)
[07:49]  * broder disclaims all repsonsibility for the state of ajmitch's laptop
[07:50] <ajmitch> btw, that bug was closed with syncpackage
[07:50] <micahg> cool, that's the way it should be :)
[07:51] <Rhonda> ajmitch: 2.1.10-2ubuntu1 would be the proper version, right?
[07:52] <ajmitch> Rhonda: yep
[07:53] <Rhonda> ajmitch: So, can I just dput ubuntu, or would it need to go through some approval?
[07:54] <Rhonda> Guess I just dput because I am MOTU, but this is my first sourceful upload :)
[07:54] <ajmitch> you're in MOTU, it's in universe
[07:54] <ajmitch> should be fine
[07:55] <Rhonda> duh
[07:55] <ajmitch> as we said, what can possibly go wrong? :)
[07:55] <Rhonda> hmm, if I doesnt include the orig tarball it fetches it from debian, right?
[07:56] <ajmitch> no, it uses what's already been synced from debian
[08:08] <ajmitch> micahg: that's a lot of CVEs for chromium there
[08:30] <Rhonda> ajmitch, thanks for the headsup, is built now :)
[08:35] <ajmitch> Rhonda: don't thank me, thank micahg
[08:36] <Rhonda> oh, right
[08:36]  * Rhonda hugs micahg :)
[08:39] <micahg> ajmitch: indeed
[12:11] <arand> tumbleweed: The Ubuntu-FTBFS for cube2font is fixed in Debian now, would you have time to re-view the sync request?
[12:11] <bkerensa> https://code.launchpad.net/~bkerensa/ubuntu/precise/liboggz/fix-for-789179/+merge/93191
[12:22] <geser> bkerensa: can you please forward this also to Debian and/or upstream so we don't have to carry this delta for long (if it didn't already happen)
[12:24] <bkerensa> geser: I will forward
[12:29] <geser> thx
[12:34] <bkerensa> geser: Is there a easy way to turn my changes into a diff to submit upstream
[12:34] <bkerensa> or will they take a .patch?
[12:53] <geser> there is a tool "submittodebian" which helps with it, but as I didn't use it yet myself you might want to doublecheck what exactly gets forwarded to Debian
[13:03] <tumbleweed> it gives you a chance to edit the patch
[13:17] <tumbleweed> arand: done
[13:17] <arand> tumbleweed: thanks! :)
[13:18] <tumbleweed> it was a good test case for bug 931644 :)
[14:38] <scott-work> ubuntu studio is still working on getting the lowlatency kernel into universe and needs one more advocate :)  http://revu.ubuntuwire.com/p/linux-lowlatency
[14:39] <scott-work> anyone who feels capable of reviewing it, please do so, i believe we need another advocate before tomorrow
[15:00] <tumbleweed> bdrung: fixed a pile of easy bugs, will upload u-d-t now
[15:02] <bdrung> tumbleweed: thanks. will sponsor-patch bail out for missing binaries before it starts?
[15:05] <tumbleweed> bdrung: doesn't bail out, just warns
[15:05] <bdrung> k
[15:05] <tumbleweed> (probably less than ideal, but it isn't obvious what programs its going to need)
[15:05] <bdrung> tumbleweed: maybe doing the check after reading the parameters?
[15:06] <tumbleweed> that still doesn't tell us if its a bzr branch or a patch
[15:06] <tumbleweed> (and I thought printing out the warning when you do --help isn't a bad idea)
[15:10] <ockham> hi, i'd like to merge scribus from sid, but i'm a bit confused about merging documentation at the wiki. i'm not a motu, so do i just file a merge request at launchpad? or also build a merged version and upload it to REVU?
[15:12] <geser> ockham: first you don't need REVU for a merge
[15:12] <ockham> geser: okay; but i'm not a MOTU, so if I do work on the package, how make it available for upload?
[15:13] <geser> you can only file a merge request once you have a branch in LP which is ready to get merged (sponsored)
[15:13] <tumbleweed> ockham: provide a debdiff (against debian) or a bzr branch
[15:13] <geser> "provide a debdiff" = file a bug and attach the debdiff to it
[15:13] <ockham> ok, i'll try that
[15:14] <tumbleweed> ockham: btw, don't forget we have feature freeze tomorrow evening. work fast :)
[15:14] <geser> or merge a package which doesn't introduce new features
[15:15] <tumbleweed> or request an exception, if the new features are important
[15:15] <ockham> i think it's quite straight-forward, so i shouldn't take too long
[15:18] <ockham> oops, scribus is in main. is that a problem?
[15:19] <tumbleweed> ockham: no
[15:21] <geser> ockham: it shouldn't matter for you if you need a core-dev or a MOTU as sponsor
[15:22] <ockham> yikes. just tried debdiff on debian's and ubuntu's .dsc files, and as debian has a new upstream version, that's quite long.
[15:23] <ockham> ubuntu has an RC for 1.4.0, debian a post-1.4.0 svn revision
[15:23] <ockham> will that be a problem?
[15:23] <ockham> the reason i'd like to update is that some relevant bugs got fixed by upstream in between...
[15:25] <ockham> tumbleweed, geser: ^
[15:26] <tumbleweed> ockham: the version in ubuntu is based on a previous version from debian
[15:26] <tumbleweed> compare against that
[15:26] <tumbleweed> (or just grab diffs from mom (merges.ubuntu.com, see grab-merge)
[15:31] <ockham> tumbleweed: ok, i'm not sure i'm getting this right. the merge request will require a debdiff from the debian version i'd like to base it on, right?
[15:31] <ockham> and grab-merge complains that there is not entry for scribus on m.u.c
[15:32] <tumbleweed> ockham: yes, that's usually the easiest diff to review
[15:32] <ockham> tumbleweed: but in my case, it will contain a long list of upstream changes
[15:33] <tumbleweed> ok, MoM was recently broken and is probably still catching up
[15:33] <tumbleweed> err, a merge shouldn't end up wit ha long list of upstream changes
[15:33] <tumbleweed> the diff should show the desired changes between debian and ubuntu
[15:34] <ockham> but what if, as in this case, debian is based on a newer upstream version?
[15:34] <tumbleweed> so provide a diff from that
[15:34] <ockham> tumbleweed: hm, makes sense
[15:35] <tumbleweed> https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[15:35] <tumbleweed> I think MoM is also currently running against wheezy (our default sync source) not sid
[15:36] <tumbleweed> (our default sync source for LTSs)
[15:37] <geser> ockham: grab the current delta (mom or from packages.qa.debian.org), apply it on the new debian version (and check if those changes are still needed or perhaps also fixed in debian/upstream), generate new debdiff for you patched version (compare to the unpatched debian version)
[15:37] <ockham> geser: that sounds good, i'll try it
[15:38] <geser> that's what MoM does (without the checking, that left for the merger)
[15:39] <geser> it's not black magic :)
[15:43] <ockham> geser: ok, i've tried to apply http://patches.ubuntu.com/s/scribus/scribus_1.4.0.dfsg~rc3+svn20110401-1.1ubuntu1.patch to the current debian source, but patch -p 1 fails -- and it's not obvious to me, why, as the .rej files look quite feasible
[15:45] <tumbleweed> ockham: pull-lp-source -d scribus && pull-debian-source -d scribus 1.4.0.dfsg~rc3+svn20110401-1.1 && debdiff ....
[15:52] <ockham> tumbleweed: same result. the debdiff that line produces is probably the same as the one found on patches.ubuntu.com, no?
[15:53] <tumbleweed> yes, it should be
[15:53] <ockham> well it fails :-(
[15:53] <tumbleweed> so, yes, the patch probably won't apply cleanly, they almost never will
[15:54] <ockham> yeah, but it's strange -- see e.g. http://paste.ubuntu.com/843180/ for changelog.rej
[15:54] <tumbleweed> there'll be a new changelog entry in debian, that clashes with the ubuntu one
[15:55] <tumbleweed> so, I was wrong, not "almost never will", "never will"
[15:56] <ockham> ok, so it's copy-pasting stuff from the patch to those files.
[15:56] <ockham> oh well, not so trivial after all...
[15:57] <ockham> i'll probably get back to it later...
[15:57] <ockham> thx so far!
[15:57] <tumbleweed> look at merge-changelog
[15:57] <tumbleweed> it'll sort that bit out for you
[16:26] <pabelanger> mdeslaur: ping
[16:26] <mdeslaur> pabelanger: hi!
[16:27]  * pabelanger waves
[16:27] <mdeslaur> pabelanger: what's up?
[16:27] <pabelanger> mdeslaur: re: bug 931859
[16:27] <pabelanger> the patch is actually from upstream
[16:27] <pabelanger> and the file permissions are already changed in the -common package
[16:27] <mdeslaur> pabelanger: ah!, yeah, reading your update now
[16:28] <pabelanger> greast
[16:28] <mdeslaur> pabelanger: ok, thanks for the explanation
[16:28] <pabelanger> great*
[16:28] <pabelanger> np
[16:28] <pabelanger> I should have adding something to the debdiff
[16:28] <pabelanger> will next time
[16:31] <mdeslaur> pabelanger: ok, ACK on the debdiff. I'll update the bug and upload it in a sec. Thanks!
[16:31] <pabelanger> danke
[18:30] <Corey> Oh what the...  + git-dch --auto --debian-branch=master
[18:30] <Corey> You are not on branch 'master' but on '(no branch)'
[18:30] <Corey> Use --debian-branch to set the branch to pick changes from
[18:30] <tumbleweed> sounds like you aren't on a branch...
[18:31] <Corey> Sure, but to fix that it suggets passing --debian-branch=master, which I'm doing.
[18:31] <tumbleweed> I don't think it realises that you aren't on a branch. It just sees that you aren't on the branch that it's expecting to use
[18:32] <Corey> tumbleweed: Sure, but a "git checkout master" before the git-dch also fails.
[18:32] <tumbleweed> presumably not with the same error
[18:33] <Corey> Indeed.
[18:33] <Corey> (I'm trying to have Jenkins automatically build on commits)
[18:33] <Corey> With the checkout master beforehand, http://pastebin.com/WKiBMqTL
[18:33] <tumbleweed> missing a pull?
[18:33] <Corey> It's Jenkins, it should have pulled automatically.
[18:34] <Corey> I can explicitly throw it in there.
[18:34] <Corey> But it seems counterintuitive.
[18:34]  * tumbleweed doesn't know jenkins, and has never doen what you are trying to do. But I can read error messages / output and give interpretation :P
[18:42] <Corey> tumbleweed: Yeah, the git pull sorted it.
[18:42] <Corey> Seems wrong, but if it works, who'm I to argue? :-)
[18:42] <Corey> But the git-dch --auto now isn't incrementing the version string in changelog
[18:44] <Corey> Ooh, I may have to throw a -S into it.
[18:44] <Corey> Man pages, not just for bathroom reading. :-p
[18:44] <tumbleweed> :)
[18:45] <_ruben> i have a local repo using mini-dinstall where i push my pbuilder generated packages. what would it take to be able to add downloaded .deb packages to such a repo?
[18:45] <_ruben> downloaded from 3rd parties that is
[18:45] <_ruben> no source packages or anything
[18:47] <tumbleweed> _ruben: I don't know mini-dinstall, but I assume it is driven by .changes files, like the archive
[18:47] <tumbleweed> so, generate .changes files
[18:47]  * _ruben tries some google-foo based on that :)
[18:48] <_ruben> the use of pbuilder got me lazy in that respect, all needed files are generated for me ;)
[18:48] <tumbleweed> .changes are usually generated by dpkg-genchanges. You can drive it by hand
[18:48] <_ruben> had just found that cmd in the debian maint guide :)
[18:49] <_ruben> lets see
[18:53] <_ruben> hmm .. dpkg-genchanges seems to work on a source tree, and all i got is the binary package
[19:01] <ockham> geser, tumbleweed: okay, i've produced a debdiff. anyone mind uploading? https://bugs.launchpad.net/ubuntu/+source/scribus/+bug/932962
[19:01] <_ruben> guess crafting it by hand it is
[19:01] <tumbleweed> ockham: I can't, but someone from ubuntu-desktop or a core-dev can
[19:01] <tumbleweed> !sponsorship
[19:01] <tumbleweed> ockham: ^
[19:02] <tumbleweed> _ruben: probably the easiest, although you could cheat and create all the files dpkg-genchanges needs, but that's probably harder
[19:03] <_ruben> tumbleweed: yeah
[20:12] <jtaylor> when exactly does feature freeze take effect?
[20:12] <micahg> jtaylor: per https://wiki.ubuntu.com/PreciseReleaseSchedule, 21:00 UTC tomorrow
[20:14] <jtaylor> thx
[20:15] <pabelanger> I have a debdiff for bug 897006 but it's also include another bug fix.  Should I create 2 different debdiffs?  Or can 1 close 2 issues?
[20:15] <pabelanger> would like to make sure it gets uploaded before tomorrows freeze for 12.04
[20:19] <tumbleweed> pabelanger: so would everyone, there's been a big rush on the sponsorship queue
[20:19] <pabelanger> tumbleweed: ack'd
[20:19] <pabelanger> always the case
[20:19] <pabelanger> just want to make sure I make the request easy as possible
[20:21] <tumbleweed> pabelanger: did you see the comments in the debian changelog wrt nsca-client?
[20:23] <pabelanger> tumbleweed: yes, I talked to the upstream maintain a while back and at the time they thought it was a waste of resources.  After working with the debian maintainer, the next release in Sid will actually start building the package
[20:24] <pabelanger> but that package has not been merged into sid yet
[20:24] <tumbleweed> pabelanger: I see a comment which says "Add possibility to locally build an nsca-client package which cannot be in Debian.
[20:24] <tumbleweed> do you know the logic behind that?
[20:25] <pabelanger> right, see my above comment about waste of resources
[20:25] <tumbleweed> what kind of resources?
[20:25] <pabelanger> HDD space in the repository
[20:25] <pabelanger> I know
[20:26] <tumbleweed> ok, that's probably not an issue :)
[20:26] <pabelanger> indeed
[20:26] <tumbleweed> please amend the bug, rather than saying "I don't know why"
[20:28] <pabelanger> tumbleweed: and done
[20:28] <pabelanger> thanks
[20:45] <kklimonda> when did Ubuntu start using 3.0 source format?
[20:45] <micahg> kklimonda: it's supported in Lucid on
[20:45] <kklimonda> ah, thanks
[21:00] <jtaylor> can someone apt-file bin/rsvg in precise please
[21:00] <jtaylor> my is acting up
[21:04] <jtaylor> I can't locate that in precise ._.
[21:05] <jtaylor> a bug 931802
[22:27] <Corey> Seeing a pbuilder failure on broken deps, but I can't quite understand why it's breaking: http://pastebin.com/3bFPC6U1
[22:27] <jtaylor> I prefer PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi"
[22:27] <jtaylor> tends to give better error messages
[22:29]  * micahg also prefered the gdebi resolver with pbuilder
[22:46] <Corey> jtaylor: Toss that into .pbuilderrc?
[22:46] <jtaylor> yes
[22:46] <Corey> Or as an environment variable?
[22:46] <Corey> Ah.
[22:53] <Corey> jtaylor: http://pastebin.com/Bux5wUup
[22:54] <Corey> Hmm.  It looks like that package isn't installable in the pbuilder, but clearly exists elsewhere.  Is there a sane way to show whcih repository it came from on the installed box?
[22:54] <broder> Corey: do you have universe disabled in your pbuilder or something?
[22:58] <Corey> broder: Not sure.  I didn't do anything magic to create it, which may explain it.
[22:59] <tumbleweed> Corey: do a pbuilder update and see if it mentions anything besides main
[22:59] <Corey> tumbleweed: Just main.
[22:59] <Corey> That'd do it.
[22:59] <Corey> Time to fix my pbuilderrc