Open Bug 1826311 Opened 3 years ago Updated 1 year ago

Print Dialog: Add support for the Common Print Dialog Backends (CPDB)

Categories

(Core :: Printing: Setup, enhancement, P3)

Product:
Core
Component:
Printing: Setup
Type:
enhancement

Tracking

()

People

(Reporter: till.kamppeter, Unassigned, Mentored, NeedInfo)

Details

Attachments

(4 files)

Sidebar in print preview
58.24 KB, image/png
Details
WIP: Bug 1826311:- Add CPDB support to Print Dialog
48 bytes, text/x-phabricator-request
Details | Review
WIP: Bug 1826311:- Add CPDB support to Print Dialog
48 bytes, text/x-phabricator-request
Details | Review
WIP: Bug 1826311:- Add CPDB support to Print Dialog
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

I am Till Kamppeter, leader of OpenPrinting and so responsible for the printing infrastructure in Linux and other Posix-style operating systems.

https://openprinting.github.io/about-us/

Firefox and Thunderbird (probably all Mozilla applications on the Linux desktop) are under the few applications which have their own print dialog, and do not use one of the desktop environment toolkit's (GTK/Qt) ones primarily (AFAIR one can use the GTK one optionally, via a link/button in Mozilla's print dialog). Here a change is needed to assure smooth and easy printing in the future.

Now, after 22 years of CUPS with PPD files and print filter executables as printer drivers we have a change in the print architecture. The use of PPD files gets abolished in CUPS and CUPS will go all-IPP, due to the fact that modern printers are driverless IPP printers, which tell everything about their capabilities to the clients via IPP (so do not need PPDs) and use standard file formats for print jobs (and so do not need driver filters). This requires changes in print dialogs.

https://openprinting.github.io/current/#the-new-architecture-for-printing-and-scanning

As this is most probably not the last major change needed and also for print dialogs to support other print technologies than CUPS, for example cloud printing services, I have created already 5 years ago, the concept of the Common Print Dialog Backends (CPDB):

https://openprinting.github.io/achievements/#common-print-dialog-backends

Here the print dialog does not talk directly with the print technology (like CUPS) but there are GUI-toolkit-independent backends, usually maintained by the maintainer/developer of the print technology (OpenPrinting for CUPS and for print-to-file). This way the maintainer of the print technology, when they change something, they also change the backend appropriately and all print dialogs immediately work with the change. And if someone introduces a cloud printing service, they simply put the backend for it into the Snap Store and once installed the user can use the service from any print dialog.

Now, with the upcoming New Architecture for printing and scanning there was a need of change on all print dialogs and I decided to finally get CPDB be used in all print dialogs, and found a great, enthusiastic GSoC (2022) contributor for it. He implemented the support in both GTK and Qt dialogs and succeeded to get the merge request on the GTK one accepted upstream.

https://github.com/TinyTrebuchet/gsoc22/
https://openprinting.github.io/OpenPrinting-News-February-2023/#common-print-dialog-backends-support-accepted-into-gtk

For this he did not only work on GTK and Qt code but also on the development of CPDB, creating a second generation with much more functionality:
https://openprinting.github.io/Common-Print-Dialog-Backends-Second-Generation-First-Beta-Release/

My Feature Request now is to get CPDB support into the print dialog of Mozilla, so that users of Firefox, Thunderbird, and other Mozilla applications will be able to continue to easily print also after the transition to CUPS 3.x (or to the CUPS Snap, which also does not support classic CUPS drivers/PPD files) and also print with any upcoming cloud printing technology right out of the print functionality of the Mozilla applications.

If the choice of "Core" for the product and "Printing: Setup" for the component is wrong, please correct.

I can also help with the implementation as I have a contributor who would do the coding, he only needs somone mentoring/guiding him to do the code contribution to Mozilla correctly.

I'd be happy to mentor fwiw. Another potential approach here is using the print portal here, right? But IIRC last we checked that wasn't flexible enough, so we had to enable cups access instead and use our cups back-end (bug 1712555).

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Mentor: emilio

Till, I'm the Eng Mgr for the Layout Team. Let me gather my experts on this and give you some feedback on whether this is something we are willing and able to pursue.

Flags: needinfo?(jwatt)
Flags: needinfo?(emcdonough)

I'm definitely not against this idea. CUPS has been a lot of trouble to integrate and actually have work well with many printers.

One thing I'll note is that we do have tentative plans (or just ideas for the future) to implement our own IPP backend rather than using the CUPS client library at some point.

We've found that CUPS can be difficult to deal with in an application like Firefox: it often requires us to craft our own IPP requests to determine printer details, its threading model requires extra work to integrate and requires extra work to use in a thread-safe manner within Gecko, and its HTTP library and scheduler duplicates a lot of functionality already present in Gecko.

I would hope that this would reduce the first kind of work (having to drop down to IPP requests directly), but I worry it would be just as much trouble as CUPS (or more) to make it work nicely with Firefox's threading and multiprocess architecture.

It also seems like many Linux systems aren't even on CUPS 2 yet, so this would at best live alongside a CUPS (or our own IPP code) for quite some time. This seems to be in a better situation for BSD systems, at least.

Sorry for the late answer I was busy the last days, especially with the Linux App Summit 2023 in Brno, Czech Republic.

First, portals. like xdg-desktop-portal are not the ultimative solution as, AFAIK, they are only available in sandboxed packaging, Flatpak and Snap, distros who stay with their classic packaging, like Debian or RPM, for Firefox and Thunderbird will not have a portal for these available.

The Common Print Dialog Backends do not only make print technology support exchangeable and addable and move responsibility on printing technology support to the maintainers of the print technologies, but also de-couple the libcups use from the application. I do not know whether the threading behavior of the CPDB libraries is actually better, but at OpenPrinting we are open to still needed functions if needed.

Are there really still distros using CUPS 1.x? I assumed that at least desktop Linux distributions all use CUPS 2.x. CUPS 3.x is actually not completed yet. But even without CUPS 3.x, CUPS 2.x for example has the concept of temporary queues for IPP print services, and with CPDB these get displayed. Generally the current CPDB backend for CUPS supports both CUPS 2.x and CUPS 3.x.

Hi, Till!

Trying to make sure I understand what's being requested here. Firefox (and Thunderbird) both have a non-native cross-platform print preview UI that it offers to users when initiating a print. Within that UI, there is a link to "Print using the system dialog" (see the attached screenshot).

Clicking that opens up a native print dialog (which on the Linux platform tries to do this with Gtk).

Am I to understand that this system dialog is the one that you'd like to be configurable via CPDB?

Flags: needinfo?(till.kamppeter)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jwatt, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(till.kamppeter) → needinfo?(jwatt)

Sorry for the late answer, seems that I did not get a notification.

The system print dialog which you get by the link, meaning for Linux the GTK dialog is already supporting CPDB, from on current GTK 4.

What I also like to have CPDB on are all the application's native dialogs in Linux (and generally Posix-style operating systems). There are not many, most apps use the dialogs of GNOME/GTK and KDE/Qt, which are taken care of, to my knowledge the apps with their own dialogs are Chromium Browser, LibreOffice, and Mozilla (Firefox/Thunderbird). We want them all use CPDB so that if there is a significant change in CUPS, like currently the New Architecture which goes all IPP and abolishes classic drivers with PPD files, we at OpenPrinting update the CPDB backend for CUPS along with CUPS and that way assure that the desktop print dialogs are immediately working with the new CUPS, and if somebody introduces a cloud printing service, they only need to publish a CPDB backend and the service gets available in all the print dialogs. So the responsibility of the print dialogs supporting each print system correctly gets delegated to the developers of each print system, who also develop the corresponding CPDB backend.

So for Mozilla this means that with this bug report I request the feature of adding CPDB support to Mozilla's own print dialog, the one with the preview, which you are showing in the picture.

CPDB does not need to support previews for that, the preview continues to be generated by the dialog itself. CPDB provides access to the list of available printers, the capabilities and user-settable options of each printer, and an interface to send off the jobs to the desired printers, and that all in a way independent of the actual printing system being used (CUPS, a cloud printing service, ...). So on the following operations of your dialog you do not use the CUPS (libcups) functionality any more, but instead, the corresponding functionality of CPDB (cpdb-libs):

  • Get a list of all available printers
  • For a selected printer, get a list of all options and available choices for each option
  • For a selected printer, send off a job to the printer

CPDB has also auxiliary functions to obtain human-readable option and choice names, translations, unprintable margins, ...

That is all you need. For the preview you poll the options of the selected printer to get the page size and the fact whether we print in grayscale or color, and in addition, you poll the unprintable margins.

So you should be able to replace all communication with CUPS by communication with CPDB.

Hi, @mconley, we did not hear from you for some time. Is there anything still missing from me? If so, please tell me.

Hi everyone,
I hope this message finds you well. My name is Kushagra Sharma, and I am writing to introduce myself and express my interest in contributing to Mozilla Firefox by adding Common Print Dialog Backends (CPDB) support.

I was a contributor to Google Summer of Code (GSoC) 2023, where I successfully added CPDB support to Chromium. This project is currently under review and has been well-received by the community. My experience working on Chromium has equipped me with a deep understanding of CPDB and its integration into web browsers.

Building on this experience, I am eager to extend CPDB support to Mozilla Firefox. I believe this integration would enhance the printing capabilities of Firefox and provide a more consistent user experience across different platforms.

To get started, I would like to review the current implementation of the print backend in Mozilla Firefox. Could you please guide me on where to find the relevant documentation and codebase? Any pointers or initial guidance would be greatly appreciated.

Thank you for considering my request. I am excited about the possibility of contributing to Mozilla Firefox and look forward to your response.

Let me try to give you a proper response early next week. Thanks!

Flags: needinfo?(emilio)

To get started, I would like to review the current implementation of the print backend in Mozilla Firefox. Could you please guide me on where to find the relevant documentation and codebase? Any pointers or initial guidance would be greatly appreciated.

So, there's a lot that happens before, but when printing a page we basically do a static copy of the document, and create a print job, which eventually ends up in nsPrintJob::DoPrint (here).

By that point we've already created a PrintTarget (like PrintTargetPDF or PrintTargetCG or ...) and received an appropriate nsPrintSettings object from the front-end.

In terms of the print dialog, which might be more interesting for you... The Firefox print dialog is in toolkit/components/printing/content/print.html, and the relevant JS code is print.js, which basically takes care of mapping the dialog into an nsPrintSettings object, and eventually call into gecko for printing.

The code to use the system dialog is here, which eventually gets here, and eventually in a per-platform PrintDialogService::ShowPrintDialog.

So it seems the way we'd proceed here would be to add a pref, and change nsPrintServiceGTK::ShowPrintDialog to do whatever you need to do? Not sure off-hand if you'd need to extend other parts of the codebase, but we can probably work through that as needs arise.

Hopefully that helps? Let me know if that wasn't what you were looking for, or if you need any extra details or what not.

Flags: needinfo?(emilio)

Depending on what you mean by "print backend", you might also need to implement an nsPrinterList https://searchfox.org/mozilla-central/rev/64ddb621a0d3905fc2e3df475517d4163d377b22/widget/nsPrinterListBase.h which is how we enumerate printers and their properties, and where we do most of our CUPS work.

Thank you for providing the resources related to the current print dialog implementation. I have reviewed the documentation and codebase and have a some understanding of the current setup.

To implement CPDB support, the essential tasks involve:

  1. Enumerating the printer list using CPDB APIs.
  2. Fetching and setting printer settings through CPDB APIs.

This approach mirrors the existing CUPS implementation. The primary objective is to replace the CUPS-specific calls with CPDB calls wherever applicable. Additionally, it's crucial to create an environment that checks for the presence of CPDB on the system and defaults to the existing implementation if CPDB is not available.

Could you please assist me with any specific guidance or best practices for making these modifications? Additionally, any tips on integrating this conditional environment setup would be greatly appreciated. Is there any CUPS specific code to do that or any generic interface that contains virtual functions that I can implement using CPDB.

Thank you for your support. I am looking forward to your guidance as I proceed with this contribution.

I found this nsPrinterBase(https://searchfox.org/mozilla-central/source/widget/nsPrinterBase.h) file which contains virtual functions that could be later on implemented as per requirement as I can see this being inherited in nsPrinterCUPS(https://searchfox.org/mozilla-central/source/widget/nsPrinterCUPS.h). I think if we implement a similar file say nsPrinterCPDB and other similar file that are there for CUPS if instead uses CPDB's implementation for those virtual functions then it should work. I would like to hear your opinion on this.

Yeah that sounds like the right approach. The print service might need more tweaks, or we might need some trickier interaction to implement the fallback to CUPS, but that can be worked on some way or another

I have gone through the code for current implementation and I am ready to start implementing CPDB support. Could you share the guide to setup Mozilla so that I can try the changes on local and see if this approach works. Initially I will try to generate temporary dummy print backend that replicates all function calls used for CUPS implementation and later I will use CPDB’s API.

Sure, https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html should have everything you need afaict, but if that's not the case let me know here or in matrix (or in the #introduction channel linked there) so that we can improve the docs.

Thanks!

The above issue was resolved with rebase. Now I am getting another error
" error: could not compile style (lib)
22:48.91 Caused by:
22:49.06 process didn't exit successfully: /home/kushagra/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc --crate-name style --edition=2018 servo/components/style/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C panic=abort -C embed-bitcode=no --cfg 'feature="bindgen"' --cfg 'feature="gecko"' --cfg 'feature="mozbuild"' --cfg 'feature="nsstring"' --cfg 'feature="regex"' --cfg 'feature="serde"' --cfg 'feature="toml"' -C metadata=3cb9ac7ad48d2731 -C extra-filename=-3cb9ac7ad48d2731 --out-dir /home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -C linker=/home/kushagra/mozilla/mozilla-central/build/cargo-linker -C incremental=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/incremental -C strip=debuginfo -L dependency=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps -L dependency=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/release/deps --extern app_units=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libapp_units-2e579aefc490bc6e.rmeta --extern arrayvec=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libarrayvec-238f85d25730f4d9.rmeta --extern atomic_refcell=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libatomic_refcell-1c64de21f7f51c28.rmeta --extern bitflags=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libbitflags-5c8f17ea755d80dd.rmeta --extern byteorder=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libbyteorder-236863020154eaea.rmeta --extern cssparser=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libcssparser-c6028e0524795374.rmeta --extern derive_more=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libderive_more-2bc2a4b098a6150c.rmeta --extern dom=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libdom-38ac49b4fb2c1cbb.rmeta --extern euclid=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libeuclid-2eef71f7fb7bd65e.rmeta --extern fxhash=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libfxhash-e3e3c02cace3aa18.rmeta --extern gecko_profiler=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libgecko_profiler-e4ab83cfe703fea1.rmeta --extern icu_segmenter=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libicu_segmenter-5c0c9298e98cd7ff.rmeta --extern indexmap=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libindexmap-37e1f87940c828dd.rmeta --extern itertools=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libitertools-ac847ad9c6b5733c.rmeta --extern itoa=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libitoa-f4280e5923785a58.rmeta --extern lazy_static=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/liblazy_static-2dbf929ea730edef.rmeta --extern log=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/liblog-57fb28525de4972f.rmeta --extern malloc_size_of=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libmalloc_size_of-a4a84a4d51c59ec8.rmeta --extern malloc_size_of_derive=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/release/deps/libmalloc_size_of_derive-ca32b4681166ef0c.so --extern matches=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libmatches-d6b2669e76003ef5.rmeta --extern debug_unreachable=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libdebug_unreachable-a6223032f01726ac.rmeta --extern nsstring=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libnsstring-f27fa735d17f94ee.rmeta --extern num_derive=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/release/deps/libnum_derive-c8992c77a4a69942.so --extern num_integer=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libnum_integer-3ac1a312f3fde5f6.rmeta --extern num_traits=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libnum_traits-93f3705dba45cf4d.rmeta --extern num_cpus=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libnum_cpus-fe471c487318c415.rmeta --extern parking_lot=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libparking_lot-7964010254814b95.rmeta --extern precomputed_hash=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libprecomputed_hash-ca017028ca776635.rmeta --extern rayon=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/librayon-471b9538604f4b9d.rmeta --extern rayon_core=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/librayon_core-8001d65adb963c9b.rmeta --extern selectors=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libselectors-c27af6eb363ea99e.rmeta --extern serde=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libserde-7852799d0b3b3a42.rmeta --extern servo_arc=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libservo_arc-b20d2deb740f806d.rmeta --extern smallbitvec=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libsmallbitvec-8a1b8b49a5a79197.rmeta --extern smallvec=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libsmallvec-cd9c2299a175b6de.rmeta --extern static_assertions=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libstatic_assertions-38340e47301f353e.rmeta --extern static_prefs=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libstatic_prefs-859f841d9777f98a.rmeta --extern style_derive=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/release/deps/libstyle_derive-1998eaa7de71c016.so --extern style_traits=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libstyle_traits-917d5850e8233f7d.rmeta --extern thin_vec=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libthin_vec-81b092f7dea287ad.rmeta --extern time=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libtime-7590a2a5feca0682.rmeta --extern to_shmem=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libto_shmem-d84e744adcf80ae3.rmeta --extern to_shmem_derive=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/release/deps/libto_shmem_derive-ae4770bc34598037.so --extern uluru=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libuluru-ee99021023683d24.rmeta --extern unicode_bidi=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libunicode_bidi-1b14a8d749dd99a6.rmeta --extern void=/home/kushagra/mozilla/mozilla-central/obj-x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu/release/deps/libvoid-f683c21dbb8405c5.rmeta -C debuginfo=2 -C force-frame-pointers=yes --cap-lints warn -Clto=off (signal: 9, SIGKILL: kill)
22:49.06 warning: build failed, waiting for other jobs to finish...

74:38.79 gmake[4]: *** [/home/kushagra/mozilla/mozilla-central/config/makefiles/rust.mk:498: force-cargo-library-build] Error 101
74:38.81 gmake[3]: *** [/home/kushagra/mozilla/mozilla-central/config/recurse.mk:72: toolkit/library/rust/target-objects] Error 2
74:38.85 gmake[3]: *** Waiting for unfinished jobs....
74:48.00 gmake[2]: *** [/home/kushagra/mozilla/mozilla-central/config/recurse.mk:34: compile] Error 2
74:48.30 gmake[1]: *** [/home/kushagra/mozilla/mozilla-central/config/rules.mk:359: default] Error 2
74:48.51 gmake: *** [client.mk:60: build] Error 2
74:48.61 W 125 compiler warnings present.
74:51.60 /usr/bin/notify-send '--app-name=Mozilla Build System' 'Mozilla Build System' 'Build failed'
"

kindly have a look

Hello everyone,
I wanted to know how can I import CPDB (Common Print Dialog Backend) package in mozilla. Can I use pkg-config or is there any other way to import package.

Hi Everyone,
please check the above query for importing CPDB package in Mozilla. Currently I have added a dummy print back-end that implements all the virtual functions of base class and I have assigned some hard coded values to the the dummy printer , now I have to import CPDB package and replace the the function calls with CPDB APIs ,I will be adding a code review for current implementation that I have done so far. Looking forward to hear from you

Thanks

Can someone share the steps to push code review. i am trying to push the code review using moz-phab but I am not able to submit mu patch. It seems like I am having issue with rights on phabricator.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: