[00:07] <YokoZar> ScottK: so the revolution R people are JUST NOW sending me their packages...
[01:52] <MTeck-ricer> So.. how do you make a package for the kernel?
[01:53] <MTeck-ricer> Or is it pretty much just like any other package?
[01:53] <crimsun> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[01:53] <crimsun> pretty much, just read the knowledgebase
[01:54] <crimsun> meaning: "essentially you need to read the KB"
[01:54] <crimsun> not: "it's essentially the same as any other package"
[01:54] <MTeck-ricer> crimsun: I don't get what you mean, is there a wiki or anything?
[01:54] <MTeck-ricer> :P
[01:55] <MTeck-ricer> crimsun: thanks
[02:00] <CTho> what is the distinction between PPA and backports?
[02:00] <CTho> or, why would a package only be in a PPA?
[02:02] <crimsun> sometimes it doesn't make sense to continuously push to $release-backports
[02:02] <crimsun> e.g., daily builds of $package
[02:03] <CTho> so does the frequency of firefox patches push it above that threshold?
[02:03] <crimsun> I don't understand your intended question
[02:03] <CTho> why is firefox 3.6 not in backports?
[02:03] <crimsun> for which release?
[02:03] <CTho> security patches are too often?
[02:04] <CTho> karmic
[02:04] <MTeck-ricer> crimsun: wow
[02:04] <crimsun> are you not using the ubuntu mozillateam security ppa?
[02:04] <MTeck-ricer> crimsun: there's a LOT to that...
[02:04] <crimsun> ^^ CTho
[02:05] <crimsun> CTho: also, backports is not intended for security.
[02:05] <CTho> crimsun: should that be set by default?
[02:05] <crimsun> CTho: you're asking questions that I can't answer for an entire distribution.
[02:06] <CTho> i'm apparently not using the mozillateam ppa
[02:13] <ScottK> You shouldn't need to.
[02:13] <ScottK> Security fixes get pushed via the regular updates process.
[02:14] <ScottK> Ubuntu backports are part of the Ubuntu distribution and you can be assured that anything in an Ubuntu backport has been checked by an Ubuntu developer.
[02:14] <ScottK> Anyone can have a backport and put anything in it they want, so you need to evaluate them indifvidually and determine if you trust them.
[02:14] <ScottK> PPAs are not part of Ubuntu.
[02:16] <wgrant> ScottK: Did you mean 'Anyone can have a *PPA*'?
[02:16] <ScottK> wgrant: I did.  Thanks
[02:16] <ScottK> Long day.
[02:16] <wgrant> Heh.
[02:26] <funkyHat> Is it still worth working through FTBFS packages at this stage?
[02:54] <wgrant> funkyHat: Yes.
[02:54] <wgrant> The fewer FTBFSes we have, the easier LTS is going to be.
[02:54] <wgrant> If we need to do an SRU or security update on a package that we can't build, we are in trouble.
[03:38] <funkyHat> Just finished bug #565152 -- doesn't look like it will be relevant to debian unfortunately as they have a separate ftbfs relating to gcc 4.5
[03:44] <imbrandon> ouch not good i need memcached /me looks
[03:46] <imbrandon> funkyHat: i havent looked at the debdiff yet, but i noticed you say in the bug that you changed a bit of code, you did this via a patch file hopefully, correct ?
[03:47] <imbrandon> funkyHat: i actualy would like to see that fixed too so if it all works after a bit of testing i'll sponsor it for ya
[03:47] <funkyHat> imbrandon: yes, there were already some patches in the package so I added a new one. It's using quilt
[03:47] <imbrandon> funkyHat: great, give me about ~30 min to look it over etc and i'll sponsor if its ready
[03:47] <funkyHat> imbrandon: great ⢁)
[04:13] <ScottK> IIRC there was a memcached upload earlier today.
[04:14] <ScottK> Ah, which didn't build either
[04:14]  * ScottK lart's zul.
[04:17] <imbrandon> lol
[04:18] <imbrandon> this one looks fine, still doing a cursory test build though
[04:19] <imbrandon> funkyHat: looks good build / test install finished fine, patch looks sane, i'm just gonna update your changelog entry to be a bit more desciptive and upload , ok ?
[04:21]  * imbrandon is really suprised memcached isnt in main 
[04:22] <wgrant> It's odd, yes.
[04:22] <wgrant> Particularly since LP uses it now.,
[04:22] <ScottK> Then that's probably a bug.
[04:23] <ScottK> But if Canonical IS doesn't care, why should I?
[04:23] <wgrant> Heh.
[04:23] <imbrandon> lol
[04:26] <imbrandon> funkyHat: uploaded
[04:27] <imbrandon> wgrant: just out of curiosity ( if you know ) what does LP use to run its python stack ? apache ?
[04:28] <imbrandon> err apache2 + mod_*
[04:30] <ScottK> Not in the queue yet.
[04:31] <imbrandon> ScottK: [ubuntu/lucid] memcached 1.4.2-1ubuntu3 (Waiting for approval)
[04:32] <wgrant> imbrandon: haproxy in front of Apache in front of a Zope server running on Twisted.
[04:32] <ScottK> There it is.  Let me have a look....
[04:32] <imbrandon> wgrant: ahh sounds like a fun job for the IS guys/gals
[04:34] <ScottK> Nice.
[04:34] <ScottK> imbrandon and funkyHat: Accepted.
[04:34] <imbrandon> ScottK: thanks
[04:34] <imbrandon> funkyHat: and thanks for looking at the bug
[04:34]  * ScottK hearts queuediff
[04:35] <imbrandon> i have fell in love with offlineimap, i have no idea why i never used the GREAT tool untill this week
[04:36] <persia> You were participating in the movement to avoid email at all costs?
[04:36] <ScottK> imbrandon: Would you mind taking a look at libgda4 and making a recommendation.  It's FTBFS in lucas_' rebuild and we're several upstream versions behind.  What's the shortest/safest path to something that builds.
[04:37] <imbrandon> persia: lol
[04:37] <imbrandon> ScottK: sure
[04:37] <ScottK> Thanks.
[04:39] <imbrandon> ScottK: upstream or upstream;upstream ? ( did that make sense ? e.g. Debian or further up )
[04:39] <ScottK> imbrandon: Debian.
[04:39] <imbrandon> k
[04:40] <imbrandon> my gut says a sync but lemme look at our deltas and such though
[04:40] <imbrandon> ( havent even looked yet )
[04:41] <wgrant> ScottK: That reminds me. I should see how hard it is to hook the diffs up into the UI.
[04:41]  * wgrant suspects three lines of template should do it.
[04:41] <ScottK> Nice.
[04:57] <imbrandon> dget http://ftp.de.debian.org/debian/pool/main/libg/libgda4/libgda4_4.0.8-1.dsc
[04:57] <imbrandon> err
[05:00] <imbrandon> ScottK: it looks like it can be just a solid sync, they have adopted all our deltas ( even the ones they dident need specifcly for debian , how nice of them ) BUT it might ftbfs on x86_64
[05:00] <imbrandon> thats what i'm checking now
[05:00] <imbrandon> per lp bug 537379
[05:00] <ScottK> OK.
[05:00] <ScottK> Also look at the rdepends and see if it might affect any of them negatively.
[05:01] <imbrandon> yup
[05:03] <imbrandon> suprisingly it has very few rdepends, but ya checkign them
[05:07] <ScottK> imbrandon: BTW, this one is in Main, so it's useful for your core-dev reactivation
[05:12] <imbrandon> ScottK: i noticed ;)
[05:56] <imbrandon> ScottK: looks like it builds fine on x86_64 too
[05:56] <imbrandon> dunno why it is not in debian
[05:56] <ScottK> Cool
[05:56] <imbrandon> anyhow looks like a solid sync, all deltas are accounted for, i'll say so on the bug
[05:56] <imbrandon> if you wanna do the honors
[05:56] <imbrandon> rdepends are also fine
[05:56] <imbrandon> there are only 3 real ones and none will be affected
[05:58] <imbrandon> done
[05:59] <ScottK> imbrandon: File the sync request then and give me the bug number so I can ack it.
[05:59] <ScottK> Explain how much you tested it
[05:59] <imbrandon> ok
[06:08] <imbrandon> ScottK: bug 537379
[06:11] <ScottK> imbrandon: Ack'ed.  Thanks.
[06:11] <ScottK> imbrandon: Want another one?
[06:13] <imbrandon> sure
[06:18] <ScottK> imbrandon: How about flite3 ee http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[06:19] <ScottK> imbrandon: err flite 1.3-release-2
[06:19] <imbrandon> k
[06:20] <imbrandon> strange ver nums ;)
[06:21] <imbrandon> sf.net hosts thinkgeek ? wow never knew
[07:14] <imbrandon> ScottK: please check bug 565207
[07:27] <imbrandon> ScottK: btw per the jorge and planet ...
[07:27]  * imbrandon hugs ScottK 
[07:49] <imbrandon> ScottK: bug updated ( FFe info added )
[08:17] <imbrandon> ScottK: ping
[11:46] <dutchie> hi, I'm looking at pushing a fix to bug 64917 into my ppa. I've added a libwebkit-dev Build-Depends: into the debian/control.in file, but I can't work out how to regenerate the debian/control file from it
[11:54] <chrisccoulson> dutchie - the debian/control file should be regenerated automatically when you build the source package (debuild -S)
[11:54] <chrisccoulson> AFAIR it's regenerated as part of the clean target
[11:55] <dutchie> ok
[11:58] <chrisccoulson> dutchie - /usr/share/gnome-pkg-tools/1/rules/uploaders.mk has the hook for regenerating it, in case you are curious
[11:58] <dutchie> cool, thanks
[16:01] <lfaraone> Would any MOTU have a chance to approve the merge of a SRU to {Karmic, Jaunty, Intrepid} in bug 301190? (already been approved by ~ubuntu-sru)
[16:48] <kobrien> can someone review a patch for me in lucid libruby?
[16:49] <kobrien> bug 561432
[18:33] <kobrien> lfaraone: thanks
[18:35] <lfaraone> kobrien: no problem. looks fine, but I'm not a MOTU :)
[18:37] <kobrien> lfaraone: ah, I see. so what happens next?
[18:38] <lfaraone> kobrien: we wait for a sponsor (who *is* a MOTU) to go through the sponsorship list and commit your fix.
[18:38] <hyperair> lfaraone: you aren't? i thought you were.
[18:38] <kobrien> hyperair: are you?
[18:38]  * hyperair is.
[18:39] <hyperair> a motu with no time.
[18:39] <kobrien> I see, I know my patch works. Wouldn't take long :).
[18:39] <hyperair> wait until after my exams and i'll look through anything you like.
[18:39] <lfaraone> hyperair: heh, thanks, feel free to mention that on https://wiki.ubuntu.com/LukeFaraone/MOTUApp when you *do* have time :)
[18:39] <kobrien> lol, I know the feeling
[18:39] <hyperair> lfaraone: sure ;-)
[18:39] <hyperair> kobrien: glad you understand =)
[18:40] <kobrien> hyperair: I've got 2.5 weeks to finish off my project and thesis. :)
[18:40] <lfaraone> hyperair: actually, I just remembered ruby is in main, so we'll need to snag a core dev.
[18:41] <kobrien> well, I'm sure a motu will get to it. As soon as the thesis is done, I'm full steam for becoming a motu. :)
[18:41] <hyperair> kobrien: i've got 6 days to cover 2 months worth of study backlog ;-)
[18:41] <kobrien> RoAkSoAx: ping
[18:41] <RoAkSoAx> kobrien, pong
[18:41] <kobrien> hyperair: good luck
[18:41] <hyperair> kobrien: thanks
[18:41]  * lfaraone seconds kobrien wrt hyperair.
[18:42] <hyperair> lfaraone: thanks
[18:42] <RoAkSoAx> kobrien, how may I help you
[18:42] <kobrien> RoAkSoAx: are you a motu?
[18:42] <hyperair> i guess that's how grim my situation is eh >_>
[18:42] <RoAkSoAx> kobrien, yep
[18:42] <kobrien> good you review a patch for me?
[18:42] <kobrien> could*
[18:42] <RoAkSoAx> kobrien, bug?
[18:42] <lfaraone> kobrien: you don't just need a motu, you need a core dev.
[18:42] <RoAkSoAx> bug #?
[18:42] <lfaraone> RoAkSoAx: bug 561432
[18:42] <kobrien> oh ok, I misunderstood
[18:43] <lfaraone> kobrien: I misspoke earlier, no worries.
[18:44] <RoAkSoAx> kobrien, ruby is in main so you'll need a core dev
[18:45] <kobrien> RoAkSoAx: thanks. Seeing as how someone has subscribed "ubuntu sponsors" and "ruby motu" to the bug, do I need to do anything more?
[18:46] <geser> be patient :)
[18:46] <kobrien> cool cool. :)
[18:47] <lfaraone> geser: hm. that won't make it into lucid, will it...
[18:47] <RoAkSoAx> kobrien, nope, just wait for someone to review it and upload it
[18:47] <kobrien> RoAkSoAx: cheers
[18:47] <lfaraone> RoAkSoAx: but while we have your attention, could you review the merge proposals for SRUing bug 301190 ?
[18:47] <geser> lfaraone: hard to tell
[18:48] <lfaraone> RoAkSoAx: (it's the same change in each SRU, and I tested/built each in their own VM)
[18:50] <RoAkSoAx> lfaraone, ok will take a look at it
[18:50] <lfaraone> RoAkSoAx: thanks :)
[18:53] <kobrien> eh, someone has changed my bug to wishlist but I really don't agree.
[18:53] <kobrien> feedback?
[18:54] <kobrien> ah, it's RoAkSoAx :)
[18:55] <RoAkSoAx> kobrien, whenever you subscribe to ubuntu-sponsors you changed the bug to confirmed, and if possible, to wishlist
[18:55] <kobrien> i see, so is it still considered a bug, cause it is incorrect behaviour of the code?
[18:56] <RoAkSoAx> lfaraone, I'd get approvel from ubuntu-sru first, and then I'll sponsor your upload. And could you please provide buildlogs (of PPAs if possible) to test it?
[18:56] <lfaraone> RoAkSoAx: uh, I thought persia approved it when he accepted the SRU request. Did I miss something?
[18:57] <RoAkSoAx> lfaraone, i dont see any sru ack
[18:58] <persia> I didn't approve anything but the nomination.
[18:58] <RoAkSoAx> lfaraone, ^^
[19:00] <RoAkSoAx> kobrien, yes whenever you subscribe to ubuntu-sponsors mark the bug as confirmed
[19:00] <kobrien> RoAkSoAx: personally I can't
[19:01] <RoAkSoAx> kobrien, btw... I just saw that ruby1.8 is using a patch system. You should make your change in a patch
[19:02] <kobrien> RoAkSoAx: debdiff won't work? there's a link in the bugreport to a ruby site with a patch.
[19:03] <RoAkSoAx> kobrien, yes you have to attache the debdiff, however, you are modifying the source directly. You need to create a patch and make the change in the patch
[19:06] <kobrien> RoAkSoAx: ah, I've found docs, ok. thanks
[19:07] <RoAkSoAx> kobrien, i have unsubscribe your bug from ubuntu-sponsors for now, subscribe again when you made the proper changes..
[19:08] <kobrien> RoAkSoAx: ok, understood
[19:53] <lfaraone> persia: my apologies. would you have time to review the attached branches?
[19:56] <persia> lfaraone: I can't approve an SRU: you really want someone in the SRU team.
[20:01] <lfaraone> jdong: poke.
[20:03] <jdong> lfaraone: yeah, what bug number?
[20:04] <lfaraone> jdong: bug 301190
[20:05] <jdong> *looking*
[20:05] <jdong> apologies, I'm a bit behind in my SRU bug tracking.
[20:06] <lfaraone> jdong: no problem, I only posted it two days ago :)
[20:07] <jdong> lfaraone: ok, you've got a SRU ack :)
[20:07] <jdong> I do like the shiny new workflow with bzr :)
[20:12] <lfaraone> jdong: you and me both. I detested debdiffs, and the pretty colors make it easy to review.
[20:12] <lfaraone> RoAkSoAx: see above :)
[20:12] <hyperair> debdiffs rock.
[20:12] <jdong> lol and I started a war ;-)
[20:12] <hyperair> ;-)
[20:12] <lfaraone> hyperair: but when you need to make a fix you need to build a new source package, generate the debdiff, upload it as an attachment... :P
[20:13] <lfaraone> (vs. "commit, push, wait")
[20:13] <hyperair> lfaraone: actually no you don't.
[20:13] <hyperair> lfaraone: the thing about debdiffs are that... they are diffs.
[20:13] <hyperair> lfaraone: any -p1 diff would do.
[20:13] <lfaraone> hyperair: good point :)
[20:13] <hyperair> my workflow is: git diff <old-tag>, and fire off an email
[20:14] <lfaraone> well, we'll have both methods working for the immediate future; I don't think anybody's suggesting we dump them, I just think new people may find it easier. But I should shut up, since I havne't done testing.
[20:15] <hyperair> lfaraone: there are many who share that opinion
[20:15] <hyperair> lfaraone: but i just dislike bzr.
[20:21]  * ScottK tried the new way and found it slower and more complex so far.
[20:27] <directhex> ScottK, i tried it, then hyperair informed me (correctly) that the bzr branch on launchpad wasn't the same as the package in the archive. which annoyed me
[20:28] <ScottK> I can imagine.
[20:28] <directhex> given i'd spent my time preparing a bunch of changes which were already in the archive but not in bzr
[20:29] <lfaraone> directhex: interesting. usually it is only 12h behind or so.
[20:30] <Laney> 12h is way more than 0h
[20:30] <lfaraone> Laney: ideally, we'd use push mirroring :)
[20:30] <directhex> it's a good thing we don't have a release coming, or an un-warned 12h delay between developer doing one thing and being able to make changes to it would be vexatious
[20:30] <hyperair> i imagine it must take 12 hours to import all the changes made in the archive into the bzr trees >_>
[20:31] <Laney> I just accidently put Britain's Got Talent on
[20:31]  * Laney scrubs eyes with acid
[20:31] <hyperair> lol
[20:31]  * ScottK notes a distressing lack of stuff to review in the queue.  Please fix stuff.
[20:31]  * Rhonda sighs.
[20:31] <hyperair> ScottK: if you have main upload privileges go upload indicator-application please =p
[20:32] <directhex> Laney, i thought that wasn't until thursday evening
[20:32] <Laney> dunno, check ITV1 if you dare
[20:32] <ScottK> I do, but I'm not going to touch that one.  Also, stuff I upload, I can't accept.
[20:32] <Rhonda> ScottK: Good that I asked you to sync wesnoth 1:1.8-1 right ahead, seems my support for parallel build in 1:1.8-2 is giving troubles, at least on Debian buildds. %-/
[20:32] <directhex> IT'S A FUNNY POLITICS JOKE
[20:32] <hyperair> heheh
[20:32] <Laney> oh
[20:32] <Laney> :(
[20:32] <ScottK> Rhonda: I was about to ask.
[20:33] <hyperair> ScottK: oh yeah, i filed a sync request about nautilus-share.
[20:33] <ScottK> Rhonda: Is there anything in -2 we should cherrypick for a -1ubunu1 upload?
[20:34] <Rhonda> ScottK: The two patches that I pulled from upstream would make a lot of sense, yes.
[20:34] <hyperair> bug #565418
[20:34] <ScottK> hyperair: It's best to wait for an archive admin with shell access to deal with the syncs.
[20:35] <hyperair> ScottK: okay.
[20:35] <ScottK> Rhonda: If we could get a bug with a debdiff, then we could get that going.
[20:35] <hyperair> ScottK: i think it still needs an ack from someone with main-upload-privileges though.
[20:35] <ScottK> hyperair: I don't really know enough about Gnome stuff to have an opinion.
[20:36] <hyperair> ScottK: alright then
[20:38] <Laney> how does the rcbugs page look?
[20:38] <lfaraone> it's always interesting to see "ubuntu1) karmic" in debian changelogs :) http://packages.debian.org/changelogs/pool/main/n/ncpfs/ncpfs_2.2.6-7/changelog.html
[20:39] <Laney> looks like those changes should have been forwarded
[20:39] <lfaraone> Laney: they were merged back, yes.
[20:39] <ScottK> Laney: Lots of bugs on it.
[20:39]  * lfaraone is currently looking at syncing ncpfs.
[20:39] <Laney> pulled though, not pushed
[20:45] <sistpoty> ScottK: can you take a look at bug #542634 please? I'm a little bit lost there :/
[20:45] <ScottK> Sure.
[20:45] <sistpoty> thanks
[20:48]  * ScottK is confused too.
[20:50]  * imbrandon is always confused
[20:50] <ScottK> sistpoty: Let's see if we can get an opinion from doko
[20:50] <imbrandon> ScottK: did you see my note about libgda ?
[20:50] <ScottK> imbrandon: I did.  I subscribed the release team.  I think it's reasonable, but didn't want to decide all by myself
[20:50] <imbrandon> k
[20:51] <imbrandon> bdrung: ping ( re: apt-mirror )
[20:51] <ajmitch> sistpoty: sorry that I didn't comment on it, but I don't know that part well enough
[20:52] <sistpoty> k, thanks ScottK and ajmitch
[20:53] <ajmitch> zope has further turned into small piles of black magic :)
[20:53] <imbrandon> lol
[20:54] <lfaraone> ajmitch: it's always been magic :P
[20:54] <ajmitch> but they've cut it up into smaller piles
[20:54] <ajmitch> ScottK: do you know if ~ubuntu-archive is still syncing packages?
[20:55] <bdrung> imbrandon: pong
[20:55] <ScottK> ajmitch: It's a matter if someone has time.
[20:55] <ScottK> Should be so.
[20:55] <ajmitch> so I have to bribe someone, or perhaps change the importance away from wishlist
[20:56] <ScottK> Just put something suitable RC sounding in the description.
[20:56] <ajmitch> "package is burnt toast with php 5.3"
[20:57] <imbrandon> bdrung: i seen you applied ( and authored ) a few patches in apt-mirror, just wanted to let you know i have commited those to upstreams svn today
[20:57] <imbrandon> so they will be in the next release ( maybe today if i can get the other patches ready )
[20:58] <bdrung> imbrandon: great
[20:58] <ScottK> bdrung: Is Audacious all sorted out?
[20:59] <bdrung> imbrandon: one thing that does not work properly: killing apt-mirror with ctrl+c (it kills only a subprocess)
[20:59] <bdrung> ScottK: no, two bugs remain: bug #564087 and #564092
[21:00] <imbrandon> bdrung: probably, never thought about it being run interactively, my mindset is normaly run as a cron, but yea i'll have a look at that
[21:00] <ScottK> sistpoty: Since you approved the audacious FFe, I think you should help with those.
[21:00] <bdrung> imbrandon: thanks
[21:00] <lfaraone> bdrung: hm. whenever I kill it, the network IO stops, so I assume the threads die with it.
[21:00] <sistpoty> crap, that's what you got for only checking rdepends but not build-rdepends
[21:00] <lfaraone> but the lockfile does not go away :)
[21:01] <imbrandon> lfaraone: yea the lockfile bug is fixed in svn now
[21:01]  * sistpoty fixes
[21:02] <ScottK> excellent.
[21:10] <bdrung> sistpoty: and i forgot to check it completely.
[21:10] <sistpoty> well, yeah, things happen... :(
[21:10] <bdrung> lfaraone: do you use the latest version?
[21:12] <lfaraone> bdrung: no, I mean the version in karmic. Is there a behavioral change in this regard in Lucid?
[21:13] <ScottK> sistpoty: I'd appreciate your opinion on Bug 561631.
[21:13] <sistpoty> *looking*
[21:14] <bdrung> lfaraone: yes, the lock file removal is fixed in lucid
[21:17] <imbrandon> yes, and once 0.4.7 is out i'm going to do a -backport, just need to find enough fingers to get it all done ;)
[21:18] <bdrung> imbrandon: backport?
[21:18] <imbrandon> for apt-mirror to older supported releases
[21:18] <sistpoty> ScottK: libpcap is in main, and has very many rdepends, I fear I'll need to thouroughly review the entire diff
[21:19] <ScottK> sistpoty: I think it's worth considering, but I don't know enough to really decide.
[21:29] <bdrung> imbrandon: which releases?
[21:31] <imbrandon> bdrung: all that are still under support, should be fairly simple given the lax dependencys
[21:31] <crimsun> sistpoty: it's a bit big for my comfort, but I understand the discomfort with carrying the current version for 5 years, too.
[21:32] <crimsun> sistpoty: I'm happy to help; there seem to be only 3 source packages that b-d on libpcap0.8-dev
[21:33] <crimsun> 3 in main, that is
[21:35] <sistpoty> crimsun: sure, any help is welcome
[21:35] <sistpoty> crimsun: can you test the 3 packages in main?
[21:36] <crimsun> sistpoty: sure. I'll work on that in about seven hours for a stretch
[21:36] <sistpoty> excellent, thanks crimsun
[21:37] <sistpoty> crimsun: and if you find anything other noteworthy, just add a comment to the FFe in question
[22:00] <ScottK> geser: You TIL rbot.  There's a security fix in Debian I think we'd want.  Would you please have a look at a merge?
[22:03] <geser> ScottK: can do. Does the switch to v3 format need a FFe?
[22:03] <ScottK> geser: No.
[22:04] <ScottK> If that's going to cause problems it'll almost certainly fail to build and we'll know
[22:20] <geser> ScottK: merged
[22:20] <ScottK> geser: Thanks.  I'll accept it when it hits the queue.
[22:22]  * ScottK looks at http://qa.ubuntuwire.com/bugs/rcbugs/ and invites others to find fixes we could benifit from.
[22:26] <geser> ScottK: do you know if sync requests will be processed in time or should packages get synced with the syncpackage script?
[22:27] <ScottK> I don't know for sure, but I think they will.
[22:42] <sistpoty> ScottK: commented on libpcap. I think I'm ok with getting it in, but I'd like someone else take a look at it as well (crimsun maybe?) and see testing of all rdepends in main
[22:42] <ScottK> sistpoty: OK.  Please ask for that in the bug.  I think we should let slangasek make the final call on this one.
[22:43] <sistpoty> ScottK: already done. an opinion from slangasek would certainly be preferred :)
[22:43] <ScottK> lucas_: Is it possible your last rebuild was done with Main only even for Universe packages?  I see a lot of FTBFS due to non-existant packages that do in fact exist in Universe.
[22:47] <imbrandon> ScottK: the more i look at libgda4-4.0.8 ( and subsuqent fix for ftbfs ) we'll need to push that as a sru when we get the x86_64 worked out
[22:47] <imbrandon> ( thats the opinion of the DD's too from the gnome team )
[22:47] <ScottK> imbrandon: OK.  Thanks for looking into it.  BTW, I think deciding stuff shouldn't be uploaded yet should count on core-dev apps too.
[22:48] <imbrandon> heh
[22:49] <slangasek> sistpoty: do you have the bug # handy for that one?
[22:49] <sistpoty> slangasek: bug #561631
[22:50] <sistpoty> slangasek: crimsun volunteered to test rdepends in main, but will need a few hours before doing so
[22:53] <sistpoty> bdrung: do you have the HW to test g15daemon-audacious?
[22:53] <sistpoty> bdrung: as I've got a trivial fix around now
[22:54] <bdrung> sistpoty: no. you can give me 100 euro and i will buy the HW ;)
[22:54] <lfaraone> If a sync request would fix a bug (say, bug 549692), should I modify that bug, or create a new one?
[22:55] <sistpoty> bdrung: haha... then let's just cross fingers that it'll still work with the ftbfs fix (just updating one include directive)
[22:58] <sistpoty> bdrung: I haven't forwarded the change to debian yet, and am quite sure that I'll forget to do so... can you do that please (if it affects unstable as well)?
[22:58] <bdrung> sistpoty: currently it affects only experimental
[22:58] <sistpoty> bdrung: ah, ok
[22:58] <bdrung> sistpoty: didn't we have a tool for sending our changes to debian?
[22:59] <sistpoty> bdrung: could be... I prefer reportbug after checking on an unstable system though
[23:01] <Kangarooo> to get programm to universe i found i need to post to launchpad request for packaging or package myself. if that is done then i post it to revu but http://revu.ubuntuwire.com/ is down
[23:01] <Kangarooo> ups its forbiden
[23:01] <lfaraone> Kangarooo: new packages are not being accepted right now, so there's no rush :)
[23:01] <sistpoty> Kangarooo: hm? revu is down?
[23:01] <geser> bdrung: submittodebian? never used it personally
[23:01] <lfaraone> Kangarooo: I'd ask about it in #ubuntuwire
[23:01] <sistpoty> crap, revu *is* down :(
[23:01]  * sistpoty fixes it
[23:01] <bdrung> geser: yes
[23:01] <ajmitch> sistpoty: the server itself is down?
[23:02] <sistpoty> ajmitch: nope, just apache returns a 403
[23:02] <lfaraone> submittodebian works pretty well in my experience, but occasionally picks up extraneous changes (like debian/control)
[23:02] <ajmitch> sistpoty: ugh, that's bad
[23:02] <sistpoty> ajmitch: not necessarily, looks like md is not mounted
[23:02] <sistpoty> (where revu resides)
[23:03] <imbrandon> fun fun
[23:04] <ajmitch> that's still bad
[23:04] <sistpoty> ajmitch: or can you take a look, since you're already logged in?
[23:04] <Kangarooo> and what to do if i asked for packaging and someone else packages then will he also post to revu or i need to check LP page and get and post to revu that package?
[23:04] <ajmitch> yeah I can confirm it's not mounted
[23:04] <ajmitch> but /dev/md0 isn't looking happy
[23:05] <lfaraone> Kangarooo: most likely the packaging will  not be done unless you do it yourself :)
[23:05] <imbrandon> is revu still on spooky ?
[23:05] <ajmitch> sistpoty: the server was rebooted ysterday?
[23:05] <ajmitch> imbrandon: yep
[23:05] <Kangarooo> ajmitch: i hope this is small problem and server is in cloud :)
[23:06] <Kangarooo> like in cloud computer not rip
[23:06] <imbrandon> Kangarooo: revu will be fixed, its just a matter of when ( depending on the severity of the issue )
[23:06] <lfaraone> Did I update bug 549692 properly to reflect its status as a sync request? (syncing would fix the bug the reporter asked)
[23:07] <Kangarooo> lfaraone: but if i post package request then if not me then someone from motu packages it or anyone also who is not motu can do that? (if yes dont answer- i think yes but not sure)
[23:08] <lfaraone> Kangarooo: somebody *may* package it. if they are not in MOTU, they'll post it to REVU and be responcible for getting it accepted.
[23:09] <ajmitch> sistpoty: I think someone needs to take a look at the raid setup there, /dev/md0 doesn't want to go
[23:10] <Kangarooo> ok thx. ok now the bigest question this maybe a security issue: is programm put to universe checked by someone like checked All code it contains?
[23:10] <sistpoty> ajmitch: ok, I'll take a look
[23:10] <ajmitch> sistpoty: thanks :)
[23:10] <doctormo> http://doctormo.org/2010/04/17/input-debian-packaging-guide/
[23:10] <ScottK> sistpoty: g15daemon-audacious accepted.  Thanks.
[23:10] <lfaraone> Kangarooo: uh, yes, that's the purpose of the sponsorship / mentorship guide.
[23:10] <lfaraone> Kangarooo: * system, I mean
[23:10] <doctormo> I'm after some really simple deb packaging guides, I got a few links so far, but they're rather more verbose.
[23:10] <sistpoty> ScottK: thanks!
[23:11] <ScottK> doctormo: The problem is that packaging is inherently complex.  Anything simple is wrong or dangerously incomplete.
[23:11] <ScottK> Making it simple is an unsolved problem.
[23:11] <doctormo> ScottK: It doesn't have to simple in it's end condition, it just needs to build up with grace
[23:12] <doctormo> Instead of the lumbering clunky documents I read in a few of these links
[23:12] <ScottK> That's not easy either.
[23:12] <doctormo> At least I'll know where to come for critique ;-)
[23:12] <ScottK> Part of the problem is that as soon as you understand packaging, you're inherently unqualified to write documentation for people that don't.
[23:12] <ScottK> There's a very narrow window where you still remember what it was like to learn.
[23:12] <Kangarooo> so no one can put programm witch contains line witch simulates virus? like deleting files. gaining sudo and listening to keystrokes and at random time execute that.
[23:13] <ScottK> Trying to catch people in that window and force them to do documentation is hard.
[23:13] <doctormo> ScottK: Well I don't know how to make deb packages, even though I've done it several times.
[23:13] <ScottK> Kangarooo: In theory no.  In practice no system is perfect.  AFAIK it hasn't happened yet.
[23:13] <jdong> Kangarooo: in general, yes, for new packages 2 sponsors and an archive manager reviews the code comprehensively
[23:14] <slangasek> so I was just thinking yesterday that https://wiki.ubuntu.com/PackagingGuide/Complete could use some refining
[23:14] <jdong> Kangarooo: and for most uploads in general, there are developers that look at what's being uploaded
[23:14] <slangasek> but stopped short of editing it because I don't want to push things there that aren't considered community best practice
[23:14] <jdong> Kangarooo: from personal experience, when I've made some careless oversights in my uploads, I've had fellow developers email me a few hours afterwards.
[23:15] <jdong> (At the same time this does NOT mean you should blindly go trusting every package in the repository from a security standpoint...)
[23:16] <bdrung> sistpoty: now only bug #564092 remains
[23:17] <Kangarooo> ok. i wast just confused 2 days ago why i had system update for sudo. and i hoped it wont take something over with sudo. couse i have never experienced any problem with it and problem with sudo may do some big problem like not overwriting some config and telling all done.
[23:17] <sistpoty> bdrung: I'll take a stab at it
[23:17] <bdrung> thanks
[23:18] <bdrung> i will fix bug #563043 as counterpart
[23:18] <Kangarooo> ok thx all and sistpoty ur welcome :)
[23:20] <doctormo> What is the easiest way to install all build deps for a given control file?
[23:21] <Kangarooo> doctormo: yes make post why packaged things work. im similar like u - tryg to package but cant understand why they work
[23:21] <lfaraone> Kangarooo: if you have specific questions please ask.
[23:21] <dutchie> doctormo: there's a mk-build-deps thingy
[23:21] <dutchie> you can just "sudo mk-build-deps -i" and it creates and installs the build dependencies
[23:21] <lfaraone> dutchie: copy and paste :)
[23:21] <doctormo> This is very much like Alchemy, some things work, some others don't, no one knows quite why.
[23:22] <lfaraone> doctormo: well, there are usually good reasons for this, but it's poorly documented :)
[23:22] <doctormo> lfaraone: Of course! don't you know anything about Science!
[23:24] <bdrung> i had two problems at the beginning: 1. i didn't know all tools. there are a bunch of tools. you need to know how they play together 2. i didn't know how debian/rules worked. which targets were called in which order.
[23:25] <doctormo> bdrung: The targets thing sounds important
[23:26] <bdrung> doctormo: there are only one or two websites showing the targets graph
[23:26] <bdrung> doctormo: maybe it's time for a gui helping to create a package
[23:28]  * lfaraone just used CDBS and didn't worry about targets :)
[23:29]  * sistpoty recalls a packaging without helpes session