On 21/02/2024 10:41, Ed Wong wrote:
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:])
Thanks.
Without digging deep at all, a quick answer:
Evidently, that is a corner case that doesn't have any/sufficient test
coverage. But it might not be worth it to add it.
First of all, it is a bug that this NodeError shows up as a server
error. It should show a nice error, as it
On 11/11/2023 12:25, Branko Majic wrote:
Since a couple of days ago, I don't seem to be able to access the main
Kallithea website (https://kallithea-scm.org/). The connections keeps
timing out.
And it seems to be back now... I guess somebody restarted a service or
two or...? :)
Yeah - sorry
Hi
It seems odd that the problem should be caused by the upgrade.
Celery is not involved when cloning, so that doesn't make any difference.
If the problem only was seen with http, then I would blame the proxy.
Both the problems with ssh rules that out.
Especially for ssh, Kallithea gets out
On 09/05/2023 16:04, toras wrote:
> I propose
https://kallithea-scm.org/repos/kallithea-incoming/changeset/dee1b60bad29621882eb769eb5bc8707647ccf1d
.
As far as I have tried, I believe this change fixes the new owner to
operate correctly. (Both from the web and from the API.)
Thanks for
On 07/05/2023 17:37, toras wrote:
Commit abc29122c7f2 has been addressed to allow repository group owner
changes.
I think the owner change itself is working.
However, for non-admin users, the permission evaluation in the
repository group seems to be incorrect.
For example, if you try to
On 20/04/2023 14:55, Manuel Jacob wrote:
# HG changeset patch
# User Manuel Jacob
# Date 1681995256 -7200
# Thu Apr 20 14:54:16 2023 +0200
# Node ID 56aad162afcff89ec7e0b8cc7a60fff2bbde6ec1
# Parent 294f5a6814edc267c87a77dad5131c08a50fae1c
# EXP-Topic non_publishing_changeset_evolution
On 20/04/2023 01:30, Manuel Jacob wrote:
On 20/04/2023 01.07, Mads Kiilerich wrote:
Thanks - this looks much more approachable.
But while processing v2 and our discussion and trying to give good
input to what I would like to see in v3, I figured it perhaps would
be better with a simpler
Thanks - this looks much more approachable.
But while processing v2 and our discussion and trying to give good input
to what I would like to see in v3, I figured it perhaps would be better
with a simpler solution.
What do you think about doing it as in
On 19/04/2023 17:27, Manuel Jacob wrote:
On 19/04/2023 17.21, Manuel Jacob wrote:
On Arch Linux:
% git --version
git version 2.40.0
% GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_SYSTEM=/dev/null
EMAIL='foo@bar' git commit -m "committed new 0" --author "User ǝɯɐᴎ
"
Committer identity unknown
On 19/04/2023 15:14, Manuel Jacob wrote:
On 19/04/2023 14.27, Mads Kiilerich wrote:
On 18/04/2023 20:35, Manuel Jacob wrote:
...
I think this changeset should come first. As you say, it makes the
test work the same way everywhere. user.useconfigonly is probably
just one of many settings
On 18/04/2023 20:35, Manuel Jacob wrote:
# HG changeset patch
# User Manuel Jacob
# Date 1680139355 -7200
# Thu Mar 30 03:22:35 2023 +0200
# Branch stable
# Node ID e5251abd0a3c677d7bb0828f3a744789bd6fe4cb
# Parent 30082bb9719eb00f3be0081b7221d7c3061d4345
# EXP-Topic tests-git
tests:
Hi
The code in this area has worked surprisingly well since Kallithea
inherited it, even though it has popped up regularly needing tricky
maintenance. I agree it would be nice to refactor / reimplement this
area. It is just that nobody invested time or sponsorship in doing it. I
guess it
On 17/04/2023 15:45, Manuel Jacob wrote:
On 17/04/2023 13.39, Mads Kiilerich wrote:
Hi
That seems to be a Mercurial 6.4 regression, introduced by
87f0155d68aa .
Can you confirm, and will you follow up upstream?
I can do that, but I would be interested in how you found out.
At first I
Hi
That seems to be a Mercurial 6.4 regression, introduced by 87f0155d68aa .
Can you confirm, and will you follow up upstream?
/Mads
On 17/04/2023 03:10, Manuel Jacob wrote:
When I cloned the Kallithea repository, it was corrupted.
% hg clone https://kallithea-scm.org/repos/kallithea
Hi
I haven't seen that problem and can't reproduce it.
The wait for 10 seconds in some pretty obscure code came from a comment
in
https://kallithea-scm.org/repos/kallithea/changeset/034e4fe1ebb2#rhodecodelibsubprocessiopy_n127
before The Big Fork. The comment became reality in
Hi
You are right. That regressed with TurboGears 2.4.3, kind of documented
on https://github.com/TurboGears/tg2/releases .
As a workaround, does it work as expected for you if setting
i18n.native = en
?
I will consider pushing
Hi
Some brief comments to the big questions:
c.cs_repo.statuses() is already used for finding status for changeset
hashes in bulk. It will perhaps also be able to handle that you pass all
ancestor hashes for all pending PR changes. But you will of course have
to process the result and pick
Thanks - pushed to stable.
/Mads
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Thanks - pushed to stable.
/Mads
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
On 30/03/2023 03:37, Manuel Jacob wrote:
# HG changeset patch
# User Manuel Jacob
# Date 1680139355 -7200
# Thu Mar 30 03:22:35 2023 +0200
# Node ID 4933600c49883dfc142f97a32dd08f9dd82b0d31
# Parent 2304f8da62b03f6cfd966b72eec70c38c4d52e37
# EXP-Topic tests-git
tests: prevent Git system
On 30/03/2023 03:37, Manuel Jacob wrote:
# HG changeset patch
# User Manuel Jacob
# Date 1680121377 -7200
# Wed Mar 29 22:22:57 2023 +0200
# Node ID 2304f8da62b03f6cfd966b72eec70c38c4d52e37
# Parent 7037365a7bc351b81f05c790c6d3417d81d7bd5d
# EXP-Topic tests-git
tests: set Git author and
----
*Van: *"Mads Kiilerich"
*Aan: *"vanheesbeke stefaan" , "kallithea-general"
*Verzonden: *Dinsdag 21 februari 2023 15:25:10
*Onderwerp: *Re: username allowed characters
Hi
Tha
Hi
Thank you.
But ...
Kallithea generally tries to keep logins and emails unambiguous and in
different namespaces. It is arguably a bug if Kallithea allows LDAP to
use email addresses as usernames.
The assumption is probably not entirely enforced, but it and the
consequences show up for
Thank you. Pushed to stable with some minor tweaks and additions.
/Mads
On 18/01/2023 07:45, Mathias De Mare wrote:
# HG changeset patch
# User Mathias De Mare
# Date 1672834977 -3600
# Wed Jan 04 13:22:57 2023 +0100
# Branch stable
# Node ID ac278c9c011136b72de43d8dbd742f9cf3dbf020
#
.
Professor, Faculty of Science, Engineering and Information Technology
Durham College
-Original Message-
From: Mads Kiilerich
Sent: October 29, 2022 12:08 PM
To: Louis Bertrand
Subject: Re: Patch for repo groups API documentation
[EXTERNAL EMAIL - USE CAUTION]
(Private reply)
Thanks
On 18/12/2022 10:48, toras wrote:
>> Attachment: fix-update_repo_group-2.patch
>
> Lots of things happening in that patch. Can you explain in more
details what is changed and why ... and perhaps do it in several
> simpler changesets?
...
The second is to modify the log output.
Sorry for the
should perhaps test when I
can. As far as uwsgi-socket goes, it seems to be just a synonym for
socket.
All the best,
- David
On Mon, 12 Dec 2022 at 15:12, Mads Kiilerich wrote:
Hi David
The Kallithea docs aim to help getting a very basic setup with the
essentials. Somet
On 30/10/2022 13:00, toras wrote:
> Yes. Can you confirm this will solve the code problems you reported:
>
https://kallithea-scm.org/repos/kallithea-incoming/changeset/088551a24485247af328f0b8e395fdbbcd62a700
?
1. Modify create_repo()
I don't think this change is correct.
I overwrote
Thank you.
Is the overwhelming on the server side or in the browser?
I don't like showing incorrect information. Lists must be reliable. It
must be made quite clear when lists have been truncated.
It would conceptually also be nice to be able to opt out of the truncation.
But that raise the
Hi David
The Kallithea docs aim to help getting a very basic setup with the
essentials. Something that perhaps can be used directly, but mainly
serve as a starting point for further setup which is outside the scope
of Kallithea. It is important to keep the configuration examples focused
Hi
Yes. Can you confirm this will solve the code problems you reported:
https://kallithea-scm.org/repos/kallithea-incoming/changeset/088551a24485247af328f0b8e395fdbbcd62a700
?
/Mads
On 29/10/2022 09:28, toras wrote:
Hi
I then noticed that the enable_downloads/enable_statistics parameters
Hi
Thank you. (If you are working from a repo checkout, it would be more
helpful if you could send a diff.) I haven't verified in detail, but all
the changes seem plausible ;-) I have pushed them to the stable branch.
One question though:
id :
result : {
ot pip.
hint: See above for details.
Hope this helps
--Louis
-Original Message-
From: Mads Kiilerich
Sent: September 17, 2022 2:52 PM
To: Louis Bertrand ; Kallithea
Subject: Re: repo groups API methods not documented
[EXTERNAL EMAIL - USE CAUTION]
I found that the supported Sphin
-Louis
-----Original Message-
From: Mads Kiilerich
Sent: September 17, 2022 8:55 AM
To: Louis Bertrand ; Kallithea
Subject: Re: repo groups API methods not documented
[EXTERNAL EMAIL - USE CAUTION]
Hi
That is just the documentation that is incomplete (and perhaps slightly wrong).
You can ge
Hi
That is just the documentation that is incomplete (and perhaps slightly
wrong).
You can get an idea of the functionality by looking at the
implementation in
https://kallithea-scm.org/repos/kallithea/files/stable/kallithea/controllers/api/api.py
.
/Mads
On 9/17/22 10:11, Louis
Hi
Right. Thanks for reporting.
That should be fixed with
https://kallithea-scm.org/repos/kallithea/changeset/ed117efc9ae952bbab966a267bbd2297d31b05e2
.
You can apply the fix manually, or install from the stable branch -
Hi
Right. I reproduced on
http://localhost:5000/_admin/user_groups/1/edit/perms and fixed it (and
other similar potential problems).
See
https://kallithea-scm.org/repos/kallithea/changeset/cc70797e70e16163c6862a42f7f045fb6782f202
.
For now, you can upgrade to the head of the stable
Pushed to stable - thanks.
These auto generated doc strings have no value and adds a maintenance
burden. It would be equally good to just remove them.
/Mads
On 2/26/22 05:24, Manuel Jacob wrote:
# HG changeset patch
# User Manuel Jacob
# Date 1645849430 -3600
# Sat Feb 26 05:23:50
Pushed to stable - thanks.
/Mads
On 2/25/22 22:08, Manuel Jacob wrote:
# HG changeset patch
# User Manuel Jacob
# Date 1645822846 -3600
# Fri Feb 25 22:00:46 2022 +0100
# Branch stable
# Node ID 397f73d1cdd4b39c9c17bb8d45592e866fcab88c
# Parent 017595560fc1e0f2acc086c63ed5f8906011d77b
On 2/26/22 05:06, Manuel Jacob wrote:
# HG changeset patch
# User Manuel Jacob
# Date 1645848272 -3600
# Sat Feb 26 05:04:32 2022 +0100
# Branch stable
# Node ID 84c94153376698aa028c03dbad1fc0dcf6f081ed
# Parent 397f73d1cdd4b39c9c17bb8d45592e866fcab88c
hg: use correct start / stop indices
Yes, now "メモ.txt" works for me too.
/Mads
On 2/8/22 14:58, toras wrote:
Hello.
I'm sorry, I should have given a concrete example.
Thank you for creating the fix code.
From the conclusion, I've confirmed that the fixed code downloaded the
file correctly.
I tried overwriting the fixed file
Hi
Thanks for the report.
It took a while to reproduce. Many filenames work ok. An exact example
would have been helpful.
I reproduced the problem (or another similar one) on Linux with a
Mercurial repository with a file created as
python -c 'open("\U0001f4a9", "w").write("\U0001f4a9")'
://www.w3.org/International/questions/qa-lang-priorities .
/Mads
On 1/13/22 14:32, Ansis Māliņš wrote:
What I want is a 100% English UI. Why is Kallithea trying to show me
the German localization at all? I did not find any language settings
anywhere.
On Sun, Jan 9, 2022 at 6:57 PM Mads Kiilerich
Hi
That is because the German translation isn't fully updated. Not really a
bug, just work that has to be done. It is kind of tracked on
https://hosted.weblate.org/projects/kallithea/kallithea/ .
A small peek behind the scene shows for example
On 12/10/21 18:14, Uwe Brauer wrote:
On 12/10/21 12:29, Łukasz Michalski wrote:
Hi,
I would like to migrate a repository myrepo from mercurial to git.
I want to rename mercurial repository to myrepo_old and use orginal name for
new git repository.
Is it enough to rename mercurial repository
On 12/10/21 12:29, Łukasz Michalski wrote:
Hi,
I would like to migrate a repository myrepo from mercurial to git.
I want to rename mercurial repository to myrepo_old and use orginal name for
new git repository.
Is it enough to rename mercurial repository on disk and copy new one under
Hi
In what way do you experience that it doesn't work with Kallithea?
Kallithea implements a custom wrapper around hgweb. Mainly to provide
integrated hosting with correct access control. It is a basic assumption
that reads are with GET and writes are with POST.
Without being told more
On 10/4/21 23:31, Don Zimmer wrote:
Hi,
I had set up an Apache server running Kallithea recently and all seems
working well except I have just discovered that although ‘git clone’
works on an http URL to my server, that ‘git fetch’ fails with the
message ‘fatal: not a git repository (or any
On 7/22/21 18:13, A. Klitzing wrote:
By the way... I receive this in my log if I create a new repository
with a clone:
Fehler: Hook changegroup.kallithea_push_action löste eine Ausnahme
aus: Environment variable KALLITHEA_EXTRAS not found
But the repository works after that.
I have noticed
On 6/17/21 7:04 AM, 김태호 wrote:
Hello Kallithea, Thank you so much.
We ended up upgradingthe EC2 instane from t2.micro to r5.xlarge.
So the specifications of the instance are as follows.
(Intel Xeon 3.1GHz Skylake-SP or Cascade Lake) vCPU = 4, RAM = 32GiB
We set the thread value to 1 when
and we can use the pull
command about GIT Repo.
However, in Mercurial Repo, no function can be used.
Do I have to install additionally to use Mercurial Repo?
What am I supposed to do?
Regards,
JH Park.
*From:*Mads Kiilerich
*Sent:* Thursday, June 17, 2021 6:07 AM
*To:* 김태호; kallithea-general
On 6/15/21 1:02 PM, 김태호 wrote:
We are testing by installing 0.7.0 version of Kallithea in two
different environments.
One was installed on WSL2 on my Windows 10 computer, and the other on
EC2 (t2.Micro, Ubuntu20.04) on AWS.
The Kallithea git repo that I want to download is about 2.84GB.
On 6/11/21 12:07 PM, 김태호 wrote:
Hello Kallithea
Thank you for your answer !
We have solved Question1 and Question3 but the second one.
To help others with similar problems (and perhaps help us improve the
software to avoid it), can you explain what the problem was and how you
solved
Hi
On 6/10/21 9:25 AM, 김태호 wrote:
*>> Question 1*
We are constantly getting this kind of log as following (at WARNING
level) :
...
2021-06-10 07:04:42.989 ERROR
[kallithea.lib.auth_modules.auth_internal] user admin had a bad password
2021-06-10 07:04:42.989 WARNI
I think Kallithea is using gearbox in a pretty standard way. You can
tweak your .ini to change the configuration.
What do you get in the Kallithea logs for such requests - especially
after setting the log levels to DEBUG?
On 6/7/21 8:12 AM, 김태호 wrote:
Hello Kallithea
We are currnetly
Hi
I have no magic solution to "doesn't work". We will need more info.
Exactly how did you configure crowd auth in Kallithea? On which address
is your crowd instance running?
How do you experience it doesn't work?
What do you get in the server log when it doesn't work? Especially with
Hi
No, we haven't made any recommendations. It depends so much on the size
of repositories and the amount of usage and traffic. For private use, it
is probably fine if it can serve one page per second, so everything is
fine as long as it doesn't start swapping. Memory will probably be the
On 4/21/21 1:50 PM, Mads Kiilerich wrote:
On 4/21/21 2:09 AM, Felipe Cardoso Resende wrote:
Hi,
I'm experimenting with kallithea but I'm having trouble making it
read from the .hg/hgrc inside the project. Looking through
the history, I found the revision 802fdeefc8cc linking to
Issue #246 [1
On 5/19/21 4:21 PM, Louis Bertrand wrote:
Hello,
When I upgraded Kallithea, I somehow changed the venv directory from
~/kallithea-venv to kallithea/venv. In other words, instead of a venv directory
beside the kallithea directory, it's now under the directory.
Everything is fine except for
On 4/21/21 2:09 AM, Felipe Cardoso Resende wrote:
Hi,
I'm experimenting with kallithea but I'm having trouble making it
read from the .hg/hgrc inside the project. Looking through
the history, I found the revision 802fdeefc8cc linking to
Issue #246 [1] that changes how the configuration is read.
On 4/13/21 4:29 PM, Brett Smith wrote:
Hi Kallithea team,
I got this crash report I thought I should pass on. The short version:
some IP address/Internet mapping service visited us, and provided a
full DNS hostname in the various IP address headers. The code crashes
because it assumes any
Hi
Thanks for the report and the test case.
Yes, that comment is wrong. It didn't consider that if the page number
is too high, the resulting page will be empty even though the first page
isn't.
I propose fixing it with
of
this setting value.
I'm looking forward to future versions including behavior fixes.
Thanks
toras9000
On 2021/01/03 7:49, Mads Kiilerich wrote:
Hi
You are right. Kallithea has some bugs around API permission
handling. It is not
using the "create top-level repositories" p
On 1/11/21 10:16 PM, Lance Edgar wrote:
On 1/11/21 7:53 AM, Mads Kiilerich wrote:
As next step, I propose the changes in
https://kallithea-scm.org/repos/kallithea/pull-request/306/_/hooks .
Some of it took a slightly different direction than Tim proposed. And
cleaning up many other related
m
being honest I think option A should exist and if so I'd use it.
On 11/4/20 3:14 AM, Tim Ooms wrote:
On 24/10/2020 13:05, Mads Kiilerich wrote:
On 10/23/20 9:30 AM, Tim Ooms wrote:
It might have rough edges to bypass Kallithea when accessing
Kallithea-managed repos. It is perhaps bet
Hi
You are right. Kallithea has some bugs around API permission handling.
It is not using the "create top-level repositories" permissions correctly.
This problem is related to the
"This will also give all users API access to create repositories
everywhere. That might change in future
We landed the fix as
https://kallithea-scm.org/repos/kallithea/changeset/f950740985f47ea09ef3361fa56b3d7581429156
Thanks,
Mads
On 12/15/20 4:10 PM, Brett Smith wrote:
On 12/14/20 5:15 PM, Mads Kiilerich wrote:
Ouch, yeah, .splitlines() is confusingly different from .split('\n')
. Thanks
Ouch, yeah, .splitlines() is confusingly different from .split('\n') .
Thanks for the patch.
Would it perhaps be better to just use .split instead of .splitlines()?
But since the commit message text is shown as a link, would it perhaps
be even better to avoid the void and show a text like
ith virtualenv, but in my opinion the hook
should be changeable
*Von:*Mads Kiilerich
*Gesendet:* Freitag, 4. Dezember 2020 00:43
*An:* Benny Bürger ; kallithea-general@sfconservancy.org
*Betreff:* Re: Issue with kallithea 0.6.2 in combination with
mercurial hook
If you can get the same error when
lled, although did a test with 5.6
but there was another error.
*Von:*Mads Kiilerich
*Gesendet:* Montag, 30. November 2020 17:59
*An:* Benny Bürger ; kallithea-general@sfconservancy.org
*Betreff:* Re: Issue with kallithea 0.6.2 in combination with
mercurial hook
On 11/30/20 5:30 PM, Benn
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.
I've been
On 11/30/20 5:30 PM, Benny Bürger wrote:
Hi,
I use the pretxnchangegroup.check with a bash script.
The script executes but the error code is ignored because of the
following error:
Gegenseite: Traceback (most recent call last):
Gegenseite: File "/usr/local/bin/hg", line 43, in
On 11/20/20 9:49 AM, Łukasz Michalski wrote:
On 19/11/2020 20.53, Mads Kiilerich wrote:
On 11/19/20 4:31 PM, Łukasz Michalski wrote:
Hi,
I have a problem with one of git repos. When I try to push changes I got "remote
rejected":
[zork@serenity filebench]$ git push zork
Password
On 11/19/20 4:31 PM, Łukasz Michalski wrote:
Hi,
I have a problem with one of git repos. When I try to push changes I got "remote
rejected":
[zork@serenity filebench]$ git push zork
Password for 'https://zork@':
Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
On 11/5/20 1:11 AM, Mads Kiilerich wrote:
On 11/3/20 5:08 PM, Valentin Kleibel wrote:
Hi,
We are using kallithea with a postgres database on another server
connected via ssl.
It seems that celery in version 4 uses prefork in its worker pool
model now, which leads to issues
On 11/3/20 5:08 PM, Valentin Kleibel wrote:
Hi,
We are using kallithea with a postgres database on another server
connected via ssl.
It seems that celery in version 4 uses prefork in its worker pool
model now, which leads to issues with such a database connection:
I think you are right
Hi
Thanks for reporting ... and for the proposed fix.
That bug is something I missed when porting to py3. Apparently, other
Git implementations are less strict, and it didn't come up while testing.
But I think the fix can be made simpler and more complete:
Hi
Thanks for reporting.
I have fixed the welcome message.
Enjoy,
Mads
On 10/27/20 3:47 PM, Valentin wrote:
Hi,
I just joined thje mailing list and noticed that the nmailman welcome
message for this list still contains links to the removed wiki and
issue tracker on bitbucket.org.
It
On 10/23/20 9:30 AM, Tim Ooms wrote:
# HG changeset patch
# User Tim Ooms
# Date 1603201903 -7200
# Tue Oct 20 15:51:43 2020 +0200
# Node ID 672e57b165d0c1774b692b5706a174bf98f42e4c
# Parent b9b53e25a08d3714c54d82641b419e6d01820e12
git: move non-kallithea hooks and execute other hooks
On 9/28/20 2:03 AM, Ed Wong wrote:
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
(Note: please post to kallithea-general@sfconservancy.org - not to the
-bounces address.)
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
I started looking at it.
https://kallithea-scm.org/repos/kallithea/pull-request/273/_/refactorings_and_stable_fixes_from_mailing_list
propose some tests (after refactoring to add basic test coverage of git
PRs).
/Mads
On 9/25/20 6:38 PM, Thomas De Schampheleire wrote:
Hi,
Thanks for your
On 8/23/20 7:29 AM, Thomas De Schampheleire wrote:
Aug 22 22:29:49 universe gearbox[22393]: File
"/srv/kallithea/venv/lib/python3.7/site-packages/kallithea/lib/vcs/nodes.py",
line 587, in __init__
Aug 22 22:29:49 universe gearbox[22393]: self.path =
name.rstrip('/')
On 8/15/20 2:00 PM, Uwe Brauer wrote:
1. I understand kallithea comes with some sort of notifying utility?
That would be sort of important, I usually use notify myself but
other users might not.
Yes, users will be notified by mail when they are added to PRs, and also
On 8/14/20 10:03 PM, Uwe Brauer wrote:
> Hi Uwe,
> On Fri, Aug 14, 2020, 17:24 Uwe Brauer wrote:
> In general you should avoid changing such links manually. I suggest you
> restore the original one.
> The virtual environment (venv) created with the command will use the
On 8/13/20 9:24 PM, Uwe Brauer wrote:
"MK" == Mads Kiilerich writes:
> On 8/13/20 8:53 PM, Uwe Brauer wrote:
>>> I suggest creating /srv/kallithea as root, and chown it to the
>>> kallithea user. (I am trying to tweak the documentation based on you
On 8/13/20 9:15 PM, Uwe Brauer wrote:
which version (changeset) requires only 3.5)??
3.6 was the first python3 we supported. (Inherited from the versions
supported by Mercurial).
3.5 was never supported.
0.5.2 aa0a637fa6f6 was the last py2 version.
For a simple test I think that should
On 8/13/20 8:53 PM, Uwe Brauer wrote:
I suggest creating /srv/kallithea as root, and chown it to the
kallithea user. (I am trying to tweak the documentation based on your
input and already had some draft changes to this.)
Good, at least something useful will come out from my intents. ;-)
When
On 8/13/20 7:54 PM, Uwe Brauer wrote:
> Hi Uwe,
> On Thu, Aug 13, 2020, 17:50 Uwe Brauer
wrote:
> The '.' is an alias to the 'source' shell command. It reads and executes
> the file provided as arguments.
> See section "Shell Builtin Commands" at:
>
On 8/13/20 5:45 PM, Uwe Brauer wrote:
Hi
Since I cannot install kallitea via pip (my python version in Ubuntu
16.04 is too old) I thought to give the installation from source a try.
The documentation in
https://kallithea.readthedocs.io/en/stable/installation.html
Reads
,
| hg clone
On 8/13/20 5:42 PM, Uwe Brauer wrote:
> It seems like your installation somehow got off track and you thus got
> on a bumpy road. At this point I would suggest reinstalling Ubuntu (to
> get an easy cleanup after the things done as root) and start over,
> keeping records of which
On 8/13/20 1:47 PM, Uwe Brauer wrote:
> On 8/13/20 10:39 AM, Uwe Brauer wrote:
> We can improve the documentation to say something like
> but I don't know if we should go into details on how to do it on each OS.
> Googling for "ubuntu /usr/bin/env: ‘node’: No such file or
On 8/13/20 1:35 PM, Uwe Brauer wrote:
I guess this perhaps could be caused by partial installation from
previous attempts. Try to delete kallithea/front-end/node_modules/ and
try again.
Thanks, but this directory does not exist
node_modules is created and updated when running `kallithea-cli
On 8/13/20 10:39 AM, Uwe Brauer wrote:
> Hi Uwe,
> On Thu, Aug 13, 2020, 10:11 Uwe Brauer wrote:
> It seems this is version dependent. The nodejs package on later versions
> indeed provides both node and nodejs.
> I don't know if there is a non-manual way in ubuntu 16.04
is needed with py3?
I currently don't use mod_wsgi myself. Can you help verify if your
dispatch script works without these?
/Mads
From: Mads Kiilerich
Sent: Saturday, August 1, 2020 4:49 PM
To: Louis Bertrand; Kallithea
Subject: Re: Unable to connect to WSGI daemon process
[EXTERNAL EMAIL]
On 7/31/20 4:37 PM, Louis Bertrand wrote:
There was a disconnect between Apache and the Kallithea WSGI daemon process.
The WSGI daemon was unable to read the socket. The exact error message in
Apache's logs/ssl-errors is
[Thu Jul 30 17:52:34.396927 2020] [wsgi:error] [pid 10169]
On 7/30/20 3:03 PM, Louis Bertrand wrote:
Hi,
While reviewing the installation of Kallithea on a test server, one of our
college Unix admins pointed out two issues with the way SSH public keys are
saved in .ssh/authorized_keys
1) When a user is deleted from the Kallithea system, the public
any of my own
itches, except for the itch for keeping the project going.
Now I happen to have time and skills to provide consulting or custom or
sponsored development in this area.
Please contact me directly if you are interested.
Regards,
Mads Kiilerich
m...@kiilerich.com
On 5/15/20 9:35 PM, Louis Bertrand wrote:
I chose PostgreSQL because a) it's already installed on the eventual
target server and b) I'm familiar with it. However, where is the
trade-off between SQLite and PostgreSQL? Tens, hundreds, thousands?
Number of users, transactions? Etc. In other
1 - 100 of 539 matches
Mail list logo
