* [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a. @ 2014-10-10 18:18 Eric Bavier 2014-10-11 21:59 ` Ludovic Courtès 0 siblings, 1 reply; 6+ messages in thread From: Eric Bavier @ 2014-10-10 18:18 UTC (permalink / raw) To: guix-devel [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: 0002-gnu-libjpeg-Upgrade-to-version-9a.patch --] [-- Type: text/x-diff, Size: 1167 bytes --] From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001 From: Eric Bavier <bavier@member.fsf.org> Date: Fri, 10 Oct 2014 13:07:55 -0500 Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a. * gnu/packages/image.scm (libjpeg): Upgrade to version 9a. --- gnu/packages/image.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm index 1b15be3..e4f831e 100644 --- a/gnu/packages/image.scm +++ b/gnu/packages/image.scm @@ -64,13 +64,13 @@ library. It supports almost all PNG features and is extensible.") (define-public libjpeg (package (name "libjpeg") - (version "9") + (version "9a") (source (origin (method url-fetch) (uri (string-append "http://www.ijg.org/files/jpegsrc.v" version ".tar.gz")) (sha256 (base32 - "0dg5wxcx3cw0hal9gvivj97vid9z0s5sb1yvg55hpxmafn9rxqn4")))) + "19q5zr4n60sjcvfbyv06n4pcl1mai3ipvnd2akflayciinj3wx9s")))) (build-system gnu-build-system) (synopsis "Libjpeg, a library for handling JPEG files") (description -- 1.7.9.5 [-- Attachment #2: Type: text/plain, Size: 17 bytes --] -- Eric Bavier ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a. 2014-10-10 18:18 [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a Eric Bavier @ 2014-10-11 21:59 ` Ludovic Courtès 2014-10-12 4:46 ` Mark H Weaver 0 siblings, 1 reply; 6+ messages in thread From: Ludovic Courtès @ 2014-10-11 21:59 UTC (permalink / raw) To: Eric Bavier; +Cc: guix-devel Eric Bavier <ericbavier@gmail.com> skribis: > From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001 > From: Eric Bavier <bavier@member.fsf.org> > Date: Fri, 10 Oct 2014 13:07:55 -0500 > Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a. > > * gnu/packages/image.scm (libjpeg): Upgrade to version 9a. OK. Ludo'. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a. 2014-10-11 21:59 ` Ludovic Courtès @ 2014-10-12 4:46 ` Mark H Weaver 2014-10-12 12:58 ` Rebuilds and branches Ludovic Courtès 0 siblings, 1 reply; 6+ messages in thread From: Mark H Weaver @ 2014-10-12 4:46 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel ludo@gnu.org (Ludovic Courtès) writes: > Eric Bavier <ericbavier@gmail.com> skribis: > >> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001 >> From: Eric Bavier <bavier@member.fsf.org> >> Date: Fri, 10 Oct 2014 13:07:55 -0500 >> Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a. >> >> * gnu/packages/image.scm (libjpeg): Upgrade to version 9a. > > OK. This triggered over 450 rebuilds. I wonder if it should have been done in core-updates instead. Mark ^ permalink raw reply [flat|nested] 6+ messages in thread
* Rebuilds and branches 2014-10-12 4:46 ` Mark H Weaver @ 2014-10-12 12:58 ` Ludovic Courtès 2014-10-12 14:50 ` Mark H Weaver 0 siblings, 1 reply; 6+ messages in thread From: Ludovic Courtès @ 2014-10-12 12:58 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel Mark H Weaver <mhw@netris.org> skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >> Eric Bavier <ericbavier@gmail.com> skribis: >> >>> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001 >>> From: Eric Bavier <bavier@member.fsf.org> >>> Date: Fri, 10 Oct 2014 13:07:55 -0500 >>> Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a. >>> >>> * gnu/packages/image.scm (libjpeg): Upgrade to version 9a. >> >> OK. > > This triggered over 450 rebuilds. I wonder if it should have been done > in core-updates instead. Arf, probably yes, in a ‘libjpeg-update’ branch, rather. What about having a policy for that? Like, above some threshold of the number of rebuilds reported by ‘guix refresh -l’ (200 packages?), set up a separate branch and Hydra job set. In an ideal world a patch queue manager would automatically take care of that. Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rebuilds and branches 2014-10-12 12:58 ` Rebuilds and branches Ludovic Courtès @ 2014-10-12 14:50 ` Mark H Weaver 2014-10-12 15:58 ` Ludovic Courtès 0 siblings, 1 reply; 6+ messages in thread From: Mark H Weaver @ 2014-10-12 14:50 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel ludo@gnu.org (Ludovic Courtès) writes: > Mark H Weaver <mhw@netris.org> skribis: > >> ludo@gnu.org (Ludovic Courtès) writes: >> >>> Eric Bavier <ericbavier@gmail.com> skribis: >>> >>>> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001 >>>> From: Eric Bavier <bavier@member.fsf.org> >>>> Date: Fri, 10 Oct 2014 13:07:55 -0500 >>>> Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a. >>>> >>>> * gnu/packages/image.scm (libjpeg): Upgrade to version 9a. >>> >>> OK. >> >> This triggered over 450 rebuilds. I wonder if it should have been done >> in core-updates instead. > > Arf, probably yes, in a ‘libjpeg-update’ branch, rather. Well, suppose we update two different core packages in close succession, e.g. make 4.1 and bash 4.3.30. I don't want two independent rebuilds, one with make 4.1 and bash 4.3.27 and another with make 4.0 and bash 4.3.30. Each of those would turn out to be useless. > What about having a policy for that? Like, above some threshold of the > number of rebuilds reported by ‘guix refresh -l’ (200 packages?), set up > a separate branch and Hydra job set. The severity of the bug being fixed may also be a relevant factor in the decision. > In an ideal world a patch queue manager would automatically take care of > that. I'm not sure the decision can be made fully automatically, but it would certainly be nice to have some tools to make the job easier. Mark ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rebuilds and branches 2014-10-12 14:50 ` Mark H Weaver @ 2014-10-12 15:58 ` Ludovic Courtès 0 siblings, 0 replies; 6+ messages in thread From: Ludovic Courtès @ 2014-10-12 15:58 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel Mark H Weaver <mhw@netris.org> skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver <mhw@netris.org> skribis: >> >>> ludo@gnu.org (Ludovic Courtès) writes: >>> >>>> Eric Bavier <ericbavier@gmail.com> skribis: >>>> >>>>> From 88a4cc3aa53c73186b5dbb85bf03b2138f24c825 Mon Sep 17 00:00:00 2001 >>>>> From: Eric Bavier <bavier@member.fsf.org> >>>>> Date: Fri, 10 Oct 2014 13:07:55 -0500 >>>>> Subject: [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a. >>>>> >>>>> * gnu/packages/image.scm (libjpeg): Upgrade to version 9a. >>>> >>>> OK. >>> >>> This triggered over 450 rebuilds. I wonder if it should have been done >>> in core-updates instead. >> >> Arf, probably yes, in a ‘libjpeg-update’ branch, rather. > > Well, suppose we update two different core packages in close succession, > e.g. make 4.1 and bash 4.3.30. I don't want two independent rebuilds, > one with make 4.1 and bash 4.3.27 and another with make 4.0 and bash > 4.3.30. Each of those would turn out to be useless. Right. However, this is not a good example, since both Make and Bash are core packages, so they would go in the same ‘core-updates’ branch. I was rather thinking of packages like libjpeg, libpng, GLib, GTK+, Qt, which have many dependencies, but are fairly independent from one another. Maybe in some cases it’ll make sense to update several of them in the same branch, as you note. >> What about having a policy for that? Like, above some threshold of the >> number of rebuilds reported by ‘guix refresh -l’ (200 packages?), set up >> a separate branch and Hydra job set. > > The severity of the bug being fixed may also be a relevant factor in the > decision. Yes, I was thinking of non-security-critical updates. For bug-fix updates that trigger 200+ rebuilds, it may still make sense to have a separate branch and job set, for the sake of keeping ‘master’ stable. WDYT? Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-10-12 15:58 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-10 18:18 [PATCH 2/4] gnu: libjpeg: Upgrade to version 9a Eric Bavier 2014-10-11 21:59 ` Ludovic Courtès 2014-10-12 4:46 ` Mark H Weaver 2014-10-12 12:58 ` Rebuilds and branches Ludovic Courtès 2014-10-12 14:50 ` Mark H Weaver 2014-10-12 15:58 ` Ludovic Courtès
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.