Tested this package for a while on gentoo-bsd and seems to be 100% but the init script which i don't think it works even on other arch's due to the fact it has --quiet which makes the pidfile to be created empty... I'm attaching a patch to fix this...
Created attachment 159756 [details, diff] Fix for /etc/init.d/ziproxy replaced ${myservice} which doesn't exist anymore with ziproxy and removed --quiet from start() so it can create the pidfile properly
Please look up "critical" in a dictionary. :)
From what I see....critical is for bugs when packages do not work...and this one simply doesn't work..hence the critical..whats the point of having something that doesn't in the tree? Either fix it or remove it...but at least one of them ;]
If you click on "severity" label you will see this explanation: Critical crashes, loss of data, severe memory leak Care to give us the source of your (very) personal definition?
The init script has been fixed in cvs. Reassigned to bsd for ~x86-fbsd keyword.
(In reply to comment #4) > If you click on "severity" label you will see this explanation: > Critical crashes, loss of data, severe memory leak > Care to give us the source of your (very) personal definition? What would you call let's say...if GNOME didn't work? 'normal'? So if some other app doesn't work...why doesn't it get fixed? I just filed a bug for pciutils which seems to be a duplicate but eitherways...the filed bug report has been going on for a few months already on that one To me these are my definitions: Blocker: Only for apps such as binutils/gcc/libedit etc...that can bork the entire system Critical: When a package does not work Normal: Something that should be fixed Major: Works, but with some errors Minor: Works, but does something which ain't supposed to Trivial: Suggestions to comment something this or that way...or mostly text errors and such Enhancement: If there's no problem, but you still feel like you can contribute with something to improve it.. On the Severity list u can look at these two: Critical crashes, loss of data, severe memory leak Major major loss of function There's no major loss of function cose the damn thing doesn't even work! so one goes higher...Critical! Fix it, period. Dragging these stupid conversations over and over about nonsense is dumb and gets nothing fixed.
nonetheless: your ziproxy.patch is broken, since you did: - start-stop-daemon --stop --quiet --pidfile /var/run/${myservice}.pid + start-stop-daemon --stop --quiet --pidfile /var/run/ziproxy.pid that ${myservice} has a reason! It's there, so that you can have more ziproxy instances with different configurations. But Alin fixed it correctly at last.
(In reply to comment #7) > nonetheless: your ziproxy.patch is broken, since you did: > - start-stop-daemon --stop --quiet --pidfile /var/run/${myservice}.pid > + start-stop-daemon --stop --quiet --pidfile /var/run/ziproxy.pid > that ${myservice} has a reason! It's there, so that you can have more ziproxy > instances with different configurations. > But Alin fixed it correctly at last. (In reply to comment #7) > nonetheless: your ziproxy.patch is broken, since you did: > - start-stop-daemon --stop --quiet --pidfile /var/run/${myservice}.pid > + start-stop-daemon --stop --quiet --pidfile /var/run/ziproxy.pid > that ${myservice} has a reason! It's there, so that you can have more ziproxy > instances with different configurations. > But Alin fixed it correctly at last. Next time you wanna follow other people talking crap...at least test the damn thing, and KNOW what you're talking about! 1. The patch ain't broken 2. You can't run more than one server unless you create multiple confs and run it manually (which has nothing to do with the script..) 3. There's no ${myservice} anymore 4. STFU instead of trying to be a smart-ass...I'm tired of people here acting stupid instead of fixing things, people spend more time in here probably talking trash than actually fixing things... why can't I ever see a bug like...someone submits a fix and a dev just tests it or makes his own fix and just writes...FIXED!.. it always takes months to get things fixed...sad sad sad
First of all, I've fixed the problem, see comment #5. Second, you should learn some manners before attempting to speak in public! Not that I would expect much from a person that choose to have such an email address, but still... I'm out of here.
@Kiko: > Next time you wanna follow other people talking crap...at least test the > damn thing, and KNOW what you're talking about! I know what I'm talking about, since I wrote than "damn" ebuild. > 1. The patch ain't broken it is! Since you degrade the original purpose. > 2. You can't run more than one server unless you create multiple confs and run it manually (which has nothing to do with the script..) indeed. That's why there is a variable in that init-script. You can symlink "ziproxy" to e.g. "ziproxy-foo". Then /etc/conf.d/ziproxy-foo will be loaded. An in /etc/conf.d/ziproxy(*) you find this: # Full path to ziproxy.conf file (instead of default one). CONFIG="/etc/ziproxy/ziproxy.conf" Well, problem sovled. > 3. There's no ${myservice} anymore I know. THAT was the only bug. Now it's called ${SVCNAME}. That init-script is quite old, and it was just forgotten to migrate to OpenRC. > 4. STFU instead of trying to be a smart-ass...I'm tired of people here > acting stupid instead of fixing things, people spend more time in here > probably talking trash than actually fixing things... You should learn how to behave. We ARE actually *fixing* things. But you should accept, that we don't *degrade* features like you did.
(In reply to comment #9) > First of all, I've fixed the problem, see comment #5. > Second, you should learn some manners before attempting to speak in public! Not > that I would expect much from a person that choose to have such an email > address, but still... > I'm out of here. * Starting ziproxy ... * start-stop-daemon: did not create a valid pid in `/var/run/ziproxy.pid' [ !! ] * ERROR: ziproxy failed to start upgraded to the new version...it's still broken you forgot to remove the '--quiet' from the start-stop-daemon command in the start() function --quiet needs to be removed so the output can be sent to the /var/run/${SVCNAME}.pid file
yes, indeed. I fixed this in CVS. But this is also a regression because of OpenRC. With the old baselayout, it worked.
