09:00 sistpoty    ok, welcome to the meeting
09:01 sistpoty    please state your names for the minutes
=== sistpoty is StefanPotyra
=== lucas is LucasNussbaum
=== lfittl is LukasFittl
09:01 zul         ChuckShort
09:01 sivang      hi all, I will watch not sure will stay to end
                  I added most (all?) of the points on
09:01 lucas . 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
=== zyga [n=zyga@ubuntu/member/zyga] has joined #ubuntu-meeting
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
09:03 lucas       (which generates )
09:03 lucas       are people using it ? what's missing ? etc
=== bmon [] has joined
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
                  hm... iirc the science team wanted like it. but I don't
09:05 sistpoty    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 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
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
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
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
                  hm... I remember bits of the discussion when utnubu was founded,
09:13 sistpoty    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
09:14 lucas       also, DCT would be a way to put some pressure on Debian
                  but having the DCT to give back the changes might lead to the
09:14 sistpoty    idea "oh we have DCT to report back changes why should I do it
                  then?", which should be avoided
                  lucas: DCT is good as a team of people comitted to their work
09:14 zyga        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
                  lucas: I think a team like the DCT should rather focus on making
09:19 siretart    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)
=== rob^^^ [] has joined #ubuntu-meeting
09:20 siretart    I think some people overrate the tb. it gives decisions on
                  technical problems. this is partly a technical problem
=== lucasd [n=lucas@ubuntu/member/lucasd] has left #ubuntu-meeting ["Fui]
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 :-)
                  lucas: I have the impression that, given to the very few
09:23 siretart    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
=== Kyral [n=kyral@ubuntu/member/kyral] has joined #ubuntu-meeting
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:
                  Several people mentionned that Ubuntu devs should already send
                  patches and report bugs upstream. However, it's often not the
09:27 lucas       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
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.
                  lucas: I don't think we need an official statement for that,
09:30 sistpoty    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 ;)
=== minghua [] has joined #ubuntu-meeting
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
09:33 siretart    yes. espc. on important things. I consider this really important,
                  if we don't want to fail badly
09:33 lucas
                  lucas: ok, these pages you are reffering to. Yeah, I also think
09:35 siretart    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?
=== ajmitch is just a simple MOTU :)
=== sistpoty puts the DD hat on ajmitch's head
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
09:42 siretart    ajmitch: what was the question? and what the answer?
                  siretart: the problem is that I can't recall just what was asked
09:43 ajmitch     - I think it was about motus packaging new stuff & diverging from
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"
09:44 lucas       ajmitch: yup
=== ajmitch probably saw it
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
=== ajmitch had spotted it on the wiki the night before
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
=== ajmitch is probably obliged to help out with the DCT
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
                  I mean, given that someone (or team) gives some guidelines. what
09:46 siretart    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
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
                  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
09:48 lucas       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
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 ;)
=== ajmitch sighs
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
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
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
                  sistpoty: I have a very mixed feeling. it depends on the package.
09:54 siretart    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
09:55 ajmitch     siretart: that's not the fault of the MoM reports
09:55 lucas       example of package with the problem :
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
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
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?
                  ajmitch: that's why we should start working on a tool ASAP so we
09:58 lucas       get a lot of "common base packages" when we start working on
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
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
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 ?
=== ajmitch gives up
10:03 lucas       s/can get take/can I take/
                  well, from the viewpoint of a tiber-admin, I don't really object
10:03 sistpoty    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
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
                  backups of (lucas). Some people are hosting bzr
10:06 siretart    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
10:08 siretart    lucas: tiber is not in the DC of canonical
10:09 siretart    lucas: it is rented by canonical at
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.
=== Hirion [] has joined #ubuntu-meeting
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 has bought several servers with some
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 I think he
                  has no problems with putting those tarballs on
10:14 siretart    lucas: 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
                  but I still would really appreciate if these snapshots are only
10:17 sistpoty    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
=== siretart on every boot, but not offsite, only on the second hard drive
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
10:22 ajmitch     not hct
                  and to be honest...what do we need to backup from tiber? the only
10:22 \sh         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...
=== smurf [n=smurf@debian/developer/smurf] has joined #ubuntu-meeting
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?
=== lucas doesn't
10:29 lucas       unmet build-dep or unmet Depends/Recommends ?
10:29 ajmitch     sistpoty: yes?
10:29 sistpoty    ajmitch: you once started on 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
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
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
                  sistpoty: unmet deps means: "some of the deps a package tries to
10:33 \sh         install is broken" but that a dep itself can be 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
=== dirvine [] has joined #ubuntu-meeting
10:35 siretart    you will get this output:
10:35 siretart      zope3: Depends: python2.4-mechanize (>= 0.0.10a) but it is not
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)
=== ajmitch has a script in his bzr repository for that also
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
                  if it's pbuilding, you can find out only the obvious ftbfs...but
10:39 \sh         our buildds are different and sometimes showing different ftbfs
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
=== Hirion [] has left #ubuntu-meeting []
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 ?
=== lucas is LucasNussbaum
=== sistpoty is StefanPotyra
10:46 lucas       Feb 15th, 21 UTC ?
10:46 sistpoty    ok with me
=== ajmitch will skip the next meeting
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 :)
=== siretart is ReinhardTartler
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 :)
=== ajmitch doesn't matter
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

MeetingLogs/MOTU_2006-02-01 (last edited 2008-08-06 16:24:38 by localhost)