Hi, I build tlog for EPEL7 and it finished with only one error. The changelog is not in the correct chronological order. However, when I removed all changelog entries except for the latest one, the build completed without issues. Of course this needs to be properly fixed to prevent mock from failing. After the build, I installed the tlog package on a RHEL7 system and worked fine when doing simple records and replays. Would you please consider to maintain an EPEL version of this package? It would simplify installation and maintenance. Thanks!
I could also co-maintain this package with you. But I personally would then remove the debbuild and SUSE stuff from it. Is there a reason why you want to support Debian based systems in this RPM? SUSE I get, but for simplicity I would personally only focus on Fedora and EPEL.
Hi, sorry I don't have time to maintain tlog in EPEL. You are welcome to take it over if you are able to. If you are referring to the spec file SUSE/debbuild parts, they can be removed - I was trying to keep a unified spec file with the upstream git repo. -Justin
(In reply to jstephen from comment #2) > Hi, sorry I don't have time to maintain tlog in EPEL. You are welcome to > take it over if you are able to. If you are referring to the spec file > SUSE/debbuild parts, they can be removed - I was trying to keep a unified > spec file with the upstream git repo. > > -Justin I'm interested! But I'm too quite busy at the moment. But I put it on my longlist of todos. I'll notify you when a review of the package is needed. Basically all I will have to do is. * Fix the changelog order * Remove the SUSE/debbuild parts to make it better readable and easier to maintain * Apply any modernization of the spec file, if needed
Okay sounds good to me. Thank you.
I found some time to have a look at it. The review request can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1997521
Hi, I still am responsible for maintaining tlog, and will continue to do so. In the BugZilla I only meant that I do not have plans to prepare packages for EPEL specifically. Apologies for the confusion.
Ah okay. Well in any case, the errors have been fixed in the new spec file, so it builds again. I also fixed/updated/improved the following things: - Removed EL6 support - Removed "with systemd" build conditions - Removed debbuild conditions - Removed tmpfilesdir conditions, added systemd-rpm-macros as build requirement - Replacing short command options with the long notation, e.g. -m is now --mode - Removed compatibility marcros, not needed anymore - Cleaned up build dependencies - Replaced ldconfig commands from post and postun Maybe you can update the spec file with my version? As far as I know, in order to maintain an EPEL version of a package, I also need to be a (co-)owner of the package. Because an EPEL branch needs to be created and then a build has to be submitted and pushed for that branch. Let me know how you want to proceed. It would be cool to at least use the changes I prepared, because the old version of the spec file contained some old stuff and minor errors. I'm also okay to be a co-owner and work on the EPEL stuff.
Hi, if possible I would like to merge spec file changes upstream to make a single working spec file that requires only minor distro-specific changes (if any) in downstream packaging for RHEL, etc. The debbuild and SUSE are useful for other distro packagers therefore I would prefer to leave them, and try to make a working spec file for RHEL/Fedora/debian/etc. If the distro specific code becomes too much, then we can create different spec files upstream. It sounds like you have made some useful improvements however, so would you mind submitting a PR upstream https://github.com/Scribery/tlog/blob/master/tlog.spec with these changes? Thanks.
(In reply to jstephen from comment #8) > Hi, if possible I would like to merge spec file changes upstream to make a > single working spec file that requires only minor distro-specific changes > (if any) in downstream packaging for RHEL, etc. The debbuild and SUSE are > useful for other distro packagers therefore I would prefer to leave them, > and try to make a working spec file for RHEL/Fedora/debian/etc. If the > distro specific code becomes too much, then we can create different spec > files upstream. > > It sounds like you have made some useful improvements however, so would you > mind submitting a PR upstream > https://github.com/Scribery/tlog/blob/master/tlog.spec with these changes? > Thanks. I can do a PR request this week, been a bit busy. But I understand that I can do a pull request for the spec file I created, without the debbuild and SUSE parts, right?
(In reply to Kees de Jong from comment #9) > (In reply to jstephen from comment #8) > > Hi, if possible I would like to merge spec file changes upstream to make a > > single working spec file that requires only minor distro-specific changes > > (if any) in downstream packaging for RHEL, etc. The debbuild and SUSE are > > useful for other distro packagers therefore I would prefer to leave them, > > and try to make a working spec file for RHEL/Fedora/debian/etc. If the > > distro specific code becomes too much, then we can create different spec > > files upstream. > > > > It sounds like you have made some useful improvements however, so would you > > mind submitting a PR upstream > > https://github.com/Scribery/tlog/blob/master/tlog.spec with these changes? > > Thanks. > > I can do a PR request this week, been a bit busy. But I understand that I Thank you, sorry I provided the wrong link in my previous comment, here is the PR github link https://github.com/Scribery/tlog/pulls > can do a pull request for the spec file I created, without the debbuild and > SUSE parts, right? What is the issue with these lines in the spec file? It would be nice to keep these lines in the spec file to simplify work for packagers of non-Red Hat based distros. I would also prefer to keep the RHEL6 conditional lines, as we had a user report they were building tlog for RHEL6 with our spec file (without journal support of course).
> What is the issue with these lines in the spec file? Not a huge issue, I like a one size fits all solution. But I have no idea about the package requirements for SUSE and Debian-based systems. So in that case I personally would prefer to keep things simple and thus separate spec files. Fedora + EPEL is for me doable enough to support. But I'm not eager to support such a broad range of distros popperly. That would require a lot more reading and keeping up with guidelines and rules.
(In reply to Kees de Jong from comment #11) > > What is the issue with these lines in the spec file? > > Not a huge issue, I like a one size fits all solution. But I have no idea > about the package requirements for SUSE and Debian-based systems. So in that > case I personally would prefer to keep things simple and thus separate spec > files. Fedora + EPEL is for me doable enough to support. But I'm not eager > to support such a broad range of distros popperly. That would require a lot > more reading and keeping up with guidelines and rules. For now i'd like to leave as is, we will rely on SUSE/Debian packagers to submit PRs to fix issue that arise on their end. Tlog is not changing frequently, so leaving these lines in the spec file should not be an issue. If you would like to submit a PR upstream for the other spec file changes not related to SUSE/debbuild then please go ahead.
Sounds good. I'll aim for next week to squeeze in some time to merge the Fedora/RHEL specific changes into the upstream spec file. That way those 2 will be modern. The other distro specifics I'll leave for other people more knowledgeable in that.
Great, thank you for your contributions