Re: [RFC PATCH v3 00/15] Modernize the build system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 24/10/2024 08:19, Patrick Steinhardt wrote:
> On Wed, Oct 23, 2024 at 03:38:18PM +0100, Ramsay Jones wrote:
>>> Do any of the versions used maybe differ?
[snip]
> Oh, wait! I can see that there's a "python3" 3.9.18 available as a
> testing version. I don't quite understand how this works though, because
> when I install it I still have Python 3.9.16. Seems like there are two
> Python packages: "python3", which has the 3.9.18 test version, and then
> there's "python39", which only has 3.9.16. The first one just seems to
> be a meta package, so it doesn't contain anything.
> 
> So... where did you get Python 3.9.18 from? You mentioned that it also
> hogs all CPU, so could it be that this is basically a broken Python
> installation?

Hmm I have no idea how my python installation got messed up (I never try
to install TEST packages, but I do just install anything that is in the
'pending' page without even thinking!).

Last night I remembered that when installing something recently on windows
it also (without even asking) installed a windows python as well, but that
is hidden due to my path ...

  $ /cygdrive/c/Users/ramsay/AppData/Local/Programs/Python/Python312/python --version
  Python 3.12.4
  $

My current python packages (which include many obsolete python2 packages)
looks like:

  $ cygcheck -c python
  Cygwin Package Information
  Package              Version    Status
  python               3.0.0-1        OK
  $ cygcheck -c python3
  Cygwin Package Information
  Package              Version    Status
  python3              3.9.18-1       OK
  $ which python python3
  /usr/bin/python
  /usr/bin/python3
  $ python --version
  Python 3.9.18
  $ python3 --version
  Python 3.9.18
  $

Go away and wrangle with setup.exe ...

  $ python --version
  Python 3.9.16
  $ python3 --version
  Python 3.9.16
  $ which python python3
  /usr/bin/python
  /usr/bin/python3
  $ cd git
  $ mkdir build
  $ cd build
  $ meson setup .. -Dprefix=$HOME
  ...
  git v2.47.GIT
  
    User defined options
      prefix: /home/ramsay
  
  Found ninja-1.12.0 at /usr/bin/ninja
  $ ninja
  [699/699] Linking target t/helper/test-tool.exe
  $ meson test 't000*'
  ninja: Entering directory `/home/ramsay/git/build'
  ninja: no work to do.
  1/9 t0002-gitfile           OK             10.52s
  2/9 t0004-unwritable        OK              6.78s
  3/9 t0005-signals           OK              5.96s
  4/9 t0003-attributes        OK             54.40s
  5/9 t0006-date              OK             31.39s
  6/9 t0001-init              OK             61.68s
  7/9 t0007-git-var           OK             12.93s
  8/9 t0008-ignores           FAIL           106.29s   exit status 1
  >>> PATH='/home/ramsay/git:/usr/bin:/usr/bin:/usr/bin:/usr/bin:/home/ramsay/bin:/usr/bin:/usr/bin:/home/ramsay/bin:/home/ramsay/bin:/usr/local/bin:/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Users/ramsay/AppData/Local/Programs/Python/Python312/Scripts:/cygdrive/c/Users/ramsay/AppData/Local/Programs/Python/Python312:/cygdrive/c/Users/ramsay/AppData/Local/Programs/Python/Launcher:/cygdrive/c/Users/ramsay/AppData/Local/Microsoft/WindowsApps:/usr/lib/lapack' MALLOC_PERTURB_=105 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 GIT_BUILD_DIR=/home/ramsay/git/build /usr/bin/sh t0008-ignores.sh
  
  9/9 t0000-basic             OK             193.52s
  
  Ok:                 8
  Expected Fail:      0
  Fail:               1
  Unexpected Pass:    0
  Skipped:            0
  Timeout:            0
  
  Full log written to /home/ramsay/git/build/meson-logs/testlog.txt
  $
 
So, a big improvement! :)

Having a quick squint at the failure, it '# failed 1 among 397 test(s)'
which was 'not ok 391 - correct handling of backslashes', which is the
only test marked with a '!CYGWIN' prerequisite! ;) So it seems that I
am doing something wrong, which results in the prerequisite not being
set.

I haven't debugged that yet, but I wanted to note the above improvement
having 'fixed' my python installation. (It doesn't look good for the
TEST package! :) ).

Thanks!

ATB,
Ramsay Jones
 `





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux