Re: [Scons-dev] RPM helper functions, where should they go?
On 25.09.2012 20:03, Gary Oberbrunner wrote: On Tue, Sep 25, 2012 at 1:38 PM, Dirk Bächle wrote: Hi there, for fixing the current Buildbot failures I still have to fight down several RPM tests. They check the names of the created RPM files I think many of the current tests are way too strict in how they test the build output. They could achieve the same goals (success/failure) but be a lot more resistant to path changes, drive name changes and even language changes if we just check the output for certain key words. Plus it makes the tests simpler to create and maintain. Would that help here? We'll probably end there anyhow, once the number of Buildslaves is going up again. ;) Right now, the showstopper is the check in line 89 of SCons/Tool/rpm.py. Should I rather remove it, instead of mimicking all the RPM stuff? My suggestion would be a new file "rpmrc.py" in the SCons/Tools dir, alongside the "rpm.py" tool. Does this make sense or do we have a better place? I think since it is tool-specific, putting it in SCons/Tools is best -- it shouldn't go up in the core. You could call it rpmutils.py perhaps? I called it "rpmrc", because that's the name of the file in the RPM sources. But "rpmutils" would be fine with me too. P.S.: For cases like this it would be cool to have a "scons-common" package with stuff that can get used by SCons itself, the test framework and perhaps even Parts. It could offer basic things like "starting processes, is-this-a-list?" and similar stuff, which are partly spread over the whole codebase in different variations... Util.py has some of this, but indeed not all of it. In my experience, trying to define what's "basic" in your sense above is trickier than it seems. But I also agree there is some duplication that should be eliminated -- not all that much though, right? Yes, I think we're still good with what we have right now. It was more like a mental note to myself, just thinking out loud. While skimming through all the test stuff and the source, I stumbled over a few places and had a little deja-vu experience...that's all. Regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] RPM helper functions, where should they go?
On Tue, Sep 25, 2012 at 1:38 PM, Dirk Bächle wrote: > Hi there, > > for fixing the current Buildbot failures I still have to fight down several > RPM tests. They check the names of the created RPM files I think many of the current tests are way too strict in how they test the build output. They could achieve the same goals (success/failure) but be a lot more resistant to path changes, drive name changes and even language changes if we just check the output for certain key words. Plus it makes the tests simpler to create and maintain. Would that help here? >, which differ > depending on the used hardware/os combination. > I'd like to wrap the original RPM functions for canonicalizing > machine/system names and all the supporting stuff to a Python module, but I > can't make up my mind about where the file should go. > It should be possible to import it from the RPM/packaging stuff and the test > suite in QMTest as well. > > My suggestion would be a new file "rpmrc.py" in the SCons/Tools dir, > alongside the "rpm.py" tool. > Does this make sense or do we have a better place? I think since it is tool-specific, putting it in SCons/Tools is best -- it shouldn't go up in the core. You could call it rpmutils.py perhaps? > P.S.: For cases like this it would be cool to have a "scons-common" package > with stuff that can get used by SCons itself, the test framework and perhaps > even Parts. It could offer basic things like "starting processes, > is-this-a-list?" and similar stuff, which are partly spread over the whole > codebase in different variations... Util.py has some of this, but indeed not all of it. In my experience, trying to define what's "basic" in your sense above is trickier than it seems. But I also agree there is some duplication that should be eliminated -- not all that much though, right? -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] RPM helper functions, where should they go?
Is there any relationship with the RPM functions in tools/packaging/rpm.py?? Personally I like the idea of an independent RPM tool from the packaging logic. Jason -Original Message- From: scons-dev-boun...@scons.org [mailto:scons-dev-boun...@scons.org] On Behalf Of Dirk Bächle Sent: Tuesday, September 25, 2012 12:39 PM To: SCons developer list Subject: [Scons-dev] RPM helper functions, where should they go? Hi there, for fixing the current Buildbot failures I still have to fight down several RPM tests. They check the names of the created RPM files, which differ depending on the used hardware/os combination. I'd like to wrap the original RPM functions for canonicalizing machine/system names and all the supporting stuff to a Python module, but I can't make up my mind about where the file should go. It should be possible to import it from the RPM/packaging stuff and the test suite in QMTest as well. My suggestion would be a new file "rpmrc.py" in the SCons/Tools dir, alongside the "rpm.py" tool. Does this make sense or do we have a better place? Best regards, Dirk P.S.: For cases like this it would be cool to have a "scons-common" package with stuff that can get used by SCons itself, the test framework and perhaps even Parts. It could offer basic things like "starting processes, is-this-a-list?" and similar stuff, which are partly spread over the whole codebase in different variations... ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
[Scons-dev] RPM helper functions, where should they go?
Hi there, for fixing the current Buildbot failures I still have to fight down several RPM tests. They check the names of the created RPM files, which differ depending on the used hardware/os combination. I'd like to wrap the original RPM functions for canonicalizing machine/system names and all the supporting stuff to a Python module, but I can't make up my mind about where the file should go. It should be possible to import it from the RPM/packaging stuff and the test suite in QMTest as well. My suggestion would be a new file "rpmrc.py" in the SCons/Tools dir, alongside the "rpm.py" tool. Does this make sense or do we have a better place? Best regards, Dirk P.S.: For cases like this it would be cool to have a "scons-common" package with stuff that can get used by SCons itself, the test framework and perhaps even Parts. It could offer basic things like "starting processes, is-this-a-list?" and similar stuff, which are partly spread over the whole codebase in different variations... ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
[Scons-dev] Cache
I've been having a problem recently where stuff is not being copied from the cache, so I put some extra trace into FS.get_cachedir_bsig to try and find out what was going on, and I'm getting this sort of thing: Creating the .o file (tries to push to the cache twice) CachePush(thing/unittest/test.o): 3e0cf. CachePush(thing/unittest/test.o): 3e0cf. Using the .o file: Child thing/unittest/test.o sig eca.. which produces this: CachePush(thing/unittest/test_mangled): 65cd... when that is used Child thing/unittest/test_mangled sig e265... The differeng signatures seem odd. What is more, if I'm using a repository (which seems to be part of the issue here) which is in a user dependant location, and I do the build using the other location, the .o file behaves as expected, but the mangled file does something odd: Find the .o file: Retrieved `thing/unittest/test.o' from cache CacheRetrieve(thing/unittest/test.o): retrieving from 3e0c... using the .o file Child thing/unittest/test.o sig eca... Finding the mangled file CacheRetrieve(thing/unittest/test_mangled): retrieving from 65cd But using the mangled file gets this: Child thing/unittest/test_mangled sig d5bf Which causes the thing that depends on test_mangled not to be pulled from the cache. Any suggestions? ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
