[00:16] <coppro> I smell a broken dependency!
[00:19] <NCommander> rofl
[00:19] <coppro> wait, false alarm, synaptic doesn't mention replaced packages
[00:20] <mneptok> coppro: no, just a broken Depends
[00:27] <nxvl> persia: ready for the last 48 hours before relase?
[00:27]  * nxvl still remembers hardy's last 48 hours as if it were last week
[00:31] <NCommander> nxvl & persia: does anything special happen in the last 48?
[00:32] <nxvl> yeah
[00:32] <nxvl> bug squashing
[00:32] <nxvl> mainly ftbfs
[00:32] <ajmitch> finding SRU candidates
[00:32] <nxvl> that too
[00:32] <nxvl> but SRU's can wait 2 days
[00:33] <NCommander> nxvl, if you see any good FTBFS, I'll work on it
[00:33] <nxvl> \o/
[00:33] <nxvl> NCommander: compiz is FTBFS on lpia, still haven't have a closer look, but it's faling
[00:33] <nxvl> failing*
[00:34] <NCommander> do we care about lpia ;-) *shot*
[00:34] <NCommander> link to build log
[00:34] <nxvl> http://qa.ubuntuwire.con/ftbfs
[00:35] <nxvl> i cara about pia, it's what we use on netbooks
[00:35] <nxvl> :D
[00:35] <NCommander> con?
[00:35] <NCommander> :-P
[00:35] <NCommander> compiz is hosed because KDE is hosed
[00:36] <NCommander> nxvl, your not a core dev, right?
[00:36]  * NCommander notes that KDE just need a whole bunch of retrying to clear up the builds
[00:36] <NCommander> ScottK, poke
[00:36] <nxvl> nop
[00:36] <NCommander> wait
[00:36] <NCommander> ...
[00:36] <NCommander> crap
[00:36] <NCommander> This might be my fault
[00:37] <NCommander> Yes
[00:37] <NCommander> Yes it is
[00:37] <NCommander> Crap
[00:37]  * NCommander is responsible for the upload that broke kde4bindings on lpia 
[00:37] <NCommander> Which broke KDE
[00:37] <NCommander> Which broke compiz
[00:37]  * ajmitch claps
[00:37] <NCommander> I thought we rolled back that upload
[00:37] <NCommander> ajmitch, oh hush
[00:37] <NCommander> Is it too late to get one last upload in? :-) *shot*
[00:38] <azeem> that compiz log is from Oct 17th, AFAICT
[00:38] <NCommander> azeem, its still broken
[00:40] <NCommander> nxvl, is it the end of the world if compiz and friends have to be fixed via -updates?
[00:41]  * cody-somerville blinks.
[00:41] <slangasek> a) no, b) if it is it should have been escalated last week or earlier
[00:43] <NCommander> cody-somerville, on lpia
[00:43] <NCommander> oh well
[00:44] <NCommander> slangasek, if a build is broken due to depwait, and that dep-wait is cleared via updates, (i.e. kde4bindings is fixed via updates), can those builds simply be retried, or do we need to push an upload to the -proposed/-uploads tree?
[00:47] <slangasek> I believe soyuz will require a -proposed upload
[00:47] <NCommander> wait
[00:47]  * NCommander is off the hook
[00:47] <NCommander> I didn't break bindings
[00:47] <NCommander> *phew*
[00:48] <NCommander> kde4bindings was dep-waited on libplasma2, and it didn't clear properly
[00:48] <NCommander> It builds properly out of the box now it seems
[02:52] <persia> nxvl, Just as a counter statement : fixing FTBFS during this 48-hour window isn't very useful : one wants to have done that *before* archive freeze.  For now, there's just image testing and waiting for -proposed to open (which usually happens within a couple days of release).
[02:56] <NCommander> persia, I'm sorta suprised proposed isn't already open (it already exists along w/ backports and updates)
[02:58] <coppro> what is -proposed? Not familiar with that archive [/newb]
[02:59] <persia> NCommander, Well, it accepts uploads, but they get blocked in unaccepted as a side effect of the current state of the main archive, and the release team is busy with other things, so doesn't accept them.
[02:59] <persia> Err.  It *allows* uploads ...
[02:59] <rhpot1991> ScottK ScottK-laptop ping
[02:59] <persia> coppro, -proposed is a respository to which candidates for -updates are uploaded for testing before they get passed in SRUs.
[03:00] <ScottK-laptop> Yes
[03:00] <ScottK-laptop> rhpot1991: ^^
[03:00]  * NCommander also notes the existance of backports
[03:00] <coppro> thanks
[03:00] <rhpot1991> ScottK-laptop: superm1 told me to come and talk to you about a package
[03:00] <ScottK-laptop> Uh oh.
[03:00] <ScottK-laptop> What's up?
[03:00] <rhpot1991> I fixed some bugs, but I guess the archive is locked now
[03:00] <persia> NCommander, backports are not supposed to be used for things that fix bugs.
[03:01] <ScottK-laptop> rhpot1991: It is, but intrepid-proposed is open if they are severe problems that should be fixed post-release.
[03:01] <rhpot1991> wondering what I should do
[03:01] <persia> (well, excepting bugs in backports packages)
[03:01] <NCommander> persia, we have used it for minor bugs that don't meet SRU certeria
[03:01] <persia> NCommander, That didn't include new upstream versions?
[03:02] <NCommander> persia, as long as the fix is in a newer release, we can backport it
[03:02] <ScottK-laptop> persia: Yes.  If it's too minor for SRU then a backport isn't actually harmful.
[03:02] <NCommander> Generlaly, if a backport is for a bug fix, we ask them to get SRUs two cents
[03:02] <persia> ScottK, OK.  I think that represents a change in policy, but don't explicitly object.
[03:02] <NCommander> If SRU rejects, we backport it then
[03:03] <rhpot1991> ScottK-laptop: there are 3 of them listed here: https://code.launchpad.net/~mythbuntu/mythexport/trunk
[03:03] <rhpot1991> they are far from critical to systems
[03:04] <ScottK-laptop> persia: My interpretation of the guidance from the TB is that backports should not be a path to avoid SRU so that all users benifit from fixing significant bugs.
[03:04] <ScottK-laptop> I think using backports for both minor fixing and new features is consistent with that policy.
[03:05] <ScottK-laptop> rhpot1991: Pointing me at bzr isn't goint to get us very far.
[03:05] <rhpot1991> sorry, was pointing at the 3 bugs on that page
[03:06] <NCommander> where is this guidance on backports
[03:06] <persia> ScottK, Makes sense.  I'm more going off my memory of the BackportsProcess wiki page, which may well be out of date.
[03:06] <NCommander> persia, the BackportsProcess page is out of date
[03:07] <NCommander> (at least with respect to some things like testing requirements)
[03:07] <ScottK-laptop> NCommander: That's my recollection of what jdong told me his guidance from the TB was when backports was brought in out of the wilderness and made official.
[03:07] <rhpot1991> ScottK-laptop: basically just looking for where to go from here, I would have liked to have gotten them in, but since I didn't should I start a SRU?
[03:08] <NCommander> I know we've done somethings with backports that bend the rules (i.e. KDE 3.5.10, since that wasn't pulled from intrepid)
[03:08] <ScottK-laptop> rhpot1991: That's the path you should take.  I'm not on the motu-sru team and so I can't approve it.
[03:08] <rhpot1991> ScottK-laptop: thanks, was just looking for a little guidance.  Think its a good idea to start it now or wait till after release?
[03:09] <ScottK-laptop> Now.
[03:09] <persia> NCommander, Perhaps you'd like to update it so those of us less familiar with backports don't get confused?
[03:09] <rhpot1991> ok, thanks
[03:09] <ScottK-laptop> Stuff can be uploaded to intrepid-proposed now.  It just doesn't get published until after release.
[03:10] <NCommander> persia, probably a good idea, but I'll let jdong do that, since backports is his baby, and I might leave something out important
[03:10] <NCommander> (the only section I think that is vastly out of date are the testing requirements, which are pretty much relaxed down to one confirmed b/i/r)
[03:10] <persia> NCommander, Probably faster to update it, and point him at the updates for confirmation : it's usually less work to review a 90% complete job than to start from scratch.
[03:11] <NCommander> persia, we should note the exception to the rule that every backport must come from an Ubuntu release
[03:12] <ScottK-laptop> NCommander: Let's not broadcast that one too broadly.
[03:12] <persia> If that restriction is lifted, it would be good to change.  I've told lots of people they have to wait for a backport based on that rule.
[03:12] <NCommander> persia, its a sanity rule
[03:12] <NCommander> If backprots > next release
[03:12] <NCommander> Bad things happen
[03:13] <ScottK-laptop> persia: The only times we've relaxed it is when it wasn't possible to do otherwise.
[03:13] <persia> ScottK, So what is the appropriate guidance to give requestors?  "No, you can't have a backport until it is available in the next release" or "File a bug against backports : the backports team will be able to determine if it is possible to backport that release"?
[03:13] <NCommander> THe only exception we make usually is if the release in development is unusable for backports, but there is a version (from sid, or simply repackaging a tarball) can be done
[03:15] <ScottK-laptop> persia: The advice is no you can't have it until it's in a later Ubuntu release.
[03:15] <ScottK-laptop> If it won't/can't be in a later release, then we can talk.
[03:15] <coppro> so when will we see OO.o 3.0
[03:15] <NCommander> coppro, when it lands in jaunty, then backported to both intrepid and hardy
[03:17]  * ScottK-laptop notes we do have python3.0 packages.
[03:17] <persia> ScottK, OK.  I'll keep providing that guidance.  If someone doesn't believe me (hey, I'm not on the backports team), and pushes, perhaps they will discover the possibility of exception.
[03:18] <coppro> is there any way to keep track of what's in backports?
[03:23] <ScottK-laptop> OK.  I've now used Ubuntu and I didn't like it.
[03:23] <NCommander> ScottK-laptop, O_o?
[03:24] <NCommander> persia, you should come join us down in backports
[03:24] <ScottK-laptop> Yeah.  Dead box and I needed a Live CD session to get a needed .deb on the hard drive.
[03:24] <coppro> you normally a KDE guy?
[03:24] <nxvl> persia: for hardy i remember we did that
[03:25] <ScottK-laptop> The only remaining Hardy CDs I have are from the stack of 10 Ubuntu CDs I got from ship-it because someone didn't notice (I guess) the K
[03:25] <ScottK-laptop> coppro: Yes.
[03:25]  * coppro is also K
[03:25] <ScottK-laptop> I needed a Hardy CD because this box won't boot Intrepid so far.
[03:25]  * nxvl hates the K
[03:25] <nxvl> :D
[03:26] <nxvl> what i actually hate is that EVERY package start with K
[03:26] <nxvl> that annoys me
[03:26] <ScottK-laptop> nxvl: Have you tried KDE4?
[03:26] <nxvl> yup
[03:26] <nxvl> still hate it
[03:26] <ScottK-laptop> nxvl: You mean like Kompozer?
[03:26] <nxvl> Konsole
[03:26] <nxvl> Kopete
[03:26] <NCommander> K Desktop Environment
[03:26] <ScottK-laptop> nxvl: Kompozer is not a KDE package.
[03:26] <nxvl> Konkeror
[03:27] <persia> nxvl, We did it over the weekend before release (we did that this time too).
[03:27] <persia> NCommander, I don't currently have the available resources to also work on backports, but thanks for the invitation.
[03:27] <nxvl> persia: really? i remember to be running against the time before the release or it was before the freeze?
[03:27] <persia> nxvl, It was before the freeze.  There was a similar run this time, but not as many people joined (and you weren't one of them).
[03:28] <nxvl> right
[03:28] <nxvl> it was before freeze
[03:28] <nxvl> i remember you said "keep uploading until someone tells you to stop"
[03:28] <nxvl> :D
[03:29] <ScottK-laptop> Yeah, well you've been told to stop.
[03:29] <nxvl> yes
[03:29] <nxvl> :D
[03:29] <nxvl> now i remember
[03:30] <nixternal> kind of like gedit, gstreamer, gdesklets, gconf, gvfs, and more?  <- nxvl  :P
[03:30] <nxvl> now it's clearer why i remember that so closer to this date
[03:30] <nxvl> nixternal: that's why i don't use most of them, or if i do i don't know i use them
[03:30] <nxvl> :D
[03:31] <persia> nxvl, So, next time, plan your time so you can chase stuff madly for the 72 hours after RC releases.
[03:31] <nxvl> what i actually love about Gnome and why i don't use KDE is that with gnome yo don't notice the desktop, it's just there silent, but with KDE you notice it every day since you can, and you mostly do, configure it the way you want
[03:31] <persia> nxvl (or just fix all the FTBFS and RCbugs before this)
[03:32] <nxvl> persia: i think i did it, and i was confusing it with the 48 hours before hardy
[03:32] <nxvl> persia: but it was the 48 hourse before RC freeze, or beta
[03:32] <nxvl> anyway, need to reboot, brb
[06:00] <dholbach> good morning
[06:42] <iulian> Morning dholbach.
[06:42] <dholbach> hi iulian
[08:18] <stefanlsd> james_w: you around?
[08:48] <didrocks> morning o/
[08:52] <directhex> is it? bah :(
[09:32] <huats> morning !
[09:33] <BugMaN> morning huats
[10:00] <sistpoty|work> hi folks
[10:05] <Hobbsee> hey sistpoty|work!
[10:05] <sistpoty|work> hi Hobbsee
[10:11] <huats> Laney: once you are back ping me :)
[11:29] <Laney> good day huats ;)
[11:34] <verwilst> has TKIP for wireless been removed for intrepid?
[11:38] <highvoltage> verwilst: do you have an atheros card?
[11:39] <verwilst> euh no Intel Corporation PRO/Wireless 3945ABG
[11:41] <persia> I've seen some traffic about issues with that card, but I think there was a solution found.  Check the release notes to be sure.
[11:41] <verwilst> well it's not really a traffic issue
[11:43] <verwilst> you just can't choose TKIP anymore
[11:47] <verwilst> which is used in our corporate network
[13:01] <huats> ping nxvl
[13:11] <cambridgecow> is getdeb.net in anyway associated with the MOTU's?
[13:12] <joaopinto> cambridgecow, no
[13:12] <laga> i hope not
[13:17] <gouki> cambridgecow, no. getdeb.net is a project by a member of the ubuntu-pt community.
[13:19] <joaopinto> gouki, correction, by a team :P
[13:19] <gouki> There you are :P
[13:24] <ScottK-laptop> But it would not be correct to infer that getdeb was in any way associated with Ubuntu.
[13:26] <joaopinto> ScottK-laptop, please add the word "officially", getdeb is driven by/to the Ubuntu community
[13:38] <nevans> question about a version number: 1.3.0~RC1really1.2.0-2ubuntu3 ... what does that mean?  is it 1.3.0 RC1 or 1.2.0?  :)
[13:38] <DktrKranz> nevans: is it ruby?
[13:38] <nevans> that's from http://packages.ubuntu.com/intrepid/rubygems ... I'm just looking into certain packages before I upgrade.
[13:38] <nevans> DktrKranz, yep
[13:39] <nevans> rubygems: the perpetual annoyance to packagers, I'm sure.
[13:40] <mathiaz> nevans: it's 1.2.0
[13:40] <nevans> mathiaz, then why the 1.3.0~RC1?  :)
[13:41] <mathiaz> nevans: long story - see bug 145267 for more information. short version: 1.3.0RC1 was uploaded but reverted later to 1.2.0
[13:41] <nevans> mathiaz, thanks.
[14:41] <bddebian> Heya gang
[14:44] <sistpoty|work> hi bddebian
[14:44] <bddebian> Hi sistpoty|work
[14:45] <RainCT> porthose: I've read your idea (and I had actually though about someting similar before), but give me some more time to think about it :)
[15:13] <nxvl> persia: http://jamesburkle.wordpress.com/2008/10/28/motu-mentors-mailing-list/ <- that's what you were trying to avoid?
[15:13]  * persia grumbles at epiphany freezing hard when trying to add an exception for an invalid security certificate
[15:16] <stefanlsd> heh. great way to get +1 on your app. heh. doesnt really seem to offer any constructive or address the source first.
[15:16] <RainCT> persia: btw, I've just created a patch for the REVU cookies to last longer. I'll apply it on production once I'm sure that it's working :)
[15:19] <persia> nxvl, Yep.  That's precisely what I wanted to avoid.  Either that belongs on -motu, or some set of people have to be watching -motu-mentors, and answering the questions.
[15:19] <nxvl> yup
[15:19] <nxvl> agreed
[15:19] <persia> RainCT, Thanks.  Is it not possible for them to last a very long time (at least the length of the session, if not indefinitely)?
[15:21] <RainCT> persia: The patch is for mod_python to let the cookies last as long as the session, and the session is currently expires after 86400 seconds, but I'm going to make that configurable
[15:23] <persia> RainCT, Hrm.  OK.  The part that always confused me about REVU was that sometimes I could reboot, and it would keep me logged in, but sometimes closing my browser was enough that I had to log in again, and sometimes I had to log in again while actively working with REVU (timeout would happen between loading a page and entering the comment).
[15:23] <persia> Would it be possible instead to have it be something like 1 hour past the last page load in a session, or similar?
[15:23] <persia> Aboslute timeframes work badly for this sort of thing, to my mind.
[15:27] <RainCT> persia: I'd say that's what it'll do now (replacing "1 hour" with the configured amount), but if you still experience the same problem after I apply the patch tell me and I'll have another look at mod_python's..
[15:27] <RainCT> s/mod_python's/mod_python/
[15:30] <persia> RainCT, Well, I'm not likely to be a heavy REVU user for another week or two, but if I get another session timeout while working with REVU, I'll let you know right away.
[15:33] <jdong> siretart: what are our plans for VLC 0.9.5?
[16:21] <siretart> jdong: ATM I don't have any plans for that. Feel free to update if you feel like it
[16:23] <jcastro> YokoZar: slots are running out, hurry!
[16:25] <jdong> ScottK: ^^ what do you feel as ~motu-release regarding the above? VLC 0.9.5 fixes a security bug and "various bugfixes" as described by upstream
[16:26] <siretart> jdong: TBH, this looks like SRU stuff to me right now. my current plan is to get the vlc package in debian updated first
[16:26] <jdong> siretart: yeah, I agree on this. For no rdepends, I woudln't mind tracking upstream 0.9.x releases in -updates
[16:29] <sistpoty|work> jdong: I don't think we have much chance to get anything sqeezed into intrepid itself right now --> updates would be more appropriate
[16:29] <sistpoty|work> (or maybe -security)
[16:37] <jdong> sistpoty|work: agreed.
[16:37] <jdong> I'm gonna play with a POC for the exploit
[16:37] <jdong> I want to see if it would get caught by our passive hardening.
[16:38] <jdong> [00000379] ty demux error: Unsupported SEQ bitmap size in master chunk
[16:38] <jdong> *** stack smashing detected ***: vlc terminated
[16:38] <jdong> siretart: ^^ :)
[16:47] <siretart> jdong: cool :-)
[16:48] <jdong> siretart: yeah, a much better prospect than random code execution on double-clicking a .mpg file :)
[16:48] <jdong> i love GCC hardening.
[16:52] <siretart> we should still fix the issue though
[16:52] <YokoZar> jcastro: haha cool I got the spot after Mark :)
[16:52] <jcastro> YokoZar: rock
[16:53] <jcastro> YokoZar: I don't know why people didn't pick that before, it's like 300+ people off the bat
[16:53] <jdong> siretart: absolutely we should but it's not as deathly urgent as it would be
[16:55] <YokoZar> jcastro: because he just picked it ;)  Was blank 2 minutes ago, I put in mine and then by coincidence he got it.
[16:56] <siretart> jdong: indeed
[18:01]  * sistpoty|work heads home... cya
[19:14] <lobo-ptr> hi, I've created a patch for bug http://is.gd/5290 . This is my first attempt to fix a bug in Ubuntu and I'm a little confused with freeze. Don't know if I should post it now or after new 8.10 release.
[19:19] <geser> lobo-ptr: you can add it now too, but as the bug isn't important it won't get fixed for intrepid. You patch should get applied on the next upload (for jaunty)
[19:23] <lobo-ptr> geser, thanks, I'll do that
[19:38] <sebner> ScottK-laptop: Added a comment to the ogle removal request (set to invalid)
[19:38] <sebner> emgent: \o/
[19:41] <geser> lobo-ptr: I gave a quick look at your debdiff and it looks good.
[19:42] <lobo-ptr> geser, cool :]
[19:44] <lobo-ptr> geser, i've changed bug status to fix committed, but now I'm in doubt, if Iiiiiiiii should do this
[19:58] <fabrice_sp_> Hi. With the Intrepid now out (or near), what can I do with bugs like Bug #290164?
[20:00] <geser> lobo-ptr: looking at https://wiki.ubuntu.com/Bugs/Status, I guess Triaged would be better (Fix Commited is wrong according to that page)
[20:02] <lobo-ptr> geser, you're right, but now i can't set it back to triaged
[20:03] <geser> why not?
[20:03] <geser> lobo-ptr: I've done it now.
[20:04] <lobo-ptr> geser, don't know, option is not available in dropdown
[20:04] <lobo-ptr> geser, thanks
[20:07] <lobo-ptr> geser, do I need to do something else?
[20:18] <jcastro> straw poll: when you guys have a patch to send upstream do you do it in the upstream bug tracker directly or do you put it in lp and then put a link in the upstream bug tracker?
[20:19] <laga> i put it in the upstream bug tracker directly.
[20:19] <laga> upstream has a bug tracker for a reason. they usually do not want to go to whatever $distro uses
[20:23] <ScottK-laptop> jcastro: Upstream bug tracker.
[20:24] <ScottK-laptop> jcastro: A lot of FOSS projects aren't a fan of LP.  Most of my 'upstreaming' is to Debian and it's particularly true there.
[20:24] <calc> when i report bugs upstream to OOo I usually just put the url to the file in launchpadlibrarian since they limit attachments to only 1MB so I generally don't both to attach directly anymore
[20:24] <ScottK-laptop> jcastro: Additionally, I think we want to make life as easy as possible for upstream.
[20:24] <calc> s/both/bother/
[20:25] <jcastro> ok so let's say you're looking at a bug and a user posts the patch, you do all the discussion and review etc. in lp then when it's ready you just post it upstream?
[20:25] <jcastro> calc: ah that's interesting
[20:25] <ScottK-laptop> Yes.  With an explanation of why the patch is needed and what it does
[20:25] <calc> a lot of the files i want to attach are more than 1MB which is why i don't even bother to check the size then attach or link anymore
[20:26] <calc> esp microsoft related binary files
[20:26] <jcastro> ScottK-laptop: so I know this seems like common sense and best practice, I am just wondering if we need to explain that better to new contributors
[20:26] <calc> memory dumps for document types are ewww :(
[20:27] <ScottK-laptop> jcastro: I have a hard time finding my way through our docs now, so I'm not the best one to ask about how we explain stuff.
[20:27] <ScottK-laptop> I mostly find stuff in the wiki via redirects from old pages it seems.
[20:28] <jcastro> yeah so I was noticing that which is why I ended up here
[20:29] <ScottK-laptop> jcastro: I'd suggest ask a new contributor.
[20:30] <ScottK-laptop> Gotta run.
[20:41] <DktrKranz> doko, could you please comment on bug 211309? it seems it has been fixed differently in bug 258624.
[21:17] <DktrKranz> jdong, did you do any progress with bug 200025?
[22:13] <jdong> DktrKranz: I got stuck on that bug at the point of finding a video file to demonstrate the phenomenon
[22:13] <jdong> verification is going to be difficult by strict SRU guidelines as a failure case is hard to point out
[22:13] <DktrKranz> jdong, thanks
[22:14] <ScottK> jdong: Stuck finding a video file or stuck finding one you were willing to admit you'd watched?
[22:14] <jdong> DktrKranz: yeah I'm really not sure how to proceed (or if we should proceed)
[22:14] <jdong> ScottK: no comment ;-)
[22:15]  * DktrKranz is curious