Is docker of NZBget been updated to NZBGet 13 yet?

Just wondering if the NZBGet docker is at the latest version (13.0) or still the older 12.0 version ?  Also, could be possible to support "EDGE" and "NORMAL", so we can try latest BETA or Pre-Production Builds ?  (I think that should be in each docker, I mean the support of EDGE).

Yeah, I run nzbget-testing, not nzbget-release. Not having a current build of nzbget is stopping me moving over to unRAID 6/Docker.

nbget-testing is not the development build, it's the one most of us actually use.

So, you have:

* Stable

* Testing

* Development

No-one runs Development, but the avid users all run Testing because Testing generally isn't buggy and you could be looking at 6 months before testing goes to the stable branch, missing out on features, not to mention helping debug them for hugbug.

All software seems to be Beta now, and nzbget-testing is a heck of a lot less "Beta" than a lot of "release" commercial software!

It seems that casual compilers who want to provide builds just see the stable version and put that out, not realising it's not what people actually want.

Currently, nzbget 13 just went to the stable branch, meaning nzbget-testing is now at 14.

http://nzbget.net/Packaging#What_version_to_use_for_packaging

How hard is it to compile this? I'm not a developer, so I'd rather not have to do it myself, but I can if there's no other option -- I've done it in the past, having made the first build of nzbget for unRAID, but it was a bit of a pain.

Ideally, we'd have a maintainer who was compiling each Stable and Testing release. There aren't actually that many releases: http://nzbget.net/forum/viewforum.php?f=4

It has been raised already. 13 should hit the unstable Ubuntu repo soon and then a new docker will be trivial.

patience i would say.

Stick with stable unless you actually need testing (which IMHO post v12 almost no one does).

13 is stable not 12. I would have to disagree about "no-one needing testing". I've been running testing branches since 2008! :-)

It is considered unstable at the upstream repo that is what I am referring to.

I too have been using testing on an off for a long while but IMHO the days of needing to run testing to get the features you need are gone. As such we should really only tell users to run the stable branch and not actively encourage them not to (they will do that all on their ownsome i reckon

Again, sorry, but you are wrong about the testing builds. They are NOT development builds, they are the current version of the software, they are not unstable builds.

There is a significant performance increasing feature in the new builds which is almost specific to unRAID:

I came up with the idea of writing articles to a RAM drive to get around the issue of ReiserFS not working well with DirectWrite and now that's been implemented as the new article cache feature: http://nzbget.net/forum/viewtopic.php?f=10&t=1317

Except, I can't test it when it goes in to the next testing build as we have no-one maintaining the nzbget-testing builds for unRAID or Docker, which is now getting frustrating.

Again, how hard is it to compile nzbget for Docker and can I do that based on an existing Docker nzbget setup? I'm not even running 6 yet.

As I said on the nzbget forum, it was a lot easier when I had a LinkStation. All I had to do was type "installpkg nzbget-testing"....   

Again, sorry, but you are wrong about the testing builds. They are NOT development builds, they are the current version of the software, they are not unstable builds.

They are by very definition builds for testing... the clue is in the name the dev chose. Saying otherwise is just an opinion of how good the code quality being tested is and is merely a user opinion not a dev sactioned fact.

We wont ever agree on this so lets just leave that part aside shall we

There is a significant performance increasing feature in the new builds which is almost specific to unRAID:

 

I came up with the idea of writing articles to a RAM drive to get around the issue of ReiserFS not working well with DirectWrite and now that's been implemented as the new article cache feature: http://nzbget.net/forum/viewtopic.php?f=10&t=1317

This essentially proves my point; you know this because you are a keen user, have been watching forums and commits and have been testing the future release.

Except, I can't test it when it goes in to the next testing build as we have no-one maintaining the nzbget-testing builds for unRAID or Docker, which is now getting frustrating.

Again, how hard is it to compile nzbget for Docker and can I do that based on an existing Docker nzbget setup? I'm not even running 6 yet.

Docker development has a tricky initial learning curve and then it is easy. You essentially would need to copy and paste some stuff from other people exmaples and then build, test and publish it.

Not hard but requires some commitment to do it and keep doing it.

Please dont take any of this the wrong way but you have to remember most user simply dont care about all this stuff they want a button that just works.

Like it or not your a tester

Edit: and we can help I just dont have time to take point on this with all the other things going on here and IRL

Please dont take any of this the wrong way but you have to remmeber most user simply dont care about all this stuff they want a button that just works.

Most users do not know what usenet is and most users don't run unRAID. It's going to be hard to find a combination of the two who are not "hardcore" users.

Who is maintaining the nzbget Docker? Is there more than one Docker for nzbget? The Docker thing looks like a huge clusterf**k with no centralisation of who is doing what with which apps on which OSes.

Maybe I'd be better off with a VM that I can just run "apt-get install nzbget-testing" or whatever the command is in. I'm just reluctant to go full VM as I'm running low-end CPUs.

Please dont take any of this the wrong way but you have to remmeber most user simply dont care about all this stuff they want a button that just works.

 

Most users do not know what usenet is and most users don't run unRAID. It's going to be hard to find a combination of the two who are not "hardcore" users.

 

Who is maintaining the nzbget Docker? Is there more than one Docker for nzbget? The Docker thing looks like a huge clusterf**k with no centralisation of who is doing what with which apps on which OSes.

 

Maybe I'd be better off with a VM that I can just run "apt-get install nzbget-testing" or whatever the command is in. I'm just reluctant to go full VM as I'm running low-end CPUs.

That's a complete misunderstanding on what we are doing here. This Docker fever is only 1 month old, and see what we already had done. Most of plugins are already ported to docker containers, we have a webGUI that can  make the users live easier, and most of the containers are maintained by needo. We are formating the best practices, and we are trying to stick with phusion base image.

Ubuntu hasn't incorporate NZBGet 13 yet, there isn't a NZBGet 13 deb package in any PPA I could found. So if you want to make a container that has build-essentials (a 200MB+ extra in download bandwidth) just to use a recently updated version, you will better get served with your own VM.

Take a look here: http://pkgs.org/search/?query=nzbget&type=smart

No DEB! What do you wish us to do? Reinvent the wheel? Please, stop this nonsense. Containers will be updated as soon as updates are available. Simple as that!

I don't know why you're shouting at me?

I have no idea what you're talking about. I don't know what a deb or PPA is. I'm not talking nonsense -- how am I supposed to know there's no Debbie or PAPA or whatever. And what the hell that's supposed to mean. We're not all Linux programmers, dude.

It sounds odd that nzbget-testing can't be compiled for Ubuntu? Why isn't it as easy as doing one of those apt-get thingies?

And don't shout the answer, please.

Thanks.

I don't know why you're shouting at me?

 

I have no idea what you're talking about. I don't know what a deb or PPA is. I'm not talking nonsense -- how am I supposed to know there's no Debbie or PAPA or whatever. And what the hell that's supposed to mean. We're not all Linux programmers, dude.

 

It sounds odd that nzbget-testing can't be compiled for Ubuntu? Why isn't it as easy as doing one of those apt-get thingies?

 

And don't shout the answer, please.

 

Thanks.

Do you know the difference of talking and SHOUTING? I'm not shouting at you, I'm telling you.

.DEB are already compiled packages, that can be installed by the apt/dpkg package control program. They are stored in repositories, some official, some unofficial. The unofficial repositories in Ubuntu are called PPA.

So here we go. Pre-compiled packages save a LOT of necessary steps to make things work. They describe all dependencies needed, so they will be installed too. If there's not a .deb package available, you will have to install a build environment (200MB+ size), install manually the dependencies, download the source, extract the source, configure the source, compile the program, install the program, do a cleanup.

See, this is not easy. It's not a case of apt-get install nzbget-testing. There is no nzbget-testing package, do you understand. It's a lot of handwork to manually compile a program that will eventually be included in the repositories.

Is it clear now?

No DEB! What do you wish us to do? Reinvent the wheel? Please, stop this nonsense. Containers will be updated as soon as updates are available. Simple as that!

This is shouting. You can tell by the exclamation marks.

neil,

if you can hang on until tomorrow, I'll have a go at building v13 stable. I have a docker container that I've setup especially for building nzbget

It doesn't result in a .deb but it does create a .tar.bz2 package that I use with a customised version of needos nzbget docker that, on startup replaces the nzbget install with one from a specified package - see https://github.com/butlerpeter/nzbget/tree/nzbget-package

I haven't had chance to look at building v13 stable yet, but I am running v13-test-r1053 (I think! - the last testing release before stable anyway)

Thanks, butlerpeter.

The thing is, I don't mind doing all the work myself, but I can't see a good reason why there is no package for it.

A reasonable answer rather than all the yelling might have been "Docker uses packages from Ubuntu and there is no nzbget-testing package for Ubuntu yet", not a lot of yelling about having to download 200MB of stuff (as if that's a huge amount in 2014!      )

That, I would have understood.

If you can look at building nzbget-testing, that would be great. I'm running NZBGet 13.0-testing-r1028, but the next 14.x testing builds (not out yet) will have (sorta) unRAID-specific optimizations.

And before the shouting and exclamation marks start again, take a look at which idiot did all the original hard work to get nzbget working on unRAID before we have Docker Pants and KEVINS and XFMs and all that: http://lime-technology.com/forum/index.php?topic=12188.msg115768#msg115768

And before the shouting and exclamation marks start again, take a look at which idiot did all the original hard work to get nzbget working on unRAID before we have Docker Pants and KEVINS and XFMs and all that: http://lime-technology.com/forum/index.php?topic=12188.msg115768#msg115768

You are still holding a grunge at this? I didn't know you're a such delicate person, i"ll make sure to measure my words upfront. Sorry for upsetting you. 

Ubuntu hasn't incorporate NZBGet 13 yet, there isn't a NZBGet 13 deb package in any PPA I could found. ...

...

I have no idea what you're talking about.

...

A reasonable answer rather than all the yelling might have been "Docker uses packages from Ubuntu and there is no nzbget-testing package for Ubuntu yet", not a lot of yelling about having to download 200MB of stuff (as if that's a huge amount in 2014!  [img alt=]http://lime-technology.com/forum/Smileys/default/shocked.gif[/img]  [img alt=]http://lime-technology.com/forum/Smileys/default/rolleyes.gif[/img]  [img alt=]http://lime-technology.com/forum/Smileys/default/grin.gif[/img] )

That, I would have understood.

Apparently not. He told you that NZBGet 13 was not available on Ubuntu. I would think that implies that nzbget-testing is not available on Ubuntu.

Surely someone who is advanced enough to make a plugin pulling dependencies, etc. (and wants to remind us of that fact three years later) is advanced enough to be able to figure out for themselves that needo's Docker images are based on Phusion/Ubuntu and has relatively basic Linux knowledge about what a deb is.

Or, you know, you could have looked at nzbet.com/download which has a link to check for availability of NZBGet 13 on...pkgs.org. AKA the link that gfjardim posted. AKA the website you yourself used when doing the hard work for your plugin.

Also, I enjoy that you are using exclamation points in a sentence one post after describing the usage of exclamation points as "shouting". (P.S. Bonus points for Docker Pants and KEVINS...LOL)

Wow... I just check on my thread... Did I open a can of worm ?

Lol.  I'll wait for the needo next stable as I don't need the other feature.  About the patch for Unraid, what is the purpose of it?  I don't have any issue with 12.0 on my Unraid? Is it limited to people using low-End CPU?

@needo Ok, not related to version 13.

Is it possible to have the current docker postproessing-script folder to outside of the docker ?  I want to use the VideoSort (http://nzbget.net/VideoSort) PostProcessing script to sort, rename and move Movies to a different location (in the array instead of the btrfs partition)...

You could also just add the latest version of VideoSort to your docker and that will be good too.

@needo Ok, not related to version 13.

 

Is it possible to have the current docker postproessing-script folder to outside of the docker ?  I want to use the VideoSort (http://nzbget.net/VideoSort) PostProcessing script to sort, rename and move Movies to a different location (in the array instead of the btrfs partition)...

 

You could also just add the latest version of VideoSort to your docker and that will be good too.

Currently I have ppscripts living outside the docker. For example I have my ScriptDir in nzbget set to ${MainDir}/ppscripts And my MainDir set to /mnt/downloads/nzbget which lives outside the docker.

Now if VideoSort needs more then ffmpeg for it's work I will need to add those dependencies which I am happy to do.

Regarding nzbget v13 I am waiting for it to pop up in the Ubuntu repositories. Yes, I could build the .deb myself but then I would be responsible for supporting it. In addition I prefer if at all possible to install packages that have gone through the Debian/Ubuntu process or are made by trustworthy individuals with peer review. To insure that some malicious individual is not "sneaking something in."

Once nzbget v13 pops up from a trusted source I will upgrade my Docker for it.

Who is maintaining the nzbget Docker?

A user who is kind enough to do this in his own spare time.

Is there more than one Docker for nzbget?

Docker NZBGet Images

Although you will need to tweak them for unRAID.

The Docker thing looks like a huge clusterf**k with no centralisation of who is doing what with which apps on which OSes.

It is set up much like how unRAID plugins were. As in, most of us rely on one kind unRAID user who in his spare time created Docker Containers for us. He also is the person who maintains them and provides tech support.

Maybe I'd be better off with a VM that I can just run "apt-get install nzbget-testing" or whatever the command is in. I'm just reluctant to go full VM as I'm running low-end CPUs.

That is what I ended up doing. Docker is great and all but even if you know how to create your own docker containers you still have to jump through a lot of hoops to set up the apps to work well in unRAID. I switched back to VMs so I am not depended on a part time unRAID user to update / upgrade / maintain and provide tech support.

Needo is doing a fantastic job and providing a very valuable service and I hope users are donating to support his efforts. In my case, I have enough linux knowledge to install / maintain my own Apps in a few VMs.

Also, Ubuntu is not the best choice for the Docker Image. The various Media Apps we use and depend on are updated way to much or even forked and new apps pop up all the time. Using a Linux Distro with a ports system like Arch or Gentoo who attract a lot of power users who have the latest and greatest stable and development branches is a much better way to go.

Even without the port system, Arch had nzbget 13 in their main repo 6 days ago. They also have a NZBGet Wiki.

@needo Ok, not related to version 13.

 

Is it possible to have the current docker postproessing-script folder to outside of the docker ?  I want to use the VideoSort (http://nzbget.net/VideoSort) PostProcessing script to sort, rename and move Movies to a different location (in the array instead of the btrfs partition)...

 

You could also just add the latest version of VideoSort to your docker and that will be good too.

 

Currently I have ppscripts living outside the docker. For example I have my ScriptDir in nzbget set to ${MainDir}/ppscripts And my MainDir set to /mnt/downloads/nzbget which lives outside the docker.

 

Now if VideoSort needs more then ffmpeg for it's work I will need to add those dependencies which I am happy to do.

 

Regarding nzbget v13 I am waiting for it to pop up in the Ubuntu repositories. Yes, I could build the .deb myself but then I would be responsible for supporting it. In addition I prefer if at all possible to install packages that have gone through the Debian/Ubuntu process or are made by trustworthy individuals with peer review. To insure that some malicious individual is not "sneaking something in."

 

Once nzbget v13 pops up from a trusted source I will upgrade my Docker for it.

Damn! I didn't thought of changing the Path !   Sorry, i'll try that for that PP-Script.  Thanks, i'll report if something is needed.

Needo is doing a fantastic job and providing a very valuable service and I hope users are donating to support his efforts. In my case, I have enough linux knowledge to install / maintain my own Apps in a few VMs.

Thank you for the compliment. However I have not accepted one donation for the work I have put in to Docker/unRAID. I am appreciative of those that have offered but it is a personal choice.

For those who are feeling extremely adventurous, I made fork from needo's excellent NZBGet container that allows users to experiment the EDGE feature. It will checkout the source code from SF and compile it.

The repository is gfjardim/nzbget.

Set a variable EDGE with value "1" to compile the trunk (unstable) version. Set EDGE to "13.0" to compile the 13.0 version.

Nice work. Looks like Debian has accepted the par2 patches upstream hence why you no longer need to patch the source (that was a complete pain and often caused clashes in a nomral Deb install).

A few questions for my own sanity:

So once the user checks out and runs this they get v12 stable by default. However if they set the EDGE variable this passes in a environmental variable into the docker. When edge.sh runs (as defined in the dockerfile) its sees this variable and checks out the relevant code, compiles it and installs it.

I have not run this yet (as I am not at docker) but I have a question:

does this not result in a big bunch of interim containers and one randomly named final container or does the fact the we set --name="nzbget" do something clever in docker land

Thanks for all the info. I will look in to running a VM.

I'm a bit confused by this EDGE thing, though. Which branch does that implement?

Hopefully testing and not development? No-one should be running the development branch.