Yeah, I was planning to patch your upstream version in our internal package
too before this entire virus lock down kicked in...
On Sun, 29 Mar 2020 at 11:26, Stephan Sürken wrote:
> Hi Marc,
>
> On Wed, 2020-03-18 at 14:42 +0100, Marc Leeman wrote:
> (...)
> > Thanks for the pointer.
> >
> >
Hi Marc,
On Wed, 2020-03-18 at 14:42 +0100, Marc Leeman wrote:
(...)
> Thanks for the pointer.
>
> I've applied the patch and restarted the service. I could recompile
> openjdk-8 without problem; it seems that this was the problem.
great!
Fwiw, afaik all packages failing to build (their 'all'
Stephan,
Thanks for the pointer.
I've applied the patch and restarted the service. I could recompile
openjdk-8 without problem; it seems that this was the problem.
I'm trying to a couple of rebuilds for packages that failed in the past
(and where the state is not consistent because of this).
Hi Marc,
On Thu, 2020-03-12 at 11:15 +0100, Marc Leeman 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
>
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:
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
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
Could it be that there is some config option that is still wreaking havoc
after having been disabled.
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
So the good news is that it is not something general, ...
No, I've checked it only for amd64
I also had exactly the same issue backporting 1.16.2 from sid :-/
[image: Screenshot from 2020-02-20 14-14-42.png]
On Thu, 20 Feb 2020 at 14:01, Stephan Sürken wrote:
> Hi Marc,
>
> On Wed,
Hi Marc,
On Wed, 2020-02-19 at 12:17 +0100, Marc Leeman wrote:
(...)
> older platforms) and amd64 (current). I've come accross the following
> while backporting GStreamer 1.14.4 from buster to stretch.
just tried it here with no issues.
Ftr, I did a portext to stretch with
Package: mini-buildd
Version: 1.0.36
Severity: important
Dear Maintainer,
I am using mini-buildd to backport packages and to package our own
software into a Debian derived distribution. The distro is both i386 (for
older platforms) and amd64 (current). I've come accross the following
while
11 matches
Mail list logo
