Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: INN 2.7.0 and development repository (Julien ?LIE)
2. Re: INN 2.7.0 and development repository (Russ Allbery)
3. Re: INN 2.7.0 and development repository (Julien ?LIE)
4. hissqlite (was Re: ovsqlite) (Bo Lindbergh)
5. Re: hissqlite (was Re: ovsqlite) (Russ Allbery)
6. Re: hissqlite (was Re: ovsqlite) (Bo Lindbergh)
7. Re: hissqlite (was Re: ovsqlite) (Russ Allbery)
8. New ovsqlite overview storage method available for testing
(Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Dec 2020 22:37:37 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: INN 2.7.0 and development repository
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
> I've been thinking about useful cleanup for INN 2.7.0 and wanted to open a
> conversation about possibly moving to Git and GitHub.
I also support that move!
> Using GitHub would also let us support pull requests if people wanted to
> use that development flow (although of course nothing prevents us from
> continuing to handle patches sent to the mailing list).
It would maybe attract more people, and increase development efforts in INN.
> I grabbed the InterNetNews organization name on GitHub just in case we
> want to use it. (INN was already taken by an unrelated organization.)
Great!
--
Julien ?LIE
??Love isn't all smiles and laughs for the moment; but crying and
fighting for what you believe is right and will last forever.??
------------------------------
Message: 2
Date: Thu, 24 Dec 2020 14:40:15 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: INN 2.7.0 and development repository
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Hi Russ,
>> I've been thinking about useful cleanup for INN 2.7.0 and wanted to
>> open a conversation about possibly moving to Git and GitHub.
> I also support that move!
Okay, folks in general seem to be in favor. Let's wait until 2.6.4 is out
the door, since we have to freeze the repository. Then I'll use git-svn
to try to convert all of the history, branches, and tags into a Git
repository, which usually requires a bit of cleanup, and push the
converted repository up to GitHub. After that, I'll look at converting
the Trac issues to GitHub issues.
Julien, could you let me know your GitHub username so that I can add you
to the organization?
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Fri, 25 Dec 2020 00:07:32 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: INN 2.7.0 and development repository
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
> Okay, folks in general seem to be in favor. Let's wait until 2.6.4 is out
> the door, since we have to freeze the repository. Then I'll use git-svn
> to try to convert all of the history, branches, and tags into a Git
> repository, which usually requires a bit of cleanup, and push the
> converted repository up to GitHub. After that, I'll look at converting
> the Trac issues to GitHub issues.
That sounds great, thanks for taking care of it!
> Julien, could you let me know your GitHub username so that I can add you
> to the organization?
Sure, it's simply "Julien-Elie".
--
Julien ?LIE
??? Chef?! On vient?!
? On se met en carr???
? Non?! En bosquet?!?? (Ast?rix)
------------------------------
Message: 4
Date: Fri, 25 Dec 2020 04:52:00 +0100
From: Bo Lindbergh <[email protected]>
To: [email protected]
Subject: hissqlite (was Re: ovsqlite)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Quoth Russ Allbery <[email protected]>:
>
> I'm wondering if sqlite could handle the history file.
I'll have a look at it.
history/buildconfig.in contains:
> if (!-d 'hisv6') {
> if (-d 'history/cnfs') {
^^^^
This is a copy-and-paste error, right?
Step 1 seems to be merging and refactoring history/buildconfig
and storage/buildconfig since they apparently do the same thing
except with different names.
/Bo Lindbergh
------------------------------
Message: 5
Date: Thu, 24 Dec 2020 19:59:17 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: hissqlite (was Re: ovsqlite)
Message-ID: <[email protected]>
Content-Type: text/plain
Bo Lindbergh <[email protected]> writes:
> Quoth Russ Allbery <[email protected]>:
>> I'm wondering if sqlite could handle the history file.
> I'll have a look at it.
> history/buildconfig.in contains:
>> if (!-d 'hisv6') {
>> if (-d 'history/cnfs') {
> ^^^^
> This is a copy-and-paste error, right?
Yes.
> Step 1 seems to be merging and refactoring history/buildconfig
> and storage/buildconfig since they apparently do the same thing
> except with different names.
Yes, that would be great.
(I have been dubious for a while whether that level of indirection in the
build system is worth it. The theory is that it makes it easy to drop in
a new backend, and makes it easy to deactivate backends, but honestly, how
often do we do that? One option might be to get rid of that indirection
entirely.)
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 6
Date: Fri, 25 Dec 2020 07:26:14 +0100
From: Bo Lindbergh <[email protected]>
To: [email protected]
Subject: Re: hissqlite (was Re: ovsqlite)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Quoth Russ Allbery <[email protected]>:
>
> (I have been dubious for a while whether that level of indirection in the
> build system is worth it. The theory is that it makes it easy to drop in
> a new backend, and makes it easy to deactivate backends, but honestly, how
> often do we do that? One option might be to get rid of that indirection
> entirely.)
And it's apparently too hard to get right.
>From storage/buildconfig.in before I ever touched it:
vvvvvvv
> if (defined $$config{number}{$number}) {
> die "$dir/$file: method number $number was already "
> . "allocated in $$config{number}{$number}\n";
> }
> $$config{number}{$dir} = $number;
^^^^
Checking $$config{number}{$number} for collisions doesn't work
when the actual assignment is to $$config{number}{$dir}.
/Bo Lindbergh
------------------------------
Message: 7
Date: Thu, 24 Dec 2020 22:30:48 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: hissqlite (was Re: ovsqlite)
Message-ID: <[email protected]>
Content-Type: text/plain
Bo Lindbergh <[email protected]> writes:
> Quoth Russ Allbery <[email protected]>:
>> (I have been dubious for a while whether that level of indirection in the
>> build system is worth it. The theory is that it makes it easy to drop in
>> a new backend, and makes it easy to deactivate backends, but honestly, how
>> often do we do that? One option might be to get rid of that indirection
>> entirely.)
> And it's apparently too hard to get right.
> From storage/buildconfig.in before I ever touched it:
> vvvvvvv
>> if (defined $$config{number}{$number}) {
>> die "$dir/$file: method number $number was already "
>> . "allocated in $$config{number}{$number}\n";
>> }
>> $$config{number}{$dir} = $number;
> ^^^^
> Checking $$config{number}{$number} for collisions doesn't work
> when the actual assignment is to $$config{number}{$dir}.
Heh. Yeah, all the pieces of that code that were never tested because we
never dynamically add new methods.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 8
Date: Fri, 25 Dec 2020 12:55:19 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: New ovsqlite overview storage method available for testing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Merry Christmas all!
I've just committed to CURRENT the new overview storage method based
on SQLite. Thanks again to Bo Lindbergh for his very appreciated
addition to the existing methods!
We now need to test ovsqlite more widely. In case you wish to test it,
just grab tomorrow's CURRENT snapshot (or update your local Subversion
repository) and switch to ovsqlite.
Here is the procedure for an overview rebuild:
1. Set the new overview storage method "ovsqlite" in the
*ovmethod* parameter
in inn.conf.
2. Check that "ovsqlite.conf" is correctly installed in
*pathetc* and fits your needs.
3. Make sure that INN is stopped.
4. Make sure that the directory specified by the *pathoverview*
parameter in inn.conf exists and is empty. Otherwise, rename the
current one (to backup existing overview data) and re-create
*pathoverview* as the news user.
5. Start ovsqlite-server as the news user.
6. Run "makehistory -O -x -F" and wait for the command to
finish.
7. Start INN and check the logs to make sure everything is fine.
You will normally notice that the active file is renumbered
(rc.news
takes care of that when run after an overview rebuild; otherwise,
manually run "ctlinnd renumber ''").
Enjoy!
--
Julien ?LIE
??Ce qui est fait n'est plus ? faire.??
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 126, Issue 21
********************************************
