Hi Daniel, Thanks for the reply an upload and especially for helping me realize that there is a real problem in the tool itself and not only in the test suite.
I am going to address the environment issue for the next release, using your guidelines. Dne 09.11.2024 (sob) ob 22:24 +0100 je Daniel Gröber napisal(a): > Hi Samo, > > On Fri, Oct 25, 2024 at 03:09:04PM +0200, Samo Pogačnik wrote: > > I prepared initial update of our package against newer upstream release > > 0.4.9 > > in: https://salsa.debian.org/spog/git-subrepo/-/tree/debian/sid > > > > You may inspect the salsa pipeline build in > > https://salsa.debian.org/spog/git-subrepo/-/tree/debian/sid_force, where > > changelog has also been committed. > > You don't have to do it like that, you can commit the changelog entry as > UNRELEASED to the debian/sid branch without any process problems. Avoid > setting the distribution to unstable however as sponsor will usually do > that :-) > I'll try that next time. > > I notified upstream about the update via a new pull request and informed > > them of what we are trying to achieve. > > It's good to link to the discussion: > https://github.com/ingydotnet/git-subrepo/pull/637 > ok > You make no mention of the test environment hacks just hiding the real > problem. Personally I couldn't use git-subrepo in it's current state > because my config is actively interfering as we've seen and frankly it's > also not making me very enthusiastic about continuing to work on the Debian > package as I consider this state basically unfit for release. > > I have half a mind to open an RC bug against git-subrepo to keep it out of > testing until this is resolved but I don't want your hard work to go to > waste. > thanks > The tests are still very slow (feels like they got slower still since last > time): > > > Files=39, Tests=341, 320 wallclock secs ( 0.15 usr 0.05 sys + 43.01 cusr > > 32.41 csys = 75.62 CPU) > > 320 seconds, 5+min! > > Only seems to happen in the sbuild chroot, debuild is way faster (64 secs) > but some tests fail instead probably due to the known enviornmental issues. > This is a mystery to me. I currently can not make a bookworm environment for sbuild chroot, to repeat the problem. I tried debuild on a borrowed bookworm container and tests run fast. > Please have a look at how we can mitigate the environment problem properly > in git-subrepo without hacks in the testsuite (or get upstream to do it ;) > > I think the right way to go about that would be to send a PR with failing > tests demonstrating the problem. I believe all you need is in my previous > mail dissecting what config is causing the issue: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078960#25 > > There's an existing upstream issues you can reference too: > https://github.com/ingydotnet/git-subrepo/issues/550 > > This shouldn't be too hard -c merge.ff=yes/no -c pull.ff=yes/no in the right > places and we're golden. I'll leave the detailed analysys to you ;P > I'll do a separate upstream PR the merge/pull ff_only problem as suggested and include a patch into next debian release. I still believe that having a predictable test environment for the package build is also important, however it should be the most problematic one for the tool to handle. To achieve that i intend to add an explicit .gitconfig into our temporary HOME with merge/pull-ff_only options enabled. What are your thoughts about this? regards, Samo
