[gentoo-dev] dev-util/jenkins-bin GLEP-81 migration

[gentoo-dev] dev-util/jenkins-bin GLEP-81 migration

[Thomas Deutschmann]

Hi,

please see my first package migration to GLEP 81.

Complete change set can be found at https://github.com/gentoo/gentoo/pull/14121.

Previous ebuilds using user eclass called

  fowners jenkins:jenkins /var/log/jenkins ${JENKINS_DIR} ${JENKINS_DIR}/home ${JENKINS_DIR}/backup

which I changed to

  fowners jenkins:jenkins /var/log/jenkins ${JENKINS_DIR}/home ${JENKINS_DIR}/backup

in assumption that $JENKINS_DIR is now maintained through acct-* package.

I changed chmod for $HOME to 0750 which should be a safer default.

Thanks.

[gentoo-dev] [PATCH 1/4] acct-group/jenkins: Add jenkins group, GID 473

[Thomas Deutschmann]

Package-Manager: Portage-2.3.82, Repoman-2.3.20
Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>
---
 acct-group/jenkins/jenkins-0.ebuild |  9 +++++++++
 acct-group/jenkins/metadata.xml     | 12 ++++++++++++
 2 files changed, 21 insertions(+)
 create mode 100644 acct-group/jenkins/jenkins-0.ebuild
 create mode 100644 acct-group/jenkins/metadata.xml

diff --git a/acct-group/jenkins/jenkins-0.ebuild b/acct-group/jenkins/jenkins-0.ebuild
new file mode 100644
index 00000000000..0786846c589
--- /dev/null
+++ b/acct-group/jenkins/jenkins-0.ebuild
@@ -0,0 +1,9 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-group
+
+DESCRIPTION="Jenkins program group"
+ACCT_GROUP_ID=473
diff --git a/acct-group/jenkins/metadata.xml b/acct-group/jenkins/metadata.xml
new file mode 100644
index 00000000000..de8ce22b371
--- /dev/null
+++ b/acct-group/jenkins/metadata.xml
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
+<pkgmetadata>
+	<maintainer type="person">
+		<email>patrick@gentoo.org</email>
+		<name>Patrick Lauer</name>
+	</maintainer>
+	<maintainer type="person">
+		<email>graaff@gentoo.org</email>
+		<name>Hans de Graaff</name>
+	</maintainer>
+</pkgmetadata>
-- 
2.24.1

[gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

[Thomas Deutschmann]

Package-Manager: Portage-2.3.82, Repoman-2.3.20
Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>
---
 acct-user/jenkins/jenkins-0.ebuild | 13 +++++++++++++
 acct-user/jenkins/metadata.xml     | 12 ++++++++++++
 2 files changed, 25 insertions(+)
 create mode 100644 acct-user/jenkins/jenkins-0.ebuild
 create mode 100644 acct-user/jenkins/metadata.xml

diff --git a/acct-user/jenkins/jenkins-0.ebuild b/acct-user/jenkins/jenkins-0.ebuild
new file mode 100644
index 00000000000..b3f9a003cd6
--- /dev/null
+++ b/acct-user/jenkins/jenkins-0.ebuild
@@ -0,0 +1,13 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="Jenkins program user"
+ACCT_USER_ID=473
+ACCT_USER_HOME=/var/lib/jenkins
+ACCT_USER_HOME_PERMS=0750
+ACCT_USER_GROUPS=( jenkins )
+acct-user_add_deps
diff --git a/acct-user/jenkins/metadata.xml b/acct-user/jenkins/metadata.xml
new file mode 100644
index 00000000000..de8ce22b371
--- /dev/null
+++ b/acct-user/jenkins/metadata.xml
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
+<pkgmetadata>
+	<maintainer type="person">
+		<email>patrick@gentoo.org</email>
+		<name>Patrick Lauer</name>
+	</maintainer>
+	<maintainer type="person">
+		<email>graaff@gentoo.org</email>
+		<name>Hans de Graaff</name>
+	</maintainer>
+</pkgmetadata>
-- 
2.24.1

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

[Michael Orlitzky]

On 12/25/19 10:11 AM, Thomas Deutschmann wrote:
> +ACCT_USER_HOME=/var/lib/jenkins
Needed?

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 885 bytes --]

On 2019-12-26 12:04, Michael Orlitzky wrote:
> On 12/25/19 10:11 AM, Thomas Deutschmann wrote:
>> +ACCT_USER_HOME=/var/lib/jenkins
> Needed?

I cannot answer that for sure. In *my* setups I need a valid home for
standard SSH setup (~/.ssh/authorized_keys). But there are dozen ways
how you can run and use Jenkins...

For myself I am probably not going to use Gentoo's acct-* stuff. While
*I* need valid HOME for jenkins' user to get working SSH setup without
any additional configuration I also store services in
/srv/<server-instance> instead of /var/lib. I am still scared to death
that when I change HOME (usermod) which is part of my Salt state
(configuration management) that acct-* stuff will revert at some point
and break dozen of clusters ;]


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

[Michael Orlitzky]

On 12/26/19 8:28 AM, Thomas Deutschmann wrote:
> On 2019-12-26 12:04, Michael Orlitzky wrote:
>> On 12/25/19 10:11 AM, Thomas Deutschmann wrote:
>>> +ACCT_USER_HOME=/var/lib/jenkins
>> Needed?
> 
> I cannot answer that for sure. In *my* setups I need a valid home for
> standard SSH setup (~/.ssh/authorized_keys). But there are dozen ways
> how you can run and use Jenkins...
> 
> For myself I am probably not going to use Gentoo's acct-* stuff. While
> *I* need valid HOME for jenkins' user to get working SSH setup without
> any additional configuration I also store services in
> /srv/<server-instance> instead of /var/lib. I am still scared to death
> that when I change HOME (usermod) which is part of my Salt state
> (configuration management) that acct-* stuff will revert at some point
> and break dozen of clusters ;]
> 

Unless you override acct-{user,group}/jenkins, you won't really be safe.
Every time the package is installed -- particularly, the first time --
it's going to clobber the existing user's settings. This is true for
everyone using Jenkins in those dozens of different ways.

So before you push this, I would figure out what you want the Jenkins
user to look like on your machine, and add an -r1 of acct-user/jenkins
in a local overlay that configures it how you want. At that point, you
can drop the usermod calls from your configuration management tools.

For the benefit of those other users, it would be extra nice if you
could document how to do all that. I recently had to do the same thing
for OpenDKIM, because the old instructions that were gave were being
wiped out on upgrades and reinstalls:

  https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way

Then if the home directory is only needed by people who are going to be
overriding the acct-user ebuild anyway, you might as well leave
ACCT_USER_HOME at the default and let people set it in their overlays.

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 3209 bytes --]

On 2019-12-26 14:42, Michael Orlitzky wrote:
> So before you push this, I would figure out what you want the Jenkins
> user to look like on your machine, and add an -r1 of acct-user/jenkins
> in a local overlay that configures it how you want. At that point, you
> can drop the usermod calls from your configuration management tools.
> 
> For the benefit of those other users, it would be extra nice if you
> could document how to do all that. I recently had to do the same thing
> for OpenDKIM, because the old instructions that were gave were being
> wiped out on upgrades and reinstalls:
> 
>   https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way
> 
> Then if the home directory is only needed by people who are going to be
> overriding the acct-user ebuild anyway, you might as well leave
> ACCT_USER_HOME at the default and let people set it in their overlays.

Now, after reading the wiki for OpenDKIM I am more concerned than
before: We are also changing groups?!

Let me show you an example:
System has www-servers/nginx installed which created nginx user+group
via user eclass.

Now let's say I have a custom application for which I created user+group
"myapp".

I add nginx user to myapp group to allow nginx to access files from
myapp to serve application.

My current understanding is that during www-servers/nginx migration to
GLEP-81, i.e. when www-servers/nginx ebuild will pull in acct-user/nginx
and acct-group/nginx for the first time, the acct-* thing will do

  local groups=${ACCT_USER_GROUPS[*]}
  esetgroups "${ACCT_USER_NAME}" "${groups// /,}"

which would remove nginx from myapp group to match ACCT_USER_GROUPS set
in acct-*/nginx ebuild which would break my application server. Does
that really happen?

And would I really have to create my own acct-*/nginx user+group ebuild
to mirror my myapp use case? In other words: Thanks to GLEP 81, in
Gentoo, you can no longer use known default Linux utilities like usermod
to maintain your system and make changes to users/groups created by
packages, instead you will always have to 'fork' involved acct-*/<user>
package and adjust for your needs?

Things like

https://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html
https://docs.ansible.com/ansible/latest/modules/user_module.html

which are commonly used to apply configurations can't be used anymore?!

Which will become funny if you are maintaining multiple systems: On one
system you have said "myapp", but on another system you would have a
second application named "myapp2". So you cannot even share repositories
between your systems anymore or would have to ensure somehow that system
A which acts as application server for "myapp" will only get
acct-*/<user>-<numeric-identifier-for-myapp-cfg> and system B which will
act as application server for "myapp2" will get
acct-*/<user>-<numerc-identifier-for-another-myapp2-cfg> instead?! Not
to mention what will happen if you get a third system which will be able
to run multiple nginx instances, one for myapp and one for myapp2... ;]


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

[Michael Orlitzky]

On 12/26/19 9:41 AM, Thomas Deutschmann wrote:
> 
> which would remove nginx from myapp group to match ACCT_USER_GROUPS set
> in acct-*/nginx ebuild which would break my application server. Does
> that really happen?

Yes; if we want to be able to add/remove groups in acct-user ebuilds,
then that's the only possible thing it could do.


> And would I really have to create my own acct-*/nginx user+group ebuild
> to mirror my myapp use case? In other words: Thanks to GLEP 81, in
> Gentoo, you can no longer use known default Linux utilities like usermod
> to maintain your system and make changes to users/groups created by
> packages, instead you will always have to 'fork' involved acct-*/<user>
> package and adjust for your needs?

That's right, but you're making it sound worse than it is. You also
cannot use known default tools like rm, mv, cp, and your text editor to
change things installed by system packages, because those changes will
get overwritten the next time that the package is upgraded or
reinstalled. Now user/group management works the same way.

If you want to change something that belongs to the system, you override
and tweak the package that installs it. It's consistent, and you don't
have to tell people to install puppet/salt/etc. as a special case just
to make users work like everything else. Those were always band-aids for
the lack of a better way to do it.


> 
> Things like
> 
> https://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html
> https://docs.ansible.com/ansible/latest/modules/user_module.html
> 
> which are commonly used to apply configurations can't be used anymore?!

You don't need them any more, there's a better way to do it.


> Which will become funny if you are maintaining multiple systems: On one
> system you have said "myapp", but on another system you would have a
> second application named "myapp2". So you cannot even share repositories
> between your systems anymore or would have to ensure somehow that system
> A which acts as application server for "myapp" will only get
> acct-*/<user>-<numeric-identifier-for-myapp-cfg> and system B which will
> act as application server for "myapp2" will get
> acct-*/<user>-<numerc-identifier-for-another-myapp2-cfg> instead?! Not
> to mention what will happen if you get a third system which will be able
> to run multiple nginx instances, one for myapp and one for myapp2... ;]

I don't completely understand your example, but it doesn't sound like
something that should be particularly hard. Can you elaborate before I
stick my foot in my mouth?

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 4885 bytes --]

Hi,

On 2019-12-26 16:28, Michael Orlitzky wrote:
>> And would I really have to create my own acct-*/nginx user+group
>> ebuild to mirror my myapp use case? In other words: Thanks to GLEP
>> 81, in Gentoo, you can no longer use known default Linux utilities
>> like usermod to maintain your system and make changes to
>> users/groups created by packages, instead you will always have to
>> 'fork' involved acct-*/<user> package and adjust for your needs?
> 
> That's right, but you're making it sound worse than it is. You also 
> cannot use known default tools like rm, mv, cp, and your text editor
> to change things installed by system packages, because those changes
> will get overwritten the next time that the package is upgraded or 
> reinstalled. Now user/group management works the same way.
> 
> If you want to change something that belongs to the system, you
> override and tweak the package that installs it. It's consistent, and
> you don't have to tell people to install puppet/salt/etc. as a
> special case just to make users work like everything else. Those were
> always band-aids for the lack of a better way to do it.

Why can't I use rm, mv, cp or text editor to change things?

System configuration management is abstraction. You don't care about
details like if you are using Debian, RHEL or Gentoo. This is
implemented in used tool. You only define "states":

- Make sure user X is present and member of group Y.

- Make sure directory /var/foo exists and is owned by x:y.

- Make sure service Z is installed.

- Make sure your configuration for service Z is installed.

- Make sure service Z is enabled and running.

*You* don't need to know if you have to use apt, yum or emerge to get Z
installed. This is something the tool (puppet, ansible, salt, chef...)
will know and take care of. You will probably manage a mapping of
package names on your own so that you can always say "Install Z" but on
Debian your configuration management tool will install openssh-server
and on Gentoo it will just be a package named net-misc/openssh.

You can deploy your own configuration (=replace /etc/ssh/sshd_config) or
you can say "Make sure /etc/ssh/sshd_config contains 'PermitRootLogin
without-password'" or that "/etc/php/fpm-php7.4/ext-active/foo.ini" is
absent on Gentoo which will translate to "[[ ! -f
/var/lib/php/modules/7.4/fpm/disabled_by_admin/foo]] && phpdismod -v 7.4
-s fpm foo ]]"
on Debian.


>> Things like
>> 
>> https://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html
>>
>> 
https://docs.ansible.com/ansible/latest/modules/user_module.html
>> 
>> which are commonly used to apply configurations can't be used
>> anymore?!
> 
> You don't need them any more, there's a better way to do it.

Ever deployed a custom Tomcat application for example? Sure, you have
dozen ways to do that. Like dev-util/jenkins-bin, you could create your
own package. But if you have to maintain various operating systems you
will write a role/state, see above. Or if this is your own in-house
application it could be easier that your CI pipline will just copy to
/srv/myapp/$buildid on each application server and to flip
/srv/myapp/current symlink so you can update/rollback in seconds and to
support staggered deployment.

My point is, it's pointless to say there are better ways. Making Gentoo
special because you can't use well established things which are working
on every other distribution and would require that everyone would
rewrite their states/roles and/or implement something new just to keep
Gentoo supported is not going to happen.


> I don't completely understand your example, but it doesn't sound
> like something that should be particularly hard. Can you elaborate
> before I stick my foot in my mouth?

Heh :)

In you example user would have to fork acct-*/<user/group> package in
his/her overlay to adjust for his/her needs. At the moment, all larger
Gentoo setups I am aware of are maintaining a company repository in
addition to the official Gentoo repository. So they would put
acct-user/nginx-0-r1 and acct-group/nginx-0-r1 in that repository with
their changes. But this doesn't work if you have multiple different
nginx instances for example. Sure, the forked acct-* packages would work
for all the application servers running this specific role/state. But
these adjusted packages would be wrong for the servers running grafana
role/state, i.e. running www-apps/grafana-bin behind www-servers/nginx
proxy. So you would end up with multiple acct-*/nginx ebuilds for each
configuration which can't be right. Whereas at the moment you will use
your configuration management tool to get things into describe state.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

[Michael Orlitzky]

On 12/26/19 11:56 AM, Thomas Deutschmann wrote:
> 
> Why can't I use rm, mv, cp or text editor to change things?

If you change a file belonging to a system package, then the next time
you upgrade or reinstall that package, your changes get overwritten.


> System configuration management is abstraction. You don't care about 
> details like if you are using Debian, RHEL or Gentoo... You will
> probably manage a mapping of package names on your own so that you
> can always say "Install Z" but on Debian your configuration
> management tool will install openssh-server and on Gentoo it will
> just be a package named net-misc/openssh.

I get that (I've used these tools), but the abstraction is always leaky.
At some point, you wind up managing the differences between the target
systems yourself, just like with your package-name example. Is the
difference between "emerge acct-user/foo" and "useradd foo" really that
much greater than "emerge openssh" versus "apt-get install openssh-server"?

Presumably your company overlay (mentioned later) is automatically
installed on your Gentoo machines, after which everything is already
abstracted for you and your CM tool doesn't need to do anything special.
If it knows how to install acct-user/nginx in the first place (to
satisfy the "user must exist" requirement), then it knows how to install
your overlay copy of it. Or if it knows to install nginx, then the
package manager will pull in your overlay user as a dependency.


> Ever deployed a custom Tomcat application for example? Sure, you have
> dozen ways to do that. Like dev-util/jenkins-bin, you could create your
> own package. But if you have to maintain various operating systems you
> will write a role/state, see above. Or if this is your own in-house
> application it could be easier that your CI pipline will just copy to
> /srv/myapp/$buildid on each application server and to flip
> /srv/myapp/current symlink so you can update/rollback in seconds and to
> support staggered deployment.
> 
> My point is, it's pointless to say there are better ways. Making Gentoo
> special because you can't use well established things which are working
> on every other distribution and would require that everyone would
> rewrite their states/roles and/or implement something new just to keep
> Gentoo supported is not going to happen.

The old way still works fine, so long as you don't want to modify a user
in ::gentoo. We do run Tomcat applications (against my... everything),
and I still use useradd to create the www.example.com users they run as.
In the future, I'll create acct-user ebuilds for them in our overlay --
I already wrote ebuilds to pull in their java dependencies; might as
well pull in the user accounts, too. That WORKSFORME because we only
have Gentoo servers; but if we didn't, the old way would continue to
work just fine.

You only need to change something when you want to modify a system user.
In the past, you could usermod them and the changes would stick. Now,
you have to override the ebuild in an overlay. But once you override the
acct-user package, you're back where you started and whatever you were
going to do in the first place should work.


> In you example user would have to fork acct-*/<user/group> package in
> his/her overlay to adjust for his/her needs. At the moment, all larger
> Gentoo setups I am aware of are maintaining a company repository in
> addition to the official Gentoo repository. So they would put
> acct-user/nginx-0-r1 and acct-group/nginx-0-r1 in that repository with
> their changes. But this doesn't work if you have multiple different
> nginx instances for example. Sure, the forked acct-* packages would work
> for all the application servers running this specific role/state. But
> these adjusted packages would be wrong for the servers running grafana
> role/state, i.e. running www-apps/grafana-bin behind www-servers/nginx
> proxy. So you would end up with multiple acct-*/nginx ebuilds for each
> configuration which can't be right. Whereas at the moment you will use
> your configuration management tool to get things into describe state.


Ok, I understand now. This is a little more clumsy than I'd like, but is
still doable using standard ebuild tools. In your company overlay,
create a copy of acct-group/nginx, but then add a few USE flags that
control the extra roles. You can then use your configuration management
tool to push out the corresponding setting to /etc/portage/package.use.

It's clumsy because you can't put USE dependencies in ACCT_USER_GROUPS,
but these are just ebuilds after all. You can edit (R)DEPEND yourself to
make it do exactly what you want.

[gentoo-dev] [PATCH 3/4] dev-util/jenkins-bin: bump to v2.204.1

[Thomas Deutschmann]

Package-Manager: Portage-2.3.82, Repoman-2.3.20
Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>
---
 dev-util/jenkins-bin/Manifest                 |  1 +
 .../jenkins-bin/jenkins-bin-2.204.1.ebuild    | 47 +++++++++++++++++++
 2 files changed, 48 insertions(+)
 create mode 100644 dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild

diff --git a/dev-util/jenkins-bin/Manifest b/dev-util/jenkins-bin/Manifest
index 39d97b60d3e..854cbb4f581 100644
--- a/dev-util/jenkins-bin/Manifest
+++ b/dev-util/jenkins-bin/Manifest
@@ -2,4 +2,5 @@ DIST jenkins-bin-2.190.1.war 78245883 BLAKE2B 6c80eaebc6fe34e2c889c78a34dfc3e105
 DIST jenkins-bin-2.190.2.war 78243424 BLAKE2B 7a6bd4cf1c070ce3a09fb84b3dbe7e87f474f4254dd4b4fcffdd7dedf7d4c2ba91d8783e7273214aaaa39bfeb02da721e4d539cba76312c21b523a9bf336a964 SHA512 b1f59ef10dfdfda06bedbf9a40a9e83e159b44b2b5574cba4d62547294386224f64d856490fd4477fb3300a4119d17fc284819719218dfcf32d3dc20ce468847
 DIST jenkins-bin-2.190.3.war 78247363 BLAKE2B 99d4c13236b4b4f7308c7993033d1e5f9dd2fd9926febf52ffdacea595fecaba0d0eb8962761d8a6f983eaf9738f8be1ba4df785bb2fe6b613ac8cadcc618e23 SHA512 4ffa2ce3be4d55f0df8021026115d9ce8f1d0f4faa16eaf9f327ce17105f61731730c2a0124fb9af5d8c16c8fee9200f9b785b23856896e292a19f5404a9d2c2
 DIST jenkins-bin-2.197.war 78309466 BLAKE2B c3d34c6fc40a82148eafa978c8787375ece6522d0d936b42f0296ee13cd084669bfa31975c0ad27816bdd4c1266cb066c0909774199a1373661a7ec524c06e91 SHA512 3b6a00dee5aeb8a94c8f75323c2469b54fe96d90bf8371898e41dc5bdecaa472f112bff1466481c66c9c7a07b22cbe799a08e45ac486d68fd5bdc7c20d43d722
+DIST jenkins-bin-2.204.1.war 63433755 BLAKE2B 53cb254ddf3b59e083b564adf8d5696c61012e6d0d26b622eac7023268d5ba3d43082d07cae5654e032169cd144a5338f2553d4ee39c851c4126fe0be5378f1e SHA512 2ebf1ff7792a2ba80d8cf6f8675864580533b62659346e9ef3334ff988899d735d5d72cb3a89308cd9287bcaa74c42306cbf80a716d03658ad748688f94f394b
 DIST jenkins-bin-2.205.war 62738246 BLAKE2B de350469e3a6e0d93f6d05c38f7669ce630f01a0284db83a0ba002e15ef712b4dddca6dcac804ab45c898f5c73cdac99bfe9b9bb99f6534c1446d8f4545660ec SHA512 1c0b12cdf7dadaba8d81ede769f76b059c7869732610353658cc928dd8c4943f8cf8beb15498a0dd4e064688cfdb7f88faaa9165c6da97c20d5e99080a12f413
diff --git a/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild b/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
new file mode 100644
index 00000000000..f29b83b491f
--- /dev/null
+++ b/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
@@ -0,0 +1,47 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit systemd
+
+DESCRIPTION="Extensible continuous integration server"
+HOMEPAGE="https://jenkins.io/"
+LICENSE="MIT"
+SRC_URI="http://mirrors.jenkins-ci.org/war-stable/${PV}/${PN/-bin/}.war -> ${P}.war"
+RESTRICT="mirror"
+SLOT="lts"
+KEYWORDS="~amd64 ~x86 ~amd64-linux"
+IUSE=""
+
+COMMON_DEPS="acct-user/jenkins
+	acct-group/jenkins"
+
+DEPEND="${COMMON_DEPS}"
+
+RDEPEND="${COMMON_DEPS}
+	media-fonts/dejavu
+	media-libs/freetype
+	!dev-util/jenkins-bin:0
+	>=virtual/jre-1.8.0"
+
+S=${WORKDIR}
+
+JENKINS_DIR=/var/lib/jenkins
+
+src_install() {
+	keepdir /var/log/jenkins ${JENKINS_DIR}/backup ${JENKINS_DIR}/home
+
+	insinto /opt/jenkins
+	newins "${DISTDIR}"/${P}.war ${PN/-bin/}.war
+
+	insinto /etc/logrotate.d
+	newins "${FILESDIR}"/${PN}-r1.logrotate ${PN/-bin/}
+
+	newinitd "${FILESDIR}"/${PN}.init2 jenkins
+	newconfd "${FILESDIR}"/${PN}.confd jenkins
+
+	systemd_newunit "${FILESDIR}"/${PN}.service2 jenkins.service
+
+	fowners jenkins:jenkins /var/log/jenkins ${JENKINS_DIR}/home ${JENKINS_DIR}/backup
+}
-- 
2.24.1

Re: [gentoo-dev] [PATCH 3/4] dev-util/jenkins-bin: bump to v2.204.1

[Joakim Tjernlund]

On Wed, 2019-12-25 at 16:11 +0100, Thomas Deutschmann wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Package-Manager: Portage-2.3.82, Repoman-2.3.20
> Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>
> ---
>  dev-util/jenkins-bin/Manifest                 |  1 +
>  .../jenkins-bin/jenkins-bin-2.204.1.ebuild    | 47 +++++++++++++++++++
>  2 files changed, 48 insertions(+)
>  create mode 100644 dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
> 
> diff --git a/dev-util/jenkins-bin/Manifest b/dev-util/jenkins-bin/Manifest
> index 39d97b60d3e..854cbb4f581 100644
> --- a/dev-util/jenkins-bin/Manifest
> +++ b/dev-util/jenkins-bin/Manifest
> @@ -2,4 +2,5 @@ DIST jenkins-bin-2.190.1.war 78245883 BLAKE2B 6c80eaebc6fe34e2c889c78a34dfc3e105
>  DIST jenkins-bin-2.190.2.war 78243424 BLAKE2B 7a6bd4cf1c070ce3a09fb84b3dbe7e87f474f4254dd4b4fcffdd7dedf7d4c2ba91d8783e7273214aaaa39bfeb02da721e4d539cba76312c21b523a9bf336a964 SHA512 b1f59ef10dfdfda06bedbf9a40a9e83e159b44b2b5574cba4d62547294386224f64d856490fd4477fb3300a4119d17fc284819719218dfcf32d3dc20ce468847
>  DIST jenkins-bin-2.190.3.war 78247363 BLAKE2B 99d4c13236b4b4f7308c7993033d1e5f9dd2fd9926febf52ffdacea595fecaba0d0eb8962761d8a6f983eaf9738f8be1ba4df785bb2fe6b613ac8cadcc618e23 SHA512 4ffa2ce3be4d55f0df8021026115d9ce8f1d0f4faa16eaf9f327ce17105f61731730c2a0124fb9af5d8c16c8fee9200f9b785b23856896e292a19f5404a9d2c2
>  DIST jenkins-bin-2.197.war 78309466 BLAKE2B c3d34c6fc40a82148eafa978c8787375ece6522d0d936b42f0296ee13cd084669bfa31975c0ad27816bdd4c1266cb066c0909774199a1373661a7ec524c06e91 SHA512 3b6a00dee5aeb8a94c8f75323c2469b54fe96d90bf8371898e41dc5bdecaa472f112bff1466481c66c9c7a07b22cbe799a08e45ac486d68fd5bdc7c20d43d722
> +DIST jenkins-bin-2.204.1.war 63433755 BLAKE2B 53cb254ddf3b59e083b564adf8d5696c61012e6d0d26b622eac7023268d5ba3d43082d07cae5654e032169cd144a5338f2553d4ee39c851c4126fe0be5378f1e SHA512 2ebf1ff7792a2ba80d8cf6f8675864580533b62659346e9ef3334ff988899d735d5d72cb3a89308cd9287bcaa74c42306cbf80a716d03658ad748688f94f394b
>  DIST jenkins-bin-2.205.war 62738246 BLAKE2B de350469e3a6e0d93f6d05c38f7669ce630f01a0284db83a0ba002e15ef712b4dddca6dcac804ab45c898f5c73cdac99bfe9b9bb99f6534c1446d8f4545660ec SHA512 1c0b12cdf7dadaba8d81ede769f76b059c7869732610353658cc928dd8c4943f8cf8beb15498a0dd4e064688cfdb7f88faaa9165c6da97c20d5e99080a12f413
> diff --git a/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild b/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
> new file mode 100644
> index 00000000000..f29b83b491f
> --- /dev/null
> +++ b/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
> @@ -0,0 +1,47 @@
> +# Copyright 1999-2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +inherit systemd
> +
> +DESCRIPTION="Extensible continuous integration server"
> +HOMEPAGE="https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.io%2F&amp;data=02%7C01%7Cjoakim.tjernlund%40infinera.com%7Cf63d3323a1844a3463cc08d7894d0284%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637128836158940038&amp;sdata=EZ5QAWXzcxCKufgyrnYoYyL4uPSmG5rENE4zQG747Gg%3D&amp;reserved=0"
> +LICENSE="MIT"
> +SRC_URI="https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirrors.jenkins-ci.org%2Fwar-stable%2F%24&amp;data=02%7C01%7Cjoakim.tjernlund%40infinera.com%7Cf63d3323a1844a3463cc08d7894d0284%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637128836158940038&amp;sdata=YZPJP7qtEM17poTYYuclipefI2YRyt1AF2PPaQjoL1I%3D&amp;reserved=0{PV}/${PN/-bin/}.war -> ${P}.war"
> +RESTRICT="mirror"
> +SLOT="lts"
> +KEYWORDS="~amd64 ~x86 ~amd64-linux"
> +IUSE=""
> +
> +COMMON_DEPS="acct-user/jenkins
> +       acct-group/jenkins"
> +
> +DEPEND="${COMMON_DEPS}"
> +
> +RDEPEND="${COMMON_DEPS}
> +       media-fonts/dejavu
> +       media-libs/freetype
> +       !dev-util/jenkins-bin:0
> +       >=virtual/jre-1.8.0"
> +
> +S=${WORKDIR}
> +
> +JENKINS_DIR=/var/lib/jenkins

Home dir is hardcoded, should just follow what acct-user/jenkins has defined.
Then one can finally choose some other dir for jenkins without duplicating the ebuild.

  Jocke

[gentoo-dev] [PATCH 4/4] dev-util/jenkins-bin: bump to v2.210

[Thomas Deutschmann]

Package-Manager: Portage-2.3.82, Repoman-2.3.20
Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>
---
 dev-util/jenkins-bin/Manifest                 |  1 +
 dev-util/jenkins-bin/jenkins-bin-2.210.ebuild | 47 +++++++++++++++++++
 2 files changed, 48 insertions(+)
 create mode 100644 dev-util/jenkins-bin/jenkins-bin-2.210.ebuild

diff --git a/dev-util/jenkins-bin/Manifest b/dev-util/jenkins-bin/Manifest
index 854cbb4f581..678e7c5e3a5 100644
--- a/dev-util/jenkins-bin/Manifest
+++ b/dev-util/jenkins-bin/Manifest
@@ -4,3 +4,4 @@ DIST jenkins-bin-2.190.3.war 78247363 BLAKE2B 99d4c13236b4b4f7308c7993033d1e5f9d
 DIST jenkins-bin-2.197.war 78309466 BLAKE2B c3d34c6fc40a82148eafa978c8787375ece6522d0d936b42f0296ee13cd084669bfa31975c0ad27816bdd4c1266cb066c0909774199a1373661a7ec524c06e91 SHA512 3b6a00dee5aeb8a94c8f75323c2469b54fe96d90bf8371898e41dc5bdecaa472f112bff1466481c66c9c7a07b22cbe799a08e45ac486d68fd5bdc7c20d43d722
 DIST jenkins-bin-2.204.1.war 63433755 BLAKE2B 53cb254ddf3b59e083b564adf8d5696c61012e6d0d26b622eac7023268d5ba3d43082d07cae5654e032169cd144a5338f2553d4ee39c851c4126fe0be5378f1e SHA512 2ebf1ff7792a2ba80d8cf6f8675864580533b62659346e9ef3334ff988899d735d5d72cb3a89308cd9287bcaa74c42306cbf80a716d03658ad748688f94f394b
 DIST jenkins-bin-2.205.war 62738246 BLAKE2B de350469e3a6e0d93f6d05c38f7669ce630f01a0284db83a0ba002e15ef712b4dddca6dcac804ab45c898f5c73cdac99bfe9b9bb99f6534c1446d8f4545660ec SHA512 1c0b12cdf7dadaba8d81ede769f76b059c7869732610353658cc928dd8c4943f8cf8beb15498a0dd4e064688cfdb7f88faaa9165c6da97c20d5e99080a12f413
+DIST jenkins-bin-2.210.war 62752366 BLAKE2B 02124970276a8c0edf8946413bd109a9835e047fd7e96bd05dfdb3454e3603720d6f6a630fb9f2a26a6431c30ed560116a3f40aabfaa5bb2667d80ef5909cd35 SHA512 fc4f64c0c2e7b4269b8b9e67332d7749ab8bd415b8fa1dc6df26529fc3164b57de49a71390f335b728ac2faeb3a1dfa148fd9bf3fc814e897efb484c1e226d8e
diff --git a/dev-util/jenkins-bin/jenkins-bin-2.210.ebuild b/dev-util/jenkins-bin/jenkins-bin-2.210.ebuild
new file mode 100644
index 00000000000..45f7e332969
--- /dev/null
+++ b/dev-util/jenkins-bin/jenkins-bin-2.210.ebuild
@@ -0,0 +1,47 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit systemd
+
+DESCRIPTION="Extensible continuous integration server"
+HOMEPAGE="https://jenkins.io/"
+LICENSE="MIT"
+SRC_URI="http://mirrors.jenkins-ci.org/war/${PV}/${PN/-bin/}.war -> ${P}.war"
+RESTRICT="mirror"
+SLOT="0"
+KEYWORDS="~amd64 ~x86 ~amd64-linux"
+IUSE=""
+
+COMMON_DEPS="acct-user/jenkins
+	acct-group/jenkins"
+
+DEPEND="${COMMON_DEPS}"
+
+RDEPEND="${COMMON_DEPS}
+	media-fonts/dejavu
+	media-libs/freetype
+	!dev-util/jenkins-bin:lts
+	>=virtual/jre-1.8.0"
+
+S=${WORKDIR}
+
+JENKINS_DIR=/var/lib/jenkins
+
+src_install() {
+	keepdir /var/log/jenkins ${JENKINS_DIR}/backup ${JENKINS_DIR}/home
+
+	insinto /opt/jenkins
+	newins "${DISTDIR}"/${P}.war ${PN/-bin/}.war
+
+	insinto /etc/logrotate.d
+	newins "${FILESDIR}"/${PN}-r1.logrotate ${PN/-bin/}
+
+	newinitd "${FILESDIR}"/${PN}.init2 jenkins
+	newconfd "${FILESDIR}"/${PN}.confd jenkins
+
+	systemd_newunit "${FILESDIR}"/${PN}.service2 jenkins.service
+
+	fowners jenkins:jenkins /var/log/jenkins ${JENKINS_DIR}/home ${JENKINS_DIR}/backup
+}
-- 
2.24.1

[gentoo-dev] Re: dev-util/jenkins-bin GLEP-81 migration

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Wed, 2019-12-25 at 16:11 +0100, Thomas Deutschmann wrote:
> 
> Complete change set can be found at 
> https://github.com/gentoo/gentoo/pull/14121.
> 
> Previous ebuilds using user eclass called
> 
>   fowners jenkins:jenkins /var/log/jenkins ${JENKINS_DIR}
> ${JENKINS_DIR}/home ${JENKINS_DIR}/backup
> 
> which I changed to
> 
>   fowners jenkins:jenkins /var/log/jenkins ${JENKINS_DIR}/home
> ${JENKINS_DIR}/backup
> 
> in assumption that $JENKINS_DIR is now maintained through acct-*
> package.
> 
> I changed chmod for $HOME to 0750 which should be a safer default.

Looks good to me, thanks!

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 484 bytes --]