NAS Posted July 29, 2014 Share Posted July 29, 2014 holy thread fork batman... this is the docker forum p.s. you will notice the the testing release is so cutting edge even the developer of the feature hasnt finished working on the feature yet http://nzbget.net/forum/viewtopic.php?f=10&t=1333&view=unread#p8408 So as far as I am concerned this proves for all time testing releases are actually development releases Quote Link to comment
overbyrn Posted July 29, 2014 Share Posted July 29, 2014 holy thread fork batman... this is the docker forum Fair point NAS. Feel free to move to the nzbget plugin thread. I should have posted there and linked instead. Was being lazy. Quote Link to comment
NAS Posted July 29, 2014 Share Posted July 29, 2014 all good every time i go to move or split a thread I mess it up badly so if you dont mind i wont make a fool of myself again Has anyone got a link to the par2 changes this introduces and perhaps the thread discussing the theory. I cant seem to find it yet Quote Link to comment
neilt0 Posted July 29, 2014 Share Posted July 29, 2014 holy thread fork batman... this is the docker forum p.s. you will notice the the testing release is so cutting edge even the developer of the feature hasnt finished working on the feature yet http://nzbget.net/forum/viewtopic.php?f=10&t=1333&view=unread#p8408 So as far as I am concerned this proves for all time testing releases are actually development releases Yil is not the developer, hugbug is. In that thread, yil is talking about implementing other features, but hugbug has implemented the feature as he saw fit. It's finished and it works. Quote Link to comment
NAS Posted July 29, 2014 Share Posted July 29, 2014 holy thread fork batman... this is the docker forum p.s. you will notice the the testing release is so cutting edge even the developer of the feature hasnt finished working on the feature yet http://nzbget.net/forum/viewtopic.php?f=10&t=1333&view=unread#p8408 So as far as I am concerned this proves for all time testing releases are actually development releases Yil is not the developer, hugbug is. In that thread, yil is talking about implementing other features, but hugbug has implemented the feature as he saw fit. It's finished and it works. My take is different in that Yil is the developer of the feature and nzbget has forked it before it is complete (which he clearly says). Why is this important? because he is the person who created the par2 patch. As for being finished sorry but it is not. It has not been audited upstream of which nzbget doesnt maintain the code. Regardless this is just business as usual in the development world and thats what makes it exciting and precisely why we need to be clear to our users in simple terms to stay away from development code unless they want to live dangerously. Most people do not know about all this stuff and if we make using it a few dumb mouse clicks it is doubly important. Quote Link to comment
neilt0 Posted July 29, 2014 Share Posted July 29, 2014 Yil is not an nzbget developer. It's just hugbug. Quote Link to comment
NAS Posted July 29, 2014 Share Posted July 29, 2014 "This feature is based on research of par algorithm and source code of par library made by forum member Yil." He is in fact the developer of the code nzbget is using which in itself is a patch the the work of Peter Clements and many many others. None of which to my knowledge have even seen the code yet never mind audited it (certainly i haven't seen it on the mailing list). And this is all fine. No one is arguing that this is anything other than business as usual and awesome but this is not the nzbget development and testing forum it is the forum for docker on unRAID which is principally for end users. End users should not be using development code unless they need to. Quote Link to comment
neilt0 Posted July 29, 2014 Share Posted July 29, 2014 Why do you keep repeating the same mantra that no-one should be using the testing versions? As I said before, no-one should be running the development version, but most avid users will run the testing version. It's more stable than you seem to think. I haven't had a testing version crash since 2008. We're going to keep using the testing versions, in part to help test the software and in part because if you only ran the release version, you'd see approximately one release per year. The software moves more quickly than that. I'm not sure why you want to weigh in with your opinions on what people should and should not run? What are you trying to achieve? The plugin version of nzbget has had testing versions built in for a long time (since the beginning?) Why did you not kick up a fuss then? Why are you so interested in this topic -- do you even run nzbget? Also, nzbget does not contain code by Peter B. Clements. That's par2lib -- which is called from nzbget, just like unrar, for example. Maybe contact hugbug to ask him who the developers are if that's important to you. I haven't seen anyone else working in it for 6+ years. I'm not trying to be combative here, but you don't seem to want to drop this topic! Maybe move these posts elsewhere, if you see fit. Although, the thread is about nzbget. Quote Link to comment
Pducharme Posted July 29, 2014 Author Share Posted July 29, 2014 Ok Ok guys Keep peace I tend to agree with neilt0 - If us, the users, want to test a "testing" version, it's on us. It can help the development of NZBGet and that's good. neilt0 just want a docker that you can choose, by using a variable, what you want to run. I understand that pkgs.org doesn't have yet a new "stable" of version 13. Someone else (can't remember who) did fork the NZBGet and made that work. For me, it doesn't work because I can't save the Config change for my Post Processing script, but it's just a Config file issue, I guess it can be fixed easily. I think the NZBget "official" docker should be the new one, it's not the "standard" one that Install Pkgs.org apt-get package, but in the case of NZBGet, those packages are not create fast enough to be a good idea. What do you think ? Quote Link to comment
NAS Posted July 29, 2014 Share Posted July 29, 2014 Why do you keep repeating the same mantra that no-one should be using the testing versions? simply because you keep asking for testing versions to be made available here which we have to support. If you really want it make it and support it If you cant then perhaps someone else can make it for you and you can offer support. Really though there's perhaps 10 commands to be added to a fork of the current v13 docker to make this work. Honestly I really hope you do take up this as nzbget is an amazing tool but until then as Pducharme says lets keep bleeding edge code away from general end users. From my end I will take up the challenge to see if we can learn from this and build in a framework that allows testing and development code to be hidden from the general userbase unless they specifically opt in (or something similar). Something that ballances the ease of docker but limits the support burden (which we are already seeing here) and risk of running code this edgy. Quote Link to comment
Pducharme Posted July 29, 2014 Author Share Posted July 29, 2014 I could see something that look for a specific XML file on the appdata folder with a value like: BleedingEdgeAllowed = True or False. The XML can also contains other useful value. If the XML is not present, the only thing available could be the "stable" available build. Quote Link to comment
NAS Posted July 29, 2014 Share Posted July 29, 2014 Yeah something like that is an option. I suggest we fork that discussion and get back to what to do about letting committed users install development versions. The current problem is that within days of someone creating the v13 docker it cant handle development builds since they arent tagged. Also even if we fix that part (which is easy) the way the stable installs libpar2 cant be the same as testing. This means that the edge script has to purge the apt par2 first and that is getting to much of a kludge for my liking. Quote Link to comment
nzbget Posted July 29, 2014 Share Posted July 29, 2014 "This feature is based on research of par algorithm and source code of par library made by forum member Yil." He is in fact the developer of the code nzbget is using which in itself is a patch the the work of Peter Clements and many many others. None of which to my knowledge have even seen the code yet never mind audited it (certainly i haven't seen it on the mailing list). Guys, let me clarify the things. That's probably an unfortunate wording that had lead to misunderstanding. Yil is not the author of par2 library, neither the author of this feature or any other single line of code included in NZBGet. What was meant in the phrase is that Yil has made a research of par algorithm and of source code of par library. He has published his findings on NZBGet forum and his idea (skipping the scan of undamaged files) was implemented by me in the new feature. The required patch for libpar2 was made by me as well, similar to other patches made by me years ago, which are already included in the Debian/Ubuntu fork of libpar2. The new patch is actually very small, it's just making one of the function "virtual" allowing NZBGet to intercept the call and perform verification instead of letting libpar2 doing it. Plus another small change, not related to this. The feature is complete, it was tested by few forum members and is now available for testing for all other users in the new testing release. Yil has many ideas. Some of them can find their way into NZBGet. We will see. As for waiting for libpar2 upstream to review the patch - this will never happen. The libpar2 project is dead for years. I'm glad the Debian/Ubuntu team has taken the maintenance but they don't do more than integrating the submitted patches. And it's not a coincidence that the maintainer of Debian/Ubuntu fork of libpar2 is the same person who maintains NZBGet for Debian/Ubuntu. par2cmdline vs libpar2: please don't confuse that two packages. NZBGet doesn't use par2cmdline, but only libpar2. There are not so many software which use libpar2. I know only one (in addition to NZBGet) - gpar (gnome frontend). There is no risk in integrating the new patch into your version of libpar2 because NZBGet is most likely the only program in your repository depending on it (I don't think unRAID has gpar and if it uses gnome at all, I don't know). -- hugbug Quote Link to comment
BRiT Posted July 29, 2014 Share Posted July 29, 2014 Thanks for taking the time out of your busy schedule to educate the masses on the situation. Quote Link to comment
nzbget Posted July 29, 2014 Share Posted July 29, 2014 Thanks for taking the time out of your busy schedule to educate the masses on the situation. I appreciate your sense of humor Quote Link to comment
NAS Posted July 29, 2014 Share Posted July 29, 2014 Thanks for clearing that up. The patch has no attribution or licensing directly associated with it so there was no reason to assume that "source code of par library made by forum member Yil" meant anything other than it specifically said. From a docker based on phusion standpoint Debian being directly upstream leads us to the annoying mismatch between the libpar2 version required in v12, v13 and v14 vs. the various Debian derivatives. Docker can help solve this problem as one of its specific design tenants is to break "dependency hell" which this is. This thread has become somewhat forked as this is absolutely not the best place to be doing anything related to testing, auditing code, debating attribution or licensing in nzbget. The natural place for that is obviously your own forum and tracker however we have some keen users here that want to keep up to date with nzbget release. Some of these users may be valuable testers for you but most will just want the latest and greatest for no real reason and there within lies my fundamental issue with this. We are not best placed to support keeping building test releases on docker and certainly not supporting the application itself. That is not to say the unRAID community cannot do it but ideally our job should begin and end at enabling the ability to install applications in a way that the real experts in that app can support it (be this nzbget, sabnzb, plex et al). This is a brave new world for us. unRAID traditionally made Debian stable looked fast paced and we always had to do things in such oddball Slackware ways there was no option to self support. But with docker in a matter of months we now have the ability to give users access to pretty much anything and pass the application support burden along with it, but we haven't got there yet. Quote Link to comment
nzbget Posted July 29, 2014 Share Posted July 29, 2014 I fully understand the idea of providing robust (stable) packages. I also understand the wish of some users to have the latest and greatest (with bugs). A good compromise was discussed in this thread - to let the user pass a revision number to fetch from svn (trunk). This unfortunately will not help in the current case because of a patch required for libpar2. Still it's generally a good idea for the future. It's very rare for NZBGet to need new dependencies and the patches for libpar2 are also rare (the previous was about two years ago). BTW v12 and v13 require the same libpar2 - either official 0.2 + patches or 0.4 from Debian/Ubuntu (which already includes the patches). Quote Link to comment
gfjardim Posted July 29, 2014 Share Posted July 29, 2014 I fully understand the idea of providing robust (stable) packages. I also understand the wish of some users to have the latest and greatest (with bugs). A good compromise was discussed in this thread - to let the user pass a revision number to fetch from svn (trunk). This unfortunately will not help in the current case because of a patch required for libpar2. Still it's generally a good idea for the future. It's very rare for NZBGet to need new dependencies and the patches for libpar2 are also rare (the previous was about two years ago). BTW v12 and v13 require the same libpar2 - either official 0.2 + patches or 0.4 from Debian/Ubuntu (which already includes the patches). Just to be clear, the official libpar2 on the Ubuntu repository is already patched? By the way, tags are easier to fetch and control than revisions. Quote Link to comment
nzbget Posted July 29, 2014 Share Posted July 29, 2014 Just to be clear, the official libpar2 on the Ubuntu repository is already patched? Debian/Ubuntu version of libpar2 includes all patches required for v12 or v13. It doesn't have the new patch for v14 yet. Quote Link to comment
NAS Posted July 29, 2014 Share Posted July 29, 2014 Agreed. In and ideal world we would agree on a docker that works here and which could be supported by yourself. I think there is probably some joint effort that could happen. The changes to make the docker support stables by default and specific revision number are far from insurmountable and with the near native speed of docker and its widespread uptake it could be useful to a far wider audience. What I am primarily concerned about though, as i said previously, is that we dont have the helpers to support this properly; certainly not if every docker needs a similar treatment. I dont want to rush into this as I am just a single voice that happens to be awake... but let me ask one last question Do you have any plans to distribute nzbget via docker? Edit: gfjardim .. it depends on the version of nzbget vs the repo used. My understanding is the current debian testing supports up to and including V13. Debian stable doesnt support any of these and none support v14. Similar situation with Ubuntu it is all very convoluted Edit2: possibly the best approach is to not use apt at all for libpar2 and make+patch based on the specific revision SVN checkout. This would negate the need to get into situations where the dev nzbget requires you to apt-get purge libpar2 Quote Link to comment
gfjardim Posted July 29, 2014 Share Posted July 29, 2014 Just to be clear, the official libpar2 on the Ubuntu repository is already patched? Debian/Ubuntu version of libpar2 includes all patches required for v12 or v13. It doesn't have the new patch for v14 yet. Can you create tags for these testings? I can easily recompile the libpar2 and path it for v14-testing. Quote Link to comment
NAS Posted July 29, 2014 Share Posted July 29, 2014 gfjardim I wouldn't rely on tags I would just get users to enter the SVN revision number. More flexible and removes a human step upstream e.g. people that want it can easily see the release notes and get the revision number such as http://nzbget.net/forum/viewtopic.php?f=4&t=1334 Quote Link to comment
nzbget Posted July 29, 2014 Share Posted July 29, 2014 Do you have any plans to distribute nzbget via docker? No, at least not in the near future. I've heard about docker for the first time about a month ago. I'm not familiar with this technology at all and have no idea how much efforts it will take to provide the package and support for it. Can you create tags for these testings? I can easily recompile the libpar2 and path it for v14-testing. Revision numbers are much better. They even allow user to try a version which was not released as testing yet. Or quickly test a bugfix. And I don't want to clutter the "tags"-subdirectory with testing releases. Making it work with release numbers shouldn't be that much trouble for you? Quote Link to comment
NAS Posted July 29, 2014 Share Posted July 29, 2014 Have a look into docker. gfjardim is a particularly good example of how elegant and powerful it is. https://github.com/gfjardim/docker-nzbget Must sleep; back tomorrow Quote Link to comment
gfjardim Posted July 29, 2014 Share Posted July 29, 2014 Tags are more "human readable". But I can work with pretty much anything. Thanks a lot for your time, hugbug! Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.