[opensuse-factory] Re: Meeting minutes dist meeting 2007-03-23
Andreas Jaeger wrote: [...]
* Status on print configuration
- Discussion on opensuse-factory has been started. - Cups 1.2 has policies - and there's also discussion about role based YaST. We should avoid too many different solutions. - Red Hat seems to use hal backend. - Looking at Fedora solutions, they have some database for automatic setup. - not sure what can be done in time for 10.3
I'm wondering how this _result_ came up. The discussion on opensuse-factory seemed to have stopped, whereas in the dist meeting were now some results presented, which seem not to honor some important facts, and seem not to be common positions. So I cannot agree with the later listed results, i.e. the RedHat/Fedora related ones. Why we should _not_ use Hal backend: - We cannot use hal backend, if we have need to support printing ability of multifunction printers (scanner/printer/fax). The lock of the usb device when supporting the scanning functionality is the main reason. - To have a full support of printers, we need to support vendor specific backends (!= hal backend), like those from HP or Epson. - The hal backend lacks still of implementation of new features of the cups-1.2.x system. The upstream maintainer (RedHat/Fedora) doesn't show any activity regarding this since release of cups-1.2x (9 months). ==> outdated. - It's not necessary to use the hal backend just to have the hal functionality of plugin/remove of printers use. Writing a hal policy file (.fdi file) with call of an Novell/SuSE specific tool should be enough/better. We should not use the automatic setup solution from Fedora: - The origin of the database seems not to be public. We cannot react if we want to handle all of our supported printers just before a product realase. We are always one release cycle behind RedHat/Fedora if we want to use their solution. No improvements at our side. - The automatic setup didn't show any further development at Fedora/RedHat since quiet some time (it's outdated!). This was the main reason, why even Ubuntu/Debian went away and uses now printerdrake. - We already have a in-house solution, named YaST!!! Why cant we use that? YaST already does automatic printer installation, when doing a new system installation. It should be no major effort, to enhance YaST in such a way that we get an command-line interface to do this. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, 2007-03-26 at 14:41 +0200, Klaus Singvogel wrote:
Andreas Jaeger wrote: [...]
* Status on print configuration
- Discussion on opensuse-factory has been started. - Cups 1.2 has policies - and there's also discussion about role based YaST. We should avoid too many different solutions. - Red Hat seems to use hal backend. - Looking at Fedora solutions, they have some database for automatic setup. - not sure what can be done in time for 10.3
I'm wondering how this _result_ came up.
The discussion on opensuse-factory seemed to have stopped, whereas in the dist meeting were now some results presented, which seem not to honor some important facts, and seem not to be common positions.
I noted the discussion had stalled on factory, we became way bogged down on the issue of root vs non-root, questioning the fundamental use case after it was agreed on in previous dist meetings rather than focusing on solutions for the cases, so Chris Rivera has been doing more research that should be reported this week.
So I cannot agree with the later listed results, i.e. the RedHat/Fedora related ones.
Why we should _not_ use Hal backend: - We cannot use hal backend, if we have need to support printing ability of multifunction printers (scanner/printer/fax). The lock of the usb device when supporting the scanning functionality is the main reason. - To have a full support of printers, we need to support vendor specific backends (!= hal backend), like those from HP or Epson. - The hal backend lacks still of implementation of new features of the cups-1.2.x system. The upstream maintainer (RedHat/Fedora) doesn't show any activity regarding this since release of cups-1.2x (9 months). ==> outdated. - It's not necessary to use the hal backend just to have the hal functionality of plugin/remove of printers use. Writing a hal policy file (.fdi file) with call of an Novell/SuSE specific tool should be enough/better.
I said in the dist meeting I was not convinced we should use the hal backend, I was noting RedHat uses it and has no intention of stopping. We may still need to solve the hal uri -> cups usb URI mapping problem though if we want to trigger intelligent behavior when a usb printer is plugged in.
We should not use the automatic setup solution from Fedora: - The origin of the database seems not to be public. We cannot react if we want to handle all of our supported printers just before a product realase. We are always one release cycle behind RedHat/Fedora if we want to use their solution. No improvements at our side.
I noted it could be a starting point, nothing more. How do we generate our database? No one in the previous dist meetings indicating we had a good mapping of printers to print drivers and noted that previous efforts to collect this data had failed.
- The automatic setup didn't show any further development at Fedora/RedHat since quiet some time (it's outdated!). This was the main reason, why even Ubuntu/Debian went away and uses now printerdrake. - We already have a in-house solution, named YaST!!! Why cant we use that? YaST already does automatic printer installation, when doing a new system installation. It should be no major effort, to enhance YaST in such a way that we get an command-line interface to do this.
Fine with me to examine, but no one had proposed this at all, as noted above the discussion got completely side tracked on the root/non-root issue. -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
JP Rosevear wrote:
On Mon, 2007-03-26 at 14:41 +0200, Klaus Singvogel wrote: I noted the discussion had stalled on factory, we became way bogged down on the issue of root vs non-root, questioning the fundamental use case after it was agreed on in previous dist meetings rather than focusing on solutions for the cases, so Chris Rivera has been doing more research that should be reported this week.
Thanks for the update.
Why we should _not_ use Hal backend: [...]
I said in the dist meeting I was not convinced we should use the hal backend, I was noting RedHat uses it and has no intention of stopping. We may still need to solve the hal uri -> cups usb URI mapping problem though if we want to trigger intelligent behavior when a usb printer is plugged in.
hal provides for a device the same information, which usb backend of CUPS uses: vendor, model, serial number. A few execptions are done for some vendors: so "Hewlett-Packard" (regardless of lower-/uppercase writing) is always mapped to "HP". This was done to be compatible with PPD and ICC spec naming. It should be easy with these information to do a mapping between hal device_id and the cups device_uri naming. A simple scan should be enough. :-)
We should not use the automatic setup solution from Fedora: - The origin of the database seems not to be public. We cannot react if we want to handle all of our supported printers just before a product realase. We are always one release cycle behind RedHat/Fedora if we want to use their solution. No improvements at our side.
I noted it could be a starting point, nothing more. How do we generate our database? No one in the previous dist meetings indicating we had a good mapping of printers to print drivers and noted that previous efforts to collect this data had failed.
YaST already uses one. :-) To summarize it: CUPS collection of PPD files (/usr/share/cups/model/*) contains the information for which printer drivers (please note the plural form) can be used (and how) for a single, specific printer. One PPD file for a specific printer contain the word "(recommended)" in the field "*NickName". But there exists a specific subdirectory below /usr/share/cups/model : /usr/share/cups/model/manufacturer-PPDs. If there is a printer listed in one of these sub-subdirectories there, then this printer driver should be prefered, otherwise the one from above: with "(recommended)" in the field "*NickName". Note that /usr/share/cups/model consists of subdirectories, and /usr/share/cups/model/manufacturer-PPDs is one of them, but needs to be handled special. If you're unfamiliar with PPD files, or need just a source reference about them, use: http://partners.adobe.com/public/developer/en/ps/5003.PPD_Spec_v4.3.pdf
- The automatic setup didn't show any further development at Fedora/RedHat since quiet some time (it's outdated!). This was the main reason, why even Ubuntu/Debian went away and uses now printerdrake. - We already have a in-house solution, named YaST!!! Why cant we use that? YaST already does automatic printer installation, when doing a new system installation. It should be no major effort, to enhance YaST in such a way that we get an command-line interface to do this.
Fine with me to examine, but no one had proposed this at all, as noted above the discussion got completely side tracked on the root/non-root issue.
Ok. But I still had the feeling that those steps can be developed independently from each others. Please forgive me for my ongoing discussing, even there are situation where someone might see a break for investigation. I'm having the feeling that we could still discuss the other parts, as they can be developed independently. There are more or less obvious interfaces for me in development: the call-backs of the hal system, the mapping of "hal device ids" <-> "cups usb device_uris", the selection of a printer driver and installation process (or the enhancement of YaST). But also the remove of a printer when unplugged happens, and the book-keeping for a change of state when a reboot happens. Please keep in mind, that installation of printers in the CUPS system is boot persistent, but this contradicts the plug/unplug philosophie and the volatile installation of hal devices. So an additional mechanism needs to be developed here. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, 2007-03-26 at 16:40 +0200, Klaus Singvogel wrote:
hal provides for a device the same information, which usb backend of CUPS uses: vendor, model, serial number.
A few execptions are done for some vendors: so "Hewlett-Packard" (regardless of lower-/uppercase writing) is always mapped to "HP". This was done to be compatible with PPD and ICC spec naming.
It should be easy with these information to do a mapping between hal device_id and the cups device_uri naming. A simple scan should be enough. :-)
After further investigation I don't think using the HAL backend buys us anything if we need to keep the usb backend around. It just creates more work mapping between the two uri schemes to resolve ambiguities without giving us any real benefit other than being cleaner. In an ideal world HAL would be used to detect hardware, but we can still leverage HAL callouts without using the HAL uri scheme.
We should not use the automatic setup solution from Fedora: - The origin of the database seems not to be public. We cannot react if we want to handle all of our supported printers just before a product realase. We are always one release cycle behind RedHat/Fedora if we want to use their solution. No improvements at our side.
I noted it could be a starting point, nothing more. How do we generate our database? No one in the previous dist meetings indicating we had a good mapping of printers to print drivers and noted that previous efforts to collect this data had failed.
YaST already uses one. :-)
Is /var/lib/YaST2/ppd_db.ycp the one you're referring to? How is this generated? Where do you get the mapping information from? Also, Fedora uses Foomatic, which is in no way private. Is there any reason why we don't ship and use Foomatic? There are tools other than Yast that need a printer to ppd/driver mapping. The parsing and fuzzy mapping of ppd files on the system is painful. It would be nice to have one solution used by all of our tools.
- The automatic setup didn't show any further development at Fedora/RedHat since quiet some time (it's outdated!). This was the main reason, why even Ubuntu/Debian went away and uses now printerdrake.
Printerdrake also uses automatic queue setup. See https://wiki.ubuntu.com/PrinterDrake.
- We already have a in-house solution, named YaST!!! Why cant we use that? YaST already does automatic printer installation, when doing a new system installation. It should be no major effort, to enhance YaST in such a way that we get an command-line interface to do this.
I'd be happy to chat with you about the requirements for this piece of the puzzle and how we can go about doing this.
There are more or less obvious interfaces for me in development: the call-backs of the hal system, the mapping of "hal device ids" <-> "cups usb device_uris", the selection of a printer driver and installation process (or the enhancement of YaST). But also the remove of a printer when unplugged happens, and the book-keeping for a change of state when a reboot happens.
We might not even need a mapping for the uris. We can simply use the callout as a "a new printer was added" event. We can then use the list of printers detected by the backends and compare them to the list cups knows about to figure out which printers need to be setup. Just a thought. Chris --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Chris Rivera wrote:
On Mon, 2007-03-26 at 16:40 +0200, Klaus Singvogel wrote:
After further investigation I don't think using the HAL backend buys us anything if we need to keep the usb backend around. It just creates more work mapping between the two uri schemes to resolve ambiguities without giving us any real benefit other than being cleaner. In an ideal world HAL would be used to detect hardware, but we can still leverage HAL callouts without using the HAL uri scheme.
Yes, I came to the same result after doing these investigations. Thanks.
We should not use the automatic setup solution from Fedora: - The origin of the database seems not to be public. We cannot react if we want to handle all of our supported printers just before a product realase. We are always one release cycle behind RedHat/Fedora if we want to use their solution. No improvements at our side.
I noted it could be a starting point, nothing more. How do we generate our database? No one in the previous dist meetings indicating we had a good mapping of printers to print drivers and noted that previous efforts to collect this data had failed.
YaST already uses one. :-)
Is /var/lib/YaST2/ppd_db.ycp the one you're referring to? How is this generated? Where do you get the mapping information from?
Sorry, but I'm not the author of the printer part of YaST2. It's developed in Czech, and I think the current developers name is Michal Zugec. I noticed this possibility of YaST during last installation, and thought it is worth telling about here.
Also, Fedora uses Foomatic, which is in no way private. Is there any reason why we don't ship and use Foomatic?
Sorry to say, but we ship Foomatic too. But it's possible to ship Foomatic in different ways: as an uncompiled database or with compiled PPDs. In the past (cups-1.1.x) it was necessary to ship it in compiled form, but now (cups-1.2.x) distributions have the choice as both ways are supported. I still kept the compiled form, because it seems to be less error prone, it's easier to remove unsupported printers in the database (e.g. due to license issues), and to find those which are supported, as they contain a more mnemonic file name in the system (finding them via beagle or findutils-locate).
There are tools other than Yast that need a printer to ppd/driver mapping. The parsing and fuzzy mapping of ppd files on the system is painful. It would be nice to have one solution used by all of our tools.
I think we shouldn't dig to deep into YaST here, and let YaST do it's magic as it is. An additional commandline interface with a valid cups device-uri should be enough. Letting YaST doing all the rest of the installation magic without spending to much effort in rewriting the code. :-) I'm thinking of this kind of interface: yast install_printer usb://Brother/HL-5150D%20series
- The automatic setup didn't show any further development at Fedora/RedHat since quiet some time (it's outdated!). This was the main reason, why even Ubuntu/Debian went away and uses now printerdrake.
Printerdrake also uses automatic queue setup. See https://wiki.ubuntu.com/PrinterDrake.
Aah, yes. Thanks.
- We already have a in-house solution, named YaST!!! Why cant we use that? YaST already does automatic printer installation, when doing a new system installation. It should be no major effort, to enhance YaST in such a way that we get an command-line interface to do this.
I'd be happy to chat with you about the requirements for this piece of the puzzle and how we can go about doing this.
I'm not quiet sure now, if I'm the right person. I'm not very familiar with YaST, it's Michal Zugec. I only know a lot about CUPS, Foomatic, and the gory internals of those. And I'll be happy if I can share those information with you. My goal is to get the best perfect fitting solution for our distribution whatever we can get. If you still think that I'm the right person, feel free to contact by any kind of media you want to use: telefon, groupwise messanger, irc, etc.
There are more or less obvious interfaces for me in development: the call-backs of the hal system, the mapping of "hal device ids" <-> "cups usb device_uris", the selection of a printer driver and installation process (or the enhancement of YaST). But also the remove of a printer when unplugged happens, and the book-keeping for a change of state when a reboot happens.
We might not even need a mapping for the uris. We can simply use the callout as a "a new printer was added" event. We can then use the list of printers detected by the backends and compare them to the list cups knows about to figure out which printers need to be setup. Just a thought.
I agree with you. But I was talking about a different situation: a printer gets removed from the system while there was a shutdown. I had the feeling that we don't get any HAL callouts of "a printer is removed" when the system comes up again. But the information of the installed printer is still stored in the CUPS system. How is this printer removed in CUPS then, if we don't get the callout? Another advantage when doing this kind of book-keeping can be: The configuration of the removed printer can be stored in a different place. Next time when the same printer gets replugged, the stored information (e.g. resolution, default page size, etc) can be used, and there is no data loss in the configuration. But... it should be clear that YaST shouldn't be used in such a case for printer installation. Just a thought about future enhancements. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 2007-03-28 at 18:17 +0200, Klaus Singvogel wrote:
Sorry to say, but we ship Foomatic too.
The only foomatic package I see is foomatic-filters. All other ppds on my system are provided by cups-drivers or vendor specific packages.
There are tools other than Yast that need a printer to ppd/driver mapping. The parsing and fuzzy mapping of ppd files on the system is painful. It would be nice to have one solution used by all of our tools.
I think we shouldn't dig to deep into YaST here, and let YaST do it's magic as it is.
I'm not 100% convinced that Yast is the right tool for this. There are other tools, like gnome-cups-manager, that still need this same functionality. A simple mapping solution should be available to all system tools, not just Yast. Chris --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Chris Rivera wrote:
On Wed, 2007-03-28 at 18:17 +0200, Klaus Singvogel wrote:
Sorry to say, but we ship Foomatic too.
The only foomatic package I see is foomatic-filters. All other ppds on my system are provided by cups-drivers or vendor specific packages.
Yes, true. You might not find it, if you're just looking at the names. :-) "cups-drivers" contains the foomatic database, but some additional drivers too. I don't think that there are good reasons to rename it at the moment. I think even more it helps the customer to classify the package as a cups related package, whereas "foomatic-db" might not. :-)
There are tools other than Yast that need a printer to ppd/driver mapping. The parsing and fuzzy mapping of ppd files on the system is painful. It would be nice to have one solution used by all of our tools.
I think we shouldn't dig to deep into YaST here, and let YaST do it's magic as it is.
I'm not 100% convinced that Yast is the right tool for this. There are other tools, like gnome-cups-manager, that still need this same functionality. A simple mapping solution should be available to all system tools, not just Yast.
Correct. The maping needs to be done by a helper tool, which is called by a HAL callout. And it should then call a further tool (with the mapping information) which does the installation of the printer in CUPS. Please keep in mind that there are specifications how much time a tool can maximum run, when being a HAL callout. Whereas the first tool needs still to be written, and could (in theorie) call any printer installation tool in second step. So do I think the later should become YaST, as it already contains a lot of the needed code for PPD selection, etc. But even more: it's independend of the used desktop system (politically clean and therefore might get accepted by the KDE fraction and X11 purists too :-), and even runs on headless server machines. I might have given additional reasons in the past why we should use YaST for the installation process. I will look them up, if you're still in doubt. I have this workflow in mind: HAL --callout--> "helper tool" (tbd) --device mapping--> YaST Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, I added Michal Zugec, the author of the YaST printer module to CC. On Mar 28 11:37 Chris Rivera wrote (shortened):
I noted it could be a starting point, nothing more. How do we generate our database? No one in the previous dist meetings indicating we had a good mapping of printers to print drivers and noted that previous efforts to collect this data had failed.
YaST already uses one. :-)
Is /var/lib/YaST2/ppd_db.ycp the one you're referring to?
Basically this is a leftover from old days when YaST also supported old-style printing systems like LPRng/lpdfilter. Currently it is merely the YaST version (a YaST YCP data structure) of a PPD info cache what CUPS has as /var/cache/cups/ppds.dat and from which CUPS can show the "lpinfo -l -m" output quite fast (i.e. without parsing all PPDs under /user/share/cups/model/ again).
How is this generated? Where do you get the mapping information from?
The details can be answered by Michal Zugec. Basically the mapping is based upon a tricky manufacturer and model string comparison (don't expect they match exactly) together with "recommended" info from the NickName in the PPDs and the PPD's sub-directory and a lot of hope that it works well ;-) see https://bugzilla.novell.com/show_bug.cgi?id=220712#c11
Fedora uses Foomatic
In the past (I don't know about the current state) Red Hat's printer setup tool was not in compliance to CUPS because it worked based upon Foomatic's XML-like database files. What the tool did was to generate a PPDs file on the fly from Foomatic's XML-like database files and then set up the queue with this new generated PPD file. If a printer setup tool uses whatever "private" data source, the consequence is that this tool will set up different stuff than all the other tools which work in compliance to CUPS like "lpadmin", CUPS web frontend, YaST, KDE printer setup tool, Gnome printer setup tool, HPLIP printer setup tool, ... The only way a printer setup tool can work in compliance to CUPS is to use the PPDs under /user/share/cups/model/ and nothing else. Stricty speaking even this is wrong since CUPS 1.2 because CUPS 1.2 supports printer drivers which generate PPDs on the fly (note the difference to printer setup tools which do this!) so that since CUPS 1.2 the only way a printer setup tool can work in compliance to CUPS 1.2 is to work based upon CUPS's "lpinfo -l -m" output (or matching CUPS library calls). Regarding "PPD generation on the fly" by printer drivers see http://www.cups.org/newsgroups.php?s1+gcups.general+v2+T0+Q%22PPD+generation... This means that as soon as there are printer drivers which generate PPDs on the fly, YaST does no longer work in compliance to CUPS.
There are tools other than Yast that need a printer to ppd/driver mapping.
Note the "device-id" field in "lpinfo -l -m" which matches a 1284DeviceID entry in the PPD file and which should (hopefully) match how the model shows up at the parallel port or USB.
The parsing and fuzzy mapping of ppd files on the system is painful.
Unfortunately many PPDs don't have a 1284DeviceID entry and therefore the painful fuzzy mapping via manufacturer and model name is all what can be done for many models. But it doesn't work too bad if the manufacturer shows reasonable manufacturer and model name via USB (which is e.g. often true for HP but often false for Epson).
Printerdrake also uses automatic queue setup. See https://wiki.ubuntu.com/PrinterDrake.
As far as I know Till Kamppeter is involved in PrinterDrake and Till knows very well how to work in compliance to CUPS so that PrinterDrake might be a much better example how it can be done than the Red Hat tool (which doesn't mean that looking at Red Hat's tool is forbidden ;-)
We might not even need a mapping for the uris.
If we find a way how to do it without such a mapping, it would be great because actually such a mapping cannot work because nobody can predict what whatever (third-party) backend will use for its URIs.
We can simply use the callout as a "a new printer was added" event. We can then use the list of printers detected by the backends and compare them to the list cups knows about to figure out which printers need to be setup.
You mean compare the "lpinfo -l -v" output to the "grep DeviceURI /etc/cups/printers.conf" output? With some tricks it might work (at least at the moment I don't see why it cannot work at all - like the URI mapping). Perhaps it is sufficient to filter the "lpinfo -l -v" output to ignore those URIs which are only generic placeholders but don't mean a real detected printer. At least all URIs which are only the scheme (i.e. the backend name and no colon and stuff after the colon) don't mean a real detected printer (see "man backend"). Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, On Monday, March 26, 2007 at 14:41:54, Klaus Singvogel wrote:
Andreas Jaeger wrote: [...]
* Status on print configuration
- Discussion on opensuse-factory has been started. - Cups 1.2 has policies - and there's also discussion about role based YaST. We should avoid too many different solutions. - Red Hat seems to use hal backend. - Looking at Fedora solutions, they have some database for automatic setup. - not sure what can be done in time for 10.3
I'm wondering how this _result_ came up.
This is a result on the status of the discussion. Not a result how we will do things. At the moment we are left with two points to discuss: 1. What to use as policy system 2. How to do auto-configuration Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (5)
-
Chris Rivera -
Henne Vogelsang -
Johannes Meixner -
JP Rosevear -
Klaus Singvogel