Our last meeting was moved by a week and I forgot to inform you. Sorry about that. Here're the minutes, Andreas * libata per default We're going to use libata by default for future products. For 10.3, we will implement the following in YaST to handle disks with more than 15 partitions (libata uses the SCSI stack that only allows 15 partitions): If YaST recognizes that an IDE disk has more than 15 partitions and we use libata on it, YaST will display something like the following message: "openSUSE is switching to the new IDE drivers using the libata modules. These do only support partitions with up to 15 partitions. You have the following options with openSUSE 10.3: - Use the old IDE drivers: Boot again and add 'hwprobe=-modules.pata' as argument to the kernel - Repartition your system so that maximal 15 partitions are used. To repartition, use your existing operating system. In the future only the new libata drivers will be supported, so we advice to repartition. Installation will be aborted now." * Hal vs USB backends for cups. The use cases we like to solve are: * Detecting a printer when plugged into the machine and prompting the user to configure it - or even automatically selecting a driver like OS X and have the printer just work. * Not needing root to configure a printer * Detecting when a printer is connected/disconnected and offering virtual feedback * Ability to remove printers from copy when they are unplugged Basically cups is using its USB backend to detect printers. There is a hal backend we are kind of using for GNOME (Fedora also ships it) that only partially integrates. Since the rest of our hardware detection is running through hal, this seems like a sensible move. The discussion showed that there are many open questions and a smaller group will discuss how to move forward. * Splitting languages out of packages Usecases: * Reduced image size especially of thin clients and Live images * Reduced image size for distributions * Updating of single translation should be easier We do not want to make a $lang sub-package for every package, this way we get far too many. The following ideas exist: * convince upstream, e.g. GNOME, to do this similar to KDE. But this will only solve one part of the problem and not the base system. * Alter autobuild to split out languages itself. * Use the lang support in RPM, ie: rpm -i --define "_install_langs fr:es" <package> This would break delta RPMs. The idea is to add to spec file of packages a new rpm macro so that subpackages are created and then related subpackages are repacked for each language in our build system. This way we would get e.g. basesystem-$lang and gnome-$lang packages and those can then be installed. -- Andreas Jaeger, aj@suse.de, 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