[01:05] <jelkner> kjcole: can you give me a call?
[01:05] <kjcole> Man, I'm beat.  Was out at the "State of Emergency" protest last night, for all the good it did.
[01:05] <kjcole> jelkner, at school right?
[01:05] <jelkner> yup
[01:07] <flint> god it is early...
[01:09] <spacey> morning
[01:10] <flint> JaneW, ogra, you folks back from lunch?
[01:11] <dholbach> flint: not lunched yet.
[01:11] <jelkner> Are we meeting this morning?
[01:11] <dholbach> ogra went out for a smoke
[01:12] <flint> well, I suppose we are...Jeff.
[01:12] <jelkner> I only have 15 more minutes, if we don't start soon, I'll miss it
[01:12] <flint> dholbach, of course, I should join him...
[01:12] <spacey> dholbach, how is it going there?
[01:13] <flint> jelkner, you could do a doc report and then go tame the screaming kids... :^)
[01:13] <dholbach> spacey: fine, apart from everybody being ill :)
[01:13] <jelkner> certainly
[01:13] <jelkner> kevin and i got together last sunday
[01:14] <jelkner> we have updated the wiki: https://wiki.ubuntu.com/EdubuntuDocumentation/EdubuntuCookbook
[01:14] <spacey> dholbach, oh:/ that sucks
[01:14] <flint> spacey, sorry about the sick part.  the flu?
[01:14] <spacey> flint, i'm not sick :p
[01:14] <dholbach> Yep.
[01:14] <flint> jelkner, strong opening, this is good stuff, what else?
[01:14] <jelkner> anyone interested in contributing to the cookbook, could choose their favorite "recipe" and write it up...
[01:15] <spacey> dholbach, contanmination sprint
[01:15] <spacey> :P
[01:15] <dholbach> gar! :)
[01:15] <jelkner> we will be meeting again next Sunday to outline which recipies we think are essential.
[01:15] <flint> spacey, atta boy! :^)
[01:15] <jelkner> that's it for our report.
[01:15] <jelkner> questions?
[01:15] <spacey> jelkner, where is a list of the recipies?
[01:16] <flint> I like what I see on  your web site Jeff.
[01:16] <jelkner> spacey: we will be working on that next sunday
[01:16] <jelkner> we don't have them yet
[01:16] <jelkner> next week we will
[01:16] <flint> Let me think of a softball question like they would ask Bush at a news conference...
[01:16] <spacey> jelkner, if you have a list of that, i might have time to write a few 
[01:17] <jelkner> spacey: great!
[01:17] <jelkner> ok, gotta run...
[01:18] <flint> ...that was painless...
[01:19] <JaneW> hello :/
[01:19] <flint> JaneW, you just missed jeff...
[01:19] <JaneW> yeah sorry
[01:20] <JaneW> we are at the DistroSprintDeathPlague
[01:20] <flint> he actually did a very coherant doc report...
[01:20] <flint> the what?
[01:20] <JaneW> I am on line so I'll scroll back and catch up
[01:20] <JaneW> well 9 of the 16 ppl here are down with a nasty bug
[01:20] <JaneW> the rest are waiting with bated breath to see if we are going to die too
[01:21] <sivang> JaneW: oh my god, waht seems to be the bug?
[01:21] <ogra> nobody has grown wings, so it might not be bird flu 
[01:21] <JaneW> sivang: fever, headache, vomitting, diarroea - you get the idea
[01:22] <JaneW> ogra: got time for a quick tech update?
[01:22] <ogra> hmpf ... 
[01:22] <JaneW> careful I can throw a danish at you ;)
[01:22] <ogra> you got that in the sprint update already ...
[01:22] <ogra> there is not much to add, i could copy and paste though
[01:22] <flint> ogra, did you enjoy the cigarette with coffee?
[01:23] <ogra> flint, which of the 10 i head already 
[01:23] <sivang> JaneW: lol
[01:23] <ogra> (smoking apparently prevents me from getting ill)
[01:23] <flint> the best times are smoking...
[01:24] <ogra> so tech update.... seeing that i get ltsp in shape with all the functions we need before feture freeze 
[01:24] <ogra> we found an evil bug with the system clock i should solve currently instead of chatting ... 
[01:24] <simira> JaneW: are you all right? And how come you speak Danish? Har du noen gang boet i Danmark?
[01:24] <JaneW> ogra: yeah cut and paste for those that didn;t read
[01:25] <ogra> seems we need ntpdate to run on the client and a ntp server on the ltsp server, else udev cant create devices if the hardware clock is jfar out of sync
[01:25] <jsgotangco> edubuntu meeting?
[01:25] <sivang> jsgotangco: seems so :)
[01:25] <JaneW> simira: I am ok I think , feeling a bit spaced out though. I mean a Danish PASTRY though
[01:25] <simira> hehe, ok
[01:25] <ogra> * LTSP work included sanitizing all the LTSP breakage which occurred due
[01:25] <ogra> to changes in the underlying Dapper architecture - this is now fixed and
[01:25] <ogra> running again.
[01:25] <ogra> * Work was done on Xauthority handling on LTSP to allow secure
[01:25] <ogra> authentication of thin clients to the Edubuntu server.
[01:25] <ogra> * Thin Client Low Memory Usage:  netboot mode in initramfs tools added
[01:25] <ogra> and integrated to LTSP - still to be tested and uploaded.
[01:25] <ogra> * Reverted the change of the SIaddr that breaks the LTSP booting with
[01:26] <jsgotangco> oh great i got to attend one again =)
[01:26] <ogra> DHCPD. This prevents breakage on upgrades of LTSP set-ups.
[01:26] <JaneW> jsgotangco: :) wb
[01:26] <ogra> but currently that time bug has the highes prio, since i need to work with the people that are left before they also fall dead
[01:27] <flint> from sprint to sick bed :^)
[01:27] <jsgotangco> ogra, how is amd64?
[01:27] <ogra> jsgotangco, works fine 
[01:28] <ogra> i havent gotten around to set the default chroot creation in the installer to i386 yet 
[01:28] <ogra> which i think makes sense ... but i dnot know if its possible to do for just oine arch
[01:29] <JaneW> who is in charge of edubuntu documentation for dapper, over and above the cookbook? jsgotangco ?
[01:29] <ogra> jsgotangco, wait some days before testing, currently the ltsp client is broken ... the next uploads will fix this
[01:29] <ogra> JaneW, still jelkner and kjcole 
[01:29] <flint> JaneW, what jeff reported on is: https://wiki.ubuntu.com/EdubuntuDocumentation/EdubuntuCookbook it is a start.
[01:29] <jsgotangco> JaneW, what needs to be updated? i still have my olld sources
[01:30] <ogra> jsgotangco, probably the mizilla page ...
[01:30] <jsgotangco> JaneW, as for cookbook, i have no relationship to it for dapper
[01:30] <ogra> *mozilla
[01:30] <jsgotangco> ok
[01:30] <jsgotangco> we made a shorter one
[01:30] <jsgotangco> i'll update
[01:30] <JaneW> Let me rephrase... who is in charge of edubuntu documentation for dapper, other than the cookbook? 
[01:30] <JaneW> about edubuntu and release notes etc
[01:30] <jsgotangco> i can only think of releasenotes and about
[01:31] <JaneW> ditto
[01:31] <jsgotangco> i'll take charge of that then
[01:31] <spacey> if there are several parts of documentation that are missing out, i don't might writing it up
[01:31] <JaneW> jsgotangco: cool thanks, will you have time?
[01:31] <jsgotangco> JaneW, yes
[01:31] <JaneW> jsgotangco: have you worked with that pdf guy yet?
[01:31] <JaneW> spacey, great thanks please co-ord with jsgotangco 
[01:31] <jsgotangco> JaneW, he hasn't been communicating, i'll bug him
[01:31] <JaneW> jsgotangco: hmmm...
[01:32] <jsgotangco> JaneW, its a bit too late for dapper, but we can make a plan for it
[01:32] <jsgotangco> DITA is the future
[01:32] <flint> JaneW, is the plan that all docs be in pdf?
[01:33] <flint> JaneW, outside of the cookbook I mean.
[01:33] <JaneW> flint: I am not clear on the plan jsgotangco would know more
[01:33] <jsgotangco> flint, this is more of a toolchain project rather than edubuntu specific
[01:34] <flint> JaneW, you asked about the "pdf guy"  what a great name! :^)
[01:34] <flint> gotcha Jane
[01:34] <JaneW> well his name is Mark Johnson, know that I think about it
[01:35] <flint> jsgotangco, I am slow, what is DITA?
[01:35] <flint> JaneW, I think he should change his name... Mark Johnson is pretty plain.  chicks dig "the pdf guy"...
[01:36] <JaneW> flint: agreed
[01:36] <flint> orga would the brower in edubuntu default to the doc pages?
[01:37] <ogra> flint, it will default to the about page
[01:37] <ogra> (which might contain links to the docs)
[01:37] <jsgotangco> flint, Darwin Information Typing Architecture
[01:37] <flint> indeed... the about page could be customized to link to these very docs...
[01:37] <jsgotangco> (DITA XML)
[01:38] <flint> jsgotangco, thank you, a morning without a new acronym is like a morning without coffee...like this morning...argh!
[01:39] <flint> jsgotangco, the trick with the docs is how to get the average install to read them.  when I installed, the first thing I did was click on that silly fox.
[01:39] <flint> JaneW, I LIKE the fox :^)
[01:40] <JaneW> ok any more edubuntu business?
[01:40] <JaneW> highvoltage: ?
[01:40] <flint> anyway ollie how hard set is the html for that page?
[01:40] <JaneW> you said you wanted to discuss web stuff today?
[01:41] <JaneW> also I have been chatting with hno73 and he supports the idea of MOIN for edubuntu website
[01:41] <JaneW> mhz around?
[01:42] <jsgotangco> cool
[01:42] <highvoltage> sorry, i'm here, but i'm also not
[01:43] <highvoltage> JaneW: hi
[01:44] <flint> hi jonathan!
[01:44] <highvoltage> hi mr flint!
[01:44] <highvoltage> flint: how's the cookbook?
[01:45] <flint> there is progress: https://wiki.ubuntu.com/EdubuntuDocumentation/EdubuntuCookbook 
[01:45] <flint> highvoltage, it is far from being hot and on the table :^)
[01:46] <flint> I would say they are cutting up the carrots and looking for the soup pot.
[01:46] <highvoltage> :)
[01:46] <flint> I personally have found the sherry :^)
[01:46] <JaneW> highvoltage: Henrik supports the idea of using MOIN instead of drupal for the site...
[01:47] <highvoltage> JaneW: i'm actually very ambivilant between the two, both are good.
[01:47] <highvoltage> flint: yes, thank you!
[01:47] <JaneW> highvoltage: the ubuntu site is moin now and it looks good
[01:47] <flint> JaneW, I have to go and check EVERY TIME, but you are welcome!!!
[01:47] <JaneW> highvoltage: it may make sense to standardise, and unify to a degree
[01:48] <highvoltage> it's less work too :)
[01:48] <highvoltage> it's just philip who feels really, really strong that it should be drupal
[01:48] <flint> JaneW, in this case I really feel that it is not about the tool.  lets get something out there and deal tools on the back end.
[01:48] <highvoltage> and he had lots of ideas which he says depends more or less on it.
[01:48] <highvoltage> but i'm sure you could get those tools in moin with some work too
[01:50] <flint> highvoltage, Jonathan I just think of the text processing fun one could have cross converting between all these damn tools (choy curl :^)
[01:50] <flint> I meant "holy curl"
[01:50] <highvoltage> yes, there's that too
[01:51] <jsgotangco> ok i've seeded initial Edubuntu 6.04 docs (not cookbook) in svn
[01:51] <flint> I have played with moin and drupal, and a few others.  all can handle content.  as we say in cookbook land, "where is the beef?"
[01:51] <ogra> great 
[01:52] <JaneW> highvoltage: how involved is phillip now?
[01:52] <JaneW> flint: look at www.ubuntu.com - like what you see? = moin
[01:52] <flint> jsgotangco, for the svn crippled, how do I get to them?  we take this offline?
[01:52] <highvoltage> JaneW: he's gone a bit quiet, i think mainly because of the drupal stuff, i think he likes workign with drupal a lot, somehow
[01:53] <highvoltage> if we stick with moin, i can at least get the translators going on the web content.
[01:53] <highvoltage> there's about 7 people wanting to translate the edubuntu site into different languages.
[01:53] <jsgotangco> flint, you grab it via svn but its in docbook source...i'll give you the link later
[01:53] <highvoltage> (each a different one)
[01:53] <flint> JaneW, no need to sell any tool... all I know is that I have to register again and again because none of the tools allow cross passwords!
[01:53] <sivang> JaneW: you mean, wiki.ubuntu.com ?
[01:54] <JaneW> sivang: both
[01:54] <sivang> JaneW: AFAIK this is Plone at the front
[01:54] <ogra> we dont use plone since breezy anymore
[01:54] <sivang> ah , I didn't know plone was moved out from the main site.
[01:54] <JaneW> sivang: no it's not, it was migrated, it's moin now
[01:54] <ogra> thats why plone is in universe ;)
[01:54] <sivang> ogra: heh
[01:55] <jsgotangco> its moin, we've been doing in the OpenCD project too
[01:55] <jsgotangco> the tabs are moin
[01:57] <flint> JaneW, I do know you are hell on wheels with the moin meta-language for links and etc... :^)
[01:58] <JaneW> well Hendrik made a helpful help page with tips as well, so I can learn more now
[01:58] <JaneW> highvoltage: anyway think about it, but it's your call in the end, I just rem there were security concerns about drupal.
[01:58] <JaneW> jsgotangco: indeed
[01:58] <flint> ogra, my remaining question is how hard set is the "about page"?
[01:59] <JaneW> pity mhz is not here, he touts moin every chance he gets
[01:59] <ogra> flint, its the default page, it gets set by the artwork page
[01:59] <ogra> s/page/package/
[01:59] <flint> JaneW, the default page of the browser is where the results of our document labor end up.
[02:00] <flint> na it gets set up in the profile thingy in firefox...
[02:00] <ogra> firefox can only point to one page that is the same location for ubuntu, edubuntu and kubuntu ...
[02:00] <ogra> the different artwork packages replace this file ...
[02:00] <flint> it is not a url at first ollie it is a file
[02:00] <ogra> its a file:/// url
[02:00] <flint> ok gotcha... 
[02:00] <jsgotangco> flint, we'd like to put it on docfreeze too to open up for translations (that's why we'd love to do xml)
[02:01] <ogra> flint, which is hardcoded in firefox
[02:01] <flint> ogra, am I more nuts than usual to want to find the docs when I open the browser?
[02:02] <ogra> flint, as i said, there should be no probelm to add links to that page 
[02:02] <jsgotangco> flint, do you want to add the cookbook in the distro?
[02:02] <ogra> (Unote that file:/// can also be a link)
[02:02] <flint> ogra, there is not enough space on the CD for the cookbook.
[02:02] <ogra> jsgotangco, i doubt that will be ready in time for being packaged in dapper
[02:02] <jsgotangco> i agree
[02:03] <flint> ogra, I think the docs that Jsgotangco is cooking could open as links on the default browser page
[02:03] <ogra> flint, i'd love to drop all KDE stuff to make space available ;)
[02:03] <ogra> (but we're lacking replacements yet)
[02:03] <flint> ogra, that was harsh....
[02:04] <ogra> flint, it takes a huge amount of space to hold all the dependencys for kdeedu on the cd
[02:04] <jsgotangco> yeah
[02:04] <flint> that kevin, he was there all the time!
[02:05] <flint> anyway, I gotta get coffee.  excellent conspiracy this morning.  Thanks!!!!
[02:05] <flint> sksk
[02:05] <JaneW> sorry that was a bit disjointed folks
[02:06] <JaneW> we are multitasking here and a bit disease infected.
[02:06] <JaneW> thanks for the cook book work and updates
[02:06] <JaneW> same time, same place next week, and hopefully we'll have good progress by then :)
[02:06] <JaneW> I may have some exciting news to share then too.
[02:07] <jsgotangco> i still havent seen any cookbook source :/
[02:11] <highvoltage> JaneW: if majority is happy with moin, then so am i
[02:11] <JaneW> it's lunch time - over and out
[02:12] <highvoltage> btw
[02:12] <highvoltage> here's a very, very early version of the troubleshooter i talked about at the summit:
[02:12] <highvoltage> http://jonathancarter.co.za/projects/xola/index.py
[02:13] <highvoltage> it's layout is awkward and it's still very strange, but it should give you a vague idea of where it might be going to
[02:15] <jsgotangco> wow
[02:16] <jsgotangco> that is so cool
[02:16] <highvoltage> thanks :)
[02:17] <highvoltage> long term goal is to have a nice wiki-style editor for all the options, so that the help desk of who-ever is deploying the installations can easily edit the entire thing.
[02:17] <jsgotangco> yes that would be really cool
[02:17] <jsgotangco> hrmmm
[02:17] <jsgotangco> this could be great to adapt for ubuntu itself
[02:17] <jsgotangco> make it a wee bit smaller i guess
[02:17] <highvoltage> yeah.
[02:17] <jsgotangco> wonder if this can run off yelp
[02:18] <highvoltage> it's probably going to become smaller anyway, those penguins are expensive on screen space.
[02:18] <jsgotangco> do you want to try this out on Yelp?
[02:19] <highvoltage> i would if i had the time, i think mdke suggested the same
[02:19] <highvoltage> thign
[02:19] <highvoltage> how would this work with yelp?
[02:19] <jsgotangco> yelp can render html
[02:19] <jsgotangco> but that's static
[02:19] <jsgotangco> this is a python script
[02:19] <jsgotangco> hrmm
[02:21] <highvoltage> this python script is still very static
[02:21] <highvoltage> i plan to have the data in a sqlite database later on
[02:21] <jsgotangco> hmm can i take a peek?
[02:21] <jsgotangco> i can try it over the weekend
[02:21] <highvoltage> of course, don't expect much though
[02:22] <jsgotangco> its ok
[02:22] <highvoltage> can i tar it up and e-mail it to you?
[02:22] <jsgotangco> yes thanks
[02:22] <highvoltage> it's less than 800k, including images
[02:22] <jsgotangco> alright
[02:22] <highvoltage> jgotangco@ubuntu.com?
[02:22] <jsgotangco> yeah
[08:59] <zul> hi
[08:59] <lucasd> hello
[09:00] <sistpoty> hi everyone
[09:00] <lucas> hi all
[09:00] <lucas> seems like many MOTU are missing
[09:00] <sistpoty> :(
[09:00] <lfittl> hi all
[09:00] <sistpoty> ok, welcome to the meeting
[09:01] <sistpoty> please state your names for the minutes
[09:01] <zul> ChuckShort
[09:01] <sivang> hi all, I will watch not sure will stay to end
[09:01] <lucas> I added most (all?) of the points on https://wiki.ubuntu.com/MOTU/Meetings . All points are just discussion points, so I think we should proceed with the meeting even if not everybody is here
[09:02] <sistpoty> yes
[09:02] <sistpoty> first of all, anybody willing to do the minutes for this meeting?
[09:02] <lucas> sistpoty: I can do them if you want
[09:02] <zyga> hello
[09:02] <sistpoty> cool, great 
[09:03] <sistpoty> ok, let's move to the first point... lucas go ahead plz 
[09:03] <lucas> ok
[09:03] <lucas> I'm just looking for feedback about https://wiki.ubuntu.com/MultiDistroTools
[09:03] <lucas> (which generates http://tiber.tauware.de/~lucas/versions/ )
[09:03] <lucas> are people using it ? what's missing ? etc
[09:04] <lucas> are there some MOTU teams who would like some more specific reports (like the ruby one) ?
[09:04] <zyga> lucas: I'm not using it (I didn't knew about it) but it's a good idea IMHO
[09:05] <sistpoty> hm... iirc the science team wanted s.th. like it. but I don't remember if it was raphing or laserjock who wanted to start a branch from it
[09:05] <lucas> laserjock
[09:05] <lucas> he started something
[09:06] <lucas> anyone else ? ;)
[09:06] <sistpoty> lucas: can you split the list somehow? 
[09:06] <lucas> based on what ?
[09:06] <sistpoty> lucas: the whole list is 1.7Mb which is quite big... 
[09:06] <lucas> that's why I'm proposing to generate smaller reports
[09:06] <sistpoty> lucas: not quite sure what would be reasonable... maybe alphabet or sections or s.th. else
[09:07] <lucas> with only a specific set of packages
[09:07] <sistpoty> lucas: yes... but just as addon ;)
[09:07] <lucas> mmh, I could generate one with only packages outdated in ubuntu
[09:07] <lucas> since it's probably the most interesting part
[09:07] <sistpoty> that would be great :)
[09:08] <lucas> ok
[09:08] <sistpoty> apart from that I also think it's pretty feature complete. good work!
[09:08] <lfittl> lucas: outdated in debian and not in debian should also get their own page
[09:09] <lucas> ok
[09:09] <lucas> I recently discovered that data from the Debian PTS was available on http://qa.debian.org/data/ddpo/results/
[09:09] <lfittl> apart from that, well done :)
[09:09] <lucas> I'll try to integrate some of it (like the bug numbers)
[09:09] <sistpoty> cool :)
[09:10] <lucas> ok
[09:10] <lucas> next point ?
[09:10] <sistpoty> yes, move on
[09:10] <lucas> https://wiki.ubuntu.com/DCT
[09:10] <lucas> Debian Collaboration Team
[09:10] <lucas> question: what do you think ?
[09:12] <lfittl> lucas: I would be interested to help with this, although I am no MOTU yet..
[09:13] <lucas> no problem: if you have some experience with packaging/bug reporting etc, it's ok
[09:13] <sistpoty> hm... I remember bits of the discussion when utnubu was founded, which resulted iirc that it is better to directly contact the debian maintainer...
[09:13] <lucas> sistpoty: some people don't do it
[09:13] <sistpoty> yes, which is not really good imo
[09:13] <zyga> lucas: I comment if I may
[09:13] <lfittl> lucas: k, perfect, let's talk about this after the meeting
[09:14] <lucas> well, I don't think we can force ubuntu devs to report bugs to Debian
[09:14] <lucas> also, DCT would be a way to put some pressure on Debian maintainers
[09:14] <sistpoty> but having the DCT to give back the changes might lead to the idea "oh we have DCT to report back changes why should I do it then?", which should be avoided
[09:14] <zyga> lucas: DCT is good as a team of people comitted to their work that get notified by regular developers to do some work and keep track of this 
[09:14] <lucas> by forcing them to deal with bugs promptly
[09:15] <sistpoty> but generally I think DCT is a good idea
[09:15] <lucas> ok
[09:15] <lucas> any other comments
[09:15] <lucas> ?
[09:16] <siretart> re
[09:16] <siretart> sorry for being late
[09:16] <sistpoty> my proposal would be: just go ahead and try it out and see how it works out
[09:16] <sistpoty> hi siretart
[09:16] <lucas> ok
[09:16] <lucas> anybody else interested in helping ?
[09:16] <siretart> dct
[09:16] <siretart> I made some thoughts about this
[09:16] <lucas> ah
[09:16] <lucas> go ahead :)
[09:16] <siretart> to be honest, I'm a bit sceptical
[09:17] <siretart> because I don't really see the point in that project
[09:17] <siretart> I mean, the members are basically commiting to submitting patches and doing work vice versa
[09:17] <siretart> did I get this right?
[09:18] <lucas> siretart: the problem is that in theory, members should submit patches upstream
[09:18] <lucas> however, there are many changes which should be reported in Debian but aren't
[09:18] <siretart> lucas: right. 
[09:19] <lucas> if there's a CC or TB decision saying that it's WRONG not to report changes upstream, DCT isn't needed
[09:19] <siretart> lucas: I think a team like the DCT should rather focus on making proposal how collaboration could be improved, and give recommendations on how that goal can be achieved
[09:19] <lucas> (I would prefer such a decision)
[09:20] <siretart> I think some people overrate the tb. it gives decisions on technical problems. this is partly a technical problem
[09:20] <lucas> maybe CC would be best suited
[09:20] <siretart> I don't think the tb nor the CC can change the way people think, or tell them how to work
[09:21] <lucas> in some way, it can
[09:21] <lucas> it could say : if have to do that
[09:21] <lucas> s/if/you
[09:22] <siretart> lucas: I don't say the DCT is a bad idea. it may be quite possible that I didn't get the idea right
[09:22] <sistpoty> lucas: did you get feedback from debian so far about DCT?
[09:22] <lucas> I haven't really announced it to Debian
[09:22] <lucas> only utnubu
[09:23] <lucas> siretart: no offense taken :-)
[09:23] <siretart> lucas: I have the impression that, given to the very few responses yet, most people fear that working on the DCT mean going through endless lists of patches, writing emails to people who are likely to not even notice that
[09:23] <siretart> and this is what makes me very sceptical
[09:24] <lucas> "going through endless lists of patches" <= probably
[09:24] <Kyral> meh I'm late
[09:24] <lucas> "writing emails to people who are likely to not even notice that" <= no, because it's a win-win solution
[09:24] <lucas> the debian maintainer HAS to care
[09:24] <lucas> or we are just going to stop working with him
[09:24] <siretart> I'd rather like to see the DCT to be a forum which makes recommendations on how collaboration can be improved
[09:24] <lucas> there's already utnubu for this, I think
[09:25] <siretart> but thats just my personal opinion. you asked for comments ;)
[09:25] <sistpoty> oh, one thing I just found in the DCT wiki-page: "Provide better (more verbose) changelog entries" 
[09:25] <sistpoty> ^^ this is not only good for debian collaboration, but also for team maintenance, so PLEASE DO! ;)
[09:25] <siretart> sistpoty: yeah. but I don't expect the DCT to fix my changelogs
[09:26] <siretart> sistpoty: I could imagine that the DCT could make some charts about 'worst merging changelogs ever' ;)
[09:26] <lucas> siretart: this is in the list of things you can do to help as a DCT outsider
[09:26] <sistpoty> siretart: he, no I wanted to tell this to every motu, esp. hopefuls ;)
[09:27] <siretart> sistpoty: right. but regular uploaders (me included) also write bad/confusing changelog entries
[09:27] <siretart> I need to improve
[09:27] <lucas> from my minutes:
[09:27] <lucas> Several people mentionned that Ubuntu devs should already send patches and report bugs upstream. However, it's often not the case, especially for MOTUs who deal with a lot of packages. It would be great to have an official position : is it considered "OK" or "WRONG" for Ubuntu developers to forget to report worthy changes to the Debian BTS ?
[09:28] <lucas> we all agree on that ?
[09:28] <lucas> (it's a bit hard for me to write the minutes since I'm obviously biaised)
[09:28] <ajmitch> morning, sorry I'm late :)
[09:28] <sistpoty> hi ajmitch
[09:29] <siretart> lucas: what are you asking. is it reasonable to send patches or if it was reasonable to define guidelines how to do merges?
[09:30] <lucas> siretart: I'm asking whether ubuntu devs are "supposed" to submit patches to the BTS.
[09:30] <lucas> or if it's OK not to do it.
[09:30] <sistpoty> lucas: I don't think we need an official statement for that, since it's already there (at least somewhere in the wiki), that it is considered good practice to forward patches
[09:30] <lucas> sistpoty: yeah, but is it considered bad practice not to ? :-)
[09:31] <siretart> good point
[09:31] <sistpoty> lucas: not directly, but indirectly ;)
[09:32] <sistpoty> what might also be good would be some school-lesson on how to use BTS and submit patches back to debian, what do you think?
[09:32] <lucas> it's already quite well documented on the wiki
[09:32] <siretart> ajmitch: did you manage to catch up the backlog? I'd like to hear the opinion from someone with a Debian hat on
[09:32] <lucas> I'm not sure it's necessary
[09:32] <siretart> lucas: which page are you reffering to?
[09:32] <lucas> mmh :)
[09:33] <siretart> sistpoty: I think this is an excellent topic for a lesson!
[09:33] <sistpoty> well, sometimes it's better to take ppl. by the hand ;)
[09:33] <lucas> https://wiki.ubuntu.com/Bugs/Debian
[09:33] <siretart> yes. espc. on important things. I consider this really important, if we don't want to fail badly
[09:33] <lucas> https://wiki.ubuntu.com/ContributingToDebian
[09:35] <siretart> lucas: ok, these pages you are reffering to. Yeah, I also think they are a good start, but they could also have some more polishing, updating, and better integration
[09:36] <siretart> short: I'm not that happy with them, but not that unhappy to change them immediately 
[09:36] <lucas> ok
[09:36] <siretart> lucas: this could be imo another topic of a DCT session, btw
[09:36] <lucas> ajmitch: you catched up ? (/me is also interested by your POV)
[09:37] <siretart> any DD around by chance?
[09:38] <ajmitch> sigh
[09:39] <ajmitch> I'd really like to see more MOTUs filing patches & bugs
[09:39] <ajmitch> and I really have to do more of it myself :)
[09:39] <siretart> lucas: what do you think about semi regular DCT meetings?
[09:40] <lucas> you mean meetings to discuss collaboration with debian ?
[09:40] <ajmitch> it depends no what the DCT is going to be
[09:40] <siretart> or sessions, if they are focused on a specific topic
[09:40] <lucas> ah, yes
[09:40] <lucas> ok
[09:40] <ajmitch> whether it's a small group of MOTUs & willing DDs
[09:41] <ajmitch> the comment about 'putting pressure on DDs' is something I don't like so much
[09:41] <siretart> because I don't think this MOTU Meeting is the right place for a lenghty discussion about what the DCT should do and not
[09:41] <siretart> right
[09:41] <lucas> ok
[09:41] <ajmitch> especially with so few of us here today
[09:41] <siretart> we don't really want to force anywany. at least, nobody should be
[09:42] <ajmitch> even at mark's keynote at LCA there were questiosn about those MOTUs
[09:42] <siretart> ajmitch: what was the question? and what the answer?
[09:43] <ajmitch> siretart: the problem is that I can't recall just what was asked - I think it was about motus packaging new stuff & diverging from debian
[09:43] <siretart> i see
[09:43] <ajmitch> hopefully the video will be out soon :)
[09:43] <sistpoty> ok, lucas: how about you just announce a date/time for a DCT meeting to discuss this more in depth?
[09:43] <lucas> ok, I'll think about it
[09:43] <lucas> when the minutes will be ready
[09:44] <ajmitch> lucas: have you announced the DCT on the motu mailing list?
[09:44] <lucas> I'll ask mark to comment on the "good practice / bad practice" problem
[09:44] <lucas> ajmitch: yup
[09:44] <ajmitch> but I'd already known of the existence of it by then
[09:44] <lucas> are some of you willing to get more involved in DCT ?
[09:44] <ajmitch> lucas: btw it got a mention at LCA in lathiat's debian/ubuntu talk ;)
[09:44] <ajmitch> lucas: sure
[09:44] <lucas> hehe
[09:45] <lucas> currently, DCT is only a spec ;)
[09:45] <ajmitch> and this was before you announced it
[09:45] <ajmitch> I know
[09:45] <sistpoty> lucas: not right now, since I'm hellish short of time :(... perhaps in one/two month ;)
[09:45] <ajmitch> we announced it as such
[09:45] <lucas> ok
[09:45] <siretart> I think another problem is what be expected from MOTUs
[09:45] <lucas> nobody is obliged
[09:45] <tseng> stupid question
[09:45] <tseng> what is the difference between joining utnubu and dct
[09:46] <ajmitch> utnubu is on the debian side
[09:46] <ajmitch> so not much
[09:46] <tseng> "and?"
[09:46] <lucas> utnubu is about pulling, DCT about pushing
[09:46] <siretart> I mean, given that someone (or team) gives some guidelines. what would be an acceptable scope of what to do and what not to do for such a document
[09:46] <ajmitch> I wouldn't care too much which group I was officially with
[09:46] <lucas> currently, utnubu hasn't achieved much
[09:46] <ajmitch> as long as stuff was being done
[09:46] <lucas> and seems to be working on getting new packages from ubuntu to debian
[09:46] <tseng> i see no difference outside of a name
[09:47] <tseng> not to throw a fork in forward progress, just curious
[09:47] <tseng> carry on
[09:47] <lucas> tseng: utnubu is about helping with DM power (ie you mostly need to be a DD to be helpful in utnubu)
[09:48] <sistpoty> ok, do we want to move to the next item?
[09:48] <siretart> sistpoty++
[09:48] <lucas> DCT is helping from Ubuntu (you need to be familiar with Ubuntu dev to help in DCT)
[09:48] <lucas> ok
[09:48] <lucas> Status of MoM (lucas). During the last ?TechnicalBoard meeting, the status of MoM was discussed. It often can't find the correct base version because the morgue (repository of old packages) it is using went out of disk space. Should we set up our own morgue to make the merging process more efficient ? It would require at most 13(n+1) GB, n being the number of Ubuntu releases we want to support, and a few hours of coding.
[09:48] <ajmitch> it's been discussed at the TB
[09:49] <ajmitch> and it's not really something we can do - we can't retrieve those old package that are list
[09:49] <ajmitch> s/list/lost/
[09:49] <lucas> yeah, but we could start working on our own morgue to improve the future
[09:49] <siretart> well, we have about 80gb of free space on tiber, currently, which we can use as interim solution
[09:49] <siretart> I think this is the question, is it?
[09:50] <ajmitch> why should we have to duplicate what *should* be working for the whole distro but isn't yet?
[09:50] <siretart> ajmitch: obviously, there is not much interest in reviving the 'real' morgue
[09:50] <lucas> ajmitch: scott's tools are closed source
[09:50] <lucas> also, the way it's currently working is not satisfying
[09:50] <ajmitch> siretart: no, but some changes may come from the move to soyuz
[09:50] <lucas> it fetches packages from a debian morgue which stores everything
[09:51] <lucas> so it goes out of space from time to time
[09:51] <siretart> ajmitch: yes. but soyuz is.. well, not there yet.
[09:51] <ajmitch> siretart: within days, they say ;)
[09:51] <siretart> ajmitch: since hoary release. I know :/
[09:51] <ajmitch> lucas: I think it's run out of space once
[09:51] <lucas> yeah, but since it stores everything
[09:52] <lucas> it's supposed to run out of space on a regular basis ;)
[09:52] <sistpoty> I guess what's more important is that we know ahead of time how the next merges can be handled (will bugs be filed etc.)
[09:52] <siretart> so it SHOULD just be putting in a bigger disk. which didn't happen since a LOOONG time
[09:52] <lucas> also, they might decide to expire packages which we would like to keep
[09:52] <lucas> and keep some which are useless
[09:53] <sistpoty> just curious: how important do you consider the MoM-report for doing merges? (I rarely used them for this merge-phase)
[09:53] <siretart> lucas: so, what are you basically proposing to improve the situation?
[09:53] <lucas> siretart: build our own morgue, but keeping only the packages which matters to us
[09:54] <lucas> sistpoty: mom reports isn't really helpful
[09:54] <lucas> but having the common base package is
[09:54] <siretart> sistpoty: I have a very mixed feeling. it depends on the package. In general, I think a manual review of the debdiff to the latest debian package before uploading is a must. I've seen a lot of packages whose uploader obviously didn't do that :/
[09:54] <siretart> s/a lot of/some/ (well, in fact, 2 packages where I noticed that problem)
[09:55] <ajmitch> siretart: that's not the fault of the MoM reports
[09:55] <lucas> example of package with the problem : http://people.ubuntu.com/~scott/ongoing-merge/xscreensaver/REPORT
[09:56] <lucas> the base version should be 4.23-2
[09:56] <siretart> ajmitch: right. but I think the MoM report mislead/seduce developers to that :(
[09:56] <lucas> but we only have the diffs against 4.23-1
[09:56] <ajmitch> lucas: guess what
[09:56] <ajmitch> setting up yet another tool won't fix that
[09:56] <siretart> right
[09:56] <lucas> ajmitch: it depends on the tool.
[09:56] <lucas> the problem with debian's morgue is that it attemps to keep everything
[09:57] <siretart> lucas: not if it is not going to be used by Keybuks MoM script
[09:57] <ajmitch> and we don't have access to the debian morgue
[09:57] <ajmitch> so we only have the incomplete set of packages on snapshot.d.n
[09:57] <siretart> I think lucas refers to snapshot.debian.net
[09:57] <sistpoty> ajmitch: we could mirror incoming and build a morgue from there with some tricks
[09:57] <ajmitch> the debian morgue is separate
[09:58] <ajmitch> it was referred to in the TB meeting
[09:58] <siretart> ajmitch: debian has an morgue on its own?
[09:58] <lucas> ajmitch: that's why we should start working on a tool ASAP so we get a lot of "common base packages" when we start working on merges
[09:58] <lucas> siretart: yes, but it ran out of space in november
[09:58] <siretart> lucas: a tool to do what excatly?
[09:58] <lucas> fetch source packages on a regular basis, and remove those that we won't need
[09:58] <ajmitch> to store the 4th copy of packages?
[09:59] <siretart> lucas: I don't really get the point
[09:59] <lucas> siretart: the point is: we need to be able to fetch the base version when we need it
[09:59] <lucas> currently, it's often lost
[10:00] <lucas> ajmitch: 30GB of disk space isn't really expensive
[10:00] <siretart> lucas: this means debian packages only, right?
[10:00] <sistpoty> I'm still not 100% convinced what the win is from having the base version
[10:00] <lucas> sistpoty: how do you usually know what changed ?
[10:00] <siretart> I think s.d.n and ftp.d.o is sufficient. we have more important things to do
[10:00] <sistpoty> lucas: from the changelog
[10:00] <ajmitch> 'often lost' - the main reason is the single occurrence of a disk failure that rendered the RAID array on snapshot.s.n bad
[10:01] <lucas> ajmitch: and the debian morgue ran out of space
[10:01] <siretart> which debian morgue are you reffering to? s.d.n?
[10:01] <ajmitch> and I don't know if we even use that, as it's on a restricted host
[10:01] <lucas> the debian ftpmaster has their own morgue
[10:02] <lucas> ajmitch: Keybuk and Kamion said we used it
[10:02] <lucas> I'd like to work on this. siretart, can get take 30 to 40 GB of disk space on tiber for this ?
[10:03] <lucas> s/can get take/can I take/
[10:03] <sistpoty> well, from the viewpoint of a tiber-admin, I don't really object to having a separate morgue, as long as a reasonable amount of disk space will still be reserved and it won't produce too much cpu-load
[10:04] <siretart> I'm sceptical in doing that on tiber. tiber was not donated for this, and I don't really see the profit we gain from this
[10:04] <lucas> ok
[10:05] <lucas> I'll reexplain in a mail to ubuntu-motu
[10:05] <siretart> I see additional load and additional traffic caused from this
[10:05] <siretart> yes, that would be great
[10:05] <lucas> so we can discuss this on the mailing list
[10:06] <sistpoty> ok, next item?
[10:06] <siretart> lucas: I'd suggest explaining that on the mailing list, and write a summary on the wiki page. then we can decide in another meeting
[10:06] <siretart> next iteam
[10:06] <siretart> backups of tiber.tauware.de (lucas). Some people are hosting bzr repositories on tiber. It would be quite a shame if they were lost. Are there some plans to setup some off-site backups of tiber ?
[10:06] <siretart> well, this is a status report
[10:06] <siretart> I've just did a tarball of /etc /srv and /home, and copied it to my private vserver in germany
[10:07] <siretart> I have to talk to my hoster, if he is willing to backup this tarball for me before I do this in a cron job
[10:07] <lucas> couldn't canonical backup tiber ?
[10:08] <siretart> the tarball is currently about 1 gig.
[10:08] <lucas> (don't they have a backup system ?)
[10:08] <lucas> oh, this is quite small
[10:08] <tseng> 1gb isnt quite small if you want to have daily/weekly backups forever
[10:08] <siretart> lucas: tiber is not in the DC of canonical
[10:09] <siretart> lucas: it is rented by canonical at serverpronto.com
[10:09] <siretart> last time I looked, they didn't offer free backups, I think
[10:09] <lucas> siretart: it doesn't mean they can't do backups
[10:09] <lucas> tseng: tarballs are very inefficient
[10:09] <lucas> you could you rsync based stuff
[10:09] <sistpoty> siretart: 1) do serverpronto offer a backup system? 2) are revu-uploads backup'd as well?
[10:09] <lucas> I use dirvish for backups for example
[10:10] <siretart> sistpoty: no, revu uploads are not backed up. 
[10:10] <ajmitch> siretart: rsync is preferable to a tarball every week
[10:10] <sistpoty> siretart: ah, good... otherwise we really needed to tidy these *g* (and fix the remove functionality)
[10:10] <ajmitch> well rdiff-backup is better still :)
[10:11] <lucas> ajmitch: yeah but I'm used to dirvish ;)
[10:11] <siretart> hm. if I read that correctly, serverpronto seem to offer 2gb ftp space for free..
[10:11] <siretart> mom phon
[10:11] <lucas> there are lots of good backup solutions
[10:11] <lucas> we don't need to use a custom-made one, especially involving FTP ;)
[10:12] <lucas> I know ubuntu-fr.org has bought several servers with some donations
[10:12] <lucas> I could ask whether they could donate some disk space for backups
[10:13] <siretart> lucas: let me talk to joerg, my hoster of tauware.de. I think he has no problems with putting those tarballs on tauware.de
[10:14] <siretart> lucas: tauware.de is on a raid and backupped daily
[10:14] <lucas> siretart: you should really do something else than tarballs
[10:14] <lucas> usually, with tarballs, you make a mistake, then the next cron job overwrites the last good tarball, and you lose everything
[10:14] <\sh> argl...
[10:15] <siretart> hi \sh 
[10:15] <sistpoty> hi \sh
[10:15] <siretart> :)
[10:15] <\sh> just forgot the meeting..damn...sorry
[10:15] <siretart> lucas: perhaps rsync snapshots would be better. Let me talk to joerg about this
[10:16] <lucas> rsync alone doesn't solve the problem
[10:16] <lucas> you have to keep a short history
[10:16] <lucas> (like 1, 3, 7, 14, days, 1 month)
[10:17] <ajmitch> otherwise what good is it if you suddenly have 0 byte files in /etc that get backed up & no replacement ;)
[10:17] <siretart> yes. you mean a decent rotation script
[10:17] <sistpoty> but I still would really appreciate if these snapshots are only done to prevent disk corruption. (so that nobody even thinks about "I accidentilly removed xyz, can you restore it plz?")
[10:18] <\sh> well....
[10:18] <siretart> sistpoty: we could setup a convinience rsnapshot locally for that
[10:18] <lucas> sistpoty: how often do you backup your desktop system ?
[10:18] <\sh> the bzr archives will go sometime onto the canonical bazaar server (hint HCT)
[10:18] <sistpoty> lucas: I don't, and had no real losses so far
[10:18] <\sh> and everybody should have local backups
[10:18] <lucas> sistpoty: you have been lucky so far
[10:19] <siretart> \sh: right. note the 'sometime', it is not there yet, and I don't expect that in near future
[10:19] <sistpoty> lucas: no, once the old hdd made noises I bought a new one (well, so I have *some* backup) *g*
[10:19] <ajmitch> siretart: bzr branches are already on launchpad
[10:19] <lucas> you never removed files by mistake ?
[10:19] <\sh> ajmitch: upstream archives..yes
[10:20] <\sh> ajmitch: but not distro specific
[10:20] <ajmitch> \sh: I mean just bzr branches, not the packaging stuff
[10:20] <siretart> ajmitch: how do you push changes to those branches on launchpad?
[10:21] <sistpoty> lucas: sure did I, but nothing really important (I tend to keep important stuff stored in several places)
[10:21] <ajmitch> siretart: ask #launchpad, I haven't tried :)
[10:21] <lucas> ajmitch: I don't think it works
[10:21] <\sh> siretart: you don't :) it's an automatic task :) the last time I asked because of gajim, it was even an manual task 
[10:22] <\sh> actually this bzr stuff is part of hct for the future.
[10:22] <ajmitch> \sh: we're mainly caring about bzr for scripts & tools at the moment
[10:22] <ajmitch> not hct
[10:22] <\sh> and to be honest...what do we need to backup from tiber? the only important stuff from my home e.g. are the bzr archives. which can be tarred
[10:22] <tseng> revu?
[10:23] <ajmitch> that's what we're talking about backing up..
[10:23] <\sh> revu can be tarred and dumped
[10:23] <lucas> we could live without backups
[10:23] <lucas> but I think it has to be clearly announced
[10:23] <sistpoty> well, it would be quite a loss if revu-uploads or the database with comments were lost
[10:24] <\sh> well..for ours sake we can do tarring and sql dumping revu etc. but we should not do it officially
[10:24] <sistpoty> as in much work lost
[10:24] <siretart> \sh: right. I intend to do weekly dumps of /etc, /srv, /home to my private place. the discussion is currently diverging a bit
[10:24] <\sh> siretart: I have space too and bandwidth...if you need something...please poke me :)
[10:25] <sistpoty> ok, anything else about backups?
[10:26] <lucas> I don't think so
[10:26] <siretart> \sh: oh. then lets talk about details later, okay?
[10:26] <sistpoty> ok, then a small point from me (which is not on the agenda): current motu work
[10:26] <\sh> siretart: k
[10:27] <sistpoty> well, what do we have? bugfixing, unmet deps and new packages...
[10:27] <sistpoty> I'm sorry, I didn't write anything to properly handle unmet deps yet... is someone actually working on unmet packages?
[10:28] <sistpoty> or on a tool to work on unmet deps?
[10:29] <sistpoty> ajmitch, siretart?
[10:29] <lucas> unmet build-dep or unmet Depends/Recommends ?
[10:29] <ajmitch> sistpoty: yes?
[10:29] <sistpoty> ajmitch: you once started on s.th. to find out packages with unmet deps? any progress?
[10:30] <sistpoty> lucas: unmet Depends/Recommends
[10:30] <siretart> sistpoty: sorry, I'm too busy right now
[10:30] <smurf> sistpoty: Just install everything, you'll notice which packages break. ;-)
[10:30] <sistpoty> hehe
[10:30] <siretart> sistpoty: I only have this for now http://tiber.tauware.de/~siretart/unmet/dapper-unmet.txt
[10:30] <ajmitch> sistpoty: no, I haven't done much on anything motu-related lately
[10:31] <lucas> a script to pick up unmet depends/recommends should be quite easy to write
[10:31] <siretart> this is the output from 'apt-cache -i unmet' on i386. I can easily create those for ppc and amd64 as well
[10:31] <sistpoty> ok, since I don't know when I'll have some generated list ready, what about using the wiki (once again) as an interim solution?
[10:31] <siretart> lucas: apt-cache -i unmet also reports about broken recommends
[10:31] <lucas> ok
[10:31] <siretart> the output is not very clear at all
[10:31] <siretart> ajmitch: didn't you say you managed to do something with britney?
[10:31] <ajmitch> siretart: yes
[10:31] <ajmitch> siretart: but it's not ready for general consumption
[10:31] <\sh> the problem with the last unmet deps run during breezy was that there was a misunderstanding
[10:32] <ajmitch> it may kill kittens when run, etc
[10:32] <siretart> ajmitch: does that output help more than http://tiber.tauware.de/~siretart/unmet/dapper-unmet.txt?
[10:32] <ajmitch> siretart: if I make it so
[10:32] <sistpoty> \sh: in what way?
[10:32] <siretart> \sh: what do you mean with 'unmet deps run'?
[10:32] <siretart> that list is generated daily
[10:33] <\sh> sistpoty: unmet deps means: "some of the deps a package tries to install is broken" but that a dep itself can be broken..so we need to make sure, to communicate that
[10:33] <\sh> siretart: breezy :)
[10:33] <ajmitch> \sh: that was what I was trying to do
[10:33] <\sh> ajmitch: cool :) I just wanted to mention that :) 
[10:33] <siretart> \sh: ah, thats britney
[10:33] <sistpoty> \sh: sure, we need to write that up ;)
[10:33] <lucas> how could a dep be broken ?
[10:34] <siretart> lucas: broken == not satifiable
[10:34] <lucas> ok and what's the other one then ? ;)
[10:34] <sistpoty> lucas: cannot be installable due to dep on the dep's package 
[10:34] <\sh> lucas: e.g. apt-get install bla -> bla deps on foo -> foo deps on fubac and fubac is ftbfs
[10:34] <\sh> so a rebuild doesn't work ... and fubac is not shown directly
[10:35] <siretart> lucas: try 'apt-get -s install zope3' on a current dapper system and see what happens
[10:35] <siretart> you will get this output:
[10:35] <siretart>   zope3: Depends: python2.4-mechanize (>= 0.0.10a) but it is not installable
[10:35] <ajmitch> siretart: yes, I filed a bug about that :P
[10:36] <sistpoty> ok, still the question: do we want to use the wiki to coordinate the work, unless we don't have another list-tool?
[10:36] <siretart> btw, I remember we had a zope team. who was that?
[10:36] <ajmitch> siretart: me
[10:36] <siretart> ajmitch: only you? - ooh
[10:36] <ajmitch> siretart: well doko as well, for stuff in main
[10:36] <siretart> I see
[10:36] <ajmitch> and herve when he's been around, which hasn't been often
[10:36] <siretart> oh, zope3 is in main. interesting
[10:36] <ajmitch> which is why I did those zope merges :)
[10:36] <ajmitch> yes
[10:37] <ajmitch> zope 2.x was in main for breezy, but has been demoted to universe
[10:37] <siretart> hm. I wanted to play around with zope anyway. hmmhmm
[10:37] <siretart> no not now :)
[10:37] <sistpoty> please, get back on topic ;)
[10:37] <ajmitch> siretart: it's not like I'm alone, since it's really the debian/ubuntu zope team ;)
[10:37] <ajmitch> sistpoty: this is on-topic ;)
[10:37] <sistpoty> hehe
[10:38] <lucas> regarding FTBFS packages
[10:38] <lucas> I have a script that pbuilds a list of packages and output the build logs in directories depending on the result
[10:38] <ajmitch> yes, that was done for breezy as well
[10:38] <lucas> (I ran it against ruby packages already)
[10:39] <\sh> well...
[10:39] <sistpoty> we had test-builds from the buildds for breezy, didn't we?
[10:39] <ajmitch> yes
[10:39] <ajmitch> it was often more useful than pbuilder
[10:39] <\sh> if it's pbuilding, you can find out only the obvious ftbfs...but our buildds are different and sometimes showing different ftbfs mess
[10:40] <sistpoty> s.o. should talk to lamont|infinity, so that we have these again (more in time for dapper)
[10:40] <ajmitch> \sh: yep, and my box was a bit slow to do lots of pbuilder work ;)
[10:40] <lamont-work> needs to be run again, not sure where it sits in relation to the launchpad migration
[10:40] <ajmitch> hi lamont
[10:41] <sistpoty> hi lamont-work
[10:41] <ajmitch> amazing who shows up when you mention them
[10:41] <sistpoty> lamont-work: any chance to start test-builds soon?
[10:41] <lamont-work> sistpoty: starting them is something that goes through elmo before me...
[10:41] <\sh> sistpoty: I think we have to wait for the launchpadders and soyuz
[10:41] <sistpoty> ah, k
[10:42] <sistpoty> note to self, ping elmo about that
[10:42] <\sh> lamont-work: any ETA on soyuz?
[10:42] <lamont-work> \sh: I'm out-of-loop
[10:43] <siretart> \sh: on saturday, there were some testuploads done
[10:43] <ajmitch> there was an update mail on the launchpad-users list about it
[10:43] <\sh> lamont-work: ok :)
[10:44] <lucas> ok. any other points ?
[10:45] <sistpoty> if not, date and time of next meeting... any proposals?
[10:45] <lucas> could everybody give their names again, for the minutes ?
[10:46] <lucas> Feb 15th, 21 UTC ?
[10:46] <sistpoty> ok with me
[10:47] <lucas> then we can do it at 20 UTC ;)
[10:47] <sistpoty> also ok, for me
[10:47] <sistpoty> if nothing needs discussion any more, meeting adjourned :)
[10:47] <siretart> ok
[10:48] <ajmitch> the meeting time is agreed then?
[10:48] <lucas> I'll put the minutes on the wiki in a few minutes
[10:48] <ajmitch> oh well
[10:48] <lucas> ajmitch: we can discuss it again later
[10:49] <sistpoty> ajmitch: seems like it... at least nobody cried, but we can do another poll or discuss it on the ML
[10:49] <ajmitch> sistpoty: I won't be there then
[10:49] <lucas> which time of day would suit you ?
[10:49] <sistpoty> but at least we have a proposal, ppl. should shout if they don't like it :)
[10:51] <ajmitch> I may not even have much net access then
[10:51] <ajmitch> I don't know at the moment :)
[10:51] <lucas> ok
[10:51] <sistpoty> goes for me one month later probably (since I'm moving then)
[10:53] <ajmitch> but there are > 30 MOTUs, so finding a time that suits even all the active ones is impossible
[10:55] <siretart> right
[10:55] <sistpoty> ok, I'm off again... cya
[10:57] <lucas> ok, could somebody review and fix https://wiki.ubuntu.com/MOTU/Meetings/2005-02-01 ?