Re: kfreebsd-10_10.3~svn300087-7_source.changes REJECTED
On 2 Apr 2020, at 17:28, Steven Chamberlain <steven@pyro.eu.org> wrote:
> Hello, Jess,
>
> Jessica Clarke wrote:
>> I suspect you're falling afoul of the fact that, although I made the orig
>> tarball reproducible [...]
>
> Actually, in this case, I did change the contents of the tarball. I
> believe I should have changed the source version as well. I think
> convention is to add something like +ds1 or +repack1.
Oh, then yes, one of those (I feel +ds1 is more common but either WFM).
> Since I had a little bit of free time this week I have this roadmap:
>
> * Update kfreebsd-10 package to gcc-9 (done).
> * Add version 10.3 man pages into kfreebsd-source-10.3.
> * Build man pages related to kernel headers from
> src:kfreebsd-kernel-headers instead of src:freebsd-manpages;
> that way the man pages are in sync with the actual version of the
> headers, but mainly: if k-k-h builds some arch-indep package, then
> k-k-h could go back into sid, so that bootstrapping becomes possible
> again. (Then maybe Helmut could keep it on jenkins.d.n).
Oh cool, that's another workaround. We were thinking on IRC that perhaps
everything kernel-related should just be built from src:k-X rather than having
the complexity of multiple separate packages.
> * Similarly, get freebsd-utils back into sid.
Yep, manpages would be an easy method for that.
> * Update the debian/copyright file for kfreebsd-10, then kfreebsd-11.
This is the thing that I stalled on, for obvious reasons... but I see you've
done a bunch of work towards that already which is exciting!
> * Get kfreebsd-11 through the NEW queue *maybe*
It was "just" copyright for the last REJECT...
> Although I'm only really focusing on kfreebsd-10 at first, to get kbsd
> bootstrappable and debootstrappable *at all* with the least effort. The
> switch to a newer kernel is way bigger project than I probably have time
> for. But maybe then someone else feels like doing it!
kfreebsd-11 should be in decent shape (other than the few freebsd-utils that
need to be kept in sync with the kernel version due to a lack of stability for
sysctls, in particular netstat IIRC :/), the rejected version has been on the
buildd for ages now. But updating to newer versions is probably something I
would be more likely to end up finding time for :) Regardless, thanks for
coming back, at least for now! That just leaves finding time to (or tricking
someone into) refactor the glibc patches after they killed of sysdeps for
plugins... but at least there's the upstreamed hurd port to follow as an
example these days.
Also at some point I might try and upstream some of our patches that make sense
to upstream (i.e. newer GCC versions, and building with GNU tools like date), I
work on a FreeBSD fork for my research and have (post-review) commit access so
wouldn't be too painful...
Jess
Reply to: