Re: [opensuse-factory] Boot speed and services
On Fri 09 Mar 2007 09:01:58 NZDT +1300, Carlos E. R. wrote: > Some system services use email to notify root or the user of some things. > For instance, smart monitoring, raid monitoring, rm installs - there was a > time when Yast mailed the user of some install notices. Yes, having an MTA which can deliver local email is absolutely essential. cron, smartmontools, fetchmail(!), you name it. What would be a very good idea(TM) is if the MTA in its default configuration was prevented from delivering email to other than localhost or one of localhost's domain aliases. I tried this with postfix and found that it's not possible, though there are 2 drastic and not very nice workarounds for this problem. I believe Debian and a few other distros have had a default of "no mail is delivered externally" for a long time. SUSE should do likewise. Note I'm talking about the default config only here. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] no cdrecord
Hi, > > In a separate deprecated package cdrkit-cdrtools-compat. > > Does it get installed in the update case? In most cases it should be, because packages which need the cdrecord symlink should require cdrecord and this is only provided by cdrkit-cdrtools-compat. E.g. if k3b is installed, it requires /usr/bin/cdrecord and since cdrkit-cdrtools-compat is the only package which provides this, the depsolver has to install it. If this does not work, it's a bug. There is a possible case where the package will not be installed on upgrade: If the user had a minimalist system without any package that requires cdrecord (no k3b, no nautilus-cd-burner, no xcdroast etc.), cdrecord will be upgraded to wodim without installing cdrkit-cdrtools-compat. If it is desired to install cdrkit-cdrtools-compat even in that case, a "split provides" can be used. Andreas Hanke -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Printing in openSUSE 10.3
JP Rosevear wrote: > On Tue, 2007-03-06 at 10:58 +0100, Johannes Meixner wrote: [...] > > Your info is too terse for me. > > I still do not understand the end-user's situation. > > Please do not misunderstand me - I don't want to do nitpicking. > > But I need to understand the whole picture from the end-user's point > > of view - otherwise whatever nice-looking implementation may not > > solve the actual end-user problem. > > The situtation is the end user doesn't want to type in a password to do > simple operations. Sorry, but I don't understand you here. Can you please elaborate these operations to me? What are they? [...] > > From my point of view all we may need is a nice GUI to set up > > those policies in cupsd.conf - e.g. an enhancement of the CUPS > > web-interface, see on a CUPS 1.2 system > > http://localhost:631/admin > > "Server" > > Yes, quite possibly with the policy system above. I might rather see a > single yast module that is a starting point for various configurations > of this type of options, ie something like: > > [ ] Primary user can mount removable media > [ ] All users can mount removable media > [ ] Primary user can add and remove printers > [ ] All users can add and remove printers > [ ] Primary user can install, update and remove software > [ ] All users can install, update and remove software I think the comparision isn't very good. Removing media / updating software happens more recently than to add/remove printers. The spooling mechanism of print jobs (even printing to a printer, even not plugged in) is an important feature which is not comparable with the other two situations. > Where the primary user is the first user you create. Ideally we'd be > able to keep this hidden and have a 'Home User' vs 'Traditional Unix > Permissions' option or something. (I'm also not sure this is actually a > Yast module, but it will do for now as an example). This would lead > into a nice system for things like basic parental controls. I agree with the intention, but I'm unhappy with the qualification of "primary user". This is not applicable when setting up a server. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] cvsgraph?
On Mon, 12 Mar 2007, Cristian Rodriguez R. wrote: > Andreas Vetter escribió: > > > > > Thank you for support. That's exactly my point of view. > > > > I personally prefer quality over quantity... however took five minutes > to create a cvsgraph package and should be available shortly at: > > http://ftp-1.gwdg.de/pub/opensuse/repositories/home:/elvigia/openSUSE_10.2 > > aint that hard to do it yourself ;-P Cool, thank you. I use the 10.1 rpm and it works great. -- Regards, Andreas Vetter
Re: [opensuse-factory] Printing in openSUSE 10.3
JP Rosevear wrote: > On Thu, 2007-03-01 at 12:33 +0100, Klaus Singvogel wrote: > > JP Rosevear wrote: [...] > > > entirely impossible, there is some code in /usr/bin/add-unknown-printer > > > (part of the gnome-volume-manager) to do some of this. > > > > We need to mention that the current hal backend needs to be extended > > to satisfy the new requirements, which actual CUPS system expects > > from backends. But it seems that upstream developers didn't work on > > this opportunity till today. > > Well, it works enough to be used extensively in Fedora and Ubuntu, but > yes it could be missing some pieces that we would need to add. Sorry, but to my knowledge Ubuntu isn't using it anymore, due to given reasons. They will move toward PrinterDrake in future: https://wiki.ubuntu.com/PrinterDrake [...] > > Hmm. I had a quick look at the current hal/dbus architecture. I didn't > > see any pollin by any device so far. Instead an administration process > > called by the hal/dbus system is executed. I'm speeking about the > > hal-cups-utils/hal_lpadmin tools. > > Maybe I'm wrong... > > I meant if we want to base the detection on the usb backend we'll need > polling. Sorry, but I'm not able to follow you here. Isn't this polling/interrupt mode depending on the configured dbus/hal callout configuration (the fdi file) and not the used cups backend? If I understood the hal-cups-utils correctly (which Fedora is using), then this is only a small helper tool "/usr/sbin/hal_lpadmin", which is independend from the used cups backend. I don't see at the moment any relationship between polling mode of dbus/hal and the used cups backend. The only advantage of using the hal backend is IMHO that we don't need any additional book keeping about the used backends for configured printer. But (!) as soon as we accept that multi function printers have to use different backends (hplip), and which are not the hal backend, this book keeping has to be done anyway. So I think the hal backend isn't really helpful as soon as we need to support additional backends anyway. And due to given reason (no further developing upstream for new cups features, problems in the past), I still vote not to use the hal backend as default and to use of the usb backend instead. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Printing in openSUSE 10.3
Hi. sorry for delay, but had the flue last week... Chris Rivera wrote: > On Thu, 2007-03-01 at 12:33 +0100, Klaus Singvogel wrote: > > > We need to mention that the current hal backend needs to be extended > > to satisfy the new requirements, which actual CUPS system expects > > from backends. But it seems that upstream developers didn't work on > > this opportunity till today. > > What requirements are you referring to? The backends report now different states of printers back to the cups daemon. > > Hmm. I had a quick look at the current hal/dbus architecture. I didn't > > see any pollin by any device so far. Instead an administration process > > called by the hal/dbus system is executed. I'm speeking about the > > hal-cups-utils/hal_lpadmin tools. > > Maybe I'm wrong... > > Right. HAL callouts are used to add/remove printers when appropriate. So, we can use any program here? Thinking of YaST for automatic de-/installation... > > But if not, then we might replace the hal backend by _any_ backend, > > and no need to use no longer developed tools (hal backend) is needed. > > Instead we can use our own mechanism here, even YaST, as soon as YaST > > supports installation of printers without any need of user feedback > > (full automatism). > > You would have to convert the HAL udis to whatever uri scheme the other > backends use. We might be able get the device node in the callout and > eliminate some of the work for the backends, but this seems kinda > clunky. It would be nice to just take advantage of HAL and use the HAL > udis as persistent printer uris. But does HAL backend work properly for multi function printers (MFP) (= FAX/Scanner/Printer devices)? Does HAL backend always work with _any_ supported OpenSource driver? AFAIK the hplip backend needs to be used to be able to scan with such MFP devices. Using the usb backend caused (locking) problems, when scaning with such devices. As the code of the hal backend is pretty close to the usb backend, I expect same problems here. > > I want to point out, that there should be no goal to remove the usb > > backend from the system. The reasons are the manuals, and the CUPS > > book, which only speaks about this. Also the good help at the cups > > mailing lists should be mentioned, which is no longer usuable for > > the customers, if we cut the usb backend off the system. > > How are ambiguities between the backends resolved? Having both usb and > HAL backends cause the same printer to be detected twice. You need > mappings between uri schemes to avoid this, right? Yes, I think that such a mapping might be necessary. But the libusb provides the same information (vendor, model, serial) as the dbus node contains. I think the program for mapping shouldn't take to long to write down. But a good testing needs to be done though. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
