Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:15
    raedrizqie ready_for_review #10287
  • Dec 07 23:55
    raedrizqie synchronize #10287
  • Dec 07 21:15

    lazka on master

    mosquitto: Update to 2.0.14 Re… Merge pull request #10290 from … (compare)

  • Dec 07 21:15
    lazka closed #10290
  • Dec 07 21:14

    lazka on master

    python-nuitka: Update to 0.6.18… Merge pull request #10286 from … (compare)

  • Dec 07 21:14
    lazka closed #10286
  • Dec 07 21:14

    lazka on master

    cmake-doc-qt: Update to 3.22.1 Merge pull request #10289 from … (compare)

  • Dec 07 21:14
    lazka closed #10289
  • Dec 07 21:14

    lazka on master

    cmake: Update to 3.22.1 Merge pull request #10288 from … (compare)

  • Dec 07 21:14
    lazka closed #10288
  • Dec 07 21:11
    lazka commented #10285
  • Dec 07 21:10
    lazka commented #10285
  • Dec 07 21:09
    lazka commented #10168
  • Dec 07 20:50
    MehdiChinoune commented #10288
  • Dec 07 20:50
    MehdiChinoune commented #10288
  • Dec 07 19:16
    1480c1 commented #10209
  • Dec 07 19:12
    1480c1 commented #10209
  • Dec 07 19:09
    podsvirov opened #10290
  • Dec 07 18:44
    podsvirov opened #10289
  • Dec 07 18:27
    podsvirov opened #10288
Unai Martinez-Corral
@umarcor
When contributions are pushed to the git repository, there is a Continuous Integration (CI) service. It's a "virtual machine" in a server, where MSYS2 is installed, the repository is downloaded and the packages are built.
Packages are only built if someone updates them, not all of them are built every day.
fulcobohle
@fulcobohle
@umarcor I am learning every day...
Unai Martinez-Corral
@umarcor
In the case of graphviz, I set up a job that tries to build it weekly.

However, there is a very easy thing you can do for having this tested (viewing something is always easier than imagining...):

  • In your fork of MINGW-packages, create a git branch.
  • In that git branch, edit the pkgrel value of the graphviz PKGBUILD recipe. Just increase it by one.
  • Commit the changes, and push the branch to your fork.

CI will start automatically, and it will attempt to build it. You will then see if it works as it does locally, or whether it fails.

fulcobohle
@fulcobohle
@umarcor What is the difference between my setup and the Cl
Unai Martinez-Corral
@umarcor
Theoretically, there is no difference. But, that's the beauty of computer science! If theory worked, this would all be so boring, isn't it?
fulcobohle
@fulcobohle
@umarcor No not really, we could than make some progress haha
Unai Martinez-Corral
@umarcor
:laughing:
Anyway, as I said some days ago, don't you get stuck with graphviz. It was just one among many possible issues for you to get a feel about how contributing to MSYS2 looks like.
fulcobohle
@fulcobohle
@umarcor Every time I install an update of msys software will fail compiling somewhere. But I like msys non the less.
@umarcor I have not done anything useful yet
Unai Martinez-Corral
@umarcor
That's actually weird I'd say. There are update issues, for sure. But most of the time it is painless here, and problems are typically due to network/signing, not compilation.
fulcobohle
@fulcobohle
@umarcor It is not always an msys related problem, packages change...
Unai Martinez-Corral
@umarcor
Yes, that's the "Arch nature" in MSYS2. I like it that way, tho.
fulcobohle
@fulcobohle
@umarcor What shall I do now, remove the compiler warnings from graphviz and make patches ? And see if this will solve compilation errors. I hate source code with warnings, they will bite you in the b** eventually.
Unai Martinez-Corral
@umarcor
That's up to you. As Alexey said, he had to patch it a lot for to work. Therefore, some/many of the warnings might come from those patches. Then, it would be nice if you want to clean that. Other warnings might come from upstream, tho. Anyway, if you feel like focusing on "removing annoying/potential harmful graphviz/gtk warnings", that's nice!
Typically, what I'd do for working on patches is clone the original repository (graphviz). Create a branch, where I apply the patches and I copy a PKGBUILD recipe there. That allows me to test makepkg-mingw in-place: just edit the sources of graphviz and build. Later, I commit, export the patches and update them in MINGW-packages.
Unai Martinez-Corral
@umarcor
Sometimes, I contribute the PKGBUILD recipe upstream. See, for instance:
fulcobohle
@fulcobohle
@umarcor I will dive into it, if I have questions I will let you know...
Unai Martinez-Corral
@umarcor
Sure! Have fun :wink:
Unai Martinez-Corral
@umarcor
Anyone has some guess about ImportError: DLL load failed while importing pytrellis: %1 is not a valid Win32 application. ? https://github.com/msys2/MINGW-packages/pull/7568/checks?check_run_id=1671268526#step:5:1369
It's coming from msys2/MINGW-packages#7568.
Biswapriyo Nath
@Biswa96

will we create new repos for clang packages?

I would vote for a gcc+ucrt one.

Naveen M K
@naveen521kk
Anyone has some guess about ImportError: DLL load failed while importing pytrellis: %1 is not a valid Win32 application. ?
If thats python then it means mixing of 32-bit and 64-bit DLL files
Ah, gitter is weird on mobile.
Mateusz Mikuła
@mati865

Ah, gitter is weird on mobile.

No, it's just terrible.

Unai Martinez-Corral
@umarcor

If thats python then it means mixing of 32-bit and 64-bit DLL files

@naveen521kk, yes. The problem is that the recipe needs to build some assets which take more than 4GB of memory, so it crashes on MINGW32. I'm calling a MINGW64 bash from the PKGBUILD recipe (https://github.com/msys2/MINGW-packages/pull/7568/files#diff-3e2029a456a188ac9c6af1a1f77cbeabeb85b7ce75bbd7577a98d2b795fba704R53-R55), but it's not doing it properly. The DLLs are installed for both MINGW32 and MINGW64: https://github.com/msys2/MINGW-packages/pull/7568/files#diff-3e2029a456a188ac9c6af1a1f77cbeabeb85b7ce75bbd7577a98d2b795fba704R33-R34. The same recipe works on MINGW64.

Naveen M K
@naveen521kk
Possibly add MINGW64 python as a make dependency in MINGW32. See if that works?
Biswapriyo Nath
@Biswa96
I would suggest not to mix those.
Naveen M K
@naveen521kk
If you do so the python library there will not work.
If its only a makedep then it is ok.
Ray Donnelly
@mingwandroid
You could setup a new sysconfig_blah.py for this cross scenario too ..
easily enough done
Unai Martinez-Corral
@umarcor
@naveen521kk mingw-w64-x86_64-python is already installed, because it's a dependency of mingw-w64-x86_64-prjtrellis: https://github.com/msys2/MINGW-packages/pull/7568/checks?check_run_id=1677639388#step:5:1106

I would suggest not to mix those.

@Biswa96, honestly, I don't like doing it like this. But I think this is better than pushing an intermediate package to MSYS2 which is just to be used while building nextpnr.

So, I thought about creating nextpnr-chipdbs and then make mingw-w64-nextpnr depend on that.

You could setup a new sysconfig_blah.py for this cross scenario too ..

@mingwandroid, there is already a helper script for executing this step (https://github.com/msys2/MINGW-packages/pull/7568/files#diff-5525f40256b3131d3d3c52f57815fb1ca64d76f2bcc3a94cbf41ac9705fe2afd). Yet, I don't see where would sysconfig_blah.py fit in there, since those are just calls to cmake.

Ray Donnelly
@mingwandroid
If you want me to take a look I can, but CMake asks distutils for the details basically
But they keep reworking FindPython.cmake so yeah, YMMV!
I can't look until I get out of this place and back home though
In fact, everything that interfaces with CPython correctly from a build POV asks distutils at the end of the day since that's the only source of truth for how to compile stuff
well, there's numpy too, it has its own stuff but that gets 'copied' from distutils when you build numpy (to a certain extent)
the only other avenue things can reasonably use is to call python-config
Алексей
@Alexpux
Hi!
I start new discussion for Python users here https://github.com/msys2/MINGW-packages/discussions/7646
Алексей
@Alexpux
@lazka hi
Christoph Reiter
@lazka
hi
Алексей
@Alexpux
why CI start building only last commit if I push multiple commits?
Christoph Reiter
@lazka
it only triggers on push