Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes required for RPM Build #59

Closed
mbhangui opened this issue Aug 11, 2019 · 41 comments

Comments

@mbhangui
Copy link
Contributor

commented Aug 11, 2019

So I spent some time setting up opensuse build service (obs) for notqmail. The RPM builds are available at

https://software.opensuse.org//download.html?project=home%3Anotqmail&package=notqmail

This is work in progress and I still have to start creating the necessary files needed for debian builds (rules, changelog, notqmail.dsc, etc).

The good thing is that notqmail will build on all the known linux distros. So far notqmail was found to build successfully on the following distros
centos7, centos6, rhel7, rhel6, FC30, opensuse Tumbleweed, opensuse leap 15.1, opensuse leap 15.0, suse linux enterprise 15 (& SP1), suse linux enterprise 12 (sp1, sp2, sp3, sp4)

To build binary packages, following are the issues (all suppressed by creating rpmlintrc file) and by modifying instchown.c,

  • non fhs compliance
  • instchown needs the same destdir changes as was done in instpackage.c. I will raise a separate pull request for all changes after I complete the debian build
  • all calls to chown to be skipped when instchown is run with non-root uid. This is because rpm and debian builds is built using non-privileged user
  • The license file COPYRIGHT is termed as illegal for suse builds. Somehow opensuse wants a known license like GPLv3, BSD, etc. So I have to figure out this license problem
  • creating a systemd unit file to start qmail-send. I have modified hier.c to install notqmail.service in /var/qmail/boot
  • The binary builds shouldn't be shipping /var/qmail/queue. It should be created during rpm/debian installation. This will require modification to hier.c and a seperate binary like queue-fix (e.g. /var/qmail/bin/queue-fix /var/qmail/queue) which will create the queue when invoked.
@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 11, 2019

The url for the notqmail package on obs is at
https://build.opensuse.org/package/show/home:notqmail/notqmail

@DerDakon

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2019

Running instchown in this sort of package builds isn't actually required, one could instead specify the needed users/groups in the rpm file. When you are not root don't call it.

The instchown DESTDIR thing IMHO also belongs into 1.07 as that is most of the purpose of exactly that change.

The systemd service file can just be copied in the spec file, no need to touch hier.c for this.

What is wrong with the queue in rpm?

@DerDakon

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2019

Does this work:

License: Public Domain
@schmonz

This comment has been minimized.

Copy link
Collaborator

commented Aug 11, 2019

+1 to providing a separate queue-create-and-fix program that can be avoided at build time and invoked at package-install time. I worked around this in pkgsrc by calling instpackage twice: once with DESTDIR to stage and package (and pkgsrc omits the queue from the package since it’s outside PREFIX), and a second time at package-install, ignoring errors, just before calling instchown on the installed files.

Can you say more about why instchown needs DESTDIR support? I didn’t need it for pkgsrc, so I’m wondering what’s different in other systems.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 12, 2019

Running instchown in this sort of package builds isn't actually required, one could instead specify the needed users/groups in the rpm file. When you are not root don't call it.

Good idea. Yes. We can modify the Makefile and skip calling instchown when the user is not root.

The instchown DESTDIR thing IMHO also belongs into 1.07 as that is most of the purpose of exactly that change.

Yes. The RPM build fails without the changes.

The systemd service file can just be copied in the spec file, no need to touch hier.c for this.

That was my original plan. But on second thoughts I thought all startup related files belong in /var/qmail/boot. Also systemd is so ubiquitous now. We need to add it in the documentation somewere on how to start qmail-send, svscan, etc using systemd. I will put it as part of the spec/rules file with few echo statements.

What is wrong with the queue in rpm?

The timestamp of the directories and files in the queue directories keep on changing. If these directory/files, belonging to /var filesystem are part of the RPM package, it creates a problem when we do rpm --verify notqmail. All of these show as having been modified, indicating changes made to the RPM package.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 12, 2019

Can you say more about why instchown needs DESTDIR support? I didn’t need it for pkgsrc, so I’m wondering what’s different in other systems.

@schmonz without the DESTDIR support, while building the RPM, instchown tries to create directories in /var/qmail, which fails because rpmbuild is running with a non-privileged userid.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 12, 2019

Does this work:

License: Public Domain

It failed.
[ 36s] notqmail.src: E: invalid-license (Badness: 100000) Public Domain
[ 36s] notqmail.x86_64: E: invalid-license (Badness: 100000) Public Domain
[ 36s] The specified license string is not recognized. Please refer to
[ 36s] https://spdx.org/licenses/ for the list of known licenses and their exact
[ 36s] spelling.

The full list of acceptable license is here
https://spdx.org/licenses/

The one that comes closest to Public Domain is this
https://spdx.org/licenses/CC-PDDC.html#licenseText

@schmonz

This comment has been minimized.

Copy link
Collaborator

commented Aug 12, 2019

Can you say more about why instchown needs DESTDIR support? I didn’t need it for pkgsrc, so I’m wondering what’s different in other systems.

@schmonz without the DESTDIR support, while building the RPM, instchown tries to create directories in /var/qmail, which fails because rpmbuild is running with a non-privileged userid.

Okay, that helps me ask a more precise question: why does instchown need to run while building the RPM? I would expect installing the RPM package to

  1. Install a bunch of programs, docs, etc.
  2. Install instchown as one of them (e.g., pkgsrc will install it to PREFIX/share/qmail/setup/instchown)
  3. Post-install, run instchown and instcheck

Here's the notqmail-ready version of my install script for pkgsrc.

Another question, are you using instpackage (possibly via the new "package" Makefile target) when building the RPM?

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 12, 2019

Can you say more about why instchown needs DESTDIR support? I didn’t need it for pkgsrc, so I’m wondering what’s different in other systems.

@schmonz without the DESTDIR support, while building the RPM, instchown tries to create directories in /var/qmail, which fails because rpmbuild is running with a non-privileged userid.

Okay, that helps me ask a more precise question: why does instchown need to run while building the RPM? I would expect installing the RPM package to

  1. Install a bunch of programs, docs, etc.
  2. Install instchown as one of them (e.g., pkgsrc will install it to PREFIX/share/qmail/setup/instchown)
  3. Post-install, run instchown and instcheck

Ok. This is what i will do

  1. do not run make setup in the RPM build
  2. Call instpackage to install the packages

Do the following in postinst

  1. Create the queue
  2. run instcheck

Here's the notqmail-ready version of my install script for pkgsrc.

I see that you are also running config-fast. That would complete the notqmail setup for binary installations. I will follow your steps.

Another question, are you using instpackage (possibly via the new "package" Makefile target) when building the RPM?

Yes. It gets called because I do a make setup to install the binaries in BUILD_ROOT/var/qmail

@schmonz

This comment has been minimized.

Copy link
Collaborator

commented Aug 12, 2019

Another question, are you using instpackage (possibly via the new "package" Makefile target) when building the RPM?

Yes. It gets called because I do a make setup to install the binaries in BUILD_ROOT/var/qmail

Aha! If my mental model of building packages applies to the RPM world, setup is too big a target to call. Instead, call package, which does the subset of setup that doesn't require any qmail users or root access.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 12, 2019

Aha! If my mental model of building packages applies to the RPM world, setup is too big a target to call. Instead, call package, which does the subset of setup that doesn't require any qmail users or root access.

It is the same here. That's why I skip all calls to chown (because non of the users exist on the machine where RPM is being built). The user/group creation is done in postinst

/usr/bin/getent group nofiles > /dev/null || /usr/sbin/groupadd nofiles || true
/usr/bin/getent group qmail > /dev/null || /usr/sbin/groupadd qmail || true

/usr/bin/getent passwd alias > /dev/null || /usr/sbin/useradd -M -g nofiles -d %{qmaildir}/alias -s /sbin/nologin alias || true
/usr/bin/getent passwd qmaild > /dev/null || /usr/sbin/useradd -M -g nofiles -d %{qmaildir} -s /sbin/nologin qmaild || true
/usr/bin/getent passwd qmaill > /dev/null || /usr/sbin/useradd -M -g nofiles -d %{logdir} -s /sbin/nologin qmaill || true
/usr/bin/getent passwd qmailp > /dev/null || /usr/sbin/useradd -M -g nofiles -d %{qmaildir} -s /sbin/nologin qmailp || true
/usr/bin/getent passwd qmailq > /dev/null || /usr/sbin/useradd -M -g qmail -d %{qmaildir} -s /sbin/nologin qmailq || true
/usr/bin/getent passwd qmailr > /dev/null || /usr/sbin/useradd -M -g qmail -d %{qmaildir} -s /sbin/nologin qmailr || true
/usr/bin/getent passwd qmails > /dev/null || /usr/sbin/useradd -M -g qmail -d %{qmaildir} -s /sbin/nologin qmails || true

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 12, 2019

The build has been created successfully without modifying instchown or any file in the distribution. Thank you @schmonz and @DerDakon

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 12, 2019

The debian builds have got completed successfully. I installed one of them (debian 7) and it worked. Now I still have few things left on the plate

  1. The installation doesn't call /usr/sbin/alternatives to install notqmail as an alternative mta. There are few things required to make it so. e.g. man page for sendmail. services for smtp, pop3, etc which will require ucspi-tcp. So for the time being I have shelved this task.

  2. For the debian builds, the permissions of the binaries were all default. So I had to modify the build to copy instchown to /var/qmail/bin and run that in postinst script. Maybe /var/qmail/bin isn't the right place for instchown as it shouldn't be something that the user will execute it often. Perhaps /var/qmail/sbin

  3. There is no point in have /var/qmail/man/man3. I have removed this in the debian build. WIll modify the rpm spec file to remove this for the RPM builds too

  4. The email id for maintainer, I have used mine temporarily. We should decide on some standards, some of which @alanpost has discussed in his email about IRC bot notifications. OBS build failures can also be sent to an email id.

  5. I have to complete few things for the binary builds - namely running config-fast, etc and create few default qmail control files, just like what @schmonz demonstrated above in his pkgsrc. I plan to complete those this week.

  6. There should be a directory for out-of-tree builds where we can put miscellaneous items like the RPM spec file, rules file so that they come under git verison control. Refer to #26

  7. I have to test the binary installation. Once that is complete, I will create a dockerfile on github, which can automatically create docker builds for all the linux distros configured in OBS. Creating the dockerfile is trivial. An example of a dockerfile (which I use for indimail) is pasted below. It will require little changes to adapt it for notqmail.

From ubuntu:xenial
MAINTAINER cprogrammer

\# Freshen RUN apt-get -y update
RUN export HOSTNAME=indimail.org DEBIAN_FRONTEND=noninteractive \
    && mkdir -p /root \
    && apt-get -y update \
    && apt-get install -y wget gnupg2 \
    && wget -nv https://download.opensuse.org/repositories/home:mbhangui/Debian_9.0/Release.key -O - | apt-key add - \
    && echo 'deb http://download.opensuse.org/repositories/home:/mbhangui/xUbuntu_17.04/ /' > /etc/apt/sources.list.d/indimail.list \
    && apt-get -y update \
    && apt-get -y install \
        debianutils \
        less \
        man-db \
        net-tools \
        openssh-server \
        openssl \
        procps \
        systemd \
        systemd-sysv \
        telnet \
        strace \
        lsof
        vim \
    && apt-get -y install mrtg indimail \
    && /usr/sbin/svctool --config=cert --postmaster=postmaster@indimail.org --common_name=indimail.org >/dev/null \
    && echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config \
    && unset HOSTNAME
COPY .alias .bash_profile .bashrc .exrc .gfuncs .glogout .indent.pro .vimrc /root/
@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 12, 2019

BTW the debian builds include ubuntu. Also I can turn on the builds for ARM architecture on OBS. But I doubt if anyone will be looking forward to have notqmail on raspberrypi and clones. I use daemontools, ucspi-tcp, qmail built on obs for my very low jitter music mpd player based on volumio/dietpi https://www.allo.com/sparky/piano-dac-2-1.html

@mbhangui mbhangui self-assigned this Aug 12, 2019
@mbhangui mbhangui added the packaging label Aug 12, 2019
@mbhangui mbhangui added this to the 1.08 milestone Aug 12, 2019
@DerDakon

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2019

I have modified the RPM build (log here:

  • split man and doc into notqmail-doc
  • put manpages and documentation in standard directories
  • delete catman
  • have service file as file source and install it to proper unit directory
@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

The RPM build for few of the RPM distros failed for lack of sysuser-tools. I will link notqmail with an existing project on obs for sysuser-tools package. That will take care of the build.

@DerDakon The debian/ubunto distros come with sysuser-tools. I linked sysuser-tools project from openSUSE:Factory to home:notqmail, but the build for sysuser-tools failed on most of the RPM distros (except for FC30). So we will have to try a different approach to create the qmail users. Maybe #if defined statments to use the usual useradd command where the sysuser-tools are missing.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

@DerDakon Looks like Fedora, CentOS & RHEL, using useradd in the spec file scripts is the only way to package the users. I will do reading on packaging guidlines for suse distributions (on tumbleweed they do have sysuser-tools. So it looks like suse will also add this package in the future).
https://fedoraproject.org/wiki/Packaging:UsersAndGroups

Edit: Same goes for suse distributions. They have pwdutils instead of shadow-utils
https://en.opensuse.org/Packaging/Users_And_Groups

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

The builds have got completed successfuly for all the distros. I had to put conditional inclusion of sysuser-tools

%if 0%{?fedora_version} || 0%{?centos_version} || 0%{?rhel_version}
Requires(pre): shadow-utils
Requires(postun): shadow-utils
%endif
%if 0%{?suse_version} || 0%{?sles_version}
Requires(pre): pwdutils
Requires(postun): pwdutils
%endif
%if %{undefined fedora_version} && %{undefined centos_version} && %{undefined rhel_version} && %{undefined sles_version} && %{undefined suse_version}
BuildRequires: sysuser-tools
%endif
%if 0%{?suse_version} >= 1500 || 0%{?sles_version} >= 15
BuildRequires: sysuser-tools
%endif
@DerDakon

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

Thanks for caring about this. This was what I was about to do, but I was too tired and went to bed instead.

@DerDakon

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

I was able to install the openSUSE 15.0 rpm and actually start the qmail-send daemon now.

I broke much of it when I moved the documentation around, this leads to instchown failing early because it can't touch it. I added a patch for that in the meantime.

Another problem is that when I update from one build to another the user accounts are deleted, so the runtime user lookup code fails hard. I have only solved this by hard-uninstalling (to ignore the system dependencies to smtp_daemon) the rpm and then just installing it again.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

I was able to install the openSUSE 15.0 rpm and actually start the qmail-send daemon now.

Great

Another problem is that when I update from one build to another the user accounts are deleted, so the runtime user lookup code fails hard. I have only solved this by hard-uninstalling (to ignore the system dependencies to smtp_daemon) the rpm and then just installing it again.

I will fix the deletion of user accounts on upgrade. This could be because, the postun script should exit when doing upgrade.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

Another problem is that when I update from one build to another the user accounts are deleted, so the runtime user lookup code fails hard. I have only solved this by hard-uninstalling (to ignore the system dependencies to smtp_daemon) the rpm and then just installing it again.

I just realized that there is no need for instchown for RPM builds. RPM spec has the permissions for each and every file. As long as the user accounts are created in the %pre scriptlet, the permissions will be correct. inschown is needed only for the debian builds. I will remove the call to instchown in the spec file. This is one of the reaons I find RPM packaging superior to the debian way of doing things. Just one file to mess around with. For my first debian build, it had taken enormous effort to create a successful build.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

I have just updated the spec file with the changes. Let me know if the new build upgrades successfully

Edit: I missed out skipping service deletion in %preun for upgrades. Added that just now and issued a new build

@DerDakon

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

The problem with the users getting deleted on update is still existent in revision 50.

@DerDakon

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

Also instchown is still installed (which is good atm) as the queue is created with wrong permissions on sendmutex and friends, so qmail-start would fail.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

The problem with the users getting deleted on update is still existent in revision 50.

That could be because the postun of the previous package got called. The postun of the previous package didn't have the following lines. The current package that you have will have the below lines and hence when you do the next upgrade, the users shouldn't get deleted

# we are doing upgrade
if [ $argv1 -eq 1 ] ; then
exit 0
fi

value of arguments passed to sciptlets
#            install   erase   upgrade  reinstall
# pretrans      0        -         0
# pre           1        -         2         2
# post          1        -         2         2
# preun         -        0         1         -
# postun        -        0         1         -
# posttrans     0        -         0
# The scriptlets in %%pre and %post are respectively run before and after a package is installed.
# The scriptlets %%preun and %postun are run before and after a package is uninstalled.
# The scriptlets %%pretrans and %posttrans are run at start and end of a transaction.
# On upgrade, the scripts are run in the following order:
#
#   1. pretrans of new package
#   2. pre of new package
#   3. (package install)
#   4. post of new package
#   5. preun of old package
#   6. (removal of old package)
#   7. postun of old package
#   8. posttrans of new package
@DerDakon

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

You are right, reinstalling the same package again leaves the users in place.

@DerDakon

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

I fixed basically all permissions, my check is at the moment:

rpm -q --verify notqmail
/var/qmail/bin/instchown
rpm -q --verify notqmail

Since that works fine now I have entirely dropped instchown from the rpms.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

lovely.
I was about to put the permisions for each of the directories and files in the spec file. But I see it is no longer needed

%dir %attr(0750,qmailq,qmail) /var/qmail/queue
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/todo
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/15
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/0
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/2
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/9
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/13
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/14
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/4
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/22
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/10
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/17
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/18
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/6
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/19
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/1
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/8
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/5
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/12
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/7
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/11
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/21
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/16
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/3
%dir %attr(0700,qmails,qmail) /var/qmail/queue/info/20
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/15
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/0
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/2
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/9
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/13
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/14
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/4
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/22
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/10
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/17
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/18
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/6
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/19
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/1
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/8
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/5
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/12
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/7
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/11
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/21
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/16
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/3
%dir %attr(0700,qmails,qmail) /var/qmail/queue/remote/20
%dir %attr(0700,qmails,qmail) /var/qmail/queue/bounce
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/15
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/0
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/2
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/9
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/13
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/14
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/4
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/22
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/10
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/17
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/18
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/6
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/19
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/1
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/8
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/5
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/12
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/7
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/11
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/21
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/16
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/3
%dir %attr(0700,qmails,qmail) /var/qmail/queue/local/20
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/lock
%attr(0600,qmails,qmail) /var/qmail/queue/lock/sendmutex
%attr(0622,qmails,qmail) /var/qmail/queue/lock/trigger
%attr(0644,qmailr,qmail) /var/qmail/queue/lock/tcpto
%dir %attr(0700,qmailq,qmail) /var/qmail/queue/intd
%dir %attr(0700,qmailq,qmail) /var/qmail/queue/pid
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/15
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/0
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/2
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/9
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/13
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/14
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/4
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/22
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/10
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/17
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/18
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/6
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/19
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/1
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/8
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/5
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/12
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/7
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/11
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/21
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/16
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/3
%dir %attr(0750,qmailq,qmail) /var/qmail/queue/mess/20
@alanpost

This comment has been minimized.

Copy link
Member

commented Aug 14, 2019

@mbhangu,

In the notqmail.spec file, there are a couple references to notqmail URLs: see_base and the URL field. Will you modify both of these, along with other places we have a URL, to be https://notqmail.org/ ?

That location is a temporary redirect to the URLs as you have them, but it's temporary: it might change in the future whereas our domain will not.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 14, 2019

In the notqmail.spec file, there are a couple references to notqmail URLs: see_base and the URL field. Will you modify both of these, along with other places we have a URL, to be https://notqmail.org/ ?

Done

@alanpost

This comment has been minimized.

Copy link
Member

commented Aug 14, 2019

@mbhangui,

Awesome, thank you. I'll get myself signed up to that service as soon as I'm able--I appreciate your being attentive here where I can leave comments until I do so.

I'm not sure that https://notqmail.org/wiki works, probably the /wiki slug should be / like this, instead:

https://notqmail.org/

We could certainly cause /wiki to work, however, if that is the superior option.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 14, 2019

@alanpost if you have a opensuse id, i will add that id to the list of collaborators for notqmail.

@alanpost

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

@mbhangui, I have created an account on build.opensuse.org. alynpost. Note the 'y', which differs from my account name here in GitHub. Thank you for adding me to the notqmail project.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 20, 2019

Fixed debian builds by modifying notqmail.dsc with the proper tar file name notqmail-1.07.tar.xz instead of notqmail-1.07.tar.gz

@DerDakon

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2019

Thanks, I broke it but was too tired to fix it. Thanks for cleaning up after me.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 22, 2019

Closing this because the build was accomplished without changing any existing code.

@mbhangui mbhangui closed this Aug 22, 2019
@alanpost

This comment has been minimized.

Copy link
Member

commented Aug 22, 2019

I would like to pull all the (relevant) files from build.opensuse.org in to the codebase, bringing in-tree deb and rpm build rules for notqmail. I'd be happy to have a PR for that work--a separate PR for each package type.

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 22, 2019

I would like to pull all the (relevant) files from build.opensuse.org in to the codebase, bringing in-tree deb and rpm build rules for notqmail. I'd be happy to have a PR for that work--a separate PR for each package type.

There is a way where obs can pull the files from github using a file named _service. Something like this (the below is just an example and I will change the url and filenames).

<services>
  <service name="download_url">
    <param name="host">downloads.sourceforge.net</param>
    <param name="protocol">http</param>
    <param name="path">/indimail/libdkim-1.5.tar.gz</param>
  </service>
  <service name="download_url">
    <param name="host">downloads.sourceforge.net</param>
    <param name="protocol">http</param>
    <param name="path">/indimail/libsrs2-1.0.18.tar.gz</param>
  </service>
  <service name="download_url">
    <param name="host">downloads.sourceforge.net</param>
    <param name="protocol">http</param>
    <param name="path">/indimail/Patches-2.0/ucspi-tcp-0.88.patch.gz</param>
  </service>
</services>

The question I have for @alanpost , @DerDakon , @schmonz is the following

  1. Do I create a new repository named obs with all the files under netqmail?

or

  1. Do I create a new subdirectory named obs with all the files under netqmail?
@alanpost

This comment has been minimized.

Copy link
Member

commented Aug 22, 2019

  1. Do I create a new repository named obs with all the files under netqmail?

or

  1. Do I create a new subdirectory named obs with all the files under netqmail?

No need for a separate repository, you can create a directory or the appropriate files in notqmail.git.

  1. We have vendor/third-party configuration in-tree, as of the 1.07 release (a .gitignore for git and a .travis.yml for TravisCI), so the tree already has these sorts of integrations.
  2. The Debian/deb package system requires it's files be in the debian/ directory, and I expect other packaging tools are or can be similar. Creating directories for packaging in therefor already a requirement.

If we have a choice, I'd rather a longer name than obs--spelling out the vendor/third-party rather than abbreviating it, and if it's only a single file or so (I'm unclear on that part) just put it in the root of the repository.

Did that answer your question?

@mbhangui

This comment has been minimized.

Copy link
Contributor Author

commented Aug 22, 2019

No need for a separate repository, you can create a directory or the appropriate files in notqmail.git.

  1. We have vendor/third-party configuration in-tree, as of the 1.07 release (a .gitignore for git and a .travis.yml for TravisCI), so the tree already has these sorts of integrations.
  2. The Debian/deb package system requires it's files be in the debian/ directory, and I expect other packaging tools are or can be similar. Creating directories for packaging in therefor already a requirement.

If we have a choice, I'd rather a longer name than obs--spelling out the vendor/third-party rather than abbreviating it, and if it's only a single file or so (I'm unclear on that part) just put it in the root of the repository.

Did that answer your question?

It answers my question. But it will be multiple files (just the spec file & rpmlintrc for .rpm and multiple files in debian subdirectory for .deb). Let me think of a name for a directory which will represent openSUSE build service.

The files in the debian subdirectory will be the following
changelog
compat
control
copyright
notqmail.install
postinst
postrm
preinst
prerm
README
rules
source/
source/format

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.