[04:28] <paultag> Any DDs around to review ( and upload if you're feeling rowdy ) a small package I maintain? It fixes two bugs, package is not in Testing, only Unstable.
[04:29] <paultag> My mentor is out for a few weeks -- I put the dsc on my personal server ( that's how we usually work ) -- http://me.pault.ag/fbautostart_2.7182-2.dsc
[04:29] <paultag> pbuilds fine, ran lintian with --pedantic, came out great.
[04:29] <persia> You might also want to try #debian-ubuntu@OFTC
[04:30] <paultag> persia, I don't like bugging them, seems like it's usually quiet in there, and I don't want to get everyone awake for such a small package :)
[04:31] <persia> Folk read backscroll, and there's a greater concentration of DDs there than here :)
[04:31] <persia> Since it's not -mentors, you won't even be repeating yourself
[04:31] <paultag> persia, cool. Cheers, thanks
[06:49] <dholbach> good morning!
[08:24] <hrw> hi
[08:54] <Rhonda> I guess it's fine to remove jaunty from wiki.ubuntu.com frontpage in the supported release section?
[08:55]  * Rhonda . o O ( done )
[09:12] <persia> Rhonda, Indeed, it ought be fine to do so.
[11:41] <ari-tczew> ScottK: got a time today?
[11:42] <ScottK> Probably, but not for at least an hour.
[12:02] <ari-tczew> ScottK: got a time today?
[12:04] <Rhonda> That were only 20 minutes.
[12:05] <persia> Indeed.
[12:07] <\sh> ari-tczew: you queried me
[12:14] <ari-tczew> \sh: that's right, I wanted to ask about depends on firefox | abrowser | www-browser, but chrisccoulson answered to me yesterday on mozilla team channel. The merge is here: https://launchpad.net/ubuntu/+source/wysihtml/0.13-5.1ubuntu1
[12:15] <ari-tczew> Rhonda: hmmm, I lost my internet connection 35 minutes ago. I didn't know whether my question has been sent.
[12:16] <\sh> ari-tczew: oh well, I'm not the right person for <insert your fav browser package here> ;)
[12:16] <ari-tczew> \sh: but you put this depends to package, so I would ask you.
[12:16] <Rhonda> ari-tczew: That's what the irclogs are useful for, to check. :9
[12:17] <Rhonda> ari-tczew: http://irclogs.ubuntu.com/2010/11/03/%23ubuntu-motu.txt
[12:18] <\sh> ari-tczew: ah...that was long time ago..and actually, we are shipping firefox / mozilla foo instead of debians iceweasel/ape/snake/dog/foo ;)
[12:18] <ari-tczew> thanks Rhonda. probably I lost connection after my message. really 16/1 mbit is not enough? :)
[12:18] <Laney> doesn't firefox Provide: iceweasel?
[12:19] <\sh> Laney: in old times no...I think I touched it during gutsy cycle...so long time ago
[12:19] <Laney> probably makes more sense for it to provide abrowser anyway
[12:19] <Rhonda> \sh: It's not "debian's". The reason for the renaming was to unbrand it, not to debian-brand it.
[12:19]  * Laney has thought about this not at all
[12:20] <\sh> Rhonda: yes..but regarding upstream of ubuntu == debian ;) that's what I wanted to say...:)
[12:20] <persia> Rhonda, While that was the rationale, has anyone else (excluding Debian derivatives) adopted that?
[12:23] <ScottK> persia: If others had it would then be an alternative brand, not an unbrand, so I think that's beside the point.
[12:25] <persia> ScottK, I agree it's beside the point of Debian rebranding it, but I think it may be the source of the perception that it is a Debian brand.
[12:25] <Rhonda> persia: Well, ubuntu did unbrand it to "abrowser" in the beginning, and I didn't follow what other distributions did.
[12:25] <persia> And I ask out of genuine curiosity, rather than in an attempt to suggest Rhonda is misinformed (as this is clearly not the case)
[12:27] <persia> "abrowser" is still about, and suffers from the same issues (although because the patchset/branding for abrowser differs from that of iceweasel, they oughtn't have the same name)
[12:28] <\sh> is someone firm with python setuptools and why it doesn't execute install_data action during install anymore, when you overwrite it with your own class?
[12:28] <ScottK> OK.  I read that as "the change Debian made" rather than Debian's brand.
[12:28] <ScottK> \sh: I think barry is your man for that question.
[12:28] <directhex> IceWeasel(tm)(r)
[12:29] <\sh> ScottK: thx :)
[12:30] <ScottK> ari-tczew: What's up?
[12:30] <persia> directhex, Actually, precisely the opposite.
[12:31] <ari-tczew> ScottK: could you take a look is package ttf-ubuntu-title mergeable?
[12:31] <ScottK> ari-tczew: Do you have a proposed merge?  Last time I looked it made my head hurt.  It wasn't clear to me if Debian or Ubuntu had the correct source.
[12:32] <ari-tczew> ScottK: No, I don't. I'm also confused what's going there.
[12:32] <ScottK> ari-tczew: I think the first question is to establish what's the authoritative upstream for the package.  This will take a bit of detective work.
[12:34] <ari-tczew> mhm
[13:00] <zesoze> hi where can I get help  for Makefile?
[14:28] <ari-tczew> crimsun: ping
[15:32] <ari-tczew> DktrKranz: could you take a look on merge package hp-ppd - is it merge or sync?
[15:34] <DktrKranz> ari-tczew: hp-ppd is unmergeable, IIRC
[15:34] <ari-tczew> DktrKranz: due to versions in debian/changelog?
[15:36] <DktrKranz> exactly: dpkg --compare-versions 0.9-0.1 gt 0.9ubuntu2; echo $? => 1
[15:37] <DktrKranz> and, IIRC, ubuntu2 alreaedy has the NMU included
[15:41] <ari-tczew> ok thanks. I must report a bug against MoM - blacklist merges
[15:50] <eolo999> hi, how do i get a list of open bugs related to python packages?
[15:51] <ScottK> eolo999: Look for the ~pythonistas and ~pythoneers teams in Launchpad and the bug lists for each.
[15:52] <eolo999> thx
[15:52] <eolo999> ;)
[15:55] <eolo999> ScottK: 2 bugs there (pythonistas+pythoneers), am I wrong?
[15:55]  * ScottK looks
[15:56] <eolo999> ok found
[15:56] <eolo999> i have to list subscribed packages
[15:56] <ScottK> Looks like you have to do https://bugs.launchpad.net/~pythonistas/+packagebugs
[15:56] <ScottK> Yes.
[15:58] <bilalakhtar> ScottK: Are the ~python{istas,eers} subscribed to ALL python packages?
[15:59] <ScottK> bilalakhtar: No.  They are subscribed to the ones doko and myself noticed.  If some need adding, let me know.
[15:59] <bilalakhtar> okay
[17:10] <ari-tczew> cjwatson: could you take a look, whether if you delete package hp-ppd, does MoM will regenerate again?
[17:24] <cjwatson> ari-tczew: what's wrong with it?
[17:25] <ari-tczew> cjwatson: http://irclogs.ubuntu.com/2010/11/03/%23ubuntu-motu.html#t15:32
[17:25] <ari-tczew> due to mistake versions in d/changelog. similiar case as with ilohamail
[17:26] <cjwatson> I don't see why asking MoM to regenerate would make the slightest bit of difference
[17:26] <cjwatson> perhaps I'm not understanding your question
[17:27] <ari-tczew> cjwatson: we can't merge this one. I want to hide it on MoM.
[17:27] <ari-tczew> cjwatson: and some packages needs hide as well
[17:27] <cjwatson> the bit of your question that confused me was "does MoM will regenerate again?"
[17:27] <cjwatson> if your request is to get rid of hp-ppd from the merge list, then I can do that
[17:28] <ari-tczew> cjwatson: ya, so please do this :)
[17:28] <cjwatson> in future, please file this sort of thing as a bug against merge-o-matic.  I think I already asked for this a couple of weeks ago
[17:29] <ari-tczew> cjwatson: file a bug for every package?
[17:30] <cjwatson> file a bug for each action you wish a merge-o-matic admin to take
[17:31] <ari-tczew> cjwatson: hmm. or file a one bug for the same action. then updating bug for new action in this same case.
[17:31] <cjwatson> this means that it won't forever be bottlenecked on just me (while it's true that I'm the only active MoM admin right now, I'm sure that won't always be the case)
[17:31] <cjwatson> one bug per action
[17:32] <cjwatson> if you go around reopening bugs for updated actions then I'm guaranteed to get confused.
[17:32] <cjwatson> and if you aggregate multiple things into the same bug then I'll probably end up picking a random subset of them to do
[17:33] <ari-tczew> cjwatson: hmm. I've noticed that you're tired working on MoM (or due to pings on you to MoM). sorry then.
[17:33] <cjwatson> huh?  no, I'm asking for you to use a more convenient form for reports so that I can process them more effectively
[17:33] <cjwatson> I'm not tired of it
[17:34] <cjwatson> I just don't want IRC to be the mechanism by which I'm asked for this sort of thing, because it will get lost
[17:34] <ari-tczew> cjwatson: I got the point. I'll report with list including a couple of packages to hide on MoM.
[17:34] <cjwatson> and IRC forces me to make a choice between (a) interrupt whatever I'm doing to take the action or (b) forget about it, neither of which is ideal
[17:34] <cjwatson> thank you
[17:35] <cjwatson> I think I probably need to add a way to merge-blacklist a single version
[17:36] <ari-tczew> cjwatson: I just wanted to file a wish against MoM. [16:41] <ari-tczew> ok thanks. I must report a bug against MoM - blacklist merges
[17:36] <cjwatson> otherwise you'll never find out about future Debian versions of hp-ppd
[17:36] <cjwatson> that would be Invalid, since it already has a way to blacklist merges
[17:36] <cjwatson> what it doesn't have is a way to blacklist individual versions from merging
[17:37] <ari-tczew> cjwatson: hmmm. maybe should be created a separate department like - blacklist.hmtl
[17:37] <ari-tczew> html*
[17:37] <cjwatson> if you want the merge-blacklist published, file a bug for that, sure
[17:38] <ari-tczew> cjwatson: then we won't loose informations about blacklisted merges
[17:38] <cjwatson> oh, no, I'd rather just blacklist individual versions
[17:39] <ari-tczew> cjwatson: versions? but I'm afraid about: <cjwatson> otherwise you'll never find out about future Debian versions of hp-ppd
[17:39] <cjwatson> that's what blacklisting individual versions would fix
[17:39] <cjwatson> I know what I mean :)
[17:39] <ari-tczew> cjwatson: mhm.... let's do this then.
[17:39] <cjwatson> already working on it
[17:40] <ari-tczew> cjwatson: so - report bug or not? ;)
[17:41] <cjwatson> report a bug please
[21:54] <xteejx> Hia ll
[21:54] <xteejx> Hi all
[21:55] <xteejx> package threadscope FTBFS, build-dep on libghc6-ghc-events-dev, but its not in our repos. It is in unstable ??
[21:55] <xteejx> I mean it IS in unstable, can it be synced over?
[21:55] <persia> xteejx, Try `rmadison -u debian ...`
[21:55] <geser> xteejx: or the PTS
[21:55] <persia> Check the NEW queue: it may already have been.
[21:55] <xteejx> persia: How do I do that?
[21:55] <micahg> xteejx: it's in natty, might be in NEW
[21:55] <persia> ( https://launchpad.net/ubuntu/natty/+queue )
[21:56] <xteejx> ahhh :) thanks
[21:56] <xteejx> persia: Nope, not int eh queue
[21:56] <xteejx> not in the *
[21:57] <geser> published 20 hours ago
[21:57] <micahg> xteejx: it's in natty, just needs to be given back then
[21:57] <geser> the binaries
[21:57] <xteejx> given back??
[21:57] <micahg> xteejx: the build given back for another try to build
[21:57] <geser> "ask" the buildds to try again
[21:57] <xteejx> ohhh is that done manually?
[21:58] <persia> Yeah, needs someone to press the button.
[21:58] <geser> yes
[21:58]  * persia goes to press some buttons
[21:58] <xteejx> in that case, can I ask that threadscope be done too, its only the build-dep stopping it afai can see
[21:58]  * geser points persia at ubuntu-build if he prefers to use a keyboard instead
[21:59]  * xteejx points at a cow in the field ... is that it?
[21:59]  * xteejx presses an udder......ummm that didn't seem to work!?
[21:59] <persia> geser, Thanks.  I'll try that next time.
[22:00]  * micahg didn't know it was that easy
[22:00] <persia> xteejx, threadscope given-back on all architectures
[22:00] <persia> micahg, If something didn't build, and you have upload rights, a rebuild can be requested.
[22:00] <xteejx> persia: Wow, either its easy or you work extremely fast, both are good ;) PS Thank you :)
[22:00] <micahg> persia: that I know, I was just looking at ubuntu-build, it's real simple
[22:00]  * persia usually encounters failure records from the ubuntuwire FTBFS page, so already has the buttons present
[22:00]  * micahg is thinking to extend ubuntu-build for packagesets
[22:01] <geser> micahg: give-back a whole packageset?
[22:01] <persia> micahg, How so?
[22:01] <micahg> geser: no, just report on it
[22:02] <persia> Oh, that's a good idea.  Please do.  Remember that a package can be in an arbitrary number of packagesets
[22:02] <micahg> persia: indeed, but it would be easier to see if any of the packages in my package set are FTBFS if there was a tool that just looked at those packages
[22:03] <geser> that wouldn't be too hard to implement
[22:03] <persia> Err, yeah.  And if I manage to pull off my MOTU hat, I can even see how that might be a good idea.
[22:04] <geser> perhaps I'll implement it when I find some time for coding (if micahg doesn't get it done before me)
[22:04] <geser> micahg: can you file a wishlist bug for it?
[22:05] <micahg> geser: sure, I'll take a look at teh FTBFS page code this weekend and see if there's an easy way to select by packageset
[22:07] <micahg> geser: I think there should be 2 changes, 1. packagesets added to FTBFS page, 2.  Individual packageset lists
[22:07] <geser> micahg: shouldn't be that hard, as ubuntu-build can already operate on a package list, you would just need to populate that package list from the packageset instead of the command line
[22:08] <persia> micahg, For 1) do you mean a per-package list, or separations?
[22:08] <micahg> geser: and I can already do that with edit_acl.py in the u-a-t
[22:08] <micahg> persia: just added to the list like the sponsorship queue
[22:09] <persia> Ah, that ought be fairly easy, indeed.
[22:10] <geser> micahg: you mean an additional column with the package sets or seperates lists (like for main, universe, etc.) for the package sets? or would you prefer seperate pages for each package set?
[22:10] <micahg> maybe I can even do it tonight on my way home
[22:10] <micahg> geser: additional column
[22:10] <micahg> geser: separate lists might be nice as well, but that can come later
[22:11] <geser> might be hard to find the needed space for the additional column without making the other ones too narrow
[22:12] <micahg> geser: we used to have 3 more arches listed, I think I can make it fit ;)
[22:12] <geser> I was happy to be able to make some columns a little bit wider when some architectures got removed
[22:12] <micahg> geser: would you prefer listing by packageset instead of the current setup or as another page?
[22:13] <geser> micahg: if I would be interested in one specific package set, I would prefer to have them in a seperate list (or even page) instead of searching for them in the whole list
[22:14] <micahg> geser: indeed, but if there's not included in this list, MOTUs might work on the packageset packages where the unseeded need love
[22:14] <micahg> *they're
[22:16] <geser> hmm
[22:16] <micahg> geser: where can I find the code for the FTBFS page?
[22:18]  * micahg tried lp:ubuntuwire-website
[22:18] <geser> micahg: https://code.launchpad.net/~geser/+junk/qa-ftbfs or follow the link at the end of the FTBFS page
[22:19] <micahg> geser: would you prefer a merge proposal or a diff?
[22:19]  * geser didn't know of lp:ubuntuwire-website
[22:20] <geser> micahg: merge proposal would probably be better to credit you but a diff works too (what's easier for you)
[22:20] <micahg> merge is easier in this case
[22:21] <geser> I'm also thinking about replacing the genshi templates with jinja (or mako)
[22:21] <micahg> bzr: ERROR: Invalid http response for https://code.launchpad.net/~geser/%2Bjunk/qa-ftbfs/.bzr/branch-format: Unable to handle http code 405: expected 200 or 404 for full response.
[22:21] <geser> interesting
[22:22] <ajmitch> that's a bit odd
[22:23] <geser> just tested "bzr branch lp:~geser/+junk/qa-ftbfs" myself and it worked for me
[22:23] <ajmitch> proxy breaking it?
[22:23] <micahg> user error :-/
[22:24]  * micahg branched the URL instead of lp:
[22:24] <persia> I don't think the source of the tools that happen to be hosted on ubuntuwire are really the same project as ubuntuwire-website.
[22:24]  * ajmitch thought that worked, maybe it's only bazaar.lp.net urls that do
[22:29] <geser> micahg: what about a column which contains only a checkmark if the package is part of a package set and display the packages sets in a tooltip for it? that wouldn't use that much space (additional to the table for each package set)
[22:33] <persia> Trick there is immediate visual identification for packageset developers.
[22:34] <persia> But I agree it would be nice not to degrade the experience too much for MOTU (who are likely to be processing the bulk of the page anyway) to support the addition.
[22:36] <geser> persia: for MOTUs is the mark that the package belongs also to a package set (which one can be seen in the tooltip) and for package set developers are the list with only their package set listed
[22:36] <persia> Oh, now that's a cool idea.  Yeah, with selection view, tooltip is completely sufficient.
[22:37] <persia> And MOTU can use the presence in *any* packageset as a hint that it may not be a priority (as MOTU)
[22:40] <ebroder> Hmm, dumb question, but is there a quick way to get a list of packages I'm TIL for?
[22:41] <geser> visit MoM and search for your name
[22:41] <ebroder> Ah, cool. Looks like I'm off the hook for now :)
[22:42] <ari-tczew> ebroder: or visit http://people.ubuntuwire.org/~lucas/merges.html and search your LP account name
[22:44]  * ari-tczew is afraid about remaining merges in universe. Number can't fall down under 75 this week.
[22:44] <persia> ebroder, In general, if you don't have packages for which you feel you have special expertise that will make it easier to proceed (e.g. complex merge and you've been working with Debian to sort it, but it shouldn't be merged because there is an upload to experimental that would be a sync expected next week), don't worry about being TIL.  Someone who needs the update will poke you, or someone will just do the trivial merge post-DIF.
[22:45] <ebroder> persia: Yeah, sure. I'm just trying to be more responsible this cycle than I was last one
[22:45] <persia> ari-tczew, The number of outstanding merges is not a useful metric, without a detailed understanding of the status of development on the Debian side for each package on the list.
[22:45] <ari-tczew> persia: what do you mean? forwarding delta to Debian?
[22:45] <persia> ebroder, Focus on fixing bugs and being responsive to communication.  Everything else is process wash.
[22:46] <persia> ari-tczew, Unless you inspect each case in detail, you can't know things like whether the delta is already in Debian VCS, or there are pending uploads to experimental sitting in a team staging repo, or similar.  As a result, the raw number may have absolutely no relation to the work to be done.
[22:47] <ari-tczew> persia: I always check whether delta is incorporated in Debian.
[22:48] <ari-tczew> and I don't understand why grabing changes from Debian is wrong.
[22:48] <ari-tczew> persia: That's not like I don't cooperate with Debian. Lately I gained ace-of-penguins Ubuntu = Debian.
[22:48] <persia> Grabbing changes from Debian isn't wrong.  It's impossible to know the state of delta incorporation for the vast majority of packages, as they don't have documented public pre-upload source availability.
[22:51] <ari-tczew> persia: do you know how many changes in Ubuntu are not documented in detail? Looking on your POV, we should do nothing, because there are no details!
[22:52] <persia> What?  I only said the number that appear in MoM is a useless statistic, not that we shouldn't do merges.
[22:52] <ari-tczew> persia: okay I have upload access and let me go working, if I'm not doing anything critical.
[22:54] <persia> You are doing critical stuff.  Please keep doing so.
[22:55] <ari-tczew> persia: we never will understand in this case
[22:56]  * ScottK has mashed retry on all the powerpc FTBFS due to archive skew or the python2.7 FTBFS.
[22:57] <ScottK> powerpc	2	 39 jobs (2 hours 10 minutes) <-- And it built a number already.
[22:57] <ScottK> ari-tczew: He's not telling you not to do work.  He's just telling you not to worry about counting merges.
[22:58] <ari-tczew> ScottK: ok
[22:58] <persia> ScottK, Thanks for the translation :)
[22:58] <micahg> ScottK: PM?
[22:59] <ScottK> Sure
[23:01] <kklimonda_> ScottK: the python-visual ftbfs will take some time so I've assigned it to myself for now. I have to get gtkmm updated first.
[23:01] <ajmitch> python-visual broke again?
[23:01] <ScottK> kklimonda_: Thanks.
[23:02] <ScottK> ajmitch: Needs a rebuild for boost transition, but the gdk-pixbuf .la file disappeared out from under it, so now it's untangling not caring about .la anymore.
[23:02] <ajmitch> as logn as I don't need to touch boost again...
[23:02] <kklimonda_> :D
[23:03] <ScottK> ajmitch: I'm sure we can arrange something.
[23:03] <kklimonda_> ajmitch: next boost is on me ;)
[23:03] <DktrKranz> ari-tczew: FYI, GNUstep transition complete, now it's just a matter of clearing NBS packages.
[23:03] <kklimonda_> (famous last words)
[23:04] <persia> kklimonda_, Brave words, but thanks!
[23:05] <ScottK> Halleluah (sp?)! A new Boost maintainer.
[23:06]  * ScottK passes the torch.
[23:06] <ebroder> ScottK: He said next boost, not all boosts :-P
[23:06] <ScottK> ebroder: Then he's TIL so as long as the rest of us are careful ....
[23:06] <ebroder> Ha!
[23:08]  * persia kinda likes TIL being a level to force people to keep doing stuff rather than a blocker to other people doing stuff
[23:08] <persia> s/level/lever/
[23:10] <ScottK> kklimonda_: Just let me know when you have stuff to review.
[23:42] <xteejx> vpb-driver has been updated in unstable, but doesn't appear on MoM, how come?
[23:43] <Laney> it was only done today
[23:44] <xteejx> ohh right, does it take a few days to update, and would it normally show that?
[23:44] <DktrKranz> xteejx: it won't be on mirrors in lesser than an hour and a half, you have to wait until then
[23:45] <xteejx> thats no prob, but it will show up right?
[23:45] <Laney> yeah I usually give at least a day for Debian stuff to be visible to the Ubuntu tools
[23:45] <xteejx> oh ok, just wondered is all :) thank you
[23:45] <Laney> if it's urgent then you can grab it from incoming/ftp.d.o directly sooner
[23:45] <DktrKranz> (already there)
[23:45] <xteejx> I'll have a look tomorrow, time for bed methinks
[23:46] <xteejx> night all :)