Re: CUPS will change license since 2.3 version - now incompatible with GPLv2

[Tim Waugh]

On 8 November 2017 at 09:42, Zdenek Dohnal  wrote:

> CUPS upstream changed license of project to Apache license 2.0, which is
> now incompatible with GPLv2. This change will be in new minor release of
> CUPS - 2.3.0, which is currently in developing phase (not in Fedora for
> now). If someone takes code of CUPS and has its project under GPLv2,
> please change it to GPLv3 (which should be compatible according
> https://fedoraproject.org/wiki/Licensing:Main?rd=
> Licensing#SoftwareLicenses
> ) or try to argument with CUPS developers against this change on their
> mailing list c...@cups.org .
>
> Is there someone who is influenced by this change?
>

Sounds like pycups may need to change license as a result:
https://github.com/zdohnal/pycups/blob/master/cupsconnection.c#L8-L9

Tim.
*/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Round 2 review of Fedora Docker Layered Image Guidelines

[Tim Waugh]

On Thu, 2016-08-18 at 09:28 -0400, Tomas Tomecek wrote:
>  * Guidelines suggest to use "BZComponent" but upstream label
> guidelines mention
>    "com.redhat.component"; I would suggest using the latter one
> (disclaimer: I
>    participated actively in the early history of changes in the label
> name, am
>    quite surprised it's still not sorted out -- not blaming anyone)

Upstream tooling (atomic-reactor) still uses the 'old' label set.
Switching to the lower-case-style labels requires more careful
orchestrating than you would expect.

Tim.
*/


signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

patch(1): symbolic links with .. components in the target accepted again

[Tim Waugh]

The problem with accepting symbolic links with target pathnames
containing .. components has been fixed in patch-2.7.4. Updates are in
testing for Fedora 20 and 21.

https://bugzilla.redhat.com/show_bug.cgi?id=1185928

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

patch(1) no longer applies patches for symbolic links with .. components in the target

[Tim Waugh]

Last week, patch-2.7.3 was released fixing CVE-2015-1196. Both Fedora 20
and Fedora 21 have testing updates:
https://admin.fedoraproject.org/updates/FEDORA-2015-1165
https://admin.fedoraproject.org/updates/FEDORA-2015-1134

The fix prevents patches applying if they are for symbolic links with a
target containing the .. pathname component:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775901#13

Please be aware that some legitimate patches may fail as a result, until
a better fix can be found.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Packaging ghostscript's X11 support separately

[Tim Waugh]

Hi,

I'd like to move %{_libdir}/ghostscript/9.15/X11.so into its own package
so that ghostscript can be used without pulling in libX11 etc.

All that needs to be done is to package X11.so separately, and if gs can
load it at runtime it can provide x11* drivers. If not, it won't.

I could package it in its own sub-package, ghostscript-x11, but that
might be a bit surprising to people who expect 'ghostscript' to have an
x11alpha driver.

Alternatively I could move everything else from ghostscript to a new
sub-package ghostscript-base, and have 'ghostscript' (i.e. just the
X11.so plugin) require ghostscript-base (i.e. everything else).

Opinions either way?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On-demand launching via socket activation

[Tim Waugh]

On Wed, 2014-09-10 at 12:55 -0400, Matthias Clasen wrote:
 I think its a great idea. If you want to propose it, we can discuss it
 in the next WG meeting (I sadly saw this too late for the one that just
 ended...).

OK. I've filed this: https://fedorahosted.org/workstation/ticket/8

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

On-demand launching via socket activation

[Tim Waugh]

Hi,

I'd like to have the default cups presets be:
enable cups.socket
enable cups.path
disable cups.service

In other words, I'd like cupsd to start when accessed locally
via /var/run/cups/cups.socket, and when there are unprocessed files in
the spool directory, but not otherwise.

It looks like the packaging policy prevents that though. I'm trying to
track down the rationale behind this part of the packaging policy:

==
1.3.2 Socket activation
Socket activation occurs when a service allows systemd to listen for
connections to a specific socket and, when systemd receives a connection
on that socket, it starts the service. To do this, the upstream source
needs to have some minor coding work to let systemd listen for
connections on the socket and there needs to be a .socket file in
%{_lib}/systemd/system/ that tells systemd to listen to that socket and
what to start when a connection is received. This is similar in function
to inetd and some, but not all, services coded to work with inetd will
work with socket activation. ***Simila to inetd, using socket activation
for on-demand loading will impose a startup time penalty so we currently
do not use this feature in Fedora.***
== (my emphasis)

It looks like this Socket Activation section was added on March 9th
2011. The only FPC meeting prior to that mentioning socket activation
was on January 19th 2011:

[...]
17:10:58 abadger1999 All services (started by systemd, xinet.d, bus
activated, etc) should not be turned on by the package unless they are
granted an exception.  The exceptions are listed on this page along with
reasons that the exception was granted which may lead to more general
rules in the future:
[...]

The cups.socket unit passes the listening socket to cupsd, and only
starts one instance of cupsd, so I don't think the start-up time
penalty reason applies to it.

Should I apply for an exception of some sort, or does the socket
activation policy need revisiting?

Tim.
*/




signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On-demand launching via socket activation

[Tim Waugh]

On Wed, 2014-09-10 at 14:10 +0200, drago01 wrote:
 As written today you should ask for an exception ... but I agree that
 the policy needs to be revised.

A good start to revising it is here:
  https://fedorahosted.org/fpc/ticket/208

e.g.
==
If a service is enabled by default after installation and has both a
socket activated and a non-socket activated unit file set, then it
SHOULD enable the socket activated version and leave the non-socket
activated unit file off. (But the packager might choose not to do this
if he has good reasons for it.)
==

But that ticket hasn't been touched since it was filed in 2012.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Problems with Ghostscript license switched to AGPL?

[Tim Waugh]

On Tue, 2014-07-29 at 22:40 -0400, Adam Goode wrote:
 I know this is old news, but Ghostscript switched to AGPL with version
 9.07 (Feb 2013). I was not able to find any announcement of this on
 the Fedora lists.

Here's the discussion from this list at the time:
https://lists.fedoraproject.org/pipermail/devel/2013-February/178982.html

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

[Tim Waugh]

This new checking looks really powerful.

Unfortunately, I'm seeing a build failure for libgphoto2 that I'm having
a hard time making sense of:

http://kojipkgs.fedoraproject.org//work/tasks/7196/6727196/root.log

DEBUG util.py:331:  Executing command: ['fedpkg', 'sources'] with env
{'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash',
'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n mock-chroot', 'HOME':
'/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
DEBUG util.py:281:  ==15737==AddressSanitizer CHECK failed: 
../../../../libsanitizer/asan/asan_globals.cc:91 
((AddrIsAlignedByGranularity(g-beg))) != (0) (0x0, 0x0)
DEBUG util.py:281:  #0 0xb583d21b (/lib/libasan.so.1+0x6121b)
DEBUG util.py:281:  #1 0xb5841a8b in __sanitizer::CheckFailed(char const*, 
int, char const*, unsigned long long, unsigned long long) 
(/lib/libasan.so.1+0x65a8b)
DEBUG util.py:281:  #2 0xb57fb01b in __asan_register_globals 
(/lib/libasan.so.1+0x1f01b)
DEBUG util.py:281:  #3 0xb6f14877 in call_init.part.0 
(/lib/ld-linux-armhf.so.3+0x11877)
DEBUG util.py:281:  #4 0xb6f149d3 in _dl_init 
(/lib/ld-linux-armhf.so.3+0x119d3)
DEBUG util.py:281:  #5 0xb6f199e7 in dl_open_worker 
(/lib/ld-linux-armhf.so.3+0x169e7)
DEBUG util.py:281:  #6 0xb6f14723 in _dl_catch_error 
(/lib/ld-linux-armhf.so.3+0x11723)
DEBUG util.py:281:  #7 0xb6f18f3f in _dl_open 
(/lib/ld-linux-armhf.so.3+0x15f3f)
DEBUG util.py:281:  #8 0xb6d58d03 in dlopen_doit (/lib/libdl.so.2+0xd03)
DEBUG util.py:281:  #9 0xb6f14723 in _dl_catch_error 
(/lib/ld-linux-armhf.so.3+0x11723)
DEBUG util.py:281:  #10 0xb6d594c7 in _dlerror_run (/lib/libdl.so.2+0x14c7)
DEBUG util.py:281:  #11 0xb6d58dcf in __dlopen (/lib/libdl.so.2+0xdcf)
DEBUG util.py:281:  #12 0xb6e8055f in _PyImport_GetDynLoadFunc 
(/lib/libpython2.7.so.1.0+0xfa55f)
DEBUG util.py:281:  #13 0xb6e6803b in _PyImport_LoadDynamicModule 
(/lib/libpython2.7.so.1.0+0xe203b)
DEBUG util.py:281:  #14 0xb6e65e7f (/lib/libpython2.7.so.1.0+0xdfe7f)
DEBUG util.py:281:  #15 0xb6e660d3 (/lib/libpython2.7.so.1.0+0xe00d3)
DEBUG util.py:281:  #16 0xb6e66bab in PyImport_ImportModuleLevel 
(/lib/libpython2.7.so.1.0+0xe0bab)
DEBUG util.py:281:  #17 0xb6e4adf3 (/lib/libpython2.7.so.1.0+0xc4df3)
DEBUG util.py:281:  #18 0xb6def51b in PyCFunction_Call 
(/lib/libpython2.7.so.1.0+0x6951b)
DEBUG util.py:281:  #19 0xb6db1d6f in PyObject_Call 
(/lib/libpython2.7.so.1.0+0x2bd6f)
DEBUG util.py:281:  #20 0xb6e4ceab in PyEval_CallObjectWithKeywords 
(/lib/libpython2.7.so.1.0+0xc6eab)
DEBUG util.py:281:  #21 0xb6e4fb63 in PyEval_EvalFrameEx 
(/lib/libpython2.7.so.1.0+0xc9b63)
DEBUG util.py:281:  #22 0xb6e53c3f in PyEval_EvalCodeEx 
(/lib/libpython2.7.so.1.0+0xcdc3f)
DEBUG util.py:281:  #23 0xb6e53e03 in PyEval_EvalCode 
(/lib/libpython2.7.so.1.0+0xcde03)
DEBUG util.py:281:  #24 0xb6e64e93 in PyImport_ExecCodeModuleEx 
(/lib/libpython2.7.so.1.0+0xdee93)
DEBUG util.py:281:  #25 0xb6e6511b (/lib/libpython2.7.so.1.0+0xdf11b)
DEBUG util.py:281:  #26 0xb6e666b7 (/lib/libpython2.7.so.1.0+0xe06b7)
DEBUG util.py:281:  #27 0xb6e65e7f (/lib/libpython2.7.so.1.0+0xdfe7f)
DEBUG util.py:281:  #28 0xb6e6612b (/lib/libpython2.7.so.1.0+0xe012b)
DEBUG util.py:281:  #29 0xb6e66b5f in PyImport_ImportModuleLevel 
(/lib/libpython2.7.so.1.0+0xe0b5f)
DEBUG util.py:281:  #30 0xb6e4adf3 (/lib/libpython2.7.so.1.0+0xc4df3)
DEBUG util.py:281:  #31 0xb6def51b in PyCFunction_Call 
(/lib/libpython2.7.so.1.0+0x6951b)
DEBUG util.py:281:  #32 0xb6db1d6f in PyObject_Call 
(/lib/libpython2.7.so.1.0+0x2bd6f)
DEBUG util.py:281:  #33 0xb6e4ceab in PyEval_CallObjectWithKeywords 
(/lib/libpython2.7.so.1.0+0xc6eab)
DEBUG util.py:281:  #34 0xb6e4fb63 in PyEval_EvalFrameEx 
(/lib/libpython2.7.so.1.0+0xc9b63)
DEBUG util.py:281:  #35 0xb6e53c3f in PyEval_EvalCodeEx 
(/lib/libpython2.7.so.1.0+0xcdc3f)
DEBUG util.py:281:  #36 0xb6e53e03 in PyEval_EvalCode 
(/lib/libpython2.7.so.1.0+0xcde03)
DEBUG util.py:281:  #37 0xb6e64e93 in PyImport_ExecCodeModuleEx 
(/lib/libpython2.7.so.1.0+0xdee93)
DEBUG util.py:281:  #38 0xb6e6511b (/lib/libpython2.7.so.1.0+0xdf11b)
DEBUG util.py:281:  #39 0xb6e666b7 (/lib/libpython2.7.so.1.0+0xe06b7)
DEBUG util.py:281:  #40 0xb6e65e7f (/lib/libpython2.7.so.1.0+0xdfe7f)
DEBUG util.py:281:  #41 0xb6e6612b (/lib/libpython2.7.so.1.0+0xe012b)
DEBUG util.py:281:  #42 0xb6e66b5f in PyImport_ImportModuleLevel 
(/lib/libpython2.7.so.1.0+0xe0b5f)
DEBUG util.py:281:  #43 0xb6e4adf3 (/lib/libpython2.7.so.1.0+0xc4df3)
DEBUG util.py:281:  #44 0xb6def51b in PyCFunction_Call 
(/lib/libpython2.7.so.1.0+0x6951b)
DEBUG util.py:281:  #45 0xb6db1d6f in PyObject_Call 
(/lib/libpython2.7.so.1.0+0x2bd6f)
DEBUG util.py:281:  #46 0xb6e4ceab in PyEval_CallObjectWithKeywords 
(/lib/libpython2.7.so.1.0+0xc6eab)
DEBUG util.py:281:  #47 0xb6e4fb63 in PyEval_EvalFrameEx 
(/lib/libpython2.7.so.1.0+0xc9b63)
DEBUG 

Re: ps2pdf not finding Times-Italic font - where should it be?

[Tim Waugh]

On Wed, 2013-08-07 at 18:53 +0100, Paul Howarth wrote: 
 Error: /invalidfont in /findfont

Generally ghostscript will substitute another font if it can't find what
you're after.

This is /invalidfont though, which I think means it tried reading the
font you asked for but that font was invalid.

There was a bug a bit like this in urw-fonts not long ago:
  https://bugzilla.redhat.com/show_bug.cgi?id=921706

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

ghostscript changing license from GPLv3+

[Tim Waugh]

In Ghostscript 9.07, the license for the majority of the package is
changing from GPLv3+ to AGPLv3+ (the Affero General Public License).  I
intend to update to 9.07 in rawhide shortly.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ghostscript changing license from GPLv3+ to AGPLv3+

[Tim Waugh]

In Ghostscript 9.07, the license for the majority of the package is
changing from GPLv3+ to AGPLv3+ (the Affero General Public License).  I
intend to update to 9.07 in rawhide shortly.

Tim.
*/


[Fixed subject line to include new license shortname]


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ghostscript changing license from GPLv3+ to AGPLv3+

[Tim Waugh]

On Fri, 2013-02-22 at 11:48 +0100, Florian Weimer wrote:
 Is there some exception (like for the database with the unspeakable 
 name), or does this affect CUPS?  Will CUPS be extended to allow 
 downloading the Ghostscript source code?

Good question: CUPS is licensed as GPLv2, which is listed on the Fedora
licensing page as not compatible with AGPLv3+.

The cups package has a requirement on ghostscript-cups, a sub-package of
ghostscript.  This sub-package provides the CUPS filter for converting
PostScript or PDF to CUPS Raster format.  CUPS filters are separate
executables which follow a particular interface (see the filter(7) man
page) regarding stdin, stdout, and stderr.

Not being a linkage dependency, I wasn't expecting that to be affected
by the Ghostscript license change to Affero GPL.  But perhaps it would
be?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Mass rebuild for Fedora 18 Complete

[Tim Waugh]

On Sun, 2012-07-22 at 14:33 -0600, Kevin Fenzi wrote:
 Yep: http://fedorapeople.org/~ausil/f18-failures.html

I've fixed diffutils and built it.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Escalation - better desktop printing policy (over two years old issue)

[Tim Waugh]

On Sat, 2012-06-16 at 15:12 +0200, valent.turko...@gmail.com wrote:
 OK, but why isn't this easy fix via new policy done, why is it sitting
 in bugzilla for over two years?

I really don't know.  I don't maintain the cups-pk-helper package.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Escalation - better desktop printing policy (over two years old issue)

[Tim Waugh]

On Fri, 2012-06-15 at 09:30 +0200, valent.turko...@gmail.com wrote:
 Hi,
 Fedora still has quite strict printing policies even if users choose
 to be a part of Administrator group during installation still need to
 input passwords while changing even the minor printer settings (like
 unpausing). This is still an issue on Fedora 16 and 17, is has been in
 bugzilla for over 2 years:
 https://bugzilla.redhat.com/show_bug.cgi?id=596711
 
 Why are Administrator users being asked for root pasword when editing
 printer options? There is a fix from Fedora wiki page:
 http://fedoraproject.org/wiki/Printing/ConfigurationTool
 
 Please make this fix permanent and enabled by default in Fedora.
 
 If I'm not mistaken this is the same issue that Linus Torvalds vented
 regarding same issue on OpenSuse -
 https://plus.google.com/102150693225130002912/posts/1vyfmNCYpi5

FWIW, a better way of doing print-to-remote-service is being planned
which requires no special privilege:
  http://cyberelk.net/tim/2012/03/08/session-printing/

(This is no help for print-to-locally-attached-printer though.)

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PDF printing woes

[Tim Waugh]

On Wed, 2012-05-30 at 21:32 +0800, P J P wrote:
 I'm facing a weird printing problem with cups-1.5.2 on F16. I can
 print a document from the browser; But when i try to print a PDF
 document, it prompts me for the cups server password. I've tried with
 epdfviewer and Adobe Reader both halt at the same point.

This looks like a problem in the print dialog for the application you
are using to print.

I gather you have set 'ServerName' in /etc/cups/client.conf (or
~/.cups/client.conf) to cups.x.com, and that the server policy on
that machine requires authentication for at least one of the steps
required for printing a job.

Does printing from the command line (using lp) work?  Does it ask for a
password?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: User session printing

[Tim Waugh]

On Fri, 2012-03-09 at 08:21 -0900, Jef Spaleta wrote:
 Back to the use case of a primarily single user laptop touching
 multiple networks on a daily basis.  For that situation is it expected
 that the default print server will still be the laptop's own cup
 server for networked printers?

Networked printers that communicate using IPP, and which can accept PDF
natively, could be used directly from the user session without needing a
CUPS server, either running locally or on the network. In practice I'm
not sure how many jobs IPP printers are generally able to queue -- it
may only be 1. In a busy office it might be preferable to have a print
server machine running CUPS, and have clients use that instead of
sending jobs directly to the printers; that way jobs will get spooled.

There would still need to be a locally running CUPS server if any other
communication protocol is used (LPD, JetDirect, SMB/CIFS etc), or if the
printer does not accept PDF.  For one thing, those protocols don't allow
us to detect whether PDF is accepted or not.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: User session printing

[Tim Waugh]

On Thu, 2012-03-08 at 09:52 -0900, Jef Spaleta wrote:
 2012/3/8 Miloslav Trmač m...@volny.cz:
  The lazy answer to both is fail, or not, the same way as cups
  currently fails, or not (in fact, could the session printing service
  simply be cups that treats the system instance as another remote
  server?).
 
 If we were looking for the lazy answer, we'd just not bother with queing at 
 all.

Yes, exactly, and that is what I'm suggesting.  For printing entirely in
the user session it is a case of using an alternative to using CUPS
running on the local machine, so that means:

a) no filters or drivers; the job document is the PDF produced by the
application/print dialog

b) no queueing; submit the job directly to the print server, and if that
fails then explain why immediately

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: root password considered harmful, and other security policies. (was Re: Torvalds:requiring root password for mundane things is moronic

[Tim Waugh]

On Wed, 2012-03-07 at 11:05 -0800, Scott Doty wrote:
 /etc/polkit-1/localauthority.conf.d/60-desktop-policy.conf
 
 Regarding this situation: turns out that if system-config-printer
 doesn't establish proper contact with cups-pk-helper, it will fall back
 to a mode that pops up the root password dialogue.

Some more about this: what you are actually seeing is the IPP
authentication dialog, i.e. the same authentication mechanism you would
use if cups-pk-helper were not installed or if you were configuring a
remote CUPS server.

Although the default username that s-c-printer puts in there is root,
that's just because CUPS requires the root user for remote admin.  CUPS
can be configured to allow e.g. anyone in the wheel group to admin
instead.  It's not clear whether I should make that configuration change
or not.  It's also not clear what the policy for this is, or who to ask,
or whether anyone actually has any clear overview of what the security
policies are for Fedora and how that might differ in each spin etc.

 The FESCo ticket that was opened on my behalf was based on the idea that
 we were confronting a policy decision, not bugs -- and the idea was to
 have whomever reviews security policy do a review of these password
 dialogues to see if any could be eliminated, esp. the root password
 dialogue that kicked off this issue.  There is a Privilege escalation
 policy that can be found here:
 
http://fedoraproject.org/wiki/Privilege_escalation_policy

...except that the primary author of that document told me this month
that it is only a draft and can be ignored¹.  In any case it seems to
make no distinction between a user logged in remotely and one sat in
front of the machine.

In that document you can clearly see where the current cups-pk-helper
policy came from, especially here:

* Add, remove, or downgrade any system-wide application or shared
resource (packaged or otherwise)

Tim.
*/

¹ https://bugzilla.redhat.com/show_bug.cgi?id=596711#c16


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: User session printing

[Tim Waugh]

On Mon, 2012-03-05 at 12:02 -0500, Bill Nottingham wrote:
 Tim Waugh (twa...@redhat.com) said: 
  For things like cloud printing, where the print server is a hosted
  service somewhere out in the Internet, I think the applications should
  be talking directly to it (via the print dialog).
  
  For a plain network printer, where the printer might not be able to
  accept the job while it's busy processing others, you might have to
  queue the job and retry it later.  So if you are doing that as a user
  process, how should that work when you log out, and when the machine is
  restarted?
 
 It waits until you log in again.

Where I can see it can make some sense to have printing entirely in the
user session is for PDF printing to smart services hosted elsewhere:
e.g. the office CUPS server, or Google Cloud Print.  Applications
produce PDF, so for printing to these types of service there is nothing
to do but send the PDF (along with any print options).

I've written up some thoughts about it, with a diagram, here:
  http://cyberelk.net/tim/2012/03/08/session-printing/

Here's the text:

The GTK print dialog supports multiple print backends, and currently
'cups' is the one we use for printing.  This communicates with the
locally-running cupsd.

Printing is more than simply getting capabilities and submitting jobs
though: we also need to monitor the status of submitted jobs, and
perform actions on those jobs such as pause, resume, and cancel.

Currently job status monitoring is performed in gsd-printer, which
displays notifications when a job has completed etc, and job management
actions are implemented in the Printers panel of the Systems Settings
application.

Adding support for printing to PDF-capable print services directly from
the session could be implemented as follows.

A new session service for printing could be created, providing methods
for obtaining a list of printers, explicitly adding/removing printers,
and with properties for finding out the current state of each printer
and whether it is reporting problems.  It could also provide methods for
retrieving the list of jobs for each printer, performing actions on
those jobs, and have properties for the state of each job.

This service could have plug-ins for dealing with the locally-running
cupsd; with CUPS/IPP servers on the network; and with Google Cloud
Print.

For the network IPP plug-in, it could discover available CUPS (and IPP
Everywhere) queues using Avahi, and show in the list of printers only
those queues that handle PDF.  Additionally, the print dialog could
allow IPP print servers to be added by hostname (for CUPS) or URI (for
network printers which speak IPP and handle PDF).

For the cloudprint plug-in, it could interrogate the Google Cloud
Print server to determine the list of available queues. (The Online
Accounts/Google part of System Settings knows how to log in.)

For job status feedback, gsd-printer could instead query the new
service. (Or perhaps the service would be implemented in gsd-printer?)

For job management, the printer panel in System Settings could perform
actions through the new service.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: User session printing

[Tim Waugh]

Can't we just get the policy right so that users can add queues?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

User session printing

[Tim Waugh]

(changing the subject line since this is a bit different from the
original topic)

On Sun, 2012-03-04 at 00:22 +0100, Miloslav Trmač wrote:
 Another way to look at this issue is - if printers were maintained
 per-user (per-user, unprivileged cups daemon, per-user configuration,
 per-user print queue), there would be no reason to ask for
 authentication.  Given that printers are so often networked nowadays
 and no access to hardware is required, we might even be able to avoid
 running the system-wide cups daemon at all in some cases.  There would
 be one less process running as root, no reason to authenticate, an
 increase both in security and ease of use.
[...]
 Would something like this at all possible to do with cups and the
 current printing design and protocols?

For things like cloud printing, where the print server is a hosted
service somewhere out in the Internet, I think the applications should
be talking directly to it (via the print dialog).

For a plain network printer, where the printer might not be able to
accept the job while it's busy processing others, you might have to
queue the job and retry it later.  So if you are doing that as a user
process, how should that work when you log out, and when the machine is
restarted?

Another issue is that the LPD printer protocol requires the client to
connect from a privileged port, so it won't work for that without some
extra hoops.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Torvalds:requiring root password for mundane things is moronic

[Tim Waugh]

On Fri, 2012-03-02 at 05:21 -0600, Conan Kudo (ニール・ゴンパ) wrote:
 For printers, currently installing printers does not require superuser
 privileges, but managing those printers installed by that user does.
 Is it possible to make it so that printers installed by that user can
 be managed by the user without superuser authentication?

Yes, it's a policy.

Also see this bug which I filed nearly two years ago on just this
subject:
  https://bugzilla.redhat.com/show_bug.cgi?id=596711

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning pyusb

[Tim Waugh]

I don't have the time to maintain pyusb, and it isn't used by any other
package I maintain.

$ repoquery -q --whatrequires pyusb
garmin-sync-0:0.3-4.fc16.noarch
nxt_python-0:0.7-8.fc15.noarch

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Changes coming for CUPS 1.6

[Tim Waugh]

On Thu, 2012-01-19 at 15:50 -0800, Adam Williamson wrote:
 What a great idea! We could call one of them 'Postscript'...

Not likely. :-)

I think the current candidate for the optional vector format is PDF
1.4/1.5.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

[Tim Waugh]

On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote:
 I use closed/upstream, when I already fixed it in upstream. This bug 
 should be closed with number of release, where it is fixed or with the 
 link to the commit. I wouldn't blame this state for not fixing bug in 
 some projects. I guess instead of closed/upstream we would see more 
 closed/wontfix|cantfix.

I use POST for that.

A patch or solution believed to resolve this matter has been proposed
(POSTed) for inclusion in the package or kernel.

For non-kernel packages I read that as meaning that the patch is in-hand
upstream, and not yet built in Fedora.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Changes coming for CUPS 1.6

[Tim Waugh]

On Wed, 2012-01-18 at 17:11 +, Ben Boeckel wrote:
 For those of us that just have static printer setups, would it be
 possible to make a cups-browse (or similar) subpackage which brings in
 Avahi?

The dependency will be on libavahi-client and libavahi-common, which are
part of avahi-libs.  These are hard dependencies as the scheduler will
link to those libraries.

Now that avahi-libs is a separate sub-package from the main avahi
package, it does not require the Avahi server.

So currently there is no dependency on the Avahi server, and I don't
expect that to change with CUPS 1.6.

Additionally, I expect the BrowsePoll directive in cupsd.conf will
still work in CUPS 1.6 as it does not use CUPS Browsing.  It works by
periodically issuing IPP requests to the listed CUPS servers to fetch
information about their queues.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Changes coming for CUPS 1.6

[Tim Waugh]

On Wed, 2012-01-18 at 18:14 +0100, Kevin Kofler wrote:
 What's the story about the PPD stuff Till is talking about there? That
 scares me the most when I read that mail. Will this be supported by a patch
 from openprinting.org? Seeing how Apple upstream is dropping features we
 need, I wonder whether the best solution wouldn't be a full-blown fork of
 CUPS, where your Avahi patches could also be merged to.

I'm not sure of the details.  Here is the background:

The Printer Working Group is engaged in an effort called IPP
Everywhere¹.  The goal is to have driverless printing by having a
small common set of imaging standards in printers, and for the printer
capabilities to be inspected using IPP.

There is no need for PPDs in this vision of how things will work in the
glorious future, when all printers support IPP Everywhere.

The way I expect it to work in CUPS 1.6 is that the concept of PPDs
disappears as far as clients to CUPS are concerned, but that it will
still use PPDs internally for existing printers that do not support IPP
Everywhere (that is to say, all of them right now).

In other words, I think the direction it is going is to make PPDs an
implementation detail of CUPS.

How that will work in practice I don't know yet.

Tim.
*/

¹ http://pwg-wiki.wikispaces.com/IPP+Everywhere


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Changes coming for CUPS 1.6

[Tim Waugh]

On Wed, 2012-01-18 at 17:28 +, Jóhann B. Guðmundsson wrote:
 Has it been considered to ditch cups altogether ( or keep what's worth 
 keeping from it ) and coming up with a native printer client/server for 
 GNU/Linux?

It's been considered, yes.  For the time being it isn't beneficial to do
that.  It isn't ruled out.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Changes coming for CUPS 1.6

[Tim Waugh]

On Thu, 2012-01-19 at 11:38 +, Richard W.M. Jones wrote:
 I'm still using a very servicable HP LaserJet 5M from ca.1996.

Quite -- which is why I believe that CUPS 1.6 will still support PPDs,
and why I didn't mention it in my original email.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Changes coming for CUPS 1.6

[Tim Waugh]

Hi,

Although the latest version of CUPS is 1.5.0, development is continuing
apace on 1.6.  There are some important changes coming in 1.6 which
deserve to be pointed out.

Some time ago CUPS became an Apple project, and now some of the features
that are not relevant to Mac OS are being orphaned.  Where they are of
use for the Linux environment, those orphaned features will continue to
be maintained at OpenPrinting (http://www.openprinting.org/) as a
separate project.

CUPS Browsing
-

One of the notable things that will be disappearing is CUPS Browsing.
This is currently the primary mechanism for CUPS-to-CUPS printer queue
discovery on Linux.  It works by having each CUPS server periodically
broadcast UDP packets on port 631 announcing its available queues.

This method of discovery is being dropped in favour of DNS-SD.  Support
for this has been upstream in CUPS for some time -- it's what CUPS uses
on Mac OS X -- but is not functional with Avahi. (For Fedora, I have
added patches to support Avahi.)

This means that once CUPS drops support for CUPS Browsing, automatic
CUPS queue discovery *will require Avahi* to be running on both the
server (i.e. the system hosting the CUPS queue) and the clients (i.e.
the systems wanting to print to it).

Some Filters Moving To New Home
---

Apple is removing some filters from CUPS as they are not needed for Mac
OS X.  These filters will be maintained in a new cups-filters project
at OpenPrinting.

As part of this move, Till Kamppeter will be merging the existing PDF
Workflow filters¹ into that effort.

The main purpose of this email was to raise awareness of the CUPS
Browsing/Avahi issue.

Till Kamppeter's email about the CUPS 1.6 changes on the
printing-architecture list:
http://lists.linuxfoundation.org/pipermail/printing-architecture/2012/002412.html

Tim.
*/

¹ 
http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: libpng bumped to 1.5.x in rawhide

[Tim Waugh]

On Sat, 2011-11-05 at 13:02 -0400, Tom Lane wrote:
 twaugh ghostscript 
 twaugh gutenprint 

I've rebuilt these two.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Tim Waugh]

Actually there is another reason for socket activation to use AF_INET as
well as AF_UNIX: doing so prevents e.g. rpc.statd from port-squatting.
In fact, this is why CUPS no longer ships to ship a portreserve file.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Tim Waugh]

On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote:
 It's not so much cups start up being slow as discovering network printers. 
 That can take up to a minute I think.

This is true... however, discovered printers are cached so this is only
an issue the first time CUPS starts after installation (or after
connection to a new network).

Additionally there are plans afoot to use Avahi for CUPS - CUPS
printer discovery, replacing the current send a broadcast packet every
30s protocol.  This would eliminate the problem entirely.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Tim Waugh]

On Fri, 2011-08-19 at 11:03 -0400, Steve Grubb wrote:
 People running in a LSPP configuration would be horrified 
 to know avahi is now required for printing top secret documents.

Just to clarify: it is not required.  Most likely in an LSPP
configuration not even CUPS Browsing is used, but explicit queues are
set up on each client machine.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Default services enabled

[Tim Waugh]

Hi,

I'm having trouble finding a policy on which systemd units may be
enabled by default.

The case I'm interested in particularly is cups.socket, cups.path,
cups.service.

What's the current policy, and where can I find it on the wiki?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Tim Waugh]

On Wed, 2011-08-17 at 20:04 +0530, Rahul Sundaram wrote:
 https://fedoraproject.org/wiki/Starting_services_by_default

Ah, thanks.  So it looks like CUPS can be enabled by default:

If a service does not require configuration to be functional and is not
network enabled, it may be enabled by default

(The default CUPS configuration is localhost-only)

In the light of this I'll enable cups.path (to allow printing jobs which
are queued, on boot) and cups.socket (to allow on-demand start).

I'll leave cups.service out because that's only required for
network-enabled configurations -- but perhaps that needs a release note?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Tim Waugh]

On Wed, 2011-08-17 at 10:33 -0500, Chris Adams wrote:
 Is CUPS functional without any configuration?  How do you print without
 configuring a printer?

By plugging one in.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Tim Waugh]

On Wed, 2011-08-17 at 21:02 +0530, Rahul Sundaram wrote:
 On 08/17/2011 08:47 PM, Tim Waugh wrote:
  I'll leave cups.service out because that's only required for
  network-enabled configurations -- but perhaps that needs a release
  note? Tim. */
 
 Yes.  You can add it here
 
 https://fedoraproject.org/wiki/Documentation_Printing_Beat

Oh, I just noticed this:

https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activation
Since Fedora currently doesn't want any services to do on-demand
loading, all socket activated services must autostart.

So I'll also enable cups.service.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Tim Waugh]

On Wed, 2011-08-17 at 10:46 -0500, Michael Cronenworth wrote:
 Are you pushing this change into Fedora 16?

Once it's built, yes, to fix:
https://bugzilla.redhat.com/show_bug.cgi?id=731421

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd vnc - how to properly handle /etc/sysconfig/vncservers

[Tim Waugh]

On Wed, 2011-07-20 at 11:48 +0200, Adam Tkac wrote:
 Any idea how to handle the VNCSERVERS argument in backward-compatible
 way is welcomed, otherwise I will simply drop sysconfig support at all
 in the service file and admin will have to create /etc/systemd/system/
 service files with appropriate params.

IMHO dropping the sysconfig support and having separate systemd unit
files for each session is the best approach.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Deprecating portreserve

[Tim Waugh]

The BMC thing sounds a bit more special-purpose than portreserve, and
presumably could be done in its own package that could perhaps be
installed as needed depending on the hardware.

So is the next step to deprecate portreserve?  What actually needs to be
done for that to happen?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: cups service gone walkabouts?

[Tim Waugh]

On Wed, 2011-07-06 at 10:30 +0100, Tom Hughes wrote:
 Well first of all I'd check it's enabled as I believe policy is that the 
 enabled/disabled state of a service is not carried over when it migrates 
 from svsvinit to systemd.

Correct, and I haven't pursued getting an exception for cups so that it
can automatically be enabled.

Did we decide in the end that default service enabling should happen as
part of a spin's kickstart, or does it need to be in the package?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: cups service gone walkabouts?

[Tim Waugh]

On Wed, 2011-07-06 at 11:32 +, Jóhann B. Guðmundsson wrote:
 I thought with Lennart patch/setup on his blog the only case you need to 
 enable cups is if you are going to be running centralized printer server 
 which in that case the admin himself would enabled it hence we would not 
 have to have it enabled by default...

Yes, you're quite right, my mistake.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: cups service gone walkabouts?

[Tim Waugh]

On Wed, 2011-07-06 at 13:38 +0100, Tom Hughes wrote:
 I had assumed that was deliberate, but maybe not?

Try today's rawhide.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20110531 changes

[Tim Waugh]

On Tue, 2011-05-31 at 10:17 +, Rawhide Report wrote:
   rasterview-1.3-2.fc16.x86_64 requires libfltk.so.1.1()(64bit)
   rasterview-1.3-2.fc16.x86_64 requires libfltk_images.so.1.1()(64bit)

Fixed.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: quilt, patch, diff or something else is br0ken in F15

[Tim Waugh]

The patch command was recently fixed to prevent files outside the
current working directory from being patched unintentionally.  Could
that be the issue?

(It doesn't look like it from the error messages you are getting, but I
thought it worth mentioning...)

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: hplip (hp-plugin) installs binary-only plugins and firmware into system directories without RPM control

[Tim Waugh]

On Sun, 2011-03-13 at 01:14 +0100, Dominik 'Rathann' Mierzejewski wrote:
 For Tim: have you considered doing something similar to RPMFusion akmod,
 i.e. modifying hp-setup/hp-plugin to build an appropriate package
 on-the-fly? Also, the binary plugins get installed under /usr/share/hplip,
 which is against the packaging guidelines (binaries should go in /usr/lib
 or /usr/lib64, depending on the arch).

I haven't considered that, no.

 For Tim and legal folks: has anyone tried asking HP to open-source the
 plugins and the firmware or at least changing the license for the plugins
 and the firmwares to one allowing redistribution? The latter would make
 the firmwares acceptable for Fedora and the plugins acceptable for
 RPMFusion.

HP won't open-source them unfortunately.  I don't know whether they will
change the license to allow for redistribution.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Services that can start by default policy feedback

[Tim Waugh]

On Wed, 2011-02-23 at 11:56 -0700, Kevin Fenzi wrote:
 Some questions: 
 
 * Do you know of/maintain another service that should start by default?
   Why? 

CUPS currently starts by default.  The reason is that, even when
printing over the network as a client, this service is required to be
running (it spools the job, handles status feedback etc).

In the default configuration (i.e. client only, no local print queues
defined) it only listens to UDP port 631, which is used by CUPS
Browsing.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Services that can start by default policy feedback

[Tim Waugh]

On Thu, 2011-02-24 at 14:27 +0100, Lennart Poettering wrote:
 I still have unupstreamed patches here which would allow us to start
 CUPS automatically when a local client needs it or when a printer is
 plugged in. 

I think that's separate from the issue of whether the service is allowed
to start automatically, isn't it?

In other words, delaying start-up until it is needed is separate from
whether the service is available by default at all.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firewall

[Tim Waugh]

On Tue, 2010-12-07 at 11:18 -0500, Matthew Miller wrote:
 Is there a compelling reason for this not to be:
 
 - cups snmp backend says to the firewall, hey, please allow
   responses on this port I've got
 - cups snmp backend listens for responses until timeout
 - cups snmp backend says to the firewall, hey, I'm done now. thanks!
 
 That seems more helpful than a few seconds anyway. And worst case is that
 the snmp backend crashes or otherwise forgets to remove its rule, which
 shouldn't be terribly severe since then it won't be listening, either. Some
 other point the the cups startup/stop process could make sure any such
 leftover rules are cleared just to be sure.

Well, it could be done that way.  The reason I didn't suggest that
originally was that CUPS has to kill backends if they take too long, so
it would seem quite likely that stale rules would get left around in
some instances if they required explicit revocation.

In the worst case you have a random unprivileged UDP port open --
there's nothing to associate it with SNMP, or the CUPS snmp backend.
The backend won't be listening on it, but some other process may well
choose that port later on.

 I have no problem with the mechanism for talking to the firewall being some
 PolicyKit-enabled helper program. I just don't see a strong argument for it
 being a daemon.

With D-Bus object activation, maybe it doesn't need to be running all
the time (e.g. as with the current system-config-firewall D-Bus
service)?  I'm not sure as I haven't seen the prototype yet.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firewall

[Tim Waugh]

On Mon, 2010-12-06 at 21:50 +, Richard W.M. Jones wrote:
 Still not seeing how /etc/iptables.d wouldn't work ...

Here is how:

When I ask CUPS for a list of network printers, it runs the backends
in /usr/lib/cups/backend.  One of those is /usr/lib/cups/backend/snmp,
which:

a) binds to a local unprivileged UDP port
b) sends a broadcast SNMP request
c) listens for (unicast) responses to that request

We don't hear any of those responses because they are not recognised as
related by the kernel.  The iptables rules drop them.

If the CUPS snmp backend could say to the firewall, hey, please allow
responses on this port I've got for the next few seconds -- which can
be controlled using PolicyKit -- then this network discovery would
finally work.

There's no way to know the local UDP port in advance
so /etc/iptables.d-like systems all fail here.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New gtk-vnc slower?

[Tim Waugh]

On Wed, 2010-11-24 at 22:05 -0700, Jerry James wrote:
 Is anybody else seeing this?  Is there any other component besides
 gtk-vnc that I should examine as a possible source of the slowdown?

I'm seeing this too.  Downgrading to gtk-vnc-0.4.1-6.fc14.1 fixes it
here.

I've filed a bug report about it:
  https://bugzilla.redhat.com/show_bug.cgi?id=657542

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firewall settings unworkable

[Tim Waugh]

On Wed, 2010-10-06 at 17:26 +0200, Thomas Woerner wrote:
 It is possible to specify a timeout for a firewall service and also the 
 other features. The service will be opened immediately and closed again 
 after the defined period is over. This allows to accept new connections 
 from unknown sources in the specified time frame. This will be very 
 useful for UPNP, SNMP or NetBIOS for example to find printers or to 
 share data with others. This mechanism is similar to the bluetooth 
 handler in cell phones.

This is great news, can't wait to see the interface.

Thanks,
Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firewall settings unworkable

[Tim Waugh]

On Wed, 2010-10-06 at 19:31 +0100, Richard W.M. Jones wrote:
 Seems quite complex.  What's wrong with a directory:
 
   /etc/iptables.d/
 
 where RPMs like libvirt just drop the required additional rules (in a
 separate chain if you like) and restart the iptables service?  It's
 low-tech but simple and it's all that libvirt needs.

Other applications need more than that.

For example, when CUPS wants to detect network printers using SNMP, a
query is sent as a UDP packet to the broadcast address(es) from a local
unprivileged port to the remote SNMP port, 161.  It needs to be able to
hear replies.

What I was saying in my original post is that there is no simple
iptables rule that can be written today to express that, aside from
simply allowing all UDP packets to unprivileged ports, obviously not
something we want to do.

Ideally the kernel would provide a way to express this using a conntrack
module.  Until that time, however, being able to do this would suffice:

* bind() to get a free local unprivileged port

* use D-Bus to tell the firewall to allow UDP sport:161 dport:$port for
a short time

* send query

* listen for responses

* (optionally) use D-Bus to tell the firewall it can discard that rule
now

Until bind() is called, no-one knows what local port to allow UDP
packets in on.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

[Tim Waugh]

On Tue, 2010-10-05 at 15:27 -0700, Jesse Keating wrote:
 PPS  I did not modify my bump script yet to attempt a commit to master
 and merge to the f14 branch.  In the interest of time, I took the easy
 route and just did commits to the f14 branch.  Maintainers can do a
 merge and fixup after the builds have been done if they wish to have
 their branches in sync with master once more.

For this sort of thing I would have thought that separate commits on
whichever branches need changing would be fine.  Git's merging (if/when
each maintainer decides to merge branches) ought to be able to handle
that.

I don't think that merging backwards from master to f14 would be a
good idea.  Wouldn't that bring rawhide-y changes into f14?  For
example, ghostscript's master branch uses ghostscript-9.00 -- merging
master into f14 would cause havoc.

Or have I misunderstood what you are saying?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Firewall settings unworkable

[Tim Waugh]

There are several protocols used for discovery of network services that
currently cannot be made to work on Fedora simply due to the restrictive
firewall we use by default.

For example, a broadcast SNMP query to discover network printers is sent
as a UDP packet from an unprivileged local port to SNMP port of the
broadcast address.  Network printers respond by sending a UDP packet in
response, from the SNMP port back to the local unprivileged port.

The default firewall drops these packets.  However, there is no canned
firewall setting to allow these packets in.  No checkbox or on/off
switch will do it except Disable Firewall.

In system-config-printer I try to get it to modify the firewall to allow
in the various network query responses that we expect, but I find it
cannot be done for SNMP or NetBIOS (which works in a similar way).

There is an open bug against the kernel for general broadcast query
response tracking:
https://bugzilla.redhat.com/show_bug.cgi?id=538675

In the mean time, I'm left wondering whether I ought to teach
system-config-printer how to temporarily insert a rule to allow in all
UDP packets from source port SNMP and with destination port  1024...

Until then people will end up just turning off their firewalls
altogether in order to get things to work.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firewall settings unworkable

[Tim Waugh]

On Fri, 2010-10-01 at 15:23 +0200, Tomasz Torcz wrote:
   ZeroConf discovery (port 5353) is denied by default also :(

But that can be enabled with a single checkbox (Multicast DNS (mDNS)),
and that can also be done programmatically using
system-config-firewall's D-Bus interface, such as it is.  In fact,
system-config-printer does just that.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firewall settings unworkable

[Tim Waugh]

On Fri, 2010-10-01 at 15:07 +0100, David Howells wrote:
 The following works for UDP too:
 
   -A INCOMING -m state --state RELATED,ESTABLISHED -j ACCEPT
 
 Leastways, I can do AFS through my firewall with it.

Does that work for unicast replies to broadcast queries though?

e.g.

IP 10.1.1.8.33353  10.1.1.255.snmp:  GetRequest(28) 
.1.3.6.1.2.1.25.3.2.1.2.1

IP 10.1.1.7.snmp  10.1.1.8.33353:  GetResponse(37) 
.1.3.6.1.2.1.25.3.2.1.2.1=.1.3.6.1.2.1.25.3.1.5

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firewall settings unworkable

[Tim Waugh]

On Fri, 2010-10-01 at 15:19 +0100, David Howells wrote:
 Good question; I don't know.  netfil...@vger.kernel.org is probably the place
 to ask.

I did ask about this issue on netfilter, last year (look for SNMP
conntrack module a la netbios_ns, Dec 4th 2009).

That's where the idea for a general broadcast query response tracking
module came from.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Too late to merge unix2dos/dos2unix?

[Tim Waugh]

The unix2dos and dos2unix packages have merged upstream and I've been
sent a spec file that upgrades dos2unix to the new upstream version.  It
correctly obsoletes the unix2dos package.

Is it too late in the Fedora 14 cycle to bring this package in (and
retire unix2dos)?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] The systemd unit files I'll post

[Tim Waugh]

On Wed, 2010-07-14 at 21:41 -0400, Bill Nottingham wrote:
 Re: cups, if the entire point is to reserve the sockets early with
 systemd, why would portrelease still be required?

Also, re: this comment:

# This is evil stuff. CUPS should use proper enumeration instead of
# retriggering these devices. CUPS folks, please fix this, otherwise Kay will
# come after you!
ExecStartPost=/sbin/udevadm trigger --subsystem-match=usb 
--attr-match=bInterfaceClass=07 --attr-match=bInterfaceSubClass=01
ExecStartPost=/sbin/udevadm trigger --subsystem-match=usb 
--property-match=DEVNAME=/dev/usb/lp*

Kay actually suggested doing this in the first place IIRC.  We have udev
triggers for when printers are connected/disconnected, but the triggers
require cupsd to be running.  The situation the above lines are to deal
with is that a new printer is connected at boot, so the (earlier) udev
trigger had to abort because cupsd wasn't running.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] The systemd unit files I'll post

[Tim Waugh]

Another question about the cups config:

[Install]
# This is activated via any of these three triggers:
# 1. Somebody connects to its sockets
# 2. A file is in the spool directory
# 3. A printer is plugged in
# This follows the same scheme MacOS uses to spawn CUPS only when necessary
Also=cups.socket cups.path
WantedBy=printer.target

I think I mentioned in the original systemd discussion that there is a
case not covered by this approach, which is that there is a network
queue configured and available to the network, i.e. this computer is a
central print server for a bunch of network printers.

In this case, there is no local requirement for cups to be running --
the requirement is that the service is available to the network.

Will it be possible/easy for administrators to configure that?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] The systemd unit files I'll post

[Tim Waugh]

On Thu, 2010-07-15 at 15:32 +0200, Lennart Poettering wrote:
 The right approach here is to enumerate existing devices when CUPS
 starts up. All programs that care about devices should do that: 

But CUPS has no interest in what devices are currently attached.  It
only cares what queues are configured.  It doesn't automatically create
queues for connected devices.

The automatically created queues are configured by
system-config-printer.  This is done using udev rules.  Those udev rules
cannot perform their job is cupsd is not running at the moment the
printer is connected/disconnected.  That's why we have to replay them
when cupsd *is* started.

If there is a more correct way of doing it that fits within the CUPS
framework, I would love to use that.

There is no daemon running that monitors which printers are connected.
It is all done entirely with udev rules.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] The systemd unit files I'll post

[Tim Waugh]

On Thu, 2010-07-15 at 17:25 +0200, Lennart Poettering wrote:
 Extend the binary you call from the udev rules so that it also can be
 called outside of the rules and in that case enumerates what is already
 there. Then, call that after cupsd is started (for example from a
 ExecStartPost= line in cups.service).

Brilliant, that was the pointer I needed. :-)

Thanks,
Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Privilege escalation policy and desktop_admin_r

[Tim Waugh]

I have a question about how our privilege escalation policy interacts
with the desktop_admin_r group.

Is a member user of desktop_admin_r considered an unprivileged user?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Privilege escalation policy and desktop_admin_r

[Tim Waugh]

On Thu, 2010-05-27 at 08:23 -0700, Adam Williamson wrote:
 The relevant bit here is the last sentence, which was intended to cover
 the whole desktop_admin_r stuff. Let me know if it's factually off.

Seeing as desktop_admin_r is actually part of the default spin, can we
add some text which explicitly exempts users in that group from the
privilege escalation policy?

In other words, can we say something along the lines of it's fine for
the default spin to ship policykit files allowing desktop_admin_r users
to do stuff without passwords being required?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 2010-03-25 Printing test day recap

[Tim Waugh]

On Fri, 2010-04-02 at 12:49 -0500, Bruno Wolff III wrote:
 This isn't exactly a bug, but if I print text files I need to specify a
 top margin of 9 points and a left margin of 18 points or some text doesn't
 show up. But postscript output to the same printer works without fudging.
 This seems odd.

Yes, that is a bug.  It sounds like the PPD contains incorrect margin
data.  If you are using a driver from Fedora, please report it in
bugzilla along with the troubleshoot.txt from the printing
troubleshooter¹.

Thanks,
Tim.
*/

¹
https://fedoraproject.org/wiki/Printing/Debugging#Printing_troubleshooter



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 2010-03-25 Printing test day recap

[Tim Waugh]

On Tue, 2010-04-06 at 08:06 -0500, Bruno Wolff III wrote:
 For both different printer types? (I am pretty sure they used different PPD
 files.)

Well, does the PostScript output go closer to the edge of the paper than
where the text output gets cut off?  In other words, does it look like
it is a hardware limitation that print output cannot be closer to the
edge?

Unfortunately a lot of our PPD files have incorrect margin data, so it
is no big coincidence if two PPD files are wrong in that way. :-/

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Tim Waugh]

On Mon, 2010-03-29 at 13:35 +0200, Jaroslav Reznik wrote:
 The problem is - we can't act as man in middle - it's better when original 
 reporter is also upstream reporter = direct communication.

Wait -- *any* Fedora developer could say this about any bug.  I just
don't think it's true, and it assumes that the person reporting the bug
knows as much about the intricacies of source code and programming as
the developers do.

If I were were to put the onus of finding the right upstream project and
reporting bugs there onto people reporting printing problems, none of
those bugs would get fixed at all.

The user experiencing a bug *already* has to be pretty determined in
order to get as far as filing a bug in Bugzilla.

 If reporter 
 doesn't want to fill upstream bug - we do it (for example he doesn't want to 
 create upstream bz account).

Seems to me this ought to be opt-in not opt-out -- we should be
reporting the bugs upstream, and then the original reporter gets to add
themselves to the upstream bug's CC field if they like.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] Printing Test Day Thursday 2010-03-25

[Tim Waugh]

There will be a Printing Test Day[1] this Thursday, 2010-03-25.  Have
access to a printer?  Please come along and join in!

This is an opportunity to try out the new automatic printer driver
installation feature[2] in Fedora 13, as well as to give the printing
system a bit of an exercise.

For the automatic printer driver installation to work properly we need
your Device IDs!  Many IDs are missing for current printers, and some
existing IDs are incorrect.  You can help fix this by running following
the instructions in the test day page.

You don't need a Rawhide installation to provide useful feedback, just a
nightly live image[3] will do.

The Test Day will run all day in Freenode IRC #fedora-test-day.

Tim.
*/

[1] https://fedoraproject.org/wiki/Test_Day:2010-03-25_Printing
[2]
https://fedoraproject.org/wiki/Features/AutomaticPrintDriverInstallation
[3] http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/



signature.asc
Description: This is a digitally signed message part
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debugging printing problems

[Tim Waugh]

On Thu, 2010-03-18 at 21:37 +0100, Louis Lagendijk wrote:
 great info indeed. Maybe you could consider adding info on the bjnp
 backend (for Canon's proprietary network (usb-over-ip)  protocol:
 
 bjnp is for Canon's proprietary bjnp network protocol (usually port
 8611)
 
 The bjp backend is available in the cups-bjnp package

Feel free to edit the wiki, although perhaps that ought to go on the
main Printing page.  I've added it there now:
  https://fedoraproject.org/wiki/Printing

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GSoC 2010 : Better iptables management

[Tim Waugh]

On Fri, 2010-03-12 at 10:49 +0530, Zubin Mithra wrote:
 My name is Zubin Mithra and I am aspiring to get into GSoC on behalf
 of Fedora. I wish to work on making a library for better iptables
 management. Details can be viewed in the proposal which I have
 attached along with the email.
 
 I would love to hear your views on it.

Hi,

I think that a CLI/library based approach for this is not really
sufficient -- the main problem we currently have with iptables
management is that user applications need to be able to request that
certain rules are added, via PolicyKit.

The user experience ought to be something like: click 'share this
folder', dialog says Oh, you need a firewall modification to allow that
to work, shall I go ahead and do it?.

We already have a mechanism for doing this, but the existing mechanism
is quite crude.

Take a look at the D-Bus service provided by system-config-firewall.
This is the correct approach.  I think it just needs making generally
better by having an interface that is a bit more idiot proof, i.e.
some way to know whether the existing rules already do what the
application needs without having to have lots of internal knowledge of
system-config-firewall.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Final (hopefully) privilege escalation policy draft

[Tim Waugh]

On Mon, 2010-02-15 at 12:10 -0800, Adam Williamson wrote:
 That's correct. This is frankly a 'realistic' decision, on the basis
 that the PackageKit maintainer believes updating packages should be
 allowed for a regular user by default and intends to implement this, and
 I don't want to dictate this decision via the policy (that's not really
 what we're writing the policy for), so I'd rather just go with PK's
 choice there.

The justification I remember for it was that authentication dialogs
should be for exceptional situations, not for things that might
regularly need to occur such as updates, and to avoid lulling users into
blinding typing passwords into dialogs every time they are presented
just to get stuff done.

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Final (hopefully) privilege escalation policy draft

[Tim Waugh]

On Wed, 2010-02-10 at 12:48 -0800, Adam Williamson wrote:
 I have now adjusted the draft -
 https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy
  - to reflect all feedback from this list and from FESco. It will be reviewed 
 again by FESco next week. Please raise any potential issues or further 
 suggestions for adjustments before then. Of course, even if the policy is 
 accepted by FESCo it will not be set in stone and changes and exceptions can 
 be added in future as appropriate, but I'd like to have it as good as 
 possible at first :) thanks all!

==
In practice, packages which provide one or more of:

  * setuid binaries
  * PolicyKit policies
  * consolehelper configurations
  * udev rules

are likely to be affected by this policy
==

Shouldn't

  * D-Bus services on the system bus

be listed there, to make sure that /etc/dbus-1/system.d/*.conf files are
sane?  It's just that it is quite a commonly used mechanism.

This was brought up in discussion of one of the first drafts, IIRC, so
perhaps it is intentionally omitted..?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel