binary builds on openSUSE build service and locally

[mbhangui]

These files have been added for openSUSE build service on https://build.opensuse.org/project/show/home:notqmail

Description of the important files
notqmail.spec - The RPM spec file
notqmail-rpmlintrc - Containing rules to ignore few non-compliance errors (mostly FHS) on obs.
notqmail-permission.* - These files are needed for SUSE Enterprise Linux (AFAIK)
qmail-send.service - systemd unit file to start qmail-send
notqmail.dsc - packages that opensuse build service should pull before doing a notqmail build
debian/rules - The debian rules file
deban/control - debian packaging control file
debian/preinst,postinst, prerm, postrm - debian pre/post installation and deinstallation scripts

[alanpost]

It's certainly fine to use the same PR, but will you separate the debian and redhat packaging in to separate commits?

[alanpost]

The debian/ directory belongs in the root of notqmail.git, not inside the open the opensuse_buildservice directory. That is the location it is expected when you run dpkg-buildpackage and friends locally.

[mbhangui]

The debian/ directory belongs in the root of notqmail.git, not inside the open the opensuse_buildservice directory. That is the location it is expected when you run dpkg-buildpackage and friends locally.

OK. I will move the the spec file and the debian subdirectory to the root.

There are two ways of doing it. One is having debian subdirectory in the netqmail source tar ball and the other is by having a single tar file named debian.tar.gz. If I have the debian directory in the root, one cannot have debian.tar.gz. My plan is to do the following

1. Modify Makefile to create debian.tar.gz in the opensuse_buildservice directory
2. Have a _service file on opensuse build service notqmail directory which will pull notqmail.spec, notqmail.dsc, notqmail-rpmlintr, notqmail-permssion.* files, debian.dsc and debian.tar.gz. obs will then automatically pull all these files when triggerred using the web ui or using the osc command.
3. A way to automatically trigger the build when anything is updated (just like travis). I am yet to figure this out.
4. A script to automatically create the changelog from the CHANGES file.

Let me think of a way where both can be achieved and I will reorganize the files accordingly

1. Building the RPM or debian locally so that any user can build the packages locally by just executing the commands rpmbuild or dpkg-buildpackage
   and
2. Building the RPM and debian packages on the obs

[schmonz]

Bump, @mbhangui and others. How can we help get this done and merged for 1.08?

[mbhangui]

Bump, @mbhangui and others. How can we help get this done and merged for 1.08?
I just need to upload the latest tar.gz and do the build. I will do this tomorrow

[DerDakon]

Maybe just wait until 1.08 is out, the build is done and we are satisfied with it, and then merge it. I would like to avoid that we have a bunch of 1.07.9999 build with patches or weird tarballs and all that. YMMV.

[DerDakon]

I took the opportunity to rebase this on current master, adapt to some 1.08 changes, and add a second optional commit that drops some things that we want to remove in 1.09 even from the 1.08 packages.

[DerDakon]

I upgraded one of my servers using this RPM this morning and everything went fine. Some thoughts:

-is it the default to enable a newly installed service?
-what happens if a user like me overrides the service by placing a modified copy in /etc/systemd, should we disable this on package removal?
-/var/qmail/queue/lock/tcpto will show as modified when using "rpm --verify notqmail" because it is modified by the running services. Is there a way that we can mark it as "this file will be modified"? Mark as configuration file?

[mbhangui]

-is it the default to enable a newly installed service?
Yes it is the default with almost all standard daemons (atleast on Fedora & CentOS). I have once in a while tried out Ubuntu and Debian. There too, these services get installed for startup by default. A good example is MySQL.

-what happens if a user like me overrides the service by placing a modified copy in /etc/systemd, should we disable this on package removal?

I don't have a definite answer to this. But in postinst, most packages do

systemctl disable servicename

-/var/qmail/queue/lock/tcpto will show as modified when using "rpm --verify notqmail" because it is modified by the running services. Is there a way that we can mark it as "this file will be modified"? Mark as configuration file?

I had this issue in indimail-mta. So what I did was

1. have /var/indimail/queue in the spec file
2. create the queue during postinstall of the package
3. Files which can be created later but actuall belong to the package can be marked as ghost. e.g.

%ghost %config(noreplace,missingok)                %{qsysconfdir}/tcp/tcp.smtp

Today I have built successfully binary builds for all the distros configured in OBS. Added Ubuntu 20.04 and openSUSE leap 15.2. I have done some modifications to the spec file and tested the installation on ubuntu 20.04 and CentOS7. I also tested the delivery. I had to make changes to fix few errors. The errors were all related to installing the systemd unit file.

Meanwhile I have also created docker & podman container images for notqmail. I will create a pull request for the same. The podman/docker images will use the opensuse build service to build the container.

[mbhangui]

Oh I forgot to mention. I have created a _service file for obs. Having such a file enables obs to pull the source archive directly from github

<services>
  <service name="download_url">
    <param
        name="host">github.com</param>
    <param name="protocol">https</param>
    <param name="path">/notqmail/notqmail/releases/download/notqmail-1.08/notqmail-1.08.tar.xz</param>
  </service>
</services>

[mbhangui]

I did some screw up. I pushed one commit which was supposed to be committed in the opensuse_buildservice branch to the docker branch. I don't know how to fix it

[DerDakon]

You can do something like "git checkout docker; git reset --hard HEAD^; git push --force" which would wipe the last commit from that given branch.

[mbhangui]

Yes. That worked

[mbhangui]

@DerDakon can you check the docker pull request. I see older commits that were related to opensuse_buildservice there. I don't understand how those have gone there because the docker pull request is something I just created few minutes back.

I have created the dockerfiles created for ubuntu and centos but don't want to push it till this is cleaned up.

[schmonz]

At a glance, without trying to deeply understand these packaging systems, it is plainly evident how much effort you put into understanding these packaging systems. Thank you for going to the trouble: it will help our users (and especially future users) quite a bit. We see some opportunities to lower the future maintenance cost of this packaging code but mostly no urgency, we can do them at leisure as we continue to live with this integrated packaging automation.