[00:02] <dgrt> mok0: thanks! I will.
[00:12] <slangasek> TheMuso, Hobbsee: ping
[00:20] <slangasek> TheMuso, Hobbsee: bug #214083, fwiw
[00:20] <ubotu> Launchpad bug 214083 in opensync "[FFe request] Please sync opensync_0.22-2 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/214083
[00:20] <TheMuso> slangasek: Isn't that main?
[00:20] <slangasek> TheMuso: the plugins are in universe and need updated at the same time
[00:20] <TheMuso> slangasek: Oh right, will attend to that, as I want to see this in. :)
[00:21] <slangasek> ok :)
[00:41] <xtknight> LaserJock, the feisty-proposed flash debdiff is up at bug 173890
[00:41] <ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install due to md5sum mismatch" [Undecided,Confirmed] https://launchpad.net/bugs/173890
[00:44] <superm1> LaserJock, i talked to the adobe rep at LF today, he wasn't aware of the issue with the naming scheme, and said he'd poke around to get it fixed
[00:44] <superm1> so we may have a better situation in the future
[00:56] <LaserJock> superm1: awesome thanks
[02:10] <bddebian> Heya gang
[02:11] <RAOF> bddebian heya!
[02:11] <bddebian> Hi RAOF
[02:11] <RAOF> (Why doesn't heya tab autocomplete? :))
[02:11] <RAOF> nv4x gallium now does reflections properly!  neverball isn't evilly slow!
[02:11] <bddebian> heh
[02:12] <RAOF> Although it doesn't seem to want to quit :)
[02:16] <ajmitch> RAOF: but can it play WoW in wine? :)
[02:16] <lifeless> RAOF: how did mandalon and mantuu go?
[02:17] <RAOF> lifeless: It turns out that lvl 70 mages kick the pants of lvl 19 mobs.  Who'd've thought?
[02:17] <RAOF> But there didn't seem to be _that_ much XP gained.  Mantuu is now 17.3
[02:18] <ajmitch> let me guess, a deadmines run?
[02:18] <RAOF> SFK
[02:18] <StevenK> If you play with a much higher level character in a group, your XP is hamstrung
[02:18] <lifeless> StevenK: its a net win done well
[02:18] <lifeless> RAOF: how long was the run? 20 minutes or so ?
[02:19] <RAOF> lifeless: maybe 1/2 an hour?
[02:19] <nalioth> anybody got a couple of minutes to help oil my rusty brainz?
[02:19]  * StevenK did a deadmines run with two other 70s about a week ago
[02:19] <lifeless> RAOF: do you have an xp/hour figure?
[02:19] <RAOF> lifeless: I think it was somewher around 13K/hr
[02:19] <lifeless> RAOF: so, 1 level / hour.
[02:20] <lifeless> RAOF: that can be increased with practice :P
[02:20] <RAOF> ajmitch: Nope; WoW still dies in st_program_stringify (which I should check against that intel mesa bug; it may well be that gallium hasn't had the fix applied).
[02:20] <lifeless> StevenK: three 70's?
[02:21] <StevenK> A rogue stealthed in, and killed all the bosses aside from VC himself, and then a 70 pally ran through the instance trying to drag every mob up to VC so we could try and kill everything at once.
[02:21] <lifeless> StevenK: rotfl
[02:21] <StevenK> It was great fun.
[02:22] <lifeless> StevenK: I *can't* do that on my mage; level one arcane explosion kills the mobs too quickly
[02:22] <ajmitch> or a paladin tankign all of a scarlet monastery wing?
[02:22] <StevenK> I've not seen that -- that would be cool.
[02:22] <ajmitch> RAOF: a shame, it'll be good to start replacing the binary blob
[02:22] <lifeless> ajmitch: meh, a clothy can do all of SM nonstop
[02:22] <StevenK> Aside from the fact that Scarlet Monastery sucks to get to
[02:22] <ajmitch> StevenK: having a trinket that heals on each block is useful there
[02:23] <ajmitch> lifeless: in 1 pull?
[02:23] <lifeless> figurine of the colossus
[02:23] <lifeless> ajmitch: if you mean 'without dropping out of combat' yes
[02:23]  * StevenK plays a 'lock, still wearing cloth and no shield
[02:23] <lifeless> ajmitch: walk and ae nostop
[02:23] <StevenK> Well, I have a shield, it's called a Felguard.
[02:24] <lifeless> ajmitch: frost nova every time its up
[02:24] <ajmitch> ah, by the time I get home from work, the new badge vendor should be open
[02:25] <StevenK> Mmmmm, the Isle
[02:25] <StevenK> Dath finally hit phase 3 last night.
[02:25] <ajmitch> khaz is at 97% for the vendor
[02:25] <RAOF> lifeless: On the plus side, Mantuu is coated in delicious blue
[02:25] <lifeless> RAOF: I'm jealous
[02:25] <StevenK> ajmitch: Which phase is that? If you know what you're fighting for, I can figure it out
[02:26] <lifeless> RAOF: also, lvl 18 :P
[02:26]  * StevenK replaced one of his greens last night.
[02:26] <StevenK> One more green and I'll be blue and purples only
[02:26] <ajmitch> StevenK: midway through phase 3
[02:26] <RAOF> lifeless: We picked up an 2h blue axe you would have loved.  Sadly, BoP.
[02:26] <lifeless> RAOF: ah well, we will get to sfk in a coulple of weeks I think
[02:27] <ajmitch> 1 more purple trinket, and I'll have a full set of epic gear for dps
[02:27] <lifeless> I have 21 badges on my priest I think; need moar
[02:27] <StevenK> ajmitch: Ahhhhh, you're a bit a head of us. Dath was 4% into phase 3 when I went to bed last night
[02:27] <lifeless> cool
[02:27]  * ajmitch has 190 badges saved
[02:27] <lifeless> jubei has the badge vendor already
[02:27]  * StevenK has 14, and is due in Karazhan tonight, so that should give another 5
[02:27] <StevenK> (Depending which opera event we get)
[02:28] <RAOF>  /topic Welcome to #ubuntu-WoW
[02:28] <ajmitch> well, technically we've got the vendor, just not selling anything :)
[02:28] <StevenK> #ubuntu-wow actually exists, too
[02:28]  * slangasek stares
[02:28] <DarkMageZ> i didn't know there was a native linux binary for wow.
[02:29] <lifeless> StevenK: you aren't downing curator yet ?
[02:29] <RAOF> DarkMageZ: There isn't.  Wine runs it nicely though.  (On a laptop that isn't totally borked, like mine)
[02:29] <StevenK> lifeless: Our group needs better gear for Curator
[02:29] <DarkMageZ> ah, heathens the lot of you :P
[02:29] <bddebian> heh
[02:30] <bddebian> Yeah at least NWN runs natively on linux ;-P
[02:30] <RAOF> bddebian: Is that "natively", like the Eve client?
[02:30] <DarkMageZ> ut2k4 as well =D
[02:30] <RAOF> (Which embeds an old and crap cedega into it's installer)
[02:30] <bddebian> No, there was a Linux client and server
[02:31] <bddebian> Had to buy the windows CD to get the CD-key though :-(
[02:37] <nalioth> i used to have a pbuilder set up (still do) for breezy and dapper.  can anyone help me remember how to run this setup with breezy-base.tgz and dapper-base.tgz files in my pbuilder directory?
[02:38] <StevenK> nalioth: You can pass a --base-tgz argument
[02:38] <nalioth> StevenK: ah, excellent :)  thanks
[03:07] <YokoZar> nalioth: for some reason my pbuilder scripts broke when I upgraded to Hardy
[03:08] <YokoZar> nalioth: I'd recommend starting from scratch with the new pbuilderrc given on the wiki
[03:09] <nalioth> YokoZar: i seem to have it working ( but i do things the longhanded way )
[04:07] <emgent> good night people
[04:10] <Hobbsee> LaserJock: am now
[04:47] <Hobbsee> slangasek: looks to be doen
[05:14] <LaserJock> Hobbsee: you pinged me for something yesterday
[05:14] <Hobbsee> LaserJock: yeah.  what do you think would happen if all, or almost all, restrictions about paperwork applied for intrepid?
[05:16] <ajmitch> the people would revolt?
[05:17] <Hobbsee> would they? i thoguth they'd be pleased.
[05:18] <LaserJock> Hobbsee: what to you mean?
[05:18] <LaserJock> we through out all the "paperwork"?
[05:18] <LaserJock> *throw
[05:18] <Hobbsee> LaserJock: and put an emphasis on thinking before uploads
[05:18] <Hobbsee> for MOTU's
[05:19] <LaserJock> well, hmmm
[05:19] <LaserJock> that sounds pretty chaotic
[05:19] <LaserJock> I was thinking more like streamlining
[05:19] <Hobbsee> how so?
[05:19] <LaserJock> so that we have useful paperwork, helpful paperwork
[05:20] <LaserJock> well, in general I think throwing out all the rules is just swinging the pendulum (sp?) to the other side
[05:20] <LaserJock> a nice balance would be good
[05:21] <TheMuso> Wow. This is the first time I've seen code in a package to check copyright stuff...
[05:21] <ajmitch> but the suggestion wasn't raised to throw out everything?
[05:21] <LaserJock> ajmitch: Hobbsee just suggested it :-)
[05:21] <Hobbsee> ajmitch: i suggested it as a starting point - for MOTU's, anyway
[05:22] <TheMuso> Hobbsee: I'd withdraw from MOTU in a heartbeat. We still need some paperwork.
[05:22] <LaserJock> firstly, I think maybe we're obsessing too much "paperwork" and "beaurocracy"
[05:22] <LaserJock> I'm very guilty of that
[05:22] <LaserJock> in fact, we really don't have all that much
[05:23] <LaserJock> some policies could use some tweaks
[05:23] <StevenK> TheMuso: ... You would?
[05:23] <LaserJock> for instance, I'd like to make it possible for MOTU SRU to approve bug-fix microreleases
[05:23] <TheMuso> StevenK: If there was no paperwork involved for some MOTU related stuff, yeah I'd certainly think about it.
[05:24] <LaserJock> I think MOTU Release has done a good job of keeping things sane
[05:24] <LaserJock> so I don't think we need to do a lot there
[05:24] <LaserJock> Hobbsee: do you agree?
[05:24] <ajmitch> Hobbsee: how much do you trust all MOTUs? :)
[05:25] <Hobbsee> LaserJock: i don't think it's helpful that i'm getting told off by core canonical people, for asking them why they didn't do the required procedures, because i'm creating work for them, and they're just trying to get their job done.
[05:25] <LaserJock> ajmitch: I assume that's her poing ;-)
[05:25] <Hobbsee> ajmitch: it varies.
[05:25] <LaserJock> *point
[05:25] <LaserJock> Hobbsee: which procedures specifically are troublesome?
[05:25] <Hobbsee> LaserJock: actually having to file a uvfes, i think
[05:26] <Hobbsee> particularly for native packages, where the rules later changed.
[05:26] <LaserJock> ah
[05:26] <LaserJock> I agree
[05:26] <Hobbsee> they just want to upload and do their job, rather than fiddle with teh paperwork, because they're good enough that they're going to get it right anyway.
[05:26] <LaserJock> we can tweak that though fairly easily
[05:26] <ajmitch> LaserJock: by exempting core developers, or certain people?
[05:26] <Hobbsee> LaserJock: motu release certainly isn't looking - or even if they are, there's no real way that we can raise it with people when they're not following policy
[05:27] <ajmitch> or delegating all responsibility for certain packages?
[05:27] <LaserJock> ajmitch: perhaps for a time
[05:27] <Hobbsee> ajmitch: if you exempt canonical, core devs, and trusted (older) MOTU's, then taht would work quite well.  But, you couldn't then say that there was no canonical/community split, and the people who don't fall into the trusted category woudln't be happy.
[05:28] <LaserJock> we can say that for native packages whether a UVFe is needed is up to the descretion of the developer
[05:28] <LaserJock> for non-native it's pretty obvious and you avoid having to do UVFes for trivial changes
[05:28] <ajmitch> Hobbsee: in practice, we know there's a split
[05:28] <Hobbsee> ajmitch: between which?
[05:29] <ajmitch> canonical & community practices
[05:29] <Hobbsee> ajmitch: certain canonical people will tell you until they're black and blue that there is none, and get pissed off that you're saying there is.
[05:29] <Hobbsee> so exacerbating that may not be so helpful.
[05:29] <LaserJock> well, we can make it workable
[05:30] <ajmitch> but I'm good at annoying people anyway
[05:30] <LaserJock> even if it's "ping a MOTU Release member and get an IRC ok first"
[05:30] <Hobbsee> ajmitch: sure, but then they discredit you publically.
[05:30] <Hobbsee> ajmitch: which often doesnt' help for getting other stuff done
[05:30] <ajmitch> no big deal
[05:31] <Hobbsee> ajmitch: it is when the discussions suddenly die.
[05:32] <Hobbsee> but, meh.  I'd prefer not to deal in rants about how i can't effectively contribute to MOTU, again.
[05:33] <Hobbsee> LaserJock: is it worth making that split worse, seeing as our non-canonical people are likely to be a larger group than the canonicalites?
[05:33] <LaserJock> sure you can
[05:33] <LaserJock> we don't have to make the split worse
[05:33] <LaserJock> I don't see how I'm saying that at all
[05:34] <LaserJock> I'm saying we can have a pretty laid-back and flexible policy that still provides guidlines
[05:35] <LaserJock> Canonical people can be held to the exact same standard as everybody else
[05:35] <LaserJock> and I don't think they expect less really
[05:35] <Hobbsee> does that actually happen in practice?
[05:35] <LaserJock> mostly yes
[05:35] <ajmitch> I'd say it mostly does
[05:35] <ajmitch> not that I've been watching closely in recent months :)
[05:36] <LaserJock> we have a few instances each release of Canonical people "sneaking" things in last minute to get a spec done or things like that
[05:36] <LaserJock> but we can handle that fine
[05:36] <StevenK> But since the discussion was had privately, it didn't happen?
[05:37] <StevenK> (I'm guessing)
[05:37] <LaserJock> StevenK: regarding what?
[05:37] <StevenK> LaserJock: Never mind
[05:38] <LaserJock> I don't think anybody has said that Canonical people should be treated any differently
[05:38] <LaserJock> mostly what happens is people are either unaware of the policies or disgree on the interpretation
[05:39] <LaserJock> *that* we can fix I think
[05:39] <LaserJock> I've certainly noticed that Main tends to be more flexible than Universe
[05:39] <slangasek> Hobbsee: yep, thanks though :)
[05:39] <LaserJock> which is pretty weird
[05:39] <Hobbsee> slangasek: y/w
[05:40] <Hobbsee> LaserJock: why are they unaware?  Are the decisions not on the ML enough?
[05:40] <LaserJock> well, honestly people are just used to uploading stuff
[05:40] <LaserJock> they know what they're working on and that it's good to go
[05:40]  * TheMuso beats the csound package into submission, since the person who requested its syncing didn't check that it built...
[05:41] <TheMuso> ...or, who acked it.
[05:41] <LaserJock> so I was thinking of doing like a developer cheat sheet
[05:41] <LaserJock> with like a checklist to make sure everybody is following the same or similar steps
[05:42] <Hobbsee> TheMuso: tasty.  And people wonder why i don't trust all MOTU's.
[05:43] <Hobbsee> TheMuso: transient, or "no way this could have built in ubuntu, under any circumstances"?
[05:43] <TheMuso> Hobbsee: It wouldn't have built, and likely not have even built in sid, but I haven't checked yet.
[05:43] <LaserJock> a problem I see is that we kind of have to have an agreed upon standard before we can really say "heah, you need to ..."
[05:43] <TheMuso> This copyright code I mentioned earlier found a discrepancy in the copyright data, and flagged it, hense the FTBFs.
[05:43] <slangasek> TheMuso: it did build in sid, fwiw
[05:44] <TheMuso> slangasek: Very interesting.
[05:44] <LaserJock> Hobbsee: I think a lot of the problems you are facing is that your fighting a subjective/non-existant standard
[05:44] <Hobbsee> LaserJock: because what's written in the wiki isn't a standard.
[05:45] <LaserJock> the question should not be "what should you have done?" but rather "did you do what everybody knows you should do" write?
[05:45] <Hobbsee> its' just suggestions.  or something.
[05:45] <LaserJock> no, I don't think that's really it
[05:45] <LaserJock> though some of it
[05:45] <LaserJock> I don't know what's on most of the wiki pages right now
[05:46] <LaserJock> like I said yesterday, I often spend more time finding and reading policy wiki pages than I do doing the work
[05:46] <Hobbsee> sounds like the people at UDS need to do a great wiki rework again.
[05:46] <LaserJock> well
[05:46] <ajmitch> the neverending story
[05:47] <LaserJock> I'm not sure that just endlessly "redoing" the wiki is what we need
[05:47] <LaserJock> hence why I was thinking of a cheatsheet
[05:47] <nixternal> to noisey in here
[05:47] <LaserJock> nixternal: go to bed vista lover
[05:47] <nixternal> I am trying to
[05:48] <nixternal> I have a long drive to Michigan in the morning...not looking forward to that
[05:48] <Hobbsee> LaserJock: cheatsheets would be a good idea.
[05:48] <ajmitch> nixternal: just dream of vista on the way
[05:48] <nixternal> I dream of you!
[05:48] <ajmitch> isn't that sweet?
[05:48]  * ajmitch finds a bucket
[05:48] <nixternal> it sure is
[05:48] <nixternal> hahahaha
[05:49] <LaserJock> I personally think a lot of the policy wiki pages could be simplifies or clarified
[05:49] <nixternal> clarified yes
[05:49] <LaserJock> I read and reread the SRU page like 4 times yesterday to figure it out
[05:49] <nixternal> LaserJock: if you work up something I will help you tackle the wiki changes
[05:49] <LaserJock> and I'm on MOTU SRU!
[05:49] <nixternal> haha
[05:49]  * ajmitch would need to study for a week before doing any uploads
[05:50] <LaserJock> exactly
[05:50] <TheMuso> Right, csound dealt with.
[05:50] <LaserJock> I want packaging to be the bottleneck for Ubuntu Developement
[05:50] <LaserJock> and that's what contributors are having a hard time with
[05:51] <LaserJock> that creating a package is just the beginning
[05:52] <LaserJock> so we need short, clear, and flexible policy pages
[05:52] <LaserJock> and not a bunch of them
[05:52] <LaserJock> and then have a cheatsheet page, a single page, that is all a dev needs once they've read the policy pages
[05:52] <slangasek> what does "flexible" mean here?
[05:53] <LaserJock> well
[05:53] <slangasek> i.e., how does "flexible" differ from "ignorable by people who think they know better but really don't, to the detriment of the archive"?
[05:54] <LaserJock> I was thinking about times when we make sort of insane policy "rulings" because that's what the wiki page says
[05:55] <LaserJock> *I* think it differs because I wouldn't say ignorable
[05:56] <LaserJock> but rather things like letting developers get IRC approval or doing more case-by-case judgements
[05:56] <LaserJock> I think a lot of things can be at the descretion of the developer
[05:56] <LaserJock> otherwise what's the point of being a developer?
[05:56] <LaserJock> the definition of MOTU/Core Dev is "we trust you to do day-to-day work in Universe/Main"
[05:57] <LaserJock> am I wrong?
[05:57] <Hobbsee> LaserJock: do *you* trust all the MOTU's to do day-to-day work in universe?
[05:58] <slangasek> all of the above is rather abstract, and I'm not sure what pages we're talking about that have led to insane policy rulings
[05:58] <LaserJock> honestly, no, not at the moment all of them
[05:58] <LaserJock> slangasek: the diffstat thing cjwatson was talking about yesterday?
[05:58] <LaserJock> slangasek: not allowing any new upstream releases in -updates?
[05:59] <slangasek> hrm
[05:59] <slangasek> well, the latter of those is a point of ongoing discussion in the archive team anyway
[05:59] <LaserJock> yeah
[06:00] <slangasek> but part of the trouble is that, once you say that /one/ package is allowed new upstream releases in -updates, it's very difficult to know where to draw the line
[06:00] <LaserJock> yeah
[06:00] <LaserJock> but that's where I think you can rely on the discretion of the developer for most cases
[06:01] <LaserJock> and the relavent oversight teams in others
[06:01] <LaserJock> but if we are honestly looking at what's best for the archive/users
[06:01] <slangasek> well, we do need to have clear guidelines for the archive team saying when we're supposed to push the button or not, and I don't think those guidelines are ever going to say "a MOTU vouched for it, so rubber stamp it"
[06:02] <slangasek> (wrt to -updates, that is)
[06:02] <LaserJock> why not?
[06:02] <LaserJock> not that I really disagree
[06:02] <LaserJock> but we used to just upload to -updates directly
[06:02] <slangasek> because not all MOTUs will necessarily be familiar with the guidelines for what's *supposed* to go into an SRU?
[06:02] <slangasek> well, ok
[06:02] <LaserJock> why not though?
[06:02] <slangasek> why wouldn't they be familiar with the guidelines?
[06:03] <LaserJock> is it really that hard to figure out what is SRU worthy?
[06:03] <LaserJock> that too
[06:03] <slangasek> because SRUs arguably don't fall under "day-to-day work"
[06:03] <RAOF> Because it's not necessary for "day to day" Universe activity?
[06:03] <LaserJock> I agree
[06:03] <LaserJock> and that's why I do think we need an "oversight" team there
[06:03] <slangasek> ok
[06:03] <slangasek> in that case, the failure was merely that the archive admin you tagged wasn't familiar with the oversight process and wasn't comfortable sticking his neck out :)
[06:04] <LaserJock> well, as being a member of the oversight team, I feel a little confined
[06:04] <LaserJock> I can't just look at an update and say "yeah, that's SRU worthy"
[06:05] <LaserJock> if I have things like "it can't be a new upstream release, it has to be fixed in the development release already, etc."
[06:05] <LaserJock> sometimes those are just not practical
[06:05] <LaserJock> and are more harm than good
[06:06] <LaserJock> so that's sort of what I'm thinking in terms of "flexible"
[06:06] <slangasek> ok
[06:06] <LaserJock> it could be that this is fairly specific to SRUs though
[06:06] <LaserJock> and not a general thing with "oversight" teams
[06:07] <LaserJock> I feel like as a MOTU SRU member *I'm* not being trusted
[06:07] <LaserJock> which I guess may or may not be true
[06:07] <LaserJock> but I'd hope if I wasn't trustworthy somebody would say something so I could step down
[06:07] <LaserJock> because *I* don't want to harm Ubuntu or the archive
[06:08] <slangasek> FWIW, it's my view that the flashplugin-nonfree SRU is one that should never have flown if it were a package in main or universe because there's really no assurance that it's not including random unrelated changes that would constitute regressions
[06:08] <LaserJock> sure
[06:09] <slangasek> but obviously you don't have many choices when it's a closed-source app; which we're having to contend with as well for the Canonical partner archive
[06:09] <LaserJock> I did the best I could, I had multiple people test the package for regressions on multiple browsers
[06:10] <slangasek> "not being trusted"> in seb128's case, that's probably not an inaccurate description, because he's been outside the SRU process so he doesn't know the decisions that have been made /institutionally/ wrt trusting people
[06:11] <LaserJock> but I'm slightly concerned because, for instance, I had that update in Fedora within a couple hours, and people notice that kind of stuff
[06:11] <slangasek> but I don't think it's a criticism of you /personally/
[06:11] <LaserJock> and the only real roadblock for us was getting it actually *into* the archives
[06:12] <LaserJock> right, and I know that. seb128 probably didn't even know I was in MOTU SRU
[06:12] <LaserJock> so I'm not holding that against anybody, for sure
[06:13] <slangasek> so should I file a wishlist bug against LP asking for the MOTU SRU team to have access to moderate the *-updates unapproved queues? :)
[06:13] <LaserJock> I think that's in the works already
[06:13] <slangasek> oh.  should I ask you for a bug number so I can +1 it? :)
[06:13] <slangasek> or do you think the right answer is that MOTU should be able to upload directly to -updates again?
[06:13] <LaserJock> I don't know if there's a bug for it, there is a blueprint I belive
[06:13] <LaserJock> no
[06:14] <LaserJock> that worked in the beginning
[06:14] <LaserJock> but after the dapper Xorg incident everybody got paranoid
[06:14] <LaserJock> and now that Universe is turned on by default we need higher standards
[06:14] <LaserJock> such that I don't think uploading to -updates should be called "day-to-day" work
[06:15] <slangasek> hmm, did I mean *-proposed or *-updates, probably not a good think for me to not be able to keep those two straight :-P
[06:15] <slangasek> s/think/thing/
[06:15] <LaserJock> to be honest, flash worked pretty darn well
[06:15] <LaserJock> once we got it into -proposed
[06:16] <LaserJock> we got the required 2 "works for me"s and pitti moved it to -updates promptly
[06:16] <LaserJock> really nice
[06:16] <LaserJock> I do have an issue with treating -proposed so carefully
[06:16] <LaserJock> the whole point of having it is to test stuff out
[06:16]  * slangasek nods
[06:17] <LaserJock> I would think it would be as "experimental" as the development release
[06:17] <LaserJock> and users should have about the same level of expectation of breakage
[06:18] <LaserJock> so I don't think archive admins should really need to do much other than perhaps make sure the versioning is sane
[06:18] <slangasek> well, IMHO if there are objective guidelines that we agree should be applied to SRUs, as a best-available heuristic for blocking broken updates and making sure the process is *scalable* by not eating up all the time of the handful of trusted MOTU/core devs involved with this stuff, those objective tests should be applied before -proposed rather than after
[06:18] <LaserJock> but to go through "MOTU ack", "MOTU SRU ack", "Archive Admin ack" just to get into -proposed seems a tad much
[06:19] <LaserJock> well, we've gone back and forth on that
[06:19] <LaserJock> whether the careful analysis should be done before -proposed or before -updates
[06:20] <LaserJock> I would think though that if the MOTU treated the upload as one would any other upload as far as testing, etc.
[06:20] <LaserJock> and that MOTU SRU acks it, it should be fairly safe to go into -proposed
[06:21] <LaserJock> would you agree?
[06:22] <slangasek> LaserJock: so you view it as a question of allowing better parallelization of the work effort by having it in -proposed as early as possible for testing?
[06:23] <LaserJock> well
[06:23] <slangasek> I was looking at it from the other side, that having users test packages that can never pass the SRU guidelines is time wasted, but I can see it both ways
[06:23] <LaserJock> if we have a testing repo but we have to do all the testing beforehand, what's the point?
[06:23] <LaserJock> no, they *should* pass SRU guidelines
[06:24] <slangasek> oh, ok then
[06:24] <slangasek> those are what I meant by "objective tests"
[06:24] <LaserJock> but I think by the time it's uploaded it should be there
[06:24] <LaserJock> so archive admin's shouldn't need to do anything but accept the upload
[06:24] <slangasek> as opposed to user testing, which is entirely subjective but we depend on to catch things that we can't automate
[06:25] <slangasek> oh, I agree; is that not what happens today, aside from the flash case?
[06:25] <LaserJock> well, I'm honestly not sure
[06:25] <LaserJock> I would think that's mostly how it goes
[06:26] <LaserJock> I personally test that every package I upload/sponsor builds and installs
[06:26] <LaserJock> and for SRUs specific testing to make sure the bug is indeed fixed and there are no obvious regressions
[06:27] <LaserJock> that's my minimum "objective tests"
[06:28] <LaserJock> is that sane?
[06:28] <LaserJock> do we need more than that for SRUs?
[06:29] <slangasek> does "no obvious regressions" mean runtime tests?  no requirements that the changes to the source be minimally intrusive?
[06:29] <LaserJock> if I'm preparing an SRU I do runtime tests
[06:30] <LaserJock> if I'm sponsoring one I might not do the runtime tests if I'm confident the sponsoree did them
[06:30] <LaserJock> and the minimally intrusive I think is a MOTU SRU judgement
[06:30] <LaserJock> but if I want an SRU to go through I'll do that
[06:30] <LaserJock> :-)
[06:31] <slangasek> so you think it shouldn't be a requirement for all SRUs?
[06:31] <LaserJock> which one?
[06:31] <slangasek> that the changes be minimal
[06:31] <LaserJock> I think it should
[06:31] <slangasek> ok
[06:31] <LaserJock> but what constitutes "minimal" is the discretion of the SRU team
[06:32] <slangasek> then I think we're pretty much on the same page :)
[06:32] <slangasek> well, ok; I understand "minimal" to imply "doesn't contain extraneous changes"
[06:32] <LaserJock> sure
[06:32] <slangasek> btw, where did we chase everyone else off to? :)
[06:33]  * TheMuso is here but is busy doing other things.
[06:33] <LaserJock> but from my view the only reasons for an "oversight" team are 1) to make sure the upload is SRU worthy 2) make sure the changes are minimal
[06:33]  * Hobbsee is drowning her sorrows in lots of drink.
[06:34] <LaserJock> so obviously MOTUs *should* be making minimal changes but MOTU SRU is there to make sure that's the case
[06:34] <slangasek> Hobbsee: are LaserJock and I one of the sorrows?
[06:34] <LaserJock> I hope not
[06:35] <Hobbsee> slangasek: no, not at the moment, at least.
[06:35] <slangasek> well if I'm to be drowned, I guess I'd prefer it to be in drink
[06:35] <LaserJock> so really, I expect MOTUs to basically make sure SRUs are good and MOTU SRU is around for Quality Assurance
[06:35] <Hobbsee> hehe
[06:36] <LaserJock> making sure that MOTUs are correctly applying these "objective tests" and know what is SRU worthy
[06:37] <LaserJock> in any case, the only thing I'm having issues right now with SRU is upstream microreleases
[06:37] <LaserJock> from a "oversight" team perspective
[06:38] <LaserJock> most of the SRU applications have been good
[06:38] <LaserJock> slangasek: do you know if the archive admins agree?
[06:38] <LaserJock> if we're causing problems for the archive admins I certainly want to know about it
[06:38]  * Fujitsu just read all the scrollback. Wow, there's a lot of it.
[06:39] <LaserJock> Fujitsu: sorry
[06:39] <Fujitsu> 'tis a most interesting discussion.
[06:40] <LaserJock> now that I've been thinking about stuff for a while
[06:40] <Fujitsu> And brought to light one of the strangest differences between main and universe I've seen lately: pinging slangasek on IRC vs. filing a bug and waiting for motu-release acks, for freeze exceptions.
[06:40] <LaserJock> I'm thinking a lot of the issues are basically MOTU consistency
[06:41] <slangasek> LaserJock: I don't know, the person to ask that particular question is probably pitti :)
[06:41] <LaserJock> we need to reliably expect that from MOTU to MOTU that we get similar results
[06:41] <slangasek> but I haven't /heard/ him complain
[06:41] <LaserJock> slangasek: good
[06:41] <LaserJock> he complained about the last SRU policy we had and we redid it
[06:41] <LaserJock> so that was nice to get feedback from the archive admins
[06:41] <slangasek> Fujitsu: you mean the pings today from people asking me to look at the unapproved queue?
[06:42] <Fujitsu> LaserJock: Or was that two or three policies ago?
[06:42] <LaserJock> maybe two
[06:42] <LaserJock> seems like it was fairly recently
[06:42] <Fujitsu> slangasek: I've seen a few `OK to upload <somepastebinurl>' today.
[06:42] <slangasek> (not actually something I'm in favor of, I don't particularly enjoy having my day be interrupt-driven :-P)
[06:42] <LaserJock> but the policy is kinda a blur
[06:42] <TheMuso> slangasek: heh just say file a bug. :)
[06:42] <LaserJock> slangasek: if it was a team rather than just you would it help?
[06:42] <slangasek> Fujitsu: right... IIRC, the universe policy says pinging motu-release on IRC is ok as well?
[06:43] <LaserJock> well, I honestly think there is often disconnect between what the wiki page says and what happens
[06:43] <LaserJock> and it depends on which team member you ask
[06:43] <slangasek> LaserJock: technically it is a team already, I still have the problem of being the one who can't pass the buck, which everyone else also knows :)
[06:44] <LaserJock> slangasek: you also hang out here. You're the only archive admin to do so
[06:44] <slangasek> but, I made a point in the u-d-a emails to also tell people "if it's sane, just upload it instead of asking first", which I think has improved things this time around vs. last cycle
[06:44] <LaserJock> which I appreciate tremendously, btw
[06:45] <Fujitsu> I remember being very surprised to see an archive admin in these parts near the end of last cycle. It is, as LaserJock says, very good.
[06:46] <LaserJock> I try not to bug you too much though, I don't want to scare you away :-)
[06:46] <slangasek> heh
[06:46] <slangasek> hasn't been an issue so far :)
[06:46] <Hobbsee> it's got something to do with the shackles.
[06:46] <Fujitsu> slangasek: Hm, looks like IRC pings are OK as well.
[06:47] <Hobbsee> (to the channels)
[06:47] <Fujitsu> So we have a less frozen freeze for FinalFreeze.
[06:47] <LaserJock> I do find that bug reports are not very great for release approvals
[06:47] <LaserJock> I think we need to minimize "queue hopping"
[06:47] <slangasek> Fujitsu: "less frozen" because IRC pings are allowed?
[06:47] <Fujitsu> slangasek: Yes. FFes couldn't be granted except by bugs and waiting.
[06:47] <slangasek> oh
[06:48] <slangasek> well, hmm; I guess I've assumed that if there are new features, the FFe proces still applies
[06:48] <slangasek> ICBW
[06:48] <LaserJock> hmm
[06:48] <LaserJock> it would be cool if we could have a Universe unaccepted queue
[06:48] <slangasek> and others may not have read the motu-release announcement that way
[06:48] <slangasek> LaserJock: yes, yes it would
[06:48] <slangasek> :)
[06:48] <Fujitsu> LaserJock: It's coming.
[06:48] <Fujitsu> LP 1.2.4
[06:48] <LaserJock> and we could do a "upload then ask"
[06:48] <LaserJock> Fujitsu: "to be started" in 1.2.4 as far as I know ;-)
[06:49] <Hobbsee> LaserJock: don't dream about it.  it's infuriating.
[06:49] <slangasek> could do that already - you just need an archive admin to do the button pushing
[06:49] <LaserJock> Hobbsee: it's happening, just how fast is the question
[06:49] <Hobbsee> LaserJock: it sends you back to the new queue, after you accept from unapproved, so then you have to click back, and wait for another page load.
[06:49] <Fujitsu> LaserJock: So targets are targets for when to start? How smart of the LP people. So they don't keep missing deadlines.
[06:49] <Fujitsu> LaserJock: It's not the question. `Not very'
[06:49] <Hobbsee> LaserJock: and after doing it a few times in a row, let me tell you, it is quite frustrating.
[06:50] <LaserJock> sure, but in general we're getting there
[06:50] <Hobbsee> unfortunately, not annoying enough for me to have written a greasemonkey thing to fix it.
[06:50] <LaserJock> anyway, what I was gonna say was then we could have MOTU Release handle it
[06:50] <LaserJock> so we could do an "upload then ask" kind of thing
[06:51] <LaserJock> rather than "file bug and wait"
[06:51] <LaserJock> without making more work for slangasek, et al.
[06:52] <LaserJock> I really dislike having bugs having to go through multiple queues
[06:52]  * slangasek nods
[06:52] <LaserJock> it's confusing to everybody and you end up waiting a lot 'cause everybody is busy
[06:53] <dholbach> good morning
[06:53] <slangasek> well, at least the current freeze process makes it possible to distribute the workload among ubuntu-archive
[06:53]  * slangasek waves to dholbach 
[06:53] <LaserJock> I've had a few instances of "oh, I didn't know it had to be in *that* queue, I've been waiting for a couple weeks"
[06:53] <slangasek> instead of requiring ubuntu-release to do all the unapproved processing for universe, or such
[06:53] <Hobbsee> LaserJock: how would you do diffs, etc?  afaik, launchpad doesn't do diffs-against-previous yet?
[06:54] <LaserJock> Hobbsee: well, I wouldn't
[06:54] <Fujitsu> It is meant to do so RSN, though it was targetted to several months ago initially.
[06:54] <dholbach> hi slangasek
[06:54] <Hobbsee> LaserJock: right
[06:54] <LaserJock> I mean, the whole idea is "if you're sure upload, if not file the bug"
[06:55] <Fujitsu> LaserJock: It would help if our all our queues didn't involve horrible abuses of Malone.
[06:55] <Fujitsu> s/our //
[06:55] <LaserJock> Fujitsu: so very true
[06:55] <LaserJock> honestly, what we really need is to not use a bug tracker for non-bugs :-)
[06:56] <Fujitsu> (aka. bug #179857)
[06:56] <LaserJock> maybe something like an task tracker that can be linked to bug reports
[06:57] <Hobbsee> LaserJock: ahhh, i see.
[06:57] <Fujitsu> It's not just us that need sponsorship (and other process) tracking. I'm sure there's a way LP could help.
[07:00] <LaserJock> well, I would honestly like to sit down and work out all our tasks as developers
[07:00] <LaserJock> and figure out how the "should" be done
[07:00] <LaserJock> and thing figure out what we need from LP, uploaders, policies, triagers, etc. to do it
[07:00] <LaserJock> *then
[07:01] <LaserJock> it can be quite a muddled mess, for me at least
[07:02] <LaserJock> I think a cheatsheet would be good though
[07:02] <LaserJock> I think consistency is more an issue than our actual policies a lot of times
[07:02] <warp10> Good morning
[07:03] <Fujitsu> Some of our current processes are very wrong because of LP. Like backports. Backports should be handled by setting the pocket of a release targetting to backports, not filing a bug against <release>-backports. Security tasks should be handled with a security pocket target release (and approvable by a different team to -updates). It's a mess.
[07:03] <LaserJock> *I* have to remember that darn "close from changelog" bit, I can't for the life of me get that habit
[07:04] <LaserJock> Fujitsu: yeah
[07:04] <LaserJock> patch handling as well
[07:04] <awmcclain> If I'm creating a new ubuntu package (or really, repackaging a debian package for ubuntu), are there guidelines for installation? Installing into /etc/foo, etc?
[07:04] <LaserJock> we keep running into issues there
[07:05] <LaserJock> awmcclain: as long as it conforms to the Debian Policy it should be pretty much good
[07:05] <Hobbsee> slangasek: got any ideas for a really good, stiff drink?
[07:07] <Fujitsu> Oh yeah, and not having to track the status of every CVE in every release in two places would be nice.
[07:07] <slangasek> Hobbsee: 12-year Glenfiddich on the rocks? :)
[07:08] <Hobbsee> slangasek: hmmm.  i do have to go to work, too
[07:08] <slangasek> oh, well, perhaps that puts an upper limit on "stiff"
[07:08] <LaserJock> I was gonna say
[07:08] <StevenK> To 'nothing'
[07:08] <LaserJock> isn't that sort of an oxymoron?
[07:09] <Hobbsee> heh
[07:09] <Hobbsee> well, people have been known to turn up to work rather tipsy.
[07:11] <awmcclain> LaserJock: One thing I'm confused about is where to install the binary and the sample conf files. I understand that the active conf files should live in /etc, but what about the other things? Are there any standards?
[07:11] <Fujitsu> awmcclain: Why are you repackaging a Debian package?
[07:12] <slangasek> awmcclain: sample conf files -> /usr/share/doc/<package>/examples; as opposed to templates for config files that are used by the maintainer scripts, which should be in /usr/share/<package> instead; covered by Debian policy
[07:12] <awmcclain> Fujitsu: Becuase perlbal 1.70's debian packaging has the wrong dependencies so I'm updating the package. I'm also not thrilled with where it's installed.
[07:13] <awmcclain> slangasek: Ah, thank you. I couldn't find it in the policy manual.
[07:13] <Fujitsu> Why not just change the dependencies?
[07:13] <Fujitsu> Rather than changing other things?
[07:13] <Fujitsu> Minimal diff is good. Anything else gets people annoyed.
[07:13] <slangasek> awmcclain: Policy 12.6; the keyword is "examples" rather than "samples", so. :)
[07:14] <awmcclain> fujitsu: It's for my own use, thank you. And I already have the blessings of the perlbal list.
[07:14] <slangasek> what is perlbal? I don't see any Debian package of that name.
[07:14] <awmcclain> slangasek: Ah! I see. I wasn't considering it "documentation". That makes more sense.
[07:15] <Fujitsu> Ah, so you're not making an Ubuntu package, but a Debian-style package for your own use?
[07:15] <awmcclain> slangasek: Exactly! Perlbal is the perl-based load balancer used by LiveJournal, Pownce, among many others. It has abysmal package support -- just an old /debian folder from a year ago checked into svn
[07:16] <slangasek> ah, heh
[07:16] <awmcclain> Fujitsu: Correct! This is not official.
[07:16] <awmcclain> Fujitsu: (I wouldn't be so presumptuous). :)
[07:17] <awmcclain> Fujitsu: Part of the feeling I got from the existing installation was that the directories it installed to weren't quite the same as ubuntu standards, hence my questions here.
[07:17] <Fujitsu> I see. That makes more sense.
[07:17] <awmcclain> I'm trying to get a feel if there are things you do "differently" on ubuntu rather than debian
[07:18] <awmcclain> Plus, I want to learn more about building packages
[07:18] <awmcclain> I've already had to build a lighttpd 1.5.0 package for myself before it was (or is it) included in heron
[07:18] <Fujitsu> We take the vast majority of packages from Debian.
[07:18] <Fujitsu> So we can't really do much differently without having to package 20000 things ourselves.
[07:19] <awmcclain> Another question... since this is a very "unnofficial" build, it'd be more appropriate to version as 1.70-1 rather than 1.70-1ubuntu1, correct?
[07:19] <Fujitsu> -0, even
[07:19] <awmcclain> Ah.
[07:19] <awmcclain> Ok.
[07:19] <Fujitsu> -1 would be for the first Debian version.
[07:19] <awmcclain> Even better. ;)
[07:19] <awmcclain> Ah, since there isn't one.... gotcah
[07:20] <awmcclain> Are examples only installed by the foo-doc package?
[07:21] <awmcclain> I'm confused by the grouping of examples under "documentation"
[07:22] <awmcclain> slangasek: And just to be clear, "templates" (/usr/shar/<package>) would refer to a file that you would use to _create_ a conf file in /etc, perhaps during installation?
[07:23] <slangasek> awmcclain: yes, exactly
[07:23] <slangasek> awmcclain: as far as "foo-doc", not every source package creates a separate binary package for the documentation
[07:23] <awmcclain> slangasek: My existing template has a split for -doc.
[07:25] <slangasek> ok
[07:25] <slangasek> you're not obligated to put the examples in the -doc package if that's not where you think they belong
[07:27] <awmcclain> slangasek: And I'm not finding anything in the policy manual about _location_ of the binary file for a daemon (i really apologize if i'm missing it). I know packages like lighttpd and apache install in /usr/sbin/, is that correct?
[07:27] <\sh> moins
[07:27] <slangasek> awmcclain: Debian policy refers to the FHS for this; a copy of the FHS is included in the debian-policy package
[07:28] <awmcclain> slangasek: Ah! That's why i couldn't find it in my distro. Thank you!
[07:45] <awmcclain> Thank you all very much for the help.
[07:46] <LaserJock> alright, I gotta head to bed
[07:46] <LaserJock> slangasek: thanks so much for the discussion this evening, it's been helpful
[07:47] <slangasek> LaserJock: my pleasure; g'night :)
[07:57] <Fujitsu> Any motu-release people around to let me upload http://pastebin.com/f1d819686?
[07:57] <TheMuso> anybody seen this error before? http://launchpadlibrarian.net/13350746/buildlog_ubuntu-hardy-i386.csound_1%3A5.08.0.dfsg2-1ubuntu1_FAILEDTOBUILD.txt.gz
[07:58] <TheMuso> Fujitsu: looking
[07:58] <Fujitsu> TheMuso: You're missing a Package or Architecture line in debian/control.
[07:58] <Fujitsu> TheMuso: Thanks.
[07:59] <TheMuso> Fujitsu: Right thanks. Will have to track that one down.
[07:59] <dholbach> can somebody of the motu release team ACK http://launchpadlibrarian.net/13334232/glipper_1.0-1ubuntu1.debdiff ?
[07:59] <dholbach> (bug 193256)
[07:59] <ubotu> Launchpad bug 193256 in glipper "glipper background is not transparent" [Low,Confirmed] https://launchpad.net/bugs/193256
[07:59] <TheMuso> Fujitsu: Why does this need MOTU release?
[08:00] <Fujitsu> TheMuso: FinalFreeze is in effect, isn't it?
[08:01] <TheMuso> Fujitsu: Hang on, let me read the mail again... *sigh*
[08:01] <slangasek> wait, what?  missing Package or Architecture line, how the heck did this package build in Debian?
[08:02] <Fujitsu> slangasek: Presumably it didn't.
[08:02] <slangasek> but it did
[08:02] <TheMuso> More to the point, how did I get it built locally?
[08:02] <superm1> someone uploaded prebuilt binaries perhaps in debian?
[08:02] <TheMuso> superm1: But it would FTBFs on other arches in that case.
[08:02] <Fujitsu> TheMuso: Does it regenerate control automagically?
[08:03] <superm1> unless they had a whole slew of arches locally to add to .changes :)
[08:03] <slangasek> superm1: on amd64, hppa, i386, and mipsel?:)
[08:03] <superm1> yeah probably fairly unlikely...
[08:03] <TheMuso> Fujitsu: in that case, go for the security update.
[08:04] <Fujitsu> TheMuso: Thanks.
[08:04] <TheMuso> Fujitsu: re control, checking.
[08:06] <TheMuso> hrm. The only reason why things might bork is for one package, there is no space between Architecture: and any...
[08:06] <TheMuso> I'm going to have to play with this in a PPA... But thats for later.
[08:06] <Fujitsu> Hm. I forget if that's legal.
[08:07] <TheMuso> dholbach: looking
[08:07] <dholbach> TheMuso: thanks
[08:07] <Fujitsu> slangasek: Oh Debian god, does one need a space after the colon in a control file?
[08:08] <TheMuso> dholbach: go for it.
[08:09] <\sh> Fujitsu, after I read the dak source of parsing control and dsc files...I think it needs a \s ;)
[08:10] <\sh> add _changes files to that list too
[08:10] <Fujitsu> I'd hope they all used a similar parser.
[08:10] <\sh> Fujitsu, I think dak source is reference implementation and I trust elmo on this ;)
[08:11] <Fujitsu> As do I.
[08:11] <Fujitsu> The question now is why it didn't build on the buildds, but did build everywhere else.
[08:12] <slangasek> heh, I've certainly never tried creating a debian/control without a space after the :
[08:12] <\sh> Fujitsu, which package?
[08:12] <Fujitsu> sbuild uses the dpkg-* inside the chroot, doesn't it?
[08:12] <slangasek> it's "pseudo-rfc822", which implies a space :)
[08:12] <Fujitsu> \sh: TheMuso's csound
[08:12]  * TheMuso will look at it later, with trying a PPA upload or two to get it resolved.
[08:15] <\sh> whatever alternate means
[08:15] <Fujitsu> \sh: In which context? The error message?
[08:16] <\sh> Fujitsu, yepp
[08:16] <Fujitsu> It means that they don't follow the sequence Package-Architecture-Package-Architecture-Package-[...]
[08:17] <TheMuso> Anyway, I've uploaded it to my PPA and will see what eventuates with the space where it should be.
[08:17] <TheMuso> And on that note, I'm outa here for a while.
[09:48] <agentsoul> Hello, I'm working with hardy, unfortunenatly it comes with an old unuseable (the numerical integration isn't working) version of qtiplot 0.9.3 rc2. The stable and fixed version 0.9.4 is released but only available as source. What is the right way and who is to ask to let the new version slip into hardy? I will write another short msg why this upgrade is needed.
[09:50] <murrayc> agentsoul: You need to file a bug in launchpad, at least.
[09:51] <awmcclain> Say the ubuntu package I'm building has a perl module requirement (for building). Could I use a package from http://debian.pkgs.cpan.org/?
[09:51] <agentsoul> First I could build 0.9.4 by my own but for sure I'm not the only one using the program. the problem is that the version coming with hardy is unuseable. I don't write that to emphasis my question. Numerical integration is a basic operation in a plot program. It's a little bit like if you can't change colors in GIMP or steer a car only left and not right. It's an essential function. Most of the users can not work with that version or wors
[09:51] <agentsoul> they will get wrong calculations and don't even realize.
[09:51] <agentsoul> murrayc: there is a bugreport in launchpad
[09:52] <agentsoul> murrayc: https://bugs.launchpad.net/ubuntu/+source/qtiplot/+bug/199234
[09:52] <james_w> awmcclain: the package needs to be in Ubuntu if you want to build against it.
[09:52] <ubotu> Launchpad bug 199234 in qtiplot "[Hardy] Integration produces nonsense results" [Undecided,New]
[09:53] <awmcclain> james_w: What if it's just a private ubuntu package, not-to-be-included in the universal repository?
[09:55] <james_w> awmcclain: then you can do whatever you like :-)
[09:56] <awmcclain> james_w: Ok, is the format for apt sources.list the same for a debian apt repo? Do I need to download the package and bundle it into my own repository?
[09:56] <james_w> I don't know how they provide their packages. I would recommend downloading it
[09:57] <awmcclain> james_w: Ok. Thank you@
[09:59] <beasty_> morning
[09:59] <agentsoul> murrayc: Is there anything else I can do?
[10:03] <beasty_> hmm
[10:04] <beasty_> i'm trying to rebuild a package with 'pbuilder' but it gives other depends than i used in my control file
[10:05] <beasty_> any clue for this ?
[10:10] <james_w> agentsoul: you would need to apply for a freeze exception to get it in at this point.
[10:10] <james_w> beasty_: sorry, can you explain what you mean?
[10:12] <agentsoul> james_w: who or where do I have to explain the problem to ask for such an exception?
[10:13] <james_w> agentsoul: you can find some information at https://wiki.ubuntu.com/FreezeExceptionProcess
[10:14] <james_w> basically you file a bug with the reasoning and subscribe "motu-release".
[10:18] <agentsoul> james_w: I chekced the subscribers of the bugreport MOTU Science is notified. Should I subscribe motu-release anyhow.
[10:20] <james_w> agentsoul: have you filed a new bug?
[10:21]  * Fujitsu appears at the mention of motuscience.
[10:22] <agentsoul> james_w: no, but the old report ( https://bugs.launchpad.net/ubuntu/+source/qtiplot/+bug/199234 ) describes the problem, I think.
[10:22] <ubotu> Launchpad bug 199234 in qtiplot "[Hardy] Integration produces nonsense results" [Undecided,New]
[10:22] <james_w> agentsoul: yes, but the process requires a new bug report, as your problem will still exist, even if the fix is not accepted in to Hardy.
[10:24] <agentsoul> james_w: OK I will write a new bug report and add motu-release and try to follow the steps of the FreezeExceptionProcess howto from the wiki.
[10:24] <mvo> hey! I would like to upload compiz 0.7.4 into the archive (I got a FFE for this). the configuration utilities are in universe for this, do I need a seperate FFE from the motu FFE team for this?
[10:25] <james_w> mvo: I think you would, yes.
[10:25] <Amaranth> d'oh
[10:26] <james_w> I haven't seen any of them around to confirm though.
[10:28] <Amaranth> mvo: does ccsm 0.7.2 break when used with libcompizconfig 0.7.4?
[10:29] <mvo> I don't think so, but I need to test
[10:29] <Amaranth> You could just put in a Breaks too :)
[10:30] <mvo> I think its just python-compizconfig (very few changes), ccsm and simple-ccsm (both hvae mostly fixes)
[10:31] <Amaranth> I know ccsm had a bit of churn
[10:31] <Fujitsu> IMO you should file universe-style FFes for each.
[10:31] <Amaranth> Crap, that's another day without a new compiz :/
[10:31] <colinl> hi, I'm trying to use my PPA and am having "State: Chroot problem" on every try... anything I should do to fix it?
[10:31] <Fujitsu> colinl: First upload?
[10:31] <colinl> yes
[10:31] <Fujitsu> (also, #launchpad is better)
[10:32] <Fujitsu> colinl: You uploaded less than 13 minutes ago?
[10:32] <colinl> ah, sorry
[10:32] <colinl> Fujitsu: yes
[10:32] <Fujitsu> colinl: Wait until 40 past this hour.
[10:32] <Fujitsu> Then retry it.
[10:32] <Fujitsu> It will work.
[10:32] <colinl> Fujitsu: ah, ok, thanks. this is a server-side problem?
[10:32] <Fujitsu> Correct.
[10:32] <colinl> OK, great, thanks :)
[10:32] <Fujitsu> All CHROOTWAITs are server problems.
[10:33] <colinl> ok :)
[10:40] <james_w> motu has been around since the start of Ubuntu hasn't it?
[10:40] <stani> pochu, POX_, ScottK: Nautilus extensions have changed in Hardy and Debian Unstable. Therefore I am preparing a patch for Phatch which is compatible both with Nautilus 2.22 and previous versions. (There was a post on the PAPT mailing list about it.) I hope it can still be included, otherwise nautilus-integration for Phatch is broken.
[10:43] <beasty_> is there a way to get the list off depends generated by a .deb file ?
[10:46] <dholbach> james_w: no, not entirely - I have #ubuntu-motu logs from since Thu Feb 17 12:22:12 2005 - it was a few weeks before that a group of ~5 community developers had formed - afair ogra came up with the MOTU name
[10:46] <stani> colinl: This is normal. Just patience.
[10:46] <dholbach> james_w: in any case it's been around for almost all the time of ubuntu :)
[10:47] <james_w> dholbach: thanks.
[10:48] <dholbach> it's a shame nobody wrote the "History of MOTU" book yet
[10:48] <james_w> beasty_: "dpkg -I .deb" should list them.
[10:49] <beasty_> ok
[10:50] <beasty_> i just applied some stuff on 'python-pexpect'
[10:50] <colinl> stani: yes, seen that. it works now :)
[10:52] <beasty_> and added it to my local repository
[10:52] <beasty_> how can i force apt-get to use the local repository ?
[10:56] <colinl> beasty_: the easiest way it to bump the version in your patched package's debian/changelog
[10:56] <colinl> *is
[11:00] <beasty_> hmm
[11:00] <beasty_> just added my changes to changelog
[11:00] <beasty_> rebuild it
[11:00] <beasty_> and it's installed now
[11:08] <\sh> hey Czessi
[11:09] <Czessi> morning \sh :)
[11:09] <\sh> Czessi, send me the ammount of € you need for pre-finance the LT flat :)
[11:12] <ogra> dholbach, james_w, the name came from mdz as a joke during the mataro confernce (where als MOTU was founded and the first process for becoming a MOTU was defined)
[11:12] <ogra> s/als/also/
[11:12] <Czessi> \sh: in week 17 i'll write a mail will further informations (flat, booth passes and much more)
[11:13] <\sh> Czessi, rock :) I finally got my holiday approved....
[11:14] <Czessi> \sh: kool, is carine coming too?
[11:14] <\sh> Czessi, hopefully..we don't know yet, she was actually for 4 weeks in cameroon now...so I don't know if she gets holidays in may..
[11:16] <Czessi> \sh: ok. i've rent the holliday flat for 7 people wirth an option for 10 people + 2 who can sleep in my flat.
[11:17] <\sh> Czessi, this should be more then enough :)
[11:17] <\sh> Czessi, at least, imho we need 3 places for the beer crates ;)
[11:23] <Czessi> \sh: 3 places for the beer crates?
[11:23] <\sh> Czessi, joking
[11:25] <Czessi> <= english dau ;)
[11:31] <Czessi> \sh: cold beer and some snacks are i available in the flat ... like the last year
[11:32] <\sh> When Carine is not coming, I'm trying to bring some camroonian food...or when she's actually coming, then I'll try to convince her, to cook some cameroonian food, eventually we can do this when we have a barbequeue or something like that...this time, I'll stay until the end of LT
[11:36] <Czessi> no bbq is planned, maybe we can have a bbq in the backyard from the flat
[11:37] <\sh> Czessi, let's plan one then :)
[11:38] <Czessi> yes, i'll ask the renter and when not, i'll search a bbq place
[11:41] <\sh> Czessi, we need sponsors ;)
[11:41] <YokoZar> What are you two plotting?
[11:42] <\sh> YokoZar, LinuxTag :)
[11:42] <\sh> YokoZar, food drink and a lot of ubuntu love  ;)
[11:42] <Czessi> \sh: yes, but i don't know where we can get a sponsor
[11:43] <\sh> Czessi, public call on planet, forums, etc.?
[11:44] <\sh> Czessi, you still have the paypal account?
[11:44] <\sh> for kubuntu-de?
[11:44] <crimsun> and most importantly, a method of accepting contributions.
[11:44] <\sh> good point
[11:45] <\sh> and a place where we can make the sponsors public
[11:45] <Czessi> \sh: yes, we have a paypal account for kubuntu-de but my blog is only in german at this time
[11:45] <\sh> Czessi, well, I'll can help with that :)
[11:45] <\sh> s/\'ll//
[11:46] <Czessi> \sh: http://www.kubuntu-de.org/pinnwand
[11:46] <\sh> or s/can// whatever
[11:48] <\sh> crimsun, are you going to UDS @Praque this year?
[11:55] <YokoZar> launchpad really should have a "not incomplete" bug filter
[12:55] <persia> MOTU Meeting in #ubuntu-meeting in 5 minutes
[13:48] <jdong> oh! oh! SCREW YOU TOO, Firefox!
[13:48] <jdong> you don't see ME closing down randomly whenever you need to tell me something!
[13:51] <tseliot> ﻿jdong: talking to firefox again? ;)
[13:51] <mok0> jdong: I can't even start FF
[13:52] <mok0> jdong: I get a dialog box that says it's already running
[13:52] <dholbach> regarding Mootbog usage: how do I end the vote afterwards?
[13:52] <mok0> jdong: (but not responding)
[13:55] <jdong> mok0: ouchies
[13:55] <dholbach> ok, got it, was [ENDVOTE]
[13:55] <mok0> jdong: it tells me to restart my computer! I refuse
[13:56] <mok0> jdong: I already have problems getting my graphics going using the newest kernels :-(
[13:57] <mok0> hardy is in pretty bad shape right now
[14:00] <stani> james_w or ember: are you there? I have some questions about python-nautilus 0.5.
[14:00] <jdong> mok0: that's rough... :(, Hardy seems to be going well for me on my two laptops though I'll only find out for sure tonight when I formally upgrade my primary lappy to Hardy
[14:00] <james_w> stani: yeah, I'm around, I don't know much about it though. Was I the last one to upload?
[14:02] <stani> james_w: pochu told me you did -ubuntu2 which is the latest.
[14:03] <james_w> stani: yeah
[14:03] <stani> james_w: python-nautilus 0.5 creates the folder ﻿/usr/lib/nautilus/extensions-2.0/python
[14:04] <stani> james_w: but in order to make a python extension to work you have to put in the non existing ﻿/usr/lib/nautilus/extensions-1.0/python folder
[14:04] <stani> james_w: nautilus 2.22 switched to the 2.0 extension api
[14:05] <james_w> ah, it still supports the 1.0 API?
[14:06] <stani> james_w: I think there must be a typo. It works with nautilus 2.22 (so I guess it works with the 2.0 api), but the location it requires is of the 1.0 api, not the 2.0 api
[14:07] <stani> james_w: I would think that all references to ﻿/usr/lib/nautilus/extensions-1.0/python are a typo and should be replaced by ﻿/usr/lib/nautilus/extensions-2.0/python
[14:07] <james_w> I don't understand the problem, sorry, python-nautilus doesn't work?
[14:08] <stani> it works if I place the extensions (= python scripts) in ﻿/usr/lib/nautilus/extensions-1.0/python, but it doesn't work when I place them in ﻿/usr/lib/nautilus/extensions-2.0/python
[14:09] <stani> james_w: python-nautilus 0.4 creates ﻿/usr/lib/nautilus/extensions-1.0/python, but python-nautilus 0.5 creates ﻿/usr/lib/nautilus/extensions-2.0/python
[14:11] <james_w> 0.5 moved to the new nautilus API.
[14:11] <james_w> if you place them in the 1.0 directory with nautilus 2.22 they work?
[14:11] <stani> indeed so why do scripts need to be in a deprecated path?
[14:11] <stani> yes than they work
[14:12] <stani> but this path does not exist, a user has to create it himself
[14:12] <james_w> I don't know, does it require that the script be changed to the new API?
[14:12] <nixternal> see you all on sunday! have a great weekend everyone!
[14:12] <dholbach> nixternal: you too
[14:13] <stani> I would think that all references to ﻿/usr/lib/nautilus/extensions-1.0/python should be replaced with ﻿/usr/lib/nautilus/extensions-2.0/python inside python-nautilus 0.5
[14:14] <stani> so that when I install my scripts in the 2.0 path it does work
[14:15] <stani> for example my application checks during installation which path exist (1.0 or 2.0) in order to install python extensions.
[14:15] <stani> now it detects 2.0 and not 1.0 which is correct
[14:15] <stani> it installs the extensions in 2.0 which does not work
[14:16] <james_w> stani: you're right:   nautilus_python_load_dir(module, NAUTILUS_LIBDIR "/nautilus/extensions-1.0/python");
[14:16] <stani> right now my setup.py copies the extensions to 1.0 anyway which is an ugly hack
[14:17] <stani> james_w: so this is a bug right? (otherwise all python extensions in 2.0 will not work on Hardy)
[14:18] <james_w> correct.
[14:18] <james_w> however, should we be supporting a transition?
[14:18] <james_w> phatch seems to be the only user of python-nautilus in the archive, so we can fix that.
[14:19] <james_w> but do we want to support users who have installed other extensions?
[14:20] <stani> well for user installed extensions it is not a problem
[14:21] <stani> they are installed in ~/.nautilus/python-extensions
[14:21] <stani> so they will continue working
[14:21] <james_w> yes, but users can install them system-wide as well.
[14:21] <siretart> persia: perhaps here so we don't interrupt dholbach
[14:21] <persia> siretart: Sure, although I'm interested in the results of that.
[14:22] <stani> but on a clear Hardy install there is no ﻿/usr/lib/nautilus/extensions-1.0 or ﻿/usr/lib/nautilus/extensions-1.0/python
[14:22] <persia> Essentially, lots of people complained about code-monkeys and nobody defended it.  I reverted it.  Do you think it needs more discussion?
[14:22] <stani> but only ﻿/usr/lib/nautilus/extensions-2.0/python
[14:22] <siretart> persia: it was not only the name 'code monkey', I feel on the mailing list the objection was that there seems to be a trend to use 'silly' names like 'code monkeys'
[14:23] <stani> james_w: so if users install it systemwide why would they start creating system directories themselves?
[14:23] <stani> james_w: or do you mean for system upgrades?
[14:23] <persia> siretart: True.  I think the best defense against that trend is vigilance.
[14:23] <james_w> stani: yes, this path existed in previous releases
[14:23] <stani> james_w: in that case provide at least a symlink
[14:24] <stani> symlink ﻿/usr/lib/nautilus/extensions-2.0/python to ﻿/usr/lib/nautilus/extensions-1.0/python
[14:24] <stani> otherwise you force applications to copy files incorrectly
[14:24] <stani> during setup
[14:24] <james_w> that's not great, it's quite a lot of code in the postinst.
[14:26] <stani> james_w: is it not possible to load from both 1.0 and 2.0?
[14:26] <james_w> stani: yes, it probably is, I'm asking if it should be done.
[14:27] <james_w> the other question is whether loading from both is guaranteed to work, as there has been an API change it may mean some things from the old location will not work any more.
[14:28] <stani> james_w: I thought Hardy is a LTS so why would you force the 1.0 which is deprecated from nautilus 2.22
[14:29] <stani> and why would python-nautilus create ﻿/usr/lib/nautilus/extensions-2.0/python if it is totally not functional
[14:29] <james_w> the latter was my mistake, I didn't test it with a system wide install
[14:29] <bddebian> Heya gang
[14:31] <james_w> hi bddebian
[14:31] <bddebian> Hi james_w
[14:32] <stani> james_w: I would vote for migrating the path to 2.0 (I think the chance for system wide python-nautilus extensions are small.)
[14:33] <stani> james_w: but it is your choice
[14:33] <stani> james_w: I just want to know what you will do with it as it has consequences for Phatch.
[14:34] <james_w> stani: could you provide a patch to python-nautilus?
[14:35] <stani> james_w: also by keeping the 1.0 path nautilus may try load incompatible extensions
[14:36] <stani> james_w: unfortunately I only know python and do not have a lot of packaging experience
[14:36] <LarstiQ> stani!
[14:37] <stani> james_w: I can try as it just is a find replace, but someone should review it
[14:37] <LarstiQ> stani: is your copacabana (if I got that right) proxy still available somewhere?
[14:37] <james_w> LarstiQ!
[14:37] <LarstiQ> james_w! :)
[14:37] <james_w> LarstiQ: how are you?
[14:37] <stani> LarstiQ: yes, at my home ;-)
[14:37] <james_w> stani: sure, I can review it. I can do it myself, I'm just doing 3 other things at the moment.
[14:38] <LarstiQ> james_w: okish. Currently looking for help on bug 120834
[14:38] <ubotu> Launchpad bug 120834 in mesa "intel gm965 freezes with 3d applications" [High,Confirmed] https://launchpad.net/bugs/120834
[14:38] <LarstiQ> stani: I'd love to come to Utrecht again if that is necessary ;)
[14:38] <stani> LarstiQ: haha, I live now in Amsterdam
[14:38] <LarstiQ> stani: doh! What happened to the boerderij?
[14:39] <stani> I was there temporarily as an artist residency
[14:39] <james_w> LarstiQ: ugh, nice bug.
[14:39] <stani> I only stayed there for three months
[14:40] <LarstiQ> stani: ah, I didn't catch on to that. I enjoyed the python-nl meeting there anyway :)
[14:40] <stani> yes, it was fun. Are you a motu?
[14:40] <LarstiQ> stani: nope
[14:41] <afflux> james_w: just curious, what's the issue with the nautilus extension?
[14:41] <afflux> I missed the start
[14:42] <james_w> afflux: I messed up the last upload somewhat
[14:42] <james_w> recent versions of nautilus use 2.0 extensions, I changed the python directory name, but not the code, which is confusing.
[14:42] <afflux> ah, okay
[14:43] <james_w> the question is whether we should transition the old location to the new one, or support both, or just not bother.
[14:44] <afflux> james_w: IIRC nautilus doesn't even look at the old location but only considers $(pkg-config --variable=extensiondir libnautilus-extension). I patched nautilus-actions lately to change the install directory to the pkg-config thing.
[14:45] <james_w> so, just having no transition would be ok?
[14:46] <afflux> I'm not a motu and not really a dev, but I think we should change the directory in the source and the packaging and check if it works. Maybe check what part of the api changed and whether we need to reflect those changes too.
[14:47] <stani> afflux: now nautilus looks for python extensions in the old 1.0 path
[14:47] <james_w> afflux: neither am I :-)
[14:48] <afflux> that doesn't sound very sane to me :) I think it rather causes confusion when a user sees multiple extension directories, especially since the old path is obsolete since the new release (2.20? 2.22? not sure).
[14:48] <james_w> afflux: I'm not sure how API changes would affect python though.
[14:48] <persia> Bah.  Anyone who can read code and test is entitled to an opinion :)
[14:48] <afflux> james_w: I think maybe the extension code itself needs to be updated
[14:48] <stani> well I got a mail from debian that I needed to update phatch otherwise it wouldn't work with nautilus 2.22
[14:49] <james_w> afflux: it does that:  nautilus_python_load_dir(module, NAUTILUS_LIBDIR "/nautilus/extensions-1.0/python");
[14:49] <stani> so I was quite surprised to find out that on Hardy it did work with nautilus2.22
[14:49] <james_w> which is wrong for the new API
[14:49] <stani> and which may load incompatible scripts (based on the 1.0 api)
[14:50] <afflux> yes
[14:52] <afflux> james_w: well, I think it should have another #define like NAUTILUS_EXTENSIONDIR which should be set by the configure script, guessed by the pkg-config command, but that sounds like a quite big upstream code change.
[14:52] <afflux> oh wait.
[14:53] <afflux> it's already defined, it's NAUTILUS_EXTENSION_DIR.
[14:53] <afflux> or, is it? there's something in configure.in.
[14:54] <stani> so than you would expect ﻿NAUTILUS_EXTENSION_DIR "/python"
[14:54] <afflux> yes
[14:54] <stani> which will refer to the 2.0 path
[14:54] <dholbach> persia: thanks for doing the minutes
[14:55] <pochu> err, I thought the meeting was in about 6 hours or so :(
[14:56] <persia> pochu: Nope.  12:00 this week.  Just ended.  Next week is 20:00.
[14:56] <pochu> anyway, it was so long I'd have missed half of it due to lunch...
[14:57]  * pochu waits for persia to send the minutes :)
[14:57] <persia> pochu: It will be 15-20 hours.  You might want to read the logs, if you want to know today.
[14:58] <pochu> persia: ok, thanks
[14:58] <afflux> stani: it should, but it configure currently does not export the variable to config.h
[14:59] <stani> afflux: That's a pitty.
[15:00] <Hobbsee> debian bug 473999
[15:00] <ubotu> Debian bug 473999 in bip "bip: bugs in the configuration file validation" [Normal,Fixed] http://bugs.debian.org/473999
[15:02] <stani> afflux and james_w: so what can we do about it?
[15:02] <afflux> stani: we could patch this away ;)
[15:04] <stani> afflux: great, can you do that?
[15:04] <afflux> looking
[15:04] <stani> pochu: I have sent you a part of the motu meeting
[15:04] <stani> pochu: by email
[15:05] <james_w> stani: I spoke to seb, and he said that we should just do the easy thing.
[15:06] <afflux> which means?
[15:06] <james_w> just load from the new directory
[15:07] <stani> ﻿so that requires a patch
[15:07] <afflux> okay, I'm looking at it now
[15:08] <stani> afflux: great, is it ok I file a bug on launchpad so I can follow progress?
[15:08] <afflux> I think so
[15:11] <mok0> Hobbsee: ping
[15:11] <Hobbsee> mok0: pong
[15:11] <mok0> Hobbsee: I need you to ack a fix I have of libpythonize0
[15:11] <Hobbsee> ScottK: permission to upload bip? (memory fix, config change fix)
[15:11] <mok0> Hobbsee: ScottK is away
[15:12] <Hobbsee> mok0: i know.  i need to test this first.
[15:12] <mok0> Hobbsee: I talked to ScottK about the fix before he left town
[15:12] <Hobbsee> oh, he's out of town
[15:13]  * Hobbsee could, theoretically, ack her own bug, then approve her own upload
[15:13] <mok0> Hobbsee: yes, and he will be away for a week
[15:13] <mok0> Hobbsee: you have time now?
[15:14] <mok0> Hobbsee: look at http://irclogs.ubuntu.com/2008/04/09/%23ubuntu-motu.html around 22:25
[15:16] <stani> afflux: Please use this bug report for your patch: Bug #215714
[15:16] <ubotu> Launchpad bug 215714 in nautilus-python "The path for python extensions should be reflect the 2.0 api" [Undecided,Confirmed] https://launchpad.net/bugs/215714
[15:18] <afflux> wah, what the
[15:18] <afflux> my firefox just diappeared, session recover does not work o.o
[15:20] <stani> afflux: did you recover already ;-)
[15:23] <afflux> stani: commented on the bug
[15:24] <stani> afflux: do you think you can make this in Hardy?
[15:26] <afflux> stani: I'm checking some things, if everything works the patch should be ready in the next few hours ;)
[15:26] <Hobbsee> mok0: i'm hoping to head to bed soon
[15:26] <mok0> Hobbsee: It'll only take a minute
[15:27] <stani> afflux: great, so I than I can test it with Phatch and if it works upload a patch for Phatch
[15:28] <mok0> Hobbsee: I tested the fix like ScottK suggested and it works
[15:28] <afflux> stani: in the meantime, what changes were needed for phath? Only path stuff or code logic, too?
[15:28] <stani> pochu: ^^^ (could you upload then phatch to ubuntu, not necessary for debian)
[15:28] <jdong> may I get MOTU release permission to upload a nosrcchange rebuild for bug 212855?
[15:28] <ubotu> Launchpad bug 212855 in nspluginwrapper "npviewer.bin crashed with SIGSEGV in g_type_check_instance_cast()" [High,Confirmed] https://launchpad.net/bugs/212855
[15:29] <mok0> Hobbsee: as you can see from the discussion in Bug #138189 the problem has been around for a while
[15:29] <ubotu> Launchpad bug 138189 in pykdeextensions "application tries to dlopen /usr/lib/libpython2.5.so (only found in the -dev package) " [Medium,Confirmed] https://launchpad.net/bugs/138189
[15:29] <stani> afflux: I am the author of phatch, so don't worry about it. I am in fact ready already as I expected python-nautilus to work from the 2.0 path.
[15:29] <mok0> Hobbsee: I would like you to ack it and I can upload
[15:29] <afflux> I'll read the changes to the api, because the package may need further adjustments for this
[15:30] <jdong> mok0: hey! I supplied a bugno first! ;-)
[15:30] <pochu> stani: now, or when python-nautilus is fixed?
[15:30] <stani> afflux: then I run into this problem, and I thought it would be better to solve it at the root
[15:30] <mok0> jdong: ubotu fears me
[15:30] <stani> pochu: when python-nautilus is fixed
[15:31] <stani> pochu: just that you know it will happen (did you get my email?)
[15:32] <stani> afflux: are you a motu?
[15:33] <afflux> no
[15:33] <afflux> bugcontrol only ;)
[15:33] <stani> afflux: do you know someone to upload it?
[15:33] <afflux> no, I tend to subscribe ubuntu-universe-sponsors and wait ;)
[15:33] <afflux> or motu-release if in FFe
[15:34] <pochu> stani: the meeting logs? yes, but I'm reading them in #ubuntu-meeting, as I was in the channel
[15:34] <stani> ok
[15:35] <pochu> stani: does phatch need a patch? or is a no-changes-upload enough (as you said it autodetects the extensions path)
[15:36] <james_w> afflux: I have a sponsor for it if you get the FFe
[15:37] <stani> pochu: in the current version it does not. but I have here a patch ready in which it does. The patch is not necessary if the patch of afflux does not get through. As I expect that his patch will be accepted, I can upload the patch for phatch already as it is backwards compatible.
[15:37] <stani> pochu: can you help with the FFe of python-nautilus?
[15:37] <jdong> can we call this a SuperFreeze? It sounds cool :)
[15:37] <jdong> oh oh! Freeze 2.0!
[15:38] <mok0> jdong: the next will be carbonization
[15:39] <stani> jdong: the freeze of automatix on april 1rst was already Freeze 3.0
[15:39]  * Hobbsee gives stani the boot
[15:39] <jdong> Hobbsee: now that you twitched, do you handle Universe freeze exceptions too? :)
[15:40] <Hobbsee> jdong: depends what time it is, how hard they are, and whether i feel like giving a damn or not :)
[15:40] <jdong> Hobbsee: bug 212855, trivial (no source change rebuild), high impact on flash for all amd64 users
[15:40] <ubotu> Launchpad bug 212855 in nspluginwrapper "npviewer.bin crashed with SIGSEGV in g_type_check_instance_cast()" [High,Confirmed] https://launchpad.net/bugs/212855
[15:41] <jdong> regression from bet
[15:41] <jdong> a
[15:42] <Hobbsee> jdong: please do it.
[15:43] <Hobbsee> jdong: and there are too many johns on that bug.
[15:43] <jdong> Hobbsee: thanks :D
[15:43] <Hobbsee> jdong: if you're quick, i'll even send it thru teh queue
[15:44] <jdong> Hobbsee: push push push!
[15:47] <afflux> stani: updating the pbuilder and doing some testing now, I think I did the important changes
[15:47]  * Hobbsee hits the big green button, and gets an oops.  What an anticlimax.
[15:48] <stani> afflux: great!
[15:48] <jdong> Hobbsee: lovely :)
[15:49] <pochu> james_w, stani: no FFe needed, that's a bug fix AFAICS. We would need motu-release approval though... could you file a bug report with a debdiff attached and the rationale? I think we will get approval for it
[15:49] <pochu> jdong: lol at SuperFreeze :-)
[15:50] <pochu> afflux: ^-- the FFe stuff was for you rather than james_w...
[15:51] <jdong> whee my N800 arrived! Just have to go pick it up at the front desk
[15:51] <stani> afflux: could you do a test: install phatch and move manually the phatch extensions from ﻿﻿/usr/lib/nautilus/extensions-1.0/python to ﻿﻿/usr/lib/nautilus/extensions-2.0/python, restart nautilus and see if it works if you right click on a jpeg file
[15:51] <afflux> stani: will do that in a minute
[15:51] <stani> afflux: great
[15:52] <afflux> pochu: alright, but isn't that still a FinalFreezeexception?
[15:52] <pochu> ah, I was thinking on FeatureFreezeException...
[15:52] <afflux> that's what I did first, too ;)
[15:56] <sommer> sweet
[15:56] <sommer> woops wrong console
[16:11] <afflux> anyone familiar with autoconf/automake/autowhatever packages? I had to change a configure.in script, and I don't know what I need to do additionally to make this build cleanly in the pbuilder
[16:12] <afflux> I changed the configure.in in a cdbs simple-patchsys patch
[16:13] <Laney> afflux: AFAIK, you need to run autoconf
[16:13] <afflux> and get the changes in the patch too?
[16:14] <afflux> or in a seperate patch?
[16:15] <mok0> ScottK: you there?
[16:15] <azeem> slangasek: I'll try to deal with the rest of opensync tonight, am travelling now (I tried to port opensync-plugin-google-calendar to python-4suite-xml, but to no avail so far); thanks for dealing with it so far
[16:15] <geser> afflux: how big are the changes you did?
[16:16] <afflux> geser: added one AC_DEFINE_UNQUOTED line
[16:16] <geser> afflux: if the changes are small I usually patch configure and configure.in (in case someone wants to run autoreconf)
[16:16] <afflux> the build fails without
[16:17] <afflux> err, I mean the build fails without running autoreconf
[16:17] <geser> I'd propose to run autoreconf and put the changes from configure into a new patch (so you don't need rerun autoreconf during build)
[16:18] <afflux> so, I need to cdbs-edit-patch, do my changes, exit, cdbs-edit-patch a higher number, run autoreconf save those patches, correct?
[16:19] <geser> yes, so you have your changes and the changes from autoreconf into seperate files and can easily recreate it if configure changes in future (and the configure patch doesn't apply anymore)
[16:20] <afflux> ah, okay
[16:20] <geser> the alternative would be to run autoreconf during build (but it's not liked by all people)
[16:51] <slangasek> azeem: oh, well, I'm already working on merging some of the plugins myself :)
[17:54] <crimsun> \sh: no.
[17:54] <emgent> hi crimsun
[17:55] <crimsun> hi emgent
[18:10] <RainCT> siretart: ping
[18:12] <afflux> I've an upstream configure.in script using a AM_CHECK_PYTHON_HEADERS macro. However, my automake installation can't find it. What do I need to make aclocal add this?
[18:16] <siretart> RainCT: pong
[18:16] <RainCT> siretart: InternalError: could not connect to server: No such file or directory
[18:16] <RainCT> Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
[18:16] <RainCT> siretart: any idea how to fix this?
[18:18] <siretart> sorry, no.
[18:20] <nityad> Is packages.ubuntu.com down?
[18:21] <RainCT> nityad: seems so
[18:24] <afflux> upstream forgot to export the m4 directory in it's release tarballs, but I need it for fixing a bug. is it okay to just check it out from the svn and add it to my patch?
[18:25] <james_w> afflux: is this for python-nautilus?
[18:25] <afflux> yes
[18:25] <james_w> is the problem fixed upstream?
[18:25] <afflux> you mean the problem I'm fixing at the moment? No, not yet.
[18:26] <afflux> I'll forward this bug when I checked whether my patch is valid
[18:26] <afflux> but I can't without adding the directory ;)
[18:26] <james_w> for the package I think you should just change that line in the source.
[18:26] <james_w> when you report the bug upstream you can point them to the configure part, or provide the whole patch there if you like.
[18:26] <afflux> james_w: you mean hardcode the new extension dir?
[18:27] <james_w> this is turning in to a very invasive change for a one-line problem.
[18:27] <james_w> afflux: yes
[18:27] <afflux> okay
[18:27] <james_w> you can write a note in the changelog that it is not the right way to fix it, but that it will so for hardy
[18:29] <afflux> okay
[18:36] <RainCT> siretart: got it working, had to change the port in the config file for 8.3 to the same one 8.2 was using
[19:09] <afflux> stani, james_w: added a debdiff to bug 215714, subscribed motu-release.
[19:09] <ubotu> Launchpad bug 215714 in nautilus-python "The path for python extensions should be reflect the 2.0 api" [Medium,Confirmed] https://launchpad.net/bugs/215714
[19:21] <afflux> stani, james_w: checked the "better" fix with non-hardcoded paths and it's working, *if* I add some files from their SVN repo. I'll forward this patch to them tomorrow. Good night :)
[19:24] <rzr> is http://packages.ubuntu.com down ?
[19:45] <stani> afflux: thanks
[19:55] <smagoun> is there a way to make dh_installchangelogs (called via debhelper.mk) *exclude* debian/changelog from a package? I have a source package that generates a number of binary packages, one for each of my customers. I don't want the source pkg's changelog in the binary packages since it has proprietary info in it.
[19:57] <slangasek> I think you can have a debian/${binary-package}.changelog that dh_installchangelogs will install instead
[19:57] <slangasek> every binary package is supposed to have a changelog, though, and that's the purpose of dh_installchangelogs, so there's no way to tell it not to do its job
[19:59] <smagoun> slangasek: thanks. The docs for CDBS implied that you can install stuff in addition to the debian/changelog rather than instead of it, haven't tried it though. I'll give it a shot.
[20:00] <slangasek> smagoun: hmm, docs for debhelper are what you really want here; and it's a generic feature of debhelper that if there's a debian/<package>.<file>, it will use that in preference to debian/<file>
[20:09] <smagoun> slangasek: that worked, thanks! (but now I have to maintain a changelog for each binary package which is not what I want - should be easy to create a dummy CL with dpkg-parsechangelog+dch)
[20:13] <slangasek> smagoun: right, that sounds like it would work :)
[20:45] <sistpoty> hi folks
[20:49] <mok0> sistpoty: ping
[20:49] <sistpoty> mok0: pong
[20:50] <mok0> sistpoty: I need a 2nd ack on bug 195772
[20:50] <ubotu> Launchpad bug 195772 in matplotlib "please upgrade python-matplotlib to version later than 0.90.1" [Wishlist,Confirmed] https://launchpad.net/bugs/195772
[20:50]  * sistpoty looks
[20:53] <awmcclain> Hi all. I'm building an Ubuntu package for perlbal (initially not for distribution to universal or anything). It currently requires libio-aio-perl, which is no longer (or never was) in the Ubuntu repository. Is it better to 1) massage my sources.list to download libio-aio-perl from http://debian.pkgs.cpan.org/, or 2) Download the perl module myself and build the ubuntu debian package for libio-aio-perl myself?
[20:56] <sistpoty> awmcclain: is it in debian/unstable already? if so, then I using that (or rather a rebuild) would seem like the best choice
[20:58] <awmcclain> sistpoty: Ah, good point. Is there a doc for using the debian repos as a source for ubuntu somewhere?
[20:59] <sistpoty> awmcclain: no, and actually you shouldn't use them (it's not guaranteed that these are binary compatible)... so you'll really only want to grab the source and do a local rebuild
[20:59] <awmcclain> sistpoty: Great. That was my hunch but I wanted to make sure I wasn't making more work for myself.
[20:59] <awmcclain> Thank you!
[20:59] <sistpoty> np
[21:03] <sistpoty> awmcclain: side note: for perl packages, it should indeed be safe right now to use debian packages on hardy (perl doesn't get compiled)... however this might change in a few days, as soon as the new perl version enters unstable
[21:04] <awmcclain> (I'm also targeting for gutsy, so I appreciate the warning)
[21:06] <sistpoty> mok0: do you have a diff of the debian directory available somewhere? (pastebin is ok for me)
[21:10] <sistpoty> asac: just looking at bug 213827.. imo you could have just ack'd that as FF liason for motu-release ;)
[21:10] <ubotu> Launchpad bug 213827 in flashplugin-nonfree "typo in prerm file breaks failed-upgrade processing" [High,Fix committed] https://launchpad.net/bugs/213827
[21:17] <asac> sistpoty: yes i considered this but wasn't sure
[21:20] <mok0> sispoty: just came back... let me find that diff
[21:25] <mok0> sispoty: the diff is huge
[21:27] <mok0> sistpoty: ... or did you only want debian/ ?
[21:27] <sistpoty> sistpoty: only debian actually
[21:27] <sistpoty> erm.. mok0: even
[21:28] <mok0> http://pastebin.com/f7694b212
[21:33] <sistpoty> asac: funny, I get an assertion error with FF3 (while upgrading while trying to look at mok0's diff)
[21:38] <sebner> mok0: please upload rrootage :)
[21:38] <mok0> sebner: you got that bullet thing uploaded?
[21:39] <sebner> mok0: debwait ;)
[21:39] <sebner> mok0: I testbuilded it. all is fine
[21:39] <mok0> sebner: I gotta get acks first
[21:40] <sebner> sistpoty: ping
[21:40] <sistpoty> sebner: pong
[21:40] <sebner> sistpoty: please ACK. bug #212766 . hi btw :)
[21:40] <mok0> sebner: sispoty is looking at another package for me
[21:40] <ubotu> Launchpad bug 212766 in rrootage "Merge rrootage 0.23a-7 from Debian(Unstable)" [Wishlist,In progress] https://launchpad.net/bugs/212766
[21:41] <sebner> mok0: he has multitasking abilities :P
[21:41] <sistpoty> mok0: just looked over it (now with the ugpraded FF3...) looks like debian/changelog doesn't really match the diff. also I guess I really would like Fujitsu to give an ACK/REJ instead of me
[21:42] <mok0> sistpoty: ok, I'll ask him
[21:42] <sistpoty> mok0: thanks... I'll subscribe him to the bug
[22:09] <asac> sistpoty: while upgrading? was xul replaced underneath?
[22:09] <sistpoty> asac: need to check the logs, but I guess that may well be
[22:10] <sistpoty> asac: nope, doesn't look like it from /var/log/dpkg.log: 2008-04-03 22:36:22 install libxul-common <keine> 1.8.1.13+nobinonly-0ubuntu1
[22:11] <sistpoty> (first match to /xul)
[22:11] <asac> sistpoty: what kind of assertion? "just" glib?
[22:11] <asac> only assertion? or just crash?
[22:11] <asac> flash definitly dumps glib assertions
[22:11] <sistpoty> asac: assertion shown in window... give me a sec, I have a screenshot
[22:11] <sistpoty> (I don't have flash installed :P)
[22:11] <asac> ah
[22:12] <sistpoty> asac: http://www.potyra.de/ff3.assert.errror.png
[22:13] <sistpoty> (but it's gone now after the upgrade :))
[22:14] <asac> could you reproduce before?
[22:14] <asac> what did you do to get that?
[22:14] <sistpoty> asac: no, it only happened *during* the upgrade, so no...
[22:16] <sistpoty> asac: well, I did an apt-get update && apt-get dist-upgrade... so I assume that FF3 opened some files on demand, which might have not been there during the upgrade
[22:16] <sistpoty> (so I wouldn't give that too much priority actually)
[22:17] <asac> strange anyway
[22:17] <asac> maybe cairo update
[22:17] <asac> butunlikely
[22:20] <sistpoty> sebner: ack'd
[22:22] <sebner> sistpoty: thx :D
[22:23] <sebner> sistpoty: previous version: - Add libboost-dev to build-depends (fixes FTBFS)
[22:24] <sistpoty> sebner: previous version doesn't mean, that it still applies to the current version
[22:25] <sebner> sistpoty: that's clear. just wanted to answer your question ^^
[22:25] <sistpoty> sebner: heh, but also the question is really: why was this needed in the first place (as in where did ubuntu diverge from debian) that much... but it's really just a side-note ;)
[22:30] <sebner> sistpoty: fix was introduced because of this. http://pastebin.com/m5b87f1ed
[22:35] <sebner> sistpoty: I'm a dork -.-
[22:35] <sistpoty> heh
[22:35] <xtknight> so we're frozen and there's a fix for Bug 215027.  what do i do?
[22:35] <ubotu> Launchpad bug 215027 in jockey "jockey-gtk crashed with AttributeError: 'tuple' object has no attribute 'getSections'" [Undecided,Confirmed] https://launchpad.net/bugs/215027
[22:35] <slangasek> azeem: fyi, libopensync-plugin-google-calendar doesn't build out-of-the-box for me, because the configure script in the source package isn't up-to-date wrt the automake macros
[22:35] <sebner> sistpoty: It's a sync. Debian solved the problem in another way. Added libboost-dev as a dependency for libbulletml-dev.
[22:36] <xtknight> !info jockey hardy
[22:36] <ubotu> Package jockey does not exist in hardy
[22:36] <xtknight> !info jockey-gtk hardy
[22:36] <ubotu> jockey-gtk (source: jockey): GNOME user interface and desktop integration for driver management. In component main, is optional. Version 0.3.3-0ubuntu7 (hardy), package size 6 kB, installed size 96 kB
[22:36] <azeem> slangasek: weird, the PPA I uploaded this week built fine AFAICT
[22:37] <sistpoty> xtknight: you'll need an ack from ubuntu-release (maybe slangasek might want to take a look :P)(
[22:37] <xtknight> ah joy "0-
[22:37] <slangasek> azeem: oh, this is a merge against 0.22-4 rather than 0.22-5, is that the difference?
[22:37] <xtknight> :)
[22:38] <xtknight> critical fix imo, hardware drivers dialog is broken for everybody
[22:38] <azeem> slangasek: there's a problem with python at runtime
[22:38] <slangasek> sistpoty: unless it needs a feature freeze exception, no, I want core-dev to use their best judgement, upload, and let it be reviewed in the queue ;)
[22:38] <slangasek> azeem: python-xml? :)
[22:38] <azeem> depending on how you handled the merge
[22:38] <azeem> doko's diff wasn't enough
[22:38] <slangasek> oh?
[22:38] <sebner> sistpoty: I'll change it to a sync. ACK is still valid, right :)
[22:38] <xtknight> sistpoty, i should subscribe ubuntu-main-sponsors or someone else?
[22:39] <crimsun> jdong: / sistpoty: RE: 185634, have you guys reviewed the code?
[22:39] <slangasek> azeem: if you have a package that works better, I'll happily take it
[22:39] <azeem> unfortunately, not
[22:39] <azeem> been hacking on it for a couple of days now
[22:39] <sistpoty> xtknight: yes, please (and/or asking in #ubuntu-devel)
[22:39] <xtknight> sistpoty, never mind i found instructions on FreezeExceptionProcess.  sorry for bothering you
[22:39] <slangasek> azeem: ah, drat.  I was just looking at the 0.22-5 changelog and wondering if I should just take that one...
[22:39] <azeem> slangasek: oh, I haven't looked at 0.19-2ubuntu3
[22:39] <azeem> yet
[22:40] <azeem> doko only told me about -2ubuntu2
[22:40] <slangasek> ah
[22:40] <azeem> lemme try that
[22:40] <slangasek> well, MoM didn't know about -2ubuntu3 either at the time I started my merge :-P
[22:40] <sistpoty> crimsun: no... I don't have much clue about kernel stuff
[22:40] <slangasek> I may be better off wiping this dir and starting over (or letting you get it) :)
[22:41] <crimsun> sistpoty: that's not kernel stuff, really.
[22:41] <crimsun> sistpoty: it's really no different from any other firmware loader source package we have, like the midisport stuff
[22:42] <sistpoty> crimsun: I guess that falls under "kernel-stuff" for me :P
[22:42] <crimsun> (so yes, while it involves the kernel and udev, it's pretty much still MOTU)
[22:42] <azeem> oh, so python-xml isn't totall gone afterall?
[22:43] <slangasek> azeem: for all intents and purposes it's supposed to be
[22:43] <slangasek> azeem: in practice it may not actually be /gone/ yet...
[22:43] <azeem> well, did the cop-out thing in 2ubuntu3
[22:44] <azeem> +doko
[22:44] <sebner> mok0: I unsubscribed you. It's a sync now ^^
[22:44] <sistpoty> crimsun: still, it seems to be caused by changes in the kernel (or rather kernel package), right?
[22:44] <slangasek> oh
[22:44] <azeem> i.e. frobbed sys.path
[22:44] <azeem> that might sensible enough for enough
[22:44] <slangasek> oh grr, libopensync-plugin-kdepim was 1ubuntu1 when it should've been 1build1
[22:44]  * slangasek shakes fist
[22:46] <sistpoty> sebner: how do I actually play it (just testing the current version in ubuntu)... I can't seem to pass the intro screen :/
[22:47] <crimsun> sistpoty: not that I can tell.
[22:47] <sistpoty> crimsun: I'm asking because of https://bugs.launchpad.net/ubuntu/+bug/185634/comments/3
[22:48] <ubotu> Launchpad bug 185634 in ubuntu-meta "uvcvideo: iSight firmware loading does not work" [Medium,Confirmed]
[22:48] <sebner> sistpoty: choose a level and press "z"
[22:49] <crimsun> sistpoty: the kernel driver absorbing diffs and being renamed is not the culprit.  The culprit is combined /proc/bus/usb deprecation and udev rule silliness.
[22:50] <sistpoty> sebner: ok, thanks... that game sucks actually... I'm constantly loosing :O
[22:50] <slangasek> azeem: ok, and libopensync-plugin-sunbird wants to rename to -iceowl... :)  Do you have a package for this in your ppa that does the Ubuntu-ish thing?
[22:50] <sebner> sistpoty: xD. yeah not that exciting but hey there's still xmoto :P
[22:50] <crimsun> sistpoty: if I were doing a more thorough review, I would tidy up the udev rule to be conditional.
[22:51] <azeem> slangasek: hrm, no :-/
[22:51] <crimsun> sistpoty: aside from that, it's really up to MOTU-R.  :-)
[22:51] <sistpoty> crimsun: that's much more than I'd have known for instance... what would you do? give an ack for this?
[22:51] <slangasek> azeem: ok, I'll chase that up, but not today :)
[22:51] <sistpoty> sebner: bah... xmoto... I want a game I can easily win :P
[22:52] <azeem> slangasek: maybe it's better to drop that package, because it doesn't work with latest sunbird (they changed file format)
[22:52] <azeem> it used to be .ics or so, now it's some nightmare
[22:52] <sebner> sistpoty: you're just lazy. xD
[22:52] <sistpoty> heh
[22:52] <slangasek> azeem: drop it from both Debian and Ubuntu, or just Ubuntu for hardy?
[22:53] <crimsun> sistpoty: no.  I'd ask for the udev rule to be updated (e.g., checking for ACTION!="add" then short-circuiting, etc.)
[22:53] <azeem> slangasek: for hardy; I need to investigate for Debian; maybe it can be renamed to -plugin-file-ics, or so :)
[22:53] <azeem> this is second hand konwledge though
[22:53] <slangasek> azeem: haha, ok.  Would you mind filing a bug against it in LP with the rationale, and pointing me at it (or subscribing ubuntu-archive), so I have something to point at when people ask where it's gone?
[22:54] <azeem> (astronut fried his calendar by pointing that plugin to the new locations/file)
[22:54] <sistpoty> crimsun: ok, thanks (still have no clue, but I'll just cite you :P)
[22:54] <slangasek> sweet
[22:54] <crimsun> sistpoty: np
[22:54] <azeem> slangasek: ok, the plugin didn't get ported to 0.3x now anyway and looks like a dead-end
[23:03] <jdong> bug 185634
[23:03] <ubotu> Launchpad bug 185634 in ubuntu-meta "uvcvideo: iSight firmware loading does not work" [Medium,Confirmed] https://launchpad.net/bugs/185634
[23:05] <azeem> bug 215981
[23:05] <ubotu> Launchpad bug 215981 in libopensync-plugin-sunbird "Package should get removed or renamed" [Undecided,New] https://launchpad.net/bugs/215981
[23:05] <azeem> slangasek: ^^
[23:10] <sebner> gn8 folks :)
[23:17] <slangasek> azeem: thanks
[23:19] <YokoZar> Forgive me if this sounds like a really stupid question, but why is BLAH="what" echo $BLAH    giving me no output on the terminal?
[23:20] <slangasek> because structured like that, what you're saying is "run the 'echo $BLAH' command with BLAH set to "what" in its environment"
[23:21] <slangasek> so $BLAH gets evaluated, passed as an argument to the 'echo' command, and BLAH=what is set in the environment
[23:24] <Fujitsu> sistpoty: You mean I did the last upload to hardy? I don't believe I've ever uploaded matplotlib to unstable.
[23:24] <tjaalton> any motu-release members available? I've got a couple of vdr-plugin merges to fix FTBFS, debdiffs: http://users.tkk.fi/~tjaalton/dpkg/ {console,osdserver}.debdiff
[23:25] <YokoZar> slangasek: I guess I was expecting it to do the same thing as export BLAH="what" and then typing echo $BLAH on a new line (which does output what)
[23:25] <tjaalton> vdr-plugin-xinelibout fails to build on 64bit even though it uses -fPIC.. don't know what's going on there
[23:26] <slangasek> YokoZar: yes, it's not unreasonable to /expect/ that, but that's not what it does, for the reason explained. :)
[23:28] <sistpoty> Fujitsu: damn, yes. I've been intrigued by the diff
[23:31] <sistpoty> tjaalton: http://users.tkk.fi/~tjaalton/dpkg/osdserver.debdiff looks sane, ACK for this one
[23:32] <sistpoty> tjaalton: http://users.tkk.fi/~tjaalton/dpkg/console.debdiff looks a little bit whacky in regards to rules?
[23:34] <sistpoty> tjaalton: the other change to console.debdiff look sane though. please go ahead with this as you deem fit
[23:35] <sistpoty> tjaalton: the hutcc.* also for discussion?
[23:35] <sistpoty> (01_hutcc.* even)
[23:36] <tjaalton> sistpoty: heh, no, those are just leftovers
[23:36] <sistpoty> heh, k
[23:36] <sistpoty> tjaalton: ok, then please go ahead
[23:36] <tjaalton> sistpoty: -console switched to cdbs as the other plugins did, so that's why the diff looks odd
[23:36] <sistpoty> tjaalton: ah, didn't see this
[23:38] <sistpoty> k, /me needs to go to bed now... gn8 everyone
[23:39] <RainCT> good night