Package: istgt
Severity: important
User: bl...@debian.org
Usertags: missing-systemd-service
Dear Maintainer(s),
istgt has been flagged by Lintian as shipping a sysv-init script
without a corresponding systemd unit file. The default init system in
Debian is systemd, and so far this worked because
Hi all,
in linux I can set a parameter in the kernel command line, like for
example runitdir=somedir , and it will be added to init's environment.
Will this work with a FreeBSD kernel? If not, is there a way to achieve
the same result?
Regards,
Lorenzo
Hello,
Matthew Vernon, le mar. 16 oct. 2018 14:10:23 +0100, a ecrit:
> I mentioned this on debian-devel already in the thread about Buster
> maybe losing sysvinit support, but I thought it was worth flagging to
> the HURD/BSD lists since it seems relevant to your interests :-)
FYI, I have bounced
http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2018-October/thread.html
And the mailman listinfo page (where you can subscribe and suchlike) is:
http://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity
[I've set follow-ups there; feel free to redirect to me i
On Sat, Jun 25, 2016 at 07:09:35PM +0200, Christoph Egger wrote:
> Hi!
>
> Jon Boden writes:
> > What are your plans for the future of init on Debian GNU/kFreeBSD? Are you
> > going to continue with sysvinit for the time being?
> >
> > For the upcoming releas
Hi!
Jon Boden writes:
> What are your plans for the future of init on Debian GNU/kFreeBSD? Are you
> going to continue with sysvinit for the time being?
>
> For the upcoming release of ubuntuBSD I'm thinking about using BusyBox
> + OpenRC
> (https://blog.flameeyes.eu/201
Package: busybox
Version: 1.22.0-19
Tags: patch
Hi
With the package added by this patch (busybox-openrc), BusyBox Init can be used
as PID 1 as a launcher for OpenRC (instead of SysV /sbin/init). This has the
potential for faster boot times (but I haven't measured it, see
n too (I
haven't tested the whole init yet, but I verified that with my patch it can
print to stdout).
I've also sent it to BusyBox bugzilla:
https://bugs.busybox.net/show_bug.cgi?id=9031
--
Jon Boden
ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!
http://ww
Hi
What are your plans for the future of init on Debian GNU/kFreeBSD? Are you
going to continue with sysvinit for the time being?
For the upcoming release of ubuntuBSD I'm thinking about using BusyBox + OpenRC
(https://blog.flameeyes.eu/2012/03/using-busybox-with-openrc). Do you think
Your message dated Thu, 13 Aug 2015 19:04:04 +
with message-id
and subject line Bug#795354: fixed in freebsd-utils 10.1~svn273304-1+kbsd8u1
has caused the Debian Bug report #795354,
regarding freebsd-utils: init script fails on ZFS root
to be marked as done.
This means that you claim that
Package: freebsd-utils
Version: 10.1~svn273304-1
Severity: normal
Tags: pending
Hi,
The freebsd-utils init script can fail on first boot of a newly-
installed system, trying to point /etc/mtab to /proc/mounts, in
the case of a ZFS root that is read-only until after the zfs init
script has run
Hi,
[I don't currently have an OpenID, so was unable to comment directly at
http://joeyh.name/blog/entry/how_I_wrote_init_by_accident/ ]
Propellor also just accidentally works on Debian GNU/kFreeBSD! In the
same way as a Docker container, it can be used as the init for a jail:
(some argu
On 22/02/2014 03:32, Joel Lopes Da Silva wrote:
> I don't really know much more than that, sorry. I'm not a FreeBSD
> developer either. I'm just a guy who thinks launchd is a pretty awesome
> init system, and who would love to see it more widely used.
Well, our hands are
be pretty clear that launchd seems to be only one that’s actually being
> > worked on by FreeBSD developers: https://wiki.freebsd.org/launchd
> > I couldn’t find any similar page for the other contenders on the FreeBSD
> > wiki.
> >
> > Surely, using the same init system as
n by FreeBSD developers: https://wiki.freebsd.org/launchd
> I couldn’t find any similar page for the other contenders on the FreeBSD
> wiki.
>
> Surely, using the same init system as the one that FreeBSD might use
> someday will be nice for maintaining the Debian GNU/kFreeBSD port
ts to wiki.freebsd.org, it will
be pretty clear that launchd seems to be only one that’s actually being
worked on by FreeBSD developers: https://wiki.freebsd.org/launchd
I couldn’t find any similar page for the other contenders on the FreeBSD
wiki.
Surely, using the same init system as the one that Fr
Apparently sysvinit scripts must be retained anyway for a smooth
migration to jessie; also for easy backporting of jessie packages to
wheezy, and maybe other reasons. Non-Linux ports are likely to use
those SysV init scripts, though we might invoke them from something
other than sysvinit.
I
On Tue, Feb 18, 2014 at 05:26:05PM +0100, Christoph Egger wrote:
> Hm so why was none of the ports list Cc-ed on this mail? There is
> active discussion [0] between hurd and bsd people were we want to go
> now.
Likewise perhaps pkg-sysvinit-devel should be copied into all such
discussions (copie
Hi!
Ondřej Surý writes:
> I don't really want to open another can of worms, but what's the opinion
> of non-Linux ports maintainers on default init?
Hm so why was none of the ports list Cc-ed on this mail? There is
active discussion [0] between hurd and bsd people were w
Hi,
On Sat, Feb 15, 2014 at 02:47:14PM +, Robert Millan wrote:
> On 14/02/2014 18:46, Steven Chamberlain wrote:
> > Well, we have an announcement today from Canonical - AIUI Upstart will
> > be discontinued after Ubuntu 14.04 LTS and they will switch to systemd:
> > http://www.markshuttleworth
On 14/02/2014 18:46, Steven Chamberlain wrote:
> Well, we have an announcement today from Canonical - AIUI Upstart will
> be discontinued after Ubuntu 14.04 LTS and they will switch to systemd:
> http://www.markshuttleworth.com/archives/1316
I'm not familiar with Ubuntu politics. Is everyone in li
On 12/02/14 12:40, Steven Chamberlain wrote:
> In particular I wonder what Ubuntu will do, and
> if Upstart has a future at all.
Well, we have an announcement today from Canonical - AIUI Upstart will
be discontinued after Ubuntu 14.04 LTS and they will switch to systemd:
http://www.markshuttlewort
hings don't match up (e.g. udev <-> devd events).
We didn't start on Hurd yet.
In the best interest of Debian/kFreeBSD, it is probably best to stick
with sysv-init as default for jessie, and have alternatives fully
available by feature freeze such that a switch can be made for
jessie+1.
On 12/02/14 13:18, Robert Millan wrote:
> Or maybe backward compat? I hear some of the new init implementations
> support SysV.
SysV init scripts?
I thought this was obvious, or maybe I misunderstand what you mean.
*All* of the init systems that were discussed by the TC, even systemd
(f
On 12/02/2014 12:40, Steven Chamberlain wrote:
> Although, come jessie+1, I wonder how upgrades will be handled, if
> sysvinit scripts go away.
Maybe Pre-Depends. Or maybe have written instructions to install
the new init by hand, like we often do for kernels.
Or maybe backward compat?
On 12/02/14 12:23, Robert Millan wrote:
> If we have to support it anyway, is it really worth spending effort on
> Upstart/OpenRC for Jessie?
Right, sysvinit is a viable and easy option for jessie; having any
other init systems working is a bonus.
At least we know now that we n
On 12/02/2014 12:09, Steven Chamberlain wrote:
> There are a few reasons to keep sysvinit scripts maintained for jessie:
> 1. for smoother upgrades from wheezy
> 2. in order to backport jessie packages to wheezy
> 3. for non-Linux (or non-systemd) ports
>
> So ports are not the only reason. And y
Forwarded Message
From: Svante Signell
To: debian-h...@lists.debian.org
Subject: Re: Init system for non-Linux ports
Date: Wed, 12 Feb 2014 13:02:45 +0100
On Wed, 2014-02-12 at 10:45 +, Robert Millan wrote:
> On 29/01/2014 09:26, Petr Salinger wrote:
> What is the c
ose, but seems we'd want to
make use of legacy sysvinit compatibility - write very few scripts in
specific formats (e.g. OpenRC runscripts / Upstart jobs). We probably
have right up until freeze to make a preference, and perhaps by then
there will be more than one fully-working init system.
On 12/02/14 12:04, Svante Signell wrote:
> I fear that it is currently broken since one of the latest patches. Do
> you have a (scrappable) pre-installed image I can download, ala:
> http://people.debian.org/~sthibault/hurd-i386/
Yes, Aurelien Jarno has kindly made these:
> http://blog.aurel32.ne
On 29/01/2014 09:26, Petr Salinger wrote:
>> 1. stay with sysvinit
>> 2. switch to OpenRC unconditionally
>> 3. switch to Upstart unconditionally
>> 4. switch to Upstart only if Linux uses it by default, otherwise OpenRC
>> 5. further discussion
>>
>> Please rank the above putting your preferred op
On 31/01/14 10:57, Justus Winter wrote:
> 1. Up to this day, Debian/Hurd has never used the current default init
> system (sysvinit) but has relied on its own init and rc system. We
> are prepared to use a non-default init system in the future.
This will become increasingly difficult
I'm only a kFreeBSD user and don't have any official standing within the
Debian project, but all the same my preferences are
614253
where 6. is the proposed alternative to switch to Upstart if Linux uses
it, otherwise sysvinit.
Jeff
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.
lly ignorant of).
I'm the tech-ctte will even consider deciding anything for !linux
without a really good reason. As long as we (the kfreebsd people) and
the hurd people each find something that works for us we should be
fine. The only thing from the tech-ctte / GR discussions that might
affe
1. stay with sysvinit
2. switch to OpenRC unconditionally
3. switch to Upstart unconditionally
4. switch to Upstart only if Linux uses it by default, otherwise OpenRC
5. further discussion
Please rank the above putting your preferred option first, as per
Debian's usual Condorcet voting system. T
On 28/01/14 22:31, Steven Chamberlain wrote:
> 1. stay with sysvinit
I know that would be the least work, but I think we should take the
opportunity to switch now to one of the modern init systems. Some
package maintainers specifically expressed that they don't want to
maintain SysV init
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/01/2014 23:31, Steven Chamberlain wrote:
> Here are the options I can think of - but let me know if you want
> something not represented here:
>
> 1. stay with sysvinit
> 2. switch to OpenRC unconditionally
> 3. switch to Upstart unconditionally
Em 2014-01-28 20:31, Steven Chamberlain escreveu:
Hi everyone,
"What init system would we like to use by default on the non-Linux
ports
for jessie?"
I hope this question is really as straightforward as it looks, and that
we might come to some general agreement much more quickly tha
Hi everyone,
"What init system would we like to use by default on the non-Linux ports
for jessie?"
I hope this question is really as straightforward as it looks, and that
we might come to some general agreement much more quickly than the
tech-ctte bug!
Here are the options I can thin
TNAME ip4.addr=$IP
> command=/sbin/rc sysinit
>
>OpenRC 0.10.9429351 is starting up GNU/kFreeBSD 9.0-2-amd64-xenhvm (x86_64)
>
> mdconfig: ioctl(/dev/mdctl): Device or resource busy
> /libexec/rc/sh/init.sh: 18: /libexec/rc/sh/init-common-post.sh: newfs: not
> found
>
Hi,
On Sun, 27 Oct 2013 02:47:56 +0800 Thomas Goirand wrote:
> Note that OpenRC already works on some (non-Debian) BSD platforms, and
> that it should be trivial to have it to build on kFreeBSD and Hurd,
And so I came up with the attached patch which gets it building on
GNU/kFreeBSD, and it passe
Your message dated Wed, 02 Oct 2013 23:34:02 +
with message-id
and subject line Bug#721446: fixed in freebsd-utils 9.2-1
has caused the Debian Bug report #721446,
regarding nfsiod: Init script needs output formatting.
to be marked as done.
This means that you claim that the problem has been
Package: freebsd-nfs-common
Version: 9.0+ds1-11~deb7u1
Severity: normal
Tags: patch
As nfsiod is started the executable emits some text.
This upsets the message flow crafted by log_msg_*.
The following patch silences that glitch.
Regards,
Mats Erik Andersson, DM
--- etc/init.d/nfsiod.orig 2013-
Your message dated Sun, 30 Dec 2012 00:33:22 +
with message-id
and subject line Bug#695679: fixed in freebsd-utils 9.0+ds1-9
has caused the Debian Bug report #695679,
regarding freebsd-utils: Init script fails in jail, breaks dist-upgrade
to be marked as done.
This means that you claim that
Processing control commands:
> tags -1 + confirmed patch
Bug #695679 [freebsd-utils] freebsd-utils: Init script fails in jail, breaks
dist-upgrade
Added tag(s) confirmed and patch.
> severity -1 important
Bug #695679 [freebsd-utils] freebsd-utils: Init script fails in jail, breaks
dist-u
Control: tags -1 + confirmed patch
Control: severity -1 important
On 11/12/12 16:20, Stefan Ott wrote:
> Setting up freebsd-utils (9.0+ds1-8) ...
> Installing new version of config file /etc/init.d/freebsd-utils ...
> [] Loading devfs rules...devfs ruleset: ioctl DEVFSIO_SUSE:
> Operation not
status 1
configured to not write apport reports
Errors were encountered while processing:
freebsd-utils
E: Sub-process /usr/bin/dpkg returned an error code (1)
It's easy enough to work around this issue (exit 0 in the init script
does the trick) but it's a little annoying and would b
Your message dated Fri, 25 May 2012 17:18:02 +
with message-id
and subject line Bug#674582: fixed in freebsd-utils 9.0+ds1-5
has caused the Debian Bug report #674582,
regarding init script requires kldutils, but devd doesn't Depend on it
to be marked as done.
This means that you claim
Package: devd
Version: 9.0+ds1-4
Severity: grave
devd init script requires kldutils, but a dependency on this package is
missing.
This is currently breaking debootstrap when run against sid.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'uns
Your message dated Tue, 08 May 2012 06:47:36 +
with message-id
and subject line Bug#670412: fixed in freebsd-utils 9.0+ds1-4
has caused the Debian Bug report #670412,
regarding geli init script fails if /etc/default/geli is unconfigured
to be marked as done.
This means that you claim that
On 26/04/12 00:21, Steve Fouchet wrote:
> It can be bypass if you initialise $geli_devices with any value in
> /etc/default/geli.
> ex : geli_devices="da75"
>
> then geli start and booting process/ packages configuration can continue.
Thanks... that would work around this problem, yes.
The packa
On 26/04/12 00:21, Steve Fouchet wrote:
> It can be bypass if you initialise $geli_devices with any value in
> /etc/default/geli.
> ex : geli_devices="da75"
>
> then geli start and booting process/ packages configuration can continue.
Thanks... that would work around this problem, yes.
The packa
It's due to a checks in geli init script.
line 108: if [ -z "${devices}" ];
It can be bypass if you initialise $geli_devices with any value in
/etc/default/geli.
ex : geli_devices="da75"
then geli start and booting process/ packages configuration can continue.
Hope
Processing commands for cont...@bugs.debian.org:
> tags 670412 + pending
Bug #670412 [geom] geli init script fails if /etc/default/geli is unconfigured
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
670412: http://bugs.debian.org/c
On 25/04/12 12:52, Stefan Bühler wrote:
> Setting up geom (9.0+ds1-3) ...
> Starting GELI subsystem...UNCONFIGURED. See /etc/default/geli ... failed!
> invoke-rc.d: initscript geli, action "start" failed.
> dpkg: error processing geom (--configure):
> subprocess installed post-installation script
Package: geom
Version: 9.0+ds1-3
The geli init script fails if no geli devices are configured in
/etc/fstab and /etc/default/geli.
This prevented an upgrade of geom and freebsd-geom:
[...]
Setting up geom (9.0+ds1-3) ...
Starting GELI subsystem...UNCONFIGURED. See /etc/default/geli ... failed
Thank you for filing a new Bug report with Debian.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.
As you requested
-* buildds:
The following packages have unmet dependencies:
module-init-tools : Depends: libkmod2 but it is not installable
Depends: kmod but it is not installable
module-init-tools recently became a arch:all package (it was linux-any
before) so the Provides: by kfreebsd&#
Helo
I've noticed that kldutils now provides module-init-tools.
Although I understand that their both functions at the end are the same,
It appears to me that the debconf templated module-init-tools selection
was really user friendly and simplified the administration of a box.
I spent some
Your message dated Mon, 14 Dec 2009 21:49:58 +
with message-id
and subject line Bug#559344: fixed in freebsd-utils 8.0-2
has caused the Debian Bug report #559344,
regarding kldutils: bashism used in /etc/init.d/module-init-tools
to be marked as done.
This means that you claim that the
On Fri, 4 Dec 2009 14:43:52 +0100 (CET)
Petr Salinger wrote:
> It might be related to package name change in
>
> freebsd-utils (7.1-4) unstable; urgency=low
>
>* Rename module-init-tools to kldutils and net-tools to freebsd-net-tools,
> as this is messing up the expec
Hi,
Rogério Brito writes:
> On Dec 03 2009, Thorsten Glaser wrote:
>> modules="$(cat /etc/modules /etc/modules.d/* 2>/dev/null | \
>> sed -e 's/#.*//g' -e '/^[ ]*$/d')"
>> ^ ^-> space
>> +> tab
>
> Are character classes (
On Dec 03 2009, Thorsten Glaser wrote:
> modules="$(cat /etc/modules /etc/modules.d/* 2>/dev/null | \
> sed -e 's/#.*//g' -e '/^[ ]*$/d')"
> ^ ^-> space
> +> tab
Are character classes (e.g., [[:blank:]]) understood by standard too
When running with a default shell of dash and not bash, the
/etc/init.d/module-init-tools script complains about not finding the bash
builtin shopt:
# /etc/init.d/module-init-tools start
/etc/init.d/module-init-tools: 62: shopt: not found
#
Which is from this call:
modules="`sho
On Thu, Dec 03, 2009 at 08:58:49PM +0100, Hanno Hecker wrote:
> Package: kldutils
> Version: 8.0-1
> Severity: normal
>
> When running with a default shell of dash and not bash, the
> /etc/init.d/module-init-tools script complains about not finding the bash
> builtin sh
On Thu, 3 Dec 2009 20:44:03 + (UTC)
Thorsten Glaser wrote:
> I propose: (untested at the moment though)
>
> modules="$(cat /etc/modules /etc/modules.d/* 2>/dev/null | \
> sed -e 's/#.*//g' -e '/^[ ]*$/d')"
> ^ ^-> space
> +>
Hanno Hecker dixit:
>modules="`shopt -s nullglob ; cat /etc/modules /etc/modules.d/* \
> | sed -e \"s/#.*//g\" -e \"/^\( \|\t\)*$/d\" `"
This is even worse, as "...`..."..."...`..." (with or without inner
quotes) is always wrong and not portable, however $(...) is guaranteed
by POSIX
Package: kldutils
Version: 8.0-1
Severity: normal
When running with a default shell of dash and not bash, the
/etc/init.d/module-init-tools script complains about not finding the bash
builtin shopt:
# /etc/init.d/module-init-tools start
/etc/init.d/module-init-tools: 62: shopt: not found
On 22/07/2009, Luca Favatella wrote:
> On 22/07/2009, Otavio Salvador wrote:
>> Hello,
>>
>> On Wed, Jul 22, 2009 at 2:26 PM, Luca Favatella
>> wrote:
>>> On 22/07/2009, Luca Favatella wrote:
>>>> This patch adds GNU/kFreeBSD /etc/fstab
Hello,
On Wed, Jul 22, 2009 at 2:26 PM, Luca Favatella wrote:
> On 22/07/2009, Luca Favatella wrote:
>> This patch adds GNU/kFreeBSD /etc/fstab and /sbin/init.
>> Please carefully review it.
>
> Now the patch should be really attached.
> Sorry for the noise.
Fine with m
On 22/07/2009, Otavio Salvador wrote:
> Hello,
>
> On Wed, Jul 22, 2009 at 2:26 PM, Luca Favatella wrote:
>> On 22/07/2009, Luca Favatella wrote:
>>> This patch adds GNU/kFreeBSD /etc/fstab and /sbin/init.
>>> Please carefully review it.
[...]
> Fine with me
On 22/07/2009, Luca Favatella wrote:
> This patch adds GNU/kFreeBSD /etc/fstab and /sbin/init.
> Please carefully review it.
Now the patch should be really attached.
Sorry for the noise.
Index: debian/changelog
===
---
This patch adds GNU/kFreeBSD /etc/fstab and /sbin/init.
Please carefully review it.
I'm proposing both together because they are closely related.
This patch should not affect GNU/Linux builds and has been in the
kfreebsd d-i branch for a while.
Cheers,
Luca Favatella
--
To UNSUBS
Hi,
On Friday 01 May 2009 09:24:11 Christian Perrier wrote:
> Quoting Justin B Rye (j...@edlug.org.uk):
> > "Possible FreeBSD keyboards" are the keyboard-layouts that are
> > available for FreeBSD (the things you switch between by using the
> > command referred to in the previous line). FreeBSD
Quoting Justin B Rye (j...@edlug.org.uk):
> "Possible FreeBSD keyboards" are the keyboard-layouts that are
> available for FreeBSD (the things you switch between by using the
> command referred to in the previous line). FreeBSD apparently uses
> things like /usr/share/syscons/keymaps/finnish.iso
Esko Arajärvi wrote:
> Description: command-line tool to change FreeBSD keyboard layout
> This package provides the original FreeBSD command to set keyboard layout
> and
> the FreeBSD possible
> keyboards.
>
> The part "and the FreeBSD possible keyboards" is (to me) somewhat confusing.
> Just
On Thursday 30 April 2009 08:37:38 Christian Perrier wrote:
> This is the last call for comments for the review of debconf
> templates for freebsd-utils.
>
> The reviewed templates will be sent on Saturday, May 02, 2009 to the
> package maintainer as a bug report and a mail will be sent to this lis
rol/keymap
Type: select
Choices: ${choices}
Default: none
Description: Keymap:
Please choose the keyboard map.
.
If in doubt, don't choose any map. You can always come back to
this question with "dpkg-reconfigure kbdcontrol".
Template: module-init-tools/network
Type: multi
Marco d'Itri wrote:
On Apr 22, Matthew Lockner wrote:
What kind of crap am I looking for?
Anything related to snd* modules for a start.
properly. If we as users can't expect to be able to use this file
anymore, it would be user-friendlier for the package upgrade to tell us
so
Marco d'Itri wrote:
On Apr 22, Matthew Lockner wrote:
Since its postinst is my means of demonstrating the problem, then of
course removing the package will prevent the problem from appearing, at
least in this context.
You can remove it and manually run modprobe.
Anyway, I am quite
On Apr 22, Matthew Lockner wrote:
> What kind of crap am I looking for?
Anything related to snd* modules for a start.
> properly. If we as users can't expect to be able to use this file
> anymore, it would be user-friendlier for the package upgrade to tell us
> so and state the correct alte
Marco d'Itri wrote:
On Apr 22, Matthew Lockner wrote:
The strongest evidence is that if I downgrade module-init-tools to the
prior version and hold the prior version and hold the package, the
problem goes away. I'd find the next most likely candidate to be
Not very
On Apr 22, Matthew Lockner wrote:
> Since its postinst is my means of demonstrating the problem, then of
> course removing the package will prevent the problem from appearing, at
> least in this context.
You can remove it and manually run modprobe.
Anyway, I am quite sure that there is some c
On Apr 22, Matthew Lockner wrote:
> The strongest evidence is that if I downgrade module-init-tools to the
> prior version and hold the prior version and hold the package, the
> problem goes away. I'd find the next most likely candidate to be
Not very compelling evidence.
T
evidence is that if I downgrade module-init-tools to the
prior version and hold the prior version and hold the package, the
problem goes away. I'd find the next most likely candidate to be
oss-compat's postinst script, but downgrading that package does nothing
if you still have t
On Apr 21, "Matthew J. Lockner" wrote:
> I suspect this will be unreproducible since it hasn't been reported yet that
I definitely never experienced this on my system.
Anyway, I have no reason to believe this to be a m-i-t bug.
Please show the content of /etc/modprobe.d/oss-compat.conf.
Are you s
Package: module-init-tools
Version: 3.7-pre9-1
Severity: important
I recently did an "aptitude upgrade". I found that when the postinst of the
oss-compat package was run during configuration of packages, I got a
screenful of warnings, and found a long list of modprobe and "sh modp
Quoting Justin B Rye (j...@edlug.org.uk):
> Christian Perrier wrote:
> > Your review should be sent as an answer to this mail.
>
> I'm having trouble generating a patch here, since freebsd-utils
> 7.1-5 in Sid doesn't have a module-init-tools.templates file. Th
Christian Perrier wrote:
> Your review should be sent as an answer to this mail.
I'm having trouble generating a patch here, since freebsd-utils
7.1-5 in Sid doesn't have a module-init-tools.templates file. The
changelog for 7.1-4 says "Rename module-init-tools to kldutils&quo
r standard formula here "If in doubt...".
--- freebsd-utils.old/debian/module-init-tools.templates2009-04-14
21:47:59.795981291 +0200
+++ freebsd-utils/debian/module-init-tools.templates2009-04-14
22:35:56.143982264 +0200
@@ -2,30 +2,30 @@
Type: multiselect
Choices:
Dear Debian maintainer,
The Debian internationalisation team and the Debian English
localisation team will soon begin the review of the debconf
templates used in freebsd-utils.
This review takes place for all packages that use debconf to interact with
users and its aims are:
- to improve the use
Subject: module-init-tools: Recent upgrade broke module auto-loading
Package: module-init-tools
Version: 3.7-pre9-1
Severity: important
After booting today, several essential modules were not loaded at
bootup, giving me a barely functional system (no sound and no external
drives). The missing
able enough for /bin/sh):
--- module-init-tools.orig Wed May 16 19:05:53 2007
+++ module-init-tools Wed May 16 19:09:37 2007
@@ -27,12 +27,14 @@ do_start() {
for i in load stat unload ; do
which kld$i >/dev/null || exit 1
done
- modules="`shopt
On Tue, 15 May 2007, Marco d'Itri wrote:
> On May 15, Thorsten Glaser <[EMAIL PROTECTED]> wrote:
>
> > Package: module-init-tools
> > Version: 6.2-3
>
> Why do I keep receiving bugs for a kfreebsd-i386 package which I do not
> maintain?
Because people are
Marco d'Itri dixit:
>On May 15, Thorsten Glaser <[EMAIL PROTECTED]> wrote:
>
>> Package: module-init-tools
>> Version: 6.2-3
>
>Why do I keep receiving bugs for a kfreebsd-i386 package which I do not
>maintain?
No idea, in this case I suspect there are two
Marco d'Itri wrote:
> On May 15, Thorsten Glaser <[EMAIL PROTECTED]> wrote:
>
>> Package: module-init-tools
>> Version: 6.2-3
>
> Why do I keep receiving bugs for a kfreebsd-i386 package which I do not
> maintain?
Because of this:
X-Original-To: debi
On May 15, Thorsten Glaser <[EMAIL PROTECTED]> wrote:
> Package: module-init-tools
> Version: 6.2-3
Why do I keep receiving bugs for a kfreebsd-i386 package which I do not
maintain?
--
ciao,
Marco
signature.asc
Description: Digital signature
em.
> > Here is the report as generated by reportbug:
> > Package: module-init-tools
> > Version: 6.2-3
> > Severity: normal
> >
> > The initscript module-init-tools uses /usr/bin/sort and /usr/bin/uniq
> > while /usr may not yet be mounted. Worst, it is t
ntent compared to Linux one (and is from different source package).
There is a small number of such kfreebsd specific packages,
this one belongs to them.
Here is the report as generated by reportbug:
Package: module-init-tools
Version: 6.2-3
Severity: normal
The initscript module-init-tools uses
I tried to report it using reportbug, but it ended in Debian's official
BTS as #423662 (so maybe this is another bug to report) and was almost
instantly closed. Feel free to point me to the right place to report.
Here is the report as generated by reportbug:
Package: module-init-tools
Ve
1 - 100 of 128 matches
Mail list logo
