[Reproducible-builds] Bug#809650: linuxdcpp: FTBFS: msgcat: error while opening "build/release/glade/po/glade.pot" for reading
Source: linuxdcpp Version: 1.1.0-1 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, linuxdcpp fails to build from source in unstable/amd64: [..] dcpp/po/sk.po:7: warning: header field 'Language' missing in header Compiling message catalog build/locale/sl/LC_MESSAGES/libdcpp.mo from dcpp/po/sl.po dcpp/po/sl.po:7: warning: header field 'Language-Team' still has the initial default value dcpp/po/sl.po:7: warning: header field 'Language' missing in header Compiling message catalog build/locale/sq/LC_MESSAGES/libdcpp.mo from dcpp/po/sq.po dcpp/po/sq.po:7: warning: header field 'Language-Team' still has the initial default value dcpp/po/sq.po:7: warning: header field 'Language' missing in header Compiling message catalog build/locale/sr/LC_MESSAGES/libdcpp.mo from dcpp/po/sr.po dcpp/po/sr.po:7: warning: header field 'Language' missing in header Compiling message catalog build/locale/sv/LC_MESSAGES/libdcpp.mo from dcpp/po/sv.po dcpp/po/sv.po:7: warning: header field 'Language' missing in header Compiling message catalog build/locale/sv/LC_MESSAGES/linuxdcpp.mo from po/sv.po po/sv.po:7: warning: header field 'Language' missing in header Compiling message catalog build/locale/tr/LC_MESSAGES/libdcpp.mo from dcpp/po/tr.po dcpp/po/tr.po:7: warning: header field 'Language-Team' still has the initial default value dcpp/po/tr.po:7: warning: header field 'Language' missing in header Compiling message catalog build/locale/uk/LC_MESSAGES/libdcpp.mo from dcpp/po/uk.po dcpp/po/uk.po:7: warning: header field 'Language-Team' still has the initial default value dcpp/po/uk.po:7: warning: header field 'Language' missing in header Compiling message catalog build/locale/zh_CN/LC_MESSAGES/libdcpp.mo from dcpp/po/zh_CN.po dcpp/po/zh_CN.po:7: warning: header field 'Language' missing in header Compiling message catalog build/locale/zh_TW/LC_MESSAGES/libdcpp.mo from dcpp/po/zh_TW.po dcpp/po/zh_TW.po:7: warning: header field 'Language-Team' still has the initial default value dcpp/po/zh_TW.po:7: warning: header field 'Language' missing in header Extracting messages to build/release/glade/po/glade.pot from glade/downloadqueue.glade glade/favoritehubs.glade glade/favoriteusers.glade glade/finishedtransfers.glade glade/hash.glade glade/hub.glade glade/mainwindow.glade glade/privatemessage.glade glade/publichubs.glade glade/search.glade glade/settingsdialog.glade glade/sharebrowser.glade glade/transfers.glade xgettext: warning: file 'glade/downloadqueue.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/favoritehubs.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/favoriteusers.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/finishedtransfers.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/hash.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/hub.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/mainwindow.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/privatemessage.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/publichubs.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/search.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/settingsdialog.glade' extension 'glade' is unknown; will try C glade/settingsdialog.glade:483: warning: unterminated character constant glade/settingsdialog.glade:3861: warning: unterminated character constant xgettext: warning: file 'glade/sharebrowser.glade' extension 'glade' is unknown; will try C xgettext: warning: file 'glade/transfers.glade' extension 'glade' is unknown; will try C Extracting messages to build/release/gui/po/linux.pot from linux/UserCommandMenu.cc linux/WulforUtil.cc linux/bookentry.cc linux/dialogentry.cc linux/downloadqueue.cc linux/entry.cc linux/favoritehubs.cc linux/favoriteusers.cc linux/finishedtransfers.cc linux/hashdialog.cc linux/hub.cc linux/mainwindow.cc linux/privatemessage.cc linux/publichubs.cc linux/search.cc linux/settingsdialog.cc linux/settingsmanager.cc linux/sharebrowser.cc linux/transfers.cc linux/treeview.cc linux/wulfor.cc linux/wulformanager.cc linux/IntlUtil.hh linux/UserCommandMenu.hh linux/WulforUtil.hh linux/bookentry.hh linux/dialogentry.hh linux/downloadqueue.hh linux/entry.hh linux/favoritehubs.hh linux/favoriteusers.hh linux/finishedtransfers.hh linux/func.hh linux/hashdialog.hh linux/hub.hh linux/mainwindow.hh linux/privatemessage.hh linux/publichubs.hh linux/search.hh linux/settingsdialog.hh linux/settingsmanager.hh linux/sharebrowser.hh linux/transfers.hh linux/treeview.hh
[Reproducible-builds] koji 1.10.0-1 MIGRATED to testing
FYI: The status of the koji source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 1.10.0-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Cross-building across architectures (reproducibly?)
Steven Chamberlain wrote: > using Helmut's tool, I've been able to rebootstrap a minimal Debian > linux-i386 chroot (445 binary packages[3]). These were cross-compiled > from source, by only running kfreebsd-amd64 binaries on a FreeBSD > kernel, and having some Arch:all packages installed. I've begun to analyze this now, using diffoscope to compare a stage1 debootstrapped chroot of linux-i386, from official Debian packages vs. my cross-built ones from kfreebsd-amd64. Unfortunately all the ELF binaries have differences, but most other files' contents are reproducible. The biggest problem was that the cross toolchain's linker used a different target ABI: │ │ │ -OS: Linux, ABI: 3.2.0 │ │ │ +OS: Linux, ABI: 2.6.32 and that leads to huge differences in the output binaries, such as not using .init_array/.fini_array sections. That may have consequences, such as if reproducible.debian.net jobs ever override uname to 2.6.x (Bug #806911), we may run into this problem there. umasks are applied to symlinks differently on kfreebsd than on linux: │ │ -lrwxrwxrwx root/root 0 2015-10-28 22:29:08 ./etc/os-release -> ../usr/lib/os-release │ │ +lrwxr-xr-x root/root 0 2015-10-28 22:29:08 ./etc/os-release -> ../usr/lib/os-release base-files seems to look at uname of the build architecture, rather than host arch it is building for: │ ├── ./usr/lib/os-release │ │ @@ -1,6 +1,6 @@ │ │ -PRETTY_NAME="Debian GNU/Linux stretch/sid" │ │ -NAME="Debian GNU/Linux" │ │ +PRETTY_NAME="Debian GNU/kFreeBSD stretch/sid" │ │ +NAME="Debian GNU/kFreeBSD" gzip embeds the version of a build-dependency, makeinfo. That's slightly annoying; it creates differences where there needn't have been otherwise: │ ├── ./usr/share/info/gzip.info.gz │ │ ├── gzip.info │ │ │ @@ -1,2827 +1,2827 @@ │ │ │ : 5468 6973 2069 7320 677a 6970 2e69 6e66 This is gzip.inf │ │ │ 0010: 6f2c 2070 726f 6475 6365 6420 6279 206d o, produced by m │ │ │ 0020: 616b 6569 6e66 6f20 7665 7273 696f 6e20 akeinfo version │ │ │ -0030: 352e 3220 6672 6f6d 2067 7a69 702e 7465 5.2 from gzip.te │ │ │ +0030: 362e 3020 6672 6f6d 2067 7a69 702e 7465 6.0 from gzip.te │ │ │ 0040: 7869 2e0a 0a54 6869 7320 6d61 6e75 616c xi Then I saw some some reproducibility issues that are already known (#774425 in dash, #806328 in xz-utils). Here are my chroots and diffoscope output, in case anyone is curious: http://kfreebsd.eu/rebootstrap/2016010100/native.tar.xz (12MiB) http://kfreebsd.eu/rebootstrap/2016010100/rebootstrap.tar.xz (12MiB) http://kfreebsd.eu/rebootstrap/2016010100/diff.xz (6MiB) Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Cross-building across architectures (reproducibly?)
Hi Steven, On Sat, Jan 02, 2016 at 09:03:21PM +, Steven Chamberlain wrote: > I've begun to analyze this now, using diffoscope to compare a stage1 > debootstrapped chroot of linux-i386, from official Debian packages vs. > my cross-built ones from kfreebsd-amd64. Note that there are public jenkins jobs for a very similar task already. On https://jenkins.debian.net/view/rebootstrap/ the "*_diffoscope" jobs do compare the cross build packages to the archive versions. The resulting text diffs are embedded into the build logs, so apart from the missing cross kernel part (because kfreebsd-any doesn't cover release architectures atm and jenkins.d.n doesn't have any kfreebsd-any slaves), we do get these diffs for almost a year already. > Unfortunately all the ELF binaries have differences, but most other > files' contents are reproducible. There are lots of reasons for these differences. The top reasons most likely are: * Different gcc version * Different build path (and thus different build ids) * Different configure check results due to cross compilation > The biggest problem was that the cross toolchain's linker used a > different target ABI: > > ??? ??? ??? -OS: Linux, ABI: 3.2.0 > ??? ??? ??? +OS: Linux, ABI: 2.6.32 > > and that leads to huge differences in the output binaries, such as not > using .init_array/.fini_array sections. This is surprising as glibc explicitly requests 3.2 via --enable-kernel. I also cannot confirm this in the (linux-only) diffoscope logs mentioned above. There all the cross built packages use the 3.2 ABI. Maybe some configure check went wrong here? In general, wrong configure results are a big problem to cross compilation and are the main reason why I added support for running diffoscope early. Some wrong checks simply make the build fail, but many go unnoticed until you diff the binary. The root cause is that autotools tends to be pessimistic rather than optimistic. When you cross build and a particular check cannot be run, autotools tends to assume the worst possible outcome. To solve this, we need an organized way to preseed these check results to configure scripts. Currently, some check results are bundled into dpkg-cross (not in jessie or stretch), but ideally these would be distributed to the packages that are being checked (e.g. glibc when you test whether malloc(0) returns NULL). While my focus has been on making cross building work at all, I welcome and support efforts to make it reproducible as well. You can find interesting pieces in the rebootstrap_*_diffoscope jobs today for packages like libtool, nettle-dev, bash, libfreetype6-dev, libexpat1-dev, libicu-dev, libxml2-dev and libdebian-installer4-dev. Please Cc me in your replies. Helmut ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
