[00:06] <directhex> general packaging question: if, for the sake of argument, you have a source package which produces multiple binaries, and the install list for one of those binaries is empty, is that package just skipped entirely?
[00:06] <directhex> i.e. if i put foo.so and bar.so into different binary packages, but foo.so only builds on one arch, is that a problem?
[00:08] <ScottK-laptop> directhex: No and Yes.
[00:27] <sevenseeker> question about dpatch, how do I convert a normal patch to a dpatch?  I am trying dpatch-edit-patch new.dpatch old.dpatch per instructions at https://wiki.ubuntu.com/PackagingGuide/Complete#Patch%20Systems, but no new.dpatch is created
[00:34] <azeem> sevenseeker: you can just add the usual boilerplate (at least "@DPATCH@" I think) and add it to debian/patches/00list
[00:35] <azeem> I think dpatch expect -p1 style diffs
[00:35] <sevenseeker> ok, so if I have a normal style patch it will still work, just have to make sure it is p1 directory compliant?
[00:35] <azeem> and have the boilerplat
[00:35] <azeem> e
[00:35] <sevenseeker> where do I add the @DPATCH@ at?
[00:36] <azeem> at the top
[00:36] <azeem> just look at some other dpatch using package
[00:36] <sevenseeker> I see
[00:36] <sevenseeker> ok, I am still hunting around :)
[00:36] <sevenseeker> thanks guys, one other question
[00:36] <sevenseeker> does dpatch also create new dpatches just like diff does?
[00:36] <azeem> I don't understand the question
[00:37] <sevenseeker> if I want to create a new dpatch between two files or directories, how do I go about doing that?
[00:38] <sevenseeker> just manually edit a normal patch as with this one already in existence?
[00:38] <azeem> a dpatch is just a regular diff/patch with @DPATCH@ on top
[00:38] <sevenseeker> heh, ok... I thought it might potentially have more
[00:38] <sevenseeker> thanks again, keep up the good work guys
[00:43] <NCommander> hey azeem
[00:43] <azeem> heya
[00:44] <NCommander> how goes it azeem
[00:45] <azeem> tiiired
[00:46] <azeem> just back from the pub
[00:46] <azeem> if I keep on going, I can just as well watch the debate in a couple of hours I guess :-/
[00:46] <azeem> you?
[01:20] <NCommander> azeem, run down FTBFS, trying to force lenny out the door
[02:30] <tonyyarusso> Anyone around to give a little insight on some bugs?  There's been a significant uptick in bugs reported for kompozer in Intrepid, but the kompozer package itself hasn't changed at all, so it seems likely to be related to a dependency.
[02:46] <Hobbsee> tonyyarusso: or more people using it.  but yes, possibly a dependancy
[02:47] <tonyyarusso> Hobbsee: Fair point, but it's a Mozilla-related app that's based on what is now a VERY old base compared to Firefox and kin, so things are probably flat out missing.
[02:48] <ScottK> tonyyarusso: Dunno if it's related, but the Firefox packages (with Firefox 2.0) was recently removed from Intrepid entirely.
[02:48] <StevenK> And their locales and other bits
[02:48] <tonyyarusso> hmm
[02:50] <StevenK> Blah.
[02:50] <StevenK> ichthux-desktop still wants kio-sword
[02:50] <tonyyarusso> Well, here's what I have listed in the Depends:  libatk1.0-0, libc6, libcairo2, libfontconfig1, libgcc1, libglib2.0-0, libgtk2.0-0, libidl0, libpango1.0-0, libstdc++6, libx11-6, libxft2, libxt6, zlib1g
[02:50] <tonyyarusso> The application apparently will build and run, but certain actions cause it to segfault.
[02:51] <StevenK> tonyyarusso: Get a backtrace from it?
[02:51] <tonyyarusso> StevenK: I believe someone made one - lemme look quick.
[02:52] <tonyyarusso> StevenK: there are a couple of files on https://bugs.edge.launchpad.net/ubuntu/+source/kompozer/+bug/283400, but I'm not sure if they're what you're looking for.
[02:58] <tonyyarusso> StevenK: Do those look right or should I try to make one myself?
[02:59] <StevenK> tonyyarusso: The first one doesn't
[02:59] <StevenK> tonyyarusso: Install debug libraries and try and get a stack trace
[02:59] <tonyyarusso> okeydoke
[03:27] <sevenseeker> howdy, I am updating a library package that went from a lib.so.6 to lib-7.so, how do I specify the shlibs file line for that library?  Use a 0 for the 'version' field?
[04:30] <_Andrew> Could anyone look at this and tell me why my dependencies can't be resolved? http://pastebin.com/d450e8afb
[04:33] <RAOF> It's been some time since I used pbuilder, but that output looks normal so far - where's the rest?
[04:34] <_Andrew> http://pastebin.com/d503b6f03
[04:36] <_Andrew> It says Aptitude couldn't satisfy the build dependencies
[04:38] <RAOF> It does indeed.  That's fairly strange.
[04:40] <tonyyarusso> Um, so I'm trying to collect a backtrace of something, but it's not actually quitting completely.
[04:40] <RAOF> Run it in gdb?
[04:40] <tonyyarusso> There's a segfault, which shows up in the terminal with gdb, but the process hangs and I end up having to use 'kill' to get things done.
[04:40] <wgrant> Or attach to it in gdb.
[04:40] <wgrant> Hmm, what is it?
[04:40] <tonyyarusso> I attached while it was running, yes.
[04:40] <tonyyarusso> It's kompozer.
[04:41] <wgrant> What does bt say?
[04:41] <wgrant> Could be its signal handler dieing, thus giving nice recursion.
[04:41] <tonyyarusso> erm, could you be more specific please?
[04:41] <wgrant> Type 'bt' in gdb.
[04:42] <StevenK> wgrant: If Kompozer has a SEGV handler, they're even more on crack that I thought
[04:43] <wgrant> StevenK: It has a K and a z in its name. What do you expect?
[04:43] <wgrant> SDL does, so why not Kompozer?
[04:43] <StevenK> Hah
[04:43] <StevenK> wgrant: SDL is a framework, though
[04:43] <wgrant> True.
[04:44] <RAOF> There's some KDE people in here, I'm sure.  Where in the name of all that is holy can I add a program to my session under 3.5?  (Hint: Control Centre->Session Manager is a lie).
[04:44] <tonyyarusso> wgrant: working on getting to that point again - one sec
[04:44] <_Andrew> Would this be because I have a package that doesn't exist? Depends on package1 or unknown package ?
[04:44] <_Andrew> or would it just ignore the unknown package?
[04:45] <RAOF> _Andrew: No, it'd die in the way you've seen if it was depending on a non-existent package.  But libboost-regex-dev _isn't_ a virtual package, at least in Intrepid.
[04:45] <tonyyarusso> wgrant: http://pastebin.com/m50786a4
[04:46] <_Andrew> This is for hardy
[04:46] <_Andrew> sorry I should have mentioned that
[04:46] <wgrant> Oh. It looks Mozillary. I'm running away no.
[04:46] <wgrant> s/no/now/
[04:47] <tonyyarusso> It is a Mozilla stepchild, yes.
[04:47] <tonyyarusso> I get that reaction a lot.......
[04:48] <NCommander> hey wgrant
[04:49] <RAOF> _Andrew: So, it would seem likely that something's messed up in your pbuilder setup.  Have you run 'pbuilder update' recently?
[04:52] <_Andrew> same result
[04:53] <RAOF> Care to pastbin the output of "pbuilder update"?
[04:55] <fabrice_sp> _Andrew: you have a warning that could explain your problem: W: /home/andrew/.pbuilderrc does not exist
[04:56] <fabrice_sp> Could you create that file with COMPONENTS="main restricted universe multiverse" in it
[04:56] <fabrice_sp> ?
[05:04] <ScottK> fabrice_sp: That warning isn't a problem.
[05:11] <fabrice_sp> ScottK: I know that it isn't a problem, but I had a similar dependency problem, and it solved it. In this case, the missing lib are in main, so it shouldn't help. You're right
[05:18] <ScottK> fabrice_sp: No, I mean lack of a per user config file isn't a source of problems.  Not having a .pbuilderrc isn't wrong if the right options are set elsewhere
[05:20] <fabrice_sp> ScottK: sure. In this case, as it seems that it's his first use of pbuilder, I assumed that he could miss that other options, so creating .pbuilderrc with the right options could have helped
[05:23] <_Andrew> RAOF: Well, I can't figure out why this is, I didn't change any of the dependencies from the package.
[05:24] <_Andrew> I don't think it's pbuilder..
[05:24] <_Andrew> http://packages.ubuntu.com/hardy/libcegui-mk2-1
[05:25] <_Andrew> I took that package
[05:26] <_Andrew> ah I think I know
[05:27] <_Andrew> no universe packages
[05:29] <_Andrew> yep that it, hehe woops..
[05:29] <_Andrew> thanks guys
[06:58] <dholbach> good morning
[08:11] <NCommander> hey dholbach
[08:12] <dholbach> hi NCommander
[08:13] <NCommander> how goes it dholbach
[08:13] <dholbach> good good, how 'bout you?
[08:39] <directhex> mornin'!
[09:49] <didrocks> morning :)
[09:56] <sebner> huhu sistpoty|work :)
[09:56] <sistpoty|work> hi sebner
[09:57] <NCommander> hey sistpoty|work
[09:57] <sistpoty|work> hi NCommander
[09:57] <NCommander> sistpoty|work, how goes it?
[09:58] <sistpoty|work> NCommander: quite good
[09:59] <NCommander> sistpoty|work, that's good. I'm working to improve REVU. We now have trustroot status
[10:00] <NCommander> (or in other words, go try logging in on REVU and see the new message ;-))
[10:00] <laga_> what's that? trustroot?
[10:03] <NCommander> laga_, it means REVU can pull trusted information over openid such as email addresses
[10:03] <sistpoty|work> NCommander: excellent!
[10:04] <NCommander> laga_, go try logging in on REVU,a nd take a close look at the text
[10:04] <NCommander> There is a message from canonical on it ;-)
[10:18] <StevenK> sistpoty|work: So, why haskell-devscripts from *testing*, we sync from unstable?
[10:19] <sistpoty|work> StevenK: because I haven't looked over the changes that are in between testing and unstable yet
[10:19] <StevenK> sistpoty|work: I'm not sure that I can sync from testing
[10:19] <sistpoty|work> hm...
[10:19] <sistpoty|work> StevenK: give me a few minutes, to look at what changed, ok?
[10:23] <james_w> StevenK: I've requested it before and it was done
[10:23] <StevenK> james_w: Shh!
[10:23] <StevenK> :-P
[10:23] <james_w> :-)
[10:25] <sistpoty|work> StevenK: haskell-devscripts 0.6.14 is likewise sane :)
[10:25] <StevenK> sistpoty|work: Please comment on the bug
[10:26] <sistpoty|work> StevenK: done
[10:39] <directhex> hm. i need to refresh an autoreconf patch
[10:47] <NCommander> directhex, have you made the necessary sacarifies?
[10:47] <directhex> NCommander, i've decided to work on a different package and pretend this one doesn't exist :)
[10:48] <NCommander> you gave up on mono ;-)?
[10:49] <directhex> meebey is working on mono.
[10:49] <directhex> i've done gluezilla, libgdiplus, and mono-basic
[10:51] <directhex> http://monoport.com/37751
[10:53] <directhex> thankfully, the 2.0 components i've done so far don't actually need 2.0 to build/install
[11:03] <james_w> Hi all, does every upload now require motu-release ACK? There have been possibly conflicting statements
[11:03] <persia> james_w, For hardy, we did it that way post-final-freeze.
[11:04] <persia> james_w, Generally, my experience is that someone glances at the debdiff, and says "sure", assuming it's small and prevents an SRU.
[11:04] <persia> (or otherwise does something critically good)
[11:05] <james_w> oh yeah, I know it's a smooth process usually, I'm just wondering whether I should start bugging members of the release team yet
[11:05] <persia> james_w, Note that I've not yet received the freeze mail, so you might have a couple hours left before that applies.
[11:05]  * persia hopes so, as the timidity debdiff isn't exactly small
[11:05] <james_w> I've got Steve's, and the archive is frozen
[11:05] <DktrKranz> james_w: a IRC ACK is usually enough (they did so for hardy)
[11:06] <persia> Ah.  I do have it, I just hadn't pulled my mail in an hour :(
[11:06] <james_w> and the mail he pointed to from the hardy release suggests that everything now requires approval
[11:06] <james_w> but the other day in response to my question about universe for "RC freeze this Thursday" Scott said
[11:06] <james_w> "I don't think it means anything more than the other freeze have meant.  The
[11:06] <james_w> weekend before the final freeze we'll want to start approving all uploads.
[11:06] <james_w> Exactly when is dependent on when Ubuntu Release intends too final freeze."
[11:07] <persia> Well, this is final freeze, so this would be the beginning of that weekend.
[11:07] <directhex> yay for slipping a final mono release out of the door, then
[11:07] <james_w> ok, I'll request exceptions, thanks
[11:10] <ScottK> james_w: I don't think you need to do that.
[11:11] <james_w> really?
[11:11] <persia> ScottK, What's the policy for FinalFreeze then?
[11:11] <wgrant> I faintly recall that it is usually the final week that is universe FinalFreeze, but it happens so rarely that I can't remember.
[11:11] <directhex> next MOTU meeting is a fortnight ago? /topic needs a poke
[11:12] <ScottK> persia: Final freeze would be the one before release, not before RC.  I'm rereading the referenced mail and will work on a clarification.
[11:12] <directhex> that's better :)
[11:12] <persia> ScottK, The freeze applied today is the last freeze listed at https://wiki.ubuntu.com/IntrepidReleaseSchedule
[11:13] <james_w> see, this is why I request a mail stating the policy from the release team
[11:13] <persia> RC and FinalFreeze were at the same time in previous cycles : I think FinalFreeze got moved up one week this time.
[11:14] <directhex> jaunty debianimportfreeze is ~xmas, then?
[11:14] <ScottK> Right.  I'll work on clarification.
[11:14] <persia> directhex, Somewhere around there.
[11:14] <persia> directhex, Might even be as late as mid-january, depending.
[11:14] <wgrant> persia: Ahh, that makes more sense.
[11:14] <wgrant> I didn't think FinalFreeze was so long.
[11:15] <persia> wgrant, Except it doesn't match wiki history.  It appears FinalFreeze was introduced in Hardy, and was a week before RC.
[11:15] <persia> (10th April)
[11:15] <wgrant> Hrmph.
[11:17] <persia> Anyway, I still want to push bug #281276 and various timidity stuff.  Do I need explicit permission from someone?
[11:19] <ScottK> sistpoty|work, TheMuso, DktrKranz, (and norsetto if you show up): I just sent mail to the MOTU list asking about when we start approving all uploads.  Please read and reply.
[11:28] <DktrKranz> ScottK: replied, thanks
[11:36] <DktrKranz> persia: for -rt stuff, linux-meta-rt needs some adjustments too (IIRC, there are packages pointing to *-restricted-extra which are not available).
[11:37] <persia> DktrKranz, Yep, and something needs to depend on linux-firmware.  I believe Alessio is planning to finalise everything tonight (in light of KernelFreeze).
[11:37] <DktrKranz> persia: good. I sponsored uploads of it, if needed just give a shout
[11:38] <apachelogger> dholbach, persia, geser, nixternal, soren: what is the hold up on smarter's MOTU application?
[11:38] <persia> DktrKranz, I'll probably upload it when it's done : I just want to make sure I've gotten any required approvals.  Kernel team did a preliminary recently, so I'm feeling pretty good about stability.  Regression risk is nil as the current -rt doesn't work at all.
[11:39] <DktrKranz> persia: thanks (from a linux-rt user POV)
[11:40] <dholbach> apachelogger: afaics only nixternal and I voted +1 up until now - I'll prod the others again to vote
[11:40] <persia> apachelogger, Just the usual extreme slowness.  Waiting for three more MC comments.
[11:41] <apachelogger> :) it's been > 12 days already https://wiki.ubuntu.com/UbuntuDevelopers#MOTU
[11:42] <persia> apachelogger, Yeah.  The 12 days bit was something that nobody ever accepted as binding, unfortunately.
[11:43] <apachelogger> Maybe you could discuss this some time? Either it should be accepted as binding or removed from that page.
[11:43] <dholbach> *nod*
[11:48] <wgrant> sistpoty|work: Launchpad provides no facility to freeze just some components.
[11:48] <sistpoty|work> wgrant: ah thanks
[11:49] <emgent> gmoin
[11:50] <persia> motu-release: thanks for the speedy establishment of a clear guideline.
[11:52] <wgrant> Mightn't it be best to put that up the front?
[11:53] <wgrant> And merge it with the FF item.
[11:53] <persia> That should improve readability, at least
[11:53] <wgrant> And perhaps drop MoM, as the topic is overly long now.
[11:53] <sistpoty|work> or maybe even drop it altoghether?
[11:53]  * sistpoty|work tries again
[11:54] <sistpoty|work> hm...
[11:54] <wgrant> As there are no further restrictions in this freeze, that should be OK.
[11:54] <sistpoty|work> otherwise I'll leave it to whomever has better ideas :)
[12:38] <siretart> @motu-release: OK to upload this vlc update: http://paste.ubuntu.com/58308/ to intrepid?
[12:39] <siretart> according to sistpoty's mail at https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html it is okay to ping you on irc
[12:40] <sistpoty|work> siretart: we're not yet in final freeze for universe/multiverse, so only "normal" feature freeze applies
[12:40] <persia> siretart, According to https://lists.ubuntu.com/archives/ubuntu-motu/2008-October/004849.html you don't have to ask until next week.
[12:40] <sistpoty|work> hi siretart btw. ;)
[12:41] <siretart> ah, then I misread steve's mail. great
[12:41] <siretart> heyha sistpoty|work! hi persia
[12:41] <persia> siretart, Hi :)  And no, you didn't misread the mail, the policy was just updated *very* recently.
[12:42] <siretart> persia: ah, I see. perhaps a followup u-d-a would prevent further confusion?
[12:42] <laga_> is there a wiki page which explains the policy? i don't want to read hundreds of different opinions on the ML, just the definite point
[12:43] <persia> laga_, No.
[12:43] <siretart> laga_: http://wiki.ubuntu.com/UbuntuDevelopment
[12:43] <siretart> if something is missing there, I'd consider it as a bug
[12:44] <siretart> (including the referenced wiki pages from there)
[12:44] <laga_> by "explains", i meant a page that simply states the current policy
[12:45] <persia> Hrm.  Good point.
[12:45] <laga_> it shouldn't be an insider only thing :)
[12:46] <persia> laga_, It's very much not an insider-only thing.  It's just that nobody has yet taken the recent decision from the mailing list and put it in the wiki.  If you did that, I'm sure your efforts would be appreciated.
[12:49] <siretart> is bzr 1.7 going to hit intrepid?
[12:51] <persia> It's unlikely at this point, unless someone gets special approval.  I haven't heard of a special bug.
[13:01] <wgrant> I think it might be a good idea, particularly as bzr isn't well known for regressions, and LP seems to want bzr 1.7. And bzr 1.7 is fast.
[13:04] <persia> james_w, Any guidance from upstream on which bzr for intrepid?
[13:04] <wgrant> But it's in main, so it's not likely.
[13:05] <james_w> they would probably like 1.7, but it was released after feature freeze and I didn't push it
[13:05] <james_w> as long as we are >=1.6.1 it's a good start
[13:05] <persia> james_w, OK.  Do we lose compatibility with LP the way we did in hardy with 1.3?
[13:06] <james_w> not 1.6->1.7
[13:06] <james_w> can't speak for the future though
[13:07] <persia> Understood.  1.6 -> 1.7 is the interesting part, as it would fall into RC land.
[13:09] <james_w> I'll probably be organising backports of some version to hardy, so I could do the same for Intrepid
[13:13] <lfaraone> Hey, what's the feature-freeze for jaunty>?
[13:14] <persia> lfaraone, Probably sometime in February, although the schedule is yet to be established.
[13:15] <lfaraone> persia: crap.
[13:15] <persia> !ohmy
[13:15] <lfaraone> persia: the project I'm packaing for releases march 3rd.
[13:15] <persia> lfaraone, That aside, why?
[13:15] <lfaraone> (sugar)
[13:16] <persia> lfaraone, That might not be an issue if you plan well.  Make sure the snapshots make FeatureFreeze, and you should only have bugfix updates for the last few weeks.
[13:16] <persia> (at least assuming sugar follows a features-first-then-bugfix development model)
[13:17] <lfaraone> persia: yeah, RC comes out feb 13th, and betas are as early as dec 21
[13:18] <persia> lfaraone, You might be a bit tight on RC, but going from RC to final is just a matter of helping the sugar team not add any features post RC.
[13:20] <lfaraone> persia: Bad news: debian upstream maintainer is slow to package. Would we be able to send in updated versions bypassing debian if they will be too late?
[13:21] <persia> lfaraone, Yes, although perhaps working with the Debian maintainer to collaborate would be better.
[13:22] <lfaraone> persia: we'll send him our patches :)
[13:22] <persia> lfaraone, Rather, you might want to engage in a deeper dialogue to collaborate.
[14:23] <james_w> stefanlsd: hi, I still can''t install bugzilla
[14:24] <james_w> stefanlsd: http://paste.ubuntu.com/58348/
[14:33] <stefanlsd> james_w: is this within a pbuilber or chroot?
[14:33] <james_w> yeah pbuilder chroot
[14:37] <stefanlsd> james_w: i suspect it may be related to that. Did you get the debconf dialog stuff?
[14:38] <james_w> stefanlsd: yeah
[14:38] <james_w> I told it not to use dbconfig-common
[14:42] <stefanlsd> wgrant: k. im getting the same thing. i will investigate
[14:42] <stefanlsd> bleh
[14:42] <stefanlsd> james_w: ^
[14:46] <sistpoty|work> ScottK, DktrKranz, TheMuso: I'm just about to post a follow up about current universe/multiverse freeze handling: http://paste.ubuntu.com/58351/
[14:46]  * ScottK looks
[14:47] <sistpoty|work> any corrections? anything I missed?
[14:47] <ScottK> sistpoty|work: I'd add a mention that the last opportunity for uploads will likely be sometime next weekend depending on when ubuntu-release decides to freeze the archive solid.
[14:48] <ScottK> What's there is good.
[14:49] <persia> Will we still be able to push RC stuff post solid-freeze for unseeded stuff, or are we not doing that this cycle?
[14:50]  * DktrKranz looks too
[14:51] <Hobbsee> persia: unlikely.
[14:51] <Hobbsee> persia: (dak import)
[14:51] <persia> sistpoty|work, Could you put a note in there about the universe flavours?  CD testing is happening next week, and it'd be unfortunate to break something.
[14:52] <persia> Hobbsee, Hrm?
[14:52] <Hobbsee> persia: the final, solid, no more packages accepted freeze?
[14:52] <Hobbsee> no, you cant' push packages after that ( a couple of days before release)
[14:52] <Hobbsee> prior to that, *shrug*
[14:52] <persia> Hobbsee, This is new.  I've previously pushed until about 2 hours before a release.
[14:53] <Hobbsee> persia: nwo that would be odd - usually the import is started way before that.
[14:53] <Hobbsee> unless it got pushed to -updates or something
[14:53] <persia> No, into the main repos.
[14:53] <ScottK> persia: I think you are mis-remembering.
[14:54]  * Hobbsee agreeswith ScottK - and suspects persia also doesn't mean the final release.
[14:54] <persia> Or perhaps I have the time of release wrong.
[14:54] <ScottK> The last two releases, the final uploads happened on Sunday or Monday before release.
[14:54] <persia> I remember pushing the aolserver4 changes *very* late.
[14:54] <ScottK> I remember that and it was before the archive froze, not release.
[14:57] <persia> Yeah.  That was Monday night (~13:00 UTC).  I am misremembering.
[14:59] <sistpoty|work> next try: http://paste.ubuntu.com/58354/
[14:59] <sistpoty|work> slangasek: is final release scheduled directly at oct 30th? (not that I give wrong dates in the follow up *g*)
[15:00]  * ScottK notes that http://qa.ubuntuwire.com/bugs/rcbugs/ is working again and it's a good place for people to look for easy wins.
[15:03] <AnAnt> if no one has responded to bugs that I reported few days ago, what should I do ?
[15:04] <persia> AnAnt, Not much you can do, except wait.  If you think it's critical, and you have some ideas, you could see if anyone wants to talk about it.
[15:04] <ScottK> sistpoty|work: two/four, but otherwise good.
[15:05] <james_w> sistpoty|work: bug 257110
[15:05] <james_w> sistpoty|work: when you reverted, did you revert the previous upload in its entirety?
[15:05] <AnAnt> is bug 281696 critical ?
[15:06] <sistpoty|work> james_w: yep, that's what I did
[15:07] <AnAnt> persia: I have that feeling that you didn't try sl-modem yet
[15:08] <persia> AnAnt, It may be for certain hardware, or if it affects many users.  I'd ask about that in #ubuntu-desktop
[15:08] <persia> And you'd be right about sl-modem :)  It's on my to-be-tested list, and about #5, but not quite at the top.
[15:09] <AnAnt> ok
[15:10] <james_w> ah, it's in NBS
[15:10] <james_w> anybody want to teach me about how to clear a package from NBS?
[15:10] <persia> sistpoty|work, Oh, and thanks for adding the note about the flavours.  Looks good to me.
[15:11] <persia> james_w, I'd be happy to in ~20 minutes, if nobody else does.
[15:11] <james_w> persia: great, I'll go get lunch in the mean time
[15:12] <ScottK> james_w: The short version is figure out what's in the archive that depends on it and make the dependency go away.
[15:19] <rainct> nhandler: man those encoding errors will get me mad :P
[15:26] <sevenseeker> good morning everyone
[15:27] <sevenseeker> I am updating a library package where the numbering of the so lib changed from something like foo.so.1 to foo-2.so, how can I use a foolib.shlibs in my package in that scheme?
[15:31] <ScottK> sistpoty|work: Would you be able to help me with a library package update?  I have a new upstream that has a bunch of important fixes, but also bumped the minor version of the soname.  I'd like an expert review to see if it's potentially sensible to include in Intrepid.
[15:31] <sistpoty|work> ScottK: sure
[15:32] <ScottK> sistpoty|work: The package is libspf2.  You can grab the Intrepid on and I'll put the candidate somewhere you can get it.  One moment.
[15:35] <ScottK> sistpoty|work: http://kitterman.com/test/libspf2_1.2.8.dfsg-0ubuntu1.dsc
[15:37] <sistpoty|work> ScottK: wow, that's a huge diff... might take a while to review
[15:38] <ScottK> sistpoty|work: I'm not asking for a full source review, but just the abi/api.  Is that huge?
[15:39] <sistpoty|work> ScottK: well, this also means to review the headers...
[15:42] <ScottK> Ah.  Well from what I can tell the package was fairly broken before in a number of subtle ways.  It'd be good to get it in if we could.
[15:43] <james_w> ah, I found https://wiki.ubuntu.com/UbuntuDevelopment/NBS which is pretty good
[15:44] <persia> james_w, That's the output of my last session :)  Let me know if you have questions.
[15:44] <james_w> ah, cool
[15:44] <james_w> nice work
[15:45] <persia> Much of the credit goes to the wiki editors : it started as an IRC log.
[15:46] <james_w> turns out this one is dead simple
[15:46] <sevenseeker> persia: do you know how I would package a lib that is named foo-1.so with no version at the end for the libfoo.shlibs file?
[15:47] <persia> sevenseeker, Only very vaguely : shlibs generally confuse me.  Generally, you want a versioned .so anyway, as otherwise things tend to break.
[15:48] <broonie> sevenseeker: The versioning is pretty much essential.
[15:48] <sevenseeker> persia: I am not that familiar with the build practices in regards to naming conventions, could I change the make file to generate one with a version?
[15:48] <sevenseeker> for example, it is actually foo-1.5.11.so, could I rename to foo-1.5.so.11?
[15:49] <james_w> persia: I assume the package in question being in "|" group in Depends won't keep it from being removed?
[15:49] <broonie> sevenseeker: No.
[15:49] <persia> james_w, In cases like that, sometimes it's helpful to give a hint to the archive-admins.  Once you clear an entire set, just mention in #ubuntu-devel that something can be NBS'd.
[15:50] <sevenseeker> broonie: james_w: thank you for your feedback
[15:50] <sevenseeker> looks like I should deal with the upstream guys or just ignore shlibs for now :( :( :(
[15:50] <ScottK> sistpoty|work: I have upstream on another IRC channel if you have questions.
[15:50] <ScottK> The latter is a recipe for pain.
[15:50] <sistpoty|work> ScottK: nope, haven't got questions yet... still reading ;)
[15:50] <ScottK> OK.
[15:51] <broonie> sevenseeker: Yes, SONAME really needs to come from upstream since it should ideally be consistent over all distibutions, not just Ubuntu.
[15:51] <sevenseeker> broonie: I am glad you confirmed that
[15:58] <sistpoty|work> ScottK: though I've only read through the header diffs right now, I think there is a tiny ABI incompatibility
[15:58] <ScottK> sistpoty|work: OK. Would you mail/paste me details?
[15:58] <sistpoty|work> ScottK: in one structure, an int is replaced with a size_t, which has a different storage size on amd64 at least (didn't know that myself yet )
[15:59] <ScottK> sistpoty|work: I think that's a bug fix.
[15:59] <sistpoty|work> ScottK: there: http://paste.ubuntu.com/58378/
[15:59] <ScottK> Did you look in our patches to see if we'd patched it (I will if you didn't)
[16:00] <sistpoty|work> ScottK: even if size_t looks more correct, that still breaks the abi
[16:00] <sistpoty|work> ScottK: nope, haven't done that yet
[16:00] <ScottK> OK.  I'll look
[16:00] <sistpoty|work> hm... I guess that's why I dislike patch systems *g*
[16:02] <sistpoty|work> ScottK: there's also one in /src/include/spf_request.h
[16:02] <sistpoty|work> change from int to size_t
[16:03] <ScottK> The one you pastebinned we already patched, so it's no change
[16:04] <ScottK> The second one we didn't patch, but should have.
[16:05] <ScottK> sistpoty|work: So I can check the source of the rdepends to see if they use that include, right?
[16:06] <sistpoty|work> ScottK: yes
[16:06] <ScottK> OK.  Is that the only one or are you still looking?
[16:07] <ScottK> I'm guessing it didn't get patched because no one used it and no one complained, but I'll look.
[16:07] <sistpoty|work> ScottK: that *seems* to be the only one, but I haven't looked at symbols yet
[16:07] <ScottK> OK.
[16:08]  * ScottK waits with baited breath ...
[16:08] <sistpoty|work> ScottK: most probably you'll want to grep any rdepends if they create/use a SPF_request_t somewhere
[16:09] <bddebian> Heya folks
[16:09] <sistpoty|work> ScottK: because that would then be 4 bytes too small on amd64 :(
[16:09] <sistpoty|work> hi bddebian
[16:09] <bddebian> Heya sistpoty|work
[16:10] <sistpoty|work> ScottK: Ideally, libspf2 would have an SONAME bump upstream-wise
[16:10] <sistpoty|work> ScottK: but in the lack of it, I'm quite assured that rdepends will still build
[16:10] <ScottK> It went from 2.0 to 2.1 IIRC
[16:11] <sistpoty|work> ScottK: but the name of the binary package didn't change?
[16:12] <ScottK> sistpoty|work: Because I didn't change it.
[16:12] <sistpoty|work> ScottK: ah, then I guess you'd better change it ;)
[16:12] <geser> Hi bddebian
[16:13] <bddebian> Heya geser
[16:13] <ScottK> sistpoty|work: Yeah.  I'm not ready to upload it yet.  I'm trying to get this sorted to see if I can.
[16:13] <sistpoty|work> ScottK: then, I don't even need to look at symbols, since rdepends would still need a rebuild
[16:15] <huats> nxvl: and porthose : hey
[16:16] <ScottK> sistpoty|work: Well I'd like to know if it's sane to think it'd work.  Also what should I name the new binary package?
[16:16] <porthose> huats: hey
[16:16] <sistpoty|work> ScottK: what lintian tells you to ;) (it should reflect the soname)
[16:16] <sistpoty|work> the rules are somewhere in the library packaging guide, but lintian also knows the bits
[16:17] <nxvl> huats: i'm ok with the date
[16:17] <nxvl> :D
[16:18] <huats> nxvl: porthose so it is now right ?
[16:18] <huats> :)
[16:18] <nxvl> huats: yes, channel?
[16:18] <huats> -meeting :)
[16:18] <porthose> huats: :)
[16:18] <ScottK> sistpoty|work: OK.  IIRC it didn't complain about the old name.
[16:19] <csilk> is it ok to include three .desktop files in one package or should it be split into 3 packages?
[16:20] <csilk> one for kubuntu, xubuntu and gnome..
[16:21] <geser> csilk: why do you need different .desktop files?
[16:21] <persia> csilk, Unless you're *really* careful with OnlyShowIn, you might want three.  Often you want to split the frontends anyway, so people don't have too many dependencies.
[16:22] <csilk> persia, ok three packages it shall be
[16:22] <csilk> this is the kind of info the wiki lacks
[16:22] <sistpoty|work> ScottK: do you happen to have an amd64 binary of the new package? (then I wouldn't need to build it myself)
[16:22] <persia> csilk, It's actually a fairly uncommon question.  I've seen it asked thrice since I've been following IRC.
[16:23] <ScottK> sistpoty|work: No.  All I have it i386
[16:23] <sistpoty|work> ok
[16:23] <ScottK> sistpoty|work: It's a quick build.
[16:23] <csilk> persia,  yeah I usually wouldn't bother but upstream is insisting the packages works just as well in kubuntu and xubuntu as it will in gnome
[16:23] <csilk> *work
[16:24] <persia> csilk, Wait.  How do the .desktop files differ?
[16:25] <_Andrew> Is there anyone around that can help me? My ppa won't compile because the build machines aren't installing the packages.
[16:25] <cprov> _Andrew: hi, point me to the broken buildlog
[16:25] <_Andrew> ok 1 sec
[16:25] <csilk> persia, at the moment they don't as I haven't started on them
[16:25] <_Andrew> did you want a url or package name?
[16:25] <cprov> _Andrew: url
[16:26] <_Andrew> http://launchpadlibrarian.net/18603984/buildlog_ubuntu-hardy-i386.ogre_1.6.0~ppa2_MANUALDEPWAIT.txt.gz
[16:26] <cprov> _Andrew: nvidia-cg-toolkit is trying to download stuff.
[16:26] <_Andrew> It fails when it trys to install nvidia-cg-toolkit .
[16:27] <_Andrew> yeah, so how can I get it to install the toolkit
[16:27] <csilk> persia,  the only difference in them should be icon and menu population related things
[16:27] <persia> csilk, OK.  Unless you're generating different binaries for the front-ends, there's usually little point to adjusting the .desktop files.  If you are generating different binaries, then you need it, of course :)
[16:28] <persia> Why a different icon?
[16:28] <persia> And the menu population should be the same : they are all XDG-compliant environments.
[16:28] <csilk> I assumed the way you would popualte a kde menu would differ from gnome?
[16:28] <cprov> _Andrew: soyuz builds are explicit forbidden to access external sources. I don't know exactly what motu guys does to workaround this and the related legal issues involved.
[16:29] <persia> csilk, It shouldn't.
[16:29] <csilk> in that case I wouldnt need more than one .desktop file would I?
[16:30] <persia> Unless you have different front-ends, or you need to pass some argument to hint at the interface, you shouldn't.
[16:31] <csilk> No, the front end should be consistent accorss all the distros
[16:31] <_Andrew> oh.. Then who can I talk to, to get it working?
[16:31] <csilk> *across
[16:31] <csilk> hmm, looks like I'll just be making the one .desktop file then, thanks alot persia, big help
[16:32] <cprov> _Andrew: also 'libfreeimage-dev (>= 3.11.0)' dep can't be satisfied, since ubuntu has 3.10.0-1 and your ppa has 3.11.0~ppa2   (which is lower than 3.11.0)
[16:33] <cprov> _Andrew: make it "(> 3.10.0-1)" , I guess.
[16:33] <_Andrew> oh, it's lower?
[16:34] <_Andrew> If 3.11.0~ppa2 is lower then 3.11.0 then what is it?
[16:34] <_Andrew> hehe confusing..
[16:34] <persia> csilk, That's part of why the question doesn't come up much :)
[16:37] <persia> Is anyone currently looking at gtklookat ?
[16:41] <sistpoty|work> ScottK: ok, upstream didn't change the resulting soname (but should have)
[16:41] <_Andrew> cprov: Thanks for help with the version thing, it's building on my machine now
[16:41] <sistpoty|work> ScottK: however I guess there is little risk in bringing in the library if you also rebuild all rdepends (as the ABI change is pretty minimal)
[16:42] <sistpoty|work> ScottK: hence from a library packaging perspective, I see no reason not to go for it
[16:42] <_Andrew> What can I do about the nvidia tool kit though? Do I need to file a bug or email someone ?
[16:42] <_Andrew> It's important that cg support in Ogre isn't disabled
[16:42] <cprov> _Andrew: it won't be considered a bug, it's a security feature instead.
[16:43] <sistpoty|work> ScottK: however now I've gotta run, cya
[16:43] <_Andrew> yeah, sorry I did mean it was a bug, I mean how do I contact someone
[16:43] <cprov> _Andrew: as I said, I don't know what's the right way to include non-free build dependencies.
[16:43] <_Andrew> didn't**
[16:43] <cprov> persia: do you know know ? ^
[16:44] <persia> _Andrew, The problem is that the buildd admins don't want to manually build ogre every time, and the toolkit package needs access to the internet at build-time.
[16:44] <persia> cprov, The right way depends on the non-freeness of the dependencies.  In this case, ogre does the best it can, but it just doesn't work with Soyuz.
[16:45] <persia> cprov, If you want to fix it, it would mean allowing binary uploads by more than the current three people, but only in special cases.
[16:45] <persia> Personally, I'm not sure it should be fixed.
[16:45] <cprov> persia: yes, me neither.
[16:46] <_Andrew> Can't you just host the nvidia files on the build machine and when it tries to download them it goes to the local machine rather then on the internet?
[16:46] <_Andrew> I understand the problems with download stuff off the net
[16:46] <persia> _Andrew, That would be redistribution, which nVidia prohibits.
[16:47] <cprov> _Andrew: hosting non-free would incur in legal issues.
[16:47] <geser> _Andrew: that's probably the problem and the reason why nvidia-cg-toolkit is an installer
[16:47] <_Andrew> hehe yeah
[16:47] <persia> _Andrew, I chased this for a couple weeks about a year ago, and the only solution was to have one of three people manually update it *every* upload, which none of them were willing to do.
[16:48] <_Andrew> oh : /
[16:48] <persia> cprov, Not at all.  Most non-free packages may be hosted legally, it's just a couple special cases (like nvidia-cg-toolkit) that have issues.
[16:50] <_Andrew> What's so special about the cg-toolkit?
[16:50] <cprov> persia: really ? I always take this very conservative approach about non-free sources. But, that's more ignorance than knowledge on my side.
[16:51] <cprov> I will let you guys talk about it ... I need to grab some food.
[16:51] <persia> cprov, There's several classes of stuff in multiverse.  Some is free, but has non-free dependencies.  Some is limited by use case (non-military and  non-commercial being the most common).
[16:52] <persia> Some is restricted in use (e.g. "users of this software should send the author a postcard"), and some in modification (e.g. "This software must be shipped without distribution patches").
[16:53] <_Andrew> So the problem with Nvidia toolkit is that you can not redistribute it?
[16:53] <persia> Only a small minority is binary only, and of that, an even smaller minority has restrictions on redistribution (where we ship an installer).
[16:53] <persia> _Andrew, precisely.  Get nVidia to allow redistribution, and we'll ship the binary for Jaunty, which means ogre-contrib can build.
[16:54] <persia> (and fungaloids will stop being broken)
[16:54] <_Andrew> Then why do they have a redistributable binaries page? Or are you saying that the binarys is different from the source package
[16:56] <_Andrew> btw, I'm not trying to argue with you here, just trying to understand the situation
[16:57] <persia> _Andrew, Did the licensing change?  Last I looked it didn't permit free redistribution.  If this changed, this becomes a soluable problem.
[16:57] <_Andrew> http://developer.nvidia.com/object/cg-redistributable-binaries.html
[16:58] <_Andrew> I can't find any information about the rights given to the downloader
[16:59] <persia> Yeah.  That's the tricky part.  Given the current state of copyright, it needs to explicitly permit redistribution in some license text somewhere.
[17:00] <_Andrew> All I see is a blanket legal document.. maybe it's in the toolkit..
[17:03] <persia> _Andrew, I found the license.  It seems there is a "Linux Exception" (section 2.1.3) that would allow distribution of software designed exclusively for use on the Linux operating system, and there seems to be a way to download only the linux binaries.  With some hacking of nvidia-cg-toolkit, you may be able to make it work.
[17:04] <_Andrew> The docs directory contains a file Cg_Redist_License.pdf providing a non-exclusive, world-
[17:04] <_Andrew> wide, royalty free licensee for redistributing Cg with your applications. See this license for
[17:04] <_Andrew> details.
[17:04] <persia> _Andrew, It's in /usr/loca/Cg/docs/license.txt in the full Cg toolkit download.
[17:05] <persia> That's even better.  I suspect that you've found a solution (and that the license has been changed since I last looked).  Try adjusting the packaging to be based on something redistributable, and if you can get that working, let the Debian maintainer know.  It's too late to try to fix this for intrepid, but it can surely be fixed for jaunty, and the best way to do that now is by fixing it in Debian.
[17:08] <_Andrew> Since no packages depend on the nvidia-cg-toolkit can't we make an exception for intrepid?
[17:08] <_Andrew> Its just a download, you don't need to build anything
[17:10] <persia> _Andrew, You can request one, but I'd be surprised if the release managers approved it : it's a major repackaging effort.
[17:11] <persia> The fact that nothing is rebuilt, and that all the reverse-build-depends are broken currently anyway might help.  If you can get it working in the next couple days, it's probably worth requesting an exception, but don't count on getting approved.
[17:13] <_Andrew> When you say get it working, you mean build my own package into ppa?
[17:15] <persia> That would be one way to do it.  Getting debian/copyright correct and verifiable is going to be tricky, as will getting dh_install to put everything in the right place, but the rest should be fairly trivial, and you can drop the fancy really-install-the-package from the postinst.
[17:16] <persia> You're also going to have to have an interesting get-orig-source rule, as you'll want to pull both the 32- and 64-bit binaries from nvidia, and bundle them, and then install the right set at package build-time.
[17:16] <persia> Doesn't really matter if you put it in a PPA or somewhere else, as long as it's in a format the release managers can review and determine if they will accept.
[17:20] <jdong> oh. that's disappointing. FTBFS at the last dh_install of a 2hr build.
[17:31] <ScottK> james_w: If the clutter packages are bugfix only, you don't need to subscribe motu-release.
[17:32] <james_w> ScottK: the first two were, but there is one new feature in -gtk
[17:32] <james_w> I can retitle the report if you like
[17:32] <ScottK> james_w: I think that'd be good.  I read the title and thought I could ignore it.
[17:33] <_Andrew> Oh wow the nvidia package install the 2004 version of cg.. lol, so old
[17:33] <james_w> ScottK: yeah, done now, sorry
[17:33] <persia> _Andrew, If you update, do make sure it still works with ogre.  If not, it's hardly worth it.
[17:34] <_Andrew> Yeah I know it works because I have been compiling here for awhile
[17:34] <persia> _Andrew, with the newest Cg toolkit?
[17:35] <james_w> anybody understand -meta packages?
[17:35] <james_w> bug 284497
[17:35] <_Andrew> persia: yes
[17:36] <persia> james_w, txwikinger is chasing that.
[17:36] <james_w> great
[17:36] <ScottK> james_w: I'm about to sponsor that.
[17:36] <_Andrew> persia: I'll check it again though
[17:36] <james_w> thanks ScottK
[17:36] <ScottK> We're discussing it on #kubuntu-devel (It's a KDE oriented derivative)
[17:37] <txwikinger> hi persia o/
[17:38] <james_w> \o/ import finished
[17:39] <persia> txwikinger, Hey.
[17:41] <persia> Anyone know octave?  http://people.ubuntu.com/~ubuntu-archive/NBS/libhdf5-serial-1.6.5-0 needs help.
[17:44] <jcastro> crimsun: are your slides from your talk available anywhere?
[17:47] <lfaraone> hey crimsun !
[18:01] <postalchris> Where can I get advice about whether a project's license is compatible with packaging the project for Ubuntu?
[18:02] <persia> postalchris, You can ask here, and we can give you an unofficial answer.
[18:03] <persia> An official answer can only come from the archive admins, but they tend to review licenses only when a package is otherwise in perfect shape.
[18:04] <postalchris> OK. I have reason to believe it might be problematic, bc apparently the same package was rejected from Fedora for licensing issues...
[18:04] <postalchris> The license is here: http://www.cs.nyu.edu/acsys/cvc3/doc/LICENSE.html
[18:05] <postalchris> And here's a log post about the Fedora issues: http://www.dwheeler.com/blog/2008/08/20#license-proliferation
[18:05] <persia> OK.  Section 3 can be problematic, but there are known workarounds.
[18:07] <persia> Personally, I don't get the same meaning as that blog post.
[18:07] <postalchris> Me neither, but IANAL.
[18:07] <postalchris> I think it's the indemnity clause that he's referring to.
[18:08] <persia> I read "LICENSEE shall indemnify, hold hardmelss and defend ..." as meaning that if something goes wrong, you can't sue upstream, and if you redistribute, and someone sues you and upstream, you must defend both cases.
[18:10] <persia> Mind you, unless I misunderstand, due to the section 4 "this probably doesn't work, and might infringe on a patent" clause, it's unlikely to get anything other than a request to cease distributing or a recall.
[18:12] <postalchris> That all sounds reasonable to me. What restrictions does Ubuntu have on project licenses?
[18:13] <persia> Hrm.  You'll want to delete the SAT solver zchaff stuff though.  That's not going to be acceptable (internal use typically prohibits redistribution)
[18:14] <persia> postalchris, Generally, the requirements are the same as the Debian Free Software Guidelines.  There are a couple licenses on which Debian and Ubuntu differ.
[18:14] <persia> (like CC 2.0 or GFDL)
[18:14] <persia> But it's a difference in interpretation, rather than a difference in the guidelines.
[18:15] <postalchris> OK. So a package would have to strip out and/or disable zchaff, bc it's not redistributable?
[18:16] <persia> If I were packaging it, I'd strip that out because I wouldn't feel comfortable distributing my package to Ubuntu with those files.
[18:17] <persia> http://www.cs.nyu.edu/acsys/cvc3/doc/xchaff__base_8h-source.html just doesn't look like something that permits distribution.
[18:18] <postalchris> But if the package is "original tarball + patch that deletes zchaff files", isn't that redistribution?
[18:19] <persia> Were I doing this, I'd write a debian/rules get-orig-source rule that generated a modified original tarball.
[18:19] <ScottK> No, you need to repack the tarball and remove the file so the tarball is distributable.
[18:19] <persia> Normally, this is a bad idea, but in this case, I think it's required if this is to be packaged.
[18:20] <persia> ScottK, I've been told there is a patch for Japanese localisation of clamtk floating about, but I can't seem to find it.  Have you heard of such a thing, and would you know if it was applied?
[18:20] <ScottK> No and No.
[18:21] <persia> heh.  Given the second, the first isn't surprising.  Thanks.
[18:22] <postalchris> Thanks guys. If I understand correctly, the (main) license isn't a deal-breaker. I'll look into this some more.
[18:26] <persia> postalchris, It is different than normal, so it may take quite a while for the archive-admins to review and approve/deny.  I'd recommend that if you want it in, you try to get it added to the queue for jaunty as early as possible (preferably mid-november to early-december)
[18:29] <emh> persia: xprintidle 0.2 is due for debian experimental. lenny is frozen.
[18:31] <persia> emh, Good work.  Intrepid just froze about 8 hours ago, so it should be an autosync for jaunty.  Nice job working with all the parties to get that fixed.
[18:52] <rainct> ScottK: have you seen the "*" note on my mail?)
[19:02] <ScottK> rainct: No.  I hadn't.  Need to read the whole message.  Sorry.
[19:02] <stefanlsd> Does anyone know what happened / how to run db_unregister
[19:04] <stefanlsd> ooh, its a function of debconf
[19:07] <rainct> ScottK: Heh. No problem :).   It's not that I mind much about it, but I think it makes more sense to have such requests on Brainstorm
[19:15] <ScottK> rainct: I guess.  Personally I don't look there, but I suppose others do.
[19:17] <fabrice_sp> Hi. Is it still possible to include the fix for Bug #283717 in Intrepid? I've just uploaded the debdiff
[19:18] <fabrice_sp> (only a patch to b3)
[19:20] <stefanlsd> Does anyone have an idea why i would be getting /var/lib/dpkg/info/bugzilla3.postrm: 1: db_unregister: not found (multiple times) - http://pastebin.ubuntu.com/58461/ (debug output)
[19:22] <crimsun> jcastro: I dented you the URL yesterday...
[19:23] <jcastro> crimsun: oh, thanks!
[19:23] <jcastro> fell off my gwibber scrollbar. :-/
[19:24] <stefanlsd> james_w: you around?
[20:10] <crimsun> jdong: mind approving the patch in bug 132133, please?  if so, please sponsor.
[20:11] <jdong> crimsun: you mean if not, please sponsor, correct? :). Grammar nazi aside, the patch looks good to me; I'll test & sponsor.
[20:14] <stefanlsd> crimsun: i see you did a couple of updates to flashplugin-nonfree - do you know how you managed to get the direct download link for flash player?  cant seem to get it...
[20:14] <crimsun> stefanlsd: I use the link for the tar.gz
[20:15] <crimsun> jdong: thanks
[20:17] <stefanlsd> crimsun: current one is - http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_10_linux.tar.gz - which is suspect is always linked to the latest
[20:21] <crimsun> stefanlsd: perhaps it is now the permanent link, but I always confirm the URL's validity.
[20:22] <psusi> it appears that the defrag package is missing from hardy and intrepid... according to the launchpad page on the source package, it was "superseded" in hardy... what does this mean?
[20:22] <slytherin> psusi: superceeded simply means a new version was packaged.
[20:22] <psusi> slytherin: but there isn't a newer one...
[20:23] <psusi> it simply was dropped it looks like
[20:23] <slytherin> psusi: can you point me to the link?
[20:23] <psusi> https://launchpad.net/ubuntu/+source/defrag
[20:23] <crimsun> psusi: you'll need to ask if it was removed from the archive
[20:23] <psusi> and packages.ubuntu.com doesn't find it in hardy or later
[20:24] <psusi> it looks to me like it has been... but how do I see when and why and how to undo that?
[20:24] <crimsun> psusi: please ask an archive admin in -devel
[20:25] <psusi> hrm... ok
[20:25] <crimsun> (sorry, I don't know offhand if there are new notifications, etc.)
[21:05] <james_w> hey stefanlsd
[21:06] <stefanlsd> james_w: heys. bugzilla3.  it works for me when i use dbconfig, and yeah. fails for me when i dont - you get the same result?
[21:07] <ajmitch_>  /win 21
[21:08]  * ajmitch_ blames irssi
[21:08] <james_w> stefanlsd: not tried with dbconfig
[21:08] <milli> ScottK: around?
[21:08] <ScottK> Yes
[21:09] <milli> what's it take to get xserver-xorg-video-radeonhd version 1.2.3 into Interpid at this point?
[21:09] <milli> I've been using it for a week now without any problems... it has 3D acceleration in it and XVideo support!
[21:10] <milli> version 1.2.1 is what's in Interpid right now, with no 3D support
[21:10] <ScottK> milli: I think we have 1.2.1
[21:10] <milli> (this is an alternative to using fglrx driver for recent ATI chipsets)
[21:10] <milli> I also notice that 1.2.3 is not even in Debian experimental....
[21:11] <ScottK> milli: It's in Main, so unless there is something actually release critical, pretty well zero.
[21:11] <milli> I'd call 3D support release critical...  ;-)
[21:11] <milli> or not
[21:12] <milli> np, I can live with building my own packages
[21:12] <ScottK> tseliot or superm1: Do you know anything about this one^^
[21:12] <milli> would be nice to have a 3D alternative to fglrx that's working today
[21:13] <tseliot> ScottK: that's something Bryce deals with
[21:13] <ajmitch> problem is the possibility of regressions on all the other ATI chipsets that may be around
[21:13] <milli> I added a note here -->  http://www.thinkwiki.org/wiki/ATI_Mobility_FireGL_V5200
[21:13] <ajmitch> because drivers are so much fun
[21:13] <milli> that I will have to amend
[21:14] <tseliot> milli: maybe try asking bryce in #ubuntu-x
[21:14] <milli> ajmitch: nod, what I figured...  it works perfectly on an M56 core fwiw
[21:14] <milli> tseliot: nod
[21:14]  * ajmitch doesn't even know what driver would be suitable for this old card
[21:15] <stefanlsd> james_w: kk. can you try and edit /etc/bugzilla3/localconfig  and change db_check = 0 ..
[21:15] <james_w> stefanlsd: I'm trying again with dbconfig
[21:15] <james_w> stefanlsd: I'll be with you in a minute
[21:15] <stefanlsd> james_w: kk
[21:16] <tseliot> ScottK: can you have a look at my SRU, please? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/261816
[21:16] <tseliot> ScottK: it's just a bugfix in a postinst which I backported from Intrepid to Hardy
[21:17] <ScottK> tseliot: I'm not in the SRU team.
[21:18] <tseliot> ScottK: no? I thought you were a member of motu-sru
[21:19] <ScottK> I was, but no longer.
[21:20] <tseliot> aah
[21:20] <tseliot> ok, thanks anyway
[21:24] <james_w> stefanlsd: still fails
[21:24] <stefanlsd> james_w: db_check or dbconfig?
[21:25] <james_w> stefanlsd: apparently because it can't connect to a local mysql server
[21:26] <james_w> morgs: hi, I don't mind you subscribing me to your sponsor requests, but please also subscribe the sponsor team as normal so that they don't get dropped
[21:26] <stefanlsd> james_w:  dbconfig failing or db_check = 0 still failing?
[21:27] <james_w> http://paste.ubuntu.com/58513/
[21:28] <stefanlsd> james_w: mysql running?
[21:28] <james_w> nope
[21:31] <stefanlsd> james_w: k. works on my intrepid, gonna test it in pbuilder chroot now
[21:35] <stefanlsd> james_w: heh. i see mysql-server is in the recommends (along with postgres)
[22:09] <sebner> wb geser :)
[22:24] <geser> Hi sebner