Re: Future of kFreeBSD in Debian unstable

[Aurelien Jarno]

On 2018-05-02 12:34, James Clarke wrote:
> On 2 May 2018, at 10:52, Svante Signell  wrote:
> > 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?

Those box where hosted by the Department of Physics of the ETH Zürich.

> The DNS entries are Aurelien's who may be able to shed some light?

Oh, I forgot about those DNS entries. Given those boxes have been dead
for many years, I have just released them.

Aurelien 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: Future of kFreeBSD in Debian unstable

[James Clarke]

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 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: Future of kFreeBSD in Debian unstable

[Samuel Thibault]

Svante Signell, on ven. 02 mars 2018 19:16:32 +0100, wrote:
> On Fri, 2018-03-02 at 16:19 +, James Clarke wrote:
> > 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
[...]
> > 
> > As has been mentioned before, the sensible thing seems to be to move
> > over to debian-ports as well.
> 
> Is this really necessary, I'm hosting a buildd for GNU/Hurd and don't
> see any problems with that?

In the Debian GNU/Hurd case is somebody who does maintain buildds etc.

Samuel

Re: Future of kFreeBSD in Debian unstable

[Svante Signell]

On Fri, 2018-03-02 at 16:19 +, James Clarke wrote:
> On 2 Mar 2018, at 00:12, Svante Signell 
> wrote:
> > Hi,
> > 
> 
> 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.

Is this really necessary, I'm hosting a buildd for GNU/Hurd and don't
see any problems with that?

> 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.

What would be gained by moving to debian-ports??

> 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.

As far as the buildd goes, please let me know your wishes in a private
mail and I'll set up a VM for you, size, partitions, software for
me/you to install, etc

   I. I already havea few kfreebsd images, but they are not upgraded for
  some time. Regarding bug fixing, many bugs (except PATH_MAX ones)
  appearing for GNU/Hurd also appear for GNU/kFreeBSD. So, I think it
  is rally nice to have a sister architecture to Hurd pushing
  upstreams to really be writing portable code.

Thanks!

Re: Future of kFreeBSD in Debian unstable

[James Clarke]

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

Future of kFreeBSD in Debian unstable

[Svante Signell]

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)

Re: Future of kFreeBSD in Debian unstable

[Thorsten Glaser]

Ansgar Burchardt wrote:

>Though it might make sense to move kfreebsd-* to ports.d.o.  That was
>planned to happen for hurd-i386 too.

That might be for the best… if not for this ultra-annoying
shortcoming of mini-dak which hurts me on x32, and hurt me
on m68k even more:

when a new version of a library comes out, say src:gdbm now
ships libgdbm5 and used to ship libgdbm3, mini-dak (contrary
to dak) drops libgdbm3 (one run) after accepting the new
version.

This is a really big showstopper for the ideal procedure of
basically letting buildds churn unattended and looking at
failing builds only. Porters must manually look at the list
of BD-Uninstallable packages on wuiet every once in a while
and do their manual best to fix that, using porter uploads.
(The old packages are still there on snapshot.d.o and can
easily be fed into cowbuilder using a hook script.)

So, unless someone who has knowledge of mini-dak (how it
works and the programming language it’s written in) and
fixes this bug, please don’t move architectures to ports
for as long as it can be avoided.

That being said: libcomerr2 in quinn-diff currently is a
bit of in a WTF state, isn’t it? (That being said, on ports,
we also sometimes have packages listed as BD-Uninstallable
which aren’t, but it’s rare.)

bye,
//mirabilos (hat: x32 user and sorta porter, former m68k porter)
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs

Re: Future of kFreeBSD in Debian unstable

[Ansgar Burchardt]

Wouter Verhelst writes:
> On Mon, Jan 15, 2018 at 01:32:08PM +, Steven Chamberlain wrote:
>> Hi Ansgar,
>> 
>> Ansgar Burchardt wrote:
>> > however with the kFreeBSD buildds gone, we would also need at least some
>> > people willing to maintain buildds (this is limited to Debian Developers
>> > as long as the port lives on ftp.debian.org).
>> 
>> Assuming I could find/maintain a couple of VMs to build kfreebsd sid,
>> how exactly could the .debs be uploaded to ftp.d.o?  Are they simply
>> uploaded with ftp/scp along with a .changes/.buildinfo, just like a
>> binNMU or source package upload?
>
> Yes.
>
>> Would the buildds need their own GPG keys, added into some keyring also?
>
> GPG keys for buildds are in a separate keyring, and they are required to
> be limited to one year (since they are passwordless)
>
>> That's possible even for non-DSA maintained buildds?
>
> Yes, all the buildds for the other non-release ports (e.g., PowerPC,
> m68k, ...) do that.

For ports.d.o maybe; for ftp-master.d.o not: only DSA-maintained buildds
get automatic signing.

For non-DSA maintained buildds (hurd only?) the maintainer gets to
review the .changes and sign them with his own key.

Though it might make sense to move kfreebsd-* to ports.d.o.  That was
planned to happen for hurd-i386 too.

Ansgar

Re: Future of kFreeBSD in Debian unstable

[Wouter Verhelst]

On Mon, Jan 15, 2018 at 01:32:08PM +, Steven Chamberlain wrote:
> Hi Ansgar,
> 
> Ansgar Burchardt wrote:
> > however with the kFreeBSD buildds gone, we would also need at least some
> > people willing to maintain buildds (this is limited to Debian Developers
> > as long as the port lives on ftp.debian.org).
> 
> Assuming I could find/maintain a couple of VMs to build kfreebsd sid,
> how exactly could the .debs be uploaded to ftp.d.o?  Are they simply
> uploaded with ftp/scp along with a .changes/.buildinfo, just like a
> binNMU or source package upload?

Yes.

> Would the buildds need their own GPG keys, added into some keyring also?

GPG keys for buildds are in a separate keyring, and they are required to
be limited to one year (since they are passwordless)

> That's possible even for non-DSA maintained buildds?

Yes, all the buildds for the other non-release ports (e.g., PowerPC,
m68k, ...) do that.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Future of kFreeBSD in Debian unstable

[Yavor Doganov]

В Tue, 16 Jan 2018 23:23:43 +0100, Christoph Egger написа:
> I guess the hurd example shows that very few people can sucecssfully run
> a port -- for a release architecture you need a couple more people.

Exactly.  Right now the goal should be to run the port, with a priority 
to restore the buildds as an initial step.

Being a release architecture is a different beast, I think it was way too 
premature for Debian GNU/kFreeBSD and has had a negative effect at the 
end.  TBH, I was quite surprised at the time why the stable kfreebsd-* 
release was rushed so much and announced as a "release preview" (or a 
similar buzzword never used before).

Re: Future of kFreeBSD in Debian unstable

[Christoph Egger]

On Monday 15 January 2018 11:10:18 CET Ansgar Burchardt wrote:
> Hardware resources shouldn't be a problem: I'm fairly sure the buildds
> were VMs anyway.

Jep one VM with reasonable IO each and a second VM mostly due to redundancy 
requirements

> kFreeBSD could have chosen to use another default init system.  I don't
> think there is any requirement for this to be the same everywhere.  The
> main problem was that there wasn't anyone willing / having time to
> commit to kFreeBSD as far as I remember; not much will happen if that is
> the case.

Totally. A 1.5 - 2 person port is just not manageable as a release and way to 
much risk (no redundancy in manpower and such). In the end jessie-kfreebsd was 
probably more work for release team and ftp masters and others than just 
having kfreebsd as part of jessie.

I guess the hurd example shows that very few people can sucecssfully run a 
port -- for a release architecture you need a couple more people.

  Christoph

signature.asc
Description: This is a digitally signed message part.

Re: Future of kFreeBSD in Debian unstable

[Luca Capello]

Hi there,

for a while now I am in the process of looking at another OS than stock
Debian, which means either another Linux-based (hi, Slackware!) or
FreeBSD (I need ZFS support).

The above was the reason why on 2017-04-09 I installed my first Debian
GNU/kFreeBSD, using the d-i available back then.  The installation went
smoothly once I brought up the Wi-Fi (ThinkPad X200t here with Intel
WiFi 5300 8086:236).  I am sorry to not have filed an
installation-report bug at that time, but I wanted to test it again to
fully document how Wi-Fi can be brought up (no custom .(u)deb were
used).

The lack of filesystem native encryption in ZFS on kFreeBSD 10 was
however a showstopper and since then I booted my Debian GNU/kFreeBSD
rarely, despite the fact that everything else, except for the YubiKey 4
(kernel panic) worked *out of the box*.  A big kudos to everyone
involved here, the achievement is IMHO quite a success already.

My free time for Debian has vastly reduced in the last year,
nevertheless I am available for sponsoring/reviewing and buildd work if
needed (I setup a no-wannabuild one at work for internal/external
packages).  And I would be more than happy to financially help.

For everything else, I have the same feeling as Axel: I am not a
toolchain guy, debugging does not scare me, but fixing the problem could
end up being the bigger problem (pun intended).

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Re: Future of kFreeBSD in Debian unstable

[Steven Chamberlain]

Hi Ansgar,

Ansgar Burchardt wrote:
> however with the kFreeBSD buildds gone, we would also need at least some
> people willing to maintain buildds (this is limited to Debian Developers
> as long as the port lives on ftp.debian.org).

Assuming I could find/maintain a couple of VMs to build kfreebsd sid,
how exactly could the .debs be uploaded to ftp.d.o?  Are they simply
uploaded with ftp/scp along with a .changes/.buildinfo, just like a
binNMU or source package upload?

Would the buildds need their own GPG keys, added into some keyring also?
That's possible even for non-DSA maintained buildds?

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Future of kFreeBSD in Debian unstable

[Ansgar Burchardt]

Yavor Doganov writes:
> В Fri, 12 Jan 2018 11:08:20 +0100, Axel Beckert написа:
>> I just read jcristau's mail: I don't see the difference between running
>> buildds for jessie-kfreebsd and sid. Why can the one continue while the
>> other can't/
>
> I don't understand either.  I guess DSA are upgrading the last hosts
> to stretch as jessie is nearing to EOL.  Or they need the machines for
> some other services.

There are no buildds for jessie-kfreebsd either (so no security updates
either).

Hardware resources shouldn't be a problem: I'm fairly sure the buildds
were VMs anyway.

>>> As kfreebsd-* are probably never going to to be release architectures
>>> due to systemd, maybe it is better to move the port to debian-ports.
>> 
>> Wait! Debian runs fine without systemd. sysvinit has recently been
>> revived upstream and there's OpenRC which is doing fine on my boxes.
>
> My impression was that the release team would not bless an
> architecture if it doesn't use the default init system.  Also, certain
> sets of packages will not work properly without systemd.

kFreeBSD could have chosen to use another default init system.  I don't
think there is any requirement for this to be the same everywhere.  The
main problem was that there wasn't anyone willing / having time to
commit to kFreeBSD as far as I remember; not much will happen if that is
the case.

(Hurd was never a release architecture either, though I wouldn't be
surprised if someone was trying to blame systemd for that too ;-) )

Ansgar

Re: Future of kFreeBSD in Debian unstable

[Yavor Doganov]

В Fri, 12 Jan 2018 11:08:20 +0100, Axel Beckert написа:
> I can imagine doing sysadmin work on buildds.

I can also host a buildd at home, no restrictions AFAICT.
Administration can be handled remotely by a DD if I'm not able to do
the job properly and/or I'm not being trusted.  I can't participate
with a hardware donation, unfortunately, with three grown-up children
and a chronically ill wife on my neck.

> I just read jcristau's mail: I don't see the difference between running
> buildds for jessie-kfreebsd and sid. Why can the one continue while the
> other can't/

I don't understand either.  I guess DSA are upgrading the last hosts
to stretch as jessie is nearing to EOL.  Or they need the machines for
some other services.

>> As kfreebsd-* are probably never going to to be release architectures
>> due to systemd, maybe it is better to move the port to debian-ports.
> 
> Wait! Debian runs fine without systemd. sysvinit has recently been
> revived upstream and there's OpenRC which is doing fine on my boxes.

My impression was that the release team would not bless an
architecture if it doesn't use the default init system.  Also, certain
sets of packages will not work properly without systemd.

> I wonder what is exactly needed to run a buildd wrt. to the host
> operating system. Does it need to be a "stable" Debian?

Apparently no as that would rule out GNU/Hurd.  There's no stable
release for ia64 that is being resurrected/bootstrapped at the moment.

Re: Future of kFreeBSD in Debian unstable

[Axel Beckert]

Hi,

after more than a year or so, I recently revived my kFreeBSD box (an
now about 10 years old not-meltdown-affected ASUS EeeBox) and just
noticed that the kfreebsd buildds stopped working around the same
time. That's why I looked into this mailing list again after quite a
while, too.

Yavor Doganov wrote:
> I'm not qualified to work on the toolchain

Same issue here.

> and don't have special sysadmin skills

I think, I have those at least.

> However, I can work on bugs in specific packages with a certain degree
> of stubbornness.

Sounds familiar.

> Contrary to most people, my interest is philosophical, not
> technical.

For me it's mostly because I like exots, things mixed which weren't
planned to be mixed. :-)

> > however with the kFreeBSD buildds gone, we would also need at least some
> > people willing to maintain buildds (this is limited to Debian Developers
> > as long as the port lives on ftp.debian.org).

I can imagine doing sysadmin work on buildds.

I just read jcristau's mail: I don't see the difference between
running buildds for jessie-kfreebsd and sid. Why can the one continue
while the other can't/

> As kfreebsd-* are probably never going to to be release architectures
> due to systemd, maybe it is better to move the port to debian-ports.

Wait! Debian runs fine without systemd. sysvinit has recently been
revived upstream and there's OpenRC which is doing fine on my boxes.
(I though haven't yet tried the combination of OpenRC and kFreeBSD.)

> At some point, it was evident that much more people were engaged with
> GNU/kFreeBSD compared to GNU/Hurd.  It is bewildering why human
> resources have been in short supply lately.

For me it were essential bugs like newer kernels providing no more
network on my machine while older kernels prevents packages from being
installed. At some point I had to wait quite long until I got that box
working again.

I had similar demotivating toolchain/kernel issues with my Sparc
engagement. (Which will likely respark at some point, too, but I can't
tell when.)

> > Currently no architecture-dependent packages get updated for kFreeBSD;
> 
> That's the beginning of the end, unfortunately.  If the port is moved
> elsewhere, does it have to be bootstrapped again or the wanna-build
> database can be reused?

I wonder what is exactly needed to run a buildd wrt. to the host
operating system. Does it need to be a "stable" Debian?

With regards to hardware: I can imagine buying a small system for that
in case I'm hosting that at home (reachable from the outside only via
IPv6).

But as mentioned before: I'm definitely the wrong guy for toolchain
issues. I remember having put many hours into a grave startpar issue
on kFreeBSD, just to notice in the end (when someone else found the
fix) that I was on the completely wrong way.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Re: Future of kFreeBSD in Debian unstable

[Yavor Doganov]

В Mon, 08 Jan 2018 12:32:33 +0100, Ansgar Burchardt написа:
> But we would need people to commit to that: someone has to address
> issues that arise (these do not have to be Debian Developers, though
> ports should have at least some Debian Developers commit to them);

I'm not qualified to work on the toolchain and don't have special
sysadmin skills that are probably needed for a buildd maintainer.
However, I can work on bugs in specific packages with a certain degree
of stubbornness.  My impression is that the majority of GNU/kFreeBSD
bugs are fairly trivial to fix like this one:

https://sources.debian.org/src/terminal.app/0.9.9-1/debian/patches/FTBFS-
kFreeBSD/

I first installed GNU/kFreeBSD some time after the first installation
instructions became available, but couldn't get it to boot.  I made a
fresh reinstall following #593898.  I felt guilty for losing Axel
Beckert's time so went on and installed kfreebsd-i386 on one of my
machines.  I had to buy a LAN card as mine wasn't supported by the
kernel.  I couldn't use it as my main workstation but that was mostly
because the machine was rather old and slow.  I used it regularly for
several years to test packages (mostly GNUstep) until the HDD died.

Contrary to most people, my interest is philosophical, not technical.

> however with the kFreeBSD buildds gone, we would also need at least some
> people willing to maintain buildds (this is limited to Debian Developers
> as long as the port lives on ftp.debian.org).

As kfreebsd-* are probably never going to to be release architectures
due to systemd, maybe it is better to move the port to debian-ports.

At some point, it was evident that much more people were engaged with
GNU/kFreeBSD compared to GNU/Hurd.  It is bewildering why human
resources have been in short supply lately.

> Currently no architecture-dependent packages get updated for kFreeBSD;

That's the beginning of the end, unfortunately.  If the port is moved
elsewhere, does it have to be bootstrapped again or the wanna-build
database can be reused?

Re: Future of kFreeBSD in Debian unstable

[Ansgar Burchardt]

Hi,

Gianluca Bonetti writes:
> I think it is a project worth keeping alive, even if not 100% workable.
> Dumping it away is a great waste of previous and precious work on
> portability and kernel abstraction.
> kFreeBSD 7 was stable enough to be used as desktop, as I did on a secondary
> box, real hardware.

It certainly would be nice if the kfreebsd port would be kept alive; I
find it an interesting project myself.

But we would need people to commit to that: someone has to address
issues that arise (these do not have to be Debian Developers, though
ports should have at least some Debian Developers commit to them);
however with the kFreeBSD buildds gone, we would also need at least some
people willing to maintain buildds (this is limited to Debian Developers
as long as the port lives on ftp.debian.org).

Currently no architecture-dependent packages get updated for kFreeBSD;
updates to architecture-independent (arch: all) packages will eventually
be incompatible with those old versions and more and more packages will
no longer be installable.  I don't believe it is worth keeping a port on
ftp.d.o in this state (snapshot.d.o will provide historic packages that
might be helpful if someone wants to restart the effort in the future).

Ansgar

Re: Future of kFreeBSD in Debian unstable

[Yavor Doganov]

В Fri, 05 Jan 2018 11:41:08 +0100, Ansgar Burchardt написа:

> I'm wondering if there is still any interest in keeping kFreeBSD in
> unstable?

There is interest, but it is not clear to me what has to be done to keep 
the port alive.  How can non-DDs help to resurrect the port?

Re: Future of kFreeBSD in Debian unstable

[Gianluca Bonetti]

Hello
I am not a debian developer, and I just use kFreeBSD on a VMs for testing
purposes.

I think it is a project worth keeping alive, even if not 100% workable.
Dumping it away is a great waste of previous and precious work on
portability and kernel abstraction.
kFreeBSD 7 was stable enough to be used as desktop, as I did on a secondary
box, real hardware.

Given the stats from https://popcon.debian.org/ it seems that kFreeBSD is
still running on 38 active machines (not counting my 2 VMs, as I don't run
them 24x7)
38 kFreeBSD boxes are more than hurd-i386, s390*, ppc64*.
mips64el is an official port, and is running only on one machine, so it
seems that there is more interest in unofficial kFreeBSD than official
mips64el

Just my personal opinion, as a debian user.

Bye
gl

2018-01-05 11:41 GMT+01:00 Ansgar Burchardt :

> Hi,
>
> last month Julien Cristau wrote that buildds for kFreeBSD will go
> away[1]; there was no reply and this has since happened.
>
> I'm wondering if there is still any interest in keeping kFreeBSD in
> unstable?  Given the lack of response, I am considering removal in a
> few weeks.
>
> Ansgar
>
>   [1] https://lists.debian.org/debian-bsd/2017/12/msg8.html
>
>

Future of kFreeBSD in Debian unstable

[Ansgar Burchardt]

Hi,

last month Julien Cristau wrote that buildds for kFreeBSD will go
away[1]; there was no reply and this has since happened.

I'm wondering if there is still any interest in keeping kFreeBSD in
unstable?  Given the lack of response, I am considering removal in a
few weeks.

Ansgar

  [1] https://lists.debian.org/debian-bsd/2017/12/msg8.html