Re: error while pulling changes from remote mercurial repo
Branko Majic wrote: > On Wed, 21 Feb 2024 17:41:40 +0800 > Ed Wong wrote: > >> I've moved a mercurial repository from an old Kallithea installation >> to a new machine (Kallithea 0.7.0) and things have been going on ok. >> (Using Python3.9 and mercurial 6.1.4) > > So... I don't know what the exact issue is you are facing here, but > based on some personal experiences The released version of > Kallithea (0.7.0) is quite outdated from the code perspective when > compared to what is currently in the repository tip (if I got > terminology right, I'm really mainly a Git user :) ). Hi Branko, I think that might be a good idea. Though did you end up fixing your issues when you use the dev- tree? (And yes, I'm also mainly a git user as well... though recently need to use hg.) Take care, Edmund ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
error while pulling changes from remote mercurial repo
Hi, I've moved a mercurial repository from an old Kallithea installation to a new machine (Kallithea 0.7.0) and things have been going on ok. (Using Python3.9 and mercurial 6.1.4) Realized I hadn't updated two of the mercurial repositories, so I went and did a "Pull changes from Remote Repository", but I get an error message "An error occurred during pull from remote location". Fwiw, the two repositories are: - https://hg.mozilla.org/comm-central - https://hg.mozilla.org/mozilla-central I took a look at the httpd log, and I came across the following: File "/repos/kallithea/kallithea/model/scm.py", line 359, in pull_changes repo.pull(clone_uri) File "/repos/kallithea/kallithea/lib/vcs/backends/hg/repository.py", line 634, in pull mercurial.exchange.pull(self._repo, other, heads=None, force=None) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/exchange.py", line 1680, in pull _pulldiscovery(pullop) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/exchange.py", line 1727, in _pulldiscovery step(pullop) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/exchange.py", line 1752, in _pulldiscoverychangegroup tmp = discovery.findcommonincoming( File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/discovery.py", line 62, in findcommonincoming res = setdiscovery.findcommonheads( File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/setdiscovery.py", line 404, in findcommonheads ui.status(_(b"searching for changes\\n")) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/ui.py", line 1849, in status self._writemsg(self._fmsgout, type=b'status', *msg, **opts) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/ui.py", line 1331, in _writemsg _writemsgwith(self._write, dest, *args, **opts) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/ui.py", line 2285, in _writemsgwith write(dest, *args, **opts) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/ui.py", line 1274, in _write self._writenobuf(dest, *args, **opts) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/ui.py", line 1299, in _writenobuf dest.write(msg) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/utils/procutil.py", line 115, in write c = write1(m[total_written:]) peError: write() argument 1 must be read-only bytes-like object, not memoryview ERROR [kallithea.controllers.admin.repos] Traceback (most recent call last): File "/repos/kallithea/kallithea/controllers/admin/repos.py", line 464, in edit_remote ScmModel().pull_changes(repo_name, request.authuser.username, request.ip_addr) File "/repos/kallithea/kallithea/model/scm.py", line 359, in pull_changes repo.pull(clone_uri) File "/repos/kallithea/kallithea/lib/vcs/backends/hg/repository.py", line 634, in pull mercurial.exchange.pull(self._repo, other, heads=None, force=None) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/exchange.py", line 1680, in pull _pulldiscovery(pullop) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/exchange.py", line 1727, in _pulldiscovery step(pullop) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/exchange.py", line 1752, in _pulldiscoverychangegroup tmp = discovery.findcommonincoming( File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/discovery.py", line 62, in findcommonincoming res = setdiscovery.findcommonheads( File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/setdiscovery.py", line 404, in findcommonheads ui.status(_(b"searching for changes\\n")) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/ui.py", line 1849, in status self._writemsg(self._fmsgout, type=b'status', *msg, **opts) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/ui.py", line 1331, in _writemsg _writemsgwith(self._write, dest, *args, **opts) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/ui.py", line 2285, in _writemsgwith write(dest, *args, **opts) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/ui.py", line 1274, in _write self._writenobuf(dest, *args, **opts) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/ui.py", line 1299, in _writenobuf dest.write(msg) File "/var/www/kali/venv/lib64/python3.9/site-packages/mercurial/utils/procutil.py", line 115, in write c = write1(m[total_written:]) peError: write() argument 1 must be read-only bytes-like object, not memoryview Thinking that this might have been some compatibility issue between the old Kallithea managed repos and the 0.7.0, I thought I'd create a new repository. So I went and created another mercurial repo using the same remote repository (either one): but again, I get an error: ERROR [kallithea.controllers.admin.repos] Traceback (most recent call last): File "/repos/kallithea/kallithea/controllers/admin/repos.py", line 119, in create
creating repository from cloning remote
Hi, While cloning off a repo and then pushing to it, I got some 'could not write' errors. When I logged on to the Kallithea server, I noticed that the resulting repositories that I created (by cloning off a remote one) are all owned by root, when they should be owned by the Kallithea user. As Kallithea is run under mod_wsgi in Apache, I thought I had mis-set it; but this is what's set: WSGIDaemonProcess kallithea user=kali group=kali processes=5 threads=1 ... if it isn't the process that creates the repos, what does? Any clarifications appreciated. Ed ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: mercurial clone log
Minor addendnum. As I've been having difficulties with this problem, I figured it would be a workaround if I could log on to the kallithea instance and then clone it to that path. Having done that, and gotten a rescan, the resulting repository is recognized by Kallithea. That said, cloning from that resulting mercurial repo is still taking too long. In the Journal, I don't see a log stating that I'm pulling from that repo even though I do have a Jenkins execute shell job: hg clone http://server/code/mcrepo temp Still no log in the Journal. I tried: hg clone --stream http://server/code/mcrepo temp And nothing. Does Kallithea have internal logs that show actual incoming connections? I can clone other repositories fine. Any help appreciated Edmund ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: AW: custom mercurial
Benny Bürger wrote: > You have to configure the global hooks using > http://[hostname]:[port]/_admin/settings/hooks > You can define different events e.g.: > > incoming.jenkins /opt/kallithea-data/hooks/buildJob.sh > pretxnchangegroup.check /opt/kallithea-data/hooks/checkForMissingFiles.sh > $HG_NODE > > The first is what you want, the second is a preCheck if the push should be > accepted. > > I hope this helps, Hi Benny, Thanks for the clarification on that. What I was wondering is what information is passed into the buildJob.sh? The documentation is a little light on that and the info in kallithea.lib.hooks.py is puzzling. Anyway, I guess I can set up a testhook on a test repo and see what gets passed. Thanks! Edmund ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
custom mercurial
Hi, Pardon my ignorance, but can someone clarify how to install hooks (mercurial) on Kallithea? In the docs, it states to add the "." and the path; but what types are there? Furthermore, what should the path be? What should the contents be in the hook file? Are there repository-specific hooks? I'm particularly interested in getting a hook which runs when a push has been made to the repository. Is that the post-receive hook? Any help appreciated. Thanks Ed ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
mercurial clone log
Hi, I'm using the latest version (from source) and am trying to create a clone of a mercurial repo (clone of https://hg.mozilla.org/comm-central). When I go to the UI to create the repository, I enter temp_cc as name, https://hg.mozilla.org/comm-central as the url. I clicked on save. It then shows me a page with the message: "Repository "code/temp_cc" is being created, you will be redirected when this process is finished." But even after 1/2 hour, it doesn't redirect. When I log on to the system and take a gander at the path "/code", /code doesn't have the "temp_cc" folder. I took a look at the Journal; but nothing is shown (pertaining to this repo). Does Kallithea have some sort of log showing its attempts at cloning? If I log on to that system and do a "hg clone https://hg.mozilla.org/comm-central temp-cc", it takes around 10 minutes. Any clarification in how to debug this issue very much appreciated. Thanks Ed ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: wsgi setup getting Permission Denied
Two things that need to be mentioned. 1) This issue was fixed by disabling SELinux. I'll need to figure out if I don't need to disable SELinux. Currently looking at this. 2) Forgot to include locale=en_US.UTF-8 in WSGIProcessGroup. ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
wsgi setup getting Permission Denied
Hi,
Having given up with the httpd proxy to get Kallithea working with
Apache, I'm going with the Apache mod_wsgi path and am nearly
there.
My setup;
dispatch.wsgi:
ini = '/var/www/kali/my.ini'
from logging.config import fileConfig
fileConfig(ini, {'__file__': ini, 'here': '/var/www/kali'})
from paste.deploy import loadapp
application = loadapp('config:' + ini)
The repository is at /repos/repos [user: kali, group: kali]
The Source installation is at /repos/kallithea [user: kali, group: kali]
Virtual env: /var/www/kali/venv
Python 3.9
Apache 2.4.37
Apache configuration:
ServerName 127.0.0.1
CustomLog logs/kali/access.log common
ErrorLog logs/kali/error.log
WSGIDaemonProcess kallithea user=kali group=kali processes=5
threads=1 maximum-requests=100 python-home=/var/www/kali/venv
WSGIProcessGroup kalllithea
WSGIScriptAlias / /var/www/kali/dispatch.wsgi
process-group=kallithea application-group=%{GLOBAL}
WSGIPassAuthorization On
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
Require all granted
Order allow,deny
Allow from all
Require all granted
When I run the above setup, I get the following error in the traceback:
[Fri Jul 21 03:45:11.596117 2023] [wsgi:error] [pid 65057:tid
140148165671232] File "", line 925, in
_find_spec
[Fri Jul 21 03:45:11.596123 2023] [wsgi:error] [pid 65057:tid
140148165671232] File
"/var/www/kali/venv/lib64/python3.9/site-packages/__editable___Kallithea_0_7_0_finder.py",
line 19, in find_spec
[Fri Jul 21 03:45:11.596126 2023] [wsgi:error] [pid 65057:tid
140148165671232] return cls._find_spec(fullname, Path(pkg_path, *rest))
[Fri Jul 21 03:45:11.596132 2023] [wsgi:error] [pid 65057:tid
140148165671232] File
"/var/www/kali/venv/lib64/python3.9/site-packages/__editable___Kallithea_0_7_0_finder.py",
line 28, in _find_spec
[Fri Jul 21 03:45:11.596135 2023] [wsgi:error] [pid 65057:tid
140148165671232] if candidate.exists():
[Fri Jul 21 03:45:11.596141 2023] [wsgi:error] [pid 65057:tid
140148165671232] File "/usr/lib64/python3.9/pathlib.py", line 1424, in
exists
[Fri Jul 21 03:45:11.596144 2023] [wsgi:error] [pid 65057:tid
140148165671232] self.stat()
[Fri Jul 21 03:45:11.596149 2023] [wsgi:error] [pid 65057:tid
140148165671232] File "/usr/lib64/python3.9/pathlib.py", line 1232, in
stat
[Fri Jul 21 03:45:11.596152 2023] [wsgi:error] [pid 65057:tid
140148165671232] return self._accessor.stat(self)
[Fri Jul 21 03:45:11.596163 2023] [wsgi:error] [pid 65057:tid
140148165671232] PermissionError: [Errno 13] Permission denied:
'/repos/kallithea/kallithea/__init__.py'
I added the following to top of dispatch.wsgi:
import getpass
print(getpass.getuser())
And I get:
kali
So I know for sure that it's trying to access
/repos/kallithea/kallithea/__init__.py as kali; but I still get
permission denied.
Permission of /repos/kallithea/kallithea/__init__.py: rw-rw-rw-.
[kali.kali]
Permission of /repos/kallithea: drwxrwxr-x. [kali.kali]
Permission of /repos: drwxr-xr-x. [kali.kali]
Am I missing something?
Thanks
Ed
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: mercurial cloning from git bash
Mads Kiilerich wrote: > Hi > > It seems odd that the problem should be caused by the upgrade. It isn't much as 'caused' rather than a setup issue that I'm not familiar with; but then again, I've *never* had a great experience with using mercurial to clone something that huge. Anyway, the basic problem is the proxying. I'm hitting some timeout (I think) and getting the following error in the httpd log. [Fri Jul 21 01:08:38.204419 2023] [proxy_http:error] \ [pid 43810:tid ] (70008)Partial results are valid but \ processing is incomplete: [client :] AH01110: \ error reading response I haven't found anything that helps this issue despite lots o possible hits with this error message. I'm going to try to get wsgi running and seeing if this helps. At least it'll remove the proxy from the equation. Thanks Edmund ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: mercurial cloning from git bash
Actually I forgot to mention the following. I have httpd acting as proxy using the configuration as mentioned in the Setup wiki page. I setup gearbox to run as a daemon. (System is RockyLinux 8.0) Right now, I've setup celery and redis; but I'm not entirely sure how to test whether or not kallithea is using Celery. I set "use_celery" to true, I set the celery broker url to the redis://localhost:6379/0. I ran both "kallithea-cli celery-run -c new.ini" and "redis-server" and then I ran the clone command; but I don't see kallithea using celery (as there are no logged entries of anything being used). Any clarifications appreciated Thanks Ed ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
mercurial cloning from git bash
Hi, I finally was able to upgrade an old Kallithea setup to the latest version and migrated the old repositories to the new system. That said, I haven't setup Celery as that requires either RabbitMQ or redis. However, I'm having some difficulties in cloning off a mercurial repository (based on Mozilla's mozilla-central). I tried the following: 1) hg clone --debug ssh:/// newrepo At this point, it would spew out a long list of entries such as "add changeset "; but would hang at some changeset and would just display "ad" 2) hg clone --debug http:/// newrepo Does the same thing as #1, but at one point it dumps the following: . . add changeset 5f2a7ad96962 bundle2-input-part: total payload size 85113701 transaction abort! rollback completed (sent 3 HTTP requests and 1287 bytes; received 19595741 bytes in response) abort: HTTP request error (incomplete response) (this may be an intermittent network failure; if the error persists, consider contacting the network or server operator) The mercurial client that comes with git bash (2.40.1) is 5.0.2. Might anyone have any idea how to fix this issue? Thanks Ed ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: post-receive webhooks for git
Mads Kiilerich wrote: > On 12/2/20 4:49 AM, Ed Wong wrote: >> Hi, >> >> I'm using version 0.5.0 (due to system still using python.27). > > > I think all OSes make it easy to install Python 3 side by side with > Python 2 without any further impact. I suggest upgrading. We don't have > resources to support old versions. > Hi Mads, I understand about the supporting old versions. Turning into a yak shaving experience with installing a newer version of python etc.. Might just stand up a new CentOS system. > > The hooks support is a bit half baked. > > Are you using Mercurial? Then it is quite easy to add additinoal custom > hooks of any kind through the UI. Thinking about it, I guess we should > clarify in the UI that the hooks settings is for Mercurial only ... Nope. I'm using Git. > > The Git hook functionality only allows for one hook of each kind - and > has other hook entry points and a different hook API than Mercurial. It > is not feasible to make them equal. But see Tim Ooms' related proposal > in > https://lists.sfconservancy.org/pipermail/kallithea-general/2020q4/thread.html#3241 > . I've looked at the thread but need to get acquainted with the code. I'm guessing that each repository needs some ui to add hook code so that Kallithea, which would be more of a natural way [kinda like how github has git hooks] than creating a Kallithea extension. But as it stands, I have no idea how it would work. As far as I understand post-receive hooks and say, Jenkins, it basically requires some sort of authorization token and a specific url that triggers the CI. The more I think of it, the more complicated it feels. Again, will need to sit down and understand what the code does. Thanks Edmund > > Extensions ( > https://kallithea.readthedocs.io/en/default/usage/customization.html#behavioral-customization-kallithea-extensions > ) allow some more high level hooks, more consistent across Git and > Mercurial, but they are global and do not have any UI. > > /Mads > ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
post-receive webhooks for git
Hi, I'm using version 0.5.0 (due to system still using python.27). I've been looking at the documentation for hooks and have looked at the Admin->Settings->Hooks; but I can't make heads or tails in how to set up a hook which gets triggered when someone pushes to the repo. I see that in the main repo there is a hooks dir with the post-receive hook but with the "don't customize it manually" warning. Where do I make changes to the post-receive hook? Thanks Edmund ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: adding ssh public keys with lf in it
Mads Kiilerich wrote: > Ok. I coldn't verify ... but that depends on whether the truncation was > in a place that didn't make the base64 string invalid. > > I implemented more thorough validation of ssh keys and ended up with > https://kallithea-scm.org/repos/kallithea/pull-request/274/_/ssh_key_verification > - how does that work for you? > > /Mads > Will test it out, thanks Mads! Edmund ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: adding ssh public keys with lf in it
Mads Kiilerich wrote: > (Note: please post to kallithea-general@sfconservancy.org - not to the > -bounces address.) > My bad, sorry Mads. > > Thanks for the report and patch. > > Can you clarify exactly which problem you saw? Did you get a "nice" > "Incorrect SSH key - failed to decode base64 part" message when adding > the key? A correct and correctly shown message ... but not helpful? And > you missed the error message and thought the key had been added > successfully? The key was added successfully without any errors. When I reload the account's ssh keys, it shows the added key. > > It seems like the added test will pass, also without the fix. The > kallithea/model/db.py public_key setter will just decode using > base64.b64decode which happens to happily ignore any kind of whitespace. > I guess it would be better to test this change like we test ssh key > adding in kallithea/tests/functional/test_admin_users.py and > kallithea/tests/functional/test_my_account.py . Yeah, I'm still working on the patch but haven't gotten my dev env setup properly yet. Thanks to Patrick though, I'm closer. :) So the tests aren't failing as I am hoping as I've forgotten how the tests are setup. > > But back to the core of the problem: > > The format of these ssh public keys is that they are one line. First the > key type, then space, then the base64 encoded key, then optional space > followed by anything that is a comment and ignored. I thus have some > concerns of adding partial support for a non-standard format. Especially > as this is security sensitive and we thus try to be paranoid. When > parsing the base64 encoded part, we even have a "Incorrect SSH key - > unexpected characters in base64 part" check to explicitly avoid newlines. > > But we could perhaps do it anyway... Would > https://kallithea-scm.org/repos/kallithea-incoming/changeset/d8ec9261cead78bb6f4768ebf7f82bd21c0d74fd > work for you and fix your problem? Will test it out locally. Edmund ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
KALLITHEA_EXTRAS environment variable missing
Hi,
Just managed to work around the database unicode issue and
could both clone and push via the ssh:// url; however,
pushing to a git repository gave me the following 'error':
Total 3 (delta 1), reused 0 (delta 0)
remote: Traceback (most recent call last):
remote: File "hooks/post-receive", line 38, in
remote: main()
remote: File "hooks/post-receive", line 34, in main
remote:
sys.exit(kallithea.lib.hooks.handle_git_post_receive(repo_path,
git_stdin_lines))
remote: File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/kallithea/lib/hooks.py",
line 343, in handle_git_post_receive
remote: baseui, repo = _hook_environment(repo_path)
remote: File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/kallithea/lib/hooks.py",
line 310, in _hook_environment
remote: extras = get_hook_environment()
remote: File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/kallithea/lib/utils2.py",
line 538, in get_hook_environment
remote: raise Exception("Environment variable KALLITHEA_EXTRAS not
found")
remote: Exception: Environment variable KALLITHEA_EXTRAS not found
To seavcs:repos/infrastructure/testgit2
887eb3c..19b77cd master -> master
Apparently, it did save the push.
I've looked at the documentation; but haven't yet seen the mention
of the KALLITHEA_EXTRAS requirement. Looking at the code,
I'm not exactly sure what fields are required in the json
structure.
Any help appreciated.
Thanks
Edmund
PS: Merry Christmas and a Happy New Year!
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: upgrading 0.4.x to 0.5 database error.
Mads Kiilerich wrote:
> On 12/23/19 4:46 PM, Ed Wong wrote:
>> Hi,
>>
>> I'm running Kallithea 0.4.0 and tried to upgrade to 0.5.0; but at the
>> point of running "alembic -c my_new.ini upgrade", I got the following
>> error:
>>
>
>> 2019-12-23 15:42:42.575 INFO [alembic.runtime.migration] Running
>> upgrade 151b4a4e8c48 -> 4851d15bc437, db: migration step after
>> 95c01895c006 failed to add usk_public_key_idx in alembic step
>> b74907136bc1
>
>> sqlalchemy.exc.OperationalError: (_mysql_exceptions.OperationalError)
>> (1170, "BLOB/TEXT column 'public_key' used in key specification without
>> a key length") [SQL: u'CREATE INDEX usk_public_key_idx ON user_ssh_keys
>> (public_key)'] (Background on this error at: http://sqlalche.me/e/e3q8)
>
>
> Hmm.
>
>
> One solution could perhaps be to change db.py to something like
>
> _public_key = Column('public_key', Unicode(512), nullable=False)
>
> ... but I'm not sure if 512 (or anything else) is reasonable - that
> depends on how long public keys ever can be, and what the lowest key
> constraints among databases is these days.
>
>
> But it seems like we only use the public_key index for deleting ssh keys.
>
> Most likely, it will work just fine without that index. As a quick
> temporary workaround, I suggest skipping that upgrade step: edit
> kallithea/alembic/versions/4851d15bc437_db_migration_step_after_95c01895c006_.py
> and disable the checkings.
I commented out the three lines:
> def upgrade():
pass
# meta = sa.MetaData()
# meta.reflect(bind=op.get_bind())
# if not any(i.name == 'usk_public_key_idx' for i in
meta.tables['user_ssh_keys'].indexes):
# with op.batch_alter_table('user_ssh_keys', schema=None) as
batch_op:
# batch_op.create_index('usk_public_key_idx',
['public_key'], unique=False)
And now running "alembic -c my.ini upgrade head", I get:
(kalivenv) [root@vcsSeaBuildNet srv]# alembic -c my.ini upgrade head
2019-12-24 00:53:02.660 INFO [alembic.runtime.migration] Context impl
MySQLImpl.
2019-12-24 00:53:02.660 INFO [alembic.runtime.migration] Will assume
non-transactional DDL.
2019-12-24 00:53:02.669 INFO [alembic.runtime.migration] Running
upgrade a020f7044fd6 -> ad357ccd9521, Drop locking
2019-12-24 00:53:04.849 INFO [alembic.runtime.migration] Running
upgrade ad357ccd9521 -> b74907136bc1, Create table for ssh keys
2019-12-24 00:53:05.552 INFO [alembic.runtime.migration] Running
upgrade b74907136bc1 -> 151b4a4e8c48, db: migration step after
93834966ae01 dropped non-nullable inherit_default_permissions
2019-12-24 00:53:06.717 INFO [alembic.runtime.migration] Running
upgrade 151b4a4e8c48 -> 4851d15bc437, db: migration step after
95c01895c006 failed to add usk_public_key_idx in alembic step b74907136bc1
But it doesn't seem to affect much as I can still run Kallithea
and the ssh does seem to work and not to tempt fate with
deleting keys...
Thanks Mads!
Edmund
> It now seems like the right solution would be to change the code to use
> the fingerprint when deleting keys. I will work on that.
>
>
> /Mads
>
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
upgrading 0.4.x to 0.5 database error.
Hi,
I'm running Kallithea 0.4.0 and tried to upgrade to 0.5.0; but at the
point of running "alembic -c my_new.ini upgrade", I got the following
error:
2019-12-23 15:42:40.924 INFO [alembic.runtime.migration] Running
upgrade ad357ccd9521 -> b74907136bc1, Create table for ssh keys
2019-12-23 15:42:41.609 INFO [alembic.runtime.migration] Running
upgrade b74907136bc1 -> 151b4a4e8c48, db: migration step after
93834966ae01 dropped non-nullable inherit_default_permissions
2019-12-23 15:42:42.575 INFO [alembic.runtime.migration] Running
upgrade 151b4a4e8c48 -> 4851d15bc437, db: migration step after
95c01895c006 failed to add usk_public_key_idx in alembic step b74907136bc1
Traceback (most recent call last):
File "/var/www/environments/kalivenv/bin/alembic", line 11, in
load_entry_point('alembic', 'console_scripts', 'alembic')()
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/config.py",
line 527, in main
CommandLine(prog=prog).main(argv=argv)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/config.py",
line 521, in main
self.run_cmd(cfg, options)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/config.py",
line 501, in run_cmd
**dict((k, getattr(options, k, None)) for k in kwarg)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/command.py",
line 276, in upgrade
script.run_env()
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/script/base.py",
line 475, in run_env
util.load_python_file(self.dir, "env.py")
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/util/pyfiles.py",
line 90, in load_python_file
module = load_module_py(module_id, path)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/util/compat.py",
line 216, in load_module_py
mod = imp.load_source(module_id, path, fp)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/kallithea/alembic/env.py",
line 105, in
run_migrations_online()
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/kallithea/alembic/env.py",
line 99, in run_migrations_online
context.run_migrations()
File "", line 8, in run_migrations
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/runtime/environment.py",
line 839, in run_migrations
self.get_context().run_migrations(**kw)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/runtime/migration.py",
line 361, in run_migrations
step.migration_fn(**kw)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/kallithea/alembic/versions/4851d15bc437_db_migration_step_after_95c01895c006_.py",
line 39, in upgrade
batch_op.create_index('usk_public_key_idx', ['public_key'],
unique=False)
File "/opt/python27/lib/python2.7/contextlib.py", line 24, in __exit__
self.gen.next()
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/operations/base.py",
line 325, in batch_alter_table
impl.flush()
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/operations/batch.py",
line 73, in flush
fn(*arg, **kw)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/ddl/impl.py",
line 275, in create_index
self._exec(schema.CreateIndex(index))
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/alembic-1.0.8-py2.7.egg/alembic/ddl/impl.py",
line 134, in _exec
return conn.execute(construct, *multiparams, **params)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
line 980, in execute
return meth(self, multiparams, params)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/sqlalchemy/sql/ddl.py",
line 72, in _execute_on_connection
return connection._execute_ddl(self, multiparams, params)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
line 1042, in _execute_ddl
compiled,
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
line 1240, in _execute_context
e, statement, parameters, cursor, context
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
line 1458, in _handle_dbapi_exception
util.raise_from_cause(sqlalchemy_exception, exc_info)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/sqlalchemy/util/compat.py",
line 296, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
File
"/var/www/environments/kalivenv/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
line 1236, in _execute_context
Re: errors with cloning remote mercurial that's HTTPS based
Mads Kiilerich wrote:
> On 12/21/18 5:52 AM, Ed Wong wrote:
>> Hi,
>>
>> I've followed the Contribution page [1] page and
>> would like to understand what I might be doing wrong.
>>
>> I've set up the 0.3.99 Kallithea (via [1]) and while the dev site isn't
>> https-based, the remote repos that I clone off of do use HTTPS and
>> the code doesn't seem to like that. (It's perfectly ok with 0.3.6.
>> but 0.3.99 doesn't like it)
>>
>> I am getting:
>>
>> Exception AttributeError: "'httppeer' object has no attribute
>> '_urlopener'" in > > ignored
>> 2018-12-21 12:28:38.122 ERROR [kallithea.model.validators] URL
>> validation failed
>> Traceback (most recent call last):
>> File "/home/kali/kallithea/kallithea/model/validators.py", line 430,
>> in validate_python
>> is_valid_repo_uri(repo_type, url, make_ui('db',
>> clear_session=False))
>> File "/home/kali/kallithea/kallithea/lib/utils.py", line 226, in
>> is_valid_repo_uri
>> MercurialRepository._check_url(url, ui)
>> File
>> "/home/kali/kallithea/kallithea/lib/vcs/backends/hg/repository.py", line
>> 349, in _check_url
>> % (cleaned_uri, e))
>> URLError: > [https://:*@hg.mozilla.org/releases/comm-beta] does not look like an
>> hg repo org_exc: __init__() takes exactly 7 arguments (3 given)>
>
>
> It sounds like an issue that is solved by
> https://lists.sfconservancy.org/pipermail/kallithea-general/2018q4/002877.html
> - can you confirm?
>
> And thanks for giving feedback!
>
Yes, I can confirm it works! But when I click on "add", should it not
go to the "Cloning Repository... please wait"(or something like that)?
It's currently still at the Add Repository page and the page is
Loading.
Thanks!
Ed
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
errors with cloning remote mercurial that's HTTPS based
Hi,
I've followed the Contribution page [1] page and
would like to understand what I might be doing wrong.
I've set up the 0.3.99 Kallithea (via [1]) and while the dev site isn't
https-based, the remote repos that I clone off of do use HTTPS and
the code doesn't seem to like that. (It's perfectly ok with 0.3.6.
but 0.3.99 doesn't like it)
I am getting:
Exception AttributeError: "'httppeer' object has no attribute
'_urlopener'" in > ignored
2018-12-21 12:28:38.122 ERROR [kallithea.model.validators] URL
validation failed
Traceback (most recent call last):
File "/home/kali/kallithea/kallithea/model/validators.py", line 430,
in validate_python
is_valid_repo_uri(repo_type, url, make_ui('db', clear_session=False))
File "/home/kali/kallithea/kallithea/lib/utils.py", line 226, in
is_valid_repo_uri
MercurialRepository._check_url(url, ui)
File
"/home/kali/kallithea/kallithea/lib/vcs/backends/hg/repository.py", line
349, in _check_url
% (cleaned_uri, e))
URLError: https://:*@hg.mozilla.org/releases/comm-beta] does not look like an
hg repo org_exc: __init__() takes exactly 7 arguments (3 given)>
This is when I try to add a repository:
https://hg.mozilla.org/releases/comm-beta.
I'm using Mercurial 4.8.1 and I noticed this version's httppeer.py's
httppeer class has 7 arguments as opposed to 4.3.1's version which
only has 3.
Basically from this (line336 from
kallithea/lib/vcs/backends/hg/repository.py:
try:
httppeer(repoui or ui.ui(), url).lookup('tip')
and for 4.3.1's httppeer.py :
class httppeer(wireproto.wirepeer):
def __init__(self, ui, path):
self.path = path
self.caps = None
whereas 4.8.1's httppeer:
class httppeer(wireprotov1peer.wirepeer):
def __init__(self, ui, path, url, opener, requestbuilder, caps):
Is this a known issue?
Thanks
[1]-
https://kallithea.readthedocs.io/en/latest/contributing.html#getting-started
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
