[00:21] <Laney> mk-sbuild chroots seem to be very far from minimal
[00:21] <Laney> just noticed subversion being installed in a lenny one
[02:37] <funkyHat> I've posted a version bump debdiff which fixes mpd: https://bugs.edge.launchpad.net/ubuntu/+source/mpd/+bug/588253
[02:54] <cpscotti> Hey everyone, whats next for a SRU with verification-done? just waiting? ( bug 480772 )
[04:35] <darkwing-netbook> Question... is packaging for GNOME (Ubuntu) and KDE (Kubuntu) The same? I want to learn and I and KDE/Kubuntu user so as I take my journey I want to learn the KDE side if there is a difference
[05:22] <ScottK> cpscotti: Is it tagged 'verification-done'?  If so, then it's just a question of it having had enough age in proposed and then it will get copied to updates.
[06:44] <om26er> I have made an upload to revu should I subscribe ubuntu sponsers?
[06:46] <om26er> * to the bug report
[06:53] <dupondje> om26er: what bug # ?
[06:53] <om26er> bug 590048
[06:56] <dupondje> think it should just be on REVU
[06:56] <dupondje> not totally sure neither :)
[07:29] <YokoZar> ScottK: ugh so it appears that somehow we ended up with two versions of spring in the lucid archive
[07:29] <ScottK> YokoZar: Oops.
[07:30] <ScottK> How so?
[07:30] <YokoZar> ScottK: I think one was synced from debian ("spring") and the other was the upgrade of the one I made ("spring-engine")
[07:30] <\sh> ScottK, I just dist-upgraded to lucid yesterday, since then my dovecot sieve stuff is not working anymore...(not it's not the plugin s/cmusieve/sieve/ problem) and I can't see anything in the logfiles...any clue where I can have look to determine the problem?
[07:31] <ScottK> \sh: No.  That's the only issue I've heard of.  I'd ping ivoks when he's around.  He knows it better than I do.
[07:31] <ScottK> YokoZar: What's the state of spring/spring-engine relative to each other?
[07:31] <\sh> YokoZar, talk to ttx.. because I wanted to work on integrating spring into ubuntu for the ehcache stuff
[07:32] <\sh> s/I/he == ttx/
[07:32] <ScottK> \sh: Are you sure it's the same spring?
[07:32] <YokoZar> ScottK: lucid version of spring is unplayable and out of date.  Debian unstable version is up to date.  Lucid spring-engine is playable but one minor version behind debian unstable spring
[07:32] <\sh> argl..it RTS...hail double names
[07:33] <YokoZar> right that was one reason why I called it spring-engine to begin with
[07:33] <\sh> YokoZar, hmmm..then I think the java spring will be named after libspring-<foo>-java ?
[07:33] <YokoZar> If that makes more sense then yeah
[07:33] <ScottK> YokoZar: Then my recommendation would be to SRU the Lucid spring to be a dummy package that pulls in spring-engine and then do the reverse in maverick.
[07:34] <YokoZar> ScottK: Yeah that was my thought
[07:34] <ScottK> Then get spring-engine source removed in Maverick.
[07:34] <ScottK> We'll have to carry a diff until after then next LTS, but that's unavoidable now.
[07:35] <YokoZar> Well it was unavoidable when debian chose a different package name really
[07:35] <YokoZar> we'd always have to have the dummy package
[07:35] <ttx> \sh: https://launchpad.net/ubuntu/+source/libspring-2.5-java
[07:36] <\sh> ttx, yes...aren't there any binaries for spring java still?
[07:37] <ttx> \sh: "Missing build dependencies: libtiles-java"
[07:38] <\sh> ScottK, FAILED /etc/dovecot/conf.d/01-dovecot-postfix.conf overwrote my dovecot.conf settings
[07:39] <ScottK> You had a file called /etc/dovecot/conf.d/01-dovecot-postfix.conf?
[07:40] <\sh> ScottK, no I haden't my old config was in dovecot.conf
[07:40] <ScottK> Then it didn't overwrite it.
[07:40] <\sh> ScottK, but now installed dovecot-postfix created one 01-dovecot-postfix.conf and this overwrote the settings in dovecot.conf it seems
[07:40] <ScottK> It may have over-ridden it ....
[07:40] <\sh> because in it is still cmusieve
[07:40] <\sh> which is wrong
[07:41] <ScottK> We did an SRU to fix the sieve naming problem in dovecot-postfix.
[07:41] <\sh> ScottK, is it sill in proposed?
[07:41] <ScottK> Is it still in -proposed maybe?
[07:41] <ScottK> Heh.
[07:42] <ScottK> I'd say have a look.
[07:42] <ScottK> (it's very late here)
[07:42] <maco2> live lock on answers from each other now?
[07:43] <\sh> ScottK, still in proposed
[07:43] <ScottK> \sh: Give it a try and then mark it verified if it works.
[07:59] <dholbach> good morning
[10:07] <eric_> when is next revu motu meeting day?
[11:42] <kaushal> hi
[11:43] <kaushal> can some one here help me with my post on https://lists.ubuntu.com/archives/ubuntu-server/2010-June/004279.html ?
[11:55] <soren> kaushal: Did you read xtables-addons-common's package description?
[11:58] <kaushal> soren: is there a way to uninstall iptables ?
[11:58] <kaushal> I mean source
[11:58] <soren> Just delete it.
[11:58] <kaushal> where do i look for it ?
[11:58] <soren> You put it there.
[11:59] <kaushal> soren: i deleted it
[11:59] <soren> Then it's gone.
[11:59] <soren> this conversation is silly.
[12:00] <kaushal> soren: apologies
[12:01] <kaushal> I did that still it refers to iptables v1.4.4: Couldn't load match `ipp2p':/usr/local/libexec/xtables/libipt_ipp2p.so: cannot open shared object file: No such file or directory
[12:01] <kaushal> wierd
[12:01] <soren> You did what?
[12:01] <kaushal> I did apt-get purge iptables xtables-addons-common
[12:01] <kaushal> and reinstalled it
[12:03] <soren> Well, you clearly installed some other version of iptables in /usr/local
[12:03] <kaushal> yeah
[12:03] <soren> You probably want to get rid of that.
[12:03] <kaushal> yes
[12:04] <kaushal> soren: is there a way to remove it completely
[12:04] <soren> kaushal: You could rm the files completely. Incidentally, "rm" is short for remove.
[12:04] <dholbach> Adri2000: are you still working on bug 366532? somebody in #debian-ubuntu just asked me about the bug
[12:08] <kaushal> soren: i deleted it completely
[12:08] <kaushal> now the error i get is -bash: /usr/local/sbin/iptables: No such file or directory
[12:08] <kaushal> when i ran iptables -m ipp2p --help
[12:08] <Rhonda> kaushal: I think your question is better suited in #ubuntu, actually.  But a "rehash" should help you.
[12:09] <Rhonda> hmm, or what that is called.
[12:10] <kaushal> Rhonda: i did hash ldconfig
[12:11] <Rhonda> It's iptables that gives you troubles, not ldconfig. Just restart your shell session will get rid of the message too, and those questions are still better suited in #ubuntu.
[12:11] <kaushal> sure
[12:12] <kaushal> Rhonda: Thanks
[12:14] <kaushal> Rhonda: i rebooted the box
[12:14] <kaushal> still no luck
[12:16] <Rhonda> kaushal: I'm sorry but I won't continue this in here because this clearly is the wrong channel for your question, see #ubuntu instead for end-user trouble shooting. Sorry.
[12:16] <kaushal> Rhonda: ok
[12:16] <xteejx> Hey guys, I'm messing around trying to package stuff for Ubuntu, more of a "learn to use my packaging skills" thing. Does it make a difference whether it is packaged for Ubuntu or Debian? i.e. can I package something purely for Ubuntu, and does it go over to Debian anyway or is that nothing to worry about?
[12:18] <Rhonda> xteejx: There is nothing going over to Debian, the workflow only does the other direction. Out of curiosity, why don't you want to have it in Debian?
[12:18] <xteejx> Rhonda: There's no reason, its just that the documentation for packaging for Ubuntu seems to be easier to follow
[12:18] <xteejx> I don't know how to package for Debian, barely even Ubuntu but getting there
[12:19] <Rhonda> It shouldn't be any difference, actually. :)
[12:19] <xteejx> Oh :)
[12:19] <Rhonda> If the package is proper for Ubuntu it should be proper for Debian too, lintian has only minor differences in Debian and Ubuntu.
[12:19] <xteejx> Oh cool, I've had no lintian errors or anything
[12:19] <Rhonda> And the policy isn't derived in relevant parts from what I know.
[12:20] <xteejx> That's handy then. So it's just a small change in the changelog really to reflect debian instead?
[12:21] <Rhonda> Usually yes. I think there is minor difference in the control file too.
[12:21] <Rhonda> Debian usually just uses Maintainer: field and nothing more in that respect that ubuntu does.
[12:22] <xteejx> One other question sorry for being a pain: Is it Ok to use dpatch with a single patch to change the Makefile? (I don't seem to be able to make the PREFIX bit work on its own)
[12:22] <xteejx> Oh that's good then :)
[12:22] <Rhonda> Oh, you aren't a pain. :)  And actually I'd settle for quilt instead of dpatch, but yes, using patches is a good thing instead of changing directly.
[12:23] <Rhonda> Some people would even suggest to you to use source format 3.0 (quilt) right ahead.
[12:23] <xteejx> Is there any documentation for quilt at all? (I have googled but its a bit mumbo jumbo dpatch seems dead easy)
[12:26] <xteejx> https://wiki.ubuntu.com/PackagingGuide/Howtos/Quilt found something :)
[13:27] <xteejx> Is anyone able to take a look at my debian/rules and Makefile please I think I've got it right but not totally sure http://paste.ubuntu.com/446080/ http://paste.ubuntu.com/446081/
[13:33] <xteejx> Anyone at all? Please :)
[13:35] <tumbleweed> xteejx: you can use "dh" for a much shorter debian/rules
[13:36] <xteejx> tumbleweed: How do you mean?
[13:36] <tumbleweed> you can use "install" instead of copy + chmod
[13:36] <tumbleweed> and instead of mkdir
[13:37] <xteejx> But that's what the upstream Makefile does I'm confused
[13:38] <tumbleweed> xteejx: oh, don't modify upstream makefile if you don't have to. I assume you pasted it because you wrote it
[13:38] <xteejx> Oh lol nope :)
[13:39] <xteejx> I ermmm nicked it for packaging it seemed a simple perl script would be easier to package for a first go than something complex :)
[13:40] <tumbleweed> xteejx: /usr/share/debhelper/dh_make/debians/rules is an example
[13:41] <tumbleweed> man dh for more
[13:41] <xteejx> tumbleweed: It's just dh $@   - what will that do?
[13:41] <sommer> morning
[13:41] <tumbleweed> xteejx: that calls dh with the rule name as a parameter
[13:41] <tumbleweed> man dh to see what it does then
[13:42] <xteejx> ok thanks
[13:42] <tumbleweed> xteejx: see http://kitenet.net/~joey/blog/entry/debhelper_dh_overrides/ for some more advanced usage
[13:42] <tumbleweed> (or look at packages using it)
[13:46] <carstenh> xteejx: if you don't like the short rules file just don't use it. there is nothing wrong with a longer one, although yours could be cleaned up
[13:47] <tumbleweed> and you have to understand what's going on in the longhand version to understand dh
[13:49] <xteejx> I understand the Makefile, dh is the problem
[13:50] <tumbleweed> xteejx: dh just calls all the debhelper scripts one would normally call, in the right order
[13:51] <tumbleweed> and it can correctly build some of the most common build methods without any configuration
[13:51] <BlackZ> xteejx: I'd replace PREFIX ?= /usr/local with PREFIX ?= /usr
[13:53] <tumbleweed> BlackZ: that was the upstream Makefile
[13:54] <BlackZ> tumbleweed: well, I think /usr/local should be replaced by /usr
[13:55] <tumbleweed> BlackZ: that can be passed on the make command line
[13:55] <tumbleweed> i.e. make PREFIX=/usr
[13:55] <BlackZ> tumbleweed: sure
[13:56] <xteejx> yeah I tried that with the package itself "make PREFIX=/usr" and it looked fine
[13:56] <BlackZ> xteejx: yeah, that works
[13:56] <xteejx> I think that's the only difference from the Makefile really, just how to put it into a rules
[13:56] <tumbleweed> xteejx: btw it's hard to evaluate your package just from the rules file. upload it to revu if you want decent feedback
[13:57] <BlackZ> tumbleweed: why revu and not in debian instead?
[13:57] <BlackZ> it'd have a lot of benefits
[13:57] <tumbleweed> BlackZ: oh, definitly, assuming xteejx is keen
[13:57] <xteejx> I'm keen :)
[13:57] <tumbleweed> xteejx: mentors.debian.net
[13:58] <BlackZ> xteejx: read http://wiki.debian.org/Utnubu
[13:58] <BlackZ> it could help you too
[13:59] <xteejx> utnubu lol
[13:59] <tumbleweed> or probably more relevant https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
[14:00] <BlackZ> tumbleweed: what I have linked is the more simple, considering xteejx is still learning
[14:00] <BlackZ> s/what/the one
[14:01] <tumbleweed> BlackZ: that page is all about ubuntu for debian people. I don't seet hta much relevance
[14:04] <xteejx> So upload the package to debian mentors and have it reviewed then? Or revu?
[14:04] <BlackZ> xteejx: I'd suggest mentors.debian.net first
[14:04] <tumbleweed> xteejx: if you can, get it through debian first. No need to duplicate effort
[14:04] <BlackZ> but if you prefer REVU, go ahead
[14:05] <BlackZ> the fact is that if you will get your work into debian it will be synced with ubuntu and the other debian-derivates
[14:05] <xteejx> I suppose if it was Ubuntu only, if someone in deb packaged it mine would get removed
[14:05] <BlackZ> so that would give more benefits
[14:05] <xteejx> never used revu by the way so either is fine with me :)
[14:07] <xteejx> http://wiki.debian.org/HowToPackageForDebian seems more readable on most things
[14:09] <tumbleweed> https://wiki.ubuntu.com/PackagingGuide is also useful. But be aware - lots of guides on these topics are out of date
[14:09] <xteejx> that's cool I've already went through that one anyway :)
[14:53] <RunePhilosof> ajmitch, Is there something more I can do to speed up the sru process for bug 528957 (button clicks not detected)?
[16:06] <ari-tczew> cody-somerville: do you will merge xchat?
[16:09] <cody-somerville> I can
[16:13] <ari-tczew> cody-somerville: nice
[16:13] <cody-somerville> ari-tczew, If you're interested in doing it, please feel free to go ahead though
[16:14] <ari-tczew> cody-somerville: hmm, so, I'll try do it, if I won't got time or my work will fails, then I'll ask you for merge okay?
[16:15] <cody-somerville> ari-tczew, okay
[16:20] <ari-tczew> can I clean /var/cache/pbuilder/result by any command?
[16:21] <sebner> ari-tczew: wouldn't it make more sense to wait for 2.8.8 to appear in Debian?
[16:22] <arand> ari-tczew: I think rm ./* is the way things go..
[16:23] <ari-tczew> sebner: I want to have a clean merge, now we have ubuntu5 revision. and we dunno when Debian will release 2.8.8 version
[16:23] <ari-tczew> I've reported to bug tracking a new upstream release a few days ago
[16:23] <sebner> ari-tczew: bug them :P
[16:23] <sebner> ari-tczew: *directly*
[16:23] <ari-tczew> ^^
[16:23] <ari-tczew> sebner: what "directly" ?
[16:24] <sebner> ari-tczew: catch them in irc
[16:24] <ari-tczew> arand: I asked for command
[16:24] <ari-tczew> sebner: are you lazy? :>
[16:24] <sebner> ari-tczew: hm?
[16:25] <ari-tczew> sebner: wiki
[16:25] <sebner> ari-tczew: have you sent me a mail? :P
[16:25] <ari-tczew> I've forgotten email you yesterday
[16:25] <sebner> ;)
[16:25] <arand> ari-tczew: I was simply saying "there doesn't seem to be one"..
[16:25] <dupondje> doing some merges again :)
[16:25] <dupondje> hrhr :p
[16:25] <sebner> ari-tczew: I'll write something today, promised
[16:26] <ari-tczew> arand: ok
[16:26] <ari-tczew> dupondje: what do you think about fix some security issues?
[16:26] <dupondje> like ?
[16:27] <ari-tczew> example
[16:27] <ari-tczew> are you interested?
[16:27] <dupondje> maby yea :) if its not that hard
[16:28] <ari-tczew> dupondje: you should get to know fixing security issues if you're interested in MOTU
[16:28] <dupondje> fine, you have an example where I can start ?
[16:29] <ari-tczew> https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
[16:30]  * micahg didn't think security fixes were part of MOTU
[16:30] <jdstrand> they sure can be
[16:30] <highvoltage> micahg: who else would do them for universe :)
[16:31] <ari-tczew> open bugs are available on https://bugs.launchpad.net/~motu-swat
[16:31] <jdstrand> I would encourage anyone wanting to contribute to universe to look at open security issues
[16:31]  * ari-tczew +1 for jdstrand
[16:31]  * micahg was referring to not required for becoming MOTU, not as in good to do
[16:32] <dupondje> thats a nice list ... :)
[16:32] <ari-tczew> of course all CVEs are available on Ubuntu CVE Tracker http://people.canonical.com/~ubuntu-security/cve/ but I think that we should fix security issues by importance and reports
[16:34] <ari-tczew> I disagree with micahg. I think that fixing security issues should be a part of MOTU work
[16:34] <micahg> ari-tczew: I'm not disagreeing with that
[16:34] <jdstrand> ari-tczew: well, I don't think micahg expressed an opinion, just current state
[16:35] <micahg> ari-tczew: I'm just saying that I didn't think it was *required* for becoming a MOTU
[16:35] <jdstrand> I too think it should be part of MOTU
[16:35] <ari-tczew> micahg: so current state, ok
[16:37] <ari-tczew> I think that this was a language barrer
[16:37] <micahg> ari-tczew: +1
[16:37] <ari-tczew> :)
[16:42] <dupondje> so ari-tczew, pick one of https://bugs.launchpad.net/~motu-swat list ?
[16:42] <ari-tczew> dupondje: I'll be glad
[16:43] <dupondje> damn, some seem to be extremely old
[16:43] <dupondje> and some have already patches :)
[16:44] <ari-tczew> dupondje: yea, but you should check these patches in upstream
[16:44] <ari-tczew> there are a channel for security  #ubuntu-hardened
[16:45] <ari-tczew> and I'm open for questions
[17:12] <xteejx> Question: If a source tarball has a directory Name-x.y-src can we change it to name-x.y when packaging it (even though this is changing the source)?
[17:13] <slytherin> xteejx: yes you can
[17:13] <xteejx> slytherin: Cool thanks :)
[17:14] <slytherin> xteejx: your .orig.tar.gz should have the directory in name-x.y format
[17:14] <xteejx> slytherin: The source tarball doesn't really matter then? Or keep that the same to it can be diff'd properly?
[17:15] <slytherin> It is acceptable to repack source tarball for cases like this.
[17:16] <xteejx> Oh Ok that saves messing around then hehe thanks slytherin :)
[17:19] <tumbleweed> dpkg-source doesn't care about the root directory in the .orig.tar.gz
[17:19] <tumbleweed> it can be called anything, as long as there is only one root-level item
[17:27] <Adri2000> dholbach: no I'm not
[17:27] <dupondje> ari-tczew: http://dupondje.be/asterisk.debdiff
[17:27] <dholbach> Adri2000: ok :/
[17:28] <ari-tczew> dupondje: could you give me a bug number?
[17:28] <dupondje> https://bugs.launchpad.net/ubuntu/dapper/+source/asterisk/+bug/173610
[17:29] <dupondje> ah well :)
[17:43] <dupondje> and ari-tczew  :)
[17:43] <ari-tczew> dupondje: wait 5 minutes okay?
[17:44] <dupondje> fine :)
[17:44] <dupondje> take your time
[17:44] <ari-tczew> dupondje: do you plan using bazaar instead debdiffs?
[17:46] <dupondje> ari-tczew: never used bazaar ...
[17:46] <dupondje> but can't be that hard ? :)
[17:48] <ari-tczew> dupondje: I thought that this is hard, but not! you're downloading source by command: bzr branch
[17:48] <ari-tczew> upload by: bzr push
[17:49]  * tumbleweed still finds mom quicker than the UDD equivalent
[17:49] <ari-tczew> dupondje: I'll review your patch, if it will be good, then I'll teach you to use bzr
[17:53] <ari-tczew> can I got .deb files generated by pbuilder?
[17:54] <tumbleweed> ari-tczew: /var/cache/pbuilder/result
[17:54] <ari-tczew> tumbleweed: doesn't exist :/
[17:54] <ari-tczew> .deb file of course doesn't exist
[17:54] <tumbleweed> ari-tczew: are you using the standard .pbuilderrc where you specify DIST?
[17:55] <tumbleweed> then it would be /var/cache/pbuilder/maverick-amd64/result
[17:56] <ari-tczew> tumbleweed: I use command $ sudo pbuilder-dist maverick build
[17:57] <tumbleweed> hmm never used that
[17:57] <tumbleweed>        By  default, pbuilder-dist will store all the files it generates in ~/pbuilder/. This can be changed by setting
[17:58] <tumbleweed> ... from pbuilder-dist(1)
[17:59] <ari-tczew> tumbleweed: it's exist, thanks! you have a beer from me
[18:00] <tumbleweed> lol
[18:00] <dupondje> mmm beer :)
[18:00] <ari-tczew> ~/pbuilder/maverick_result
[18:02] <ari-tczew> dupondje: you will get a more beer from me if you help me to clear bug list on ~motu-swat :)
[18:05] <dupondje> to bad
[18:05] <dupondje> i'll have to cook :P
[18:06] <ari-tczew> dupondje: some comments from me about your patch, have you got a time right now?
[18:06] <dupondje> sure
[18:09] <ari-tczew> dupondje: well, the line SECURITY UPDATE should be shorten. before http references you should put a "-"
[18:10] <ari-tczew> like in merges: first "*", below "-"
[18:11] <ari-tczew> CVE's number too have to start with -
[18:11] <ari-tczew> dupondje: look at bug 322196
[18:12] <ari-tczew> click on bzr diff, this is my patch. please look
[18:12] <dupondje> hmz ari-tczew all the previous changelog entries of asterisk doesn't have - in front ...
[18:12] <dupondje> thats why I did it like that
[18:13] <ari-tczew> dupondje: I see, but please put as I propose to you
[18:13] <ari-tczew> latest upload in asterisk dapper was in 2007, long time ago
[18:13] <dupondje> I see, i'l fix
[18:14] <ari-tczew> also, I don't see patch description
[18:14] <ari-tczew> please follow with https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines
[18:15] <ari-tczew> also you can look on my patch (bug number is above ^^ ) as example for security update. as you saw, ACK without problems
[18:19] <dupondje> http://ubuntu.dupondje.be/asterisk2.debdiff
[18:23] <ari-tczew> dupondje: better, better! progress. but please in debian/changelog, please do [enter] after "Detail" word, then white spaces until word "Record" will be under "SECURITY". then will be looks clearly
[18:25] <ari-tczew> dupondje: and rename file patch.CVE-2007-6170.dpatch to CVE-2007-6170.dpatch I don't see a reason for have this filename
[18:27] <ari-tczew> dupondje: your CVE's patch still needs to got a description https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines -> http://dep.debian.net/deps/dep3/ you can look on my patches
[18:31] <dupondje> http://ubuntu.dupondje.be/asterisk3.debdiff
[18:32] <ari-tczew> dupondje: I'm going on dinner, you're free and go cooking :)
[18:34] <dupondje> ok chief ;)
[18:34] <ari-tczew> I'll leave a message
[19:07] <ari-tczew> dupondje: I have to go out right now. I'll review your 3rd patch later.
[19:25] <RoAkSoAx> micahg: did you file the bug for testdrive?
[19:25] <micahg> RoAkSoAx: no, I was going to SRU in your bug
[19:26] <micahg> RoAkSoAx: are there specific commits that I can pull to make an SRU?
[19:26] <dupondje> asac: you there ?
[19:31] <RoAkSoAx> micahg: just the support for vbox3.2 right?
[19:31] <micahg> RoAkSoAx: yep
[19:31] <RoAkSoAx> micahg: http://bazaar.launchpad.net/~testdrive/testdrive/trunk/revision/245 though the packaging change has not yet been pushed to the trunk
[19:32] <micahg> RoAkSoAx: perfect, thank you, if you want, I can prepare the SRU
[19:32] <dupondje> somebody can help me with a MIR ?
[19:32] <micahg> RoAkSoAx: oh, right, we need to push the packaging change to maverick first
[19:33] <micahg> RoAkSoAx: so, should I just make a debdiff?
[19:35] <micahg> RoAkSoAx: unless you want to just push it, it's just | virtualbox-3.2 in control
[19:46] <ScottK> dupondje: What kind of help?
[19:50] <dupondje> ScottK: https://bugs.launchpad.net/ubuntu/+source/libutempter/+bug/589103
[19:50] <dupondje> Include the rationale and description of the violations of UbuntuMainInclusionRequirements, and a confirmation that you checked the requirements carefully.
[19:50] <dupondje> tought I did it ...
[19:52] <ScottK> dupondje: List all the items 1 - 9 in https://wiki.ubuntu.com/UbuntuMainInclusionRequirements in the bug.
[20:06] <dupondje> ScottK: https://bugs.launchpad.net/ubuntu/+source/libutempter/+bug/589103 better ? :)
[20:08] <ScottK> dupondje: Much.
[20:08] <dupondje> asac: https://bugs.launchpad.net/ubuntu/+source/libutempter/+bug/589103 :)
[20:08] <dupondje> feel free
[20:10] <ScottK> asac: Don't forget about gpsd ....  I never heard back from lool on it.
[20:17] <BlackZ> please, sponsor bug #590481
[20:19] <dupondje> BlackZ: thats something for -devel
[20:19] <dupondje> main package ..
[20:19] <BlackZ> I think here are some core developers ;)
[20:20] <hyperair> it's off-topic here ;-)
[20:21] <BlackZ> OK hyperair sorry, asking in the -devel channel
[20:21] <dupondje> anyway if you added ubuntu-sponsors it should be ok :)
[20:22]  * hyperair agrees
[20:23] <hyperair> i wish there was a way to filter out just the packages that i can upload =\
[20:23] <hyperair> i used to regularly check the uus queue, but now that it's been merged with ums, it's kind of hard to figure out which packages you can and cannot sponsor
[20:23] <micahg> hyperair: well, CTRL + F on the sponsors page :)
[20:23] <geser> hyperair: go for core-dev :)
[20:24] <hyperair> =(
[20:24] <hyperair> micahg: what do you expect me to do, ctrl+f each of the... god knows how many packages there are in universe?
[20:25] <ScottK> Sounds like a great task for a new script in ubuntu-dev-tools
[20:25] <micahg> hyperair: sorry, I was about to look at the page, there was a new version that made it easier to tell what one could upload
[20:25] <hyperair> lol ScottK.
[20:25] <ScottK> Not kidding.
[20:26] <micahg> hyperair: would unseeded count?
[20:26] <hyperair> ScottK: i'm more inclined towards launchpad.net button^Wfilter
[20:26] <hyperair> micahg: i think so.
[20:26] <micahg> hyperair: http://qa.ubuntu.com/reports/sponsoring/
[20:26] <ScottK> hyperair: Yes, but guess which is easier to get done sooner ...
[20:26] <hyperair> hmm has that been updated?
[20:26] <dupondje> I can't sponsor :p
[20:27] <dupondje> hyperair: yes
[20:27] <hyperair> i remember that list being hopelessly outdated, *and* still sticking seeded packages in.
[20:27] <dupondje> Last updated at: Mon, 07 Jun 2010 20:26:25 +0100
[20:27] <hyperair> ScottK: like syncpackage, eh?
[20:28] <ScottK> Sure.
[20:33] <dupondje> hyperair: if you feel bored: https://launchpad.net/bugs/590820, https://launchpad.net/bugs/590831
[20:34] <hyperair> eh no, i'm not bored =p
[20:34] <dupondje> https://launchpad.net/bugs/589908
[20:34] <dupondje> there is enough of review stuff :D
[20:34] <hyperair> i'll start looking at them once my btrfs woes are over.
[20:35] <hyperair> or otherwise temporarily stalled.
[20:35] <dupondje> exotic filesystems :)
[20:37] <ScottK> dupondje: I just put a comment in 589908 that I think we should hold off on uploading it for now.  Let's see if we get the fix for free from Debain via sync first.
[20:39] <dupondje> ok
[20:39] <dupondje> there is an upstream bug, so it should be possible :)
[20:40] <ScottK> I'm pretty sure the guy that filed it will NMU the package if the maintainer doesn't respond.
[20:41] <dupondje> I keep an eye on it
[20:41] <hyperair> dupondje: yes, very exotic ;-)
[20:42] <dupondje> SynCE is outdated since karmic or so, its nice to have 0.15 now
[20:42] <dupondje> :)
[20:43] <dupondje> hyperair: xfs feels exotic also sometimes
[20:43] <dupondje> xfs_check doesn't even work if you don't have tons of memory :P
[21:37] <cpscotti> Hey any archive admin with some time to check a SRU with fix-commited and verification-done (10 days old) (bug 480772 ) Is there something else to do? Or waiting is enough?
[22:41] <ari-tczew> dupondje: ping
[22:49] <lool> ScottK: Saw the gpsd ping, but didn't get a chance to have a look, dont have much time for MIRs right now
[22:49] <lool> ScottK: If you'd find another MIR reviewer in the mean time, that might work better
[23:04] <ScottK> asac: ^^^
[23:04] <ScottK> lool: Thanks.
[23:09] <ari-tczew> lool: do you maintain libsmbios in Debian?