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 b
:
>
> 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
> ht
: 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,
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
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
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,
p
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-t
(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 g
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 Apa
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-gute
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
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
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
; ) 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
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
ta.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
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
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
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.
> >
>
* 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, an
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
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
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
suring 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
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
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
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
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
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 the
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 De
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 containin
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 agai
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 emplo
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)
>
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 GPL
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.
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.
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-witho
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
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] gen
ce
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 pr
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 pri
rtant
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 'wi
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 lis
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 blac
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
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 exist
* 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 wel
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
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 ser
s
> 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 aft
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 yo
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 ap
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
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
> > t
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
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
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
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.
> > > There
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.
> &g
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 di
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
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 "
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 functionalitie
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 proble
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 p
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 Prin
u 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?
>>>
>>>
&g
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
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
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 assista
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.
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 r
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 s
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 v
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 th
:
>
> 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 fix
ith 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
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 UNSUB
* 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
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
.
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
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 con
[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 o
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, be
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 las
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' (
> 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
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 lase
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 standa
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 s
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
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 desk
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
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
> > Uni
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:
> standar
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 c
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 woul
[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
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 th
1 - 100 of 160 matches
Mail list logo
