Re: [D-I] mass kernel udeb update and preparations for RC1
On 9/22/06, Frans Pop <[EMAIL PROTECTED]> 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 read the mail, sorry, I'm not a porter, Of course I must say "THANKS" I'm a 64 bit user. THANKS. 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 -- Engañarse por amor es el engaño más terrible; es una pérdida eterna para la que no hay compensación ni en el tiempo ni en la eternidad. Kierkegaard Jaime Ochoa Malagón Integrated Technology Tel: (55) 52 54 26 10
Bug#150791: After evaluating
Sorry for taking so long to reply. We are sorry to inform you that our product is still not in stores. Currently we are only offering it on our product website and plan on having it in stores come November 2006. As mentioned Dr. Banks is still recommending a 4 month supply for best results. If you have anymore health concerns then feel free to send me an email. Below I have posted our site for further info. Company Website: http://097.muggadget.com Sterling Koch
Bug#195955: Please consider
Sorry for taking so long to reply. We are sorry to inform you that our product is still not in stores. Currently we are only offering it on our product website and plan on having it in stores come November 2006. As mentioned Dr. Winslow is still recommending a 4 month supply for best results. If you have anymore health concerns then feel free to send me an email. Below I have posted our site for further info. Company Website: http://097.mugutensil.com Nelda Mason
Bug#150779: Thank you for your inquiry
Sorry for taking so long to reply. We are sorry to inform you that our product is still not in stores. Currently we are only offering it on our product website and plan on having it in stores come November 2006. As mentioned Dr. English is still recommending a 4 month supply for best results. If you have anymore health concerns then feel free to send me an email. Below I have posted our site for further info. Company Website: http://097.mugfork.com Mary Ayers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212881: Please consider
Sorry for taking so long to reply. We are sorry to inform you that our product is still not in stores. Currently we are only offering it on our product website and plan on having it in stores come November 2006. As mentioned Dr. Weiss is still recommending a 4 month supply for best results. If you have anymore health concerns then feel free to send me an email. Below I have posted our site for further info. Company Website: http://097.muggadget.com Terrell Means
Bug#137991: To learn more
Sorry for taking so long to reply. We are sorry to inform you that our product is still not in stores. Currently we are only offering it on our product website and plan on having it in stores come November 2006. As mentioned Dr. Lang is still recommending a 4 month supply for best results. If you have anymore health concerns then feel free to send me an email. Below I have posted our site for further info. Company Website: http://097.mugtool.com Eloise Golden
rootskel_1.38_i386.changes ACCEPTED
Accepted: rootskel-bootfloppy_1.38_i386.udeb to pool/main/r/rootskel/rootskel-bootfloppy_1.38_i386.udeb rootskel_1.38.dsc to pool/main/r/rootskel/rootskel_1.38.dsc rootskel_1.38.tar.gz to pool/main/r/rootskel/rootskel_1.38.tar.gz rootskel_1.38_i386.udeb to pool/main/r/rootskel/rootskel_1.38_i386.udeb Override entries for your package: rootskel-bootfloppy_1.38_i386.udeb - extra debian-installer rootskel_1.38.dsc - source debian-installer rootskel_1.38_i386.udeb - standard 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#152152: maryann blicharz Approved
Hi, Annie has re ceieevi ed your fill ed app lication. Lillian shall then Re-confirm yo ur infom ation. http://BEA1D1.n0.be For maryann blicharz and your Cr. R ating is not a factor. All Re financetypes have been approoved for you maryann blicharz Thanks, George -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#152152: Reg. Quote for maryann blicharz
Hello, Denis has rec eiieved your filled app. Damien shall then Re-confirm yo ur info. http://0F2780.ssr.be For maryann blicharz and your past Track Record is not an iss ue. All re Financetypes have been aproved for you maryann blicharz Res pects, Merle -- 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 Sat, Sep 23, 2006 at 10:46:05PM +0200, Attilio Fiandrotti wrote: > Sven Luther wrote: > >On Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: > > > >>looking at DFB's supported-hardware page > >> > >>http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics > > > > > >Well, ... > > > >I did some try with my xgi card, and even though i disabled hardware > >acceleration, this is a nogo. I ended up in a messed up text terminal (with > >black blocks and â chars for the box borders and shadow). > > > >So, it is clear that directfb needs not only the per-card drivers for > >acceleration, but also for normal usage. > > You're talking about per-card framebuffer devices, not per-card DFB > gfxdrivers, right? > On i386 the vesafb device can be used in place of card-specific fb > devices and DFB will run unaccelerated on top of it. > Does a device driver equivalent to vesafb exists for PPCs? Forget it, there is something clearly wrong in my 2.6.18 based gtk-di build, even the radeon has problems, so i probably did some error in the build. Will investigate tomorrow. Friendly, Sven Luther
Bug#388572: marked as done (debian-installer won't let me select a local apt-proxy mirror)
Your message dated Sun, 24 Sep 2006 00:00:07 +0200 with message-id <[EMAIL PROTECTED]> and subject line my apologies has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: debian-installer Version: no idea. Netinstall image was DL'ed on 20-Sep-2006 The way you're expected to enter a server and path differs from how sources are defined in every other place; it's not apparent how they are translated into a sources.list entry. After trying several combinations of "server" and "path" statements to no avail, I resigned and switched to the second console in an attempt to edit the sources.list manually. In vain, though, as the installer would immediately uncomment my changes in an attempt to make a clean start. Good intentions notwithstanding, I found this to be annoying. Please bring back the option to edit the sources.list file; while it may look scary to a beginner, even a half-experienced user who has no idea how sources work (like me) could still add a valid entry simply by copying it verbatim from another source. regards, Schnobs --- End Message --- --- Begin Message --- The actual problem was an old (and long since closed) apt-proxy bug: #374405: Incompatible with full URL HTTP requests from recent apt versions An update of the apt-proxy machine would be overdue, it seems. I still find it interesting that while installing the base system, outdated apt-proxy served well -- apparently the old way (no full URLs) is still being used during that step. However, the actual issue of the installer not getting along with my apt-proxy was in no way a bug in apt-setup, but my own damn fault. I'm sorry for wasting your time. regards, Schnobs --- End Message ---
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 10:50:37PM +0200, Attilio Fiandrotti wrote: > IIUC, you loaded the per-card (SiS) fb device, but DFB ran unaccelerated > because it didn't recognize the board and furthermore acceleration was > forced off, right? No, i didn't even get into gtk-di, i ended up in a somewhat messed up text di, i don't know why. Let me retry this image with the radeon. > In this case i wonder where the bug is, in the framebuffer device or in > DFB card-indipendent code? > Should we start x-posting on directfb-devel to get an expert help? Yes, this would be nice. Maybe you can introduce the problem, and i give a full summary of what i have experienced thus far ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389096: installation-reports
Package: installation-reports Boot method: CD Image version: From sources.list: deb cdrom:[Debian GNU/Linux testing _Etch_ - Official Snapshot amd64 Binary-1 (20060810)] Date: 2006-08-30 Machine: Selfmade: MSI K8N-SLI, 3x250GB SATA as RAID with LVM Processor:AMD64 3000+ Memory: # free total used free sharedbuffers cached Mem: 33515123306688 44824 0 2366242181348 -/+ buffers/cache: 8887162462796 Swap: 97672883169766972 Partitions: # df -Tl Dateisystem Typ1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf /dev/mapper/RAID-root ext310321208484008 9312912 5% / tmpfstmpfs 167575612 1675744 1% /dev/shm /dev/md1 ext3 90195 12223 73160 15% /boot /dev/mapper/RAID-home ext382569904 67374696 11000904 86% /home /dev/mapper/RAID-mmedia ext3 247709760 199405572 35721276 85% /mmedia /dev/mapper/RAID-srv ext361927420 34753148 24028544 60% /srv /dev/mapper/RAID-tmp ext2 4128448 156 3918580 1% /tmp /dev/mapper/RAID-usr ext3 5160576 4463008435424 92% /usr /dev/mapper/RAID-var ext3 4128448651452 3267284 17% /var tmpfstmpfs 10240 116 10124 2% /dev Output of lspci and lspci -n: lspci 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a4) 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a4) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a4) 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f3) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:06.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08) 01:07.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02) 01:09.0 SCSI storage controller: Adaptec AIC-7861 (rev 01) 01:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 05:00.0 VGA compatible controller: nVidia Corporation NV44 [GeForce 6200 LE] (rev a1) lspci -n 00:00.0 0580: 10de:005e (rev a4) 00:01.0 0601: 10de:0050 (rev a4) 00:01.1 0c05: 10de:0052 (rev a2) 00:02.0 0c03: 10de:005a (rev a2) 00:02.1 0c03: 10de:005b (rev a4) 00:04.0 0401: 10de:0059 (rev a2) 00:06.0 0101: 10de:0053 (rev f3) 00:07.0 0101: 10de:0054 (rev f3) 00:08.0 0101: 10de:0055 (rev f3) 00:09.0 0604: 10de:005c (rev a2) 00:0a.0 0680: 10de:0057 (rev a3) 00:0b.0 0604: 10de:005d (rev a3) 00:0c.0 0604: 10de:005d (rev a3) 00:0d.0 0604: 10de:005d (rev a3) 00:0e.0 0604: 10de:005d (rev a3) 00:18.0 0600: 1022:1100 00:18.1 0600: 1022:1101 00:18.2 0600: 1022:1102 00:18.3 0600: 1022:1103 01:06.0 0200: 8086:1229 (rev 08) 01:07.0 0100: 9005:0080 (rev 02) 01:09.0 0100: 9004:6178 (rev 01) 01:0c.0 0c00: 1106:3044 (rev 80) 05:00.0 0300: 10de:0163 (rev a1) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[o ] Configure network HW: [E ] Config network: [o ] Detect CD: [o ] Load installer modules: [o ] Detect hard drives: [o ] Partition hard drives: [o ] Create file systems:[o ] Mount partitions: [o ] Install base system:[o ] Install boot loader:[o ] Reboot: [o ] Comments/Problems: I used the grafical Installer the first time. The network interface is detected as NVIDIA but i can't get an Internet connection. Thats the reason for the e100 Interface. I use a RAID1 of three partitions at three disks for /boot and a RAID5 of three partitions at three disks for LVM with grub. During the bootloader installation is there a way to install it on every MBR of the disks? I did it after installation manualy. After installation i installed openoffice, worked fine. Then after apt-updete a
Re: Gtk 2.10 availability
On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: > First, the bad news: GTK 2.10.4 has a broken DFB backend, as an old > bugfix [1] by Mike Emmel icluded in CVS was not relesed, so to get a > working GTKDFB library you'll have to use sources form CVS HEAD. The link you're giving seems like the solution of the bug I've searched the last hour or so. If it's only that, it should be easy to include in the Debian packages, thanks for the pointer. > In addition to this, the bug i posted about in July still affects GTK > CVS HEAD, so i think this is enough to try re-backporting from scratch > the HEAD GDKDFB to 2.8.20 (current DFB backend in debian unstable is > dated around May 2006). I checked with Joss, and he said you did the backporting. Would you provide a similar patch or explain the process you followed to make it? -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389079: partman-md: 2.6.18 kernel renamed raid5 module to raid456.
reassign 389079 mdcfg tags 389079 + pending thanks On Saturday 23 September 2006 21:05, Sven Luther wrote: > FYI, so partman-md doesn't break once 2.6.18 is uploaded to unstable > and migrated to testing, especially important since 2.6.18 is the etch > target release kernel. Module loading updated in: - mdcfg - partman-auto-raid - rescue For now both new and old modules are tried. pgp9xTYqjeOKg.pgp Description: PGP signature
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Eddy Petrişor wrote: A round of PPC tests would be useful, especially it happens to find owners of ATI or NVIDIA boards. Got one. Eddy, do you have the chance to test if forcing off DFB's HW acceleration makes g-i run on your Mac?
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: On Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: looking at DFB's supported-hardware page http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics Well, ... I did some try with my xgi card, and even though i disabled hardware acceleration, this is a nogo. I ended up in a messed up text terminal (with black blocks and â chars for the box borders and shadow). So, it is clear that directfb needs not only the per-card drivers for acceleration, but also for normal usage. You're talking about per-card framebuffer devices, not per-card DFB gfxdrivers, right? On i386 the vesafb device can be used in place of card-specific fb devices and DFB will run unaccelerated on top of it. Does a device driver equivalent to vesafb exists for PPCs? That said, i couldn't find any kind of directfb log or something, so maybe the above guess was bad, and something else funny happened, since that was with a 2.6.18 kernel. Usually DFB produces some debug output on VT1, can you get any info there? Attilio
Bug#389092: etch-beta-installer: can't install KDE from graphical installer
Package: tasksel
Version: etch-beta-installer
Severity: minor
I just tried today's Etch beta netinst install CD. Since I was curious I
tried the graphical installer ("installgui" installation mode). When the
'tasksel' step was reached I wished I could have installed KDE. But
there was only a "Desktop" task that installed a Gnome system. How can a
user install KDE directly during the installation phase from the
graphical installer?
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages tasksel depends on:
ii aptitude 0.4.3-1terminal-based apt frontend
ii debconf [debconf-2.0] 1.5.4 Debian configuration management sy
ii liblocale-gettext-perl1.05-1 Using libc functions for internati
ii tasksel-data 2.54 Official tasks used for installati
tasksel recommends no packages.
-- debconf information excluded
--
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 Sat, Sep 23, 2006 at 10:13:10PM +0200, Sven Luther wrote: On Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: looking at DFB's supported-hardware page http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics Well, ... I did some try with my xgi card, and even though i disabled hardware acceleration, this is a nogo. I ended up in a messed up text terminal (with black blocks and â chars for the box borders and shadow). So, it is clear that directfb needs not only the per-card drivers for acceleration, but also for normal usage. That said, i couldn't find any kind of directfb log or something, so maybe the above guess was bad, and something else funny happened, since that was with a 2.6.18 kernel. DirectFB only supports : FB_ACCEL_SIS_GLAMOUR_2 FB_ACCEL_SIS_XABRE While my card is : FB_ACCEL_XGI_VOLARI_V But that is only for accel. I didn't find where the pci ids are checked, but maybe this is related to the sis->xgi vendor id change. IIUC, you loaded the per-card (SiS) fb device, but DFB ran unaccelerated because it didn't recognize the board and furthermore acceleration was forced off, right? In this case i wonder where the bug is, in the framebuffer device or in DFB card-indipendent code? Should we start x-posting on directfb-devel to get an expert help? Attilio
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 11:35:28PM +0300, Eddy Petrişor wrote: > On 23/09/06, Attilio Fiandrotti <[EMAIL PROTECTED]> wrote: > >> Also, about the console font corruption with radeonfb, i would be > >interested > >> in feedback of if it is a powerpc only issue, or ppc stuff ? > > > >No idea, i on no radeon boards :( > > $ lspci | grep ATI > :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 > [Mobility Radeon 9600 M10] So, do you see the garbage in the console too ? Ah, but i suppose you don't use radeonfb, but vesafb, right ? Friendly, Sven Luther
Processed: Re: Bug#389079: partman-md: 2.6.18 kernel renamed raid5 module to raid456.
Processing commands for [EMAIL PROTECTED]: > reassign 389079 mdcfg Bug#389079: partman-md: 2.6.18 kernel renamed raid5 module to raid456. Bug reassigned from package `partman-md' to `mdcfg'. > tags 389079 + pending Bug#389079: partman-md: 2.6.18 kernel renamed raid5 module to raid456. There were no tags set. Tags added: pending > 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#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 10:13:10PM +0200, Sven Luther wrote: > On Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: > > looking at DFB's supported-hardware page > > > > http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics > > Well, ... > > I did some try with my xgi card, and even though i disabled hardware > acceleration, this is a nogo. I ended up in a messed up text terminal (with > black blocks and â chars for the box borders and shadow). > > So, it is clear that directfb needs not only the per-card drivers for > acceleration, but also for normal usage. > > That said, i couldn't find any kind of directfb log or something, so maybe the > above guess was bad, and something else funny happened, since that was with a > 2.6.18 kernel. DirectFB only supports : FB_ACCEL_SIS_GLAMOUR_2 FB_ACCEL_SIS_XABRE While my card is : FB_ACCEL_XGI_VOLARI_V But that is only for accel. I didn't find where the pci ids are checked, but maybe this is related to the sis->xgi vendor id change. Friendly, Sven Luther
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On 23/09/06, Attilio Fiandrotti <[EMAIL PROTECTED]> wrote: > Also, about the console font corruption with radeonfb, i would be interested > in feedback of if it is a powerpc only issue, or ppc stuff ? No idea, i on no radeon boards :( $ lspci | grep ATI :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] >>Any chanche to test if disabling HW acceleration also makes the g-i >>usable on machines equippped with ATI or NVIDIA graphic boards ( where >>atyfb and nvidiafb modules would be used in the case HW acceleration was >>not forced off ) ? > > > Nope, but as soon as the fixed rootskel-gtk is uploaded, we can issue a call > for testers on debian-powerpc, using the daily builds. A round of PPC tests would be useful, especially it happens to find owners of ATI or NVIDIA boards. Got one. -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein -- 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 Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: > looking at DFB's supported-hardware page > > http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics Well, ... I did some try with my xgi card, and even though i disabled hardware acceleration, this is a nogo. I ended up in a messed up text terminal (with black blocks and â chars for the box borders and shadow). So, it is clear that directfb needs not only the per-card drivers for acceleration, but also for normal usage. That said, i couldn't find any kind of directfb log or something, so maybe the above guess was bad, and something else funny happened, since that was with a 2.6.18 kernel. Friendly, Sven Luther
Bug#389088: Segfault when taking a screenshot after disk partitioning
Package: cdebconf-gtk-udeb I just tried todays Etch beta netinstall install CD with the graphical install (installgui). When the partitioning step is done and the computer starts to actually do something in the background (probably writing the partition table or mkfs) it seems to be unwise to click on the "Screenshot" button. I got thrown to the text console and saw a segfault. Then the partitioning manager was started again and at least I could start from scratch. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
Loïc Minier wrote: On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: I never filed a bug into GNOME's bugzilla because no one ever was able to reproduce this bug, but if someone can manage to achieve this (Loic? :) we could file a proper bugreport to have ot fixed in next GTK release. I would be happy to be a test puppet, but one of the reason I requested testing of Gtk 2.10 + DirectFB was that I don't know how to test it. I know it sounds a bit irresponsible, so I did my best to verify that I didn't break anything incrementally (but I still missed some stuff). I don't want you to lose too much time explaining me with details how your test environment is built, but if you could give some high level hints on the process you follow to test, what you test, and how you debug, that would be really nice. If such a documentation already exist, that would be nice! The most effective way for me would be to be able to test binaries from my laptop, perhaps from a different VT. I understand I might need to boot some d-i builds via the network or a CD in some cases. I also have a Xen setup, it it can help in any tests, and even a VMWare Workstation license (didn't update the kernel modules to 2.6.17 though). Thanks in advance for your help! Please don't feel obliged to document this in great length, I don't want to waste *your* time. First, the bad news: GTK 2.10.4 has a broken DFB backend, as an old bugfix [1] by Mike Emmel icluded in CVS was not relesed, so to get a working GTKDFB library you'll have to use sources form CVS HEAD. In addition to this, the bug i posted about in July still affects GTK CVS HEAD, so i think this is enough to try re-backporting from scratch the HEAD GDKDFB to 2.8.20 (current DFB backend in debian unstable is dated around May 2006). Your help in testing and debugging GTKDFB would be really useful and appreciated: what i usually do to is compiling GTKDFB with debugging symbols, and then running a GTK application like gtk-demo or the GIMP within gdb. I have no special methods to test the d-i but runing it into a chroot cage and attaching gdb at it. I know davide viti used to attach gdb to the debconf process running in qemu, but i've never done this by myself. cheers Attilio [1] http://cvs.gnome.org/viewcvs/gtk%2B/gtk/Makefile.am?r1=1.315&r2=1.316 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389079: partman-md: 2.6.18 kernel renamed raid5 module to raid456.
Package: partman-md Severity: normal FYI, so partman-md doesn't break once 2.6.18 is uploaded to unstable and migrated to testing, especially important since 2.6.18 is the etch target release kernel. Friendly, Sven Luther -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389074: kernel-wedge: 2.6.18 kernel has raid456 instead of raid5 module.
Package: kernel-wedge Version: 1.20 Severity: normal As subject says, please find attached patch. Friendly, Sven Luther -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Index: linux-kernel-di-powerpc-2.6/kernel-versions === --- linux-kernel-di-powerpc-2.6/kernel-versions (revision 40861) +++ linux-kernel-di-powerpc-2.6/kernel-versions (working copy) @@ -1,4 +1,5 @@ # arch version flavour installedname suffix build-depends -powerpc 2.6.17-2 powerpc 2.6.17-2-powerpc- linux-image-2.6.17-2-powerpc -powerpc 2.6.17-2 powerpc642.6.17-2-powerpc64 - linux-image-2.6.17-2-powerpc64 -powerpc 2.6.17-2 powerpc-miboot 2.6.17-2-powerpc-miboot - linux-image-2.6.17-2-powerpc-miboot +powerpc 2.6.18-1 powerpc 2.6.18-1-powerpc- linux-image-2.6.18-1-powerpc +#powerpc 2.6.18-1 powerpc64 2.6.18-1-powerpc64 - linux-image-2.6.18-1-powerpc64 +#powerpc 2.6.18-1 powerpc-miboot 2.6.18-1-powerpc-miboot - linux-image-2.6.18-1-powerpc-miboot +#powerpc 2.6.18-1 prep2.6.18-1-prep - linux-image-2.6.18-1-prep Index: kernel-wedge/debian/changelog === --- kernel-wedge/debian/changelog (revision 40836) +++ kernel-wedge/debian/changelog (working copy) @@ -1,9 +1,14 @@ kernel-wedge (2.27) UNRELEASED; urgency=low + [ Joey Hess ] * Fix exclusion of optional modules to work. - -- Joey Hess <[EMAIL PROTECTED]> Sun, 20 Aug 2006 01:04:32 -0400 + [ Sven Luther ] + * Optionalized raid5 and added optional raid456, since 2.6.18 kernels +renamed the raid module (and added support for raid4 and raid6). + -- Sven Luther <[EMAIL PROTECTED]> Sat, 23 Sep 2006 19:51:54 +0200 + kernel-wedge (2.26) unstable; urgency=low * mark scsi modules optional that aren't available for ia64: Index: kernel-wedge/modules/md-modules === --- kernel-wedge/modules/md-modules (revision 40836) +++ kernel-wedge/modules/md-modules (working copy) @@ -7,7 +7,8 @@ multipath raid0 raid1 -raid5 +raid5 ? +raid456 ? xor dm-mirror ? dm-snapshot ?
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Frans Pop wrote: On Saturday 23 September 2006 12:45, Attilio Fiandrotti wrote: Speaking generically, i don't know how much is safe having DFB running in accelerated mode using fb module "X" on architecture "Y". An extensive set of tests to detect bad X,Y couples looks dificlut to be performed, so to be sure the end-user never runs in a bad X,Y situation, a safe choice would be disabling hw acceleration by defalut, for all architectures. On the other hand, that does not really help directfb development... But I've now changed rootskel-gtk so that no-hardware is set by default but hardware acceleration can be enabled with directfb/hw-accel=true. IMHO i still think this was a wise move, since it solves a wide range of potential problems and the boot time option you introduced still allows people who want to debug DFB's hw acceleration to do it. The d-i ISO itself could become a useful tool for directfb developers to test DFB's HW accelerated functionalities on a wide range of different HW configurations. 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
On Sat, Sep 23, 2006 at 05:09:15PM +0200, Frans Pop wrote: > On Saturday 23 September 2006 16:17, Sven Luther wrote: > > Is there some place where we can do some kind of framebuffer device > > detection, and loading of the appropriate modules ? Where is it done > > for vesafb, which if i am not wrong, is modular on x86 ? > > That should also be an issue for the newt frontend then... Indeed. Also, given the way initramfs is initialized very early, i have had some thoughts of moving all the builtin framebuffer devices into the initramfs, and then have some kind of kernel fbdev hook or something which will load it. Need to find time to investigate this. > See: > rootskel/src/lib/debian-installer-startup.d/S40framebuffer-module-linux-* Cool, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Saturday 23 September 2006 19:22, Loïc Minier wrote: > What would be the best way to have debug symbols? libgtk2.0-0-dbg has > the debug symbols of both flavors of Gtk, for example it has: > /usr/lib/debug/usr/lib/libgdk-directfb-2.0.so.0.1000.3 > /usr/lib/debug/usr/lib/libgtk-directfb-2.0.so.0.1000.3 > > Some objects are built with both flavors, I'm not sure whether the > debug symbols are for both or only one particular flavor. > > Perhaps you simply want a build with DEB_BUILD_OPTIONS="nostrip noopt" > of the udeb? I don't think we want a "debug udeb" in the archive. If someone needs debugging symbols, he can (I suppose) quite easily do a local build with debugging enabled and use that when bulding d-i images. Thanks for the offer though. pgpkDx3nM99yS.pgp Description: PGP signature
Re: [D-I] mass kernel udeb update and preparations for RC1
On Fri September 22 2006 05:31, Frans Pop wrote: > /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. I'll give this post a cool and a thanks! :) I can't add much to it but I do like to see etch (and the kernel) moving along to the stable release. I say thanks to everyone who has had a hand in making this happen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: > if we could build a 2.10.x ISO with debugging symbols for GTK+, and > processes run within vmware could be debugged remotlely using gdb (like > qemu allows to do), this could be a a good proof for the bug. > Meanwhile, let's see if can reproduced with GTKX 2.10.4. What would be the best way to have debug symbols? libgtk2.0-0-dbg has the debug symbols of both flavors of Gtk, for example it has: /usr/lib/debug/usr/lib/libgdk-directfb-2.0.so.0.1000.3 /usr/lib/debug/usr/lib/libgtk-directfb-2.0.so.0.1000.3 Some objects are built with both flavors, I'm not sure whether the debug symbols are for both or only one particular flavor. Perhaps you simply want a build with DEB_BUILD_OPTIONS="nostrip noopt" of the udeb? -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Sat, Sep 23, 2006, Attilio Fiandrotti wrote: > I never filed a bug into GNOME's bugzilla because no one ever was able > to reproduce this bug, but if someone can manage to achieve this (Loic? > :) we could file a proper bugreport to have ot fixed in next GTK release. I would be happy to be a test puppet, but one of the reason I requested testing of Gtk 2.10 + DirectFB was that I don't know how to test it. I know it sounds a bit irresponsible, so I did my best to verify that I didn't break anything incrementally (but I still missed some stuff). I don't want you to lose too much time explaining me with details how your test environment is built, but if you could give some high level hints on the process you follow to test, what you test, and how you debug, that would be really nice. If such a documentation already exist, that would be nice! The most effective way for me would be to be able to test binaries from my laptop, perhaps from a different VT. I understand I might need to boot some d-i builds via the network or a CD in some cases. I also have a Xen setup, it it can help in any tests, and even a VMWare Workstation license (didn't update the kernel modules to 2.6.17 though). Thanks in advance for your help! Please don't feel obliged to document this in great length, I don't want to waste *your* time. -- Loïc Minier <[EMAIL PROTECTED]> -- 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
I like knowing what is going on thanks for the updates ;-)There is an old UNIX addage. "No news is good news."But then again there are some of us that like hearing about the good stuff. On 9/22/06, Frans Pop <[EMAIL PROTECTED]> 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 mailThe 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
Processing of oldsys-preseed_0.4_i386.changes
oldsys-preseed_0.4_i386.changes uploaded successfully to localhost along with the files: oldsys-preseed_0.4.dsc oldsys-preseed_0.4.tar.gz oldsys-preseed_0.4_i386.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[D-I] Switching initrd filesystem (was: mass kernel udeb update and preparations for RC1)
On Friday 22 September 2006 16:39, Grant Grundler wrote: > I didn't see anything for parisc (HPPA). > I don't know of any problems with initramfs on parisc. > but I don't expect any surprises from the kernel on that. Maybe I was not clear enough on this. The original text was: * 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. The default is: config/common:59:INITRD_FS = ext2 $ wcgrep INITRD_FS config/hppa This means that all hppa d-i initrds currently use the default ext2 filesystem. The question was: should hppa be switched to using initramfs instead of ext2 for Debian Installer images? Whether this is possible depends amongst others on what the bootloaders used for different installation methods support. Note that using intramfs has some advantages as can be seen from these changelog entries from Joey for i386/amd64: * Remove root=/dev/ram from syslinux configs, turns out not to be needed for the kernel to find initramfs. * Remove ramdisk_size= and "rw" settings, also not needed. The same goes for other architectures: alpha: uses default ext2 arm/armeb: most subarches use cramfs ia64: uses cramfs m68k: uses default ext2 mips: uses cramfs mipsel: uses cramfs (except bcm947xx/netboot/firmware.cfg: jffs2) sparc: uses default ext2 i386, amd64, powerpc and s/390 already use initramfs as default. pgp8gj99lRa3m.pgp Description: PGP signature
rootskel-gtk_0.11_i386.changes ACCEPTED
Accepted: rootskel-gtk_0.11.dsc to pool/main/r/rootskel-gtk/rootskel-gtk_0.11.dsc rootskel-gtk_0.11.tar.gz to pool/main/r/rootskel-gtk/rootskel-gtk_0.11.tar.gz rootskel-gtk_0.11_i386.udeb to pool/main/r/rootskel-gtk/rootskel-gtk_0.11_i386.udeb Override entries for your package: rootskel-gtk_0.11.dsc - source debian-installer rootskel-gtk_0.11_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]
linux-kernel-di-i386-2.6_1.37_i386.changes ACCEPTED
Accepted: acpi-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/acpi-modules-2.6.17-2-486-di_1.37_i386.udeb cdrom-core-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/cdrom-core-modules-2.6.17-2-486-di_1.37_i386.udeb cdrom-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/cdrom-modules-2.6.17-2-486-di_1.37_i386.udeb crc-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/crc-modules-2.6.17-2-486-di_1.37_i386.udeb crypto-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/crypto-modules-2.6.17-2-486-di_1.37_i386.udeb ext3-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ext3-modules-2.6.17-2-486-di_1.37_i386.udeb fat-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/fat-modules-2.6.17-2-486-di_1.37_i386.udeb fb-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/fb-modules-2.6.17-2-486-di_1.37_i386.udeb firewire-core-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/firewire-core-modules-2.6.17-2-486-di_1.37_i386.udeb firmware-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/firmware-modules-2.6.17-2-486-di_1.37_i386.udeb floppy-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/floppy-modules-2.6.17-2-486-di_1.37_i386.udeb ide-core-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ide-core-modules-2.6.17-2-486-di_1.37_i386.udeb ide-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ide-modules-2.6.17-2-486-di_1.37_i386.udeb input-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/input-modules-2.6.17-2-486-di_1.37_i386.udeb ipv6-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ipv6-modules-2.6.17-2-486-di_1.37_i386.udeb irda-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/irda-modules-2.6.17-2-486-di_1.37_i386.udeb jfs-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/jfs-modules-2.6.17-2-486-di_1.37_i386.udeb kernel-image-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/kernel-image-2.6.17-2-486-di_1.37_i386.udeb linux-kernel-di-i386-2.6_1.37.dsc to pool/main/l/linux-kernel-di-i386-2.6/linux-kernel-di-i386-2.6_1.37.dsc linux-kernel-di-i386-2.6_1.37.tar.gz to pool/main/l/linux-kernel-di-i386-2.6/linux-kernel-di-i386-2.6_1.37.tar.gz loop-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/loop-modules-2.6.17-2-486-di_1.37_i386.udeb md-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/md-modules-2.6.17-2-486-di_1.37_i386.udeb mouse-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/mouse-modules-2.6.17-2-486-di_1.37_i386.udeb nic-extra-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-extra-modules-2.6.17-2-486-di_1.37_i386.udeb nic-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-modules-2.6.17-2-486-di_1.37_i386.udeb nic-pcmcia-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-pcmcia-modules-2.6.17-2-486-di_1.37_i386.udeb nic-shared-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-shared-modules-2.6.17-2-486-di_1.37_i386.udeb nic-usb-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-usb-modules-2.6.17-2-486-di_1.37_i386.udeb ntfs-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ntfs-modules-2.6.17-2-486-di_1.37_i386.udeb parport-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/parport-modules-2.6.17-2-486-di_1.37_i386.udeb pcmcia-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/pcmcia-modules-2.6.17-2-486-di_1.37_i386.udeb pcmcia-storage-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/pcmcia-storage-modules-2.6.17-2-486-di_1.37_i386.udeb plip-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/plip-modules-2.6.17-2-486-di_1.37_i386.udeb ppp-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ppp-modules-2.6.17-2-486-di_1.37_i386.udeb qnx4-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/qnx4-modules-2.6.17-2-486-di_1.37_i386.udeb reiserfs-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/reiserfs-modules-2.6.17-2-486-di_1.37_i386.udeb sata-modules-2.6.17-2-486-di_1.37_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/sata-modules-2.6.17-2-486-di_1.37_i386.udeb scsi-common-modules-2.6.17-2-486-di_1.37_i386.udeb to po
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.) [ offlist ] > /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), Thanks! :) I don't respond to every mail just because it feels like noise to get back a ton a short emails. But I do appreciate the effort you've put into it and am very impressed that mass uploads are even possible. > but the second part has some issues that need attention. I didn't see anything for parisc (HPPA). I don't know of any problems with initramfs on parisc. but I don't expect any surprises from the kernel on that. > Have D-I porters actually read the mail? Yes - I did. > Is it useful that I send such mails at all? Yes. kudos and thanks! grant -- 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 Saturday 23 September 2006 12:45, Attilio Fiandrotti wrote: > Speaking generically, i don't know how much is safe having DFB running > in accelerated mode using fb module "X" on architecture "Y". > An extensive set of tests to detect bad X,Y couples looks dificlut to > be performed, so to be sure the end-user never runs in a bad X,Y > situation, a safe choice would be disabling hw acceleration by defalut, > for all architectures. On the other hand, that does not really help directfb development... But I've now changed rootskel-gtk so that no-hardware is set by default but hardware acceleration can be enabled with directfb/hw-accel=true. pgpgjZeZZf7py.pgp Description: PGP signature
linux-kernel-di-amd64-2.6_1.14_amd64.changes ACCEPTED
Accepted: acpi-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/acpi-modules-2.6.17-2-amd64-di_1.14_amd64.udeb cdrom-core-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/cdrom-core-modules-2.6.17-2-amd64-di_1.14_amd64.udeb crc-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/crc-modules-2.6.17-2-amd64-di_1.14_amd64.udeb crypto-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/crypto-modules-2.6.17-2-amd64-di_1.14_amd64.udeb ext3-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ext3-modules-2.6.17-2-amd64-di_1.14_amd64.udeb fat-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/fat-modules-2.6.17-2-amd64-di_1.14_amd64.udeb fb-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/fb-modules-2.6.17-2-amd64-di_1.14_amd64.udeb firewire-core-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/firewire-core-modules-2.6.17-2-amd64-di_1.14_amd64.udeb firmware-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/firmware-modules-2.6.17-2-amd64-di_1.14_amd64.udeb floppy-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/floppy-modules-2.6.17-2-amd64-di_1.14_amd64.udeb ide-core-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ide-core-modules-2.6.17-2-amd64-di_1.14_amd64.udeb ide-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ide-modules-2.6.17-2-amd64-di_1.14_amd64.udeb input-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/input-modules-2.6.17-2-amd64-di_1.14_amd64.udeb ipv6-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ipv6-modules-2.6.17-2-amd64-di_1.14_amd64.udeb irda-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/irda-modules-2.6.17-2-amd64-di_1.14_amd64.udeb jfs-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/jfs-modules-2.6.17-2-amd64-di_1.14_amd64.udeb kernel-image-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/kernel-image-2.6.17-2-amd64-di_1.14_amd64.udeb linux-kernel-di-amd64-2.6_1.14.dsc to pool/main/l/linux-kernel-di-amd64-2.6/linux-kernel-di-amd64-2.6_1.14.dsc linux-kernel-di-amd64-2.6_1.14.tar.gz to pool/main/l/linux-kernel-di-amd64-2.6/linux-kernel-di-amd64-2.6_1.14.tar.gz loop-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/loop-modules-2.6.17-2-amd64-di_1.14_amd64.udeb md-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/md-modules-2.6.17-2-amd64-di_1.14_amd64.udeb mouse-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/mouse-modules-2.6.17-2-amd64-di_1.14_amd64.udeb nic-extra-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/nic-extra-modules-2.6.17-2-amd64-di_1.14_amd64.udeb nic-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/nic-modules-2.6.17-2-amd64-di_1.14_amd64.udeb nic-pcmcia-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/nic-pcmcia-modules-2.6.17-2-amd64-di_1.14_amd64.udeb nic-shared-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/nic-shared-modules-2.6.17-2-amd64-di_1.14_amd64.udeb nic-usb-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/nic-usb-modules-2.6.17-2-amd64-di_1.14_amd64.udeb ntfs-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ntfs-modules-2.6.17-2-amd64-di_1.14_amd64.udeb parport-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/parport-modules-2.6.17-2-amd64-di_1.14_amd64.udeb pcmcia-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/pcmcia-modules-2.6.17-2-amd64-di_1.14_amd64.udeb pcmcia-storage-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/pcmcia-storage-modules-2.6.17-2-amd64-di_1.14_amd64.udeb plip-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/plip-modules-2.6.17-2-amd64-di_1.14_amd64.udeb ppp-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ppp-modules-2.6.17-2-amd64-di_1.14_amd64.udeb qnx4-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/qnx4-modules-2.6.17-2-amd64-di_1.14_amd64.udeb reiserfs-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/reiserfs-modules-2.6.17-2-amd64-di_1.14_amd64.udeb sata-modules-2.6.17-2-amd64-di_1.14_amd64.udeb to pool/main/l/linux-kernel-di-amd64
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Saturday 23 September 2006 16:17, Sven Luther wrote: > Is there some place where we can do some kind of framebuffer device > detection, and loading of the appropriate modules ? Where is it done > for vesafb, which if i am not wrong, is modular on x86 ? That should also be an issue for the newt frontend then... See: rootskel/src/lib/debian-installer-startup.d/S40framebuffer-module-linux-* pgpC5uuoo6R5M.pgp Description: PGP signature
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Mmm, nogo on the xgi card, since 2.6.16/17 have the sisfb framebuffer device not builtin, but modular. Is there some place where we can do some kind of framebuffer device detection, and loading of the appropriate modules ? Where is it done for vesafb, which if i am not wrong, is modular on x86 ? 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: > > * 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. :) > > * powerpc: oldworld boot problems with recent kernels benh made a patch that still needs confirmation, patch is included in latest 2.6.18 regards -- maks -- 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 Sat, Sep 23, 2006 at 01:56:40PM +0200, Attilio Fiandrotti wrote: > Sven Luther wrote: > > > > Yes, i saw the vanished lines in your screenshots and i belive this may > be #385026, which is GTKDFB 2.8.x related and affects all HW platforms. > As Frans said, this is a quite annoying bug and i'll try to see if i > can fix it in GTKDFB 2.8.20 with a small patch (but i'm not sure it's > going to be an easy fix). > >>> > >>> > >>>Is it fixed in 2.10.x ? > >> > >>Basing on my past tests with different GTK+ 2.10 versions, it is. > > > > > >This would be a reason to go with gtk 2.10.x, those packages are built and > >uploaded to experimental, right ? So we could do a second build using the > >2.10 > >stuff ? > > Yes, GDKDFB backend found in 2.10.4 is more stable and clean than one > found in 2.8.20, which is an old backported DFB backend some months old. > If we can fix this issue[1] before GTK 2.10.5 is out, we may prefer > switching to GTK 2.10.5 later, otherwise we may need to backport current > GDKDFB backend from 2.10.4 to 2.8.20 for immediate use. > 2.10.x, compared to 2.8.x, offers nothing we really need, but of course > avoiding dirty backports wouldn't be bad! > > [1] http://lists.debian.org/debian-boot/2006/09/msg00995.html That would be the BOOM issue, right, in my experience, from my X hacking days, is that stuff like this happens when the refresh is no more happening, and when one is using a software cursor, which is still working or something. Friendly, Sven Luther -- 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 Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: > looking at DFB's supported-hardware page > > http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics > > i can see some of those fb modules may allow DFB to run in hw > accelerated mode, but for many of them no functionality tests on PPC > hardware were ever peformed, so i guess disabling HW acceleration tout > court for PPC was indeed the right choice for safeness. > Speaking generically, i don't know how much is safe having DFB running > in accelerated mode using fb module "X" on architecture "Y". > An extensive set of tests to detect bad X,Y couples looks dificlut to be > performed, so to be sure the end-user never runs in a bad X,Y situation, > a safe choice would be disabling hw acceleration by defalut, for all > architectures. Understood. > Sven, looking at the PNG you posted it looks like the trashed banner > colours issue we experienced at extremadura is gone, does also the > cursor is displayed correctly (to grab both screen and pointer at DFB's > level, you can press the "PrtSc" key in the case your PPC has one) ? > >>> > >>> > >>>The pegasos uses a normal PC keyboard, so i should have this key, but in > >>>any > >>>case, indeed both these issues are gone, and the two new ones i > >>>mentioned are > >>>there (the list selection dissapearance thingy). Do you see that on x86 > >>>also ? > >> > >>Yes, i saw the vanished lines in your screenshots and i belive this may > >>be #385026, which is GTKDFB 2.8.x related and affects all HW platforms. > >>As Frans said, this is a quite annoying bug and i'll try to see if i can > >>fix it in GTKDFB 2.8.20 with a small patch (but i'm not sure it's going > >>to be an easy fix). > > > > > >Is it fixed in 2.10.x ? > > Basing on my past tests with different GTK+ 2.10 versions, it is. This would be a reason to go with gtk 2.10.x, those packages are built and uploaded to experimental, right ? So we could do a second build using the 2.10 stuff ? > >Not sure if we ever had a success with g-i on oldworld, so it is less > >important, and my prep box has a sis and a matrox, but g-i is too big to > >boot > >on it. I do have a spare matox millenium i could plug in the pegasos, and > >just > >got a xgi volari v3xt. Will test with them. nvidia is evil and should be > >boycotted anyway :) > > On my PReP 7043/140 box i experienced success in running unaccelerated > DFB applications with a Matrox card some times ago, but i never managed > to test GTKDFB applications. The problem on PReP is getting it to load the huge g-i initrd, not really running apps afterward, altough this would indicate there is a serious problem with matroxfb maybe. Friendly, Sven Luther -- 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: Yes, i saw the vanished lines in your screenshots and i belive this may be #385026, which is GTKDFB 2.8.x related and affects all HW platforms. As Frans said, this is a quite annoying bug and i'll try to see if i can fix it in GTKDFB 2.8.20 with a small patch (but i'm not sure it's going to be an easy fix). Is it fixed in 2.10.x ? Basing on my past tests with different GTK+ 2.10 versions, it is. This would be a reason to go with gtk 2.10.x, those packages are built and uploaded to experimental, right ? So we could do a second build using the 2.10 stuff ? Yes, GDKDFB backend found in 2.10.4 is more stable and clean than one found in 2.8.20, which is an old backported DFB backend some months old. If we can fix this issue[1] before GTK 2.10.5 is out, we may prefer switching to GTK 2.10.5 later, otherwise we may need to backport current GDKDFB backend from 2.10.4 to 2.8.20 for immediate use. 2.10.x, compared to 2.8.x, offers nothing we really need, but of course avoiding dirty backports wouldn't be bad! [1] http://lists.debian.org/debian-boot/2006/09/msg00995.html cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
Frans Pop wrote: On Saturday 23 September 2006 12:54, Attilio Fiandrotti wrote: I never filed a bug into GNOME's bugzilla because no one ever was able to reproduce this bug, but if someone can manage to achieve this (Loic? Well, I see it completely reliably with the image I built for 2.10 in vmware. Possibly the fact that it is vmware also makes it reproducible for others. if we could build a 2.10.x ISO with debugging symbols for GTK+, and processes run within vmware could be debugged remotlely using gdb (like qemu allows to do), this could be a a good proof for the bug. Meanwhile, let's see if can reproduced with GTKX 2.10.4. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-auto-crypto_1_i386.changes is NEW
(new) partman-auto-crypto_1.dsc standard debian-installer (new) partman-auto-crypto_1.tar.gz standard debian-installer (new) partman-auto-crypto_1_all.udeb standard debian-installer Automatically partition storage devices using crypto and LVM Changes: partman-auto-crypto (1) unstable; urgency=low . [ David Härdeman ] * Initial version Override entries for your package: Announcing to debian-devel-changes@lists.debian.org Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. -- 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: That's a good idea. I also wonder if kernels shipped in d-i include or not modules for hardware specific framebuffer devices, or generic drivers (like vesafb on i386) only. CONFIG_FB_CIRRUS=m CONFIG_FB_OF=y CONFIG_FB_CONTROL=y CONFIG_FB_PLATINUM=y CONFIG_FB_VALKYRIE=y CONFIG_FB_CT65550=y CONFIG_FB_IMSTT=y CONFIG_FB_S1D13XXX=m CONFIG_FB_NVIDIA=y CONFIG_FB_MATROX=y CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y CONFIG_FB_RADEON=y CONFIG_FB_ATY128=y CONFIG_FB_ATY=y CONFIG_FB_SAVAGE=m CONFIG_FB_SIS=y CONFIG_FB_SIS_300=y CONFIG_FB_SIS_315=y CONFIG_FB_NEOMAGIC=m CONFIG_FB_KYRO=m CONFIG_FB_3DFX=y CONFIG_FB_TRIDENT=m So, on powerpc, we have : offb, controlfb, platinumfb, valkyriefb, imsttfb, nvidiafb, matroxfb, radeonfb, aty128fb, atyfb, sisfb and 3dfxfb builtin. cirrusfb, s1d13xxxfb (no idea what this one is), savagefb, neomagixfb, kyrofb and tridentfb as modules. looking at DFB's supported-hardware page http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics i can see some of those fb modules may allow DFB to run in hw accelerated mode, but for many of them no functionality tests on PPC hardware were ever peformed, so i guess disabling HW acceleration tout court for PPC was indeed the right choice for safeness. Speaking generically, i don't know how much is safe having DFB running in accelerated mode using fb module "X" on architecture "Y". An extensive set of tests to detect bad X,Y couples looks dificlut to be performed, so to be sure the end-user never runs in a bad X,Y situation, a safe choice would be disabling hw acceleration by defalut, for all architectures. Sven, looking at the PNG you posted it looks like the trashed banner colours issue we experienced at extremadura is gone, does also the cursor is displayed correctly (to grab both screen and pointer at DFB's level, you can press the "PrtSc" key in the case your PPC has one) ? The pegasos uses a normal PC keyboard, so i should have this key, but in any case, indeed both these issues are gone, and the two new ones i mentioned are there (the list selection dissapearance thingy). Do you see that on x86 also ? Yes, i saw the vanished lines in your screenshots and i belive this may be #385026, which is GTKDFB 2.8.x related and affects all HW platforms. As Frans said, this is a quite annoying bug and i'll try to see if i can fix it in GTKDFB 2.8.20 with a small patch (but i'm not sure it's going to be an easy fix). Is it fixed in 2.10.x ? Basing on my past tests with different GTK+ 2.10 versions, it is. Also, about the console font corruption with radeonfb, i would be interested in feedback of if it is a powerpc only issue, or ppc stuff ? No idea, i on no radeon boards :( Someone else ? Any chanche to test if disabling HW acceleration also makes the g-i usable on machines equippped with ATI or NVIDIA graphic boards ( where atyfb and nvidiafb modules would be used in the case HW acceleration was not forced off ) ? Nope, but as soon as the fixed rootskel-gtk is uploaded, we can issue a call for testers on debian-powerpc, using the daily builds. A round of PPC tests would be useful, especially it happens to find owners of ATI or NVIDIA boards. ati being mach64 (rage) and aty (rage 128) here. Not sure if we ever had a success with g-i on oldworld, so it is less important, and my prep box has a sis and a matrox, but g-i is too big to boot on it. I do have a spare matox millenium i could plug in the pegasos, and just got a xgi volari v3xt. Will test with them. nvidia is evil and should be boycotted anyway :) On my PReP 7043/140 box i experienced success in running unaccelerated DFB applications with a Matrox card some times ago, but i never managed to test GTKDFB applications. cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gtk 2.10 availability
On Saturday 23 September 2006 12:54, Attilio Fiandrotti wrote: > I never filed a bug into GNOME's bugzilla because no one ever was able > to reproduce this bug, but if someone can manage to achieve this (Loic? Well, I see it completely reliably with the image I built for 2.10 in vmware. Possibly the fact that it is vmware also makes it reproducible for others. pgpe1PRpyxhhL.pgp Description: PGP signature
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. 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. Hey, now i remember i ran into a similar issue [1] some times ago. I wasn't able to fix it, but i eventually concluded it was due to a memory corruption issue that affects GTK (or GLib or something else), no matter what GDK backend was used, and not the DFB backend (see gdb traces in the below thread). Such a bug causes crashes with the DFB backend and on some test machines only, but never causes crashes with the X backend, even if memory corruption could be detected with gdb. I never filed a bug into GNOME's bugzilla because no one ever was able to reproduce this bug, but if someone can manage to achieve this (Loic? :) we could file a proper bugreport to have ot fixed in next GTK release. Attilio [1] http://mail.gnome.org/archives/gtk-devel-list/2006-July/msg00157.html -- 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: I belive disabling hw acceleration on PPC machines is a good choice, as we're interested in stability, not performance, and i also belive performance drop won't be even detectable in the case of a simple DFB application like our GTK frontend. By the way, i think disabling HW acceleration unconditionally for *every architecture* wouldn't be a bad idea, this could save us many a headache in the future. I would enable a 'secret' debconf switch to enable hw accel, be it only for testing. That's a good idea. I also wonder if kernels shipped in d-i include or not modules for hardware specific framebuffer devices, or generic drivers (like vesafb on i386) only. Sven, looking at the PNG you posted it looks like the trashed banner colours issue we experienced at extremadura is gone, does also the cursor is displayed correctly (to grab both screen and pointer at DFB's level, you can press the "PrtSc" key in the case your PPC has one) ? The pegasos uses a normal PC keyboard, so i should have this key, but in any case, indeed both these issues are gone, and the two new ones i mentioned are there (the list selection dissapearance thingy). Do you see that on x86 also ? Yes, i saw the vanished lines in your screenshots and i belive this may be #385026, which is GTKDFB 2.8.x related and affects all HW platforms. As Frans said, this is a quite annoying bug and i'll try to see if i can fix it in GTKDFB 2.8.20 with a small patch (but i'm not sure it's going to be an easy fix). Also, about the console font corruption with radeonfb, i would be interested in feedback of if it is a powerpc only issue, or ppc stuff ? No idea, i on no radeon boards :( Any chanche to test if disabling HW acceleration also makes the g-i usable on machines equippped with ATI or NVIDIA graphic boards ( where atyfb and nvidiafb modules would be used in the case HW acceleration was not forced off ) ? Nope, but as soon as the fixed rootskel-gtk is uploaded, we can issue a call for testers on debian-powerpc, using the daily builds. A round of PPC tests would be useful, especially it happens to find owners of ATI or NVIDIA boards. 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
On Sat, Sep 23, 2006 at 12:07:45PM +0200, Attilio Fiandrotti wrote: > Sven Luther wrote: > > > > >>I belive disabling hw acceleration on PPC machines is a good choice, as > >>we're interested in stability, not performance, and i also belive > >>performance drop won't be even detectable in the case of a simple DFB > >>application like our GTK frontend. > >>By the way, i think disabling HW acceleration unconditionally for *every > >>architecture* wouldn't be a bad idea, this could save us many a headache > >>in the future. > > > > > >I would enable a 'secret' debconf switch to enable hw accel, be it only for > >testing. > > That's a good idea. > I also wonder if kernels shipped in d-i include or not modules for > hardware specific framebuffer devices, or generic drivers (like vesafb > on i386) only. CONFIG_FB_CIRRUS=m CONFIG_FB_OF=y CONFIG_FB_CONTROL=y CONFIG_FB_PLATINUM=y CONFIG_FB_VALKYRIE=y CONFIG_FB_CT65550=y CONFIG_FB_IMSTT=y CONFIG_FB_S1D13XXX=m CONFIG_FB_NVIDIA=y CONFIG_FB_MATROX=y CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y CONFIG_FB_RADEON=y CONFIG_FB_ATY128=y CONFIG_FB_ATY=y CONFIG_FB_SAVAGE=m CONFIG_FB_SIS=y CONFIG_FB_SIS_300=y CONFIG_FB_SIS_315=y CONFIG_FB_NEOMAGIC=m CONFIG_FB_KYRO=m CONFIG_FB_3DFX=y CONFIG_FB_TRIDENT=m So, on powerpc, we have : offb, controlfb, platinumfb, valkyriefb, imsttfb, nvidiafb, matroxfb, radeonfb, aty128fb, atyfb, sisfb and 3dfxfb builtin. cirrusfb, s1d13xxxfb (no idea what this one is), savagefb, neomagixfb, kyrofb and tridentfb as modules. > >>Sven, looking at the PNG you posted it looks like the trashed banner > >>colours issue we experienced at extremadura is gone, does also the > >>cursor is displayed correctly (to grab both screen and pointer at DFB's > >>level, you can press the "PrtSc" key in the case your PPC has one) ? > > > > > >The pegasos uses a normal PC keyboard, so i should have this key, but in > >any > >case, indeed both these issues are gone, and the two new ones i mentioned > >are > >there (the list selection dissapearance thingy). Do you see that on x86 > >also ? > > Yes, i saw the vanished lines in your screenshots and i belive this may > be #385026, which is GTKDFB 2.8.x related and affects all HW platforms. > As Frans said, this is a quite annoying bug and i'll try to see if i can > fix it in GTKDFB 2.8.20 with a small patch (but i'm not sure it's going > to be an easy fix). Is it fixed in 2.10.x ? > >Also, about the console font corruption with radeonfb, i would be > >interested > >in feedback of if it is a powerpc only issue, or ppc stuff ? > > No idea, i on no radeon boards :( Someone else ? > >>Any chanche to test if disabling HW acceleration also makes the g-i > >>usable on machines equippped with ATI or NVIDIA graphic boards ( where > >>atyfb and nvidiafb modules would be used in the case HW acceleration was > >>not forced off ) ? > > > > > >Nope, but as soon as the fixed rootskel-gtk is uploaded, we can issue a > >call > >for testers on debian-powerpc, using the daily builds. > > A round of PPC tests would be useful, especially it happens to find > owners of ATI or NVIDIA boards. ati being mach64 (rage) and aty (rage 128) here. Not sure if we ever had a success with g-i on oldworld, so it is less important, and my prep box has a sis and a matrox, but g-i is too big to boot on it. I do have a spare matox millenium i could plug in the pegasos, and just got a xgi volari v3xt. Will test with them. nvidia is evil and should be boycotted anyway :) Friendly, Sven Luther > > cheers > > Attilio > --- > 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#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 10:53:56AM +0200, Attilio Fiandrotti wrote: > Sven Luther wrote: > >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, > > I belive disabling hw acceleration on PPC machines is a good choice, as > we're interested in stability, not performance, and i also belive > performance drop won't be even detectable in the case of a simple DFB > application like our GTK frontend. > By the way, i think disabling HW acceleration unconditionally for *every > architecture* wouldn't be a bad idea, this could save us many a headache > in the future. I would enable a 'secret' debconf switch to enable hw accel, be it only for testing. > Sven, looking at the PNG you posted it looks like the trashed banner > colours issue we experienced at extremadura is gone, does also the > cursor is displayed correctly (to grab both screen and pointer at DFB's > level, you can press the "PrtSc" key in the case your PPC has one) ? The pegasos uses a normal PC keyboard, so i should have this key, but in any case, indeed both these issues are gone, and the two new ones i mentioned are there (the list selection dissapearance thingy). Do you see that on x86 also ? Also, about the console font corruption with radeonfb, i would be interested in feedback of if it is a powerpc only issue, or ppc stuff ? > Any chanche to test if disabling HW acceleration also makes the g-i > usable on machines equippped with ATI or NVIDIA graphic boards ( where > atyfb and nvidiafb modules would be used in the case HW acceleration was > not forced off ) ? Nope, but as soon as the fixed rootskel-gtk is uploaded, we can issue a call for testers on debian-powerpc, using the daily builds. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [g-i] patch for the lines problem
Loïc Minier wrote: On Thu, Sep 21, 2006, Attilio Fiandrotti wrote: FYI, Mathias Classen said GTK+ 2.10.4 is going to be presumably released at the end of this week. I'm preparing 2.10.4, and it has some bug fixes, but it doesn't seem to change anything related to DFB. No, nothing the end user will notice, but Mike Emmel did some code cleanup recently to remove long time hacks and now we should have what is going to be the definitive sourcecode base for the DFB backend. 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
Denis Barbier wrote:
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.
ok, i agree not to add unnecesary PNGs to the accessibility GTK theme.
I 've just looked at theme PNGs in Bladr which are referred to by gtkrc
ls -l pixmaps | awk '{system("grep "$8" gtkrc >/dev/null; if [ $? -eq 0
]; then echo "$8" >>used_png; else echo "$8" >>unused_png; fi")}'
and it turned out that below listed PNGs are *not* referred to by gtkrc.
Luca, are those PNGs really used ? in the case are not, can we remove
them from the tarball to save up some space?
cheers
Attilio
[EMAIL PROTECTED]:~/bladr/usr/share/themes/Bladr/gtk-2.0$ cat unused_png
arrow_down1.png
arrow_down2.png
arrow_left1.png
arrow_left2.png
arrow_right1.png
arrow_right2.png
arrow_up1.png
arrow_up2.png
blank.png
button1.png
button2.png
button3.png
button4.png
check1.png
check2.png
default.png
ext1.png
ext2.png
menu_background_4.png
menu-item.png
nautilus_back.png
notebook_top_flat_transparent.png
obutton1.png
obutton2.png
option1.png
option2.png
progressbar_3.png
radio1.png
radio2.png
scroll1.png
scroll2.png
scroll3.png
scroll4.png
SelectedTabTop_backup.png
shadow_out.png
spin1.png
spin2.png
spin3.png
toolbar_background.png
--
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 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, I belive disabling hw acceleration on PPC machines is a good choice, as we're interested in stability, not performance, and i also belive performance drop won't be even detectable in the case of a simple DFB application like our GTK frontend. By the way, i think disabling HW acceleration unconditionally for *every architecture* wouldn't be a bad idea, this could save us many a headache in the future. Sven, looking at the PNG you posted it looks like the trashed banner colours issue we experienced at extremadura is gone, does also the cursor is displayed correctly (to grab both screen and pointer at DFB's level, you can press the "PrtSc" key in the case your PPC has one) ? Any chanche to test if disabling HW acceleration also makes the g-i usable on machines equippped with ATI or NVIDIA graphic boards ( where atyfb and nvidiafb modules would be used in the case HW acceleration was not forced off ) ? thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [g-i] patch for the lines problem
On Thu, Sep 21, 2006, Attilio Fiandrotti wrote: > FYI, Mathias Classen said GTK+ 2.10.4 is going to be presumably released > at the end of this week. I'm preparing 2.10.4, and it has some bug fixes, but it doesn't seem to change anything related to DFB. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381979: keymap not changed in g-i after selection in kbd-chooser
On Thu, Sep 21, 2006, Attilio Fiandrotti wrote: > >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 :) I've noticed this problem when I compared a full DFB build with a standard X11 build, this is why I've started shipping the gdkconfig.h of the directfb build in /usr/lib/gtk-2.0/include/directfb/gdkconfig.h starting with 2.10.1-1. To use it, you should prepend -I/usr/lib/gtk-2.0/include/directfb to your build flags. I have in my TODO to patch the DirectFB pkg-config files to achieve this, but I didn't have the time to do that yet. -- Loïc Minier <[EMAIL PROTECTED]> -- 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 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! I was suggesting to simply run the dfb_input_device_reload_keymap( dfb_input_device_at( DIDID_KEYBOARD ) ); as davide suggested, no matter the GTKDFB version is :) I don't see any real need to split cases GTK >= 2.10.0 and < 2.10.0, as no one runs cdebconf with the GTK frontend on X server, but of course the GTK version check is harmless, so please proceed patching the GTK frontend with the patch (Davide's or yours) you prefer. cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
