Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

On 26 August 2016 at 13:34, Raphael Hertzog wrote: > On Fri, 26 Aug 2016, adrian15 wrote: >> > Well, it sucks compared to the default visual appearance of >> > isolinux/syslinux in live-build. >> I know, but the purpose of my patch is to add UEFI support. Not to improve >>

Bug#573173: support multiple kernel versions with same flavour

Package: live-build Followup-For: Bug #573173 Hello, sending fixed/updated version of the patch. This works for me quite well with live-build in Debian and Syslinux. Grub is unsupported. Build menu for multiple kernels of the same flavour. - does not crash if multiple kernels of same flavour

Bug#573173: support multiple kernel versions with same flavour

Package: live-build Version: 1:20151215 Followup-For: Bug #573173 Hello, sending patch against version of live-build currently in debian: 20151215 The patch was rejected in the past mainly due to pending rewrite of live-build in python which is no longer planned AFAIK. This patch makes the

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Hello, On 31 July 2016 at 09:35, adrian15 wrote: > This new update tries to implement actual support for multiple bootloaders. > It only enforces grub-legacy not to be an extra bootloader because it's > current implementation in binary-iso is not compatible (without

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

On 21 March 2016 at 23:06, adrian15 <adrian15...@gmail.com> wrote: > El 21/03/16 a las 22:19, Michal Suchanek escribió: > >> The bootloader support in live-build is limited. With your patches it >> becomes wrong. eg. compatibility of bootloader with selected >> fil

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Hello, On 21 March 2016 at 21:09, adrian15 wrote: > > The branch which include specifically the commits I attach here as patches > is: > > https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5 > > . > > About the variable names issue: I

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

On 26 January 2016 at 23:20, adrian15 <adrian15...@gmail.com> wrote: > El 26/01/16 a las 10:18, Michal Suchanek escribió: >> >>> >>> My use case is the following one. The final user requests: >>> >>> --bootloaders=grub-efi,syslinux >>>

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

On 25 January 2016 at 21:33, adrian15 <adrian15...@gmail.com> wrote: > > > El 25/01/16 a las 16:12, Michal Suchanek escribió: >> >> On 25 January 2016 at 03:05, adrian15 <adrian15...@gmail.com> wrote: >>> >>> El 24/01/16 a las 16:51, Michal Suchan

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

On 25 January 2016 at 03:05, adrian15 <adrian15...@gmail.com> wrote: > El 24/01/16 a las 16:51, Michal Suchanek escribió: > What you are describing here is what it's actually implemented in my patch > (Well, actually the first patch version because the current one enforces >

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

On 24 January 2016 at 00:41, adrian15 wrote: > El 23/01/16 a las 09:21, Thomas Schmitt escribió: >> >> There is a fourth dimension to be expressed: Bootloader. >> Then there is the dimension of ISO filesystem objects. >> A user wish would contain at least >>ISO-Object,

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

On 18 January 2016 at 10:43, adrian15 <adrian15...@gmail.com> wrote: > El 18/01/16 a las 07:31, Michal Suchanek escribió: >> >> Hello, >> >> thanks for working on this. >> > >> As to the primary and secondary bootloader - how is the efi bootload

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Hello, thanks for working on this. On 18 January 2016 at 05:24, adrian15 wrote: > In my last message I forgot to CC many people who are involved in this bug > so I'm going to refer to my former message, CC some people and finally point > you to my repo/branches where you

Bug#770369: Eterm: does not run shell

Package: Eterm Version: 0.9.6-1 Severity: normal Hello, I did # apt-get install eterm $ Eterm A window opens with cursor but no shell starts. I can type in the window and characters appear as typed. There is no other response. Presumably if some poor user installed Eterm and their

Bug#769704: /etc/fb.modes: fb.modes lacks standard hd modes

Package: fbset Version: 2.1-28 Severity: normal File: /etc/fb.modes Hello, I upgraded my system, X crashed, and when it came up it came up with fbdev driver rather than Radeon. The resolution is less than optimal: $ fbset mode 1024x768 geometry 1024 768 1024 768 32 timings 0 0 0 0 0

Bug#595518: jack-tools: refuses to install with jackd2

Package: jack-tools Version: 0.0.2-7+b1 Severity: normal jack-tools can use libjack-jackd2-0 but depend uncnditionally on jackd. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (300, 'unstable'), (295, 'experimental'),

Bug#586332: skribe: broken dependencies

Package: skribe Version: 1.2g-2 Severity: normal skribe: error while loading shared libraries: libbigloo_s-2.8c.so: cannot open shared object file: No such file or directory -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (900, 'stable'), (700, 'testing'), (500,

Bug#494933: charmap.app: the range switching is terribly slow

Package: charmap.app Version: 0.2-9+b1 Severity: important When switching to a rarer range (like Cherokee) the applicatin locks up for noticable time (in the range of minutes) eating 100% cpu. Note that I did not specifically install any Cherokee fonts, and have some 100+ font faces installed.

Bug#494933: charmap.app: the range switching is terribly slow

On 13/08/2008, Yavor Doganov [EMAIL PROTECTED] wrote: В 09:50 +0200 на 13.08.2008 (ср), Michal Suchanek написа: When switching to a rarer range (like Cherokee) the applicatin locks up for noticable time (in the range of minutes) eating 100% cpu. Thanks for the report. I suspect