heptapod issueshttps://foss.heptapod.net/groups/heptapod/-/issues2020-09-22T09:18:50Zhttps://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/68Hosting request for Magic Lantern (firmware add-on for Canon DSLRs)2020-09-22T09:18:50ZAlexHosting request for Magic Lantern (firmware add-on for Canon DSLRs)## Description of the projects to be hosted
- Project Name: Magic Lantern
- Project URL: https://bitbucket.org/hudson/magic-lantern, https://www.magiclantern.fm
- Project Maintainers: a1ex (a1ex@magiclantern.fm), g3gg0 (ml@g3gg0.de)
- P...## Description of the projects to be hosted
- Project Name: Magic Lantern
- Project URL: https://bitbucket.org/hudson/magic-lantern, https://www.magiclantern.fm
- Project Maintainers: a1ex (a1ex@magiclantern.fm), g3gg0 (ml@g3gg0.de)
- Project License: GPLv2
Hi, we are looking for a new home for the source code repository of Magic Lantern, which is currently hosted on Bitbucket (Mercurial). Magic Lantern is relatively well-known among Canon DSLR users; it was started back in 2009 by Trammell Hudson (https://trmm.net/Magic_Lantern_firmware) and adds several features, developed from scratch, to camera firmware. It runs on top of camera's operating system (DryOS), fully usable on most DIGIC 4 and 5 EOS cameras at the time of writing, and there are porting efforts for both newer (DIGIC 6/7/8) and older (DIGIC 2/3) models.
The "obvious" choice for moving the repository would have been Github/Gitlab, but we prefer to keep the Mercurial workflow. We have already tried to convert our repository to Git using various tools (hg-git, hg-fast-export, git-hg, git-hg-again), unfortunately with only partial success. Main issue: the conversion does not keep Mercurial changeset IDs (referenced in many places in our documentation and technical discussions). There are also a few corner cases with unusual branch names that were generated by Bitbucket when users contributed small changes via their web interface.
We are here at the suggestion of @antocuni from the PyPy project (already hosted here). After researching things a bit and noticing your (well, Octobus') activities in archiving existing Bitbucket content, alongside with Software Heritage, Heptapod came on top of my choices for a new Mercurial host. I also appreciate the ability to import Bitbucket data, including issues and open pull requests, and the option to login with Bitbucket and Github credentials - hopefully this should make the transition a lot easier for existing contributors.
I understand there will be a change in workflow, as personal forks are not supported, but I'm sure we'll figure it out. I still have to research things a bit before importing the currently-pending changes from other contributors (which are stored in their personal forks for now).
As for the group name, I'm not sure what to suggest, as there are not many camera firmware projects around, and most of them are not hosted on Bitbucket anyway. However, we do have a few related projects, such as MlRawViewer, MLVFS, MLV App, Switch, ml-focus-pixels, ufraw-mod and others, which are standalone repositories (some of them use Git, others Mercurial). So, a group name like "magic-lantern" might be appropriate, if you ask me.
Thanks for considering!
P.S. Right before noticing your Bitbucket archiving project, I have started my own small-scale backup of currently-available Mercurial repositories on Bitbucket (plain "hg clone" followed by tar archive). If you think it could be useful (e.g. for cross-checking the list of repositories or available changesets), kindly let me know where's the best place to discuss this further.
### Main criteria
- [X] Free / Open Source
- [X] main development repositories
- [X] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on foss.heptapod.net
### Priority Criteria
- [X] currently hosted on Bitbucket
- [X] officially released
## Post approval maintainer task list
See [README](README.md#maintainer-task-list-for-the-import-to-happen)
for explanations.
- [X] Heptapod / Bitbucket accounts link
- [ ] Reviewing [Heptapod workflow](https://heptapod.net/pages/faq.html#workflow)
## Post import maintainer task list
- [X] Clone the project afresh from foss.heptapod.net.
- [X] Check that the repository looks good: branches are as expected in the
clone and the web interface, with no `wild` branches unless
there are known multiple heads.
- [X] Check that issues are imported, and notably that all open issues are
there. Watch for attachments etc. [ some issues missing; reported below ]
- [X] Check that Pull Requests are imported, and in particular take a close
look at the resulting open Merge Requests - they should be backed by a
topic. Make sure you can navigate these in the fresh clone. [ error merging MR #963 ]
- [ ] Check that against foss.heptapod.net, `hg outgoing` and `hg incoming`
from a prior clone are as expected
- [ ] Add the Octobus and Clever cloud acknowledgement at the selected place.
- [X] Communicate about the migration to help others to aware of the options [ [on our forum](https://www.magiclantern.fm/forum/index.php?topic=24420.msg228034#msg228034); initial suggestion [here](https://www.magiclantern.fm/forum/index.php?topic=24420.msg227797#msg227797) ]https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/72Set hook `pretxnclose.heptapod_check_publish=` on two isa-afp repos2021-02-04T21:03:19ZGerwin KleinSet hook `pretxnclose.heptapod_check_publish=` on two isa-afp reposNot sure if this is the right place to ask, but I'd like to set
```
[hooks]
pretxnclose.heptapod_check_publish=
```
for the the two repositories [isa-afp/af-devel](http://foss.heptapod.net/isa-afp/afp-devel) and [isa-afp/afp-testboard]...Not sure if this is the right place to ask, but I'd like to set
```
[hooks]
pretxnclose.heptapod_check_publish=
```
for the the two repositories [isa-afp/af-devel](http://foss.heptapod.net/isa-afp/afp-devel) and [isa-afp/afp-testboard](http://foss.heptapod.net/isa-afp/afp-testboard).
According to the FAQ, this should allow people in the `Developer` role to push directly to the default branch, which is something we'd like (`Maintainer` rights are too much, and not all logicians and mathematicians are that firm in version control and installing an extension for topics).
If I've understood correctly, this needs to happen on the server side to which we don't have access on the foss instance. Is that something you could do for us or should I be using some API/setting that I haven't found yet?Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/74Commit messages autoclose not working2020-07-10T13:06:37ZCharlieCCommit messages autoclose not workingThis may just be me getting used to the setup but I'm used to closing/resolving issues via the commit message but this isn't happening so far. I looked at the regex and it looks correct and it looks active. I wonder if it's related to mu...This may just be me getting used to the setup but I'm used to closing/resolving issues via the commit message but this isn't happening so far. I looked at the regex and it looks correct and it looks active. I wonder if it's related to multiline commit messages, as I normally put the command in a separate line.https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/75Hosting pages2023-02-22T19:45:38ZMatti PicusHosting pagesIs there any chance we could get something like github pages? I see [gitlab supports the feature](https://docs.gitlab.com/ee/user/project/pages/). I would like to do something like [this blog](https://www.varrazzo.com/blog/) for PyPy, wh...Is there any chance we could get something like github pages? I see [gitlab supports the feature](https://docs.gitlab.com/ee/user/project/pages/). I would like to do something like [this blog](https://www.varrazzo.com/blog/) for PyPy, which is hosted via [this repo](https://github.com/dvarrazzo/www.varrazzo.com) and uses issues and [utterance bot](https://github.com/dvarrazzo/www.varrazzo.com/issues/9) for discussions. That would drive people to sign up for heptapod to comment.https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/77Hosting request for grin32020-08-04T09:15:17ZRaffaele SalmasoHosting request for grin3## Description of the projects to be hosted
- Project Name: grin3
- Project URL: https://github.com/rsalmaso/grin3.git (was: https://bitbucket.org/rsalmaso/grin3)
- Project Maintainers: Raffaele Salmaso
- Project License: BSD
Please ex...## Description of the projects to be hosted
- Project Name: grin3
- Project URL: https://github.com/rsalmaso/grin3.git (was: https://bitbucket.org/rsalmaso/grin3)
- Project Maintainers: Raffaele Salmaso
- Project License: BSD
Please explain here why they meet our current criteria.
All details are in the [invitation announcement](https://heptapod.net/a-public-heptapod-for-free-and-open-source-software.html#a-public-heptapod-for-free-and-open-source-software)
To recapitulate, these are:
### Main criteria
- [X] Free / Open Source
- [X] main development repositories
- [X] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on foss.heptapod.net
### Priority Criteria
- [ ] currently hosted on Bitbucket
- [X] was hosted on Bitbucket
- [X] officially released
## Post approval maintainer task list
See [README](README.md#maintainer-task-list-for-the-import-to-happen)
for explanations.
- [ ] Hosting Request assignee has repository membership on Bitbucket
- [ ] Heptapod / Bitbucket accounts link
- [ ] Reviewing [Heptapod workflow](https://heptapod.net/pages/faq.html#workflow)
## Post import maintainer task list
- [ ] Clone the project afresh from foss.heptapod.net.
- [ ] Check that the repository looks good: branches are as expected in the
clone and the web interface, with no `wild` branches unless
there are known multiple heads.
- [ ] Check that issues are imported, and notably that all open issues are
there. Watch for attachments etc.
- [ ] Check that Pull Requests are imported, and in particular take a close
look at the resulting open Merge Requests - they should be backed by a
topic. Make sure you can navigate these in the fresh clone.
- [ ] Check that against foss.heptapod.net, `hg outgoing` and `hg incoming`
from a prior clone are as expected
- [ ] Add the Octobus and Clever cloud acknowledgement at the selected place.
- [ ] Communicate about the migration to help others to aware of the options
(for example on mastodon, twitter, bitbucket thread, mailing list, …)https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/80Discoverability and search2021-07-11T12:46:13ZMatti PicusDiscoverability and searchEven when I specify heptapod, google/duckduckgo do not show me heptapod/pypy/pypy when I search for "pypy +heptapod". I would expect it to be the top result by now. Is there some robot.txt blocking the site? Try it with a clean browser.Even when I specify heptapod, google/duckduckgo do not show me heptapod/pypy/pypy when I search for "pypy +heptapod". I would expect it to be the top result by now. Is there some robot.txt blocking the site? Try it with a clean browser.https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/84connect travis-ci.com to foss.heptapod.net2020-11-01T16:36:19ZMatti Picusconnect travis-ci.com to foss.heptapod.netIt seems one can [sign in to travis-ci.com](https://travis-ci.com/signup) with github, bitbucket, gitlab or assembla credentials. It would be nice if I could use foss.heptapod.net as well. This would open up nice CI integrations.It seems one can [sign in to travis-ci.com](https://travis-ci.com/signup) with github, bitbucket, gitlab or assembla credentials. It would be nice if I could use foss.heptapod.net as well. This would open up nice CI integrations.https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/85500 Error while editing wiki page2020-10-08T14:34:52ZEli Collins500 Error while editing wiki pageFor the past few days, I've been getting a 500 error when trying to save changes to https://foss.heptapod.net/python-libs/passlib/-/wikis/home using the web interface. It's been a few months since I last made an edit to a wiki page, so ...For the past few days, I've been getting a 500 error when trying to save changes to https://foss.heptapod.net/python-libs/passlib/-/wikis/home using the web interface. It's been a few months since I last made an edit to a wiki page, so not sure how long it's been going on.https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/86Get Git commit sha in the CI? CI_COMMIT_SHA2020-10-12T07:07:00ZPierre AugierGet Git commit sha in the CI? CI_COMMIT_SHAI guess that in Heptapod CI_COMMIT_SHA corresponds to the Mercurial commit sha.
It would be useful to have also the Git commit sha during the CI in another variable.
For example, I would use it to tell https://codecov.io about the Git ...I guess that in Heptapod CI_COMMIT_SHA corresponds to the Mercurial commit sha.
It would be useful to have also the Git commit sha during the CI in another variable.
For example, I would use it to tell https://codecov.io about the Git commit sha (because it does not support Heptapod and Mercurial to read the source).
It would be useful also in the future hg-native mode if we can still do Git push mirroring (which would be really useful! see https://foss.heptapod.net/heptapod/heptapod/-/issues/355).
Sorry if one can already get that. I looked in https://foss.heptapod.net/help/ci/variables/predefined_variables.md but I didn't find the information.https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/90Automatization of press department2021-08-30T12:45:11ZVladimir RomanovskyAutomatization of press department## Description of the projects to be hosted
- Project Name: automatization of press department at a manufacturing plant
- Project URL:
- Project Maintainers: Vladimir Romanovsky
- Project License: GPL
Please explain here why they meet ...## Description of the projects to be hosted
- Project Name: automatization of press department at a manufacturing plant
- Project URL:
- Project Maintainers: Vladimir Romanovsky
- Project License: GPL
Please explain here why they meet our current criteria.
This is just for evaluation Mercurial SCM for two persons: me-at-work,me-at-home
All details are in the [invitation announcement](https://heptapod.net/a-public-heptapod-for-free-and-open-source-software.html#a-public-heptapod-for-free-and-open-source-software)
To recapitulate, these are:
### Main criteria
- [x] Free / Open Source
- [x] main development repositories
- [x] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on foss.heptapod.net
### Priority Criteria
- [ ] currently hosted on Bitbucket
- [ ] officially released
## Post approval maintainer task list
See [README](README.md#maintainer-task-list-for-the-import-to-happen)
for explanations.
- [ ] Hosting Request assignee has repository membership on Bitbucket
- [ ] Heptapod / Bitbucket accounts link
- [ ] Reviewing [Heptapod workflow](https://heptapod.net/pages/faq.html#workflow)
## Post import maintainer task list
- [ ] Clone the project afresh from foss.heptapod.net.
- [ ] Check that the repository looks good: branches are as expected in the
clone and the web interface, with no `wild` branches unless
there are known multiple heads.
- [ ] Check that issues are imported, and notably that all open issues are
there. Watch for attachments etc.
- [ ] Check that Pull Requests are imported, and in particular take a close
look at the resulting open Merge Requests - they should be backed by a
topic. Make sure you can navigate these in the fresh clone.
- [ ] Check that against foss.heptapod.net, `hg outgoing` and `hg incoming`
from a prior clone are as expected
- [ ] Add the Octobus and Clever cloud acknowledgement at the selected place.
- [ ] Communicate about the migration to help others to aware of the options
(for example on mastodon, twitter, bitbucket thread, mailing list, …)https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/91CI: registry.heptapod.net / S3 cache for OSUOSL runners2021-01-20T14:05:47ZGeorges RacinetCI: registry.heptapod.net / S3 cache for OSUOSL runnersOnce a runner already got an image, it keeps it locally, like any repetitive use of `docker pull` would do, but that's not enough.
Our OSUOSL x86_64 runners all share the same link. That makes 8 machines that will download the images fr...Once a runner already got an image, it keeps it locally, like any repetitive use of `docker pull` would do, but that's not enough.
Our OSUOSL x86_64 runners all share the same link. That makes 8 machines that will download the images from registry.heptapod.net, to which the bandwidth isn't great. In particular, the bandwidth to our registry is a few times less than to docker.io, which makes totally sense geographically.
This is especially problematic for the Heptapod image, because it is really heavy (1GB, compressed) and produced automatically by CI (potentially more frequently). In the same time frame, we went from 4 OSUOSL runners to 8.
Caching alternative registries is notoriously problematic if one wants to cache all interactions with the registry. But the bulk of the traffic being taken directly from the S3 backend means that we should be able to cache only that.
The plan would be:
- [x] declare at least two runners to be also caching servers for their peers. We obviously don't want a SPOF.
- [x] make a private Certificate Authority (CA)
- [x] make all runners accept the private CA
- [x] create certificate for the S3 service signed by the private CA
- [x] setup local DNS servers to redirect S3 traffic to two machines (simple round-robin DNS works well) and forward all other zones to the datacenter-wide resolvers. I'm usually happy using unbound for that kind of purpose.
- [x] configure the two caching servers as bi-layered HA NGINX reverse proxies.https://foss.heptapod.net/heptapod/hgext-loggingmod/-/issues/6Non official way to know repo path2023-07-25T12:51:23ZGeorges RacinetNon official way to know repo pathIn `hgext-loggingmod` and in future `hg-git` or specific heptapod extension (see hg-git!7), we're relying on non-standard way to access the repo root, remarked by @lothiraldan in https://dev.heptapod.net/heptapod/hg-git/merge_requests/17...In `hgext-loggingmod` and in future `hg-git` or specific heptapod extension (see hg-git!7), we're relying on non-standard way to access the repo root, remarked by @lothiraldan in https://dev.heptapod.net/heptapod/hg-git/merge_requests/17#note_1301
It'd be better to submit upstream a standard API for that and use it.https://foss.heptapod.net/heptapod/heptapod/-/issues/98Cleanup hotfix for #952023-07-25T12:51:58ZGeorges RacinetCleanup hotfix for #95The hotfix is provided in heptapod-docker by 0fd5c18585f0, we should either rewrap it in a more manageable way in a `heptapod` hg extension, or simply consider dropping it if the patch mentioned in #95 has made its way into 5.2 final and...The hotfix is provided in heptapod-docker by 0fd5c18585f0, we should either rewrap it in a more manageable way in a `heptapod` hg extension, or simply consider dropping it if the patch mentioned in #95 has made its way into 5.2 final and we're using that version.Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod/-/issues/100Branch view should be more mercurial-like and less git like2023-07-24T14:59:43ZMaciej FijalkowskiBranch view should be more mercurial-like and less git likeRight now the branch view in heptapod follows git standard of branches, more or less equivalent to `ancestors(branch)`. In my opinion, the branch view should just show commits from this branch - something equivalent to `hg log -b <branch>`Right now the branch view in heptapod follows git standard of branches, more or less equivalent to `ancestors(branch)`. In my opinion, the branch view should just show commits from this branch - something equivalent to `hg log -b <branch>`https://foss.heptapod.net/heptapod/heptapod/-/issues/117Push bug after pruned a git branch2019-11-12T11:00:00ZFabien AmargerPush bug after pruned a git branch### Summary
After creating a new git branch with mercurial topic, the associated changesets have been pruned. After a new push, the branch still exists and there is no possibility to push a new branch again (multiple heads error).
### ...### Summary
After creating a new git branch with mercurial topic, the associated changesets have been pruned. After a new push, the branch still exists and there is no possibility to push a new branch again (multiple heads error).
### Steps to reproduce
To reproduce this bug, you have to create a new git branch with the mercurial topic, push it to heptapod, then prune all the changesets associated with the branch topic. After that there is an error when trying to push a new branch again.
### Temporary solution
To solve this problem we had to `hg touch` the old changesets and prune them again. This solved the issue apparently since we could push a new branch again.
(maybe this is similar to #109)https://foss.heptapod.net/heptapod/heptapod/-/issues/124[doc] Shorter topics tutorial2023-07-24T15:06:23ZArthur Lutz[doc] Shorter topics tutorialMy every day use of topics seems much simpler than what I find in https://www.mercurial-scm.org/doc/evolution/tutorials/topic-tutorial.html which I send to new heptapod users.
It would be nice to have a simpler tutorial available which...My every day use of topics seems much simpler than what I find in https://www.mercurial-scm.org/doc/evolution/tutorials/topic-tutorial.html which I send to new heptapod users.
It would be nice to have a simpler tutorial available which talks about :
* start a topic
* assign a topic to existing changesetshttps://foss.heptapod.net/heptapod/heptapod/-/issues/132Merge via webui adds a merge commit - expected rebase and publish2024-03-21T13:42:49ZArthur LutzMerge via webui adds a merge commit - expected rebase and publishSince upgrade to 0.7.0rc (we need to check if this was not the case on 0.6.x).
From :
```mermaid
graph BT
A --> B
A[init]
B[topic1]
A --> C
C[topic2]
```
I click merge on topic2 then topic1 in the web UI, I get :
```mermaid
gra...Since upgrade to 0.7.0rc (we need to check if this was not the case on 0.6.x).
From :
```mermaid
graph BT
A --> B
A[init]
B[topic1]
A --> C
C[topic2]
```
I click merge on topic2 then topic1 in the web UI, I get :
```mermaid
graph BT
A --> B
A(init)
B(topic1)
A --> C
C(topic2)
C --> D
B --> D
D(Merge branch 'topic/default/topic2 into 'branch/default')
```
I would expect
```mermaid
graph BT
A --> C
A(init)
B(topic1)
C --> B
C(topic2)
```Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/136What to do of CI builds on obsolete changesets?2023-07-26T15:23:43ZGeorges RacinetWhat to do of CI builds on obsolete changesets?If a build is for a changeset that's already obsolete by the time the build starts (more likely to happen if CI is really busy), it will fail with something like
```
Checking out Hg node 31732d6a012e9d25fbc8e7faa6f8dad040ecd513 as topic...If a build is for a changeset that's already obsolete by the time the build starts (more likely to happen if CI is really busy), it will fail with something like
```
Checking out Hg node 31732d6a012e9d25fbc8e7faa6f8dad040ecd513 as topic/default/refactor-contentdiv... (skip)
abort: unknown revision '31732d6a012e9d25fbc8e7faa6f8dad040ecd513'!
```
The obsolete changeset is in that situation not available at all in the clone of the runner (not even with `--hidden`). What the runner could do, is query obsmarkers, since they are always fully exchange.
But then, what to do with the information: not fail? Return a special payload that'd be equivalent to a cancel?
Alternatively, the Rails app could check upon pushes if some changesets have been obsoleted and if there are pending builds for them, but that's not something we can do very easily at this time. It would be heavier on the Rails app, yet probably better for the whole resources consumption.https://foss.heptapod.net/heptapod/heptapod/-/issues/137Review "Suggest changes" - in GitLab 11.62024-03-21T13:27:25ZArthur LutzReview "Suggest changes" - in GitLab 11.6https://docs.gitlab.com/ce/user/discussions/#suggest-changes
```
As a reviewer, you’re able to suggest code changes with a simple Markdown syntax in Merge Request Diff threads.
Then, the Merge Request author (or other users with approp...https://docs.gitlab.com/ce/user/discussions/#suggest-changes
```
As a reviewer, you’re able to suggest code changes with a simple Markdown syntax in Merge Request Diff threads.
Then, the Merge Request author (or other users with appropriate permission) is able to apply these suggestions with
a click, which will generate a commit in the Merge Request authored by the user that applied them.
```
Just to track this feature for heptapod (I know there's quite a road to 11.6).Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/146Some permission user feedbacks get lost2023-07-24T15:34:34ZGeorges RacinetSome permission user feedbacks get lostIn standard GitLab, push denies come with an explicit reason, which range from
not very interesting "You are not allowed to upload code for this project" to actually useful "The repository is temporarily read-only".
The way permission c...In standard GitLab, push denies come with an explicit reason, which range from
not very interesting "You are not allowed to upload code for this project" to actually useful "The repository is temporarily read-only".
The way permission checks work currently in Heptapod, except for the general access/visibility check, GitLab has no idea what the user is trying to do, and can only pass over a permission level to be used by Mercurial.
Hence these user feedbacks are lost. This isn't a big concern for the time being, and there's not so much we can do about it short time, but it's perhaps something we can improve within the hgitaly project.