Re: how to control/override dev assigment 3ware and USB
Frans Pop wrote: On Friday 22 September 2006 23:58, RParr wrote: Any guidance would be most appreciated; especially any way to capture the early boot messages; /etc/default/bootlogd enabling does not seem to help. Which kernel is being booted? If it is 2.6.16 the cause may be that your hardware needs 2.6.17. The daily images of the installer have already been using 2.6.17 for a while which could explain why you did not see any problems there. The 2.6.17 kernel is now available in testing though. To upgrade the kernel use the rescue mode of the installer, mount your root filesystem on target (the installer will ask you that) get into a chroot shell on /target and upgrade the kernel. You may have to mount proc inside the chroot. I tried again with the newest snapshot (2006.09.22) and I added labels to the partitions. With those two changes I was able to get it to install AND boot after the install. Previously, the installer was partitioning drive /dev/sde BUT I noticed it was formatting /dev/sda. I think it was a bit confused. It appears to be better now. I also upgraded the system to sid and everything still running ok. Thanks for the suggestions. R -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388549: Please pull avahi-daemon with a GNOME desktop installation (for Rhythmbox)
Sjoerd Simons wrote: > If avahi is install by default though, libnss-mdns should probably be in too. Good point.. > Although that package needs some work (ensuring automatic setup of nsswitch..) I thought this was fixed since #348580 is closed, but it seems it's not. Color me puzzled. -- see shy jo signature.asc Description: Digital signature
Re: how to control/override dev assigment 3ware and USB
Frans Pop wrote: On Friday 22 September 2006 23:58, RParr wrote: Any guidance would be most appreciated; especially any way to capture the early boot messages; /etc/default/bootlogd enabling does not seem to help. Which kernel is being booted? If it is 2.6.16 the cause may be that your hardware needs 2.6.17. The daily images of the installer have already been using 2.6.17 for a while which could explain why you did not see any problems there. The 2.6.17 kernel is now available in testing though. To upgrade the kernel use the rescue mode of the installer, mount your root filesystem on target (the installer will ask you that) get into a chroot shell on /target and upgrade the kernel. You may have to mount proc inside the chroot. Been there; done that. Originally it was 2.6.16 but I got the same problem after upgrading (as you described) to 2.6.17. Kubuntu installs fine and that uses 2.6.15 Knoppix runs fine and it is using 2.6.17 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to control/override dev assigment 3ware and USB
On Friday 22 September 2006 23:58, RParr wrote: > Any guidance would be most appreciated; especially any way to capture > the early boot messages; /etc/default/bootlogd enabling does not seem > to help. Which kernel is being booted? If it is 2.6.16 the cause may be that your hardware needs 2.6.17. The daily images of the installer have already been using 2.6.17 for a while which could explain why you did not see any problems there. The 2.6.17 kernel is now available in testing though. To upgrade the kernel use the rescue mode of the installer, mount your root filesystem on target (the installer will ask you that) get into a chroot shell on /target and upgrade the kernel. You may have to mount proc inside the chroot. pgpFaBGTWJPYz.pgp Description: PGP signature
Bug#388846: installation: Warn of sarge apt-proxy
Package: installation Severity: wishlist I tried to install debian behind an apt-proxy and the installations hangs when fetching packages during installation (Errormsg on ALT-F4). See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388769 . It seems that all Debian etch installations and probably upgrades behind a sarge apt-proxy fail because of apt-proxy bug 374405: > Incompatible with full URL HTTP requests from recent apt versions > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374405 Upgrading the apt-proxy from sarge to backports.org solved the installation-problem. IMHO it would be nice to have a hint / warning about sarge apt-proxy in the sarge to etch upgrade instructions. Otherwise many people may stumble over this incompatibility. For installation a hint in d-i mirror selection could be sufficient. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388845 . Bye, Wolfgang -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (21, 'testing'), (20, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-3-586tsc Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Fri, Sep 22, 2006 at 10:40:34PM +0200, Frans Pop wrote: > On Friday 22 September 2006 21:32, Sven Luther wrote: > > We did never implement the thingy which disables the acceleration in > > the directfbrc, right ? > > I've committed a patch now that always disables it for ppc. Thanks, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to control/override dev assigment 3ware and USB
Jurij Smakov wrote: On Thu, Sep 21, 2006 at 05:25:13PM -0700, RParr wrote: I am still unable to get Debian installed on this machine. I AM able to boot Knoppix LiveCD and NOT have any device conflicts. Knoppix (5.0.1) assigns the 3ware /dev/sde and the USB card reader as /dev/sda, sdb, sdc, and sdd and thus has no conflict. I used the Debian netinst to boot into rescue mode, change the apt sources.list from etch to sid and dist-upgrade. That went well and the system is now booting the 2.6.17 kernel but still freezing because /dev/sde is reassigned. I have already edited /etc/default/bootlogd to enable boot logging but I get no logs. 1) Does anyone have any ideas as to how I can log the initial boot up stuff and figure out if something is getting assigned to /dev/sda (and thus starting the USB reading at /dev/sdb) or if the USB assignment is just wrong. 2) Does anyone know how best to prevent the USB drive assignments from happening. Hi, You can "blacklist" a module, so that it's not going to be automatically loaded by udev, even if a device is present. To do that, assuming the name of the module is foo, you should create an arbitrarily named file in /etc/modprobe.d directory, with contents blacklist foo You can (hopefully) try to blacklist modules usbcore, ehci_hcd and uhci_hcd to disable USB devices. To be honest, I don't think that device naming conflict is responsible for the hang, but so far I have no clue what might cause it. What CD image are you using? What are the last messages on the screen that you see? The blacklisting did not work (maybe because these drivers are built into the kernel?) I did get them to not load by pulling the plug on the USB card reader. You're right, they were not the cause (although I still think the whole /dev/sde assignment thingy is going to be problem later). Now, booting gets to the part where it says waiting for root filesystem and hangs. Before it got to the same place, spit out the USB card reader detection and hung. A ways back in the boot process, the 3Ware 8006 controller was found, module, loaded, etc. and the booting is being done from the /boot/ directory on that root partition/filesystem. It should be noted that I can boot Knoppix 5.0.1, Kubuntu 6.06, and can install Kubuntu 6.06 on this machine with none of these problems. Any guidance would be most appreciated; especially any way to capture the early boot messages; /etc/default/bootlogd enabling does not seem to help. Thanks R.Parr, RHCE, Temporal Arts -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bladr GTK theme for g-i ready for packaging
On Fri, Sep 22, 2006 at 04:10:09PM +0200, Frans Pop wrote: > On Friday 22 September 2006 15:12, Attilio Fiandrotti wrote: > > I think we may want let "icons" PNGs in place because this would allow > > me to replace the special PNGs used for the "error" (error_icon.png) > > and "warning" (note_icon.png) questions with PNGs belonging to the > > current theme in use (e.g.: stock_cancel.png and stock_apply.png ). > > If denis could provide stock_apply.png, stock_cancel.png in > > HignContrastLargeInverse too, also the accessibility theme could have > > its own nice error and note icons. > > I'm not objecting to anything that is used, but please do not include > _anything_ that is not used. It can always be added in later when it is > needed. I concur, but for a slightly different reason. The primary goal of an accessibility theme is to be usable by disabled people which could not use g-i otherwise. This is not a cosmetic issue. The HignContrastLargePrintInverse theme is usable without those icons, so I hope that it can be enabled soon. We could make it fancier later, if we have some free space/memory, but honestly I much prefer having a not appealing HignContrastLargePrintInverse theme than no theme at all, this is a first step in the right direction. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388769: installer hangs when installing packages; no abort possible
I also tried to install debian behind an apt-proxy and the installations hangs when fetching packages during installation (Errormsg on ALT-F4). It seems that all Debian etch installations behind a sarge apt-proxy fail because of apt-proxy bug 374405: > Incompatible with full URL HTTP requests from recent apt versions > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374405 Upgrading the apt-proxy from sarge to backports.org solved the installation-problem. Bye, Wolfgang
Bug#388845: debian-installer: Warn of sarge apt-proxy when selecting mirror
Package: debian-installer Severity: wishlist I tried to install debian behind an apt-proxy and the installations hangs when fetching packages during installation (Errormsg on ALT-F4). See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388769 . It seems that all Debian etch installations behind a sarge apt-proxy fail because of apt-proxy bug 374405: > Incompatible with full URL HTTP requests from recent apt versions > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374405 Upgrading the apt-proxy from sarge to backports.org solved the installation-problem. IMHO it would be nice to have a hint / warning about sarge apt-proxy when manually selecting a mirror. Otherwise many people may stumble over this incompatibility. Bye, Wolfgang -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (21, 'testing'), (20, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-3-586tsc Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Fri, Sep 22, 2006 at 09:37:28AM +0200, Attilio Fiandrotti wrote: > Last times the g-i was tested on PPC, it turned tout that > > Known good : radeonfb, vesafb (or whatever x86 uses). > Known bad : atyfb, nvidiafb > > when acceleration was enabled. > But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB > 0.9.25 and GTK 2.8.20 and many bugs got fixed. > This is the most serious bug affecting g-i on PPC, and i wasn't able to > fix it because i have no PPC HW. > Sven, do you think can give the PPC g-i a try? i will help you on > debugging it as much as i can. Ok, i gave a quick test, and discovered the following : (hardware is a pegasos machine, with radeon 9250 graphic card). I did a plain g-i from unstable build, and netbooted the vmlinuz-chrp.initrd file. It booted nicely, but ended up in a blue screen, i suppose these are the symptoms of the crash. I thus rebuilt the installer with adding : no-hardware screenshot-dir=/ (is this one still needed ?) to /etc/directfbrc, as explained in a post from december 2005 in this bug report. This one booted fine, and the only problem i could see, is shown in the following picture : http://people.debian.org/~luther/languagechooser_language-name_0.png As you can see, there is a white space where the selection should be, this works fine when you use the mouse to point on stuff, but using up/down arrow keys exhibits this behaviour rather consistently. The last issue i saw when going to the consoles with ctr+alt+Fn to investigate a bit. The console font is garbagy, but this is probably a bug in either the radeonfb driver, or the enter/leave-VT functions of directfb. When you kill the X server from the console, this happens also. Ok, that is all for now, i will propose a patch later on which always enables no-hardware on powerpc, so we can at least get some testing done, and then would be happy to do some more advanced debuging to tackle the bug and/or also the console font issue. Friendly, Sven Luther > > Attilio > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > --- > Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381979: keymap not changed in g-i after selection in kbd-chooser
On Friday 22 September 2006 22:03, Attilio Fiandrotti wrote: > Yes, i think the patch by davide should be applied: when we switch to > GTKDFB later, we'll have the chance to re-enable the check on the GDK > backend used, so that the GTK frontend works again with GTKX. You did not read the patch I attached! pgptdaR7m4l7T.pgp Description: PGP signature
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Friday 22 September 2006 21:32, Sven Luther wrote: > We did never implement the thingy which disables the acceleration in > the directfbrc, right ? I've committed a patch now that always disables it for ppc. pgpu2hF2ZnaR2.pgp Description: PGP signature
Re: [D-I] mass kernel udeb update and preparations for RC1
On Fri, Sep 22, 2006 at 02:31:43PM +0200, Frans Pop wrote: > (Reply-to set to debian-boot; please only add relevant port if needed.) > > /me wonders why there have been almost no reactions to this mail > The first part is mostly information (though a "cool" or "thanks" would be > appreciated), but the second part has some issues that need attention. > > Have D-I porters actually read the mail? > Is it useful that I send such mails at all? I was happy to hear about it. About the only reponse I have is "thanks!" :) Stephen (for m68k) > On Sunday 17 September 2006 14:28, Frans Pop wrote: > > Dear (d-i) porters, > > > > First mass upload of kernel udebs > > = > > Today I have uploaded kernel udeb updates to 2.6.17-9 _for all arches_. > > This is the first time using the 'massbuild' [1] script I wrote > > recently. > > > > Effectively this means that d-i porters won't really have to worry > > anymore about updating kernel udebs after uploads by the kernel team. > > Only if the kernel major/minor changes will I request porters to do the > > upload themselves. For stable releases (including ABI changes) I intend > > to do these mass builds and do the uploads myself. > > > > Hopefully this will help the speed with which kernel udebs are updated > > and allow you all to spend more time testing d-i ;-) > > > > Of course porters are still responsible for maintaining which modules > > will be included for each arch/flavor. If you have changes between > > kernel major/minor releases you can either commit them and upload, or > > commit them as UNRELEASED and they will be automatically included in > > the next mass build. > > > > The massbuild script can be used for single-arch builds too. Its main > > advantage is that kernel images don't need to be installed and the > > certainty that the correct kernel version will be used. Feel free to > > contact me to help you get started. > > > > Some comments on today's upload: > > - I have used the last released version of kernel-wedge and will > > normally do that in the future too > > - I have not really checked or tested the udebs [2], so there could be > > some surprises; please be alert for them > > - m68k: I had to update the dependencies from kernel-image to > > linux-image > > > > > > The road to RC1 > > === > > We are slowly moving towards RC1. I plan to post an initial planning > > later this week. > > As we get closer to Etch, testing the installer for all arches gets to > > be more important. Any time you can spend on that is very much > > appreciated. > > > > There are some issues that need attention: > > * type of initrd used > > Some arches have already switched to using initramfs for d-i initrds, > > other arches are still using cramfs or ext2. Please check if a change > > could/should be made for your architecture. > > * 2.4 support now officially dropped > > Starting with RC1 d-i will no longer support 2.4 based installations. > > All arches have been switched now and some cleanup has been started; > > more cleanup is expected and this may cause unexpected breakage. > > * support for non-devfs device names > > Colin Watson has committed a series of changes to make d-i support > > non-devfs device names. We will be slowly moving away from using > > devfs names, but the most intrusive work will be postponed until > > after Etch. Please check for unexpected breakage though. > > * partman-auto using LVM and crypto > > partman-auto-lvm now has been available for some time, but is still > > not available for all arches. LVM support is a prerequisite for > > partman-auto-crypto support which will be uploaded soon. > > Note: swap on LVM should be possible now and is even required for > > partman-auto-crypto. > > If you would like to add support for it, please see [3]. Feel free > > to contact me or David Härdeman (Alphix) for help. > > > > * mips: keyboard issues > > We've had a report about a dead keyboard on installation (#382983). > > This needs to be investigated. > > * powerpc: oldworld boot problems with recent kernels > > > > If there are other architecture specific issues that we should be aware > > of, please let me know. > > > > Cheers, > > FJP > > > > [1] > > http://svn.debian.org/wsvn/d-i/people/fjp/massbuild?op=file&rev=0&sc=0 > > [2] The script does have a number of sanity checks though. > > [3] http://lists.debian.org/debian-boot/2006/01/msg01054.html -- Stephen R. Marenka If life's not fun, you're not doing it right! <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#381979: keymap not changed in g-i after selection in kbd-chooser
Davide Viti wrote: On Tue, Sep 19, 2006 at 10:04:47AM +0200, Frans Pop wrote: On Monday 18 September 2006 23:45, Attilio Fiandrotti wrote: I did not test this by myself, but davide did it and the patch proved to work (Davide, any hint about how to reproduce a correct keymap change in the g-i ?). Davide? this was discussed tonight on IRC. GDK_WINDOWING_DIRECTFB is apparently not defined inside gtk.c the following patch works for me GDK_WINDOWING_[X11|DIRECTFB|...] is a macro defined at GTK configure time and in GTK 2.10.4 i can find it defined in gdk/gdkconfig.h, while sourcecode for package libgtk-directfb-2.0-0 doesn not contain it. The problem seems so bounded to GTK 2.8.x with backported DFB backend we currently use, and should be fixed when we switch to GTK 2.10.x. Removing the GDK backend check is harmless unless someone wants to build the GTK frontend against GTKX too, so i guess as a temporary solution it can do. I never noticed this missing define because i usually perform all my test using latest GTK from CVS, thanks to Davide who spotted this :) cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381979: keymap not changed in g-i after selection in kbd-chooser
Frans Pop wrote: On Thursday 21 September 2006 23:32, Davide Viti wrote: I have just tested keymap switching with a slightly modified patch (attached) with the current 2.8 GTK libs. Attilio: is this patch OK with you? Yes, i think the patch by davide should be applied: when we switch to GTKDFB later, we'll have the chanche to re-enable the check on the GDK backend used, so that the GTK frontend works again with GTKX. For the crash happening when the acive terminal is not VT5, i'll ask for advice on directfb-dev. cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: On Fri, Sep 22, 2006 at 02:52:24PM +0200, Attilio Fiandrotti wrote: Sven Luther wrote: Last times the g-i was tested on PPC, it turned tout that Known good : radeonfb, vesafb (or whatever x86 uses). vesafb is not built on powerpc, and the laptop we had in extremadura used a radeon chipset, altough of the R300 variety. isn't "fbonly" the PPC equivalent to "vesafb" on i386? That is offb, and no, it is totally different :) Most drivers are builtin the kernel though, so therei s really no need for offb, except for real old hardware. ah, ok! I know claudio ciccani worked a lot on DFB's Radeon driver recently, so things may have been fixed in DFB 0.9.25. Currently in unstable ? yes, the same version we're using in the g-i Known bad : atyfb, nvidiafb when acceleration was enabled. But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB 0.9.25 and GTK 2.8.20 and many bugs got fixed. And it will be better with gtk 2.10.x even, right ? On i386 this proved to be true, but i cannot speak for other archs as i never experimented anything personally. Ok. Let me think to get you an efika board once the developper program is underway. ok, BTW i'm in contact with Gentoo PPC porter, maybe i could ask him if he can let me use a PPC board to debug the g-i This is the most serious bug affecting g-i on PPC, and i wasn't able to fix it because i have no PPC HW. Yes, i will. Need to build a netboot g-i image and will test that on my pegasos with the radon 9250 board. If you experience crashes, you may want to run the d-i in a chroot cage, like explained in this [1] wiki page. Ok, thanks. Sven, do you think can give the PPC g-i a try? i will help you on debugging it as much as i can. Indeed, that is my intentions, a first test today, and more over the week-end. thanks! Having the g-i avalable for PPCs too would be really nice! Indeed. As said, i would have done this earlier, but well, the context was not favourable to this kind of things, let's say. I really hope we'll be able to deliver a working g-i to PPC users too.. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Well, My first naive test with the unstable g-i, gives just a blue screen. I can alt-ctr-f2 away, and check a bit. We did never implement the thingy which disables the acceleration in the directfbrc, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
Frans Pop wrote: On Wednesday 20 September 2006 11:00, Loïc Minier wrote: Gtk 2.10.1-1 was uploaded yesterday to experimental (and 2.10.3-1 after dinstall). This new upstream release is not compatible with modules built with prior Gtk versions. Some longstanding issues have been addressed in this release as well. I have tested g-i with the libs currently in experimental: - libgtk* 2.10.3-3 - libcairo udeb 1.2.4-2 Unfortunately this results in the following screenshot. http://people.debian.org/~fjp/d-i/g-i_boom.png Although it is a very nice feature to be able to Etch-a-sketch with the installer (and very appropriate too), it does make installations impossible. I was totally amazed when i saw the "BOOM" PNG, never seen anything like that, also because the GTK 2.10 libs provided by loic worked well for me previously: i'll try to look at this tomorrow. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388114: installation-report: Installed on HP NC6400 went ok but had problem with grub install
On Tue, Sep 19, 2006 at 12:14:09PM +0100, stephen mulcahy wrote: > Hi Geert, > > Thanks for your response - I hope the installation report is useful to > someone. > > I'm replying off-bug because I'm not sure any of the following is > relevant/useful - feel free to add in if you wish. Because we both care about others, we should can it visible for others. > See some comments below, > > Geert Stappers wrote: > > On Mon, Sep 18, 2006 at 06:31:00PM +0100, stephen mulcahy wrote: > >> Package: installation-report > >> Severity: normal > >> > >> See blog at > >> http://blog.aplpi.com/index.php/2006/09/18/debian-gnulinux-on-a-hp-nc6400/ > >> for details. Seems to be related to bug 380351 but worked around it. (FYI: #380351 is a grub-install bug, fixed in 1.18) > > Okay, fine. Thank you for reporting the succesfull install. > > You may want to mention the above bug in the errata. The sugestion makes sense. I don't if the Beta 3 errata is also frozen. > >> Also, didn't get option to install SMP kernel - should I? > > > > Recent kernels have SMP support (iow: there are no "SMP-kernels" any more) > > This is news to me - is it documented anywhere? There was only one core > available in /proc/cpuinfo until I installed the SMP flavoured 2.6.16 > kernel (is this a dummy image or are you talking about changes in > unstable/post-2.6.16?). It is a 2.6.17 thing. > > Something else: > > > > Debian-installer can resize NTFS partitions > > ( no need for an extra piece of software ) The blog says "use an extra piece of software", I'm trying to say "no need for an extra piece of software" > > Just select the partition, select the size and enter the new desired size. > > Thanks, I was aware of this but I've yet to have any success using it. That makes your feedback interresting. You are telling that something that should work, doesn't work ... > I suspect running chkdsk/f on the NTFS partition fixes the parted in > Debian aswell .. but since it was significantly older than the parted in > the gparted livecd the last time I tried it and failed I got in the > habit of using gparted. Allow me to focus on debian-installer (i.o.w. allow me to ignore the other software ;-) > I'll give it another shot the next time. What about this proposal: * backup the NTFS partition * resize the NTFS partition with debian-installer (just make it some what smaller ) * Restart the computer, boot into MS-Windows to check the partition. * resize the NTFS partition with debian-installer (back to previous size) * Restart the computer, boot into MS-Windows to check the partition. * Report/blog about the NTFS resize excersize ??? > > Have fun with you Debian GNU/Linux computer system. > > Thanks! And well done on the Debian etch installer so far - overall it > is working very well. Your efforts are appreciated. Thank you. With a non-private reply see more d-i developers your compliment. > -stephen Cheers Geert Stappers -- $ apt-cache show linux-image-2.6-686-smp Package: linux-image-2.6-686-smp Maintainer: Debian Kernel Team Version: 2.6.17+2 Description: Linux 2.6 image on PPro/Celeron/PII/PIII/P4 SMP - transition package This package is for transition only. signature.asc Description: Digital signature
Re: Preparing linux-2.6 2.6.18-1
On Thu, Sep 21, 2006 at 11:46:06AM -0600, dann frazier wrote: > The ia64/xen folks here think so too - I'm not too familiar with Xen, > but if you want to enable ia64/xen in linux-2.6 I should be able to > get help from HP people if we run into ia64-specific problems. The question is, do we want/can we support that? Bastian -- Oh, that sound of male ego. You travel halfway across the galaxy and it's still the same song. -- Eve McHuron, "Mudd's Women", stardate 1330.1 signature.asc Description: Digital signature
Bug#388114: installation-report: Installed on HP NC6400 went ok but had problem with grub install
Hi Geert, Thanks for your response - I hope the installation report is useful to someone. I'm replying off-bug because I'm not sure any of the following is relevant/useful - feel free to add in if you wish. See some comments below, Geert Stappers wrote: > On Mon, Sep 18, 2006 at 06:31:00PM +0100, stephen mulcahy wrote: >> Package: installation-report >> Severity: normal >> >> See blog at >> http://blog.aplpi.com/index.php/2006/09/18/debian-gnulinux-on-a-hp-nc6400/ >> for details. Seems to be related to bug 380351 but worked around it. > > Okay, fine. Thank you for reporting the succesfull install. You may want to mention the above bug in the errata. > >> Also, didn't get option to install SMP kernel - should I? > > Recent kernels have SMP support (iow: there are no "SMP-kernels" any more) This is news to me - is it documented anywhere? There was only one core available in /proc/cpuinfo until I installed the SMP flavoured 2.6.16 kernel (is this a dummy image or are you talking about changes in unstable/post-2.6.16?). > > > Something else: > > Debian-installer can resize NTFS partitions ( no need for an extra > piece of software ) Just select the partition, select the size > and enter the new desired size. Thanks, I was aware of this but I've yet to have any success using it. I suspect running chkdsk/f on the NTFS partition fixes the parted in Debian aswell .. but since it was significantly older than the parted in the gparted livecd the last time I tried it and failed I got in the habit of using gparted. I'll give it another shot the next time. > > > Have fun with you Debian GNU/Linux computer system. Thanks! And well done on the Debian etch installer so far - overall it is working very well. Your efforts are appreciated. -stephen -- Stephen Mulcahy, Applepie Solutions Ltd, Innovation in Business Center, GMIT, Dublin Rd, Galway, Ireland. mailto:[EMAIL PROTECTED] mobile:+353.87.2930252 office:+353.91.751262 http://www.aplpi.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: missing lspci on a fresh install
On Mon, Sep 18, 2006 at 11:56:30PM +0200, Geert Stappers wrote: > On Mon, Sep 18, 2006 at 11:24:17PM +0200, De Leeuw Guy wrote: > > Another question : where I post this kind of report ? > > If debian-boot is not the good place, ok, sorry for the disturb, but where ? > > I assume that the pointer to package 'base' has been seen. > > "base" is what the computer does need to boot. > The computer can start without the lspci program, > but it can't without a shell nor other essential programms. > > In other words: Install the package pciutils if you want the lspci tool > > > Guy > > HtH > GSt Hi, I want to say that Rick Thomas is my hero, he filed BR #388159 "Rick Thomas is my hero, he filed bugreport #388159" Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
On Thu, Sep 21, 2006 at 06:51:12PM +0200, Bastian Blank wrote: > Xen should be okay. According to the maintainer of this tree, ia64 > should work fine also. The ia64/xen folks here think so too - I'm not too familiar with Xen, but if you want to enable ia64/xen in linux-2.6 I should be able to get help from HP people if we run into ia64-specific problems. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debianinstaller/contrib
On Tue, Sep 19, 2006 at 05:03:09PM -0500, Nicolas Valcarcel wrote: > On Tue, 2006-09-19 at 13:03 +0530, Deepak Kumar Tripathi wrote: > > From: Rajasekaran J. [mailto:[EMAIL PROTECTED] > > Sent: Mon 9/18/2006 4:30 PM > > > > > > > > Hi All, > > > > > >I am Rajasekaran J. > > > I am using debian for the past two years and we came > > > out with debian based disto called as BOSS(Bharat Operating System > > > Solutions).I would like to participate the development activity of > > > DebianInstaller. > > > > > > > > > Thanks & Regards, > > > > > > Rajasekaran J > > > > > hi Rajasekaran, > > > > At what stage your team has finished it or developing in which stage. > > what help is your team is looking for. > > > > Can you please explain . > > > > > > Deepak Tripathi .---. > > Open Source Developer / \ > >[EMAIL PROTECTED]@./ > >/`\_/`\ > >.''`. // _ \\ > > : :' :| \ )|_ > > `. `'`/`\_`> <_/ \ > > `- \__/'---'\__/ > > Debian GNU/Linux > > > I think he's trying to help the team of the debian installer, > not looking for help on his proyect. Yes, that is also how I read > > > I would like to participate the development activity of DebianInstaller. One response was an unwritten "Fine, find your way how to contribute." Because it is a harsh answer, it is unwritten. Not writing rude messages avoids conflicts about the tone of an E-mail. Another time saver in silence is there are no E-mails (and time) about "What skills do you have?" and "What would you like to do?" The "no response" on an actual contribution offer leaves all the choices to the person who is offering the help. He/she can contribute where he/she thinks help is needed. And that is also the place where he/she can help best ... > P.S: sorry for my bad english. No worries Mate! Just show in your conversion that you care about what you write. Another good thing is to reply below the text. Cheers Geert Stappers signature.asc Description: Digital signature
Releasing G-I with RC1 - one RC issue remaining
Hi Attilio, With the new GTK 2.8 upload by Loïc [1] and the changes in keymap support, we now have only one RC problem remaining in G-I: the disappearing text on the current line in multi-select lists. I do not think that 2.10 will be in unstable in time for the RC1 release, so it would be great if this issue could be solved in the current 2.8 libs. Is there any way that you could backport the fix for this from 2.10? Thanks, FJP [1] The "blue lines" issue is fixed in 2.8.20-2 by #386860. pgppOJyVWSnUh.pgp Description: PGP signature
oldsys-preseed_0.4_i386.changes ACCEPTED
Accepted: oldsys-preseed_0.4.dsc to pool/main/o/oldsys-preseed/oldsys-preseed_0.4.dsc oldsys-preseed_0.4.tar.gz to pool/main/o/oldsys-preseed/oldsys-preseed_0.4.tar.gz oldsys-preseed_0.4_i386.udeb to pool/main/o/oldsys-preseed/oldsys-preseed_0.4_i386.udeb Override entries for your package: oldsys-preseed_0.4.dsc - source debian-installer oldsys-preseed_0.4_i386.udeb - optional debian-installer Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388572: apt-proxy woes during installation
Sorry if this is getting out of hand; I'm not experienced with reporting bugs. In reply to Don Wright: > The secret is to scroll to the top of the list of countries > and pick "enter information manually". That's not the issue. The issue is that it expects me to enter a "server" and a "path" part of the URI with no hint how these are going to be merged into a sources.list entry. Now my setup doesn't come with a complicated URI, yet no combination seemed to work. Eventually I had the idea to look at the generated sources.list file after entering the data (darn obvious, yes, but it took me a few hours to think of that) and I managed to enter the right data into the fields that would result in a sources.list entry similar as to what I have on working machines, namely deb http://zwerg:/main/ etch main However, this still didn't work. The installer (or apt-setup or whatever else is in charge at that time) connected to zwerg (or tried to, at any rate) but never retrieved the file. Progress stalled completely (I've filed another bug report about being unable to abort or cancel this). Only *after* I manually killed the apt-get process, the following line appeared in the log: "Failed to fetch http://zwerg:/main/pool/main/p/popularity-contest/popularity-contest_1.34_all.deb Connection failed" Interesting enough, switching to the other console I was able to retrieve the file using wget. Why apt-get stalls and wget works is beyond me; I've seen no further error message in the logs that would give me a hint. All this was using the debian-testing-amd64-netinst.iso from Wed, 20-Sep-2006. Things became a little more interesting when I tried the debian-testing-i386-businesscard.iso from today (Fri 22-Sep-2006): It would actually use my proxy to retrieve the base system, but when it came to the "select and install software" step it would again stall as described above. Now, it may well be that my apt-proxy is responsible for all of this; but I still blame the installer (or apt-setup or whatever) that it doesn't come up with a helpful error message allowing me to track down the actual problem. regards, Schnobs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware and d-i
On Tue, Sep 19, 2006 at 03:01:19PM -0400, Joey Hess wrote: > Wouter Verhelst wrote: > > I've been thinking that the best way here is to just nuke the > > configuration of the retriever before (or while) running > > customization-modules in some way. We'll be assuming that there is at > > least one way to get udebs onto the running debian-installer session; so > > the assumption that udebs have been downloaded isn't totally unfair, and > > there won't be a need to download additional modules at that point > > anymore. At least I think so; would have to do a test run to be sure. > > d-i needs to be able to load udebs from the primary source at multiple > points during the installation. Oh? Didn't know that. Okay, so that's out, then. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Wednesday 20 September 2006 11:00, Loïc Minier wrote: > Gtk 2.10.1-1 was uploaded yesterday to experimental (and 2.10.3-1 > after dinstall). This new upstream release is not compatible with > modules built with prior Gtk versions. Some longstanding issues have > been addressed in this release as well. I have tested g-i with the libs currently in experimental: - libgtk* 2.10.3-3 - libcairo udeb 1.2.4-2 Unfortunately this results in the following screenshot. http://people.debian.org/~fjp/d-i/g-i_boom.png Although it is a very nice feature to be able to Etch-a-sketch with the installer (and very appropriate too), it does make installations impossible. What happens is that on the first screen, I can use cursor keys and the mouse to select items, but as soon as I press enter or click the Continue button with the mouse, the installer freezes and I can Etch-a-sketch with the mouse. So, it looks like 2.10.3 has RC issues for the installer. Cheers, FJP pgpH7yKJswgRn.pgp Description: PGP signature
Re: Bladr GTK theme for g-i ready for packaging
On Friday 22 September 2006 15:12, Attilio Fiandrotti wrote: > I think we may want let "icons" PNGs in place because this would allow > me to replace the special PNGs used for the "error" (error_icon.png) > and "warning" (note_icon.png) questions with PNGs belonging to the > current theme in use (e.g.: stock_cancel.png and stock_apply.png ). > If denis could provide stock_apply.png, stock_cancel.png in > HignContrastLargeInverse too, also the accessibility theme could have > its own nice error and note icons. I'm not objecting to anything that is used, but please do not include _anything_ that is not used. It can always be added in later when it is needed. Memory is valuable in the installer. Don't waste it! pgpd1NlWINXXq.pgp Description: PGP signature
Bug#388769: installer hangs when installing packages; no abort possible
Package: debian-installer Version: no idea. Netinstall image was DL'ed on 22-Sep-2006 During the installation step "Select and install software", progress ground to a halt. It said "running tasksel", the progress bar remained at 1% for several minutes. A motionless progress bar doesn't convey much information; there is no hint as to what actually went wrong. Even if I knew, there is no way to abort / go back at this point (short of switching to another console and applyig some l33t linux skillz. Due to insufficient knowledge of what I was doing, this only raised even more issues). So much for the actual complaint. Here's what I was doing: According to ALT-F4, it was trying to download the popularity-contest package at that time. After killing apt-get, the log said "Failed to fetch http://zwerg:/main/pool/main/p/popularity-contest/popularity-contest_1.34_all.deb Connection failed" zwerg happens to be the local apt-proxy machine; a subsequent attempt to retrieve that file from another box on the network was sucessful, so I don't think it's he proxy's fault. ---snip--- [EMAIL PROTECTED]:~$ wget http://zwerg:/main/pool/main/p/popularity-contest/popularity-contest_1.34_all.deb --14:02:48-- http://zwerg:/main/pool/main/p/popularity-contest/popularity-contest_1.34_all.deb => `popularity-contest_1.34_all.deb' Resolving zwerg... 192.168.30.1 Connecting to zwerg[192.168.30.1]:... connected. HTTP request sent, awaiting response... 200 OK Length: 48,774 [application/dpkg] 100%[=>] 48,774 215.45K/s 14:02:49 (215.45 KB/s) - `popularity-contest_1.34_all.deb' saved [48774/48774] ---snap--- Or maybe it was the proxy's fault, after all, because currently the restarted installer is busy downloading stuff from ftp.de.debian.org -- but that's beside the point. I'm filing a bug report because I couldn't abort the stalled installation and just go back to selecting another mirror. I had to reboot the box and start over from scratch. regards, Schnobs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Hello, On Fri, Sep 22, 2006 at 03:13:14PM +0200, Jonas Smedegaard wrote: > > And exactly this is what it is all about: find a way to satisfy BOTH > > priorities, not just one. > > No. It is about the definition of "our users". > > If "our users" are dependent on non-free software, then we indirectly > say in our social contract that free and non-free software is of equal > concern to us. this is what section 5 of the social contract is about. let me cite the relevant part: "Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages" > I claim that "our users" does not include users of non-free software. This is a contradiction to the social contract. > I would even say that such users are free-riders of free software, if > their use is dependent on our system which is "100% free software". This is insulting. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Fri, Sep 22, 2006 at 02:52:24PM +0200, Attilio Fiandrotti wrote: > Sven Luther wrote: > > >>Last times the g-i was tested on PPC, it turned tout that > >> > >> Known good : radeonfb, vesafb (or whatever x86 uses). > > > > > >vesafb is not built on powerpc, and the laptop we had in extremadura used a > >radeon chipset, altough of the R300 variety. > > isn't "fbonly" the PPC equivalent to "vesafb" on i386? That is offb, and no, it is totally different :) Most drivers are builtin the kernel though, so therei s really no need for offb, except for real old hardware. > I know claudio ciccani worked a lot on DFB's Radeon driver recently, so > things may have been fixed in DFB 0.9.25. Currently in unstable ? > >> Known bad : atyfb, nvidiafb > >> > >>when acceleration was enabled. > >>But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB > >>0.9.25 and GTK 2.8.20 and many bugs got fixed. > > > > > >And it will be better with gtk 2.10.x even, right ? > > On i386 this proved to be true, but i cannot speak for other archs as i > never experimented anything personally. Ok. Let me think to get you an efika board once the developper program is underway. > >>This is the most serious bug affecting g-i on PPC, and i wasn't able to > >>fix it because i have no PPC HW. > > > > > >Yes, i will. Need to build a netboot g-i image and will test that on my > >pegasos with the radon 9250 board. > > If you experience crashes, you may want to run the d-i in a chroot cage, > like explained in this [1] wiki page. Ok, thanks. > >>Sven, do you think can give the PPC g-i a try? i will help you on > >>debugging it as much as i can. > > > > > >Indeed, that is my intentions, a first test today, and more over the > >week-end. > > thanks! Having the g-i avalable for PPCs too would be really nice! Indeed. As said, i would have done this earlier, but well, the context was not favourable to this kind of things, let's say. > Attilio > > [1] http://wiki.debian.org/DebianInstaller/GUIBuild Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] mass kernel udeb update and preparations for RC1
On Fri, Sep 22, 2006 at 02:31:43PM +0200, Frans Pop wrote: > (Reply-to set to debian-boot; please only add relevant port if needed.) > > /me wonders why there have been almost no reactions to this mail > The first part is mostly information (though a "cool" or "thanks" would be > appreciated), but the second part has some issues that need attention. > > Have D-I porters actually read the mail? > Is it useful that I send such mails at all? Well, i read it, but as i am no more d-i porter in charge of the kernels, ... But then, you could maybe do a separate mail asking about the issues which need attention or something :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Arrgh! Please ignore my post a moment ago. In a moment of carelessness I forgot my promise of throwing no more flames in this thread :-( - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgp2nsQFlR3u6.pgp Description: PGP signature
Re: Bladr GTK theme for g-i ready for packaging
Frans Pop wrote: On Friday 22 September 2006 14:39, Luca Bruno wrote: Frans Pop scrisse: Question: are all the PNGs currently included in your tarball actually used? Could any of them be left out? IIRC there are still some of them which can be stripped down, but first I need to see which icons and pixmaps are needed by the new graphical partitioner. There will be no graphical partitioner for Etch, so you only need to take the current situation into account. Please strip down the theme as far as possible. I don't know how the filesystem used for g-i ISOs performs with small files, but i noticed ext3 needs to allocate ~230 KBs of space for the whole theme, when the files provided by the theme are only ~130 KB. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
On Fri, 22 Sep 2006 11:16:02 +0200 Frederik Schueler wrote: > On Thu, Sep 21, 2006 at 02:53:21PM +0200, Jonas Smedegaard wrote: > > I honestly believe that moving linux-2.6 to non-free hurts our users > > more than stripping non-free parts of the Debian-precompiled kernel. > > of course. > > > Also, section 4 of the SC talks equally about users and free > > software, not users above free software. > > And free software above the needs of our users neither. > > And exactly this is what it is all about: find a way to satisfy BOTH > priorities, not just one. No. It is about the definition of "our users". If "our users" are dependent on non-free software, then we indirectly say in our social contract that free and non-free software is of equal concern to us. (I deliberately take the example of "non-free software" instead of of "firmware", to simplify my argument) I claim that "our users" does not include users of non-free software. I would even say that such users are free-riders of free software, if their use is dependent on our system which is "100% free software". > working together with upstream and the vendors to fix the issue is > what we should do, I agree. That is exactly what we should do. Just as we should work together with the GNU people to "fix" what we consider problems with their free documentation license. But until those issues are solved, we need to rip out any and all parts of our system that we become aware of is in violation with our own rules. > not ripping the blobs aout of the kernel and forgetting about their > existence. I see no contradiction between working with upstream and ripping out bobs (until hopefully upstream is convinced in each case). I think none wants to forget. > Guess which Distribution users who "made a poor buying choice" will > not use again. Whatever you're hinting at, it sounds like "their users", not ours. If we lose users due to removing questionable stuff from our distribution, then those users were, in my opinion, never really "ours". They really truly wanted a different kind of system, and just ended up with ours due to misunderstanding or accident or whatever. - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpKgeoOlcQwy.pgp Description: PGP signature
Re: Bladr GTK theme for g-i ready for packaging
Frans Pop wrote: On Friday 22 September 2006 09:42, Attilio Fiandrotti wrote: any progress in packaging the Bladr and HighContrastLarge GTK themes for g-i ? IIRC it was proposed to pack them into rootskel-gtk package. Yes, I'm working on it. We need some other changes first, but those are in progress. I can finalize after we have a new fontconfig upload. Question: are all the PNGs currently included in your tarball actually used? Could any of them be left out? Talking about bladr, i see almost all PNGs in the "pixmap" directory are needed, while only some in the "icons" directory are (but they are few and small when compared to those in the pixmap directory). I think we may want let "icons" PNGs in place because this would allow me to replace the special PNGs used for the "error" (error_icon.png) and "warning" (note_icon.png) questions with PNGs belonging to the current theme in use (e.g.: stock_cancel.png and stock_apply.png ). If denis could provide stock_apply.png, stock_cancel.png in HignContrastLargeInverse too, also the accessibility theme could have its own nice error and note icons. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381979: keymap not changed in g-i after selection in kbd-chooser
On Thursday 21 September 2006 23:32, Davide Viti wrote: I have just tested keymap switching with a slightly modified patch (attached) with the current 2.8 GTK libs. Attilio: is this patch OK with you? The testresults: - keymap switching works now :-) - VT1 does get quite a few messages "Reloading keymap" and "Reloaded keymap", but it does not get totally flooded, so that is acceptable - the change causes frontend crashes in some situations (see below) :-( - I have now seen a situation where regular + and - don't work to expand/collapse a the full country list (#343244), but instead activate searching; not sure what is happening exactly though as it works in other cases The frontend crashes occur only if the frontend is running while the active console is not VT5 (e.g. VT1 or VT2). I've only seen the crashes while netcfg or partman were running, i.e. when a C program is running; not sure if that is significant. I am willing to ignore this issue for RC1, but I would very much hope it can be resolved before the Etch release! Index: src/modules/frontend/gtk/gtk.c === --- src/modules/frontend/gtk/gtk.c (revision 40817) +++ src/modules/frontend/gtk/gtk.c (working copy) @@ -49,9 +49,13 @@ #include #include +#if GTK_CHECK_VERSION(2,10,0) #ifdef GDK_WINDOWING_DIRECTFB #include #endif +#else +#include +#endif #define WINDOW_WIDTH 800 #define WINDOW_HEIGHT 600 @@ -1543,10 +1547,15 @@ * for dfb to support automatic keymap change detection and reloading * (See also bug #381979) */ + +#if GTK_CHECK_VERSION(2,10,0) #ifdef GDK_WINDOWING_DIRECTFB dfb_input_device_reload_keymap( dfb_input_device_at( DIDID_KEYBOARD ) ); #endif - +#else +dfb_input_device_reload_keymap( dfb_input_device_at( DIDID_KEYBOARD ) ); +#endif + gtk_rc_reparse_all(); questionbox = gtk_vbox_new(FALSE, 0); pgpyrhYEifAZ8.pgp Description: PGP signature
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: Last times the g-i was tested on PPC, it turned tout that Known good : radeonfb, vesafb (or whatever x86 uses). vesafb is not built on powerpc, and the laptop we had in extremadura used a radeon chipset, altough of the R300 variety. isn't "fbonly" the PPC equivalent to "vesafb" on i386? I know claudio ciccani worked a lot on DFB's Radeon driver recently, so things may have been fixed in DFB 0.9.25. Known bad : atyfb, nvidiafb when acceleration was enabled. But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB 0.9.25 and GTK 2.8.20 and many bugs got fixed. And it will be better with gtk 2.10.x even, right ? On i386 this proved to be true, but i cannot speak for other archs as i never experimented anything personally. This is the most serious bug affecting g-i on PPC, and i wasn't able to fix it because i have no PPC HW. Yes, i will. Need to build a netboot g-i image and will test that on my pegasos with the radon 9250 board. If you experience crashes, you may want to run the d-i in a chroot cage, like explained in this [1] wiki page. Sven, do you think can give the PPC g-i a try? i will help you on debugging it as much as i can. Indeed, that is my intentions, a first test today, and more over the week-end. thanks! Having the g-i avalable for PPCs too would be really nice! Attilio [1] http://wiki.debian.org/DebianInstaller/GUIBuild -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Fri, Sep 22, 2006 at 09:37:28AM +0200, Attilio Fiandrotti wrote: > Sven Luther wrote: > >On Thu, Sep 21, 2006 at 03:32:28PM +0200, Frans Pop wrote: > > > >>severity 342053 important > >>thanks > >> > >>Lowering the severity of this bug to important. > >>This issue is the main reason that g-i is only provided as experimental > >>mini.iso for powerpc. However, that does not make RC for the package as a > >>whole. > > > > > >Notice: Do we have a proof that by disabling acceleration, the issue goes > >away ? > >I remember in extremadura that by booting the system by hand into text mode > >and then launching the graphical mode made it work, so i am not sure that > >we > >have only this as issue, not sure. > > Last times the g-i was tested on PPC, it turned tout that > > Known good : radeonfb, vesafb (or whatever x86 uses). vesafb is not built on powerpc, and the laptop we had in extremadura used a radeon chipset, altough of the R300 variety. > Known bad : atyfb, nvidiafb > > when acceleration was enabled. > But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB > 0.9.25 and GTK 2.8.20 and many bugs got fixed. And it will be better with gtk 2.10.x even, right ? > This is the most serious bug affecting g-i on PPC, and i wasn't able to > fix it because i have no PPC HW. Yes, i will. Need to build a netboot g-i image and will test that on my pegasos with the radon 9250 board. > Sven, do you think can give the PPC g-i a try? i will help you on > debugging it as much as i can. Indeed, that is my intentions, a first test today, and more over the week-end. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bladr GTK theme for g-i ready for packaging
On Friday 22 September 2006 14:39, Luca Bruno wrote: > Frans Pop scrisse: > > Question: are all the PNGs currently included in your tarball > > actually used? Could any of them be left out? > > IIRC there are still some of them which can be stripped down, but > first I need to see which icons and pixmaps are needed by the new > graphical partitioner. There will be no graphical partitioner for Etch, so you only need to take the current situation into account. Please strip down the theme as far as possible. TIA, Frans pgpSd6xIFsw6D.pgp Description: PGP signature
Re: Bladr GTK theme for g-i ready for packaging
Frans Pop scrisse: > Question: are all the PNGs currently included in your tarball > actually used? Could any of them be left out? IIRC there are still some of them which can be stripped down, but first I need to see which icons and pixmaps are needed by the new graphical partitioner. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno : :' : The Universal O.S.| luca.br(AT)uno.it `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Proud Debian GNU/Linux User pgp25945yqtTK.pgp Description: PGP signature
Bug#388464: debian-installer: ~2.6.17-2 amd64 kernel appears to be missing lvm-mod
reassign 388464 debian-installer tags 388464 + unreproducible thanks On Wednesday 20 September 2006 16:34, Alastair McKinstry wrote: > Installing a Dell 1950 Server (x86_64), LVM support is broken as there > is no LVM support in the kernel (-8 or -9, I believe), and no LVM > modules available. > > This worked with the i386 installer of the same build (20060920) LVM works fine for me using current daily AMD64 image using kernel udebs based on -9. Please be more specific as to what is failing. Is it just that you do not see the LVM option in the main partman menu? If so, that is because an interface change. Please see the installation guide on alioth. pgpiDxSXM3Mri.pgp Description: PGP signature
Processed: Re: Bug#388464: debian-installer: ~2.6.17-2 amd64 kernel appears to be missing lvm-mod
Processing commands for [EMAIL PROTECTED]: > reassign 388464 debian-installer Bug#388464: debian-installer: ~2.6.17-2 amd64 kernel appears to be missing lvm-mod Bug reassigned from package `linux-kernel-di-amd64-2.6' to `debian-installer'. > tags 388464 + unreproducible Bug#388464: debian-installer: ~2.6.17-2 amd64 kernel appears to be missing lvm-mod There were no tags set. Tags added: unreproducible > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
On Fri, Sep 22, 2006 at 03:25:12AM -0700, Steve Langasek wrote: > [Dropping -release from cc anyway; there's no possible reason this needs to > be cross-posted to 4 lists] > > On Fri, Sep 22, 2006 at 07:12:53AM +0200, Sven Luther wrote: > > On Thu, Sep 21, 2006 at 02:58:31AM -0500, Bill Allombert wrote: > > > On Thu, Sep 21, 2006 at 08:52:15AM +0200, Sven Luther wrote: > > > > There won't be any GR, there will be a new pet proposal until forever, > > > > and > > > > endless discussions as we start recalling the DPL, and bashing on the > > > > secretary and what not. > > > > In the absence of GR, the current situation is that sourceless > > > firmwares are not allowed in main. This is the reason the RM > > > proposed this GR in the first place. > > > The current consensus is that it is well among the power of the RMs to > > ignore a number of bugs for the sarge release, including this one. > > I see no evidence that there is a consensus on this point. Since it's the > RMs who have to make this decision to ignore these bugs, you're not going to > get very far if the RMs don't actually feel empowered to make this decision > on their own. Yeah, badly worded. Let's say that it could be interpreted as if you have the right to it, but as you said, you don't feel like going that way. > > > Re-adding them at this stage > > > 1) is against the current social contract > > > Yes, but then so is shipping the firmware actually still in main, > > So two bugs is better than one? Yes, because re-adding the drivers which used to be pruned, allow a category of users to install, which they did not previously. Thus, your arithmetic is wrong, because you don't count the "can't install" bug, and if you do, it sorts out evenly, especially if you take in account that we put non-free software and users equally in the SC. > > and i guess one could evoke the "won't discriminate" clause of the > > SC/DFSG, > > That's not what the DFSG says. No, but it certainly is in the spirit of it ? Why should we discriminate against users of non-free firmware that was decided to be removed in a distant past, over users of non-free firmware which we decide not to remove today ? > > Now, as said, this is a step back to better jump, and the real solution on > > this is to follow on with what has been done (by upstream) on the qlogic > > drivers, whose firmware is actually already in non-free, even though d-i > > doesn't support it yet. This is an upstream work, and as thus will take time > > to come to debian, but we, the debian kernel team (or at least me and > > Frederik) take the engagement to work on this during etch+1 devel cycle. > > If it is the consensus of the project that sourceless firmware doesn't > belong in main, this is a conscious regression in DFSG-compliance relative Can you quantify it ? How many such firmwares ? how many lines of code ? How many users of affected hardware ? > to sarge. I don't think that's acceptable. We obviously do have the means > to remove this particular subset of non-free firmware from main (technically But we don't have the mean to support the users of said non-free firmwares. > imperfect though it may be), and of the firmware that was removed for sarge > the only one that was important enough to get me glared at personally was > qla2xxx -- so what are these other already-removed firmwares that are so > important to have re-added now? (I did ask for a list, which no one has > provided yet; I can't find the pruning script in the kernel team's svn > repo, or I would look it up myself.) http://svn.debian.org/wsvn/kernel/dists/trunk/scripts/prune-non-free?op=file&rev=0&sc=0 Already pasted here the last time someone asked (was you maybe even ?). The complete list is : drivers/net/acenic.c drivers/net/acenic.h drivers/net/acenic_firmware.h drivers/net/dgrs.c drivers/net/dgrs.h drivers/net/dgrs_es4h.h drivers/net/dgrs_plx9060.h drivers/net/dgrs_i82596.h drivers/net/dgrs_ether.h drivers/net/dgrs_asstruct.h drivers/net/dgrs_bcomm.h drivers/net/dgrs_firmware.c drivers/net/tokenring/smctr.c drivers/net/tokenring/smctr.h drivers/net/tokenring/smctr_firmware.h drivers/media/video/dabusb.c drivers/media/video/dabusb.h drivers/media/video/dabfirmware.h drivers/usb/misc/emi62.c drivers/usb/misc/emi62_fw_m.h drivers/usb/misc/emi62_fw_s.h drivers/usb/serial/keyspan.c drivers/usb/serial/keyspan.h -drivers/usb/serial/usb-serial.h drivers/usb/serial/keyspan_mpr_fw.h drivers/usb/serial/keyspan_usa18x_fw.h drivers/usb/serial/keyspan_usa19_fw.h drivers/usb/serial/keyspan_usa19qi_fw.h drivers/usb/serial/keyspan_usa19qw_fw.h drivers/usb/serial/keyspan_usa19w_fw.h drivers/usb/serial/keyspan_usa28_fw.h drivers/usb/serial/keyspan_usa28x_fw.h
Re: [D-I] mass kernel udeb update and preparations for RC1
(Reply-to set to debian-boot; please only add relevant port if needed.) /me wonders why there have been almost no reactions to this mail The first part is mostly information (though a "cool" or "thanks" would be appreciated), but the second part has some issues that need attention. Have D-I porters actually read the mail? Is it useful that I send such mails at all? On Sunday 17 September 2006 14:28, Frans Pop wrote: > Dear (d-i) porters, > > First mass upload of kernel udebs > = > Today I have uploaded kernel udeb updates to 2.6.17-9 _for all arches_. > This is the first time using the 'massbuild' [1] script I wrote > recently. > > Effectively this means that d-i porters won't really have to worry > anymore about updating kernel udebs after uploads by the kernel team. > Only if the kernel major/minor changes will I request porters to do the > upload themselves. For stable releases (including ABI changes) I intend > to do these mass builds and do the uploads myself. > > Hopefully this will help the speed with which kernel udebs are updated > and allow you all to spend more time testing d-i ;-) > > Of course porters are still responsible for maintaining which modules > will be included for each arch/flavor. If you have changes between > kernel major/minor releases you can either commit them and upload, or > commit them as UNRELEASED and they will be automatically included in > the next mass build. > > The massbuild script can be used for single-arch builds too. Its main > advantage is that kernel images don't need to be installed and the > certainty that the correct kernel version will be used. Feel free to > contact me to help you get started. > > Some comments on today's upload: > - I have used the last released version of kernel-wedge and will > normally do that in the future too > - I have not really checked or tested the udebs [2], so there could be > some surprises; please be alert for them > - m68k: I had to update the dependencies from kernel-image to > linux-image > > > The road to RC1 > === > We are slowly moving towards RC1. I plan to post an initial planning > later this week. > As we get closer to Etch, testing the installer for all arches gets to > be more important. Any time you can spend on that is very much > appreciated. > > There are some issues that need attention: > * type of initrd used > Some arches have already switched to using initramfs for d-i initrds, > other arches are still using cramfs or ext2. Please check if a change > could/should be made for your architecture. > * 2.4 support now officially dropped > Starting with RC1 d-i will no longer support 2.4 based installations. > All arches have been switched now and some cleanup has been started; > more cleanup is expected and this may cause unexpected breakage. > * support for non-devfs device names > Colin Watson has committed a series of changes to make d-i support > non-devfs device names. We will be slowly moving away from using > devfs names, but the most intrusive work will be postponed until > after Etch. Please check for unexpected breakage though. > * partman-auto using LVM and crypto > partman-auto-lvm now has been available for some time, but is still > not available for all arches. LVM support is a prerequisite for > partman-auto-crypto support which will be uploaded soon. > Note: swap on LVM should be possible now and is even required for > partman-auto-crypto. > If you would like to add support for it, please see [3]. Feel free > to contact me or David Härdeman (Alphix) for help. > > * mips: keyboard issues > We've had a report about a dead keyboard on installation (#382983). > This needs to be investigated. > * powerpc: oldworld boot problems with recent kernels > > If there are other architecture specific issues that we should be aware > of, please let me know. > > Cheers, > FJP > > [1] > http://svn.debian.org/wsvn/d-i/people/fjp/massbuild?op=file&rev=0&sc=0 > [2] The script does have a number of sanity checks though. > [3] http://lists.debian.org/debian-boot/2006/01/msg01054.html pgpd83vnCPbGf.pgp Description: PGP signature
Re: grub2 on powerpc
On Tue, Sep 19, 2006 at 10:19:28AM +0200, Gaudenz Steinlin wrote: > On Sun, Sep 17, 2006 at 12:20:43PM +0200, Aurélien GÉRÔME wrote: > > On Sun, Sep 17, 2006 at 11:24:41AM +0200, Sven Luther wrote: > > > ofpathname is part of the ibm-powerpc-utils package (not the same as the > > > package currently in debian), and Aurelien Gerome is packaging it, since > > > yaboot also needs it over the kind-of-broken ofpath found in the yaboot > > > code, > > > so this should be less an issue than you think. > > > > This is Bug#386675 (ITP: powerpc-ibm-utils -- Utilities for maintenance > > of IBM PowerPC platforms) which blocks Bug#377097 (yaboot: ofpath > > fails on IBM JS21 blades). > > > > The powerpc-ibm-utils package will have the same Priority & Section > > the legacy powerpc-utils package have, i.e. important & utils, and > > Yaboot will depend on it to use ofpathname. > > Why not put it into the powerpc-utils package then? As far as I Because Michael Schmitz thinks it is a bad idea, and doesn't really believe in group maintenance ? > understood from the discussion, ofpathname is not specific to IBM > powerpc machines. It should work on every OpenFirmware based powerpc > (including macs), correct? It may be a bit more buggy on powermacs than on true CHRP boxes, and there are some issues yet, which it would be good to fix ASAP. There are three packages indeed, the powerpc-utils, the powerpc-utils-papr (ibm 64bit specific) and the librtas one. only the first has any chance to work on powermacs. But indeed, my original proposal was to include all those packages in the same powerpc-utils source package, with some binary packages, but neither Aurelien nor Michael where trilled over it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bladr GTK theme for g-i ready for packaging
On Friday 22 September 2006 09:42, Attilio Fiandrotti wrote: > any progress in packaging the Bladr and HighContrastLarge GTK themes > for g-i ? IIRC it was proposed to pack them into rootskel-gtk package. Yes, I'm working on it. We need some other changes first, but those are in progress. I can finalize after we have a new fontconfig upload. Question: are all the PNGs currently included in your tarball actually used? Could any of them be left out? pgpLG3GSrIjhF.pgp Description: PGP signature
Re: Preparing linux-2.6 2.6.18-1
On Thursday 21 September 2006 19:01, Frans Pop wrote: > It will only hit the mirrors tonight or maybe even tomorrow (not sure). > I will try to run an installation test tomorrow to see if 2.6.17 is > picked up correctly. Tested and OK. pgpcD2wdz1o73.pgp Description: PGP signature
Bug#388549: Please pull avahi-daemon with a GNOME desktop installation (for Rhythmbox)
Am Freitag, den 22.09.2006, 00:53 +0200 schrieb Sjoerd Simons: > On Thu, Sep 21, 2006 at 01:50:23PM -0400, Joey Hess wrote: > > Ross, since you maintain it, I'd appreciate any thoughts you have about > > whether avahi should be included in the default desktop install. IMHO, > > you should have veto power over putting it in; conversely if you think > > it's a good idea that will count for something in my decision. > > I really would like to see avahi in the default (gnome?, kde?,.. ) desktop > install. All parts of zeroconf should really be what the name implies, no > extra > configurations needed. Having things like music sharing (when turned on in > rhythmbox), the autodetection of local websites in epiphany or the > autodetection of local ftp/sftp/dav-shares in nautilus just work is imho an > important part of the polish that we as a distribution can provide to the > gnome > desktop. I don't know how well it's integrated in the other desktops, so i > guess that should be on a case-by-case basis. Completely agreed here, we should have it installed and enabled by default, at least for gnome (I don't know how the situation is on KDE). Also I agree to Lennart's assessment that regarding security implications it is more likely that DNS/DHCP are a problem than avahi-daemon. But we should only enable/install avahi-daemon by default, not avahi-autoipd (which will be packaged with 0.6.14) as this was not yet really widely tested and could have some unforeseen consequences. Maybe later, in the default configuration it shouldn't interfere with something else and only makes your life better at the times where no DHCP server is available (which you can't say about the "zeroconf" package when looking at the bugreports). IMHO Ubuntu's decision to have it a) not installed by default and b) not running by default even after installing it with the upcoming release is wrong and destroys the real use of zeroconf (beeing zero configuration)... I wouldn't create a "zeroconf" task as it's a bit weird to "configure" (i.e. select the task) something to have no configuration ;) > If avahi is install by default though, libnss-mdns should probably be in too. > Although that package needs some work (ensuring automatic setup of nsswitch..) > and the maintainer seems MIA :(. I've been planning to do some work on the > package, but didn't have the time yet.. Agreed... after fixing the few points you and Lennart mentioned on IRC. Bye signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Processed: Re: Bug#388591: nobootloader: [powerpc]
Processing commands for [EMAIL PROTECTED]: > tags 388591 pending Bug#388591: nobootloader: [powerpc] Tags were: d-i patch Tags added: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#388671: cdebconf-gtk-udeb: should support double click and pressing enter in partitioner menu
Processing commands for [EMAIL PROTECTED]: > forcemerge 383946 388671 Bug#383946: installation-report: Double-click doesn't work in choose country dialog Bug#388671: cdebconf-gtk-udeb: should support double click and pressing enter in partitioner menu Bug#382357: double click on leaf item in lists should continue Bug#382359: double click on partman partition does not open partition Forcibly Merged 382357 382359 383946 388671. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#251905: Problems/workarounds for install to root on LVM on RAID
I just tried a root-on-RAID1 setup and the only issue was that GRUB was only installed to the MBR of the first hard disk, so when I simulated the failure of the first disk, the system would not boot. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 signature.asc Description: This is a digitally signed message part
Re: Preparing linux-2.6 2.6.18-1
[Dropping -release from cc anyway; there's no possible reason this needs to be cross-posted to 4 lists] On Fri, Sep 22, 2006 at 07:12:53AM +0200, Sven Luther wrote: > On Thu, Sep 21, 2006 at 02:58:31AM -0500, Bill Allombert wrote: > > On Thu, Sep 21, 2006 at 08:52:15AM +0200, Sven Luther wrote: > > > There won't be any GR, there will be a new pet proposal until forever, and > > > endless discussions as we start recalling the DPL, and bashing on the > > > secretary and what not. > > In the absence of GR, the current situation is that sourceless > > firmwares are not allowed in main. This is the reason the RM > > proposed this GR in the first place. > The current consensus is that it is well among the power of the RMs to > ignore a number of bugs for the sarge release, including this one. I see no evidence that there is a consensus on this point. Since it's the RMs who have to make this decision to ignore these bugs, you're not going to get very far if the RMs don't actually feel empowered to make this decision on their own. > > Re-adding them at this stage > > 1) is against the current social contract > Yes, but then so is shipping the firmware actually still in main, So two bugs is better than one? > and i guess one could evoke the "won't discriminate" clause of the > SC/DFSG, That's not what the DFSG says. > Now, as said, this is a step back to better jump, and the real solution on > this is to follow on with what has been done (by upstream) on the qlogic > drivers, whose firmware is actually already in non-free, even though d-i > doesn't support it yet. This is an upstream work, and as thus will take time > to come to debian, but we, the debian kernel team (or at least me and > Frederik) take the engagement to work on this during etch+1 devel cycle. If it is the consensus of the project that sourceless firmware doesn't belong in main, this is a conscious regression in DFSG-compliance relative to sarge. I don't think that's acceptable. We obviously do have the means to remove this particular subset of non-free firmware from main (technically imperfect though it may be), and of the firmware that was removed for sarge the only one that was important enough to get me glared at personally was qla2xxx -- so what are these other already-removed firmwares that are so important to have re-added now? (I did ask for a list, which no one has provided yet; I can't find the pruning script in the kernel team's svn repo, or I would look it up myself.) > But due to everyone (including you), trying to pull the glory to themselves, > and proposing their pet GR to muddle the issue, without any respect for the > GRs proposed previously, and because of the loophole in the constitution, I don't believe there is any loophole there. The constitution defines what it means for an amendment to be accepted, and it does not apply to additional related resolution proposals, it only applies to amendments to a resolution that are *accepted by the proposer*. Which means independent draft proposals are not supposed to reset the minimum discussion period. (FWIW, it took a hint from AJ for me to recognize that this is what the constitution actually says, but Ian Jackson -- original author of the constitution -- has recently confirmed this understanding.) Anyway, I think we'd be able to get to the point of holding a vote much sooner if we weren't having distracting side discussions like this one. I know it's sucking up time that *I* would rather be spending examining the various resolutions that are already out there. > So, given the defaillance of the GR system, there is no point in worrying > about the vote or not, and always remember, that debian was at the base, and > still is to a mesure, a system where those who do the work get to do the > decision, so you know what you have to do if you want those firmwares not to > be in main :) Well, all /I/ have to do to keep the reintroduced firmware blobs from being in etch is to freeze the linux-2.6 package at 2.6.17 :/ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388549: Please pull avahi-daemon with a GNOME desktop installation (for Rhythmbox)
On Fri, 2006-09-22 at 00:53 +0200, Sjoerd Simons wrote: > On Thu, Sep 21, 2006 at 01:50:23PM -0400, Joey Hess wrote: > > Ross, since you maintain it, I'd appreciate any thoughts you have about > > whether avahi should be included in the default desktop install. IMHO, > > you should have veto power over putting it in; conversely if you think > > it's a good idea that will count for something in my decision. > > While Ross is still listed as the maintainer, in practise the package is > maintained by Sebastian Droege and myself. Guess we should change the > maintainer failed someday :) That's probably a good idea. :) > I really would like to see avahi in the default (gnome?, kde?,.. ) desktop > install. All parts of zeroconf should really be what the name implies, no > extra > configurations needed. Having things like music sharing (when turned on in > rhythmbox), the autodetection of local websites in epiphany or the > autodetection of local ftp/sftp/dav-shares in nautilus just work is imho an > important part of the polish that we as a distribution can provide to the > gnome > desktop. I don't know how well it's integrated in the other desktops, so i > guess that should be on a case-by-case basis. > > If avahi is install by default though, libnss-mdns should probably be in too. > Although that package needs some work (ensuring automatic setup of nsswitch..) > and the maintainer seems MIA :(. I've been planning to do some work on the > package, but didn't have the time yet.. For what it's worth, I agree. Both libnss-mdns should be installed and enabled by default. If people object to the open socket, then installed but not enabled by default would be sufficient. The core avahi-daemon isn't large (~500K installed) so this isn't a big deal. Note that Ubuntu Edgy (AFAIK) does not install Avahi by default, and even if you install it, it defaults to not running. This is due to their "no open ports" policy I presume. However if I was in their situation I'd have installed but not enabled it by default, as they are putting unneeded barriers to working mDNS. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Re: Preparing linux-2.6 2.6.18-1
Hello, On Thu, Sep 21, 2006 at 02:53:21PM +0200, Jonas Smedegaard wrote: > I honestly believe that moving linux-2.6 to non-free hurts our users > more than stripping non-free parts of the Debian-precompiled kernel. of course. > Also, section 4 of the SC talks equally about users and free software, > not users above free software. And free software above the needs of our users neither. And exactly this is what it is all about: find a way to satisfy BOTH priorities, not just one. As long as there is no working alternative to shipping firmwares in main, removing them is simply wrong. working together with upstream and the vendors to fix the issue is what we should do, not ripping the blobs aout of the kernel and forgetting about their existence. Guess which Distribution users who "made a poor buying choice" will not use again. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Preparing linux-2.6 2.6.18-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 21 Sep 2006 12:58:14 +0200 Frederik Schueler wrote: > On Wed, Sep 20, 2006 at 06:16:32PM -0700, Steve Langasek wrote: > > On Wed, Sep 20, 2006 at 03:38:50PM +0200, Frederik Schueler wrote: > > > Second: this release contains ALL binary firmware blobs shipped > > > upstream, even those we kept pruning since the day Herbert Xu > > > removed them the first time in 2004. > > > > What in the world? Why would you do that anyway? > > because removing firmwares without an adequate alternative means not > considering the needs of our users which rely on these firmware blobs > to run their hardware, and thus IMHO conflicts with section 4 of the > social contract. > > > > Neither is introducing regressions in the freeness of our kernel > > packages relative to sarge. > > pruning the firmware without an alternative was wrong in the first > place, this step just fixes that error. > > > > Indeed, taking such a step is likely to lead many voters > > to think that the only way to prevent the kernel team from filling > > our kernel packages with as much non-free code as they can stuff > > into it is by voting down any GRs that would relax our stance on > > firmware. *THAT* would cause release delays. > > This would be a gross overreaction, and if this happens, I will opt > for moving linux-2.6 to non-free until the firmware issue is sorted > out *completely* with upstream and the hardware vendors. I honestly believe that moving linux-2.6 to non-free hurts our users more than stripping non-free parts of the Debian-precompiled kernel. Also, section 4 of the SC talks equally about users and free software, not users above free software. Then again, you can argue that binary blobs are not software, so the section is really about users above "anything but what you choose to define as software"... :-P But wait: If our main concern is "our users and free software", and binary blobs are not software, then users of binary blobs are not *our* users, and we don't favor them. Let the flamewar continue - I promise to not respond any more to this thread! - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFEotBn7DbMsAkQLgRAkrCAJ4kUA9DTfb5zrvubPi53l7lj5XLLQCghZrE AD90Dz26w+U6YnopxCwWrCs= =CWri -END PGP SIGNATURE-
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: On Thu, Sep 21, 2006 at 03:32:28PM +0200, Frans Pop wrote: severity 342053 important thanks Lowering the severity of this bug to important. This issue is the main reason that g-i is only provided as experimental mini.iso for powerpc. However, that does not make RC for the package as a whole. Notice: Do we have a proof that by disabling acceleration, the issue goes away ? I remember in extremadura that by booting the system by hand into text mode and then launching the graphical mode made it work, so i am not sure that we have only this as issue, not sure. Last times the g-i was tested on PPC, it turned tout that Known good : radeonfb, vesafb (or whatever x86 uses). Known bad : atyfb, nvidiafb when acceleration was enabled. But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB 0.9.25 and GTK 2.8.20 and many bugs got fixed. This is the most serious bug affecting g-i on PPC, and i wasn't able to fix it because i have no PPC HW. Sven, do you think can give the PPC g-i a try? i will help you on debugging it as much as i can. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bladr GTK theme for g-i ready for packaging
Attilio Fiandrotti wrote: Hi Luca Bruno has just finished polishing up his nice "Bladr" GTK+ theme, that i propose as default GTK theme for use in the g-i. A tarball can be found here [1] and i suggest (at least for the short period) to package Bladr in the rootskel-gtk theme like it was proposed to do for the GTK accessibility theme by Denis. An issue arises: to make GTKDFB able to load PNGs for themes, the pixmap loading library must be provided, like the package gtk2-engines-pixmap does on a regular debian system by providing "libpixmap.so" on a X GTK target. I guess this issue has to be managed by the gtk-gnome-team, should we ask them to provide a .udeb containing the libpixmap.so engine only ? Hi any progress in packaging the Bladr and HighContrastLarge GTK themes for g-i ? IIRC it was proposed to pack them into rootskel-gtk package. cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
