[02:17] <anakron> hi all
[02:18] <anakron>  i wanna know what i can do if when i compile with cmake (my first time) appears 'Unknown CMake command "qt4_wrap_ui"
[02:31] <anakron> ping persia
[02:31]  * persia prefers contentful pings
[02:31] <anakron> :) hi
[02:32] <anakron> i have some problems for reproduce a bug of qterm
[02:32] <laga> persia: i'd word that a bit more strongly.
[02:32] <anakron> jeje
[02:33] <persia> laga, Well, I usually just ignore them.  When the third comes in 12 hours, I figure it's worth a note.
[02:39] <persia> anakron, I know almost nothing about qterm.  Also, you may have better luck getting someone to help you reproduce a bug in #ubuntu-bugs.
[02:39] <anakron> mm ok :)
[04:12] <persia> nellery, Just FYI, MC voting is majority, so despite my dissent, you'll likely get added to the group once the remaining council member votes.  Don't worry about waiting for that resolution to proceed with other activities.
[04:17] <nellery> persia: ok.  It's an interesting point to bring up... I'd always considered universe contributors to be generally necessary, and that becoming a member was just an added bonus
[04:17] <nellery> has this ever been brought up in the past?
[04:18] <ScottK> nellery: There have been cases in the past where people tried to make UUC into more than "Member via MOTU Council for MOTU work", but that's really all it is.
[04:19] <persia> It's been brought up several times.  The group exists simply because the CC didn't want to grant MC admin over UbuntuMembers (note that the majority of current MC have that anyway).
[04:20] <persia> Personally, I'd like to see UUC be more, but that means essentially a blanket auto-ACK for any current member wanting to join the team, by simple request.
[04:20] <persia> Since people seem to be processing applications by existing members (no idea why), I'll agree that there's no point to granting special permissions or anything.
[04:21] <persia> In the last CC meeting, there was talk about not further delegating ubuntumembership to additional councils, and redirecting to the RMBs.  Depending on how that conversation proceeds, I may wish to take the position that MC shouldn't be approving members, instead redirecting to the RMBs.
[04:22] <persia> Of course, that probably requires coordination with the other pre-delegated councils (e.g. Kubuntu Council, Edubuntu Council) for coordinated action.
[05:00] <ScottK> persia: FYI, for a Kubuntu member there are PPA's and such that they gain upload rights to, so we've had Ubuntu members who got involved in Kubuntu ask to become Kubuntu members and it's been (reasonably, IMO) done.
[05:00] <ScottK> So it's a little different than UUC.
[05:01] <persia> ScottK, Well, I'd like to see UUC more like that, as a proponent of making UUC special, but in the current incarnation, there's no value to it.
[05:01] <persia> The part about Kubuntu Membership that I was referencing was that Kubuntu members are inherently Ubuntu members.
[05:02] <ScottK> Right, but if we want that, then we need to select for it and we haven't been.
[05:02] <persia> Ignoring the lack of Gubuntu branding.
[05:02] <ScottK> Yes.
[05:02] <persia> Well, all current non-MOTU members of UUC are at least around and doing stuff, but yes, it would need a review.
[05:03] <persia> The team as it exists is poorly defined, in part because it was unexpected, and there's several ways to define it.
[05:03] <persia> With the current model, UUC can't be defined as special without breaking mako's directive that membership-through-development shouldn't be different.
[05:04] <persia> I suspect Kubuntu-member oughtn't be defined as special for the same reason, but that's far too sensitive an area for me to want to poke.
[05:04] <ScottK> Right, Kubuntu membership predates that, so I think it's grandfathered.
[05:04] <persia> Yes, let's call it grandfathered.
[05:04] <persia> As long as KC has a sane procedure for current Ubuntu Members (and I think they do), it should be fine.
[05:05] <ScottK> Seems to me they do.
[05:06] <persia> Still, with RMBs (which didn't exist at the time of UUC creation), and with the growth in the community causing apparent tribal development (as is natural), I'm not sure we wouldn't be better off removing previous membership delegations (including to the MC), and pushing everyone to the RMBs.
[05:07] <persia> Then tribes can develop within that group, but there's a fairly standard basis for all members.
[05:07] <persia> Of course, this requires that RMBs be representative: members from each tribe in each region.
[05:08] <ScottK> If I were an aspiring MOTU I'd find that incredibly demotivating.
[05:08] <persia> How so?
[05:09] <ScottK> Instead of getting recognized within the framework to which I was accustomed, I'd be going to a group of strangers.
[05:10] <persia> Well, the point would be to reduce the perception of them as strangers.
[05:10] <persia> And to have members of one's tribe represent one's suitability to the RMB.
[05:10] <ScottK> Well unless i have an incentive to interact with them before I want to be a member...
[05:10] <ScottK> OK.  What's a tribe in this context?
[05:11] <persia> a tribe is a set of people that consider people outside that context as strangers.
[05:11] <ScottK> OK.  Makes sense.
[05:11] <persia> Classes might include Kubuntu folk, who look to the KC, or MOTU, who look to the MC, etc.
[05:11] <ScottK> So in those terms it'd be having to go outside my tribe for approval.
[05:12] <ScottK> To me that's more intimidating and less comfortable than staying within.
[05:12] <ScottK> ergo, demotivating.
[05:12] <persia> My thought is that it's better for a tribe to bring a prospective member to the RMB for approval, than to have each tribe approve separately, if there is a desire to have a single identity associated with "Ubuntu Member".
[05:12] <persia> So members of one's tribe escort one to the RMB, rather than telling one to proceed alone.
[05:12] <persia> Those with strong tribal affiliations would likely have an easier time than those who don't associate with a given tribe.
[05:13] <ScottK> Right.  We have problems like that here  already.
[05:13] <persia> The LoCos do that fairly agressively now, where endorsements from other LoCo members are present.
[05:14] <persia> Yes, we have lots of those sorts of problems.  We also do fairly poorly at intertribal communication.  There are individuals who participate in several tribes, but that is no longer sufficient.
[05:14] <agent47a> I'm an aspiring MOTU.  Honestly not following the conversation very well. :)  I'm looking for bitesized stuff to do and learn here: https://launchpad.net/ubuntu/+mentoring .  Just wondering if this is the best approach.
[05:14] <persia> agent47a, That's a very good approach.
[05:14] <persia> agent47a, Another thing I found motivating was to look for bugs that annoy me, and hunt them down until they were dead, to make my system work perfectly.
[05:15]  * ScottK too
[05:15] <persia> The former will get you more help, and the latter may be more satisfying.  In either case, if you get stuck, or need help, feel free to ask here, regardless of what other discussions are underway.
[05:15] <agent47a> persia: cool.  thanks!
[05:16] <ScottK> agent47a: https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=bitesize&field.tags_combinator=ANY&field.has_no_package.used= may a
[05:16] <ScottK>  interest.
[05:16] <ScottK> Sorry, but blame the LP devs for that, not me.
[05:17] <persia> ScottK, The issue is that in many languages, it's a small step from "stranger" or "other" to "enemy".  I presume that link is related to something in human psyche, and so would prefer to avoid too much of it, as much as we need to have functional tribes to maintain cohesion with our increasing size.
[05:17] <ScottK> I agree.
[05:18] <ScottK> There is something very fundamental in the human mind that divides people into "us" and "them".
[05:18] <persia> Creating a hierarchy, such that tribes then bring people to the RMBs, rather than having tribes independently approve, helps define the model that we are part of a larger body, regardless of how well we define ourselves within a tribe.
[05:18] <agent47a> i was thinking of trying to package performous: http://www.performous.org .  As my first foray into packaging, is this advisable?  What's the best way to check that I'm not already duplicating an effort?
[05:18] <ScottK> But you don't send the new people out into the jungle to meet with strange tribes.  It should be the experienced people.
[05:19] <bluesmoke> persia: I tried hunting down bugs that annoyed me once, I think I ended up spending a year on a menu editor and 2 years on a window manager :P
[05:19] <persia> That is annoying for KC, MC, etc.  It's also annoying for people joining, but I think it matches the federated city-state better.
[05:19] <bluesmoke> oh...
[05:19] <persia> ScottK, Well, sorta.  You bring the new person with you on a visit, to introduce them around, but along with experienced people.
[05:19] <ScottK> agent47a: Look for a bug tagged needs-packaging about it.
[05:20] <ScottK> Right.  I do that now between Kubuntu and MOTU and Server Team and MOTU.
[05:20] <persia> agent47a, I'd recommend working on bugs first, and developing some preferences for packaging styles, before packaging something from scratch.
[05:20]  * ScottK too
[05:20] <persia> Amaranth, And we've all benefited.  Thank you :)
[05:20] <ScottK> persia: I agree with the goal, I just don't know that that's the best way to achieve it.
[05:20] <agent47a> persia: ic
[05:20] <Amaranth> persia: Just saying, hunting down your personal annoyances can be a big task :P
[05:21] <persia> ScottK, Neither do I.  I've just been reflecting on it since the CC decision not to grant IRCC membership authority on the basis of functional RMBs.
[05:21] <Amaranth> I'll be working on said window manager once I finish some projects I can't do from Ubuntu, btw
[05:21] <ScottK> Well I know people have gotten Kubuntu membership based on IRC support participation.
[05:22] <ScottK> I'm not sure what an IRC membership would be for.
[05:23] <persia> ScottK, Well, presume someone does a lot of channel coordinate and operations work, for say 25 channels (there is an *explosion* in LoCo channels, and IRCOps are thin in some places).  They do this for several months, and expect to do it in the future.  They want an @ubuntu.com for this.
[05:23] <ScottK> OK.  I'll buy that.
[05:24] <ScottK> But I'm going to guess that those channels are related to something.
[05:24] <persia> So, based on this, the IRCC asked the CC for the ability to grant memberships to people who met the criteria (note that there is some IRCC representation in RMBs, so it's not "I want to do that too").
[05:24] <ScottK> IRC doesn't stand alone.
[05:24] <persia> Well, yes.
[05:24] <persia> Alternately, I could imagine the LoCo Council asking for membership grant, which would likely be denied on the same basis.
[05:25] <ScottK> Well LoCo's by definition already have a regional focus.
[05:26] <persia> Yes, but don't assume that the "Regional" in RMB has anything to do with location.  On several occasions the CC has directed people to pick the RMB based on convenient time for the meeting, rather than location.
[05:27] <persia> While I haven't tracked others closely, I know that the AsiaOceania board has seen people from 5 continents.
[05:27] <ScottK> I've seen that.  I've found it odd.
[05:27] <persia> Based on that, I've presumed that it's just poor nomenclature.
[05:29] <ScottK> Of course post archive reorganization, MC might be bringing people toghether from different developer tribes.
[05:30] <persia> Quite possibly.  At least there should be some sane definition of developer tribes which matches reality.
[05:30] <Amaranth> Any idea when we're actually going to get archive reorg?
[05:31] <Amaranth> It's been almost a year since it was an active topic :/
[05:31] <ScottK> I understand we're blocked on LP won't do some stuff it needs to.
[05:31] <ScottK> It's been a discussion point at the last two UDS.
[05:31] <ScottK> it appears to me that things are headed in that direction.
[05:31] <persia> My understanding is that the necessary LP bits are now at least planned.
[05:31] <Amaranth> I was at the one in prague, most exciting/boring session ever :P
[05:32] <persia> The last UDS discussion covered a lot of implementation details.
[05:32] <persia> I expect that the specification will become more clear in the next week or two: I know the spec is approved for jaunty, although it's not entirely clear what that means.
[05:34] <Amaranth> I just want to be able to upload compiz :P
[05:35] <ScottK> Amaranth: Per package upload rights for MOTU are already possible.  You can ask the tech board.
[05:35] <Amaranth> Ooh
[05:35] <Amaranth> First I have to get MOTU again
[05:36] <ScottK> I think they decided not to do it for non-MOTU, but I don't recall for certain.
[05:37] <persia> There's a precedence for the TB to reject an application for per-package uploads by non-MOTU, for packages in main.
[05:37] <ScottK> OK.  That's the one I didn't remember how it was resolved.
[05:38] <persia> I'm not sure that any clear statement was made about per-package uploads for universe by non-MOTU: I think discussions on those lines were routinely pushed into ArchiveReorganisation.
[05:38] <ScottK> Well since he wants Compiz, I think he needs MOTU then.
[05:38] <persia> ScottK, It's not yet entirely resolved: TB needs to rule on the renewed application now that it comes from a MOTU.
[05:39] <persia> Amaranth, For returning MOTU, just send an email to MC saying why you want to be MOTU again, and what you plan to do in the future.  I think these just get approved, although I need to double-check the procedures.
[05:40] <persia> Amaranth, Or, wait a bit, and maybe it won't matter.  Unless you want MOTU for some other reason (and you'd be welcome), I'd suggest at least waiting until the next revision of the ArchiveReorganisation spec.
[05:40] <Amaranth> Honestly all the packages I want to work with have ended up moving to main so...
[05:41] <persia> In that case, you're better off waiting.  Given the timing (February was mooted as a possible date at UDS), being MOTU may not be useful for you.
[05:42] <persia> Of course, if I'm wrong, and it's going to be a long time, then of course, renew your MOTUship, and apply to be a per-package uploader.
[05:47] <Amaranth> I dunno, I suppose there are a couple packages in universe I'd want to work with
[05:47] <Amaranth> and of course new packages have to start in universe
[05:48] <persia> Well, there are certainly a lot of advantages to being MOTU, but there was some reason you gave it up in September, so you'll have to decide.
[05:48] <ScottK> I think I'm going to head off to bed.  Good night all.
[05:48] <persia> Good night ScottK
[05:49] <Amaranth> It'll probably be a month before I'm ready to get back into all this anyway, I suppose I'll check again then
[05:49] <persia> That sounds like the most sane of plans.  If nothing else, there should be an answer to the question "What does ArchiveReorganisation mean?" at that point.
[05:50] <Amaranth> persia: I didn't know it was auto-renew and I wasn't active in Ubuntu at the time
[05:50] <Amaranth> err, self-renew
[05:50] <persia> Oh, in that case, you may as well reapply :)  No point stopping being MOTU by accident.
[06:02] <agent47a> Regarding bug #270984.  What's involved in updating the man system tool?  I tried to get the source via "apt-get source man" but came back empty-handed.
[06:03] <agent47a> i think ubottu answered my question :)  "man-db"
[06:03] <persia> Yep, and ubottu is usually faster than the rest of us :)
[06:20] <binarymutant> when is the deadline for jaunty?
[06:20] <persia> binarymutant, There are several deadlines.  For which action?
[06:21] <binarymutant> to get a package thats not in the repos already ready to be uploaded
[06:21] <persia> FeatureFreeze is 19th February, which is probably the closest, but that's the deadline to have it uploaded, rather than the deadline to get it ready.
[06:23] <binarymutant> if I get the required advocation before Feb 19th could the package be uploaded to the repos?
[06:23] <persia> Most likely.  In fact, if you get the required advocation before then, and your advocate doesn't upload, something is wrong.
[06:23] <binarymutant> very cool, thanks for the info persia
[06:53] <agent47a> I nx'ed into jaunty running freenx 0.7.3 (NX sources 3.3.0) and noticed that the arrow keys do not work as expected.  When pressed while in a textbox or in gnome-terminal, a metacity error pops up.  "No command 33 has been defined"  Anybody else experienced this?
[06:56]  * Hobbsee wonders why that's a question for here, as freenx doesn't seem to be in the repository
[07:05] <persia> agent47a, Does the same happen with intrepid?  It may be a result of work done to change how keycodes are tracked
[07:06] <tritium> 8.10 uses /dev/.static/dev?  http://paste.ubuntu.com/103400/
[07:14] <tritium> Any thoughts as to what's going on there?
[07:21] <persia> tritium, At a guess, there may be some device nodes that need to be present before udev starts, which live in a /dev that gets remounted.  Note that I'm guessing based on vague memories of documentation I read when I switched from devfs to udev some time back.
[07:23] <tritium> persia: was there a significant change between 8.04 and 8.10 regarding how device files are handled?
[07:24] <persia> tritium, Not to my knowledge.
[07:24] <tritium> Those errors puzzle me, as I was able to install and use dvb-utils just fine in 8.04, and xine and VLC could see my DBV card.  Now, neither can see my card.
[07:25] <tritium> DVB, even
[07:25] <tritium> Well, thanks for looking at the paste, persia.
[07:26] <persia> I would have expected that sort of thing with 8.04 as well.  The package ought do better than call makedev, it probably needs migration to also support udev.
[07:27] <tritium> Ah, I'll poke around the postinst, to see what it's doing.  Thanks again, persia.
[07:31] <tritium> persia: yeah, in its postinst script:
[07:31] <tritium> if [ ! -e /dev/.devfsd ] ; then
[07:31] <tritium> cd /dev && /sbin/MAKEDEV dvb
[07:31] <tritium> fi
[07:32] <persia> tritium, Right.  That looks like something that's just never been migrated to udev.  Take a look for it installing udev rules, or dh_installudev|dh_installdev
[07:33] <tritium> I appreciate the help, persia.
[07:33] <persia> No problem.  As long as you're going to fix the bug, I'm happy to help you find it.  Seems the least I can do.
[07:35] <tritium> I will fix it, if I am able.
[08:23] <AnAnt> Hello, is there a way to provide an alternate firefox homepage URL ? There used to be a firefox-homepage alternate in Hardy I think
[11:03] <gouchi> hi
[11:04] <gouchi> the application I try to package is using CodeBlocks to compile
[11:06] <gouchi> must I move the compilation tool to autotools / make ... to comply with debian/ubuntu policies ?
[11:06] <gouchi> or can I keep CB ?
[11:07] <iulian> I would like to backport git-cola from Jaunty to Intrepid and AFAICS from the https://help.ubuntu.com/community/UbuntuBackports for no-source-change backports, MOTUs and core-devs are allowed to upload directly to -backports, however they will need an archive admin approval.
[11:10] <iulian> The package builds and runs fine on Intrepid. Can I upload it to intrepid-backports appending ~intrepid1 to the version and writing something like "Backport to Intrepid; no source changes" to debian/changelog?
[11:11] <persia> gouchi, You can keep codeblocks.  Just change debian/rules to make the appropriate calls.
[11:11] <gouchi> cool
[11:12] <gouchi> thanks for the tips
[11:12] <persia> iulian, Best to file a backports bug, get some backport tester reports, and then push it, in collaboration with the backporters.
[11:12] <persia> !backports
[11:13] <jpds> persia: Can we upload directly? Or do we have to poke an archive admin as usual?
[11:14] <jpds> "Ubuntu Backporters (MOTU and core-dev as of Nov 2008) are allowed to upload directly to -backports".
[11:14] <persia> jpds, For no-source-change backports, it's best to have an archive-admin do it, for all the same reasons we don't upload syncs directly.
[11:15] <iulian> persia: OK, thanks, will do that.
[11:15] <persia> for source-changing backports, it's all the more important to have a backports bug, and tester feedback, of course.
[11:22] <quadrispro> anyone on bug 316033?
[11:27] <tuxmaniac> someone seen nellery around?
[11:31] <persia> tuxmaniac, He was about earlier.
[11:43] <RainCT> asac: What is the /usr/share/mozilla/extensions directory for? Is it used by all Mozilla browsers or what?
[11:43] <asac> no
[11:43] <asac> its a hoax
[11:43] <RainCT> lol
[11:44] <asac> its used by some mozilla-extensions that tried to establish a substandard
[11:44] <asac> e.g. they ship their extensions in that dir and link to the app extensions/ directories
[11:45] <RainCT> asac: Ah, right. How does the mozvoikko extension work then if it has no symlink?
[11:45] <RainCT> (http://packages.ubuntu.com/jaunty/i386/mozvoikko/filelist)
[11:45] <asac> does it work?
[11:45] <RainCT> asac: I don't know. You didn't complain about this on bug #297169, that's why I'm asking
[11:46] <asac> i expect submitters to test stuff
[11:46] <asac> and look at debdiffs only ;)
[11:46] <asac> but could be that it really works
[11:47] <asac> maybe some distro got this added as a legacy location for the extensions
[11:47] <asac> must have been quite late in 3.0 cycle - if so ;)
[11:47] <RainCT> hehe.. yeah, I usually look at such stuff because there were a lot of uploads which changed the dependency and the description to firefox but left the symlink in the iceweasel dir :P
[11:48]  * RainCT checks
[11:48] <asac> right. we should do a thorough reveiew
[11:48] <asac> of extensions
[11:48] <RainCT> (that's also why I wrote the /Merging wiki page, btw :))
[11:48] <asac> feel free to help out ;)
[11:48] <asac> thanks!
[11:50] <asac> RainCT: i think we could at least try to submit the Description stuff to debian
[11:50] <asac> they could name both: Firefox/Iceweasel
[11:50] <asac> and with some care we can make the packaging in such a way that it works at both places
[11:51] <RainCT> uhm.. how can I force a package to install with missing dependencies? (dpkg --force-depends -i ..   doesn't work)
[11:51] <asac> also those debian folks should stop from prefixing stuff with target app name (e.g. iceweasel-superextension)
[11:51] <RainCT> asac: +1
[11:52] <asac> i never understood this. frequently extensions work not only on iceweasel but on seamonkey too ... they then default to "mozilla-" prefix; which doesnt make sense as its not usable in tbird, xulrunner or other mozillas
[11:54] <persia> RainCT, --force-depends is specicifically designed to permit it: note that if something uses a dependency in a maintainer script, that causes other issues.
[11:55] <RainCT> persia: oh, right. it complains but then it configures it, hadn't seen the last line :). thanks
[11:55] <persia> Right.  Just converts dependency errors into warnings.
[11:58] <RainCT> asac: "Mozilla-laajennus Voikon käyttöön" - if that's the extension, then it works
[11:59] <RainCT> although I don't see why they want a spell checker extension instead of just using the inbuild spell-checker..
[11:59] <asac> thx
[12:00] <asac> i think ... i think that this one uses a more enhanced thing than hunspell
[12:00] <asac> i had a bug open asking for using that by default
[12:00] <asac> but we cant unless its something better everywhere and upstream adopts it
[12:00] <asac> RainCT: ^^
[12:04] <iulian> persia: I just noticed that you forgot to mention mok0's feedback when you sent the mail to MC and TB (https://lists.ubuntu.com/archives/motu-council/2008-December/001889.html).
[12:04] <iulian> It doesn't matter now :)
[12:06] <persia> iulian, OOps.  Sorry.  I did read that, and consider it.
[12:06] <persia> Probably just me trying to do it when I really should have been asleep, but I didn't want to make you wait another day.
[12:08] <iulian> There is no problem.  I was too excited when I got that mail and didn't notice that mok0's feedback is missing.
[12:08] <iulian> Yeah, I appreciate that.
[12:09] <persia> Really?  I'd think the LP group notification mail would be more exciting, or at least it was for me.
[12:09] <persia> Did you put up your wiki page yet?
[12:09] <persia> Do try to get it up before UWN goes out, as you will be listed, and it's better if it can be a link.
[12:10] <iulian> persia: I was at school then and IIRC I saw the LP group notification mail.
[12:11] <persia> Ah, that makes sense.  The notification mail is a bit more public :
[12:11] <iulian> persia: Oh, honestly I forgot about the wiki page. I will do that today or tomorrow.
[12:12] <persia> You might check with the News team to find out when they publish, to get a deadline.
[12:13] <iulian> persia: Do they have an IRC channel?
[12:13] <persia> #ubuntu-news
[12:14] <persia> Dunno if they're online now though.
[12:15] <RainCT>  
[12:15] <persia> RainCT, Now try that with a unicode non-printing space :p
[12:16] <RainCT> uoops
[12:17] <RainCT> wow, persia joking \o/
[12:18] <iulian> OK. I'm writing something on the wiki now.
[12:18] <StevenK> Haha. persia does joke ...
[12:18] <RainCT> that must have been the holidays.. P
[12:18] <sebner> yeah, persia joking \o/
[12:18] <iulian> Yay.
[12:18] <StevenK> Obviously, neither of you were at UDS ...
[12:19] <persia> There's some correlation to time-since-last-idle-for-significant-time.
[12:33] <pmjdebruijn> lo
[12:33] <pmjdebruijn> what currently the preferred way to patching packages?
[12:34] <pmjdebruijn> In the past I've read about several different ways to patch packages... I'm wondering whether a single method is preferred above others...
[12:35] <RainCT> pmjdebruijn: if the package comes from Debian, use whatever it is already using
[12:35] <pmjdebruijn> RainCT: it's a new package
[12:35] <pmjdebruijn> so I'd need to modify debian/rules
[12:35] <pmjdebruijn> that's why I'm asking
[12:36] <RainCT> well, then you can choose
[12:37] <pmjdebruijn> no method is preferred?
[12:37] <RainCT> Not afaik. The most popular ones are simple-patchsys (for cdbs), dpatch and *urgh*quilt*urgh*, though
[12:38] <azeem> urgh?
[12:39] <Laney> s/urgh/love/g
[12:39] <RainCT> Laney: rather the opposite :P
[12:40] <RainCT> although, now that I've had to touch it 2 or 3 times I'm starting to see that it may even be not that bad :P
[12:41] <proppy> hi
[12:41] <RainCT> hi proppy
[12:41] <persia> pmjdebruijn, Also, if you're managing your package in a VCS, you may not want to use a patch system at all.
[12:41] <pmjdebruijn> huh?
[12:42] <pmjdebruijn> my package isn't in vcs
[12:42] <pmjdebruijn> but I thought that was frowned upon
[12:42] <pmjdebruijn> directly patching
[12:42] <pmjdebruijn> RainCT: http://matrixhasu.altervista.org/index.php?view=use_dpatch I've used that in the past... would that be okay?
[12:43] <RainCT> pmjdebruijn: if you are not using cdbs, yes
[12:44] <RainCT> btw, does anyone know what the rationale for simple-patchsys was?
[12:44] <laga> it's simple?
[12:46] <RainCT> laga: it's exactly the same as dpatch (using cdbs), just without the 00list, which I've come to see as something really useful (considering that diffs can't handle file renames)
[12:46] <laga> RainCT: it doesn't need the patch header either AFAIK
[12:47] <azeem> RainCT: dpatch can (in theory) run arbitrary code during patching, as it executes the patches as shell scripts
[12:47] <azeem> at least that was the case in the past
[12:48] <RainCT> Oh. So why not just fix dpatch?
[12:48] <azeem> fix how?
[12:48] <laga> redesign it and call it simple-patchsys?
[12:49] <RainCT> redesigning it and calling it dpatch2 :P
[12:49] <azeem> s/simple-patchsys/quilt/
[12:49] <RainCT> anyway, I should go work on my research project..
[12:50] <azeem> yeah, it's Sunday after all :P
[14:17] <iulian> persia: I've written something on the wiki page. It's not complete anyway. Honestly, I don't like writing about me. ;)
[14:17] <iulian> Hope it's good for now.
[14:27] <persia> iulian, Anything is fine :)  You did a nice job introducing yourself and your work in both your applications, so I figured the wiki page would be easy.
[14:29] <slytherin> does anyone know when is slomo expected to be hear. I was planning to sync/merge libdvdread and libdvdnav from experimental and thought that I should first get his opinion.
[14:30] <slytherin> s/hear/here
[14:31] <iulian> persia: Excellent.
[15:30] <bersace> Hi everyone
[16:17] <iulian> Hmm, why doesn't dupload send announcements when uploading to ubuntu, even though I've removed "dinstall_run => 1" from the configuration file.
[16:18] <azeem> iulian: cause ubuntu doesn't use dinstall
[16:18] <azeem> iulian: where do you expect announcements to go?
[16:21] <iulian> Ah, right, didn't know that.
[16:22] <iulian> I thought it uses like Debian.
[16:23] <azeem> I don't think this does anything in debian either
[16:24] <iulian> Isn't that when you get an ACCEPTED/REJECTED e-mail?
[16:24] <azeem> iulian: no, you get them always
[16:25] <azeem> I think dinstall_run is some 90s thing about mailing debian-devel-changes or another obscure list with your .changes
[16:25] <azeem> or something
[16:25] <azeem> obsolete nowadays
[16:31] <iulian> azeem: Ubuntu's format changed a little bit regarding the notification email. I was confused because from Debian I get an email with the name of the files uploaded.
[16:31] <iulian> Even though I'm not really sure about this.
[16:32] <azeem> Debian and Ubuntu use completely different archiving software
[16:32] <iulian> Indeed.
[16:33] <fabrice_sp> Hi, Dvdstyler package (http://revu.ubuntuwire.com/details.py?package=dvdstyler) has had his first advocate. Can someone else review it? Thanks.
[16:36] <Laney> I seem to remember a way of getting debuild to list files that are installed by upstream's install rules but don't make it  into any .deb. Anyone know what this is?
[16:37] <azeem> Laney: dh_install --list-missing
[16:37] <persia> I think it's dh_install --list-missing
[16:37] <Laney> I thought I could turn it on as a default?
[16:38] <Laney> but this is good for what I need right now, thanks
[16:42] <Laney> fakeroot debian/rules list-missing, nice
[17:11] <savvas0> can someone upgrade the jaunty linuxlogo from 5.04-1 to 5.04-2 (debian unstable)? They fixed a bug about it: https://bugs.launchpad.net/ubuntu/+source/linuxlogo/+bug/291958
[17:14] <fabrice_sp> savvas0, just open a syn request bug
[17:15] <savvas0> fabrice_sp: can I rename the bug report subject instead?
[17:20]  * Laney smacks RainCT 
[17:20] <Laney> pbuilder-dist bug
[17:20] <Laney> missing " on line 219
[17:21] <ScottK> savvas0: You can.
[17:21] <fabrice_sp> saivann, I don't know if it's politically correct, but I would say, yes. Let's wait for a MOTU to answer
[17:21] <fabrice_sp> (ScottK did :-) )
[17:22] <savvas0> oki doki
[17:23] <ScottK> It's pointless to make a new bug that then someone has to go back and remember to clost this one manually.
[17:23] <jpds> Laney: Fix pushed.
[17:24] <Laney> jpds: nice work
[17:26] <Laney> jpds: Er, you needed to add a quote, not remove the other one
[17:26] <jpds> Laney: Why? "arguments.append('--components %s' % components)"
[17:26] <Laney> because the components are one argument
[17:27] <Laney> e.g. --components "main restricted universe multiverse" vs --components main restricted universe multiverse
[17:27] <RainCT> jpds: there are more than 1 component, so a quote was missing
[17:27] <jpds> RainCT: Ah right.
[17:28] <slytherin> do we prefer the new machine readable copyright format for new packages?
[17:28] <persia> slytherin, Yes.
[17:28] <persia> Be nice if it was finalised, or approved or something though.
[17:28] <RainCT> is there already some application to validate copyright files or not yet?
[17:29] <Laney> I don't think so as there's no valid format yet
[17:29] <Laney> s/valid/stable/
[17:30] <RainCT> fabrice_sp: ah, I'm not sure if that's what you were talking about, but yes, you can not only change the title of bugs, but if that's to improve them you are encouraged to do so
[17:31] <jpds> Laney: That should do it :)
[17:31] <RainCT> (well, and if it's not to improve them I'll hit you if you change them :P)
[17:31] <fabrice_sp> lol
[17:31] <RainCT> jpds: you also like --overwrite? ;P
[17:31] <fabrice_sp> in this case, it was to transform a normal bug en sync request
[17:32] <RainCT> fabrice_sp: yes, that's fine
[17:32] <slytherin> persia: is the format even in RC state or something?
[17:33] <Laney> heh, bzr didn't like that --overwrite
[17:33] <persia> Dunno.  I've seen a few packages go through with the draft, and nobody seems to object.
[17:33]  * Laney had to merge
[17:33] <slytherin> hmm
[17:34] <RainCT> persia: well, it contains all the requires information, so there's no reason why someone could object to it
[17:34] <slytherin> by the way, does anyone know why cheese is in universe? it was in main in hardy and IIRC, it is included by default in netbook-remix
[17:34] <fabrice_sp> RainCT: and in this case, you just add a comment with the sync request or you change the description (and loose the bug)?
[17:35] <RainCT> slytherin: just guessing, but perhaps there's a better application now? (cheese has a rather bad performance imho)
[17:35] <RainCT> fabrice_sp: you can add the sync info at the top of the description
[17:36] <slytherin> RainCT: I am not even aware of any other application of that sort. And if cheese had bad performance then it should have not been in main in first place.
[17:36] <fabrice_sp> ok Thanks to clarify that!
[17:36] <slytherin> RainCT: could you please grant me motu powers on revu? I don't see any link to advocate a package.
[17:38] <RainCT> slytherin: and you haven't noticed until now?   *evil REVU Coordinator look*
[17:39] <slytherin> RainCT: because I didn't look into any package till the point of advocacy.
[17:40] <RainCT> slytherin: ah well, if that's the case then I can forgive you :P
[17:40] <RainCT> ok, done
[17:41] <slytherin> RainCT: thanks
[17:43] <RainCT> np
[17:44] <RainCT> ohh.. mok0 is about to catch me in the "top commenters"
[17:44] <slytherin> if a motu is doing a new package, ideally it should still go to revu, right?
[17:45] <RainCT> slytherin: yes, that's encouraged
[17:45] <Laney> it still needs to get one +1
[17:45] <RainCT> (s/needs/should, but yes)
[17:46] <Laney> right
[17:46] <ScottK> slytherin: I've always gotten reviews and never regretted it.
[17:46] <slytherin> :-)
[17:48] <RainCT> slytherin: Wait, I change my comment. Packages should not get through REVU
[17:48] <RainCT> slytherin: they should get through mentors.debian.net ;)
[17:49] <persia> Depends on the package really.  For something advantageous to Debian, yes, but for things naturally Ubuntu-only, not so much.
[17:49] <slytherin> Well, that means it will be probably jaunty +2 before it lands in Ubuntu. :-P
[17:49] <persia> Even so, pushing to REVU before mentors isn't bad.
[17:49] <RainCT> slytherin: not necessarily, I usualy get fast reviews
[17:50] <RainCT> and even more if I get the package in through some team (python, games or whatever)
[17:50] <slytherin> RainCT: java team is really moving slow with regards to sponsorship these days.
[17:51] <persia> slytherin, if you get a delay in your sponsorship, and you're getting close to Feature Freeze, feel free to push to Ubuntu.  Just be sure to make the tar.gz the same.
[17:51]  * RainCT images himself reviewing a package from ScottK and feels strange :P
[17:52]  * ScottK makes plenty of stupid mistakes in his packages.
[17:52] <slytherin> persia: Well, I didn't submit for sponsorship as I don't have any hope. I will make it for Ubuntu first and then as I get time put into sponsorship inDebian.
[17:53] <persia> RainCT, The first time I reviewed a package by a MOTU, I was surprised at how many things I caught.  Just little stuff, but we all make mistakes.
[17:54] <RainCT> hehe yes, but nevertheless it's somehow funny/weird (especially reviewing stuff from people who sponsored you before)
[17:54] <persia> slytherin, Just put a copy on mentors.debian.net, update the ITP, and make a request.  It might not happen soon, but it might happen sooner if you request sooner :)
[17:54] <persia> RainCT, I know what you mean.  Mine was in fact one of my sponsors :)
[17:55] <ScottK> These twists do get odd.
[17:55] <RainCT> persia: btw, out of curiosity, how long have you been around?
[17:56] <ScottK> I've sponsored uploads into Ubuntu for my Debian NM application manager.
[17:56] <RainCT> XD
[17:59] <persia> RainCT, I've been a user since Warty, started submitting patches in Breezy, and became MOTU in Gutsy.
[18:00] <nhandler> persia: I didn't realize that you had just become a MOTU at the time you were mentoring me ;)
[18:01] <RainCT> persia: errr.. really? \o/
[18:02] <RainCT> ah, but before gutsy's release
[18:02] <RainCT> so you became a MOTU and like 1 month later I started contributing
[18:02] <persia> RainCT, About that, yes.
[18:03] <persia> nhandler, Yes.
[18:03]  * slytherin pats himself on the back for sponsoring a package.
[18:05] <RainCT> and I though big master persia would have been there for ages.. :P
[18:06] <nhandler> persia: When did you get on the council?
[18:07] <persia> nhandler, 11 months ago.
[18:42] <sooth> What is the name of the utility that quickly creates a package. You wrap the install command with it.
[18:42] <sooth> ?
[18:42] <jpds> sooth: checkinstall?
[18:42] <ScottK> dh_make
[18:42] <persia> jpds, Please, no.
[18:43] <jpds> persia: Just checking.
[18:43] <directhex> persia, that's pretty obviously what sooth wanted, though
[18:43] <directhex> system killer though it may be
[18:44] <sooth> jpds: Yes, thanks.
[18:44] <slytherin> directhex: is there any status page about mono2 transition?
[18:45] <directhex> slytherin, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO ?
[18:45] <sooth> Is there something else I should be using. It is for a python egg.
[18:45] <sooth> Is there something else I should be using? It is for a python egg.
[18:46] <POX> sooth: stdeb
[18:47] <klasikahl> howdy... i've got some questions/issues with the -virtual kern tree.  i am curious if anyone here would be able to answer my questions
[18:47] <slytherin> sooth: it depends on what you want to do with the package.
[18:48] <sooth> POX: Thanks. (Ironically, it is not packaged)
[18:48] <sooth> slytherin: Personal use.
[18:48] <slytherin> sooth: then please go ahead with checkinstall.
[18:48] <sooth> slytherin: Okay, thanks.
[18:49] <POX> sooth: what module do you need?
[18:49] <POX> pygments?
[18:50] <slytherin> persia: if you see doko around then can you please remind him to look into (if he has not already looked) why java stack is broken on hppa.
[18:51] <sooth> POX: Something called pisa. http://www.htmltopdf.org/
[18:53] <directhex> slytherin, you don't have super u-u-s powers do you?
[18:54] <slytherin> directhex: I am not in team yet. Why?
[18:54] <slytherin> directhex: but that doesn't prohibit me from sponsoring a package.
[18:54] <directhex> slytherin, my ikvm sync request. t'was a challenge, but it's finally in experimental
[18:55] <directhex> slytherin, with super openjdk powers
[18:55] <coppro> uus is a sigma particle :P
[18:55] <directhex> ooh, sebner could do it. /me pats sebner
[18:55] <slytherin> directhex: you are a motu, right?
[18:56] <persia> slytherin, I'm rather tempted to wait for lamont's investigation as to whether we need to support hppa at all :)
[18:56] <directhex> nay
[18:56] <directhex> just a contributor
[18:56] <slytherin> persia: hmm.
[18:57] <slytherin> directhex: I will only check that it builds. Rest I believe debian uploaders must have already checked. is that fine?
[18:57] <directhex> hm, no, sebner's leaving us to shoot windows users
[18:57] <directhex> slytherin, i only ever tested in jaunty during development, so frankly i'm impressed that it built on experimental
[18:58] <sebner> directhex: I can at least do a testbuild but nothing more
[18:58] <directhex> slytherin, i did a test build earlier, but feel free. hope you have gobs o' ram
[18:58] <directhex> -rw-r--r-- 1 jms jms 13M 2009-01-11 14:48 /var/cache/pbuilder/jaunty-amd64/result/ikvm_0.38.0.2+dfsg-1_all.deb
[18:58] <directhex> -rw-r--r-- 1 jms jms 16K 2009-01-11 14:41 /var/cache/pbuilder/jaunty-amd64/result/libikvm-native_0.38.0.2+dfsg-1_amd64.deb
[18:59] <slytherin> directhex: I have 1.2 GB of RAM on a powerpc 1.3 GHz G4. Is that good enough for build?
[18:59] <directhex> slytherin, can you build openjdk on that?
[18:59] <slytherin> directhex: never tried.
[19:00] <directhex> slytherin, javac is called with -Xmx1536M during build, so...
[19:01] <slytherin> directhex: ahh, you told me. sorry can't help there.
[19:01] <directhex> slytherin, when i started adopting this package, i thought there was a memory leak..... the only leak is called "javac"
[19:05] <slytherin> what command does dch use to invoke editor? In my case it is always opening vi basic which does not have syntax highlighting.
[19:07] <sooth> slytherin: VISUAL, EDITOR env variablese
[19:07] <sooth> variables
[19:07] <slytherin> sooth: I don't have any of those set.
[19:08] <sooth> slytherin: Set them?
[19:09] <nhandler> slytherin: Just put them in your .bashrc
[19:09] <persia> slytherin, I suspect it uses sensibleeditor if the environment variables are unset.
[19:09] <sooth> persia: That's what the man page says.
[19:10] <nhandler> But setting EDITOR and VISUAL is still a good idea. Many tools use those variables
[19:10] <sooth> But sensible-editor checks those env variables doesn't it.
[19:10] <sooth> ?
[19:10] <slytherin> persia: right. and it is a binary not an alternative option.
[19:11] <sooth> slytherin: There is select-editor
[19:11] <sooth> Which is overridden by VISUAL and EDITOR.
[19:12] <slytherin> I will set those variables
[19:16] <fabrice_sp> I have a question about backports: what is the point of backporting a package in -backport if it has been backported in a ppa?
[19:18] <slytherin> fabrice_sp: not everyone wants to use ppa. the packages in ppa are not signed and there is no gurantee that they even had minimal QA that a backport package had.
[19:18] <RainCT> slytherin: unsigned is not necessarily true
[19:19] <oojah> And backports is a lot more official looking than random-ppa.
[19:19] <fabrice_sp> I backported hugin 0.7.1 (jaunty) to Hardy and Intrepid in my ppa, and closed a lot of bug report because of that (the reportees tested the ppa's version)
[19:19] <slytherin> RainCT: how do you sign packages in PPA?
[19:19] <RainCT> slytherin: PPAs are now signed, but LP is still catching up with signing all existing ones
[19:19] <fabrice_sp> so, I should open a backport request, then?
[19:19] <RainCT> slytherin: this was announced not much time ago
[19:19] <slytherin> fabrice_sp: closing bugs against package in your ppa is very wrong.
[19:20] <slytherin> RainCT: I must have missed.
[19:20] <fabrice_sp> I closed them because the jaunty version fixed the problem
[19:20] <fabrice_sp> not my ppa one
[19:21] <slytherin> then, that is fine
[19:22] <slytherin> depending on severity of bugs, it should either be an SRU or a backport
[19:23] <maxb> PPAs aren't signed *yet*
[19:23] <fabrice_sp> There is a way to bypass the problem, so it's not really a SRU, but it's a must have, so it will be a backport. Anyway, it's difficult to have a new version as a SRU
[19:25] <maxb> last I heard from the people on #launchpad, signed PPAs are blocked on additional hardware being installed to run the mass key-generation on
[19:26] <oojah> https://launchpad.net/soyuz/+bug/125103 <- cprov says "signed ppas should happeen next week" or "the infrastructure for signing keys should happen next week" depending on how you read it.
[19:28] <slytherin> fabrice_sp: you can backport the fix in an SRU. No need for whole new version.
[19:32] <fabrice_sp> slytherin, the hardy version is 0.7~beta4 and the jaunty one, 0.7.1, so it's very difficult to find the fix for the more than 6 problems I closed with that version
[19:34] <slytherin> fabrice_sp: contact upstream :-)
[19:35] <fabrice_sp> :-) I think upstream will tell me to install the latest version (beta 4 wasn't the last beta, so not sure about the answer).
[20:15] <sooth> packages.ubuntu.com lists python-reportlab as having version 2.2 but I cannot seem to get it from the jaunty repositories after adding it to my sources.list and doing apt-get source python-reportlab. Can anyone else see it?
[20:16] <sooth> Ah never mind. My mistake with apt-pinning.
[20:16] <nhandler> sooth: Try using pull-lp-source from ubuntu-dev-tools if you are only interested in the source
[20:17] <sooth> nhandler: Does that retrieve the dev version from bzr?
[20:19] <sooth> nhandler: Thanks, that tool will save make my life easier in the future.
[20:27] <nhandler> sooth: It doesn't work with bzr, but you can specify what Ubuntu version it should use (default=jaunty)
[21:20] <binarymutant> if my python package is not compatible with python3 should I change the dependency requirement from  >=2.3 ?
[21:21] <ScottK> binarymutant: If you use python-support or python-central to build your package, they'll handle that for you.
[21:21] <binarymutant> thats cool thanks :)
[21:21] <ScottK> They should build packages that depend python <<2.6.
[21:22] <binarymutant> thanks for the help
[21:22] <ScottK> No problem.
[23:08] <james_w> Debian bug 511530
[23:10] <directhex> o_o
[23:12] <RAOF> I'm all for it
[23:12] <jorgenpt> haha
[23:12] <jorgenpt> mmpong ftw
[23:13] <directhex> free software developers in "failing to see what makes games fun" shocker o_o
[23:15] <jorgenpt> ;-)
[23:44] <lifeless> wow, mmpong - did you read the details