[RFE] Implement printer profiles

This issue is a placeholder for implementing printer profiles, which are needed for several cases:

CUPS temporary queues work only with LAN located devices, because the tech uses mDNS for device discovery. However, this situation isn't usually a case for enterprises, where their IT engineers tend to put printers into a separate VLAN - they do it because of security and monitoring. Without any migration plan, these use cases would be left behind if permanent queues are gone and CUPS temporary queues become the only technology in CUPS.
Sometimes admins implement N queues to 1 device in environments where users have scripts (with lp commands) to automate printing process, or where users aren't that technically experienced/or don't bother to check up the print dialog and set up print options accordingly. f.e. print queues like printer_bw, printer_bw_duplex, printer_color, printer_color_duplex etc... - currently there would be only one print queue for one device, printer profiles should enable the behavior mentioned above.
Users sometimes want a different default option than printer itself offers them - because print queue is always created a new during print dialog, the printer default would be always set and an user would need to change it, which can be annoying and a possible source of issues. A different default option would be recorded in printer profile and it will overwrite a value coming from IPP communication with printer.

The idea of printer profiles was introduced by Mike Sweet during email communication within OpenPrinting group and distro maintainers and presented during PWG F2F meetups.
Tasks:

[ ] implement CUPS-Create-Printer-Profile operation in cupsd/local cups module in modular design (idea: lpadmin/web ui/cups-browsed would sent the IPP_OP_CUPS_CREATE_PRINTER_PROFILE request and cupsd will create /etc/cups/profiles/<queue_name>.profile, containing name, uri and possible options defined in CLI/web ui)
[ ] implement showing queues defined by printer profiles in cupsEnumDests() CUPS library function (idea: cupsEnumDests() will check /etc/cups/profiles/ and if there are some, add them to the output - this will show profile queues in print dialogs, which use cupsEnumDests())
[ ] implement sharing profile-defined queues in cupsd/sharing cups module in modular design
[ ] implement an option for lpadmin to create profiles - after some testing time and permanent queue removal, this behavior will be switched to default
[ ] implement a checkbox/page in CUPS web ui for creating profiles - after testing+permanent queue removal, it will be moved under 'Add Printer' tab
[ ] implement tests for printer profiles in CUPS test suite
[ ] add printer profiles into CUPS documentation, man pages etc

I will try to implement this feature in meantime, but any other help is welcomed.
@michaelrsweet WDYT? Did I forget about something in tasks or do you have any recommendation what to add?

@zdohnal We don't want an operation for this, we want it to be in file(s) that can be installed.

Hi @michaelrsweet ,
hmm, so the expectation is the clients (lpadmin/cups web ui/control-centers/cups-browsed) will write profile files by themselves and libcups functions only pick them up?
Or should admins write profiles by hand and then save them into /etc/cups/profiles or ~/.cups/profiles/ and possibly distribute the profiles through the organization (via special packages)?
Either way, I can't help to not to see a classic PPD déjavu - in both cases above we need to count on profiles being generated and maintained correctly instead of having a full control over them. We would have to keep stable a whole profile file structure or coordinate with known profile implementations if we make some changes - it looks like a bigger challenge than keeping IPP request format stable.
Ad clients creating profiles - I guess we can add the functionality into lpadmin/cups web ui and cups-browsed, but I'm not sure how GTK or other GUI apps will be interested in writing profiles.
What do you think?

@zdohnal So the point of my "profiles" featurette in my CUPS slides was not to provide a way to further inject PPDs into the system but to provide a simple way for enterprises to configure/deploy IPP Everywhere queues (pointed at real printers, a central CUPS server, etc.) when mDNS/DNS-SD wasn't feasible - basically duplicating what Apple has done for iOS/iPadOS/macOS and what hundreds of users have been asking for over the years on Linux (re: supporting multiple ServerName directives in client.conf).
We can keep the format dirt simple, e.g.:
# comment
ServerName hostname-or-ip[:port]
Printer {ipp,ipps}://hostname-or-ip[:port]/path

Then libcups just contacts each of the hosts during enumeration and lists any it can contact. The auto-assigned names can use either the reported DNS-SD name (from the printer-dns-sd-name attribute) or the remote printer name (from the printer-name attribute) plus hostname, same as what we do for DNS-SD.
(the same approach would be used for LDAP support, whenever we decide to implement that again using the IETF-published schema...)

@zdohnal So the point of my "profiles" featurette in my CUPS slides was not to provide a way to further inject PPDs into the system

That wasn't what I meant by PPD dejavu remark, I'm sorry, if it sounded like that - I'll explain later.

but to provide a simple way for enterprises to configure/deploy IPP Everywhere queues (pointed at real printers, a central CUPS server, etc.) when mDNS/DNS-SD wasn't feasible - basically duplicating what Apple has done for iOS/iPadOS/macOS and what hundreds of users have been asking for over the years on Linux (re: supporting multiple ServerName directives in client.conf).

That would be great if cupsd was able to support this feature - I guess it is exactly the first point from my initial comment - can't we have libcups reading client.conf for multiple 'ServerName's and then provides queues from destinations?
However this feature will set the same default options for such queues in user's print dialog as the default options, which the queue has on the server/device - which sometimes differs from the default options user wants - it will become annoying to set the default options every time you want to print.
So IMO cupsd should have a way how to override the attributes which come from server, to give user more flexibility about such queues - and attributes (or options - I guess it will be more readable for non-IPP people) in profiles can do the trick.
Based on the info above, we still would have needed a new file and a new format (or adding it to printers.conf), f.e. like:
<Printer <name>>
URI <value>
(this one would be applied only if we put them into printers.conf) Printer-is-profile <yes/no>
<new default option1/attribute1> <value1>
.
.
.
<new default optionN/attributeN> <valueN>
</Printer>

Additionally - IIUC the permanent queues are planned to go away in the future and that's the source of other mentioned use cases (different default options, 1 device to N queues), which printer profiles can support in addition to the idea what you meant in CUPS slides (althought IIRC you proposed using printer profiles for other mentioned user cases as well when we were discussing CUPS with other maintainers at the time of forking CUPS).
And if user can change options to set new default values in print dialog, something will need to do it for him (I cannot expect an user creating a xml file by themselves), so the options are following:

clients will create profiles by themselves and libcups will read them - we won't need an operation for it, but we will need to count on application to create a valid profile and we will need to keep compatibility for whole profile file, otherwise users will have breakages - this is what I meant by PPD dejavu - developing profiles will be blocked/obstructed by client implementations, which aren't on track with CUPS development and compatibility scope is larger than with IPP request.
define IPP request/DBUS method, which clients will use to create a profile, and cupsd will create a profile as it sees fit - the pros will be an united profile generation (so not every client needs to implement it) under CUPS. The problem will be to adjust clients to use it (the same is for the former option) and to keep compatibility in IPP request, but that's smaller scope than a file structure.

IMHO it is more feasible to adjust clients to do a request than implement a profile writer, so that's why I proposed a new request type - but I wasn't that sure if we aren't restricted by RFC and PWG standards for IPP, but I didn't find IPP_OP_CREATE_LOCAL_PRINTER operation in the standard either, so I guess it's fine.

Then libcups just contacts each of the hosts during enumeration and lists any it can contact. The auto-assigned names can use either the reported DNS-SD name (from the printer-dns-sd-name attribute) or the remote printer name (from the printer-name attribute) plus hostname, same as what we do for DNS-SD.

IMO if we can decide what to use based on path in uri. If it contains /printers/, use remote printer name, otherwise use DNS-SD name if available.

(the same approach would be used for LDAP support, whenever we decide to implement that again using the IETF-published schema...)

I'm not aware about anyone who uses LDAP for printing right now, so we can leave it out for now - we can reevaluate if there is a demand.

@zdohnal
thank you so much for your expnanatory description of the issue.
It helps so much to better understand possible consequences
of what is planned for the upcoming new CUPS.
As far as I currently understand it it seems
an underlying fundamental change in CUPS is
that CUPS will become basically "stateless".
The cupsd itself in the upcoming new CUPS will be stateful because
while it runs it keeps some state of the IPP printers it communicates with.
But when the cupsd is stopped it does not save its state persistently into some files.
When it is started it does not load a prior saved state from some persistent files.
So in the upcoming new CUPS there will be no longer be a persistently stored state.
The cupsd configuration files specify how cupsd behaves but do not save its state.
Also files as in https://github.com/OpenPrinting/cups/issues/207#issuecomment-879903893
specify an ascpect how cupsd behaves but do not specify some kind of state for the cupsd.
In contrast in current CUPS there is a persistently stored state
mainly /etc/cups/printers.conf and the /etc/cups/ppd/queue_name.ppd files
and when current cupsd is stopped it saves its current state to files
and when current cupsd is (re)started it (re)establishes its state
according to a prior saved state from such persistent files.
Initially such a "prior saved state" could be provided by an admin.
If my understanding is right that CUPS will become basically "stateless"
as I described above then a consequence is that the upcoming new CUPS
can no longer be used to provide traditional print server functionality
in a managed environment.
With "traditional print server functionality in a managed environment" I mean:
An admin specifies his intended print server functionality persistently in config files
and the print server service process (i.e. cupsd) obeys what the admin specified.
With "persistently (in config files)" I mean that what the admin specified persists.
I.e. what the admin specified does not "magically" change "on its own".
I.e. only the admin specifies things.
E.g. when the admin specified a print queue with certain print queue specific settings
the print server will provide that particular functionality as specified by the admin
even if it is nonsense what the admin had specified - provided his specification
is not impossibe - i.e. basically as long as his specification is syntactically correct.
For example the admin can specify print queues for printers that do not exist
or he could even specify print queue specific things that will not work
for the printer that is associated with that print queue.
Bottom line from my point of view as far as I currently understand it:
When temporary queues have become the only technology in CUPS
CUPS will be no longer usable as a print server.

@zdohnal WRT default options, the existing lpoptions support (which has been in CUPS since v1.1) is intended to provide the overrides you seek. The server/printer-side defaults are the base, then any local admin-defined defaults (in /etc/cups/lpoptions), then finally any per-user defaults (in ~/.cups/lpoptions). I don't want to add yet another way to specify/override default values as we have enough trouble getting applications to support the current API.
The profile mechanism should be hooked into the client side code (so libcups, not cupsd) and should transparently show up in the output from cupsGetDests and cupsEnumDests so that applications don't need to change. Just as for printers discovered via DNS-SD, a temporary queue will be created to handle spooling and filtering the first time you print to a profile printer.

@jsmeix So if you look at my most recent CUPS slide deck, one of my proposed future architectural changes is to split cupsd into two services - a per-user "local server" that handles the normal printing tasks and a system-wide "sharing server" that would provide persistent queues, ACLs, accounting, etc. Most users would never install the sharing server.

@michaelrsweet
thank you for the prompt reply.
It is much appreciated.
I had read
https://ftp.pwg.org/pub/pwg/liaison/openprinting/presentations/cups-plenary-may-2021.pdf
and I had noticed the CUPS 3.0 Local Server and Sharing Server parts
but I did not see the whole idea behind - in particular I did not see that
the CUPS 3.0 Sharing Server would still provide persistent queues.
Somehow the "Configuration similar to existing cupsd" did not trigger
the right things in my brain.
So as far as I now understand things:
The CUPS 3.0 Local Server basically provides what normal end-users usually need
in particular automated setup of what is needed to "just print" to IPP printers.
The CUPS 3.0 Sharing Server basically provides what admins in a managed environment need
in particular persistent queues where admins can specify print queue specific things
as they need it in their particular environment.

@jsmeix Right. And since the sharing server doesn't have to deal with drivers it can (hopefully) end up providing a lot better support for accounting and other enterprise-y features... :)

@jsmeix

Bottom line from my point of view as far as I currently understand it:
When temporary queues have become the only technology in CUPS,
CUPS will be no longer usable as a print server.

Before I was corrected by @michaelrsweet in the next comment, I thought there will be no permanent queues in CUPS model in the future, so I thought additional features for profiles will be needed to cover the functionality, which was provided by permanent queues.
The original idea behind this issue was to cover use cases which aren't on the same LAN or are done by permanent queues right now with new, future CUPS compatible ways, so CUPS can be used as a print server even after removals of legacy technologies - meaning we would have not removed the old until the new is implemented and tested.
With my mistake corrected, I'll update the issue description to match up with the original idea - getting devices outside of LAN.

@michaelrsweet

@zdohnal WRT default options, the existing lpoptions support (which has been in CUPS since v1.1) is intended to provide the overrides you seek.

Aha, ok - so I've tried:

using lpoptions for setting a default option from PPD to different value by:

$ lpoptions -p <temp_queue> -o <option>=<value>

, the option was applied and a permanent queue was created (so GTK will now get two same queues again :( ...), but I can see the correct default option for both.
The questions are:

Will be permanent queues available in CUPS 3.0 Local Server too, since changing default options depends on it?
Will be CUPS Web UI available in CUPS 3.0 Local Server? To have a GUI way how to set the defaults.

using lpadmin to set job options associated with the queue:

$ lpadmin -p <temp_queue> -o <option>-default=<value>

This way, a normal permanent queue would change the option's value listed by lpoptions -p <queue>, but if we do it on temp queue, the temp queue will become permanent, but with invalid URI and the option isn't applied.:
$ lpadmin -p HP_LaserJet_M1536dnf_MFP_42307C_ -o copies-default=2
$ lpstat -v
device for HP_LaserJet_M1536dnf_MFP_42307C_: ///dev/null
$ lpoptions -p HP_LaserJet_M1536dnf_MFP_42307C_
device-uri=ipp://HP%20LaserJet%20M1536dnf%20MFP%20(42307C)._ipp._tcp.local/ Duplex=DuplexNoTumble printer-info='HP LaserJet M1536dnf MFP (42307C)' printer-location printer-make-and-model='HP LaserJet M1536dnf MFP' printer-type=83886100

Is it expected or is it a bug?

I don't want to add yet another way to specify/override default values as we have enough trouble getting applications to support the current API.

As permanent queues will not go away, there is no need for applications to create profiles, so no need for adding new operations.

The profile mechanism should be hooked into the client side code (so libcups, not cupsd)

I mentioned cupsd because that was the place where the proposed operation was supposed to be implemented.

and should transparently show up in the output from cupsGetDests and cupsEnumDests so that applications don't need to change. Just as for printers discovered via DNS-SD, a temporary queue will be created to handle spooling and filtering the first time you print to a profile printer.

Agreed.

@zdohnal OK, so I think there are still some misconceptions about this.
First, using lpoptions to set default options should definitely not be creating a permanent queue (or converting a temporary queue into a permanent one) - lpoptions is all client-side and should not affect server state. Moreover, lpoptions has dealt with temporary queues since the beginning when cupsd would create an delete local queues via the old CUPS browsing mechanism, so there is NO requirement for lpoptions to work with permanent queus. So if you are seeing permanent queues getting created, that is a bug (and please file it separately...)
Second, I hope I've made it clear that the local server is supposed to be very lightweight with no permanent queues, no web interface, and very little that can be configured. It is, by design, a transient thing that comes and goes only to handle whatever print jobs the user sends to a printer or print server. Printers and servers that are setup via profiles contribute to the list of potential destinations for the user to pick but queues for them are only created as needed and destroyed when not. Think of them like you are sending an email to someone - you don't keep a persistent connection to a particular mail server on the chance you might send an email to it, you connect as needed based on the messages being sent.
Using lpadmin to change the default option value doesn't convert a temporary queue into a permanent one, although if you specify "-o printer-is-temporary=false", it will. I'm not sure why you are seeing what you are seeing unless cupsd is going away between the lpadmin and lpoptions commands - it isn't what I would expect, but then there is no place for the default values to go when it is a temporary queue so I am not surprised either...

@zdohnal
It is a long time ago since I actually used lpoptions
so perhaps this behaviour may have substantially changed.
If it still baheves basically same as in the past
you may have a look at my rather old article
https://en.opensuse.org/SDB:Print_Settings_with_CUPS
that desribes how lpoptions behaved in the past
which is basically (summary):

lpoptions stores permanent settings in some files
that stored settings stay in those files even when queues are deleted

So when lpoptions stores some setting for a temporary queue
that setting for a queue with that name is kept
also when the queue gets (automatically) deleted
and that setting will be used again if a queue with same name
gets (automatically) (re-)created.
Again: This is the old behaviour which might have meanwhile changed.

@michaelrsweet
my offhanded gut-feeling (I don't have a sufficient deeper understanding here) is
that the CUPS 3.0 Local Server should be as simple as possible
i.e. as small and lightweight and stateless as possible.
I think the less there is in a CUPS 3.0 Local Server the better it is.
I think a clear distinction is good (and avoids false expectations):
The CUPS 3.0 Local Server is has intentionally "plug-and-play/pray" semantics.
It does basically all fully automated in some reasonable way but nothing more.
Users who need something special (i.e. where the Local Server
does not "play" for them) must switch (bacause "pray" won't help them ;-)
to the CUPS 3.0 Sharing Server with all its config options and features.

Something general to find out if my understanding is right:
I think current CUPS is only for "admins in a managed environment".
To print on a printer normal (unexperienced) end-users must first
put themselves into the role of an "admin in a managed environment"
and set up a print queue - at least that is what I see on
https://www.cups.org/doc/overview.html
where all basically starts with "set up a print queue".
There is additional software (various kind of automated print queue setup tools)
but that is not part of CUPS itself.
With the new CUPS 3.0 Local Server normal end-users can stay normal end-users
because the Local Server does all what is needed to print on "suitable printers"
in a "sutiable environment" fully automated in some reasonable way
where "suitable printers" are in particular IPP Everywhere printers
and "sutiable environment" is the directly accessible local network.
The CUPS 3.0 Sharing Server is still for "admins in a managed environment".

@jsmeix Current CUPS supports temporary queues for IPP Everywhere printers (which includes printers shared from another CUPS server and certified IPP Everywhere/AirPrint/Mopria printers), and assuming that the desktop toolkits use the provided CUPS APIs they should provide access to those printers without requiring the user to setup a queue at all. I honestly don't print from Linux desktop applications enough to know whether they are using the APIs we've provided for this, but that has been the goal since CUPS 2.0 (and the APIs have been around since CUPS 1.4...)

Now it has become obvious that I know basically nothing at all about IPP Everywhere ;-)
The reason is simple: I do not have an IPP Everywhere printer.
So all I know about things like IPP Everywhere and "driverless" is from hearsay.
I have only a traditional PostScript color laser USB printer.
I hope it will continue to print reliably for some more years as it did all the time.
I also don't print from Linux desktop applications enough to know how they behave.
I use mostly the plain lp command when I print every now and then.
I assume that will continue to work for many more years.

EDIT: updated the first comment to reflect the discussion.

I honestly don't print from Linux desktop applications enough to know whether they are using the APIs we've provided for this

@michaelrsweet Most desktop application work with libcups for printing, only very old apps call lp or other similar tools directly. Have a look at which applications from a ditro repo + proprietary repo of Google Chrome depens from libcups:
$ sudo dnf repoquery --whatrequires lib64cups2
boomaga-0:3.0.0-3.x86_64
chromium-browser-stable-0:94.0.4606.71-1.x86_64
cinnamon-settings-daemon-0:5.0.3-1.x86_64
cnrdrvcups-lipslx-0:5.40-1.x86_64
cnrdrvcups-ufr2-uk-0:5.40-1.x86_64
cnrdrvcups-ufr2-us-0:5.40-1.x86_64
cups-0:2.3.3op2-4.x86_64
cups-browsed-0:1.27.5-4.x86_64
cups-common-0:2.3.3op2-4.x86_64
cups-drivers-bjnp-0:2.0.3-3.x86_64
cups-drivers-foo2zjs-0:0.0-2.2020.2.x86_64
cups-drivers-lxx74-0:<IP_ADDRESS>-17.x86_64
cups-drivers-magicolor2430dl-0:1.6.1-22.x86_64
cups-drivers-magicolor2530dl-0:2.1.1-20.x86_64
cups-drivers-magicolor5430dl-0:1.8.1-22.x86_64
cups-drivers-magicolor5440dl-0:1.2.1-21.x86_64
cups-drivers-ptouch-0:1.6-2.x86_64
cups-drivers-splix-0:2.0.1-0.20130902svn.3.x86_64
cups-filters-0:1.27.5-4.x86_64
cups-pk-helper-0:0.2.6-0.git151fb.2.x86_64
darktable-0:3.4.1-1.x86_64
draftsight-0:2<IP_ADDRESS>15-2.x86_64
draftsight-0:2<IP_ADDRESS>07-4.x86_64
epdfview-0:0.1.8-9.x86_64
gnome-control-center-0:40.0-5.x86_64
gnome-settings-daemon-0:40.0.1-4.x86_64
gnustep-gui-0:0.29.0-2.x86_64
google-chrome-beta-0:96.0.4664.35-1.x86_64
google-chrome-stable-0:95.0.4638.69-1.x86_64
google-chrome-unstable-0:97.0.4688.2-1.x86_64
gutenprint-cups-0:5.3.3-3.x86_64
hplip-0:3.20.9-6.x86_64
hplip-0:3.21.8-1.x86_64
java-1.8.0-openjdk-headless-1:<IP_ADDRESS>.b02-0.2.ea.i686
java-1.8.0-openjdk-headless-1:<IP_ADDRESS>.b02-0.2.ea.x86_64
java-1.8.0-openjdk-headless-slowdebug-1:<IP_ADDRESS>.b02-0.2.ea.i686
java-1.8.0-openjdk-headless-slowdebug-1:<IP_ADDRESS>.b02-0.2.ea.x86_64
java-11-openjdk-headless-1:<IP_ADDRESS>.7-7.x86_64
java-11-openjdk-headless-fastdebug-1:<IP_ADDRESS>.7-7.x86_64
java-11-openjdk-headless-slowdebug-1:<IP_ADDRESS>.7-7.x86_64
kde-print-manager-0:21.08.1-1.x86_64
lib64cups-devel-0:2.3.3op2-4.x86_64
lib64cupsfilters1-0:1.27.5-4.x86_64
lib64cupsimage2-0:2.3.3op2-4.x86_64
lib64freerdp-client2-0:2.4.0-1.x86_64
lib64gnomecups-1.0_1-0:0.2.3-16.x86_64
lib64gs9-0:9.54.0-5.x86_64
lib64gtk-modules2.0-0:2.24.33-2.x86_64
lib64gtk-modules3.0-0:3.24.30-5.x86_64
lib64gtk-modules4.0-0:4.3.2-3.x86_64
lib64hpipp0-0:3.20.9-6.x86_64
lib64hpipp0-0:3.21.8-1.x86_64
lib64qt5gui5-0:5.15.2-15.x86_64
lib64samba-libs0-1:4.12.11-3.x86_64
lib64sane-hpaio1-0:3.20.9-6.x86_64
lib64sane-hpaio1-0:3.21.8-1.x86_64
libgnomeprint-0:2.18.8-12.x86_64
libreoffice-common-1:7.1.6-1.x86_64
lsb-lib64-0:5.0-0.alpha.7.x86_64
perl-Net-CUPS-0:0.610.0-9.x86_64
popcorntime-0:0.3.10-1.x86_64
python3-cups-0:1.9.74-4.x86_64
qpdfview-0:0.4.18-5.x86_64
remmina-plugins-rdp-0:1.4.9-1.x86_64
riot-0:1.4.2-1.x86_64
samsung-unified-driver-0:4.01.17-4.x86_64
samsung-unified-driver3-0:3.00.90-1.x86_64
scribus-0:1.5.7-2.x86_64
system-config-printer-udev-0:1.5.15-4.x86_64
wire-desktop-0:3.19.2928-1.x86_64
x2goclient-1:<IP_ADDRESS>-3.x86_64
xpdf-0:4.02-1.x86_64

GTK+ and Qt toolkits are also among them.

Centralizing managing printers via text configs seems to be a good idea, sssd could be taught to get and apply them from FreeIPA domain, for example.
But it seems to be a bit far from real life. Usually only a few PCs require access to one printer, trying to centralize management of it will be a big overkill in many cases.
(and most printers are some crap not ready for IPP without PPDs by the way, CUPS 3.0 will not be usable without support of PPDs either directly or indirectly, most distros simply won't package it in such case, I am pretty sure).
If I am not mistaken, currently there is no way to disable automatic discovery of printers by CUPS via mDNS/Avahi. It is possible to off advertizing them, but not discovering. CUPS can discover too many printers in even small corporate environments. CC @sibskull

split cupsd into two services - a per-user "local server" that handles the normal printing tasks and a system-wide "sharing server" that would provide persistent queues, ACLs, accounting, etc. Most users would never install the sharing server.

Hi @mikhailnov ,

@michaelrsweet Most desktop application work with libcups for printing, only very old apps call lp or other similar tools directly. Have a look at which applications from a ditro repo + proprietary repo of Google Chrome depens from libcups:

unfortunately working with libcups doesn't automatically mean working with modern CUPS API, which is needed for proper temp queues support and which has been the issue causing most people to install their printers.

Centralizing managing printers via text configs seems to be a good idea, sssd could be taught to get and apply them from FreeIPA domain, for example.

It seems there is a misunderstanding - the printer profiles aren't about centralizing managing printers, but about making printers, which aren't in the local network (which is the mDNS default limitation), available in a print dialog without requiring them to be installed permanently.

(and most printers are some crap not ready for IPP without PPDs by the way, CUPS 3.0 will not be usable without support of PPDs either directly or indirectly, most distros simply won't package it in such case, I am pretty sure).

Most printers made after 2010 are capable of IPP Everywhere, so they don't need a PPD for working properly.
Most probable hiccups which set an user back to a PPD usually are:

applications don't use the modern CUPS API
user doesn't open/does close on purpose IPP port on the printer
user doesn't allow IPP communication in firewalls
a state-of-art printer, which is capable of IPP Everywhere is behind an old CUPS server, which is unable of IPP Everywhere

For old devices which doesn't support IPP Everywhere, OpenPrinting's already provided a retro-fitting printer applications for several PDLs and created manual how to create a new printer application - see #103 .
The printer application's mechanism can be used for devices which provide more specialized settings than IPP Everywhere has to offer - Gutenprint people are working on such app.

If I am not mistaken, currently there is no way to disable automatic discovery of printers by CUPS via mDNS/Avahi. It is possible to off advertizing them, but not discovering. CUPS can discover too many printers in even small corporate environments. CC @sibskull

Hmm, you're right - I thought there is the same directive as in cups-browsed, BrowseRemoteProtocols, which sets the protocols used for discovery, and setting them to 'none' disables the discovery as whole.
However, the same can be done by a simple stopping/disabling/not installing avahi-daemon, which takes care of mDNS discovery - IMHO requiring avahi-daemon running but disabling its mDNS support for CUPS is a corner case which I won't pursue because of its scarce usage, however if there is a PR, we in OpenPrinting will review it.

08.11.2021 10:27, zdohnal пишет:

Hi @mikhailnov https://github.com/mikhailnov ,
@michaelrsweet <https://github.com/michaelrsweet> Most desktop application work with libcups for printing, only very old apps call |lp| or other similar tools directly. Have a look at which applications from a ditro repo + proprietary repo of Google Chrome depens from libcups:

unfortunately working with libcups doesn't automatically mean working with modern CUPS API, which is needed for proper temp queues support and which has been the issue causing most people to install their printers.
Centralizing managing printers via text configs seems to be a good idea, sssd could be taught to get and apply them from FreeIPA domain, for example.

It seems there is a misunderstanding - the printer profiles aren't about centralizing managing printers, but about making printers, which aren't in the local network (which is the mDNS default limitation), available in a print dialog without requiring them to be installed permanently.

Thanks for clarifying. It also helps to manage printers centrally.

(and most printers are some crap not ready for IPP without PPDs by the way, CUPS 3.0 will not be usable without support of PPDs either directly or indirectly, most distros simply won't package it in such case, I am pretty sure).

Most printers made after 2010 are capable of IPP Everywhere, so they don't need a PPD for working properly.

I have Kyocera FS-1060DN bought in 2017. It requires a custom CUPS backend rastertokpsl and does not understand standard formats like PDF, PCL etc. I think it does not support IPP.
Also there is quite a  \lot of pre-2010 printers in use.
Many printers being sold require proprietary "drivers", sometimes those are convertors to an internal proprietary format, some times just PPDs with custom settings and calling custom scripts which do hackery with utilities like gs(1) preparing the input for the printer.

I have Kyocera FS-1060DN bought in 2017.

Unfortunately it doesn't depend on when you've bought it, but when the model was started to sell - your model (according dates on its manual) is from 2012.

It requires a custom CUPS backend rastertokpsl and does not understand standard formats like PDF, PCL etc. I think it does not support IPP.

You can check whether the device supports IPP Everywhere/AirPrint. If you have the device connected by USB, look for 7/1/4 interface in lsusb -v output. If you have the device connected via wifi/ethernet, most devices provide configuration web interface where you can see available options for your printer - look for IPP/AirPrint/Mopria/Bonjour/mDNS settings.
Brian documented nicely all driverless options here https://wiki.debian.org/CUPSDriverlessPrinting .

Also there is quite a  \lot of pre-2010 printers in use.

That's what a printer application technology is for.


Change content related errors from http status of 500 to 422

@jk-intuit Is this issue still open?


Roll Engine from b7cd3f8e706d to e64aabc8ce58 (7 revisions)

https://github.com/flutter/engine/compare/b7cd3f8e706d...e64aabc8ce58
2020-12-23<EMAIL_ADDRESS>Roll Dart SDK from f5b451f0dc86 to 6e1161e70a00 (1 revision) (flutter/engine#23260)
2020-12-23<EMAIL_ADDRESS>Roll Skia from 3624aba91f44 to fa711c4c756a (1 revision) (flutter/engine#23259)
2020-12-23<EMAIL_ADDRESS>Roll Dart SDK from 7d35f9bc72fb to f5b451f0dc86 (1 revision) (flutter/engine#23258)
2020-12-23<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from PzW6aMw3A... to gVgXlVNti... (flutter/engine#23257)
2020-12-23<EMAIL_ADDRESS>Roll Skia from c5ff48648ada to 3624aba91f44 (10 revisions) (flutter/engine#23254)
2020-12-22<EMAIL_ADDRESS>Roll Dart SDK from 62b0361d470f to 7d35f9bc72fb (1 revision) (flutter/engine#23251)
2020-12-22<EMAIL_ADDRESS>Roll Skia from f2ce4e91a2a5 to c5ff48648ada (6 revisions) (flutter/engine#23250)
Also rolling transitive DEPS:
fuchsia/sdk/core/mac-amd64 from PzW6aMw3AGVD to gVgXlVNtiZ1N
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Commit queue failed; closing this roll.


fixed (#176)

descriptions
fixed the images to centre from right in all types of devices (bug fixed)
issue
#176  fixed
preview link-
you can preview my code change through this link
https://trusting-swanson-0ef044.netlify.app/
and the image is fixed in all types of devices you can check with any types of screen it fixed through this link
screenshot fixed

@jhung @colinbdclark you can check my code change through this link  https://trusting-swanson-0ef044.netlify.app/
i fixed this bug in all types of devices
thanks i hope you like it

Thanks for your contributions, @Raunaksingh100. I've left comments on the issue you filed, #176, regarding this. At the moment, we're not accepting pull requests for styling issues while the site is being partially redesigned and ported to a static site generator.
For future pull requests, please also ensure that you're following the commit message guidelines for our community, which you can find in the wiki. For example, "Fixed" isn't a very informative commit message when someone is looking back at the history of the code later.

@colinbdclark sure

with the same code the two issues  fixed you can test with any screen or can decrease the text size no bug plz merge this pr
you can test the two issues from the this link -------- https://trusting-swanson-0ef044.netlify.app/
@colinbdclark  thanks


std::mutex alternative CriticalSection

Hey,
I was looking over this and I was wondering
https://github.com/DarthTon/Blackbone/blob/master/src/BlackBone/Misc/Utils.h
Shouldn't you be using LeaveCriticalSection inside of the destructor? Or else won't it still be "locked"? Just like how std::unique_lock/std::lock_guard seem to destroy the mutex when out of scope.

Yes, my mistake.

Actually it works as intended. CriticalSection behaves like std::mutex which has undefined behavior if destroyed while locked. And CSLock works as std::lock_guard - it leaves critical section in destructor. Moreover if LeaveCriticalSection is called on non-locked object, it may cause other threads to deadlock.

Oh, alright. Nice implementation then :)


Roll engine ff49ca1c6e5b..c5d3c90d985b (6 commits)

git@github.com:flutter/engine.git/compare/ff49ca1c6e5b...c5d3c90d985b
git log ff49ca1c6e5b..c5d3c90d985b --no-merges --oneline
2019-08-09<EMAIL_ADDRESS>Roll fuchsia/sdk/core/linux-amd64 from 9xVXx... to HsuAH... (flutter/engine#10806)
2019-08-09<EMAIL_ADDRESS>Roll src/third_party/dart 3d9a356f6e..78ce916d82 (7 commits)
2019-08-09<EMAIL_ADDRESS>Roll src/third_party/skia b2151310068b..26cedb4c603b (1 commits) (flutter/engine#10804)
2019-08-09<EMAIL_ADDRESS>Roll src/third_party/skia 059bf776c184..b2151310068b (3 commits) (flutter/engine#10803)
2019-08-09<EMAIL_ADDRESS>Roll src/third_party/dart f29f41f1a5..3d9a356f6e (65 commits)
2019-08-09<EMAIL_ADDRESS>Roll src/third_party/skia 4d557e3df433..059bf776c184 (1 commits) (flutter/engine#10801)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (jimgraham@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/5553800725659648

Commit queue failed; closing this roll.


Quilt Tooltip API

The Quilt Tooltip API is a brand new module in the gui library, its main focus is, well... tooltips!
This PR mainly focuses on the TooltipData/TooltipComponent-related APIs, which to remind everyone this is what the bundle item uses for its fancy tooltip render, other mods have found uses too.
The main issue in Vanilla is TooltipData has no "unhardcoded" conversion mechanism to TooltipComponent, the only way to convert is by mixining TooltipComponent#of, which is rather not practical, historically it was worse with interface mixins being disallowed.
This API introduces 2 new additions:

TooltipComponentCallback, a straight port of Fabric API's one, use an event-based approach.
ConvertibleTooltipData which is an extended TooltipData interface which adds a client-only method to convert it to a TooltipComponent. Be careful with it since anyone implementing it must use the environment annotation to avoid crashes, this is mentioned heavily in the javadoc. This interface is implemented through the event mentioned earlier, thus it uses the quilt_tooltip:convertible_tooltip_data phase which runs before the quilt:default phase (which is the default phase for any registered event listener), thus allowing easy overriding through the use of events.

Maybe add a test for the tooltip callback, otherwise fine

The test is already there.


Trust: issue reporter does not mention trust

When I report an issue from our issue reporter from an untrusted workspace, there is no info about this in the GH issue.

Marking as important to make sure we care about this before enabling trust by default.

Two examples:
https://github.com/microsoft/vscode/issues/125533
https://github.com/microsoft/vscode/issues/125535
in an effort to make the smallest change this late in the game, I’ve put it in System Info however when you report a performance issue, we also have a section called “Workspace Info” that shows up that gives details on the workspace (like number of files, etc). I think it should eventually go there

lol jk @sbatten sent a PR putting it next to the OS which I don't love... but the change is small and it means the user can't not tell us their WT situation which is good.


Alternate schedule times can't be saved unless they're in the top row

Version: v0.8.4-beta-win-x64
I'm trying to set up a channel with two schedules, one for Sun-Thu and one for Fri and Sat. I create the second schedule in my channel's alternate schedules page, but only the top row will save the custom days/months, with the lower rows reverting to *any* after I click "Save Changes" and check again. If the rows are reordered, the new top one will be allowed to be saved but the new lower ones will be wiped back to *any*.
Interestingly and possibly relatedly, if there's only one row, it also can't be saved and reverts to *any*, but that's more intuitive to me since if there's only one schedule it should be playing all the time!

This is by design - the list is prioritized from top to bottom, so the bottom row will always match all days, ensuring each day of the year will have a schedule. You can just pick one to assign to specific days in the top row, and leave the other one matching everything in the bottom.
ETV checks from top to bottom and uses the first row that matches the day that it needs to schedule.

Thank you for explaining that! So it seems like my use case should be:
Line 1: Fri, Sat
Line 2: All days

Where Friday and Saturday would match on the first line and thus never "fall through" to the second, catch-all line.


One Bulb Working

One Bulb Works Perfectly while the other 14 don’t and they’re all the same brand and firmware.  Any ideas?

I have no idea.
What is the log? disconnected?

For example LR Lamp R works beautifully whereas LR Lamp L never works nor do the others.  See attached screenshot.  I'm not sure what the red errors are.
Tuya Connector Management.pdf

Only thing I noticed is that under SmartThings IDE Home Location Devices, the working lamp lists data for CURRENT STATE whereas the other devices have no data under CURRENT STATE.  No idea why.

Sorry I have no idea..
I just use a this tuya library.
https://github.com/codetheweb/tuyapi

@jkessle2 Have you tried using tuya-cli?


[Test](index compaction) refine index compaction case

What problem does this PR solve?

Related PR: #41625
Problem Summary:
Refine case of index compaction, DO NOT need so much data.
Check List (For Committer)

Test

[x] Regression test
[ ] Unit Test
[ ] Manual test (add detailed scripts or steps below)
[ ] No need to test or manual test. Explain why:

[ ] This is a refactor/code format and no logic has been changed.
[ ] Previous test can cover this change.
[ ] No colde files have been changed.
[ ] Other reason

Behavior changed:

[x] No.
[ ] Yes.

Does this need documentation?

[x] No.
[ ] Yes.

Release note

None

Check List (For Reviewer who merge this PR)

[ ] Confirm the release note
[ ] Confirm test cases
[ ] Confirm document
[ ] Add branch pick label

run buildall


Stellar - There should be a trustline to TFT

[x] Implement a trustline to TFT to link the currency to an account
[x] Ensure there are fallbacks

implementet with fallback in 2.0.0


Will there be pause options and other user control buttons for Odyssey slide shows?

Give user option to pause/control slideshow progression

Related with the one with the controls. Marked as duplicated and creating a new one for the pause button. Thanks!