"Geoff Beier" <geoff@tuxpup.com> writes:

> "unit" is much clearer than "pole" to me.

Fixed, thanks.

> Hearing that it is a handful
> of civil servants, I might also consider "free software contributors" as
> in "Why free software contributors at Etalab use SourceHut."

Writing and publishing code is only a small part of our job: we also
maintain a list of free software other agencies should use, writing
guides on how to publish source code, etc.  So "contributors" does
not really reflect what we are/do exactly.

Hi Geoff,

"Geoff Beier" <geoff@tuxpup.com> writes:

> I love your post and your organization's reasons for choosing
> SourceHut!

Thanks!

> I know I should go find a way to contribute to the wiki, but I only have
> a minute to spare. At least in US English, "Free Software pole" is a
> very funny translation of "le pôle logiciels libres." "Free Software
> Center" would be a much clearer choice and would, in my opinion, almost
> certainly better reflect the intent of the original version.

Hi all,

as kindly mentioned by Drew on his blog post, Etalab's Free
Software pole uses SourceHut for its repositories, e.g. for
the code behind https://code.gouv.fr.

We wrote some explanations of this choice here:

https://man.sr.ht/~etalab/logiciels-libres/why-sourcehut.md

I posted this page on HN for further discussion:

https://news.ycombinator.com/item?id=29342920

Thank you very much for the directions!  Really appreciated.

I will see how I can move forward on this.

-- 
 Bastien

"Drew DeVault" <sir@cmpwn.com> writes:

> Can you enumerate exactly what data you hope to collect, so that we
> needn't find out by reverse engineering the GitHub integration?

Yes, here it is:

For accounts (aka "organizations"):

  - URL (as primary key)
  - avatar_url (no-op?)
  - creation_date
  - description (srht "bio"?)
  - email

Hi all,

as you've read in Drew's anniversary blog, one of the service of the
French administration (Etalab/DINUM) is hosting some of its projects
on SourceHut: https://sr.ht/~etalab/

Our main project is the one related to https://code.gouv.fr where we
expose published repositories from the French public sector.

The very first step when building this website is to collect data from
several forges: github.com, gitlab.com and GitLab instances.

See this file for the list of forges we collect data from:
https://git.sr.ht/~etalab/codegouvfr-fetch-data/blob/master/platforms.csv

Philip Kaludercic <philipk@posteo.net> writes:

> What I can add is that this doesn't seem to be an issue on Emacs 27,
> just on Emacs 28. I just pulled and rebuilt the emacs-28 branch, and the
> issue persists. On my system I apparently can replicate the issue
> reliably using emacs -Q. Deleting
> .config/emacs/elpa/archives/gnu/archive-contents doesn't seem to change
> anything.

Right, thanks for the additional info.  Can you report this to the
Emacs developers?  M-x report-emacs-bug RET

Thanks!

Hi Philip,

I've checked with the GNU ELPA maintainers and things look fine on
their end, I don't know what goes wrong on yours.

I hope this will somehow resolve.

Thanks,

-- 
 Bastien

Philip Kaludercic <philipk@posteo.net> writes:

> Sorry for the last response (I was waiting for NonGNU to rebuild), but
> no org-contrib is still marked as incompatible, for the same reason.

That's weird, especially because the org dependency was updated in the
latest org-contrib version, that is 0.3.

Can you report again what error message you get this time?

Thanks for this,

-- 
 Bastien

Bastien <bzg@gnu.org> writes:

> I'd rather not update the dependency to 9.5 right now, it would force
> org-contrib users to migrate while they might not be ready for that.

Actually I just released org-contrib 0.3 and updated org dependency to
the latest bugfix release there (9.4.6).

Let me know if this fixes the problem you reported.

-- 
 Bastien Guerry