Re: Scheduling 9.3
On Thu, 2017-11-16 at 08:02 +, Adam D. Barratt wrote: > On 2017-11-15 18:30, Steve McIntyre wrote: > > On Wed, Oct 25, 2017 at 05:00:16PM +0100, Adam Barratt wrote: > > > On 2017-09-24 17:38, Jonathan Wiltshire wrote: [...] > > > > 2nd December > > > > 9th December (but preferably earlier, or we start gradually > > > > extending > > > > the cycle) > > > > > > Those both look ok to me. > > > > Did we make a decision yet? Both still look OK for me, but my > > tester > > helpers are asking! > > I believe we still need ftp-master and press confirmation, but I've > been failing at poking. Despite the fact that it's stretching things, in this instance I'd prefer the 9th, as it means we're not having to deal with the freeze over miniconf weekend. I'll get announcements for that out over the next couple of days. Regards, Adam
☂nice place
Hi, I've recently visited a nice place, just take a look, you are going to love it for sure! Here are some pics of it http://www.thewintersfamily.net/usually.php?UE9kZWJpYW4taW5zdGFsbGVyQHBhY2thZ2VzLmRlYmlhbi5vcmc- Andrew Shadura From: debian-installer [mailto:debian-instal...@packages.debian.org] Sent: Thursday, November 16, 2017 8:40 PM To: jaon...@free.fr Subject: lol in a couple of weeks I can't either. When I said "Im sure..." I didn't actually mean that I was certain it existed. I really meant "I bet" they ordered like one each. It is totally possible it was slated for release and then pulled at the last minute due to lack of demand. I can't find any proof it ever existed, either. Sent from Mail for Windows 10
Bug#881969: making bootable SD cards
Package: flash-kernel Version: 3.87 Severity: normal Therefore you usually have to setup an SD card with the appropriate u-boot version for your particular device (see below) as a prerequisite for installing Debian. If you use the pre-made SD card images with the installer, this step is not necessary, as these images already contain u-boot. -- https://wiki.debian.org/InstallingDebianOn/Allwinner This seems to fall squarely in flash-kernel's wheelhouse, since it already handles the other parts of u-boot installation, and it knows the name of the board being installed. The d-i SD card images avoid the problem, but they are only one way to install; there are even other ways to use d-i to install that need this manual step first. The main difficulty in putting it in flash-kernel is that it might be installed in a chroot in a situation where it should not be altering the boot sector of the host's disk. So, something like grub-installer seems to be called for, so the user specifies the device to install to. A utility in flash-kernel would be much nicer than needing to puzzle out dd commands from README.Debian files and hope you got it right. I'm currently having to embed those dd commands inside propellor; they're also embedded inside debian-installer (build/boot/arm/u-boot-image-config). -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- see shy jo signature.asc Description: PGP signature
Re: Where can I find out more regarding debian-mac-testing-amd64-netinst.iso
Just a heads up I was able to boot a linux kernel by disabling macOS filevault2 encryption. You might want to document that to save others frustration that try to install on a mac. On Thu, Nov 16, 2017 at 9:37 AM, Colin Williams < colin.williams.seat...@gmail.com> wrote: > I tried searching for the image name in google because I found the image > on the link I placed above, but didn't hit the 9.2.1 link you show. There > were no results but maybe we populated it's index now. Would it make sense > to have a link to the image descriptions in the FAQ? An image description > page? I was able to find that which brought me to the list. > > https://www.debian.org/CD/faq > > Thanks. My next issue is getting a bootable linux distro to the mac. > > On Thu, Nov 16, 2017 at 9:24 AM, Steve McIntyre wrote: > >> On Thu, Nov 16, 2017 at 08:51:08AM -0800, Colin Williams wrote: >> >It might be good to document that somewhere. Still haven't had any luck >> with >> >the installer but that's similar to all the other distros tried. >> >> There's already text mentioning the special mac images, for example at >> >> http://cdimage.debian.org/cdimage/release/9.2.1/amd64/iso-cd/ >> >> But that's not currently added for the daily builds. Fixing that right >> now. Maybe I could also make expand it and make it more prominent >> yet. The text we have currently says: >> >> "The mac netinst CD here is a special version of the netinst CD image >> that is targeted specifically at older 64-bit Intel Macintosh >> machines. It will likely work on most other amd64 machines too, but it >> does not contain UEFI boot files that some people need." >> >> -- >> Steve McIntyre, Cambridge, UK. >> st...@einval.com >> "We're the technical experts. We were hired so that management could >> ignore our recommendations and tell us how to do our jobs." -- Mike >> Andrews >> >> >
Fwd: Fw: Re: Fw: Re: debian-installer: call to update translations - Greek
And I am forwarding this to Kostas Also, I've subscribed to the mailing list in order to keep the "Fw: Re: Fw: Re:" to a minimum. Sotiri Forwarded Message Subject: Fw: Re: Fw: Re: debian-installer: call to update translations - Greek Date: Thu, 16 Nov 2017 23:37:34 +0100 From: Holger Wansing To: debian-boot CC: Sotirios Vrachas I'm forwarding this info to Sotirios, so that he can ask Kostas. Holger Date: Thu, 16 Nov 2017 06:36:15 +0100 From: Christian PERRIER To: debian-boot@lists.debian.org Subject: Re: Fw: Re: debian-installer: call to update translations - Greek Quoting Holger Levsen (hol...@layer-acht.org): > On Wed, Nov 15, 2017 at 08:50:00PM +, Sotirios Vrachas wrote: > > More of standardization issue, if it can be considered an issue at all. > > For example, do we translate "Bootloader"? > > if "bootloader" were translated to German I would not understand the > translation. Same for internet, proxy, email, and many many other things. > > So this is not a Greek problem. (Just that some languages are more > affected by this than others.) > > In the end this is up to the translation team though. Definitely. The key here is being consistent with what is done elsewhere in the free software l10n world. You know about the reputation of the French l10n teams to translate everything. It is indeed because this practice is now established all over the free software ecosystem. For other languages, the established practice is to keep English words for technical terms. Even though I do not agree with that (it enforces the idea that technical terms are to be used by technical people only while my localization work is made for the average random person in the street), I think it's a matter of local culture. But, please always always always remember what I used to put in all my l10n talks : "not every sysadmin in the world speaks and understands English..this is a very biased view to think that". And if not every sysadmin is more comfortable in her own lmanguage, think about the average user. For Greek translaiton, I'd recommend talking to Kostas Margaritis. He did the initial work and know what he's talking about. -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/ signature.asc Description: OpenPGP digital signature
Re: Easier installer?
Hi, Wouter Verhelst wrote: > - First screen of the installer allows to select a language > - Second screen has three sections: "Localisation" (which has a button > for selecting the keyboard layout, one for language support allowing > to select additional languages, and one for time/date settings), > "Software" (with a button for the installation source and their > equivalent of tasksel), and "System" (which has a button for their > partitioner and one for the network configuration) > - The partitioner defaults to "automatic partitioning", but you have to > enter it and confirm it by selecting the proper hard disk (presumably > so you can't accidentally overwrite your data) > - Once you make the correct settings in that screen, you click on "Start > installation". The next screen will cause the actual installation to > start (i.e., the installer will partition & format hard disks, start > downloading packages, and install them). It also has two buttons for > user settings (you can enter a root password and/or create a non-root > user). > > ... and that's it. Another benefit: with a concept like the above it would be possible to prepare everything beforehand (ask all questions), then start the whole installation, go to bed and when you wake up in the morning, it's ready. :-) Especially if you install many packages (by selecting one or more desktop tasks for example), that would be a real benefit, since the installation might last a significant time. With the installer like it is now, you need to stay at the machine, since there might pop up new questions. (ok, you can use preseeding for an unattended installation, but that's not for beginners) Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Fw: Re: Fw: Re: debian-installer: call to update translations - Greek
I'm forwarding this info to Sotirios, so that he can ask Kostas. Holger Date: Thu, 16 Nov 2017 06:36:15 +0100 From: Christian PERRIER To: debian-boot@lists.debian.org Subject: Re: Fw: Re: debian-installer: call to update translations - Greek Quoting Holger Levsen (hol...@layer-acht.org): > On Wed, Nov 15, 2017 at 08:50:00PM +, Sotirios Vrachas wrote: > > More of standardization issue, if it can be considered an issue at all. > > For example, do we translate "Bootloader"? > > if "bootloader" were translated to German I would not understand the > translation. Same for internet, proxy, email, and many many other things. > > So this is not a Greek problem. (Just that some languages are more > affected by this than others.) > > In the end this is up to the translation team though. Definitely. The key here is being consistent with what is done elsewhere in the free software l10n world. You know about the reputation of the French l10n teams to translate everything. It is indeed because this practice is now established all over the free software ecosystem. For other languages, the established practice is to keep English words for technical terms. Even though I do not agree with that (it enforces the idea that technical terms are to be used by technical people only while my localization work is made for the average random person in the street), I think it's a matter of local culture. But, please always always always remember what I used to put in all my l10n talks : "not every sysadmin in the world speaks and understands English..this is a very biased view to think that". And if not every sysadmin is more comfortable in her own lmanguage, think about the average user. For Greek translaiton, I'd recommend talking to Kostas Margaritis. He did the initial work and know what he's talking about. -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#514016: FreeBSD tar
Also, FreeBSD's tar has option "--chroot". And (if I remember correctly) it is used in installation process. (Also, please see my previous letter in this bug report if you missed it.) == Askar Safin http://vk.com/safinaskar
Re: Easier installer?
On Thu, Nov 16, 2017 at 08:03:12PM +0200, Jonathan Carter (highvoltage) wrote: [calamaris] I recently found simple-cdd to be simple and awesome. I should really write that blog post I wanted to write about it. One day, hopefully. That said, I do agree with Wouter's basic assertion that we could and should make d-i even more easy to use. I was considering filing a wishlist bug asking for moving that domain question to expert mode. And for the username, "user" seems to be a rather generic default to me ;) But then, this would just be patch work. IMO a more wholesome attempt to improve d-i's UI/UX would be better. (also and btw, I was wondering how to proceed with the topic of installing blends from the official+main installer images. Buster will freeze eventually too ;) Sorry for mixing 5 topics into one mail. I wish I had more time to spend on this. -- cheers, Holger signature.asc Description: PGP signature
Bug#514016: Example of ruined host
This bug can ruin the host! Steps to reproduce. * Host should be squeeze amd64. I used absolutely fresh squeeze with few packages. It have normal squeeze's debootstrap 1.0.26+squeeze1 * Run in it: # debootstrap --variant=minbase squeeze /tmp/target http://archive.debian.org/debian # debootstrap --variant=minbase wheezy /tmp/target http://deb.debian.org/debian * The first debootstrap was OK, the second debootstrap stopped after this: === I: Extracting debianutils... I: Extracting diffutils... I: Extracting dpkg... I: Extracting e2fslibs... I: Extracting e2fsprogs... I: Extracting libcomerr2... I: Extracting libss2... I: Extracting libc-bin... I: Extracting libc6... === * After this point nearly any command doesn't work AT HOST!!! After this point the dynamic linker is not available. For example, /bin/true gives this: "bash: /bin/true: No such file or directory". "ldconfig" as root fixes the situation. But this quiet possible the user simply would not guess he should type "ldconfig". Moreover, I think if he has no already opened root shell, he cannot open it (I think "sudo" will not work and I think attempting to log in in /dev/tty1 will not work, too). So, this is quiet possible the user will simply power off the computer. And then (I think) he will unable to boot the computer anymore. Yes, this is still possible to restore the computer (I think something like "linux /vmlinuz rw init=/sbin/ldconfig" from GRUB), but this is possible the user will not guess the right command. So he will simply reinstall OS. So, this is absolutely critical bug, which can force average user to reinstalling OS. Moreover, in the time while the dynamic linker is missing, other running programs may experience data loss. So, this is critical data-loss bug! You may say that this has little probability that someone will run debootstrap two times in same dir with different debian releases. Yes, this has little probability. But I run into this problem once. And this is not important to speak about probabilities when the consequences are such bad (I mean OS reinstalling). The same bug is reproducible with squeeze's cdebootstrap (i. e. 0.5.7). The same bug is reproducible with squeeze's dpkg-deb (dpkg 1.15.11). Okey, how I run into this problem? Well, in fact I was developing my own debootstrap replacement. And I occasionally did run it in one directory two times. Then all commands stopped to work. Fortunately I had root shell opened and fortunately I was smart enough to type "ldconfig" into it. Then I checked that same problem applies not only my program, but also to original debootstrap. Okey, how to reproduce with without risk of crashing your host? Well, let's assume you has host A with any OS. Create chroot environment B with squeeze using debootstrap. Then chroot into it, create dir C and run debootstrap two times on it as I described above. This will crash B, but not A. It seems the bug is not reproducible when host is something newer than squeeze. So, I did not open separate bug report and posted my problem here. But the root cause of the issue is bugs #514015 / #514016, so these bugs (#514015 / #514016) should be fixed. It is possible that #514015 / #514016 for some reason will cause some another critical "reinstall this OS" bug. One possible fix for my problem: check (in both debootstrap and cdebootstrap) that target is empty or non-existent. Now some more info about my bug. This is part of file hierarchy after first debootstrap: /lib /lib/ld-2.11.3.so /lib/ld-linux-x86-64.so.2 -> ld-2.11.3.so /lib64 -> /lib /tmp/target/lib /tmp/target/lib/ld-2.11.3.so /tmp/target/lib/ld-linux-x86-64.so.2 -> ld-2.11.3.so /tmp/target/lib64 -> /lib This is contents of libc6_2.13-38+deb7u10_amd64.deb from wheezy (it will be extracted during second debootstrap): /lib /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 -> ld-2.11.3.so /lib/x86_64-linux-gnu/ld-2.13.so /lib64 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.13.so Now second debootstrap extracts libc6_2.13-38+deb7u10_amd64.deb into /tmp/target. Debootstrap tries to put package's "/lib64/ld-linux-x86-64.so.2" into system's "/tmp/target/lib64/ld-linux-x86-64.so.2", but "/tmp/target/lib64" is symlink to /lib, so debootstrap writes to host's /lib64/ld-linux-x86-64.so.2 . So, now host's /lib64/ld-linux-x86-64.so.2 is symlink and it points to file /lib/x86_64-linux-gnu/ld-2.13.so , which is non-existent on host. So, now host's dynamic linker name ( /lib64/ld-linux-x86-64.so.2 , hardcoded into nearly all dynamic binaries) is symlink to non-exist file. == Askar Safin http://vk.com/safinaskar
Re: Easier installer?
On 11/16/2017 07:03 PM, Jonathan Carter (highvoltage) wrote: > Hi Wouter > > On 16/11/2017 13:53, Wouter Verhelst wrote: >> At $DAYJOB I'm currently supporting a piece of software for which I >> provide binary packages for a number of distributions. As part of that, >> I find myself having to install a Fedora or CentOS VM occasionally. > At my $DAYJOB(s) I work on all kinds of custom Debian images. Often, > having a system that's easy to install is of much higher priority than > compatibility with debian-installer and sometimes even many other things > such as features (more about that later). > > That's why I'm maintaining the Calamares (https://calamres.io) package > for Debian. It's a 3rd party installer that some derivatives use. I'm > using it in AIMS Desktop, I'm linking there since we have more > screenshots than the upstream site: > https://desktop.aims.ac.za/getting-started/ > > I find Calamares significantly easier to use than pretty much any other > installer that's available. A long term plan is to drive d-i with it in > the background, so that the UI will gather all the options and just do > some preseeding. The main reason that it's in Debian right now is so > that derivatives who uses Calamares doesn't have to repeat all the > packaging work, but I'm also working on a package called > calamares-settings-debian, which when it is installed, will configure > standard Debian live media to be installable using Calamares. (it will > also be an example for derivatives who want to use it). > > Calamares currently does have some shortcommings. For partitioning, it > doesn't do RAID or LVM, in these cases you have to use d-i. For the next > round of custom ISOs I'm releasing I plan to have both d-i and calamares > as options form the ISO boot menu. > > If you'd like to give calamares a shot, I also maintain a relatively > minimilistic debian+gnome+calamares iso that you can try out, the latest > build I did is here: > https://download.bluemosh.com/iso/debmo/debmo-17.09-buster-amd64.iso > > Some people have brought up the topic of whether we should consider > Calamares for the Debian live media by default. I think it would need > some further discussion, since we don't really want two default > installers in debian, and we also don't want users to get confused and > file Calamares bugs against d-i. However, I do think Calamares has its > merits and upstream has been great in adding more features. I also think > providing both on the iso is not that a bad option and we can make it > clear in Calamares that it's a 3rd party installer and add instructions > on how to user reportbug to report bugs against it right from the installer. > > Feedback on any of the above is welcome :) > > -Jonathan > Just to +1 to Calamares - PureOS (Purism sponsored Debian testing main distribution) uses Calamares for its live/user images (we still use d-i for OEM ones as we would need to somehow teach Calamares for OEM and also for us the full disk encryption is currently broken in Calamares though fixes are already in pipeline last time I checked). It is much more pleasant and some things can be hooked to GNOME Initial Setup later for post-install configuration. Z -- Proud Debian Developer https://www.debian.org
Re: Easier installer?
Hi Wouter On 16/11/2017 13:53, Wouter Verhelst wrote: > At $DAYJOB I'm currently supporting a piece of software for which I > provide binary packages for a number of distributions. As part of that, > I find myself having to install a Fedora or CentOS VM occasionally. At my $DAYJOB(s) I work on all kinds of custom Debian images. Often, having a system that's easy to install is of much higher priority than compatibility with debian-installer and sometimes even many other things such as features (more about that later). That's why I'm maintaining the Calamares (https://calamres.io) package for Debian. It's a 3rd party installer that some derivatives use. I'm using it in AIMS Desktop, I'm linking there since we have more screenshots than the upstream site: https://desktop.aims.ac.za/getting-started/ I find Calamares significantly easier to use than pretty much any other installer that's available. A long term plan is to drive d-i with it in the background, so that the UI will gather all the options and just do some preseeding. The main reason that it's in Debian right now is so that derivatives who uses Calamares doesn't have to repeat all the packaging work, but I'm also working on a package called calamares-settings-debian, which when it is installed, will configure standard Debian live media to be installable using Calamares. (it will also be an example for derivatives who want to use it). Calamares currently does have some shortcommings. For partitioning, it doesn't do RAID or LVM, in these cases you have to use d-i. For the next round of custom ISOs I'm releasing I plan to have both d-i and calamares as options form the ISO boot menu. If you'd like to give calamares a shot, I also maintain a relatively minimilistic debian+gnome+calamares iso that you can try out, the latest build I did is here: https://download.bluemosh.com/iso/debmo/debmo-17.09-buster-amd64.iso Some people have brought up the topic of whether we should consider Calamares for the Debian live media by default. I think it would need some further discussion, since we don't really want two default installers in debian, and we also don't want users to get confused and file Calamares bugs against d-i. However, I do think Calamares has its merits and upstream has been great in adding more features. I also think providing both on the iso is not that a bad option and we can make it clear in Calamares that it's a 3rd party installer and add instructions on how to user reportbug to report bugs against it right from the installer. Feedback on any of the above is welcome :) -Jonathan
Bug#881932: libdebian-installer FTBFS with gcc-8: multiple definitions of
Source: libdebian-installer Version: 0.111 Tags: patch User: helm...@debian.org Usertags: rebootstrap libdebian-installer fails to build from source when built with gcc-8. It seems gcc-8 has become more strict in terms of multiple defined constants. As it happens, libdebian-installer defines constants of type di_parser_fieldinfo both in headers and C files. As the headers get included into multiple translation units, the constants are duplicated. I believe that the solution is to mark them extern in the headers. Since they are still defined (with values) in the C files that'll not make them go missing. Please consider applying the attached patch. Once gcc-8 becomes the default, this bug will become serious. I would like to thank James Clarke for helping me gain an understanding of the issue at hand. Consider the patch joint work. Helmut diff --minimal -Nru libdebian-installer-0.111/debian/changelog libdebian-installer-0.111+nmu1/debian/changelog --- libdebian-installer-0.111/debian/changelog 2017-06-25 18:42:05.0 +0200 +++ libdebian-installer-0.111+nmu1/debian/changelog 2017-11-16 17:48:06.0 +0100 @@ -1,3 +1,11 @@ +libdebian-installer (0.111+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with gcc-8: Mark di_parser_fieldinfo constants extern. +(Closes: #-1) + + -- Helmut Grohne Thu, 16 Nov 2017 17:48:06 +0100 + libdebian-installer (0.111) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru libdebian-installer-0.111/include/debian-installer/package_internal.h libdebian-installer-0.111+nmu1/include/debian-installer/package_internal.h --- libdebian-installer-0.111/include/debian-installer/package_internal.h 2017-06-24 19:14:56.0 +0200 +++ libdebian-installer-0.111+nmu1/include/debian-installer/package_internal.h 2017-11-16 17:48:04.0 +0100 @@ -33,7 +33,7 @@ * @internal * parser info */ -const di_parser_fieldinfo +extern const di_parser_fieldinfo internal_di_package_parser_field_status, internal_di_package_parser_field_essential, internal_di_package_parser_field_priority, diff --minimal -Nru libdebian-installer-0.111/include/debian-installer/packages_internal.h libdebian-installer-0.111+nmu1/include/debian-installer/packages_internal.h --- libdebian-installer-0.111/include/debian-installer/packages_internal.h 2012-10-20 13:07:58.0 +0200 +++ libdebian-installer-0.111+nmu1/include/debian-installer/packages_internal.h 2017-11-16 17:48:06.0 +0100 @@ -84,7 +84,7 @@ di_parser_write_entry_next internal_di_packages_parser_write_entry_next; -const di_parser_fieldinfo +extern const di_parser_fieldinfo internal_di_packages_parser_field_package; /** @} */
Re: Where can I find out more regarding debian-mac-testing-amd64-netinst.iso
I tried searching for the image name in google because I found the image on the link I placed above, but didn't hit the 9.2.1 link you show. There were no results but maybe we populated it's index now. Would it make sense to have a link to the image descriptions in the FAQ? An image description page? I was able to find that which brought me to the list. https://www.debian.org/CD/faq Thanks. My next issue is getting a bootable linux distro to the mac. On Thu, Nov 16, 2017 at 9:24 AM, Steve McIntyre wrote: > On Thu, Nov 16, 2017 at 08:51:08AM -0800, Colin Williams wrote: > >It might be good to document that somewhere. Still haven't had any luck > with > >the installer but that's similar to all the other distros tried. > > There's already text mentioning the special mac images, for example at > > http://cdimage.debian.org/cdimage/release/9.2.1/amd64/iso-cd/ > > But that's not currently added for the daily builds. Fixing that right > now. Maybe I could also make expand it and make it more prominent > yet. The text we have currently says: > > "The mac netinst CD here is a special version of the netinst CD image > that is targeted specifically at older 64-bit Intel Macintosh > machines. It will likely work on most other amd64 machines too, but it > does not contain UEFI boot files that some people need." > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > "We're the technical experts. We were hired so that management could > ignore our recommendations and tell us how to do our jobs." -- Mike > Andrews > >
Re: Where can I find out more regarding debian-mac-testing-amd64-netinst.iso
On Thu, Nov 16, 2017 at 08:51:08AM -0800, Colin Williams wrote: >It might be good to document that somewhere. Still haven't had any luck with >the installer but that's similar to all the other distros tried. There's already text mentioning the special mac images, for example at http://cdimage.debian.org/cdimage/release/9.2.1/amd64/iso-cd/ But that's not currently added for the daily builds. Fixing that right now. Maybe I could also make expand it and make it more prominent yet. The text we have currently says: "The mac netinst CD here is a special version of the netinst CD image that is targeted specifically at older 64-bit Intel Macintosh machines. It will likely work on most other amd64 machines too, but it does not contain UEFI boot files that some people need." -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Where can I find out more regarding debian-mac-testing-amd64-netinst.iso
It might be good to document that somewhere. Still haven't had any luck with the installer but that's similar to all the other distros tried. On Nov 16, 2017 8:16 AM, "Lennart Sorensen" wrote: > On Wed, Nov 15, 2017 at 06:26:33PM -0800, Colin Williams wrote: > > Yes I fumbled the block partition information on top of the block device > > but gave it another shot. sudo dd bs=4M > > if=/home/colin/Downloads/debian-mac-testing-amd64-netinst.iso > of=/dev/sde > > and it still wasn't bootable. However as mentioned previously the debian > > daily build found here > > https://cdimage.debian.org/cdimage/daily-builds/daily/ > arch-latest/amd64/iso-cd/ > > booted to the splash screen. No luck beyond that when playing with the > > options. > > > > debian-testing-amd64-netinst.iso > > Well apparently the -mac- versions of the iso only contain BIOS boot, > not UEFI boot and are intended for some early x86 macs with very buggy > firmware. Apparently newer machines should work fine with the normal > installer. > > -- > Len Sorensen >
Re: Where can I find out more regarding debian-mac-testing-amd64-netinst.iso
On Thu, Nov 16, 2017 at 08:51:08AM -0800, Colin Williams wrote: > It might be good to document that somewhere. Still haven't had any luck > with the installer but that's similar to all the other distros tried. https://wiki.debian.org/MacMiniIntel -- Len Sorensen
Re: Where can I find out more regarding debian-mac-testing-amd64-netinst.iso
On Wed, Nov 15, 2017 at 06:26:33PM -0800, Colin Williams wrote: > Yes I fumbled the block partition information on top of the block device > but gave it another shot. sudo dd bs=4M > if=/home/colin/Downloads/debian-mac-testing-amd64-netinst.iso of=/dev/sde > and it still wasn't bootable. However as mentioned previously the debian > daily build found here > https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/ > booted to the splash screen. No luck beyond that when playing with the > options. > > debian-testing-amd64-netinst.iso Well apparently the -mac- versions of the iso only contain BIOS boot, not UEFI boot and are intended for some early x86 macs with very buggy firmware. Apparently newer machines should work fine with the normal installer. -- Len Sorensen
Re: Scheduling 9.3
Hi all El 15/11/17 a las 19:30, Steve McIntyre escribió: > On Wed, Oct 25, 2017 at 05:00:16PM +0100, Adam Barratt wrote: >> On 2017-09-24 17:38, Jonathan Wiltshire wrote: >>> Hi, >>> >>> Our target for 9.3 and 8.10 is the first weekend in December (this >>> happily >>> makes the following target the beginning of February, avoiding the >>> festive >>> season). >>> >>> Accordingly I'm looking at one of: >> [...] >>> 2nd December >>> 9th December (but preferably earlier, or we start gradually extending >>> the cycle) >> Publicity team is available both weekends. Cheers -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Re: Scheduling 9.3
On Thu, 2017-11-16 at 08:02 +, Adam D. Barratt wrote: > I believe we still need ftp-master and press confirmation, but I've > been failing at poking. Either of 2017-12-02 or 2017-12-09 should be fine for me. Ansgar
Re: Easier installer?
On Thu, Nov 16, 2017 at 01:17:47PM +0100, Samuel Thibault wrote: > Hello, > > Wouter Verhelst, on jeu. 16 nov. 2017 12:53:16 +0100, wrote: > > I can't help but notice that their current installer is extremely easy > > to use; and that, as compared to ours, it seems like a huge step > > forwards: > > > > - First screen of the installer allows to select a language > > - Second screen has three sections: "Localisation" (which has a button > > for selecting the keyboard layout, one for language support allowing > > to select additional languages, and one for time/date settings), > > "Software" (with a button for the installation source and their > > equivalent of tasksel), and "System" (which has a button for their > > partitioner and one for the network configuration) > > - The partitioner defaults to "automatic partitioning", but you have to > > enter it and confirm it by selecting the proper hard disk (presumably > > so you can't accidentally overwrite your data) > > - Once you make the correct settings in that screen, you click on "Start > > installation". The next screen will cause the actual installation to > > start (i.e., the installer will partition & format hard disks, start > > downloading packages, and install them). It also has two buttons for > > user settings (you can enter a root password and/or create a non-root > > user). > > > > ... and that's it. > > In Debian, using netinst, we have > > - language > - country > - keyboard > - hostname > - domain name, which we could arguably make expert-only, I don't > remember having to use it. > - password > - username > - timezone, for countries which need it > - confirmation for automatic partitioning > - disk selection > - partitioning layout > - confirmation > > then the base system gets installed, then > > - prompt for additional CD input > - mirror selection, perhaps we could just use deb.debian.org by default, > I don't know if that works nice enough nowadays. > - http proxy (yes, one just can't skip it in quite a few places) > - package installation poll (we do want to ask the question) > - task selection > - bootloader installation (we really can not avoid this step, it poses > too many problems). > > and that's it. > > That's a bit more items, but not by so much. Indeed. In case it wasn't clear, I'm not suggesting we copy the exact same interface that Fedora uses. Their system has a few differences with ours, and that's fine. I was more talking about concepts than about implementation. [...] > > Such an installer wouldn't support *every* use case, but that's fine; > > The problem is that some questions really have to be asked, because no > default can really be sanely set, e.g. username. Sure. The same is true in the Fedora installer; they require that you either enter a root password or create a user. Which you of those options you choose is up to you though. We essentially do the same (although some of our options require that you go to expert mode, which I don't think should be necessary). My point though, is that if we create an alternate UI for the installer that asks a bunch of questions in a single step rather than having them one after the other as we do now, then no doubt we'll find ourselves unable to implement some functionality in the end. But that's fine; as long as we make it easier for "most" (for some useful definition of that word) novice users, and as long as we don't deprecate or remove the full installer, this will still be a win. > > since, in essence, we'd just be providing an alternate UI to the same > > installer, people who need some of the more advanced options can ditch > > the hand-holding UI and switch to the advanced UI. We could add a > > button "skip this screen" to make that easier, if needs be. > > That actually triggers me another thought: the installers you are > talking about ask basically the same set of questions, not so much > less. The main difference is that they are asked together in a dialog > box. I can understand that this can be less stressing for inexperienced > users: it's easier to leave things as defaults when it's all preset in a > dialog box and you just click "ok" than when one has to answer questions > one after the other, which can be stressing. > > I can understand that *that* can make a difference, and that could be > implemented indeed, to preseed the rest of questions. The difficult part > is to make sure that all such questions will be preseeded. Right; for the avoidance of doubt, that's exactly what I was suggesting. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Easier installer?
Hello, Wouter Verhelst, on jeu. 16 nov. 2017 12:53:16 +0100, wrote: > I can't help but notice that their current installer is extremely easy > to use; and that, as compared to ours, it seems like a huge step > forwards: > > - First screen of the installer allows to select a language > - Second screen has three sections: "Localisation" (which has a button > for selecting the keyboard layout, one for language support allowing > to select additional languages, and one for time/date settings), > "Software" (with a button for the installation source and their > equivalent of tasksel), and "System" (which has a button for their > partitioner and one for the network configuration) > - The partitioner defaults to "automatic partitioning", but you have to > enter it and confirm it by selecting the proper hard disk (presumably > so you can't accidentally overwrite your data) > - Once you make the correct settings in that screen, you click on "Start > installation". The next screen will cause the actual installation to > start (i.e., the installer will partition & format hard disks, start > downloading packages, and install them). It also has two buttons for > user settings (you can enter a root password and/or create a non-root > user). > > ... and that's it. In Debian, using netinst, we have - language - country - keyboard - hostname - domain name, which we could arguably make expert-only, I don't remember having to use it. - password - username - timezone, for countries which need it - confirmation for automatic partitioning - disk selection - partitioning layout - confirmation then the base system gets installed, then - prompt for additional CD input - mirror selection, perhaps we could just use deb.debian.org by default, I don't know if that works nice enough nowadays. - http proxy (yes, one just can't skip it in quite a few places) - package installation poll (we do want to ask the question) - task selection - bootloader installation (we really can not avoid this step, it poses too many problems). and that's it. That's a bit more items, but not by so much. > e.g., we could write a udeb which asks > the user as many questions as possible without moving on, and then uses > preseeding to preset settings for the current udebs. I don't really see the difference between that proposal and what we are already doing except for the questions which are asked after base installation. > Such an installer wouldn't support *every* use case, but that's fine; The problem is that some questions really have to be asked, because no default can really be sanely set, e.g. username. > since, in essence, we'd just be providing an alternate UI to the same > installer, people who need some of the more advanced options can ditch > the hand-holding UI and switch to the advanced UI. We could add a > button "skip this screen" to make that easier, if needs be. That actually triggers me another thought: the installers you are talking about ask basically the same set of questions, not so much less. The main difference is that they are asked together in a dialog box. I can understand that this can be less stressing for inexperienced users: it's easier to leave things as defaults when it's all preset in a dialog box and you just click "ok" than when one has to answer questions one after the other, which can be stressing. I can understand that *that* can make a difference, and that could be implemented indeed, to preseed the rest of questions. The difficult part is to make sure that all such questions will be preseeded. Samuel
Easier installer?
Hi, At $DAYJOB I'm currently supporting a piece of software for which I provide binary packages for a number of distributions. As part of that, I find myself having to install a Fedora or CentOS VM occasionally. I can't help but notice that their current installer is extremely easy to use; and that, as compared to ours, it seems like a huge step forwards: - First screen of the installer allows to select a language - Second screen has three sections: "Localisation" (which has a button for selecting the keyboard layout, one for language support allowing to select additional languages, and one for time/date settings), "Software" (with a button for the installation source and their equivalent of tasksel), and "System" (which has a button for their partitioner and one for the network configuration) - The partitioner defaults to "automatic partitioning", but you have to enter it and confirm it by selecting the proper hard disk (presumably so you can't accidentally overwrite your data) - Once you make the correct settings in that screen, you click on "Start installation". The next screen will cause the actual installation to start (i.e., the installer will partition & format hard disks, start downloading packages, and install them). It also has two buttons for user settings (you can enter a root password and/or create a non-root user). ... and that's it. I think that their installer is much easier to use for inexperienced users than is ours, and that we should take a good look at what they've done and see if we can make improvements to ours so that it would support a similar experience. That doesn't have to mean we need to completely rewrite our installer; e.g., we could write a udeb which asks the user as many questions as possible without moving on, and then uses preseeding to preset settings for the current udebs. Such an installer wouldn't support *every* use case, but that's fine; since, in essence, we'd just be providing an alternate UI to the same installer, people who need some of the more advanced options can ditch the hand-holding UI and switch to the advanced UI. We could add a button "skip this screen" to make that easier, if needs be. Thoughts? -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Scheduling 9.3
On 2017-11-15 18:30, Steve McIntyre wrote: On Wed, Oct 25, 2017 at 05:00:16PM +0100, Adam Barratt wrote: On 2017-09-24 17:38, Jonathan Wiltshire wrote: Hi, Our target for 9.3 and 8.10 is the first weekend in December (this happily makes the following target the beginning of February, avoiding the festive season). Accordingly I'm looking at one of: [...] 2nd December 9th December (but preferably earlier, or we start gradually extending the cycle) Those both look ok to me. Did we make a decision yet? Both still look OK for me, but my tester helpers are asking! I believe we still need ftp-master and press confirmation, but I've been failing at poking. *poke* Regards, Adam
