On 04/02/2016 05:53 PM, Gordan Bobic wrote: > On 02/04/16 16:44, Jacco Ligthart wrote: >> On 04/02/2016 04:12 PM, Gordan Bobic wrote: >>> On 02/04/16 14:34, Jacco Ligthart wrote: >>>> Hi, >>>> >>>> I found an error in kde-workspace. whenever I install the latest >>>> version >>>> (from RSEL 7.2) I get windows without borders. Highly annoying. I >>>> decided to revert the version of kde-workspace back to the working one >>>> in RSEL 7.1 >>> >>> When you say you find an error, you mean you find the root cause, or >>> you mean you found that it was broken kde-workspace was causing the >>> borderless windows? >>> >> I did not find the root cause. I just noticed that, when updating >> kde-workspace from 4.10.5-21 (the 7.1 version) to 4.11.19-7 (the 7.2 >> version) all windows in KDE would get borderless. I'm talking here about >> the SRC rpm, after building it will expand to a number of binary rpms >> (23 for the new version), which all depend on each other. I could not >> determine which binary rpm holds the issue. >> >> I could not find any reference that anybody else is seeing the same >> issue. >> >> The errata says that the update was a bugfix. I thought that the best >> route was to just revert back to the old version. > > Fair enough. As long as it's not a security related fix, I can live > with the package not being fully up to date. > >>>> This means that I now know of no open issues in 7.2 :) >>>> >>>> I think it's time to work towards release. >>>> @Gordan, how do we want to do this? same as 6.7? >>> >>> Yes, can do. If everything broken is fixed/removed from the 7.2 >>> branch, and the packages are deduplicated, I can put them through the >>> signing box, and re-create the same directory structure as we have >>> with 6.x. >> >> It should be mostly deduped. let me check. >> I only have the following dupes: >> - I keep the original srpms when I patch, so those are all dupes > > I don't think we should keep the original SRPMs, only the patched > SRPMS and the patches from original SRPMs to the modified ones. Do you > have a view on this? I often use 'repodiff' to find out if our tree is up-to-date with upstream. I find that it helps to keep the original SRPMs to keep the noise down. For example: db4: db4-4.7.25-20.el6_7 -> db4-4.7.25-20.el6.0 If I would have had the original SRPM in the tree I would not have seen this. OTOH, it is no extra effort on my side to keep them in a separate tree.
>> - mesa and mesa-private-llvm are duped between new and extra > If one set is broken, can we just outright remove them? Yes, could be. We should move the new ones then from extra to new. >> - kde-workspace is duped between base and new/broken > OK, I'll exclude the stuff in broken from the release. I normally exclude broken in the createrepo step, but I thought to keep it in to let others try to find out what's going on. >> - I have multiple versions of kernels for raspberries and odroids. >> (which reminds me, I should have put them in separate SOC repos) > As long as you put them in an obviously separate directory, I should > be able to selective pull the base distro RPMs for signing. They are now all in extra. I'll separate them. >> (base is unchanged from 7.1; new is newly build for 7.2) > Are there any duplicates between base and new? Or have the deprecated > packages been removed from your 7.1 base directories? no dupes. everything deprecated is still in the original 7.1 tree but not here in 7.2/base >>> Which reminds me, I still have 6.x cleanups left to do... :-/ >> Let me know what you're still syncing from me for RSEL6. I could >> probably clean some on my side and start a new updates-testing repo. > > I am currently syncing: > /Redsleeve6/raspberrypi/ -> /var/ftp/pub/el6-staging/rootfs/ AHA, that's where the raspberrypi kernels are. Can you move this out of the rootfs tree? Even I could not find this. > /Redsleeve6/Redsleeve6.7 /var/ftp/pub/el6-staging/6.7/ > > I guess this ^^^ is now static, synced and re-signed, so I can drop it > from the sync as any updates will be going to updates, which is the > next entry below? Yes. And I can then consequently drop it from my server. > /Redsleeve6/Redsleeve6.7-updates /var/ftp/pub/el6-staging/6.7/ Is this not identical to /var/ftp/pub/el6/6.7/updates/ ? And could similarly be dropped? > /Redsleeve6/odroid/ /var/ftp/pub/el6-devel/ Please move next to the raspberrypi tree. Both are kernels for specific SOCs > /Redsleeve6/rootfs/ /var/ftp/pub/el6-devel/ I'm getting a bit confused. what's the difference between staging and devel? I just made a dummy /Redsleeve6/Redsleeve6.7-updates-testing In due course I'll make new RSEL6.7 updates available here. Jacco _______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
