Bug#485447: tasksel: Rename Northern Sami to North Sámi and add hunspell-se package
Quoting Christian Perrier ([EMAIL PROTECTED]): > The English name of the language *in the ISO-639 standard* is > "Northern Sami", see > http://www.loc.gov/standards/iso639-2/php/code_list.php > > In all tasks we have tried to use the officially standardized name of > the relevant language. I suggest we stick up with that choice. The change already happened in tasksel's git. I have to say that I'm not entirely happy of the very short discussion leading to it. I particularly object to the change that happened to the language name in the tasks descriptions, along with 248 other string changes. Even though I may sometimes appear as less directly involved in D-I and D-I related software l10n, I think I would have had the opportunity to discuss these changes before they are committed...and offered to translators. I don't really like playing rude games but I'm very much tempted to revert the change that turned the *English* name of "se" into "North Sami" in the tasks descriptions. signature.asc Description: Digital signature
Bug#485447: tasksel: Rename Northern Sami to North Sámi and add hunspell-se package
[Christian Perrier] > The English name of the language *in the ISO-639 standard* is > "Northern Sami", see > http://www.loc.gov/standards/iso639-2/php/code_list.php I am aware of thus, but suspect it is incorrect in that list and should be fixed in ISO-639-2 too. I've pointed the Divvun project members to this discussion, and hope for their feedback here. They are native speakers, and involved in the Divvun project which is a government funded project to provide langauge tools for the Sámi langauges. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485447: tasksel: Rename Northern Sami to North Sámi and add hunspell-se package
Hi,
Christian Perrier wrote:
The change already happened in tasksel's git. I have to say that I'm
not entirely happy of the very short discussion leading to it.
Sorry, I thought it was a trivial change. I'll revert it as soon as I
get home to my ssh key (or you can revert if you want).
I particularly object to the change that happened to the language name
in the tasks descriptions, along with 248 other string changes.
That was the splitting of {kde,gnome}-desktop, I believe, which Joey did.
Even though I may sometimes appear as less directly involved in D-I
and D-I related software l10n, I think I would have had the
opportunity to discuss these changes before they are committed...and
offered to translators.
Sure.
I don't really like playing rude games but I'm very much tempted to
revert the change that turned the *English* name of "se" into "North
Sami" in the tasks descriptions.
It's not rude; please revert the change if you feel it is incorrect. I'm
not an i18n expert. Note that there are two commits as I wanted git to
catch the renaming correctly.
--
Pelle
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485586: debian-installer: Default to graphical install
Package: debian-installer Severity: wishlist Hi, In my humble opinion, with the stability (and the beauty) of the graphical installer, the graphical menu (under i386 and amd64) should default to the graphical installer. Obviously, the change has to be done with care and only on arches where applicable, but would be a good step forward (with the classical text installer staying as fallback). Regards, Didier -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (50, 'experimental'), (50, 'unstable'), (50, 'testing'), (50, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-rc5-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404950: Installation Report [mips] [rc1] [Failure] SWARM (Broadcom BCM91250a)
* Karsten Merker <[EMAIL PROTECTED]> [2008-01-21 21:54]: > > Karsten, can you check if this problem is still there with current > > kernels? i.e. 2.6.23 or 2.6.24 > > I'll check it, but I probably won't be able to do so before > next week. Karsten, did you ever find time to check this? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484121: tasksel: let's sync on the GNOME task
Le lundi 09 juin 2008 à 18:59 +0200, Per Olofsson a écrit : > Eric Dorland wrote: > > As to whether to include Iceweasel over epiphany (or whatever) in the > > gnome task, that's probably the gnome team's call. However, Iceweasel > > is clearly the more popular one and 3.0 does have better integration > > with Gnome (at least look at feel wise). > > FWIW, Iceweasel 3.0 also incorporates some of Epiphany's features, namely > bookmark tagging and bookmark typeahead finding from the location bar. And still: * it does not follow the HIG (which is, after theming and icons, the most important thing when it comes to look and feel); * there is no network-manager integration; * there is no avahi integration; * there is no support for notifications; and I probably forget some. There are definitely some nice improvements in iceweasel 3.0 when it comes to GNOME integration (especially the proxy settings, the beginning of GTK+ icon theme support and native widgets), but it still looks like a second-class browser to me in this context. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#485586: debian-installer: Default to graphical install
On Tuesday 10 June 2008, Didier Raboud wrote: > In my humble opinion, with the stability (and the beauty) of the > graphical installer, the graphical menu (under i386 and amd64) should > default to the graphical installer. > > Obviously, the change has to be done with care and only on arches where > applicable, but would be a good step forward (with the classical text > installer staying as fallback). We are considering this but there are still a few blocking issues before we can do that: - issues with keyboard support in some languages - missing support to start a shell from other components, which especially affects the rescue mode for the graphical installer - some dialogs, especially in the partitioner, still look too messy because of missing column alignment The last two issues are actively being worked on and may be solved in time for Lenny. The first is much more problematic and will likely require (upstream) help. Another issue is that it requires much more memory, but that IMO is not a blocker. It does require careful documentation though. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485609: Problem with device renaming and grub after clean install
Package: installation-reports Boot method: netinst Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/ Date: 2008-06-08 Machine: i386 custom built Processor: intel pentium 4 2.4 ghz circa 2003 Memory: 1GB Partitions: df -Tl with the in memory mounts removed FilesystemType 1K-blocks Used Available Use% Mounted on /dev/hda4 ext319236340 10108000 8151188 56% / /dev/hdb1 ext276920416 59808876 13204132 82% /mnt/backups /dev/hda2 ext318263556 7231344 10104460 42% /mnt/Stable /dev/hda3 ext319228308 3024584 15226972 17% /mnt/Testing This is a system arrangement I have been using for about 8 years now. I setup swap, Stable, Testing, and Unstable on a single machine. As simple as this seems grub (specifically update-grub) doesn't play very nice with it. I am generating this report from the current unstable installation on hda4, which is as up to date as I can get it without ripping out things I need. Output of lspci -nn 00:00.0 Host bridge [0600]: Silicon Integrated Systems [SiS] 645xx [1039:0648] (rev 02) 00:01.0 PCI bridge [0604]: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) [1039:0001] 00:02.0 ISA bridge [0601]: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] [1039:0963] (rev 04) 00:02.1 SMBus [0c05]: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller [1039:0016] 00:02.3 FireWire (IEEE 1394) [0c00]: Silicon Integrated Systems [SiS] FireWire Controller [1039:7007] 00:02.5 IDE interface [0101]: Silicon Integrated Systems [SiS] 5513 [IDE] [1039:5513] 00:03.0 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 Controller [1039:7001] (rev 0f) 00:03.1 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 Controller [1039:7001] (rev 0f) 00:03.2 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 Controller [1039:7001] (rev 0f) 00:03.3 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 2.0 Controller [1039:7002] 00:09.0 Ethernet controller [0200]: 3Com Corporation 3c905C-TX/TX-M [Tornado] [10b7:9200] (rev 78) 00:0a.0 Multimedia audio controller [0401]: Ensoniq 5880 AudioPCI [1274:5880] (rev 04) 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon R300 NE [Radeon 9500 Pro] [1002:4e45] 01:00.1 Display controller [0380]: ATI Technologies Inc Radeon R300 [Radeon 9500 Pro] (Secondary) [1002:4e65] and lspci -vnn: 00:00.0 Host bridge [0600]: Silicon Integrated Systems [SiS] 645xx [1039:0648] (rev 02) Subsystem: ASUSTeK Computer Inc. Device [1043:8086] Flags: bus master, medium devsel, latency 32 Memory at d000 (32-bit, non-prefetchable) [size=128M] Capabilities: [c0] AGP version 3.0 Kernel driver in use: agpgart-sis Kernel modules: sis-agp 00:01.0 PCI bridge [0604]: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) [1039:0001] Flags: bus master, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: cf00-cfff Prefetchable memory behind bridge: e000-febf Kernel modules: shpchp 00:02.0 ISA bridge [0601]: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] [1039:0963] (rev 04) Flags: bus master, medium devsel, latency 0 00:02.1 SMBus [0c05]: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller [1039:0016] Flags: medium devsel I/O ports at e600 [size=32] Kernel driver in use: sis96x_smbus Kernel modules: i2c-sis96x 00:02.3 FireWire (IEEE 1394) [0c00]: Silicon Integrated Systems [SiS] FireWire Controller [1039:7007] (prog-if 10) Subsystem: ASUSTeK Computer Inc. Device [1043:809a] Flags: bus master, medium devsel, latency 64, IRQ 17 Memory at ce80 (32-bit, non-prefetchable) [size=4K] Expansion ROM at dffe [disabled] [size=128K] Capabilities: [64] Power Management version 2 Kernel driver in use: firewire_ohci Kernel modules: firewire-ohci 00:02.5 IDE interface [0101]: Silicon Integrated Systems [SiS] 5513 [IDE] [1039:5513] (prog-if 80 [Master]) Subsystem: ASUSTeK Computer Inc. Device [1043:8087] Flags: bus master, medium devsel, latency 128, IRQ 16 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at a400 [size=16] Kernel driver in use: SIS_IDE Kernel modules: sis5513, pata_sis 00:03.0 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 Controller [1039:7001] (rev 0f) (prog-if 10) Subsystem: ASUSTeK Computer Inc. Device [1043:8087] Flags:
Processed: Re: Bug#485609: Problem with device renaming and grub after clean install
Processing commands for [EMAIL PROTECTED]: > reassign 485609 linux-2.6 2.6.24-7 Bug#485609: Problem with device renaming and grub after clean install Bug reassigned from package `installation-reports' to `linux-2.6'. > retitle 485609 modules.pcimap lists both pata_sis and sis5513 for [1039:5513] Bug#485609: Problem with device renaming and grub after clean install Changed Bug title to `modules.pcimap lists both pata_sis and sis5513 for [1039:5513]' from `Problem with device renaming and grub after clean install'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485609: Problem with device renaming and grub after clean install
reassign 485609 linux-2.6 2.6.24-7 retitle 485609 modules.pcimap lists both pata_sis and sis5513 for [1039:5513] thanks On Tuesday 10 June 2008, [EMAIL PROTECTED] wrote: > It seems that the kernel is remapping /dev/hda using the scsi > emulation, which I did not enable and grub doesn't know about during > the installation. Oddly I have the same kernel installed for the > unstable partition and I do not run into the same problem. I took a > look at the kernel config on both and nothing stands out. Reason for this is that the Debian kernel provides two modules that support your IDE controller: $ grep 1039.*5513 /lib/modules/2.6.24-1-amd64/modules.pcimap pata_sis 0x1039 0x5513 0x 0x 0x 0x 0x0 sis5513 0x1039 0x5513 0x 0x 0x 0x 0x0 Which gets loaded is somewhat random and apparently the installer used the second (setting the system up to use /dev/hda), while after the reboot the first was used (changing the device name to /dev/sda). This is a known issue listed in the errata. Reassigning your report to the kernel team because AFAIK we should not be listing two modules for the same controller. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485447: tasksel: Rename Northern Sami to North Sámi and add hunspell-se package
Quoting Petter Reinholdtsen ([EMAIL PROTECTED]): > I've pointed the Divvun project members to this discussion, and hope > for their feedback here. They are native speakers, and involved in > the Divvun project which is a government funded project to provide > langauge tools for the Sámi langauges. The point is that ISO 639-2 does not standardize langguages names in the languages themselves, but languages names in English (and French, FWIW). And, I really think that things should go the Right Way, ie change nameswhen they are changed in the standard. Otherwise, I deeply fear request from here and there to change language names for this or that reason (sometimes political ones). signature.asc Description: Digital signature
Bug#485447: tasksel: Rename Northern Sami to North Sámi and add hunspell-se package
On 2008-06-10 Christian Perrier wrote: > The point is that ISO 639-2 does not standardize langguages names in > the languages themselves, but languages names in English (and French, > FWIW). Well, "North Sámi" is probably not the language's name in the language itself. According to Wikipedia it's "Davvisápmi". -- Pelle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485447: tasksel: Rename Northern Sami to North Sámi and add hunspell-se package
On Tuesday 10 June 2008, Per Olofsson wrote: > On 2008-06-10 Christian Perrier wrote: > > The point is that ISO 639-2 does not standardize langguages names in > > the languages themselves, but languages names in English (and French, > > FWIW). > > Well, "North Sámi" is probably not the language's name in the language > itself. According to Wikipedia it's "Davvisápmi". Note that having accents in English names causes its own problems. It's for example the reason the we currently do not list two (French?) islands in the D-I country list. signature.asc Description: This is a digitally signed message part.
Bug#485447: tasksel: Rename Northern Sami to North Sámi and add hunspell-se package
Quoting Per Olofsson ([EMAIL PROTECTED]): > Well, "North Sámi" is probably not the language's name in the language > itself. According to Wikipedia it's "Davvisápmi". Of course, but that just makes the request even more dabatable..:-) signature.asc Description: Digital signature
Bug#485617: os-prober: Does not detect K-DEMar - include distro info
Package: os-prober Version: 1.24 Severity: wishlist Can you add K-DEMar linux support. Detection is done by adding those lines: elif [ -e "$dir/etc/kdemar-release" ]; then short="K-DEMar" [ -e /usr/kdemar/config ] && . /usr/kdemar/config long="K-DEMar $kdemar_type `cat $dir/etc/kdemar-release` GNU/Linux" Tnx -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25.1 (SMP w/2 CPU cores; PREEMPT) Locale: [EMAIL PROTECTED]:ca_ES:ca:[EMAIL PROTECTED]:es_ES:es, LC_CTYPE=ca_ES.iso8859-15 (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MENU DEFAULT64 support for syslinux
On Tue, Jun 10, 2008 at 01:38:43AM -0700, Ryan Finnie wrote: > On Mon, Jun 9, 2008 at 1:08 PM, Frans Pop <[EMAIL PROTECTED]> wrote: > > * Installer images for i386 and amd64 have a new boot menu using > > syslinux's vesamenu. This allows for a more user-friendly selection > > of for example the regular or graphical installer. For the multi- > > architecture CD/DVD images this change means the 64-bits version of > > the installer needs to be selected manually from the menu. See the > > Installation Guide [2] for details on how to use the new menu. > > Beta 2 is looking nice, but not having multi-arch boot detection was a > bummer. So I took it upon myself to add the missing functionality to > menu.c32/vesamenu.c32. I'm posting the patch here first because I Am > Not A C Programmer(TM), and I really need more set of eyes on it. > Functionally it seems to be working well, as I converted my own > distro's[0] straight isolinux setup to a vesamenu system[1], and it's > been guessing correctly on everything I've thrown at it so far. Hi Ryan, Thanks for your help. I'm also interested in this feature (I updated the patch which was being currently used, 02-64bit-autodetection.dpatch, but it seems that it has no effect when using the menu). I have two comments: - Would you please open a bug report (see bugs.debian.org) against syslinux package for this? debian-devel is not the most indicate place. - Have you based your code on the currently existing check in 02-64bit-autodetection.dpatch? It is best to reuse known-working code for this. If you want a C-friendly version, you can use cpuid.c from the win32-loader package (it derives from GCC and has been widely tested). -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please unfreeze libdirectfb 1.0.1-9
Hi, Could you please unfreeze libdirectfb 1.0.1-9 ? It contains cross build support for emdebian, a patch accepted upstream (1) and unblock splashy 0.3.10 to enter Lenny. (1) when libdirectfb detects zero length reads, it attempts to reopen the console (possibly from a newly mounted root tree). cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unfreeze libdirectfb 1.0.1-9
On Tuesday 10 June 2008, Fathi BOUDRA wrote: > Could you please unfreeze libdirectfb 1.0.1-9 ? Already suggested yesterday: http://lists.debian.org/debian-release/2008/06/msg00179.html Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Post D-I release hints
On Mon, Jun 09, 2008 at 11:24:12PM +0200, Frans Pop wrote: > Now that Beta 2 has been released, the following packages can be hinted > for migration: > > * remove the block hint for apt (set on request from Otavio) Done. (Already yesterday.) > * hints for packages with udebs, probably routine/safe: > unblock brltty/3.10~r3724-1 > unblock cpuburn/1.4-33 > unblock devmapper/2:1.02.25-1 > unblock dhcp3/3.1.1-1 > unblock kbd/1.14.1-3 > unblock ttf-cjk-compact/1.13 > unblock ttf-dejavu/2.25-1 In place. > * the following should probably be checked by RT too before hinting: > unblock openssh/1:4.7p1-12 > unblock openssl/0.9.8g-10.1 > unblock directfb/1.0.1-9 > unblock gtk2-engines/1:2.14.2-1 All confirmed and unblocked. > * the following are not ready: > - gnupg (37 days old, missing hppa) > - multipath (23 days old, missing alpha+hppa) Don't see the source package for multipath, gnupg needs aging again. Kind regards, Philipp Kern -- .''`. Philipp Kern Debian Developer : :' : http://philkern.de Debian Release Assistant `. `' xmpp:[EMAIL PROTECTED] `-finger pkern/[EMAIL PROTECTED] signature.asc Description: Digital signature
Re: UUID support in GRUB
On Mon, Jun 02, 2008 at 11:00:30AM -0300, Otavio Salvador wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Robert Millan <[EMAIL PROTECTED]> writes: > > > I'd like to receive some feedback on: > > > > - Whether it would be preferable to wait untill beta2 is out to allow this > > change to migrate to testing. > > Please wait us to finish beta2. Ok, it's in 0.97-40. Some notes: 1- It is disabled for installs that have root filesystem in LVM or RAID, because of bug #484297. 2- It does only affect menu.lst generation, NOT menu.lst update. So unless the admin explicitly takes action, it will only be enabled in new installs. 3- Admin can disable it simply by setting the "kopt" variable to its traditional device-name value (and - related to #2 - subsequent update-grub runs will make it persist, as usual). Please test this actively if you can (on an existing install, simply by removing menu.lst and regenerating it). -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435769: debian-installer: no checking for sufficient disk space
Le vendredi 3 août 2007 07:55:47 Christian Perrier, vous avez écrit : > Quoting Frédéric Brière ([EMAIL PROTECTED]): > > Package: debian-installer > > Severity: normal > > > > d-i does not appear to make sure that the partitioning scheme it has > > been given allows for sufficient space. This was made painfully obvious > > Hmm, that would require knowing what exactly the user wants to > install.. > > Indeed, at least checking that the base system will fit before running > base-installer would be something to do. However, there is currently > no way to really know what the size of a Debian base system is because > it depends on what packages are part of it. > > We could however have some hardcoded value somewhere for /, /usr and > /var and have partman choke if one of these is below this value. But, > even this is not that trivial to implement. > > This, that bug could be reassigned to some partman-* package. > > > For something that warns users that the partitioning scheme does not > fit the choice of packages, see #282155 which no-one has been able to > implement (here again, the size of an installed system depend on the > user's choices). Hi, I'm reacting on this bug because I thought that the latest installer had many other issues because of this bug: I tried to install Lenny Beta2 amd64 KDE within KVM, providing an disk image of 2G. The installer failed to complete the install of the packages because of lacking space (but did not mention anything to me). I see two problems here: * Not checking that enough disk space is available * Not mentioning the user that he lacks space. The second can rather easily be correcting by mentioning the fact after the error triggers (just check df). With that in hands, the user can know that the partitioning scheme he has chosen (or the virtual image he provided) is not good. For the moment, the message is just "there is an error", which is not sufficient to me. Regards, Didier -- Didier Raboud, proud Debian user. CH-1802 Corseaux [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
Re: unblock request: ttf-cjk-compact 1.13
Frans Pop wrote: > On Sunday 25 May 2008, Kenshi Muto wrote: >> Please unblock ttf-cjk-compact/1.13. >> This source provides only ttf-cjk-compact-udeb package. >> This version fixes FTBFS and syncs glyphs with current installer >> messages. I believe there aren't any regressions. > > This will have to wait until after the release of D-I Beta2. unblocked Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unfreeze openssh 1:4.7p1-12
Colin Watson wrote: > On Sun, Jun 08, 2008 at 09:00:22PM +0200, Frans Pop wrote: >> On Sunday 08 June 2008, Colin Watson wrote: >>> Could you please unfreeze this? The updates are mostly a long series of >>> fairly minor adjustments following the recent OpenSSL security update >>> mitigation work. >>> >>> CCing debian-boot since this contains udebs so requires a d-i RM ack. >> CD images for beta2 have been built so if final tests show no problems the >> release will probably be tomorrow. We will send a list with suggested >> hints to d-release after the release is final and include openssh. > > Thanks, that sounds like it should be fine. unblocked Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Post D-I release hints
On Tue, Jun 10, 2008 at 04:40:55PM +0200, Philipp Kern wrote: > > * the following are not ready: > > - gnupg (37 days old, missing hppa) > > - multipath (23 days old, missing alpha+hppa) > Don't see the source package for multipath, gnupg needs aging again. multipath-tools. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unfreeze libdirectfb 1.0.1-9
Frans Pop wrote: > On Tuesday 10 June 2008, Fathi BOUDRA wrote: >> Could you please unfreeze libdirectfb 1.0.1-9 ? > > Already suggested yesterday: > http://lists.debian.org/debian-release/2008/06/msg00179.html unblocked Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Post D-I release hints
On Tuesday 10 June 2008, Philipp Kern wrote: > > - multipath (23 days old, missing alpha+hppa) > > Don't see the source package for multipath, gnupg needs aging again. Sorry, that should have been multipath-tools, but never mind. Thanks for the rest. signature.asc Description: This is a digitally signed message part.
Re: MENU DEFAULT64 support for syslinux
On Tue, Jun 10, 2008 at 7:04 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 01:38:43AM -0700, Ryan Finnie wrote: >> On Mon, Jun 9, 2008 at 1:08 PM, Frans Pop <[EMAIL PROTECTED]> wrote: >> > * Installer images for i386 and amd64 have a new boot menu using >> > syslinux's vesamenu. This allows for a more user-friendly selection >> > of for example the regular or graphical installer. For the multi- >> > architecture CD/DVD images this change means the 64-bits version of >> > the installer needs to be selected manually from the menu. See the >> > Installation Guide [2] for details on how to use the new menu. >> >> Beta 2 is looking nice, but not having multi-arch boot detection was a >> bummer. So I took it upon myself to add the missing functionality to >> menu.c32/vesamenu.c32. I'm posting the patch here first because I Am >> Not A C Programmer(TM), and I really need more set of eyes on it. >> Functionally it seems to be working well, as I converted my own >> distro's[0] straight isolinux setup to a vesamenu system[1], and it's >> been guessing correctly on everything I've thrown at it so far. > > Hi Ryan, > > Thanks for your help. I'm also interested in this feature (I updated the > patch which was being currently used, 02-64bit-autodetection.dpatch, but it > seems that it has no effect when using the menu). I have two comments: > > - Would you please open a bug report (see bugs.debian.org) against syslinux >package for this? debian-devel is not the most indicate place. My mistake. I could have sworn the original d-d-a announcement had a Reply-To: debian-cd, not debian-devel. I will also file a bug soon. > - Have you based your code on the currently existing check in >02-64bit-autodetection.dpatch? It is best to reuse known-working code >for this. If you want a C-friendly version, you can use cpuid.c from >the win32-loader package (it derives from GCC and has been widely >tested). Thanks. My version was pretty close to win32-loader's cpuid.c, but that one had a few extra precautions, so I'll grab from there. A new version is attached (also at http://www.finnie.org/software/debian/devel/syslinux-menu-default64.patch). And to avoid a bit of confusion, the functionality isn't /exactly/ the same as the old autodetection patch. The original 02-64bit-autodetection.dpatch logic was "if the user presses Enter, boot this section if it's 64-bit, otherwise boot this section". The logic for the new menu patch is "if it's 64-bit, highlight this menu entry for the user, otherwise highlight this menu entry", which is more in line with the concept of the menu (and easier to implement). RF syslinux-menu-default64.patch Description: Binary data
Bug#485655: debian-installer: The KDE images should use sudo too and configure KDE accordingly.
Package: debian-installer Version: LennyBeta2 Severity: wishlist Hi, I think that the KDE CD images should install and configure sudo as the Gnome images do. Additionnally, it should configure KDE to use it correctly. Regards, Didier -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (50, 'experimental'), (50, 'unstable'), (50, 'testing'), (50, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-rc5-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485656: menu.c32/vesamenu.c32: Add MENU DEFAULT64 support
Package: syslinux
Version: 2:3.63+dfsg-1
Severity: wishlist
Tags: patch
Current Debian syslinux packages have the patch to add DEFAULT64 support
to the core syslinux/isolinux/etc bootloader. However, debian-installer
recently switched[0] to the vesamenu.c32 system, which is a chained
bootloader on top of syslinux, and cannot take advantage of DEFAULT64.
Attached is a patch that adds "MENU DEFAULT64" support to the
menu.c32/vesamenu.c32 chain loader. The classic behavior is of this
loader is to highlight a menu entry that contains the "MENU DEFAULT"
keyword. This patch extends that functionality to highlight a menu
entry that has the "MENU DEFAULT64" keyword if the CPU is x86_64 (but
will still fall back to the "MENU DEFAULT" entry if the CPU is not
x86_64).
An example screenshot of a menu taking advantage of this is here[1].
"Boot Finnix (AMD64)" was highlighted because it was booted on a Core 2
Duo, but on a 32-bit CPU, "Boot Finnix (x86)" would be highlighted by
default.
[0] http://lists.debian.org/debian-devel-announce/2008/06/msg2.html
[1] http://www.finnix.org/Image:Finnix_dev_boot_menu.png
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
diff -ruN syslinux-3.63+dfsg-orig/com32/menu/menu.h syslinux-3.63+dfsg/com32/menu/menu.h
--- syslinux-3.63+dfsg-orig/com32/menu/menu.h 2008-04-10 10:30:35.0 -0700
+++ syslinux-3.63+dfsg/com32/menu/menu.h 2008-06-10 09:42:31.749682563 -0700
@@ -163,6 +163,8 @@
struct color_table *color_table;
struct fkey_help fkeyhelp[12];
+
+ int has_default64;
};
extern struct menu *root_menu, *start_menu, *hide_menu, *menu_list;
diff -ruN syslinux-3.63+dfsg-orig/com32/menu/readconfig.c syslinux-3.63+dfsg/com32/menu/readconfig.c
--- syslinux-3.63+dfsg-orig/com32/menu/readconfig.c 2008-04-10 10:30:35.0 -0700
+++ syslinux-3.63+dfsg/com32/menu/readconfig.c 2008-06-10 09:48:06.133719250 -0700
@@ -67,6 +67,56 @@
};
/*
+ * Test for long mode using cpuid instruction
+ * Based on plugins/cpuid/cpuid.c from win32-loader
+ * Copyright (C) 2007 Robert Millan <[EMAIL PROTECTED]>
+ * Based on gcc/gcc/config/i386/driver-i386.c
+ * Copyright (C) 2006, 2007 Free Software Foundation, Inc.
+ */
+
+#define cpuid(num,a,b,c,d) \
+ asm volatile ("xchgl %%ebx, %1; cpuid; xchgl %%ebx, %1" \
+ : "=a" (a), "=r" (b), "=c" (c), "=d" (d) \
+ : "0" (num))
+
+#define bit_LM (1 << 29)
+
+int
+check_64bit ()
+{
+ unsigned int eax, ebx, ecx, edx;
+ unsigned int max_level;
+ unsigned int ext_level;
+ unsigned char has_longmode = 0;
+
+ /* See if we can use cpuid. */
+ asm volatile ("pushfl; pushfl; popl %0; movl %0,%1; xorl %2,%0;"
+ "pushl %0; popfl; pushfl; popl %0; popfl"
+ : "=&r" (eax), "=&r" (ebx)
+ : "i" (0x0020));
+ if (((eax ^ ebx) & 0x0020) == 0)
+goto done;
+
+ /* Check the highest input value for eax. */
+ cpuid (0, eax, ebx, ecx, edx);
+ /* We only look at the first four characters. */
+ max_level = eax;
+ if (max_level == 0)
+goto done;
+
+ cpuid (0x8000, eax, ebx, ecx, edx);
+ ext_level = eax;
+ if (ext_level < 0x8000)
+goto done;
+
+ cpuid (0x8001, eax, ebx, ecx, edx);
+ has_longmode = !!(edx & bit_LM);
+
+done:
+ return has_longmode;
+}
+
+/*
* Search the list of all menus for a specific label
*/
static struct menu *
@@ -206,6 +256,7 @@
unsigned int ipappend;
unsigned int menuhide;
unsigned int menudefault;
+ unsigned int menudefault64;
unsigned int menuseparator;
unsigned int menudisabled;
unsigned int menuindent;
@@ -273,6 +324,8 @@
struct menu_entry *me;
const struct syslinux_ipappend_strings *ipappend;
+ int is_64bit = check_64bit();
+
if (!ld->label)
return; /* Nothing defined */
@@ -361,8 +414,26 @@
break;
}
-if ( ld->menudefault && me->action == MA_CMD )
+/* If this ld has DEFAULT on it, it's a candidate for the default entry.
+ * But if a 64-bit default has already been set, we know that A) the CPU
+ * is 64-bit, and B) a DEFAULT64 has already occurred, so we don't even
+ * want to attempt 32-bit defaults anymore. If it's a 64-bit CPU,
+ * regular DEFAULTs can of course be considered for the default,
+ * but any past or future DEFAULT64 (with a corresponding 64-bit CPU)
+ * will eventually win.
+ */
+if ( ld->menudefault && me->action == MA_CMD && !m->has_default64 )
+ m->defentry = m->nentries-1;
+
+/* If the CPU is 64-bit and DEFAULT64 is set for this ld, set it as
+ * default. However, if DEFAULT64 is set and the CPU is NOT 64-bit,
+ * don't even consider it for a default.
+ */
+if ( ld->menudefault64 && me->action == MA_CMD && is_64bit ) {
m->defentry = m->nentries-1;
+ m->has_default64 = 1;
+}
+
}
clear_label_data(ld);
@@ -620,6
Re: Extending flash-kernel to support KuroBox Pro
* Per Andersson <[EMAIL PROTECTED]> [2008-06-09 08:50]: > + # KuroBox Pro > + "MV-88fxx81") This is what the default kernel in the Kurobox Pro uses, but the mainline kernel from kernel.org (and hence the Debian kernel) will use something different. The script has to work with the Debian kernel, not with the original kernel (which we will replace). The string is: Buffalo/Revogear Kurobox Pro > + check_subarch "orion5x" > + check_mtd > + kmtd=$(mtdblock uImage) > + if [ -z "$kmtd" ]; then > + error "Cannot find mtd partition 'uImage'" > + fi > + kmtdsize=$(mtdsize "uImage") > + check_size "uImage" $(($kfilesize + 8 + 64)) $kmtdsize > + printf "Generating kernel u-boot image... " >&2 > + tmp=$(tempfile) > + devio > $tmp 'wl 0xe3a01c05,4' 'wl 0xe38110e5,4' ok, that's the right machine id. > + cat $kfile >> $tmp > + mkimage -A arm -O linux -T kernel -C none -a 0x8000 \ > + -e 0x8000 -n "$desc" -d $tmp $tmp.uboot >&2 > 1>/dev/null You have to check what address the Kurobox actually uses. When you connect the serial console and load the default kernel, you'll see the values. > + echo "done." >&2 > + printf "Flashing kernel... " >&2 > + cat $tmp.uboot > $kmtd || error "failed." > + echo "done." >&2 > + rm -f $tmp.uboot $tmp > + ;; So you flash the kernel but not the ramdisk. You'll also have to figure out how the ramdisk should be written to flash (in particular, in which format). See the previous mail I sent you about this. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484121: tasksel: let's sync on the GNOME task
Eric Dorland wrote: > So the user agent thing is fairly well documented at > http://bugs.debian.org/399633, but basically it's our stand against > user-agent insanity. We could of course make it say Firefox easily, > but this certainly seems a bit defeatist. s/defeatist/defeated/ I realized this battle was over when discussion on debian-user revieled that google maps behaved differently in firefox than iceweasel, because it used a firefox-UA specific test to enable a feature (closing the sidebar to make the map take up the full screen). If the top website out there gets it "wrong", the battle is effectively over; "right" or "wrong" no longer really matters (victors write history etc). > I think we should almost > certainly document the workaround better in the README.Debian. Of > course I highly respect Joey's opinion so I'm open to more > convincing. I'm afraid that documenting it in README.Debian won't help desktop users who just find that this strange "iceweasel" browser we install by default doesn't work on sites that firefox works on. -- see shy jo signature.asc Description: Digital signature
Bug#485617: os-prober: Does not detect K-DEMar - include distro info
Adonay Sanz wrote: > [ -e /usr/kdemar/config ] && . /usr/kdemar/config os-prober does not run code from os's its probing, which this line attempts to do. If you'd like to provide a way to grep out the kdemar_type setting from this file that does not involve executing arbitrary code, I'll add that; for now I've done this: long=$(printf "K-DEMar GNU/Linux (%s)\n" "$(cat $dir/etc/kdemar-release)") -- see shy jo signature.asc Description: Digital signature
Re: Tibetan Machine Uni font sources for the new version (v1.901)
On Mon, Jun 09, 2008 at 02:40:09PM +0200, Frans Pop wrote: > On Monday 09 June 2008, Tom Söderlund wrote: > > On Mon, 2008-06-09 at 11:06 +0200, Frans Pop wrote: > > > > On Fri, 6 Jun 2008, Tom Söderlund wrote: > > > > > [0] http://gamma.nic.fi/~t_om/debian/ttf-tmuni/ > > > > > > if there are any major changes in the font that could affect the > > > udeb or cause a significant change in its size, it would be nice to > > > hear about those. > > > > The font file which is the sole content of the udeb package has grown a > > bit over threefold from 1355768 bytes to 4511176 bytes. > > Hmmm. That's not nice for the memory usage of the graphical installer. > It would be good to look into that before the new version is uploaded. > > Davide Viti is our current "fonts manager". Added him in CC in the hope > that he has time to contact you about this and see if that increase can > be reduced. I've created PDF charts [1] for old and new version just to have a quick way for comparing the two: new version does contain more glyphs indeed. The obvious suggestion would be to introduce a mechanism fo stripping unneeded glyps out of the udeb as we already do for ttf-dejavu [2] and ttf-freefont [3] packages. 3 megabytes difference is quite alot, and I'd like to dig a bit more to understand if there's anything else which causes this increase: will probablyhave the chance to work on this tomorrow evening. BTW, I noticed the ttf file has been renamed from TibetanMachineUniAlpha.ttf to TibMachUni-1.901b.ttf ; any particular reason for such change? regards, Davide [1] http://alioth.debian.org/~zinosat-guest/ttf-tmuni/ [2] svn://svn.debian.org/svn/pkg-fonts/packages/ttf-dejavu [3] svn://svn.debian.org/svn/pkg-fonts/packages/ttf-freefont signature.asc Description: Digital signature
Re: [SCM] tasksel repository branch, master, updated. 2591b858d17530309c3bc795130349170e7d5dda
Joey Hess wrote: > Per Olofsson wrote: >> myspell dictionaries can also be used at the console. The hunspell program >> can >> work with either myspell or hunspell dictionaries. Hunspell is merely an >> extension of myspell AIUI. Only a few languages have "hunspell" dictionaries. >> Indeed, they are all placed in /usr/share/myspell/dicts/. > > IIRC all the tasks I moved myspell-* from didn't have hunspell in them > though. > Except hungarian, which I've moved back now. -- Pelle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 485447
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.29 > tags 485447 - pending Bug#485447: tasksel: Rename Northern Sami to North Sámi and add hunspell-se package Tags were: pending Tags removed: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tibetan Machine Uni font sources for the new version (v1.901)
On Tuesday 10 June 2008, Davide Viti wrote: > BTW, I noticed the ttf file has been renamed from > TibetanMachineUniAlpha.ttf to TibMachUni-1.901b.ttf ; any particular > reason for such change? Although I'm the "To" addressee, I'm obviously not the correct person to answer the questions :-) One comment: the name change means that the font selection script in rootskel-gtk will need to be adjusted as well! Maybe we should implement a more generic mechanism where font udebs include a file in a certain location in which they "declare" which languages (by language code) they cover and which font size change is desired. Only for languages where a font switch is needed of course. Advantage would be that a font rename or other changes only has consequences in a single package: the relevant udeb. Davide: would you be willing to work something out for that? For transition we could probably first test if there is such a file and if not, fall back to current hard-coded values. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Beta2 released (was: Beta2 ready for testing)
On Wednesday 28 May 2008, Frans Pop wrote: > Weekly built CD images based on D-I beta2 are now available. I've also > asked Steve to switch the daily CD images over to lenny_d-i. I've just requested the daily CD images to be switched back to sid_d-i. There will also be a new weekly build probably sometime tomorrow, but I've disabled the links to weekly images on the project page for now to give Beta2 more exposure. Note that I did not create the extended "human readable changelog" that was created for Beta1. If someone else wants to work on that, please do. Note that I do have a (somewhat rough) script that can show changes in D-I components based on release dates, which could make that task somewhat easier. It's available on request. Cheers, FJP P.S. Just in casethat was not clear: the fact that I did the final bits of the release was on request from Otavio because he was unavailable to do it himself. signature.asc Description: This is a digitally signed message part.
Re: nslu2: status of beta2
On Monday 09 June 2008, Martin Michlmayr wrote: > The bad news is that the official d-i beta2 won't start on the NSLU2 > because the kernel fails to load the ramdisk. This is a combination > of a new APEX moving to testing recently and the d-i image not dealing > with that change. > The good news is that a) nobody uses the official images because they > don't contain the proprietary microcode needed for networking and b) > the problem is only with the way the d-i image is put together, not > with the installer itself. Don't you think that this should be added to the errata anyway? With link to your webpage. signature.asc Description: This is a digitally signed message part.
ttf-cjk-compact 1.13 MIGRATED to testing
FYI: The status of the ttf-cjk-compact source package in Debian's testing distribution has changed. Previous version: 1.12 Current version: 1.13 -- This email is automatically generated; [EMAIL PROTECTED] is responsible. See http://people.debian.org/~henning/trille/ for more information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485694: Submitting Installation Reports
Package: installation-reports Boot method:CD Image version: debian-LennyBeta2-i386-CD-1.iso Date: 2008/06/11 Machine: Assembled Processor: AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ Memory:DDR2 2G Partitions: Sorry not available, because the installation was failed, but I followed the basic partition steps given by Debian installer. HDD: Maxtor DiamondMax Plus9 80G ATA/133 Output of lspci -nn and lspci -vnn: >From Ubuntu 00:00.0 RAM memory [0500]: nVidia Corporation Unknown device [10de:0547] (rev a2) 00:01.0 ISA bridge [0601]: nVidia Corporation Unknown device [10de:0548] (rev a2) 00:01.1 SMBus [0c05]: nVidia Corporation Unknown device [10de:0542] (rev a2) 00:01.2 RAM memory [0500]: nVidia Corporation Unknown device [10de:0541] (rev a2) 00:02.0 USB Controller [0c03]: nVidia Corporation Unknown device [10de:055e] (rev a2) 00:02.1 USB Controller [0c03]: nVidia Corporation Unknown device [10de:055f] (rev a2) 00:04.0 USB Controller [0c03]: nVidia Corporation Unknown device [10de:055e] (rev a2) 00:04.1 USB Controller [0c03]: nVidia Corporation Unknown device [10de:055f] (rev a2) 00:06.0 IDE interface [0101]: nVidia Corporation Unknown device [10de:0560] (rev a1) 00:07.0 Audio device [0403]: nVidia Corporation MCP67 High Definition Audio [10de:055c] (rev a1) 00:08.0 PCI bridge [0604]: nVidia Corporation Unknown device [10de:0561] (rev a2) 00:09.0 IDE interface [0101]: nVidia Corporation Unknown device [10de:0550] (rev a2) 00:0a.0 Ethernet controller [0200]: nVidia Corporation Unknown device [10de:054c] (rev a2) 00:12.0 VGA compatible controller [0300]: nVidia Corporation Unknown device [10de:053e] (rev a2) 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:0e.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [E] Install boot loader:[O] Overall install:[E] Comments/Problems: Install tasks does not work properly. The task could start, but there was nothing installed (not even one package). The task just said "Failed". Then I tried to start the task manually again, but failed again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: r53660 - in trunk/installer: build/boot/x86 debian
On Wednesday 11 June 2008, Joey Hess wrote: > Author: joeyh > Date: Tue Jun 10 23:50:53 2008 > New Revision: 53660 > > Log: > Use menu default64 support added to syslinux 2:3.63+dfsg-2 to > automatically select the amd64 installation option on multiarch images. Could this cause problems while d-cd does not yet use the new syslinux? signature.asc Description: This is a digitally signed message part.
Re: r53660 - in trunk/installer: build/boot/x86 debian
On Wednesday 11 June 2008, Frans Pop wrote: > On Wednesday 11 June 2008, Joey Hess wrote: > > Use menu default64 support added to syslinux 2:3.63+dfsg-2 to > > automatically select the amd64 installation option on multiarch > > images. > > Could this cause problems while d-cd does not yet use the new syslinux? NM, I just see that you updated that as well. Cool. signature.asc Description: This is a digitally signed message part.
Bug#485508: SV: Bug#485508: Bug report
Perhaps I should have called it 'Application for best Subject Line', since a subject stating what the message is about was obviously not enough. I wish that I, as a debian newbie, could say 'thanks for your fast reply', however I am overwhelmed by the warmth that only a truly helpful and cheerful Linux Guru as yourself can provide. Additionally, I will of course consider to offer my help in the future to report bugs that I happend to run into. Futhermore, I will of course tell all my friends to do the same, because of the joy of writing replies such as this. Please do continue your contribution to world growth by replying to this message with comments regarding relevant issues such as my english grammar. With kind regards, Patrick -Ursprungligt meddelande- Från: Jim [mailto:[EMAIL PROTECTED] Skickat: den 10 juni 2008 06:00 Till: Patrick Fabrizius; [EMAIL PROTECTED] Ämne: Re: Bug#485508: Bug report On Mon, Jun 9, 2008 at 3:22 PM, Patrick Fabrizius <[EMAIL PROTECTED]> wrote: > Subject: Bug#485508: Bug report For that specific, informative title, that told us this bug report is a bug report, tell him what he won! Well Jim, he's won something of questionable substance... a bladeless knife without a handle! You won't want for a place to put it... it can fit in any space because it takes up no space! (unlike this message...I'm realizing you must have gotten a lot of this... so, let this be just one more request to put greater than zero information in the subject line... thanks! Hi! Buy!) No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.2.0/1493 - Release Date: 2008-06-09 17:25 No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.2.0/1493 - Release Date: 2008-06-09 17:25 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
