Am 17.09.2015 um 01:45 schrieb Nick Edwards:
also I wonder why an unbound user joins the bind list
because some people are smart enough to use different software for
different usecases as unbound for caching-only servers and named for
autoritative nameservers and for some usecases like rout
lol I KNEW youd that cause you just cant help yourself, trying to draw
attention away from yourself, but thats OK every person whos come
across you knows better, a simple google of your name shows an
immense number of your vitriol on many many lists.
the bannings youve had from many many lists s
On Wednesday 16 September 2015 at 10:32:55, Reindl Harald wrote:
> Am 16.09.2015 um 04:25 schrieb Nick Edwards:
> > - and no that is not rude, you have no idea how i sound
> > if i start to get rude
>
> the fact you don't feel being rude does not mean you are not.
> >>>
> >>>
Am 16.09.2015 um 04:25 schrieb Nick Edwards:
On 9/15/15, Reindl Harald wrote:
Am 15.09.2015 um 00:05 schrieb Nick Edwards:
On 9/15/15, Matus UHLAR - fantomas wrote:
On 12.09.15 15:27, Reindl Harald wrote:
and no, i am not the package maintainer but the first person who
would
file a bug
On 9/15/15, Reindl Harald wrote:
>
>
> Am 15.09.2015 um 00:05 schrieb Nick Edwards:
>> On 9/15/15, Matus UHLAR - fantomas wrote:
> On 12.09.15 15:27, Reindl Harald wrote:
>> and no, i am not the package maintainer but the first person who
>> would
>> file a bug for *any* packa
Am 15.09.2015 um 00:05 schrieb Nick Edwards:
On 9/15/15, Matus UHLAR - fantomas wrote:
On 12.09.15 15:27, Reindl Harald wrote:
and no, i am not the package maintainer but the first person who would
file a bug for *any* package which rely on a internet connection due
update
Am 14.09.2015 u
On 9/15/15, Matus UHLAR - fantomas wrote:
>>>On 12.09.15 15:27, Reindl Harald wrote:
and no, i am not the package maintainer but the first person who would
file a bug for *any* package which rely on a internet connection due
update
>
>>Am 14.09.2015 um 17:25 schrieb Matus UHLAR - f
already
I see this particular information for the first time.
Maybe you could point me to proper place in the archive?
Or maybe you could be more specific instead of blame everyone for
everything?
Weitergeleitete Nachricht ----
Betreff: Re: Live upgrade safe?
Datum: Mon, 14 Sep 201
On 12.09.15 15:27, Reindl Harald wrote:
and no, i am not the package maintainer but the first person who would
file a bug for *any* package which rely on a internet connection due
update
Am 14.09.2015 um 17:25 schrieb Matus UHLAR - fantomas:
in such case it's up to the distributions' maintain
Am 14.09.2015 um 17:25 schrieb Matus UHLAR - fantomas:
On 12.09.15 15:27, Reindl Harald wrote:
and no, i am not the package maintainer but the first person who would
file a bug for *any* package which rely on a internet connection due
update
in such case it's up to the distributions' maintain
On 12.09.15 15:27, Reindl Harald wrote:
and the package maintainer will tell you it should be considered as
bug upstream when updates from the network are mandatory - no package
does that and SA can also be sueful on machines without a internet
connection working with local files and corpus
Am
On September 14, 2015 2:25:19 AM Reindl Harald wrote:
you are talking bullshit!
what ?
Am 14.09.2015 um 02:17 schrieb Benny Pedersen:
Greg Troxel skrev den 2015-09-14 01:35:
I don't remember getting bit by it until just now.
ask your self, what will happend if you upgraded rpm package that is
possible new in the rpm repos, but cointains also the rules that are
old, and you dai
Greg Troxel skrev den 2015-09-14 01:35:
I don't remember getting bit by it until just now.
ask your self, what will happend if you upgraded rpm package that is
possible new in the rpm repos, but cointains also the rules that are
old, and you daily have used sa-update via cron, do you then lik
Am 14.09.2015 um 01:41 schrieb Reindl Harald:
Am 14.09.2015 um 01:35 schrieb Greg Troxel:
Reindl Harald writes:
RPM packages are not supposed to contact network *3rd party*
ressources at install time and when you think 1 second you know why -
who tells you that the 3rd party ressource is
Am 14.09.2015 um 01:35 schrieb Greg Troxel:
Reindl Harald writes:
RPM packages are not supposed to contact network *3rd party*
ressources at install time and when you think 1 second you know why -
who tells you that the 3rd party ressource is available at that moment
and how handle errors an
Reindl Harald writes:
> RPM packages are not supposed to contact network *3rd party*
> ressources at install time and when you think 1 second you know why -
> who tells you that the 3rd party ressource is available at that moment
> and how handle errors and bugreports when it fails?
>
> that wil
Am 12.09.2015 um 19:15 schrieb Matus UHLAR - fantomas:
On 12.09.15 15:27, Reindl Harald wrote:
and the package maintainer will tell you it should be considered as
bug upstream when updates from the network are mandatory - no package
does that and SA can also be sueful on machines without a int
On 12.09.15 15:27, Reindl Harald wrote:
and the package maintainer will tell you it should be considered as
bug upstream when updates from the network are mandatory - no package
does that and SA can also be sueful on machines without a internet
connection working with local files and corpus
Am
Am 12.09.2015 um 16:08 schrieb Matus UHLAR - fantomas:
Am 11.09.2015 um 21:08 schrieb Matus UHLAR - fantomas:
if your distribution restarts spamassassin, it will most probably
download the rules before. Not everyone uses distributions...
On 12.09.15 04:20, Reindl Harald wrote:
no, the ser
Am 11.09.2015 um 21:08 schrieb Matus UHLAR - fantomas:
if your distribution restarts spamassassin, it will most probably
download the rules before. Not everyone uses distributions...
On 12.09.15 04:20, Reindl Harald wrote:
no, the service restarts are usually rpm-macros in the %post section
Am 12.09.2015 um 15:24 schrieb Matus UHLAR - fantomas:
Am 11.09.2015 um 21:08 schrieb Matus UHLAR - fantomas:
if your distribution restarts spamassassin, it will most probably
download
the rules before. Not everyone uses distributions...
On 12.09.15 04:20, Reindl Harald wrote:
no, the servi
Am 11.09.2015 um 21:08 schrieb Matus UHLAR - fantomas:
if your distribution restarts spamassassin, it will most probably download
the rules before. Not everyone uses distributions...
On 12.09.15 04:20, Reindl Harald wrote:
no, the service restarts are usually rpm-macros in the %post section
an
Am 11.09.2015 um 21:08 schrieb Matus UHLAR - fantomas:
>Can I safely upgrade SA from 3.4.0 to 3.4.1 without changing any local
>configuration files, and without regenerating the Bayes database? (I
>use the default bdb Bayes store.)
On 2015-08-14 17:45 +0200, Reindl Harald wrote:
yes, but yo
>Can I safely upgrade SA from 3.4.0 to 3.4.1 without changing any local
>configuration files, and without regenerating the Bayes database? (I
>use the default bdb Bayes store.)
On 2015-08-14 17:45 +0200, Reindl Harald wrote:
yes, but you need to run "sa-update" before restart to fetch the
l
Am 11.09.2015 um 18:12 schrieb Benny Pedersen:
Ian Zimmerman skrev den 2015-09-11 18:05:
I appreciate you trying to help, but you don't really answer my
question. Even if I could do what you suggest, the rsync would still
take finite time - longer than the interval between the upgrade and th
Ian Zimmerman skrev den 2015-09-11 18:05:
I appreciate you trying to help, but you don't really answer my
question. Even if I could do what you suggest, the rsync would still
take finite time - longer than the interval between the upgrade and the
restart on the production system.
if you recen
Am 11.09.2015 um 18:05 schrieb Ian Zimmerman:
On 2015-09-11 17:35 +0200, Reindl Harald wrote:
Can I safely upgrade SA from 3.4.0 to 3.4.1 without changing any local
configuration files, and without regenerating the Bayes database? (I
use the default bdb Bayes store.)
yes, but you need to ru
Ian Zimmerman skrev den 2015-09-11 17:21:
Isn't this a contradiction? If my distribution automatically restarts
(which it does), how can I sneak in a sa-update run after the upgrade
but before the restart?
ask the precompiled problem maintainer, not here, your packege is not
doing well if th
On 2015-09-11 17:35 +0200, Reindl Harald wrote:
> >>>Can I safely upgrade SA from 3.4.0 to 3.4.1 without changing any local
> >>>configuration files, and without regenerating the Bayes database? (I
> >>>use the default bdb Bayes store.)
> >>
> >>yes, but you need to run "sa-update" before restart
Am 11.09.2015 um 17:54 schrieb RW:
On Fri, 11 Sep 2015 08:21:15 -0700
Ian Zimmerman wrote:
On 2015-08-14 17:45 +0200, Reindl Harald wrote:
Can I safely upgrade SA from 3.4.0 to 3.4.1 without changing any
local configuration files, and without regenerating the Bayes
database? (I use the defa
On Fri, 11 Sep 2015 08:21:15 -0700
Ian Zimmerman wrote:
> On 2015-08-14 17:45 +0200, Reindl Harald wrote:
>
> > >Can I safely upgrade SA from 3.4.0 to 3.4.1 without changing any
> > >local configuration files, and without regenerating the Bayes
> > >database? (I use the default bdb Bayes store.)
Am 11.09.2015 um 17:21 schrieb Ian Zimmerman:
On 2015-08-14 17:45 +0200, Reindl Harald wrote:
Can I safely upgrade SA from 3.4.0 to 3.4.1 without changing any local
configuration files, and without regenerating the Bayes database? (I
use the default bdb Bayes store.)
yes, but you need to r
On 2015-08-14 17:45 +0200, Reindl Harald wrote:
> >Can I safely upgrade SA from 3.4.0 to 3.4.1 without changing any local
> >configuration files, and without regenerating the Bayes database? (I
> >use the default bdb Bayes store.)
>
> yes, but you need to run "sa-update" before restart to fetch
Am 14.08.2015 um 17:32 schrieb Ian Zimmerman:
Can I safely upgrade SA from 3.4.0 to 3.4.1 without changing any local
configuration files, and without regenerating the Bayes database? (I
use the default bdb Bayes store.)
yes, but you need to run "sa-update" before restart to fetch the latest
Can I safely upgrade SA from 3.4.0 to 3.4.1 without changing any local
configuration files, and without regenerating the Bayes database? (I
use the default bdb Bayes store.)
--
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to l
36 matches
Mail list logo
