treewide: start marking packages broken #173671
Conversation
Mindavi
force-pushed
the
treewide/broken-zhf
branch
from
ddc6f2b
to
6ac60b6
Compare
ofborg
bot
added
8.has: clean-up
10.rebuild-darwin: 0
| @@ -1,4 +1,4 @@ | |||
| { lib, buildGoPackage, fetchFromGitHub }: | |||
| { stdenv, lib, buildGoPackage, fetchFromGitHub }: | |||
|
|
|||
| buildGoPackage rec { | |||
| pname = "awless"; | |||
There was a problem hiding this comment.
Bluntly said unfortunately, this project has stopped, no development is done on it and it is not worth submitting PRs. I was a contributor but I am no longer in the company (Wallix)
2021-06-02
last commit was 2018-12-10!
I think we should probably remove awless
The maintainers of this derivation haven't committed to nixpkgs since 2017 and 2019 respectively although @swdunlop has commented recently so 👋
Any thoughts?
There was a problem hiding this comment.
Awless still works, it just doesn't understand any AWS features newer than 2018. I do not know why it stopped, outside of the comments we see in wallix/awless#297. I will dig in, see if I can root out why x/sys/unix is not building on linux-aarch64 with Go 1.17.10 and how wide the damage is.
There was a problem hiding this comment.
The dependencies are super old and who knows what vulnerabilities are in there since most scanners dont consume dep format
There are packages that have had commits in the last 2 years we've dropped as unmaintained, this one is almost 4
If someone wants to migrate it to go modules and update the dependencies then sure
There was a problem hiding this comment.
Opened #173792 to limit Awless to remove linux-aarch64 from the set of platforms. A better change would be to revise the upstream project to use a newer version of x/sys/unix, but there is a good likelihood that we will find a regression since x/sys/unix does not guarantee backward compatibility.
Lesson learned -- I'll watch https://zh.fail instead of just running maintainer tests on the builders I have. :)
There was a problem hiding this comment.
The dependencies are super old and who knows what vulnerabilities are in there since most scanners dont consume dep format
There are packages that have had commits in the last 2 years we've dropped as unmaintained, this one is almost 4
If someone wants to migrate it to go modules and update the dependencies then sure
Sorry, I thought this was related to ZHF. If this was really about airing frustration about awless not being updated for years, I agree. But I do not have the resources or time for a hard fork of someone else's project.
There was a problem hiding this comment.
ZHF means the packages that are broken come into view. When looking at the derivation and the upstream project you review if its just better to drop it as unmaintained rather than mark it broken
If you as the maintainer want to keep it then fair enough. I dont think there's an explicit nixpkgs policy around dead projects
There was a problem hiding this comment.
Yeah, either mark it broken and remove in 1-2 releases if nothing happens, or just drop immediately.
This comment was marked as outdated.
This comment was marked as outdated.
ghost
mentioned this pull request
|
FYI @06kellyjac I wasn't planning on pinging maintainers, I'd say that ZHF should have pinged them already and if they didn't respond to that it doesn't make much sense to try and get their attention again here. But of course, feel free to do so anyway if you think that's still valuable. |
Mindavi
force-pushed
the
treewide/broken-zhf
branch
from
6ac60b6
to
2b87ba2
Compare
Mindavi
force-pushed
the
treewide/broken-zhf
branch
from
2b87ba2
to
8fedfb5
Compare
|
I dont think anything so-far related to ZHF has actually pinged maintainers. Only the maintainers actively watching the issue, running the Hydra check scripts, checking the new website tracker, will have seen which of their packages are broken. |
Mindavi
force-pushed
the
treewide/broken-zhf
branch
from
e7c897c
to
ce2d57e
Compare
| # x86_64-linux: | ||
| # dbwrapper.h:26:49: error: ISO C++17 does not allow dynamic exception specifications | ||
| # void HandleError(const leveldb::Status& status) throw(dbwrapper_error); | ||
| broken = stdenv.isDarwin || (stdenv.isLinux && stdenv.isx86_64); |
Mindavi
force-pushed
the
treewide/broken-zhf
branch
from
ce2d57e
to
9b180bf
Compare
Mindavi
force-pushed
the
treewide/broken-zhf
branch
from
9b180bf
to
fc541e6
Compare
IMO we shouldn't ping hundreds of people just to mark things for aarch64-linux or x86_64-darwin broken. If we mark things for everything broken we could. If something is broken for longer than 6/12 months I don't think we should ping anyone. |
|
cc @ajs124, do you have anything prepared (in your stash or somewhere) that is worth picking onto this PR? |
|
Don't think so. You can consult #174634 if you're thinking about marking something as broken or removing it, I guess? That way you'd know if I'd have removed it, if you're interested in that, for some reason. Also, I think #174103 marked most of the kernel modules as broken, that are still listed here. |
Marked as broken by NixOS#173671 but builds and works fine on darwin, with sandbox enabled.
Marked as broken by NixOS#173671 but builds and works fine on darwin, with sandbox enabled.
Marked as broken by NixOS#173671 but builds and works fine on darwin, with sandbox enabled.
Marked as broken by NixOS#173671 but builds and works fine on darwin, with sandbox enabled.
Marked as broken by NixOS#173671 but builds and works fine on darwin, with sandbox enabled.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/why-is-swift-marked-as-broken/20889/2 |
Description of changes
Start marking some packages as broken as part of the end of ZHF: #172160.
I think we can keep this open until ZHF is over and merge then?
Or should we pick some starting letters or so and go letter by letter?
Things done
Made a script for listing all builds with their status. It's
very slownot very fast but should do the job: https://gist.github.com/Mindavi/6b33251a3a7a207e95d0ca289da312cb. I'll make a list of all (currently failing) packages so we can work through this.