Re: Stepping the clock during boot
[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. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flaap45dpx@login2.uio.no
Re: which gfortran version is used to compile liblapack.so.3gf.0
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 it > does not have any build logs fro 3.2.1-8 It was built on maintainer's machine, so no public build-log. Anyway, assuming he had an up-to-date building environment at the time, you can check amd64 log[1], which shows gfortran-4.4_4.4.3-9. But you'd better ask the maintainer directly. Ciao, Luca [1] https://buildd.debian.org/fetch.cgi?pkg=lapack;ver=3.2.1-8;arch=amd64;stamp=1272412251 -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpUfuLKwocmv.pgp Description: PGP signature
When the init.d script exist, the service should be operational
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 operational. Based on this assumption, it is then safe to start new services that the depend on the already started service and expect them to find the services they need. This means that init.d scripts should not exit at boot before the service they start is operational, and in the common case, this mean service daemons should have loaded their configuration and started listening on their sockets before the init.d script ends. This is not the case with some of the services in Debian, and this causes race conditions in the boot. Two bugs are reported already for pdns (#585966) and slapd (#589915), but I expect there to be more of these problems. These bugs are easier to expose with parallel booting based on dependencies, but was also present earlier with the static boot ordering. Some of them were hidden by chance, thanks to the slow boot, but are now exposed because the boot happen faster than before. 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. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl4ofc5bka@login2.uio.no
Re: When the init.d script exist, the service should be operational
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 decreases the parallelisation factor and it won't help with temporarily disappearing daemons, for instance during upgrades or other restarts. A superior paradigm (IMHO) is to move the burden to client developers to implement retry schemes. Hence, connect() becomes an asynchronous and otherwise fault-tolerant operation. For example, many applications relying on persistent SQL server connections currently break when the server is restarted - shouldn't the goal be to not let them break when the service is temporarily not available? Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008031112.21654.2...@kuarepoti-dju.net
Re: Stepping the clock during boot
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 ntpdate, I'm not sure which) would correct the time, the clock would move backwards 30 seconds or so and dovecot would crash. I can add an "X-Starts-Before: dovecot" line to protect dovecot. I think that ideally chrony would replace hwclock as provider of $time when present but I don't know how to arrange that... 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 the /etc/insserv.conf.d files work. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1008031008260.2...@jago.allcutt.me.uk
More advanced home directory creation in Debian?
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 /etc/skel to the freshly created home directory, and the ownership of the files are set to the created user. Some tools will run some scripts after /etc/skel/ is created, but the location of these scripts differ from system to system. This of cause causes the created users home directories to have different content depending on how they are created. Typical use cases are setting up mail client to use the correct mail server and other connection defaults and adding KDE and Gnome shortcuts to the network home directory for a user. It would be nice if all the tools copying /etc/skel/ also had a common location for their "post-creating" scripts, making sure users created by for example adduser, lwat, libpam-mkhomedir and libpam-mklocaluser get the same content. The location could for example be /etc/skel.d/, and the scripts should be called with the path to the new home directory, the name of the user, and uid and gid of the user, and perhaps some more information that is needed. This information could either be arguments, or stored in the environment. Are there better ways to do this? If this is a good idea, I suggest we extend adduser in Debian to use it first, and then move on to change other packages to use this location too. I suspect it is best to create a new tool for creating the home directory, to make sure all user creation tools call these .d scripts the same way. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flzkx43vx5@login2.uio.no
Re: Stepping the clock during boot
[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 the /etc/insserv.conf.d > files work. It will add it to the existing line. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flpqy03upz@login2.uio.no
Re: Seeking machines for nightly builds of ITK
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 | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100803094149.gg27...@anguilla.noreply.org
Bug#591460: ITP: libcache-memcached-managed-perl -- Memcached storage backend for Catalyst
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 Lang: Perl Description : Memcached storage backend for Catalyst Catalyst::Plugin::Session::Store::Memcached is a session storage plugin for Catalyst that uses the Cache::Memcached::Managed module to connect to memcached, a fast data caching server. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100803102521.27006.70761.report...@labrie.wayforth.com
Re: which gfortran version is used to compile liblapack.so.3gf.0
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 testing branch, 3.2.2-1 package on i386 in the Debian sid branch thanks raju Kamaraju S Kusumanchi wrote: > 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 it does not > have any build logs fro 3.2.1-8 > > Why I need this? I am having some segmentation fault issues with code > compiled with gfortran-4.4 but not with gfortran-4.3. When I asked the > question on gfortran mailing lists ( > http://gcc.gnu.org/ml/fortran/2010-08/msg00022.html ) one of the > developers of gfortran wanted to know this info. > > thanks > raju -- Kamaraju S Kusumanchi http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i38sas$br...@dough.gmane.org
Bug#591463: ITP: libcache-memcached-managed-perl -- API for managing cached information with memcached
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 Description : API for managing cached information with memcached Cache::Memcached::Managed provides an API to values cached in one or more memcached servers. It is similar to the API of Cache::Memcached but also allows for management of groups of values for simplified key generation and expiration, as well as version and namespace management and a few other goodies. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100803105407.27818.80601.report...@labrie.wayforth.com
Re: Stepping the clock during boot
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"). A "Should-Start" might suffice, though. -- John Hasler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6cnao4i@thumper.dhh.gt.org
Re: Stepping the clock during boot
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 existing line. That wouldn't really help as hwclock is always present and would satisfy the $time requirements before chrony started. -- John Hasler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tynbamn7@thumper.dhh.gt.org
Re: Stepping the clock during boot
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 UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqxzamgf@thumper.dhh.gt.org
Re: Stepping the clock during boot
[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 depending on $time will start. PS: Peter Reinholdtsen is my cousin. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl7hk7g5ae@login1.uio.no
Bug#591494: ITP: bambam -- Keyboard masher game for babies
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 babies Bambam is a simple baby keyboard masher application that locks the keyboard and mouse and instead displays bright colors, pictures, and sounds. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100803151757.30543.30824.report...@ripps-desktop.eau.wi.charter.com
Re: Stepping the clock during boot
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 $time chrony guarantees that no script depending on $time will start before chrony does. No, wait. Chrony depends on things that depend indirectly on $time (so does ntp, IIRC). -- John Hasler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6cn9070@thumper.dhh.gt.org
Re: When the init.d script exist, the service should be operational
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 approach: It decreases the parallelisation >factor But allows you much more control over the parallelisation, such that it might actually work reliably. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ogjdo-0004ym...@jack.mossbank.org.uk
Re: When the init.d script exist, the service should be operational
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 script exits. > There are two disadvantages to this approach: It decreases the > parallelisation > factor ... only between services that have declared a dependency relationship, which should obviously *not* be started in parallel. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: When the init.d script exits [typo fixed], the service should be operational
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 not a package dependency. And the only reason the ordered runtime dependency exists is because dhcpd cannot handle the fact that the DNS server is not running. So once dhcpd is fixed to only return its results after having successfully contacted the DNS server, the runtime dependency loses its ordering requirement, allowing pdns to be started at any time after dhcpd without waiting for some (potentially buggy and never returning) init.d script to finish. Depending on the type of daemon, there might already be some functions offered at this point (e.g., logging) while more functions are being offered once the dependency service has also been started (e.g., query interface). What am I missing here? Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008031902.12711.2...@kuarepoti-dju.net
Re: Stepping the clock during boot
[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 Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl1vaffvth@login1.uio.no
Bug#591528: ITP: livetribe-jsr223 -- Implementation of JSR 223: Scripting for Java
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 223: Scripting for Java This library allows bundling scripting pages into a WAR file, either stand-alone, or as part of an EAR. The full specification can be found at http://jcp.org/en/jsr/detail?id=223 . -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100803183817.3696.50399.report...@twerner
Re: When the init.d script exits [typo fixed], the service should be operational
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, dhcpd runtime-depends on pdns through some > configuration option. This is not a package dependency. I didn't say package dependency. The only reason this question arises is *because* one service may depend on another to be started first. If there is no dependency relationship *between the services*, they may *already* be started in parallel; so requiring the service to be running before the init script returns neither impacts parallelization in that case, nor benefits services whose init scripts don't specify dependencies. > What am I missing here? Common sense, which dictates that whatever interface a service promises, that interface should be available before the init script returns a successful exit code to the caller. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Stepping the clock during boot
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, shouldn't (or at least should only require hwclockfirst). I also don't see that we still need two hwclock scripts. Then ntp, chrony, and hwclock could provide $time and only those packages that really need exact time should require it. If the clock gets stepped at bootup that fact will be quite obvious in the logs so $syslog should be able live with the rare stepping. I think I'll have chrony require hwclockfirst and add "X-Start-Before"s for packages such as dovecot that stepping might break (so if you know of such a package tell me). -- John Hasler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj8n8pp5@thumper.dhh.gt.org
Re: Stepping the clock during boot
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. -- John Hasler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3tz8dm6@thumper.dhh.gt.org
mass bug filing: packages not installable on any architecture
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 daily analysis done by edos-debcheck, the results of which is available on edos.debian.net/edos-debcheck/. Packages can be temporarily uninstallable in sid and on some architectures for all possible transient reasons, so I think a good start would be packages that (1) do not install on *any* architecture and (2) are not installable for a certain length of time (e.g., 1 month) In that case I would file a bug with severity=grave since the package is not usable for all, or at least a large number of, users. Currently there are 68 packages that satisfy (1), I didn't check for (2) yet: http://edos.debian.net/edos-debcheck/results/unstable/latest/every/list.php Any opinions? -Ralf -- Ralf Treinen Laboratoire Preuves, Programmes et Systèmes Université Paris Diderot, Paris, France. http://www.pps.jussieu.fr/~treinen/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100803235055.ga8...@uranium.pps.jussieu.fr
Re: mass bug filing: packages not installable on any architecture
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 -- Daniel E. Markle http://ashtech.net/~syntax/ signature.asc Description: Digital signature
Re: mass bug filing: packages not installable on any architecture
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 I'd better ask here whether that would be OK. > > The source is the daily analysis done by edos-debcheck, the results of > which is available on edos.debian.net/edos-debcheck/. Packages can be > temporarily uninstallable in sid and on some architectures for all > possible transient reasons, so I think a good start would be packages > that > (1) do not install on *any* architecture and > (2) are not installable for a certain length of time (e.g., 1 month) > In that case I would file a bug with severity=grave since the package > is not usable for all, or at least a large number of, users. > > Currently there are 68 packages that satisfy (1), I didn't check for > (2) yet: > > http://edos.debian.net/edos-debcheck/results/unstable/latest/every/list.php > > Any opinions? -Ralf I think some of these are old versions of arch:all packages that for some reason have not been automatically removed. I think you should consider only the latest version of each binary package available in the suite. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
