You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Newsboat version (copy the output of newsboat -v or the first line of git show):
Newsboat 2.29.0 - https://newsboat.org/
Copyright (C) 2006-2015 Andreas Krennmair
Copyright (C) 2015-2022 Alexander Batischev
Copyright (C) 2006-2017 Newsbeuter contributors
Copyright (C) 2017-2022 Newsboat contributors
Newsboat is free software licensed under the MIT License. (Type `newsboat -vv' to see the full text.)
It bundles:
- JSON for Modern C++ library, licensed under the MIT License: https://github.com/nlohmann/json
- optional-lite library, licensed under the Boost Software License: https://github.com/martinmoene/optional-lite
- expected-lite library, licensed under the Boost Software License: https://github.com/martinmoene/expected-lite
Newsboat 2.29.0
System: Linux 6.0.10-0-xyz (x86_64)
Compiler: g++ 12.2.1 20220924
ncurses: ncurses 6.3.20221126 (compiled with 6.3)
libcurl: libcurl/7.86.0 OpenSSL/3.0.7 zlib/1.2.13 brotli/1.0.9 nghttp2/1.51.0 (compiled with 7.85.0)
SQLite: 3.40.0 (compiled with 3.39.3)
libxml2: compiled with 2.10.2
Config file (copy from ~/.newsboat/config or ~/.config/newsboat/config):
empty
Steps to reproduce the issue:
open any feed on a 32-bit musl 1.2 system, idk
Other info you think is relevant:
on a 64-bit system, with https://social.treehouse.systems/@marcan.rss as the sole url in ~/.newsboat/urls:
Newsboat 2.29.0 - Articles in feed 'Hector Martin' (20 unread, 20 total) - https://social.treehouse.systems/@marcan.rss
1 N Dec 03 203 109447971687181420
2 N Dec 02 213 109441875890551358
3 N Dec 02 671 109441870318393322
4 N Nov 28 196 109420862652320078
5 N Nov 28 762 109420859349587697
6 N Nov 26 513 109408192786292944
7 N Nov 26 58 109408013385376758
8 N Nov 22 248 109387939953882850
9 N Nov 22 343 109386987351333117
10 N Nov 22 1.1K 109386654184095095
11 N Nov 21 163 109382184123846257
12 N Nov 20 36 109376434341919332
13 N Nov 20 319 109374672766433721
14 N Nov 20 210 109374666547170531
15 N Nov 20 54 109373692359879200
16 N Nov 19 242 109369145771646198
17 N Nov 17 272 109359975139353020
18 N Nov 17 439 109359926470501861
19 N Nov 17 218 109359914213636319
20 N Nov 17 309 109359331538695321
the same thing on a 32-bit system (specifically, an armv7 userspace container running on aarch64 hardware):
Newsboat 2.29.0 - Articles in feed 'Hector Martin' (17 unread, 20 total) - https://social.treehouse.systems/@marcan.rss
1 N May 29 343 109386987351333117
2 N May 29 58 109408013385376758
3 N May 28 1.1K 109386654184095095
4 N May 27 218 109359914213636319
5 N May 27 54 109373692359879200
6 N May 27 163 109382184123846257
7 N May 27 36 109376434341919332
8 N May 27 319 109374672766433721
9 N May 27 272 109359975139353020
10 N May 27 203 109447971687181420
11 N May 27 671 109441870318393322
12 N May 26 309 109359331538695321
13 N May 26 248 109387939953882850
14 N May 26 513 109408192786292944
15 N May 26 762 109420859349587697
16 N May 25 196 109420862652320078
17 N May 25 439 109359926470501861
18 N May 25 213 109441875890551358
19 N May 25 242 109369145771646198
20 N May 25 210 109374666547170531
(also note the 'marker' at the 1.1K size and how offset it is- it's a different resulting order for the same request at the same time, on top of all the dates being wrong. those are the same responses where the sizes match).
(it also then segfaults on exit, but i can't debug that in a container without ptrace. probably caused by the same issue anyway.).
this is probably related to the 64-bit-always time_t change in musl 1.2 if i had to guess and some type via the libc crate messing it up, as the rust libc::time_t type is c_long which is 32-bit for musl (for which the fix is in rust-lang/libc#2088 i guess, but not sure if it might be something else entirely).
The text was updated successfully, but these errors were encountered:
Thanks for the report, and sorry for such a late response!
Dates are parsed with RssParser::w3cdtf_to_rfc822() (rss/rssparser.cpp), which doesn't involve Rust or libc crate. Probably just an error in our own parsing logic.
Haven't tried to reproduce this yet. I guess the first step would be to grab the feed from that URL, put it into tests/data and write a test for the parser to check which dates it returns; then upgrading to musl 1.2 and ensuring it still passes; then checking that the fixes didn't break musl pre-1.2 and other libcs.
Minoru
added
bug
This issue reports a problem that ought to be fixed
to check
This bug has a good enough description but has to be reproduced by someone else
labels
Dec 27, 2022
Minoru
changed the title
time stuff seems to be broken on 32-bit 1.2 musl
Item dates seem to be broken on 32-bit musl 1.2
Dec 27, 2022
Dates are parsed with RssParser::w3cdtf_to_rfc822() (rss/rssparser.cpp), which doesn't involve Rust or libc crate.
ah! my apologies, i see rust somewhere and always jump to that as the first conclusion without checking further. i guess that (somewhat) simplifies the fixability.
sorry for such a late response!
no worries. no priority from me- someone had just noticed it on IRC and i reproduced it for them and though i'd write it out here just to make sure it was known and not invisible. i don't have any 32-bit systems myself.
Newsboat version (copy the output of
newsboat -v
or the first line ofgit show
):Config file (copy from ~/.newsboat/config or ~/.config/newsboat/config):
empty
Steps to reproduce the issue:
Other info you think is relevant:
on a 64-bit system, with
https://social.treehouse.systems/@marcan.rss
as the sole url in~/.newsboat/urls
:the same thing on a 32-bit system (specifically, an armv7 userspace container running on aarch64 hardware):
(also note the 'marker' at the 1.1K size and how offset it is- it's a different resulting order for the same request at the same time, on top of all the dates being wrong. those are the same responses where the sizes match).
(it also then segfaults on exit, but i can't debug that in a container without ptrace. probably caused by the same issue anyway.).
this is probably related to the 64-bit-always time_t change in musl 1.2 if i had to guess and some type via the libc crate messing it up, as the rust libc::time_t type is c_long which is 32-bit for musl (for which the fix is in rust-lang/libc#2088 i guess, but not sure if it might be something else entirely).
The text was updated successfully, but these errors were encountered: