diff mbox

gnunet-svn, gnunet-gtk-svn

Message ID 87lh0jf9fa.fsf@we.make.ritual.n0.is
State New
Headers show

Commit Message

non such July 30, 2016, 3:11 p.m. UTC
This is functional, but it suffers the same bug as the gnunet-0.10.1
package. I will write a gnunet-service for guix which will fix all
versions.
The expected behavior for installing gnunet is: create gnunet user with
gnunet group, create gnunet-dns group, build, install, configure through
gnunet-setup -c /path/to/gnunet.conf or setup without graphical tools,
add regular user to gnunet group, run gnunet stuff with regular user.

You will experience the same stability with this svn as with 0.10.1 but
it will have the same broken behavior until I have fixed it.
Thanks for reviewing.

Comments

non such July 30, 2016, 3:41 p.m. UTC | #1
ng0 <ng0@we.make.ritual.n0.is> writes:

> This is functional, but it suffers the same bug as the gnunet-0.10.1
> package. I will write a gnunet-service for guix which will fix all
> versions.
> The expected behavior for installing gnunet is: create gnunet user with
> gnunet group, create gnunet-dns group, build, install, configure through
> gnunet-setup -c /path/to/gnunet.conf or setup without graphical tools,
> add regular user to gnunet group, run gnunet stuff with regular user.
>
> You will experience the same stability with this svn as with 0.10.1 but
> it will have the same broken behavior until I have fixed it.

I am running a `gnunet-search avi' now to see how badly it needs to be
fixed, but writing the service is in my own interest, so this will
happen as the next contribution.
non such July 30, 2016, 3:56 p.m. UTC | #2
ng0 <ng0@we.make.ritual.n0.is> writes:

> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>> This is functional, but it suffers the same bug as the gnunet-0.10.1
>> package. I will write a gnunet-service for guix which will fix all
>> versions.
>> The expected behavior for installing gnunet is: create gnunet user with
>> gnunet group, create gnunet-dns group, build, install, configure through
>> gnunet-setup -c /path/to/gnunet.conf or setup without graphical tools,
>> add regular user to gnunet group, run gnunet stuff with regular user.
>>
>> You will experience the same stability with this svn as with 0.10.1 but
>> it will have the same broken behavior until I have fixed it.
>
> I am running a `gnunet-search avi' now to see how badly it needs to be
> fixed, but writing the service is in my own interest, so this will
> happen as the next contribution.

It is functional on that level, results come in after a while.
Whoever reviews, run this[0] instead and wait long enough. Maybe you even
need to run gnunet-setup before, adding the service would fix this a
bit.

[0]: `gnunet-search -V avi'


Off I go to openrc + guix service writing/debugging :)
non such July 31, 2016, 1:08 p.m. UTC | #3
ng0 <ng0@we.make.ritual.n0.is> writes:

> This is functional, but it suffers the same bug as the gnunet-0.10.1
> package. I will write a gnunet-service for guix which will fix all
> versions.
> The expected behavior for installing gnunet is: create gnunet user with
> gnunet group, create gnunet-dns group, build, install, configure through
> gnunet-setup -c /path/to/gnunet.conf or setup without graphical tools,
> add regular user to gnunet group, run gnunet stuff with regular user.
>
> You will experience the same stability with this svn as with 0.10.1 but
> it will have the same broken behavior until I have fixed it.
>
> +      (arguments
> +       '(#:configure-flags
> +         (list (string-append "--with-nssdir=" %output "/lib"))
> +         #:parallel-tests? #f ; parallel building is not functional
> +         #:tests? #f ; FAIL: test_testbed_logger_api

Comment in the previous patch I received:

> > Okay, is it easy to disable just the failing test? Also, can you
 > > include a link to the upstream bug report in this comment?

This was another failing test, someone before me reported it and
therefore I have no bugreport to point to. I consider it superfluous
work to fix 0.10.1 (the (define-public gnunet)) now that work towards
0.10.2 release happens. Tests might or might not change, so the svn
version is more logical to fix and report bugs on.

The failing more current test will be reported as soon as I have time
for it.
non such Aug. 1, 2016, 2:34 p.m. UTC | #4
ng0 <ng0@we.make.ritual.n0.is> writes:

> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>> This is functional, but it suffers the same bug as the gnunet-0.10.1
>> package. I will write a gnunet-service for guix which will fix all
>> versions.
>> The expected behavior for installing gnunet is: create gnunet user with
>> gnunet group, create gnunet-dns group, build, install, configure through
>> gnunet-setup -c /path/to/gnunet.conf or setup without graphical tools,
>> add regular user to gnunet group, run gnunet stuff with regular user.
>>
>> You will experience the same stability with this svn as with 0.10.1 but
>> it will have the same broken behavior until I have fixed it.
>>
>> +      (arguments
>> +       '(#:configure-flags
>> +         (list (string-append "--with-nssdir=" %output "/lib"))
>> +         #:parallel-tests? #f ; parallel building is not functional
>> +         #:tests? #f ; FAIL: test_testbed_logger_api
>
> Comment in the previous patch I received:
>
>> > Okay, is it easy to disable just the failing test? Also, can you
>  > > include a link to the upstream bug report in this comment?
>
> This was another failing test, someone before me reported it and
> therefore I have no bugreport to point to. I consider it superfluous
> work to fix 0.10.1 (the (define-public gnunet)) now that work towards
> 0.10.2 release happens. Tests might or might not change, so the svn
> version is more logical to fix and report bugs on.
>
> The failing more current test will be reported as soon as I have time
> for it.

"The refactoring of the gnunet code is going on like a thunderstorm."
Work towards 0.10.2 release - so maybe the failing test will just be
resolved with the next version release.
Catonano Aug. 1, 2016, 7:01 p.m. UTC | #5
2016-08-01 16:34 GMT+02:00 ng0 <ng0@we.make.ritual.n0.is>:



> "The refactoring of the gnunet code is going on like a thunderstorm."
>

I can't see this sentence in the gnunet irc log, neither on the mailing
list archive

Where did you get it ?
non such Aug. 1, 2016, 7:42 p.m. UTC | #6
Catonano <catonano@gmail.com> writes:

> 2016-08-01 16:34 GMT+02:00 ng0 <ng0@we.make.ritual.n0.is>:
>
>
>
>> "The refactoring of the gnunet code is going on like a thunderstorm."
>>
>
> I can't see this sentence in the gnunet irc log, neither on the mailing
> list archive
>
> Where did you get it ?

Somewhere else, just a comment which I see fitting for the
development. Point is that they are working hard on making 0.10.2
happening, maybe even at the end of the summer.
Andreas Enge Aug. 1, 2016, 10:21 p.m. UTC | #7
On Sun, Jul 31, 2016 at 01:08:54PM +0000, ng0 wrote:
> This was another failing test, someone before me reported it and
> therefore I have no bugreport to point to. I consider it superfluous
> work to fix 0.10.1 (the (define-public gnunet)) now that work towards
> 0.10.2 release happens. Tests might or might not change, so the svn
> version is more logical to fix and report bugs on.

So maybe it may make sense to wait for 0.10.2 instead of adding packages
based on unreleased commits? In the meantime, you could work with upstream
to iron out test failures, and when 0.10.2 comes out, you might have a
working gnunet package.

Andreas
non such Aug. 2, 2016, 8:27 a.m. UTC | #8
Andreas Enge <andreas@enge.fr> writes:

> On Sun, Jul 31, 2016 at 01:08:54PM +0000, ng0 wrote:
>> This was another failing test, someone before me reported it and
>> therefore I have no bugreport to point to. I consider it superfluous
>> work to fix 0.10.1 (the (define-public gnunet)) now that work towards
>> 0.10.2 release happens. Tests might or might not change, so the svn
>> version is more logical to fix and report bugs on.
>
> So maybe it may make sense to wait for 0.10.2 instead of adding packages
> based on unreleased commits? In the meantime, you could work with upstream
> to iron out test failures, and when 0.10.2 comes out, you might have a
> working gnunet package.
>
> Andreas

The reason for packaging -svn was to offer an regulary checked and
updated svn revision of gnunet. I don't know much about what the 0.10.2
release will mean, certainly it will mean the API compability is fixed
for those who update to 0.10.2.
It can be the end of the summer, it can be the end of the year. the
targeted date was 2016-07-01. They are working quick, but I don't know
what needs to be fixed etc. My contribution so far is just
gnunet-gtk.desktop, something I feel like it's safe enough but
necessary.

If we had just 0.10.2, it would rule out one problem of my bigger
roadmap. But people who would want to develop for it and use Guix at the
same time, would want svn. Normaly HEAD isn't broken, it's as good as a
release if they would  not change this much at the moment. 

Should I provide -svn outside of Guix master?

Should the -svn I provided just become a base for 0.10.2, waiting for
release? The idea was a different one.. like guile and guile-next, 2
releases, however I have to pin to a number for the reasons explained
above.


Based on this, could you still review it so independent from the
decision I can have apply changes?
If the decision is that having 2 versions and one working as the -svn I
described above is not okay at the present moment, I will just start
working on the gnunet-service.


Thanks,
non such Aug. 2, 2016, 10:30 a.m. UTC | #9
ng0 <ng0@we.make.ritual.n0.is> writes:

> Andreas Enge <andreas@enge.fr> writes:
>
>> On Sun, Jul 31, 2016 at 01:08:54PM +0000, ng0 wrote:
>>> This was another failing test, someone before me reported it and
>>> therefore I have no bugreport to point to. I consider it superfluous
>>> work to fix 0.10.1 (the (define-public gnunet)) now that work towards
>>> 0.10.2 release happens. Tests might or might not change, so the svn
>>> version is more logical to fix and report bugs on.
>>
>> So maybe it may make sense to wait for 0.10.2 instead of adding packages
>> based on unreleased commits? In the meantime, you could work with upstream
>> to iron out test failures, and when 0.10.2 comes out, you might have a
>> working gnunet package.
>>
>> Andreas
>
> The reason for packaging -svn was to offer an regulary checked and
> updated svn revision of gnunet. I don't know much about what the 0.10.2
> release will mean, certainly it will mean the API compability is fixed
> for those who update to 0.10.2.
> It can be the end of the summer, it can be the end of the year. the
> targeted date was 2016-07-01. They are working quick, but I don't know
> what needs to be fixed etc. My contribution so far is just
> gnunet-gtk.desktop, something I feel like it's safe enough but
> necessary.
>
> If we had just 0.10.2, it would rule out one problem of my bigger
> roadmap. But people who would want to develop for it and use Guix at the
> same time, would want svn. Normaly HEAD isn't broken, it's as good as a
> release if they would  not change this much at the moment. 
>
> Should I provide -svn outside of Guix master?
>
> Should the -svn I provided just become a base for 0.10.2, waiting for
> release? The idea was a different one.. like guile and guile-next, 2
> releases, however I have to pin to a number for the reasons explained
> above.
>
>
> Based on this, could you still review it so independent from the
> decision I can have apply changes?
> If the decision is that having 2 versions and one working as the -svn I
> described above is not okay at the present moment, I will just start
> working on the gnunet-service.

Development is a bad example, but for the current state, not considering
"0.10.2 will be out soon", the existence of -svn on a system was more
than just for development.
When you read the old threads you can see that release
tarballs are just svn revisions with no additional changes.

With this recent change, maybe out-of-tree is a better place.

Fyi, I tried with most recent head and tests no longer fail it seems.
Catonano Aug. 2, 2016, 1:05 p.m. UTC | #10
2016-08-02 12:30 GMT+02:00 ng0 <ng0@we.make.ritual.n0.is>:

>
> Development is a bad example, but for the current state, not considering
> "0.10.2 will be out soon", the existence of -svn on a system was more
> than just for development.
>

In fact, for what it matters, I'd like to be able to play with Gnunet.

Installing a development version on my own is too difficult for me, having
it in Guix would be a boon



> When you read the old threads you can see that release
> tarballs are just svn revisions with no additional changes.
>
> With this recent change, maybe out-of-tree is a better place.
>

Which recent change ? What does "out-of-tree" exactly mean ?


>
> Fyi, I tried with most recent head and tests no longer fail it seems.
>

This is one more reason to provide a package from a checkout.
non such Aug. 2, 2016, 2:09 p.m. UTC | #11
Catonano <catonano@gmail.com> writes:

> 2016-08-02 12:30 GMT+02:00 ng0 <ng0@we.make.ritual.n0.is>:
>
>>
>> Development is a bad example, but for the current state, not considering
>> "0.10.2 will be out soon", the existence of -svn on a system was more
>> than just for development.
>>
>
> In fact, for what it matters, I'd like to be able to play with Gnunet.
>
> Installing a development version on my own is too difficult for me, having
> it in Guix would be a boon
>
>
>
>> When you read the old threads you can see that release
>> tarballs are just svn revisions with no additional changes.
>>
>> With this recent change, maybe out-of-tree is a better place.
>>
>
> Which recent change ? What does "out-of-tree" exactly mean ?

Recent change -> 0.10.2 will be out soon™.


For the collaborative Gentoo overlay I share work with, many packages
I contributed either originate there or got their first year of practice
and debugging there and when I started to contribute to Guix, they
started moving into Guix master.
However we have some packages which can not make it into guix master in
their (current) form (one example: powwow. unaltered it came into Guix,
but we still patch it for Gentoo. Best case scenario would be to patch
it upstream). I am testing for the best way to transition the packages
which do not fit into Guix master to a form which does not depend on
maintaining another Guix checkout (too many wip packages on my side, and
it must mean low maintenance costs).

This is what I mean with out-of-tree.

>
>>
>> Fyi, I tried with most recent head and tests no longer fail it seems.
>>
>
> This is one more reason to provide a package from a checkout.

Maybe, maybe not. I'll see that I append a revision-less patch later
today. Builds does not always mean "runs".

And it still requires (for GuixSD) the service for best experience. I'm
slow with that.
Catonano Aug. 2, 2016, 2:57 p.m. UTC | #12
2016-08-02 16:09 GMT+02:00 ng0 <ng0@we.make.ritual.n0.is>:

>
> Recent change -> 0.10.2 will be out soon™.
>
>
> For the collaborative Gentoo overlay I share work with, many packages
> I contributed either originate there or got their first year of practice
> and debugging there and when I started to contribute to Guix, they
> started moving into Guix master.
> However we have some packages which can not make it into guix master in
> their (current) form (one example: powwow. unaltered it came into Guix,
> but we still patch it for Gentoo. Best case scenario would be to patch
> it upstream). I am testing for the best way to transition the packages
> which do not fit into Guix master to a form which does not depend on
> maintaining another Guix checkout (too many wip packages on my side, and
> it must mean low maintenance costs).
>
> This is what I mean with out-of-tree.
>

Thanks for your clarifications.

Why don't these packages fit into Guix master ?

Could you provide a list of these packages ?

Someone could take the initiative to try to work on one of those and you
could be lifted from the brunt

Just maybe.
non such Aug. 2, 2016, 3:31 p.m. UTC | #13
Catonano <catonano@gmail.com> writes:

> 2016-08-02 16:09 GMT+02:00 ng0 <ng0@we.make.ritual.n0.is>:
>
>>
>> Recent change -> 0.10.2 will be out soon™.
>>
>>
>> For the collaborative Gentoo overlay I share work with, many packages
>> I contributed either originate there or got their first year of practice
>> and debugging there and when I started to contribute to Guix, they
>> started moving into Guix master.
>> However we have some packages which can not make it into guix master in
>> their (current) form (one example: powwow. unaltered it came into Guix,
>> but we still patch it for Gentoo. Best case scenario would be to patch
>> it upstream). I am testing for the best way to transition the packages
>> which do not fit into Guix master to a form which does not depend on
>> maintaining another Guix checkout (too many wip packages on my side, and
>> it must mean low maintenance costs).
>>
>> This is what I mean with out-of-tree.
>>
>
> Thanks for your clarifications.
>
> Why don't these packages fit into Guix master ?
>
> Could you provide a list of these packages ?
>
> Someone could take the initiative to try to work on one of those and you
> could be lifted from the brunt
>
> Just maybe.

I have around 30-60 packages work in progress, not all from the
overlay.
You can take a look at https://we.make.ritual.n0.is/#overlays for ways
to display the whole content of the Gentoo specific overlay.

So far the only limitation is either specific changes which are not yet
in upstream or we package all dependencies even if it is in one case
shareware as a dependency, etc etc. Some are just waiting for a bugfix
upstream - I identified 2 bugs in torsocks and 1 in perl, at least one
torsocks and the one perl bug will be fixed in the next releases or once
they are downstreamed.

I have a no longer up-to-date todo list which also includes guix in the
"todo.git" repository.
non such Aug. 3, 2016, 11:45 a.m. UTC | #14
I think the costs of maintaining a -svn of gnunet are too high at the
moment. I'm using these two packages as a base for debugging gnunet in
addition to gentoo to help work with upstream.

A revision-less svn package does not work (unlike in gentoo), so my
focus is at the moment to help to push towards 0.10.2 release.

Afterwards I can decide wether to include it or not, and dicuss this
with the proper attention.
If anyone else wants to contribute to this discussion you are invited
to do so.
Catonano Aug. 3, 2016, 12:05 p.m. UTC | #15
2016-08-03 13:45 GMT+02:00 ng0 <ng0@we.make.ritual.n0.is>:

> I think the costs of maintaining a -svn of gnunet are too high at the
> moment. I'm using these two packages as a base for debugging gnunet in
> addition to gentoo to help work with upstream.
>
> A revision-less svn package does not work (unlike in gentoo), so my
> focus is at the moment to help to push towards 0.10.2 release.
>
> Afterwards I can decide wether to include it or not, and dicuss this
> with the proper attention.
> If anyone else wants to contribute to this discussion you are invited
> to do so.
>

Thank you, ng0, I will try to contribute to this discussion.

Too bad, until now I had no enough time to look at the link you provided
and I'm afraid I won't have time this week.

But the availability of Gnunet is important for me so I will be back on
this.
Andreas Enge Aug. 3, 2016, 9:10 p.m. UTC | #16
Hello,

On Wed, Aug 03, 2016 at 11:45:56AM +0000, ng0 wrote:
> I think the costs of maintaining a -svn of gnunet are too high at the
> moment. I'm using these two packages as a base for debugging gnunet in
> addition to gentoo to help work with upstream.
> 
> A revision-less svn package does not work (unlike in gentoo), so my
> focus is at the moment to help to push towards 0.10.2 release.

that sounds like a good option, to make sure that the 0.10.2 release will
work on Guix, and hopefully pass all its tests.

Thanks for the work!

Andreas
non such Aug. 6, 2016, 12:54 p.m. UTC | #17
Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> On Wed, Aug 03, 2016 at 11:45:56AM +0000, ng0 wrote:
>> I think the costs of maintaining a -svn of gnunet are too high at the
>> moment. I'm using these two packages as a base for debugging gnunet in
>> addition to gentoo to help work with upstream.
>> 
>> A revision-less svn package does not work (unlike in gentoo), so my
>> focus is at the moment to help to push towards 0.10.2 release.
>
> that sounds like a good option, to make sure that the 0.10.2 release will
> work on Guix, and hopefully pass all its tests.
>
> Thanks for the work!
>
> Andreas
>

Update: I think I have found what causes the problem, I'll post an
updated patch soon.
diff mbox

Patch

From 756e355a24b508ff5434e34002545c994a18df3a Mon Sep 17 00:00:00 2001
From: ng0 <ng0@we.make.ritual.n0.is>
Date: Sat, 30 Jul 2016 15:04:24 +0000
Subject: [PATCH 2/2] gnu: Add gnunet-gtk-svn.

* gnu/packages/gnunet.scm (gnunet-gtk-svn): New variable.
---
 gnu/packages/gnunet.scm | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index 25ac073..a3f34ea 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -412,3 +412,50 @@  an application for secure publication of files, it has grown to include all
 kinds of basic applications for the foundation of a GNU internet.")
       (license license:gpl3+)
       (home-page "https://gnunet.org/"))))
+
+(define-public gnunet-gtk-svn
+  (let ((svn-revision 37273))
+    (package
+      (inherit gnunet-svn)
+      (name "gnunet-gtk-svn")
+      (version (package-version gnunet-svn))
+      (source
+       (origin
+         (method svn-fetch)
+         (uri (svn-reference
+               (url "https://gnunet.org/svn/gnunet-gtk/")
+               (revision svn-revision)))
+         (file-name (string-append name "-" version "-checkout"))
+         (sha256
+          (base32
+           "1mckc5aq05wpbvb8mbm0llkhavb0j2f496l73zaapdy3ndyhai8j"))))
+      (arguments
+       `(#:configure-flags
+         (list "--without-libunique"
+               "--with-qrencode"
+               (string-append "--with-gnunet="
+                              (assoc-ref %build-inputs "gnunet-svn")))
+         #:phases
+         (modify-phases %standard-phases
+           (add-before 'configure 'bootstrap
+             (lambda _
+               (zero? (system* "autoreconf" "-vfi")))))))
+      (inputs
+       `(("gnunet-svn" ,gnunet-svn)
+         ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
+         ("gnutls" ,gnutls)
+         ("libgcrypt" ,libgcrypt)
+         ("gtk+" ,gtk+)
+         ("libextractor" ,libextractor)
+         ("glade3" ,glade3)
+         ("qrencode" ,qrencode)))
+      (native-inputs
+       `(("pkg-config" ,pkg-config)
+         ("libglade" ,libglade)
+         ("autoconf" ,autoconf)
+         ("gnu-gettext" ,gnu-gettext)
+         ("automake" ,automake)
+         ("libtool" ,libtool)))
+      (synopsis "Graphical front-end tools for GNUnet")
+      (home-page "https://gnunet.org"))))
+
-- 
2.9.2