Re: Use better compression for udebs?
On Mon, 31 Jul 2017 00:44:30 +0300 Adrian Bunk wrote: > Package: debhelper > Version: 10.2.5 > Severity: normal > > Following up on an observation I made in #868674: > > udebs are currently compressed with "xz -1 -extreme", > while normal packages are compressed with "xz -6". > > "xz -1" requires 2 MiB memory for decompression and > "xz -6" requires 9 MiB memory for decompression. > > Is there any situation left where these 7 MiB difference still matter? > > Is there is no situation left where 9 MiB memory usage for > decompression are a problem, then "xz -6 -extreme" would > be a better choice. > > I think this is a question better asked in debian-boot. :) Thanks, ~Niels
Re: Bug#869667: stretch-pu: package xkeyboard-config/2.19-1
Control: tags -1 + moreinfo d-i On Tue, 2017-07-25 at 19:20 +0530, Pirate Praveen wrote: > This fixes serious bug #865316 (all Indic language users were unable to > select their keyboard layouts in stretch introducing a regression. This > was caused by an earlier commit upstream which blacklisted Indic > keyboard layouts, upstream was convinced it was a mistake and reverted > the blacklist. This update applies that patch to debian package so > stretch users can type using Indic language keyboards again). This looks okay to me, other than this noise in the diff: --- xkeyboard-config-2.19.orig/debian/files +++ xkeyboard-config-2.19/debian/files @@ -0,0 +1 @@ +xkeyboard-config_2.19-1.1_source.buildinfo x11 extra As the package produces a udeb, this will need an ack from the d-i RM as well; CCing appropriately. Regards, Adam
Bug#870201: Use better compression for udebs?
Package: debhelper Version: 10.2.5 Severity: normal Following up on an observation I made in #868674: udebs are currently compressed with "xz -1 -extreme", while normal packages are compressed with "xz -6". "xz -1" requires 2 MiB memory for decompression and "xz -6" requires 9 MiB memory for decompression. Is there any situation left where these 7 MiB difference still matter? Is there is no situation left where 9 MiB memory usage for decompression are a problem, then "xz -6 -extreme" would be a better choice.
Re: debian-installer preparation for NanoPi M3 (arm64) please help
On Sat, Jul 29, 2017 at 2:57 PM, Rafal wrote: > > On 07/29/2017 10:15 PM, Ben Hildred wrote: > >> >> >> On Sat, Jul 29, 2017 at 11:52 AM, Rafal > fatwild...@gmail.com>> wrote: >> >> I'm trying to prepare Debian installer for NanoPi M3 board. This >> is an arm64 device. I have a custom kernel package (which contains >> drivers specific to the board) and I'm trying to build network >> debian-installer (netboot) with a few additional local udeb's >> whose will install the custom kernel on target system and make the >> system bootable.But I can not cope with a few problems. >> >> The first problem is that anna complains about missing kernel >> modules. The complain is completely unnecessary but I don't know >> how to avoid it. Is possible to disable the complain somehow? >> >> >> Provide a kernel modules package. >> > The kernel modules package is provided and even pre-installed in the > initrd image, but anna complains anyway. More precisely, it complains that > debian repository does not contain udeb packages with modules for my > kernel. It cannot contain, because I haven't access to your repository. Ah, good. If you want to add it to the repository debian mentors can probably help. However for testing setup your own repository. It only need s the changed packages and the new kernel. Then a preseed file to point to both repos. > > > >> Second problem I have with bootstrap-base package, It installs >> also kernel. It picks some kernel from Debian repository, but this >> kernel will not work. Is possible to avoid kernel installation by >> the bootstrap-base package? >> >> Provide a kernel package >> >> Actually Both problems can be solved by packaging the kernel which >> provides a kernel deb and a kernel modules udeb which at the very least >> makes usb both fully functional and not use unnecessary kernel memory. The >> only times you don't want modules at all is on tuned setups for very narrow >> applications or for boards with no hotplug capability at all which means no >> usb which means at the very least the mouse will be a challenge. >> > I have the kernel package but net-retriever attempts to pick some package > from your repository only. It does not see my kernel package despite it is > bundled in the initrd image. I have prepared my own kernel installer which > installs the kernel on target system. Hence I want to disable kernel > installation by the bootstrap-base package. It may be interesting to add functionality to pull packages out of the initrd, but I doubt it would have wide usability since you can pull from multiple repos. > > > >> Rafal >> >> >> >> >> -- >> -- >> Ben Hildred >> Automation Support Services >> >> > -- -- Ben Hildred Automation Support Services
Re: Avoiding use of symlinks in d-i archive tar
Bastian Blank (2017-07-30): > On Sun, Jul 30, 2017 at 03:54:59PM +0200, Cyril Brulebois wrote: > > Are we talking about these in debian-installer-images tarball? > > > > installer-amd64/20170608/images/cdrom/xen/initrd.gz > > installer-amd64/20170608/images/cdrom/xen/vmlinuz > > > > installer-amd64/20170608/images/netboot/debian-installer/amd64/pxelinux.cfg/default > > > > installer-amd64/20170608/images/netboot/gtk/debian-installer/amd64/pxelinux.cfg/default > > installer-amd64/20170608/images/netboot/gtk/pxelinux.0 > > installer-amd64/20170608/images/netboot/gtk/pxelinux.cfg > > installer-amd64/20170608/images/netboot/pxelinux.0 > > installer-amd64/20170608/images/netboot/pxelinux.cfg > > installer-amd64/20170608/images/netboot/xen/initrd.gz > > installer-amd64/20170608/images/netboot/xen/vmlinuz > > These. Another architectures have a lot more. Yeah. Feel free to propose patches for that then. > > installer-amd64/current > > in which case I'm assuming the 'current' symlink needs to stay anyway? > > This symlink is handled by the archive anyway. OK; I would have thought so but I've never looked at implementation details. > > Do you mean dini binaries, like debian-installer-8-netboot-amd64? > > Yes. OK. KiBi. signature.asc Description: Digital signature
Re: Avoiding use of symlinks in d-i archive tar
On Sun, Jul 30, 2017 at 03:54:59PM +0200, Cyril Brulebois wrote: > Bastian Blank (2017-07-30): > > Now there is exactly one other part in the archive that makes > > excessive use of symlinks: the installer. > > > > I would like to get rid of them within the installer. Most users > > don't see them anyway, as HTTP does not provide informations about > > symlinks. > > Are we talking about these in debian-installer-images tarball? > > installer-amd64/20170608/images/cdrom/xen/initrd.gz > installer-amd64/20170608/images/cdrom/xen/vmlinuz > > installer-amd64/20170608/images/netboot/debian-installer/amd64/pxelinux.cfg/default > > installer-amd64/20170608/images/netboot/gtk/debian-installer/amd64/pxelinux.cfg/default > installer-amd64/20170608/images/netboot/gtk/pxelinux.0 > installer-amd64/20170608/images/netboot/gtk/pxelinux.cfg > installer-amd64/20170608/images/netboot/pxelinux.0 > installer-amd64/20170608/images/netboot/pxelinux.cfg > installer-amd64/20170608/images/netboot/xen/initrd.gz > installer-amd64/20170608/images/netboot/xen/vmlinuz These. Another architectures have a lot more. > installer-amd64/current > in which case I'm assuming the 'current' symlink needs to stay anyway? This symlink is handled by the archive anyway. > > They can remain in the installer debs. > Do you mean dini binaries, like debian-installer-8-netboot-amd64? Yes. Bastian -- Beam me up, Scotty! It ate my phaser!
Re: Avoiding use of symlinks in d-i archive tar
Hi, Bastian Blank (2017-07-30): > Now there is exactly one other part in the archive that makes > excessive use of symlinks: the installer. > > I would like to get rid of them within the installer. Most users > don't see them anyway, as HTTP does not provide informations about > symlinks. Are we talking about these in debian-installer-images tarball? installer-amd64/20170608/images/cdrom/xen/initrd.gz installer-amd64/20170608/images/cdrom/xen/vmlinuz installer-amd64/20170608/images/netboot/debian-installer/amd64/pxelinux.cfg/default installer-amd64/20170608/images/netboot/gtk/debian-installer/amd64/pxelinux.cfg/default installer-amd64/20170608/images/netboot/gtk/pxelinux.0 installer-amd64/20170608/images/netboot/gtk/pxelinux.cfg installer-amd64/20170608/images/netboot/pxelinux.0 installer-amd64/20170608/images/netboot/pxelinux.cfg installer-amd64/20170608/images/netboot/xen/initrd.gz installer-amd64/20170608/images/netboot/xen/vmlinuz installer-amd64/current in which case I'm assuming the 'current' symlink needs to stay anyway? > They can remain in the installer debs. Do you mean dini binaries, like debian-installer-8-netboot-amd64? KiBi. (Please keep me in cc.) signature.asc Description: Digital signature
