This problem affect clanlib as well. I'm trying to prepare an NMU to
get it to use the new C++ ABI, and ran into this compile error:
Compiling Sources/Display/Input/X11/joystick_linux.cpp
In file included from Sources/Display/Input/X11/joystick_linux.h:45,
from
[Steve Halasz]
I believe debian/libgdal1.files needs to be renamed to
libgdal12c.files.
Also may need to be renamed on dh_makeshlibs and dh_shlibdeps lines
in debian/rules.
You are right. My NMU to fix the C++ transition was incomplete. I'm
working on a new version now.
--
Petter
Thank you for your interest in earth3d. :)
[Ingo Saitz]
1. It is linked against libXmu.so.6, so why does it try to open it again?
I have no idea. I believed dh_shlibdeps in debian/rules would do the
right thing.
2. Loading libXmu.so will fail if it points to another ABI version of
the
Package: libtextwrap-dev
Version: 0.1-2
Severity: serious
Setting severity to serious as I believe policy states clearly that a
package must conflict with other packages containing the same file as
the package itself.
When trying to upgrade my sid chroot, I ran into this problem:
Unpacking
libodbcinstq1 than unixodbc-bin.
The gdal problem affects mapserver, thuban and qgis, and probably
other packages, all of which need to move to the new C++ ABI.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
[Kurt Roeckx]
Your package is failing to build on 64 bit arches with the following
error:
Heh, I guess it always was broken, but no-one used it on 64-bit archs. :)
It's trying to print the address. In C, with printf, you'd use a %p
for it. I have no idea if std::cout has something simular.
This bug keep this package from propagating into testing. Because of
the 'wontfix' tag, I am unsure if this is intentional or not. What is
the plan? Perhaps the severity of the bug should be reduced, the
wontfix flag should be removed and the bug fixed, or what?
--
To UNSUBSCRIBE, email to
tags 346669 + patch
thanks
I'm preparing an NMU to fix this problem. Here is the patch and
proposed changelog entry.
* Change build depend from 'xlibs-dev ( 4.1.0)' to 'libx11-dev,
libxext-dev, x-dev', as xlibx-dev is being removed from Debian.
(Closes: #346669)
diff -ur
[Jörg Sommer]
What would you suggest?
I suggest reducing the severity to 'wishlist' while keeping the
wontfix flag, and perhaps retitle the bug if that make it more obvious
what the bug is all about. requires j2re1.4 indicate a serious bug,
while bootchart do not really require j2re1.4 and thus
severity 349271 normal
merge 349271 331438
thanks
Thank you for your bug report. Sad to hear that the problem is still
affecting users. The fixed package should make it into etch in 6
days.
[Ron Johnson]
On 14-Jan, cron.weekly started sending me emails with this in them:
CONTENTS
If the package never build before on the given platform, I do not
believe it is an RC bug that it fail to build. Because of this, I
suggest redusing the severity to important.
'serious' should be used if it is breaking etch rc policy, and
according to
tags 292347 + patch
thanks
This patch should fix the problem. The gpsd developers didn't know
about the problem before I told them this morning, and just released
v2.8 with this problem fixed.
Index: gpsd.c
===
--- gpsd.c
===
--- debian/changelog(revisjon 4869)
+++ debian/changelog(arbeidskopi)
@@ -3,6 +3,7 @@
[Petter Reinholdtsen]
* Rename default monitor and card name to use 'Xdebconfigurator'
instead of just 'Xdevc', to make it clearer what
The problem seem to trigger in this code in netplan.c function main().
'==' marks line 269.
fd_set rd, wr, ex; /* returned fd masks from select */
[...]
nclients = sizeof(fd_set)*8; /* max # of clients */
== client_list = allocate(nclients
[Petter Reinholdtsen]
Can you try to apply this diff, to get the size of the memory
alloctaion printed, and run the program again:
Doh. No need. I see from the backtrace, that the number is very
large (268517376).
Hm, could this be a signed/unsigned issue? Try to apply this patch
and see
Hi. Do you have time to look at the netplan memory error bug
(#334351) on URL:http://bugs.debian.org/src:plan? I suspect some
code error regarding nclients, as it seem to be used both as the
number of file descriptors in use (with select()), and as a buffer
size. Any clues to spare?
--
To
Package: gpsdrive
Version: 2.09-2
Severity: grave
Tags: security patch
A hole in the gpsd binary friendsd2 has been announced today.
Severity grave, as it is a remotely exploitable hole. This is the
content of
URL:http://article.gmane.org/gmane.comp.security.full-disclosure/37400:
Date: Fri,
[William McKee]
However, the session is still active which means anyone else may
walk up to the system and use the History or the Back button of the
browser to access all account information for the previously logged
in user.
What do you mean? Can one continue to work in sql-ledger after
Package: popularity-contest
Version: 1.30
Severity: serious
The HTTP POST upload being done by popcon-upload do not seem to follow
the CGI file upload specification. This make it hard to use common
CGI parsers on the server end, and also make it confusing to analyze
the HTTP trafic. In
Package: conquest-gl
Version: 8.1-2
Severity: grave
Justification: renders package unusable
When I try to start conquestgl on my sarge installation, I only get an
assertion error. This render the package completely useless. As I
suspect this will be the case for all users of the package, I set
tags 327718 + patch
thanks
I found this patch from ubuntu to fix this issue. I'm preparing an
NMU to use it. This is the changelog entry from Ubuntu:
* Added patch to prevent installation of /usr/share/locale/locale.alias.
#! /bin/sh /usr/share/dpatch/dpatch-run
##
[Frans Pop]
Severity: serious
Why the serious severity? lilo is not the default boot loader, so
this only affect expert installs.
In commit r29833 the value of link_in_boot was changed from false to
true for i386 and amd64. This change make lilo-installer fail as
lilo.conf is configured to
Package: avifile
Version: 1:0.7.43.20050224-1
Severity: grave
The avifile library need to be renamed and rebuild according to the
C++ transition. More info on the C++ transition is available from
URL:http://lists.debian.org/debian-devel-announce/2005/07/msg1.html
and
Package: lvm-common
Severity: serious
Version: 1.5.20
Justification: circular dependency
When trying to build a LTSP chroot, the lvm-common package fail to
install. I use this command in a sid chroot to build the ltsp
environment (chroot):
# ltsp-build-client --dist sid --mirror
found 330809 1.3.25-23
reopen 330809
thanks
[Bastian Blank]
This is the same bug than #306990.
Yes, look like the same bug. And it is still present when using
devfsd version 1.3.25-23 and lvm-common version 1.5.20.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
severity 321563 serious
merge 321563 287244
thanks
After applying the patch included in bug #321563, I just tried to
build kudzu in debian/sid, as part of my plan to NMU the package.
The build failed with an error messages from the assembler:
make[1]: Entering directory
severity 306990 grave
found 306990 1.3.25-23
thanks
I see this problem with the current unstable/sid packages. To
reproduce it, install ltsp-server and run this command:
ltsp-build-client --dist sid --mirror http://ftp.skolelinux.no/debian
After a while, this error occures:
[...]
[Dan Griswold]
With the new upgrade, the netplan daemon ate up all the memory on the
system and caused the xserver and its associated tty to fail. This
required a reboot.
Hm. I'm not aware of any changes which could give this result. What
was the version number you used before this problem
[Dan Griswold]
That's what I thought when I looked in the changelog. I upgrade very
frequently, so my replaced version must be the immediately previous
one, 1.9-2.
Can you try to verify this by installing the old binary package and
see if it get rid of the problem?
[Dan Griswold]
Can you try with ltrace?
Yields nothing obviously of value.
Well, please send the last 50 lines anyway, to let me know what is
going on when it fails. And send the last 50 strace lines as well,
though I do not expect them to tell me much.
So, I guess I need to gpg --import
[Dan Griswold]
Will do!
Hm, the problem seem to happen in the forked off child, and not in the
parent process. Try running the same using netplan -f, to avoid the
fork.
To test in gdb, do this:
gdb src/netplan
break exit
run -f
bt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
I contacted the maintainer 2005-09-25 about this issue, and got a
reply the same day telling me that he had been waiting for the KDE and
Qt libraries to get sorted out, and would do an upload with a new
release in 1-2 weeks.
Today I was asked what happened with my NMU, and realised that I
forgot
Package: debootstrap
Version: 0.3.1.7
Severity: grave
A new version of apt just made it into etch. This make it impossible
to use debootstrap to generate an etch chroot, as the
libsigc++-1.2-5c102 package is no longer in etch, but it is expected
by debootstrap.
When running debootstrap, this
tags 334506 + patch
thanks
This patch solves this issue for etch. I suggest this changelog
entry:
* [etch] Replace libsigc++-1.2-5c102 with libsigc++-1.2-5c2 in
$base. (Closes: #334506)
diff -ur debootstrap-0.3.1.7/etch debootstrap-0.3.1.8/etch
--- debootstrap-0.3.1.7/etchThu Sep 15
severity 339007 important
thanks
I get this error because php_mapscript.so is into /usr/lib/php4/20020429:
Warning: dl(): Unable to load dynamic library
'/usr/lib/php4/20050606/php_mapscript.so' -
/usr/lib/php4/20050606/php_mapscript.so: cannot open shared object file
I have corrected
[Brendan O'Dea]
Debian Policy states (§9.3.1):
Also, if the script name ends `.sh', the script will be sourced
in runlevel `S' rather that being run in a forked subprocess, but
will be explicitly run by `sh' in all other runlevels.
What a strange thing for policy to specify. :)
[Brendan O'Dea]
I'm not quite sure what the initial rationale was, although Adam Heath
suggested on IRC that it could be to allow scripts to set environment
variables which would propagate through to subsequent scripts.
I'm not sure why it is documented in policy, but the sysv-rc
[Steve Langasek]
It's perfectly sensible: if the scripts were meant to be run in
parallel, they shouldn't have the .sh extension...
Eh, are you claiming that policy mention sourcing of .sh scripts to
make sure those scripts are not run in paralell? It does not sounds
reasonable to me, as the
[Petter Reinholdtsen]
The patch look good, but will be equivalent to a forked subprocess
when running the scripts in parallel.
Here is a possible patch to avoid running .sh scripts in the
background when using CONCURRENCY=shell.
Index: debian/sysv-rc/etc/init.d/rc
tags 339000 + patch
thanks
Here is a patch to fix this issue.
-- bin/nicec.orig 2005-11-20 10:00:56.004671430 +0100
+++ bin/nicec 2005-11-20 10:00:40.563175008 +0100
@@ -89,6 +89,6 @@
# Certain JVMs seem to exit by throwing SIGHUP, thus replacing the exit code
# with 129.
# This
This build problem affect several architectures, not just sparc.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: libc6
Version: 2.3.5-5
Severity: serious
The script /etc/init.d/glibc.sh can not be sourced, as it contain
'exit 0' at the end of the script. This is against policy, specifying
that all .sh scripts in /etc/rcS.d/ will be sourced. I discovered
this while fixing sysv-rc (bug #339955),
I'm not sure how this could happen, but when I enabled sourcing of the
.sh scripts in rcS.d/, the boot failed because /etc/rcS.d/S01glibc.sh
uses 'exit 0' at the end of the script, and thus terminates the S
runlevel. This script was added in glibc version 2.3.5-5 uploaded
2005-08-27. The
[Thomas Hood]
pere: Please just close this if you disagree.
I'm not sure if I agree or not. :)
The version in testing have bugs too, which are fixed by version
2.86.ds1-6. Which bugs in 2.86.ds1-6 are not present in testing, and
are serious enough to keep 2.86.ds1-6 from entering testing?
[Noèl Köthe]
the copyright:
...
You acknowledge that this software is not designed or intended for use
in the design, construction, operation or maintenance of any nuclear
facility.
This makes the package non-free.
Eh, no it doesn't. The license do not forbid the use of this software
[Steve Langasek]
So yes, if insserv assumes that all Debian initscripts are LSB init
scripts, it is fundamentally broken.
insserv do not assume this. It uses init.d script dependecy
information as provided by the scripts themselves and from files
included in insserv, to reorganize the boot
[Martin-Éric Racine]
Therefore, it seems that your affirmation about someone not having
read the documentation is purely gratuitous at best and downright
insulting at worst.
I must have misread the initial report, as I read that you had checked
the boot order before you ran insserv, and not
03-Jun-2004 [EMAIL PROTECTED]
+# Version: @(#)umountfs 2.85-17 03-Sep-2005 [EMAIL PROTECTED]
+# Modified by Petter Reinholdtsen [EMAIL PROTECTED]
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin
+umask 022
echo -n Deactivating swap...
umount -ttmpfs -a -r
swapoff -a
echo done
Could this problem be related to the problems reported when running
liquidwar in valgrind? I saw several issues when running the binary
from the package, and the program refused to start. I decided to
rebuild with debug info and do a new test. This is the result:
reading past allocated memory
when switcing from rcS.d to the real runlevel.
* Make it easier to override /etc/defaults/rcS parameters. (Closes: #286081)
* Updated Standards-Version to 3.6.2.1 (no changes needed).
-- Petter Reinholdtsen [EMAIL PROTECTED] Sun, 4 Sep 2005 15:00:14 +0200
As you can see, there are quite a few
tags 325978 + patch
thanks
The GCC bug in question seem to be #323686. When it is fixed, the
special handling of arm could be removed.
This patch switches the arm build to use gcc 3.4. Perhaps it will
work. I got no way to test it, as I lack an arm machine.
diff -ur
Package: qgis
Version: 0.6.0-2
Severity: grave
Because of the ongoing C++ transition, qgis is uninstallable in
unstable. It need a rebuild with the new C++ ABI to fix it. When I
try to install it, I get this message:
The following packages have unmet dependencies:
qgis: Depends:
[Steve Halasz]
Please don't. I've been watching this all carefully.
OK. Sounds good.
I think I need to wait until gdal is built on all architectures, but
I'll upload soon.
You do not need to wait for this, I believe, if you set your versioned
build-dependency to reflect this need. The
and the cookie is required to have the
LDAP admin password, and nothing dangerous is stored in the cookie nor
on the server.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
compile:
[javac] Compiling 6 source files to
/tmp/buildd/commons-daemon-1.0.1/target/classes
BUILD FAILED
/tmp/buildd/commons-daemon-1.0.1/build.xml:144: Compile failed; see
the compiler error output for details.
I see no error message from the compiler. When I tested this
in CVS.
I'm ignoring the possibility of having /etc/php4/$SAPI/php.ini
inserted after the config script but before the postinst, as I am not
quite sure how to solve that, and I hope the template naming issue is
enough to solve this problem.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email
to have it working, but am not able to spend the
time required to fix it myself. I hope someone will come up with
working patches soon, to avoid this package being removed from the
archive (ref
URL:http://lists.debian.org/debian-qa/2006/04/msg00067.html).
Friendly,
--
Petter Reinholdtsen
[Matthias Klose]
is debconf configured for non-interactive installation mode? If yes,
it's pretty clear, as the license is not yet accepted.
Nope. I had already answered the license question when the script
failed.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
/testing until the new versions of jamvm and cacao are
available, to make sure the versions in Debian/testing keep working.
Setting severity to serious for the same reason, to make sure
classpath do not enter testing before the conflicts are added.
Friendly,
--
Petter Reinholdtsen
tags 348778 + patch
thanks
I got this answer on the ext2resize-devel mailing list:
[Andreas Dilger]
That's because ext2prepare was never updated to support the new
ext3 resize inode format. There was actually a patch posted on
ext2-devel which may fix this from Takashi Sato, but I haven't
[Daniel Kobras]
Please investigate.
This seem to be the problem:
gcc -I/include -fPIC -O2 -ansi -pedantic
-DGMT_DEFAULT_PATH=\/usr/lib/gmt\ blockmean.o -L. -lgmt -lpsl
-L/lib -lnetcdf -lm -s -Wl,-rpath,/usr/lib/gmt/lib -o blockmean
/usr/bin/ld: blockmean: hidden symbol
need a complete
rewrite to work with the new libsysfs. :(
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Petter Reinholdtsen]
Anyway, I believe the code in hwinfo-8.38/src/hd/edd.c need a complete
rewrite to work with the new libsysfs. :(
I looked in the old library, and found the structs and functions
needed by hwinfo there. When I inserted the struct in hd_int.h, the
code built but failed
tags 285257 + patch
thanks
The following patch was found in the fedora version of ext2resize, and
claim to fix all endian issues with the package. When it is inserted
instead of the 01_fix-endianess patch in debian version 1.1.19-3 of
ext2resize, it should solve this bug. Can anyone test and
I was able to reproduce this, by creating a LVM volume with ext3 and
running ext2prepare on it. The same problem occur when I use ext2.
Commands to recreate:
lvcreate -L150 -ntest_lv intern_vg
mke2fs -j /dev/intern_vg/test_lv
ext2prepare /dev/intern_vg/test_lv 500m
e2fsck -y -f
tags 285257 - patch
thanks
[Petter Reinholdtsen]
Can anyone test and verify that it solves the problem?
I got Sven Luther to test on a powerpc machine, without much success.
He was using test filesystem and used resize2fs to reduce it and then
tried to use ext2resize to reduce and extend
that the package maintainer worry about it.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Jonas Smedegaard]
It is a violation of Debian Policy to mess with conffiles of other
packages, and http://release.debian.org/sarge_rc_policy.txt section
3 adds this:
Debian policy section 10.7.4 (Sharing configuration files) reads:
The maintainer scripts must not alter a conffile of any
Is the strace for the crashing and the non-crashing run of f-spot
different? Perhaps you can use strace or ltrace to pinpoint where it
fails?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Petter Reinholdtsen]
An option might be to mount a private tmpfs (aka mounting it, chdir
into it and umounting it, thus making it available only to the process
running within it), but this will not make the life of mtab.sh easier.
Here is a draft patch for the private tmpfs approach
/ until
we do come up with a working solution.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
have to work around the fact that
/etc/mtab is written to.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
readers experience this same problem, I've been able to
solve it by downgrading to 2.86.ds1-1 (as found in sarge).
Good. How did you downgrade when the system was unbootable? Did you
have to use a rescue CD?
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
[Arjan Oosting]
I found the problem in update-rc.d. There is a little logic error in one
of the functions update-rc.d. After i fixed that it worked again:
Ah, then it was introduced in version 2.86.ds1-16. Thank you for the
patch. I've included it in svn instead of my proposed patch.
--
To
tags 386500 + pending patch confirmed
thanks
I am able to reproduce the problem. And I must say, wow, that was a
scary bug. And if I should believe the svn changelog for the script,
it has been there forever, forever here meaning since before the svn
repository was created 2005-09-10. :)
I
,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
it? As it stands, this bug report
is unsolvable as there is nothing in it to work on.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
the /var/log/dpkg.log file. It include
the list of installs, upgrades and removals. You should be able to
use it to figure out what packages that need a reinstall. I have not
yet a script fragment to do this.
Sorry for the mess.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email
[Shobhit Jindal]
just back from a scare of udev
i too confirm the above missing links ... after linking
update-rc.d -f udev start 03 S .
update-rc.d -f udev-mtab start 36 S .
everything seems to be working fine
Thank you for letting me know. Again, sorry for the mess.
Friendly,
--
Petter
severity 386661 important
merge 386649 386661
thanks
[Olaf van der Spek]
Isn't it possible to just run the postinst scripts of these packages again?
Probably, but I did not want to bypass dpkg. Perhaps it is a good
idea in this case, to avoid having to pull in new versions of the
packages.
with a
different fix for your problem.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Frederik Schueler] wrote:
the new initscripts package mounts ramfs filesystems into my chroots:
tmpfs /org/chroots/sid/lib/init/rw tmpfs rw,nosuid 0 0
Yes. This is fixed in -28. It will not mount it in chroots any more.
additionally, it breaks on upgrade in my vservers:
Can you explain
On Sat, Sep 30, 2006 at 10:20:56AM +0200, Loïc Minier wrote:
[Loïc Minier]
Now that I think again about it, I suppose what happened is that
some services with init scripts were upgraded, then initscripts, but
since the old initscript was used in the first part of the upgrade,
the tmpfs was
,
and it points to
URL:http://packages.qa.debian.org/g/gtk2-engines.html where
gtk2-engines-clearlooks no longer is listed as a binary package.
Anyone know more?
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
/messages
#
Are you still seeing the problem? If so, I suggest checking for HTTP
proxies between your machine and popcon.debian.org.
Redusing severity to normal, as this do not affect all users.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
this solution? [Y/n/q/?] q
Abandoning all efforts to resolve these dependencies.
Abort.
#
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Peter Eisentraut]
I will upload an NMU based on the attached patch in a few days if
the bug is not addressed by then.
Good to hear, as this bug make it impossible for the ntp package to
propage into etch, and radioclk is impossible to install in unstable:
# aptitude install radioclk
Reading
:
libsensors3: Depends: libsysfs2 which is a virtual package
Resolving dependencies...
Unable to resolve dependencies! Giving up...
Abort
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
and libsysfs2-udeb are put on the CD, and hope that will
solve the problem.
I guess this bug could be reassigned to debian-cd, but I leave it
closed for now.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
into the main d-i atm also, which _might_
be more unlikely to fix until the release anyway.
What do you mean? Our udeb integrates very nicely into the main d-i
framework. There are some minor bugs left, but in general, it is
doing quite well.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email
enable the debian-edu udeb if some kernel option is
passed into d-i, and get the d-i team to include it on the DVD. Of
course we might not be able make sure all our packages are on the
official DVD. :)
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
This problem keep the KDE-based APT frontend adept out of etch. Are
anyone working on fixing this problem?
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I am unable to find any newer version in /usr/share/misc/. We use
config.guess dated 2006-07-02 and config.sub dated 2006-09-20. What
version do we have to use to get the source built on hppa?
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
of course upload a new version with the
quites replaced, but I doubt it will change anything related to the
original problem.
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Frans Pop]
I suspect that this is particular to debian-edu because you have some
other package that changes configuration info, which causes the strange
configuration (quoting Petter) that update-inetd wants to ask about.
You could try if delaying those configuration steps to later helps
tags 334351 + patch pending
thanks
I believe the attached patch solve the issue, but dropping the use of
NGROUPS_MAX, and instead count the number of groups before allocating
the memory needed from the heap.
Please test it and let me know if it solve your problem. Unless you
tell me it failed
[Kurt Roeckx]
Your package still has a build dependency on xlibs-dev. This has
been removed as announced on:
http://lists.debian.org/debian-devel-announce/2005/11/msg00022.html
Will update it.
This means your package is now failing to build.
Eh, where and how is it failing to build? All
[Kurt Roeckx]
But all those packages have to be fixed sooner or later. I hope
people will go and fix this themself. But I'll file bugs after they
uploaded it and it failed.
Yes, a fix need to be inserted. But I have a hard time figuring out
how to fix it in a way that make the package still
...
pid=`pidof portmap`
if [ -n $pid ] ; then
log_begin_msg Already running.
log_end_msg 0
exit 0
fi
Thus the 'start' option isn't using the pid file. This should be
fixed.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email
1 - 100 of 969 matches
Mail list logo
