[John Hasler]
> Would it be unacceptable for Chrony to step the clock (particularly
> back) during boot?
If you are going to do this, it might be a good idea to try to do it
before the syslog collector starts, as most daemons depend on $syslog
and would thus start after the clock is correct.
Happ
Kamaraju S Kusumanchi scrisse:
> Is there a way to find out the version of gfortran compiler used to
> build /usr/lib/lapack/liblapack.so.3gf.0 in the package liblapack3gf
> 3.2.1-8 on i386 Debian testing machine? I tried looking at
> https://buildd.debian.org/build.php?arch=i386&pkg=lapack . But
During my work on dependency based boot sequencing and parallel
booting, I have ran across bugs in packages exposed by the new boot
ordering, and thought it best to mention it here.
The SysV boot system runs init.d scripts in sequence with the
assumption that when a script exits, its service is o
In data martedì, 3. di agosto 2010 10:45:41, Petter Reinholdtsen ha scritto:
> If you maintain a package with a service started during boot using a
> init.d script, please make sure your service is operational when the
> init.d script exits.
There are two disadvantages to this approach: It decreas
On Tue, 3 Aug 2010, John Hasler wrote:
I wrote:
Well, it's a reason. But note that such backward stepping would only
happen when your clock is really screwed up.
brian writes:
It actually used to happen every reboot of my server, which is why I'm
aware of the dovecot problem. When ntp (or n
I got this idea from Debian Edu, where we need to run scripts when a
user is created to create files adjusted for each user, and we would
like this to work with any tool used to create users.
At the moment, a users home directory is created by adduser and other
tools by copying the content of /et
[Edward Allcutt]
> You could append +chrony to the $time line in /etc/insserv.conf as a local
> fix. You might be able to ship a /etc/insserv.conf.d/chrony that to that
> effect but I'm unsure whether that would replace or add to the existing
> line. I couldn't find documentation on exactly how th
On Tue, 03 Aug 2010, Steve M. Robbins wrote:
> Can I use the official Debian developer machines for this task?
As long as you do it manually.
Maybe an alternative is to upload packages to experimental.
--
| .''`. ** Debian GNU/Linux **
Peter Palfrader |
Package: wnpp
Severity: wishlist
Owner: Antony Gelberg
* Package name: libcache-memcached-managed-perl
Version : 0.04
Upstream Author : 0.04
* URL :
http://search.cpan.org/dist/Catalyst-Plugin-Session-Store-Memcached/
* License : GPL / Artistic
Programming L
Hi Sylvester,
I was told to ask you directly for this information as the lapack packages
for i386 were built on your computer. Could you please let me know which
gfortran version was used to generate /usr/lib/lapack/liblapack.so.3gf.0 in
the liblapack3gf package 3.2.1-8 on i386 in the Debian test
Package: wnpp
Severity: wishlist
Owner: Antony Gelberg
* Package name: libcache-memcached-managed-perl
Version : 0.20
Upstream Author : Elizabeth Mattijsen
* URL : http://search.cpan.org/dist/Cache-Memcached-Managed/
* License : GPL-2
Programming Lang: Perl
Jaldhar H. Vyas writes:
> I haven't really looked into the new dependency-based stuff so this
> might be a naive question but wouldn't "X-Starts-After: chrony" in
> dovecots init script be a better idea?
There is no such thing as far as I know (and I should have written
"X-Start-Before": no "s").
Edward Allcutt writes:
> You could append +chrony to the $time line in /etc/insserv.conf as a
> local fix. You might be able to ship a /etc/insserv.conf.d/chrony that
> to that effect but I'm unsure whether that would replace or add to the
> existing line.
As Peter says, it would add it to the exi
Petter Reinholdtsen writes:
> If you are going to do this, it might be a good idea to try to do it
> before the syslog collector starts, as most daemons depend on $syslog
> and would thus start after the clock is correct.
Unfortunately, chrony also wants $syslog.
--
John Hasler
--
To UNSUBSCRI
[John Hasler]
> As Peter says, it would add it to the existing line. That wouldn't
> really help as hwclock is always present and would satisfy the $time
> requirements before chrony started.
Actually, it would help, because all the parts making up $time need to
be satisfied before those dependi
Package: wnpp
Severity: wishlist
Owner: "Taylor LeMasurier-Wren"
* Package name: bambam
Version : 0.3
Upstream Author : Spike Burch
* URL : https://launchpad.net/bambam
* License : GPL
Programming Lang: Python
Description : Keyboard masher game for ba
Petter Reinholdtsen writes:
> Actually, [a chrony file in insserv.conf.d] would help, because all
> the parts making up $time need to be satisfied before those depending
> on $time will start.
Then that solves my problem (should apply to ntp too) if adding a file to
insserv.conf.d containing
$tim
Josef wrote:
>In data martedì, 3. di agosto 2010 10:45:41, Petter Reinholdtsen ha scritto:
>> If you maintain a package with a service started during boot using a
>> init.d script, please make sure your service is operational when the
>> init.d script exits.
>
>There are two disadvantages to this a
On Tue, Aug 03, 2010 at 11:12:21AM +0200, Josef Spillner wrote:
> In data martedì, 3. di agosto 2010 10:45:41, Petter Reinholdtsen ha scritto:
> > If you maintain a package with a service started during boot using a
> > init.d script, please make sure your service is operational when the
> > init.d
Am Dienstag, 3. August 2010, 18:24:09 schrieb Steve Langasek:
> ... only between services that have declared a dependency relationship,
> which should obviously *not* be started in parallel.
In the example given by Petter, dhcpd runtime-depends on pdns through some
configuration option. This is n
[John Hasler]
> No, wait. Chrony depends on things that depend indirectly on $time
> (so does ntp, IIRC).
Yes, such change need to be done very carefully and in stages, to
avoid dependency loops. See #542602 for a discussion on the ntp order
relative to $syslog. :)
Happy hacking,
--
Petter Rei
Package: wnpp
Severity: wishlist
Owner: Torsten Werner
* Package name: livetribe-jsr223
Version : 2.0.6
Upstream Author : Alan D. Cabrera
* URL : http://www.livetribe.org/
* License : Apache-2.0
Programming Lang: Java
Description : Implementation of JSR
On Tue, Aug 03, 2010 at 07:02:12PM +0200, Josef Spillner wrote:
> Am Dienstag, 3. August 2010, 18:24:09 schrieb Steve Langasek:
> > ... only between services that have declared a dependency relationship,
> > which should obviously *not* be started in parallel.
> In the example given by Petter, dhc
Petter Reinholdtsen writes:
> Yes, such change need to be done very carefully and in stages, to
> avoid dependency loops. See #542602 for a discussion on the ntp order
> relative to $syslog.
After some research I'm tending to think that many (if not most) of the
scripts that require $time, should
I wrote:
> After some research I'm tending to think that many (if not most) of
> the scripts that require $time, shouldn't (or at least should only
> require hwclockfirst). I also don't see that we still need two
> hwclock scripts.
BTW hwclockfirst.sh and hwclock.sh add about a 1.5 second delay.
Hi,
I started to file bugs against packages that are not installable on any
architecture. There were only a handful of them in testing, but now I am
turning to unstable and that now more looks like a mass bug filing. So
I reckoned I'd better ask here whether that would be OK.
The source is the d
On Wed, Aug 04, 2010 at 01:50:55AM +0200, Ralf Treinen wrote:
> I started to file bugs against packages that are not installable on any
I am working on xtrkcad (on your list) at Debconf now. It already has a bug
filed for this issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549039
--
On Wed, 2010-08-04 at 01:50 +0200, Ralf Treinen wrote:
> Hi,
>
> I started to file bugs against packages that are not installable on any
> architecture. There were only a handful of them in testing, but now I am
> turning to unstable and that now more looks like a mass bug filing. So
> I reckoned
28 matches
Mail list logo
