[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
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
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
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
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
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
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
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
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
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
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
20:52 < white> pere: ok i think all other points can wait until we
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: