Re: [RFC] Add support for shells in the graphical installer
On Wed, Jul 23, 2008 at 04:27:24PM +0200, Davide Viti wrote: On Tue, Jul 22, 2008 at 02:04:59AM +0200, J??r??my Bobbio wrote: On Sun, Jul 20, 2008 at 08:04:29PM +0200, Frans Pop wrote: That is still with the to-much-reduced font udeb, isn't it? Or did Davide already provide a new version for you? I have used the last one mentioned by Davide on the list, which is the too-much-reduced one, IIRC. I've prepared a new package […] Which I have used to produce a new image, see: http://people.debian.org/~lunar/g-i+terminal-mini.iso (Home and End keys should work fine.) Here some numbers: 73738 ttf-dejavu-mono-udeb_2.25-2_all.udeb 123660 DejaVuSansMono.ttf And more numbers: (not including rescue-mode and rescue-check as the previous image) * initrd size: without: 12609 k with: 13473 k = + 864 k * memory after boot: without: 47044 k with: 49060 k = + 2016 k * memory for the shell: before shell: 49496 k during shell: 50612 k = + 1116 k (Test process: qemu, expert installation, adding a shell on ttyS0 by editing /etc/inittab with BOOT_DEBUG, switching to serial console and looking at the used column with the free command.) In its current (and hopefully final) version, support for shells in the graphical installer require the introduction of three new udebs, namely: cdebconf-terminal, libvte9-udeb and ttf-dejavu-mono-udeb. I would take care of cdebconf-terminal as part of d-i, ttf-dejavu-mono-udeb as been worked on by Davide and Loïc Minier already integrated most of the required changes in VTE's packaging repository. I think that most issues I have been told about have now been solved. I would be happy if we could take a final decision quite soon. I can see four options: [ ] NACK [ ] Further discussions after Lenny is released [ ] Merge now, including cdebconf-gtk-terminal in the gtk initrd [ ] Merge now, loading cdebconf-gtk-terminal on demand I would tick the third one myself. As far as I have seen, the memory usage stays below 64 MB memory before anna drop its translation. And having a shell is pretty worthwhile when you have trouble with your network setup… :) Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Wed, Jul 23, 2008 at 07:10:38PM +0200, Frans Pop wrote: On Tuesday 22 July 2008, Jérémy Bobbio wrote: If you want to have a look, I have updated the test image at: http://people.debian.org/~lunar/g-i+terminal-mini.iso I am quite happy with the result. :) Yes, much more natural IMO. For the goback confirmation dialog I suggest changing the text to something a bit more positive (avoid kill; mention of terminal process is technical). Something like: Resume installation Choose Continue to really exit the shell and resume the installation; any processes still running in the shell will be aborted. Thanks for your proposal, which I have happily integrated. (If wonder if there is any material I could read which would help me to write more helpful documentation, help strings and similar stuff…) Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
Jérémy Bobbio [EMAIL PROTECTED] writes: [4] NACK [3] Further discussions after Lenny is released [1] Merge now, including cdebconf-gtk-terminal in the gtk initrd [2] Merge now, loading cdebconf-gtk-terminal on demand I would tick the third one myself. As far as I have seen, the memory usage stays below 64 MB memory before anna drop its translation. And having a shell is pretty worthwhile when you have trouble with your network setup… :) This is my vote -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Add support for shells in the graphical installer
On Tue, Jul 22, 2008 at 02:04:59AM +0200, J??r??my Bobbio wrote: On Sun, Jul 20, 2008 at 08:04:29PM +0200, Frans Pop wrote: That is still with the to-much-reduced font udeb, isn't it? Or did Davide already provide a new version for you? I have used the last one mentioned by Davide on the list, which is the too-much-reduced one, IIRC. I've prepared a new package [1] (including pdf chart) and committed the changes to svn [2]; I think this is the best I can do at the moment, since stripping too much would lead to problems similar to #428747, #411909 or #409509 Here some numbers: 73738 ttf-dejavu-mono-udeb_2.25-2_all.udeb 123660 DejaVuSansMono.ttf I've managed to strip some more glyphs out of the other udeb, saving around 44Kb out of the ttf files, so I think the situation is not too bad. Upstream is about to come up with a new release (expected to be dropped next weekend): shall I wait for it or do you prefere going through 2.25-2 first? I'm open to any option regards, Davide [1] http://www.alioth.debian.org/~zinosat-guest/2.25-2-mono3/ [2] svn://svn.debian.org/svn/pkg-fonts/packages/ttf-dejavu/trunk signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Tuesday 22 July 2008, Jérémy Bobbio wrote: If you want to have a look, I have updated the test image at: http://people.debian.org/~lunar/g-i+terminal-mini.iso I am quite happy with the result. :) Yes, much more natural IMO. For the goback confirmation dialog I suggest changing the text to something a bit more positive (avoid kill; mention of terminal process is technical). Something like: Resume installation Choose Continue to really exit the shell and resume the installation; any processes still running in the shell will be aborted. Here is the problem. You seem to have added a dep from rescue-check on di-utils-shell. As rescue mode depends on rescue-check, this causes the execute a shell option to always appear _before_ rescue mode. Dependencies overrule menu item numbers. Thanks for opening my eyes. I have moved start-shell from di-utils-shell to plain di-utils and it did fix the issue. Looks good now. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: [RFC] Add support for shells in the graphical installer
On Sun, Jul 20, 2008 at 08:04:29PM +0200, Frans Pop wrote: On Sunday 20 July 2008, Jérémy Bobbio wrote: On Sat, Jul 19, 2008 at 01:47:17PM +0200, Frans Pop wrote: Current size numbers (with the last ttf-dejavu-mono-udeb): That is still with the to-much-reduced font udeb, isn't it? Or did Davide already provide a new version for you? no, I haven't prepared any new updated udebs; fortunately this week I can spend some time on debian stuff :) regards, Davide signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Sun, Jul 20, 2008 at 08:04:29PM +0200, Frans Pop wrote: On Sunday 20 July 2008, Jérémy Bobbio wrote: On Sat, Jul 19, 2008 at 01:47:17PM +0200, Frans Pop wrote: Ok, the behaviour I have implemented today: * When the terminal process exits, the plugin exit as well. * The Continue button has been replaced with a Go back button. * When pressed, the Go back button displays a confirmation message, with Cancel (default) and Continue button. Pressing the later exits. * Pressing Ctrl-Shift-Escape in the terminal is a shortcut result in the same behaviour as pressing the Go back button. After some testing, it feels indeed better. Looks excellent. Doubt anyone will be using that key combo though :-) If you want to have a look, I have updated the test image at: http://people.debian.org/~lunar/g-i+terminal-mini.iso I am quite happy with the result. :) (I must have mixed up my various versions of libvte9-udeb as the Home/End issue is not fixed in this test image.) You must have something different as in the normal rescue case it does work correctly. I doubt including rescue in the initrd makes any difference, although I have not checked that. It really might make a difference. I don't see how any changes that I have done could affect the menu ordering! Here is the problem. You seem to have added a dep from rescue-check on di-utils-shell. As rescue mode depends on rescue-check, this causes the execute a shell option to always appear _before_ rescue mode. Dependencies overrule menu item numbers. Thanks for opening my eyes. I have moved start-shell from di-utils-shell to plain di-utils and it did fix the issue. That is still with the to-much-reduced font udeb, isn't it? Or did Davide already provide a new version for you? I have used the last one mentioned by Davide on the list, which is the too-much-reduced one, IIRC. Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Wed, Jul 16, 2008 at 11:04:16PM +0200, Frans Pop wrote: Davide, is there any special things that we should know about Chinese in DejaVu-Mono? Dejavu* do not contain any glyph falling in the Chinee range, so I guess they're taken out of the ttf-cjk-compact-udeb (which I guess is not monospaced) […] IMO this is not a major issue and improving it is not a priority. If there are simple tricks (such as antialiasing) that can improve things at low cost, then fine. If not, to bad. I have made some tests, and specifiying an aliasing option while specifying use of the monospace font does not change Chinese rendering. Antialiasing must be defined inside the fallback mechanism used by Pango to render the fonts. This is a little bit out of my knowledge, here. :) Cheers, -- Jérémy Bobbio signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Sat, Jul 19, 2008 at 01:47:17PM +0200, Frans Pop wrote:
Why is the Continue button needed? Could an active Go back button
be shown instead of the Continue that (after a warning) just kills
the plug-in if it is clicked (the mouse is still active after all)?
I need to think of a proper way to display a warning, but it sounds
like a better idea.
I had intended for the warning to be optional. I mainly feel that a
graphical alternative to typing exit would be useful, and certainly
more useful than a Continue button which only means you have exited,
please confirm that you've already exited and we'll return to the
installer proper (exaggerated).
Ok, the behaviour I have implemented today:
* When the terminal process exits, the plugin exit as well.
* The Continue button has been replaced with a Go back button.
* When pressed, the Go back button displays a confirmation message,
with Cancel (default) and Continue button. Pressing the later
exits.
* Pressing Ctrl-Shift-Escape in the terminal is a shortcut result in
the same behaviour as pressing the Go back button.
After some testing, it feels indeed better.
You must have something different as in the normal rescue case it does
work correctly. I doubt including rescue in the initrd makes any
difference, although I have not checked that.
It really might make a difference. I don't see how any changes that I
have done could affect the menu ordering!
On another topic, I have been able to fix the Home/End keys. That was a
side effect while trying to see if I could remove the dependency on
ncurses completely.
VTE uses ncurses to read terminfo files, if they are not accessible it
falls back to its own internal termcap parser. Good news is that I have
been able to completely remove the useless dependency on ncurses, as no
terminfo files were accessible in the installer anyway.
Fixing the Home/End keys was only a matter of tweaking the minimal
termcap file shipped in libvte9-udeb.
Current size numbers (with the last ttf-dejavu-mono-udeb):
* initrd.gz:
without: 13271k
with: 13626k
= + 355k
* memory after boot:
without: 49340k
with: 49988k
= + 648k
* memory for the plugin:
before the shell: 50424k
during the shell: 51484k
= + 1060k
Last patchset attached.
Cheers,
--
Jérémy Bobbio.''`.
[EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism
`. `'`
`-
commit 220e2d3e7540dce4263ed8f6fda1f38157125e77
Author: Jérémy Bobbio [EMAIL PROTECTED]
Date: Sun Jul 6 20:54:58 2008 +
Add cdebconf-terminal package
cdebconf-terminal builds a plugin for the GTK+ frontend adding the
possibility to display terminals as debconf questions.
This will allow shells to be started inside the graphical installer like
the other frontends.
As the terminal widget is provided by VTE, the package depends on
libvte9-udeb. It also depends on ttf-dejavu-mono-udeb to display properly
monospaced fonts.
diff --git a/packages/cdebconf-terminal/Makefile.in b/packages/cdebconf-terminal/Makefile.in
new file mode 100644
index 000..9d156b6
--- /dev/null
+++ b/packages/cdebconf-terminal/Makefile.in
@@ -0,0 +1,51 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+bindir=${prefix}/bin
+sbindir=${prefix}/sbin
+libdir=${prefix}/lib
+moddir=${libdir}/cdebconf/frontend
+sharedir=${prefix}/share/debconf
+mandir=${prefix}/share/man
+incdir=${prefix}/include/cdebconf
+
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@ -I.
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+
+CFLAGS += -funsigned-char -fstrict-aliasing -Wall -W -Werror -Wundef \
+ -Wwrite-strings -Wsign-compare -Wno-unused-parameter -Winit-self \
+ -Wpointer-arith -Wredundant-decls -Wno-format-zero-length \
+ -Wmissing-prototypes -Wmissing-format-attribute
+
[EMAIL PROTECTED]@
+PLUGIN_MODULES=$(addsuffix -plugin-$(PACKAGE).so,$(FRONTENDS))
+
+all: $(PLUGIN_MODULES)
+
+install: $(PLUGIN_MODULES)
+ for p in $(PLUGIN_MODULES); do \
+ install -m755 -d $(DESTDIR)/$(moddir)/$${p%%-*} ; \
+ install -m644 $$p $(DESTDIR)/$(moddir)/$${p%%-*}/$${p#*-} ; \
+ done
+
+gtk-plugin-$(PACKAGE).so: gtk-plugin-$(PACKAGE).opic
+ $(CC) $(LDFLAGS) -shared -o $@ $^ $(GTK_LIBS) -lvte
+
+clean:
+ rm -f $(PLUGIN_MODULES)
+ rm -f *.opic
+
+distclean: clean
+ rm -f config.log config.status
+ rm -f Makefile
+
+gtk-%.opic: gtk-%.c
+ @echo Compiling $ to $@
+ $(CC) $(CFLAGS) $(GTK_CFLAGS) -fPIC -o $@ -c $
+
+%.opic: %.c
+ @echo Compiling $ to $@
+ $(CC) $(CFLAGS) -fPIC -o $@ -c $
diff --git a/packages/cdebconf-terminal/configure.ac b/packages/cdebconf-terminal/configure.ac
new file mode 100644
index 000..2297f0f
--- /dev/null
+++ b/packages/cdebconf-terminal/configure.ac
@@ -0,0 +1,31 @@
+AC_INIT
+
+PACKAGE=terminal
Re: [RFC] Add support for shells in the graphical installer
Jérémy Bobbio [EMAIL PROTECTED] writes: On Sat, Jul 19, 2008 at 01:47:17PM +0200, Frans Pop wrote: Why is the Continue button needed? Could an active Go back button be shown instead of the Continue that (after a warning) just kills the plug-in if it is clicked (the mouse is still active after all)? I need to think of a proper way to display a warning, but it sounds like a better idea. I had intended for the warning to be optional. I mainly feel that a graphical alternative to typing exit would be useful, and certainly more useful than a Continue button which only means you have exited, please confirm that you've already exited and we'll return to the installer proper (exaggerated). Ok, the behaviour I have implemented today: * When the terminal process exits, the plugin exit as well. * The Continue button has been replaced with a Go back button. * When pressed, the Go back button displays a confirmation message, with Cancel (default) and Continue button. Pressing the later exits. * Pressing Ctrl-Shift-Escape in the terminal is a shortcut result in the same behaviour as pressing the Go back button. After some testing, it feels indeed better. We are doing great progress on that, indeed. You must have something different as in the normal rescue case it does work correctly. I doubt including rescue in the initrd makes any difference, although I have not checked that. It really might make a difference. I don't see how any changes that I have done could affect the menu ordering! On another topic, I have been able to fix the Home/End keys. That was a side effect while trying to see if I could remove the dependency on ncurses completely. VTE uses ncurses to read terminfo files, if they are not accessible it falls back to its own internal termcap parser. Good news is that I have been able to completely remove the useless dependency on ncurses, as no terminfo files were accessible in the installer anyway. That is nice, indeed. Fixing the Home/End keys was only a matter of tweaking the minimal termcap file shipped in libvte9-udeb. hehe ... great :-) Current size numbers (with the last ttf-dejavu-mono-udeb): * initrd.gz: without: 13271k with: 13626k = + 355k * memory after boot: without: 49340k with: 49988k = + 648k * memory for the plugin: before the shell: 50424k during the shell: 51484k = + 1060k Last patchset attached. This is really impressive since it has low impact on the installer and really improves the user experience. I won't be able to try those patches myself in next days but I fully trust your and Frans judgement about it and if both agree I'd say to upload it as soon as possible to get a wider testing on that. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Add support for shells in the graphical installer
On Sunday 20 July 2008, Jérémy Bobbio wrote: On Sat, Jul 19, 2008 at 01:47:17PM +0200, Frans Pop wrote: Ok, the behaviour I have implemented today: * When the terminal process exits, the plugin exit as well. * The Continue button has been replaced with a Go back button. * When pressed, the Go back button displays a confirmation message, with Cancel (default) and Continue button. Pressing the later exits. * Pressing Ctrl-Shift-Escape in the terminal is a shortcut result in the same behaviour as pressing the Go back button. After some testing, it feels indeed better. Looks excellent. Doubt anyone will be using that key combo though :-) You must have something different as in the normal rescue case it does work correctly. I doubt including rescue in the initrd makes any difference, although I have not checked that. It really might make a difference. I don't see how any changes that I have done could affect the menu ordering! Here is the problem. You seem to have added a dep from rescue-check on di-utils-shell. As rescue mode depends on rescue-check, this causes the execute a shell option to always appear _before_ rescue mode. Dependencies overrule menu item numbers. On another topic, I have been able to fix the Home/End keys. That was a side effect while trying to see if I could remove the dependency on ncurses completely. Nice. Current size numbers (with the last ttf-dejavu-mono-udeb): That is still with the to-much-reduced font udeb, isn't it? Or did Davide already provide a new version for you? signature.asc Description: This is a digitally signed message part.
Re: [RFC] Add support for shells in the graphical installer
On Wednesday 16 July 2008, Jérémy Bobbio wrote: However, I do see that this implementation is simpler and there were issues with the tabs, so post-Lenny for that is fine. The tabs should, IMHO, come with a wider redesign of the current interface. Debian is going to be installed on more and more wide TFT screens and g-i should support them in a better way that it currently does. Agreed, at least that it can be looked into later. I would still like to see Yes and No buttons instead of radio buttons for single boolean questions. And I have other changes on my list… :) Attilio did that at some point and we discussed it. Major disadvantage was the distance between the question and the buttons which made answering the question completely inintuitive. I don't have any real objection to using buttons, but IMO that issue would definitely need to be solved before we could change to using them. Getting cdebconf-terminal ready for Lenny will allow us to offer users of languages only supported by the graphical installer at least one way to access a shell. And this sounds like a really desirable goal. :) Yes, absolutely. What I really don't like from a usability PoV is the requirement to type 'exit' to leave the shell and the IMO unnecessary two-step exit (first 'exit' and then 'Continue'). Rationale behind it is that sometimes one mistype a Ctrl+D, and going back to the menu directly typing random letters sounded like a bad idea. I don't think that is sufficient reason to make the normal exit so convoluted. If I type ctrl-D in a shell in konsole it also just exits. For me that is a case of don't do that then :-) Why is the Continue button needed? Could an active Go back button be shown instead of the Continue that (after a warning) just kills the plug-in if it is clicked (the mouse is still active after all)? I need to think of a proper way to display a warning, but it sounds like a better idea. I had intended for the warning to be optional. I mainly feel that a graphical alternative to typing exit would be useful, and certainly more useful than a Continue button which only means you have exited, please confirm that you've already exited and we'll return to the installer proper (exaggerated). I fail to see the point in the End of shell process. message, even if the two-step exit is technically unavoidable. If you do want to keep some message, then I'd suggest a simple Click Continue to proceed. which is much more helpful. One can reach the Continue button using the keyboard, that's why I Only after you've already exited, which IMO makes it redundant anyway. avoided such message. The various situations where such a shell could have been called also made me pounder about something like proceed. But maybe it should just be avoided. Yes :-) Most important issue: position of Execute a shell in the menu is incorrect after anna (before partman instead of after finish-install). […] I did no changes to the actual code for Execute a shell or rescue mode options except that removing the tests which removed these options when DEBIAN_FRONTEND was gtk. So if di-utils-shell position is wrong when rescue-mode is put on the initrd, normal builds once the patch will have been applied will not be affected. You must have something different as in the normal rescue case it does work correctly. I doubt including rescue in the initrd makes any difference, although I have not checked that. If you'd like help with this I'm willing to take a closer look, but I won't unless you ask. Other issues/suggestions: [...] - if possible repeat the type 'exit' to close the shell and return to the installer info somewhere on the screen while the plug-in is running; looks like there's little room for this though I can make this message configurable through a variable, as the View system log option you were asking previously will not need exit but Ctrl-C. More strings, angrier Christian… This was low priority anyway and is less needed if there is a Go back option. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: [RFC] Add support for shells in the graphical installer
Quoting Frans Pop ([EMAIL PROTECTED]): I would make that: In the meantime you can make use of the debug shells available on VT2 and VT3. Press Ctrl+Alt+F2 to switch to VT2. When you are done, use Alt+F5 to return to the installer. Isn't VT a little bit of jargon, by the way? Couldn't we speak about virtual terminal which would be clearer to newbies? signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Wed, Jul 16, 2008 at 01:35:45AM +0200, Frans Pop wrote:
Main thing still is that it's great to have a graphical shell and that it
would be a real plus if we can get it ready in time for Lenny. At the
same time, it should IMO be solid enough to be included.
First and most importantly: I've not seen any crashes or weird glitches.
Sounds like a good answer to the previous remark. :)
Integration into the installer has some problems I think. I really likes
the tabs idea in your previous test image especially because that also
offered a scrollable syslog screen _with_ correct display in foreign
scripts. It also makes the shell available in parallel to the
installation process instead of temporarily replacing it.
Both are complementary: cdebconf-terminal is meant to be the graphical
version of the debconf-disconnect trick for both the Execute a shell
and rescue mode shell options.
Tabs for parallel shells and syslog are graphical versions of the
Linux VT, accessible with Alt+F{2,3,4}.
However, I do see that this implementation is simpler and there were
issues with the tabs, so post-Lenny for that is fine.
The tabs should, IMHO, come with a wider redesign of the current
interface. Debian is going to be installed on more and more wide TFT
screens and g-i should support them in a better way that it currently
does. I would still like to see Yes and No buttons instead of radio
buttons for single boolean questions. And I have other changes on my
list… :)
Getting cdebconf-terminal ready for Lenny will allow us to offer users
of languages only supported by the graphical installer at least one way
to access a shell. And this sounds like a really desirable goal. :)
It would still be nice if an extra menu item could be added View system
log that shows a tail of 500 lines or so.
This can easily be added to di-utils-shell or rootskel-gtk. It also
depends if we decide to include cdebconf-terminal in the initrd or leave
it as an extra udeb.
What I really don't like from a usability PoV is the requirement to
type 'exit' to leave the shell and the IMO unnecessary two-step exit
(first 'exit' and then 'Continue').
Rationale behind it is that sometimes one mistype a Ctrl+D, and going
back to the menu directly typing random letters sounded like a bad idea.
Is it technically not possible to just quit the plug-in after typing exit?
It is possible.
Why is the Continue button needed? Could an active Go back button be
shown instead of the Continue that (after a warning) just kills the
plug-in if it is clicked (the mouse is still active after all)?
I need to think of a proper way to display a warning, but it sounds like
a better idea.
I fail to see the point in the End of shell process. message, even if
the two-step exit is technically unavoidable. If you do want to keep some
message, then I'd suggest a simple Click Continue to proceed. which is
much more helpful.
One can reach the Continue button using the keyboard, that's why I
avoided such message. The various situations where such a shell could
have been called also made me pounder about something like proceed.
But maybe it should just be avoided.
Most important issue: position of Execute a shell in the menu is
incorrect after anna (before partman instead of after finish-install).
[…]
I did no changes to the actual code for Execute a shell or rescue mode
options except that removing the tests which removed these options when
DEBIAN_FRONTEND was gtk. So if di-utils-shell position is wrong when
rescue-mode is put on the initrd, normal builds once the patch will have
been applied will not be affected.
Other issues/suggestions:
- home and end keys don't work while editing a line
I need to figure out why.
- scrollback is only 100 lines while it's 200 on VT2/3; would be good to
be consistent there
Easily fixed.
- if possible repeat the type 'exit' to close the shell and return to the
installer info somewhere on the screen while the plug-in is running;
looks like there's little room for this though
I can make this message configurable through a variable, as the View
system log option you were asking previously will not need exit but
Ctrl-C. More strings, angrier Christian…
- why is the position of the End of shell process different for regular
shell and rescue shell (for the first it is indented by 7 or 8 chars)
I have noticed it, but haven't been able to understand why. :(
- Chinese looks reasonable: fairly sharp but some characters are much
brighter than others (varying from very dark grey to white); guess
antialiasing would be needed?
I see that VteTerminal API has a VTE_ANTI_ALIAS_FORCE_ENABLE option, but
it does not sound like a good idea to use it. Davide, is there any
special things that we should know about Chinese in DejaVu-Mono?
+Template: rescue/initrd-shell/title
+_Description: Interactive shell in the installer environment
+
This is not a new string! It's
Re: [RFC] Add support for shells in the graphical installer
On Wednesday 16 July 2008, Davide Viti wrote: On Wed, Jul 16, 2008 at 03:31:56PM +0200, J??r??my Bobbio wrote: On Wed, Jul 16, 2008 at 01:35:45AM +0200, Frans Pop wrote: - Chinese looks reasonable: fairly sharp but some characters are much brighter than others (varying from very dark grey to white); guess antialiasing would be needed? I see that VteTerminal API has a VTE_ANTI_ALIAS_FORCE_ENABLE option, but it does not sound like a good idea to use it. Why not? Davide, is there any special things that we should know about Chinese in DejaVu-Mono? Dejavu* do not contain any glyph falling in the Chinee range, so I guess they're taken out of the ttf-cjk-compact-udeb (which I guess is not monospaced) Monospace is not the problem here. And adding CJK (and all other languages) in the monospace font would require way too much memory anyway. The languages that are in there now have a reasonably limited character set, so the cost is not too high. The same is just not true for most other languages. IMO this is not a major issue and improving it is not a priority. If there are simple tricks (such as antialiasing) that can improve things at low cost, then fine. If not, to bad. It could well be that it looks much better on a real display than in an emulator. I did see a big difference for a few scripts yesterday when I did an install on real hardware. signature.asc Description: This is a digitally signed message part.
Re: [RFC] Add support for shells in the graphical installer
On Thursday 10 July 2008, Jérémy Bobbio wrote: I'd really like to see this before forming a final opinion, especially as it has an impact on the graphical installer as a whole. Ok, here it is: I've played around with it quite a lot and here are my comments. I realize that this is an intermediate solution that will be improved later, but I'll still just list everything I have for discussion. I don't expect everything to necessarily be solved. Main thing still is that it's great to have a graphical shell and that it would be a real plus if we can get it ready in time for Lenny. At the same time, it should IMO be solid enough to be included. First and most importantly: I've not seen any crashes or weird glitches. Integration into the installer has some problems I think. I really likes the tabs idea in your previous test image especially because that also offered a scrollable syslog screen _with_ correct display in foreign scripts. It also makes the shell available in parallel to the installation process instead of temporarily replacing it. However, I do see that this implementation is simpler and there were issues with the tabs, so post-Lenny for that is fine. It would still be nice if an extra menu item could be added View system log that shows a tail of 500 lines or so. What I really don't like from a usability PoV is the requirement to type 'exit' to leave the shell and the IMO unnecessary two-step exit (first 'exit' and then 'Continue'). Is it technically not possible to just quit the plug-in after typing exit? Why is the Continue button needed? Could an active Go back button be shown instead of the Continue that (after a warning) just kills the plug-in if it is clicked (the mouse is still active after all)? I fail to see the point in the End of shell process. message, even if the two-step exit is technically unavoidable. If you do want to keep some message, then I'd suggest a simple Click Continue to proceed. which is much more helpful. Most important issue: position of Execute a shell in the menu is incorrect after anna (before partman instead of after finish-install). Without having looked at it, I'm fairly certain that this is just a dependency issue: you probably have rescue mode depending on the udeb that provides the postinst for Execute a shell. It looks like you have duplicated the entire existing rescue-mode udeb. Is that really necessary? Can't we just make sure the correct thing is done by testing the current environment in existing scripts, or only activate the correct hook scripts through such tests? It would also reduce the duplication of strings. Solution is to split them: one udeb with plug-in and one with postinst. Note that you may not be able to depend on the plug-in at all for rescue as we don't want to pull it into regular images! I think that for rescue you should just test if it's available or not and in that case the split would not be needed either. Other problem related to rescue mode: a shell gets executed without any warning just before rescue mode (possibly because the wrong position in the menu). Also, the informational message before entering the rescue shell is a lot less informational than the one for a normal shell. It misses the info on how to exit for example. Why not reuse the message shown by the existing rescue shell? Other issues/suggestions: - home and end keys don't work while editing a line - scrollback is only 100 lines while it's 200 on VT2/3; would be good to be consistent there - if possible repeat the type 'exit' to close the shell and return to the installer info somewhere on the screen while the plug-in is running; looks like there's little room for this though - why is the position of the End of shell process different for regular shell and rescue shell (for the first it is indented by 7 or 8 chars) Nice things: - keyboard changing OK (same issues as in G-I in general) - Cyrillic in 'nano /var/log/syslog' very readable - Chinese looks reasonable: fairly sharp but some characters are much brighter than others (varying from very dark grey to white); guess antialiasing would be needed? - Hebrew is there and nice; no idea if it's drawn correctly. Templates: +Template: di-utils-shell/workaround-gtk +_Description: In the meantime, a shell is still accessible by pressing Ctrl+Alt+F2. Use Alt+F5 to get back to the installer. Alternatively, you can open a shell by pression Ctrl+Alt+F2. Use Alt+F5 to get back to the installer. I would make that: In the meantime you can make use of the debug shells available on VT2 and VT3. Press Ctrl+Alt+F2 to switch to VT2. When you are done, use Alt+F5 to return to the installer. +Template: rescue/initrd-shell/title +_Description: Interactive shell in the installer environment + Do we really need to specify this? This is not a new string! It's already used in the regular rescue mode. IMO this duplication should be avoided.
Re: [RFC] Add support for shells in the graphical installer
On Wednesday 16 July 2008, Frans Pop wrote: Other problem related to rescue mode: a shell gets executed without any warning just before rescue mode (possibly because the wrong position in the menu). Also, the informational message before entering the rescue shell is a lot less informational than the one for a normal shell. It misses the info on how to exit for example. Why not reuse the message shown by the existing rescue shell? The second part is confusion on my part because of the fact that a regular shell gets run before rescue is actually started. Fact remains though that rescue mode displays a lot less informational message than the normal shell. IMO the rescue mode message should be based on the normal one with the needed extra info about the chroot merged in. signature.asc Description: This is a digitally signed message part.
Re: [RFC] Add support for shells in the graphical installer
On Thu, Jul 10, 2008 at 07:50:41PM +0200, Frans Pop wrote: * libncurses5-udeb needed by libvte. For this one we need to be careful that others don't start using it for other purposes which may get it included in normal initrds. It's not huge, but still. This could be prevented by statically linking libncurses5 to libvte9 in the udeb. Would that be a desirable option? I think it's probably a bit too big and common for that. Do you have any idea how much of the lib actually gets used? If it is really minimal that could be a reason to do it anyway. It is really minimal: only termcap features are used. I have managed to statically link ncurses to libvte, and the size increase is only 50k (where full libncurses5 library is 158k already). On Thursday 10 July 2008, Jérémy wrote: Questions: - What is size increase of initrd with this included? [...] Thanks for the numbers. Those are pretty hefty runtime demands (total of 2.5 MB for first shell). However, I guess it's still not completely absurd for what G-I already uses and can expect to have available. Updated numbers some time with Davide's improvements would be nice. Updated numbers with the newer libvte and Davide's ttf-dejavu-mono-udeb (but with mklibs-copy… mklibs suddently failed with an error on [EMAIL PROTECTED] and after more than an hour of various fights, I just gave up): * Initrd size: without: 13072 kB with: 13461 kB increase: 389 kB * cdebconf-gtk-terminal on initrd, memory right after boot: without: 48464 kB with: 49328 kB increase: 864 kB Both are clearly improved. * cdebconf-gtk-terminal on initrd, memory usage: right before shell: 49644 kB (on di-utils-shell/do-shell) during shell: 50868 kB (on di-utils-shell/shell-plugin) increase: 1224 kB That is higher than during the previous test. Surely due to mklibs-copy. Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Thu, Jul 10, 2008 at 07:53:33PM +0200, Frans Pop wrote: On Wednesday 09 July 2008, Davide Viti wrote: On Wed, Jul 09, 2008 at 03:56:28PM +0200, Frans Pop wrote: I would not have thought anything higher than 2100 (inclusive, so after general punctuation) will ever be needed in the context of a D-I shell. I think you mean u210 I'm applying the same reduction script used for stripping ttf-dejavu-udeb_2.25-2_all.udeb; if necessary, we can apply different rules rules for Mono (it's been already done in the patch) I think a separate rule makes sense in this case as the usage is really different. Also depends on what the extra gain is of course. I changed the stripping rule (for mono) as to strip all but u0..u210 -rw-r--r-- 1 zino zino37416 Jul 12 00:22 ttf-dejavu-mono-udeb_2.25-2_all.udeb -rw-r--r--root/root65920 2008-07-12 00:22 ./usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf Possibly some of the exclusions could also be used for all udebs? I've stripped out more ranges which were included in 2.25; I'm sure we can do better, but IMO it'd be risky at this point Updated files available in [1] and all changes were committed in ttf-dejavu repository [2] (I still left the UNRELEASED flag set) regards, Davide [1] http://alioth.debian.org/~zinosat-guest/2.25-2-mono2/ [2] svn://svn.debian.org/svn/pkg-fonts/packages/ttf-dejavu/trunk signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Saturday 12 July 2008, Davide Viti wrote: I think you mean u210 [...] I changed the stripping rule (for mono) as to strip all but u0..u210 No. This strips more than I intended. The Cyrillic and Latin Extended sets for example should IMO remain included. I really meant u2100: Letterlike symbols and higher. I'm aware that makes the savings a _lot_ less, but all small bits help in D-I. Also means that Jérémy will have to redo his numbers :-) Unless of course others feel that we really should strip down this much. Guess now that we have the extra-reduced udeb a comparison of the difference between the two makes sense, for example in Greek or Russian, when reading the syslog (which _does_ contain translated text) in nano. I would expect the quality loss to be significant and thus worth the cost. Jérémy: could you do that compare maybe? signature.asc Description: This is a digitally signed message part.
Re: [RFC] Add support for shells in the graphical installer
On Wed, Jul 09, 2008 at 05:02:08PM +0200, Frans Pop wrote:
The result is quite nice, and the user experience is very similar
between the different frontends. The impact on the current code by
these changes are really low and they should be seen as strong
candidate for inclusion in Lenny.
This should really be considered carefully, especially given the timing.
I fully agree. But I think that including this as an extra package
would be quite safe.
As you probably know the freeze for Lenny for libraries is expected pretty
soon. Also, the libvte9 udeb is rather big. Even with the reduced size of
the udeb we're looking at at least 1MB extra memory usage.
Maybe I am missing some way to reduce its size even more ; but let's
assume that the increase would be of this order.
From the templates discussion you are leaving open whether or not to
include it in the initrd or not. IMO we should discuss that now.
The following results are from my current development image, which
contain a little bit more changes that just cdebconf-gtk-terminal.
The only change I have made is to comment out cdebconf-gtk-terminal in
pkg-lists/local.
All this have been done _without_ Davide's reduced ttf-dejavu-mono-udeb.
Questions:
- What is size increase of initrd with this included?
Without:
14419388 netboot/gtk/debian-installer/i386/initrd.gz
With:
15187021 netboot/gtk/debian-installer/i386/initrd.gz
= Increase of 767633 = 749 kB
- What is memory usage increase immediately after boot if this is included
in initrd?
Without: 50868 kB
With: 52320 kB
= Increase of 1452 kB
- Is there any increase in memory usage if shell(s) are actually started?
Before: 52728 kB
(on di-utils-shell/do-shell)
After: 53872 kB
(on di-utils-shell/shell-plugin)
= Increase of 1144 kB
Subsequent shells only costs 200 kB during their execution.
http://people.debian.org/~lunar/ttf-dejavu_2.25-1_add_mono-udeb.diff.gz
* libvte9-udeb containing the VteTerminal widget used by the
plugin.
315kB compressed, 688kB installed
http://people.debian.org/~lunar/vte_0.16.14-1_enable_udeb.diff.gz
- Please shorten the long package description for the udeb.
I have reused the one from the original package. I am going to shorten
it nevertheless.
- I see nothing in the patch that ensures we'll get correct dependencies
on this udeb.
I thought that it would be enough to have in debian/control:
Depends: ${misc:Depends}, ${shlibs:Depends}
Or I might not have exactly understood what you mean…
* libncurses5-udeb needed by libvte.
80k compressed, 172k installed
http://people.debian.org/~lunar/ncurses_5.6+20080614-1_enable_udeb.diff
.gz
For this one we need to be careful that others don't start using it for
other purposes which may get it included in normal initrds. It's not
huge, but still.
This could be prevented by statically linking libncurses5 to libvte9 in
the udeb. Would that be a desirable option?
Cheers,
--
Jérémy Bobbio.''`.
[EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism
`. `'`
`-
signature.asc
Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Wed, Jul 09, 2008 at 05:02:08PM +0200, Frans Pop wrote: I can't provide a test image right now as I am lacking the necessary network connectivity. I will try to provide one as soon as possible. I'd really like to see this before forming a final opinion, especially as it has an impact on the graphical installer as a whole. Ok, here it is: http://people.debian.org/~lunar/g-i+terminal-mini.iso This image uses the reduced ttf-dejavu-mono-udeb and have the template fixes already discussed on the list. (For an added bonus, it also has the cancelable NTP synchronisation.) Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Thursday 10 July 2008, Jérémy wrote:
Questions:
- What is size increase of initrd with this included?
[...]
Thanks for the numbers.
Those are pretty hefty runtime demands (total of 2.5 MB for first shell).
However, I guess it's still not completely absurd for what G-I already
uses and can expect to have available.
Updated numbers some time with Davide's improvements would be nice.
I have reused the one from the original package. I am going to shorten
it nevertheless.
It's mainly because nobody reads it anyway (at least, not for the udeb)
and it only wastes space in the status file.
- I see nothing in the patch that ensures we'll get correct
dependencies on this udeb.
I thought that it would be enough to have in debian/control:
Depends: ${misc:Depends}, ${shlibs:Depends}
For library udebs we need to ensure that _other_ udebs that get built
against them on them get their deps on the lib correct. So the shlibs
file must have udeb: lines. You do have the necessary magic in the
ncurses patch (though you should still check the generated shlibs file
and the deps of udebs built against it).
* libncurses5-udeb needed by libvte.
For this one we need to be careful that others don't start using it
for other purposes which may get it included in normal initrds.
It's not huge, but still.
This could be prevented by statically linking libncurses5 to libvte9 in
the udeb. Would that be a desirable option?
I think it's probably a bit too big and common for that. Do you have any
idea how much of the lib actually gets used? If it is really minimal that
could be a reason to do it anyway.
Cheers,
FJP
signature.asc
Description: This is a digitally signed message part.
Re: [RFC] Add support for shells in the graphical installer
On Wednesday 09 July 2008, Davide Viti wrote: On Wed, Jul 09, 2008 at 03:56:28PM +0200, Frans Pop wrote: I would not have thought anything higher than 2100 (inclusive, so after general punctuation) will ever be needed in the context of a D-I shell. I'm applying the same reduction script used for stripping ttf-dejavu-udeb_2.25-2_all.udeb; if necessary, we can apply different rules rules for Mono (it's been already done in the patch) I think a separate rule makes sense in this case as the usage is really different. Also depends on what the extra gain is of course. Possibly some of the exclusions could also be used for all udebs? signature.asc Description: This is a digitally signed message part.
Re: [RFC] Add support for shells in the graphical installer
Christian Perrier wrote: The 'terminal' plugin, which is required to open a shell, is not available. Please load it from the main menu in 'Loading additional components'. The 'cdebconf-gtk-terminal' module, which is required to open a shell, is not available. Please load it from the main menu in 'Loading additional components'. -- see shy jo signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
Quoting Jérémy Bobbio ([EMAIL PROTECTED]):
+Template: debconf/terminal/gtk/child-exit
+Type: text
+_Description: Shell process has exited.
Well, I don't like it..:-)
Not sure what would be the best. Where is this displayed ? Inside a
box ?
Inside the terminal to indicate that the shell is gone. Terminal.app in
Mac OS X gave me the idea. The output is something like:
+---+
| $ pwd |
| /tmp |
| $ exit|
| |
| Shell process has exited. |
+---+
I would sugges something like End of shell process or Shell process
terminated.
Well, then I suggest End of shell process.
+Template: di-utils-shell/terminal-plugin-unavailable
+Type: error
+# :sl2:
+_Description: Terminal plugin unavailable
+ This build of the debian-installer requires the terminal plugin in
+ order to display a shell. Unfortunately, this plugin is currently
+ unavailable.
+ .
+ It should be available after reaching the Loading additional
components
+ installation step.
+ .
+ ${WORKAROUND}
s/unavailable/not available
Done.
The 'terminal' plugin, which is required to open a shell, is not
available. Please load it from the main menu in 'Loading additional
components'.
There is no need to load it manually: it will be automatically retrieved
by the start-shell script, but the source for the udebs must be
configured in order to do so.
I don't really understand. You mean that in normal situations, that
template has no chance to be used? If I'm correct, unless something
bad happens, there's always a source for udebs when a d-i component
needs them.
+Template: rescue/initrd-shell/title
+Type: text
+# :sl2:
+_Description: Interactive shell in the installer environment
+
Do we really need to specify this?
I'm not sure that the in the installer environment is really
meaningful for our users. When we run a shell in the text installer,
it's in the installer's environment and we don't specify it.
The difference is significant in the rescue-mode context: two different
options are offered. Either the shell is started from the rescued
system environment, or it is started within d-i, with the rescued system
in /target.
Ah, right. I didn't noticed this was indeed meant for rescue. It makes
sense for it.
However, please use Execute a shell in the installer environment and
Execute a shell in ${DEVICE} as these strings are already used by
rescue and I don't see any reason to make them different..:-)
signature.asc
Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Wed, Jul 09, 2008 at 06:56:21AM +0200, Christian Perrier wrote:
Well, then I suggest End of shell process.
Done.
The 'terminal' plugin, which is required to open a shell, is not
available. Please load it from the main menu in 'Loading additional
components'.
There is no need to load it manually: it will be automatically retrieved
by the start-shell script, but the source for the udebs must be
configured in order to do so.
I don't really understand. You mean that in normal situations, that
template has no chance to be used? If I'm correct, unless something
bad happens, there's always a source for udebs when a d-i component
needs them.
Not necessarily. If cdebconf-gtk-terminal has not been put on the
initrd, then the package won't be available until anna is configured.
But there is no need to explicitely select the module in anna, as
start-shell does it automatically by using anna-install.
+Template: rescue/initrd-shell/title
+Type: text
+# :sl2:
+_Description: Interactive shell in the installer environment
+
Do we really need to specify this?
I'm not sure that the in the installer environment is really
meaningful for our users. When we run a shell in the text installer,
it's in the installer's environment and we don't specify it.
The difference is significant in the rescue-mode context: two different
options are offered. Either the shell is started from the rescued
system environment, or it is started within d-i, with the rescued system
in /target.
Ah, right. I didn't noticed this was indeed meant for rescue. It makes
sense for it.
However, please use Execute a shell in the installer environment and
Execute a shell in ${DEVICE} as these strings are already used by
rescue and I don't see any reason to make them different..:-)
I see one: they are not displayed in the same context. The last string
you mention are in a menu (hence they are actions). The template is
displayed as a title, right above the terminal window. I think the
later ought to be more a description of the current status.
(But please excuse my english here… and I already have a hard time using
meta-language in french.)
Cheers,
--
Jérémy Bobbio.''`.
[EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism
`. `'`
`-
signature.asc
Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
Hi, On Tue, Jul 08, 2008 at 10:42:39PM +0200, Davide Viti wrote: On Tue, Jul 08, 2008 at 06:01:54PM +0200, J??r??my Bobbio wrote: The attached patchset adds support for shells in the graphical installer: Execute a shell in menu, and rescue-mode shells can now be used in the graphical installer. this is really great! cdebconf-gtk-terminal requires three new udebs on top of itself: * ttf-dejavu-mono-udeb containing DejaVu monospaced font. 349kB compressed, 624kB installed (might surely be reduced if Davide take a look at it.) http://people.debian.org/~lunar/ttf-dejavu_2.25-1_add_mono-udeb.diff.gz I've worked on your patch and generated a test ttf-dejavu 2.25-2 package whose files are available in [1]; there you will also find an updated version of your patch and a pdf chart showing all the available glyphs. As for the size, it got reduced alot: -rw-r--r-- 1 zino zino 79102 9 lug 13:14 ttf-dejavu-mono-udeb_2.25-2_all.udeb -rw-r--r-- 1 zino zino 135172 9 lug 13:14 mono/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf It'd be nice if somebody could take a look at the patch: if everything's ok I'll proceed with creating the parckage and ping Christian for the upload. regards, Davide [1] http://alioth.debian.org/~zinosat-guest/2.25-2-mono/ signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Wednesday 09 July 2008, Davide Viti wrote: I've worked on your patch and generated a test ttf-dejavu 2.25-2 package whose files are available in [1]; there you will also find an updated version of your patch and a pdf chart showing all the available glyphs. I would not have thought anything higher than 2100 (inclusive, so after general punctuation) will ever be needed in the context of a D-I shell. As for the size, it got reduced alot: Nice. It'd be nice if somebody could take a look at the patch: if everything's ok I'll proceed with creating the parckage and ping Christian for the upload. I think that would be OK as, even if we decide not to include this feature for Lenny. As it is a separate package, it will not affect D-I until we actually start using it and as the source package already has other udebs the impact there is negligible too. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: [RFC] Add support for shells in the graphical installer
On Wed, Jul 09, 2008 at 03:56:28PM +0200, Frans Pop wrote: I would not have thought anything higher than 2100 (inclusive, so after general punctuation) will ever be needed in the context of a D-I shell. I'm applying the same reduction script used for stripping ttf-dejavu-udeb_2.25-2_all.udeb; if necessary, we can apply different rules rules for Mono (it's been already done in the patch) thanx, Davide signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Tuesday 08 July 2008, =?iso-8859-1?B?Suly6W15?= Bobbio wrote: The attached patchset adds support for shells in the graphical installer: Execute a shell in menu, and rescue-mode shells can now be used in the graphical installer. Great work Jérémy, but... The result is quite nice, and the user experience is very similar between the different frontends. The impact on the current code by these changes are really low and they should be seen as strong candidate for inclusion in Lenny. This should really be considered carefully, especially given the timing. As you probably know the freeze for Lenny for libraries is expected pretty soon. Also, the libvte9 udeb is rather big. Even with the reduced size of the udeb we're looking at at least 1MB extra memory usage. From the templates discussion you are leaving open whether or not to include it in the initrd or not. IMO we should discuss that now. Questions: - What is size increase of initrd with this included? - What is memory usage increase immediately after boot if this is included in initrd? - Is there any increase in memory usage if shell(s) are actually started? http://people.debian.org/~lunar/ttf-dejavu_2.25-1_add_mono-udeb.diff.gz * libvte9-udeb containing the VteTerminal widget used by the plugin. 315kB compressed, 688kB installed http://people.debian.org/~lunar/vte_0.16.14-1_enable_udeb.diff.gz - Please shorten the long package description for the udeb. - I see nothing in the patch that ensures we'll get correct dependencies on this udeb. * libncurses5-udeb needed by libvte. 80k compressed, 172k installed http://people.debian.org/~lunar/ncurses_5.6+20080614-1_enable_udeb.diff .gz For this one we need to be careful that others don't start using it for other purposes which may get it included in normal initrds. It's not huge, but still. I can't provide a test image right now as I am lacking the necessary network connectivity. I will try to provide one as soon as possible. I'd really like to see this before forming a final opinion, especially as it has an impact on the graphical installer as a whole. If you can provide a set of udebs for i386 with no other changes relative to current unstable, that would be fine too. I'll comment on templates after testing. If there is no strong objections after a first round of testing, I would like to ask for the changes outside d-i without waiting too much. I think we should only do this if a freeze exception is approved by the release team before the changes are requested. I also think we should get an OK from the libvte maintainer that the patch is OK with him before requesting the other changes. Cheers, FJP signature.asc Description: This is a digitally signed message part.
[RFC] Add support for shells in the graphical installer
Hi!
It feels quite strange to look back at the past year and realize that
first task I really decided to tackle in the debian-installer might be
done with this mail… The experience has been pretty intense and thanks
for the ride! :)
The attached patchset adds support for shells in the graphical
installer: Execute a shell in menu, and rescue-mode shells can now be
used in the graphical installer.
Main changes:
* A new source package is introduced, cdebconf-terminal, which builds
cdebconf-gtk-terminal. It contains the terminal plugin for the
GTK+ frontend.
* A new script, start-shell, is added to di-utils-shell. This script
either uses debconf-disconnect (old style) or a newly introduced
template using the new terminal type. In order to reduce the
memory footprint, start-shell tries to anna-install
cdebconf-gtk-terminal when the plugin is not available.
* di-utils-shell.postinst, rescue.d/shell and rescue.d/initrd-shell all
uses start-shell.
The result is quite nice, and the user experience is very similar
between the different frontends. The impact on the current code by
these changes are really low and they should be seen as strong candidate
for inclusion in Lenny.
cdebconf-gtk-terminal requires three new udebs on top of itself:
* ttf-dejavu-mono-udeb containing DejaVu monospaced font.
349kB compressed, 624kB installed
(might surely be reduced if Davide take a look at it.)
http://people.debian.org/~lunar/ttf-dejavu_2.25-1_add_mono-udeb.diff.gz
* libvte9-udeb containing the VteTerminal widget used by the
plugin.
315kB compressed, 688kB installed
http://people.debian.org/~lunar/vte_0.16.14-1_enable_udeb.diff.gz
* libncurses5-udeb needed by libvte.
80k compressed, 172k installed
http://people.debian.org/~lunar/ncurses_5.6+20080614-1_enable_udeb.diff.gz
This patch adds 6 new translatable debconf templates. They worth a
review, for sure. :)
I can't provide a test image right now as I am lacking the necessary
network connectivity. I will try to provide one as soon as possible.
If there is no strong objections after a first round of testing, I would
like to ask for the changes outside d-i without waiting too much.
As all this work as been done offline, the changelogs probably miss a
Closes or two.
Cheers,
--
Jérémy Bobbio.''`.
[EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism
`. `'`
`-
commit 67a8e6b7a46ceae376833e537c731099c6749d5f
Author: Jérémy Bobbio [EMAIL PROTECTED]
Date: Sun Jul 6 20:54:58 2008 +
Add cdebconf-terminal package
cdebconf-terminal builds a plugin for the GTK+ frontend adding the
possibility to display terminals as debconf questions.
This will allow shells to be started inside the graphical installer like
the other frontends.
As the terminal widget is provided by VTE, the package depends on
libvte9-udeb. It also depends on ttf-dejavu-mono-udeb to display properly
monospaced fonts.
---
packages/cdebconf-terminal/Makefile.in | 51
packages/cdebconf-terminal/configure.ac| 31 +++
.../debian/cdebconf-gtk-terminal.install |1 +
.../debian/cdebconf-gtk-terminal.templates |3 +
packages/cdebconf-terminal/debian/changelog|5 +
packages/cdebconf-terminal/debian/compat |1 +
packages/cdebconf-terminal/debian/control | 19 ++
packages/cdebconf-terminal/debian/copyright| 30 +++
packages/cdebconf-terminal/debian/po/POTFILES.in |1 +
packages/cdebconf-terminal/debian/po/templates.pot | 23 ++
packages/cdebconf-terminal/debian/rules| 78 ++
packages/cdebconf-terminal/gtk-plugin-terminal.c | 270
12 files changed, 513 insertions(+), 0 deletions(-)
diff --git a/packages/cdebconf-terminal/Makefile.in b/packages/cdebconf-terminal/Makefile.in
new file mode 100644
index 000..9d156b6
--- /dev/null
+++ b/packages/cdebconf-terminal/Makefile.in
@@ -0,0 +1,51 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+bindir=${prefix}/bin
+sbindir=${prefix}/sbin
+libdir=${prefix}/lib
+moddir=${libdir}/cdebconf/frontend
+sharedir=${prefix}/share/debconf
+mandir=${prefix}/share/man
+incdir=${prefix}/include/cdebconf
+
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@ -I.
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+
+CFLAGS += -funsigned-char -fstrict-aliasing -Wall -W -Werror -Wundef \
+ -Wwrite-strings -Wsign-compare -Wno-unused-parameter -Winit-self \
+ -Wpointer-arith -Wredundant-decls -Wno-format-zero-length \
+ -Wmissing-prototypes -Wmissing-format-attribute
+
[EMAIL PROTECTED]@
+PLUGIN_MODULES=$(addsuffix -plugin-$(PACKAGE).so,$(FRONTENDS))
+
+all: $(PLUGIN_MODULES)
+
+install: $(PLUGIN_MODULES)
+ for p in $(PLUGIN_MODULES); do \
+ install -m755 -d $(DESTDIR)/$(moddir)/$${p%%-*} ; \
+ install -m644 $$p
Re: [RFC] Add support for shells in the graphical installer
Quoting Jérémy Bobbio ([EMAIL PROTECTED]):
This patch adds 6 new translatable debconf templates. They worth a
review, for sure. :)
Grmbl...:-)...maybe some day, I have the hope to have a stable basis
for our translators. These days, they're hunting a moving target...:-)
OK, let's review the new debconf templates.
For dle readers: this is about a new feature in the graphical
installer, allowing to run a shell in a windows.
+Template: debconf/terminal/gtk/child-exit
+Type: text
+_Description: Shell process has exited.
Well, I don't like it..:-)
Not sure what would be the best. Where is this displayed ? Inside a
box ?
I would sugges something like End of shell process or Shell process
terminated.
Whether or not there should be a final dot depends on the context
where this is displayed, imho.
+Template: test/terminal
+Type: terminal
+Description: Feel free to rescue your system.
When is this displayed?
+
+Template: debconf/terminal/gtk/child-exit
+Type: text
+Description: Shell process has exited.
Ditto
-debconf-disconnect /bin/sh || true
+start-shell di-utils-shell/do-shell /bin/sh || true
diff --git a/packages/debian-installer-utils/debian/di-utils-shell.templates
b/packages/debian-installer-utils/debian/di-utils-shell.templates
index d84a942..4ff8c49 100644
--- a/packages/debian-installer-utils/debian/di-utils-shell.templates
+++ b/packages/debian-installer-utils/debian/di-utils-shell.templates
@@ -11,6 +11,34 @@ _Description: Interactive shell
.
Use the exit command to return to the installation menu.
+Template: di-utils-shell/shell-plugin
+Type: terminal
+# :sl2:
+_Description: ${TITLE}
Make this non translatable (removing the leading _)
+
+Template: di-utils-shell/shell-plugin-default-title
+Type: text
+# :sl2:
+_Description: Interactive shell
Seems OK for me.
+
+Template: di-utils-shell/terminal-plugin-unavailable
+Type: error
+# :sl2:
+_Description: Terminal plugin unavailable
+ This build of the debian-installer requires the terminal plugin in
+ order to display a shell. Unfortunately, this plugin is currently
+ unavailable.
+ .
+ It should be available after reaching the Loading additional components
+ installation step.
+ .
+ ${WORKAROUND}
s/unavailable/not available
The 'terminal' plugin, which is required to open a shell, is not
available. Please load it from the main menu in 'Loading additional
components'.
Template: di-utils-shell/terminal-plugin-unavailable
Type: error
# :sl2:
#flag:translate!:3
_Description: Terminal plugin no available
The 'terminal' plugin, which is required to open a shell, is not
available. Please load it from the main menu in 'Loading additional
components'.
.
${WORKAROUND}
+
+Template: di-utils-shell/workaround-gtk
+Type: text
+# :sl2:
+_Description: In the meantime, a shell is still accessible by pressing
Ctrl+Alt+F2. Use Alt+F5 to get back to the installer.
+
Alternatively, you can open a shell by pression Ctrl+Alt+F2. Use
Alt+F5 to get back to the installer.
(note the single spacing between sentences)
+Template: rescue/shell/title
+Type: text
+# :sl2:
+_Description: Interactive shell on ${DEVICE}
+
Seems OK
Template: rescue/initrd-shell/intro
Type: text
# :sl2:
@@ -96,6 +101,11 @@ _Description: Executing a shell
chroot /target. If you need any other file systems (such as a separate
/usr), you will have to mount those yourself.
+Template: rescue/initrd-shell/title
+Type: text
+# :sl2:
+_Description: Interactive shell in the installer environment
+
Do we really need to specify this?
I'm not sure that the in the installer environment is really
meaningful for our users. When we run a shell in the text installer,
it's in the installer's environment and we don't specify it.
signature.asc
Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
Christian Perrier wrote: +Template: di-utils-shell/workaround-gtk +Type: text +# :sl2: +_Description: In the meantime, a shell is still accessible by pressing Ctrl+Alt+F2. Use Alt+F5 to get back to the installer. + Alternatively, you can open a shell by pression Ctrl+Alt+F2. Use Alt+F5 to get back to the installer. (note the single spacing between sentences) s/pression/pressing/ (but that's all I've got.) -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Add support for shells in the graphical installer
On Tue, Jul 08, 2008 at 06:01:54PM +0200, J??r??my Bobbio wrote: The attached patchset adds support for shells in the graphical installer: Execute a shell in menu, and rescue-mode shells can now be used in the graphical installer. this is really great! cdebconf-gtk-terminal requires three new udebs on top of itself: * ttf-dejavu-mono-udeb containing DejaVu monospaced font. 349kB compressed, 624kB installed (might surely be reduced if Davide take a look at it.) http://people.debian.org/~lunar/ttf-dejavu_2.25-1_add_mono-udeb.diff.gz right, will look at this. Does this mean that we have both to generate this out of the ttf-dejavu package and strip unneeded glyphs out of it, right? regards, Davide signature.asc Description: Digital signature
Re: [RFC] Add support for shells in the graphical installer
On Tue, Jul 08, 2008 at 10:42:39PM +0200, Davide Viti wrote: On Tue, Jul 08, 2008 at 06:01:54PM +0200, J??r??my Bobbio wrote: The attached patchset adds support for shells in the graphical installer: Execute a shell in menu, and rescue-mode shells can now be used in the graphical installer. this is really great! cdebconf-gtk-terminal requires three new udebs on top of itself: * ttf-dejavu-mono-udeb containing DejaVu monospaced font. 349kB compressed, 624kB installed (might surely be reduced if Davide take a look at it.) http://people.debian.org/~lunar/ttf-dejavu_2.25-1_add_mono-udeb.diff.gz right, will look at this. Does this mean that we have both to generate this out of the ttf-dejavu package and strip unneeded glyphs out of it, right? I've just taken a look at the patch and should have done it before replying to your message: sorry for the noise! Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Add support for shells in the graphical installer
On Tue, Jul 08, 2008 at 07:49:30PM +0200, Christian Perrier wrote:
Quoting Jérémy Bobbio ([EMAIL PROTECTED]):
This patch adds 6 new translatable debconf templates. They worth a
review, for sure. :)
Grmbl...:-)...maybe some day, I have the hope to have a stable basis
for our translators. These days, they're hunting a moving target...:-)
Sorry… But that should be my last template until Lenny. :)
+Template: debconf/terminal/gtk/child-exit
+Type: text
+_Description: Shell process has exited.
Well, I don't like it..:-)
Not sure what would be the best. Where is this displayed ? Inside a
box ?
Inside the terminal to indicate that the shell is gone. Terminal.app in
Mac OS X gave me the idea. The output is something like:
+---+
| $ pwd |
| /tmp |
| $ exit|
| |
| Shell process has exited. |
+---+
I would sugges something like End of shell process or Shell process
terminated.
Whether or not there should be a final dot depends on the context
where this is displayed, imho.
I hope that you know have the missing bits…
In cdebconf/src/test/terminal.templates:
+Template: test/terminal
+Template: debconf/terminal/gtk/child-exit
When is this displayed?
Never in the installer. These templates are purely for internal tests.
The later should obviously be synchronized with the one given in
cdebconf-gtk-terminal.templates, though.
+Template: di-utils-shell/shell-plugin
+Type: terminal
+# :sl2:
+_Description: ${TITLE}
Make this non translatable (removing the leading _)
Done.
+Template: di-utils-shell/terminal-plugin-unavailable
+Type: error
+# :sl2:
+_Description: Terminal plugin unavailable
+ This build of the debian-installer requires the terminal plugin in
+ order to display a shell. Unfortunately, this plugin is currently
+ unavailable.
+ .
+ It should be available after reaching the Loading additional components
+ installation step.
+ .
+ ${WORKAROUND}
s/unavailable/not available
Done.
The 'terminal' plugin, which is required to open a shell, is not
available. Please load it from the main menu in 'Loading additional
components'.
There is no need to load it manually: it will be automatically retrieved
by the start-shell script, but the source for the udebs must be
configured in order to do so.
+Template: di-utils-shell/workaround-gtk
+Type: text
+# :sl2:
+_Description: In the meantime, a shell is still accessible by pressing
Ctrl+Alt+F2. Use Alt+F5 to get back to the installer.
+
Alternatively, you can open a shell by pression Ctrl+Alt+F2. Use
Alt+F5 to get back to the installer.
(note the single spacing between sentences)
Done.
+Template: rescue/initrd-shell/title
+Type: text
+# :sl2:
+_Description: Interactive shell in the installer environment
+
Do we really need to specify this?
I'm not sure that the in the installer environment is really
meaningful for our users. When we run a shell in the text installer,
it's in the installer's environment and we don't specify it.
The difference is significant in the rescue-mode context: two different
options are offered. Either the shell is started from the rescued
system environment, or it is started within d-i, with the rescued system
in /target.
As the difference is not that obivous, I think it makes sense to be
specific here.
Thanks for your comments! :)
Cheers,
--
Jérémy Bobbio.''`.
[EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism
`. `'`
`-
signature.asc
Description: Digital signature
