On Tue, 15 Jul 2014 13:44:04 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:
> Sword is a library for free Bible software.> It can also be used for other books.
...
> +++ b/testing/sword/01-corediatheke.patch> @@ -0,0 +1,18 @@> +diff --git a/utilities/diatheke/corediatheke.cpp b/utilities/diatheke/corediatheke.cpp> +index 6e05e7c..c2b6efb 100644> +--- a/utilities/diatheke/corediatheke.cpp> ++++ b/utilities/diatheke/corediatheke.cpp> +@@ -454,7 +454,6 @@ void doquery(unsigned long maxverses = -1, unsigned char outputformat = FMT_PLAI> + if (font) { *output << "style=\"font:\"" << font << ";\" " ;}> + if (strcmp(modlocale,locale) !=0 ) { *output << "lang=\"" << modlocale << "\"";}> + *output << ">";> +- }> + } > + > + if (font && (outputformat == FMT_HTML || outputformat == FMT_HTMLHREF || outputformat == FMT_XHTML || outputformat == FMT_THML || outputformat == FMT_CGI)) {> +@@ -498,4 +497,4 @@ void doquery(unsigned long maxverses = -1, unsigned char outputformat = FMT_PLAI> + }> + > + }> +-> ++}
I saw your work with upstream to get this fixed. What I find
interesting is that they didn't catch an error like this upstream. Why
didn't the problem show up on glibc?
musl again causes hidden bugs bubble up to the surface.
Good job!
Applied. Thanks!
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello!
On Tue, Jul 15, 2014 at 9:28 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:
> On Tue, 15 Jul 2014 13:44:04 -0700> Isaac Dunham <ibid.ag@gmail.com> wrote:>>> Sword is a library for free Bible software.>> It can also be used for other books.> ...>>> +++ b/testing/sword/01-corediatheke.patch>> @@ -0,0 +1,18 @@>> +diff --git a/utilities/diatheke/corediatheke.cpp b/utilities/diatheke/corediatheke.cpp>> +index 6e05e7c..c2b6efb 100644>> +--- a/utilities/diatheke/corediatheke.cpp>> ++++ b/utilities/diatheke/corediatheke.cpp>> +@@ -454,7 +454,6 @@ void doquery(unsigned long maxverses = -1, unsigned char outputformat = FMT_PLAI>> + if (font) { *output << "style=\"font:\"" << font << ";\" " ;}>> + if (strcmp(modlocale,locale) !=0 ) { *output << "lang=\"" << modlocale << "\"";}>> + *output << ">";>> +- }>> + }>> +>> + if (font && (outputformat == FMT_HTML || outputformat == FMT_HTMLHREF || outputformat == FMT_XHTML || outputformat == FMT_THML || outputformat == FMT_CGI)) {>> +@@ -498,4 +497,4 @@ void doquery(unsigned long maxverses = -1, unsigned char outputformat = FMT_PLAI>> + }>> +>> + }>> +->> ++}>> I saw your work with upstream to get this fixed. What I find> interesting is that they didn't catch an error like this upstream. Why> didn't the problem show up on glibc?>> musl again causes hidden bugs bubble up to the surface.>> Good job!>> Applied. Thanks!>> -nc
Since this package was added to testing, there was a discussion on an
IRC channel where this software became interesting to test, as I
wanted to factcheck some things being claimed on it.
Unfortunately, I discovered that after installing sword and
sword-utils, and then running:
user$ installmgr -init
[...]
user$ installmgr -r CrossWire
user$ installmgr -ri CrossWire KJV
Then doing a query using diatheke:
user$ diatheke -b KJV -k ...
Nothing came up. Running strace(1) on diatheke showed it required the
data files to be installed as root before the software would function
correctly.
With the software configured as root, it functions correctly, however
I believe this is a policy violation as software is typically supposed
to be accessible to the user without configuration systemwide, and
installmgr does *something* with the data it downloads when running as
a user.
I am not sure about why it is malfunctioning, if you have any feedback
let me know.
- kaniini
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Wed, Jul 16, 2014 at 12:51:21AM -0500, William Pitcock wrote:
> Hello!> > On Tue, Jul 15, 2014 at 9:28 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:> > On Tue, 15 Jul 2014 13:44:04 -0700> > Isaac Dunham <ibid.ag@gmail.com> wrote:> >> >> Sword is a library for free Bible software.> >> It can also be used for other books.> > ...> >> > Since this package was added to testing, there was a discussion on an> IRC channel where this software became interesting to test, as I> wanted to factcheck some things being claimed on it.> > Unfortunately, I discovered that after installing sword and> sword-utils, and then running:> > user$ installmgr -init> [...]> user$ installmgr -r CrossWire> user$ installmgr -ri CrossWire KJV> > Then doing a query using diatheke:> > user$ diatheke -b KJV -k ...> > Nothing came up. Running strace(1) on diatheke showed it required the> data files to be installed as root before the software would function> correctly.> > With the software configured as root, it functions correctly, however> I believe this is a policy violation as software is typically supposed> to be accessible to the user without configuration systemwide, and> installmgr does *something* with the data it downloads when running as> a user.
installmgr installs "modules" to a configured location.
This location is set by DataPath and extended by AddDataPath in the
[INSTALL] section.
/etc/sword.conf points it at /usr/share/sword; this is not writeable.
I'm not aware of any way to point it at a sane default that everyone can use.
If there are NO config files, it will look for ~/.sword/mods.d, and install
into ~/.sword/modules.
installmgr won't work right unless it can find mods.conf or a writeable
mods.d directory in the DataPath.
If it can figure out where it /should/ put modules, it will run,
downloading the modules to a per-repository location.
Then it will move them into location or silently delete them.
Now I need to figure out what's the right fix.
I guess installmgr should error out if it can't write somewhere.
Debian's approach is to require at least one package containing a
SWORD module.
Thanks,
Isaac Dunham
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello!
On Wed, Jul 16, 2014 at 4:22 PM, Isaac Dunham <ibid.ag@gmail.com> wrote:
> installmgr installs "modules" to a configured location.> This location is set by DataPath and extended by AddDataPath in the> [INSTALL] section.> /etc/sword.conf points it at /usr/share/sword; this is not writeable.> I'm not aware of any way to point it at a sane default that everyone can use.> If there are NO config files, it will look for ~/.sword/mods.d, and install> into ~/.sword/modules.
Why not patch it to prefer ~/.sword/mods.d by default? I could
imagine the upstream developers finding that useful too.
> installmgr won't work right unless it can find mods.conf or a writeable> mods.d directory in the DataPath.> If it can figure out where it /should/ put modules, it will run,> downloading the modules to a per-repository location.> Then it will move them into location or silently delete them.>> Now I need to figure out what's the right fix.> I guess installmgr should error out if it can't write somewhere.> Debian's approach is to require at least one package containing a> SWORD module.
I don't like this, simply because it's creating a package for some
datafiles, which in this case seems odd to me since installmgr is
available.
One thing we could do is simply have a prompt in the post-install
script saying that you must install the modules you want as root. A
couple of other packages do this when they require post-install
configuration.
- kaniini
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Wed, 16 Jul 2014 14:22:49 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:
> On Wed, Jul 16, 2014 at 12:51:21AM -0500, William Pitcock wrote:> > Hello!> > > > On Tue, Jul 15, 2014 at 9:28 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:> > > On Tue, 15 Jul 2014 13:44:04 -0700> > > Isaac Dunham <ibid.ag@gmail.com> wrote:> > >> > >> Sword is a library for free Bible software.> > >> It can also be used for other books.> > > ...> > >> > > > Since this package was added to testing, there was a discussion on an> > IRC channel where this software became interesting to test, as I> > wanted to factcheck some things being claimed on it.> > > > Unfortunately, I discovered that after installing sword and> > sword-utils, and then running:> > > > user$ installmgr -init> > [...]> > user$ installmgr -r CrossWire> > user$ installmgr -ri CrossWire KJV> > > > Then doing a query using diatheke:> > > > user$ diatheke -b KJV -k ...> > > > Nothing came up. Running strace(1) on diatheke showed it required the> > data files to be installed as root before the software would function> > correctly.> > > > With the software configured as root, it functions correctly, however> > I believe this is a policy violation as software is typically supposed> > to be accessible to the user without configuration systemwide, and> > installmgr does *something* with the data it downloads when running as> > a user.> > installmgr installs "modules" to a configured location.> This location is set by DataPath and extended by AddDataPath in the> [INSTALL] section.> /etc/sword.conf points it at /usr/share/sword; this is not writeable.> I'm not aware of any way to point it at a sane default that everyone can use.> If there are NO config files, it will look for ~/.sword/mods.d, and install> into ~/.sword/modules.> > installmgr won't work right unless it can find mods.conf or a writeable> mods.d directory in the DataPath.> If it can figure out where it /should/ put modules, it will run,> downloading the modules to a per-repository location.> Then it will move them into location or silently delete them.> > Now I need to figure out what's the right fix.> I guess installmgr should error out if it can't write somewhere.> Debian's approach is to require at least one package containing a> SWORD module.
How about using /var/lib/sword as default and have a
'sword' group with write permissions there?
They you can just add your users to the sword group to be able to
install the data files.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Tue, Jul 22, 2014 at 02:27:28PM +0200, Natanael Copa wrote:
> On Wed, 16 Jul 2014 14:22:49 -0700> Isaac Dunham <ibid.ag@gmail.com> wrote:> > installmgr installs "modules" to a configured location.> > This location is set by DataPath and extended by AddDataPath in the> > [INSTALL] section.> > /etc/sword.conf points it at /usr/share/sword; this is not writeable.> > I'm not aware of any way to point it at a sane default that everyone can use.> > If there are NO config files, it will look for ~/.sword/mods.d, and install> > into ~/.sword/modules.> > > > installmgr won't work right unless it can find mods.conf or a writeable> > mods.d directory in the DataPath.> > If it can figure out where it /should/ put modules, it will run,> > downloading the modules to a per-repository location.> > Then it will move them into location or silently delete them.> > > > Now I need to figure out what's the right fix.> > I guess installmgr should error out if it can't write somewhere.> > Debian's approach is to require at least one package containing a> > SWORD module.> > How about using /var/lib/sword as default and have a> 'sword' group with write permissions there?> > They you can just add your users to the sword group to be able to> install the data files.>
That should work.
One question/minor issue:
abuild warns about chown in the post-install script.
But it would seem that there's no other sane way to make sure that
/var/lib/sword belongs to the "sword" group: to make it belong to
root:sword in the package, this group must exist when the package is
built and when it is extracted.
I presume pre-install could do the latter, but manipulating groups in
a build script is insanity.
If I can ignore that warning (assuming it belongs in abuild), I have a
script ready to go.
What's the preferred approach?
Thanks,
Isaac Dunham
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Wed, Jul 23, 2014 at 08:19:36AM +0300, Timo Teras wrote:
> On Tue, 22 Jul 2014 21:01:42 -0700> Isaac Dunham <ibid.ag@gmail.com> wrote:> > > On Tue, Jul 22, 2014 at 02:27:28PM +0200, Natanael Copa wrote:> > > How about using /var/lib/sword as default and have a> > > 'sword' group with write permissions there?> > > > > > They you can just add your users to the sword group to be able to> > > install the data files.> > > > > That should work.> > One question/minor issue:> > > > abuild warns about chown in the post-install script.> > > > But it would seem that there's no other sane way to make sure that> > /var/lib/sword belongs to the "sword" group: to make it belong to> > root:sword in the package, this group must exist when the package is> > built and when it is extracted.> > I presume pre-install could do the latter, but manipulating groups in> > a build script is insanity.> > > > If I can ignore that warning (assuming it belongs in abuild), I have a> > script ready to go.> > > > What's the preferred approach?> > Use pkgusers and pkggroups in APKBUILD, and do chown in the package()> or subpkg split function. See 'transmission' or any other package with> pkgusers in it for an example. And create the user in pre-install> script.> > This allows apk to keep track of the file permissions properly.> Doing chown in post-install would make the file permissions mismatch> with what is in the apk database, and thus make 'apk audit' give> spurious results.
Ok, thanks for the explanation. Patch should be incoming as soon as I've
built and tested it.
...
I might drop clucene as a build dependency, since sword seems to pick up
the libc regex interface. But I'd rather not do that right now.
Thanks,
Isaac Dunham
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Tue, 22 Jul 2014 21:01:42 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:
> On Tue, Jul 22, 2014 at 02:27:28PM +0200, Natanael Copa wrote:> > How about using /var/lib/sword as default and have a> > 'sword' group with write permissions there?> > > > They you can just add your users to the sword group to be able to> > install the data files.> > > That should work.> One question/minor issue:> > abuild warns about chown in the post-install script.> > But it would seem that there's no other sane way to make sure that> /var/lib/sword belongs to the "sword" group: to make it belong to> root:sword in the package, this group must exist when the package is> built and when it is extracted.> I presume pre-install could do the latter, but manipulating groups in> a build script is insanity.> > If I can ignore that warning (assuming it belongs in abuild), I have a> script ready to go.> > What's the preferred approach?
Use pkgusers and pkggroups in APKBUILD, and do chown in the package()
or subpkg split function. See 'transmission' or any other package with
pkgusers in it for an example. And create the user in pre-install
script.
This allows apk to keep track of the file permissions properly.
Doing chown in post-install would make the file permissions mismatch
with what is in the apk database, and thus make 'apk audit' give
spurious results.
- Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---