Re: Second Groovy Gorilla test rebuild

2020-10-01 Thread Christian Ehrhardt 
On Tue, Sep 29, 2020 at 11:07 AM Christian Ehrhardt
 wrote:
>
> On Mon, Sep 28, 2020 at 9:39 PM Sebastien Bacher  wrote:
> >
> > Hey Matthias,
> >
> > Le 28/09/2020 à 18:07, Matthias Klose a écrit :
> > > Some build failures on ppc64el and s390x are caused by a buildd issue, 
> > > and will
> > > be retried soonish. Please ignore these where you see a ftbfs just on 
> > > those
> > > architectures, but successes on the other architectures.
> >
> > There seems to be some flakyness on arm as well, are those going to be
> > retried or should that be requested by e.g pinging you?
> >
> > Some examples
> >
> > https://launchpadlibrarian.net/499016257/buildlog_ubuntu-groovy-armhf.colord-gtk_0.2.0-0ubuntu1_BUILDING.txt.gz
> > https://launchpadlibrarian.net/499209776/buildlog_ubuntu-groovy-arm64.gpm_1.20.7-6_BUILDING.txt.gz
> > https://launchpadlibrarian.net/499174464/buildlog_ubuntu-groovy-arm64.remmina_1.4.8+dfsg-1ubuntu1_BUILDING.txt.gz
>
> Adding the same armhf dependency issue on these:
> htop: 
> https://launchpadlibrarian.net/499078378/buildlog_ubuntu-groovy-arm64.htop_3.0.2-1_BUILDING.txt.gz
> openvpn: 
> https://launchpadlibrarian.net/499161991/buildlog_ubuntu-groovy-armhf.openvpn_2.4.9-3ubuntu1_BUILDING.txt.gz
> I see that Laney already filed a bug about that with IS.
>
> Furthermore some armhf issues are due to
> https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1890435
> php7.4: 
> https://launchpadlibrarian.net/499168409/buildlog_ubuntu-groovy-armhf.php7.4_7.4.9-1ubuntu1_BUILDING.txt.gz
>
> When doing an initial triage of some errors I found three sets of
> recurring issues:
> 1. rpc includes like "rpc/rpc.h: No such file"
> 2. better null checking like " -Werror=nonnull" or "directive argument is 
> null"
> 3. linker shows "multiple definitions of"

Just as FYI to save you some debugging, common issue #3 is due to gcc now
defaulting to -fno-common Most of the time that is due to missing "extern"
declarations and the fix is to add them.
This even is the first entry on [1] Porting to GCC 10 page.

But there is one more case which is less clear than missing "extern",
Defines that are meant to be linked together like the following also trigger it:
#define __shared __asm__ ( "_shared_bss" ) __aligned
The fix here is to add back -fcommon for such.

[1]: https://gcc.gnu.org/gcc-10/porting_to.html

> #2 likely comes down to fixing code or disabling the warning for now.
> But for #1 and #3 I think there is a general change and every affected
> package likely will need the similar fix.
> So if someone already debugged those it would be great to let the others know.
>
>
> > Cheers,
> > Sebastien Bacher
> >
> >
> >
> > --
> > ubuntu-devel mailing list
> > ubuntu-devel@lists.ubuntu.com
> > Modify settings or unsubscribe at: 
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
>
>
> --
> Christian Ehrhardt
> Staff Engineer, Ubuntu Server
> Canonical Ltd



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-30 Thread Heather Ellsworth 



On 9/29/20 5:05 AM, Iain Lane wrote:

On Mon, Sep 28, 2020 at 07:13:16PM -0600, Heather Ellsworth wrote:

However, when you install libreoffice-dev, there is still no
/usr/lib/libreoffice/program/{gengal, gengal.bin} in any libreoffice 7.x but
they are present in 6.4.6. Looking into the LO packaging, those files should
definitely be there.

I've opened a bug about this because it will take a bit more investigation
to root cause and fix:

https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1897644


The bug says it, but for the list: this moved to libreoffice-dev-gui at
the same time we moved to LO 7 - a change via Debian.


Ah yes this is true. I was looking at a 6.4 branch of libreoffice on 
accident yesterday.




I took a look at codesearch:

   https://codesearch.debian.net/search?q=gengal=1=1

and it looks like in Debian openclipart is the only victim of this
change.

And that's now fixed in Ubuntu too, so all good I hope.


Thanks so much Iain!

Cheers,
Heather

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-29 Thread Erich Eickmeyer 
On 9/29/2020 4:05 AM, Iain Lane wrote:
> On Mon, Sep 28, 2020 at 07:13:16PM -0600, Heather Ellsworth wrote:
>> However, when you install libreoffice-dev, there is still no
>> /usr/lib/libreoffice/program/{gengal, gengal.bin} in any libreoffice 7.x but
>> they are present in 6.4.6. Looking into the LO packaging, those files should
>> definitely be there.
>>
>> I've opened a bug about this because it will take a bit more investigation
>> to root cause and fix:
>>
>> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1897644
> The bug says it, but for the list: this moved to libreoffice-dev-gui at 
> the same time we moved to LO 7 - a change via Debian.
>
> I took a look at codesearch:
>
>   https://codesearch.debian.net/search?q=gengal=1=1
>
> and it looks like in Debian openclipart is the only victim of this 
> change.
>
> And that's now fixed in Ubuntu too, so all good I hope.
Yep, I uploaded the fix yesterday. :)

-- 
Erich Eickmeyer
Project Leader
Ubuntu Studio



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-29 Thread Andreas Hasenack 
Hello,

On Tue, Sep 29, 2020 at 7:29 AM Christian Ehrhardt
 wrote:
> And we are by pushing glibc2.32 late in groovy we are forcing everything that
> is left to resolve the same now. I'm not sure should glibc provide a compat
> path - I assume this was made so that every project has to make a concious
> switch?

Others (I checked Fedora, and I think gentoo did it too) did the
switch years ago (circa 2018). They have a master bug[1] which might
be worth checking if someone is looking for patches.

> Note, in most cases this include path should be covered by libtirpc 
> pkg-config.
> # pkg-config --cflags libtirpc
> -I/usr/include/tirpc
> But e.g. in the case of open-vm-tools that seems not to be propagated to all
> toolchain calls :-/

I briefly tried building squid's NIS auth helper with tirpc when
trying to sort out its ftbfs[2]. It worked, but for reasons outlined
in the bug[2] and the WIP branch[3] which I didn't propose, I decided
to drop the NIS auth helper. Other than some annoying autoconf issues,
it seemed to work just fine, but I didn't have a real NIS domain to
test.

Of note is that the final binary wasn't directly linked with tirpc,
but pulled it in via libnsl.

1. https://bugzilla.redhat.com/show_bug.cgi?id=1531540
2. https://bugs.launchpad.net/ubuntu/+source/squid/+bug/1895694
3. 
https://code.launchpad.net/~ahasenack/ubuntu/+source/squid/+git/squid/+ref/groovy-squid-use-tirpc

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-29 Thread Iain Lane 
On Mon, Sep 28, 2020 at 07:13:16PM -0600, Heather Ellsworth wrote:
> However, when you install libreoffice-dev, there is still no
> /usr/lib/libreoffice/program/{gengal, gengal.bin} in any libreoffice 7.x but
> they are present in 6.4.6. Looking into the LO packaging, those files should
> definitely be there.
> 
> I've opened a bug about this because it will take a bit more investigation
> to root cause and fix:
> 
> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1897644

The bug says it, but for the list: this moved to libreoffice-dev-gui at 
the same time we moved to LO 7 - a change via Debian.

I took a look at codesearch:

  https://codesearch.debian.net/search?q=gengal=1=1

and it looks like in Debian openclipart is the only victim of this 
change.

And that's now fixed in Ubuntu too, so all good I hope.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-29 Thread Christian Ehrhardt 
On Tue, Sep 29, 2020 at 11:07 AM Christian Ehrhardt
 wrote:
>
> On Mon, Sep 28, 2020 at 9:39 PM Sebastien Bacher  wrote:
> >
> > Hey Matthias,
> >
> > Le 28/09/2020 à 18:07, Matthias Klose a écrit :
> > > Some build failures on ppc64el and s390x are caused by a buildd issue, 
> > > and will
> > > be retried soonish. Please ignore these where you see a ftbfs just on 
> > > those
> > > architectures, but successes on the other architectures.
> >
> > There seems to be some flakyness on arm as well, are those going to be
> > retried or should that be requested by e.g pinging you?
> >
> > Some examples
> >
> > https://launchpadlibrarian.net/499016257/buildlog_ubuntu-groovy-armhf.colord-gtk_0.2.0-0ubuntu1_BUILDING.txt.gz
> > https://launchpadlibrarian.net/499209776/buildlog_ubuntu-groovy-arm64.gpm_1.20.7-6_BUILDING.txt.gz
> > https://launchpadlibrarian.net/499174464/buildlog_ubuntu-groovy-arm64.remmina_1.4.8+dfsg-1ubuntu1_BUILDING.txt.gz
>
> Adding the same armhf dependency issue on these:
> htop: 
> https://launchpadlibrarian.net/499078378/buildlog_ubuntu-groovy-arm64.htop_3.0.2-1_BUILDING.txt.gz
> openvpn: 
> https://launchpadlibrarian.net/499161991/buildlog_ubuntu-groovy-armhf.openvpn_2.4.9-3ubuntu1_BUILDING.txt.gz
> I see that Laney already filed a bug about that with IS.
>
> Furthermore some armhf issues are due to
> https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1890435
> php7.4: 
> https://launchpadlibrarian.net/499168409/buildlog_ubuntu-groovy-armhf.php7.4_7.4.9-1ubuntu1_BUILDING.txt.gz
>
> When doing an initial triage of some errors I found three sets of
> recurring issues:
> 1. rpc includes like "rpc/rpc.h: No such file"

FYI These are broken by libc6-dev dropping rpc.h being taken over by
libtirpc-dev
Paths changed:
Before:
# dpkg -S rpc/types.h rpc/rpc.h
libc6-dev:amd64: /usr/include/rpc/types.h
libc6-dev:amd64: /usr/include/rpc/rpc.h
After:
# dpkg -S rpc/types.h rpc/rpc.h
libtirpc-dev:amd64: /usr/include/tirpc/rpc/types.h
libtirpc-dev:amd64: /usr/include/tirpc/rpc/rpc.h

Ubuntu/Debian build of glibc for a long time had --enable-obsolete-rpc
but that was
now removed upstream and this is the fallout.
Include paths might need to add -I/usr/include/tirpc to resolve correctly.

This already exists in some places:
https://sources.debian.org/src/zsh/5.8-5/configure/?hl=11274#L11274
https://sources.debian.org/src/libquota-perl/1.8.1+dfsg-1/Makef

Not (yet) a problem in Debian because there we are still on 2.31
# dpkg -S rpc/types.h rpc/rpc.h
libc6-dev:amd64: /usr/include/rpc/types.h
libc6-dev:amd64: /usr/include/rpc/rpc.h

And we are by pushing glibc2.32 late in groovy we are forcing everything that
is left to resolve the same now. I'm not sure should glibc provide a compat
path - I assume this was made so that every project has to make a concious
switch?

Note, in most cases this include path should be covered by libtirpc pkg-config.
# pkg-config --cflags libtirpc
-I/usr/include/tirpc
But e.g. in the case of open-vm-tools that seems not to be propagated to all
toolchain calls :-/


> 2. better null checking like " -Werror=nonnull" or "directive argument is 
> null"
> 3. linker shows "multiple definitions of"
>
> #2 likely comes down to fixing code or disabling the warning for now.
> But for #1 and #3 I think there is a general change and every affected
> package likely will need the similar fix.
> So if someone already debugged those it would be great to let the others know.
>
>
> > Cheers,
> > Sebastien Bacher
> >
> >
> >
> > --
> > ubuntu-devel mailing list
> > ubuntu-devel@lists.ubuntu.com
> > Modify settings or unsubscribe at: 
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
>
>
> --
> Christian Ehrhardt
> Staff Engineer, Ubuntu Server
> Canonical Ltd



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-29 Thread Christian Ehrhardt 
On Mon, Sep 28, 2020 at 9:39 PM Sebastien Bacher  wrote:
>
> Hey Matthias,
>
> Le 28/09/2020 à 18:07, Matthias Klose a écrit :
> > Some build failures on ppc64el and s390x are caused by a buildd issue, and 
> > will
> > be retried soonish. Please ignore these where you see a ftbfs just on those
> > architectures, but successes on the other architectures.
>
> There seems to be some flakyness on arm as well, are those going to be
> retried or should that be requested by e.g pinging you?
>
> Some examples
>
> https://launchpadlibrarian.net/499016257/buildlog_ubuntu-groovy-armhf.colord-gtk_0.2.0-0ubuntu1_BUILDING.txt.gz
> https://launchpadlibrarian.net/499209776/buildlog_ubuntu-groovy-arm64.gpm_1.20.7-6_BUILDING.txt.gz
> https://launchpadlibrarian.net/499174464/buildlog_ubuntu-groovy-arm64.remmina_1.4.8+dfsg-1ubuntu1_BUILDING.txt.gz

Adding the same armhf dependency issue on these:
htop: 
https://launchpadlibrarian.net/499078378/buildlog_ubuntu-groovy-arm64.htop_3.0.2-1_BUILDING.txt.gz
openvpn: 
https://launchpadlibrarian.net/499161991/buildlog_ubuntu-groovy-armhf.openvpn_2.4.9-3ubuntu1_BUILDING.txt.gz
I see that Laney already filed a bug about that with IS.

Furthermore some armhf issues are due to
https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1890435
php7.4: 
https://launchpadlibrarian.net/499168409/buildlog_ubuntu-groovy-armhf.php7.4_7.4.9-1ubuntu1_BUILDING.txt.gz

When doing an initial triage of some errors I found three sets of
recurring issues:
1. rpc includes like "rpc/rpc.h: No such file"
2. better null checking like " -Werror=nonnull" or "directive argument is null"
3. linker shows "multiple definitions of"

#2 likely comes down to fixing code or disabling the warning for now.
But for #1 and #3 I think there is a general change and every affected
package likely will need the similar fix.
So if someone already debugged those it would be great to let the others know.


> Cheers,
> Sebastien Bacher
>
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-29 Thread Iain Lane 
On Mon, Sep 28, 2020 at 09:38:55PM +0200, Sebastien Bacher wrote:
> Hey Matthias,
> 
> Le 28/09/2020 à 18:07, Matthias Klose a écrit :
> > Some build failures on ppc64el and s390x are caused by a buildd issue, and 
> > will
> > be retried soonish. Please ignore these where you see a ftbfs just on those
> > architectures, but successes on the other architectures.
> 
> There seems to be some flakyness on arm as well, are those going to be
> retried or should that be requested by e.g pinging you?
> 
> Some examples
> 
> https://launchpadlibrarian.net/499016257/buildlog_ubuntu-groovy-armhf.colord-gtk_0.2.0-0ubuntu1_BUILDING.txt.gz
> https://launchpadlibrarian.net/499209776/buildlog_ubuntu-groovy-arm64.gpm_1.20.7-6_BUILDING.txt.gz
> https://launchpadlibrarian.net/499174464/buildlog_ubuntu-groovy-arm64.remmina_1.4.8+dfsg-1ubuntu1_BUILDING.txt.gz

There appears to be some sort of network glitch that's been going on for 
a few days now. I've filed a request with Canonical IS for them to have 
a look. It's also affecting some CD image builds (or there are two 
problems).

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-29 Thread Heather Ellsworth 

Hi Erich,

> However, openclipart seems to be suffering from an update in
> libreoffice, so I'm hoping someone who maintains libreoffice can give me
> some pointers here as I might be able to fix the package. It seems to be
> looking for /usr/lib/libreoffice/program/gengal and is not finding it,
> so I'm not sure what is going on there.
> 
>
> So, perhaps someone can clue me in on this? If gengal is no longer part
> of libreoffice then, unfortunately, it looks like the openclipart
> package might have to die as well.

I'm working on libreoffice and took a look into this.

Gengal is a utility provided by the libreoffice-dev package, which is 
not installed by default alongside libreoffice-common and friends.


However, when you install libreoffice-dev, there is still no 
/usr/lib/libreoffice/program/{gengal, gengal.bin} in any libreoffice 7.x 
but they are present in 6.4.6. Looking into the LO packaging, those 
files should definitely be there.


I've opened a bug about this because it will take a bit more 
investigation to root cause and fix:


https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1897644


Hope this helps,
Heather



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-28 Thread Colin Watson 
On Mon, Sep 28, 2020 at 06:07:08PM +0200, Matthias Klose wrote:
> Some build failures on ppc64el and s390x are caused by a buildd issue, and 
> will
> be retried soonish. Please ignore these where you see a ftbfs just on those
> architectures, but successes on the other architectures.

This should be fixed now.  I think I've retried most of the affected
builds, though I was doing this manually so it's certainly possible that
I missed some.

-- 
Colin Watson (he/him)  [cjwat...@ubuntu.com]

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-28 Thread Sebastien Bacher 
Hey Matthias,

Le 28/09/2020 à 18:07, Matthias Klose a écrit :
> Some build failures on ppc64el and s390x are caused by a buildd issue, and 
> will
> be retried soonish. Please ignore these where you see a ftbfs just on those
> architectures, but successes on the other architectures.

There seems to be some flakyness on arm as well, are those going to be
retried or should that be requested by e.g pinging you?

Some examples

https://launchpadlibrarian.net/499016257/buildlog_ubuntu-groovy-armhf.colord-gtk_0.2.0-0ubuntu1_BUILDING.txt.gz
https://launchpadlibrarian.net/499209776/buildlog_ubuntu-groovy-arm64.gpm_1.20.7-6_BUILDING.txt.gz
https://launchpadlibrarian.net/499174464/buildlog_ubuntu-groovy-arm64.remmina_1.4.8+dfsg-1ubuntu1_BUILDING.txt.gz

Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

2020-09-28 Thread Erich Eickmeyer 
Hi Matthias,

On 9/28/2020 9:07 AM, Matthias Klose wrote:
> The second test rebuild of Groovy Gorilla was started on September 25 2020 for
> all architectures, all components. The rebuild is finished for the
> main component. It is still running for the universe/multiverse components.
>
> Results (please also look at the superseded builds) can be found at
>
> https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200925-groovy-groovy.html
>
> Some build failures on ppc64el and s390x are caused by a buildd issue, and 
> will
> be retried soonish. Please ignore these where you see a ftbfs just on those
> architectures, but successes on the other architectures.
>
> Additional build failures for packages in groovy-proposed (not yet in groovy)
> can be found at http://qa.ubuntuwire.com/ftbfs/
>
> Please help fixing the build failures.
>
> Matthias

I took a look at the ubuntustudio packageset there and noticed only 3
problematic packages out of the criteria you specified. Two of them
(jamin and petri-foo) are lost to bit rot due to gtk compatibility
issues. Jamin hasn't been worked on by the upstream since 2013 and
petri-foo since 2012. My guess is that these two applications are dead,
so I have no problem letting them go.

However, openclipart seems to be suffering from an update in
libreoffice, so I'm hoping someone who maintains libreoffice can give me
some pointers here as I might be able to fix the package. It seems to be
looking for /usr/lib/libreoffice/program/gengal and is not finding it,
so I'm not sure what is going on there.


So, perhaps someone can clue me in on this? If gengal is no longer part
of libreoffice then, unfortunately, it looks like the openclipart
package might have to die as well.

Thanks,
Erich

-- 
Erich Eickmeyer
Project Leader
Ubuntu Studio



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel