In reply to @timlinux:osgeo.org

wcohenunfortunately I left the macOS ecosystem after dabbling in it for 5 years of so, so I can't help much

In reply to @nh2:matrix.org
Then they aren't fit for Hydra, we need to disable them.
I asked in the ticket which ones those are.

In reply to @imincik:matrix.org
I would be very happy if we could identify and disable couple of tests which are more likely to fail, but I would feel very uncomfortable to disable all of them.

In reply to @nh2:matrix.org
Ivan Mincik (imincik): Yes, we should not disable all tests just because some are flaky.
But we should disable all tests that are flaky in any way. Flaky tests cause huge problems: Disabling a large amount of nixpkgs packages, wasting time on Hydra and 1000x that time on users' computers, as well as contributor time.
Fixing flaky tests is an upstream responsibility; we should report the flakiness, disabled them in nixpkgs, and let upstream solve it (or help with that if we have the time).

In reply to @nh2:matrix.org
Ivan Mincik (imincik): Yes, we should not disable all tests just because some are flaky.
But we should disable all tests that are flaky in any way. Flaky tests cause huge problems: Disabling a large amount of nixpkgs packages, wasting time on Hydra and 1000x that time on users' computers, as well as contributor time.
Fixing flaky tests is an upstream responsibility; we should report the flakiness, disabled them in nixpkgs, and let upstream solve it (or help with that if we have the time).

In reply to @imincik:matrix.org
Let's create PR where we start disabling all gdal tests which we see failing, keep it open for at least one month and then merge. Repeat if needed. What do you think?

In reply to @vengmark2:matrix.org
By the way, do we have some sort of simple upstream feedback mechanism? Passing flaky tests onto upstream should hopefully result in less flaky tests.

In reply to @vengmark2:matrix.org
By the way, do we have some sort of simple upstream feedback mechanism? Passing flaky tests onto upstream should hopefully result in less flaky tests.

In reply to @imincik:matrix.org

Hi autra , you are very welcome to join. You can learn as you go, start from simple things like reviewing version bumps. I can also provide some onboarding sessions if you are interested.

Please, add yourself to Nixpkgs team list and create a pull request with short introduction of yourself and assign it to me for review. Looking forward to see you around.

In reply to @autra:trancart.eu
done! https://github.com/NixOS/nixpkgs/pull/327419

In reply to @autra:trancart.eu
Ivan Mincik (imincik): when you have build failure on dependant packages (like for geopandas), do you fix them in the same PR? Or do you open subsequent PRs?

Can be fixed in the same PR or in a new one. Doesn't matter too much. If you personally want to fix some of failures reported in geopandas PR it might be better to open a new PR rather then pushing in PR created by me.

We also ignore failures if we know that they are not caused by current PR. For example, packages like bsuite or plotnine are broken very often because of something else.