[00:00] <james_w> I have no objection to that, and I will happily add my concern as the first bit of feedback if that doesn't convince you to weaken your argument :-)
[00:00] <persia> Oh.  I don't think that this process solves the problem of not having stuff stored in a useful location.
[00:01]  * Hobbsee wonders where this wiki page is?
[00:01] <persia> https://wiki.ubuntu.com/UbuntuDevelopment/News
[00:02] <persia> james_w, I took Edgy mostly off (well, X wouldn't start for about 3 months).  When I came back, things were a little different.
[00:02] <james_w> well, I wasn't going that far, just that it makes it harder for just any developer to send the mail to -devel-annouce. The wiki page means that even if those who initially agree to shepherd the process disappear there is nothing lost
[00:02] <persia> Having a list of news-type postings wouldn't have helped me much.
[00:03] <Hobbsee> ah, thanks
[00:03] <persia> lists.ubuntu.com has full archives of all submissions to the news team.
[00:03] <james_w> persia: hopefully that will be one thing we can discuss at Hobbsee's UDS session, or at least during UDS.
[00:04] <james_w> persia: any objection to me adding a note that no-one has actually asked the news team yet?
[00:04] <persia> james_w, That works for me.
[00:04] <persia> No.
[00:05] <Hobbsee> james_w: indeed.
[00:05] <persia> james_w, So you're thinking intro in the next MOTU meeting, chatting at UDS, and decision in the following MOTU meeting?
[00:05] <ogra> Hobbsee's UDS session ? we're discussing Hobbsee ?
[00:05] <ogra> where can i subscribe ?
[00:06] <Hobbsee> ogra: yes, clearly we're discussing how much I suck.  i'm sure certain flamers will be delighted to attend...
[00:06] <james_w> persia: well, that feels heavyweight for me. I don't feel we need a MOTU decision about this.
[00:06] <ogra> oh, i thought we can dress you up in funny ways ... :) "wear these shoes with that hat i just found online"
[00:07] <Hobbsee> ogra: oh dear...
[00:07] <james_w> persia: If you wish to ask for one that is fine
[00:07] <persia> james_w, That wiki page says "Will be introduced at the 28th November MOTU Meeting".  I didn't add that part.
[00:07] <Hobbsee> ogra: https://blueprints.edge.launchpad.net/ubuntu/+spec/retaining-ubuntu-developers
[00:08] <persia> Personally, I think it's nice to discuss things at MOTU Meetings.
[00:08] <james_w> my proposal to the lists was going to be that if there was no clear consensus on  on the wiki page soon then I would just ask for volunteers to go the news-team route
[00:08] <ogra> Hobbsee, subscribed
[00:08] <Hobbsee> ogra: oh dear ;)
[00:08] <ogra> :)
[00:08] <james_w> the MOTU meeting just gave a nice milestone at which to make that call.
[00:08]  * Hobbsee is apparently going to get the entire development team subscribed to this.
[00:08] <Hobbsee> perhaps i'm just going to get lynchmobbed at the end?
[00:08] <james_w> we can add it to the agenda if it is desired
[00:09] <TheMuso> persia: Since you will be offline for a while, what is your position re your merges? Do you want them taken care of?
[00:09] <persia> james_w, OK, although we've had a lot of fairly dead-end ML discussions recently.  I'd like to get back to the relatively quicker route of using MOTU Meetings to quick review/approve/proceed with basic stuff
[00:10] <james_w> persia: yeah, I was trying to avoid a long ML discussion, by having a short non-ML discussion and calling your proposal the winner if we didn't get anywhere
[00:10] <persia> TheMuso, I should only have lash (which is annoying tarball-in-tarball) and matchbox-window-manager (which stefanlsd already did) outstanding.  freqtweak still shouldn't be merged, unless someone wants pain.  There's a couple useful bits in debian, but no code patches.
[00:11] <james_w> matchbox is uploaded
[00:11] <persia> TheMuso, If I get new ones, and someone grabs them, I won't complain (this is a standing policy: excepting freqtweak, I don't really care if people upload stuff I uploaded last, and freqtweak is mostly special because the Debian tarball is so ugly, and it's orphaned, and nobody has made any useful improvements.
[00:12] <persia> james_w, Ah.  I was waiting to look at the BTS entry, but thank you.
[00:12] <TheMuso> persia: Ok fair enough.
[00:14] <persia> And I won't actually cause the pain to anyone merging freqtweak: they just get to try to track down the very different ways Bart and I chose to work with dead upstream, and figure how just how many of my patches Bart finally applied, or whether some bits are missing.
[00:14]  * persia should really try to adopt it again: it's been long enough that maybe it won't get blocked this time
[00:25] <james_w> persia: thanks for your help
[00:25] <JonReagan> yeeehaaaw!  the upload worked, and the lintian issue I had earlier has been resolved!
[00:26] <JonReagan> now all that's left as far as issues are concerned is my changelog... apparently something is "missing or invalid"
[00:26] <persia> Did you use dch --create to create your changelog?
[00:26] <JonReagan> oh, when was I supposed to do that?
[00:27] <persia> That's the preferred way to construct debian/changelog
[00:27] <JonReagan> it has a changelog included in debian/
[00:28] <persia> stefanlsd, bug 506352 looks perfect.  Well described and well tagged.  Thank you very much.
[00:28] <persia> JonReagan, Right, but you got a complaint that it's missing or invalid.  I'm guessing there's something funny with that changelog.
[00:28] <james_w> Hobbsee: still around?
[00:28] <Hobbsee> james_w: yes
[00:28] <james_w> Hobbsee: on to point 2 in your brainstorm.txt :-)
[00:29] <JonReagan> ah, k, thanks... I remember seeing a page for the changelog on the wiki.  I'll give that a look
[00:29] <Hobbsee> JonReagan: hurrah!
[00:29] <Hobbsee> james_w: woot :)
[00:29] <james_w> Hobbsee: "- Wiki documentation!" <- what do you mean by that?
[00:31] <Hobbsee> james_w: kinda the news stuff that was being discussed earlier, and a bit that I mentioned yesterday about the triaging with jono
[00:31] <Hobbsee> james_w: we need a good way of saying 'Here's the latest information you need to know, in digest form'
[00:32] <james_w> by digest do you mean like a diff from when you last knew everything?
[00:32] <Hobbsee> james_w: most of hte discussions happen after long threads on the mailing list, and don't get put somewhere where someone can take 10 minutes to read and think on what's been decided, and remember it
[00:32] <Hobbsee> james_w: maybe it should be something like "major decisions / changes made in <release>"
[00:32] <Hobbsee> and just keep updating the wiki page
[00:32] <james_w> hmm, I'm having trouble seeing how that is different from the news stuff
[00:32] <Hobbsee> we don't actually have that many, iirc - but stuff like the maintainer field change, which has changed again.
[00:33] <Hobbsee> i don't think it is, as such, except that I thought you were sending out the news in chunks, whereas what I was thinking was one page that routinely gets updated after every major decision.  I think one would be taken from the other and sent out :)
[00:33] <james_w> for that one you just get it pointed out the first time you get it wrong :-)
[00:33] <Hobbsee> (i think they're both needed)
[00:33] <Hobbsee> well...
[00:34]  * Hobbsee wonders if you can rss-ize wiki pages.
[00:34] <james_w> that was my proposal for how the news would work
[00:34] <Hobbsee> right, yes
[00:34] <james_w> you can subscribe by mail on moin
[00:34] <Hobbsee> it was a rather unedited brain-dump.
[00:34] <james_w> . o 0 (email2rss?)
[00:34] <persia> james_w, The issue is that the news thing serves a slightly different purpose.
[00:34] <Hobbsee> but i do think it's important to have a listing where one does *not* have to chain thru bits of mailing list archives to read them, too
[00:35] <persia> james_w, The "Today's best practices" document is more useful, especially if it's fed to everyone every cycle, and required to be updated for major decisions.
[00:35] <Hobbsee> content-wise, one would definetly be a subset of the other - in fact, the wiki'd version would probably be an amalgamation of all the posts that had been sent out
[00:35] <james_w> persia: perhaps we have a different idea of what the news thing would be then
[00:35] <persia> It's not so much news, as a quick explanation of current practices and pointers to current Docs.
[00:35] <persia> We maintained one up to Breezy or so, but then lost track.
[00:36] <james_w> persia: ah, I haven't seen that, does it still exist?
[00:36] <Hobbsee> that's a point. i'd not realised that was persia's definition either :)
[00:36] <james_w> I'm having trouble seeing how it is different to the wiki though
[00:36] <persia> What?
[00:36] <Hobbsee> james_w: in my proposal?
[00:36] <persia> I think the news thing is interesting from a news perspective.  I'd like to see news.
[00:37] <persia> I just don't think news solves the issue of maintaining a useful wiki page of knowledge or practices.
[00:37] <james_w> erm, sorry, typing too quickly
[00:37] <james_w> does the Breezy "best practices" document still exist somewhere, I would be interested in reading it.
[00:37] <persia> My disagreement about new implementation is fairly minor, and only about the implementation.
[00:37] <persia> I'm looking for it.
[00:38] <james_w> thanks
[00:38] <james_w> my other point was that the "current" state stuff is just the wiki documentation isn't it?
[00:38] <Hobbsee> current state stuff?
[00:38] <persia> Well, yes, but it would be nice to have a summary bullet page.
[00:39] <Hobbsee> james_w: btw, if you're taking notes of this discussion, along with annotations, i'd apprecaite them sent to me, etc.
[00:39] <james_w> while there may be valid concerns about it being incomplete or hard to navigate that would be different to being something that would be missing
[00:39] <Hobbsee> james_w: i'm not sure I'll be able to run such a high profile session completely on my own :P
[00:39] <persia> Mind you, the wiki in general needs help, and many of the recent semi-incomplete revamps haven't helped (and I share responsibility for at least two of them)
[00:40] <james_w> I'm trying to grasp if there is something missing, or it is just insufficient effort in maintaining the wiki.
[00:40] <persia> james_w, The part that's oft considered "missing" is the "Well, I've been away for a while: how do I get started again" page.
[00:41] <james_w> and I'm also having trouble envisioning what would be on the "summary bullet page" as opposed to a general wiki documentation index.
[00:42] <Hobbsee> persia++
[00:42] <james_w> persia: in what ways does a list of the decisions taken and new tools, processes, and best practices not provide that?
[00:43] <james_w> (damn, just noticed a thinko in my mail)
[00:44] <persia> james_w, It's a TLDR thing.
[00:44] <persia> james_w, You're entirely correct, but the trick is to make it look trivially easy, rather than wading through history.
[00:44] <Hobbsee> persia: TLDR?
[00:44] <persia> I'm also very much not convinced that some things would make that news, as they happen gradually enough nobody notices unless they've been away for a while.
[00:45] <persia> Hobbsee, Too-Long-Didn't-Read.
[00:45] <Hobbsee> persia: oh :)
[00:45]  * persia almost never suffers from that problem, but knows that many do, and avoiding it is key to making something that looks useful
[00:45] <james_w> hmm, a way for someone to catch up on all changes in a certain time frame without at least looking over a list of the changes within that timeframe? neat.
[00:46] <persia> james_w, Right.  It's a bit of a snark
[00:46] <persia> james_w, The two easy solutions are 1) don't change anything (people change, not gonna happen)
[00:46] <directhex> i think it's meant to be written "tl;dr"
[00:47] <james_w> some things not making it is a valid concern though. I'm not sure any process will easily capture things happening too slowly to notice.
[00:47] <persia> 2) Create a semi-accurate short summary document "Jaunty Development is different than Intrepid Development in these four ways".
[00:47] <persia> That's clearly incomplete, but satisfies the desire for understanding.
[00:47] <persia> james_w, And no, it's not a substitute for the wiki being dredged properly.
[00:47] <james_w> persia: I agree with your two points. That is one role that I see the news things filling.
[00:48] <persia> And to me, it's completely separate from news.  I'd like to hear more about what people are planning and doing, but that's not process and the like.
[00:49] <james_w> Intrepid was released on this date, here is a list of things that happened since that date, each a title and one paragraph with links for more information seems like a good way to organise it
[00:49] <Hobbsee> james_w: i don't *actually* think there's that many decisions that get taken, in a cycle, on a technical note, for things that are required for later releases.  dh_icons, major X dependancy changes, mono changes, maintainer field changes, that kind of thing was what I was imagining.  Were you thinking of other type of things apart from that?
[00:49] <persia> See, I want news to have things like "We've decided to move to X 1.6, with the following implications"  "The new armel port is underway, has these outstanding issues, but is otherwise in fairly good shape"  "OpenJDK will now be the default Java for Ubuntu, so everything should be aligned to work with that".
[00:49] <directhex> persia, i'm planning and doing things. perhaps you've hard of them? :p
[00:50] <persia> directhex, Yes.  you sent mail.  Thank you.
[00:50] <james_w> Hobbsee: in my head it would be a superset of those things, including the things that persia lists.
[00:51] <persia> james_w, None of these are interesting to someone who has been away for 6 months, as they're mostly done, or not actively important.  What is interesting is "There's a new team called UUC" or "We can do normal uploads or bzr pushes now" or "Soyuz *finally* supports orig.tar.bz2, so don't bother re-wrapping the source".
[00:51] <james_w> skimming the titles would hopefully allow you to quickly see "dh_iconcache is deprecated, use dh_icons" and read that, but skip over "OpenJDK will now be the default Java for Ubuntu" if you don't work on Java packages.
[00:51] <persia> It's not whether one works on Java packages.
[00:52] <persia> It's that it's not even interesting to someone who does work on Java packages who's been away for a while.
[00:52] <persia> it's obvious from looking at the state of the stack.
[00:52] <Hobbsee> james_w: right, yes.
[00:52] <james_w> and with the list of everything it would be easier for interested parties to compile the list of things that affect the workflow
[00:52] <persia> armel is news today.  In 6 months, it won't have mattered.
[00:53] <persia> Oh, sure.  The news can be a source of input to a "What changed" wiki page, and an important one.  I just think they are different.
[00:53] <james_w> persia: if it is obvious, how hard is it to skip it?
[00:53] <persia> james_w, You're missing my point.
[00:54] <persia> The problem is not that the information doesn't exist.
[00:54] <persia> It's easy to collect by skimming the ubuntu-devel@ archives, reading the ubuntu-devel-announce@ archives, and going through the MOTU Meeting minutes.
[00:55] <persia> Sometimes it's worth going through the CC and TB minutes also, but those usually have slightly less effect to most developers (with a few key exceptions).
[00:55] <persia> The problem is that people don't want to read that.
[00:56] <james_w> ok, I would say that the list of news items would provide an acceptable granularity to me.
[00:56] <persia> james_w, I understand that.
[00:57] <james_w> given the opposite, but lesser, concern that too much filtering will lead to things of interest to someone being left out.
[00:57] <persia> Most of the old devs who swing by need to be caught fast.  Anything that doesn't fit in a quick span of vague attention will get skipped ("Bah, too much changed"), unless there's some external motivation to engage again.
[00:58] <persia> There have been a few who went away and came back.
[00:58] <james_w> and I'm satisfied if work on the news project can make it easier to achieve what you want.
[00:58] <persia> There have been many who went away, came back for a day or two, said hi, asked a coupe questions, and left saying it was confusing.
[00:58] <persia> I don't think the news archive would serve them, and there's few others who would clearly benefit.
[00:59] <persia> james_w, Um.  Firstly, I don't really care if this exists.  I'd rather have a "current best practices" document than "changes since when", and to push it to everyone every few months.
[00:59] <persia> james_w, Also, I think there's *huge* value in news regardless of this other thing.
[01:00] <persia> My only objection is that I don't think news in-and-of-itself addresses the request.
[01:00] <james_w> ok, I can accept that
[01:00] <james_w> would your "best practices" thing be like the dev-ref, but more useful?
[01:01] <persia> james_w, Shorter, more based on variation from current Debian practice, and more useful.
[01:01] <james_w> ok
[01:02] <persia> Whlie there's lots of people who don't come from Debian, it remains a great source of documentation, and I think listing things like "Everything is maintained by teams, and the current maintainer string should be taken as guidance rather than restriction" is more useful than "Ubuntu is collaborative, and works on the basis of collected and contributed patches by interested parties".
[01:03] <persia> Writing that takes a bunch or work by someone (and I'd still like to find the old one), but it's punchy, and if we make it a practice to put all significant choices and decisions there, it becomes a useful reference, even if much of it ends up being pointers to more verbose explanations.
[01:04]  * james_w nods
[01:05] <james_w> Hobbsee: another one for you :-)
[01:05] <persia> Anyway, I'm not especially promoting that right now, as I don't have the idea for it strongly enough to start drafting something.
[01:05] <james_w> Hobbsee: "- Decrease sponsorship times, for various teams"
[01:05] <james_w> persia: yeah, it sounds like something I would like to see, but I don't want to walk down that path just now.
[01:09] <Hobbsee> james_w: hmm?
[01:09] <james_w> Hobbsee: sorry, I mean I'm not sure what you mean by that.
[01:09] <persia> reducing time from subscription to upload
[01:09] <Hobbsee> james_w: the sponsorship queues can get very long
[01:10] <james_w> I thought you might mean people feel like they have to spend too much time sponsoring
[01:10] <Hobbsee> oh
[01:10] <persia> Frustratingly, when the sponsoring queue is in the 30-40 range, there are lots of sponsors.  When it gets above 50, it seems all sponsoring mostly stops for a while.
[01:10] <Hobbsee> hadn't thought of it that way
[01:10] <james_w> or perhaps that applications took too long to process
[01:10] <persia> Probably just needs work on how we organise sponsoring.
[01:11] <james_w> just delete items if it threatens to hit 50?
[01:11] <persia> No.
[01:11] <james_w> damn
[01:12] <persia> I've gone through it about 10 times and pushed out non-debdiffs to get down to the magic number, but people kept yelling at me for that, so I stopped.
[01:12] <Hobbsee> heh
[01:12] <Hobbsee> i liked that solution too :P
[01:12] <Hobbsee> and shoving debian stuff out of the queue, after it was already in ubuntu
[01:13] <persia> The idea was to add a tag to them, and have interested contributors use that tag to make debdiffs, which seemed to work, but generated a lot of bugmail, and annoyed some patch authors who didn't know how to make debdifs, and didn't espectially want to learn.
[01:13]  * james_w notes that the universe queue is at 49
[01:13] <persia> james_w, Thank you for that.
[01:13] <james_w> without pruning stuff that shouldn't really be on there
[01:14]  * persia isn't sure if this is good or bad.
[01:15] <persia> Either we're not getting that many submissions, or there's been an immense amount of work done.
[01:16] <james_w> it's dropped by almost 100 in the last week
[01:16] <persia> What's your guess on merges vs. bugfixes by count?
[01:17] <serialorder> i have a question I was hoping to get some help with, i am fairly new to all this
[01:17] <james_w> 90% merges/syncs of the newer items
[01:17] <persia> serialorder, What's the question.
[01:17] <james_w> (i.e. anything added since Intrepid)
[01:17] <serialorder> i am attempting to apply to create patch  a simple bug fix and repackage
[01:17] <persia> james_w, Right.  That means we're not getting enough submissions.
[01:18] <persia> serialorder, Excellent.  That's why we're here.
[01:18] <persia> Have you determined which patch fixes the bug?
[01:18] <serialorder> that part went fine but just out of curiosity I ran licensecheck -r --copyright . and noticed there are several copyright holders listed in the output that are not in debain/copyright
[01:18] <persia> serialorder, Which package?
[01:19] <serialorder> uml-utilities
[01:19] <persia> serialorder, That's probably not worth fixing directly, but it is worth filing a bug about it.  Extra points for filing the bug in the Debian BTS.
[01:19] <james_w> persia: 250 sponsored uploads this week, which is around average I think
[01:20] <serialorder> ok so i will file a bug about it
[01:20] <james_w> I think that number is right
[01:20] <persia> james_w, Roughly, yeah.
[01:20] <serialorder> are you saying I should file in both or only Debain BTS
[01:21] <persia> serialorder, I like both linked, but lots of people would say only the Debian BTS.
[01:21] <serialorder> ok, thanks for the help persia
[01:21] <persia> It's not something we fix in Ubuntu for packages in Debian, except in very special cases (e.g. where one of the missing authors complains).
[01:21] <persia> So the only reason for the Ubuntu bug is to track the Debian bug, and maybe provide an announcement in case anyone wants to complain.
[01:22] <serialorder> oh ok, that is good to know
[01:22] <serialorder> this can all be a bit daunting at first
[01:23] <persia> serialorder, The basic rule is: if it's a package only in Ubuntu, we fix everything we can for every upload.
[01:23] <persia> If it's a pacakge also in Debian, we mostly concentrate on bugfixes, or adjustments to make it work better in Ubuntu.  We send all the bugfixes also to Debian and upstream so everyone benefits.
[01:24] <persia> The exceptions are usually for release freezes of one sort or another, where certain types of uploads become restricted.
[01:26] <serialorder> if the fix closes a bug I am supposed to include something like (closes: #<bug number>) in the change log correct?
[01:26] <persia> LP: #nnnnnnn
[01:26] <persia> closes: is used to close Debian bugs.
[01:27] <serialorder> thanks , i thought it did'nt look right
[01:29] <persia> james_w, My apologies, but I'm not finding it.  I've looked through about 1000 wiki page titles, and maybe 75 pages, but I think it's gone.
[01:30] <james_w> persia: no problem, thanks for looking :-)
[01:30] <persia> I remember it mentioning the GCC ABI change, and the X libraries transition, and stuff like that.
[01:30] <james_w> persia: if you ever stumble across it I would like to see it
[01:30] <persia> Sure.
[01:30] <persia> Problem is that it takes about a month (straight) to read the wiki, so it's easy to lose stuff.
[01:31] <persia> I've still not actually finished processing https://wiki.ubuntu.com/MOTU/WikiCleanUp/SomeReviewNotes
[01:32] <persia> That it exists still, the date it was last edited, and the number of referenced pages that still exist are a good indication of just how much cruft is there.
[01:42] <james_w> Is there somewhere I can read up on what clean-la.mk is trying to fix?
[01:42] <james_w> does it just make .la files less useful, but make dependency management easier?
[01:47] <RAOF> Aargh.  Must not reply to mono troll on ubuntu-motu@
[01:47] <Hobbsee> RAOF: yes, you musn't.  I already got a lovely reply to *my* mail to him today.
[01:48] <RAOF> (Hopefully by putting that determination in the public sphere, I'll be able to actually resist)
[01:48] <Hobbsee> RAOF: yes.  Try very hard not to feed the trolls.  Go find beer instead ;)
[01:49] <RAOF> Hm.  I suppose the sun /is/ over the yardarm...
[01:54] <persia> james_w, My (vague) understanding is that it's trying to avoid .la files, and discourage both use and the possibility they might be used at build time to make dependency chains more sensible.  Unfortunately, I don't know of any good doc about it.
[01:55] <james_w> persia: ok, thanks.
[01:55] <james_w> I'm looking at a sponsorship request, and whether to forward the change to Debian
[01:56] <persia> Which one?
[01:56] <james_w> the changelog entry when it was introduced was about "fixing" the .la file, which makes it sound like something that should be, but I'm pretty convinced it's not something to forward
[01:56] <james_w> though it seems a little odd to do it on a per-package basis
[01:57] <james_w> bug 299350
[02:01] <persia> james_w, I'll agree it's odd to do on a per-package basis.  On the other hand, I can see iulian's arguments, and think that including that is useful.
[02:01] <persia> .la based dependency chains get *very* annoying.
[02:02] <james_w> I guess if it involves packaging modifications not appropriate for Debian to cope with the stripped .las anyway then we wouldn't gain anything by doing it for all packages
[02:02] <persia> The per-package basis might be to preserve those cases where we *need* .la files, or it might be part of an attempt at a gentle introduction to Debian.
[02:03] <persia> I think current Debian practices to reduce dependencies are moving in different directions (from what small bits I see), but until there's a reduction in the Debian pacakge itself, it probably has some value.
[02:04] <persia> I wouldn't forward this patch to Debian, personally, it's far too awkward, relies on Ubuntu infrastruture, etc.
[02:04] <james_w> yeah, I just wondered if the "fix" was a "fix", and so we should send a bug report.
[02:06] <persia> Well, yes and no.
[02:06] <persia> It's a "fix", but it's not clear if the problem being fixed either exists or is important in Debian.
[02:09] <persia> pitti or slangasek would be the experts on this.  My main argument against sending it back is that I can't find a bug for clean-la.mk on CDBS.
[02:09] <persia> I'd presume that if that were applicable to Debian, it would be there.
[02:12] <slangasek> pff, name droppers.  Can someone give me some summary context?
[02:14] <slangasek> james_w: so what clean-la.mk does is munge the .la files in the installed package so that there are no dependencies.  It has been debated whether this is a correct thing to do, but the strongest opponent to it is Keybuk, who won't stand in the way of pushing it to Debian if that's the question
[02:15] <james_w> slangasek: the question boiled down to whether using clean-la.mk indicated that there was a bug in the package that should be reported to Debian
[02:16] <slangasek> are you asking whether a patch should be forwarded up to Debian to /use/ clean-la.mk, or are you asking whether the use of clean-la.mk implies bugginess in the package?
[02:16] <persia> The latter
[02:17] <slangasek> then no
[02:20] <james_w> thanks slangasek
[02:21] <JonReagan> is a debian/watch file necessary for a package?
[02:21] <persia> JonReagan, It's very strongly recommended for packages that are not also in Debian, so we can more easily track when a new upstream is available.
[02:22] <JonReagan> ah... k, thanks.
[02:22] <persia> If a debian/watch file cannot be constructed, please construct a get-orig-source rule.
[02:22] <james_w> bug 299353 is an interesting one
[02:22] <persia> Many reviewers will not advocate a package without one of the two.
[02:22] <JonReagan> persia: thanks
[02:23]  * persia seems to remember being disturbed by libkipi previously
[02:23] <james_w> the -common package is gone, so the libpackage should ship its own icons, but that would seemingly make libkipi0 and libkipi5 not co-installable.
[02:25] <james_w> and a quick glance suggests to me that removing libkipi0 is tied up with the KDE4 transition, so I'm not chasing that rabbit
[02:26] <serialorder> ok persia I have another question
[02:26] <persia> I'd be suspicious of that.  Last merge by that merger I reviewed was a thoughtless copy&paste.
[02:26] <persia> serialorder, Just ask generally.  I could have fallen asleep by now :)
[02:26] <serialorder> well i saw you typing away
[02:26] <serialorder> but point taken
[02:27] <james_w> persia: suspicious of what?
[02:28] <persia> james_w, Suspicious of the merge because 1) it's adding a dependency to a package that doesn't exist, and 2) I had a poor experience with the last merge from the same person.
[02:28] <persia> (that was last week or earlier this week or something)
[02:29] <Hobbsee> oh, that's always a good one.
[02:29]  * Hobbsee encountered that a while ago, but then discovered an out of date cache.
[02:29] <james_w> persia: yeah, I'm talking about what should happen, the proposed debdiff is certainly wrong
[02:29] <serialorder> the package I have been working on, uml-utilities was never synced in hardy or intrepid, last version that has an ubuntu specific build is in gutsy
[02:30] <serialorder> when I post the fix to this bug should I also create a sync request bug as well?
[02:30] <persia> james_w, Well, there are two options.  #1) unsub the sponsors and leave a comment saying what should be done, or #2 (my favorite) do it yourself, ignore the debdiff, and close the bug.
[02:31] <persia> I often attach the correct debdiff to a bug so that the merger can examine the difference, and include a paragraph about why it was completely wrong.
[02:31] <james_w> persia: I'm trying to do number two
[02:31] <persia> This is just a clear case of trusting MoM.
[02:32] <persia> I'd be tempted to sync, if that's the outstanding change
[02:32] <Hobbsee> james_w: libkipi-common is gone?
[02:32]  * persia looks harder at the debdiff
[02:32] <persia> No, it's there.  I read rmadison wrong.
[02:32] <persia> james_w, Ignore most of what I've said.
[02:32] <james_w> Hobbsee: I looked at the last upload of the source package
[02:32] <james_w> ...that used to provide it
[02:32]  * persia goes back to the list of things that are annoying, but must be done, rather than making more mistakes here.
[02:33] <james_w> has it moved?
[02:33] <persia> libkipi-common | 4:4.1.2-0ubuntu3 |        jaunty | amd64, i386
[02:33] <Hobbsee> persia: er, that'd be old
[02:33] <Hobbsee> kdegraphics | 4:4.1.3-1ubuntu1 |        jaunty | source
[02:33] <Hobbsee> james_w: would be right, there, and it needs to be NBSd out
[02:35]  * persia tries harder to avoid making mistakes by stopping typing
[02:35] <james_w> Hobbsee: I'm trying :-)
[02:35] <james_w> it would have been uploaded by now if the solution was obvious
[02:35] <Hobbsee> heh
[02:36] <james_w> libkipi0 Depends: libkipi5?
[02:39] <Hobbsee> where?
[02:39] <james_w> no, that's my suggestion
[02:39] <Hobbsee> oh
[02:39] <james_w> libkipi0 would then have the icons it needs installed
[02:39] <james_w> they would still be co-installable
[02:40] <james_w> and builds would still work as the -dev symlink wouldn't change
[02:40] <james_w> it does make me want to take a shower though
[02:41] <Hobbsee> er, is making the kde3 version depend on the kde4 version a really wise move?
[02:41] <james_w> oh, there's a kdegraphics-kde4
[02:41] <Hobbsee> you can ask that in #kubuntu-devel, anyway
[02:42] <james_w> ah, not any more
[02:42] <Hobbsee> james_w: there was, anyway.  it's been phased out, afaik.
[02:42] <Hobbsee> when we had the emss of 2 kdes.
[02:42] <james_w> if the packages aren't co-installable then it would make it impossible to install some kde3 apps on jaunty
[02:43] <serialorder> im going to try asking this one more time
[02:43] <serialorder> the package I have been working on, uml-utilities, the upstream version  was never synced in hardy or intrepid, last version that has an ubuntu specific build is in gutsy
[02:43] <serialorder> when I post the fix to this bug should I also create a sync request bug as well?
[02:44] <james_w> oh, sorry serialorder, missed your question
[02:44] <james_w> serialorder: I don't see a new version in Debian we can sync
[02:44] <serialorder> http://packages.ubuntu.com/source/uml-utilities
[02:44] <james_w> but you mean update to the new upstream version
[02:44] <serialorder> that is where i am looking
[02:45] <serialorder> maybe that is the wrong place?
[02:45] <serialorder> or im using the wrong words
[02:45] <james_w> "sync" has a specific meaning in Ubuntu, usually to pull in a version of a package from Debian
[02:45] <james_w> in this case we have the same version as Debian, so there is nothing to sync
[02:45] <james_w> if there is a new upstream then it would be possible to update to that though
[02:45] <serialorder> ok maybe i am confused then
[02:46] <serialorder> is there a reason the versions in hardy and intrepid dunot have an ubuntu ending?
[02:46] <Yasumoto> james_w: Wow, I probably should've thought about that. Thanks for cleaning up the formatting :)
[02:46] <Yasumoto> (re: ubuntu dev news)
[02:46] <james_w> Yasumoto: no problem
[02:47] <james_w> Yasumoto: apologies if I munged your meaning at all
[02:48] <Yasumoto> not at all, thanks
[02:48] <serialorder> james_w: I think im confused then, is there a reason the versions in hardy and intrepid do not have an ubuntu# ending?
[02:49] <Hobbsee> james_w: they're coinstallable, no question, it's just whether one should be able to remove the kde4 version if desired that is the question
[02:49]  * Hobbsee apparently can't type today
[02:49] <james_w> serialorder: that means that the package is unmodified from Debian
[02:49] <serialorder> are those only introduced when there is a bug fix introduced in ubuntu but not upstream
[02:49] <serialorder> ahhh ok
[02:49] <james_w> Hobbsee: yes, but a sync would mean they were no longer co-installable.
[02:50] <james_w> Hobbsee: and given that ubuntu is now kde4 I'm not sure why you would want to remove a kde4 lib from your system
[02:50] <Hobbsee> james_w: point taken.
[02:51] <Hobbsee> james_w: unless you ran it on gnome, and didn't want more kde deps than you absolutely had to have.
[02:51] <james_w> I agree it's not nice, but neither is a lib shipping images
[02:51] <Hobbsee> it being stuff like digikam : that's a real scenario
[02:51] <Hobbsee> debian should be able to be reasoned with, though.
[02:51] <serialorder> james_w: last question, so if i applied a patch and rebuilt to resolve the bug then in launchpad all I need to do is attach the debdiff and subscribe sponsors right?
[02:51] <james_w> but if Riddell dropped -common then he may have a plan
[02:51] <Hobbsee> they're pretty good, there, and the kde guys have connections
[02:51] <Yasumoto> RAOF: thanks for being so patient/helping me merge :)
[02:52] <james_w> serialorder: correct
[02:52] <serialorder> sweet thanks!
[02:52] <RAOF> Yasumoto: No problem.  You noticed that I added another missed remaining change to the changelog, I guess?
[02:52] <james_w> Hobbsee: I'll talk to someone in the morning. Thanks for your advice
[02:52] <Hobbsee> james_w: you're welcome.
[02:54] <Yasumoto> RAOF: yeah, thanks for catching that
[03:00] <jmarsden> Where can I find out how to package something, where the original source package format is a .zip ?
[03:00] <jmarsden> Not a .tar.gz or tar.bz2 as is "normal"
[03:00] <Hobbsee> jmarsden: unzip, tar & gz it?
[03:01] <Hobbsee> afaik, there's no actual 'difference' than it would be with a normal package
[03:01] <jmarsden> I can,. but I think there is supposed to be a way to do it... http://www.debian.org/doc/maint-guide/ch-first.en.html says you can but it "takes more knowledge..." ?
[03:01] <james_w> hmm, libkipi5 doesn't Conflict/Replace libkipi-common
[03:02] <james_w> isn't that required for moving files between packages?
[03:02] <james_w> the changelog says "(add conflicts/replaces)" but it doesn't add those ones at least
[03:02]  * Hobbsee notes the possibility of a bad merge
[03:03] <Hobbsee> but, you'd think so?
[03:04] <Hobbsee> jmarsden: i presume that means for things like sources in git / bzr / etc
[03:04] <Hobbsee> where you're doing a checkout
[03:04] <Hobbsee> i can't imagine zip files should be on that list
[03:04]  * james_w stops looking and will wait to ask someone more knowledgeable
[03:05] <jmarsden> OK.  I just thought that by unzip and tar I'm making an undocumented and un-automated change to the original sources "tarball", in a way... if it's Ok to just do that, then I'll just do that :-)
[03:06] <jmarsden> The guide says things are compicated if ... "the source file format being neither in tar.gz. nor tar.bz2" ...
[03:06] <Hobbsee> jmarsden: that's true.
[03:06] <Hobbsee> jmarsden: I *suspect* it's just an oversight of the guide.
[03:06] <jmarsden> OK, thanks.
[03:07] <Hobbsee> jmarsden: but yes, document that you did unzip and tar it, so people will be able to figure out why they can't find an upstream tarball ;P
[03:07] <jmarsden> OK :)
[03:07] <Hobbsee> certainly fro stuff like bzr & git, you want to ignore certain directories, etc.
[03:07] <Hobbsee> which would require more knowledge
[03:31] <RAOF> jmarsden: It doesn't _have_ to be an undocumented, unautomated change to the original sources; you can easily automate this in a get-orig-source rule in your debian/rules file.
[03:32] <jmarsden> RAOF: OK... sounds like what I was thinking of... any quick pointers to examples of that or a tutorial or something?
[03:32] <RAOF> https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball
[03:32] <jmarsden> Thanks!
[04:14] <bain> Can some motu take a look at http://revu.ubuntuwire.com/details.py?package=teamgit
[04:14] <bain> it has already received some prilim review
[04:22] <x1250> hey guys, could someone please tell me why this happens at line 70? http://paste.ubuntu.com/75079/
[04:22] <x1250> dpkg: dependency problems prevent configuration of pbuilder-satisfydepends-dummy:
[04:28] <RAOF> x1250: I'd guess the problem is that you don't have universe enabled in your pbuilder chroot.
[04:31] <x1250> RAOF, right. Thanks.
[04:50] <jsmidt> I have been looking at harvest and found a package called moodbar has a patch from fedora for it.
[04:50] <jsmidt> How do I figure out what the patch does?
[04:51] <jsmidt> The patch is found on the fedora website.
[04:51] <jsmidt> Here: http://cvs.fedoraproject.org/viewvc/devel/moodbar/moodbar-0.1.2-glib.patch?view=markup
[04:52] <jsmidt> I would like to learn to patch packages but am sure in the changelog you want to state why the package is being patched.
[04:52] <jsmidt> Or do I just say something like: "patched with fedora patch"?
[05:05] <RAOF> You'd _definitely_ need to know what the patch does before doing anything else.
[05:05] <RAOF> As for how to work this out... it depends.  If they've been nice and documented it, the patch should have something telling you what it actually does, or a reference to a bug to follow up, or somesuch.
[05:06] <RAOF> If it _doesn't_, then you need to use initiative; see if you can read what the patch does.  See if you can find the first time the patch appeared in the Fedora package; what bugs did that release fix?  Etc.
[05:11] <jsmidt> RAOF, thanks.  This is what I needed to know.  I was just wondering if fedora had an official way of documenting their patches and thought if so you guys would know about it.
[06:01] <RAOF> jsmidt: Now that I've actually _looked_ at the patch, it's obvious what it's doing, and I'd guess we don't need to (or have already) apply it; if we didn't have something like that, moodbar would be quite consistently crashing.
[06:04] <jsmidt> RAOF, okay, thanks.
[06:05] <RAOF> jsmidt: Obviously, if there are a bunch of segfault bugs on launchpad, it's worth investigating :)
[06:05] <RAOF> Failing that, I'd guess we've already got it.
[06:06] <jsmidt> RAOF, yeah, I'm new at this.  I'm just trying to track down bugs I know I can fix, especially ones where there is already a patch. :)
[06:07] <RAOF> Yeah.  That's the important part; you start with the bug, then find (or write) the patch.  Such is the way of things :)
[06:38] <dholbach> good morning
[06:40] <iulian> Good morning dholbach.
[06:40] <dholbach> hi iulian
[06:41] <jsmidt> dholbach, I am reading a guide I belive you wrote.  I found a bug and patch and patched the package and created a debdiff.  Now your guide says "You can now attach the debdiff to a bug report or send it to the relevant person. "  Who would that be?
[06:42] <jsmidt> Should I just make a bug report?
[06:42] <jsmidt> Or is there someone specific I should track down?
[06:42] <dholbach> jsmidt: if you want to get a patch uploaded, check out https://wiki.ubuntu.com/SponsorshipProcess
[06:42] <jsmidt> dholbach, thanks.
[06:43] <dholbach> basically attach the bug to an existing bug report or file a new one with all the information, then subscribe ubuntu-main-sponsors (for main/restricted) or ubuntu-universe-sponsors (for *verse)
[06:43] <dholbach> I'll fix the doc
[06:43] <dholbach> thanks for the feedback jsmidt
[06:43] <jsmidt> dholbach, thanks.
[06:44] <dholbach> rock on jsmidt!
[07:14] <didrocks> morning o/
[07:15] <nellery> dholbach: hi, I'm having some trouble with bug 300547
[07:15] <nellery> attempting to build it with the proper dependency fails
[07:15] <nellery> do you have any ideas?
[07:33] <dholbach> nellery: let me see
[07:33] <nellery> dholbach: I've just attached the debdiff's which failed to the bug report
[07:34] <Yasumoto> does MoM get updated frequently?
[07:41] <dholbach> nellery: did you try just taking the debian version and changing the build-dep to linux-source-2.6.27?
[07:41] <dholbach> nellery: that built fine for me
[07:51] <nellery> dholbach: there we go, I got it
[07:51] <nellery> is that the only change necessary?
[07:52] <dholbach> nellery: I don't know
[07:52] <dholbach> I have no idea how modconf works and what else might be necessary to make it work
[07:53] <dholbach> which changes were necessary between 0.3.7 and 0.3.7ubuntu1?
[07:55] <nellery> dholbach: it looks like it was just the build-dep change
[07:56] <dholbach> does the newly built version work in jaunty?
[07:58] <nellery> dholbach: it builds fine in jaunty
[07:58] <dholbach> nellery: does it work too?
[08:03] <dholbach> sorry, got kicked out
[08:03] <dholbach> nellery: does it work too?
[08:09] <nellery> dholbach: sorry, I had to run away for a sec
[08:09] <nellery> I'm very sorry, but I have to leave
[08:09] <dholbach> nellery: no worries, I need to leave too
[08:09] <dholbach> just follow up on the bug repotr
[08:09] <dholbach> and thanks for looking into this
[08:09] <nellery> alright, once I confirm everything works
[08:09] <nellery> thanks for your help :)
[08:10] <dholbach> nor worries
[09:50] <bain> can some motu please take a look at http://revu.ubuntuwire.com/details.py?package=teamgit
[09:50] <bain> it has already received a prilim review
[10:38] <kiko-afk> hello gentlemen
[10:38] <kiko> no use pretending
[10:38] <kiko> anybody feel like merging a patch to unbreak syncropated? fix > 10 dupes in the process? I wrote the patch so it's obviously right <wink>
[10:38] <kiko> https://bugs.edge.launchpad.net/ubuntu/+source/syncropated/+bug/200357
[10:47] <dholbach> kiko: I'll take a look at it... https://wiki.ubuntu.com/SponsorshipProcess (ubuntu-universe-sponsors is the 'magic word') :-)
[10:51] <kiko> magic
[10:51]  * kiko <- fan of dholbach 
[10:53] <dholbach> kiko: I'd love if we could just "take at the list of ubuntu bugs with patches attached", but there's so much stuff tagged as patch that does not apply or is no patch at all, so that's why we have this process as a filter
[10:53] <Hobbsee> oh, kiko's here.
[10:53] <dholbach> in a new world, merge proposals might work for it
[10:54] <Hobbsee> hey :)
[10:56] <eMerzh> if someone is in a reviewing mood....my package is waiting for comments : http://revu.ubuntuwire.com/details.py?package=sqliteman
[10:56] <kiko> dholbach, isn't the right solution there to go over stuff marked as patch and unmark it, or delete it?
[10:57] <dholbach> kiko: right, but it's ~1200 bugs or something
[10:57] <dholbach> kiko: I think we can slowly get there, but only slowly
[10:57] <persia> kiko, Very much unmark.  Most of the "patches" are useful as attachments, just not as patches.
[10:58] <kiko> dholbach, I can do like 50 a day and then you just need to watch the queue
[10:59] <dholbach> kiko: another problem is bug status often != patch status, so it's hard to keep track of when a review is required without guessing
[10:59] <dholbach> kiko: if you can just unsubscribe a team, that's easy
[10:59] <persia> kiko, That'd be great.  We're currently only getting about 40 a day sponsored, but with real commitment to feed the rest in (tested, of course), We could probably get some more.
[11:00] <dholbach> but anyway... I agre with you that the list of bugs with patches should be a lot lot lot shorter
[11:00] <dholbach> and people get good feedback
[11:00] <kiko> dholbach, give me a link and let me see if I can go through it
[11:01] <persia> kiko, There's a bug against Malone about awkward machinations for sponsoring.  Is that maybe something that could be scheduled for a meeting sometime to look at a possible cleaner way to do things?
[11:01] <kiko> persia, give me the bug number and I'll put it on next week's agenda
[11:02] <persia> kiko, There's one on the front page of qa.ubuntuwire.com (list of bugs with patch attachments)
[11:02]  * persia will be a few minutes digging up the bug number
[11:02] <dholbach> kiko: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.has_patch=on
[11:03] <dholbach> I think james_w had an idea about automatically testing the attachments and test-applying them
[11:03] <dholbach> but I'm not sure I'm correct
[11:03] <kiko> that's not a bad idea -- you can at least get freshness
[11:04] <persia> kiko, bug #179857
[11:12] <kiko> persia, dholbach: I'll also get https://bugs.edge.launchpad.net/malone/+bug/35030 fixed because that is fucking annoying
[11:13]  * dholbach hugs kiko
[11:13] <dholbach> that's nice about bug lists like https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-main-sponsors :-)
[11:13] <dholbach> not repetition :)
[11:16] <persia> kiko, Cool.  Thanks for chasing this class of bugs.  It's a big help.
[11:41] <bain>  can some motu please take a look at http://revu.ubuntuwire.com/details.py?package=teamgit
[11:41] <bain> it has already received a prilim review
[11:44] <handschuh> I'm afraid to ask, but since it is revu-day, could somebody revu a small package of mine (http://revu.ubuntuwire.com/details.py?package=uiflite) ?
[11:45] <persia> handschuh, Don't be afraid to ask.  It's REVU day.  It's the best possible time to ask.
[11:45] <persia> I'll take a quick look once I finish the current spec, unless someone else grabs it first.
[11:45] <handschuh> persia: thanks !
[11:45] <persia> (or even if someone else grabs it if they advocate)
[11:47]  * handschuh eats some lunch
[11:50]  * cody-somerville goes to get some breakfast :)
[11:52] <luisbg_> cody-somerville, bon appetite :)
[12:05] <persia> handschuh, Although .* is extremely greedy in perl, it can sometimes be useful in that class of watch file (but it's not worth fixing that: when it works, it's good)
[12:06] <laga> are there various levels of greediness?
[12:06] <persia> handschuh, Also, using ([_\d]+ and opts=uversionmangle= is another way to do it.
[12:07] <persia> laga, Yep.  Some regex processors will grab everything possible with that sort of glob.  Others will grab as little as possible.
[12:07] <laga> persia: then they're not greedy at all :)
[12:08] <persia> For example, If I'm using /(.*)q.*/ to match lkjhlkjheqlkjhkljheqlkjh, some implementations return lkjhlkjhe and others return lkjhlkjheqlkjhkljhe
[12:09] <persia> Hrm.  I can see that.  Dunno if there's more than greedy and not greedy, but I've only played with 6 or 7 regex implementations.
[12:09] <handschuh> persia: ok i am going to change this
[12:09] <persia> handschuh, Really, it's not worth changing.
[12:10] <persia> handschuh, When you get a watch file that works, keep it.
[12:10] <persia> These are just a couple other options that might be interesting if you run into similar issues in the future, or for you to play around with to become more familiar with watch files in general.
[12:11] <handschuh> persia: *notices*
[12:11] <persia> hrm?
[12:11]  * persia is mostly confused by the notation
[12:12] <handschuh> persia: (your different way of getting the version)
[12:12]  * handschuh notices
[12:12] <persia> Ah.  Got it.  Sorry for the confusion.
[12:12] <persia> Note that it's perl, so TMTOWTDI is a basic axiom :)
[12:13] <handschuh> persia: i don't  chat a lot so it is very likely that I make strange notations
[12:14] <persia> Well, I'm glad to see you about.  I've seen your blog a bunch, but think more interactive channel discussion is a good way to learn.
[12:16] <persia> handschuh, Also, you might find reading about the $(patsubst ...) function in make interesting.  It can save you calling out to external processes for some things.
[12:16] <persia> (or: I would have written "UIFLITE_ORIGVERSION=$(shell echo $(UIFLITE_VERSION) | sed "s/\./_/g")" differently, but it doesn't really matter)
[12:16] <handschuh> persia: calling out ot external processes?
[12:17] <handschuh> persia: a, ok
[12:17] <persia> Right.  In the variable definition above, you're launching three extra processes.
[12:18] <persia> Again, not worth fixing: just me pointing out features in make (as I was perl and watch file options earlier)
[12:19] <handschuh> persia: I really do appreciate it because I am a "java-only" guy that does not know much about anything else
[12:20] <persia> I will be rejecting your license though.  It's only save to use /usr/share/common-licenses/BSD when it's "Copyright (c) The Regents of the University of California."
[12:21] <handschuh> ok so i just include the original (upstream) 3-clause bsd
[12:21] <persia> Yep, because it's not actually BSD, it's BSD-like.
[12:22] <persia> This is why I recommend the "ISC" or "MIT" licenses for such code.  Nearly identical permissions, but less confusing.
[12:22] <persia> Of course, it's not worth asking upstream to relicense.
[12:23] <persia> That's it though.  I can't find much wrong with this one.
[12:23] <persia> So fix debian/copyright, and I'll advocate.
[12:23] <handschuh> persia: great, thanks
[12:26] <handschuh> persia: so just to be sure: http://paste.ubuntu.com/75197/
[12:27] <persia> Yep.  That works.
[12:28] <handschuh> persia: ok, I uploaded the new version
[12:31] <eMerzh> if someone is in a reviewing mood....my package is waiting for comments : http://revu.ubuntuwire.com/details.py?package=sqliteman :) thanks
[12:32]  * handschuh is going to review eMerzh's package 
[12:32] <eMerzh> \me is happy :)
[12:32] <eMerzh> oups :D
[12:33]  * eMerzh is happy :)
[12:33] <handschuh> eMerzh: you still have the empty line in the middle of the watch-file
[12:34] <eMerzh> erf
[12:34] <handschuh> eMerzh: this is just a minor issue
[12:35] <handschuh> eMerzh: no real issue to be specific, but if enything else is wrong with the package, you could upload this, too
[12:36] <eMerzh> handschuh: ok...
[12:36] <handschuh> eMerzh: sorry to be so padantic, but debian/changelog: "this patch corrects" (this is not important, but maybe you want to change it)
[12:37] <handschuh> eMerzh: lets see, if it builds
[12:44] <handschuh> persia: thanks for advocationg uiflite - now i can repare a new package  :-)
[12:45] <stefanlsd> ScottK: you around?
[12:46] <persia> handschuh, Well, you still need another advocate.
[12:46]  * stefanlsd is gonna make all the guys at the company watch dholbach's motu videos in our tech session
[12:46] <persia> stefanlsd, You're pushing the corporate "Everyone is an Ubuntu Developer" model?
[12:47] <handschuh> persia: yes, but if there are changes needed in tha package, i assume they will not be that drastical
[12:47] <persia> handschuh, Oh, probably not.  Someone might complain more about the stuff I mentioned as alternates, but that's trivial.
[12:47] <persia> I'd not be surprised if someone wanted Java 6 to be prioritised over Java 5 in the alternates.
[12:48] <stefanlsd> persia: mm. no. but i think it gives people fundemental understanding around .deb stuff i think they should have.  (and im pushing my own agenda of wanting more MOTU's and devs coming out of south africa) - and hopefully this will get some of them excitied
[12:49] <handschuh> eMerzh: you package successfully build, but did you run lintian on the binary package?
[12:49] <persia> stefanlsd, I'm reminded: how much do you know about building mesh networks?
[12:50] <eMerzh> handschuh: i think i did it, but nothing shows up....you have errors?
[12:50] <stefanlsd> persia: what kind of mesh?
[12:50] <handschuh> eMerzh: W: sqliteman: copyright-without-copyright-notice
[12:51] <persia> stefanlsd, Like devices hopping to other devices ad-hoc.
[12:51] <stefanlsd> persia: mesh like cloud stuff, or mesh re infrastructure components?
[12:52] <handschuh> eMerzh: I think I know the reason: debian/changelog: under the section Copyright, there is no "Copyright (C)"
[12:52] <eMerzh> handschuh: yep...but i should write it for each line?
[12:52] <persia> stefanlsd, infrastructure stuff.
[12:53] <stefanlsd> persia: mm. cant say i've ever done anything specific. but do quite alot of routing stuff with load balancer and replicated services
[12:53] <handschuh> eMerzh: interesting question ... I don't know ... sry (let me try to find a policy)
[12:53] <eMerzh> handschuh:  because someone  told me that i should'nt repeat it each time
[12:54] <handschuh> eMerzh: ok then, just write it in the first line of the copyright-section
[12:54] <eMerzh> handschuh:  i think that it was persia...but not sure of that
[12:54] <handschuh> eMerzh: (no name attached)
[12:54] <eMerzh> ok
[12:54] <handschuh> eMerzh: wait, i will check if it works  :-)
[12:54] <persia> stefanlsd, Oh well.  Thanks.  I was thinking about advantages of using things like mesh to try to improve connectivity at things like UDS, but I guess I'm misremembering that you might be someone who knows.  Sorry for the confusion.
[12:55] <persia> What did I say?
[12:55] <stefanlsd> hehe
[12:58] <handschuh> eMerzh: for me, it didn't work ... lintian is still complaining
[12:58] <eMerzh> handschuh: ok...so i repeat it?
[12:59] <handschuh> eMerzh: wait, I will search for the policy
[12:59] <eMerzh> i've just found the comment... it said "Copyright: there is no need to add the word "Copyright" before every name" ....
[13:01] <eMerzh> handschuh: did i misunderstood?
[13:01] <handschuh> eMerzh: no you did not ... maybe the lintian error is pointing somewere else
[13:02] <eMerzh> ok
[13:02] <handschuh> eMerzh: http://lintian.debian.org/tags/copyright-without-copyright-notice.html
[13:04] <eMerzh> handschuh: ok, so, i just write (c)  ?
[13:04] <handschuh> eMerzh: (C), yes
[13:05] <handschuh> eMerzh: well -maybe- lets try  :-)
[13:05] <eMerzh> handschuh: héhé..ok
[13:08] <eMerzh> handschuh: thanks for your help....something else?
[13:08] <handschuh> eMerzh: did it work?
[13:09] <handschuh> eMerzh: (for me it did not ... but maybe I am doing something wrong)
[13:09] <handschuh> eMerzh: something else i did not found
[13:09] <eMerzh> i've not my compilation env right now....i'll test it in 2h :/
[13:10] <handschuh> eMerzh: the reason could also be: there is no year after the second name
[13:11] <eMerzh> handschuh: oh k...i'll try....
[13:13] <handschuh> eMerzh: i am trying it now
[13:14] <eMerzh> handschuh:  thanks a lot!
[13:14] <handschuh> eMerzh: you're welcome
[13:16] <handschuh> eMerzh: a least, this keeps me away from my master-thesis
[13:17] <eMerzh> handschuh: héhé :)
[13:17] <handschuh> eMerzh: there is still the copyright-without-copyright-notice
[13:18] <handschuh> eMerzh: this is the copyright-section, I am using: http://paste.ubuntu.com/75214/
[13:19] <eMerzh> handschuh: maybe it's about other legal issues? but for that i've contact upstream
[13:20] <handschuh> eMerzh: that may be ... I am sorry but I don't have enough experiance for determining the problem in detail
[13:21] <eMerzh> handschuh: ok, thanks anyway...i'll investigate ....
[13:27] <eMerzh> handschuh: exepted this,  anything else look wrong?
[13:27] <slytherin> handschuh: eMerzh: make sure you both are using same lintian versions and preferably one in intrepid-backports.
[13:28] <handschuh> slytherin, eMerzh: I am using Version Lintian v2.0.0~intrepid1
[13:29] <eMerzh> i haven't mine here so i can't tell...but it think that it's the version of intrepid backports
[13:30] <handschuh> slytherin: but the lintian has to be empty before the package could be accepted, right?
[13:31] <ScottK> stefanlsd: Here now.
[13:32] <stefanlsd> ScottK: sorry, just bout to go into a meeting. catch up later. was re spambayes.
[13:33] <ScottK> OK
[13:49] <mok0> Re: # 1 on the REVU list, what is supercollider? I can find no packages having to do with that
[13:50] <james_w> bddebian: hey. I see you uploaded the NMU of fcitx, I just sent a note to the bug stating that I'm not sure the fix is complete. I'm not sure whether to re-open it.
[13:50] <persia> It's a sound generator.  It got removed a couple releases ago for being unforgivably buggy.
[13:50] <james_w> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454363
[13:50] <persia> artfwo has a new version in PPAs, and is around, but due to a bug in REVU, it doesn't show in the list.
[13:50] <persia> Needs extra testing on amd64.
[13:50] <james_w> bddebian: I don't even have confirmation of my suspicions at this point though.
[13:52] <persia> mok0, I keep gettiing about halfway through comments on that one, and my browser crashes, and I get distracted.
[13:52] <persia> If you have time to hit it, great.
[13:52] <persia> If not, it's on my list to hit before I leave.
[13:52] <persia> #2 isn't on my list though.
[13:53] <JonReagan> do any of y'all know where I can find a good example debian/watch file?
[13:53] <mok0> persia: I'll take #2
[13:53] <persia> JonReagan, There's a howto in the wiki, or look at any of the majority of the approved archived packages on REVU.
[13:54] <JonReagan> thanks!
[13:54] <mok0> persia: artfwo has a package that's been sitting in "needs work" for a while, so maybe he's not too active
[13:54] <handschuh> JonReagan: http://wiki.debian.org/debian/watch might help you
[13:55] <Laibsch> any kind soul around willing to commit the SRU debdiffs I prepared  for bug 221010 and bug 227547 ?
[13:55] <JonReagan> thanks
[13:55] <bddebian> james_w: Well if you think it isn't fixed, re-open it :)
[13:56] <persia> mok0, He's around.  Saw him in #launchpad about 4 days ago.  He just doesn't have a lot of confidence in REVU right now.
[13:56] <james_w> bddebian: actually, I guess I will open a new bug, as I think the same problem exists for Qt
[13:56] <persia> mok0, We've a lot of people like that, in part because we sorta skipped REVU for intrepid.
[13:56] <mok0> persia: can't say I blame him :-)
[13:56] <persia> mok0, Neither I
[13:56] <mok0> persia: confidence takes a long time building, only a short time to tear down...
[13:58] <bddebian> Just never have any confidence and you won't have that problem :)
[13:58] <handschuh> who is the one in charge of programming revu?
[13:58] <persia> handschuh, The REVU Hackers share that, but REVU is open source: patches are usually accepted fairly quickly.
[14:00] <handschuh> persia: as I not arround here for a long time, was there the attempt of creating an auto-build-environment for revu?
[14:00] <persia> handschuh, It's been discussed.  I've yet to be unsuccessful at shooting it down.
[14:00] <persia> For a while there was a manual build triggering process that could be performed by reviewers, but that bitrotted.
[14:01] <mok0> It's good for uploaders to learn how to set up a building environment of their own
[14:01] <persia> handschuh, In short, the argument is that because we want to support uploading earlier versions, it's important that REVU isn't used as a repository.
[14:01] <persia> Also, developers are expected to have a working clean build environment, so it's good practice to do it that way.
[14:02] <persia> If you're really short on CPU time, a few people have debomatic or other build farm environments up.
[14:02] <handschuh> persia, mok0: my idea was to create something like lintian, but just for the build process
[14:02] <handschuh> maybe one can connect revu to a ppa
[14:03] <handschuh> so that the ppa does the work of compiling
[14:03] <persia> There's a beta PPA importer to do something like that.
[14:04] <handschuh> persia: oh, great - so it could be done in that way
[14:04] <persia> On the other hand, the LP devs finally decided a direction for PPAs, and they are making them first-class repos, which add a lot of versioning and release restrictions that aren't appropriate for REVU.
[14:05] <handschuh> persia: ok thats a good point
[14:07] <handschuh> persia: what do you mean by "first-class repositories"?
[14:08] <persia> From what I understand, essentially somewhere from which you could distribute an entire distro if you wanted (and didn't need components)
[14:08] <persia> Very focused on providing services to end-users, including care to ensure upgrades happen sanely, signatures for packages, etc.
[14:08] <persia> Not all that's implemented yet, but the recent set of bug comments indicate that it is the decision.
[14:09] <persia> As a result, the iterative process to create the perfect package doesn't work well on PPAs now, and can be expected to work less well as the optimisation continues.
[14:10] <persia> Well, you could do e.g. foo-1.2.3-0ubuntu1~ppa97 but you'd get hit with the version number every time.
[14:12] <handschuh> persia: thanks for that information ... really interesting
[14:17] <directhex> yay for PPA signing, that would make my life easier... although i would probably continue to mirror, so i get usage stats
[14:19] <directhex> i wonder how my download rates are this month
[14:21] <ScottK> persia: Until they sign PPA repos, then they really shouldn't be considered suitable for anything bug testing.
[14:21] <persia> directhex, stats are another thing that was mentioned as possible as part of being first-class, although that might take a while to implement.
[14:21] <persia> ScottK, Right.
[14:21] <ScottK> bug/but, but anyway ...
[14:21] <persia> The decision was made that they get signed and get made first class.  Not done yet, but at least decided.
[14:22] <mok0> persia: If you have a minute? http://pastebin.com/f7f0d7f3f
[14:22] <persia> As a result of the decision, I'm much more opposed to recommending PPAs for test builds, or package reviews than I was before.
[14:22]  * persia should have run out of minutes an hour ago
[14:22] <persia> mok0, What's the question about that?
[14:22] <mok0> I am OK with not including GPL verbatim, but I think its required
[14:23] <mok0> ?
[14:23] <persia> mok0, Not according to http://wiki.debian.org/Proposals/CopyrightFormat
[14:24] <mok0> persia: ... so it needs to be include 1 time
[14:24] <mok0> thx
[14:25] <persia> mok0, Oh, right.  Missed that (see previous not about minutes)
[14:26] <directhex> hm, my usage figures are way down compared to this time last month. i suspect due to people installing intrepid
[14:27] <directhex> not even 6k users, 2/3 of the way though the month
[14:29] <stefanlsd> ScottK: still there?
[14:32] <ScottK> stefanlsd: Yes.
[14:36] <stefanlsd> ScottK: cool. just wanted to ask you re spambayes and the work you did to get the patches unapplying.  The future_import_fix is now inline. which means i dont think we need dpatch and your other changes. i suspect if there are new other dpatch changes, we would like a working dpatch system (your changes).  soo basically, would you prefer a sync and maybe a bug to BTS making it dpatch compatibile, or keep your patch changes?
[14:37] <ScottK> stefanlsd: IIRC there were some changes in my version of the future_import patch that didn't make it into Debian.  I suspect they are not needed and thats the first thing to check.
[14:38] <ScottK> stefanlsd: I don't recall.  Are there other patches in the package?
[14:38] <stefanlsd> ScottK: kk, will confirm re future_import.  there is a spambayes.dpatch but with the original rules and without dpatch build-dep, it does build
[14:40] <ScottK> stefanlsd: In that case (assuming the Debian patch is sufficiently complete) I go with sync and file a wishlist bug with the patch.
[14:40] <stefanlsd> ScottK: yeah, cool. was just writing that
[14:40] <stefanlsd> ScottK: will check and let you know
[14:40] <stefanlsd> heh. crumbs
[14:40] <stefanlsd> http://www.tectonic.co.za/?p=3692
[14:47] <RainCT> siretart: is spooky's connection working fine again?
[14:51] <RainCT> err
[15:18] <jerbear> if i've got a patch to an existing package (network-manager-pptp in this case), how would i go about putting the modified package on my ppa (i already have this setup)?
[15:24] <bain> can some motu take a look at http://revu.ubuntuwire.com/details.py?package=teamgit
[15:24] <bain> it has already received some prilim review :
[15:24]  * mok0 about to review scim-sayure
[15:24]  * mok0 about to review scim-sayura
[15:37]  * mok0 intends to REVU gebabel
[15:39] <ScottK> dholbach: How does HoF determine the sponsorship numbers?
[15:40] <dholbach> ScottK: signed-by on the *-changes + mails on the *-sponsors mailing lists
[15:41] <ScottK> dholbach: Where signed-by != changed-by I guess?
[15:41] <dholbach> ScottK: yeah
[15:42] <ScottK> dholbach: That makes sense.  I do worry a bit that such things as HoF demotivate activities that don't count towards it (HoF makes a statement about what work is important in Ubuntu).
[15:42]  * ScottK wonders how the hour I just spent testing the new kernel in intrepid-proposed moves me towards the HoF?
[15:43] <dholbach> ScottK: right, I got a lot of feedback about what could go on there as well and I'm still thinking about it - I'm happy to change things like the karma numbers for example
[15:43] <dholbach> they're so hard to reach that it's no fun
[15:43] <ScottK> dholbach: I also worry that emphasizing quantity over quality sends a bad message too.
[15:44] <dholbach> right, I was also thinking of things like "random 5 people who did their 5-a-day this week"
[15:45] <ScottK> dholbach: That's another place where I think the quantity thing is biting us.
[15:45] <dholbach> I'm not sure about that
[15:46] <ScottK> I don't have metrics, but I'm pretty certain I see a lot more 'poorly considered' short comments in bugs by people who clearly don't know enough to be triaging that particular bug.
[15:46] <dholbach> look at http://daniel.holba.ch/5-a-day-stats/ - we know most of the people on there quite well
[15:46] <ScottK> I can't say 5 a day is the cause.
[15:46] <dholbach> exactly
[15:46] <dholbach> I agree that there's bad stuff on wikis, forums and in the bug tracker
[15:46] <ScottK> I do think we have a bug triaging problem.
[15:46] <dholbach> and that we should be discussing improving it
[15:47] <dholbach> by training, better documentation and maybe having something like a QA council that can deal with and think about governance issues there
[15:48] <ScottK> dholbach: One thing I've noticed recently is people marking a bug invalid 'because it's already been reported' and not duping to the original bug.  This leaves the reporter of the supposed dupe kind of hanging.
[15:48] <dholbach> yeah, that definitely sucks
[15:49] <dholbach> maybe some kind of 'survey' would help or a canned reply saying "It would have been better to do X instead of Y because Z, do you still remember where you learned about the process of doing X?"
[15:49] <dholbach> or something like that
[15:50] <dholbach> that way we could get to the root of misinformation
[15:50] <dholbach> it clearly needs a multi-pronged approach
[15:50] <dholbach> generally I wouldn't say that the total ratio of "stuff that goes wrong" has increased
[15:51] <dholbach> it was the same in the ubuntu-bugzilla days, but it's just that the number of people involved in the whole project has grown
[15:51] <dholbach> I don't have numbers for that though
[15:51] <james_w> hex version numbers? that's irritating
[15:51] <dholbach> james_w: hm?
[15:52] <james_w> dholbach: sponsor request for 0.8.A of a package when we have 0.8.9
[15:52]  * dholbach shudders slightly
[15:52] <mok0> In watchfiles, do we promote the use of the qa.debian,org php script for sourceforge ??
[15:53] <james_w> mok0: it's automatic
[15:53] <james_w> uscan sees sf.net and replaces it with the qa.debian.org page
[15:53] <mok0> james_w: ah, so you need to use "sf.net" ??
[15:54] <james_w> mok0: line 791 of /usr/bin/uscan
[15:54] <mok0> james_w: thanks
[15:54] <james_w> so yes, I should say automatic for some cases
[15:55] <james_w> can someone confirm for me that 0.8.9 < 0.8.A to dpkg?
[15:55] <mok0> james_w: sorry for being a dud, but how should it appear in watch?
[15:55] <james_w> I'm always concerned about making a mistake with --compare-version
[15:55] <james_w> mok0: http://sf.net/whatever I believe
[15:55] <dholbach> james_w: dpkg --compare-versions 0.8.9 lt 0.8.A && echo TRUE
[15:55] <james_w> mok0: you can of course just use the qa.debian.org page directly
[15:56] <james_w> dholbach: thanks for confirming
[15:56] <dholbach> de rien
[15:56] <mok0> james_w: yes, there I know how the search string should look like...
[15:58] <james_w> dholbach: does the hof just look for signed-by != changed-by on the sponsors' lists?
[16:00] <dholbach> james_w: yeah
[16:01] <james_w> dholbach: if it looked on the -changes lists it would mean that it would catch the cases where a sponsorship bug is not used, which I expect is common in some cases. Would there be a downside to doing that?
[16:02] <dholbach> hum, not sure
[16:14] <eMerzh> if someone want to review my just updated package...it's waiting on http://revu.ubuntuwire.com/details.py?package=sqliteman ... thanks :)
[16:26] <siretart> RainCT: schould be. it works at least for me
[16:31] <eMerzh> handschuh: I've just correct my package....i've add Copyright everywhere and it works for me
[16:31] <handschuh> eMerzh: great, so the lintian on the binary is empty?
[16:32] <eMerzh> handschuh: no warning..just info :)
[16:32]  * mok0 is about to REVU tomboy-blogposter
[16:33] <eMerzh> handschuh:  no errors neither
[16:34] <handschuh> eMerzh: good thing! you also fixed the small things i mentioned, so the package looks very good to me
[16:34] <mok0> (even though I don't approve of Mono, as observant readers of the ML will have noticed...
[16:35] <eMerzh> handschuh:  cooool :D happy to read it :)
[16:35] <laga> mok0: are you morten?
[16:35] <mok0> Yes
[16:35] <laga> mok0: good job on that mail. YMMD ;)
[16:36] <handschuh> eMerzh: good job!
[16:36] <mok0> I got trashed
[16:37] <handschuh> eMerzh: has upstream answered to you?
[16:38] <eMerzh> handschuh: yes ...he is workin on it....
[16:39] <handschuh> eMerzh: great, then you should add this as a comment @ revu so that other reviewers will not complain about this
[16:39] <eMerzh> handschuh: done :)
[16:40] <eMerzh> \me is now looking for Advocate :)
[16:41]  * eMerzh is now looking for Advocate :)
[16:41] <handschuh> eMerzh: ok good. so now you can do nothing else except waiting ... or better: prepare your next package  ;-)
[16:42] <eMerzh> handschuh: héhé .... thanks for your help anyway :)
[16:42] <handschuh> eMerzh: you're welcome
[16:52]  * mok0 about to review docang-theme...
[16:53]  * mok0 is wondering whether persia managed to review the supercollider thingie
[16:54]  * handschuh cheers on mok0 for beeing so industriously
[16:54]  * mok0 hugs handschuh
[16:54]  * handschuh hugs mok0 back
[17:02]  * mok0 is about to REVU dodol-theme
[17:05]  * RainCT tells mok0 that he rocks ;)
[17:06]  * mok0 is struggling to have more reviews that RainCT ;-P
[17:06] <mok0> /s/that/than
[17:06] <mok0> Only 4 to go...
[17:07] <RainCT> mok0: uhm.. where are you looking? :P
[17:08] <mok0> RainCT: http://revu.ubuntuwire.com/stats.py
[17:09] <RainCT> mok0: 133-107 isn't 4 :P
[17:09]  * mok0 is struggling to have more reviews than dktrkranz :-P
[17:09] <mok0> my bad
[17:09] <RainCT> ah :)
[17:09] <mok0> No hope of getting above 2nd place though
[17:10] <RainCT> lol
[17:10] <mok0> persia rules
[17:10] <RainCT> yeah, it's difficult to beat robots :P
[17:10] <mok0> LOL
[17:10] <RainCT> although, he's going to holiday.. so now I only need to see him laugh and he will have proved that he's human ;P
[17:11] <sebner> RainCT: at least he uses smilies. bot's with smilies? ^^
[17:12] <RainCT> he does?
[17:12] <RainCT> well, my previous IRC bot used smilies too ^^
[17:12] <sebner> RainCT: even good ones like :)
[17:12] <sebner> heh
[17:13]  * RainCT goes to review gnome-video-arcabe before mok0 get's a chance to beat me :P
[17:13] <mok0> Yikes
[17:13]  * mok0 is about to revu mac4lin-gdm-themes
[17:14] <RainCT> wah, someone stop him! *g*
[17:14]  * handschuh is even more impressed by todays attitude
[17:14] <mok0> ... working mechanically  from the top...
[17:14]  * RainCT can't parse that sentence
[17:14] <RainCT> mok0: good, persia will love you :)
[17:14] <RainCT> I shall do that to, once I finish with the REVU Day targets
[17:15] <RainCT> *too - my English is awful today :P
[17:15] <mok0> RainCT: ... well, not quite the top, since persia said he was reviewing the supercollider thing
[17:15] <RainCT> btw guys, feel free to update https://wiki.ubuntu.com/MOTU/Headers/NextREVUDay if I forget to do so :P
[17:16] <DktrKranz> mok0: argh! :)
[17:16]  * RainCT throws a REVU url at DktrKranz 
[17:16]  * DktrKranz hasn't a browser, but will have tonight
[17:17]  * RainCT wonders what DktrKranz is using :P
[17:17] <RainCT> (just curiosity, I'm fine with tonight :))
[17:17] <handschuh> isn't there an option to automatically export the next revu date from revu onto the wiki?
[17:17] <DktrKranz> RainCT: blocked by a strict firewall
[17:18] <RainCT> handschuh: REVU takes it from the wiki
[17:18] <handschuh> RainCT: ok, great
[17:18]  * handschuh hates redundant data
[17:18] <RainCT> and I don't feel like writing a script to edit it automatically (would probably take more time than I need to change it myself :P)
[17:18] <RainCT> DktrKranz: that sucks :(
[17:21] <DktrKranz> RainCT: we're under a multinational, and connections are proxied by their server, which blocks HTTP traffic, only SMTP/SSH is allowed
[17:21] <DktrKranz> so, I tunnelled irc traffic ;)
[17:22] <RainCT> And w3m/elinks over SSH? *g*
[17:22] <RainCT> ok.. you can't really what you get with that a web :P
[17:25] <DktrKranz> RainCT: exactly ;)
[17:28]  * DktrKranz kills asterisk
[17:30] <RainCT> longtitle="Play classic arcade games"   is that appropiate in a .menu file?
[17:32]  * RainCT reviews alarm-clock-applet
[17:33] <eMerzh> \me is now looking for Advocate or comments (http://revu.ubuntuwire.com/details.py?package=sqliteman)...RainCT if you are in a reviewing mood...your welcome :p
[17:37]  * RainCT asks for feedback on the get-orig-source rule from http://revu.ubuntuwire.com/revu1-incoming/alarm-clock-applet-0808280150/alarm-clock-applet-0.2.4/debian/rules
[17:38] <RainCT> the last line is evil, isn't it?
[17:38] <mok0> eMerzh: what's with the legal issue?
[17:39] <eMerzh> mok0: upstream autor was contacted to correct issues...he answer that he is workin on it....
[17:39] <mok0> eMerzh: ... shouldn't we wait for that to be resolved?
[17:40]  * mok0 is not going to help RainCT maintain his reviewing lead :-P
[17:40] <eMerzh> mok0: legal issues are minors i think no? like old fsf address in sources , ....
[17:40] <mok0> eMerzh: ah
[17:40] <RainCT> mok0: *g*
[17:41] <mok0> RainCT: ... but more likely I'm fading... what's wrong with that rule, doesn't it work?
[17:41] <RainCT> mok0: it recompresses the tarball
[17:42] <RainCT> which changes the checksum, iirc..
[17:42] <mok0> RainCT: ah, yes, that's kinda redundant...
[17:43] <mok0> The policy is to use gzip -9 mode, but that's not mandatory for pristine tarballs afaik
[17:44] <RainCT> bah I can't find anything else wrong
[17:44] <mok0> RainCT: advocate it
[17:45] <mok0> RainCT: next advocate can remove that before upload
[17:46]  * RainCT needs to test-build and test-install it first.. but this isn't funny :P
[17:47] <mok0> RainCT: yeah, I wonder why anyone wants to be MOTU
[17:47] <RainCT> heh
[17:47]  * mok0 is about to review sqliteman
[17:48]  * RainCT looks at mac4lin-icons while pbuilder updates
[17:48] <mok0> ... breaking the tedious top-to-bottom processing
[17:49] <RainCT> mok0: people who ask on IRC have priority ;)
[17:49]  * handschuh is glad about this
[17:49] <mok0> RainCT: yeah, but these guys are spoiled... they've been hanging around for days :-)
[17:50] <RainCT> btw, can a pbuilder tgz be converted to cowbuilder?
[17:50] <eMerzh> \me thanks mok0 for watching :)
[17:50] <mok0> Hmm, what's in the sqliteman tarball... ETA is going UP??
[17:52] <rugueux> does anyone know how to compile a java source with a build.xml (I suppose from eclipse) ?
[17:52] <fabrice_sp> Hi. Can someone review dvdstyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler)? It's also built in my ppa. Thanks
[17:52] <james_w> rugueux: ant is the tool to build from a build.xml
[17:53] <slytherin> rugueux: why do you need eclipse for that?
[17:54] <rugueux> I don't know, i've just searched around, and found that build.xml is created by eclipse
[17:54] <rugueux> I won't to find how to compile it, in order to package
[17:54] <rugueux> wan't
[17:54] <fabrice_sp> Hi james_w: about Bug #296618. What do you mean by transitional package?
[17:54] <handschuh> rugueux: first of all, install ant
[17:54] <rugueux> I've install the package libantlr-java, but could not find the ant binary, where is it ?
[17:55] <eMerzh> mok0: sorry but what did you mean by "eta"?
[17:55] <mok0> "Expected Time of Arrival"
[17:55] <mok0> eMerzh: but I got it now
[17:55] <james_w> fabrice_sp: what in your proposed package causes someone with icedove-dispmua to end up with dispmua installed?
[17:56] <handschuh> rugueux: the package you need is named "ant" (nothing more)
[17:56] <rugueux> handschuh thank u, I'll try right now
[17:57] <fabrice_sp> james_w: I explicitly put conflicts and replaces lines in control file, and I checked that with thunderbird-dispmua installed, I ended with dispmua installed
[17:57] <fabrice_sp> after a apt-get update / upgrade
[17:57] <james_w> odd
[17:58] <slytherin> rugueux: build.xml is java world analogous to Makefile
[17:59] <fabrice_sp> odd? It shouldn't have worked?
[17:59] <RainCT> those mac4lin packages scare me :P
[18:01] <slytherin> !sru
[18:01]  * RainCT rejects -icons with licensing complaints :P
[18:04] <RainCT> mok0: yeah, found another problem with alarm-clock-applet! :P
[18:05] <mok0> RainCT: it doesn't build?
[18:05] <RainCT> mok0: It does. The name of file debian/*.manpages is wrong
[18:06] <mok0> RainCT: ah, nice catch
[18:15] <slytherin> When does the sync from Debian happen in a day? Is it once a day?
[18:17] <mok0> eMerzh: done
[18:17]  * mok0 goes to pick up a pizza now...
[18:17] <rugueux> compiling the java source is failing because missing jdesktop files, I've installed libjdic-java, but still not working ? any ID ?
[18:17] <eMerzh> mok0: thanks
[18:17] <mok0> eMerzh: you're welcome
[18:18] <handschuh> rugueux: I have to go home now, but then I will help you if noone else does it until then
[18:18]  * handschuh finally goes home
[18:19] <slytherin> rugueux: what are you trying to compile?
[18:21] <rugueux> a jar file from a gui-application...
[18:22] <slytherin> rugueux: which application? where did you get the source?
[18:22] <rugueux> http://www.homeopathyonline.org/download_OpenRep.html
[18:29] <fabrice_sp> james_w: I just made another test, and you're right: dispmua (the new package) doesn't install automatically. I think I install it from a local package, and when updating from ppa, It installed the latest and desinstall the old one. So what do you recommendme: keep the old name or create a transitional package?
[18:30] <james_w> create a transitional package
[18:30] <james_w> why is your new package called "dispmua"
[18:31] <fabrice_sp> Because I packaged other thunderbird plugin, and I've been requested each time to delete 'thunderbird' from package name
[18:31] <fabrice_sp> (like itsalltext or vimperator)
[18:31] <fabrice_sp> That's why I wanted to follow the same rule with dispmua
[18:32] <fabrice_sp> is it a bad idea?
[18:34] <eMerzh> mok0: when you said README.source is redundant. ...should i remove it?
[18:34] <mok0> yes
[18:35] <james_w> fabrice_sp: ok, that's fine
[18:35] <RainCT> mok0: you dislike README.source, too? :)
[18:35] <slytherin> rugueux: looks like it can be compiled only from netbeans. Tell them to release with a build.xml that is not dependent on an IDE.
[18:35] <mok0> heh,depends... if it doesn't contain any useful inormation...
[18:36] <RainCT> wuahahaha.. 21 comments more and I'll beat ScottK :P
[18:36] <mok0> It's just one more file to maintain, and README.source tends to go out-of-date quickly
[18:36] <fabrice_sp> Can someone point me to how creating a transitional package to migrate from thunderbird-dispmua to dispmua? I've some idea but I'd prefer to follow some rules
[18:36] <mok0> Go, RainCT!!
[18:37]  * RainCT laughs at the current "Next REVU Day" text on REVU
[18:37] <rugueux> slytherin, thank u, I'll try to ask them
[18:37]  * RainCT fixes it
[18:43] <ScottK> RainCT: On what?
[18:46]  * mok0 will be afk for a while
[18:50] <JonReagan> yipeee... fixed all the problems (problems, so far) in my package!  I can has REVU? :)  It's the openproj package... http://revu.ubuntuwire.com/details.py?package=openproj
[18:54] <fabrice_sp> james_w: just uploaded a new debdiff in Bug #296618 with the transitional package. Can you have a quick look, and tells me if it looks good? Thanks.
[18:55] <james_w> fabrice_sp: changelog entry for the transitional package missing
[18:56] <james_w> do you not want to capitalise thunderbird in the short description?
[18:56] <james_w> transitional package should be icedove- not thunderbird- shouldn't it?
[18:57] <fabrice_sp> james_w: the intrepid package has been named thunderbird-
[18:57] <fabrice_sp> (I changed the name for Intrepid, has it ws a FTBFS)
[18:57] <james_w> oh yeah, sorry
[18:57] <james_w> not sure the section is correct
[18:57] <handschuh> rugueux: could your problem be solved?
[18:58] <james_w> you need Conflicts/Replaces as files are moving between packages
[18:58]  * handschuh follows mok0's example and eats a pizza
[18:59] <slytherin> JonReagan: I was going to try building your package, but looks like it will take me at least 1 hour, after that I will add comments.
[18:59] <james_w> is the priority different to the other package? if not then don't put make it explicit
[18:59] <fabrice_sp> james_w: about section: I copy it from another package. And I will put back Conflicts/Replaces also. What do you mean capitalise thunderbird in the short description?
[18:59] <james_w> fabrice_sp: I'm done for the day, I'll look at any debdiff on the bug next time I'm around
[18:59] <fabrice_sp> ok
[18:59] <fabrice_sp> thanks!
[18:59] <james_w> you've changed "Icedove" to "thunderbird"
[19:00] <james_w> do you not want "Thunderbird"?
[19:00] <fabrice_sp> ahhhhh: sure
[19:00] <JonReagan> thanks slytherin
[19:00] <fabrice_sp> It's only a languaqe problem :-)
[19:00] <fabrice_sp> thanks again james_w
[19:01] <DktrKranz> RainCT, now I've got a browser, have some cool packages? ;)
[19:08] <RainCT> DktrKranz: https://wiki.ubuntu.com/REVUDays :)
[19:09] <DktrKranz> thanks
[19:09] <RainCT> ScottK: REVU Ranking ("Statistics" menu entry) :P
[19:12] <ScottK> RainCT: How about a stat for most times found something wrong after another MOTU had advocated (MOTU comment follows an advocation, but doesn't advocate)?
[19:14] <RainCT> ScottK: uhmmm.. perhaps once neutral comments are implemented, but I'm not very fond of this
[19:26] <bmm> I'm trying out CDBS, just for the fun of it, and debuild gives me a problem with install-info: too many arguments. I have debian/lzip.info with one line containing "doc/lzip.info" which is an info file. What is going wrong?
[19:27] <bmm> This is the output: http://pastebin.com/m7645ca1f
[20:22] <slytherin> geser: Just FYI ... I am still working on libjdic-java. I hope to have it fixed by tomorrow.
[20:28] <fabrice_sp> Somebody knows why I'm getting that in REVU, in legal link:
[20:28] <fabrice_sp> /var/revu/revu1-incoming/dvdstyler-0811190636/dvdstyler-1.7.1/src/Utils.h: UNKNOWN
[20:28] <fabrice_sp>   [Copyright: Alex Thuering]
[20:29] <fabrice_sp> in the sourc efile, it's references GPL
[20:30]  * mok0 is about to review mac4lin-splash
[20:31] <superm1> slytherin, did you ever sort out that issue with nautilus-sendto?
[20:32]  * mok0 is about to review glusterfs
[20:32] <slytherin> superm1: nope, sorry. :-(
[20:33] <slytherin> superm1: was busy after that with work. Haven't really found time to look into bluetooth again.
[20:33] <superm1> that's a shame.  could you keep an eye on upstream then at least and see if they ever end up rev'ing it with a fix themselves?
[20:33] <slytherin> superm1: sure.
[20:34] <bmm> Could somebody look at http://pastebin.com/m7645ca1f and tell me why the install-info gives an error and why it is ignored by CDBS ?
[20:42]  * mok0 about to review bitmeter
[20:43] <fabrice_sp> bmm: install-info only needs a filename, and you are giving him a filename and a directory
[20:43] <fabrice_sp> mok0: not willing to review dvdstyler? ;-)
[20:43] <mok0> fabrice_sp: ok
[20:44] <bmm> fabrice_sp: currently, I have a debian/lzip.info file which mentions "doc/lzip.info" in a single line. The rest is all default dh_make with CDBS enabled. So what might be causing this problem?
[20:45] <bmm> fabrice_sp: I'll put it on REVU, maybe that can show me the error of my ways ;) I'll post back when it's there. Thanks for you response!
[20:46] <fabrice_sp> bmm: ok. I'm not an expoert on CDBS myself, but will try to help :-)
[20:47] <bmm> fabrice_sp: first time for me also, so I have no idea what all those defaults are doing.. let only what is happening if they don't ;)
[20:48] <fabrice_sp> bmm: that's why I don't like that 'automatic' things. I prefer to understand how things work, even if it's more manual ;-)
[20:48] <slytherin> mok0: openproj got review from java centric reviewer. :-)
[20:49] <mok0> slytherin: great!
[20:49] <slytherin> JonReagan: reviewed openproj. You have got at least 2 days of work ahead. :-)
[20:49]  * mok0 hugs JonReagan
[20:50]  * mok0 need to update builder
[20:51]  * slytherin resumes watching movie
[20:53] <bmm> fabrice_sp: it's now on REVU, here: http://revu.ubuntuwire.com/details.py?upid=4084 with a small lintian error on the standards version.
[20:53] <bmm> Maybe the error is actually normal behavior
[20:53] <fabrice_sp> bmm: will check :-)
[20:54] <fabrice_sp> bmm: lintian error is because of out-of-date standard. Nothing to do with CDBS
[20:57] <fabrice_sp> trying to build the package here, in Intrepid
[20:57] <mok0> fabrice_sp: is dvdstyler in lenny?
[20:58] <fabrice_sp> mok0: no. It's only the upstream changelog that comes with that (you can download the package from sourceforge)
[20:59] <fabrice_sp> upstream provides a debian directory
[20:59] <mok0> fabrice_sp: ah, ok. You need to get rid of the by repackaging the tarball
[20:59] <mok0> get rid of that
[20:59] <mok0> fabrice_sp: we don't want upstreams changelogs
[21:00] <mok0> fabrice_sp: debian/changelog that is
[21:00] <fabrice_sp> mok0: ok. So I repack the tarball, to get rid of all the debian directory or only the changelog?
[21:00] <mok0> fabrice_sp: we _do_ want the ordinary Changelog
[21:00] <mok0> fabrice_sp: the whole debian/
[21:00] <fabrice_sp> of course :-)
[21:00] <fabrice_sp> ok
[21:01] <fabrice_sp> mok0: thanks for taking time to review the package! :-)
[21:01] <mok0> fabrice_sp: ok, I'll carry on, assuming that you take over the debian/ that is in the package.
[21:01] <mok0> fabrice_sp: when you build the source package, debian/ will end up in the diff.gz
[21:01] <fabrice_sp> mok0: will do (I'm repacking the tarball right now :-) )
[21:02] <mok0> fabrice_sp: so, you will need a "get-orig-source" target in rules to create the repackage tarball
[21:03] <JonReagan> oh. geez.. shoulda stuck to the list... thanks slytherin... what work needs to be done?
[21:03] <RainCT> bmm: I think CDBS just calls dh_installinfo
[21:04] <JonReagan> ah, now I see, thanks for the comment
[21:04] <RainCT> bmm: (and I have no idea what info files are, so I can't help)
[21:04] <fabrice_sp> mok0: this will allow to download the source again, right?
[21:05] <fabrice_sp> mok0: ok. Found a wiki page explaining that ;-) Thanks
[21:05] <mok0> fabrice_sp: you have the watch file to download the upstream tarball. Then you have the get-orig-source rule to repackage it
[21:05] <bmm> RainCT: that is the weird thing, I thought I did it the way dh_installinfo wants me to, but I still get this error. Maybe I just did everything the way I should ;)
[21:06] <mok0> fabrice_sp: If you are smart, you can make fancy tricks with the watch file to make it call the repackage command after downloading.
[21:07] <fabrice_sp> mok0: I would say skilled, and not only smart :-)  Will look for other packages to see how to do that :-)
[21:08] <mok0> fabrice_sp: If you like, it's not required  though
[21:09] <mok0> fabrice_sp: If you get hit by a bus (God forbid) the new maintainer needs to be able to do what you have done
[21:10] <fabrice_sp> mok0: I like the idea of doing smart things, but not of being hit by a bus :-)
[21:10]  * mok0 nods
[21:22] <mok0> fabrice_sp: comments ready
[21:23] <fabrice_sp> mok0: great! Thanks for your time :-)
[21:23]  * mok0 about to review bitmeter
[22:25]  * bmm is loving the fact that his PPA support Jaunty and he can go do both REVU and PPA at the same time.
[22:31] <NCommander> RainCT finally turned on that code
[22:31] <NCommander> w00t
[22:32]  * NCommander doesn't see the package importer ...
[22:34]  * bmm made that same Maintainer: field mistake AGAIN and can't understand why no automated system points that out on REVU
[22:35] <RainCT> bmm: which mistake, listing yourself as Maintainer?
[22:35] <bmm> RainCT: yep, not mentioning MOTU
[22:35] <RainCT> it's easy to add a check for that.. which addresses are allowed there, only @ubuntu.com or was there something more?
[22:36] <bmm> Well, if REVU is only used for MOTU development, then a check on the mention of Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> in control would help
[22:37] <RainCT> bmm: no, people are allowed to list themselves if they want and they have an @ubuntu.com
[22:37] <bmm> Then "@(.+\.)?ubuntu.com" might help?
[22:38] <RainCT> and there are also teams and stuff (well, not sure if there's any team right now using their ML as Maintainer in Ubuntu, but that's certainly allowed)
[22:38] <RainCT> bmm: that's not the problem, the question is if it's only @ubuntu.com or something else.. because I think there was something more
[22:38] <RainCT> but perhaps I dreamed that :P
[22:39] <bmm> RainCT: at least "lists.ubuntu.com" but for the rest I don't know, sorry.
[22:39] <RainCT> uhm.. the wiki only says ubuntu.com
[22:40]  * RainCT add a check
[22:40] <bmm> maybe conanical.com or something like that? I don't know, but it might be good to just make it a warning ;)
[22:44] <nhandler> If a MOTU Acked a Sync request (for a package in Universe), but forget to set the status to 'Confirmed', is it ok for me to do it?
[22:45] <RainCT> nhandler: presumably
[22:47]  * nhandler goes to review a few packages on REVU before dinner
[22:49] <RainCT> bmm: done, REVU will show a warning now
[23:05] <NCommander> And I'm off to dinner
[23:07] <directhex> this sounds quite daft when i type it: "i have root on over a million and a half pounds of computers"
[23:25] <nhandler> If a person packages an application for a PPA, how should they be recognized if another person takes their package and tries to get it through the REVU process? Should they be listed as the person who debianized the application in debian/copyright?
[23:27] <ScottK> nhandler: If their package was mostly correct, then I'd say yes.
[23:29] <nhandler> ScottK: Ok, but what about the XSBC-Original-Maintainer and the Debian Packaging Copyright? Should those be for the person sending it through REVU or the person who originally packaged it for the PPA?
[23:29] <ScottK> Copyright is a function of who did the work, so the original guy and the new person can list themselves if they view their contribution as significant.
[23:29] <ScottK> I'd say original maintainer is the guy bringing it to REVU.
[23:30] <nhandler> Ok, thanks a lot ScottK
[23:30] <directhex> ScottK, how about if you start with someone else's package, and every single file you go to improve you end up needing to rewrite due to crap packaging?
[23:31] <ScottK> directhex: I'd still list both in debian/copyright. Unless you start from a clean room, it's a derivative work.
[23:32] <directhex> ScottK, okay, good, that's what i've done
[23:33] <directhex> though i plan on rewriting the package description to remove retarded appeasements I put in due to an unnamed DD moaning. fsck him, right in the ear. it's ftpmaster's call, not his, on whether the description is good enough
[23:34] <slytherin> Does anyone have any idea what could be wrong here - http://paste.ubuntu.com/75453/
[23:34] <laga> directhex: CoC FTW :)
[23:34] <mok0> Anyone has an example of how a Launchpad watch file should look like?
[23:35] <ScottK> directhex: If he's going to sponsor it, it's his call.  You can always find another sponsor.
[23:35] <directhex> ScottK, no, he'd never sponsor it. he'd not only like the package never to see the archive, but for me to be shot into the sun for suggesting it
[23:36] <slytherin> directhex: you are still stuck at the same issue?
[23:36] <ScottK> Ah.  I see.  Well he's entitled to that opinion too.
[23:36] <nhandler> mok0: Look at the uscan man page. It shows a few examples.
[23:37] <mok0> nhandler: ah.. now why didn't I think of that...
[23:37] <mok0> nhandler: thx
[23:37] <nhandler> mok0: http://manpages.ubuntu.com/manpages/intrepid/en/man1/uscan.html
[23:37] <nhandler> np mok0
[23:37] <directhex> ScottK, well, of course. but some topics inspire demagogy, and if attempting to meet in the middle doesn't go anywhere, i fail to see why i should continue user-unfriendly self-gimping
[23:37] <slytherin> mok0: why should launchpad be any different from any other site?
[23:37] <mok0> slytherin: I dunno... getting tired I suppose
[23:38] <directhex> slytherin, which issue are we talking about today? being shot into the sun? well, due to alpha1-induced boredom, i accused the guy behind boycottnovell of libel, for saying i was getting paid off by someone for working on mono packaging
[23:38] <ScottK> slytherin: Launchpad usually is (different).
[23:38] <mok0> slytherin: also LP has version numbers in the path
[23:39] <ScottK> directhex: Why would it be libel?  Would it be bad to get paid?
[23:39] <slytherin> directhex: I thought you were talking about the moonlight plugin
[23:39] <directhex> slytherin, good guess! i was! want a cookie? i have a spare one here
[23:40] <slytherin> directhex: nah, use it while your work on mono packages. :-)
[23:40] <directhex> ScottK, "They need Mono.. they do it for a living and the poison the most-used distro"
[23:40] <directhex> slytherin, i'm blocked on alpha 1 - though i'm arguing with upstream that they should really release a new tarball real soon now so i can get it into jaunty asap
[23:41] <directhex> slytherin, want to be certain moon is offered by the plugin finder service - though due to JS nastiness, that may need some extra magic. where's asac hiding...
[23:43] <slytherin> mok0: any sample url?
[23:43] <mok0> Arch, I can
[23:43] <mok0> can't get it to work...
[23:43] <ScottK> directhex: Ugly, but unlikely to be actual libel (at least as I understand it in most US jurisdictions).
[23:43] <mok0> http://pastebin.com/f3f898424
[23:43] <directhex> ScottK, fortunately, BN's main muckraker is in britain, and britain has mad libel laws that mean you can sue left right & center
[23:44] <directhex> it's actually common enough for people in other countries to sue you in britain, because they know they'll win - if your content can be accessed in any way within the isles, it counts
[23:44] <lfaraone> james_w: is bzr-builddeb ready for use in actual packages yet?
[23:44] <lfaraone> (how can I use bzr to maintain packaging)
[23:45] <ScottK> Yes.  I've heard that.  Then he ought to be more careful.
[23:46] <RainCT> good night
[23:47] <ScottK> Good night RainCT
[23:47] <directhex> nighty night, sweet RainCT
[23:47] <mok0> Good night RainCT
[23:47] <nhandler> Night RainCT
[23:47] <laga> good night RainCT
[23:48] <RainCT> wow, best answer ever :P
[23:48] <directhex> man, if i thought i'd get this sort of reaction, i'd announce sleepytime more often
[23:48] <laga> i'm going to go to bed, too
[23:48]  * laga wonders what's gonna happen
[23:48] <RainCT> good night laga :)
[23:48] <laga> yay. :)
[23:48] <laga> g'night
[23:51] <slytherin> mok0: I guess bluez package has some sort of html parsing to retrieve download url from the page. See if that helps.
[23:51] <slytherin> mok0: I mean the watch file in bluez.
[23:51] <mok0> slytherin: I figured out the problem. The second "https" should be a "http"
[23:51]  * mok0 sighs
[23:52] <mok0> slytherin: but now hear what it says: "remote site does not even have current version" :-)
[23:53] <slytherin> mok0: that is probably because your expression is wrong
[23:54] <mok0> slytherin: no, it's because the package version is 0.1.0 and the upstream tarball is 0.0.5
[23:54] <slytherin> mok0: I guess it should be ([\d.]+)
[23:54] <directhex> mok0, why?
[23:55] <mok0> directhex: why what?
[23:55] <directhex> why is the package 0.1.0 if upstream tar is 0.0.5?
[23:55] <mok0> Newest version on remote site is 0.0.5, local version is 0.1.0
[23:55] <mok0> Perhaps they changed the numbering scheme?
[23:56] <directhex> how silly
[23:56] <mok0> ... or perhaps he meant 0.0.1 ??
[23:56] <mok0> I will let uploader explain this mess...
[23:59]  * mok0 calls it a day after 16 REVUs today.
[23:59] <nhandler> mok0: You are a REVU beast
[23:59] <handschuh>  mok0: great job!
[23:59] <mok0> We're almost through July
[23:59] <mok0> Thanks guys!