~alpine/aports

6 2

[alpine-aports] [PATCH 2/2] testing/drbd9-grsec: upgrade to 9.0.2

Details
Message ID
<1461273747-10283-2-git-send-email-roland.kammerer@linbit.com>
Sender timestamp
1461273747
DKIM signature
missing
Download raw message
Patch: +6 -6
- New upstream release
- Changed download url
---
 testing/drbd9-grsec/APKBUILD | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/testing/drbd9-grsec/APKBUILD b/testing/drbd9-grsec/APKBUILD
index ecf7d4c..db52fec 100644
--- a/testing/drbd9-grsec/APKBUILD
+++ b/testing/drbd9-grsec/APKBUILD
@@ -8,13 +8,13 @@ _kpkg=linux-$_flavor
_kver=4.4.8
_kpkgrel=0

_usver=9.0.1
_usver=9.0.2
# upstream now also has a -rel in the tar-balls
# set it here for "source", but don't mangle it into pkgrel/_mypkgrel
# if there is a new upstream rel (eg. 9.0.1-2), we just increase _mypkgrel
_usrel=1

_mypkgrel=0
_mypkgrel=1

_kernelver=$_kver-r$_kpkgrel
_abi_release=${_kver}-${_kpkgrel}-${_flavor}
@@ -31,7 +31,7 @@ depends_dev=""
makedepends="linux-grsec-dev"
install=""
subpackages=""
source="http://oss.linbit.com/$_usname/${_usver%.*}/$_usname-$_usver-$_usrel.tar.gz"
source="http://www.drbd.org/download/$_usname/${_usver%.*}/$_usname-$_usver-$_usrel.tar.gz"

_builddir=$srcdir/$_usname-$_usver-$_usrel
prepare() {
@@ -68,6 +68,6 @@ package() {
	make DESTDIR="$pkgdir" install || return 1
}

md5sums="0d1d50e225ee0c8058af4fe1442d5242  drbd-9.0.1-1.tar.gz"
sha256sums="f0862fffa5d73c433598fe1957bab61a2ae7ae1c4c7c0cecbef760e67a65fe20  drbd-9.0.1-1.tar.gz"
sha512sums="0deb07d5c0217d35f85902064725311b3b74fe53ccb7faddb16624654c04edb44fb9462b0d967b1eb618a658ed66d32e71aa2b2048aa3fcd43a95d0f099f55d4  drbd-9.0.1-1.tar.gz"
md5sums="b906e860f97fa4b0652f499a8b22c260  drbd-9.0.2-1.tar.gz"
sha256sums="507de8869fa7f6b54a68554e6203a4ca3fc39adc85016fbfe9bc6b9b43d04c9f  drbd-9.0.2-1.tar.gz"
sha512sums="45b14690e1b063be5e64244ac91e096542f1805f15936ad89ed59716f93a585927f228b920008bba736d4096714901aa65d431684b8f54244dc643d72eec624f  drbd-9.0.2-1.tar.gz"
-- 
2.6.6



---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20160422142444.358c4bd5@ncopa-desktop.alpinelinux.org>
In-Reply-To
<1461273747-10283-2-git-send-email-roland.kammerer@linbit.com> (view parent)
Sender timestamp
1461327884
DKIM signature
missing
Download raw message
On Thu, 21 Apr 2016 23:22:27 +0200
Roland Kammerer <roland.kammerer@linbit.com> wrote:

> - New upstream release
> - Changed download url
> ---
>  testing/drbd9-grsec/APKBUILD | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)

This and drbdmanage was applied. Thanks!

I am about to do a v3.4 release. I wonder if you think we can move
drbd9-grsec and drbdmanage to main repository? can we expect upstream
bug fixes for at least 6 months (if any) and upstram sec fixes for
about 2 years?

Are there any reason to not move it to repository 'main'?

-nc


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Details
Message ID
<20160422130731.GU1371@rck.sh>
In-Reply-To
<20160422142444.358c4bd5@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1461330452
DKIM signature
missing
Download raw message
On Fri, Apr 22, 2016 at 02:24:44PM +0200, Natanael Copa wrote:
> On Thu, 21 Apr 2016 23:22:27 +0200
> Roland Kammerer <roland.kammerer@linbit.com> wrote:
> 
> > - New upstream release
> > - Changed download url
> > ---
> >  testing/drbd9-grsec/APKBUILD | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> This and drbdmanage was applied. Thanks!
> 
> I am about to do a v3.4 release. I wonder if you think we can move
> drbd9-grsec and drbdmanage to main repository? can we expect upstream
> bug fixes for at least 6 months (if any) and upstram sec fixes for
> about 2 years?

Hi Natanael,

How is the policy for "main" and a given release? Maybe I missed it, but
at a first look I did not find a policy. Are version bumps allowed? If
so, what are the rules? Guess "no regressions" would be one ;-). Or is
it more like Debian stable where the version is pinned and only fixup
patches are allowed?

Regards, rck


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20160425122202.0717a996@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20160422130731.GU1371@rck.sh> (view parent)
Sender timestamp
1461579722
DKIM signature
missing
Download raw message
On Fri, 22 Apr 2016 15:07:32 +0200
Roland Kammerer <roland.kammerer@linbit.com> wrote:

> On Fri, Apr 22, 2016 at 02:24:44PM +0200, Natanael Copa wrote:
> > On Thu, 21 Apr 2016 23:22:27 +0200
> > Roland Kammerer <roland.kammerer@linbit.com> wrote:
> >   
> > > - New upstream release
> > > - Changed download url
> > > ---
> > >  testing/drbd9-grsec/APKBUILD | 12 ++++++------
> > >  1 file changed, 6 insertions(+), 6 deletions(-)  
> > 
> > This and drbdmanage was applied. Thanks!
> > 
> > I am about to do a v3.4 release. I wonder if you think we can move
> > drbd9-grsec and drbdmanage to main repository? can we expect upstream
> > bug fixes for at least 6 months (if any) and upstram sec fixes for
> > about 2 years?  
> 
> Hi Natanael,
> 
> How is the policy for "main" and a given release? Maybe I missed it, but
> at a first look I did not find a policy. Are version bumps allowed? If
> so, what are the rules? Guess "no regressions" would be one ;-). Or is
> it more like Debian stable where the version is pinned and only fixup
> patches are allowed?

The general rule is that if you use a stable repository (eg v3.3), then
you should be able to `apk upgrade -U` without need to worry that
anything breaks. that means, we cannot break ABI in a stable branch. We
can not introduce changes that requires user to change configuration to
make things work.

Generally speaking, only bugfixes should go there.

We prefer using upstream version bumps over backporting patches (Debian
style) because it is less work for us, but often we backport sec fixes
because upstream only provides version bumps that breaks things (break
abi or require user to reconfig things).

We also accept exceptions, where we backport new functionality if there
are good reasons to do so and if it does not break anything for
existing users.

So, for drbd, we would like minor version bumps for v3.4/main and sec
fix releases. Those should preferable not introduce new functionality,
but we may accept them if they don't introduce breakages.

I don't have the impression that drbd introduce big revolutions every
minor release so I don't think there will be any problem.

What I don't want is, that in 1.5 years in future, there show up a
critical sec issue in drbd9 and the *only* way to fix it is to upgrade to
drbd13 which require full reconfiguration and ABI incompatible libary
updates and recompile of half the world.

Bascially what I want is to be sure that we can minor sec fix release
bump or maybe even getting help in backporting sec fixes for 2 years if
needed.

Thanks!

-nc


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Details
Message ID
<20160425105146.GZ1371@rck.sh>
In-Reply-To
<20160425122202.0717a996@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1461581506
DKIM signature
missing
Download raw message
On Mon, Apr 25, 2016 at 12:22:02PM +0200, Natanael Copa wrote:
> On Fri, 22 Apr 2016 15:07:32 +0200
> Roland Kammerer <roland.kammerer@linbit.com> wrote:
> 
> > On Fri, Apr 22, 2016 at 02:24:44PM +0200, Natanael Copa wrote:
> > > On Thu, 21 Apr 2016 23:22:27 +0200
> > > Roland Kammerer <roland.kammerer@linbit.com> wrote:
> > >   
> > > > - New upstream release
> > > > - Changed download url
> > > > ---
> > > >  testing/drbd9-grsec/APKBUILD | 12 ++++++------
> > > >  1 file changed, 6 insertions(+), 6 deletions(-)  
> > > 
> > > This and drbdmanage was applied. Thanks!
> > > 
> > > I am about to do a v3.4 release. I wonder if you think we can move
> > > drbd9-grsec and drbdmanage to main repository? can we expect upstream
> > > bug fixes for at least 6 months (if any) and upstram sec fixes for
> > > about 2 years?  
> > 
> > Hi Natanael,
> > 
> > How is the policy for "main" and a given release? Maybe I missed it, but
> > at a first look I did not find a policy. Are version bumps allowed? If
> > so, what are the rules? Guess "no regressions" would be one ;-). Or is
> > it more like Debian stable where the version is pinned and only fixup
> > patches are allowed?
> 
> The general rule is that if you use a stable repository (eg v3.3), then
> you should be able to `apk upgrade -U` without need to worry that
> anything breaks. that means, we cannot break ABI in a stable branch. We
> can not introduce changes that requires user to change configuration to
> make things work.
> 
> Generally speaking, only bugfixes should go there.
> 
> We prefer using upstream version bumps over backporting patches (Debian
> style) because it is less work for us, but often we backport sec fixes
> because upstream only provides version bumps that breaks things (break
> abi or require user to reconfig things).
> 
> We also accept exceptions, where we backport new functionality if there
> are good reasons to do so and if it does not break anything for
> existing users.
> 
> So, for drbd, we would like minor version bumps for v3.4/main and sec
> fix releases. Those should preferable not introduce new functionality,
> but we may accept them if they don't introduce breakages.
> 
> I don't have the impression that drbd introduce big revolutions every
> minor release so I don't think there will be any problem.
> 
> What I don't want is, that in 1.5 years in future, there show up a
> critical sec issue in drbd9 and the *only* way to fix it is to upgrade to
> drbd13 which require full reconfiguration and ABI incompatible libary
> updates and recompile of half the world.
> 
> Bascially what I want is to be sure that we can minor sec fix release
> bump or maybe even getting help in backporting sec fixes for 2 years if
> needed.

In that case I suggest the following:

Let's move drbd9 to main. Security fixes and don't break the upgrade
path is something our (Linbit's) customers expect anyways. It should
always be save to upgrade drbd (kernel side and user space).

Drbdmanage is a relatively young project and while basically the same
rules apply, I simply don't want to make these guarantees. We are close
to 1.0, but who knows, there might be a 2.0 in a few months which breaks
the dbus API, configuration files, and what not. This should not happen,
but I don't want to maintain old crap I then don't really care about
anymore... So for now I think we should keep it in testing.

While drbdmanage makes using drbd a lot more comfortable, drbd backing
devices can be manually created and configuration files can be scp'ed.
Not having drbdmanage in main is no show stopper for drbd itself.

Regards, rck


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20160425131120.613e81bc@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20160425105146.GZ1371@rck.sh> (view parent)
Sender timestamp
1461582680
DKIM signature
missing
Download raw message
On Mon, 25 Apr 2016 12:51:46 +0200
Roland Kammerer <roland.kammerer@linbit.com> wrote:

> On Mon, Apr 25, 2016 at 12:22:02PM +0200, Natanael Copa wrote:
> > On Fri, 22 Apr 2016 15:07:32 +0200
> > Roland Kammerer <roland.kammerer@linbit.com> wrote:
> >   
> > > On Fri, Apr 22, 2016 at 02:24:44PM +0200, Natanael Copa wrote:  
> > > > On Thu, 21 Apr 2016 23:22:27 +0200
> > > > Roland Kammerer <roland.kammerer@linbit.com> wrote:
> > > >     
> > > > > - New upstream release
> > > > > - Changed download url
> > > > > ---
> > > > >  testing/drbd9-grsec/APKBUILD | 12 ++++++------
> > > > >  1 file changed, 6 insertions(+), 6 deletions(-)    
> > > > 
> > > > This and drbdmanage was applied. Thanks!
> > > > 
> > > > I am about to do a v3.4 release. I wonder if you think we can move
> > > > drbd9-grsec and drbdmanage to main repository? can we expect upstream
> > > > bug fixes for at least 6 months (if any) and upstram sec fixes for
> > > > about 2 years?    
> > > 
> > > Hi Natanael,
> > > 
> > > How is the policy for "main" and a given release? Maybe I missed it, but
> > > at a first look I did not find a policy. Are version bumps allowed? If
> > > so, what are the rules? Guess "no regressions" would be one ;-). Or is
> > > it more like Debian stable where the version is pinned and only fixup
> > > patches are allowed?  
> > 
> > The general rule is that if you use a stable repository (eg v3.3), then
> > you should be able to `apk upgrade -U` without need to worry that
> > anything breaks. that means, we cannot break ABI in a stable branch. We
> > can not introduce changes that requires user to change configuration to
> > make things work.
> > 
> > Generally speaking, only bugfixes should go there.
> > 
> > We prefer using upstream version bumps over backporting patches (Debian
> > style) because it is less work for us, but often we backport sec fixes
> > because upstream only provides version bumps that breaks things (break
> > abi or require user to reconfig things).
> > 
> > We also accept exceptions, where we backport new functionality if there
> > are good reasons to do so and if it does not break anything for
> > existing users.
> > 
> > So, for drbd, we would like minor version bumps for v3.4/main and sec
> > fix releases. Those should preferable not introduce new functionality,
> > but we may accept them if they don't introduce breakages.
> > 
> > I don't have the impression that drbd introduce big revolutions every
> > minor release so I don't think there will be any problem.
> > 
> > What I don't want is, that in 1.5 years in future, there show up a
> > critical sec issue in drbd9 and the *only* way to fix it is to upgrade to
> > drbd13 which require full reconfiguration and ABI incompatible libary
> > updates and recompile of half the world.
> > 
> > Bascially what I want is to be sure that we can minor sec fix release
> > bump or maybe even getting help in backporting sec fixes for 2 years if
> > needed.  
> 
> In that case I suggest the following:
> 
> Let's move drbd9 to main. Security fixes and don't break the upgrade
> path is something our (Linbit's) customers expect anyways. It should
> always be save to upgrade drbd (kernel side and user space).
> 
> Drbdmanage is a relatively young project and while basically the same
> rules apply, I simply don't want to make these guarantees. We are close
> to 1.0, but who knows, there might be a 2.0 in a few months which breaks
> the dbus API, configuration files, and what not. This should not happen,
> but I don't want to maintain old crap I then don't really care about
> anymore... So for now I think we should keep it in testing.
> 
> While drbdmanage makes using drbd a lot more comfortable, drbd backing
> devices can be manually created and configuration files can be scp'ed.
> Not having drbdmanage in main is no show stopper for drbd itself.

we could also move it to "community" repo. then we only need provide
fixes for it til next stable branch (6 months).

The thing is that we don't build testing repo for stable releases, so
it will not be available for v3.4 users we move it to either main or
community.

 
> Regards, rck

-nc


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Details
Message ID
<20160425113812.GA1371@rck.sh>
In-Reply-To
<20160425131120.613e81bc@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1461584293
DKIM signature
missing
Download raw message
On Mon, Apr 25, 2016 at 01:11:20PM +0200, Natanael Copa wrote:
> we could also move it to "community" repo. then we only need provide
> fixes for it til next stable branch (6 months).

Sounds reasonable, ok from my side. 

Regards, rck


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)