Re: [opensuse-factory] Minutes from 2007-03-23 dist meeting

2007-03-24 Thread Andreas Jaeger
Ludwig Nussel [EMAIL PROTECTED] writes:

 Andreas Jaeger wrote:
 Let's look what can be done for ntp - and later look at other
 services.  Note the ntp service is also usefull for machines without
 network (serial DCF77 clock).  Right now the dispatcher script sends a
 signal to ntp if the IP address changes but during boot ntp starts
 even if network is not running.
 
 Suggestion: ntp start script should figure out if NetworkManager is
 running and if it is only start if network is up - otherwise the
 dispatcher script will start it.

 At home my ntpd starts up with no servers defined and the ip-up
 script adds time servers via ntpdc IIRC. Requires that the local
 clock is sufficiently exact though. I'm not sure if there is a way
 to remove time servers from a running ntpd again though.

Yeah, there are some challenges to get all usecases right.

 Dial-in support for NetworkManager to support ISDN, Modem, UMTS, 3G
 cards is beeing worked on and should be ready for openSUSE 10.3.

 Whatever that means. Does it use existing config files as created by
 yast?

Better ask the experts, we didn't go into details,

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
  SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
   Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpxdoujD1pNP.pgp
Description: PGP signature


[opensuse-factory] Minutes from 2007-03-23 dist meeting

2007-03-23 Thread Andreas Jaeger

Here are the minutes from yesterday's dist meeting.  If you have any
questions, comments, ideas, please speak up!

Thanks,
Andreas


* Enabling more network services to be NetworkManager aware, e.g. ntp and autofs

This is in general desired but might need quite large rework for some
services like autofs that do not handle IP changes properly.

Proposal: Services should be aware that network goes up/down and
handle no network (instead of timing out).

Let's look what can be done for ntp - and later look at other
services.  Note the ntp service is also usefull for machines without
network (serial DCF77 clock).  Right now the dispatcher script sends a
signal to ntp if the IP address changes but during boot ntp starts
even if network is not running.

Suggestion: ntp start script should figure out if NetworkManager is
running and if it is only start if network is up - otherwise the
dispatcher script will start it.

AI: Work together on ntp.

Dial-in support for NetworkManager to support ISDN, Modem, UMTS, 3G
cards is beeing worked on and should be ready for openSUSE 10.3.

* Checkin policy for specific projects and how to track them

Current example is postgresql.  This was a question for security
update of old distributions.  The maintenance team grants exceptions
on a case by case basis, e.g. if the new version just fixes the
security problem.

* AppArmor: Move the profiles from our package to their packages

This would allow easier tracking of changes in packages.  On the other
hand a central place might give some extra review.

Consensus: If the format is stable enough, we should distribute the
profiles.  Once we do it, we should train the packagers and institure
some review process for the profiles to maintain a high quality.

Beside manual page apparmor.d(5) a short documentation for packagers
in plain english of the format is missed.

AI: talk to Apparmor folks.

* Faster booting?
  What can be done here?

  Booting consists of kernel startup, initrd and System V scripts.
  The bootchart scripts do measure the System V scripts but not the
  initial ramdisk.

  Idea: Snapshotting at gdm/kdm time: Write a snapshot and resume at
  the next boot back to this version.  This is different from suspend
  to disk.

  Filesystem fragmentation under Linux is in general not a problem -
  but it is a problem in booting.  Therefore measurements have to be
  done on freshly installed systems.

AI: Generate some bootcharts to show current bottlenecks.

* Shrink the basepackages (packages always installed for building)

  With todays changes we seem to be able to do a self-contained
  build of base with just 72 source packages (spec files).  By heavily
  stripping the set of basepacks of course.  And we have side-by-side
  compiles against the openSUSE config to compare logfiles (no differences
  sofar).

  This means that e.g. vim and strace will be removed from the build
  environment.  The autobuild team will add options to build to easily
  add debug tools to the tree.

AI: Show list of packages to autobuild to adjust configs, announce
changes to opensuse-packaging - and run comparisions of the complete
system to check that all requirements are met.
  
* Email notifications for checkins for not novell addresses

Package.changes file coming from the build service might contain
non-Novell email addresses.  We decided to not send any autobuild
emails to those adddresses.

AI: implement whitelist of domains (currently @novell.com,
@suse.de, @suse.cz)


Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
  SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
   Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgplLVk7rDt0L.pgp
Description: PGP signature


Re: [opensuse-factory] Minutes from 2007-03-23 dist meeting

2007-03-23 Thread M9.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Andreas Jaeger schreef:
 Here are the minutes from yesterday's dist meeting.  If you have any
 questions, comments, ideas, please speak up!

 Thanks,
 Andreas


 * Enabling more network services to be NetworkManager aware, e.g. ntp and 
 autofs

 This is in general desired but might need quite large rework for some
 services like autofs that do not handle IP changes properly.

 Proposal: Services should be aware that network goes up/down and
 handle no network (instead of timing out).

 Let's look what can be done for ntp - and later look at other
 services.  Note the ntp service is also usefull for machines without
 network (serial DCF77 clock).  Right now the dispatcher script sends a
 signal to ntp if the IP address changes but during boot ntp starts
 even if network is not running.

 Suggestion: ntp start script should figure out if NetworkManager is
 running and if it is only start if network is up - otherwise the
 dispatcher script will start it.

This is also a good idea, to make sure things happen as they should...

 AI: Work together on ntp.

 Dial-in support for NetworkManager to support ISDN, Modem, UMTS, 3G
 cards is beeing worked on and should be ready for openSUSE 10.3.

 * Checkin policy for specific projects and how to track them

 Current example is postgresql.  This was a question for security
 update of old distributions.  The maintenance team grants exceptions
 on a case by case basis, e.g. if the new version just fixes the
 security problem.

 * AppArmor: Move the profiles from our package to their packages

 This would allow easier tracking of changes in packages.  On the other
 hand a central place might give some extra review.

 Consensus: If the format is stable enough, we should distribute the
 profiles.  Once we do it, we should train the packagers and institure
 some review process for the profiles to maintain a high quality.

 Beside manual page apparmor.d(5) a short documentation for packagers
 in plain english of the format is missed.

 AI: talk to Apparmor folks.

 * Faster booting?
   What can be done here?

   Booting consists of kernel startup, initrd and System V scripts.
   The bootchart scripts do measure the System V scripts but not the
   initial ramdisk.

   Idea: Snapshotting at gdm/kdm time: Write a snapshot and resume at
   the next boot back to this version.  This is different from suspend
   to disk.

This looks like a smart idea, suspend to disk sometimes fails, but if it
works, it takes a little less time than a complete boot...(and one is
were one left off..)


   Filesystem fragmentation under Linux is in general not a problem -
   but it is a problem in booting.  Therefore measurements have to be
   done on freshly installed systems.

 AI: Generate some bootcharts to show current bottlenecks.

 * Shrink the basepackages (packages always installed for building)

   With todays changes we seem to be able to do a self-contained
   build of base with just 72 source packages (spec files).  By heavily
   stripping the set of basepacks of course.  And we have side-by-side
   compiles against the openSUSE config to compare logfiles (no differences
   sofar).

   This means that e.g. vim and strace will be removed from the build
   environment.  The autobuild team will add options to build to easily
   add debug tools to the tree.

 AI: Show list of packages to autobuild to adjust configs, announce
 changes to opensuse-packaging - and run comparisions of the complete
 system to check that all requirements are met.

 * Email notifications for checkins for not novell addresses

 Package.changes file coming from the build service might contain
 non-Novell email addresses.  We decided to not send any autobuild
 emails to those adddresses.

 AI: implement whitelist of domains (currently @novell.com,
 @suse.de, @suse.cz)


 Andreas

- --


Have a nice day,

M9.   Now, is the only time that exists.



  OS:  Linux 2.6.18.2-34-default x86_64
  Huidige gebruiker:  [EMAIL PROTECTED]
  Systeem:  openSUSE 10.2 (X86-64)
  KDE:  3.5.5 release 45.2
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGA853X5/X5X6LpDgRAkSlAKCYzeoTZCANKbbHms+9R/v0W/KpQACfeu4T
/jAH1II0jLbE2gHQxpsGvK8=
=z2cG
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-factory] Minutes from 2007-03-23 dist meeting

2007-03-23 Thread Ludwig Nussel
Andreas Jaeger wrote:
 Let's look what can be done for ntp - and later look at other
 services.  Note the ntp service is also usefull for machines without
 network (serial DCF77 clock).  Right now the dispatcher script sends a
 signal to ntp if the IP address changes but during boot ntp starts
 even if network is not running.
 
 Suggestion: ntp start script should figure out if NetworkManager is
 running and if it is only start if network is up - otherwise the
 dispatcher script will start it.

At home my ntpd starts up with no servers defined and the ip-up
script adds time servers via ntpdc IIRC. Requires that the local
clock is sufficiently exact though. I'm not sure if there is a way
to remove time servers from a running ntpd again though.

 Dial-in support for NetworkManager to support ISDN, Modem, UMTS, 3G
 cards is beeing worked on and should be ready for openSUSE 10.3.

Whatever that means. Does it use existing config files as created by
yast?

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE Labs
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-factory] Minutes from 2007-03-23 dist meeting

2007-03-23 Thread JP Rosevear
On Fri, 2007-03-23 at 14:44 +0100, Ludwig Nussel wrote:
 Andreas Jaeger wrote:
  Let's look what can be done for ntp - and later look at other
  services.  Note the ntp service is also usefull for machines without
  network (serial DCF77 clock).  Right now the dispatcher script sends a
  signal to ntp if the IP address changes but during boot ntp starts
  even if network is not running.
  
  Suggestion: ntp start script should figure out if NetworkManager is
  running and if it is only start if network is up - otherwise the
  dispatcher script will start it.
 
 At home my ntpd starts up with no servers defined and the ip-up
 script adds time servers via ntpdc IIRC. Requires that the local
 clock is sufficiently exact though. I'm not sure if there is a way
 to remove time servers from a running ntpd again though.
 
  Dial-in support for NetworkManager to support ISDN, Modem, UMTS, 3G
  cards is beeing worked on and should be ready for openSUSE 10.3.
 
 Whatever that means. Does it use existing config files as created by
 yast?

Potentially, just as we can use yast info for wireless and wired configs
now, however the upstream implementation will not do this by default of
course, it will have its own PPP config UI.  How much knowledge we can
extract from yast to implement the upstream config is an open question.

Longer term however, I think the approach is almost definitely to use NM
everywhere (of course it needs a lot of work to get there for things
like static routes, multiple interfaces at the same time etc, but when
discussed with the Mobile and Server teams several months ago there was
general agreement on this direction).

-JP
-- 
JP Rosevear [EMAIL PROTECTED]
Novell, Inc.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-factory] Minutes from 2007-03-23 dist meeting

2007-03-23 Thread Ludwig Nussel
JP Rosevear wrote:
 On Fri, 2007-03-23 at 14:44 +0100, Ludwig Nussel wrote:
  Andreas Jaeger wrote:
   Dial-in support for NetworkManager to support ISDN, Modem, UMTS, 3G
   cards is beeing worked on and should be ready for openSUSE 10.3.
  
  Whatever that means. Does it use existing config files as created by
  yast?
 
 Potentially, just as we can use yast info for wireless and wired configs
 now, however the upstream implementation will not do this by default of
 course, it will have its own PPP config UI.  How much knowledge we can
 extract from yast to implement the upstream config is an open question.

Which distro serves as model for the upstream config?

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE Labs
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-factory] Minutes from 2007-03-23 dist meeting

2007-03-23 Thread jdd

Andreas Jaeger wrote:


  Idea: Snapshotting at gdm/kdm time: Write a snapshot and resume at
  the next boot back to this version.  This is different from suspend
  to disk.


the différence needs to be explained (in function way, not in 
implementation way) : what are the différences for the user?


In fact, I usually don't use suspend because when I need a start, it's 
rarely to continue the very same work I did at shutdown. (usually I 
beging lurking at my mail and need this fast, the remaining can wait 
or be done in the background)


Notice than the competitor (at least XP) displays its desktop very 
soon, but there is still some time before anywork can be done. on the 
contrary, when Kde is started it's immediately available.


this is very typical of the OS way of life: Linux want to be 
effective, Win to be good looking. However, in this precise case, may 
be we could take a snapshot (just an image of the desktop - is that 
the snpshot you speak about there up?) of the screen that will be 
restored?? (not sure I should like it :-)



* Shrink the basepackages (packages always installed for building)

  With todays changes we seem to be able to do a self-contained


should be a good idea to have a pattern old fashioned base system 
for people used to what is now openSUE :-)


jdd


--
http://www.dodin.net
Lucien Dodin, inventeur
http://lucien.dodin.net/index.shtml
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse-factory] Minutes from 2007-03-23 dist meeting

2007-03-23 Thread Jonathan Arsenault
On Fri, 2007-03-23 at 17:21 +0100, jdd wrote:
 Andreas Jaeger wrote:
Idea: Snapshotting at gdm/kdm time: Write a snapshot and resume at
the next boot back to this version.  This is different from suspend
to disk.
 
 However, in this precise case, may be we could take a snapshot
 (just an image of the desktop - is that the snpshot you speak about there up?)
 of the screen that will be restored?? (not sure I should like it :-)
 
 jdd

Now am not sure if i want to laugh or cry after such a comment ...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]