> On 10. Feb 2019, at 22:28, Christian Grothoff wrote:
>
> Signed PGP part
> On 2/10/19 9:25 PM, Hartmut Goebel wrote:
>> Am 10.02.19 um 17:43 schrieb Christian Grothoff:
>>
>> IMHO gnunet should be split into repos like this:
>>
>> - framework ("core")
>
> Should framework include the
so
I'm building gnunet-gtk with Gnutls 3.6.5
I built this Gnuutls myself and I selected it with
--with-gnutls=$HOME/opt
In the config.log there are these 2 lines:
configure:16404: checking for gnutls
configure:16409: result: /home/catonano/opt
And yet, when I run make, I get
In file
On 2/10/19 10:57 PM, Hartmut Goebel wrote:
> Am 10.02.19 um 22:28 schrieb Christian Grothoff:
>>> - framework ("core")
>> Should framework include the gnunet-gtk-common, causing GNUnet to drag
>> in Gtk+ (that's a bit along my question of merging gnunet-gtk.git with
>> gnunet.git, which few people
Am 10.02.19 um 22:28 schrieb Christian Grothoff:
>> - framework ("core")
> Should framework include the gnunet-gtk-common, causing GNUnet to drag
> in Gtk+ (that's a bit along my question of merging gnunet-gtk.git with
> gnunet.git, which few people seemed to like)? Should framework include
>
On 2/10/19 9:25 PM, Hartmut Goebel wrote:
> Am 10.02.19 um 17:43 schrieb Christian Grothoff:
>
> IMHO gnunet should be split into repos like this:
>
> - framework ("core")
Should framework include the gnunet-gtk-common, causing GNUnet to drag
in Gtk+ (that's a bit along my question of merging
Am 10.02.19 um 17:43 schrieb Christian Grothoff:
IMHO gnunet should be split into repos like this:
- framework ("core")
- applications
- file sharing
- conversation
- reclaim
- secushare
I would expect every developer working on one of the applications to
understand he/she needs
Schanzenbach, Martin transcribed 5.2K bytes:
> I propose we just add a couple of configure switches, you know --build-deb
> (if course one for each deb-based distro), --build-rpm etc... you know, to
> "reduce" complexity.
> Of course, in addition to the --disable-gtk/--disable- switches
> which
Schanzenbach, Martin transcribed 5.2K bytes:
> I propose we just add a couple of configure switches, you know --build-deb
> (if course one for each deb-based distro), --build-rpm etc... you know, to
> "reduce" complexity.
Before I read a concrete proposal in code I will just say No to the part
On 2/10/19 4:41 PM, Schanzenbach, Martin wrote:
>> No, that's horrible. The main release should be a source release,
>> packaging into particular containers, VMs or operating systems
>> should never be the _primary_ release mechanism. That's almost
>> worse than the idea of us primarily offering
Schanzenbach, Martin transcribed 9.7K bytes:
>
>
> > On 10. Feb 2019, at 13:56, Christian Grothoff wrote:
> >
> > On 2/10/19 11:59 AM, Schanzenbach, Martin wrote:
> >>> --disable-FEATURE flats for configure where then src/Makefile.am simply
> >>> doesn't enter certain subdirectories would
Christian Grothoff transcribed 4.7K bytes:
> On 2/10/19 2:11 PM, n...@n0.is wrote:
> > *We* have define what it should look like. *We* have to set the
> > expected results. *We* have to say, this is how gnunet should
> > look like. Every deriviation from what we say in the official
> >
> On 10. Feb 2019, at 13:56, Christian Grothoff wrote:
>
> On 2/10/19 11:59 AM, Schanzenbach, Martin wrote:
>>> --disable-FEATURE flats for configure where then src/Makefile.am simply
>>> doesn't enter certain subdirectories would certainly have my approval here.
>>
>> See above, yay more
Which version of GnuTLS are you using? It is likely too old.
Happy hacking!
Christian
On 2/10/19 11:59 AM, Catonano wrote:
> Build fails
>
> I checked it out this morning and this is make:
>
> ...
> In file included from plugin_gtk_namestore_box.c:62:0:
> plugin_gtk_namestore_tlsa.c: In
On 2/10/19 2:11 PM, n...@n0.is wrote:
> *We* have define what it should look like. *We* have to set the
> expected results. *We* have to say, this is how gnunet should
> look like. Every deriviation from what we say in the official
> installation methods is without warranty. Every good packaging
>
Catonano transcribed 1.7K bytes:
> Il giorno dom 10 feb 2019 alle ore 12:41 ha scritto:
>
> > iirc we have instructions for building gnunet-gtk.
> > If not, this is a bug you should report (even if you
> > did not find them at first!).
> >
> > have you looked at the guix package for gnunet-gtk
Christian Grothoff transcribed 9.0K bytes:
> On 2/10/19 11:59 AM, Schanzenbach, Martin wrote:
> >> --disable-FEATURE flats for configure where then src/Makefile.am simply
> >> doesn't enter certain subdirectories would certainly have my approval here.
> >
> > See above, yay more flags. But this
On 2/10/19 11:59 AM, Schanzenbach, Martin wrote:
>> --disable-FEATURE flats for configure where then src/Makefile.am simply
>> doesn't enter certain subdirectories would certainly have my approval here.
>
> See above, yay more flags. But this is actually a problem I have not thought
> through
Il giorno dom 10 feb 2019 alle ore 12:41 ha scritto:
> iirc we have instructions for building gnunet-gtk.
> If not, this is a bug you should report (even if you
> did not find them at first!).
>
> have you looked at the guix package for gnunet-gtk to
> compare what I have done there?
>
I
> On 10. Feb 2019, at 11:59, Schanzenbach, Martin
> wrote:
>
> Signed PGP part
>
>
>> On 10. Feb 2019, at 11:14, Christian Grothoff wrote:
>>
>> Signed PGP part
>> On 2/10/19 10:06 AM, Schanzenbach, Martin wrote:
>>> Maybe let me wrap this up for now because I do not see a point in
iirc we have instructions for building gnunet-gtk.
If not, this is a bug you should report (even if you
did not find them at first!).
have you looked at the guix package for gnunet-gtk to
compare what I have done there?
Catonano transcribed 3.1K bytes:
> Build fails
>
> I checked it out this
> On 10. Feb 2019, at 11:14, Christian Grothoff wrote:
>
> Signed PGP part
> On 2/10/19 10:06 AM, Schanzenbach, Martin wrote:
>> Maybe let me wrap this up for now because I do not see a point in arguing
>> further and there does not seem to be consensus:
>>
>> From a GNUnet app/service
Build fails
I checked it out this morning and this is make:
...
In file included from plugin_gtk_namestore_box.c:62:0:
plugin_gtk_namestore_tlsa.c: In function ‘import_address_cb’:
plugin_gtk_namestore_tlsa.c:964:10: error: ‘GNUTLS_CRT_RAW’ undeclared
(first use in this function); did you mean
On 2/10/19 10:06 AM, Schanzenbach, Martin wrote:
> Maybe let me wrap this up for now because I do not see a point in arguing
> further and there does not seem to be consensus:
>
> From a GNUnet app/service developer perspective (i.e. not GNUnet core
> services) I have made the experience that
My point was that they do it by having a stable API/ABI across major versions.
But they do not check our builds and do not modify our code if they change
major versions.
We have to do that ourselves.
> On 10. Feb 2019, at 11:03, Christian Grothoff wrote:
>
> Signed PGP part
> On 2/10/19 10:50
On 2/10/19 10:50 AM, Schanzenbach, Martin wrote:
> That is also the point. They should not care. Do you really think
> Gtk+ devs care if they break API/ABI and gnunet-gtk fails to build?
Yes, they do, and they should.
signature.asc
Description: OpenPGP digital signature
> On 10. Feb 2019, at 10:36, Florian Dold wrote:
>
> 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,
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
>
https://packages.ubuntu.com/bionic/libgtk-3-dev ?
> On 10. Feb 2019, at 09:54, Catonano wrote:
>
>
>
> Il giorno dom 10 feb 2019 alle ore 09:52 Catonano ha
> scritto:
>
>
> Il giorno dom 10 feb 2019 alle ore 09:27 Schanzenbach, Martin
> ha scritto:
> The gnunet-gtk are and have always
Maybe let me wrap this up for now because I do not see a point in arguing
further and there does not seem to be consensus:
From a GNUnet app/service developer perspective (i.e. not GNUnet core services)
I have made the experience that the use of proper tooling and separation
benefits the
Il giorno dom 10 feb 2019 alle ore 09:27 Schanzenbach, Martin <
mschanzenb...@posteo.de> ha scritto:
> The gnunet-gtk are and have always been a mess.
> But let me try:
>
> do you have gtk+-3.0-dev installed? (next up will probably be glade2 or
> sth)
>
I can find a
libgtk-3-0
package, but not
The gnunet-gtk are and have always been a mess.
But let me try:
do you have gtk+-3.0-dev installed? (next up will probably be glade2 or sth)
> On 10. Feb 2019, at 09:21, Catonano wrote:
>
>
>
> Il giorno dom 10 feb 2019 alle ore 08:36 Schanzenbach, Martin
> ha scritto:
> The Gtk ui is in a
> On 10. Feb 2019, at 08:46, Florian Dold wrote:
>
> 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
Il giorno dom 10 feb 2019 alle ore 08:36 Schanzenbach, Martin <
mschanzenb...@posteo.de> ha scritto:
> The Gtk ui is in a separate repository:
> https://gnunet.org/git/gnunet-gtk.git
>
> > On
>
Thank you Martin
In configuring I get this
...
checking for gtk... checking for pkg-config...
33 matches
Mail list logo
