Hello, Am Donnerstag, 29. Juni 2017, 11:31:32 CEST schrieb Theo Chatzimichos: ...

I took a look, in general they are fine and production ready imho.

:-)

I took the following notes, but they are mostly minor:

elasticsearch - why not linkpac from security:logging:elma, take changes from :devel, andrew and his and send them all as SR to security:logging:elma

The SR to security:logging:elma probably makes sense - I'll do that in the next days. Do I need to follow the link chain (which would mean to ask Andrew to do the SR), or can I send the SR directly to security:logging:elma without breaking the linked packages in between?

- why it has old distro / non-systemd support? - why is the Source1 URL commented out? - what is %setup -a1? - what is %build true? maybe just remove the "true"? - getent group || groupadd - on package removal, user and group should be preserved - instead of systemctl reload, it should do the same %service_*_* as it did for the main package

Let me try a summary answer ;-) I took the package from Andrew's home repo because it was clearly the best updated I could get. I only did a minor version update which means I only touched the version number in the spec. For everything else, please blame the previous packagers ;-) As already mentioned elsewhere, elasticsearch 1.x is EOL (but MediaWiki 1.27.x unfortunately still requires this version), so I'd prefer not to waste time on this package ;-) For newer elasticsearch versions, there are already separate packages, so improvements in the 1.x package won't improve the newer packages automatically. That said - if you still think I should spend time on this package and/ or answer your comments in detail, please tell me ;-)

mediawiki-1_27 - instead of linkpac to home:cboltz:infra, I would suggest to remove the _link and osc branch openSUSE:infrastructure:wiki/$pkg

Indeed, that makes sense. I just did osc detachbranch all packages (and made the packages in home:cboltz:infra links instead). If the elasticsearch SR gets accepted, we can in theory linkpac elasticsearch to security:... - but since there won't be any new 1.x releases, that won't be really useful.

- remove the commented out Requires and Conflicts

I assume you are talking about the mediawiki_1_27 package here. The commented out Requires and Conflicts basically mean differences to the package in server:php:applications (which I used as a base, but it was too different from my needs to just use it). (Actually, thanks for the reminder - I had to add a few missing dependencies which I should send to the package in server:php:applications) The ImageMagick dependency depends on the MediaWiki config - for historical reasons, the openSUSE wiki doesn't use ImageMagick. php-gettext really seems to be superfluous, so I'll remove that. For the versioned vs. unversioned php5 conflict - that's also something I'll remove.

- mediawiki gets installed in /usr/share/mediawiki-1_27, how are you handling it in production? copying it somewhere or using it from there directly?

Does salt/profile/wiki/docroot.sls answer your question? ;-) TL;DR: the document root is in /srv/www/$wiki/public/, and I let salt create symlinks to /usr/share/mediawiki_1_27/ there. Regards, Christian Boltz -- Linux just isn't user-friendly when it comes to viruses. You have to work to find and run them. It doesn't happen automatically as it does with Windows. The GNU/Linux folks really should improve this glaring discrepancy. [http://os.newsforge.com/article.pl?sid=05/01/25/1430222&from=rss] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org

Hello, Am Donnerstag, 29. Juni 2017, 14:48:07 CEST schrieb Theo Chatzimichos:

On Thu, Jun 29, 2017 at 02:39:56PM +0200, Christian Boltz wrote:

...

The SR to security:logging:elma probably makes sense - I'll do that in the next days.

Do I need to follow the link chain (which would mean to ask Andrew to do the SR), or can I send the SR directly to security:logging:elma without breaking the linked packages in between?

Do it directly, we couldn't care less about andrew's fork or about the :devel repo

I'll quote you if someone complains ;-) Nevertheless, following the link chain basically means to add a "please forward this" note which is not really hard, so I'll simply do that now. If it takes too long, I can still use the direct way ;-)

...

Let me try a summary answer ;-) ... That said - if you still think I should spend time on this package and/ or answer your comments in detail, please tell me ;-)

At least the useradd/groupadd commands should be fixed, as removing

I assume you meant userdel/groupdel here ;-)

the user is a security issue. Imagine the case where the user gets removed, and there are still files owned by that user. A new user takes over this userid and owns those files now.

Good point -> SR 507546 BTW: you asked about "%setup -a1". It's one of the lesser known options of the %setup macro ;-) from http://ftp.rpm.org/max-rpm/s1-rpm-specref-macros.html The -a option is used to direct %setup to unpack the source archive specified on the nth Source: tag line after changing directory into the build directory.

...

The commented out Requires and Conflicts basically mean differences to the package in server:php:applications (which I used as a base, but it was too different from my needs to just use it).

You still don't need comments, osc rdiff can provide you this.

I know about osc rdiff, but it shows much more than this ;-) Regards, Christian Boltz -- Versuchst du mal bitte zu formulieren, was du eigentlich möchtest? Mit diesem Posting hast du gute Chancen auf den "Marcel Stein Award". [Christian Paul in suse-linux] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org