9:59 a.m.
2016-09-24 5:39 GMT+02:00 Sérgio M. Basto <sergiomb(a)rpmfusion.org>:
commit 36ac6ae0d5cb72b37ba60a8dc69eae3b147e0935
Author: Sérgio M. Basto <sergio(a)serjux.com>
Date: Sat Sep 24 04:31:21 2016 +0100
Update to 0.148-20160924-86b7198 version
%endif
%changelog
+* Sat Sep 24 2016 Sérgio Basto <sergio(a)serjux.com> - 0.148.20160924git86b7198-1
+- Update to 0.148-20160924-86b7198 version
+- Change versioning of the package in order to have better information, now the
+ package version include date plus git short commit, as result we may reset the
+ release count.
This versionning change violate the packaging guideline.
https://fedoraproject.org/wiki/Packaging:Versioning
I've untagged this build for now.
If you want to enforce dependencies based on snapshot date, please
have a look on live555 instead.
Thx
--
-
Nicolas (kwizart)
4:34 p.m.
New subject: [x264] Update to 0.148-20160924-86b7198 version
On Seg, 2016-09-26 at 11:59 +0200, Nicolas Chauvet wrote:
2016-09-24 5:39 GMT+02:00 Sérgio M. Basto
<sergiomb(a)rpmfusion.org>:
>
> commit 36ac6ae0d5cb72b37ba60a8dc69eae3b147e0935
> Author: Sérgio M. Basto <sergio(a)serjux.com>
> Date: Sat Sep 24 04:31:21 2016 +0100
>
> Update to 0.148-20160924-86b7198 version
> %endif
--- a/x264.spec
+++ b/x264.spec
@@ -1,7 +1,7 @@
-# globals for x264-0.148-20160614-a5e06b9.tar.bz2
+# globals for x264-0.148-20160924-86b7198.tar.bz2
%global api 148
-%global gitdate 20160614
-%global gitversion a5e06b9
+%global gitdate 20160924
+%global gitversion 86b7198
%global snapshot %{gitdate}-%{gitversion}
%global gver .%{gitdate}git%{gitversion}
%global branch stable
@@ -29,8 +29,8 @@
Summary: H264/AVC video streams encoder
Name: x264
-Version: 0.%{api}
-Release: 11%{?gver}%{?_with_bootstrap:_bootstrap}%{?dist}
+Version: 0.%{api}%{?gver}
+Release: 1%{?_with_bootstrap:_bootstrap}%{?dist}
Version: 0.148.20160924git86b7198-1
vs live555 Version: 2016.07.19
Version 0.148 is useful, you suggest 0.148.2016.09.24.git86b7198-1 ? ,
also git hash is useful ... or like this 0.148.20160924.86b7198-1
without git world ?
yeah I think version should be with date of the source and git
shortcommit : %{gitdate}.git%{shortcommit} this should be part of
version, if not, one day we are in 0.148-117 and counting, is like
rtmpdump.spec ! , the version almost stopped , so our version should
include %{gitdate}.git%{shortcommit} .
This is approved ?
Thanks
> %changelog
> +* Sat Sep 24 2016 Sérgio Basto <sergio(a)serjux.com> -
> 0.148.20160924git86b7198-1
> +- Update to 0.148-20160924-86b7198 version
> +- Change versioning of the package in order to have better
> information, now the
> + package version include date plus git short commit, as result we
> may reset the
> + release count.
This versionning change violate the packaging guideline.
https://fedoraproject.org/wiki/Packaging:Versioning
I've untagged this build for now.
If you want to enforce dependencies based on snapshot date, please
have a look on live555 instead.
Thx
--
Sérgio M. B.
6:52 p.m.
New subject: [x264] Update to 0.148-20160924-86b7198 version
2016-09-26 18:34 GMT+02:00 Sérgio Basto <sergio(a)serjux.com>:
On Seg, 2016-09-26 at 11:59 +0200, Nicolas Chauvet wrote:
> 2016-09-24 5:39 GMT+02:00 Sérgio M. Basto <sergiomb(a)rpmfusion.org>:
> >
> > commit 36ac6ae0d5cb72b37ba60a8dc69eae3b147e0935
> > Author: Sérgio M. Basto <sergio(a)serjux.com>
> > Date: Sat Sep 24 04:31:21 2016 +0100
> >
> > Update to 0.148-20160924-86b7198 version
> > %endif
--- a/x264.spec
+++ b/x264.spec
@@ -1,7 +1,7 @@
-# globals for x264-0.148-20160614-a5e06b9.tar.bz2
+# globals for x264-0.148-20160924-86b7198.tar.bz2
%global api 148
-%global gitdate 20160614
-%global gitversion a5e06b9
+%global gitdate 20160924
+%global gitversion 86b7198
%global snapshot %{gitdate}-%{gitversion}
%global gver .%{gitdate}git%{gitversion}
%global branch stable
@@ -29,8 +29,8 @@
Summary: H264/AVC video streams encoder
Name: x264
-Version: 0.%{api}
-Release: 11%{?gver}%{?_with_bootstrap:_bootstrap}%{?dist}
+Version: 0.%{api}%{?gver}
+Release: 1%{?_with_bootstrap:_bootstrap}%{?dist}
Version: 0.148.20160924git86b7198-1
vs live555 Version: 2016.07.19
Version 0.148 is useful, you suggest 0.148.2016.09.24.git86b7198-1 ? ,
also git hash is useful ... or like this 0.148.20160924.86b7198-1
without git world ?
yeah I think version should be with date of the source and git
shortcommit : %{gitdate}.git%{shortcommit} this should be part of
version, if not, one day we are in 0.148-117 and counting, is like
rtmpdump.spec ! , the version almost stopped , so our version should
include %{gitdate}.git%{shortcommit} .
This is approved ?
No I'm sorry, I should have been more accurate.
Packaging guideline mandate that the snapshot date and/or git hash to
be in the release field.
for x264 the version is 0.148 as reported by the upstream version.sh
script. we could add the X264_REV field, but I'm not sure if it's
sorted, so it might not be relevant as a RPM Version field (as later
version won't be higher).
So basically I'm asking to revert back to the previous version - release scheme.
Why I've mentioned live555 is because it's the same as x264 in the
sense that SONAME is the same since few time already but previously
there were no enforcement that the version installed at runtime is
high enough.
It is done by dropping a RPM macro in the live555-devel that is later
re-used by packages using live555 (mainly vlc). Since this macro is
used at build time, this enforce that the live555 version used at
build time is the same at runtime (but it could be >= instead of ==).
I don't know why you thought it was important to change the version
field in x264, but this seems a better approach.
Thx
--
-
Nicolas (kwizart)
1:55 a.m.
New subject: [x264] Update to 0.148-20160924-86b7198 version
On Seg, 2016-09-26 at 20:52 +0200, Nicolas Chauvet wrote:
2016-09-26 18:34 GMT+02:00 Sérgio Basto <sergio(a)serjux.com>:
>
> On Seg, 2016-09-26 at 11:59 +0200, Nicolas Chauvet wrote:
> >
> > 2016-09-24 5:39 GMT+02:00 Sérgio M. Basto <sergiomb(a)rpmfusion.org
> > >:
> > >
> > >
> > > commit 36ac6ae0d5cb72b37ba60a8dc69eae3b147e0935
> > > Author: Sérgio M. Basto <sergio(a)serjux.com>
> > > Date: Sat Sep 24 04:31:21 2016 +0100
> > >
> > > Update to 0.148-20160924-86b7198 version
> > > %endif
>
> --- a/x264.spec
> +++ b/x264.spec
> @@ -1,7 +1,7 @@
> -# globals for x264-0.148-20160614-a5e06b9.tar.bz2
> +# globals for x264-0.148-20160924-86b7198.tar.bz2
> %global api 148
> -%global gitdate 20160614
> -%global gitversion a5e06b9
> +%global gitdate 20160924
> +%global gitversion 86b7198
> %global snapshot %{gitdate}-%{gitversion}
> %global gver .%{gitdate}git%{gitversion}
> %global branch stable
> @@ -29,8 +29,8 @@
>
> Summary: H264/AVC video streams encoder
> Name: x264
> -Version: 0.%{api}
> -Release: 11%{?gver}%{?_with_bootstrap:_bootstrap}%{?dist}
> +Version: 0.%{api}%{?gver}
> +Release: 1%{?_with_bootstrap:_bootstrap}%{?dist}
>
>
> Version: 0.148.20160924git86b7198-1
>
> vs live555 Version: 2016.07.19
>
> Version 0.148 is useful, you suggest 0.148.2016.09.24.git86b7198-1
> ? ,
> also git hash is useful ... or like this 0.148.20160924.86b7198-1
> without git world ?
>
> yeah I think version should be with date of the source and git
> shortcommit : %{gitdate}.git%{shortcommit} this should be part of
> version, if not, one day we are in 0.148-117 and counting, is like
> rtmpdump.spec ! , the version almost stopped , so our version
> should
> include %{gitdate}.git%{shortcommit} .
>
> This is approved ?
No I'm sorry, I should have been more accurate.
Packaging guideline mandate that the snapshot date and/or git hash to
be in the release field.
for x264 the version is 0.148 as reported by the upstream version.sh
script. we could add the X264_REV field, but I'm not sure if it's
sorted, so it might not be relevant as a RPM Version field (as later
version won't be higher).
So basically I'm asking to revert back to the previous version -
release scheme.
The X264_REV field is the counting number of the commits, but I prefer
use date because have more meaning.
And what do you say about Version: 0.148.20160924-1.git86b7198 ?
Why I've mentioned live555 is because it's the same as x264
in the
sense that SONAME is the same since few time already but previously
there were no enforcement that the version installed at runtime is
high enough.
It is done by dropping a RPM macro in the live555-devel that is later
re-used by packages using live555 (mainly vlc). Since this macro is
used at build time, this enforce that the live555 version used at
build time is the same at runtime (but it could be >= instead of ==).
I didn't understand this part ...
I don't know why you thought it was important to change the
version
field in x264, but this seems a better approach.
Because when source change, version should change. The Release field is
to counting the rebuilds. Since in x264, version and api version is the
same thing and since api doesn't change a lot, we should change the
version, otherwise release number doesn't make much sense, we are in
the 11 release, also makes more sense make this change in rhel7 where
the counting of release was reset to 0, in my very personal counting I
had begin by 1, since is one counting, but since is bootstrap may make
sense 0, I dunno.
Doen't make more sense use x264-0.148.20160614-1.gita5e06b9.el7 as next
version of x264-0.148-0.20160614gita5e06b9_bootstrap.el7 [1]?
0.148.20160924-1.git86b7198.fc26
0.148.20160614-1.gita5e06b9.el7
[1] http://koji.rpmfusion.org/koji/packageinfo?packageID=272
BTW, I already tried change NamingGuidelines [2] in
post or pre releases [2], we have some cases of packages where version
almost not change but source change often, digging on my emails I found
yet another choice in [3] but 0.148.%{gitdate}-1.git%{shortcommit} is
my choice.
[2] https://fedoraproject.org/wiki/Packaging:Versioning#Post-Release_packages
[3]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Thanks and best regards,
--
Sérgio M. B.
9:35 p.m.
New subject: [x264] Update to 0.148-20160924-86b7198 version
Sérgio Basto wrote:
And what do you say about Version: 0.148.20160924-1.git86b7198 ?
That is also not compliant with the current Fedora packaging guidelines.
Because when source change, version should change. The Release field
is
to counting the rebuilds.
Sorry, that is not how Fedora packaging works, in the case of snapshot
packages.
Please follow:
https://fedoraproject.org/wiki/Packaging:Versioning
exactly as written, and do not try to discuss that with us, we did not make
these guidelines, we just have to enforce them to ensure consistency across
the distribution.
There is a proposal that would change this:
https://fedorahosted.org/fpc/ticket/398
(by introducing Debian-style + and ~ suffixes in Version), but it has not
been approved yet. So you cannot use it at this time.
Kevin Kofler
12:17 a.m.
New subject: [x264] Update to 0.148-20160924-86b7198 version
On Qua, 2016-09-28 at 23:35 +0200, Kevin Kofler wrote:
Sérgio Basto wrote:
>
> And what do you say about Version: 0.148.20160924-1.git86b7198 ?
That is also not compliant with the current Fedora packaging
guidelines.
>
> Because when source change, version should change. The Release
> field is
> to counting the rebuilds.
Sorry, that is not how Fedora packaging works, in the case of
snapshot
packages.
Yes , like I already wrote in fedoras list, versioning on packages
which doesn't have version should have 2 counters, but you win, by I'm
not following the guideline, IMHO I'm improving it, but I'm not going
discus this, because I can't win.
I'd like point out 2 things, 1 - IMHO Package guidelines, is what it
says, one guide and is *not* the supreme truth, that I have to follow
strictly, 2 - I'm one of the official package maintainer of x264 [1] so
I felt that I have more property / authorization .
So no problem nor a big deal, we already rollback the versioning, sorry
if I brought you trouble or bother anyone, it wasn't my intention and
it was just a small detail, I think.
[1]
https://admin.rpmfusion.org/pkgdb/package/free/x264/
Please follow:
https://fedoraproject.org/wiki/Packaging:Versioning
exactly as written, and do not try to discuss that with us, we did
not make
these guidelines, we just have to enforce them to ensure consistency
across
the distribution.
There is a proposal that would change this:
https://fedorahosted.org/fpc/ticket/398
(by introducing Debian-style + and ~ suffixes in Version), but it has
not
been approved yet. So you cannot use it at this time.
Let me see, I can fit in what I want, in resume, my case, is about
packages without version or is a version that stalled and the package
is just maintained over the time ...
Thanks,
--
Sérgio M. B.
1:18 a.m.
New subject: [x264] Update to 0.148-20160924-86b7198 version
Sérgio Basto wrote:
I'd like point out 2 things, 1 - IMHO Package guidelines, is what
it
says, one guide and is *not* the supreme truth, that I have to follow
strictly, 2 - I'm one of the official package maintainer of x264 [1] so
I felt that I have more property / authorization .
Sorry, but the naming is misleading there (at least for us non-native
English speakers – I cannot comment on how it sound to a US American). The
Fedora Packaging "Guidelines" are actually not just informative guidelines,
but policies that, for the most part, have to be followed strictly.
Kevin Kofler
8:46 p.m.
New subject: [x264] Update to 0.148-20160924-86b7198 version
On Sex, 2016-09-30 at 03:18 +0200, Kevin Kofler wrote:
Sérgio Basto wrote:
>
> I'd like point out 2 things, 1 - IMHO Package guidelines, is what
> it
> says, one guide and is *not* the supreme truth, that I have to
> follow
> strictly, 2 - I'm one of the official package maintainer of x264
> [1] so
> I felt that I have more property / authorization .
Sorry, but the naming is misleading there (at least for us non-
native
English speakers – I cannot comment on how it sound to a US
American). The
Fedora Packaging "Guidelines" are actually not just informative
guidelines,
but policies that, for the most part, have to be followed strictly.
Hello ,
Trying focus on what matters, we do not follow strictly the guidelines,
neither here neither in Fedora, I know many exceptions, follow
guideline strictly is an error .
First, think that we can make a guideline that covers all cases is
utopian.
When we have cases coming out of the ordinary, we must have the ability
to do the best and do not do what is in the guides strictly.
Of course does not mean that we can break the rules deliberately, we
have to have a consistent justification and only in cases out of the
ordinary, but we should have some flexibility, IMHO. Also we should try
improve guidelines and include some rules for out of the ordinary
cases.
Now, have a long conversation and argumentation and in the end someone
says "ah but doesn't follow guidelines so no", is a waste of time
because if we begin an argumentation is because we know that is not in
guidelines strictly or else we don't need argue.
Cheers,
--
Sérgio M. B.
3009
days inactive
3013
days old
rpmfusion-developers@lists.rpmfusion.org
7 comments
3 participants
participants (3)
-
Kevin Kofler -
Nicolas Chauvet -
Sérgio Basto