Packages: canutils: Subcomponents do not build after commit 5f9a918c4fe8d3e6e3a29f653204683881ae6f07

[Entropy512]

Maintainer: @neheb
Environment: Latest git master, built on amd64, target for ar750s

Description:

The listed commit states "Revert b70cb0e : that commit was misleading

How is the following misleading?

Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for canutils-asc2log:
 *      canutils
 * opkg_install_cmd: Cannot install package canutils-asc2log.
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for canutils-bcmserver:
 *      canutils
 * opkg_install_cmd: Cannot install package canutils-bcmserver.
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for canutils-canbusload:
 *      canutils
 * opkg_install_cmd: Cannot install package canutils-canbusload.
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for canutils-can-calc-bit-timing:
 *      canutils
 * opkg_install_cmd: Cannot install package canutils-can-calc-bit-timing.
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for canutils-candump:
 *      canutils
 * opkg_install_cmd: Cannot install package canutils-candump.
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for canutils-canfdtest:
 *      canutils
 * opkg_install_cmd: Cannot install package canutils-canfdtest.
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for canutils-cangen:
 *      canutils
 * opkg_install_cmd: Cannot install package canutils-cangen.
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for canutils-cangw:
 *      canutils

Above repeats for every canutils subcomponent that is selected unless DEPENDS:=canutils is removed again

[neheb]

Removing that causes a pointless coreutils metapackage with all of the subpackages to be outside of it.

[Entropy512]

No it doesn't. The current DEPENDS line causes a dependency on a "pointless canutils metapackage" that, in fact, prevents any of the canutils packages from getting installed (as seen in the log snippet shown) because the metapackage is not built/does not exist.

Remove the DEPENDS line and:
No metapackage is built (no change)
No metapackage is required either (change that allows individual canutils packages to be installed)

In the current state of things with that DEPENDS line in there, selecting any canutils component will cause the build to fail at the install stage.

[neheb]

Just tried. I get the same error.

However, removing that line is not the solution.

I will look into a proper one soon.

[neheb]

The commit that broke this was actually 5969273ff40cdf6d90f3442aa6c986226e0a16dc

Adding back the install section fixes everything.

[Entropy512]

I'll take a look at this later this week - at least on first inspection it seems to me like this would do exactly what you were complaining about the other patch doing (creating a useless empty metapackage)?

[neheb]

This has been fixed.

[Entropy512]

So, while it is fixed, I'd like to know why this package was in a broken state for over a month, with the only reason being your provably false assertion that:
"Removing that causes a pointless coreutils metapackage with all of the subpackages to be outside of it."

It is my assumption that "coreutils" above was a typo and you meant to state "canutils"

However, your eventual fix caused the exact "problem" you were stating that you were trying to solve. Prior to you breaking the package, there was no pointless canutils metapackage, because it did not need to exist due to the subpackages not depending on it.

Now, there is pointless empty (no contents in data.tar.gz) canutils metapackage that serves no purpose except to satisfy a dependency that it's already proven does not need to exist. This is exactly what you were previously claiming was unacceptable and "fixing" this was your rationale for breaking the package for more than a month in the first place?

[neheb]

My understanding is that the canutils metapackage pulls in all of the subpackages. That's no longer true if you remove the DEPENDS.

[Entropy512]

Sorry for the slow response, this week has been hectic.

It does not pull in the subpackages.
Prior to removing the DEPENDS:
We had separate packages for the individual utilities (good, because probably 90% of people only want candump and the other stuff can be a problem on a space-constrained device. For example, a CANopen shop has zero use for any of the ISO-TP stuff), and no silly metapackage
We now have separate packages for the utilities (good), and now a useless empty metapackage (annoying/wasteful/pointless) that exists solely to satisfy a dependency that has no reason for existing

[neheb]

I have no idea what you're complaining about. I made a bad change, reverted it (added back the necessary lines) to get the original behavior, and you're still complaining.

Look at coreutils as another example. It functions the same way.

[Entropy512]

No, you made a bad change, refused to revert it based on a provably false assertion that it would create a "pointless metapackage", and took weeks to "fix" it, creating the very problem you claimed to be "fixing".

As to coreutils, it has the exact same issue you claim to have "fixed", a pointless metapackage which solely exists to be an empty dependency of other packages:

adodd@andyslaptop-old:~/tmp$ tar -xzvf coreutils_8.32-1_arm_cortex-a15_neon-vfpv4.ipk
./debian-binary
./data.tar.gz
./control.tar.gz
adodd@andyslaptop-old:~/tmp$ tar -xzvf data.tar.gz 
./
adodd@andyslaptop-old:~/tmp$ 

See the contents of data.tar.gz? EMPTY. A "pointless metapackage" as you describe it...

[neheb]

Please look at the actual changes:

https://github.com/openwrt/packages/commit/5969273ff40cdf6d90f3442aa6c986226e0a16dc <-- removed install section
https://github.com/openwrt/packages/commit/b70cb0ef5ed196247bd4bcce3cb84167420eeb4d <-- bad change based on removed install section
https://github.com/openwrt/packages/commit/5f9a918c4fe8d3e6e3a29f653204683881ae6f07 <-- reverted bad change
https://github.com/openwrt/packages/commit/d34430f02f33765770e4fc748094a0a047c73265 <--added back install section

There is no behavior change. Only version bumps.

[Entropy512]

Let us go back to, YOUR OWN WORDS:
"Removing that causes a pointless coreutils metapackage with all of the subpackages to be outside of it."
This is provably false. You are either lying, our you are not bothering to test your own changes to verify that they are doing what you think they are doing. Because your changes have done the exact opposite of what you claim that your goals are. Again - take the "pointless metapackages" you created and take a look at them, you will see that they are, indeed, empty and pointless and serve absolutely no purpose other than to be an unnecessary dependency satisfaction for other packages which do not need to have a dependency.

What you call a "bad change" FIXED THE VERY PROBLEM YOU CLAIMED TO WISH TO FIX. And when you reverted the change that fixed the very problem you claimed to want to fix, you broke the package based on an assertion that the change in question would cause the very problem which you yourself have caused.

You reverted this "bad change", and created the very problem you are claiming to try to fix, a "pointless metapackage".

In the current state of coreutils, and canutils, you have an EMPTY metapackage which serves NO purpose other than to satisfy a bogus dependency which does not need to exist. This is EXACTLY the "problem" you claimed to wish to "fix" but you actually CAUSED said problem with your changes. Or in this case, someone else fixed the problem you claimed to wish to fix, you declared it "bad" because you didn't bother to test the change at all, and then caused the very problem you, in your own words, claimed to want to fix - that of a pointless empty metapackage which serves no purpose other than to be an empty dependency satisfaction for other packages. Now you constantly assert that you "fixed" something even though anyone who actually bothers to test your changes can see that you broke what you claimed to be trying to fix.

If you hadn't made that provably false claim earlier, I wouldn't be complaining. But you broke the package, declared the working solution that met your stated goals to be "bad", and then after a long time "fixed" the package bringing back the very "problem" you claimed earlier to be trying to fix.

[neheb]

Let us go back to, YOUR OWN WORDS:
"Removing that causes a pointless coreutils metapackage with all of the subpackages to be outside of it."
This is provably false. You are either lying, our you are not bothering to test your own changes to verify that they are doing what you think they are doing. Because your changes have done the exact opposite of what you claim that your goals are.

I made pictures showcasing the problem:

https://imgur.com/a/BUnEDFC

The latter is the way it originally was and currently is. There's no need for all of the utilities to clutter menuconfig.

Again - take the "pointless metapackages" _you created_ and take a look at them, you will see that they are, indeed, empty and pointless and serve _absolutely no purpose_ other than to be an unnecessary dependency satisfaction for other packages which do not need to have a dependency.

What you call a "bad change" FIXED THE VERY PROBLEM YOU CLAIMED TO WISH TO FIX. And when you reverted the change that fixed the very problem you claimed to want to fix, you broke the package based on an assertion that the change in question would cause the very problem which you yourself have caused.

You reverted this "bad change", and created the very problem you are claiming to try to fix, a "pointless metapackage".

In the current state of coreutils, and canutils, you have an EMPTY metapackage which serves NO purpose other than to satisfy a bogus dependency which does not need to exist. This is EXACTLY the "problem" you claimed to wish to "fix" but you actually CAUSED said problem with your changes. Or in this case, someone else fixed the problem you claimed to wish to fix, you declared it "bad" because you didn't bother to test the change at all, and then caused the very problem you, in your own words, claimed to want to fix - that of a pointless empty metapackage which serves no purpose other than to be an empty dependency satisfaction for other packages. Now you constantly assert that you "fixed" something even though anyone who actually bothers to test your changes can see that you broke what you claimed to be trying to fix.

If you hadn't made that provably false claim earlier, I wouldn't be complaining. But you broke the package, declared the working solution that met your stated goals to be "bad", and then after a long time "fixed" the package bringing back the very "problem" you claimed earlier to be trying to fix.
The end result is the package being brought back to the way it was before.

Note that canutils is not really maintained. @toxxin is not active. If you feel that the package currently is broken, please propose a PR instead of ranting under a closed issue.

[Entropy512]

Have you ever considered that it is not maintained because someone who is too incompetent or lazy to bother to test changes keeps on overriding the maintainer?

Because I know exactly what was needed to fix the previous issue, and know what is needed to fix your claimed "issue" that you broke the package for a month to "fix", but I'm not going to PR it because you will reject it because you are too incompetent/lazy to verify that a change does what you actually think it will do.

Because the proper "fix" for the issue YOU raised as a supposed issue is to:
Back out your change
Reinstate the change made by @pffmachado

So if you're wondering why this package is unmaintained - YOU keep on breaking it with the claim that you need to "fix" problems which other maintainers fix but YOU break.

So, to come up with the simplest TL;DR:
THIS PACKAGE HAS NO ACTIVE MAINTAINERS BECAUSE OF YOU.
You outright broke the package, and refused the simplest and most obvious fix, in order to bring back the very problem you were claiming to wish to solve.

[Entropy512]

Yet another "problem" you claim to have "solved", but you clearly didn't if you were a competent software developer that did things such as:
TEST YOUR CHANGES

Because you have done NOTHING to change the "problem" that you outlined in your post.

[Grommish]

Yet another "problem" you claim to have "solved", but you clearly didn't if you were a competent software developer that did things such as:
TEST YOUR CHANGES

Because you have done NOTHING to change the "problem" that you outlined in your post.

Then instead of the issue tab, maybe hit the Pull Request tab, submit the fix and justification for it, and then be the center of attention for fixing an issue, wash, rinse, repeat?

I'm not sure where the hostility is coming from, given this isn't a paid product and you aren't a customer? Not be come off as a total fop, but this appears to be have solved over a month ago? Why so upset?

[Entropy512]

@Grommish Why waste my time to submit a pull request when I know it will get rejected because @neheb doesn't bother to understand or test what changes to code do?

He outright undid SOMEONE ELSE'S change in favor of his own, for the sole purpose of CREATING THE PROBLEM HE CLAIMED TO WISH TO SOLVE.

I'm upset because @neheb broke this package, @neheb refused to accept the obvious solution to the package, and @neheb forced us to wait for his "acceptable" solution which caused the exact problem he claimed to wish to fix.

Edit: Now he wonders why there are no maintainers for this package. It's pretty obvious, as said in my previous comment: There are no maintainers of this package because of him.

Edit 2: As to your question of "why so upset" - The inability of @neheb to test and verify code wastes my time and his. While you say this is not a paid product, "time is money" and @neheb has actively wasted our time by making provably false claims about his approach vs. that of other maintainers who have apparently gone inactive - likely because of him. There was a simple solution to this problem, one which was outright rejected by @neheb because of his provably false assertion that the solution would cause the very problem he himself not only failed to solve, but caused.

[Grommish]

@Entropy512, it doesn't seem like this is a more than edge-case issue, which does happen from time to time. Given that no one on the forums has been complaining about canutils tells me it's either not a popular package, or the specific use-case you are using isn't one most people run.

Bad things will happen. Unintended consequences to changes will pop up from time to time, and it's certainly _extremely_ helpful when they get reported - Thank you for that. I also don't think you're being intentionally incendiary (or, I hope not anyway), but it did come across that way.

A few suggestions on future issues. First, please don't be upset about a change, or think it was intentionally designed to bork something/someone. No one wants things that break other things, because waves hands around things like this happen.

You figured out what the issue was, you can fix it locally, then submit the change.. Explain that "hey, this broke my stuff and this is why.. Is there something we can do about it?".. I can't see @neheb telling anyone to go away, especially if they send the changes in that make everyone happy. As long as it works, why wouldn't it be included? Especially when someone else does the work :+1:

Why not ask about being the maintainer? You obviously USE the package and have experience with it. Run with it. At the very worse, you'll have an updated canutils while everyone else suffers.

EDIT: For anyone who can't fix the issue locally, reporting the issue is still the way to go. In this particular case, the knowledge and experience to effect local changes is there.

[Entropy512]

@Grommish I don't disagree that canutils is pretty niche. But, no less than two people have asked @neheb to revert a one-line change that broke the build, he refused to do so because of a false assertion that it would cause a problem, and forced us to wait a month for him to finally "fix" the "problem" by causing the very issue he claimed to be saving us by "fixing".

If he hadn't outright overriden the last person to make a change that cared about the package, and told the rest of us to f**k off, we wouldn't be so angry. But he did. He broke the package for over a month, ignoring the obvious solution, in favor of his own which caused the very problem he was claiming to want to solve.

As to why not ask to be the maintainer: It's pretty obvious @neheb will tell me to f**k off and stop doing the job. Again, if you're wondering why the maintainer of this package has gone inactive, look no further than @neheb who jumps in and makes false assertions about how the makefiles behave.

[Grommish]

@Entropy512 Understood, and that can be frustrating.

Since the package is niche, and doesn't have a full time maintainer, just take it over. If your commits are good, you can raise a stink about it being ignored (unintentional or not, given real life and workloads, etc), but seriously, send them in. Again, absolute worse case scenario is that you have an up-to-date package locally, and just keep it to yourself.

[Entropy512]

OK, I'll make the change to this and coreutils, since @neheb claims has the same "problem" and I have verified it. This particular item is one of those "affects me primarily at work" so it will have to wait until monday.

Possibly a bit longer because the next week is going to be a mess of tidying things up before a 2-week vacation...

[neheb]

@Grommish I don't disagree that canutils is pretty niche. But, no less than two people have asked @neheb to revert a one-line change that broke the build, he refused to do so because of a false assertion that it would cause a problem, and forced us to wait a month for him to finally "fix" the "problem" by causing the very issue he claimed to be saving us by "fixing".

I posted two pictures outlining the issue raised by removing DEPENDS. Upon investigation, it turned out that there was a missing dependency issue, which is the reason for defining the install section to true. The buildbot never ran into this because everything is compiled as a module.

If he hadn't outright overriden the last person to make a change that cared about the package, and told the rest of us to f**k off, we wouldn't be so angry. But he did. He broke the package for over a month, ignoring the obvious solution, in favor of his own which caused the very problem he was claiming to want to solve.
I don't use profanity here. I fixed the package to its previous behavior by investigating the issue when I had time.

As to why not ask to be the maintainer: It's pretty obvious @neheb will tell me to f**k off and stop doing the job. Again, if you're wondering why the maintainer of this package has gone inactive, look no further than @neheb who jumps in and makes false assertions about how the makefiles behave.

I don't care much for this package, meaning I'd be fairly happy to have someone actually maintaining it.

[Grommish]

I'd be fairly happy to have someone actually maintaining it.

And, there you go :+1:

@Entropy512 enjoy your vacation and be safe!

[Entropy512]

In addition to the issues I've already raised, me becoming maintainer might lead to some issues with my company's legal department - which I would be willing to at least put some pressure on to change (participation/upstreaming to FOSS projects has been something I want to push up the flagpole for a year or two, and I think I might be actually able to do so). I'll start the process of poking them in the next week before I poof off for vacation. This could take a while to push through, I hope I can do so because it makes my job much easier in the long term. :)

If I can sort that out, I'd be willing to take over maintainership of most of canutils. If someone else wants to focus on the ISO-TP stuff, I'd happily hand that over to them since... That's a no-op where I work. But hopefully at an OpenWRT level it is just "does it compile/does it use too much space".

[clanmills]

Gentlemen: I don't know what's being discussed here. I am willing to mediate a discussion on Zoom with one precondition - _only one person can speak at a time_.