/srv/irclogs.ubuntu.com/2006/01/17/#ubuntu-meeting.txt

=== dholbach [n=daniel@ubuntu/member/dholbach] has left #ubuntu-meeting ["Ex-Chat"]
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-meeting
=== slomo_ [n=slomo@ubuntu/member/slomo] has joined #ubuntu-meeting
=== jsgotangco [n=jsg@210.4.38.43] has joined #ubuntu-meeting
=== mhz [n=mhz_chil@moinmoin/fan/mhz] has joined #ubuntu-meeting
=== nomed [n=debaser@host82-194.pool8254.interbusiness.it] has joined #ubuntu-meeting
=== highvoltage [n=Jono@196.36.161.235] has joined #ubuntu-meeting
=== LoneVVolf [n=lonevvol@85-124-12-244.dynamic.xdsl-line.inode.at] has joined #ubuntu-meeting
=== robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #ubuntu-meeting
=== mvo [n=egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting
=== ..[topic/#ubuntu-meeting:robitaille] : 12 Jan 08:00 UTC: Dapper Development Status | 12 Jan 20:00 UTC: MOTU | 13 Jan 14:00 UTC: Documentation Team Meeting | 17 Jan 20:00 UTC: Technical Board | 24 Jan 21:00 UTC: Community Council
=== ..[topic/#ubuntu-meeting:robitaille] : Calendar: http://fridge.ubuntu.com/event | Logs: http://people.ubuntu.com/~fabbione/irclogs/ | 12 Jan 08:00 UTC: Dapper Development Status | 12 Jan 20:00 UTC: MOTU | 13 Jan 14:00 UTC: Documentation Team Meeting | 17 Jan 20:00 UTC: Technical Board | 24 Jan 21:00 UTC: Community Council
=== Lathiat [i=lathiat@ubuntu/member/lathiat] has joined #ubuntu-meeting
=== Burgundavia [n=corey@24.68.149.225] has joined #ubuntu-meeting
=== Hobbsee [n=Hobbsee@CPE-144-136-118-222.nsw.bigpond.net.au] has joined #ubuntu-meeting
=== dholbach [n=daniel@i577B10F4.versanet.de] has joined #ubuntu-meeting
=== Hobbsee [n=Hobbsee@CPE-144-136-118-222.nsw.bigpond.net.au] has left #ubuntu-meeting ["So]
=== Keybuk [n=scott@descent.netsplit.com] has joined #ubuntu-meeting
=== pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-meeting
pittihey08:56
=== seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-meeting
=== infinity [n=adconrad@203-214-4-60.dyn.iinet.net.au] has joined #ubuntu-meeting
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #ubuntu-meeting
mdzis everyone here?08:58
Riddellgood morning08:58
mjg59Morning08:58
dholbachhello08:58
Mithrandirehlo08:58
=== Mez waves
=== pitti waves to mdz
seb128hi08:58
ajmitchevening08:59
Kamionmorning08:59
mvohello08:59
dokogood morning08:59
ogra_ibook*yawn*09:00
mdzJaneW: ping?09:00
=== iwj [n=ian@xenophobe.extern.relativity.greenend.org.uk] has joined #ubuntu-meeting
mdzfabbione,Keybuk,infinity,BenC,daniels: ping09:01
Keybukyeah, I'm here ;)09:01
fabbionemdz: pong09:01
JaneWpong09:01
infinitypong.09:01
JaneWhi all09:01
=== fabbione needs 2 minutes to write up
pittihey JaneW, how are you09:02
mdzdoes anyone know if BenC is about?09:02
JaneWpitti: good thanks and you?09:02
pittifine09:02
JaneWmdz: he is not but I have an update from him09:02
Keybukmdz: he only just joined #u-d09:02
fabbionemdz: he should. he knew the meeting was today09:02
JaneWmdz: I have an update from daniels and sivang too09:02
mdzKeybuk: his client rejoins every 20 minutes or so due to network problems09:02
mdzJaneW: did he send you an update because he had a reason he couldn't be here?09:03
=== Mez [n=Mez@ubuntu/member/mez] has joined #ubuntu-meeting
JaneWmdz: there was no explanation or comment, just the update, - testing-server-hardware09:04
mdzJaneW: I see, please paste what you have for BenC and daniels09:04
JaneWBenC09:04
JaneWpreventing-hardware-support-regressions: Build system tested, will start09:04
JaneWpushing builds this week. Afterwards will announce to the community for09:04
JaneWtesting.09:04
JaneWubuntu-server-kernel: Done (marked implemented in lp).09:04
JaneWDaniels09:05
JaneWx-roadmap: x11r7 final in, polishing xorg source package for imminent09:05
JaneWpost-fl3 upload09:05
JaneWmisc: broken laptop screen and dsl hilarity make for interesting09:05
JaneWavailability, generally smsable within reasonable hours 09:05
mdzJaneW: what about testing-server-hardware?09:05
JaneWlike I said above... his report was -testing-server-hardware09:05
JaneWI did e-mail and ask about it tho09:05
mdzoh, I thought you were saying he gave an update for testing-server-hardware specifically09:06
Kamionoh you mean "minus" rather than a bullet09:06
mdzok09:06
JaneWyes sorry, the hyphens confussed the issue09:06
mdzok09:07
mdzdholbach: next09:07
dholbachformal-test-plans: talked with BenC about hardware-regressions, added Instructions on how to report bugs from testing, referred to DebuggingProcedures; needs fleshing out, but i consider the pages 'ready to go' - media testing needs test files, jdub didn't want to have example-content used for this, we'll link to test files from Media/Testing09:07
dholbachthis week (done): package updates, bug triage, bug day, some merges09:07
dholbachthis week (todo): motu meeting, more merges, bug triage09:07
dholbachnext week: bug triage, more package updates, merges, starting apt-get.org reviews09:07
=== ealden [n=ealden@ipdial-167-232.tri-isys.com] has joined #ubuntu-meeting
mdzdholbach: what's the reason not to use example-content?09:07
dholbachmdz: jdub considers it as something "for end users" not for "developers", although i said, that i didn't want to ship all sorts of broken stuff, he didnt like the idea09:08
mdzdholbach: it's something we'll include in the default install, it's natural to use it for testing09:08
dholbachhe gave me the idea of investigating in the test files of the gstreamer development team09:09
mdzok09:09
mdzthanks dholbach09:09
dholbachde rien09:09
mdzdoko: next?09:09
Kamionthat sounds like it would test the things that already work?09:09
dokothis week:09:09
doko- openoffice.org: 2.0.1 packages built on breezy (for breezy-updates?), start merging with unstable, renaming the packages09:09
doko- python-roadmap: python-central update, preparing snapshot version for testing09:09
doko- toolchain-roadmap: ia64 fixes, prepare for amd64 biarch update09:09
doko- other: syncs/merges, updates to new upstream versions, eclipse update (needs mozilla-dev update), half yearly ISDN updates, happy about ronne's disk space09:09
Kamionor do they have an a-priori good spread of test files?09:09
dokonext week:09:09
doko- openoffice.org: sync week, i.e. dictionary and locale support (kurdish merge)09:10
dokostatus:09:10
doko- toolchain-roadmap: amd64-biarch (blocked on fixing a glibc amd64-i386 self-bootstrap)09:10
doko- toolchain-dapper+1: blocked by preparation of wanna-build and buildd infrastructure (no change)09:10
mdzdholbach: ping me sometime tomorrow to chat about it if there is still a question, we need to keep going09:10
doko- openoffice-gnome: not started, need an update from martink09:10
doko- openoffice-help: implemented (no change)09:10
doko- openoffice-spellchecking: not started (no change)09:10
doko- native-java-gcj: infrastructure is ready, packaging of -gcj binary packages not started09:10
doko- java-roadmap: mostly done, pending are eclipse updates (blocked by firefox-dev/mozilla-dev) and the native-java-gcj support09:10
doko- python-roadmap: proposal implemented, testing outside the archive now.09:10
dholbachmdz: ok09:10
mdzdoko: renaming = openoffice.org2 -> openoffice.org?09:10
dokoyes09:10
mdzis there any real value in that?  it will complicate upgrades09:10
dokowe cannot support dictionaries for both versions (1 and 2), so we have to either derive for all dictionary package from debian, or make the name change as well09:11
mdzdoko: is the biarch bootstrap an infinity task?09:12
dokoI don't think the change will be that complicated for the end user09:12
mdzdoko: please talk with mvo about how it should be handled in the upgrade tool09:12
dokomdz: currently Mithrandir is looking at it09:12
Kamionwe've already gone openoffice.org -> openoffice.org2 in previous releases, going back should be relatively straightforward I'd expect09:12
infinitymdz: I took over the "fixing glibc" task from jbailey while he's off galavanting.09:12
dokomdz: will take the upgrade with mvo09:12
infinitymdz: Mithrandir had a poke last night, I'm back at it today to see where it went wrong. :)09:13
Kamiondoko: are we using the python-support work being done in Debian now?09:13
Kamion(or working with them, I guess)09:13
mdzKamion: .org -> .org2 was sort of a mess; if they now conflict that will be easier but still09:13
dokoKamion: not yet, I'm talking with Joss about merging the two09:13
mdzdoko: is the help system bounty completed?09:13
Kamionok, great, there was a lot of good analysis of the problem domain on #debian-release (which you saw, I know) so sharing that would be good09:14
dokomdz: from my point of view, yes, it does build. hope, it will not break for 2.0.2 ;)09:14
mdzdoko: ok, please send me a reminder to deal with the payment09:15
dokomdz: ok09:15
mdzthanks, doko09:15
mdzfabbione: next09:15
fabbione* server-candy: system-integrity-check: fixed performance issues. Deploy is blocked on admins (rt: #723). Started other activities l09:15
fabbioneike collecting 3rd party pkgs and so on.09:15
fabbione* ubuntu-cluster: full upgrades of currently supported suites. Performed some tests and bug fixes (redhat-cluster-suite). Missing to test OCFS2.09:15
fabbione* probe-for-root-filesystem: no progress. Probably needs reassigment to somebody else.09:15
fabbione* boot-from-usb: implemented.09:15
fabbione* merges: zlib - still pending libc6-i386-dev, one merge (partman-auto-lvm) is pending but nothing scary or urgent.09:15
fabbione* last week: server-candy, ubuntu-cluster, boot-from-usb.09:15
fabbione* next week: vac. Tomorrow i will be merging the last bits around and testing OCFS2 so there will be no need for updates at the next09:15
fabbione meeting.09:15
infinityfabbione: Is the zlib merge just pending on that as a build-dep, but otherwise done?09:16
fabbioneinfinity: no it needs to be done from scratch09:16
mdzMithrandir: do you have some free bandwidth to help finish off probe-for-root-filesystem?09:16
infinityfabbione: If so, you can reassign the merge to me, give me your sources, and I'll make sure it's sorted within minutes of the biarch stuff being unbroken.09:16
Mithrandirmdz: sure, I can probably reuse some casper stuff.09:16
fabbioneinfinity:  i will reassign the bug, but i have no sources.09:16
infinityfabbione: Oh, if it's Real Effort(tm), then you're welcome to keep it. :)09:16
Mithrandirmdz: give me a minute to skim the spec before giving it to me09:16
mdzMithrandir: great; the remaining piece is just to have it mount by uuid I think.  fabbione can fill you in09:16
fabbioneinfinity: it needs to go in before UVF and i won't be here next week09:16
infinityfabbione: Oh, then reassign it, yes.09:17
mdzfabbione: enjoy your vacation, have a good rest09:17
fabbionemdz: assuming we are going, yes thanks :)09:17
fabbioneinfinity: yup09:17
Mithrandirmdz: looks simple enough.09:17
mdzfabbione: you will take the time off even if you do not travel, right?09:17
fabbioneMithrandir: i will talk to you about it after the meeting09:17
fabbionemdz: yes, but i will be around if we don't travel.09:17
Mithrandirmdz: I need to get my USB hard drive back, but that should be today or tomorrow or so.09:17
mdzMithrandir: ok09:18
mdzfabbione: thanks09:18
mdzinfinity: next09:18
fabbionewelcome :)09:18
infinityLast week:09:18
infinity* reducing duplication: Got MySQL 5.0 in, did some rapid bugfixing to get the packaging sane. (have joined the Debian MySQL team to make sure it gets enough polish)09:18
infinity* usplash-initramfs: Implement dirty hack for this that seems to work fine.  Eventually needs more work to do it "right" in usplash itself.09:18
infinity* misc: security, initramfs bugfixing, new LRM, new PHP, livefs changes for Mithrandir, random installability/buildability fixes in line with ongoing buildd maintenance.09:18
infinityNext week:09:18
infinity* reducing duplication: Begin rebuilding all of main to use libmysqlclient15, and kick MySQL 4.x to universe09:18
infinity* splash-down: Should have time to get this one in this week.09:18
infinity* misc: - glibc amd64-i386 biarch needs bootstrapping (but first, an irritating bug that Tollef and I spent several hours on last night needs to be hunted and killed) - need to merge subversion_1.3 for the masses (doko's request, but I agree we want it for release) - need to hunt down a kernel frequency_scaling bug that's preventing my laptop from working at full speed. :)09:18
mdzthe last update has a note for us to discuss mysql 5.0; I think we're in agreement there per email conversations09:18
infinity<nod>  I'd say so.09:19
dokoinfinity: any note about db4.4, or do we go with 4.3?09:19
infinityI think we'll stick with 4.309:19
=== pitti agrees
pittiwell, most packages should play well with any version, so if we need to upgrade, there are no blockers09:20
infinitySleepycat's upstream support is good (for EVER), so there's no concern there, and 4.4 is completely untested in Debian/Ubuntu, so I don't want to risk it.09:20
mdzinfinity: sounds like we can call usplash-initramfs implemented09:20
infinityBut 4.3 and 4.4 both have versioned symbols, so if we need to bring it in, it probably won't hurt anyone to have a mix.09:20
mdzinfinity: livefs changes includes squashfs images?09:20
infinity(I'd prefer not to have a mix)09:20
infinitymdz: Yes, we have squash.09:20
mdzcool09:21
infinitymdz: On amd64 right now, will turn it on on the other arches as soon as we've had a successful amd64 build that we've tested and know works. :)09:21
mdzKamion: should be trivial to switch the daily builds to use squashfs, yes?09:21
infinitymdz: Already done.09:21
Kamionmdz: already done09:22
mdzis there a build available with the change?09:22
Kamion(and yes, was trivial except for me getting it wrong the first time)09:22
Mithrandirmdz: it's also a trivial per-arch switch, so we can switch ppc back to cloop if we deem unionfs too unstable09:22
=== ealden_ [n=ealden@ipdial-189-46.tri-isys.com] has joined #ubuntu-meeting
Kamionmdz: on amd64, yes, but it doesn't boot yet for other reasons09:22
infinitymdz: Yes, but it's broken due to initramfs messing up.  I'll build again after the meeting.09:22
mdzok, looking forward to testing that09:22
mdzthanks infinity09:22
mdziwj: next09:22
iwjAutomatedTesting:  Making reasonable progress on implementation.  Tester core is about half-done now.  From last week: Apparently the IBM LTC are interested in this too and there's going to be a call (organised by Malcom Yates I think) - but this has all gone quiet.09:23
iwjFirefox maintenance:  The package isn't quite so hopeless since my upload at the end of last week.  Not working on it this week (so as to get AutomatedTesting done).09:23
iwjDefaultApplicationsFirefox: no change since last report.  I will pick this up properly when AutomatedTesting is done.09:23
iwjDeveloperDocumentation: Not started, not blocked.09:23
iwjEmail and bugs backlog: moderate.09:23
mdziwj: what remains on DefaultApplicationsFirefox again?09:23
iwjIt's basically still buggy.09:23
mdzhmm09:23
iwjFor example, it's hard to select a non-default application.09:23
mdzdid you have a chance to do that examination of epiphany?09:24
iwjAnd I'm told it has a security problem with .desktop files.09:24
mdza security problem?09:24
dokoiwj: does Firefox maintenance include mozilla maintainance as well (at least until mozilla-dev is installable again)09:24
=== pitti doesn't know anything
iwjApparently you can download them and then clicky clicky gnome will run them.09:24
iwjdoko: It does in the sense that I'm not doing it this week.09:24
iwjYes, we ought to talk about mozilla.09:25
seb128right, GNOME will display the Name= of the .desktop as title and use the Icon= and run whatever command is used09:25
pittiouch09:25
iwjI haen't looked at epiphany yet.  That definitely counts as ff maintenance :-).09:25
mdzdo we need mozilla in main?09:25
ogra_ibookpitti, ouch ? 09:25
seb128pitti: we had this discussion on ubuntu-devel some months ago I think09:25
ogra_ibookpitti, you can only run existing apps09:25
infinitymdz: No, it's on its way out.  Once I split enigmail, nothing's holding it in.09:25
seb128ogra_ibook: like rm -rf ...09:26
Kamionogra_ibook: with arbitrary arguments, and gksudo is an existing app09:26
mdzok09:26
ogra_ibookoh, yes09:26
iwjI made nspr and nss come out of ff to try to get mozilla out of main.09:26
mdzdoko: so mozilla-dev shouldn't be blocking anything, no?09:26
ogra_ibooksilly me09:26
pittiseb128: hm, I don't remember that09:26
dokomdz: currently eclipse doesn't work with firefox 1.5, ok that's universe, but currently mozilla-dev isn't even installable, and firefox-dev doesn't built on amd64 and ia6409:26
iwjThe 64-bit problem I will fix but not until next week.09:27
mdzok09:27
seb128pitti: what epy issue?09:27
iwjThis only affects things that embed ff.09:27
ogra_ibookpitti, in the beginning of breezy there was a discussion about autostart on CDs, i think it inherited from this one09:27
mdziwj: do you have an ETA for something basically functional for automated testing?09:28
pittiogra_ibook, seb128: let's discuss that in #u-devel09:28
iwjThat depends on how badly ff eats me next week, I think.09:28
seb128pitti: Date: Mon, 03 Jan 2005 18:55:21 -0500, Subject: Scary .desktop behaviour09:28
seb128pitti: for the security issue09:28
iwjIt's possible I'll finish it and produce something playable-with the end of this week but I'm not promising that.09:28
mdzok09:29
mdzthanks iwj09:29
mdzKamion: next09:29
iwjOf course there's hardly any tests.  Just one example for now that I'm playing with, sitting on my hard disk.09:29
Kamionue-partitioning-tool: Got partman running under espresso, which makes the autopartitioning screen work. Basic progress bar handling and chaining to gparted implemented. Some bug fixes still required to make it all flow smoothly enough to use, but we're getting close. Various UI changes in partman will be needed further down the line.09:29
Kamionubuntu-express-copy-filesystem: Tollef has made /rofs available to me with the unmodified file system; I've changed the espresso code to use it. Agreed hook scheme for casper to propagate configuration.09:29
Kamioncd-bootloader: Killed scary timeout clock, fixed some video mode menu bugs, and fixed syslinux to clear the screen properly when switching back to text mode. Still to do: help text and keymap support.09:29
Kamionmisc: Helped switch live CDs to squashfs (with Adam/Tollef). I'm preparing Flight CD 3 now; exact ETA unknown but obviously ASAP; help with testing appreciated, especially for Kubuntu/Edubuntu; broken live CD boot process being fixed (we hope) at the moment.09:29
Kamionblocked: nothing much09:29
Kamionnext-week: merge catch-up; get espresso up to the point where I can do a test install as long as I avoid the UI bugs (should be feasible, I think)09:29
mdzKamion: what's the plan for the keymaps in cd-bootloader?09:30
RiddellKamion: I should test today's dailys for kubuntu on all arches then?09:30
ogra_ibookRiddell, you should do that every day :P09:31
Kamionmdz: waiting for keymapper to switch to X keymaps (Tollef's looking at this), then scrape out the list of keymaps in much the same way as we do for locales and stick them in a menu09:31
infinityRiddell: Test the installation CDs, don't bother with Live until someone gives a go-ahead in #ubuntu-devel.09:31
KamionRiddell: what infinity said09:31
mdzKamion: for flight 3, please poll everyone for items which should be included in the release announcement, especially new features which are ready to test, and infrastructure which needs to be regression-tested09:31
Kamionmdz: if feasible and I have time, limit the keymap menu to those optimal for the current locale09:31
Kamionmdz: ok, I'll see if I can track down the guy who did that excellent wiki page for Flight 209:31
KamionDapperFlight209:32
mdzKamion: did the flight 2 announcement go to -users and -devel as in the past?09:32
mdzKamion: I'm thinking we should start announcing them on -announce09:32
BurgundaviaKamion, DapperFlight3 already exists and has content going in09:32
=== dholbach_ [n=daniel@i577B06D0.versanet.de] has joined #ubuntu-meeting
Kamionrah, DapperFlight3 already exists09:32
KamionBurgundavia: yeah, just noticed :)09:32
dholbach_sorry, flew out09:32
Kamionmdz: -users and -devel-announce, and I've been warning that it might be just -devel-announce in the future09:32
MithrandirRiddell / ogra_ibook / everybody who cares about live cds: it's very, very important to keep -desktop installable, else, you won't get new live images and stuff breaks.  Also, make sure to merge seeds, since we've seen that cause live failures with user-setup.09:32
KamionI'm vacillating on that; a lot of people on -users aren't on -devel-announce09:33
KamionMithrandir> merge seeds *and* upload -meta to cope09:33
ogra_ibookMithrandir, yup, known here ...09:33
Kamion(since the live CD build process relies on -meta)09:33
mdzKamion: a lot of the people who we want to regression-test the Flight CDs are not on -devel-announce09:33
mdzand people want to hear more on -announce09:34
dholbachfridge-devel too :)09:34
Kamionmdz: oh right, you actually mean -announce09:34
infinityKamion: That could be changes, but since livefs builds are about the only real-world automated test we have right now to prove that the metapackages work...09:34
Kamionok, can do; ubuntu-announce and fridge-devel then?09:34
mdzRiddell, ogra_ibook: you should be merging your seeds regularly, e.g. if you see an ubuntu-meta upload there are probably changes you need to merge09:35
Kamioninfinity: yeah09:35
mdzKamion: sounds good09:35
mdzKamion: thanks09:35
mdzKeybuk: next09:35
ogra_ibookmdz, yup, i normally do ...09:35
Keybukurgent-reboot-notification: Stole this spec off the nobody it was assigned to (it was linked from the udev-roadmap) and implemented it.09:35
Keybukstreamlined-boot: in progress;  have designed new readahead stuff09:35
Keybuknetwork-magic: ifupdown mods finished, need to test and upload.  network-manager still blocked on infinity (madwifi-ng) and jbailey (libc resolved patch)09:35
Keybuknext week: the same, but more so; merges09:35
mdzKeybuk: is there anything further in streamlined-boot which has much regression potential?09:36
mdzreadahead should be pretty tame in that respect09:36
Keybukmdz: no, it's mostly just careful adjusting and tweaking09:36
MithrandirKeybuk: uh, you're doing evil stuff to readahead?  What's that?09:36
Keybuk*checks his board*09:36
Keybuknope, definitely all the scary stuff is done09:36
KeybukMithrandir: will discuss out-of-band if you like09:36
mdzKeybuk: now that jbailey is finished with the biarch work, he shouldn't be holding a lock on glibc anymore, no?09:36
mdzshould be ok to upload that patch09:37
Keybukmdz: aye, he said he'd do it a few weeks ago, then two weeks ago, then one week ago09:37
MithrandirKeybuk: please, since I have evil plans for readahead magic for the live cds.09:37
Keybuk:p09:37
infinityI have the current lock, actually.09:37
KeybukMithrandir: ok, then we should definitely talk; straight after this meeting?09:37
MithrandirKeybuk: sure09:37
infinityKeybuk: If the patch is sane, toss it to me, and I'll put it in the "fix the bloody biarch bootstrap" upload.09:37
mdzinfinity: ok, perhaps you can merge that ptach along teh way then09:37
mdzit's been discussed and agreed upon already09:37
infinityRock.09:37
infinityKeybuk: Patch and/or bug# SVP.  My INBOX wants love.09:38
Keybukinfinity: 09:38
Keybukhttp://sources.redhat.com/ml/libc-alpha/2004-09/msg00130.html09:38
mdzKeybuk: thanks09:38
pittiKeybuk: does NM have a realistic change to make it before feature freeze?09:38
=== LoneVVolf [n=lonevvol@213.164.22.2] has joined #ubuntu-meeting
mdzLathiat: do you have anything to report on zeroconf?09:38
Keybukpitti: depends on infinity09:38
Keybukpitti: but I don't see why not09:38
mjg59NM is mostly a problem due to the kernel support at the moment09:38
mdzMithrandir: next09:39
Mithrandiropenoffice-amd64: no progress09:39
Mithrandirlive-cd-performance: squashfs images are now produced, should speed up the cd a fair bit.  Readahead/inotify hacks are being worked on, but not there yet.09:39
Mithrandirone-true-path: no progress09:39
Mithrandirsimplified-livecd: almost there.  keyboard selection is missing, espresso integration is missing09:39
Mithrandirnetwork-authentication: no progress, doubtful it'll make feature freeze09:39
Mithrandirlivecd-squashfs: implemented09:39
Mithrandirlivecd-unionfs. implemented, but has problems on powerpc.  I'm working on it with BenC.09:39
Mithrandirmisc: done a bit of d-i keyboard hackery so we can hopefully switch to using X keymaps in both console and X.09:39
MithrandirBlocked on: nothing, I have plenty to do and work is progressing09:39
MithrandirThis week: Get simplified-livecd done, help Colin with Flight3, hopefully some live-cd-performance hacking09:39
mdzMithrandir: let's drop network-authentication officially09:39
Mithrandirmdz: defer for dapper+1, I guess, not drop?09:40
mdzMithrandir: drop from dapper, yes09:40
Mithrandirsure09:40
mdzMithrandir: looking good, thanks09:40
JaneWmdz: I just mailed you an update from krstic...09:40
mdzmjg59: power-management-configuration?09:40
mjg59mdz: gnome-power-manager is ready, dbus is dealt with09:41
mdzmjg59: you wanted some help from pitti?09:41
mjg59The two things that are needed are (a) libpam-foreground integration (discussion on -devel didn't get very far, I'd like some more feedback) and (b) support for hal to execute privileged code09:41
mdzok, let's talk about that after I've slept09:42
mdzmvo: next09:42
ogra_ibookmjg59, look at my dmidecode patch from dapper 09:42
mjg59(b) is basically cutting and pasting some code from hald into a daemon that runs as root and has some generic dbus glue, but I don't have time right now09:42
ogra_ibookmjg59, err, hoary, sorry09:42
KamionMithrandir: I think you can count casper/espresso integration as part of ubuntu-express-copy-filesystem, not simplified-livecd, for purposes of marking the latter implemented09:42
mvoDid:09:42
mvo* apt support for multiple signatures on the release file09:42
mvo* gnome-app-install fixes, supports license display/accept screen for proprietary apps and per channel apt-keys now [ThirdPartyPackages] 09:42
mvo* Dist-Upgrade tool:09:42
mvo  - more reliable meta-pkg detection/fixing missing one, should work on broken caches as well09:42
mdzKamion: agreed09:42
MithrandirKamion: ok09:42
mvo  - more sanity checking after it calculated the upgrade (are the meta-pkgs still installed etc)09:42
mvo  - better error detection/handling on e.g. network problems  09:42
mvo  - logs it's activities09:42
mvo  - various hoary->breezy test-upgrades09:42
mvo[AutomaticUpgrades] 09:42
mvo* updated the apt-get.org fetching/test-building script (with dholbach) and ran a first test-run through all the stuff available on apt-get.org (291 repos scanned, 393 successful builds, 825 failed) 09:42
mvoNext week:09:42
mvo- work on the ThirdPartyPackages spec (add key support to the channels)09:42
mvo- work on the AutomaticUpgrades09:42
mdzmvo: is the dist-upgrade tool in reasonable enough shape for community testing?09:42
mvomdz: very close. what would we test it on? hoary->breezy?09:43
mdzmvo: sure, or breezy->dapper09:43
mdzmvo: just get some exercise for the infrastructure.  write a simple howto and post to -devel-announce with a call for testers09:44
mvoyes, that sounds good, I'll do that09:44
mdzneed to hurry to finish in time09:44
mdzmvo: thanks09:44
mdzogra_ibook: next09:44
ogra_ibook* thin-client-sound: implemented (thank you pitti, for the gstreamer magic!)09:44
ogra_ibook* thin-client-local-devices: dropped09:44
ogra_ibook* thin-client-memory-usage: worked on forced 16bit xorg mode (not preseedable, as most of the xorg settings). looked at nbd and the implementation for network swapping.09:44
ogra_ibook* thin-client-faster-startup: worked on the initscript handling, did more initramfs testing.09:44
ogra_ibook* gnome-screensaver-default-image: no progress, still need pictures ....09:44
ogra_ibook* general: done some further work on ltsp-build-client and ltsp-update-kernels (yaboot and kernel stuff) for ppc, getting edubuntu-artwork in shape, preparing for flight3, did some more dhcpd tests for the --next-server stuff09:44
ogra_ibook* next week: flight3 testing, missed the nfs timeout bugsqashing i had planned for last week, will do it this week, last xscreensaver merge work before UVF, getting all the local bits and pieces of ltsp into shape.09:44
mdzogra_ibook: any leads on the nfs timeout issue?09:45
ogra_ibooknot yet09:45
ogra_ibookas i said, i missed the time for debugging 09:45
mdzogra_ibook: if you haven't already, arrange to talk with BenC about it09:45
ogra_ibooksince its a bug its not critical for feature freez09:45
mdzit seems awfully like a kernel issue09:45
Riddellogra_ibook: what happened with thin-client-local-devices?09:45
ogra_ibookRiddell, postponed09:45
mdzRiddell: the spec was never complete, it needs much more discussion and design woru09:46
mdzwork09:46
ogra_ibookmdz, yes, i suspect the same09:46
mdzogra_ibook: thanks09:46
mdzpitti: next09:46
pittilast week: caught up with a lot of security updats, caught up with bug triage, lots of urgent bug fixes, main inclusion reviews09:46
pittino progress on specs (ENOTIME), but for JaneW's overview I'll give the current status of the non-implemented specs:09:46
pittifirewall: long-outstanding bounty proposal, I do not know about mdz's approval status; no news from carstenh for quite a while now09:46
pittiautomatic-printer-conf: DONE: dynamic USB printer recognition implemented due to cupsys 1.2beta; TODO: gnome UI integration requires to evaluate hal-cups-utils from Fedora, port it to Ubuntu, do integration and tests; no blocks, no progress09:46
pittilangpacks-desktopfiles: DONE: implemented for .desktop files; PLAN: outstanding for .server files (will try to look into this next week)09:46
pittiplan next week: get an agreement about sudo help approach in TB, last steps to throw mozilla out of main09:46
mdzpitti: is there an actual proposal for firewall?09:47
mdzscope of work and price?09:47
pittimdz: hm, carsten sent one ages ago, I have to look again (don't remember any more)09:47
mdzpitti: ok, if it's something I lost track of over the holidays, please resend09:47
pittimdz: no price, but scope etc. is there09:48
mdzpitti: thanks09:48
mdzseb128: next09:48
seb128dapper-desktop-plan: default panel configuration changed, "add to panel" changes will be uploaded today09:48
seb128other: load of bug triage, pushed some GNOME changes/patches upstream before the feature freeze, GNOME changes (pygtk splitted to pyobject/pygtk, etc)09:48
seb128next-week: dapper-desktop-plan, continue bug triage09:48
mdzseb128: which other parts of dapper-desktop-plan are still pending?  can you estimate the completion of the spec?09:49
mdzseb128: I saw that mjg59 posted some concerns which I think were aimed at dapper-desktop-plan, please make sure that sabdfl sees and responds09:49
seb12840% complete when the add to panel changes land today09:49
seb128that's menus-revisited09:50
seb128(mjg59 mail)09:50
mdzoh, even so09:50
seb128yeah, will do that09:50
mdzthanks seb12809:50
mdzsivang: ayt?09:50
seb128for dapper-desktop-plan there is some applet hacking that should be easy, and then the gdm changes09:50
mdzRiddell: next09:51
Riddelldone: KDE security fixes, shipping breezy CDs, bug day recruitment and support, CD testing, final few libstdc++ transition packages09:51
Riddellzeroconf: avahi support added09:51
Riddellkubuntu-express: browsing the current sources, touching up my pykde skills09:51
Riddellkubuntu-roadmap-dapper: CKJ support now complete (question, should scim etc go into main?)09:51
Riddellnext week: flight 3, qtparted changes for kubuntu-express, sudo wrapper09:51
mdzRiddell: I'm happy for scim to enter main given inclusion reports09:51
mdzRiddell: I'm less clear on what we need to do with it once it's there, beyond installing it by default09:51
Riddellmdz: we have them so I'll link them from the to be reviewed list09:52
dokowe be interesting to know how to test/use it ...09:52
pittiRiddell: I have a pending main inclusion report for scim09:52
RiddellI don't know if it should be installed by default since most users don't use it, maybe ship only09:52
mdzI've seen some email from a fellow who is interested in helping us with input methods09:52
mdzI'll see if he can provide some instruction about testing/using it09:53
ogra_ibookoh, main inclusion, any chance i see gobby reviewed pitti ? its a listed goal for edubuntu 09:53
KamionRiddell: the gparted --installer changes are (back) in now; emulating that general approach for kubuntu-express would probably be good09:53
RiddellKamion: that's the plan09:53
pittiogra_ibook: no problem security wise, I'm just scared of bug reports that complain about broken documents :)09:53
KamionRiddell: does Qt support anything like GtkPlug/GtkSocket for inter-process widget embedding?09:53
ogra_ibookpitti, forward them to me :) 09:53
RiddellKamion: I'm not sure exactly what that is, KDE has kparts09:54
mvoRiddell: the dist-upgrade tool is designed to make it easy to plug a new interface to it, we should talk about this after the meeting09:54
KamionRiddell: http://developer.gnome.org/doc/API/2.0/gtk/PlugSocket.html09:54
dholbachRiddell: wasn't there a blog entry recently about embedding qt in gtk and vice versa?09:54
mdzRiddell: thanks for the update09:55
mdzJaneW: any questions or concerns for the last 5 minutes?09:55
mdzor anyone else?09:55
JaneWI was going to raise the TC local devices issue, but after mails earlier I think it's not necessary09:56
JaneWI'll give sivang's update...09:56
mdzJaneW: I am going to throttle flint the next time I see him09:56
JaneWmdz: thank-you ;)09:56
JaneWSivan09:56
JaneWUpdates:09:56
JaneW1)Already working on the main backup application GUI together with finishing utility components. 09:56
JaneW2)Finished the media device detection code. (to offer a user to choose among available media targets to backup to).09:56
JaneW3)I expect to be able to finish the project before FF which is 23rd February. That should give me a month to QA and test the work. (As well as by other community members)09:56
JaneWTodo:09:56
JaneW1) Finish main application GUI and startup stuff.09:56
JaneW2) Write code to allow notification through notify-daemon about backup intervals. I had set up wrapping up libnotify for python usage for this, but this may be dropped if time does not allow it and I will use the gross hack of having pre-made C binaries per the 2 notificatios I need there instead.09:56
JaneW3) Code the dar integration bits.09:56
JaneW4) Code the mkisofs / cd burning bits.09:57
mdzok09:57
JaneWsorry the above is for: home-user-backup09:57
mdzright09:57
mdzogra_ibook: how does edubuntu look for flight 3?09:57
JaneWplease could everyone make sure their specs are up to date in LP09:57
mdzRiddell: and kubuntu?09:57
JaneWI know most ppl have been good at updating statuses etc09:58
JaneWalso not everyone finished the est dev days and expectation of delivery, we should still try to complete that09:58
MithrandirI wish launchpad had a way to say "this is 50% completed"09:58
mdzJaneW: have you made progress with someone on the LP team as far as getting a spec report export implemented in launchpad?09:58
ogra_ibookmdz, should be fine ... -desktop was broken for a while, i'm just pulling the first isos09:58
Mithrandirsome sort of rudimentary progress tracking.09:58
Riddellmdz: should be fine, I just need to test the CDs09:58
JaneWlast thing, the meeting for the week of the sprint, can we make it a sane local time instead of 2am?09:58
Mithrandirnow, stuff jumps from "approved" to "done".09:58
KamionJaneW: should the estimated dev days be remaining or from-start-of-project?09:59
mdzRiddell: have you tested some recent dailies?09:59
pittiMithrandir: you can use the whiteboard09:59
JaneWmdz: no I haven;t taken that further, is everyone happy with the report format and content?09:59
JaneWMithrandir: I did ask for a WIP at least09:59
=== vincent_ [n=vincent@85.69.101.91] has joined #ubuntu-meeting
mdzJaneW: I'd prefer that the old and new statuses were in separate cells10:00
KamionJaneW: start of the working day would be good10:00
mdzit's hard to read as is10:00
Kamion(for sprint meeting)10:00
JaneWKamion: I think from start to finish for consistency10:00
KamionJaneW: ok, so what should we be updating?10:00
Riddellmdz: been testing lives, which have had the authentication issue, should be working ok now after seed merge but yet to test today10:00
Kamionlikelihood of completion?10:00
Kamion(and I agree, it gets a bit mad otherwise)10:00
pittiJaneW: hm, I adapted mine to be the 'days left', not the 'total days'10:00
mdzJaneW: we also need that access control fix for targeting specs to a release, so that launchpad can be authoritative for that10:00
mdzJaneW: please follow up with kiko, find out who we should talk to about spec tracker stuff since mark will be too busy10:00
mdzand that's a wrap10:01
mdzthanks, everyone10:01
JaneWKamion: expectation of delivery (i.e. will the thing get done?) and estimated dev days (how long it;s expected to take)10:01
mdzand good night10:01
=== iwj [n=ian@xenophobe.extern.relativity.greenend.org.uk] has left #ubuntu-meeting []
fabbionenight mdz10:01
mvogood night mdz 10:01
fabbionecya later10:01
JaneWmdz: ok I'll pick it up again...10:01
ogra_ibooknight mdz10:01
dholbachgood night mdz10:01
JaneWlast thing, the meeting for the week of the sprint, can we make it a sane local time instead of 2am?10:01
pittithanks folks, bye10:01
Kamion09:00 < Kamion> JaneW: start of the working day would be good10:01
pittiJaneW: yes, pleeeeease :)10:02
JaneWKamion: ah right good, I opted for 10am, shall we make it 9am?10:02
=== Seveas [n=seveas@ubuntu/member/seveas] has joined #ubuntu-meeting
KamionI imagine we'll be doing start-of-day things anyway?10:02
Kamion9am+coffee = 10am, so I don't mind10:02
=== Keybuk [n=scott@descent.netsplit.com] has left #ubuntu-meeting [""]
JaneWwe'll need to decide if it's verbal, with report, or IRC as usual10:02
fabbionei suggest verbal10:03
infinityverbal = violence.10:03
sivangmdz: here now10:03
JaneWdepends how many on-line ppl want to listen in10:03
fabbioneso we can kill each other10:03
fabbione:)10:03
infinityWhich is fine, so long as I make sure I'm not blocking anyone by then.10:03
fabbioneinfinity: ++10:03
BurgundaviaJaneW, please keep it online10:03
sivangah bad, too late ..:-/10:03
mvoverbal has the disadvantage that external people can't follow it 10:03
infinityPoint.10:03
dholbachi think we'll have quite a lot of verbal interaction anyway :)10:04
=== pitti imagines 15 people sitting next to each other and talking over IRC - funny
JaneWBurgundavia: I am happy to means I can  cut 'n paste - less typing for me!10:04
ogra_ibookwhy keeping it online, the reports are public10:04
infinityOnline also makes it easier to hack in the background when you're not the focus of attention. :)10:04
Kamionverbal+minutes is fine too, but I think the minuter would be somewhat overloaded with the volume of information in a distro team meeting10:04
infinityIt's like two hours for the price of one!10:04
Mithrandirverbal with paintball guns sounds good.  So you shoot people if they block you and stuff.10:04
Kamionogra_ibook: the conversation's useful too ...10:04
Seveaspitti, we sort of had that on the Ubuntu NL spurt, but with 7 people ;)10:04
JaneWpitti: we do that normally anyway!10:04
KamionMithrandir++10:04
=== fabbione will take his cluebat in London
pittiJaneW: I don't :)10:04
ogra_ibookKamion, true ...10:05
=== JaneW will take rubber rocket with elastic launcher...
dholbachguys, you are agressive - didn't you have time to relax?10:05
mvoHUG DAY!10:05
pittiMithrandir: you should keep them alive enough for them to be able to finish the stuff you wait for10:05
dholbachtsssss10:05
Mithrandirpitti: paintballs don't kill.  They just hurt.10:05
=== Mez [n=Mez@ubuntu/member/mez] has joined #ubuntu-meeting
=== infinity [n=adconrad@203-214-4-60.dyn.iinet.net.au] has left #ubuntu-meeting []
pittiJaneW: 'rubber rocket', I see. The Orion shop calls them a bit differently :)10:06
JaneWLOL10:06
sivangJaneW: Thank you for reporting for me, in my absence :)10:06
pittiJaneW: anyway, 10am is probably sane, after the initial talks and tea10:06
dholbachJaneW: i was reminded on sabdfl's latex lotion the moment you talked about it ;)10:06
=== sivang thought everybody forgot about that already :)
ajmitchdholbach: hehe :)10:07
sivangah ah10:07
pittiok, back to work. thanks to everybody10:07
=== pitti [n=pitti@ubuntu/member/pitti] has left #ubuntu-meeting ["Ex-Chat"]
JaneWbye10:07
=== sivang goes to read scrollback
JaneWpitti: what's ENOTIME?10:07
MithrandirJaneW: no time available10:08
mvoJaneW: it just means Error No Time10:08
JaneWoic, I was thininking 'not enough time' or suchlike10:08
Kamionpretty much the same10:08
dholbachJaneW: E<BOLDLETTERS> are usually made up "error messages" :)10:08
JaneWta10:08
Kamion(or real libc error codes, sometimes ...)10:08
Kamion(e.g. my house is ENOSPC)10:09
JaneWEFNF10:09
=== nomed [n=debaser@host82-194.pool8254.interbusiness.it] has left #ubuntu-meeting ["Leaving"]
=== vincent_ [n=vincent@85.69.101.91] has left #ubuntu-meeting ["Ex-Chat"]
=== jane_ [n=JaneW@dsl-146-165-158.telkomadsl.co.za] has joined #ubuntu-meeting
=== klepas [n=klepas@203-213-31-142.static.tpgi.com.au] has joined #ubuntu-meeting
=== Hobbsee [n=Hobbsee@CPE-144-136-118-222.nsw.bigpond.net.au] has joined #ubuntu-meeting
=== highvoltage [n=Jono@196.36.161.235] has joined #ubuntu-meeting
=== highvoltage [n=Jono@196.36.161.235] has joined #ubuntu-meeting
=== Hobbsee [n=Hobbsee@CPE-144-136-118-222.nsw.bigpond.net.au] has left #ubuntu-meeting ["So]
=== klepas_away [n=klepas@203-213-31-142.static.tpgi.com.au] has joined #ubuntu-meeting
=== Lathiat [i=lathiat@ubuntu/member/lathiat] has joined #ubuntu-meeting
=== azeem [n=mbanck@host45.natpool.mwn.de] has joined #ubuntu-meeting
=== Kyral [n=kyral@ubuntu/member/kyral] has joined #ubuntu-meeting
=== artnay_ [i=artnay@hdr.unk.fi] has joined #ubuntu-meeting
=== fabbione [i=fabbione@gordian.fabbione.net] has joined #ubuntu-meeting
=== JanC [n=janc@lugwv/member/JanC] has joined #ubuntu-meeting
=== shawarma [n=sh@3E6B503C.rev.stofanet.dk] has joined #ubuntu-meeting
=== lucasd [n=lucas@200.209.160.119] has joined #ubuntu-meeting
=== ealden [n=ealden@219.90.91.195] has joined #ubuntu-meeting
=== Simira [n=rpGirl@118.84-48-121.nextgentel.com] has joined #ubuntu-meeting
=== doko_ [n=doko@dslb-084-059-088-045.pools.arcor-ip.net] has joined #ubuntu-meeting
=== dholbach [n=daniel@ubuntu/member/dholbach] has joined #ubuntu-meeting
=== ealden [n=ealden@219.90.91.195] has joined #ubuntu-meeting
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-meeting
=== lamont [n=lamont@mib.fc.hp.com] has joined #ubuntu-meeting
=== jsgotangco [n=jsg@host-202-163-240-162.dhcp.infocom.ph] has joined #ubuntu-meeting
=== lucasd [n=lucas@200.209.160.94] has joined #ubuntu-meeting
=== ogra [n=ogra@ubuntu/member/ogra] has joined #ubuntu-meeting
=== ogra_ibook [n=ogra@ubuntu/member/ogra] has joined #ubuntu-meeting
=== Yagisan [n=jamie@60-240-125-87.tpgi.com.au] has joined #ubuntu-meeting
=== ealden [n=ealden@203.76.228.68] has joined #ubuntu-meeting
=== kjcole [n=kjcole@pchb1f.gallaudet.edu] has joined #ubuntu-meeting
=== lamont [n=lamont@mib.fc.hp.com] has joined #ubuntu-meeting
=== lamont [n=lamont@mib.fc.hp.com] has joined #ubuntu-meeting
=== cyphase [n=cyphase@adsl-68-125-50-225.dsl.pltn13.pacbell.net] has joined #ubuntu-meeting
=== ealden [n=ealden@ipdial-167-90.tri-isys.com] has joined #ubuntu-meeting
=== seb128_ [n=seb128@ANancy-151-1-58-107.w83-196.abo.wanadoo.fr] has joined #ubuntu-meeting
=== lucasd [n=lucas@200.209.160.94] has joined #ubuntu-meeting
=== Seveas [n=seveas@ubuntu/member/seveas] has joined #ubuntu-meeting
=== lucasd [n=lucas@200.209.160.94] has joined #ubuntu-meeting
=== lguerra [n=lguerra@200.21.93.196] has joined #ubuntu-meeting
=== lguerra is now known as lguerra_ya_vuelv
=== Treenaks [n=martijn@thuis.foodfight.org] has joined #ubuntu-meeting
=== lguerra_ya_vuelv is now known as lguerra
=== lucas [n=lucas@ubuntu/member/lucas] has joined #ubuntu-meeting
=== LaserJock [n=LaserJoc@ubuntu/member/laserjock] has joined #ubuntu-meeting
=== Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has joined #ubuntu-meeting
=== ajmitch [i=ajmitch@port162-39.ubs.maxnet.co.nz] has joined #ubuntu-meeting
=== uniq [n=frode@213.184.199.55] has joined #ubuntu-meeting
=== sistpoty [n=sistpoty@ubuntu/member/sistpoty] has joined #ubuntu-meeting
=== Gloubiboulga [n=gauvain@84.5.64.26] has joined #ubuntu-meeting
=== chninkel [n=yann@alcyone.pleiades.fr.eu.org] has joined #ubuntu-meeting
=== lucas [n=lucas@ubuntu/member/lucas] has joined #ubuntu-meeting
\shevening gentlemen08:56
LaserJockhi \sh08:56
sistpotyhiho08:57
lucasdhello :)08:57
lucashello08:57
=== crimsun [i=crimsun@pdpc/supporter/silver/crimsun] has joined #ubuntu-meeting
lucasShould I announce the meeting on #ubuntu-motu and #ubuntu-devel ?08:58
raphinkhop08:58
raphinkhi guys :)08:58
dholbachhello08:59
sistpotyhey dholbach08:59
raphink:)08:59
chninkelhi08:59
dholbachlucas: yeah, although #ubuntu-motu should be aware of it :)08:59
raphinkhopefully09:00
=== nlindblad [n=nlindbla@user179.217-10-120.netatonce.net] has joined #ubuntu-meeting
=== tvo [n=tobi@5354EA9B.cable.casema.nl] has joined #ubuntu-meeting
sistpotydo we want to start?09:00
\shit's 20:00 UTC...welcome ladies and gentlemen09:00
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-meeting
zulheylo09:00
ogra_ibook:)09:00
sistpotyhey ogra_ibook09:00
raphinkhi ogra_ibook 09:01
raphinkhi zul 09:01
sistpotyok, anyone volunteering to do the minutes?09:01
lucas* silence *09:01
raphink* more silence *09:02
Riddelllike a Quaker meeting this09:02
raphinkhi Riddell 09:02
\shsistpoty: i'll do it when it's ok if I send later this week :)09:02
sistpotycool, thx \sh09:02
sistpotylet's start with discussion... who made the first point /usr/share/common-licenses/GPL vs /usr/share/common-licenses/GPL-2?09:03
siretarthu folks09:03
sistpotyhi siretart09:03
=== janimo [n=jani@Home03207.cluj.astral.ro] has joined #ubuntu-meeting
raphinkI did sistpoty 09:03
Riddellstart with names no?09:03
sistpotythen go ahead, raphink ;)09:03
\shyes09:03
\shplease state your names09:03
=== sistpoty is StefanPotyra
=== dholbach is Daniel Holbach
=== \sh is Stephan Hermann
=== crimsun is Daniel Chen
=== chninkel is Yann Rouillard
=== raphink is Raphael Pinson
=== LaserJock is Jordan Mantha
=== janimo is Jani Monoses
=== lucasd is Lucas Duailibe
=== Riddell is Jonathan Riddell
=== lucas is Lucas Nussbaum (LP: nussbaum)
=== zul is Charles Short
=== ogra_ibook is ogra on th eibook :)
dholbachwow, full house09:04
sistpoty:)09:04
=== siretart is Reinhard Tartler
=== Mithrandir is Tollef Fog Heen, but not really present
lucaslrwxrwxrwx 1 root root     5 2005-10-02 23:23 GPL -> GPL-209:04
lucas-rw-r--r-- 1 root root 17989 2005-06-16 16:32 GPL-209:04
lucaswhat do you suggest, raphink ?09:05
raphinkthe first poing comes from some talks on #ubuntu-motu about the license link in debian/copyright. This seems like a small issue but not everbody seem to have tyhe same opinion of it. I looked in Policy for this and found only notices about the GPL file, not GPL-209:05
raphinkso it seems like GPL is a link to the latest version of GPL, currently GPL-209:05
raphinkI wanted to point that out since many seem to belive that packages licensed under "GPL v2 or later" should point to GPL-209:05
raphinkthis doesn't matter so much now09:05
raphinkbut GPL-3 is to be out in a matter of months, if not weeks now09:06
=== lucas thinks we should leave Debian decide about this, since changing this requires changing a lot of packages
raphinkso we'd better have clear policy on this link in copyright imo09:06
lucasGPL v3 won't be released before a year or so09:06
lucasit's only the reviewing process that starts next monday09:06
raphinklucas : my point was mainly about REVU so far since we also release new packages ;)09:06
=== siretart also agrees with lucas that this discussion should be rather rised on debian-devel
raphinkok09:07
raphink:)09:07
ogra_ibooki think it should be rised at the TB09:07
sistpotyogra_ibook++09:07
raphinkok09:07
raphinknext week then ;)09:07
dholbachyeah, i agree with ogra09:07
ogra_ibookput it on the agenda there :)09:07
siretarteven better :)09:08
Riddellare we under disagreement?09:08
\shwell...09:08
crimsunif in doubt we should be consulting /usr/share/doc/$foo/copyright anyhow, but yes, the issue's one for the TB (though we should try and minimize deviation from Debian)09:08
\shI'm not convinced about this paragraph:09:08
\shEach version of the License is given a distinguishing version09:08
\shnumber. If the Document specifies that a particular numbered version09:08
\shof this License "or any later version" applies to it, you have the09:08
\shoption of following the terms and conditions either of that specified09:08
\shversion or of any later version that has been published (not as a09:08
\shdraft) by the Free Software Foundation.09:08
=== claud1 [n=claude@151.87.79.83.cust.bluewin.ch] has joined #ubuntu-meeting
crimsunerr, not /usr/share/doc/$foo/copyright but COPYING in the source09:08
raphinkhmm09:08
lucas\sh: what do you mean by "not convinced" ?09:09
raphinkdo I had it to the TB agenda ?09:09
raphinks/had/add/09:09
\shlucas: it gives upstream a choice 09:09
lucasbasically, a package stating GPLv2 or later should point to GPL, while a package stating GPLv2 should point to GPL-209:09
ogra_ibookraphink, thats the way to get it to the TB09:10
sistpoty\sh: imo it also gives distributors a choice, but IANAL09:10
lucas\sh: it gives the user or the distributor a choice09:10
\shlucas: to say: only GPLv2 or "later == GPLv3"09:10
Riddelldoes anyone disagree with use GPL-2 for programs that are strictly GPL 2 and use GPL symlink for programs that are GPL 2 or later?09:10
ogra_ibookraphink, i dont think its a MOTU specific issue ...09:10
\shsistpoty: well...the debian/dir is licensed by the maintainer in my POV09:10
raphinkindeed ogra_ibook 09:10
sistpotygood point \sh09:10
sistpotybut let's defer that to TB and move on... agreed?09:10
crimsunRiddell: I don't disagree, but it's a matter for the TB09:10
\shso we have to deal with two license issues here09:10
siretartnext!09:11
\shsistpoty: agreed :)09:11
ogra_ibook\sh, nope, we dont09:11
sistpotyok, next point are the todo's doko_ has for us...09:11
\shogra_ibook: to go on :()09:11
ogra_ibook\sh, the whole distro has ;)09:11
sistpotyhehe09:11
raphinkhuhu09:12
sistpotythey are basically 1) packages still depending on libstdc++5 (gcc-3.3)09:12
sistpotywhich ftbfs09:12
sistpotyI once started a wiki page MOTUStdc++-transition...09:12
dholbachhow is the status there? how much is left?09:12
sistpotybut I don't know about the current state of these09:12
\shsistpoty: vn4 / im-sdk are not gcc4 compatible somehow09:13
sistpoty\sh: we need at least g++-3.409:13
siretartsistpoty: please allow me a foolish question: why do packages build depending on gcc-3.3 ftbfs?09:13
siretartI mean why still have gcc-3.3 around!09:13
\shsistpoty: i think the page is broken..when I looked only 1 or 2 packages were left...and then we recevied again a mail from doko..so I have a look09:13
sistpotysiretart: obviously they don't b-d on gcc-3.3, but didn't get ever rebult09:13
siretartah. I see09:14
sistpotydoko_: reading this?09:14
\shsiretart: because it was the time in breezy, when not all packages were tested to be build with gcc-3.4/4.009:14
raphinksistpoty: so then? how is it a work for MOTU to rebuild them ? 09:14
lucasso it's just about uploading a -1build1 version so they gets rebuilt ?09:14
siretartsistpoty: so can we assume that all those FTBFS do also apply in debian?09:14
sistpoty\sh: I'm not quite clear (in his mail, doko_ wrote, that the lists are rebuilt daily, but I don't think they are)09:14
sistpotylucas: no09:15
raphinkwhat has to be done with these packages then?09:15
sistpotyraphink, lucas: they ftbfs... we need to make them build again09:15
siretartlucas: they most probably where tried to be rebuild but failed09:15
lucasok09:15
\shlucas: definetly not :)09:15
raphinkk09:15
sistpotyiirc they where all uloaded with -nbuildx09:15
\shand one of the biggest problem with this is, some packages are not well maintained anymore09:15
lucasso this item can be merged with the FTBFS check later ;)09:15
sistpotylucas: it could, but should at least get some attention now09:16
sistpotyI tried some packages, but they are horribly broken, so we might want to check for a new upstream version09:16
dholbachyeah, upstream versions asap :)09:16
raphinkok09:16
raphinkfor each of them?09:17
dholbachonly if it helps and it is feasible09:17
raphinkok09:17
sistpotyraphink: if it makes them compile ;)09:17
dholbachsome upstreams have stopped working too, i fear09:17
\shraphink: try to build them first with actuall toolchain, if this is not working out, try gcc-3.4 and if this is not working new upstream check and try to build it :)09:17
dholbachuvf is in one week09:17
\shs/actuall/actual/09:17
dholbachwe will have exceptions, but not too many09:18
raphinkyep \sh understood :)09:18
sistpotyhow do we want to handle these packages? try again with the wiki-page?09:18
crimsunif you come across mythtv, discard it. I'm pulling from -fixes svn branch to make it build with g++-4.0.09:18
sistpotys/handle/organize handlinge/09:18
siretartsistpoty: they aren't that many, I think a wiki page might be feasible in this case (and you know how much I hate wikis for that!)09:18
sistpotycrimsun: bah... I'm just about to fix mythplugins... 09:18
\shwell, I can take the new allocator transition list 09:18
sistpoty\sh: they seem to be ftbfs-candidates as well09:19
siretartsistpoty: and mythtv needs a lot of love, it is currently orphaned :(09:19
\shsistpoty: doesn't matter...but most of hte packages don't need a rename because they're apps :)09:19
dholbachi think for the following week we should concentrate on updating/merging where we need it - what do you guys think?09:19
sistpotydholbach++09:20
raphink+1 dholbach 09:20
raphinksome guys will shout on REVU that their packages are not being reviewed ;)09:20
dholbachif there are fixes we can get from cvs, we should get them in too09:20
\shwell..merging/updating/new apps are prio 1 i think until the 19th09:20
dholbachraphink: NEW packages have time until feature freeze (= Feb 23)09:20
raphinkdholbach: what exactly is frozen on 19th then?09:21
lucascan't we postpone UVF for universe ?09:21
dholbachnew upstream versions09:21
\shlucas: no09:21
dholbachthe spec explicitly say no09:21
crimsunlucas: no, that was a huge issue last release09:21
siretartlucas: we have UVF for a reason09:21
sistpotyok, seems like we are already moving to the next point on the agenda... uvf for universe09:21
\shlucas: we decided at ubz to go with the release schedule this time more strictly09:21
lucasraphink: MoM stops working, so new packages in Debian don't get imported into Ubuntu09:22
sistpotydholbach: do you know if mom will be running until the last day of UVF?09:22
dholbachsistpoty: we should Keybuk about that09:22
dholbachi think it'll have to be fixed for Malone09:22
dholbachalthough... that doesn't matter for universe09:22
dholbachforget what i said09:22
\shdholbach: well...for universe it never filed any bugs in bugzilla :) so we don't need a fix :) right now09:22
dholbachwe should kindly ask him09:22
sistpotydholbach: if it *is* running till the last day, we definitely won't be able to "hand"-merge last runs packages09:23
dholbachwe can just talk to him09:23
\shactually for the remaining merges we have time to the 2nd of February09:23
\shhttps://wiki.ubuntu.com/DapperReleaseSchedule09:23
raphinkso on the 19th automatic merges stop09:23
raphinkbut we keep merging manually till the 2nd of feb ?09:24
\shraphink: there are no automatic merges :)09:24
raphinkright?09:24
siretartand hey, UVF is not the end of the world. if you can show that a new version from debian fixes some important problem, we can still sync it09:24
sistpotyah, good to know \sh09:24
\shraphink: only mom stops...and we have to stop on the 2nd09:24
raphink\sh: I mean syncs09:24
lucasraphink: right09:24
siretartbut we won't focus on merging anymore. we focus on bugfixing. of a bug can be fixed by a sync, even better!09:24
\shraphink: the auto sync robot is stopping, MoM is not running anymore09:24
sistpotyok, how will we handle uvf-exceptions? 09:25
raphinkyep got that :)09:25
sistpotysame as last year: get dholbach's or ogra_ibook's ok?09:25
raphinkand we only sync as manual requests if syncs fix bugs09:25
\shsistpoty: I think the same way as we handle it in main..ask mdz or kamion 09:25
siretartsistpoty: I propose the same procedure as with breezy09:25
sistpotys/last year/breezy/ 09:25
sistpotysiretart++09:25
=== dsas [n=dean@host86-129-20-159.range86-129.btcentralplus.com] has joined #ubuntu-meeting
siretartsistpoty: ogra appointed 2 or 3 delegates who proxied/approved sync requests09:25
dholbachi think they will have better things to do09:25
dholbachwe should raise the topic in the TB meeting09:26
siretartyes09:26
ogra_ibooksistpoty, there was a documment anywhere on the wiki from the UBZ BOF where its outlined09:26
\shdholbach: we should :) 09:26
dholbachsince this was not explicitly mentioned in the spec09:26
ogra_ibookdholbach, it was mentioned09:26
ogra_ibookKamion showed me the part09:26
dholbachogra_ibook: who approves exceptions?09:26
ogra_ibookas it sounded there should be no exceptions ... 09:27
\shogra_ibook: 09:27
\shWe have found in the past that newer universe packages tend to demand newer dependencies in main. Accordingly, universe will enter UpstreamVersionFreeze at the same time as main, in order to reduce dependency tension between newer versions of packages in main and universe. The exact details of sync and merge schedules will be the decision of the MOTU team. As in main, syncs and merges to universe after UVF must be verified to build and in09:27
\shanted for new or updated dependencies).09:27
ogra_ibookapart from that it will be as in all releases before, Kamion and mdz i think09:27
dholbachogra_ibook: you're wrong09:27
\shhttps://wiki.ubuntu.com/DapperReleaseProcess09:27
dholbach"no exceptions" is wrong.09:27
siretartogra_ibook: come on, we will need exceptions, if we don't want to diverge totally!09:27
ogra_ibooksiretart, sure09:27
dholbachJan 06 13:50:53 Kamion        dholbach: https://wiki.ubuntu.com/DapperReleaseProcess explicitly contradicts that, but we'll be flexible with exceptions for universe09:28
ogra_ibooksiretart, but at a very minimal base as i understand the above \sh just pasted09:28
dholbachthere you go09:28
crimsunwell, since we need a decision, how do dholbach and \sh feel about being the proxies? (Don't mean to exclude ogra, but I presume he'll be busy with Edubuntu)09:28
dholbachcrimsun: let's raise the topic at the TB09:28
\shthe biggest problem is "new dependencies in main for universe packages" this we should avoid...for universe itself, we can get it straight, and we can discuss it with mdz/kamion 09:28
dholbachand sort out the process explicitly09:28
=== siretart would volunteer again for proxying
lucaswhat do we do regarding REVU ?09:28
ogra_ibookyou can abuse me after feature freeze again ... i'll have more time then :)09:29
lucaswe just stop uploading packages on the 19th ?09:29
=== \sh is not volunteering because I don't know if i'm still there then :) (means online)
ogra_ibooklucas, new versions, yes09:29
ogra_ibooklucas, exceptions need approval and extra review09:29
lucas(this would lower the pressure on the MOTUs and let them concentrate on bugfixing)09:29
crimsundholbach: certainly; it would be nice to say "here are our proxies" when approved09:29
lucasogra_ibook: totally new packages are no longer accepted ?09:30
siretartI'd really require a malone bugnr for each exception this time09:30
raphinkogra_ibook: I understnad new packages are not considered new versions ?09:30
dholbachlucas: https://wiki.ubuntu.com/DapperReleaseProcess09:30
dholbachFeature Freeze is the date09:30
sistpotydo we have an agreement for exceptions already?09:31
crimsunraphink: right, 1.2.3-(X+1) is fine, but 1.2.(Y+1)-X is not09:31
ogra_ibooksistpoty, TB09:31
sistpotyok09:31
raphinkbetween UVF and FF, we keep getting new packages in, but not getting new versions of existing packages from Debian, alright?09:31
siretartfrom DapperReleaseProcess: The exact details of sync and merge schedules will be the decision of the MOTU team.09:31
\shregarding new packages: this paragraph is important09:31
\shSince entirely new packages in universe are relatively safe and attract a number of new developers, they will be liberally admitted until FeatureFreeze if they do not require additional or newer dependencies.09:31
raphinkcrimsun: I guess unless Y=-109:31
raphinkok09:32
raphink:)09:32
raphinkso REVU is still up till FF09:32
dholbach"new versions" are cumbersome09:32
siretartyes09:32
sistpoty\sh: ok, then we can defer the point "packages on revu" (I have already some thoughts about it, but let's defer this)09:32
dholbachyou can always pack a 3MB patch in debian/patches09:32
\shdholbach: go away :)09:32
raphinklol09:33
ogra_ibookdholbach, i was told that nobody will approve that anymore in breezy :)09:33
dholbachso try to have this in mind, we really want minimal changes :)09:33
crimsunthat way madness lies (cf. vlc)09:33
LaserJocknext item?09:33
dholbachyeah :)09:33
sistpotyLaserJock++09:33
lucasok, I think the topic was covered. Shall we move on to FTBFS packages ?09:33
siretartso, did we agree on the proxies yet?09:33
raphinkyep09:33
siretartplease repeat them09:34
=== freemanen [n=freemane@c83-248-210-247.bredband.comhem.se] has joined #ubuntu-meeting
sistpotysiretart: deferred to TB, as I understood it09:34
\shsiretart: TB ... and remove me from the list :)09:34
siretartsorry, please not the TB09:34
ogra_ibooksistpoty, the called proxies were \sh and dholbach 09:34
siretartwe should at least make proposals for the TB09:34
lucaswho is in charge of forwarding items to the TB ?09:34
\shogra_ibook: the called proxies were siretart and dholbach09:34
ogra_ibookbut to get the right conact people we said TB09:34
ogra_ibook\sh, and you :)09:34
raphinkTB is on 17th right?09:35
\shogra_ibook: no...because of the private matters09:35
lucas15th I think09:35
lucasbut not sure09:35
=== raphink checks
siretartogra_ibook: \sh doesn volunteer, and me alone is crazy09:35
siretartogra_ibook: I'd propose sistpoty as proxy09:35
lucasah no 1709:35
dholbachi trust enough in siretart, sistpoty and slomo_ to have them decide too09:35
\shogra_ibook: right now, I'm more a SPoF09:35
siretartand slomo, right09:35
raphink;)09:35
ogra_ibookdholbach++09:35
raphinklucas: better for you to know and not miss it ;)09:35
lucas:)09:36
dholbachcrimsun too09:36
raphink;)09:36
ogra_ibookdholbach++09:36
dholbachbut we should decide on the number of people proxying in the TB meeting09:36
ogra_ibook:)09:36
siretartyay for crimsun! :)09:36
dholbachand see how well we do09:36
=== dholbach hugs crimsun
sistpotyyay for crimsun from /me as well09:36
sistpotyprobably ajmitch for nightly changes?09:36
=== \sh can play the replacement proxy when there is a chance
lucasyeah, I was about to say that TZ problems should be considered09:37
\shbut I wouldn't count on that09:37
ogra_ibookhow many did we have in breezy ? 3 ? 5 ?09:37
siretartogra_ibook: too few09:37
\shogra_ibook: 4 or 5 ... you dholbach siretart I and ?09:37
ogra_ibooklucas, you can cover TZ shifts on the ML :)09:37
ogra_ibooki think ajmitch too09:38
lucastrue09:38
ogra_ibookand crimsun09:38
siretartok, so I count 4 + 2 proxies, which need approval by TB, yes?09:38
ogra_ibookso we were at least 5 09:38
dholbachwe need elmo to sync (or maybe to do approvals), let's raise the issue at the TB09:38
dholbachwe can still decide  then09:38
ogra_ibookyuo09:39
siretartok09:39
ogra_ibookerr yup09:39
sistpotynext item?09:39
ogra_ibookelmo also need the list ...09:39
lucasok, packages that FTBFS (fail to build from source)09:39
lucaswho will do the mass testing ? how ? (pbuilder ?)09:39
\shupcoming todos09:39
sistpotylucas: not so fast...09:39
lucasah09:39
lucassorry09:39
lucasmissed 2 items :-)09:39
dholbachlucas: test rebuild on the buildds?09:40
lucasthe buildd don't pbuild09:40
dholbachwe can infinity to do this09:40
\shso....bug fixing, unmet deps are the most common workloads these days after uvf 09:40
dholbachthey sbuild, yes09:40
sistpotyok, well I named the point "upcoming todo's" to try to list what should be our next priorities after uvf09:40
siretartdholbach: yes, we should ask lamont for that. but earlier than for breezy!09:40
dholbachsiretart: absolutely, of infinity rather09:40
elmoeh?09:40
\shftbfs issues we can sort out with infinity/lamont and their "testbuilds of the universe"09:40
elmowhat are you guys talking about WRT me?09:40
ogra_ibookelmo, uvf exception handling09:41
ogra_ibookelmo, and who is your MOTU contact to approve stuff09:41
siretartelmo: we agreed on proxies who are allowed to request syncs after UVF && FF from you09:41
elmooh, ok, fine09:42
LaserJockI hate to be a pain but I gotta leave in 3 min. is there anything needing I or MOTUScience team? 09:42
sistpotyLaserJock: from the agenda, nothing science-specific09:42
sistpotyLaserJock: for the rest you can read the irc-logs or the minutes (once they are there)09:42
LaserJockI just wondered about the LP team item09:43
sistpotyok, back to "what's priorities after uvf"09:43
ogra_ibookbugs09:43
sistpotyI guess one of the big priorities should also be reviewing packages... then we have unmet deps and bugs09:43
dholbachnew packages09:43
dholbachyeah09:44
ogra_ibookas its for main 09:44
dholbachi'll do the apt-get.org import as well :/09:44
=== freemanen [n=freemane@c83-248-210-247.bredband.comhem.se] has left #ubuntu-meeting ["Konversation]
dholbachbut bugs, of course09:44
dholbachthe more the better09:44
dholbachwe have a *bunch* piled up on launchpad09:44
sistpotyok, for unmet deps, ajmitch wanted to write some stuff iirc... hopefully we'll have some webtool for it as well09:44
raphinkhehe09:45
siretartsistpoty: I have this: http://tiber.tauware.de/~siretart/unmet/09:45
sistpotyah, yes, I forgot ;)09:45
lucaswhich kind of deps ? build-deps ?09:45
siretartlucas: no, binary dependencies09:45
\shok...can we agree on "prio 1) bugs, prio 2) unmet deps prio 3) poke buildd when it's necessary to rebuild universe?"09:46
siretartlucas: basically the output of apt-cache -i unmet09:46
sistpoty\sh: and 4) reviewing new packages09:46
\shsistpoty: ok..that whould be 1b)09:46
\shnot 409:46
siretart\sh: 3 does not necessarily block human ressources. I think it should be started quite quickly09:46
raphinkhehe09:47
sistpotysiretart: you might want to talk to ajmitch, he said s.th. bout britney ;)09:47
lucaswe could run piuparts on the whole universe09:47
\shsiretart: yepp...09:47
dholbachif we all concentrate on a review day, we can achieve quite much09:47
lucasthis would catch them all09:47
sistpotylucas: catch what?09:47
raphinkyep I think so09:47
lucasmissing deps09:47
raphinkif we do better than last time ;)09:47
lucaspackages that don't install etc09:48
=== byteunix [n=byteunix@200.223.10.10] has joined #ubuntu-meeting
=== allee [n=ach@allee.exgal.mpe.mpg.de] has joined #ubuntu-meeting
sistpotywe might do many things, if s.o. volunteers ;)09:48
raphink:)09:49
sistpotyok, next item?09:49
lucasmaybe there are some plans for this on the ubuntu scale09:49
lucasnot MOTU09:49
lucaswe should ask in TB09:49
sistpotyoh, sorry, I forgot another important point that falls under "TODO"09:49
\shlucas: what plans?09:49
lucasplans for pbuilder builds + piuparts runs09:49
dholbachsistpoty: fire away09:50
sistpotypoint is: soyuz...09:50
\shlucas: hmmm..if, then it will be soyuz :) and buildd integration in launchpad :)09:50
sistpotywill it come, when, what will change, are we going to die?09:50
lucas\sh: I'm talking about dapper09:50
\shsistpoty: dapper +1 :) 09:51
lucasnot dapper+x ;)09:51
\shlucas: I don't think infinity will deal now with pbuilder :) 09:51
lucasI'll take care of the issue with infinity and the TB09:51
sistpoty\sh: ah, good to know... thought I heard some rumors of soyuz being available very next days :)09:51
siretartsistpoty: we are definitly going to die, except the immortals ;) - but hopefully not related to ubuntu work 09:51
sistpotyhehe09:51
lucasI'm interested in providing CPU power too anyway09:51
ogra_ibooklucas, for unmet deps, get familiar with germinate ...09:52
\shsistpoty: well...it could be as well a release cycle like "hurd" :)09:52
lucaspiuparts catches much more than germinate09:52
sistpoty\sh: or longwait?09:52
raphink\sh: you mean 1.0 is released in 20 years ?09:52
\shASK #launchpad :)09:53
sistpotyok, I guess we're getting offtopic... let's move on to next point?09:53
dholbach:)09:53
raphinksistpoty: yep09:53
siretartMOTU Team Reorg?09:53
\shok..lp motu teams reorg09:53
sistpotylucas: your stage ;)09:53
lucasThere is currently a high number of MOTU-related teams on Launchpad. I proposed a new organization on https://wiki.ubuntu.com/MOTUMeetingTeamReorg which (I think) makes it easier to understand and use. Please read the wikipage and comment.09:53
\shah well..09:54
\shthe blue teams: members of the blue teams don't need to be members of MOTU09:55
\sheveryone is normally allowed to enter :)09:55
lucasthere are no members of MOTU09:55
\shactually for MOTUIM :)09:55
lucasexcept the owner + teams09:55
raphinklucas : then the "normal" MOTUs are in Ubuntu-dev only?09:55
lucasyes09:55
\shno09:55
\shubuntu-dev means only people with universe upload rights09:56
raphink\sh: according to the scheme I mean09:56
lucas\sh: elaborate09:56
lucasok, so some people with universe upload rights are not MOTUs ?09:56
lucas(that was my question on the list)09:56
\shlucas: yes09:56
\shlucas: every core dev has universe upload rights, but is not always a MOTU, neither interested in MOTU09:57
raphinkyou have to be a dev to be a MOTU09:57
raphinkbut being a dev doesn't make you a MOTU09:57
\shraphink: no..09:57
lucasok09:57
raphinkright?09:57
raphink...09:57
lucas\sh: who are MOTUs then ?09:57
\shubuntu-dev means only "universe upload rights"...09:57
raphinkyes09:57
ogra_ibookubuntu-core-dev is a member of ubuntu-dev 09:58
raphinkand I mean MOTUs are necessarily ubuntu-dev 09:58
raphinks09:58
ogra_ibookubuntu-dev includes all MOTUs09:58
\shlucas: MOTUs is a bunch of people who wants to work on the universe repos and/or working on the distro as volunteer...they can go further with universe uploads rights, but they don't have to09:58
raphinkso among ubuntu-dev you have MOTUs, ubuntu-core-dev and others09:58
ogra_ibook\sh, nope09:58
ogra_ibook\sh, a MOTU is approved to upload09:58
\shogra_ibook: no :) MOTUs includes all ubuntu-devs...but MOTUs are more ( regarding the team lists)09:59
raphinkhmm09:59
ogra_ibook\sh, i was there when we wrote the definition09:59
=== sistpoty is confused
raphinkdo MOTUs belong to ubuntu-dev or ubuntu-dev belong to MOTUs ? ;)09:59
ogra_ibook\sh, MOTUs are all memebers of ubuntu-dev09:59
\shogra_ibook: in my POV MOTUs are Hopefuls + ubuntu-devs (reading the team names)09:59
raphinksistpoty: same here09:59
\shogra_ibook: not when I see the LP team list09:59
ogra_ibook\sh, nope, there are MOTUs and there are MOTU hopefuls10:00
ogra_ibookits ever been like this 10:00
raphinkadjime10:00
siretartogra_ibook: whats the difference between the lp group MOTU and ubuntu-dev? can't we merge them?10:01
lucasok, so how do we transpose this to LP teams ? :-)10:01
ogra_ibookand there is a definition somewhere in the wiki10:01
ogra_ibook...from the mataro conference10:01
siretartit causes much confusion10:01
\shogra_ibook: sorry...I was mistaken...what the lp teams are10:01
ogra_ibooksiretart, yes, we should10:01
sistpotysiretart++10:01
ogra_ibooksiretart, mdz didnt know about the exiatance of the MOTU launchpad group10:01
raphinkconfusing10:01
lucasogra_ibook: can you comment on the proposed scheme on https://wiki.ubuntu.com/MOTUMeetingTeamReorg ?10:02
ogra_ibookso he created ubuntu-dev, which is the official MOTU team now10:02
lucasI used the MOTU as a way to join MOTU Hopefuls and ubuntu-dev10:02
siretartogra_ibook: ubuntu-dev is used for upload permissions, MOTU is used for bug triage/management atm10:03
=== lucas realizes nobody read his wiki page despite the announcement sent to ubuntu-motu@ ;)
ogra_ibooksiretart, hmm, we should probably keep them distinct10:03
\shogra_ibook: and we left the MOTU team because of the -bug mail address right?10:03
ogra_ibookyup10:03
sistpotylucas: what is your rationale/use case behind this proposal?10:04
ogra_ibooki doubt the TB would be happy if we used ubuntu-dev for bugs etc10:04
siretartright10:04
siretartbecause main developers won't probably care that much about bugs in universe, I assume10:04
lucassistpoty: it seemed it matched what I understood from this complex stuff ;)10:04
ogra_ibooklucas, our policy for teams was always: everybody can join, it must be one MOTU and one point of contact in the team (they may be the same person) and teams organize themselves internally10:05
sistpotywhat do you want to achieve with this proposal?10:05
\shwell..what we want to achieve? seeing a team which is there because of managing upload rights, and a more theoretical team named MOTU which can be the mother of all MOTU* teams :) in a more practical way10:06
ogra_ibookto me it looks like you want to restrict access to cretain teams ...10:06
lucassistpoty: make things easier to understand from the user or potential MOTU Hopeful point of view10:06
ogra_ibook*certain10:06
lucasogra_ibook: ? my proposal is not about teams like MOTUScience, MOTURuby, etc10:07
sistpotylucas: I'm not quite sure if using lp team relations will be succesful in making things clearer 10:07
ogra_ibookTeams accepting direct members are in blue. All other teams have no direct members except owner/admins.10:07
sistpotylucas: instead of e.g. a wiki-page with some drawings like yours10:07
ogra_ibooklucas^^^10:07
lucasogra_ibook: yes, and ?10:07
lucasI never talked about team creation10:08
=== mvo [n=egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting
ogra_ibookwhy would you restrict reviewers or mergers ?10:08
=== raphink is subscribed to reviewers and mergers
lucasbecause we don't need them if everybody is in MOTU through inclusion relationships10:09
ogra_ibooki just wouldnt put up rules for mergers or reviewers ... 10:09
\shlucas: and people who are not team members of any team?10:09
janimoso can MOTUxxxxx teams have not-yet-motu members on launchpad?10:09
lucas\sh: they are MOTU Hopefuls10:09
siretartI think lucas proposal reflects reality better than the current situation in launchpad10:09
lucas\sh: which is blue, too10:09
ogra_ibookyes, everybody is a merger or reviewer in motu, why are there teams ? 10:09
\shlucas: well in the MOTU IM team I have someone, who is not even a motu hopeful, but wants to work on packages...10:10
sistpotyogra_ibook: for bug-mails10:10
ogra_ibooksistpoty, hmm, confusing10:10
sistpotyogra_ibook: and for grouping bugs... that were the primary reasons10:10
lucasogra_ibook: because you can assign a bug to motureviewers to mark it as 'I think it's ready, review needed'10:10
siretartogra_ibook: I think you have a point there. every ubuntu-dev should be a reviewer rather than every motu10:10
\shogra_ibook: to assign bugs towards those teams, that a mail is generated10:10
sistpotyogra_ibook: so that you can search for all bugs assigned to motu-merges (e.g.)10:11
lucas\sh: no problem, he is part of the MOTU 'galaxy' too10:11
\shlucas: if "MOTU galaxy" is the MOTU team , then no10:11
lucasMOTU IM is in blue, next to MOTU RUby ;)10:11
\shlucas: if you see it separated from the team view in LP then yes10:11
ogra_ibooksistpoty, yes, i understand, i just find the need for a full team page confsing10:11
lucas\sh: I don't understand what you mean10:11
ogra_ibookbut thats a LP limitation10:11
sistpotyunfortunately :(10:12
lucas\sh: with my proposal, MOTUIM is included in MOTU. So anybody in MOTUIM is also in MOTU10:12
\shlucas: the LP view is quite different from the idea of MOTU galaxy :) everybody who is bringing in patches to universe etc. belongs to the "MOTU galaxy" but they are not shown up in the LP team view of MOTU :)10:13
ogra_ibook"What about universe maintainers not willing to do MOTU work ?" 10:13
ogra_ibookwhat does this mean ? 10:13
siretartlucas: with your proposal, every bug assigned to MOTUReviewers would be assigned to ubuntu-dev and ubuntu-core-dev, too10:13
siretartlucas: so we would bother to many ppl with bugs we don't want them to bother10:13
lucasogra_ibook: ubuntu-dev members who don't do MOTU work10:13
ogra_ibooklucas \sh: with my proposal, MOTUIM is included in MOTU. So anybody in MOTUIM is also in MOTU10:13
lucassiretart: yup, what's exactly the point ogra just raised10:14
\shlucas: so ubuntu core dev :)10:14
ogra_ibook^^^that cant work10:14
lucasso maybe we need a 'MOTU Developers' team instead of ubuntu-dev10:14
ogra_ibooksince MOTUIM can have non MOTU members10:14
ogra_ibookas every team can10:14
lucasor MOTUWithUploadRights team ;)10:14
ogra_ibookyou would make them MOTU automatically10:14
raphinkloooool10:14
lucasogra_ibook: please read 'MOTU' on the diagram as 'MOTU galaxy'10:15
lucasif you prefer10:15
ogra_ibookno, please dont10:15
\shokokokok10:15
lucasif we :10:15
\shone moment...10:15
lucass/ubuntu-dev/MOTU/10:15
ogra_ibookcurrently you refer to the LP team 10:15
lucass/MOTU/MOTUGalaxy/10:15
lucason a diagram10:15
=== allee [n=ach@allee.exgal.mpe.mpg.de] has left #ubuntu-meeting ["Konversation]
lucaswould it be ok ?10:15
ogra_ibookand this should only contain approved MOTUs10:15
ogra_ibookthats even more confusing ...10:16
lucasok, so let's create a MOTU Galaxy team which includes all subteams10:16
siretartlucas: what do you gain from another team?10:16
lucassiretart: currently, there are members of all MOTU related teams10:16
ogra_ibookyes, thats what i'm asking as well here10:16
lucassome people are members of several teams10:16
\shtechnical solutions can't solve social problems10:16
lucaswhich is useless, etc10:16
=== raphink still doesn't see the point
lucasthere's a lot of redundancy10:16
ogra_ibookits just bringing up more confusion10:16
sistpoty\sh++10:16
ogra_ibooki'd keep the LP teams distinct ...10:16
lucasI'd just like a clean mapping of the reality to launchpad10:17
raphinkI don't see a pb with redundancy in teams10:17
\shso which view do you have: the social view of MOTU or the technical LP view of MOTU?10:17
raphinkI'm subscribed to ML that send me the same bugs three times10:17
raphinkand that's ok10:17
=== sistpoty agrees to ogra_ibook
raphinkredundancy in work or bugs or so can be a pb10:17
siretartwhat about breaking all inclusion relationsships in the MOTU Teams?10:17
raphinkbut in teams ... well I don't see the pb10:17
lucasMOTUIM is part of MOTU I think10:17
lucasthat's wrong, then10:17
lucasso we do no relationships between LP teams ?10:17
ogra_ibookyes10:17
\shlucas: no10:17
ogra_ibookMOTUIM is a team with at least one MOTU10:18
ogra_ibookbut its not member of MOTU as whole team10:18
lucasok, let's reject the item, and just say that our policy regarding LP is 'join as much teams you can' :-)10:19
\shlucas: there is no relation between the MOTUIM team and the MOTU team .. the only connection to the MOTU team is me (and nafallo, slomo) but nothing else...it10:19
ogra_ibooklucas, it isnt10:19
sistpotyI guess the policy is come to #ubuntu-motu and talk to people... 10:19
lucasah sorry10:19
lucasMOTURuby is member of MOTU10:20
ogra_ibooklucas, join the teams you like to work with is and was the policy10:20
lucasnot MOTUIM10:20
ogra_ibooknope10:20
ogra_ibookit cant10:20
lucaswhy is MOTURuby member of MOTU, and not MOTUIM ?10:20
lucasit is.10:20
lucashttps://launchpad.net/people/motu10:20
=== ogra_ibook removes
\shlucas: I'm in the ubuntu-dev team, because of the upload rights, I'm in the MOTU team, because I'm a MOTU and I'm team lead of MOTU IM...oh yes and the Kubuntu team 10:20
lucasok, so let's remove inclusion relationships between team10:21
lucass10:21
siretartany objections?10:21
siretartIt seems to reduce confusion10:21
sistpotyno objections... let's move to the next item10:21
ogra_ibookhmm who added the teams there ? 10:21
janimomaybe MOTU should be just the groups of people doing regular merges, transitions etc10:21
raphinkyeah next item :)10:21
siretartogra_ibook: confused ppl (like probably me)10:21
janimowhile the MOTUxxx groups usually care about one singel area and set of pacvkages10:22
lucasthat's me again10:22
\shnot me10:22
lucasnext or not next ?10:22
=== sistpoty keeps the spotlight focused on lucas
sistpotygo on10:22
lucasWe currently accept a lot of packages through REVU. After they are uploaded, the maintainer is free to totally forget about it and leave us maintain them. I'd like to raise two issues :10:22
lucas * Maybe we should find a way (writing a policy ?) to actually make REVU uploaders feel more responsible of what they upload in the long term.10:22
lucas * Maybe we should consider removing some of the 300+ universe packages that are not in Debian. What's the procedure for this ? (note that popcon.u.c is broken, so we can't determine which packages are actually used).10:22
ogra_ibooksiretart, heh10:23
\shlucas: why? 10:23
lucas\sh: why what ?10:23
\shlucas: ubuntu decided in the beginning not to have this maintainer thingy10:23
lucasok, but who cares about the packages ?10:23
lucasI know we are not doing security updates for universe10:23
siretartlucas: everyone and nobody, thats how universe works10:23
\shlucas: so actually I don't mind to touch packages which are not directly mine...but because they're in universe they're mine and yours and dholbachs and siretarts somehow10:23
ogra_ibooklucas, they disappear if nobody cares for them 10:24
lucasbut every ubuntu user adding universe potentially get lots of root holes ;)10:24
ogra_ibookthats normal evolution :)10:24
raphinkand if there is a new version in Deiban, it'll overwrite the package in universe anyway, which is likely to be for many of them since DDs are much more numerous10:24
lucasalso, since we don't check if packages still work, there might be a lot of broken packages in universe10:25
sistpotyapart from that most of the ppl. of revu hang around in -motu or can be reached by mail... so it's easy to do a "nmu": just ask10:25
siretartogra_ibook: uuh, I think the 'dissapear' part is worth another point on the agenda10:25
ogra_ibooksiretart, why ? thats what happens ... 10:25
lucassistpoty: I'm not concerned about packages which are actually used by a lot of users10:25
lucasI'm concerned about the invisible ones10:25
\shsiretart: if they disappear from debian, they disappear from ubuntu at some very special time...10:25
lucaspotentially broken, or with security issues10:26
ogra_ibooksiretart, if nobody cares for them, they'll not survive a transition etc10:26
\shlucas: e.g.?10:26
lucasno idea, because nobody here obviously know about them ;)10:26
lucasok, example: xnetcardconfig, a ruby packagez10:26
siretartogra_ibook: how many package actually got removed that way yet?10:26
lucasnot in debian10:26
lucasuploaded once, never updated10:26
lucassome users might have install it10:26
lucasit might be rootable10:27
ogra_ibooksiretart, none, because we cared for most of them :)10:27
siretartogra_ibook: what about packages which got removed in debian but are still in ubuntu?10:27
\shlucas: hmmm...sure...there is a ruby team..and this team can decide if ubuntu needs this package or not10:27
ogra_ibooksiretart, if someone wants to care for them :)10:27
sistpotybasically I dislike the idea of removing packages, just because nobody uses them10:27
lucasok10:27
siretartI think we should work on a process for package removals10:27
lucasproblem is, I'm not using it10:27
lucasbut I don't know if somebody else is10:27
lucashow can I know ?10:27
siretartogra_ibook: how to you know when 'nowbody cares anymore for a package'?10:28
raphinkI used to use xnetcardconfig lucas 10:28
\shlucas: I'm not using actually 95% of universe but should I propose to elmo to remove 95% of universe?10:28
raphinkonce10:28
lucasit was just an example10:28
lucas\sh: that's exactly the problem10:28
\shlucas: but I do care about my universe work..and therefore I have to touch those packages, so I do care :)10:28
sistpotyif nobody uses these/nobody has these installed, it's not a probrem if a packages has issues. if ppl. have it installed, it's likely that they'll report bugs10:29
\sheven if i'm not using it in my daily work10:29
sistpotyor even start caring for the package10:29
raphinkhow many packages do we even merge that we won't ever use10:29
raphink;)10:29
ogra_ibooksiretart, if it lies broken on the floor in front of me and nobody complains ;)10:29
lucassistpoty: not likely. not many people report bugs10:29
\shraphink: a lot :)10:29
lucassyncs/merges are different, since debian maintains them10:29
raphink\sh: yes ;)10:29
sistpotyand maybe some people use even the source (sourcepackage)10:29
siretartogra_ibook: cool. that would apply to mythtv!10:30
lucasogra_ibook: what about blog entries like 'ubuntu is crap, I installed this and it doesn't work at all!'10:30
\shlucas: hmmm...nope...many packages are not compatible with debian anymore....gajim is a good example...and I know why :)10:30
ogra_ibooksiretart, drop it then :) (but also deal with mdz afterwards ;) )10:30
siretartogra_ibook: he orphaned it and asked for an adopter10:31
ogra_ibooklucas, look for a comment section and add a link to malone ;)10:31
\shlucas: well...we have settled communication channels like malone for bugs...we can't read all blog pages about "this and that is not working". there was one colleague of mine, who tried to do it, and forced us to read forum posts...well...he's gone now :)10:31
ogra_ibooksiretart, oh, he probably bought a TV now :)10:31
\shlucas: it doesn't work 10:31
ogra_ibookwho knows10:31
lucaspoll: do you prefer: (A) get as many packages in, even if we can't make sure all of them work as expected. (B) maintain a smaller amount of packages, but be reasonably sure they work.10:32
=== sistpoty casts a
raphinka10:32
\shlucas: how do you determine the need of (B)?10:32
siretartlucas: a is how universe is constructed and expected to work10:33
\shlucas: and don't mention popcon10:33
lucas\sh: by using popcon would be great10:33
\shlucas: no10:33
raphinkwe want A10:33
raphinkA provides bugs10:33
raphinkand bugs make software better10:33
sistpotyvote, \sh! ;)10:33
raphink)10:33
raphink:)10:33
lucasraphink: you won't know anything about those bugs10:33
raphinklucas: if they are reported, we will10:33
ogra_ibooklucas, i agree with sabdfl on a ...10:33
ogra_ibookits a declared target 10:33
doko_sistpoty, dholbach, lucas, siretart: just updated the libstdc++ list, the allocator list is currently updating, no need to rebuild, they were all tried and failed. just fix ;)10:33
lucassince joe doesn't know about bug reports and will only blog that ubuntu sucks10:33
crimsundoko_: thanks10:34
\shsoftware comes and goes....like the dinos10:34
siretartdoko_: thanks!10:34
dholbachdoko_: rocking, thanks.10:34
raphinkI consider open-source users to be generally a bit more responsible about reporting bugs than proprietary soft ones10:34
sistpotydoko_: are they rebuilt on a daily basis?10:34
sistpoty(the lists)10:34
sistpotyand thanks doko_ btw ;)10:34
\shdoko_: merci :)10:34
raphinkthanks doko_ 10:35
lucas\sh: what's the problem with popcon ?10:35
\shlucas: it's off by default I think10:35
sistpotyok, since ogra_ibook had the ultimate vote (sabdfl's), what about considering a) the agreement and move to the next topic?10:36
lucashttp://popcon.ubuntu.com never get refreshed10:36
lucasjust a note10:36
\shlucas: and if it wouldn't be switched of by default, I would blog about breaking my private environment of ubuntu10:36
doko_sistpoty: no, takes too long, I'll rebuild these on request10:36
lucasdoes MOTURuby has the right to request removal of a ruby-related package ?10:36
sistpotyok, thx doko_: 10:36
\shsistpoty: there is no vote, because there is no mathematical solution for b)10:36
ogra_ibooksistpoty, this came up at hoary time when we discussed apt-get.org inclusion10:36
lucasif MOTURuby doesn't want to hear people saying that ruby sucks in dapper ?10:37
sistpotybut can we agree to move to the next topic (at least :P)?10:37
crimsunlucas: as opposed to fixing it?10:37
lucascrimsun: yes10:37
lucasbecause it's not integrated in debian, and nobody seems to care10:37
crimsunit's going to have to be fixed _somewhere_, but yes, let's move on10:38
\shlucas: welcome to the world of volunteers :) 10:38
raphink:)10:38
sistpotyok, next item: Collaborative maintenance on tiber via svn or other means10:38
sistpotywho listed this? siretart?10:38
raphinkthere are always people to criticize volunteer and not do anything to help ;)10:38
\shI'm publishing my bzr archives on tiber in my public_html dir :) 10:38
lucasbut there's no bzr-buildpackage10:39
siretartsistpoty: yes, that was me10:39
lucasalso, collaborative maintenance != bzr model ;)10:39
\shlucas: so? I can use bzr and be able to export :) and use debuild and pbuilder...10:39
sistpotysiretart: grab the mic ;)10:39
siretartthis touches a bit the previous point10:39
raphinkis that link to buxy's proposal?10:39
siretartyes, sort of10:39
ogra_ibooki do all my development in bzr (public available on p.u.c) as all main devs do 10:39
raphinks/link/linked/10:40
siretartbuxy's proposal was to have a common svn repo, where interested ppl can just commit10:40
lucasogra_ibook: using bzr is a PITA when you don't have an account on tiber or somewhere else10:40
ogra_ibooksince launchpad will offer access to packages in bzr as well, i think you need to khave a working gateway layer to svn for this proposal10:40
siretartwe have quite some packages, which are activley maintained by us MOTUs and have no debian upstream10:40
ogra_ibooklucas, that will change with the supermirror10:41
siretartsince we are doing team maintenance, I think it is reasonable to have a common repository for them10:41
lucasogra_ibook: ETA ?10:41
\shlucas: why? some webspace is enough..and it can be anywhere..if someone wants that I merge his branch, he should give me the location.10:41
ogra_ibooklucas, no idea10:41
ogra_ibookbut soon i guess10:41
dholbachi have a visitor here, i will leave now - but i'll read the irclog from now on.10:41
\shwhen hct is deployed10:41
dholbachhave a nice evening.10:41
siretartI don't consider bzr suitable for group package maintenance yet, so I'd propose svn10:41
sistpotybye dholbach10:41
ogra_ibookdholbach, have fun10:41
siretartbye dholbach 10:41
dholbachthanks a lot10:41
raphinkbye dholbach 10:42
siretartwe could host that repo on tiber and grant individuals svn access. this is basically buxys proposal for debian, right10:42
raphinkmhm10:42
lucasyeah, why not do that on alioth ?10:43
siretartmy question is: does anyone have objections about this? - and should the different MOTU Teams have different repos or should everything go into ONE big archive?10:43
lucasit would benefit more people10:43
sistpotysiretart: what packages do you think of? all that became uploaded from revu? or just a subset of ppl. willing to do comaintenance?10:43
\shsiretart: I thought buxys proposal was "collaborative work between ubuntu and debian or vice versa"...which means, debian is going away from maintainership10:43
=== lucasd [n=lucas@200.209.160.94] has left #ubuntu-meeting ["Ex-Chat"]
siretartlucas: because we are ubuntu and cannot occupy debians ressources for ubuntu development10:43
crimsunsiretart: would be best to stick to one big one10:43
ogra_ibooklucas, because we have LP ?10:43
lucassiretart: buxy proposed we do10:43
siretart\sh: I didn't get buxy's proposal that way10:44
raphinkogra_ibook: many DDs will refuse to work with LP :(10:44
lucas\sh: buxy doesn't have the power to propose this ;)10:44
siretartlucas: he is an alioth admin, why not?10:44
raphinklucas: buxy has quite some power ;)10:44
lucassiretart: I was talking about moving away from maintainership10:44
raphinkbeing one of the 3 or 4 alioth admins10:45
sistpotysiretart: I'm already having a package on alioth (min12xxw) to test the collaborative maintenance10:45
siretartlucas: oh, your right, sorry10:45
\shlucas: that's what I mean, how can they "pray" for a collaborative work, when they don't have such a system. svn doesn't mean, everyone is allowed to branch and merge and commit to one package at all10:45
ogra_ibookraphink, LP will be the core of ubuntu development 10:45
siretartsistpoty: If I find some time, I will apply, too10:45
raphinkyes ogra_ibook, so it's fine for us ubuntu devs and contributors10:45
sistpotybut I don't know how many ppl. from debian side are caring for that alioth-project... if we come with 20 devs it might be overkill for alioth10:45
lucaswe could start on alioth using the collab-maint project, and move to LP when LP is ready (for dapper+1 or +2)10:45
sistpoty(at least now)10:45
ogra_ibooki dont discuss debian development here ... and i thought the topic is collaboration, not forc one or the other to use the others tools ;)10:46
siretartogra_ibook: you're right. I proposed using tiber, not alioth10:46
raphinkand I tend to agree10:46
lucassiretart: how will you handle security ?10:46
siretartogra_ibook: some packages could be maintained on alioth, that would be more or less 'upstream work'10:47
ogra_ibooksiretart, thats fine 10:47
siretartlucas: security in what way?10:47
lucasif you give svn access to lots of people10:47
sistpotyyes, basically I agree, siretart. we might have public read access and probably some few persons who can be naibed (bringing packages to utnubu/alioth)10:47
siretartlucas: what do you want to protect from whom?10:47
ogra_ibooki think its fine for the debian side to use alioth though10:47
\shregarding MOTUIM, I'm going to do the work with bzr...so gajim is bzr conform..xterm is bzr conform...and everybody who wants to branch, can branch, and if someone is giving me a pointer to a bzr archive and tells me, my patch is quite nice, I'll consider merging it, and daniels can take it over again, when ever he wants...and debian can use those archives as well...10:47
\shand nafallo is doing bzr as well :)10:48
siretart\sh: do you have a list where can I branch what of 'your' packages?10:48
lucassiretart: guys who get their system rooted, got no passphrase, and therefore give access to tiber from the outside10:48
ogra_ibooklucas, thats why i prefer one controlled bzr archive ...10:48
siretartlucas: I don't intend to give out shell access at all10:48
\shsiretart: http://revu.tauware.de/~shermann/packages/ and you find all patch branches in separate branches :) take what you need :)10:49
lucasogra_ibook: svn-{inject,buildpackage} really rocks for collaborative maintenance compared to bzr10:49
\shsiretart: the description of the directories is straight forward, if you are conform with the upstream development10:49
sistpoty\sh: didn't you want to focus a bit on programming? what about bzr-buildpackage ;)10:49
\shsistpoty: it's called hct :) and keybuk is working on it :)10:50
raphink:)10:50
sistpotybut it's not ready yet :P10:50
\shsistpoty: well...until then I'm doing it the manual way10:50
lucassiretart: have you contacted buxy about his proposal ?10:51
lucas(also about REVU2)10:51
siretartlucas: what do you mean exactly?10:51
sistpotyback to topic again, I basically like the idea of having packages around at one central place, or at least one central place to know what packages reside where10:51
siretartlucas: I joined the discussion on the mailing list10:51
lucaswell, maybe his opinion could be interesting10:51
raphinkbuxy is on #ubuntu-motu currently10:52
raphink;)10:52
=== claud1 [n=claude@151.87.79.83.cust.bluewin.ch] has left #ubuntu-meeting []
lucasjust a poll: we should use (A) svn on tiber or alioth, to be determined (B) bzr10:52
=== lucas votes A
raphinkmaybe he could jump in and give us his opinion10:52
sistpotyerm... what about another suggestion: everybody to his likes10:53
\shsistpoty: to be honest, my central place to work with packages is archive.ubuntu.com/ubuntu and a deb-src line in my sources.list...which means, all patches are inside the packages, or in the .diff.gz which I can read and understand :)10:53
=== raphink has no opinion on this matter
lucassistpoty: what would you use ?10:53
lucasit's a poll, not a vote10:53
siretart\sh: the point is to give svn access to ppl which are not in the ubuntu keyring (yet)10:53
sistpotyI'd prefer a), but if there is a package with b) there, I'd use b)10:53
ogra_ibooklucas, you dont understand ... 10:53
\shsiretart: the keyring has nothing to do with "populating changes towards packages".10:54
ogra_ibookthere will be a central mirror for ubuntu packages in bzr format in the future, so you need to use bzr10:54
sistpoty\sh: and I also wrote that I'd like at least a list, where I can get to bzr or svn packages10:54
siretart\sh: the same point is raised by buxy, btw. he wants to give ppl with no strong commitment to packages the chance to contribute to a collaborative development10:54
ogra_ibookor a layer that imports it in your preferred system10:54
siretart\sh: svn commit is way faster than filing patches via malone10:55
sistpotymaybe we could provide svn on tiber, and have a wiki-page that states if a package is in svn or if it's in bzr and where to get it10:55
\shsiretart: but this is contrary to the debian philosophy, and I see his proposal more in this way of a collaborative work between MOTUs and debian maintainers.10:55
=== buxy [n=nnnnnrap@arrakeen.ouaza.com] has joined #ubuntu-meeting
sistpotyhi buxy10:56
raphinkhi buxy 10:56
siretart\sh: I don't think buxy proposale about collaborative maintenance was 'just' about collaboration between ubuntu and debian10:56
\shsiretart: patches are small and if someone has to provide something, he can file a bug. or he is involved directly in #ubuntu-motu :)10:56
siretarthuhu buxy 10:56
siretart\sh: I want to reduce overhead.10:56
\shsiretart: and can send me a debdiff, bzr archive url, svn access, or what ever, if he's not a member of ubuntu-dev :)10:57
buxyhi everyone, I'm sorry to join so late in the discussion but I've just been invited by sirestart and raphink :)10:57
raphink;)10:57
raphinkbuxy: well I guess you're still the best guy to talk about your proposal and make it cleare10:57
raphinks/cleare/clearer/10:58
buxyOk, if you think it's needed I can try explain the context10:58
=== raphink wonders why it's so silent here all of a sudden
siretartbuxy: from this discussion here, I'm a bit confused. Did you really invite all MOTUs to commit and work on packages for ubuntu (and debian as well this way) in the collab-maint svn repo?10:59
\shfollowing the last discussion at the Debian-QA meeting on Darmstadt, it11:00
\shappears that the proposal called "Collaborative maintenance" is of generic11:00
\shinterest :11:00
\sh- for Debian sponsors and Debian mentors11:00
\sh- for QA which may use the infrastructure for orphaned packages11:00
\sh- for Ubuntu's MOTU School11:00
\shthis is the first paragraph of the mail :)11:00
buxysiretart: it's a possibility that I offered yes, but as I told, the important part is what's above "svn" and we could make the infrastructure support more than just svn11:01
raphinkand I've actually been wondering what was meant by "MOTU School" 11:01
siretartbuxy: yes. I see. 11:02
\shraphink: he means MOTU motu school is something different..but quite popular :) 11:02
buxyraphink: The MOTU school is the "mentoring process inside Ubuntu" for me :)11:02
raphinkoh ok ;)11:02
sistpotyoh, he, no... it's irc lessons about a specific topic11:03
raphinkbuxy: MOTU school is something else for us but ok :)11:03
raphinkat least I get it :)11:03
ogra_ibookbuxy, #ubuntu-motu is the mentoring process we use ;)11:03
lucasbuxy: you mean REVU actually11:03
lucas(basically)11:03
buxy\sh: yes the context is summed up in the wiki page, the project started for managing orphaned packages but we found out that it could be a good way to handle packages from new maintainers and in general for packages maintained by contributors outside of Debian (and MOTU are contributors outside of Debian for me)11:04
buxy"contributors outside of Debian" is badly said, I should have said "non-DD contributors"11:05
\shbuxy: so does it mean, debian will go away from the maintainership of packages and let everybody who wants touch packages? without being killed or flamed of the former maintainer?11:05
lucas\sh: the proposal is about *some* packages, not all packages.11:06
\shlucas: even orphaned packages are still maintained..the former maintainer will help the new maintainer to take over the package..11:06
buxy\sh: this can't be a one-day change, but maintainers who are willing to go in that direction could put their packages in a pool where many people could work on it11:06
\shlucas: (in the best situation)11:06
buxy\sh: but not all packages will be managed that way11:07
=== segfault_ [i=carlos@prognus.com.br] has joined #ubuntu-meeting
siretartbuxy: does the debian QA team has a 'common' svn repo for orphaned packages?11:09
\shbuxy: so it can be possible to branch this package source and provide an archive url towards the package maintainer...if I want to work on this particular package...11:09
\shbuxy: despite the fact of a centralized package repository11:09
buxysiretart: not yet, but QA people have nothing against that11:09
=== lucasd [n=lucas@200.209.160.94] has joined #ubuntu-meeting
\shbuxy: because this is my meaning of collaboration...if I want to contribute, the maintainer of package is always the last point of decision if he wants my patch or not11:10
siretartbuxy: currently, the utnubu team has its own 'common' svn repo. are they expected to keep their own repo or merge it with the collab-maint one?11:10
\shmeans: there is no need of something centralized..11:10
buxysiretart: that's a topic that I haven't brought up yet, but of course I'd like to push in that direction11:11
=== tseng [n=tseng@brandonhale.us] has joined #ubuntu-meeting
tsengeh11:12
\shmoins tseng 11:12
buxy\sh: collaboration is not only a tool, it's a behaviour11:12
buxy\sh: if you work n a branch on your side, and tell the maintainer what you did and where he can get the stuff to get integrated, that's fine11:12
\shbuxy: yes...and a nice one...but again...the maintainer is the last resort of the decision11:13
\shbuxy: that's what I said, yes :)11:13
sistpotyok, let's try to get back to the topic?11:13
siretartyes, please11:13
sistpotyok... what prosals are there/can we agree on s.th. or should we defer this?11:14
siretartbuxy: the discussion was to instantiate a common svn repo for us motus11:14
siretartI proposed to host it on tiber, mainly because I did not want to abuse alioth for mainly ubuntu work11:15
\shsistpoty: what proposal...if it's regarding buxy, we are speaking of something to be made between debian and ubuntu, if we are talking about "motu collaboration" we have actually11:15
siretartwe want to maintain there package which we motu's activly maintain11:15
=== ajmitch prefers to do normal debian maintenance for those
siretartso the question is: should this be rather on tiber or on alioth. buxy: what do you think?11:16
ajmitchfor my packages, that is11:16
\shif we want to maintain the packages for ubuntu, then we should discuss an ubuntu way...if we are talking about debian and ubuntu, we should postpone this discussion to a better time and with all people involved in this....] 11:17
buxysiretart: difficult to say, but hosting on alioth is ok for me as long as we agree that all packages which are not ubuntu-specific should also be integrated in Debian (even if the upload is in fact done by utnubu)11:18
lucas\sh: can you define "all people involved in this" ?11:18
\shlucas: all debian responsibilities and as well all ubuntu reponsibilities. 11:18
\shlucas: because this is nothing for the motu meeting at all..it touches more then "svn repos for motu on tiber"11:19
ajmitchlucas: it'd involve others from the utnubu team11:19
siretartbuxy: I think mostly about packages which are interesting for debian, too, but I didn't care enough for searching for a sponsor, because I did not wanted to be the only maintainer. I think there are quite some packages of this kind11:20
siretartbuxy: for packages which are only of interest for ubuntu, thats a clear matter11:21
siretartbuxy: what is the procedure to get svn access to the collab maint svn?11:21
buxysiretart: okay, then I think alioth is a good choice11:21
tsengsiretart: anyone can get an account on alioth11:22
buxysiretart: mail me and tell me your alioth login name and why I should add you to the project :)11:22
tsengsiretart: team members can give you access to the svn11:22
buxytseng: team admin only11:22
ajmitchbuxy: can I join too? :)11:22
buxyajmitch: sure :)11:22
siretartbuxy: great. will do. (my login is siretart-guest ;)11:22
ajmitchI'll get over my dislike of svn one day11:23
siretartok. I think we are done with this point11:23
siretartnext?11:23
sistpotysiretart++11:23
sistpotynext point is "Brainstorming/Ideas how to organize divergence in our universe"11:23
sistpotywho's one was that?11:23
ogra_ibook"divergence in our universe" ??11:23
siretartlucas: I think http://tiber.tauware.de/~lucas/versions/unimultiverse.html is really rocking! I wanted to say you a big THANK YOU for that11:24
sistpotyogra_ibook: copy'n'paste from wiki11:24
siretartogra_ibook: I'm talking about divergence from our upstream: debian11:24
lucas:-) thank you for hosting me11:24
lucasand thank sistpoty for providing the merge comments :)11:24
sistpotyhe, np11:24
siretartlucas: you have a coloum there for notes on individual packages which can be edited via the wiki11:25
lucassiretart: yes ?11:25
\shsiretart: when debian will adjust to our infrastructure, e.g. modular xorg etc. those diffs will automagically go away11:25
siretartI'd like that everyone who touches a package in ubuntu makes a note about what kind of divergence the package is in ubuntu. perhaps you remember my posting to the mailinglist11:25
siretart\sh: exactly thats my point11:26
\shsiretart: transitions...well, if they are announce earlier for debian then ubuntu, then we will have less packages to touch, if not..well you know the fun :)11:26
ajmitch\sh: xlibs-dev is removed from sid now - I think it's just the gl libs that are a hassle11:26
siretart\sh: I'd like to know when all patches e.g. because of xorg are obsolete11:26
lucassiretart: I started that for ruby packages, but not sure if there should be a 'MUST' here11:26
ajmitchsiretart: that would require us to identify by patch that it's a build-depends change :)11:26
ajmitchsiretart: it *could* be done with grep & a fair bit of work11:27
sistpotyI already feared, you would say that, ajmitch ;)11:27
\shsiretart: there was last time a blog post of the xorg maintainer, and he is pushing the modular xorg now into debian, so it can be, that for dapper+1 those changes are gone11:27
ajmitchsistpoty: why do you say that?11:27
sistpotyajmitch: that it could be done automatically ;)11:27
siretartajmitch: there are many types of divergence. I'd like to have some more overview and statistics about how far we are diverged from debian and why11:28
ajmitchsistpoty: nah, I didn't say automatically11:28
\shsiretart: means dapper+1 will be a fcking sync orgy11:28
sistpotyajmitch: come on, you implied it :P11:28
ajmitchsistpoty: certainly, and we can identify a few of those automatically, to keep sistpoty happy :)11:28
ajmitchheh11:28
sistpotyhehe11:28
siretart\sh: that would be really awesome, because I think we have diverged from debian to much. and way too often unnecessarily11:28
ajmitchsiretart: of course, and it's always a matter of what time we have to sort this out11:29
sistpotysiretart, lucas: where should we post/submit the divergence?11:29
ajmitchin between the bugfixing11:29
\shsiretart: well...patches like launchpad integration etc. which are not taken by debian upstream neither real upstream will stay in ubuntu, so we will always have an ubuntuX package11:29
siretartsistpoty: and now we come to the point I wanted to raise11:29
lucassistpoty: http://wiki.ubuntu.com/MOTUNotes11:29
ajmitchsiretart: not filing bugs, is it?11:30
siretartsistpoty: I think we have 2 options: http://wiki.ubuntu.com/MOTUNotes, or some more magic with postgresql and javascript.11:30
siretartajmitch: would you really file a new bug for each diverged package explaining why it diverged? that would be true overkill11:30
sistpotysiretart: I don't like the 2nd option... we'd need some kind of user management for this to work11:30
siretartsistpoty: why?11:30
sistpotysiretart: because otherwise everyone could change the type of divergence?11:31
siretartsistpoty: a wiki doesn't need usermanagement, too11:31
siretartsistpoty: *Shrug*. wikipedia works too11:31
sistpotysiretart: it does... and it has revision control as well11:31
lucassiretart: I don't care, just generate or help me generate a text file with the MOTUNotes syntax11:32
lucasI can add several other columns to the reports if needed ;)11:32
\shto be honest, we can't avoid to be different in some areas from debian, and we shouldn't want to avoid it. infrastructure reasons are one point, but special ubuntu patches or patches we can provide upstream is something else11:32
siretart\sh: I strongly disagree11:32
siretart\sh: I think we should avoid divergence where possible, because we are really lacking ressources11:33
\shsiretart: you can't force debian to apply our gnome patches e.g. for launchpad11:33
sistpoty\sh: the advantage would be to have "all packages with motuglutransition" at hand, and once debian and ubuntu are back in sync, this might save a lot of work11:33
\shsistpoty: this is "infrastructure" which will go away11:33
siretart\sh: please don't overread the 'where possible and necessary' part. I certainly know that we want some divergence, but I think we have way too much of it11:34
\shsistpoty: the same applies for transitions..as we saw from breezy to dapper :)11:34
\shsiretart: don't blame us, blame the slowliness of the transitions in debian...honestly11:34
sistpotyexactly, but what do you mean with infrastructure, that will go away?11:34
siretart\sh: I don't want to blame anyone, I want to solve problems11:34
\shsiretart: the system how debian works is really different from ours...and even if we're less people then debians DDs and NMs, we are quite faster in those transitions.11:35
siretart\sh: so what?11:35
\shsiretart: so you can't avoid it...and thinking about sabdfls speech at debconf5 those deltas are really normal11:35
\shsiretart: for ubuntu.11:36
\shsiretart: the solution is "time"11:36
lucassome of them are normal, some of them aren't11:36
\shlucas: which aren't normal?11:36
lucasbugs fixed in ubuntu but not reported upstream, for example11:36
siretart\sh: http://tiber.tauware.de/~lucas/versions/unimultiverse.html lists about 900 packages, which of same upstream version in both ubuntu and debian (but ubuntu hast 'local' changes)11:36
sistpoty\sh: but I still think we might gain much time, if we could categorize the reason, why a package diverges from debian, whilst doing merges11:36
lucaswe have to stay at a stable distance from debian. not increase this distance release after release11:37
siretart\sh: I suspect a big part of them to be unnecessary. and 900 diverged packages is definitly way to much for us11:37
siretartlucas: how often is that list updated?11:37
\shok ok..11:37
\shshort summary11:38
\shwhat do we have:11:38
lucasevery 6 hours11:38
sistpoty\sh: consider that you can just see: ah siretart last uploaded foo and transitioned it to c2a... debian/changelog states the same, then you'll only need to check if the debian package did it right11:38
lucassiretart: read http://tiber.tauware.de/~lucas/versions/ ;)11:38
\shwe have packages with more actual upstream version means  0UbuntuX11:38
siretart82 packages11:38
\shsistpoty: yes..that's what we did in dapper with the c2 transitions.11:38
\shsistpoty: and we will do the same for dapper+1 with all c2a transitions11:39
\shwe have packages which were renamed from us, but not renamed by debian11:39
\sh(but will be in time)11:39
siretart\sh: please. 900 packages is really ridiculous. our main divergence should be in main, not in universe. we simply don't have the ressources to maintain it11:40
\shwe have packages, which have special ubuntu patches applied, those patches debian never will apply11:40
sistpoty\sh: yes, and that's the reason to categorize the divergence... to see if patches need to be reapplied or if it's probably a sync candidate11:41
siretart\sh: now you slowly get the point. I want a list where I can look of what kind of divergence (i.e. why the package was diverged from debian) a given package has11:41
\shsiretart: so we need a tool which fetches the debian source package and fetches the ubuntu source package and run a diff 11:42
\shsiretart: and we need someone who has knowledge about all the changes and he can classify them11:42
buxy\sh: people.u.c/~scott/patches/ :)11:43
sistpoty\sh: the tool is mom... but that doesn't classify them11:43
=== ealden [n=ealden@ipdial-166-146.tri-isys.com] has joined #ubuntu-meeting
siretart\sh: and I'd propose lets do that marginally. everytime someone touches a package causing divergence or working on merges he should add a note what kind of divergence that package has11:43
\shsiretart: most propably we will find out, that our people were doing the dpatch/simple-patchsys way, debian is doing the diff.gz way...or the other way around...11:43
sistpotyhehe, buxy11:43
ajmitch\sh: sounds like a job for an unemployed motu like me ;)11:44
\shsiretart: and then we have ubuntu packages where we fixed a bug from our bugtrackers...11:44
\shor simple .desktop files 11:44
lucaswe could start by making very verbose changelog entries11:44
buxysiretart: if you keep that info somewhere, please make it parsable by a program so that I can make that information available together with "sctottish pacthes" for Debian maintainer11:44
lucasso we know *exactly* what changed11:44
buxyin the Package Tracking System11:45
=== sistpoty has just an idea
ajmitchbuxy: good idea11:45
\shlucas: what means "verbose changelog entries" ?11:45
siretartbuxy: I have in mind that this information is valuable to both debian and ubuntu, as it helps minimizing divergence11:45
lucas\sh: no need to read the rest of the debdiff to know what changed11:45
buxybecause actually Debian maintainer can grab the diff but they don't always know why the changes have been made11:45
\shlucas: added .desktop file is quite simple and meaning full...reading the source and debian/rules should be accomplished by someone who is working on packages at all11:46
sistpotysiretart: if we use revu logins, we already have a user-system... I guess I could easily h4ck up the merge list to store some catagories as well11:46
\shlucas: that is wrong11:46
\shlucas: because you need to know more then only the changelog and the diff.gz.11:46
\shlucas: today one DD gave me an example....source package ppp11:46
ogra_ibooksiretart, sistpoty, err, isnt revu2 supposed to be included in LP ?11:46
siretartsistpoty: we could also use revu for authentication. but I'm not convinced that we would need authentication at all, because I don't think there is much interest for vandalism with wrong entries11:46
siretartogra_ibook: yes11:46
ogra_ibooksiretart, sistpoty, in which case LP logins will apply ...11:47
\shdoko wrote after the merge something like this in the changelog: "11:47
lucas\sh: the changelog, if verbose enough, is enough to categorize packages11:47
\sh* Synchronise with Debian unstable.11:47
\sh  * Still keep the pppoe_on_boot stuff.11:47
sistpotyogra_ibook: tiber isn't whitelisted for lp yet... if it was, I guess it would be trivial (at least from reading the interface specs)11:47
siretartogra_ibook: yes. my point stand, I don't think that we would need authentication at all, but I could live with lp accounts11:47
ogra_ibooksiretart, yup11:47
sistpotysiretart: if I make a web interface w.o. accounts, everyone could change the catagory... I don't like that11:48
\shlucas: reading this, is verbose enough, because I know that we have a pppoe on boot functionality...reading the diffs but shows me, that this feature was just gone in the debian package long ago, but we need it11:48
sistpotysiretart: other possibility was to hack up lpbugs and handle this by bugs in malone11:48
siretartsistpoty: I want everyone to be able to change the category and even to introduce new categories11:49
siretartsistpoty: do you fear much vandalism?11:49
sistpotysiretart: i'm pretty paranoid ;)11:49
buxy\sh: and the interesting stuff is to understand why this feature is needed by Ubuntu and why it has been removed in Debian :) did the Debian maintainer have a nicer solution to the problem ?11:50
siretartwhat do others think? is there a big danger from vandalism?11:50
\shbuxy: no :)11:50
sistpotysiretart: possibility was to use wiki, but that would mean to have a "divergence" in catagories11:50
\shbuxy: that's why he complained today :)11:50
\shbuxy: but he didn't want to read the diff..but my opinion is, as package maintainer you should 11:51
lucassiretart: you need to be able to restore a previous version easily11:51
lucassiretart: I'm not sure such a page would be enough.11:51
\shbuxy: and if I need some more info, I'll ask the guy who did the merge :)11:51
ajmitchbuxy: we'll always run into problems when we make some changes without proper understanding of the package, just for a quick fix :)11:51
siretartso we have 4 possibilities: (a) don't categorize since uneccesary work (b) categorize via wiki/MergeNotes (c) categorize via webtool and login (d) categorize via webtool without login11:51
lucaswe need to be able to put a package into several categories11:51
siretartlucas: right11:52
ajmitchI know I'd even be wary of MOTUs patching some of my debian packages :)11:52
sistpotyand a user should be able to add a catagory11:52
lucas(e) categorize via bugs, or a specific interface in LP11:52
sistpoty:(11:52
\shajmitch: hmmm? :)11:52
=== siretart votes for (d)
=== lucas not sure yet
ajmitchsiretart: why no login?11:53
ogra_ibooksounds like a cool database project :)11:53
lucaswe want knowledgeable people to do the tagging11:53
=== sistpoty votes for (c)
lucasso login is fine11:53
\shogra_ibook: long term :)11:53
=== ajmitch thinks (c)
ogra_ibookyup11:53
=== slomo_ is for (c) too
\shoh wow...a lot to read for me for the minutes :)11:54
slomo_(hi btw, sorry for beeing that late, didn't notice that there was a meeting :/ )11:54
sistpotyhi slomo_11:54
siretartajmitch: no login because I don't fear vandalism and I want to make it as easy as possible to use11:54
ajmitchslomo_: don't worry, I was 2 hours late11:54
siretarthi slomo_ 11:54
siretartok, the majority seems to be (c)11:55
ajmitchslomo_: being 3 hours late is no obstacle, we're still going ;)11:55
siretartI think I'll meet with sistpoty in person and get details about this discussed with him, ok?11:55
siretartsistpoty: ok?11:55
sistpotysiretart: sure11:55
ajmitchah, closed secret meetings? ;)11:55
buxya town name please !11:55
siretartajmitch: of course, secret cabal and such ;)11:55
siretartbuxy: we are at the same university, in erlangen ;)11:56
ajmitchsiretart, sistpoty: we need to discuss some REVU2 coding sometime also11:56
Lathiatmotu m eeting?11:56
sistpotybuxy: erlangen probably, or nuremberg11:56
siretartajmitch: right11:56
ajmitchLathiat: yes11:56
Lathiat*still* going? :)11:56
ajmitchLathiat: yes11:56
buxyhehe, the famous erlangen meeting !11:56
Lathiatok :)11:56
ajmitchbuxy: better than vancouver :)11:56
siretartlol11:56
\shejabberd is in erlangen 11:56
sistpotyajmitch: oki11:56
=== BxL [n=BxL@modemcable097.172-131-66.mc.videotron.ca] has joined #ubuntu-meeting
sistpotyok... what's left to discuss? date and time of next meeting?11:57
siretartI think so11:57
siretart3h meetings are too long11:57
sistpotydefinitely11:57
ajmitchyes11:57
ajmitchfar too long11:57
sistpotyI guess it would be good just after uvf?11:58
ajmitch2 weeks from now?11:58
ajmitchnah11:58
lucassiretart: please mail a summary of what you intend to do to ubuntu-motu. I'm interested in this :-)11:58
\shwasnt it the first meeting after ubz?11:58
=== ajmitch will be at LCA in 2 weeks ;)
ajmitchlucas: they will have to11:58
sistpotyajmitch: sure, that's what I call "just after uvf" ;)11:58
lucassiretart: and setup those backups for tiber ;)11:58
siretartlucas: I'll try :) - most of this was already said in my first post this year11:59
ajmitchlucas: I also want to discuss some things with you..11:59
siretartlucas: yes, thats on my list, too11:59
siretartnext meeting in 2 weeks?11:59
lucasajmitch: now ?11:59
siretartobjections?11:59
sistpotytime, 20.00 utc?11:59
lucastime is fine for me.11:59
ajmitchlucas: whenever suits11:59
Lathiatmm 4am :)11:59
sistpotytime for objections left: 511:59
sistpoty412:00
ajmitchsistpoty: hm, I'll be busy then12:00
sistpotyajmitch: propose another time12:00
\sh3...2...1...12:00
ajmitchnah, it doesn't matter12:00
=== ajmitch is just another face in the crowd
siretartok. I need to go now, sorry12:00
buxyajmitch: you're an important face12:00
sistpotyno, we can't meet at 20.00h... -meeting is busy there12:01
sistpotygn8 siretart12:01
slomo_bye siretart :)12:01
siretartI wish you a good night, sleep well everyone!12:01
ajmitchbye siretart 12:01
\shsistpoty: put a date and time on the wiki page..I'll promote them in the minutes :)12:01
buxywe don't have so many people with double hat MOTU/DD outside of the core developers paid by Canonical12:01
sistpoty\sh: I vote for ajmitch to put it there ;)12:02
ajmitchbuxy: no, I think I'm one of the few who can upload to main, universe & debian who's not employed :)12:02
\shwhatever :)_12:02
ajmitchsistpoty: 2000 UTC is 9am for me, I'm busy all that week of the 23rd-28th12:03
ajmitchso I can't hold others back12:03
\shdamn..I forgot to kiss ajmitch's feet while I had the time during UBZ ,)12:03
ajmitch\sh: you'd get a kick in the mouth :P12:03
\shajmitch: hehe :)12:03
sistpotyajmitch: there is status meeting at 20.00 utc, so we can't meet at that time and I don't have any preferences 12:03

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!