This is the status of the openjdk-8 build: as the log confirms, the i386 packages got inserted, while the amd64 not due to the md5 conflict since both are creating the same openjdk-8-source_8u242-b04-2~company10+6_all.deb
In my setup, the error seems consistent for "any" source packages that also produce an "all" package. From a reprepro point of view, it makes sense; though I doubt that I am the first one that requires to compile these packages. I must be missing something. mini-buildd@debian-builder01:~/repositories/televic$ reprepro listmatched buster-televic-unstable '*openjdk*' buster-company-unstable|main|amd64: openjdk-8-dbg 8u232-b09-1~deb9u1 buster-company-unstable|main|amd64: openjdk-8-demo 8u232-b09-1~deb9u1 buster-company-unstable|main|amd64: openjdk-8-doc 8u242-b04-2~company10+6 buster-company-unstable|main|amd64: openjdk-8-jdk 8u232-b09-1~deb9u1 buster-company-unstable|main|amd64: openjdk-8-jdk-headless 8u232-b09-1~deb9u1 buster-company-unstable|main|amd64: openjdk-8-jre 8u232-b09-1~deb9u1 buster-company-unstable|main|amd64: openjdk-8-jre-headless 8u232-b09-1~deb9u1 buster-company-unstable|main|amd64: openjdk-8-jre-zero 8u232-b09-1~deb9u1 buster-company-unstable|main|amd64: openjdk-8-source 8u242-b04-2~company10+6 buster-company-unstable|main|i386: openjdk-8-dbg 8u242-b04-2~company10+6 buster-company-unstable|main|i386: openjdk-8-demo 8u242-b04-2~company10+6 buster-company-unstable|main|i386: openjdk-8-doc 8u242-b04-2~company10+6 buster-company-unstable|main|i386: openjdk-8-jdk 8u242-b04-2~company10+6 buster-company-unstable|main|i386: openjdk-8-jdk-headless 8u242-b04-2~company10+6 buster-company-unstable|main|i386: openjdk-8-jre 8u242-b04-2~company10+6 buster-company-unstable|main|i386: openjdk-8-jre-headless 8u242-b04-2~company10+6 buster-company-unstable|main|i386: openjdk-8-jre-zero 8u242-b04-2~company10+6 buster-company-unstable|main|i386: openjdk-8-source 8u242-b04-2~company10+6 buster-company-unstable|main|source: openjdk-8 8u242-b04-2~company10+6 On Thu, 12 Mar 2020 at 11:04, Marc Leeman <marc.lee...@gmail.com> wrote: > > As it turns out, I have had the issue before and did not really notice it. > > I tried to backport openjdk8 to buster and both builds (after fixing > lintian) errors succeed. However, there is that strange reprepro error as > described before (so not from a portext this time). > > The result is that the i386 package gets inserted (not mandatory) but the > amd64 package does not end up in the repository. The log entries are again > (see log), but it is again the md5 conflict that is acting up. > > > > > On Tue, 25 Feb 2020 at 13:36, Stephan Sürken <abs...@debian.org> wrote: > >> Hi Marc, >> >> On Fri, 2020-02-21 at 11:54 +0100, Marc Leeman wrote: >> > >> > Could it be that there is some config option that is still wreaking >> > havoc after having been disabled. >> >> Fwiw, there is this 'inconvenience' bug: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838393 >> >> So just be sure to restart the Daemon after configuration changes. >> >> > The initial setup might have had amd64/i386 build architecture all >> > enabled. >> > >> > I then disabled i386 to get something working quickly only to enable >> > it again a couple of months later, this time with the build >> > architecture all disabled for i386. >> >> Hmm, ok. Seems suspicious, but would still not explain the behaviour >> you are seeing, imho. >> >> Could you, before doing the failing portext, check the repo status for >> the package? I.e., s.th. like >> >> --- >> su - mini-buildd >> cd ~/repositories/<repo>/ >> reprepro listmatched stretch-<repo>-experimental '*gstreamer*' >> --- >> >> Thx! >> >> S >> >> > > -- > g. Marc > -- g. Marc
