Re: Debian GNU/Hurd 2017 released!
Samuel Thibault writes: > It is with huge pleasure that the Debian GNU/Hurd team announces the > release of Debian GNU/Hurd 2017. That’s awesome! Thank you! I’d just like to note that "Hurd in 140 letters command" still works: http://www.draketo.de/english/free-software/howto-hurd-140-chars wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz; tar xf de*hu*gz; qemu-system-x86_64 -hda de*hu*g -m 1G > * It is now possible to run subhurds as unprivileged user, thus > providing easy lightweight virtualization. It would be great to have a tutorial which shows starting a subhurd very concisely — ideally starting with the qemu image as above so other people can follow the tutorial with minimal fuss. Subhurds are one of the features which might actually get companies interested in the Hurd. Can we already run subhurds from a shared readonly qemu image with per-subhurd unionfs translators to store all writes in separate locations? Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Enable PIE by default in GCC?
Hi, as $subj asks, should we ask for GCC with PIE enabled by default, like is done in the majority of the other archs (i.e. [1])? Is it supposed to work on Hurd as well, or does it require any kind of work for it? (Yes, I could dive in GCC sources, but since it is not an easy task, I figured somebody might know that already.) If so, I can send the patch for GCC, and also for dpkg (so it considers PIE as enabled by default in GCC). Apparently the current situation causes build issues when PIE is enabled for us, e.g. src:gpgme1.0, as C*FLAGS get "-specs=/usr/share/dpkg/pie-compile.specs", and LDFLAGS gets "-specs=/usr/share/dpkg/pie-link.specs". [1] as found in GCC's debian/rules.defs: pie_archs = amd64 arm64 armel armhf i386 mips mipsel mips64el \ ppc64el s390x sparc sparc64 kfreebsd-amd64 kfreebsd-i386 Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Debian GNU/Hurd 2017 released!
Hi, in http://ftp.ports.debian.org/debian-ports-cd/hurd-i386/debian-hurd-2017/debian-hurd-2017-i386-NETINST-1.iso i see a quite insane MBR partition table: $ /sbin/fdisk -lu debian-hurd-2017-i386-NETINST-1.iso ... Disklabel type: dos ... Device Boot StartEndSectors Size Id Type debian-hurd-2017-i386-NETINST-1.iso1 ?3451924861 3662313359 210388499 100.3G 0 Empty debian-hurd-2017-i386-NETINST-1.iso2 ?2766929882 4653280287 1886350406 899.5G be Solaris debian-hurd-2017-i386-NETINST-1.iso3 ? 28891953 3082391602 3053499650 1.4T 0 Empty debian-hurd-2017-i386-NETINST-1.iso4 4278184271 4278184271 0 0B d4 unknown The bytes of the MBR stem obviously from this xorrisofs option (learned from file /.disk/mkisofs in the ISO): --embedded-boot boot1/boot/grub/grub_embed One should ask the provider of grub_embed whether it is intentional to have a MBR signature in bytes 510 and 511 and to have the cleartext word "Floppy" in the range where the MBR is supposed to expose its partition table. Especially strange is that the MBR code contains lots of zeros in its first 80 bytes. Can it be that the code should be moved ~ 80 bytes lower and rather hop over a more plausible partition table beginning at byte 446 ? The MBR code itself seems to be functional. I get to a GRUB menu by $ qemu-system-x86_64 -enable-kvm -m 4096 -hda debian-hurd-2017-i386-NETINST-1.iso although the menu switches by every press of an arrow key from dark purple with horizontal and vertical roll-over to grey cyan with correct geometry. This menu display defect is not bound to MBR booting. If i erase the MBR and boot by -cdrom, i get to the same situation. (It is not 100% sure that -hda uses MBR and -cdrom uses El Torito because some virtual BIOSes are known to boot El Torito from -hda and MBR from -cdrom. So to be sure, one has to cripple the unwanted boot starting point. The default virtual BIOS of Debian 8 qemu is ok in this aspect, nevertheless.) Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Merci beaucoup to All for big work
Debian GNU/Hurd 2017 released!
It is with huge pleasure that the Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2017. This is a snapshot of Debian "sid" at the time of the stable Debian "stretch" release (May 2017), so it is mostly based on the same sources. It is not an official Debian release, but it is an official Debian GNU/Hurd port release. The installation ISO images can be downloaded from Debian Ports (http://ftp.ports.debian.org/debian-ports-cd/hurd-i386/debian-hurd-2017/) in the usual three Debian flavors: NETINST, CD, or DVD. Besides the friendly Debian installer, a pre-installed disk image is also available, making it even easier to try Debian GNU/Hurd. The easiest way to run it is inside a VM such as qemu (https://www.debian.org/ports/hurd/hurd-install) Debian GNU/Hurd is currently available for the i386 architecture with about 80% of the Debian archive, and more to come! * The core GNU Hurd and GNU Mach packages were updated to versions 0.9 and 1.8, respectively. Besides numerous other improvements, they bring vastly improved stability under memory load and prolonged uptime. * The native fakeroot tool has been greatly improved, allowing to be used for building packages, making that quite faster and safer. * It is now possible to run subhurds as unprivileged user, thus providing easy lightweight virtualization. * The supported memory size was extended beyond 3GiB. Please make sure to read the configuration information (https://www.debian.org/ports/hurd/hurd-install), the FAQ (http://www.gnu.org/software/hurd/faq.html) (or its latest version ()http://darnassus.sceen.net/~hurd-web/faq/), and the translator primer (http://www.gnu.org/software/hurd/hurd/documentation/translator_primer.html) to get a grasp of the great features of GNU/Hurd. We would like to thank all the people who have worked on GNU/Hurd (http://www.gnu.org/software/hurd/history.html) in the past. There were not many people at any given time (and still not many people today, please join (http://www.gnu.org/software/hurd/contributing.html)!), but in the end a lot of people have contributed one way or the other. Thanks everybody!
