And now I find out this wasn't eaten and made it through when I
unblocked it. Nevermind...
On 12/05/2014 11:54 PM, Jacco Ligthart wrote:
Hi List,
Here me again with lists and todo's :)
Today I wanted to know the difference with the upstream provider and
redsleeve6. For various reasons, I thought that loking at this from a
src.rpm perspective would be most efficient.
I'm not even sure there is a different sane way to do it other than by
looking at the list of .src.rpms
One thing to note, though, is that upstream have src.rpm distro tags
like el6_n where n is a number. This seems to have something to do with
the way their build farm is set up. These will get replaced by a simple
el6 tag when it passes through a normal build process. I am hoping this
accounts for all opf
One of the issues I had was
that upstream provides a tree with all older versions also present, and
it's difficult to get a list of the latest src.rpms with bash tools.
You should be able to get pretty far by something like
for file in `ls *.src.rpm | sed -e 's/-[0-9].*//' | sort -u`; do
ls $file-* | grep "$file-[0-9]" | head -1
done
That should get you the latest version of everything.
Unfortunately, java packages are named in a way that breaks this, but
there are hopefully few enough of them for it to be handlable manually.
Also on our side those issues are present as there are at least three
package trees to consider. after reading and searching I found however a
tool called repodiff. This tool can (as implied) diff two repos.
So I copied all src.rpms from upstream and created a repo. I also copied
base/SRPMS/upstream/ base/SRPMS/changed/ update/SRPMS/ and my test tree
with both upstream and updated src.rpms and again made a repo of that.
Ah, those three trees (base/upstream, base/changed, updates). I
understand what you mean now.
the result of the repodiff is an attachment to this mail.
Summary of the result:
* we have the following src.rpms newer/patched, without a note on
http://wiki.redsleeve.org/index.php/ModifiedPackages
Tables mingw32-libxml2-2.7.6-6.el6
ocaml-3.12.0-6.el6
pilot-link-0.12.4-6.el6.0.sl6
* there are 292 src.rpms newer on upstream that previously build without
issue on redsleeve. (plain.txt)
* there are 46 src.rpms newer on upstream that previously needed patches
to build (issue.txt)
Are these figures including your updates here:
http://cdn.opensxce.org/redsleeve/el6/updates-testing/
?
Speaking of which, I have observed a weird problem with the updated
glibc - when nscd is running I am seeing spurious DNS lookup failures.
Things still seem to work, but there are warning messages all over the
place. If I disable nscd (so there's no client side caching), everything
works fine. Has anyone else seen this problem with Jacco's glibc build?
* there are 192 src.rpms op upstream that have never been build on
redsleeve (new.txt)
I am not sure that latter bit is correct. For example, we have no
redhat-release-* packages in our repository.
I plan to build most of the packages the coming weeks. As I want to
reduce the list quickly, I randomly decided to start with the plain and
the new src.rpms smaller than 10MB. I'll report back when a significant
part of the building is done (or when I hit issues :) ).
One of my tricks is to order the build in ascending order of src.rpm
size. That way the small stuff gets built quickly, and the biggest,
slowest stuff gets built last.
One of the issues is however, that I do not know all these packages. I
can tell if they build without error, and maybe even if they are able to
install, but other testing than that should be done by a user of the
packages.
I have the same problem. That's why RS spent so long labeled "alpha",
even though it always worked just fine with everything I threw at it.
The only thing we can do is have a testing repository, and some kind of
a process to move things from testing to updates after, say, a month.
But if we do that we will need to do extra scrutinizing of any packages
that include critical security fixes and push those straight into the
update repository on the grounds that a relatively low risk of the
package being broken is not as bad as the certainty of there being a
known exploit in it.
Next question is to Gordan, what is the procedure to get these (and the
packages I made earlier) into the mainstream?
The procedure is that when you are happy that they build, install and
start correctly (no segfaults), you put them into your repository at
opensxce.org. Please keep packages that require modification in a
separate repository from the ones that build as-is from the upstream
src.rpms, and make sure that:
1) Version is bumped with an extra .0 on the end, after any existing
upstream version tags.
2) %changelog is updated appropriately.
3) diff of the build tree is provided in the same form as the existing
patches. What I do is:
rpm -rf rpmbuild
rpm -ivh $upstream.src.rpm
mv rpmbuild rpmbuild.old
rpm -ivh $modified.src.rpm
diff -ruN rpmbuild.old rpmbuild > $upstream.src.rpm.patch
I'll pull them down onto the ARM machines I use for testing, and try
them for a few days. Once I've put it all through a cursory check, I'll
make sure I can rebuild them all cleanly, and post them in the updates
repository.
Any ideas for improving this process are welcome.
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
