[00:01] Dossy: any problems with it? === iceman is now known as gluck === gluck is now known as Iceman === Iceman is now known as gluck === danielm_ is now known as danielm === jamesfoster is now known as jamessfoster [02:19] 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] Legendario: https://wiki.ubuntu.com/UbuntuDevelopment/Merging ? [02:27] thanks RAOF, you're the one that always answers my question... :-D [02:28] Heya gang [02:28] Yo! bddebian! [02:29] Hello RAOF [02:34] hey bddebian [02:34] Hi protonchris [03:48] pochu, yeah - vncconfig bug - I'd like to help make sure the fix makes it into hardy or whatever [03:48] https://bugs.launchpad.net/ubuntu/+source/vnc4/+bug/119982 [03:48] Launchpad bug 119982 in vnc4 "amd64 vncconfig crashes" [Undecided,Confirmed] === kitterma is now known as ScottK2 [04:27] Dossy, that bug is irrelevant if bug 184225 isn't fixed [04:27] Launchpad bug 184225 in vnc4 "FTBFS in latest archive rebuild test" [High,Confirmed] https://launchpad.net/bugs/184225 [04:38] superm1: that's strange - it builds for me ... what version of gcc was used there? [04:38] Dossy, are you building on hardy? [04:39] No, gutsy ... ah. [04:39] Still, it'd be worth backporting a fix to bug #119982 to gutsy, no? [04:39] Launchpad bug 119982 in vnc4 "amd64 vncconfig crashes" [Undecided,Confirmed] https://launchpad.net/bugs/119982 [04:39] yeah. and not to mention the related bug that all the xorg stuff in there is all out of date [04:39] the new stuff doesnt compile [04:39] i spent a few evenings at it and made a fair deal of progress [04:39] but never successful [04:40] can't be backported unless we have a "working" vnc :) [04:40] you know, to backport from [04:40] Hm. I guess I should set up a hardy VM too, then [04:40] well, patching the existing vnc4server from gutsy w/ the fix, fixes the problem :) [04:40] https://code.edge.launchpad.net/~superm1/+junk/vnc4 [04:40] https://code.edge.launchpad.net/~superm1/baracuda/trunk [04:40] if you want to pick up where I left off at [04:41] "baracuda"? [04:44] what version of x11proto-render-dev is in hardy? [04:44] !info x11proto-render-dev hardy [04:44] Package x11proto-render-dev does not exist in hardy [04:44] oh. wacky. [04:44] !info x11proto-render-dev gutsy [04:44] Package x11proto-render-dev does not exist in gutsy [04:44] uh, that's wrong. [04:45] So, ubotu is wrong. It's version 0.9.3 [04:51] and gutsy is 0.9.2. I wonder what changed between the two versions. [04:55] So ... the hurdle here is getting the vnc4 stuff to build on hardy? OK - guess I'm setting up a hardy image :) [04:57] Is there a way to find out what packages were installed at the time of the sbuild? [05:01] What is the opposite of "subtle"? [05:01] Other than "anvilicious" [05:02] obvious? [05:03] No, not in that sense :) [05:03] Well, in what sense, then? :) [05:04] 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] Unmistakable? [05:05] Gah... no :) [05:05] never mind [05:05] :) [05:11] what is the best virtual machine software for running Windows XP Professional and Fruti Loops Audio Software with USB Midi Keyboard [05:16] realtime audio in virtualized guest? wow, you're brave :) [06:31] good morning [06:33] morning dholbach [06:33] hiya LaserJock [06:40] Dossy, baracuda was a fork of realvnc [06:40] intended to work on xorg [06:40] whereas realvnc was always patched to make it work [06:41] good morning dholbach [06:41] hey superm1 [06:42] whatcha been up to these days? [06:44] j #gnu [06:44] gr === asac_ is now known as asac [06:46] superm1: lots and lots of small stuff [07:13] bug #210860 [07:13] Launchpad bug 210860 in scim-m17n "After adding scim-m17n scim does not work automatically" [Undecided,New] https://launchpad.net/bugs/210860 [07:13] Good morning [07:36] good morning, MOTU! [07:36] Morning. [12:23] heya [12:43] Fujitsu: ping [12:43] zul: Hi. [12:44] Fujitsu: is nagios2 in a state to go into main? [12:45] zul: In what respect? [12:45] Fujitsu: see invite. [12:46] Fujitsu: ie If I take the time to do a MIR it wont get rejected and would be easy to promote? [12:46] emgent: I tried to join earlier, but I don't have the key. [12:46] ok see notice :) [12:47] 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] Hm, only two non-nagios, actually. [12:47] libnet-smtp-perl and libradius1. So it shouldn't be hard. [12:49] *snmp-perl === jono is now known as severedfifth === severedfifth is now known as jono [13:30] ScottK? [13:30] Yes [13:31] mok0: ? [13:31] I would like to upload the xtide packages, but I want to make sure that it's ok FFe-wise [13:32] OK. Bug #? [13:32] bug 188086 [13:32] Launchpad bug 188086 in xtide "[needs-merge] xtide-2.9.5-2 from sid" [Wishlist,Confirmed] https://launchpad.net/bugs/188086 [13:32] Looking [13:32] bug 188093 [13:32] Launchpad bug 188093 in xtide-data "[needs-sync] xtide-data-20070318-1 from sid" [Wishlist,Confirmed] https://launchpad.net/bugs/188093 [13:32] They belong together [13:34] Making sure I understand ... [13:35] xtide needs a merge. It looks like it also needs an FFe unless the upstream version is bugfix only. [13:35] xtide-data is just a new revision. [13:35] mok0: Is that right? [13:35] right [13:36] the problem is with the current xtide in hardy [13:36] For xtide are there new features or is it just bugfixes? [13:36] I introduced (in agreement with the DM) a change which we later revoked [13:37] ScottK; but the upload got hung in LP as you can see [13:37] 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] I could, but I am pretty sure that there is no real difference [13:38] (Except we would loose the icons I made) [13:38] That gets back then to the question of are there new features in the new xtide version? [13:39] I can investigate it further [13:39] I dont want my first upload to be a FF violation :-) [13:40] 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] 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] If it's got features you need to fill out an FFe. [13:40] ScottK; got it [13:40] \sh: We don't normally bother. It'll just go off our radar once it goes Fix Released. [13:40] ScottK: what about xtide-data? [13:41] <\sh> ScottK, good then :) [13:41] mok0: That's just a new revision, right? You should be able to just do that one. [13:41] ScottK: great [13:43] mok0: I did review xtide's changelog diff and it looked like bug fix only [13:43] pochu: that's my impression too, but it's been a while since I looked at it [13:47] 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] gtg [13:49] thanks pochu [13:53] <\sh> so...wireshark 1.0.0-1 synced [13:54] hardy? [13:54] <\sh> yepp [13:54] 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] ok cool [13:57] * emgent adding it in todolist. [13:58] * \sh has some nice octave crap on his todo [13:58] :) [14:01] omg it's late.. [14:01] i go to office [14:01] see you later people [14:24] 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] http://launchpadlibrarian.net/13092176/buildlog_ubuntu-hardy-lpia.xine-plugin_1.0.1~cvs20070523-1ubuntu2_FAILEDTOBUILD.txt.gz [14:25] looks like that the version checks are busted [14:25] *** 'xine-config --version' returned -1717986918.1072798105.-1717986918, but XINE (1072798105.858993459.1076245299) [14:25] ouch [14:25] $ xine-config --version [14:25] 1.1.11.1 [14:25] thats what i get :/ [14:28] mok0: I'm curious if you have an opinion on Bug 66862 [14:28] Launchpad bug 66862 in python-numpy "scipy not built with atlas support ?" [Undecided,Confirmed] https://launchpad.net/bugs/66862 [14:28] hm [14:29] it should build depend on libatlas-base-dev [14:30] not atlas3-base [14:30] after gfortran transition... [14:30] ok i think i have the fix. cheers [14:31] Otherwise it can't find the right lapack library, and I bet it switches off lapack support then [14:36] asac: it always helps talking to one self... === Sebast1an is now known as Sebastian [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] hi all [15:15] * cody-somerville is excited about the change. [15:15] cody-somerville: Welcome to yet another group :) [15:16] :) [15:16] persia: is it the way to implement the decision about MC assigning ubuntu membership for good, not yet ready for MOTUness contributor? [15:16] 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] warp10: While it does implement the recent CC decision, it will also be used to make things easier for contributors. [15:19] 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] persia if I understand correctly, every current contributor is encourage to apply to that new group [15:21] 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] 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] persia: We don't have bzr managed packages in Universe [15:21] persia: of course [15:21] ScottK: Are they all in multiverse now? The one I remember most closely is mplayer. [15:22] persia: There is no process agreement. The agreed process is that the canonical source for our packages is the Debian Source package. [15:22] persia: it is the way for the MC to manage to grant membership ? we already discussed that a long time ago [15:22] :) [15:22] persia: I also see that teams are being renamed. [15:22] ScottK: I don't disagree. On the other hand, there are a couple packages listed that way. Maybe only mplayer. [15:23] persia: Just because someone stuffed some VCS headers into a package doesn't mean anything. [15:23] ScottK: Only the one team is being renamed. [15:23] persia: On what basis? [15:23] Who has agreed to this? [15:23] It's been done with no discussion. [15:24] 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] persia: MC has no authority to change process. [15:25] persia: It seems no comment is needed since MC has already acted and dictated. [15:26] 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] There's also automatic expiration. [15:26] There is using a VCS. [15:27] Expiration hasn't been done yet, and it's a valid point. I'll take it to the next MOTU Meeting. [15:27] persia: This is not written as a proposal, but as an MC fiat. [15:27] Some packages use a VCS. I don't think this is a new argument. [15:27] persia: We've been through the VCS business many times before and the answer was no. [15:28] persia: Where in the sponsorship process is there a VCS? [15:28] persia: is there somewhere where sponsors can found a more detailled description of the requirements to integrate that team ? [15:29] ScottK: VCS is not part of sponsorship. That's agreed. [15:30] persia: This fiat changes that. [15:30] 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] 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] ScottK: Which change? The new team? That was in part the implementation of the previous CC decision. [15:32] persia: Yes. [15:32] The team structure has been changed with not even notification to the community. [15:33] 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] I discovered it because I happen to be subscribed to a wiki page. [15:33] ScottK: apart from the de facto decision, do you disagree with it? [15:34] 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] persia: Not true. [15:34] mok0: congrats btw :) [15:34] huats: thanks :-) [15:34] I don't understand this as fiat, and it can be undone, if it is. [15:34] mok0: Except for the VCS business, I think it's in the right area. [15:35] 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] I read it such that the VCS is an option for contributors [15:35] persia: Look where this link goes https://launchpad.net/~ubuntu-universe-contributors [15:35] I didn't say "people should use VCS" [15:35] Debian makes heavy use of VCS. They must see some benefit. Why don't we see the same benefit? [15:35] I think there could be some benefit in group maintenance [15:35] 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] cody-somerville: Because it makes merging annoying, especially as LP is restricted to bzr, and bzr is almost never used in Debian. === hexmode` is now known as hexmode [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] persia: I will argue strongly against any mention of bzr in particular and vcs in general. [15:36] But bzr and git are very similar in their functionality [15:37] 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] I think you can run whatever you want on your side [15:38] 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] persia: Then put it in some documentation related to that. Not in anything Universe related. [15:39] ScottK: new ubuntu-local packages are in universe. Please suggest text for a correction [15:39] persia: It's orthoganal to the question. Just delete it. [15:40] 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] 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] 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] 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] code monkeys? who came up with that name? [15:43] If I understand this correctly; the overall intention is to make it easier for "smaller" contributors to contribute? [15:44] (ie: people like me ;)) [15:44] siretart: Don't worry. MC have it all figured out. It'll be wonderful. We can just go about our business. [15:44] slicer: Right. [15:44] ScottK: REVU upload is still through the open team ~ubuntu-code-monkeys (formerly know as ~ubuntu-universe-contributors) [15:44] ScottK: lol [15:44] ScottK: I disagree with that entirely. [15:44] persia: If so, I heartily applaud it :) [15:44] 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] persia: Actions speak louder than words and the actions started before there was even an announcement. [15:45] 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] geser, persia: Why was it renamed? [15:45] slicer: Yes. [15:45] persia: well, then it should be stated in terms of skills, etc [15:46] mok0: Maybe. I've never seen a list of requirements for any of the teams that was a firm set of rules. [15:46] Or to be more correct it appears action and the announcement happened at roughly the same time. [15:46] persia: I think it is difficult to understand if you don't already know the system [15:46] ScottK: We created a LP group, and sent an email. If you disagree, help me understand how, and we can change it. [15:47] Given that the plan is being excecuted already, it seems quite clear that the decision is taken and it's done. [15:47] 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] ... [15:47] While I hope the new group will inform changes in process, none are currently imposed. [15:47] ScottK: I assume to show that there is action in ubuntu development. TBH, those renames are pretty confusing to me [15:47] persia: I disagree that MC has any authority to make any changes. [15:47] ScottK: No changes have been made. I sent an email. [15:47] persia: LP teams have been changed already. That is a change. [15:47] 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] ScottK: OK. If the rename is your issue, I'll rename it back. Is that it, or is there something else? [15:48] slicer: #launchpad can likely help you with that [15:48] persia: My issue is action in advance of decision by the MOTU community. [15:48] persia: Ah, thanks :) [15:49] ScottK: Umm. By "action" do you mean a team rename, or something else. [15:49] <\sh> -ETOOMUCHREDTAPE [15:49] 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] persia: I think ScottK thinks there should have been some discussion first [15:50] * siretart tends to agree with ScottK [15:50] mok0: I'd put it stronger. I think that under our agreed method of making policy, MC has exceeded it's authority. [15:50] 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] 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] persia: Put back what's been done and let's discuss it all. [15:51] 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] it seems that we need a defined process for changing processes [15:51] 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] siretart: We've done that. [15:52] ScottK: we did? [15:52] siretart: It's my understanding that the process is we discuss it at a MOTU meeting and vote. [15:52] 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] 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] I see. [15:53] We at least have a basic mechanism defined. It may or may not need more structure. [15:53] right [15:54] is this worth a bof in prague? [15:54] 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] I feel like it might. I thought I followed all the processes. I'd like a BOF [15:54] ScottK: Anyone can make an LP team. Why are you mad about Universe Hackers? [15:54] 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] siretart: Help me understand how. Please. [15:55] persia: I'm mad about unilateral action. What that action is is pretty irrelevant. [15:55] 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] ScottK: That happens every time I upload. Further, this was based on things discussed in MOTU Meetings and CC Meetings. [15:55] Help me understand where I messed up, so I can undo what I can, and do it right. [15:56] persia: To start with you just broke REVU keyring syncs. [15:56] persia: That should be clue enough that there was insufficient discussion. [15:56] 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] 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] No problem. I'm happy to undo the rename, and whether for now or forever isn't important to me. [15:57] heya [15:57] 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] besides, this is really a pretty unfortunate time for doing process change. lets defer that to after hardy release [15:58] ScottK: I'll dig up my proposals then, all sent to lists or presented at meetings. Hold on for some URLs... [15:58] 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] (after unrenaming the team) [15:58] persia: Be sure to find the one that talks about Ubuntu Code Monkeys. [15:59] in principal. but I agree to scottk that this hasn't been discussed in appropriate length and forum [15:59] even dholbach told me in a private mail that this discussion did happen on motu-council, but was rather hidden [16:00] 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] 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] 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] \sh: there is nothing hidden about that mail. he asked me privately to transfer ownership of the lp team 'ubuntu-universe-contributors' [16:01] \sh: and I insist that we need to allow private discussion and chatter, even about development, processes and change [16:02] siretart: Sure, but private disucssion followed by action with no public discussion is what's at issue. [16:02] https://launchpad.net/~ubuntu-universe-contributors [16:02] OOPS-824EB60 -- code monkeys are gone... [16:03] <\sh> siretart, I don't say nobody can discuss in private, quite the opposite [16:03] persia: Thank you. I'll calm down and consider the main points. [16:03] ScottK: I wasn't involved in the decision process. I'm not guilty! :) [16:03] siretart: Of course. [16:03] Well this is a a good time to reboot the discussion [16:03] ScottK: Thank you. I'm more than happy to undo things as required, but I'll argue for some of them. [16:04] ScottK: I agree with you about process, and thought I had done it correctly with the new team. [16:04] 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] persia: What is there that's been done that is hard to undo? [16:04] 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] 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] 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] persia: I don't mind the team existing as long as it's made clear it's a placeholder for now. [16:05] 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] 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] \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.... === tonyyarusso is now known as anthony [16:06] 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] \sh: exactly, which is what often happens. [16:07] 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 === anthony is now known as tonyyarusso [16:07] I think these changes are pointless... [16:07] pochu: VCS is not part of our sponsorship process. [16:07] 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] pochu: Until someone shows me a VCS that scales to 20,000 packages, it's not something that we can use. [16:08] hct! [16:08] \sh: Right. The new team is that, and ought get granted what rights seem appropriate. [16:09] 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] 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] 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] 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] cody-somerville: i don't think so, this group has nothing to do with packaging/hacking [16:10] 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] and I agree with ScottK this should have been proposed first... [16:10] 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] jeromeg, I'm pretty sure it has everything to do with packaging/hacking [16:11] jeromeg, Hence why it is called the "Ubuntu Universe Hackers". [16:11] cody-somerville: ubuntu bug control ? [16:12] 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] \sh, ... [16:13] cody-somerville: by this i meant your proposal of making it part of ubuntu ug control, sorry if I was not clear [16:13] cody-somerville: do you also got the mail and are thinking. Heee? [16:15] see my e-mail === x-spec-t is now known as Spec [16:20] OK. Unmonkeying complete (https://wiki.ubuntu.com/UbuntuDevelopers?action=fullsearch&context=180&value=code-monkeys&fullsearch=Text) [16:20] cody-somerville: it worth what it worth but I think that you email introduces a good point [16:21] (I mean it is just my opinion) [16:22] persia: Thank you. [16:22] * ScottK needs to run. Back later. [16:23] 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. === danielm_ is now known as danielm [16:57] slomo__, you around to take a peek at mscore? [17:37] 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] 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] once that fix is in then all that needs to happen for the first package is a rebuild. [17:38] I'm now thinking about version numbers. The change is already in Debian's packages which are newer. [17:39] so I could go build1 for both, so we just get Debian's packages after release with no intervention [17:39] ubuntu1 for the second package as it is a code change, and build1 for the first, as it isn't [17:40] however until the merge was done this could lead to a FTBFS, or at least a dep-wait. [17:40] 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] https://bugs.edge.launchpad.net/ubuntu/+source/debian-edu/+bug/190682 if anyone wants specifics [17:43] 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] it's a milestoned bug for Hardy. [17:46] dholbach: universe-code-monkeys? [17:47] LaserJock: sounds funny :D [17:48] 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] persia: thanks [17:50] 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] Best to set versioned build-depends if you need them. Otherwise, it doesn't flag right for someone trying to backport. [17:54] For the same reason, best not to set versioned build-depends if you don't need them. [17:55] heya bddebian [17:55] Heya gang [17:55] Hi sebner [17:59] persia: well, it will still build with the old version, you'll just end up with the same bug again. [17:59] 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] 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] true, thanks [18:08] 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] libavutil.so.49 exists... it's just called /usr/lib/libavutil.so.1d.49.3.0 [18:09] is there a reason why it adds a 1d in front and a 3.0 at the end of the filename? [18:10] if I symbolic link it it runs fine. [18:10] lol... i hope this is the right place to ask this kind of question [18:11] 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] got ya === danielm_ is now known as daneilm === daneilm is now known as danielm [18:12] just wonderinf if I modify the debian/changelog if it wants to change the name of the shared libraries [18:13] just doing that shouldn't do it. [18:20] 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] 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] (and you misspelled my name :p) [18:22] 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] 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] 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] persia: It is not possible to fix any other way. The newer java is simply too new for batik 1.6. :-P [18:25] 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] 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] 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] (That's part of why I suggested you mail the list before, instead of just answering your question in February) [19:12] asac, hi [19:12] hi [19:13] I have a question (excuse my English) [19:14] yeah ... if its mozilla related please use #ubuntu-mozillateam [19:14] otherwise go ahead :) [19:14] :P [19:14] xD [19:15] ok === danielm_ is now known as danielm [19:45] persia: how is the Universe Hackers thing going? [19:50]