Re: Debian live stable images with just console and software speech using espeakup

[Lorenzo "Palinuro" Faletra]

hi, the debian netinstall images include obly the debian installer (which is an 
autonomous OS), and the debian installer can give you access to a minimal 
console with many useful utilities. give it a try and let us know if it is what 
you need


On December 23, 2017 9:10:22 PM GMT+01:00, Nick Gawronski 
 wrote:
>Hi, I was looking for a Debian live disc that is just for console use
>for
>doing things like copying off files and installing a basic console
>Debian
>system using software speech.  I searched the Debian live project but
>could not find just console images they all had a desktop on them which
>I
>don't need.  Could this be looked into for times where a minimal live
>disc
>is needed?  Nick Gawronski

-- 
Lorenzo "Palinuro" Faletra

Parrot Security

GPG FINGERPRINT: B350 5059 3C2F 7656 40E6 DDDB 97CA A129 F4C6 B9A4

GPG Info: http://pgp.mit.edu/pks/lookup?op=vindex=0x97CAA129F4C6B9A4
GPG Key: http://pgp.mit.edu/pks/lookup?op=get=0x97CAA129F4C6B9A4

Debian live stable images with just console and software speech using espeakup

[Nick Gawronski]

Hi, I was looking for a Debian live disc that is just for console use for
doing things like copying off files and installing a basic console Debian
system using software speech.  I searched the Debian live project but
could not find just console images they all had a desktop on them which I
don't need.  Could this be looked into for times where a minimal live disc
is needed?  Nick Gawronski

Bug#884585: live-build: Grub autodetect option no longer works with 686 kernel

[adrian15]

El 21/12/17 a las 14:32, Raphael Hertzog escribió:
> On Sun, 17 Dec 2017, adrian15 wrote:
>>* What led up to the situation?
> 
> The reportbug templates are not always very appropriate when you
> just want to submit a patch... just go straight to the explanation
> of the patch and why it should be merged.
> 
>> I attach a patch (that can be applied on current git head) that fixes
>> this bug by replacing the old 486 references
>> with the new 686 references in binary_loopback_cfg file.
> 
> Applied. I also renamed the variables for consistency.
> 
> Cheers,
> 
Thank you for applying it.

Just for the record. I did not update those variables so that further
commits / pull requests around that code did work in a clean manner and
would not have to depend on a previous commit / patch of mine.

And, well, I somehow thought it did not matter too much. Actually
renaming them to X86 would be a better move.

But, then, you know there is 686 but... there hasn't been any 786
kernels so I don't think that variable will get renamed any where in the
future... so that's fine after all.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#884553: live-build: Foreign architecture package support for linux kernel flavours in Stretch

[adrian15]

El 21/12/17 a las 14:11, Raphael Hertzog escribió:
> Hi,
> 
> On Sat, 16 Dec 2017, adrian15 wrote:
>> Now using:
>>
>> --linux-flavours="amd64:amd64 686"
>>
>> in a i386 system does install amd64 kernel from amd64 architecture in a
>> transparent manner.
>>
>> Please tell me if there's something to be polished so that it's accepted
>> upstream.
> 
> Your patch does nothing except dropping the ":amd64" suffix. You could
> just as well not use the suffix and use your system where you manually
> enabled the foreign architecture.
> 
> I would have expected your patch to somehow add the foreign architecture
> to the build chroot and figure it out from there.
> 
> As it stands, I don't see the point of this patch.
> 
> Cheers,

  I wanted to spare you the long explanation but here it goes.

1) live-build already enables the foreign architecture in linux flavour
associated packages



https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/chroot_install-packages?id=acafe6618bfb7a9f7525e723e13ade2956e10b4f#n45

That: packages.foreign-architectures file gets created at:

https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/chroot_package-lists?id=acafe6618bfb7a9f7525e723e13ade2956e10b4f#n80

which it's reading: packages.chroot file.

packages.root file is being feed up with the linux flavour packages in:

https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/chroot_linux-image?id=acafe6618bfb7a9f7525e723e13ade2956e10b4f#n51



2) My first implementation of this patch tried not to invent a new
package variable (which would keep the :amd64 package suffix) but to
invent a new filename variable so that further code regarding installing
different linux kernel filenames did not fail later in the code.

I mean:

DEFAULT_KERNEL="$(basename chroot/boot/vmlinuz-*${DEFAULT_FLAVOUR})"

would have translated to:

DEFAULT_KERNEL="$(basename chroot/boot/vmlinuz-*amd64:amd64)"

and there is no such installed files with those filenames.

You can check it here:
https://github.com/rescatux/live-build/commit/25bbc377a2e9ca67240f7a396f53637426ba4eb6


I discarded myself this implementation because it modifies too many
lines (Occam's razor reference) and seems too much of an artificial fix.


3) So I dropped that implementation of the patch and searched for
something more elegant. A patch that modified the least possible lines
of the live-build code and I finally found out how... with this new
package based variable that would only have to be used in one specific
place.

And that's the patch I submitted here in the first place.



  Do you prefer my discarded implementation? The one I sent initially?
Or is it a better way of approaching this problem?

  Thank you for your feedback.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/