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
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
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
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
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 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
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/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: 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: 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
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
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: 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
Request for testing+adding karma for Fedora 24 VIM's update
Hi all, I have VIM update for fedora 24 in Bodhi, which should solve two CVEs. Would anyone mind testing it and adding karma to this update for speeding up process? Thank you in advance. -- Zdenek Dohnal Associate Software Engineer Brno, Purkyňova 99, Czech Republic RED HAT | TRIED. TESTED. TRUSTED. Every telecommunications Company in the Fortune Global 500 relies on Red Hat. Find out why at Trusted | Red Hat signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
RPM macros - case insensitive since Fedora 27 (maybe Fedora 26)
Hi, I was doing rebase for gutenprint pre-release in recent rawhide (fc27) and I couldn't build it because I had %VERSION macro defined by myself and it got rewritten by default macro %version. That indicates rpm macros have been case insensitive since fc27 (colleague told me the same situation is in fc26 too, but I encountered it in fc27). Would anyone mind explaining why such change was introduced for RPM macros, please? IMHO I do not think it is good idea, because it shrinks group of useful names for packager defined RPM macros. I hope I didn't miss discussion about it in the past. If that's so, my apologies for duplicate. Best regards, Zdenek -- Zdenek Dohnal Associate Software Engineer Brno, Purkyňova 99, Czech Republic RED HAT | TRIED. TESTED. TRUSTED. Every telecommunications Company in the Fortune Global 500 relies on Red Hat. Find out why at Trusted | Red Hat signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM macros - case insensitive since Fedora 27 (maybe Fedora 26)
On 05/24/2017 05:49 PM, Jonathan Wakely wrote:
> On 24/05/17 17:32 +0200, Zdenek Dohnal wrote:
>> Hi,
>>
>> I was doing rebase for gutenprint pre-release in recent rawhide (fc27)
>> and I couldn't build it because I had %VERSION macro defined by myself
>> and it got rewritten by default macro %version. That indicates rpm
>> macros have been case insensitive since fc27 (colleague told me the same
>> situation is in fc26 too, but I encountered it in fc27).
>
> Isn't this because "Version" is the name of a tag? Just like Name and
> Release. And Tag names are not case-sensitive, so you could write this
> in your spec file:
>
> VERSION: 12.34
>
> Reusing those for your own macros seems like a very bad idea and bound
> to lead to confusion. Does %version refer to the VERSION tag? Or does
> %VERSION refer to that?
%{VERSION} contains %{version}-%{prever}. AFAIK macro %{version}
contains value for Version: tag, so I defined other macro %{VERSION}.
And I thought macros are case sensitive. I worked fine this way before.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
Zdenek Dohnal
Associate Software Engineer
Brno, Purkyňova 99, Czech Republic
RED HAT | TRIED. TESTED. TRUSTED.
Every telecommunications Company in the Fortune Global 500 relies on Red Hat.
Find out why at Trusted | Red Hat
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM macros - case insensitive since Fedora 27 (maybe Fedora 26)
On 05/24/2017 06:08 PM, Jonathan Wakely wrote:
> On 24/05/17 17:58 +0200, Zdenek Dohnal wrote:
>> On 05/24/2017 05:49 PM, Jonathan Wakely wrote:
>>> On 24/05/17 17:32 +0200, Zdenek Dohnal wrote:
>>>> Hi,
>>>>
>>>> I was doing rebase for gutenprint pre-release in recent rawhide (fc27)
>>>> and I couldn't build it because I had %VERSION macro defined by myself
>>>> and it got rewritten by default macro %version. That indicates rpm
>>>> macros have been case insensitive since fc27 (colleague told me the
>>>> same
>>>> situation is in fc26 too, but I encountered it in fc27).
>>>
>>> Isn't this because "Version" is the name of a tag? Just like Name and
>>> Release. And Tag names are not case-sensitive, so you could write this
>>> in your spec file:
>>>
>>> VERSION: 12.34
>>>
>>> Reusing those for your own macros seems like a very bad idea and bound
>>> to lead to confusion. Does %version refer to the VERSION tag? Or does
>>> %VERSION refer to that?
>> %{VERSION} contains %{version}-%{prever}. AFAIK macro %{version}
>> contains value for Version: tag, so I defined other macro %{VERSION}.
>> And I thought macros are case sensitive. I worked fine this way before.
>
> And my point is that "the Version: tag" is not case-sensitive, so can
> be written in a spec-file as VERSION: or VeRsIoN: or any other
> variation, so defining any macro like VERSION of version or Version is
> a bad idea. It can only lead to confusion.
>
> Wouldn't %{PKG_VERSION} or %{VERSION_EXTRA} or something be a better
> name for your macro?
Yes, you are right - I should use some prefix for it to clearly
distinguish these two macros. I originally thought the only one and
unique macro for Version: tag is only %{version} and %{VERSION} etc. are
different (because I thought all macros are case sensitive - I didn't
know that macros for tags are case insensitive lately). But %{VERSION}
macro worked well until Fedora 27, so this insensitivity was introduced
during fc26/fc27. Wouldn't it be better to create some guidelines for
RPM macros like "You mustn't create your RPM macros without some prefix"
rather than making macros for tags case insensitive?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
Zdenek Dohnal
Associate Software Engineer
Brno, Purkyňova 99, Czech Republic
RED HAT | TRIED. TESTED. TRUSTED.
Every telecommunications Company in the Fortune Global 500 relies on Red Hat.
Find out why at Trusted | Red Hat
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fedpkg says "fedora.client.bodhi has been deprecated."
On 05/25/2017 09:04 PM, Pete Zaitcev wrote: > Dear Packagers: > > I probably missed some kind of announcement, but this started happening > unexpectedly: > > [zaitcev@lembas liberasurecode.master]$ fedpkg srpm > /usr/lib/python2.7/site-packages/fedora/client/bodhi.py:48: > DeprecationWarning: fedora.client.bodhi has been deprecated. Please use > bodhi.client.bindings instead. > DeprecationWarning) > > All the packages are up to date... or so I think (fedpkg-1.28-1.fc25.noarch, > python-fedora-0.9.0-3.fc25.noarch). Is there something I need to steal from > Rawhide or what? > > -- Pete > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Hi, I asked about this message on IRC #fedora-admin channel and they told me this message should disappear after future updates (no specific version wasn't told). -- Zdenek Dohnal Associate Software Engineer Brno, Purkyňova 99, Czech Republic RED HAT | TRIED. TESTED. TRUSTED. Every telecommunications Company in the Fortune Global 500 relies on Red Hat. Find out why at Trusted | Red Hat signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM macros - case insensitive since Fedora 27 (maybe Fedora 26)
On 05/25/2017 03:20 PM, Jonathan Wakely wrote:
> On 25/05/17 09:23 +0200, Zdenek Dohnal wrote:
>> Yes, you are right - I should use some prefix for it to clearly
>> distinguish these two macros. I originally thought the only one and
>> unique macro for Version: tag is only %{version} and %{VERSION} etc. are
>> different (because I thought all macros are case sensitive - I didn't
>> know that macros for tags are case insensitive lately). But %{VERSION}
>> macro worked well until Fedora 27, so this insensitivity was introduced
>> during fc26/fc27. Wouldn't it be better to create some guidelines for
>> RPM macros like "You mustn't create your RPM macros without some prefix"
>> rather than making macros for tags case insensitive?
>
> The tags themselves are case-insensitive, but the macros aren't.
>
> %{VeRsIoN} is not automatically defined. I just did a quick test and
> %it looks like only %{VERSION} and %{version} are. Even %{Version} is
> not. And I don't see %{VERSION} defined in an f26 mock build, only for
> rawhide.
You're correct. Difference in macros (from output of 'rpm --showrc'):
- Fedora 25:
RPM_PACKAGE_VERSION="%{version}" (and rpm uses this macro everywhere)
- Fedora 27:
RPM_PACKAGE_VERSION="%{VERSION}" (and uses %{VERSION} and %{version}
in other built-in macros - IMO it can be confusing too, if packager
doesn't know this only macro is case insensitive)
>
> But I still think relying on %VERSION and %version to mean two
> different things makes your spec confusing.
>
You're right, I'll change it by Jose suggestion. My original question
was why this macro change was introduced, when previous macro worked fine.
> _______
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
Zdenek Dohnal
Associate Software Engineer
Brno, Purkyňova 99, Czech Republic
RED HAT | TRIED. TESTED. TRUSTED.
Every telecommunications Company in the Fortune Global 500 relies on Red Hat.
Find out why at Trusted | Red Hat
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM macros - case insensitive since Fedora 27 (maybe Fedora 26)
On 05/25/2017 03:35 PM, José Abílio Matos wrote:
>
> On Wednesday, 24 May 2017 16.58.10 WEST Zdenek Dohnal wrote:
>
> > > Isn't this because "Version" is the name of a tag? Just like Name and
>
> > > Release. And Tag names are not case-sensitive, so you could write this
>
> > > in your spec file:
>
> > >
>
> > > VERSION: 12.34
>
> > >
>
> > > Reusing those for your own macros seems like a very bad idea and bound
>
> > > to lead to confusion. Does %version refer to the VERSION tag? Or does
>
> > > %VERSION refer to that?
>
> >
>
> > %{VERSION} contains %{version}-%{prever}. AFAIK macro %{version}
>
> > contains value for Version: tag, so I defined other macro %{VERSION}.
>
> > And I thought macros are case sensitive. I worked fine this way before.
>
>
>
> Possibly you have considered this before.
>
>
>
> For the above example why not to define version in the spec file as
>
>
>
> Version: 12.34{?prever:-%{prever}}
>
>
>
>
>
> If the %{prever} is defined is adds -%{prever} to the version else it
> does nothing.
>
That's great, I'll change it that way. Thank you, José.
>
>
> Regards,
>
> --
>
> José Abílio
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
Zdenek Dohnal
Associate Software Engineer
Brno, Purkyňova 99, Czech Republic
RED HAT | TRIED. TESTED. TRUSTED.
Every telecommunications Company in the Fortune Global 500 relies on Red Hat.
Find out why at Trusted | Red Hat
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fedpkg says "fedora.client.bodhi has been deprecated."
On 05/26/2017 06:27 PM, Randy Barlow wrote: > On Fri, 2017-05-26 at 08:33 +0200, Zdenek Dohnal wrote: >> I asked about this message on IRC #fedora-admin channel and they told >> me >> this message should disappear after future updates (no specific >> version >> wasn't told). > I wrote a bit about this here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1455800 > > Python DeprecationWarnings should not be shown to users by default: > > https://docs.python.org/2/library/warnings.html#warning-categories > > Perhaps you have PYTHONWARNINGS set in your environment to a non-defaul > value? I do not have set anything in PYTHONWARNINGS environmental variable at all. It doesn't even show when I ran '$ env'/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Zdenek Dohnal Associate Software Engineer Brno, Purkyňova 99, Czech Republic RED HAT | TRIED. TESTED. TRUSTED. Every telecommunications Company in the Fortune Global 500 relies on Red Hat. Find out why at Trusted | Red Hat signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Orphan: mupdf/jbig2dec
On 05/30/2017 01:19 PM, Dridi Boukelmoune wrote: > On Tue, May 30, 2017 at 1:05 PM, Pavel Zhukov > wrote: >> Hello. >> Due to many CVEs and low quality/security of these packages as well as >> Windows oriented upstream I'm going to orphan both jbig2dec and mupdf >> packages in Fedora/EPEL. >> Sometimes the build doesn't reach stable branch just because it's deprecated >> by new build with new CVE. >> Feel free to take them. > It sounds more like something to retire instead, at least on Fedora... At least mupdf is needed in cups-filters as BuildRequire - cups-filters uses it in pdftopdf filter, so abandoning it would resolve in more difficult PDF printing in Fedora. And as I can see jbig2dec is in BuildRequires for mupdf, I should take it. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Zdenek Dohnal Associate Software Engineer Brno, Purkyňova 99, Czech Republic RED HAT | TRIED. TESTED. TRUSTED. Every telecommunications Company in the Fortune Global 500 relies on Red Hat. Find out why at Trusted | Red Hat signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Orphan: mupdf/jbig2dec
On 05/31/2017 08:32 AM, Rémi Verschelde wrote: > 2017-05-31 8:24 GMT+02:00 Zdenek Dohnal : >> On 05/30/2017 01:19 PM, Dridi Boukelmoune wrote: >>> On Tue, May 30, 2017 at 1:05 PM, Pavel Zhukov >>> wrote: >>>> Hello. >>>> Due to many CVEs and low quality/security of these packages as well as >>>> Windows oriented upstream I'm going to orphan both jbig2dec and mupdf >>>> packages in Fedora/EPEL. >>>> Sometimes the build doesn't reach stable branch just because it's >>>> deprecated by new build with new CVE. >>>> Feel free to take them. >>> It sounds more like something to retire instead, at least on Fedora... >> At least mupdf is needed in cups-filters as BuildRequire - cups-filters >> uses it in pdftopdf filter, so abandoning it would resolve in more >> difficult PDF printing in Fedora. And as I can see jbig2dec is in >> BuildRequires for mupdf, I should take it. > For what it's worth, I briefly maintained mupdf in Mageia before > deciding to drop it from Cauldron (our development release) for the > same reasons that Pavel mentioned. > > If you want to keep mupdf, I would advise to patch away the mujstest > program, which is the one affected by most CVEs against mupdf over the > last couple of years. Without mupdf, you'd be down to patching > security vulnerabilities every 2 months instead of every 2 weeks... :) I disabled mupdf in cups-filters - problem solved. We can retire it at least from the view of cups-filters. > > Regards, > Rémi > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Zdenek Dohnal Associate Software Engineer Brno, Purkyňova 99, Czech Republic RED HAT | TRIED. TESTED. TRUSTED. Every telecommunications Company in the Fortune Global 500 relies on Red Hat. Find out why at Trusted | Red Hat signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Koji update to Kerberos problem
Hi,
I am stuck with same error like Michal. I logged into FAS and waited for
long time (cca 1 hour), but still I get same error:
kinit: Client 'zdoh...@fedoraproject.org' not found in Kerberos database
while getting initial credentials
There is my debug output (same as gil and Dmitrij):
http://paste.fedoraproject.org/505248/48153744/
My set of packages:
fedpkg-1.26-2.fc25.noarch
koji-1.11.0-1.fc25.noarch
python2-cccolutils-1.4-1.fc25.x86_64
fedora-packager-0.6.0.0-1.fc25.noarch
pyrpkg-1.47-3.fc25.noarch
I changed /etc/krb5.conf.d/fedoraproject_org file into this:
[realms]
FEDORAPROJECT.ORG = {
kdc = https://id.fedoraproject.org/KdcProxy
}
[domain_realm]
.fedoraproject.org = FEDORAPROJECT.ORG
fedoraproject.org = FEDORAPROJECT.ORG
and my /etc/krb5.conf file has line with includedir. I talked about it
on IRC channel #fedora-admin, where they told me it is some sync
problem. Any advice how to solve it? For me as package maintainer is
this issue really critical.
On 12/12/2016 09:12 AM, Michal Schorm wrote:
> Yes, I am still stuck with the same error.
>
> "kinit: Client 'msch...@fedoraproject.org
> <mailto:msch...@fedoraproject.org>' not found in Kerberos database
> while getting initial credentials"
>
>
>
> On Mon, Dec 12, 2016 at 5:48 AM, Kevin Fenzi <mailto:ke...@scrye.com>> wrote:
>
> On Sun, 11 Dec 2016 22:41:19 +0100
> Michal Schorm mailto:msch...@redhat.com>> wrote:
>
> > > You have two accounts? Or you mean you tested with someone elses
> > > account and got a Password prompt, but not your own?
> >
> > I have only one account.
> > I used someone else's username to prove, I got right configuration.
> >
> > > In any case, you need to login to fas
> > > ( https://admin.fedoraproject.org/accounts
> <https://admin.fedoraproject.org/accounts> ) with your account and
> > > then try again. Logging in there should sync your information to
> > > ipa.
> >
> > I logged in and ... waitinig?
> > Nothing happens...
>
> There is no visual indicator, but when you login fas syncs your
> information to ipa. So, after loging into fas, try the kinit again.
>
> > I logged there before, when I encountered this, in belief, that I
> > need to update some configuration in FAS or sign myself up to
> > Kerberos credentials DB.
>
> So, you still see the same issue with kinit?
>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> <mailto:devel-le...@lists.fedoraproject.org>
>
>
>
>
> --
>
>
>
> Michal Schorm
> Core Services - Databases Team
> mail: msch...@redhat.com <mailto:msch...@redhat.com>
> Brno-IRC: mschorm
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
Zdenek Dohnal
Associate Software Engineer
Brno, Purkyňova 99, Czech Republic
RED HAT | TRIED. TESTED. TRUSTED.
Every telecommunications Company in the Fortune Global 500 relies on Red Hat.
Find out why at Trusted | Red Hat
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Koji update to Kerberos problem
Unfortunately, no change, still getting error. On 12/12/2016 11:59 AM, Hans de Goede wrote: > Hi, > > On 12-12-16 11:58, Hans de Goede wrote: >> Hi, >> >> On 12-12-16 11:44, Zdenek Dohnal wrote: >>> Hi, >>> >>> I am stuck with same error like Michal. I logged into FAS and waited >>> for long time (cca 1 hour), but still I get same error: >>> >>> kinit: Client 'zdoh...@fedoraproject.org' not found in Kerberos >>> database while getting initial credentials >>> >>> There is my debug output (same as gil and Dmitrij): >>> >>> http://paste.fedoraproject.org/505248/48153744/ >> >> From: >> >> https://fedoraproject.org/wiki/Infrastructure/Kerberos#Questions_and_Answers >> >> >> Question: When I run kinit I get: Client >> 'yourname(a)FEDORAPROJECT.ORG' >> not found in Kerberos database while getting initial credentials >> >> Answer: Login to fas ( https://admin.fedoraproject.org/accounts ) and >> then retry. Your information needs to be synced from fas to the ipa >> server. Logging into fas does so. > > Nevermind, I did not read your mail properly, I see now that you've > already done this, sorry. > > Maybe this helps ? I was getting a different error, but who knows ? : > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6352NZ7K3REWAL76ABQDRIIO5B2Z7P2Q/ > > > Regards, > > Hans > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Zdenek Dohnal Associate Software Engineer Brno, Purkyňova 99, Czech Republic RED HAT | TRIED. TESTED. TRUSTED. Every telecommunications Company in the Fortune Global 500 relies on Red Hat. Find out why at Trusted | Red Hat signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
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: 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
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
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
Vim and spec template
Hi all, I would like to ask as Vim co-maintainer, do you find useful for Vim to do: - when you open new file with .spec suffix, Vim will get you basic spec file structure? Recently I found out someone can find it as bad behavior https://bugzilla.redhat.com/show_bug.cgi?id=1724126 , so I consider changing the default vimrc to tell Vim 'Don't do it'. What's your opinion? Is it useful feature of Vim and it should stay as default, or it needs to be disabled? -- 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 and spec template
On 7/18/19 3:25 PM, Steven A. Falco wrote: > On 7/18/19 7:44 AM, Zdenek Dohnal wrote: >> Hi all, >> >> I would like to ask as Vim co-maintainer, do you find useful for Vim to do: >> >> - when you open new file with .spec suffix, Vim will get you basic spec >> file structure? >> >> Recently I found out someone can find it as bad behavior >> https://bugzilla.redhat.com/show_bug.cgi?id=1724126 , so I consider >> changing the default vimrc to tell Vim 'Don't do it'. >> >> What's your opinion? Is it useful feature of Vim and it should stay as >> default, or it needs to be disabled? > I've never had a problem with it, but then I only edit rpm spec files. > > If you were to remove it from /etc/vimrc, would the normal syntax system > still provide a good way to edit rpm spec files? Yep, AFAIK syntax while editing spec will not be changed - just providing basic spec file structure will be removed (you will have plain file) when you create new spec file. That could be useful for people who creates new package from scratch though... > > Steve > > > > ___ > 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: Vim and spec template
On 7/18/19 3:39 PM, Vitaly Zaitsev via devel wrote: > Hello, Zdenek Dohnal. > > Thu, 18 Jul 2019 13:44:56 +0200 you wrote: > >> What's your opinion? Is it useful feature of Vim and it should stay as >> default, or it needs to be disabled? > I think, that *.spec files on Fedora should be treated as RPM SPEC files > by default. Even the new .spec files, which do not have to be RPM spec files? Because Vim provides spec template for such cases. > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.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: Vim and spec template
On 7/18/19 4:10 PM, Vitaly Zaitsev via devel wrote: > Hello, Zdenek Dohnal. > > Thu, 18 Jul 2019 15:51:33 +0200 you wrote: > >> Even the new .spec files, which do not have to be RPM spec files? >> Because Vim provides spec template for such cases. > I never used this feature, so I think it can be disabled by default. That's the thing which I asked for opinion on, not about syntax highlighting. > But > syntax highlighting for RPM SPEC files should be enabled. > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.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: Vim and spec template
On 7/18/19 9:47 PM, Jason L Tibbitts III wrote:
>>>>>> "ZD" == Zdenek Dohnal writes:
> ZD> Hi all, I would like to ask as Vim co-maintainer, do you find useful
> ZD> for Vim to do:
>
> ZD> - when you open new file with .spec suffix, Vim will get you basic
> ZD> spec file structure?
>
> Personally I have always found that behavior annoying. If I open a new
> file, I expect that the file would be empty. If I want a template, I
> can copy one. Editing a new HTML file doesn't bring up a template for
> HTML files, for example.
>
> The spec template used isn't something I ever want anyway. It uses tabs
> instead of spaces and uses them in a way that implies that indentation
> is somehow required.
Converted to spaces now.
> And it includes a default release tag of
> "0%{?dist}" which isn't permitted by the packaging guidelines.
Expected. It is designed for user to run rpmdev-bumpspec .spec,
so the tool will supply correct format of changelog entry and increment
the release.
> (Releases start at one except when packaging prerelease software, and are
> never exactly zero.)
>
> Best to leave it to the packager to choose their own template, or to
> allow somehow who wants templating behavior to configure templating in a
> general way.
>
> - J<
--
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: Mass rebuild - emacs broken
On 2/1/19 12:21 PM, Jan Synacek wrote: > On Thu, Jan 31, 2019 at 11:19 PM Richard W.M. Jones <mailto:rjo...@redhat.com>> wrote: > > > emacs isn't installable at the moment, so any package that needs emacs > fails to build, eg: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=32380321 > > > DEBUG util.py:490: BUILDSTDERR: Error: > DEBUG util.py:490: BUILDSTDERR: Problem: package > emacs-1:26.1-7.fc30.x86_64 requires libMagickCore-6.Q16.so.6()(64bit), > but none of the providers can be installed > DEBUG util.py:490: BUILDSTDERR: - package emacs-1:26.1-7.fc30.x86_64 > requires libMagickWand-6.Q16.so.6()(64bit), but none of the providers > can be installed > DEBUG util.py:490: BUILDSTDERR: - conflicting requests > DEBUG util.py:490: BUILDSTDERR: - nothing provides > libwmflite-0.2.so.7()(64bit) needed by > ImageMagick-libs-1:6.9.10.23-1.fc30.x86_64 > > Looks like a broken ImageMagick to me. IMO it is unannounced soname bump of libwmflite and libwmf and it is even in F29 - it broke my gutenprint build too (because gutenprint has dependency on gimp, which is broken by unannounced soname bump) https://koji.fedoraproject.org/koji/taskinfo?taskID=32416632 . > > -- > Jan Synacek > Software Engineer, Red Hat > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Unannounced soname bump - libwmf-0.2.so.7 -> libwmf-0.2.so.8
Hi, there is unannounced soname bump in the buildroot of rawhide and F29: libwmf-0.2.so.7 -> libwmf-0.2.so.8 It breaks several components like gimp, ImageMagick, libabiword etc and packages dependent on them (like emacs, gutenprint...) . These updates are now unpushed, so they did not get into stable. -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Mass rebuild - emacs broken
On 2/1/19 2:37 PM, Björn 'besser82' Esser wrote: > Am Freitag, den 01.02.2019, 13:30 +0100 schrieb Zdenek Dohnal: >> On 2/1/19 12:21 PM, Jan Synacek wrote: >>> On Thu, Jan 31, 2019 at 11:19 PM Richard W.M. Jones < >>> rjo...@redhat.com> wrote: >>>> emacs isn't installable at the moment, so any package that needs >>>> emacs >>>> fails to build, eg: >>>> >>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=32380321 >>>> >>> DEBUG util.py:490: BUILDSTDERR: Error: >>> DEBUG util.py:490: BUILDSTDERR: Problem: package emacs-1:26.1- >>> 7.fc30.x86_64 requires libMagickCore-6.Q16.so.6()(64bit), but none >>> of the providers can be installed >>> DEBUG util.py:490: BUILDSTDERR: - package emacs-1:26.1-7.fc30.x86_64 >>> requires libMagickWand-6.Q16.so.6()(64bit), but none of the >>> providers can be installed >>> DEBUG util.py:490: BUILDSTDERR: - conflicting requests >>> DEBUG util.py:490: BUILDSTDERR: - nothing provides libwmflite- >>> 0.2.so.7()(64bit) needed by ImageMagick-libs-1:6.9.10.23- >>> 1.fc30.x86_64 >>> >>> Looks like a broken ImageMagick to me. >> IMO it is unannounced soname bump of libwmflite and libwmf and it is >> even in F29 - it broke my gutenprint build too (because gutenprint has >> dependency on gimp, which is broken by unannounced soname bump) >> https://koji.fedoraproject.org/koji/taskinfo?taskID=32416632 . > > I've untagged the buildroot-override for libwmf in f29. Your build > should be fine again in about 15 minutes or so. Thank you, Björn! > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Blocking criteria proposal for F30+: Printing
evelopers are >> familiar with them so as they get escalated, it eliminates the kick >> back "how did you create this test file? can you attach it to the >> bug?" etc. >> >> > This sounds useful for automating the tests, but I think in general we > don't need to write this into the criteria. They don't need to be that > specific. > > >> >> >>> and this to Final for Fedora 30+: >>> * Printing must work on at least one printer using each of the >>> following drivers: >>> - The built-in print-to-PDF driver >>> - The generic IPP driver >>> >>> To clarify, this does not mean that all printers need to function >>> properly that use the IPP driver, just that at least one does (so we >>> know that printing as a whole is unbroken). Contrary to the first >>> proposal, we won't specify any particular hardware makes or models >>> that must work. >> I agree with this. One possible sanity test: >> >> 1. "Print" the standardized test file to a PDF file (using the >> built-in print to PDF driver) >> 2. Print both the resulting PDF from 1, and the original standardized >> test file, to the designated IPP printer. >> >> i.e. two physical prints on paper. And within some ballpark on >> scaling, they should appear the same. Some of the subcriteria: >> >> a. PDF file is created from test document >> b. PDF file is viewable with the default PDF viewer >> c. PDF file is printed >> d. Test document is printed >> e. minor differences aside: b, c, and d should not cause a WTF >> reaction by a human >> > That seems reasonable, though I'd rather have Master Wordsmith Adam > Williamson phrase that better. I agree, although I would add printing to generic postscript printer, because lots of devices are older and take postscript as input file type. And IMO we can spare the paper in the most test runs, if we use FileDevice print queue device type in testing - it is special type of CUPS backend, which creates a file which should go to the printer in the place specified in URI. The file is final output of all filters needed for input file conversion (used filters differs according to input file document format and printer's model) and ipp backend (which used for sending filters output to printer), so it matches our needs imo. But I will welcome suggestion for more sophisticated testing way than comparison or checking file type. Best regards, Zdenek CUPS Fedora maintainer > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Default LDFLAGS in build system - possible problems
Hi! I, as Fedora's vim co-maintainer, encountered the issue with default LDFLAGS. I tried to manually run configure script for Vim, with ruby support enabled, but it always failed with error message about missing ncurses (ncurses-devel was installed though). When I looked into config.log, I saw: configure:12069: gcc -o conftest -g -O2 -L. -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector -rdynamic -Wl,-export-dynamic -L/usr/local/lib conftest.c -lselinux -lncurses >&5 conftest.c: In function 'main': conftest.c:67:26: warning: implicit declaration of function 'tgetent' [-Wimplicit-function-declaration] char s[1]; int res = tgetent(s, "thisterminaldoesnotexist"); ^~~ /usr/bin/ld: /tmp/ccivPtT5.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: final link failed: nonrepresentable section on output collect2: error: ld returned 1 exit status Adding -fPIC actually solved it, but why does the script want it in the first place? Then I ran configure without ruby support enabled and it passed... again from config.log I found out that script wants ruby's LDFLAGS, because script needs them for compilation of ruby support and Ruby LDFLAGS are: -L. -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector -rdynamic -Wl,-export-dynamic , where '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' causes the issue. I talked with Vita Ondruch, Fedora's ruby maintainer, and he explained Ruby embeds LDFLAGS from the machine, where Ruby was built - in our case in our building system, and Ruby's upstream are not willing to change this behavior. To sum it up, I would like to ask if there is way how to solve it in our build system, not in Vim or Ruby projects themselves - because at least Ubuntu does not have this issue... and python+perl seem to have it solved too. (I can patch Vim downstream in the worst scenario...) Thank you for reading the email and answers in advance! Zdenek -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Default LDFLAGS in build system - possible problems
On 2/28/19 9:46 AM, Tom Hughes wrote: > On 28/02/2019 08:30, Zdenek Dohnal wrote: > >> I tried to manually run configure script for Vim, with ruby support >> enabled, but it always failed with error message about missing ncurses >> (ncurses-devel was installed though). When I looked into config.log, >> I saw: >> >> configure:12069: gcc -o conftest -g -O2 -L. -Wl,-z,relro -Wl,-z,now >> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector >> -rdynamic -Wl,-export-dynamic -L/usr/local/lib conftest.c -lselinux >> -lncurses >&5 >> conftest.c: In function 'main': >> conftest.c:67:26: warning: implicit declaration of function 'tgetent' >> [-Wimplicit-function-declaration] >> char s[1]; int res = tgetent(s, "thisterminaldoesnotexist"); >> ^~~ >> /usr/bin/ld: /tmp/ccivPtT5.o: relocation R_X86_64_32 against >> `.rodata.str1.1' can not be used when making a PIE object; recompile >> with -fPIC >> /usr/bin/ld: final link failed: nonrepresentable section on output >> collect2: error: ld returned 1 exit status >> >> Adding -fPIC actually solved it, but why does the script want it in the >> first place? Then I ran configure without ruby support enabled and it >> passed... again from config.log I found out that script wants ruby's >> LDFLAGS, because script needs them for compilation of ruby support and >> Ruby LDFLAGS are: > > You don't need -fPIC but you need -fPIE at least. > > The simple rule is that if you're going to link with Fedora's > linker flags (which you are doing here) then you need to compile > with Fedora's compiler flags, That was it :) - configure script was using LDFLAGS embedded in ruby, but it did not use CFLAGS. Thank you for the hint! > which would have included -fPIE if > you didn't already specify -fPIE or -fPIC on the command line. > > So make sure you tell configure to use $RPM_OPT_FLAGS when > compiling - if you use %configure and the configure script is > not too silly then that should happen automatically. > > There is a reasonable argument here that the pkgconfig file > that our ruby package installs is broken, because it embeds > our linker flags without embedding our compiler flags. > > So "pkg-config --libs ruby" tells you to link with those > flags but "pkg-config --cflags ruby" doesn't give you matching > compiler flags. > > That said, the ruby.pc file may be assuming that it will be > used for building ruby extensions, which would be .so files > and hence use -fPIC anyway... > > Tom > -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Default LDFLAGS in build system - possible problems
On 2/28/19 12:04 PM, Florian Weimer wrote: > * Zdenek Dohnal: > >> I, as Fedora's vim co-maintainer, encountered the issue with default >> LDFLAGS. >> >> I tried to manually run configure script for Vim, with ruby support >> enabled, but it always failed with error message about missing ncurses >> (ncurses-devel was installed though). When I looked into config.log, I saw: >> >> configure:12069: gcc -o conftest -g -O2 -L. -Wl,-z,relro -Wl,-z,now >> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector >> -rdynamic -Wl,-export-dynamic -L/usr/local/lib conftest.c -lselinux >> -lncurses >&5 >> conftest.c: In function 'main': >> conftest.c:67:26: warning: implicit declaration of function 'tgetent' >> [-Wimplicit-function-declaration] >> char s[1]; int res = tgetent(s, "thisterminaldoesnotexist"); >> ^~~ >> /usr/bin/ld: /tmp/ccivPtT5.o: relocation R_X86_64_32 against >> `.rodata.str1.1' can not be used when making a PIE object; recompile >> with -fPIC >> /usr/bin/ld: final link failed: nonrepresentable section on output >> collect2: error: ld returned 1 exit status > This is a bug in the configure script. It needs to pass the original > CFLAGS when compiling link tests. > > The command is set correctly initially: > > | ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS > conftest.$ac_ext $LIBS >&5' > > So something appears to reset CFLAGS in the script. Actually it was like Tom wrote - Fedora specific linker flags were used, but compiler flags were not. When I added including Fedora specific compiler flags to configure script, it started to work. Now let's hope upstream will take it. Thank you for the hint too though :) . > > Thanks, > Florian > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Blocking criteria proposal for F30+: Printing
+1, I agree with proposed text. On 2/28/19 10:56 PM, Stephen Gallagher wrote: > I just realized I only responded to Zdenek the other day. Re-sending > my response now. > > > On Tue, Feb 12, 2019 at 9:13 AM Zdenek Dohnal wrote: >> Hi, >> >> comments are in the text: >> >> On 2/11/19 9:17 PM, Stephen Gallagher wrote: >>> On Mon, Feb 11, 2019 at 2:24 PM Chris Murphy >>> wrote: >>>> On Mon, Feb 11, 2019 at 9:58 AM Stephen Gallagher >>>> wrote: >>>>> Sorry that it's taken me so long to get back to this. >>>>> >>>>> I think the feedback on this has been mostly positive on the Beta >>>>> criteria, but I'd like to tweak the phrasing a bit and see if this >>>>> comes off more favorable: >>>>> >>>>> I'd like to propose that we add the following criteria to Beta for Fedora >>>>> 30+: >>>>> * Printing must work on at least one printer available to Fedora QA. >>>>> "Work" is defined as the output from the device matching a preview >>>>> shown on the GNOME print preview display. (Note that differences in >>>>> color reproduction are not considered "non-working".) >>>> Does the criterion pply strictly to the printing of text and line >>>> art, or does it also apply to gross departures in photographs? If the >>>> latter: >>>> >>>> ^minor differences in color reproduction are not considered "non-working"; >>>> or >>>> ^only major differences in color reproduction are considered "non-working" >>>> >>>> Major defined as any of: >>>> obvious and grossly incorrect scaling (e.g. +/- 20%) >>>> color inversion, torqued primaries (white becomes black, black becomes >>>> white; red becomes blue, blue becomes green, etc) >>>> tone reproduction that obliterates relevant identifying detail in two >>>> or more test images >>>> >>>> With that language I'm trying to carve out only remarkable, WTF level, >>>> bugs as blockers. >>>> >>> I think we can *probably* leave this as a thing to be decided at a >>> blocker bug review. I really want to avoid trying to set a hard line >>> on a topic that is inherently subjective. In general, I think we can >>> just rely on the "last blocker at Go/No-Go" test for this. >> I agree with Stephen - such topics can be really subjective and even the >> fault does not have to be on Fedora side (f.e. when you catch the file >> which goes to the printer, you look into it and it looks fine, but >> output paper has 'slightly' different colors, scale etc... - so there >> can be issues in the printer itself). >>>> Next question is what applications to use for printing, since the >>>> initiating application matters. What if there's a bug in just one >>>> application? That shouldn't be a printing blocker (it might be a basic >>>> functionality blocker for that application if it's included in default >>>> installations). So I'd say pick two. Firefox and LibreOffice? Firefox >>>> and evince? >>>> >>> How about "Desktop environment's 'test page' functionality" and >>> whichever basic text editor comes with it. >> IMHO it is not correct blocker criteria for printing as itself, but it >> is more like blocker for these applications. AFAIK blocker is the issue, >> which can not be worked around - if the file is printable by CUPS CLI >> commands 'lp'/'lpr', but not from a app, IMHO it is not blocker for >> printing. >> >> IMO issues like 'not being able to print from X application' should be >> blocking/release criteria for some common/widely used apps like >> Firefox/evince/libreoffice, not for printing itself. (If the issue would >> be actually connected to CUPS, I'll cooperate with them to fix the issue). >> > Well, we don't have to be that specific in the release criteria, > honestly. We're talking about blocker criteria specifically for > blocking desktops, so in my opinion it's okay to have "test page" and > "basic text editor" as the stand-ins for this. (This is similar to how > we have "package manager must be able to download and apply updates" > as a stand-in for "the network must not be totally broken".) > > I'd be fine if we wanted to add a corollary that ei
Re: Blocking criteria proposal for F30+: Printing
On 3/11/19 10:52 PM, Chris Murphy wrote: > On Thu, Feb 28, 2019 at 2:56 PM Stephen Gallagher wrote: > >> * Printing must work on at least one printer available to Fedora QA. >> "Work" is defined as the output from the device matching a preview >> shown on the GNOME print preview display. (Note that non-ridiculous >> differences in color reproduction are not considered "non-working". In >> general, we'll apply the "last blocker at Go/No-Go" principle here >> when deciding whether a print glitch is truly blocking.) >> >> and this to Final for Fedora 30+: >> * Printing must work (as defined above) on at least one printer using >> each of the following drivers: >> - The built-in print-to-PDF driver >> - The generic IPP driver >> * For each blocking desktop, it must be possible to print: >> - A test page from the desktop environment's built-in "test page" >> feature, if such a feature exists. >> - A simple text document of at least 100 words (lorem ipsum) from >> the standard basic text editor accompanying that desktop. >> >> This does not mean that all printers need to function properly that >> use the IPP driver, just that at least one does (so we >> know that printing as a whole is unbroken). We won't specify any >> particular hardware makes or models that must work. > I think "generic IPP driver" needs to be more specifically stated. > > There's IPP protocol versions 1.1, 2.0, 2.1 and 2.2. The "driverless" > specification is IPP Everywhere, which uses IPP protocol versions 2.0 > or higher, along with additional requirements to support driverless > device discovery and printing of text and images. There isn't strictly > speaking a generic IPP driver, although PCL and PostScript are common. IMHO Stephen meant it as driverless 'driver' or IPP everywhere enabled printer, since 'generic IPP driver' does not exist. > > What supports IPP Everywhere out of the box? > > Any computer running CUPS 1.5 or later I beg to differ that it is not entirely correct. Yes, there are some features for driverless support in <2.1.0 (approximately), but since it was not so widely used at that time, some features were still missing or needed some more tweaks for make it right. > Mobile devices running Android 4.4 and later > > Proposal for Fedora 30: If anyone is able to, with reasonable effort, > successfully run the agreed test cases to any printer supporting IPP > 2.0 or higher, using whatever driver is required, then we don't block. I would go with 'if printing works on IPP everywhere printer available for Fedora QA' (hooray, we have one :) ) 'then do not block'. But it seems as technicality... IMHO blocking the release if 'whatever' IPP everywhere printer does not work seems like a trap to me - you basically believe that every printer vendor implemented their IPP server and used HTTP server (IPP is transfered by HTTP protocol) into printers firmware correctly - which is not true till now. > Proposal for Fedora 31: If anyone is able to, with reasonable effort, > successfully run the agreed test cases to any IPP Everywhere printer, > then we don't block. > > Something I need to dig into deeper is how to create a virtual IPP > Everywhere printer (a service); which would be useful for testing, in > particular automated testing such that the virtual printer itself says > "yes this is a valid print job". ippsample project does that, you can find it in that github link you posted, together with sample of ippserver, which should become 'server solution' for CUPS (the idea is to use CUPS only as client app, and any infrastructure servers will run only IPP server, which will present printers to other machines). > But also it might be possible to > bridge the virtual IPP Everywhere printer with a conventional > CUPS+gimp/foomatic driver based printer. This idea is similar to which Mike Sweet presented on PWG meetup last year - printer applications - combination of IPP server(not CUPS)+specific printer driver provider. I created a report from that PWG meetup, please see that. I plan to add all these projects into Fedora to have fully IPP everywhere solution (ippusbx, ipp-selfcert, ippsample), but not so much time to do it yet... > If so, I'm thinking Fedora > IoT on a Raspberry Pi Zero W, using a static containerized approach, > that once working, should be a reliable indicator that any failures > coinciding with print pipeline changes in the client, are in fact > client bugs. But we'll see about that. > > This might be useful: > IPP Everywhere mini-tutorial > https://github.com/apple/cups/w
Re: Blocking criteria proposal for F30+: Printing
On 3/12/19 11:28 PM, Chris Murphy wrote: > On Tue, Mar 12, 2019 at 2:53 AM Zdenek Dohnal wrote: >> IMHO Stephen meant it as driverless 'driver' or IPP everywhere enabled >> printer, since 'generic IPP driver' does not exist. > OK. > >>> What supports IPP Everywhere out of the box? >>> >>> Any computer running CUPS 1.5 or later >> I beg to differ that it is not entirely correct. > I got that straight out of the IPP Everywhere FAQ, but the point I did > not state and should have is, Fedora 30 definitely far exceeds the > minimum requirement. That was also the point of pointing out Android > 4.4 supports it. > > >>> Proposal for Fedora 30: If anyone is able to, with reasonable effort, >>> successfully run the agreed test cases to any printer supporting IPP >>> 2.0 or higher, using whatever driver is required, then we don't block. >> I would go with 'if printing works on IPP everywhere printer available >> for Fedora QA' (hooray, we have one :) ) 'then do not block'. But it >> seems as technicality... > I'm completely fine with narrowing this to an IPP Everywhere printer > for Fedora 30. From yesterday's QA meeting, I was understanding they > don't have an IPP Everywhere printer, but figured it should be > possible to track down an IPP 2.0+ printer. So yeah if there's an IPP > Everwhere test printer handy, just go with that from the outset. > I'm not entirely sure who is exactly meant as Fedora QA to be honest. IMHO since most developers in Fedora works on RHEL+CentOS too, I would expect similar thing on QA part. And RHEL QE now has IPP Everywhere printer available, so as CUPS maintainer can test if it works. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
PWG f2f - Lexington 2019 - report
Hi! I attended PWG (printing working group) f2f vie Webex last week (I attended one and half day of conference). It was held in Lexington this year and you can find by full report in the attachment. The main new (in comparison to previous year) points were: 1) CUPS license issue is coming to the solution - CUPS 2.3 will stay under new Apache License 2.0 and it will have exception like LLVM does for GPL2 only programs. Security fixes and other important fixes (if you want something to backport to 2.2.x, create an issue at cups github for backporting that specific patch) will stay under old license. But there is still open issue about it, so I would delay rebasing CUPS to 2.3 in Fedora rawhide until final outcome exists. 2) ippeveprinter binary came into CUPS master branch - the purpose of the binary is to be kind-of wrapper around PCL or Postscript printers, makes them visible for Avahi (preferred way of sharing printers since cca 2012) and process received document to wanted data for printer. You can check the code and try it from CUPS master branch. 3) Several projects of Openprinting+PWG were announced in Google Summer of Code 2019 - the main project is creating API for writing Printer Applications, I will mentor one small project - convert scp-dbus-service.py into C, since printing sw is mainly written in C. -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C PWG 2019 PWG plenary -- - ipp eve certified printers - now 365! - new versions of IPP eve - 1.1 and IPP eve selfcert - 1.1 - new project - ipp registry - imaging device security - security of hardcopy devices -focus on common criteria profiles for HCD - ipp workgroup - maintenance of IPP, support of network archs in IPP - IPP enterprise printing extension 1.0? - trusted computing group - specifications for mobile platforms and trusted mobility solutions - IETF - RFC for new TLS-1.3, security automation and continuous monitoring drafts - openprinting - new gsoc projects (Zdenek Dohnal is one of the mentors) - test script for IPP errata and IPP system service, printer app from legacy driver, improve pdftoraster filter, turn scp-dbus-service into C, new website - mopria - print and scanning services for mobiles - 3D printing Openprinting plenary - CUPS-filters - no new features, focus on reliability, pdftoopvp and pdftoijs deprecated, in the future remove CUPS PPD API, treat equal IPP printers and remote cups queues as equal - IPP system service - future - support for MFD and printers+possible driverless MFD and scan - GSoC projects CUPS plenary - licensing - report important issues for backporting to older CUPS with old license, security fixes will be still with old license, APACHE 2.0 otherwise - CUPS-2.3.0 - focus on license change, ipp eve, print accounting, scheduler - the last release with printer driver support (2021) - they will have exception for GPL2/LGPL2-only sw (same as LLVM) - ipp eve - localizations, job preset, finishing-template support, closing any CUPS API holes preventing of usage of ipp eve - print accounting - track total number of pages at the end of job - scheduler - sharing hostname can be set, .strings file is created when printer is created - for localization, support for printer id and no hardcoded script interpreters in CGI - API - new function for adding media options - cupsAddDestMediaOptions(), encoding IPP attr from CUPS options - cupsEncodeOption, -D_IPP_PRIVATE_STRUCTURES=1 does not work, -D_PPD_DEPRECATED="" does not work :) - FUTURE: Modular cups with following modules: commands, local server handles print requests on local temporary queues, cups sharing server handles network print requests (acounting, Acl, pam auth, oauth2 ipp shared infrastructure) with permanent CUPS queues, CUPS library, oauth 2.0 as replacement for Kerberos (does not need root access) - printer apps - printer drivers will look as ipp eve - ipp eve printer - replacement of ippserver, two commands - PCL printers ippevepcl - like PCL laser printer bundled with CUPS, ippeveps for postscript printers (runs pdftops and specific filters), use with PPD file - output from commands can be sent to AppSocket or spool dir - why? wonderful for debugging for now! just get PPD and create ippeve printer by it - FUTURE ippeveprinter vs ippserver - single ipp eve printer vs implements ipp system service with multiple IPP printers (print commands for ippserver will work for ippeveprinter, but not otherwise because missing backends and filters) Openprinting projects update - - 2018 - conversion bannertopdf to QPDF, enhancement ipptool (new support for attributes and operations), ippdoclint program (check-up if pwg raster document file is correct - structure, content), content-oriented printer auto-selection (cluster abritary collection of printers into one queue with merghed PPD with a
Re: Blocking criteria proposal for F30+: Printing
Hi, as CUPS maintainer, I agree with the idea of working printing as beta criteria for Fedora. I have two printers (Canon, HP) at my disposal, which I test cups, cups-filters and hplip on when they have rebase. IMO it would be perfect if such tests can be run every time when a component, which CUPS requires, have an update - this way I could get know of glibc change or nsswitch change sooner... I can cover two printer driver software, hplip and foomatic-db+foomatic with this testing (at least for these two printer models), but I would need other printers for others (like gutenprint, foo2zjs, not mention 3rd party ones like brother, lexmark, epson) and especially a printer which is capable of driver-less printing (like IPP everywhere standard, or Airprint), which is the newest way how to install printers (I mean most printers with release date after 2010). It would be great that we can test it out too... This way I would like to reach who they have such printers and asked them for cooperation with testing - preferably on every cups update test if printer works as it should. According cups-pdf, which is different project and isn't under my maintenance, I'm not sure, but I'm CCing cups-pdf maintainer, if he can say more about it. The same can be said about ghostscript - it should be tested properly too. On 9/20/18 4:21 PM, Chris Murphy wrote: > > > On Thu, Sep 20, 2018, 7:50 AM Stephen Gallagher <mailto:sgall...@redhat.com>> wrote: > > On Thu, Sep 20, 2018 at 9:47 AM Ben Cotton <mailto:bcot...@redhat.com>> wrote: > > > > On Thu, Sep 20, 2018 at 8:33 AM Stephen Gallagher > mailto:sgall...@redhat.com>> wrote: > > > > > > I'd like to propose that we add the following criteria to Beta > for Fedora 30+: > > > * Printing must work on at least one printer available to > Fedora QA. > > > "Work" is defined as the output from the device matching a preview > > > shown on the GNOME print preview display. (Note that > differences in > > > color reproduction are not considered "non-working".) > > > > > +1 to this > > > > > and this to Final for Fedora 30+: > > > * Printing must work on at least one printer using each of the > > > following drivers: > > > (I don't know which ones to specify here, but we ought to try to > > > figure out a cross-section that covers a large swath of our > expected > > > user base). > > > > Print to file (PDF) is available by default and should be in the list. > " work" means > - creates a file that, when opened with the default PDF reader and in > Firefox using its built-in PDF support, is reasonably similar to > the preview shown on the GNOME print preview display. > > As for a real printer, I suggest limiting it to an IPP Everywhere > printer (any make and model), also known as driverless printing. > > Otherwise you can quickly get stuck in the mud. > > > > So I'd suggest that this criteria > essentially means "We block if it is *known* to fail". > > > > +1 > > Chris Murphy > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Blocking criteria proposal for F30+: Printing
On 9/20/18 6:47 PM, Chris Murphy wrote: > On Thu, Sep 20, 2018 at 10:22 AM, Peter Robinson wrote: >>> There was a bug[1] filed recently that indicated that printing was >>> broken on certain printers. As a result of that discussion, it became >>> apparent that there was no criteria for printing to work at all, which >>> seems like an oversight. >>> >>> I discussed this briefly with Matthias Clasen this morning and he >>> agreed that this should be treated as blocking for Workstation. >>> >>> I'd like to propose that we add the following criteria to Beta for Fedora >>> 30+: >>> * Printing must work on at least one printer available to Fedora QA. >>> "Work" is defined as the output from the device matching a preview >>> shown on the GNOME print preview display. (Note that differences in >>> color reproduction are not considered "non-working".) >>> >>> and this to Final for Fedora 30+: >>> * Printing must work on at least one printer using each of the >>> following drivers: >>> (I don't know which ones to specify here, but we ought to try to >>> figure out a cross-section that covers a large swath of our expected >>> user base). >> I'm against this as a blocker for a number of reasons: >> * When we've tried to do hardware specific blocking at the time like >> dual boot with MacOS this has not worked well and the dual boot is >> testable with one piece of hardware >> * It's easy to do a zero day update or a standard update to fix it >> post release as doesn't affect the install path >> * We don't do it for other non critical hardware selections such as >> digital cameras, video cameras, and other such things >> * Hardware availability, I don't see blocking for one type of printer >> over another type is a good use of our time. > > I think it's reasonable to block on some really basic aspects of > printing breakage, like not being able to print to a PDF file, and > possibly being unable to print to the far simpler realm of IPP > Everywhere printers. > > But model specific stuff. No way. I'd be generous with freeze > exceptions, but not blocking the release. I'm even on the fence if I'd > actually block on IPP Everywhere printing being broken. Once we're at > a blocker, do we have the resources to get it fixed within a few days? > If not, forget it. It can't be a blocker if we don't have the > resources to support fixing the blocker in a time escalated manner. > > IMHO for the specific stuff (main printer drivers packages - hplip, foomatic+foomatic-db, gutenprint) we could do a test of general functionality - like if there is at least one printer which works with ppd from the package, then package seems to okay to go. -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
qpdf soname bump in rawhide to 21.2.1
Hi, qpdf got new version and I would like to rebase our rawhide version, but two packages will need to be rebuilt, because they depends on libqpdf library. They are: - python-pikepdf - cups-filters I can manage cups-filters rebuild, but I would like to ask python-pikepdf's maintainer to rebuild his package. I have copr project https://copr.fedorainfracloud.org/coprs/zdohnal/qpdf/builds/ , where I tried to rebuild cups-filters and python-pikepdf with new qpdf. python-pikepdf's new version fails to build even with old qpdf (I reported it to python-pikepdf's maintainer at bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1631890). Because python-pikepdf is broken anyway, I'll rebuild cups-filters and put new qpdf with rawhide. -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: qpdf soname bump in rawhide to 21.2.1
I'm sorry, it is only minor soname bump 21.0.1 -> 21.2.1, but I wasn't sure if dependent packages needs to rebuild, so I rather announced it and rebuilt dependent packages. On 9/25/18 1:44 AM, Elliott Sales de Andrade wrote: > Hi, > > On Mon, 24 Sep 2018 at 09:52, Zdenek Dohnal <mailto:zdoh...@redhat.com>> wrote: > > Hi, > > qpdf got new version and I would like to rebase our rawhide > version, but > two packages will need to be rebuilt, because they depends on libqpdf > library. > > > I'm confused; there does not appear to be a soname bump: > > $ rpm -q --provides qpdf-libs > libqpdf.so.21()(64bit) > libqpdf.so.21(LIBQPDF_21)(64bit) > qpdf-libs = 8.1.0-3.fc29 > qpdf-libs(x86-64) = 8.1.0-3.fc29 > > vs > > $ rpm -q --provides -p ./qpdf-libs-8.2.1-1.fc30.x86_64.rpm > libqpdf.so.21()(64bit) > libqpdf.so.21(LIBQPDF_21)(64bit) > qpdf-libs = 8.2.1-1.fc30 > qpdf-libs(x86-64) = 8.2.1-1.fc30 > > > - python-pikepdf > > - cups-filters > > I can manage cups-filters rebuild, but I would like to ask > python-pikepdf's maintainer to rebuild his package. > > > Rebuild is done. > > > I have copr project > https://copr.fedorainfracloud.org/coprs/zdohnal/qpdf/builds/ , where I > tried to rebuild cups-filters and python-pikepdf with new qpdf. > python-pikepdf's new version fails to build even with old qpdf (I > reported it to python-pikepdf's maintainer at bugzilla > https://bugzilla.redhat.com/show_bug.cgi?id=1631890). > > Because python-pikepdf is broken anyway, I'll rebuild cups-filters and > put new qpdf with rawhide. > > -- > Zdenek Dohnal > Associate Software Engineer > Red Hat Czech - Brno TPB-C > > > > > -- > Elliott -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 29 Beta - Cannot add printer
Hi, What type of printer do you want to add (ethernet/usb/wifi)? I tried to add ethernet and usb types in my clean F29 virtual machine and both worked. If the printer is usb or it is in the same network as your PC, then you should see it in CUPS web api when you try to add new printer (on localhost:631, when cups.service is running - tab Administration, 'Add new printer'). If you can add printer through CUPS web api, then the issue will be in gnome-control-center. On 10/12/18 12:28 AM, Gilles Dubreuil wrote: > Added screenshot > > > On 12/10/18 09:27, Gilles Dubreuil wrote: >> Hi, >> >> Using default Gnome shell on Wayland I cannot add a printer. >> >> In Gnome settings, after pressing "unlock" and "add" button and than >> selecting a driver, a pop up message "Failed to add new printer" >> There are no messages in system journal. >> >> PS: I've SELinux in permissive mode just in case. > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 29 Beta - Cannot add printer
Thanks for letting me know. Would you mind filing the bugzilla report to control-center component with steps to reproduce, mention the printer connection type, model of the printer, mention the fact the installation works through CUPS web api and some other info mentioned in https://fedoraproject.org/wiki/How_to_debug_printing_problems (f.e. cups logs from journal are the most important). Thank you! On 10/24/18 12:59 AM, Gilles Dubreuil wrote: > > Hi Zdenek, > > I'm doing a WIFI mode. > Installation works fine using CUPS but It's not working through > gnome-control-center. > > Thanks, > Gilles > > On 12/10/18 8:42 pm, Zdenek Dohnal wrote: >> >> Hi, >> >> What type of printer do you want to add (ethernet/usb/wifi)? I tried >> to add ethernet and usb types in my clean F29 virtual machine and >> both worked. >> >> If the printer is usb or it is in the same network as your PC, then >> you should see it in CUPS web api when you try to add new printer (on >> localhost:631, when cups.service is running - tab Administration, >> 'Add new printer'). >> >> If you can add printer through CUPS web api, then the issue will be >> in gnome-control-center. >> >> On 10/12/18 12:28 AM, Gilles Dubreuil wrote: >>> Added screenshot >>> >>> >>> On 12/10/18 09:27, Gilles Dubreuil wrote: >>>> Hi, >>>> >>>> Using default Gnome shell on Wayland I cannot add a printer. >>>> >>>> In Gnome settings, after pressing "unlock" and "add" button and >>>> than selecting a driver, a pop up message "Failed to add new printer" >>>> There are no messages in system journal. >>>> >>>> PS: I've SELinux in permissive mode just in case. >>> >>> >>> >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> -- >> Zdenek Dohnal >> Associate Software Engineer >> Red Hat Czech - Brno TPB-C > -- > Gilles Dubreuil > Senior Software Engineer - Red Hat - Openstack DFG Integration > Email: gil...@redhat.com > GitHub/IRC: gildub > Mobile: +61 400 894 219 > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 29 Beta - Cannot add printer
Hi Sam, thank you for your opinion! Would you mind telling me what are the features of s-c-p, which makes you think s-c-p is more useful and functional? I'm not control-center maintainer or upstream, but IMHO they will be happy for propositions of enhancements. Or if control-center doesn't make it, there's still CUPS web api, which is enabled by default at localhost:631. You only need to have cups.service running (if you don't want to have the service running forever and you have socket and path units enabled and running, then you can stop and disable the service). On 10/24/18 4:26 AM, Samuel Sieb wrote: > On 10/23/18 3:59 PM, Gilles Dubreuil wrote: >> I'm doing a WIFI mode. >> Installation works fine using CUPS but It's not working through >> gnome-control-center. > > I find that "system-config-printer" is much more useful and functional > than trying to do it through the control center. I have had very > little success in using the control center option. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Zdenek Dohnal Associate 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
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
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: 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
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: 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: 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
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
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: 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
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 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/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
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
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
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
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: 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
[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: [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
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: 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
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
Write permissions on Fedora Wiki
Hi, this is probably kind of off-topic, but I think there could be a someone, who encountered it too. Does anyone please know, in which Fedora user group I need to be to be able to write to Fedora wiki and where I can be added to such user group? I would like to update printing pages, but sadly I do not have such right to modify the page. Thank you in advance, Zdenek signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Write permissions on Fedora Wiki
On 01/02/2018 04:32 PM, Pierre-Yves Chibon wrote: > On Tue, Jan 02, 2018 at 04:05:11PM +0100, Zdenek Dohnal wrote: >> Hi, >> >> this is probably kind of off-topic, but I think there could be a >> someone, who encountered it too. Does anyone please know, in which >> Fedora user group I need to be to be able to write to Fedora wiki and >> where I can be added to such user group? I would like to update printing >> pages, but sadly I do not have such right to modify the page. > You need to sign the Fedora Project Contributor Agreement (FPCA) and be part > of > one more group (doc, ambassador, design, packager...). > > We had to put this requirement in place due to a wave of spammers that hit us > hard a few months back. Sorry that it causes you problems. > > > Pierre Sorry for spamming guys, issue was on my part - new web ui confused me, so I thought I'm logged in, but I wasn't. > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Zdenek Dohnal Associate 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
Re: [HEADS UP] Removal of systemd-units
On 01/25/2018 07:17 PM, Jason L Tibbitts III wrote: > > zdohnal system-config-printer Done. -- Zdenek Dohnal Associate 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
Re: Escaping macros in %changelog
On 02/08/2018 05:02 PM, Igor Gnatenko wrote:
> Hello everyone,
>
> It seems that a lot of people have %file, %check, %build, %whatsoever
> in their
> changelog section.
>
> Is there any reason I should not go and automatically escape them?
>
> %check → %%check
> %build → %%build
> %whatsoever → %%whatsoever
>
> There might be valid use-cases, but I'm not sure if they really are:
> %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
>
>
> Thoughts?
+1 for me, go ahead :)
> ___ > devel mailing list --
> devel@lists.fedoraproject.org > To unsubscribe
send an email to devel-le...@lists.fedoraproject.org
--
Zdenek Dohnal
Associate 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
Re: [HEADS UP] Mass-macro-escape in %changelog
> zdohnal cups-filters net-tools system-config-printer I checked system-config-printer and there are only '% ' and '%,' in changelog, which aren't rpm macros. Others are escaped in changelog, no need to fixing it. -- Zdenek Dohnal Associate 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
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On 02/18/2018 06:09 PM, Igor Gnatenko wrote: > > List of packages and respective maintainers: > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt > zdohnalc2esp cups cups-filters enscript foomatic hplip jbigkit mgetty > openobex pnm2ppa ptouch-driver python-cups python-smbc qpdf sane-backends > sane-frontends splix system-config-printer vim xsane Done in packages where I am the main admin. -- Zdenek Dohnal Associate 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
Vim: removing %{_libdir}/vim from vim-filesystem
Hi,
I want to have vim-filesystem subpackage as noarch (as most packages
with *-filesystem subpackage have), but dir mentioned above is
architecture specific, so I want to remove it.
This dir was added in bugzilla #1193230 as dir for plugins .so files. I
made repo queries, if any package puts files there - none package from
official Fedora repositories puts files in %{_libdir}/vim, so its
removal shouldn't influence anyone.
I'm writing this email to just let you know - if this removal will cause
problems for someone, please let me know/file a bugzilla.
--
Zdenek Dohnal
Associate 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
Re: CUPS will change license since 2.3 version - now incompatible with GPLv2
Thanks Louis! On 02/21/2018 11:15 PM, Louis Lagendijk wrote: > On Wed, 2017-11-08 at 10:42 +0100, Zdenek Dohnal wrote: >> Hi, >> >> CUPS upstream changed license of project to Apache license 2.0, which >> is >> now incompatible with GPLv2. This change will be in new minor release >> of >> CUPS - 2.3.0, which is currently in developing phase (not in Fedora >> for >> now). If someone takes code of CUPS and has its project under GPLv2, >> please change it to GPLv3 (which should be compatible according >> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLi >> censes >> ) or try to argument with CUPS developers against this change on >> their >> mailing list c...@cups.org . >> >> Is there someone who is influenced by this change? > My apologies fr the late response: I have been pretty busy. > cups-bjnp was affected as it was GPLv2 only. In versiob 2.0.1 It is now > changed to be GPLv2 or later. The new package has been built for > Rawhide and f28. > > /Louis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Zdenek Dohnal Associate 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
Re: CUPS will change license since 2.3 version - now incompatible with GPLv2
On 02/26/2018 10:41 AM, Florian Weimer wrote: > On 11/08/2017 01:45 PM, Neal Gompa wrote: >> It will. Previously, it was licensed under GPLv2 + LGPLv2 with Apple >> exceptions. Now it is ASL 2.0 across the board. GPLv2 projects can not >> link to the newer version. > > On the other hand, libgcc switched to GPLv3+ with exceptions (but > those exceptions do not restore GPLv2 compatibility), so under this > strict interpretation, we could not ship any GPLv2 userspace software > anyway. > > So I wonder if we can just declare CUPS a system library and move on. Solomon asked about the issue on legal list https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/TYGLR34XR6L6MAXMVSDNYT3ZYXUKY7FX/ . I concluded from Tom's comment that even declaring CUPS as OS-supplied library needs to be documented in a way (not mention this isn't solution which Debian/Ubuntu would approve). I presented both Tom's solutions (mentioned in his email) to Mike on cups-devel mailing list+github issue, but without any decision yet (pinged him during beta and release candidate). It's sad - I will not package cups 2.3 for Fedora until it is solved... Github issue: https://github.com/apple/cups/issues/5174 > > (It would be a different matter if CUPS itself depended on GPLv2 > components. I have not checked that.) I checked requirements in spec - CUPS doesn't need any GPLv2only component for building nor linking. > > Thanks, > Florian > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Zdenek Dohnal Associate 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
Re: CUPS will change license since 2.3 version - now incompatible with GPLv2
Hi Gerald, I'll try to explain how I understood it: On 02/26/2018 03:45 PM, Gerald B. Cox wrote: > > I must be missing something what is sad? It has been stated that > CUPS does > not need any GPLv2 only component for building or linking. The issue is about packages, which have GPLv2only license and they need CUPS libraries for building or linking. > Tom's comment stated: > > "Thus, pretty much everyone is in agreement that GPLv3 + Apache 2.0 is > a fine combination. > If the combination is GPLv2 or later, then you can resolve any > concerns about compatibility between GPLv2 and > Apache 2.0 by using the GPLv3 license in situations where that work is > combined with an Apache 2.0 work." > > and > > "As far as LGPL compatibility goes, because the LGPL provides > permission for anyone to use the LGPL > work under the terms of the GPL (section 3 of the LGPLv2 and section > 2.b of the LGPLv3). LGPLv2 permits the > terms of GPLv2 or GPLv3 (or any future version of GPL) to be applied > in place of the LGPLv2 terms. > LGPLv3 permits the terms of GPLv3 to be applied in place of the > LGPLv3 terms. > Thus, LGPLv2 + Apache 2.0 _and_ LGPLv3 + Apache 2.0 are considered > compatible." > > So what's the issue? > I think the problem's description lies lower in Tom's email - begins "So, that leaves us with GPL version 2 (only) and Apache 2.0. In this scenario, it is worth noting a few things:" -- Zdenek Dohnal Associate 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
Re: CUPS will change license since 2.3 version - now incompatible with GPLv2
On 02/27/2018 03:22 PM, Gerald B. Cox wrote: > AA. Fedora is not (at this time) concerned about license compatibility > issues arising from the relicensing of CUPS to Apache 2.0, in as much > as this applies to linking of components together (our use case). > > BB. If you are planning on (or have) copying code from CUPS and > including it in a GPLv2 only licensed work, seek legal counsel, that > is a more complicated scenario that Fedora does not face right now (as > far as I know). > > Then I don't quite get A. paragraph, where Tom talks about requirements which need to be done. Tom, would you mind clarify it for me, please? > As I understand the issue - this is only related to a few projects > that are GPLv2 and are using CUPS in such a way that causes license > issues. If that is the case they should simply change their license > to GPLv2 or later. That's the issue - change of license needs mutual agreement of project owner and all contributors, whose made significant contribution into project (AFAIK) . And it can be difficult. > It's that simple. In other words, the onus to fix the issue lies > with the projects that are using GPLv2 - not CUPS. If they don't want > to change their license, going forward they shouldn't be using cups. > Yes, I can package cups 2.3 for Fedora, but I don't want to create additional work for packagers, whose components depend on CUPS, without clear steps what to do when their package is GPLv2 only - because it is not clearly clarified by upstream yet. I would like to package new cups when I can clearly say - "Hi, CUPS moved to Apache 2.0 license in 2.3.0 version, which is incompatible with GPLv2 only. Packages which are GPLv2 only needs to be re-licensed, there is only way.". > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Zdenek Dohnal Associate 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
Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)
Hi, I'm deeply sorry, I thought cups-filters will be rebuilt with new qpdf during next mass rebuild - I forgot about 'rawhide is alpha' policy so dependent packages need to be rebuild immediately with rebased package. Again, I'm deeply sorry and thank you Adam and Rex for fixing it! On 02/27/2018 07:16 PM, Adam Williamson wrote: > qpdf was updated from 7.1.1-4 to 8.0.0-1 in Rawhide on 2018-02-26. > This update bumped the soname from libqpdf.so.18 to libqpdf.so.21 . > This soname bump was not announced, as it is supposed to be, and > dependent packages were not rebuilt. > > cups-filters depends on qpdf, so anything that includes cups-filters is > now broken. This includes at least the Astronomy_KDE live image, per > https://pagure.io/dusty/failed-composes/issue/24#comment-496381 . > > Once again, folks, *please* announce your soname bumps, and co-ordinate > rebuilds. (In fact it looks like Zdenek is the maintainer of both > packages and could have rebuilt cups-filters, but just forgot to). > > I will attempt a rebuild of cups-filters using provenpackager > privileges. -- Zdenek Dohnal Associate 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
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: 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
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
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
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: 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
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: 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/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/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: 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: 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
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
