Chris Marusich writes: > Gábor Boskovits writes: > >> Hello! >> >> I just run a quick grep to see which files might be interesting. >> >> We use ant-build-system in: >> axoloti.scm * >> bioinformatics.scm * >> compression.scm * >> icu4c.scm >> java.scm * >> libusb.scm * >> music.scm * >> textutlis.scm >> uml.scm * >> version-control.scm * >> web.scm * >> xml.scm >> >> Only the ant-build system uses icedtea among build systems. >> >> Icedtea is explicitly metioned in the ones maked with *, and: >> kodi.scm >> math.scm >> ruby.scm >> >> We have a definition in place where currently icedtea is defined to be >> icedtea-7. >> I guess we could just flip that to icedtea-8, and check what still works. >> That would flip the version in the build system also, as it uses "icedtea". >> >> Should I check which packages are affected in advance, or just go with the >> build and see what does not work? > > Another way to check what packages we'll need to try to build is to use > "guix refresh", which uses some features of (guix graph) to display > information about dependent packages. Here's what we get for icedtea-7: > > [0] marusich@garuda.local:~/guix > $ ./pre-inst-env guix refresh -l -e '(@ (gnu packages java) icedtea-7)' > Building the following 39 packages would ensure 202 dependent packages are rebuilt: sra-tools@2.8.2-1 minced@0.2.0 r-seurat@1.4.0.12-1.fccb77d ant@1.10.1 java-htsjdk@1.129 java-jdom@1.1.3 clojure@1.8.0 java-osgi-service-jdbc@1.0.0 java-plexus-interpolation@1.23 java-commons-daemon@1.0.15 java-commons-net@3.6 java-commons-cli@1.2 java-commons-lang@2.6 java-jmh@1.17.5 tuxguitar@1.4 java-commons-collections4@4.1 java-javax-mail@1.5.6 f-seq@1.1-1.6ccded3 java-commons-beanutils@1.9.3 java-jgit@4.7.0.201704051617-r java-osgi-service-resolver@1.0.1 java-osgi-service-packageadmin@1.2.0 java-osgi-service-cm@1.5.0 java-osgi-util-tracker@1.5.1 antlr3@3.5.2 java-eclipse-team-core@3.8.0 java-httpcomponents-httpcore-ab@4.4.6 java-httpcomponents-httpmime@4.5.3 java-httpcomponents-httpcore-nio@4.4.6 java-plexus-container-default@1.7.1 kodi@18.0_alpha-6-f22d62d hdf-java@3.3.2 ruby-atoulme-antwrap@0.7.5 plantuml@8048 java-guice-servlet@4.1 java-eclipse-jetty-servlet@9.4.6 java-eclipse-jetty-servlet@9.2.22 icedtea-web@1.6.2 axoloti-patcher@1.0.12 > > > So, I think we should probably do the following: > > 1) Confirm that these packages build before making changes. If any > fail, fix them first if possible. > > 2) As you suggested, flip the icedtea variable to point to icedtea-8 > instead of icedtea-7. > > 3) Repeat the builds, and see what fails. Fix any new breakage. > > And of course, we should opportunistically clean up package definitions > as we go. > > I'm going to try step (1) tonight on my laptop. Is there a way to check > their build status on Hydra, I wonder? I'm planning to just do it in a > simple shell one-liner like the following: > > for pkg in $(> /tmp/log; else echo failure: $pkg >> /tmp/log; fi; done > > ...but I'm sure there is probably a more elegant way to accomplish the > same task. Anyway, I'll let you know how it goes. > >> As first step it is not needed to remove #:jdk icedtea-8 references, >> because I think that simply becomes a noop. Am I right here? >> That can be done as the last step before merging, I guess. > > I think that's right, but I haven't looked closely yet, and Ricardo may > know more. Whoops! I forgot to include Gábor on my last email, so I've included Gábor on this one. Sorry about that. -- Chris