[12:08] <dholbach> 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] <dholbach> 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] <dholbach> a aalib transition manager or something
[12:09] <dholbach> for example
[12:09] <\sh> s/are/is/
[12:09] <siretart> dholbach: this would my my suggestion/expectations from the teams
[12:09] <dholbach> the c++ transition was a good example for this - our beloved doko did an awesome job in planning this
[12:09] <bddebian> 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] <siretart> dholbach: having a lead and interested people for a specific topic which need to get done
[12:10] <siretart> the lead should have an overview and be able to explain what is going on
[12:10] <dholbach> absolutely
[12:11] <dholbach> 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] <Seveas> 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] <ajmitch> dholbach: sounds good, just like what you did for hoary ;)
[12:11] <bddebian> Seveas: Where is this happening?
[12:11] <dholbach> ajmitch: thanks for the flowers :-p
[12:12] <Seveas> bddebian, http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
[12:12] <ajmitch> 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] <bddebian> Seveas: Ah, nice
[12:12] <dholbach> \sh: they're not supposed to do the work all themselves
[12:13] <\sh> dholbach: right..but this I don't mean...
[12:13] <dholbach> ah ok... maybe i got you wrong
[12:13] <ogra> \sh, you need a point of contact... someone who is responsible and trys to coordinate a bit
[12:13] <ajmitch> 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] <dholbach> i'm not quite sure, if all the stuff doesnt really go hand in hand
[12:14] <dholbach> 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] <ogra> 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] <siretart> \sh: hm. so you want to make people concentrating on one specific topic?
[12:15] <siretart> I just try to understand you
[12:15] <\sh> siretart: yes...in busy times like these days e.g.
[12:15] <ogra> siretart, that would be desirable, but happens anyway imho
[12:16] <bddebian> 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] <crimsun> bddebian: we should all be assisting each other.
[12:17] <siretart> bddebian: let's discuss this later, ok?
[12:17] <ogra> bddebian, depending on your questions, yes
[12:17] <bddebian> siretart: ok
[12:17] <ogra> hey tseng
[12:17] <tseng> hi
[12:17] <\sh> tseng: welcome
[12:17] <bddebian> welcome tseng
[12:17] <dholbach> hey tseng :)
[12:17] <siretart> hey tseng, how are you?
[12:17] <ajmitch> morning tseng
[12:17] <tseng> i will be just watching I think
[12:17] <dholbach> tseng: https://wiki.ubuntu.com/MOTUMeeting - first point
[12:17] <ogra> \hif everybody had looked at the merge stuff first, we wouldnt have had 250 pkgs there
[12:18] <dholbach> bddebian: i hope i'll be able to do more on this front in 4 weeks
[12:18] <ogra> \sh, even
[12:18] <dholbach> ogra: yes, that's why i suggest some leads organizing the different motu actions
[12:18] <bddebian> 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] <ogra> dholbach, nope, its a process we must establish...
[12:18] <ajmitch> ogra: yeah, I started doing some merges right at the beginning of the breezy cycle with my list
[12:19] <ajmitch> ogra: but quickly ran out of spare time
[12:19] <dholbach> ogra: a process like what?
[12:19] <\sh> ajmitch: so did I during the cxx trans
[12:19] <ogra> if you touch a package with -ubuntuX version you should always look for mergers first
[12:19] <comadreja> what about this as a middle point. Somebody dispatching tasks on a "do-it-if-you-can" way ?
[12:19] <siretart> \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] <ajmitch> ogra: that will reduce forking from debian
[12:19] <dholbach> ogra: ah ok yes
[12:19] <comadreja> like writing a wiki page
[12:19] <ogra> dholbach, if we do the merges constantly, we dont have this many
[12:19] <dholbach> ogra: absolutely
[12:20] <dholbach> 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] <ogra> ajmitch, yes, exactly... it will still be a fork, but the changes are smaller
[12:20] <crimsun> 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] <comadreja> dholbach : like in writing in a wiki page a priority list
[12:20] <dholbach> comadreja: ah ok, i see
[12:20] <ajmitch> ogra: well we have to try & keep as close to debian as possible to avoid work for us
[12:20] <ajmitch> we have to be naturally lazy! ;)
[12:20] <\sh> crimsun: this is something u will always have for volunteer work
[12:21] <ogra> crimsun, did you look for every -ubuntuX package you touched at MOM first ?
[12:21] <comadreja> that way, every single motu can use their time on that...
[12:21] <tseng> i dont like MOM
[12:21] <\sh> crimsun: even ogra is too busy to deal with motu stuff right now...
[12:21] <dholbach> \sh: do you think planning will be easier, if somebody signs up for such a task force?
[12:21] <crimsun> 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] <ogra> crimsun, ah, great ten... i didnt and was hit by it...
[12:22] <ogra> s/ten/then
[12:22] <ogra> and many others of us too...
[12:22] <dholbach> who else thinks that a recruited taskforce will make planning easier?
[12:22] <bddebian> tseng: Agreed, it does have it's limitations
[12:22] <ogra> some packages from MOM were already touched in the Cxx transition for example
[12:22] <comadreja> dholbach : we first need a scheduler :)
[12:23] <dholbach> comadreja: of course, we need the plan first
[12:23] <comadreja> 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] <dholbach> 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
[12:24] <dholbach> \sh: some things just happend and you can't foresee them, because you're not involved with libxyz's upstream
[12:24] <ogra> \sh, note, there will be no X and no Cxx transition...
[12:24] <siretart> \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] <ogra> breezy+1 will be an awesome development cycle
[12:24] <dholbach> 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] <ajmitch> breezy+1 is going to be different, in that main will be supported by the ubuntu foundation for *5* years
[12:25] <ajmitch> we need to try & get quality up
[12:25] <ogra> \sh, yes, but a lot less mass transitions and thus a lot more time to play and develop
[12:25] <ajmitch> ogra: more recruiting! :)
[12:25] <ogra> 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] <dholbach> ok, who wants to make a suggestion that goes  beyond  "more organization"
[12:26] <bddebian> Then you need to either recruit folks that are familiar with hacking/Debian packaging or get some better direction for the NewMOTU process
[12:26] <ajmitch> bddebian: fine, put your suggestions down somewhere :)
[12:27] <siretart> ajmitch: I think I have an suggestion for NewMOTU process, more on this later..
[12:27] <dholbach> ok, as i see it there are 2 options
[12:27] <ajmitch> siretart: great
[12:27] <dholbach> 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] <dholbach> 2) flesh out the process for such a task forces with all it's implications and go from there again
[12:27] <crimsun> 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] <ogra> \sh, sure, lets d that
[12:28] <ogra> do even
[12:29] <dholbach> ok... shall we put up wiki pages up for those ideas and decide over them again?
[12:29] <dholbach> this to me sounds like the best plan, since it is more detailed and more goal focused
[12:29] <siretart> dholbach: I second this suggestion. let's move on
[12:29] <ajmitch> yep
[12:29] <\sh> let's do it like that...
[12:29] <dholbach> \sh: thanks for bringing the point up - as you see - there are lot of opinions on that
[12:30] <dholbach> point two
[12:30] <siretart> but may I suggest some procedure for new MOTU's?
[12:30] <\sh> dholbach: yes...likley :)
[12:30] <siretart> it is somehow related to that Team concept
[12:30] <dholbach> siretart: fire away
[12:30] <siretart> I propose a mentoring concept for newMOTU's
[12:30] <ogra> dholbach, why do we need to feed them, they give a grown up impression... they can gra it themselves
[12:31] <ogra> grab even
[12:31] <siretart> a bit similar to debian, but not quite. Each new candidate is assigned to one specific motu he uses as mentor
[12:31] <dholbach> ogra: siretart wanted to add a new team idea in between
[12:31] <tseng> eh
[12:31] <ogra> ah,oh, ok
[12:31] <tseng> people move really fast in motu right now
[12:31] <tseng> because they can get help from everyone
[12:31] <siretart> 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
[12:32] <siretart> this may or may not be using revu
[12:32] <ajmitch> tseng: they wouldn't be limited to this one person, but they'd be their primary contact
[12:32] <ajmitch> ogra: what's wrong with it?
[12:32] <siretart> \sh: I don't know how gentoo works, can you elaborate?
[12:32] <ajmitch> too much workload on existing motus?
[12:33] <dholbach> siretart: what i like about the current process is it's openness
[12:33] <ogra> 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] <dholbach> siretart: so more people have a good image of how a motu hopeful proceeds
[12:33] <tseng> ogra: right.
[12:33] <ogra> it tears down the amount of work done with the whole tem
[12:33] <ogra> team
[12:33] <siretart> ok. I see the point raised by dholbach and ogra.
[12:34] <dholbach> siretart: but this is a point we will have to discuss soon
[12:34] <dholbach> 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] <ajmitch> right, you don't want the big happy family to be dysfunctional
[12:34] <siretart> I don't want to take the newbees into secret corners. they should work with the community
[12:34] <siretart> the problem I want to solve is another one:
[12:34] <ajmitch> 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] <siretart> 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] <dholbach> what do you think about this: shall a motu-process2 team sit together and throw some ideas together and form a "spec"?
[12:35] <siretart> so this mentoring concept is rather a more formal process of having packages sponsored
[12:35] <dholbach> over which we can decide more formally?
[12:35] <siretart> dholbach: perhaps this would be an idea.
[12:36] <dholbach> any other opinions?
[12:36] <ajmitch> dholbach: we might need to schedule another meeting soon then
[12:36] <dholbach> yes
[12:36] <siretart> I'll try to write up my ideas on a wiki page and present them the next meeting
[12:36] <ajmitch> unless we do our debating on the wiki
[12:36] <dholbach> super, thanks siretart
[12:36] <dholbach> it think it's better to have ideas more fleshed out, before we decide
[12:36] <siretart> this won't be before next week ;)
[12:37] <dholbach> may we get to point 2 now?
[12:37] <\sh> yes
[12:37] <ogra> siretart, we meet once a month ;)
[12:37] <ajmitch> please do..
[12:37] <ogra> take your time
[12:37] <dholbach> i proposed this one: "Proceedings of feeding UniverseNewPackages (and Andrew's RFP list) to utnubu-discuss."
[12:37] <dholbach> because i found that most of our NEW packages are not announced anywhere and just "end up in the archive"
[12:37] <dholbach> don't you think we should push them more into the debian direction?
[12:37] <ajmitch> dholbach: agreed, very important
[12:37] <ogra> 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] <ajmitch> at the last meeting we resolved to file these RFPS
[12:38] <dholbach> there were only SOME reactions RFP/ITP-wise from our side
[12:38] <dholbach> ogra: yeah, but *nearly* nobody does it at the moment
[12:38] <ogra> ajmitch, now there is an active group in debian....
[12:38] <dholbach> so i think this should be more of a policy
[12:38] <ogra> dholbach, what ?
[12:38] <ajmitch> ogra: I know, I see you're in the group
[12:38] <siretart> well, I don't think that it would be very much efford announcing new addition to universe to the utnubu mailing list
[12:38] <dholbach> that the package needs to be announced
[12:38] <\sh> ogra: u r involved in that utnubu thing
[12:38] <dholbach> siretart: ++
[12:39] <ajmitch> I've got to get involved there too
[12:39] <siretart> and I think nometa and other debian developers would really appreciate it
[12:39] <dholbach> \sh, ogra: yes?
[12:39] <\sh> ogra: how is the mood towards ubuntu patches and new packages at all?
[12:39] <ogra> dholbach, they have browsers eyes and are able to read... lets point them to the page and they can care themselves
[12:39] <luis_> could you create an rss feed from your current tools, and ask them to subscribe to that for timely/reliable info?
[12:39] <ogra> \sh, its ok... the tone is rougher...
[12:39] <ogra> luis_, sure
[12:39] <\sh> ogra: rougher?
[12:40] <Seveas> luis_, there are RSS feeds for Ubuntu uploads
[12:40] <\sh> ogra: in what way?
[12:40] <siretart> \sh: I think it is generally very mixed and depends whom you ask. the utnubu guys seem to be very colaborative.
[12:40] <ogra> 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] <dholbach> 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] <ogra> but in the end its *their* job
[12:40] <dholbach> ogra: nobody does that either
[12:41] <\sh> actually, I can tell only about my experiences with some maintainers...
[12:41] <dholbach> 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] <ogra> dholbach, i dont know since when youre subscribed to -utnubu-devel, but they already have tools to produce theur lists
[12:41] <siretart> 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] <dholbach> ogra: i read all the threads
[12:42] <dholbach> who is opposed to add "announce it on utnubu" to our MOTUNewPackagesPolicy?
[12:42] <ogra> dholbach, its their job as import team... its nice of us to offer them something, but i refuse to do their job
[12:42] <dholbach> ogra: we're not going to make them debian compliant or uploading or do whatever to the debian archive
[12:43] <comadreja> dholbach : I also think it's their job
[12:43] <dholbach> ok... any other opinions?
[12:43] <ogra> 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] <dholbach> 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] <comadreja> dholbach : that mail could be automated
[12:44] <ogra> \sh, its on alioth.debian.org
[12:44] <ogra> \sh, search for utnubu
[12:44] <ogra> \sh, i meant -discuss above, sorry
[12:44] <\sh> ogra: ah ok :)
[12:45] <seb128> dholbach: don't annonce stuff on utnubu
[12:45] <ajmitch> ogra: perhaps I should try & make it more part of my MOTU responsibilites then?
[12:45] <dholbach> ok... we seem to cannot agree here and will rely on volunteer action
[12:45] <dholbach> 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] <seb128> it's not ok
[12:45] <CarlFK> I didn't see anyone opposed to the rss feed idea
[12:45] <ogra> 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] <seb128> 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] <dholbach> i think we can just offer
[12:46] <siretart> seb128: what are your objections to utnubu?
[12:46] <dholbach> ogra: i was talking about making info public available, nothing else :)
[12:46] <seb128> 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] <seb128> Debian expects some quality
[12:47] <dholbach> but it might be a start of working together on stuff
[12:47] <seb128> if somebody wants to maintain a GNOME stuff with Debian he should rather work with pkg-gnome
[12:47] <ogra> 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] <siretart> seb128: I think that was not nometa's intention
[12:47] <seb128> ie: with people interesting on that
[12:47] <dholbach> ogra: announcing, not discussing details :)
[12:47] <seb128> s/interesting/interested/
[12:47] <ogra> dholbach, you end up with this... see gparted... i dont see the last word spoken there
[12:48] <seb128> dholbach: that's not the place to announce, stuff
[12:48] <seb128> they will grab them
[12:48] <dholbach> ogra: that's one case - you can't judge a project after 3-4 weeks
[12:48] <seb128> upload them here rather than at the right place
[12:48] <ogra> dholbach, nope, i know...
[12:48] <seb128> and non-maintain them
[12:49] <dholbach> ok, we had quite some interesting points here... :)
[12:49] <dholbach> ok, looking at the time, we might hop over to point 3 - is that ok for you?
[12:49] <siretart> please
[12:49] <seb128> 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] <seb128> them
[12:49] <seb128> dholbach: go :)
[12:49] <dholbach> Trashing of MOTUNewPackages and MOTUToReview in favour of REVU
[12:49] <dholbach> the pages are momentarily just lying around
[12:50] <\sh> dholbach: when it's in the proper place on an own linode
[12:50] <dholbach> and nobody cares after them, some packages already got uploaded to REVU
[12:50] <dholbach> \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] <dholbach> \sh: we are discussing the point now :)
[12:51] <dholbach> does anybody feel we should keep them for a bit of time?
[12:51] <siretart> \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] <dholbach> or elmo?
[12:51] <ogra> \sh, rather elmo
[12:51] <\sh> someone :)
[12:51] <\sh> or elmo
[12:51] <siretart> \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] <dholbach> ok? anybody who wants to keep them to not annoy people who mentioned their package there?
[12:52] <siretart> I think I read that the common lisp team has packages for review there..
[12:52] <siretart> what about packages which are on the package, but not uploaded yet to revu?
[12:52] <\sh> what about this: <h1>THESE PAGES WILL BE REMOVED IN THE NEAR FUTURE</h1> <h2>Please upload your packages to REVU</h2> on the first two lines?
[12:53] <ogra> yep, thats there since a month
[12:53] <tseng> and email -devel
[12:53] <\sh> yep
[12:53] <dholbach> yeah, we maybe should do that
[12:53] <dholbach> keep them for a brief period of time
[12:53] <dholbach> and announce their disposal
[12:53] <dholbach> agreed
[12:53] <dholbach> robitaille: are you there? point 4 is your point :)
[12:53] <robitaille> yes I'm here.
[12:54] <ajmitch> bug squashing!
[12:54] <dholbach> introduce us into the delights of malone assigning :)
[12:54] <robitaille> Should Malone bugs on Universe packages be assigned to MOTU members, or leave them unassigned?
[12:54] <ajmitch> as an aside, we should have a bug squashing party ;)
[12:54] <ajmitch> robitaille: assign them
[12:54] <robitaille> I have seen 2 positive feedback and one negative to the few I did recently
[12:55] <ajmitch> otherwise we don't see them
[12:55] <siretart> ++
[12:55] <tseng> i have no attention in even looking at bugs that are mass assigned to me
[12:55] <tseng> just one opinion
[12:55] <ogra> ajmitch, we have bugday every wednesday, since 2 months
[12:55] <dholbach> robitaille: i'm for it as well
[12:55] <tseng> i have my own bugs
[12:55] <ajmitch> tseng: you're different, in that you mainly focus on mono
[12:55] <tseng> yes.
[12:55] <ogra> ajmitch, tseng is on the teamlist
[12:55] <ajmitch> ogra: sure, but how often do people hear about that?
[12:55] <ogra> so he gets the bugmails
[12:55] <ajmitch> ogra: I know
[12:56] <\sh> well...we can assign them to the team and then can somebody pick up his favorite
[12:56] <ogra> ajmitch, you dont need to tell me that i suck as bugmaster ;)
[12:56] <dholbach> ok, how shall we deal with this?
[12:56] <robitaille> and there are maybe 250-300 bugs on universe packages.  THat's could be a lot of traffic
[12:56] <ajmitch> ogra: haha, I didn't mean that ;)
[12:56] <ogra> ajmitch, but i... i'd love to get rid of that job :)
[12:56] <ajmitch> ogra: search for willing victims :)
[12:56] <dholbach> ogra: can we add a mailing list for assigned bugs?
[12:57] <dholbach> ogra: so we don't annoy people with millions of bug mails
[12:57] <dholbach> ogra: i don't remember the last state
[12:57] <ogra> dholbach, why dilys is posting every new bug in #ubuntu-bugs
[12:57] <ogra> ajmitch, yes, i saw him too :)
[12:57] <dholbach> ogra: but i'm not on irc 24h
[12:57] <ajmitch> ogra: irc isn't the best place for bug notification
[12:57] <dholbach> ajmitch: ++
[12:57] <ajmitch> it's useful, for sure
[12:57] <ogra> ajmitch, dholbach dilys can be easily modified to feed to rss i guess
[12:58] <ajmitch> I've spotted bugs there & started on the fixing because of dilys
[12:58] <robitaille> I like the dilys announcements...a good way to do quick bug triage on the spot
[12:58] <dholbach> ok, how can we have MOTUs in the MOTU team (for visibility), but not annoy them with sometimes useless bug mails
[12:58] <ogra> since she already entertains us with her prose :)
[12:59] <dholbach> ok, don't we have a solution for that yet?
[12:59] <ogra> dholbach, thats a question  to the launchpad team
[12:59] <dholbach> 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] <dholbach> ogra: i recall to already have asked the question - or maybe you did it
[12:59] <ogra> \sh, no idea... its not my baby
[12:59] <\sh> ajmitch: akregator ;)
[12:59] <ogra> dholbach, i think kiko said its trivial iirc
[12:59] <dholbach> ok
[01:00] <ajmitch> \sh: I said *decent* :)
[01:00] <dholbach> so we defer this question until we have a launchpad answer
[01:00] <\sh> ajmitch: ffox ;)
[01:00] <siretart> sistpoty: we need rss feeds for revu2 ;)
[01:00] <ajmitch> \sh: besides, I do a fair bit of work remotely
[01:00] <dholbach> is that ok with you?
[01:00] <\sh> sistpoty: rss2 please with full comments ;)
[01:00] <sistpoty> siretart: ack ;)
[01:00] <ogra> dholbach, yep... o with me...
[01:00] <ogra> ok
[01:00] <dholbach> ok
[01:00] <dholbach> 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] <dholbach> 1)  config.{guess,sub} in the diff (relying on build hosts' build system vs. clean diff)
[01:01] <dholbach> 2)  changing .ORIG.tar.gz (sorry, I'm a bit biased)
[01:01] <dholbach> :)
[01:01] <\sh> aehm
[01:01] <dholbach> 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] <ogra> i thinkwe should hear a very experienced package for 1)
[01:01] <ogra> packager even
[01:02] <siretart> ajmitch: how do you think about this topic, with your DD hat on ;)
[01:02] <\sh> they're messing sometimes the who diff.gz so I put them in the configure target before ./configure
[01:02] <bddebian> heh
[01:02] <Riddell> \sh: you mean removing copies in the clear targets?
[01:02] <ajmitch> siretart: I've been a MOTU longer than a DD ;)
[01:02] <\sh> Riddell: yep
[01:02] <siretart> hehe
[01:03] <\sh> or the build management is so intelligent to remove those diffs from diff.gz
[01:03] <ajmitch> 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] <dholbach> i think there is clearly clearability of the diff  versus  relying on build systems' config.{guess,sub}
[01:04] <dholbach> (and we're talking about two files)
[01:04] <Riddell> \sh: what's wrong with removing it in debian/rules clean?
[01:04] <siretart> I see general agreement leaving config.{guess,sub} out for nicer .diff.gz (and therefore, better reviewability)
[01:04] <ogra> Riddell, its about *adding* it there
[01:04] <tseng> thats a pet peeve of mine
[01:04] <tseng> 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
[01:05] <tseng> 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] <mdz> I can't be fully attentive but if you have specific questions I can try to answer
[01:06] <dholbach> we're trying to arrange a bendable agreement on point 5 of https://wiki.ubuntu.com/MOTUMeeting
[01:06] <dholbach>  config.{guess,sub} in the diff (relying on build hosts' build system vs. clean diff)     and      changing .ORIG.tar.gz
[01:06] <siretart> mdz: the current topic is if config.{guess,sub} should be deleted in debian/rules clean target
[01:07] <dholbach> because the reviewers suggested different "solutions"
[01:07] <mdz> I am not a fan of updating those files during the build in the first place
[01:07] <ogra> 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] <dholbach> be back in a minute
[01:07] <Riddell> \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] <ogra> Riddell, its the cp that puts them into your sourcetree, not the rm....
[01:09] <seb128> just use cdbs :p
[01:09] <ajmitch> seb128: sadly we can't convert the world to cdbs :)
[01:09] <bddebian> Why not? ;-)
[01:09] <mdz> doing a build and then cleaning the tree should give you back the same tree you started with
[01:10] <ogra> 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] <ajmitch> mdz: isn't that part of the automated testing spec?
[01:10] <dholbach> the readability isnt such a big point when you're talking about two files, is it?
[01:10] <mdz> ajmitch: possibly?
[01:11] <mdz> 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] <ogra> dholbach, if you make only a dependency change the difference is *huge*
[01:11] <ajmitch> I think pitti was talking about that, but that's another matter
[01:11] <mdz> that is what cdbs does, I believe
[01:12] <dholbach> 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] <siretart> so the approach dh_make uses is broken?
[01:12] <mdz> dh_make is broken in all sorts of ways
[01:12] <sistpoty> 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] <ogra> 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] <dholbach> 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] <dholbach> oh sorry, \sh wanted to say something
[01:15] <\sh> example: atlas-cpp
[01:15] <dholbach> \sh: it doesnt "mess" for the sake of it
[01:15] <siretart> from the discussions we had, I'd consider that pattern in debian/rules broken
[01:15] <ajmitch> \sh: right, cdbs has a fair bit of stuff in /usr/share/cdbs/1/rules/buildcore.mk & other files for handling this
[01:15] <ogra> me too
[01:15] <dholbach> \sh: it's there for a good reason - even lintian complains about too old config.{guess,sub} for a reason
[01:15] <siretart> it fails to restore the package state
[01:16] <ogra> 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] <dholbach> \sh: if you copy it in, it will always be in the diff
[01:17] <ogra> 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] <ogra> dholbach, which is a total waste
[01:17] <seb128> 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] <dholbach> (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] <dholbach> but then you don't have control over what you upload, you rely on the build hosts config.{sub,guess}
[01:18] <ogra> seb128, yes, but why not updating them on the actual build system they use... i.e. at buildtime...
[01:19] <seb128> that's what cdbs does
[01:19] <seb128> 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] <ogra> ah, so my doing isnt wrong then :)
[01:20] <ajmitch> ogra: no, that's what we're arguing about ;)
[01:20] <mdz> 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] <dholbach> seb128: i want to use the version, i have locally on my disk, which procudes my diff :)
[01:20] <mdz> then this problem goes away entirely
[01:20] <seb128> dholbach: why?
[01:20] <mdz> it's the way it should have worked in the first place
[01:20] <ogra> dholbach, that might be outdated at buildtime...
[01:21] <mdz> I suggest proposing that to the upstream maintainer with a description of our situation
[01:21] <ogra> ok...
[01:21] <dholbach> mdz: which upstream?
[01:21] <dholbach> mdz: every single one of each package?
[01:21] <ogra> any objections when we go on to use the ones on the buildd until thats fixed ?
[01:22] <mdz> dholbach: autoconf upstream, as I said
[01:22] <dholbach> mdz: ah ok
[01:22] <dholbach> mdz: thanks
[01:23] <dholbach> ok, seems like we should proceed to the next time :)
[01:23] <bddebian> Are we making any decisions? ;-)
[01:23] <dholbach> what do you all think about chaging orig.tar.gz?
[01:23] <ogra> bddebian, thats rare in motu meetings...
[01:23] <ajmitch> dholbach: I don't like it
[01:23] <ogra> ;)
[01:23] <ogra> me neither
[01:24] <\sh> bddebian: yes we're contacting the autotools (god) upstream maintainer ;)
[01:24] <ajmitch> dholbach: and it should only be done where really really necessary
[01:24] <seb128> don't touch the orig.tar.gz
[01:24] <dholbach> i know cases of packaging cvs exported stuff, where a ./autogen.sh && make dist is in order
[01:24] <ajmitch> exceptions are license issues, where you have to cut out undistributable source
[01:24] <dholbach> but that's all i'd allow policy-wise
[01:25] <ogra> seb128, what do you do with cvs checked out stuff... dont you remove the CVS dirs ?
[01:25] <\sh> dholbach: why don't u call ./autogen during build time? ,-)
[01:25] <dholbach> ogra: cvs export
[01:25] <ajmitch> ogra: do that in debian/rules
[01:25] <dholbach> \sh: you don't do that :)
[01:25] <seb128> ogra: I use "make dist" which makes a proper tarball
[01:25] <Riddell> changing .orig.tar.gz is fine for removing upstream debian/ directories
[01:25] <seb128> no
[01:25] <\sh> dholbach: for cvs stuff of course...cause the original tarball is cvs exported...
[01:26] <siretart> debian policy suggests the target get-orig-source
[01:26] <siretart> This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory.
[01:26] <seb128> replacing the debian/ dir can go to the diff.gz
[01:26] <dholbach> seb128: ++ even if it looks ugly
[01:26] <seb128> it's not ugly
[01:26] <dholbach> seb128: in the diff - and i don't care about that :)
[01:27] <dholbach> seb128: i'm not opposing
[01:27] <seb128> k :)
[01:27] <seb128> -- other way :p
[01:27] <dholbach> but it's very hard to check hwo the source was altered
[01:27] <dholbach> and i ALWAYS do that when reviewing packages
[01:27] <dholbach> and you should imho do that too
[01:27] <ajmitch> my debian sponsor told me off for repacking the orig tarball :)
[01:27] <ogra> dholbach, please... indeed everybody does that :)
[01:27] <dholbach> in that perspective chainging orig.tar.gz is not very nice
[01:28] <dholbach> ogra: yes?
[01:28] <ogra> dholbach, sure... at least every reviewer i know around here
[01:28] <Riddell> I've also had tar files which are badly made upstream and arn't distcleaned, that should be tidied for .orig.tar.gz in my opinion
[01:28] <dholbach> ogra: i never did see such a comment on REVU expept my own :)
[01:29] <ogra> dholbach, you need to be more around on IRC ;-p
[01:29] <ajmitch> there is the other exception - cdbs & tarball.mk
[01:29] <seb128> if upstream tarball is not nice speak with upstream to get that fixed
[01:29] <dholbach> Riddell: i think it's more important to lart upstream and get it fixed in the diff :)
[01:29] <\sh> the question is, when you generate a CVS/SVN snapshot..is it a real orig.tar.gz or should we handle it in some other way
[01:29] <tseng> \sh: look at evolution-sharp
[01:29] <seb128> dholbach: exactly :)
[01:29] <tseng> evolution-sharp_0.6.99+0.7.orig.tar.gz
[01:30] <\sh> tseng: u made a diff from 0.699 to 0.7...
[01:30] <dholbach> siretart: i never heard of that target before - i'll have a look into it, thanks for the pointer
[01:30] <\sh> ?
[01:30] <tseng> no, i made a snapshot of the 0.7 branch
[01:31] <siretart> dholbach: it is an optinal target, though. But mentioned in debian policy, so I'd consider that as semi official target
[01:31] <\sh> tseng: and u called autogen.sh and created your own tarball?
[01:31] <dholbach> siretart: i'll look into it :)
[01:31] <tseng> autogen and make dist
[01:31] <ajmitch> \sh: that's a standard way to do it
[01:31] <ajmitch> \sh: since there is no existing tarball
[01:31] <siretart> dholbach: section 4.8
[01:31] <dholbach> cvs exports are an exceptional case i think
[01:31] <ogra> dholbach, isnt that what the debian/watch file is for ?
[01:31] <Riddell> I also change .orig from tar when using unsermake but upstream has made the tar for automake
[01:32] <seb128> all the changes can go to the diff.gz
[01:32] <Riddell> seb128: that makes for a muckle .diff.gz
[01:32] <ogra> seb128, s/can/should
[01:33] <dholbach> who took notes for PackagingTips?
[01:33] <ajmitch> ok, so do we have any agreement here?
[01:33] <Riddell> and some changes can't go in .diff e.g. removing files
[01:33] <ogra> Riddell, sure they can
[01:33] <\sh> too many ways are leading to mekkah
[01:34] <Riddell> ogra: removing files can't, means you need to add explicit rm -f  lines to debian/rules
[01:34] <bddebian> heh
[01:34] <ogra> ajmitch, bah, youre just volunteering for a review day master job and cant wait... be patient !
[01:34] <dholbach> i think it's crucial, to encourage new motus to work tidily, to just grab upstream's tarball, apply their changes to it and not let them rip out what they want to make something "easier"
[01:34] <ogra> Riddell, and ?
[01:35] <Riddell> tidier and less error prone to just fix the upstream tar for the .orig
[01:35] <siretart> sorry folks, I need to leave now. See you tomorrow
[01:35] <\sh> cu siretart
[01:35] <bddebian> Later siretart
[01:36] <sistpoty> gn8 siretart
[01:36] <ajmitch> ogra: oh sure, it's my wildest dream ;)
[01:36] <ogra> ;)
[01:37] <dholbach> the problem as i see it, is: it's harder to track what people did to the code, people from other distributions/other developers have no clue, what they did to upstreams code, in my eyes it might even lead to security - imagine a new motu uploading a "modified" upstream source - you'd just read .diff.gz and not recognize what happened
[01:37] <ogra> Riddell, but breaking a holy rule :)
[01:37] <\sh> dholbach: changing upstreams code only via patch in debian/rules patch
[01:37] <dholbach> bye siretart
[01:37] <seb128> dholbach: md5sum should match upstream one
[01:37] <ajmitch> dholbach: I agree, someone reviewing should ideally be able to grab the tarball off upstream's site, confirm md5sum is what you have, and use it
[01:37] <dholbach> \sh: that's what we're talking about
[01:38] <tseng> im not sure why we even need to talk about this :)
[01:38] <dholbach> seb128: that's what i'm saying: never change the upstream orig.tar.gz :)
[01:38] <tseng> it seems obvious.
[01:38] <dholbach> ajmitch: that's what i do
[01:38] <ajmitch> tseng: it is obvious, but not everyone does it
[01:38] <\sh> dholbach: but this is the rule ;)
[01:38] <dholbach> ok, then we can all agree on pushing people to lart upstream, if the code/buildsystem is buggy and fix it in .diff.gz, right?
[01:38] <seb128> yep
[01:39] <dholbach> super
[01:39] <tseng> ++
[01:39] <dholbach> i love you guys
[01:39] <dholbach> last point on the agenda
[01:39] <dholbach> ajmitch: do it! :)
[01:39] <dholbach> seb128: :))))
[01:39] <\sh> dholbach: this is what we're doing all the time..fixing stuff from upstream via patch/dpatc
[01:39] <\sh> h
[01:39] <ajmitch> dholbach: why me? ;)
[01:39] <ogra> yeah, ajmitch for REVIEW MASTER !!
[01:39] <dholbach> ajmitch: it's your point
[01:40] <bddebian> ++
[01:40] <ajmitch> ok, I'm not applying for ReviewMaster, but we need to review *more*! :)
[01:40] <Riddell> dholbach: I trust you'll inform debian's ftpmasters of that policy then
[01:40] <\sh> ajmitch: come on...push us ,-)
[01:40] <ogra> ajmitch, to late... you got the job now :)
[01:40] <ajmitch> dholbach's enthusiasm for review days is great
[01:40] <ajmitch> so I think they need to be a regular part of our calendar
[01:40] <ajmitch> and we need to keep the list as short as possible
[01:41] <ajmitch> of course, feel free to do reviewing at anytime you can
[01:41] <ogra> ajmitch, dholbach will soon have a new job that draws his time.... dont expect him to be much more active then me
[01:41] <ogra> (in motu land)
[01:41] <dholbach> Riddell: i think we established reasons for doing it that way
[01:41] <ajmitch> ogra: yeah, don't expect anyone here to have lots of free time
[01:41] <ogra> ajmitch, and since you brought it up .... :)
[01:41] <ogra> ajmitch, i dont ...
[01:41] <ajmitch> looks like I've got another cap then?
[01:42] <dholbach> ogra: you seem to know more than i do
[01:42] <ajmitch> dholbach: sure, you'll probably find out about your job responsibilities the day you start (or later) :)
[01:42] <dholbach> i always had review days in mind like a measure to catch up on the always growing lists
[01:42] <\sh> ok...last point now...last cigarette
[01:42] <ogra> dholbach, just guessing from experience
[01:42] <ogra> ;)
[01:42] <dholbach> \sh: i have no papers left
[01:42] <ogra> dholbach, next meeting date and time
[01:43] <ajmitch> review days are a good time to make sure that the new guys are around to talk to
[01:43] <dholbach> i hope we'll find a way to get them sorted soon
[01:43] <dholbach> ajmitch: yeah that's true
[01:43] <ajmitch> ogra: 2 weeks or 4?
[01:43] <dholbach> ok... when will be next 1) review day 2) motu meeting?
[01:43] <ogra> we had said 4 once
[01:43] <\sh> ogra: between the last one and now were only 2 ;)
[01:43] <ogra> but if itsrewuired, we should change it
[01:43] <ajmitch> dholbach: next review day in 2 weeks
[01:43] <\sh> as I remember
[01:44] <ogra> \sh, the last one was postponed 2 weeks
[01:44] <ogra> so it were actually 6
[01:44] <ajmitch> by 'day' we mean a 48-hour period or more :)
[01:44] <dholbach> ajmitch: ok, i'll do an announce - august 18th?
[01:44] <\sh> ogra: oh yes
[01:44] <ajmitch> dholbach: sounds good
[01:44] <dholbach> ok, next review day august 18th
[01:44] <\sh> 2.9 + 14 days?
[01:44] <ogra> dholbach, calendar ?
[01:44] <dholbach> next motu meeting when?
[01:44] <\sh> 16
[01:44] <\sh> fits
[01:44] <dholbach> ogra: i'll do it
[01:44] <ogra> great...
[01:45] <dholbach> so when will it be?
[01:45] <dholbach> which time?
[01:45] <dholbach> the motu meeting
[01:45] <ogra> this current meeting isnt mentioned... we are lost without your care dholbach
[01:45] <ajmitch> dholbach: 3 weeks? :)
[01:45] <ajmitch> does this time of day suit people?
[01:45] <dholbach> a bit earlier :)
[01:46] <ajmitch> ok
[01:46] <dholbach> ogra: it is
[01:46] <ogra> iwouldnt say it suits, but better then 6:00 UTC
[01:46] <ajmitch> 20:00 UTC?
[01:46] <bddebian> Aye
[01:46] <bddebian> ajmitch: 20:00 is good
[01:46] <dholbach> yeah
[01:46] <ajmitch> great
[01:46] <comadreja> ++
[01:46] <dholbach> which date?
[01:46] <ajmitch> 8am for me, not too hard :)
[01:46] <ogra> dholbach, since when, i imported the calendar yesterday
[01:46] <ajmitch> dholbach: 3 weeks from now is the 24th
[01:46] <ajmitch> if you want it that soon
[01:47] <ajmitch> we've got a few things for the agenda already
[01:47] <dholbach> ok
[01:47] <ogra> dholbach, haha... 4th 00:00 *g* its there since ~2h it seems, sorry for the noise
[01:47] <dholbach> ogra: 3rd 22:00 utc
[01:48] <ogra> dholbach, my evo translates the TZ to localtime :)
[01:48] <dholbach> ah ok
[01:48] <dholbach> ok
[01:48] <ogra> so it shows up for the 4th
[01:48] <dholbach> one last thing: who will do a quick wrap up for the mailing lists?
[01:48] <dholbach> a quick one
[01:48] <ogra> i already missed the last one...
[01:48] <dholbach> i won't have the time this time
[01:49] <ogra> me neither 11th is feature freeze
[01:49] <\sh> bddebian will do it ,-)
[01:49] <dholbach> i'll do the announces of the next meetings/review days - thanks everybody - you guys rock! :)
[01:49] <ajmitch> dholbach: great, thanks
[01:49] <bddebian> \sh: Sure pretty easy.  "No decisions were made"
[01:49] <ogra> bddebian, volunteering to write a wrap up ?
[01:49] <ajmitch> so who will summarise? bddebian, or shall I volunteer? :)
[01:49] <\sh> bddebian: ;) http://people.ubuntu.com/~fabbione/irclogs/
[01:49] <ogra> bddebian, thanks :)
[01:50] <dholbach> just describe the points on the agenda and 2 sentences on what we decided/discussed :)
[01:50] <ajmitch> looks like it's been decided for poor bddebian
[01:50] <bddebian> Aye, wtf? :-)
[01:50] <ajmitch> bddebian: I can do it if you prefer
[01:50] <ajmitch> but it will take a couple of days for me to get to
[01:50] <\sh> bddebian: actually u r a native speaker...so when I will write all this...damn my english teacher will kill me ,-)
[01:50] <dholbach> good night :)
[01:51] <ajmitch> night dholbach
[01:51] <\sh> ajmitch: let bddebian do it ;)
[01:51] <bddebian> ajmitch: I wouldn't mind but between not being an MOTU nor being on the ML, maybe you should?
[01:51] <bddebian> gnight dholbach
[01:51] <sistpoty> night dholbach
[01:51] <\sh> bddebian: u will write...and I will post
[01:51] <comadreja> nite
[01:51] <\sh> cu guys...
[01:51] <ogra> ciao dholbach
[01:51] <\sh> good night even :)
[01:51] <mbreit> good night...
[01:51] <\sh> bddebian: deal?
[01:52] <bddebian> \sh: deal
[01:52] <\sh> bddebian: ok :)
[01:52] <ajmitch> alright..
[01:52] <ogra> bddebian, http://lists.ubuntu.com/archives/ubuntu-devel/2005-March/005093.html
[01:53] <bddebian> Can I hit it tomorrow morning, my time?
[01:53] <\sh> bddebian: and u'll find the logs of this meeting on http://people.ubuntu.com/~fabbione/irclogs/ so u know what to summarize
[01:53] <\sh> bddebian: yes
[01:53] <ogra> bddebian, you can hit it every time you like...
[01:53] <bddebian> heh
[01:53] <sistpoty> gn8 everybody
[01:53] <bddebian> gnight sistpoty
[01:53] <ajmitch> night sistpoty
[01:53] <bddebian> Go to bed :-)
[01:54] <\sh> will do right now :)
[01:54] <bddebian> I gotta go play with the kids, catch you all later
[01:54] <bddebian> ajmitch: Have fun :-)
[01:54] <ogra> ciao bddebian and thanks :)
[01:54] <\sh> bddebian: play soccer ;)
[01:54] <bddebian> ogra: np
[01:54] <\sh> ok...good night gentlemen :) cu later this morning ;)
[01:54] <bddebian> \sh: Aye :)
[01:54] <bddebian> gnight \sh
[01:54] <ogra> \sh, sleep well
[01:54] <\sh> trying to :)
[01:54] <ajmitch> someone can put the next meeting & review days on the calendar?
[01:55] <janimonoses> good night all
[01:56] <ajmitch> hmm, will do after lunch, someone remind me then :)
[01:56] <robitaille> ajmitch: I can do it a bit later when I update my ics file
[01:56] <ogra> ajmitch, dholbach said he would
[01:56] <ajmitch> robitaille: dholbach has it open for editing
[01:56] <ajmitch> so I'll leave that to him
[01:57] <robitaille> these daniels are so good at updates... :)
[01:57] <ogra> heh
[01:57] <ogra> what would we dou without you :)
[01:57] <ogra> s/dou/so
[01:57] <ogra> do
[01:57] <ogra> grrrr
[01:58] <cyphase> hey everyon
[01:59] <cyphase> everyone*
[01:59] <ajmitch> hello
[02:00] <ajmitch> bye all
[02:01] <robitaille> cyphase:  looking for a meeting?
[02:05] <Seveas> robitaille, this isn't a dating channel ;)
[02:08] <tseng> its not?


[09:42] <syrious> hello?
[21:02] <ruben_> Hello, my laptop (ASUS k53S) does not boot normally anymore (in peppermint 4) all of the sudden, i have to to start with lubuntu livecd and set acpi=no, lacpi=no ...
 otherwise my pc just freezes during boot
 $ dmesg | egrep -i "Error|fail"
 [    0.004000] tsc: Fast TSC calibration failed
 [    8.594848] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
 [    8.990064] iwlwifi 0000:03:00.0: pci_enable_msi failed(0Xfffffffa)
 [   10.752996] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the agpgart module.
 [   10.753065] DRM: Fill_in_dev failed.
 [   11.877526] init: failsafe main process (598) killed by TERM signal
 [   16.421130] atl1c 0000:05:00.0: Unable to allocate MSI interrupt Error: -6
 [  356.716539] mce: [Hardware Error]: Machine check events logged
 does anybody have a clue what could be the issue or here to look, i have allready opened my laptop and the fan seems to working fine btw
 I also resetted bios settings after tinkering with them (after things allready went wrong, so should not be the issue)


[00:46] <daurn> jbernard__, ping?
[00:51] <jbernard__> daurn: yep
[00:52] <daurn> jbernard__, i don't understand revu, but the latest diff looks like its created errors?
[00:52] <jbernard__> daurn: which diff are you referring to? lua-iconv?
[00:52] <daurn> ya
[00:53] <jbernard__> hang on, lemme check
[00:53] <daurn> http://revu.ubuntuwire.com/report.py/diff?upid1=6660&upid2=6657
[00:54] <jbernard__> that diff looks good to me, which part is concering?
[00:55] <james_w> jbernard__: https://edge.launchpad.net/ubuntu/+source/lua-iconv is already available if you would like to subscribe to the bugs for the package
[00:55] <daurn> all the warnnings/notices in the revu look like they're created in that diff to me?
[00:57] <jbernard__> the only warning refers to no debian/watch file or get-orig-source target, that I see
[00:57] <jbernard__> james_w: awesome, thanks
[01:00] <daurn> jbernard__, "Package is for "unstable" but only packages for "karmic" are currently accepted. " and "The changelog does not close a bug from Launchpad. New packages should have a needs-packaging bug and the upload close it using the syntax "(LP: #nnnn)". "
[01:01] <jbernard__> ahh
[01:01] <jbernard__> that was an early upload
[01:01] <jbernard__> i fixed that shortly after
[01:02] <daurn> and my point is the latest diff looked like it un-fixed it to me (it changed back to unstable from karmic, and to changed it from LP: top Closed:
[01:02] <daurn> s/top/to/
[01:04] <jbernard__> so the diff that I'm seeing from the main page: http://revu.ubuntuwire.com/revu1-incoming/lua-iconv-0908172306/lua-iconv_6-0ubuntu1.diff
[01:04] <jbernard__> i do agree that the diff you've got looks a bit odd
[01:05] <daurn> don't worryu
[01:05] <daurn> I fiigured it out
[01:05] <james_w> daurn: I think you are looking at an earlier version, and so the diff is backwards
[01:05] <daurn> I just didn't understand revu
[01:05] <daurn> james_w, yeah >.<
[01:06] <james_w> no worries then :-)
[01:06] <daurn> i don't even know what it means, but why doesn't it have the get-orig-source thing?
[01:07] <daurn> btw, will it get pushed upstream to debian?
[01:07] <jbernard__> ahh, the lua hosting site creates a new (and random) url for each new release tarball
[01:08] <jbernard__> daurn: yep, it's waiting in the NEW queue at the moment
[01:08] <daurn> ok
[01:09] <jbernard__> i don't have an easy solution for that, if anyone's got one, though, I'm all ears
[01:09] <daurn> jbernard__, care to look into another, much much larger request for packaging me?
[01:09] <jbernard__> daurn: i can at least take a look..
[01:09] <daurn> i haven't even made a needs-packaging bug yet as it  might seem like too much
[01:10] <daurn> jbernard__, http://oproj.tuxfamily.org/wiki/doku.php?id=lgob
[01:13] <daurn> I don't know if you can work from an AUR package?
[01:13] <daurn> but theres one here: http://aur.archlinux.org/packages.php?ID=25570
[01:13] <jbernard__> there's a 'Sources' link that has a tarball, so that's probably where I would start
[01:14] <daurn> ok, well, I've gotta head off now
[01:14] <daurn> but thanks for doing iconv
[01:14] <jbernard__> sure, file the needs-packaging bug and I'll see if i can get to it
[01:14] <jbernard__> no problem
[01:15] <daurn> means lgob is the only dep left for my app that has no package
[01:15] <daurn> :)
[01:17] <daurn> cya
[01:33] <rowinggolfer> hi folks.
[01:33] <rowinggolfer> can anyone point me to a howto on where to put my .desktop file?
[01:33] <rowinggolfer> I am trawling the web with no joy.
[01:35] <rowinggolfer> project is http://launchpad
[01:35] <rowinggolfer> https://launchpad.net/~rowinggolfer/+archive/ppa
[01:36] <rowinggolfer> I have a working deb, but need to get desktop integration.
[01:36] <rowinggolfer> this is a pure python app, using disutils
[01:41] <rowinggolfer> no worries - found this https://help.ubuntu.com/community/PythonRecipes/DebianPackage
[02:13] <kklimonda> is there an official way of getting diff between orig and dfsg tarballs? or somewhere where I can see a list of changes?
[02:14] <directhex> kklimonda, it ought to be documented in README.source
[02:15] <directhex> or failing thst the packager should have a get-orig-source rule which does it
[02:18] <kklimonda> directhex: thanks.
[04:00] <EagleScreen> should debootstrap 1.0.15 from Debian unstable know about karmic release?
[04:54] <ipatrol> Hello?
[04:55] <EagleScreen> many few people at this time
[04:55] <ipatrol> devel sent me here
[04:55] <EagleScreen> visit the links on the top, ipatrol
[04:57] <ipatrol> yes
[06:55] <dholbach> good morning
[07:14] <porthose> dholbach, good morning :)
[07:16] <porthose> would a kind MOTU please ACK Bug #415102.  :)
[07:16] <dholbach> porthose: taking a look
[07:19] <slytherin> dholbach: ping
[07:20] <porthose> dholbach, ty :)
[07:21] <dholbach> slytherin: pong
[07:21] <slytherin> dholbach: Sorry, I couldn't respond to the mail till now. Have been busy with other tasks.
[07:22] <dholbach> slytherin: no worries - just follow up on it when you have the time - I'll keep nagging you ;-)
[07:27] <slytherin> asac: I tried updating obexd yesterday. It was simple 'get new source and build'. I couldn't actually test it. It seems my phone's bluetooth support is broken.
[07:31] <porthose> dholbach, ty :)
[07:31] <dholbach> no worries
[07:32]  * porthose huges dholbach
[07:32]  * dholbach hugs porthose back :)
[08:18]  * quadrispro hugs all
[08:18]  * quadrispro asks if everyone has some time to spend in a REView
[08:22]  * quadrispro oops, s/everyone/anyone
[10:29] <slytherin> ttx: Any ides why ant-optional is not getting installed, http://launchpadlibrarian.net/30455994/buildlog_ubuntu-karmic-ia64.java3d_1.5.2%2Bdfsg-2_FAILEDTOBUILD.txt.gz
[10:29] <ttx> slytherin: yes.
[10:30] <ttx> let me fix that.
[10:30] <slytherin> what is the issue?
[10:31] <ttx> slytherin: basically I moved libxerces2-java to build "any" so that it can have spearate recommends on -gcj based on  arch
[10:31] <slytherin> Right you told me.
[10:31] <ttx> however libxerces2-java fails to build, since it build depends on itself.
[10:31] <slytherin> he he
[10:31] <ttx> well, it depends on ant
[10:31] <ttx> which depends on libxerces2-java
[10:32] <ttx> so... I'll just move it back to arch:all and suggest the -gcj stuff
[10:32] <slytherin> Let me know when you fix it. :-)
[10:33] <slytherin> asac: Not sure if you know this already. There is a bluetooth plugin in network-manager (in karmic). From build logs it looks like the plugin is getting built but it is not installed anywhere.
[10:33] <ttx> slytherin: as soon as i'm done with my sponsoring task.
[10:33] <slytherin> Take you time. Anytime before weekend.
[10:34] <ttx> it's blocking most java builds on ia64/armel/sparc.
[10:34] <ttx> so I'll fix it now.
[10:43] <asac> let me check
[10:46] <asac> slytherin: you mean on applet side?
[10:46] <slytherin> asac: no, I mean the core code.
[10:48] <asac> slytherin: on the daemon side there is no plugin ... its directly linked into the main binary and in libnm-util
[10:48] <asac> but i think you are right. the applet needs libgnome-bluetooth build depends and also ensure that the plugin gets installed to right place
[10:50] <slytherin> asac: I misunderstood the build log of daemon then.
[10:53] <juli__> slytherin, Hi! It looks like sf.net still have problem:( so I checked my corrections manually. Should I upload cobertura on REVU again?
[10:53] <slytherin> juli__: Upload it somewhere so that I can review.
[10:54] <juli__> slytherin, ok I'll upload on REVU soon
[11:01] <juli__> slytherin, done: http://revu.ubuntuwire.com/p/cobertura
[11:06] <slytherin> give me some time, busy with office task.
[11:08] <asac> slytherin: ok so https://edge.launchpad.net/~network-manager/+archive/trunk will have it tonight
[11:08] <asac> upload will happen in two days or so
[11:13] <juli__> slytherin, ok, no problem:) Thank you!
[11:39] <Hew> fteqcc "failed to upload", what can be done about this?
[11:39] <pochu> what was the way to create a tarball with the same hash? -m option to tar?
[11:40] <geser> Hew: bug in LP, let me find the bug number
[11:40] <Laney> pochu: tar --mtime=@0
[11:41] <Laney> and then gzip -9fn
[11:41] <pochu> Laney: that's it, thanks!
[11:42] <juanje> dholbach: Hi, have you some time?
[11:43] <Hew> geser, would it be bug 408528?
[11:43] <geser> Hew: yes
[11:44] <Hew> thanks for the info geser, at least it's not a problem with fteqcc itself :-)
[11:44] <juanje> dholbach: well, when you can... I did change the stuff you told me the other day on the http://revu.ubuntuwire.com/p/nautilus-md5sum package. Please, have a look at it when you can. Thanks ;-)
[11:52] <gilir> can someone change my status on REVU ? I can't review any package
[11:57] <juanje> if someone is up for reviewing, I got two packages just cleaned up which need a review: http://revu.ubuntuwire.com/p/nautilus-md5sum  and  http://revu.ubuntuwire.com/p/mount-systray  ;-)
[11:57] <juanje> thanks in advance
[11:57] <juanje> :-)
[12:14] <slytherin> juanje: Does the md5sum extension work only for ISO files?
[12:17] <pochu> Laney: I get this:
[12:17] <pochu> E: scribes: package-contains-ancient-file usr/share/doc/scribes/TODO 1970-01-01
[12:17] <pochu> E: scribes: package-contains-ancient-file usr/share/doc/scribes/changelog.gz 1970-01-01
[12:17] <pochu> I: scribes source: tar-errors-from-source scribes-0.4~r473/intltool-update: implausibly old time stamp 1970-01-01 00:00:00
[12:17] <pochu> I: scribes source: tar-errors-from-source scribes-0.4~r473/intltool-merge.in: implausibly old time stamp 1970-01-01 00:00:00
[12:17] <Laney> yeah
[12:18] <pochu> Laney: seems to be because of --mtime=@0
[12:18] <Laney> you can change @0 to something else if you want
[12:18] <pochu> Laney: something arbitrary?
[12:18] <Laney> something more recent
[12:18] <Laney> I'd be tempted to ignore or override it though
[12:20] <Laney> or you could somehow retrieve the timestamp of the downloaded tarball and use that
[12:23] <sistpoty|work> gilir: done
[12:23] <pochu> it's a bzr export
[12:24] <pochu> and seems to be changing the timestamps with every export
[12:25] <Laney> well you could always be clever with commit timestamps or something
[12:25] <Laney> I'm not sure that it's worth the effort
[12:25] <juanje> Sylphid: I'm really sure, I just fix some stuff at teh package
[12:25] <juanje> ups
[12:25] <juanje> slytherin: the message was for you
[12:26] <juanje> slytherin: I can ask to who did it, but I think that, by now, it just work for iso files
[12:26] <slytherin> juanje: what I meant was , does it not work for other file types?
[12:27] <juanje> slytherin: I think not. At least, not in this version
[12:29] <slytherin> ttx: LOL. Now you have more problems related to libxerces2-java. :-P
[12:29] <slytherin> libxerces2-java itself is failing to build.
[12:29] <ttx> slytherin: nah, just a timing issue :)
[12:30] <slytherin> oh
[12:30] <ttx> the all package was not published yet for those to use it
[12:30] <ttx> I'm retrying them now
[12:45] <Laney> whoops
[12:45] <Laney> I totally forgot to reply to that archive reorg mail
[12:46]  * Laney does it Right Now
[12:48] <hyperair> what archive reorg mail?
[12:49] <Laney> hyperair: secret mail to developers
[12:49] <DktrKranz> hyperair: MOTUs were asked which kind of upload privileges they want after archive-reorg
[12:49] <Laney> How to organise hyperair into the cupboard and only let him out for feeding
[12:49] <hyperair> ah i see
[12:50]  * hyperair forces Laney into a cupboard and tosses a donut in
[12:50] <Laney> first toss, then no forcing required
[12:50] <Laney> nomnom
[12:50] <DktrKranz> and obviously secret plans for hyperair to pay ice cream to MOTUs
[12:50] <hyperair> haha
[12:51] <gilir> sistpoty|work: thanks :)
[12:59] <Laney> my laptop is so screwed
[13:11] <directhex> Laney, unscrew it!
[13:11] <Laney> I think it would involve a reinstall
[13:11] <Laney> damn osx
[13:11] <Laney> maybe Karmic will work well on it now :O
[13:12] <directhex> my office pc died :(
[13:12] <Laney> hardware?
[13:12] <directhex> Laney, clunky disk
[13:12] <Laney> at least applecare is decent
[13:13] <directhex> it's intensely slow. unless you take it to your nearest aplpe premium partner under applecare, and add some middleman for speed
[13:14] <Laney> I took it in on Thursday and got it back on Monday for a new hard disk
[13:14] <Laney> was reasonable enough
[13:15] <directhex> my machine's in bristol right now
[13:15] <Laney> orly
[14:06] <ttx> slytherin: the build issue with libxerces2-java on ia64/sparc/armel should be gone now.
[14:10] <directhex> yays!
[14:21] <alkisg> How could I put a repository into a CD? Like, when I insert the ubuntu alternate CD, when I get prompted to install packages from it?
[14:22] <slytherin> ttx: thanks. Let me try rebuilding the packages that were failing for me.
[14:22] <slytherin> alkisg: you might want to try aptoncd.
[14:23] <alkisg> slytherin: I think that doesn't use the same method like the ubuntu alternate cd, i.e. the end user needs aptoncd to install the packages
[14:24] <slytherin> alkisg: Then probably it is the update-manager that handles alternate CD specially.
[14:24] <alkisg> I think so, yeah. I'm looking for information on what to put to the CD so that update-manager can handle it
[14:24] <alkisg> I tried putting the dist/ and pool/ folders from my repository, but it didn't work...
[14:37] <slicer> Can someone give me access to bug 407848 so I can close it? :) I have access to 412873 but that's a duplicate of the original, so I can't change its state.
[14:38] <Laney> slicer: try now
[14:39] <slicer> Laney: Thanks :)
[14:40] <slicer> Laney: BTW, how come I didn't have access to it originally? I thought I had access to all bugs against my package?
[14:40] <Laney> slicer: Private bugs are visible to their subscribers only
[14:41] <slicer> Laney: Ah. So I won't be notified until someone on the bug squad makes it public?
[14:41] <Laney> right
[14:41] <Laney> of course you could join bug control yourself...
[14:42] <slicer> Laney: Would that be appropriate when I'm really only interested in bug reports for 2-3 packages?
[14:42] <Laney> I don't think that matters
[14:42] <slicer> Laney: In that case.. *goes to google*
[14:42] <Laney> but ask bdmurray
[14:44] <slicer> bdmurray: Is it appropriate to join bug control when I'm really only interested in bug reports for "my" packages?
[14:44] <Laney> imho we are short of triagers for universe packages, and want people with a special interest
[14:46] <slicer> Well, the original bug report was 12 days old when the duplicate was filed; I never saw the original, or I'd have the fix commited 2 weeks ago ;)
[14:47] <slytherin> slicer: have you subscribed to the bug mail for your packages?
[14:47] <Laney> go for it
[14:47] <slicer> slytherin: I get email for all other bug reports, but apparantly not private ones.
[14:48] <slytherin> hmm
[14:48] <slytherin> got to go, see you all later.
[14:50] <slicer> Ah, there's even a "way to join" for upstream developers. Perfect :)
[15:03] <mzz> so (still assuming you let me ask packaging questions here even if they're not directly motu-related) I'm still trying to find the best tools to use for actual building. I really want to like sbuild/schroot's lvm-snapshot support, but I can't find a way to not reinstall all the source deps for every build conveniently.
[15:03] <mzz> is there some trick I'm overlooking? I'd expect there to be a way to snapshot the master image with the source deps installed, so they don't have to be refetched for every build attempt
[15:05] <mzz> I think I can actually do that by hand, but if it was a reasonable thing to do I'd expect it to be easier :)
[15:07] <mathiaz> mzz: I'd suggest to use a local apt cache so that packages don't need to be refetched from the network
[15:07] <mzz> mathiaz: oh, the network fetch isn't an issue, it's the time needed to actually install a few 100 source dependencies.
[15:08] <mathiaz> mzz: I wouldn't recommend to leave all the dependencies in the pristine chroot
[15:08] <mzz> yeah, that wouldn't be good.
[15:08] <mzz> but couldn't I make a snapshot of that pristine chroot, then install the dependencies, then have sbuild make another snapshot of that snapshot?
[15:08] <mathiaz> mzz: if you leave dependency in the source chroot then you may miss some of them in your build-dep
[15:08] <mathiaz> mzz: and then the build would fail on the buildd
[15:08] <mzz> this is true.
[15:09] <mathiaz> mzz: another solution is to have two chroots
[15:09] <mathiaz> mzz: a minimal one and another one with all the build deps always installed
[15:09] <mzz> I understand why sbuild goes out of its way to use a clean build environment, and I think that's a really good thing. But I *also* want a way to build a package more quickly while I'm still tinkering with the packaging.
[15:10] <mzz> yes, and I think I could do that second chroot via a snapshot of the first
[15:10] <mathiaz> mzz: you could just create a second chroot and install all the build dep in the source chroots
[15:11] <mathiaz> mzz: if you use schroot+lvm, you can enter the source chroot with: schroot -c karmic-source -u root
[15:11] <mathiaz> mzz: you just append -source to the name of the chroot
[15:11] <mathiaz> mzz: everything you installed in the -source chroot will be kept afterwards
[15:12] <mzz> I think I'll just create a snapshot of my jaunty_chroot lv, install the source deps in there, install dependencies (as indicated above :), get the package working right, then roll jaunty_chroot back to the snapshot (still have to look up the right lvm incantation for that)
[15:12] <mathiaz> mzz: does lvm support snapshots of snapshots?
[15:12] <mzz> let's find out!
[15:13] <c_korn> how do I tell cdbs to run autoreconf at the beginning ? google pointed me to a cdbs patch which never got into ubuntu: https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/026954.html
[15:15] <mathiaz> c_korn: you can use the makebuilddir target
[15:15] <mzz> (so far this really is me tinkering for personal use, but I'll probably end up building a few things that should go into a ppa at least)
[15:16] <mathiaz> c_korn: http://paste.ubuntu.com/255153/
[15:17] <c_korn> mathiaz: thanks
[15:24] <EagleScreen> hello
[15:24] <EagleScreen> i am trying to build some ubuntu packages in my Debian system, but i have problems: http://paste.ubuntu.com/255159/
[15:27] <sistpoty|work> EagleScreen: I assume you should use --mirror http://archive.ubuntu.com as an argument to pbuilder (or some such)
[15:28] <mzz> mathiaz: my other plan was to use schroot's session support, but I haven't manage to trick sbuild into using an existing session yet
[15:28] <EagleScreen> yes i am using de.archive.uubntu.com
[15:29] <EagleScreen> but well spelled lol
[15:29] <virtuald> do you have ubuntu-keyring installed?
[15:29] <EagleScreen> i have found a workaround, adding --allow-unauthenticated to debootstrapopts
[15:30] <EagleScreen> shall i install it in host system or in chroot?
[15:30] <virtuald> no idea
[15:30] <mathiaz> mzz: I'd suggest to create two chroots (ie have two lvs) and put all the build dep in one them
[15:30] <mathiaz> mzz: you can always get rid of the latter when you've finished testing your packakge
[15:30] <mathiaz> mzz: building a chroot is a matter of minutes
[15:30] <mzz> mathiaz: yes, but the set of build deps won't be the same all the time (I'm not building the same package all the time) so I'd have to blow that chroot away again frequently. Just basing it off the perfectly decent chroot I already have seems reasonable.
[15:31]  * mzz is picky
[15:31] <mzz> also, assuming lvm actually supports stacking snapshots like this it'll be pretty easy.
[15:31]  * mzz tries.
[15:31] <mathiaz> mzz: sure - if lvm supports snapshots of snapshots
[15:32] <mathiaz> mzz: otherwise you can just dd the minimal chroot when creating a new one
[15:33] <mzz> :( "Snapshots of snapshots are not supported yet."
[15:33] <mzz> and it was such a good plan! Let's see if I can find an eta for this
[15:38] <bddebian> Heya gang
[15:44] <EagleScreen> i have installed uubntu-keyring due to the pbuilder problem here http://paste.ubuntu.com/255159/
[15:44] <EagleScreen> this is the output http://paste.ubuntu.com/255172/
[15:44] <EagleScreen> any mention to ubuntu?
[16:03] <EagleScreen> cdebootstrap 0.5.5 and debootstrap 1.0.15 (Debian unstable) don't know about jaunty and karmic suits
[16:04] <alkisg> I have a repository with educational apps, how can I put them in a DVD so that update-manager would be able to read the packages from it?
[16:59] <hggdh> c.f. bug 415435 -- what is the S.O.P. for licence mismatch (packages states GPLV2+, source states GPLV3+)?
[17:00] <Laney> hggdh: Forward it to Debian please
[17:00] <Laney> the package is on sync
[17:00] <Laney> in
[17:01] <hggdh> yes, I was unsure. Will do, manually, since reportbug seems to like to sigsegv on me. thanks, Laney
[17:18] <qnix> what's the site for *-security packages ?
[17:20] <kees> qnix: do you mean security.ubuntu.com?
[17:21] <qnix> I mean something like packages.ubuntu.com
[17:22] <qnix> but for the packages in *-security repos
[17:22] <kees> qnix: normally i just use launchpad directly.  which package do you want details on?
[17:22] <kees> (I thought packages.ubuntu.com contained -security too, but it lags a bit)
[17:23] <qnix> I would like to see if a security patch I've made is in the repository and available
[17:24] <kees> qnix: which package?
[17:24] <ryanakca> look at http://launchpad.net/ubuntu/+source/<packagename>/  ... might see something in the changelog
[17:25] <qnix> seems that the url of ryanakca do the job. but my patch is not yet available.
[17:25] <qnix> thanks
[18:02] <j^> happyaron, was anything specific not ok with the package i updated at http://revu.ubuntuwire.com/p/oggvideotools
[18:02] <happyaron> j^: not really, but the project maintainer of gmchess asked me to do that
[18:03] <happyaron> j^: oh, sorry
[18:03] <happyaron> get mistaken on project
[18:03] <j^> i uploaded a version based on cdbs, you another version, was just wondering
[18:04] <happyaron> j^: That's a mis-doing on oggvideotools, but didn't have time to ask you, so sorry
[18:04] <j^> i dont care one way or the other, as long as it gets into 9.10
[18:04] <happyaron> j^: I didn't see anyone replied on that bug
[18:05] <happyaron> j^: if you could maintain it that's better, the day before yesterday a friend ask me to help him maintain package for his project
[18:06] <happyaron> but his project still needs lots of work, i am also considering how to deal with that oggvideotools,:)
[18:07] <happyaron> j^: you could re-upload to replace mine
[18:07] <j^> right now i can not upload packages to universe, so i would depend on someone else doing that, i am willing to update it as new version of oggvideotools come out
[18:08] <j^> happyaron, can you upload to universe?
[18:09] <happyaron> j^: I am also not a MOTU, either
[18:10] <happyaron> j^: no, I cannot
[18:10] <j^> ok will push my version again, i think it a bit cleaner and has a working debian/watch file
[18:11] <happyaron> j^: that's good
[18:22] <mzz> another stupid sbuild question: I can see in the logs a .ddeb was built, but it's not copied out of the chroot. Any way I can change that?
[18:40] <jtimberman> mathiaz: I pushed a new upload for merb.
[18:57] <mathiaz> jtimberman: great - I'm reviewing the other packages
[18:58] <jtimberman> mathiaz: thanks!
[19:01] <mathiaz> jtimberman: IIRC libsyntax-ruby   is the only package that does *not* to be reviewed on REVU?
[19:01] <mathiaz> jtimberman: IIRC libsyntax-ruby   is the only package that does *not* need to be reviewed on REVU?
[19:01] <jtimberman> mathiaz: correct, libsyntax-ruby is deprecated in chef for coderay.
[19:01] <jtimberman> coderay/libcoderay-ruby
[19:49] <mathiaz> jtimberman: libsystemu-ruby is already in debian
[19:49] <jtimberman> mathiaz: that happened over the weekend.
[19:50] <mathiaz> jtimberman: great - I've filed a sync request for ubuntu
[19:50] <jtimberman> mathiaz: awesome, thanks!
[19:50] <jtimberman> i saw notices that the mixlibs were synced
[19:51] <jtimberman> oh, and merb is MIT license.. updating the man pages and other bits.
[19:51] <jtimberman> the installedfiles and .configs were there from when i built the actual .debs for my testing repo :)
[20:06] <jtimberman> mathiaz: new upload for merb (two uploads, consider the second, i didn't verify the lsdiff output before uploading the first)
[20:10] <mathiaz> jtimberman: ok - I'll review that after stompserver
[20:10] <jtimberman> thanks!
[20:11] <mathiaz> jtimberman: IIUC stompserver doesn't provide an upstream release tarball?
[20:11] <mathiaz> jtimberman: and this why the package is native?
[20:12] <mathiaz> jtimberman: hm - no it seems that there is an upstream tarball
[20:12] <mathiaz> jtimberman:      stompserver-0.9.9.tgz
[20:13] <jtimberman> mathiaz: Not entirely sure, I adapted the package btm was working on for Debian.
[20:14] <jtimberman> stompserver isn't even in Debian NEW yet per the ITP
[20:25] <jtimberman> mathiaz: coderay re-uploaded w/ changes.
[20:43] <mathiaz> jtimberman: send feedback on stompserver - that one may require more work
[20:44] <jtimberman> mathiaz: ok
[20:44] <mathiaz> jtimberman: let me know if you have any question on the comments I made
[20:44] <jtimberman> mathiaz: i'm making a couple changes to chef based on what you've looked at for other packages (man page license stuff, copyright, uploaders, etc)
[20:44] <jtimberman> going to finish that and re-upload chef in a few.
[20:44] <jtimberman> then i'll take a look at stompserver
[20:44] <mathiaz> jtimberman: right - I haven't looked at chef yet
[20:45] <mathiaz> jtimberman: I'll go through the other package first (merb, stompserver, coderay)
[20:45] <mathiaz> jtimberman: and then start looking at chef
[20:45] <jtimberman> k
[20:53] <jtimberman> mathiaz: does the patch tagging recognize "DebianSpecific" as well?
[20:53] <jtimberman> or just UbuntuSpecific
[20:55] <mathiaz> jtimberman: I don't think DebianSpecific is recognized
[20:55] <jtimberman> okay.
[20:56] <mathiaz> jtimberman: you can see the Debian Patch tagging guidline in DEP3
[20:56] <mathiaz> jtimberman: however dep.debian.net is offline for now
[20:57] <mathiaz> jtimberman: google for "debian dep3" and you'll be able to retrieve a cached copy
[20:57] <jtimberman> came up for me.
[20:57] <jtimberman> :)
[20:57] <mathiaz> jtimberman: dep.debian.net?
[20:58] <jtimberman> http://dep.debian.net/deps/dep3/
[20:58] <mathiaz> jtimberman: hm - interesting
[20:58] <mathiaz> jtimberman: anyway there doesn't seem to have a DebianSpecific tag.
[21:01] <jtimberman> mathiaz: can i have 'daemonuser' be 'daemon', which already exists?
[21:01] <jtimberman> or does it have to be a user named after the package/service
[21:02] <mathiaz> jtimberman: better to have user named after the service
[21:05] <jtimberman> k
[21:09] <mathiaz> jtimberman: http://paste.ubuntu.com/255351/
[21:09] <mathiaz> jtimberman: ^^ this is some code to create a system user that needs to be added to the postinst script
[21:09] <jtimberman> gotcha.
[21:10] <jtimberman> so i try to set the log directory in the stompserver config file, and it wants to make it /var/lib/stompserver/var/log/stompserver .. i know FHS discourages logging to /var/lib, but this seems to be a limitation in the stompserver code itself.
[21:10] <mathiaz> jtimberman: and you also need to delete user on purge (in the postrm script)
[21:10] <jtimberman> will do
[21:11] <mathiaz> jtimberman: could symlink /var/log/stompserver to /var/lib/stompserver/log/ ?
[21:11] <mathiaz> jtimberman: apache2 does something similar
[21:13] <jtimberman> egh, it puts the pid file in there too.
[21:15] <mathiaz> jtimberman: hm - how easy would it be to patch the code to do the right thing?
[21:15] <jtimberman> mathiaz: that i don't know, i've not looked at the stompserver internals.
[21:16] <mathiaz> jtimberman: it seems that it just takes /var/lib/stompserver as the base directory
[21:16] <jtimberman> well thats in the config file.
[21:17] <mathiaz> jtimberman: http://paste.ubuntu.com/255358/
[21:17] <mathiaz> jtimberman: in lib/stomp_server.rb
[21:17] <jtimberman> oh geez. thats silly.
[21:19] <mathiaz> jtimberman: could a logdir and pidfile options be added?
[21:26] <stochastic> can any kind motu with a free minute take a loot at http://revu.ubuntuwire.com/p/a2jmidid ?
[21:55] <james_w> stochastic: are you on karmic?
[21:55] <stochastic> james_w, I have a karmic boot, yes
[21:55] <james_w> are you logged in to it now?
[21:55] <stochastic> nope not right now
[21:56] <james_w> ok
[21:56] <stochastic> why?
[21:56] <james_w> http://paste.ubuntu.com/255382/
[21:58] <stochastic> ahh, yes, someone told me that 3.8.2 was the latest standards version and packages should be updated to that, so that's what I did
[21:58] <james_w> plus, you don't need to list all the files that are under the dominant license, just list the exceptions
[21:59] <stochastic> okay, I just wanted clarity on the matter, shall I create a new upload?
[22:00] <james_w> sure
[22:00] <james_w> advocated
[22:01]  * james_w goes back to coding
[22:02] <stochastic> james_w: thanks
[22:12] <binarymutant> will the Dev Week schedule be put into the Fridge's calendar?


[00:00] <StevenK> Okay, I'll sort that out with Praj
[00:13] <StevenK> rustyl_: So when is this call happening?
[00:13] <rustyl_> StevenK, i don't know
[00:16] <StevenK> rustyl_: Is Mauri around there?
[00:16] <rustyl_> let me see
[00:17] <rustyl_> StevenK, she is not on irc, but she is in the office.... StevenK who was calling the meeting, were you asking for this, what it davidm?
[00:17] <rustyl_> s/what it/was it/
[00:17] <StevenK> EPARSE
[00:18] <StevenK> rustyl_: I thought Mauri was calling the meeting, based on the flurry of e-mail I got this morning.
[00:22] <rustyl_> StevenK, just talked to Mauri... she basically said... 'Canonical guys are having a hard time getting helix + hw accelerated codecs working, so we were asked to walk them through it'
[00:23] <rustyl_> StevenK, and all i will say is: first integrate all the graphics components, and only after that should you expect the codecs to work
[00:24] <rustyl_> but... Calvin can not make this time to walk through any issues you have with integrating the graphics components
[00:24] <rustyl_> StevenK, do you already have all the 2d/3d/libva all figured out and working?
[00:24] <rustyl_> or do we need Calvin?
[00:25] <StevenK> rustyl_: Well, sure, but I'm having a hard time reconciling packages to if they are required for 3d, since Hardy includes the 2d driver already
[00:26] <rustyl_> i'm not going to be any help getting all the graphics components working... that is all coming from Calvin
[00:27] <StevenK> rustyl_: Even a mapping of what package is for what bit if you know would be very helpful.
[00:28] <rustyl_> i don't even know what you guys are being handed.
[00:28] <StevenK> The 3d driver from ARMS.
[00:28] <rustyl_> for our gutsy based images, i have three different psb-*.deb packages that i install
[00:28] <StevenK> Which also includes the 2d driver, too
[00:29] <rustyl_> so then... the packages are no coming in a form that you can just 'install'?
[00:29] <rustyl_> because of conflicts in hardy?
[00:30] <StevenK> Well, I'd rather not install the 2d driver from the package since hardy already provides it
[00:34] <rustyl_> StevenK, ok, so forgetting about unhappiness with the form of the graphics drivers as they are arriving.... if you just install the packages (as is), then are you seeing issues with helix + hardware accelerated codecs?
[00:36] <StevenK> rustyl_: If I force everything to be installed, 3d works. I didn't yet have helix in a state where I could test it. Now I do, but I wanted to get the 3d driver sorted out as well
[00:37] <rustyl_> ok, i was under the impression that you were running into issues getting the codecs to work, but I could never get an answer from anyone on what the problem was
[00:38] <rustyl_> StevenK, btw... do you have the umc_va_player from ARMS? It's a nice way to verify that your libva + 3d driver is really working without using helix (basically remove another variable from the equation)
[00:39] <StevenK> rustyl_: No, I don't have that.
[00:40] <rustyl_> StevenK, look in your home directory on moblin
[00:41] <rustyl_> it's just a stand command line player that spits out a bunch of debug info and doesn't depend on installed codecs or media infrastructure
[00:42] <rustyl_> stand along that is
[01:40] <MutantBC> hi
[01:41] <MutantBC> have anyone experience  an error when installing the mobile image creator - "Couldn't find package mobile-image-creator"?
[01:41] <MutantBC> im using ubuntu 7.10 oem version
[01:41] <StevenK> It's moblin-image-creator
[01:42] <MutantBC> yes its still the same "Couldn't find package moblin-image-creator
[01:43] <StevenK> Do you have universe enabled?
[01:43] <MutantBC> where can i find that?
[01:43] <MutantBC> how do i check if the universe is enabled?
[01:43] <StevenK> System->Administration->Software Sources
[01:44] <MutantBC> ok one moment
[01:58] <MutantBC> StevenK do I have to reload? coz the downloading is taking awhile even though the internet connection here is fast
[01:59] <StevenK> MutantBC: You should have to, no.
[02:02] <MutantBC> StevenK: Ok
[02:03] <MutantBC> StevenK: Are the packages that to be downloaded are huge?
[02:03] <StevenK> I don't think they are.
[02:06] <MutantBC> StevenK: that strange, coz the downloading is slow but the browsing is fast
[02:07] <StevenK> Perhaps you need to pick a faster mirror
[02:14] <MutantBC> StevenK: How do I do that?
[02:15] <MutantBC> StevenK: Can you suggest which mirror is faster?
[02:16] <StevenK> MutantBC: Change the "Download from" in Software Sources
[02:31] <MutantBC> StevenK: Ok
[03:30] <MutantBC> StevenK: but still slow been choosing a lot of mirror sites
[03:31] <StevenK> MutantBC: You aren't clear on what is slow.
[03:35] <MutantBC> StevenK: downloading the packages from the Software Sources is taking too long
[03:36] <MutantBC> StevenK: I kept swtiching to a better mirror site but still downloading around 600 B/s
[03:37] <StevenK> MutantBC: Right. The right forum to ask questions about what to do in that case is #ubuntu
[03:40] <MutantBC> StevenK: I just wanted to download the moblin-image-creator but without updating the Software Sources, I can't do anything
[03:47] <MutantBC> StevenK: #ubuntu is too crowded, they said its normal to get a slower speed on the mirror servers when updating the packages from the Software Sources
[03:47] <MutantBC> :(
[04:28] <MutantBC> StevenK: Can the moblin image create a customize image for a specific device such as 7" similar to eeePC?
[05:01] <MutantBC> Can the moblin image create a customize image for a specific device such as 7" similar to eeePC?
[05:24] <nrp> MutantBC: right now it only does mccaslin and menlow stuff, of which the eee is neither
[05:25] <nrp> you could just install ubuntu server on the eee and install the ubuntu-mobile package
[06:32] <MutantBC> nrp: so you mean I have to install ubuntu to the eeePC and later install the ubuntu mobile?
[06:32] <MutantBC> nrp: can I just install the ubuntu mobile?
[06:32] <MutantBC> nrp: can i just install the ubuntu mobile to the eeePC?
[06:43] <nrp> itll be infinitely easier for you to just install ubuntu server, and the ubuntu-mobile package
[06:44] <nrp> if you want to make it difficult and save a little space, you could use debootstrap and make a really basic install to install ubuntu-mobile onto
[06:47] <nrp> don't expect to get anything usable though. unless you're doing development or are just bored, youre better off going with something else
[06:47] <dholbach> good morning
[06:47] <nrp> mornin'
[06:54] <WcktKlwn> what kind of devices are supported under ubuntu mobile?
[06:58] <dholbach> see the topic: https://wiki.ubuntu.com/MobileAndEmbedded/FAQ
[07:17] <MutantBC> nrp: Ok
[07:18] <MutantBC> nrp: right now im using VIA VX800 chipset, which i don't think Ubuntu 7.10 is supported on this chipset
[12:16] <Fenario> KevinTW: ping
[16:23] <davidm> Don_Johnson, http://linuxdevices.com/news/NS5429881813.html
[21:47] <bert_> hi, I'm trying to get onto ubuntu mobile (installed the packages) but it doesn't seem to work
[21:47] <bert_> do I need some kind of alpha image ?
[21:49] <bert_> anyone ?
[21:55] <nrp> bert_: what did you install it onto
[21:56] <bert_> I just took a clean 32-bit ubuntu 7.10
[21:56] <bert_> and then installed ubuntu-mobile and ubuntu-mobile-dev
[21:59] <bert_> nrp ???
[21:59] <nrp> are you using it with Xephyr?
[22:01] <bert_> nrp: what's Xephyr ?
[22:04] <nrp> lets you run X inside X
[22:05] <nrp> theres a guide to using ubuntu-mobile with it somewhere on the ubuntu wiki
[22:05] <bert_> really
[22:05] <bert_> I didn't get the information that was on there
[22:05] <bert_> (I'm not a native-english speaker
[22:05] <bert_> )
[22:07] <bert_> I have to go now
[22:07] <bert_> thx for your help
[22:29] <GrueMaster> davidm ping
[22:35] <davidm> Hi GrueMaster
[22:37] <GrueMaster> I got a note from Don re USB Client.
[22:37] <GrueMaster> I just got the source tree this afternoon (everyone was sending me links but no access - doh).
[22:38] <GrueMaster> What did you need info on?


[15:03] <czajkowski> Aloha
[15:05] <duanedesign> o/
[15:10] <czajkowski> duanedesign: hey how are you doing
[15:10] <czajkowski> duanedesign: if you're free at some point mind if I nab you for a short chat at some point please
[15:24] <duanedesign> czajkowski: i am doing well thank you. Just doing a little catch up work.
[15:24] <duanedesign> czajkowski: i am free if you want to chat
[15:30] <czajkowski> duanedesign: thanks
[22:21] <paultag> Howdy, ya'll
[23:05] <nigelb> howdy paultag
[23:25] <rrnwexec> hello community stars. any UCW questions?
[23:43] <paultag> rrnwexec: nonsir. Are we all set?
[23:43] <paultag> nigelb: s'new?
[23:43] <rrnwexec> we are all set :)
[23:44] <paultag> rrnwexec: great :)
[23:44] <rrnwexec> thanks to our community rockstars like Paul ::
[23:44] <paultag> oh ppffft, flattery will get you everywhere
[23:44] <rrnwexec> aha
[23:48] <popey> rrnwexec: I am impressed at the work you've done for UCW
[23:48] <rrnwexec> alan. thank you. i'm pretty jazzed about UCW and i think we can really amp this up.
[23:48] <rrnwexec> it's time.
[23:52] <popey> guess I should write my talk! :D
[23:53] <popey> (before wednesday)
[23:53] <rrnwexec> hee. that would make some sense ;)
[23:53] <popey> we're not using learnid are we?
[23:54] <popey> or at least not compelled to use it
[23:54] <nigelb> lyz still had trouble at UDW with lernid.
[23:54] <nigelb> So, I really hope not.
[23:54] <pleia2> we're hoping to have a PPA ready for cloud days
[23:54] <popey> well, I'll probably be on windows at work which makes using lernid somewhat problematic
[23:54] <nigelb> ^ speak of the devil :P
[23:54] <popey> AIUI
[23:54] <pleia2> the thread is on the classrom list: https://lists.ubuntu.com/archives/ubuntu-classroom/2011-July/thread.html
[23:55] <popey> of course when i say 'at work'
[23:55] <popey> ahem
[23:55] <pleia2> we'll never switch to lernid exclusively
[23:55] <nigelb> popey: its now logged for your employer's viewing pleasure :P
[23:55] <pleia2> it's unreasonable for most attendees who use irc regularly
[23:55] <popey> nigelb: I am my employer
[23:55] <popey> :D
[23:55] <nigelb> drat
[23:56] <nigelb> pleia2: \o/
[23:56] <popey> anyone here running oneiric?
[23:56] <popey> is lightdm properly broken?
[23:56] <nigelb> <-- lucid
[23:56] <popey> smart man
[23:56]  * popey highlights nigelb as the clever one here
[23:57] <popey> right, I do believe it's bed time
[23:57] <popey> Good night all!
[23:57] <pleia2> night popey
[23:57] <nigelb> night popey!
[23:57] <rrnwexec> night alan