[00:43] <Jimerson> Good Evening All.
[00:45] <Jimerson> I have some questions about sponsorship, I have read through the wiki, and I have some questions if someone is willing to help me.
[00:56] <rick_h_> jcastro: you see the video of the new rythmbox plugin?   I hope physics lives fine.
[01:52] <Jimerson> I have some questions on sponsorship, I have read the wiki's information and would like to talk to someone about it.
[01:52] <Hobbsee> shoot :
[01:53] <Jimerson> Your following me :)
[01:53] <Jimerson> Hobbsee: mind if I pm you?
[01:53]  * Hobbsee is omnipotent :)
[01:53] <Hobbsee> Jimerson: would prefer you to ask in here, then multiple people can answer
[01:53]  * Hobbsee is a bad mentor, tbh.
[01:53] <persia> Jimerson: It's generally best to ask any questions in-channel, and not to specific people, so everyone can learn.
[01:53] <eneko_tab> we are trying to relaunch the Ubuntu Home Server project as it seems death
[01:54] <eneko_tab> UHS would be analog to the windows home server
[01:54]  * Hobbsee wonders how that fits in with ubuntu server.
[01:54] <StevenK> persia: Your make foo fails!
[01:54] <eneko_tab> however, we need help specially in the management
[01:54] <Jimerson> Fair enough. I have not really found any information on how to find a sponsor, I am new to this, and am interested in helping, just need a kick in the right direction.
[01:54] <StevenK> persia: make says "The directory exists, so I don't need to do anything"
[01:54] <persia> StevenK: Hrm?  Which part?
[01:54] <Hobbsee> Jimerson: got a bug in particular, or wanting to know in general?
[01:54] <StevenK> persia: The $(MAKE_DIRS) bit
[01:55] <Jimerson> Hobbsee: general.
[01:55] <persia> StevenK: Did you not add $(MAKE_DIRS) as a dependency of .PHONY?
[01:55] <Hobbsee> Jimerson: you usually just make sure the patch is correct, and subscribe ubuntu-universe-sponsors
[01:55] <jdong> stupid GPG question: can I have GPG show "info" about an encrypted file or signature (i.e. who signed it, who's it encrypted to, etc)
[01:55] <StevenK> persia: Oh, was I supposed to? :-)
[01:55] <persia> Jimerson: You don't need to find a sponsor: the sponsors need to find your patches.  This is done with bug subscriptions.
[01:55] <eneko_tab> anyone is experienced managing an open source sw prject?
[01:55] <Hobbsee> jdong: you can do gpg --validate-sig or something, for the first.
[01:55] <persia> StevenK: Sorry: I was tired last night.  Yes, if you don't want it to block on timestamps :)
[01:56] <Hobbsee> jdong: i dont think that's right, but it's close enough that the man page should help
[01:56] <Jimerson> persia: where is a good place to get started.
[01:56] <Hobbsee> eneko_tab: we're MOTU's.  we manage universe ;)
[01:56] <jdong> Hobbsee: hmm I'm perusing thru the manpage currently
[01:56] <Hobbsee> silly question.
[01:56] <persia> Jimerson: What do you seek to accomplish?
[01:56] <Hobbsee> jdong: gpg --verify
[01:57] <Hobbsee> i was close :)
[01:57] <Jimerson> persia: to help in any way that I can, does not matter to me what I accomplish, I would just like to give something back wherever it is needed.
[01:57] <jdong> Hobbsee: ah, ok
[01:57] <Hobbsee> jdong: no idea on who it's encrypted to.  i've not had to use it.
[01:58] <persia> Jimerson: If you want to help MOTU, the best ways are 1) bug triage, 2) patches, and 3) Preparing candidate revisions with the patches to close the bugs.  There's an overview at https://wiki.ubuntu.com/MOTU/Contributing
[01:59] <persia> Jimerson: I'd suggest starting with #1, doing #2 when there's an obvious solution, and doing #3 when you've a package where you can close a few of the bugs due to #2.
[02:00] <Jimerson> persia: Thank you for your answers and time.
[02:08] <bddebian> Heya gang
[02:45] <Hobbsee> TheMuso: for u-u-s fun - all of http://tinyurl.com/2nynzm
[02:45] <Hobbsee> TheMuso: that's a list fo bugs that have patches associated.  the users presumably havent subscribed the sponsorship team.  just if you get bored
[02:45] <Hobbsee> persia: ^ bluekuja
[02:46] <persia> Hobbsee: Yep.  There's a link there from qa.ubuntuwire.com :)  Part of the issue is that most of those patches aren't debdiffs.  I'd say they aren't appropriate for sponsorship, although they are certainly appropriate for regular MOTU updates (just a different hat).
[02:47] <Hobbsee> persia: might be a good thing for new people to do
[02:47] <Hobbsee> that way they don't have to write the code themselves, but take the patch and apply it.
[02:47] <bddebian> Heya persia, Hobbsee
[02:47] <persia> Hobbsee: Absolutely.
[02:47] <Hobbsee> hi bddebian
[02:47] <persia> Hi bddebian
[02:47] <Hobbsee> bddebian: right, youv'e got a job.
[02:48] <persia> bddebian: 1500 patches that need debdiffs & uploads (or just flat rejection) :)
[02:48] <Hobbsee> no, not quite that
[02:48] <Hobbsee> to write the documentation, and help new people out with applying them.
[02:48] <bddebian> Huh?
[02:49] <ajmitch> bddebian: hop to it, before you get beaten
[02:49]  * persia suggests that editing https://wiki.ubuntu.com/MOTU/Contributing might be a good way to do that, but thinks most of it is already there
[02:50] <bddebian> What am I doing?
[02:50] <ajmitch> everything
[02:50] <persia> bddebian: You're the new meta-MOTU: you get to make sure everything gets done :)
[02:50] <ajmitch> more specifically, taking patches that aren't on the u-u-s watchlist
[02:51] <bddebian> hahaha
[02:52] <ajmitch> bddebian: you seem to think that we're joking?
[02:52] <bddebian> You must be since you all know that I suck :)
[02:53] <ajmitch> no, this is a way to shut you up & keep you so busy that you can't complain about sucking or being stupid :)
[02:54] <bddebian> hah
[03:02] <TheMuso> Hobbsee: Thanks.
[03:34] <LaserJock> man I love merging hugemongous packages :/
[03:34] <bddebian> heh
[03:34] <bddebian> As much as I love reviewing crappy ones? :-)
[03:35] <LaserJock> running grab-merge.sh on gcompris is gonna take almost 400MB
[03:35] <StevenK> Mmmm, yummy
[03:35] <StevenK> LaserJock: Ponies!
[03:35]  * StevenK works on giving LaserJock a complex some more
[03:36] <Hobbsee> yay, ponies!
[03:40]  * LaserJock twitches
[03:53] <bddebian> Jesus, could we get a few more packages on REVU please?
[03:54] <StevenK> Sure.
[03:54] <LaserJock> I'm sure that could be arranged
[03:55]  * imbrandon uploads 40 more
[03:55] <bddebian> That's just 40 more that will get ignored ;-P
[03:56] <imbrandon> maybe REVU should be wiped at every FF ( e.g. start clean for the next release )
[03:56] <imbrandon> atleaste all packages "archived" , thus a new upload will bring them back
[03:58] <Hobbsee> imbrandon: that was the plan
[03:58] <Hobbsee> but people started uploading stuff for hardy, during gutsy.
[03:59] <imbrandon> ahh then those people need to have gotten a "too bad" when they asked what happened :)
[03:59] <imbrandon> lol
[03:59] <imbrandon> btw hiya *
[04:00] <Hobbsee> greetings :)
[04:00] <bddebian> wtf: aswvdial_0.1patch2.dsc
[04:01] <imbrandon> heh
[04:05] <bddebian> Well that was worth wasting my time on
[04:12] <mdomsch> for uploads to REVU, do we have to change debian/changelog to use hardy now, or can it remain as gutsy?
[04:12] <bddebian> Hardy
[04:13] <StevenK> mdomsch: If you upload as Gutsy, Soyuz will yell at you.
[04:14] <persia> mdomsch: Just to make sure, are you considering an upload of a candidate for hardy, or a candidate for gutsy?
[04:14] <mdomsch> hardy most likely, though Dell will likely publish the packages for feisty and gutsy too
[04:14] <mdomsch> firmware-tools and firmware-addon-dell for flashing BIOS
[04:15] <persia> mdomsch: Hmm...  Is there a backporting / update policy for the Dell repos?
[04:15] <imbrandon> i would target hardy then -backport it
[04:15] <imbrandon> Dell has seperate repos? why
[04:15]  * persia tends to agree with imbrandon, but it may depend on Dell policies
[04:16] <persia> imbrandon: Special add-ons which we don't have or want yet.
[04:16] <mdomsch> we don't have policies yet, we haven't published debs yet
[04:16] <mdomsch> but we do publish rpms for other distros/versions
[04:16]  * bddebian covers his ears
[04:16] <mdomsch> :-)
[04:16] <imbrandon> mdomsch: assuming your part of the DELL team i would closely follow the Ubuntu policy ( or atleaste have a good reason not to )
[04:17] <mdomsch> imbrandon, yes, which is why I'm asking and trying to understand
[04:17] <Hobbsee> mdomsch: this is the problme that you need to sign with the dell key, isnt it?
[04:17] <mdomsch> I believe no more new packages will be accepted for feisty and gutsy via MOTU
[04:17] <persia> mdomsch: I'm generally in favor of using distro releases when feasible, so in this case, I'd suggest an upload to hardy, and performing the backport for the others.
[04:17] <imbrandon> :) mdomsch normaly it would be targeted at the current development release, then semi automaticly added to -backports after a but of testing
[04:17] <mdomsch> yet those are the releases we're shipping now or will soon
[04:18] <Hobbsee> mdomsch: correct, but you're dell.  so it's probably possible to mangle things.
[04:18] <Hobbsee> assuming soyuz doesnt blow up.
[04:18] <imbrandon> mdomsch: technicly yes, but new {feisty,gusty}-backports can happen
[04:18] <mdomsch> ahh, -backports - I hadn't seen that
[04:18] <imbrandon> :)
[04:18] <Hobbsee> mdomsch: would the hardy/gutsy/feisty packages be the same?
[04:19] <Hobbsee> imbrandon: except that a lot don't use backports, so -updates might be smarter.
[04:19] <mdomsch> Hobbsee, certainly same source; most likely different packages due to different python versions
[04:19] <imbrandon> Hobbsee: this is for dell, theey can enable -backports if they want :)
[04:19]  * persia votes for -updates with special pleading to the archive-admins
[04:19] <mdomsch> which is fine by me
[04:19] <mdomsch> imbrandon, Hobbsee, if it's not enabled by default, we haven't enabled it in our factory images
[04:19] <imbrandon> mdomsch: will python-central python-support not take care of the versioning diffrences ?
[04:20] <Hobbsee> imbrandon: then i dont want to see a repeat of the flashplugin fiasco.
[04:20] <persia> imbrandon: True, but it's "Community Support": do you want backports by default?
[04:20] <mdomsch> oh, that's right - debs build the .pyc files at install time
[04:20] <imbrandon> persia: personaly since i'm on the backports team it wouldent bother me, but i see your point
[04:20] <mdomsch> then the same package will probably work on all
[04:20] <persia> mdomsch: Right.  .py is distributed, and .pyc is local.
[04:20] <Hobbsee> mdomsch: right.  then throw it into hardy, and then get the archive admins to copy it to the other releases.
[04:20] <mdomsch> persia, fedora does that different, fwiw
[04:20] <Hobbsee> abuse of power, but oh well.
[04:21] <persia> mdomsch: So does everyone not debian-derived :)
[04:21] <imbrandon> heh yea ubuntu == <3
[04:21]  * mdomsch tries to understand and follow the rules before discarding them
[04:21] <imbrandon> well you've come to the correct place :)
[04:21] <Hobbsee> mdomsch: the rules are "no new packages to released versions, unless they fit !sru, unless there's a damned good reason.  assuming the build system wont curl up in a ball and die"
[04:22] <Hobbsee> in a nutshell, that's the rule
[04:22] <Hobbsee> easiest way to get something in is to get it into the development version, then get it backported.
[04:22] <Hobbsee> or, in special cases as this, copied, so it appears in -updates
[04:22] <imbrandon> and persia fwiw i did do a fresh install of gutsy for my step-dad tonight ( converting him from vista w00t ) and multiverse is indeed on
[04:22] <Hobbsee> does the help?
[04:23] <mdomsch> now for backports, do I or do I not have to edit debian/changelog to s/hardy/gutsy/ ?
[04:23] <mdomsch> if it's just a file copy on the archive, I assume no
[04:23] <imbrandon> you dont, its automagic
[04:23] <mdomsch> cool
[04:23] <Hobbsee> mdomsch: it would be to gutsy-backports anyway.  </pedant>
[04:23] <imbrandon> assuming no source changes are needed etc etc etc
[04:24] <Hobbsee> i dont think you *can* upload to gutsy anymore, without the build system blowing up.
[04:24] <Hobbsee> i think it has to be -updates or -backports
[04:24] <imbrandon> if source changes are needed then a direct upload to -backports is required and alot of a$$ kissing to the archive team
[04:24] <Hobbsee> imbrandon: chocolate accepted.  :)
[04:24] <imbrandon> heh
[04:24] <Hobbsee> other bribes also accepted.
[04:25] <persia> imbrandon: Thanks for the confirmation.  I think that's broken, but will wait until I'm organised to complain.
[04:25] <Hobbsee> imbrandon: just none of multiverse is used by default.
[04:25] <imbrandon> correct
[04:25] <Hobbsee> i guess that makes sense - the first step in any ubuntu script is to enable universe, do an update, then install the required codec
[04:25] <imbrandon> nothing is used, and i 1000% agree with the way it is
[04:25] <imbrandon> Hobbsee: right
[04:26] <imbrandon> but we had this "disscussion" the other nigth
[04:26] <imbrandon> night*
[04:26] <Hobbsee> ah right.  i was probably "studying"
[04:26] <imbrandon> i 1000% agree it should be on but nothing installed from it, saves tons of support
[04:26] <Hobbsee> heh
[04:27]  * Hobbsee just wants to know how people randomly manage to remove parts of their kernel.
[04:27] <persia> Whereas I believe that due to the questionable nature of some of the contents, there should be a click-through at least.
[04:27] <persia> Hobbsee: rm?
[04:27] <StevenK> Hobbsee: Wielding sudo mv/rm ?
[04:27] <tonyyarusso> Hobbsee: I dd zeros in the middle of it.
[04:27]  * StevenK high fives persia
[04:27] <imbrandon> persia: thats easy to fix, if its questionable dont put it in the archive :)
[04:27] <persia> Tonio_: That's living dangerously :)
[04:27] <Hobbsee> haha
[04:28] <Hobbsee> no, they seem to remove the generic kernel package.  and then whine that they have no l-u-m, so their card doesnt work.
[04:28] <Hobbsee> the stuff is seeded, it's on installs, it's mandatory to have it for upgrades...yet somehow people still file bugs due to not having it.  *sigh*
[04:29] <imbrandon> they might be manualy installing a -rt or kernel image , e.g. linux-image-2.X.X-rt not the meta package
[04:29] <imbrandon> that woudl do it
[04:29] <Hobbsee> hm, yeah, could do.
[04:30] <persia> imbrandon: I'll also agree with that, but https://lists.ubuntu.com/archives/motu-council/2007-November/000512.html is authoritative today.
[04:30] <imbrandon> sure
[04:39] <LaserJock> persia: authoritative regarding what?
[04:39] <persia> LaserJock: Multiverse inclusion policy
[04:39] <LaserJock> persia: there wasn't much said
[04:40] <persia> LaserJock: To give context, last week imbrandon and I were debating whether multiverse should be configured by default.
[04:40] <LaserJock> ah
[04:41] <LaserJock> I thought mayber we were back to Windows binaries
[04:41] <LaserJock> *maybe
[04:41] <bddebian> heh
[04:41] <persia> Essentially, imbrandon's position is that it's a support nightmare to explain to each and every user how to enable multiverse, and it's my position that parts of multiverse are possibly inappropriate for some uses.  We're both right, but it doesn't help that there are no restrictions on multiverse inclusion.
[04:42] <persia> LaserJock: Related, but not the current topic of debate.  The policy I cited applies in both cases.
[04:42] <LaserJock> well, kinda
[04:43] <LaserJock> somebody really needs to respond to that thread
[04:43] <LaserJock> I don't think anybody knows what it was about
[04:43] <imbrandon> what thread?
[04:43] <persia> LaserJock: I disagree that the thread needs a response.  Someone needs to define a reasonable goal for multiverse, and promote that set of criteria.
[04:43] <LaserJock> imbrandon: https://lists.ubuntu.com/archives/motu-council/2007-November/000498.html
[04:43] <persia> If approved, the thread can be revisited.
[04:44] <LaserJock> persia: they don't know about it
[04:44] <LaserJock> I talked to dholbach
[04:44] <persia> LaserJock: Who doesn't know about it?
[04:44] <LaserJock> and he didn't know what was going on
[04:44] <LaserJock> he thought it was just non-free stuff
[04:44] <persia> Right.  And pq has an advocate on REVU.
[04:44] <LaserJock> which of course is fine fore Multiverse
[04:44] <LaserJock> *for
[04:44] <LaserJock> the question is specifically about Windows binaries
[04:44] <LaserJock> and that *hasn't* been brought up
[04:45] <persia> LaserJock: Thanks for the heads-up: I thought this was intentional.  I've a draft I've been not posting, and will send it wiithin the next 12 hours.
[04:45] <imbrandon> LaserJock: what makes a diffrence if its a windows binary or a BSD binary etc ? if its distributable
[04:45] <LaserJock> and dholbach was like, "why hasn't anybody said anything then?"
[04:45] <LaserJock> imbrandon: some MOTUs are concerned about security, viruses, etc.
[04:46] <imbrandon> ok then take wine out, wtf
[04:46] <persia> Because Toni reported it as a Windows binary in the blob post.
[04:46] <imbrandon> that makes no sense
[04:46] <persia> imbrandon: I'm not opposed to wine, or windows binaries, but I can't support them.  That's the essence of my point.
[04:46] <LaserJock> imbrandon: because it's a slipper slope according to crimsun
[04:47] <LaserJock> *slippery
[04:47] <imbrandon> LaserJock: the slope was choosen when we put wine in, i mean you cant give somone a tool and expect them not to use it
[04:47] <LaserJock> no
[04:47] <LaserJock> but that doesn't mean we have to have packages for it
[04:47] <LaserJock> we have 0install
[04:48] <TheMuso> Yay. Storm coming.
[04:48] <LaserJock> but we don't provide 0install packages
[04:48]  * persia still thinks there is a difference between supporting user-insalled Windows software and distributing Windows software.
[04:48] <LaserJock> in any case, the objection was brought up
[04:48] <LaserJock> several MOTUs had problems with it
[04:48] <StevenK> TheMuso: Really? Still bright and sunny here
[04:49] <LaserJock> so we should have some sort of discussion and resolution of the issue
[04:49] <TheMuso> StevenK: Yeah. Cloudi is building up, and thunder can be heard.
[04:49] <imbrandon> persia: i think you mix up supporting the packaging and supporting a program, very few is ANY programs we support as the coomunity, i've seen you make that statement before and it baffles me
[04:50] <imbrandon> LaserJock: i thought the resolution was pretty clear when mdz said "if its distributeable"
[04:50] <LaserJock> I honestly don't care what the resolution is, I just think we should have some sort of policy
[04:50] <persia> imbrandon: When I have time, I try to fix all the bugs I can.  I further try to help users to use the software, and make sure it works.  90% off the stuff I investigate is for packages I will never use, sometimes in languages I do not know.
[04:50] <LaserJock> imbrandon: well, not exactly
[04:50] <persia> I try to provide support.  I do not require you to do so, but I do expect that you will not make it harder for me to do so.
[04:50] <imbrandon> LaserJock: how is that not clear ? seems cut and dry to me
[04:51] <StevenK> TheMuso: Neat. Hopefully it won't end up as muggy as it was yesterday
[04:51] <persia> LaserJock: We do have a policy.  The last message in the thread is authoritative.
[04:51] <TheMuso> StevenK: Yeah.
[04:51] <LaserJock> persia: I don't think it exactly is
[04:51] <imbrandon> persia: and i also like to make the end user experince for adding new software easy, i dont ask you to support it either
[04:51] <imbrandon> same other reverse
[04:51] <imbrandon> only*
[04:51] <LaserJock> it was stated that Debian wouldn't take it
[04:52] <persia> imbrandon: Actually, you do :), but that's a different issue (and I don't mind)
[04:52] <LaserJock> and since that was the criteria for the policy we have
[04:52] <imbrandon> LaserJock: how is it not, its from the CEO of canonical and a member of .....
[04:52] <persia> LaserJock: Ah.  Good point.  That means it's not acceptable to us.
[04:52] <LaserJock> imbrandon: if they didn't know the specifics
[04:52] <LaserJock> bah
[04:53] <persia> LaserJock: You might want to leave a comment on the REVU entry...
[04:53] <imbrandon> we have firmware and other bits ( firefox ) that debian wont take, we're != debian
[04:53] <imbrandon> LaserJock: they dont have to know the specifics
[04:53] <imbrandon> you think someone will change their mind because its a BSD or SUNOS or $other binary ? wtf
[04:53] <LaserJock> yes
[04:54] <LaserJock> well many MOTUs felt so
[04:54] <LaserJock> so it's worth addressing
[04:54] <LaserJock> from mdz: My implicit policy for multiverse has always been that it must be
[04:54] <LaserJock> distributable, and little else.  It was modeled after Debian non-free, which
[04:54] <persia> I don't think the source of the binary matters: I'd be just as opposed to a new BSD or SunOS binary.
[04:54] <imbrandon> wtf so inclusion would read "if its distributable but not built on Windows"
[04:54] <LaserJock> is similarly defined (everything which doesn't meet the DFSG but is still
[04:54] <imbrandon> what if its a reactos binary?
[04:54] <LaserJock> distributed by Debian).
[04:55] <LaserJock> the point being that Multiverse is modeled after Debian non-free
[04:55] <LaserJock> and several people said that Debian would never take this package
[04:55] <imbrandon> yes but not byte for byte, just as ubuntu != debian
[04:55] <LaserJock> so it's *worth* discussing for goodness sakes
[04:55] <LaserJock> I honestly don't care about the outcome
[04:56] <LaserJock> but I really feel like we need so real resolution
[04:56] <imbrandon> and it was, and because the awnser wasent liked it has to be driven out, thats what i'm getting at, a specific question was asked "what is the inclusion policy" and one was give, it falls in that so whats the problem
[04:56] <LaserJock> imbrandon: the question is specifically about Windows binaries
[04:56] <persia> LaserJock: I'm not sure we don't have real resolution at this point.  I don't understand how the last message isn't clear, and I don't understand why only Windows is bad.
[04:57] <LaserJock> because when I talked with dholbach he was like "oh, I didn't know that that was about"
[04:57] <LaserJock> I think they thought it was just the usual thing
[04:57] <LaserJock> which we all know
[04:57] <persia> LaserJock: Check with elmo: that's the only person who needed to know.
[04:57] <imbrandon> omfg listen to the words i'm saying LaserJock , one second, listen to me , the specific question was "what is the multiverse inclusion policy" and that windows binary falls into it, NOW if you want to bring up a second question or exception fine, but the decision is very clear IMHO
[04:58] <LaserJock> imbrandon: but that was *not* the question
[04:58]  * persia agrees with imbrandon despite not agreeing with the decision
[04:58] <imbrandon> LaserJock: it WAS https://lists.ubuntu.com/archives/motu-council/2007-November/000498.html
[04:58] <imbrandon> ^^ READ
[04:58] <LaserJock> imbrandon: that was the guy who's trying to push his stuff
[04:58] <imbrandon> and?
[04:58] <LaserJock> he *nowhere* mentions the stuff that crimsun and the other guys talked about
[04:59] <imbrandon> err shit wrong link
[04:59] <LaserJock> they know the multiverse policy as much as everybody else
[04:59] <persia> LaserJock: So, what does that matter.  Interested party asks project leader.  Project leader identifies delegate.  Delegate publishes policy.
[04:59] <LaserJock> bahhhh
[04:59] <LaserJock> screw it
[04:59] <imbrandon> LaserJock: mdz stated "any thing thats distributweable"
[04:59]  * mdomsch uploads firmware-tools and firmware-addon-dell to REVU
[04:59] <LaserJock> imbrandon: I know, but I don't feel like he looked at the issue
[05:00] <LaserJock> I just want to be sure
[05:00] <LaserJock> but well, it's not my package and I don't care about this at all
[05:00] <LaserJock> I just want to make sure that the objections that people had are addressed
[05:00] <persia> LaserJock: Please, I do agree that the policy needs to be redefined, I just don't think that is the place to argume about it.  I think a wiki draft policy, review by MC, and presentation to TB would have a greater chance of accomplishing something.
[05:00]  * mebrown says thanks to mdomsch...
[05:00] <imbrandon> LaserJock: what issue, i think he looked at it very clearly, its not a question if X can be included, its a question of what can be, you cant do every package on a case by case you have to follow or change the policy
[05:01] <LaserJock> persia: that's what I'm trying to do!!!!!
[05:02] <persia> LaserJock: Ah.  My misunderstanding.  From your notes above, I had the impression you were arguing with the process for establishing the current policy.
[05:02] <imbrandon> LaserJock: and if that is the case then all firmware will have to be removed because it was built on and for windows to be used by those drivers
[05:02] <LaserJock> I'm saying that this hasn't been properly addressed
[05:02] <LaserJock> the guy sent an email to Mark
[05:02] <LaserJock> who then CCd the MC
[05:03] <LaserJock> it's not addressing the issue that MOTUs had
[05:03] <imbrandon> LaserJock: you are looking at the wrong email, you should be looking at the one titled "multiverse inclusion policy"
[05:03] <LaserJock> imbrandon: I am looking at it
[05:03] <imbrandon> LaserJock: ok then you see where mdz said "ok" ?
[05:03] <imbrandon> i'm not seeing your point here
[05:03] <persia> LaserJock: Ah.  Right.  I think that comes from no activity on part of MC: I'm not sure how we are intended to prod them to action.
[05:03] <Zelut> anyone know a good resource for setting gconf settings via the shell/scripts?
[05:04] <LaserJock> persia: I talked to dholbach last night
[05:04] <imbrandon> LaserJock: as the policy stands right this second the package is ready for multiverse
[05:04] <LaserJock> he wondered why the MOTUs who objected didn't reply to the email
[05:04] <LaserJock> imbrandon: I would agree with you, other MOTUs didn't
[05:05] <persia> LaserJock: Right.  Based on that, I'm of the opinion there is more to be said, but I'm just not sure that continuing that thread is the way to do it, nor do I know that the final decision is not an infomed decision.
[05:05] <LaserJock> persia: I'm just not sure
[05:05] <LaserJock> that's why I'm trying to get people to write something up, get it going
[05:06] <LaserJock> my goodness
[05:06] <imbrandon> man-o-man but firmware built for and on windows is "OK" wtf is the diffrence
[05:06] <persia> LaserJock: Regarding replies, I suspect most MOTU don't follow MC closely, and I also suspect that most would not feel obliged to respond to queries directed to MC.
[05:06] <LaserJock> I'm just trying to get us to get this thing resolved
[05:07] <persia> imbrandon: No difference.  Personally, I'd like to see all acceptable binary blobs restricted to "restricted", where an NDA can be signed, and followed.
[05:07] <imbrandon> LaserJock: i dont and dident volenteer to because i whole heartly agree with mdz's statement "anything thats distributable" and that falls into that category IMHO so why do i need to reply or write something ?
[05:08] <imbrandon> in other words it IS resolved untill someone oposing brings up an issue and gets a new policy
[05:08] <LaserJock> imbrandon: I didn't say you did
[05:08] <LaserJock> bahhhhhhhhh
[05:08] <persia> imbrandon: I'll agree to that: I think LaserJock is only trying to start the opposition at this point.
[05:09] <imbrandon> right
[05:10] <LaserJock> all I'm saying is that it looks like the opposition to the policy was not getting heard
[05:10] <LaserJock> I'm just trying to make sure we get proper resolution to the issue
[05:11] <LaserJock> I personally agree with imbrandon, but the specific issue should be addressed by MC/TB IMO
[05:11] <imbrandon> sure i can agree to that since they dident email anyone they cant be heard, but on the other hand saying "Windows" binarys cant be in multiverse wont fly i can 1000% tell you that
[05:11] <imbrandon> you might find some other way to get that package not included but it wont be for that because all other binary only packages could be removed using the same arguments
[05:12] <LaserJock> well, I'm not going to argue about it
[05:12] <imbrandon> LaserJock: mdz is still on the TB afaik
[05:12] <LaserJock> but there were some well-respected MOTUs who disagree
[05:12] <LaserJock> imbrandon: and?
[05:13] <imbrandon> seemed like a official response to me
[05:13] <LaserJock> no it's not
[05:13] <LaserJock> mdz != TB
[05:13] <imbrandon> it dident say it was a personal opinion and it came from his ubuntu adrress to the -devel ML
[05:13] <imbrandon> pretty official
[05:14]  * persia doesn't think it matters, and suggests forgetting about the history of that thread, and that those interested draft an alternate policy.
[05:15]  * imbrandon agrees
[05:15] <LaserJock> *sigh*
[05:16]  * imbrandon packages Photoshop CS
[05:16] <imbrandon> and runs
[05:16] <LaserJock> that only took half an hour :/
[05:17] <persia> LaserJock: What sort of response do you seek?  Do you want us to all agree with the undefined position, and argue that the current policy was badly generated, never applied, and something else should?
[05:20]  * bddebian packages Wolfenstein: Enemy Territory
[05:20] <persia> imbrandon: That doesn't even meet the current policy :)
[05:20] <LaserJock> persia: no, I was trying to say exactly what you just said
[05:20]  * StevenK makes a movie called "imbrandon and bddebian must die" and then packages it.
[05:20] <bddebian> hahaha
[05:20] <persia> LaserJock: Ah.  OK.  I misinterpreted "*Sigh*".  My apologies.
[05:20] <imbrandon> LOL
[05:20] <bddebian> StevenK: At least mine is "free" :)
[05:20] <imbrandon> can i package Photoshop CS2 as Gimp-NG ?
[05:20] <StevenK> bddebian: Mine can be under whatever license I want, so there
[05:20] <bddebian> heh
[05:20] <persia> imbrandon: With permission from Adobe, yes.
[05:48] <bddebian> Gnight gang
[05:48] <RAOF> Hey, anyone know if it's safe to build gecko-embedding packages against libxul1.9-dev yet?
[05:51] <RAOF> Ok, given we don't *have* a 1.9 libxul package, I'll call that "no".
[06:37] <warp10> Hi all!
[06:44] <LaserJock> RAOF: hehe
[06:45] <dholbach> good morning
[06:45]  * Hobbsee stomps on midi files.
[06:45] <persia> Hobbsee: Why?  What did they do to you?
[06:45] <Hobbsee> persia: they wont play in wine.
[06:45] <Hobbsee> i dont know why.
[06:45]  * Hobbsee wants aoe music.
[06:46] <persia> Hobbsee: Do you have a MIDI device defined in WINE?
[06:46] <persia> Hobbsee: Alternately, might I suggest timidity?
[06:46] <Hobbsee> persia: afaics, yes.  but i may be looking in th wrong place
[06:46] <Hobbsee> timidity is running - but i still never get music.
[06:47] <persia> Hobbsee: Right.  Do you have a soundfont installed?
[06:47] <Hobbsee> persia: taht would not be in conjunction with "Just Working", i'm sure.
[06:47] <Hobbsee> ie, no.
[06:48] <persia> Hobbsee: I forget.  I have heaps of soundfonts, and don't actually know if one is installed by default.  Open a bug, and subscribe me, and I'll take a look this weekend.
[06:48] <Hobbsee> okay
[06:49] <Hobbsee> persia: oh, hmm, i presume i follow http://frankscorner.org/index.php?p=mid or something?
[06:50] <persia> Hobbsee: I thought that timidity had an init.d that did the last step, I'm just not sure about the soundfont.  That page should work though.
[06:51] <LaserJock> dholbach's here, that's my que to go to bed
[06:51]  * dholbach hugs LaserJock
[06:51] <dholbach> LaserJock: sleep tight!
[06:51] <persia> Hobbsee: I still want the bug, as I'll forget to investigate otherwise.
[06:51]  * LaserJock hugs dholbach
[06:51] <Hobbsee> persia: will do
[06:51] <LaserJock> night MOTU Land!
[06:51] <Hobbsee> persia: any idea wht the init.d was?
[06:52] <persia> Hobbsee: /etc/init.d/timidity I think.  I'm not near a useful machine now, and it was back in Dapper / Edgy I was chasing that.
[06:52] <Hobbsee> ok
[06:56] <Lutin> persia: looking at the ggobi merge: can you recall by xdg/ggobi.png is converted to xpm ?
[06:56] <persia> Lutin: s/by/why/ ?
[06:57] <persia> If so, it's to support the Debian menu system, for e.g. fluxbox users.
[06:57] <Lutin> persia: yep, sorry :)
[06:57] <Lutin> persia: ah ok
[06:58] <persia> Lutin: Just in the spirit of full disclosure, I don't remember ggobi specifically at all, but that's true for everything.  Ideally, every GUI package has a debian menu file with a 32x32 xpm as well as a .desktop file.
[06:59] <imbrandon> ( even some non gui apps , e.g. nano do )
[06:59] <imbrandon> :)
[06:59] <Lutin> hehe :)
[07:00] <persia> imbrandon: True.  I've never really understood that.  Does it call x-terminal-emulator and execute inside?
[07:00] <imbrandon> yea
[07:01] <persia> imbrandon: Do you think that should be standard?  I'd prefer to limit at least the standard menus to GUI apps, although I'm not volunteering to strip all the extra menu files.
[07:04] <imbrandon> really i have no opinion either way, i think some apps should yea, mutt , nano , etc but ls and other binutils ?
[07:05] <persia> imbrandon: Hmm..  Interesting point.  Perhaps curses apps are OK, and others less so?
[07:05] <imbrandon> yea, thats kinda what i was getting at and dident know it
[07:06]  * persia doesn't dare propose the inclusion of .desktop files for curses apps to -desktop
[07:06] <imbrandon> LOL
[07:07] <imbrandon> although tech curses apps are ( a form of ) GUI ( see: MS Windows 1.0 )
[07:07]  * imbrandon ducks
[07:07] <persia> imbrandon: I did, and I didn't want to remember having done so.
[07:07] <imbrandon> lol
[07:08] <imbrandon> but serouisly i guess thats the thinking, because mc does too
[07:08] <imbrandon> and others the more i think about it
[07:08] <imbrandon> ( the debian menu, not .desktop )
[07:08] <jdong> imbrandon: poke; would you like to sponsor KTorrent 2.2.3 into hardy for me? :)
[07:08]  * persia encourages jdong to use the sponsors queues, and scream when they are broken, rather than poking people

[07:09] <imbrandon> jdong: if it can wait ~9 hours, i definately will, i'm in total wind-down mode tonight
[07:09] <Hobbsee> thanks, persia!
[07:09]  * jdong heeds advice :)
[07:09] <imbrandon> btw jdong why havent you applied for MOTU yet ? heh
[07:10] <jdong> imbrandon: funny you should mention that
[07:10] <persia> imbrandon: You should check your mail...
[07:10] <jdong> imbrandon: just sent off that e-mail
[07:10] <imbrandon> ahhh lol
[07:10]  * imbrandon looks
[07:10] <jdong> ooh look at that, bug reports I can close in ktorrent at the same time :D
[07:11]  * persia wonders why imbrandon isn't a listed sponsor, given vocal support over a long time
[07:11] <imbrandon> and having sponsord a few packages :)
[07:12] <imbrandon> hrm i dont seem to find the email, was it sent reciently ?
[07:12] <imbrandon> e.g. last 2 hours
[07:12] <jdong> I smacked my forehead when I hit send
[07:12] <jdong> realized I forgot to put imbrandon down :)
[07:13] <jdong> who has been unfortunate enough to be dragged into sponsorin my junk in the past ;-)
[07:13] <persia> imbrandon: You weren't cc'd.  jdong: you might want to forward that mail :)
[07:13] <imbrandon> persia: i'm on the MC list though
[07:13] <imbrandon> so i should have still a copy
[07:13] <jdong> I'm sitting in mod queue for MC list
[07:13] <imbrandon> ahh
[07:13] <dholbach> approved 2 minutes ago
[07:13] <persia> imbrandon: Hmm...  I don't know why you don' have it then.
[07:14] <imbrandon> slow mail ( gmail via imap ) it'll be here if it was approved 2 minutes ago
[07:14] <imbrandon> rsn
[07:16] <imbrandon> persia: infact i replied to your mc mail about IRC heh, so i know i'm subscribed :)
[07:16] <persia> imbrandon: Right.  I was trying to ignore that :)
[07:16]  * imbrandon kills afterthoughts
[07:16] <imbrandon> hehe
[07:18] <imbrandon> anyone else notice they got osx 10.5 loaded on an eeepc :)
[07:18] <persia> MOTU applicants: it's awfully nice when there are links to LP and your wiki page in your application :)  Your sponsors know who you are, but it's an extra hunt.
[07:18] <jdong> persia: oops, this isn't a good start of me doing things right :)
[07:19] <persia> jdong: Unfortunately it's something we each only get to do once.  I wasn't happy with my own application after sending it either :)
[07:20]  * imbrandon got a ~1 hour drilling by mdz and co. instead of a nice email to MC :)
[07:21] <imbrandon> actualy that was for core-dev, not sure whom I talked to for MOTU
[07:21] <jdong> yeah I remember you coming back from the core dev one breathing a huge sigh of relief :)
[07:21] <imbrandon> heh yea
[07:22] <imbrandon> i was sweating IRL, then went for beer that night :)
[07:22] <jdong> alright fine, taunt me about the alcohol thing :P
[07:22] <imbrandon> lol
[07:22] <imbrandon> i'm sure with some MIT in your blood you can find ways, not that i'm encouraging it
[07:23] <imbrandon> still no mail /me goes to troll the archives
[07:25]  * jdong makes wishlist for Santa
[07:26] <jdong> (1) 3.0GHz quad-core penryn......
[07:27] <imbrandon> (1) eeepc (2) new computer chair (3) Employment at a FL/OSS based company
[07:27] <imbrandon> heh
[07:27] <imbrandon> i'm easy
[07:27] <jdong> ooh (2) eeepc!
[07:28] <\sh> moins
[07:28] <jdong> umm... (3) Dodge Charger RT AWD....
[07:28] <imbrandon> heya \sh
[07:36] <imbrandon> jdong: what email do you use for REVU ?
[07:37] <jdong> imbrandon: probably<EMAIL_ADDRESS>if I've uploaded anything there (vaguely recall a long time back)
[07:37] <persia> imbrandon: It's not REVU.  It's in the sponsors queue: https://bugs.launchpad.net/~ubuntu-main-sponsors
[07:37] <jdong> imbrandon: careful though, Tonio_ says he got it ;-)
[07:37] <persia> imbrandon: There are 38 others available for you :)
[07:37] <jdong> imbrandon: remember this tangle from when I first started doing KTorrent? :D
[07:37] <imbrandon> got what ?
[07:37] <jdong> the KTorrent upload
[07:38] <imbrandon> i was gonna include a link for<EMAIL_ADDRESS>:)
[07:38] <Tonio_> jdong, imbrandon: currently building here
[07:38] <imbrandon> Tonio_: kk
[07:38] <imbrandon> papa !!
[07:38] <Tonio_> imbrandon: not yet still
[07:38] <persia> imbrandon: Ah.  Right.  I forgot about that.
[07:38] <imbrandon> heh, but always fun trying
[07:38] <RAOF> Hm.  I wonder under what circumstances os.getcwd() can throw a "file not found" exception.
[07:38] <Tonio_> imbrandon: don't laugh about that, but I'll have to do a spermogram exam soon
[07:39] <Tonio_> imbrandon: not that fun :/
[07:39] <imbrandon> heh
[07:39] <jdong> RAOF: when the cwd doesn't exist anymore?
[07:39] <RAOF> jdong: I suppose so.  Miro's being strange, then.
[07:39] <Tonio_> we've been trying to make it to work for 18 month now, so it looks like there is a problem
[07:39]  * Tonio_ whishes making a baby is as simple as packaging
[07:40] <imbrandon> heh
[07:40] <\sh> lol
[07:41] <jdong> does wife go under Suggests or Recommends?
[07:41]  * jdong ducks
[07:41] <Tonio_> jdong: build-depends I suspect
[07:41] <jdong> :)
[07:42] <Tonio_> but you have to make a dh_shlibsdeps exception, since the package will depend on "mother | second-gay-father"
[07:42] <Tonio_> not to say that probably should be a recommend or even suggest thing
[07:43] <jdong> meh we can put a Suggest on parents
[07:43] <Tonio_> imbrandon: so yes, not "papa" yet, and it looks like not going to for a moment :'(
[07:43] <imbrandon> someday, Tonio_ :)
[07:43] <Tonio_> imbrandon: hopefully
[07:44] <Tonio_> :)
[07:44] <imbrandon> maybe next time you are in the US you will get a call saying "yes" :)
[07:44] <imbrandon> err on second thought, i dunno if i wanna wish comming to the US on anyone
[07:45] <imbrandon> :P
[07:45] <imbrandon> grr dholbach i sent the mail to MC from the wrong email address, mind pushing it though ?
[07:46] <jdong> imbrandon: have you figured out any way for mutt or something in the sending stack to rewrite from: based on to:?
[07:47] <jdong> I'd love to be able to rewrite my @gmail to @ubuntu based on if I'm sending to a Ubuntu list
[07:47] <imbrandon> heh yea me too
[07:47] <persia> jdong: procmail can do that for you, if the internal mutt scripts aren't sufficiently powerful
[07:47] <imbrandon> only its from @brandonholtsclaw.com
[07:47] <\sh> oh damn...more exploits for wireshark
[07:48] <persia> (Just tell mutt to use procmail on outbound, and tell procmail where to look for an SMTP server)
[07:48] <jdong> persia: interesting idea :) I'll have to look into that
[07:49] <imbrandon> yea i can see my stack now, incomming is already complicated enough, now i'll have going out evolution --> procmail --> sendmail --> gmail smtp --> ....
[07:49] <jdong> haha
[07:49] <jdong> yeah I don't like watching my mail evolve to rocket science either :D
[07:50] <imbrandon> i've just learned to try and keep most things serverside so i dont have alot of setup on a new box
[07:50]  * persia apologies to all German speakers for poor spelling :(
[07:51] <imbrandon> before gmail's imap i had an "interesting" setup to say the leaste
[07:52] <imbrandon> basicly all mail forwarded to gmail , then i got gmail via pop to my own server and used imap to access it from there, and google smtp out so my "sent" would be in the webui too
[07:53] <imbrandon> now atleaste i get to cut my own server out of the equasion, except for archives
[07:53] <\sh> imbrandon, so it's easier to setup a mail service directly and not using gmail ;)
[07:53] <imbrandon> \sh: maybe, but gmail spam filter > spamassasin
[07:54] <persia> ¥sh: In that case it's harder to use the gmaili spam filter
[07:54] <jdong> imbrandon: I still have that setup (mirrored via getmail/fetchmail and served thru dovecot) going :D
[07:54] <imbrandon> jdong: enable imap via the settings hehe
[07:54] <jdong> imbrandon: set it up like two weeks before IMAP came out
[07:54] <jdong> GRR :)
[07:54] <imbrandon> lol
[07:55] <jdong> but it's working now so I'd rather not change it.... got a spare 250GB drive sitting here to collect mail so thought what the heck, might as well
[07:55] <imbrandon> ssh jdong@dovecot shutdown -h now
[07:55] <jdong> haha
[07:55]  * jdong shamefully admits writing an apparmor profile excitedly to secure dovecot :D
[07:55] <imbrandon> lol
[07:56] <dholbach> imbrandon: done
[07:56] <imbrandon> dholbach: thanks, my mistake
[07:56] <jdong> it's that new-security-system reflex.... gotta use it like crazy for a day then abandon it :D
[07:56] <dholbach> no problem
[07:56]  * dholbach hugs listadmin
[07:56] <jdong> wow it's 3AM, time for bed :)
[07:59] <Hobbsee> yay, listadmin!
[08:00]  * Hobbsee goes thru ti too
[08:00]  * Hobbsee thougth norsetto was a MOTU.
[08:01] <dholbach> norsetto is
[08:01] <RAOF> They are, aren't they?  Recently approved.
[08:02] <Hobbsee> his mail's getting moderated.  i wonder if<EMAIL_ADDRESS>isnt listed on launcphad or something.
[08:03] <\sh> oh damn..I'm doomed...why I took the wireshark for security fixing
[08:03] <\sh> this package is evil but important..:(
[08:03] <persia> Hobbsee: Is it based on LP emails?  I thought listadmin was separate.
[08:04] <Hobbsee> persia: this is ubuntu-devel, which i believe takes a list of the people in ~ubuntu-dev, and whitelists them.
[08:04] <persia> Hobbsee: Ah.  That might be special.  I was thinking of the subscriber-only block.
[08:04] <Hobbsee> ah yes.
[08:05] <Hobbsee> there's whitelisting and stuff from listadmin, i think
[08:05]  * Hobbsee hasnt needed to use it yet
[08:08] <geser> morning
[08:09] <\sh> damn....27 CVEs for wireshark/etherreal from 0.99.0 up to 0.99.5 that means dapper will get a lot of love now..and a lot of dpatches
[08:33] <\sh> Fujitsu, ping dapper wireshark/ethereal
[08:35] <Fujitsu> \sh: Hi.
[08:37] <\sh> Fujitsu, the only way to fix at least CVE-2006-3627 CVE-2006-3628 CVE-2006-3629 CVE-2006-3630 CVE-2006-3631 CVE-2006-3632 is to try to find a way to bump the dissectors of 0.99.0 in dapper to 0.99.2
[08:38] <ubotu> Unspecified vulnerability in the GSM BSSMAP dissector in Wireshark (aka Ethereal) 0.10.11 to 0.99.0 allows remote attackers to cause a denial of service (crash) via unspecified vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3627)
[08:38] <ubotu> Multiple format string vulnerabilities in Wireshark (aka Ethereal) 0.10.x to 0.99.0 allow remote attackers to cause a denial of service and possibly execute arbitrary code via the (1) ANSI MAP, (2) Checkpoint FW-1, (3) MQ, (4) XML, and (5) NTP dissectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3628)
[08:38] <ubotu> Unspecified vulnerability in the MOUNT dissector in Wireshark (aka Ethereal) 0.9.4 to 0.99.0 allows remote attackers to cause a denial of service (memory consumption) via unspecified vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3629)
[08:38] <ubotu> Multiple off-by-one errors in Wireshark (aka Ethereal) 0.9.7 to 0.99.0 have unknown impact and remote attack vectors via the (1) NCP NMAS and (2) NDPS dissectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3630)
[08:38] <ubotu> Unspecified vulnerability in the SSH dissector in Wireshark (aka Ethereal) 0.9.10 to 0.99.0 allows remote attackers to cause a denial of service (infinite loop) via unknown attack vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3631)
[08:38] <ubotu> Buffer overflow in Wireshark (aka Ethereal) 0.8.16 to 0.99.0 allows remote attackers to cause a denial of service and possibly execute arbitrary code via the NFS dissector. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3632)
[08:38] <Fujitsu> \sh: Why can't we backport those fixes?
[08:39] <\sh> Fujitsu, most of this stuff is not documented correctly in wireshark svn...even RH and others upgraded to 0.99.2 because of those issues these days
[08:40] <Fujitsu> I recall them doing that yes... hmm..
[08:40] <Fujitsu> How big is the diff, and what kind of changes are there?
[08:40] <\sh> Fujitsu, I'm just trying to diff from 0.99.0 to 0.99.2 and prepare some patches and hopefully it works
[08:41] <\sh> Fujitsu, go to the wireshare viewsvn and diff e.g. epan/dissectors/packet-gsm.c from 18759 (0.99.2) to 17982 (0.99.0) revisions
[08:43] <Fujitsu> \sh: Are their patches these days a bit more sane and locatable?
[08:43] <\sh> Fujitsu, yepp
[08:44] <\sh> Fujitsu, 0.99.0 was the first wireshark release...everything before was ethereal...and I don't know why they documented the stuff much better...
[08:45] <Fujitsu> \sh: OK, so once we're at 0.99.2, we should be OK forever?
[08:46] <\sh> Fujitsu, nope, I don't think so
[08:47] <\sh> Fujitsu, but let me try something first...I need to test something
[09:09] <\sh> Fujitsu, no...doesn't work .. we need to bump at least to 0.99.2 or we try to backport latest wireshark to dapper
[09:11] <\sh> Fujitsu, tbh, I don't know what is the best way...carrying a big patch from 0.99.0 to 0.99.2 in the package and patch more CVE fixes from 0.99.2 upto now
[09:11] <Fujitsu> \sh: Argh, damn.
[09:11] <\sh> Fujitsu, thinking about the importance of this package...I would try to carry a patch ....
[09:12] <\sh> Fujitsu, and we should ask for main inclusion for hardy :)
[09:19] <Fujitsu> I swear, some upstreams are really looking to get themselves killed. phpMyAdmin, WordPress, [insert other PHP projects here]...
[09:19] <\sh> Fujitsu, agreed ;)
[09:20] <\sh> Fujitsu, I'll raise the wireshark discussion on -devel.
[09:22] <Fujitsu> I guess I'd better have a look at phpMyAdmin in Gutsy at least.
[09:23] <Fujitsu> Woah, they provide patches too now!
[09:28] <pwnguin> arg. why does gnome have to redo all the basic types
[09:31] <persia> pwnguin: flexibility
[09:37] <pwnguin> i guses
[09:37] <pwnguin> guess
[09:38] <pwnguin> but it also sucks having to know what the hell g_new0() does in order to debug code
[09:38] <awalton__> O_o that's a problem?
[09:38] <persia> pwnguin: No, really.  The idea is that compliant GTK apps could be ported to an environment where the definitions of the basic types were different, and the application would never need any changes, as long as GTK worked.
[09:39] <pwnguin> its a problem in the sense that i dont know gtk off hand
[09:39] <persia> pwnguin: It's an object layer.  Works about the same as for any OO environment.
[09:39] <persia> Ah.  There's docs :)
[09:39] <awalton__> good docs too
[09:39] <pwnguin> i like to take a kantian cosmopolitan approach
[09:39] <pwnguin> everywhere looks the same ;)
[09:40] <pwnguin> the sad thing is, everyone writes their portable code different
[09:40] <pwnguin> sdl doesnt look like gtk doesnt look like qt
[09:40] <awalton__> tis a shame.
[09:40] <persia> pwnguin: Well, you could learn WX.  There's a couple apps need porting :)
[09:41] <pwnguin> anyways, i think i found the offending line
[09:41] <pwnguin> helpfully commented
[09:41] <pwnguin> 	/* When opening enclosures we need the type to determine
[09:41] <pwnguin> 	   the configured launch command. The format of the enclosure
[09:41] <pwnguin> 	   info: <url>[,<mime type] */
[09:41] <awalton__> whatcha debugging pwnguin
[09:41] <pwnguin> liferea
[09:42] <awalton__> ah.
[09:42] <pwnguin> that's supposedly to do with podcasts / enclosures
[09:51] <s1024kb> norsetto: hello my teacher
[09:51] <norsetto> hiya s1024kb
[09:52] <dholbach> hey s1024kb, hey norsetto
[09:52] <norsetto> s1024kb: happily merging!?
[09:52] <geser> hi s1024kb, hi norsetto
[09:52] <s1024kb> norsetto: i am happy to see you again! just want to finish "yappy" now
[09:52] <s1024kb> geser: hi!
[09:52] <norsetto> hi dholbach!
[09:52] <s1024kb> dholbach::^^
[09:52] <norsetto> heya geser :-)
[09:54] <emgent> heya norsetto ^^
[09:54] <norsetto> emgent: oh, now I feel safe ....
[09:54] <emgent> :)
[09:55]  * cyberix hopes nmap 4.23 will make it for Hardy.
[09:55] <cyberix> (note: /me does not live in Germany)
[09:56] <norsetto> cyberix: don't worry, we all know about you and your boots ;-)
[09:56] <DaveMorris> can someone review my package on revu please  - http://revu.tauware.de/details.py?package=cpptest
[09:58] <norsetto> Does anyone know how often dad is checking the debian archives for packages to sync/merge?
[09:59] <geser> DaveMorris: the changelog entry could be more infomative, like "* Initial packaging (LP: #162913)"
[10:00] <DaveMorris> ok, I'll do that on my other packages as well
[10:00] <geser> DaveMorris: if you have no files in /usr/{s,}bin don't list it in debian/dirs
[10:00] <geser> and your rules files looks like a mix from cdbs and a normal rules file with debhelper (and you include two different patch systems)
[10:01] <DaveMorris> which 1 do I need?
[10:01] <s1024kb> norsetto: i had already use "grab-merge" to merge "yappy", now i should edit the changelog in /debian, right?
[10:02] <norsetto> s1024kb: right
[10:03] <DaveMorris> geser: I'm afraid I don't know what you mean by it been a mix of debhelper and cdbs
[10:03] <norsetto> s1024kb: you checked if grab-merge did a good job? You happy about the resulting package?
[10:03] <geser> DaveMorris: and name the -dev package only "libcpptest-dev" (you usually don't need the soversion in the -dev package name)
[10:04] <s1024kb> norsetto: in this case, i think yes... what i should add to the changelog? i open "yappy_1.8-3ubuntu1.patch", shall i copy the paragraph "merge from debian unstable..." and paste them in changelog?
[10:04] <norsetto> s1024kb: you should work on the source tree that grab-merge expanded for you
[10:04] <geser> DaveMorris: you include files from cdbs (line 3 and 4). with cdbs you only specify the targets which are different than usual (or need additional steps)
[10:05] <s1024kb> norsetto: don't know what to do...
[10:05] <geser> DaveMorris: the rest of your rules file looks like a rules file which doesn't use cdbs but only debhelper
[10:05] <norsetto> s1024kb: in the dir where you run grab-merge, there should be a directory called yappy-1.8
[10:06] <DaveMorris> I was under the impression I need lines 3/4 for the cdbs patches to be applied
[10:06] <s1024kb> norsetto: yes
[10:06] <norsetto> s1024kb: do you see it? Thats the root of the source tree that grab-merge expanded for you; it contains its guess of the merge
[10:06] <s1024kb> norsetto: yes, see it
[10:07] <norsetto> s1024kb: well, then you should work on that tree
[10:07] <norsetto> s1024kb: check if the changes that grab-merge made are acceptable, and if so fill in the changelog in its /debian directory
[10:08] <norsetto> s1024kb: its like for any other source tree you have seen before
[10:09] <geser> DaveMorris: yes, but you mixed different packaging styles
[10:09] <DaveMorris> ok, which one am I best to use in this instance?
[10:10] <BugMaN> hi all
[10:11] <norsetto> bugman: hola
[10:11] <s1024kb> norsetto: i had read all the files carefully already, and i thought that they're like what i imagine... and i open /debian/changelog,  i saw that the second record is about yappy 1.8.3, the changes of debian. and the top record is "merge from debian...", shall i add anything in the file now?
[10:11] <BugMaN> norsetto: ave :)
[10:12] <norsetto> s1024kb: I think so, what would you add in the changelog?
[10:13]  * pochu waves
[10:13] <s1024kb> norsetto: ... i don't know... i have been thinking about it for 2 days already...
[10:13] <geser> DaveMorris: if you want to use dpatch, include "/usr/share/dpatch/dpatch.make" in your rules file, man the clean target depend on unpatch and the build target depend on patch
[10:14] <geser> DaveMorris: and you need to convert your patch files to dpatch
[10:14] <DaveMorris> I created the patches using cdbs-edit-patch is that a problem
[10:14] <geser> the alternative would be to convert your rules file complete to cdbs
[10:15] <geser> DaveMorris: they are then for simple-patchsystem from cdbs
[10:15] <norsetto> s1024kb: you should report all the changes from previous ubuntu versions which you are carrying over
[10:16] <s1024kb> norsetto: but the file seems to have written them already...
[10:17] <norsetto> s1024kb: I don't think the changelog has though
[10:17] <norsetto> s1024kb: what is in the changelog now?
[10:18] <s1024kb> norsetto: Line 1: yappy (1.8-3ubuntu1) gutsy; urgency=low
[10:18] <s1024kb> norsetto: line 2:   * Merge from debian unstable, remaining changes:
[10:19] <s1024kb> norsetto: line 3:     - SUMMARISE HERE
[10:19] <s1024kb> norsetto: line 4:  -- Ubuntu Merge-o-Matic<EMAIL_ADDRESS>Mon, 24 Sep 2007 23:35:32 +0100
[10:19] <norsetto> ok, lets work line by line. You are happy about line 1?
[10:20] <s1024kb> norsetto: line 5: yappy (1.8-3) unstable; urgency=low
[10:20] <s1024kb> norsetto: line 6: * Bug fix: "python-yappy: typo in Description: field", thanks to Olivier
[10:20] <s1024kb> norsetto: line 7: Tetard (Closes: #443680).
[10:20] <norsetto> s1024kb: ok ok ... don't paste the whole thing :-)
[10:20] <norsetto> s1024kb: lets work line by line. You are happy about line 1?
[10:21] <s1024kb> norsetto: line 1, yes...
[10:21] <norsetto> s1024kb: are you sure, for what distribution are we doing the merge?
[10:23] <norsetto> s1024kb: are we merging for gutsy?
[10:23] <s1024kb> norsetto: yappy-1.8, ... is it right?
[10:24] <norsetto> s1024kb: yes the version number is correct, but, are we merging for gutsy?
[10:24] <geser> s1024kb: small hint: what's the current development version of Ubuntu?
[10:25] <s1024kb> norsetto: gutsy? right?
[10:25] <norsetto> s1024kb: well, gutsy is now what we call a Stable Release
[10:25] <norsetto> s1024kb: we only fix very serious bugs for it
[10:26] <norsetto> s1024kb: our development version is not gutsy
[10:26] <s1024kb> norsetto: understand so far... so it's...
[10:27] <norsetto> s1024kb: when you made your pbuilder, you did it with ....?
[10:27] <geser> s1024kb: h...y (replace the . with a-z)
[10:27] <s1024kb> norsetto: feisty?
[10:27] <norsetto> s1024kb: did you? Seriously?
[10:29] <geser> s1024kb: next hint: https://edge.launchpad.net/ubuntu (look at Series)
[10:29] <norsetto> s1024kb: what I'm asking is for what version of pbuilder are you building, not where you installed it
[10:33] <s1024kb> norsetto: hoary?but why? (sorry)
[10:34] <Hobbsee> ...?
[10:34] <Hobbsee> why on earth would we use pbuilders for now unsupported versions of ubuntu?
[10:35] <norsetto> s1024kb: ok, do you know that our next version of ubuntu is called hardy?
[10:35] <s1024kb> norsetto: yes
[10:36] <norsetto> s1024kb: ok, thats our next version, is what we call our development version
[10:36] <DaveMorris> has anyone got an example of what a <pkg>.install file should look like
[10:36] <DaveMorris> I can't find one :(
[10:36] <s1024kb> norsetto: okay
[10:36] <norsetto> s1024kb: hardy is our development version, gutsy is our current version, feisty is not our current version but we still support it
[10:37] <s1024kb> norsetto: okay, understand
[10:38] <norsetto> s1024kb: so, why would we merge for gutsy? Do we need to do that? (I answer: NO)
[10:39] <norsetto> s1024kb: therefore you have to change the first line, agreed?
[10:39] <s1024kb> norsetto: we merge for "Hardy", oh, i understand now!
[10:41] <s1024kb> norsetto: so i should change: "yappy (1.8-3ubuntu1) hardy; urgency=low"
[10:45] <s1024kb> norsetto: and now i understand why we're fixing bugs, merging packages here... for the next version. because in my experience i thought that we're doing that for the current OS... i guess that it's what a windows user will think...
[10:45] <effie_jayx> could anyone help me with my gpg key
[10:45] <norsetto> s1024kb: right
[10:45] <effie_jayx> it's preventiing me from signing anything
[10:46] <effie_jayx> I am playing around making debdiffs and it says it can't saign the packages
[10:46] <effie_jayx> I know I have my key in my system
[10:46] <norsetto> s1024kb: its indeed a very common problem with many users
[10:47] <norsetto> s1024kb: now, back to business, what changes are we carrying over from previous ubuntu changes?
[10:47] <s1024kb> norsetto: i have to apologize, before this i really don't have the "next version" in mind... sorry
[10:47] <norsetto> s1024kb: don't have to be sorry, its a very common problem many users are having
[10:49] <s1024kb> norsetto: i guess that the 1.8-3 is the latest version in this case?
[10:50] <norsetto> s1024kb: yes, but is that an ubuntu version?
[10:50] <norsetto> s1024kb: that version is coming from Debian, doesn't include whatever change was made by Ubuntu, which is why we need to merge
[10:51] <s1024kb> norsetto: the latest ubuntu version should be 1.8-3ubuntu1?
[10:51] <norsetto> s1024kb: no, thats the one we are doing
[10:52] <norsetto> s1024kb: we are working on that right now, the one before that is the last
[10:54] <s1024kb> norsetto: 1.8-2? sorry...
[10:54] <norsetto> s1024kb: what versions you you see in the changelog?
[10:55] <geser> effie_jayx: does your key uid match the name entry in the changelog (including all comments)?
[10:56] <s1024kb> norsetto: 1.8-3ubuntu1, 1.8-3, 1.8-2ubuntu1, 1.8-2, ...
[10:56] <norsetto> s1024kb: ok, so what would be the last ubuntu version, the one before 1.803ubuntu1 ?
[10:56] <norsetto> sorry, before 1.8-3ubuntu1
[10:57] <s1024kb> norsetto: 1.8-3?
[10:57] <norsetto> s1024kb: the last UBUNTU version
[10:57] <effie_jayx> geser,  let me check
[10:58] <s1024kb> norsetto: 1.8-2?
[10:59] <effie_jayx> geser,  checked .. it maches
[10:59]  * effie_jayx echo's DEBEMAIL and DEBFULLNAME
[11:01] <geser> and you get that error that the secret key couldn't be found?
[11:01] <effie_jayx> geser,  yes
[11:02] <geser> btw signing is only imporant when you want to upload not for debdiffs
[11:02] <effie_jayx> geser,  it says ... public key not found
[11:02] <geser> public key?
[11:02] <effie_jayx> geser,  really?. I am new to this so I though it was needed
[11:02] <geser> can you paste bin the whole output?
[11:02] <effie_jayx> geser,  it read public key not fpund
[11:02] <effie_jayx> ok
[11:03] <geser> effie_jayx: yes, as the signture is only on the .dsc file and .changes file and both files aren't in the debdiff
[11:03] <s1024kb> norsetto: i guess that they're both had been modified from yappy-1.8, in Ubuntu the modified version is yappy-1.8-2, in Debian the modified version is yappy-1.8-3, so is it the last ubuntu version yappy-1.8-2?
[11:04] <effie_jayx> geser, http://pastebin.ubuntu-nl.org/44712/
[11:05] <effie_jayx> geser,  it seems to me ... it's trying to search for a key that signed the package in 2005, no?
[11:06] <geser> effie_jayx: debdiff tries to verify the signature of the debian.dsc and complains that you don't have that public key
[11:06] <geser> you can ignore it
[11:06] <effie_jayx> geser,  ok
[11:07] <effie_jayx> thanks geser
[11:09] <effie_jayx> ok I ma ready to make patches if needed :D
[11:09] <norsetto> s1024kb: sorry, I'm having some net troubles
[11:09] <Lutin> norsetto: every 30 mins iirc (how hoften DaD checks for new merges)
[11:09] <Lutin> ot maybe an hour
[11:09] <Lutin> or*
[11:10] <norsetto> lutin: oh, I see, I'm asking since I've seen a merge in MoM since a couple of days but not yet in DaD
[11:10] <Lutin> norsetto: Oo . what one ?
[11:10] <s1024kb> norsetto: sorry my teacher...  i had a hard time just now, i guess that you were angry with my stupid mistakes...
[11:11] <norsetto> lutin: cuyo
[11:11] <s1024kb>  norsetto: i guess that they're both had been modified from yappy-1.8, in Ubuntu the modified version is yappy-1.8-2, in Debian the modified version is yappy-1.8-3, so is it the last ubuntu version yappy-1.8-2?
[11:11] <norsetto> s1024kb: not at all, its that I have many things to do all at once
[11:12] <Lutin> norsetto: indeed ... weird
[11:12] <s1024kb> norsetto: so if you're busy now, shall we do it the tomorrow?
[11:13] <Lutin> norsetto: Oo, can't find it on MoM actually
[11:13] <geser> s1024kb: you hope he'll be less busy tomorrow? :)
[11:13] <norsetto> s1024kb: well, you do require a lot of attention
[11:13] <norsetto> lutin: just checked now and it was there!?
[11:14] <norsetto> lutin: can it be the funny version number?
[11:14] <Lutin> norsetto: well I checked merges.ubuntu.com/c/ , and there"s no cuyo package
[11:15] <norsetto> s1024kb: the last ubuntu version is 1-8-2ubuntu1, you have to report in the changelog all the changes from that version which you are merging
[11:15] <geser> norsetto: really a very interesting version 2.~-1.0~beta1-1
[11:15] <norsetto> lutin: funny, I see it
[11:15] <s1024kb> norsetto: sorry... thank you my teacher...
[11:16] <Lutin> norsetto: you see the link on the html page, but the folder doesn't exist
[11:16] <geser> norsetto: ask Keybuk why MoM lists it
[11:16] <Lutin> norsetto: actually I think it's a merge from experimental
[11:16] <norsetto> lutin: oh yes
[11:16] <Lutin> DaD never polls experimental for updates
[11:17] <norsetto> lutin: ah right, it is indeed
[11:18] <Lutin> maybe MoM has some code to see if a merge comes from experimental, but it seems it just doesn't merge the package
[11:18] <norsetto> lutin, geser: that explains it, thanks
[11:19] <s1024kb> norsetto: i guess now i understand what i shall write in the changelog... thank you very much. i try to do it at home... i go home now, thank you for showing me a new world.
[11:19] <norsetto> s1024kb: thanks to you selene, see you soon then!
[11:21] <s1024kb> norsetto: thank you again my teacher, i will not give up, i will work hard and i wish that i can depend on myself soon...
[11:21] <norsetto> s1024kb: don't worry, one step at the time and we will be there soon
[11:22] <s1024kb> norsetto: many many thanks. i see the dawn today... :-)
[11:38] <proppy> hi
[11:41] <norsetto> heya proppy
[11:42] <proppy> heya norsetto
[11:44] <proppy> norsetto: wassup
[11:45] <norsetto> proppy: well, soon lunch !
[11:45] <proppy> norsetto: I bet you'll be eating some viking food again
[11:45] <norsetto> proppy: actually I got some kind of stomach flu today
[11:46] <norsetto> proppy: maybe some rice :-(
[11:46] <proppy> norsetto: My room mate ordered a rice cooker, it's a must have
[11:47] <norsetto> proppy: we have plenty of those already, my wife is a fanatic of oriental cooking
[11:48] <norsetto> proppy: what about you? still trying to digest debhelper?
[11:48] <proppy> norsetto: maybe she can share some receipe with my girlfriend :), does she have a blog (ahah) ?
[11:48] <norsetto> proppy: she has actually :-)
[11:48] <proppy> norsetto: I'm kinda stuck with an impossible choice (like usual)
[11:48] <proppy> norsetto: a friend of mine recently give me a CMakeList.txt to build juce
[11:49] <proppy> norsetto: and as the original makefile does not generate shared library
[11:50] <proppy> norsetto: and I feel pretty unconfortable patching a premake generated Makefile
[11:50] <proppy> norsetto: I've give a though using cmake instead of the upstream provided makefile
[11:50] <norsetto> not knowing the details I see 4 choices here
[11:51] <proppy> norsetto: but if I do so, I'll be trouble with debuild reverse patching, as cmake will overwrite the upstream provided Makefile, and then cdbs patch will have trouble to revert
[11:51] <proppy> I'll be glad to have some guru thought about this :)
[11:52] <norsetto> proppy: well, why do you patch something which is not there?
[11:52] <proppy> norsetto: I'll be using patch to add the cmake support
[11:52] <proppy> norsetto: and remove the upstream provided makefile
[11:53] <norsetto> proppy: is this cmake a nice new toy or you really need it (meaning, you can't do otherwise)?
[11:53] <proppy> norsetto: but as cmake will create a different makefile, reverse-patch will be troublesome I guess
[11:54] <proppy> norsetto: I thought about this, cause I get my hands on a CMakeList.txt for juce, then I don't have to write it myself
[11:54] <proppy> norsetto: but the alternative is to patch a premake.lua generated Makefile
[11:54] <proppy> norsetto: which doesn't sound nice either
[11:55] <norsetto> proppy: well, the cleanest would be to ask upstream to use it
[11:56] <proppy> norsetto: you mean to use cmake, or to generate a shared library and have some install rules ?
[11:56] <norsetto> proppy: generate a shared library and have some install rules
[11:56] <norsetto> proppy: which they can do easily with some #IFDEFS
[11:57] <proppy> norsetto: I guess premake.lua already support it
[11:57] <norsetto> proppy: I mean, are they interested to port this properly to linux or not?
[11:57] <proppy> norsetto: but then instead of patching the generated Makefile
[11:57] <proppy> norsetto: I have to patch the lua script with generate the makefile
[11:58] <proppy> norsetto: and then propose my patch to the upstream
[11:58] <proppy> so step 1: report missing install rules and shared library on forum
[11:58] <proppy> step 2: work on a patch
[11:58] <proppy> step 3: reply with the patch
[11:58] <proppy> ok ?
[11:59] <norsetto> proppy: why not just report the missing install rules and shared library with a patch?
[12:00] <proppy> norsetto: I use to thought that report first, then fix, is a good habit
[12:00] <proppy> norsetto: but it may be a wrong idea
[12:00] <norsetto> proppy: it depends on upstream, some like if you report a problem and a (possible) fix at the same time
[12:01] <proppy> norsetto: the upstream is very responsive, maybe he will fix it himself
[12:01] <proppy> norsetto: in the next version
[12:01] <dholbach> MOTU Q&A session in #ubuntu-classroom now
[12:01] <proppy> norsetto: but it should speed thing if I post the fix too
[12:02] <norsetto> proppy: it usually does
[12:02] <proppy> norsetto: thanks for your time
[12:02] <proppy> norsetto: go to class now !
[12:02] <norsetto> proppy: heck, you should go to class!
[12:03]  * norsetto writes a report to the principal about proppy not showing in time to class
[12:03] <proppy> norsetto: already in
[12:08] <deadwill> morning
[12:10] <norsetto> hey deadwill, join us in #ubuntu-classroom
[12:11] <\sh> woohoo...edgy wireshark cves fixed
[12:12] <Fujitsu> \sh: Nice one!
[12:12] <\sh> Fujitsu, 10 fixes cherry picked :) 5 backported from 0.99.6 for feisty (applies for edgy too)
[12:13] <proppy> norsetto: bug #158605 commented
[12:13] <ubotu> Launchpad bug 158605 in ubuntu "[needs-packaging] juce" [Wishlist,In progress] https://launchpad.net/bugs/158605
[12:15] <norsetto> proppy: looks good
[12:21] <Fujitsu> \sh: Sounds painful.
[12:36] <rexbron> Don't you want to review? http://revu.tauware.de/details.py?package=openlibraries and http://revu.tauware.de/details.py?package=genpo
[12:36]  * rexbron is running out of creative ways to ask for a review....
[12:38] <Hobbsee> Fujitsu: wants to review.
[12:39] <norsetto> rexbron: bribes usually work .....
[12:39] <norsetto> :-X
[12:39] <rexbron> norsetto: Want a cookie?
[12:39] <zul> morning
[12:49] <eneko_tab> morning
[12:50] <DaveMorris> geser: I've done it with cdbs now, hopefully its right,  can you check for me please http://revu.tauware.de/details.py?package=cpptest
[13:01] <\sh> Fujitsu, dapper is a no go...you can't change it back to old variable names...they changed everything ...
[13:01] <Fujitsu> \sh: -grumble-
[13:01] <\sh> Fujitsu, bumping to 0.99.2 is valid, and we can backport all fixes like I did now with 0.99.3
[13:02] <Fujitsu> Dapper will have to rot, then. Maybe try to backport the latest through -backports.
[13:02] <\sh> well, when edgy is in the security archive, we can backport them...
[13:02] <Fujitsu> We can't really backport from -security.
[13:02] <\sh> wireshark package has transitional packages handy
[13:03] <\sh> Fujitsu, the real problem is the complete namechange they went through
[13:03] <\sh> they even changed the libnames on windows and looks like on unix too
[13:04] <Fujitsu> Lovely. I don't think we can support Ethereal in Dapper then. People will have to rely on -backports, if anything.
[13:04] <\sh> Fujitsu, funny thing about edgies version was, debian upstream maintainer put some not official svn checkout in..:(
[13:05] <\sh> Fujitsu, e.g. for epan/dissectors/packet-http.c I had to patch it three times, to apply the CVE fix...and the real upstream version is correct :(
[13:07] <Fujitsu> \sh: Fun. I'll work on phpMyAdmin back to at least Feisty, and maybe Dapper/Edgy tomorrow, but sleep for me shortly.
[13:09] <\sh> Fujitsu, I'm done for today looks like...
[13:09] <\sh> I think it's the longest changelog ever (actually for me)
[13:11] <Fujitsu> \sh: I saw that it was rather long, yeah.
[13:12] <\sh> Fujitsu, that was only feisty....edgy is much more ,)
[13:13] <Fujitsu> Haha.
[13:13] <Fujitsu> I guess it would be.
[13:34] <geser> DaveMorris: looks better. Why are you shipping README and README.in in libcpptest0? Have you tried to install both libcpptest0 and libcpptest-dev as both ship /usr/lib/libcpptest.so.0? And you probably should add a (versioned) dependency on libcpptest0 to libcpptest-dev.
[13:35] <DaveMorris> ok geser I'll look at that, I must of over looked the readme thing
[13:36] <proppy> DaveMorris: (you know unittest++?)
[13:36] <DaveMorris> yeah, cpptest is another one which I used in my project
[13:36] <DaveMorris> so I thought I'd get it packaged
[13:37] <proppy> DaveMorris: (cause I packaged unittest++ for debian, just in the case you need it)
[13:37] <proppy> :)
[13:37] <geser> DaveMorris: and you should also work on debian/copyright. At least the upstream authors and upstream copyright is missing.
[13:38] <proppy> DaveMorris: do you supply a non -dev package ? cause I dropped it for unittest++, cause you don't really need to ship executable that depends upon a unittest shared library do you ?
[13:39] <DaveMorris> proppy: good point, I hadn't thought about it that way
[13:40] <proppy> DaveMorris: btw I still have an empty libunittest++0 for retro compatibility which is odd :(
[13:56] <proppy> anyone know a package builded with premake (lua) ?
[14:08] <Fujitsu> \sh: That is an impressive changelog.
[14:08] <Fujitsu> (entry)
[14:08] <\sh> Fujitsu, yeah :)
[14:11] <DaveMorris> geser: Do you mind having a look at my latest attempt?
[14:11] <DaveMorris> http://revu.tauware.de/details.py?package=cpptest
[14:16] <geser> DaveMorris: as you don't use dpatch you don't need to build-depend on it
[14:16] <DaveMorris> k
[14:20] <DaveMorris> geser: anything else apart from that?
[14:21] <rexbron> Hobbsee: Hey, how are things on your side of the world?
[14:21] <Hobbsee> rexbron: well, we're upside down still, so things are normal
[14:21] <rexbron> :)
[14:21] <rexbron> Hobbsee: Have time for a review?
[14:22] <Hobbsee> no, sorry
[14:22]  * Hobbsee has an exam tomorrow, and needs bed soon
[14:22] <rexbron> its ok
[14:22] <rexbron> gogogo
[14:22] <rexbron> and good luck
[14:35] <geser> Hobbsee: good luck for your exam
[14:36] <Hobbsee> geser: thanks :)
[14:47] <MagicFab> hi
[14:48] <Hobbsee> oh noes, it's MagicFab
[14:48] <MagicFab> How can I check which package installed another one as dependency ? I am trying to find out how debsig-verify got installed on a system.
[14:48] <MagicFab> Hobbsee, I am glad to see you too :)
[14:49] <Hobbsee> MagicFab: the unefficient method would be to do an apt-cache rdepends <dependancy>, and see which of those you've installed.
[14:49] <Hobbsee> other effective ways are trying to remove it, and seeing what else it takes with it - assuming it's not a recommends
[14:49] <Hobbsee> i think there's been something on the debian package of the day thing that does that, though
[14:50] <mrigns> hmm debsign -S fails...  wrong passphrase, I does not even ask me anymore for it
[14:50] <MagicFab> I mean I know how to go in Synaptic and seach in " dependencies "  only, but I' d like to know how to do the same in command line
[14:50] <griffinc> Hi there -- I am working on a merge and was wondering where to put my debdiff when it's done for folks to look at?  should I open a bug on launchpad?
[14:51] <Hobbsee> MagicFab: then use the rdepends stuff.
[14:51] <mrigns> apt-cache depends should also work
[14:52] <MagicFab> mrigns, I want that but the other way around ("list of packaages that depend on debsig-verify :" ) - but tx, didn' t know that one
[14:53] <mrigns> oh, well, didn't follow the conversation ;P
[14:53] <mrigns> np
[14:54] <MagicFab> Hobbsee, rdpeends lists dependencies of dependencies etc. recursively but tx.
[14:55]  * Hobbsee thought it only did it one layer deep
[14:56] <MagicFab> hmm found a script: http://noisybox.net/computers/debdeps/
[14:56]  * Hobbsee is still havign trouble figuring out if you want the deps, or rdeps of a particular package
[14:56] <mrigns> *sigh* I got the same problem with debuild failing to sign packages with seahorse installed, but this time seahorse isn't involved at alle
[14:57] <Hobbsee> debuild doesnt sign by default, iirc, unless you specify the key ID.
[14:57] <Hobbsee> or sometimes borks at the keys
[14:57] <Hobbsee> griffinc: yes, bug, subscribe ubuntu-universe-sponsors.
[14:57] <Hobbsee> second link in the topic, iirc.
[14:58] <norsetto> Hobbsee: heh, I'm moderated because somebody knows me well ;-)
[14:58] <Hobbsee> norsetto: nah, i think something's just borked.
[14:58] <Hobbsee> norsetto: although your mail was somewhat harsh, though.
[14:59] <norsetto> Hobbsee: you think so? It wasn't meant to be
[14:59] <MagicFab> deborphan does the job :D
[14:59]  * MagicFab is now happy
[14:59]  * Hobbsee dont need no deborphan :P
[15:00] <MagicFab> tx all
[15:02] <mrigns> Hobbsee: debuild -S always asked me for my passphrase to unlock my gpg key, the one I specified in my bashrc, but now it just skips the point where I can enter my passphrase
[15:02] <norsetto> Hobbsee: must be the latino who is buried in me ...
[15:02] <mrigns> after that it complains the passphrase would be wrong
[15:02] <Hobbsee> mrigns: specify it with -k<yourkeyid> then
[15:02] <Hobbsee> on teh debuild
[15:03] <Hobbsee> norsetto: must be :P
[15:03]  * Hobbsee --> bed.
[15:03] <mrigns> night
[15:04] <mrigns> hmm there is no -k for debuild *sigh*
[15:04] <\sh> mrigns, sure there is
[15:04] <Hobbsee> mrigns: yes there is.
[15:04] <\sh> debuild -S -sa -k<your id>
[15:04] <\sh> as an example
[15:05] <\sh> guys, what was the name of the webfrontend for the server administration what soren wanted to add to ubuntu?
[15:05] <StevenK> Ebox
[15:05] <\sh> thx...
[15:05] <mrigns> hmm it's not mentioned in the man page
[15:05] <\sh> debuild knows everything of dpkg-buildpackage
[15:06] <mrigns> hmm i c
[15:06] <mrigns> well doesn't work either, still skips the part where I'm prompted for my pass
[15:07] <\sh> mrigns, debuild -S -ksh@source e.g. works for me.
[15:07] <\sh> mrigns, sure, that you have a secret key handy? :)
[15:08] <mrigns> It recognises my key and everything
[15:12] <mrigns> now, this really drives me mad
[15:21] <\sh> phew...end of business, let's drink a beer
[15:27] <mrigns> hmm killing gpg-agent solved it
[15:27] <mrigns> sorry, for bothering
[15:33] <simu> i downloaded jdk 6 for amd_64 bit but I did not found a plugin folder in the jre directory
[15:33] <simu> no java browser plugins for 64bit yet??
[15:33] <simu> shit wron channel
[15:34] <ogra> simu, well http://packages.ubuntu.com/gutsy/devel/icedtea-java7-plugin claims its for amd64
[15:44] <dfiloni> can someone view this package: http://revu.ubuntuwire.com/details.py?package=wxwidgets2.8 ?
[15:44] <azeem> view or review?
[15:45] <dfiloni> review
[15:45] <dfiloni> sorry
[15:45] <griffinc> Debian has added "Homepage" to its control files -- do we keep this for Ubuntu or remove it?
[15:46] <pochu> griffinc: keep it, since dpkg will be merged to support it (if it hasn't already)
[15:47] <griffinc> pochu: makes sense. thanks!
[15:49] <proppy> hi
[15:51] <\sh> another bug bytes the dust.....openldap2.2 dapper love
[15:51] <\sh> ok..cu later guys
[15:51] <griffinc> one more question:  I have specified "hardy" as the distribution and lintian gives me an error 'you've specified an unknown target distribution in your upload debian/changelog file.'  I assume it's because I am running gutsy even though I am using a hardy pbuilder environment?  ok to ignore for now?
[15:52] <proppy> maybe lintian@hardy doesn't know hardy yet :)
[15:54] <minghua> lintian@hardy knows about hardy.
[15:55] <minghua> griffinc: It's fine to ignore.  You can also run lintian in a hardy chroot, of course...
[15:55] <griffinc> minghua: ah, yes.  thanks -- I'll do that.
[15:56] <proppy> dpkg -L lintian | xargs grep hardy
[15:56] <proppy> seems that gutsy knows hardy as well
[15:56] <proppy> norsetto: I've just beat premake.lua !
[15:57] <griffinc> proppy: interesting.  my lintian message lists warty through gutsy but no hardy.
[15:57] <proppy> norsetto: http://hg.juce.aminche.com/rev/7ce48f47eda7
[15:58] <proppy> griffinc: dpkg -l lintian ?
[15:58] <norsetto> proppy: dll to you too
[15:59] <proppy> root@juce:/home/www/juce-1.45/build/linux# ls ../../bin | grep .so
[15:59] <proppy> libjuce_debug.so
[15:59] <proppy> norsetto:
[15:59] <proppy> yeappa
[15:59] <griffinc> 1.23.32ubuntu1
[15:59] <proppy> griffinc: mine is ii  lintian        1.23.36ubuntu1 Debian package checker
[16:00] <griffinc> proppy: yep, you have the hardy lintian pkg
[16:01] <proppy> griffinc: :)
[16:02] <proppy> griffinc: strange grep hardy in my source.list doesn't show anything
[16:02] <proppy> griffinc: maybe it's because of gutsy-proposed
[16:03] <pochu> proppy: try apt-cache madison lintian
[16:03] <proppy> it's gutsy-backports :)
[16:03] <proppy> pochu: thanks
[16:04] <proppy> griffinc: lintian@gutsy-backports knows hardy
[16:06] <griffinc> proppy: ok, cool. thanks!
[16:08] <proppy> norsetto: my dll is bigger than yours
[16:09] <norsetto> proppy: everyone is .... I haven't got any
[16:10] <proppy> norsetto:  libjuce.a  libjuce_debug.a  libjuce_debug.so  libjuce.so
[16:17] <proppy> norsetto: replyed with the patch upstream
[16:17] <proppy> norsetto: waiting for his review
[16:42] <bddebian> Heya gang
[16:42] <geser> Hi bddebian
[16:42] <bddebian> Hi geser
[16:44] <huats> hey bddebian
[16:48] <bddebian> Hello huats
[17:04] <LaserJock> morning bddebian
[17:05] <bddebian> Heya LaserJock.  Did you ever have any luck with any of those machines?
[17:06] <LaserJock> yes
[17:06] <LaserJock> I mashed them all together
[17:07] <LaserJock> and got a 1.7GHz P4, 512MB RAM, 200GB hard drive machine going
[17:07] <LaserJock> now I have to figure out what to do with the leftovers
[17:09] <bddebian> heh
[17:11] <proppy> norsetto: here ?
[17:13] <norsetto> proppy: yes?
[17:13] <geser> LaserJock: ebay?
[17:13] <proppy> norsetto: what about packaging premake ?
[17:13]  * RainCT thinks: is this a questions contest? :P
[17:13] <norsetto> proppy: yes, what about it?
[17:14] <proppy> norsetto: it will ease juce makefile hacking, even if my change get accepted upstream
[17:14] <proppy> norsetto: and in the end others project could benefit of this
[17:15] <norsetto> proppy: I know nothing about premake, is there any reason why is not packed by debian? like license or even technical ones?
[17:15] <proppy> norsetto: I've just unpackaged the (zip) tarball
[17:15] <proppy> looks like GPL
[17:15] <proppy> many of .c files that build very fast
[17:16] <jdong> hehehe lol at LaserJock's comment on my MOTU application :)
[17:19] <proppy> and a nice executable in the end
[17:19] <proppy> norsetto: I'm glad that they don't use premake to generate premake makefile
[17:19] <proppy> oups
[17:19] <proppy> THEY ARE !
[17:20] <proppy> norsetto: sorry I didn't get your message if there were any
[17:20] <proppy> (06:18:06 PM) proppy: norsetto: so the reason why it's not in debian, may be that you actually need premake to regenerate premake Makefile,
[17:21] <norsetto> proppy: heck, must have been at least 10 of them, I m not going to repeat them
[17:21] <proppy> sorry
[17:22] <proppy> just past them somewhere
[17:22] <proppy> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262864
[17:22] <ubotu> Debian bug 262864 in wnpp "ITP: premake -- A build script generator for C, C++, and C#" [Wishlist,Open]
[17:22] <proppy> there is an tip
[17:22] <proppy> itp
[17:22] <norsetto> proppy: just kidding ;-)
[17:23] <norsetto> proppy: well, it doesn't seem to be a very warm welcome to that package
[17:23] <proppy> norsetto: it's on mentors http://mentors.debian.net/debian/pool/main/p/premake/
[17:24] <norsetto> proppy: if its there since august I wouldn't raise your hopes too much
[17:27] <\sh> re
[17:27] <proppy> norsetto: premake: A build script generator for C, C++, and C#, 1201 days in preparation.
[17:27] <proppy> norsetto: there've been plenty of preparation on it
[17:28] <norsetto> r\sh
[17:31] <LaserJock> jdong: you deserve it dude
[17:31] <proppy> norsetto: let's ask #debian-mentors
[17:33] <norsetto> proppy: what is tiddlywiki!?
[17:34] <LaserJock> tiddlywiki is cool
[17:34] <LaserJock> wiki done mostly in JavaScript
[17:35] <proppy> norsetto: a self contained wiki
[17:35] <proppy> norsetto: a wiki in a file
[17:35] <proppy> norsetto: an html page that can edit itself locally
[17:36] <proppy> norsetto: you open the html file, you modify some text in it, you save it to the same html file
[17:37] <proppy> another one ?
[17:39] <proppy> the best way to figure what it is, is to try it: wget http://www.tiddlywiki.com/empty.html && firefox empty.html
[17:41] <proppy> norsetto: how did you find about it ?
[17:41] <proppy> LaserJock: do you use it ?
[17:43] <norsetto> proppy: was checking to see if you were in #debian-mentors and found out you were in #tiddlywiki
[17:43] <proppy> norsetto: debian-mentors is on irc.debian.org
[17:44] <proppy> norsetto: http://lp152438.aminche.com/ tiddlywiki in action
[17:44] <norsetto> proppy: yes, I realised it too late :-)
[17:44] <LaserJock> proppy: no, but I often look around at wikis
[17:44] <LaserJock> especially personal ones
[17:45] <proppy> LaserJock: there is a lot of tiddlywiki derivative, some of them implementing GTD stuff
[17:45] <LaserJock> neat
[17:45] <norsetto> proppy: ok, so suppose I want to modify it how do I do it?
[17:45] <LaserJock> I'm using pmwiki currently
[17:46] <proppy> put you name in authors
[17:47] <proppy> click on options
[17:47] <proppy> put you username in the box
[17:47] <proppy> then click advancedoptions
[17:47] <proppy> uncheck 'Hide editing features when viewed over HTTP'
[17:47] <proppy> and reload the page
[17:48] <proppy> then you will be able to edit and save on the remote url
[17:48] <proppy> via webdav
[17:48] <proppy> if you want to edit it locally
[17:48] <proppy> i.e: not on http://lp152438.aminche.com/
[17:49] <proppy> just wget http://lp152438.aminche.com/index.html -O norsetto_vs_tiddlywiki.html && firefox norsetto_vs_tiddlywiki.html
[17:49] <proppy> and you should be able to edit it locally
[17:49] <norsetto> proppy: ok, but, what is different form your everyday wiki?
[17:50] <proppy> norsetto: ?
[17:50] <norsetto> proppy: ops .....
[17:50] <proppy> I'm not sure to understand what you mean
[17:50] <proppy> by everyday wiki ?
[17:50] <norsetto> proppy: err, can you check that page again?
[17:51] <norsetto> proppy: phew .... never mind that
[17:51] <proppy> http://lp152438.aminche.com/ looks fine
[17:51] <norsetto> proppy: I mean, like the ubuntu wiki?
[17:51] <LaserJock> it's a lot different
[17:51] <norsetto> proppy: moinmoin or whatever is called
[17:52] <LaserJock> moin, mediawiki, etc. require installation and setup
[17:52] <LaserJock> mediawiki for instance requires PHP and a DB like MySQL
[17:52] <LaserJock> moin at least doesn't require a DB necessarily but it's still involved
[17:52] <proppy> norsetto: the wiki engine, is self contained in the html file
[17:52] <norsetto> LaserJock: ok, so its different from the server side, from a user pov its the same?
[17:53] <LaserJock> norsetto: it's different in that it's mostly JavaScript
[17:53] <norsetto> proppy: ok, think I got it
[17:53] <LaserJock> so it looks different
[17:53] <proppy> norsetto: you can't grab a copy of a mediawiki or a moin wiki on your local machine easily
[17:53] <LaserJock> and it's got different features
[17:53] <proppy> norsetto: you can fork the wiki with cp
[17:53] <norsetto> LaserJock, proppy: sure, I get it now
[17:53] <proppy> norsetto: you can thought about it as a decentralized wiki
[17:54] <proppy> norsetto: just like bzr versus svn
[17:54] <norsetto> proppy: well, I just checked the source to see whats in there :-)
[17:54] <proppy> norsetto: you can clone the wiki locally edit it, and then someone can poll you changes back
[18:00] <proppy> norsetto: are you considering using tiddlywiki for some hot stuff ?
[18:01] <norsetto> proppy: hot stuff? You should see my home page ;-)
[18:03] <proppy> the launchpad one ?
[18:05] <davromaniak> is somerville32 here ?
[18:09] <norsetto> proppy: no, the real one, red hot ....
[18:09] <proppy> norsetto: url !
[18:10] <proppy> oops
[18:10] <proppy> seems that I've overwrited a package on mentors
[18:10] <proppy> :(
[18:10] <norsetto> proppy: I'm not so sure you can survive it ... its only for a mature audience
[18:11] <bddebian> proppy: It's not biggie :)
[18:11] <bddebian> Err no
[18:11] <proppy> norsetto: nothing can beat cuteoverload.com
[18:11] <proppy> doesn't understand my dput didn't reject me
[18:11] <bddebian> proppy: I'm just trying to make sure something actually gets uploaded to Debian :-)
[18:12] <proppy> aaaa
[18:12] <proppy> it's the same bdd*
[18:12] <proppy> I've just realised it :)
[18:13] <bddebian> Yeah, they made me change my name over there ;-P
[18:13] <proppy> glad to see someone in between
[18:13] <proppy> :)
[18:14] <norsetto> bddebian: so, you are bdubuntu there?
[18:16] <bddebian> norsetto: Hahah, yeah I should have ;-P
[18:27] <txwikinger> Das every package for ubuntu get the -0ubuntu1 suffix?
[18:27] <txwikinger> Does
[18:28] <jdong> it depends on the origin of the packagesl
[18:28] <jdong> packages directly pulled from Debian without any changes retain their Debian version
[18:28] <txwikinger> if the package itself is the first time it is packaged as a .deb
[18:28] <jdong> packages where Ubuntu has made changes get version suffic <debian_version>ubuntu1
[18:29] <jdong> if there is no previous debian package it's based on, 0ubuntu1 is used
[18:29] <txwikinger> thank jdong
[18:29] <txwikinger> I have another question
[18:29] <txwikinger> what is if a copyright file in the original package is missing
[18:29] <txwikinger> but there is copyright statement in another file
[18:30] <jdong> hmm, good question; I'm not sure how to handle that, perhaps someone more knowledgeable can give an answer
[18:30] <bluekuja> txwikinger, actually every upstream tarball should contain a copyright file
[18:31] <bluekuja> txwikinger, like COPYING
[18:31] <txwikinger> well some don't, but have a statement in i.e README
[18:31] <bluekuja> txwikinger, and anyway every license should reported in debian/copyright
[18:31] <txwikinger> should I just create one then
[18:31] <jdong> I've seen some that just say "Licensed under GPL" in some documentation
[18:31] <jdong> I'm not sure how to handle those cases
[18:31] <bluekuja> txwikinger, and if differents just list file-->license
[18:32] <txwikinger> I have create a debian/copyright
[18:32] <jdong> Ideally, see if you can get upstream to more explicitly license their tarball ;-)
[18:32] <bluekuja> txwikinger, of course...
[18:32] <txwikinger> I don't know if there needs one also in the package root
[18:32] <bluekuja> txwikinger, without that the package cannot be archived
[18:32] <bluekuja> and accepted
[18:33] <desertc> Are the MOTU involved with the Update Manager package releases?
[18:33] <bluekuja> txwikinger, plus every source file should contain license headers
[18:33] <bluekuja> if not, ping upstream
[18:33] <bluekuja> ;)
[18:33] <desertc> I mean to say, involved with deciding what gets pushed out?
[18:33] <bluekuja> desertc, I would say core-devs
[18:33] <desertc> TY!
[18:33] <bluekuja> desertc, that package is in main actually
[18:33] <jdong> desertc: ultimately that's the archive manager's call
[18:34] <bluekuja> desertc, get to #ubuntu-devel
[18:34] <bluekuja> and ask there
[18:34] <desertc> Already there.
[18:34] <bluekuja> perfect then :)
[18:34] <bluekuja> ok, I'm off
[18:34] <bluekuja> have a good evening
[18:35] <desertc> Thanks again
[18:35] <txwikinger> bye bluekuja
[18:37] <somerville32> davromaniak, Hi
[18:37] <somerville32> I'm here
[18:38] <davromaniak> i saw you've proposed youtranslate upgrade in revu
[18:39] <davromaniak> it's good, but I've declared a bug, and I'm working on it (correcting minor mistakes in the package)
[18:59] <BlueDevil> hi guys
[18:59] <BlueDevil> where is the proper place to report that security.ubuntu.com is giving 403 - Forbidden errors?
[18:59] <jdong> BlueDevil: it's a known issue
[19:00] <jdong> BlueDevil: the Samba update has been disabled due to a few regressions spotted
[19:00] <jdong> as a safeguard users are denied access to these broken updates
[19:00] <jdong> c.f. bug #163042
[19:00] <ubotu> Launchpad bug 163042 in samba "nmbd crashes after routine Dapper upgrade" [Critical,In progress] https://launchpad.net/bugs/163042
[19:01] <BlueDevil> ok
[19:01] <BlueDevil> thanks
[19:11] <somerville32> davromaniak, okay.
[19:11] <somerville32> davromaniak, What is the bug number?
[19:13] <davromaniak> Bug #159249
[19:13] <ubotu> Launchpad bug 159249 in youtranslate "[needs-upgrade] youtranslate 1.1.9 => 1.1.10" [Undecided,In progress] https://launchpad.net/bugs/159249
[19:24] <pwnguin> so what's a good runtime debugger for gtk applications?
[19:24] <pwnguin> preferably something more than gdb
[19:25] <azeem> pwnguin: nevimer, maybe?
[19:27] <pwnguin> package not found
[19:28] <azeem> pwnguin: http://home.gna.org/nemiver/
[19:28] <azeem> nemiver*
[19:28] <pwnguin> ah
[19:49]  * Kmos gots miro 1.0 working with python 2.5 :)
[19:49] <jdong> :)
[19:51] <Kmos> jdong :)
[19:56] <dfiloni> someone can review this package: http://revu.ubuntuwire.com/details.py?package=wxwidgets2.8 ?
[19:57] <gnudles> hello
[19:58] <gnudles> I'd like to know when will you create gimp 2.4.1 package...
[20:03] <LordKow> https://bugs.launchpad.net/ubuntu/+source/exaile/+bug/163181 debian maintenance for this package seems to be almost non-existent
[20:03] <ubotu> Launchpad bug 163181 in exaile "[hardy] New upstream release <IP_ADDRESS>" [Undecided,New]
[20:04] <somerville32> LordKow, I'll update it.
[20:05] <minghua> gnudles: It's better to contact previous uploaders of wxwidgets2.8 instead of generally asking for review, IMO.
[20:05] <gnudles> update the gimp package to version 2.4.1
[20:05] <LordKow> is gimp a universe/multiverse package?
[20:06] <_MMA_> no
[20:06] <gnudles> I didn't asked for review..
[20:06] <somerville32> LordKow, Can you upload an interdiff?
[20:07] <LordKow> never made an interdiff there a deb helper script for it?
[20:07] <somerville32> No.
[20:07] <somerville32> apt-get install interdiff
[20:08] <somerville32> interdiff the two diff files generated when you build the source package
[20:08] <minghua> gnudles: Sorry, speaking to wrong person...
[20:08] <somerville32> There is a flag you can use so you don't have to decompress them by hand.
[20:08] <minghua> dfiloni: It's better to contact previous uploaders of wxwidgets2.8 instead of generally asking for review, IMO.
[20:08] <LordKow> oh i see
[20:08] <gnudles> a bot?
[20:09] <LordKow> okay i'll run interdiff against the 0.2.11 diff and my <IP_ADDRESS> diff and attach it
[20:09] <somerville32> LordKow, Thank you muchly
[20:10] <gnudles> but gimp is based on GTK, not on wxwidgets....
[20:10] <gnudles> just update it... please, It's very important package...
[20:11] <LordKow> what would be the standard way to name a file with the output of interdiff?
[20:13] <_MMA_> Hey guys. A idea to blow off some steam came out of UDS that Ive been working on. Just a little game server we can run around in.
[20:13] <_MMA_> The development page: https://wiki.ubuntu.com/CommunityGameServer and the "Solid info" page: https://help.ubuntu.com/community/CommunityGameServer (both a work in progress) I have 2 games done now.
[20:13] <_MMA_> If you wanna help us test the Warsow server now hit me up in PM.
[20:15] <LordKow> i didnt use debdiff, let me do that. i think it will produce the same results but its best to do it debian style whenever possible
[20:19] <minghua> LordKow: interdiff is preferred over debdiff because debdiff would include all upstream changes as well, which we don't want.
[20:19] <LordKow> okay well i uploaded a giant selection of things
[20:19] <LordKow> debdiff, interdiff, orig src, dsc... diff gz
[20:19] <LordKow> go for it :P
[20:20] <somerville32> jdong, come for a visit to #xubuntu-devel svp :P
[20:21] <somerville32> LordKow, ermm...
[20:22] <LordKow> i wasnt quite sure what to do with the debian directory because apparently the exaile devs try to maintain it too
[20:23] <somerville32> LordKow, Can you do a -p1 with that interdiff
[20:24] <somerville32> The interdiff is not useful because it shows both copies of everything because the top directory name is different
[20:24] <somerville32> the -p1 will ignore that so that we get a proper debdiff
[20:24] <somerville32> *interdiff
[20:25] <LordKow> done
[20:27] <somerville32> LordKow, Did you upload it?
[20:27] <LordKow> https://bugs.launchpad.net/ubuntu/+source/exaile/+bug/163181/comments/7
[20:27] <ubotu> Launchpad bug 163181 in exaile "[hardy] New upstream release <IP_ADDRESS>" [Wishlist,New]
[20:27] <somerville32> Much better :)
[20:35] <gnudles> I checked, Gimp is a universe package..
[20:35] <LordKow> Maintainer: Ubuntu Core Developers
[20:35] <gnudles> yes
[20:36] <gnudles> but It was in the list of the universe packages..
[20:36] <gnudles> so where can I get them?
[20:37] <LordKow> there was a site that does backports for ubuntu outside of ubuntu
[20:37] <LordKow> let me find the link, im pretty sure they have gimp 2.4.1
[20:37] <LordKow> http://www.getdeb.net/release.php?id=1760
[20:38] <LordKow> i believe they only package 386 debs so you will need to build the source if you are on another arch
[20:38] <LordKow> i would imagine gimp 2.4.1 will get into hardy. a final release will always have much higher priority over an RC :P
[20:39] <minghua> gnudles: Gimp is in main, not universe.
[20:39] <LordKow> even if its after the appropriate freeze
[20:39] <LordKow> if gutsy has an RC of 2.4.1 it will likely be updated there too
[20:40] <gnudles> but what about al the other users?
[20:40] <minghua> Gimp in gutsy won't be updated unless there is an important bug.
[20:40] <gnudles> ok...
[20:40] <minghua> ...which exists in RC but fixed in 2.4.1, that is.
[20:40] <LordKow> gnudles, what makes the final release much more important than the RC's?
[20:41] <gnudles> but the RC is for 2.4.0
[20:41] <gnudles> not for 2.4.1
[20:41] <LordKow> ah, okay well gutsy will likely not see 2.4.1 thats just how ubuntu works (unless there is a major bug fix)
[20:42] <somerville32> LordKow, Why did you redo rules?
[20:42] <LordKow> it will likely be in backports
[20:42] <LordKow> somerville32, i didnt i copied it from upstream. i wasnt quite sure what to do with the debian folder because exaile maintains one
[20:42] <nenolod> if anyone asks about backports for audacious 1.4, i already did it
[20:42] <gnudles> I'll check the change log..
[20:42] <nenolod> so someone could take my source and do an official one :P
[20:42] <LordKow> look at the orig src and you will see a debian folder
[20:43] <LordKow> i guess i should have diff'd it to make sure we (ubuntu) didnt put in any ubuntu-specific things to the rules
[20:44] <somerville32> LordKow, right.
[20:44] <LordKow> our rules though are almost always verbatim to debian (are they not?)
[20:44] <somerville32> LordKow, You didn't look?
[20:45] <somerville32> You cut out a lot of stuff
[20:45] <gnudles> I think it's quiet important bug fixes
[20:45] <gnudles> http://developer.gimp.org/NEWS-2.4
[20:45] <somerville32> We don't use upstream's  debian/ directory
[20:45] <LordKow> well as i said, make sure you look at the debian folder because im not quite sure what to do when the maintainers of the software also maintain a debian folder
[20:45] <LordKow> are we supposed to merge with them? or keep our own?
[20:46] <somerville32> Well, we don't just replace our stuff with their stuff
[20:48] <gnudles> anyway, thanks..
[20:49] <LordKow> okay i jacked up the rules, i accept it ;)
[20:50] <frafu> Hello, could anybody please tell me whether the people that review the packages in REVU, do review them with the available patches applied, or before applying the patches? (I am asking because the package that I am talking about does not have complete copyright and license information)
[20:50] <LordKow> honestly somerville32, you should just do the upgrade yourself its basically a 1 minute max deal. the most work would be merging upstream rules with ours
[20:51] <frafu> The patches complete that information.
[20:54] <sistpoty> hi folks
[20:54] <LordKow> i really think software developers should not include debian in their original source code let debianization happen downstream at the appropriate level
[20:54] <bddebian> Heya sistpoty
[20:54] <sistpoty> hi bddebian
[20:55] <bddebian> frafu: I'm not sure I understand your question but debian/copyright should be populated regardless of patches
[20:58] <minghua> frafu: Where is this patch about copyright/license information coming from?
[20:58] <frafu> bddebian: I am talking for example about the missing gfdl license text; the debian folder is ok
[20:58] <siretart> hey sistpoty, hi emgent!
[20:58] <sistpoty> hi siretart
[20:59] <emgent> hey :D
[20:59] <frafu> I am a maintainer of the package; I added the patch to not raise the version number
[21:03] <frafu> debian copyright is ok, but the manual has an error, so that it does not show the license; moreover, the file that contains the complete license text is missing before applying the patch
[21:06] <bddebian> I would say that is generally frowned upon because upstream should be providing a license.  How do we know you aren't just sticking whatever license you want in there? :-)  Of course I am no where near an expert on licensing issues
[21:09] <frafu> bdebian: I am one of the maintainers; moreover, I am the guy who wrote the manual 8-)
[21:10] <frafu> I am upstream
[21:10] <somerville32> bluekuja, Hey. Is there any reason why you changed the versioning for exaile by dropping the debian version?
[21:11] <somerville32> bluekuja, Okay. never mind.
[21:12] <somerville32> bddebian, Should I remove debian/ from the orig tarball or just endure the added delta?
[21:13] <bddebian> somerville32: Sorry, for what ?
[21:13] <bddebian> frafu: So add the file like it should be :)
[21:13] <somerville32> bddebian, For a package :P
[21:13] <somerville32> bddebian, If upstream ships a debian/ directory
[21:13] <bddebian> somerville32: Get upstream to remove it :-)
[21:13] <somerville32> bddebian, Yes but for the time being :P
[21:14] <bddebian> Probably should repack it but I'm never sure
[21:14] <somerville32> bddebian, Would you upload if I didn't?
[21:17] <frafu> bddebian: if I add the file, the source tree does not correspond anymore to the tarball we produced for the release. Will that not be a problem? (we forgot to add the file with the gfdl text in the release)
[21:18] <slangasek> frafu: I would suggest using the pristine tarball from the upstream release and add the licensing info in the diff only
[21:19] <slangasek> frafu: there are lots of cases where we effectively have to trust the packager's statements about the license, so this isn't really a big deal
[21:21] <minghua> frafu: Are you talking about the content of the GFDL text here?  In that case I think you don't even need to include that, just saying which files are licensed under GFDL in debian/copyright, and referring to /usr/share/common-licenses/GFDL-1.2 should be enough, IMHO.
[21:24] <bddebian> frafu: slangasek would certainly know more than me :)
[21:24] <bddebian> somerville32: I might but I'm a moron ;-)
[21:24] <drarem> so i have glade and anujta, is that all i need for gtkmm or is there another recommended route to go?  I want to make cross-compatible applications (using the ftp lib stuff) and a nice gui?  I notice resizing controls in glade is a pain or non-existant
[21:29] <LordKow> bddebian, have some self-esteem :P
[21:30] <frafu> slangasek: I just tried: debuild -S copies the license from the in the ...diff.gz; so everything should be ok!?
[21:32] <frafu> thanks to all for your help
[21:32] <Kmos> https://wiki.ubuntu.com/PackagingGuide/Basic#ChangingOrigTarball
[21:33] <LaserJock> LordKow: he can't, it's impossible
[21:34] <sistpoty> Kmos: if upstream changes the orig tarball it's not much of a problem imho, see the rationale given there
[21:34] <bddebian> LaserJock: You got it :)
[21:34] <Kmos> sistpoty: this is for somerville32
[21:35] <sistpoty> then maybe you should add a highligh for him, Kmos ;)
[21:35] <Kmos> I think the orig tarball even with debian dir inside it, don't need to be changed. just report a bug upstream to remove it in the next release.
[21:35] <sistpoty> +t
[21:35] <Kmos> sistpoty :)
[21:35] <LordKow> as long as our orig tarball matches debians i think we're fine
[21:36] <LordKow> things get very difficult if our source tarballs are different than debians, especially when it comes to merging.
[21:36] <LaserJock> yes
[21:36] <LaserJock> I did that once
[21:36] <LaserJock> it's no fun
[21:37] <sistpoty> hah, and then you do everything correctly, where upstream provides a .zip and even have that get-orig-source thingy and end up with a different tarball from your sponsored package in debian (happened to me *g*)
[21:38] <sistpoty> (and I wrote that changing the orig tarball section in the first place *g*)
[21:38] <LaserJock> I forgot to remove the build stamp
[21:38] <frafu> kmos: you link says that I should not change the tarball (if I get it right; I am rather new to this) ;-)
[21:38] <LordKow> the latest debian unstable of exaile does not have the debian folder in its orig src
[21:38] <LaserJock> so it somehow got into my .orig.tar.gz
[21:38] <LaserJock> that's was a real "doh!" moment
[21:38] <Kmos> frafu: yes, but there are situations that you can change.. read more :)
[21:39] <LordKow> now, im not sure if the exaile developer added the debian folder to his latest src or if debian is removing it. regardless i think our orig src should not have it.
[21:39] <LordKow> orig src tarball should have no debianization in it
[21:39] <Kmos> LordKow: mail the debian maintainer to know about it :) you already reported upstream a bug to remove it from tarball ?
[21:39] <frafu> LordKow: what do you mean by: "as long as our orig tarball matches debians"
[21:40] <LordKow> frafu, if our src tarball is different than debians (same version of the package) then its difficult to merge with upstream even if its just releasing a new patch based on the same src
[21:41] <LordKow> debian does everything against the src tarball, so do we. if the src tarballs are different than debian applied patches may fail against our src, for instance.
[21:41] <sistpoty> frafu: if a package is both in debian and in ubuntu and we introduce a new upstream version and later debian does the same (and introduces a different orig.tar.gz than we have), it ends up in the manual merge section
[21:42] <somerville32> http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
[21:42] <somerville32> I'm a little fuzzy about the XB-*
[21:42] <Kmos> somerville32: with XB- you can remove debian/pyversions
[21:43] <somerville32> XS goes in the first paragraph
[21:43] <somerville32> XB in the second, right?
[21:43] <Kmos> yes
[21:43] <somerville32>  So I can ignore dpkg-genchanges: warning: unknown information field 'Xb-Python-Version' in input data in package's section of control info file ?
[21:44] <Kmos> somerville32: no, you can add it to your debian/control
[21:44] <Kmos> Package: startupmanager
[21:44] <Kmos> XB-Python-Version: ${python:Versions}
[21:44] <Kmos> for example
[21:44] <Kmos> in the second
[21:44] <Kmos> XS- goes after Standards-Version: 3.7.2
[21:45] <somerville32> I have XB- in the second paragraph
[21:45] <Kmos> XS-Python-Version: current
[21:45] <somerville32> I have XS-Python-Version: current, >= 2.4
[21:46] <somerville32> The pyversions had 2.4-
[21:46] <Kmos> somerville32: http://svn.debian.org/wsvn/python-apps/packages/startupmanager/trunk/debian/control?op=file&rev=0&sc=1
[21:46] <Kmos> somerville32: it's a package for hardy ?
[21:47] <LordKow> Kmos, https://bugs.launchpad.net/ubuntu/+source/exaile/+bug/163181
[21:47] <ubotu> Launchpad bug 163181 in exaile "[hardy] New upstream release <IP_ADDRESS>" [Wishlist,New]
[21:47] <LordKow> ignore all my attach's they're bogus
[21:48] <DaveMorris> can someone please review my small package http://revu.tauware.de/details.py?package=cpptest
[21:48] <somerville32> Kmos, Yes.
[21:48] <LordKow> with regards to exaile, the question as to whether the debian folder should be included in the orig src tarball is very important. what will be done to it upstream in sid?
[21:49] <Kmos> LordKow: +Section: universe/devel , why universe/devel ?
[21:50] <somerville32> Kmos, LordKow said to disregard his work. I'm doing it now.
[21:50] <Kmos> somerville32: nice :) i'm not a motu, i just try to hlep
[21:50] <Kmos> help
[21:50] <somerville32> Kmos, He used the upstream debian directory
[21:51] <LordKow> yea there are actually a lot more issues with exaile than i originally thought. needs quite a bit of review which should be left to the MOTU team :)
[21:51] <bddebian> Should be done by the damn Debian maintainers
[21:51] <LordKow> exactly
[21:51] <sistpoty> DaveMorris: give me a little bit time, and you'll get a review ;)
[21:51] <LordKow> i was going to leave it out of ubuntu but the debian maintainer is slacking
[21:52] <bddebian> Have you poked them?  There is a maintainer and co-maintainer and they did upload in 2007
[21:52] <Kmos> i've reported a bug to BTS about exaile new upstream version
[21:52] <LordKow> BTS?
[21:52] <Kmos> let's see if lazy maintainer do something :)
[21:52] <DaveMorris> thanks, I'll be here for a bit
[21:52] <LordKow> Kmos, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451549
[21:52] <ubotu> Debian bug 451549 in exaile "New upstream version <IP_ADDRESS>" [Wishlist,Open]
[21:52] <somerville32> Well, I'm going tto finishh tisu p and we can meerge/sync latre. :]
[21:52] <Kmos> LordKow: exactly
[21:52] <LordKow> thats you?
[21:53] <Kmos> yeah
[21:53] <LordKow> oh cool ;p
[21:53] <somerville32> LordKow, Is he some demi-guru? :P
[21:53] <LordKow> i only brought this down to the ubuntu level because i noticed that 0.2.11 was never put into sid so i figured it was not being maintained well at all
[21:54]  * Kmos not gutu
[21:54] <Kmos> lol
[21:54] <Kmos> *guru
[21:57] <bddebian> LordKow: It's OK, I think we have already jumped Debian versions anyway but poking the maintainer is the "right thing to do"
[21:58] <LordKow> yea we did with 0.2.11
[21:59] <LordKow> basically what im saying is we need to keep our version as close to debians non-existent version so that when/if debian updates exaile we can easily merge with it
[22:00] <LordKow> just 1 more package that can be merged more easily without a lot of work
[22:00] <sistpoty> DaveMorris: please don't override lintian
[22:00] <somerville32> LordKow, You obviously don't know bddebian. He demands hard merges.
[22:00] <LordKow> k :P
[22:00] <somerville32> Only ones he does.
[22:00] <sistpoty> DaveMorris: though I haven't test-built it yet, it seems weird to me to ship a shared object in a -dev package
[22:01] <DaveMorris> sistpoty: I thought you where ment to for a good reason
[22:01] <sistpoty> DaveMorris: so what's the reason to do so
[22:01] <DaveMorris> sistpoty: its for unit testings and I didn't see the point of having a libcpptest and a libcpptest-dev
[22:01] <sistpoty> +?
[22:01] <DaveMorris> as you'll only usee the -dev version
[22:02] <Kmos> bug 163208
[22:02] <ubotu> Launchpad bug 163208 in exaile "Please remove debian directory from tarball" [Undecided,New] https://launchpad.net/bugs/163208
[22:02] <Kmos> :)
[22:02] <sistpoty> DaveMorris: so there is no real point in linking to the shared library?
[22:02] <DaveMorris> only as a programmer  who will need the header files etc
[22:03] <DaveMorris> its the same as cppunit I believe
[22:04] <sistpoty> DaveMorris: but a progammer might want to use shared linking against libcpptest? or would he only be interested in static linking?
[22:04] <sistpoty> (he/she of course to be political correct)
[22:04] <LordKow> well Kmos, somerville32 is working on the new version :P
[22:04] <LordKow> i think he is aware of it
[22:04] <DaveMorris> I personally link using the shared object in my programming
[22:04] <bddebian> sistpoty: You are already looking at cpptest?
[22:04] <sistpoty> bddebian: yep
[22:05] <bddebian> Ah good I'll stop then :-)
[22:05] <sistpoty> DaveMorris: then it makes sense to build a shared library as well (I guess you know the library packaging guide?)
[22:05] <DaveMorris> there should be a shared object lib in that package
[22:06] <sistpoty> bddebian: hehe
[22:06] <LordKow> whats the best/easiet way to report bugs in the debian system?
[22:06] <sistpoty> DaveMorris: but if s.o. wants to link against it, it should use the normal library packaging scheme (which means that a shared object should go in a package with the name of the soname)
[22:07] <bddebian> LordKow: Build a new package, upload to mentors and ping the maintainer pointing them at the new package :_)
[22:07] <DaveMorris> since there  is no point  having it as a seperate package IMO since it'll only ever be used by people using the -dev package
[22:07] <bddebian> Of course that did work for me with valknut or pybliographer...
[22:07] <LordKow> thnx
[22:07] <bddebian> Err did NOT work for me :)
[22:07] <sistpoty> DaveMorris: let me think about this for a few minutes (while I'm out for a smoke...)
[22:09] <bddebian> Gah WTF was I thinking starting a build on an 8Mb source package when I want to go home :(
[22:10] <LordKow> okay well if debian does exaile upstream correctly according to their specs, then debian folder shall not be in the src tarball :)
[22:10] <somerville32> bddebian, Just walk away :P
[22:12] <bddebian> heh
[22:12] <jdong> somerville32: NEVER what if it FTBFS'es as soon as you leave??
[22:12] <somerville32> jdong, Than you find out when you come back :]
[22:13] <bddebian> I didn't screen and I'm ssh'd to home so I can't walk away :(
[22:13] <DaveMorris> start it in a screen and reconnect when you get home
[22:13] <LordKow> bddebian, now if you're really unlucky the build will fail at the end :P
[22:13] <LordKow> use ccache? heheh
[22:14] <jdong> LordKow: heh idn, I wouldn't trust a build done in ccache for verification purposes
[22:14] <jdong> I recall from Gentoo days there were some pretty weird effects with ccache at times
[22:14] <LordKow> true
[22:15] <LordKow> yea jdong, i dont use ccache for that reason and the fact that i dont have enough disk space
[22:15] <jdong> though, yeah, it's the most irritating thing ever when a build fails at one of the last steps :D
[22:15] <LordKow> the problem with Gentoo is its so user specific that its hard to distinguish true bugs from jacked up systems
[22:16] <jdong> LordKow: agreed -- trying to isolate user error from a bug report is the hardest thing ever
[22:16] <jdong> I recall bugs being posted where the user has a 4-line CFLAGS variable
[22:16] <LordKow> LOL
[22:16] <jdong> lol no joke :)
[22:16] <bddebian> LordKow: Nah it died on build-deps so I got lucky :-)
[22:16] <sistpoty> DaveMorris: I guess what you want to do is to ship the shared object as "private" under /usr/lib/<packagename> in the -dev package. that way only people having the -dev package can link against it and you don't need to care about library packaging
[22:16] <LaserJock> jdong: I had one of those ;-)
[22:16] <LaserJock> at least 3 lines
[22:17] <LordKow> a mile long USE= flags are never good either
[22:17] <DaveMorris> sistpoty: how do you do that?  I've not heard of it beforre
[22:18] <jdong> http://bugs.gentoo.org/show_bug.cgi?id=74072
[22:18] <jdong> *THAT* is the one
[22:18] <ubotu> bugs.gentoo.org bug 74072 in Unspecified "ld errors" [Trivial,Resolved: wontfix]
[22:18] <sistpoty> DaveMorris: move it around in debian/rules, or change the upstream make files (and probably adjust whatever needs adjusted, e.g. a *.pc file)
[22:18] <bddebian> usually configure --libdir will do it or you may need -rpath
[22:19] <sistpoty> or that ;)
[22:20] <LaserJock> jdong: that's quite funny
[22:20] <jdong> LaserJock: I'm shocked nothing else broke for him :)
[22:20] <DaveMorris> so instead of installing it to /usr/lib install it to /usr/lib/cpptest/
[22:21] <LordKow> hahaha those CFLAGS are ridiculous
[22:21]  * DaveMorris looks at how to do that in cdbs
[22:21] <LordKow> i stick with -march=k8 -O2 -pipe
[22:22] <sistpoty> jdong: lol, I've always thought that gentoo encourages to use -f-omg-superfast *g*
[22:23] <jdong> LordKow: likewise, the most I optimize is a -march close to my arch, -O2, -pipe, and sometimes -fomit-frame-pointer
[22:24] <LordKow> http://bugs.gentoo.org/show_bug.cgi?id=74072#c2 <-- LOL
[22:24] <jdong> and I don't even like applying -fomit-frame-pointer across the system
[22:24] <ubotu> bugs.gentoo.org bug 74072 in Unspecified "ld errors" [Trivial,Resolved: wontfix]
[22:24] <slangasek> (.oO -O99 -pipe -hash -smoke-it)
[22:24] <sistpoty> haha
[22:24] <jdong> slangasek: sadly I have seen -O99 suggested on Gentoo Forums as future proofing....
[22:25] <jdong> and people do rebuild all the packages on their system everytime GCC/glibc gets a minor version bump
[22:25] <jdong> I cringe to think about the carbon footprint of Gentoo :D
[22:25] <sistpoty> hm... I could abuse university compution power, but I'm too lazy :D
[22:25] <LordKow> 4th largest supercomputer in the US about a block from me... >:)
[22:26] <LordKow> that would help out ubuntu's build queue quite a bit
[22:26] <somerville32> Slowest computer in the world, 30cm from my feet
[22:26] <RainCT> hi
[22:26] <bddebian> Later gang
[22:26] <sistpoty> cya bddebian
[22:26] <LordKow> later bddebs
[22:27] <RainCT> are PNG's on /usr/share/pixmaps required to be 48x48 or are 32x32 also ok?
[22:27] <RainCT> /me would prefer not to use uuencode
[22:27] <sistpoty> LordKow: nothing of that scale around here, but if it were I'd set up a heat pipe directly to my office (it's freaking cold in there in winter time)
[22:27] <LordKow> hm time to lurk the bug reports looking for a simple bug to fix
[22:27] <jdong> bug 163185   <-- is hell freezing over yet?
[22:27] <ubotu> Launchpad bug 163185 in ubuntu "ubuntu freezes completely (all graphics and mouse) when executing shell ascii forkbomb" [Undecided,Invalid] https://launchpad.net/bugs/163185
[22:27] <LordKow> heh sistpoty you need my dual opteron desktop. one of the first revisions and they run like a furnace
[22:27] <sistpoty> hehe
[22:28] <LaserJock> man, that sounds good
[22:28] <LaserJock> I don't want to  have to pay for the electricity bill thoug
[22:28] <LaserJock> +h
[22:28] <jdong> LOL @ reproducing steps
[22:28] <jdong> (1) open shell (2) type in forkbomb (3) computer freezes
[22:29] <sistpoty> we need to shutdown everything unused over christmas, due to 1) electricity bill but much more due to 2) heating costs *g*
[22:29] <Fujitsu> jdong: Blink.
[22:29] <Fujitsu> That has to go on one of the top 10 stupid bug lists.
[22:29] <LordKow> jdong, that actually does bring up a good point. should ubuntu be setting the max process limit?
[22:29] <jdong> LordKow: IMO no... it should make it easy, however, for users to set one via the User and Groups applet
[22:30] <Fujitsu> jdong: I like your response: `One should avoid typing in forkbombs into the terminal if one does not want to forkbomb his computer.'
[22:30] <sistpoty> LordKow: it should and it does (as far as i can tell right now)
[22:30] <jdong> Fujitsu: hehe I tried to disguise a bit of humor in there :D
[22:31] <LordKow> i might as well link that bug report to every linux distribution known to man :P
[22:31] <jdong> sistpoty: does it? I don't see it on Gutsy at least
[22:31] <sistpoty> mom.
[22:31] <jdong> that was the first vulnerability I found on my shared shell setup :)
[22:31] <sistpoty> !pastebin | sistpoty
[22:32] <LordKow> sistpoty, i dont think it does
[22:32] <keescook> we do set a max process limit.
[22:32] <jdong> Fujitsu: next we'll get "All files are deleted when executing rm -rf command" and an argument why Ubuntu should have an undo/cancel command for that :D
[22:32] <keescook> it's based on available physical memory (this is the default for modern kernels)
[22:32] <LordKow> keescook, where?
[22:32] <keescook> LordKow: ulimit -u
[22:32] <jdong> keescook: it's not enough to stop a forkbomb, is it?
[22:32] <sistpoty> that's what I get: http://paste.ubuntu-nl.org/44816/
[22:33] <jdong> 8180
[22:33] <LordKow> ah okay, its dynamic
[22:33] <keescook> jdong: since a forkbomb won't every stop, no.  ;)
[22:33] <LordKow> or not
[22:33] <sistpoty> (though my .zshrc my interfere *g*)
[22:33] <slangasek> jdong: it may not be enough to prevent the fork bomb from spinning in an infinite loop trying and failing to fork more processes
[22:33] <slangasek> but it will limit the total number of processes forked
[22:34] <jdong> slangasek: right; I doubt a system with 5000+ spinning processes will be all that interactive!
[22:34] <keescook> it's hard to protect someone from themself.  ;)
[22:34] <LordKow> of course if we took this far we could create some sort of shell wrapper script that parses the command to check for this sort of thing before initiating the command
[22:34] <keescook> in non-desktop shared environments, admins will usually set nproc much lower
[22:35] <keescook> LordKow: sure, but then the griefer would just adjust the syntax a little.
[22:35] <LordKow> "Running command <command> may lock your system, continue?"
[22:35] <Fujitsu> Ew.
[22:35] <jdong> LordKow: You are executing a command. Cancel or Allow? :)
[22:36] <jdong> The command "oowriter" may cause your system to become slow or unstable. Cancel or Allow?
[22:36]  * jdong ducks
[22:36] <somerville32> lol
[22:36] <sistpoty> haha
[22:36] <LaserJock> Cancel! Cancel!
[22:36] <Fujitsu> s/may/will/
[22:36] <LordKow> it would check the syntax and thats all
[22:36] <keescook> bash: function call loop detected, aborting.
[22:38] <slangasek> jdong: well, you can nice the users who are inclined to do stupid things with their shells, and then it'll be nice and interactive for everyone else. ;)
[22:38] <jdong> aren't there people who have tried to write heuristic forkbomb detectors/preventers for Linux/OpenBSD?
[22:38] <jdong> I recall seeing a kernel patch relating to that before
[22:43] <LordKow> bug 163188
[22:43] <ubotu> Launchpad bug 163188 in yelp "spelling and information issues " [Undecided,New] https://launchpad.net/bugs/163188
[22:43] <LordKow> does anyone know where exactly these typos are?
[22:44] <LordKow> oh i found it
[22:46] <RainCT> whree should html documentation be installed?
[22:46] <RainCT> *where
[22:46] <sistpoty> DaveMorris: any reason to ship an older version of cppunit than available on sourceforge?
[22:47] <sistpoty> RainCT: /usr/share/doc/<packagename>/html
[22:47] <RainCT> ok, thanks sistpoty
[22:49] <DaveMorris> my package is cpptest, not cppunit
[22:49] <sistpoty> DaveMorris: sorry, of course cpptest
[22:50] <sistpoty> DaveMorris: hm
[22:50] <sistpoty> DaveMorris: sorry, been clicking on the wrong links
[22:51] <DaveMorris> sistpoty: I'vee just up loaded a revised version with you suggestions
[22:51] <DaveMorris> linitan warrns about pointless calls to ldconfig but I have no idea how to stop them
[22:52] <RainCT> do *.install files accept regex?
[22:53] <slangasek> RainCT: I believe they only accept globs
[22:53] <RainCT> globs?
[22:54] <slangasek> RainCT: aka, "*"
[22:54] <RainCT> ah ok
[22:55] <jdong> globs: Regex Home Basic Edition :)
[22:55] <RainCT> so if I want to install everything in folder "data" that doesn't start with "html*", I've to copy everything and then remove the html* files?
[22:55] <sistpoty> DaveMorris: where can I actually download cpptest? (debian/copyright refers to the cppunit sf page, and I can't find a link there)
[22:58] <DaveMorris> sistpoty: you missed that I linked to the cppunit page when it sould of been cpptest
[22:58] <DaveMorris> hence why you though I had an old version
[22:58] <DaveMorris> let me fix it
[22:59] <sistpoty> DaveMorris: ah, ok.
[22:59] <DaveMorris> http://cpptest.sourceforge.net/ anyway
[23:01] <DaveMorris> I hate it when I make stupid mistakes like that
[23:02] <sistpoty> so do I, and I tend to make lot's of these
[23:03] <DaveMorris> hence the revu process I guess :)
[23:03] <sistpoty> DaveMorris: btw.: the patch you're adding via debian/patches about the .pc file: that's a new file rather than a change to an old one, right?
[23:03] <DaveMorris> yeah new one
[23:03] <DaveMorris> I was told before thats the better way to do it
[23:04] <sistpoty> DaveMorris: I'd just put it under debian and include it in the .install rule, but both have its benefits (and it's not wrong to do it either way)
[23:05] <LordKow> https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/163076 is this something i can do or is there some automated system for this?
[23:05] <ubotu> Launchpad bug 163076 in multipath-tools "New upstream version available" [Undecided,New]
[23:06] <LordKow> basically just needs an upstream merge
[23:06] <LordKow> i guess i should have checked if this is even a universe package :P
[23:06] <LordKow> nope, k nvmnd
[23:07] <sistpoty> DaveMorris: if I'm not mistaken the ldconfig call is generated from dh_makeshlibs (you could of course export DH_VERBOSE=1 in debian rules to get the details from the build (log).) However I'm not sure how to make cdbs not call dh_makeshlibs.
[23:08] <DaveMorris> am I allowed to leave those calls there?
[23:08] <DaveMorris> dh_makeeshlibs does do it as I learn't that earlier
[23:10] <sistpoty> DaveMorris: well, these are unneeded... if this is the only issue, I'd say why not (since a regular user won't install the -dev package and thus won't have delays in installing/upgrading)(
[23:10] <sistpoty> DaveMorris: of course if you want to dig, you could try to see if dh_makeshlibs can be tweaked into not adding that call for a known shared object (by looking at the man page first, and in doubt at the code)
[23:11] <norsetto> sistpoty: there is a flag you can pass in cdbs to avoid dh_makeshlibs inserting a ldconfig call in the maintainers script. Is that usefull?
[23:12] <sistpoty> norsetto: sure, I guess DaveMorris would be interested ;)
[23:12] <slangasek> er, why are you having to override dh_makeshlibs then?
[23:13] <sistpoty> slangasek: building a shared object in /usr/share/<packagename>/
[23:13] <slangasek> ...
[23:13] <slangasek> that's an FHS violation
[23:13] <sistpoty> slangasek: where would these go then?
[23:13] <slangasek> I don't know, what is it?
[23:14] <slangasek> binary objects don't belong under /usr/share, though, because /usr/share is for arch-independent data
[23:14] <slangasek> if you're ending up with auto-generated shlibs for the file, that probably indicates the object has an SONAME
[23:14] <DaveMorris> its going into /usr/lib/<package namee>/
[23:14] <sistpoty> slangasek: testing framework for c++ (cpptest)
[23:14] <norsetto> sistpoty, davemorris: its DEB_DH_MAKESHLIBS_ARGS_<package> -n
[23:14] <slangasek> which means it's either a library and belongs in /usr/lib, or it's not a library, should be stowed under /usr/lib/<package name>/, and shouldn't have an soname
[23:15] <sistpoty> slangasek: yes it does, but it wouldn't be of much use for anyone since it's a testing framework (you wouldn't want to link a binary against it, unless you're running a test suite and have the -dev package installed anyways)
[23:16] <norsetto> g'night all
[23:16] <slangasek> sistpoty: then why does it have an soname?
[23:16] <sistpoty> slangasek: that's of course a good question... which I guess goes along the line of why does a soname not change if the compatibility changes *g*
[23:17] <RainCT> Does anyone know why    install/lighyears:: rm -f debian/lightyears/usr/share/games/lightyears/data/html*    isn't removing the files that start with "html*" that were copied there because of an *.install file?
[23:19] <DaveMorris> for the logs it's actually DEB_DH_MAKESHLIBS_ARGS_<pkgname> := -n
[23:20] <sistpoty> slangasek: of course if you believe that if upstream provides a soname it should get library packaging style, (or otherwise if it's shipped as /usr/lib/<packagename> packaging should remove the soname), I'll be happy to know about as I'd really like to know the best practice there
[23:21] <slangasek> sistpoty: well, my point is that dh_makeshlibs is a very mature tool which always DTRT for me, so if you're seeing it do something unexpected, question the upstream library first
[23:21] <slangasek> rather than trying to force it to not be invoked for a given packgae
[23:23] <sistpoty> slangasek: sure, the soname is there (and upstream seems to have gotten it right). however the lib doesn't seem to make much use to link a regular binary against, so what to do then?
[23:24] <RainCT> good night
[23:25] <slangasek> sistpoty: it exists for the purpose of linking against, doesn't it?
[23:25] <slangasek> if so, why make it harder to link things against it by moving it out of /usr/lib?
[23:28] <sistpoty> slangasek: hm... good point, and I guess that's where I wouldn't know how to chose a preference between the counter-argument (need to have install the -dev package to even want to link against the shared object) and this one