Review @paparodeo ?

not sure if ignoring the test failure is the right thing to do here. updating the package perhaps tho the patch(s) need to get fixed.

I don't want to maintain this package. I'm doing minimal change to avoid false positives in builds. In this regard, I think this change is fine.

I cannot properly test the upgrade of this package since I have no context of it.

marking it broken makes more sense to me. it seems like it needs to be somewhat in sync with mapnik. I tried to just update it but it failed to compile and all the things seemed to be at synced versions.

anyway, I also don't care about the package but think that marking broken is preferable to marking a possibly broken package as working.

@paparodeo I agree the sensible thing to do is to mark broken. But unfortunately, many people at nixpkgs force contributors to fix packages which they don't understand or have context of. I think, reporting a false positive build dependency as broken should have a low barrier, and contributors should not be forced into fixing things that do not concern them. And this should not be frowned upon.

I actually wanted to remove all these unmaintained packages. Either someone steps up to maintain, or these packages should be made inactive (since they are broken).

CC @hummeltech @Dettorer

Would you have an interest in this package?
(Found your handles from Git History that bumped/altered this package locally.)

Maybe @NixOS/geospatial ?

Yeah, marking is broken is fine by me. I don't really use it, so I might not be the best maintainer, but it looks like there might soon be a new release.
mapnik/python-mapnik@10315a6

Yeah, marking is broken is fine by me. I don't really use it, so I might not be the best maintainer, but it looks like there might soon be a new release. mapnik/python-mapnik@10315a6

the new release doesn't compile (and it doesn't seem they ever lose the beta suffix).

CC @hummeltech @Dettorer

Would you have an interest in this package? (Found your handles from Git History that bumped/altered this package locally.)

In principle why not, but same as hammeltech, I don't really us it these days (I did for a small personal project that's on hiatus, like personal projects tend to end up). And more importantly, I really don't have the time right know, but I'll see if this still needs a nixpkgs maintainer once my schedule clears up a bit (in a few months hopefully).

I also think we should mark this as broken:

• upstream is currently undergoing a big rewrite, at least in the build process
• they don't give us a clear release compatible with the current mapnik version in nixpkgs. We are doing guessworks.

I've tried fixing it, but didn't manage to, probably because I don't have the correct commit. As I'm not using it either, I won't be spending more time on this. For those interested, here is my wip.

I think we can also add the geospatial team as maintainers. If someone fixes it, they'd have someone to ping for the review.

Successfully created backport PR for staging-24.11:

• [Backport staging-24.11] python3Packages.python-mapnik: mark broken #359346

I also think we should mark this as broken:

• upstream is currently undergoing a big rewrite, at least in the build process
• they don't give us a clear release compatible with the current mapnik version in nixpkgs. We are doing guessworks.

I've tried fixing it, but didn't manage to, probably because I don't have the correct commit. As I'm not using it either, I won't be spending more time on this. For those interested, here is my wip.

I think we can also add the geospatial team as maintainers. If someone fixes it, they'd have someone to ping for the review.

Thanks for investigating. I agree with you .