It seems the 'all' packages are built for i386 as for amd64. As I
understood, they should not be built for i386 and only for amd64. They are
built for both architectures.
I'm havling a look in the sql configuration and from the following table,
it seems that the configuration is correct: build_architecture_all only for
amd64 and i386 is optional (so insert if i386 build fails).
355 CREATE TABLE IF NOT EXISTS "mini_buildd_architectureoption" ("id"
integer NOT NULL PRIMARY KEY AUTOINCREMENT, "extra_options" text NOT NULL,
"pickled_data" text NOT NULL, "architecture_id" varchar(50) NOT NU LL
REFERENCES "mini_buildd_architecture" ("name") DEFERRABLE INITIALLY
DEFERRED, "distribution_id" integer NOT NULL REFERENCES
"mini_buildd_distribution" ("id") DEFERRABLE INITIALLY DEFERRED, "optional"
bool NOT NULL, "build_architecture_all" bool NOT NULL);^M
356 INSERT INTO mini_buildd_architectureoption
VALUES(1,'','','amd64',1,0,1);^M
357 INSERT INTO mini_buildd_architectureoption
VALUES(3,'','','amd64',2,0,1);^M
358 INSERT INTO mini_buildd_architectureoption
VALUES(5,'','','amd64',3,0,1);^M
359 INSERT INTO mini_buildd_architectureoption
VALUES(11,'','','amd64',6,0,1);^M
360 INSERT INTO mini_buildd_architectureoption
VALUES(13,'','','i386',6,1,0);^M
361 INSERT INTO mini_buildd_architectureoption
VALUES(14,'','','i386',3,1,0);^M
362 INSERT INTO mini_buildd_architectureoption
VALUES(15,'','','i386',1,1,0);^M
363 INSERT INTO mini_buildd_architectureoption
VALUES(16,'','','i386',2,1,0);^M
On Thu, 12 Mar 2020 at 11:15, Marc Leeman <marc.lee...@gmail.com> wrote:
> 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
>
--
g. Marc
