Log from meeting
20:00 < pere> so, lets start. who are present? Please respond with
'I'm here."
20:00 < finnarne> I'm here
20:01 < white> I'm here
20:01 < pwinnertz> I'm here
20:01 < k4x> hi
20:01 < white> pwinnertz: let's talk about this test later after the meeting
20:01 < pere> first topis is who will write the summary. We can not
continue before someone volunteers.
20:01 < pwinnertz> white: yes
20:01 < jemtland> I'm here
20:02 < finnarne> argh getting warning about lag here :(
20:02 < pere> no-one?
20:02 < white> dumdidum
20:02 < pwinnertz> pere: I can write a summary... i would write it
tomorrow morning :)
20:02 < white> pwinnertz: do you really have the time?
20:02 < white> pere: i can do it ...
20:02 < pwinnertz> white: i have tomorrow 4 free-lessons
20:02 < white> pwinnertz: then make test installations!!! ;)
20:02 < pwinnertz> and i have to stay in school :S
20:02 < pwinnertz> white: after the meeting ;-)
20:03 < pere> white pwinnertz: please make up your minds. who write
the summary?
20:03 < white> pwinnertz: let me write this one and you write the next
one ok?
20:03 < pwinnertz> white: okay...
20:03 < white> pere: ok go on please
20:03 < pere> ok, we move on to the current status. what is the status?
20:04 < white> finnarne: 3 RC bugs left i think
20:04 < white> we have to verify 2 of them
20:04 < white> one needs to be fixed
20:04 < white> and we have to make a decision tonight what to do with
other small bugs
20:04 < white> that's it i would say
20:05 < pere> anyone else with some status info?
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
20:05 < pere> what exacly are the rc issues?
20:05 < finnarne> I'm checking a fresh install to see if the 2 bugs are
actually closed
20:05 < white> pwinnertz: i think we only provide a runnging system *with*
a tjener
20:05 * pere is quite sure the ldm background issue is fixed.
20:05 < white> pwinnertz: so no RC severity
20:06 < klausade> white: what do you mean by " i think we only provide
a runnging system *with* a tjener"?
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
20:06 < finnarne> background looks like it's fixed
20:06 < white> klausade: if there is no tjener we are currently not
saying that the installations are completely running
20:06 < pwinnertz> this is the problem i see...
20:06 < white> klausade: the system has to have access to the tjener
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.
20:07 < finnarne> firefox printing is fixed
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.
20:07 < finnarne> so we're left with 1 major bug, and that is kmail
config #550
20:07 < white> pere: but i don't see a release blocker with this bug
20:07 < klausade> white: another popular use is ltsp-server togeher with
some other linux distro, and also no tjener.
20:07 < pere> white: I agree, but something strange must be new in the
installer if it _fail_ to install.
20:08 < pwinnertz> klausade: yes... the installation should complete
without any errors even if no tjener is connected
20:08 < finnarne> I still think that ltsp-only will install succesfully
from a cd tonight
20:08 < pere> so I believe we need to make the installer more robust
anywayh.
20:08 < klausade> white: if the installation *demands* a tjener, it's
a showstopper and blocker, and critical, imho.
20:08 < klausade> white: but it's fixed, looks like it.
20:08 < white> pere: maybe but i think we should focus on that *after*
the release because we release a complete skolelinux network
system
20:08 < pippin> top
20:08 < finnarne> there was some bugs that prevented cfengine from
runnign which was critical
20:09 < white> klausade: but we should make sure if it is fixed or not
before we start a long discussion about it
20:09 < pere> white: well. I do not want us to release with such fragile
installer. this used to work, and should still work.
20:09 < Werner_> I'm here (sorry too late, but too much snow).
20:09 < finnarne> and with a failed cfengine, lots of things fail
20:09 < white> pwinnertz: when did you find the bug?
20:09 < pere> anyway, lets not get hung up on that issue. other status
updates to mention?
20:09 < pwinnertz> white: this morning
20:09 < white> hmm
20:10 < finnarne> pwinnertz: which image ?
20:10 < white> let's keep it in mind and follow pere to the next issue
20:10 < pwinnertz> white: at 10.00 o'clock i think runns the rsync
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.
20:11 < pwinnertz> finnarne: the images was very fresh, you see :)
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.
20:11 < pere> I believe ash is now called dash.
20:11 < pere> name changed between woody and sarge.
20:11 < finnarne> pwinnertz: the cfengine stuff should have been fixed
~09:20
20:12 < klausade> pere: still ash in sarge
20:12 < pwinnertz> finnarne: mh... i will test it again tomorrow morning
20:12 < pere> klausade: ash is a compatibility wrapper in sarge, I believe.
20:12 < klausade> pere: yes, look like that.
20:13 < klausade> then cfengige shouldn't try to setup a ash link
20:13 < pere> klausade: I agree. it should set up a dash link instead.
20:13 < klausade> pere: i'll add your comments to #1041
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.
20:14 < pere> given the type of comments so far, I guess the CD is
installing just fine?
20:14 < white> pere: i think so
20:14 < finnarne> yes
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?
20:15 < finnarne> last one tested was 2006-02-06 11:21
20:15 < Werner_> which bug # is that?
20:15 < white> pere: i am not sure if we are ready
20:15 < pere> Werner_: the lack of translations? not a bug, as such.
20:16 < white> pere: we changed a bit for the barebone stuff but now we
should stay with the old translations i think
20:16 < pere> did someone send a reminder to the translators when the
text was changed?
20:16 < white> nope
20:16 < Werner_> ahh .. we lack translations after the barebone-stuff
.. those strings isn't displayed in an usual install.
20:16 < white> or at least for the barebone stuff some time ago and i
got some updates and added them
20:16 < white> but i am not sure if all languages are updated
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
20:18 < pere> how many translations are outdated and updated?
20:18 < finnarne> and also (I) changed standalone from experimental to
working status, but that text is fixed, at least for norwegian
20:18 < white> pere: 50/50 %
20:18 < Werner_> only new strings for the barebone profile..
20:18 < white> Werner_: yes
20:18 < pere> white: what are the numbers? how many?
20:19 < Werner_> finnarne: that string is possibly the important one..
20:19 < finnarne> yes, and it's important that it was changed
20:19 < Werner_> pere: two new strings for the barebone profile and the
one finnarne mentions..
20:19 < white> pere: i am not completely sure but i think 5-6 are updated
20:19 < finnarne> because now, people are installign ubunutu or whatever
instead, because standalone was "experimental"
20:20 < pere> white: I checked, and only nb.po is updated.
20:20 < Werner_> an upload of debian-edu-install to debian and reminding
the last translators will probably help a lot.
20:20 < pere> 21 is not.
20:21 < white> pere: hmm but i got various updates and i also applied
them!
20:21 < pere> Werner_: I recommend reminding the translators first,
using for example the podebconf-report-po program.
20:21 < Werner_> ok .. I'll do that tonight.
20:21 < white> pere: anyway let's remind the translators again
20:21 < white> Werner_: thx
20:21 < pere> white: I use this formula to test: for fin *.po; do echo -n
"$f "; msgfmt --statistics $f; done
20:22 < pere> s/fin/f in/
20:22 < Werner_> pere: doesn't the translators like to download the
po-file from the debian package and report a bug?
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. :)
20:23 < pere> ok, lets try to move from status to the next topic: what
is left to do?
20:23 < Werner_> I guess..
20:23 < Werner_> first rc-bug: email client configuration..
20:23 < white> pere: at the end of the meeting we should make a vote
for the release codename ;)
20:24 < Werner_> white: have you had time to test your commit's which
should fix the kmail configuration?
20:24 < finnarne> what we have now is not working
20:24 < white> Werner_: finnarne tested it and it is not working :(
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
20:24 < Werner_> ok, do we know what is missing?
20:25 < pere> we only have one remaining issue, the mail client config?
20:25 < white> finnarne: yes we have to decide it now
20:25 < white> switch to skel and make it available only for new users
20:26 < white> or stay with debian-edu and make it broken during upgrades
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
20:26 < white> hmm
20:26 < pere> white: skels is a hell to maintain in the long run.
20:26 < pere> why was kmailrc removed, and why did it break the config?
20:26 < white> pere: i know the problem but it upgrades break the config
20:26 < finnarne> pere: having kmailrc preconfigured for users using
some other mail server is also a nightmare
20:26 < white> s/it//
20:27 < finnarne> pere: everytime we upgraded debian-edu-config, the
user who used kmail lost their mail config
20:27 < white> finnarne: do we really want/need a preconfigured kmail
for the internal mail stuff?
20:27 < finnarne> at least if they used external mail servers
20:27 < pere> finnarne: why? didn't the user have their config in
~/.kde/?
20:27 < white> finnarne: are there users which uses our mail system?
20:27 < finnarne> and 98 % of the user used external mail servers
20:28 < white> s/which/who/
20:28 < white> finnarne pere: so is there a possibility for us to drop
our mail system?
20:28 < Werner_> at least we should prevent existing users to loose
their configuration .. is that really a problem?
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.
20:29 < finnarne> pere: because there was an account definition under
/usr/share/debian-edu/.../kmailrc
20:29 < pere> finnarne: that does not tell me why it broke.
20:29 < finnarne> and even if they had their own email config in
their .kde
20:29 < finnarne> that account information was lost when debian-edu-config
was upgraded
20:29 < finnarne> so it went like this:
20:30 < finnarne> install a working system
20:30 < finnarne> set up your email account (to use online.no bzz.no
or whatever)
20:30 < finnarne> upgrade kmail
20:30 < finnarne> shit I lost all my mail
20:30 < finnarne> no - it was only the imap info that were lost
20:31 < finnarne> or - if they used pop3, they would not get any new mail
20:31 < finnarne> ok
20:31 < finnarne> fetch from backup
20:31 < Werner_> upgrade kmail or upgrade debian-edu-config ?
20:31 < pere> finnarne: when you say upgrade kmail, do you mean from
woody to sargE?
20:31 < finnarne> now everything works
20:31 < finnarne> ah - new version of debian-edu-config, lets upgrade
20:31 < finnarne> shit - there gores the mail config of the users again :(
20:32 < white> finnarne: a bit frustrating i see ;)
20:32 < pere> finnarne: so you did not modify the files in d-e-config?
20:32 < finnarne> white: I'm glad I have a working backup
20:32 < finnarne> pere: no
20:32 * pere believe kmail must be seriously broken if it don't accept
the users configuration over the defaults in /usr/share/.
20:32 < finnarne> it took a while before I understaood why it broke
20:32 < pere> never seen any kde app behave like that.
20:33 < white> sometimes kmail is a pain
20:33 < pere> who removed kmailrc, btw?
20:33 < finnarne> pere: this was happening on installation were the
servers was installed with sarge.
20:33 < finnarne> pere: I think white did, after I've told him this
20:34 < white> pere: finnarne and me decided to switch to skel and remove
the files under debian-edu ... to prevent breaking upgrades
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.
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.
20:35 < pere> finnarne: perhaps you do, but I know that upgrading packages
will break users configuration in the future. :)
20:35 < Werner_> maybe we should drop trying to autoconfigure kmail for
the sarge-release?
20:35 < white> pere: so then let's think about a new solution
20:35 < finnarne> well - sane applications would upgrade their old
config files
20:35 < white> i would agree to Werner_
20:36 < finnarne> Werner_: I agree
20:36 < white> pere: so can we drop the config for ... kmail
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.
20:37 < finnarne> pere: it depends on the config file and the app
20:37 < finnarne> pere: maybe kmail will behave better in the future
20:38 < Werner_> so do all agree about dropping autoconfiguration of
kmail for postoffice(.intern) ? pere: ?
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. :)
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.
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
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?
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/.
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/
20:41 < pere> that do not match my understanding of the KConfig class
behaviour.
20:41 < white> arguing about the kmail topic is not very productive
20:42 < white> pere: then we have to find a way we can provide
configuration for kmail
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.
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
20:42 < white> :)
20:42 < finnarne> we have a working email service
20:42 < finnarne> but just dont use kmail
20:42 < finnarne> use thunderbird instead
20:43 < finnarne> that's the result
20:43 < finnarne> even though thunderbird is not translated into nb nor nn
20:43 < pere> anyone disagreeing that we should provide a mail system
that work out of the box?
20:44 < finnarne> we have a working mail system
20:44 < pere> finnarne: is thunderbird included in the default
installation?
20:44 < finnarne> but we dont have preconfigured clients
20:44 < finnarne> pere: yes
20:45 < pere> finnarne: is it configured?
20:45 < finnarne> nope
20:45 < Werner_> finnarne: do you know approx. how much time we have to
use to autoconfigure it?
20:45 < pere> how many mail clients are included in the default
installation?
20:45 < pere> (can we get it down to 1. :)
20:46 < Werner_> looking at
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=kmail gives me
a good feeling about dropping kmail..
20:46 < finnarne> we have 2 clients I believe, kmail and thinderbird
20:48 < Werner_> anyone know how hard it is to autoconfigure?
20:48 < pere> do kmail and thunderbird use the same mail box format?
Can they work on the same files?
20:48 < finnarne> pere: We use imap, remember ...
20:49 < pere> finnarne: you lost me?
20:49 < knuty> Werner: Many schools uses kmail.
20:50 < pere> I'm not sure we want to tell everyone to switch from kmail
to thunderbird, no.
20:50 < Werner_> even though they can loose all users configurations?
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?
20:51 < white> pere: but at the end we should go back to the mail stuff
20:51 < pere> white: there is 8 minutes left. :)
20:52 < pere> no other issues seem to be remaining. I'm slightly
surprised.
20:52 < white> pere: ok i think all other points can wait until we
released
20:52 < white> pere: except one
20:52 < white> one RC bug left
20:52 < white> and the core team is here so let's decide which codename
and version number we use!!!
20:53 < white> :)
20:53 < white> pere: agree?
20:53 < finnarne> I'm thinking about taking a closer look at slapd.conf
20:53 < pere> white: did you have an RC bug?
20:53 < white> pere: mail configuration ...
20:53 < white> pere: means except the mail configuration we are ready
to release
20:54 < white> pere: so we should also start to think about the name
and version
20:54 < white> pere: then we can just release after we have a running
CD without the last RC bug
20:54 < finnarne> lets foxus on ldap for 2 minutes
20:54 < Werner_> should we try to make a new pr or rc-relase soon?
20:54 < finnarne> argh - focus
20:54 < white> pere: please make an order
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.
20:55 < pere> finnarne: ok, what about ldap?
20:55 < finnarne> now - members of the admins group can change the
users password.
20:55 < finnarne> that is - allusers except the ldap-admin
20:56 < Werner_> yes .. ?
20:56 < finnarne> there are a few other entries they should be allowed
to change, such as
20:56 < pere> must be a long one... :)
20:57 < white> :)
20:57 < finnarne> looking ...
20:57 < white> hihi
20:57 < finnarne> shadowLastChange
20:57 < finnarne> sambaPwdLastSet,sambaPwdCanChange
20:57 < finnarne>
20:58 < pere> finnarne: did you send an email about this? what are the
pros and cons?
20:58 < finnarne> nope, but it's needed to allow the group admins to
change password properly
20:59 < pere> finnarne: why? what is using shadowLastChange?
20:59 < pere> which tools need these fields writable?
20:59 < finnarne> the pros are that admins can change password, and set
when when the password should be changed again.
21:00 < finnarne> shadowLastChanged is used to tell kdm that the user
must change password
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)
21:01 < finnarne> and sambaPwdlastSet and CanChange is updated when the
samba password is updated
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
21:03 < finnarne> yes, but they need to be possible to be written by both
21:03 < Werner_> meeting is over .. I'll have to leave for an hour or
two :/
21:03 < finnarne> admins set ShadowLastChange=0
21:03 < finnarne> kdm sees this
21:03 < finnarne> user set password and shadowLastChange =today
21:04 < finnarne> ok - Werner_ said it
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?
21:05 < pere> yes, we need to wrap up this meeting.
21:05 < pere> next meeting date?
21:05 < finnarne> in 2 weeks
21:05 < pere> monday 2006-02-20?
21:05 < white> yes and hopefully with a released debian-edu ;)
21:06 < finnarne> pere: I guess the user can, but today, password updates
are not enforced at all
21:06 < pere> we failed to talk about the next gathering. we need to
fix a date for that one too.
21:06 < jemtland> I'll send a mail about it to debian-edu@l.d.o
21:06 < pere> jemtland: what is the current date alternative counts?
Reply to: