elieux on main
HISTORY: Write down actual work… (compare)
github-actions[bot] on srcinfo-cache
Add libcue static lib Build bo… Merge pull request #8063 from d… (compare)
github-actions[bot] on srcinfo-cache
Add libreplaygain package Merge pull request #8064 from d… (compare)
lazka on master
Add libcue static lib Build bo… Merge pull request #8063 from d… (compare)
github-actions[bot] on srcinfo-cache
Add sidplayfp package Update mingw-w64-sidplayfp/PKGB… Merge pull request #8062 from d… (compare)
lazka on master
Add libreplaygain package Merge pull request #8064 from d… (compare)
github-actions[bot] on srcinfo-cache
hwloc: update Merge pull request #8060 from 3… (compare)
lazka on master
Add sidplayfp package Update mingw-w64-sidplayfp/PKGB… Merge pull request #8062 from d… (compare)
are git-bash.exe is mingw program?
Yes. They are in the root directory because otherwise users would not discover them in, say, a Portable Git.
git-cmd
.)
@mingwandroid, WRT :point_up: January 10, 2021 11:27 PM no worries, I'm not in a rush to have it done, just slightly annoyed/frustrated because finding the workaround is being harder than packaging several other tools. Hope they let you out soon! (despite not having much outside to go to :S)
Thanks @umarcor , I am back now. I must say that the Spanish health service took good care of me, despite my sorely lacking Spanish language skills. I will not say too much about the food, because as my dear Mum often says "if you can't say something nice it's best to say nothing at all" ;-)
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?
@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.
@mingwandroid, personally, I would be happy to hear your thoughts about this parallel/concurrent packaging approach:
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.