4 ms·

Anyone have a link to the patch in uutils? Curious to see that the problem and solution were.

by jey 1y ago

janzer 1y ago
It would be really nice if something said what the actual problem was. The last commit[0] is a fix for date parsing to bring it in line with the GNU semantics, which seems like a pretty good candidate. Edit: Or not, see evil-olive's comment[1] for a more likely candidate. 0: https://github.com/uutils/coreutils/commit/0047c7e66ffb579713d0673dec17875d7e6fbfeb https://github.com/uutils/coreutils/commit/0047c7e66ffb57971... 1: https://news.ycombinator.com/item?id=45687743 https://news.ycombinator.com/item?id=45687743
pedrocr 1y ago
This seems to be the Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2127970 https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
cataflam 1y ago
This comment[0] explains it. The core bug seems to be that support for `date -r <file>` wasn't implemented at the time ubuntu integrated it [1, 2]. And the command silently accepted -r before and did nothing (!) 0: https://lwn.net/Articles/1043123/ https://lwn.net/Articles/1043123/ 1: https://github.com/uutils/coreutils/issues/8621 https://github.com/uutils/coreutils/issues/8621 2: https://github.com/uutils/coreutils/pull/8630 https://github.com/uutils/coreutils/pull/8630
- nine_k 1y ago
  This doesn't look like a bug, that is, something overlooked in the logic. This seems like a deliberately introduced regression. Accepting an option and ignoring it is a deliberate action, and not crashing with an error message when an unsupported option is passed must be a deliberate, and wrong, decision.
  - imiric 1y ago
    I would say that Canonical is more at fault in this case. I'm frankly appalled that an essential feature such as system updates didn't have an automated test that would catch this issue immediately after uutils was integrated. Nevermind the fact that this entire replacement of coreutils is done purely out of financial and political rather than technical reasons, and that they're willing to treat their users as guinea pigs. Despicable.
    - nine_k 1y ago
      What surprises me is that the job seems rushed. Implementation is incomplete. Testing seems patchy. Things are released seemingly in a hurry, as if meeting a particular deadline was more important for the engineers or managers of a particular department than the qualify of the product as a whole. This feels like a large corporation, in the bad sense.
  - johnisgood 1y ago
    > deliberately introduced regression > deliberate and wrong decision Yeah... I hope "we" will not switch to it just because it is written in Rust. There is much more than just the damn language behind it.
  - zahlman 1y ago
    It's wrong (and coreutils get it right) but I don't see why it would have to be deliberate. It could easily just not occur to someone that the code needs to be tested with invalid options, or that it needs to handle invalid options by aborting rather than ignoring. (That in turn would depend on the crate they're using for argument parsing, I imagine.)
    - nine_k 1y ago
      Could parsing the `-r` be added without noticing it somehow? If it was added in bulk, with many other still unsupported option names, why does the program not crash loudly if any such option is used? A fencepost error is a bug. A double-free is a bug. Accepting an unsupported option and silently ignoring it is not, it takes a deliberate and obviously wrong action.
- Avamander 1y ago
  Man, if I had a nickel every time some old Linux utility ignored a command-line flag I'd have a lot of nickels. I'd have even more nickels if I got one each time some utility parsed command-line flags wrong. I have automated a lot of things executing other utilities as a subprocess and it's absolutely crazy how many utilities handle CLI flags just seemingly correct, but not really.
egorfine 1y ago
The problem is the existence of the project of Rust rewrite itself.

Anyone have a link to the patch in uutils? Curious to see that the problem and solution were.

by jey 1y ago

Anyone have a link to the patch in uutils? Curious to see that the problem and solution were.

It would be really nice if something said what the actual problem was. The last commit[0] is a fix for date parsing to bring it in line with the GNU semantics, which seems like a pretty good candidate. Edit: Or not, see evil-olive's comment[1] for a more likely candidate. 0: https://github.com/uutils/coreutils/commit/0047c7e66ffb579713d0673dec17875d7e6fbfeb https://github.com/uutils/coreutils/commit/0047c7e66ffb57971... 1: https://news.ycombinator.com/item?id=45687743 https://news.ycombinator.com/item?id=45687743

pedrocr 1y ago

This seems to be the Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2127970 https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...

cataflam 1y ago

This comment[0] explains it. The core bug seems to be that support for `date -r <file>` wasn't implemented at the time ubuntu integrated it [1, 2]. And the command silently accepted -r before and did nothing (!) 0: https://lwn.net/Articles/1043123/ https://lwn.net/Articles/1043123/ 1: https://github.com/uutils/coreutils/issues/8621 https://github.com/uutils/coreutils/issues/8621 2: https://github.com/uutils/coreutils/pull/8630 https://github.com/uutils/coreutils/pull/8630

nine_k 1y ago
This doesn't look like a bug, that is, something overlooked in the logic. This seems like a deliberately introduced regression. Accepting an option and ignoring it is a deliberate action, and not crashing with an error message when an unsupported option is passed must be a deliberate, and wrong, decision.
- imiric 1y ago
  I would say that Canonical is more at fault in this case. I'm frankly appalled that an essential feature such as system updates didn't have an automated test that would catch this issue immediately after uutils was integrated. Nevermind the fact that this entire replacement of coreutils is done purely out of financial and political rather than technical reasons, and that they're willing to treat their users as guinea pigs. Despicable.
  - nine_k 1y ago
    What surprises me is that the job seems rushed. Implementation is incomplete. Testing seems patchy. Things are released seemingly in a hurry, as if meeting a particular deadline was more important for the engineers or managers of a particular department than the qualify of the product as a whole. This feels like a large corporation, in the bad sense.
- johnisgood 1y ago
  > deliberately introduced regression > deliberate and wrong decision Yeah... I hope "we" will not switch to it just because it is written in Rust. There is much more than just the damn language behind it.
- zahlman 1y ago
  It's wrong (and coreutils get it right) but I don't see why it would have to be deliberate. It could easily just not occur to someone that the code needs to be tested with invalid options, or that it needs to handle invalid options by aborting rather than ignoring. (That in turn would depend on the crate they're using for argument parsing, I imagine.)
  - nine_k 1y ago
    Could parsing the `-r` be added without noticing it somehow? If it was added in bulk, with many other still unsupported option names, why does the program not crash loudly if any such option is used? A fencepost error is a bug. A double-free is a bug. Accepting an unsupported option and silently ignoring it is not, it takes a deliberate and obviously wrong action.
Avamander 1y ago
Man, if I had a nickel every time some old Linux utility ignored a command-line flag I'd have a lot of nickels. I'd have even more nickels if I got one each time some utility parsed command-line flags wrong. I have automated a lot of things executing other utilities as a subprocess and it's absolutely crazy how many utilities handle CLI flags just seemingly correct, but not really.

egorfine 1y ago

The problem is the existence of the project of Rust rewrite itself.