Hi t3ss,
Is the pip you're invoking pip2 or pip3? Maybe you're installing the
package for Python2, when the Website builder is using Python3. Could
you post the output of "pip --version"?
- Florian
On 7/27/21 2:15 PM, t3sserakt wrote:
Hello *,
although I run
pip install jinja2.ext
I go
On 5/27/20 2:46 PM, Schanzenbach, Martin wrote:
> Here, a message of "fix #1234" is NOT sufficient.
> I have done so myself and have found ~50 in the current log since 0.12.1.
> Those are not useful messages. Having to do to mantis to check the changes
> meaning
> is quite annoying. Especially if
On 5/27/20 1:58 PM, Daniel Golle wrote:
> Yes, let's please establish something like that. I've tried my best
> myself, but that's like 0.01% of GNUnet commits -- and of course,
> as was pointed out in a previous debate on that, GNUnet is not the
> Linux kernel and experimentation becomes very
Hi *,
On 4/19/20 5:31 PM, Alessio Vanni wrote:
> In my opinion, a nicer approach could be something based on Java's
> Buffer object from the NIO package. For example (again no error
> checking; also the names could use some more work):
We already have something exactly like that:
https://git.gn
ss that couldn't be started in the first place (since
the binary doesn't exist). But that's not really that bad.
- Florian
On 9/24/19 11:22 AM, Christian Grothoff wrote:
> On 9/24/19 11:14 AM, Florian Dold wrote:
>> Hi *,
>>
>> I ran into two usability issues with
7;t be started in the first place (since
the binary doesn't exist). But that's not really that bad.
- Florian
On 9/24/19 11:22 AM, Christian Grothoff wrote:
> On 9/24/19 11:14 AM, Florian Dold wrote:
>> Hi *,
>>
>> I ran into two usability issues with GNUnet's a
Hi *,
I ran into two usability issues with GNUnet's arm:
When a service couldn't be executed at all because the binary doesn't
exist, arm logs a message at the *info* log level. This means the
message usually won't be seen *anywhere*, since the info log level is
too verbose and thus supressed.
4/18/19 2:44 PM, Hartmut Goebel wrote:
> Am 18.04.19 um 14:31 schrieb Florian Dold:
>> I am curious why this file had to be committed *individually* to every
>> repository, including the wallet and python repositories? It's
>> completely useless for these projects
>
Hi Hartmut,
It's a bit disheartening to see an honest attempt to improve things
being shot down like this.
The clang-format style that Martin created tries to mirror what style
the existing codebase already has or is supposed to have. If you want
to make any tweaks on top of that, please contrib
On 4/10/19 1:10 AM, Raphael Arias wrote:
> I don't see why the database of a read-only legacy system would need to
> be regularly backed up. If it remains online purely as an archive
> (possibly with a note to go see the gitlab issue tracker) history is
> preserved while not forcing anyone to do re
> No, we don't. We dvn et al are faced with unreasonable requirements for the
> use of gitlab which include:
>
> - Migration of Mantis issues -> completely unnecessary. Mantis could remain
> read-only for the "legacy" issues and gitlab used for new issues.
> - No user forks, no pull requests ->
On 4/7/19 6:46 PM, Schanzenbach, Martin wrote:
> The CAA does not help in any way. You are still liable as a platform. It has
> literally nothing to do with the copyright infringements if the contributor
> copied code from somewhere else. You cannot delegate this responsibility
> anymore to the
9 12:47 PM, Florian Dold wrote:
> On 4/7/19 8:33 AM, Schanzenbach, Martin wrote:
>> Contributors should be able to do anything they want in their own namespaces
>> including committing code that does not compile (e.g. for their gnunet.git
>> forks).
>> However, in order to
On 4/7/19 8:33 AM, Schanzenbach, Martin wrote:
> Contributors should be able to do anything they want in their own namespaces
> including committing code that does not compile (e.g. for their gnunet.git
> forks).
> However, in order to get it into the "main" gnunet project codebase, the CI
> mus
On 4/7/19 6:29 AM, Devan C. - dvn wrote:
> Until email/smtp is setup we will not have confirmation emails.
Ah. I assumed the setup was mostly complete and you wanted feedback.
> Neither of these are actual problems right now, because it is easy
> enough to manually administer, prune, and moderat
Thanks for taking the time to set this up. So far some things don't
seem right yet:
There is a massive security problem. Everybody (!!) is able to create
accounts and set their password, *without* being the owner of the
respective email address. As "proof", I've been so friendly to create
an ac
On 3/19/19 6:55 PM, Christian Grothoff wrote:
> On 3/16/19 10:32 PM, Florian Dold wrote:
>> The model of "nobody should push to master" is great if you have the
>> right tooling on the server, but breaks GPG signing of commits by the
>> author, AFAICT.
>
>
On 3/19/19 8:05 PM, n...@n0.is wrote:
> Christian Grothoff transcribed 5.4K bytes:
> See my last message and read it. It depends on if this
> is applicable. I'll spend tomorrow looking into the 2
> codebases and deciding on if/how this can be applied
> for us.
Please see
ssh://g...@git.taler.ne
I agree with what you've said about not encoding hierarchies in
gitolite. I also think that either nobody or everybody should be able
to merge into master.
The model of "nobody should push to master" is great if you have the
right tooling on the server, but breaks GPG signing of commits by the
au
On 2/10/19 1:55 PM, Schanzenbach, Martin wrote:
>> An example for such
>> tooling would be Googles's Repo tool
>> (https://source.android.com/setup/develop /
>> https://source.android.com/setup/develop/repo).
>
>
> Actually, google is an example for a proponents of monorepos. So your point
> is
From my experience with working on GNU Taler, I tend to agree with the
arguments *against* multirepos, especially for GNUnet.
Multirepos tend to work well if either:
a) The language you're using has support for project-local package
dependencies. This is the case for JavaScript (with npm/yarn),
I'm not the biggest fan of texinfo either, but it works.
mandoc looks like a terrible replacement, and I strongly disagree with
your proposal of switching to it.
When comparing the documentation of mandoc/mdoc
http://mandoc.bsd.lv/man/mandoc.1.html
http://mandoc.bsd.lv/mdoc/
to GNUnet or ev
On Fri, Sep 7, 2018 at 4:25 PM Nils Gillmann wrote:
> could you please document 'contrib/guix' somewhere? I will keep using
> my personal modules which were moved around.
The purpose of the directory is already explained in the README file
in the contrib/guix directory. Please let me know if I m
On 08/01/2018 06:23 PM, Nils Gillmann wrote:
> I just responded to an off-list message from Christian with an example of
> someone I study with. I think they are younger than I am, and have some
> but not too much experience with Free Software. Not a complete beginner.
> I had to point them to the
I agree that we should not encourage or endorse using proprietary code
hosting sites such as GitHub. I'm strongly against accepting contributions
on GitHub. Even if the Gentoo project decided to do that, it remains a bad
idea. The furthest we could go is have a read-only mirror with issues, pull
re
On 12/02/2016 09:23 AM, Markus Teich wrote:
> Heyho,
>
> I can't seem to find any macro in the GNUNET_assert/GNUNET_break family which
> allows me to specify the component used for logging (like with
> GNUNET_log_from).
> Is this intentional? Is every component expected to define their own assert
26 matches
Mail list logo
