[PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[宋文武]

* gnu/packages/glib.scm (gobject-introspection): Update to 1.44.0.
  [source]: Use mirror://gnome.
  [arguments]<#:phases>: Remove.
* gnu/packages/patches/gobject-introspection-cc.patch: Rewrite to
  set os.environ['CC'] in 'giscanner/__init__.py'.
---
 gnu/packages/glib.scm                              | 15 ++++---------
 .../patches/gobject-introspection-cc.patch         | 25 ++++++++++------------
 2 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index 688c0b6..fe89909 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -207,14 +207,14 @@ dynamic loading, and an object system.")
 (define gobject-introspection
   (package
     (name "gobject-introspection")
-    (version "1.42.0")
+    (version "1.44.0")
     (source (origin
              (method url-fetch)
-             (uri (string-append "http://ftp.gnome.org/pub/GNOME/sources/"
+             (uri (string-append "mirror://gnome/sources/"
                    "gobject-introspection/" (version-major+minor version)
                    "/gobject-introspection-" version ".tar.xz"))
              (sha256
-              (base32 "1xwm7wmr9r9wp6xljb3bckx3a4siybavaq39w46ly7gpskxfv8iv"))
+              (base32 "1b972qg2yb51sdavfvb6kc19akwc15c1bwnbg81vadxamql2q33g"))
              (patches (list
                        (search-patch "gobject-introspection-cc.patch")
                        (search-patch
@@ -243,14 +243,7 @@ dynamic loading, and an object system.")
     (arguments
      `(;; The patch 'gobject-introspection-absolute-shlib-path.patch' causes
        ;; some tests to fail.
-       #:tests? #f
-       #:phases
-        (alist-cons-before
-         'configure 'patch-paths
-         (lambda _
-           (substitute* "giscanner/sourcescanner.py"
-             (("GUIX_GCC_PATH") (which "gcc"))))
-         %standard-phases)))
+       #:tests? #f))
     (home-page "https://wiki.gnome.org/GObjectIntrospection")
     (synopsis "Generate interface introspection data for GObject libraries")
     (description
diff --git a/gnu/packages/patches/gobject-introspection-cc.patch b/gnu/packages/patches/gobject-introspection-cc.patch
index 38b919a..d9cacf4 100644
--- a/gnu/packages/patches/gobject-introspection-cc.patch
+++ b/gnu/packages/patches/gobject-introspection-cc.patch
@@ -1,14 +1,11 @@
---- a/giscanner/sourcescanner.py	2013-12-15 23:03:54.002937000 +0100
-+++ b/giscanner/sourcescanner.py	2013-12-15 23:04:50.322937000 +0100
-@@ -277,6 +277,11 @@
-         defines = ['__GI_SCANNER__']
-         undefs = []
-         cpp_args = os.environ.get('CC', 'cc').split()  # support CC="ccache gcc"
-+        if (cpp_args == ['cc'] and
-+            not any(map(lambda x: os.access(os.path.join(x, 'cc'), os.X_OK),
-+                        os.environ.get('PATH').split(':')))):
-+            cpp_args = ['GUIX_GCC_PATH']
-+
-         if 'cl' in cpp_args:
-             # The Microsoft compiler/preprocessor (cl) does not accept
-             # source input from stdin (the '-' flag), so we need
+Use gcc as the default C compiler if CC is not set.
+
+
+--- gobject-introspection-1.44.0.orig/giscanner/__init__.py	2014-08-04 22:37:07.000000000 +0800
++++ gobject-introspection-1.44.0/giscanner/__init__.py	2015-04-20 17:30:26.507697234 +0800
+@@ -22,3 +22,5 @@
+ builddir = os.environ.get('UNINSTALLED_INTROSPECTION_BUILDDIR')
+ if builddir is not None:
+     __path__.append(os.path.join(builddir, 'giscanner'))
++if not 'CC' in os.environ:
++    os.environ['CC'] = 'gcc'
-- 
2.2.1

[PATCH 2/7] gnu: itstool: Update to 2.0.2.

[宋文武]

* gnu/packages/glib.scm (itstool): Update to 2.0.2.
---
 gnu/packages/glib.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index fe89909..13c1314 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -306,14 +306,14 @@ The intltool collection can be used to do these things:
 (define itstool
   (package
     (name "itstool")
-    (version "1.2.0")
+    (version "2.0.2")
     (source (origin
              (method url-fetch)
              (uri (string-append "http://files.itstool.org/itstool/itstool-"
                                  version ".tar.bz2"))
              (sha256
               (base32
-               "1akq75aflihm3y7js8biy7b5mw2g11vl8yq90gydnwlwp0zxdzj6"))))
+               "0fh34wi52i0qikgvlmrcpf1vx6gc1xqdad4539l4d9hikfsrz45z"))))
     (build-system gnu-build-system)
     (propagated-inputs
      `(("libxml2" ,libxml2)
-- 
2.2.1

[PATCH 3/7] gnu: dbus-glib: Update to 0.104.

[宋文武]

* gnu/packages/glib.scm (dbus-glib): Update to 0.104.
---
 gnu/packages/glib.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index 13c1314..c0fb00b 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -343,7 +343,7 @@ translated.")
 (define dbus-glib
   (package
     (name "dbus-glib")
-    (version "0.102")
+    (version "0.104")
     (source (origin
              (method url-fetch)
              (uri
@@ -351,7 +351,7 @@ translated.")
                              version ".tar.gz"))
              (sha256
               (base32
-               "177j5p2vrvpmzk2xrrj6akn73kvpbvnmsjvlmca9l55qbdcfsr39"))))
+               "1xi1v1msz75qs0s4lkyf1psrksdppa3hwkg0mznc6gpw5flg3hdz"))))
     (build-system gnu-build-system)
     (inputs
      `(("dbus" ,dbus)
-- 
2.2.1

[PATCH 4/7] gnu: libsigc++: Update to 2.4.1.

[宋文武]

* gnu/packages/glib.scm (libsigc++): Update to 2.4.1.
---
 gnu/packages/glib.scm | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index c0fb00b..f1de887 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -370,14 +370,15 @@ by GDBus included in Glib.")
 (define libsigc++
   (package
     (name "libsigc++")
-    (version "2.3.1")
+    (version "2.4.1")
     (source (origin
              (method url-fetch)
-             (uri (string-append "mirror://gnome/sources/libsigc++/2.3/libsigc++-"
-                                 version ".tar.xz"))
+             (uri (string-append "mirror://gnome/sources/libsigc++/"
+                                 (version-major+minor version) "/"
+                                 name "-" version ".tar.xz"))
              (sha256
               (base32
-               "14q3sq6d43f6wfcmwhw4v1aal4ba0h5x9v6wkxy2dnqznd95il37"))))
+               "1v0rvkzglzmf67y9nkcppwjwi68j1cy5yhldvcq7xrv8594l612l"))))
     (build-system gnu-build-system)
     (native-inputs `(("pkg-config" ,pkg-config)
                      ("m4" ,m4)))
-- 
2.2.1

[PATCH 5/7] gnu: glibmm: Update to 2.44.0.

[宋文武]

* gnu/packages/glib.scm (glibmm): Update to 2.44.0.
---
 gnu/packages/glib.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index f1de887..18a5a51 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -397,7 +397,7 @@ has an ease of use unmatched by other C++ callback libraries.")
 (define glibmm
   (package
     (name "glibmm")
-    (version "2.42.0")
+    (version "2.44.0")
     (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnome/sources/glibmm/"
@@ -405,7 +405,7 @@ has an ease of use unmatched by other C++ callback libraries.")
                                  "/glibmm-" version ".tar.xz"))
              (sha256
               (base32
-               "15rk3az8jh3rdwlc3lxjljbnh60drj3ka9574zd39lkqfgcq6l4q"))))
+               "1a1fczy7hcpn24fglyn4i79f4yjc8s50is70q03mb294bm1c02hv"))))
     (build-system gnu-build-system)
     (arguments
      `(#:phases (alist-cons-before
-- 
2.2.1

[PATCH 6/7] gnu: python-pygobject: Update to 3.16.1.

[宋文武]

* gnu/packages/glib.scm (python-pygobject): Update to 3.16.1.
---
 gnu/packages/glib.scm | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index 18a5a51..f888d5b 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -479,8 +479,7 @@ useful for C++.")
 (define-public python-pygobject
   (package
     (name "python-pygobject")
-    (version "3.12.2")                  ;last version that works with
-                                        ;gobject-introspection 1.38
+    (version "3.16.1")
     (source
      (origin
        (method url-fetch)
@@ -489,8 +488,7 @@ useful for C++.")
                            "/pygobject-" version ".tar.xz"))
        (sha256
         (base32
-         "08m5yad1hjdax4g39w6lgjk4124mcwpa8fc5iyvb8nygk8s3syky"))))
-    ;; 3.14.0: 0m1d75iwxa6k1xbkn6c6yq5r10pxnf7i5c2a5yvwsnab7ylzz7kp
+         "1hqyma73w0lnjcgx68kawhnq84aq92xlkdqphrlc2ppia38dm5kx"))))
     (build-system gnu-build-system)
     (native-inputs
      `(("which" ,which)
-- 
2.2.1

[PATCH 7/7] gnu: poppler: Update to 0.32.0.

[宋文武]

* gnu/packages/pdf.scm (poppler): Update to 0.32.0.
---
 gnu/packages/pdf.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/pdf.scm b/gnu/packages/pdf.scm
index 21fb395..bca577e 100644
--- a/gnu/packages/pdf.scm
+++ b/gnu/packages/pdf.scm
@@ -50,13 +50,13 @@
 (define-public poppler
   (package
    (name "poppler")
-   (version "0.28.1")
+   (version "0.32.0")
    (source (origin
             (method url-fetch)
             (uri (string-append "http://poppler.freedesktop.org/poppler-"
                                 version ".tar.xz"))
             (sha256 (base32
-                     "01pxjdbhvpxf00ncf8d9wxc8gkcqcxz59lwrpa151ah988inxkrc"))))
+                     "162vfbvbz0frvqyk00ldsbl49h4bj8i8wn0ngfl30xg1lldy6qs9"))))
    (build-system gnu-build-system)
    ;; FIXME: more dependencies could  be added
    ;;  cairo output:       no (requires cairo >= 1.10.0)
-- 
2.2.1

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Ludovic Courtès]

Hi!

Note: this series should go to a ‘glib’ branch, which we’ll get Hydra to
build.

宋文武 <iyzsong@gmail.com> skribis:

> * gnu/packages/glib.scm (gobject-introspection): Update to 1.44.0.
>   [source]: Use mirror://gnome.
>   [arguments]<#:phases>: Remove.
> * gnu/packages/patches/gobject-introspection-cc.patch: Rewrite to
>   set os.environ['CC'] in 'giscanner/__init__.py'.

I don’t know exactly what happened but something broke since the
original patch went in.  The intent was described at
<https://lists.gnu.org/archive/html/guix-devel/2013-11/msg00127.html>.

> +Use gcc as the default C compiler if CC is not set.
> +
> +
> +--- gobject-introspection-1.44.0.orig/giscanner/__init__.py	2014-08-04 22:37:07.000000000 +0800
> ++++ gobject-introspection-1.44.0/giscanner/__init__.py	2015-04-20 17:30:26.507697234 +0800
> +@@ -22,3 +22,5 @@
> + builddir = os.environ.get('UNINSTALLED_INTROSPECTION_BUILDDIR')
> + if builddir is not None:
> +     __path__.append(os.path.join(builddir, 'giscanner'))
> ++if not 'CC' in os.environ:
> ++    os.environ['CC'] = 'gcc'

Is it OK if $CC is set for all the child processes of giscanner?

Assuming there’s no issue in this area, that looks good to me.  And
there’s a whole bunch of CC=gcc that you can remove afterwards.  :-)

Thanks!

Ludo’.

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[宋文武]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Note: this series should go to a ‘glib’ branch, which we’ll get Hydra to
> build.
>
> 宋文武 <iyzsong@gmail.com> skribis:
>
>> * gnu/packages/glib.scm (gobject-introspection): Update to 1.44.0.
>>   [source]: Use mirror://gnome.
>>   [arguments]<#:phases>: Remove.
>> * gnu/packages/patches/gobject-introspection-cc.patch: Rewrite to
>>   set os.environ['CC'] in 'giscanner/__init__.py'.
>
> I don’t know exactly what happened but something broke since the
> original patch went in.  The intent was described at
> <https://lists.gnu.org/archive/html/guix-devel/2013-11/msg00127.html>.
>
>> +Use gcc as the default C compiler if CC is not set.
>> +
>> +
>> +--- gobject-introspection-1.44.0.orig/giscanner/__init__.py	2014-08-04 22:37:07.000000000 +0800
>> ++++ gobject-introspection-1.44.0/giscanner/__init__.py	2015-04-20 17:30:26.507697234 +0800
>> +@@ -22,3 +22,5 @@
>> + builddir = os.environ.get('UNINSTALLED_INTROSPECTION_BUILDDIR')
>> + if builddir is not None:
>> +     __path__.append(os.path.join(builddir, 'giscanner'))
>> ++if not 'CC' in os.environ:
>> ++    os.environ['CC'] = 'gcc'
>
> Is it OK if $CC is set for all the child processes of giscanner?
IIUC, this didn't set $CC for child processes, just update the
os.environ dict (not the env table in unix way) for the python process.
>
> Assuming there’s no issue in this area, that looks good to me.  And
> there’s a whole bunch of CC=gcc that you can remove afterwards.  :-)
Yes.
>
> Thanks!
>
> Ludo’.

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Ludovic Courtès]

OK for the 6 package updates, in a ‘glib’ (or similar) branch.

Thanks!

Ludo’.

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Andreas Enge]

On Tue, Apr 21, 2015 at 11:05:43PM +0200, Ludovic Courtès wrote:
> OK for the 6 package updates, in a ‘glib’ (or similar) branch.

I created a branch "wip-glib" from master and have it built on hydra;
you can push there.

Andreas

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> On Tue, Apr 21, 2015 at 11:05:43PM +0200, Ludovic Courtès wrote:
>> OK for the 6 package updates, in a ‘glib’ (or similar) branch.
>
> I created a branch "wip-glib" from master and have it built on hydra;
> you can push there.

We shouldn't ask Hydra to build it until all of the relevant patches are
pushed.  Therefore, I have deleted the 'wip-glib' jobset for now, since
it was about to rebuild 1335 builds based on the libidn-1.30 update,
much of which would have been wasted because they'd have to be rebuilt
again after 宋文武 pushed his patches.  I also have an libxfont security
update to add to the branch as well.

I'm sorry for stepping on toes here, but our humble build farm is in
dire need of an upgrade, and in the meantime we will have to be careful
not to put too much load on it, and especially to avoid gratuitous
wasted work for it.

     Regards,
       Mark

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[宋文武]

Mark H Weaver <mhw@netris.org> writes:

> Andreas Enge <andreas@enge.fr> writes:
>
>> On Tue, Apr 21, 2015 at 11:05:43PM +0200, Ludovic Courtès wrote:
>>> OK for the 6 package updates, in a ‘glib’ (or similar) branch.
>>
>> I created a branch "wip-glib" from master and have it built on hydra;
>> you can push there.
Thanks.
>
> We shouldn't ask Hydra to build it until all of the relevant patches are
> pushed.  Therefore, I have deleted the 'wip-glib' jobset for now, since
> it was about to rebuild 1335 builds based on the libidn-1.30 update,
> much of which would have been wasted because they'd have to be rebuilt
> again after 宋文武 pushed his patches.  I also have an libxfont security
> update to add to the branch as well.
>
> I'm sorry for stepping on toes here, but our humble build farm is in
> dire need of an upgrade, and in the meantime we will have to be careful
> not to put too much load on it, and especially to avoid gratuitous
> wasted work for it.
OK, I have pushed those into 'wip-glib'.
Thanks for taking care of hydra ;-)
>
>      Regards,
>        Mark

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Andreas Enge]

On Tue, Apr 21, 2015 at 06:18:48PM -0400, Mark H Weaver wrote:
> We shouldn't ask Hydra to build it until all of the relevant patches are
> pushed.  Therefore, I have deleted the 'wip-glib' jobset for now, since
> it was about to rebuild 1335 builds based on the libidn-1.30 update,

These were shared with master anyway, so the argument does not apply.

I still think we should evaluate once without the patches in the new
branch (which causes only little work, modulo the problems with the
virtual machine...) so that we can see under "newly failing builds" what
problems have been caused by the patches.

Currently, all packages in wip-glib are listed under "new jobs", so the
successful and the (currently close to 500) failed builds are mixed up in an
enormous list of over 5000 packages, as well as those that already fail
on master are mixed up with those that fail only in the new branch.

> I also have an libxfont security update to add to the branch as well.

Well, in an ideal world, these two patch sets would be built separately,
so that any failure could be attributed to one or the other. So I would
not call two rebuilds "wasted work" in such a context. Apart from that,
maybe with the lack of build resources, we cannot afford to rebuild after
each git commit...

Andreas

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> On Tue, Apr 21, 2015 at 06:18:48PM -0400, Mark H Weaver wrote:
>> We shouldn't ask Hydra to build it until all of the relevant patches are
>> pushed.  Therefore, I have deleted the 'wip-glib' jobset for now, since
>> it was about to rebuild 1335 builds based on the libidn-1.30 update,
>
> These were shared with master anyway, so the argument does not apply.

Well, fair enough :)  However, since I reverted the libidn-1.30 update
and cancelled all the associated jobs on Hydra, the argument actually
does apply, although that was not clear from this message alone.

> I still think we should evaluate once without the patches in the new
> branch (which causes only little work, modulo the problems with the
> virtual machine...)

If evaluations were as cheap as they should be, then I think this would
be a reasonable thing to do.  Unfortunately, evaluations are currently
quite expensive on hydra.

> so that we can see under "newly failing builds" what
> problems have been caused by the patches.
>
> Currently, all packages in wip-glib are listed under "new jobs", so
> the successful and the (currently close to 500) failed builds are
> mixed up [...]

There's an easy solution for this: click on the little "Compare to..."
button near the top right corner of the evaluation page, and select
"Jobset gnu:master".  More generally, visit:

  http://hydra.gnu.org/eval/<XXXXXX>?compare=<YYYYYY>

where <XXXXXX> and <YYYYYY> are evaluation IDs.

>> I also have an libxfont security update to add to the branch as well.
>
> Well, in an ideal world, these two patch sets would be built separately,
> so that any failure could be attributed to one or the other. So I would
> not call two rebuilds "wasted work" in such a context.

Agreed.  If our build farm had enough capacity, this would be ideal.
I should not have said "wasted work".

Unfortunately, our build farm capacity is quite limited, and its master
machine is currently lacking in RAM and has extraordinarily poor disk
performance.  For these reasons, at present, it requires a great deal of
hand-holding to keep it from becoming overloaded to the point of being
unusuable.  I do a lot of that work myself, so I'm sensitive to the
issue.

I'm currently working on building the new hydra.gnu.org which will
hopefully perform much better, although we will still need to work
within our build capacity constraints until we have many more build
slaves.

Does this make sense?

       Mark

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Andreas Enge]

On Wed, Apr 22, 2015 at 11:03:08AM -0400, Mark H Weaver wrote:
> Well, fair enough :)  However, since I reverted the libidn-1.30 update
> and cancelled all the associated jobs on Hydra, the argument actually
> does apply, although that was not clear from this message alone.

Definitely, these two needed to go together.

> There's an easy solution for this: click on the little "Compare to..."
> button near the top right corner of the evaluation page, and select
> "Jobset gnu:master".  More generally, visit:
>   http://hydra.gnu.org/eval/<XXXXXX>?compare=<YYYYYY>
> where <XXXXXX> and <YYYYYY> are evaluation IDs.

Nifty trick, thanks for sharing!

> Does this make sense?

It does.

Now, I would still like some guidelines for what to commit to master and what
to core-updates, that we could possibly write down in HACKING (and update when
the hydra situation changes). Does something like "If you modify PACKAGE from
base.scm, or 'guix refresh -l PACKAGE' shows that >= N packages are affected,
then commit to core-updates" make sense? If yes, what should be the value
of N? If not, what would be a better idea?

Andreas

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> Now, I would still like some guidelines for what to commit to master and what
> to core-updates, that we could possibly write down in HACKING (and update when
> the hydra situation changes). Does something like "If you modify PACKAGE from
> base.scm, or 'guix refresh -l PACKAGE' shows that >= N packages are affected,
> then commit to core-updates" make sense? If yes, what should be the value
> of N? If not, what would be a better idea?

I personally use ‘guix refresh -l’ as the metric to decide whether to
create a branch or not.  I think it’s a good one though the ideal one
would be makespan.  Another consideration is the current build farm
load.

The “Commit Access” section mentions “upgrades that trigger a lot of
rebuilds”, which is quite vague but appeals to “common sense.”  I’m not
sure this can usefully worded as strictly as you suggest.  WDYT?

Thanks,
Ludo’.

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Andreas Enge <andreas@enge.fr> skribis:
>
>> Now, I would still like some guidelines for what to commit to master and what
>> to core-updates, that we could possibly write down in HACKING (and update when
>> the hydra situation changes). Does something like "If you modify PACKAGE from
>> base.scm, or 'guix refresh -l PACKAGE' shows that >= N packages are affected,
>> then commit to core-updates" make sense? If yes, what should be the value
>> of N? If not, what would be a better idea?
>
> I personally use ‘guix refresh -l’ as the metric to decide whether to
> create a branch or not.  I think it’s a good one though the ideal one
> would be makespan.  Another consideration is the current build farm
> load.
>
> The “Commit Access” section mentions “upgrades that trigger a lot of
> rebuilds”, which is quite vague but appeals to “common sense.”  I’m not
> sure this can usefully worded as strictly as you suggest.  WDYT?

I don't think we can decide on a value of N.  The decision should be
based not on the number of packages, but rather on the expected time
that users will be left without binary substitutes of the packages to
rebuild, how popular those packages are, how inconvenient it would be
for users to rebuild them on their own systems (e.g. icecat is very
popular and takes a long time to build), etc.

These considerations of the inconvenience to users should be compared
with the importance of the update/modification.  For example, security
updates warrant more inconvenience.  How much more depends on the
severity of the flaw.

I see no good way to formalize this.  I think we must rely on our best
judgment.

What do you think?

      Mark

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> Andreas Enge <andreas@enge.fr> writes:
>
>> Well, in an ideal world, these two patch sets would be built separately,
>> so that any failure could be attributed to one or the other. So I would
>> not call two rebuilds "wasted work" in such a context.
>
> Agreed.  If our build farm had enough capacity, this would be ideal.
> I should not have said "wasted work".
>
> Unfortunately, our build farm capacity is quite limited, and its master
> machine is currently lacking in RAM and has extraordinarily poor disk
> performance.  For these reasons, at present, it requires a great deal of
> hand-holding to keep it from becoming overloaded to the point of being
> unusuable.  I do a lot of that work myself, so I'm sensitive to the
> issue.
>
> I'm currently working on building the new hydra.gnu.org which will
> hopefully perform much better, although we will still need to work
> within our build capacity constraints until we have many more build
> slaves.

As you can see, even with the trimming of unnecessary jobs that I have
already done, Hydra has too much to do and is making very slow progress.

I would like to propose that we merge 'wip-glib' into 'core-updates',
remove the 'wip-glib' branch and jobset, and focus Hydra on building all
of 'core-updates'.

What do you think?

      Mark

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> I would like to propose that we merge 'wip-glib' into 'core-updates',
> remove the 'wip-glib' branch and jobset, and focus Hydra on building all
> of 'core-updates'.

I looked again, and see that wip-glib is already fully built on x86_64
and the amount left to build on i686 is manageable, so I retract this
proposal.  Sorry for the noise.

      Mark

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Andreas Enge]

On Sat, Apr 25, 2015 at 05:00:29AM -0400, Mark H Weaver wrote:
> Mark H Weaver <mhw@netris.org> writes:
> > I would like to propose that we merge 'wip-glib' into 'core-updates',
> > remove the 'wip-glib' branch and jobset, and focus Hydra on building all
> > of 'core-updates'.
> I looked again, and see that wip-glib is already fully built on x86_64
> and the amount left to build on i686 is manageable, so I retract this
> proposal.  Sorry for the noise.

How about merging wip-glib into master instead?

Andreas

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[宋文武]

Andreas Enge <andreas@enge.fr> writes:

> On Sat, Apr 25, 2015 at 05:00:29AM -0400, Mark H Weaver wrote:
>> Mark H Weaver <mhw@netris.org> writes:
>> > I would like to propose that we merge 'wip-glib' into 'core-updates',
>> > remove the 'wip-glib' branch and jobset, and focus Hydra on building all
>> > of 'core-updates'.
>> I looked again, and see that wip-glib is already fully built on x86_64
>> and the amount left to build on i686 is manageable, so I retract this
>> proposal.  Sorry for the noise.
>
> How about merging wip-glib into master instead?
Now, packages for i386 have finished, it's time to merge into master?

http://hydra.gnu.org/eval/103900?compare=master
> Andreas

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Andreas Enge]

On Sun, Apr 26, 2015 at 08:00:55AM +0800, 宋文武 wrote:
> Now, packages for i386 have finished, it's time to merge into master?
> http://hydra.gnu.org/eval/103900?compare=master

The main problemm seems to be that pulseaudio did not build on mips. But
is this at all related to your changes?

Andreas

Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Andreas Enge]

On Sun, Apr 26, 2015 at 08:00:55AM +0800, 宋文武 wrote:
> Now, packages for i386 have finished, it's time to merge into master?

I just merged and pushed, hopefully I did it correctly...

Andreas