Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 11:22
    mstorsjo commented #2294
  • 11:16
    mati865 commented #2294
  • 11:16
    mati865 commented #2294
  • 10:08
    naveen521kk synchronize #31
  • 09:46
    naveen521kk synchronize #31
  • 09:45
    mstorsjo commented #2294
  • 09:16
    carlkl commented #8317
  • 09:16
    carlkl commented #8317
  • 09:11
    carlkl commented #8317
  • 08:56

    github-actions[bot] on master

    Cygwin: console: Fix race issue… Cygwin: pty: Fix race issue in … Cygwin: pty: Make rlwrap work w… and 1 more (compare)

  • 08:39

    github-actions[bot] on srcinfo-cache

    Lowercase all perl package name… perl packages: rebuild Merge pull request #8430 from l… (compare)

  • 08:30

    lazka on master

    Lowercase all perl package name… perl packages: rebuild Merge pull request #8430 from l… (compare)

  • 08:30
    lazka closed #8430
  • 08:21
    Biswa96 ready_for_review #8424
  • 08:21
    Biswa96 synchronize #8424
  • 08:06
    lazka commented #8430
  • 08:03
    Astrum-polaris synchronize #8393
  • 07:58
    Astrum-polaris synchronize #8393
  • 07:39
    Biswa96 synchronize #8424
  • 07:38

    github-actions[bot] on srcinfo-cache

    libgme: cherry pick a few GBS f… Merge pull request #8431 from d… (compare)

loonycyborg
@loonycyborg:matrix.org
[m]
I don't see why not
I'm not sure what exact purpose of those three repos(like msys vs mingw-w64) but packages from them can be installed in parallel
Christopher Degawa
@1480c1
The mingw64 repo is for native 64 bit windows programs compiled by mingw-w64-x86_64-gcc (for the most part), mingw32 is native 32-bit windows program, msys is for cygwin like packages that is either tied too closely to posix that it won't compile or work as intended if compiled to windows (like bash) or programs that don't need a native equivalent (like nano, although there are exceptions such as cmake etc which are in there mainly because other things need them)
in order of preference on which to download, it should be mingw{64,32} and then msys
umarcor
@umarcor

Random thought. Is it possible to create a bot in github which will comment when a issue is fixed and the package is uploaded?

@Biswa96, it's pretty trivial to comment/open/close issues in GitHub using any library for interacting with the API, such as octokit (js) or pyGitHub (Python). However, I did not understand where do you want the comment to be posted. Can you please clarify?

umarcor
@umarcor
@syarif-hsb in https://hdl.github.io/MINGW-packages/#_usage a few quotes from msys2.org are shown and referred, which explain exactly what @1480c1 said. Even though it is explicitly explained in the docs, I find many users confused about that, so I tried to make it as short and direct as possible.
Ray Donnelly
@mingwandroid
@umarcor nicely written site! Very useful for any other project who'd like to upstream stuff too.
umarcor
@umarcor

@mingwandroid thanks so much. I'm glad you liked it. In fact, I tried not to duplicate the content of msys2's docs, so that my "workflow guidelines" can be potentially moved there in the future. Yet, I'm still shaping and reworking my own workflow, so it's pretty organic work in progress for now. E.g. it was initially a fork of MINGW-packages, but then lazka could not edit the PRs because he was not a member of that org, so I had to fall back to using my personal fork for PRs. Overall, I think it can be interesting to create documentation for "packager camps" in the MSYS2 ecosystem, which can offload the main maintainers from niche issues related to multiple packages in some area. This is already done in larger teams, such as Debian or Fedora. In both cases, there is an EDA related group of tools and people.

Noticed a broken link though: https://github.com/hdl/smoke-tests/blob/main/CONTEXT.md

Thanks for pointing that out! 'HDL' is undergoing some fast and disruptive changes, because we are aiming at bringing together packagers from different EDA tooling camps. https://github.com/hdl/packages was a created a couple of days ago, and the context is now located there. I will fix the broken link.
BTW, you might find all the litex-conda-* packages interesting/exciting or maybe infuriating ( :laughing: ), due to your background. Those are soon to be transferred from litex-hub to hdl.

umarcor
@umarcor

@mingwandroid, personally, I would be happy to hear your thoughts about this parallel/concurrent packaging approach:

  • MINGW-packages (+ pip with a little mouth :blush: ).
  • Conda.
  • Containers (Docker/Podman).

My hope is that different people can take care of each of those approaches, but handle it so that users can pick any of them as their "system/tooling management solution". That is, "project management scripts for hdl designs" should be able to use tools installed using any of those methods/ecosystems.

Ray Donnelly
@mingwandroid
Yeah, interesting stuff. There's the R world and Julia also to consider! We have MSYS2 packages in conda to help with building stuff mostly, and also for R but it is out of date. Actually Anaconda Inc. are looking for people to work on this kind of thing if anyone was interested in doing it professionally.
I will check out litex-conda-*!
Conda-forge would probably love someone to update MSYS2-in-conda and automate the continual update of the same, too.
I lost the scripts I wrote in 2016 that I used to do the original import. I added libalpm packages to conda as I remember and parsed the MSYS2 metadata. Now-a-days, I'd rather conda-forge built MSYS2 packages from source using the PKGBUILDs.
Ray Donnelly
@mingwandroid
I worked with Tim Ansell before actually. He helped us to get our linux-64 compilers in shape in a few ways.
I do like the idea of having sub-teams contribute to MSYS2. I see gnome and HDL as two we kind of have already.
Then there's the real compiler engineers helping tremendously, so glad I don't have to mess with that stuff these days :-)
umarcor
@umarcor

@mingwandroid

There's the R world and Julia also to consider!

Yes. However, the language of choice in EDA is Python (probably for the following couple of decades at least). It was TCL for 2-3 decades, and many vendor tools do still only support TCL for scripting. Hence, there is a long way yet until "too modern" environments such as R or Julia meet EDA.

We have MSYS2 packages in conda to help with building stuff mostly, and also for R but it is out of date.
Conda-forge would probably love someone to update MSYS2-in-conda and automate the continual update of the same, too.
I lost the scripts I wrote in 2016 that I used to do the original import. I added libalpm packages to conda as I remember and parsed the MSYS2 metadata. Now-a-days, I'd rather conda-forge built MSYS2 packages from source using the PKGBUILDs.

I'm not following you completely, but it sounds quite exciting. Did I understand correctly and you are suggesting it's possible to use MSYS2 packages (or recipes), and have them wrapped in Conda? Is that for Windows targets only, or would the same apply for Linux targets (using Arch's recipes)?

I worked with Tim Ansell before actually. He helped us to get our linux-64 compilers in shape in a few ways.

The litex-conda stuff is actually being done by people from Antmicro, who are working with mithro in SymbiFlow. In fact, those litex-conda packages were located in SymbiFlow and Antmicro orgs, they were merged into litex-hub and now are to be moved into hdl.

Actually Anaconda Inc. are looking for people to work on this kind of thing if anyone was interested in doing it professionally.
Conda-forge would probably love someone to update MSYS2-in-conda and automate the continual update of the same, too.

Just to clarify, do you mean someone working on allowing any user to have Windows targets in Conda "for free" as long as the project/tools exists on MSYS2 repos?

Ray Donnelly
@mingwandroid
on conda on Windows you can already do e.g conda install m2-bash yeah.
But it installs really old packages so we need to fix that (both my company and conda-forge, the open source community effort who are our upstream).
umarcor
@umarcor
By looking at https://anaconda.org/search?q=m2-, essentially all the MSYS2 packages were "wrapped" 4 years ago?
So, you were not referring a manual procedure, but to something similar to MSYS2 autobuilder which would generate Conda m2- packages, isn't it?
Ray Donnelly
@mingwandroid
Something automatic yes. We call it binary-repackaged at my place but yes, wrapped works too.
We'd prefer from source builds of the PKGBUILDs inside the conda recipe to repackaging.
Christopher Degawa
@1480c1
I just realized something that might be something I have a problem against, in the start menu, msys2 shows up as MSYS2 MinGW {64,32}-bit referring to MinGW instead of mingw-w64
along with the MSYS2 MSYS one since technically msys also is from MinGW
Ray Donnelly
@mingwandroid
Yeah, we should fix that IMHO.
Christoph Reiter
@lazka
it refers to the msys2 subsystem
David Macek
@elieux
Then maybe it should be called the same as inside (and everywhere else).
Christoph Reiter
@lazka
yeah
Алексей
@Alexpux
@lazka @elieux I se that some updatea are go to repo but some not
what the reason for it?
Christoph Reiter
@lazka
@Alexpux some failed, others are waiting for those
@Alexpux I'll improve all this shortly
sadly busy at work atm
Алексей
@Alexpux
ok
Christoph Reiter
@lazka
python3 autobuild.py fetch-assets --verbose --pretend _bla shows you why
I'll integrate this information into the website
summary: for a package to be downloadable all its dependencies and reverse dependencies in the queue need to be finished.
Алексей
@Alexpux

python3 autobuild.py fetch-assets --verbose --pretend _bla shows you why

I dont understand output of this command

Алексей
@Alexpux
@dscho there are problems with symlinks in current msys2 runtime
Johannes Schindelin
@dscho
@dscho there are problems with symlinks in current msys2 runtime
  1. What exactly do you want to tell me?
  2. What exactly do you want me to do about it?
Christoph Reiter
@lazka
@Alexpux that's ok. I'll improve things
Christoph Reiter
@lazka
@Alexpux the information is now in the "Status" column here: https://packages.msys2.org/queue
I'll work on the manual package upload next
David Macek
@elieux
What do you mean?
Christoph Reiter
@lazka
hm?
David Macek
@elieux
... by manual package upload.
Christoph Reiter
@lazka
@elieux oh. I was planning to have a "autobuild.py upload-assets" command so alexey can upload some packages CI can't handle.
David Macek
@elieux
Oh. Cool.