On 12/06/2014 01:21 PM, Gordan Bobic wrote: > > On 12/05/2014 11:54 PM, Jacco Ligthart wrote: > >> 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 >> I forgot, we also have the following extra: jack-audio-connection-kit-0.118.0-1.el6 libfreebob-1.0.11-6
>> * 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/ > ? > yup, I made a vague reference above: "my test tree" > 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? I normally don't use nscd. I tried it now on a couple of machines. I see nothing strange apart from: nscd: 2862 cannot stat() file `/etc/netgroup': No such file or directory (once on startup) (I see the same on x86_64 although I see there also "Access Vector Cache (AVC) started") > >> * 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. That is exactly what I meant to say. 192 srpms that are not in our repository. Some are newish, and needed for new dependencies, others we might like to have, but were never done and probably a couple that are redhat specific and are not (ever) needed. > >> 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. I was thinking of the same, but decided on the simple cut-off. I found, however that size and buildtime have no real correlation. another thing I found is that there are a gazillion undocumented dependencies. sometimes you can build 2 srpms successful, only to find that they don't install, because you build them in the wrong order. > >> 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. > OK. previously I created the changed RPMS more as a proof-of-concept than as a finished and complete product. Especially the changelog was therefore quite empty. I will make them all nice :) I think there should also be a signing step. Jacco _______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
