Re: Bug#137560: apt: build-deps not resolved
On Sun, 2003-08-03 at 08:47, Matt Zimmerman wrote: retitle 137560 [apt-get] build-dep cannot resolve conflicts between build dependencies (e.g., boot-floppies) thanks The problem seems to be that if the default choice of each OR expression in boot-floppies' build-depends is chosen, the result is incompatible. Specifically, it build-depends on: slang1-pic | slang1-utf8-pic, libnewt-dev | libnewt-utf8-dev However: mizar:[...otmine/boot-floppies-3.0.23] sudo apt-get install slang1-pic libnewt-dev Reading Package Lists... Done Building Dependency Tree... Done libnewt-dev is already the newest version. Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: slang1-pic: Depends: slang1-dev (= 1.4.5-2.1) but it is not going to be installed E: Broken packages zsh: exit 100 sudo apt-get install slang1-pic libnewt-dev A separate issue is that you are building boot-floppies in a sid environment (presuming this is deliberate, for the moment; if you are building for 3.0r2, then do so in woody); libnewt and slang have changed in woody. In sid, libnewt-utf8-dev no longer exists: there is both versions have been merged into libnewt-dev, so remove libnewt-utf8-dev refereences. This has not been done for slang1 as it would break binary interfaces of existing programs; nevertheless I would strongly recommend not using non-UTF8 slang1. So use: slang1-utf8-pic, libnewt-pic libnewt-dev Depends on slang1-utf8-dev, which conflicts with slang1-dev (depended upon by slang1-pic). A simple workaround would be to change the dependency to be: slang1-utf8-pic | slang1-pic, libnewt-dev | libnewt-utf8-dev (reverse the order of the first OR) build-dep presumably could be made smart enough to detect this situation and backtrack to find a better solution, but currently it selects the first package that it finds to satisfy each dependency. -- - mdz -Alastair -- Alastair McKinstry [EMAIL PROTECTED] GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#186331: raising severity; was: busybox FTBTS problems
On Sat, Aug 02, 2003 at 04:19:31PM +0100, Alastair McKinstry wrote: I'll take a look at the adjtimex problem. However, static binaries are always going to be second-class citizens as far as glibc is concerned and you should avoid them whenever possible. Ok, how about doing that? not building a static version of busybox on alpha until this bug is resolved? (and applying the known-to-work patch for ia64/alpha). It would get d-i building again. reassign to libc6 as they are problems of this package. ia64 may be fixable by a binary nmu. bastian -- Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 pgp0.pgp Description: PGP signature
Re: Bug#186331: raising severity; was: busybox FTBTS problems
On Sun, 2003-08-03 at 10:38, Bastian Blank wrote: On Sat, Aug 02, 2003 at 04:19:31PM +0100, Alastair McKinstry wrote: I'll take a look at the adjtimex problem. However, static binaries are always going to be second-class citizens as far as glibc is concerned and you should avoid them whenever possible. Ok, how about doing that? not building a static version of busybox on alpha until this bug is resolved? (and applying the known-to-work patch for ia64/alpha). It would get d-i building again. reassign to libc6 as they are problems of this package. ia64 may be fixable by a binary nmu. bastian The adjtimex bug has been assigned to libc6 already, with a note that its now severity serious as it breaks d-i. I'm proposing to do binary NMUs for alpha, ia64 busybox-cvs : hence I'm CC'ing all the uploaders for busybox CVS (its maintainer is set to debian-boot). Any objections? Regards, Alastair -- Alastair McKinstry [EMAIL PROTECTED] GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#186331: raising severity; was: busybox FTBTS problems
On Sun, Aug 03, 2003 at 10:44:23AM +0100, Alastair McKinstry wrote: The adjtimex bug has been assigned to libc6 already, with a note that its now severity serious as it breaks d-i. I'm proposing to do binary NMUs for alpha, ia64 busybox-cvs : hence I'm CC'ing all the uploaders for busybox CVS (its maintainer is set to debian-boot). Any objections? i prepare a new upload which may break modutils on any arch != i386 because noone want to recently test them. it fixes any syscall problems. before upload i want to fix the support for biarch in modutils. bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, Who Mourns for Adonais? stardate 3468.1 pgp0.pgp Description: PGP signature
Re: d-i and iBooks
Sven Luther schrieb: On Fri, Aug 01, 2003 at 08:06:56PM +0200, Thorsten Sauter wrote: I guess thats the best solution to put all needed images in one udeb. The makefile can copy all images into different directories on the cdrom-image. We will need some additional logic in the makefile. You have to list all the possible kernel image names in build/config/arch/linux-powerpc and adjust the makefile logic in build/make/arch/linux-powerpc Ok, i will see if i can do that, altough the real problem is to build more than just the vmlinux and vmlinux.coff images. I guess we could get the images directly out of the arch/ppc/boot/images : Sven, have a look at how Herbert Xu creates kernel udebs with kernel-image-2.4.20-1-i386-udeb. He has an additional source package for the udebs, which depens on the kernel-image. IMHO this is the best way to package kernel udebs. You don't need an extra kernel build for the udebs if you do it that way (even if kernel udebs change but the kernel stays the same). I'm not sure, but I think it could be better if these kernel udeb source packages would be maintained by debian-boot and not the individual kernel maintainers. Like that we would have better control over the udebs and don't have to bother the kernel maintainers every time the content of some udeb changes. We could also provide more unified udebs across all architectures. But I don't want to stand on the feets of the kernel maintainers. If they prefer to do this job, do it. gaudenz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
grub-installer spanish templates updated
Hi,
I've updated the spanish translation of grub-installer.
Bye, Carlos.
--
Carlos Valdivia Yagüe [EMAIL PROTECTED]
#
#Translators, if you are not familiar with the PO format, gettext
#documentation is worth reading, especially sections dedicated to
#this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
#Some information specific to po-debconf are available at
#/usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
#
#Developers do not need to manually edit POT or PO files.
#
# Carlos Valdivia Yagüe [EMAIL PROTECTED], 2003
#
msgid
msgstr
Project-Id-Version: grub-installer 0.0.13\n
POT-Creation-Date: 2003-07-30 00:18+0200\n
PO-Revision-Date: 2003-08-03 16:35+0200\n
Last-Translator: Carlos Valdivia Yagüe [EMAIL PROTECTED]\n
Language-Team: Debian L10n Spanish [EMAIL PROTECTED]\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=ISO-8859-15\n
Content-Transfer-Encoding: 8bit\n
#. Description
#: ../templates:4
msgid On which device should GRUB be installed?
msgstr ¿En qué dispositivo debería instalarse GRUB?
#. Description
#: ../templates:4
msgid
GRUB needs to install the stage 1 boot loader on a bootable device. This is
usually the first hard drive. Note that GRUB counts devices differently than
the Linux kernel, so the first one is usually '(hd0)'. Leave this at default
if unsure.
msgstr
GRUB necesita instalar la primera etapa del cargador de arranque en un
dispositivo arrancable. Normalmente, se trata del primer disco duro. Tenga
en cuenta que GRUB cuenta los dispositivos de modo diferente al núcleo
Linux, por lo que el primero es habitualmente '(hd0)'. Si no está seguro,
deje la opción predeterminada.
#. Description
#: ../templates:13
msgid Unable to install grub in /target/. Continue anyway?
msgstr
No fue posible instalar grub en /target/. ¿Desea continuar de todas formas?
#. Description
#: ../templates:13
msgid
The grub package failed to install into /target/. It is required to install
GRUB as a boot loader. The install problem might be unrelated to grub, and
it might work to continue anyway.
msgstr
No se pudo instalar el paquete grub en /target/. Es necesario para instalar
GRUB como cargador de arranque. El problema puede no estar relacionado con
grub y es posible que funcione de todas formas.
#. Description
#: ../templates:20
msgid Unable to install grub in ${BOOTDEV}
msgstr No se pudo instalar grub en ${BOOTDEV}
#. Description
#: ../templates:20
msgid Executing 'grub-install ${BOOTDEV}' failed.
msgstr La ejecución de «grub-install ${BOOTDEV}» falló.
#. Description
#: ../templates:27
msgid Unable to configure grub
msgstr No se pudo configurar grub
#. Description
#: ../templates:27
msgid Executing 'update-grub' failed.
msgstr La ejecución de «update-grub» falló.
#. Description
#: ../templates:27
msgid This is a fatal error.
msgstr Error fatal.
#. Description
#: ../templates:34
msgid Installing GRUB boot loader
msgstr Instalando el cargador de arranque GRUB
#. Description
#: ../templates:38
msgid Install the 'grub' package.
msgstr Instalar el paquete «grub».
#. Description
#: ../templates:42
msgid Determining GRUB boot device.
msgstr Determinando el dispositivo de arranque de GRUB.
#. Description
#: ../templates:46
msgid Running \grub-install ${BOOTDEV}\.
msgstr Ejecutando «grub-install ${BOOTDEV}».
#. Description
#: ../templates:50
msgid Running \update-grub\.
msgstr Ejecutando «update-grub».
#. Description
#: ../templates:54
msgid Updating /etc/kernel-img.conf.
msgstr Actualizando /etc/kernel-img.conf.
(powerpc) kernel udebs (was Re: d-i and iBooks)
Sven Luther schrieb: On Sun, Aug 03, 2003 at 04:13:02PM +0200, Gaudenz Steinlin wrote: We will need some additional logic in the makefile. You have to list all the possible kernel image names in build/config/arch/linux-powerpc and adjust the makefile logic in build/make/arch/linux-powerpc That would be the d-i makefiles ? yes. Ok, i will see if i can do that, altough the real problem is to build more than just the vmlinux and vmlinux.coff images. I guess we could get the images directly out of the arch/ppc/boot/images : Sven, have a look at how Herbert Xu creates kernel udebs with kernel-image-2.4.20-1-i386-udeb. He has an additional source package for the udebs, which depens on the kernel-image. IMHO this is the best way to package kernel udebs. You don't need an extra kernel build for the udebs if you do it that way (even if kernel udebs change but the kernel stays the same). Ok, i will have a look. The real problem for ppc though is that there are various subarches, which build different kind of images including the subarch specific bootloaders. I don't think this problem exists on i386. I suppose the udeb-source package gets the kernel-image package, and extracts the needed kernel image or something from it to build the udeb ? yes, it build-depends on kernel-image-?? I'm not sure about the subarchs, but I think to best way for the moment is what Thorsten suggested, to put them together into one udeb and handling all the subarches in the d-i makefile. One other possibility that comes into my mind, is to have one udeb for every subarch. But subarches need special handling in the makefile anyway, so this is probably overkill. I'm not sure, but I think it could be better if these kernel udeb source packages would be maintained by debian-boot and not the individual kernel maintainers. Mmm, i would have to look at the source udeb in question before i can give my opinion on this. Like that we would have better control over the udebs and don't have to bother the kernel maintainers every time the content of some udeb changes. We could also provide more unified udebs across all architectures. But I don't want to stand on the feets of the kernel maintainers. If they prefer to do this job, do it. The problem is that the kernel maintainer for a given arch may have a better knowledge of what modules build or fail to build on said arch or other such problems, does he not ? Not really speaking about me, since i don't own powermac hardware, and have the impression that most powermac people use the benh kernels instead anyway. Yes, kernel maintainers probably know better. So in any case there needs to be tight cooperation between debain-boot and the maintainers. gaudenz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i and iBooks
On Sun, Aug 03, 2003 at 04:13:02PM +0200, Gaudenz Steinlin wrote: Sven Luther schrieb: On Fri, Aug 01, 2003 at 08:06:56PM +0200, Thorsten Sauter wrote: I guess thats the best solution to put all needed images in one udeb. The makefile can copy all images into different directories on the cdrom-image. We will need some additional logic in the makefile. You have to list all the possible kernel image names in build/config/arch/linux-powerpc and adjust the makefile logic in build/make/arch/linux-powerpc That would be the d-i makefiles ? Ok, i will see if i can do that, altough the real problem is to build more than just the vmlinux and vmlinux.coff images. I guess we could get the images directly out of the arch/ppc/boot/images : Sven, have a look at how Herbert Xu creates kernel udebs with kernel-image-2.4.20-1-i386-udeb. He has an additional source package for the udebs, which depens on the kernel-image. IMHO this is the best way to package kernel udebs. You don't need an extra kernel build for the udebs if you do it that way (even if kernel udebs change but the kernel stays the same). Ok, i will have a look. The real problem for ppc though is that there are various subarches, which build different kind of images including the subarch specific bootloaders. I don't think this problem exists on i386. I suppose the udeb-source package gets the kernel-image package, and extracts the needed kernel image or something from it to build the udeb ? I'm not sure, but I think it could be better if these kernel udeb source packages would be maintained by debian-boot and not the individual kernel maintainers. Mmm, i would have to look at the source udeb in question before i can give my opinion on this. Like that we would have better control over the udebs and don't have to bother the kernel maintainers every time the content of some udeb changes. We could also provide more unified udebs across all architectures. But I don't want to stand on the feets of the kernel maintainers. If they prefer to do this job, do it. The problem is that the kernel maintainer for a given arch may have a better knowledge of what modules build or fail to build on said arch or other such problems, does he not ? Not really speaking about me, since i don't own powermac hardware, and have the impression that most powermac people use the benh kernels instead anyway. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: grub-installer spanish templates updated
On Sun, Aug 03, 2003 at 04:32:49PM +0200, Carlos Valdivia Yag?e wrote: I've updated the spanish translation of grub-installer. Thanks, I've committed it to CVS. -- Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (powerpc) kernel udebs (was Re: d-i and iBooks)
On Sun, Aug 03, 2003 at 04:37:59PM +0200, Gaudenz Steinlin wrote: Sven Luther schrieb: On Sun, Aug 03, 2003 at 04:13:02PM +0200, Gaudenz Steinlin wrote: We will need some additional logic in the makefile. You have to list all the possible kernel image names in build/config/arch/linux-powerpc and adjust the makefile logic in build/make/arch/linux-powerpc That would be the d-i makefiles ? yes. Ok, i will see if i can do that, altough the real problem is to build more than just the vmlinux and vmlinux.coff images. I guess we could get the images directly out of the arch/ppc/boot/images : Sven, have a look at how Herbert Xu creates kernel udebs with kernel-image-2.4.20-1-i386-udeb. He has an additional source package for the udebs, which depens on the kernel-image. IMHO this is the best way to package kernel udebs. You don't need an extra kernel build for the udebs if you do it that way (even if kernel udebs change but the kernel stays the same). Ok, i will have a look. The real problem for ppc though is that there are various subarches, which build different kind of images including the subarch specific bootloaders. I don't think this problem exists on i386. I suppose the udeb-source package gets the kernel-image package, and extracts the needed kernel image or something from it to build the udeb ? yes, it build-depends on kernel-image-?? I'm not sure about the subarchs, but I think to best way for the moment is what Thorsten suggested, to put them together into one udeb and handling all the subarches in the d-i makefile. One other possibility that comes into my mind, is to have one udeb for every subarch. But subarches need special handling in the makefile anyway, so this is probably overkill. Yes, but as i see it, kernel-package needs to be patched to allow for the kernel-images to have different subarches in it. I need to override the kernel-package rule file in order to build a pmac kernel image on my pegasos/chrp related box. Not sure though, maybe it already allows this, i will have to check it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#203852: llseek bug
tag 203852 + patch
This patch fixes the compile problem of fdisk.c
diff -ur -x '*.o' -x '*.a' busybox-cvs-0.60.99.cvs20030426/util-linux/fdisk.c
my-busybox-cvs-0.60.99.cvs20030426/util-linux/fdisk.c
--- busybox-cvs-0.60.99.cvs20030426/util-linux/fdisk.c 2003-08-03 16:20:21.0
+0200
+++ my-busybox-cvs-0.60.99.cvs20030426/util-linux/fdisk.c 2003-07-26
04:19:24.0
+0200 @@ -859,7 +859,11 @@
static int _llseek( unsigned int fd, unsigned long offset_high,
unsigned long offset_low, loff_t *result, unsigned int whence)
{
+#ifndef __alpha__
return(syscall(__NR__llseek, fd, offset_high, offset_low,
result, whence));
+#else
+ return(syscall(__NR_lseek, fd, offset_high, offset_low, result,
whence));
+#endif
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#137560: apt: build-deps not resolved
On Sun, Aug 03, 2003 at 09:55:00AM +0100, Alastair McKinstry wrote: On Sun, 2003-08-03 at 08:47, Matt Zimmerman wrote: The following packages have unmet dependencies: slang1-pic: Depends: slang1-dev (= 1.4.5-2.1) but it is not going to be installed E: Broken packages zsh: exit 100 sudo apt-get install slang1-pic libnewt-dev A separate issue is that you are building boot-floppies in a sid environment (presuming this is deliberate, for the moment; if you are building for 3.0r2, then do so in woody) I was only trying to reproduce the bug, not trying to actually build boot-floppies. Thanks, though. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aboot
On Sun, Aug 03, 2003 at 11:14:40PM +0200, Peter 'p2' De Schrijver wrote:
Hi,
Attached you will find a patch for aboot which fixes the following
problems :
Oops. I forgot 1 file in the patch. Note that I will be away from my
alpha hw coming 2 weeks.
Cheers,
peter
diff -wur -x *.o -x *.a -N /dev/null my-aboot-0.9/net_aboot.lds.in
--- /dev/null 2003-03-08 19:13:42.0 +0100
+++ my-aboot-0.9/net_aboot.lds.in 2003-07-30 23:02:48.0 +0200
@@ -0,0 +1,17 @@
+OUTPUT_FORMAT(binary)
+TARGET(binary)
+INPUT(NET_ABOOT)
+INPUT(VMLINUXGZ)
+INPUT(INITRD)
+INPUT(CMDLINE)
+SECTIONS {
+ output : {
+NET_ABOOT
+LONG(endkernel - beginkernel);
+LONG(endinitrd - endkernel);
+CMDLINE
+BYTE(0)
+beginkernel = . ; VMLINUXGZ ; endkernel = . ;
+INITRD ; endinitrd = . ;
+ }
+}
debian-installer kernel policy
hi folks i try to write a kernel policy for debian-installer. it may make the communication between the d-i team and the kernel maintainers. http://debian.ipv4.waldi.eu.org/debian-installer/kernel-policy/ bastian -- Is truth not truth for all? -- Natira, For the World is Hollow and I have Touched the Sky, stardate 5476.4. pgp0.pgp Description: PGP signature
Re: Bug#186331: raising severity; was: busybox FTBTS problems
On Sun, Aug 03, 2003 at 10:44:23AM +0100, Alastair McKinstry wrote: The adjtimex bug has been assigned to libc6 already, with a note that its now severity serious as it breaks d-i. I'm proposing to do binary NMUs for alpha, ia64 busybox-cvs : hence I'm CC'ing all the uploaders for busybox CVS (its maintainer is set to debian-boot). Any objections? getting ia64 building needs more than just a rebuild against the newer libc6.1-dev - it needs source changes too. see #201161. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Boot problem
Hi! This: http://lists.debian.org/debian-boot/2003/debian-boot-200302/msg00253.html appears to be an architecture problem. I have reached the installation screen without a problem using a computer with 8MB RAM, but it failed as per the message with another computer (Thinkpad AT clone) with 8MB RAM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
