ergo: update to 2.11.1, rename from oragono.

[chilledfrogs]

Note: I couldn't find out what was the procedure for updating packages where they get renamed, I did what I thought wasn't stupid, please feel free to tell me if I screwed anything up with it 😅

Testing the changes

• I tested the changes in this PR: briefly

Local build testing

• I built this PR locally for my native architecture, (x86_64-glibc)
• I built this PR locally for these architectures (if supported. mark crossbuilds):
  • aarch64

[TinfoilSubmarine]

Sorry, commented before I was done thinking :)

You already have the symlink, but I think the provides=... and replaces=... should be similar to what mysql/mariadb has since this is just a rename, as well as an oragano_package() similar to mysql_package().

[TinfoilSubmarine]

Actually, you should follow what was done for pulseeffects being renamed to easyeffects, since that was more recent and was just a rename unlike the mysql/mariadb drop-in case.

[ericonr]

@pbui ok for you?

[pbui]

@pbui ok for you?

Yes, these changes look reasonable.

As a side note, you can probably remove me from the maintainer field... as I don't use Void Linux anymore and probably will not be contributing updates for the foreseeable future.

[sgn]

Please move data files in /var to new location if we choose to rename its folder.

[chilledfrogs]

@sgn I'm sorry but I'm not sure what you want me to do concretely with which exact folder

[sgn]

@sgn I'm sorry but I'm not sure what you want me to do concretely with which exact folder

I meant move files from /var/lib/oragono to /var/lib/ergo

[chilledfrogs]

@sgn I actually wanted to do that conditionally but couldn't figure out whether there was an appropriate way to do it or not, so any ideas would be greatly appreciated

[paper42]

@sgn I actually wanted to do that conditionally but couldn't figure out whether there was an appropriate way to do it or not, so any ideas would be greatly appreciated

What would be the condition? Do you mean that you would want existing installations to keep using the old location, but new ones to use the ergo location? We don't have a good way to do this.

[sgn]

In my opinion, at least keychain should be kept.

[chilledfrogs]

@paper42 I more meant as a specific way of doing a one-time rename of the directory when updating it

[chilledfrogs]

Would something like the oragono.INSTALL I added be appropriate?

[Piraty]

applied onto 3a4b215, it currently FBTFS FTBFS .

_cgo_callers: relocation target x_cgo_callers not defined
_cgo_init: relocation target x_cgo_init not defined
_cgo_mmap: relocation target x_cgo_mmap not defined
_cgo_munmap: relocation target x_cgo_munmap not defined
/usr/lib/go/pkg/tool/linux_amd64/link: too many errors
=> ERROR: ergo-2.10.0_1: do_build: 'go install -p "$XBPS_MAKEJOBS" -mod="${go_mod_mode}" -x -tags "${go_build_tags}" -ldflags "${go_ldflags}" ${go_package}' exited with 2
=> ERROR:   in do_build() at common/build-style/go.sh:43

pkg:ergo host:x86_64-musl target:armv7l-musl cross:y result:FAILED

[chilledfrogs]

_cgo_callers: relocation target x_cgo_callers not defined
_cgo_init: relocation target x_cgo_init not defined
_cgo_mmap: relocation target x_cgo_mmap not defined
_cgo_munmap: relocation target x_cgo_munmap not defined
/usr/lib/go/pkg/tool/linux_amd64/link: too many errors
=> ERROR: ergo-2.10.0_1: do_build: 'go install -p "$XBPS_MAKEJOBS" -mod="${go_mod_mode}" -x -tags "${go_build_tags}" -ldflags "${go_ldflags}" ${go_package}' exited with 2
=> ERROR:   in do_build() at common/build-style/go.sh:43

Issue is I can't reproduce it for the moment and seems apparently neither can the CI, but is it related to this? golang/go#43505

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

[chilledfrogs]

...?

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

[chilledfrogs]

@classabbyamp could this be re-opened? To the best of my knowledge this PR still works just fine and is simply waiting to be merged for a very long time

[classabbyamp]

apparently not... make a new pr please an link this one. I've been meaning to look at this but it's fairly complex so hard to find the time