Bug#402127: closed by Regis Boudin re...@boudin.name (cdebconf now uses X11)
I totally agree :) Thanks, Attilio Fiandrotti Il 21/11/2011 13:00, Debian Bug Tracking System ha scritto: This is an automatic notification regarding your Bug report which was filed against the cdebconf-gtk-udeb package: #402127: GTK frontend should build on and X target too It has been closed by Regis Boudinre...@boudin.name. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Regis Boudinre...@boudin.name by replying to this email. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eca4d0b.70...@gmail.com
Re: Adding the cdebconf web frontend to alioth SVN repo
Frans Pop wrote: On Sunday 24 February 2008, Attilio Fiandrotti wrote: The stuff i'd like to upload consists in the web frontend itself, which i plan to add to cdebconf/src/modules/frontends/web, and some cgi files which could be added for now to cdebconf/test/web and later moved to a dedicate udeb. Can i proceed ? I don't think there's any real problem with committing the work as long as it is not included in any builds by default. Of course: i just want to make the code available to anyone so that others can start working on it. Please add a README explaining the status of the frontend and a TODO with open issues. For the installer the main issue to be solved IIRC is authentication: how to prevent that just anybody can connect to the installer without any kind of authentication. Luckily, such issue can be addressed outside the frontend itself, in the CGI scripts that sends to client the HTML page and forwards back the HTTP GET/POST requests to the frontend via unix pipes. I hope i'll be able to do the commit this weekend. Cheers, FJP Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding the cdebconf web frontend to alioth SVN repo
Jérémy Bobbio wrote: On Sun, Feb 24, 2008 at 12:59:17PM +0100, Attilio Fiandrotti wrote: Some times ago, i started developing a web frontend for cdebconf [1]: […] During those years many people privately showed interest for the project, so i tought it could be a good idea eventually uploading the sources and related cgi scripts somewhere on alioth, so that if someone is interested, he can resume working on it. With Debian installation on NAS device becoming more common, web based installation would make a nice alternative to SSH based ones! :) For sure it would, and the memory requirements souldn't be excessive either, as the web frontends is just a few KB big piece of code. The only other requirement is a small, CGI capable, http server like thttpd, which needs to be packaged as an udeb, anyway. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding the cdebconf web frontend to alioth SVN repo
Frans Pop wrote: On Wednesday 27 February 2008, Attilio Fiandrotti wrote: The only other requirement is a small, CGI capable, http server like thttpd, which needs to be packaged as an udeb, anyway. Why does it need to be packaged *anyway*? What other use case is there for thttpd inside the installer other than the web interface? Uhm.. how would you provide the HTTP server to the installer, then ? by means of the the same udeb which is supposed to provides the CGI scripts companion to the frontend ? Given a regular deb providing thhtpd already exists, i guess it shouldn't be too complicated building the udeb... Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Adding the cdebconf web frontend to alioth SVN repo
Hi Some times ago, i started developing a web frontend for cdebconf [1]: as it is now, it can basically do all what other frontends do, but i lacked the time/resources to merge everything upstream, so the sourcecode stayed neglected for a year or so on my disk. During those years many people privately showed interest for the project, so i tought it could be a good idea eventually uploading the sources and related cgi scripts somewhere on alioth, so that if someone is interested, he can resume working on it. The stuff i'd like to upload consists in the web frontend itself, which i plan to add to cdebconf/src/modules/frontends/web, and some cgi files which could be added for now to cdebconf/test/web and later moved to a dedicate udeb. Can i proceed ? sincerely Attilio [1] http://wiki.debian.org/DebianInstaller/WebInstaller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409412: Please retest g-i on Intel MacBook using recent daily builds
Lior Kaplan wrote: Attilio Fiandrotti wrote: Hi Testing a daily build [1] in Arabic, i noticed that during udeb downloading the text under the progressbar no longer drifts to the left while the progressbar moves. Lior, could you please verify whether this bug is really gone or still it persists? Both bugs (CCed) still exists in the daily build of gtk-miniiso from 04 Jan 2008. Do the two bugs show up independently from the language used (e.g. both Arabic and Hebrew) or only when a particular language is used? sincerely Attilio FIandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396520: Reordering BRs about the missing libgcc.so.1
retitle 373253 libgcc_s.so.1 on AMD64 and PowerPC should be provided via udeb unmerge 399837 unmerge 396520 close 399837 close 396520 thanks I'm closing bugs 399837 and 396520 because on AMD64 libgcc is currently provided via udeb, hence the referred bug is now fixed. Moreover, both bugs are superseded by 373253, whch also reminds us that libgcc is not provided at all on PowerPC and that a libgcc udeb is still needed. Attilio Fiandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405737: Reassigning 405737 to debian-installer
reassign 405737 debian-installer retitle 405737 i810 based gfx cards need adhoc framebuffer driver to support g-i thanks I am reassigning this bug to debian-installer because it's not due to a bug in the GTK cdebconf frontend, but rather to the lack of the i810 fb module in the kernel. Attilio Fiandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415127: Please retest g-i on Intel MacBook using recent daily builds
Hi Daily builds [1] are now based on linux=2.6.22 and DirectFB 1.0, so could please someone recheck wheter this bug, which was reported at the times of linux 2.6.18 and DirectFB 0.9.25, is gone or still persists? thanks Attilio Fiandrotti [1] http://people.debian.org/~joeyh/d-i/images/daily/netboot/gtk/mini.iso -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409412: Please retest g-i on Intel MacBook using recent daily builds
Hi Testing a daily build [1] in Arabic, i noticed that during udeb downloading the text under the progressbar no longer drifts to the left while the progressbar moves. Lior, could you please verify whether this bug is really gone or still it persists? thanks Attilio Fiandrotti [1] http://people.debian.org/~joeyh/d-i/images/daily/netboot/gtk/mini.iso -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405737: Reassigning 405737 to debian-installer
Frans Pop wrote: reassign 405737 cdebconf-gtk-udeb retitle 405737 i810 based gfx cards need adhoc framebuffer driver to support g-i thanks I am reassigning this bug to debian-installer because it's not due to a bug in the GTK cdebconf frontend, but rather to the lack of the i810 fb module in the kernel. I don't think that's a good idea. AFAIK just providing the module is not enough as the load order of FB modules and the fact that some are built into the kernel will still result in the i810 FB driver not being used. Also, this is not a build system issue and thus debian-installer is just the wrong package. To support this changes will be needed in kernel-wedge, specific kernel-image-di udebs and probably rootskel or rootskel-gtk. While there are no specific and tested patches to implement support for this, the best place to keep this BR is at cdebconf-gtk-udeb as we still have the old agreement that we use that also to park general issues with the graphical installer. When someone does actually work on this and _has_ patches, the BR should be cloned/reassigned to the components that need to be changed. My concern is this bug will stay neglected forever if it remains in cdebconf-gtk-udeb. What about filing a new BR to another package, more kernel specific, so that once the kernel guys have added the i810 fb module to the kernel we can patch rootskel-gtk to have directfb using the right fb device ? Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#247218: List of PowerMac and used fb modules
FYI, this wikipage [1] contains a listing of some machines where the graphical d-i was tested: the big table has a column which shows the /proc/fb string, which may be of some help in understanding what machines need the ofonly fb. sincerely Attilio Fiandrotti [1] http://wiki.debian.org/DebianInstaller/GUIPowerPC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440446: Is this bug related to the GTK frontend?
Hi I didn't understand whether this bug is related to the GTK frontend or not: in the former case, it should be reassigned to cdebconf-gtk-udeb. sincerely Attilio Fiandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#373253: Cause of g-i crashing on AMD64 at VT switch found
retitle 373253 g-i requires libgcc_s.so.1 on AMD64 and PowerPC thanks Given that this is not really a problem in directfb, and was agreed the proper fix would be to ship libgcc in a new udeb post-etch, I'm closing this bug now. I agree, btw i recently noticed that also the PowerPC g-i builds need the libgcc_s.so.1 file to be pulled in (this requires a patch to the relevant configuration powerpc files in the installer), so i'm retitling this BR accordingly for future reference. sincerely Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410559: Bug 410559 belongs to libgtk-directfb-2.0-0 and is upstream
reassign 410559 libgtk-directfb-2.0-0 severity 410559 normal tags 410559 upstream thanks I just verified that this bug can be found in upstream gtk+ sources too, hence reassigning to libgtk-directfb-2.0-0 Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453703: GTK frontend crashes when clicking on the Cancel button during DHCP address acquisition
package: cdebconf-gtk-udeb version: 0.125 severity: normal The GTK frontend crashes when clicking on the Cancel button during DHCP address acquisition, the bug was found in today's (Nov 30) i386 build. sincerely Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452020: closed by Bastian Blank [EMAIL PROTECTED] (Re: Bug#452020: Wrong library reduction performed when building debian-installer on PowerPC)
Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the mklibs package: #452020: Wrong library reduction performed when building debian-installer on PowerPC It has been closed by Bastian Blank [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Bastian Blank [EMAIL PROTECTED] by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) Subject: Re: Bug#452020: Wrong library reduction performed when building debian-installer on PowerPC From: Bastian Blank [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 12:15:30 +0100 To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] On Mon, Nov 19, 2007 at 10:26:27PM +0100, Attilio Fiandrotti wrote: I noticed the mklibs performs uncorrectly when building the d-i on PowerPC [1]: as i'm not mklibs expert You use a broken version of slang. The linker call lacks the map file which maps the symbol versions. | $ dpkg -l libslang2-pic [...] | ii libslang2-pic 2.0.7-5The S-Lang programming library, shared libra | $ dpkg -L libslang2-pic | grep .map | /usr/lib/libslang_pic.map This usualy means you use an outdated or otherwise broken build environment. Please provide proper informations about the packages you use in the bugreport. This i what i got on the PowerPC machine where mklibs failed to operate on libslang2 [EMAIL PROTECTED]:~/svn/installer/build$ apt-cache show libslang2-pic slang-pic Package: libslang2-pic ... Version: 2.0.7-3 Depends: libslang2-dev (= 2.0.7-3) [EMAIL PROTECTED]:~/svn/installer/build$ dpkg -L libslang2-pic /. /usr /usr/lib /usr/lib/libslang_pic.a /usr/share /usr/share/doc /usr/share/doc/libslang2-pic /usr/share/doc/libslang2-pic/copyright /usr/share/doc/libslang2-pic/changelog.gz /usr/share/doc/libslang2-pic/changelog.Debian.gz /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/libslang2-pic as you can see, the /usr/lib/libslang_pic.map file was not provided by that version of the package, so i modified the /etc/apt/sources.list file to take debs from unstable instead of lenny and, after updating the package list, a new libslang2-pic package, version 2.0.7-3 again, was pulled in, this time providing the needed map file and i could successfully complete the building of the installer. Still, i wonder why i had to mess with sources.list to get the correct package. Many thanks for helping me solve this issue! Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Issues building the g-i on PowerPC
Frans Pop wrote:
On Friday 16 November 2007, Attilio Fiandrotti wrote:
Frans Pop wrote:
On Friday 16 November 2007, Attilio Fiandrotti wrote:
1) When i make the build_powerpc_netboot-gtk target (other targets
untested), i get the following error by mklibs
That looks like it could be #433874, but that is supposed to be
solved...
The only thing that can tell exactly what happens is the full output of
mklibs with three times the '-v' option (-v -v -v).
A full gzipped log (900KB) can be found here [1].
That log does _not_ contain the additional mklibs debugging output.
You need to add the additional -v options in the Makefile.
my fault: i was adding the -v -v -v options to the MKLIBS variable in
cfg/common file, not to the Makefile.
Now i patched properly the Makefile
Index: Makefile
===
--- Makefile(revision 50159)
+++ Makefile(working copy)
@@ -436,7 +436,7 @@
-cp -a `find $(EXTRAUDEBSDIR)/lib -name '*.so.*'` $(TEMP)/udeblibs
-cp -a `find $(TREE)/lib -name '*.so.*'` $(TEMP)/udeblibs
mkdir -p $(TREE)/lib
- $(MKLIBS) -L $(TREE)/usr/lib -L $(TEMP)/udeblibs -v -d
$(TREE)/lib --root=$(TREE) \
+ $(MKLIBS) -L $(TREE)/usr/lib -L $(TEMP)/udeblibs -v -v -v -d
$(TREE)/lib --root=$(TREE) \
-L $(TREE)/usr/lib/cdebconf/frontend \
$(addprefix -l,$(notdir $(wildcard
$(TREE)/usr/lib/cdebconf/frontend/*.so))) \
`find $(TEMP) -type f -a \( -perm +0111 -o -name '*.so'
-o -name '*.so.*' \) | grep -v udeblibs`
and updated the gzipped logfile [1], but at my inexerienced eyes it
looks like the previous.
2) I have rebuilt some udebs (gtk+, cairo, pango, cdebconf) against
dfb 1.0
Change $debug=0 to 1 in installer/build/util/pkg-list to see what's
pulling it in.
done, but didn't work, so excluded manually the udeb from list of those
used for building the image
It was not supposed to _fix_ the issue, but to _show why/how_ the old udeb
is getting pulled in.
Please do not work around this, but check the debugging output with that
option enabled!
i patched the pkg-list perl script as
[EMAIL PROTECTED]:~/svn/installer/build$ svn diff util/pkg-list
Index: util/pkg-list
===
--- util/pkg-list (revision 50159)
+++ util/pkg-list (working copy)
@@ -36,7 +36,7 @@
print STDERR ** warning: @_\n;
}
-my $debug=0;
+my $debug=1;
my $debugindent=0;
sub debug {
and removed the old hack, but still i cannot get any valuable
information (or i'm not able to recognize it) from the output i get [2].
3) At the end of the building process i get this error
but still i'm getting the same error, pherhaps because it's related to
chrp and not prep ?
OK. In that case I cannot help with this. You could try asking Colin Watson.
My commits to disable prep were still correct though.
ok, tank you anyway, i hope Colin can have a look at that, although it's
not a critical issue atm.
sincerely
Attilio
[1] https://debian.polito.it/downloads/build_powerpc_netboot-gtk.log.gz
[2] https://debian.polito.it/downloads/build_pkg-list.log.gz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Issues building the g-i on PowerPC
Frans Pop wrote: The only thing that can tell exactly what happens is the full output of mklibs with three times the '-v' option (-v -v -v). and updated the gzipped logfile [1], but at my inexerienced eyes it looks like the previous. No, it now provides the correct info. Here is what seems to happen. If I call readelf on libslang from unstable on a PPC system, I get: $ readelf -s libslang.so.2 | grep SLsmg_write_string 319: 000680c080 FUNCGLOBAL DEFAULT 11 SLsmg_write_string@@SLANG2 In the log you provided I see: [...] reducing libslang.so.2 using: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] resolving /usr/lib//libslang_pic.a resolved to /usr/lib//libslang_pic.a extracting from: /usr/lib//libslang_pic.a so_file: /lib//libslang.so.2 calling mklibs-readelf --print-soname /lib//libslang.so.2 soname: libslang.so.2 calling mklibs-readelf --print-needed /lib//libslang.so.2 calling gcc -nostdlib -nostartfiles -shared -Wl,-soname=libslang.so.2 -uSLcurses_nodelay -uSLsmg_refresh -uSLcurses_wnoutrefresh -uSLcurses_wgetch -uSLcurses_wscrl -uSLcurses_nil -uSLcurses_initscr -uSLcurses_endwin -uSLsmg_touch_screen -uSLcurses_wrefresh -uSLcurses_delwin -uSLcurses_wattron -uSLcurses_wmove -uSLutf8_enable -uSLcurses_wclrtobot -uSLtt_set_cursor_visibility -uSLcurses_wattroff -uSLcurses_waddnstr -uSLcurses_waddch -uSLang_init_tty -uSLcurses_cbreak -uSLcurses_newwin -uSLtt_beep -o ./tmp/powerpc_netboot-gtk/tree/lib/libslang.so.2-so /usr/lib//libslang_pic.a -lgcc -L./tmp/powerpc_netboot-gtk/tree/lib -L./tmp/powerpc_netboot-gtk/tree/usr/lib -L./tmp/powerpc_netboot-gtk/udeblibs -L./tmp/powerpc_netboot-gtk/tree/usr/lib/cdebconf/frontend -L/lib/ -L/usr/lib/ -L/usr/X11R6/lib/ -L./tmp/powerpc_netboot-gtk/tree//usr/lib/cdebconf:/usr/lib/libcairo-directfb/lib -L./tmp/powerpc_netboot-gtk/tree//usr/lib/cdebconf -ldl -lm -lc /lib//ld.so.1 calling objcopy --strip-unneeded -R .note -R .comment ./tmp/powerpc_netboot-gtk/tree/lib/libslang.so.2-so ./tmp/powerpc_netboot-gtk/tree/lib/libslang.so.2-so-stripped /lib//libslang.so.2 868280L ./tmp/powerpc_netboot-gtk/tree/lib/libslang.so.2-so 331859L ./tmp/powerpc_netboot-gtk/tree/lib/libslang.so.2-so-stripped 306308L [...] calling mklibs-readelf --print-symbols-undefined \ ./tmp/powerpc_netboot-gtk/tree/lib/libnewt.so.0.52-so-stripped needed_symbols adding [EMAIL PROTECTED], weak: False [...] calling mklibs-readelf --print-symbols-provided \ ./tmp/powerpc_netboot-gtk/tree/lib/libslang.so.2-so-stripped present_symbols adding [EMAIL PROTECTED] So it looks like somehow the @SLANG2 extension changes to @Base during library reduction and that causes that the symbol cannot be found. Please file a serious BR against mklibs with this info and links to this BR and the logfile. I'll do 2) I have rebuilt some udebs (gtk+, cairo, pango, cdebconf) against dfb 1.0 Change $debug=0 to 1 in installer/build/util/pkg-list to see what's pulling it in. i patched the pkg-list perl script as That is correct, but your log is incomplete. You should be getting a lot of output like this near the beginning of the log (before the line starting with get-packages): pkg-lists: reading pkg-lists for netboot pkg-lists: processing pkg-lists/netboot/amd64.cfg pkg-lists: adding console-keymaps-at pkg-lists: collecting dependencies for console-keymaps-at pkg-lists: added cdebconf-udeb for console-keymaps-at pkg-lists: collecting dependencies for cdebconf-udeb pkg-lists: added libc6 for cdebconf-udeb pkg-lists: collecting dependencies for libc6 pkg-lists: added libdebian-installer4-udeb for cdebconf-udeb pkg-lists: collecting dependencies for libdebian-installer4-udeb pkg-lists: added libc6 for libdebian-installer4-udeb [...] Did you 'make reallyclean'? sure, i always call fakeroot make reallyclean; fakeroot make build_powerpc_netboot-gtk to build the images: the problem is that i'm not getting those lines and that's the reason why i had to remove from the UDEBS variable in the Makefile the entry about directfb 0.9.25 Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Issues building the g-i on PowerPC
Frans Pop wrote: On Monday 19 November 2007, Attilio Fiandrotti wrote: to build the images: the problem is that i'm not getting those lines and Not getting those lines is an error on your side!!! You should absolutely be able to get those lines. Suggest you work on that a bit more. I was eventualy able to debug the calls made by the Makefile on my i386 and figure out the correct call to pkg-list for powerpc util/pkg-list netboot/gtk di 2.6 2.6.22-3-powerpc and to get those pkg-lists: strings (which, btw, are printed to stderr and not on stdout, and that's the reason why tee'ing the latter only didn't do the trick): - libgtk-directfb-2.0-0-udeb pulls in libdirectfb-1.0-0-udeb pulls directly (that's ok) but i also see that - libgtk-directfb-2.0-0-udeb pulls in libcairo-directfb2-udeb (that's ok) - libcairo-directfb2-udeb pulls in libdirectfb-0.9-25-udeb (that's not ok) So, i hand-extracted the control file from inside the libcairo-directfb2-udeb udeb which i personally built against dfb 1.0 and placed inside localudebs, and its actual content is: Package: libcairo-directfb2-udeb Source: libcairo Version: 1.4.10-1 Architecture: powerpc Maintainer: Dave Beckett [EMAIL PROTECTED] Installed-Size: 412 Depends: fontconfig-udeb (= 2.4.0), libc6 (= 2.6-1), libdirectfb-1.0-0-udeb, libfreetype6-udeb (= 2.3 .5), libpng12-0-udeb (= 1.2.13-4), zlib1g-udeb (= 1:1.2.3.3.dfsg-1) as you can see, the udeb correctly depends from libdirectfb-1.0-0-udeb, so i'm wondering where that libdirectfb-0.9-25-udeb dependancy comes from. that's the reason why i had to remove from the UDEBS variable in the Makefile the entry about directfb 0.9.25 That's *by far* the ugliest d-i build hack I've ever heard of! You should never have to mess with the Makefile like that. If you really need to exclude a udeb, you should do it in pkg-lists. ah, i didn't know such an option existed, now i do, and i agree it's better than hacking the Makefile :) Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452020: Wrong library reduction performed when building debian-installer on PowerPC
Package: mklibs Severity: serious Version: 0.1.26 I noticed the mklibs performs uncorrectly when building the d-i on PowerPC [1]: as i'm not mklibs expert , i'm reporting what FJP said about this issue: It looks like somehow the @SLANG2 extension changes to @Base during library reduction and that causes that the symbol cannot be found. The post can be found here [2] and this bug was workarounded for now by using mklibs-copy in place of mklibs. regards Attilio Fiandrotti [1] https://debian.polito.it/downloads/build_pkg-list.log.gz [2] http://lists.debian.org/debian-boot/2007/11/msg00500.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Issues building the g-i on PowerPC
Rick Thomas wrote: On Nov 16, 2007, at 8:44 AM, Attilio Fiandrotti wrote: Anyway, i was able to produce a dfb 1.0 based miniiso for powerpc [3]: it would be nice if someone could give it a try and report whether it works or not regards Attilio [3] https://debian.polito.it/downloads/mini_powerpc_dfb1.0.iso I downloaded, burned and booted this on a BlueWhite G3 PowerMac. When booted with the default (just CR at the boot: prompt) the monitor showed an internal diagnostic No Signal and went into power saving mode. When booted with expert video=ofonly at the boot: prompt, the screen went red and flashed back and forth red with a black screen with the error message libgcc.so.1 must be installed for pthread_cancel to work ah, that looks to be #373253 once again: this bug was workarounded by adding the EXTRAFILES = /lib/libgcc_s.so.1 line to i386 and amd64 conf files for gtk images: i did the same for powerpc and i see that library is now copied into the initrd tree. Could you please try burning and booting the mini.iso image you find in my ~ in macswell once again (i also updated the iso on the debian.polito.it website) ? many thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Issues building the g-i on PowerPC
Hi I recently started doing some work with DirectFB 1.0 on PowerPC ( many thanks go to Rick Thomas who provided me remote access to a development PowerPC box), and i run into the following issues i wasn't able to solve myself, but pehrhaps some of you can 1) When i make the build_powerpc_netboot-gtk target (other targets untested), i get the following error by mklibs 2865 symbols, 56 unresolved Traceback (most recent call last): File /usr/bin/mklibs, line 432, in ? raise Unresolvable symbol %s % name Unresolvable symbol [EMAIL PROTECTED] make[2]: *** [stamps/tree-powerpc_netboot-gtk-stamp] Error 1 make[1]: *** [_build] Error 2 make: *** [build_powerpc_netboot-gtk] Error 2 the problem is that mklibs strips away that symbol from the shared library which provides it during reduction [EMAIL PROTECTED]:~/svn/installer/build$ objdump -x ./tmp/powerpc_netboot-gtk/tree/lib/libslang.so.2-so-stripped | grep SLsmg_write_string no results [EMAIL PROTECTED]:~/svn/installer/build$ objdump -x ./tmp/powerpc_netboot-gtk/tree/lib/libslang.so.2-so | grep SLsmg_write_string 0002ef90 g F .text 0050 SLsmg_write_string anyway, this problem can be workarounded by replacing mklibs with mklibs-copy in config/common.cfg 2) I have rebuilt some udebs (gtk+, cairo, pango, cdebconf) against dfb 1.0 [EMAIL PROTECTED]:~/svn/installer/build$ ls localudebs/*udeb localudebs/cdebconf-gtk-udeb_0.125_powerpc.udeb localudebs/cdebconf-newt-udeb_0.125_powerpc.udeb localudebs/cdebconf-priority_0.125_all.udeb localudebs/cdebconf-text-udeb_0.125_powerpc.udeb localudebs/cdebconf-udeb_0.125_powerpc.udeb localudebs/libcairo-directfb2-udeb_1.4.10-1_powerpc.udeb localudebs/libdebconfclient0-udeb_0.125_powerpc.udeb localudebs/libdirectfb-1.0-0-udeb_1.0.1-2_powerpc.udeb localudebs/libdirectfb-bin-udeb_1.0.1-2_powerpc.udeb localudebs/libgtk-directfb-2.0-0-udeb_2.12.1-1_powerpc.udeb localudebs/libpango1.0-udeb_1.18.3-1_powerpc.udeb localudebs/rootskel-gtk_1.08_powerpc.udeb but, no matter i have no dfb 0.9.25 dependencies anymore, i still get the dfb 0.9.25 udeb unpacked into the cd tree aside dfb 1.0 [EMAIL PROTECTED]:~/svn/installer/build$ ls tmp/powerpc_netboot-gtk/tree/usr/lib/ |grep directfb directfb-0.9.25 directfb-1.0-0 libdirectfb-0.9.so.25 libdirectfb-0.9.so.25.0.0 libdirectfb-1.0.so.0 libdirectfb-1.0.so.0.1.0 libgdk-directfb-2.0.so.0 libgdk-directfb-2.0.so.0.1200.1 libgtk-directfb-2.0.so.0 libgtk-directfb-2.0.so.0.1200.1 [EMAIL PROTECTED]:~/svn/installer/build$ find -iname '*udeb'|grep libdirectfb ./apt.udeb/cache/archives/libdirectfb-1.0-0-udeb_1.0.1-2_powerpc.udeb ./apt.udeb/cache/archives/libdirectfb-0.9-25-udeb_0.9.25.1-6_powerpc.udeb ./localudebs/libdirectfb-1.0-0-udeb_1.0.1-2_powerpc.udeb ./localudebs/libdirectfb-bin-udeb_1.0.1-2_powerpc.udeb how is this possible, since all the udebs which depended upon dfb 0.9.25 were rebuilt to depend from dfb 1.0 ? 3) At the end of the building process i get this error === Moving bootable kernel image file to ./dest/powerpc/netboot-gtk/vmlinuz-chrp.initrd... /usr/sbin/mkvmlinuz: line 451: ./dest/powerpc/netboot-gtk/vmlinuz-chrp.initrd: No such file or directory === Cleaning up... Any help would be realy apreciated. thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Issues building the g-i on PowerPC
Frans Pop wrote: On Friday 16 November 2007, Attilio Fiandrotti wrote: 1) When i make the build_powerpc_netboot-gtk target (other targets untested), i get the following error by mklibs That looks like it could be #433874, but that is supposed to be solved... The only thing that can tell exactly what happens is the full output of mklibs with three times the '-v' option (-v -v -v). A full gzipped log (900KB) can be found here [1]. 2) I have rebuilt some udebs (gtk+, cairo, pango, cdebconf) against dfb 1.0 Change $debug=0 to 1 in installer/build/util/pkg-list to see what's pulling it in. done, but didn't work, so excluded manually the udeb from list of those used for building the image 3) At the end of the building process i get this error If you want help with that, provide the full log, or do a careful check for differences with daily build logs yourself. It's the very same error reported at the end of this build log [2]. I tested your last patch r50159 | fjp | 2007-11-16 12:09:07 +0100 (ven, 16 nov 2007) | 2 lines * Disable builds for PowerPC PReP images as there are no prep kernels available. but still i'm getting the same error, pherhaps because it's related to chrp and not prep ? Anyway, i was able to produce a dfb 1.0 based miniiso for powerpc [3]: it would be nice if someone could give it a try and report whether it works or not regards Attilio [1] https://debian.polito.it/downloads/build_powerpc_netboot-gtk.log.gz [2] http://people.debian.org/~wouter/d-i/powerpc/daily/build_powerpc_netboot-gtk.log [3] https://debian.polito.it/downloads/mini_powerpc_dfb1.0.iso -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [directfb-users] porting etch graphic installer to mips/lemote
Vern Sun wrote: I am porting etch graphic installer to a mips based Desktop system (Lemote/Fulong[1]) and am having a problem running dfbinfo. Cool! right now g-i works on i386, amd64, ppc (partially), support for mips would be great! == Crash problem when dfbinfo is running in chroot jail. But it works fine without a chroot. -- /dev# /usr/lib/directfb-0.9.25/bin/dfbinfo /snip Unfortunately i cannot help you with such platform, but i know Davide Viti had been working in the past to port g-i on ARM or MIPS (cannot remeber correctly right now). Because the g-i is (hopefully) moving to DFB 1.0 soon, i suggest you perform preliminar tests with dfb 1.0 anf gtkdfb compiled against dfb 1.0 on aregular debian system. Btw, i suggest you to cc debian-boot, as the most part of the development of the g-i takes place there. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [directfb-users] porting etch graphic installer to mips/lemote
Vern Sun wrote:
I am porting etch graphic installer to a mips based Desktop system
(Lemote/Fulong[1]) and am having a problem running dfbinfo.
== Crash problem when dfbinfo is running in chroot jail.
But it works fine without a chroot.
--
/dev# /usr/lib/directfb-0.9.25/bin/dfbinfo
...
(!) [ 4618:0.218] -- Caught signal 6 (unknown origin) --
(-) [ 4618: -STACK- ]
#0 0x2abb3000 in ?? () from /usr/lib/libdirect-0.9.so.25
#1 0x2abbb33c in direct_thread_cancel () from /usr/lib/libdirect-0.9.so.25
#2 0x2c5bd5e0 in ?? () from
/usr/lib/directfb-0.9.25/inputdrivers/libdirectfb_keyboard.so
#3 0x2ab39d30 in ?? () from /usr/lib/libdirectfb-0.9.so.25
#4 0x2ab2e41c in dfb_core_part_shutdown () from
/usr/lib/libdirectfb-0.9.so.25
#5 0x2ab2cb10 in ?? () from /usr/lib/libdirectfb-0.9.so.25
#6 0x2ab2cdec in ?? () from /usr/lib/libdirectfb-0.9.so.25
#7 0x2ab8da50 in fusion_arena_exit () from /usr/lib/libfusion-0.9.so.25
#8 0x2ab2c308 in dfb_core_destroy () from /usr/lib/libdirectfb-0.9.so.25
#9 0x2aae5fb4 in IDirectFB_Destruct () from /usr/lib/libdirectfb-0.9.so.25
#10 0x2aae6160 in ?? () from /usr/lib/libdirectfb-0.9.so.25
#11 0x00400c6c in main () from /usr/lib/directfb-0.9.25/bin/dfbinfo
(-) [ 4621: -STACK- 'VT Switcher']
#0 0x2ad8a9b4 in ?? () from
/usr/lib/directfb-0.9.25/systems/libdirectfb_fbdev.so
(-) [ 4624: -STACK- 'Keyboard Input']
#0 0x2c5bdb84 in ?? () from
/usr/lib/directfb-0.9.25/inputdrivers/libdirectfb_keyboard.so
The complete log here: [2].
== Here are the steps I am going through.
. Build udebs needed
---
/directfb# cat DirectFB-0.9.25.1/debian/rules
...
../configure \
--prefix=/usr \
--bindir=\$${libdir}/directfb-$(version_abi)/bin \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
--with-gfxdrivers=radeon \
--enable-debug \
--disable-sdl \
--disable-x11 \
--disable-vnc \
--disable-gif \
--disable-jpeg \
--disable-mpeg2 \
--disable-unique \
--disable-video4linux \
--disable-mmx \
--disable-sse
---
. Make the initrd.gz
---
/debian-installer/build# ...
/debian-installer/build# fakeroot make build_decstation_gtk
---
. In chroot jail
---
~# debian-installer-startup
~# cd /dev
/dev# mknod fb0 c 29 0
/dev# mknod tty c 5 0
/dev# mknod tty0 c 4 0
/dev# mknod tty7 c 4 7
/dev# mknod tty8 c 4 8
/dev# ls
console fb0 log net ppp shm stderr stdout tty0
tty8
core fd loop null pts sndstat stdintty tty7
/dev# fbset -i
mode 1680x1050-60
# D: 146.263 MHz, H: 65.296 kHz, V: 59.960 Hz
geometry 1680 1050 1680 1050 8
timings 6837 280 104 30 3 176 6
hsync high
rgba 8/0,8/0,8/0,0/0
endmode
Frame buffer device information:
Name: ATI Radeon QZ
Address : 0x1400
Size: 16777216
Type: PACKED PIXELS
Visual : PSEUDOCOLOR
XPanStep: 8
YPanStep: 1
YWrapStep : 0
LineLength : 1728
MMIO Address: 0x1604
MMIO Size : 16384
Accelerator : ATI Radeon family
/dev# cat /etc/directfbrc
#no-hardware
bg-color=ffdcdad5
screenshot-dir=/var/log
#disable-module=keyboard
#disable-module=ps2mouse
#disable-module=linux_input
log-file=/var/log/directfb.log
Any ideas? Thanks in advance.
BTW.. have you tried disabling the radeon module
(disable-module=keyboard) or the hw acceleration at whole (no-hardware)
? Our past experience with DFB on non-i386 archs is that hw acceleration
often fails.
regards
Attilio
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451221: report-hw should consider newer versions of DirectFB too
package: installation-report severity: normal tags: patch While experimenting with the new DirectFB 1.0, i noticed the report-hw script has the 0.9.25 version of DirectFB hardcoded into it. As a consequence, it looks for the diagnostig dfbinfo tool into /usr/lib/directfb-0.9.25/bin/, while libdirectfb-1.0-0-udeb provides such tool into /usr/lib/directfb-1.0.0/bin/ and future versions of this package may install dfbinfo in other paths. So, i propose to make the script dfb version agnostic with the attached patch: is it ok committing the patch ? regards Attilio Fiandrotti Index: report-hw === --- report-hw (revisione 50086) +++ report-hw (copia locale) @@ -67,7 +67,7 @@ if [ $DEBIAN_FRONTEND = gtk ]; then addfile /proc/fb addfile /etc/directfbrc - if [ -x /usr/lib/directfb-0.9.25/bin/dfbinfo ]; then - /usr/lib/directfb-0.9.25/bin/dfbinfo 21 | addinfo dfbinfo + if [ -x /usr/lib/directfb-*/bin/dfbinfo ]; then + /usr/lib/directfb-*/bin/dfbinfo 21 | addinfo dfbinfo fi fi
Bug#451221: report-hw should consider newer versions of DirectFB too
Frans Pop wrote: On Wednesday 14 November 2007, Geert Stappers wrote: Op 14-11-2007 om 10:46 schreef Geert Stappers: What will happen when there are several version of directfb installed? (example given: head has dfb-1.0, developer adds dfb-1.1 for testing) I actually considered this, but I did not think it necessary. The build system should _not_ install two versions of directfb, so the additional code is redundant. Having an empty string is no problem either because [ -x ] will return false (something that you could have checked trivially). That's correct, no ISO contains two versions of directfb, so i'm going to commith the patch with modifications by frans. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [directfb-users] porting etch graphic installer to mips/lemote
Frans Pop wrote: On Wednesday 14 November 2007, Attilio Fiandrotti wrote: BTW.. have you tried disabling the radeon module (disable-module=keyboard) or the hw acceleration at whole (no-hardware)? disable-module=keyboard for disabling the radeon module??? /me suspects a copy-and-paste error I apologize: the string to add to the directfbrc file is disable-module=radeon, which has no effect if Vern is using our standard libdirectfb udeb, which doesn'include that module. Otherwise, in the case Vern is using his own handmade udeb with custom gfx accellerators including radeon, that string will disable it. regards Attilio Fiandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447610: Succesfull install on iBook G4
Geert Stappers wrote: Package: installation-reports Boot method: netinst CD Image version: lenny (installer build 20071016-02:06) Date: 2007-10-22 Machine: Apple iBook G4 Processor: PowerPC 7447A, altivec supported Memory: 1.2 Gigabyte Partitions: ... Comments: It surprised me there was no graphical installer. At present date, g-i on PPC is still far from being in a good enough shape to be used as any sort of official installer. What needs to be done is rebuilding cairo and gtk against new dfb 1.0.1 in experimental and produce a PPC miniiso like Jeremy did for i386, to see how the new version of our windowing system behaves on PPCs. I wonder if a call for testing should be posted on debian-powerpc ? regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [g-i] Test image built with directfb 1.0.1-2 and GTK+ 2.11.6-1
Jérémy Bobbio wrote: Hi! To see how smooth would be the migration to core components of the graphical installer currently in experimental, I have built a test image using directfb 1.0.1-2 and GTK+ 2.11.6-1. I have not noticed any problems so far, but perhaps some of you could. You can get the image at: http://people.debian.org/~lunar/mini-dfb1.0.1-i386.iso (This image was built with my cdebconf_tetris branch.) By monitoring debconf's memory usage during installation process, it looks to me the patch recently added to gtk/dfb to fix a memory leak occourring at window destruction does its job. It would also be interesting knowing how the new set of libraries performs on PPC architecture, especially on boxes equipped with nvidia graphic chips, whre DFB 0.9.25 used to crash. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed list of udebs for removal
Jérémy Bobbio wrote: On Fri, Aug 17, 2007 at 10:29:36AM -0300, Otavio Salvador wrote: I've done a look on current available udebs and some look very useless currently and I'd like to request their removal. For it, I'd like, first, to discuss here to see if someone complain about: [...] - libsdl1.2debian-udeb If no one speaks up, I will ask for its removal in two days. I remember it was proposed [1] to include sdl-based games in the g-i, but i doubt this is ever going to happen.. regards Attilio [1] http://wiki.debian.org/DebianInstaller/GUIToDo#head-f50d41a0a8234fc372b261b86ac73548e6be4746 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#416911: New DirectFB 1.x releases are available
Davide Viti wrote: Hi Guillem, On Tue, Sep 04, 2007 at 12:01:16AM +0300, Guillem Jover wrote: I'm not going to upload 1.1.0, as it can be read from the release announcment that not all features are working again. I might later on upload it to experimental. I see; I hope problems will be fixed soon, so that we can see how g-i behave with something recent. It would especially be interesting checking if the problems related to some input devices and nvidia video cards on PPCs are gone. As also mentioned on IRC I'd like to move the dfbinfo binary current provided in the udeb lib into its own package (which didn't happen at the time due to the release being so close). The new package (libdirectfb-bin-udeb) would mostly contain that, but other programs useful for debugging purposes can be added later on if requested. that makes sense Indeed, we asked Guillem specifically for that some times ago (#390437). regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New DirectFB 1.x releases are available
Hi Recently DirectFB version 1.0.1 [1] and 1.1.0 [2] were released: i suggest we switch to the most recent DFB version while we're still early in Lenny release cycle. regards Attilio [1] http://directfb.org/index.php?path=Main%2FNewsentry=2007-08-26-0.dok [2] http://directfb.org/index.php?path=Main%2FNewsentry=2007-08-27-0.dok -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Add cdebconf-gtk-tetris package
Jérémy Bobbio wrote: Hi! This (fairly big) patch adds a cdebconf-gtk-tetris package to the debian-installer. As the name suggest, this will allow you to play Tetris within d-i. ... super-cool, i liked it! :) Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Minutes from d-i meeting on July, 25th
Jérémy Bobbio wrote: snip/ Future of g-i - Attilio has less time than he used to for taking care of the graphical installer. Daily maintainance will be done by Lunar once his branch is ready to be merged, with Attilio helping out. This will also give Attilio more time to fix remaining issues in the dependencies of g-i (e.g directfb). Lunar will first remove new features from his branch to get a side-by-side functionally equilavent implementation. Once ready, we will switch over to the new codebase at once. Actually, it's true i have less time to dedicate to GTK frontend development, so i'm glad Lunar took it over to add new features like vte terminal, plugins for partitioner and locale choseer etc.. I'll keep on working on the infrastructural side of g-i project taking care to maintain in good shape those packages the g-i depends upon (of course, as soon as i have time, i'll try to understand the new codebase once it has settled.) Specifically, now that i have svn access to Gnome repo i can take care of upstream maintainance of gtk's dfb backend, which was cause of much pain during last years. This means that gtkdfb bugs found affecting the g-i will be quickly fixed upstream, freeing Loic, our gtk/dfb maintainer, from the burden of applying debian-specific patches. ATM, one of the gratest architectural challenges i see in g-i's future is switching to DirectFB 1.0 (#416911), which also implies rebuilding cairo/dfb and gtk/dfb against new DFB libraries. As otavio pointed out, we need to do this early in release cycle in order to be able to spot and fix possible issues and regressions. I tried to mail Guillem a couple of times recently, but received no answer yet. Eventually, there should be no problem in having the GTK frontend becoming default for i386 and amd64, viceversa, g-i on PPC is still affected by some issues, among others the crashing of DirectFB on NVidia-equipped boxes. It would be great if some debian-powerpc people could be involved in the g-i project. The remaining technical details will be sorted out on the mailling-lists. About the BOOLEAN handler, i'm for the Radio option as in current GTK frontend buttons are reserver to Continue/Back/Screenshot button. About the Screenshot button issue, i'm for keeping it in d-i, posssibly moving it to the left-bottom corner of the screen and replacing the Screenshot label with a camera icon regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407035: Bug fixed in gtk+ 2.10.x series, workaround removed
Hi I just removed the workaround i previously introduced for this bug (see r48749) because it was fixed upstream in recent gtk+ 2.10.x releases. You may now notice warning messages by gtk/dfb when performing d'n'd: those are due to a minor gtk/dfb issue i'm going to address upstream very soon. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434723: debian-installer: doesn't boot in VirtualBox
Peter Eisentraut wrote: Package: debian-installer Severity: important I downloaded http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso just now, booted it up in a VirtualBox. It gets to Uncompressing Linux... Ok, booting the kernel. At that point it hangs. If I replace the virtual CD image with the etch release (debian-40r0-i386-netinst.iso), it boots up just fine. could you please try booting with install DEBIAN_FRONTEND=newt ? regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [long] An attempt to improve the code of the GTK+ frontend
Frans Pop wrote:
On Sunday 08 July 2007 01:28, Jérémy Bobbio wrote:
I never knew that it would take me so much time, but I now consider
that the work I had started on improving the code of the GTK+ frontend
of cdebconf is ready for a broader review.
Thanks for all the work Jérémy!
I'll not comment on the really technical side of the changes, mostly
because my grasp of C is not sufficient to have an opinion on them.
However, in general the refactoring seems like a good idea to me.
Indeed, the code is technically well written / formatted
--- 8 ---
We could use the following process to integrate it:
* discuss, comment and test;
Ack.
* make the needed changes to fe_gtk's branch;
Ack.
* once we agree that it can be integrated in the main branch,
write small patches (or incremental commits) to slowly transform the
current code into the result of the process.
Hmm. If the changes are so structural, I'm not sure that the effort of
creating patches to have a gradual changeover is worth it. I'd suggest
just getting the code in your branch into the state we want it and then
just merging it into trunk in one commit.
Probably, because of the huge number of changes, a single commit is a
more viable option
I am open to normalize the code before integrating it. But I would
be inclined to get a broader opinion about at least:
} else {
[...]
I find the former much more readable!
I agree that this would be an improvement. Colin?
I agree: code in GTK frontend is not very clean and needed some reworking
2.3 Code has been split in different files
The longest file have a total of 638 lines (including documentation
and header) vs. 1790 lines for the current code.
The stats at the bottom show an increase in lines of code of 1000 lines,
or 70%. That seems excessive, but I suspect the true increase is more
subtle.
Could you provide sloccounts:
- excluding comments
- excluding completely new functionality (such as the entropy plugin
That would give a more realistic basis for comparison.
2.5 Separation of code specific to the debian-installer
The screenshot module is compiled conditionally as I see no reason
to enable this feature on standard desktops.
Agreed.
I see that in current jeremy's proposal the screenshot button is
disabaled by default: i think we must somehow allow the user to take
screenshots using the mouse only.
In the past, that screenshot facility revealed to be very useful in
reporting issues with complex fonts, isuues that may arise when new
languages are added to the installer or we switch to new fontsets.
So, i suggest to put a small Camera icon in the bottom-left corner of
the screen (pherhaps displayed only in the case the installer is started
in expert mode ?)
3.5 fe_gtk_set_title() reactivated
The implementation of the set_title method of cdebconf was changed
to the default one in r43372 to avoid spurious title changes during
pkgsel.
Note that the TITLE command is deprecated in debconf anyway, although
there is at least one location in D-I (lowmem) where it is currently used
and, AFAICT, needed.
Because this looks like it's more related to the generic debconf
architecture, i cannot properly speak about it.
4.1 Banner adapts to various screen size
The banner now adapts to any screen width. The logo is aligned on
the left of the screen, and its right side is filled with the color
defined in LOGO_BACKGROUND_COLOR.
I'm not sure that this is a good solution. With the current bannersetting
a fixed background color works, but this would not be true for more
complex banners as proposed in #414785 or [1], or with banners for
derived distributions using a completely different banner (such a Dzongha
Linux [2]).
Basically, hardcoding a color seems very wrong to me.
fjp's observation are correct, probably a better solution has to be seeked.
4.2 Main window adapts to various screen size
WINDOW_HEIGHT and WINDOW_WIDTH constants were removed, as the screen
height and width are are now dynamically retrieved through
gdk_screen_get_height() and gdk_screen_get_width(). The frontend now
works a bit better on higher-resolution [11].
IMO supporting higher resolutions will require a redesign of the
interface, for the following reasons:
- the text area becomes too wide, which means that lines of text become
too long which reduces readability
- the buttons get very isolated at the extreme bottom of the screen
In other words: yes, supporting higher resolutions is a great goal, but
not without making sure that the total presentation is still useable. IMO
we'd need to limit the effective usable area of the screen, for example
by defining a rectangular container within which all other elements are
positioned.
We'd probably also need a somewhat more interesting background outside
that container than our current grey.
Probably a good idea would be taking advantage of hi-resolution
Bug#433073: Please disable DirectFB's window backend buffer
Frans Pop wrote: On Saturday 14 July 2007 11:15, Attilio Fiandrotti wrote: DirectFB allows to set [1] the way the desktop window buffering mechanism works by disabling the backend buffer. The result, in my experiments, was saving some some hundreds KB of memory with no noticeable drawbacks. I'm not sure about this. I've tested this change in VMWare and I get quite a lot of flashes when the display is updated in quick succession. The flashes are really noticeable and are not there without the patch, so it looks as if the window buffer does help to stabilize display updates in D-I. I don't get that many flashes on my pc, but i guess the behaviour may be strictly hardware-dependant. The flashes are due to the lack of a backend buffer and exploit the possible drawbacks i was talking about, as described in directfbrc man page. Anyway, i don't feel compromising usability for some hundreds KB of memory saving, so if you don't think this patch should be applied, please just mark it as wontfix for future reference. I hope to get considerable memory savings when DirectFB 1.0 is available [1]. regards Attilio Fiandrotti [1] http://lists.debian.org/debian-boot/2007/07/msg00355.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DirectFB 1.0 needed to fix a memory leak in gtk/dfb
Hi I'd like to know if any progress was recently made towards packaging DirectFB 1.0. DirectFB 1.0, among many improvements and fixes over version 0.9.25 like better touchpad support, provides a new method (DFBWindow::DetachEventBuffer () ) which is needed by a patch which was recently committed into gnome's svn. Such patch [1] fixes a huge memory leak which currently happens every time a progressbar is displayed and hid, resulting in some megs of memory wasted at the end of the installation. regards Attilio Fiandrotti [1] http://svn.gnome.org/viewcvs/gtk%2B/trunk/gdk/directfb/gdkevents-directfb.c?r1=17195r2=18459sortby=date -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433073: Please disable DirectFB's window backend buffer
package: rootskel-gtk severity: wishlist tags: patch DirectFB allows to set [1] the way the desktop window buffering mechanism works by disabling the backend buffer. The result, in my experiments, was saving some some hundreds KB of memory with no noticeable drawbacks. I propose to apply the attached one-line patch and look for possible artifact which may appear on the display, and in the case reverse the patch. regards Attilio [1] http://www.directfb.org/docs/directfbrc.5.html Index: src/etc/directfbrc === --- src/etc/directfbrc (revisione 48095) +++ src/etc/directfbrc (copia locale) @@ -4,3 +4,4 @@ disable-module=keyboard disable-module=ps2mouse #disable-module=linux_input +desktop-buffer-mode=frontonly
Re: Notes from the D-I future BOF meeting at Debconf
Christian Perrier wrote: If OK, I can send my rough notes to the list. I'd find this useful. snip/ pere: make g-i configurable improve the user interface Is there any further detail available on plans about these two points ? work on issues with input handling I guess this is #401296 and #394871, which i suspect they are upstream gtk/dfb problems desêrately new cdebconf plugin automatic partition support for mor ethan 1 volume, more than 1 disk partitioner with the GTK frontend sit down, think about partitioner flows then try coding Coling strongly recommends against using gparted after experience in Ubuntu IIUC, the plans are abandoning the idea of porting to plain C gparted, is this correct ? cdebconf become the standard debconf The GTK frontend is nicely going this way :) redards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402126: Reworking the GTK+ cdebconf frontend
tags 402126 pending thanks Attilio Fiandrotti wrote: snip/ 4) As suggested by Jeremy on IRC, reading d-i/keymap while keeping track of last known value and looking for changes. This is, IMHO, the easiest solution available ATM, and morover doesn't require touching other parts of the installer than the GTK frontend and avoids dealing with pipes. I eventually implemented keymap reloading checking d-i/keymap value as suggested by Jeremy, this should fix properly bug #402126. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reworking the GTK+ cdebconf frontend
Loïc Minier wrote:
snip/
Because keymap reloading may be a common issue for other gtk/dfb based
apps, i think a reasonable way to proceed is adding a
gdk_directfb_keymap_reload()
Would there be a X11 equivalent for this? I'm not sure I agree Gdk
needs to gain a directfb specific function concerning keymap reloading,
nor that manual reloading is the way to go.
Gdk has some API regarding keymaps, but mostly getters and no setter.
It also seems to provide a way to detect when a keymap changes via the
::keys-changed signal.
Isn't there a way to make directfb triggers the internal gdk keymap
reload mechanism without adding a manual reload API? This would save
the cdebconf frontend and other gtk/gdk apps the trouble of manually
reloading the keymap.
The core of the problem is not detecting the keymap change at the
toolkit level (which is unimportant in our case) but rather informing
the windowing system (DirectFB in our case) that the keymap has to be
updated to match the console one set by keymap-chooser (or whatever is
the d-i component performing that task).
If we were on X, we could probably use setxkbmap to tell the X server
the keymap had changed.
Because we are on DFB, and because we haven't multicore support enabled
in our directfb builds, we cannot tell the master DFB process the
keymap has changed unless from within the cdebconf process.
From within the cdebconf process, there is unluckily no easy way to
detect / being informed that the console's keymap has changed.
So, what we do is forcing, from the gtk frontend, keymap reloading at
every frontend::go() call.
This would save us from including directfb's header files from the GTK
frontend and directly calling directfb functions from within it.
I could propose a patch and apply it upstream, but i'd like to hear an
opinion from our gtk/dfb maintiner: Loic, what's your opinion on this
issue?
I don't see the problem in including the directfb headers from one of
the file used to build cdebconf/gtk: can't you have
cdebconf/gtk/common.c, directfb.c, and x11.c?
Because we can now detect whether to enable or not DirectFB code by mean
of the DI_UDEB check, the best solution is probably leaving the
dfb_input_device_reload_keymap( dfb_input_device_at( DIDID_KEYBOARD ) );
call where it is, and probably fixing the compiler warining with Lunar's
patch.
A reasonable improvement over current situation could prbably be setting
TRUE a boolean d-i/keymap_changed question from within the
keymap-chooser everytime the console keymap is updated.
At every frontend_go() call, the gtk frontend should do something like
(pseudocode)
if ( question_get(d-i/keymap_changed) == TRUE ) {
dfb_input_device_reload_keymap( dfb_input_device_at( DIDID_KEYBOARD ) );
question_set (d-i/keymap_changed, FALSE);
}
So that we don't pollute the output of the GTK frontend with
unneded messages related to keymap reloading anymore.
This fix to work requires of course updating both the keymap-chooser and
gtk frontend toghether.
I'd like to hear opinions on this solution.
regards
Attilio Fiandrotti
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reworking the GTK+ cdebconf frontend
Loïc Minier wrote:
On Mon, Jul 02, 2007, Attilio Fiandrotti wrote:
The core of the problem is not detecting the keymap change at the toolkit
level (which is unimportant in our case) but rather informing the windowing
system (DirectFB in our case) that the keymap has to be updated to match
the console one set by keymap-chooser (or whatever is the d-i component
performing that task).
Well, s/toolkit/windowing system/: why not work on making the windowing
system aware of keymap changes rather than adding API to force a reload
manually?
Well, neither X is able nor supposed, AFAIK, to detect console keymap
changes and set its keymap accordingly, it has to be told from external
by means of setxkbmap..
If we were on X, we could probably use setxkbmap to tell the X server
the keymap had changed.
Hmm you could use setxkbmap to *change* the keymap of the server, and
you wouldn't have to do anything in each client. It's precisely
thinking of the X model that I was surprized you wanted to add API to
do more things manually, and it's only fixed at the toolkit level, for
this toolkit, instead of the lower levels.
As i said before, if we had multiapp support in our DirectFB builds, we
could implement a setxkbmap-like mechanism with DFB, but since we don't,
i was thinking about that from-toolkit-level hack to force keymap
reloading, which i now see it's not a good solution after all..
From within the cdebconf process, there is unluckily no easy way to
detect / being informed that the console's keymap has changed.
So, what we do is forcing, from the gtk frontend, keymap reloading at
every frontend::go() call.
What channels could we use to inform directfb of keymap changes? Would
it be possible to make whatever first process controls the FB listen on
some agreed upon socket location and send some the keymap has been
reloaded messages to it when the relevant change keymap binary is
run? Or perhaps the kernel can send such events, as I understand it's
the layer where the switch happens?
Because it's difficult, without multiapp support, telling the directfb
master application (cdebconf, in the case) to reload keymap from
external, then it's better having cdebconf listening on a dedicated
channel (a debconf question, a socket, a pipe.. ) for the update to happen.
I guess the reload-keymap signal must be sent at the application
level, namely from the application that manages keymap changes in d-i.
A reasonable improvement over current situation could prbably be setting
TRUE a boolean d-i/keymap_changed question from within the keymap-chooser
everytime the console keymap is updated.
At every frontend_go() call, the gtk frontend should do something like
(pseudocode)
if ( question_get(d-i/keymap_changed) == TRUE ) {
dfb_input_device_reload_keymap( dfb_input_device_at( DIDID_KEYBOARD ) );
question_set (d-i/keymap_changed, FALSE);
This would only work for debconf aware programs having this snippet and
if all keymap-changing programs are made debconf-aware too. The
advantage of a lower-level solution would be to enable this detection
for all situations.
That's correct, but ATM only d-i requires keymap updates.
If we were using cdebconf as a debconf replacement, i doubt such a
necessity would arise.
IOW: how do keymap-changing programs inform the DirectFB layer that the
keymap has changed and it should reload it (transparently for any
higher layer)?
ATM, there is no such mechanism: at every frontend::go() call the GTK
frontend forces DFB to reload keymap, no matter the update was realy
necessary or not, hence the pollution in cdebconf's output :(
regards
Attilio
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reworking the GTK+ cdebconf frontend
Frans Pop wrote: On Monday 02 July 2007 09:34, Attilio Fiandrotti wrote: A reasonable improvement over current situation could prbably be setting TRUE a boolean d-i/keymap_changed question from within the keymap-chooser everytime the console keymap is updated. This could be an option, but using debconf for this is probably not the correct solution (debconf abuse). Couldn't the frontend listen on a named pipe for keyboard change triggers, or something like that? kbd-chooser could then check if that pipe exists and write something to that to indicate a keymap change. Note that as we intend to switch to console-setup, that would have to be made to support this mechanism too. Disclaimer: as this is totally outside my scope, the responsibility to translate this the the correct technical terms and implementation has to lie with others. After evaluating available options, we concluded the GTK frontend has to be signaled from the external (by kbd-chooser or whatever), when DirectFB's keymap has to be updated, and that the keymap reloading call has to be performed directly by the GTK frontend. In my vision, the code inside the GTK frontend implementing the mechanism will be compiled out unless DI_UDEB is defined, so that it remains compatible with X environments when cdebconf is used as a debconf replacement. We must decide anyway how kbd-chooser and the GTK frontend should communicate (although it's one-way signaling, from kbd-chooser to the GTK frontend). Options are 1) by mean of a debconf question (debconf abuse?) 2) by mean of a named pipe or a socket (probably the simplest option) 3) by mean of a special question type the GTK frontend handles from within a plugin. In the latter case, we could move all the DirectFB specific code currently embedded in the frontend into a separate plugin, which can be disabled when building aganst X11 targets. Of course i can take care of the GTK frontend-side implementation of the mechanism. Any other option ? regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reworking the GTK+ cdebconf frontend
Attilio Fiandrotti wrote: Frans Pop wrote: On Monday 02 July 2007 09:34, Attilio Fiandrotti wrote: A reasonable improvement over current situation could prbably be setting TRUE a boolean d-i/keymap_changed question from within the keymap-chooser everytime the console keymap is updated. This could be an option, but using debconf for this is probably not the correct solution (debconf abuse). Couldn't the frontend listen on a named pipe for keyboard change triggers, or something like that? kbd-chooser could then check if that pipe exists and write something to that to indicate a keymap change. Note that as we intend to switch to console-setup, that would have to be made to support this mechanism too. Disclaimer: as this is totally outside my scope, the responsibility to translate this the the correct technical terms and implementation has to lie with others. After evaluating available options, we concluded the GTK frontend has to be signaled from the external (by kbd-chooser or whatever), when DirectFB's keymap has to be updated, and that the keymap reloading call has to be performed directly by the GTK frontend. In my vision, the code inside the GTK frontend implementing the mechanism will be compiled out unless DI_UDEB is defined, so that it remains compatible with X environments when cdebconf is used as a debconf replacement. We must decide anyway how kbd-chooser and the GTK frontend should communicate (although it's one-way signaling, from kbd-chooser to the GTK frontend). Options are 1) by mean of a debconf question (debconf abuse?) 2) by mean of a named pipe or a socket (probably the simplest option) 3) by mean of a special question type the GTK frontend handles from within a plugin. 4) As suggested by Jeremy on IRC, reading d-i/keymap while keeping track of last known value and looking for changes. This is, IMHO, the easiest solution available ATM, and morover doesn't require touching other parts of the installer than the GTK frontend and avoids dealing with pipes. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402127: Can we depend on --enable-d-i configure option to enable keymap reloading in g-i ?
Colin Watson wrote: On Thu, Jun 28, 2007 at 11:13:10AM +0200, Attilio Fiandrotti wrote: With gtk+ 2.10.13 from debian archives, the GDK_WINDOWING_DIRECTFB is still not defined (while it is when building gtk/dfb from sources), hence we cannot depend on it to enable at compile time the code (whatever it is) that performs keymap reloading. So i wonder if we can set a proper define when --enable-d-i configuration switch is used (which, i guess, is turned on when building for the d-i), It is, yes. and depend on it to compile in keymap reloading and possibily other d-i specific options in the GTK frontend. Any opinion on this? I think that's reasonable. Basing on answers from Colin and Loic, I've applied a patch (r47807) which compiles in DirectFB specific code only if DI_UDEB was set at compile time. This is a first step in having cdebconf building against gtk/x11 too, but is not enough, so i'm leaving this bug open. Infact, in the GTK frontend's Makefile we always take compiler and linker flags from gtk+-directfb-2.0 package, and this always results in a gtk/dfb build of the frontend. So, we lack a clean way to get a gtk/x11 build of cdebconf's GTK frontend, which is required if someday cdebconf is going to replace debconf. I think the frontend should be built against gtk/x11 by default, unless the --enable-di flag is set: to achieve this, the proper pkg-config's package should be called basing on the flag. This would allow easy locale cdebconf building, testing and deployment in an x11 environment. I'd like to hear oter people's opinion on this idea. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build failures on some images. Grarphical installer related?
Christian Perrier wrote: This happened last night on my system: The following packages have unmet dependencies: cdebconf-gtk-udeb: Depends: libcairo2 (= 1.4.0) but it is not installable The same goes for all images that includes the graphical installer. The floopy and netboot images build fine. It may be local to my system, but I'd recommend some attention , at least. Same happens here.. but shouldn't we depend on libcairo-directfb2 instead (libcairo2 is the X11 verion of Cairo) ? regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reworking the GTK+ cdebconf frontend
Colin Watson wrote: On Thu, Jun 21, 2007 at 03:35:09PM +0200, Attilio Fiandrotti wrote: * r47575 - There are plans for having cdebconf replacing debconf someday, this means the gtk frontend should build against gtk/x11 too [1]. Including more directfb private includes files goes the oppposite way, so this change is wrong. Attilio, the includes go with the function calls. Either you have both private dfb_* function calls and private directfb includes, or you have neither. You can't have it both ways! If you want it to build against GTK/X11, use ifdefs around both the includes and the function calls. Current cdebconf warns: /home/cjwatson/d-i/packages/cdebconf/src/modules/frontend/gtk/gtk.c: In function ‘gtk_go’: /home/cjwatson/d-i/packages/cdebconf/src/modules/frontend/gtk/gtk.c:1475: warning: implicit declaration of function ‘dfb_input_device_reload_keymap’ /home/cjwatson/d-i/packages/cdebconf/src/modules/frontend/gtk/gtk.c:1475: warning: implicit declaration of function ‘dfb_input_device_at’ ... and this is unambiguously a bug, no matter how it gets fixed. I've been thinking a lot in the past about the optimal way to implement keymap reloading in g-i. The cleanest solution would probably be delegating keymap reloading (acually, the calling of dfb_input_device_reload_keymap() ) to an external application, called by the a debconf client only when needed, and not by the frontend. This was stated being impossible because our directfb libraries, IIRC, are built without the multiapp support (and we neither have the fusion module packaged). So, the keymap reloading function has to be called by the cdebconf process. Because keymap reloading may be a common issue for other gtk/dfb based apps, i think a reasonable way to proceed is adding a gdk_directfb_keymap_reload() function to the directfb gdk backend (other directfb specialized functions already exist in that backend, like gdk_directfb_window_set_opacity() etc.. ) This would save us from including directfb's header files from the GTK frontend and directly calling directfb functions from within it. I could propose a patch and apply it upstream, but i'd like to hear an opinion from our gtk/dfb maintiner: Loic, what's your opinion on this issue? regards Attilio ps Still, this wouldn't allow building the gtk frontend against gtk/x11 (#402127), which is a different bug which should be fixed apart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402127: Can we depend on --enable-d-i configure option to enable keymap reloading in g-i ?
Hi With gtk+ 2.10.13 from debian archives, the GDK_WINDOWING_DIRECTFB is still not defined (while it is when building gtk/dfb from sources), hence we cannot depend on it to enable at compile time the code (whatever it is) that performs keymap reloading. So i wonder if we can set a proper define when --enable-d-i configuration switch is used (which, i guess, is turned on when building for the d-i), and depend on it to compile in keymap reloading and possibily other d-i specific options in the GTK frontend. Any opinion on this? regards Attilio Fiandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409412: Can this bug still be reproduced?
Hi Lior I'd like to know if this bug is still reproducible with a daily build [1] which is based on the recent 2.10.13 GTK+ version, which among the many bugfixes it provides, may also have fixed this specific one. thanks Attilio [1] http://people.debian.org/~joeyh/d-i/images/daily/gtk-miniiso/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427657: #427657 is fixed in cdebconf 0.117
tags 427657 pending thanks This bug was fixed in cdebconf 0.117 regards Attilio Fiandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reworking the GTK+ cdebconf frontend
Jérémy Bobbio wrote: On Thu, Jun 21, 2007 at 03:35:09PM +0200, Attilio Fiandrotti wrote: I must evantually say i'm disappointed of the way the gtk frontend code was nonchalantly modified, without any patch being posted and discussed on d-boot previously, moreover proving to ignore many design decisions behind the whole g-i. Because of all the above reasons, i'd like to revert the gtk frontend to r47287 ASAP. My initial plan was to work on the code alone until I would be satisfied with it and then only to submit it for inclusion. Colin told me that it would be better if I would rather do more incremental changes that could be more easily reviewed. I then followed his advice and started to commit incremental changes in the repository. What I have done yet is only a first step in a process. I basically wanted to have a better view on the code to be able to refactor it. It's currently underdocumented, so I wanted to get things clearer in the first place. This meant expanding variable definitions and adding a lot of comments all over the code. And yes, this made the code longer, but that's only a first step to be sure that I would not loose any subtitlities during the refactoring step. I felt a general consensus here, in Edinburgh, from most people involved in the debian-installer, that such improvement of the code base would be more than welcome. I also felt that they were trusting my intents and my abilities to improve the code. I know how much time you have actually spent on that code, and I fully appreciate it. If you don't trust me, well... I might just go on with my initial idea and submit a huge diff at the end. In any case, please give me more time before rejecting my contributions straight away. I see you reverted recents modifications you made to the gtk frontend, thanks for doing so: aAs i said before, i think modifications introduces in 47578 and 47611 are ok, so no problem for me in reapplying again without further delays. G-I is a complex project that many and many people contributed to over time and new contributore are not only welcome, but also needed, so welcome aboard :) If you look at cdebconf-gtk-udeb [1] bugs page, you'll see a list of open issues regarding the g-i. Since it looks to me you're interesting in adding new functionalities to the g-i, here is a resume of the most implementative still open issues -Adding a grahical partitioner to the g-i: oswald xavier started porting gparted, C++ written, to plain C; a good codebase already exists, but the project is currently halted -Adding a graphical terminal to the g-i: (see [2]) ATM possible options are VTE, ZVT and DFBterm -Moving specialized handlers for countrychooser out of the GTK frontend, into an appropriate plugin (this requires, i think, also rewriting of related debconf clients) -Developing a better handler for language chooser, pherhaps as a plugin, as right now localized languages names are displayed unaligned vertically [3] regards Attilio [1] http://svn.debian.org/wsvn/d-i/trunk/packages/cdebconf/src/modules/frontend/gtk/gtk.c?op=diffrev=47611sc=1 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339855 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401715 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reworking the GTK+ cdebconf frontend
Jérémy Bobbio wrote: On Thu, Jun 21, 2007 at 03:35:09PM +0200, Attilio Fiandrotti wrote: I must evantually say i'm disappointed of the way the gtk frontend code was nonchalantly modified, without any patch being posted and discussed on d-boot previously, moreover proving to ignore many design decisions behind the whole g-i. Because of all the above reasons, i'd like to revert the gtk frontend to r47287 ASAP. My initial plan was to work on the code alone until I would be satisfied with it and then only to submit it for inclusion. Colin told me that it would be better if I would rather do more incremental changes that could be more easily reviewed. I then followed his advice and started to commit incremental changes in the repository. What I have done yet is only a first step in a process. I basically wanted to have a better view on the code to be able to refactor it. It's currently underdocumented, so I wanted to get things clearer in the first place. This meant expanding variable definitions and adding a lot of comments all over the code. And yes, this made the code longer, but that's only a first step to be sure that I would not loose any subtitlities during the refactoring step. I felt a general consensus here, in Edinburgh, from most people involved in the debian-installer, that such improvement of the code base would be more than welcome. I also felt that they were trusting my intents and my abilities to improve the code. I know how much time you have actually spent on that code, and I fully appreciate it. If you don't trust me, well... I might just go on with my initial idea and submit a huge diff at the end. In any case, please give me more time before rejecting my contributions straight away. I see you reverted recents modifications you made to the gtk frontend, thanks for doing so: aAs i said before, i think modifications introduces in 47578 and 47611 are ok, so no problem for me in reapplying again without further delays. G-I is a complex project that many and many people contributed to over time and new contributore are not only welcome, but also needed, so welcome aboard :) If you look at cdebconf-gtk-udeb [1] bugs page, you'll see a list of open issues regarding the g-i. Since it looks to me you're interesting in adding new functionalities to the g-i, here is a resume of the most implementative still open issues -Adding a grahical partitioner to the g-i: oswald xavier started porting gparted, C++ written, to plain C; a good codebase already exists, but the project is currently halted -Adding a graphical terminal to the g-i: (see [2]) ATM possible options are VTE, ZVT and DFBterm -Moving specialized handlers for countrychooser out of the GTK frontend, into an appropriate plugin (this requires, i think, also rewriting of related debconf clients) -Developing a better handler for language chooser, pherhaps as a plugin, as right now localized languages names are displayed unaligned vertically [3] regards Attilio [1] http://svn.debian.org/wsvn/d-i/trunk/packages/cdebconf/src/modules/frontend/gtk/gtk.c?op=diffrev=47611sc=1 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339855 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401715 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reworking the GTK+ cdebconf frontend
Jérémy Bobbio wrote: On Thu, Jun 21, 2007 at 03:35:09PM +0200, Attilio Fiandrotti wrote: I must evantually say i'm disappointed of the way the gtk frontend code was nonchalantly modified, without any patch being posted and discussed on d-boot previously, moreover proving to ignore many design decisions behind the whole g-i. Because of all the above reasons, i'd like to revert the gtk frontend to r47287 ASAP. My initial plan was to work on the code alone until I would be satisfied with it and then only to submit it for inclusion. Colin told me that it would be better if I would rather do more incremental changes that could be more easily reviewed. I then followed his advice and started to commit incremental changes in the repository. What I have done yet is only a first step in a process. I basically wanted to have a better view on the code to be able to refactor it. It's currently underdocumented, so I wanted to get things clearer in the first place. This meant expanding variable definitions and adding a lot of comments all over the code. And yes, this made the code longer, but that's only a first step to be sure that I would not loose any subtitlities during the refactoring step. I felt a general consensus here, in Edinburgh, from most people involved in the debian-installer, that such improvement of the code base would be more than welcome. I also felt that they were trusting my intents and my abilities to improve the code. I know how much time you have actually spent on that code, and I fully appreciate it. If you don't trust me, well... I might just go on with my initial idea and submit a huge diff at the end. In any case, please give me more time before rejecting my contributions straight away. Apropos of the changes you brought to the sourcecode (the one where you added comments all over the code specifically), i already expressed my opinion: i believe they don't bring any substantial benefit, overcomplicate it and don't take into account existing issues. I understand GTK+'s API may look complex to newbies, so adding comments aboout GTK's API may seem a good idea initially, but in the long term perspective all those obvious commentings will turn into a burden for sourcecode manageability. IMHO, what *really* needs to be documented are cdebconf's internals (data structures, frontend/db implementation..): i still remember my initial difficulties in working on the GTK frontend were not related to the GTK API, which is well documented, but rather to the understanding of how cdebconf is structured and works internally, which i had to understand by myself. Apropos of the way of performing commits, after the g-i became part of official builds i became very prudent about committing huge changes to the sourcecode. If you look into last months d-boot archives, you'll see that i usually discuss patches on list before committing, and you'll also see the same do all other people working on the g-i: because the d-i is a community project, i think posting-before-commiting is the correct way of proceeding. You did warn the ml about your intentions about refactoring the GTK frontend in the next 2-3 days, but your mail dates 20/06/2007 18:55 and your first commit 2007-06-20 21:31:37 (just a few hours later), practically leaving no time for replies: using an euphemism, i consider this behaviour unfair. I'd like you to respect the simple post-before-committing and discuss with the d-boot team further changes before they take place. As anyone can see, i didn't rejected (reverted) anything, but rather expressed my doubts about your commits; still, my opinion is that commits 47577, 47580, 47591 have to be reverted, while 47587 and 47611 are ok. regards Attilio Fiandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [directfb-dev] GTK-DFB and libvte
Jérémy Bobbio wrote: Hi! As some of you might know, the debian-installer uses GTK+ on DirectFB as its front-end. We were thinking of adding an integrating terminal window to the graphical installation process. I have looked at libvte [1] which is part of GNOME libraries and can provide a terminal emulator in the form of a GtkWidget. [1] http://developer.gnome.org/doc/API/2.0/vte/ This library seems exactly what we need to add this feature to d-i. Unfortunately, it does not work correctly on the DirectFB backend of GTK+. After having hooking the integrated debugging of libvte, I know that the terminal itself fully works: the process is there, I can type commands and the resultings characters are processed by libvte. But I happen to see nothing on the screen except a black empty square. It's probably some incompatibilities between the way libvte displays characters on the screen and the DirectFB backend for GTK+. I would really like to get that issue fixed, but I don't have a clue about the process of debugging such issues. Maybe someone familiar with GTK-DFB could just look at libvte's code and figure out pretty quickly what is going wrong, which could be great. But I would also be dilligent to try to work out what's happening myself, but I won't be able to do so without some tips or pointers on how to do that. :) (CC'ing d-boot) Adding a graphical terminal to the GTK frontend is in the wishlist [1] from a long time. In the past i successfully managed to have libvte running on top of gdk/dfb, but two things discouraged me from going further this road 1) Adding libvte and related stuff to the installer requires some non negligible space in the ISO 2) Need to mantain over time patches to vte: we already maintain the directfb flavour of gtk and that's already complicated enough I know libzvt is somehow smaller than libvte, but IIRC it's not maintained from a long time and i'm not even sure it compiles against gtk-2.0 regards Attilio [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339855 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reworking the GTK+ cdebconf frontend
Jérémy Bobbio wrote: Hi! Just a short notice to tell everyone that I have started to work on improving the code of the GTK+ frontend for cdebconf. The whole frontend is currently in one huge single C file. I'm proofreading the whole thing for refactoring, memory leaks, potentiel segfauts, etc. This should keep me pretty busy during the next 2 or 3 days. The changes might be pretty invasive at the end, so this might result in a pretty huge patch at the end. :( Hi Jérémy I'd like to know What's the problem in having the gtk frontend in one single file: same is for newt and text frontends, are you planning a similar code refactoring for them too? regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reworking the GTK+ cdebconf frontend
Jérémy Bobbio wrote:
On Thu, Jun 21, 2007 at 10:39:24AM +0200, Attilio Fiandrotti wrote:
Jérémy Bobbio wrote:
The whole frontend is currently in one huge single C file. I'm
proofreading the whole thing for refactoring, memory leaks, potentiel
segfauts, etc.
I'd like to know What's the problem in having the gtk frontend in one
single file: same is for newt and text frontends, are you planning a
similar code refactoring for them too?
It might worth it as well. :)
I was currently interested into improving the GTK+ frontend codebase
because it seemed like the one the most likely to get improvements and
new features.
It's not a *real* problem to have everything in just one single 2500
lines long C file. But it's not what people usually call
maintainable. :)
Here's the statistics for the three frontend that were mentioned:
1347 newt/newt.c
923 text/text.c
2354 gtk/gtk.c(after my add of more lines to improve readability,
though)
GTK+ API is quite verbose and if we keep adding new debconf question
type to improve the installer usuability, it might just become really
too long to be humanly apprehendable. :)
Another improvement in spliting the current file to more separated
modules is to get more defined interfaces and area of concerns. In the
process of refactoring into more modules, you have to define clear
interfaces and the whole process really helps to improve code
readability (and add documentation).
I'd be happy to have a more lively discussion about all that on IRC if
you (or anyone else) are interested.
I've been looking at recent commits to cdebconf's gtk frontend, and my
comments are
* r47575
- There are plans for having cdebconf replacing debconf someday, this
means the gtk frontend should build against gtk/x11 too [1].
Including more directfb private includes files goes the oppposite way,
so this change is wrong.
- Text reformatting you performed to gtk.c makes it longer, althought
cleaner, so *less* readable.
* 47577
- Makefile got overcomplicated without any real need for that
- if (NULL != questionbox_scroll) { is unneded: if there are multiple
questions to display, that scrollbox cannot be NULL
- Same observation on text reformatting as above
* 47578
- #define'ing patch to icons is ok, but someday the may be read as
debconf questions, so this change may need to be reverted in the future
* 47580
- comments were added to almost any gtk_* function: those functions are
already well documented in gtk's API manuals, so there is absolutely no
need to add many and many times *the same* comment all over the file.
So, we have
[EMAIL PROTECTED] (before Lunar's changes) : 1779 lines (newt.c is ~1300)
[EMAIL PROTECTED] (after Lunar's changes) : 2354 lines
difference is +575 lines (~+33% of lines)
So, i don't think this means improving code readability at all,
especially because the comments you provided, as i said before, are on
the usage of gtk functions only, so completly useless.
One thing that *really* should be done is moving the
gtkhandler_select_single_tree() code to an appropriate plugin, and
modifying the debconf clients accordingly: this will reduce gtk.c of
~130 lines.
This will reduce gtk.c to ~1600 lines, only slightly bigger than newt.c,
so i don't think there is any real need to split it in multiple files.
I must evantually say i'm disappointed of the way the gtk frontend code
was nonchalantly modified, without any patch being posted and discussed
on d-boot previously, moreover proving to ignore many design decisions
behind the whole g-i.
Because of all the above reasons, i'd like to revert the gtk frontend to
r47287 ASAP.
regards
Attilio Fiandrotti
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A common Debian style for Debian Installer and the desktop
Frans Pop wrote: On Wednesday 13 June 2007 21:25, André Luiz Rodrigues Ferreira wrote: Can we prepare an other GTK theme, using other gtk2 engine? In theory, yes. But there are technical issues that need to be considered. For example, we partly ended up with the Clearlooks engine because it solved a bug with some display issues we were having. snip/ ... that was a bug in cairo's accelerated rectangle filling, which was workarounded by disabling that functionality in trunk of cairo (our directfb debian stable version udeb doesn't include the fix). If we fix the bug in debian packages, then we can switch back to libpixmap, if we desire so. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404482: Patch to remove the ugly cursor hack
Hi
As gtk+-directfb 2.10.13 (containing my upstream patched for the wrong
cursor shape issue) entered unstable, the workaround i provided in gtk
frontend is no longer necessary, so here is a patch to get us rid of it.
If no one notices regressions (and this shouldn't happen), i'm going to
commit the patch in trunk.
regards
Attilio
Index: cdebconf/src/modules/frontend/gtk/gtk.c
===
--- cdebconf/src/modules/frontend/gtk/gtk.c (revisione 47278)
+++ cdebconf/src/modules/frontend/gtk/gtk.c (copia locale)
@@ -86,8 +86,6 @@
static const char * get_text(struct frontend *obj, const char *template, const char *fallback );
-static int reset_cursor_cnt = 0;
-
void register_setter(void (*func)(void*, struct question*),
void *data, struct question *q, struct frontend *obj)
{
@@ -346,22 +344,7 @@
return FALSE;
}
-/* TODO: workaround for bug #404482
- * This is a workaround for a bug in gtk/dfb which causes wrong GDK crossing
- * events (not) to be delivered and hence cursor not to be reshaped when
- * entering or leaving a gtktextview or a gtkentry
- */
-static gboolean reset_cursor_callback (GtkWidget *widget, GdkEventExpose *event, void *data)
-{
-if (event-type == GDK_LEAVE_NOTIFY || event-type == GDK_ENTER_NOTIFY) {
-if ( (reset_cursor_cnt % 2) == 0)
-gdk_window_set_cursor (widget-window, NULL);
-reset_cursor_cnt++;
-}
-return FALSE;
-}
-
/* Scrolling to default row in SELECT questions has to be done after the
* treeview has been realized
*/
@@ -1436,7 +1419,6 @@
gtk_init (args, name);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
-g_signal_connect_after (G_OBJECT (window), event, G_CALLBACK (reset_cursor_callback), NULL);
gtk_widget_set_size_request (window, WINDOW_WIDTH, WINDOW_HEIGHT);
gtk_window_set_resizable (GTK_WINDOW (window), TRUE);
gtk_window_set_position (GTK_WINDOW (window), GTK_WIN_POS_CENTER);
Bug#404482: Patch to remove the ugly cursor hack
Frans Pop wrote: On Monday 18 June 2007 12:21, Attilio Fiandrotti wrote: If no one notices regressions (and this shouldn't happen), i'm going to commit the patch in trunk. Feel free to commit so it can be tested. Done: it's worth pointing out that the cursor is now expected to be I shaped when passing over a question's descripion, since that's the default behaviour for GtkTextView's. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#385074: virtual console switching doesn't work: this is still an issue
Holger Wansing wrote: On Wed, 13 Jun 2007 10:21:58 +0200 Attilio Fiandrotti wrote: This is #373253: as listed in the GuiToDo [1] wiki page, the solution is Hmm, #373253 is about amd64. I have an i386 machine with the same error. I think this worked with etch r0 here. yep, that's correct: after etch r0, something has changed in gcc and now libgcc.so.1 is required also by i386 images ( and possibly ppc ): i think the EXTRAFILES workaround should be applied to i386 and ppc in the etch branch of the installer (see my yesterday's reply to #427657) regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428749: G-I: Some graphical elements have lost their color
Frans Pop wrote: Package: cdebconf-gtk-udeb With current daily images, checkboxes and radio buttons are completely black. For etch, the checkmark in a checkbox and the center of the selected radio button did have a red color. Filing this report against cdebconf as I'm not sure what the cause of this regression is. As there have been no changes in the theme, I suspect that this is a change somewhere in Gnome, possibly in the Clearlooks engine. It may be a regression, but it could also be that we now need to explicitly set this color somewhere in the Clearlooks gtkrc file. I'm not sure that's the cause, but i see, in VT1, a lot of Clearlooks warnings like Clearlooks configuration option menuitemstyle is not supported and will be ignored. I think something has changed in gtkrc syntax and we may need to update our gtkrc files: pherhaps we should ask advice to debian-gnome guys? regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#385074: virtual console switching doesn't work: this is still an issue
Frans Pop wrote: On Thursday 14 June 2007 10:46, Attilio Fiandrotti wrote: yep, that's correct: after etch r0, something has changed in gcc and now libgcc.so.1 is required also by i386 images ( and possibly ppc ): i think the EXTRAFILES workaround should be applied to i386 and ppc in the etch branch of the installer (see my yesterday's reply to #427657) Why should it be applied in the Etch branch if the issue only affects daily images? Or am I missing something here? It has already been fixed for daily images. As i reported yesterday, i built a miniiso from the etch branch in svn and, everytime i switched to VTn, the installer crashed. The workaround was adding the EXTRAFILES=/lib/libgcc.so.1 to i386 configuration files in etch branch, like you previously did for the installer in trunk (and, infact, if you build from trunk, you won't get the crash at VT switch). Isn't the etch branch the one Etch next pointrelease is going to be taken ? regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#385074: virtual console switching doesn't work: this is still an issue
Attilio Fiandrotti wrote: Frans Pop wrote: On Thursday 14 June 2007 10:46, Attilio Fiandrotti wrote: yep, that's correct: after etch r0, something has changed in gcc and now libgcc.so.1 is required also by i386 images ( and possibly ppc ): i think the EXTRAFILES workaround should be applied to i386 and ppc in the etch branch of the installer (see my yesterday's reply to #427657) Why should it be applied in the Etch branch if the issue only affects daily images? Or am I missing something here? It has already been fixed for daily images. As i reported yesterday, i built a miniiso from the etch branch in svn and, everytime i switched to VTn, the installer crashed. The workaround was adding the EXTRAFILES=/lib/libgcc.so.1 to i386 configuration files in etch branch, like you previously did for the installer in trunk (and, infact, if you build from trunk, you won't get the crash at VT switch). Isn't the etch branch the one Etch next pointrelease is going to be taken ? One more thing: ihavent tested the g-i on PPC, but i suspect we may need to add the EXTRAFILES=/lib/libgcc.so.1 thing to PowerPc configuration files in both trunk and etch branch. It would be nice if someone could build from both trunk and etch branch and test on PPC and report whether the workaround is needed or not. thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#385074: virtual console switching doesn't work: this is still an issue
Frans Pop wrote: On Thursday 14 June 2007 12:15, Attilio Fiandrotti wrote: As i reported yesterday, i built a miniiso from the etch branch in svn and, everytime i switched to VTn, the installer crashed. That is completely crazy as nothing can have changed since the release for Etch. Did you build it in an Etch environment? I suspect you built it in either unstable or testing and then it would be expected, but completely irrelevant. Ah, that's the reason, then: i built the etch branch installer on an unstable host, so i must have taken udebs from unstable; thanks for making light on this and sorry for the noise. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385074: virtual console switching doesn't work: this is still an issue
reassign 385074 libdirectfb-0.9-25-udeb severity 385074 important merge 373253 385074 thanks Holger Wansing wrote: This still doesn't work. Shouldn't this be fixed? This is #373253: as listed in the GuiToDo [1] wiki page, the solution is providing libgcc1.so.1 via an appropriate udeb. regards Attilio [1] http://wiki.debian.org/DebianInstaller/GUIToDo#head-db957f996166c4f0f28b086ffa9e5d5db52779b6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427657: Processed: Re: Bug#427657: wrong keyboard at gui install
Holger Wansing wrote: Hi, On Thu, 07 Jun 2007 21:33:55 +0200 Attilio Fiandrotti wrote: I'm aware we had problems like that before, but we addressed them by switching to linux_input before. Moreover i wonder why this bug doesn't show up when booting with expertgui, as Holger reported. I'm sorry, I have to corrrect myself: some more investigation has shown, that the expertgui boot method wasn't the reason for the keymap beeing ok, but another queery thing: When you try to switch to another terminal (with Ctrl-Alt-Fx), this doesn't work (I have already reported this), but after the failed attempt the keymap is correct! Huh? Holger, you said switching to a different VT (with Ctrl-Alt-Fx) this doesn't work, right ? but was this tested on i386 or x86 ? In the latter case, that's a known issue, but i never heard f vt switching broken on i386. Could you please specify which architecture you're referring to? thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427657: Processed: Re: Bug#427657: wrong keyboard at gui install
Frans Pop wrote: On Wednesday 13 June 2007 10:27, Attilio Fiandrotti wrote: Holger, you said switching to a different VT (with Ctrl-Alt-Fx) this doesn't work, right ? but was this tested on i386 or x86 ? s/x86/amd64/ Indeed, i was menaing amd64, not x86, sorry.. In the latter case, that's a known issue, but i never heard f vt switching broken on i386. It was broken on i386 this time. I have just checked and the same workaround we already had for in place for amd64 is now also required for i386. I have committed the necessary changes. It would be nice if somebody could check if it is needed for powerpc as well. So, i assume something has changed after etch release which requires libgcc on i386 too, right? The German keyboard issue is unrelated. With VT switching fixed I have been able to check that the keyboard _is_ correct in the shell on VT2 and VT3, so it looks like the keymap reloading for directfb is broken somehow. If I check VT1, the messages about keymap reloading are indeed missing; these messages are displayed if I test with an Etch image. Attilio: it would be great if you could look into this. So, again something has changed after etch release, which now prevents keyboard reloading (which instead worked in etch) from working: any clue about what it may be ? regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427657: Processed: Re: Bug#427657: wrong keyboard at gui install
tags 427657 patch retitle 427657 Crash at VT switch in Etch and keymap not reloaded in Lenny thanks Frans Pop wrote: On Wednesday 13 June 2007 13:22, Attilio Fiandrotti wrote: So, i assume something has changed after etch release which requires libgcc on i386 too, right? Yes. No idea exactly what, but I suspect gcc. directfb itself has had an upload after Etch, but that included only minor changes. I doubt it is really worthwhile to investigate exactly what changed. The German keyboard issue is unrelated. So, again something has changed after etch release, which now prevents keyboard reloading (which instead worked in etch) from working: any clue about what it may be ? Nope. It is nothing in D-I itself. directfb seems unlikely too. This one is all yours. I built to i386 installers (build_netboot_gtk target) from svn trunk and etch branch, patching both the vt crash and the keymap bugs, see below regards Attilio 1) *Etch installer* - Keymap bug is not reproducible (italian keymap works perfectly) - VT crash bug is reproducible, the patch consists in providing libgcc.so.1 via EXTRAFILES, like we did for amd64 previously (i suspect also PPC may need this workaround) 2) *Lenny installer* - Keymap bug is reproducible: because in lenny we use gtk 2.10.x (2.8.x is instead used in etch) and GDK_WINDOWING_DIRECTFB is not defined, and because of the #ifdef's i removed in the attached patch, the code which reloads the keymap is no longer built into the gtk frontend, which consequently doesn't reload the keymap. The attached patch should be commited in trunk only. -VT crash bug is not reproducible because libgcc is already provided in lenny installer by some udeb Index: cdebconf/src/modules/frontend/gtk/gtk.c === --- cdebconf/src/modules/frontend/gtk/gtk.c (revisione 47245) +++ cdebconf/src/modules/frontend/gtk/gtk.c (copia locale) @@ -49,13 +49,7 @@ #include debian-installer/slist.h #include gdk/gdkkeysyms.h -#if GTK_CHECK_VERSION(2,10,0) -#ifdef GDK_WINDOWING_DIRECTFB #include directfb.h -#endif -#else -#include directfb.h -#endif #define WINDOW_WIDTH 800 #define WINDOW_HEIGHT 600 @@ -1493,14 +1487,7 @@ * 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();
Bug#427657: Processed: Re: Bug#427657: wrong keyboard at gui install
Frans Pop wrote: On Wednesday 13 June 2007 16:16, Attilio Fiandrotti wrote: 2) *Lenny installer* - Keymap bug is reproducible: because in lenny we use gtk 2.10.x (2.8.x is instead used in etch) and GDK_WINDOWING_DIRECTFB is not defined Great. I'll commit the patch and upload. ok -VT crash bug is not reproducible because libgcc is already provided in lenny installer by some udeb No, that is not correct. I added the EXTRAFILES workaround for i386 too. It is currently not provided by a udeb. ah ok, i didn't know that, but do you confirm now also etch needs the EXTRAFILES workaround for i386 (and possibly powerpc) too? Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427657: Processed: Re: Bug#427657: wrong keyboard at gui install
Christian Perrier wrote: reassign 427657 cdebconf-gtk-udeb thanks I just reproduced that bug with g-i but I can't reproduce it with D-I. It is not limited to the german keymap. The same hapens with the French one. I'm aware we had problems like that before, but we addressed them by switching to linux_input before. Moreover i wonder why this bug doesn't show up when booting with expertgui, as Holger reported. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processed: Re: Bug#427657: wrong keyboard at gui install
Christian Perrier ha scritto: Quoting Debian Bug Tracking System ([EMAIL PROTECTED]): Processing commands for [EMAIL PROTECTED]: reassign 427657 console-data Bug#427657: wrong keyboard at gui install Bug reassigned from package `kbd-chooser' to `console-data'. Well, given that the keymap seems to be properly loaded and used with the text installer but not the graphical one, I wonder whether the bug really belongs to console-data. If this bug is not reproducible with the NEWT frontend, then i guess it belongs to cdebconf-gtk-udeb. We had a report in the past about a wrong german keymap, but in that case, IIRC, the user was unaware he was using the standard german keyboard instead of the swiss flavour he really wanted (or something like that). Exactly, what's the xx_yy keymap which is broken? thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426745: cdebconf-gtk-udeb: Reduce the usage of casting to struct frontend_data
As i said before, this patch looks harmless to me, so no problem for me
in applying it.
regards
Attilio
Otavio Salvador ha scritto:
Package: cdebconf
Severity: wishlist
Tags: patch
Reduce the usage of casting to struct frontend_data
From: Otavio Salvador [EMAIL PROTECTED]
Use a local variable to avoid casting when possible. This makes the
code easier to read.
Signed-off-by: Otavio Salvador [EMAIL PROTECTED]
---
packages/cdebconf/src/modules/frontend/gtk/gtk.c | 25 +++---
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/packages/cdebconf/src/modules/frontend/gtk/gtk.c
b/packages/cdebconf/src/modules/frontend/gtk/gtk.c
index 59a6135..9ea2928 100644
--- a/packages/cdebconf/src/modules/frontend/gtk/gtk.c
+++ b/packages/cdebconf/src/modules/frontend/gtk/gtk.c
@@ -98,13 +98,14 @@ void register_setter(void (*func)(void*, struct question*),
void *data, struct question *q, struct frontend *obj)
{
struct setter_struct *s;
+struct frontend_data *frontend_data = obj-data;
s = malloc(sizeof(struct setter_struct));
s-func = func;
s-data = data;
s-q = q;
-s-next = ((struct frontend_data*)obj-data)-setters;
-((struct frontend_data*)obj-data)-setters = s;
+s-next = frontend_data-setters;
+frontend_data-setters = s;
}
void free_description_data( GtkObject *obj, struct frontend_question_data* data )
@@ -1279,6 +1280,7 @@ void set_design_elements(struct frontend *obj, GtkWidget
*window)
GtkWidget *label_title, *h_title_box, *v_title_box, *logo_button;
GList *focus_chain = NULL;
int *ret_val;
+struct frontend_data *data = obj-data;
/* A logo is displayed in the upper area of the screen */
logo_button =
gtk_image_new_from_file(/usr/share/graphics/logo_debian.png);
@@ -1287,7 +1289,7 @@ void set_design_elements(struct frontend *obj, GtkWidget
*window)
/* A label is used to display the fontend's title */
label_title = gtk_label_new(NULL);
gtk_misc_set_alignment (GTK_MISC (label_title), 0, 0);
-((struct frontend_data*) obj-data)-title = label_title;
+data-title = label_title;
h_title_box = gtk_hbox_new (TRUE, 0);
gtk_box_pack_start(GTK_BOX (h_title_box), label_title, TRUE, TRUE,
DEFAULT_PADDING);
v_title_box = gtk_vbox_new (TRUE, 0);
@@ -1295,7 +1297,7 @@ void set_design_elements(struct frontend *obj, GtkWidget
*window)
/* This is the box were question(s) will be displayed */
targetbox = gtk_vbox_new (FALSE, 0);
-((struct frontend_data*) obj-data)-target_box = targetbox;
+data-target_box = targetbox;
actionbox = gtk_hbutton_box_new();
h_actionbox = gtk_hbox_new(FALSE, 0);
@@ -1307,7 +1309,7 @@ void set_design_elements(struct frontend *obj, GtkWidget
*window)
button_screenshot = gtk_button_new_with_label (get_text(obj,
debconf/gtk-button-screenshot, Screenshot));
g_signal_connect (G_OBJECT (button_screenshot), clicked, G_CALLBACK
(screenshot_button_callback), obj );
gtk_box_pack_start (GTK_BOX(actionbox), button_screenshot, TRUE, TRUE,
DEFAULT_PADDING);
-((struct frontend_data*) obj-data)-button_screenshot = button_screenshot;
+data-button_screenshot = button_screenshot;
gtk_widget_set_sensitive (button_screenshot, FALSE);
/* Here are the back and forward buttons */
@@ -1328,8 +1330,8 @@ void set_design_elements(struct frontend *obj, GtkWidget
*window)
gtk_box_pack_start (GTK_BOX(actionbox), button_next, TRUE, TRUE,
DEFAULT_PADDING);
GTK_WIDGET_SET_FLAGS (button_next, GTK_CAN_DEFAULT);
-((struct frontend_data*) obj-data)-button_prev = button_prev;
-((struct frontend_data*) obj-data)-button_next = button_next;
+data-button_prev = button_prev;
+data-button_next = button_next;
gtk_widget_set_sensitive (button_prev, FALSE);
gtk_widget_set_sensitive (button_next, FALSE);
@@ -1341,7 +1343,7 @@ void set_design_elements(struct frontend *obj, GtkWidget *window)
g_signal_connect (G_OBJECT(button_cancel), clicked,
G_CALLBACK(cancel_button_callback), obj);
gtk_box_pack_start (GTK_BOX(actionbox), button_cancel, TRUE, TRUE,
DEFAULT_PADDING);
-((struct frontend_data*) obj-data)-button_cancel = button_cancel;
+data-button_cancel = button_cancel;
gtk_widget_set_sensitive (button_cancel, FALSE);
/* focus order inside actionbox */
@@ -1396,7 +1398,7 @@ void *eventhandler_thread()
static int gtk_initialize(struct frontend *obj, struct configuration *conf)
{
-struct frontend_data *fe_data;
+struct frontend_data *fe_data = obj-data;
GtkWidget *window;
GThread *thread_events_listener;
GError *err_events_listener = NULL ;
@@ -1408,13 +1410,12 @@ static int gtk_initialize(struct frontend *obj, struct
configuration *conf)
name[1] = NULL;
/* INFO(INFO_DEBUG, GTK_DI - gtk_initialize() called); */
-obj-data = NEW(struct frontend_data);
Re: questions regarding debian gui installer cutomization.
Anant Shrivastava ha scritto: hello everyone, i am anant shrivastava, a new member of this list, my company was working on developing an internal distro derived from RH earlier, but with the release of Debian 4.0 i am able to convince the administration on using Debian. now we are facing with few problems, 1) they want some changes in the installation process 2) regarding downloads of updates as far as updates download is concerned i have came to one solution i am downloading packages on one PC and then using apt-move created http/ ftp repo for updation for internal usage. is there any other option also i have to manually add the http and ftp details to each pc, is any workaround possible. now comes the big part, they want a lot of changes in GUI, well when i looked at the steps they are a lot exploded, i mean to say like initially we have to choose a language and then based on language we can workout the country, what i was thinking of was that is it possible to implement combo box / drop down menu style function so that they get a list of languages in a combo box and as soon as they select the language they get the next combo box custom filled as per their language preference if any one can help me in this matter, i am very thankful in advance. also please give details considering that i am just 3months old for Debian. The cdebconf protocol allows you to display multiple questions at once, and the GTK frontend supports this functionality. When more than a question is displayed in the same window, SELECT questions are displayed as pulldown combo boxes instead of scrollable lits But you cannot change a question's default value as soon as another question is changed in value. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Preliminary success reported in fixing this bug
Hi Yesterday Luca Suriano managed to rebuild directfb-0.9.25 applying Ville's patch for linux_input module on his power mac and reported a preliminary success by copying on the fly the new input driver in the g-i environment. Luca is now trying to building a custom gtk-miniiso including the patched directfb udeb to allow wider testing of Ville's patch. If the patch should prove to be definitively ok, then we'll be able to drop a lot of startup scripts in rootskel :) The gtk-miniiso seems to be anyway broken [1] because of the libc dependancy, so i guess he has to defer building until that's fixed, is this correct? Attilio http://people.debian.org/~wouter/d-i/powerpc/daily/build_powerpc_netboot-gtk.log ps many thanks to Luca, who also helped me many times in past in debugging the g-i on powerpc! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preliminary success reported in fixing this bug
Otavio Salvador ha scritto: Attilio Fiandrotti [EMAIL PROTECTED] writes: The gtk-miniiso seems to be anyway broken [1] because of the libc dependancy, so i guess he has to defer building until that's fixed, is this correct? Looks like it was fixed on yestarday dak's pulse on a Bastian's mklibs upload. Alright, i'll try again later, but anyway installer from etch branch builds, so i told luca to use that for the short term tests, it should do anyay for our purpose thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: usplash in desktop task?
David Härdeman ha scritto: On Tue, May 08, 2007 at 10:24:01PM +0200, Attilio Fiandrotti wrote: Otavio Salvador ha scritto: Joey Hess [EMAIL PROTECTED] writes: My standpoint is that installing (or at least activating) splashy should only be done if it is *known* beforehand that the display will be correct. usplash uses bogl, same as d-i, so if d-i worked in framebuffer mode, I'll bet that usplash will also work. Until I see a system where it doesn't anyway. :-) Systems installed using g-i also seem likely to support usplash. AFAIK g-i uses dfb and on this case splashy would work ;-) If usplash uses bogl and bogl uses framebuffer, then usplash will work almost anywhere g-i does. It wont't work on i386 and amd64 systems where the video chip is not supported by vesafb (see #405737). AFAIK, usplash has two backends, svgalib and bogl...and I believe that usplash works with both vesafb and vga16fb as well as chipset-specific fb drivers... iirc, we have vga16fb always up, even if vesafb is not, so if you can make usplash run on vga16fb only, there should be no problem on x86. Infact, iirc, vga16fb is much more compatible than vesafb. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415127: installation-report: Graphical install does not work on Apple MacBook
Davide Viti ha scritto: Very recently a patch [1] was pushed upstream in directfb, which is supposed to fix a similar crash on ppc (#422146), again due to linux_input. If you have time, could you please try rebuilding directfb udeb with Ville's patch and rebuild a gtkminiiso for testing? I've tried an iso image using a custom udeb with that patch (without booting with newt and changing directfbrc): it hangs. Anything else I can try? any suggestion for debugging the problem? Could you please boot once again the custom iso and provide dfbinfo output again ? We should attach that to a mail to directfb-dev explaining the issue and asking for advice. I guess debugging linux_input on intel macs requires a db session in a standard debian environment Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415127: installation-report: Graphical install does not work on Apple MacBook
Davide Viti ha scritto: snip/ As suggested by Attilio, I then got the output of dfbinfo (attached to this message) which I hope will help identifying the root of the problem. snip/ (*) Direct/Modules: suppress module 'keyboard' (*) Direct/Modules: suppress module 'ps2mouse' (*) Direct/Thread: Running 'Linux Input' (INPUT, 6306)... I see we're using linux_input input module to handle mouse and keyboard, which is default for i386 and usually works well. To be sure linux_input is not broken on Intel Macs, could you pleas try to boot textual, then remove from /etc/directfb the two lines disabling keyboard and ps2mouse modules and instead disable linux_input module only ? If the crash should persist, we can at least say it's not because of linux_input module. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: usplash in desktop task?
Otavio Salvador ha scritto: Joey Hess [EMAIL PROTECTED] writes: My standpoint is that installing (or at least activating) splashy should only be done if it is *known* beforehand that the display will be correct. usplash uses bogl, same as d-i, so if d-i worked in framebuffer mode, I'll bet that usplash will also work. Until I see a system where it doesn't anyway. :-) Systems installed using g-i also seem likely to support usplash. AFAIK g-i uses dfb and on this case splashy would work ;-) If usplash uses bogl and bogl uses framebuffer, then usplash will work almost anywhere g-i does. It wont't work on i386 and amd64 systems where the video chip is not supported by vesafb (see #405737). In g-i we look in /proc/fb to detect a working vesa framebuffer, but this is done at a late stage of the boot process. regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415127: installation-report: Graphical install does not work on Apple MacBook
Davide Viti ha scritto: On Tue, May 08, 2007 at 10:18:47PM +0200, Attilio Fiandrotti wrote: Davide Viti ha scritto: snip/ As suggested by Attilio, I then got the output of dfbinfo (attached to this message) which I hope will help identifying the root of the problem. snip/ (*) Direct/Modules: suppress module 'keyboard' (*) Direct/Modules: suppress module 'ps2mouse' (*) Direct/Thread: Running 'Linux Input' (INPUT, 6306)... I see we're using linux_input input module to handle mouse and keyboard, which is default for i386 and usually works well. To be sure linux_input is not broken on Intel Macs, could you pleas try to boot textual, then remove from /etc/directfb the two lines disabling keyboard and ps2mouse modules and instead disable linux_input module only ? it worked (so the problem must be linux_input), and here's the output: snip/ ah, so linux_input strikes again! :( Very recently a patch [1] was pushed upstream in directfb, which is supposed to fix a similar crash on ppc (#422146), again due to linux_input. If you have time, could you please try rebuilding directfb udeb with Ville's patch and rebuild a gtkminiiso for testing? resolution for the seems wrong but that's another problem yes, that must be another issue, we may try to track it down later too ciao, Davide ciao Attilio [1] http://git.directfb.org/?p=core/DirectFB.git;a=commitdiff;h=47d97462a08240236683b4cc3aa77c66bd8ca241;hp=a7d95847288c8c490c4ea4d60e973e2838e5ac2c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Possible patch for linux_input crash on PowerPC available, testing is needed
Eddy Petrișor ha scritto: Attilio Fiandrotti wrote: snip The patch Ville applied upstream should be backported to dfb 0.9.25 and a test gtk-miniiso built to see whether this patch fixes the bug or not. Unluckily, i cannot do this test myself because i own no PPC hardware: so it would be nice if a PPC owner among those who reported a crash [1] with PPCs could perform this check and report results. Once at every two weeks I have access to the PowerBook I brought with me in January 2006 in Spain. Also, until Sunday, next week I will also have access to it. Please announce when everything is set for a test and provide an image and I will test. The problem is that i own no ppc hw to build the udeb and the iso, so i cannot produce anything to test Ville's patch [1] :( Is there any facility tool available for cross-compiling/building which doesn't require a complex setup before use? Attilio [1] http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=47d97462a08240236683b4cc3aa77c66bd8ca241 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [directfb-users] Problem with Czech keymap
clone 342053 -1 retitle -1 Input driver linux_input crashes on some PPC machines tags -1 upstream thanks Ville Syrjälä ha scritto: On Thu, May 03, 2007 at 11:25:34AM +0200, Attilio Fiandrotti wrote: Christian Schaubschlaeger ha scritto: You're right, i was confusing the deadkeys bug, which is gtkdfb related, with this other one, which is dfb related. Anyway, we never succeeded in addressing this specific issue :( I see. Are there any known workarounds for this? I guess I'm not the only one who wants to use keymaps other than us... I tried using linux_input as inputdriver instead of dfb-keyboard, but that does not help unfortunately. I've been working for a couple of years now with DFB inthe context of developing the graphical debian installer and, at current date, linux_input is the DFB component which is causing us most severe headaches. Most severe issue we found is linux_input crashing on some PPC machines [1], this force us to switch to keyboard and ps2mouse drivers depending on specific hardware, which adds complexity to the installer and prevents us from switching to an unique input driver for all i386, amd64 and ppc. BTW it would make sense to re-test the crash cases. Many ioctl arguments were incorrect. It was spotted by Sakur here: http://mail.directfb.org/pipermail/directfb-dev/2007-April/002961.html I pushed the fix some time ago: http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=47d97462a08240236683b4cc3aa77c66bd8ca241 I'm cloning bug 342053 to a specific bugreport about linux_input crashing on some PPC machines: i should have done this before to distinguish from the case a crash occours because of video hardware acceleration. The patch Ville applied upstream should be backported to dfb 0.9.25 and a test gtk-miniiso built to see whether this patch fixes the bug or not. Unluckily, i cannot do this test myself because i own no PPC hardware: so it would be nice if a PPC owner among those who reported a crash [1] with PPCs could perform this check and report results. regards Attilio [1] http://wiki.debian.org/DebianInstaller/GUIPowerPC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421323: Bug in Debian expertgui installer
highdruff ha scritto: Attilio Fiandrotti schrieb: highdruff ha scritto: Package: debian-installer Version: Etch 4.0r0 Hello If Debian Etch 4.0r0 installed from the official DVD (i386) with the bootparameter expertgui and then deactivate the root Account to use sudo there is a Bug in Gnome Menue. Whenever you will start an administrative application with Gnome Menue there comes an password Dialog and a error Message like this: Incorrect Password (but it is the right one) because the entry in Gnome Menue is e.g for start Synaptic gksu -u root /usr/sbin/synaptic but the right way is: gksudo -u root /usr/sbin/synaptic. Then the Application will start correctly and the wrong password Dialog is away. Does this bug shows up only with expertgui or also with expert boot option? thanks Attilio Both boot options expert and expertgui have it. cu Mathias ah ok, so that's not related to the gtk frontend, i guess this bug has to be reassigned to the belonging package (i don't know what it is). thanks attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421323: Bug in Debian expertgui installer
highdruff ha scritto: Package: debian-installer Version: Etch 4.0r0 Hello If Debian Etch 4.0r0 installed from the official DVD (i386) with the bootparameter expertgui and then deactivate the root Account to use sudo there is a Bug in Gnome Menue. Whenever you will start an administrative application with Gnome Menue there comes an password Dialog and a error Message like this: Incorrect Password (but it is the right one) because the entry in Gnome Menue is e.g for start Synaptic gksu -u root /usr/sbin/synaptic but the right way is: gksudo -u root /usr/sbin/synaptic. Then the Application will start correctly and the wrong password Dialog is away. Does this bug shows up only with expertgui or also with expert boot option? thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419352: Access with keyboard with installgui
Frans Pop ha scritto: On Wednesday 18 April 2007 09:47, Attilio Fiandrotti wrote: Using + and - to expand and collapse trees is GTK's default option. This is a problem which was raised some time ago too [1], since it's the second time this thing come up, i guess we must do something about it. That's fine by me, but please only allow space to toggle and _not_ enter, except perhaps if you can make it so that enter only has that function if the active line is a continent and still works to activate Continue if it is a country. Yes, of course Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer plans for the lenny cycle
Frans Pop ha scritto: On Tuesday 17 April 2007 21:06, Luk Claes wrote: We would like to know which major features are expected to be added in the next 24 months and how much time you expect them to need to get stable enough for a Debian stable release. An overview of the plans of the D-I team can be found at: http://wiki.debian.org/DebianInstaller/LennyGoals Most of this is incremental development and not earth-shattering change. Quite a few items are optional. ... One thing i started working on before Etch was released is cdebconf's web frontend [1]: basically it provides ability to perform remote graphical instalations once the network is set up. The frontend itself is complete, what needs to be done is adding authentications and ciphering mechanisms. All this can be done outside the cdebconf module, let's say in appropriate cgi scripts, so even by someone who's not really into cdebconf's internals but has knowldge of web servers, ssl, cgi. I would like to know if there is interest enough in this frontend to be considered a goal for Lenny, and if somone's willing to work on the authentication/security part. thanks Attilio [1] http://wiki.debian.org/DebianInstaller/WebInstaller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419352: Access with keyboard with installgui
reassign 419352 cdebconf-gtk-udeb severity minor thanks Dan Phillips ha scritto: Christian Perrier wrote: Quoting Dan Phillips ([EMAIL PROTECTED]): http://www.debian.org/releases/stable/i386/apds06.html.en Can I make a suggestion that or maybe a change request for use of space key or Enter key rather than + or - keys for expanding the options as referred to in the above document. I am not the first person to be fooled by this and most likely not the last. I do not believe using + and - is an intuitive way of using these menus and not everyone will read the Appendix Some people would laugh seeing me taking this example, but + is the common way to deploy a sublist in hierarchical menus in many graphical environments, including MS Windows (just try with en Explorer window on any Windows flavour). I just played around on a couple of applications and noticed that nautilus accepts this method, but then Thunar and Thunderbird does not. They prefer the space or return method. I didn't even think to use + and - when faced with that situation, although thinking back to when I worked for Microsoft I used it often, but this was a while ago now and with earlier versions of windows and file manager. I am guessing most people wouldn't know what to do here and would not try the + or -, I could be wrong, but that's my guess. No laughs here, just a few chuckles :) Using + and - to expand and collapse trees is GTK's default option. This is a problem which was raised some time ago too [1], since it's the second time this thing come up, i guess we must do something about it. regards Attilio [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382370 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415715: installation-report: installgui does not work with logitech mouse deluxe 650
reassign 415715 directfb tags 415715 upstream thanks A Mennucc ha scritto: Package: installation-reports Version: 2.29 Severity: important Boot method: CD Image version: http:http://cdimage.debian.org/cdimage/etch_di_rc2/amd64/iso-cd/debian-testing-amd64-netinst.iso Date: 21 march 2007 Machine: Intel Dual core due CPU, Intel MB I decided to give a try to the new gui installer; boot went OK and I was confronted with the language choice; but I could not operate the mouse properly. The mouse ( keyboard) is a wireless USB Logitech, named deluxe 650. Moving the mouse up and down would move the pointer up and down on screen, but moving it left and right did not move it left and right but rather scrolled the list of languages as crazy (it was as if left and right was remapped to the scrolling wheel!!) So I had to abort installation. :-( My suggestion: the GUI installer, as a first step, needs to check if the mouse is working OK. Here is a proposal: a small window is presented saying try moving the mouse around, and click on the nice CLICK ME button; hit enter on the keyboard when done; hit space if you cannot operate the mouse. At the same time a wonderful autodetect gizmo analyzes the USB and PS2 traffic and tries to detect and load the appropriate driver; and if it cannot, when the user hits space, a list of drivers is presented; (or otherwise, it is suggested that the user would use the no-GUI install). a. Hi Thanks for testing: at the moment it's the input devices handling part of directfb which seems to be weaker and be the cause of major problems (deadkeys, special characters, unrecognized input devices, crash on ppcs etc) I tink some directfb upstream work here is needed after etch release, and specifically i'd like to see linux_input not crashing anymore on PPCs. Attilio Fiandrotti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fan control OK on PowerMac8,1 (iMac G5)
Charles Plessy wrote: Le Wed, Mar 14, 2007 at 05:56:48PM +0530, Praveen A a écrit : 2007/3/14, Charles Plessy [EMAIL PROTECTED]: CD/DVD images are available from: http://www.debian.org/devel/debian-installer/ I would like to check if everything is OK on iMac G5, which image shall I use ? You can use either the daily-built (no full cd/dvd images only net install) or weekly built images. AFAIK both are based on RC2. Thank you all for your answers, everything went fine for a very minimal install ; my primary goal was to make sure that the problem with the loud fans was solved (PowerMac8,1 iMac G5). I used the daily netinst of yesterday (3dd2144e53255fe6ecf4273176c25107). I am not filing a bug report since I have to hurry up this morning. Also, I added a line in the table of the wiki page which lists the problems with the GTK installer on powermacs. Thanks a lot: your report confirms g-i is broken pn powerpc systems equipped with geforce 5200 boards, and this is bad because those videocards seem to be quite popular. We must first understand if this crash is specific to ppc only in order to fix it in post etch. It would be nice if someone owning that card could test the g-i on i386 or amd64. The board should be listed with someting like nVidia Corporation NV34M [GeForce FX Go5200] (rev a1) by lspci | grep VGA thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414190: cdebconf-gtk-udeb: Selected text for checkboxes dissapears.
Kurt Roeckx wrote: On Sat, Mar 10, 2007 at 05:13:10PM +0100, Attilio Fiandrotti wrote: We had some simiar issues in the past (it's a cairo-directfb bug) but we workarounded them by using a gtk theme engine. could you please provide a screenshot? Here are various screenshots of it. This is a well known bug in cairo-dfb (accelerated rect filling is broken, debs/udebs should be rebuilt without it), we workarounded it by using clearlooks engine, which obviously failed in your case. I think there are two options 1) you're using and outdated installer iso 2) for some strange reason, the clearlooks engine fails to start on your hardware could you please verify your ISO is not out of date? thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414190: cdebconf-gtk-udeb: Selected text for checkboxes dissapears.
Kurt Roeckx wrote: Package: cdebconf-gtk-udeb Version: 0.113 Hi, I was using the debian-testing-i386-kde-CD-1.iso from http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/ from 05-Mar-2007. I assume it has either version 0.113 or 0.114 of cdebconf-gtk-udeb in it, not sure. When I came to the point where xserver-xorg gets configured, it asks which resolutions you want to have. This is a list of checkboxes. When clicking on one of the lines the text seems to be dissapearing. I think it's changing the background so you know you clicked on it, but it doesn't put any text in it. You only get to see a little square. We had some simiar issues in the past (it's a cairo-directfb bug) but we workarounded them by using a gtk theme engine. could you please provide a screenshot? thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413538: G-I freezes on directfb initialization
Frans Pop wrote: On Thursday 08 March 2007 22:01, Attilio Fiandrotti wrote: Frans, can i proceed closing this bug or you want this bug to be renamed and ket open to be listed in the errata list or in the GUI post Etch TODO? I would not close it but ask dok to look into it to see if he wants to fix the bug that is obviously there in directfb. Ok, i'll properly retitle and reassign to directfb package. I already reported this bug upstream yesterday, but i think this will be a hard one because debugging would require owning the offending hardware. It's, more or less, the situation we're facing with some MacIntosh [1] laptopts, where linux-input module causes a crash: it's hard fixing that bug without owning the hardware. regards Attilio [1] http://wiki.debian.org/DebianInstaller/GUIToDo#head-fa668fd9c7b4c31a91f90019b6133be37ab31fda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413538: G-I freezes on directfb initialization
[EMAIL PROTECTED] wrote: On Monday 05 March 2007 13:45, Frans Pop wrote: snip/ Can you try booting the installer with 'installgui DEBIAN_FRONTEND=newt', switch to VT2 when the first dialog comes up [1] and then give us the output of the following commands: - cat /proc/bus/input/devices - ls -l /dev/input - dfbinfo Here's the output: /snip Input (00) AT Translated Set 2 keyboard(primary keyboard) Type: KEYBOARD Caps: KEYS Input (01) SynPS/2 Synaptics TouchPad (primary mouse) Type: MOUSE Caps: AXES BUTTONS Max. Axis: 1 Max. Button: 2 Input (10) USB tenkeypad Type: KEYBOARD Caps: KEYS Input (11) Logitech USB Receiver Type: MOUSE Caps: AXES BUTTONS Max. Axis: 3 Max. Button: 15 Input (12) TPPS/2 IBM TrackPoint Type: MOUSE Caps: AXES BUTTONS Max. Axis: 1 Max. Button: 2 Hope this helps. This may be a bug in the input handling subsystem of DFB, we already had a lot of preoblems with it in the past we fixed. In order to detect what's the input peripheral that causes DFB to crash, could you please try unplugging the numeric keypad and the wireless mouse receiver and see if the graphical installer still crashes? If the installer should still crash, is there a way to disable from bios the trackpoint and test again ? thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413538: G-I freezes on directfb initialization
[EMAIL PROTECTED] wrote: On Thursday 08 March 2007 11:56, you wrote: [EMAIL PROTECTED] wrote: On Monday 05 March 2007 13:45, Frans Pop wrote: snip/ Can you try booting the installer with 'installgui DEBIAN_FRONTEND=newt', switch to VT2 when the first dialog comes up [1] and then give us the output of the following commands: - cat /proc/bus/input/devices - ls -l /dev/input - dfbinfo Here's the output: /snip Input (00) AT Translated Set 2 keyboard(primary keyboard) Type: KEYBOARD Caps: KEYS Input (01) SynPS/2 Synaptics TouchPad (primary mouse) Type: MOUSE Caps: AXES BUTTONS Max. Axis: 1 Max. Button: 2 Input (10) USB tenkeypad Type: KEYBOARD Caps: KEYS Input (11) Logitech USB Receiver Type: MOUSE Caps: AXES BUTTONS Max. Axis: 3 Max. Button: 15 Input (12) TPPS/2 IBM TrackPoint Type: MOUSE Caps: AXES BUTTONS Max. Axis: 1 Max. Button: 2 Hope this helps. This may be a bug in the input handling subsystem of DFB, we already had a lot of preoblems with it in the past we fixed. In order to detect what's the input peripheral that causes DFB to crash, could you please try unplugging the numeric keypad and the wireless mouse receiver and see if the graphical installer still crashes? If the installer should still crash, is there a way to disable from bios the trackpoint and test again ? thanks Attilio I did as you asked and found the culprit. It's the external keypad: a Dynex Model No.: DX-NBKP20. $5.99 at BestBuy. It takes very little money to get into a lot of trouble. :) Better the keypad than the mice -- I'd think there would be comparatively fewer of these keypads in use. Thanks for the sleuthing and for making etch such a great release. I'm really happy this bug was workarounded. Frans, can i proceed closing this bug or you want this bug to be renamed and ket open to be listed in the errata list or in the GUI post Etch TODO? Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412124: installation-report: HP Compaq NX7400
Hermann Kraus wrote: snip/ Comments/Problems: HDD: GTK installer didn't work (failed to recognize hdd), however this seems to be a problem with my image, as it also failed on an other machine. Text based install worked very well. This is strange: the installer, and hence the hdd recognition code, is always the same, what changes is just the final interface (text or graphical). Anyone has an explanation for this? regards Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412124: installation-report: HP Compaq NX7400
Hermann Kraus wrote: On Sat, 24 Feb 2007 11:16:10 +0100, Attilio Fiandrotti [EMAIL PROTECTED] wrote: Hermann Kraus wrote: Comments/Problems: HDD: GTK installer didn't work (failed to recognize hdd), however this seems to be a problem with my image, as it also failed on an other machine. Text based install worked very well. This is strange: the installer, and hence the hdd recognition code, is always the same, what changes is just the final interface (text or graphical). Anyone has an explanation for this? I have some additional information about this problem: I tried this today on my other machine (Yakumo notebook) and took some screenshots (with my digital camera as I couldn't write to harddisk). While doing this I noticed something strange: After about 5 minutes of now activity suddenly the installer started. However I still was not able to mount the HDD. The messages were the same with the HP notebook, but I didn't want to try it here as I need this machine and didn't want to risk any problems here. dmesg (textbased installer) http://r2d2.stefanm.com/bootlog Messages where the boot process stalled (note the completely wrong size and disk geometry) The lost interrupt messages appeared about once per minute. http://r2d2.stefanm.com/pict0369_small.jpg Messages on console 1 after the installer finally started: http://r2d2.stefanm.com/pict0370_small.jpg Those pango warnings are no problem Complete dmesg output for the grapical installer: http://r2d2.stefanm.com/pict0373_small.jpg http://r2d2.stefanm.com/pict0374_small.jpg http://r2d2.stefanm.com/pict0375_small.jpg http://r2d2.stefanm.com/pict0376_small.jpg http://r2d2.stefanm.com/pict0377_small.jpg Bios messages: http://r2d2.stefanm.com/pict0378_small.jpg I hope this helps. Perhaps I find some free time to try the current image later on. i eventually believe this is not related with the GTK frontend :) Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
