Hi folks.
Sorry, no patches, sources, or udebs, at least for now. (Yes, this is
a teaser; booh, bad bad bad KiBi.)
I just wanted to keep you posted about my latest hacks. Please note
the following numbers are based on my IRC backlog between successive
builds, so they might not be the exact figur
Accepted:
acpi-modules-2.6.32-trunk-486-di_1.85_i386.udeb
to
main/l/linux-kernel-di-i386-2.6/acpi-modules-2.6.32-trunk-486-di_1.85_i386.udeb
acpi-modules-2.6.32-trunk-686-bigmem-di_1.85_i386.udeb
to
main/l/linux-kernel-di-i386-2.6/acpi-modules-2.6.32-trunk-686-bigmem-di_1.85_i386.udeb
ata-
Accepted:
acpi-modules-2.6.32-3-amd64-di_1.63_amd64.udeb
to
main/l/linux-kernel-di-amd64-2.6/acpi-modules-2.6.32-3-amd64-di_1.63_amd64.udeb
ata-modules-2.6.32-3-amd64-di_1.63_amd64.udeb
to
main/l/linux-kernel-di-amd64-2.6/ata-modules-2.6.32-3-amd64-di_1.63_amd64.udeb
cdrom-core-modules-2.6
Accepted:
acpi-modules-2.6.32-trunk-amd64-di_1.62_amd64.udeb
to
main/l/linux-kernel-di-amd64-2.6/acpi-modules-2.6.32-trunk-amd64-di_1.62_amd64.udeb
ata-modules-2.6.32-trunk-amd64-di_1.62_amd64.udeb
to
main/l/linux-kernel-di-amd64-2.6/ata-modules-2.6.32-trunk-amd64-di_1.62_amd64.udeb
cdrom-
Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
linux-kernel-di-ia64-2.6_1.18etch5.dsc
linux-kernel-di-ia64-2.6_1.18etch5.tar.gz
This looks like an upload, but a .changes file is missing, so the job
cannot be processed.
If no .changes file arrives w
Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
linux-kernel-di-arm-2.6_1.10etch5.dsc
linux-kernel-di-arm-2.6_1.10etch5.tar.gz
This looks like an upload, but a .changes file is missing, so the job
cannot be processed.
If no .changes file arrives wit
linux-kernel-di-powerpc-2.6_1.29etch5_powerpc.changes uploaded successfully to
localhost
along with the files:
linux-kernel-di-powerpc-2.6_1.29etch5.dsc
linux-kernel-di-powerpc-2.6_1.29etch5.tar.gz
kernel-image-2.6.18-6-powerpc-di_1.29etch5_powerpc.udeb
nic-modules-2.6.18-6-powerpc-di_1.29
linux-kernel-di-s390-2.6_0.13etch5_s390.changes uploaded successfully to
localhost
along with the files:
linux-kernel-di-s390-2.6_0.13etch5.dsc
linux-kernel-di-s390-2.6_0.13etch5.tar.gz
kernel-image-2.6.18-6-s390-di_0.13etch5_s390.udeb
nic-modules-2.6.18-6-s390-di_0.13etch5_s390.udeb
scs
linux-kernel-di-mipsel-2.6_0.13etch5_mipsel.changes uploaded successfully to
localhost
along with the files:
linux-kernel-di-mipsel-2.6_0.13etch5.dsc
linux-kernel-di-mipsel-2.6_0.13etch5.tar.gz
kernel-image-2.6.18-6-r3k-kn02-di_0.13etch5_mipsel.udeb
ipv6-modules-2.6.18-6-r3k-kn02-di_0.13et
linux-kernel-di-sparc-2.6_1.20etch5_sparc.changes uploaded successfully to
localhost
along with the files:
linux-kernel-di-sparc-2.6_1.20etch5.dsc
linux-kernel-di-sparc-2.6_1.20etch5.tar.gz
kernel-image-2.6.18-6-sparc64-di_1.20etch5_sparc.udeb
nic-modules-2.6.18-6-sparc64-di_1.20etch5_spar
linux-kernel-di-i386-2.6_1.44etch5_i386.changes uploaded successfully to
localhost
along with the files:
linux-kernel-di-i386-2.6_1.44etch5.dsc
linux-kernel-di-i386-2.6_1.44etch5.tar.gz
kernel-image-2.6.18-6-486-di_1.44etch5_i386.udeb
nic-modules-2.6.18-6-486-di_1.44etch5_i386.udeb
nic-e
linux-kernel-di-hppa-2.6_1.17etch5_hppa.changes uploaded successfully to
localhost
along with the files:
linux-kernel-di-hppa-2.6_1.17etch5.dsc
linux-kernel-di-hppa-2.6_1.17etch5.tar.gz
kernel-image-2.6.18-6-parisc-di_1.17etch5_hppa.udeb
nic-modules-2.6.18-6-parisc-di_1.17etch5_hppa.udeb
linux-kernel-di-amd64-2.6_1.21etch5_amd64.changes uploaded successfully to
localhost
along with the files:
linux-kernel-di-amd64-2.6_1.21etch5.dsc
linux-kernel-di-amd64-2.6_1.21etch5.tar.gz
kernel-image-2.6.18-6-amd64-di_1.21etch5_amd64.udeb
nic-modules-2.6.18-6-amd64-di_1.21etch5_amd64.ud
linux-kernel-di-alpha-2.6_0.17etch5_alpha.changes uploaded successfully to
localhost
along with the files:
linux-kernel-di-alpha-2.6_0.17etch5.dsc
linux-kernel-di-alpha-2.6_0.17etch5.tar.gz
kernel-image-2.6.18-6-alpha-generic-di_0.17etch5_alpha.udeb
nic-modules-2.6.18-6-alpha-generic-di_0.
On Thursday 25 February 2010, dann frazier wrote:
> fyi, I'm planning to upload a new set of linux-kernel-di packages for
> the upcoming etch point release, mainly to fix a regression on s390
> (#562525).
Ack. Let me/us know when there are images that could use testing.
--
To UNSUBSCRIBE, email
fyi, I'm planning to upload a new set of linux-kernel-di packages for
the upcoming etch point release, mainly to fix a regression on s390
(#562525).
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Arch
(new) acpi-modules-2.6.32-3-amd64-di_1.63_amd64.udeb extra debian-installer
ACPI support modules
This package contains kernel modules for ACPI.
(new) ata-modules-2.6.32-3-amd64-di_1.63_amd64.udeb extra debian-installer
ATA disk modules
This package contains core ATA disk modules used by both PATA
I'm back from 4 days away without mail access. I just catched up with
the list without really reading it. In case something important
needing my attention happened since Saturday evening, please mail me
privately.
--
signature.asc
Description: Digital signature
linux-kernel-di-amd64-2.6_1.63_amd64.changes uploaded successfully to localhost
along with the files:
linux-kernel-di-amd64-2.6_1.63.dsc
linux-kernel-di-amd64-2.6_1.63.tar.gz
kernel-image-2.6.32-3-amd64-di_1.63_amd64.udeb
nic-modules-2.6.32-3-amd64-di_1.63_amd64.udeb
nic-extra-modules-2.6
On Wednesday 24 February 2010, Raúl Benencia wrote:
> Althought I've tried a lot of times, you made me doubt what I had done
> and I had tried one more time half an hour ago with a clean and fresh
> installer. These were my steps:
>
> svn co svn://svn.debian.org/d-i/tags/installer/20090123lenny6 d-
Marco d'Itri wrote:
> devices.tar.gz should contain only the devices which are strictly
> needed, even if udev is not installed the others can be created by
> makedev.
>
> At least the ram* devices should be removed because they were needed
> by initrds and are not useful anymore.
Then they shoul
On Wednesday 24 February 2010, Mario 'BitKoenig' Holbe wrote:
> On Wed, Feb 24, 2010 at 06:02:44PM +0100, Frans Pop wrote:
> > I've done a quick test using tftpd-hpa with the '-r tsize' option,
> > which should make it not accept that option.
> > D-I still boots fine when I use the lenny or squeeze
On Wed, Feb 24, 2010 at 06:02:44PM +0100, Frans Pop wrote:
> I've done a quick test using tftpd-hpa with the '-r tsize' option, which
> should make it not accept that option.
> D-I still boots fine when I use the lenny or squeeze images.
Could you please try tftpd (plain, from netkit-tftp)?
I was
El 24/02/10 13:00, Frans Pop escribió:
> On Wednesday 24 February 2010, Raúl Benencia wrote:
>
>> After playing around for a while, I found out that modprobe is trying to
>> load the kernel modules from a relative path. This, obviously, is a bug.
>> d-i hackers may have not noticed that because
On Wednesday 24 February 2010, Frans Pop wrote:
> So that does seem to confirm that tsize is not the problem here. It also
> seems more likely that it's not syslinux that's broken, but either the
> PXE client in Mario's system(s), or his TFTP server (I'd bet on the
> latter).
OTOH, tftpd-hpa is of
On Wednesday 24 February 2010, Ferenc Wagner wrote:
> But if you look in the NEWS file of Syslinux, which is packaged as
> /usr/share/doc/syslinux/changelog.gz (why?) you'll find:
> * PXELINUX: We no longer require a TFTP server which supports
> the tsize option for all transfers.
Thanks f
Since release 150, udev requires that support for the CONFIG_SYSFS_DEPRECATED
feature is disabled in the running kernel.
Please upgrade your kernel before or while upgrading udev.
AT YOUR OWN RISK, you can force the installation of this version of udev
WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL
On Wednesday 24 February 2010, Raúl Benencia wrote:
> After playing around for a while, I found out that modprobe is trying to
> load the kernel modules from a relative path. This, obviously, is a bug.
> d-i hackers may have not noticed that because they're tremendously busy
> with the squeeze rele
During the last month, I've been having problems with the creation of
debian-installer images for a lenny-based distro. I've tried with
different svn tags and even with the trunk version, but the results were
the same.
The error appears after selecting the graphical install and enabling the
framebu
On Wed, Feb 24, 2010 at 02:03:44PM +0100, Frans Pop wrote:
> On Wednesday 24 February 2010, أحمد المحمودي wrote:
> > So, after reading #570581, is this actually a fribidi or a newt bug ?
>
> It can probably be argued that it's both :-)
>
> In newt for not initializing and in fribidi for not termi
Hello,
On Wed, Feb 24, 2010 at 11:28:32AM +, Colin Watson wrote:
> It's possible (and arguably sane, on the basis of defence in depth at
> least) to work around this in newt. See:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570581
---end quoted text---
I tried Ubuntu's patch righ
On Wednesday 24 February 2010, أحمد المحمودي wrote:
> So, after reading #570581, is this actually a fribidi or a newt bug ?
It can probably be argued that it's both :-)
In newt for not initializing and in fribidi for not terminating.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.
Processing commands for cont...@bugs.debian.org:
> tags 544513 + patch
Bug #544513 [netcfg] dhcp returned hostname take precedence on
netcfg/get_hostname
Added tag(s) patch.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(ad
On Tue, Feb 23, 2010 at 02:30:11PM +0100, Frans Pop wrote:
> On Tuesday 23 February 2010, Frans Pop wrote:
> > Hmmm. If I compare the MANIFEST.udebs from testing and my build the only
> > thing that jumps out is:
> > - libfribidi0-udeb 0.10.9-1+b1 amd64
> > + libfribidi0-udeb 0.19.2-1 a
Package: tasksel
Version: 2.81
Severity: normal
Hi,
AFAICT of the four desktop environments that Debian offers to install from
installations CDs, LXDE is currenly the only one that does not ship with
network management software. In GNOME, network-manager-gnome is pulled in via
recommends of th
On Feb 24, Ferenc Wagner wrote:
> > FYI, the only devices needed by udev to start are null and console.
> Aren't those created by devtmpfs? Or will Debian not use that?
If devtmpfs is mounted, yes. Currently it is not.
And I believe it's a good idea to have these on the underlying
filesystem any
Package: tasksel
Version: 2.81
Severity: normal
Hi,
the desktop task still installs swfdec-mozilla, which has been thrown out of
the meta-gnome2 (1:2.28+2) package "since it’s incompatible with webkit
currently :(". In current SVN a dependency on mozilla-plugin-gnash has been
added instead.
C
Marco d'Itri writes:
> FYI, the only devices needed by udev to start are null and console.
Aren't those created by devtmpfs? Or will Debian not use that?
--
Thanks,
Feri.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list
Frans Pop writes:
> Why image size is important
> [...]
> 2) makes loading the image for netboot installs slower
While I'm in Syslinux mood: version 3.85 has a full-featured gPXELinux
component, boasting HTTP support (among others). Image loading over
HTTP is *much* faster than over TFTP. On t
"Mario 'BitKoenig' Holbe" writes:
> On Thu, Feb 18, 2010 at 01:18:01AM +0100, Frans Pop wrote:
>> Problem is: it works perfectly here for me using the daily image you linked
>> to on two systems: in VirtualBox and my (oldish) Toshiba laptop.
>
> All right, I think I got it... syslinux/pxelinux.t
40 matches
Mail list logo