Re: cups-pdf is marked for autoremoval from testing

[Andrey Rahmatullin]

On Thu, May 26, 2022 at 02:33:20PM +0300, Martin-Éric Racine wrote:
> Someone apparently made a commit to the autoremoval hinter that makes
> it mark packages unrelated to an RC-bug package getting marked for
> autoremoval.
That's not what has happened.

> Could someone please look into this?
The bug report you replied to already has the bug report for this linked:
https://bugs.debian.org/1011268.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: cups-pdf is marked for autoremoval from testing

[Martin-Éric Racine]

Dev list,

Someone apparently made a commit to the autoremoval hinter that makes
it mark packages unrelated to an RC-bug package getting marked for
autoremoval.

Could someone please look into this?

Thanks!

Martin-Éric

On Thu, May 26, 2022 at 10:38 AM Debian testing autoremoval watch
 wrote:
>
> cups-pdf 3.0.1-14 is marked for autoremoval from testing on 2022-06-30
>
> It (build-)depends on packages with these RC bugs:
> 1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, CVE-2022-28183, 
> CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, CVE-2022-28192
>  https://bugs.debian.org/1011146
>
>
>
> This mail is generated by:
> https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
>
> Autoremoval data is generated by:
> https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl

Bug#980200: ITP: pappl -- C-based framework/library for developing CUPS Printer Applications

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-print...@lists.debian.org

Package name: pappl
Version : 1.0.1
Upstream Author : Michael R Sweet 
URL : hhttps://www.msweet.org/pappl
License : Apache License Version 2.0 with an (optional) exception to 
allow linking against GPL2/LGPL2 software
Programming Lang: C
Description : C-based framework/library for developing CUPS Printer 
Applications

 PAPPL is a simple C-based framework/library for developing CUPS Printer
 Applications, which are the recommended replacement for printer drivers. It
 was specifically developed to support LPrint and a future Gutenprint Printer
 Application but is sufficiently general purpose to support any kind of printer
 or driver that can be used on desktops, servers, and in embedded environments.

I'll be maintaining this under the Debian Printing Team umbrella. Current 
packaging
is hosted at https://salsa.debian.org/printing-team/pappl/.

Bug#911340: ITP: cpdb-backend-cups -- Common Print Dialog Backends - CUPS/IPP Backend

[Till Kamppeter]

Package: wnpp
Severity: wishlist
Owner: Till Kamppeter 

* Package name: cpdb-backend-cups
  Version : 1.1.0
  Upstream Author : Nilanjana Lodh 
* URL : https://github.com/OpenPrinting/cpdb-backend-cups
* License : MIT
  Programming Lang: C
  Description : Common Print Dialog Backends - CUPS/IPP Backend

This package needs cpdb-libs, ITP here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911335

This is already packaged for Ubuntu. This is the long description of
the Ubuntu package:

 This is the CUPS/IPP backend for print dialogs using the Common Print
 Dialog Backends concept of OpenPrinting. It makes the dialog list CUPS
 print queues and driverless-capable IPP printers and allows printing
 on these using the dialog.

The idea is to decouple the print dialog's GUI code (GTK, Qt,
LibreOffice, ... The frontends) from the code which communicates with
actual print technologies (CUPS, IPP, Google Cloud Print, Save to
File, ... The backends) to make them independently
interchangable. This way one can do things like

- Add a new print technology and it is immediately available for all
  GUI apps. Especially an online print service provider could simply
  put its backend into the Snap Store and asks his Linux users to
  install it.

- A change in a print technology, for example new functionality in
  CUPS, can be covered by simply updating the CUPS backend. No need to
  change all GUI libraries.

- User logs in for Google Cloud Print once and not separately for each
  GUI platform to get his cloud printers into all the apps.

- In case of a security bug in the communication code with one print
  technology only the backend needs to get fixed, not several GUI
  libs.

This package contains the backend for access local and remote CUPS
print queues and IPP network printers. It supplies information about
the printers, their capabilities, and user-settable options and it
passes print jobs on to printers. The print dialogs (using cpdb-libs)
connect to this backend via D-Bus. To do so, it is enough to have this
backend package installed.

For this to work at least one application with a print dialog using
cpdb-libs must be installed.

Of the GUIs LibreOffice already supports this system and only needs to
get rebuilt with this library. Patches for GTK and a modified Qt print
dialog are in the works.

All packages are already available as Ubuntu packages in Ubuntu's
Universe part. The maintenance in Debian should be done in the Debian
Printing Team.

I am not a Debian Developer but OdyX (Didier Raboud, o...@debian.org)
is willing to upload these packages.

Re: CUPS GPL → Apache license change, how to proceed?

[Holger Levsen]

On Tue, Feb 20, 2018 at 07:21:21PM +0800, Paul Wise wrote:
> adequate has an incompatible-licenses tag that probably could be used
> for this. Just install all rdeps of cups and check all packages on the
> system with adequate.
 
piuparts.debian.org does this automatically (obviously only for stuff
already in the archive...)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: CUPS GPL → Apache license change, how to proceed?

[Paul Wise]

On Tue, Feb 20, 2018 at 3:20 PM, Stuart Prescott wrote:

> I thought there might be something that could be done here.

adequate has an incompatible-licenses tag that probably could be used
for this. Just install all rdeps of cups and check all packages on the
system with adequate.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: CUPS GPL → Apache license change, how to proceed?

[Stuart Prescott]

Didier 'OdyX' Raboud wrote:

> - What tools should I be using to identify which of these will be
> undistributable constructs?  Aka: how, given a list of source packages,
> can I determine which are GPL-2-only in the codepaths that link against
> CUPS?

> [CUPS-links-to] CUPS dynamically links against
> (excluding 'system libraries' such as libc, libgcc, libstdc++)
> - cups → libusb-1.0-0 (LGPL-2.1)
> - libcups2 → libavahi-client3 & libavahi-common3 (GPL-2+)
> - libcups2 → libc6 (GPL-2+)
> - libcups2 → libgnutls30 (LGPL-2.1+)
> - libcups2 → libgssapi-krb5-2 (MIT)
> - libcups2 → zlib1g (Zlib)

Having looked at python-debian's debian.copyright.Copyright module just the 
other day, I thought there might be something that could be done here. With 
77% of the packages in the rdeps list that have a readable copyright-
format/1.0 (or an older format), we can make reasonable progress.

* we can say that 3746 (70%) of the packages in the build-rdeps list have no 
*direct* problem because they are not GPLv2-only. (That is to ignore that 
they might depend on packages that are themselves in trouble with this 
licence change)

* there are 379 packages that are GPLv2-only; that doesn't mean that they 
definitely load both GPLv2-only code and libcups* into the same executable, 
but they need checking. (gplv2-only.txt attached)

* 1220 packages haven't been checked; most aren't in copyright-format/1.0 
but a few generate parse errors or have sufficiently complicated licence 
terms that this tool can't figure it out. (unknown.txt attached)

These good(ish) looking numbers at least cut down the scope of the checking 
that is required by 70%. There's still 1600ish packages that need to be 
looked at in some way.

I'm not sure what the next steps would be. Perhaps walking the dependency 
tree looking at these 1600 packages is what should happen next. We would 
likely find places where the tree can be pruned because there is no linking 
involved, merely use of a tool at build time. I'm sure we've got graph 
walking code in the archive somewhere that might help…

For those in need of amusement, code at 

https://salsa.debian.org/stuart/package-license-checker

and all relevant copyright files (current as of unstable today) from the 
packages analysed at

https://people.debian.org/~stuart/copyright.tar.xz

Happy for suggestions, merge requests etc!

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7389-admin-console
389-ds-console
4pane
abiword
aeskulap
airport-utils
akonadi
akonadi-contacts
akonadiconsole
alsa-tools
alt-ergo
android-framework-23
android-platform-libcore
apophenia
ask
asterisk
asunder
audacity
baloo
bibtex2html
bindex
blender
blktrace
blogilo
calf
calibre
calligra
cdbs
ceph
cl-asdf
comedilib
cpl
cups-filters
daisy-player
dar
denemo
dia
diffoscope
djvusmooth
doc-linux-fr
dogtag-pki
dolphin-emu
doxygen
dozzaqueux
dpdk
dpmb
dpuser
drupal7
dtd-parser
dune-common
dune-geometry
dune-grid
dune-istl
dune-localfunctions
edb-debugger
edfbrowser
eiskaltdcpp
espresso
evas-loaders
exactimage
fbpanel
felix-framework
felix-main
felix-osgi-obr
ferret-vis
fio
foomatic-db
foxtrotgps
frama-c
free42-nologo
freefem++
freemat
frei0r
gajim
gamera
gazebo
geany-plugins
geg
geneweb
getdp
gfarm
gigedit
git-cola
gkrellm-gkrellmpc
gkrellm2-cpufreq
gkrelluim
gmanedit
gmidimonitor
gmrun
gmsh
gmtp
gnome-colors
gnuais
goobox
goocanvas-2.0
goocanvasmm-2.0
gpicview
gpsprune
gpsshogi
gpt
grace
grantlee5
grass
groovy
gspiceui
gtk-sharp3
gtk2-engines-xfce
gxmms2
hardinfo
haskell-yi-frontend-pango
heaptrack
hedgewars
hhvm
highlight.js
iio-sensor-proxy
ikiwiki
imview
ini4j
instead
invesalius
isomaster
istack-commons
jack-mixer
jalview
java-imaging-utilities
java3d
javamail
jaxb
jaxb-api
jaxrs-api
jd
jenkins-htmlunit-core-js
jericho-html
jersey1
jmol
josm
jsjac
jtharness
jtreg
juffed
kaccounts-integration
kajongg
kalarm
kamailio
kcachegrind
kdbg
kde-dev-scripts
kdeconnect
kdelibs4support
kdepim-addons
kdepim-runtime
kdepimlibs
kdocker
keepassx
kf5-messagelib
kio
kio-extras
kjots
kleopatra
kmail
kmailtransport
kmenuedit
kodi
korganizer
kpimtextedit
krita
ksirk
kstars
ksyntax-highlighting
ksysguard
ktexteditor
kturtle
ladish
lammps
latex2html
latexdiff
ldm
ldm-themes
libaopalliance-java
libemf
libexif-gtk
libgaminggear
libhtmlcleaner-java
libitext1-java
libj2ssh-java
libjgroups-java
libjpfcodegen-java
libjsr166y-java
libjtds-java
libkf5calendarsupport
libkf5eventviews
libkf5grantleetheme
libkf5gravatar
libkf5incidenceeditor
libkf5ksieve
libkf5libkdepim
libkf5libkleo
libkf5mailcommon
libkf5mailimporter
libkf5pimcommon
libnb-javaparser-java
libodb-qt
libpulse-java
librecad
libreoffice
libsimple-validation-java
libswarmcache-java
libzypp
light-locker
lightdm
lightdm-gt

Re: CUPS GPL → Apache license change, how to proceed?

[Ian Jackson]

(Adding d-legal)

Didier 'OdyX' Raboud writes ("CUPS GPL → Apache license change, how to 
proceed?"):
> tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to
> "Apache-2.0"; how should the license incompatibilities be enforced?

This reply is going to be annoying, I fear:

> Some questions at this point (Some for FTP Masters, CC'ed):
> - Does Debian hold the view that Apache-2.0 and GPL-2.0-only dynamic linking 
> is unacceptable for Debian main?  In both directions?

I think the answer is "yes, we think that is unacceptable".

ftpmaster seem rarely to reply to these kind of questions.  If you
actually want the answer, I suggest you:
 - search for existing cases and see if they got REJECTed or ACCEPTted
 - upload and see
:-/

> - Can CUPS link against GPL-2-only code?
> - Can GPL-2-only code link against CUPS?

I don't understand how these are different to the previous question.

> - Whose reponsibility is it to check for these incompatibilities, and make 
> sure they are not shipped in Debian?

I think (and this is my personal opinion) that a licence
incompatibility is a bug in the depending package, and it is the
responsibility of the depending package maintainer.

> - What tools should I be using to identify which of these will be
> undistributable constructs?

I'm not aware of any useful tools and I hope someone else will be
able to help.

>  Aka: how, given a list of source
> packages, can I determine which are GPL-2-only in the codepaths that
> link against CUPS?  - What fields could I / should I use in src:cups
> to enforce these?  I was initially thinking of setting versionless
> Breaks: in each src:cups' library against the identified GPL-2-only
> culprits, then mass-filing bugs against these, promising to add
> version constraints when/if the licensing issue gets lifted. Does
> that sound like a good way forward?

I guess.  It seems like a lot of work, and the cups transition would
be blocked.

You might instead consider simply filing bugs against the
dependencies, and setting a deadline by which they will be escalated
to RC.  You will want to discuss this with the release team.

Good luck.

Ian.

CUPS GPL → Apache license change, how to proceed?

[Didier 'OdyX' Raboud]

tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to "Apache-2.0"; how 
should the license incompatibilities be enforced?


As you might have heard [lwn][cups-apache], Apple has changed the CUPS license 
away from a "GPL-2/LGPL-2 with exceptions" to plain Apache-2.0, effective in 
the 2.3 branch [23branch] and available from 2.3~b1 on [23b1].

Despite bold attempts from Fedora and Debian community members to try 
clarifying what issues this change causes and the incompatibilities it 
creates, Apple has, so far, unsurprisingly not changed CUPS' license.

The principal issue, as I understand it, is that the Apache-2.0 license is 
incompatible with GPL-2 [apache-gpl2], although compatible with GPL-3 
(therefore compatible with GPL-2+, and with LGPL through LGPL→GPL-3).  See the 
lengthy explanation by Tom Callaway on Fedora's legal list [fedora-tom].

Further, it is my (current) understanding that having Apache-2.0 software (for 
instance, CUPS) in a dynamically-linked construct together with GPL-2-only 
software makes the result undistributable.  This seems to be a situation which 
Debian needs to protect its users from.

One way out, as outlined by Mike Sweet [system-library] as upstream author, is 
for Debian to consider that libcups/libcupsimage qualify as system-supplied 
libraries for the purposes of GPLv2.  Having these two libraries in LSB could 
support that argument, but, using that argument, Debian could have gone away 
for the OpenSSL case long ago, and didn't.  I made it clear to upstream [odyx-
statement] that this was most certainly not going to happen.

Some questions at this point (Some for FTP Masters, CC'ed):
- Does Debian hold the view that Apache-2.0 and GPL-2.0-only dynamic linking 
is unacceptable for Debian main?  In both directions?
- Can CUPS link against GPL-2-only code?
- Can GPL-2-only code link against CUPS?
- Whose reponsibility is it to check for these incompatibilities, and make 
sure they are not shipped in Debian?


Now, onto the ways forward. From a quick glance, the libraries CUPS links 
against don't seem to be an issue [CUPS-links-to], so let's focus on the 
libraries linked against CUPS' libraries (libcups2, libcupsmime1, 
libcupsppdc1, libcupsimage2, libcupscgi1).  Using `build-rdeps`, it appears 
there are 5345 packages that (also indirectly) build-depend on these packages 
(attached). I am not going to review all these by hand.  So, new questions:

- What tools should I be using to identify which of these will be 
undistributable constructs?  Aka: how, given a list of source packages, can I 
determine which are GPL-2-only in the codepaths that link against CUPS?
- What fields could I / should I use in src:cups to enforce these?  I was 
initially thinking of setting versionless Breaks: in each src:cups' library 
against the identified GPL-2-only culprits, then mass-filing bugs against 
these, promising to add version constraints when/if the licensing issue gets 
lifted. Does that sound like a good way forward?

Many thanks in advance for your insights!

Cheers,
OdyX

(
  A build-ready package is available from CUPS' Vcs-Git, in branch
  debian/experimental [cups-deb], just `dch -v2.3~b3-1local0` before building
)

[lwn] https://lwn.net/Articles/738531/
[cups-apache] https://lists.cups.org/pipermail/cups-devel/2017-November/
017085.html
[23branch] https://github.com/apple/cups/tree/master
[23b1] https://github.com/apple/cups/releases/tag/v2.3b1
[apache-gpl2] https://www.apache.org/licenses/GPL-compatibility.html
[fedora-tom] https://lists.fedoraproject.org/archives/list/
le...@lists.fedoraproject.org/message/NEQDL6V4RBRQTPI3YYBSZH5CTZG257F2/
[system-library] https://lists.cups.org/pipermail/cups-devel/2017-November/
017095.html
[odyx-statement] https://lists.cups.org/pipermail/cups-devel/2017-December/
017097.html
[cups-deb] https://salsa.debian.org/printing-team/cups/tree/debian/
experimental

[CUPS-links-to] CUPS dynamically links against
    (excluding 'system libraries' such as libc, libgcc, libstdc++)
- cups → libusb-1.0-0 (LGPL-2.1)
- libcups2 → libavahi-client3 & libavahi-common3 (GPL-2+)
- libcups2 → libc6 (GPL-2+)
- libcups2 → libgnutls30 (LGPL-2.1+)
- libcups2 → libgssapi-krb5-2 (MIT)
- libcups2 → zlib1g (Zlib)0ad
2048-qt
389-admin-console
389-console
389-ds-console
3depict
3dldf
4pane
4ti2
a2ps
aac-tactics
abego-treelayout
abgate
abinit
abiword
ableton-link
abntex
aboot
abx
accerciser
access-modifier-checker
accessodf
ace
acedb
ace-link
ace-popup-menu
acetoneiso
ace-window
acl2
aclock.app
actiona
activemq
activemq-activeio
activemq-protobuf
actor-framework
adacontrol
ada-reference-manual
adasockets
addresses-for-gnustep
adql
adun.app
advi
adwaita-icon-theme
adwaita-qt
aegisub
aeskulap
aespipe
aether
aether-ant-tasks
aewm
afew
affiche
afterburner.fx
afterstep
agda
agenda.app
aggressive-indent-mode
agherm

Refresh the CUPS driver recommends (was: Re: Opt out style recommends)

[Didier 'OdyX' Raboud]

Package: cups
Version: 1.5.2-9

Le vendredi, 8 avril 2016, 10.31:17 Josh Triplett a écrit :
> I'm not going to go through a full analysis here, but here's a *tiny*
> subset of the output on my system, with some annotations:
> 
> (…)
> cups Recommends: printer-driver-gutenprint
> 
> Why does cups recommend some printer drivers and only suggest others?
> For instance, I have printer-driver-hpcups installed instead.

This should indeed be changed. Reporting a bug to keep track.

-- 
Cheers,
OdyX

Bug#807615: ITP: printer-driver-indexbraille -- CUPS printing to Index Braille printers

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: printer-driver-indexbraille
  Version : 1.2.2
  Upstream Author : Index Braille AB.
* URL : http://indexbraille.com
* License : GPLv2
  Programming Lang: C, shell
  Description : CUPS printing to Index Braille printers

This package contans the necessary filters and PPDs for installing and
printing to Index Braille printers.

It will be mostly maintained by the manufacturer itself.

Samuel

Bug#792660: ITP: cups-x2go -- Virtual X2Go printer for CUPS

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: cups-x2go
  Version : 3.0.1.3
  Upstream Author : Oleksandr Shneyder 
* URL : http://wiki.x2go.org
* License : GPL
  Programming Lang: Perl
  Description : Virtual X2Go printer for CUPS

 X2Go is a server based computing environment with
- session resuming
- low bandwidth support
- session brokerage support
- client side mass storage mounting support
- audio support
- authentication by smartcard and USB stick

 CUPS-X2Go provides a CUPS-backend for X2Go printing.

 This package will be provided by the X2Go Packaging Team.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150717082130.14260.34476.report...@minobo.das-netzwerkteam.de

Re:Serve High Quality Baking Cups/cake board/cake stand

[vicky]

Dear Purchasing Manager,


We are mainly specialize in various cupcake cups,cupcake wrapper,baking 
moulds,muffin cups,cake boards,paper straw and etc.

Please contact me ris...@ltwpack.com for any questions.


Best Regards,
Vicky

Re: CUPS is now linked against OpenSSL (and will stay GPLv2-only)

[Didier 'OdyX' Raboud]

Le mardi, 28 janvier 2014, 16.07:34 Daniel Kahn Gillmor a écrit :
> On Sun 2013-12-22 14:12:40 -0500, Andreas Metzler wrote:
> > #3 Hope that GMP is relicensed to GPL2+/LGPLv3+
> 
> On Tue 2014-01-14 04:53:51 -0500, Didier 'OdyX' Raboud wrote:
> > 2) GnuTLS
> > 
> >2.x is useable but deprecated, 3.x is GPLv3+ through GMP. We're
> >back to "talk to the FSF to license GMP back to LGPLv2+"
> 
> I think OdyX is asking for more from GMP than is necessary; note that
> Andreas earlier pointed out that GMP just needs to be GPL2+/LGPLv3+.

Ah yeah, good point. I was merely asking for a revert of the change that 
broke the GPLv2-only uses. I had overlooked that "GPLv2+/LGPLv3+" would 
also be okay; thanks for having pointed that out.

> This is exactly what libgmp (in particular, Torbjorn Granlund
> ) appears to have decided to do as of yesterday:
> 
> Changelog:
>   https://gmplib.org/repo/gmp/rev/02634effbd4e
> Huge diff with licensing changes:
>   https://gmplib.org/repo/gmp/rev/da670a8513db
> 
> So i believe this makes the GPLv2-only CUPS re-distributable again
> when linked to modern versions of GnuTLS.

That's quite awesome news! Let's see if that makes it to a public 
release (which I don't doubt) and we'll have a clean way forward after 
GnuTLS 2.x !

Cheers,

OdyX

signature.asc
Description: This is a digitally signed message part.

Re: CUPS is now linked against OpenSSL (and will stay GPLv2-only)

[Daniel Kahn Gillmor]

On Sun 2013-12-22 14:12:40 -0500, Andreas Metzler wrote:

> #3 Hope that GMP is relicensed to GPL2+/LGPLv3+

On Tue 2014-01-14 04:53:51 -0500, Didier 'OdyX' Raboud wrote:

> 2) GnuTLS
>2.x is useable but deprecated, 3.x is GPLv3+ through GMP. We're back
>to "talk to the FSF to license GMP back to LGPLv2+"

I think OdyX is asking for more from GMP than is necessary; note that
Andreas earlier pointed out that GMP just needs to be GPL2+/LGPLv3+.

This is exactly what libgmp (in particular, Torbjorn Granlund
) appears to have decided to do as of yesterday:

Changelog:
  https://gmplib.org/repo/gmp/rev/02634effbd4e
Huge diff with licensing changes:
  https://gmplib.org/repo/gmp/rev/da670a8513db 

So i believe this makes the GPLv2-only CUPS re-distributable again when
linked to modern versions of GnuTLS.

Happy Hacking,

   --dkg


pgpxiOPBSQOhM.pgp
Description: PGP signature

Re: Bug#736826: ITP: tea4cups -- The Swiss Army's knife of advanced CUPS administrators

[Chris Bannister]

On Mon, Jan 27, 2014 at 11:02:55AM +0100, Mike Gabriel wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Mike Gabriel 
> 
> * Package name: tea4cups
>   Version : 3.13~alpha1+svn3565
>   Upstream Author : Jerome Alet 
> * URL : http://www.pykota.com/software/tea4cups
> * License : GPL
>   Programming Lang: Python
>   Description : The Swiss Army's knife of advanced CUPS administrators
>  .
>  Tea4CUPS is the Swiss Army's knife of the advanced CUPS administrator, and

Sorry, but I think you'll find that it's actually 'Swiss Army knife'

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128131958.GF24708@tal

Bug#736826: ITP: tea4cups -- The Swiss Army's knife of advanced CUPS administrators

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: tea4cups
  Version : 3.13~alpha1+svn3565
  Upstream Author : Jerome Alet 
* URL : http://www.pykota.com/software/tea4cups
* License : GPL
  Programming Lang: Python
  Description : The Swiss Army's knife of advanced CUPS administrators

 Tea4CUPS is a CUPS backend wrapper which can capture print datas before they
 are sent to a printer and process, duplicate or dispatch them in a number of
 ways.
 .
 Tea4CUPS is the Swiss Army's knife of the advanced CUPS administrator, and
 can easily replace or extend most of the existing specialized CUPS backends
 (pdf, email, ftp, etc...).
 .
 You are greatly encouraged to use this software instead of writing your own
 CUPS backends: Tea4CUPS will let you plug your own scripts, filters, tools,
 or commands wherever you want, while giving them access to all the print
 job's characteristics in a consistent way.
 .
 Tea4CUPS makes all information about the current print job, in particular the
 job's datas and attributes, available to your own commands through environment
 variables.
 .
 The possibilities are endless:
 .
   - Your own commands can optionally decide to discard the current print job
 instead of printing it.
   - Send the same job to several printers at the same time, which is not 
possible
 with CUPS.
   - Automate the PDF archiving of all print jobs.
   - Forbid duplicate print jobs (a simple example is shown in the sample
 configuration file)
   - Easily create a print accounting solution.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140127100255.2732.1135.report...@minobo.das-netzwerkteam.de

Re: CUPS is now linked against OpenSSL

[brian m. carlson]

On Mon, Jan 13, 2014 at 11:03:04PM -0500, Daniel Kahn Gillmor wrote:
> Alternately, does anyone know anyone from the polarssl community who we
> could cajole into patching that TLS implementation into CUPS?

I'd like to point out that PolarSSL doesn't correctly implement TLS 1.0
since it doesn't support the mandatory cipher suite.  That isn't a
practical problem, since nobody implements only that cipher suite, but
it is a conformance issue that needs to be addressed.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: CUPS is now linked against OpenSSL

[Henrique de Moraes Holschuh]

On Tue, 14 Jan 2014, Jakub Wilk wrote:
> * Daniel Kahn Gillmor , 2014-01-13, 23:03:
> >if the only axis we're measuring along is cryptographic security,
> >then protecting against passive attackers (eavesdroppers) is
> >clearly better than not doing so.
> >
> >but if people think that CUPS' TLS protects them against active
> >attackers, and they use that to do things like send confidential
> >information over the link, they have been lulled into a false
> >sense of security.
> 
> Hear, hear.
> 
> So, how would people feel about the following policy:
> 
> TLS clients must either:
> - validate server certificates;
> - or prominently document that they don't do that?

As in log "unsafe TLS connection to "?

Because anything less than that would not be effective at all.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140114114323.gb31...@khazad-dum.debian.net

Re: CUPS is now linked against OpenSSL

[Jakub Wilk]

* Daniel Kahn Gillmor , 2014-01-13, 23:03:
if the only axis we're measuring along is cryptographic security, then 
protecting against passive attackers (eavesdroppers) is clearly better 
than not doing so.


but if people think that CUPS' TLS protects them against active 
attackers, and they use that to do things like send confidential 
information over the link, they have been lulled into a false sense of 
security.


Hear, hear.

So, how would people feel about the following policy:

TLS clients must either:
- validate server certificates;
- or prominently document that they don't do that?

?

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140114113150.ga11...@jwilk.net

Re: CUPS is now linked against OpenSSL (and will stay GPLv2-only)

[roucaries bastien]

On Tue, Jan 14, 2014 at 10:53 AM, Didier 'OdyX' Raboud  wrote:
> Le lundi, 13 janvier 2014, 17.38:12 Didier Raboud a écrit :
>> Le samedi, 11 janvier 2014, 14.22:28 Daniel Kahn Gillmor a écrit :
>> >  0) ask CUPS to move from GPL2 to GPL2+ (with or without OpenSSL
>> > exception)
>>
>> As asking generally can't hurt, I have filed
>> https://cups.org/str.php?L4337 on the upstream bugtracker to discuss
>> that. I'll keep the list posted.
>
> The answer came back faster than I expected and is public [1], I'm
> quoting it here for completeness' sake:
>
> Le lundi, 13 janvier 2014, 14:24:33 Michael Sweet a écrit :
>> We cannot, for a number of legal and (Apple) liability reasons,
>> relicense CUPS as [L]GPL2+.  It will never happen.
>>
>> OpenSSL support has been removed from the CUPS 2.0 source code and is
>> not an option.
>>
>> That leaves you with using GnuTLS ([L]GPL2/3) or porting Apple's
>> CDSA/Security code (Apache license), although the Apache license may
>> not be GPL3 compatible according to the FSF.  Given that GnuTLS is
>> included with basically every Linux distribution as a standard OS
>> component, it SHOULD automatically fall under the [L]GPL2/3 exception
>> for system libraries (just as OpenSSL should have fallen under the
>> same exception...)  If not, then I humbly suggest you talk to the FSF.
>
> Now, for the set of options he described:
>
> 1) OpenSSL
>As he claims that OpenSSL has been removed from the master CUPS
>branch, I think that this, by itself, disqualifies the linking of
>libcups2 against OpenSSL, as it would be a dead end.
>
> 2) GnuTLS
>2.x is useable but deprecated, 3.x is GPLv3+ through GMP. We're back
>to "talk to the FSF to license GMP back to LGPLv2+"
>
> 3) Apple CDSA / libsecurity
>From [1], this is currently being deprecated by Apple from OSX v10.7.
>Also, it licensed under the APSL [Apple Public Source License] which
>is incompatible with the GPL. It isn't packaged in Debian as far as I
>could find.

4/ Port to lib nss using  comptability layer.


> So in the current situation, I don't see any good long-term solution but
> a port to another license-compatible library such as polarssl…
>
> Cheers,
> OdyX
>
> [1] And GPG-signed:
> http://www.cups.org/pipermail/cups-devel/2014-January/014768.html
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAE2SPAYVsY1qLW2x7RYZ+6thoT=r48xqgrdt-qkzer8rrmm...@mail.gmail.com

Re: CUPS is now linked against OpenSSL (and will stay GPLv2-only)

[Didier 'OdyX' Raboud]

Le mardi, 14 janvier 2014, 10.53:51 Didier '' Raboud a écrit :
> 3) Apple CDSA / libsecurity
>From [1], this is currently being deprecated by Apple from OSX
>v10.7.

Meh. The link should have been

https://developer.apple.com/library/mac/documentation/security/conceptual/cryptoservices/CDSA/CDSA.html

It is apparently replaced by CommonCrypto

signature.asc
Description: This is a digitally signed message part.

Re: CUPS is now linked against OpenSSL (and will stay GPLv2-only)

[Didier 'OdyX' Raboud]

Le lundi, 13 janvier 2014, 17.38:12 Didier Raboud a écrit :
> Le samedi, 11 janvier 2014, 14.22:28 Daniel Kahn Gillmor a écrit :
> >  0) ask CUPS to move from GPL2 to GPL2+ (with or without OpenSSL
> > exception)
> 
> As asking generally can't hurt, I have filed
> https://cups.org/str.php?L4337 on the upstream bugtracker to discuss
> that. I'll keep the list posted.

The answer came back faster than I expected and is public [1], I'm 
quoting it here for completeness' sake:

Le lundi, 13 janvier 2014, 14:24:33 Michael Sweet a écrit :
> We cannot, for a number of legal and (Apple) liability reasons,
> relicense CUPS as [L]GPL2+.  It will never happen.
> 
> OpenSSL support has been removed from the CUPS 2.0 source code and is
> not an option.
> 
> That leaves you with using GnuTLS ([L]GPL2/3) or porting Apple's
> CDSA/Security code (Apache license), although the Apache license may
> not be GPL3 compatible according to the FSF.  Given that GnuTLS is
> included with basically every Linux distribution as a standard OS
> component, it SHOULD automatically fall under the [L]GPL2/3 exception
> for system libraries (just as OpenSSL should have fallen under the
> same exception...)  If not, then I humbly suggest you talk to the FSF.

Now, for the set of options he described:

1) OpenSSL
   As he claims that OpenSSL has been removed from the master CUPS
   branch, I think that this, by itself, disqualifies the linking of
   libcups2 against OpenSSL, as it would be a dead end.

2) GnuTLS
   2.x is useable but deprecated, 3.x is GPLv3+ through GMP. We're back
   to "talk to the FSF to license GMP back to LGPLv2+"

3) Apple CDSA / libsecurity
   From [1], this is currently being deprecated by Apple from OSX v10.7.
   Also, it licensed under the APSL [Apple Public Source License] which
   is incompatible with the GPL. It isn't packaged in Debian as far as I
   could find.

So in the current situation, I don't see any good long-term solution but 
a port to another license-compatible library such as polarssl…

Cheers,
OdyX

[1] And GPG-signed:
http://www.cups.org/pipermail/cups-devel/2014-January/014768.html


signature.asc
Description: This is a digitally signed message part.

Re: CUPS is now linked against OpenSSL

[Daniel Kahn Gillmor]

On 01/13/2014 11:38 AM, Didier 'OdyX' Raboud wrote:

> That would be quite a bold move to take. The one aspect that puzzles me 
> most is: in which ways "no TLS security" is better than "incompletely 
> secure TLS"? 

if the only axis we're measuring along is cryptographic security, then
protecting against passive attackers (eavesdroppers) is clearly better
than not doing so.

but if people think that CUPS' TLS protects them against active
attackers, and they use that to do things like send confidential
information over the link, they have been lulled into a false sense of
security.

And: cryptographic security is not the only axis we should be measuring
on.  The other axis is difficulty of license compliance, and CUPS
licensing is currently in a state that i would consider it difficult to
ship effectively with any sort of well-maintained cryptographic support
and remain in compliance with all the relevant licenses.

Does this make CUPS less useful than it used to be?  Is this a
regression?  yes, and yes.  That's why we should try to get one project
(either CUPS or GMP) to change their licensing to fix the issue rather
than trying to get dozens of projects to change their licensing.

Alternately, does anyone know anyone from the polarssl community who we
could cajole into patching that TLS implementation into CUPS?

--dkg



signature.asc
Description: OpenPGP digital signature

Re: CUPS is now linked against OpenSSL

[Didier 'OdyX' Raboud]

Hi Daniel, and thanks for the insightful response,

Le samedi, 11 janvier 2014, 14.22:28 Daniel Kahn Gillmor a écrit :
> There is a fourth way forward -- loath though i am to propose it --
> which is to avoid enabling TLS in CUPS at all until upstream gets
> their act together and does something sensible, both licensing-wise
> and crypto-wise.

That would be quite a bold move to take. The one aspect that puzzles me 
most is: in which ways "no TLS security" is better than "incompletely 
secure TLS"? Now some CUPS bugs are probably not known widely enough and 
we could warn about using CUPS's TLS support in the packaging, wording 
welcome.

Also, TLS is enabled in all actually our supported src:cups uploads. 
Introducing this regression is a move for which I would need quite a 
strong encouragement to proceed with.

> last i checked, cups does not support certificate validation or
> checking [0], making the crypto vulnerable to any active attacker:
> 
> [0] http://www.cups.org/str.php?L1616
> 
> According to the roadmap [0] this is due on the 2.0 branch, but i
> haven't seen it yet.
> 
> [1] http://www.cups.org/roadmap.php

Quite bad indeed. I have pinged that bug to see whether a fix could 
happen earlier.

> The idea of opening RC bugs against everything that links to libcups2
> to demand an OpenSSL exception sounds really, really ugly to me. 
> what about the packages that link to those packages?  I'd rather see
> less OpenSSL, not more, because of its mutual incompatibility  with
> the GPL.

Frightening can of worms.

>  0) ask CUPS to move from GPL2 to GPL2+ (with or without OpenSSL
> exception)

As asking generally can't hurt, I have filed 
https://cups.org/str.php?L4337 on the upstream bugtracker to discuss 
that. I'll keep the list posted.

>  1) ask GMP to switch back from LGPLv3+ to LGPLv2+ (it made the change
> in 4.2.2).  Does anyone have a strong relationship with GMP 
> maintainers who could open this conversation with them?

I don't, but would hope the libgmp maintainers could ask the question; 
I've hereby CC'ed Steve.

>  2) turn off TLS support in CUPS until upstream works things out and
> actually provides some cryptographic defense against an active
> attacker

For now, I will rather revert the switch to OpenSSL and …

>  5) ask dozens of packages which already have reasonable copyleft
> licensing to make openssl execptions, iterating until we've covered
> everything contaminated with this mess.

… try to see what this can of worms looks like.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: CUPS is now linked against OpenSSL

[Holger Levsen]

Hi Ian,

On Sonntag, 12. Januar 2014, Ian Jackson wrote:
> The argument I would make (because I believe in it) is that lack of
> good cryptographic software is a bigger threat to the freedom of users
> than tivoisation (and, the other downsides of GPLv2 compared to v3).

absolutly agreed! Please go for it!

> I'm no fan of TLS but it is very unfortunate that we are considering
> further weakening security provisions in printing protocols, for
> example, because of this kind of licensing problem.
[...]
> For vaguely analogous reasons we (the free software world) try to make
> our codecs have very liberal licences.

also.


cheers,
Holger




signature.asc
Description: This is a digitally signed message part.

Re: CUPS is now linked against OpenSSL

[Ian Jackson]

Russ Allbery writes ("Re: CUPS is now linked against OpenSSL"):
> Isn't GMP an official GNU project?  I thought the FSF had an
> organization-wide policy to relicense all of their packages to v3 or
> later.

Perhaps we might be able to persaude them to make an exception for
GMP.  The FSF certainly recognise that licensing decisions are a
question of tactics.

The argument I would make (because I believe in it) is that lack of
good cryptographic software is a bigger threat to the freedom of users
than tivoisation (and, the other downsides of GPLv2 compared to v3).
I'm no fan of TLS but it is very unfortunate that we are considering
further weakening security provisions in printing protocols, for
example, because of this kind of licensing problem.

(This is true even though a GPLv2+ GMP can be used as _part of_ a
cryptographically enforced tivoisation setup, whereas a GPLv3+ GMP can
only be part of such a system at the "mater" rather than "slave" end.)

For vaguely analogous reasons we (the free software world) try to make
our codecs have very liberal licences.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21201.52641.560191.663...@chiark.greenend.org.uk

Re: CUPS is now linked against OpenSSL

[Russ Allbery]

Daniel Kahn Gillmor  writes:
> On 01/11/2014 02:22 PM, Daniel Kahn Gillmor wrote:

>>  1) ask GMP to switch back from LGPLv3+ to LGPLv2+ (it made the change
>> in 4.2.2).  Does anyone have a strong

> Bah.  This was supposed to say "Does anyone have a strong relationship
> with GMP maintainers who could open this conversation with them?"

> i'd be willing to participate to that discussion if someone can make
> good introductions to get the ball rolling.

Isn't GMP an official GNU project?  I thought the FSF had an
organization-wide policy to relicense all of their packages to v3 or
later.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txdaw9y0@windlord.stanford.edu

Re: CUPS is now linked against OpenSSL

[Daniel Kahn Gillmor]

On 01/11/2014 02:22 PM, Daniel Kahn Gillmor wrote:

>  1) ask GMP to switch back from LGPLv3+ to LGPLv2+ (it made the change
> in 4.2.2).  Does anyone have a strong

Bah.  This was supposed to say "Does anyone have a strong relationship
with GMP maintainers who could open this conversation with them?"

i'd be willing to participate to that discussion if someone can make
good introductions to get the ball rolling.

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature

Re: CUPS is now linked against OpenSSL

[Daniel Kahn Gillmor]

On 01/11/2014 11:55 AM, Didier 'OdyX' Raboud wrote:
> So as far as CUPS is concerned, I see three ways forward:
> 
> 1) revert the switch to OpenSSL and link against GnuTLS 2. This
>basically postpones the question to the moment when GnuTLS 2 is
>removed from Debian. As I understood the thread, GnuTLS 2 is likely
>to be removed from testing before the freeze, right?
> 
> 2) switch to GnuTLS 3. This is not allowed because GnuTLS 3 is GPL-3 and
>CUPS is GPL-2 only.
> 
> 3) report RC bugs against all packages linking against libcups2
>which licenses don't allow indirect linking to OpenSSL (mostly GPL-
>-without-OpenSSL-exception) and hope that fixes can be found license-
>-wise. There are >= 38 packages build-depending on libcups2-dev and
>>= 120 packages depending on libcups2. Also, I am not aware of tools 
>to detect this incompatibility automatically. I also doubt we'll be
>able to find solutions for all packages; yet libcups2 is quite
>important in desktop stacks.

There is a fourth way forward -- loath though i am to propose it --
which is to avoid enabling TLS in CUPS at all until upstream gets their
act together and does something sensible, both licensing-wise and
crypto-wise.

last i checked, cups does not support certificate validation or checking
[0], making the crypto vulnerable to any active attacker:

[0] http://www.cups.org/str.php?L1616

According to the roadmap [0] this is due on the 2.0 branch, but i
haven't seen it yet.

[1] http://www.cups.org/roadmap.php

This is a terrible solution, but an encryption layer that silently fails
open in the presence of an adversary is a bad thing too, especially if
it introduces all sorts of licensing gymnastics.

The idea of opening RC bugs against everything that links to libcups2 to
demand an OpenSSL exception sounds really, really ugly to me.  what
about the packages that link to those packages?  I'd rather see less
OpenSSL, not more, because of its mutual incompatibility  with the GPL.

Modern versions of GnuTLS could be GPL2+ if GMP relaxes their licensing,
which would also solve this situation, and would be a better win for
copyleft and free software all around.

If we're willing to go around asking folks for changes to their
licensing, my preferences would be (highest preferences first):

 0) ask CUPS to move from GPL2 to GPL2+ (with or without OpenSSL exception)

 1) ask GMP to switch back from LGPLv3+ to LGPLv2+ (it made the change
in 4.2.2).  Does anyone have a strong

 2) turn off TLS support in CUPS until upstream works things out and
actually provides some cryptographic defense against an active attacker

 3) drive bamboo shoots under my fingernails

 4) patch CUPS to use some other GPL2-compatible TLS implementation
(libnss?  polarssl?)

 5) ask dozens of packages which already have reasonable copyleft
licensing to make openssl execptions, iterating until we've covered
everything contaminated with this mess.

(ok, maybe 3 and 4 are actually tied)

happy hacking,

--dkg



signature.asc
Description: OpenPGP digital signature

Re: CUPS is now linked against OpenSSL

[Cameron Norman]

El sáb, 11 de ene 2014 a las 10:41 , Russ Allbery  
escribió:

Matthias Klumpp  writes:


 Changing this would only mean that CUPS forks have the option to be
 distributed under GPLv3. I don't see a reason why Apple should be
 against this.

Apple appears to be against anything containing the phrase GPLv3, to 
the
extent that their employees were even forbidden from reading GCC 
mailing

lists once the project started considering GPLv3 patches.  Presumably
their lawyers freaked out about something in the license, possibly the
patent handling.



It seems like it was the tivo-ization stuff. They license a lot of 
their stuff under the Apache v2 license, so I do not think it is the 
patent provisions that frighten them.


--
Cameron Norman

Re: CUPS is now linked against OpenSSL (was: Re: GnuTLS in Debian)

[Steve Langasek]

On Sat, Jan 11, 2014 at 05:24:16PM +, Ben Hutchings wrote:
> On Sat, 2014-01-11 at 17:55 +0100, Didier 'OdyX' Raboud wrote:
> > Hi all,
> > 
> > this "GnuTLS in Debian" thread triggered my switch of the src:cups 
> > package from linking against GnuTLS to now link against OpenSSL. CUPS is 
> > GPL-2 only with an OpenSSL exception.
> > 
> > Today, Andreas rightly pointed to me that this induces a problem (for 
> > Debian) for all GPL-without-OpenSSL-exception programs linked against 
> > libcups2. As far as I understand our current stance on that problem, 
> > GPL-licensed programs without an OpenSSL exception are absolutely 
> > forbidden to link with it, even indirectly.
> [...]

> I think this is an absurd interpretation.  It is certainly not being
> applied to linux-tools, where we have perf linked against libpython
> linked against OpenSSL.

$ ldd /usr/bin/perf_3.12 |grep ssl
$

This is not an analogous situation.  libpython does *not* link against
OpenSSL; it merely supports dynamically loading libssl on behalf of python
programs that request it.  So perf is not loading OpenSSL into memory, and
there is no GPL problem here.  I would suggest dropping the disclaimer from
the copyright file, as it's not really applicable.

Had the situation actually been analogous, with perf calling into openssl
code via libpython, I would have filed a serious bug against linux-tools in
response to your message.  This is not a matter that maintainers are
entitled to exercise their own opinions on; if Debian were to decide to no
longer hold itself to the letter of the GPL, that's a decision for the
project to make as a whole.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: CUPS is now linked against OpenSSL

[Russ Allbery]

Matthias Klumpp  writes:

> Changing this would only mean that CUPS forks have the option to be
> distributed under GPLv3. I don't see a reason why Apple should be
> against this.

Apple appears to be against anything containing the phrase GPLv3, to the
extent that their employees were even forbidden from reading GCC mailing
lists once the project started considering GPLv3 patches.  Presumably
their lawyers freaked out about something in the license, possibly the
patent handling.

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874n5axsx5@windlord.stanford.edu

Re: CUPS is now linked against OpenSSL

[Matthias Klumpp]

2014/1/11 Andreas Metzler :
> Svante Signell  wrote:
> [...]
>> What are the chances of cups re-licensing (dual-licensing) to GPL2+?
>> This would be a step in the right direction. (in worst case use some
>> other software package than cups as default for printing)
>
> I'd guess minimal, iirc Apple has no love for GPLv3.
Changing this would only mean that CUPS forks have the option to be
distributed under GPLv3. I don't see a reason why Apple should be
against this.
But I guess a decision like this would run with low priority over there...
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny-x=3wjuhq1spxdy6htsbwkxtckzpnoocqkopk7plu...@mail.gmail.com

Re: CUPS is now linked against OpenSSL

[Andreas Metzler]

Svante Signell  wrote:
[...]
> What are the chances of cups re-licensing (dual-licensing) to GPL2+?
> This would be a step in the right direction. (in worst case use some
> other software package than cups as default for printing)

I'd guess minimal, iirc Apple has no love for GPLv3.
cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/98e8qa-1uu@argenau.downhill.at.eu.org

Re: CUPS is now linked against OpenSSL (was: Re: GnuTLS in Debian)

[Svante Signell]

On Sat, 2014-01-11 at 17:55 +0100, Didier 'OdyX' Raboud wrote:
> Hi all,
> 
> this "GnuTLS in Debian" thread triggered my switch of the src:cups 
> package from linking against GnuTLS to now link against OpenSSL. CUPS is 
> GPL-2 only with an OpenSSL exception.

> Now, as far as I understood the thread, there are suggestions floating 
> around to stop caring about this incompatibility and just consider "as a 
> project" that OpenSSL is a system library, but this decision hasn't been 
> formally taken yet.
> 
> So as far as CUPS is concerned, I see three ways forward:
> 
> 1) revert the switch to OpenSSL and link against GnuTLS 2. This
>basically postpones the question to the moment when GnuTLS 2 is
>removed from Debian. As I understood the thread, GnuTLS 2 is likely
>to be removed from testing before the freeze, right?
> 
> 2) switch to GnuTLS 3. This is not allowed because GnuTLS 3 is GPL-3 and
>CUPS is GPL-2 only.

What are the chances of cups re-licensing (dual-licensing) to GPL2+?
This would be a step in the right direction. (in worst case use some
other software package than cups as default for printing)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1389462256.3662.22.camel@PackardBell-PC

Re: CUPS is now linked against OpenSSL (was: Re: GnuTLS in Debian)

[Ben Hutchings]

On Sat, 2014-01-11 at 17:55 +0100, Didier 'OdyX' Raboud wrote:
> Hi all,
> 
> this "GnuTLS in Debian" thread triggered my switch of the src:cups 
> package from linking against GnuTLS to now link against OpenSSL. CUPS is 
> GPL-2 only with an OpenSSL exception.
> 
> Today, Andreas rightly pointed to me that this induces a problem (for 
> Debian) for all GPL-without-OpenSSL-exception programs linked against 
> libcups2. As far as I understand our current stance on that problem, 
> GPL-licensed programs without an OpenSSL exception are absolutely 
> forbidden to link with it, even indirectly.
[...]

I think this is an absurd interpretation.  It is certainly not being
applied to linux-tools, where we have perf linked against libpython
linked against OpenSSL.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


signature.asc
Description: This is a digitally signed message part

CUPS is now linked against OpenSSL (was: Re: GnuTLS in Debian)

[Didier 'OdyX' Raboud]

Hi all,

this "GnuTLS in Debian" thread triggered my switch of the src:cups 
package from linking against GnuTLS to now link against OpenSSL. CUPS is 
GPL-2 only with an OpenSSL exception.

Today, Andreas rightly pointed to me that this induces a problem (for 
Debian) for all GPL-without-OpenSSL-exception programs linked against 
libcups2. As far as I understand our current stance on that problem, 
GPL-licensed programs without an OpenSSL exception are absolutely 
forbidden to link with it, even indirectly.

Now, for the actual situation: I initially switched cups following my 
option 0) aka:

0) "move away from GnuTLS as its newer versions are incompatible with
GPL-2, use OpenSSL as cups is allowed to be linked against it"

… but I had overlooked the indirect linking problem.

Now, as far as I understood the thread, there are suggestions floating 
around to stop caring about this incompatibility and just consider "as a 
project" that OpenSSL is a system library, but this decision hasn't been 
formally taken yet.

So as far as CUPS is concerned, I see three ways forward:

1) revert the switch to OpenSSL and link against GnuTLS 2. This
   basically postpones the question to the moment when GnuTLS 2 is
   removed from Debian. As I understood the thread, GnuTLS 2 is likely
   to be removed from testing before the freeze, right?

2) switch to GnuTLS 3. This is not allowed because GnuTLS 3 is GPL-3 and
   CUPS is GPL-2 only.

3) report RC bugs against all packages linking against libcups2
   which licenses don't allow indirect linking to OpenSSL (mostly GPL-
   -without-OpenSSL-exception) and hope that fixes can be found license-
   -wise. There are >= 38 packages build-depending on libcups2-dev and
   >= 120 packages depending on libcups2. Also, I am not aware of tools 
   to detect this incompatibility automatically. I also doubt we'll be
   able to find solutions for all packages; yet libcups2 is quite
   important in desktop stacks.

So there is apparently no good solution on the long-term if the need for 
OpenSSL exceptions isn't waived. For now, I'm leaning towards solution 
1) to avoid willingly introducing dozens of RC bugs in testing when 
libcups2 enters testing (unless I create a "maintainer RC bug" blocked 
by all the 3)-created bugs).

I would really welcome opinions and advices on this matter.

Many thanks in advance, cheers,

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#695401: ITP: cups-bjnp -- CUPS back-end for the canon printers using the proprietary USB over IP BJNP protocol

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 

* Package name: cups-bjnp
  Version : 1.2
  Upstream Author : Louis Lagendijk 
* URL : http://cups-bjnp.sourceforge.net/
* License : GPL-2
  Programming Lang: C
  Description : CUPS back-end for the canon printers using the proprietary 
USB over IP BJNP protocol

This back-end allows Cups to print over the network to a Canon printer.
It is designed using reverse engineering of the protocol. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121207184727.17351.84786.report...@brain.nahmias.net

Processed: Re: Problems with either samba and/or cups and printing from windows

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 660651 samba
Bug #660651 [general] general: Problems with either samba and/or cups and 
printing from windows
Bug reassigned from package 'general' to 'samba'.
> tags 660651 + moreinfo
Bug #660651 [samba] general: Problems with either samba and/or cups and 
printing from windows
Added tag(s) moreinfo.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
660651: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660651
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.132976308930189.transcr...@bugs.debian.org

Bug#660651: Problems with either samba and/or cups and printing from windows

[Jonathan Nieder]

reassign 660651 samba
tags 660651 + moreinfo
quit

Hi Christian,

Christian Andretzky wrote:

> Sorry for using the general tag, but I've no idea which of the named packages 
> is responsible
> for the problem.

That doesn't make it a general issue.  Reassigning to samba, since
one has to start somewhere.

What versions of samba and cups do you have installed?  Can you attach
output from "reportbug --template samba"?  What does /etc/papersize
say?

Thanks for writing, and hope that helps,
Jonathan

> We have a samba server as domain controler and do all printings via
> cups.
>
> The cups server is located on the same machine and printing fom
> linux was never a problem.
>
> For various reasons we set the set the 'cups options' switch in
> /etc/smb.conf to empty, so that cups handles the print jobs from the
> windows client completely (not only printqueue administration)
>
> All things work as expected with one big exception.
>
> I'm unable to set/maintain the samba server default settings for
> paper size. I can do other changes in the server settings like
> comment or location for the printers with no problems (I can do this
> from windows either via menu or via commandline with no problems.)
> The result is stored in the ntprinters.tdb But if I try to change
> the default paper size for the printer, it only seems to work, but
> it is never stored in the ntprinters.tdb.
>
> The big problem for me is, why (either samba or cups) think, they
> have to set the default paper size to letter.
>
> Nothing in our whole configuration (neither in cups, nor in samba
> and in windows also) has paper sizes of the type 'letter'.
>
> For our users this is a really frustrating and time/paper intensive
> problem, because many of them work with remote desktops and
> dynamically created printer forwardings from remote printers to
> local printers. Don't ask me why, sometimes such printer
> forwardings have 'letter' as default paper size.
>
> By necessity I tried to change ntprinters.tdb with a hex editor. It
> seems to work, but after some time my 'A4' setting were overwritten
> with letter.
>
> If you need more details, feel free to ask.
>
> TIA for Your help.
>
> Christian
>
> -- System Information:
> Debian Release: 6.0.4
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.32-5-amd64 (SMP w/6 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120220183726.GA18695@burratino

Bug#660651: general: Problems with either samba and/or cups and printing from windows

[Christian Andretzky]

Package: general
Severity: important
Tags: squeeze

Sorry for using the general tag, but I've no idea which of the named packages 
is responsible
for the problem.
We have a samba server as domain controler and do all printings via cups.
The cups server is located on the same machine and printing fom linux was never 
a problem.
For various reasons we set the set the 'cups options' switch in /etc/smb.conf 
to empty, so that
cups handles the print jobs from the windows client completely (not only 
printqueue administration)
All things work as expected with one big exception.

I'm unable to set/maintain the samba server default settings for paper size. I 
can do other changes
in the server settings like comment or location for the printers with no 
problems (I can do this from
windows either via menu or via commandline with no problems.) The result is 
stored in the ntprinters.tdb
But if I try to change the default paper size for the printer, it only seems to 
work, but it is never stored
in the ntprinters.tdb.
The big problem for me is, why (either samba or cups) think, they have to set 
the default paper size to letter.
Nothing in our whole configuration (neither in cups, nor in samba and in 
windows also) has paper sizes of the type
'letter'.
For our users this is a really frustrating and time/paper intensive problem, 
because many of them work with remote desktops
and dynamically created printer forwardings from remote printers to local 
printers. Don't ask me why, sometimes such printer
forwardings have 'letter' as default paper size.
By necessity I tried to change ntprinters.tdb with a hex editor. It seems to 
work, but after some time my 'A4' setting were
overwritten with letter.

If you need more details, feel free to ask.

TIA for Your help.

Christian

-- System Information:
Debian Release: 6.0.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120220162250.6138.29357.report...@otto.fritz.box

Processed: cups: please support Brother HL-2130 laser printer out of the box

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 635157 Brother HL-2130 laser printer support
Bug #635157 [general] Package: NA - wishlist bug
Changed Bug title to 'Brother HL-2130 laser printer support' from 'Package: NA 
- wishlist bug'
> severity 635157 important
Bug #635157 [general] Brother HL-2130 laser printer support
Severity set to 'important' from 'normal'

> severity 618640 important
Bug #618640 [cups] CAPT (first-generation Canon winprinters --- e.g. LBP-1120) 
support
Severity set to 'important' from 'wishlist'

> reassign 635157 cups
Bug #635157 [general] Brother HL-2130 laser printer support
Bug reassigned from package 'general' to 'cups'.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
635157: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635157
618640: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618640
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.13188235357338.transcr...@bugs.debian.org

Bug#635157: cups: please support Brother HL-2130 laser printer out of the box

[Jonathan Nieder]

retitle 635157 Brother HL-2130 laser printer support
severity 635157 important
severity 618640 important
reassign 635157 cups
quit

Hi,

micha...@gmail.com wrote:

> Using Squeeze and wanted to install a new Brother HL-2130 laser printer.
> Noticed that the printer is not in the printer list from Debian.
>
> Went to Brother's Linux driver site
> (http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/download_prn.html#HL-2130),
> download the packages and everthing works well.
>
> Suggest to update Debian's driver list (since Brother is providing them) so
> that these working drivers can be added to benefit future users.

Thanks for a nice report.  I'm passing it on to the Debian CUPS
maintainers with this message.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111017035151.ga6...@elie.hsd1.il.comcast.net

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Russell Coker]

On Sun, 21 Aug 2011, Henrique de Moraes Holschuh  wrote:
> On Sat, 20 Aug 2011, Andreas Barth wrote:
> > * Henrique de Moraes Holschuh (h...@debian.org) [110820 14:39]:
> > > Yes.  And we can easily maintain a current one for Debian-packaged
> > > software, although the initial build of such a blacklist will take
> > > some work.
> > 
> > Actually, the existing interface net.ipv4.ip_local_port_range seems to
> > work quite well. And there are so many ports that for most servers it

# cat /proc/sys/net/ipv4/ip_local_port_range 
32768   61000

The above is from one of my systems.  This isn't used for RPC, presumably 
because they want the special <1024 port numbers that imply root ownership.

> No, it doesn't.  And we have at least one extremely important protocol that
> needs as many ports as we can give it (DNS).

Aug 21 11:42:48 ns named[2382]: using default UDP/IPv4 port range: [1024, 
65535]
Aug 21 11:42:48 ns named[2382]: using default UDP/IPv6 port range: [1024, 
65535]

BIND seems to use ports >1024 as well, again this is different from the 
typical RPC issues but does have the potential to cause problems (there are 
more than a few UDP ports >1024 in /etc/services).  Maybe BIND should be 
patched to use the same port reservation procedure as RPC.
 
> A blacklist is the way to go, and we already have it.  We just need to fill
> it, make it easier to extend (.d directory), tell people about it, and
> teach stuff other than SunRPC to use it when necessary.

Yes.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201108212238.05409.russ...@coker.com.au

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Henrique de Moraes Holschuh]

On Sat, 20 Aug 2011, Andreas Barth wrote:
> * Henrique de Moraes Holschuh (h...@debian.org) [110820 14:39]:
> > Yes.  And we can easily maintain a current one for Debian-packaged software,
> > although the initial build of such a blacklist will take some work.
> 
> Actually, the existing interface net.ipv4.ip_local_port_range seems to
> work quite well. And there are so many ports that for most servers it

No, it doesn't.  And we have at least one extremely important protocol that
needs as many ports as we can give it (DNS).

A blacklist is the way to go, and we already have it.  We just need to fill
it, make it easier to extend (.d directory), tell people about it, and teach
stuff other than SunRPC to use it when necessary.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110821035156.ga32...@khazad-dum.debian.net

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Ben Hutchings]

On Sat, 2011-08-20 at 16:17 +0200, Andreas Barth wrote:
> * Henrique de Moraes Holschuh (h...@debian.org) [110820 14:39]:
> > Yes.  And we can easily maintain a current one for Debian-packaged software,
> > although the initial build of such a blacklist will take some work.
> 
> Actually, the existing interface net.ipv4.ip_local_port_range seems to
> work quite well. And there are so many ports that for most servers it
> seems acceptable to limit the outgoing ports to only a tiny portion of
> port numbers (like 1/4th or so).

This has nothing to do with bindresvport().

Ben.



signature.asc
Description: This is a digitally signed message part

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Andreas Barth]

* Henrique de Moraes Holschuh (h...@debian.org) [110820 14:39]:
> Yes.  And we can easily maintain a current one for Debian-packaged software,
> although the initial build of such a blacklist will take some work.

Actually, the existing interface net.ipv4.ip_local_port_range seems to
work quite well. And there are so many ports that for most servers it
seems acceptable to limit the outgoing ports to only a tiny portion of
port numbers (like 1/4th or so).


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110820141725.gf15...@mails.so.argh.org

Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Ben Hutchings]

On Fri, 2011-08-19 at 14:36 +0100, Edward Allcutt wrote:
> On Thu, 18 Aug 2011, Ben Hutchings wrote:
> > On Thu, Aug 18, 2011 at 05:39:16PM +0200, Jan Möbius wrote:
> >> sometimes rpc.statd binds to port 631 udp which is used by cups. Therefore 
> >> cups is unable to bind to its port and no printers get discovered.
> >>
> >> Rebooting the system helps as rpc.statd uses another port afterwards.
> >
> > This is a fundamental problem of the bindresvport() function, and
> > not specific to rpc.statd.  Reassigning to general.
> 
> Sure, bindresvport is archaic, but workarounds already exist. In
> particular, Debian already adds /etc/bindresvport.blacklist and the
> default already contains port 631. Does the submitter have this
> file in place with the default contents?

Oh, I completely missed that.

> > The 'portreserve' package provides a kluge to avoid this, but it
> > requires other packages to register the ports that must be reserved.
> > It also won't work reliably, because insserv runs init scripts in
> > parallel and there is thus a race condition in the way services claim
> > their ports from the portreserve daemon.
> 
> That seems like a much worse kluge than the existing blacklist. Allowing
> packages to register reserved ports however seems a useful feature.
> 
> Reassign to eglibc as request for supporting /etc/bindresvport.blacklist.d ?
[...]

That seems like it would be necessary in the general case.  However, if
port 631 is already on the list then it has nothing to do with the
current bug report.

In fact, the problem seems to be that bindresvport() supports IPv4 only
and therefore libtirpc (the new SunRPC client library) does not use it
(for either IPv4 or IPv6).  glibc declares bindresvport6() for IPv6
addresses, but it doesn't appear to define it.  So it seems like we need
to:

1. Add bindresvport6() to glibc
2. Use glibc's bindresvport{,6}() in libtirpc
3. Add configuration directory for reserving more ports (not for this
bug)

Ben.



signature.asc
Description: This is a digitally signed message part

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Henrique de Moraes Holschuh]

On Sat, 20 Aug 2011, Russell Coker wrote:
> On Sat, 20 Aug 2011, Adam Borowski  wrote:
> > > It seems to me that the only problem is if you run multiple instances of
> > > a daemon on different ports and don't use /etc/bindresvport.blacklist,
> > > SE Linux, or some other method of telling bindresvport() to leave your
> > > port alone.  That wouldn't be an issue of sysadmin freedom but sysadmin
> > > ignorance (and I am one of the people who was ignorant of
> > > bindresvport.blacklist).
> > 
> > You can't blame "sysadmin ignorance".  I've just grepped through every
> > single man page in Debian (ok, amd64 main), and there is not a single
> 
> Ignorance means not knowing.  Sure there are probably some bug reports about 
> man pages due, but it's still something you or I could have found out.

...

> > No other daemon I know has this problem.  If I install daemon foo, I can
> > expect it to not touch any ports it hasn't been configured to use.  It's
> > just portmap/SunRPC that uses random scatter-shot that can trample on
> > something else.
> 
> Yes, SunRPC and anything that opens a port for callback.

Firewall port blocking can also cause such problems (denial of service).
While it is a different problem, it has the same roots as SunRPC binding to
undesired sockets: applications that use random sockets do not know whether
they're going to get a socket they're supposed to use.

Intelligent use of conntrack can help on single hosts (reducing the problem
to incoming callback connections), but most sites have border policies that
forbid any traffic to flow for some ports.  It causes minor issues for DNS
traffic (timeouts on a small fraction of the queries), for example.

> So it seems that some sort of blacklist is the only way to go.

Yes.  And we can easily maintain a current one for Debian-packaged software,
although the initial build of such a blacklist will take some work.

> The idea of a .d directory for blacklist files such that every package 
> installation that is likely to use some ports will automatically have a 
> reservation is a good one.  Of course there's still the corner case of trying 
> to install CUPS (or some other daemon) after a long-running RPC service has 
> grabbed the port.

That's not such a big problem, as it will be noticed immediately and causes
no surprise downtime of a service.

> Maybe we should default to having ports such as 631, 993, 995, 873, 587, 636, 
> 546, and 547 reserved at all times.  From a quick scan of /etc/services they 
> seem to be the most likely ports to be used in the 500-1024 range.

Looks good, and we can take extra ports as bug reports.  A mail to d-d-a and
a short article to planet.d.o and LWN may help to raise awareness of such
issues: although this _is_ a longstanding and _well known_ issue, the ways
to avoid the worst problems it can cause are _not_ well known.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110820123852.ga22...@khazad-dum.debian.net

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Russell Coker]

On Sat, 20 Aug 2011, Adam Borowski  wrote:
> > It seems to me that the only problem is if you run multiple instances of
> > a daemon on different ports and don't use /etc/bindresvport.blacklist,
> > SE Linux, or some other method of telling bindresvport() to leave your
> > port alone.  That wouldn't be an issue of sysadmin freedom but sysadmin
> > ignorance (and I am one of the people who was ignorant of
> > bindresvport.blacklist).
> 
> You can't blame "sysadmin ignorance".  I've just grepped through every
> single man page in Debian (ok, amd64 main), and there is not a single

Ignorance means not knowing.  Sure there are probably some bug reports about 
man pages due, but it's still something you or I could have found out.

apt-get source libc6

> No other daemon I know has this problem.  If I install daemon foo, I can
> expect it to not touch any ports it hasn't been configured to use.  It's
> just portmap/SunRPC that uses random scatter-shot that can trample on
> something else.

Yes, SunRPC and anything that opens a port for callback.

> So what about this: let's reserve a number of ports for portmap's exclusive
> usage[1].  There's like 900 unused assignments, so there's plenty of space
> than could be parcelled off.  SunRPC has long since degenerated from
> something with a general purpose to a peculiarity of NFS, so not many ports
> are needed.  Only under a pathological configuration one could exceed any
> reasonable static limit, and in that case bindresvport() would revert to
> the blacklist+scattershot.

The problem with this theory is the fact that the problem that was reported 
with CUPS only occurred after bindresvport() had used every port from 1023 
down to 631.  A casual scan of /etc/services reveals that there are no long 
contiguous ranges available without reserved ports.  If you start at the top 
the common ports pop3s and imaps could be reached quite quickly.

So it seems that some sort of blacklist is the only way to go.

The idea of a .d directory for blacklist files such that every package 
installation that is likely to use some ports will automatically have a 
reservation is a good one.  Of course there's still the corner case of trying 
to install CUPS (or some other daemon) after a long-running RPC service has 
grabbed the port.

Maybe we should default to having ports such as 631, 993, 995, 873, 587, 636, 
546, and 547 reserved at all times.  From a quick scan of /etc/services they 
seem to be the most likely ports to be used in the 500-1024 range.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201108202219.58742.russ...@coker.com.au

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Adam Borowski]

On Sat, Aug 20, 2011 at 12:02:12AM +1000, Russell Coker wrote:
> On Fri, 19 Aug 2011, Adam Borowski  wrote:
> > Not to mention bindresvport() removes the freedom of the sysadmin to bind
> > services to whatever ports she wishes.  Or, say, run multiple instances of
> > a service.
> 
> If you make your program use bindresvport() then it means that you don't care 
> what the port number is as long as it's in the reserved range.

Except that it should not get into ports used by something else.

> It seems to me that the only problem is if you run multiple instances of a 
> daemon on different ports and don't use /etc/bindresvport.blacklist, SE 
> Linux, 
> or some other method of telling bindresvport() to leave your port alone.  
> That 
> wouldn't be an issue of sysadmin freedom but sysadmin ignorance (and I am one 
> of the people who was ignorant of bindresvport.blacklist).

You can't blame "sysadmin ignorance".  I've just grepped through every
single man page in Debian (ok, amd64 main), and there is not a single
reference to /etc/bindresvport.blacklist.  In fact, even bindresvport() is
referenced only from its own manpage and from portreserve which is another
hack to work around this bug.  portreserve is neither recommended/suggested,
nor has any data that would allow it to work.

No other daemon I know has this problem.  If I install daemon foo, I can
expect it to not touch any ports it hasn't been configured to use.  It's
just portmap/SunRPC that uses random scatter-shot that can trample on
something else.

So what about this: let's reserve a number of ports for portmap's exclusive
usage[1].  There's like 900 unused assignments, so there's plenty of space
than could be parcelled off.  SunRPC has long since degenerated from
something with a general purpose to a peculiarity of NFS, so not many ports
are needed.  Only under a pathological configuration one could exceed any
reasonable static limit, and in that case bindresvport() would revert to the
blacklist+scattershot.



[1]. Unless the sysadmin knowingly takes them for some other purpose; no
different from, say, having sshd listen on port 443.

-- 
1KB // Yo momma uses IPv4!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110819175346.ga26...@angband.pl

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Russell Coker]

On Fri, 19 Aug 2011, Adam Borowski  wrote:
> Or use a whitelist rather than pretending that /etc/services was complete
> anywhere within the last 20 years.

AFAIK /etc/services has always been a complete list of ports assigned by IANA.  
If someone makes a port commonly used without getting IANA approval that's 
their problem/mistake.

> Not to mention bindresvport() removes the freedom of the sysadmin to bind
> services to whatever ports she wishes.  Or, say, run multiple instances of
> a service.

If you make your program use bindresvport() then it means that you don't care 
what the port number is as long as it's in the reserved range.  This generally 
means that it's a RPC service and the Portmapper will tell everyone which port 
to use or that there is some other channel to tell the clients which port to 
connect to (maybe a bit like the FTP two-port setup).

If you run multiple instances of a service using RPC then I guess you could 
use different names with the Portmapper.

It seems to me that the only problem is if you run multiple instances of a 
daemon on different ports and don't use /etc/bindresvport.blacklist, SE Linux, 
or some other method of telling bindresvport() to leave your port alone.  That 
wouldn't be an issue of sysadmin freedom but sysadmin ignorance (and I am one 
of the people who was ignorant of bindresvport.blacklist).

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110822.12738.russ...@coker.com.au

Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Edward Allcutt]

On Thu, 18 Aug 2011, Ben Hutchings wrote:

On Thu, Aug 18, 2011 at 05:39:16PM +0200, Jan Möbius wrote:

sometimes rpc.statd binds to port 631 udp which is used by cups. Therefore cups 
is unable to bind to its port and no printers get discovered.

Rebooting the system helps as rpc.statd uses another port afterwards.


This is a fundamental problem of the bindresvport() function, and
not specific to rpc.statd.  Reassigning to general.


Sure, bindresvport is archaic, but workarounds already exist. In
particular, Debian already adds /etc/bindresvport.blacklist and the
default already contains port 631. Does the submitter have this
file in place with the default contents?


The 'portreserve' package provides a kluge to avoid this, but it
requires other packages to register the ports that must be reserved.
It also won't work reliably, because insserv runs init scripts in
parallel and there is thus a race condition in the way services claim
their ports from the portreserve daemon.


That seems like a much worse kluge than the existing blacklist. Allowing
packages to register reserved ports however seems a useful feature.

Reassign to eglibc as request for supporting /etc/bindresvport.blacklist.d ?


A proper fix probably involves using systemd's socket-activation.
Yes, I said systemd - which presumably means we'll have to wait
another 5 years for this to be fixed.


Irrelevant. Promoting systemd for its side-effect as an amelioration for an
ureliable kluge is not a strong argument. ;) [0]

[0] Not intended as an argument against systemd either.

--
Edward Allcutt

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Adam Borowski]

On Fri, Aug 19, 2011 at 10:49:41AM +0200, Guus Sliepen wrote:
> On Fri, Aug 19, 2011 at 10:13:17AM +1000, Russell Coker wrote:
> > Systems running SE Linux tend not to have this problem.  In most cases the 
> > daemons which use RPC services are not permitted to bind to any of the 
> > ports 
> > that are reserved for services and therefore such a bind attempt fails with 
> > EPERM, glibc will just decrement the port number and try again when this 
> > happens.
> 
> We could also patch bindresvport() to skip all ports mentioned in
> /etc/services, to get similar behaviour as with SE Linux. Or patch the 
> programs
> using it to first try to bind to a static port that does not conflict with
> those in /etc/services, and if that fails fall back to bindresvport().

Or use a whitelist rather than pretending that /etc/services was complete
anywhere within the last 20 years.

Not to mention bindresvport() removes the freedom of the sysadmin to bind
services to whatever ports she wishes.  Or, say, run multiple instances of a
service.

-- 
1KB // Yo momma uses IPv4!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110819094712.ga24...@angband.pl

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Russell Coker]

On Fri, 19 Aug 2011, Guus Sliepen  wrote:
> We could also patch bindresvport() to skip all ports mentioned in
> /etc/services, to get similar behaviour as with SE Linux. Or patch the
> programs using it to first try to bind to a static port that does not
> conflict with those in /etc/services, and if that fails fall back to
> bindresvport().

That would be a viable option.  On my system there are 124 TCP ports listed 
with numbers <1024 (which seems to be the main problem area).  Losing 12% of 
the address space seems viable.

One thing to note when comparing this to SE Linux is that the SE Linux policy 
labels some ports that aren't in /etc/services but which are in relatively 
common use.  One example is port 24 for LMTP.  Also with SE Linux there is an 
easy way of adding new port labels and as the typical daemon won't be 
permitted to bind to an unlabeled port the sysadmin is compelled to do the 
correct thing.

Now one could patch bindresvport() to also check /etc/services.local or some 
other source of configuration information about which ports are likely to be 
used.  But getting the users to accept that will take some effort.

Of course most users just don't have enough RPC traffic to generate the 
problem.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201108191920.49612.russ...@coker.com.au

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Guus Sliepen]

On Fri, Aug 19, 2011 at 10:13:17AM +1000, Russell Coker wrote:

> Systems running SE Linux tend not to have this problem.  In most cases the 
> daemons which use RPC services are not permitted to bind to any of the ports 
> that are reserved for services and therefore such a bind attempt fails with 
> EPERM, glibc will just decrement the port number and try again when this 
> happens.
> 
> http://etbe.coker.com.au/2007/11/06/squid-and-se-linux/
> 
> I mentioned this in the above blog post, I think it was in about 2002 that I 
> wrote the policy to do this.

We could also patch bindresvport() to skip all ports mentioned in
/etc/services, to get similar behaviour as with SE Linux. Or patch the programs
using it to first try to bind to a static port that does not conflict with
those in /etc/services, and if that fails fall back to bindresvport().

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Russell Coker]

Systems running SE Linux tend not to have this problem.  In most cases the 
daemons which use RPC services are not permitted to bind to any of the ports 
that are reserved for services and therefore such a bind attempt fails with 
EPERM, glibc will just decrement the port number and try again when this 
happens.

http://etbe.coker.com.au/2007/11/06/squid-and-se-linux/

I mentioned this in the above blog post, I think it was in about 2002 that I 
wrote the policy to do this.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201108191013.17845.russ...@coker.com.au

Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Ben Hutchings]

On Thu, 2011-08-18 at 19:03 +, brian m. carlson wrote:
> On Thu, Aug 18, 2011 at 05:41:22PM +0100, Ben Hutchings wrote:
> > On Thu, Aug 18, 2011 at 05:39:16PM +0200, Jan Möbius wrote:
> > > sometimes rpc.statd binds to port 631 udp which is used by cups. 
> > > Therefore cups is unable to bind to its port and no printers get 
> > > discovered.
> > > 
> > > Rebooting the system helps as rpc.statd uses another port afterwards.
> >  
> > This is a fundamental problem of the bindresvport() function, and
> > not specific to rpc.statd.  Reassigning to general.
> 
> Actually, according to the manpage:
> 
>   Unlike some bindresvport() implementations, the glibc implementation
>   ignores any value that the caller supplies in sin->sin_port.
> 
> Fixing this might be a useful way around the problem.  I'd code up a
> patch, but eglibc won't take it without copyright assignment.

You can't fix that, because it can't rely on existing callers to
initialise the field at all.

Ben.



signature.asc
Description: This is a digitally signed message part

Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[brian m. carlson]

On Thu, Aug 18, 2011 at 05:41:22PM +0100, Ben Hutchings wrote:
> On Thu, Aug 18, 2011 at 05:39:16PM +0200, Jan Möbius wrote:
> > sometimes rpc.statd binds to port 631 udp which is used by cups. Therefore 
> > cups is unable to bind to its port and no printers get discovered.
> > 
> > Rebooting the system helps as rpc.statd uses another port afterwards.
>  
> This is a fundamental problem of the bindresvport() function, and
> not specific to rpc.statd.  Reassigning to general.

Actually, according to the manpage:

  Unlike some bindresvport() implementations, the glibc implementation
  ignores any value that the caller supplies in sin->sin_port.

Fixing this might be a useful way around the problem.  I'd code up a
patch, but eglibc won't take it without copyright assignment.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup

[Ben Hutchings]

On Thu, Aug 18, 2011 at 05:39:16PM +0200, Jan Möbius wrote:
> Package: nfs-common
> Version: 1:1.2.4-1
> Severity: normal
> 
> Hi,
> 
> sometimes rpc.statd binds to port 631 udp which is used by cups. Therefore 
> cups is unable to bind to its port and no printers get discovered.
> 
> Rebooting the system helps as rpc.statd uses another port afterwards.
 
This is a fundamental problem of the bindresvport() function, and
not specific to rpc.statd.  Reassigning to general.

The 'portreserve' package provides a kluge to avoid this, but it
requires other packages to register the ports that must be reserved.
It also won't work reliably, because insserv runs init scripts in
parallel and there is thus a race condition in the way services claim
their ports from the portreserve daemon.

A proper fix probably involves using systemd's socket-activation.
Yes, I said systemd - which presumably means we'll have to wait
another 5 years for this to be fixed.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110818164122.gr29...@decadent.org.uk

Re: Packaging cups with cdbs

[Laszlo Papp]

Hi,

> override_dh_installinit:
>        $stuff_to_manually_install_to_etc_init_apps

I am just about to make it this way for now. One question here: can I
override only the file installation path, I am interested in, instead
of doing manually for all the 100(0)+ files manually that the package
is supposed to contain ?

Thank you in advance!

Best Regards,
Laszlo Papp


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktinlrg-ugm0awjuvoze0y+3...@mail.gmail.com

Re: Packaging cups with cdbs

[Laszlo Papp]

Hi Steve,

On Tue, May 24, 2011 at 8:11 PM, Steve Langasek  wrote:
> Hi Laszlo,
>
> On Tue, May 24, 2011 at 07:08:22PM +0300, Laszlo Papp wrote:
>> I have tried to use the debian/rules that you can see below. My
>> concern is that I would like to make a test package (for maemo, but
>> actually should also work for debian) in case of using upstart for
>> init functionalities.
>> The problem is that if I try to use a debian/cups.upstart file for
>> that purpose, it seems to be hard coded. It installs the upstart job
>> into the /etc/init/ and I cannot customize that path, for instance to
>> /etc/init/apps/ as I would like to have it. I tried to set the
>> "--onlyscripts" option in order to hope that it does not generate any
>> init script/job inside the package and I could just make a workaround
>> by using postinst.
>
> It installs it to /etc/init because this is the upstream path for upstart
> jobs.  There is no dh_installinit implementation that knows about this
> maemo-specific /etc/init/apps/ path.

It is actually not maemo specific feature, it is more like a general
customization. (which seems to be missing from the dh_installinit
implementation right now).

>From the man page of that:
   -o, --onlyscripts
   Only modify postinst/postrm/prerm scripts, do not actually
install any init script, default files, or upstart job.  May be useful
if the init script or upstart job is shipped and/or installed by
upstream in a
   way that doesn't make it easy to let dh_installinit find it.

   If no upstart job file is installed in the target directory
when dh_installinit --onlyscripts is called, this program will assume
that an init script is being installed and not provide the
compatibility symlinks
   or upstart dependencies.

I thought it should eliminate the installation and I could do it
"manually" from the postinst script.

> You could patch dh_installinit to do this in a maemo context, or you could
> pass DEB_DH_INSTALLINIT_ARGS=--name=nonexistent to force dh_installinit to
> only look for debian/cups.nonexistent.upstart.

I have also tried this option, but I still get the /etc/init.d/cups
file somehow. :o I am not sure what I am doing wrong.
I hoped either this option you mentioned, or the "-o" should help to
not install anything, not /etc/init.d/cups either. It might well be, I
have just made some dumb mistake and it should work however. Anyway,
it would be nice if the installation path could be customizable in
case of the cdbs usage.

If nothing works, I think it is time to start thinking of the
debhelper usage, but I do still hope I did something wrong or I missed
something.

Thank you for your answer !

Best Regards,
Laszlo Papp


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTinF=QDhE_vUSLOhZLoaR=m=vt1...@mail.gmail.com

Re: Packaging cups with cdbs

[Steve Langasek]

Hi Laszlo,

On Tue, May 24, 2011 at 07:08:22PM +0300, Laszlo Papp wrote:
> I have tried to use the debian/rules that you can see below. My
> concern is that I would like to make a test package (for maemo, but
> actually should also work for debian) in case of using upstart for
> init functionalities.
> The problem is that if I try to use a debian/cups.upstart file for
> that purpose, it seems to be hard coded. It installs the upstart job
> into the /etc/init/ and I cannot customize that path, for instance to
> /etc/init/apps/ as I would like to have it. I tried to set the
> "--onlyscripts" option in order to hope that it does not generate any
> init script/job inside the package and I could just make a workaround
> by using postinst.

It installs it to /etc/init because this is the upstream path for upstart
jobs.  There is no dh_installinit implementation that knows about this
maemo-specific /etc/init/apps/ path.

You could patch dh_installinit to do this in a maemo context, or you could
pass DEB_DH_INSTALLINIT_ARGS=--name=nonexistent to force dh_installinit to
only look for debian/cups.nonexistent.upstart.

> Other option is to change the whole packaging to "dh" usage. However
> if I could just bypass the systemv init script and/or hard coded
> upstart job installation, it would be easier for me because I am not a
> packager. =)

With dh the solution is certainly more easily discoverable and less
convoluted; you can override dh_installinit with a simple rule:

override_dh_installinit:
$stuff_to_manually_install_to_etc_init_apps


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Packaging cups with cdbs

[Jonas Smedegaard]

Hi Laszlo,

On 11-05-24 at 07:08pm, Laszlo Papp wrote:
> I have tried to use the debian/rules that you can see below. My 
> concern is that I would like to make a test package (for maemo, but 
> actually should also work for debian) in case of using upstart for 
> init functionalities.
> The problem is that if I try to use a debian/cups.upstart file for
> that purpose, it seems to be hard coded. It installs the upstart job
> into the /etc/init/ and I cannot customize that path, for instance to
> /etc/init/apps/ as I would like to have it. I tried to set the
> "--onlyscripts" option in order to hope that it does not generate any
> init script/job inside the package and I could just make a workaround
> by using postinst.
> 
> Other option is to change the whole packaging to "dh" usage. However
> if I could just bypass the systemv init script and/or hard coded
> upstart job installation, it would be easier for me because I am not a
> packager. =)


Not quite sure what is the central issue of yours here.


CDBS is *not* a tool for beginners to do packaging blind-folded!

I believe (and hope) same is true for short-form dh.


CDBS use (long-form) debhelper tools.  If you experience a sensible 
use-case impossible or awkward to express using CDBS, then please do 
contact us at the [CDBS mailinglist] or file a bugreport against it.

[CDBS mailinglist]: 
http://lists.alioth.debian.org/mailman/listinfo/build-common-hackers


If you know what you are doing but believe there is an issue more 
enerally with how Debian (and debhelper and CDBS) deals with upstart, 
then please isolate the problematic long-form debhelper command instead 
of convoluting in some more specific packaging style.

If you need help packaging in general, then perhaps debian-users or 
debian-mentors are more appropriate than this list.


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Packaging cups with cdbs

[Laszlo Papp]

Hi,

I have tried to use the debian/rules that you can see below. My
concern is that I would like to make a test package (for maemo, but
actually should also work for debian) in case of using upstart for
init functionalities.
The problem is that if I try to use a debian/cups.upstart file for
that purpose, it seems to be hard coded. It installs the upstart job
into the /etc/init/ and I cannot customize that path, for instance to
/etc/init/apps/ as I would like to have it. I tried to set the
"--onlyscripts" option in order to hope that it does not generate any
init script/job inside the package and I could just make a workaround
by using postinst.

Other option is to change the whole packaging to "dh" usage. However
if I could just bypass the systemv init script and/or hard coded
upstart job installation, it would be easier for me because I am not a
packager. =)

I am not sure what I am doing wrong, so any help is welcome and thank
you in advance! :)

Best Regards,
Laszlo Papp



#!/usr/bin/make -f
export DH_VERBOSE=1

export LIBTOOL=

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk

PACKAGE_TARGETS :=  $(foreach pkg,$(DEB_ALL_PACKAGES),binary/$(pkg))
$(PACKAGE_TARGETS)::
[ ! -f debian/$(notdir $@).aegis ] || aegis-deb-add -control
debian/$(notdir $@)/DEBIAN/control .. debian/$(notdir $@).aegis=_aegis

DEB_DH_INSTALLINIT_ARGS := --onlyscripts
DEB_MAKE_INSTALL_TARGET := install BUILDROOT=$(DEB_DESTDIR)


Best Regards,
Laszlo Papp


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktin_re4ne9snzonmubr1-v1smou...@mail.gmail.com

Bug#602389: ITP: pyppd -- CUPS PostScript Printer Driver's compressor and generator

[Didier Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier Raboud 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  Package name: pyppd
  Version : 0.4.9
  Upstream Author : Vitor Baptista 
  URL : http://pypi.python.org/pypi/pyppd
  License : GPLv3
  Programming Lang: Python
  Description : CUPS PostScript Printer Driver's compressor and generator

pyppd is a CUPS PPD generator. It holds an compressed archive of PPDs, which
can be listed and retrieved only when needed by CUPS, saving disk space

This package will be maintained under the "Debian Printing Group" umbrella.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iJwEAQECAAYFAkzSqiQACgkQKA1Vt+jBwDiJ2AQApx+H6H6vRHyg7xui32new4PD
cMg/6o3xRH7sl09fcjKarhpIrXqmB8lXCH+fgU1znQtDW/ph6nw8gTRvru6+xoLc
lXfkCBOlkP3xgr589synVmPrd/xYiShA4WXrfDaqF6EJHnG6WF+iNGjmM7roQraO
BTAr52DCs2irT+a0CKs=
=eaVc
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101104124224.26294.76752.report...@tamino

Re: Printing Long Edge (Standard) with HP DeskJet 990C - CUPS+Gutenprint v5.0.2 does not work

[Camaleón]

On Sat, 18 Sep 2010 12:43:50 +0200, Merciadri Luca wrote:

> Camaleón wrote:

>> The command above lacks the file/document to print? :-?
>>   
> Well, this is what Adobe indicates me as the sent command. I assume it
> appends the name of the stuff to print!

Oh, okay, you didn't say you were printing from Acrobat Reader :-)

Can you test double side printing from Evince? Just to discard a problem 
with Adobe program.

>>> where `Deskjet' is the name of the printer for CUPS.
>>>
>>> Any idea?
>>> 
>>> 
>> You can first check that duplex printing is an available option for
>> your driver:
>>
>> ***
>> lpoptions -p printername -l | grep -i duplex ***
>>   
> ==
> 
> # lpoptions -p printername -l | grep -i duplex
> 
> Duplex/2-Sided Printing: *None DuplexNoTumble DuplexTumble 

Rigth.

>> If it is listed there and you get no output when calling "lpr", take a
>> look into CUPS logs (/var/log/cups/*), maybe there is any error there

> Calling `lpr' gives simply nothing, but a blinking cursor. I checked log
> files, but there seems to be nothing indicated, be it in error_log*,
> page_log*, access_log*.

Well, of course, you have to type the whole command:

***
lpr -P Deskjet -o Resolution=300dpi -o PageSize=Letter -o Duplex=DuplexNoTumble 
/path/to/pdffile.pdf
***

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pan.2010.09.18.11.17...@gmail.com

Re: [Pkg-cups-devel] Bug#582441: /var/spool/cups-pdf/ANONYMOUS is inappropriately owned by nobody:nogroup

[Roger Leigh]

On 22/05/2010 12:14, Martin-Éric Racine wrote:

On Thu, May 20, 2010 at 10:26 PM, Roger Leigh  wrote:

Package: cups-pdf
Version: 2.5.0-14
Severity: normal

% ls -ld /var/spool/cups-pdf/ANONYMOUS
drwxrwxrwt 2 nobody nogroup 4096 Jan 27  2009 /var/spool/cups-pdf/ANONYMOUS

This directory is world-writable with the sticky-bit set, which allows
any user to create files and directories in this location.  However, the
ownership is not appropriate; compare with /tmp:

% ls -ld /tmp
drwxrwxrwt 13 root root 300 May 20 20:20 /tmp

The ownership by nobody:nogroup gives processes run under this
UID and/or GID additional privileges to delete content under this
location.  Given that they are intended to be a restricted-privilege
user/group, this is not appropriate.  Ownership by root:root is
perfectly acceptable here (if you're creating files in here owned
by nobody:nogroup that will still work fine).


If I recall correctly, it was suggested that I'd make this directory
owned by nobody:nogroup to give it the lowest possible priority,
because of the risky way that Samba accesses this spool when offering
login-free guest printer access.  I welcome debian-devel's input on
whether this statement is correct or not.


This probably needs some clarification from the Samba maintainers, but I 
don't at first glance see why it's any safer than root:root; from the 
way I see it, it's actually less secure due to the unwarranted extra 
authority you're granting the nobody user.


If Samba is running with an EUID/EGID of root/root, it has the ability 
to read/write in that location under any circumstances.  Given that 
other has rwx/sticky, any user can read/write here whatever their 
EUID/EGID, including Samba.  So I'm not sure what's different between 
root:root and nobody:nogroup from the Samba POV: it has equal rights 
under both circumstances.


From the system POV, if owned by root:root with 01777 perms, any user 
may create and delete *their own* files.  Only root may delete files 
owned by non-root users (since they own the directory).  Likewise if 
owned by nobody:nogroup, any user may create and delete their own files, 
but in this case any file may be deleted *by user nobody*.


Given that user nobody is a minimum-privilege account, you've actually 
escalated the privileges nobody has by creating a directory owned by 
nobody--the nobody user, and any daemons running as nobody, now have the 
power to delete other users' files under this location.  Clearly, this 
is no longer "minimum privilege".  i.e. nobody is kept having minimal 
privs by not creating files/directories owned by nobody which can allow 
situations like this to arise.


Hopefully you can see where I'm coming from with this, and appreciate 
the potential for abuse and the security considerations related to that; 
I'd be interested to know more about the rationale from the Samba side.



Regards,
Roger


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf844cb.20...@codelibre.net

Re: [Pkg-cups-devel] Bug#582441: /var/spool/cups-pdf/ANONYMOUS is inappropriately owned by nobody:nogroup

[Martin-Éric Racine]

On Thu, May 20, 2010 at 10:26 PM, Roger Leigh  wrote:
> Package: cups-pdf
> Version: 2.5.0-14
> Severity: normal
>
> % ls -ld /var/spool/cups-pdf/ANONYMOUS
> drwxrwxrwt 2 nobody nogroup 4096 Jan 27  2009 /var/spool/cups-pdf/ANONYMOUS
>
> This directory is world-writable with the sticky-bit set, which allows
> any user to create files and directories in this location.  However, the
> ownership is not appropriate; compare with /tmp:
>
> % ls -ld /tmp
> drwxrwxrwt 13 root root 300 May 20 20:20 /tmp
>
> The ownership by nobody:nogroup gives processes run under this
> UID and/or GID additional privileges to delete content under this
> location.  Given that they are intended to be a restricted-privilege
> user/group, this is not appropriate.  Ownership by root:root is
> perfectly acceptable here (if you're creating files in here owned
> by nobody:nogroup that will still work fine).

If I recall correctly, it was suggested that I'd make this directory
owned by nobody:nogroup to give it the lowest possible priority,
because of the risky way that Samba accesses this spool when offering
login-free guest printer access.  I welcome debian-devel's input on
whether this statement is correct or not.

Martin-Éric


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimv2ezrwr6norhsxdexncxzw5thvwoidbyvn...@mail.gmail.com

Processed: Re: Processed: Re: Bug#519837: Debian 5.0 - Cups -Canon Pixma iP3500 installation printing failure

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 519837 cups
Bug#519837: Debian 5.0 - Cups -Canon Pixma iP3500 installation printing failure
Bug reassigned from package `general' to `cups'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#519837: Debian 5.0 - Cups -Canon Pixma iP3500 installation printing failure

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 519837 general
Bug#519837: Debian 5.0 - Cups -Canon Pixma iP3500 installation printing failure
Warning: Unknown package 'debian'
Bug reassigned from package `debian' to `general'.

> --
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#482994: marked as done (general: gnome applications fails to print with cups on remote printer, authorization request not fullfilled.)

[Debian Bug Tracking System]

Your message dated Mon, 8 Sep 2008 17:28:55 +0200
with message-id <[EMAIL PROTECTED]>
and subject line closing after (more than) a week, as announced
has caused the Debian Bug report #482994,
regarding general: gnome applications fails to print with cups on remote 
printer, authorization request not fullfilled.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
482994: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482994
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: general
Severity: important



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm (armv5tel)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-ixp4xx
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Gnome applications like gedit evolution etc. fail to print on remote printer 
using cups due to authentication problems.


--- End Message ---
--- Begin Message ---
feel free to reopen


pgpGDcoEbutBB.pgp
Description: PGP signature
--- End Message ---

Re: "cupsys" renamed to "cups", please adjust your (build-)depends

[Jörg Sommer]

Hallo Bernhard,

Bernhard R. Link <[EMAIL PROTECTED]> wrote:
> * Martin Pitt <[EMAIL PROTECTED]> [080612 18:04]:
>> after many years of calling our CUPS package "cupsys" it has finally
>> be renamed to the proper upstream name "cups", including init scripts,
>> library packages, etc. This makes us compatible again with all the
>> upstream documentation out there, unbreaks the LSB printer driver
>> packages from openprinting.org, reduces confusion with users, and
>> finally makes the libraries Policy compliant (SONAME == package name).
>> Please see http://bugs.debian.org/482296 for details.
>
> How about using this transition to move some binaries between package
> boundaries? Especially having some programs with generic names in -client and
> some in -bsd seem to be a problem for some users (like #405827).
>
> I do not think having lp and lpr in different packages can cause any
> good (and the same for lprm and cancel and so on).

But lpr and lprm aren't commands mentioned in the POSIX standard. The
POSIX standard knows only the lp command.

Schöne Grüße, Jörg.
-- 
> Definiere ‚Demokratie‘ …
… eine Mehrheit beweist einer Minderheit, dass Widerstand zwecklos ist.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "cupsys" renamed to "cups", please adjust your (build-)depends

[Martin Pitt]

Hi Bernhard,

Bernhard R. Link [2008-06-12 18:23 +0200]:
> How about using this transition to move some binaries between package
> boundaries? Especially having some programs with generic names in -client and
> some in -bsd seem to be a problem for some users (like #405827).

I do not agree to this bug report. CUPS upstream's native tools have
sysv names, so they should be in cups-client, and not a package which
says "please do not install me". With those you can access all the
features of cups (especially with lpadmin and lpinfo). Also, it
already renames the very generic 'enable' and 'disable' commands to
'cupsenable' and 'cupsdisable'. But we cannot really do that for all
the other frontend programs (lp, etc.), since their names have a long
history and are just expected to be named like this. Renaming them now
would break a lot.

You can install a cups server without the client programs, and thus
only use IPP for printing (as done by GNOME/KDE/gtkprint, etc.).

So isn't the real problem that lprng isn't split into a client and
server side package? If it was, you could mix them by installing
cups and lprng-client, or the other way around (no idea whether this
actually makes sense and would work, and whether the wire protocols
are compatible).

> I do not think having lp and lpr in different packages can cause any
> good (and the same for lprm and cancel and so on).

The cups-bsd package should really stay split, too, IMHO. They are a
compatibility layer, and you do not need to have them installed in
order to use cups for printing on the client side. Also, from your
POV, merging -bsd into -client would only aggravate the problem?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Re: "cupsys" renamed to "cups", please adjust your (build-)depends

[brian m. carlson]

On Fri, Jun 13, 2008 at 03:07:02PM +0200, Bernhard R. Link wrote:

* Steve Greenland <[EMAIL PROTECTED]> [080612 19:01]:

Isn't the whole point of having cups-bsd etc. to provide replacement
commands that are compatible with older tools?


Well, from my view lpr, lprm, lpc, lpq are the new tools while lp,
cancel, lpstat are the compatibility links for tools coming from sysv.


My experience over eight years of using GNU/Linux distributions is that
programs that don't have native support for a printing implementation
tend to use lpr and friends (the BSD tools) rather than the SysV tools.
I recall seeing lpr as a printing command numerous times, and lp only
once[0].  It appears that at least in GNU/Linux history, the BSD tools
are more prevalent.

Of course, many programs nowadays support CUPS natively through their
desktop environments, so this becomes almost moot.

[0] My first thought on seeing lp was that someone had made a typo.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: "cupsys" renamed to "cups", please adjust your (build-)depends

[Emilio Pozuelo Monfort]

Martin Pitt wrote:
> Please change your packages accordingly. I'll start filing bugs in a
> few months, when the bulk of packages is hopefully fixed already.
> 
> Thank you in advance!
> 
> Martin
> 
> 
> List of affected (binary) packages, per maintainer:
> 

> Debian GNOME Maintainers <[EMAIL PROTECTED]>
>gnome-cups-manager

It doesn't build-depends on *cupsys*, so I guess it's picked up by
shlibs:Depends (it build-depends on libgnomecups1.0-dev which picks
libcupsys2-dev), so a rebuild when that's fixed should do the trick.

>gtk+2.0 (U)
>libgnomecups (U)
>libgnomeprint (U)

All fixed in svn.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: "cupsys" renamed to "cups", please adjust your (build-)depends

[Bernhard R. Link]

* Steve Greenland <[EMAIL PROTECTED]> [080612 19:01]:
> On 12-Jun-08, 11:23 (CDT), "Bernhard R. Link" <[EMAIL PROTECTED]> wrote: 
> > How about using this transition to move some binaries between package
> > boundaries? Especially having some programs with generic names in -client 
> > and
> > some in -bsd seem to be a problem for some users (like #405827).
> >
> > I do not think having lp and lpr in different packages can cause any
> > good (and the same for lprm and cancel and so on).
>
> Isn't the whole point of having cups-bsd etc. to provide replacement
> commands that are compatible with older tools?

Well, from my view lpr, lprm, lpc, lpq are the new tools while lp,
cancel, lpstat are the compatibility links for tools coming from sysv.

Having those sysv ones in the -clients package together with the native
cups clients, while the bsd ones are in -bsd is a bit strange.

I personaly to not care, because I just have not cups installed. But for
cups users it might be intresting to have -clients split.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "cupsys" renamed to "cups", please adjust your (build-)depends

[Steve Greenland]

On 12-Jun-08, 11:23 (CDT), "Bernhard R. Link" <[EMAIL PROTECTED]> wrote: 
> How about using this transition to move some binaries between package
> boundaries? Especially having some programs with generic names in -client and
> some in -bsd seem to be a problem for some users (like #405827).
> 
> I do not think having lp and lpr in different packages can cause any
> good (and the same for lprm and cancel and so on).


Isn't the whole point of having cups-bsd etc. to provide replacement
commands that are compatible with older tools?

Steve


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "cupsys" renamed to "cups", please adjust your (build-)depends

[Bernhard R. Link]

* Martin Pitt <[EMAIL PROTECTED]> [080612 18:04]:
> after many years of calling our CUPS package "cupsys" it has finally
> be renamed to the proper upstream name "cups", including init scripts,
> library packages, etc. This makes us compatible again with all the
> upstream documentation out there, unbreaks the LSB printer driver
> packages from openprinting.org, reduces confusion with users, and
> finally makes the libraries Policy compliant (SONAME == package name).
> Please see http://bugs.debian.org/482296 for details.

How about using this transition to move some binaries between package
boundaries? Especially having some programs with generic names in -client and
some in -bsd seem to be a problem for some users (like #405827).

I do not think having lp and lpr in different packages can cause any
good (and the same for lprm and cancel and so on).

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

"cupsys" renamed to "cups", please adjust your (build-)depends

[Martin Pitt]

Hello all,

after many years of calling our CUPS package "cupsys" it has finally
be renamed to the proper upstream name "cups", including init scripts,
library packages, etc. This makes us compatible again with all the
upstream documentation out there, unbreaks the LSB printer driver
packages from openprinting.org, reduces confusion with users, and
finally makes the libraries Policy compliant (SONAME == package name).
Please see http://bugs.debian.org/482296 for details.

To faciliate smooth upgrades and not immediately break everything,
cups builds transitional packages with the old names, and will do so
at least until after Lenny's release (this was cleared with the
release team). However, it would be nice if all the existing build and
binary dependencies would be changed to the new names:

  cupsys -> cups
  cupsys-client  -> cups-client
  cupsys-bsd -> cups-bsd
  cupsys-common  -> cups-common
  libcupsys2-dev -> libcups2-dev
  libcupsys2 -> libcups2

Please change your packages accordingly. I'll start filing bugs in a
few months, when the bulk of packages is hopefully fixed already.

Thank you in advance!

Martin


List of affected (binary) packages, per maintainer:

Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
   rezound

Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>
   ghostscript

J.H.M. Dassen (Ray) <[EMAIL PROTECTED]>
   gnome-cups-manager (U)

Sebastien Bacher <[EMAIL PROTECTED]>
   gnome-cups-manager (U)
   gtk+2.0

Armin Berres <[EMAIL PROTECTED]>
   kde4libs (U)
   kdelibs (U)

Fathi Boudra <[EMAIL PROTECTED]>
   kde4libs (U)
   kdelibs (U)
   qt-x11-free (U)

Marc 'HE' Brockschmidt <[EMAIL PROTECTED]>
   gnome-cups-manager (U)

Ross Burton <[EMAIL PROTECTED]>
   gnome-cups-manager (U)
   libgnomecups

Marco Cabizza <[EMAIL PROTECTED]>
   gnome-cups-manager (U)

Hubert Chathi <[EMAIL PROTECTED]>
   gnustep-gui (U)

Adam Conrad <[EMAIL PROTECTED]>
   samba (U)

Debian Bluetooth Maintainers <[EMAIL PROTECTED]>
   bluez-utils

Debian CUPS Maintainers <[EMAIL PROTECTED]>
   cups-pdf

Debian GNOME Maintainers <[EMAIL PROTECTED]>
   gnome-cups-manager
   gtk+2.0 (U)
   libgnomecups (U)
   libgnomeprint (U)

Debian GNUstep maintainers <[EMAIL PROTECTED]>
   gnustep-gui

Debian HPIJS and HPLIP maintainers <[EMAIL PROTECTED]>
   cupsddk
   hplip

Debian Perl Group <[EMAIL PROTECTED]>
   libnet-cups-perl

Debian Printing Group <[EMAIL PROTECTED]>
   gutenprint

Debian Qt/KDE Maintainers <[EMAIL PROTECTED]>
   kde4libs
   kdelibs
   qt-x11-free

Debian Samba Maintainers <[EMAIL PROTECTED]>
   samba

Debian Wine Party <[EMAIL PROTECTED]>
   wine

Debian Xfce Maintainers <[EMAIL PROTECTED]>
   xfprint4

Sebastian Dröge <[EMAIL PROTECTED]>
   gtk+2.0 (U)
   libgnomeprint (U)

Edd Dumbill <[EMAIL PROTECTED]>
   bluez-utils (U)

Zak B. Elep <[EMAIL PROTECTED]>
   gtklp

Martín Ferrari <[EMAIL PROTECTED]>
   libnet-cups-perl (U)

Gustavo Franco <[EMAIL PROTECTED]>
   gnome-cups-manager (U)

Ionut Georgescu <[EMAIL PROTECTED]>
   grace6

Oystein Gisnas <[EMAIL PROTECTED]>
   gnome-cups-manager (U)

Filippo Giunchedi <[EMAIL PROTECTED]>
   bluez-utils (U)

Dafydd Harries <[EMAIL PROTECTED]>
   gnome-cups-manager (U)

gregor herrmann <[EMAIL PROTECTED]>
   libnet-cups-perl (U)

Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
   hplip (U)
   xpp

Simon Huggins <[EMAIL PROTECTED]>
   xfprint4 (U)

Mario Iseli <[EMAIL PROTECTED]>
   bluez-utils (U)

Damyan Ivanov <[EMAIL PROTECTED]>
   libnet-cups-perl (U)

Ove Kaaven <[EMAIL PROTECTED]>
   wine (U)

Till Kamppeter <[EMAIL PROTECTED]>
   cupsddk (U)

Noèl Köthe <[EMAIL PROTECTED]>
   samba (U)

Torsten Landschoff <[EMAIL PROTECTED]>
   fox1.4
   fox1.6
   ghostscript (U)
   hplip (U)

Steve Langasek <[EMAIL PROTECTED]>
   samba (U)

Andrew Lau <[EMAIL PROTECTED]>
   gnome-cups-manager (U)

Chris Lawrence <[EMAIL PROTECTED]>
   foomatic-gui
   lsb

Roger Leigh <[EMAIL PROTECTED]>
   gutenprint (U)

Arthur Loiret <[EMAIL PROTECTED]>
   wine (U)

Ana Beatriz Guerrero Lopez <[EMAIL PROTECTED]>
   kde4libs (U)
   kdelibs (U)
   qt-x11-free (U)

Jordi Mallach <[EMAIL PROTECTED]>
   gnome-cups-manager (U)

Rene Mayorga <[EMAIL PROTECTED]>
   libnet-cups-perl (U)

Loic Minier <[EMAIL PROTECTED]>
   gnome-cups-manager (U)
   gtk+2.0 (U)
   libgnomecups (U)
   libgnomeprint (U)

Oleksandr Moskalenko <[EMAIL PROTECTED]>
   scribus
   scribus-ng

Josselin Mouette <[EMAIL PROTECTED]>
   gnome-cups-manager (U)

Eloy A. Paris <[EMAIL PROTECTED]>
   samba (U)

Guilherme de S. Pastore <[EMAIL PROTECTED]>
   gnome-cups-manager (U)

Yves-Alexis Perez <[EMAIL PROTECTED]>
   epdfview

Bug#479397: RFA: gutenprint -- printer drivers for CUPS

[Roger Leigh]

Package: wnpp
Severity: normal

I request an adopter for the gutenprint package.  I no longer have time
to maintain it, and it deserves to be maintained to a better standard
than I can currently manage.  Not only am I short of time, but I no
longer have an inkjet printer for testing and bug fixing.

Gutenprint is used for printing on EPSON, Canon, Olympus, and some HP
and other makes of printer via CUPS, LPRng etc..  It is an important
part of the printing infrastructure in Debian.  There is a new upstream
release due out in the next week or so (5.2.0).  Upstream is very
friendly.  The package isn't too complex, though there are quite a few
binary packages.  What it really needs is proper testing and bugs being
pushed upstream.

I'll continue to be available to co-maintain if you like, and I do know
a fair bit about its internals (I am, albeit currently inactive, an
upstream developer as well).  I will also be orphaning ijs, one of
gutenprint's build dependencies.


Thanks,
Roger


The package description is:
 This package includes a CUPS driver based on Gutenprint.
 .
 The CUPS drivers contain all of the files needed to support
 photo-quality printing on any printer supported by Gutenprint.  You
 can find out more about the Common UNIX Printing System ("CUPS"), an
 IPP-based printing system for UNIX/Linux, at:
 .
   http://www.cups.org
 .
 This is Gutenprint version 5.0.2, a stable release
 in the 5.0 series.
 .
 Gutenprint is the print facility for the GIMP, and in addition a
 suite of drivers that may be used with common UNIX spooling systems
 using GhostScript or CUPS.  These drivers provide printing quality
 for UNIX/Linux on a par with proprietary vendor-supplied drivers in
 many cases, and can be used for many of the most demanding printing
 tasks.  Gutenprint was formerly known as Gimp-Print.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.24-1-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation

[Riku Voipio]

On Mon, Apr 21, 2008 at 10:36:37PM +1000, Mark Purcell wrote:
> But you are free to assist with the package in what ever
> way you can.  All contributions are welcome.

Patrick, as you see you are clearly welcome. So please cool down
and submit patches :) 

> Perhaps in the longer term we could consolidate in a debian printing team,
> http://lists.debian.org/debian-printing/ but given the amount of work
> (outstanding BTS) each team has any contributions are welcome.

Certainly, a package called "cupsddk" ending up maintained by
hplip team is quite suprising..


-- 
"rm -rf" only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation

[Leo costela Antunes]

[removing non-related maillists and recipients, this is a purely devel
comment]

Patrick wrote:
> Till did never deal with my correspondence so far, which is why I think
> he should not maintain it - apart from that I am a CDBS fan, and things
> look far cleaner than with his debian/rules.

A bit of - hopefully constructive - nit-picking:
Just because a rules file with CDBS *looks* clean that doesn't
necessarily imply any direct improvement in package quality.
I'm playing devil's advocate here because I also use CDBS in many of my
packages, but I still think it's important to keep the distinction in mind.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation

[Martin Pitt]

Hi Patrick,

Patrick [2008-04-21 17:55 +0200]:
> You have not _explicitely refused it - but you didnt add me either. 

Oh, that might have been the point of confusion. I am an administrator
for the cupsys package alioth project, but you didn't state that you
wanted to work on cupsys itself (and, besides, you should do some
contributions before you get commit access). So far I assumed that
there would be separate projects for separate sources?

> And to be honest - or rathe rin fact it does NOT make any sense, since  
> the Ubuntupackage is more of a hack than a debian-like package 

That might very well be so, I haven't checked it at all. I just wanted
to ensure that you are aware of it.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation

[Patrick]

Mark Purcell schrieb:

Patrick Ringl [2008-04-21  3:46 +0200]:


I am concerned about 'cupsddk' which recently passed NEW. On 25th of
march I contacted pkg-cups for joining the team and working on cupsddk
[1] since I am about to repackage 'splix' (a driver for samsung laser
printers).
Martin Pitt did not accept my request for NO reason and told me to work
together with the Ubuntumaintainer of the package.
  


Patrick,

Maintenance of cupsddk is open for team contributions, please pass any changes 
you have to the mailing list [EMAIL PROTECTED] and we will 
incorporate them.


 http://svn.debian.org/wsvn/pkg-hpijs/cupsddk/?op=log

We also need cupsddk to fix some release critical bugs in hplip, which is why 
we have packaged it.  We work with Till in the hplip team as well and he has 
commit access, so it seemed like the next most sensible place.  


http://lists.debian.org/debian-printing/2008/02/msg00043.html
  
Well that is true, but uploading a package that WILL be release-critical 
is any good? And yes since the copyright file is wrong, this is a rc-bug.
And well, since it is cups related, I'd like to see it in pkg-cups tho. 
I doubt that my changes are 'accepted' by Till, since they'll turn the 
package inside out - but I'll give it a try.


Till did never deal with my correspondence so far, which is why I think 
he should not maintain it - apart from that I am a CDBS fan, and things 
look far cleaner than with his debian/rules.
You didn't change the RFP to an ITP and the WNPP is full of people who haven't 
issued an ITP and say they will but then never do anything.  Policy states 
you should change the WNPP bug to ITP, which you didn't, so there has been no 
policy violation.  But you are free to assist with the package in what ever 
way you can.  All contributions are welcome.
  
Yes, you are right. Although I maintain several packages, I forgot about 
filing the ITP. My hint of a proper policy violation was anot about that 
'act of stealing' but rather because it keeps the wrong copyright file :-)


cupsddk has been uploaded to NEW twice and updates since, so you could of said 
anything at any time.  There have also been some bug reports, so please 
forward any comments you have on the copyright file etc...
  
Yep, unfortunately I have not noticed it's upload to SID in the first 
place - but I'll try to contribute :-)
Perhaps in the longer term we could consolidate in a debian printing team,  
http://lists.debian.org/debian-printing/ but given the amount of work 
(outstanding BTS) each team has any contributions are welcome.


  
Mark
  

regards,
Patrick


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation

[Patrick]

Hello Martin,

Martin Pitt wrote:

Hi Patrick,

Patrick Ringl [2008-04-21  3:46 +0200]:
  
I am concerned about 'cupsddk' which recently passed NEW. On 25th of 
march I contacted pkg-cups for joining the team and working on cupsddk 
[1] since I am about to repackage 'splix' (a driver for samsung laser 
printers).
Martin Pitt did not accept my request for NO reason and told me to work 
together with the Ubuntumaintainer of the package.



What? I was happy to see someone working on those in Debian and
welcomed you to join [1][2]. That hasn't changed, and I did not refuse
your request at all. I merely suggested that someone else already
packaged those, and it would make sense to look at the existing
package rather than doing everything from scratch again.

Where did I write that I refused your request??
  
You have not _explicitely refused it - but you didnt add me either. If 
you did in the first place I would have used Alioth's SVN repo tho.
And to be honest - or rathe rin fact it does NOT make any sense, since 
the Ubuntupackage is more of a hack than a debian-like package - and 
even the one that just passed NEW is just the Ubuntupackage with some of 
the lintian-warnings fixed.

Martin,
who is slightly confused and thinks that there is a big
misunderstanding happening here

[1] 
http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005104.html
[2] 
http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005110.html

  
Could be that I have been a bit harsh in the first place, but I was 
disappointed and angry and felt of ignored by you in some way.




regards,
Patrick


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation

[Mark Purcell]

> Patrick Ringl [2008-04-21  3:46 +0200]:
> > I am concerned about 'cupsddk' which recently passed NEW. On 25th of
> > march I contacted pkg-cups for joining the team and working on cupsddk
> > [1] since I am about to repackage 'splix' (a driver for samsung laser
> > printers).
> > Martin Pitt did not accept my request for NO reason and told me to work
> > together with the Ubuntumaintainer of the package.

Patrick,

Maintenance of cupsddk is open for team contributions, please pass any changes 
you have to the mailing list [EMAIL PROTECTED] and we will 
incorporate them.

 http://svn.debian.org/wsvn/pkg-hpijs/cupsddk/?op=log

We also need cupsddk to fix some release critical bugs in hplip, which is why 
we have packaged it.  We work with Till in the hplip team as well and he has 
commit access, so it seemed like the next most sensible place.  

http://lists.debian.org/debian-printing/2008/02/msg00043.html

You didn't change the RFP to an ITP and the WNPP is full of people who haven't 
issued an ITP and say they will but then never do anything.  Policy states 
you should change the WNPP bug to ITP, which you didn't, so there has been no 
policy violation.  But you are free to assist with the package in what ever 
way you can.  All contributions are welcome.

cupsddk has been uploaded to NEW twice and updates since, so you could of said 
anything at any time.  There have also been some bug reports, so please 
forward any comments you have on the copyright file etc...

Perhaps in the longer term we could consolidate in a debian printing team,  
http://lists.debian.org/debian-printing/ but given the amount of work 
(outstanding BTS) each team has any contributions are welcome.

Mark


signature.asc
Description: This is a digitally signed message part.

Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation

[Martin Pitt]

Hi Patrick,

Patrick Ringl [2008-04-21  3:46 +0200]:
> I am concerned about 'cupsddk' which recently passed NEW. On 25th of 
> march I contacted pkg-cups for joining the team and working on cupsddk 
> [1] since I am about to repackage 'splix' (a driver for samsung laser 
> printers).
> Martin Pitt did not accept my request for NO reason and told me to work 
> together with the Ubuntumaintainer of the package.

What? I was happy to see someone working on those in Debian and
welcomed you to join [1][2]. That hasn't changed, and I did not refuse
your request at all. I merely suggested that someone else already
packaged those, and it would make sense to look at the existing
package rather than doing everything from scratch again.

Where did I write that I refused your request??

Martin,
who is slightly confused and thinks that there is a big
misunderstanding happening here

[1] 
http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005104.html
[2] 
http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005110.html

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Re: priorities (was: Re: RFC: cups as "default" printing system for lenny?)

[Agustin Martin]

On Fri, Dec 07, 2007 at 12:01:43AM +1000, Anthony Towns wrote:
> Kind of reviving an old thread, but anyway:
> It also includes, but afaics, probably doesn't need to (anymore):
> 
>   ispell, dictionaries-common, iamerican, ibritish, wamerican

#416572: ibritish: Should not have priority standard 

Only wamerican was originally intended for standard, because former
wamerican maintainer considered that a basic english wordlist should be
present in a system. dictionaries-common is standard only because is
needed by wamerican. I have been thinking at various ways to lower
the standard size, but am still undecided about the best choice, if
wamerican is to remain standard.

a) Splitting a new 'dictionaries-common-base' package containing
   things meant only for wordlists (and so for wamerican) and some
   things that are better here for simplicity.  
b) Having a wamerican-standard package that is the same as normal
   wamerican, but without the dictionaries-common integration stuff.
   With proper conflicts/provides wamerican would replace it as soon
   as another wordlist or an ispell/myspell/aspell dict is installed.

Still need to make some tests about this.

-- 
Agustin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

priorities (was: Re: RFC: cups as "default" printing system for lenny?)

[Anthony Towns]

Kind of reviving an old thread, but anyway:

On Sun, Nov 11, 2007 at 07:12:35PM +0100, Marc 'HE' Brockschmidt wrote:
> I believe it to be one of the more important bits of a standard Unix
> *desktop* installation - but this just reminds me of the fact that I'm
> quite uncomfortable with keeping a system like package priorities around
> for much longer. Diverging use-cases (like in this case) show that one
> definition of "standard" isn't really helpful anymore.

Haven't we more or less already moved away from priorities as meaning
anything particularly important? We have:

required/essential -- stuff that can't be removed: libc, dpkg, etc
important -- the rest of base, stuff necessary to bootstrap and
recover a usable and useful system
standard -- a minimal collection of useful stuff we'd like to see on
every Debian system
optional -- all the good software in the world
extra -- obscure stuff

All the really important questions are which bits of "optional" (and
occassionally extra) are useful for a given user.

I'm not sure if there's any point to continuing to try to make sure that
nothing >= optional conflicts with anything else >= optional.

> I think we may want to start thinking about getting rid of the whole
> thing and switching to something which allows us to express more complex
> importance measurements for packages. In fact, d-i and its task system
> have been a step in that direction, so we maybe should evaluate if we
> want to formalize it a bit more and get it into policy to replace
> priorities.

required and important are both needed by debootstrap, so can't be gotten
rid of (though they could be changed to use some other field/name).

Priority: standard currently contains:

at, bc, dc, lsof, file, less, sharutils, strace
dnsutils, ftp, host, ssh, mtr-tiny, finger, w3m, whois
doc-debian, doc-linux-text
exim, mailx, mutt, procmail, mime-support, mpack
gettext-base, locales
pciutils
perl (not just perl-base), python
reportbug
selinux policy

That seems a pretty reasonable set of functionality to put on all Debian
boxes (unless the admin specifically says otherwise), afaics.

It might be sensible to replace ftp with lftp these days, though. And
I'm not sure what happened to the exim v postfix defaults discussion a
little while ago, and maybe procmail/mpack aren't all that necessary.

It also includes, but afaics, probably doesn't need to (anymore):

ispell, dictionaries-common, iamerican, ibritish, wamerican
m4, texinfo (???)
mtools (access unmounted msdos filesystems, not NTFS though)
nfs-common, portmap (enables mounting NFS shares)
pidentd (is IDENT still used on today's internet, with all its NAT?)
openbsd-inetd  (needed by pidentd)
tcsh (people who remember what it is know how to install it)
time (???)
telnet (netcat is important, as is wget)

But as far as "default installs" for anything of any real meaning,
I just don't see Priorities as being relevant anymore.

Cheers,
aj



signature.asc
Description: Digital signature

Re: RFC: cups as "default" printing system for lenny?

[Marc 'HE' Brockschmidt]

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Sun, Nov 11, 2007 at 07:12:35PM +0100, Marc 'HE' Brockschmidt wrote:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>>> Also, do we really need *any* printing system as priority: standard?  It's
>>> not clear to me that printing is still really part of a standard Unix
>>> installation, even for desktop users (and it definitely isn't for
>>> servers).
>> I believe it to be one of the more important bits of a standard Unix
>> *desktop* installation - but this just reminds me of the fact that I'm
>> quite uncomfortable with keeping a system like package priorities around
>> for much longer. Diverging use-cases (like in this case) show that one
>> definition of "standard" isn't really helpful anymore.
> Well, sure it is; it defines the lowest common denominator that we think
> should be installed by default on all systems.  Just because it may be
> difficult to decide what that is doesn't make "standard" irrelevant, because
> we still /do/ have to decide what we're going to install by default. :)

Yes, but our current framework makes the decision more complex than it
needs to be: What we kick out from standard is either in the (gigantic)
desktop task or not installed at all anymore. Having a
standard-{desktop,server,...} task would make it easier.

>> I think we may want to start thinking about getting rid of the whole
>> thing and switching to something which allows us to express more complex
>> importance measurements for packages. In fact, d-i and its task system
>> have been a step in that direction, so we maybe should evaluate if we
>> want to formalize it a bit more and get it into policy to replace
>> priorities.
> The d-i task system looks at the Priority: standard packages to assemble the
> "standard" task...

Sure, but it also provides tasks that split up optional and extra into
manageable chunks. The need for that is not disputed, simply because of
the number of packages that are << standard. I just believe that the
number of candidates for standard has increased enough to make it
reasonable to apply a similar split.

Most people have no idea what the actual difference between extra and
optional is supposed to be, in fact, most people only work with two
priorities: standard and !standard.

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
98: Emacs
   emacs makes any computer slow


pgpDLE7wmBBa8.pgp
Description: PGP signature

Re: RFC: cups as "default" printing system for lenny?

[Steve Langasek]

On Sun, Nov 11, 2007 at 07:12:35PM +0100, Marc 'HE' Brockschmidt wrote:
> Russ Allbery <[EMAIL PROTECTED]> writes:
> > Also, do we really need *any* printing system as priority: standard?  It's
> > not clear to me that printing is still really part of a standard Unix
> > installation, even for desktop users (and it definitely isn't for
> > servers).

> I believe it to be one of the more important bits of a standard Unix
> *desktop* installation - but this just reminds me of the fact that I'm
> quite uncomfortable with keeping a system like package priorities around
> for much longer. Diverging use-cases (like in this case) show that one
> definition of "standard" isn't really helpful anymore.

Well, sure it is; it defines the lowest common denominator that we think
should be installed by default on all systems.  Just because it may be
difficult to decide what that is doesn't make "standard" irrelevant, because
we still /do/ have to decide what we're going to install by default. :)

> I think we may want to start thinking about getting rid of the whole
> thing and switching to something which allows us to express more complex
> importance measurements for packages. In fact, d-i and its task system
> have been a step in that direction, so we maybe should evaluate if we
> want to formalize it a bit more and get it into policy to replace
> priorities.

The d-i task system looks at the Priority: standard packages to assemble the
"standard" task...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: cups as "default" printing system for lenny?

[Josselin Mouette]

Le lundi 12 novembre 2007 à 12:08 -0800, Steve Langasek a écrit :
> I'm assuming that re-raising the priority of lpr is not a reasonable means
> of addressing this, since that's now a completely separate printing
> implementation than the one used by default on the desktop now and AFAICS it
   ^^
> doesn't make sense to use two different defaults for these purposes.

I should add that it's not only a default anymore. Since GTK+ 2.12
(maybe 2.10 ?) printers made available through lpr aren't even displayed
in the print dialog box, and you need to change your gtkrc if you want
to see them.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: RFC: cups as "default" printing system for lenny?

[Steve Langasek]

On Sun, Nov 11, 2007 at 01:26:25AM -0600, Manoj Srivastava wrote:
> On Sat, 10 Nov 2007 21:42:52 -0800, Russ Allbery <[EMAIL PROTECTED]> said: 

> > Also, do we really need *any* printing system as priority: standard?
> > It's not clear to me that printing is still really part of a standard
> > Unix installation, even for desktop users (and it definitely isn't for
> > servers).

> Way back when, “standard” was defined as  stuff that an old UNIX
>  hand would say “WTF happened to that?” if it is not present on a
>  default install. While I am unsure of this definition of standard still
>  holds,

According to Policy, this is the definition of "important" rather than
"standard"?  ("Standard" is defined as "what we install by default", where
the core UNIX stuff is identified as the "important" subset of this.)

> but as an old UNIX hand I can say that if I am on a UNIX like
> machine, and I can't just say lpr foo.txt and have it printed on the
> default printer, I would find the system deficient and un-UNIX like.

> How the printing occurs is not significant, as long as it can.

To satisfy this I guess we would need to raise the priority of both cupsys
and cupsys-bsd.

I'm assuming that re-raising the priority of lpr is not a reasonable means
of addressing this, since that's now a completely separate printing
implementation than the one used by default on the desktop now and AFAICS it
doesn't make sense to use two different defaults for these purposes.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-samba-maint] RFC: cups as "default" printing system for lenny?

[Christian Perrier]

Quoting Steve Langasek ([EMAIL PROTECTED]):
> A few years back, Samba upstream began using CUPS as the default printing
> system whenever CUPS support was enabled.  At the time, cupsys was Priority:
> optional, and lpr as the standard Unix printing interface was Priority:
> standard (or higher), so I patched the Samba packages in Debian to default
> to BSD printing instead of CUPS.
> 
> Today the circumstances have changed.  It seems that lpr was demoted to
> optional sometime before the etch release, putting it on equal footing with
> cupsys in that regard, and CUPS itself has IME improved markedly since the
> time that decision was made (I'm personally still not fond of the
> implementation, but at least it does a better job of talking to printers for
> me :).  So I have two questions:
> 
> - Is there any remaining reason why the Samba maintainers shouldn't drop
>   this patch, switching to CUPS as the default print system?

I think that no objections to this was made so we might drop the
patch. DO you agree, Steve, or should we wait longer for other comments?

I vote for dropping the patch which is yet another step towards having
samba in Debian as close as possible as its upstream.

> - Should we consider raising the priority of cupsys to standard, to take the
>   place of lpr as an available-by-default printing system on stock installs?


Here, we clearly don't seem to have any consensus, but anyway, *this*
is not in samba maintainers hands, of course.




signature.asc
Description: Digital signature

Re: RFC: cups as "default" printing system for lenny?

[Steve Langasek]

On Sat, Nov 10, 2007 at 09:42:52PM -0800, Russ Allbery wrote:

> > - Should we consider raising the priority of cupsys to standard, to take the
> >   place of lpr as an available-by-default printing system on stock installs?

> The last time I looked at CUPS, it was massively more complicated than lpr
> and involved dubious things like running daemons that listened on network
> ports for user configuration.  Is that still the case?

CUPS still supports configuration via the web interface on port 631, yes; by
default the daemon only listens on localhost, though, and there are other
config tools that don't rely on the web interface for managing
printers/queues in a desktop setting.

It is more complicated than lpr, for sure.  That's a big reason why I don't
particularly care for the implementation.  Nevertheless, CUPS has
effectively won out as the standard printing service on Linux.

> Also, do we really need *any* printing system as priority: standard?  It's
> not clear to me that printing is still really part of a standard Unix
> installation, even for desktop users (and it definitely isn't for
> servers).

Perhaps not.  It did seem to me like something that we would want available
by default, and that would in any case be consistent with past practice.
After all, this isn't so much a question of installing a "print server"
task, the cupsys package is these days the package most users will want
installed even for local printing.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: cups as "default" printing system for lenny?

[Steve Langasek]

On Sun, Nov 11, 2007 at 01:05:36AM -0500, Joey Hess wrote:
> Yes, it would make more sense for samba to default to CUPS, if there's
> some reason it can't probe/support both,

Well, because there's no code written to do this, and anyway supporting both
at the same time would likely be messy and result in duplicate queues.
(Note that one of the reasons Samba needs to know what print system is in
use is in order to export the list of available queues over SMB if
configured to do so.)

> and if it can't use the generic lpr interface also provided by cupsys.

The cupsys lpr interface is only available with the cupsys-bsd package,
which is Priority: extra and is not likely to be installed unless
specifically requested.  So if CUPS is preferred, it's more straightforward
to just use the native CUPS support.

I'll make this change to the Samba packages for lenny, after verifying
whether any special handling is needed for transitioning.

> Yes, there's no reason to have any printing system at standard priority.
> A full CUPS install with all the PPDs and such would bloat standard
> enormously.

I don't agree that making CUPS standard implies also making all of the PPDs
standard (AFAICS cupsys only Recommends foomatic-filters and doesn't depend
on any PPDs at all), but I'm not bothered if CUPS doesn't become standard
either; just thought the question was worth asking.

> Just making cupsys standard would perhaps allow spooling to remote
> printers from the command line, but not much else. d-i makes it easy
> enough to get CUPS installed.

Indeed, I seem to have it already installed even in places where I didn't
want it. ;)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: cups as "default" printing system for lenny?

[Leo "costela" Antunes]

[not subscribed to -policy, just keeping original cross-posting]

Marc 'HE' Brockschmidt wrote:
> I think we may want to start thinking about getting rid of the whole
> thing and switching to something which allows us to express more complex
> importance measurements for packages. In fact, d-i and its task system
> have been a step in that direction, so we maybe should evaluate if we
> want to formalize it a bit more and get it into policy to replace
> priorities.

Seconded.
A use-case based priority system is clearly - IMHO - a better suited
system then the "Priority:" paradigm for a distribution as broad
reaching as Debian.
Whether by extending the tasks system, the Priority paradigm (by perhaps
including a [use-case] tag, for instance: "Priority: standard
[!embeded]") or another wholly different approach, this seems like a
worthwhile idea.

One of the possible advantages for a different paradigm would be for
"reduced" CDDs, such as Emdebian, whose standard set of packages might
divert considerably by having _less_ packages, in which case the current
task system would fall short, AFAICT.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFC: cups as "default" printing system for lenny?

[Marc 'HE' Brockschmidt]

Russ Allbery <[EMAIL PROTECTED]> writes:
> Also, do we really need *any* printing system as priority: standard?  It's
> not clear to me that printing is still really part of a standard Unix
> installation, even for desktop users (and it definitely isn't for
> servers).

I believe it to be one of the more important bits of a standard Unix
*desktop* installation - but this just reminds me of the fact that I'm
quite uncomfortable with keeping a system like package priorities around
for much longer. Diverging use-cases (like in this case) show that one
definition of "standard" isn't really helpful anymore.

I think we may want to start thinking about getting rid of the whole
thing and switching to something which allows us to express more complex
importance measurements for packages. In fact, d-i and its task system
have been a step in that direction, so we maybe should evaluate if we
want to formalize it a bit more and get it into policy to replace
priorities.

Marc
-- 
BOFH #4:
static from nylon underwear


pgpqsyucbj3TQ.pgp
Description: PGP signature