[12:08] that's why i'd like to introduce another idea for solving this: in my opinion what makes a transition a good one, is a good plan [12:09] so having somebody responsible for a task who keeps an eye on it, is more important [12:09] <\sh> when there are more work then in normal times (breezy is not really normal) [12:09] a aalib transition manager or something [12:09] for example [12:09] <\sh> s/are/is/ [12:09] dholbach: this would my my suggestion/expectations from the teams [12:09] the c++ transition was a good example for this - our beloved doko did an awesome job in planning this [12:09] dholbach: That's mor along the lines of what I was thinking [12:09] <\sh> then we should split up our strength, and say ok, 5 members here, 5 members there and 5 members are doing something else also important [12:09] dholbach: having a lead and interested people for a specific topic which need to get done [12:10] the lead should have an overview and be able to explain what is going on [12:10] absolutely [12:11] write a nice wiki page, with notes about the transition and a list to tick things off - and pushes people into it, creates some party atmosphere behind it all :) [12:11] this sounds just like the way tasks are planned already in ubuntu: One lead, perhaps a second and a bunch of worker drones [12:11] dholbach: sounds good, just like what you did for hoary ;) [12:11] Seveas: Where is this happening? [12:11] ajmitch: thanks for the flowers :-p [12:12] bddebian, http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals [12:12] bddebian: breezy goals, lead & seconds were assigned at the kickoff meeting [12:12] <\sh> actually, I don't like the lead stuff for those works [12:12] Seveas: Ah, nice [12:12] \sh: they're not supposed to do the work all themselves [12:13] <\sh> dholbach: right..but this I don't mean... [12:13] ah ok... maybe i got you wrong [12:13] \sh, you need a point of contact... someone who is responsible and trys to coordinate a bit [12:13] you want more of a coordinator [12:13] <\sh> ok, we have some good members working on sources..the others are working as good reviewers..so everybody has their own field, right? [12:14] i'm not quite sure, if all the stuff doesnt really go hand in hand [12:14] i mean reviewing and fixing is all about fixing source packages :) [12:14] <\sh> so if there is a lot of "source" work to do, those members will help in the transitions, while the others are doing review or new motu trainings etc. [12:15] yes, both teaches you a lot... you shouldnt do one without the other [12:15] <\sh> the rest of the time, it will stay like normal work...merges, new uploads, sourcework, review, training at the same time and everybody is helping [12:15] \sh: hm. so you want to make people concentrating on one specific topic? [12:15] I just try to understand you [12:15] <\sh> siretart: yes...in busy times like these days e.g. [12:15] siretart, that would be desirable, but happens anyway imho [12:16] Please don't take this the wrong way but are there people concentrating on training new MOTU's? [12:16] <\sh> ogra: but u have to see, like those merges now, if we would have this work in our eyes, we wouldn't be in a hurry and we wouldn't be in this situation far away from the timetable [12:17] bddebian: we should all be assisting each other. [12:17] bddebian: let's discuss this later, ok? [12:17] bddebian, depending on your questions, yes === tseng [~tseng@tseng2.ath.cx] has joined #ubuntu-meeting [12:17] siretart: ok [12:17] hey tseng [12:17] hi [12:17] <\sh> tseng: welcome [12:17] welcome tseng [12:17] hey tseng :) [12:17] hey tseng, how are you? [12:17] morning tseng [12:17] i will be just watching I think [12:17] tseng: https://wiki.ubuntu.com/MOTUMeeting - first point [12:17] \hif everybody had looked at the merge stuff first, we wouldnt have had 250 pkgs there [12:18] bddebian: i hope i'll be able to do more on this front in 4 weeks [12:18] \sh, even [12:18] ogra: yes, that's why i suggest some leads organizing the different motu actions [12:18] Like I said, don't take that the wrong way. Everyone has been very helpful, I just don't see a specific "direction" so to speak. [12:18] <\sh> ogra: that's what I meant...we had our eyes on something else as prio 1, and forget about those merges [12:18] dholbach, nope, its a process we must establish... [12:18] ogra: yeah, I started doing some merges right at the beginning of the breezy cycle with my list [12:19] ogra: but quickly ran out of spare time [12:19] ogra: a process like what? [12:19] <\sh> ajmitch: so did I during the cxx trans [12:19] if you touch a package with -ubuntuX version you should always look for mergers first [12:19] what about this as a middle point. Somebody dispatching tasks on a "do-it-if-you-can" way ? [12:19] \sh: the problem I have with this suggestion is, that I have different interests for breezy, and I try to accomplish them all. So focusing on one topic would mean choosing one topic I'd like to accomplish [12:19] ogra: that will reduce forking from debian [12:19] ogra: ah ok yes [12:19] like writing a wiki page [12:19] dholbach, if we do the merges constantly, we dont have this many [12:19] ogra: absolutely [12:20] comadreja: you mean as in assigning jobs? [12:20] <\sh> siretart: actually we all have "different" interessts ... I'm far from being finished with my projects I wanted to accomplish [12:20] ajmitch, yes, exactly... it will still be a fork, but the changes are smaller [12:20] To be fair, though, several MOTUs have been busy otherwise (tritium, dholbach, and myself at least). As I see it, the problem isn't so much one of "we spent too much time doing non-merge stuff" but "we didn't have time at all". [12:20] dholbach : like in writing in a wiki page a priority list [12:20] comadreja: ah ok, i see [12:20] ogra: well we have to try & keep as close to debian as possible to avoid work for us [12:20] we have to be naturally lazy! ;) [12:20] <\sh> crimsun: this is something u will always have for volunteer work [12:21] crimsun, did you look for every -ubuntuX package you touched at MOM first ? [12:21] that way, every single motu can use their time on that... [12:21] i dont like MOM [12:21] <\sh> crimsun: even ogra is too busy to deal with motu stuff right now... [12:21] \sh: do you think planning will be easier, if somebody signs up for such a task force? [12:21] ogra: yep, that's how I've been getting back into the MOTU swing of things. [12:21] <\sh> dholbach: I think it could help...some things are really showstopping us, right, and other things are just slipped out of our hands [12:21] crimsun, ah, great ten... i didnt and was hit by it... [12:22] s/ten/then [12:22] and many others of us too... [12:22] who else thinks that a recruited taskforce will make planning easier? [12:22] tseng: Agreed, it does have it's limitations [12:22] some packages from MOM were already touched in the Cxx transition for example [12:22] dholbach : we first need a scheduler :) [12:23] comadreja: of course, we need the plan first [12:23] I'll join \sh [12:23] <\sh> dholbach: if we have a fighting plan (for breezy+1), we know what transitions have to be done, on what we have to have a closer look (MoMs) etc. then we don't need a taskforce for those things [12:23] to cap it up a bit: we agreed that we need more planning and maybe guys responsible for that, we too agreed, that we rely on volunteers work === sistpoty2 is now known as sistpoty [12:24] \sh: some things just happend and you can't foresee them, because you're not involved with libxyz's upstream [12:24] \sh, note, there will be no X and no Cxx transition... [12:24] \sh: Can you describe what you expect a taskforce to look like? what would be expected from ppl joining a taskforce? give an example [12:24] <\sh> dholbach: things like Xorg yes..but this is ok..this will halt everything [12:24] breezy+1 will be an awesome development cycle [12:24] yeah... let's get back to the TASK FORCE concept planning [12:24] <\sh> ogra: we will have many bugs for breezy+1 [12:24] breezy+1 is going to be different, in that main will be supported by the ubuntu foundation for *5* years [12:25] we need to try & get quality up [12:25] \sh, yes, but a lot less mass transitions and thus a lot more time to play and develop [12:25] ogra: more recruiting! :) [12:25] yay ! [12:26] <\sh> ogra: breezy+1 will be polishing our work now...breezy will be a desert safari ,-) [12:26] <\sh> ok...long story short... [12:26] ok, who wants to make a suggestion that goes beyond "more organization" [12:26] Then you need to either recruit folks that are familiar with hacking/Debian packaging or get some better direction for the NewMOTU process === bddebian ducks [12:26] bddebian: fine, put your suggestions down somewhere :) [12:27] ajmitch: I think I have an suggestion for NewMOTU process, more on this later.. [12:27] ok, as i see it there are 2 options [12:27] siretart: great [12:27] 1) just try it out, whatever happens [12:27] <\sh> ogra: u r involved in all that main stuff...I would like to take u as a "gateway" with main...to plan some important stuff to accomplish for breezy+1 so we can create something like a "MOTU project plan" [12:27] 2) flesh out the process for such a task forces with all it's implications and go from there again [12:27] We could try each having a primary and a secondary "role", if you will. For instance, my primary role would be Mentoring new MOTUs, and my secondary would be Review work (aside from that done as part of mentoring). We could put this on our wiki pages. [12:28] <\sh> ogra: just because u guys have a better overview what will come...and even 5 mins before it happens ,-) [12:28] \sh, sure, lets d that === siretart likes that role concept [12:28] do even [12:29] ok... shall we put up wiki pages up for those ideas and decide over them again? [12:29] this to me sounds like the best plan, since it is more detailed and more goal focused [12:29] dholbach: I second this suggestion. let's move on [12:29] yep [12:29] <\sh> let's do it like that... [12:29] \sh: thanks for bringing the point up - as you see - there are lot of opinions on that [12:30] point two [12:30] but may I suggest some procedure for new MOTU's? [12:30] <\sh> dholbach: yes...likley :) [12:30] it is somehow related to that Team concept [12:30] siretart: fire away [12:30] I propose a mentoring concept for newMOTU's [12:30] dholbach, why do we need to feed them, they give a grown up impression... they can gra it themselves [12:31] grab even [12:31] a bit similar to debian, but not quite. Each new candidate is assigned to one specific motu he uses as mentor [12:31] ogra: siretart wanted to add a new team idea in between [12:31] eh [12:31] ah,oh, ok [12:31] people move really fast in motu right now [12:31] because they can get help from everyone [12:31] the apprentice and the motu aggree on a workflow how to get packages from the apprentice into universe [12:31] <\sh> siretart: gentoo has this concept === CarlFK [~CarlK@c-67-163-43-70.hsd1.il.comcast.net] has joined #ubuntu-meeting [12:32] this may or may not be using revu [12:32] tseng: they wouldn't be limited to this one person, but they'd be their primary contact === ogra doesnt like the mentor concept at all [12:32] ogra: what's wrong with it? [12:32] \sh: I don't know how gentoo works, can you elaborate? [12:32] too much workload on existing motus? [12:33] siretart: what i like about the current process is it's openness [12:33] it drags people more away into a secret corner... i see this with my google students, they arenot very active in the motu world, even if there are often people that could help them better then me [12:33] <\sh> siretart: as u explained...when u want to get the dev status quo for gentoo, u need to have a mentor, which guides u through the whole infra structure and things like that, explains what is important in building ebuilds (in our case debian/*) etc. [12:33] siretart: so more people have a good image of how a motu hopeful proceeds [12:33] ogra: right. [12:33] it tears down the amount of work done with the whole tem [12:33] team [12:33] ok. I see the point raised by dholbach and ogra. === tseng still thinks gentoo is broken [12:34] siretart: but this is a point we will have to discuss soon [12:34] siretart: you were right in bringing this up [12:34] <\sh> siretart: but the other devs don't know the "apprentice" at this time...and most of the times, the new devs will do whatever they want... [12:34] right, you don't want the big happy family to be dysfunctional [12:34] I don't want to take the newbees into secret corners. they should work with the community [12:34] the problem I want to solve is another one: === ogra guesses after breezy+1, when we have lots and lots more people to manage [12:34] as the team grows, we don't want new MOTUs to get lost in the cracks [12:34] <\sh> tseng: it's broken yes [12:35] having a mentor, an apprentice has a an advocate, which really know about the packaging skills of his apprentice [12:35] <\sh> tseng: but it's not against gentoo..it's against their governance :( [12:35] what do you think about this: shall a motu-process2 team sit together and throw some ideas together and form a "spec"? [12:35] so this mentoring concept is rather a more formal process of having packages sponsored [12:35] over which we can decide more formally? [12:35] dholbach: perhaps this would be an idea. === kinjoo [~kinjoo@p54AA677A.dip.t-dialin.net] has left #ubuntu-meeting ["Verlassend"] [12:36] any other opinions? [12:36] dholbach: we might need to schedule another meeting soon then [12:36] yes [12:36] I'll try to write up my ideas on a wiki page and present them the next meeting [12:36] unless we do our debating on the wiki [12:36] super, thanks siretart [12:36] it think it's better to have ideas more fleshed out, before we decide [12:36] this won't be before next week ;) [12:37] may we get to point 2 now? [12:37] <\sh> yes [12:37] siretart, we meet once a month ;) [12:37] please do.. [12:37] take your time [12:37] i proposed this one: "Proceedings of feeding UniverseNewPackages (and Andrew's RFP list) to utnubu-discuss." [12:37] because i found that most of our NEW packages are not announced anywhere and just "end up in the archive" [12:37] don't you think we should push them more into the debian direction? [12:37] dholbach: agreed, very important [12:37] why do we need to feed them, they give a grown up impression... they can grab it themselves lets just point them there [12:38] at the last meeting we resolved to file these RFPS [12:38] there were only SOME reactions RFP/ITP-wise from our side [12:38] ogra: yeah, but *nearly* nobody does it at the moment [12:38] ajmitch, now there is an active group in debian.... [12:38] so i think this should be more of a policy [12:38] dholbach, what ? [12:38] ogra: I know, I see you're in the group [12:38] well, I don't think that it would be very much efford announcing new addition to universe to the utnubu mailing list [12:38] that the package needs to be announced [12:38] <\sh> ogra: u r involved in that utnubu thing [12:38] siretart: ++ [12:39] I've got to get involved there too [12:39] and I think nometa and other debian developers would really appreciate it [12:39] \sh, ogra: yes? === ajmitch has been saying that for awhile though [12:39] <\sh> ogra: how is the mood towards ubuntu patches and new packages at all? [12:39] dholbach, they have browsers eyes and are able to read... lets point them to the page and they can care themselves [12:39] could you create an rss feed from your current tools, and ask them to subscribe to that for timely/reliable info? [12:39] \sh, its ok... the tone is rougher... [12:39] luis_, sure [12:39] <\sh> ogra: rougher? [12:40] luis_, there are RSS feeds for Ubuntu uploads [12:40] <\sh> ogra: in what way? [12:40] \sh: I think it is generally very mixed and depends whom you ask. the utnubu guys seem to be very colaborative. [12:40] but my opinion is that we have enough work to do here... putting this stuff on a wiki page for them is already nice and makes their job easier [12:40] i think it's no problem for anybody to write a mail: "hey, this is my package, it's in the archive, if you have questions, feel free to ask me" [12:40] but in the end its *their* job [12:40] ogra: nobody does that either [12:41] <\sh> actually, I can tell only about my experiences with some maintainers... [12:41] an RSS feed in my opinion is not much of a "relationship", although it's convenient [12:41] <\sh> and these exp. are really mixed [12:41] dholbach, i dont know since when youre subscribed to -utnubu-devel, but they already have tools to produce theur lists [12:41] dholbach: this could be the last step of work of the reviewing team, if a package is accepted into universe, write a small mail for that. I think I could hack something up like that for revu2.. [12:41] ogra: i read all the threads [12:42] who is opposed to add "announce it on utnubu" to our MOTUNewPackagesPolicy? [12:42] dholbach, its their job as import team... its nice of us to offer them something, but i refuse to do their job [12:42] ogra: we're not going to make them debian compliant or uploading or do whatever to the debian archive [12:43] dholbach : I also think it's their job [12:43] ok... any other opinions? [12:43] dholbach, if there are problems with a particular package i'm happy to help if they ask... but still they want to be the ubuntu import team... [12:43] i never thought we'd have that response to writing a mail [12:43] <\sh> ogra: can u give me the subscription address for this utnubu-devel ML? i only see -discuss and -maintainers [12:43] dholbach : that mail could be automated [12:44] \sh, its on alioth.debian.org [12:44] \sh, search for utnubu [12:44] \sh, i meant -discuss above, sorry [12:44] <\sh> ogra: ah ok :) [12:45] dholbach: don't annonce stuff on utnubu [12:45] ogra: perhaps I should try & make it more part of my MOTU responsibilites then? [12:45] ok... we seem to cannot agree here and will rely on volunteer action [12:45] seb128: it think it's ok to announce a new package there - do you think that's a problem or might make us run into problems? [12:45] it's not ok [12:45] I didn't see anyone opposed to the rss feed idea [12:45] ajmitch, i dont see it as a motu responsibility... i see itas a responsibility to make the info public available, but thats all [12:45] this project is not fine [12:46] <\sh> dholbach: I think with new packages not in debian they will come with RFP/ITP process... [12:46] i think we can just offer [12:46] seb128: what are your objections to utnubu? [12:46] ogra: i was talking about making info public available, nothing else :) [12:46] ie: I don't want somebody to just take GNOME stuff from Ubuntu, to put them on the utnubu SVN and non maintain them from here [12:46] Debian expects some quality [12:47] but it might be a start of working together on stuff [12:47] if somebody wants to maintain a GNOME stuff with Debian he should rather work with pkg-gnome [12:47] dholbach, you were talking about announcing it to utnubu, which may end in endless discussions... i dont like to waste my time with that [12:47] seb128: I think that was not nometa's intention [12:47] ie: with people interesting on that [12:47] ogra: announcing, not discussing details :) [12:47] s/interesting/interested/ [12:47] dholbach, you end up with this... see gparted... i dont see the last word spoken there [12:48] dholbach: that's not the place to announce, stuff [12:48] they will grab them [12:48] ogra: that's one case - you can't judge a project after 3-4 weeks [12:48] upload them here rather than at the right place [12:48] dholbach, nope, i know... [12:48] and non-maintain them [12:49] ok, we had quite some interesting points here... :) [12:49] ok, looking at the time, we might hop over to point 3 - is that ok for you? [12:49] please [12:49] if somebody is interested to do the job for Debian he can do it correctly and join the appropriate team and working with thel [12:49] them [12:49] dholbach: go :) [12:49] Trashing of MOTUNewPackages and MOTUToReview in favour of REVU [12:49] the pages are momentarily just lying around [12:50] <\sh> dholbach: when it's in the proper place on an own linode [12:50] and nobody cares after them, some packages already got uploaded to REVU [12:50] \sh: i'm solely talking about the wiki pages mentioned [12:50] <\sh> I will clean them up...on sunday [12:50] <\sh> dholbach: yes... [12:51] \sh: we are discussing the point now :) [12:51] does anybody feel we should keep them for a bit of time? [12:51] \sh: have you heard any news about the linode server? [12:51] <\sh> siretart: no ... I will poke mdz or mako [12:51] <\sh> or jane? [12:51] or elmo? [12:51] \sh, rather elmo [12:51] <\sh> someone :) [12:51] <\sh> or elmo [12:51] \sh: great. I haven't had time the last weeks. next week I think I will have more time to work on revu [12:52] ok? anybody who wants to keep them to not annoy people who mentioned their package there? [12:52] I think I read that the common lisp team has packages for review there.. [12:52] what about packages which are on the package, but not uploaded yet to revu? [12:52] <\sh> what about this:

THESE PAGES WILL BE REMOVED IN THE NEAR FUTURE

Please upload your packages to REVU

on the first two lines? [12:53] yep, thats there since a month [12:53] and email -devel [12:53] <\sh> yep [12:53] yeah, we maybe should do that [12:53] keep them for a brief period of time [12:53] and announce their disposal [12:53] agreed [12:53] robitaille: are you there? point 4 is your point :) [12:53] yes I'm here. [12:54] bug squashing! [12:54] introduce us into the delights of malone assigning :) [12:54] Should Malone bugs on Universe packages be assigned to MOTU members, or leave them unassigned? === Treenaks [~martijn@messy.foodfight.org] has joined #ubuntu-meeting [12:54] as an aside, we should have a bug squashing party ;) [12:54] robitaille: assign them [12:54] I have seen 2 positive feedback and one negative to the few I did recently [12:55] otherwise we don't see them [12:55] ++ [12:55] i have no attention in even looking at bugs that are mass assigned to me [12:55] just one opinion [12:55] ajmitch, we have bugday every wednesday, since 2 months [12:55] robitaille: i'm for it as well [12:55] i have my own bugs [12:55] tseng: you're different, in that you mainly focus on mono [12:55] yes. [12:55] ajmitch, tseng is on the teamlist [12:55] ogra: sure, but how often do people hear about that? [12:55] so he gets the bugmails [12:55] ogra: I know [12:56] <\sh> well...we can assign them to the team and then can somebody pick up his favorite [12:56] ajmitch, you dont need to tell me that i suck as bugmaster ;) [12:56] ok, how shall we deal with this? [12:56] and there are maybe 250-300 bugs on universe packages. THat's could be a lot of traffic [12:56] ogra: haha, I didn't mean that ;) [12:56] ajmitch, but i... i'd love to get rid of that job :) [12:56] ogra: search for willing victims :) [12:56] ogra: can we add a mailing list for assigned bugs? [12:57] ogra: so we don't annoy people with millions of bug mails === ajmitch spots luis_ hiding in the crowd [12:57] ogra: i don't remember the last state [12:57] dholbach, why dilys is posting every new bug in #ubuntu-bugs [12:57] ajmitch, yes, i saw him too :) [12:57] ogra: but i'm not on irc 24h [12:57] ogra: irc isn't the best place for bug notification [12:57] ajmitch: ++ [12:57] it's useful, for sure [12:57] ajmitch, dholbach dilys can be easily modified to feed to rss i guess [12:58] I've spotted bugs there & started on the fixing because of dilys [12:58] I like the dilys announcements...a good way to do quick bug triage on the spot [12:58] ok, how can we have MOTUs in the MOTU team (for visibility), but not annoy them with sometimes useless bug mails [12:58] since she already entertains us with her prose :) [12:59] ok, don't we have a solution for that yet? [12:59] dholbach, thats a question to the launchpad team [12:59] a mailing list for motu bug mails would be cool [12:59] <\sh> ogra: how fast can dilys be changed for feeding rss? [12:59] ogra: i recall to already have asked the question - or maybe you did it [12:59] \sh, no idea... its not my baby === ajmitch will have to find a decent rss reader then [12:59] <\sh> ajmitch: akregator ;) [12:59] dholbach, i think kiko said its trivial iirc [12:59] ok [01:00] \sh: I said *decent* :) [01:00] so we defer this question until we have a launchpad answer [01:00] <\sh> ajmitch: ffox ;) [01:00] sistpoty: we need rss feeds for revu2 ;) [01:00] \sh: besides, I do a fair bit of work remotely [01:00] is that ok with you? [01:00] <\sh> sistpoty: rss2 please with full comments ;) [01:00] siretart: ack ;) [01:00] dholbach, yep... o with me... [01:00] ok [01:00] ok [01:00] common REVU practices - there are two topics I can think of, which got discussed on REVU - maybe we should have a bit of bendable policy and an agreement here [01:00] 1) config.{guess,sub} in the diff (relying on build hosts' build system vs. clean diff) [01:01] 2) changing .ORIG.tar.gz (sorry, I'm a bit biased) [01:01] :) [01:01] <\sh> aehm [01:01] opinions on how to deal with that kind of stuff :) [01:01] <\sh> 1) i don't like copies of config.{guess,sub} in the clean targets of the rules... [01:01] i thinkwe should hear a very experienced package for 1) [01:01] packager even [01:02] ajmitch: how do you think about this topic, with your DD hat on ;) === ajmitch hates having a messy diff [01:02] <\sh> they're messing sometimes the who diff.gz so I put them in the configure target before ./configure [01:02] heh [01:02] \sh: you mean removing copies in the clear targets? [01:02] siretart: I've been a MOTU longer than a DD ;) [01:02] <\sh> Riddell: yep [01:02] hehe [01:03] <\sh> or the build management is so intelligent to remove those diffs from diff.gz [01:03] but I don't like having a diff with that mess [01:03] <\sh> Riddell: and putting them in the configure target or config.sub [01:03] i think there is clearly clearability of the diff versus relying on build systems' config.{guess,sub} [01:04] (and we're talking about two files) [01:04] \sh: what's wrong with removing it in debian/rules clean? [01:04] I see general agreement leaving config.{guess,sub} out for nicer .diff.gz (and therefore, better reviewability) [01:04] Riddell, its about *adding* it there [01:04] thats a pet peeve of mine [01:04] i cant stand that stuff in the diff [01:05] <\sh> Riddell: dh_make templates is not removing them in debian/rules clean, they're copying it from build system [01:05] <\sh> Riddell: so the diff.gz or debdiffs are getting messy with this crap === mdz [~mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net] has joined #ubuntu-meeting [01:05] hi mdz :) [01:05] <\sh> Riddell: it you move it from clean target to configure target u won't see them in the diff.gz or debdiff [01:06] I can't be fully attentive but if you have specific questions I can try to answer [01:06] we're trying to arrange a bendable agreement on point 5 of https://wiki.ubuntu.com/MOTUMeeting [01:06] config.{guess,sub} in the diff (relying on build hosts' build system vs. clean diff) and changing .ORIG.tar.gz [01:06] mdz: the current topic is if config.{guess,sub} should be deleted in debian/rules clean target [01:07] because the reviewers suggested different "solutions" [01:07] I am not a fan of updating those files during the build in the first place [01:07] by default dh_make places the copying of these files in the clean target, that means i clutter my diff.gz totally... whats the rationale for that [01:07] be back in a minute [01:07] \sh: so move the rm -f config.{guess,sub} from debian/rules clean to debian/rules configure? how it that more elegant? [01:08] <\sh> Riddell: it's not about rm -f config.{guess,sub} it's about cp -f /usr/share/misc/config.{guess,sub} $(CURDIR) in clean target [01:08] Riddell, its the cp that puts them into your sourcetree, not the rm.... [01:09] just use cdbs :p [01:09] seb128: sadly we can't convert the world to cdbs :) [01:09] Why not? ;-) [01:09] doing a build and then cleaning the tree should give you back the same tree you started with [01:10] it is done in the clean target by default, while it could be done with a build-dep on autotools-dev which makes sure the fils are the most recent and saves space in the diff [01:10] mdz: isn't that part of the automated testing spec? [01:10] the readability isnt such a big point when you're talking about two files, is it? [01:10] ajmitch: possibly? [01:11] so if 1) you are updating config.* during the build, and 2) the build is being done in-tree, then you need to restore the files, not delete them [01:11] dholbach, if you make only a dependency change the difference is *huge* [01:11] I think pitti was talking about that, but that's another matter [01:11] that is what cdbs does, I believe [01:12] ogra: and you rely on the build system's config.{sub,guess}, which is the whole point of copying them in before, NOT relying on the build system, but on your patch [01:12] so the approach dh_make uses is broken? [01:12] dh_make is broken in all sorts of ways [01:12] siretart: i think so... at least the templates that come from it (iirc) [01:12] <\sh> ok... [01:13] <\sh> this is an example [01:13] dholbach, but since they carry the descriptions of supported arches etc, i dont see the point not to take them from the build system... they'll match the build system... and in my eyes they are part of the tools, not of the source [01:13] <\sh> -test -r /usr/share/misc/config.sub && \ [01:13] <\sh> cp -f /usr/share/misc/config.sub config.sub [01:13] <\sh> -test -r /usr/share/misc/config.guess && \ [01:13] <\sh> cp -f /usr/share/misc/config.guess config.guess [01:13] <\sh> in clean target before dh_clean [01:14] shall we take this question to the mailing list and proceed to the next one? :) [01:14] <\sh> so debuild is calling debian/rules clean first, copies the build systems config.{guess,sub} to the $(CURDIR) and messes the diff..this is what dh_make gives u as template...and many packages are using it [01:14] oh sorry, \sh wanted to say something [01:15] <\sh> example: atlas-cpp [01:15] \sh: it doesnt "mess" for the sake of it [01:15] from the discussions we had, I'd consider that pattern in debian/rules broken [01:15] \sh: right, cdbs has a fair bit of stuff in /usr/share/cdbs/1/rules/buildcore.mk & other files for handling this [01:15] me too [01:15] \sh: it's there for a good reason - even lintian complains about too old config.{guess,sub} for a reason [01:15] it fails to restore the package state === Treenaks [~martijn@messy.foodfight.org] has joined #ubuntu-meeting [01:16] dholbach, but it describes the capabilitys of the build tools, so why not use the ones from the actual build system [01:16] <\sh> dholbach: i don't mind to copy that stuff..but not in the clean target, cause the diff is generated after debian/rules clean [01:16] \sh: if you copy it in, it will always be in the diff [01:17] dholbach, it will be always new in every diff... [01:17] <\sh> dholbach: not if the tree is cleaned correctly...it copies the stuff only, when config.{guess,sub} is not in place [01:17] dholbach, which is a total waste [01:17] these file are updated because that's required to build on some archs [01:17] <\sh> but it's build time..not cleaning time... [01:18] (especially for all those packages in debian that weren't touched for like two decades.... :)) [01:18] <\sh> so it should be in those parts where the build is done..and not where the build stuff is cleaned up [01:18] but then you don't have control over what you upload, you rely on the build hosts config.{sub,guess} [01:18] seb128, yes, but why not updating them on the actual build system they use... i.e. at buildtime... [01:19] that's what cdbs does [01:19] dholbach: you don't want to use your version, autotools-dev has the reference versions known to work [01:19] <\sh> seb128: that's what I said...put this piece of code in debian/rules configure target before the ./configure call... [01:19] ah, so my doing isnt wrong then :) [01:20] ogra: no, that's what we're arguing about ;) [01:20] the best solution would be to modify autoconf, upstream, to use the newer of the installed file and the one shipped with the package [01:20] seb128: i want to use the version, i have locally on my disk, which procudes my diff :) [01:20] then this problem goes away entirely [01:20] dholbach: why? [01:20] it's the way it should have worked in the first place [01:20] dholbach, that might be outdated at buildtime... [01:21] I suggest proposing that to the upstream maintainer with a description of our situation [01:21] ok... [01:21] mdz: which upstream? [01:21] mdz: every single one of each package? [01:21] any objections when we go on to use the ones on the buildd until thats fixed ? [01:22] dholbach: autoconf upstream, as I said [01:22] mdz: ah ok [01:22] mdz: thanks [01:23] ok, seems like we should proceed to the next time :) [01:23] Are we making any decisions? ;-) [01:23] what do you all think about chaging orig.tar.gz? [01:23] bddebian, thats rare in motu meetings... [01:23] dholbach: I don't like it [01:23] ;) [01:23] me neither [01:24] <\sh> bddebian: yes we're contacting the autotools (god) upstream maintainer ;) [01:24] dholbach: and it should only be done where really really necessary [01:24] don't touch the orig.tar.gz [01:24] i know cases of packaging cvs exported stuff, where a ./autogen.sh && make dist is in order [01:24] exceptions are license issues, where you have to cut out undistributable source [01:24]