Re: poppler soname bump in Rawhide
Thank you Marek for coordinating the change! Zdenek On 8/22/24 20:56, Marek Kasik wrote: Hi, I've finished the rebuild for Fedora 41 and rebuilt all the packages again for rawhide since there were several packages which have been updated in the meantime. Thank you all for your help Marek On 8/20/24 16:36, Marek Kasik wrote: Hi, On 8/20/24 13:44, Jan Grulich wrote: Hi, út 20. 8. 2024 v 12:30 odesílatel Fabio Valentini napsal: On Mon, Aug 19, 2024 at 4:33 PM Marek Kasik wrote: Hi, I've fixed this issue and rebuilt Inkscape. Unfortunately, I have issues with some other packages due to the unannounced soname bump of re2. qt5-qtwebengine needs to be rebuilt due to that but it fails. I watch the https://src.fedoraproject.org/rpms/qt5-qtwebengine/pull-request/18#request_diff and I'm trying to fix the issue with undefined references. I think the issue with undefined references on aarch64 should be fixed? I have already fixed the undefined reference (at least on paper as the build didn't finish yet). The reason for this is that qt5-qtwebengine copies over re2 header files, but that doesn't mean it links against the system version, it still uses the bundled one anyway. There has been an API change in some of the functions in re2 and that's the reason for undefined reference. I'm now fixing qt5-qtwebengine to use Python3 to make it build in Rawhide and I'll do the rebuild against poppler once I finish that. Thank you very much for fixing that! I'll try to build the rest of the packages dependent on poppler tomorrow. Jan Marek -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
PWG+OpenPrinting meetup 2024
Hi all, I've joined the mentioned meetup to see what are the changes from the last year and proposal what to do in the future. Highlights: - CUPS 2.5 on the way, only requirement which is left if OAuth2 support, targeting autumn this year, - one of GSOC 2024 projects is to implement support and distribute OpenPrinting projects as OCI containers, - one of GSOC 2024 projects is to update system-config-printer to work with CUPS 3.x series, where libcups is available as beta. The detailed notes from the talks are attached. Have a nice day, Zdenek -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC PWG/OpenPrinting f2f meetup 2024 OpenPrinting Plenary - 4 out of 6 GSOC passed - OpenPrinting CUPS - release 2.4.8 - libcups3 - 3.0b2 - CUPS Snap uses latest tag from CUPS upstream - cups-filters - 2.0.0 - retrofitting printer apps - added release numbering schemes for snaps - ps-printer-app (20240209-5 based on foomatic) - gs-printer-app - based on gs 10.03.0 - hplip-printer-app - 3.22.10-8 - cpdb - snap support, GTK support merged, Qt+Chromium before merged, mozilla and libreoffice support part for GSOC 2024 - cpdb-backend-file is discontinued - desktop integration - print dialogs covered by cpdb support, gnome-control-center by GSOC 2023 and GSOC 2024, kde-print-manager, system-config-printer GSoC 2024 - Ubuntu requires all desktops and GUI apps to be ready for CUPS 3.x - distribution methods upstream - snap + OCI - OCI part of GSoC 2024 GSOC 2023 and 2024 -- - cpdb for firefox, chromium, libreoffice, sandboxced scanner app framework, listing of IPP services in gnome-control-center, testing for libcupsfilters, libppd, cpdb, libpappl-retrofit - passed - failed - new functionality for libcupsfilters regarding IPP Everywhere 2.0, and native gutenprint printer app - GSOC 2024: - pappl api bridging for scanner apps, - CUPS and printer apps for OCI images,m - cpdb for libreoffice - cpdb for Mozilla - upgrade for system-config-printer to CUPS 3.0/driverless printing - native gutenprint printer app - user interfaces for OAuth2 with imaging devices (printer/scanners) - gnome-control-center and CUPS 3.x finalizing - convert braille to printer app - qpdf -> pdfio replacement in libcupsfilters - fuzz testing for C components - GSOC 2023/2024 - Akarshan Kapoor - pappl scanning support - arch: - client which does escl or can emulate escl for non-escl devices - framework for writing the client - mopria escl endpoints - /eSCL/ScannerCapabilities, /eSCL/ScanJobs, - dummy druiver emulation files for emulating non-ESCL models - ScannerCapabilities, ScannerStatus, ScannerBufferInfo - xml parser - eSCL protocol is basically in XML format, so it needs to be parsed - created SANE driver from PAPPL retrofit project - for GSOC 2024 - struct in PAPPL for scanners, updating dns-sd registration to include both printers and scanners CUPS Plenary - CUPS 2.4.8/ CUPS 2.5b1 - June/July 2024?, gold release in August/September 2024 - DONE: - wide area DNS-SD lookups and printer profiles (some minor things to be done), - locale improvements for multiple langs in IPP Everywhere PPDs (based on what printer supports - dynamically changes the lang), - X509 cert management, - backporting some CUPS 3.0 API, - job-sheet-col support - banner pages on different media types - TBD: - OAuth2/OpenID support OAuth2/OpenID: - replacement for kerberos - many implementations like moauth from Mike - public cli tool and web interface popup window to be implemented - libcups 3.0.0 - August/September 2024 - cups-local 3.0.0 - February/March 2025 - cups-sharing 3.0.0 - April/May 2025 Future: - pappl moved into CUPS servers dependencies - libcups - requirements for C99, DNS-SD (Avahi, mdnsresponder - RFE for systemd-resolved), TLS (gnutls, libressl, openssl), zlib, posix threading, removing of old API functions, new API for JSON, HTML form, JWT and X509 API - see MIGRATING.md document at the project - installable together with libcups 2.x - cups-local - discovery, comm with printers, handles authentication, authorization, consent and notfi UI - runs as user, has domain socket - we can present UI, can log remotely - previously problematic with IPP backend - job history limited to current login - no web interface - conversions to PDF/raster - printer profiles for non-DNS-SD printers/servers - UNIX domain socket and dbus APIs - cups-sharing: - sharing over internet sockets - web interface - authorization/consent/notif ui - Accounting, ACL - full enterprise solution with sharing server - user sends job with files and then choose files to print on the server, give consent and gets it printed - OAuth JWT inspections Printer applications - pappl - CUPS based C framework for printer apps - jpeg, png, pwg raste
Re: Current status of OSTree and its handling RPM scriptlets?
Hi Jonathan! On 2/13/24 16:47, Jonathan Lebon wrote: Has it got fixed during the time? Or is there a new technology which would do the trick for Silverblue and Fedora Linux alike? Just a note: I would say "for Silverblue and traditional systems alike" instead. Silverblue is part of Fedora Linux. :) Ok, I thought there are Fedora Linux, Fedora Silverblue and Fedora CoreOS (maybe others :) ). Thanks! The common way to make "image-mode friendly" system state changes is to e.g. use a systemd service Do you have an example of such systemd service? I could see that a shell script can be started by systemd unit to do the migration, but that would have to be run in %post scriptlet again AFAIK - unless you would require machine restart (and the service is run during reboot) or manual service start... tmpfiles.d won't work for me, I have to make changes in /usr/bin :( - looks like it designed for temp/volatile files. or a tmpfiles.d dropin or to bake the migration into the application itself (all these would of course work across OSTree and non-OSTree based variants). Specifically for alternatives, see also https://github.com/fedora-sysv/chkconfig/issues/9 which calls for changing how it's implemented to be more compatible with image-based updates. Specifically for your issue though, it's not clear to me how much it's worth supporting this. Do they also have a way to prevent `sudo vi` from e.g. creating/modifying a systemd unit that can run arbitrary code? :) Thank you in advance! Hope that helps! -- ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Current status of OSTree and its handling RPM scriptlets?
Hi all, there was an issue (either due a bug or due design) in the past about RPM OSTree treating %post scriptlets in SPEC file differently than on Fedora Linux - IIUC the explanation was %post scriptlets were applied on the server side of the system with RPM OSTree, thus any configuration changes like switching symlinks with alternatives were not applied/usable for normal user. Has it got fixed during the time? Or is there a new technology which would do the trick for Silverblue and Fedora Linux alike? Because there is a user which was used to setting NOEXEC on /usr/bin/vi to prevent running shell from vi as a root when using 'sudo vi' - since the /usr/bin/vi is shell script now and uses exec to spawn the correct binary, NOEXEC flags breaks 'sudo vi' completely. The only possible solution here I see is to use alternatives in %post scriptlet, but if the situation is the same, the functionality brought by alternatives (automatic switch from vi -> vim and back if vim-enhanced is installed without shell restart) won't work in OSTree. Thank you in advance! Zdenek -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Opportunity Open Source - OpenPrinting track
Hi all, I've joined virtually the Opportunity Open Source conference at IIT Mandi, India, where we as OpenPrinting held track about the recent events in our group. Brief summary: - current CUPS 2.4.x works with classic drivers and printer applications, as whole 2.x series will - Till works on finishing common-print-dialog-backends into Ubuntu, so GTK4 applications can use unified print dialog with the latest features - CUPS 2.5 is held until we have OAuth support (aimed at the end of this year) - I will be releasing 2.4.x until CUPS 2.5 gold release - soon there will be 2.4.7 with several bug fixes. - looking for help with desktop integration and feature implementation Complete notes are attached. Zdenek -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC Opportunity open source - now we work with printer apps and classic drivers - classic drivers will be removed in CUPS 3 - 2.4 Zdenek Dohnal released manager, 2.5 Till Kamppeter - delayed for OAuth - 2.5: - getting rid of some deprecated functions (windows sspi tls implementation switched for LibreSSL) - new requirements - C99 standrad, DNS-SD (Avahi/mDNSResponder), TLS (Gnutls, LibreSSL), ZLIB, POSIX/Win threading - for discovery: - wide-area DNS-SD for Avahi needs to implemented - config profiles needs to be implemented - localization improvements - OAuth/OpenID - lot of desktop work - API, UI - job-sheets-col - (I want to print certain banner onto specific media - classified banner on blue paper) - backporting CUPS 3 things: - better media-col suppport - cups_media_t - HTML/Rest/JSON/JWT apis - IPP file API (file of IPP attributes which you can use for printer configuration) - profiles - directory with file with plain text files of printers which want to see (~/.cups, ~/.config, /etc/cups/profiles) - directives - Server/ServerName/Printer, filtering options (by location name, geo location, type) - OAuth/OpenID - replacement for kerberos, because it does not uphold security standards and win moves away from it - OAuth does not need root to access the ticket or user changing - 2.5 with OAuth and Kerberos, CUPS 3.0 removes Kerberos - OpenID needed JSON and JWT - basically adding support for RFC 8414/OpenID - we need to cache bearer and refresh tokens per user/auth-server in cupsd once this is implemented - once we have this we need Authorization UI and CLI tool for authentication - CUPS 3.0 - Mike Sweet release manager - libcups is now in the first beta, cups-sharing, cups-local in next year - cups-commands will be split into cups-local and cups-sharing - modular CUPS - library and two type of daemons - sharing, local - modules: - libcups: - ippeverinter, ippevepcl, ippeveps, ippfind, ipptool, ipptransform (for transformations, use in ippeveprinter), libcups (see changes in MIGRATING.md) - removed deprecated APIs - bumped SONAME - local: - cancel, lp, lpq, lpr, lpstat, cups-locald - temporary queues+profiles - runs as user - CUPS 2.x UNIX domain socket, DBUS API, XPC API - barely started - handling auth and notif UI - no web interface - job history for current login - convertion to/grom PDF/raster as printer wants - sharing: - cupsaccept, cupsdisable, cupsenable, cupsreject, lpadmin, cups-sharingd - for SecurePrint, load balancing, OAuth, ACLs, print accounting - config similar to current cupsd - only network sockets - web interface, printers, jobs - challenges - broader scope - lot of work on UI - uplifting GNOME/KDE/XFCE for new D-BUS API for printing auth, consent UI - common-print-dialog-backends - hopefully we can reuse some of PAPPL, reuse of authorization/notification UI from somewhere - bad Ghostscript license complicates PDF conversions with using its API (so we still need call it as binary) - maybe PDFium from Chrome can fix this Desktop integration of the new architecture === - common print dialog backends now have support in GTK4, working on QT, Firefox - for non-gnome desktop - update system-config-printer or get printer module from gnome-control-center and make it generic for all desktops (from current Gnome Control Center, GNOME is going to move to a new library which is not compatible with non-Gnome desktops) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On 8/7/23 12:38, Pavel Březina wrote: IIUC, when 2228533 is resolved, I should switch from mdns[-|4|6]_minimal to mdns[-|4|6] and otherwise keep it as is? Yes. The order of the modules should be also kept: Current order is: hosts: files myhostname libvirt libvirt_guest mdns_minimal|mdns4_minimal|mdns6_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns I wouldn't play with the order, because I don't understand it perfectly to make such decisions, so yes, keep the order as it is. Thanks, Pavel But I'm not a nss-mdns or avahi maintainer, just a maintainer of stacks which use mdns often - printing and scanning. I've got this opinion from issues in past, by checking nss-mdns code and by intention of minimizing of new work in authselect, unless it is necessary. Zdenek Yes, I admit current way of providing different plugins instead of one plugin with related configuration is unfortunate. Because it depends on avahi-daemon anyway, I hope it can be reduced to single plugin, where every customization can be done on side of avahi-daemon. But needs code modifications first, so waiting for a volunteer. -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On 8/1/23 12:41, Petr Menšík wrote: Hi Zdenek, the current logic is: - with-mdns4: mdns4_minimal - with-mdns6: mdns6_minimal - with-mdns4 and with-mdns6? mdns_minimal If I understand your message correctly, you propose to keep this logic but use mdns4/mdns6/mdns instead of minimal and drop support for minimal completely. Is that right? Thank, Pavel No, not at all. We want minimal variants preferred until nss-mdns is changes significantly. Check nss-mdns issue #88 [1]. 1. https://github.com/lathiat/nss-mdns/issues/88 Petr, this issue exists only if mdns.allow exists, so if we don't ship it as I recommend, we don't hit this issue. The file will be created by a user in case he needs to override settings which are against standards, where IMO a delay is tolerable. Thus, the issue is nice to have and should not block using mdns4/mdns6 variants. What I would support is adding a note into README file of nss-mdns, mentioning the delay due the mentioned bug - until it is fixed. So Pavel, I've understood me correctly - use mdns/mdns4/mdns6 instead of minimal variants, because they provide the same functionality as minimal + possibility to override network misconfigurations. And don't use complete 'mdns' by default. But I'm not a nss-mdns or avahi maintainer, just a maintainer of stacks which use mdns often - printing and scanning. I've got this opinion from issues in past, by checking nss-mdns code and by intention of minimizing of new work in authselect, unless it is necessary. Zdenek -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On 8/1/23 12:16, Petr Menšík wrote:
Hi Pavel,
With Avahi upstream maintainer hat on, I would say it still makes
sense to have separate mdns*_minimal and mdns? modules. I would say
mdns (non-minimal) should be rarely needed, because by default it
should be used just for *.local names.
I would expect there can be network setups which aren't according
standards and normal users are not able to change it, so it would be
great to have a way how to setup an override in default configuration
instead of expecting authselect to provide 3 more profile features for
no relevant gain so far I can see it.
I've looked into nss-mdns code about what are differences between full
and _minimal except for mdns.allow support and I found a difference in a
function (_nss_mdns_gethostbyaddr_r()) is only used on FreeBSD,
otherwise they're the same.
If there is not, I don't see an important reason why don't use full
variants (I don't mean full in meaning IPv support, but regarding
not-minimal) - the file won't exist in 99% (rhetorically speaking) of
configurations, so it won't be read and
https://github.com/lathiat/nss-mdns/issues/88 is irrelevant in those cases.
In the cases where it will exist, then there is something against
standards in local network configuration, so IMO a delay is tolerable.
As I have wrote to referenced ticket, I think we want to prefer
mdns_minimal in the future, but it first needs solving increased
timeouts for not present names [1]. As soon as it is solved on
avahi-daemon side, we can deprecate mdns{4,6}_minimal and mdns{4,6}
variants. If only one family should be resolved, I think it would be
better to configure it on side of avahi-daemon.
Since there is no solution for it now, I repeat my previous answer
regarding this - no profile feature in authselect for this, do not set
plain mdns/mdns_minimal as default, if someone wants it, he can enable
it by enabling both --with-mdns4 and --with-mdns6.
I think mdns resolution needs smarter approach from avahi-daemon. It
might be useful to not open and re-parse /etc/mdns.allow on every
single ``getaddrinfo()`` call, but cache it in thread local storage
and re-read its contents only on timestamp change. Maybe with checking
the file stamp only once per second at most.
An alternative approach might be fetching list of wanted domains first
time the process uses mdns plugin from avahi-daemon. And cache it in
thread local storage of the process (with some ttl before refresh).
That would avoid separate mdns?_minimal and mdns? plugins, because the
smartness would be at avahi-daemon. That is required for any
combination anyway. No slowing down unrelated queries after the first
one. I guess that would make browser people happy, because they try
hard to make everything quite fast. Wrote new issue [2] for this idea.
IMO this is nice to have fix, because of reasons above.
So a quick summary. I am afraid all those variants are needed until
some volunteer improves the situation and makes them obsolete. I think
we are not there yet.
I beg to differ here - there is no downside for majority of user by
supporting full variants mdns4/mdns6 in authselect by default instead of
_minimal (if the file won't be shipped by default, which I highly
recommend to not ship to get '_minimal' behavior by default) and IMO it
is tolerable to have a delay for setups which don't follow standards.
AFAIK this solution has the following pros:
- no new profile features for authselect,
- _minimal behavior by default,
- having a way how to override default without changing authselect
settings in case there are discrepancies in network
Cons:
- delay if /etc/mdns.allow exists
Zdenek
Cheers,
Petr
1. https://github.com/lathiat/nss-mdns/issues/83
2. https://github.com/lathiat/nss-mdns/issues/88
On 31. 07. 23 14:47, Pavel Březina wrote:
Hi Fedora,
I have this ticket opened against authselect:
https://github.com/authselect/authselect/issues/334
I am not user of mdns myself, so I wonder if non-minimal version of
mdns is something used and if it should be included in the authselect
profiles (or even replace the minimal version).
mdns support is already complicated since there are mdns, mdns4 and
mdns6 full and minimal versions of the module. Is it really required
nowadays? In might opinion, it might be good to move the logic out of
nsswitch into a configuration file.
Thank you for your feedback,
Pavel.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.i
Re: RFC authselect: mdns or mdns-minimal
On 8/1/23 09:56, Zdenek Dohnal wrote: Fortunately Petr came up with solution for it (now nss-mdns does always mDNS lookup for .local, but if there is DNS SOA for .local and mDNS lookup didn't succeed, moves to DNS), so this scenario doesn't need mdns.allow anymore, but IMO there could be other divergence from standards in the networks, so having the option to use mdns.allow in default configuration is welcome. Of course, the bypassing would be turned off by default (nss-mdns will not ship any /etc/mdns.allow file), so mDNS resolution would have worked according standards by default. User will be expected to create the file and make necessary changes if he needs to. -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
Hi Pavel, since authselect already advertises features for profiles regarding mdns as: --with-mdns4 --with-mdns6 it would be great if the profile feature logically matched what is going to be enabled - --with-mdn4 will put 'mdns4' into 'hosts' in nsswitch.conf instead of current mdns_minimal. AFAIK from Avahi people (pemensik in CC) I wouldn't go for mdns and mdns_minimal, because hostname->IPv6 + hostname->IPv4 address resolutions are currently made in sequence in Avahi, so the getting the result will be unnecessary delayed if one of them is not defined. IIUC nss-mdns README, the main difference between mdns4 and mdns4_minimal is /etc/mdns.allow file support, which can allow bypassing heuristics and allows user to do mDNS queries in conflict to mDNS standard (f.e. standard specifies that only .local or .local. domains can be used for mDNS) - although it would be great if networks were up to the standards, it is not a case in reality. We had this issue https://bugzilla.redhat.com/show_bug.cgi?id=2148500 , where ISP injected DNS server which defined 'local' domain as classic DNS record, breaking mDNS resolution in whole user's environment. Fortunately Petr came up with solution for it (now nss-mdns does always mDNS lookup for .local, but if there is DNS SOA for .local and mDNS lookup didn't succeed, moves to DNS), so this scenario doesn't need mdns.allow anymore, but IMO there could be other divergence from standards in the networks, so having the option to use mdns.allow in default configuration is welcome. So what I would propose: - use mdns4/mdns6 with authselect --with-mdns4 and --with-mdns6 profile features instead of _minimal to honor name logic, - don't use mdns/mdns_minimal - if someone wants to use it, he can enable both features separately, - if someone would like to use mdns4/6_minimal, he can opt-out from authselect and update nsswitch.conf manually. @Adam, @Petr, please let me know if there are other things to consider or disadvantages in this. Zdenek On 7/31/23 14:47, Pavel Březina wrote: Hi Fedora, I have this ticket opened against authselect: https://github.com/authselect/authselect/issues/334 I am not user of mdns myself, so I wonder if non-minimal version of mdns is something used and if it should be included in the authselect profiles (or even replace the minimal version). mdns support is already complicated since there are mdns, mdns4 and mdns6 full and minimal versions of the module. Is it really required nowadays? In might opinion, it might be good to move the logic out of nsswitch into a configuration file. Thank you for your feedback, Pavel. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: PWG+OpenPrinting meetup 2023
Hi Doug, thank you for the info! I've CCed Richard, who maintains pappl - you're right, this will have to be fixed in PAPPL before packaging pappl-retrofit - some with downstream patch, some with spec file changes. Zdenek On 7/4/23 04:12, Douglas Kosovic wrote: Hi Zdenek, Regarding packaging pappl-retrofit and printer applications, looking at the pappl-retrofit based snaps from Till Kamppeter, I suspect the existing Fedora pappl package might need to be modified. For example, extract from ps-printer-app's snapcraft.yaml file which modifies pappl's default build settings: https://github.com/OpenPrinting/ps-printer-app/blob/master/snap/snapcraft.yaml pappl: ... override-build: | set -eux # Raise the supported number of vendor-specific options/attributes in # PAPPL to 256, as the original 32 can be too small for some busy PPD # files perl -p -i -e 's/(define\s+PAPPL_MAX_VENDOR\s+)32/\1 256/' pappl/printer.h # De-activate log-rotating. It does not work with the forked processes # of the filters perl -p -i -e 's/(system->logmaxsize\s+=).*/\1 0;/' pappl/system.c # As we do not use PAPPL's own backends but the CUPS backends using the # "cups" device scheme of pappl-retrofit, we let the manual "Network # Printer" device on the "Add Printer" page of the web interface use a # "cups:socket://..." URI instead of simply "socket://..." perl -p -i -e 's/(httpAssembleURI\(.*?)"socket"(.*?\))/\1"cups:socket"\2/' pappl/system-webif.c # PAPPL's build system does not insert the LDFLAGS when linking. # Patching Makedefs.in to fix this perl -p -i -e 's/^(\s*DSOFLAGS\s*=\s*\S*\s+)/\1\$\(LDFLAGS\) /' Makedefs.in Cheers, Doug -Original Message- From: Zdenek Dohnal Sent: Thursday, May 18, 2023 4:26 AM To: Development discussions related to Fedora Subject: PWG+OpenPrinting meetup 2023 Hi all, I've joined annual PWG+OpenPrinting virtual meetup where the news and statuses from the current printing development are discussed. The main points are: - cups-filters 2.0 betas and release candidates are released and present in Fedora 38 - since new cups-filters are in Fedora 38, nothing stands in the way of packaging pappl-retrofit and printer applications based on it into Fedora as RPMs - any volunteers are welcome! - CUPS 2.4.x, CUPS 2.5 and CUPS 3.0 are delayed: - 2.4.x - there are several regressions I haven't able to tackle yet, but I hope there is a new version in a month - 2.5 - OAuth support took lot of time to implement - 3.0 - libcups (its version 3.0) has a beta which developers which uses libcups 2.0 can compile and link their applications and see what changed between major release - GTK (its version 4) has merged support for Common Print Dialog Backends - universal print dialog, which can work not only with cups, but with other possible backends (like google cloud print) - WIP on Printer Setup Tool for GNOME Control Center - full support for driverless printers and printers via printer applications The full report is attached. Zdenek -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
PWG+OpenPrinting meetup 2023
Hi all, I've joined annual PWG+OpenPrinting virtual meetup where the news and statuses from the current printing development are discussed. The main points are: - cups-filters 2.0 betas and release candidates are released and present in Fedora 38 - since new cups-filters are in Fedora 38, nothing stands in the way of packaging pappl-retrofit and printer applications based on it into Fedora as RPMs - any volunteers are welcome! - CUPS 2.4.x, CUPS 2.5 and CUPS 3.0 are delayed: - 2.4.x - there are several regressions I haven't able to tackle yet, but I hope there is a new version in a month - 2.5 - OAuth support took lot of time to implement - 3.0 - libcups (its version 3.0) has a beta which developers which uses libcups 2.0 can compile and link their applications and see what changed between major release - GTK (its version 4) has merged support for Common Print Dialog Backends - universal print dialog, which can work not only with cups, but with other possible backends (like google cloud print) - WIP on Printer Setup Tool for GNOME Control Center - full support for driverless printers and printers via printer applications The full report is attached. Zdenek -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC PWG 2023 PWG Plenary === - now we are accepting only IPP Everywhere 1.1 certifications (no 1.0) - IPP group - approved IPP Job Extensions 2.1, IPP Production Printing Extensions 2.0, IPP Driver replacement extensions 2.0 - pending IANA registrations for standard names for medias - development - IPP OAuth 1.0, IPP Enterprise printing extensions 2.0, IPP Encrypted jobs and documents 1.0, IPP Eve 2.0, IPP Everywhere SelfCert manual 2.0 - Liaisons - OpenPrinting - NEW: Mopria as liason to PWG (via Anthony Suarez from Kyocera) - open to collaboration - 3MF Consortium - Mike Sweet is PWG liaison to 3MF - 3D related work - America Makes & ANSI Additive Manufacturing Standardization Collaborative (AMSC) - liaison for 3D printing OpenPrinting Plenary - Linux servers takes 39% of market share - Android went down by 3% of market share on mobiles - distrowatch about Linux distro popularity - Fedora went up :) - works on CUPS, cups-filters, PAPPL, and various printer apps, ipp-usb (Google Chrome has its own daemon written in Rust), driverless scanning - results of GSOC 2022 - almost all passed, one partially failed - highlights 2023 - cups-filters 2.0rc1 released, pappl 1.3.2, GTK (only GTK4) and QT Common print dialog backends are on the way (GTK4 part is in upstream already) - gutenprint printer app is on the way to being native printer application, hplip native printer application waits on scanning support in PAPPL (and then ask HP to write it) - plans - CUPS dev and evolutions, cups-filters 2.0 dev and evolution, GSOC implementation of PWG IPP specs, Driverless printing+scanning development - Linux Plumbers now conflicts with PWG meetup this year - so trying to get into Open Source Summit (ticket 800$ in September) or only a virtual meetup with Canonical infra - probably only virtual meetup GSOC Projects = 2022: GUI for discovering non-driverless printers and finding suitable Printer Applications - Mohit Verma - worked with Marek Kasik on integration to GNOME Control Center CPDB (common print dialog backends) support to existing print dialogs - Gaurav Guleria - worked with Marek Kasik as well on CPDB integration to GTK4 Scanning support in PAPPL with eSCL Converting Braille driver into printer application 2023: CPDB support for Firefox, Chromium, Libreoffice Sand Boxed Scanner application Framework GNOME Control Center - list and handle IPP services CI for our packages Adding IPP Everywhere 2.x functionality to libcupsfilters and CPDB Native Gutenprint Printer application CUPS Plenary - 26 years old now :) - CUPS 2.4.x - in one month new release - CUPS 2.5 - discovery improvements, conf profiles, cert improvements, JWT and JSON for OAuth and OAuth support as additional auth in 2.5, and replace Kerberos in 3.0 - we will need to create auth UI - may use OAuth implementation from Mike - moauth - new arch CUPS 3.0: - commands - local server - discovery, AAA, notifications, conversions, job history to thte current session - sharing server - web interfaces, AAA, infrastructre printer support, OAuth token introspection - tools - ippeveprinter, ippfind, ipptool, ipptransform - libcups - new beta on the way, based on C99 standard, new hard requirements on mDNS, TLS, ZLIB and POSIX threading - new API - IPP test file, HTML form (parsing), JSON (parsing), JWT (parsing) and X509 APIs - 3.0 challenges - we need more desktop support - support for CUPS dBUS API for printing, authorization, consent UIs in various desktops, Auth+Notification UIs - graphical libraries and its incompatible licenses... - so we mostly raste
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
On 1/16/23 12:31, Björn Persson wrote: Robert Marcano via devel wrote: The admin can implement CUPS authentication but an ipp://localhost:6 open port entirely open to anyone on the local machine to submit print jobs directly bypassing CUPS. In that case it's also accessible to all the untrusted Javascript junk that regularly runs in the user's browser. Because IPP is built on HTTP, a Javascript program can tell the browser to send an IPP request. What has been done to secure those "virtual printer devices" against DNS rebinding attacks? https://en.wikipedia.org/wiki/DNS_rebinding I'll ask IPP-USB upstream about it, stay tuned. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
rison to `lpoptions` and `scanimage` outputs (details how to find out device's capabilities in [https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency#Upgrade/compatibility_impact Upgrade/compatibility impact]), report the issue to the application's bugzilla component, * try the actions you usually do on your device (print/scan/fax) with your common options set: :* in case of printers and fax if the printout is not in expected format, do report the issue to `cups` bugzilla component together with additional info (described [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-problems/#_cups_generic_issue here]), :* in case of problem with scanning output do report the issue to `sane-airscan` bugzilla component together with additional info acquired by following steps from this [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-problems/#_debugging_sane_airscan link], * once you disable the device or backend for scanning, check whether one scanner's disappeared from scanner application's dialog (`simple-scan`, `xsane`, `scanimage`) In case user chooses to have classic driver support instead of driverless because driverless support does not work or it misses some options which user requires, it would be great if the user reported such case by filing an issue to `golang-github-openprinting-ipp-usb` bugzilla component, explaining which required options are missing or whether driverless does not print/scan at all and it will reviewed by the component's maintainer. If the model has the driverless support broken in general, the model can be disabled in `ipp-usb` on system level by quirk, which is located in `/usr/share/ipp-usb/quirks`. Once the quirk is set and `ipp-usb` restarted, previously installed printers and scanners will work as before - the printing/scanning/fax will end with error otherwise. == User Experience == A new printer and a new scanner will appear in applications and settings for IPP-over-USB devices by default. Previously installed printer and discovered scanner for the device will stop working and manual intervention is required to remove the broken instances, or to create a quirk for `ipp-usb`. == Dependencies == == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * Printing and scanning [https://docs.fedoraproject.org/en-US/quick-docs/cups-terminology/ terminology] * [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-problems/ Printing] debugging * [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-problems/ Scanning] debugging * [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/ Tips and tricks] * [https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/ Known issues] == Release Notes == Driverless USB printing/scanning/fax support is present by default with printing and scanning packages, providing the support for devices capable of using IPP-over-USB. The manual intervention is required after upgrade, which is described [https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency#Upgrade/compatibility_impact here]. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec - how to add suffix to the current release and don't bump it right now
On 1/3/23 12:19, Zbigniew Jędrzejewski-Szmek wrote: Is this doable with rpmautospec and if it is, how? The desired effect can be implemented by overriding %dist: %global dist %dist~test.0 Release: %autorelease Notice that I used '~' to make the redefined %dist _lower_ than the original. Let's say that the last official build had Release==1. When this spec is built, you end up with Release==2.fc38~test.0. When the %dist override is removed, and the package is built officially, we end up with Release==2.fc38 (2.fc38~test.0 < 2.fc38). Thanks, Zbyszek! That's exactly I was looking for. Zdenek Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
rpmautospec - how to add suffix to the current release and don't bump it right now
Hi all, I would like to ask a question about whether the workflow below, which I use frequently, can be used in packages which uses rpmautospec. I hit this when I was doing a testing scratch build of another package which already switched to rpmautospec and since rpmautospec is now proposed to be default for new packages, I would like to know whether, and if so, how my workflow can be applied with rpmautospec. My workflow: If I have a fix which I want to send to user to verify in its environment, I do a testing build, which has the same release as the current stable package (f.e. 1.fc37), but I add additional suffix to set the testing build to higher NVR than the package in the stable (f.e. 1.fc37.test.1). Then the user can just install the testing packages via DNF, accepting koji links to RPMs, and once an official fixed package arrives (with bumped NVR - 2.fc37), the official stable package replaces the testing one, ensuring the user has the supported rpms. Is this doable with rpmautospec and if it is, how? Thank you in advance! Zdenek -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: zdohnal pushed to tests/vim (main). "upstream-unittests: Apply RPM workaround for package notes from Ruby (..more)"
Thanks, Mamoru!
Looks like a race condition between me and Vita :D
Either way, I've tested whether Vim with Ruby interpreter can be built
without Ruby's LDFLAGS and it worked fine, so I've sent a patch which
removes Ruby's LDFLAGS from Vim. The patch was accepted, so hopefully I
can avoid such errors in Vim in the future even without such workarounds.
Zdenek
On 11/23/22 13:20, Mamoru TASAKA wrote:
notificati...@fedoraproject.org wrote on 2022/11/23 20:34:
Notification time stamped 2022-11-23 11:34:19 UTC
From 1f016e5dedbb5bc7293c1638e1238989d6fabaa5 Mon Sep 17 00:00:00 2001
From: Zdenek Dohnal
Date: Nov 23 2022 11:30:01 +
Subject: upstream-unittests: Apply RPM workaround for package notes
from Ruby
Vim adds Ruby LDFLAGS during configuration, which (due Ruby's decision
to embed flags from the building time) contains flags from buildsystem
environment, especially package notes. This flag expects additional
environment variables to be set and they aren't set in normal
environment.
I've reported it to Vim upstream with PR which removes Ruby LDFLAGS from
configure script https://github.com/vim/vim/pull/11592 .
And ruby (on rawhide for now) removed package_notes again because
currently non-rpmbuild build is broken with embedded package_notes flag:
https://src.fedoraproject.org/rpms/ruby/c/1d0c071aebd50621eb049a2ab8d20da3133f9f16
https://bugzilla.redhat.com/show_bug.cgi?id=2142119
https://bugzilla.redhat.com/show_bug.cgi?id=2043092
Regards,
Mamoru
---
diff --git a/Sanity/upstream-unittests/runtest.sh
b/Sanity/upstream-unittests/runtest.sh
index 1919bd4..6f22812 100755
--- a/Sanity/upstream-unittests/runtest.sh
+++ b/Sanity/upstream-unittests/runtest.sh
@@ -70,6 +70,10 @@ rlJournalStart
rlRun "RUBY_CFLAGS='`ruby -r rbconfig -e "puts
RbConfig::CONFIG['CFLAGS']"`'" 0 "Get ruby CFLAGS"
rlRun "export CFLAGS='$RUBY_CFLAGS'" 0 "Set ruby CFLAGS"
+ # newer redhat-rpm-config brings in packager-notes script,
which breaks LDFLAGS we get from Ruby
+ # we need to set several env variable randomly to get
configure working again...
+ rlRun "RPM_WORKAROUND='RPM_ARCH=\"x86_64\"
RPM_PACKAGE_RELEASE=\"1\" RPM_PACKAGE_VERSION=\"1\"
RPM_PACKAGE_NAME=\"vim\"'"
+
# show relevant info & ENV variables
rlLog "TEST: $TEST"
rlLog "CONFOPT: $CONFOPT"
@@ -85,8 +89,8 @@ rlJournalStart
rlRun "TERM=$TERM_type"
# following block of code is taken from upstream travis.yml
- rlRun "su $TESTER -c './configure ${CONFOPT}
CFLAGS=\"${CFLAGS} $RUBY_FLAGS\"'" 0 "Configure Vim"
- rlRun "su $TESTER -c 'make'" 0 "Build the binary which we
substitute"
+ rlRun "su $TESTER -c './configure ${CONFOPT}
CFLAGS=\"${CFLAGS} $RUBY_FLAGS\" $RPM_WORKAROUND'" 0 "Configure Vim"
+ rlRun "su $TESTER -c '$RPM_WORKAROUND make'" 0 "Build the
binary which we substitute"
rlRun "su $TESTER -c 'ln -sf /usr/bin/vim src/vim'" 0
"Create symlink to installed vim for testing"
rlRun "su $TESTER -c 'make ${TEST} |& tee output'" 0,2 "Run
tests (skip builtin terminal errors)"
_res_=$?
https://src.fedoraproject.org/tests/vim/c/1f016e5dedbb5bc7293c1638e1238989d6fabaa5?branch=main
___
scm-commits mailing list -- scm-comm...@lists.fedoraproject.org
To unsubscribe send an email to
scm-commits-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/scm-comm...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?
Koji devs forwarded me to releng pagure, so there is a new issue for this https://pagure.io/releng/issue/11093 . On 10/14/22 12:57, Zdenek Dohnal wrote: Hi Kevin, I've created the issue https://pagure.io/koji/issue/3554 for the problem. I agree with docs update (maybe it would be nice as well mention the side tag disappears once the packages are in stable, so users don't have to try removing it :) ) and the script update (adding --inactive-delay option, probably set to 21 days?) Thank you for looking into it! Zdenek On 10/11/22 03:16, Kevin Fenzi wrote: got automatically deleted, even when it had builds connected to it already. Documentation [1] does not mention any automatic side-tags cleanup and its deadlines. We should update the docs. We did announce adding this. Although packagers can create a new side tag easily, I found it inconvenient for maintainers, because the synchronization among the maintainers can take weeks to finish the rebuild and release the update and automatic removal without notice (do excuse me if I missed a notification email about this - I have many filters and it could end up somewhere where I wasn't able to find it) prolongs this process. What I would like to propose are the following options: A) don't do side-tag cleanups after a specific time frame, but only when the specific event happens - branching, GA, EOL - it can be consuming to our resources, but maintainer are still able to remove the side tags manually in case it contains a big set of packages and AFAIK the process itself is not such spread in usage... Side tags are actually pretty costly on the server end. It means every single time a build lands in the parent tag they have to have their rpeodata regenerated. It's tons of newRepos. I'd prefer to clean them up as quickly as we can, but no quicker. :) or B) do a side-tags cleanup and mention it in the documentation together with specification what the removal's time frame is, so maintainers can act accordingly We should do this in any case. or C) (my preferred) Koji or releng (depends on whether the cleanup happened automatically or manually) will send an email to a side tag creator with 'Hi, your side tag is going to expire - do you need it?' Or with automaton - 'use this command to prolong it.' And if there is no response or if the creator approves, remove the side tag. Doable, but more notifications and things to deal with. Note that sidetag cleanup has a newer option we aren't using yet too: --inactive-delay=DAYS delete tags inactive for DAYS (no build was un/tagged there) We could perhaps use this. IMO basically side-tag is not expected to exist for such a long time, side-tag requester should take effort to merge it into main buildroot within, say, one week at most. I'm not sure this is always going to be realistic. We are increasingly encouraging folks to do big complicated rebases in side tags rather than breaking Rawhide or Branched for days at a time; sometimes this might take more than a week. I don't want folks to be discouraged from using side tags and just go back to breaking Rawhide because of this kind of cleanup. I agree... I'm open to adjusting the cleanup script, but I do think we should limit sidetags somewhat. We should in any case document and fix the empty thing. kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?
Hi Kevin, I've created the issue https://pagure.io/koji/issue/3554 for the problem. I agree with docs update (maybe it would be nice as well mention the side tag disappears once the packages are in stable, so users don't have to try removing it :) ) and the script update (adding --inactive-delay option, probably set to 21 days?) Thank you for looking into it! Zdenek On 10/11/22 03:16, Kevin Fenzi wrote: got automatically deleted, even when it had builds connected to it already. Documentation [1] does not mention any automatic side-tags cleanup and its deadlines. We should update the docs. We did announce adding this. Although packagers can create a new side tag easily, I found it inconvenient for maintainers, because the synchronization among the maintainers can take weeks to finish the rebuild and release the update and automatic removal without notice (do excuse me if I missed a notification email about this - I have many filters and it could end up somewhere where I wasn't able to find it) prolongs this process. What I would like to propose are the following options: A) don't do side-tag cleanups after a specific time frame, but only when the specific event happens - branching, GA, EOL - it can be consuming to our resources, but maintainer are still able to remove the side tags manually in case it contains a big set of packages and AFAIK the process itself is not such spread in usage... Side tags are actually pretty costly on the server end. It means every single time a build lands in the parent tag they have to have their rpeodata regenerated. It's tons of newRepos. I'd prefer to clean them up as quickly as we can, but no quicker. :) or B) do a side-tags cleanup and mention it in the documentation together with specification what the removal's time frame is, so maintainers can act accordingly We should do this in any case. or C) (my preferred) Koji or releng (depends on whether the cleanup happened automatically or manually) will send an email to a side tag creator with 'Hi, your side tag is going to expire - do you need it?' Or with automaton - 'use this command to prolong it.' And if there is no response or if the creator approves, remove the side tag. Doable, but more notifications and things to deal with. Note that sidetag cleanup has a newer option we aren't using yet too: --inactive-delay=DAYS delete tags inactive for DAYS (no build was un/tagged there) We could perhaps use this. IMO basically side-tag is not expected to exist for such a long time, side-tag requester should take effort to merge it into main buildroot within, say, one week at most. I'm not sure this is always going to be realistic. We are increasingly encouraging folks to do big complicated rebases in side tags rather than breaking Rawhide or Branched for days at a time; sometimes this might take more than a week. I don't want folks to be discouraged from using side tags and just go back to breaking Rawhide because of this kind of cleanup. I agree... I'm open to adjusting the cleanup script, but I do think we should limit sidetags somewhat. We should in any case document and fix the empty thing. kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?
Hi all, I maintain qpdf in Fedora, which recently got a new major release version, which breaks compatibility with other packages, so I created a side tag for other maintainers to use for building, and then releasing it altogether in rawhide. However the side tag: f38-build-side-58658 got automatically deleted, even when it had builds connected to it already. Documentation [1] does not mention any automatic side-tags cleanup and its deadlines. Although packagers can create a new side tag easily, I found it inconvenient for maintainers, because the synchronization among the maintainers can take weeks to finish the rebuild and release the update and automatic removal without notice (do excuse me if I missed a notification email about this - I have many filters and it could end up somewhere where I wasn't able to find it) prolongs this process. What I would like to propose are the following options: A) don't do side-tag cleanups after a specific time frame, but only when the specific event happens - branching, GA, EOL - it can be consuming to our resources, but maintainer are still able to remove the side tags manually in case it contains a big set of packages and AFAIK the process itself is not such spread in usage... or B) do a side-tags cleanup and mention it in the documentation together with specification what the removal's time frame is, so maintainers can act accordingly or C) (my preferred) Koji or releng (depends on whether the cleanup happened automatically or manually) will send an email to a side tag creator with 'Hi, your side tag is going to expire - do you need it?' Or with automaton - 'use this command to prolong it.' And if there is no response or if the creator approves, remove the side tag. WDYT? Zdenek [1] https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenPrinting NEWS from Linux Plumbers 2022 AKA feel free to try driverless printing and printer applications in SNAPs
On 9/15/22 19:01, Vitaly Zaitsev via devel wrote: On 15/09/2022 13:35, Zdenek Dohnal wrote: 1. install snapd No. Thanks. Please build regular RPMs. That's the plan, but it is currently blocked as it is written in the email. However the guts of functionality will be the same (Web UI, sharing over localhost, provided options) as in SNAP, the only difference will be that you don't run snapd, but directly a systemd service for the printer application. IMHO it is much better to find out earlier that your printer does not work/is missing some options when printing via printer application and report it, than later just cry in beer that there wasn't enough time to test. Either way it is wonderful those printer applications are available in some way, since there were complaints that nobody will create printer applications for all packaged printer drivers available in Linux distro repos. Zdenek -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenPrinting NEWS from Linux Plumbers 2022 AKA feel free to try driverless printing and printer applications in SNAPs
' 4. check what options are provided by 'lpoptions -p -l' 5. try to print to the printer via 'lp' command, using the options you frequently use, f.e. $ lp -d -o PageSize=A4 -o Duplex=DuplexNoTumble *IN CASE OF BUGS/MISSING IMPORTANT OPTIONS/OTHER PROBLEMS *- report the issue to the Fedora bugzilla to component *cups *- driverless standards sometimes provide less options than classic drivers, because they focus on common options and many users are not aware of driverless printing and use the classic drivers, so I would like to track such models. 6. try to print to found printer via your favorite viewer or browser - check whether the printer is seen and has all the options shown by 'lpoptions' *IN CASE OF BUGS/BROKEN FUNCTIONALITY/MISSING OPTIONS DURING THIS STEP* - report issues to the component in bugzilla representing *your chosen application* * * *_KNOWN BUGS:_* Several printer configuration tools (GNOME Control Center, system-config-printer at least, I'm not sure about others) is not able to see temporary queues or they're seen as 'ghost printers' and don't communicate with printer applications (by communication I mean their installation based on your printer model and providing the link to the printer application Web UI). GNOME Control Center is working on improving IPP support and adding printer application support right now. Thank you for reading this far and if you are able to test, thank you in advance! Zdenek -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC Open Printing Mini-conference 2022 == CUPS 2.5 and 3.0 development - - 2.4.x and printer applications - manager Zdenek Dohnal - currently on the way for 2.4.3 - color fixes, OpenSSL fixes (cert issues will be fixed soon) - printer apps - check OpenPrinting and michaelrsweet repos at Github - 2.5 and OAuth - Till Kamppeter will be the release manager - QAuth support will be finished there and tested - localization improvements going to happen - first beta in March 2023, GA in May 2023 - OAuth support: - protocol work being done in IPP PWG group - the current 2.4.x has a WIP OAuth implementation, but it is missing internals of OAuth support - we have to implement OAuth callback and Bearer auth method for the cupsd daemon - json tickets being added to libcups project - we need desktop developer for OAuth UI - synch up with GNOME - if they have some OAuth, see if we can use it - do we need a separate project for UI and DBUS service? - coordinate X509/OAuth functionality with CUPS 3.0 development and provide a clear migration path for the functionality - we won't release 2.5 without OAuth support - don't be afraid of 3.0 and printer applications - we have covered all printer drivers from Debian distro - the schedule is optimistic and you still have 2.5 in the meantime - new Ubuntu version will include only CUPS SNAP with printer applications, since Ubuntu moves towards SNAP-only distro - GNOME control center will have support for printer applications - can download the printer app from SNAP and open its web UI - 3.0 - manager Michael Sweet - mover away from PPD files - split between local and sharing servers + libcups + tools - splitted projects are getting to beta state - available on OpenPrinting and Mike's github - libcups - OpenPrinting/libcups - removed PPD API and other deprecations - using bool and size_t - MIGRATING.md and CUPS programming manuals created/updated - threading APIs, IPP data file, portable DNS-SD - we still have to add DBUS interface, JSON support on the way, ipptool fixes - cups-commands - lpinfo removed, lpadmin updated for PPD free world - cups-local - OpenPrinting/cups-local - baseline code commited and rebuilt - pre-beta - test on your own risk, but any test help is welcome - communication with printers, convert to PDF/raster as needed for printer, job his - configuration limited to profiles - cups-sharing - OpenPrinting/cups-sharing - rebuilt and base code line in it - waiting for OAuth from 2.5 - printing after swiping the card will be supported, What we need: - UI - we have to get rid of PPD API in print dialogs, auth via OAuth in UI and consent for accounting/privacy (we have a list of needed info for printer and if user doesn't provide them, the printing won't happen - we need UI for this) - CLI auth and API key support - profiles in enterprise networks - printing via IPPEve/AirPrint/Mopria, Windows/SMB (Postscript/PCL), Printing to file (PDF) - we need something else for transformations - PDFio for PDF, Poppler/Xpdf on Linux, CoreGraphics on macOS (Google has a possible candidate, but needs Google buildsystem/looking to Cairo) - looking for commo
Re: hp printer installation
Hi Roger, your printer supports Airprint, so there is no need to install it with HPLIP or, if you allow mDNS in your local network, you don't have to install it at all and work via temp queue (in case you are happy with printer defaults or you don't mind checking the printing options before you print) which appears when you want to print and disappears after you print. The steps how to set the environment and what to check you can find here https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_install_a_print_queue . Unfortunately the default Firefox dialog still doesn't support this feature, but if you are on GNOME and switch to system dialog in Firefox, you will be able to print via temp queue as well. All GTK3 apps and Librefoffice are able to print like this. Zdenek On 6/18/22 16:11, Roger Wells wrote: Any attempt to install my hp4630 all-in one printer on a clean install F36 produces dialog saying "python3 not responding" and ultimately fails. Same printer has installed and worked as expected on F35 and many previous fedora installations. Installation attempt is for wireless connection. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
News from printing world aka PWG May 2022 meetup
Hi all, it is another year and we have an aggregated report of what changed in the printing world since the last year. The whole notes are as the attachment, but highlights are: - myself (Zdenek Dohnal) being release manager for CUPS 2.4.x series - Till Kamppeter wrote printer applications which covers all printer drivers in Debian distribution - we don't have any additional printer driver package in Fedora, so all our driver packages are covered as well - printer applications (the solution for driver-only printers how to work with IPP-only CUPS) are available as SNAPs in Fedora (feel free to try them and leave feedback at the respective OpenPrinting project https://github.com/orgs/OpenPrinting/repositories ), packaging them as RPMs is blocked due dependency on cups-filters 2.0, which is not released yet (though IIRC someone from Fedora community - maybe Brandon Nielsen - has them in copr) - in case of proprietary drivers which aren't packaged in OS there is a legacy printer application inside of pappl-retrofit project, which, once you install the printer in this printer application with the proprietary driver you need, gives the printer IPP Everywhere interface, which makes it visible for CUPS - flatpak isn't designed for system services such as CUPS and printer applications, so Till will investigate shipping containerized printer applications via OCI containers on dockerhub Enjoy! -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC PWG May 2022 Face-to-Face Meeting = PWG Plenary --- - steering commitee updates - Jeremy Leber from lexmark is main chair, Smith Kennedy vice chair - next meetings - August, November, February, May - IPP Everywhere self-certification - !!854!! certified printers! - printers from Digital Check, OKI, HP, LExmark, Samsung and others on the way :) - IPP Everywhere self certification 1.1 Update 4 on the way, in beta - no IPP Everywhere v1.0 certifications are no longer accepted - updated PWG IPP Everywhere Logo policy - longer grace period to have ippeve logo in materials before certification - creating several PWG policies - antitrust, press release review, namespace - https://github.com/istopwg - IPP - working on several standards - IPP Driverless printing extensions 2.0, IPP Everywhere 2.0, IPP Finishings 3.0 etc. - secretary Mike Sweet, Co-chair Paul Tykodi and Ira McDonald, editors Mike Sweet and Smith Kennedy - IDS (Image Device Security) - focus on common criteria for HCD (hard copy devices - printers/scanners) - developing HCD security guidelines - liaison status - openprinting - coming next - Mopria alliance - liaison agreement and auto-renews until one or both parties cancel it, no collaboration right now - 3D/Additive manufacturing OpenPrinting Plenary - markets and distros - distrowatch says the most popular is Linux Mint, Manjaro, Ubuntu, Debian, Fedora, openSuse, CentOS - OpenPrinting highlights 2022: - CUPS - latest release 2.4.1 - cups-filters - 1.28.15, working on 2.0 - PAPPL - printer application library 1.2.0 - ps-printer-app - currently in SNAP, waiting for cups-filters 2.0 - gutenprint-printer-app - in SNAP - hplip-gutenprint-app - in SNAP - pappl-retrofit - common functions for printer apps - driverless printing on all major OS platforms - ipp-usb - Google Chrome OS has its own in Rust - driverless scanning - more info later - GSOC 2022 - now we have contributors instead of students - standard period ends Sep 12 2022, extended Nov 13 2022 - monthly meeting on the first Tuesday in a month, invitation on printing-architecture mailing list GSoC Project Updates - ideas 2022 - we will see which will be selected by Google: - Add avahi calls for discovering and resolving driverless IPP printers and optimize the process - Gui for discovering non-driverless printers and finding suitable Printer app for them - Adding CPDB support to existing Print Dialogs - Convert Braille embosser into printer application - Scanning Support in PAPPL with eSCL Support - Scanning Support in PAPPL with IPP Scan Interface - Create new printer setup tool for the GNOME Control Center - Make a native Printer Application for Gutenprint - GSOC 2021: - Pranshu - Create a universal filter function instead of chain filtering - to save resources executables are migrated to functions - Divyasheel - GUI for listing and managing available IPP Print/Scan services - combo of gtk+ library and avahi-client backend for getting IPP services into GNOME Control Center CUPS Plenary - Apple doesn't respond, we support it in OpenPrinting for two years now under ASL 2.0 with exceptions for GPL2-only - CUPS 2.4.x - I hope I manage 2.4.2 soon - CUPS 2.5.x - new features as centralized localization, oauth, wide-area dns-sd look-up and profiles, better certificate m
Re: [IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed
at Joe also removes the real driver from the system (like hplip), or will the action described above be sufficient? Driver removal is not needed - removal of permanent print queue (printer) suffices for make printing and scanning work. 9. I read that Firefox might not work with the new setup [3][4]. I'm *very* concerned about that. Can you elaborate? When exactly will printing from Firefox not work? For all IPP over USB printers handled through ipp-usb? The default intended ipp-usb usage will not work in the default print dialog in Firefox, but it works once you switch to 'system dialog' on GNOME, which uses GTK. Or you can install the queue permanently via lpadmin (as I wrote in the initial email) or use the uri - ipp://localhost:6/ipp/print - in CUPS Web UI (localhost:631 if cups.service is running) 10. Can it happen that the IPP-over-USB approach offers less printing options than its real driver counterpart? E.g. paper types, color adjustments, etc. What if the user wants to use the real driver instead, for these reasons, what is the recommended approach? (Ideally for an average Joe, if possible, i.e. no lpadmin commands). Yes, it can happen the IPP-over-USB approach offers less options - it depends on what printer's firmware advertises in communication, and since classic drivers are still rooted deep in UIX, some manufacturers probably incline to provide a basic set of functionality via driverless protocols. Usually it can happen that there is only one print quality instead of three etc. If you want to go back to classic driver, create a .conf file at /etc/ipp-usb/quirks and reject your device model - see 'man ipp-usb'. But keep in mind classic drivers will go away in a year or two. 11. What can we do better during the upgrade? I read we can't fix this perfectly. But even if the package removed all "print queues" during installation, it would go from "My printer doesn't print and I have idea why, I'm so angry" situation into "My printer disappeared, I had to add it again, I'm so angry" situation (in case it wasn't IPP over USB, in which case it would be autodetected and immediately re-appear). That seems like an obvious lesser evil. In the first case, you have no idea what to do, except for magically stumbling on our documentation. In the second case, it's obvious that you need to add the printer again, if it is not there, and so it allows users to fix the situation themselves pretty naturally. I understand this won't work on rpm-ostree based systems, but it's still a huge leap forward. Am I misunderstanding something? There is an idea of oneshot binary which can run as systemd service which can do the trick in the other reply from Michael. I would like to pursue that way. 12. This can still be reverted, right? It's enough to stop recommending ipp-usb in F36, correct? Or is there a technical reason why that mustn't be changed? I simply wonder whether we still have a way out if this is deemed too catastrophic without some automatic workarounds like the one proposed above. Yes, the change can be reverted - which I will do based on the feedback - I will do the proper change announcement once there is a migration for affected devices. Although it would be great if the manual for ipp-usb stayed on the Ask - the ipp-usb existence really needs to be spread out and Quick Docs or Wiki don't seem to cut it. I'm deeply sorry for inconvenience and thank you for the feedback! Zdenek Thanks! Kamil [1] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/YL3XCMM7O27MEG6B2K54L2YSP2OJ7ZJ4/ [2] https://fedoraproject.org/wiki/Releases/36/ChangeSet [3] https://bugzilla.redhat.com/show_bug.cgi?id=2066528#c4 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1983403 ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed
On 3/30/22 03:26, Michael Catanzaro wrote: (removing us...@lists.fedoraproject.org)... On Wed, Mar 23 2022 at 01:58:33 PM +0100, Zdenek Dohnal wrote: Unfortunately there is no clean upgrade path to solve the migration automatically because of unrealistic requirements such as: - the USB device would have needed to be plugged in and turned on during the update - %post scriptlets don't work the same way on immutable Fedoras as on Fedora Linux, and other upgrade possibilities such as Leapp don't support Fedora upgrades AFAIK, the fix has to be done manually. Hi Zdenek, First, thanks for your work on preparing Fedora for CUPS 3.0 and driverless printing, and for helping me with the printer and scanner bug reports I reported after I discovered this broke my printer after upgrading to F36: https://bugzilla.redhat.com/show_bug.cgi?id=2066528 https://bugzilla.redhat.com/show_bug.cgi?id=2069277 Hopefully my experience after removing my old print queue and switching to the CUPS temporary queue is an anomaly. I know we don't *expect* users to have this much trouble. That said, even if everything goes as expected, requiring users to remove the original broken print queue is unfortunate. Leaving a broken scanner device around is too. I understand it is difficult to seamlessly upgrade users from F35 -> F36 due to the intrusive nature of these changes. That said, I think it's worth discussing whether a smoother upgrade is possible, because otherwise I expect a large number of complaints from users. An installed one-shot systemd service would avoid the need for any %post scriplets, for example. That could help us on immutable systems - but I'm not sure when the service should run - I would expect it would run once a certain CUPS version is on the system, but I'm not sure how to make it run only once when it is installed without any %post/%triggerin in RPM. And what should trigger the run of the service? Maybe an idea? The service will be brought up by udev rule - if action 'ADD' happens during restart as well, the daemon should be loaded during machine restart and when the printer is turned on - it will be run only for IPP-over-USB device, construct the URI for the device and then try to find the URI among local permanent queues. WDYT? Does the action 'ADD' is Alternatively, could we find a way to disable the classic drivers if the printer supports ipp-usb? Hmm... what I can think of we could come up with deny lists for classic driver projects (hplip, gutenprint, sane-backends), so users could define idVendor and idProduct and reject the device in the classic driver. However this would fit better the scanning stack, since there is automatic device discovery for classic drivers. For printers permanent queue installation with a classic driver always requires user intervention - IMO we should not block users which explicitly want to install print queue with classic driver. > - the USB device would have needed to be plugged in and turned on during the update I understand the problem is you don't know whether the printer supports ipp-usb unless it's on, right? Therefore, a one-time upgrade script has no way to know whether the print queue should be deleted or not? Exactly. Perhaps it would be possible to delete the print queue that uses the traditional driver whenever support for ipp-usb is detected? Yes, that could be possible, but it will work only if the device is turned on when the service is started. I don't know enough about printing to say whether that is a reasonable suggestion or a ridiculous one. Just brainstorming. No problem, it helps me to think about the problem from another angle. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed
erminology/#_temporary_print_queues [4] https://github.com/alexpevzner/sane-airscan#compatibility [5] https://bodhi.fedoraproject.org/updates/FEDORA-2022-037458e247 [6] https://bodhi.fedoraproject.org/updates/FEDORA-2022-140993eb13 [7] https://bodhi.fedoraproject.org/updates/FEDORA-2022-f151accd9b [8] https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks [9] https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/#_cups -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 is already inactive branch in Pagure - expected?
Filed infra ticket: https://pagure.io/fedora-infrastructure/issue/10585 On 3/9/22 09:08, Zdenek Dohnal wrote: Hi all, today I've found out F34 branch is already set as inactive in dist-git, so every commit to the branch is rejected. IMHO it is a bug, because the branch should become inactive with F34 EOL, and right now we are in F36 Beta Freeze (about 2 months from estimated F34 EOL [1]). Does anyone know whether it is outage/bug? I've written a message to #fedora-admin IRC channel for now. Thank you in advance, Zdenek [1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F34 is already inactive branch in Pagure - expected?
Hi all, today I've found out F34 branch is already set as inactive in dist-git, so every commit to the branch is rejected. IMHO it is a bug, because the branch should become inactive with F34 EOL, and right now we are in F36 Beta Freeze (about 2 months from estimated F34 EOL [1]). Does anyone know whether it is outage/bug? I've written a message to #fedora-admin IRC channel for now. Thank you in advance, Zdenek [1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Linux Plumbers Conference - Open Printing Micro Conference
On 9/21/21 1:21 PM, Neal Gompa wrote: On Tue, Sep 21, 2021 at 5:36 AM Zdenek Dohnal wrote: - several other printer applications was implemented by Till Kamppeter[1][2][3][4] - Till makes it available as Snaps, I'm planning to package it into Fedora as rpm first, then later as a flatpacks How would these even work as Flatpaks? They are not graphical applications or even console applications. These are helper services for CUPS. I wouldn't expect those to work in Flatpak at all. (here I'm starting to talk based on talks I've seen and how I've understood them - I still haven't had time to deeply test them by myself, I've only tried briefly lprint last year...) Actually they are console applications - you can start them by CLI as an user or make them start on startup by its service unit. Once you configure your device at http://localhost:8000 (web ui for the printer application), your device will become available via mDNS and you can print without any other configuration (if your mDNS support in Fedora works). Or if you don't trust your local network, you can install the queue with uri - |ipp://localhost:8000/ipp/print/| Ad printer apps being in flatpack - as you can see in the github issue[1], ps-printer-application and hplip-printer-application are available in SNAP repositories (CUPS has its SNAP as well in SNAP store). IIUC flatpack is based on the similar technology as snap, so my thoughts were the flatpack version is also possible. [1] https://github.com/OpenPrinting/ps-printer-app/issues/9 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Linux Plumbers Conference - Open Printing Micro Conference
On 9/21/21 2:12 PM, Björn Persson wrote: Zdenek Dohnal wrote: the schedule for the first no-driver was proposed What is a no-driver? Ahh, sorry - word 'release' I had in my mind, but I didn't write it :D . CUPS 3.0 is planned to be the first release without classic driver support, supporting only IPP Everywhere (Airprint/Mopria) enabled devices. The older devices will be supported via printer applications, which will add a mandatory layer for CUPS to see the device. Björn Persson ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Linux Plumbers Conference - Open Printing Micro Conference
Hi all, I attended Open Printing Micro Conference at Linux Plumbers Conference yesterday and took notes from sessions (full notes are as an attachment). Here are the highlights: - the schedule for the first no-driver was proposed - approximately GA in February 2023 - but IMO it depends how other projects will be ready, especially GUI toolkits and applications will need to be able to cope up with temporary queues - CUPS upstream introduced a new role - a release manager - which will review PRs, do github cleanups, investigate issues, release bugfix versions for duration of one Y-stream release (about one year duty) - I've volunteered to be the first manager for CUPS 2.4 - proposed a split-up of CUPS to a separate projects based on the area where it is used - CLI command tools, libcups, local cups server (lightweight daemon, running under user on demand, no web ui, no permanent queues, relies only on temporary queues, dbus-api, accessible via domain socket or dbus), sharing cups server (basically the current cupsd - web ui, only permanent queues, listens on IPP port, runs under root) - several other printer applications was implemented by Till Kamppeter[1][2][3][4] - Till makes it available as Snaps, I'm planning to package it into Fedora as rpm first, then later as a flatpacks - more GUI printer setup tools were implemented during the latest Google Summer of Code, so we need to reconnect discussions with GNOME team about integration of the projects into control center and other setup tools. [1] https://github.com/OpenPrinting/gutenprint-printer-app [2] https://github.com/OpenPrinting/hplip-printer-app [3] https://github.com/OpenPrinting/ghostscript-printer-app [4] https://github.com/OpenPrinting/ps-printer-app -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C Linux Plumber Conference 2021 - Open Printing Micro Conference == - new member of Open Printing group - Thorsten Alteholz - Debian CUPS maintainer - welcome to the team! :) - our goal is to make printing and scanning easier for users - no installtion, just plug-and-print CUPS 2.4/2.5 - Michael Sweet - Apple vs. Open Printing CUPS - Mike left Apple in 2019 and not much activity on Apple CUPS since then, so CUPS was forked into Open Printing and became the main repository for CUPS - Mike was contracted by Apple to fix issues in Mac OS CUPS - no development, only bug fixes - the real development in Open Printing CUPS - Organization in Open Printing CUPS - currently we have no leadership structure and we manager the project by consensus - Leadership and Roles - Mike has been CUPS devel for 23 years - proposal: choose a release manager for single release - minor release cycle lasts two years (one developement and one for maintenance) - Release Manager Role: - responsible for coordination of a feature release (milestone in GitHub), coordination/coaching of developers in PR, monitoring CI builds, creation release tarballs (make source-dist script) - release manager doesn't need to do all coding - where to file bugs? Log it into Open Printing CUPS first, then to Apple CUPS if it is affected (Apple printing team is currently divided to other projects, but Mike can escalate the issue to his former manager) - Zdenek Dohnal will do his best for CUPS 2.4 as a release manager :) - security response regarding CUPS now goes to Mike's mail - Aveek will try to set it for linuxfoundation email - CUPS 2.4 - official AirPrint/Mopria printer sharing support - added OAuth support - explicit container support - added pkg-config support - deprecates cups-config and Kerberos (will be removed in 3.0, replaced by OAuth) - beta in the end of September, rc in October, 2.4.0. November, patch releases every 2 months since January - CUPS 2.5 - OAuth support in cupsd - OAuth callback for desktop - D-BUS API - good for containers to do it with DBUS-API - TLS/X.509 improvements - centralized localization - OSes usually have their own localization services, let's decide what to do about it - other containers techs - docker, appimage, flatpack - note for zdohnal: contact a person for weblate integration - schedule - the similar as 2.4 but in 2022 - probably the last two release for 2.x - no backports for 2.5, get desktop devels for Dbus OAuth stuff CUPS 3.0 - Michael Sweet - move to no driver world - cups + printer application - Arch: - command - local server - run as user, only temp queues, spooling, filtering, job history limited, run on demand domain sockets, DBUS - sharing server - only perm queues, IPP domain/TCP sockets, web ui, runs a root, accounting - printer application - library - local server - has a permission for find
Re: poppler soname bump in rawhide
cups-filters's been rebuilt in side tag as cups-filters-1.28.9-5.fc35. I removed the build requirement for poppler-devel, since it is no longer needed (all stuff is now covered by poppler-cpp-devel). On 7/26/21 6:06 PM, Marek Kasik wrote: Hi, I've prepared rebase of poppler to 21.07.0 in the side tag "f35-build-side-43960". I'm asking you to build your dependent packages in it and I will ask to merge it to main branch next Monday (2nd of August). There are several API changes and soname bump of the base library libpoppler.so.*. If your package still uses the unstable API (headers from poppler-devel), could you consider to change it to use a stable API (glib, qt5, C++)? It would mean less work for you and I would be able to disable the unstable API. Regards Marek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Why doesn't iconv know ISO-8859-2 in rawhide?
Thanks Michael! Aha, it seems the rawhide buildroot from 6/23 still contained glibc with recommends on new package and not hard requires. I've explicitly added glibc-gconv-extra as a buildrequires for vim now - although as you told it is unnecessary right now, I guess it is a good thing to track what the package actually needs (dependencies can change with time, as I found out painfully over the years :D ). On 6/23/21 2:55 PM, Michael Catanzaro wrote: Hi Zdenek, See: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JQTTSNHMSFV63KIDDPW4M7WV7CI6KZYW/ TL;DR: workaround is to manually install glibc-gconv-extra, but you shouldn't need to do anything really because this should already be fixed by having glibc depend on glibc-gconv-extra. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Why doesn't iconv know ISO-8859-2 in rawhide?
Hi all, vim started to fail to build today with error during compiling desktop file: msgfmt --desktop -d . --template gvim.desktop.in -o tmp_gvim.desktop cs.po: warning: Charset "ISO-8859-2" is not supported. msgfmt relies on iconv(), and iconv() does not support "ISO-8859-2". Installing GNU libiconv and then reinstalling GNU gettext would fix this problem. Continuing anyway. msgfmt: Cannot convert from "ISO-8859-2" to "UTF-8". msgfmt relies on iconv(), and iconv() does not support this conversion. make[1]: *** [Makefile:219: gvim.desktop] Error 1 make[1]: Leaving directory '/builddir/build/BUILD/vim82/src/po' make: *** [Makefile:2154: languages] Error 2 glibc (glibc-devel, glibc-common and glibc-headers-x86) and gettext are in buildroot, so the advice should be applied, but still I cannot figure out how to fix the issue. Would anyone mind helping me here? Thank you in advance, Zdenek -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Hi Robert, On 5/24/21 2:39 PM, Robert Marcano via devel wrote: > On 5/24/21 3:29 AM, Zdenek Dohnal wrote: >> >> Devices which currently depend on a deprecated functionality - >> printer drivers and raw queues - will need a printer application once >> the deprecated functionality is removed from CUPS. This application >> will advertise the device on localhost via MDNS protocol and will >> communicate with CUPS via IPP, both public well-known protocols. The >> only place where the data can turn into proprietary is filtering, but >> it's the same with printer drivers. >> >> -- > > Greetings, Is there any plan to support these IPP printer applications > over Unix domain sockets? pappl supports listening on domain sockets (IIUC the docs https://www.msweet.org/pappl/pappl.html), so if a printer application decides on it will use domain sockets, it is possible. > > I manage a virtual printer that uses CUPS filters and backends to > capture documents to an application database. We have been using CUPS > authentication features to control who can use the printer, and not to > have to reimplement authentication on the filter and backends. With > network bound IPP applications, anyone on the same multiuser machine > would be able to bypass CUPS and send documents directly unless I > duplicate CUPS authentication functionality. Unix sockets would help > with that, > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Hi Przemek, thank you for trying the driverless and the investigation! Would you mind checking if the similar bug isn't already reported on Avahi in Fedora and reporting it if not? Maybe Avahi maintainers can point out what is the best for debugging Avahi. I recommend setting debug logging on avahi-daemon service file, maybe its logs will show something more. On 5/25/21 8:20 PM, przemek klosowski via devel wrote: > > There are so many moving pieces here that it's hard to get a handle on > this. I had trouble seeing local network printers so I tried following > the advice Zdenek published [1], but I ran into a nest of issues: > printing depending on avahi, which fails quietly and is hard to debug. > > Specifically, I did *avahi-browse -avrt* which just returns with > avahi_service_browser_new() failed: Invalid service type > > This seems to be related to a bug where some devices are sending > non-compliant data to avahi: > https://github.com/lathiat/avahi/issues/212 but we're already far away > from the print subsystem.. I tried running avahi-browser under gdb but > between the missing and not-autoloading debuginfo packages, and the > callback-style structure, I wasn't able to catch it receiving the data > that causes the problem. > > I guess my point here is that we have a complex, interdependent > system, and when it fails, it is fairly opaque. At this point I am not > sure what to do: is the root cause here the avahi bug? I am willing to > spend the effort getting to the bottom of it but I can't figure out > where to start. > IIUC the upstream issue, the core of the problem is that something in your local network sends a broken PTR record which avahi cannot cope with and it breaks avahi-browse in whole LAN... > > > >> On 5/24/21 1:42 PM, Stephen John Smoogen wrote: >>> I have had very bad luck in setting up new network printers over the >>> last 4 years. I can get all of them to print from Windows and Mac, >>> but every one of them from HP, Brother, and some other brands could >>> not print anything from Linux. They were all 'Linux ready' but were >>> doing it via either Google Print or a set of proprietary software >>> blobs to be put on the computer. [They even came with ipp filters >>> but they called the blobs]. I have a Brother MFC-27100W in my office >>> which I print to via my wife's Mac because of this. >>> >> >> I have written some basic info about how to find out whether your >> printer supports driverless [1] and how to setup it [2]. If you have >> at least F33 and have the device in your LAN, you can use temp queues >> for sure, otherwise you need to create a permanent queue via lpadmin: >> >> $ lpadmin -p -v -m >> everywhere -E >> >> >> If you still experience the issue, do feel free to file a bug for >> cups in bugzilla and I can look into it further. >> >> >> [1] >> https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_whether_my_printer_is_capable_of_driverless_printing.3F >> >> [2] >> https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_network_printer >> >> > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 1:42 PM, Stephen John Smoogen wrote: > I have had very bad luck in setting up new network printers over the > last 4 years. I can get all of them to print from Windows and Mac, but > every one of them from HP, Brother, and some other brands could not > print anything from Linux. They were all 'Linux ready' but were doing > it via either Google Print or a set of proprietary software blobs to > be put on the computer. [They even came with ipp filters but they > called the blobs]. I have a Brother MFC-27100W in my office which I > print to via my wife's Mac because of this. > I have written some basic info about how to find out whether your printer supports driverless [1] and how to setup it [2]. If you have at least F33 and have the device in your LAN, you can use temp queues for sure, otherwise you need to create a permanent queue via lpadmin: $ lpadmin -p -v -m everywhere -E If you still experience the issue, do feel free to file a bug for cups in bugzilla and I can look into it further. [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_whether_my_printer_is_capable_of_driverless_printing.3F [2] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_network_printer -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/25/21 10:22 AM, Tomasz Torcz wrote: > Dnia Mon, May 24, 2021 at 08:21:07PM -0400, Solomon Peachy napisał(a): >>> Well, if I want to configure the printer, I need to know what to point my >>> browser at. But sure, if a dialog gives me a link, that is a way. Though it >>> means yet another layer of indirection (bringing up the dialog first, only >>> to get redirected to a web interface). >> Running 'ippfind' will show you the list of all IPP-capable printers >> that are advertising themselves through mDNS, and the URI they can be >> reached at. > Nice command, but it returns host in the .local domain, resolving of which > doesn't work half of the time. The host sharing the printer has > normal, functioning FQDN, couldn't ippfind return it? IMHO the proper thing to do would be to investigate why you experience the issues with .local instead of rewritting software which uses .local addresses. Unless you have disabled weak dependencies in dnf, avahi and nss-mdns is installed together with CUPS, and .local resolution works fine with them. (The other issue is that 'driverless' binary sometimes fails to provide driverless ipp uri, which is a problem during searching for printers, but ippfind always finds the device just fine. I track it here [1]) I tried Avahi+resolved setup too and address resolving worked as well, but it needed more steps to make it work (enable mdns in resolved and enable mdns and llmr in NM for your network interface). If the resolution still doesn't work after checking your setup, it would be great if you filed a bug against nss-mdns or resolved, based on which solution do you use. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1954469 > I do control the network, including DNS server, but this zeroconf stuff > is a jungle. > > (some time ago I'v tried to share common LAN bookmarks using zeroconf, > but only Epiphany supported it. Firefox never get there - bz 173804. > Today, I don't even know what the equivalent of /etc/avahi/services/ is > in the systemd-resolved world). > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 12:33 PM, Vitaly Zaitsev via devel wrote: > On 24.05.2021 12:30, Solomon Peachy wrote: >> Not only is it possible, it's been done. > > For all existing printers in the world? I don't believe. I would have a counter question - do you think that all existing printers in the world which have a printer driver work correctly on Linux? I don't believe. :) OpenPrinting community plans to create printer applications for widely known printer drivers, plus those applications can use your own PPD file once you upload it to the application and the same is planned to do with plugins/firmware (you will be able to use 3rd party plugins and firmware with printer applications). -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 12:30 PM, Solomon Peachy wrote: > On Mon, May 24, 2021 at 10:18:17AM +0200, Vitaly Zaitsev via devel wrote: >> On 24.05.2021 08:51, Zdenek Dohnal wrote: >>> OpenPrinting plans >>> to implement printer applications for widely known printer driver >>> packages during GSoC [1] and provides a documentation for driver >>> developers who wants to implement their printer application faster[2][3]. >> I don't think this is even possible in theory. > Not only is it possible, it's been done. > > - Solomon Thanks, Solomon :) > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 12:37 PM, Vitaly Zaitsev via devel wrote: > On 24.05.2021 10:33, Zdenek Dohnal wrote: >> The future removal isn't due lacking manpower, but due moving to >> standardized and less hardware dependent solutions - driverless >> standards such as IPP Everywhere. And those standards are supported >> by 98% devices released after 2010. > > HP LaserJet P1102w and many others (also called as "win-printers"). It > will be discovered through IPP Everywhere / Avahi, but will not print > anything until the proprietary "plugin" is installed. > I answered you in your original thread, no point of spamming the same message under every related email in the conversation tree. I told you there is a plan for printer application for foo2zjs and you can join the community to implement it, you disagreed, I beg to differ. -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/22/21 9:58 PM, Björn Persson wrote: > > So what I'm hearing is that Fedora will soon stop working with my > printer, There isn't a specific date for removing the functionality, now we work on implementing printer applications for widely known and open sourced printer drivers. > because if there isn't enough manpower to even keep existing > printer drivers in place, The future removal isn't due lacking manpower, but due moving to standardized and less hardware dependent solutions - driverless standards such as IPP Everywhere. And those standards are supported by 98% devices released after 2010. > then who is going to write a bunch of pappls > for not-quite-brand-new printers? Openprinting community plans to write printer applications for some widely known printer drivers during Google Summer of Code in the future[1]. For others - we expect other communities which want those devices to work once drivers are removed from CUPS will step up and implement the missing parts. Openprinting created a printer application library [2] and documentation for them [3][4]. > > And if the bright and shiny future is that USB printers look just like > network printers, and network printers just show up without any > installation, then I'm starting to wonder how I will know whether I'm > sending my sensitive document to my USB printer or to some impostor on > a wifi network. CUPS discovery is designed to run on secure, private LAN, so it is expected that you have a protection against somebody connecting to your WIFI. [1] https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021-openprinting-projects#converting_classic_cups_printer_drivers_into_printer_applications_multiple_students [2] https://github.com/michaelrsweet/pappl/ [3] https://openprinting.github.io/documentation/01-printer-application/ [4] https://openprinting.github.io/documentation/02-designing-printer-drivers/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Hi Stephen, On 5/22/21 1:37 AM, Stephen John Smoogen wrote: > > > Yes it is a bad situation but I don’t think there are a set of ‘CUPS’ > developers versus one person trying to keep the software going. Apple > stopped supporting the product and msweet is working for himself now. > lprint seems to be a ‘make a best out of a bad situation’. CUPS is supported and developed by Openprinting+PWG community, which contains Mike Sweet and distro maintainers (like me). > > I don’t know what any other alternatives there are as more and more > printers seem to be wanting you to send your prints to some central > web server they own and then will talk with your printer and print the > task. Or they say they support the IPP but really its an app on your > machine which just takes it and makes it something proprietary and > trying to talk ipp to the printer fails. You don't need any central web server or special app to be able to print via the current printer standards, which are driverless (IPP Everywhere/Airprint/Google Cloud Print). In case your device is on your LAN or USB, you don't even install the device permanently - CUPS is able to pick up Avahi messages about a device being in LAN or on localhost (in case of USB printers after you install ipp-usb) and set up a temp queue for you when you are about to print - the queue is removed after successful printing. Printers outside of your LAN need to be installed permanently right now via printer configuration tools (CUPS web ui, gnome-control-center, lpadmin) or via cups-browsed. We plan to support such devices by printer profiles, so the queues won't installed permanently either. Devices which currently depend on a deprecated functionality - printer drivers and raw queues - will need a printer application once the deprecated functionality is removed from CUPS. This application will advertise the device on localhost via MDNS protocol and will communicate with CUPS via IPP, both public well-known protocols. The only place where the data can turn into proprietary is filtering, but it's the same with printer drivers. -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/22/21 12:17 AM, Kevin Kofler via devel wrote: > Zdenek Dohnal wrote: >> It is a library for printer applications [1], not a substitute for CUPS. >> CUPS is still present and is going to be. >> >> There will be more printer applications coming into Fedora >> (ps-printer-app f.e.) and one already is (lprint). >> >> >> The purpose of the library is have a way how to implement a support for >> devices which don't support IPP Everywhere [2] or its derivations >> (Airprint, Mopria, Google cloud print) or IPP over USB[3], so they can >> be seen by CUPS once we remove printer driver support. Hi Kevin, > I really don't see how the switch from drivers to printer applications is an > improvement. Printer applications started as a transition technology - a way how to support older printers once CUPS removes printer driver support - so for now they are here for backward compatibility. Except for Gutenprint, I'm not aware of any printer driver provider which plans to provide more specific options with a printer application. They seem to be okay with AirPrint. So printer application will be needed only for older (<2010) printer models in most cases. > All the existing drivers have to be ported to the new interface > to essentially emulate the IPP protocol. And now, instead of being able to > configure printer options through the existing graphical CUPS frontends (or > just set them temporarily in the individual application, which most > applications support nowadays), you end up with a CLI as in the old lpr > days, e.g.: > https://www.msweet.org/lprint/lprint.html#printing-options > https://www.msweet.org/lprint/lprint.html#setting-default-options > or at best, a GUI provided by the printer application in some arbitrary > toolkit, which will likely be GTK for Gutenprint (forcing KDE Plasma users > to use a GTK application to configure their printer) and Qt for HPLIP > (forcing GNOME users to use a Qt application to configure their printer). > Instead of a standardized interface to configure printer options, every > printer application now has to reinvent its own one. AFAIK PAPPL (and even the old lprint which I packaged into Fedora last year, but his web interface is going to substituted by PAPPL web ui in the next release) provides a default web interface which you can use for configuring printer options. > > From the end user perspective, the new approach brings only disadvantages. Since PAPPL provides web ui and CLI, which you can use for configuring your device, IMHO it is not much different from what CUPS provides right now. > From the driver developer perspective, it means a lot of porting work. It depends on which devices he creates drivers for - if the device supports Airprint, he can choose to let Airprint to support the printer and no printer application is needed. >From my daily work, I see people often use drivers because they are used to using it and don't know they don't need to use it. For older devices, yes, there needs to be a printer application to be able to use the device with CUPS in the future, but OpenPrinting plans to implement printer applications for widely known printer driver packages during GSoC [1] and provides a documentation for driver developers who wants to implement their printer application faster[2][3]. > The > only ones who will benefit are the CUPS developers, who will have > successfully outsourced their work to other projects that now have to do > their work for them. CUPS developers (PWG+Openprinting) decided to remove deprecated functionality (which has big issues regarding security and distribution) in the future in favor of standardized, less hardware dependent solution, which is supported by 98% of printers released since 2010. The functionality has been deprecated for 11 years and still be only deprecated (not removed) until there is a coverage for older devices by printer applications and have some tools for installing older printers via printer applications. CUPS developers came up with printer application design for older device users, so they don't have to buy a new device, created first three printer applications - ippeveprinter (shipped in CUPS itself, under cups-printerapp subpackage in Fedora), lprint (support for label printers) and ps-printer-app (which covers postscript printers) -, plans to implement printer applications for other widely packaged printer drivers and publicly provides a documentation how to create printer applications for corner use cases. [1] https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021-openprinting-projects [2] https://openprinting.github.io/documentation/01-printer-application/ [3] https://openprinting.github.io/documentation/02-designing-printer-drivers/ > > Kevin Kofler > ___
Re: When is pappl going to be good enough to replace cups?
Hi Vitaly, Openprinting community (which I am a part of the community) plans to have printer applications for printer drivers shipped in Ubuntu implemented during Google Summer of Code [1] by multiple students. foo2zjs is in Ubuntu too, so there's a plan to implement a printer application for it. However, if you don't want to rely/wait for GSoC results, one student from Google Season of Docs last year created a documentation for implementing printer applications [2][3], so you can learn more about how a printer application works and you're welcome to join our OpenPrinting community and help us implementing the foo2zjs printer application. [1] https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021-openprinting-projects [2] https://openprinting.github.io/documentation/01-printer-application/ [3] https://openprinting.github.io/documentation/02-designing-printer-drivers/ On 5/21/21 10:30 AM, Vitaly Zaitsev via devel wrote: > On 21.05.2021 08:24, Zdenek Dohnal wrote: >> If your printer is network printer released approx. 2010 and later or >> USB printer released approx. 2015 and later (tips how to find out if >> your device supports driverless printing here [4]), you don't even >> need to install your printer anymore, not mention using a printer >> driver (or future printer applications). > > What about "win-printers" like HP LajerJet P1102w? > > Currently I maintain and use foo2zjs to use them without the > proprietary "plugins" from hplip. > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/20/21 11:09 PM, Reon Beon via devel wrote: > Thoughts? > > https://src.fedoraproject.org/rpms/pappl It is a library for printer applications [1], not a substitute for CUPS. CUPS is still present and is going to be. There will be more printer applications coming into Fedora (ps-printer-app f.e.) and one already is (lprint). The purpose of the library is have a way how to implement a support for devices which don't support IPP Everywhere [2] or its derivations (Airprint, Mopria, Google cloud print) or IPP over USB[3], so they can be seen by CUPS once we remove printer driver support. Another way of usage can be for printer vendors which find IPP Everywhere as a too much generic support for their devices, so they can implement their own printer application with more specialized options and that printer application will advertise the device to CUPS. _The bottom line of all of this:_ If your printer is network printer released approx. 2010 and later or USB printer released approx. 2015 and later (tips how to find out if your device supports driverless printing here [4]), you don't even need to install your printer anymore, not mention using a printer driver (or future printer applications). Since GTK is fixed (since F33), you can just open a print dialog, the device will be found (after you do several steps - here for network printers [1], USB printers [2]), and you can print. Printer applications will be needed only for older devices and specialized printing. [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Printer_applications [2] https://www.pwg.org/ipp/everywhere.html [3] https://robots.org.uk/IPPOverUSB?action=AttachFile&do=view&target=IPP+USB+Specification.pdf [4] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_whether_my_printer_is_capable_of_driverless_printing.3F [5] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_network_printer [6] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_USB_printer > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
How-to-debug-printing-problems wiki migration to quick docs [Was Re: PWG virtual meetup 2021]
On 5/7/21 5:27 PM, Brandon Nielsen wrote: > On 5/7/21 12:01 AM, Zdenek Dohnal wrote: >> On 5/6/21 9:36 PM, Brandon Nielsen wrote: >>> Would you want to see that ported to a "How to debug printing >>> problems" Quick Doc[0]? Probably under "Usage and customisation"? I >>> could take a crack at a draft. >>> >>> [0] - https://docs.fedoraproject.org/en-US/quick-docs/ >>> >>> >> Hi Brandon! >> >> Thank you for looking into it! IMO it would be nice to have a separate >> category (for Printing and then a separate for Scanning) like kernel, >> databases or virtualization have - it would be lost in 'Usage and >> customisation' group. >> >> It is because the wiki page doesn't cover only 'How to debug printing >> problems', but it covers more terminology, tricks, known issues, user >> stories and (finally) how to debug and file the report - so it would be >> nice to have subcategory for all of those. >> >> And IMHO Fedora Linux's user base is mostly on desktop, it makes sense >> to me to have printing and scanning on the main page. >> >> If it is possible and you agree too, please let me know once you have a >> time to create a draft :) >> >> Again, thank you very much! >> >> >> Zdenek >> >> > > I started on this last night and based on the sheer quantity of > documentation I agree 100%. It should probably be it's own "Printing > and scanning" category or categories. I'm converting it as a bunch of > "partials" so it can be reorganized easily. > > You can see the start of my work in pagure[0], I tried to add you as a > collaborator to the branch, let me know if I did it wrong. I still > need to clean up a lot of the formatting and intra-document links as > well as split it out into the categories mentioned above. But all of > the text should be there. Looks good so far, I see myself as a collaborator too. Thanks! > > I also pinged the docs group to see if they have any suggestions[1]. > > [0] - > https://pagure.io/fork/nielsenb/fedora-docs/quick-docs/tree/printing-debug > [1] - > https://lists.fedoraproject.org/archives/list/d...@lists.fedoraproject.org/thread/K7VSSF3Q26CINGMU5PECARZJ7N7XQSEQ/ > >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: PWG virtual meetup 2021
On 5/6/21 9:36 PM, Brandon Nielsen wrote: > Would you want to see that ported to a "How to debug printing > problems" Quick Doc[0]? Probably under "Usage and customisation"? I > could take a crack at a draft. > > [0] - https://docs.fedoraproject.org/en-US/quick-docs/ > > Hi Brandon! Thank you for looking into it! IMO it would be nice to have a separate category (for Printing and then a separate for Scanning) like kernel, databases or virtualization have - it would be lost in 'Usage and customisation' group. It is because the wiki page doesn't cover only 'How to debug printing problems', but it covers more terminology, tricks, known issues, user stories and (finally) how to debug and file the report - so it would be nice to have subcategory for all of those. And IMHO Fedora Linux's user base is mostly on desktop, it makes sense to me to have printing and scanning on the main page. If it is possible and you agree too, please let me know once you have a time to create a draft :) Again, thank you very much! Zdenek -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: PWG virtual meetup 2021
On 5/5/21 8:35 PM, Neal Gompa wrote: > On Wed, May 5, 2021 at 2:27 PM Zdenek Dohnal wrote: >> Hi all, >> >> I attended PWG virtual meetup 2021 yesterday and today and created >> reported about it. >> >> Highlights: >> >> - CUPS got into OpenPrinting group from Apple >> > I'm confused, what does this mean? I saw a while back that > OpenPrinting had a fork of it. I see now that the fork relationship is > broken, but it seems like both Apple and OpenPrinting have trees. > What's going on now? Hi Neal, basically the best and complete explanation can be found in Mike's CUPS Plenary in PWG meetup (page 4 and on) [1], but I'll try to sum it up. Apple basically stopped developing CUPS since the end of 2019, when Mike Sweet (author of CUPS, PWG and OpenPrinting member) left Apple. Apple didn't show any intent to work on CUPS at github (except one squash of commits for CVEs in March 2020) - either it is an active development (which is needed for moving to world without drivers) or responding/solving upstream issues, so Mike forked CUPS from Apple to OpenPrinting after some time of Apple inactivity. So OpenPrinting CUPS version became upstream for CUPS packages in Linux (at least in Fedora, Debian, Ubuntu AFAIK) and we will follow the Openprinting fork. Recently, Mike has accepted Apple's offer to do some bugfixes in Apple/CUPS, but Apple isn't interested in active development, so Linux stays with Openprinting. [1] https://ftp.pwg.org/pub/pwg/liaison/openprinting/presentations/cups-plenary-may-2021.pdf > > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: PWG virtual meetup 2021
On 5/5/21 8:31 PM, Matthew Miller wrote: > On Wed, May 05, 2021 at 08:27:08PM +0200, Zdenek Dohnal wrote: >> I attended PWG virtual meetup 2021 yesterday and today and created >> reported about it. > Thanks! Printers are objectively every sysadmin's least favorite (even beating > out DNS), so I really appreciate you and everyone working on making it > better! You're welcome! IMO the situation is a lot better since 2015 when both (network printers got the driverless support sooner - in 2010) network and usb printers got driverless standards implemented into actual devices. Driverless support for network printers comes with cups and cups-filters projects by default, so it is in Fedora since upstream introduced it. Regarding USB printers, I packaged ipp-usb project into Fedora last year, so printers supporting IPP-over-USB work without driver too. Additionally, if your scanner/multi function device (MFD) supports IPP over USB, you have it connected via USB and your device supports eSCL or WSD protocols for scanning, you can even scan driverlessly with sane-airscan. Network scanners/MFD in the same LAN work out-of-the-box once you put your device into your LAN and let Avahi to do its job (all LAN printing/scanning heavily depends on mDNS). And once your PC supports driverless printing/scanning, your device has driverless support (AirPrint/IPP Everywhere/Mopria for printing, eSCL/WSD for scanning + IPP over USB if you connect via USB) and once you configure your PC (allow ipp and mdns in firewall, have avahi-daemon running) and device (enabled IPP, eSCL or WSD) you don't need to install a device at all. Your printer will 'appear' just at the time you print (in print dialog) and goes away after successful printing (so it does not block any of memory resources). Printing/scanning to devices outside of LAN requires more steps - usually you need to setup cups-browsed to browsepoll your print server (which currently has the most issues and I'm working on it to make it better) or install a permanent printer via a printer tool. So IMO it got better since times when there were a difficult questions like 'Is printer supported in Linux?' and 'How to install it in Linux?' - since any new device in shop is okay and installing works out-of-the-box for desktops. More terminology and tricks here [1] and here [2]. [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Terminology_for_printing_and_scanning [2] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Useful_tricks P.S. I know the page should be rewritten into docs.fedoraproject (I and Matt even talked together about it once), I have never got a time to do that. So if someone is willing to rewrite it in docs.fedoraproject, give me access to edit it and merge the changes, that person is very welcomed :) -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
PWG virtual meetup 2021
Hi all, I attended PWG virtual meetup 2021 yesterday and today and created reported about it. Highlights: - CUPS got into OpenPrinting group from Apple - still working on upgrade path for non-driverless printers after removing printer drivers and raw queues: 1) printer application library was created - PAPPL (already in Fedora) 2) the first printer application library created by Till Kamppeter - ps-printer-app - which supports postscript printers in the wild - ippusbxd is dead for ipp-over-usb standard - standard for driverless printing via usb [1] - we use ipp-usb (already in Fedora, how to find out my device is supported [2]) [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Driverless_printing_.28USB.29 [2] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_if_my_USB_device_supports_IPP_over_USB == -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C PWG 2021 PWG Plenary --- - 692 printers IPP Everywhere certified! https://www.pwg.org/printers/ - standards - IPP Everywhere 2.0 on the way, IPP Enterprise Printing Extensions 2.0, IPP Production Printing Extensions 2.0, IPP driverless printing extensions 2.0 etc. - IDS (Image Device Security) - now focus on hard copy devices protection profiles, hard copy devices security guidelines and standards - IPP - maintenance of the protocol and SNMP MIBs - recently published Job Accounting with IPP v1.0, in working IPP 2.0 (fourth edition), IPP driverless printing extensions 2.0, IPP encrypted jobs and documents 1.0, IPP enterprise printing extensions 2.0, IPP finishings 3.0, IPP production printing extensions 2.0 - pending IANA registrations https://www.pwg.org/ipp/ipp-registrations.xml - 3D printing - reaching 3D printer manufacturers about IPP to convince them to use IPP instead of drivers OpenPrinting Plenary - linux markets - windows lost to linux in public server market share, web server market share - linux distro popularity on distrowatch - 5th Fedora, 7th CentOS - cups-filters - highlights - clustering, dns-sd enhancing, filters - cups in SNAP - no drivers, working out of the box - participated in GSOC, GSOD abd LFMP (Linux Foundation Mentorship Program) - took over CUPS, released 2.3.3op1 and 2.3.3op2, working on 2.4.x - pappl - recent v1.0.3, written by Mike Sweet, library for printer applications - ps-printer-app - the first printerapp for postscript printers, written by Till Kamppeter - driverless - IPP Faxout support implemented in cups-filters - ipp over usb - ippusbxd removed, now we use ipp-usb written in Golang - scanning - Mopria released eSCL specification publicly, IPP scan service isn't supported by devices, so we go with eSCL and WSD - GSoC 2021 - halfed hours for projects, now only 5 students for us - GSoD 2021 - more complicated than before (legal stuff, payments to tech writer)... - cups-filters docs wasn't accepted - LFMP 2021 - currently considering projects which will go into LFMP - only technical projects (no bug fixing, maintenance, web creation, docs) GSOC, GSOD, LFMP updates - 2020 - CPDB and IPP scan projects weren't completed, but other students works on bugs in printer applications and cups-filters - LFMP 2020 - 4 students, none of them finished because LFMP started when universities in India started to have classes, so students were busy - GSoC 2021 - topics - create a single universal filter - firmware and other file handling in PAPPL - GUI for listing and managing available IPP Print/Scan services - modern IPP printers will be as IPP services, and printer applications will be drivers - converting filters to functions instead of executables - all filters must work without PPD files - coding period is reduced to half :( CUPS Plenary - future 2.4 - working on oauth 2.0 instead of kerberos, added compatibility with airprint and mopria (already done), added pkg-config support, kerberos and cups-config deprecated, snapcraft support mostly done, working on job-sheets-col and media-col (like using different output trays without postscript commands), working on TLS and X.509 (bringing OpenSSL back as an option, better X509 for servers - sharing certificates between devices instead of locally generated self-signed certs) - oauth - don't need root, Mike uses its own version - moauth, bearer and refresh tokens cached per-user/auth-server, asking for OAUTH server already implemented in IPP protocol - deprecations: - already removed in past: - due security issues - moving directives to cups-files.conf, interface script - performance and design issues - CUPS browsing (removed mainly because of wifi) - deprecated, will go away in the future: - p
Re: F35 Change: "Fedora Linux" in /etc/os-release
"Fedora" > refers to the Fedora Project. When referring to our work, please use > either a specific name like Fedora Workstation, Fedora > CoreOS, or Fedora KDE Plasma Desktop; or use Fedora > Linux to refer to the OS distribution as a whole. > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [F34] wait-repo task has been opened for approx 2 hours
On 2/11/21 1:40 PM, Miro Hrončok wrote: > Ad side-tags: >> >> IMO the process should work for buildroot overrides too. Side tags look >> good for big rebuilds, where not all packages belong to one maintainer, >> but it looks like an overhead for only two packages. > > If you want multiple (even two) packages to be shipped via a single > update in rawhide or branched (prior to updates testing activation), > side tag is the only way. Aha, so a chain-build only makes a sequence of builds, but they arrive into stable separately. Thanks! > > For branched (prior to updates testing activation) buildroot overrides > are possible, but the updates will be separated in bodhi. > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [F34] wait-repo task has been opened for approx 2 hours
Thanks, Miro! foomatic-db build is now in testing and I was able to create a override for it, but when I built foomatic, it got into bodhi automatically and now I cannot add foomatic build to foomatic-db update to prevent foomatic landing into stable than foomatic-db. I cannot even unpush the foomatic update - do you have any tips how to proceed? Ad side-tags: IMO the process should work for buildroot overrides too. Side tags look good for big rebuilds, where not all packages belong to one maintainer, but it looks like an overhead for only two packages. On 2/10/21 4:24 PM, Miro Hrončok wrote: > On 10. 02. 21 9:09, Zdenek Dohnal wrote: >> Hi all, >> >> I have started foomatic-db+foomatic chainbuild this morning for F34 and >> it has been opened for 2 hours till now. Is it expected? >> >> IIUC I don't need a buildroot override yet, since F34 hasn't been >> enabled in bodhi. So the process should be the same as in rawhide. >> >> Does anyone know what's going on? > > The first build is left in pending until the freeze is over: > > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#post-branch-freeze > > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-2e2e2883c5 > > You need a buildroot override, but the bodhi CLI will tell you: > > "Invalid build. It must be tagged as either candidate or testing." > > But the web UI allows it :/ > > Tip: You could have avoided the problem entirely by using side tags: > > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: our containers with alias vim=vi
Hi, just note - the functionality has been removed in the recent Vim package for 2 reasons: 1) making it default breaks a default vim alias - vimdiff == vim -d , because diff functionality is not a part of small set of features 'vi' is compiled with 2) making it optional via an environment variable (the way I thought it could be possible) doesn't cover all use cases when the 'vim -> vi' should work f.e. doesn't work with sudo. And it still requires an action from user which wants the functionality to be enabled, so I don't see a difference for user if the user needs to set 'alias vim=vi' or set environment variable. I'm sorry for inconvenience, Zdenek On 10/10/20 2:37 PM, clime wrote: > Hello, > > could Fedora and CentOS containers for docker and podman come with > `alias vim=vi` in ~/.bashrc? > > I would very much welcome it as I am used to type vim everywhere but > if vi starts instead I am happy too. I know that the solution is to > create a customized container but often I want to try something on > vanilla containers from the whole range. > > Didn't want to write about this first but maybe there are more people > with the same problem. > > clime > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[F34] wait-repo task has been opened for approx 2 hours
Hi all, I have started foomatic-db+foomatic chainbuild this morning for F34 and it has been opened for 2 hours till now. Is it expected? IIUC I don't need a buildroot override yet, since F34 hasn't been enabled in bodhi. So the process should be the same as in rawhide. Does anyone know what's going on? Thank you in advance, Zdenek -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
Thank you, Vitaly and Fabio! That makes sense, I didn't look on the issue from new user's view. Most people who use vi/vim are aware of the differences and wanted vi/vim just work if the other is not installed, so vi/vim are drop-in replacements for them in this matter of speaking. And Vi is just a Vim compiled more strictly nowadays, so it adds another confusion :) . But speaking technically, they aren't drop-in replacements because of different configuration options. I will drop alternatives usage and use wrappers - then it will work for immutable Fedoras too. On 1/30/21 7:41 PM, Fabio Valentini wrote: > On Sat, Jan 30, 2021 at 7:24 PM Peter Boy wrote: >> >> >>> Am 30.01.2021 um 17:45 schrieb Vitaly Zaitsev via devel >>> : >>> >>> On 30.01.2021 16:58, Peter Boy wrote: >>>> But it’s perfectly usable for Fedora Workstation or Server and almost >>>> indispensable for some development projects, e.g. Java (and vi/vim for a >>>> terminal environment). Why should alternatives not be usable there? Or >>>> what is a suitable and adequate replacement? >>> https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ >> Thanks for the info. Unfortunately, I don’t see a connection to immutable >> Fedora (it is about drop-in, user configurable, etc). Or do I miss something? > If you read the Packaging Guidelines, they actually explicitly mention > that vi / vim are a bad example for using the alternatives system - > because they're not drop-in replacements. > > Additionally, as far as I know, OSTree based Fedora variants do not > execute any RPM scriptlets, but implement their own handling of e.g. > ldconfig and such things. > And alternatives is definitely not compatible with OSTree - according > to these bug reports, at least Java alternatives are broken - > apparently primarily because OSTree stores configuration in /var > instead of /etc: > > - https://bugzilla.redhat.com/show_bug.cgi?id=1657367 > - https://github.com/coreos/rpm-ostree/issues/1614 > > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Help wanted] Setting vi/view/vim via alternatives
Hi all,
I'm currently trying to rewrite the current shell aliases for making
Vi/View/Vim use the correct compiled binary based on which Vim package
is installed. The current aliases have several downsides (don't work
with sudo, runs in subshell) so I got a recommendation for
'alternatives' which should solve all those issues.
But currently I'm stuck and I don't know how to debug - the current
patch (attached) should solve package installation, its upgrade and
removal via %post and %preun scriptlets, but whatever I do, the links
don't exist after package upgrade.
For debugging I used 'ls' in scriptlets, and the links existed at the
time the transaction was leaving the scriptlets. But the links don't
exist after the end of dnf transaction...
Would anyone mind helping me?
Thank you in advance,
Zdenek
--
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C
diff --git a/view_wrapper b/view_wrapper
new file mode 100644
index 000..f4c9b23
--- /dev/null
+++ b/view_wrapper
@@ -0,0 +1,3 @@
+#!/usr/bin/bash
+
+/usr/bin/vim -R "$@"
diff --git a/vim.csh b/vim.csh
deleted file mode 100644
index 47df221..000
--- a/vim.csh
+++ /dev/null
@@ -1,20 +0,0 @@
-# we need to use which twice - first for checking if
-# the command doesn't fail, the use it if doesn't fail
-set vim_cond = `command -v vim`
-set vi_cond = `command -v vi`
-
-switch ( $vim_cond-$vi_cond )
- case /usr/bin/vim-/usr/bin/vi:
- # apply only when founded vim and vi are in expected dirs from distro
- alias vi vim
- alias view 'vim -R'
- breaksw
- case -/usr/bin/vi:
- # apply only if founded vi is in expected dir from distro
- alias vim vi
- breaksw
-endsw
-
-# just in case
-unset vim_cond
-unset vi_cond
diff --git a/vim.fish b/vim.fish
deleted file mode 100644
index a35220d..000
--- a/vim.fish
+++ /dev/null
@@ -1,25 +0,0 @@
-# This will avoid user defined aliases and possibly stuff defined earlier in the PATH.
-# Redirecting is for the case when the binary is missing.
-set vim_cond (command -v vim)
-set vi_cond (command -v vi)
-
-switch "$vim_cond-$vi_cond"
- case /usr/bin/vim-/usr/bin/vi
- # apply only if founded vim and vi are in the expected dir from distro
- function vi
-command vim $argv
- end
-
- function view
-command vim -R $argv
- end
- case -/usr/bin/vi
- # apply only when no vim is installed and founded vi is in the expected dir from distro
- function vim
-command vi $argv
- end
-end
-
-# just in case
-set -e vim_cond
-set -e vi_cond
diff --git a/vim.sh b/vim.sh
deleted file mode 100644
index 2616693..000
--- a/vim.sh
+++ /dev/null
@@ -1,32 +0,0 @@
-__vi_internal_vim_alias()
-(
- # run vim if installed
- test -f /usr/bin/vim && exec /usr/bin/vim "$@"
-
- # run vi otherwise
- test -f /usr/bin/vi && exec /usr/bin/vi "$@"
-)
-
-__view_internal_vim_alias()
-(
- # run vim -R instead of view if vim installed
- test -f /usr/bin/vim && exec /usr/bin/vim -R "$@"
-
- # run view otherwise
- test -f /usr/bin/view && exec /usr/bin/view "$@"
-)
-
-
-if [ -n "${BASH_VERSION-}" -o -n "${KSH_VERSION-}" -o -n "${ZSH_VERSION-}" ]; then
- # This will avoid user defined aliases
- case "$(command -v vim)-$(command -v vi)" in
-"/usr/bin/vim-/usr/bin/vi" | "-/usr/bin/vi")
-# apply only when founded vim and vi are in expected dirs from distro
-# we need to call a shell function to avoid shell restarts when vi/vim
-# is being installed/uninstalled
-alias vi=__vi_internal_vim_alias
-alias view=__view_internal_vim_alias
-alias vim=__vi_internal_vim_alias
-;;
- esac
-fi
diff --git a/vim.spec b/vim.spec
index ce7d61b..3d02476 100644
--- a/vim.spec
+++ b/vim.spec
@@ -21,26 +21,26 @@ Summary: The VIM editor
URL: http://www.vim.org/
Name: vim
Version: %{baseversion}.%{patchlevel}
-Release: 2%{?dist}
+Release: 3%{?dist}
License: Vim and MIT
Source0: ftp://ftp.vim.org/pub/vim/unix/vim-%{baseversion}-%{patchlevel}.tar.bz2
-Source1: vim.sh
-Source2: vim.csh
-Source4: virc
-Source5: vimrc
-Source7: gvim16.png
-Source8: gvim32.png
-Source9: gvim48.png
-Source10: gvim64.png
+Source1: virc
+Source2: vimrc
+Source3: gvim16.png
+Source4: gvim32.png
+Source5: gvim48.png
+Source6: gvim64.png
+Source7: spec-template.new
+Source8: macros.vim
+Source9: vim-default-editor.sh
+Source10: vim-default-editor.csh
+Source11: vim-default-editor.fish
+Source12: view_wrapper
+
%if %{withvimspell}
-Source13: vim-spell-files.tar.bz2
+Source100: vim-spell-files.tar.bz2
%endif
-Source14: spec-template.new
-Source15: macros.vim
-Source16: vim-default-editor.sh
-Source17: vim-default-editor.csh
-Source18: vim-default-editor.fish
-Source19: vim.fish
+
Patch2002: vim-7.0-fixkeys
Re: Should the default editor be changed from vi to nano on upgrades to Fedora 33+
On 12/3/20 9:46 PM, Tom Hughes via devel wrote: > >> Also from that bug: >> https://bugzilla.redhat.com/show_bug.cgi?id=1896707#c13 >>> "dnf remove nano-default-editor". Alternatively, you can set "export >>> EDITOR=vim" in your ~/.bash_profile > > Setting EDITOR doesn't really work. I mean I have that but my problem > is always when I'm sudoing and suddenly get nano instead of vi which > isn't solved by that. Hi Tom, actually Vim ships vim-default-editor subpackage now, which conflicts with nano-default-editor via virtual provide 'system-default-editor'. It puts setting EDITOR environment variable into a file (vim-default-editor.sh for bash, ksh, sh and zsh, vim-default-editor.csh for tcsh and vim-default-editor.fish for fish), which is installed under a specific directory (/etc/profile.d for bash, tcsh, sh, ksh and zsh, /usr/share/fish/vendor_conf.d for fish). It sets EDITOR for all users. > > Tom > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_0x15AA6A7F4D4227D7.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: our containers with alias vim=vi
On 10/13/20 12:34 PM, Jonathan Wakely wrote:
> On 13/10/20 07:45 +0200, Zdenek Dohnal wrote:
>>
>> On 10/12/20 5:15 PM, Joe Doss wrote:
>>> On 10/12/20 1:50 AM, Zdenek Dohnal wrote:
>>>> This would break using Vim when vim-minimal and vim-enhanced are
>>>> installed (it would start Vi instead of typed Vim). To make it work,
>>>> vim-minimal would have to conflict with vim-enhanced, which doesn't
>>>> make
>>>> sense - Vi and Vim binaries can exist together just fine.
>>>
>>> I have vim-enhanced and vim-minimal installed
>>>
>>> # rpm -qa |grep vim
>>> vim-common-8.2.1770-1.fc33.x86_64
>>> vim-filesystem-8.2.1770-1.fc33.noarch
>>> vim-minimal-8.2.1770-1.fc33.x86_64
>>> vim-enhanced-8.2.1770-1.fc33.x86_64
>>>
>>> and when I type vi it launches vim.
>> I'm sorry I forgot about this alias - yes, there is an alias which is
>> applied when both - vim-minimal and vim-enhanced - are installed so it
>> launches 'vim' when you type 'vi'. I would say less people will complain
>> if something has more features than if it has less, so I'm content with
>> this alias.
>>>
>>> # whereis vi
>>> vi: /usr/bin/vi /usr/share/man/man1p/vi.1p.gz
>>> /usr/share/man/man1/vi.1.gz
>>> # /usr/bin/vi --version
>>> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Sep 29 2020 00:00:00)
>>>
>>> It doesn't look like these are existing together just fine. It seems
>>> that vim takes over vi. Shouldn't these conflict and only one can be
>>> installed over the other?
>> 'Vi' as the original project is no longer (I'm not sure for how long)
>> shipped in Fedora. 'Vi' we ship is just 'VIM' compiled with 'small' set
>> of features (f.e. without syntax highlighting) to mimic the original
>> 'Vi'. So if you run 'vi --version' it always shows 'VIM'.
>>>
>>>> In the end I find it incorrect to mislead users by default by telling
>>>> them 'Vim works' but Vi is run instead - Vi and Vim don't have the
>>>> same
>>>> set of features, which may lead into bug reports caused by this
>>>> mistake.
>>>
>>> Isn't that the reverse behavior detailed above? I type vi on Fedora
>>> Workstation it launches vim? I assume this isn't causing bug reports.
>> You're right, as I wrote above - aliasing vi->vim doesn't seem as a
>> problem to me, but aliasing vim->vi as clime suggested can cause mislead
>> for users.
>
> I would also appreciate if "vim" ran the executable installed by
> vim-minimal. I frequently type "vim" on servers I don't own and then
> grumble that it fails and I have to run "vi" instead. It **is** vim,
> it's just not installed with that name. Insisting that users call it
> vi when we know it's vim and they know it's vim seems unnecessary.
It's Vim but with a different set of features - VIM compiled as Vi
binary is trying to be small, kind of simulate Vi behavior without
setting 'compatible'.
Since you know it has less features, good for you. But unfortunately,
not all users know - there was already a report about Vim missing
highlighting, and the reporter was running /usr/bin/vi. So my aim is to
prevent such a report.
>
> $ rpm -qf /usr/bin/vi
> vim-minimal-8.2.1770-1.fc32.x86_64
>
> Could vim-minimal and vim-enhanced both install the same
> /etc/profile.d/vim.sh file that did something like this?
Installing the same file would mean to set conflicts between those two
package, wouldn't it? Or would you mind explaining how to achieve it?
>
> if [ -n "${BASH_VERSION-}" -o -n "${KSH_VERSION-}" -o -n
> "${ZSH_VERSION-}" ]; then
> [ "`/usr/bin/id -u 2>/dev/null || echo 0`" -le 200 ] && return
> # for bash and and ksh and zsh
> case "$(type -t vim)-$(type -t vi)" in
> file-file)
> # both vim and vi are present
> alias vi=vim
> alias view="vim -R"
> ;;
> -file)
> # only vim-minimal is installed, expose it as 'vim' too
> alias vim=vi
> ;;
> esac
> fi
>
Looks good, although it doesn't touch the problem mistaking Vi and Vim
as I said before. I tried to come up with a little bash script which
will mention it really runs vi instead of typed vim (just the important
snippet):
alias vim="read -rep $'No vim found, using vi, press ENTER to
continue\n'
Re: our containers with alias vim=vi
On 10/13/20 12:57 PM, Jonathan Wakely wrote: > On 13/10/20 10:53 +0200, Zdenek Dohnal wrote: >> On 10/12/20 9:34 PM, clime wrote: >>> On Mon, 12 Oct 2020 at 07:39, Zdenek Dohnal wrote: >>>> On 10/10/20 2:37 PM, clime wrote: >>>>> Hello, >>>>> >>>>> could Fedora and CentOS containers for docker and podman come with >>>>> `alias vim=vi` in ~/.bashrc? >>>>> >>>>> I would very much welcome it as I am used to type vim everywhere but >>>>> if vi starts instead I am happy too. I know that the solution is to >>>>> create a customized container but often I want to try something on >>>>> vanilla containers from the whole range. >>>> IMHO it is not a good idea. Some users which don't have to know the >>>> problem can run 'vi' while thinking they run 'vim' and be surprised >>>> that >>>> most 'Vim' features don't work and they will file a bug tickets, which >>>> will be irrelevant, consuming reporter's&maintainer's time. >>> well, it would be good if vim itself display in which mode it runs. >>> So then >>> if I run "vim", I get "vi", i will know, ok, i got only the stripped >>> down version >>> because i am in a container and the "extension" is not yet installed. >> I'm not sure if this can be done within Vim as app, but I'm checking if >> I cannot do some bash magic to achieve this. >>> >>> I would very much appreciate it as a user (about 16 years) of the >>> great vim. >>> >>> Usually in a vanilla container, i just want to run an editor quickly >>> to look at a file or >>> quickly edit something - i don't really care about user experience >>> because if I did, >>> I would already customized the container. >> I understand your point of view, it is really annoying for people who >> know the problem, although as a maintainer I must be cautious about >> generic/default settings because it influences all users, not just >> container's users. > > And yet /etc/profile.d/vim.sh will happily stomp on my own shell > functions or self-installed 'vi' executables :-) > > This isn't a problem for me in practice, because I don't have any > functions or self-installed 'vi' commands. I just find it inconsistent > that the existing script doesn't use the same caution. To be honest, it was added by the previous maintainer, and if I'm not sure about what was behind the decision to make this way, I don't touch it till someone complains. But for the new stuff I tend to apply caution with my best effort. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_0x15AA6A7F4D4227D7.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: our containers with alias vim=vi
On 10/12/20 9:34 PM, clime wrote: > On Mon, 12 Oct 2020 at 07:39, Zdenek Dohnal wrote: >> On 10/10/20 2:37 PM, clime wrote: >>> Hello, >>> >>> could Fedora and CentOS containers for docker and podman come with >>> `alias vim=vi` in ~/.bashrc? >>> >>> I would very much welcome it as I am used to type vim everywhere but >>> if vi starts instead I am happy too. I know that the solution is to >>> create a customized container but often I want to try something on >>> vanilla containers from the whole range. >> IMHO it is not a good idea. Some users which don't have to know the >> problem can run 'vi' while thinking they run 'vim' and be surprised that >> most 'Vim' features don't work and they will file a bug tickets, which >> will be irrelevant, consuming reporter's&maintainer's time. > well, it would be good if vim itself display in which mode it runs. So then > if I run "vim", I get "vi", i will know, ok, i got only the stripped > down version > because i am in a container and the "extension" is not yet installed. I'm not sure if this can be done within Vim as app, but I'm checking if I cannot do some bash magic to achieve this. > > I would very much appreciate it as a user (about 16 years) of the great vim. > > Usually in a vanilla container, i just want to run an editor quickly > to look at a file or > quickly edit something - i don't really care about user experience > because if I did, > I would already customized the container. I understand your point of view, it is really annoying for people who know the problem, although as a maintainer I must be cautious about generic/default settings because it influences all users, not just container's users. > > I wonder if typing vi instead of "vim" on my computer has any effect. > I am quite positive > that it had at some point in time but not sure about nowadays. I would say PackageKit (IIUC) stepped in and told you: 'vim is not installed, do you want to install?' But I'm not sure if it is installed by default (in container or normal OS) or if it even works nowadays this way. > > clime > >> This problem should be solved by user (when he know there is no Vim and >> excepts to use Vi, then he creates alias) or by installing vim-enhanced. >> >> -- >> Zdenek Dohnal >> Software Engineer >> Red Hat Czech - Brno TPB-C >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > _______ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_0x15AA6A7F4D4227D7.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: our containers with alias vim=vi
On 10/12/20 5:15 PM, Joe Doss wrote: > On 10/12/20 1:50 AM, Zdenek Dohnal wrote: >> This would break using Vim when vim-minimal and vim-enhanced are >> installed (it would start Vi instead of typed Vim). To make it work, >> vim-minimal would have to conflict with vim-enhanced, which doesn't make >> sense - Vi and Vim binaries can exist together just fine. > > I have vim-enhanced and vim-minimal installed > > # rpm -qa |grep vim > vim-common-8.2.1770-1.fc33.x86_64 > vim-filesystem-8.2.1770-1.fc33.noarch > vim-minimal-8.2.1770-1.fc33.x86_64 > vim-enhanced-8.2.1770-1.fc33.x86_64 > > and when I type vi it launches vim. I'm sorry I forgot about this alias - yes, there is an alias which is applied when both - vim-minimal and vim-enhanced - are installed so it launches 'vim' when you type 'vi'. I would say less people will complain if something has more features than if it has less, so I'm content with this alias. > > # whereis vi > vi: /usr/bin/vi /usr/share/man/man1p/vi.1p.gz /usr/share/man/man1/vi.1.gz > # /usr/bin/vi --version > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Sep 29 2020 00:00:00) > > It doesn't look like these are existing together just fine. It seems > that vim takes over vi. Shouldn't these conflict and only one can be > installed over the other? 'Vi' as the original project is no longer (I'm not sure for how long) shipped in Fedora. 'Vi' we ship is just 'VIM' compiled with 'small' set of features (f.e. without syntax highlighting) to mimic the original 'Vi'. So if you run 'vi --version' it always shows 'VIM'. > >> In the end I find it incorrect to mislead users by default by telling >> them 'Vim works' but Vi is run instead - Vi and Vim don't have the same >> set of features, which may lead into bug reports caused by this mistake. > > Isn't that the reverse behavior detailed above? I type vi on Fedora > Workstation it launches vim? I assume this isn't causing bug reports. You're right, as I wrote above - aliasing vi->vim doesn't seem as a problem to me, but aliasing vim->vi as clime suggested can cause mislead for users. > > Joe > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_0x15AA6A7F4D4227D7.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Introducing vim-default-editor subpackage - replace nano as a default editor if wanted
On 10/12/20 2:16 PM, Neal Gompa wrote: > On Mon, Oct 12, 2020 at 5:25 AM Zdenek Dohnal wrote: >> Hi, >> >> thanks to Pawel Marciniak's pull request [1] I'm happy to announce >> vim-default-editor subpackage, which easily sets/removes Vim as the >> default editor by installing/uninstalling the subpackage. >> >> Because of nano was selected as a default editor since Fedora 33+, the >> new subpackage conflicts with nano-default-editor subpackage to ensure >> the correct behavior. It means the dnf transaction needs to use >> '--allowerasing' option when installing vim-default-editor is going to >> be installed and nano-default-editor is already installed and vice versa. >> >> Vim's NVR which introduced the subpackage is 2:8.2.1815-2, the build >> containing the subpackage will go into updates for F31+ tomorrow. >> >> Enjoy when it comes to the updates! >> >> [1] https://src.fedoraproject.org/rpms/vim/pull-request/11 >> > There are two significant problems with this package: > > 1. It doesn't work for Fish, since Fish doesn't actually *read* > profile.d (did you look at how nano-default-editor *actually* set > things up?) D'oh... I checked whether the code brought by .fish file works in fish shell, but didn't check the dir the file is put in... my bad, sorry. > > 2. Having subpackages like this that conflict by name is going to get > crazy really fast, so we need a virtual name to make RPM only permit > one of them at a time. Agree. I will review and test your PR tomorrow, thanks for that. > > > And really, why do you need this instead of just uninstalling the > nano-default-editor package? Vim is the POSIX default already... Actually, AFAIK 'Vi' (I know, it is just Vim compiled with small features, but still...) is the POSIX default. The change sets 'Vim'. And since POSIX is probably not known for newcomers, this subpackage can come in handy for them. > > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_0x15AA6A7F4D4227D7.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Introducing vim-default-editor subpackage - replace nano as a default editor if wanted
Hi, thanks to Pawel Marciniak's pull request [1] I'm happy to announce vim-default-editor subpackage, which easily sets/removes Vim as the default editor by installing/uninstalling the subpackage. Because of nano was selected as a default editor since Fedora 33+, the new subpackage conflicts with nano-default-editor subpackage to ensure the correct behavior. It means the dnf transaction needs to use '--allowerasing' option when installing vim-default-editor is going to be installed and nano-default-editor is already installed and vice versa. Vim's NVR which introduced the subpackage is 2:8.2.1815-2, the build containing the subpackage will go into updates for F31+ tomorrow. Enjoy when it comes to the updates! [1] https://src.fedoraproject.org/rpms/vim/pull-request/11 -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_0x15AA6A7F4D4227D7.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: our containers with alias vim=vi
On 10/10/20 5:57 PM, Joe Doss wrote: > On 10/10/20 7:37 AM, clime wrote: >> Didn't want to write about this first but maybe there are more people >> with the same problem. > > You are not alone. I had to set the same alias for Fedora CoreOS > because I kept typing vim out of habit and FCOS ships vim-minimal. It > was driving me nuts. > > Maybe the vim-minimal package needs the alias instead? This would break using Vim when vim-minimal and vim-enhanced are installed (it would start Vi instead of typed Vim). To make it work, vim-minimal would have to conflict with vim-enhanced, which doesn't make sense - Vi and Vim binaries can exist together just fine. In the end I find it incorrect to mislead users by default by telling them 'Vim works' but Vi is run instead - Vi and Vim don't have the same set of features, which may lead into bug reports caused by this mistake. > I have been adding the alias on my end because it felt like a personal > problem on my end, but I am sure there are more of us. > > Joe > > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_0x15AA6A7F4D4227D7.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: our containers with alias vim=vi
On 10/10/20 2:37 PM, clime wrote: > Hello, > > could Fedora and CentOS containers for docker and podman come with > `alias vim=vi` in ~/.bashrc? > > I would very much welcome it as I am used to type vim everywhere but > if vi starts instead I am happy too. I know that the solution is to > create a customized container but often I want to try something on > vanilla containers from the whole range. IMHO it is not a good idea. Some users which don't have to know the problem can run 'vi' while thinking they run 'vim' and be surprised that most 'Vim' features don't work and they will file a bug tickets, which will be irrelevant, consuming reporter's&maintainer's time. This problem should be solved by user (when he know there is no Vim and excepts to use Vi, then he creates alias) or by installing vim-enhanced. -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_0x15AA6A7F4D4227D7.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Where did my keys go in Thunderbird?
Hi Thunderbird users, I'm not sure if you noticed, but Thunderbird got a major update for F31+, which removes XUL extensions - f.e. Enigmail is not working anymore. However, if you are using keys to your emails, don't panic and start digging into metadata to somehow recover your keys. If you go to Tools->Migrate Enigmail settings, then you are able to recover all stuff. Hope the info will save a time for someone since I wasn't looking carefully in the menu and started digging the metadata beforehand... Have a nice day, Zdenek -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_0x15AA6A7F4D4227D7.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[golang packaging] how to get files from source tarball
Hi,
I'm trying to package ipp-usb project
(https://github.com/OpenPrinting/ipp-usb) which is written in Go. I
generated spec file via go2rpm, but several files from source tarball
which supposed to be packaged is not packaged e.g. systemd unit file
ipp-usb.service or udev rule file 71-ipp-usb.rules.
I managed to package those files with following install command e.g.:
install -m 0644 -vp
%{gobuilddir}/src/github.com/OpenPrinting/ipp-usb/systemd-udev/*.rules
%{buildroot}%{_udevrulesdir}
but '%{gobuilddir}/src/github.com/OpenPrinting/ipp-usb' is quite ugly -
is there a predefined golang macro for such path? Or a best practice?
Thank you in advance,
Zdenek
--
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change: Python Upstream Architecture Names (Self-Contained Change)
ant user visible upgrade/compatibility problem is anticipated. > Filenames will be different, but the old filenames are still supported. > Scripts that hardcode filename assumptions might break. > > == How To Test == > On ppc64le, try to install a manylinux wheel and import from it. It > should work on any Python ≥ 3.5. E.g.: > > pip install simple-manylinux-demo > python -c 'from dummyextension import extension' > > On ppc64le, try to build a manylinux wheel and import from it on > another Linux. It should work on any Python ≥ 3.5. E.g.: > > pip wheel . # on some project with extension module > auditwheel repair ...whl > wormhole send ...whl # or any other way > > On another ppc64le Linux (such as Debian or openSUSE): > > wormhole receive ... > pip install ...whl > python -c 'from ... import ...' > > You can also build a regular (non-manylinux) wheel on Fedora 33/32 and > install and import it on Fedora 34. It should work. > The other way around will most likely also work, unless Fedora 34 has > an incompatible glibc update. > > == User Experience == > Users of ppc64le and armv7hl Fedora (and future RHEL) will have a > closer-to-upstream Python experience and will no longer suffer from > compatibility issues when they install or build manylinux wheels. > > == Dependencies == > No known dependencies. May the force be with us. > > == Contingency Plan == > * Contingency mechanism: Revert the change and rebuild all affected packages. > * Contingency deadline: Soft before the mass rebuild, so we could > leverage it for the revert-rebuilds. Hard before the beta freeze. > * Blocks release? No > * Blocks product? No > > == Documentation == > This page is the documentation. > > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Koji doesn't work due 'No space left on device'
It seems koji is just overloaded. On 8/20/20 2:07 PM, Zdenek Dohnal wrote: > Hi all, > > Koji seems to be broken now. Builds/scratch builds fail with: > > Fault: : [Errno 28] No space left on device: > '/mnt/koji/work/tasks/6134/49706134'"> > > Links to build: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=49706133 > > Do we have a ticket for this outage? > > Thank you in advance, > > Zdenek > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Koji doesn't work due 'No space left on device'
Hi all, Koji seems to be broken now. Builds/scratch builds fail with: Fault: : [Errno 28] No space left on device: '/mnt/koji/work/tasks/6134/49706134'"> Links to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=49706133 Do we have a ticket for this outage? Thank you in advance, Zdenek -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New libxmlb 0.2.0 which breaks API and ABI
On 8/19/20 5:04 PM, Richard Hughes wrote: > On Wed, 19 Aug 2020 at 14:57, Mohan Boddu wrote: >> It seems like gnome-firmware also needs it and due to that both >> rawhide and branched composes failed today. > I had no idea, my apologies! You can check which packages depend on your library: $ dnf repoquery --whatrequires libxmlb* in the future. > > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
release-monitoring doesn't file a new bugzilla ticket when new version comes
Hi all, I have a problem (SSIA) with release-monitoring. I have a following project (sane-airscan): https://release-monitoring.org/project/121086/ which usually has a new version weekly or once in two weeks, but I haven't got any new bug about new version being released yet. Usually the project has a green status (I would say if the configuration was wrong, the status would have been bad from the start), but it turns red if there is a new version with error "No upstream version found" - but new version is correctly showed in 'Versions' table below. Then, when I try to fix it, I tweak with project settings several times and after some time I return to original settings and the project status is green now... Would anyone mind helping me with it? Thank you in advance, Zdenek -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HOWTO] Keep using Rawhide after branching
Thanks for the Howto, Víťa! Helps a lot! On 8/17/20 1:42 PM, Vít Ondruch wrote: > Just as a reminder to all Rawhide users, this is the easiest way to keep > using Rawhide after branching: > > > ~~~ > > $ sudo dnf update fedora-gpg-keys > > $ sudo dnf update fedora-repos --release 34 > > ~~~ > > > Unfortunately, there has been no progress on [1] during past months. > > > > Vít > > > > [1] https://pagure.io/releng/issue/7445 > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Driverless scanning for WSD and ESCL supported scanners is coming
On 8/6/20 4:37 PM, Robert Marcano via devel wrote: > On 8/6/20 3:48 AM, Zdenek Dohnal wrote: >> On 8/5/20 2:30 PM, Jiří Eischmann wrote: >>> >>> Will it be possible to use a Fedora machine as a server, so that I >>> can >>> have an old scanner connected to it via USB and then shared with other >>> devices on the local network via those protocols? >>> That would be neat. >>> >>> Jiri >> >> Hi Jirka, >> >> IIRC it is possible even now via saned on the server, but saned doesn't >> use WSD or ESCL, just simple TCP transfer between client and server. >> >> In practice it looks like - you have a proprietary or sane-backends >> supported USB scanner (sane-airscan doesn't work for USB devices), you >> set up ACL on saned and setup clients to connect to the server. > > From the README, it looks like some manufacturers allow eSCL to work > over USB too: > > However, most (all?) of the eSCL devices will also work over USB, if > IPP-over-USB daemon is installed on your computer > > and some are even USB only: > > [2]: this device is USB-only, but it works well with the IPP-over-USB > daemon. > > I hope this becomes a trend for non networked scanners too. I had a suspicion ipp-over-usb daemon like ipp-usb or ippusbxd could help, but I wasn't sure (it was created for supporting USB printer devices), so didn't want to spread any mystification. ipp-over-usb daemons - ipp-usb and ippusbxd - are on my list what to package, they will come into Fedora this year (I hope). > >> >> sane-airscan is a backend for communication with scanner supporting >> WSD/ESCL, it doesn't use those protocols for sharing the device. >> >> Zdenek >> >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Driverless scanning for WSD and ESCL supported scanners is coming
On 8/5/20 10:04 PM, Robert Marcano via devel wrote: > On 8/5/20 8:30 AM, Jiří Eischmann wrote: >> Zdenek Dohnal píše v St 05. 08. 2020 v 07:44 +0200: >>> Hi all, >>> >>> I would like to announce sane-airscan project [1] will be shipped in >>> the >>> official Fedora repositories from Fedora 32 [2]. >>> >>> sane-airscan implements a backend for Microsoft WSD and ESCL (usually >>> called AirScan, originating from Apple) protocols, which are common >>> in >>> newer (2012+) scanners and multi-function devices for scanning. >>> >>> Using sane-airscan, newer devices don't need vendor proprietary >>> software >>> for scanning any longer (e.g. hplip with its hp-plugin). >>> >>> The project is divided into main package - sane-airscan - which >>> contains >>> helper tool - airscan-discover - for discovering devices in setups, >>> where automatic DNS-SD discovery doesn't do the trick, and subpackage >>> - >>> libsane-airscan - which the main package requires and the common >>> known >>> project for scanning - sane-backends - will require to get the >>> backend >>> into common scanning stack installation. >>> >>> Please feel free to test it. >> >> Will it be possible to use a Fedora machine as a server, so that I can >> have an old scanner connected to it via USB and then shared with other >> devices on the local network via those protocols? >> That would be neat. > > If your clients are SANE supported OSs, you can already do that with > saned. For example this documentation > > https://wiki.debian.org/SaneOverNetwork That's what I get if I don't finish an email at once :) you were faster :) > > >> >> Jiri >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Driverless scanning for WSD and ESCL supported scanners is coming
On 8/5/20 2:30 PM, Jiří Eischmann wrote: > > Will it be possible to use a Fedora machine as a server, so that I can > have an old scanner connected to it via USB and then shared with other > devices on the local network via those protocols? > That would be neat. > > Jiri Hi Jirka, IIRC it is possible even now via saned on the server, but saned doesn't use WSD or ESCL, just simple TCP transfer between client and server. In practice it looks like - you have a proprietary or sane-backends supported USB scanner (sane-airscan doesn't work for USB devices), you set up ACL on saned and setup clients to connect to the server. sane-airscan is a backend for communication with scanner supporting WSD/ESCL, it doesn't use those protocols for sharing the device. Zdenek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Driverless scanning for WSD and ESCL supported scanners is coming
On 8/5/20 10:07 AM, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 05 August 2020 at 07:44, Zdenek Dohnal wrote: >> Hi all, >> >> I would like to announce sane-airscan project [1] will be shipped in the >> official Fedora repositories from Fedora 32 [2]. >> >> sane-airscan implements a backend for Microsoft WSD and ESCL (usually >> called AirScan, originating from Apple) protocols, which are common in >> newer (2012+) scanners and multi-function devices for scanning. >> >> Using sane-airscan, newer devices don't need vendor proprietary software >> for scanning any longer (e.g. hplip with its hp-plugin). > This is great news, thanks to you and Alexander Pevzner for making it > happen. It makes me smile even if my current printer is not supported > and still requires hp-plugin. Hi Dominik, if your device is capable of AirPrint (is network printer+has enabled IPP+capable to be installed as '-m everywhere' model via lpadmin), there is a good chance (unless you are unlucky like me with Laserjet m1536dnf - supports AirPrint, but not AirScan) that it supports AirScan too. > > Regards, > Dominik -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Driverless scanning for WSD and ESCL supported scanners is coming
Hi all, I would like to announce sane-airscan project [1] will be shipped in the official Fedora repositories from Fedora 32 [2]. sane-airscan implements a backend for Microsoft WSD and ESCL (usually called AirScan, originating from Apple) protocols, which are common in newer (2012+) scanners and multi-function devices for scanning. Using sane-airscan, newer devices don't need vendor proprietary software for scanning any longer (e.g. hplip with its hp-plugin). The project is divided into main package - sane-airscan - which contains helper tool - airscan-discover - for discovering devices in setups, where automatic DNS-SD discovery doesn't do the trick, and subpackage - libsane-airscan - which the main package requires and the common known project for scanning - sane-backends - will require to get the backend into common scanning stack installation. Please feel free to test it. Have a nice day, Zdenek [1] https://github.com/alexpevzner/sane-airscan [2] https://bodhi.fedoraproject.org/updates/FEDORA-2020-841f4ce8df -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: We have to talk about annobin... again
Hi all, I just want to warn you the error got into Fedora 32 too. The symptoms are the same - not being able to build on aarch64 due 'gcc is not able to create executables'. Builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=48241569 https://koji.fedoraproject.org/koji/taskinfo?taskID=48234800 On 7/25/20 11:33 AM, Neal Gompa wrote: > Hey all, > > So I was trying to update libseccomp last night, and I was able to > build it for everything except aarch64 on Rawhide because it says the > compiler can't build executables[1]. > > Looking a bit closer, it looks like the compiler stack is out of sync > again with annobin. > > Is there anything that can be done to keep the compiler teams from > submitting gcc into rawhide without doing the required rebuild cycle > to make it so annobin works? > > And we're going to have the same problem with clang now that annobin > grew a clang plugin, so I would want neither LLVM nor GCC to land in > Rawhide unless those teams are literally ensuring that annobin isn't > breaking the compiler afterward. > > I'm personally very tired of having the compiler break so frequently > because of that plugin. Either some kind of mechanism to hold back GCC > builds until annobin works is implemented, or I'd much rather see the > whole thing go away. Obviously, you could just *bundle* annobin into > the GCC package and build it together to ensure it never broke, but > that option was discarded already[2]. > > Somebody fix it. ASAP. > > [1]: https://koji.fedoraproject.org/koji/taskinfo?taskID=47796366 > [2]: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2DXP7WE2TY2Q2ZTW4L5R5WO5UJVKXESB/ > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: vim has lost it's damn mind
Hi all, first I would like to recommend you to try the steps here: https://vimhelp.org/vim_faq.txt.html#faq-2.5 it should help you find out where the problem can be. If you are able to reproduce the issue with the first step, please file a bug on bugzilla.redhat.com. Thank you in advance! On 7/29/20 7:52 AM, Tomasz Torcz wrote: > On Sat, Jul 25, 2020 at 08:21:53AM -0500, Richard Shaw wrote: >> After upgrading to Fedora 32 I've noticed when editing files, especially >> spec files that vim does some crazy jumps/indents that it didn't do before. >> >> Right now I'm pressing i to insert a line before a Requires: and when I hit >> enter it jumps to the next line (fine) but with 4 indents and one space... >> WTF? >> >> Anyone else seeing strange vim behavior? > I've noticed overzealous indent while editing yaml files. I wanted > to provide example when it turned out vim also _unindents_. This is > quite jarring. > > Example: edit a yaml file, write > #v+ > some: text > #v- > > Press ENTER, cursor goes to the next line, indented 2 space. Write more: > #v+ > some: text > write > #v- > > As soon as you put “:”, whole line gets _moved back_: > #v+ > some: text > write: more > #v- > > Ugh. > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
Hi Till, I sent a question to Vim mailing list: https://groups.google.com/g/vim_dev/c/931nvz1TKyg On 6/29/20 10:47 AM, Till Maas wrote: > Hi, > > On Thu, Jun 25, 2020 at 06:48:56PM -0700, Adam Williamson wrote: > >> Nothing in vi's default view (if launched with a file, which is what >> happens in this case) tells you you need to press 'insert' in order to >> actually edit anything. Nothing in vi's default view tells you you have >> to type the entirely cryptic sequence ":wq" to save and exit (or gives > since vim addresses this when opened without a file and it is open > source, it seems to me to be a good idea to propose to adjust vim > behaviour to show the help overview when opening a file as well. For > example if there is no ~/.vimrc or some other indicator that shows the > user does not know vim, yet. > > Did someone discuss improving the novice user experience with the vim > developers, yet? What was the outcome? > > Thanks > Till > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
Sorry for duplicate, it was already answered. On 6/29/20 7:10 AM, Zdenek Dohnal wrote: > Spoiler alert :) > > It already does. > > On 6/26/20 3:41 PM, Jaroslav Skarvada wrote: >> - Original Message - >>> Adam Williamson < adamw...@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道： >>> >>> >>> On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote: >>>> What about to provide a prompt to the user telling them the difference >>>> between editors? >>>> For example, when a new user to fedora first invokes git commit >>>> without $EDITOR set, a program named fedora-default-editor comes up >>>> and asks: Which editor do you like? >>>> User can do his or hers choice and the choice will be remembered by >>>> setting $EDITOR in his or hers ~/.bashrc >>>> >>>> The fedora-default-editor can be a small script that shows user all >>>> the difference and set $EDITOR for the user. >>> It's a nice idea, but the problem with things like this is they >>> *always* introduce bugs, and often wind up being unmaintained, because >>> keeping them working is kind of a thankless task. >>> >>> IMHO it's better to keep things simple and just pick a default. And the >>> default should definitely be nano. :D >>> Then I will +1 for this proposal. Yes, this certainly will make Fedora >>> easier >>> use for beginners. And for those who would like to use vi as default, we >>> should make this as easy as possible. >>> >>> I has been asked "how to exit this hell?" multiple times by my new-to-Linux >>> friends, that time I would always suggest them to set nano as default. Vim >>> is great though, it is not for beginners. >>> >> Why not just patch vim-minimal to show the hint on the CTRL+C? >> Problem solved :) >> >> Jaroslav >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > _______ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
Spoiler alert :) It already does. On 6/26/20 3:41 PM, Jaroslav Skarvada wrote: > > - Original Message - >> >> Adam Williamson < adamw...@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道： >> >> >> On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote: >>> What about to provide a prompt to the user telling them the difference >>> between editors? >>> For example, when a new user to fedora first invokes git commit >>> without $EDITOR set, a program named fedora-default-editor comes up >>> and asks: Which editor do you like? >>> User can do his or hers choice and the choice will be remembered by >>> setting $EDITOR in his or hers ~/.bashrc >>> >>> The fedora-default-editor can be a small script that shows user all >>> the difference and set $EDITOR for the user. >> It's a nice idea, but the problem with things like this is they >> *always* introduce bugs, and often wind up being unmaintained, because >> keeping them working is kind of a thankless task. >> >> IMHO it's better to keep things simple and just pick a default. And the >> default should definitely be nano. :D >> Then I will +1 for this proposal. Yes, this certainly will make Fedora easier >> use for beginners. And for those who would like to use vi as default, we >> should make this as easy as possible. >> >> I has been asked "how to exit this hell?" multiple times by my new-to-Linux >> friends, that time I would always suggest them to set nano as default. Vim >> is great though, it is not for beginners. >> > Why not just patch vim-minimal to show the hint on the CTRL+C? > Problem solved :) > > Jaroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
s running git commit will be able to just type their > commit message, rather than having to learn about insert mode, and > they'll be able to cut and paste without having to learn special > shortcuts. > > == Dependencies == > > No additional dependencies are required. > > == Contingency Plan == > The contingency plan is to revert the change by removing the > nano-editor package. > > * Contingency deadline: probably the beta? It's an easy change to revert. > * Blocks release? If the change breaks the redirection to an editor, > it should block the release. However, this is unlikely. > * Blocks product? Potentially all. > > == Documentation == > As part of this change, it would be good to add instructions for > changing the default editor to the > [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs]. > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past
On 6/17/20 11:03 AM, Tomasz Kłoczko wrote: > > Zdenek have kind of question: why there are so many patches in the > hplip package? > Is it any problem with accepting Fedora patches by source tree maintainer? Yes, it is - HP upstream is unresponsive in most bugfix cases. > Is there any git or other VCS repo with source tree? (I don't see it > on launchpad) Unfortunately, there isn't. HP's vision of open source is releasing source tarball, not sharing any github/CVS repo for hplip. My predecessors - twaugh and jpopelka - started a github repo for hplip to track at least changes between releases, and I keep it up to date - https://github.com/zdohnal/hplip . There were considerations whether to fork the project, merge the patches and have it like that, but it would cut us off from new drivers, which come from HP, because they have access to HW. > > kloczek > -- > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past
Hi Tomasz, thank you for testing! Unfortunately, IMO hpcups still loads the plugin... I checked the code and hpcups doesn't look into models.dat - it loads the plugin either way, entry in models.dat seems to be checked only during print queue installation :( . I have the same experience with scanning on my HP laserjet m1536... it actually just loads older plugin anyway... So it wouldn't work on machines were no previous plugin installed. I'll revert the upstream change and report it. On 6/16/20 5:11 PM, Tomasz Torcz wrote: > On Tue, Jun 16, 2020 at 03:21:35PM +0200, Zdenek Dohnal wrote: >> There isn't a sucg list, but basically you can check git log at >> https://github.com/zdohnal/hplip . > Thanks, > > So I have HP M1132 MFT 2 and it basically works wi 3.20.6 and WITHOUT > plugin. yay!! > > It's not troublefree, yet: > 1) after installing 3.20.6, priting did not work > cze 16 15:28:27 mother.pipebreaker.pl hpcups[1425079]: common/utils.c > 177: validate_plugin_version() Plugin version[3.20.5] mismatch with HPLIP > version[3.20.6] > cze 16 15:28:27 mother.pipebreaker.pl hpcups[1425079]: common/utils.c > 210: Plugin version is not matching > > 2) I've removed hplip.state file, this caused another error: > cze 16 15:44:55 mother.pipebreaker.pl hpcups[1430487]: common/utils.c 116: > unable to open /var/lib/hp/hplip.state: No such file or directory > cze 16 15:44:55 mother.pipebreaker.pl hpcups[1430487]: common/utils.c 166: > validate_plugin_version() Failed to get Plugin version from > [/var/lib/hp/hplip.state] > cze 16 15:44:55 mother.pipebreaker.pl hpcups[1430487]: common/utils.c 210: > Plugin version is not matching > > 3) finally, I've edited /var/lib/hp/hplip.state changing version, now it > contains: > -- > [plugin] > installed = 0 > eula = 1 > version = 3.20.6 > -- > > And printing works. What's interesting, the value of installed= seem > irrelevant. > > (above is on Fedora 31) > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past
On 6/16/20 11:28 PM, Kevin Kofler wrote: > Zdenek Dohnal wrote: >> Do you mean GPL as a license? > Yes. By "the GPL driver", I mean the driver itself, which is under the GPL > and/or compatible licenses, as opposed to the proprietary plugin. Oh, sorry - when I read driver, I usually come up with associations like PostScript driver, PDF driver, zjstream driver - based on what stuff goes out of filtering chain. Professional deformation I guess :) > >> Either way, HP upstream makes new releases, but with not so much/any new >> features or bugfixes. Mostly adding some new PPDs. > This is quite unfortunate, because several printers are stuck requiring the > plugin because of formerly patented algorithms whose patents have since > expired, at least JBIG 1. You're right. Unfortunately, upstream's responses are scarce... you can try to approach them at https://bugs.launchpad.net/opensuse/+source/hplip/+bug/1831091 . > >> Only jbig2 thing I recall is jbig2dec package which is in Fedora. > Sorry, my mistake, it is actually JBIG 1 that is used, not JBIG 2. JBIG 1 is > implemented by jbigkit, which you now maintain in Fedora. It has been in > Fedora for 2 years now because the patent has expired. JBIG 1 is the core of > several of the protocols implemented by the proprietary HPLIP plugin, as > evidenced by the alternative drivers (foo2zjs etc.) for those printers > depending on jbigkit. But unfortunately, the plugin does not just implement > JBIG 1 directly, but large parts of the affected protocols are hidden inside > the plugin, so it is not straightforward to produce a drop-in replacement > for it. Thanks for the explanation! I didn't know that, because I had my hands full with other printing packages, so I haven't had time to look into jbigkit circumstances yet. Thanks! > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past
Oh, so the link in downloading script needs to be fixed too. Thank you for the link! On 6/16/20 3:35 PM, Tomasz Torcz wrote: > On Tue, Jun 16, 2020 at 03:23:10PM +0200, Zdenek Dohnal wrote: >> And please don't try to reinstall plugin. It seems they haven't built a >> new one yet or they aren't planning to. >> >> See http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ > Here it is: > https://developers.hp.com/hp-linux-imaging-and-printing/plugins > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past
On 6/16/20 3:21 PM, Kevin Kofler wrote: > Zdenek Dohnal wrote: >> HPLIP released a new version 3.20.6, where most models, which previously >> required HP plugin, were set to do not require plugin anymore. >> >> Although requirement of HP plugin was questionable with some printer >> models, other models may really needed it and they will not work without >> it. > So did they finally implement JBIG2 in the GPL driver? The patent expired a > couple years ago. Do you mean GPL as a license? Either way, HP upstream makes new releases, but with not so much/any new features or bugfixes. Mostly adding some new PPDs. Only jbig2 thing I recall is jbig2dec package which is in Fedora. > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past
And please don't try to reinstall plugin. It seems they haven't built a new one yet or they aren't planning to. See http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ On 6/16/20 3:01 PM, Zdenek Dohnal wrote: > > Hi all, > > I'm HPLIP maintainer in Fedora and I would like to ask *the users > which have HP printers which needed their HP plugin to test the > scratch build* of new hplip. > > HPLIP released a new version 3.20.6, where most models, which > previously required HP plugin, were set to do not require plugin anymore. > > Although requirement of HP plugin was questionable with some printer > models, other models may really needed it and they will not work > without it. > > Please try the following scratch builds: > > Rawhide: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=45790790 > > F32: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=45790902 > > F31: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=45790908 > > And if the update breaks printing or scanning for you, please let the > upstream know here: > > https://bugs.launchpad.net/hplip > > > Thank you in advance for helping with testing! > > > Zdenek > > -- > Zdenek Dohnal > Software Engineer > Red Hat Czech - Brno TPB-C > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past
There isn't a sucg list, but basically you can check git log at https://github.com/zdohnal/hplip . On 6/16/20 3:14 PM, Tomasz Torcz wrote: > On Tue, Jun 16, 2020 at 03:01:22PM +0200, Zdenek Dohnal wrote: >> Hi all, >> >> I'm HPLIP maintainer in Fedora and I would like to ask *the users which >> have HP printers which needed their HP plugin to test the scratch build* >> of new hplip. >> >> HPLIP released a new version 3.20.6, where most models, which previously >> required HP plugin, were set to do not require plugin anymore. > Is there a list of printers not requiring plugin anymore? > Downloading this plugin was the most cumbersome. In line with > Murphys's laws, I was noticing hplip was upgraded, and thus requiring > re-downloading plugin, when I had to print/scan something urgently. > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past
Hi all, I'm HPLIP maintainer in Fedora and I would like to ask *the users which have HP printers which needed their HP plugin to test the scratch build* of new hplip. HPLIP released a new version 3.20.6, where most models, which previously required HP plugin, were set to do not require plugin anymore. Although requirement of HP plugin was questionable with some printer models, other models may really needed it and they will not work without it. Please try the following scratch builds: Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=45790790 F32: https://koji.fedoraproject.org/koji/taskinfo?taskID=45790902 F31: https://koji.fedoraproject.org/koji/taskinfo?taskID=45790908 And if the update breaks printing or scanning for you, please let the upstream know here: https://bugs.launchpad.net/hplip Thank you in advance for helping with testing! Zdenek -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
PWG meetup May - the latest printing/scanning stack updates
Hi, I attended PWG meetup this week - due COVID-19 the meetup was completely virtual. The notes from the first day are attached, new PWG standards were discussed during next days - proposals can be found here https://ftp.pwg.org/pub/pwg/ipp/wd/?C=M;O=D . -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPrinting plenary - - cups-filters - moving to printer application - no remote PPDs, reliability enhancements, moves to stable API of poppler - future - printing in SNAP/flatpack - new PAPPL project - framework for printer apps - ippusbxd vs ipp-go for ipp-over-usb printers - avahi patch - for advertising local services on local machine only - finally megred, no longer blocks printer applications and ipp-over-usb - GSoC prolonged by two weeks later due COVID-19 - OP will try to participate in Google Season of Docs 2020 - starts in September to November, can go to March for longer projects GSoC 2019-2020 -- - GSoC 2020 selected projects: - linux GUI app for IPP system service - common print dialog backend with Qt - IPP scan server - General printapp SDK - speed/scaling optimization of cups-browsed - needs specific HW, delayed due COVID - extract raster data from PDF to direct printing - needs specific HW, delayed due COVID - configurable printapps - OP community bridge - funding openprinting projects Printer Applications - two printapps - ippeveprinter (ippserver), LPrint - framework PAPPL - printapps = replacement for PPD, ppd options are now ipp attributes + driver specific UI by printapp - printapp is ipp everywhere printer - requires only PWG raster/PDF and JPEG (for color printers) - CUPS libs and ippsample are good means how to create printerapp - compatible with old CUPS 1.4 and older ippeveprinter - started as ippserver, has 3 modes - ppd-based postscript printer mode, basic legacy postscript/pcl printer, attribute file mode - good for testing, not for production - enhancements - in ippsample and ippeveselfcert, Mike will provide pull requests to Apple to incorporate the changes in Apple CUPS - support resource files - clone-printer script - collects attrs, icons and strings from a printer LPrint -- - in snap or github - for common network or USB label printers - based on ippeveprinter - multiple printer support via subset of IPP system service, daemon is run on demand, it doesnt use CUPS backend - is standalone spooling without CUPS and runs as ipp everywhere printer - support raw, apple/pwg raster and PNG files PAPPL - - C framework for writing printer apps - should support any kind of printer or driver in all environments - base for gutenprint and LPrint - supports JPEG, PNG, PWG, Apple Raster and "raw" printing to USB/network printer - license the same as CUPS - framework supports adding others filters - it generates specific printerapp and web pages based on your provided options Openprinting projects - - cups-filters - now supports clustering - no longer downloads remote PPD and creates PPD based on IPP request - works with chunks of print queues - filters supports zero-page input files -> zero-page output without error - fallback during get_printer_attributes - for IPP-1.1 and then without media-col-database Future: - change of license to the same as CUPS - move more functions into libcupsfilters - filters should be PPD-less, except for foomatic-rip - take PPD functions from CUPS and create libppd library to allow converting legacy drivers into printerapps - cups-browsed as printerapp - cups-browsed may be forked from cups-filters - driverless scanning - 3 standards - IPP scan(open PWG standard), eSCL(from HP, used by Apple AirScan), WSD(from Windows and W3C) - 2 projects - escl and airscan - will be merged into one, supporting all 3 standards and added into sane-backends - sane-backends currently has escl backend, but since it will be merged into airscan the escl backend was removed in Fedora - works via ipp-over-usb (ippusbxd, ipp-usb) - goal is to rework scanning model due sandboxed packaging -> introducing IPP Scan: - scanning drivers will be scanning application, emulates IPP scanner - IPP scan client is scanning app - app uses IPP scan SANE backend, old SANE drivers in legacy Scanner Application - ipp-over-usb: - ipp-usb - written in Go, better http handling library, high memory footprint - main disapproval from ChromeOS - ippusbxd - written in C, has several problems which are fixed in ipp-usb (due better HTTP library in Go) - ChromeOS person wanted to implement the features which works in ipp-usb, but no activity since then - CUPS Snap: - has CUPS, cups-filters, cups-browsed, gs, qpdf, no classic drivers (cannot get dropped into Snap filesystem) signature.asc Description: OpenPGP d
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 4/14/20 9:23 PM, Ben Cotton wrote: > === Multicast DNS === > > systemd-resolved's multicast DNS support conflicts with Avahi. Per > recommendation from the systemd developers, we will change the default > value of this setting in Fedora from the upstream default > `MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving > will be enabled, but responding will be disabled. This will require > adding a new systemd build option to control the default value of the > MulticastDNS setting, similar to the existing `default-dnssec` and > `default-dns-over-tls` build options. > > Hi Michael, would you mind telling me more about the change's impact on MDNS support provided by Avahi and nss-mdns package, since you mention Avahi conflicts with systemd-resolved? CUPS relies on Avahi/nss-mdns for its MDNS functionality (resolving MDNS addresses, browsing services, registering services...) because it is essential for automatic printer discovery and driverless printing functionality, which is supported by devices since 2010. According https://github.com/apple/cups/issues/5452 systemd-resolved was not the replacement for Avahi at the time, so is there a way how to make Avahi work with the change, hopefully as default? Non-working MDNS via Avahi would put us back in <2010. Thank you in advance for response! Zdenek -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: buildroot problems on rawhide i386, armv7hl ??
I filed https://bugzilla.redhat.com/show_bug.cgi?id=1822468 on glibc,
maybe they can direct us to the right way.
On 4/9/20 8:12 AM, Zdenek Dohnal wrote:
> I have the same issue with vim's build:
>
> https://kojipkgs.fedoraproject.org//work/tasks/8185/43148185/build.log
>
> I did the diff of installed packages between the last successful build
> and the failed one and the packages which changed are:
>
> glibc
>
> openssl-libs
>
> krb5-libs
>
> qt5-srpm-macros
>
> graphite2
>
> Since the segfault comes from functions as make/xargs - can it be
> possible the glibc update could cause it?
>
> On 4/9/20 7:29 AM, Lumir Balhar wrote:
>> On 4/9/20 6:22 AM, Jerry James wrote:
>>> On Wed, Apr 8, 2020 at 9:57 PM Sérgio Basto wrote:
>>>> I'm having the same problem
>>>>
>>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=43144692
>>> Me, too. Two packages, both failing on the 32-bit architectures due
>>> to segfaults in find, grep, or xargs in the alt-ergo case (it's hard
>>> to tell) and remake in the flocq case.
>>>
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=43145509
>>>
>> The same problem here. It seems to be caused by find in my case in
>> /usr/lib/rpm/brp-strip-static-archive and check-buildroot
>>
>> /usr/lib/rpm/check-buildroot: line 32: 18998 Done
>> find "$RPM_BUILD_ROOT" \! \( -name '*.pyo' -o -name '*.pyc' -o -name
>> '*.elc' -o -name '.packlist' \) -type f -print0
>> 18999 Segmentation fault (core dumped) | LANG=C xargs -0r
>> -P$NCPUS -n16 grep -F "$RPM_BUILD_ROOT" >> $tmp
>>
>> + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
>> /usr/lib/rpm/brp-strip-static-archive: line 17: 19034
>> Done find "$RPM_BUILD_ROOT" -type f \! -regex
>> "${RPM_BUILD_ROOT}/*usr/lib/debug.*" -print0
>> 19035 Segmentation fault (core dumped) | xargs -0 -r
>> -P$NCPUS -n32 sh -c "file \"\$@\" | sed 's/: */: /' | grep 'current
>> ar archive' | sed -n -e 's/^\(.*\):[ ]*current ar archive/\1/p' |
>> xargs -d '\n' -I\{\} $STRIP -g \{\}" ARG0
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=43149093
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: buildroot problems on rawhide i386, armv7hl ??
I have the same issue with vim's build:
https://kojipkgs.fedoraproject.org//work/tasks/8185/43148185/build.log
I did the diff of installed packages between the last successful build
and the failed one and the packages which changed are:
glibc
openssl-libs
krb5-libs
qt5-srpm-macros
graphite2
Since the segfault comes from functions as make/xargs - can it be
possible the glibc update could cause it?
On 4/9/20 7:29 AM, Lumir Balhar wrote:
> On 4/9/20 6:22 AM, Jerry James wrote:
>> On Wed, Apr 8, 2020 at 9:57 PM Sérgio Basto wrote:
>>> I'm having the same problem
>>>
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=43144692
>> Me, too. Two packages, both failing on the 32-bit architectures due
>> to segfaults in find, grep, or xargs in the alt-ergo case (it's hard
>> to tell) and remake in the flocq case.
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=43145509
>>
> The same problem here. It seems to be caused by find in my case in
> /usr/lib/rpm/brp-strip-static-archive and check-buildroot
>
> /usr/lib/rpm/check-buildroot: line 32: 18998 Done
> find "$RPM_BUILD_ROOT" \! \( -name '*.pyo' -o -name '*.pyc' -o -name
> '*.elc' -o -name '.packlist' \) -type f -print0
> 18999 Segmentation fault (core dumped) | LANG=C xargs -0r
> -P$NCPUS -n16 grep -F "$RPM_BUILD_ROOT" >> $tmp
>
> + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
> /usr/lib/rpm/brp-strip-static-archive: line 17: 19034
> Done find "$RPM_BUILD_ROOT" -type f \! -regex
> "${RPM_BUILD_ROOT}/*usr/lib/debug.*" -print0
> 19035 Segmentation fault (core dumped) | xargs -0 -r
> -P$NCPUS -n32 sh -c "file \"\$@\" | sed 's/: */: /' | grep 'current
> ar archive' | sed -n -e 's/^\(.*\):[ ]*current ar archive/\1/p' |
> xargs -d '\n' -I\{\} $STRIP -g \{\}" ARG0
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43149093
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
CUPS 2.3.0 coming into rawhide
Hi all, after 2 years or so of solving licensing issue, I would like to announce CUPS-2.3.0 is going into Fedora rawhide next week. The 2.3.0 version brings several changes: _Change of license:_ It is Apache software license 2.0 with exceptions for LGPLv2 only and GPLv2 only now. ASL 2.0 is compatible with licenses GPLv2+ and LGPLv2+ and exceptions cover projects which are version 2 only, so no dependent package is affected. The main license is to be found in LICENSE file, exceptions in NOTICE. _Deprecation of printer drivers and raw queues:_ Because most printers produced since approx. 2012 support IPP everywhere (or AirPrint) standard [1], CUPS upstream decided to deprecate printer drivers and raw queues support. That means printer drivers and raw queues are *STILL AVAILABLE, BUT YOU GET DEPRECATION WARNING *when you create them. They will be removed in the future, substituted by printer applications or 'everywhere' model. There are small tutorial [2] and FAQ [3] about IPP everywhere. _Introduction of printer application:_ CUPS 2.3.0 now provides ippeveprinter binary, which is now shipped in cups-printerapp subpackage. This is the printer application provided by CUPS upstream, which acts as IPP everywhere print queue above NOT-IPP everywhere enabled printer. ippeveprinter now works for printers who accepts postscript and PCL languages. More info about printer applications can be seen at CUPS plenary from PWG 2018[4] or my report from PWG 2019[5], small usage cases will be in man pages ippeveprinter(1) and ippeveps/ippevepcl(7). OpenPrinting and PWG group are working hard on providing printer applications for the biggest printer driver packages e.g. foomatic, gutenprint and hplip. There will be several projects for those issues during Google Summer of Code 2020 to create those printer applications and ensure that there is a way how to make postscript and PCL printers works after printer driver removal. News from the group can be see at [6]. _How to find out that my printer is 'IPP everywhere':_ - prerequisites: - opened port 631 on the printer - [for cups temporary queues feature[7]] - running avahi-daemon.service, nss-mdns package installed, printer in local network - how to do the deed: * by 'lpstat -e' - shows all print queues available on the PC - permanent and temporary * 'sudo lpinfo -l -v' - show all devices available on local network - the IPP eve printer is marked 'driverless' * try to install printer with 'everywhere' model and IPP device uri: o common device uri is 'ipp://:631/ipp/print' o then issue the command: + $ sudo lpadmin -p -v 'ipp://:631/ipp/print -m everywhere -E o if the command went well, your printer is IPP everywhere enabled :) * there is IPP everywhere self-certification script [8], but it has not been in Fedora yet, but I plan to package it along with ippusbx [9] [1] http://www.pwg.org/ipp/everywhere.html [2] https://github.com/apple/cups/wiki/IPP-(Everywhere)-Mini-Tutorial [3] https://beta.pwg.org/ipp/evefaq.html [4] https://ftp.pwg.org/pub/pwg/liaison/openprinting/presentations/cups-plenary-may-18.pdf , page 28 [5] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FJR462QFSTSNNCHFA5GVDKV6D2SXELL6/ [6] https://openprinting.github.io/ [7] Feature introduced in cups-2.2.4 - CUPS catches avahi messages about printers in local network and make them available only when you need - during print dialog of applications - and they disappear after minute since successful print job. [8] https://github.com/istopwg/ippeveselfcert [9] Daemon which makes USB printers available on the local network through avahi https://github.com/OpenPrinting/ippusbxd -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
