1 20:00 < pere> so, lets start. who are present? Please respond with 'I'm here."
2 20:00 < finnarne> I'm here
3 20:01 < white> I'm here
4 20:01 < pwinnertz> I'm here
5 20:01 < k4x> hi
6 20:01 < white> pwinnertz: let's talk about this test later after the meeting
7 20:01 < pere> first topis is who will write the summary. We can not continue before someone volunteers.
8 20:01 < pwinnertz> white: yes
9 20:01 < jemtland> I'm here
10 20:02 < finnarne> argh getting warning about lag here :(
11 20:02 < pere> no-one?
12 20:02 < white> dumdidum
13 20:02 < pwinnertz> pere: I can write a summary... i would write it tomorrow morning :)
14 20:02 < white> pwinnertz: do you really have the time?
15 20:02 < white> pere: i can do it ...
16 20:02 < pwinnertz> white: i have tomorrow 4 free-lessons
17 20:02 < white> pwinnertz: then make test installations!!! ;)
18 20:02 < pwinnertz> and i have to stay in school :S
19 20:02 < pwinnertz> white: after the meeting ;-)
20 20:03 < pere> white pwinnertz: please make up your minds. who write the summary?
21 20:03 < white> pwinnertz: let me write this one and you write the next one ok?
22 20:03 < pwinnertz> white: okay...
23 20:03 < white> pere: ok go on please
24 20:03 < pere> ok, we move on to the current status. what is the status?
25 20:04 < white> finnarne: 3 RC bugs left i think
26 20:04 < white> we have to verify 2 of them
27 20:04 < white> one needs to be fixed
28 20:04 < white> and we have to make a decision tonight what to do with other small bugs
29 20:04 < white> that's it i would say
30 20:05 < pere> anyone else with some status info?
31 20:05 < pwinnertz> white: i report today a new bug... there is a problem with the installation of a terminalserver... this is a problem of cfengine i think
32 20:05 < pere> what exacly are the rc issues?
33 20:05 < finnarne> I'm checking a fresh install to see if the 2 bugs are actually closed
34 20:05 < white> pwinnertz: i think we only provide a runnging system *with* a tjener
35 20:05 * pere is quite sure the ldm background issue is fixed.
36 20:05 < white> pwinnertz: so no RC severity
37 20:06 < klausade> white: what do you mean by " i think we only provide a runnging system *with* a tjener"?
38 20:06 < pwinnertz> yes, of course... but what happens if you installed the terminalserver BEFORE the tjener? or you install the terminalserver without being connected to the tjener
39 20:06 < finnarne> background looks like it's fixed
40 20:06 < white> klausade: if there is no tjener we are currently not saying that the installations are completely running
41 20:06 < pwinnertz> this is the problem i see...
42 20:06 < white> klausade: the system has to have access to the tjener
43 20:06 < pere> white: yes, reommended install order is 'first install main-server', then install the rest. But I do not believe there are technical reasons to fail to install, it should just fail to work.
44 20:07 < finnarne> firefox printing is fixed
45 20:07 < klausade> white: one very popular implementation, and very sucessfull, is the use of a ltsp-server together with windows AD, hence no tjener.
46 20:07 < finnarne> so we're left with 1 major bug, and that is kmail config #550
47 20:07 < white> pere: but i don't see a release blocker with this bug
48 20:07 < klausade> white: another popular use is ltsp-server togeher with some other linux distro, and also no tjener.
49 20:07 < pere> white: I agree, but something strange must be new in the installer if it _fail_ to install.
50 20:08 < pwinnertz> klausade: yes... the installation should complete without any errors even if no tjener is connected
51 20:08 < finnarne> I still think that ltsp-only will install succesfully from a cd tonight
52 20:08 < pere> so I believe we need to make the installer more robust anywayh.
53 20:08 < klausade> white: if the installation *demands* a tjener, it's a showstopper and blocker, and critical, imho.
54 20:08 < klausade> white: but it's fixed, looks like it.
55 20:08 < white> pere: maybe but i think we should focus on that *after* the release because we release a complete skolelinux network system
56 20:08 < pippin> top
57 20:08 < finnarne> there was some bugs that prevented cfengine from runnign which was critical
58 20:09 < white> klausade: but we should make sure if it is fixed or not before we start a long discussion about it
59 20:09 < pere> white: well. I do not want us to release with such fragile installer. this used to work, and should still work.
60 20:09 < Werner_> I'm here (sorry too late, but too much snow).
61 20:09 < finnarne> and with a failed cfengine, lots of things fail
62 20:09 < white> pwinnertz: when did you find the bug?
63 20:09 < pere> anyway, lets not get hung up on that issue. other status updates to mention?
64 20:09 < pwinnertz> white: this morning
65 20:09 < white> hmm
66 20:10 < finnarne> pwinnertz: which image ?
67 20:10 < white> let's keep it in mind and follow pere to the next issue
68 20:10 < pwinnertz> white: at 10.00 o'clock i think runns the rsync
69 20:10 < pere> I've spent most of my debian-edu time working on the new ltsp packages. still much left before our changes are synced upstream.
70 20:11 < pwinnertz> finnarne: the images was very fresh, you see :)
71 20:11 < klausade> what about #1041, "cfengine tries to setup link to ash which isn't installed.", is that just ash not being on the package list? ash is very handy when you want to resize lv_usr, and must umount /usr to do that.
72 20:11 < pere> I believe ash is now called dash.
73 20:11 < pere> name changed between woody and sarge.
74 20:11 < finnarne> pwinnertz: the cfengine stuff should have been fixed ~09:20
75 20:12 < klausade> pere: still ash in sarge
76 20:12 < pwinnertz> finnarne: mh... i will test it again tomorrow morning
77 20:12 < pere> klausade: ash is a compatibility wrapper in sarge, I believe.
78 20:12 < klausade> pere: yes, look like that.
79 20:13 < klausade> then cfengige shouldn't try to setup a ash link
80 20:13 < pere> klausade: I agree. it should set up a dash link instead.
81 20:13 < klausade> pere: i'll add your comments to #1041
82 20:13 < pere> and it should do it using the procedure documented in /usr/share/doc/bash/README.Debian.gz, to make sure it last across upgrades.
83 20:14 < pere> given the type of comments so far, I guess the CD is installing just fine?
84 20:14 < white> pere: i think so
85 20:14 < finnarne> yes
86 20:15 < pere> I saw someone invalidated the translations for debian-edu-install (the profile question). how are we with getting translations back into the package?
87 20:15 < finnarne> last one tested was 2006-02-06 11:21
88 20:15 < Werner_> which bug # is that?
89 20:15 < white> pere: i am not sure if we are ready
90 20:15 < pere> Werner_: the lack of translations? not a bug, as such.
91 20:16 < white> pere: we changed a bit for the barebone stuff but now we should stay with the old translations i think
92 20:16 < pere> did someone send a reminder to the translators when the text was changed?
93 20:16 < white> nope
94 20:16 < Werner_> ahh .. we lack translations after the barebone-stuff .. those strings isn't displayed in an usual install.
95 20:16 < white> or at least for the barebone stuff some time ago and i got some updates and added them
96 20:16 < white> but i am not sure if all languages are updated
97 20:17 < white> and maybe it is better for the release when we use the old ones because we are not using barebone for the next release
98 20:18 < pere> how many translations are outdated and updated?
99 20:18 < finnarne> and also (I) changed standalone from experimental to working status, but that text is fixed, at least for norwegian
100 20:18 < white> pere: 50/50 %
101 20:18 < Werner_> only new strings for the barebone profile..
102 20:18 < white> Werner_: yes
103 20:18 < pere> white: what are the numbers? how many?
104 20:19 < Werner_> finnarne: that string is possibly the important one..
105 20:19 < finnarne> yes, and it's important that it was changed
106 20:19 < Werner_> pere: two new strings for the barebone profile and the one finnarne mentions..
107 20:19 < white> pere: i am not completely sure but i think 5-6 are updated
108 20:19 < finnarne> because now, people are installign ubunutu or whatever instead, because standalone was "experimental"
109 20:20 < pere> white: I checked, and only nb.po is updated.
110 20:20 < Werner_> an upload of debian-edu-install to debian and reminding the last translators will probably help a lot.
111 20:20 < pere> 21 is not.
112 20:21 < white> pere: hmm but i got various updates and i also applied them!
113 20:21 < pere> Werner_: I recommend reminding the translators first, using for example the podebconf-report-po program.
114 20:21 < Werner_> ok .. I'll do that tonight.
115 20:21 < white> pere: anyway let's remind the translators again
116 20:21 < white> Werner_: thx
117 20:21 < pere> white: I use this formula to test: for fin *.po; do echo -n "$f "; msgfmt --statistics $f; done
118 20:22 < pere> s/fin/f in/
119 20:22 < Werner_> pere: doesn't the translators like to download the po-file from the debian package and report a bug?
120 20:22 < pere> Werner_: I do not know, but sending them the .po file in email and asking them to submit new versions to bts works. :)
121 20:23 < pere> ok, lets try to move from status to the next topic: what is left to do?
122 20:23 < Werner_> I guess..
123 20:23 < Werner_> first rc-bug: email client configuration..
124 20:23 < white> pere: at the end of the meeting we should make a vote for the release codename ;)
125 20:24 < Werner_> white: have you had time to test your commit's which should fix the kmail configuration?
126 20:24 < finnarne> what we have now is not working
127 20:24 < white> Werner_: finnarne tested it and it is not working :(
128 20:24 < finnarne> and today - I found out that our removal of kmailrc from /usr/share/debian-edu/... also broke the existing kmail config for some users
129 20:24 < Werner_> ok, do we know what is missing?
130 20:25 < pere> we only have one remaining issue, the mail client config?
131 20:25 < white> finnarne: yes we have to decide it now
132 20:25 < white> switch to skel and make it available only for new users
133 20:26 < white> or stay with debian-edu and make it broken during upgrades
134 20:26 < finnarne> a fresh account is not set up to use postoffice as mail server, the email address of the user is not set up
135 20:26 < white> hmm
136 20:26 < pere> white: skels is a hell to maintain in the long run.
137 20:26 < pere> why was kmailrc removed, and why did it break the config?
138 20:26 -!- Asbjorn_
139 20:26 < white> pere: i know the problem but it upgrades break the config
140 20:26 < finnarne> pere: having kmailrc preconfigured for users using some other mail server is also a nightmare
141 20:26 < white> s/it//
142 20:27 < finnarne> pere: everytime we upgraded debian-edu-config, the user who used kmail lost their mail config
143 20:27 < white> finnarne: do we really want/need a preconfigured kmail for the internal mail stuff?
144 20:27 < finnarne> at least if they used external mail servers
145 20:27 < pere> finnarne: why? didn't the user have their config in ~/.kde/?
146 20:27 < white> finnarne: are there users which uses our mail system?
147 20:27 < finnarne> and 98 % of the user used external mail servers
148 20:28 < white> s/which/who/
149 20:28 < white> finnarne pere: so is there a possibility for us to drop our mail system?
150 20:28 < Werner_> at least we should prevent existing users to loose their configuration .. is that really a problem?
151 20:29 < pere> finnarne: why do users loose their config when debian-edu-config is upgraded? The users config should be in the users home directory, and the overrides in /usr/share/ should not affect it.
152 20:29 < finnarne> pere: because there was an account definition under /usr/share/debian-edu/.../kmailrc
153 20:29 < pere> finnarne: that does not tell me why it broke.
154 20:29 < finnarne> and even if they had their own email config in their .kde
155 20:29 < finnarne> that account information was lost when debian-edu-config was upgraded
156 20:29 < finnarne> so it went like this:
157 20:30 < finnarne> install a working system
158 20:30 < finnarne> set up your email account (to use online.no bzz.no or whatever)
159 20:30 < finnarne> upgrade kmail
160 20:30 < finnarne> shit I lost all my mail
161 20:30 < finnarne> no - it was only the imap info that were lost
162 20:31 < finnarne> or - if they used pop3, they would not get any new mail
163 20:31 < finnarne> ok
164 20:31 < finnarne> fetch from backup
165 20:31 < Werner_> upgrade kmail or upgrade debian-edu-config ?
166 20:31 < pere> finnarne: when you say upgrade kmail, do you mean from woody to sargE?
167 20:31 < finnarne> now everything works
168 20:31 < finnarne> ah - new version of debian-edu-config, lets upgrade
169 20:31 < finnarne> shit - there gores the mail config of the users again :(
170 20:32 < white> finnarne: a bit frustrating i see ;)
171 20:32 < pere> finnarne: so you did not modify the files in d-e-config?
172 20:32 < finnarne> white: I'm glad I have a working backup
173 20:32 < finnarne> pere: no
174 20:32 * pere believe kmail must be seriously broken if it don't accept the users configuration over the defaults in /usr/share/.
175 20:32 < finnarne> it took a while before I understaood why it broke
176 20:32 < pere> never seen any kde app behave like that.
177 20:33 < white> sometimes kmail is a pain
178 20:33 < pere> who removed kmailrc, btw?
179 20:33 < finnarne> pere: this was happening on installation were the servers was installed with sarge.
180 20:33 < finnarne> pere: I think white did, after I've told him this
181 20:34 < white> pere: finnarne and me decided to switch to skel and remove the files under debian-edu ... to prevent breaking upgrades
182 20:34 < finnarne> so now, when kmailrc is gone from /usr/share/debian-edu/.. i know that upgrading debian-edu-config wont break things in the future.
183 20:35 < pere> the point of using the KDEDIRS stuff and having defaults in /usr/share/ is to support upgrades. with skels, the only (and fraglie, bound to break accounts) way to handle upgrades it to rewrite configuration files in the users home directories.
184 20:35 < pere> finnarne: perhaps you do, but I know that upgrading packages will break users configuration in the future. :)
185 20:35 < Werner_> maybe we should drop trying to autoconfigure kmail for the sarge-release?
186 20:35 < white> pere: so then let's think about a new solution
187 20:35 < finnarne> well - sane applications would upgrade their old config files
188 20:35 < white> i would agree to Werner_
189 20:36 < finnarne> Werner_: I agree
190 20:36 < white> pere: so can we drop the config for ... kmail
191 20:36 < pere> finnarne: nope, sane apps do not change their config files. when they "upgrade them", they also make it impossible to use the same home directory with different versions of the software.
192 20:37 < finnarne> pere: it depends on the config file and the app
193 20:37 < finnarne> pere: maybe kmail will behave better in the future
194 20:38 < Werner_> so do all agree about dropping autoconfiguration of kmail for postoffice(.intern) ? pere: ?
195 20:38 < pere> finnarne: I did a talk on this topic during debconf5 in helsinki. :) And no, I do not believe it depend nor on the config file nor the app. :)
196 20:38 < pere> If we stop configuring the mail clients, we can just as well drop the mail service. after all, we provide a working out of the box solution.
197 20:39 < finnarne> but believe me. it's not nice to have 5 schools calling because the upgrade of debian-edu-config broke 40-400 configs on each school
198 20:40 < pere> finnarne: are you saying that kmail look at the date of the kmailrc file in /usr/share/ when deciding if it should use the info or not?
199 20:40 < pere> finnarne: I see no other way it would care about the content of the file when the users have overrides in ~/.kde/.
200 20:41 < finnarne> pere: i dont know, but I can maybe provide you with some config files from the users homedir, that show that it was changed because kmailrc was changed under /usr/share/debian-edu/
201 20:41 < pere> that do not match my understanding of the KConfig class behaviour.
202 20:41 < white> arguing about the kmail topic is not very productive
203 20:42 < white> pere: then we have to find a way we can provide configuration for kmail
204 20:42 < pere> I guess the question is if we should provide a working email service out the box or not. I believe we should.
205 20:42 < finnarne> there is no way that 30 teachers logged in to break kmail last nigth, so that their mail client stopped working this morning
206 20:42 < white> :)
207 20:42 < finnarne> we have a working email service
208 20:42 < finnarne> but just dont use kmail
209 20:42 < finnarne> use thunderbird instead
210 20:43 < finnarne> that's the result
211 20:43 < finnarne> even though thunderbird is not translated into nb nor nn
212 20:43 < pere> anyone disagreeing that we should provide a mail system that work out of the box?
213 20:44 < finnarne> we have a working mail system
214 20:44 < pere> finnarne: is thunderbird included in the default installation?
215 20:44 < finnarne> but we dont have preconfigured clients
216 20:44 < finnarne> pere: yes
217 20:45 < pere> finnarne: is it configured?
218 20:45 < finnarne> nope
219 20:45 < Werner_> finnarne: do you know approx. how much time we have to use to autoconfigure it?
220 20:45 < pere> how many mail clients are included in the default installation?
221 20:45 < pere> (can we get it down to 1. :)
222 20:46 < Werner_> looking at http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=kmail gives me a good feeling about dropping kmail..
223 20:46 < finnarne> we have 2 clients I believe, kmail and thinderbird
224 20:48 < Werner_> anyone know how hard it is to autoconfigure?
225 20:48 < pere> do kmail and thunderbird use the same mail box format? Can they work on the same files?
226 20:48 < finnarne> pere: We use imap, remember ...
227 20:48 -!- sanoj
228 20:49 < pere> finnarne: you lost me?
229 20:49 < knuty> Werner: Many schools uses kmail.
230 20:50 < pere> I'm not sure we want to tell everyone to switch from kmail to thunderbird, no.
231 20:50 < Werner_> even though they can loose all users configurations?
232 20:50 < pere> anyway, we are making slow progress. lets move on from the mail config issue and on to any other remaining issues. Are there any?
233 20:51 < white> pere: but at the end we should go back to the mail stuff
234 20:51 < pere> white: there is 8 minutes left. :)
235 20:52 < pere> no other issues seem to be remaining. I'm slightly surprised.
236 20:52 < white> pere: ok i think all other points can wait until we released
237 20:52 < white> pere: except one
238 20:52 < white> one RC bug left
239 20:52 < white> and the core team is here so let's decide which codename and version number we use!!!
240 20:53 < white> :)
241 20:53 < white> pere: agree?
242 20:53 < finnarne> I'm thinking about taking a closer look at slapd.conf
243 20:53 < pere> white: did you have an RC bug?
244 20:53 < white> pere: mail configuration ...
245 20:53 < white> pere: means except the mail configuration we are ready to release
246 20:54 < white> pere: so we should also start to think about the name and version
247 20:54 < white> pere: then we can just release after we have a running CD without the last RC bug
248 20:54 < finnarne> lets foxus on ldap for 2 minutes
249 20:54 < Werner_> should we try to make a new pr or rc-relase soon?
250 20:54 < finnarne> argh - focus
251 20:54 < white> pere: please make an order
252 20:54 * pere believe name and version is best left to the person doing the release, and that it should not be a vote or such.
253 20:55 < pere> finnarne: ok, what about ldap?
254 20:55 < finnarne> now - members of the admins group can change the users password.
255 20:55 < finnarne> that is - allusers except the ldap-admin
256 20:56 < Werner_> yes .. ?
257 20:56 < finnarne> there are a few other entries they should be allowed to change, such as
258 20:56 < pere> must be a long one... :)
259 20:57 < white> :)
260 20:57 < finnarne> looking ...
261 20:57 < white> hihi
262 20:57 < finnarne> shadowLastChange
263 20:57 < finnarne> sambaPwdLastSet,sambaPwdCanChange
264 20:57 < finnarne>
265 20:58 < pere> finnarne: did you send an email about this? what are the pros and cons?
266 20:58 < finnarne> nope, but it's needed to allow the group admins to change password properly
267 20:59 < pere> finnarne: why? what is using shadowLastChange?
268 20:59 < pere> which tools need these fields writable?
269 20:59 < finnarne> the pros are that admins can change password, and set when when the password should be changed again.
270 21:00 < finnarne> shadowLastChanged is used to tell kdm that the user must change password
271 21:01 < klausade> pere: shadowLastChange is needed if you want to setup a regime where the user must change their passwords first time they logon. without being able to write shadowLastChange, they must change theur password every time they logon (been there done that)
272 21:01 < finnarne> and sambaPwdlastSet and CanChange is updated when the samba password is updated
273 21:02 < pere> you seem to talk about two different issues. one is the fields writable by admins on other users, the other is the fields writable by the users themselv.es
274 21:03 < finnarne> yes, but they need to be possible to be written by both
275 21:03 < Werner_> meeting is over .. I'll have to leave for an hour or two :/
276 21:03 < finnarne> admins set ShadowLastChange=0
277 21:03 < finnarne> kdm sees this
278 21:03 < finnarne> user set password and shadowLastChange =today
279 21:04 < finnarne> ok - Werner_ said it
280 21:04 < pere> can the user trick the system into allowing him to use a password forever by keeping that date some time in the future?
281 21:05 < pere> yes, we need to wrap up this meeting.
282 21:05 < pere> next meeting date?
283 21:05 < finnarne> in 2 weeks
284 21:05 < pere> monday 2006-02-20?
285 21:05 < white> yes and hopefully with a released debian-edu ;)