Porting patches to newsbeuter?

slackhead commented 5 years ago

Hi, I've been using newsbeuter for a while now and I was told that you have contributed patches for various fixes in it.

With the switch to rust will you still be interested in porting patches for vulnerabilities etc? I don't know if anyone else is patching the original source. Debian still have many patches, while gentoo and arch have dropped newsbeuter now.

Minoru commented 5 years ago

Hi!

I was told that you have contributed patches for various fixes in it

I maintained it for a while, and most of Newsboat's contributors are originally Newsbeuter contributors. So we weren't just contributing from outside—we were running the project. That stopped a while ago, and we do not (and never did) port Newsboat's changes to Newsbeuter.

I don't plan to start porting them, either. It simply doesn't make any sense to me. The code is open, though, so you don't have to put up with my decisions if you don't want to.

Debian still have many patches

From a quick glance, it appears that most of those are backports of changes that are in Newsbeuter's master branch. We couldn't release them properly (hence Newsboat fork), but the most important ones got ported to the latest release, 2.9.

If you want to maintain Newsbeuter, I suggest you fork Newsboat 2.13 instead. It got a lot of things fixed already, and it's an easier start than Newsbueter 2.9 or even Newsbeuter's master. And you aren't the first person to ask questions like this, so perhaps you'll get some help from other people who don't like our switch to Rust.

slackhead commented 5 years ago

Hi Minoru!

The person that maintains newsbeuter and newsboat for slackware wants to drop newsbeuter and give up newsboat for someone else to take over. I did volunteer, but someone with more experience of rust made a build script. I'm not sure if he wants to take it over or not though.

I've been using newsboat for just over a week now and it works without a flaw. I'll have to see how that guy makes his build scripts. Slackware scripts are designed to build without any network connection, with just the script and the source tarballs. I know the sources are listed in the cargo files, but I haven't played with it enough yet to work out the download URLs.

About the switch - I don't dislike rust at all. It's an interesting project, but I wonder if it's really ready for use like this at the moment, since it doesn't seem to support system-wide libraries. When I built newsboat it installed everything down to libc. Doing that for each and every application would be annoying to say the least. I did read some comments that there were plans to support system libs though. I'm not sure if/when that will happen.

Minoru commented 5 years ago

Slackware scripts are designed to build without any network connection, with just the script and the source tarballs. I know the sources are listed in the cargo files, but I haven't played with it enough yet to work out the download URLs.

If the script has a "configuration" phase that's allowed to access the network, it can use cargo fetch to pre-fetch everything the build might need.

When I built newsboat it installed everything down to libc.

If you mean that you ran make and saw a line like "Compiling libc v0.2.45", it's a libc crate, not libc the C library. That crate is just a set of bindings; we need it so that our Rust code could talk to C++ code.

If you mean you installed a pre-compiled version of Rust (e.g. through rustup) and it had its own libc, then it's just a common practice with prebuilt binaries. That's the only way to make sure they will run.

I assure you that Rust binaries do use system-wide libraries. Here's how I checked:

$ cargo new testtest
$ cd testtest
$ cargo build
$ ldd target/debug/testtest
    linux-vdso.so.1 (0x00007ffe1d7d4000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa1f47a0000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa1f4796000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa1f4775000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa1f475b000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa1f459a000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa1f4830000)

If none of the above applies, I'd be glad if you could share that comments you read—I'm not an expert yet, most probably I'm not aware of something.

I'm glad Newsboat in Slackware won't be abandoned for good. If you or that other maintainer run into any problems, please open an issue here—if it's something that can be fixed upstream, I'll fix it, and if not, at least I might help you with resolving it (and you'll help me by telling me what problems people run into).

The original question here seem to have been answered, so I'll close the issue now.

slackhead commented 5 years ago

All files need to be downloaded before starting anything in the script. Here's the list of crates that the guy who made the slackbuild used:

Minoru commented 5 years ago

All files need to be downloaded before starting anything in the script.

Oh, that sucks. While I understand the logic behind this, it's still very inconvenient.

It's also fragile. What if crates.io moved to another AWS instance? All those URLs would be broken.

slackhead commented 5 years ago

That would be a problem. But it would be worse if the URL had changed in the middle of an unattended installation where a script was meant to download them automatically. That's why it's best to get the sources first manually, before running any build scripts.

But then tomorrow I may want to install something else that relies on some of those same crates and have to start from scratch again. Having some way of having them avaliable in the system somehow that other applications could use them would be ideal.

polyzen commented 5 years ago

I regularly use https://crates.io/api/v1/crates/$crate/$version/download.

newsboat / newsboat

Porting patches to newsbeuter? #399