Re: [xiphos-devel] 4.2.0 tagged and pushed
Just a quick status update on this — over the weekend I was finally granted some missing permissions on Launchpad. I think I now have what we need to make this happen. On Sat, May 9, 2020 at 4:52 AM ref...@gmx.net wrote: > This is not relevant here in terms of Xiphos, but gobiblecreator was a > Crosswire maintained programme a decade and a half ago when mobile phones > ran at best a J2ME engine. Look that up. > > GoBible was our answer to that. David Haslam and I produced dozens and > dozens of Bible apps for such phones. A Australian guy called Jolon had > originally created GoBible and GoBibleCreator and we inherited it. > > Sent from my mobile. Please forgive shortness, typos and weird > autocorrects. > > > Original Message > Subject: Re: [xiphos-devel] 4.2.0 tagged and pushed > From: Caleb Maclennan > To: Xiphos developers > CC: > > > On Sat, May 9, 2020 at 12:45 AM Greg Hellings > wrote: > >> I would stick with just updating the existing ones. It shouldn't be hard >> to drop in a new Sword, BibleTime, and Xiphos (I assume those are the three >> packages in the PPA?) >> > > It's just a bit messier than that. There is a long since discontinued gtk > edition of bibledit, there is something called gobiblecreator which I don't > recognize, there is a custom version of dh-autoreconf as a package which > has no business in there, and most strangely a _package_ called > "crosswire-ppa". How a package with that name ends up in a ppa of that name > and what it does is a mystery. > > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] why produce tar files?
To ease testing purposes it's possible we could add a third fallback on a dummy version number so that a raw source archive with no history or build information could be built. This might be confusing for end users however, I kind of prefer actually _failing_ to build if they are doing it wrong rather than ending up with a successful build with garbage information. For local testing purposes it's actually really easy to make a git-archive buildable yourself, you just have to inject the version information. Just `echo 0.0.0 > cmake/source_version.txt` after you extract. For now that's the only blocker. For CI testing purposes I think actually testing the whole process on the generated source_package as we distribute to users is preferable. There are a couple other things we could be doing with the built package source that are impossible with git archives. One we could do signed releases. Two we could get the rest of the vendored code out of the main git tree while still including it in in the built sources. More come to mind, but suffice it to say I think this is the right architecture. On Mon, May 11, 2020 at 9:55 AM Greg Hellings wrote: > > > On Mon, May 11, 2020 at 1:23 AM Caleb Maclennan wrote: > >> Because the Git generated archive of the raw repository contents is not >> the same contents as the generated source packages. Specifically the former >> has no information about what version it is. The two ways to get this >> information are to have git history (i.e. you can use a clone of the >> repository to build) or to have a source build that has this generated >> information present (i.e. our generated version specific tarballs that have >> the relevant information cached inside). >> > > I do want to say: it's a bit of a nuisance to do testing this way, though. > In order to generate a source tar, I have to successfully run CMake against > the tree, which means I need all the devel dependencies installed on my > machine. It's not impossible, but it is a bit of a pain. I'm all in favor > of the CPack generators for Windows installers, but it's not terribly > convenient for the source tar generation. > > --Greg > >> >> >> On Sun, May 10, 2020 at 5:41 PM Karl Kleinpaste >> wrote: >> >>> github release process automatically produces tarfiles, zip and tar.gz. >>> Yet our release machinery also produces tarfiles, tar.gz and tar.xz. >>> Why? >>> ___ >>> xiphos-devel mailing list >>> xiphos-devel@crosswire.org >>> http://www.crosswire.org/mailman/listinfo/xiphos-devel >>> >> ___ >> xiphos-devel mailing list >> xiphos-devel@crosswire.org >> http://www.crosswire.org/mailman/listinfo/xiphos-devel >> > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] why produce tar files?
Because the Git generated archive of the raw repository contents is not the same contents as the generated source packages. Specifically the former has no information about what version it is. The two ways to get this information are to have git history (i.e. you can use a clone of the repository to build) or to have a source build that has this generated information present (i.e. our generated version specific tarballs that have the relevant information cached inside). On Sun, May 10, 2020 at 5:41 PM Karl Kleinpaste wrote: > github release process automatically produces tarfiles, zip and tar.gz. > Yet our release machinery also produces tarfiles, tar.gz and tar.xz. > Why? > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] 4.2.0 tagged and pushed
On Sat, May 9, 2020 at 2:02 AM Karl Kleinpaste wrote: > If any of it has modtimes longer than maybe 6 months ago, it's too old to > be interesting or worthwhile. > The range is 2009-2012. That's a wee bit longer than 6 months ago unless my brain is having a hard time with math at 2 am. Maybe Greg can comment to this better than I can, but I believe all the packages in a PPA have tags for which version of Ubuntu they are targeting and that if people add this existing PPA to a machine updated in the last decade they won't even see any of these packages. Is that right? This stuff is all targeting 8.04 through 12.04. The package list in question is here: https://launchpad.net/~pkgcrosswire/+archive/ubuntu/ppa I don't currently have access to nuke individual packages (although oddly enough it looks like I could drop the whole PPA). I think I can freshen up the Sword & Xiphos targeting 20.04 and I guess add BibleSync and GTKHTML. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] 4.2.0 tagged and pushed
On Sat, May 9, 2020 at 12:45 AM Greg Hellings wrote: > I would stick with just updating the existing ones. It shouldn't be hard > to drop in a new Sword, BibleTime, and Xiphos (I assume those are the three > packages in the PPA?) > It's just a bit messier than that. There is a long since discontinued gtk edition of bibledit, there is something called gobiblecreator which I don't recognize, there is a custom version of dh-autoreconf as a package which has no business in there, and most strangely a _package_ called "crosswire-ppa". How a package with that name ends up in a ppa of that name and what it does is a mystery. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] 4.2.0 tagged and pushed
On Sat, May 9, 2020 at 12:20 AM Greg Hellings wrote: > Use pkgcrosswire, as ugly as that might be to us. It has history, I > believe it's where packages have long been held. > Thanks for the input Greg. Can you clarify whether you would suggest stuffing new packages into the existing ppa:pkgcrosswire/ppa namespace alongside the obsolete stuff or adding a clean PPA just for Xiphos and its direct dependencies such as ppa:pkgcrosswire/xiphos? I can definitely pursue that direction, although at the moment I wasn't actually given enough permissions to go either of those two routes. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] Xiphos unusable on Archlinux
You should try it again now ;-) There have been upstream releases and the Arch packaging is cleaned up to match! On Mon, Jul 10, 2017 at 4:10 PM yvand wrote: > I am running *xiphos-git*. I just tried *xiphos-gtk3* but it is also > broken, the same way. > I didn't manage to install the package *xiphos* (because of conflicts in > dependencies). > > --yvand > > Le 10/07/2017 à 11:40, Caleb Maclennan a écrit : > > Yvand are you running the xiphos, xiphos-git, or xiphos-gtk3 package from > the AUR? Have you tried one of the other packages? > > I can confirh that xiphos-gtk3-4.0.4-1 as of the last time I compiled it > was pretty non-functional, but I seem to recal the 2 version (which is what > you should get on the base package) working fine. > > Caleb > > yvand wrote: > > Hi all, > > Since several months, Xiphos is completely broken and unusable on > ArchLinux. My archlinux is uptodate and sword+xiphos comes from AUR > (sword-svn and xiphos-git packages). > > Indeed Xiphos is unusable, because : > > - when I select a chapter, it is EXTREMELY slow (except in the parallel > view) > - notes does not work (nothing in preview pane) > - left pane broken : impossible to select a bible/commentary in the left > panel (click on items does not work !) + buttons "Modules", "Search"… does > not work (nothing happens) > > Here is a screencast : https://yapper.fr/~yvand/xiphos-frejnd.ogv > > Why Xiphos is so buggy on my system ? I tried both Xorg and Wayland in GDM > but none works fine. > > yvand > > > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > > > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > > > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] 4.2.0 tagged and pushed
The guy that wrote this dropped by the #xiphos IRC channel today: https://linuxsagas.digitaleagle.net/2020/05/08/xiphos-on-ubuntu-20-04/ Nice simple writeup on installing Xiphos from source on Ubuntu 20.04 ... until such a time as there are packages! On Fri, May 8, 2020 at 2:07 PM Caleb Maclennan wrote: > And before anybody chimes in, yes I'm aware there are yet more namespaces > already floating around on launchpad. There is a "crosswire-misc" project, > a "~pkg-crosswire-devel" team, and half a dozen "xiphos-something" projects > users have spawned building their own PPAs. I would ignore all the bits > except the ones I mentioned before and gradually hope to > cleanup/consolidate/obsolete them in favor of clearly named canonical > namespaces for the various resources. > > I also forgot to mention my third recommendation: the least disruptive > solution(s) possible are to use the existing "xiphos-devel" or > "pkgcrosswire" team team space and add a new PPA (either "xiphos-devel/ppa" > or "pkgcrosswire/xiphos" and setup packaging there. No renames to existing > launchpad stuff, just a new new fresh PPA and leave the existing archaic > Crosswire PPAs to be cleaned up later. > > On Fri, May 8, 2020 at 1:50 PM Caleb Maclennan wrote: > >> A couple days ago I updated the Arch Linux AUR package build to 4.2.0 >> (now 4.2.1) and also posted pre-compiled packages to my user repository, >> see https://aur.archlinux.org/packages/xiphos. I'm also working on >> getting Xiphos included in the default Arch [community] repository, but it >> looks like that is probably going to get held up until the issue with >> GTKHTML is resolved. Having deprecated that monstrosity from [community] to >> AUR some time back nobody wants to see it moving the other way (myself >> included). If and when that gets removed as a dependency it's quite likely >> we'll be able to get Xiphos into the mainline repository. >> >> There are now just a few distros to go, see >> https://repology.org/project/xiphos/versions! >> >> *On the subject of Ubuntu packaging I*'ve been granted access to most of >> the Xiphos related shenanigans on Launchpad. I'm sorry for all ya'll Ubuntu >> folks because wow is Launchpad a disaster. Through no particular fault even >> of the original configuration (which took the shotgun approach of >> registering every project and team name variant possible) and really just a >> function of how bizarre Launchpad's namespacing is, there doesn't seem to >> be what I would consider an ideal way to name an official Xiphos PPA. So >> request for comment on the options as I see them... >> >> For background Launchpad has two basic namespaces: projects and users. >> Users can, pretty much interchangeably, be individuals or teams. Each has a >> different URL namespace (projects are / and users/teams are >> /~). So far so good. The trouble is that even though they are >> different types and have different namespaces, Launchpad cross checks users >> against projects so you cannot register a team name with the same name as a >> project. Weird (especially since the error messages don't indicate this is >> the issue, it just says another "user" is registered with that name even >> when the offending conflict is a project). Even that might have been okay, >> but Launchpad does not allow projects to have PPAs, only users/teams can >> host PPAs. >> >> 1. There is a project called "xiphos". This is logical enough, but it >> means we can't host a PPA called "xiphos/ppa", it has to be something else. >> 2. There is a team registered called "xiphos-devel". This makes (some) >> sense as a team name, but less sense as a PPA namespace for official >> builds. We could put a PPA under this namespace called "xiphos-devel/ppa" >> or "xiphos-devel/xiphos" or something like that (I think the former is more >> Ubuntu ideomatic). >> 3. There is (very unfortunately and completely uselessly) a _project_ >> called "crosswire". This should have been registered as team not a project, >> but I'm not sure we can fix that. Maybe we can ... but it would involve >> some renames. >> 4. Probably born out of the the conflict with 3, there is a team called >> "pkgcrosswire" that hosts PPAs. One of these is the default stable channel >> PPA called "pkgcrosswire/ppa". This has Xiphos already, albeit in a very >> dated form (circa 2012). Everything else in there is dated too. >> >> My personal recommendation is to attempt to ⓐ rename the "crosswire&
Re: [xiphos-devel] 4.2.0 tagged and pushed
And before anybody chimes in, yes I'm aware there are yet more namespaces already floating around on launchpad. There is a "crosswire-misc" project, a "~pkg-crosswire-devel" team, and half a dozen "xiphos-something" projects users have spawned building their own PPAs. I would ignore all the bits except the ones I mentioned before and gradually hope to cleanup/consolidate/obsolete them in favor of clearly named canonical namespaces for the various resources. I also forgot to mention my third recommendation: the least disruptive solution(s) possible are to use the existing "xiphos-devel" or "pkgcrosswire" team team space and add a new PPA (either "xiphos-devel/ppa" or "pkgcrosswire/xiphos" and setup packaging there. No renames to existing launchpad stuff, just a new new fresh PPA and leave the existing archaic Crosswire PPAs to be cleaned up later. On Fri, May 8, 2020 at 1:50 PM Caleb Maclennan wrote: > A couple days ago I updated the Arch Linux AUR package build to 4.2.0 (now > 4.2.1) and also posted pre-compiled packages to my user repository, see > https://aur.archlinux.org/packages/xiphos. I'm also working on getting > Xiphos included in the default Arch [community] repository, but it looks > like that is probably going to get held up until the issue with GTKHTML is > resolved. Having deprecated that monstrosity from [community] to AUR some > time back nobody wants to see it moving the other way (myself included). If > and when that gets removed as a dependency it's quite likely we'll be able > to get Xiphos into the mainline repository. > > There are now just a few distros to go, see > https://repology.org/project/xiphos/versions! > > *On the subject of Ubuntu packaging I*'ve been granted access to most of > the Xiphos related shenanigans on Launchpad. I'm sorry for all ya'll Ubuntu > folks because wow is Launchpad a disaster. Through no particular fault even > of the original configuration (which took the shotgun approach of > registering every project and team name variant possible) and really just a > function of how bizarre Launchpad's namespacing is, there doesn't seem to > be what I would consider an ideal way to name an official Xiphos PPA. So > request for comment on the options as I see them... > > For background Launchpad has two basic namespaces: projects and users. > Users can, pretty much interchangeably, be individuals or teams. Each has a > different URL namespace (projects are / and users/teams are > /~). So far so good. The trouble is that even though they are > different types and have different namespaces, Launchpad cross checks users > against projects so you cannot register a team name with the same name as a > project. Weird (especially since the error messages don't indicate this is > the issue, it just says another "user" is registered with that name even > when the offending conflict is a project). Even that might have been okay, > but Launchpad does not allow projects to have PPAs, only users/teams can > host PPAs. > > 1. There is a project called "xiphos". This is logical enough, but it > means we can't host a PPA called "xiphos/ppa", it has to be something else. > 2. There is a team registered called "xiphos-devel". This makes (some) > sense as a team name, but less sense as a PPA namespace for official > builds. We could put a PPA under this namespace called "xiphos-devel/ppa" > or "xiphos-devel/xiphos" or something like that (I think the former is more > Ubuntu ideomatic). > 3. There is (very unfortunately and completely uselessly) a _project_ > called "crosswire". This should have been registered as team not a project, > but I'm not sure we can fix that. Maybe we can ... but it would involve > some renames. > 4. Probably born out of the the conflict with 3, there is a team called > "pkgcrosswire" that hosts PPAs. One of these is the default stable channel > PPA called "pkgcrosswire/ppa". This has Xiphos already, albeit in a very > dated form (circa 2012). Everything else in there is dated too. > > My personal recommendation is to attempt to ⓐ rename the "crosswire" > project out of the way, ⓑ rename the "pkgcrosswire" team as "crosswire", ⓒ > add a new PPA in this namespace called "crosswire/xiphos", ⓓ include the > bare minimum Xiphos + direct dependencies, and finally ⓔ mark that new PPA > as a dependency for the default "crosswire/ppa" so that Xiphos is included > there too. Code for the Debian packaging rules could logically go under the > existing "xiphos" project, and the "xiphos-devel" team would be used as is > just for permissions management. I think this
Re: [xiphos-devel] 4.2.0 tagged and pushed
A couple days ago I updated the Arch Linux AUR package build to 4.2.0 (now 4.2.1) and also posted pre-compiled packages to my user repository, see https://aur.archlinux.org/packages/xiphos. I'm also working on getting Xiphos included in the default Arch [community] repository, but it looks like that is probably going to get held up until the issue with GTKHTML is resolved. Having deprecated that monstrosity from [community] to AUR some time back nobody wants to see it moving the other way (myself included). If and when that gets removed as a dependency it's quite likely we'll be able to get Xiphos into the mainline repository. There are now just a few distros to go, see https://repology.org/project/xiphos/versions! *On the subject of Ubuntu packaging I*'ve been granted access to most of the Xiphos related shenanigans on Launchpad. I'm sorry for all ya'll Ubuntu folks because wow is Launchpad a disaster. Through no particular fault even of the original configuration (which took the shotgun approach of registering every project and team name variant possible) and really just a function of how bizarre Launchpad's namespacing is, there doesn't seem to be what I would consider an ideal way to name an official Xiphos PPA. So request for comment on the options as I see them... For background Launchpad has two basic namespaces: projects and users. Users can, pretty much interchangeably, be individuals or teams. Each has a different URL namespace (projects are / and users/teams are /~). So far so good. The trouble is that even though they are different types and have different namespaces, Launchpad cross checks users against projects so you cannot register a team name with the same name as a project. Weird (especially since the error messages don't indicate this is the issue, it just says another "user" is registered with that name even when the offending conflict is a project). Even that might have been okay, but Launchpad does not allow projects to have PPAs, only users/teams can host PPAs. 1. There is a project called "xiphos". This is logical enough, but it means we can't host a PPA called "xiphos/ppa", it has to be something else. 2. There is a team registered called "xiphos-devel". This makes (some) sense as a team name, but less sense as a PPA namespace for official builds. We could put a PPA under this namespace called "xiphos-devel/ppa" or "xiphos-devel/xiphos" or something like that (I think the former is more Ubuntu ideomatic). 3. There is (very unfortunately and completely uselessly) a _project_ called "crosswire". This should have been registered as team not a project, but I'm not sure we can fix that. Maybe we can ... but it would involve some renames. 4. Probably born out of the the conflict with 3, there is a team called "pkgcrosswire" that hosts PPAs. One of these is the default stable channel PPA called "pkgcrosswire/ppa". This has Xiphos already, albeit in a very dated form (circa 2012). Everything else in there is dated too. My personal recommendation is to attempt to ⓐ rename the "crosswire" project out of the way, ⓑ rename the "pkgcrosswire" team as "crosswire", ⓒ add a new PPA in this namespace called "crosswire/xiphos", ⓓ include the bare minimum Xiphos + direct dependencies, and finally ⓔ mark that new PPA as a dependency for the default "crosswire/ppa" so that Xiphos is included there too. Code for the Debian packaging rules could logically go under the existing "xiphos" project, and the "xiphos-devel" team would be used as is just for permissions management. I think this would be the cleanest outcome overall, but it is dependent on 3 things. Launchpad has to support these renames without reserving the old namespaces. Also it means renaming the possible in-use pkgcrosswire/ppa to crosswire/ppa. I doubt this is a serious issue considering the newest packages in there are from 2014, with most being older than that. Lastly I/we need more access to the "crosswire" project. I am am part of the team that controls it now but not an admin/owner so I can't rename it. If that option doesn't sound good to people my next bid would be to consider renaming the "xiphos-devel" team to something more end-user friendly (maybe "xiphos-project" or "xiphos-packages" or something like that) and opening a PPA in there, so the address people would use would be "ppa:xiphos-project/ppa" or similar. The resulting PPA could still be marked as included in "pkgcrosswire/ppa" eventually. Any other suggestions? Am I missing important considerations here? Caleb ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
[xiphos-devel] Beginner issues (was: 4.2.0 tagged and pushed)
On Tue, May 5, 2020 at 5:31 PM Samuel Banya wrote: > If there are any low level tickets that could be easily read and possibly > looked at, let me know. Sam, I'm just a bystander and occasional contributor myself so this isn't any kind of official word. but please allow me to offer a little advice. First it's admirable that you want to contribute. Projects this thrive much better when there are lots of contributors. By the same token one of the main ways they falter is a lack of participation and everything falling on one guy to move forward. That being said like most open source projects my guess is here that the primary developers don't always have the time to hand-hold contributors. If you want to make a difference you have to take some initiative yourself. It's a lot easier to get help when you've offered something up front than before. Even then it's not always easy, I've had contributions to this (and many other) projects sit for years before they were reviewed and accepted! The other thing to note is that the only person really in a good position to know what issues would be good for you to work on is _you_. You know your skill set and experience. Even if I were to search the issue set looking for possibilities I wouldn't really know what is up your ally or not. The best thing to do is look through the issues yourself and see if something grabs you. Even if not I'm sure there are lots of little things you could find to fix or improve based on your own usage. Start easy and work your way up, make sure you can build and run it from source before you start hacking and submit granular focused PRs with a clear objective. Maybe open issues for things you see than need improvement to get feedback on how they should be fixed before moving too far. Keep in mind that other devs right now are in the middle of a big push for a major release and overhauling some complicated old components that are really messy work. The build issue and Webkit/GTKHTML issues are probably not good places to start getting involved. It would probably be appreciated if you stop hijacking threads that aren't related. I'm sure people even without time are putting in extra effort to get the release stuff ironed out. Having unrelated topics keep showing up in threads probably isn't as constructive as you'd hope. Regards, Caleb ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] 4.2.0 tagged and pushed
My first foray into the leper colony has been thwarted by a bunch of old cruft. There already is a Xiphos team and a Xiphos project. Unfortunately the latter has all the wrong contents (an import of 3.x era code from subversion to bazar instead of just the debian packaging). Instead of setting it up and turning over the keys, I think I'll need somebody from the existing team to authorize me. If we try to do it the other way around we're going to create no end of confusion over on Launchpad. I've filed a request to join this: https://launchpad.net/~xiphos-devel Is Dimitri John Ledkov somebody currently on this list? On Mon, May 4, 2020 at 4:52 PM Caleb Maclennan wrote: > > On Mon, May 4, 2020 at 4:08 PM Karl Kleinpaste wrote: > > I'm mostly a Fedora guy and deal with Ubuntu only when necessary. If > > you're motivated, have at it. > > I'm mostly an Arch guy and avoid Ubuntu like the plague — but even > lepers need access to the Bible so I'll give it a go. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] 4.2.0 tagged and pushed
On Mon, May 4, 2020 at 4:08 PM Karl Kleinpaste wrote: > I'm mostly a Fedora guy and deal with Ubuntu only when necessary. If you're > motivated, have at it. I'm mostly an Arch guy and avoid Ubuntu like the plague — but even lepers need access to the Bible so I'll give it a go. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] 4.2.0 tagged and pushed
> What do you need for support of a PPA? Having fairly recently setup a PPA for SILE (https://launchpad.net/~sile-typesetter/+archive/ubuntu/sile) off the top of my head setting it up will go something like this: * A Launchpad account (better yet, a team with a couple of authorized people) * Add an a xiphos archive (this will be the PPA) * Add a xiphos project (this is for the debian packaging code) * Add a gtkhtml project (for debian packaging code) (or find one, this may exist already) * Somehow obtain Ubuntu systems you want to target, this can be bare metal, virtual machine, or container — I used LXC but Docker or Podman should be fine) * Setup SSH & GPG keys in on the build system (packages in PPAs must be signed) Then for each of the two projects that will be compiled and put into the PPA: * Extract a source release of the app * Extract the relevant project code into the source dir * Setup the debian folder with a control file, rules, and a changelog * Add, commit, and push the debian tooling to the Launchpad project * Run a build-source command that combines the upstream app source and debian packaging into a combined tarball plus a changes file and a signature * Use a command that uploads the above generated resources to the PPA Then to update in the future: * Roughly the same as the per-app steps above, but instead of having to setup the Debian tooling it will be mostly ready to go you just bump the changelog to trigger a new build. I'd be happy to help with this if you want me to get it rolling. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] 4.2.0 tagged and pushed
Sorry, didn't mean to yell ;-) I would probably still go ahead an upload the source build to the tag. All the other release artifacts are candy but that one deserves to be posted for posterity if nothing else. Distros that don't have build problems can go ahead and build it (note that they cannot from the automatic git archive of the tag any more, although a work around would be to clone the repo at the tag). On Sat, May 2, 2020 at 11:50 PM Karl Kleinpaste wrote: > > On 5/2/20 4:10 PM, Caleb Maclennan wrote: > > If you are deleting the tag, DO IT NOW. > > > At this point, we'll just let 4.2.0 go, and tag 4.2.1 for a real release once > Greg does his patch. > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] 4.2.0 tagged and pushed
>> OK, to follow up to myself, I got the auto-build results email, which >> reports 6 successful builds and 1 failed deployment. From that email, I >> used the link to see the results, and have a packages.zip (174M) containing >> 2 Windows *.exe, 1 Fedora 31 rpm, a generic tarball (funny name, has double >> '.'), and a deb, which I presume is generic to Debian and Ubuntu both >> (editor-less?). Those artifacts could be manually posted to the Github release since the upload failed. I suggest that over deleting the tag, then tagging a patch release when the auto system is expected to work to make sure it does. > No Arch build? The build system tests a source build on arch. Technically you _could_ build a package too, but the Arch ecosystem has a platform for doing that already, and I'm one of the maintainers of the Xiphos recipe. Because there are also other dependencies (gtkhtml4, gnome-doc-utils, biblesync) that need to be distributed too it is better to let the distro packaging channels take care of this. > * The deb file is specifically generated as part of the Ubuntu workflow, > but it's going to require a bit of manual install of deps, because that's not > packaged into the file. Also no - it's not editor-less, and it would require > packaging up the GtkHTML we're building from source inside of the > * RPM is specific to the version of Fedora it was built on, as well. > * Conclusion: we can probably drop both of these as release artifacts. Yes to all this. All these distros have proper packaging channels, and upstreams that provide half baked packages that mostly integrate with the system but aren't quite a match for dependency versions etc. are the pits. Better to have people do source builds in most cases — or just fix the official distro packaging channels. Ubuntu, Debian, and Fedora all have those things. > Let distros do their own packaging that way it's properly integrated. If we > want to offer our own package repositories, we should do so by offering > proper repos that can be added to apt/yum/zypper/pacman etc rather than > one-off download files. Correct. For Ubuntu we could offer a PPA with all the dependencies matching a distro release. Same for most distros. > * I'm not sure Arch builds are a thing? I'm really hazy on how Arch works. It > seems like the modern day Gentoo, but with a better wiki. For Arch Linux I already do host a repository with prebuilt packages based on the AUR formula. People can build themselves from the formula or grab the package with pacman at any time. I'd be happy to push those builds to a Xiphos official location, but actually I'm working towards getting it included in the official distro repository by default so that may not be necessary. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] 4.2.0 tagged and pushed
If you are deleting the tag, DO IT NOW. 5 hours ago. This is not something that is easy to recover from and anybody that has pulled the repo will manually need to delete their own tags, git does not do it automatically. Integrity thing. Personally I would say ignore it, maybe manually throw up any artifacts you want on the release built locally, and tag 4.2.1 when you thing the build system works. On Sat, May 2, 2020 at 9:21 PM Greg Hellings wrote: > > I'm good with it. Typically things pushed publicly you're discouraged from > modifying, but I see no issues in this case. > > --Greg > > On Sat, May 2, 2020 at 1:18 PM Karl Kleinpaste wrote: >> >> On 5/2/20 2:16 PM, Greg Hellings wrote: >> >> Including that in my patch. >> >> I see that git supports deleting a tag. (Never noticed that before.) Are >> we good with doing git tag -d 4.2.0, merging a patch, and re-tagging? > > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] getting a new release out
On Sun, Apr 26, 2020 at 10:39 AM Greg Hellings wrote: > We aren't quite there, yet. Sure we are. But I think we might be talking about different things. My comments were all about local tagging and builds. That part should be 100% working now, or my job on that PR isn't done. You should be able to tag locally, then build and get the right release version. This can be tested just by `git tag`, then build and run it and see what version it says it is. `make -C build source_package` should also have the right filename. (Be sure to delete any such test tags before pushing!) What you are talking about is automating the builds on Github when a tag is pushed to the remote repository so there is no local build step needed. Great work on that and sorry I havn't been more help by the way. That's the part you mean is not quite there yet, correct? > I have CI passing all builds and creating the Windows artifacts, but I don't > yet have it creating the final build artifacts for publishing *quite* yet. I haven't looked at your code yet, but I assume you are building and posting artifacts on all [push, pull_request] jobs, but filtering `on: push: tags: [ "v*" ]` and running an extra job on them to post the correct artifacts to a Github release matching the tag ... correct? Or at least that's the goal, no? > I would agree with this sentiment. Fedora is a bit loosey-goosey with what it > allows in, but you're not going to slip this past other distros as a patch > release. It really isn't, especially once we tossed in the change from libgsf > to minizip. Let's just cut loose the next version as 4.2.0 and maybe take the > extra few weeks to figure out editor/HTML needs. At least a roadmap even if > we don't finish them in time to make 4.2.0, we can have 4.3.0 well on its way. I definitely don't want to hold up the release any longer than it needs to be and I'm not advocating for stuffing new features in to make it worthy of a minor version number bump, all I'm saying is that it already needs at least a minor version bump with what's in the release so far. The editor can go in 4.3. I wouldn't put anything else on the roadmap for 4.2 other than getting the build and release process ironed out. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] getting a new release out
On Sat, Apr 25, 2020 at 11:50 PM Karl Kleinpaste wrote: > - I need to understand how the version stamp thing happens, now that Caleb's > source_version.txt is in play. We simply tag just prior to doing github > release? Yes, just simply tag, then build. There should be virtually nothing to do. In fact it's kind of important you don't do anything else. If you tag a commit as, say, "v4.2.0", then realize you forgot something and commit a small change, then build, what you build won't be v4.2.0 at all it will be v4.2.0.1. In other words to get the actual release version as tagged you _must_ build from the actual tagged commit. You can't fudge and actually build something else and just call it something its not. By the way I would be inclined to make the next release v4.2.0 not v4.1.1. If you actually follow SemVer there are a lot more changes than should fit in only a patch version bump. As a distro packager I expect patch versions to build and install virtually identically to previous versions. This release will require an entirely new set of build commands, and even the dependencies have changed. Even if there is not a much in the way of user facing changes the under-the-hood stuff is radically different and shouldn't be hidden behind a patch release number bump — at least not in my opinion as a downstream packager. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] back from the dead
Greg, On Arch Linux we are still building 4.1.0 using the waf build system, but on our VCS package that builds from git head the cmake build system is working perfectly as is. From the git clone directory, our cmake incantation looks like this: cmake -S . -B build \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/usr \ -DGTKHTML=ON make -C build make -C build DESTDIR="$pkgdir" install Given the right system deps, this works great and is pretty generic cmake usage. Note the package build environment already hase CFlags/CXXFlags/etc. set properly so they are not part of the build recipie. The full package script is here if you are interested in the dependencies: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=xiphos-git Caleb On Thu, Apr 16, 2020 at 6:42 AM Greg Hellings wrote: > Here's the magic source of Fedora building: > https://src.fedoraproject.org/rpms/xiphos/tree/master > > Specifically we have 4.1.0 tarball > Plus the cmake.patch which is a massive commit corresponding to "git diff > 4.1.0..fccfbdc" and pulls in the CMake build and gets rid of the waf > Plus my NASB patch > > CMake incantation is: > mkdir build && cd build > export CFLAGS=-fPIC > export CXXFLAGS=-fPIC > cmake -DGTKHTML:BOOL=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo .. > make && sudo make install > > --Greg > > On Wed, Apr 15, 2020 at 10:35 PM Karl Kleinpaste > wrote: > >> On 4/15/20 11:18 PM, Greg Hellings wrote: >> >> it's gonna require some amount of ugly hackery to get that editor >> working, now. >> >> So my first attempts at cmake-driven build have failed because the attempt >> to build the editor chokes. >> What's the magic you're using for Fedora et al builds, to avoid including >> the editor at all for the time being? >> ___ >> xiphos-devel mailing list >> xiphos-devel@crosswire.org >> http://www.crosswire.org/mailman/listinfo/xiphos-devel >> > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
