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