Bug#773763: task-mate-desktop: Should install libreoffice-gnome
Samuel Thibault, le Wed 24 Dec 2014 17:49:08 +0100, a écrit : This would probably need to be added to other desktop tasks too: task-lxde-desktop, task-xfce-desktop, task-cinnamon-desktop, I forgot to mention the additional sizes for those: LXDE: 350KiB XFCE: 350KiB Cinnamon: it's actually already getting installed. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141226104354.GC3060@type
Bug#773763: task-mate-desktop: Should install libreoffice-gnome
Hello, Jean-Philippe MENGUAL, le Tue 23 Dec 2014 01:06:20 +0100, a écrit : * What was the outcome of this action? LibreOffice was announced inaccessible by Orca. The solution: add libreoffice-gnome to the automatically installed packages with task-mate-desktop. A quick measurement from a fresh MATE installation gives only 4MiB additional installed size. This would probably need to be added to other desktop tasks too: task-lxde-desktop, task-xfce-desktop, task-cinnamon-desktop, task-mate-desktop (but not task-kde-desktop, since the KDE desktop is not accessible with Orca yet). Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141224164908.GZ3060@type
Re: Bug#771607: Re : Re: Re : Re: Bug#771607: unblock: brltty/5.2~20141018-2
Jonathan Wiltshire, le Fri 12 Dec 2014 21:37:10 +, a écrit : This discussion seems to have run into the sand. Indeed. Is there any news? Well, nothing more than what was said, actually, to sum it up: - MATE is a bit more accessible than Gnome with the Orca screen reader - MATE however doesn't have screen magnification, - gnome does have integrated magnification, even if not very good. So it seems that gnome is a good default, in that it has decent support for a wide range of disabilities. MATE would however be preferrable for people who need to use the Orca screen reader, thus the proposal to automatically tune the default desktop from d-i itself. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141214190916.gs2...@type.youpi.perso.aquilenet.fr
Re: vt2-6 still not available with base system
Simon McVittie, le Fri 12 Dec 2014 16:18:13 +, a écrit : On 12/12/14 15:26, Michael Biebl wrote: Since apparently Conditions can't be used on targets, I came up with a slightly different idea, using a service, which triggers the start of getty on tty2-6 in absence of /usr/bin/dbus-daemon. Any reason not to prefer Wants=getty@tty2.service ... getty@tty6.service and ExecStart=/bin/true? The advantage of that static-getty.service compared to enabling getty on tty2-6 is, that we can easily drop that again in jessie+X once we have kdbus. I understand that advantage over Samuel's proposal, but if I was the systemd maintainer, I'd be very tempted to drop the Condition and run all six gettys unconditionally, preserving traditional functionality. And fixing #760916 along the way. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212165212.gb3...@type.bordeaux.inria.fr
Bug#772461: Update installation-guide for no separated /usr
Baptiste Jammet, le Sun 07 Dec 2014 14:34:04 +0100, a écrit : I think that this will need some rewording in the installation manual. Indeed, thanks! Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141207174759.gn3...@type.youpi.perso.aquilenet.fr
Bug#771576: tasksel: tasks=mate still also installs gnome
Control: tags -1 + patch Hello, Here is a tested patch. Samuel commit ada61ef5b9fb3c89e415c824837883fee87625b0 Author: Samuel Thibault sthiba...@debian.org Date: Mon Dec 8 01:03:30 2014 +0100 When a desktop is preseeded, only enable that desktop. diff --git a/debian/changelog b/debian/changelog index 1abc6ed..cc59469 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,11 +1,15 @@ tasksel (3.30) UNRELEASED; urgency=medium + [ Joey Hess ] * Remove pm-utils from laptop and desktop tasks. It was only added because hal needed it, hal doesn't exist anymore, and systemctl is used for command-line suspend/hibernate now. * Remove libgl1-mesa-dri from the desktop task list. xorg depends on it, so it does not need to be explicitly listed. + [ Samuel Thibault ] + * When a desktop is preseeded, only enable that desktop. Closes: #771576. + -- Joey Hess jo...@debian.org Thu, 30 Oct 2014 15:58:02 -0400 tasksel (3.29) unstable; urgency=high diff --git a/tests/default-desktop b/tests/default-desktop index 10d4a44..2b6a3b8 100755 --- a/tests/default-desktop +++ b/tests/default-desktop @@ -27,8 +27,10 @@ check_desktop_wanted() { fi } -if db_get tasksel/desktop echo $RET | grep -q $DESKTOPNAME; then - check_desktop_wanted +if db_get tasksel/desktop; then + if echo $RET | grep -q $DESKTOPNAME; then + check_desktop_wanted + fi else if [ $DESKTOPNAME = $(default_desktop_for_arch $(dpkg --print-architecture)) ]; then check_desktop_wanted
Re: vt2-6 still not available with base system
Michael Biebl, le Thu 04 Dec 2014 00:10:57 +0100, a écrit : Am 03.12.2014 um 22:42 schrieb Samuel Thibault: Simon McVittie, le Sun 09 Nov 2014 20:43:36 +, a écrit : I'm very tempted to say systemd in Debian should just make these 5 symlinks to preserve traditional Debian behaviour, at least for jessie. It doesn't really even need to run systemctl, it can just use ln -s or whatever. People who are so desperately short of memory that 5 agetty instances are undesired can always disable them. If you want it to be clear that it's a Debian-specific thing that's pulling them in, maybe it would be better to add a new debian-gettys.target or debian-gettys.service that Wants them, and make it WantedBy an appropriate target? That looks like the simplest way for now. Does anyone want to look into this and provide a patch for such a static gettys target. Maybe we could even make it Conditional on /usr/bin/dbus-daemon not being installed. I don't know how to do that, here is a more trivial way: simply doing the same as for tty1. I can confirm that this also fixes bug #760916. Samuel --- debian/changelog.original 2014-12-08 00:47:40.570640003 +0100 +++ debian/changelog2014-12-08 00:48:27.972968147 +0100 @@ -1,3 +1,9 @@ +systemd (215-9) UNRELEASED; urgency=medium + + * Always enable vt2-6. (Closes: #760916) + + -- Samuel Thibault sthiba...@debian.org Mon, 08 Dec 2014 00:47:17 +0100 + systemd (215-8) unstable; urgency=medium [ Didier Roche ] --- debian/systemd.postinst.original2014-12-05 10:01:35.0 +0100 +++ debian/systemd.postinst 2014-12-08 00:49:31.440085305 +0100 @@ -123,6 +123,15 @@ _systemctl try-restart systemd-timesyncd.service || true fi +# Now enable all gettys by default +if dpkg --compare-versions $2 lt 215-9; then +systemctl enable getty@tty2.service || true +systemctl enable getty@tty3.service || true +systemctl enable getty@tty4.service || true +systemctl enable getty@tty5.service || true +systemctl enable getty@tty6.service || true +fi + # Enable getty and remote-fs.target by default on new installs, and on # upgrades from old systemd versions (where the symlinks included as deb # content, and will thus have been removed by dpkg during the upgrade). --- debian/systemd.preinst.original 2014-12-05 10:01:35.0 +0100 +++ debian/systemd.preinst 2014-12-08 00:46:28.091353385 +0100 @@ -40,6 +40,11 @@ save_is_enabled console-shell.service save_is_enabled debug-shell.service save_is_enabled getty@tty1.service +save_is_enabled getty@tty2.service +save_is_enabled getty@tty3.service +save_is_enabled getty@tty4.service +save_is_enabled getty@tty5.service +save_is_enabled getty@tty6.service save_is_enabled remote-fs.target save_is_enabled rescue.target save_is_enabled systemd-readahead-collect.service
Re: vt2-6 still not available with base system
Simon McVittie, le Sun 09 Nov 2014 20:43:36 +, a écrit : I'm very tempted to say systemd in Debian should just make these 5 symlinks to preserve traditional Debian behaviour, at least for jessie. It doesn't really even need to run systemctl, it can just use ln -s or whatever. People who are so desperately short of memory that 5 agetty instances are undesired can always disable them. If you want it to be clear that it's a Debian-specific thing that's pulling them in, maybe it would be better to add a new debian-gettys.target or debian-gettys.service that Wants them, and make it WantedBy an appropriate target? That looks like the simplest way for now. A generator could be conditional on the absence of dbus.service, or some such, but then again so could a debian-gettys.service with ConditionPathExists=!/lib/systemd/system/dbus.service. Indeed. I'd however tend to just always start them, thus fixing along the way bug #760916 which is a pain for blind people, and for which I don't even know where to start debugging. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203214216.ga10...@type.youpi.perso.aquilenet.fr
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
I'm not sure to understand what the original bug report is about precisely. AIUI, it is about the following scenario: 1) install debian in a Xen domU, ending up with systemd installed by default 2) install sysvinit-core to switch back to sysvinit boot 3) end up having to fix this and that to get sysvinit work properly I am not very surprised that it does not work. The various tuning that d-i does usually only work on what gets installed during d-i, not on what gets installed later on. That's particularly the case for software which doesn't provide nice hooks for d-i to use them. I'm just wondering one thing: between steps 1) and 2), does the installed system (using systemd) properly have a login banner on hvc0? If not, then it's indeed a problem, but not related with sysvinit and inittab. In the current logic, some more code should be added to finish-install's 90console script to handle the systemd case. I don't have a Xen system offhand to easily test that. Cyril Brulebois, le Mon 10 Nov 2014 20:51:28 +0100, a écrit : Would it make any sense to have $something created by d-i, consumed by both systemd and sysvinit to make sure consoles are available? It would make sense, but I'm not sure we can manage to write something that both sysvinit and systemd can understand easily. include support could be added to sysvinit, and /etc/inittab made to include the d-i-generate bits, but it'd still be in inittab format, which AIUI systemd wouldn't grok. So it would be something else, but then we would have to make sysvinit aware of what a serial login is, which it has never been made to, for flexibility reasons. Of course if I'm conflating issues that are orthogonal, please say so and we'll track both issues separately. I actually haven't quoted the vt2-6 issue here because I don't think it is related with d-i. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203221226.gf3...@type.youpi.perso.aquilenet.fr
Bug#769407: Should set up Grub for serial and console
Control: reassign -1 grub-installer Geert Stappers, le Wed 03 Dec 2014 22:35:21 +0100, a écrit : On Thu, Nov 13, 2014 at 02:19:50PM +0100, martin f krafft wrote: Following an install with auto console=tty0 console=ttyS0,115200n8 on the command line and using yesterday's amd64 daily jessie installer, the /etc/default/grub file had GRUB_TERMINAL=serial enabled. Please set that to GRUB_TERMINAL=console serial to allow Grub to display on both, which it has supported for a while. To which package should this bugreport be assigned? This part is handled by grub-installer, reassigning. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203221446.gg3...@type.youpi.perso.aquilenet.fr
Bug#769406: Serial console not set up after serial install
Hello, Geert Stappers, le Wed 03 Dec 2014 22:30:39 +0100, a écrit : Jan 1 21:50:07 kernel: [0.00] Command line: BOOT_IMAGE=http://alpaca.gpm.stappers.nl/d-i/jessie/amd64/linux vga=normal console=ttyS0,19200,n8 -- initrd=http://alpaca.gpm.stappers.nl/d-i/jessie/amd64/initrd.gz Options to be propagated to the installed kernel have to be put after --. With the recent kernel change which lead to #764675, it's actually now ---, so it'd be something like vga=normal initrd=http://alpaca.gpm.stappers.nl/d-i/jessie/amd64/initrd.gz --- console=ttyS0,19200,n8 How were this console= parameter added precisely? I have added to the manual's Boot Parameters section an explicit mention of this. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203222900.gh3...@type.youpi.perso.aquilenet.fr
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
Gedalya, le Wed 03 Dec 2014 17:22:41 -0500, a écrit : On 12/03/2014 05:12 PM, Samuel Thibault wrote: I'm not sure to understand what the original bug report is about precisely. AIUI, it is about the following scenario: 1) install debian in a Xen domU, ending up with systemd installed by default 2) install sysvinit-core to switch back to sysvinit boot 3) end up having to fix this and that to get sysvinit work properly this and that being very specifically one line added to inittab: co:2345:respawn:/sbin/getty hvc0 9600 linux Given the above scenario this needs to be done by hand. As I understand the code, currently d-i would still add that for the user, if /etc/inittab existed, and it doesn't because sysvinit-core is not installed. Well, yes. But this does not seem surprising to me: again, usually d-i tunes packages which it has installed. It doesn't tune much what could potentially get installed later on. And it should for sure not install a complete /etc/inittab, that would only confuse people who were used to configure things there. I'm just wondering one thing: between steps 1) and 2), does the installed system (using systemd) properly have a login banner on hvc0? It does. The problem occurs only after installing sysvinit-core. If the user really depends on a console then they would need to add this line before rebooting, and we can expect that they might not know to do so. Well, changing the init system is not something trivial indeed. What is new here is that sysvinit-core can now get initially installed not from d-i. And thus the tuning usually done by d-i can't work. Also, we probably have to think about ping-pong scenarii: install sysvinit-core, then switch back to systemd, purge sysvinit-core, and drop /etc/inittab. Change one's mind again, reinstall sysvinit-core. We still want to have a console on /dev/hvc0. We're far from d-i, so it'd rather be sysvinit-core which does the job of adding the console to inittab. Can't some of the logic in finish-install's 90console simply moved to sysvinit-core's postinst? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203224545.gi3...@type.youpi.perso.aquilenet.fr
Re: Bug#771607: unblock: brltty/5.2~20141018-2
Cyril Brulebois, le Mon 01 Dec 2014 09:41:20 +0100, a écrit : As it seems that Jessie will install the gnome desktop by default, I would like to upload the attached changes. The idea is that the most accessible desktop we have in Debian is MATE Why are we learning about this only now? ?? This has been written on https://wiki.debian.org/DebianDesktop/Requalification/Jessie for a long time already. I only stumbled upon your mail because I'm subscribed to -accessibility@, adding -boot@ to Cc… Hum... I had put X-Debbugs-Cc: debian-boot@lists.debian.org X-Debbugs-Cc: debian-accessibil...@lists.debian.org I then guess bts only keep the last one. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201084738.ga3...@type.bordeaux.inria.fr
Re: Bug#771607: unblock: brltty/5.2~20141018-2
Hello, Cyril Brulebois, le Mon 01 Dec 2014 10:39:17 +0100, a écrit : With the tasksel/3.25 upload and the default switch back to gnome, it looked to me that the accessibility side was taken care of. What do you mean by taken care of? If you mean fixing them, the few accessibility issues that gnome 3.14 aren't easy to fix, and thus most probably won't be fixed for Jessie. If you mean taking accessibility into account when chosing the default desktop, well I thought it was done according to the version of the chart at the time: https://wiki.debian.org/DebianDesktop/Requalification/Jessie?action=recallrev=28 which clearly says that MATE is the best choice for accessibility, by a short preference over gnome, and that gnome was preferred over MATE for some other reason. Joey? Note that I'm not saying gnome is very bad for accessibility: as the chart says it's fine enough. But for the best accessible usability, MATE is preferrable, thus the idea of tuning the default for the case of braille speech. Also note that it doesn't mean that accessibility shouldn't be taken into account for the default desktop. There is still the common case of a computer installed before knowing that a disabled person will want to use it. Since the wiki page seems to have been updated to include results from [1], A long time ago, yes. and since [1] didn't exactly call for mate as the default desktop, ?? “MATE, not in this benchmarking, is the best solution.” “I'm sure MATE is the ideal solution now, given it's accessible for a lot of disabilities and also for sight people” It seemed clear to me, except that since at the time the poll was done MATE was actually not among the choices in the evaluation chart (and not even a task), Jean-Philippe made it a special case. I'm still surprised this topic is only being brought up now. There were almost 2-3 months to do so. Well, I don't remember an announcement about it. I didn't know that the choice had been actually really settled, particularly since there were edits on the wiki page since them. I was however seeing the distribution getting more and more frozen, and thus the current gnome default getting more and more settled. 1. https://lists.debian.org/debian-accessibility/2014/09/msg8.html (That also says compiz works inside MATE, but I only see compiz in oldstable, so…) Indeed, since we didn't manage to package compiz in time for Jessie, AIUI MATE doesn't have a magnifier. AIUI we still prefer MATE for the braille case at least. Jean-Philippe ? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201102256.gf3...@type.bordeaux.inria.fr
Re: Bug#771607: unblock: brltty/5.2~20141018-2
Cyril Brulebois, le Mon 01 Dec 2014 11:36:06 +0100, a écrit : It seemed clear to me, except that since at the time the poll was done MATE was actually not among the choices in the evaluation chart (and not even a task), Jean-Philippe made it a special case. !! “[…] I think Debian won't choose it. So, alternatively, I suggest gnome […]” At the time, MATE wasn't even a task, so that's why Jean-Philippe said he believed Debian would of course not choose it as a default. which seems to enact that gnome is fine enough. Yes, again, gnome *is* fine enough. But can't we fine-tune the default when we know for sure that the user is using braille? Notably since it seems we'd better go with gnome with its integrated magnifier for people with low vision, and we'd better go with MATE for people using braille? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201105719.gg3...@type.bordeaux.inria.fr
Re: Bug#771607: unblock: brltty/5.2~20141018-2
Cyril Brulebois, le Mon 01 Dec 2014 11:36:06 +0100, a écrit : Well, I don't remember an announcement about it. I didn't know that the choice had been actually really settled,[...] Well, you could have asked; Well, that's what I am doing. I guess my timeout value was just too large. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201105946.gh3...@type.bordeaux.inria.fr
Re: Re : Re: Bug#771607: unblock: brltty/5.2~20141018-2
MENGUAL Jean-Philippe, le Mon 01 Dec 2014 12:06:35 +0100, a écrit : and MATE is much more suit when we try to have a universal desktop with braille, speech and magnifying, in particular due to its visual customization capabilities, disappeared in gnome. Mmm, but do we have magnification support in MATE? AIUI we don't. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201113513.gj3...@type.bordeaux.inria.fr
Re: Re : Re: Re : Re: Bug#771607: unblock: brltty/5.2~20141018-2
MENGUAL Jean-Philippe, le Mon 01 Dec 2014 13:14:07 +0100, a écrit : - Samuel Thibault sthiba...@debian.org a écrit : MENGUAL Jean-Philippe, le Mon 01 Dec 2014 12:06:35 +0100, a écrit : and MATE is much more suit when we try to have a universal desktop with braille, speech and magnifying, in particular due to its visual customization capabilities, disappeared in gnome. Mmm, but do we have magnification support in MATE? AIUI we don't. At least there are much themes, large customizations (font, characters, colours of various items such as windows edges, areas, etc). It gives lesser choices in some areas, but isn't the lack of magnification support a problem? I mean AIUI gnome seems like a good default since it has support for a large range of accessibility features, even if it's not as good at some of them as MATE can be. MATE, on the other hand, is notably missing magnification, which I think will be a real concern for quite a few people (as in: not usable at all), and AIUI MATE customizations will not be enough to deal with that. Moreover, compiz can be easily implemented (Luca is doing). Please remember that we are talking about Jessie, not a downstream of Jessie. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201122127.gv3...@type.bordeaux.inria.fr
Bug#771576: tasksel: tasks=mate still also installs gnome
Package: tasksel Version: 3.29 Severity: important Hello, I wanted to make brltty and speakup auto-preseed tasks=mate so as to automatically install the most accessible desktop by default, but while doing so indeed enables installation of the mate desktop, the gnome desktop also gets installed: when using tasks=mate, both gnome and mate choices get ticked by default, and then the user session will default to the (lesser accessible) gnome desktop. Apparently this comes from the logic in the default-desktop script: if db_get tasksel/desktop echo $RET | grep -q $DESKTOPNAME; then check_desktop_wanted else if [ $DESKTOPNAME = $(default_desktop_for_arch $(dpkg --print-architecture)) ]; then check_desktop_wanted fi fi AIUI, this will make the gnome case skip the then part (since grep will fail), and since it's the default desktop for the amd64 arch, check_desktop_wanted will get called, and thus gnome always get ticked. Shouldn't it be rather the following? At least in my tests it works as I would expect: only tick the preseeded desktop choice. if db_get tasksel/desktop ; then if echo $RET | grep -q $DESKTOPNAME; then check_desktop_wanted fi else if [ $DESKTOPNAME = $(default_desktop_for_arch $(dpkg --print-architecture)) ]; then check_desktop_wanted fi fi With some preseeding, the mate case will enter the first then and the second then, and thus get ticked, while the gnome case will enter the first then, but not the second then. Without preseeding, all cases will enter the first else, and then only the default desktop for the arch will enter the corresponding then. Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tasksel depends on: ii apt 1.0.9.3 ii cdebconf [debconf-2.0] 0.192 ii debconf [debconf-2.0] 1.5.53 ii liblocale-gettext-perl 1.05-8+b1 ii perl-base 5.20.1-3 ii tasksel-data3.29 tasksel recommends no packages. tasksel suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141130202740.ga26...@type.youpi.perso.aquilenet.fr
Bug#769616: tasksel: fails to preseed desktop on kfreebsd, hurd
Samuel Thibault, le Sat 22 Nov 2014 23:19:24 +0100, a écrit : I however fail to preseed this and still let the user choose. Ok, forget what I wrote: I made various mistakes. tasksel tasksel/desktop multiselect mate does work, except bug #771576. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141130220609.ga17...@type.youpi.perso.aquilenet.fr
Re: base system size
Santiago Vila, le Sat 29 Nov 2014 10:49:43 +0100, a écrit : Maybe wget is too bloated for the base system? Having a wget available has been quite convenient to me several times to easily transfer a file. We could however in the future consider packaging another, lightweight wget. OTOH, 277 to 360 is just a 30% increase, in approximately two years, which is probably expected following Moore's law... Yes, the overall installation size (with generated files etc.) still largely fit in a 1GiB disk. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141129111352.gn5...@type.youpi.perso.aquilenet.fr
Re: d-i installation manual bits for arm64 and ppc64el
Hello, I can only repeat what I have posted a couple of months ago: we do need documentation in the manual about the arm64 and ppc64el new architectures. Samuel Thibault, le Tue 16 Sep 2014 14:11:01 +0200, a écrit : One of the things that needs to get added for arm64 and ppc64el is the installation manual bits. For now I have just commited the basics, so you can $ debcheckout installation-guide $ cd installation-guide/build $ ./buildone arm64 en pdf $ ./buildone ppc64el en pdf to get it built. What porters need to do is to add information specific to their arch. For arm64 = For now, arm64 is just like armel and armhf, I guess they won't differ so much. At least these files will however probably have to be updated to document some board-specific details: - en/hardware/supported/arm.xml - en/hardware/hardware-supported.xml - en/install-methods/download/arm.xml - en/preparing/bios-setup/arm.xml - en/boot-installer/arm.xml - en/using-d-i/modules/arm/flash-kernel-installer.xml It's probably useful to also look around at paragraphs marked with arch=arm For ppc64el === For now, ppc64el is just like powerpc, I guess it may be useful to distinguish them so as to drop the documentation for elder hardware? en/hardware/hardware-supported.xml will have to be updated. At least these files will probably have to be updated: - en/hardware/supported/powerpc.xml - en/hardware/hardware-supported.xml - en/install-methods/floppy/powerpc.xml - en/install-methods/usb-setup/powerpc.xml - en/preparing/bios-setup/powerpc.xml - en/boot-installer/powerpc.xml - en/using-d-i/modules/powerpc/yaboot-installer.xml - en/using-d-i/modules/powerpc/quik-installer.xml It's probably useful to also look around at paragraphs marked with arch=ppc64el Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141129120158.gs5...@type.youpi.perso.aquilenet.fr
base system size
Hello, Now that perl is out of the base system again, I've had a look at the figures of a base system install. We're ~80Mib bigger, from 277MiB to 360MiB: - aptitude is not installed by default any more - -18MiB - grub got 12MiB bigger. - wget now depends on libicu52, 27MiB. - linux-image got 37MiB bigger - systemd takes about 12MiB more than sysvinit - udev got 5MiB bigger. - util-linux got 1.3MiB bigger, and added 5MiB locale data - various bloat and optimizations (bash got 1MiB bigger for instance) Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141129014812.ga7...@type.youpi.perso.aquilenet.fr
Re: Bug#770525: tasksel: Task selection menu does not have Go Back button
Control: reassign -1 tasksel Control: retitle -1 tasksel: Task selection menu does not have Go Back button Samuel Thibault, le Sat 22 Nov 2014 02:43:54 +0100, a écrit : Samuel Thibault, le Sat 22 Nov 2014 02:34:40 +0100, a écrit : Package: tasksel Oops, sorry, I'm just realizing that in d-i it's called pkgsel. Mmm, but it's really tasksel which is running, reassigning back to tasksel. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014110045.gl12...@type.youpi.perso.aquilenet.fr
Bug#769616: tasksel: fails to preseed desktop on kfreebsd, hurd
Samuel Thibault, le Sat 22 Nov 2014 01:57:41 +0100, a écrit : Steven Chamberlain, le Sat 15 Nov 2014 02:20:53 +, a écrit : It was seen on kfreebsd and hurd that preseeding with: tasksel tasksel/first multiselect standard, desktop tasksel tasksel/desktop multiselect xfce no longer works, a regressions since wheezy; no desktop gets installed: https://lists.debian.org/debian-hurd/2014/11/msg00074.html Indeed, it should now be simply: tasksel tasksel/first multiselect standard, xfce-desktop I however fail to preseed this and still let the user choose. We'd need this for accessibility, to enable MATE by default when braille or speech was used. I have tried the following: debconf-set-selections mate-preseed.cfg where mate-pressed.cfg contains: tasksel tasksel/first multiselect standard, mate-desktop, print-server tasksel tasksel/first seen false tasksel tasksel/tasks multiselect standard, mate-desktop, print-server tasksel tasksel/tasks seen false tasksel tasksel/desktop mate tasksel tasksel/desktop seen false After that, debconf-get tasksel/first etc. return the expected values. But when arriving on the task choices, gnome is still the default... and debconf-get tasksel/first etc. have become empty. I guess I am missing something? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014111924.gm12...@type.youpi.perso.aquilenet.fr
Bug#769616: tasksel: fails to preseed desktop on kfreebsd, hurd
Hello, Steven Chamberlain, le Sat 15 Nov 2014 02:20:53 +, a écrit : It was seen on kfreebsd and hurd that preseeding with: tasksel tasksel/first multiselect standard, desktop tasksel tasksel/desktop multiselect xfce no longer works, a regressions since wheezy; no desktop gets installed: https://lists.debian.org/debian-hurd/2014/11/msg00074.html Indeed, it should now be simply: tasksel tasksel/first multiselect standard, xfce-desktop I have already pushed a patch to Holger to fix it in jenkins. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141122005741.gg4...@type.youpi.perso.aquilenet.fr
Bug#770525: tasksel: Task selection menu does not have Go Back button
Package: tasksel Version: 3.29 Severity: normal Hello, The Software selection d-i dialog does not have a Go Back button any more, which is not convenient when one wants to tinker a bit debconf before starting the long installing tasks step. Samuel -- System Information: Debian Release: jessie/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tasksel depends on: ii apt 1.0.9.3 ii cdebconf [debconf-2.0] 0.192 ii debconf [debconf-2.0] 1.5.53 ii liblocale-gettext-perl 1.05-8+b1 ii perl-base 5.20.1-2 ii tasksel-data3.29 tasksel recommends no packages. tasksel suggests no packages. -- debconf information excluded -- Samuel ... rv_ et Ctrl alt F2 pour aller sous console rv_ mais c koi pour passer d'un bureau a un autre ! rv_ au fait c koi le raccourci pour passer d'un bureau a un autre 'question stupide cycyx ça dépend du window manager et de ta conf Firebird ce qui fonctionne toujours c'est CTRL-ALT-BCKSP -:- SignOff rv_: #linuxfr (Read error: EOF from client) -:- rv_ [~rv@217.11.166.169] has joined #linuxfr rv_ Firebird: MEURT... -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141122013440.ga25...@type.youpi.perso.aquilenet.fr
Re: Bug#770525: pkgsel: Task selection menu does not have Go Back button
Control: reassign -1 pkgsel Control: retitle -1 pkgsel: Task selection menu does not have Go Back button Samuel Thibault, le Sat 22 Nov 2014 02:34:40 +0100, a écrit : Package: tasksel Oops, sorry, I'm just realizing that in d-i it's called pkgsel. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141122014354.ga5...@type.youpi.perso.aquilenet.fr
Re: tasksel desktop preseed issues (was: Re: Failure: g-i-installation_debian_sid_daily_hurd_lxde/71)
Steven Chamberlain, le Fri 14 Nov 2014 21:41:24 +, a écrit : Firstly could someone please tell me what display manager this is? https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_hurd_lxde/70/artifact/results//snapshot_008244.png See the preseed file: we force the use of xdm, I guess because lightdm doesn't work yet. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114233749.gm3...@type.youpi.perso.aquilenet.fr
Bug#745262: console-setup: Caps lock doesn't take effect on øæå (Danish characters)
Anton Zinoviev, le Sun 09 Nov 2014 17:29:53 +0200, a écrit : On Wed, Aug 13, 2014 at 12:47:26AM +0200, Samuel Thibault wrote: Anton Zinoviev, le Wed 06 Aug 2014 20:39:02 +0300, a écrit : On Sun, Apr 20, 2014 at 10:35:23PM +0200, Samuel Thibault wrote: Oops, indeed, it seems the version in Jessie does not properly defines the ctrll layer for upper cases like it used to in Wheezy. See ckbcomp dk: keycode 39 = +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute It uses only +U+00e6 +U+00c6, while it should use +U+00c6 +U+00e6 for ctrll layers. I am unable to reproduce this. What locale do you use? I've tested with LC_ALL=C, LC_ALL=da_DK.utf8 and LC_ALL=da_DK. Well, whatever the locale, LC_ALL=C for instance, I get only +U+00e6 +U+00c6, and never +U+00c6 +U+00e6. I've tried both console-setup 1.102 and 1.111. I just wanted to mention that I've never been able to reproduce this. I have tried this in clean install of jessie with Gnome, both i386 and amd64. I don't have the issue any more currently on my Jessie system. Andreas, do you still have the issue? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109155710.ga3...@type.youpi.perso.aquilenet.fr
Re: vt2-6 still not available with base system
Michael Biebl, le Sun 09 Nov 2014 19:56:40 +0100, a écrit : Running for i in `seq 2 6` ; do systemctl enable getty@tty$i.service; done on a system without dbus, would statically enable a getty on vt2-6. I know, but I don't think we want to make the user have to do that. So we could simply document this fact (in README.Debian, release notes etc). The alternative would be, to bump dbus to priority standard, so it's installed by default (on new installations). It is already priority standard. That is not enough to make it part of the base system though. A third idea would be to have a generator, which creates the getty@tty$i.service symlinks in /run/systemd/system/getty.target.wants Implementing that in shell, would only take a couple of lines. We should be careful though, to add yet another generator. Yes :/ Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109190412.gg3...@type.youpi.perso.aquilenet.fr
vt2-6 still not available with base system
Hello, I've just checked this morning with the latest netboot, when installing just the base system with no task, dbus does not get installed, and thus vt2-6 do not have a login banner because systemd-logind needs dbus for that. In 758111, systemd was made to recommend dbus so that it works on system upgrade, and in 759293 dbus was made priority standard in the archive. But this is not enough for making d-i install dbus on just a base system. Just to make sure we agree on this: do we want to install dbus in a base system without the standard task? It's not very big: 1MiB installed files. It is also getting more and more used by basic things in the system. And not getting vt2-6 working on a base system is a bit ew. Opinions? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141108115406.ga13...@type.youpi.perso.aquilenet.fr
Bug#767432: main-menu: please give a way to change the frontend
Package: main-menu Severity: normal User: debian-accessibil...@lists.debian.org Usertags: a11y Hello, Depending on the input and output accessibility helpers used by the user, one frontend or the other will be more convenient, it would be useful to be able to change the frontend during installation. More specifically, a typical example is starting the installer with the speech synthesizer (with thus enables the text frontend, way more suited to speech synthesis), but only to start brltty by hand on VT2 with special options needed by the particular braille device to be used, and then one would like to switch the frontend to newt, which is more convenient with a braille device. AIUI, it shouldn't be hard to do, it would be a matter of restarting main-menu with the selected frontend. It could be a mere entry in the main menu, similar to the change debconf priority. Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel N sl - display animations aimed to correct users who accidentally enter Nsl instead of ls. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141030234958.ga18...@type.youpi.perso.aquilenet.fr
Bug#766815: installation-reports: please omit quiet option
lee, le Sun 26 Oct 2014 02:44:01 +0100, a écrit : I strongly recommend to change the installer to *not* use the quiet option. Well, you can use the expert boot entry for this. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141026073828.gx3...@type.youpi.perso.aquilenet.fr
Bug#763695: console-setup is slowest part of boot, not fast as setupcon manpage tells us
Julian Andres Klode, le Wed 01 Oct 2014 23:31:18 +0200, a écrit : console-setup requires 800ms during a boot. That's odd, it shouldn't be taking so long, thanks to the caching in /etc/console-setup/cached.kmap.gz. You should probably check what is happening there. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141001223122.gl9...@type.youpi.perso.aquilenet.fr
Re: brltty_5.0-3_amd64.changes ACCEPTED into unstable
Cyril Brulebois, le Mon 29 Sep 2014 22:36:09 +0200, a écrit : [ Paul Gevers ] * Improved timestamp fix in man pages to be independent of locales and file timestamps (Closes: #708585) . [ Samuel Thibault ] * Team upload. * Append the d-i -inherited configure to the end of brltty.conf instead of dropping it (which was thus losing the documentation for the user). * patches/90-zh-lang-fix.patch: Fix zh translation syntax. * brltty-udeb.prebaseconfig: Enable accessibility in XFCE, LXDE and MATE sessions too. * Bump Standards-Version to 3.9.6 (no changes). So having this for the upcoming D-I Jessie Beta 2 release would make sense. How confident are you with this upload (now built everywhere)? Should I push it to testing right now? I'm very confident with the upload, it'd be good to have it for d-i B2. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929204031.ga3...@type.youpi.perso.aquilenet.fr
Bug#763005: installation-guide-amd64: website for wheezy leads to jessie installation guide
Hello, Ross Boylan, le Fri 26 Sep 2014 18:23:19 -0700, a écrit : On http://www.debian.org/releases/stable/installmanual I selected the link for amd64 pdf, http://www.debian.org/releases/stable/amd64/install.pdf.en. When I view this it says that it is the installation guide for Debian 8, jessie. See, e.g., the 2nd page. When I saw this bug report, I checked the pdf, and it was indeed a jessie manual. Now that I have a look again, it's back being wheezy, with Last-Modified: Sun, 28 Sep 2014 02:57:36 GMT so I guess somebody fixed it early this morning? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928204450.gu7...@type.youpi.perso.aquilenet.fr
Bug#762426: setup.exe does work, it just pops up an extra browser window
積丹尼 Dan Jacobson, le Mon 22 Sep 2014 15:09:16 +0800, a écrit : At least that's how it was when I used a 2010 installation disk I had lying around last week. Which was 4 years ago, with at best Lenny. We are preparing Jessie, not Lenny. Please re-test with Jessie. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140924002411.gy2...@type.youpi.perso.aquilenet.fr
Re: Bug#762024: installation-guide-amd64: Please add caution warning to instructions to create a usb bootable stick
Control: tags -1 + pending Ben Hutchings, le Thu 18 Sep 2014 16:58:56 +0100, a écrit : As people are still making this mistake, I would suggest explicitly saying The image must be written to the whole-disk device and not a partition, e.g. /dev/sdb and not /dev/sdb1. I have commited it, thanks. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140919165803.GG2332@type
Re: Installation manual upload?
Karsten Merker, le Sun 14 Sep 2014 20:37:12 +0200, a écrit : I currently have some small uncommitted changes to the english manual in my local working tree. Is it ok to do further commits for now or should I postpone them until after the package has been uploaded? It's now uploaded, you can feel free to commit. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916112540.ge2...@type.bordeaux.inria.fr
d-i installation manual bits for arm64 and ppc64el
Hello, One of the things that needs to get added for arm64 and ppc64el is the installation manual bits. For now I have just commited the basics, so you can $ debcheckout installation-guide $ cd installation-guide/build $ ./buildone arm64 en pdf $ ./buildone ppc64el en pdf to get it built. What porters need to do is to add information specific to their arch. For arm64 = For now, arm64 is just like armel and armhf, I guess they won't differ so much. At least these files will however probably have to be updated to document some board-specific details: - en/hardware/supported/arm.xml - en/hardware/hardware-supported.xml - en/install-methods/download/arm.xml - en/preparing/bios-setup/arm.xml - en/boot-installer/arm.xml - en/using-d-i/modules/arm/flash-kernel-installer.xml It's probably useful to also look around at paragraphs marked with arch=arm For ppc64el === For now, ppc64el is just like powerpc, I guess it may be useful to distinguish them so as to drop the documentation for elder hardware? en/hardware/hardware-supported.xml will have to be updated. At least these files will probably have to be updated: - en/hardware/supported/powerpc.xml - en/hardware/hardware-supported.xml - en/install-methods/floppy/powerpc.xml - en/install-methods/usb-setup/powerpc.xml - en/preparing/bios-setup/powerpc.xml - en/boot-installer/powerpc.xml - en/using-d-i/modules/powerpc/yaboot-installer.xml - en/using-d-i/modules/powerpc/quik-installer.xml It's probably useful to also look around at paragraphs marked with arch=ppc64el Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916121101.gf2...@type.bordeaux.inria.fr
Re: Installation manual upload?
Karsten Merker, le Sun 14 Sep 2014 20:37:12 +0200, a écrit : On Sun, Sep 14, 2014 at 07:13:33PM +0200, Cyril Brulebois wrote: last manual upload was 20131009 which is a while ago. Since we're closing in for a Jessie Beta 2 release, it'd be nice to have current svn uploaded soon. I'm not sure whether some translations are pending though. I currently have some small uncommitted changes to the english manual in my local working tree. Is it ok to do further commits for now or should I postpone them until after the package has been uploaded? If the changes are indeed small, it's probably better for non-english people to have the old, but translated, documentation, rather than having the new but untranslated documentation. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915112824.ge3...@type.bordeaux.inria.fr
Re: Installation manual upload?
Cyril Brulebois, le Sun 14 Sep 2014 19:13:33 +0200, a écrit : last manual upload was 20131009 which is a while ago. Since we're closing in for a Jessie Beta 2 release, it'd be nice to have current svn uploaded soon. I'm not sure whether some translations are pending though. Christian, what do you think? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915114318.gg3...@type.bordeaux.inria.fr
Re: default desktop: availability on all arches
Steven Chamberlain, le Wed 10 Sep 2014 11:56:58 +0100, a écrit : What happens otherwise if trying to start GNOME3 (or others)? * without 3D, with llvmpipe * without both Does it fall back gracefully to a fallback/flashback mode, and does that still work these days? In this mode would it still meet the 'accessibility' or other criteria already on the Wiki page? Accessibility is independent from the actual rendering. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910112256.gc10...@type.bordeaux.inria.fr
Bug#760992: debian-installer: i18n: doesn't load keyboard layout that was just set
Control: reassign -1 debian-live Tamás Tardos, le Wed 10 Sep 2014 00:03:44 +0200, a écrit : Hi and thanks for your quick responses. The exact ISOs are: debian-live-7.6.0-amd64-xfce-desktop.iso debian-live-7.6.0-amd64-kde-desktop+nonfree.iso With both of these I'm able to reproduce the bug by booting into the live system, selecting the installer launcher and running it. After I set my keymap, it remains English. However, I found out that this bug doesn't occur if I directly boot into the installation (either the graphical or the text-based) from the same disk. So if I select Live at boot time, I get only English keymap, but if I select Install, it sets my layout correctly. Ah, this is a bug in debian-live then, not the installer. I have just tried with an old debian-live-7.2-i386-lxde-desktop.iso image I had on my harddisk, there was no bug there. Perhaps the difference is 7.2 vs 7.6, perhaps the difference is lxde vs xfce/kde. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910222929.go3...@type.youpi.perso.aquilenet.fr
Bug#760992: debian-installer: i18n: doesn't load keyboard layout that was just set
Hello, Tardos Tamás, le Tue 09 Sep 2014 20:17:40 +0200, a écrit : My language is Hungarian (magyar). Although the installer asks for my keyboard layout, this choice only affects the final installed system: the installer doesn't instantly load the keymap as I would expect. That is not expected indeed. I have however tested it with debian-7.4-amd64-mini.iso and debian-jessie-DI-b1-amd64-netinst.iso, in both cases I selected the Hungarian language (Magyar), then Magyarorsźag, and magyar layout, and in the next text field when I pressed the first keyboard row, I got qwertz, so at least the keyboard layout changed. I don't know the hungarian layout, so I can't tell whether it is right, but pressing keys on the right of 9 brings ö, ü, ó, and with other keys I could type í, ú, á, etc. so it seems like hungarian. So, as KiBi said, please tell us which ISO image you used exactly, otherwise it's unreproducible for us. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140909190515.gp4...@type.youpi.perso.aquilenet.fr
Bug#760778: [Pkg-xfce-devel] Bug#760778: xfce4-session: Please depend on gnome-orca
Yves-Alexis Perez, le Mon 08 Sep 2014 10:37:34 +0200, a écrit : What I'm against is forcing stuff onto users which have exactly no need for it. With that kind of reasoning we would install the complete set of packages in every installed system “just in case”. There is a big difference in the case of accessibility: the user needing it can't use the computer *at all*. And again, I fail to see why this is about Xfce desktop. One can use GTK stuff in a KDE desktop where I guess GTK+ a11y would work. One could be blind and don't use a full DE but just a window manager. Well, the window manager needs to be accessible too, otherwise it's quite inconvenient, but at least that allows to access some applications indeed. I fail to see why a11y would be important enough to force it to Xfce installations while not beeing important enough to force it to default installations. Right, we can probably add it to task-desktop instead. Joey? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140908085850.go3...@type.bordeaux.inria.fr
Re: Bug#760778: [Pkg-xfce-devel] Bug#760778: xfce4-session: Please depend on gnome-orca
Michael Biebl, le Mon 08 Sep 2014 14:30:56 +0200, a écrit : I fail to see why a11y would be important enough to force it to Xfce installations while not beeing important enough to force it to default installations. Right, we can probably add it to task-desktop instead. Joey? I'm not sure if this is the right approach. Isn't there a risk that alternative desktop environments (MATE, KDE, Cinnamon, LXDE,you name it) use other components then gnome-orca to implement a11y? There is extremely little probability that this happens. There is already little manpower to implement the server part (which has to be implemented anyway before thinking about writing the client part); nobody will spend time on implementing another client than orca. ATM there is no such thing, and there will not be any for Jessie. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140908124002.gl3...@type.bordeaux.inria.fr
Re: accessibility of jessie desktops
Joey Hess, le Sat 06 Sep 2014 12:44:29 -0400, a écrit : When I select Enable assitive technologies in xfce4-accessability-settings, it claims that it will start the required applications for screen readers and magnifiers. But if it does, I can't tell. It doesn't. First, due to a bug in lightdm, see #760740 After that bug is fixed, xfce4-session indeed starts at-spi-bus-launcher and at-spi2-registryd, but that's only the server part of the accessibility stack. orca also needs to have been installed (currently it is not), and be started. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907130309.gj20...@type.youpi.perso.aquilenet.fr
Re: accessibility of jessie desktops
Samuel Thibault, le Sun 07 Sep 2014 15:03:09 +0200, a écrit : After that bug is fixed, xfce4-session indeed starts at-spi-bus-launcher and at-spi2-registryd, but that's only the server part of the accessibility stack. orca also needs to have been installed (currently it is not), and be started. Ah, but that is actually handled by the gnome-orca package itself. So all xfce4-session needs to do is to depend on gnome-orca, just like gnome does. orca will auto-start only if the gsettings for it is enabled. There is just a missing change in orca for this to work with XFCE, I'll handle that. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907181420.gy20...@type.youpi.perso.aquilenet.fr
Re: [Pkg-xfce-devel] Bug#760778: xfce4-session: Please depend on gnome-orca
Yves-Alexis Perez, le Sun 07 Sep 2014 21:06:43 +0200, a écrit : ATM, with a fresh XFCE installation, enabling Enable assitive technologies does not actually start the orca screen reader, because the screen reader does not get installed along the XFCE installation. XFCE should thus depend on the gnome-orca, just like gnome depends on gnome-orca for instance. I guess xfce4-session would be the natural choice for this dependency, thus assigning to this package. Note: for now, Orca will not actually start because of bugs 760777 and 760740, but that's not a reason for not adding the dependency in XFCE already. Orca is in no way a dependency (neither a recommends, actually) of the Xfce desktop environment, so sorry, no. Well, for a blind user, it *is*!... Anyhow, what do you propose to fix the accessibility of XFCE? Adding the dependency to task-xfce-desktop? (Cc-ed) Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907191338.gk20...@type.youpi.perso.aquilenet.fr
Re: [Pkg-xfce-devel] Bug#760778: xfce4-session: Please depend on gnome-orca
Yves-Alexis Perez, le Sun 07 Sep 2014 21:15:19 +0200, a écrit : On dim., 2014-09-07 at 21:13 +0200, Samuel Thibault wrote: Well, for a blind user, it *is*!... Sure, but not everyone's blind. And not everyone speaks all languages on earth, yet we install all language files by default, which really eats a lot of disk by default, just because we can't know when one will need it because a random user happens to need it. That is the same with accessibility. I sympathise with a11y, but forcing gnome-orca on everyone won't happen. Well, that is actually precisely our goal: to have gnome-orca installed on all systems, ready to be started in case one needs it. There is this very simple scenario: you welcome a blind guest at home, and he'd like to use the home computer. Currently, with XFCE, you'd click on Enable assistive technologies, and unlog/relog. But nothing happens, no speech. You then have to connect to the Internet (who knows whether it works that day), look for why this is not working, eventually understand that you need to install the gnome-orca package, install it, etc. and at last it works. Another typical scenario is a public library with computers: there is very little hope that the user will manage to find out how to contact the sysadmin to get gnome-orca installed (and there is very little hope that the sysadmin will have already thought about installing it), so he will just not be able to use the computer at all. Yes, real accessibility means being available, ready to be enabled. Any barrier is really a killing pain for disabled people. Anyhow, what do you propose to fix the accessibility of XFCE? Adding the dependency to task-xfce-desktop? (Cc-ed) That's exactly the same thing. Just create an a11y subtask or whatever, bringing everything needed? That won't change the fact that we'll want to always install it by default (thus at least via a Recommends) Just to bring the figure in the discussion: from a base system, installing task-xfce-desktop without Orca uses 1596MiB. Adding Orca brings 1658MiB, so that's just a 3% increase. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907195342.gm20...@type.youpi.perso.aquilenet.fr
Re: accessibility of jessie desktops
Samuel Thibault, le Sun 07 Sep 2014 20:14:20 +0200, a écrit : Samuel Thibault, le Sun 07 Sep 2014 15:03:09 +0200, a écrit : After that bug is fixed, xfce4-session indeed starts at-spi-bus-launcher and at-spi2-registryd, but that's only the server part of the accessibility stack. orca also needs to have been installed (currently it is not), and be started. Ah, but that is actually handled by the gnome-orca package itself. So all xfce4-session needs to do is to depend on gnome-orca, just like gnome does. orca will auto-start only if the gsettings for it is enabled. There is just a missing change in orca for this to work with XFCE, I'll handle that. This is Bug#760777 and Bug#760778. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907212502.ga23...@type.youpi.perso.aquilenet.fr
Re: [Pkg-xfce-devel] Bug#760778: xfce4-session: Please depend on gnome-orca
Control: reassign -1 task-xfce-desktop Control: tags -1 - wontfix Yves-Alexis Perez, le Sun 07 Sep 2014 22:23:34 +0200, a écrit : On dim., 2014-09-07 at 21:53 +0200, Samuel Thibault wrote: Yves-Alexis Perez, le Sun 07 Sep 2014 21:15:19 +0200, a écrit : On dim., 2014-09-07 at 21:13 +0200, Samuel Thibault wrote: Well, for a blind user, it *is*!... Sure, but not everyone's blind. And not everyone speaks all languages on earth, yet we install all language files by default, which really eats a lot of disk by default, just because we can't know when one will need it because a random user happens to need it. That is the same with accessibility. Last time I did an install, a debconf question was actually asking about the locale. Sure, but it still installs mostly all translations. I sympathise with a11y, but forcing gnome-orca on everyone won't happen. Well, that is actually precisely our goal: to have gnome-orca installed on all systems, ready to be started in case one needs it. Then it's unrelated to Xfce, and you want to include that in the base system. Not in the base system, since the base system doesn't have X. But in all graphical tasks where it makes sense, yes (it doesn't make sense for KDE yet for instance, since qt is still completely inaccessible). I'm sure you can find a lot of slightly convoluted scenarios. I'm sure we can find a lot of them for a lot of packages, actually. Yes, and that's something that people can usually work around. Here, they can't. Just to bring the figure in the discussion: from a base system, installing task-xfce-desktop without Orca uses 1596MiB. Adding Orca brings 1658MiB, so that's just a 3% increase. That's not just a question of installed size. A lot of people want to keep a somehow minimal system in term of disk, memory, CPU time, and which doesn't get in their way. And some actually chose Xfce *for* that. I am here talking *only* about installed size, precisely. I'm not asking for always starting Orca. I'm asking for making it available, ready to be enabled, I'm not asking for it to be enabled by default. That won't consume any memory or CPU time, just a few dozen MiB more (which is roughly indistinguishable from the usual release+1 increase in installed size). In any case, the original bug was about adding dependency to xfce4-session, and the answer is no (and the same applies to the xfce task). If you want to add gnome-orca to the base system, I don't think it's the right place. As said above, that can't fit the base system, only the graphical tasks, thus task-xfce-desktop at best. Reassigning it there for now. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907215350.gr20...@type.youpi.perso.aquilenet.fr
Re: accessibility of jessie desktops
Hello, MENGUAL Jean-Philippe, le Sat 06 Sep 2014 00:25:05 +0200, a écrit : I don't know exactly what's expected (should 9e an]ier here? on the wiki? etc)? I have filled the wiki with a summary of your answer. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140906123257.gf20...@type.youpi.perso.aquilenet.fr
Re: accessibility of jessie desktops
BTW, I would like to emphasize that it's very good news that tasksel people care about accessibility for the default choices, that's really good for getting mainstream accessibility! Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140906123725.gg20...@type.youpi.perso.aquilenet.fr
Bug#759290: debian-installer: 'Automated install' does not delay the locale and keyboard questions
Andreas B. Mundt, le Tue 26 Aug 2014 08:16:01 +0200, a écrit : Before, I was using the method B.2.5. Using a DHCP server to specify preconfiguration files described in [1]. Is there a reason not to delay the questions with that method? Probably not, and then it's a bug indeed. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826092108.gh5...@type.youpi.perso.aquilenet.fr
Bug#759290: debian-installer: 'Automated install' does not delay the locale and keyboard questions
Control: tags -1 + pending Hello, Andreas B. Mundt, le Tue 26 Aug 2014 08:16:01 +0200, a écrit : Before, I was using the method B.2.5. Using a DHCP server to specify preconfiguration files described in [1]. Is there a reason not to delay the questions with that method? This apparently takes back March 2010: locale kbd selection was disabled only on explicit URL on boot parameters. I've made it always done whenever auto is enabled, as I don't see why we shouldn't do it. Fixing fully-automated-from-dhcp seems more important to me than the inconvenience of a qwerty layout for typing the URL if really none is available. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826100413.gk5...@type.youpi.perso.aquilenet.fr
Bug#759336: linux-i386 lowmem install: anna fails with ENOSPC
Steven Chamberlain, le Tue 26 Aug 2014 13:48:53 +0100, a écrit : Using: http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386/current/images/netboot/mini.iso wheezy install guide suggests a minimum of 80MB RAM to run d-i. But even with 128MB RAM, not choosing any additional components, I saw this issue during anna: These figures haven't been updated for Jessie yet indeed. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826130059.ga3...@type.bordeaux.inria.fr
Bug#759336: linux-i386 lowmem install: anna fails with ENOSPC
Steven Chamberlain, le Tue 26 Aug 2014 14:10:51 +0100, a écrit : I should be able to help with that, I'll already be testing lots of low-memory installs, in order to find a good size for the kfreebsd d-i ramdisks. Well, the testing has to be done for each architecture, since that change quite a bit depending on the arch. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826131530.gc3...@type.bordeaux.inria.fr
Bug#759336: linux-i386 lowmem install: anna fails with ENOSPC
Steven Chamberlain, le Tue 26 Aug 2014 14:10:51 +0100, a écrit : It's odd that there still seemed to be ~50% free memory when this problem happened, though. Is there some maximum size that the linux-i386 root ramdisk can grow to? There seems to be something odd somewhere indeed. Just trying to update the lowmem value for amd64 brings me from 109MiB to 164MiB, that's a big jump! I guess the kernel somehow now has a heuristic to limit the rootfs size. When using 163MiB, I hit a bug when lvm tries to start, and indeed / is said to be full while free shows 44MiB free. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826134625.ge3...@type.bordeaux.inria.fr
Bug#759336: linux-i386 lowmem install: anna fails with ENOSPC
Samuel Thibault, le Tue 26 Aug 2014 15:46:25 +0200, a écrit : Steven Chamberlain, le Tue 26 Aug 2014 14:10:51 +0100, a écrit : It's odd that there still seemed to be ~50% free memory when this problem happened, though. Is there some maximum size that the linux-i386 root ramdisk can grow to? There seems to be something odd somewhere indeed. Just trying to update the lowmem value for amd64 brings me from 109MiB to 164MiB, that's a big jump! I guess the kernel somehow now has a heuristic to limit the rootfs size. When using 163MiB, I hit a bug when lvm tries to start, and indeed / is said to be full while free shows 44MiB free. In /proc/mounts, one can read for the rootfs on / a size= value, which seems to be half the memory size. That's probably the culprit, perhaps it can be worked around somehow for d-i at least. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826134932.gf3...@type.bordeaux.inria.fr
Bug#759336: linux-i386 lowmem install: anna fails with ENOSPC
Steven Chamberlain, le Tue 26 Aug 2014 14:48:30 +0100, a écrit : On 26/08/14 14:15, Samuel Thibault wrote: Steven Chamberlain, le Tue 26 Aug 2014 14:10:51 +0100, a écrit : I should be able to help with that, I'll already be testing lots of low-memory installs, in order to find a good size for the kfreebsd d-i ramdisks. Well, the testing has to be done for each architecture, since that change quite a bit depending on the arch. If we say in the install manual that a particular arch needs 80MiB RAM to run d-i, do you think we should have a Jenkins job that runs installs in a Qemu VM having exactly that amount? So we know if/when that stops being the case? That could be useful indeed. I don't know how jenkins works exactly, but it needs to really go through the dialog boxes (selection portuguese as language, etc.) Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826135058.gg3...@type.bordeaux.inria.fr
Bug#759336: linux-i386 lowmem install: anna fails with ENOSPC
Samuel Thibault, le Tue 26 Aug 2014 15:49:32 +0200, a écrit : In /proc/mounts, one can read for the rootfs on / a size= value, which seems to be half the memory size. That's probably the culprit, perhaps it can be worked around somehow for d-i at least. Indeed: static unsigned long shmem_default_max_blocks(void) { return totalram_pages / 2; } which probably makes sense for an installed system, but not for an installer. We can however do this early at boot: mount / -o remount,size=$(( $(grep ^MemTotal: /proc/meminfo | { read x y z; echo $y; }) * 1024 ) notably before unpacking .udebs, S15lowmem would probably be a fine place for this? (it notably already does the computation trick) Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826140510.gh3...@type.bordeaux.inria.fr
Re: Debian Installer Jessie Beta 1 release
cstrobel, le Tue 26 Aug 2014 20:31:55 -0400, a écrit : Are you saying XFCE is the problem? Yes. Is there going to be an updated installer you want me to test again, or what do you suggest to get ORCA working?? You can use a gnome image, such as http://cdimage.debian.org/cdimage/jessie_di_beta_1/amd64/iso-cd/debian-jessie-DI-b1-amd64-gnome-CD-1.iso Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827003929.gy4...@type.youpi.perso.aquilenet.fr
Bug#712907: grub-installer: No longer installs automatically on a normal machine with one hard drive
Cyril Brulebois, le Thu 20 Mar 2014 14:51:32 +0100, a écrit : Salvatore Bonaccorso car...@debian.org (2014-03-20): It looks bootdev could be preseeded[1], at least for a test for a VM preseed the following worked for me: d-i grub-installer/bootdev string /dev/vda [1] https://bugs.debian.org/666974 But having string (hd0) does not seem to work here (have not checked why), which would be nicer to have more generalised preseed files as previous possible (for say when having machines having a /dev/vda or a /dev/sda ...). First of all, I'm not familiar with d-i best practices. So maybe the following won't make sense. We could imagine either proposing another variable which would take specifications like “(hd0)” and do what's needed to convert them back to /dev/foo stuff, or detect (based on what? parens?) when a conversion is needed for the bootdev variable that was passed, and do that. Well, grub-installer actually already does something like this in the auto-detect phase. It tries to be very careful about not using an hd0 that would actually be a USB stick, but apparently (considering the bug reports we have seen) it's not reliable enough. We at the very least need to document this in the preseed file of the installer, and probably in the relase as this will hit all automated installations. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140825224515.ga9...@type.youpi.perso.aquilenet.fr
Bug#759290: debian-installer: 'Automated install' does not delay the locale and keyboard questions
Control: tags -1 unreproducible Andreas B. Mundt, le Mon 25 Aug 2014 23:19:03 +0200, a écrit : when experimenting with unattended installations using PXE-boot and preseeding d-i, I did not find the 'Automated install' (auto mode) working as described in [1]: The auto kernel parameter is an alias for auto-install/enable and setting it to true delays the locale and keyboard questions until after there has been a chance to preseed them ... When I choose 'Automated install' from the 'Advanced options' menu, the first questions show up nevertheless (before setting up the network) and I have to answer them or preseed them on the kernel boot line. Could it be that the delaying functionality got lost? No, it is still there, but only if you provide some preseeding URL on the boot line or CD image etc. Otherwise it will prompt for the URL, and I guess that while at it, there's no point in not configuring the keyboard before that. At any rate, booting jessie b1 with the Automated install boot entry and passing url=http://dept-info.labri.fr/~thibault/preseed-jessie.txt on the kernel command line does install a Debian system without any prompt. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140825235217.ge3...@type.youpi.perso.aquilenet.fr
Re: Debian Installer Jessie Beta 1 release
Cyril Brulebois, le Fri 22 Aug 2014 01:43:07 +0200, a écrit : Given what I mentioned above, I think what's in debian-installer should just work as it previously did? I have tested it again with the gnome desktop and it works fine indeed. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140824125238.gc3...@type.youpi.perso.aquilenet.fr
Re: Debian Installer Jessie Beta 1 release
Hello, Luke Yelavich, le Fri 22 Aug 2014 11:05:17 +1000, a écrit : You would probably have to set the correct gsettings keys for the login user. We already do it for gdm actually. In Ubuntu I have things set up to set appropriate settings up for lightdm and the unity greeter. Ah, these could be useful indeed, where can I find them? The gsettings command-line tool can be used to do this. Note you do need dbus and dconf installed and working for this to work. That is already working for gdm. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140824125727.gd3...@type.youpi.perso.aquilenet.fr
Re: Bug#757987: kfreebsd: cannot create swap space
Steven Chamberlain, le Fri 22 Aug 2014 14:42:45 +0100, a écrit : mkswap, and the whole format_swap script, is of no use to kfreebsd (or hurd I presume - please correct me if I'm wrong) hurd uses the same format as Linux, do not disable formatting swap there. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140822134814.gb3...@type.bordeaux.inria.fr
Bug#739989: espeak: build proper library udeb so that espeakup doesn't have to be statically linked and hence break on upstream version changes
Control: reopen 739989 Oops, sorry, I replied to the original mail, and thus closed the original bug, while I wanted to close the clone. This should be fixing it. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140822231548.ga14...@type.youpi.perso.aquilenet.fr
Re: d-i's purpose (was: Cannot find debian-installer/main-menu doesn't exist in menu)
Steven Chamberlain, le Thu 21 Aug 2014 14:00:06 +0100, a écrit : d-i images may be very small, but I haven't found it practical on embedded systems, which may not even have working VGA or networking; That's fine. I actually don't usually use VGA or network on servers, but simply a serial port. The d-i running live way is already available in the debian live CD-ROMs. I don't know how easy they are to produce, though. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821142315.gk3...@type.bordeaux.inria.fr
Re: hurd-i386 daily build status
Cyril Brulebois, le Thu 21 Aug 2014 17:51:23 +0200, a écrit : Builds have been missing for a week. Can you please have a look? I missed making the incoming.d.o change there indeed. It's polluting monitoring. Which monitoring? Are some mails sent somewhere? I guess I missed that. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821212743.gn3...@type.youpi.perso.aquilenet.fr
Re: hurd-i386 daily build status
Cyril Brulebois, le Thu 21 Aug 2014 23:43:48 +0200, a écrit : Samuel Thibault sthiba...@debian.org (2014-08-21): It's polluting monitoring. Which monitoring? Are some mails sent somewhere? I guess I missed that. Talking about: | Architectures with missing build: | | hurd-i386 on http://d-i.debian.org/daily-images/daily-build-overview.html Ok, that's indeed the page I had just added to my watchlist. Thanks. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821220021.gq3...@type.youpi.perso.aquilenet.fr
Re: Debian Installer Jessie Beta 1 release
Hello, cstrobel, le Mon 18 Aug 2014 22:11:54 -0400, a écrit : I installed Jessie using a Braille display. Debian-Jessie-DI-b1-amd64-net inst.iso I tried to get Orca going like this. Ah. Normally Orca should automatically start at gdm and in the user session if installation was done with a braille device or speech synthesis. Does anybody in d-accessibility how one is supposed to enable accessibility in gdm with some shell script (probably calling some gconftool-2 or using some schema)? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821233612.gt3...@type.youpi.perso.aquilenet.fr
Re: Debian Installer Jessie Beta 1 release
Cyril Brulebois, le Fri 22 Aug 2014 01:43:07 +0200, a écrit : Samuel Thibault sthiba...@debian.org (2014-08-22): Hello, cstrobel, le Mon 18 Aug 2014 22:11:54 -0400, a écrit : I installed Jessie using a Braille display. Debian-Jessie-DI-b1-amd64-net inst.iso I tried to get Orca going like this. Ah. Normally Orca should automatically start at gdm and in the user session if installation was done with a braille device or speech synthesis. FWIW installing gnome with speech synthesis led me to have orca both at the gdm prompt and in the user session, Ah, then perhaps it's just the braille case which is broken. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821234851.gu3...@type.youpi.perso.aquilenet.fr
Re: Debian Installer Jessie Beta 1 release
Cyril Brulebois, le Fri 22 Aug 2014 01:53:39 +0200, a écrit : Samuel Thibault sthiba...@debian.org (2014-08-22): Ah, then perhaps it's just the braille case which is broken. (You lost the submitter in your reply.) The submitter said the netinst image was used. So xfce/lightdm were presumably installed. Ah, right. We could make braille speech preseed installing gnome if not preseeded already (from explicit boot menu choice ending up on the kernel command line or other preseeding methods). I'm not sure installing gnome-orca is sufficient since finish-install.d/07speakup only sets gnome schema things? It's not sufficient indeed. The braille case does the same schema things. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140822000541.gw3...@type.youpi.perso.aquilenet.fr
Re: Bug#758757: kfreebsd-10: d-i bugs caused by qemu-system-i386+kvm
Cyril Brulebois, le Thu 21 Aug 2014 02:03:48 +0200, a écrit : Steven Chamberlain ste...@pyro.eu.org (2014-08-21): On 21/08/14 00:23, Steven Chamberlain wrote: Using qemu-system-i386 with the -smp 2 flag, I started seeing weird issues early in d-i: It seems more likely this was triggered by -enable-kvm (on a wheezy linux-amd64 host). Without that flag it looks reliable so far, even with -smp 2 (but I'm worried it could be non-deterministic). While this might be a bug in the emulation layer indeed, another view would be that -enable-kvm means stuff go quicker and you might have higher chances of hitting race conditions. Without -enable-kvm, one only gets software simulation, which exposes extremely little concurrency indeed: there is no real concurrent execution at all, and just periodic execution switch from one virtual CPU to another. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821001142.gg21...@type.youpi.perso.aquilenet.fr
Re: localechooser_2.63_amd64.changes ACCEPTED into unstable
Cyril Brulebois, le Sat 02 Aug 2014 02:31:22 +0200, a écrit : Debian FTP Masters ftpmas...@ftp-master.debian.org (2014-04-02): localechooser (2.63) unstable; urgency=high it'd be nice to stick to $version rather than debian/$version as far as git tags go. Mmm, I indeed didn't notice that. I had just used git-buildpackage --git-tag-only, thinking that it would Do The Right Thing, as it usually does in other repositories. It would probably make sense to put a gbp.conf file in the repositories which use that format? I've pushed a 2.63 tag to localechooser.git accordingly. Thanks, Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821002227.gk21...@type.youpi.perso.aquilenet.fr
Bug#485586: debian-installer: Default to graphical install
Cyril Brulebois, le Mon 18 Aug 2014 23:36:03 +0200, a écrit : +notepara + +The graphical installer requires significantly more memory to run than +the regular installer: minimum-memory-gtk;. If insufficient memory is +available, it will automatically fall back to the regular +quotenewt/quote frontend. + +/parapara + +If the amount of memory in your system is below minimum-memory;, +the graphical installer may fail to boot at all while booting the +regular installer would still work. Using the regular installer is +recommended for systems with little available memory. + +/para/note I'm not sure since I tend to use 1GB RAM every time, but I thought there was some fallback mechanism in place? There is, but atm with 128MiB RAM it doesn't even boot, just because the initrd is so big that we don't even get to boot to the point of the fallback script. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818214931.gh8...@type.youpi.perso.aquilenet.fr
Bug#485586: debian-installer: Default to graphical install
Helloo, Holger Wansing, le Mon 18 Aug 2014 23:07:11 +0200, a écrit : Basically I moved the chapter Appendix D.6. The Graphical Installer to 5.1.8 (at the end of Booting the installer on 32-bit PC), leaving the content unchanged. And I moved chapter Appendix D.6.1. Using the graphical installer to 6.1.1 (at the end of How the Installer Works), leaving the content mostly unchanged (only the first line differs). That seems sensible indeed. It would be very convenient, whenever you commit this, to actually remove the old text, so it's really a move :) Also, please do the same move in all the .xml translations, so that translators don't have to do anything about it. The po translations shouldn't need any change. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818214812.gg8...@type.youpi.perso.aquilenet.fr
Re: Bug#485586: debian-installer: Default to graphical install
Cyril Brulebois, le Tue 19 Aug 2014 01:17:02 +0200, a écrit : = debian-accessibility@: if we go from i386 to amd64 by default, is there anything that needs to be done on your side (doc update etc.) Normally, only the installer manual would need an update. I don't see the multi-arch boot menu documented there, however. that we should coordinate with you? As far as I can see, right now we have s = i386, s + down arrow = amd64. This change would mean s = amd64, s + up arrow = i386. I'm not sure that changing the shortcuts are a good thing, to be honest, but being consistent as far as the default architecture is concerned would probably be G good idea anyway. :/ It happens that we have apparently never documented the case of the multiarch image on http://wiki.debian.org/accessibility , so there is no actual regression with the change. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818233805.gs8...@type.youpi.perso.aquilenet.fr
Bug#758476: d-i manual: part about bootloader installation is missing in example preseed file 'preseed.txt'
Control: tags -1 + pending Holger Wansing, le Sun 17 Aug 2014 22:59:19 +0200, a écrit : The relevant paragraph was set to arch=any-x86 with this commit: http://anonscm.debian.org/viewvc/d-i/trunk/manual/en/appendix/preseed.xml?r1=65001r2=65009 This attribute works for building the manual itself, but it fails for the preseed.pl script, which generates the preseed.txt file. In the perl script it is documented that 'condition' attributes and 'arch' attributes are supported by the script, but there are apparently some problems. Indeed, it wasn't implementing the any and x86 magics. I have commited support for them, the bootloader section now gets in. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819001932.gw8...@type.youpi.perso.aquilenet.fr
Bug#745262: console-setup: Caps lock doesn't take effect on øæå (Danish characters)
Anton Zinoviev, le Thu 14 Aug 2014 13:53:41 +0300, a écrit : I don't like to upgrade the software of my computer too often. I suppose it is closer to wheezy than to jessie and that's why I don't see the problem. Well, you can probably set up a jessie or sid chroot. What is the output of perl -e 'printf %04X - %04X - %04X\n, hex(e6), ord(lc(pack(U,hex(00e6, ord(uc(pack(U,hex(00e6;' It has to be 00E6 - 00E6 - 00C6 € perl -e 'printf %04X - %04X - %04X\n, hex(e6), ord(lc(pack(U,hex(00e6, ord(uc(pack(U,hex(00e6;' 00E6 - 00E6 - 00C6 Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814113109.ga8...@type.bordeaux.inria.fr
Bug#745262: console-setup: Caps lock doesn't take effect on øæå (Danish characters)
Anton Zinoviev, le Wed 06 Aug 2014 20:39:02 +0300, a écrit : On Sun, Apr 20, 2014 at 10:35:23PM +0200, Samuel Thibault wrote: Andreas, le Sun 20 Apr 2014 03:30:13 +0200, a écrit : On the Linux console the caps lock key doesn't take effect on the Danish characters æøå. With caps lock on they are simply rendered æøå (lower case), and not ÆØÅ as one would expect. Oops, indeed, it seems the version in Jessie does not properly defines the ctrll layer for upper cases like it used to in Wheezy. See ckbcomp dk: keycode 39 = +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute +U+00e6 +U+00c6 dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute dead_acute dead_doubleacute It uses only +U+00e6 +U+00c6, while it should use +U+00c6 +U+00e6 for ctrll layers. I am unable to reproduce this. What locale do you use? I've tested with LC_ALL=C, LC_ALL=da_DK.utf8 and LC_ALL=da_DK. Well, whatever the locale, LC_ALL=C for instance, I get only +U+00e6 +U+00c6, and never +U+00c6 +U+00e6. I've tried both console-setup 1.102 and 1.111. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812224726.gc8...@type.youpi.perso.aquilenet.fr
Bug#757882: pkgsel: [text frontend] No feedback right after selecting the software tasks
Package: pkgsel Version: 0.42 Severity: normal Hello, This is a problem only with the test frontend, used by our speech synthesizer version. This can be tested easily by booting the installer with the Install with speech synthesis boot entry. Right after answering the Software selection tasksel question, one does not get any feedback, so the user is wondering whether it's installing anything. AIUI, the issue is that the title, Select and install software, has already been printed above, before the tasksel question, and when getting back to pkgsel, the title is not printed again. Perhaps it would be possible to separate software selection and installation, so that we have two titles? Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tasksel depends on: ii apt 1.0.6 ii cdebconf [debconf-2.0] 0.191 ii debconf [debconf-2.0] 1.5.53 ii liblocale-gettext-perl 1.05-8 ii perl-base 5.18.2-7 ii tasksel-data3.20 tasksel recommends no packages. tasksel suggests no packages. -- debconf information excluded -- Samuel Raize can you guys see what I type? vecna no, raize Raize How do I set it up so you can see it? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811215302.ga13...@type.youpi.perso.aquilenet.fr
Re: Reverting to GNOME for jessie's default desktop
Jonas Smedegaard, le Fri 08 Aug 2014 16:11:58 +0200, a écrit : The following is on a wheezy chroot: root@bastian:/# aptitude install task-gnome-desktop The following NEW packages will be installed: [...] Need to get 370 MB of archives. After unpacking 1099 MB will be used. root@bastian:/# aptitude install task-xfce-desktop The following NEW packages will be installed: [...] Need to get 115 MB of archives. After unpacking 348 MB will be used. Desktop needing 370MB versus 115MB seems pretty significant to me. Actually it's 1.1GiB versus 348MiB. But that is barring the rest of the desktop. More precise measurements can be found in the installation manual, for which we also install task-desktop etc. which ends up with 3.2GiB for Gnome KDE, 2.3GiB for XFCE, 2GiB for LXDE. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808141928.ge3...@type.bordeaux.inria.fr
Bug#757099: d-i manual: update relevant archs for jessie
Holger Wansing, le Tue 05 Aug 2014 11:57:46 +0200, a écrit : Package: installation-guide Tags: patch arch list for d-i manual needs an update (dropped architectures): Indeed, please commit. +#Package: installation-guide-s390 You can probably just remove it, like you did in archlist. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805101223.gq9...@type.youpi.perso.aquilenet.fr
Bug#756893: ram requirements for d-i: stats in d-i manual
Holger Wansing, le Mon 04 Aug 2014 11:22:06 +0200, a écrit : Cyril Brulebois k...@debian.org wrote: Holger Wansing li...@wansing-online.de (2014-08-03): the ram requirements needed to install with d-i stated in the d-i manual are not up-to-date. Indeed they are outdated since release of Wheezy and before. Read https://lists.debian.org/debian-boot/2013/05/msg00654.html and follow-ups, to get an idea what could be changed. Probably this should be updated now? Sure, please go ahead. Ok, so the decision is still open, which values to use. The procedure is documented in the lowmem's README file. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140804093344.gr3...@type.youpi.perso.aquilenet.fr
Bug#756893: ram requirements for d-i: stats in d-i manual
Holger Wansing, le Mon 04 Aug 2014 11:22:06 +0200, a écrit : So what needs to be changed? In https://lists.debian.org/debian-boot/2013/05/msg00662.html I have already proposed the following: Table 3.2. Recommended Minimum System Requirements Install TypeRAM (minimal) RAM (recommended) Hard Drive - No desktop 64 megabytes256 megabytes 1 gigabyte - With Desktop128 megabytes 512 megabytes 5 gigabytes + No desktop 128 megabytes 512 megabytes 1 gigabyte + With Desktop256 megabytes 1 gigabyte 5 gigabytes OK to commit this? That sounds reasonable to me, although we may want to double the hard drive part too (these are recommended values, not minimum values; I wouldn't recommend just 1GiB and 5GiB). Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140804093928.gs3...@type.youpi.perso.aquilenet.fr
Bug#756996: mentions of 2.6 kernel in the d-i manual
Hello, Holger Wansing, le Mon 04 Aug 2014 11:55:43 +0200, a écrit : Please note that I have added an entity for the default kernel series shipped with the respective release. Would it be worse to add such an entity? I'm actually surprised it wasn't there already.: Is 3.14 kernel for Jessie correct? Recent mails said it'd rather be 3.16 Index: en/appendix/files.xml === --- en/appendix/files.xml (Revision 69218) +++ en/appendix/files.xml (Arbeitskopie) @@ -202,7 +202,8 @@ para A standard installation for the amd64 architecture, including all standard -packages and using the default 2.6 kernel, takes up std-system-size;MB of disk space. +packages and using the default linuxkernelseries-ver; kernel, takes up to +std-system-size;MB of disk space. A minimal base installation, without the quoteStandard system/quote task selected, will take base-system-size;MB. Well, I'm not sure it's actually useful to mention the kernel version at all actually. Mentioning the precise version (3.16) seems really pointless at least. Index: en/install-methods/tftp/rarp.xml === --- en/install-methods/tftp/rarp.xml (Revision 69218) +++ en/install-methods/tftp/rarp.xml (Arbeitskopie) @@ -17,7 +17,7 @@ /parapara -On a RARP server system using a Linux 2.4 or 2.6 kernel, or Solaris/SunOS, +On a RARP server system using a Linux 2.4, 2.6 or 3.x kernel, or Solaris/SunOS, I would rather patch into Linux 2.4 and further. The functionality is not to go away any time soon, even in a 4.x etc. timeframe. === --- en/partitioning/tree.xml (Revision 69218) +++ en/partitioning/tree.xml (Arbeitskopie) @@ -49,7 +49,7 @@ entryMount point for mounting a file system temporarily/entry /rowrow entryfilenameproc/filename/entry - entryVirtual directory for system information (2.4 and 2.6 kernels)/entry + entryVirtual directory for system information (2.4, 2.6 and 3.x kernels)/entry I wouldn't even mention the version: I've seen /proc for as long as I can remember. @@ -61,7 +61,7 @@ entryEssential system binaries/entry /rowrow entryfilenamesys/filename/entry - entryVirtual directory for system information (2.6 kernels)/entry + entryVirtual directory for system information (2.6 and 3.x kernels)/entry I'd rather patch into Linux 2.6 and further, I don't think /sys is to go away. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140804101457.gv3...@type.youpi.perso.aquilenet.fr
Bug#756996: mentions of 2.6 kernel in the d-i manual
Holger Wansing, le Mon 04 Aug 2014 22:54:17 +0200, a écrit : Then there is no need to create that entity at all, right? Indeed. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140804210234.ga9...@type.youpi.perso.aquilenet.fr
Bug#755871: doesn't prompt for keyboard layout when installing over serial konsole
Daniel Baumann, le Thu 24 Jul 2014 08:30:25 +0200, a écrit : when installing serial console, kbd-chooser is run but doesn't prompt for a keyboard layout. eventhough when installing over serial, the remote machine has the keyboard that is used to enter things during installation, i'd still like to configure the target systems keyboard. I don't know when the discussion happened (if any), but from the source code it seems that it was made on purpose to avoid a seemingly useless question. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140724081654.gr4...@type.youpi.perso.aquilenet.fr
Re: Bug#754544: espeakup-udeb: uninstallable due to wrong version information for espeak-data-udeb
Samuel Thibault, le Sun 13 Jul 2014 00:55:14 +0200, a écrit : Cyril Brulebois, le Sun 13 Jul 2014 00:23:31 +0200, a écrit : and this is the expected version dependency at work. Just binNMU-ing espeakup will fix it. but anyway, someone needs to perform the binNMUs or request them; and I haven't seen anything on -wb-team@ yet. Sure, I just hadn't gotten the time to do it yet. This is now done. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713153116.GA23177@type
Re: Bug#754544: espeakup-udeb: uninstallable due to wrong version information for espeak-data-udeb
Hello, Cyril Brulebois, le Sat 12 Jul 2014 11:10:08 +0200, a écrit : Package: espeakup-udeb Version: 1.48.04+dfsg-1 this package can't be installed due to the version information for espeak-data-udeb: | $ dpkg --compare-versions 1.48.04+dfsg-1 '=' 1.48.04~; echo $? | 0 | $ dpkg --compare-versions 1.48.04+dfsg-1 '' 1.48.04A; echo $? | 1 Well, yes, as I mentioned on the d-boot list, +dfsg was just added, and this is the expected version dependency at work. Just binNMU-ing espeakup will fix it. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712220514.GP5689@type
Re: Bug#754544: espeakup-udeb: uninstallable due to wrong version information for espeak-data-udeb
Cyril Brulebois, le Sun 13 Jul 2014 00:23:31 +0200, a écrit : and this is the expected version dependency at work. Just binNMU-ing espeakup will fix it. but anyway, someone needs to perform the binNMUs or request them; and I haven't seen anything on -wb-team@ yet. Sure, I just hadn't gotten the time to do it yet. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712225514.GX5689@type
Re: libespeak / espeakup
Cyril Brulebois, le Mon 07 Jul 2014 02:44:03 +0200, a écrit : Samuel Thibault sthiba...@debian.org (2014-05-22): Some time ago, I realized that espeakup-udeb needs to be rebuilt on each new upstream libespeak upload, because libespeak needs an exact match between the library version and the data version, and espeakup is linked statically against libespeak. So whenever we get a new upstream version of the espeak-data-udeb package, we have to relink espeakup statically against the corresponding libespeak.a. You might prove me wrong but I don't think that's happening a lot? It's not that often, indeed. The concern is more to make sure that we detect it. Right now we have a cronned edos/dose job that looks for uninstallable udebs and let me know when situation changes (be it for better or for worse); so at least the detection side is implemented already, Not completely: for now espeakup-udeb has an unversioned dependency on espeak-data-udeb. But that will probably be far easier and maintain than several udebs, I'll have a look. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140711090402.GI4837@type
Re: libespeak / espeakup
Samuel Thibault, le Fri 11 Jul 2014 11:04:02 +0200, a écrit : Cyril Brulebois, le Mon 07 Jul 2014 02:44:03 +0200, a écrit : Right now we have a cronned edos/dose job that looks for uninstallable udebs and let me know when situation changes (be it for better or for worse); so at least the detection side is implemented already, Not completely: for now espeakup-udeb has an unversioned dependency on espeak-data-udeb. But that will probably be far easier and maintain than several udebs, I'll have a look. It does seem to work fine. I'll drop the libespeak-udeb package then. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140711095831.GL4837@type
Re: libespeak / espeakup
Samuel Thibault, le Fri 11 Jul 2014 11:58:31 +0200, a écrit : Samuel Thibault, le Fri 11 Jul 2014 11:04:02 +0200, a écrit : Cyril Brulebois, le Mon 07 Jul 2014 02:44:03 +0200, a écrit : Right now we have a cronned edos/dose job that looks for uninstallable udebs and let me know when situation changes (be it for better or for worse); so at least the detection side is implemented already, Not completely: for now espeakup-udeb has an unversioned dependency on espeak-data-udeb. But that will probably be far easier and maintain than several udebs, I'll have a look. It does seem to work fine. I'll drop the libespeak-udeb package then. We'll actually be able to check that the uninstallability test and binNMU of espeakup to fix it works fine, since I had added +dfsg suffix for the repackaging of the upstream espeak tarball. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140711102547.GN4837@type
Bug#749262: debian-installer: Please start generating hurd-i386 daily images
Cyril Brulebois, le Fri 30 May 2014 20:48:16 +0200, a écrit : Samuel Thibault sthiba...@debian.org (2014-05-30): Gabriele Giacone, le Sun 25 May 2014 19:24:24 +0200, a écrit : Please start generating them at http://d-i.debian.org/daily-images/hurd-i386/ in order to let debian-cd getting components under daily/cdrom. This is now set up. Committing changes to daily-build-setup.git would have been better. Oops, sorry, after doing all the needed work, I didn't remember that this was a git repository. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530220933.gq7...@type.youpi.perso.aquilenet.fr