[10:52] <Laney> nigelb: I see you offered gwibber help in debian #573822 (reminded by http://identi.ca/notice/88168234) — want sponsorship? :-) :-)
[10:52]  * Laney grins
[11:07] <iulian> Good Laney!
[11:08] <iulian> He always has something to offer.
[11:08] <Laney> I live to please.
[11:10] <Daviey> poor nigelb
[11:13] <Laney> Ongoing (regular) maintenance might not be that hard if a bzr branch gets set up which we can merge the Ubuntu packaging branch with…
[11:14]  * Laney looks aruodn
[13:15] <jtaylor> I wonder how wakeup made it into the archive, that thing is full of security holes
[13:17] <Laney> let me guess
[13:17] <Laney> ...an Ubuntu local package?
[13:17] <jtaylor> yes
[13:17] <Laney> funny
[13:18] <jtaylor> saw dozens of potential issues and one definite priv escl. just by looking at a diff ...
[13:20] <Laney> If only we had a good policy for kicking out shoddy apps
[13:20] <Laney> in Debian it would be RC bugs and therefore not released
[13:21] <tumbleweed> I don't ithkn we need one, kick it
[13:21] <stgraber> file a package removal bug (after contacting whoever got the package in Ubuntu in the first place)
[13:21] <Laney> absolutely it can be done, but having a policy gives things more weight, no?
[13:21] <tumbleweed> we should review ubuntu-only packages with high severity bugs once a cycle or so
[13:21] <Laney> and lets people stop them getting in
[13:22] <tumbleweed> well, we're working hard on that :)
[13:22] <tumbleweed> we stop anyone getting anything in :P
[13:22]  * Laney can think of another time we failed ...
[13:22]  * Laney coughs
[13:23] <tumbleweed> that wasn't actually dangerous, just low quality
[13:23] <tumbleweed> I thought micahg was going to find a serious security problem in it? :)
[13:24] <Laney> well I would probably put the barrier at a different place :P
[13:26] <Laney> argh I grepped for sudo in wakeup's source
[13:27] <tumbleweed> ubuntu-dev-tools also overuses sudo a bit :/
[13:27] <tumbleweed> (but safely, I think)
[13:27] <jtaylor> sudo + predicatable tmpfilename = bad
[13:28] <jtaylor> see data/scripts/wakeup
[13:28] <jtaylor> data/scripts/wakeup +67
[13:29] <Laney> maybe ARB does have a use :-)
[13:29] <jtaylor> and it uses os.system all over the place with non constant arguments
[13:29] <jtaylor> though the author is responsive, it could be fixed
[13:31] <tumbleweed> yeah, I suspect we need a repo somewhere for everyone to upload their junk to, to get their warm fuzzy feelings, before they become competant, trustworthy developers
[14:42]  * tumbleweed wonders if anyone has ever used a signed .changes file from -changes to mess with another developer's PPA
[14:43] <psusi> you mean upload the same package they uploaded to main into their ppa?
[14:43] <Laney> yes, I did once, to demonstrate why it was bad
[14:43] <Laney> where are you seeing a signed one?
[14:43] <tumbleweed> -changes has signed .changes files
[14:44] <Laney> heh
[14:44] <tumbleweed> psusi: yeah, you'd have to use the upload url mangling trick to do any real damage, though (to put it into a release that didn't have that version)
[14:44] <tumbleweed> Laney: glad to see I'm not the first person to wonder this :)
[14:44] <Laney> the case I got it fixed for was from +queue
[14:44] <Laney> this was ages ago
[14:51] <savvas> is the symbols file required for a debian library package?
[14:51] <jtaylor> not required but strongly recommended
[14:54] <savvas> thank you :) one more question: how do I file a new bug needs-packaging? Because now +filebug in launchpad redirects me to use ubuntu-bug and I cannot file a bug report without a package name
[15:05] <Ampelbein> savvas: https://bugs.launchpad.net/ubuntu/+filebug shouldn't redirect to ubuntu-bug.
[15:05] <Laney> yes it should
[15:05] <Laney> you need to add ?no-redirect to that URL unless you are in bug control
[15:06] <Ampelbein> ... That's interesting, thanks.
[15:06] <savvas> thank you!
[16:35] <softcoder> anyone here know who to ask about debian games getting puleld into ubuntu?
[16:36] <tumbleweed> what's the question?
[16:36] <softcoder> I worked with pabs and got megaglest to replace glest, its been in debian testing since jan 2 but it never got puleld into ubuntu
[16:37] <softcoder> just wondering why not (pabs also thought it was strange)
[16:37] <tumbleweed> it's a new package
[16:37] <tumbleweed> they have to be manually reviewed
[16:37] <tumbleweed> give it time
[16:37] <softcoder> gotcha, its not really new, its a 'transition' or replacement
[16:38] <tumbleweed> right, but that still means it has to go through the NEW review
[16:38] <softcoder> ok, how long does that process usually take?
[16:39] <tumbleweed> < 1 month. Someone should do a final cleanup of new around DIF
[16:39] <softcoder> ok thx for the info
[16:42] <micahg> nothing in NEW ATM, we need the new package sync first :)
[16:42] <tumbleweed> well, for new packages from debian the review happens before the source upload
[16:43] <micahg> not AIUI, they just get stuck in NEW and there they have to be reviewed
[16:52] <ahasenack> hi guys, can someone take a look at this merge proposal for python-tz? https://code.launchpad.net/~ahasenack/ubuntu/precise/python-tz/day-leap-fix-885163/+merge/87407
[18:05] <ahasenack> hi, can someone take a look at this merge proposal, or should I ask in #ubuntu-motu, since it's a universe package? https://code.launchpad.net/~ahasenack/ubuntu/precise/python-tz/day-leap-fix-885163/+merge/87407
[18:17] <broder> ahasenack: i can look at it. one moment
[18:18] <broder> (you are asking in #ubuntu-motu, though :-P)
[18:18] <ahasenack> broder: thanks
[18:18] <ahasenack> broder: oh, I thought that second question was in #ubuntu-devel, I got my tabs mixed :P
[18:23] <broder> ahasenack: in the interests of getting a simple test that i can understand, tz=pytz.timezone('Pacific/Apia'); datetime(2012, 1, 1, tzinfo=tz) - datetime(2011, 12, 30, tzinfo=tz) == 1, right? As opposed to now, when it's 2?
[18:24] <ahasenack> broder: you mean, besides the backtrace test I pasted in the comments?
[18:25] <broder> ahasenack: aha, got it
[18:28] <broder> tumbleweed, bdrung: :-/ sponsor-patch started calling debuild with --no-lintian, which oneiric's debuild doesn't support
[18:30] <bdrung> broder: really?
[18:31] <broder> uh...hmm
[18:31] <broder> it does look like it has it doesn't it?
[18:31] <broder> i wonder what my laptop was whining about
[18:32] <bdrung> broder: i am running oneiric with latest u-d-t without having problems
[18:33] <broder> bdrung: yeah, i think something else went wrong. will dig into it later. looks like a false alarm for the moment, though
[18:35] <broder> ahasenack: uploaded
[18:35] <ahasenack> broder: that's precise, right?
[18:35] <broder> right
[18:35] <ahasenack> broder: thanks!
[18:35] <broder> ...i was going to open the sru bug tasks for that bug, but apparently i can't. wtf'
[18:35] <ahasenack> broder: yeah, we have to ask someone for that
[18:35] <ahasenack> broder: but let me prepare the sru template first
[18:35] <ahasenack> broder: with justification, impact, etc
[18:36] <broder> ahasenack: unless something changed very recently, motu could open the bug tasks
[18:36] <broder> oh, i see. i'm looking at the upstream bug task
[18:36]  * broder glares at lp
[18:38] <broder> ahasenack: ok. tasks are open
[18:38] <ahasenack>  broder thanks
[18:51] <ahasenack> broder: can you also take the review from that mp? It's still "pending"
[18:51] <broder> ahasenack: it got marked as merged
[18:52] <ahasenack> broder: yeah, but the review request itself is still pending: Ubuntu branches: Pending requested 2012-01-03
[18:52] <broder> i've merged the branch - any review would just be a formality. the mp should fall off the sponsorship queue the next time it runs, because its state isn't "needs review"
[18:53] <ahasenack> ah, ok
[19:02] <l3on> Hi all.. I'm looking at a orphaned package, in the many lintian errors I see:
[19:02] <l3on> W: ferret: command-with-path-in-maintainer-script postinst:18 /usr/bin/update-mime-database
[19:02] <l3on> and in postinst I have:
[19:02] <l3on> # Deregister our X Desktop Group Shared MIME-info Database info
[19:02] <l3on> if [ -x /usr/bin/update-mime-database ] ; then
[19:02] <l3on>         /usr/bin/update-mime-database /usr/share/mime
[19:02] <l3on> fi
[19:02] <l3on> is it still necessary update mime ?
[19:03] <l3on> does someone of you know how can I fix it?
[19:03] <jtaylor> does it use debhelper?
[19:04] <jtaylor> if yes dh_installmime will fill postinst correctly
[19:04] <jtaylor> with is something like this: http://paste.ubuntu.com/795189/
[19:06] <l3on> jtaylor, I use dh 8, yes :)
[19:07] <l3on> jtaylor, so, have I to delete those lines from postinst, right?
[19:07] <jtaylor> if you use dh_installmime their probably redundant and can be removed
[19:07] <jtaylor> l3on: ukopp and dkopp ftbs in precise due to a zfuncs.h issue, did you get my mail?
[19:08] <l3on> jtaylor, yeeeepppp you're right!
[19:08] <l3on> damn it :/
[19:08] <l3on> I'll look at them i
[19:08] <l3on> in one hour
[19:08] <jtaylor> upstream said he'll release a new version 1. jan if you could package that and add it to debian that would be great
[19:08] <jtaylor> but its not very urgent
[19:09] <l3on> well, considering that debian import freeze is coming... :P
[19:09] <l3on> lol
[19:09] <jtaylor> we can still sync manually
[19:09] <l3on> ah oki :)
[19:10] <l3on> sorry for not reply, but when I received mail I was in holydays with family and a little bit busy :/
[19:10] <l3on> jtaylor, anyway... my ferret rules is like:
[19:10] <l3on> # Deregister our X Desktop Group Shared MIME-info Database info
[19:11] <l3on> if [ -x /usr/bin/update-mime-database ] ; then
[19:11] <l3on>         /usr/bin/update-mime-database /usr/share/mime
[19:11] <l3on> fi
[19:11] <l3on> opsss... sorry:
[19:11] <l3on> %:
[19:11] <l3on> 	dh $@
[19:11] <l3on> I suppose that dh_installmime is called somewhere
[19:11] <tumbleweed> easy enough to find out :)
[19:12] <jtaylor> make sure the postinst contains the debhelper token
[19:12] <jtaylor> (lintian will warn if not)
[19:43] <nigelb> Laney: I do want to help, when I find more time. Currently packed schedule.
[20:18] <Alison_Chaiken> Greetings all, my project needs a newer version of another project than upstream is offering as a package.
[20:18] <Alison_Chaiken> I want to use the recommended procedure to address this problem, assuming I can understand it.
[20:19] <Alison_Chaiken> From reading the Policy, I have the impression that I can package master/HEAD of project foo and distribute it with my other packages, as long as I use debian/watch to update when the latest foo is offered by upstream as a package.
[20:20] <Alison_Chaiken> Is this more or less correct?
[20:21] <Alison_Chaiken> I understand that what I want to avoid is that a year from now, my users have the old version of foo that I distribute today -- we want them to get an upstream update when it's available, which may not be long for all I know.
[20:27] <Alison_Chaiken> I see that when I git-pull the last tagged release of an upstream, I get their debian directory.
[20:27] <tumbleweed> Alison_Chaiken: why do you need a newer version? massive changes or a single patch?
[20:27] <Alison_Chaiken> When I pull master/HEAD, I don't get one.
[20:27] <tumbleweed> Alison_Chaiken: is this upstream a package in Ubuntu, or are we talking about a PPA
[20:28] <Alison_Chaiken> tumbleweed, one of my collaborators sent a patchset to the upstream, which they liked, but which is not yet part of a release.
[20:28] <tumbleweed> we can just cherry-pick that patch for Ubuntu
[20:28] <Alison_Chaiken> My packages are in a PPA; what I'm patching is qjson, which is the RESTful part of Qt.
[20:29] <tumbleweed> right, qjson is part of debian & ubuntu
[20:29] <tumbleweed> you can just package the latest head of it in your PPA
[20:29] <tumbleweed> as it's a PPA, don't worry about the watch file, just make an orig tarball from the latest upsteram HEAD
[20:30] <tumbleweed> (or cherry-pick that patch, for a qjson upload to your ppa)
[20:30] <Alison_Chaiken> I can just git-pull master/HEAD from qjson and then debuild it?
[20:31] <Alison_Chaiken> I upload it to my ppa and call it . . . qjson?
[20:31] <jtaylor> use an appropriate version number, e.g. one that replaces current ubuntu package but would get replaced by next one
[20:31] <tumbleweed> rather try and create a .orig.tar.gz from upstream HEAD, and treat it as if it was an upstream release
[20:31] <tumbleweed> but with a version number like 0.7.1+git20110106
[20:32] <Alison_Chaiken> Upstream is at 0.7.1; I could package their master/HEAD and call it 0.7.1.1 so that when 0.7.2 is released by them, users are offered an update?
[20:33] <tumbleweed> Alison_Chaiken: that looks like an upstream version, though
[20:33] <tumbleweed> it's better to make it clearer that you packaged a random revision
[20:33] <Alison_Chaiken> tumbleweed, I had called the package I already uploaded qjson-`git rev-parse HEAD` but that broke all our project's build machinery: nothing linked against it. (Duh, in retrospect.)
[20:33] <tumbleweed> but again, this is a PPA, it doesn't really matter so much :P
[20:34] <Alison_Chaiken> Learning right procedure is good though.
[20:34] <tumbleweed> yeah, don't change the package name
[20:34] <Alison_Chaiken> I don't want to do something stupid just because I can!
[20:34] <tumbleweed> and don't use a git hash in a version, they don't increment
[20:35] <Alison_Chaiken> I could just solve the problem with the usual cascade of symlinks in /usr/lib of course, too, and make postinst or whatever that script is called do the right linking.
[20:35] <Alison_Chaiken> But I'm having trouble figuring out what the cool kids do here, since this problem obviously arises every day for everyone.
[20:36] <tumbleweed> err, why the symlinks in /usr/lib?
[20:36] <Alison_Chaiken> I could symlink qjson-123ac.so.1.0.0 to qjson.so in /usr/lib.
[20:36] <tumbleweed> oh, did it require an ABI change?
[20:37] <Alison_Chaiken> But users still wouldn't be offered an update when 0.7.2 actually is released.
[20:37] <Alison_Chaiken> No, no, no ABI change: sorry to be misleading.
[20:38] <Alison_Chaiken> What I actually did so far is package master/HEAD and call the package qjson-712b15 and put it in my ppa.
[20:39] <Alison_Chaiken> It installs fine, but the other binaries didn't link against it, due to the stupid name, even though apt knows they depend on it.
[20:39] <tumbleweed> right, don't rename it :)
[20:40] <tumbleweed> you can keep the same name as debian
[20:41] <Alison_Chaiken> I created my debian directory from the dh_make templates.   Perhaps what I need to do to have a happy ending is to copy upstream's debian directory and (ahem) properly amend it to reflect my use of HEAD?
[20:41] <tumbleweed> yes
[20:41] <tumbleweed> it's really just like any other modification ubuntu makes, from debian
[20:43] <Alison_Chaiken> So if I call my package libqjson0, as Ubuntu does, and use qjson's debian directory and just change their metadata, that's cool?
[20:44] <Alison_Chaiken> And my users will be offered new qjson when it drops?
[20:44] <tumbleweed> yes
[20:45] <Alison_Chaiken> When they install my main package, which depends on libqjson0, I just need to make sure they get the one in my ppa, not the upstream.
[20:46] <Alison_Chaiken> I guess if the names are the same, that's the tricky part.
[20:47] <jtaylor> thats what version numbers are there :)
[20:47] <Alison_Chaiken> But maybe that dance has to do with configuring the PPA, not the package.
[20:47] <jtaylor> Depends: libqjson0 (>= 0.7.1+gitwhatever)
[20:48] <Alison_Chaiken> In the control file of the other packages, I see.
[20:48] <jtaylor> though thats also not so great in the case of a soname bump
[20:48] <Alison_Chaiken> So my package is called libqjson0, but the version is set in the metadata . . . like debian/changelog?!
[20:49] <jtaylor> yes first line of the changelog
[20:49] <Alison_Chaiken> Oh, so all I have to do is change the version number of the changelog?
[20:49] <jtaylor> add a new entry with dch -vnewversionnumber
[20:50] <Alison_Chaiken> Excellent!   Packaging is easy ;-)
[20:50] <Alison_Chaiken> Thanks very much tumbleweed and jtaylor.
[20:50] <jtaylor> if you only have to patch an existing one its very simple
[20:50] <Alison_Chaiken> As I said, it's much easier to understand how to turn the crank on these programs than to do figure *what* to do sometimes.
[20:51] <tumbleweed> yeah, cherry picking is probably simpler than HEAD, if the patch applies cleanly
[20:51] <Alison_Chaiken> I'm off to read "dch --help" or "man dch" or whatever.
[20:51] <jtaylor> its just a convinience program to add a correctly formated changelog entry
[20:51] <Alison_Chaiken> WIll do, tumbleweed.
[20:52] <Alison_Chaiken> jtaylor, I already noted that debuild is picky about changelog format!
[20:52] <tumbleweed> Alison_Chaiken: here's an example where I've supported generating both released and VCS builds with get-orig-source: http://anonscm.debian.org/viewvc/python-apps/packages/ibid/trunk/debian/rules?revision=7444&view=markup
[20:53] <Alison_Chaiken> Thank you very much, tumbleweed.    I *think* I grok all this now.    I will study your example.
[20:53] <tumbleweed> (that one uses revision numbers rather than dates)
[22:17] <Laney> nigelb: heh, OK. :-)
[22:56] <ockham> is there any such a thing as a debian import (sync) queue? or are debian packages from testing (or unstable, for not-LTS releases) just part of the regular ubuntu upload queue?
[23:00] <tumbleweed> new packages?
[23:10] <lifeless> ockham: they are mirrored across by an automatic process, no human accessible queue is involved; things that fail do need to be worked through, and that report is (or was anyhow) on MoM