19:00 < pere> lets start.  those present, please use /me = Full Name to make the summary writers job easier.
19:00  * pere = Petter Reinholdtsen
19:00  * sepski = Ronny Aasen
19:00  * white = Steffen Joeris
19:01 < pere> who collect the log and who write the summary?  I do not see the point of continuing before that is decided.
19:02 < sepski> i allready wrote myself up on the wiki as logger
19:02 < white> sepski: damn i wanted to take over that job
19:02 < pere> ok, log collector found.  summary writer?
19:03 < sepski> white, ill trade you for summary ?
19:03 < white> sepski: not really volunteering if it is not completely necessary
19:03 < sepski> white, i mean ill write summary if you post the log
19:03 < white> sepski: alright :)
19:04 < sepski> wiki updated
19:04 < white> pere: you are my whitness :) he writes the summary :)
19:04  * h01ger = Holger Levsen - sorry for being late, had to blog about dunc...
19:04 < pere> ok.  good to have that out of the way.
19:04 < sepski> ill do my very best..... :/
19:04 < white> sepski: you are welcome :) i can proofread if you want
19:04 < Baby> hi h01ger! :)
19:05 < Baby> Baby = Miriam Ruiz
19:05 -!- pere changed the topic of #debian-edu to: Meeting in progress: Agenda point "status of the installer"
19:05 < pere> so, who want to say anything about the installer?
19:05 < pere> I notice subpoints etch-test dvd, g-i, volatile
19:06 < white> i guess all in all we can be proud first :)
19:06 < white> most of the job done by pere and sepski, we should keep that in mind, thanks for that
19:06 < pere> yeah.  great work preparing the new release.  Most work was not done this weekend.  It has been done the last few months
19:07 < h01ger> + powerpc which i cant say much about as i'm away from my ppc machine. but people tested it and reported issues. which i will look into once i'm at the machine again in two weeks. i also plan to enable a amd64-cd - if you're happy with that.
19:07 < h01ger> (amd64 more being mid-term)
19:07 < pere> h01ger: powerpc has its own agenda point, so we will get to that.
19:07 < white> good idea, what about the autobuilders are they in place and fetching stuff?
19:07 < white> pere: sorry
19:08 < pere> I am all for an amd64 CD, if it make sense.
19:08 < white> i just discovered that etch-test is broken when installing thin-client-server only
19:08 < white> we should keep an eye on that
19:08 < sepski> same as i saw earlier
19:08 < white> it changes debconf to medium
19:08 < pere> yeah, we need to find out why.
19:08 < h01ger> pere, i dont see this in the agenda at http://wiki.debian.org/DebianEdu/Meeting ?!
19:09 < h01ger> (but of course fine with me)
19:09 < white> h01ger: after etch-test and dvd
19:09 < pere> h01ger: "powerpc port" ?
19:09 < pere> h01ger: oh, right.  I use an old version of the agenda.  damned browser cache.
19:09 < h01ger> heh
19:09 < white> but it is still there
19:10 < pere> ok, now I am up to date.
19:10 < white> i guess we should also keep in mind to sync changes from now on to etch once we tested something in etch-test
19:10 < white> the procedure for that is described, mail to ftpmaster@
19:10 < pere> yeah.
19:10 < pere> when I released test01 yesterday, I decided to not relase the DVD and powerpc images.
19:10 < white> any problems with ftpmaster doku or how user have to work with it, just to me and blame me
19:11 < white> pere: good idea as they are still untested i guess
19:11 < pere> I dropped the DVD images because I have not heard any successfull installation report using it, and I dropped powerpc because of the reported problems with it.
19:11 < white> it should be verified by at least one developer i guess
19:11 < pere> for the next release, I would like us to consider releasing the DVD as well, if anyone can test it.
19:11 < white> before releasing it into public
19:12 < pere> I somehow doubt the powerpc work will be well underway in time for the next test cd.
19:12 < h01ger> cant we (=everybody) test the dvd-images in qemu?  i verified it at least boots
19:12 < pere> h01ger: I guess.  need to clear out some cruft from my hard drive first...
19:12 < white> h01ger: should be possible and we can start with it :)
19:13 < pere> next on the subtopic-list is g-i.
19:13 < white> someone familiar with it and did try it?
19:13 < pere> I've had the pleasure of testing Otavios work on it, available from <URL: http://master.ossystems.com.br/snapshots/mec-unstable/20060913/mec-10-i386-binary-1.raw >.
19:14 < pere> It look nice.  But we should make more artwork if we are going to enable it.
19:14 < white> pere: do you know how much work it is to get it into our cds?
19:14 < pere> I have no idea how to enable it myself.  I suspect we need to update debian-cd to get proper support for it.
19:14 < white> pere: and at least what we have to do
19:14 < white> hmm
19:15 < pere> at the moment we use an old svn snapshot of debian-cd.  it is probably time to update it, but it will take some time to stabilize once we do.
19:15 < h01ger> isnt a dual-boot (d-i and g-i) cd planned for debian-etch anyway (so we would profit from it)?
19:15 < white> we should supervise the update carefully
19:16 < pere> h01ger: yes.  I believe it is already implemented in debian-cd svn, thus the upgrade idea
19:16 < pere> should we do the debian-cd upgrade now, or postpone it?
19:16 < h01ger> now
19:16 < white> we can do it now
19:16 < sepski> we should do it. it's been long due,
19:16 < pere> I believe we should make a new test release 2-3 weeks from now, to keep up the speed.
19:17 < h01ger> gives us more time to fix stuff :)
19:17 < pere> anyone willing to do it?  I believe it is possible to test by building on a.s.n, and then update the builder users environemtn when it work.
19:17  * pere plan to keep focusing on the configuration
19:17 < white> pere: what do you mean?
19:18 < white> pere: i would just update it with builder user and work until it works
19:18 < white> pere: or do you want to copy the stuff and test it manually with a user?
19:18 < pere> white: at the moment we have a debian-cd snapshot and our debian-cd.patch.  the patch will no longer apply once we upgrade the svn snapshot, so someone need to apply the patch, do svn update, clean up the mess, extract the new patch, and then upgrade the snapshot used by builder.
19:19 < sepski> white, you can test as a user, so you dont break while testing.
19:19 < white> yeah yeah i'll do it
19:19 < pere> and I really would like more people to figure out the inner workings of the cd build, so I would keep off it for that reason too.
19:19 < pere> great.
19:20 < white> yeah i love to adjust this patch
19:20 < sepski> white, you couls also svn sync one and one revision from debian-cd
19:20 < sepski> so you didnt get alll the breakage at once.
19:20 < sepski> but that might be a tedious prosecc
19:20 < sepski> process
19:20 < white> sepski: i am a tough guy :)
19:20 < pere> ok, next subtopic.  volatile.  what about it?
19:21 < white> shall we include it for etch?
19:21 < pere> and for newcomers, please announce your presence using /me = Full Name
19:21 < sepski> do we use anything, that's available from volatile ?
19:21 < h01ger> we should include it, if only for clamav. and i'm real sorry i can just give comments atm, i dont have any time :(
19:21 < h01ger> (+IMHO)
19:21 < white> who brought up the point by the way?
19:22 < pere> I have no idea.  I suspect we want to provide clamav, and its data files will be available from volatile, I believe.
19:22 < sepski> h01ger, for clam is sensible. im suing volatile myself and have no bad experiences with it yet
19:22 < pere> clamav should probably be on our package list.
19:22 < white> hmm i guess we can just include it for etch
19:23 < pere> what is ment by "including it"?  On the CD or in sources.list?
19:23 < sepski> is there realy a point in making it harder then provide a commented  sources list for volatile.  ? like we do for the other sources ?
19:23 < white> pere: sources.list
19:23 < white> pere: as there is currently no volatile for etch as etch is not yet released
19:23 < white> pere: just for later
19:23 < pere> ok.
19:23 < white> sepski: yeah that is what i mean
19:24 < pere> sound like a good idea to include it commented out like the rest.
19:24 < white> jip
19:24 < pere> I listed the next subtopic, security packages.
19:24 < sepski> i can do that, should be simple enoughf.
19:24 < white> not much traffic i guess
19:24 < pere> I believe we need to include on the CD security fixes for etch provided by the testing security team
19:25 < white> sorry thought you mena sarge security
19:25 < pere> (and when etch is released and we continue to make new releases, we need to provide packages from the stable security team)
19:25 < pere> anyone have any idea how to make that happen?
19:25 < white> pere: we are doing that anyway afaik?
19:25 < white> pere: i mean packages from stable security team
19:25 < pere> I believe we did do that a long time ago, for woody, and are no longer.
19:26 < white> as far as i know security.debian.org is still in the sources.list
19:26 < pere> we have no security.debian.org mirror any more, so I doubt the packages are included on the Cd.
19:26 < pere> white: which sources.list?
19:26 < white> pere: for the sarge release i mean
19:27 < white> currently we are not doing it right
19:27 < pere> we get the security fixes when a new snapshot release of sarge is released, and the security fixes are moved into the normal mirror.
19:27 < white> pere: as far as i know security.debian.org is on every installation of skolelinux 2.0
19:27 < white> like in the sources.list
19:27 < white> or am i totally wrong
19:27 < pere> white: I am not talking about the installed sources.list.  I am talking about what we include on the CD.
19:28 < white> pere: well for stable security there we have some time to fix that for etch and i don't know about testing security
19:28 < pere> when a package show up on security.debian.org, I want it on the next built CD as well.
19:28 < white> then i guess the easiest way is to mirror security.debian.org as well
19:29 < sepski> white, the only way i guess ? debian-cd want a local mirror.
19:29 < pere> that is at least the first requirement.  the next is to get debian-cd to use the packages there.
19:29 < white> sepski: yes
19:29 < white> pere: i don't know if it supports testing-security but it does support stable security or?
19:29 < pere> anyone interested in fixing this, or verify that it is already fixed?
19:29 < sepski> sounds like something we might look at after debian-cd is up to date
19:29 < pere> ok
19:29 < pere> lets move on
19:30 < white> sepski: remind me of that when we work on debian-cd :)
19:30 < sepski> i also suggest that we let the builder svnupdate to the most curret debian-cd all the time,
19:30 < white> sepski: please, sorry
19:30 -!- pere changed the topic of #debian-edu to: Meeting in progress: Agenda point "Kernels to support"
19:30 < white> sepski: that would break the builds
19:30 < sepski> so we avoid falling so far behind, and take patch breakage as they occur ?
19:30 < white> and the patch
19:30 < pere> sepski: there is code to keep debian-cd updated, but it was disabled shortly before our sarge release was done.
19:31 < h01ger> white, the patch should apply cleanly, "normally" :-D
19:31 < white> do somebody know about autobuilders status?
19:31 < pere> a problem with tracking debian-cd svn is that we do not detect when it breaks.
19:31 < pere> (well, not directly, at least. :)
19:31 < sepski> h01ger, it does not aply to a current debian-cd
19:31 < white> h01ger: not when it updates
19:31 < pere> moving on to kernel support.
19:31 < h01ger> sepski, once it's fixed (which white will do)
19:31 < pere> who want to say anything here?
19:31 < h01ger> whats the question about the kernels? why should we use other kernels than debian?
19:32 < sepski> ltsp needs a 486 kernel
19:32 < sepski> include that with it's large size or get ltsp to use a 686 kernel ?
19:32 < pere> right.  I switched from 686 to 486 kernels because of that.
19:32 < sepski> and would that break many thin clients ?
19:32 < white> are the 486 kernels still supporteed by debian and its security teams?
19:32 < white> aeh forget that question
19:32 < pere> white: yes, as far as I know.  the 386 kenrnel is not, and it is dropped.
19:32 < white> pere: yeah that is what i had in mind
19:33 < pere> are there any kernel problems now, or was the problem fixed when I switched to 486 kernel on the CD?
19:33 < sepski> pere we can still run 686 on the cd, but need a 486 present for the ltsp chroot
19:33 < white> how much extra space does that mean?
19:34 < pere> sepski: no, we can't.  One kernel spends 15-20 MiB on the CD.  we can't afford to have more than one.
19:34 < sepski> ahh.
19:34 < pere> the DVD have all the kernels.
19:34 < h01ger> then put the 486 one on the cd and mention the other ones in the release notes?!
19:34 < white> any progress in ltsp to get it working with 686 kernels?
19:34 < sepski> well i dont know if all the various thin clients out there run on 686, many are via or crusoe based machines
19:35  * pere do not know that part of the ltsp status
19:35 < sepski> vagrant mentioned it was better in 99
19:35 < pere> 1999?
19:35 < sepski> 0.99debian
19:35 < pere> right.
19:35 < sepski> http://bjorn.haxx.se/debian/testing.pl?package=ltsp-server
19:35 < sepski> 4 days to go still
19:36 < sepski> but even if we can change , would it break clients ?
19:36 < pere> right.  we will have to test it when it arrives.
19:36 < sepski> i can atlest test on crusoe.
19:36 < pere> If I understand this correctly, we agree on using the kernel version used by debian for etch, and will stay with the 486 kernel on the CD.
19:37 < white> yes
19:37 < pere> I guess we will get a similar discussion for amd64 and powerpc, but leave that for later.
19:37 < sepski> pere we test 686 when 99 hits. then we decide.
19:37 -!- pere changed the topic of #debian-edu to: Meeting in progress: Agenda point "status of the never ending bug #311188"
19:37 < pere> next on the agenda, the good old bug about messing with the configuration
19:37 < h01ger> winnie started to work on some blocking bugs. yay!
19:37 < white> what do the release managers expect, does somebody know that?
19:38 < pere> white: no idea.
19:38 < white> i could also remove a few, but i don't know what the matter is
19:38 < h01ger> white, yes. vorlon said, an etch-igore tag is out of option. we ignored the bug two years..
19:38 < vagrantc> 0.99debian2 of ltsp allows you to specify the kernel from the commandline, as well as disable the security mirror with "--security-mirror none"
19:38 < sepski> they expect it to install without and disruption on a stock debian, that's a must have.
19:38 < white> h01ger: but what is the bug
19:38 < pere> if they are serious about their written statement, localization-config will have to be dropped from etch too.
19:38 < white> we don't start the scripts by maintainer scripts
19:38 < white> like we don't do that directly, just the installer does it
19:38 < h01ger> pere, file a bug. (localisation-config)
19:38  * h01ger loves policy. sorry :-D
19:39 < white> i see the problem with upgrading
19:39 < sepski> we should add a template, that we can pressed in our installer, that prevents automatic breakage in stock debians
19:39 < pere> h01ger: vorlon got his fact wrong.  the bug was not ignored for two years.  we have worked hard for two years to get more debconf preseeding support into packages.
19:39 < white> but not with messing up conffiles
19:39 < white> pere: yeah definetely
19:39 < h01ger> and i believe we can work it out. and why should we really care, if debian-edu-config is not in etch? we have our own archive anyway?
19:39 < h01ger> (atm)
19:39 < sepski> perhaps label it something like "Enable debian-edu cfengine crontab nightly"
19:40 < white> it is bad publicity and i hate to wear the had of ignoring policy which is NOT true
19:40 < sepski> and i realy would like to make  the cfengine script rerunable
19:40 < h01ger> the syslogd-patch is not accepted by joey, not because of the question (re: white's reply to that bug), but because of the debconf-dependency. aba suggested to take it to ctte - which i have not done yet, cause i dont want to harm joey's motivation on debian more. but i really should do it now...
19:40 < pere> sepski: our config editing is only enabled when called by the installer.  there is nothing editing anything just by installing debian-edu-config.
19:41 < white> sepski: and that is the whole thing
19:41 < white> sepski: policy forbids to do that in the maintainer scripts which we are NOT doing
19:41 < h01ger> OH
19:41 < h01ger> but why do we break upgrades than?
19:41 < white> yeah everybody mixes that up and get's it wrong, so all in all we are NOT NOT NOT breaking written policy
19:41 < h01ger> (thats the reason for that policy rule)
19:42 < sepski> i have read the bug, but perhaps more layers of obscurity would let them allow it ?
19:42 < h01ger> white, but we do break the spirit (-> see breaking upgrades), dont we?
19:42 < vagrantc> not breaking the specific wording of the policy, but still breaking the spirit of the policy, which is why i think the release-managers have taken the interpretation the way they have.
19:42 < white> well how can we upgrade to another distro
19:42 < pere> h01ger: there are two issues with upgrades.  a debian-edu installation  being upgraded will ask the admin about a lot of conffiles the admin did not change
19:42 < white> slowly, i am tired :)
19:43 < h01ger> white, i also think #370339 should be reopened. it's a bug, even if you declare /etc/issue not to be important.
19:43 < white> vagrantc: i guess a lot of people just misunderstood it, seriously
19:43 < pere> second, our replacing files with symlinks will be undone whena package is upgraded, and thus the system looses the configuration.
19:43 < white> h01ger: i was just a bit annoyed by the maintainer and his stupid reaction
19:44 < white> vagrantc: then a kolab bootstrap script is also policy spirit violation!
19:44 < pere> but I believe we need to first check the cfengine rules to verify that we still need all of them.  and for those we still need, we need to submit bugs asking for preseeding support.
19:44 < white> it is doing exactly the same, just not as mich as debian-edu-config, but still
19:45 < vagrantc> white: then file a bug on kolab.
19:45  * h01ger thinks fingerpoiting to other packages is stupid. filing bugs against them is more sensible.
19:45 < white> vagrantc: and on every other package which tries to help the user by providing a script to build up a configuration?
19:45 < white> vagrantc: that will cause in a lot of angry users
19:45 < white> h01ger: i am the maintainer there anyway ;)
19:45 < h01ger> white, so i will reopen the bug :) OTOH i sympathy with the notion that debian-edu is debian :)
19:45 < pere> h01ger: then you have missed the point.  My point is that I believe providing scripts to modify configuration files are ok.
19:45 < vagrantc> white: and will provide the pressure to make the packages more configurable.
19:46 < white> h01ger: thanks
19:46 < white> vagrantc: not really userfriendly
19:46 < h01ger> white, for what? reopening or letting it being closed? (i'm undecided on /etc/issue)
19:46 < pere> if that isn't ok, the entire d-i is broken.  it is one huge package to modify other packages config files.
19:46 < vagrantc> the key difference was that the admin does not run any of the debian-edu configuration scripts- it happens without their knowledge.
19:47 < white> vagrantc: that just happens with the debian-edu-install-udeb which is called during installation
19:47 < white> vagrantc: and they use a different CD anyway
19:47 < white> vagrantc: with having a normal debian this never ever happens
19:47 < white> h01ger: that is up to you, you can explain the maintainer that we are still debian and no fork :)
19:47 < pere> ok, to try to bring the discussion back.
19:48 < pere> who are working on reducing the amount of editing we have to do?
19:48 < h01ger> pere+white, i would appreciate if you would discuss this with the RMs. (if you think that the spirit of policy is not broken..)
19:48  * h01ger is (slowly)
19:48 < white> pere h01ger: i would love to
19:48 < pere> h01ger: I will have to collect more motivation before I am ready to start on that discussion again.
19:49 < white> i guess an IRC meeting would be the best place for that
19:49 < white> as i hate endless threads of unclear emails about that and more misunderstandings
19:49 < pere> and I would rather spend that time on improving upgradability, instead of convincing the RM that their policy statement is irrational.
19:49  * h01ger nods (irc works better here than mail)
19:50 < h01ger> i believe this discussion can be short..
19:50 < white> let's move on
19:50 < h01ger> yes
19:50 < pere> http://release.debian.org/etch_rc_policy.txt is the RM policy, just for the record
19:50 -!- pere changed the topic of #debian-edu to: Meeting in progress: Agenda point "apt-key management"
19:51 < pere> h01ger: you have been working on this?
19:51 < pere> (for the last point, update-foo scripts might be a solution.  for example for syslog.conf.
19:52 < h01ger> pere, no. burried in RL & work :/
19:52 < white> does the current debian-edu-archive-keyring package work
19:52 < white> ?
19:52 < pere> there is a debian-edu-archive-keyring package, and I believe it work
19:53 < white> i don't believe that it will be accepted in debian and do we really need it there?
19:53 < white> i still don't get the point in having it in debian
19:53 < white> sorry
19:53 < pere> but it is not as nice as the debian-archive-keyring package, because the latter uses apt-key update, and apt-key update only uses the official keyring files.
19:53 < pere> I changed it to call apt-key add /our/keyring in the postinst, and this got it working.
19:53 < white> pere: isn't that a bug in apt-key update?
19:54 < pere> but to get network installation working, we need to make sure our key is inserted before debootstrap is called by d-i.
19:54 < h01ger> pere, why do you prepfer "apt-key update" over ".. add"?
19:54 < pere> h01ger: apt-key update do more than add
19:55 < pere> see the doc for the difference.  update seem to be the correct thing to use from the postinst.
19:55 < pere> there is the apt-setup (or simliar) udeb taking care of copying the debian keyring file into /target/ before debootstrap starts.  we should probably provide our own hook into that package to do the same.
19:56 < pere> any volunteers to look at this?
19:57 < pere> our keyring package is uploaded into debian (stuck in NEW, but that is a different story), and available from our archive.
19:57 < h01ger> pere, update only also does removing. which we wont need until etch+1...
19:57 < white> if you right it onto a todo list than i will look into it soon
19:57 < sepski> if we got all our packages in debian we woudnt need a separake key would we ?
19:57 < white> sepski: yes
19:57 < pere> sepski: if we get them into debian/etch, right.
19:57 < white> we target that for etch+1
19:58 < white> sepski: and then we hopefully don't need an own archive anymore
19:58 < h01ger> white, where is the todo-list you're speaking about?
19:58 < white> h01ger: so far nowhere, but i forget the points when they are not written down ;(
19:58 < sepski> put it on bugs.skolelinux.no
19:58 -!- pere changed the topic of #debian-edu to: Meeting in progress: Agenda point "user/host management in ldap"
19:59 < pere> we are still without webmin, and no replacement is available either.
19:59 < pere> who put the point on the agenda?  Anyone want to say anything?
19:59 < white> well we can use whatever tool we want as long as it supports our ldap scheme
19:59 < sepski> i put it there since i struggeled to test users.
20:00 < white> but i didn't put it on
20:00 < sepski> i ended up pulling a ldap base from sarge and feeding it to etch
20:00 < sepski> just for testing
20:00 < pere> yes, this suck.
20:00 < sepski> yes :/
20:01 < pere> we can either start maintaining webmin, or come up with some other alternative.
20:01 < sepski> how about this cipux that was so much talk about earlier ? is that debified ? or not ?
20:01 < white> pere: we should have a look what is in debian
20:01 < pere> the most pressing part is a adduser replacement.  we also need something to update netgroups
20:01 < pere> and it should be simple to use.
20:01 < white> there are various admin tools afaik in debian
20:02 < pere> cipux has been proposed, but I am not sure about its state, nor if it will replace all of webmin or just wlus
20:02 < white> sepski: it might be an option but i don't see the main commitments into the debian-edu main brunch, you?
20:02 < sepski> no nothing :/
20:02 < white> sepski: yeah :(
20:03 < sepski> how about phpldapadmin ?
20:03 < white> i just had a lot of talks about all the addon cds and everything and now we offered support and nothing, but that is the next point
20:03 < sepski> i have used it previously, but it's not exactly easy.
20:03 < white> there is also one called useradmin
20:03 < white> or something similiar
20:04 < sepski> white, i thougt that was a webmin addon ?
20:04 < white> sepski: nope
20:04 < white> sepski: i forgot the name but it is already in debian
20:04 < pere> anyone willing to look into the ldap updating issue until the next meeting?
20:05 < pere> there are two parts of this.  one is host admin (webmin-like), and the other is ldap config (wlus, webmin-ldap-netgroup like)
20:05 < pere> oh, well.  we will have bring it up again later.
20:05 -!- pere changed the topic of #debian-edu to: Meeting in progress: Agenda point "ustatus of merging french addons into base"
20:06 < white> just as a side note at the end of this topic i am still waiting for the new live-package which will include all our patches
20:06 < white> so that we can use it on administrator
20:06 < white> alright french addons
20:06 < white> i brought it up
20:06 < white> so far i saw several people helping to merge stuff from the french addon cd into the main branch
20:06 < white> this also includes cipux afaik
20:06 < white> i saw pere werner and me explaining stuff, offereing things, and so on
20:07 < white> various times, today i started the last try
20:07 < white> pere: i am against adding the addon cd question if there is no reaction, sorry
20:08 < white> pere: i don't know how you see it, but for me i won't spend a lot of thought about it anymore i guess
20:08 < white> not until someone steps in and specifically asks for stuff
20:08 < white> this might sound a bit rough and i don't mean it in a bad way
20:09 < h01ger> have you included this opinion in your "last try"?
20:09 < pere> instead of a question, what about adding an kernel option like debian-edu-expert?
20:09 < white> pere: there is one reason why i disagree
20:09 < pere> 'extra-cd' or similar?
20:09 < white> that this leads to the behavior to forget about debian-edu/skolelinux main branch and just work on own stuff and ignoring everything we do
20:09 < sepski> why can't they have their stuff in the regular cd ? included in the archive ?
20:10 < pere> but this is just a minor technical detail.  the real problem is that the "french" packages are not part fo the regular CD release.
20:10 < white> sepski: i am really seeking for an answer to that question
20:10 < white> sepski: and seriously they got any help we could give them
20:10 < pere> I believe the problem is that there is only [-oskar-] from the french team working on it, and he can't manage it all by himself.
20:11 < white> and again i like the french guys, every of them so this is not meant in a bad way! i explicitely say that again
20:11 < white> the same for the germans
20:11 < white> pere: well then there won't be a french addon cd anyway
20:11 < pere> but I agree, we need to get the extra from france and germany packages into debian and into our repository.
20:11 < sepski> having a lot to do is a common problem, is this something more of us could help them with ? do they have their sources in svn ?
20:11 < pere> sepski: they are using the alioth svn
20:12 < pere> several of the packages are already there, I believe.
20:12 < white> sepski: maybe you want to ask them on debian-edu@l.d.o.
20:12 < pere> where is the wiki page with a list of such packages?
20:12 < white> sepski: maybe you find things i completely missed
20:13 < white> pere: there is afaik one list, the merging list which Werner started
20:13 < pere> yes, URL?
20:13 < white> hold on
20:13 < white> hmm still searching ;(
20:14 < white> not on the main page
20:14 < white> i am still looking for it, just keep on going
20:16 < white> no sorry can't find it ;(
20:16 < pere> it seem to be like this group agree that it is important to get the packages we use into debian and/or our own archive.  but that does not bring us forward.  the french team  members are not here.  I hope it isn't because the final time for this meeting was set a few hours ago.
20:17 < sepski> lets be more predictable in the next meeting schedule and announcement
20:17 -!- jever [~juergen@pD9574B15.dip.t-dialin.net] has joined #debian-edu
20:17 < pere> what do we do?  white proposes to ignore those packages and focus on other things.  I am still not ready to give up on them, but will not spend much time on the topic either.
20:18 < white> pere: donÄt get me wrong, i help them when they come up with something
20:18 < white> but i am not running behind them to get them here
20:18  * jever = Jürgen Leibner
20:18 < pere> perhaps there is some misunderstanding somewhere, they waiting for us and we waiting for them?
20:19 < white> don't know, maybe someone wants to work on that and contact them?
20:19 < pere> I am waiting for the maintainer of the french and german extra pakcages to approach me and ask for sponsoring.
20:19 < white> for the record:
20:19 < white> http://wiki.debian.org/DebianEdu/MovingFrAddonsIntoBase
20:19 < white> i am waiting for help them with questions regarding our archive
20:20 < pere> my sponsoring preferences are documented in <URL: http://www.student.uit.no/~pere/debian-sponsoring.html >.
20:20 < white> checking packages or even uploading them into our archive
20:20 < sepski> well they can still read both the log and the summary.
20:20 < pere> yeah.
20:20 < pere> one last item I forgot to put on the agenda: artwork
20:21 -!- pere changed the topic of #debian-edu to: Meeting in progress: Agenda point "artwork"
20:21 < white> wait
20:21 < white> i guess i said enough about live-package or other questions?
20:21 < white> just in case not a real point but still
20:21 -!- pere changed the topic of #debian-edu to: Meeting in progress: Agenda point "astatus of merging french addons into base"
20:21 < white> so i will start to build the live cd when the live-package is ready, which should happen soon
20:22 < white> but this is not my main area,but still just for the record
20:22 < white> pere: thanks and sorry for the delay, just move on
20:22 < pere> right.  I am curious how it will work.
20:22 < white> me too :)
20:22 < white> i mean the CD
20:23 < pere> my tries to get the germans to build the live cd they are working on using a.s.n haven't had any effect yet.  I suspect it is because there is manual labour involved in the german live cd build
20:23 < white> live-package was rather easy
20:23 < pere> ok, on to artwork
20:23 < white> and i could add some nice patches
20:23 -!- pere changed the topic of #debian-edu to: Meeting in progress: Agenda point "artwork"
20:23 < white> first of all great job pere beside the kubuntu stuff it rocks :)
20:23 < pere> the debian-edu-artwork package need someone with artistic skills to make a better CD boot screen, a boot splash screen, kdm loging screen and kde wallpaper.
20:24 < sepski> is is possible to theme ldm ? it's a ugly duckling at the moment
20:24 < pere> white: thanks.  took me 2.5 days to get that far
20:24 < vagrantc> sepski: it's possible to get very basic theming for ldm.
20:24 < pere> and there is still some policy breaking editing of kdmrc being done to enable the kdm theme.
20:25 < pere> sepski: sure, that is possible.  I just had forgotten that.  Yes, we need an ldm theme too
20:25 < pere> but I believe the kdm and ldm theme should look the same
20:25 < white> yes
20:26 < vagrantc> so that it's impossible to troubleshoot which login manager they're running? :)
20:26 < sepski> can something be done with ldm button and haveing 2 boxes 1 for user and 1 for password ? the way ity is now is a bit awkward
20:26 < vagrantc> sepski: how's your python?
20:27 < pere> vagrantc: well, there might be subtle differences. :)
20:27 < sepski> just like my greek, (non exsistant) :/
20:27 < vagrantc> sepski: i.e. i don't think you can configure that just with themes- it requires possibly significant changes to the source.
20:28 < sepski> vagrantc, okay
20:28 < pere> anyway, the most pressing is the kde wallpaper.  the current one is too drastic.  we need something duller, that do not draw attention away from the application windows.
20:28 < vagrantc> sepski: feel free to pose questions like this to pkg-ltsp-devel@lists.alioth.debian.org
20:28 < pere> so if any of you got a better image, just commit it over the current ones in the -artwork package.
20:29 < white> and of course make sure that it is free :)
20:29 < pere> yes, GPL with source.
20:30  * white just finished the main-server test installation of etch-test which ran through
20:30 -!- JeanCharles [~chatzilla@ANancy-156-1-28-156.w83-203.abo.wanadoo.fr] has joined #debian-edu
20:30 < pere> thought the lack of "source" isn't a very big deal.  after all, sepski's friend managed to remove the kubuntu logo from the PNG, and the PNG was all we got.
20:30 < sepski> pere i can ask my coworker that fixed the login dialog, if he knows any thing about making backdrops too. but he to have much to do
20:31 < pere> sepski: or just find some nice-looking artwork on the net with a good license.
20:31 < sepski> what's  "the source" for such a image ? the gimp layered file ?
20:31 < white> sepski: xpm is accepted i guess
20:32 < sepski> been googeling  http://images.google.com/images?svnum=10&hl=en&lr=&safe=off&q=nice+wallpaper&btnG=Search  .. but it might be too distracting
20:32 < pere> newcomers, please indicate your presense with /me = Full Name
20:32 < sepski> my gf screams bloody murder we cant remove the nice school kid pinguin. :)
20:32 < pere> sepski: I have no idea.  the prefered form for modifications is the common test.
20:33 < white> sepski: do not touch the kid pinguin at all ;)
20:33 < white> i love it
20:33 < white> s/it/him/ !
20:33 < pere> I've saved the gimp file next to the images I made, but do not know if it is useful for others.
20:34 < pere> ok, are we done?  Next meeting?
20:34 < pere> 3 weeks?
20:35 < sepski> are we still on a 4 week rotation ?
20:35 < sepski> i feel the wtch release is coming up quickly
20:35 < pere> right.  I guess we are.  forgot about that
20:35 < sepski> well i can do it faster
20:35 < sepski> if others want too
20:35 < white> can we maybe have one on the weekend or even in 4 weeks
20:35 < white> then i might be out of my lecture time
20:35 < pere> perhaps we should have a meeting before the next release date?
20:36 < pere> and I believe october 8 or 15 are good dates for test02.
20:36 < white> but please still go ahead i can write emails about my points
20:36 < pere> by that time I expect ltsp and gnash to work as they should.
20:37 < pere> should we say meet 9. of october, and release the 15?
20:37 < pere> or release 15. and meet the 16?
20:37 < sepski> 15 is after devcamp ?
20:37 < pere> or release october 8 and 22, and meet the 16?
20:37 < white> then i would rely on a good summary if that is ok with you
20:38 < white> or what about having a meeting during the dev meeting?
20:38 < white> then a lot of developers will be in oslo and i can work during the weekend
20:38 < pere> having irc meetings during a dev-meeting have never worked before.
20:38  * vagrantc = Vagrant Cascadian
20:38 < pere> too much happening in real-life with people gathered.
20:38 < white> pere: alright, i never tried it
20:38 < pere> very hard to get the people at a gathering to sit down for an irc meeting.
20:39 < pere> after all, they want to get as much as possible out of the face-to-face opportunities
20:39 < white> pere: i believe that, was just a quick idea
20:39 < white> i hope you guys are on IRC otherwise i will give you a call and make sure you come online ;)
20:39 < pere> so, when should we have the next meeting?  should we schedule releases and meetings together, or just release when we feel like it and meet regularly?
20:39 < pere> I believe the latter is best for productivity
20:40 < white> i vote for the last one as well
20:40 < pere> ok.  lets meet october 16
20:41 < pere> same time as today, 17:00 UTC
20:41 < white> maybe one hour earlier?
20:41 < pere> maybe?
20:41 < white> or hold on i can just check my lecture stuff, if i stil have lectures then
20:41 < pere> 18:00 CET is fine with me.
20:41 < white> otherwise i might be able to attend
20:42 < sepski> ok for me too
20:42 < white> no i fear i still have lectures, so i try my best but can't promise anything, sorry
20:43 < pere> ok.  I close this meeting, and wish you all luck on your journey