Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=159756) [details]
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.