MOTU_2006-02-01
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 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
=== 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
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
=== bmon [n=monnahan@132.Red-83-40-81.dynamicIP.rima-tde.net] has joined
#ubuntu-meeting
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 s.th. 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 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
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
Debian
09:14 lucas also, DCT would be a way to put some pressure on Debian
maintainers
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^^^ [n=rcaskey@cai17.music.uga.edu] 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
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.
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 [n=minghua@danube.mems.rice.edu] 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 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
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
MOTUs
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
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
=== 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
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
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
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 ;)
=== 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
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
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
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?
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
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 ?
=== 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
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
backups of tiber.tauware.de (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
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.
=== Hirion [n=hirion@draugr.de] 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 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
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
moment
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 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
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 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
=== dirvine [n=dirvine@bozii9.host.tcw.telecomplete.net] 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
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)
=== 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
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
=== Hirion [n=hirion@draugr.de] 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... cyaMeetingLogs/MOTU_2006-02-01 (last edited 2008-08-06 16:24:38 by localhost)