Re: LFS_CFLAGS on 32bits architectures
Hi Andreas, On Mon, May 30, 2022 at 02:16:59PM +, Andreas Hasenack wrote: > on a pi3 (armhf): > $ getconf LFS_CFLAGS > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > This only returns a value where it's needed, aka, 32bits (AFAIK). > Shouldn't this be part of our default set of CFLAGS on 32bits architectures? In principle, yes. The problem is, it is ABI-breaking to add this to the default set of CFLAGS on an architecture after it has been bootstrapped. There are libraries which expose either C/Linux types or their own types in function prototypes, where those types are of different sizes depending on the LFS defines in use. IIRC a classic example of this is zlib. So because i386 and armhf (and likewise all other 32-bit Debian architectures to date) have been bootstrapped without LFS_CFLAGS exported to dpkg-buildflags by default, we can't add it now without introducing forced ABI changes on an indeterminate number of libraries. Those libraries SHOULD all be made to transition to LFS_CFLAGS, but we have to know which libraries have their ABIs changing and plan transitions for them rather than just flipping the switch. If someone were able to do the necessary static analysis over the archive to identify all of the affected libraries, then I think there's a strong case to be made that we should do them all at once and then change the default flags, because that would then fix the problem for any new libraries that are introduced in the future. FYI this issue is mentioned in the dpkg-buildflags manpage: FEATURE AREAS [...] future Several compile-time options (detailed below) can be used to enable features that should be enabled by default, but cannot due to backwards compatibility reasons. lfs This setting (disabled by default) enables Large File Support on 32-bit architectures where their ABI does not include LFS by default, by adding -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to CPPFLAGS. > I experimented a few things, and this got it building again: > --- a/debian/rules > +++ b/debian/rules > @@ -10,6 +10,10 @@ export DH_GOLANG_INSTALL_ALL := 1 > # Skip integration tests when building package: they need docker images. > export ADSYS_SKIP_INTEGRATION_TESTS=1 > > +# be sure to set LFS_CFLAGS if needed, required for libsmbclient on 32bits > +CGO_CFLAGS := $(shell getconf LFS_CFLAGS) > +export CGO_CFLAGS > + > %: > dh $@ --buildsystem=golang --with=golang,apport Would be interesting to know if 'export DEB_BUILD_MAINT_OPTIONS=future=+lfs' also fixed the build, as conceptually that's the same level of abstraction as fixing dpkg-buildflags per the above. > I'm trying a rebuild of all reverse dependencies of libsmbclient to > see if there are any other failures, but I am wondering if this is the > current approach we want to take, or revert to our old-and-tried patch > that just defines it for all apps including libsmbclient.h? I think that if there's a solution that doesn't require patching upstream samba, while guarding against miscompilation of either libraries or their consumers and avoiding accidentally introducing any ABI changes, we should prefer that. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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: +1 maintenance report
On Mon, May 30, 2022 at 09:38:33AM -0300, Lucas Kanashiro wrote: > Hi, > > Last week was my +1 maintenance shift, this time I decided to try to unblock > packages stuck in -proposed for too long (bottom of the excuses page). Below > you can find a summary of what I did: > > # debos > > Revisit this package and submitted a patch to implement the solution vorlon > brought up in the discussion (introducing some delta): > > https://bugs.launchpad.net/ubuntu/+source/debos/+bug/1940077 > > Package uploaded and added a comment to the Debian bug about it. > > # ruby-parallel > > Gave it a shot with the latest upstream release and I was not able to > reproduce > the autopkgtest failure anymore. Uploaded version 1.22.1-1 to Debian. It was > synced but it is still failing, and needs further investigation. I tested this locally with the qemu backend and it passed, on amd64, after adding more processors and RAM. Subsequently, I added it to big_packages for all arches except armhf. I'll also retry the tests. Cheers, -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Core Dev application
On Wed, May 18, 2022 at 03:25:27AM -0700, Simon Chopin wrote: > I'm hereby applying for the Core Dev membership. In today's meeting the DMB voted to add Simon to ~ubuntu-core-dev. Congratulations, Simon! On behalf of the DMB, Robie 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: +1 Maintenance report 23-27 May 2022
And I forgot to mention: astroquery I added a patch to fix the permission denied on accessing files here : https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+sourcepub/13638113/+listing-archive-extra But then autopkgtest fails on armhf https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic-alexghiti-riscv/kinetic/armhf/a/astroquery/20220525_104624_1622f@/log.gz There is no obvious reason in the link above but when launched locally, the error was not the same and may be more helpful: vals = ['9048843364125'] def generic_converter(vals): > return numpy.array(vals, numpy_type) E OverflowError: Python int too large to convert to C long /usr/lib/python3/dist-packages/astropy/io/ascii/core.py:1004: OverflowError I won't have time to follow up on this though. Thanks, Alex On Mon, May 30, 2022 at 11:54 AM Alexandre Ghiti < alexandre.gh...@canonical.com> wrote: > Hi, > > I was on +1 maintenance last week, below what I worked on: > > netdata > == > > It was a simple sync since Debian merged the patch that I had added > previously. This was uploaded by @Graham Inggs . > > node-gulp-coffee > = > > node-gulp-coffee timeouts on tests on arm64 only, I increased the timeout > and the tests passed. This was uploaded by @Graham Inggs . > > libgpg-error > = > > It regressed on i386 because debian removed the test directive > "skip-not-installable". Indeed, Ubuntu i386 autopkgtest runners actually > run on amd64 and use multi-arch which then used to trigger amd64 tests on > for i386 builds which then failed. This was fixed by @Lukas Märdian here > https://bugs.launchpad.net/ubuntu/+source/libgpg-error/+bug/1975673. But > as explained in the bug report, the i386 test still fails: this is because > autopkgtest tries to install gcc-mingw-w64-i686:i386 which does not exist, > gcc-mingw-w64-i686:all does though. Either a fix is needed in autopkgtest > in order to fallback to :all when :$arch does not, or I was told that this > package could be missing Multi-Arch: foreign field. *Anyway, I'm still > working on this.* > > aqsis > > > aqsis FTBFS on armhf because Debian had support for qt5 and armhf qt5 > libraries lack support for some OpenGL functions: indeed, armhf qt5 > libraries use the OpenGL ES 2.0 mode > (qtbase-opensource-src-5.15.4+dfsg/debian/rules), which is only a subset of > OpenGL 2.0 and does not contain the missing functions ( > https://www.khronos.org/registry/OpenGL/specs/es/2.0/es_cm_spec_2.0.pdf). > And it regressed on i386 because the last build for this arch was removed > from release: I added a Britney hint to make it pass (Thanks @Graham Inggs > for this). > > This was uploaded by @Graham Inggs . > > dropbear > === > > dropbear regressed on all archs because of the following issues: > > - mkdir fail because ~/.ssh already exists => use mkdir -p > - tests find the installed kernel by matching kernel packages suffixed by > -$arch (like Debian does) whereas in Ubuntu they are suffixed by -generic > - mmdebstrap fails because the sources.list was grepped against 'Origin: > Debian' => change that for 'Origin: Ubuntu' > > The package built successfully in my PPA and I locally validated that > autopkgtest passes on amd64 but I had to increase the memory size of the > VM, I'll add this package to big_packages too. @Graham Inggs > just told me that autopkgtest failed on > armhf for another reason, I'll fix that and ask for uploading: *I'm still > working on this*. > > That's it, > > Thanks, > > Alex > > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
LFS_CFLAGS on 32bits architectures
Hi,
on a pi3 (armhf):
$ getconf LFS_CFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
This only returns a value where it's needed, aka, 32bits (AFAIK).
Shouldn't this be part of our default set of CFLAGS on 32bits architectures?
The reason I ask is this old samba bug[1] ("64bits prototype not
precised")], which iterated over a few fixes:
- force-refine _LARGEFILE64_SOURCE and _FILE_OFFSET_BIGS in
libsmbclient.h[2] (it's been like this since 2011 in the package)
- it was replaced with [3], which uses a `static_assert(sizeof(off_t)
>= 8` check and fails the build on 32bit without LFS
- then it was replaced again with [4], which uses this one liner:
`typedef int
smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS[sizeof(off_t)-7];`,
which also fails the build because it becomes a very large array on
32bits if off_t is not 64bits.
In Ubuntu builds, only the first original patch was ever used. The
other iterations happened in debian unstable and I encountered them
while starting a new merge from debian for the kinetic cycle.
So far, only adsys is failing to build:
# github.com/ubuntu/adsys/vendor/github.com/mvo5/libsmbclient-go
In file included from
src/github.com/ubuntu/adsys/vendor/github.com/mvo5/libsmbclient-go/libsmbclient.go:17:
/usr/include/samba-4.0/libsmbclient.h:84:13: error: size of array
'smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS' is too large
84 | typedef int
smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS[sizeof(off_t)-7];
| ^~~
I experimented a few things, and this got it building again:
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,10 @@ export DH_GOLANG_INSTALL_ALL := 1
# Skip integration tests when building package: they need docker images.
export ADSYS_SKIP_INTEGRATION_TESTS=1
+# be sure to set LFS_CFLAGS if needed, required for libsmbclient on 32bits
+CGO_CFLAGS := $(shell getconf LFS_CFLAGS)
+export CGO_CFLAGS
+
%:
dh $@ --buildsystem=golang --with=golang,apport
I'm trying a rebuild of all reverse dependencies of libsmbclient to
see if there are any other failures, but I am wondering if this is the
current approach we want to take, or revert to our old-and-tried patch
that just defines it for all apps including libsmbclient.h?
1. http://bugs.debian.org/221618
2.
https://git.launchpad.net/ubuntu/+source/samba/tree/debian/patches/bug_221618_precise-64bit-prototype.patch?h=import/2%254.13.2%2bdfsg-1
3.
https://salsa.debian.org/samba-team/samba/-/blob/b141e7178961404a9f9cca92d04e780c5f504878/debian/patches/libsmbclient-ensure-lfs-221618.patch
4.
https://salsa.debian.org/samba-team/samba/-/blob/d0d8db5c6d6e8b5e26944031f6786031c1a389ca/debian/patches/libsmbclient-ensure-lfs-221618.patch
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance report
Hi, Last week was my +1 maintenance shift, this time I decided to try to unblock packages stuck in -proposed for too long (bottom of the excuses page). Below you can find a summary of what I did: # debos Revisit this package and submitted a patch to implement the solution vorlon brought up in the discussion (introducing some delta): https://bugs.launchpad.net/ubuntu/+source/debos/+bug/1940077 Package uploaded and added a comment to the Debian bug about it. # ruby-parallel Gave it a shot with the latest upstream release and I was not able to reproduce the autopkgtest failure anymore. Uploaded version 1.22.1-1 to Debian. It was synced but it is still failing, and needs further investigation. # ruby-tty-screen Filed an upstream bug report to fix tests in s390x: https://github.com/piotrmurach/tty-screen/issues/14 Once this is fixed it will also unblock ruby-tty-reader and ruby-tty-prompt. # redmine Fixed FTBFS via ruby-rack. # ruby-rack Synced version 2.2.3-4 from Debian. The Ubuntu delta was merged into Debian and this was impacting the redmine FTBFS. # python-omegaconf It builds fine in a local kinetic chroot. In LP it cannot satisfy the pytest-runner dependency, not sure yet why. # xdg-utils-cxx The symbols file needed an update. Sent a patch to Debian here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004109 I did not add a delta, let's see if Debian can sort this out soon. # ruby-omniauth-ultraauth Fixed the following bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995411 It finally migrated to the release pocket. ruby-omniauth-openid-connect should migrate soon as well. # libdancer2-plugin-passphrase-perl Filed a bug to remove it from kinetic: https://bugs.launchpad.net/ubuntu/+source/libdancer2-plugin-passphrase-perl/+bug/1975868 This is a leaf package blocking libdigest-bcrypt-perl for more than 120 days, and it is also blocked in Debian unstable for more than 765 days. # puppet There is an issue with the latest update of puppet trying to make it work with ruby 3 (upstream moved to a new major version which supports ruby 3 but we can't right now due to its dependencies). https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1969939 This is still ongoing. I'll spend more time this week on this to see if I can come up with a patch. Lucas Kanashiro. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 Maintenance report 23-27 May 2022
Hi, I was on +1 maintenance last week, below what I worked on: netdata == It was a simple sync since Debian merged the patch that I had added previously. This was uploaded by @Graham Inggs . node-gulp-coffee = node-gulp-coffee timeouts on tests on arm64 only, I increased the timeout and the tests passed. This was uploaded by @Graham Inggs . libgpg-error = It regressed on i386 because debian removed the test directive "skip-not-installable". Indeed, Ubuntu i386 autopkgtest runners actually run on amd64 and use multi-arch which then used to trigger amd64 tests on for i386 builds which then failed. This was fixed by @Lukas Märdian here https://bugs.launchpad.net/ubuntu/+source/libgpg-error/+bug/1975673. But as explained in the bug report, the i386 test still fails: this is because autopkgtest tries to install gcc-mingw-w64-i686:i386 which does not exist, gcc-mingw-w64-i686:all does though. Either a fix is needed in autopkgtest in order to fallback to :all when :$arch does not, or I was told that this package could be missing Multi-Arch: foreign field. *Anyway, I'm still working on this.* aqsis aqsis FTBFS on armhf because Debian had support for qt5 and armhf qt5 libraries lack support for some OpenGL functions: indeed, armhf qt5 libraries use the OpenGL ES 2.0 mode (qtbase-opensource-src-5.15.4+dfsg/debian/rules), which is only a subset of OpenGL 2.0 and does not contain the missing functions ( https://www.khronos.org/registry/OpenGL/specs/es/2.0/es_cm_spec_2.0.pdf). And it regressed on i386 because the last build for this arch was removed from release: I added a Britney hint to make it pass (Thanks @Graham Inggs for this). This was uploaded by @Graham Inggs . dropbear === dropbear regressed on all archs because of the following issues: - mkdir fail because ~/.ssh already exists => use mkdir -p - tests find the installed kernel by matching kernel packages suffixed by -$arch (like Debian does) whereas in Ubuntu they are suffixed by -generic - mmdebstrap fails because the sources.list was grepped against 'Origin: Debian' => change that for 'Origin: Ubuntu' The package built successfully in my PPA and I locally validated that autopkgtest passes on amd64 but I had to increase the memory size of the VM, I'll add this package to big_packages too. @Graham Inggs just told me that autopkgtest failed on armhf for another reason, I'll fix that and ask for uploading: *I'm still working on this*. That's it, Thanks, Alex -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
