bug#36634: Virtual Machine Manager (virt-manager)

[Raghav Gururajan]

> Checking my machine:
> $ ls /sys/fs/cgroup/unified/
> cgroup.controllers  cgroup.max.depth  cgroup.max.descendants  cgroup.
> procs  cgroup.stat  cgroup.subtree_control  cgroup.threads

I get the same output for `ls /sys/fs/cgroup/unified/`. But as shown in
the error, the virt-manager is searching the directory
"/sys/fs/cgroup/unified/machine" (not "/sys/fs/cgroup/unified/"), which
does not exist. o.O

Regards,
RG.

bug#35521: Mariadb test suite failures on x86_64-linux

[Marius Bakke]

Mark H Weaver  writes:

> Hi Marius,
>
> Marius wrote:
>> There has been some activity around TokuDB in later versions of MariaDB,
>> maybe we can enable it again with 10.4.  For now, I think we should just
>> disable it.
>
> Disabling TokuDB for now sounds like a fine option.
> Thanks very much for looking into it.

Done in bba7a77ed9ad826bcdc6d9b8a183d66a23229501.

Thanks for reporting the issue.

Thinking forward, to trim the mariadb package, maybe it's possible to
build all plugins as separate derivations, and let the user choose a
union when setting up the service.


signature.asc
Description: PGP signature

bug#36636: Tell users to update/reconfigure regularly

[Jesse Gibbons]

On Sun, 14 Jul 2019 18:36:45 +0200
"pelzflorian (Florian Pelz)"  wrote:

> Yes, you are right that unattended upgrades are a more responsible
> default than a notification cron job.  Unattended upgrades would
> resolve this issue.  Should an unattended upgrades service be added to
> Guix’ list of longer-term todos and this bug be closed?
> 
> Regards,
> Florian
> 
> 
> 

How often would the job be run by default? Daily? Weekly? I presume it
would be configurable to run more or less often.

bug#35521: Mariadb test suite failures on x86_64-linux

[Mark H Weaver]

Hi Marius,

Marius wrote:
> There has been some activity around TokuDB in later versions of MariaDB,
> maybe we can enable it again with 10.4.  For now, I think we should just
> disable it.

Disabling TokuDB for now sounds like a fine option.
Thanks very much for looking into it.

  Mark

bug#35521: Mariadb test suite failures on x86_64-linux

[Marius Bakke]

Mark H Weaver  writes:

> Hello again,
>
>> Could it be that you don't have enough disk space for this test?  Do you
>> have the log file available still?
>
> I made another build attempt on my X200, this time logging the output of
> "df --si" every 10 seconds.  The free space started at ~11 GB free and
> never went below 7 GB, but the 'tokudb_bugs.mdev4533' test failed as
> before: "No space left on device" while trying to create the 'test'
> table.

Thanks for testing.  Out of curiousity I tried to enable TokuDB on my
server:

MariaDB [(none)]> INSTALL PLUGIN tokudb SONAME 'ha_tokudb';
ERROR 2006 (HY000): MySQL server has gone away

Ouch.

Unfortunately the Guix service does not seem to enable any kind of
logging, so I haven't dug further.  Loading other plugins seems to work
though.

I am currently trying this patch on Berlin:

diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index 6bfeaad9a2..c17031bb2c 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -659,6 +659,10 @@ Language.")
  ;; For now, disable the features that that use libarchive (xtrabackup).
  "-DWITH_LIBARCHIVE=OFF"
 
+ ;; FIXME: Disable the TokuDB engine, because its test suite frequently
+ ;; fails, and loading it crashes the server: .
+ "-DTOKUDB_OK=OFF"
+
  ;; Ensure the system libraries are used.
  "-DWITH_JEMALLOC=yes"
  "-DWITH_PCRE=system"
@@ -706,9 +710,6 @@ Language.")
   ;; 2030-12-31.  See  for details.
   "main.mysqldump"
 
-  ;; XXX: Fails sporadically.
-  "innodb_fts.crash_recovery"
-
   ;; FIXME: This test fails on i686:
   ;; -myisampack: Can't create/write to file (Errcode: 17 "File exists")
   ;; +myisampack: Can't create/write to file (Errcode: 17 "File exists)
@@ -786,7 +787,6 @@ Language.")
("libxml2" ,libxml2)
("ncurses" ,ncurses)
("pcre" ,pcre)
-   ("snappy" ,snappy)
("xz" ,xz)
("zlib" ,zlib)))
 (propagated-inputs

WDYT?

There has been some activity around TokuDB in later versions of MariaDB,
maybe we can enable it again with 10.4.  For now, I think we should just
disable it.


signature.asc
Description: PGP signature

bug#36636: Tell users to update/reconfigure regularly

[pelzflorian (Florian Pelz)]

Yes, you are right that unattended upgrades are a more responsible
default than a notification cron job.  Unattended upgrades would
resolve this issue.  Should an unattended upgrades service be added to
Guix’ list of longer-term todos and this bug be closed?

Regards,
Florian

bug#35521: Mariadb test suite failures on x86_64-linux

[Gábor Boskovits]

Hello,

Arne Babenhauserheide  ezt írta (időpont: 2019. júl. 14.,
Vas 13:11):

> Hi Mark,
>
> Mark H Weaver  writes:
> > My log file contains the same error in the 'tokudb_bugs.mdev4533' test:
> >
> >   mysqltest: At line 6: query 'CREATE TABLE t1 (a INT(11), b CHAR(8))
> ENGINE=TokuDB' failed: 1005: Can't create table `test`.`t1` (errno: 28 "No
> space left on device")
>

Could you test using df -i if the file system is not running out of inodes?
That is another reason when the no space left on device error is reported.

>
> > After the build attempt, the failed build directory is ~3.4 GB, and I
> > still have ~7.4 GB.  That seems to imply that I had over 10 GB free
> > before starting the build, which sounds about right.  I don't have a
> > separate /tmp partition.
> …
> > I should mention that I'm using Btrfs.
>
> I use ext4, but I saw no space left on device errors when running guix
> lint. Since I had 700GiB free, that does not sound like real missing
> disk space, but rather that something else is wrong.
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>
Best regards,
g_bor

>

bug#36636: Tell users to update/reconfigure regularly

[Ludovic Courtès]

Hello,

"pelzflorian (Florian Pelz)"  skribis:

> When installing Guix System from the iso image, users should be told
> to pull and reconfigure regularly.  Even though it is mentioned in the
> manual, not everyone reads manuals.  I believe Guix’ target users
> include inexperienced users who do not know that they should update
> and upgrade regularly.  Therefore the installer should tell users how
> to do so and that it is important and perhaps what to do if things
> break.

The ‘guix’ command itself tells you to do so.  But of course, if you
never run ‘guix’, you never see that message.

> Of course, some users still won’t update and they should have the
> liberty to decide for themselves, but some users just forget to
> update.  Ubuntu defaults to automatic updates, which slow down the
> machine and annoy users.  Still, maybe there should be notifications
> like a cron job invoking libnotify’s notify-send.

Sounds like something we can do.

Ultimately though, what can we do for users who do not read the manual
and do not run ‘guix’ either?  Would a notification really help?

Longer-term I think we should have an unattended upgrade service, and it
should probably be part of ‘%desktop-services’.

Thoughts?

Ludo’.

bug#36611: Disappearing profile?

[Ludovic Courtès]

Hello,

ra...@free.fr skribis:

> (Cross-posting to help-guix as it may be more appropriate) 

I don’t think it’s necessary.

> 13. My profile disappeared once again and guix package does not work anymore 
> (it says "guix package: error: unsupported manifest format"). I realize that 
> my .guix-profile/etc/profile file has been emptied. 

What do you mean by “my profile disappeared once again”?  Is the
~/.guix-profile symlink still around?  What does:

  readlink -f ~/.guix-profile

show?

Regarding the “unsupported manifest format” error: what’s the content of
~/.guix-profile/manifest?  (You previously posted the contents of
~/.config/guix/current/manifest, but it’s not relevant here.)

In general profiles cannot “disappear”.  A potential issue one may
encounter is that, if you running several “guix install” or “guix
package” commands simultaneously, one of them will “win”, meaning that
work done by the other one is discarded.  However, that cannot lead to
the “unsupported manifest format” error.

Did you happen to run several such commands in parallel?

Thanks in advance,
Ludo’.

bug#36611: Installation of a new guix system -- summaries of the issues

[Ludovic Courtès]

Julien, could you quote only the relevant parts of the message you’re
replying to?  TIA!  :-)

Ludo’.

bug#36634: Virtual Machine Manager (virt-manager)

[Efraim Flashner]

On Sat, Jul 13, 2019 at 01:06:55AM -0400, Raghav Gururajan wrote:
> Hello Guix!
> 
> Unable to create any VMs by installing from any ISO file.
> 
> The virt-manager gives out the following error:
> 
> Unable to complete install: 'Unable to read from
> '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
> directory'
> 
> Traceback (most recent call last):
>   File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
> 2.1.0/share/virt-manager/virtManager/asyncjob.py", line 75, in
> cb_wrapper
> callback(asyncjob, *args, **kwargs)
>   File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
> 2.1.0/share/virt-manager/virtManager/create.py", line 2122, in
> _do_async_install
> guest.installer_instance.start_install(guest, meter=meter)
>   File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
> 2.1.0/share/virt-manager/virtinst/installer.py", line 415, in
> start_install
> doboot, transient)
>   File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
> 2.1.0/share/virt-manager/virtinst/installer.py", line 358, in
> _create_guest
> domain = self.conn.createXML(install_xml or final_xml, 0)
>   File "/gnu/store/kcdnna2613in9xfm9gxjqvkisdns911v-python-libvirt-
> 5.5.0/lib/python3.7/site-packages/libvirt.py", line 3840, in createXML
> if ret is None:raise libvirtError('virDomainCreateXML() failed',
> conn=self)
> libvirt.libvirtError: Unable to read from
> '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
> directory
> 
> Regards,
> RG.
> 
Checking my machine:
$ ls /sys/fs/cgroup/unified/
cgroup.controllers  cgroup.max.depth  cgroup.max.descendants  cgroup.procs  
cgroup.stat  cgroup.subtree_control  cgroup.threads

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#36571: icecat's CPE data is wrong

[Efraim Flashner]

On Thu, Jul 11, 2019 at 10:34:00PM +0200, Ludovic Courtès wrote:
> Hello,
> 
> Efraim Flashner  skribis:
> 
> > currently we have:
> > (cpe-name . "firefox_esr")
> > (cpe-version . ,(first (string-split version #\-)
> >
> > and it should be:
> > (cpe-name . "firefox")
> > (cpe-version . ,(first (string-split version #\.)
> >
> > however, this returns results for firefox@60, which I'm pretty sure
> > doesn't take into account that we're not running 60.0.0 but 60.8.0. With
> > the change 'guix lint -c cve iceat' returns:
> > icecat@60.8.0-guix1: probably vulnerable to CVE-2019-9788, CVE-2019-9789, 
> > […]
> 
> Indeed, something seems to be wrong.
> 
> --8<---cut here---start->8---
> scheme@(guile-user)> ,use(guix cve)
> scheme@(guile-user)> (vulnerabilities->lookup-proc (current-vulnerabilities))
> fetching CVE database for 2019...
> fetching CVE database for 2018...
> scheme@(guile-user)> $2
> $3 = #
> scheme@(guile-user)> (length ($2 "firefox" "60"))
> $4 = 107
> scheme@(guile-user)> (length ($2 "firefox" "60.8"))
> $5 = 0
> scheme@(guile-user)> (length ($2 "firefox" "60.5"))
> $6 = 0
> --8<---cut here---end--->8---
> 
> Actually, the procedure returned by ‘vulnerabilities->lookup-proc’
> performs exact matches on version string.  So “60” is _not_ equivalent
> to “60 or any 60.x version”.
> 
> Here are the versions we see for one of these CVEs:
> 
> --8<---cut here---start->8---
> scheme@(guile-user)> ,use(srfi srfi-1)
> scheme@(guile-user)> (find (lambda (vuln)
>(string=? (vulnerability-id vuln)
>  "CVE-2019-9788"))
>  (current-vulnerabilities))
> $9 = #< id: "CVE-2019-9788" packages: (("thunderbird" …) 
> ("firefox_esr" "60.5.0" "60.4.0" "60.3.0" "60.2.2" "60.2.0" "60.1.0" "60.0" 
> "53.0.0" "52.9.0" …) ("firefox" "9.0.1" "9.0" "8.0.1" "8.0" "7.0.1" "7.0" 
> "65.0" "64.0.2" "64.0" "63.0.3" "63.0.1" "63.0" "62.0.3" "62.0.2" "62.0" 
> "61.0.2" "61.0.1" "61.0" "60.6.1" "60.5.0" "60.4.0" "60.3.0" "60.2.2" 
> "60.2.1" "60.2.0" "60.1.0" …)>
> --8<---cut here---end--->8---
> 
> So IceCat probably corresponds to “firefox_esr”, but we got the CPE
> version string wrong: we should just strip the “-gnu*” suffix, nothing
> more.
> 
> WDYT?
> 
I was about to go and make the change but it seems that this is already
what we have. 'firefox_esr' and '(first (string-split version #\-))'. So
it looks like the vulnerability list just hasn't caught up with the
version we have now.

Closing as 'everything works as expected'

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#35521: Mariadb test suite failures on x86_64-linux

[Arne Babenhauserheide]

Hi Mark,

Mark H Weaver  writes:
> My log file contains the same error in the 'tokudb_bugs.mdev4533' test:
>
>   mysqltest: At line 6: query 'CREATE TABLE t1 (a INT(11), b CHAR(8)) 
> ENGINE=TokuDB' failed: 1005: Can't create table `test`.`t1` (errno: 28 "No 
> space left on device")
>
> After the build attempt, the failed build directory is ~3.4 GB, and I
> still have ~7.4 GB.  That seems to imply that I had over 10 GB free
> before starting the build, which sounds about right.  I don't have a
> separate /tmp partition.
…
> I should mention that I'm using Btrfs.

I use ext4, but I saw no space left on device errors when running guix
lint. Since I had 700GiB free, that does not sound like real missing
disk space, but rather that something else is wrong.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature