[sword-devel] Xiphos 3.2.1

[Karl Kleinpaste]

Released a little while ago. Source tarball and Win32 installer at
https://sourceforge.net/projects/gnomesword/files/Xiphos/3.2.1/. Also
binary tarballs for Fedora and Ubuntu, as hack interim solutions in
place of real package solutions. (We lack an Ubuntu packager; and
unknown how long it will take for Fedora packages to get around.)

See README there for short summary of what's happened lately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140606/fabc6702/attachment.html>

[Matěj Cepl]

Post by Karl Kleinpaste
Released a little while ago. Source tarball and Win32 installer at
https://sourceforge.net/projects/gnomesword/files/Xiphos/3.2.1/. Also
binary tarballs for Fedora and Ubuntu, as hack interim solutions in
place of real package solutions. (We lack an Ubuntu packager; and
unknown how long it will take for Fedora packages to get around.)

I am trying to figure out the Fedora builds in
http://copr.fedoraproject.org/coprs/mcepl/xiphos-3.2.1/ (I do
have builds for RHEL-7 and Fedora >= 20, others I have to figure
out yet). When I will be done, I will attach patches to the Red
Hat Bugzilla bugs and/or build the packages myself (I can do it,
although I am not a maintainer of the packages in question).

Meanwhile, could I ask anybody to take a look at the crashes we
have in Bugzilla? Are https://bugzilla.redhat.com/801979,
https://bugzilla.redhat.com/1085621, and
https://bugzilla.redhat.com/1098005 all caused by some of our
packaging issues, or are they genuine crashes?

Best,

Mat?j

[Karl Kleinpaste]

Post by Matěj Cepl
I am trying to figure out the Fedora builds in
http://copr.fedoraproject.org/coprs/mcepl/xiphos-3.2.1/ (I do
have builds for RHEL-7 and Fedora >= 20, others I have to figure
out yet). When I will be done, I will attach patches to the Red
Hat Bugzilla bugs and/or build the packages myself (I can do it,
although I am not a maintainer of the packages in question).

Greg is lately the regular producer of Fedora builds. Primarily he's
building for Rawhide; out of a need for folks to get current state when
they're in F20 and even F19 (which is where I am), I've begun building
my own and making them available on Xiphos' SourceForge files.

Post by Matěj Cepl
Meanwhile, could I ask anybody to take a look at the crashes we
have in Bugzilla? Are https://bugzilla.redhat.com/801979,
https://bugzilla.redhat.com/1085621, and
https://bugzilla.redhat.com/1098005 all caused by some of our
packaging issues, or are they genuine crashes?

Hm...

801979: That is from a version old enough that we no longer have or use
gecko at all. It dates from xulrunner. We use only WebKit now, and
have for a few years. No longer relevant.

1085621: A crash on exit. Not sure what to do about that. Xiphos has
shutdown the Sword backend, the GUI frontend, and told GTK to quit, and
now just wants to leave. I'll look into it but I'm mostly confused by
this: There are 60+ frames of nonsense above Xiphos' call to exit, and
perversely that includes the top 35 frames as being ... KDE
initialization. Does the phrase "um, what?" mean the same thing to
others as it means to me? Xiphos is a GNOME/GTK/GLib app. I can't
begin to guess what KDE is doing in the picture.

#34 0xa845141f in libmodman::module_manager::load_file
(this=this at entry=0x9223ed8,
filename="*/usr/lib/libproxy/0.4.11/modules/config_kde4.so*",
symbreq=symbreq at entry=true) at
/usr/src/debug/libmodman-2.0.1/libmodman/module_manager.cpp:278
mod_info = 0xa85100f4 <mm_info_>
#35 0xa8451998 in libmodman::module_manager::load_dir
#36 0xa8461392 in libproxy::proxy_factory::proxy_factory
(this=0x9223ec0) at /usr/src/debug/libproxy-0.4.11/libproxy/proxy.cpp:165
module_dir = 0xa8471670 "/usr/lib/libproxy/0.4.11/modules"
#37 0xa8461f18 in pxProxyFactory_
#39 0xaa5801b5 in g_libproxy_resolver_init
#40 0xb75fd7de in g_type_create_instance
#41 0xb75df796 in g_object_new_internal
#42 0xb75e1859 in g_object_newv
#43 0xb75e1f70 in g_object_new

1098005: I've stared at this backtrace a while, and it's troublesome to
me. The last (only) source lines being executed are
xiphos_html_new
gui_create_bible_pane
create_mainwindow
main
and this is something I've never seen fail anywhere, ever. All Xiphos
is doing at this point is obtaining its first HTML widget. Above this
are 19 frames of GLib and WebKit nightmares. Considering that this has
never been a problem for Xiphos anywhere else, I'm inclined to point the
finger at WebKit internals. I think this seems supported by the fact
that the crash is pointed out at the bottom as
=> 0xb51780a1 <+33>: movl $0x0,0xbbadbeef
"bad beef" is surely somebody's internal consistency marker, and it's
not Xiphos'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140611/1015c98b/attachment-0001.html>

[Matěj Cepl]

Post by Karl Kleinpaste
Greg is lately the regular producer of Fedora builds.
Primarily he's
building for Rawhide; out of a need for folks to get current state when
they're in F20 and even F19 (which is where I am), I've begun building
my own and making them available on Xiphos' SourceForge files.

That is not The Fedora Way? ? I have been always proud, that in
Fedora it is useless to have PPAs, because we have one shared
PPA on which everybody can work ? the Fedora itself.

Couldn?t we just make single-spec package (with some %ifs if
necessary) building on supported Fedoras (F19, F20, Rawhide, at
the moment) and the last EPEL (for a moment, I would support
EPEL-6 as well, but after half-a-year or so I would stick with
just EPEL-7)?

Would anybody mind if I just build the latest sword and xiphos
for these repos?

Post by Karl Kleinpaste

Post by Matěj Cepl
Meanwhile, could I ask anybody to take a look at the crashes we
have in Bugzilla? Are https://bugzilla.redhat.com/801979,
https://bugzilla.redhat.com/1085621, and
https://bugzilla.redhat.com/1098005 all caused by some of our
packaging issues, or are they genuine crashes?

Hm...
801979: That is from a version old enough that we no longer have or use
gecko at all. It dates from xulrunner. We use only WebKit now, and
have for a few years. No longer relevant.

So, should I close it as CANTFIX (or WONTFIX)?

Post by Karl Kleinpaste
1085621: A crash on exit. Not sure what to do about that. Xiphos has
shutdown the Sword backend, the GUI frontend, and told GTK to quit, and
now just wants to leave. I'll look into it but I'm mostly confused by
this: There are 60+ frames of nonsense above Xiphos' call to exit, and
perversely that includes the top 35 frames as being ... KDE
initialization. Does the phrase "um, what?" mean the same thing to
others as it means to me? Xiphos is a GNOME/GTK/GLib app. I can't
begin to guess what KDE is doing in the picture.

So needinfo asking what?s the relevance of KDE? Does the GUI
uses something weird like ?Gnome theme making Gnome apps looking
like KDE ones? (what?s its name)? It used to lead to many
crashes, but I don?t know if such animal still exists in
KDE4/Gnome3 world.

Best,

Mat?j

[Karl Kleinpaste]

Post by Matěj Cepl
That is not The Fedora Way? ? I have been always proud, that in
Fedora it is useless to have PPAs, because we have one shared
PPA on which everybody can work ? the Fedora itself.
Couldn?t we just make single-spec package (with some %ifs if
necessary) building on supported Fedoras (F19, F20, Rawhide, at
the moment) and the last EPEL (for a moment, I would support
EPEL-6 as well, but after half-a-year or so I would stick with
just EPEL-7)?
Would anybody mind if I just build the latest sword and xiphos
for these repos?

As Greg and I have chatted in IRC, the perspective he's offered is that
building for older releases is for bug and security vulnerabilities. I
disagree with this, but if that's Policy, I don't have a lot of say.
Obviously there are bug fixes in each release, and I would think that
justifies building for all currently-supported releases. That's why I
built Sword and Xiphos packages last evening for F19, which I've now
been told work fine on F20, too.

I of course won't mind if current versions get built for the official repos.

Post by Matěj Cepl
So, should I close it as CANTFIX (or WONTFIX)?

I would say "already fixed, by abandoning an old toolkit" but you can
pick whatever notation is appropriate.

Post by Matěj Cepl
So needinfo asking what?s the relevance of KDE? Does the GUI
uses something weird like ?Gnome theme making Gnome apps looking
like KDE ones? (what?s its name)? It used to lead to many
crashes, but I don?t know if such animal still exists in
KDE4/Gnome3 world.

I'm unaware of any such animal at all. From my perspective, any
interaction with KDE is simply wrong. So yes, need to understand how
libproxy comes into the picture in the first place, and why it wants to
interact with KDE. Xiphos has no proxy support at all -- why is
anything down there asking for /either/ libproxy /or /KDE?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140611/15076bee/attachment.html>

[Greg Hellings]

On Wed, Jun 11, 2014 at 9:27 AM, Karl Kleinpaste <karl at kleinpaste.org>

Post by Matěj Cepl
That is not The Fedora Way? ? I have been always proud, that in
Fedora it is useless to have PPAs, because we have one shared
PPA on which everybody can work ? the Fedora itself.
Couldn?t we just make single-spec package (with some %ifs if
necessary) building on supported Fedoras (F19, F20, Rawhide, at
the moment) and the last EPEL (for a moment, I would support
EPEL-6 as well, but after half-a-year or so I would stick with
just EPEL-7)?
Would anybody mind if I just build the latest sword and xiphos
for these repos?
As Greg and I have chatted in IRC, the perspective he's offered is that
building for older releases is for bug and security vulnerabilities. I
disagree with this, but if that's Policy, I don't have a lot of say.
Obviously there are bug fixes in each release, and I would think that
justifies building for all currently-supported releases. That's why I
built Sword and Xiphos packages last evening for F19, which I've now been
told work fine on F20, too.
I of course won't mind if current versions get built for the official repos.

I'm just going off of what
http://fedoraproject.org/wiki/Updates_Policy#Philosophy this has to say.
For release n-1 (Fedora 19) the guidelines specifically state:


- Push only major bug fixes and security fixes to release(n-1).


So I think this definitely rules out making "official" packages for Fedora
19. And the language there seems to indicate to me that building for Fedora
20 would not be encouraged mainly because Xiphos 3.2 requires sword 1.7.3
and the sword engine is not a "leaf node" as BibleTime would also depend on
it. Now, these rules are not tightly enforced for things like the Sword and
Xiphos packages, but unless there is a consensus that there are major bugs
fixed from Sword 1.7.2 to 1.7.3 and/or that there are major bugs in Xiphos
3.1.6 that are fixed in 3.2 I would rather not package for the current
release. If there are some major show-stopping bugs fixed then I'll gladly
merge down the new package to Fedora 20 and kick off the Bodhi updates.

--Greg

Post by Matěj Cepl
So, should I close it as CANTFIX (or WONTFIX)?
I would say "already fixed, by abandoning an old toolkit" but you can pick
whatever notation is appropriate.
So needinfo asking what?s the relevance of KDE? Does the GUI
uses something weird like ?Gnome theme making Gnome apps looking
like KDE ones? (what?s its name)? It used to lead to many
crashes, but I don?t know if such animal still exists in
KDE4/Gnome3 world.
I'm unaware of any such animal at all. From my perspective, any
interaction with KDE is simply wrong. So yes, need to understand how
libproxy comes into the picture in the first place, and why it wants to
interact with KDE. Xiphos has no proxy support at all -- why is anything
down there asking for *either* libproxy *or *KDE?
_______________________________________________
sword-devel mailing list: sword-devel at crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140611/d561645d/attachment.html>

[Matěj Cepl]

Post by Karl Kleinpaste
As Greg and I have chatted in IRC, the perspective he's offered is that
building for older releases is for bug and security vulnerabilities. I
disagree with this, but if that's Policy, I don't have a lot of say.
Obviously there are bug fixes in each release, and I would think that
justifies building for all currently-supported releases. That's why I
built Sword and Xiphos packages last evening for F19, which I've now
been told work fine on F20, too.

OK, Greg is the official maintainer so it is his decision how he wants
to maintain the package. I would just say that this policy is not
followed even for most desktop end-user packages. Just looking into our
internal build system and we have firefox-24.6.0-1.el5_10 (and planning
31, when it will be ESR). That's for RHEL-5 which is otherwise closed
for anything else than grave bugs.

The problem with desktop programs is that they are getting much sooner
obsolete than the ?server? packages. We could have
coreutils-5.97-34.el5_8.1 (if I am not mistaken, this is the last RHEL-5
version) and kernel 2.6.8, while we have 8.22 and 3.10.0 in the
yesterday released RHEL-7, and nobody cares. When there were obsolete
versions of Firefox (mozilla 0.9 in RHEL-2 as far as I remember, and I
believe Firefox 2 in RHEL-5) we heard complaints of our customers loud
and clear.

However, as I have said, it?s Greg?s call to make.

Best,

Mat?j

[Matěj Cepl]

Post by Matěj Cepl
versions of Firefox (mozilla 0.9 in RHEL-2 as far as I remember, and I
believe Firefox 2 in RHEL-5) we heard complaints of our customers loud
and clear.

Actually http://distrowatch.org/weekly.php?issue=20101206#feature says
it was 3.6.9

Mat?j

[Matěj Cepl]

Post by Matěj Cepl
Actually http://distrowatch.org/weekly.php?issue=20101206#feature says
it was 3.6.9

Damn that?s RHEL 6.0. RHEL 5.0 had firefox-1.5.0.9-10.el5

Mat?j