Re: kernel-image-2.2.20-udma100-ext3, initrd and ext3
Marek Andricik <[EMAIL PROTECTED]> wrote:
> I have had some HW problems with my computer which resulted in many
> hangups and long fsck each boot, so I decided to switch to ext3. There
> were no problem except that root fs was still mounted as ext2. Kernel
> is kernel-image-2.4.17-586tsc version 2.4.17-1 from the distribution.
> The loadmodules script in the initrd does not load ext3. When I added
> modprobe -k ext3 my problem was solved. I'd like to ask you if it is
> the right way how to solve the problem.
1. Make sure you've got initrd-tools 0.1.14 or later.
2. Set ext3 as the type of your root fs in fstab.
3. Regenerate the initrd image
mkinitrd -o /boot/initrd.img-2.4.17-586tsc /lib/modules/2.4.17-586tsc
4. Run lilo
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Work-needing packages report for Jan 11, 2002
On Fri, Jan 11, 2002 at 11:26:01PM +0100, Tollef Fog Heen wrote: > * > > |libqt3-psql (#127709), orphaned 7 days ago > > Uhm, shouldn't Daniel Stone or Cheney (sp?) take this one as well, I > guess it builds with the rest of qt3. I'm not sure if Chris is taking this along with libqt3. > |qt-embedded (#127696), orphaned 7 days ago > | Description: Embedded version of QT > | Reverse Depends: libqt-emb-dev > | > |qt-embedded-free (#127697), orphaned 7 days ago > | Reverse Depends: libqt3-emb-dev > | > |qt-x11-free (#127695), orphaned 7 days ago > | Description: QT Gui Library > | Reverse Depends: libqt3-mysql libqxt0 libqt3-odbc view3ds qt3-tools > | libqt3-mt-dev libqt3-dev kascade psi > > And those? qt-x11 is qt2, qt-x11-free is qt3. Chris has been busy getting Qt2 and KDE2.2 working fully before he turns his attention to Qt3 and KDE3. His hard drive just also died, so give him a little breathing room. -- Daniel Stone<[EMAIL PROTECTED]> * wiggy points people to arcanum.co.nz apparently it's fun wiggy: the last time you said that we lost an entire weekend of useful activity to cocklefighting pgpI3Wyl2F7Mg.pgp Description: PGP signature
Re: [kde] and, for my next trick ...
On Fri, Jan 11, 2002 at 09:14:21AM -0800, Aaron Lehmann wrote: > There appears to be a list named debian-kde. PLEASE use that. -devel > is already clogged enough, and should be reserved for extremely > general or miscellaneous discussion. Date: Thu, 10 Jan 2002 17:17:08 +1100 From: Daniel Stone <[EMAIL PROTECTED]> To: debian-kde@lists.debian.org Cc: debian-devel@lists.debian.org Subject: [kde] and, for my next trick ... Oh, there *appears* to be one? You mean the one I sent this message to, and the one that I'm subscribed to? Right! Thanks for the information! I sent it to -devel because not all KDE users are subscribed to -devel. Aaron, try thinking before you open your mouth to spurt shit. It can and will work wonders. -- Daniel Stone<[EMAIL PROTECTED]> the UI SUCKS GOAT TESTICLES! oh c'mon Robot101, don't hold back... tell us what you *really* think yeah, do you feel that way all over or just in spots? pgpparspz7MLz.pgp Description: PGP signature
Re: Installed wajig 0.2.11-1 (i386 source)
Steve Kowalik <[EMAIL PROTECTED]> cum veritate scripsit:
> > That's a bug in python2.{1,2} then. What's the point of having a platform
> > neutral 'compiled' version of a script if the format changes every time the
> > wind changes direction?
> FUD. Pure FUD.
I don't care what FUD is, but apparently I still don't know the
answer to my initial question.
How should python scripts be packaged ?
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Re: OpenPKG vs. APT
Will Lowe, on 2002-01-11, 16:12, you wrote:
> Err, the security implications of such a scheme are kinda
> imposing.
Of course you are right.
> Simpler to use an existing tool like ssh to do the
> authentication. I have a network of ~80 Debian boxen, and I do
> something rougly like this:
>
> for host in `cat hostlist`; do
> ssh [EMAIL PROTECTED] "apt-get update && apt-get upgrade"
> done
I meant such as I wrote 'or wrapper'. The problem is that every machine
maintains its very own dpkg/{status,available} etc. I thought of having
something central.
> If you run stable, use aptwatcher
> (http://people.debian.org/~lowe/aptwatcher) and each box will mail you
> when you need to do something to it.
Nice tool, seems to be going into some crontabs :-)
Joerg
--
Joerg "joergland" Wendland
GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A F318 57A3 7FBD 51CF 8417
pgp3nzCwZcTcb.pgp
Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
At 10:30 am, Saturday, January 12 2002, Rob Bradford mumbled: > I'm now a happy evolution user, to converyt my mail i did cat > Mail/lists/* | cat /var/spool/mail/rob > Congratulations, you get today's "Most Useless Use Of cat" award. Plague, and LART will be forthcoming. -- Steve (Reading database ... 134867 files and directories currently installed.) pgp1fyynSCxF8.pgp Description: PGP signature
Re: Help with configure failure on ia64 [ogle: misdetect libxml2 version]
On Fri, 2002-01-11 at 20:37, Bdale Garbee wrote: > [EMAIL PROTECTED] (Mikael Hedin) writes: > > > ogle doesn't build on ia64, and I don't understand what's causing it. > ... > > The configure script stops when testing xml2-config, but the correct > > version is on the system. > > This often indicates that the configure script is trying to run a small > test program and the test program is seg faulting at run time. Which is exactly the case here, but I'm not sure why: after looking into it, gcc gives warnings on a couple of lines (pointer to integer assignments), but those lines contain char* to char* assignments (in configure - actually, the particular lines mentioned are comments, but I assume there's an off-by-one bug.). In short, I'm stumped. Is there any way to get configure to leave its failed test programs lying around so we can see what went wrong? -- Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Please encrypt email sent to me.
Re: Help with configure failure on ia64 [ogle: misdetect libxml2 version]
On Sat, Jan 12, 2002 at 01:36:19AM +0100, Mikael Hedin wrote: > ogle doesn't build on ia64, and I don't understand what's causing it. > See > http://buildd.debian.org/fetch.php?&pkg=ogle&ver=0.8.2-2&arch=ia64&stamp=1010455931&file=log&as=raw > for the latest build log. Also look at > caballero.d.o:~micce/ogle-0.8.2 for my test configure (e.g. config.log). The > configure script stops when testing xml2-config, but the correct version is > on the system. The configure script has a bad test program. It is generated from aclocal.m4 which is normally generated by the upstream developer. If you don't want to rerun aclocal etc. this patch should suffice: [EMAIL PROTECTED]:~/ogle-0.8.2$ diff -u ~micce/ogle-0.8.2/configure configure --- /home/micce/ogle-0.8.2/configureFri Dec 7 17:45:21 2001 +++ configure Sat Jan 12 01:25:05 2002 @@ -17410,6 +17410,7 @@ #include #include #include +#include int main() Worked for me anyway. Or change aclocal.m4 in the same way... Rerunning aclocal and autoconf should suffice but did not work with this error: aclocal: configure.in: 10: macro `AM_PROG_AS' not found in library So either use the patch above or patch aclocal.m4 and run autoconf. BTW: The failure is because strdup is expected to return an int without string.h which is too short to hold a pointer on ia64. Kudos to Matthew Wilcox for telling me how big they really are ;) HTH Torsten pgpAB2k2yd9IY.pgp Description: PGP signature
Re: Help with configure failure on ia64 [ogle: misdetect libxml2 version]
[EMAIL PROTECTED] (Mikael Hedin) writes: > ogle doesn't build on ia64, and I don't understand what's causing it. ... > The configure script stops when testing xml2-config, but the correct > version is on the system. This often indicates that the configure script is trying to run a small test program and the test program is seg faulting at run time. Bdale
wnpp page down?
Hi all, As of a of minutes ago, the wnpp page shows no packages up for adoption, none orphaned, none withdrawn, none being worked on, etc. If this is true, it's a milestone for Debian.-:) Cheers, JimS
Re: Libtool, plugins and static libraries
> *** Warning: libtool could not satisfy all declared inter-library > *** dependencies of module libsmpeg_xmms. Therefore, libtool will > create > *** a static module, that should work as long as the dlopening > *** application is linked with the -dlopen flag. > > Now, I only have direct access to i386 and hppa boxes, which both > frustratingly work perfectly with smpeg-xmms, so I can't fix this > easily. Does anybody have any idea how to force libtool to make .so > files? Is it possible to fix this any other way? FYI, I think I've found a solution to this. See bug 120515: libtool was assuming that ARM (and anything it didn't recognise) was using glibc 2.1.1 or lower, and therefore making things fail. Re-running libtoolize (with package 1.4.2-4 or higher) should fix this problem. -- Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Please encrypt email sent to me.
Re: Scheduled downtime for murphy.debian.org(lists.debian.org)
On Fri, Jan 11, 2002 at 12:08:13AM -0500, Matt Zimmerman wrote: > > Brainfood is scheduling downtime for murphy.debian.org(which is also > > lists.debian.org, and runs all the mailing lists), to do a disk upgrade. > > This > > is just the addition of a new drive, with no copying of the existing data. > > We > > expect downtime to be minimal. > > > > The time for this maintenance is scheduled for Friday, January 11, at 9pm > > UTC. > > This is 3pm local time, for murphy. > > Shouldn't this kind of thing go to debian-devel-announce? No, why? No mail will be lost, and nobody really cares if they get list mails half an hour later... -- 2. That which causes joy or happiness.
Re: Should I rename scalable-cyrfonts?
On Wed, Jan 09, 2002 at 08:26:00PM +0200, Anton Zinoviev wrote: > I'am the maintainer of the package scalable-cyrfonts. It's purpose was > to contain all free scalable Cyrillic fonts I know about. However > recently the upstream of most of these fonts has added many non-Cyrillic > letters to them. Now they cover also ISO 8859-1,2,15 and will be some > of the best scalable Unicode fonts in Debian. > scalable-cyrfonts -> scalable-fonts This sounds too generic. > scalable-cyrfonts-x11 -> scalable-fonts-x11 This one should be xfonts-scalable-cyrillic or something like that. > However scalable-cyrfonts-x11 is a task-package, and its renaming will > force corresponding change in tasksel. How's that? -- 2. That which causes joy or happiness.
Re: Build dependencies, libs and buildd
On Sat, Jan 12, 2002 at 12:17:48AM +0100, Matthias Klose wrote: > my concern is, that a timely uploaded python-gnome package wanting to > be built with libfoo-dev/libfoo2 get's built by an autobuilder which > has libfoo-dev/libfoo1 available (the python-gnome source gets built > before the new libfoo-dev source). Yes, I understood why you were filing this report and thought I better ask if I am stupid not to enforce the right library version for all my build dependencies... Greetings Torsten pgpafS9WDsssq.pgp Description: PGP signature
Help with configure failure on ia64 [ogle: misdetect libxml2 version]
Hi, ogle doesn't build on ia64, and I don't understand what's causing it. See http://buildd.debian.org/fetch.php?&pkg=ogle&ver=0.8.2-2&arch=ia64&stamp=1010455931&file=log&as=raw for the latest build log. Also look at caballero.d.o:~micce/ogle-0.8.2 for my test configure (e.g. config.log). The configure script stops when testing xml2-config, but the correct version is on the system. TIA, Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Re: Temporary(?) orphaning of netsaint and my other packagen
> "Turbo" == Turbo Fredriksson <[EMAIL PROTECTED]> writes: Turbo> I'd be interested in net saint... The bugs don't look that Turbo> grave... Well if you don't want it, I do. -- Stephen "So if she weighs the same as a duck, she's made of wood."... "And therefore?"... "A witch!"
Re: OpenPKG vs. APT
> - Package installation, upgrade, deinstallation over the net[2] > [2] think of 'apt-get --host webserver.my.org install apache' > or security updates to be done on numerous machines Err, the security implications of such a scheme are kinda imposing. Simpler to use an existing tool like ssh to do the authentication. I have a network of ~80 Debian boxen, and I do something rougly like this: for host in `cat hostlist`; do ssh [EMAIL PROTECTED] "apt-get update && apt-get upgrade" done If you run stable, use aptwatcher (http://people.debian.org/~lowe/aptwatcher) and each box will mail you when you need to do something to it. -- thanks, Will
Re: Build dependencies, libs and buildd
Ben Collins writes:
> On Fri, Jan 11, 2002 at 11:15:07PM +0100, Torsten Landschoff wrote:
> > On Fri, Jan 11, 2002 at 04:05:02PM -0500, Ben Collins wrote:
> > > > binary of the newest package of each build dep available in unstable
> > > > before building the package. If that is not the case I would have to
> > > > depend on at least the library version installed on my system it seems.
> > >
> > > If the buildd for $arch only has 0.9.9 built (maybe 1.0.0 failed to
> > > build), then you have a problem.
> > >
> > > The only way to control proper build-deps is to specify them. If your
> > > package requires features in a newer version of a library, well you have
> > > to build-depend on it. That's the whole reason for having them there.
> >
> > That's obvious. What I fear could happen is that
> >
> > a) autobuilder takes my package (which works with older libgtkhtml)
> >and builds a binary
> > b) the new libgtkhtml hits the autobuilder
> > c) the resulting library is installed and the old one used by my
> >package is removed so that is it uninstallable
> >
> > IOW: My package works which whatever is the available version of that
> > package. But should I always add
> > libfoo-dev (>= `dpkg -s libfoo-dev|awk /^Ver/ {print $2}`)
> > to my build dependencies? Of should libfoo-dev suffice under normal
> > conditions?
>
> Under normal conditions, libfoo-dev should work. If say your package
> gets built with libfoo1 by the autobuilders, and then libfoo2 is
> released and the maintainer says "libfoo1 is going away, rebuild your
> packages", then you may need to do something.
my concern is, that a timely uploaded python-gnome package wanting to
be built with libfoo-dev/libfoo2 get's built by an autobuilder which
has libfoo-dev/libfoo1 available (the python-gnome source gets built
before the new libfoo-dev source).
Anthony mentioned that this is an autobuild problem, but I don't know
if this problem is already handled.
> From: Anthony Towns
>
> this bug doesn't cause problems for the autobuilders, so it needn't
> be serious right now. the python-dev bug may cause problems in future:
> if you've got a hardcoded << dependency for the packages, you need one
> for the build-depends too. the libgtkhtml-dev versioning probably needs
> to be handled by the autobuilders rather than the maintainer anyway,
> and probably isn't a bug at all.
Re: Build dependencies, libs and buildd
On Fri, Jan 11, 2002 at 05:32:13PM -0500, Ben Collins wrote: > Most people feel that not keeping older soname libs around for a certain > period is a bad idea, just for this reason. You as the package builder > shouldn't have to worry about it. Okay, thanks! cu Torsten pgp1j3ZQuywdc.pgp Description: PGP signature
Re: We still need sponsors!
On Wed, Jan 09, 2002 at 04:34:56PM +0100, Tille, Andreas wrote: > > Sounds good. Maybe we should provide a description of this technique > > somewhere within webml or ddp. > > > > WWW/doc folks: any hint about sponsorship uploading practices? > At least an FAQ would be apropriate in my opinion. > A better solution would be a paragraph in the developers reference. Quoting the Developers' Reference: 11.1 Sponsoring packages Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own, a new maintainer applicant. Sponsoring a package also means accepting responsibility for it. New maintainers usually have certain difficulties creating Debian packages - this is quite understandable. That is why the sponsor is there, to check the package and verify that it is good enough for inclusion in Debian. (Note that if the sponsored package is new, the FTP admins will also have to inspect it before letting it in.) Sponsoring merely by signing the upload or just recompiling is definitely not recommended. You need to build the source package just like you would build a package of your own. Remember that it doesn't matter that you left the prospective developer's name both in the changelog and the control file, the upload can still be traced to you. If you are an application manager for a prospective developer, you can also be their sponsor. That way you can also verify the how the applicant is handling the `Tasks and Skills' part of their application. -- 2. That which causes joy or happiness.
Re: Work-needing packages report for Jan 11, 2002
* |libqt3-psql (#127709), orphaned 7 days ago Uhm, shouldn't Daniel Stone or Cheney (sp?) take this one as well, I guess it builds with the rest of qt3. |qt-embedded (#127696), orphaned 7 days ago | Description: Embedded version of QT | Reverse Depends: libqt-emb-dev | |qt-embedded-free (#127697), orphaned 7 days ago | Reverse Depends: libqt3-emb-dev | |qt-x11-free (#127695), orphaned 7 days ago | Description: QT Gui Library | Reverse Depends: libqt3-mysql libqxt0 libqt3-odbc view3ds qt3-tools | libqt3-mt-dev libqt3-dev kascade psi And those? |giram (#96740), offered 247 days ago | Description: 3D modeller for POV-Ray Wasn't this one supposed to be removed from the archive if no one picked it up? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Bug#122342: directory-administrator: Not installable
On Fri, Jan 11, 2002 at 10:20:59PM +0100, Turbo Fredriksson wrote: > Quoting Damyan Ivanov <[EMAIL PROTECTED]>: > > > On Fri, Dec 07, 2001 at 04:14:05PM +0100 > > Turbo Fredriksson <[EMAIL PROTECTED]> wrote: > > > This was fixed in 1.1.1-9, uploaded 2001 - Nov 27. > > > > > > Please do a 'apt-get update'... > > > > But directory-administrator 1.1.1-9 depends on libldap2 (>= 2.0.18-1), > > which is not available. The last available version is 2.0.14-1.1. > > I'm running home-made packages of OpenLDAP2... Uh, don't hardcode deps, and more importantly, don't compile against packages that aren't available. I seriously doubt that everything in 2.0.18's API works with 2.0.14. Ben -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Build dependencies, libs and buildd
On Fri, Jan 11, 2002 at 11:15:07PM +0100, Torsten Landschoff wrote:
> On Fri, Jan 11, 2002 at 04:05:02PM -0500, Ben Collins wrote:
> > > binary of the newest package of each build dep available in unstable
> > > before building the package. If that is not the case I would have to
> > > depend on at least the library version installed on my system it seems.
> >
> > If the buildd for $arch only has 0.9.9 built (maybe 1.0.0 failed to
> > build), then you have a problem.
> >
> > The only way to control proper build-deps is to specify them. If your
> > package requires features in a newer version of a library, well you have
> > to build-depend on it. That's the whole reason for having them there.
>
> That's obvious. What I fear could happen is that
>
> a) autobuilder takes my package (which works with older libgtkhtml)
>and builds a binary
> b) the new libgtkhtml hits the autobuilder
> c) the resulting library is installed and the old one used by my
>package is removed so that is it uninstallable
>
> IOW: My package works which whatever is the available version of that
> package. But should I always add
> libfoo-dev (>= `dpkg -s libfoo-dev|awk /^Ver/ {print $2}`)
> to my build dependencies? Of should libfoo-dev suffice under normal
> conditions?
Under normal conditions, libfoo-dev should work. If say your package
gets built with libfoo1 by the autobuilders, and then libfoo2 is
released and the maintainer says "libfoo1 is going away, rebuild your
packages", then you may need to do something.
Most people feel that not keeping older soname libs around for a certain
period is a bad idea, just for this reason. You as the package builder
shouldn't have to worry about it.
Ben
--
.--===-=-==-=---==-=-.
/ Ben Collins--Debian GNU/Linux \
` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] '
`---=--===-=-=-=-===-==---=--=---'
Re: Build dependencies, libs and buildd
On Fri, Jan 11, 2002 at 04:05:02PM -0500, Ben Collins wrote:
> > binary of the newest package of each build dep available in unstable
> > before building the package. If that is not the case I would have to
> > depend on at least the library version installed on my system it seems.
>
> If the buildd for $arch only has 0.9.9 built (maybe 1.0.0 failed to
> build), then you have a problem.
>
> The only way to control proper build-deps is to specify them. If your
> package requires features in a newer version of a library, well you have
> to build-depend on it. That's the whole reason for having them there.
That's obvious. What I fear could happen is that
a) autobuilder takes my package (which works with older libgtkhtml)
and builds a binary
b) the new libgtkhtml hits the autobuilder
c) the resulting library is installed and the old one used by my
package is removed so that is it uninstallable
IOW: My package works which whatever is the available version of that
package. But should I always add
libfoo-dev (>= `dpkg -s libfoo-dev|awk /^Ver/ {print $2}`)
to my build dependencies? Of should libfoo-dev suffice under normal
conditions?
Thanks
Torsten
pgp6iX6H84L2Q.pgp
Description: PGP signature
Re: SHUTDOWN: Re: Scheduled downtime for murphy.debian.org(lists.debian.org)
On Fri, 11 Jan 2002, Adam Heath wrote: > Well, it's that time. I'm leaving to go to the colo where murphy is located. > I'll be shutting it down from there. This is the warning about it's > shutdown. It's been back up for 30m now.
Re: Do not link GNOME1 apps with libpng3
On Thu, Jan 10, 2002 at 09:16:30PM -0500, Steve M. Robbins wrote: > Moreover, nobody has produced a compelling reason to make the > switch other than "libpng3 is newer than libpng2". I have one, but I won't present it, because I think there are more compelling reasons NOT to switch. I say this based on my experience upgrading an app from libpng1 to libpng2, and what I learned during that adventure: * libpng1 had a rather low-level API, with direct access to many internal structures. * libpng2 introduced a new API, but kept partial compatibility with the old API. * libpng3 was supposed to have dropped the old API. (I haven't checked for sure, but I can't imagine any reason they would have done otherwise.) This means that programs which worked with libpng2 may not compile with libpng3. (Or, in some circumstances, they might compile, but not work, which is what happened to me with the libpng2 transition.) > In the absence of such, leaving imlib1 linked with libpng2 seems to > me to be the wisest course of action, *especially* during a freeze. Very much so, yes. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Build dependencies, libs and buildd
On Fri, Jan 11, 2002 at 09:38:00PM +0100, Torsten Landschoff wrote: > Hi *, > > I got a bug report on python-gnome because a) I did not yet conform to the > new python policy (missed the dep, thanks Matthias), and b) I did not > depend on at least 1.0.0 of libgtkhtml-dev. > > Now I am wondering if I have to make all dependencies of shared libraries > more strict... I would expect that the buildd ensures that it has the > binary of the newest package of each build dep available in unstable > before building the package. If that is not the case I would have to > depend on at least the library version installed on my system it seems. If the buildd for $arch only has 0.9.9 built (maybe 1.0.0 failed to build), then you have a problem. The only way to control proper build-deps is to specify them. If your package requires features in a newer version of a library, well you have to build-depend on it. That's the whole reason for having them there. Ben -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Bug#122342: directory-administrator: Not installable
Quoting Damyan Ivanov <[EMAIL PROTECTED]>: > On Fri, Dec 07, 2001 at 04:14:05PM +0100 > Turbo Fredriksson <[EMAIL PROTECTED]> wrote: > > This was fixed in 1.1.1-9, uploaded 2001 - Nov 27. > > > > Please do a 'apt-get update'... > > But directory-administrator 1.1.1-9 depends on libldap2 (>= 2.0.18-1), > which is not available. The last available version is 2.0.14-1.1. I'm running home-made packages of OpenLDAP2... I'd like to hardcode the dependency for 'libldap2 (>= 2.0)', but can't figure out how to do this in my controls/rules file... Any ideas? -- We are GNU. You will be GPL'ed. Resistance is futile. / \ / \ / \ / \ / \ / \ Turbo Fredriksson <[EMAIL PROTECTED]> ( D | e | b | i | a | n ) Debian Certified Linux Developer \_/ \_/ \_/ \_/ \_/ \_/ Stockholm/Sweden Please always Cc to me when replying to me on the lists.
Re: Temporary(?) orphaning of netsaint and my other packagen
Quoting Ben Bell <[EMAIL PROTECTED]>: > I've had to take a job where they are a lot less sympathetic to me > working on Open Source projects. Ouch. Sorry to hear that... Ah, well. They probably pay good :) > Therefore if anyone wishes to consider netsaint*, toppler or anything > else I have up for adoption they can claim it. I'd be interested in net saint... The bugs don't look that grave... -- Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just ^/ /(_)_ __ _ ___ __ selective about who its friends are / / | | '_ \| | | \ \/ /Debian Certified Linux Developer _ /// / /__| | | | | |_| |> < Turbo Fredriksson [EMAIL PROTECTED] \\\/ \/_|_| |_|\__,_/_/\_\ Gothenburg/Sweden bomb radar Serbian Ft. Meade quiche smuggle nuclear class struggle assassination Cuba domestic disruption arrangements Kennedy CIA FBI [See http://www.aclu.org/echelonwatch/index.html for more about this]
SHUTDOWN: Re: Scheduled downtime for murphy.debian.org(lists.debian.org)
On Thu, 10 Jan 2002, Adam Heath wrote: > Brainfood is scheduling downtime for murphy.debian.org(which is also > lists.debian.org, and runs all the mailing lists), to do a disk upgrade. This > is just the addition of a new drive, with no copying of the existing data. We > expect downtime to be minimal. > > The time for this maintenance is scheduled for Friday, January 11, at 9pm UTC. > This is 3pm local time, for murphy. Well, it's that time. I'm leaving to go to the colo where murphy is located. I'll be shutting it down from there. This is the warning about it's shutdown.
Build dependencies, libs and buildd
Hi *, I got a bug report on python-gnome because a) I did not yet conform to the new python policy (missed the dep, thanks Matthias), and b) I did not depend on at least 1.0.0 of libgtkhtml-dev. Now I am wondering if I have to make all dependencies of shared libraries more strict... I would expect that the buildd ensures that it has the binary of the newest package of each build dep available in unstable before building the package. If that is not the case I would have to depend on at least the library version installed on my system it seems. Please tell me I don't have to! Thanks Torsten pgpz4VH5Pdzp7.pgp Description: PGP signature
Temporary(?) orphaning of netsaint and my other packagen
Hi all, I've had to take a job where they are a lot less sympathetic to me working on Open Source projects. I am hoping that things will improve in a few months but for the time being it is unlikely I will be able to do much work on my packages. Therefore if anyone wishes to consider netsaint*, toppler or anything else I have up for adoption they can claim it. I won't officially orphan them before woody happens as I may be able to find time to get them pushed and into the new stable, but any NMUs or other forms of help would be gratefully received. I'll even do my best to respond to emails looking for help and explanations of bizarre things I may have done :) Hoping to be back in the land of the Free soon... Ben -- +-Ben Bell - "A song, a perl script and the occasional silly sig.-+ /// email: [EMAIL PROTECTED]www: http://www.deus.net/~bjb/ bjbDon't try to drive me crazy... \_/...I'm close enough to walk.
Re: problem with debconf and start-stop-daemon
On Fri, 11 Jan 2002, Wichert Akkerman wrote: > Previously Henrique de Moraes Holschuh wrote: > > Please tell me one good reason not to use the init.d script interface to > > muck around with daemons _in maintainer scripts_? > > The --exec option for start-stop-daemon. This option is very useful: it [...] > The only problem with the --exec option is that it does not work if > you use it in the postinst after an upgrade to restart the daemon > since the binary has been replaced and will now have a different inode. Yes. When one both replace the daemon executable AND the initscript uses start-stop-daemon --exec, one has to stop the daemon in prerm. Lots of packages do this already. I believe it is the default behaviour for dh_initscript for example. Any package that is -replacing- the daemon executable should know very well what its initscript does, and how. In fact, in just about 99% of the cases, either the same binary package or source package will provide the initscript and the executable. So I will assume we are talking about a maintainer script maintained by the same person/crew that maintains the initscript. The prerm solution is a problem for those who need to shorten the downtime of the service. e.g, IDS daemons. For those, it is still possible to have a new target (say, stop-nocheck) in the init.d script that does not use --exec, exactly the way it would be done in the postinst. > 1. don't use --exec at all, not even in the init script. > 2. don't use --exec in the postinst, or use it with a saved (hardlinked) >copy of the original file Actually, I was not aware of 2). I like it. While it would be possible (but ugly) to have such an "stop-alike /usr/sbin/daemon.temp" initscript target, it would look a bit kludgy (but perfectly legal, and supported). Well, policy will say "should", not "must" for the use of invoke-rc.d and initscripts. There is no reason why we could not add a sentence to the effect of "maintainer scripts that cannot use the initscript for some reason to execute an action on the service, must verify (using invoke-rc.d --query), if they would be allowed to execute a given initscript action (stop, start, restart, reload) before doing so directly." i.e., you could either live with a new action in your init.d script (using either method 1 or 2 to stop the daemon), stop it in prerm, or call invoke-rc.d to verify if the admin frowns upon what you're going to do and if it says its ok, do the start-stop-daemon thing directly. Would that be good enough? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: kernel-image-2.2.20-udma100-ext3, initrd and ext3
On Fri, Jan 11, 2002 at 07:17:13PM +0100, Eduard Bloch wrote: > > > if not, the i would not recommend the use of auto in that case. > > It is a patch for mkinitrd well, you answered my questions! it seems then ``type auto'' would be fine, especially since the patches in question don't affect the kernel itself. -john
WARNING: xmkmf/imake broken in xutils 4.1.0-12
On Fri, Jan 11, 2002 at 03:49:12PM +, James Troup wrote: > Package: xutils > Version: 4.1.0-12 > Severity: serious > Justification: breaks other packages from building from source > > xmkmf appears to have been broken by 4.1.0-12; packages which built > fine with xutils 4.1.0-11 no longer build with 4.1.0-12. It appears > Imake.tmpl and indeed the entire contents of > /usr/X11R6/lib/X11/config/ have disappeared. YEEEARGH. This is one of those "only implemented half the change" bugs. /usr/X11R6/lib/X11/config was intended to move from xlibs-dev to xutils (since only imake cares about this directory, or uses it). Unfortunately, only half of the moving took place. I'll roll new packages ASAP. Unfortunately there is no way I can make dinstall today. -- G. Branden Robinson| I had thought very carefully about Debian GNU/Linux | comitting hara-kiri over this, but [EMAIL PROTECTED] | I overslept this morning. http://people.debian.org/~branden/ | -- Toshio Yamaguchi pgpEAuYozdI1n.pgp Description: PGP signature
Request for gs-fonts-virtual package
We really should add some gs-fonts-virtual package, gs is depending upon. LOTs of People (even some Debian Developers) wonder why their printer does not work, just because they forgot to install some gs fonts. So i'd suggest gs depending upon some fonts. If a really experienced user knows that he doesn't need the gsfonts package, he could always make a printer-builtin-fonts package. I'm not sure which package do provide fonts for gs, maybe there is no need for such a virtual package, but gs could just directly depend on the package gsfonts. and we should just add a gsfonts-minimum package or something like that and have gs Depend on gsfonts | gsfonts-minimum Greetings, Erich pgppBvKNBJYhB.pgp Description: PGP signature
Re: kernel-image-2.2.20-udma100-ext3, initrd and ext3
#include John H. Robinson, IV wrote on Fri Jan 11, 2002 um 09:49:12AM: > > All this will be easier if you use "auto" as fs type and WHEN Herbert > > Xu finally applies MY PATCH submitted a while ago. > > would type auto work with a fresh, hand compiled kernel from kernel.org? Why not? On mounting the /, the kernel's builtin autodetection is used. Later, "mount" uses its heuristic, and I did not hear about big problems in last months. Only if the ext2 module has been loaded after ext3, there may be problems, but this would be fixed with the mentioned patch. > if not, the i would not recommend the use of auto in that case. It is a patch for mkinitrd Gruss/Regards, Eduard. -- Der Wahnsinn hat Methode!
OpenPKG vs. APT
Hi fellows, today I heard about OpenPGK[1] and read its feature list. Unfortunately OpenPKG describes itself as "...the world of cross-platform RPM-based Unix software packaging". It is RPM based but cross-platform. It came to my mind that having a distributed APT would be a great help to administrators managing big networks of Debian/GNU Linux machines (just as I do). OpenPKG would solve this problem but as said is RPM based. Features I would like to have in APT or a wrapper around it: - Package installation, upgrade, deinstallation over the net[2] - dpkg-database/apt-cache queries over the net[3] - central debconf database to allow central administration like cfengine does.[4] Is this functionality that would be interesting for more people? Is anything like that in planning or even development? I would be willing to implement something like that. Regards, Joerg Notes: [1] http://www.openpgk.org [2] think of 'apt-get --host webserver.my.org install apache' or security updates to be done on numerous machines [3] imagine 'apt-cache show apache' with output: Package: apache Priority: optional Section: web Hosts: webserver.my.org (1.3.22-5), intranet.my.org (1.3.19-3) [4] Think of an SSHd installed suid which you want to reconf to not to be suid anymore. The ssh package provides a debconf interface for that. Having over 50 machines running the sshd you simply could 'dpkg-reconfigure --all-hosts ssh' and change the config for every machine running ssh. -- Joerg "joergland" Wendland GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A F318 57A3 7FBD 51CF 8417 pgp0Et6TDMYfE.pgp Description: PGP signature
Re: kernel-image-2.2.20-udma100-ext3, initrd and ext3
On Fri, Jan 11, 2002 at 03:44:54PM +0100, Eduard Bloch wrote: > > All this will be easier if you use "auto" as fs type and WHEN Herbert > Xu finally applies MY PATCH submitted a while ago. would type auto work with a fresh, hand compiled kernel from kernel.org? if not, the i would not recommend the use of auto in that case. i do not know, this is why i ask. -john
Re: problem with debconf and start-stop-daemon
Previously Henrique de Moraes Holschuh wrote: > Please tell me one good reason not to use the init.d script interface to > muck around with daemons _in maintainer scripts_? The --exec option for start-stop-daemon. This option is very useful: it gives start-stop-daemon the ability to verify that it is killing the right process, and not another one with the same name or with the same (recycled) pid. This is definitely the preferred way of using start-stop-daemon. The only problem with the --exec option is that it does not work if you use it in the postinst after an upgrade to restart the daemon since the binary has been replaced and will now have a different inode. This gives you two options: 1. don't use --exec at all, not even in the init script. 2. don't use --exec in the postinst, or use it with a saved (hardlinked) copy of the original file Option 1 means we loose the advantage of being sure we are killing the right process. Option 2 is obviously better in that it does not have that problem at all of you use a saved copy, or only during upgrades if you only don't use --exec in the maintainer script. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: serious bug. Evolution and Microsoft mentality.
I'm now a happy evolution user, to converyt my mail i did cat Mail/lists/* | cat /var/spool/mail/rob Then just check your mail and using the filters setup in evolution to filter it in the boxes again. Maybe not the best way, but i didnt lose any mail. -- Rob 'robster' Bradford Chief Editor/Lead developer DebianPlanet.org
Re: problem with debconf and start-stop-daemon
Michael Banck <[EMAIL PROTECTED]> writes: > On Fri, Jan 11, 2002 at 04:49:19PM +, Mark Brown wrote: > > > You can't, in general, close *all* open file descriptors. OPEN_MAX > > > may not exist (and I would guess that it doesn't on the HURD). > > > > If OPEN_MAX is undefined you could always use INT_MAX :-) . > > I bet INT_MAX does not exist on Hurd, either... I bet it does. The ANSI C standard requires that INT_MAX be defined. POSIX only requires that OPEN_MAX be defined if it has a fixed, uniform limit. -- "While the Melissa license is a bit unclear, Melissa aggressively encourages free distribution of its source code." --Kevin Dalley <[EMAIL PROTECTED]>
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 04:49:19PM +, Mark Brown wrote: > > You can't, in general, close *all* open file descriptors. OPEN_MAX > > may not exist (and I would guess that it doesn't on the HURD). > > If OPEN_MAX is undefined you could always use INT_MAX :-) . I bet INT_MAX does not exist on Hurd, either... Michael -- -:- aj [EMAIL PROTECTED] has joined #debian-devel oh, crap, 13 RC bugs against base?
Re: [kde] and, for my next trick ...
There appears to be a list named debian-kde. PLEASE use that. -devel is already clogged enough, and should be reserved for extremely general or miscellaneous discussion.
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 04:49:19PM +, Mark Brown wrote: > On Fri, Jan 11, 2002 at 10:34:18AM -0600, Steve Greenland wrote: > > > You can't, in general, close *all* open file descriptors. OPEN_MAX > > may not exist (and I would guess that it doesn't on the HURD). It's > > completely reasonable for a daemon to that doesn't open any extras to > > assume that only stdin, stdout, and stderr are open. > > If OPEN_MAX is undefined you could always use INT_MAX :-) . iirc, there has been a problem with a program closing all descriptors before, because they were used by libc (?) for something. So no, you shouldn't use INT_MAX either :) -- Adam Olsen, aka Rhamphoryncus
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 10:34:18AM -0600, Steve Greenland wrote: > You can't, in general, close *all* open file descriptors. OPEN_MAX > may not exist (and I would guess that it doesn't on the HURD). It's > completely reasonable for a daemon to that doesn't open any extras to > assume that only stdin, stdout, and stderr are open. If OPEN_MAX is undefined you could always use INT_MAX :-) . -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgp2B5Sy7URvY.pgp Description: PGP signature
postfix & reiserfs ??
Hey I have a strange problem in here and I don't know exactly what's wrong... Regularry my /var/spool/postfix directory gets corrupted, then I get errors like the following in my console: --- find: /var/spool/postfix/deferred/1/0/10416306DA: No such file or directory find: /var/spool/postfix/deferred/1/0/10416306DA: No such file or directory find: /var/spool/postfix/deferred/1/0/10416306DA: No such file or directory find: /var/spool/postfix/deferred/1/0/10416306DA: No such file or directory find: /var/spool/postfix/deferred/D/1/D1A6D2E376: No such file or directory find: /var/spool/postfix/deferred/D/1/D1A6D2E376: No such file or directory find: /var/spool/postfix/deferred/D/1/D1A6D2E376: No such file or directory find: /var/spool/postfix/deferred/D/1/D1A6D2E376: No such file or directory find: /var/spool/postfix/deferred/1/0/10416306DA: No such file or directory find: /var/spool/postfix/deferred/1/0/10416306DA: No such file or directory find: /var/spool/postfix/deferred/1/0/10416306DA: No such file or directory find: /var/spool/postfix/deferred/1/0/10416306DA: No such file or directory find: /var/spool/postfix/deferred/D/1/D1A6D2E376: No such file or directory find: /var/spool/postfix/deferred/D/1/D1A6D2E376: No such file or directory find: /var/spool/postfix/deferred/D/1/D1A6D2E376: No such file or directory find: /var/spool/postfix/deferred/D/1/D1A6D2E376: No such file or directory --- Now, it also caused once my find process to eat all my 128 meg RAM. When I try to delete the directory /var/spool/postfix/deferred, I get an error saying: LiSa:/var/spool/postfix# rm -rf deferred rm: cannot remove directory `deferred/1/0': Directory not empty rm: cannot remove directory `deferred/1': Directory not empty rm: cannot remove directory `deferred/D/1': Directory not empty rm: cannot remove directory `deferred/D': Directory not empty rm: cannot remove directory `deferred': Directory not empty I tried a lot to delete these, but nothing helps ... My /var is a ReiserFs partition and I tried to fsck it etc, but this directory still doesn't want to be deleted. Now, the only solution that helps is renaming the directory and creating a new one called deferred. The only problem with this is they still excist and that I have some 4 or 5 of them now. Does someone know howto solve or is this (as I think) a package error? (something with endless symbolic links or something) tnx michael --- Michael De Nil -- [EMAIL PROTECTED] Linux LiSa 2.4.17 #6 SMP Sun Jan 6 11:55:25 CET 2002 i686 17:38:02 up 6:27, 1 user, load average: 0.19, 0.15, 0.08 ---
Re: problem with debconf and start-stop-daemon
On 11-Jan-02, 08:45 (CST), "Stefan Hornburg (Racke)" <[EMAIL PROTECTED]> wrote: > Yeah, but it is really a bug that should be filed. The daemon will > be killed by SAK otherwise (look at #92277 for further enlightenment). You can't, in general, close *all* open file descriptors. OPEN_MAX may not exist (and I would guess that it doesn't on the HURD). It's completely reasonable for a daemon to that doesn't open any extras to assume that only stdin, stdout, and stderr are open. Steve
Re: problem with debconf and start-stop-daemon
On Fri, 11 Jan 2002, Wichert Akkerman wrote: > Previously Henrique de Moraes Holschuh wrote: > > On Fri, 11 Jan 2002, Michael Meskes wrote: > > > In quota.postinst rpc.quotad is started using start-stop-daemon. This > > > works > > > > Don't, please. This will be forbidden in the future (right now this is ok), > > you should use the /etc/init.d interface. > > Why? That is silly, there are perfectly good reasons to use a different > method for starting/stopping a daemon in the maintainer scripts then > init scripts use. Read the invoke-rc.d stuff, and policy-rc.d stuff in the BTS (debian-policy). I don't know the bug numbers offhand. It has been approved, the code is in woody and it works (try running invoke-rc.d sometime), and we are just waiting woody to go out of the door to start deploying the stuff. Basically, the idea is to finish once and for all with the mess of daemons starting and restarting (and stopping) when the admin does not them to, due to maintainer scripts playing around. The current default behaviour will NOT change unless you go out of your way to configure the system otherwise, btw. But people that, for example, don't want any daemons running before they are configured and reviewed will be able to do that. Please tell me one good reason not to use the init.d script interface to muck around with daemons _in maintainer scripts_? I mean, a good one that justfies bowling over any changes the local administrator might have done to the initscripts? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: problem with debconf and start-stop-daemon
Previously Henrique de Moraes Holschuh wrote: > On Fri, 11 Jan 2002, Michael Meskes wrote: > > In quota.postinst rpc.quotad is started using start-stop-daemon. This works > > Don't, please. This will be forbidden in the future (right now this is ok), > you should use the /etc/init.d interface. Why? That is silly, there are perfectly good reasons to use a different method for starting/stopping a daemon in the maintainer scripts then init scripts use. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: kernel-image-2.2.20-udma100-ext3, initrd and ext3
reopen 126889 severity 126889 wishlist tags 126889 + patch quit #include Marek Andricik wrote on Fri Jan 11, 2002 um 11:05:09AM: > I have had some HW problems with my computer which resulted in many > hangups and long fsck each boot, so I decided to switch to ext3. There > were no problem except that root fs was still mounted as ext2. Kernel Do you know for sure? Did you trust "mount" output or /proc/mounts content? > is kernel-image-2.4.17-586tsc version 2.4.17-1 from the distribution. > The loadmodules script in the initrd does not load ext3. When I added > modprobe -k ext3 my problem was solved. I'd like to ask you if it is > the right way how to solve the problem. You can add ext3 to /etc/mkinitrd/modules, or change fstype to "ext3" in /etc/fstab. Then run "dpkg-reconfigure kernel-image-2.4.17-586tsc". All this will be easier if you use "auto" as fs type and WHEN Herbert Xu finally applies MY PATCH submitted a while ago. Gruss/Regards, Eduard. -- I think my Linux is more reliable than my harddrive. The question is what will crash first.
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 09:45:22AM -0500, Stefan Hornburg (Racke) wrote: > Mark Brown <[EMAIL PROTECTED]> writes: > > Or has called the standard daemon() function which doesn't close all the > > file descriptors. > Yeah, but it is really a bug that should be filed. The daemon will > be killed by SAK otherwise (look at #92277 for further enlightenment). It does close the standard file descriptors. It just doesn't close anything else (like stuff from debconf, for example). -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: problem with debconf and start-stop-daemon
Mark Brown <[EMAIL PROTECTED]> writes: > On Fri, Jan 11, 2002 at 11:40:28AM -0200, Henrique de Moraes Holschuh wrote: > > > Ah, it looks like you need to have a db_stop BEFORE you call > > start-stop-daemon or the initscript. Looks like the daemon is dumb and does > > No, the ordering is unimportant. db_stop stops debconf no matter when > you call it. > > > not close all open descriptors, creates a new session id, etc... > > Or has called the standard daemon() function which doesn't close all the > file descriptors. Yeah, but it is really a bug that should be filed. The daemon will be killed by SAK otherwise (look at #92277 for further enlightenment). Ciao Racke -- For projects and other business stuff please refer to COBOLT NetServices (URL: http://www.cobolt.net; Email: [EMAIL PROTECTED]; Phone: 0041-1-3884400)
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 11:40:28AM -0200, Henrique de Moraes Holschuh wrote: > Don't, please. This will be forbidden in the future (right now this is ok), > you should use the /etc/init.d interface. If you need extra functionality, Sorry, I wasn't precies enough. It does call /etc/init.d/quotarpc which then calls start-stop-daemon. > start-stop-daemon or the initscript. Looks like the daemon is dumb and does > not close all open descriptors, creates a new session id, etc... Yup. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 11:40:28AM -0200, Henrique de Moraes Holschuh wrote: > Ah, it looks like you need to have a db_stop BEFORE you call > start-stop-daemon or the initscript. Looks like the daemon is dumb and does No, the ordering is unimportant. db_stop stops debconf no matter when you call it. > not close all open descriptors, creates a new session id, etc... Or has called the standard daemon() function which doesn't close all the file descriptors. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgpX0u114EEbs.pgp Description: PGP signature
Re: problem with debconf and start-stop-daemon
On Fri, 11 Jan 2002, Michael Meskes wrote: > In quota.postinst rpc.quotad is started using start-stop-daemon. This works Don't, please. This will be forbidden in the future (right now this is ok), you should use the /etc/init.d interface. If you need extra functionality, you should request the maintainer of the package with the /etc/init.d script to add it, and use that. > as longs as I know the package. Now it doesn't anymore. That is the daemon > is correctly started but quota.postinst does not return anymore. It remains > defunc until I kill rpc.rquotad. As soon as I comment out the line > . /usr/share/debconf/confmodule > all works well again. Ah, it looks like you need to have a db_stop BEFORE you call start-stop-daemon or the initscript. Looks like the daemon is dumb and does not close all open descriptors, creates a new session id, etc... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Installed wajig 0.2.11-1 (i386 source)
At 11:17 am, Friday, January 11 2002, Adam Heath mumbled:
> That's a bug in python2.{1,2} then. What's the point of having a platform
> neutral 'compiled' version of a script if the format changes every time the
> wind changes direction?
>
FUD. Pure FUD.
--
Steve
We are Debian of Borg. Resistance is futile! You will be packaged!!
pgpmjFffAg3eq.pgp
Description: PGP signature
Re: IBM "Key alliances" ?
* Eric Van Buggenhaut | Helas, AFAIK, when IBM sells Linux, it sells RH. Nope. My T21 came with Caldera OpenLinux on it. Bought about a year ago. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 01:04:25PM +0100, Petter Reinholdtsen wrote: > [Mark Brown] > > You need to explicitly end Debconf processing in the postinst by > > calling db_stop. debconf causes child processes to have an extra > > file descriptor open and waits for these to be closed before exiting > > and the daemon doesn't know it has this file open so doesn't close > > it. > > Is this the case for all postinst scripts? db_stop is not mentioned > in my /usr/share/doc/debconf-doc/tutorial.html, which I use as my > debconf reference. See the "Troubleshooting" section. The debconf documentation often doesn't use the db_ prefix when discussing commands, since that's only used by the shell confmodule and not the Perl confmodule. -- Colin Watson [EMAIL PROTECTED]
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 01:04:25PM +0100, Petter Reinholdtsen wrote: > Is this the case for all postinst scripts? db_stop is not mentioned > in my /usr/share/doc/debconf-doc/tutorial.html, which I use as my > debconf reference. No. If your postinst does not leave processes running then there won't be any problem. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgpchpcTtjxc7.pgp Description: PGP signature
Re: squirrelmail: apache/php and register_globals
On Fri, 11 Jan 2002, martin f krafft wrote: > lucky it. it's a vanilla install with register_globals being the *only* > thing i changed (to off) in php.ini. Hmm... > php.ini | dconf | .htaccess || master | local > Off| On | On || Off| Off // NOT OK > Off| On | || Off| Off // NOT OK > Off| | On || Off| Off // NOT OK > Off| Off| Off || Off| Off // ok > Off| Off| || Off| Off // ok > Off| | Off || Off| Off // ok > Off| | || Off| Off // ok > On | On | On || On | Off // NOT OK > On | On | || On | Off // NOT OK > On | | On || On | Off // NOT OK > On | Off| Off || On | Off // ok > On | Off| || On | Off // ok > On | | Off || On | Off // ok > On | | || On | On // ok > > and yes, i am very certain to not have left stray .htaccess files. Yes, there appears to be a serious bug in this thing all-right. I just went to the system I have working, and tried to find out what is happening there (where it works). php.ini register_globals is on (urk). This is not enough to get squirrelmail to work (bug in php4.1). I also have dconf setting it to On on all squirrelmail directories, and THAT managed to get it to "on". No .htaccess files. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
ifupdown front-end
Hello, I was working on a ifupdown front-end. I finished the first alpha release and now I need beta-testers. This version only support ethernet interfaces. Available at: deb ftp://esware365.net/pub/updates ./ Greetings! Sergio Rua <[EMAIL PROTECTED]> -- Key fingerprint = 4B4B 1ED6 8F17 0E2B 0DA3 5978 BFB6 6565 1768 44B7
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 11:58:47AM +, Mark Brown wrote: > You need to explicitly end Debconf processing in the postinst by calling That's it. Thanks a lot. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! pgpfJMEeIzDdh.pgp Description: PGP signature
Re: problem with debconf and start-stop-daemon
[Mark Brown] > You need to explicitly end Debconf processing in the postinst by > calling db_stop. debconf causes child processes to have an extra > file descriptor open and waits for these to be closed before exiting > and the daemon doesn't know it has this file open so doesn't close > it. Is this the case for all postinst scripts? db_stop is not mentioned in my /usr/share/doc/debconf-doc/tutorial.html, which I use as my debconf reference.
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 12:44:39PM +0100, Michael Meskes wrote: > In quota.postinst rpc.quotad is started using start-stop-daemon. This works > as longs as I know the package. Now it doesn't anymore. That is the daemon > is correctly started but quota.postinst does not return anymore. It remains > defunc until I kill rpc.rquotad. As soon as I comment out the line > . /usr/share/debconf/confmodule > all works well again. You need to explicitly end Debconf processing in the postinst by calling db_stop. debconf causes child processes to have an extra file descriptor open and waits for these to be closed before exiting and the daemon doesn't know it has this file open so doesn't close it. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgpTd7ITXX72V.pgp Description: PGP signature
problem with debconf and start-stop-daemon
I'm currently working on adding debconf to quota. Well in fact Torsten Lnadschoff did that and send me the patch. However, during my tests I found a strange problem. In quota.postinst rpc.quotad is started using start-stop-daemon. This works as longs as I know the package. Now it doesn't anymore. That is the daemon is correctly started but quota.postinst does not return anymore. It remains defunc until I kill rpc.rquotad. As soon as I comment out the line . /usr/share/debconf/confmodule all works well again. Since I do not know much about debconf I'm not seeing the reason but I suppose it should be pretty simple or else other packages wouldn't work either. Any idea? Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: Musixtex not going into testing?
On Fri, 11 Jan 2002, Atsuhito Kohda wrote: > I have just uploaded for powerpc. Thanks. Hamish wrote me he did it for hppa and I just did for sparc. Kind regards Andreas.
kernel-image-2.2.20-udma100-ext3, initrd and ext3
I have had some HW problems with my computer which resulted in many hangups and long fsck each boot, so I decided to switch to ext3. There were no problem except that root fs was still mounted as ext2. Kernel is kernel-image-2.4.17-586tsc version 2.4.17-1 from the distribution. The loadmodules script in the initrd does not load ext3. When I added modprobe -k ext3 my problem was solved. I'd like to ask you if it is the right way how to solve the problem. -- Marek, http://m-a.sk
Re: Do not link GNOME1 apps with libpng3
On Thu, Jan 10, 2002 at 09:16:30PM -0500, Steve M. Robbins wrote: > On Wed, Jan 09, 2002 at 01:07:26PM -0200, Gustavo Noronha Silva wrote: > > On 09 Jan 2002 15:09:08 +0100 > > Christian Marillat <[EMAIL PROTECTED]> wrote: > > > > > > Now, the question is: should GNOME move to libpng3, and how? The QT/KDE > > > > folks have sidestepped the problem by declaring that libqt2 is > > > > remaining linked against libpng2, while libqt3 links with libpng3. I > > > > don't see why we shouldn't adopt the same approach: leave imlib1 > > > > linked with libpng2 and let imlib's successor libraries link against > > > > libpng3. Comments? > > > > > > I disagree completely. We should *always* compile all packages against > > > the latest library version and not downgrade the builg dependency to an > > > old library. We have did the same change to move to libdb3. > > > > > > I really want to know why recompiling gdk-imlib1 is too hard ? > > > > I can see your point, but the change from db2 to db3 happened months > > ago, and I really think libpng3 should be investigated before > > we move all gnome apps to use it... we must take care, because the > > freeze is going and this can delay it more and more or remove > > some gnome programs from woody > > I tend to agree with you, Gustavo. > > It also bears keeping in mind: > > * imlib1 is deprecated and won't be used in GNOME 2 > * Redhat is going to keep GNOME 1 linked with libpng2 > * Debian KDE is keeping libqt2 linked with libpng2 > (and moving to libpng2 only with libqt3) > > Moreover, nobody has produced a compelling reason to make the > switch other than "libpng3 is newer than libpng2". In the > absence of such, leaving imlib1 linked with libpng2 seems to > me to be the wisest course of action, *especially* during a freeze. > Moreover I guess libqt2 (which is essentially frozen) is tested with libpng2, not libpng3. It's not a good policy generally to change libraries without a good reason and extensive testing. In all mails I overviewed in these days I cannot find any issue about this. What's the real reason for changing library? "It's newer" is not a good reason :) We could discover new problems in linking qt2 with png3 we had not before. Anyway, it's done. Maybe something about these bad practices is already present in the Policy Manual. If not something should be obviuosly proposed. -- Francesco P. Lovergine
Re: We still need sponsors!
On Fri, 11 Jan 2002, Eric Van Buggenhaut wrote: > Since the person who upload the package is not the maintainer, it is actually > a > non-maintainer upload, isn't it ? No, the maintainer of the package is the person who gets sponsored (he's the maintainer of this package although he isn't yet an official developer). It's a bit similar e.g. to the case that you are somewhere at a conference and don't have your GPG key available but you want to fix a bug in one of your packages. You can then prepare your package and another developer who has his laptop with his GPG key available signs your package. cu Adrian
Re: libgd-perl: can't build on ia64
> Package: libgd-perl > Version: 1.38-0.2 I'm sorry. Another time I choose the wrong entry from my addressbook. -- Piotr Roszatycki, Netia Telekom S.A..''`. mailto:[EMAIL PROTECTED] : :' : mailto:[EMAIL PROTECTED] `. `' `-
Re: We still need sponsors!
On Wed, Jan 09, 2002 at 11:18:05AM +0100, Tille, Andreas wrote: > On Wed, 9 Jan 2002, Raphael Hertzog wrote: > > > So, dear co-developers, please join debian-mentors@lists.debian.org and > > respond to future maintainers, and sponsor those who are asking it. > > Also check out the sponsor page that is listing about 30 future > > maintainers who are looking for a sponsor : > > http://www.internatif.org/bortzmeyer/debian/sponsor/ > Thanks for your effort Raphael! [...] > OK. If I understand this right that would mean that the control file > would state > > Maintainer: Future Maintainer <[EMAIL PROTECTED]> > > and my own address will be in the changelog (like in an NMU). Since the person who upload the package is not the maintainer, it is actually a non-maintainer upload, isn't it ? -- Eric VAN BUGGENHAUT "Hay tampones y tampones..." (Eva Serrano) Andago \_|_/ Av. Santa Engracia, 54 \/ \/ E-28010 Madrid - tfno:+34(91)2041100 a n d a g o |--http://www.andago.com /\___/\ "Innovando en Internet" / | \ [EMAIL PROTECTED]
