Re: Bug#932258: console-setup-freebsd: missing dependency
On 17 Jul 2019, at 10:55, Holger Wansing wrote: > > Hi, > > Cyril Brulebois wrote: >> Héctor Orón Martínez (2019-07-17): >>> Package: console-setup-freebsd >>> Version: 1.191 >>> Severity: grave >>> >>> >>> Dear Maintainer, >>> >>> console-setup-freebsd has a dependency on vidcontrol, which is not >>> part of buster|bullseye|unstable, and causes the package to be >>> uninstallable. >> >> Adding debian-bsd@ to the loop for advise. > > The same counts for kbdcontrol, also not existing in all suites. vidcontrol, and the rest of src:freebsd-utils, is available in unreleased, since the source package only builds for kfreebsd-amd64 and kfreebsd-i386. Avoiding this would require either getting the source package to build on Linux architectures, or building at least one arch:all package, neither of which seem to have much point to them. As an architecture on Debian Ports, it is expected that you also have the "unreleased" suite enabled, as is clearly documented on the main site[1]. This is especially important on kFreeBSD, since bin:freebsd-utils is Essential, containing many of the core utilities required for a functioning system. All ports buildds should have unreleased available, and debian-installer learnt over 2 years ago to include unreleased when downloading udebs. Thus, I consider this not a bug; as much as we would like it to not be, as far as Debian Ports goes, unreleased is a necessary addition to unstable, with cases like these stemming from the fact that ftp-master does not allow sources to exist that don't build packages for any of its architectures. James [1] https://www.ports.debian.org/archive
Re: FTBFS on kfreebsd-* due to test-suite failures
On 2 Jul 2019, at 20:15, Michael Biebl wrote: > > Hi James > > Am 02.07.19 um 20:55 schrieb James Clarke: >> Control: reopen -1 >> >>> On 2 Jul 2019, at 19:53, Michael Biebl wrote: >>> >>> On Tue, 12 May 2015 13:38:12 +0200 Michael Biebl wrote: >>>> Source: rsyslog >>>> Version: 8.9.0-3 >>>> Severity: important >>>> User: debian-bsd@lists.debian.org >>>> Usertags: kfreebsd >>>> >>>> As can be seen at [1] or [2], rsyslog failed reliably on the kfreebsd-* >>>> buildds due to failures in the test-suite: >>>> >>>> There are 17 failed tests. It would be great to have help from the >>>> kfreebsd porting to get those fixed. >>>> >>>> Thanks, >>>> Michael >>>> >>>> >>>> [1] >>>> https://buildd.debian.org/status/logs.php?pkg=rsyslog&arch=kfreebsd-amd64 >>>> [2] >>>> https://buildd.debian.org/status/logs.php?pkg=rsyslog&arch=kfreebsd-i386 >>>> >>> >>> >>> Since there was not a single response from the kfreebsd porters on this >>> issue, I don't think it's useful to keep this bug report open any longer. >> >> It's still a bug that exists and thus should remain open until it is fixed or >> kFreeBSD no longer exists. I just have more important issues to fix on >> kFreeBSD >> right now. > > Don't you think 4 years is long enough to wait? Even if it were 100 years that wouldn't make the bug suddenly go away on its own. The bug was filed post-Jessie at a time when attention to the port was decreasing, and I was not a member of the team for most of that period. I do want to fix the bug, but nocheck builds do work in practice and I keep finding other things to fix. > I'm not sure even if that bug still applies today. Yes, it still does[1,2]. Down to FAIL: 10 (7 in experimental), but still non-zero. James [1] https://buildd.debian.org/status/package.php?p=rsyslog&suite=sid [2] https://buildd.debian.org/status/package.php?p=rsyslog&suite=experimental
Re: FTBFS on kfreebsd-* due to test-suite failures
Control: reopen -1 > On 2 Jul 2019, at 19:53, Michael Biebl wrote: > > On Tue, 12 May 2015 13:38:12 +0200 Michael Biebl wrote: >> Source: rsyslog >> Version: 8.9.0-3 >> Severity: important >> User: debian-bsd@lists.debian.org >> Usertags: kfreebsd >> >> As can be seen at [1] or [2], rsyslog failed reliably on the kfreebsd-* >> buildds due to failures in the test-suite: >> >> There are 17 failed tests. It would be great to have help from the >> kfreebsd porting to get those fixed. >> >> Thanks, >> Michael >> >> >> [1] https://buildd.debian.org/status/logs.php?pkg=rsyslog&arch=kfreebsd-amd64 >> [2] https://buildd.debian.org/status/logs.php?pkg=rsyslog&arch=kfreebsd-i386 >> > > > Since there was not a single response from the kfreebsd porters on this > issue, I don't think it's useful to keep this bug report open any longer. It's still a bug that exists and thus should remain open until it is fixed or kFreeBSD no longer exists. I just have more important issues to fix on kFreeBSD right now. James
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 14 Apr 2019, at 14:14, Samuel Thibault wrote: > Svante Signell, le dim. 14 avril 2019 14:29:48 +0200, a ecrit: >> On Sun, 2019-04-14 at 11:33 +0200, Samuel Thibault wrote: >>> Svante Signell, le dim. 14 avril 2019 10:52:19 +0200, a ecrit: I cannot follow your reasoning here, e.g. at http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/g/glibc/ there are no source packages, only binary ones. How would I ever get hold of your source changes to build that version of glibc? >>> >>> That version of glibc is in the "unreleased" distribution, not >>> "unstable". See the main/binary-hurd-i386/Packages.gz files of the >>> different distribs: >>> >>> http://ftp.ports.debian.org/debian-ports/dists/ >> >> Yes, the glibc version is there, but where are the sources, i.e. >> the *2.27.orig.tar.*, *2.27-8+hurd.1.debian.tar.* and *2.27- >> 8+hurd.1.dsc files? > > They were not uploaded at the time. I don't know if the current > debian-port upload queue can now take them for the unreleased distrib. Yes, it can, has done for as long as I've been around (though admittedly that's only a few years). The Sources file remains empty, but the .dsc etc get put in the pool alongside the .deb; see, for example silo[1]. One day I (or someone else) will finish dak-for-ports so we can have non-empty Sources files and use deb-src, among other things... James [1] https://ftp.ports.debian.org/debian-ports/pool-sparc64/main/s/silo/
Re: Bug#924390: kfreebsd mount missing libbsd.so.0 -> it is not installed.
Control: tags -1 moreinfo On Tue, Mar 12, 2019 at 01:23:53PM +0100, Thomas Schweikle wrote: > Package: kfreeBSD-kernel This package doesn't exist. If you insist on not using reportbug, please do ensure that you file against a valid package. However, in this case, I don't actually know where in the stack this bug report belongs, in part because I don't understand how it could possibly arise (as described below). > Booting Debian GNU/kfreeBSD fails because mount does not find > libbsd.so.0 and mount not build as static or libbsd.so.0 not part of > boot filesystem. So, I'm extremely confused as to why you are having an issue, and it's not helped by the fact that you have not provided any kind of log file. Please provide one (or some form of error mesage that you get, with context). The reasons why I don't understand how this is happening are as follows: 1. There is no initrd/initramfs on GNU/kFreeBSD; the root that gets mounted is your real root file system. 2. This root file system gets mounted RW during boot, as configured by GRUB, so there should be no need to use a mount binary other than much later in boot for other filesystems (the root gets mounted directly by the kernel since there is not yet a root). 3. The mount binary itself comes from freebsd-utils, which Depends on libbsd0, thus pulling in libbsd.so.0 So, really, it's a mystery to me how on earth you're having issues with a missing libbsd.so.0 that also breaks mounting the root filesystem; none of that should matter. > Any idea on how to recover? Given I have no idea what your error actually is, I can't possibly hope to tell you how to work around it. Regards, James
Bug#923197: protobuf: Enable and fix for !linux
Source: protobuf Version: 3.6.1-3 X-Debbugs-Cc: debian-bsd@lists.debian.org, debian-h...@lists.debian.org Hi, For some reason, the "solution" for #837310 was to restrict protobuf to build only on Linux architectures. That doesn't solve anything other than remove the red on the buildd.d.o pages. Lots of packages out there need protobuf to build. Please reinstate the architecture list as Architecture: any immediately, as this is not a valid reason to restrict the architecture list, and either debug the issue yourself on a porterbox or let somebody else do it. Architecture: foo (where foo is neither any nor all) should *only* be used when a package has large quantities of architecture-specific code and porting it would be a serious undertaking (generally kernels, compilers and low-level system libraries). As a porter it is far more useful to have packages like this in Build-Attempted/Failed than in Not-For-Us, since the latter are far less visible at a glance. I also see no attempt to contact either the GNU/Hurd or GNU/kFreeBSD porters. James
New GNU/kFreeBSD Porterbox
Hi, We have set up a new GNU/kFreeBSD porterbox, lemon.debian.net[0], kindly hosted by Gurkan Myczko, available to all DDs. The machine is set up to closely mirror many aspects of the standard Debian porterboxes, so you can use the usual dd-schroot-cmd workflow as described on the DSA website[1]. Both kfreebsd-amd64 and kfreebsd-i386 schroots are provided. As with all porterboxes, this machine should be used to debug issues, and not to perform binary uploads to the archive in place of the build daemons. If you have any issues or questions, please feel free to contact me on IRC (#debian-kbsd) or via email. Thanks for your future porting efforts! Regards, James [0] https://db.debian.org/machines.cgi?host=lemon [1] https://dsa.debian.org/doc/schroot/
Re: Please binNMU/RM a handfull packages on kfreebsd-* and hurd
On 19 Dec 2018, at 22:28, Sebastian Andrzej Siewior wrote: > > Hi, > > looking at the cruft-report for curl there is this: > > |* source package curl version 7.62.0-1 no longer builds > | binary package(s): libcurl3 > | - broken Depends: > [...] > > I didn't check all packages but some the reason why it still > links/depends on libcurl3 is: > - missing binNMU (uget) > - built against old curl while every one else built against the newer > one (boinc) > - built old version against old curl but can't build new version because > it is BD-Uninstallable (gmic, openalpr) Thanks, I've set up a tracker[1] so this doesn't get lost and will take a proper look at kfreebsd-* when I have the chance (other list members with wanna-build access are of course more than welcome to help!). James [1] https://ben.jrtc27.com/html/ports-curl.html
Re: Bug#912521: perl: 5.28 FTBFS on kfreebsd: test failures
> On 31 Oct 2018, at 22:38, Niko Tyni wrote: > > Source: perl > Version: 5.28.0-3 > Severity: important > X-Debbugs-Cc: debian-bsd@lists.debian.org > Tags: ftbfs > > This package failed to build on kfreebsd-amd64. > > > https://buildd.debian.org/status/fetch.php?pkg=perl&arch=kfreebsd-amd64&ver=5.28.0-3&stamp=1541024336&raw=0 > > Failed 3 tests out of 2544, 99.88% okay. > ../dist/Time-HiRes/t/utime.t > ../lib/File/Copy.t > run/switches.t > > Copying the debian-bsd list. Could you please investigate? > > The timing with the Perl 5.28 transition starting today is unfortunate; > I didn't notice that the kfreebsd experimental buildds finally got > around to trying perl a couple of days ago so I wasn't aware of these > failures. > > You (as in debian-bsd@) might want to consider uploading 5.28.0-3 > binaries built with DEB_BUILD_OPTIONS=nocheck or something for now to > get the transition binNMUs. But you probably know better than me how > all that stuff works. Hi Niko, I did this two weeks ago, but it turns out one of the failures (run/switches.t) is important, as it reveals that `perl -pi -e ... /tmp/foo` is broken, which in turn causes r-base-core's postinst to fail. I've tracked this down and sent a patch upstream[1]; could you please apply this to the packaging? Thanks, James [1] https://rt.perl.org/Ticket/Display.html?id=133668
Re: Request for kFreeBSD (and Hurd) porters
Hi Steven, Glad to see you back on the mailing list! On Mon, Jul 30, 2018 at 10:19 AM, Svante Signell wrote: > On Mon, 2018-07-30 at 09:17 +0100, Steven Chamberlain wrote: >> Hi, >> >> Svante Signell wrote: >> > The Debian GNU/kFreeBSD port recently obtained a buildd building >> > packages for the sid distribution, kamp. Thank you very much for >> > your effort making this happening jrtc27 :) >> >> Thanks very much for this James! It was a really nice surprise to >> see packages building again. > > :) > >> May I ask who has provided the hardware/hosting? And what is the DNS >> hostname of the machine? (kamp.buildd.org does not resolve for me). > > That's me :D The machine is NATed so has no public address nor a real hostname. The use of `kamp.buildd.org` is merely for mail purposes (there are only MX records that point to my mail server, from which kamp retrieves messages by fetchmail). >> Also, how are the i386 builds done: is that a kfreebsd-i386 chroot >> on a kfreebsd-amd64 system? Or is it a separate VM running >> "natively" on the 32-bit kernel? > > It's a kfreebsd-i386 chroot running on a kfreebsd-amd64 system. As Svante said; the downside is k-a has priority over k-i (though sid k-i still comes before exp k-a). >> By the way, since 4 days or so many packages are Built but not >> Installed in the archive. Is that because a DD must manually check >> and sign them? > > Yes, this is a drawback. James does all signing manually whenever he > has time. I'm not a DD so I'm not authorized to do such things. I try to do it at least every other day. The recent holdup has been waiting for the util-linux/shadow transition (takeover of su(1)), as the two must be upgraded in lockstep, so if one is built and uploaded but not the other, wanna-build will regard every package as uninstallable, blocking builds until the other is also built and uploaded. They've been built on both k-a and k-i now though so I will be resuming signing when I get home this evening. James
Re: kamp down
On 12 May 2018, at 09:15, Svante Signell wrote: > On Fri, 2018-05-11 at 23:45 +0100, James Clarke wrote: >> On 11 May 2018, at 23:29, Svante Signell >> wrote: >>> On Fri, 2018-05-11 at 22:11 +0100, James Clarke wrote: >>>> On 11 May 2018, at 21:58, Svante Signell >>>> wrote: >>> >>> Well, if I build packages and want them installed in the chroot >>> .tar.gz used for building those packages, how to do that? And how >>> to give back that package to be built the normal way? The clue for >>> i386 is to build mpclib3 to make gcc-7 buildable: Can you tell be >>> how to create an updated /srv/chroot/sid_kfreebsd-i386.tar.gz so >>> that mpclib3 builds? >> >> As I've said multiple times now, you don't. Packages built by buildd >> always use a clean copy of the tarball for their chroot; if you want >> package A to use package B in its build, you have two options: > > Even if a clean copy is used every time the base system cannot be > downloaded. Which packages are part of the base system: the kernel of > course, and? For a kfreebsd buildd chroot: libacl1 adduser apt libapt-pkg5.0 libattr1 base-files base-passwd bash binutils binutils-common binutils-i686-kfreebsd-gnu libbinutils build-essential bzip2 libbz2-1.0 libdebconfclient0 coreutils dash libdb5.3 debconf debian-archive-keyring debianutils diffutils dpkg dpkg-dev libdpkg-perl e2fsprogs libcom-err2 libcomerr2 libext2fs2 libss2 libexpat1 fakeroot libfakeroot findutils libfreebsd-glue-0 libcam6 libgeom1 libjail1 libkiconv4 libkvm6 libsbuf6 libutil-freebsd-9 freebsd-utils cpp-7 g++-7 gcc-7 gcc-7-base libatomic1 libcc1-0 libgcc-7-dev libgcc1 libgomp1 libquadmath0 libstdc++-7-dev libstdc++6 cpp g++ gcc libgdbm-compat4 libgdbm5 libc-bin libc-dev-bin libc0.1 libc0.1-dev libgmp10 gpgv libgnutls30 grep gzip hostname init-system-helpers libisl15 kfreebsd-kernel-headers libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0 libbsd0 libffi6 libgcrypt20 libgpg-error0 libidn11 libtasn1-6 libtirpc1 lsb-base liblz4-1 make mawk libmpc3 libmpfr4 libncursesw5 libtinfo5 libtinfo6 ncurses-base ncurses-bin libhogweed4 libnettle6 libp11-kit0 libpam-modules libpam-modules-bin libpam-runtime libpam0g patch libpcre3 libperl5.26 perl perl-base perl-modules-5.26 sed login passwd sysvinit-utils tar tzdata bsdutils fdisk libblkid1 libfdisk1 libmount1 libsmartcols1 libuuid1 util-linux liblzma5 xz-utils zlib1g >> 1. Upload (with a DD's signature) package B to the archive > > And I've asked you if you (or somebody else) can sign and upload > packages I've built locally without any reply so far. I don't recall being asked; if you have built packages I will happily check and sign them. >> 2. Build package A manually locally in a modified schroot session > > I've done that several times. But what's the meaning of that when those > packages cannot be uploaded? See above. James
Re: kamp down
On 11 May 2018, at 23:29, Svante Signell wrote: > On Fri, 2018-05-11 at 22:11 +0100, James Clarke wrote: >> On 11 May 2018, at 21:58, Svante Signell >> wrote: > > Well, if I build packages and want them installed in the chroot .tar.gz > used for building those packages, how to do that? And how to give back > that package to be built the normal way? The clue for i386 is to build > mpclib3 to make gcc-7 buildable: Can yoy tell be how to create an > updated /srv/chroot/sid_kfreebsd-i386.tar.gz so that mpclib3 builds? As I've said multiple times now, you don't. Packages built by buildd always use a clean copy of the tarball for their chroot; if you want package A to use package B in its build, you have two options: 1. Upload (with a DD's signature) package B to the archive 2. Build package A manually locally in a modified schroot session >>> (10:48:55 PM) srs: 4) make package build again for experimental: >>> missing dependency on libcwidget3v5 for aptitude. >> >> The rebuild of aptitude is (eventually) blocked by ruby2.5 failing to >> build; >> those test suite errors need investigating. > > Might be so, but that should not hinder libcwidget3v5 to be installed > and aptitude to be installed and run?? In this case it does; since 0.5.17-9, libcwidget3v5 declares a Breaks on older aptitude versions, and thus the latest aptitude needs to be built before it is installable again. But if you follow the chain of what's causing aptitude to not be built, you get to ruby2.5. >> Like I said in private, I'm busy writing my master's dissertation >> right now, >> but once I finish I will turn to fixing these issues. > > Yes I know, therefore I asked if somebody else could step in. > Additionally, I can help (and have the time) but without authority I > cannot :( The only things you lack are the ability to sign packages to upload and issue wanna-build commands. You can still build things manually, debug failing tests, submit patches for broken packages etc. James
Re: kamp down
On 11 May 2018, at 21:58, Svante Signell wrote: > > I'm CC:ing this to debian-kbsd too! > > On Sun, 2018-05-06 at 19:31 +0200, Svante Signell wrote: >> On Sat, 2018-05-05 at 01:45 +0100, James Clarke wrote: > > Pasted from irc, this is becoming a bad story. Do you have anybody who > can help (or teach me more on how to administer a buildd): Ask people in #debian-ports; we run a whole load of buildds as a team. > (10:43:04 PM) srs: jrtc27: I see that you are uploading/signing > packages right now. No, I signed them earlier this evening. > (10:48:55 PM) srs: I really need help configuring the buildd: > (10:48:55 PM) srs: 1) get rid of the recovery sessions If there are left-over sessions, just schroot -e -c them? > (10:48:55 PM) srs: 2) enable build of i386 again It does get round to i386; some of the packages I signed were i386. > (10:48:55 PM) srs: 3) update the build chroots: starting with i386 It updates them twice weekly, but that's broken, because it can't debootstrap them due to build-essential depending on gcc (>= 4:7.3), but the new gcc-defaults providing that is waiting for gcc-7-base (>= 7.3.0-12). > (10:48:55 PM) srs: 4) make package build again for experimental: > missing dependency on libcwidget3v5 for aptitude. The rebuild of aptitude is (eventually) blocked by ruby2.5 failing to build; those test suite errors need investigating. > (10:49:34 PM) srs: If you don't help me I shut down kamp in 24 hours. > (10:50:43 PM) srs: It is not good policy to have a buildd trying to > build packages over and over again, not having a chance to succeed :( > (10:51:05 PM) srs: We will just be laughed at ... Nobody's laughing, and it does succeed for some packages; the batch I just signed was 152 packages. It's your choice whether you shut kamp down, but I don't see what it achieves other than perhaps a small amount of power/heat savings. Like I said in private, I'm busy writing my master's dissertation right now, but once I finish I will turn to fixing these issues. James
Re: Bug#897416: mpfr4: FTBFS on kfreebsd-amd64
On 3 May 2018, at 09:21, Svante Signell wrote:
> On Wed, 2018-05-02 at 12:51 +0100, James Clarke wrote:
>> Control: reassign -1 gcc-7
>> Control: retitle -1 gcc: Decimal float support is not enabled on kfreebsd-
>> amd64
>>
>> On 2 May 2018, at 10:38, Svante Signell wrote:
>>>
>>> Source: mpfr4
>>> Version: 4.0.1-1
>>> Severity: important
>>> Tags: patch
>>> User: debian-bsd@lists.debian.org
>>> Usertags: kfreebsd
>>>
>>> Hi,
>>>
>>> mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the
>>> debian/libmpfr6.symbols
>>> file. Attached is a file with the symbols generated from the build:
>>> libmpfr6.symbols.kfreebsd-amd64.
>>>
>>> Thanks!
>>
>> You're right that the symbols file is currently wrong, but IMO gcc should
>> have
>> decimal float support enabled for kfreebsd-amd64. It's enabled for
>> kfreebsd-i386 by virtue of the fact that i?86*-*-gnu* (for Hurd) matches
>> kfreebsd-i386's tuple, but there's no corresponding x86_64*-*-gnu* for a
>> future
>> 64-bit Hurd, and thus kfreebsd-amd64's tuple is not matched[0].
>>
>> James
>>
>> [0] https://github.com/gcc-mirror/gcc/blob/trunk/config/dfp.m4#L23-L26
>
> Hi James,
>
> I think it is unfortunate that you reassigned this bug to gcc-7. That will not
> solve the mpfr4 build on the buildds.
>
> There are two ways to solve this problem:
> 1)
> - reassign this bug back to mpfr4, adding the libfr6.symbols.kfreebsd-amd64 in
> next version 4.0.1-2.
Well, if you wanted to do that, it should be by changing the (arch=...)
restriction lists in the main libfr6.symbols rather than forking a copy for
kfreebsd-amd64.
> - clone this bug to gcc-7, adding a patch to dfp.m4 so it can be integrated in
> next release of gcc-7: 7.3.0-18?
Personally I'd just get gcc patched and give back mpfr4.
> 2) (not preferred)
> - Build an NMUed version of mpfr4, 4.0.1-1.1, and install it at debian-ports.
Indeed, unreleased uploads are best avoided when possible.
> For GNU/Hurd the entry in sources.list is
> deb http://ftp.ports.debian.org/debian-ports unreleased main
>
> What about creating
> http://ftp.ports.debian.org/debian-ports/pool-kfreebsd-{amd64,i386} and
> populate
> the mpfr4 packages there at pool-kfreebsd-amd64/m/. Additionally the buildds
> need to use these packages. Unfortunately I don't know how to do that.
We could, and may well eventually need an unreleased suite, but not now.
Getting the buildds to see the suite would be simple; wanna-build would need a
copy of the hurd code to tell it that unreleased exists, and our buildd setup
scripts would need tweaking to add it to apt's sources in the chroots.
> Then when gcc-7-7.3.0-18 is released, an updated version of mpfr4 is hopefully
> available (if not, what to do, how to get back to using the old version?)
In such a situation, the updated version of mpfr4 in unstable would be picked
by `apt upgrade` as unstable and unreleased get the same priority by default,
just like how you automatically get security updates from stretch/updates for
packages installed from the stretch archive on ftp-master.
James
Re: Bug#897416: mpfr4: FTBFS on kfreebsd-amd64
Control: reassign -1 gcc-7 Control: retitle -1 gcc: Decimal float support is not enabled on kfreebsd-amd64 On 2 May 2018, at 10:38, Svante Signell wrote: > > Source: mpfr4 > Version: 4.0.1-1 > Severity: important > Tags: patch > User: debian-bsd@lists.debian.org > Usertags: kfreebsd > > Hi, > > mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the debian/libmpfr6.symbols > file. Attached is a file with the symbols generated from the build: > libmpfr6.symbols.kfreebsd-amd64. > > Thanks! You're right that the symbols file is currently wrong, but IMO gcc should have decimal float support enabled for kfreebsd-amd64. It's enabled for kfreebsd-i386 by virtue of the fact that i?86*-*-gnu* (for Hurd) matches kfreebsd-i386's tuple, but there's no corresponding x86_64*-*-gnu* for a future 64-bit Hurd, and thus kfreebsd-amd64's tuple is not matched[0]. James [0] https://github.com/gcc-mirror/gcc/blob/trunk/config/dfp.m4#L23-L26
Re: Future of kFreeBSD in Debian unstable
On 2 May 2018, at 10:52, Svante Signell wrote:
> On Mon, 2018-04-02 at 20:16 +0100, James Clarke wrote:
>> On 2 Apr 2018, at 20:04, Svante Signell wrote:
>>> On Mon, 2018-04-02 at 19:33 +0200, Svante Signell wrote:
>>>> On Sat, 2018-03-31 at 10:51 +0100, James Clarke wrote:
>>>>>
>>>>> Yeah, it hasn't been added yet, I guess to see if there are any
>>>>> comments
>>>>> from wb-t...@buildd.debian.org first.
>
> Hi again,
>
> Sorry to bother you when preparing for your thesis, but I think we have some
> problems:
>
> 1) No iso files are available any longer. Is seems like kfreebsd.eu is gone.
> How
> do we enable builds of the debian installer, at least mini.iso?
> https://d-i.debian.org/daily-images/kfreebsd-* is empty!
Normally the d-i builds run on the DSA porterboxes as a daily cron job. We
don't have anything similar for debian-ports and just do the occasional manual
build. I guess if we liaise with -boot people then we might be able to have a
cronjob on kamp publish its results (and possibly for debian-ports arches too).
> 2) People seems to want asdfasdf and io back. How?
> From https://www.debian.org/ports/kfreebsd-gnu/
> asdfasdf.debian.net (kfreebsd-amd64) and io.debian.net (kfreebsd-i386) are
> available to Debian developers for porting work.
> Who was hosting those boxes?
The DNS entries are Aurelien's who may be able to shed some light?
> 3) The buildd kamp is stuck in dependency loops due to circular dependencies
> and
> due to earlier versions of some packages not being available.
>
> kfreebsd-amd64: mpfr4-4.0.1:
> Add debian/libmpfr6.symbols.kfreebsd-amd64 created from the build
> see #897416
>
> dpkg-buildpackage
> ...
> dpkg-checkbuilddeps: error: Unmet build dependencies: build-essential:native
>
> build-essential 12.5:
> apt-get install build-essential
> The following packages have unmet dependencies:
> build-essential : Depends: gcc (>= 4:7.3) but 4:7.2.0-1d1 is to be installed
>Depends: g++ (>= 4:7.3) but 4:7.2.0-1d1 is to be installed
> E: Unable to correct problems, you have held broken packages.
>
> Workaround:
> Install build-essential 12.4
> wget snapshot.debian.org/archive/debian/20170917T214533Z/pool/main/b/build-
> essential/build-essential_12.4_kfreebsd-amd64.deb
>
> Build and install gcc-7-7.3.0-17
> Install build-essential 12.5
> ...
>
> kfreebsd-i386: mpclib3:
> mpclib3 1.1.0-1 build-depends on libmpfr-dev+libmpfr6>= 4.0.0 , which
> conflicts
> wit libmpc3 < 1.1.0-1~
>
> Solved by manually building libmpfr-dev+libmpfr6 4.0.0, removing the
> dependency
> on texlive-latex-base, which depends on texlive-binaries which build-depends
> on
> libmpfr-dev.
>
> Build and install mpclib3
> Upgrade libmpfr6 to 4.01-1
> Build and install texlive-bin
> Build and install gcc-7-7.3.0-17
> Install build-essential 12.5
> ...
>
> On IRC:
> youpi replied on #debian-hurd:
> (21:36:07) srs: youpi: Any ideas? (19:26:09) srs: jrtc27: or whoever knows:
> Seems like manually building and installing mpclib3 is needed: How?
> (21:36:07) srs: (19:26:55) srs: We have a (maybe more) lock-up situation !!
> (21:49:35) youpi: you can do that by hand
> (21:49:42) youpi: just chroot into the build chroot
> (21:50:09) youpi: build&install the lib by hand
> (21:50:13) youpi: so you can build the needed deb package
> (21:50:24) youpi: and then redo this with the deb package instead of manually-
> installed library
> (21:50:33) youpi: and the result of that, you can upload
> (21:51:04) youpi: (and better even redo yet another build, so that last build
> can be reproduced from the uploaded boostrap binaries
>
> Do you think you (or somebody else) can aid me to build those needed packages
> on
> kamp?
Which bit do you need help with? There are the sid-kfreebsd-{amd64,i386}-sbuild
chroots; you can start a session with `schroot -b -c sid-...-sbuild -n foo`, run
commands inside the chroot with `schroot -r -c foo` (with sudo if you need to
install things) and end the session with `schroot -e -c foo`. /home isn't
mounted
inside the session, so you may need to copy files into /run/schroot/mount/foo/.
James
Re: no more daily-images?
On 1 May 2018, at 17:30, igo...@free.fr wrote: > > hi > > kfreebsd.eu is down > > looking for kfreebsd iso from https://d-i.debian.org/daily-images/ > > kfreebsd directories are empty > > something happened around january 11 > > anyone aware of what's going on? The d-i daily images are built on the various porterboxes for the different architectures, but the porterboxes were shut down on 2017-12-12 thus stopping the daily builds. If you want an installer image, I have a somewhat-outdated one available from [1] (taken from jenkins.kfreebsd.eu before it went down), but it should still work. Eventually we will build newer images, but I don't have time for that at the moment. James [1] https://people.debian.org/~jrtc27/debian-unofficial-kfreebsd-amd64-NETINST-1.iso
Re: Bug#897168: proftp: FTBFS on kfreebsd
On 30 Apr 2018, at 19:22, Hilmar Preuße wrote: > On 30.04.2018 13:17, James Clarke wrote: >> On 29 Apr 2018, at 22:06, Hilmar Preuße wrote: >>> On 29.04.2018 14:01, Hilmar Preuße wrote: > > Hi James, > >>> I just noticed that our package fails to build on kfreebsd: >>> >>> https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg&arch=kfreebsd-amd64&ver=1.3.6-2&stamp=1524996945&raw=0 >>> >>> Could you help us here? proftp seems to build on FreeBSD in general so >>> there seems to be something specific to this port. >>> >>> Thanks! >>> >>>> * What led up to the situation? >>>> >>>> Since we uploaded proftp 1.3.6 to unstable the package fails to build on >>>> kfreebsd, on i386 and kfreebsd-amd64. The last lines of the log are: >>>> >>>> src/fsio.o: In function `sys_fsetxattr': >>>> ./fsio.c:1018: undefined reference to `extattr_set_fd' >>>> src/fsio.o: In function `unix_flistxattr': >>>> ./fsio.c:640: undefined reference to `extattr_list_fd' >>>> ./fsio.c:640: undefined reference to `extattr_list_fd' >>>> src/fsio.o: In function `unix_llistxattr': >>>> ./fsio.c:621: undefined reference to `extattr_list_file' >>>> ./fsio.c:621: undefined reference to `extattr_list_file' >>>> src/fsio.o: In function `unix_listxattr': >>>> ./fsio.c:602: undefined reference to `extattr_list_file' >>>> ./fsio.c:602: undefined reference to `extattr_list_file' >>>> src/fsio.o: In function `sys_fremovexattr': >>>> ./fsio.c:885: undefined reference to `extattr_delete_fd' >>>> src/fsio.o: In function `sys_fgetxattr': >>>> ./fsio.c:529: undefined reference to `extattr_get_fd' >>>> collect2: error: ld returned 1 exit status >>>> libtool: link: rm -f ".libs/proftpdS.o" >>>> >>>> I guess some libs, needed for linking are not specified. I file that bug as >>>> important as FreeBSD is not a release arch. >>>> >> >> The problem here is that kfreebsd-kernel-headers provides sys/extattr.h with >> these prototypes and so proftpd's configure defines HAVE_SYS_EXTATTR_H, but >> glibc doesn't implement them, and the Linux equivalents are currently just >> stubs that return -1 with errno=ENOSYS. Thus for now I suggest you build >> proftpd with --disable-xattr. >> > Huhh. My impression was, that these are rather old system calls, which > do exist for long time now [1] and there is just another -l$lib > statement missing. If the kfreebsd port exposes some functions in the > header files, but finally does not implement it in any library I'd call > that a bug. Would it make sense to file a bug against the kfreebsd port? Yeah, please file it against kfreebsd-10 and glibc; either the prototype should disappear from the headers or it should be implemented. Thanks, James
Re: Bug#897168: proftp: FTBFS on kfreebsd
On 29 Apr 2018, at 22:06, Hilmar Preuße wrote: > > On 29.04.2018 14:01, Hilmar Preuße wrote: > > Hi debian-bsd people, > > I just noticed that our package fails to build on kfreebsd: > > https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg&arch=kfreebsd-amd64&ver=1.3.6-2&stamp=1524996945&raw=0 > > Could you help us here? proftp seems to build on FreeBSD in general so > there seems to be something specific to this port. > > Thanks! > >> * What led up to the situation? >> >> Since we uploaded proftp 1.3.6 to unstable the package fails to build on >> kfreebsd, on i386 and kfreebsd-amd64. The last lines of the log are: >> >> src/fsio.o: In function `sys_fsetxattr': >> ./fsio.c:1018: undefined reference to `extattr_set_fd' >> src/fsio.o: In function `unix_flistxattr': >> ./fsio.c:640: undefined reference to `extattr_list_fd' >> ./fsio.c:640: undefined reference to `extattr_list_fd' >> src/fsio.o: In function `unix_llistxattr': >> ./fsio.c:621: undefined reference to `extattr_list_file' >> ./fsio.c:621: undefined reference to `extattr_list_file' >> src/fsio.o: In function `unix_listxattr': >> ./fsio.c:602: undefined reference to `extattr_list_file' >> ./fsio.c:602: undefined reference to `extattr_list_file' >> src/fsio.o: In function `sys_fremovexattr': >> ./fsio.c:885: undefined reference to `extattr_delete_fd' >> src/fsio.o: In function `sys_fgetxattr': >> ./fsio.c:529: undefined reference to `extattr_get_fd' >> collect2: error: ld returned 1 exit status >> libtool: link: rm -f ".libs/proftpdS.o" >> >> I guess some libs, needed for linking are not specified. I file that bug as >> important as FreeBSD is not a release arch. >> The problem here is that kfreebsd-kernel-headers provides sys/extattr.h with these prototypes and so proftpd's configure defines HAVE_SYS_EXTATTR_H, but glibc doesn't implement them, and the Linux equivalents are currently just stubs that return -1 with errno=ENOSYS. Thus for now I suggest you build proftpd with --disable-xattr. James
Re: Future of kFreeBSD in Debian unstable
On 2 Mar 2018, at 00:12, Svante Signell wrote: > Hi, > > I'm offering you a VM on a fast computer as a buildd for Debian > GNU/kFreeBSD, similar to a buildd for Debian GNU/Hurd. Too sad to see > kFreeBSD fading away... > > Some computer data: lscpu > Architecture: x86_64 > CPU op-mode(s):32-bit, 64-bit > CPU(s):8 > Model name:Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz > CPU MHz: 4313.232 > Virtualization:VT-x > L1d cache: 32K > L1i cache: 32K > L2 cache: 256K > L3 cache: 8192K > > I'll provide a VM with the size you ask for, and will install the > required packages/admit any of you normally doing such stuff. > > The download speed is 10 Mbit/sec but upload speed is only 1 Mbit/sec > due to an ADSL connection. However, James Clarke (jrtc27) thinks that > would be OK for now. Hopefully, soon we will have a fiber 100 Mbit/s > connection in bothe directions. > > Please let me know how to proceed. > > (one alternative would be to move kFreeBSD to Devuan, but that might > not yet be a good alternative) Hi Svante, Firstly thanks again for the VM offer. The main issue now is the lack of porters, as there needs to be at least one person willing to spend time checking on the buildds and, since this is a non-Linux architecture, maintaining the kernel-related packages. Given that it's amd64 and i386, there shouldn't really be many GCC/binutils toolchain issues to worry about which can plague less-popular ports, but there is then the issue of teaching language runtimes how to work on kFreeBSD. As has been mentioned before, the sensible thing seems to be to move over to debian-ports as well. Yes, mini-dak has a few annoyances which are a pain when they occur, but they're manageable, and probably a lot easier than having to have a DD sign all uploads (as would be the case if it stayed on ftp-master). Moreover, I've been working on patching dak to work for debian-ports, so hopefully we will be switching over to that in the not too distant future once it supports everything we need. As far as my time goes, I am willing to help setup and maintain buildd infrastructure for the port, but sadly I can't set aside time to be a porter, though that may well change in the summer once this academic year is over. If anyone who wants to see this port continue has time they can regularly devote to kFreeBSD porting, no matter how little, please let us know, as without you the port will likely suffer. Regards, James
Re: isc-dhcpd vs udhcpd
On 23 Oct 2017, at 08:36, Ondřej Surý wrote:
>
> Hi,
>
> while revising bind9 udebs, KiBi suggested that non-Linux architectures
> might be using isc-dhcpd instead of udhcpd due some problems and it
> might be a good idea to revise the decision now that we have a busybox
> maintainer?
That's not going to work right now for two reasons:
1. Busybox still FTBFS on these (I have a patch series submitted upstream that
needs minor revisions, so this should resolve itself soon).
2. udhcp's Config.src has "select PLATFORM_LINUX", so building udhcp{c,d}
isn't even attempted (it includes linux/filter.h and linux/if_packet.h).
I'm sure it could be ported, but someone would need to do that work.
Regards,
James
Re: Bug#878878: default-dbus-session-bus: Not installable on non-Linux
On 17 Oct 2017, at 22:39, Samuel Thibault wrote: > > Hello, > > It seems I missed the whole thread, so found the same issue > independently :) > > Simon McVittie, on mar. 17 oct. 2017 16:21:06 +0100, wrote: >> Thanks. Hmm, so the error is: >> >>sbuild-build-depends-opencv-dummy : Depends: libgtk-3-dev but it is not >> going to be installed >> >> which is amazingly helpful. > > Adding -o Debug::pkgProblemResolver=yes provides the useful > information: > > Investigating (0) dconf-service:hurd-i386 < none -> 0.26.1-1 @un uN Ib > > Broken dconf-service:hurd-i386 Depends on default-dbus-session-bus:hurd-i386 > < none @un H > > Considering dbus-user-session:hurd-i386 0 as a solution to > dconf-service:hurd-i386 7 > Holding Back dconf-service:hurd-i386 rather than change > default-dbus-session-bus:hurd-i386 > ... Indeed, that's how I debugged it too. >> The dependency chain: >> >>libgtk-3-dev Depends dconf-gsettings-backend | gsettings-backend >>dconf-gsettings-backend Depends dconf-service >>dconf-service Depends d-d-s-b | d-s-b >> >> so we already have two layers of "if you accepted the alternative you'd >> be fine". I thought sbuild's allergy to alternatives only extended as >> far as direct dependencies? > > That wouldn't be acceptable anyway, for the same reason as the direct > dependencies. Agreed. Note that in this case it's not sbuild ignoring the alternatives as Simon mentioned, but apt itself; this is the default behaviour you get from `apt-get install libgtk-3-dev`. Regards, James
Re: Bug#878878: default-dbus-session-bus: Not installable on non-Linux
On 17 Oct 2017, at 15:12, Simon McVittie wrote: > > Control: tags -1 confirmed pending > Control: severity -1 wishlist > > On Tue, 17 Oct 2017 at 13:41:31 +0100, James Clarke wrote: >> Please modify dbus, either with more complicated Provides > > This requires dbus-user-session to become Architecture: linux-any > instead of all (lots of duplicate per-Linux-architecture copies of > the same thing), but at least it doesn't involve going through NEW, > and arguably making it linux-any is more correct. In principle I'm OK > with doing this, although I'll need to try a build on a porterbox to > check I've done the architecture specifier syntax correctly. > > It's a pity we don't have a way to express "this is > architecture-independent, but should only appear in a subset of the > apt Packages files". If we did, dbus-user-session could be > "all [linux-any]" or whatever the syntax was, and continue to provide > d-d-s-b. > > Alternatively, I'd review patches if someone wants to teach > dbus-user-session how to support non-systemd, although that would almost > certainly mean someone writing a PAM module to do the work (an alternative > to libpam-systemd) and being its upstream and Debian maintainer. Sorry, > I'm not willing to maintain that part, only "glue" analogous to what's > already in the package for systemd. > > The design requirements for dbus-user-session are: > > * one `dbus-daemon --session` per uid > * after the PAM login stack has run, either or both (preferably both): > - XDG_RUNTIME_DIR must be set to a unique directory per uid on a >tmpfs (or non-Linux equivalent) with a listening socket at >$XDG_RUNTIME_DIR/bus > - DBUS_SESSION_BUS_ADDRESS must be set to the right thing > * connecting to the given address must result in a connection to the > `dbus-daemon --session` (it can be started lazily with socket > activation, like systemd does, or eagerly, like dbus-launch does) > * after the PAM logout stack has run, if and only if this was the uid's > last parallel login session, the dbus-daemon should be terminated > and the XDG_RUNTIME_DIR should be deleted > > In systemd-land, pam_systemd (which is misnamed, it's really part of > logind) notifies logind about the login/logout, logind creates/destroys > the XDG_RUNTIME_DIR if this is the first login/last logout, logind tells > systemd-as-pid-1 to start `systemd --user` if this is the first login or > stop it if this is the last logout, and `systemd --user` loads the > dbus.socket and dbus.service provided by dbus-user-session. > > Ubuntu used to have a PAM module to set up and tear down XDG_RUNTIME_DIR, > but they were its upstream, so now that they use systemd-logind it's > unmaintained. > >> or by making default-dbus-session-bus an actual >> meta-package > > When I proposed (default-)dbus-session-bus I was told not to use a > real package, for reasons that were never particularly clear to me. > (Thread: <https://lists.debian.org/debian-devel/2016/07/msg00484.html>, > related Policy bug documenting the metapackages: > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833401>) > > If I had used real packages, the real package would have been > dbus-session-bus, which would have had alternative dependencies > on dbus-user-session | hypothetical-future-kdbus-thing | dbus-x11 > (with [linux-any] scattered around where appropriate). However, > the virtual package approach has been widely adopted now, so I'll > go the other way. It seems to me from looking at that thread that the main reason for using a virtual package is that it's simpler. The example given was for the default MTA, which works because Debian has the same default across all architectures, but for something like this it isn't so simple and you then have to mess about with spreading the Provides across different packages and making them conditional, rather than just a single meta-package with the relevant conditional Depends in one place. >> This has recently become a problem because dconf-service >> 0.26.1-1 now depends on default-dbus-session-bus | dbus-session-bus, >> making it uninstallable on the buildds for non-Linux unless their build >> deps happen to have something else depending on dbus-session-bus (or >> dbus-x11). > > I can't help wondering whether the non-Linux ports should configure their > buildds to use the aptitude dependency resolver (as used in -backports) > or the aspcud resolver (as used in experimental) to get out of this > situation. Surely this can't be the first time this has happened? They could, but then the resolvers differ across architectures,
Re: Bug#850717: procps: [kfreebsd] pkill fails, number_of_signals changed
Control: forwarded -1 https://gitlab.com/procps-ng/procps/merge_requests/52 Control: affects -1 src:cmake On Tue, Jan 10, 2017 at 12:16:20PM +, Steven Chamberlain wrote: > Hi, > > I was wrong that this bug breaks functionality of pkill. It still > works, despite printing the warning. > > So this bug is mostly cosmetic, however, it does have an incidental > side-effect on the gcc-6 builds, where the message printed on stderr > causes sbuild to never time out the build... Hi, This bug is causing cmake to FTBFS, as the stderr in some of its tests does not match the expected output due to the extra WARNING lines. I have submitted the above merge request upstream, which moves this warning to a compile-time check, as well as uses the right value for FreeBSD (and also adds SIGLOST for the Hurd). Regards, James
Re: [PATCH 4/7] xfuncs: Handle missing non-POSIX termios constants
[Dropping debian-h...@lists.debian.org as the Hurd defines all of them] On 8 Oct 2017, at 12:18, Kang-Che Sung wrote: > 2017年10月8日 18:50，"James Clarke" 寫道： >> On 8 Oct 2017, at 02:34, Kang-Che Sung wrote: >> > On Sun, Oct 8, 2017 at 1:53 AM, James Clarke wrote: >> >> diff --git a/libbb/xfuncs.c b/libbb/xfuncs.c >> >> index 9cbfb2836..95dac656a 100644 >> >> --- a/libbb/xfuncs.c >> >> +++ b/libbb/xfuncs.c >> >> @@ -22,6 +22,16 @@ >> >> */ >> >> #include "libbb.h" >> >> >> >> +#ifndef IMAXBEL >> >> +# define IMAXBEL 0 >> >> +#endif >> >> +#ifndef IUCLC >> >> +# define IUCLC 0 >> >> +#endif >> >> +#ifndef IXANY >> >> +# define IXANY 0 >> >> +#endif >> >> + >> > >> > I wonder, how do these break, and why does defining them as 0 solve the >> > problem? >> >> FreeBSD (well, GNU/kFreeBSD at least) does not define IUCLC. They are only >> used >> in the line: >> >> > newterm.c_iflag &= ~(BRKINT|INLCR|ICRNL|IXON|IXOFF|IUCLC|IXANY|IMAXBEL); >> >> Thus, by defining them as 0 when not present, it is as if they were omitted >> from that list, without needing a bunch of confusing #ifdef's in the >> expression >> itself. While IMAXBEL and IXANY are defined everywhere Debian cares about, >> they >> are still non-standard, so I did the same for them in case there is a >> platform >> out there without them. >> >> Regards, >> James > > > Why not just fix that usage line so that the bitwise OR's are all enclosed in > #ifdef lines? I think it's better than defining the macros to a value that > may cause further problems when reused. > > Analogy: You probably won't define an unsupported signal, say SIGUSR3, to a > zero value anyway. They are undefined for a reason. Hope you understand. I can understand your reasoning; the only reason I did it that way was because coreutils/stty.c has a whole load of instances of this, including for IMAXBEL, IUCLC and IXANY, but looking at it more closely I now see that all uses of them are in fact guarded by whether they are non-zero, so I'm not sure whether there's really much point even for that file. I shall therefore change it to use #ifdef's for the OR just like you said to avoid potential confusion. Regards, James
Re: [PATCH 7/7] libbb.h: Handle missing HOST_NAME_MAX; ensure MAXFOOLEN agrees with FOO_MAX
On 8 Oct 2017, at 02:40, Kang-Che Sung wrote:
> On Sun, Oct 8, 2017 at 1:53 AM, James Clarke wrote:
>> Signed-off-by: James Clarke
>> ---
>> include/libbb.h | 19 ++-
>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/libbb.h b/include/libbb.h
>> index daccf154a..56f4f4cb3 100644
>> --- a/include/libbb.h
>> +++ b/include/libbb.h
>> @@ -181,7 +181,24 @@ extern char **environ;
>> /* klogctl is in libc's klog.h, but we cheat and not #include that */
>> int klogctl(int type, char *b, int len);
>> #ifndef PATH_MAX
>> -# define PATH_MAX 256
>> +# ifdef MAXPATHLEN
>> +# define PATH_MAX MAXPATHLEN
>> +# else
>> +# define PATH_MAX 256
>> +# endif
>> +#endif
>> +#ifndef MAXPATHLEN
>> +# define MAXPATHLEN PATH_MAX
>> +#endif
>> +#ifndef HOST_NAME_MAX
>> +# ifdef MAXHOSTNAMELEN
>> +# define HOST_NAME_MAX MAXHOSTNAMELEN
>> +# else
>> +# define HOST_NAME_MAX 256
>> +# endif
>> +#endif
>> +#ifndef MAXHOSTNAMELEN
>> +# define MAXHOSTNAMELEN HOST_NAME_MAX
>> #endif
>> #ifndef BUFSIZ
>> # define BUFSIZ 4096
>
>
> Um, why do we need to define MAXPATHLEN and MAXHOSTNAMELEN where there have
> been no use in BusyBox, and there have been standard macros available?
That's not actually true (any more); util-linux/fdisk_osf.c, whilst
Linux-specific, does use MAXPATHLEN, and networking/traceroute.c uses
MAXHOSTNAMELEN. These could be changed to use {PATH,HOST_NAME}_MAX, but it's
highly likely that a future change will re-introduce a use of one of those
macros and break the build on the Hurd, so why not just define them?
> While we are at it, could you also please change the HOST_NAME_MAX fallback
> definition to 255? 255 is the POSIX defined minimum.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
> (see _POSIX_HOST_NAME_MAX value)
Ok, that makes sense. I will do so in the next revision.
Regards,
James
Re: [PATCH 4/7] xfuncs: Handle missing non-POSIX termios constants
On 8 Oct 2017, at 02:34, Kang-Che Sung wrote: > On Sun, Oct 8, 2017 at 1:53 AM, James Clarke wrote: >> diff --git a/libbb/xfuncs.c b/libbb/xfuncs.c >> index 9cbfb2836..95dac656a 100644 >> --- a/libbb/xfuncs.c >> +++ b/libbb/xfuncs.c >> @@ -22,6 +22,16 @@ >> */ >> #include "libbb.h" >> >> +#ifndef IMAXBEL >> +# define IMAXBEL 0 >> +#endif >> +#ifndef IUCLC >> +# define IUCLC 0 >> +#endif >> +#ifndef IXANY >> +# define IXANY 0 >> +#endif >> + > > I wonder, how do these break, and why does defining them as 0 solve the > problem? FreeBSD (well, GNU/kFreeBSD at least) does not define IUCLC. They are only used in the line: > newterm.c_iflag &= ~(BRKINT|INLCR|ICRNL|IXON|IXOFF|IUCLC|IXANY|IMAXBEL); Thus, by defining them as 0 when not present, it is as if they were omitted from that list, without needing a bunch of confusing #ifdef's in the expression itself. While IMAXBEL and IXANY are defined everywhere Debian cares about, they are still non-standard, so I did the same for them in case there is a platform out there without them. Regards, James
[PATCH 7/7] libbb.h: Handle missing HOST_NAME_MAX; ensure MAXFOOLEN agrees with FOO_MAX
Signed-off-by: James Clarke --- include/libbb.h | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/include/libbb.h b/include/libbb.h index daccf154a..56f4f4cb3 100644 --- a/include/libbb.h +++ b/include/libbb.h @@ -181,7 +181,24 @@ extern char **environ; /* klogctl is in libc's klog.h, but we cheat and not #include that */ int klogctl(int type, char *b, int len); #ifndef PATH_MAX -# define PATH_MAX 256 +# ifdef MAXPATHLEN +# define PATH_MAX MAXPATHLEN +# else +# define PATH_MAX 256 +# endif +#endif +#ifndef MAXPATHLEN +# define MAXPATHLEN PATH_MAX +#endif +#ifndef HOST_NAME_MAX +# ifdef MAXHOSTNAMELEN +# define HOST_NAME_MAX MAXHOSTNAMELEN +# else +# define HOST_NAME_MAX 256 +# endif +#endif +#ifndef MAXHOSTNAMELEN +# define MAXHOSTNAMELEN HOST_NAME_MAX #endif #ifndef BUFSIZ # define BUFSIZ 4096 -- 2.14.1
[PATCH 0/7] Hurd and GNU/kFreeBSD portability fixes
Hi,
With this patch series, busybox once again builds on the Hurd and GNU/kFreeBSD,
and it also fixes one bug with "grep -cr" and symlinks to directories found as
a result of FreeBSD's handling of reading from directories:
$ ls -lR grep.testdir
grep.testdir:
total 4
drwxr-xr-x 2 jrtc27 jrtc27 4096 Oct 7 18:50 foo
lrwxrwxrwx 1 jrtc27 jrtc273 Oct 7 18:49 symfoo -> foo
grep.testdir/foo:
total 4
-rw-r--r-- 1 jrtc27 jrtc27 4 Oct 7 18:50 file
$ grep -cr . grep.testdir
grep.testdir/foo/file:1
$ busybox grep -cr . grep.testdir
grep.testdir/foo/file:1
grep.testdir/symfoo:0
Regards,
James
James Clarke (7):
blkdiscard: Only build on Linux
df: Use statvfs instead of non-standard statfs
networking: Fall back on IPPROTO_RAW when SOL_RAW is not defined
xfuncs: Handle missing non-POSIX termios constants
{udp_io,traceroute}: Standardise IPv6 PKTINFO handling to be portable
grep: Skip grepping symlinks to directories
libbb.h: Handle missing HOST_NAME_MAX; ensure MAXFOOLEN agrees with
FOO_MAX
coreutils/df.c | 6 +++---
findutils/grep.c| 22 --
include/libbb.h | 19 ++-
libbb/udp_io.c | 8 ++--
libbb/xfuncs.c | 10 ++
networking/ping.c | 8
networking/traceroute.c | 16 +++-
util-linux/blkdiscard.c | 1 +
8 files changed, 77 insertions(+), 13 deletions(-)
--
2.14.1
[PATCH 1/7] blkdiscard: Only build on Linux
Signed-off-by: James Clarke --- util-linux/blkdiscard.c | 1 + 1 file changed, 1 insertion(+) diff --git a/util-linux/blkdiscard.c b/util-linux/blkdiscard.c index 5863f0aab..e4902e5b5 100644 --- a/util-linux/blkdiscard.c +++ b/util-linux/blkdiscard.c @@ -8,6 +8,7 @@ //config:config BLKDISCARD //config: bool "blkdiscard (5.3 kb)" //config: default y +//config: select PLATFORM_LINUX //config: help //config: blkdiscard discards sectors on a given device. -- 2.14.1
[PATCH 4/7] xfuncs: Handle missing non-POSIX termios constants
Signed-off-by: James Clarke
---
libbb/xfuncs.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libbb/xfuncs.c b/libbb/xfuncs.c
index 9cbfb2836..95dac656a 100644
--- a/libbb/xfuncs.c
+++ b/libbb/xfuncs.c
@@ -22,6 +22,16 @@
*/
#include "libbb.h"
+#ifndef IMAXBEL
+# define IMAXBEL 0
+#endif
+#ifndef IUCLC
+# define IUCLC 0
+#endif
+#ifndef IXANY
+# define IXANY 0
+#endif
+
/* Turn on nonblocking I/O on a fd */
int FAST_FUNC ndelay_on(int fd)
{
--
2.14.1
[PATCH 6/7] grep: Skip grepping symlinks to directories
When grep is passed -r, recursive_action will treat any symlinks to
directories not in the root as normal files, since it lstat's them and
is therefore told they are not directories. However, file_action_grep
will still try to fopen and read from them to see whether they match,
which varies in behaviour across platforms. Linux will give EISDIR and
thus grep will not find any matching lines, but FreeBSD will give the
raw contents of the directory itself, which may match the given pattern.
Also, if grep is passed -c, it will even print a count for these
symlinks, even on Linux.
Since this recursive_action behaviour is required for the correct
functioning of other applets, such as tar, grep should handle this
special case and skip any such symlinks.
Signed-off-by: James Clarke
---
findutils/grep.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/findutils/grep.c b/findutils/grep.c
index f72175afb..0cb0aac64 100644
--- a/findutils/grep.c
+++ b/findutils/grep.c
@@ -639,11 +639,29 @@ static void load_regexes_from_file(llist_t *fopt)
}
static int FAST_FUNC file_action_grep(const char *filename,
- struct stat *statbuf UNUSED_PARAM,
+ struct stat *statbuf,
void* matched,
int depth UNUSED_PARAM)
{
- FILE *file = fopen_for_read(filename);
+ FILE *file;
+ struct stat statbufFollow;
+
+ /* If we are given a link to a directory, we should bail out now, rather
+* than trying to open the "file" and hoping getline gives us nothing,
+* since that is not portable across operating systems (FreeBSD for
example
+* will return the raw directory contents). */
+ if (S_ISLNK(statbuf->st_mode)) {
+ if (stat(filename, &statbufFollow) < 0) {
+ if (!SUPPRESS_ERR_MSGS)
+ bb_simple_perror_msg(filename);
+ return 0;
+ }
+
+ if (S_ISDIR(statbufFollow.st_mode))
+ return 1;
+ }
+
+ file = fopen_for_read(filename);
if (file == NULL) {
if (!SUPPRESS_ERR_MSGS)
bb_simple_perror_msg(filename);
--
2.14.1
[PATCH 5/7] {udp_io,traceroute}: Standardise IPv6 PKTINFO handling to be portable
The current standard (RFC 3542) is for IPV6_RECVPKTINFO to be given to
setsockopt, and IPV6_PKTINFO to be used as the packet type. Previously,
RFC 2292 required IPV6_PKTINFO to be used for both, but RFC 3542
re-purposed IPV6_PKTINFO when given to setsockopt. The special
Linux-specific IPV6_2292PKTINFO has the same semantics as IPV6_PKTINFO
in RFC 2292, but was introduced at the same time as IPV6_RECVPKTINFO.
Therefore, if we have IPV6_RECVPKTINFO available, we can use the RFC
3542 style, and if not, we assume that only the RFC 2292 API is
available, using IPV6_PKTINFO for both.
Signed-off-by: James Clarke
---
libbb/udp_io.c | 8 ++--
networking/traceroute.c | 8 +++-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/libbb/udp_io.c b/libbb/udp_io.c
index 6e3ef484e..68355e6c4 100644
--- a/libbb/udp_io.c
+++ b/libbb/udp_io.c
@@ -8,6 +8,10 @@
*/
#include "libbb.h"
+#if defined(IPV6_PKTINFO) && !defined(IPV6_RECVPKTINFO)
+# define IPV6_RECVPKTINFO IPV6_PKTINFO
+#endif
+
/*
* This asks kernel to let us know dst addr/port of incoming packets
* We don't check for errors here. Not supported == won't be used
@@ -18,8 +22,8 @@ socket_want_pktinfo(int fd UNUSED_PARAM)
#ifdef IP_PKTINFO
setsockopt_1(fd, IPPROTO_IP, IP_PKTINFO);
#endif
-#if ENABLE_FEATURE_IPV6 && defined(IPV6_PKTINFO)
- setsockopt_1(fd, IPPROTO_IPV6, IPV6_PKTINFO);
+#if ENABLE_FEATURE_IPV6 && defined(IPV6_RECVPKTINFO)
+ setsockopt_1(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO);
#endif
}
diff --git a/networking/traceroute.c b/networking/traceroute.c
index df7122047..6dcbc2faa 100644
--- a/networking/traceroute.c
+++ b/networking/traceroute.c
@@ -311,6 +311,9 @@
# ifndef SOL_IPV6
# define SOL_IPV6 IPPROTO_IPV6
# endif
+# if defined(IPV6_PKTINFO) && !defined(IPV6_RECVPKTINFO)
+# define IPV6_RECVPKTINFO IPV6_PKTINFO
+# endif
#endif
#include "libbb.h"
@@ -911,12 +914,7 @@ common_traceroute_main(int op, char **argv)
#if ENABLE_TRACEROUTE6
if (af == AF_INET6) {
xmove_fd(xsocket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6), rcvsock);
-# ifdef IPV6_RECVPKTINFO
setsockopt_1(rcvsock, SOL_IPV6, IPV6_RECVPKTINFO);
- setsockopt_1(rcvsock, SOL_IPV6, IPV6_2292PKTINFO);
-# else
- setsockopt_1(rcvsock, SOL_IPV6, IPV6_PKTINFO);
-# endif
} else
#endif
{
--
2.14.1
[PATCH 3/7] networking: Fall back on IPPROTO_RAW when SOL_RAW is not defined
Signed-off-by: James Clarke --- networking/ping.c | 8 networking/traceroute.c | 8 2 files changed, 16 insertions(+) diff --git a/networking/ping.c b/networking/ping.c index 774f8f3e0..d1d59d545 100644 --- a/networking/ping.c +++ b/networking/ping.c @@ -135,6 +135,14 @@ # define ICMP_ADDRESSREPLY 18 /* Address Mask Reply*/ #endif +/* Some operating systems, like GNU/Hurd, don't define SOL_RAW, but do have + * IPPROTO_RAW. Since the IPPROTO definitions are also valid to use for + * setsockopt (and take the same value as their corresponding SOL definitions, + * if they exist), we can just fall back on IPPROTO_RAW. */ +#ifndef SOL_RAW +# define SOL_RAW IPPROTO_RAW +#endif + #if ENABLE_PING6 # include /* I see RENUMBERED constants in bits/in.h - !!? diff --git a/networking/traceroute.c b/networking/traceroute.c index 8b6247482..df7122047 100644 --- a/networking/traceroute.c +++ b/networking/traceroute.c @@ -323,6 +323,14 @@ # define IPPROTO_IP 0 #endif +/* Some operating systems, like GNU/Hurd, don't define SOL_RAW, but do have + * IPPROTO_RAW. Since the IPPROTO definitions are also valid to use for + * setsockopt (and take the same value as their corresponding SOL definitions, + * if they exist), we can just fall back on IPPROTO_RAW. */ +#ifndef SOL_RAW +# define SOL_RAW IPPROTO_RAW +#endif + #define OPT_STRING \ "FIlnrdvxt:i:m:p:q:s:w:z:f:" \ -- 2.14.1
[PATCH 2/7] df: Use statvfs instead of non-standard statfs
Platforms differ on what their implementations of statfs include.
Importantly, FreeBSD's does not include a f_frsize member inside struct
statfs. However, statvfs is specified by POSIX and includes everything
we need, so we can just use that instead.
Signed-off-by: James Clarke
---
coreutils/df.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/coreutils/df.c b/coreutils/df.c
index 121da970b..4076b5fec 100644
--- a/coreutils/df.c
+++ b/coreutils/df.c
@@ -77,7 +77,7 @@
//usage: "/dev/sda3 17381728 17107080274648 98%
/\n"
#include
-#include
+#include
#include "libbb.h"
#include "unicode.h"
@@ -98,7 +98,7 @@ int df_main(int argc UNUSED_PARAM, char **argv)
unsigned opt;
FILE *mount_table;
struct mntent *mount_entry;
- struct statfs s;
+ struct statvfs s;
enum {
OPT_KILO = (1 << 0),
@@ -211,7 +211,7 @@ int df_main(int argc UNUSED_PARAM, char **argv)
mount_point = mount_entry->mnt_dir;
fs_type = mount_entry->mnt_type;
- if (statfs(mount_point, &s) != 0) {
+ if (statvfs(mount_point, &s) != 0) {
bb_simple_perror_msg(mount_point);
goto set_error;
}
--
2.14.1
Re: Bug#833829: libgcc-6-dev: Missing crtfastmath.o on kfreebsd-*
On Tue, Sep 06, 2016 at 03:17:52PM +0200, Andreas Beckmann wrote:
> Control: retitle -1 libgcc-6-dev: Missing crtfastmath.o on kfreebsd-*
> Control: affects -1 + src:vlc
>
> On Tue, 9 Aug 2016 11:39:54 +0200 Matthias Klose wrote:
> > > I'm unable to build a package because crtfastmath.o is missing from this
> > > package. Architecture is kfreebsd-i386. I don't see this bug on the
> > > kfreebsd-amd64
> > >
> > > ,
> > > | cc -Wall -DPIC -O2 -pipe -fno-tree-dominator-opts -fno-tree-pre
> > > -ffast-math -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g -D_FILE_OFFSET_BITS=64
> > > -D_LARGEFILE_SOURCE -fPIC -pthreadluma.c -o luma
> > > | /usr/bin/ld: cannot find crtfastmath.o: No such file or directory
> > > `
> >
> > https://buildd.debian.org/status/fetch.php?pkg=gcc-6&arch=kfreebsd-i386&ver=6.1.1-11&stamp=1470331624
> >
> > looks like this is never built, and the install step succeeds despite it
> > complains about not finding this file.
>
> Seems to be specific to gcc-6, the file is available in libgcc-4.9-dev,
> libgcc-5-dev, and gcc-snapshot (7.0.0).
>
> This bug is the cause for the FTBFS of vlc on both kfreebsd-amd64 and
> kfreebsd-i386:
>
> https://buildd.debian.org/status/fetch.php?pkg=vlc&arch=kfreebsd-amd64&ver=2.2.4-3%2Bb4&stamp=1472902929
> https://buildd.debian.org/status/fetch.php?pkg=vlc&arch=kfreebsd-i386&ver=2.2.4-3%2Bb4&stamp=1472905628
This seems to be caused by the fact that t-crtfm moved from
libgcc/config/i386 to just libgcc/config between GCC 5 and 6, but
kfreebsd-unwind.diff wasn't updated to reflect this (GCC 7's was though,
but there's another issue below). Patch included, though I haven't
actually tested it.
Matthias, I noticed a couple of other things when exploring this:
1. GCC 5 and 6 both omit the tm_file="${tm_file} i386/elf-lib.h"
statement in the new kfreebsd branch for both x86_64 and i386, but
GCC 7 includes it.
2. (Likely more important) GCC 7's kfreebsd-unwind.diff is missing the
change for x86_64[1], so I assume only i386 has unwind support.
Let me know if you want separate bugs for either of these.
Regards,
James
[1]
https://sources.debian.net/src/gcc-7/7.1.0-5/debian/patches/kfreebsd-unwind.diff/
---
diff -u gcc-6-6.3.0/debian/patches/kfreebsd-unwind.diff
gcc-6-6.3.0/debian/patches/kfreebsd-unwind.diff
--- gcc-6-6.3.0/debian/patches/kfreebsd-unwind.diff
+++ gcc-6-6.3.0/debian/patches/kfreebsd-unwind.diff
@@ -11,7 +11,7 @@
-i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | i[34567]86-*-gnu* |
i[34567]86-*-kopensolaris*-gnu)
+i[34567]86-*-kfreebsd*-gnu)
+ extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o
crtfastmath.o"
-+ tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff
t-dfprules"
++ tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff
t-dfprules"
+ md_unwind_header=i386/freebsd-unwind.h
+ ;;
+i[34567]86-*-knetbsd*-gnu | i[34567]86-*-gnu* |
i[34567]86-*-kopensolaris*-gnu)
@@ -25,7 +25,7 @@
-x86_64-*-kfreebsd*-gnu | x86_64-*-knetbsd*-gnu)
+x86_64-*-kfreebsd*-gnu)
+ extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o
crtfastmath.o"
-+ tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff
t-dfprules"
++ tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff
t-dfprules"
+ md_unwind_header=i386/freebsd-unwind.h
+ ;;
+x86_64-*-knetbsd*-gnu)
Re: Bug#852215: FTBFS on non-release architectures
On 3 Feb 2017, at 15:28, Cyril Brulebois wrote: > James Clarke (2017-01-22): >> As you know, debian-installer does not build on non-release >> architectures, since it tries to build for stretch. Some architectures >> also have some of the needed udebs in the unreleased suite, such as >> sparc-utils on sparc64. The attached patch lets me build on sparc64 >> even after a `dch --release`, and I would assume on other ports >> architectures too. Is this something you would consider applying? > > As mentioned on IRC a tiny while back, I can understand how this is > necessary since ports are going to have specific packages (e.g. > bootloaders) which don't really make sense to have in the official > archive. > > It looks to me like your proposed patch makes it a bit hard to > understand what's happening in debian/rules, and I'd like to propose > a different take on this, by first having the usual daily builds vs. > release heuristics, then having overrides for ports. I've pushed a > pu/support-for-ports branch for you folks to double check: > > https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=pu/support-for-ports&id=6580c874c5263fb500f5b222f7d4f6a1c17ac532 > > https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=pu/support-for-ports&id=1ca77bc7c8aaa7c4948905bd0dc4ca8b397a0c00 > > I removed amd64 from RELEASE_ARCHES so that amd64 would be considered > like a port (2005 called, it wants its sarge-amd64 release back!) and > it seems to work just fine, with a warning about an invalid mirror > when unreleased isn't found there. So hopefully that shouldn't make > it any harder for kfreebsd-* (which currently FTBFS anyway…). > > Please let me know what you think and which results you get with a > real test on unreleased ports. Some data points: alpha : Missing srm-reader in archive. Builds after adding a locally-built .udeb to localudebs (and working around the crazy broken mirror setup on electro [one of the local mirrors has no unstable -> sid symlink, but has an unreleased -> sid symlink]*... but that's not debian-installer's problem). If alpha porters want installer images, I guess they should upload and maintain srm-reader in unreleased. hppa : Builds after applying patch from #852260. hurd-i386 : Builds without any further changes. kfreebsd-amd64 : Builds if the netboot gtk image size limit is increased by 2M. sparc64: Builds without any further changes. These were all done in chroots with just the build-deps installed. None of the build results have been tested. Regards, James * This would not be a problem for http mirrors, since debian-installer would discard the mirror as invalid when generating the udeb sources.list, but since this is a file: mirror, it doesn't check for validity and assumes it works. In theory debian-installer could check file: mirrors too, which would work around this insanity.
Bug#849542: PIE specs ignored even with DEB_BUILD_MAINT_OPTIONS hardening
Package: gcc-6
Version: 6.2.1-7
Severity: important
The check introduced to ignore dpkg's PIE specs when PIE is not enabled
by default is wrong, and ends up ignoring them even when hardening=+all
or hardening=+pie is present in DEB_BUILD_MAINT_OPTIONS.
The current check is:
> if (ignore_pie_specs_when_not_enabled("DEB_BUILD_MAINT_OPTIONS", arg)
> || ignore_pie_specs_when_not_enabled("DEB_BUILD_OPTIONS", arg))
but since only DEB_BUILD_MAINT_OPTIONS includes the hardening options,
the second call with DEB_BUILD_OPTIONS returns true and causes the file
to be ignored. I believe this should be && rather than ||.
I can reproduce this regression by building one of my packages
(src:polyml) on sparc64:
> $ grep hardening debian/rules
> export DEB_BUILD_MAINT_OPTIONS=hardening=+all
> $ dpkg-buildpackage -us -uc
> [...]
> g++: note: pie specs /usr/share/dpkg/pie-compile.specs ignored when pie is
> not enabled
Regards,
James
