Re: Debian Buster release to partially drop non-systemd support
On Tue, 2018-10-16 at 14:48 +0200, Philipp Kern wrote: > The question is: Is > the package buggy if it does not contain an init script but a systemd > unit and it seems to be the case. Note that there are a *lot* of useful > options in a systemd unit that would need emulation to make properly > work with sysvinit. Shipping a systemd unit without a corresponding init script with the same name is forbidden by policy: | However, any package integrating with other init systems must also | be backwards-compatible with sysvinit by providing a SysV-style init | script with the same name as and equivalent functionality to any | init-specific job +---[ Debian Policy, section 9.11 ] In practice this is ignored. Note that this also forbids, for example, ssh.socket/ssh@.service or tor@.service which all don't have a corresponding init script of the same name. Also cases where the init script starts multiple services, but there are individual units for each service in systemd is forbidden. I think this requirement isn't a good idea these days for various reasons and will file a bug asking to drop it. Ansgar
Re: Bug#893591: e2fsprogs: circular build dependency block build on kfreebsd
> On Tue, Mar 20, 2018 at 08:50:43AM +0100, Petter Reinholdtsen wrote: >> The automatic builders in Debian are unable to build e2fsprogs on >> kfreebsd, because the build depend on libtirpc1 depending on libcomerr2 >> (>= 1.01). Is there a good way to break this loop? >> >> The missing build blocks libvorbis from building on kfreebsd. There no longer are any kfreebsd buildds, see https://lists.debian.org/debian-bsd/2017/12/msg8.html Ansgar
Re: Future of kFreeBSD in Debian unstable
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
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
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
Future of kFreeBSD in Debian unstable
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
Re: possibility of jessie-kfreebsd suite
Hi, Steven Chamberlain ste...@pyro.eu.org writes: Ansgar Burchardt wrote: [...] There should now be all suites needed for kfreebsd: - jessie-kfreebsd AIUI that suite was pre-populated some days ago with a snapshot of jessie. But I've noticed a few packages missing; lists attached. Have you any ideas why? I only looked at one package, but I guess the problem is the same for all packages: They are in the suite (see dak ls libc0.1), but the overrides are no longer there. I guess this happened in the final dinstall run before the release: there is a step to update testing's overrides and I assume it did remove the overrides for packages only in testing-kfreebsd, but not in testing. They should reappear with the next dinstall run. Ansgar -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d22prid7@deep-thought.43-1.org
Re: possibility of jessie-kfreebsd suite
Hi, Christoph Egger christ...@debian.org writes: Ansgar Burchardt ans...@debian.org writes: Christoph Egger christ...@debian.org writes: I was told you would be supportive of an unofficial kfreebsd jessie release and willing to add a suite for that. Guess I write here what I think would be best from our point of view and you tell me if I'm crazy or not: + There would be a jessie-kfreebsd thing next to the normal jessie with kfreebsd folks responsible for + Ideally that jessie-kfreebsd thing would exist as soon as possible so we can do our release preparations there I think we can setup a jessie-kfreebsd suite. I guess it should - just accept uploads (provided versions are greater-equal testing) Sounds OK to me. just accept uploads means uploads from any DD/DM or some list of keys? I guess it's easy to get the ACCEPTED mail for all uploads to that suite to a mailinglist? Yes and yes. Moritz Mühlenhoff j...@inutil.org writes: Sorry for the late reply. I'm afraid noone in the security team is sufficiently familiar with the wanna-build setup, but I if implementable by w-b I think it would be good to have the kfreebsd builds being triggered once they are released through security.debian.org (we can probably hook that into the dak security-install command or something similar). The kfreebsd buildds are fast and should be able to build everything in acceptable time. Right. For the wb side I do have some (limited) insight. Who would need to hook that into security-install? Hmm, does the security team plan to support kfreebsd? That is should there also be a jessie-kfreebsd/updates suite on security.d.o? I imagine we would want to automatically copy source+all packages from jessie/updates to jessie-kfreebsd/updates in that case. Probably needs some additional code in dak, but some of that I think I want to have anyway. Ansgar -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw5zx1m1@deep-thought.43-1.org
Re: possibility of jessie-kfreebsd suite
Hi,
Christoph Egger christ...@debian.org writes:
I was told you would be supportive of an unofficial kfreebsd jessie
release and willing to add a suite for that. Guess I write here what I
think would be best from our point of view and you tell me if I'm crazy
or not:
+ There would be a jessie-kfreebsd thing next to the normal jessie
with kfreebsd folks responsible for
+ Ideally that jessie-kfreebsd thing would exist as soon as possible so
we can do our release preparations there
I think we can setup a jessie-kfreebsd suite. I guess it should
- just accept uploads (provided versions are greater-equal testing)
- contain just 3 archs: all, kfreebsd-{i386,amd64}
- have no extra policy queues, and
- share overrides with jessie.
Uploads should probably include a specific suffix to avoid version
clashes with the offical release (for source and arch:all packages).
+ Ideally -release@ would accept us in testing as long as possible
(without any blocking characteristics there) and we copy everything
that is not superseeded in jessie-kfreebsd there rather late
Well, kfreebsd is still in testing for now ;)
The last point of course depends on what release thinks of it and the
implications for them. And I have no idea if it's reasonably easy for
you to do a copy everything apart from the things we already uploaded
separately.
Copying everything from testing should not be too complicated if we only
need to do so once.
Ansgar
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvc1gi1c@deep-thought.43-1.org
Re: kfreebsd-10_10.1~svn271306-1_kfreebsd-amd64.changes is NEW
Steven Chamberlain ste...@pyro.eu.org writes: On 11/09/14 01:19, Debian FTP Masters wrote: binary:acpi-modules-10.1-0-486-di is NEW. binary:cdrom-modules-10.1-0-486-di is NEW. binary:crypto-dm-modules-10.1-0-486-di is NEW. binary:crypto-modules-10.1-0-486-di is NEW. binary:ext2-modules-10.1-0-486-di is NEW. ...etc Why is that? Those existed in the previous upload to experimental: They were not in use as kfreebsd-10 wasn't build on kfreebsd-i386 in experimental. As an unused override, there were automatically removed after some time. Ansgar -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/851trid2qm@tsukuyomi.43-1.org
Bug#760206: dak cruft-report: recent source-only uploads should not be listed as obsolete
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: dak Cyril Brulebois k...@debian.org writes: Steven Chamberlain ste...@pyro.eu.org (2014-09-01): On 31/08/14 20:18, Debian FTP Masters wrote: kfreebsd-kernel-headers (10.1~1) experimental; urgency=medium . * Update for 10.1 * Add myself to uploaders This package seems to have disappeared from wanna-build? It was in Needs-Build state for several hours, the build depends should be satisfiable, but it just disappeared from the queue and there is no log? It was a source-only upload to experimental, was never held in the NEW queue, and does not build any arch-indep packages. Could anyone explain where it went? removals.822 says: | Date: Mon, 01 Sep 2014 11:10:59 + | Ftpmaster: Scott Kitterman | Suite: experimental | Sources: | kfreebsd-kernel-headers_10.1~1 | Reason: [auto-cruft] obsolete source package So cruft-report was of the opinion this source package was obsolete as it has no associated binary packages. We should probably fix cruft-report to not consider recently uploaded source packages as obsolete. Ansgar -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/851trvw0hh@tsukuyomi.43-1.org
