bug#31366: Missing icons in virt-manager user-interface

[Vagrant Cascadian]

On 2018-05-04, Vagrant Cascadian wrote:
> Many of the icons appear to be missing from the user interface, such as
> the button for "Power on", "Pause the virtual machine", "Shut down the
> virtual machine" and "Show virtual hardware details".
>
> Also, selecting the "Show virtual hardware details" nearly all the icons
> are missing (e.g. "Overview", "Performance",
> "CPUs", "Memory", etc.).

Attached patch that fixes the issue by adding adwaita-icon-theme and
hicolor-icon-theme to propagated-inputs.

live well,
  vagrant

From 82f11703d0c1c45428fd4667b02e23eb714492de Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 27 Aug 2018 22:49:30 +
Subject: [PATCH] gnu: virt-manager: Add missing icon-theme dependencies.

Fixes .

* gnu/packages/virtualization.scm (virt-manager) [propagated-inputs]: Add
  adwaita-icon-theme and hicolor-icon-theme.
---
 gnu/packages/virtualization.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/virtualization.scm b/gnu/packages/virtualization.scm
index 7427465f5..e6948b872 100644
--- a/gnu/packages/virtualization.scm
+++ b/gnu/packages/virtualization.scm
@@ -634,7 +634,9 @@ virtualization library.")
("spice-gtk" ,spice-gtk)))
 ;; virt-manager searches for qemu-img or kvm-img in the PATH.
 (propagated-inputs
- `(("qemu" ,qemu)))
+ `(("adwaita-icon-theme" ,adwaita-icon-theme)
+   ("hicolor-icon-theme" ,hicolor-icon-theme)
+   ("qemu" ,qemu)))
 (native-inputs
  `(("glib" ,glib "bin") ; glib-compile-schemas.
("gtk+" ,gtk+ "bin") ; gtk-update-icon-cache
-- 
2.18.0



signature.asc
Description: PGP signature

bug#32548: Cuirass: Performance monitoring

[Ludovic Courtès]

As discussed earlier today on IRC with Clément, we could add performance
monitoring capabilities to Cuirass.  Interesting metrics would be:

  • time of push to time of evaluation completion;

  • time of evaluation completion to time of build completion.

We could visualize that per job over time.  Perhaps these are also stats
that ‘guix weather’ could display.

Ludo’.

bug#23170: [PATCH shepherd] Restart dependent services on service restart

[Clément Lassieur]

Carlo Zancanaro  writes:

>>Anyway, it all LGTM, thanks!
>
> Pushed! Thanks for the review.
>
> Carlo

Awesome!  Thanks a lot Carlo for working on this :-)

bug#32234: [PATCH 2/2] database: Serialize all database accesses in a thread.

[Clément Lassieur]

Thank you for the explanation Danny.

Indeed I didn't fix what you described.  That could be done easily by
wrapping the handler with WITH-DB-CRITICAL-SECTION.  I'm not sure about
the consequences in terms of performance, given that this will send a
huge function to a channel, and that all the work will be done in the
same thread.  If you think it's worth it, don't hesitate to send a
patch.

Clément

Danny Milosavljevic  writes:

> Hi Clément,
>
> I've read through the patch and it seems to handle the case I mean fine 
> because
> you support an arbitrary number of queries per db critical section - so I 
> agree
> that this patchset is fine.
>
> Keep in mind this is only fine if the critical section is held over an entire 
> http
> request handler and not only over a single database query (as far as I can see
> the former is the case in the patch - OK). 
>
> Much longer explanation follows:
>
> On Mon, 27 Aug 2018 15:18:09 +0200
> Clément Lassieur  wrote:
>
>> Danny Milosavljevic  writes:
>> 
>> > Hi Clément,
>> >
>> > in the future I plan on making the actual bin/evaluate use another 
>> > database connection
>> > in order for the web interface to be isolated while it's querying.  
>> 
>> I don't understand... bin/evaluate doesn't query the database at all.  I
>> don't know why it would need to.
>
> Yeah, it has moved.  Sorry.
>
> But I mean the part that changes the values in the database (on behalf of 
> bin/evaluate).
> So now it's the procedure "evaluate" in src/cuirass/base.scm .
>
>> > Otherwise - as it is now in master - it can happen that while you are 
>> > querying one
>> > page, half of the things have different values than you requested - which 
>> > is really
>> > weird.
>> >
>> > For example right now you could query for a row with status=42 and get 
>> > back data with
>> > status=43 (because it has been changed in the mean time).  
>> 
>> Could you please show an example that I can reproduce?  I don't
>> understand what you mean.
>
> Right now something like this happens (simplified to make it easier to follow 
> - finding
> the problem by debugging the Javascript frontend (wrongly) was much more 
> difficult):
>
> Connection 1:
>
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
>
> Connection 2:
>
> ... Wait some time until the user sends a request...
> Query: SELECT x FROM a
> Result: Nondeterministic number
> Query: SELECT x FROM a
> Result: Nondeterministic possibly different number (WTF!)
>
> This is especially bad if you request extra data from other tables in an extra
> query and the join condition suddenly doesn't match (and thus the row isn't
> returned!).
>
>
> Better would be if it acted like this:
>
> Connection 1:
>
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
> Statement: UPDATE a SET x = x + 1
>
> Connection 2:
>
> ... Wait some time until the user sends a request...
> Statement: BEGIN TRANSACTION
> Statement: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
> Query: SELECT x FROM a
> Result: Some number
> Query: SELECT x FROM a
> Result: The same number
> ... wait however long you want
> Query: SELECT x FROM a
> Result: The same number
> Statement: ROLLBACK TRANSACTION or COMMIT TRANSACTION
>
> loop
>
> Statement: BEGIN TRANSACTION
> Statement: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
> Query: SELECT x FROM a
> Result: Some possibly different number xxx
> Query: SELECT x FROM a
> Result: The same number xxx as in the previous query
> Query: SELECT x FROM a
> Result: The same number xxx as in the previous query
> ...
>
>> With that patch, database queries are serialized, which means that if
>> query1, query2 and query3 are sent in that order, they will be executed
>> in that order, one after the other.
>
> It depends on what exactly that means.  As long as it means that the
> entire HTTP request handler is ONE query that is ordered such, that's fine.
>
> Otherwise not.
>
> If there are more complicated multiple queries done by the web interface
> on behalf of the user because of one HTTP request, we have to make sure
> that those queries execute without any interleaving by some writer.
>
> As a stopgap, this database query serializer should let the user batch
> the queries/statements and run each batch in its own transaction.
> I think that would be quite okay as a solution, actually, as long as
> there are no other shadow clients of the database.
>
>> Currently, there is only one connection 

bug#32234: [PATCH 2/2] database: Serialize all database accesses in a thread.

[Danny Milosavljevic]

Hi Clément,

I've read through the patch and it seems to handle the case I mean fine because
you support an arbitrary number of queries per db critical section - so I agree
that this patchset is fine.

Keep in mind this is only fine if the critical section is held over an entire 
http
request handler and not only over a single database query (as far as I can see
the former is the case in the patch - OK). 

Much longer explanation follows:

On Mon, 27 Aug 2018 15:18:09 +0200
Clément Lassieur  wrote:

> Danny Milosavljevic  writes:
> 
> > Hi Clément,
> >
> > in the future I plan on making the actual bin/evaluate use another database 
> > connection
> > in order for the web interface to be isolated while it's querying.  
> 
> I don't understand... bin/evaluate doesn't query the database at all.  I
> don't know why it would need to.

Yeah, it has moved.  Sorry.

But I mean the part that changes the values in the database (on behalf of 
bin/evaluate).
So now it's the procedure "evaluate" in src/cuirass/base.scm .

> > Otherwise - as it is now in master - it can happen that while you are 
> > querying one
> > page, half of the things have different values than you requested - which 
> > is really
> > weird.
> >
> > For example right now you could query for a row with status=42 and get back 
> > data with
> > status=43 (because it has been changed in the mean time).  
> 
> Could you please show an example that I can reproduce?  I don't
> understand what you mean.

Right now something like this happens (simplified to make it easier to follow - 
finding
the problem by debugging the Javascript frontend (wrongly) was much more 
difficult):

Connection 1:

Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1

Connection 2:

... Wait some time until the user sends a request...
Query: SELECT x FROM a
Result: Nondeterministic number
Query: SELECT x FROM a
Result: Nondeterministic possibly different number (WTF!)

This is especially bad if you request extra data from other tables in an extra
query and the join condition suddenly doesn't match (and thus the row isn't
returned!).


Better would be if it acted like this:

Connection 1:

Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1
Statement: UPDATE a SET x = x + 1

Connection 2:

... Wait some time until the user sends a request...
Statement: BEGIN TRANSACTION
Statement: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
Query: SELECT x FROM a
Result: Some number
Query: SELECT x FROM a
Result: The same number
... wait however long you want
Query: SELECT x FROM a
Result: The same number
Statement: ROLLBACK TRANSACTION or COMMIT TRANSACTION

loop

Statement: BEGIN TRANSACTION
Statement: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
Query: SELECT x FROM a
Result: Some possibly different number xxx
Query: SELECT x FROM a
Result: The same number xxx as in the previous query
Query: SELECT x FROM a
Result: The same number xxx as in the previous query
...

> With that patch, database queries are serialized, which means that if
> query1, query2 and query3 are sent in that order, they will be executed
> in that order, one after the other.

It depends on what exactly that means.  As long as it means that the
entire HTTP request handler is ONE query that is ordered such, that's fine.

Otherwise not.

If there are more complicated multiple queries done by the web interface
on behalf of the user because of one HTTP request, we have to make sure
that those queries execute without any interleaving by some writer.

As a stopgap, this database query serializer should let the user batch
the queries/statements and run each batch in its own transaction.
I think that would be quite okay as a solution, actually, as long as
there are no other shadow clients of the database.

> Currently, there is only one connection that is shared by the writers
> and readers.  Having one 'read connection' and one 'write connection'
> would be possible and make sense if both of them live in a separate
> thread and use the SQLite multithreading feature so that writing and
> reading proceed concurrently.  Is that what you mean?

No.


pgp3wDHPWJPKI.pgp
Description: OpenPGP digital signature

bug#32234: [PATCH 2/2] database: Serialize all database accesses in a thread.

[Clément Lassieur]

Ludovic Courtès  writes:

> Hi Clément,
>
> Clément Lassieur  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Excellent, thanks for working on this!  This looks great to me, and I
>>> think the pros outweigh the cons.  Did you check on a big database how
>>> well it performs?
>>
>> Yes, I didn't see any difference.  When I use Berlin's database, it
>> works well but crashes quickly for another reason (lack of disk space I
>> think, and /tmp being tmpfs).
>
> Sounds good (not that it crashes, but that you didn’t see any
> difference ;-)).
>
>>> I think I find it nicer to keep the ‘db’ parameter everywhere (except
>>> that it’s now a channel instead of an actual database) rather than using
>>> this global variable.
>>>
>>> WDYT?
>>
>> That 'db' parameter made sense before, because there were different
>> database connections: one per fiber.  But now that there is only one
>> global channel accessible from everywhere, I can't find any use for a
>> 'db-channel' parameter.
>>
>> Also, using two differents channels for the same database would be a
>> bug, it would break the serialization mechanism.
>>
>> And I don't think using several databases (with one channel per
>> database) would make sense either.
>
> These are all good points, indeed.  I’m mildly reluctant to the global
> parameter, but if you prefer it that way, I don’t mind; the end result
> matters more than this tiny issue anyway!
>
> So: LGTM.
>
> Thank you!
>
> Ludo’.

Ok, pushed!

bug#32234: [PATCH 2/2] database: Serialize all database accesses in a thread.

[Clément Lassieur]

Hi Danny,

Danny Milosavljevic  writes:

> Hi Clément,
>
> in the future I plan on making the actual bin/evaluate use another database 
> connection
> in order for the web interface to be isolated while it's querying.

I don't understand... bin/evaluate doesn't query the database at all.  I
don't know why it would need to.

> Otherwise - as it is now in master - it can happen that while you are 
> querying one
> page, half of the things have different values than you requested - which is 
> really
> weird.
>
> For example right now you could query for a row with status=42 and get back 
> data with
> status=43 (because it has been changed in the mean time).

Could you please show an example that I can reproduce?  I don't
understand what you mean.

> It's better to have serializable transaction isolation to prevent this.  That 
> means
> that each connection will have its own worldview that is fixed at the 
> beginning of
> the connection's transaction.  The worldview will update only once a new 
> transaction
> starts.

With that patch, database queries are serialized, which means that if
query1, query2 and query3 are sent in that order, they will be executed
in that order, one after the other.  I don't understand why using a
different connection would improve things.

> Therefore, it would be good for writers to have their own connection in the 
> long run
> (really, for the readers to have their own connection - but that comes out 
> the same).

Currently, there is only one connection that is shared by the writers
and readers.  Having one 'read connection' and one 'write connection'
would be possible and make sense if both of them live in a separate
thread and use the SQLite multithreading feature so that writing and
reading proceed concurrently.  Is that what you mean?

Clément

bug#32234: [PATCH 2/2] database: Serialize all database accesses in a thread.

[Danny Milosavljevic]

Hi Clément,

in the future I plan on making the actual bin/evaluate use another database 
connection
in order for the web interface to be isolated while it's querying.

Otherwise - as it is now in master - it can happen that while you are querying 
one
page, half of the things have different values than you requested - which is 
really
weird.

For example right now you could query for a row with status=42 and get back 
data with
status=43 (because it has been changed in the mean time).

It's better to have serializable transaction isolation to prevent this.  That 
means
that each connection will have its own worldview that is fixed at the beginning 
of
the connection's transaction.  The worldview will update only once a new 
transaction
starts.

Therefore, it would be good for writers to have their own connection in the 
long run
(really, for the readers to have their own connection - but that comes out the 
same).

So it would be good to keep this in mind.


pgpFA0Z76YBQ_.pgp
Description: OpenPGP digital signature

bug#23170: [PATCH shepherd] Restart dependent services on service restart

[Carlo Zancanaro]

On Mon, Aug 27 2018, Ludovic Courtès wrote:
I see that you also reverted the patch that removed the 
‘EINTR-safe’ workaround.  Could you explain why that was 
necessary?  (It should not be necessary with current Guile 
versions.)


I'm not really sure of the details, but as I mentioned on IRC, 
that commit stopped me from being able to boot. I grafted a new 
version of the Shepherd and reconfigured my system, and when it 
came up my screen was filled with messages complaining that it 
couldn't create things in /dev because they already existed. I 
tested the commits since the previous release and that was the one 
that caused my problem.


I'd like to investigate further, but I have no idea what could be 
causing it. All I have to go on so far is that I think the udev 
service is getting respawned repeatedly, but I don't know why that 
commit would cause that problem. After reverting that commit I 
could successfully boot back into my system and everything is 
working properly again.


signature.asc
Description: PGP signature

bug#32540: Cuirass: we need a way to manually trigger evaluations

[Clément Lassieur]

Gábor Boskovits  writes:

> Clément Lassieur  ezt írta (időpont: 2018. aug. 27.,
> H, 11:54):
>
>> The 'core-updates' and 'staging' branches shouldn't trigger evaluations
>> at each commit, because they produce too many derivations.  Instead, the
>> admins should have a 'trigger evaluation' button that they use once in a
>> while.  That button should be part of an 'admin interface', which should
>> be protected by NGINX's 'auth_basic' authentication mechanism.
>>
>>
> I agree that we need a mechanism like this. I am not sure about what the
> protection
> mechanism should be. 'auth_basic' has some appeal, as it is quite easy, but
> I would
> like to hear some more opinions about that part.

It's obviously not ideal, and we can implement something more
sophisticated later.

bug#23170: [PATCH shepherd] Restart dependent services on service restart

[Ludovic Courtès]

Hi,

Carlo Zancanaro  skribis:

> Pushed! Thanks for the review.

Great!

I see that you also reverted the patch that removed the ‘EINTR-safe’
workaround.  Could you explain why that was necessary?  (It should not
be necessary with current Guile versions.)

Thank you,
Ludo’.

bug#32540: Cuirass: we need a way to manually trigger evaluations

[Gábor Boskovits]

Clément Lassieur  ezt írta (időpont: 2018. aug. 27.,
H, 11:54):

> The 'core-updates' and 'staging' branches shouldn't trigger evaluations
> at each commit, because they produce too many derivations.  Instead, the
> admins should have a 'trigger evaluation' button that they use once in a
> while.  That button should be part of an 'admin interface', which should
> be protected by NGINX's 'auth_basic' authentication mechanism.
>
>
> I agree that we need a mechanism like this. I am not sure about what the
protection
mechanism should be. 'auth_basic' has some appeal, as it is quite easy, but
I would
like to hear some more opinions about that part.

bug#32540: Cuirass: we need a way to manually trigger evaluations

[Clément Lassieur]

The 'core-updates' and 'staging' branches shouldn't trigger evaluations
at each commit, because they produce too many derivations.  Instead, the
admins should have a 'trigger evaluation' button that they use once in a
while.  That button should be part of an 'admin interface', which should
be protected by NGINX's 'auth_basic' authentication mechanism.

bug#32539: Cuirass: a commit that updates doc will produce 86 tests

[Clément Lassieur]

Evaluation 338[1] is triggered by commit 1d8d69c[2], which only updates
the documentation.  This evaluation produces 86 useless tests:
test.mcron.i686-linux, test.opensmtpd.i686-linux, etc.  I believe those
tests are triggered at each evaluation (almost), and it's a considerable
waste of resources.

[1]: https://berlin.guixsd.org/eval/338
[2]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1d8d69c863ae88d5fc20e52e49a22f68c531c1db