Fedora Account System
Red Hat Associate
Red Hat Customer
Releases retrieved: 0.5.0, 0.5.1 Upstream release that is considered latest: 0.5.1 Current version/release in rawhide: 0.4.9-1.fc37 URL: http://pwmt.org/projects/zathura/download/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/5298/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/zathura
What are the plans for updating zathura to 0.5.1? The background for my questions is the release of mupdf 1.21.0. Typically, I create side-tags for rawhide and all non-EOLed releases for mupdf, zathura-pdf-mupdf and python-PyMuPDF (which should soon release 1.21.0, too). This works with the current zathura package and with 0.5.1 (tested with RCs in copr). I don't want rebuilds for mupdf 1.21.0 and for zathura 0.5.1 to step on each other's toes^Wside-tags. So we should do this as one side-tag for everything, or as two steps in a specific order. I don't mind either way as long as it is coordinated :)
Releases retrieved: 0.5.2 Upstream release that is considered latest: 0.5.2 Current version/release in rawhide: 0.4.9-1.fc37 URL: http://pwmt.org/projects/zathura/download/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/5298/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/zathura
There are upstream updates to depending packages, too, and at least in part they depend on each other functionally to make use of new features in plugins. I propose to do all these in a common side tag for rawhide and f37, and possibly f36 (up for discussion). I have package updates for all affected packages that I know about (I'll push to dist-git forks and file PRs), and I'm doing rebuilds in copr here: https://copr.fedorainfracloud.org/coprs/mjg/girara-zathura-mupdf/builds/ Once current copr issues (after the planned downtime) are sorted out expect mupdf-related packages to show up there, too. Affected dependencies that I know of: girara: zathura zathura: all plugins (cb, djvu, ps, pdf-poppler, pdf-mupdf) mupdf: zathura-pdf-mupdf, python-PyMuPDF
Hi Michael You were fastest than me. I saw the notifications and started with girara. I wish to get updates in rawhide AND EPEL9. This complicates the picture... I am not a "pro" packager, never used a side-tag. I have no idea on how we can cooperate... My current girara diff: diff --git a/girara.spec b/girara.spec index 12fed90..7620962 100644 --- a/girara.spec +++ b/girara.spec @@ -1,8 +1,8 @@ Name: girara -Version: 0.3.7 -Release: 2%{?dist} +Version: 0.3.8 +Release: 1%{?dist} Summary: Simple user interface library -License: zlib +License: Zlib URL: https://pwmt.org/projects/%{name}/ Source0: https://pwmt.org/projects/%{name}/download/%{name}-%{version}.tar.xz @@ -12,7 +12,7 @@ BuildRequires: gettext BuildRequires: glib2-devel >= 2.50 BuildRequires: gtk3-devel >= 3.20 BuildRequires: intltool -BuildRequires: json-c-devel +BuildRequires: pkgconfig(json-glib-1.0) BuildRequires: libnotify-devel >= 0.7.0 BuildRequires: meson >= 0.56 BuildRequires: pango-devel >= 1.14 @@ -58,6 +58,11 @@ developing applications that use %{name}. %{_libdir}/libgirara-gtk3.so %changelog +* Tue Nov 29 2022 Alain Vigne <avigne> - 0.3.8-1 +- 0.3.8 bump +- Switch to json-glib +- SPDX license identifier + * Thu Jul 21 2022 Fedora Release Engineering <releng> - 0.3.7-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild I see your changes are slightly different...
(In reply to Alain V. from comment #4) > Hi Michael > You were fastest than me. I saw the notifications and started with girara. Yes, I mixed up the bugs for girara and zathura. Sorry about that. Let's continue the discussion here. > I wish to get updates in rawhide AND EPEL9. This complicates the picture... Not necessarily. We (girara, zathura, mupdf, ... maintainers) just have to agree which branches receive which updates. mupdf is not in EPEL yet because RH needs to provide jbig2dec-devel for the lib. This is scheduled to happen some time during RHEL 9.1 as I understand. Until then neither mupdf nor zathura-pdf-mupdf can exist in EPEL. That implies that they are not affected by zathura updates ;) > I am not a "pro" packager, never used a side-tag. I have no idea on how we > can cooperate... If, e.g. you push a girara update with a changed lib then depending packages like zathura may break. They cannot be rebuilt easily before the girara update is available and breaks things. A side-tag solves this problem: Rather then doing `fedpkg build` to build into a Fedora or EPEL target, one creates a side-tag (I can do that) and uses `fedpkg build --target=<side-tag-name>` to build into a side-tag. Once finished, that build is available in the side-tag and you can build a depending package into the same side-tag. Once everything is ready one creates a bodhi update from the side-tag: all packages land in the same update. Each side-tag is based on a target tag (branch) such as rawhide, f37 or EPEL. So we need several side-tags anyways, and we can do some updates on some side-tags but not others. As I understand you want girara to update in rawhide and EPEL 9 only. How about zathura? For mupdf, I envisage rawhide and F37, and maybe F36 depending on the preferences of depending package maintainers. The changes and interdependcies are: girara 0.3.8: deprecates notify, replaces json-c by json-glib zathura 0.5.2: proper text selection zathura-pdf-mupdf 0.4.0: text selection requires zathura 0.5.2 zathura-pdf-poppler 0.3.1: requires zathura 0.5.2 zathura-ps 0.2.7: minor clean-up ? zathura-cb, zathura-djvu: just rebuild for updated zathura mupdf 1.21.0: API additions (including stories) python-PyMuPDF 1.21.0: support stories requires mupdf 1.21.0 So: Where girara is updated zathura has to be rebuilt - not necessarily with the 0.5.2 update, but I suggest to. Where zathura is rebuilt each plugin has to be rebuilt. Where zathura is updated plugin-ins should be. Where mupdf is updated python-PyMuPDF has to be updated, and zathura-pdf-mupdf has to be rebuilt (at least). I'll try to link bugs approriately and prod the other maintainers so that we can agree on the branches. (I have commit rights for python-PyMuPDF and zathura-pdf-mupdf but do not maintain them.) > My current girara diff: ... > I see your changes are slightly different... Yours are better :) I missed dropping json-c. Do we need to keep the deprecated notify support?
(In reply to Michael J Gruber from comment #5) > (In reply to Alain V. from comment #4) > > Hi Michael > > You were fastest than me. I saw the notifications and started with girara. > > Yes, I mixed up the bugs for girara and zathura. Sorry about that. Let's > continue the discussion here. > > > I wish to get updates in rawhide AND EPEL9. This complicates the picture... > > Not necessarily. We (girara, zathura, mupdf, ... maintainers) just have to > agree which branches receive which updates. > > mupdf is not in EPEL yet because RH needs to provide jbig2dec-devel for the > lib. This is scheduled to happen some time during RHEL 9.1 as I understand. > Until then neither mupdf nor zathura-pdf-mupdf can exist in EPEL. That > implies that they are not affected by zathura updates ;) > > > I am not a "pro" packager, never used a side-tag. I have no idea on how we > > can cooperate... > > If, e.g. you push a girara update with a changed lib then depending packages > like zathura may break. They cannot be rebuilt easily before the girara > update is available and breaks things. A side-tag solves this problem: > Rather then doing `fedpkg build` to build into a Fedora or EPEL target, one > creates a side-tag (I can do that) and uses `fedpkg build > --target=<side-tag-name>` to build into a side-tag. Once finished, that > build is available in the side-tag and you can build a depending package > into the same side-tag. Once everything is ready one creates a bodhi update > from the side-tag: all packages land in the same update. > > Each side-tag is based on a target tag (branch) such as rawhide, f37 or > EPEL. So we need several side-tags anyways, and we can do some updates on > some side-tags but not others. As I understand you want girara to update in > rawhide and EPEL 9 only. I prioritize rawhide EPEL 9 Fn-1 Fn-2... How about zathura? The good news is : zathura readme reads : girara >= 0.37, so we should be safe ;) For mupdf, I envisage rawhide > and F37, and maybe F36 depending on the preferences of depending package > maintainers. > > The changes and interdependcies are: > > girara 0.3.8: deprecates notify, replaces json-c by json-glib I built in rawhide > > zathura 0.5.2: proper text selection I built in rawhide > > zathura-pdf-mupdf 0.4.0: text selection > requires zathura 0.5.2 > > zathura-pdf-poppler 0.3.1: > requires zathura 0.5.2 > > zathura-ps 0.2.7: minor clean-up > ? > > zathura-cb, zathura-djvu: just rebuild for updated zathura > > mupdf 1.21.0: API additions (including stories) > > python-PyMuPDF 1.21.0: support stories > requires mupdf 1.21.0 > > So: > Where girara is updated zathura has to be rebuilt - not necessarily with the > 0.5.2 update, but I suggest to. I agree > > Where zathura is rebuilt each plugin has to be rebuilt. > Where zathura is updated plugin-ins should be. I did not yet have a look to plugins > > Where mupdf is updated python-PyMuPDF has to be updated, and > zathura-pdf-mupdf has to be rebuilt (at least). > > I'll try to link bugs approriately and prod the other maintainers so that we > can agree on the branches. (I have commit rights for python-PyMuPDF and > zathura-pdf-mupdf but do not maintain them.) > > > My current girara diff: > ... > > I see your changes are slightly different... > > Yours are better :) > I missed dropping json-c. Do we need to keep the deprecated notify support? upstream clearly says : dropped. I drop the BuildRequires in girara
(In reply to Alain V. from comment #6) > > girara 0.3.8: deprecates notify, replaces json-c by json-glib > I built in rawhide > > > > zathura 0.5.2: proper text selection > I built in rawhide That means that zathura plugins are broken in rawhide now, doesn't it? > > I missed dropping json-c. Do we need to keep the deprecated notify support? > upstream clearly says : dropped. I drop the BuildRequires in girara upstream says dropped about the json-c requirement, deprecated for notify support. I see you dropped both, which answers my question. Are the tests failing now? I see you diabled them. In any case, there is no point coordinating side-tags when you have built into rawhide already and want to wait with other branches. I'll see about the mupdf side then.
FEDORA-2022-38e769cd68 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-38e769cd68
FEDORA-2022-38e769cd68 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.