[00:01] <pochu> Dossy: any problems with it?
[02:19] <Legendario> hi, can anyone explain me or give me a hint on were a can read about merging a package from debian to ubuntu?
[02:26] <RAOF> Legendario: https://wiki.ubuntu.com/UbuntuDevelopment/Merging ?
[02:27] <Legendario> thanks RAOF, you're the one that always answers my question... :-D
[02:28] <bddebian> Heya gang
[02:28] <RAOF> Yo!  bddebian!
[02:29] <bddebian> Hello RAOF
[02:34] <protonchris> hey bddebian
[02:34] <bddebian> Hi protonchris
[03:48] <Dossy> pochu, yeah - vncconfig bug - I'd like to help make sure the fix makes it into hardy or whatever
[03:48] <Dossy> https://bugs.launchpad.net/ubuntu/+source/vnc4/+bug/119982
[03:48] <ubotu> Launchpad bug 119982 in vnc4 "amd64 vncconfig crashes" [Undecided,Confirmed]
[04:27] <superm1> Dossy, that bug is irrelevant if bug 184225 isn't fixed
[04:27] <ubotu> Launchpad bug 184225 in vnc4 "FTBFS in latest archive rebuild test" [High,Confirmed] https://launchpad.net/bugs/184225
[04:38] <Dossy> superm1: that's strange - it builds for me ... what version of gcc was used there?
[04:38] <superm1> Dossy, are you building on hardy?
[04:39] <Dossy> No, gutsy ... ah.
[04:39] <Dossy> Still, it'd be worth backporting a fix to bug #119982 to gutsy, no?
[04:39] <ubotu> Launchpad bug 119982 in vnc4 "amd64 vncconfig crashes" [Undecided,Confirmed] https://launchpad.net/bugs/119982
[04:39] <superm1> yeah.  and not to mention the related bug that all the xorg stuff in there is all out of date
[04:39] <superm1> the new stuff doesnt compile
[04:39] <superm1> i spent a few evenings at it and made a fair deal of progress
[04:39] <superm1> but never successful
[04:40] <superm1> can't be backported unless we have a "working" vnc :)
[04:40] <superm1> you know, to backport from
[04:40] <Dossy> Hm.  I guess I should set up a hardy VM too, then
[04:40] <Dossy> well, patching the existing vnc4server from gutsy w/ the fix, fixes the problem :)
[04:40] <superm1> https://code.edge.launchpad.net/~superm1/+junk/vnc4
[04:40] <superm1> https://code.edge.launchpad.net/~superm1/baracuda/trunk
[04:40] <superm1> if you want to pick up where I left off at
[04:41] <Dossy> "baracuda"?
[04:44] <Dossy> what version of x11proto-render-dev is in hardy?
[04:44] <RAOF> !info x11proto-render-dev hardy
[04:44] <ubotu> Package x11proto-render-dev does not exist in hardy
[04:44] <Dossy> oh.  wacky.
[04:44] <Dossy> !info x11proto-render-dev gutsy
[04:44] <ubotu> Package x11proto-render-dev does not exist in gutsy
[04:44] <Dossy> uh, that's wrong.
[04:45] <RAOF> So, ubotu is wrong.  It's version 0.9.3
[04:51] <Dossy> and gutsy is 0.9.2.  I wonder what changed between the two versions.
[04:55] <Dossy> So ... the hurdle here is getting the vnc4 stuff to build on hardy?  OK - guess I'm setting up a hardy image :)
[04:57] <Dossy> Is there a way to find out what packages were installed at the time of the sbuild?
[05:01] <LucidFox> What is the opposite of "subtle"?
[05:01] <LucidFox> Other than "anvilicious"
[05:02] <Dossy> obvious?
[05:03] <LucidFox> No, not in that sense :)
[05:03] <Dossy> Well, in what sense, then?  :)
[05:04] <LucidFox> It's when you're presented with something that conveys a particular message with such lack of subtlety that you feel like you're being hit with an anvil
[05:05] <Dossy> Unmistakable?
[05:05] <LucidFox> Gah... no :)
[05:05] <LucidFox> never mind
[05:05] <Dossy> :)
[05:11] <Exfil> what is the best virtual machine software for running Windows XP Professional and Fruti Loops Audio Software with USB Midi Keyboard
[05:16] <Dossy> realtime audio in virtualized guest?  wow, you're brave :)
[06:31] <dholbach> good morning
[06:33] <LaserJock> morning dholbach
[06:33] <dholbach> hiya LaserJock
[06:40] <superm1> Dossy, baracuda was a fork of realvnc
[06:40] <superm1> intended to work on xorg
[06:40] <superm1> whereas realvnc was always patched to make it work
[06:41] <superm1> good morning dholbach
[06:41] <dholbach> hey superm1
[06:42] <superm1> whatcha been up to these days?
[06:44] <kgoetz> j #gnu
[06:44] <kgoetz> gr
[06:46] <dholbach> superm1: lots and lots of small stuff
[07:13] <freeflying> bug #210860
[07:13] <ubotu> Launchpad bug 210860 in scim-m17n "After adding scim-m17n scim does not work automatically" [Undecided,New] https://launchpad.net/bugs/210860
[07:13] <warp10> Good morning
[07:36] <siretart> good morning, MOTU!
[07:36] <AstralJava> Morning.
[12:23] <emgent> heya
[12:43] <zul> Fujitsu: ping
[12:43] <Fujitsu> zul: Hi.
[12:44] <zul> Fujitsu: is nagios2 in a state to go into main?
[12:45] <Fujitsu> zul: In what respect?
[12:45] <emgent> Fujitsu: see invite.
[12:46] <zul> Fujitsu: ie If I take the time to do a MIR it wont get rejected and would be easy to promote?
[12:46] <Fujitsu> emgent: I tried to join earlier, but I don't have the key.
[12:46] <emgent> ok see notice :)
[12:47] <Fujitsu> zul: Security-wise it's not bad, it seems to work well (I use the package in a number of locations), but it has some dependencies not in main.
[12:47] <Fujitsu> Hm, only two non-nagios, actually.
[12:47] <Fujitsu> libnet-smtp-perl and libradius1. So it shouldn't be hard.
[12:49] <Fujitsu> *snmp-perl
[13:30] <mok0> ScottK?
[13:30] <ScottK> Yes
[13:31] <ScottK> mok0: ?
[13:31] <mok0> I would like to upload the xtide packages, but I want to make sure that it's ok FFe-wise
[13:32] <ScottK> OK.  Bug #?
[13:32] <mok0> bug 188086
[13:32] <ubotu> Launchpad bug 188086 in xtide "[needs-merge] xtide-2.9.5-2 from sid" [Wishlist,Confirmed] https://launchpad.net/bugs/188086
[13:32] <ScottK> Looking
[13:32] <mok0> bug 188093
[13:32] <ubotu> Launchpad bug 188093 in xtide-data "[needs-sync] xtide-data-20070318-1 from sid" [Wishlist,Confirmed] https://launchpad.net/bugs/188093
[13:32] <mok0> They belong together
[13:34] <ScottK> Making sure I understand ...
[13:35] <ScottK> xtide needs a merge.  It looks like it also needs an FFe unless the upstream version is bugfix only.
[13:35] <ScottK> xtide-data is just a new revision.
[13:35] <ScottK> mok0: Is that right?
[13:35] <mok0> right
[13:36] <mok0> the problem is with the current xtide in hardy
[13:36] <ScottK> For xtide are there new features or is it just bugfixes?
[13:36] <mok0> I introduced (in agreement with the DM) a change which we later revoked
[13:37] <mok0> ScottK; but the upload got hung in LP as you can see
[13:37] <ScottK> Can you make a new revision of the current version in Ubuntu that reverts that change without jumping to the new upstream version?
[13:38] <mok0> I could, but I am pretty sure that there is no real difference
[13:38] <mok0> (Except we would loose the icons I made)
[13:38] <ScottK> That gets back then to the question of are there new features in the new xtide version?
[13:39] <mok0> I can investigate it further
[13:39] <mok0> I dont want my first upload to be a FF violation :-)
[13:40] <ScottK> If you can convince yourself it's only bugfixes, then all you need to do to be clear with motu-release is paste the new upstream changelog entries in the bug and upload.
[13:40] <\sh> can someone unsubscribe motu-release from bug #211057
[13:40] <ubotu> Launchpad bug 211057 in wireshark "FFe for inclusion of wireshark 1.0.0-1 into Hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/211057
[13:40] <ScottK> If it's got features you need to fill out an FFe.
[13:40] <mok0> ScottK; got it
[13:40] <ScottK> \sh: We don't normally bother.  It'll just go off our radar once it goes Fix Released.
[13:40] <mok0> ScottK: what about xtide-data?
[13:41] <\sh> ScottK, good then :)
[13:41] <ScottK> mok0: That's just a new revision, right?  You should be able to just do that one.
[13:41] <mok0> ScottK: great
[13:43] <pochu> mok0: I did review xtide's changelog diff and it looked like bug fix only
[13:43] <mok0> pochu: that's my impression too, but it's been a while since I looked at it
[13:47] <pochu> mok0, ScottK: see the 2.9.[45] entries... the diff had a lot of space reformating: http://emilio.pozuelo.org/~deb/xtide_changelog
[13:47] <pochu> gtg
[13:49] <mok0> thanks pochu
[13:53] <\sh> so...wireshark 1.0.0-1 synced
[13:54] <emgent> hardy?
[13:54] <\sh> yepp
[13:54] <emgent> cool :)
[13:55] <\sh> emgent, your gutsy debdiff looks good..please assign the the bug to yourself, so I'm off the radar
[13:55] <\sh> now for the other CVes for wireshark in older releases ;
[13:55] <\sh> )
[13:56]  * emgent thinking to backport
[13:57] <\sh> emgent, try to backport it to dapper first..because version in dapper is bad very bad regarding security because of the state of the source
[13:57] <emgent> ok cool
[13:57]  * emgent adding it in todolist.
[13:58]  * \sh has some nice octave crap on his todo 
[13:58] <emgent> :)
[14:01] <emgent> omg it's late..
[14:01] <emgent> i go to office
[14:01] <emgent> see you later people
[14:24] <asac> hmmm ... anyone has a time-slot to fix xine-plugin build? i reuploaded it with just a new link in xine-plugin.links and now it fails to build
[14:24] <asac> http://launchpadlibrarian.net/13092176/buildlog_ubuntu-hardy-lpia.xine-plugin_1.0.1~cvs20070523-1ubuntu2_FAILEDTOBUILD.txt.gz
[14:25] <asac> looks like that the version checks are busted
[14:25] <asac> *** 'xine-config --version' returned -1717986918.1072798105.-1717986918, but XINE (1072798105.858993459.1076245299)
[14:25] <asac> ouch
[14:25] <asac> $ xine-config --version
[14:25] <asac> 1.1.11.1
[14:25] <asac> thats what i get :/
[14:28] <ScottK> mok0: I'm curious if you have an opinion on Bug 66862
[14:28] <ubotu> Launchpad bug 66862 in python-numpy "scipy not built with atlas support ?" [Undecided,Confirmed] https://launchpad.net/bugs/66862
[14:28] <mok0> hm
[14:29] <mok0> it should build depend on libatlas-base-dev
[14:30] <mok0> not atlas3-base
[14:30] <mok0> after gfortran transition...
[14:30] <asac> ok i think i have the fix. cheers
[14:31] <mok0> Otherwise it can't find the right lapack library, and I bet it switches off lapack support then
[14:36] <mok0> asac: it always helps talking to one self...
[15:05] <\sh> phew
[15:05] <\sh> company release 0.8.8 is out....so for this week i'm done...at least as relmgr
[15:10]  * persia points at https://lists.ubuntu.com/archives/ubuntu-motu/2008-April/003523.html and invites criticism, comments, and applicants.
[15:12] <mruiz> hi all
[15:15]  * cody-somerville is excited about the change.
[15:15] <persia> cody-somerville: Welcome to yet another group :)
[15:16] <cody-somerville> :)
[15:16] <warp10> persia: is it the way to implement the decision about MC assigning ubuntu membership for good, not yet ready for MOTUness contributor?
[15:16] <persia> warp10: Membership is one of the entitlements granted by the new group.
[15:17]  * cody-somerville is now a member of 48 launchpad groups.
[15:18] <persia> warp10: While it does implement the recent CC decision, it will also be used to make things easier for contributors.
[15:19] <persia> The idea being that if you've been working on stuff for a few months, it would make sense for you to be able to commit to a bzr repo, and ask for review, for bzr-managed packages.  There are several other entitlements under consideration, although suggestions are welcome.
[15:20] <huats> persia if I understand correctly, every current contributor is encourage to apply to that new group
[15:21] <warp10> persia: indeed. And I say +1 particularly because the road to MOTU is pretty long, and having an intermediate target as a first, official acknowledgment for your good contribution is something that suprs to go ahaed.
[15:21] <persia> huats: Once they've been around a while, and done some stuff, and have some sponsors, yes.  On the other hand, not everyone would be approved.
[15:21] <ScottK> persia: We don't have bzr managed packages in Universe
[15:21] <huats> persia: of course
[15:21] <persia> ScottK: Are they all in multiverse now?  The one I remember most closely is mplayer.
[15:22] <ScottK> persia: There is no process agreement.  The agreed process is that the canonical source for our packages is the Debian Source package.
[15:22] <huats> persia:  it is the way for the MC to manage to grant membership ? we already discussed that a long time ago
[15:22] <huats> :)
[15:22] <ScottK> persia: I also see that teams are being renamed.
[15:22] <persia> ScottK: I don't disagree.  On the other hand, there are a couple packages listed that way.  Maybe only mplayer.
[15:23] <ScottK> persia: Just because someone stuffed some VCS headers into a package doesn't mean anything.
[15:23] <persia> ScottK: Only the one team is being renamed.
[15:23] <ScottK> persia: On what basis?
[15:23] <ScottK> Who has agreed to this?
[15:23] <ScottK> It's been done with no discussion.
[15:24] <persia> ScottK: Hmmm...  It was done as part of the MC taking over the team from the previous administrator, but I agree that the rename may have benefitted from discussion.
[15:24] <ScottK> persia: MC has no authority to change process.
[15:25] <ScottK> persia: It seems no comment is needed since MC has already acted and dictated.
[15:26] <persia> ScottK: Right.  I guess I didn't see a process change beyond the introduction of the new team, which was confirmed in the CC meeting a month or so ago.  It can be changed back if you think the name change is a process change.
[15:26] <ScottK> There's also automatic expiration.
[15:26] <ScottK> There is using a VCS.
[15:27] <persia> Expiration hasn't been done yet, and it's a valid point.  I'll take it to the next MOTU Meeting.
[15:27] <ScottK> persia: This is not written as a proposal, but as an MC fiat.
[15:27] <persia> Some packages use a VCS.  I don't think this is a new argument.
[15:27] <ScottK> persia: We've been through the VCS business many times before and the answer was no.
[15:28] <ScottK> persia: Where in the sponsorship process is there a VCS?
[15:28] <huats> persia: is there somewhere where sponsors can found a more detailled description of the requirements to integrate that team ?
[15:29] <persia> ScottK: VCS is not part of sponsorship.  That's agreed.
[15:30] <ScottK> persia: This fiat changes that.
[15:30] <persia> huats: Not really.  it's a new team.  The first members will likely set the tone for requirements, but the requirements for Ubuntu Membership should be considered a minimum basis.
[15:30]  * persia rereads the mail, to check the phrasing again
[15:31] <ScottK> persia: Given that changes in Launchpad have already been made, there is no argument that this is a proposal.  It's already being implemented.
[15:32] <persia> ScottK: Which change?  The new team?  That was in part the implementation of the previous CC decision.
[15:32] <ScottK> persia: Yes.
[15:32] <ScottK> The team structure has been changed with not even notification to the community.
[15:33] <huats> persia: I was asking that since I am sure many potential sponsors would ask themselves asking that question (someone already asked me that since he didn"t know what was exactly required he couldn't answered me...)
[15:33] <ScottK> I discovered it because I happen to be subscribed to a wiki page.
[15:33] <mok0> ScottK: apart from the de facto decision, do you disagree with it?
[15:34] <persia> ScottK: A new team was defined.  It doesn't have any members yet.  This is implementation of the previous CC discussion, plus spin.
[15:34] <ScottK> persia: Not true.
[15:34] <huats> mok0: congrats btw :)
[15:34] <mok0> huats: thanks :-)
[15:34] <persia> I don't understand this as fiat, and it can be undone, if it is.
[15:34] <ScottK> mok0: Except for the VCS business, I think it's in the right area.
[15:35] <persia> ScottK: I said " I would like to encourage anyone maintaining a VCS for Ubuntu packaging of a universe package to consider using this team in place of ~ubuntu-dev as a source of acceptable committers"
[15:35] <mok0> I read it such that the VCS is an option for contributors
[15:35] <ScottK> persia: Look where this link goes https://launchpad.net/~ubuntu-universe-contributors
[15:35] <persia> I didn't say "people should use VCS"
[15:35] <cody-somerville> Debian makes heavy use of VCS. They must see some benefit. Why don't we see the same benefit?
[15:35] <mok0> I think there could be some benefit in group maintenance
[15:35] <ScottK> cody-somerville: They use it in small teams where there is agreement to use it.  I participate in several such teams and it works well.
[15:35] <persia> cody-somerville: Because it makes merging annoying, especially as LP is restricted to bzr, and bzr is almost never used in Debian.
[15:36]  * broonie notes that he maintains a couple of Debian packages in bzr specifically because Ubuntu send him 90% of the patches and I still don't get stuff in bzr format :/
[15:36] <ScottK> persia: I will argue strongly against any mention of bzr in particular and vcs in general.
[15:36] <mok0> But bzr and git are very similar in their functionality
[15:37] <ScottK> mok0: For me it's n+1 vcs to deal with and I've never run into bzr outside Ubuntu.  I'm not going to learn a new vcs just for Ubuntu.
[15:37] <mok0> I think you can run whatever you want on your side
[15:38] <persia> ScottK: I'm happy with that.  I'm not in favor of using bzr for Debian-derived packages myself.  On the other hand, I know some packages to be maintained in bzr, especially some newer ubuntu-local packages, and I want all members of the new team to be able to commit.
[15:38] <ScottK> persia: Then put it in some documentation related to that. Not in anything Universe related.
[15:39] <persia> ScottK: new ubuntu-local packages are in universe.  Please suggest text for a correction
[15:39] <ScottK> persia: It's orthoganal to the question.  Just delete it.
[15:40] <ScottK> persia: It does seem that there's a hidden change here that one will need to qualify for membership before one can upload to REVU.  Is that wrong?
[15:41] <ScottK> persia: Those packages (ubuntu-dev-tools for example) are separate Launchpad projects.  It's really nothing to do with Ubuntu or Universe formally it's how they manager their 'upstream' work.
[15:42] <persia> I can't delete email.  I'll issue some correction statement, but want to avoid a flamewar with the no-more-source folks (with whom I disagree)
[15:43] <persia> And, no, there's no hidden change.  While the new team does have REVU Upload rights, that's still encapsulated in the current open team (which got renamed).
[15:43] <siretart> code monkeys? who came up with that name?
[15:43] <slicer> If I understand this correctly; the overall intention is to make it easier for "smaller" contributors to contribute?
[15:44] <slicer> (ie: people like me ;))
[15:44] <ScottK> siretart: Don't worry.  MC have it all figured out.  It'll be wonderful.  We can just go about our business.
[15:44] <persia> slicer: Right.
[15:44] <geser> ScottK: REVU upload is still through the open team ~ubuntu-code-monkeys (formerly know as ~ubuntu-universe-contributors)
[15:44] <siretart> ScottK: lol
[15:44] <persia> ScottK: I disagree with that entirely.
[15:44] <slicer> persia: If so, I heartily applaud it :)
[15:44] <mok0> persia: looking at the wiki, for each type of developer, it would be good to have the _requirements_ needed to enter that group. For example, to enter group 3 (MOTU) you have to be a group 2, etc.
[15:44] <ScottK> persia: Actions speak louder than words and the actions started before there was even an announcement.
[15:45] <persia> mok0: Except you don't have to be in each of the earlier groups to join the later groups, although it is expected most people will.
[15:45] <ScottK> geser, persia: Why was it renamed?
[15:45] <persia> slicer: Yes.
[15:45] <mok0> persia: well, then it should be stated in terms of skills, etc
[15:46] <persia> mok0: Maybe.  I've never seen a list of requirements for any of the teams that was a firm set of rules.
[15:46] <ScottK> Or to be more correct it appears action and the announcement happened at roughly the same time.
[15:46] <mok0> persia: I think it is difficult to understand if you don't already know the system
[15:46] <persia> ScottK: We created a LP group, and sent an email.  If you disagree, help me understand how, and we can change it.
[15:47] <ScottK> Given that the plan is being excecuted already, it seems quite clear that the decision is taken and it's done.
[15:47] <huats> mok0: I cannot more agree more... I already asked someone if he agrees to "sponsors"  me for that new team... he told me he cannot for the moment since it is not yet clearly defined
[15:47] <huats> ...
[15:47] <persia> While I hope the new group will inform changes in process, none are currently imposed.
[15:47] <siretart> ScottK: I assume to show that there is action in ubuntu development. TBH, those renames are pretty confusing to me
[15:47] <ScottK> persia: I disagree that MC has any authority to make any changes.
[15:47] <persia> ScottK: No changes have been made.  I sent an email.
[15:47] <ScottK> persia: LP teams have been changed already.  That is a change.
[15:47] <slicer> Ah, this is probably a bad time, but creation of new users on the wiki seems broken. Once it gets to show the user preferences for the first time and you hit "save", it just hangs.
[15:48] <persia> ScottK: OK.  If the rename is your issue, I'll rename it back.  Is that it, or is there something else?
[15:48] <persia> slicer: #launchpad can likely help you with that
[15:48] <ScottK> persia: My issue is action in advance of decision by the MOTU community.
[15:48] <slicer> persia: Ah, thanks :)
[15:49] <persia> ScottK: Umm.  By "action" do you mean a team rename, or something else.
[15:49] <\sh> -ETOOMUCHREDTAPE
[15:49] <ScottK> persia: I am aware that renaming has been done.  I am not aware of what other actions have been done or may be planned to be done in advance of any agreement from the community.
[15:49] <mok0> persia: I think ScottK thinks there should have been some discussion first
[15:50]  * siretart tends to agree with ScottK 
[15:50] <ScottK> mok0: I'd put it stronger.  I think that under our agreed method of making policy, MC has exceeded it's authority.
[15:50] <persia> ScottK: The totality of that planned is my email, and a question I raised on LP: https://answers.launchpad.net/launchpad/+question/28815
[15:50] <persia> I'm hoping to see more change, but as I said in my email, that should be discussed in the ML thread, or in a MOTU Meeting.
[15:50] <ScottK> persia: Put back what's been done and let's discuss it all.
[15:51] <ScottK> persia: I also really don't like the new name.  I think it would benifit from some disucssion about why it needed changing at all.
[15:51]  * mok0 thinks that renaming certain groups doesn't really matter
[15:51] <siretart> it seems that we need a defined process for changing processes
[15:51] <persia> ScottK: Some of it I can't easily put back.  I'm happy to refrain from adding anyone to the new team, and undoing the rename, if that meets your needs.
[15:51] <ScottK> siretart: We've done that.
[15:52] <siretart> ScottK: we did?
[15:52] <ScottK> siretart: It's my understanding that the process is we discuss it at a MOTU meeting and vote.
[15:52] <persia> We've talked a lot about it, but I don't think we ever had the meta-process meeting (unfortunately).
[15:52]  * persia agrees with ScottK
[15:52] <siretart> ScottK: ah, right. I was rather thinking about somthing similar to http://www.gentoo.org/proj/en/glep/ or http://dep.debian.net/deps/dep0/
[15:53] <ScottK> I see.
[15:53] <ScottK> We at least have a basic mechanism defined.  It may or may not need more structure.
[15:53] <siretart> right
[15:54] <siretart> is this worth a bof in prague?
[15:54] <ScottK> persia: As far as putting stuff back goes, I think you need to make it as it was before.  If that's difficult, I think that only emphasizes the point that it should have been discussed and agreed in advance.
[15:54] <persia> I feel like it might.  I thought I followed all the processes.  I'd like a BOF
[15:54] <persia> ScottK: Anyone can make an LP team.  Why are you mad about Universe Hackers?
[15:54] <siretart> persia: because it is a disruptive change
[15:55] <\sh> guys, the new names of those teams is something for kids...I don't think we are K1dZ
[15:55] <persia> siretart: Help me understand how.  Please.
[15:55] <ScottK> persia: I'm mad about unilateral action.  What that action is is pretty irrelevant.
[15:55] <siretart> e.g. revu has hardcoded the team name 'ubuntu-universe-contributors' in the source. changing the team name breaks keyring syncing
[15:55] <\sh> we want to get new blood for development and packaging but we don't want to invent a kindergarden
[15:55] <persia> ScottK: That happens every time I upload.  Further, this was based on things discussed in MOTU Meetings and CC Meetings.
[15:55] <persia> Help me understand where I messed up, so I can undo what I can, and do it right.
[15:56] <ScottK> persia: To start with you just broke REVU keyring syncs.
[15:56] <ScottK> persia: That should be clue enough that there was insufficient discussion.
[15:56] <persia> siretart: Ah.  Good point.  I believe undoing that name change is already agreed, although I'd like confirmation that it meets people's needs.
[15:56] <siretart> persia: please undo the rename. at least for now
[15:57] <\sh> secondly, https://answers.edge.launchpad.net/launchpad/+question/28815 I don't know if I like to grant those permissions...what I like is the "work with your mentor or motu of your day on bugs and tasks" so the mentor or motu of the day knows what's going on...
[15:57] <persia> No problem.  I'm happy to undo the rename, and whether for now or forever isn't important to me.
[15:57] <emgent> heya
[15:57] <ScottK> persia: From my perspective your mail does not present a proposal for discussion.  It presents a fiat that's already being executed.  That's the source of my unhappiness.
[15:57] <siretart> besides, this is really a pretty unfortunate time for doing process change. lets defer that to after hardy release
[15:58] <persia> ScottK: I'll dig up my proposals then, all sent to lists or presented at meetings.  Hold on for some URLs...
[15:58] <siretart> persia: I don't really oppose to the change. Really.
[15:58] <\sh> anyhow, whatever we invent, it gives us too many policies, processes and red tape ...
[15:58] <persia> (after unrenaming the team)
[15:58] <ScottK> persia: Be sure to find the one that talks about Ubuntu Code Monkeys.
[15:59] <siretart> in principal. but I agree to scottk that this hasn't been discussed in appropriate length and forum
[15:59] <siretart> even dholbach told me in a private mail that this discussion did happen on motu-council, but was rather hidden
[16:00] <ScottK> persia: I think the change is generally a good proposal.  I just think we need to discuss/agree in advance of action.
[16:00] <\sh> siretart, there it is again: "hidden" and "private"
[16:00] <siretart> I know that discussion about processes and process change has been pretty frustrating in the past. and will be in the future. however, since we need to have this discusssion again, it appears that the current state of affairs aren't really adequate for us
[16:00] <persia> ScottK: Hmm.  OK  I thought I did, for the main thrust.  I agree that "Code Monkeys" is a surprise (which I'm currently undoing)
[16:01] <siretart> \sh: there is nothing hidden about that mail. he asked me privately to transfer ownership of the lp team 'ubuntu-universe-contributors'
[16:01] <siretart> \sh: and I insist that we need to allow private discussion and chatter, even about development, processes and change
[16:02] <ScottK> siretart: Sure, but private disucssion followed by action with no public discussion is what's at issue.
[16:02] <persia> https://launchpad.net/~ubuntu-universe-contributors
[16:02] <mok0> OOPS-824EB60 -- code monkeys are gone...
[16:03] <\sh> siretart, I don't say nobody can discuss in private, quite the opposite
[16:03] <ScottK> persia: Thank you.  I'll calm down and consider the main points.
[16:03] <siretart> ScottK: I wasn't involved in the decision process. I'm not guilty! :)
[16:03] <ScottK> siretart: Of course.
[16:03] <mok0> Well this is a a good time to reboot the discussion
[16:03] <persia> ScottK: Thank you.  I'm more than happy to undo things as required, but I'll argue for some of them.
[16:04] <persia> ScottK: I agree with you about process, and thought I had done it correctly with the new team.
[16:04] <ScottK> persia: I'd appreciate a follow-up from you making it clear that this is an MC proposal to MOTU that will be decided by MOTU.
[16:04] <ScottK> persia: What is there that's been done that is hard to undo?
[16:04] <persia> ScottK: I'll be replying to your email once I catch up on my wiki edits.
[16:04] <\sh> and again for the record: 1. too many teams for such a small bunch of people 2. the names are really childish...and I don't think that this is the right way
[16:05] <mok0> I think finer granularity is good, so people with different skills can find their slot and become actively involved Otherwise they tend to slip away again
[16:05] <persia> ScottK: I can't unsend email, and I don't want to delete the new Ubuntu Hackers team, for fear it would take a month to restore it to the current state.
[16:05] <ScottK> persia: I don't mind the team existing as long as it's made clear it's a placeholder for now.
[16:05] <cody-somerville> I think the change is a good one as well. As for the names, I don't see them as childish myself. However, I wouldn't oppose more formal terminology either.,
[16:06] <huats> sorry to insist, but it is needed to express some guidelines, or ideas of what is needed to join this group... otherwise contributors (like it already happen to me) won't be able to find anyone that accept to "sponsor" them for the new team....
[16:06] <persia> \sh: I disagree with 1, and have since feisty, which is why I've written so much about recognising contributors properly for the past while.
[16:06]  * pochu just ended reading the backscroll
[16:06] <\sh> mok0, people will go away, when they don't have interest anymore in the stuff they want to do...that is the main reason
[16:06] <\sh> mok0, or when they are not patient enough....
[16:06] <persia> huats: It may take a while before we reach that point :)  I doubt it will be formalised, but rather that someone may start sponsoring people, which may inform others.
[16:07] <mok0> \sh: exactly, which is what often happens.
[16:07] <pochu> have you guys heard of branches in distributed VCS? people don't need to be in the main team, they branch and the reviewer merges if that's ok
[16:07] <pochu> I think these changes are pointless...
[16:07] <ScottK> pochu: VCS is not part of our sponsorship process.
[16:07] <pochu> ScottK: I know, but the changes were done thinking in that, and even then that sounds wrong to me because of branches
[16:08] <\sh> persia, I agree with you, that we a) recognising people who contributed a lot, but are not ready for upload rights...
[16:08] <ScottK> pochu: Until someone shows me a VCS that scales to 20,000 packages, it's not something that we can use.
[16:08] <siretart> hct!
[16:08] <persia> \sh: Right.  The new team is that, and ought get granted what rights seem appropriate.
[16:09] <mok0> ScottK: If there are people who are willing to work using a VCS, I think it is perfectly reasonalble to allow that. It doesn't need to be either-or
[16:09] <\sh> persia, there are two ways you can recognise people: 1. in a social manner...2. in a technical manner...for 2) we need to adjust LP to have more granulated bug/task rights for people/teams...but LP is not there and this is only technical..
[16:09] <cody-somerville> persia, this new group should be a member of the ubuntu bug control group
[16:10] <\sh> I think for 1) we (the motus) need to do some action, so we should telling the people we like that they do awesome work...
[16:10] <ScottK> mok0: I disagree.  Then you have stuff in VCS that gets missed by people who don't use it.  The team either uses a VCS or not.
[16:10] <pochu> ScottK: I'm not defending moving the packages to a VCS (I don't have a strong opinion on that), I'm just saying I can't see the point of the changes *even* if we were using or were going to use bzr, because this sounds like the changes are done for contributors to be able to commit, but IMHO they can branch
[16:10] <jeromeg> cody-somerville: i don't think so, this group has nothing to do with packaging/hacking
[16:10] <persia> cody-somerville: That's a good idea, but I'm holding off making it more complex until the email thread is done.  Please reply to the email with your suggestion.
[16:10] <pochu> and I agree with ScottK this should have been proposed first...
[16:10] <ScottK> mok0: If two people agree to work together using a VCS, that's fine, but not as part of the agreed sponsorship process.
[16:11] <cody-somerville> jeromeg, I'm pretty sure it has everything to do with packaging/hacking
[16:11] <cody-somerville> jeromeg, Hence why it is called the "Ubuntu Universe Hackers".
[16:11] <jeromeg> cody-somerville: ubuntu bug control ?
[16:12] <cody-somerville> jeromeg, When you said "this", you referred to the group we were discussing which was the universe hackers group.
[16:12] <\sh> cody-somerville, packaging has nothing to with hacking...hacking has nothing to do with software development...hacking is really something else in the real old geek meaning...
[16:12] <cody-somerville> \sh, ...
[16:13] <jeromeg> cody-somerville: by this i meant your proposal of making it part of ubuntu ug control, sorry if I was not clear
[16:13] <sebner> cody-somerville: do you also got the mail and are thinking. Heee?
[16:15] <cody-somerville> see my e-mail
[16:20] <persia> OK.  Unmonkeying complete (https://wiki.ubuntu.com/UbuntuDevelopers?action=fullsearch&context=180&value=code-monkeys&fullsearch=Text)
[16:20] <huats> cody-somerville: it worth what it worth but I think that you email introduces a good point
[16:21] <huats> (I mean it is just my opinion)
[16:22] <ScottK> persia: Thank you.
[16:22]  * ScottK needs to run.  Back later.
[16:23] <persia> ScottK: Thanks for raising the flag on this.  As important as I think this is, I do want to follow the processes properly.
[16:32]  * \sh goes home...cu later
[16:32]  * cody-somerville eats lunch at his desk.
[16:57] <tsmithe> slomo__, you around to take a peek at mscore?
[17:37] <james_w> I am trying to fix a bug for hardy. The package is unmodified from Debian currently. The bug is actually caused by one of the build dependencies.
[17:38] <james_w> the fix is pulled out from Debian's svn (it's a Debian native package) for the build-dependency and I'm applying that.
[17:38] <james_w> once that fix is in then all that needs to happen for the first package is a rebuild.
[17:38] <james_w> I'm now thinking about version numbers. The change is already in Debian's packages which are newer.
[17:39] <james_w> so I could go build1 for both, so we just get Debian's packages after release with no intervention
[17:39] <james_w> ubuntu1 for the second package as it is a code change, and build1 for the first, as it isn't
[17:40] <james_w> however until the merge was done this could lead to a FTBFS, or at least a dep-wait.
[17:40] <james_w> so I could ubuntu1 them both and then request a sync for both at the same time in the next cycle, has anyone got a recommendation?
[17:43] <james_w> https://bugs.edge.launchpad.net/ubuntu/+source/debian-edu/+bug/190682 if anyone wants specifics
[17:43] <ubotu> Launchpad bug 190682 in debian-edu "package education-astronomy 0.824 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [High,In progress]
[17:43] <james_w> it's a milestoned bug for Hardy.
[17:46] <LaserJock> dholbach: universe-code-monkeys?
[17:47] <sebner> LaserJock: sounds funny :D
[17:48] <persia> james_w: I usually upload an -Xubuntu1 in that case, and note in the changelog that the change should be able to be dropped for the next merge with Debian.
[17:49] <james_w> persia: thanks
[17:50] <james_w> a related question, as I need to rebuild against the fixed package should I bump the Build-Depends to make sure, or would just submitting in order work?
[17:53] <persia> Best to set versioned build-depends if you need them.  Otherwise, it doesn't flag right for someone trying to backport.
[17:54] <persia> For the same reason, best not to set versioned build-depends if you don't need them.
[17:55] <sebner> heya bddebian
[17:55] <bddebian> Heya gang
[17:55] <bddebian> Hi sebner
[17:59] <james_w> persia: well, it will still build with the old version, you'll just end up with the same bug again.
[17:59] <james_w> I guess I'll set them here, as we're only going to be dealing with it for a few weeks until I sync the new upstream.
[18:01] <persia> james_w: If you're reporting the bug fixed in the changelog, better to set the versioned depends.  Someone can later examine the debdiff, and decide about backporting.  If you don't set it, you've not really closed the bug, it just disappeared.
[18:01] <james_w> true, thanks
[18:08] <tapH20guru> I'm trying to repackage ffmpeg... got the deb source... make the change in the C code.. ran "sudo dpkg-buildpackage -rfakeroot -uc -b" ... install the debs on another machine... now getting errors like: error while loading shared libraries: libavutil.so.49: cannot open shared object file: No such file or directory
[18:09] <tapH20guru>  libavutil.so.49 exists... it's just called  /usr/lib/libavutil.so.1d.49.3.0
[18:09] <tapH20guru> is there a reason why it adds a 1d in front and a 3.0 at the end of the filename?
[18:10] <tapH20guru> if I symbolic link it it runs fine.
[18:10] <tapH20guru> lol... i hope this is the right place to ask this kind of question
[18:11] <persia> tapH20guru: For repackaging, this is likely as close as it gets, although we tend to mostly focus on things planned for upload into Ubuntu.  On the other hand, the answer to your question is in your build system, so those not very familiar with the package may have difficulty providing a good answer.
[18:12] <tapH20guru> got ya
[18:12] <tapH20guru> just wonderinf if I modify the debian/changelog if it wants to change the name of the shared libraries
[18:13] <james_w> just doing that shouldn't do it.
[18:20] <slytherin> persia: I sent a mail to motu ML few days ago about debconf preseed for java 1.4 packages. Looks like it got overlooked. Can you make any comments?
[18:21] <persia> slytherin: I'm really sorry to say you should have sent that before, without the knowledge that sending it would be so difficult :)
[18:21] <persia> (and you misspelled my name :p)
[18:22] <persia> But seriously, I don't know enough about the specifics to have an opinion, and believe it's better decided by either the buildd admins or the motu-release team (and couldn't even say which is the right team).
[18:23] <persia> I think not having FTBFS situations is good, but I don't know if failing to build with a newer Java should be considered enough of a problem that it ought to be fixed differently than preseeding.
[18:23] <slytherin> persia: sorry about spelling. Was doing multitasking. :-D Yes the delay was very bug. I will hope for the best. Otherwise batik 1.7 will eventually enter hardy + 1 anyway. :-)
[18:24] <slytherin> persia: It is not possible to fix any other way. The newer java is simply too new for batik 1.6. :-P
[18:25] <persia> slytherin: Right.  It's a question of an upstream version exception vs. preseeding another version of non-free Java.  I'm just not sure which is safer, or the impact of one choice or the other on the distribution as a whole.
[18:26] <slytherin> persia: UVFe won't be possible at this moment because it also needs some additional library. Anyway, I think I should wait for someone to notice the mail and make a comment.
[18:26]  * slytherin goes to fix the continuous beeping elevator
[18:27] <persia> slytherin: That's probably best.  I can reply, but I just didn't think my reply would be constructive, given my lack of knowledge about the situation.
[18:27] <persia> (That's part of why I suggested you mail the list before, instead of just answering your question in February)
[19:12] <andres_> asac, hi
[19:12] <asac> hi
[19:13] <andres_> I have a question (excuse my English)
[19:14] <asac> yeah ... if its mozilla related please use #ubuntu-mozillateam
[19:14] <asac> otherwise go ahead :)
[19:14] <andres_> :P
[19:14] <andres_> xD
[19:15] <andres_> ok
[19:45] <nxvl> persia: how is the Universe Hackers thing going?
[19:50] <nxvl> geser: can you explain it?
[19:50] <nxvl> soren: or you?
[20:02] <LaserJock> nxvl: what do you want to know about it?
[20:02] <nxvl> LaserJock: if it is going to be deployed and when does applications start
[20:03] <LaserJock> I'm thinking it needs to be ratified at the next MOTU Meeting first
[20:03] <LaserJock> I think we might also need to make sure everybody's clear on it and have the right team memberships
[20:04] <sebner> slomo__: do you plan also to update ubuntu mono version?
[20:05] <slomo__> no
[20:06] <jdong> ss
[20:07] <sebner> slomo__:  what a pitty :)
[20:07] <sebner> jdong: thanks for you interest in MD :)
[20:15] <zul> hey LaserJock long time no speak
[20:16] <LaserJock> hi zul
[20:21] <POX_> RainCT: PAPT instead of DPMT is in pyclamd's Uploaders
[20:21] <POX_> also do "s/@echo/echo" in debian/rules (my mistake)
[20:26] <LaserJock> can MOTUs approve/decline release nominations?
[20:28] <RainCT> LaserJock: yes
[20:28] <slangasek> ... they can?
[20:29] <RainCT> slangasek: or at least I get a enable/disable link on nominations and clicking on it it shows a confirm button (haven't tried it though)
[20:29] <slangasek> that's interesting. if it says "confirm", it's also completely different from the UI I see.
[20:30] <RainCT> slangasek: not sure if that's the names it has. if you have a URL I can check
[20:32] <slangasek> RainCT: bug #199960?
[20:33] <LaserJock> should say " Nominated  for Hardy  by Hans Deragon   (approve/decline) "
[20:34] <LaserJock> RainCT: do you get that?
[20:34] <RainCT> LaserJock: yeh
[20:34] <LaserJock> good
[20:35] <LaserJock> I believe ~ubuntu-dev has permissions for release nominations
[20:36] <RainCT> POX_: uploaders fixed in svn. thx
[20:36] <LaserJock> it seems LPs documentation needs to be updated :-)
[20:42] <LaserJock> ok, so we've got that ~ubuntu-bugcontrol can flip Importance and Won't Fix, ~ubuntu-dev can do release nominations, are there any other bug-related permissions in LP?
[20:42] <slangasek> milestone targetting
[20:43] <LaserJock> who has permission for that? Ubuntu Drivers?
[20:43] <slangasek> I'm not sure
[20:44] <slangasek> I think it's wider than drivers
[20:46] <LaserJock> slangasek: how do you target a milestone? I don't see anything obvious in the UI?
[20:47] <slangasek> LaserJock: it's in the status/importance/assignment pull-out menu
[20:47] <LaserJock> bah
[20:47] <LaserJock> I just figured it out
[20:57] <rockstar_> Anyone have a really good tutorial for creating a pbuilder or sbuild environment?  I'm trying to build mine based off of too many different howtos that don't seem to match up
[20:59] <LaserJock> rockstar_: yeah, there are good ones for both
[20:59] <LaserJock> https://help.ubuntu.com/community/SbuildLVMHowto
[20:59] <rockstar_> Either/or is fine.  I'm just looking to build something sane
[21:00] <LaserJock> https://wiki.ubuntu.com/PbuilderHowto
[21:06] <mok0_> rockstar_: the sbuild howto requires you to have an lvm volume with room to spare
[21:06] <rockstar_> mok0_, Yea, I see that.  Not sure if that's the route I want to go with my build system.
[21:07] <mok0_> rockstar_: it's a lot easier to set up a pbuilder
[21:07] <rockstar_> mok0_, noted, thanks
[21:07] <LaserJock> well
[21:08] <LaserJock> actually if you are familiar with LVM and have spare LVM space sbuild/LVM is easier to set up IMO
[21:08] <LaserJock> other than if you want just a single pbuilder
[21:09]  * mok0_ just recently set up a whole series of sbuilders and is very happy with them
[21:09] <LaserJock> keescook's script creates everything for you
[21:09] <LaserJock> so all you need is free LVM space
[21:10] <Lamego> you can use sbuild with a file based chroot, but it will not be as fast as using LVM
[21:10] <LaserJock> although I guess it did take me a bit to get them to use a common apt cache
[21:11] <ssweeny> i did
[21:11] <Lamego> setting apt-cache is easy :P
[21:11] <LaserJock> Lamego: it will also get messed up
[21:11] <Lamego> LaserJock, not really, I use it daily, no problems
[21:11] <LaserJock> oh wait
[21:11] <Lamego> i mean file based, not dir based
[21:12] <LaserJock> oh, right, sorry
[21:12] <Lamego> it does take 12s, schroot/exit
[21:12] <LaserJock> well, pbuilder has to do the same thing right?
[21:13] <Lamego> never used pbuilder, but I guess so
[21:13] <Lamego> but I believe it is easier to interact with a schroot
[21:14] <mok0_> Another possibiliby is cowbuilder, which is nearly as fast as sbuilder
[21:16] <ScottK> mok0_: Did you do your xtide uploads?
[21:16] <LaserJock> Lamego: how did you configure a common apt cache in sbuild?
[21:16] <LaserJock> I ended up compiling a new schroot from Debian
[21:16] <mok0_> ScottK: I asked for the FFe clearance for xtide, and for xtide-data I subscribed ubuntu-archive
[21:16] <Lamego> LaserJock, I have a script which does the initial scrhoot setup, it clones my sources.list which points to the localhost apt-cache
[21:17] <ScottK> mok0_: What's the bug again for xtide?
[21:17] <mok0_> hang on
[21:17] <LaserJock> Lamego: oh, I meant actually bindmounting an apt cache directory into the chroot
[21:18] <mok0_> bug 188086
[21:18] <ubotu> Launchpad bug 188086 in xtide "[needs-merge] xtide-2.9.5-2 from sid" [Wishlist,Confirmed] https://launchpad.net/bugs/188086
[21:18] <Lamego> LaserJock, ah, I am not doing that any more, I did on the past with a bind mount, now I am using apt-cache, the http cache
[21:19] <LaserJock> I guess it would work pretty much just as well
[21:19] <ScottK> mok0_: I just confirmed no FFe needed, so go ahead and upload.
[21:20] <mok0_> So I just build the source package on my own machine and upload it?
[21:20] <ScottK> mok0_: Yep.
[21:20] <mok0_> ... and the sync is done by the archive admins, right?
[21:20] <Lamego> yes, but the bind mount is a bit more "dirty", you need to change the schroot mount script
[21:20] <ScottK> mok0_: Make sure to build with -v to get all the debian/changelog entries since the last Ubuntu on in .changes.
[21:21] <ScottK> mok0_: Yes.
[21:21] <mok0_> ok
[21:21] <ScottK> on/one
[21:21] <LaserJock> Lamego: on the other hand you have to set up apt-cacher
[21:22] <Lamego> LaserJock, which is simple, install & enable & source.lst change :)
[21:22] <LaserJock> well, sort of simply
[21:22] <LaserJock> I've had problems with it
[21:22] <Lamego> and also because I have both 32bits and 64bits
[21:23] <Lamego> I had problems with apt-proxy, moved to apt-cacher later
[21:25] <nixternal> anyone feel like doing a backport at all? if so, look at backporting the bitlbee in hardy to previous releases, otherwise everyone not using Hardy will not be able to get on Yahoo
[21:25]  * nixternal gets ready for skewl
[21:35] <dhaval> how does one get a package added to ubuntu?
[21:38] <pochu> !newpackage | dhaval
[21:38] <ubotu> dhaval: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[21:38] <pochu> !revu
[21:38] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[21:38] <dhaval> pochu, thanks!
[21:39] <pochu> no probs. what package is it?
[21:39] <dhaval> pochu, so how tough would it be find two developers to review the code?
[21:39] <dhaval> pochu, its still under development, i hope to have it in position to package it by may, http://libcg.sf.net
[21:40] <dhaval> pochu, its a library to allow userspace applications to easily exploit a kernel feature known as control groups
[21:41] <pochu> dhaval: it won't be accepted until at least when Hardy is released
[21:41] <pochu> I mean, it needs to go to Intrepid, as Hardy is frozen
[21:41] <dhaval> pochu, also another quick question, the answer to which i can't find with a quick glance, is tehre some agreement to be signed with canonical or something like that before thy will start accepting it?
[21:41] <dhaval> pochu, right, I am aware of that
[21:41] <pochu> you can start packaging it now, of course, and even get acks
[21:41] <pochu> err, no
[21:41] <dhaval> pochu, ah, first i would like to stabilise it :)
[21:42] <dhaval> pochu, it should be in a position ot be packaged sometime mid may i guess
[21:42] <pochu> Canonical sponsors ubuntu, but it's up to MOTUs to upload packages to Universe
[21:42] <pochu> that's fine then
[21:42] <dhaval> pochu, you are more tahn welcome to join the list and influence the development
[21:43] <pochu> although have in mind there will likely be quite more packages to be reviewed, so the sooner the better
[21:44] <ScottK> dhaval: The major legal/contractual requirement is that the package be licensed appropriately for inclusion in Ubuntu.
[21:44] <dhaval> pochu, true, but it has to be ready ot be reviewed, unless of course folks are willing to review it as we keep churning out patches
[21:44] <dhaval> ScottK, LGPL should be allowed right?
[21:44] <ScottK> dhaval: Absolutely.
[21:45] <dhaval> right, so libcg is licensed under LGPL
[21:48] <blueyed> dhaval: I would be glad to review it! (I'm MOTU)
[21:49] <mok0_> uhuh, another glibc build on the way...
[21:49] <dhaval> blueyed, cool! thanks! i would really love it if you joined in as we develop and give your feedback (all reviews are very well appreciated!)
[21:50] <blueyed> dhaval: sure, just let me know when there's something to test.
[22:00] <ScottK> mok0_: Congratulations on your first upload.
[22:00] <mok0_> ScottK: :-D
[22:00] <ScottK> mok0_: Now get to work ...
[22:00] <sebner> ScottK: would you mind ACKing #210849 ?
[22:00] <sebner> bug #210849
[22:00] <ubotu> Launchpad bug 210849 in conky "[FFe] Please sync conky 1.5.1-1 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/210849
[22:01] <sebner> mok0_: ah congrats also from my side
[22:02] <ScottK> sebner: How many of the conky bugs does it fix? https://bugs.launchpad.net/ubuntu/+source/conky
[22:02] <mok0_> sebner: thanks! I am having fun watching the build queue now :-P
[22:04] <sebner> ScottK: likely bug #158933
[22:04] <ubotu> Launchpad bug 158933 in conky "Conky is leaking memory at a very fast rate" [Undecided,New] https://launchpad.net/bugs/158933
[22:04] <sebner> ScottK: beside that a "non-reported-yet" segfault
[22:04] <ScottK> Just that one?
[22:05] <sebner> ScottK: ehm have you checked how many conky bugs are currently open? and for hardy? 2 I think
[22:05] <ScottK> sebner: I see 4 other than the sync.
[22:06] <ScottK> sebner: Are you subscribed for conky bugmail and are you going to mind after the package if there ther problems?
[22:06] <sebner> ScottK: I have good contacts to debian maintainer so yes
[22:09] <ScottK> OK.
[22:09] <sebner> ScottK: but If you are unsure please N'ACK
[22:09] <ScottK> sebner: Approved.
[22:09] <sebner> ^^
[22:10] <sebner> ScottK: thanks
[22:10] <ScottK> sebner: I'm sure if there are problems I'm get to torture you into fixing them.  If there aren't, the distro is improved.  Either way I win.
[22:10] <sebner> ScottK: Ok then ^^
[22:12] <sebner> ScottK: btw, can Firefox break debdiffs during upload?
[22:12] <ScottK> Dunno.  I don't much use Firefox.
[22:12] <sebner> ScottK: e.g bug #65036
[22:12] <ubotu> Launchpad bug 65036 in exim4 "Minor typo in docs" [Low,New] https://launchpad.net/bugs/65036
[22:14] <sebner> k, nvm then
[22:16] <blueyed> sebner: only displaying is b0rked.. I've changed the content type of the attachment to plain/text, now it looks better.
[22:16] <blueyed> sebner: you also want to check the "is a patch" box.
[22:16] <sebner> blueyed: cool.thank :D Never had problems with that before though
[22:17] <blueyed> sebner: from my experience, .debdiff uploads get the correct content type on upload though.. yeah, maybe a new bug then?
[22:18] <sebner> blueyed: new one?
[22:18] <blueyed> sebner: because of "never had problems with that before though"
[22:19] <sebner> blueyed: ehm this is not my first contribution to ubuntu ^^
[22:19] <blueyed> sebner: what I'm saying.. e.g. a "new bug" in firefox or launchpad, not handling the uploads correctly automatically.
[22:20] <POX_> RainCT: huh? I changed the field before uploading
[22:20] <sebner> blueyed: ah^^ sry. I'm too tired to understand what people say xD
[22:21] <RainCT> POX_: yeh, got "svn: Out of date" :)
[22:21] <POX_> RainCT: btw, join #debian-pythonm or they kick me from this channel for being offtopic
[22:21] <RainCT> POX_: have you added a changelog entry?
[22:21] <POX_> RainCT: it's "Initial release"
[22:21] <POX_> see tags
[22:22] <RainCT> POX_: ah, thought it had already been uploaded before
[22:39] <sebner> gn8 folks
[23:04] <mok0_> TheMuso: ping
[23:04] <TheMuso> mok0_: pong
[23:04] <mok0_> Hi TheMuso, I am pinging you to ask if you would add me to ~ubuntu-universe-sponsors :-)
[23:05] <TheMuso> mok0_: Sure. Whats your LP username?
[23:05] <mok0_> mok0
[23:06] <TheMuso> mok0_: Give me a sec.
[23:06] <mok0_> TheMuso: It's no hurry
[23:07] <TheMuso> mok0_: done
[23:07] <crimsun> james_w: no, I stepped down last year, but I punch the source every once in a while.
[23:07] <mok0_> TheMuso: thanks!!
[23:07] <TheMuso> mok0_: You're welcome.
[23:07] <TheMuso> mok0_: Thanks for joining, and helping out.
[23:07] <crimsun> james_w: I already feed hints, etc., to pkg-devel-alsa
[23:08] <mok0_> yay, I got another icon :-P