[00:01] <norsetto> pschulz01: this link should answer all your needs: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[00:03] <pschulz01> DarkMageZ: Not really..  I want to know how to go from an upstream release 3.0.0 to 3.0.1 (say), given that I have the packaging source (diff) for 3.0.0
[00:04] <LaserJock> pschulz01: cp the new tarball to an .orig.tar.gz and then unpack it and drop in the old debian/
[00:05] <DarkMageZ> like LaserJock said. then just add a changelog entry and build
[00:05] <DarkMageZ> pschulz01, yes. it's really that easy.
[00:05] <Fujitsu> .. or just use uupdate!
[00:06] <LaserJock> yep
[00:06]  * DarkMageZ must look @ this uupdate tool
[00:06] <proppy> Fujitsu: watch/file buddy ?
[00:06] <pschulz01> Fujitsu: I think that was what I was after in the first place!
[00:06] <Fujitsu> proppy: What?
[00:07] <proppy> Fujitsu: I mean is uupdate related to debian/watch file or am I completly mistaken ?
[00:08] <LaserJock> related, but not dependent I don't think
[00:08] <Fujitsu> uscan uses uupdate if it finds a new upstream.
[00:08] <proppy> ok :)
[00:09] <pschulz01> Fujitsu: Woot! That worked.
[00:09] <Fujitsu> pschulz01: Great :)
[00:10] <crimsun> I wonder why pulseaudio/i386 on hardy is showing pending still.
[00:10] <pschulz01> Fujitsu: Now just have to keep doing it otherwise the information will fall off the bottom of my heap.
[00:10] <crimsun> it's built and available for the other arches
[00:10] <pschulz01> Fujitsu: No more tea breaks for me.
[00:11] <LaserJock> crimsun: perhaps an arch: all backlog?
[00:11] <crimsun> LaserJock: ...
[00:12] <Fujitsu> crimsun: Pending == NEEDSBUILD
[00:12] <Fujitsu> I presume you mean Currently Building.
[00:12] <Fujitsu> Oh, wtf... It doesn't even have a builder assigned.
[00:12] <Fujitsu> And there is no cprov to be found.
[00:13] <TheMuso> Woohoo. Pulseaudio for Hardy can be set up to replace the system beep through the pc speaker with a sound of one's own choice.
[00:13] <Fujitsu> TheMuso: Yay!
[00:13] <Fujitsu> crimsun: I saw a bug similar to that a couple of nights back, on a PPA.
[00:13] <TheMuso> Fujitsu: Yeah, I think its time we had something like this. KDE has had it for ages.
[00:19] <crimsun> right.  It doesn't make sense that ndiswrapper, which was uploaded only today, is available in pool, while pulseaudio isn't for i386.
[00:19] <crimsun> Fujitsu: ok, thanks.
[00:19] <Fujitsu> crimsun: Note how it is labeled as building but has no builder or start date.
[00:20] <crimsun> Fujitsu: right.
[00:20] <Fujitsu> == great example of Soyuz's reliability.
[00:21] <TheMuso> Why is pulseaudio i386 only now currently building?
[00:21] <TheMuso> I suspect thats what you are talking about.
[00:22] <crimsun> TheMuso: yes, that's the symptom which is apparently a known issue.
[00:22] <TheMuso> Right
[00:22] <crimsun> (apologies for the gnome-audio snafu)
[00:23] <TheMuso> np
[00:23] <TheMuso> hardy ubuntu-desktop deps are somewhat broken atm anyway, so new installs can't easily be done for the desktop at least.
[00:24] <TheMuso> How long has that been building? I get the feeling for a while now.
[00:24] <Fujitsu> TheMuso: It's not building. Note the lack of builder or start time.
[00:24] <TheMuso> Fujitsu: ah ok.
[00:25]  * TheMuso pulls the source and builds locally. I want to do some testing.
[00:27] <norsetto> night all
[00:28] <TheMuso> Would a give back solve that?
[00:28] <Fujitsu> TheMuso: It may, but it could well not show the button.
[00:29] <Fujitsu> s/may/probably would/
[00:53] <LaserJock> anybody seen this gtk packaging GUI called debcreator?
[01:03] <crimsun> (https://launchpad.net/debcreator)
[01:04] <crimsun> eeek.
[01:04] <crimsun> it looks like text entry fields for control, etc.
[01:05] <crimsun> (is it really adding anything to the end user besides window decorations?)
[01:08] <pschulz01> Does anyone know of a good example of a perl (cgi) package that hooks into Postgres/Mysql. I'm looking for suitable setup scripts.
[01:48] <jscinoz> this is so strange...
[01:49] <jscinoz> I'm trying to package iourt (a modified ioquake3 engine) from source.. if i build it quickly just using "dpkg-buildpackage -rfakeroot" it works just fine.. but if i do it properly "debuild -S -sa" then "sudo pbuilder --build ../iourt-4.0-0ubuntu1.dsc" the compile fails >_<
[01:50] <persia> jscinoz: Could you put your build output in a pastebin?  It sounds like a missing build-dependency
[01:52] <DarkMageZ> you'll need to have all the dependencies from ioquake3 in the control file + any extra to cover the modifications
[01:56] <jscinoz> yeah one second.
[01:56] <jscinoz> just going to try it first with a small tweak to debian/rules
[02:00] <jscinoz> persia, heres as much output before the scroll limit http://pastebin.ubuntu-nl.org/47312/
[02:01] <persia> jscinoz: OK.  Could you paste debian/control ?
[02:01] <jscinoz> yeah one sec.
[02:02] <jscinoz> http://pastebin.ubuntu-nl.org/47313/
[02:03] <persia> jscinoz: Yep.  You need to include the SDL libraries in Build-Depends:
[02:03] <jscinoz> ah
[02:03] <jscinoz> just libsdl-dev?
[02:03] <jscinoz> silly mistake >_<
[02:04] <persia> jscinoz: Grep in /usr/include for SDL_UnloadObject, and then find the package that provides the containing file.
[02:11] <jscinoz> yep it was libsdl1.2-dev
[02:11] <jscinoz> all good now :)
[02:11] <jscinoz> doh >_< i forgot to include the .desktop file i made for it >_<
[02:31] <LaserJock> persia: have you already made a run through ~u-u-s bugs today?
[02:32] <persia> LaserJock: Not yet.
[02:42] <LaserJock> hmm, should I take a Kmos bug?
[02:42] <persia> LaserJock: No reason not to do so: just look at it with care.
[02:44] <LaserJock> hmm, it's a little fishy but it's getting there
[02:46] <LaserJock> I still think it's a bit overkill to add a patch system for a one line diff
[02:46] <persia> I don't think it's worth it.
[02:48] <LaserJock> yeah, but is it worth telling somebody to redo the debdiff
[02:48] <LaserJock> especially when another MOTU said they should add the patch?
[02:49] <LaserJock> seems like people are giving mixed messages
[02:49]  * persia grumbles at people who insist on patch systems
[02:49] <persia> LaserJock: Are there any other patches to the package in the diff.gz?
[02:50]  * StevenK appears
[02:51] <LaserJock> persia: it's a native package ...
[02:51] <jscinoz> argh.. stupid question but.. what is the syntax to leave a blank line in the long-description in debian/control?
[02:51] <StevenK> jscinoz: " ."
[02:51] <persia> LaserJock: I7d suggest that a native package should never have a patch system.  That just doesn't make any sense at all.
[02:52] <persia> LaserJock: Yes, it's worth redoing the debdiff, and yes, it's worth slapping the MOTU who advocated a patch system for a native package.
[02:54] <jscinoz> thanks stevenk
[02:54] <ScottK> LaserJock: What bug?
[02:55] <LaserJock> bug #174239
[02:55] <ubotu> Launchpad bug 174239 in dhelp "Please merge dhelp 0.6.5 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/174239
[02:55]  * ScottK looks to see who needs slapping.
[02:57] <LaserJock> hmmpf
[02:57] <LaserJock> I have to say, working on his bugs aren't very easy
[02:58]  * TheMuso avoids kmos bugs, and has done so for a while now.
[02:58] <StevenK> LaserJock: He doesn't make them very easy, either.
[02:58] <TheMuso> I've dealt with enough of them to know that he's not likely to get a clue any time soon.
[02:58] <persia> Yes.  He's often right about many things, despite being wrong about others.
[02:59] <TheMuso> And I hope, but at at the same time doubt, that he'll request syncs for packages after debian import freeze for good reasons.
[02:59] <LaserJock> so he made a changed one thing in the Makefile, but then includes a changelog entry that  references a different change
[02:59] <ScottK> IMO the odds do make it worth betting the opportunity cost of what I didn't do if I expend the time to look.
[02:59] <persia> LaserJock: That's unfortunately exceedingly common: acceptable work with seemingly random documentation :(
[03:00] <ScottK> TheMuso: He'd been told even before the first round of mass sync bugs for Gutsy not to do it, so don't get too focused on that hope.
[03:00] <TheMuso> ScottK: As I said, I doubt it.
[03:02] <persia> LaserJock: In this case, consider reviewing the patch in https://bugs.launchpad.net/ubuntu/+source/dhelp/+bug/174239/comments/17, which is perhaps more sensible.
[03:02] <ubotu> Launchpad bug 174239 in dhelp "Please merge dhelp 0.6.5 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
[03:02] <ScottK> Well until I was doing research for my recent request to the MC, I didn't know he'd been told not to even before the first time.
[03:02] <persia> Strangely, back in feisty close / gutsy open, the work was of higher quality.
[03:03] <ScottK> Well let's get it fixed then.  We'll recruit an army of new people who have no experience to help out and that'll solve the kwality problem.
[03:04] <Hobbsee> oh dear.
[03:04]  * Hobbsee looks up backscroll
[03:05] <LaserJock> persia: what was of higher quality?
[03:05] <persia> ScottK: Well, no, but it will increase the volume of work, which may be good.
[03:05] <persia> LaserJock: Submissions from kmos
[03:05] <Fujitsu> Well, we've got some easy tasks for new contributors.
[03:05] <Fujitsu> Namely tailing Kmos.
[03:05] <LaserJock> persia: yeah, I think perhaps he's doing some of it on purpose to spite some people
[03:05] <ScottK> Ah.  I thought persia was making a broad statement.
[03:06] <ScottK> LaserJock: I actually don't think he has a dishonest bone in his body.  The scary part is that he really is doing his best.
[03:06]  * TheMuso chuckles at the e2fsprogs mail on gutsy-changes
[03:06] <persia> ScottK: No.  Specific.  Broadly, I think new contributors always make mistakes, and after 10-15 bugs reach a level where their work is demonstrably good (or they leave before reaching that number).
[03:06] <LaserJock> ScottK: but why would the quality go down?
[03:07] <DarkMageZ> what's this kmos thing? it keeps on getting refered to...
[03:07] <Fujitsu> DarkMageZ: Kmos is a contributor.
[03:07] <Hobbsee> fsvo contributor.
[03:07] <Hobbsee> contributor to what, though?
[03:07] <ScottK> DarkMageZ: Kmos is probably the most painfully disruptive person we've had show up here to 'help'.
[03:07] <Fujitsu> TheMuso: I get them all the time.
[03:07] <persia> DarkMageZ: A specific person whose Contributions often don't meet sponsor requirements, and whose submissions take a larger volume of sponsoring time than those of others.
[03:07] <Fujitsu> Though what the heck happened there? Security uploads aren't announced...
[03:07] <ScottK> LaserJock: I dunno.  Maybe he's getting nervous.
[03:08] <Hobbsee> TheMuso: if he reqeusts a whole bunch of syncs after DIF, he is going to die a horrible, painful death.
[03:08] <ScottK> LaserJock: Don't ask me to explain how his mind works.  I've already got a headach.
[03:08] <LaserJock> ScottK: I'd like to think he's not doing it on purpose
[03:08] <Hobbsee> i *doubt* he's that stupid to try again
[03:08] <DarkMageZ> kmos = microsoft sabotor?
[03:08] <ScottK> LaserJock: I don't think he is.
[03:08] <persia> Hobbsee: Careful: there may be reasons for the syncs.  I tend to request heaps of them, especially for edge stuff (not libraries).
[03:08] <Hobbsee> DarkMageZ: may as well be.  have a look at the messages for this month on motu-council@l.u.c
[03:08] <Hobbsee> persia: having seen the last lot...
[03:09] <ScottK> DarkMageZ: I don't think so, but he's the primary reason I'm not doing UUS anymore.
[03:09] <persia> Hobbsee: Yes, I know.  Still, I find that > 70% of his requests actually have some root in a good thing (although it would be quicker for me to address it directly than sort out what he is trying to do).
[03:09] <Hobbsee> persia: then in the interests of time, i'd suggest you take the latter option.
[03:09] <Hobbsee> :)
[03:09]  * Fujitsu likes the addition to /+builds.
[03:09] <Hobbsee> persia: yeah, the pre-DIF ones are.
[03:10] <Hobbsee> persia: the post-DIF ones just seem to be "sync it because it has changes in debian, and might fix bugs"
[03:10] <persia> Hobbsee: Even post-DIF (but I'm an advocate of continued selected syncs / merges post-DIF for non-libraries).
[03:10] <persia> I'd be happy to see lots of sync requests if the update in Debian fixes a known issue.
[03:11] <persia> (this does, however, require documentation of the issue)
[03:11]  * ScottK feels he has done his duty and more wrt Kmos (both helping him when that seemed possible and lately), so whatever happens, he's done with it.
[03:11] <persia> ScottK: Good plan.  Less stress for you :)
[03:11] <ScottK> Yeah.
[03:11] <LaserJock> ok, I think he got this one right
[03:12] <persia> LaserJock: Now for the fun question: would it take you half an hour to process the merge directly?
[03:12] <LaserJock> hmm, probably not
[03:13] <ScottK> And this gets into the negative value thing.  Even when he's right, he suck the productivity out of people.
[03:13] <LaserJock> although he caught something I probably wouldn't have
[03:13] <LaserJock> although I don't know that it's really very important
[03:13] <Hobbsee> the more bugs he files, and the more people become accepting of his low level of quality, (not necessarily accepting the bugs, but not telling him "please don't do this again", and making sure he doesn't) the less i feel like i can be a part of the team.
[03:13]  * Hobbsee shrugs
[03:14] <LaserJock> Hobbsee: right, but it's difficult to blanket reject somebody
[03:14] <persia> Hobbsee: How can we "make sure"?
[03:14] <Hobbsee> lock the LP account.
[03:14] <Hobbsee> MC hasn't appeared to actually do anything about it yet.
[03:14]  * persia notes that LP accounts are easy to open
[03:14] <LaserJock> this is a volunteer, contributor run organization we need to figure out good ways of dealing with such things
[03:15] <Hobbsee> this is true, but there are ways around it.
[03:15] <StevenK> Hobbsee: You can't ignore him?
[03:15] <persia> StevenK: Ignoring is hard: he clutters the sponsors queues, and other fora
[03:15] <Hobbsee> StevenK: it's a perception of quality over the entire MOTU project, rather than ignoring a particular contributor
[03:15] <StevenK> persia: True.
[03:16] <persia> Further, the work he reviews often needs doing, and blanket rejecting it makes it not appetising to someone else.
[03:16] <StevenK> Hobbsee: Oh, your point is he smears our reputation and drags us all down?
[03:16] <Hobbsee> if the quality has dropped to his substandard level, then why should i put in time attempting to fix it?
[03:16] <Hobbsee> StevenK: exactly.
[03:16] <Hobbsee> StevenK: you put that very well.
[03:16]  * ScottK is back.  I had to get alcohol.
[03:17] <Hobbsee> *giggles*
[03:17] <Hobbsee> very large amounts?
[03:17] <StevenK> ScottK: You're starting the -motu drinking game?
[03:17]  * Hobbsee drinks, in preparation for work
[03:17] <ScottK> Hobbsee: Not yet.  The topic just had me headed for the liquor cabinet for solace.
[03:18] <ScottK> StevenK: Every time I complain everyone has to take a drink.
[03:18] <StevenK> ScottK: Then we'll all get smashed in about ten minutes?
[03:18]  * StevenK ducks
[03:18] <ScottK> StevenK: Isn't that the point of drinking games?
[03:19] <StevenK> Heh, yeah well
[03:19] <StevenK> Bit early to start drinking here, anyway.
[03:20] <ScottK> Speaking of mistakes, openssl097 got removed from partner today.
[03:20] <StevenK> It got removed like two days ago
[03:20] <ScottK> It's still today for me.
[03:21]  * StevenK doesn't look at -partner
[03:21] <Hobbsee> and my computer decided to freeze, when looking at the issue, clearly
[03:22] <LaserJock> heh, this is kinda silly
[03:22]  * ScottK doesn't as a rule, but when I saw an upload with a remote code execution unpatched (that I'd expended time to get out of Universe) on gutsy-changes, I got interested.
[03:22] <ScottK> LaserJock: Which?
[03:22] <LaserJock> the Makefile checks the debian/changelog for the package version, and then check to see if the version is the same as what is in the Makefile
[03:23] <LaserJock> so every time you update the changelog you gotta change the Makefile
[03:23]  * StevenK drops his shovel, and fires up the backhoe to dig through the net-snmp merge.
[03:23] <ScottK> Note that the common thread between Kmos and the openssl097 upload is that more and more of us (IMO) have come to view public shaming as the only way to correct bad work.
[03:23] <StevenK> But public shaming has had no effect on him!
[03:23] <LaserJock> ScottK: ah, right
[03:23] <ScottK> StevenK: Not that we didn't try.
[03:23] <LaserJock> that was kinda rough
[03:23] <ScottK> LaserJock: Which, the blog post on openssl?
[03:23] <StevenK> He's like bad in-laws, he just keeps coming back.
[03:24] <LaserJock> ScottK: yeah
[03:24] <LaserJock> that should have been an email to -devel methinks
[03:24] <ScottK> LaserJock: I disagree.  It's partner, it's not part of the Ubuntu development process.
[03:24] <LaserJock> hmm, I guess
[03:25] <LaserJock> although I generally consider partner to be a part of the grand Ubuntu universe
[03:25] <Fujitsu> ScottK: Did you see Colin's comment on the partner-isn't-Ubuntu-you-stupid-LP bug?
[03:25] <ScottK> LP has been modified to make it look like part of Ubuntu (separate issue), but it's not.
[03:25] <ScottK> Fujitsu: Yes I did.
[03:25]  * Fujitsu wasn't pleased.
[03:25] <StevenK> Fujitsu: I didn't, point me at the bug?
[03:25] <Fujitsu> Parter should be a special case of PPA.
[03:25] <Fujitsu> *Partner
[03:25] <LaserJock> Fujitsu: about?
[03:25] <persia> LaserJock: Ummm..  As a Master of the Universe who can't upload to Partner, I think you'd see it different.
[03:25] <Fujitsu> Bug #153798
[03:25] <ubotu> Launchpad bug 153798 in soyuz "canonical partner repo packages showing as "in ubuntu"" [Undecided,Confirmed] https://launchpad.net/bugs/153798
[03:25] <persia> Fujitsu: Yes.
[03:25] <Fujitsu> persia: What?
[03:25] <LaserJock> persia: why?
[03:26] <persia> Fujitsu: "Partner should be a special case of PPA"
[03:26] <Fujitsu> Ah, yes.
[03:26] <ScottK> Fujitsu: Well I like that he supported the concept that it was wrong.  He's not an LP dev, so I don't worry so much about his, it'll be hard.
[03:26] <persia> LaserJock: You aren't the master?
[03:26] <LaserJock> persia: heh, I see
[03:26] <StevenK> Fujitsu: What's wrong with that?
[03:26] <ScottK> When I see a non-canonical person with upload rightw to partner, then there's something to discuss.
[03:27] <StevenK> Fujitsu: I see nothing displeasing about Colin's comment.
[03:27] <ScottK> rightw/rights
[03:27] <LaserJock> well, it just doesn't bother me what they do much with partner
[03:27] <persia> LaserJock: And rightly.
[03:27] <LaserJock> and I consider it to be generally a part of broader Ubuntu
[03:27] <ScottK> LaserJock: It only bother's me to the extent it affects Ubuntu's reputation.
[03:28] <LaserJock> so I would consider -devel an ok place to ask questions about it
[03:28] <ScottK> Uploading known vulnerable software is not a good step.
[03:28] <LaserJock> for lack of a better place perhaps
[03:28] <ScottK> imbrandon blogging got people's attention.
[03:28]  * persia suggests that the issue is resolved, and that there are >1000 issues open that we can resolve that are more worthy of discussion
[03:29] <LaserJock> persia: sure, it's just an interesting thing
[03:29] <ScottK> persia: True, but the meta issue is relevant.
[03:29] <LaserJock> I generally try to only blog positive things
[03:29] <Fujitsu> StevenK: Does it not basically say it won't be resolved in the near future?
[03:29] <LaserJock> but what about when bad things happen, should be discuss things in blogs or no
[03:29] <persia> ScottK: LaserJock: Agreed, but I don't think this is a useful forum for resolution of those issues.
[03:29] <LaserJock> that's the interesting part to me
[03:29] <ScottK> Fujitsu: But that's about like me saying a Gnome bug will be tought to fix, so don't hold your breath.
[03:30] <ScottK> LaserJock: If we only talk about the good stuff we are marketing, not being a community.
[03:31] <Fujitsu> ScottK: This is something that is clearly wrong and most misleading.
[03:31] <LaserJock> ScottK: yeah, but throwing around the dirty laundry isn't necessarily great either
[03:32] <ScottK> LaserJock: I'd say if people don't want blog entries about vulnerable software being uploaded to Ubuntu, then they shouldn't do it.
[03:32]  * persia wonders if it's worth regenerating all the source packages that use the Homepage: header that were sync'd / merged prior to the new dpkg.
[03:32] <ScottK> Additionally, I think proprietary developers working in a FOSS space get less slack.
[03:33] <ScottK> persia: I'd say no.
[03:33] <Fujitsu> persia: The round of rebuilds will catch that, when/if we do them, so I'd wait...
[03:33] <LaserJock> ScottK: proprietary developers?
[03:33] <ScottK> LaserJock: Partner is not a FOSS repository.
[03:33] <persia> Fujitsu: Rebuilds for uploads?  These would all be new-in-hardy packages.
[03:33] <Fujitsu> persia: It's likely that most will be uploaded again at some point, but we'll see...
[03:34] <persia> Fujitsu: Ah.  Good point.
[03:34] <Fujitsu> Those that have been merged likely have maintainers that are alive.
[03:35] <persia> Fujitsu: Hmm..  But are such maintainers concerned?  I just don't know if it's actually an issue.  The package works, it's just the Homepage listings were silently dropped in many cases.  Likely only affects packages.ubuntu.com, if that code is updated to look for the header.
[03:36] <Fujitsu> persia: I meant maintainers in Debian, such that there will be a new version to merge before DIF. But I guess we're far too close for that now.
[03:37] <persia> Fujitsu: That was my thought.  Further, I don't think syncs need rebuild, just merges / refreshes / REVU / patches.
[03:38] <persia> Anyway, I think you're right: it's a late-cycle thing to look to see what packages with Homepage: were uploaded before the new dpkg, and check to see if they still need refresh just before release.
[03:39] <Fujitsu> It would have been a whole lot better if dpkg had been merged earlier.
[03:39] <StevenK> To Ubuntu or Debian?
[03:39] <Fujitsu> The former.
[03:39] <persia> StevenK: to Ubuntu (and, yes, we're all guilty)
[03:42] <StevenK> But merging dpkg is *hard*
[03:42] <persia> StevenK: That's why it was delayed :)
[03:50] <LaserJock> ok, we'll see if I got shot for this
[03:50]  * StevenK shoots LaserJock 
[03:50] <persia> LaserJock: what?
[03:50] <Hobbsee> LaserJock: ponies!
[03:50] <StevenK> Right!
[03:50] <LaserJock> persia: uploading kmos' debdiff
[03:50]  * persia thinks LaserJock is immune to being shot for ponies
[03:50] <StevenK> LaserJock: PONIES!
[03:51] <persia> LaserJock: Remember, it's about the work, not the person.  Certain people just cause more effort when reviewing work.  Please leave a description of what should be done better next time in a comment.
[03:52] <LaserJock> persia: it was actually good except for adding the patch thing, which was nixternal's fault anyway ;-)
[03:52] <persia> LaserJock: In which case, the comment should reflect that.
[03:52]  * persia notes that occasional rare praise is a good seasoning for excoriation.
[03:53] <ScottK> Hello stratus.  I didn't notice you there.
[03:55] <LaserJock> persia: I set it to "Fix Committed" is that alright?
[03:55] <persia> LaserJock: That's what I do: it's not mandatory.  The changelog should be closing the bug.
[03:56] <LaserJock> right, I just didn't want to leave a comment saying I uploaded without changing the status
[03:56] <Fujitsu> It's fairly useless to set it these days; sources have publishing records create as uploads are processed, so the bug will be closed within 5 minutes of the dput.
[03:56] <Fujitsu> s/create/created/
[03:56] <LaserJock> Fujitsu: I just wanted the record
[03:56] <persia> Fujitsu: Agreed.  It's only meaningful in rare cases.
[03:58] <LaserJock> yikes
[03:58] <LaserJock> this person bumped the version for each time he attached a new debdiff
[03:59] <Fujitsu> Haha.
[04:00] <persia> LaserJock: Someone from Debian mentors I expect.  Disabuse them gently, please.
[04:00] <LaserJock> persia: you know I'm a softy ;-)
[04:02] <LaserJock> bah
[04:02] <LaserJock> I think they provided debdiffs to a package they put on REVU
[04:02] <persia> LaserJock: A new package?  Which bug?
[04:02] <LaserJock> new upstream
[04:03] <persia> LaserJock: We do new upstream in UUS as well.
[04:03] <LaserJock> bug #174467
[04:03] <ubotu> Launchpad bug 174467 in gnome-schedule "Please sponsor gnome-schedule-1.2.1 into Hardy" [Wishlist,New] https://launchpad.net/bugs/174467
[04:03] <LaserJock> right, but they put the initial upstream on REVU and then put debdiffs for changes
[04:03] <Fujitsu> That's special.
[04:04] <persia> LaserJock: Ah.  I see.  Generally we prefer all the changes wrapped in one revision, and an interdiff (until I can come up with something better: suggestions welcome)
[04:04] <LaserJock> well, it would have been better to put it all on REVU IMO
[04:05] <persia> LaserJock: I disagree, for all the reasons stated in https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
[04:06] <LaserJock> I don't really see any reasons listed there
[04:07] <persia> LaserJock: Sections 3 & 4: deprecated foo
[04:07] <LaserJock> right, just found that
[04:08] <LaserJock> hmm
[04:08] <LaserJock> well if people review right it shouldn't be a problem, IMO
[04:08] <persia> LaserJock: I consider the matter open for discussion: if you've a suggestion of a better way, please share.
[04:09] <LaserJock> I see the point about it being a bit confusing to have both NEW and updated source packages on REVU
[04:09] <LaserJock> but I don't see why a link to a dget'able would really be a problem
[04:10] <persia> LaserJock: untrusted orig.tar.gz mostly.
[04:10] <LaserJock> but I don't see an issue there
[04:10] <LaserJock> if it's a matter of people not doing a proper job of reviewing shouldn't we fix that?
[04:11] <persia> Essentially, anyone who can upload something gets root on millions of systems.  For those who are insufficiently trusted to be able to upload directly to Debian or Ubuntu, hiding something in the orig.tar.gz is a good way to do interesting things.
[04:11] <LaserJock> right
[04:11] <persia> LaserJock: How do we "fix that"?
[04:11] <LaserJock> but that's the case always
[04:11] <LaserJock> why wouldn't you check?
[04:11]  * ScottK applauds persia's level of paranoia.
[04:12] <LaserJock> we should just put in a New Upstream Release Review checklist to check the .orig.tar.gz
[04:12] <persia> LaserJock: If policy doesn't require get-orig-source / working watch file, how can you check?
[04:12] <LaserJock> you go and download the source
[04:12] <LaserJock> that's what I do anyway
[04:12] <persia> If policy does require it, why would you want to download it twice?
[04:12] <persia> From where?
[04:13] <LaserJock> from the site of the app
[04:13] <LaserJock> same as you would with a NEW package
[04:13] <persia> LaserJock: And how do you get the site of the app?  How about for repacks?
[04:13] <LaserJock> debian/copyright should say where you got the app
[04:13] <persia> LaserJock: I don't like it for NEW either, but I don't have a good model that allows the flexibility of REVU yet.
[04:14] <LaserJock> and for repacks it should be documented
[04:14] <persia> LaserJock: Right.  One of the goals of using interdiff is to change "should" to "must".
[04:15] <LaserJock> but why not just make checking the .orig.tar.gz a  "must" then
[04:15] <persia> LaserJock: No enforcement mechanism.
[04:15] <LaserJock> it seems like added complexity
[04:15] <LaserJock> persia: so? isn't that part of being a MOTU
[04:15] <persia> LaserJock: I make mistakes.  I expect you to make mistakes.  More importantly, I don't expect anyone else to be as paranoid as I am.
[04:16] <LaserJock> right, so we should have a minimal paranoid level and have that be policy
[04:16] <LaserJock> but enforcement should be on MOTUs for the most part
[04:17] <persia> LaserJock: Maybe.  I think it's easier just to not pass around large binary orig.tar.gzs that need reinspection.  Waste of bandwidth.
[04:17] <LaserJock> hmm, perhaps
[04:17] <LaserJock> but I've heard people having problems with interdiffs so I don't think we should make it mandatory
[04:18] <LaserJock> sounds like it might be a good practice and a recommendation
[04:18] <persia> LaserJock: What sorts of problems?
[04:18]  * persia is working on a new system, but wants more input
[04:18] <LaserJock> not being able to recreate the package correctly
[04:18] <persia> LaserJock: Do you have an example?
[04:19] <LaserJock> no sorry
[04:19] <LaserJock> I just remember like a week ago or so somebody saying in here that they were screwed cause the interdiff didn't work, but they may have resolved it
[04:19] <ScottK> LaserJock: Were you at the meeting today?
[04:20] <persia> The only cases I've encountered so far were broken watch files, lack of get-orig-source for repacks, contributors sending interdiff -z -p1 foo bar.
[04:20] <persia> Oh, and one case where the new package didn't match upstream (as upstream hadn't released yet).
[04:21] <LaserJock> ScottK: no sorry, I've actually never been able to make a MOTU Meeting in the last year or so :(
[04:21]  * StevenK wonders if the dpkg in Debian now has triggers.
[04:21]  * Fujitsu forgot about the meeting.
[04:21] <ScottK> LaserJock: No problem.  Just we discussed this today.  Someone (I don't recall who) persia? has started a script to make the interdiff bit easier.
[04:22] <persia> My (weak) script is at http://people.ubuntuwire.com/~persia/process-interdiff (as it has been since the Interdiff docs were posted)
[04:22] <ScottK> Hey everyone...
[04:22] <LaserJock> persia: do you have to have a watch file or get-orig-source for interdiff to work?
[04:22] <ScottK> I'd like to introduce/reintroduce stratus.
[04:22] <stratus> hey :)
[04:22] <ScottK> stratus is a DD interested in becomeing a MOTU.
[04:23] <LaserJock> hi stratus
[04:23] <ScottK> In fact he was my first Debian sponsor.
[04:23] <persia> LaserJock: No, it just makes reconstruction of orig.tar.gz lots easier, and the lack of a working watch file is considered a bug in Debian.
[04:23] <stratus> hey LaserJock, what's up? :)
[04:23] <persia> stratus: Welcome.
[04:23] <LaserJock> stratus: workin' on stuff ;-)
[04:23] <stratus> persia: hey, thanks! :)
[04:24] <stratus> LaserJock: heh as usual, I guess.
[04:24] <LaserJock> persia: hmm, I'm not sure I totally agree with that
[04:24] <LaserJock> stratus: yeah
[04:24] <LaserJock> persia: I've run across sources that may be impossible to automate getting the .orig.tar.gz
[04:24] <persia> LaserJock: Which?  That a watch file should be required?  Especially with team maintenance, how else are we to know about new upstream versions?
[04:24] <stratus> btw, I've forwarded ScottK a entire new package and I will have some patches to other stuff anytime soon
[04:25] <persia> LaserJock: I don't believe you (for non-native).  Show me the package, and I'll write a get-orig-source.
[04:25] <stratus> that's why I decided come out of the shadows again and become a MOTU, since it wil be easier upload by myself in due time
[04:25] <persia> stratus: The best way to get your patches in is likely to attach a debdiff to a bug, and subscribe the ubuntu-universe-sponsors queue.  That way, you don't need to rely only on ScottK (although that works too).
[04:25] <ScottK> Which I'm going to upload for him (he's just moved and is currently GPG key contrained).
[04:26] <stratus> persia: oh, I heard about that. thanks! :)
[04:26] <LaserJock> persia: well, I'm pretty sure I've come across a few  science packages that had no machine downloadable sources
[04:26] <ScottK> Assuming it builds and produces a sane package, I'll advocate it.
[04:26] <stratus> I moved and then went on road to US, so decided to keep my priv key secured at $HOME :)
[04:27] <persia> LaserJock: Really?  Please point me towards them if you encounter them again.  It's likely one of A) Odd upstream, B) Orphaned upstream (and in need of adoption), or C) very weak documentation.
[04:28] <LaserJock> usually A, sometimes B
[04:28] <persia> In the case of A), it's worth checking with upstream to find out why they don't distribute source, and inviting them to use one of the many fine distribution services.  In the case of B, it's worth adopting the package to a new project on one of those distribution services.
[04:29] <LaserJock> there are a few that are no longer available online, but of course then we'd not be expecting a lot of new upstreams
[04:30] <persia> LaserJock: That would be B), and I'd encourage the creation of a project on sourceforge, google code, launchpad, savannah, etc.
[04:30] <persia> Err.  "one of" should be in there somewhere.
[04:30] <LaserJock> well sure, that may be nice
[04:30] <persia> LaserJock: Takes about 20 minutes :)
[04:30] <LaserJock> I'm just saying that you can't assure that 100% of packages have a machine downloadable upstream
[04:31] <persia> LaserJock: Further, it's essential to ensure the code can be shared between all distributions, making the general cause of free software stronger.
[04:31] <LaserJock> yep
[04:31] <LaserJock> I had a talk with Fink (OS X stuff) about watch files once
[04:32] <LaserJock> they wanted to use Debian to track software, but since there were so few watch files it was impossible to do it
[04:33] <LaserJock> perhaps the situation is much better now
[04:33] <persia> LaserJock: Right.  For some things, watch files don't work (I've been given many cases), but even for those, one can construct an orig.tar.gz, as long as upstream exists.
[04:34] <LaserJock> sure
[04:34] <LaserJock> it's not currently that way
[04:34] <persia> Further, for packages updated in Ubuntu, I think it's not much extra effort to generate the watch file / get-orig-source as compared to integrating the new upstream in the packaging.
[04:34] <LaserJock> but it'd be nice
[04:35] <persia> LaserJock: So, in the spirit of "it'd be nice", join in enforcement for new upstream candidates :)
[04:35] <ScottK> persia: But we don't have (widely accepted) something like Debian QA page where you see when your packages need updating.
[04:35] <LaserJock> hmm, that enforcement bit is what gets me ;-)
[04:35] <persia> ScottK: What's wrong with http://qa.ubuntuwire.com/uehs/ ?  For stuff in Debian, I'll trust the maintainer, but for the rest...
[04:36] <ScottK> persia: That's where the 'widely accepted' bit came in.  Now that we have that watch files make more sense, but people have to know about it.
[04:37] <persia> ScottK: OK.  I admit I'm behind on documentation and annoucements :)
[04:37]  * persia notes that others are more than welcome to advocate and promote QA efforts.
[04:37] <ScottK> persia: Is that all of Ubuntu or just Universe?
[04:38] <persia> ScottK: That's just packages in Ubuntu that aren't in Debian and haven't been removed from Debian.
[04:38] <ScottK> OK.
[04:38] <persia> (main+restricted+universe+multiverse)
[04:38] <persia> Essentially, the stuff we're supposed to be maintaining.
[04:39] <ScottK> It'd be interesting to add stuff that's been orphaned in Debian to that as it's officially unmaintained there too.
[04:39] <persia> ScottK: Agreed.  Do you know an easy way to extract that list?
[04:40] <pwnguin> ScottK: you defy the way of the TopPost?
[04:41] <ScottK> pwnguin: I do.
[04:41] <ScottK> persia: Maintainer is set to Debian QA group?
[04:41]  * Fujitsu doesn't think that covers all of them.
[04:42] <ScottK> Doesnt' that get set once something's officially orphaned?
[04:42] <ScottK> Agreed that there's stuff that's abandoned unofficially?
[04:42] <Fujitsu> On the first upload, probably.
[04:42]  * Fujitsu adds them to the list.
[04:42] <persia> Fujitsu: At least the vast majority, no?  The others would be MIA or ITO, but not yet orphaned, I think.
[04:43] <Fujitsu> persia: By ITO you mean RFA?
[04:43] <Fujitsu> Or is there an ITO?
[04:43]  * persia checks
[04:45] <persia> Fujitsu: http://www.infodrom.org/Debian/doc/acronyms.html tells me "Intend to Orphan" is distinct from "Request for Adoption"
[04:45] <Fujitsu> Oh.
[04:46] <persia> Hmm..  On the other hand, http://www.debian.org/devel/wnpp/ tells me it should just be O:
[04:46] <Fujitsu> I would have thought that RFA and ITO would have served similar purposes, right...
[04:46] <Fujitsu> As if you're intending to orphan it, you're asking for somebody to adopt it, but it still has a maintainer, which is what RFA is for...
[04:47] <persia> Fujitsu: I think it depends on the goal.  In the RFA case, the maintainer is looking for someone to take over, but will handle it in the meantime.  In the ITO case, the maintainer is declaring no further interest (which ought be O:, so perhaps I agree with you)
[04:47] <Fujitsu> Hm, I guess.
[04:47] <Fujitsu> Anyway.
[04:47] <persia> So the new filter will be Ubuntu-local + Maintainer: Debian QA Group ?
[04:48] <Fujitsu> I suspect so.
[04:58] <jcastro> http://www.oreillynet.com/linux/blog/2007/12/ubuntu_innovates_excuses.html?CMP=OTC-0O724Z062301&ATT=Ubuntu+Innovates+Excuses
[04:58] <jcastro> you guys see this?
[04:59] <mgunes> jcastro, yes
[04:59] <Fujitsu> jcastro: No, and it doesn't look like I really want to...
[04:59] <LucidFox> Well, bah.
[04:59] <jcastro> well, just wondering
[05:00] <jcastro> I don't even know what aumix is
[05:00] <LucidFox> It's just a rant based on a person's misunderstanding of the Ubuntu development process.
[05:01] <persia> LucidFox: Well, perhaps.  It might also be that we expect a lot from our bug submitters.
[05:01] <jcastro> hahah
[05:01] <jcastro> dude, it's just some ncurses volume thing
[05:02] <jcastro> the article made it seem like the world was collapsing
[05:02] <persia> jcastro: It doesn't really matter what it is: we do the same thing for nearly all reports.  On the other hand, we usually try to fix them in the dev environment first, and are currently reworking our SRU processing to try to catch more of those.
[05:02] <persia> Does anyone happen to know the status of current deliberations for appointing ~motu-sru members?
[05:02]  * jcastro nods
[05:03] <jcastro> persia: I would guess that you guys get dinged for every nook-and-cranny package
[05:04] <persia> jcastro: Well, somewhat.  Bugsquad does an admirable job of filtering the requests.
[05:04] <LaserJock> persia: it's RSN
[05:05] <jcastro> persia: I was being sarcastic, given the stupidity of the article.
[05:05] <LaserJock> jcastro: it's a semi-legit complaint, IMO, but it's kind of a weird thing to blog about
[05:06] <persia> jcastro: Actually, I think the article addresses a valid point: we're very focused on our processes, and have begun to expect all bug submitters to participate.
[05:06] <jcastro> well ...
[05:06] <jcastro> I mean .. come on ...
[05:06] <LaserJock> come on what?
[05:06] <jcastro> i can think of 50 bugs right now that are more important
[05:06] <persia> We'd do better if bugsquad was more freindly, and there were stronger filtering mechanisms feeding the Contributors.
[05:06] <jcastro> than some console volume mixer
[05:06] <LaserJock> we released an unusable package! that's uncool
[05:07] <jcastro> I mean, yeah, I agree, having things busted sucks
[05:07] <persia> jcastro: Maybe, but they are also likely harder.  That's a rebuild: takes all of two minutes to verify, and two minutes to sponsor.  Good for a new contributor.
[05:07] <LaserJock> jcastro: it's actually a fairly used package I think, compared to much of Univerrse
[05:07] <jcastro> I thought alsamixer was the popular curses volume package thing
[05:08] <ScottK2> And if it's actually busted and it's actually a regression, it does qualify for an SRU.
[05:08] <Fujitsu> 1569  aumix                           1967   260  1579   125     3 (Romain Francoise)
[05:08] <Fujitsu> ScottK2: It was rejected because it apparently wasn't fixed in Hardy yet.
[05:08] <persia> jcastro: Indeed, and aumix is not useful on most current Ubuntu systems, but it's still symptomatic of a larger issue.
[05:08] <Fujitsu> (that's from the universe stats, so it's in the top 10%)
[05:08] <mgunes> Hardy seems to have a newer version
[05:08] <jcastro> persia: ok, so now /that/ statement makes sense to me
[05:09] <ScottK> Well that's not a reason to reject it, just say not yet.
[05:09] <jcastro> persia: I still think her bug is an edge case, but you guys are way more experienced in this kind of thing, so continue pls.
[05:09] <persia> jcastro: Essentially, if we release something that's broken (even if it's useless), and it takes 5 minutes to fix, it's better to spend the 5 minutes.  It now being fixed in Hardy (new revision forced a rebuild), it should get SRU attention.  The SRU team doesn't currently exist, so it's in limbo.
[05:10] <LaserJock> jcastro: what package it is is almost irrelevant
[05:10] <mgunes> The person seems to interpret the declining of the SRU nomination as a "wontfix", which isn't the case; the bug's status is "Triaged".
[05:10] <ScottK2> Well that's what decline means.
[05:10] <persia> mgunes: Agreed.  The reporter would have done better to understand it.
[05:10] <Fujitsu> I don't quite see why it was declined...
[05:10] <LaserJock> yes, but it comes across as "well, we're gonna pass on a technicality"
[05:11]  * persia prefers to leave nominations open until there is a specific reason for declination.
[05:11] <jcastro> LaserJock: good point
[05:11] <LaserJock> Fujitsu: because SRUs are supposed to be fixed in Hardy first
[05:11] <Fujitsu> LaserJock: That would at worst leave the task as New or Incomplete.
[05:11] <Fujitsu> Declining says it will not be fixed in that release.
[05:11]  * mgunes subscribes heno
[05:11] <LaserJock> Fujitsu: what is it? I didn't bother to open it?
[05:11] <LaserJock> mgunes: why?
[05:11] <persia> LaserJock: Bug #145805
[05:11] <ubotu> Launchpad bug 145805 in aumix "aumix throws error aumix:  SOUND_MIXER_READ_DEVMASK" [Medium,Triaged] https://launchpad.net/bugs/145805
[05:11] <Fujitsu> LaserJock: The task itself was declined.
[05:12] <Fujitsu> jcastro: Thanks for pointing the article out.
[05:12] <jcastro> LaserJock: I guess it just irks me that someone in the media won't bother to follow up on a bug
[05:12] <mgunes> LaserJock, he may be interested in posting a clarification
[05:12] <LaserJock> jcastro: dude, you can't expect *anybody* to work with our processes
[05:12] <persia> jcastro: The trick is that it's not their job to do so.  It's the job of the Contributors (MOTU & not) to find the triaged bugs, and get the patches in.
[05:12] <ScottK2> LaserJock: The comment that Henrik sounds like a pretty definitive fuck off we ain't fixing it.
[05:13] <jcastro> well, I've had plenty of media people ask me about bugs
[05:13] <persia> ScottK: Yes.  That's a separate issue, and also needs resolution.
[05:13] <jcastro> she could have at least asked someone
[05:13] <mgunes> ScottK2, it's a canned comment, isn't it?
[05:13] <ScottK2> mgunes: It is, but it's the wrong one for this situation.
[05:13] <persia> jcastro: I'd agree that asking a media contact before posting an article is preferable, but it doesn't address the actual issue, which is that the text is not ideal, and the task should not have been declined.
[05:13] <LaserJock> well, that's a policy misunderstanding I think
[05:14] <LaserJock> because a nomination doesn't mean the SRU is approved
[05:14] <jcastro> persia: tbh, she's not exactly ubuntu friendly
[05:14] <persia> jcastro: That's all the more reason why we should fix it internally :)
[05:14] <jcastro> yeah
[05:14] <LaserJock> a nomination should generally be accepted if it's got a chance of making it
[05:14] <jcastro> I'm just whining about her at this point
[05:15] <LaserJock> jcastro: :-)
[05:15] <LaserJock> it's a bit much, but the complaint is legit in this case
[05:15] <LaserJock> IMO at least
[05:15]  * persia triages the bug again
[05:16] <ScottK2> persia: Check what I just did first
[05:16] <persia> ScottK: Excellent.  I'm testing, and expect to close the Hardy task.
[05:17] <jcastro> persia: do you guys typically have your MOTU meetings the time you did today?
[05:17] <Fujitsu> Thankyou ScottK2.
[05:18] <ScottK2> BTW, when you decline a task, LP tells you "... Declining a nomination will show on the bug page that this bug will not be fixed in that specific release."
[05:18] <persia> jcastro: We rotate between 12:00 UTC and 20:00 UTC.  Requests for 04:00 UTC have been few.
[05:18] <ScottK2> So her understanding was exactly correct.
[05:18] <jcastro> persia: does dholbach typically attend?
[05:18] <Fujitsu> ScottK2: That's what I thought.
[05:19] <persia> jcastro: About 75% of the time.  He noted he wouldn't make this one at the last one.
[05:19] <jcastro> persia: ah ok.
[05:19] <jcastro> persia: when he's absent and you need a canonical person to bitch at, I typically always idle on #u-motu and #u-meeting
[05:20] <LaserJock> jcastro: why would we need to do that? :-)
[05:20] <persia> jcastro: We try not to focus on canonical vs. non-canonical in those meetings: more about the community processes and goals for keeping universe in shape.
[05:20] <jcastro> LaserJock: well, we're both on the community team
[05:20] <ScottK2> What's the preferred approach in the .desktop file for a package that needs to run as root and can be used from within KDE and Gnome?
[05:20] <jcastro> persia: well, what I wanted to say was that if you needed to get something to daniel I can do that for you
[05:21] <persia> jcastro: You're more than welcome to attend, and your voice is appreciated, but it's not really a Canonical forum: those meetings are fortnightly on Thursday nights.
[05:21] <ScottK2> Exec=gksu disk-manager isn't getting the job done in KDE.
[05:21] <persia> jcastro: He (as all MOTUs) is expected to read the minutes :)
[05:21] <jcastro> persia: I deal with upstreams, not MOTU, but we're still teammates, and since he's like 5 hours ahead of me, if he's asleep, I can help handle things
[05:22] <jcastro> persia: noted (on the meetings)
[05:22] <persia> jcastro: Thanks for that.  Any opinion on adopting orphaned upstreams into LP projects?
[05:22] <jcastro> persia: I am dealing with one of those now
[05:22] <ScottK2> persia: Why would we want to do that?
[05:22] <jcastro> I don't know what the solution is
[05:22] <persia> ScottK2: Sometimes orphaned code is useful.
[05:23] <ScottK2> persia: Got any thoughts on my .desktop question above^^^
[05:23] <persia> ScottK: No.  I suspect it has to do with the relation of gksu to KDE somehow.  I'm presuming that the same command also doesn't work from the command-line.
[05:24] <ScottK2> No.  It wouldn't
[05:24] <persia> ScottK: We've heaps & heaps of gksu in .desktop files.  Is there a way to get at least a wrapper in default KDE?
[05:25] <ScottK2> persia: Dunno.  I'll ask ridell about it tomorrw.  I guess I'll just leave it gksu for now and sort it out later.
[05:26] <Fujitsu> Hopefully everything will be using Root^WPolicyKit soon.
[05:27] <persia> ScottK: Try with /usr/bin/su-to-root
[05:27] <ScottK2> Trying
[05:28] <ScottK2> persia: bash: /usr/bin/su-to-root: No such file or directory
[05:29] <persia> ScottK: install the menu package.
[05:29] <LucidFox> sikon@lucidfox:~$ which su-to-root
[05:29] <LucidFox> /usr/sbin/su-to-root
[05:29]  * persia grumbles about continuing disconnect between menu planning in Ubuntu and Debian
[05:30] <LaserJock> yeah, loads of fun
[05:30] <persia> Right.  So if su-to-root isn't available by default, and gksu doesn't work in KDE, how should packages gain root if they need it?
[05:31]  * ScottK2 doesn't know.  That's why I asked.  Maybe imbrandon knows.
[05:31] <LaserJock> well, kde apps would use kdesu I would assume
[05:31] <LaserJock> but as far as DE-neutral I'm not sure
[05:31] <ScottK2> LaserJock: Yes.  So then what would Gnome use.
[05:31] <ScottK2> Yeah.  That's the problem.
[05:32] <LaserJock> ScottK: kdesu ;-)
[05:32] <ScottK2> I'm good with that.
[05:32] <ScottK2> Actuall I think we have kdesudo now.
[05:32] <ScottK2> Actuall/Actually
[05:32] <persia> I'm not.
[05:32] <LaserJock> that's why I install both ubuntu-desktop and kubuntu-desktop
[05:32] <ScottK2> I wouldn't expect you to be.
[05:33] <persia> LaserJock: Sure, but we can't expect everyone to do that.
[05:33] <ScottK2> We aren't all so flexible
[05:33]  * persia wants something that works for Gnome, KDE, XFCE, and Fluxbox
[05:33] <ScottK2> If it's a Gnome app, maybe it should just depend on gksu?
[05:33] <LaserJock> persia: of course
[05:33] <jcastro> there's a spec for this
[05:34] <jcastro> I know it was talked about at uds
[05:34] <persia> jcastro: Do you happen to know which?  Also, do you know why we don't just use su-to-root, and include the menu package?
[05:34] <persia> (or the code extracted therefrom)
[05:34] <jcastro> in boston
[05:34] <jcastro> I don't recall ever hearing anything about su-to-root
[05:34] <jcastro> just a policykit session
[05:35] <jcastro> let me dig it up
[05:35] <persia> Ah.  PolicyKit.
[05:35] <jcastro> https://blueprints.edge.launchpad.net/ubuntu/+spec/killall-gksudo
[05:37] <persia> jcastro: That solves a slightly different issue.  In the one case, the app shouldn't have root for most things, and should use PolicyKit (good for main), in the other upstream doesn't do this, and requires root to work, so we need su-to-root or the equivalent (for universe).
[05:37] <jcastro> persia: I don't know one way or another what the implementation details of the spec are
[05:37] <jcastro> I just know the discussion existed
[05:37] <persia> jcastro: Understood :)
[05:37] <persia> (and thanks for pointing to it)
[05:38] <jcastro> we had david zeuthen join the discussion
[05:38] <jcastro> which was cool
[05:38] <jcastro> (the red hat guy)
[05:38] <LaserJock> ScottK: maybe it's worth an email to -devel or -motu?
[05:39]  * persia seconds LaserJock
[05:40] <jcastro> persia: I've seen it working out on fedora8, it's pretty awesome ...
[05:40]  * ScottK is doing actual packaging work right now, so would prefer someone else writes it.
[05:40] <jcastro> it'll rock for hardy+1
[05:40] <persia> jcastro: Agreed.  It's cool, it just requires big patches, which is hard for > 10,000 packages.
[05:41]  * ScottK still has a hard time understanding the point of a common front end for dis-similar backends.
[05:41] <jcastro> agreed
[05:42] <persia> ScottK: That should happen when they perform a common function.  Does it matter if I use midori or konqueror?
[05:42] <ScottK> persia: But they don't.  For one distro they manage RPMs and for another .debs.  They aren't the same.
[05:43] <persia> Ah.  That's just odd.
[05:43]  * TheMuso returns, guessing that the discussion is about policykit
[05:43] <ScottK> TheMuso guesses right.
[05:44] <LaserJock> wait
[05:44] <LaserJock> packagekit or policykit
[05:44] <ScottK> I looked at their web site and I still don't get it.
[05:44] <jcastro> 2 different things LaserJock
[05:44]  * ScottK is talking about packagekit actually.
[05:44] <ScottK> Now that you mention it.
[05:44] <LaserJock> jcastro: I know, it just looked like we were talking about both at the same time
[05:45]  * persia doesn't really understand nor like packagekit.  The semantics of package management differ significantly between packaging systems.
[05:45] <jcastro> persia: it has a backend thing
[05:45] <jcastro> you can use the frontend on fedora or ubuntu and not be able to tell the difference
[05:46]  * Fujitsu points persia at the somewhat expanded and up-to-date UEHS.
[05:46] <jcastro> well, other than the amount of packages
[05:46] <persia> jcastro: Sure, but the semantics differ.  The user goal might be to install a program, but what happens is different at a greater level than what dependencies are installed.
[05:47] <jcastro> persia: hmm, true true
[05:47] <LaserJock> jcastro: if we just got rid of Fedora/Madriva and RPMs we'd be set
[05:47] <LaserJock> and openSUSe I guess
[05:47] <persia> Fujitsu: Looks great.  Thanks.
[05:48] <jcastro> I dunno
[05:48] <jcastro> I like the idea of one update manager for everyone
[05:49] <LaserJock> I think it makes sense
[05:50] <LaserJock> I just wonder how the implementation will go
[05:50] <LaserJock> and if it'll actually go that way
[05:50] <LaserJock> people like to be different ;-)
[05:50] <ScottK> LaserJock: Why not do one for Windows too then?
[05:51] <LaserJock> well, I'm not gonna do one that's for sure
[05:52]  * imbrandon points out there is apt for w32 and *_w32.deb files
[05:52]  * ScottK neither, but I guess my point is that installing an RPM and a DEB are two almost totally different things.  I don't see the advantage to a common front end for two different things.
[05:52]  * imbrandon goes back to sleep
[05:52] <persia> LaserJock: Think diversity.  Without others, it's hard to compare and be strong.
[05:52] <LaserJock> ScottK: because installing a DEB or RPM isn't the point, installing software is
[05:52] <LaserJock> so the backend can handle the differences
[05:52] <jcastro> imbrandon: dude, I'm stepping out for a smoke
[05:53] <imbrandon> hehe
[05:53] <jcastro> let's burn a virtual one.
[05:53] <persia> jcastro: One update manager is nice in some ways, but because the way it works is so different, it will likely cause more confusion than happiness.  Essentially, what works for one person is likely to not work the same way for another.
[05:53] <imbrandon> kk
[05:53] <LaserJock> but the frontend allows people to write documentation easier and allows users a better experience
[05:53] <persia> LaserJock: It's not just packaging differences: there are semantic differences.
[05:53] <LaserJock> persia: how do you mean?
[05:53] <jcastro> persia: let me have a smoke with imbrandon, I'll be back. :D
[05:53] <persia> jcastro: You cold always move to a country that didn't require a break :)
[05:55] <imbrandon> mmm instant mashed pataoes + bacon bits + cheeese + microwave == good after some crown and coke :)
[05:55] <persia> LaserJock: 1) There isn't a firm mapping between RPMs and DEBs.  2) The nature of the meanings of Depends:, Recommends:, and Suggests: are slightly different, 3) Depending on distro choices, what may work somewhere breaks somewhere else (e.g. using VLC to generate JACK input for transforms of movie soundtracks)
[05:56] <LaserJock> persia: to me that's all backend stuff though
[05:56] <persia> LaserJock: Right.  To translate to front end: 1) means users need to install a different set of packages, 2) means that the functionality provided is undecidable, and 3) means that even when one tracks it down, it may not mean the same thing.
[05:57] <jcastro> it is all backend stuff.
[05:57] <jcastro> persia: to fill you in ...
[05:57] <imbrandon> what did i walk into, deb vs rpm? you all rember one thing, deb and rpm are VERY VERY similar file formats, now if you mean rpm vs dpkg thats totaly diffrent
[05:57] <persia> As a result, user forums for packaging kit have little to share except for a single distibution, further splintering things.  Because the backend is exposed, all users of e.g. synaptic can share their experiences for Debian, Ubuntu, MEPIS, etc.
[05:58] <jcastro> persia: there was a packagekit bof at fosscamp, and there ubuntu guys there, fedora, and rpath guys.
[05:58] <jcastro> and to be honest there was no real debate
[05:58] <jcastro> everyone loves PK
[05:58] <jcastro> the suse guys dig it too
[05:59] <persia> jcastro: Sure.  I suspect they arrived at some useful commonalities.  I still think the sematics are different, and that the participants are awed by excellent execution, and not thinking about support.
[05:59] <jcastro> the discussion was all about backends
[05:59] <jcastro> synaptic isn't going away, for example, or apt or anything
[06:00] <TheMuso> IMO if someone comes up with a way to binary patch packages, as in, downlading only patches to change binaries, and not the whole package, they will win support from all.
[06:00] <TheMuso> downloading
[06:00] <persia> jcastro: Unless we all package the same software by the same name with the same structure of Dependencies, Recommendations, and Suggestions, I'm still not happy, and I'm not sure that's a good thing.
[06:00] <jcastro> the idea is that everyone has the same update-manager
[06:00] <LaserJock> persia: why would it matter?
[06:00] <LaserJock> I don't quite get it
[06:00] <imbrandon> persia: why would that matter
[06:00]  * TheMuso agrees with persia 
[06:01] <imbrandon> persia: htat would make one better than the other but still, even debian and ubuntu differ on those respoects
[06:01] <persia> LaserJock: Because the two users of different distributions cannot expect the same behaviour from the same set of actions.  This is not currently the case for Fedora+SuSE or Debian+Ubuntu+MEPIS
[06:01] <persia> imbrandon: Not very much, semantically.
[06:01] <imbrandon> persia: sure it is
[06:01] <crimsun> I often wonder why we don't rsync our package updates.
[06:01] <imbrandon> very much dosent == not at all
[06:02] <TheMuso> crimsun: You'd need a deb to base it on locally would you not.
[06:02] <TheMuso> s/./?/
[06:02] <persia> imbrandon: Sure, but it's expanded greatly when you mix with Fedora/SuSE
[06:02] <jcastro> persia: spend sometime reading the PK docs, and playing with the ppa
[06:02] <Fujitsu> crimsun: Load on servers.
[06:02] <jcastro> it's actually quite sweet
[06:02] <jcastro> crimsun: hi btw!
[06:02] <persia> jcastro: I can't play with a PPA without allowing arbitrary upload to the repos
[06:02] <imbrandon> persia: i think the percption between the diffrences of ubuntu and debian are small but in reality are very very difffrent
[06:02] <imbrandon> even in this case
[06:03] <persia> imbrandon: Sure, but not very different semantically.
[06:03] <LaserJock> but why does it matter?
[06:03] <LaserJock> all the user wants to do is install app X
[06:03] <jcastro> persia: I'm using deb http://ppa.launchpad.net/packagekit/ubuntu gutsy main
[06:03] <persia> LaserJock: So that all the random web pages out there don't offer advice that very well may not work for a given user, causing a general dissatisfaction.
[06:04] <LaserJock> persia: what?
[06:04] <persia> jcastro: Ah.  s/a PPA/the PPA/.  Sorry.  I'll take a look.
[06:04] <jcastro> persia: the apt backend needs a bit of love, but the idea is sound
[06:04] <LaserJock> nothing changes really except the frontend no?
[06:04] <persia> LaserJock: If two users on different systems cannot expect the same behaviour from the same actions, and the same tool is advocated for both, it can be a source of user confusion.
[06:05] <jcastro> a common add/remove programs for everyone, along with an update manager
[06:05] <LaserJock> persia: right now the case is way worse though
[06:05] <LaserJock> you have different frontends that do different things
[06:05] <persia> LaserJock: Why?  Each distribution set with common semantics has a common set of tools.
[06:05] <LaserJock> I don't care about semantics
[06:06] <LaserJock> the user just wants to install app X
[06:06] <LaserJock> having a common GUI gives some familiarity
[06:07] <persia> LaserJock: Right, but if the same action produces different results, how is this useful?
[06:07] <LaserJock> because it installs what they want
[06:07] <LaserJock> and it's a common interface
[06:07] <Fujitsu> Not necessarily!
[06:08] <crimsun> (as an aside, I wonder how useful it would be to have per-application volume for pulseaudio tied to window focus ala a compiz* plugin)
[06:08] <Fujitsu> crimsun: As a plugin, that would be cool.
[06:08] <imbrandon> persia: if it DOSENT produce diffrent resuls would be the goal of the tool, the getting there might be diffrent for each distro but the end result will be the same
[06:08] <imbrandon> e.g. X is installed
[06:08] <persia> imbrandon: Right, but the semantics are differnt.
[06:09] <imbrandon> persia: exactly but users dont nor should care about those, only developtrs
[06:09] <LaserJock> persia: you have a legitimate point that users from different distros will get different packages installed
[06:09] <LaserJock> but that's not really the point
[06:10] <persia> imbrandon: No, the semantics are different.  The users need to think differently to achieve the results.  A new common set of semantics can be established, but that requires retraining for everyone.
[06:10] <LaserJock> the point, I believe, it to provide a common interface to installing software
[06:10] <imbrandon> persia: no retraining only for developrs of the inter4gration tool, not "everone"
[06:10] <persia> LaserJock: Yes it is.  It means that searching the web for someone who had the problem before and resolved it is no longer a useful way to find solutions.
[06:11] <LaserJock> persia: why not?
[06:11] <persia> imbrandon: If you change the semantics, all users (including you) need to alter thinking to match the new semantics.
[06:11] <imbrandon> no no no
[06:11] <imbrandon> not at all
[06:11] <imbrandon> not ifd the tool does its job
[06:11] <persia> LaserJock: Because the information available for a web page is no longer expected to be the same for my local environment.
[06:11] <LaserJock> persia: why not?
[06:11] <LaserJock> I don't really get it
[06:12] <Fujitsu> To make everything work uniformly, we would need strictly defined standards of how every single package is split, built, etc.
[06:12] <imbrandon> persia: thats the same if you move from epiphany to firefox
[06:12] <imbrandon> and change will produce that result
[06:12] <LaserJock> the packages are the same so the solutions are the same
[06:12] <persia> imbrandon: Yes.  if the semantics are different now, the tool must select one set of semantics, prepare a new common set of semantics, or not behave identically in differing environments.
[06:13] <LaserJock> persia: I'm still not getting it, how are we changing semantics?
[06:13] <persia> LaserJock: The packages aren't the same.  That's the point.
[06:13] <LaserJock> yes they are
[06:13] <imbrandon> i cant express how wrong you are on irc, i guess i will have to write a paper
[06:13] <LaserJock> you're still doing .debs and .rpms or whatever
[06:13] <persia> LaserJock: No.  Go review the package sets for Fedora and SuSE, and compare.  Binary packages are very frequently split differently.
[06:14] <LaserJock> persia: but that doesn't matter doesn't it?
[06:14] <imbrandon> persia: and that matters not to an end result, only how you get ther
[06:14] <LaserJock> that's the whole point of the backends
[06:14] <TheMuso> LaserJock: It matters a lot
[06:14]  * Fujitsu finds persia's point very, very valid.
[06:14] <persia> imbrandon: I agree that there is a semantic change from firefox to epiphany.  If the new tool defines a common set of semantics, I'm happy, but I don't see that.
[06:14] <imbrandon> persia: just existing it does
[06:14] <persia> LaserJock: Yes it does, because it changes what gets installed for any given action.
[06:15] <LaserJock> persia: no it doesn't
[06:15] <LaserJock> why would it?
[06:15] <imbrandon> persia: but as long as the backend is smart enough to keep track of that wtf does it matter
[06:15] <LaserJock> maybe I'm lost
[06:15] <persia> imbrandon: No, it needs to define the semantics.  If it follows the distribution guidelines, the behaviour is different for different distributions, for the same actions in the same tools.
[06:16] <persia> LaserJock: Because the packages are split differently, the same actions in the same installation tool will cause different changes to the installed system.  As a result, the mapping between user action and result will not match between distributions, for the same actions in the same tool.
[06:16] <LaserJock> persia: ok, but who cares?
[06:16] <imbrandon> if i request to install <blah> on suse and it installs <blah> + libblah-dev and blah2, on debian it only installs <blah> + blah2 WTF does it matter, i only requested <blah>
[06:16] <imbrandon> thats the whole point
[06:17] <Fujitsu> imbrandon: It's not just dependencies.
[06:17] <LaserJock> the point isn't to make the distros all the same
[06:17] <Fujitsu> It could be a package split, or alternate flavours.
[06:17] <LaserJock> it's just a common user interface for installing packages
[06:17] <imbrandon> Fujitsu: and ? how does that make the front end diffrent ?
[06:17] <LaserJock> it's not changing package formats or how we package, etc.
[06:18] <persia> Right.  So when I put up my new cool software, and find that the tool works for me, and all my users complain that it doesn't install libfoo support (as one distribution split the packages differently), how do I support that?
[06:18] <Fujitsu> imbrandon: That's the point: it looks the same, but does different things!
[06:18] <persia> Do I write separate installation guides for each distribution?  If I'm doing that, why would I want a common tool?
[06:18] <imbrandon> persia: thats a per distro issue NOT a tool issue
[06:18] <Fujitsu> Eeexactly.
[06:18] <Fujitsu> (to persia's last line, that is)
[06:18] <LaserJock> because a common user interface is much easier
[06:18] <persia> imbrandon: Exactly.  And a single tool that is intended to act the same, but requires per-distro changes is hard to support.
[06:18] <imbrandon> persia: because it makes sense for one less thing to be diffrent
[06:18] <LaserJock> and for the vast majority of apps it should be just fine
[06:19] <imbrandon> persia: easier to support than how it is now
[06:19] <persia> LaserJock: How is a common interface easier when the behaviour cannot be documented?
[06:19] <persia> imbrandon: Yes.
[06:19] <Fujitsu> imbrandon: One more thing that is the same, but is not?
[06:19] <imbrandon> Fujitsu: its exactly the same, the APPS work diffrent
[06:19] <imbrandon> you have the EXACT same issue on debian and ubuntu
[06:19] <LaserJock> persia: because you can say "To install X open up PackageKit and click blah and do foo"
[06:20] <persia> imbrandon: Sure, so we get lots of reports that "blender is broken in Ubuntu, and only works in Fedora", when it works fine in Ubuntu, except that the installation mecahnism is different.
[06:20] <persia> imbrandon: But not as much because the packages are 99% split the same.
[06:20] <Fujitsu> LaserJock: And then we have `oh dear, X is split up differently WHERE IS MY FEATURE?'
[06:20] <imbrandon> persia: your mixxing app behavure and tool behavure, TOTALY diffrent
[06:21] <imbrandon> Fujitsu: you also
[06:21] <LaserJock> Fujitsu: well, yes, that's gonna happen some, but a common interface is at least easier
[06:21] <persia> LaserJock: How is it easer?  For whom?
[06:21] <LaserJock> better than documenting yum, synaptic, g-a-i, yast, etc.
[06:21] <Fujitsu> imbrandon: The tool should behave similarly in all instances if it is the same tool.
[06:21] <imbrandon> Fujitsu: so what does that matter to the interface ?
[06:21] <Fujitsu> If it is installing different things, it is behaving differently.
[06:21] <imbrandon> Fujitsu: no it shouldent, then adept shouldent be in ubuntu and debian
[06:21] <persia> imbrandon: The tool is inherently unsupportable if the behavior cannot be mapped to user actions.
[06:21] <ScottK2> imbrandon: Common interface to different functions is dangerous.
[06:22] <imbrandon> ScottK2: same functions diffrent app
[06:22] <LaserJock> ScottK2: but it's still just installing software
[06:22] <persia> LaserJock: Yes, which is only simple for a given common set of semantics.
[06:22] <ScottK2> LaserJock and imbrandon: Yes, but that's not all you're doing.
[06:22] <LaserJock> yeah, but the problem is worse now
[06:22] <imbrandon> if what you are saying is correct , then apt for rpm wuld fail and not exist
[06:22]  * persia is not opposed to packagekit defining a common set of semantics, but doesn't see that in the code anywhere
[06:22] <LaserJock> you're not making the issue worse by having a common interface I can't imagine
[06:23] <Fujitsu> LaserJock: If things look identical, there will be more expectation that doing the same thing on two instances will give the same result.
[06:23] <persia> imbrandon: No, but apt for RPM behaves differently than apt for DEB, and yum is generally recommended as a preferred alternative.
[06:23] <LaserJock> Fujitsu: well yes, that's always the case
[06:23] <LaserJock> but software does that a lot
[06:23] <imbrandon> per not at all
[06:23] <LaserJock> and in this case I don't think it's very much
[06:23] <ScottK2> Unless you have opensuse 10.1, then apt is really good to have.
[06:23] <imbrandon> persia: ^
[06:23] <persia> LaserJock: Right, so why create a identical interface that is known not to behave identically.
[06:24] <LaserJock> persia: why not? I guess is my point
[06:24] <Fujitsu> LaserJock: There are some minor differences now... We're much, much, much closer to Debian that we are to $RPMDISTRO
[06:24] <LaserJock> it'd be nice to be able to install Fedora and see a common install interface
[06:24] <LaserJock> like when I see evolution and Firefox, etc.
[06:24] <persia> LaserJock: OK.  Good point.  I guess mine is that I wouldn't prefer to see it standardised for the distribution I spend time supporting.
[06:24] <LaserJock> they may act differently, but well, you get over that
[06:25] <persia> LaserJock: Sure, but epiphany in Fedora and epiphany in MEPIS are essentially the same.
[06:25] <LaserJock> persia: well, not necessarily
[06:26] <imbrandon> persia: it wouldnt make a lick of diffrence for distro support, whaat your talking about is multi-disro suppotr
[06:26] <persia> Firefox vs. Epiphany is $favorite-RPM-semantics-tool vs. $favorite-DEB-semantics-tools
[06:26] <LaserJock> say we split up the epiphany extensions in a separate package
[06:26] <LaserJock> and Fedora doesn't
[06:26] <LaserJock> you're gonna get different results
[06:26] <persia> imbrandon: No, it makes a difference for distro support, as searching the web no longer helps: users have to ask the distro.
[06:26] <LaserJock> but if you search for epiphany on both distros you can reasonably get what you want
[06:27] <persia> LaserJock: Sure, but the user has a different semantic framework, and installs the right support, or understands why.
[06:27] <LaserJock> persia: how so?
[06:27] <imbrandon> persia: as they do now, the only thing on the "web" is generic linux, and that only works if you dont use thedisro provided tools, e.g. compile from source etc etc etc
[06:27] <LaserJock> persia:  well, I see your point, but I don't think PackageKit is trying to resolve that problem
[06:27] <persia> LaserJock: But if you search for how to install epiphany with packagekit, the instructions may not be right for your distro (see your example above)
[06:28] <persia> LaserJock: I agree, I just don't think that the problem PackageKit is solving is worth solving without common semantics.
[06:28] <imbrandon> sure installing it would be exactly the same, but what it installs woudl be diffrent
[06:28] <imbrandon> as is now
[06:28] <LaserJock> persia: that may be
[06:28] <LaserJock> but I don't see how it would make the problem worse really
[06:28] <imbrandon> so your taking one thing away, the diffrence on the install proceedure, not the diffrnce on what it installs
[06:29] <persia> LaserJock: Because the set of actions for a user to take when using PackageKit differs between distributions, so a search on "packagekit epiphany" is much less likely to generate something useful than a search on e.g. "synaptic epiphany"
[06:30] <imbrandon> persia: how? htat is totaly wrong
[06:30] <persia> imbrandon: That would make me happy, but requires that PackageKit define a common set of semantics for all distributions.
[06:30] <imbrandon> persia: not really if it uses each distros aleadu defined semantics
[06:30] <persia> imbrandon: Because the mapping between user action and behaviour is not guaranteed without common semantics
[06:31] <persia> imbrandon: If it uses each distros semantics, then my point about web searches applies.
[06:31] <imbrandon> sure it is
[06:31] <LaserJock> I can't imagine that it would  be a bigger problem that currently exists
[06:32] <imbrandon> ugh you have the app mixed with the tool a little much in your reasoning, think about this .... ( one sec )
[06:32] <LaserJock> but for sure it'd be nice to have a common semantics to go with it
[06:32] <persia> imbrandon: How?  Without common semantics, installing a package doesn't necessarily mean the same thing.
[06:32] <imbrandon> what is the problem if the end result is EXACTLY the same as now, but the road to get there is the same for all distros
[06:32] <imbrandon> that is packagekit
[06:33] <persia> LaserJock: Personally, I'd rather force multi-distro documentation on upstream than have a common install method that appears to work everywhere but acts differently in different places, if only to make keyword searches easier.
[06:33] <ScottK> Well you either have to have RPM plus some stuff or DEB minus some stuff for that.
[06:34] <persia> imbrandon: That is PackageKit's goal, with which I do not disagree, I just claim that it first requires the definition of common semantics.
[06:34] <imbrandon> persia: how, distrubuitions already provide their own that work perfectly well
[06:34] <persia> If "Install a package" doesn't mean the same thing, it's really hard for something to manage it properly.
[06:35] <ScottK> persia: Personally, I think to do it correctly first requires someone to discover and commericalize unobtanium.
[06:35] <persia> imbrandon: Right, each with its own semantics, and its own keyword for web searches.
[06:35] <LaserJock> persia: but I can't imagine that it'd be different for a great many apps
[06:35] <imbrandon> wtf does web searches have to do with install $package
[06:35] <persia> ScottK: No, there are cases of successful collaboration.  Look at freedesktop.org.  It just requires massive effort for lots of people.
[06:35] <ScottK> persia: Yes, but you have to go reinvent the fundamental wheel first.
[06:36] <persia> LaserJock: Pick 20 apps you've worked on recently, and go look at the RPMs.  Even in cases where I'm intimately familiar with the upstream source code, I am sometimes confused trying to pull patches.
[06:36] <LaserJock> persia: but the packaging has nothing to do with it
[06:36] <persia> ScottK2: Right.  Define some semantics :)
[06:36] <imbrandon> persia: what does package ormat have to do with it ?
[06:36] <persia> LaserJock: Rather, the packaging has everything to do with it.  Same upstream.
[06:37] <LaserJock> if I do a search for epiphany in Synaptic and in yum I can get the right thing
[06:37] <ScottK> imbrandon: It's not just format, but content and structure.
[06:37] <persia> imbrandon: ormat?
[06:37] <imbrandon> format
[06:37] <persia> imbrandon: Not much at all.  It is all about the semantics of the set of packages for the environment.
[06:37] <LaserJock> I can get the same apps installed on different distros, I just have to learn different tools
[06:38] <imbrandon> but what does an end user care about that, they dont pull patches
[06:38] <persia> One could likely produce an RPM distro with Debian semantics.
[06:38] <imbrandon> they install software
[06:38] <LaserJock> learning *what* to install is much easier most of the time than *how* to install
[06:38] <persia> Right.  Without common semantics "Install software" doesn't have a common meaning.
[06:38] <imbrandon> sure it does
[06:38] <persia> imbrandon: Go read a dictionary.
[06:38] <imbrandon> yum install blah, apt-get isntall blah
[06:39] <imbrandon> persia: ???
[06:39] <persia> imbrandon: I agree with almost everything you are saying, but none of it actually works that way without common semantics.  We have a different problem that needs solving first in order for packagekit to do what you describe.
[06:40] <imbrandon> what the hell does that have to do with me reading a Dictionary ?
[06:40] <imbrandon> ...
[06:40] <persia> http://www.google.co.uk/search?hl=en&q=define%3A+semantics&btnG=Search&meta=
[06:41] <imbrandon> and ? i know what semantics means, your point ?
[06:41] <persia> "semantics" attaches meanings to words.  Without common semantics, "this" means two different things in two different contexts.
[06:41] <LaserJock> persia: but the semantics are very similar
[06:41] <imbrandon> and i';m trygin to excplain to you that it dosent except to developers
[06:41] <LaserJock> people can, in the majority of cases figure it out
[06:41] <persia> So, when I say "Without common semantics "Install Software" doesn't have a common meaning", it is a tautology.
[06:42] <imbrandon> persia: it does more than you thing
[06:42] <imbrandon> think*
[06:42] <ScottK> On the off chance anyone wants to do actual packaging work tonight, http://revu.tauware.de/details.py?package=disk-manager is looking for a second advocate.
[06:42] <persia> LaserJock: The semantics are similar in the majority cases, but dissimiar in thousands of cases, which tend to be packages that I hear about.
[06:43] <persia> imbrandon: I'm reading the code.  It helps somewhat, but doesn't handle a number of cases well, e.g. (hypothetical) epiphany suggesting epiphant-plugins-extra in one distro, and it being compiled-in in another.
[06:43] <imbrandon> ScottK: is there a reason this DD isnt uploading to debian first ?
[06:44] <persia> imbrandon: NMU barrier is higher than Ubuntu barrier?
[06:44] <ScottK> imbrandon: He wants to become a MOTU, so this is part of his body of Ubuntu work.
[06:44] <imbrandon> persia: as it shouldnt, i dont want it too, infact thats GREAT it dont
[06:44] <ScottK> persia: New package.
[06:44] <imbrandon> it SHOULD work diffrently on each distro
[06:44] <persia> ScottK: Even more so then :)
[06:44] <imbrandon> otherwise why have diffrent ones
[06:45] <ScottK> imbrandon: An excellent argument for having different package management tools.
[06:45] <persia> imbrandon: If the tool works differently for each distro, then there is no mapping between user action and berhaviour, which is considered poor form by UI people.
[06:45] <imbrandon> persia: its not a NMU
[06:45] <imbrandon> no persia your mapping APP to TOOL, not the same i want the TOOL the same but the APP diffrent
[06:45] <imbrandon> ScottK: ^
[06:46] <persia> imbrandon: Right.  So users of PackageKit cannot expect a common behaviour from a set of actions within PackageKit.  I consider that a bug.
[06:46]  * ScottK is too tired to parse that
[06:46] <imbrandon> e.g. its a feature that apt installs epiphany on ubuntu and apt installs epiphany and plugins on SuSE
[06:47] <imbrandon> persia:  NO
[06:47] <imbrandon> persia: the package kit they click INSTALL on both, the APP ends up being diffent, NOT the tool
[06:47] <imbrandon> that is corect
[06:48] <persia> imbrandon: Searching the web for "epiphany packagekit" when I'm on ubuntu in your example might take me to a page that indicates I don't need to do anything extra to get the extras pacakge.  That would be wrong.
[06:48] <ScottK> Does yum/RPM have an equivalent of update-alternatives?
[06:48] <imbrandon> persia: but you dident search for the extras you searched for packagekit
[06:48] <persia> imbrandon: The actions the tool takes as a result of user action are different.  That means that common documentation is useless.
[06:49] <persia> imbrandon: Right, because I'm installing epiphany with packagekit.
[06:49] <imbrandon> not totaly, infact more common than it is now
[06:49] <persia> And the web page tells me it automatically includes the extras package, and it doesn't, so I file a bug.
[06:49] <imbrandon> persia: no hte webpage would mention no su=ch thing, as it would be diffrent and known to be diffrent
[06:49] <persia> And the bug is rejected, as it's supposed to behave that way, and I'm an unhappy user.
[06:50] <persia> imbrandon: On some random blog?  I doubt it.
[06:50] <ScottK> persia: Do you know if RPM has update-alternatives?
[06:50] <imbrandon> some random blog is wrong now, why woudl that change
[06:50] <LaserJock> ScottK: I think the alternatives system is a Debianism
[06:50] <persia> ScottK: Not offhand, but good point.  I'll look.
[06:50] <ScottK> LaserJock: I'm fairly certain it is.
[06:50] <imbrandon> ScottK: alternaves is debian only
[06:51] <ScottK> This is an example of something that fundamentally RPM doesn't have.
[06:51] <persia> imbrandon: Sure, but the chances that "synaptic epiphany" gets me a random blog that isn't wrong is much higher now.
[06:51] <ScottK> How does a common tool manage this kind of thing.
[06:51] <LaserJock> ScottK: it has a RPM backend
[06:51] <imbrandon> persia: why would you search for epiphany when you wnt epiphany extras ?
[06:52] <ScottK> Right so it's doing RPMish things and DEBish things and they are different.
[06:52] <imbrandon> ScottK: it dosent and isnt supose to
[06:52] <persia> imbrandon: Because I'm not very experienced, and don't know I want epiphany extras.
[06:52] <LaserJock> ScottK: right, that's the point
[06:52] <persia> ScottK: No.  Guideline is to not share namespace.
[06:52] <imbrandon> persia: then you are likely to be wrong or get wrong info no matter what you do
[06:52] <imbrandon> in that case
[06:53] <LaserJock> persia: that's what package descriptions are for, right?
[06:53] <imbrandon> even now
[06:53] <ScottK> persia: It's not just namespace, it's common package functions like www-browser
[06:53] <persia> imbrandon: Why?  I subscribe to a number of RSS feeds.  Frequently the posts include info on an app I want.  This often includes instructions for Fedora & Debian.  I follow the Debian example, and am happy.  I don't want this to change.
[06:53] <imbrandon> ScottK: and no other distros  have a concept of that and it wouldent change with packagekit nor would packagekit have to maintain that, apt would
[06:53] <persia> ScottK: Right.  That's namespace.  Apps are expected to rely on preferred alternatives exclusively.
[06:54] <ScottK> OK.
[06:54] <imbrandon> persia: sure but your missing the3 point here, there would still be debian and fedora ways of doing things, but part of that process would now overlap
[06:54] <ScottK> Well it's nearly 2AM here, so I need to get to bed.
[06:54]  * persia agrees with imbrandon about alternatives
[06:54] <ScottK> Good night all and have a look at http://revu.tauware.de/details.py?package=disk-manager
[06:55] <persia> imbrandon: And I'm to trust the blog authors to explain it correctly?  With a common tool, I suspect the likelihood is significantly reduced.
[06:55] <ScottK> Apt would have to do it, but you'd still have inconsistent results between the two environments.
[06:55] <imbrandon> persia: if you trust them now you would trust them then, you cant have iot both ways
[06:55] <imbrandon> ScottK: and you have inconsitant results NOW
[06:56] <persia> imbrandon: They do it now because it's significantly different.  If it's substantially the same, I don't see why they'd bother.
[06:56] <imbrandon> that wouldent change and packagekit isnt trying to chage it
[06:56] <ScottK> imbrandon: Yes, but I have two obviously differnt tools.  It's not suprising.
[06:56] <persia> Right.  That's the problem I have with packagekit.  if it's going to provide a common tool with a common interface, it should be addressing those issues.
[06:56] <imbrandon> persia: then your putting your faith in the wrong thing, if everyone thought liek that we'd all use windows
[06:57] <imbrandon> ScottK: its not replaceing apt, you seem to think it is
[06:57] <imbrandon> its replaceing synaptic and adept
[06:57] <persia> imbrandon: Why?  By the same guidelines, I expect people to provide different notes for installing on Windows, Linux, and Mac OS X.
[06:57] <persia> (and they tend to do so)
[06:58] <imbrandon> -EPARSE
[06:58] <ScottK> imbrandon: I realize that.  It's just that it's a front end for two totally different things trying to look the same.  It's odd.
[06:58] <imbrandon> ScottK: HOW, thats what i'm getting at
[06:58] <imbrandon> its really not, you might think it is at first but i dont
[06:58]  * persia finishes looking at the packagekit code, and is very impressed with the interface and functionality, but laments the lack of specification of semantics.
[06:59] <imbrandon> persia: do distrobutions not provide those? why change them ?
[06:59] <ScottK> Of course, OTOH, almost anything would be an improvement over Adept.
[06:59] <persia> imbrandon: So that user action is mapped to result in a predictable way.
[07:00] <imbrandon> its kinda like saying there shouldent be an odbc because each DB backend is very very diffrent, odbc still seems to map them all to a common api just fine
[07:00] <LordKow> what kind of craziness does ubuntu do with the swap partition? because by all accounts mount is not mounting swap.
[07:00] <Fujitsu> LordKow: swapon -a
[07:00] <Fujitsu> Swap is never done my mount, is it?
[07:00] <ScottK> imbrandon: In my head this is like having an IM client and a mail client with a common front end and expect people to keep it straight.  The both move text and files between people, so who cares.
[07:00] <imbrandon> LordKow: mount never mounts swap
[07:00] <Fujitsu> s/my/by/
[07:00] <LordKow> then how is the swap partition utilized?
[07:00] <Fujitsu> LordKow: swapon
[07:00] <imbrandon> ScottK: heh gmail does just that
[07:00] <imbrandon> :)
[07:00] <persia> ScottK: I've actually seen apps like that.
[07:01] <ScottK> Yeah and they drive me batty.
[07:01] <ScottK> Just because it exists doesn't make it a good idea.
[07:01] <imbrandon> dosent make them worng either
[07:01] <LordKow> well that methodology breaks a lot of programs that expect to find a swap partition mounted properly... ie s2ram's userspace utility
[07:01] <persia> I also.  I'd have phrased it differently if I'd meant it to be email.
[07:02]  * persia especially dislikes getting email containing "ping"
[07:02] <imbrandon> LordKow: no distro "mounts" swap
[07:02] <imbrandon> they all use swapon etc
[07:03] <LordKow> hm
[07:04] <LordKow> i've never had any trouble using s2ram and gnome's suspend to ram has never worked. i still cant figure out why ubuntu decided s2ram was unneeded.
[07:05] <imbrandon> and suspend to "ram" shouldnt be suppend to "disk" aka swap
[07:05] <imbrandon> :)
[07:05] <LordKow> the swap thing was a side point, irrelevant.
[07:07] <LordKow> suspending to ram is about as beautiful as ever on gentoo heh. i think gnome-power-manager should have suspend to ram disabled by default. of those who actually have a use for suspend 2 ram im guessing <10% will find it actually works in ubuntu
[07:09] <LordKow> i know its a driver issue but thats what s2ram works around by utilizing the comps/laptops ability to reload the video bios itself.
[07:11] <LordKow> Dec  8 00:25:42 CSC-KDRAKE-002 console-kit-daemon[5667]: WARNING: Unable to activate console: No such device or address  <-- well there is half the problem
[07:11] <ScottK> LordKow: In Kubuntu, I've never had it not work.
[07:12]  * ScottK is really going to bed now.
[07:12] <imbrandon> gnight ScottK
[07:12] <Fujitsu> Night ScottK.
[07:12] <LordKow> thats the point. the only thing worse than a broken suspend feature is a broken suspend feature for some, while for others it works. even worse is that the fix can be any combination of seemingly a million things.
[07:14] <LordKow> and that is due to crap video drivers, so.. ubuntu is all about open source so why not use a suspend method that does not rely on the video drivers at all when resuming
[07:14] <lifeless> LordKow: I think our success rate for suspend to ram is much better than 10%
[07:14] <lifeless> LordKow: certainly it works on all my machines, and thats 5 different hardware configurations on three architectures
[07:14] <lifeless> LordKow: finally, broken suspend for all is worse that working suspend for some.
[07:15] <imbrandon> lifeless: sparc notebook ? heheh
[07:15] <LordKow> lifeless, i think a quick google search would show otherwise. most people dont even need to use suspend so the issue is there for more people than it seems.
[07:15] <LordKow> (simply because they use a desktop and have no use for suspend).
[07:15] <stratus> https://wiki.ubuntu.com/CowdancerHowto - Feedback is appreciated! :)
[07:15] <Fujitsu> Desktop has no use for suspend? I... seee.....
[07:15] <lifeless> LordKow: you make a compelling argue with no logical flaws. I'm going to go write some code now.
[07:16] <imbrandon> desktop has plenty of uses for it, like power savings
[07:16] <lifeless> s/argue/argument/
[07:16] <LordKow> if you're a bug fixer you would much rather have it broken for all because if its broken for some.. but not for others.. and yet the configurations are exactly the same (base ubuntu install) then where do you begin?
[07:16] <lifeless> LordKow: thats called debugging/diagnosis/software development.
[07:16] <Fujitsu> By filing bugs.
[07:16] <LordKow> Fujitsu, some of these bugs have been open in excess of 2 years now.
[07:17] <LordKow> thats horrible.
[07:17] <lifeless> LordKow: so get stuck in and help solve them.
[07:17] <LordKow> they've crossed 4+ ubuntu distributions.
[07:17] <LordKow> sure, the fix is to use s2ram.
[07:17] <Fujitsu> LordKow: 4+ Ubuntu releases, you mean?
[07:18] <LordKow> yea
[07:18] <imbrandon> LordKow: sure if your convinced that is the solution write a compeling spec and present it, complaining in here wont solve a whole lot
[07:18] <persia> stratus: Nice.  I'd recommend putting it under https://wiki.ubuntu.com/PackagingGuide somewhere (and am still reading)
[07:19] <imbrandon> LordKow: but on the other hand a compelling spec can change a whole ot
[07:19] <imbrandon> s/ot/lot
[07:19] <LordKow> well SuSe is going one way with s2ram while ubuntu is going the other way with gnome-power. why not combine the efforts? effectively double the manpower towards the problem.
[07:21] <LordKow> debian keeps the userland s2ram utils up-to-date so it would take little work on our part
[07:21] <stratus> persia: sure, just wanted to collect some feedback and maybe changes, grammar fixes and all that before add it into a more know document
[07:21] <LordKow> kernel.org put s2ram into the kernel starting with 2.6.23 i believe
[07:21] <LordKow> maybe earlier
[07:21] <persia> stratus: Is there by any chance a config file that would allow shorthand use of aliases for basepath?  e.g. `sudo cowbuilder --build hello*dsc -- dist hardy`?  Separately, Is there a way to get it to run without sudo?  We don't currently require sudo for pbuilder or sbuild.
[07:21] <persia> stratus: No problem :)
[07:24] <stratus> persia: hm, no shortand of aliases for basepath yet but smells like a interesting patch for upstream
[07:24] <stratus> persia: fakeroot should do
[07:25] <persia> stratus: Too bad :)  For fakeroot, if that works, it might be worth s/sudo/fakeroot/ where possible.
[07:25] <stratus> persia: I need to check, let it be sudo for a while. :)
[07:26] <persia> stratus: OK.  We just generally discourage sudo for packaging, as we see lots of cases of packages installing into /usr during build from new packagers, but it can wait for more testing.
[07:29] <stratus> persia: I see, I'll take a look and update the article don't worry.
[07:29] <stratus> persia: need some sleep now
[07:29] <persia> stratus: Thanks for writing it up.  Sleep well.
[07:29] <stratus> persia: np, thanks. see you.
[07:58]  * StevenK complains, whinges and bitches about WoW
[07:58]  * Fujitsu doesn't.
[07:58] <StevenK> Most useless group *EVER*
[07:59] <StevenK> I missed two quest items the first time I did this instance, so I did it again with another group. And we missed them *AGAIN*
[08:00] <Fujitsu> You do things in groups?
[08:00] <StevenK> Sure.
[08:00] <Fujitsu> You need a Kmos in yours.
[08:00] <StevenK> These quest items are in an instance, which you just can't do by yourself.
[08:01] <StevenK> No I don't.
[08:01] <StevenK> I need a group which doesn't get wiped in the final room of the instance
[08:01] <StevenK> *TWICE* damn it
[08:02] <Fujitsu> This must be some usage of the word instance that I wasn't previously aware of.
[08:04] <Treenaks> Fujitsu: it's a WoW thing
[08:04] <Fujitsu> That would explain it.
[08:04] <Treenaks> Fujitsu: I get to hear stories like this all day at work :)
[08:06]  * StevenK keeps grumbling
[08:06] <StevenK> If I hear the words "It's just a game" I will garrote some one.
[08:08]  * StevenK sighs
[08:09] <Treenaks> StevenK: It's just.. well.. you know :)
[08:10] <StevenK> Keep talking, I'm sharpening.
[08:11] <StevenK> Treenaks: I've just spent about four hours running around Zul'Farrak, and I've missed what I was after, *twice*.
[08:11] <persia> StevenK: How do you sharpen a garotte?
[08:11] <StevenK> I didn't say what I was sharpening ...
[08:12]  * persia suspects StevenK of being sneaky, and threatening one method of demise whilst planning quite a different one.
[08:12] <StevenK> I admit nothing
[08:13] <lifeless> StevenK: dude
[08:13] <lifeless> StevenK: what realm ?
[08:14] <StevenK> lifeless: Dath'Remar
[08:15] <lifeless> hmm, I think I have horde on there
[08:15]  * StevenK is flying his level 49 warlock to the Hinterlands
[08:15] <lifeless> StevenK: horde or ally?
[08:15] <StevenK> Alliance
[08:15] <lifeless> k
[08:15] <lifeless> I have ally on Jubei'thos
[08:16] <StevenK> I think I need to beg some guild mates for a run through Zul'Farrak. At least they probably won't stuff it up.
[08:17] <lifeless> was it your tank or healer that was fucked? or support ?
[08:17] <StevenK> Both
[08:18] <StevenK> The tank did a bad pull, the healer got smashed and died, and then fell offline, leaving us to deal
[08:18] <lifeless> garh
[08:18] <lifeless> for the healer to get smashed your tank isn't holding aggro
[08:18] <lifeless> tanks are one of the easiest things to fuck up, and *everyone* thinks they can tank.
[08:19] <lifeless> *thinks*
[08:19] <StevenK> We managed to clean up and then defeat the end-instance boss sans healer
[08:19] <StevenK> Which *sucked*
[08:20] <StevenK> I know I can't tank, I just curse and point my minion where they tells me
[08:23]  * StevenK isn't particularly looking forward to doing ZF again
[08:42] <proppy> persia: nice edit :)
[08:43] <persia> proppy: Thanks.  The most important part is pointing a the right spec :)
[08:43] <proppy> persia: I liked the s/proppy/Alice and Bob/ part too :)
[08:44] <persia> proppy: Always best to write in the third person for this sort of thing: makes it clear you're not just driving a private wishlist.  Just needs two more patches: have anything else planned today?
[08:45] <proppy> persia: I agree your comments on Outstanding Issues
[08:46] <proppy> persia: I think 'Disable advocation checkbox when level is Contributor:' is already granted by the current code isn't it ?
[08:46] <persia> proppy: Excellent.  The other point I wasn't sure about was the Contributor comment not counting as rejection.  Do you think that it should?
[08:47] <proppy> persia: I think it don't, I wasn't aware that all the comments that are not advocating
[08:47] <proppy> persia: are considered as rejection, what about your own comments ?
[08:48] <proppy> persia: I think they just need to be considered as comments of the uploaders from a REVU code pov
[08:48] <persia> proppy: Any comments except one's own are currently counted as rejection.  I think Contributor comments should be treated like Packager comments.
[08:48] <proppy> persia: agreed :)
[08:49] <persia> proppy: Exactly.  You and I have the same viewpoint
[08:49] <proppy> persia: let's try to setup revu.aminche,com then
[08:49] <proppy> persia: to test the patch somewhere
[08:49] <persia> proppy: I just wanted to check because of the note that Contributor comments otherwise were to look like MOTU comments.  Might need an update.
[08:50] <persia> proppy: I'm completely unfamiliar with the codebase, and not a python person, so I'll leave the implementation to you, but you might want to poke sistpoty who expressed interest earlier.
[08:50] <proppy> It is felt that there should be no distinction between comments from a contributor and those from MOTUs, just like for any other channels: IRC, LP, etc.
[08:50] <proppy> except from the 'advocating' 'rejection' part
[08:50] <proppy> #ubuntuwire ?
[08:50] <persia> proppy: Exactly.  If a Contributor comment is treated like a Packager comment, that's different than "no distinction".  If we agree, you might want to update the quoted bit :)
[08:52] <persia> proppy: Of general interest to pacakgers & reviewers.  Here is likely a better forum (although I'll be in deep idle soon)
[08:53] <proppy>  * Contributors are treated like a Packager comment, (no allowed to advocate, no treated as rejection).
[08:53] <proppy>  * It is felt that there should be no additional distinction between comments from a contributor and those from MOTUs, just like for any other channels: IRC, LP, etc.
[08:55] <persia> proppy: That looks excellent to me.
[08:56] <proppy> norsetto was also a great help on this one
[08:58] <proppy> i wish i could apt-get install revu :)
[10:35]  * Hobbsee waves
[10:35] <civija> hey guys
[10:36] <civija> how can I find out does some package have ubuntu maintainer or is it just synced from debian?
[10:36] <civija> i.e. slrnface
[10:36] <Hobbsee> apt-cache show slrnface
[10:36] <Hobbsee> see what the maintainer says
[10:37] <Kmos> civija: apt-cache show slrnface | grep Version -> if "Version: ... " has "ubuntu" in it, so it isn't synced.
[10:37] <Hobbsee> Kmos: ubuntu-only rebuilds?
[10:38] <Kmos> build1 ?
[10:38] <Hobbsee> (which is why i didn't give that answer)
[10:38] <Hobbsee> Kmos: yeah.  but that will still have a ubuntu maintainer - someone in ubuntu has changed it.
[10:38] <Kmos> right
[10:38] <civija> Hobbsee: it says Gerfried Fuchs <alfie et debian.org>
[10:39] <civija> i was confused with debian email addreess
[10:41] <Hobbsee> civija: *nods*
[10:41] <Hobbsee> oh, drat.  it has had binary mangling
[10:41] <Hobbsee> civija: right, anything with "ubuntu" in the version number, or "build" is not a direct sync
[10:41] <civija> ok, tnx
[10:55] <geser> Kmos: Hi, have you read the mail about you on the motu-council list?
[11:01] <Kmos> geser: the one dholbach sent ? i'm writing it right now..
[11:02] <geser> Kmos: yes, he forwarded it to you
[11:02] <Kmos> geser: i'll answer to it this morning.. thanks for remind me
[11:11] <frenchy> Hi all, I've just tried to `dpkg-buildpackage -S -sa -rfakeroot` but I keep getting a "secret key not available".  Has anyone got a spare moment to help me please?
[11:12] <geser> frenchy: does the Changed-By value in the .changes file match completely with your key id?
[11:14] <frenchy> geser: Thanks heaps ... that pointed me in the right direction.  It's not the right one because I accidentally ran `dch` without the `-m` option.  Nice work.
[11:17] <Kmos> ember_: pt boy :)
[11:19] <frenchy> geser: I'm just reading how to set it permanently so I don't make a fool out of myself again.  Well at least not with `dch`.
[11:20] <geser> frenchy: set DEBEMAIL and DEBFULLNAME and dch will use it to constuct the right value for the changelog entries
[11:22] <frenchy> Ta
[11:55] <coolbhavi> Can I upload an updated package of an existing package in ubuntu to my ppa?
[11:55] <coolbhavi> If so how?
[11:56] <Kmos> coolbhavi: do you have your ppa configure and you know how to upload to it ?
[11:56] <Kmos> i mean, configure in your dput.cf
[11:56] <coolbhavi> yes
[11:57] <Kmos> coolbhavi: you know how to use dch -i ? and package ?
[11:57] <Kmos> you can put the version 1.2.3-1~ppa1
[11:57] <Kmos> for example
[11:57] <Kmos> in the changelog entry
[11:57] <coolbhavi> I want to contribute in packaging... I am relatively new to packaging
[11:57] <Kmos> !packaging | coolbhavi
[11:57] <ubotu> coolbhavi: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[11:58] <knights> Hi guys!
[11:59] <knights> Whens the deadline for new apps for Hardy?
[11:59] <knights> (new versions)
[12:00] <coolbhavi> I have already the source tarballs with me Please help
[12:02] <coolbhavi> I have already the source tarballs with me Please help on how to package
[12:02] <coolbhavi> ?
[12:05] <geser> knights: it should be in the archive before FF (FeatureFreeze) which around Feb 14th, 2008
[12:05] <knights> Thanks geser!
[12:06] <knights> Valentines? :)
[12:06] <jonnymind> hello.
[12:06] <jonnymind> I politely ask for mentoring on the "falcon" package in revu.
[12:16] <coolbhavi> OK I have done the package using debhelper Next?
[12:18] <slicer> jonnymind: I'm not a motu, but you might want to use debhelper for the package.
[12:18] <jonnymind> how does it work?
[12:19] <Kmos> !packaging | jonnymind
[12:19] <ubotu> jonnymind: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[12:21] <slicer> Scroll down to the "Packaging with debhelper" part.
[12:21] <jonnymind> Thank you. I have read that stuff and I hope I adhere to the requiremnts and that I have fulfilled the procedure up to date.
[12:22] <jonnymind> yet the packaging of a programming language seems to be a bit outside the standard procedures indicated in the guides.
[12:23] <slicer> Actually, that wiki page should be restructured. CDBS > debhelper > from_scratch, yet it's listed in the reverse order.
[12:23] <jonnymind> I.e. I have already binary-packaged a .so, a bin and a -dev package, but I don't know how to achieve them from a single source package.
[12:24] <jonnymind> (I have an automated script that creates lintian clean binary packages from a compiled source though).
[12:24] <jonnymind> But I need a bit of help in doing this from the source package.
[12:25] <jonnymind> Also, there is a "namespace" issue someone was mentioning.
[12:25] <slicer> I dunno :( I'm only familiar with the debhelper'd process.
[12:25] <jonnymind> probably "falcon" is too wide; falconpl may be a more sensible naming for the packge.
[12:27] <slicer> falcon uses cmake?
[12:28] <jonnymind> yes
[12:28] <geser> Fujitsu: do you know if bug #129940 was fixed in the last xpdf upload to -security?
[12:28] <ubotu> Launchpad bug 129940 in xpdf "[XPDF] possible buffer overflow and execution of arbitrary code" [Undecided,Confirmed] https://launchpad.net/bugs/129940
[12:28] <jonnymind> I have too many reopsitories and I also develop with VCexpress on windows, so using automake would be a nightmare.
[12:29] <slicer> jonnymind: I haven't tried, but apparanly you can use CDBS with Cmake, which will result in a 3-line debian/rules and most things figured out auomatically for you.
[12:29] <Fujitsu> geser: I'm not quite sure. Do you have a CVE # for that?
[12:29] <jonnymind> Oh; that's good. Any doc about that?
[12:32] <slicer> jonnymind: No.. Actually, it seems I'm mistaken. Some packages add cdbs/cmake support, but it's not in cdbs by default it seems.
[12:33] <geser> Fujitsu: the CVE id mentioned in the links in that bug is CVE-2007-3387
[12:33] <ubotu> Integer overflow in the StreamPredictor::StreamPredictor function in xpdf 3.02, as used in (1) poppler before 0.5.91, (2) gpdf before 2.8.2, (3) kpdf, (4) kdegraphics, (5) CUPS, (6) PDFedit, and other products, might allow remote attackers to execute arbitrary code via a crafted PDF file that triggers a stack-based buffer overflow in the StreamPredictor::getNextLine function. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3387)
[12:33] <jonnymind> Uhm, quite a mess.
[12:33] <jonnymind> However,
[12:33] <jonnymind> as I have already a single binary package from the source package, splitting it into 3 wouldn't seem too hard.
[12:34] <Fujitsu> geser: I have that listed as being unfixed in Dapper, Edgy and Feisty.
[12:34] <jonnymind> It is also pointed out by the guide
[12:34] <jonnymind> But just pointed out.
[12:34] <geser> Fujitsu: ok, I'll subscribe motu-swat to the bug then
[12:34] <Fujitsu> geser: Thanks.
[12:36] <jonnymind> https://wiki.ubuntu.com/PackagingGuide/Basic says "The second paragraph is for the binary package that will be built from the source. If multiple binary packages are built from the source package, there should be one section for each one."
[12:36] <jonnymind> but then it fails to explain how to direct pbuilder to extract the other ones.
[12:36] <jonnymind> I suppose it should be relatively easy.
[12:38] <geser> jonnymind: you give pbuilder the .dsc file (i.e. point it to the source package) and if you got everything right it will produce you several debs
[12:38] <jonnymind> How to instruct it what to get?
[12:38] <jonnymind> i.e. headers + devel .so,
[12:38] <slicer> jonnymind: Just include another binary blurb in the control file. After the 'Package: hello' section, include 'Package: hello-dev' etc.
[12:38] <geser> through files in debian/
[12:39] <jonnymind> yes, but shouldn't I tell pbuilder what subtree or file include in each package?
[12:39] <jonnymind> and what about docs/<pname>/copyright?
[12:39] <geser> jonnymind: look at some small libraries to see how to do it
[12:40] <jonnymind> Ah, I can get the source package for them!
[12:40] <jonnymind> (how come I didn't think about that? :-)
[12:40] <geser> jonnymind: see dh_install, debian/<package>.install tells which file belongs to which package
[12:40] <slicer> jonnymind: I strongly recommend you switch to debhelper instead of doing it from scratch. debhelper has a multi-target template which has most things ready for you.
[12:41] <jonnymind> slicer: I would happily do it, but my build process requires a nonstandard script (build.sh) to be used.
[12:41] <slicer> jonnymind: You can do that with debhelper :)
[12:41] <jonnymind> Ah, that's interesting.
[12:41] <jonnymind> I will dig in that too.
[12:41] <slicer> jonnymind: debhelper creates a set of files in debian/ for you, and you can modify debian/rules as you wish.
[12:42] <jonnymind> Ok, suppose I succeed. How can I update the source package? -- just using dput again?
[12:42] <slicer> jonnymind: However, it also correctly sets shlib files, permissions and compression for man pages, init files, ldconfig etc etc.
[12:42] <slicer> jonnymind: Yes.
[12:42] <jonnymind> Great. I will try that, thanks.
[12:56] <Ubulette> anyone interested to review Bug 174739 ?
[12:56] <Ubulette>  Bug 174739
[12:56] <ubotu> Launchpad bug 174739 in seamonkey "[upgrade] seamonkey 1.1.7" [Undecided,Confirmed] https://launchpad.net/bugs/174739
[14:12] <frafu> Hello, I have build a debian package and assumed that the dependencies to run the package would be the same as the build dependencies. Obviously, they are not the same. Could anybody please tell me whether there is a systematic way to get the list of the dependencies needed to run the package?
[14:16] <StevenK> frafu: Put ${shlibs:Depends} into the Depends line only, and have dpkg-shlibdeps sort out the dependancies if it's compiled
[14:19] <frafu> StevenK: $ (...) is in the Depends line; but it seems that a user that downloaded the package from my ppa could not use it, because dbus-x11 was missing on his system
[14:20] <persia> frafu: If that isn't sufficient, try running the package in a bare chroot (ubuntu-minimal), and checking for errors.  Add a dependency to stop each error.
[14:20] <StevenK> frafu: They're curly braces, too
[14:21] <limac> hey, how can i join the ubuntu devel community for hardy?
[14:21] <persia> limac: You just did :)
[14:22] <persia> limac: More seriously, what would you like to do?
[14:23] <limac> Well actually i don't know
[14:24] <slicer> Anyone have time to do a review update of http://revu.tauware.de/details.py?package=mumble ?
[14:24] <limac> Actually it's pretty boring during the weekends so thought of contributing to ubuntu
[14:24] <persia> limac: OK.  Classes of things to do: 1) Fix bugs, 2) update software, 3) package new software.  I recommend working in that order, but it's best to do what interests you.
[14:24] <frafu> persia: my package (mousetweaks) needs a gui; would that work with ubuntu-minimal?
[14:25] <limac> cool
[14:25] <persia> frafu: Yes, if all the dependencies are correct :)  You'll likely want to use a chroot from which you run X clients back to your local X server.
[14:26] <frafu> StevenK: There are indeed curly braces in my debian/control
[14:26] <limac> do I programming experience in this? if yes what?
[14:26] <imbrandon> limac: and if you go for bugs first ( recomended ) grab some "bite-sized" ones from LP and feel free to ask about in herer to help you through the first couple
[14:26] <StevenK> frafu: Fair enough, just checking
[14:26] <limac> allright
[14:26] <RainCT> limac: no, but it does help if you have some :)
[14:26] <persia> limac: If you have experience in a language, you're encouraged to look at code bugs in that language, but it's certainly not required.
[14:26] <limac> cause I only know C++
[14:26] <imbrandon> limac: not really, it helps to be able to understand a given language but not nessesary 100%
[14:27] <persia> limac: Do you know how to read a stacktrace and figure out the issue?
[14:27] <limac> kindof not an expert at it though
[14:27] <imbrandon> limac: alot of "small" bugs are packing issues anyhow, not much wrong with actual code, i'd say ( total guess ) about %60 of the time
[14:28] <limac> ok
[14:28] <limac> so how do I begin
[14:28] <limac> with the packaging and stuff
[14:28] <persia> limac: OK.  There's a few hundred bugs that need stacktrace review, but there's also a couple hundred packaging bugs that don't need much coding, and likely around 50 "bitesize" bugs which are a good way to become familiar with our processes.
[14:28] <imbrandon> do youhave an area of packages that intrests you, like "games" or "server" or "kde" or something to narrow down your bug hunts ?
[14:28] <imbrandon> limac: ^
[14:29] <limac> no experience with kde
[14:29] <limac> and explain server
[14:29] <imbrandon> yea only an example
[14:29] <frafu> persia: I use pbuilder to check whether the mousetweaks builds properly; now I will have to look up how to run mousetweaks from a chroot environment...
[14:30] <limac> so do i need to install hardy alpha1 for these
[14:30] <imbrandon> limac: well more the question was do you have an area of prefrence to begin, we dont wanna push you into apache2 bugs if you dont even know what a webserver is and such
[14:30] <persia> limac: Best way to begin is to find a bug you can solve.  Then, follow the MOTU/Contributing link Adri2000 gave you as a first pass for the process.
[14:30] <imbrandon> limac: no but a chroot/pbuilder is almost a requirement
[14:30] <imbrandon> !pbuilder
[14:30] <ubotu> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
[14:30] <limac> anything is good for me
[14:32] <limac> wat exactly does pbiulder do?
[14:32] <limac> pbuilder
[14:32] <persia> limac: It's one of the two common systems to test-build package candidates to make sure they will build if uploaded to the repository.  There's a link to more explanation on the Contributing page.
[14:32] <imbrandon> limac: ok then if it was me in your shoes i would do the following ( approx in this order ) 1) setup a pbuilder for hardy ( explaind in that link ) 2) grab 1 or 2 "bitesized" tagged bugs in LP to learn how the MOTU workflow goes and then 3) go crazy getting "bigger" bugs from LP
[14:33] <limac> ok i'll get that installed
[14:33] <limac> right now
[14:33] <frafu> persia: however, I am still wondering whether it will give me all the dependencies; I am afraid that it will not give me the dependencies to packages that are included in ubuntu-minimal. Or do I get something wrong?
[14:33] <RainCT> how can I do something after dh_install got called with cdbs?
[14:33] <persia> frafu: You're exactly correct, but I think we don't support systems that don't have everything in ubuntu-minimal installed, so it shouldn't be an issue (although I may be mistaken)
[14:34] <persia> RainCT: Do you mean post-install, or immediately after the dh_install call?
[14:34] <RainCT> persia: after dh_install
[14:35] <nand> Hiya! I just got a FTBFS notice of the package I submitted, for the hppa arch (and it was build OK for the others archs). The problem is related to the packaging. What is the recommended way to solve an arch-dependent problem considering that I have no way to test?
[14:36] <imbrandon> RainCT: here the bit on cdbs debian/rules overrides , http://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2527787
[14:36] <RainCT> yes I know
[14:36] <RainCT> it says install/foo::, but that doesn't work
[14:36] <persia> RainCT: That's hard.  Are you sure an install/packagename:: rule isn't close enough?
[14:37] <imbrandon> RainCT: if thats not finegrained enough you likely wont want to use cdbs ( it gets into black magic past that )
[14:37] <RainCT> stuff in install/foo:: is being done before dh_install..
[14:37] <imbrandon> binary-install/foo:: ??
[14:37] <frafu> persia: but should the dependencies list theoretically not give all the dependencies, regardless whether they are in ubuntu-minimal or not?
[14:37] <persia> RainCT: You could try binary/foo:: (I don't like internals), or you could play with internals.
[14:38] <imbrandon> frafu: the dep list should list any package that is not "priority: required"
[14:38]  * RainCT is trying with binary-install
[14:38] <StevenK> Or "Essential: yes"
[14:38] <frafu> persia: Is ubuntu-minimal also a subset of xubuntu and kubuntu?
[14:39] <imbrandon> frafu: yes
[14:39] <persia> frafu: Yes.
[14:39] <LucidFox> imbrandon> amarok still doesn't build, even without --with-libkarma
[14:39] <LucidFox> it seems that libkarma is turned on by default, you probably need --without-libkarma: https://launchpad.net/ubuntu/+source/amarok/2:1.4.7-2ubuntu3/+build/464728
[14:39] <imbrandon> LucidFox: ?? shitty, ok let me get a bit more coffee in me and i'll check it out
[14:39] <RainCT> imbrandon: binary-install seems to work :)
[14:40] <frafu> imbradon: and all the packages in ubuntu-minimal are priority: required?
[14:40] <imbrandon> RainCT: great, but if your doing this package from scratch ( e.g. not a update/change from a debian package ) i recomend to use normal debhelper vs cdbs , it will let you be much more finegrained
[14:40] <imbrandon> and learn more
[14:41] <imbrandon> frafu: afaik yes, that is the case, StevenK or persia could probably verify this
[14:41] <StevenK> I'd need to check
[14:41] <limac> sudo pbuilder create <<this takes a lot of time
[14:41] <persia> frafu: You could actually verify yourself with a bit of playing with grep-dctrl
[14:42] <persia> limac: Depending on your bandwidth, yes.  You should only have to do it once.
[14:42] <limac> yeah
[14:42] <imbrandon> limac: yea but it only needs to be done for each dist you want to build for , e.g. right now probably only hardy in your case
[14:42] <imbrandon> s/done/done once
[14:43] <limac> yup
[14:43] <frafu> persia, StevenK, imbrandon: thanks for your explanations and help
[14:44] <imbrandon> and if your not super tight on your hdd space i recomend you backup the base.tgz it initial makes, incase later you tant ( sometimes required for large transisitons ) your base tar
[14:44] <imbrandon> limac: ^
[14:44] <StevenK> % for i in $(apt-cache show ubuntu-minimal | grep Depends | cut -d\  -f2- | sed 's/ //g' | tr ',' '\n') ; do apt-cache show $i | grep Priority ; done | sort | uniq -c
[14:44] <StevenK>      40 Priority: important
[14:44] <StevenK>      38 Priority: required
[14:44] <limac> ok
[14:45] <imbrandon> iirc the base.tgz isnt HUGE, but if you only have a 10gb hdd, you might want to think twice about keeping an extra copy :)
[14:45] <StevenK> So, yes, you can expect everything ubuntu-miminal pulls in to be there.
[14:46] <StevenK> limac: Priority: required is "Packages which are necessary for the proper functioning of the system" and Priority: important is "Important programs, including those which one would expect to find on any Unix-like system."
[14:46] <imbrandon> StevenK: "bash king" :P
[14:46] <StevenK> imbrandon: There is no bashism in that line.
[14:46] <StevenK> So take that back :-P
[14:46] <imbrandon> s/bash/shell
[14:46] <StevenK> :-)
[14:46] <limac> ok, i think it's almost done
[14:47] <limac> now what? after it's done
[14:48]  * StevenK rewrites the line to be quicker
[14:48] <limac> :0
[14:48] <StevenK> Which returns a different result. Wierd.
[14:48] <imbrandon> limac: other tools you will likely need close to the begining ( man or apt-cache show <pkg> if you want more info on each one ) are : devscript bzr build-essential patchutils
[14:48] <imbrandon> devscripts*
[14:48] <persia> bzr?
[14:48] <StevenK> He might need bzr
[14:49] <imbrandon> persia: not long and he will run accross packages that are maintained in bzr, and if packages are changed the "right" thing to do is make a bzr branch published with changes
[14:49] <imbrandon> like mplayer
[14:49] <limac> waht about devscript bzr build-essential patchutils
[14:49] <persia> Maybe.  I got through over 100 uploads before installing bzr.  I think ubuntu-dev-tools is likely more useful for most cases.
[14:49] <limac> ^imbrandon
[14:50] <persia> limac: You want to install those packages.  Likely cdbs as well.
[14:50] <imbrandon> limac: you will likely want those packages installed also, they will help you with fixing bugs
[14:50] <limac> ok
[14:50] <imbrandon> they are "the basic tols of the trade"
[14:50] <imbrandon> :)
[14:50] <imbrandon> tools*
[14:51] <imbrandon> persia: ahh yes i forgot about ubuntu-dev-tools, new fnagled meta packages :)
[14:52] <imbrandon> someday i will finish my meta pacakge , one that makes imbrandon-dev-tools imbrandon-base imbrandon-desktop etc etc etc so i dont have to rember this stuff
[14:52] <imbrandon> hehe
[14:52] <limac> i'll be right back after bkfast
[14:55] <imbrandon> persia: ahh bzr is "recomended" by ubuntu-dev-tools so it will be installed with it
[14:55] <imbrandon> well i think, is recomends installed by default on yet ?
[14:55] <persia> imbrandon: There you go then.
[14:55] <persia> imbrandon: Depends on the tool still.
[14:55] <imbrandon> ahh, /me sticks to apt-get , i'm assuming its on in aptitude
[14:57] <imbrandon> time to make more coffee , brb
[15:22] <imbrandon> persia / StevenK : i thought binary things ( images / gzip'd tar's etc ) were not allowed in debian/ unless they were uu encoded
[15:22] <persia> imbrandon: Except in native packages (and they shouldn't be in debian/ in that case), that's true.
[15:22] <StevenK> They are allowed, it's just that dpkg-source may hate you if they change.
[15:22] <imbrandon> looking at some cdbs doc's quote "The system can handle compressed patch with additional '.gz' or '.bz2' suffix and uu-encoded patches with additional '.uu' suffix."
[15:23] <imbrandon> talking aobut simple-patchsys
[15:23] <persia> StevenK: In non-native?  How do you get them there?  diff.gz can't put them, no?
[15:23] <StevenK> persia: Exactly, which is why dpkg-source will hate you.
[15:23] <persia> StevenK: "...if they change"?
[15:23] <imbrandon> hrm heh ok whats the point of supporting gzip patches then ? heh
[15:23] <StevenK> persia: Well, even if they don't, point.
[15:24] <persia> imbrandon: Dreaming of using xdiff or the like instead of diff likely.  Demonstration of programming skills.
[15:24] <imbrandon> heh ok
[15:28] <geser> gpocentek: any reason to not subscribe ubuntu-archive to bug #173220?
[15:28] <ubotu> Launchpad bug 173220 in xapian-core "Sync request: xapian-core 1.0.4-1 from debian unstable" [Undecided,New] https://launchpad.net/bugs/173220
[15:28] <gpocentek> geser: I just forgot...
[15:29] <geser> gpocentek: u-a is subscribed now
[15:29] <gpocentek> geser: thanks a lot
[15:52] <limac> allright then how can i get that package imbrando?
[15:53] <imbrandon> limac: what package ?
[15:53] <imbrandon> i'm sorry not sure exactly where we left off
[15:54] <limac> limac: other tools you will likely need close to the begining ( man or apt-cache show <pkg> if you want more info on each one ) are : devscript bzr build-essential patchutils
[15:54] <limac> that one^
[15:54] <imbrandon> LucidFox: amaork fix uploaded, thanks for the headsup
[15:54] <crimsun> use a package manager
[15:54] <crimsun> e.g., aptitude, adept, synaptic, ...
[15:54] <limac> dumb me!
[15:55] <imbrandon> limac: ahh "sudo apt-get install devscripts bzr build-essential patchutils ubuntu-dev-tools"
[15:55] <imbrandon> or as crimsun and pkg mgr :)
[15:55] <limac> ok thanx
[15:55] <imbrandon> s/and/any
[15:55] <limac> whats crimsun
[15:56] <imbrandon> crimsun is a person :)
[15:56] <imbrandon> scroll up 3 or 4 lines :)
[15:56] <limac> ah!
[15:57] <imbrandon> btw hiya crimsun :)
[15:57] <Hobbsee> crimsun: is what you call when your sound breaks
[15:57] <limac> srry crimsun, didn't really pay attention to ur nick!
[15:57] <limac> wat after that is done?
[15:57] <imbrandon> ok so you have pbuilder installed and those i just named correct ?
[15:58] <limac> yup
[15:58] <imbrandon> now time to look on LP for a "bitesized" bug to fix to get to know the "processes" i sugest doing one or two of those before moving on ...
[15:58] <imbrandon> one sec i'll get you a url to search the bitesized bugs
[15:59] <limac> whats LP??????
[15:59] <limac> sure take ur time
[15:59] <imbrandon> LP == launchpad.net our bug tracker
[15:59] <limac> ok
[15:59] <limac> I do have an account
[15:59] <limac> i guess
[16:00] <imbrandon> mostl likely but you will need to use it real soon, so you might verify you can log into it while i get you the url
[16:01] <limac> allright
[16:01] <imbrandon> limac: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[16:02] <imbrandon> is the bitsized bugs, i would look through those, and find one that seems fairly trivial as your first fix
[16:02] <imbrandon> announce the bug # in here and i'll walk you through the first one
[16:03] <imbrandon> s/i'll/we'll ( inviting anyone awake to help me along hehe )
[16:03] <ScottK> Good morning all.
[16:03] <imbrandon> heya ScottK
[16:03] <ScottK> Hi there imbrandon.
[16:03] <RainCT> Hi ScottK
[16:04] <StevenK> Morning.
[16:04] <StevenK> Oh damn
[16:04] <persia> RainCT: You don't happen to be up for some shell scripting, do you?  I've a script that's too fragile for release.
[16:04] <ScottK> Hello RainCT and StevenK.
[16:04]  * StevenK waves
[16:04] <RainCT> persia: what's it about?
[16:04] <persia> Good day ScottK
[16:05] <persia> RainCT: processing interdiffs: http://people.ubuntuwire.com/~persia/process-interdiff
[16:05] <limac> i'll b back in a sec
[16:05] <ScottK> Hello persia.  Thanks for looking at disk-manager.  What lintian version were you using?
[16:05] <persia> ScottK: 1.23.36ubuntu1
[16:06] <persia> RainCT: Not terribly important: you were nominated as a likely candidate in the MOTU meeting: feel free to decline :)
[16:08] <ScottK> persia: Thanks.  I guess I need to enable backports ;-)
[16:09] <persia> ScottK: If you'd be up for chasing bug #164509 whilst you're at it, it would make me extra happy .
[16:09] <ubotu> Launchpad bug 164509 in gutsy-backports "Please backport linda 0.3.26ubuntu2 to gutsy" [Undecided,New] https://launchpad.net/bugs/164509
[16:11] <imbrandon> persia / ScottK : i got it
[16:11] <ScottK> persia: Does it work on Gutsy?
[16:11] <imbrandon> ( the backport )
[16:11] <ScottK> K
[16:11] <persia> ScottK: Yes.  Only change is for the menu tests.
[16:11] <persia> imbrandon: Thanks.  I think you already did sparky for that.
[16:11] <limac> allright then, i logged in and there is like a list of bugs what do I do now?
[16:12] <imbrandon> persia: yea i did
[16:13] <persia> limac: Pick a bug that's not assigned to someone else, and figure out how to fix it.  Generate a patch, and submit it to the sponsors queue.
[16:17] <RainCT> persia: what would I've to do then?
[16:18] <limac> how can i know if the bug is assigned to someone else?
[16:18] <persia> RainCT: Well, it'd be nice to error out and print usage with the wrong arguments.  Some error detection to report what went wrong, if anything did, etc.  Currently it's a scrap script I use, and I don't consider it ready for general use.  If you want to make it generally useful, that'd be great.  If not, no worries.
[16:19] <imbrandon> limac: it has an assigned to field in the bug
[16:19] <imbrandon> when you click on it
[16:20] <limac> where is it?
[16:20] <RainCT> limac: next to the status and importance
[16:21] <RainCT> if there's a "-" then it isn't assigned to anybody
[16:21] <limac> gotcha
[16:21] <limac> now how do I fix it
[16:22] <limac> through the sftwares I installed
[16:22] <limac> ?
[16:22] <imbrandon> limac: thats where your problem solving skills are put to use, figure out what the fix is first THEN you can generate a patch
[16:22] <persia> limac: That's the tricky bit :)  If you understand, and can reproduce the bug, you've a better chance.
[16:23] <limac> say i figure out how to fix it, what do i do then?
[16:23] <persia> limac: Generate a patch.  There's some instructions on the MOTU/Contributing page as to how to make the patch.
[16:24] <limac> ok can you please give me a link to that page!! thnx
[16:24] <persia> https://wiki.ubuntu.com/MOTU/Contributing
[16:24] <imbrandon> you generate a fixed source pacakge, then debdiff it against an unchanged package, and attach the debdiff file to the bug in question and subscribe ubuntu-universe-sponsors
[16:24] <RainCT> limac: if you haven't already add the line «deb-src http://archive.ubuntu.com/ubuntu/ hardy main restricted universe multiverse» to your /etc/apt/sources.list and run "sudo apt-get update". Then you will be able to download the source of the package with "apt-get source <packagename>"
[16:25] <bulio> hi all
[16:25] <bulio> I'm just wondering, can I find a guide on how to create a ubuntu package?
[16:25] <limac> thanx RainCT I forgot to do that>>
[16:26] <limac> hi bulio
[16:26] <imbrandon> !packageguide
[16:26] <ubotu> packagingguide is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[16:26] <imbrandon> bulio: ^^
[16:26] <bulio> thanks
[16:28] <imbrandon> persia: linda will be done on the next archive run ( unless Hobbsee has the powers to doso now [ Hobbsee #164509 ] )
[16:28] <persia> imbrandon: Thanks.  I'm not in a rush :)
[16:28]  * Hobbsee does not, if it's a sync request
[16:28] <imbrandon> Hobbsee: backport
[16:28] <persia> Hobbsee: backport, but given your current environment, likely not anyway.
[16:28] <Hobbsee> nope, still can't tehn
[16:28] <imbrandon> k, next archive run it is then :)
[16:31] <limac> so first i have to be assigned to one of the bugs
[16:31] <limac> ?
[16:31] <limac> :)
[16:31] <limac> ;)
[16:31] <imbrandon> limac: no, but its best to make sure no one else is ( to not dupe efforts )
[16:31] <limac> ok  then
[16:33] <limac> I did that
[16:33] <limac> oops disregard that
[16:36] <imbrandon> debuild -S -sd
[16:36] <imbrandon> err
[16:42] <sharms> anyone have a minute to review a very small debdiff for a package that needs to be updated via SRU?
[16:43] <RainCT> sharms: URL?
[16:43] <sharms> http://www.sharms.org/files/ncpfix/ncpfs.debdiff
[16:44] <sharms> the package compiled is at http://ppa.launchpad.net/sharms/ubuntu
[16:45] <persia> sharms: 1) Your changelog & version is odd for an SRU.  2) Why the .po changes?
[16:45] <RainCT> sharms: the email is wrong "sharms@ironforge"
[16:45] <sharms> .po just was a result of the build script I believe
[16:45] <bulio> lets say I'm creating a package for firefox3
[16:45] <bulio> how can I get all the dependencies in my .deb?
[16:45] <RainCT> bulio: it's already there, granparadiso
[16:45] <RainCT> :P
[16:45] <sharms> basically just the syslog.h and the uncommenting of the FIND_ISR fix bug #140464
[16:45] <ubotu> Launchpad bug 140464 in ncpfs "ncpfs 2.2.6-4 breaks ncpmount" [Undecided,Confirmed] https://launchpad.net/bugs/140464
[16:46] <bulio> RainCT, I know, I want to make my own
[16:46] <RainCT> sharms:  you should remove changes from the diff that were added unexpectedly
[16:46] <persia> bulio: Take a look at the firefox-3.0 package from hardy.
[16:46] <persia> bulio: If you really want to do your own, just use it as an example.
[16:46] <bulio> then manually copy the dependencies to my config file?
[16:50] <sharms> RainCT, persia : I edited the debdiff, should look more sane now: http://paste.ubuntu-nl.org/47409/
[16:51] <limac> so I have to patch the bug huh? so all bugs should be patched?
[16:52] <persia> sharms: Your version should be something like 2.2.6-4ubuntu1.1 (more than gutsy, less than hardy), and the target gutsy-proposed.  On the other hand, unless there's a strong argument otherwise, you probably want to put 2.2.6-4ubuntu2 into hardy first.  Further, I'd use 2 changelog lines.
[16:52] <persia> limac: Most bugs require a patch to fix.  If you can fix it without changing the package, that's good too :)
[16:53] <limac> ok so ALL of 'em don't require to b patched
[16:53] <limac> :0
[16:53] <limac> :)
[16:53] <RainCT> limac: btw, what bug are you working on?
[16:55] <sharms> persia: I have never done that before, when you are saying to use 2 changelog lines does that just mean the next entry up put in something like: ncpfs (2.2.6-4ubuntu2) hardy; urgency=low and below that have ncpfs (2.2.6-4ubuntu1.1) gutsy; urgency=low
[16:55] <limac> I'm still looking for the ones that are not yet assingned to anybody
[16:56] <persia> sharms: 2 changelog lines being one for the FTBFS and one for the -330 issue.  You'll want two separate debdiffs, one for hardy, and one for gutsy-proposed.  Note that I've yet to have a successful SRU, so I may not be the best person giving advice (but it at least matches the docs).
[16:57] <sharms> persia: ok thanks :)
[17:01] <limac> does the list of bugs always stay the same or do they refresh every once in a while?
[17:03] <persia> limac: It refreshes constantly, based on user input.  On the other hand, the list of bitesize bugs doesn't change very often.
[17:05]  * RainCT has just reported a bitesize bug
[17:05] <limac> sweet
[17:06] <RainCT> (well, actually I reported two, but one is already taken :P)
[17:06] <oly-> could do with a bit of help, finally got my package to build, except the resulting .deb is 2.2k where as the tar.gz file is 21mb
[17:07] <oly-> any ideas on what could be the cause ?
[17:07] <RainCT> oly-: can you upload the source somewhere?
[17:08] <oly-> yeah sure have to give me a few secs
[17:08] <persia> oly-: You might also find something informative in the output of dpkg --contents foo.deb
[17:09] <oly-> okay uploading, will try that as well persia,
[17:14] <oly-> looks like its just not adding any files at all to the deb
[17:23]  * RainCT notices that there's really a lot of demand for bitesize bugs :P
[17:24]  * persia notes that packaging an existing patch is also a great way to help.
[17:25] <RainCT> persia: shouldn't bugs with patches but no debdiff get the bitesize tag, too?
[17:26] <persia> RainCT: No, as the patch may be wrong, or hard to understand.  Those patches need review & testing.  Many may be bitesize, but it's not much harder to debdiff them than to determine if they are.
[17:26] <oly-> okay, i have uploaded the files http://ubuntusm.org/files/debian.tar.gz and http://ubuntusm.org/files/usm-core.orig.tar.gz
[17:26] <oly-> if anyone wants to take a look, this is my first attempt at packaging so pointers would be useful,
[17:26] <RainCT> ah
[17:27] <oly-> i uploaded the debian folder, i created to build the package along with the source
[17:27] <oly-> i am just using dpkg-buildpackage -rfakeroot to build it
[17:28] <RainCT> oly-: (next time please upload .orig.tar.gz, diff.gz and the .dsc file and provide the link to the .dsc, as this way it can be downloaded with dget)
[17:29] <oly-> oh, right sorry did not realise that :p
[17:29] <oly-> i can upload if you like
[17:30] <crimsun> yay, down to 10 bugs in PA core.
[17:30] <RainCT> no don't worry
[17:31] <oly-> i have a load of packages todo, so just want to get to a point where i can make suitable package to get into ubuntu
[17:32] <metusaleh> Hi, I just uploaded my first patch to bug 121068 which corrects several bugs in the sysinfo package following this guide : https://wiki.ubuntu.com/Bugs/HowToFix
[17:32] <metusaleh> The guide suggested I try to find a developer in this channel to review the patch (as this is my first attempt I think it may be very useful :-) )
[17:32] <metusaleh> There is an issue with the close button in the about dialog box that I did not manage to correct (maybe someone with more knowledge of glade could correct this)
[17:32] <ubotu> Launchpad bug 121068 in sysinfo "sysinfo reports gutsy as lenny/sid" [Medium,Confirmed] https://launchpad.net/bugs/121068
[17:36]  * RainCT is downloading
[17:37] <oly-> yeah, its a bit big, i stripped a oad of files out as well
[17:40] <persia> metusaleh: Thanks for working on this.  I'll take a look.
[17:43] <persia> metusaleh: That's a nice comprehensive patch.  Thanks,  Would you like to work on integrating it into the distribution, or leave that for someone else?
[17:44] <metusaleh> persia: I'd like to include it into the distribution but will need some help
[17:46] <olopez> hi
[17:46] <olopez> i'm want to lacate where ubutu load kernel modules , is it documented ?
[17:47] <persia> metusaleh: The next step is to create a debdiff for the next revision including the patch.  Before doing that, it's worth looking at what other bugs affect the package, just to make sure you've gotten as many as you can (I think you may well have).
[17:48] <crimsun> olopez: can you be more specific?
[17:48] <olopez> yes
[17:48] <olopez> ubuntu load some kernel modules that i don't want
[17:48] <persia> metusaleh: Then, you'll want to determine which patch system the package is using (https://wiki.ubuntu.com/PackagingGuide/PatchSystems should help).
[17:49] <crimsun> olopez: blacklist them
[17:49] <RainCT> metusaleh:  if you have ubuntu-dev-tools installed, running what-patch on the terminal will tell you
[17:50] <olopez> crimsun: i must put it on /etc/modprobe.d/blacklist , it is the way ?
[17:50] <RainCT> olopez: yep
[17:50] <crimsun> olopez: I recommend you use another file
[17:51] <metusaleh> persia: I looked at all the sysinfo bugs that were reported in ubuntu and corrected all I could (which is most of them except the close button in the about box that does nothing and a possible incorrect cpu freq which I could not reproduce)
[17:51] <metusaleh> Is there a webpage that explains how to create a debdiff ?
[17:51] <crimsun> olopez: e.g., /etc/modprobe.d/blacklist-olopez
[17:51] <olopez> ok thanks crimsun
[17:51] <persia> RainCT: Just as an enhancement, it might be worth checking ../foo.diff.gz with lsdiff -z to see if there are changes outside debian/ for the raw patch system.
[17:51] <persia> metusaleh:
[17:51] <crimsun> olopez: note the syntax in the other blacklist files, too.
[17:51] <persia> metusaleh: https://wiki.ubuntu.com/MOTU/Contributing might be helpful for that.
[17:52] <persia> See section 2
[17:52] <persia> Err. 3.2
[17:52] <olopez> if i black list a module , dependences are also blacklisted ?
[17:52] <crimsun> olopez: no.
[17:53] <olopez> ok i need blacklist module by module , thanks for the information i don't see it in any place
[17:54] <persia> metusaleh: Essentially, you'll want to download the latest version in hardy, apply your patch, update the changelog, build, test, and run the debdiff command.
[17:56] <metusaleh> persia: thanks, I'll give that a go
[17:56] <persia> metusaleh: I've assigned you the bug (assuming that was your patch), so people know you are working on it.  Good luck, and ask here if you have any questions.
[17:56] <RainCT> persia: I filed a bug on u-d-t about that
[17:57] <persia> RainCT: You agree that's sensible then?  I wasn't sure.  Thanks.
[17:58] <RainCT> persia: I don't know lsdiff, but if it just tells if there are changes outside debian/ or not then I agree that I'd be good to add the check
[17:58] <persia> RainCT: It just lists all the files changed in a diff.  It's a useful tool, even if not integrated: you can find it in pathutils.
[17:58] <persia> Err.  patchutils.
[17:59] <RainCT> ah, I see
[17:59] <cbx33> yo yo yo everybody
[17:59] <RainCT> hey cbx33
[17:59] <metusaleh> persia: thanks, I've set the other sysinfo bugs that should also be corrected to "In Progress"
[18:00] <metusaleh> bye
[18:00] <persia> metusaleh: Great.  You've also assigned yourself?
[18:00] <RainCT> persia: ah I see. a "There are files modified outside debian/" notice would be good, I think
[18:00] <metusaleh> persia: yes, I assigned myself
[18:02] <persia> RainCT: I agree.  I really don't like packages that have changes in debian/patches/ and changes in the diff.gz directly.  One or the other, but both is just confusing.
[18:05] <lynx> hi ubuntu masters...
[18:06] <limac> hello
[18:07] <limac> can't find any bugs I am comfortable with
[18:07] <lynx> my problem: I 've nokia n73 mobile, i want to use it as USB Modem in my ubuntu os, but i dont know how to do for that, if u have any idea then plz tell me that how to do that..(use USB Modem)
[18:07] <Nafallo> limac: find one you are not and get rid of it then? that should make you feel better ;-)
[18:08] <persia> lynx: This really isn't a support channel.  You will likely have better luck in #ubuntu.
[18:08] <Nafallo> lynx: re-direct to #ubuntu please. this isn't a support channel.
[18:08] <olopez> crimsun: hi again
[18:08] <crimsun> olopez: hi.
[18:08] <lynx> then plz which s teat support channel that give me this question answer provide link for that
[18:08] <persia> limac: Hmm.  That's harder then.  You might consider joining the bugsquad, and watching the bug traffic in #ubuntu-bugs, so you can be the first to grab the next easy one that gets reported.
[18:09] <olopez> i blacklisted some modules joydev , apparmor and commoncap
[18:10] <olopez> but i restart the computer and i do a lsmod and apparmor and commoncap are still there
[18:11] <olopez> have you any idea ?
[18:11] <limac> ok but I am waiting for new ones. and how exactly can i be a prospective developer?
[18:12] <Nafallo> lynx: #ubuntu
[18:13] <limac> what to do to become a prospective developer?
[18:16] <oly-> RainCT, managed to download  it yet ? or is it being super slow
[18:16] <imbrandon> limac: just by "wanting to" e.g. you already have staring today by comming here
[18:16] <imbrandon> starting*
[18:16] <cbx33> limac, learn, listen, try, help
[18:16] <RainCT> oly-: ah yes, got it
[18:17] <RainCT> let's see
[18:17] <oly-> cool, probably something silly im doing :p
[18:18] <RainCT> oly-:	I think stuff in /etc/usm should be in /usr/share/usm
[18:18] <RainCT> oly-: changelog says "new upstream release" but it's the first one listed there
[18:19] <oly-> why do you say that ? /etc/usm is the main program folder
[18:19] <RainCT> oly-:	etc is for configuration files
[18:20] <RainCT> oly-: you don't need uploaders: in debian/control if you are already the maintainer
[18:20] <oly-> okay, will move it to /usr/share/usm
[18:20] <RainCT> latest standards version is 3.7.3 afaik
[18:20] <RainCT> XS-Vcs-Bzr should just be Vcs-Bzr now
[18:21] <RainCT> and it's the repository for the package and now upstream's
[18:21] <RainCT> "Upstream Author(s)"     remove the (s) or lintian will complain
[18:22] <limac> what are some ugs u guys are working on?
[18:22] <limac> bugs
[18:22] <RainCT> (I would indicate https://launchpad.net/usm/+downloads but this doesn't really make a difference)
[18:22] <oly-> okay, any ideas as to what woudl cause the files ending up in the deb though ?
[18:22] <oly-> i am fixing the other bits now
[18:24] <RainCT> I'm not sure but it seems to me that the stuff in postinst should rather be indebian/ rules
[18:24] <RainCT> and about the rules files, I can't say anything because I use cdbs always :P
[18:25] <oly-> okay, well i was using dpkg -b packagename to make my packages till i was told not to :p
[18:28] <limac> on what types of bugs do u need to apply the patch to/
[18:29] <oly-> is it likely to be the rules file, stopping my files ending up in the final deb ?
[18:30] <oly-> made all the other changes except the postinst, that will require more research into the rules files
[18:31] <oly-> at the moment though i want to just get a package built with all the files included so i can try it and make sure it works,
[18:32] <RainCT> #$(MAKE) DESTDIR=$(CURDIR)/debian/usm-core install
[18:33] <RainCT> the make is commented, might it be because of this?
[18:33] <RainCT> oly- ^
[18:33] <oly-> could be :)
[18:36] <oly-> although uncommenting seems to have made no change :/
[18:36] <oly-> is it most likely to be something in the rules file ?
[18:37] <RainCT> indeed
[18:39] <limac> how can I patch a bug?
[18:40] <RainCT> limac: what bug is it?
[18:40] <Flare183> !patch | limac
[18:40] <ubotu> limac: Patches are files describing the changes in code to achieve some results.  There are a number of ways these can be produced, but https://wiki.ubuntu.com/Bugs/HowToFix and https://wiki.ubuntu.com/PackagingGuide/PatchSystems may provide some useful guidelines.
[18:40] <limac> oh I am just curious
[18:40] <limac> disregard that sr
[18:42] <limac> thx ubotu
[18:42] <RainCT> ubotu is a bot :P
[18:42] <ubotu> Sorry, I don't know anything about is a bot :p - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[18:43] <limac> like a robot!:)
[18:43] <limac> :)
[18:43] <RainCT> heh
[18:52] <oly-> thxs for all the help you have given RainCT,
[18:52] <oly-> going to look into my rules file and see what i can figure out
[18:52] <RainCT> oly-: you're welcome :)
[18:53] <RainCT> ok, good luck
[18:54] <limac> dumb question but what do u need to no to fix bugs!
[18:54] <limac> is it basically like how we interacted in the forums or is it different?
[18:56] <jpatrick> limac: prehaps https://wiki.ubuntu.com/HelpingWithBugs might help you?
[18:56] <limac> thx jpatrick!!!!!
[19:30] <bulio> how do I read an ecrypted PGP message?
[19:30] <bulio> I have my key and all but I can't see the messagwe
[19:32] <Nafallo> bulio: decrypt it
[19:32] <sistpoty> hi folks
[19:32] <bulio> Nafallo, how?
[19:32] <bulio> I type gpg, then paste my message
[19:33] <bulio> I enter my passkey
[19:33] <bulio> but I can't see the msg
[19:33] <Nafallo> bulio: why encrypt it again? :-)
[19:33] <bulio> how do I decrypt it then?
[19:33] <bulio> how do I decrypt it then?
[19:34] <Nafallo> or hmm. maybe it does not.
[19:34] <bulio> I can see the start of the message
[19:34] <geser> bulio: was it encrypted to you?
[19:34] <bulio> but how do I scroll it down in terminal
[19:34] <bulio> geser, yes, from Ubuntu PPA
[19:34] <Nafallo> so it IS decrypted then :-)
[19:35] <bulio> Nafallo, but all i can see is the header
[19:35] <geser> encrypted mails from PPA?
[19:35] <bulio> yeah
[19:36] <geser> since when is PPA sending encrypted mails?
[19:37] <bulio> to enable PPA for the first time
[19:37] <geser> ah
[19:37] <geser> what error do you get from gpg?
[19:37] <bulio> none
[19:38] <bulio> I paste my pgp message
[19:38] <bulio> but all I see is:
[19:38] <geser> you can also put the encrypted text (including the ------ lines) into a file and use gpg --decrypt on it
[19:39] <bulio> http://rafb.net/p/6cSlXH51.html
[19:39] <Nafallo> bulio: you need a passphrase :-)
[19:39] <bulio> that worked geser
[19:39] <bulio> thanks!
[19:43] <bulio> how do I build firefox 3 with the PPA?
[19:48] <sistpoty> !pastebin | sistpoty
[19:50] <bulio> !ppa bulio
[19:50] <ubotu> Sorry, I don't know anything about ppa bulio - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[19:50] <sistpoty> anyone who'd like to proofread the meeting minutes? http://paste.ubuntu-nl.org/47433/
[20:00] <geser> sistpoty: only a minor correction: use 2007-12-21 for the date of the next meeting, I don't know how many people are used to parse 12/21 correctly. It took me some time during the meeting to parse it as a date.
[20:00] <sistpoty> geser: ok, thanks
[20:01] <bulio> how do I build firefox 3 with the PPA?
[20:01] <sistpoty> and sent
[20:02] <geser> bulio: have you a source package for it already?
[20:03] <bulio> I have the nightly tarball
[20:03] <ScottK> geser: Thanks for your mail on the MC list.
[20:03] <geser> bulio: then you are missing the packaging bits
[20:04] <bulio> which bits?
[20:07] <geser> bulio: the debian/ dir or is it included in the nightly tarball?
[20:07] <bulio> which bits?
[20:07] <bulio> oops
[20:07] <bulio> no
[20:12] <bulio> ok I downloaded firefox source
[20:12] <bulio> now what?
[20:16] <Jazzva> bulio: Maybe you could go through FF2/3 source packages to see how they are built. AFAIK, building Mozilla packages is not a trivial thing :).
[20:16] <bulio> Jazzva, but I want to make a .deb, which I can place in a repo for people to download
[20:16] <Jazzva> bulio: You can get source packages by issuing "sudo apt-get source package-name", where "package-name" is "firefox" for FF2 and "firefox-3.0" for FF3
[20:18] <sistpoty> *whistle*
[20:19]  * Nafallo puts one of those party things in sistpoty 
[20:19] <sistpoty> party things?
[20:19]  * sistpoty is just having fun with revu-production *g*
[20:19] <Nafallo> yepp. those who sound awful ;-)
[20:20] <Jazzva> bulio: You still need to make rules file which will do all the stuff... Anyway, there is firefox 3 package in repositories (alpha 8 for Gutsy and beta 1 for Hardy, if I remember correctly). Also, you can get the latest from Ubulette's PPA.
[20:21] <bulio> Jazzva, well I need to guide to do it on my own
[20:21] <bulio> I'm interested in building my own Firefox-3 from the latest nightlies
[20:23] <ScottK> bulio: Then build it locally and use it.  No need to tie up the PPA buildd's for that.
[20:23] <bulio> ScottK, its for a distro based off Ubuntu
[20:23] <Jazzva> bulio: Good luck :). I think that taking a look at rules file from firefox package from repos would be helpful.
[20:24] <bluefoxicy> is there a discussion on why vmware-server was pulled from ubuntu
[20:24] <ScottK> bluefoxicy: It wasn't
[20:24] <bluefoxicy> ScottK:  from partners?
[20:24] <ScottK> I think they just pulled openssl097.  Isn't vmware-server still there?
[20:24] <bluefoxicy> ScottK:  it used to be in commercial, which became partners
[20:24] <bluefoxicy> partners only has opera though last I looked
[20:25] <ScottK> It was recently uploaded to partners
[20:25] <Ubulette> Jazzva, fyi, I've pushed b1 for gutsy to my ppa a while ago too. i'm working on b2 right now
[20:25] <bluefoxicy> ScottK:  ah, ok, so they've added stuff since last month
[20:25] <ScottK> bluefoxicy: Friday 30 November 2007
[20:25] <bluefoxicy> ah thanks
[20:25] <ScottK> Is when it was added.
[20:26] <Jazzva> Ubulette: Yeah, I've seen it :). Tried to install it from deb in Gutsy, got tied up in dependencies, settled for a8 :).
[20:26] <Ubulette> ?
[20:26] <Ubulette> nss/nspr ?
[20:26] <Jazzva> Yep, I think...
[20:26] <bluefoxicy> ScottK:  thanks
[20:26] <bluefoxicy> ScottK:  someone should maintain an rss feed that tells you when new stuff is added <_<
[20:27] <ScottK> bluefoxicy: No problem.  There is one.  That's how I found out.
[20:27] <bluefoxicy> ScottK:  oh, where?
[20:27] <Ubulette> Jazzva, everything was in my ppa. did you grab the debs manually or did you use it as a repo ?
[20:27] <ScottK> bluefoxicy: It's the standard gutsy-changes RSS.
[20:27] <ScottK> Let me lookl
[20:27] <Jazzva> manually...
[20:28] <bluefoxicy> ScottK:  ah, there's rss feeds for changes  O_O  I didn't know that!  :D
[20:28] <Jazzva> I'll try it later again :)...
[20:28] <Jazzva> Ubulette ^^
[20:28] <ScottK> bluefoxicy: http://media.ubuntu-nl.org/rss/gutsy.xml
[20:29] <bluefoxicy> ubuntu-nl  ??
[20:29] <ScottK> Yes.  Seveas
[20:29] <bluefoxicy> ah ok :)
[20:29] <bluefoxicy> that explains a lot
[20:30] <Seveas> ScottK, those feeds might actually move to ubuntuwire soon
[20:30] <Seveas> need to talk to imbrandon about that :)
[20:30] <ScottK> Seveas: OK.  Please warn us before you move them.
[20:31] <Seveas> the current feeds will be replaces with a feed with one post containing the info :)
[20:33] <bluefoxicy> The ethernet device "eth0" was not detected on your system.  Available ethernet devices detected on your system include ath0, eth1.  Are you sure you want to use this device? (yes/no) [no]
[20:33] <bluefoxicy> Invalid default answer!
[20:33]  * bluefoxicy hacks up the install script.
[20:38] <bluefoxicy> bah I had to edit vmware-config-network.pl
[20:39] <ScottK> bluefoxicy: This probably isn't the best channel for whining about proprietary software.  ;-)
[20:42] <bluefoxicy> heh
[20:42] <ScottK> imbrandon: When you approve a backport you're supposed to set it to In Progress (I just did that for Linda).
[20:46] <_polto_> hello
[20:46] <_polto_> how can i build a source package to be compiled on PPA if the source tar does not have central ./configure or Makefile ? the sources are normally build truth ./install-cris-tools and i should respond (by default) to all questions ...
[20:51] <bluefoxicy> ScottK:  where the hell do I go to figure out why this is broke
[20:51] <bluefoxicy>    Bridged networking on /dev/vmnet0                                  failed
[20:52] <ScottK> bluefoxicy: The people that support vmware.
[20:52]  * ScottK really has no idea.
[20:54] <bluefoxicy> k
[20:54] <bluefoxicy> ScottK:  vmware's support model is basically there's nowhere to contact them on the site last i looked ;p
[20:54] <bluefoxicy> aside from sales
[20:55] <ScottK> That sounds intentional.
[20:55] <bluefoxicy> (I hate commercial software)
[20:55] <ScottK> Then don't use it.  '-)
[20:55] <bluefoxicy> ScottK:  they're totally disinterested unless you pay $1000 for esx ;p
[20:56] <ScottK> A Canonical support contract is cheaper than that ...
[20:56] <RainCT> _polto_: if install-cris-tools has a way to don't let it ask questions and to tell it to install stuff in debian/<package name>, then call it in debian/rules. if not, you can either patch it, or do the same yourself
[20:56] <bluefoxicy> ScottK:  well it's $1000 for ESX, and then you can get a premium support package or smth on top of it
[20:56] <bluefoxicy> ScottK:  ubuntu forums is cheaper than that
[20:57] <ScottK> Well sometimes you get what you pay for.
[20:57] <ScottK> You might ask zul.
[20:57] <RainCT> bluefoxicy: why not use virtualbox?
[20:57] <_polto_> RainCT, thanks
[20:57] <sistpoty> ok, gotta go... cya
[20:57] <RainCT> _polto_: yw :)
[20:58] <bluefoxicy> RainCT:  because virtualbox is impossible to get non-nat networking working
[20:58] <bluefoxicy> I tried
[20:58] <RainCT> ah
[20:58] <bluefoxicy> I wrote scripts and screwed with bridged networking and in the end it disabled my wireless and I had to uninstall brctl and reboot
[21:00] <bluefoxicy> heh vmware just doesn't work with wifi
[21:02] <Ubulette> I still need a sponsor for Bug 174739. It contains 3 security fixes.
[21:02] <ubotu> Launchpad bug 174739 in seamonkey "[upgrade] seamonkey 1.1.7" [Undecided,Confirmed] https://launchpad.net/bugs/174739
[21:14] <bobbo> Hi, ive built a package with some bug fixes for showfsck but im totally stuck on getting it included. How do i go about this?
[21:18] <pochu> bobbo: uploading to REVU is a good idea
[21:18] <pochu> !revu | bobbo
[21:18] <ubotu> bobbo: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[21:19] <pochu> bobbo: another option is to post the debdiff in the launchpad bugs and subscribe ubuntu-universe-sponsors
[21:20] <bobbo> Can a REVU admin sync my key into the REVU keyring?
[21:21] <pochu> siretart, imbrandon, LongPointyStick ^
[21:22] <pochu> bobbo: I assume you are in ~ubuntu-universe-contributors and have your key in your launchpad profile, right?
[21:22] <bobbo> yes just signed up to ~ubuntu-universe-contributors, they key is just the key you use to sign the code of conduct right?
[21:23] <pochu> yep
[21:30] <bobbo> pochu, guessing im waiting til the cron sync tonight then?
[21:31] <pochu> bobbo: I think an admin needs to run it manually
[21:31] <pochu> i.e. there's no cron for it
[21:31] <Ubulette> there's no more cron for that
[21:31] <bobbo> all night IRC camp :D
[21:31] <pochu> hey Ubulette
[21:54] <johnny_> hi, how do you build an ubuntu package?
[21:55] <johnny_> i have built a package, but it seems to be debian style
[21:55] <johnny_> am i missing an option?
[21:58] <ScottK> johnny_: That's the type of packaging that Ubuntu uses.
[21:58] <johnny_> ldm depends on libpango1.0-0 (>= 1.18.3); however:
[21:58] <johnny_>   Version of libpango1.0-0 on system is 1.18.2-0ubuntu1.
[21:59] <johnny_> oops.. that's a bad difference
[21:59] <johnny_> lemme try to get my old output
[21:59] <ScottK> johnny_: I think you need to ask a more specific question.
[21:59] <RainCT> is there any doc on bash completion?
[22:00] <ScottK> RainCT: You are remembering that Dash is the default shell in Ubuntu, right?
[22:00]  * RainCT would like to add tab autocompletion to some scripts, like desktop-file-validate and pbuilder-dist..
[22:01] <ScottK> Right, but don't assume Bash.
[22:01] <RainCT> ScottK: why is it reading ~/.bashrc then?
[22:02] <ScottK> Dunno.
[22:03] <pwnguin> is dash the default shell for users?
[22:04] <pwnguin> i thought bash still was
[22:04] <ScottK> Could be.
[22:04]  * ScottK is not an expert and all the systems I have handy were upgraded from earlier releases.
[22:04] <pwnguin> its just the scripts that say #!/bin/sh that expect bash that get hosed
[22:05]  * RainCT known autocompletion works by adding a file in /etc/bash_completion.d/, but can't find any documentation about it's syntax..
[22:05] <Ubulette> bash is still the default for users but sh is a link to dash
[22:06] <RainCT> ah
[22:08] <Ubulette> did you read /usr/share/doc/bash/README.bash_completion.gz ?
[22:10] <Ubulette> there are also tons of examples in /usr/share/doc/bash/completion-contrib/
[22:10] <Ubulette> you just need to be fluent in shell ;)
[22:13] <RainCT> doesn't really help much.. but thanks :)
[22:16] <Ubulette> just take one as a starting point and modify it. that's the easiest way
[22:24] <ScottK> Are we on Standards version 3.7.3 like Debian is now?
[22:27] <cdm10> I'm learning to write Python programs, and I'd like to learn how to package them for Ubuntu. What's the best way to go about learning this?
[22:28] <pochu> ScottK: yes, although lintian needs to be merged/synced
[22:28] <ScottK> cdm10: Are you learning to use Python distutils as part of your learning to use Python?
[22:28] <ScottK> pochu: Thanks.
[22:29] <cdm10> ScottK: No, I'm not sure what that is or how to use it. I just have a gtk/glade app that I'd like to learn how to put into an Ubuntu package.
[22:30] <ScottK> cdm10: OK.  In general packaging stuff done in Python is very easy if you have a distutils setup.py.  I'd suggest you look into that first.
[22:31] <cdm10> ScottK: okay. Any resources for learning that?
[22:31] <ScottK> cdm10: You can find it in the Python docs on python.org.
[22:31] <cdm10> alright.
[22:31] <ScottK> cdm10: You can also look at python packages for examples.  apt-get source pypolicyd-spf will give you one example.
[22:34] <cdm10> ScottK: unable to find source pkg for that
[22:34] <cdm10> ScottK: that's ok, I tried alacarte and that worked
[22:35] <ScottK> OK
[22:35] <ScottK> cdm10: What release are you running?
[22:35] <Amaranth> alacarte doesn't use distutils
[22:37] <RainCT> great, got autocompletion for desktop-file-validate working :)
[22:38] <Amaranth> Ah, RainCT, that reminds me :)
[22:38] <Amaranth> The policy of marking bugs in launchpad as medium importance just to get them off the list of untouched bugs is really annoying
[22:39] <RainCT> heh
[22:39] <Amaranth> you seemed to have been the one that touched bugs i get mail for :)
[22:39] <Amaranth> for compiz we actually _use_ the importance so getting a bunch of medium bugs disrupts things
[22:40] <cdm10> ScottK: Gutsy
[22:41] <RainCT> Amaranth: well.. I'll leave those then. sorry
[22:41] <ScottK> cdm10: I imagine you don't have source packages for Universe enabled then.
[22:42] <cdm10> ScottK: that's possible, hold on
[22:42] <Amaranth> all the other things are fine but changing the importance puts a whole bunch of bugs on the "need to look at for next release" list
[22:42] <Amaranth> dupe checking and such is appreciated though :)
[22:42] <ScottK> Anyone running Gnome have a moment to check something for me?
[22:42] <cdm10> ScottK: sure
[22:42] <Amaranth> ScottK: What do you need?
[22:43]  * Fujitsu also flies in.
[22:43] <ScottK> cdm10: (since you volunteered first) please open a python shell
[22:43] <cdm10> ScottK: done
[22:43] <ScottK> do 'import os'
[22:43] <cdm10> yep
[22:43] <ScottK> then 'print os.environ'
[22:43] <frenchy> Hi persia.
[22:44] <cdm10> ScottK: should i pastebin that?
[22:44] <ScottK> cdm10: Yes please.
[22:44] <Amaranth> are you looking for a particular variable?
[22:44] <ScottK> Amaranth: XAUTHORITY
[22:44] <cdm10> /home/caleb/.Xauthority
[22:44] <Amaranth> /home/travis/.Xauthority
[22:45] <ScottK> My Kubuntu doesn't have it set and I'm not sure if it's reasonable to expect it.
[22:45] <frenchy> Just a quick question, what lintian command are you running that generates the warnings for the manual page for me-tv?
[22:45] <Amaranth> I thought gdm set that
[22:45] <cdm10> Amaranth: and Kubuntu uses KDM... perhaps it behaves differently.
[22:45] <Amaranth> right
[22:45] <Amaranth> kdm should die :P
[22:45] <ScottK> Right.  Gotta run for dinner.  Back in a bit.
[22:46]  * Fujitsu watches ScottK vaporise Amaranth,
[22:46] <ScottK> Amaranth: Some of us feel that way about GDM.
[22:46] <ScottK> Fujitsu: It's dinnertime and vaporizing takes more time than I have right now.
[22:46] <Amaranth> I was under the impression that this is one area where most people were in agreement that gdm was better :P
[22:48] <Fujitsu> LaserRock!
[22:55] <LaserJock> hi Fujitsu
[23:34] <_16aR__> Hello
[23:35] <_16aR__> I've got a question about env variables into packages/lib
[23:35] <_16aR__> I'm packaging some lib which needs env var to be set to run ok
[23:35] <_16aR__> but as I read the debian policy, it shouldn't
[23:36] <_16aR__> So I'm wondering what to do : modify the source to add the base path where to search at the end of the GetBlaBlaRootPath() ?
[23:37] <_16aR__> and where must I put the base directory which the env var reference ?
[23:37] <_16aR__> /usr/share/packagename/ ?
[23:38] <geser> _16aR__: what about a wrapper that sets the env variables and starts then the real programm?
[23:38] <T70K5> I try to boot my machine and I get Grub error 17
[23:39] <bobbo> T70K5, #ubuntu for support, this is packaging
[23:39] <T70K5> oh ok, sorry
[23:41] <_16aR__> geser: it is not a program but libraries
[23:42] <_16aR__> geser: I've thought of it, but then I became aware that it wouldn't be useful since I have no executables :p
[23:42] <_16aR__> geser: Or maybe miss I something ?
[23:48] <ScottK> Fujitsu: Since cdm10 didn't pastebin his 'print os.environ' would you please?
[23:48] <Fujitsu> ScottK: Sure.
[23:48] <ScottK> Fujitsu: Thanks.
[23:49] <LaserJock> hi ScottK
[23:49] <ScottK> Hi LaserJock
[23:50] <Fujitsu> ScottK: Want it formatted in any particular way, or just a raw Python representation?
[23:50] <minghua> _16aR__: Which env variable does this library needs exactly?
[23:50] <ScottK> Fujitsu: Raw is fine.  Whatever's easiest
[23:50] <geser> _16aR__: does the env vars have a sensible default value that would be used by all packages using that lib and could be patched in?
[23:50] <minghua> _16aR__: And I can't think of any other way to "use" a library other than linking to it...
[23:52] <Fujitsu> ScottK: Well, it didn't pastebin well, but you can at least see it:
[23:52] <Fujitsu> http://pastebin.ubuntu-nl.org/47478/
[23:52] <ScottK> Fujitsu: Thanks.
[23:54] <ScottK> Fujitsu: I see you've got XAUTHORITY': '/home/william/.Xauthority', so it looks like I have to work around that for KDM.  That's what I needed to see.
[23:58] <Fujitsu> ScottK: Or move everybody to GDM. I'll hide now.
[23:58] <_16aR__> minghua: DELTA_ROOT and DELTA_DATA
[23:58] <_16aR__> minghua: in the same way of the openscenegraph libs uses OSG_ROOT and OSG_DATA
[23:58] <ScottK> Fujitsu: I'd be more likely to remove the code that uses XAUTHORITY.  The program already has to be root, so I think there's little point in the additional check.