[xiphos-devel] 4.2.0 tagged and pushed

[Caleb Maclennan]

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 <caleb at alerque.com> 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 <caleb at alerque.com> 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 /<project> and users/teams are
>> /~<user>). 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/xiphos-devel/attachments/20200508/5e84c711/attachment.html>