Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 04:02
    MehdiChinoune closed #10209
  • 03:26
    p-tezzie opened #10284
  • 02:21
    hoodar opened #10283
  • 00:33
    stahta01 commented #10088
  • Dec 06 22:13
    JPeterMugaas closed #10274
  • Dec 06 22:13
    JPeterMugaas commented #10274
  • Dec 06 21:19
    JPeterMugaas synchronize #10274
  • Dec 06 21:10
    1480c1 commented #1030
  • Dec 06 20:36
    okhlybov commented #10209
  • Dec 06 20:28
    okhlybov commented #10209
  • Dec 06 19:40

    lazka on master

    Libgsf: add read support for zi… Add a comment with a link to th… Merge pull request #10281 from … (compare)

  • Dec 06 19:40
    lazka closed #10281
  • Dec 06 19:36
    podsvirov synchronize #10258
  • Dec 06 19:30
    podsvirov commented #10258
  • Dec 06 18:23
    jeremyd2019 commented #10235
  • Dec 06 18:20
    eine commented on cb12d00
  • Dec 06 18:17
    jeremyd2019 commented on cb12d00
  • Dec 06 18:15

    eine on master

    bump dependencies (compare)

  • Dec 06 18:13
    jeremyd2019 commented #2678
  • Dec 06 18:05

    dependabot[bot] on npm_and_yarn

    (compare)

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
I don't think appveyor was different here, but not 100% sure
@Alexpux fyi, we have package file diffs in CI now: https://github.com/msys2/MINGW-packages/runs/1680015924#step:5:4342
Алексей
@Alexpux
ok so i nedd push commits one buy one seems
Christoph Reiter
@lazka
yes, that would work.
but CI should still build everything inbetween, shouldn't it?
Алексей
@Alexpux
yes
Christoph Reiter
@lazka
oh, looks like it doesn't
Алексей
@Alexpux
yes it doesnt build everything
it build only last commit
if i push multiple commits