Postings by Zdenek Dohnal

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.

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
<a href="" title=""></a> , 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?

PWG f2f - Lexington 2019 - report


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.

Default LDFLAGS in build system - possible problems


I, as Fedora's vim co-maintainer, encountered the issue with default

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.

Unannounced soname bump - ->


there is unannounced soname bump in the buildroot of rawhide and F29: ->

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.

qpdf soname bump in rawhide to 21.2.1


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

Correcting licenses in several packages I maintain


I reviewed licenses in files for my packages, so I added several
corrections of license tags:


- from GPLv2

- to GPLv2+ and LGPLv2+ with exceptions and AML


- from GPLv2 and GPLv2+ and GPLv3 and GPLv3+ and LGPLv2+ and MIT

- to GPLv2 and GPLv2+ and GPLv3 and GPLv3+ and LGPLv2+ and MIT and BSD
with advertising


- from GPLv2+ and MIT and BSD
- to GPLv2+ and MIT and BSD and IJG and Public Domain and GPLv2+ with
exceptions and ISC

- from Artistic 2.0
- to (Artistic 2.0 or ASL 2.0) and MIT

- from GPLv2+ and GPLv2+ with exceptions and Public

Intent to retire pkpgcounter

Hi everyone,

pkpgcounter (alternative sw written in python2 for counting pages of
several document types - usually covered by CUPS system - and computing
ink coverage needed for printing specific document - never heard of
someone who uses it...) started to fail to build from source.

I would like to retire this package (read it as I will not solve FTBFS
bugzilla, so pkpgcounter will get retired in the future) because of
following reasons:

- dead upstream - the last update on upstream website is 2013

- code is python2 only, which is going to be retired at 1st January 2020
- if someone would

qpdf SONAME bump to 21.1.0


qpdf has new version - 8.1.0 - and it bumps the soname of shared library
to 21.1.0. Only cups-filters depends on it, so I'll manage the rebuild

Vim: removing %{_libdir}/vim from vim-filesystem


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.

Write permissions on Fedora Wiki


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,


CUPS will change license since 2.3 version - now incompatible with GPLv2


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
<a href="" title=""></a>
) or try to argument with CUPS developers against this change on their
mailing list <a href="mailto: ... at cups dot org"> ... at cups dot org</a> .

Is there someone who is influenced by this change?

hp-plugin doesn't work in hplip-3.17.9 - move to 3.17.10 if you need


HP changed website this week, which has consequences for getting hp
proprietary plugin - it cannot be downloaded anymore for hplip-3.17.9,
which is in stable Fedoras (f25 and f26) and Fedora 27.

Removing ghostscript-fonts package


I am going to retire ghostscript-fonts package in F27 because its fonts
are deprecated and replaced by urw-base35-fonts package. Only package
which depends on ghostscript-fonts seems to be hylafax+ package, I
created bugzilla for it
<a href="" title=""></a> . Does anyone have
any objections on its retirement?

If there isn't any objections, I'll retire it next Monday.


RPM macros - case insensitive since Fedora 27 (maybe Fedora 26)


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.

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.