Re: root (/) partion too small by automatic partition during boot? (Re: root-fs too small [was: Re: Debian Installer Jessie Beta 2 release]
On Fri, 2017-03-31 at 15:44 +0900, ishikawa wrote: > Hi, > > Recently I have hit into the issue of automatic partition done during the > installation of Debian jessie > creating too small root (/) partition, and tried to find out where to report > this and found the following post which is quoted below. [...] I don't know whether we should change this for jessie now, but if 'multi' recipes still set the maximum size of / to 10G then it should be increased for stretch. Ben. -- Ben Hutchings To err is human; to really foul things up requires a computer. signature.asc Description: This is a digitally signed message part
root (/) partion too small by automatic partition during boot? (Re: root-fs too small [was: Re: Debian Installer Jessie Beta 2 release]
Hi, Recently I have hit into the issue of automatic partition done during the installation of Debian jessie creating too small root (/) partition, and tried to find out where to report this and found the following post which is quoted below. Sorry I am not sure how to quote a post to debian-boot mail archive, which I found at https://lists.debian.org/debian-boot/2014/10/msg00115.html. The subject was "root-fs too small [was: Re: Debian Installer Jessie Beta 2 release]". So I simply copy and paste the web page below. > > * /To/: debian-boot@lists.debian.org <mailto:debian-boot%40lists.debian.org> > * /Subject/: root-fs too small [was: Re: Debian Installer Jessie Beta 2 > release] > * /From/: Noël Köthe mailto:noel%40debian.org>> > * /Date/: Mon, 06 Oct 2014 10:53:30 +0200 > * /Message-id/: <1412585610.2093.4.ca...@debian.org > <https://lists.debian.org/debian-boot/2014/10/msg00115.html>> > * /In-reply-to/: <20141005191124.gb8...@mraw.org > <https://lists.debian.org/debian-boot/2014/10/msg00095.html>> > * /References/: <20141005191124.gb8...@mraw.org > <https://lists.debian.org/debian-boot/2014/10/msg00095.html>> > > > Hello, > > Am Sonntag, den 05.10.2014, 21:11 +0200 schrieb Cyril Brulebois: > > > Feedback for this release > > = > > > > We need your help to find bugs and further improve the installer, so > > please try it. Installer CDs, other media and everything else you will > > need are available at our web site[3]. > > I still can confirm #740330 "root-fs should be larger". You will only > run into this problem when you autopartition and later you get a kernel > update (e.g. 3.16-1 > 3.16-2 or coming kernel security updates). > If / is too small a jessie+1 will run into this problem, too. > > Please raise the size. Thank you.:) > > -- > Noël Köthe > Debian GNU/Linux, www.debian.org > > *Attachment: signature.asc > <https://lists.debian.org/debian-boot/2014/10/pgpLDkSppej9z.pgp>* > /Description:/ This is a digitally signed message part > > Does the recent netinstaller for jessie I downloaded last weekend contain the fix for above? I doubt it because I just hit the too small root partition issue after I was upgrading and doing some installation stuff on a new installation. I think in today's bloated kernel (and other related stuff) world, we should set aside 20G for root (/) [maybe much more. I found the suggestion for 32GB which may be a tad too large, but...] at the minimum during automatic partition. We probably should warn the user if the installer finds the root partition too small. I would rather live with smaller /home partition and larger /root partition. There was enough space in /home to make /root bigger in my case. I got bitten with this issue three times on different machines in the past three years and so decided to the manual partition for a fresh install based on my experience, but I was in a hurry this time and tried netinstall with automatic partition and hit into this problem again. The machine is in limbo because I cannot even remove packages. (I tried setting TMP, TMPDIR, etc. to point to a non-root partition, but to no avail.) I will try re-installing this weekend, but I wanted to report the issue to debian bug system. Where should I report this? Since the installation of Debian GNU/Linux system is NOT in usable state [the partition filled up and many commands refused to run.], I cannot send the bug report from THAT machine. Thank you in advance for your attention. Chiaki Ishikawa
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi Bas, On Thu, Oct 16, 2014 at 08:27:37PM +0200, Bas Wijnen wrote: > Ok. Is it supposed to be possible to install more than one blend > simultaneously? Is that technically prevented with Conflicts? Not at all. I have not tested but I would bet that you can install all existing metapackages of all Blends at the same time. Conflicts do not make any sense to the contrary it makes sense to install say med-bio and science-typesetting at the same time (just to say a random example). > > ... as always with documentation. :-) The same applies to me to some > > extend (and I'm not proud about this). > > No, I'm not proud of it either. But as Feynman said: "you [yourself] > are the easiest person to fool." So I take some pride in admitting it; > telling myself otherwise would have been easier. ;-) :-) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016203751.gd30...@an3as.eu
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hello, On Thu, Oct 16, 2014 at 08:47:19AM +0200, Andreas Tille wrote: > > Would this use case also be a reason for creating a personal blend? Or > > even an official one? > > Jonas has answered this question. I'd like to add that I'm no fan of > "personal" things since you spoil the idea of forming a team around the > idea. Yes, I agree. However, sometimes the needs are so specific that it doesn't make sense to do them on a larger scale. I'd make the packages public, but I wouldn't suggest that a blend for very limited use deserves a prominent position in the installer. But as Jonas pointed out, if the blend only does the setup for running a single application and any application can be chosen at install time, that increases the audience to a point where it may deserve that position. I'll consider if I want to drive that effort. I'd really like to see this happen, but I'm also trying to limit new projects I start, so that I have enough time to handle the things I do properly. If more people (besides Jonas) are interested, please let me know privately. If you want to be the driver, definitely let me know, too. :-) I'll send a status update by the end of the month. > Well, these are good questions. They are abit hard to answer in a > situation when we are discussing about how to properly install the > currently existing Blends. Indeed. Someone should remember to bring them back up once that question has been answered (and the answer has been implemented). > > So it installs a package which changes configuration of other packages > > when it is installed? That sounds very ugly... Isn't there a better > > way to preconfigure a system? > > Yes. The better way is to convince the single package maintainers. The > longish discussion is in bug #311188. Reading that raises questions regarding the configuration editing tool I wrote about some time ago. I'll follow up to that thread (on -devel only). > > Oh, and I have another question; this seems very similar to "tasks"; how > > is it different? > > Each Blend creates metapackages and a -tasks package to feed > tasksel. Yes, we are using this term actively. The difference is more > in the content that the tasks are specific for fields of interest but > the used technique is the same (which is intentional to enable > integration into the installer easily). Ok. Is it supposed to be possible to install more than one blend simultaneously? Is that technically prevented with Conflicts? > > > Enhancements / patches(source is in package source of blends source > > > package) are always welcome. > > > > I might write a patch, but knowing myself I probably don't get around to > > actually do that. > > ... as always with documentation. :-) The same applies to me to some > extend (and I'm not proud about this). No, I'm not proud of it either. But as Feynman said: "you [yourself] are the easiest person to fool." So I take some pride in admitting it; telling myself otherwise would have been easier. ;-) Thanks, Bas signature.asc Description: Digital signature
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Quoting Andreas Tille (2014-10-16 08:47:19) > On Wed, Oct 15, 2014 at 07:49:32PM +0200, Bas Wijnen wrote: >> On occasion, I've needed a single-use system; something that boots up >> into an application and that shuts down when that application exits. >> (Having the full power of Debian in the background is a nice feature, >> but mostly unused.) For example, for dancing rehearsal I want the >> instructors to be able to switch their computer on and have the sound >> program start up without any interaction. It isn't hard to set this >> up, but if I want to tell other dancing instructors how to do this, >> it requires more steps than I would like. I've tried making custom >> live CDs, with a special package that does these things. >> >> Would this use case also be a reason for creating a personal blend? >> Or even an official one? > > Jonas has answered this question. I'd like to add that I'm no fan of > "personal" things since you spoil the idea of forming a team around > the idea. I could perfectly imagine such a Blend and every specific > application is a separate "task" (in the Blends slang). So you can > assemble those people with the goal to run one dedicated application. And I fully agree with Andreas: I assumed you were talking about "Debian Blends" as defined at https://wiki.debian.org/DebianPureBlends#Terminology and that you therefore really a generally reusable Blend (sparked by personal _needs_ which I see as a perfectly fine drive for creating a Debian Blend). I am sorry if I twisted your meaning. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi Bas, On Wed, Oct 15, 2014 at 07:49:32PM +0200, Bas Wijnen wrote: > > > For the moment the way to install Blends is to use the plain Debian > > installer and afterwards install a bunch of metapackages. > > Ah, and that's what you want to change now. That sounds like a very > good idea. :-) > > The lack of a missing installer for all other Blends is a frequently > > criticised problem and I personally think this should be fixed by the > > integration into the official boot cds since this fits to the nature > > of Blends which are a subset of Debian. > > Yes, I agree. For the documentation, I think the main thing that is > missing is "how to start and stop"; important for every documentation. > "Stopping" isn't really relevant in this case (but it doesn't hurt to > mention that the metapackage can be uninstalled). But "To use a Blend, > you need to install its metapackage" would have clarified it for me. > Once it is possible, it would be very nice if "there is an option to do > this during system install" could be added to that. I'll put this on my todo list for 2014-11-05+x. > On occasion, I've needed a single-use system; something that boots up > into an application and that shuts down when that application exits. > (Having the full power of Debian in the background is a nice feature, > but mostly unused.) For example, for dancing rehearsal I want the > instructors to be able to switch their computer on and have the sound > program start up without any interaction. It isn't hard to set this up, > but if I want to tell other dancing instructors how to do this, it > requires more steps than I would like. I've tried making custom live > CDs, with a special package that does these things. > > Would this use case also be a reason for creating a personal blend? Or > even an official one? Jonas has answered this question. I'd like to add that I'm no fan of "personal" things since you spoil the idea of forming a team around the idea. I could perfectly imagine such a Blend and every specific application is a separate "task" (in the Blends slang). So you can assemble those people with the goal to run one dedicated application. > What would be the easiest way for people to > install a non-official blend? Should I create my own installer? Should > the installer be changed to allow entering a URL (for an external apt > source) before it presents the list of available blends? (I think this > might be a good idea, but it shouldn't be in there by default; only when > the user selects "back" on the blend selection menu. Or perhaps there > can be a button in that menu for opening the dialog, but if it's for > adding any apt repository, the blends dialog is not the right place for > it.) Well, these are good questions. They are abit hard to answer in a situation when we are discussing about how to properly install the currently existing Blends. > > There might be additional apt sources but it is not only about apt > > sources. For instance (as far as I'm informed) all packages in Debian > > Edu are inside Debian and there was just a need to change some > > configuration change of some *other* packages which conflicts with > > Debian policy (I'm pretty sure Jonas will respond in detail to this mail > > - so I save my time here B-)). > > So it installs a package which changes configuration of other packages > when it is installed? That sounds very ugly... Isn't there a better > way to preconfigure a system? Yes. The better way is to convince the single package maintainers. The longish discussion is in bug #311188. > > H. I had thought / hoped that this is documented in[5]. > > It is, but I think it's too much text and too far away. It's good that > it's there, but I think it would be good to have on the first page > people are pointed to (which one is that anyway? The one in the wiki?) > a one-line explanation that is understandable. The definition of "Pure > Blend" on https://wiki.debian.org/DebianPureBlends is "a subset of > Debian that is configured to support a particular target group > out-of-the-box." That does not give me enough information to know if I > should be interested enough to read any further. Also todo list for 2014-11-05+x. > Oh, and I have another question; this seems very similar to "tasks"; how > is it different? Each Blend creates metapackages and a -tasks package to feed tasksel. Yes, we are using this term actively. The difference is more in the content that the tasks are specific for fields of interest but the used technique is the same (which is intentional to enable integration into the installer easily). > > Enhancements / patches(source is in package source of blends source > > package) are always welcome. > > I might write a patch, but knowing myself I probably don't get around to > actually do that. ... as always with documentation. :-) The same applies to me to some extend (and I'm not proud about this). > > Do you think I should
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Quoting Bas Wijnen (2014-10-15 19:49:32) > On occasion, I've needed a single-use system; something that boots up > into an application and that shuts down when that application exits. > (Having the full power of Debian in the background is a nice feature, > but mostly unused.) For example, for dancing rehearsal I want the > instructors to be able to switch their computer on and have the sound > program start up without any interaction. It isn't hard to set this > up, but if I want to tell other dancing instructors how to do this, it > requires more steps than I would like. I've tried making custom live > CDs, with a special package that does these things. > > Would this use case also be a reason for creating a personal blend? > Or even an official one? What would be the easiest way for people to > install a non-official blend? Should I create my own installer? > Should the installer be changed to allow entering a URL (for an > external apt source) before it presents the list of available blends? > (I think this might be a good idea, but it shouldn't be in there by > default; only when the user selects "back" on the blend selection > menu. Or perhaps there can be a button in that menu for opening the > dialog, but if it's for adding any apt repository, the blends dialog > is not the right place for it.) That sounds like an excellent idea for a Blend! You raise a bunch of questions on how that idea should be implemented and work out in details - but that has is open for you as driver of a Blend to figure out. If you do decide to start create above as a Blend, and would be interested in collaborating (with me), please do count me in! I have fumbled with a few ideas in the past that seems to fit perfectly to above (e.g. a dead-simple videophone "PhoneHome" dialing a hardcoded number, or a party jukebox with a touch keyboard (no avoid spilling liquids into a real keyboard, or a gaming box to pacify visiting kids, or...). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi, On Wed, Oct 15, 2014 at 09:31:36AM +0200, Andreas Tille wrote: > You belong to a majority if I might conclude from my experience. I have > no idea whether I should feel responsible for this but I'm fighting on > several fronts like the extensive documentation[1] and countless > talks[2] as well as trying to push newcomers into the topic by > sponsering their packages[3]. Yes, I noticed. Thanks for all that work! > For the moment the way to install Blends is to use the plain Debian > installer and afterwards install a bunch of metapackages. Ah, and that's what you want to change now. That sounds like a very good idea. > The lack of a missing installer for all other Blends is a frequently > criticised problem and I personally think this should be fixed by the > integration into the official boot cds since this fits to the nature > of Blends which are a subset of Debian. Yes, I agree. For the documentation, I think the main thing that is missing is "how to start and stop"; important for every documentation. "Stopping" isn't really relevant in this case (but it doesn't hurt to mention that the metapackage can be uninstalled). But "To use a Blend, you need to install its metapackage" would have clarified it for me. Once it is possible, it would be very nice if "there is an option to do this during system install" could be added to that. > - Blends are a way to advertise Debian in specific fields of interest > I personally started from a point where I wanted to reach a status, > that if somebody wonders what distribution to use for biology and > medical care the natural answer should be "Use Debian" We could > easily reach this goal for other fields of interest if all our > dedicated experts we had in Debian would work on this direction in > their own field. On occasion, I've needed a single-use system; something that boots up into an application and that shuts down when that application exits. (Having the full power of Debian in the background is a nice feature, but mostly unused.) For example, for dancing rehearsal I want the instructors to be able to switch their computer on and have the sound program start up without any interaction. It isn't hard to set this up, but if I want to tell other dancing instructors how to do this, it requires more steps than I would like. I've tried making custom live CDs, with a special package that does these things. Would this use case also be a reason for creating a personal blend? Or even an official one? What would be the easiest way for people to install a non-official blend? Should I create my own installer? Should the installer be changed to allow entering a URL (for an external apt source) before it presents the list of available blends? (I think this might be a good idea, but it shouldn't be in there by default; only when the user selects "back" on the blend selection menu. Or perhaps there can be a button in that menu for opening the dialog, but if it's for adding any apt repository, the blends dialog is not the right place for it.) > There might be additional apt sources but it is not only about apt > sources. For instance (as far as I'm informed) all packages in Debian > Edu are inside Debian and there was just a need to change some > configuration change of some *other* packages which conflicts with > Debian policy (I'm pretty sure Jonas will respond in detail to this mail > - so I save my time here B-)). So it installs a package which changes configuration of other packages when it is installed? That sounds very ugly... Isn't there a better way to preconfigure a system? > I hope I added some more points to this summary. Yes, thank you. > > Examples of the target audience would be useful. > > H. I had thought / hoped that this is documented in[5]. It is, but I think it's too much text and too far away. It's good that it's there, but I think it would be good to have on the first page people are pointed to (which one is that anyway? The one in the wiki?) a one-line explanation that is understandable. The definition of "Pure Blend" on https://wiki.debian.org/DebianPureBlends is "a subset of Debian that is configured to support a particular target group out-of-the-box." That does not give me enough information to know if I should be interested enough to read any further. Oh, and I have another question; this seems very similar to "tasks"; how is it different? > Enhancements / patches(source is in package source of blends source > package) are always welcome. I might write a patch, but knowing myself I probably don't get around to actually do that. > > I admit I didn't spend a lot of > > time trying to find answers to these questions, but I think it shouldn't > > require a large time investment. > > Do you think I should add these answers to the Wiki page with the > relevant links? Yes, that would be good. But it should be as short as possible; less text is better. However, currently it is
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi Holger, On Wed, Oct 15, 2014 at 10:25:20AM +0200, Holger Levsen wrote: > Hi, > > On Dienstag, 14. Oktober 2014, Andreas Tille wrote: > > While this "no" means: There exist 1 or 2 Blends focussing on a > > specific desktop environment (as far as I know Debian Edu and Ezgo) but > > Debian Edu offers you the documented choices between KDE Plasma (default), > Gnome, Mate, Xfce4, LXDE and Sugar. (And for jessie+1 hopefully Cinnamon > too.) > And as the documentation also says you can apt-get install anything else you > wish from Debian too. > > So no, Debian Edu doesnt focus on a specific desktop anymore. A few years ago > KDE was *the* choice, but iirc that was until ~2009 or 10. Thanks for the clarification. In this case I'd answer the question from Bas > Do all blends work well with all desktop environments? rather with "yes". I'll send this to the other lists where the question came up to. At some point we should stop cross-posting to several lists, but since the topic about the installer is relevant for debian-boot as well I'm not sure whether it is good to leave this out. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141015091629.gk16...@an3as.eu
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi, On Tue, Oct 14, 2014 at 08:29:47PM +0200, Jonas Smedegaard wrote: > > Well, Blends and "the desktop situation" could be considered > orthogonal. > > > > Do all blends work well with all desktop environments? > > No. While this "no" means: There exist 1 or 2 Blends focussing on a specific desktop environment (as far as I know Debian Edu and Ezgo) but others work perfectly well under all desktop environments. So the answer is mathematical correct but a bit short to understand the full picture. Kind regards Andreas. PS: I'll answer Bas' question tomorrow in more detail but I'm to tired today. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-blends-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014215750.ga4...@an3as.eu -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014215750.ga4...@an3as.eu
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi Bas, On Tue, Oct 14, 2014 at 07:19:36PM +0200, Bas Wijnen wrote: > On Tue, Oct 14, 2014 at 11:20:02AM +0200, Andreas Tille wrote: > > I admit I expected *you* to know about Blends for a while - but > > considering the video recorded quote I think I was not wrong using this > > chance to point this out for other readers of this mail as it is really > > a fact that I always meet DDs who mix up this concept with derivatives. > > I have heard about them for quite a while, indeed, but I must say that I > never entirely understood what they are. I'm guessing I'm not alone in > this. You belong to a majority if I might conclude from my experience. I have no idea whether I should feel responsible for this but I'm fighting on several fronts like the extensive documentation[1] and countless talks[2] as well as trying to push newcomers into the topic by sponsering their packages[3]. > So let me write what I think they are, and then you can correct > me. I've read the explanation on the wiki, but I'm still not sure if I > understand it right. > > I think a blend is a system you can install, which after installing is a > regular Debian system, set up for a particular task. Because it's a > regualr Debian system, after installation packages can be installed and > removed just like on any other Debian system, and any other system can > be turned into a blend by installing the right packages. For the moment the way to install Blends is to use the plain Debian installer and afterwards install a bunch of metapackages. There is one exception Debian Edu / Skolelinux which uses dedicated installation medias with pre-feeded debconf data. There is a long standing discussion whether Debian Edu deserves the term "pure" but I will not dive into this can of worms since I do not want to spoil the general picture here with details caused by a single bug (Debian Edu people will know it by heart). The lack of a missing installer for all other Blends is a frequently criticised problem and I personally think this should be fixed by the integration into the official boot cds since this fits to the nature of Blends which are a subset of Debian. I'd like to add some informal ideas about Blends to perhaps give a better picture of the idea: - Several people entertain deriving from Debian and actually the never ending misconception about Blends is that they are derivatives. But Blends are derivatives "done the right way" - by not deriving Debian and rather do the adaptations inside Debian. The goal is to save time and prevent reinventing the wheel on the (non)derivers side and to bundle forces right into Debian. - Blends are a way to advertise Debian in specific fields of interest I personally started from a point where I wanted to reach a status, that if somebody wonders what distribution to use for biology and medical care the natural answer should be "Use Debian" We could easily reach this goal for other fields of interest if all our dedicated experts we had in Debian would work on this direction in their own field. - Blends is also about forming teams inside Debian to care for a certain topic to serve as glue between upstream and the end user and if you have watched[4] (as advised in my last mail) you not only get an idea about how we form teams but about the Blends concept in general. > From the wiki, it seems that is just the "Pure Blend", because other > Blends may have extra apt sources. There might be additional apt sources but it is not only about apt sources. For instance (as far as I'm informed) all packages in Debian Edu are inside Debian and there was just a need to change some configuration change of some *other* packages which conflicts with Debian policy (I'm pretty sure Jonas will respond in detail to this mail - so I save my time here B-)). The whole pure / non-pure discussion is from my personal point of view a consequence of nitpicking about policy compliance which was born out of the problem that some package maintainers are not willing to accept some more flexible debconf configuration options. I agree that policy is something to be really picky about and will not argue against this but on the other hand it spoils a bit the simplicy to understand the whole concept. So a "Debian Pure Blend" (I use the shortcut "Blend" as a synonym) is fully integrated into Debian while "non-pure" Blends are trying to approach the full Debian integration but some minor pieces like a hand full of packages or some policy conflicting stuff remain on their todo list. > Is this a good summary? I hope I added some more points to this summary. > If so, I think it would be a very good idea to make this part of the > installer. And turn the default system into "just another blend". Sounds like a nice view on the Blends concept. :-) > Regardless of whether my summary is good, I think the documentation can > use some improvement. +1 That's always nee
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Quoting Bas Wijnen (2014-10-14 19:19:36) > I have heard about [Blends] for quite a while, indeed, but I must say > that I never entirely understood what they are. I'm guessing I'm not > alone in this. So let me write what I think they are, and then you > can correct me. I've read the explanation on the wiki, but I'm still > not sure if I understand it right. [snip] This is the canonical definition: https://wiki.debian.org/DebianPureBlends#Terminology If that's the text you found confusing, please do help by elaborating what was confusing about it. Well, Blends and "the desktop situation" could be considered orthogonal. > > Do all blends work well with all desktop environments? No. > I can see how some blends would focus to make things work perfectly > with one of them only. In such a case, it makes sense to omit the > desktop selection after such a blend is selected, or at least let the > blend define the default. Good point! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
On Tue, Oct 14, 2014 at 11:20:02AM +0200, Andreas Tille wrote: > I admit I expected *you* to know about Blends for a while - but > considering the video recorded quote I think I was not wrong using this > chance to point this out for other readers of this mail as it is really > a fact that I always meet DDs who mix up this concept with derivatives. I have heard about them for quite a while, indeed, but I must say that I never entirely understood what they are. I'm guessing I'm not alone in this. So let me write what I think they are, and then you can correct me. I've read the explanation on the wiki, but I'm still not sure if I understand it right. I think a blend is a system you can install, which after installing is a regular Debian system, set up for a particular task. Because it's a regualr Debian system, after installation packages can be installed and removed just like on any other Debian system, and any other system can be turned into a blend by installing the right packages. From the wiki, it seems that is just the "Pure Blend", because other Blends may have extra apt sources. Is this a good summary? If so, I think it would be a very good idea to make this part of the installer. And turn the default system into "just another blend". Regardless of whether my summary is good, I think the documentation can use some improvement. Examples of the target audience would be useful. What is made possible or easier with blends? What is often confused with it, but isn't actually related? I admit I didn't spend a lot of time trying to find answers to these questions, but I think it shouldn't require a large time investment. > > > Well, Blends and "the desktop situation" could be considered orthogonal. Do all blends work well with all desktop environments? I can see how some blends would focus to make things work perfectly with one of them only. In such a case, it makes sense to omit the desktop selection after such a blend is selected, or at least let the blend define the default. Thanks, Bas signature.asc Description: Digital signature
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi Cyril, On Tue, Oct 14, 2014 at 10:14:53AM +0200, Cyril Brulebois wrote: > > > > In other words: I perfectly know the fact that Blends are widely > > ignored even amongst Debian developers and that's not about you / the > > debian-boot team - perhaps my "running around and tell people" is just > > not the right way to convince people. At least I can tell that those > > people who were listening started to like the idea [see 1]. > > to clarify a bit: my surprise was about blends support in tasksel/d-i. > I've known about blends for a while but I don't think that topic popped > up in my debian-boot radar during the whole Jessie release cycle. I admit I expected *you* to know about Blends for a while - but considering the video recorded quote I think I was not wrong using this chance to point this out for other readers of this mail as it is really a fact that I always meet DDs who mix up this concept with derivatives. > > Well, Blends and "the desktop situation" could be considered orthogonal. > > The main goal of a Blend is not primarily to tweak the desktop (even if > > this could be done). It is rather about the applications. In Debian > > Med we even have a cluster task which contains exclusively those > > packages which can be run without a graphical desktop (bio-cloud [2]). > > I meant the needed changes in tasksel to support both desktop selection > and blends. OK. > > ... > > earlier, yes. The reason why at least I stayed away from this since > > 2003 (#186085) was that I have seen little chances to change the > > refusal. However, since recently some Blends of some more general > > interest like Debian Games and Debian GIS started or gained some > > traktion resp. the idea came up to rise this question on IRC in the > > DebConf talk. > > Blends… support in d-i (during this release cycle) was what I meant, > sorry for being unclear. Hopefully that was covered by the above > clarification. ;) Yes it was. :-) However, I also had taken the chance to refer to an earlier bug (perhaps also to review its old arguments). > > I perfectly agree that you as the one person army keeping Debian Boot > > alive (hey, do you like the Blends born idea to prove this point[4]??) > > should not spend extra time cycles into the implementation. > > That really isn't true, there are many other developers, reporters, and > patch providers. I'm only adding glue or oil where needed… Of course we > could do with more hands (look at the BTS), but I'm far for being the > only one working on d-i. I agree that my term was a bit in terms of a compliment in the sense of a "friendly lie". I was not trying to underestimate the work of those people who are providing smaller contributions. However, you really find lots of graphs similar like[4] which show the feature of one dominant person at a certain time. Perhaps you take this as: Thanks for the effort you spent obviously for debian-boot. > > That's in fact a quite motivating incentive and I perfectly agree that > > we really should start rather yesterday than today. The thing is that > > it is not really clear to me, what we should do rather than adding the > > packages > > > >edu-tasks > >games-tasks > >gis-tasks > >junior-tasks > >med-tasks > >science-tasks > >debichem-tasks > >ezgo-tasks > > > > (multimedia-tasks is not ready according to their maintainer[5]) to the > > boot disks. > > > > Joey Hess as tasksel maintainer mentioned "limited amount of space in > > tasksel for blends" but this does not give a sensible hint of what exact > > action we should do now. I think currently eight additional lines is > > not that much. I also totally contradict to Joey's statement "The > > 'Debian Pure Blends' effort has been around for several releases and > > been publicised." and I take [1] as sufficient argument that it is not > > the case. Blends were never ever regarded in practice as some Debian > > internal thing and *every* time when I talk about Blends on conferences > > and in private discussions I will be asked: "Why don't you do this cool > > stuff right into Debian instead of a derivative?" It would *really* > > help in this kind of discussion to point to the Debian installer ... > > > > So if we would get some helping hand what exactly technically needs to > > be done, we could try to come up with some solution. > > I'm not sure we have 8 slots at the moment. I'm pretty sure a scrollbar > (if at all feasible) in a multi-choice menu would be a bad idea. I agree here. However, I think it would be a shame to drop a good idea (and as far as I understood the responses to the bug it is considered good by several people) since we failed to find a sensible menu design. > Maybe we'd need a separate prompt for blends. I perfectly agree that some additional menu level would be the most natural way in my eyes. I think I mentioned this before. Hmmm, just wondering why I can't find this term in the previous bugrepor
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi again Andreas, Andreas Tille (2014-10-14): > On Tue, Oct 14, 2014 at 06:02:11AM +0200, Cyril Brulebois wrote: > > well to be honest the whole blend story came as a surprise. > > Ahhh, this in turn is surprising for me since the first "version" of > this bug is dated 24 Mar 2003 (#186085) :-). But I agree that Blends > are not widely known even if I was proactively running around since > more than ten years telling people > "Is there a topic in Debian you care about? Create a Blend today!" > as Asheesh advised me in last years DebConf talk[1 - just see the > linked subtitles text to save time - it is *very* speaking for the > whole topic!] > > In other words: I perfectly know the fact that Blends are widely > ignored even amongst Debian developers and that's not about you / the > debian-boot team - perhaps my "running around and tell people" is just > not the right way to convince people. At least I can tell that those > people who were listening started to like the idea [see 1]. to clarify a bit: my surprise was about blends support in tasksel/d-i. I've known about blends for a while but I don't think that topic popped up in my debian-boot radar during the whole Jessie release cycle. > > I think we identified quite early in the release cycle that we would > > need to finally do something about the desktop situation (which first > > landed in D-I Jessie Beta 2). > > Well, Blends and "the desktop situation" could be considered orthogonal. > The main goal of a Blend is not primarily to tweak the desktop (even if > this could be done). It is rather about the applications. In Debian > Med we even have a cluster task which contains exclusively those > packages which can be run without a graphical desktop (bio-cloud [2]). I meant the needed changes in tasksel to support both desktop selection and blends. > > Blends were first mentioned during a DC'14 talk in late August. > > To be precise: Blends (formerly Custom Debian Distributions - yes, I'm > *not* responsible for this broken name :-() was mentioned on *any* > DebConf I joined with exception of DebConf 0 where this idea was not yet > born. If you scroll down my talks page[3] you stumble upon DebConf 1 in > Bordeaux 2001 as first time presenting the idea on a DebConf. Any of my > talks raised the question, whether there is a menu in the installer to > a) get an easy installation method and b) propagate the Blends concept > (which is obviously needed). It might have been the fault of people who > care about Blends that they did not approached the Debian Boot team > earlier, yes. The reason why at least I stayed away from this since > 2003 (#186085) was that I have seen little chances to change the > refusal. However, since recently some Blends of some more general > interest like Debian Games and Debian GIS started or gained some > traktion resp. the idea came up to rise this question on IRC in the > DebConf talk. Blends… support in d-i (during this release cycle) was what I meant, sorry for being unclear. Hopefully that was covered by the above clarification. ;) > > At the moment my personal feeling about this is that it looks a bit > > late, and I'm almost certainly not going to drive such changes > > myself. > > I perfectly agree that you as the one person army keeping Debian Boot > alive (hey, do you like the Blends born idea to prove this point[4]??) > should not spend extra time cycles into the implementation. That really isn't true, there are many other developers, reporters, and patch providers. I'm only adding glue or oil where needed… Of course we could do with more hands (look at the BTS), but I'm far for being the only one working on d-i. > > I don't have any strong incentive to prevent other people from > > working on this though. (Of course, any work should happen sooner > > than later.) > > That's in fact a quite motivating incentive and I perfectly agree that > we really should start rather yesterday than today. The thing is that > it is not really clear to me, what we should do rather than adding the > packages > >edu-tasks >games-tasks >gis-tasks >junior-tasks >med-tasks >science-tasks >debichem-tasks >ezgo-tasks > > (multimedia-tasks is not ready according to their maintainer[5]) to the > boot disks. > > Joey Hess as tasksel maintainer mentioned "limited amount of space in > tasksel for blends" but this does not give a sensible hint of what exact > action we should do now. I think currently eight additional lines is > not that much. I also totally contradict to Joey's statement "The > 'Debian Pure Blends' effort has been around for several releases and > been publicised." and I take [1] as sufficient argument that it is not > the case. Blends were never ever regarded in practice as some Debian > internal thing and *every* time when I talk about Blends on conferences > and in private discussions I will be asked: "Why don't you do this cool > stuff right into Debian instea
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi Cyril, On Tue, Oct 14, 2014 at 06:02:11AM +0200, Cyril Brulebois wrote: > Hi Andreas, > > Andreas Tille (2014-10-08): > > On Sun, Oct 05, 2014 at 09:11:24PM +0200, Cyril Brulebois wrote: > > > The Debian Installer team[1] is pleased to announce the second beta > > > release of the installer for Debian 8 "Jessie". > > > ... > > > > thanks for your report and your continuous work on the installer. > > > > I wonder what might be the opinion of the installer team about bug > > #758116 which contains the suggestion to add Blends to the tasks > > selection menu and whether we could do something to help with the > > implementation. The bug report received a lot of agreement from people > > working in different Blends but only one question[1] of Joey Hess > > probably wearing his tasksel maintainer hat. For me it is not clear > > whether this is an issue of deciding what Blend to include (Joey's > > question was targeting into this direction) or whether you hesitate to > > implement this at all. Since it is not clear whether you think this > > kind of menu is sensible or not we did not yet mindet providing patches > > or so to support your work. Some kind of statement could be motivating > > to provide more work on the technical side. > > > > Kind regards and thanks again for your work on the installer > > > > Andreas. > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#140 > > well to be honest the whole blend story came as a surprise. Ahhh, this in turn is surprising for me since the first "version" of this bug is dated 24 Mar 2003 (#186085) :-). But I agree that Blends are not widely known even if I was proactively running around since more than ten years telling people "Is there a topic in Debian you care about? Create a Blend today!" as Asheesh advised me in last years DebConf talk[1 - just see the linked subtitles text to save time - it is *very* speaking for the whole topic!] In other words: I perfectly know the fact that Blends are widely ignored even amongst Debian developers and that's not about you / the debian-boot team - perhaps my "running around and tell people" is just not the right way to convince people. At least I can tell that those people who were listening started to like the idea [see 1]. > I think we identified quite early in the release cycle that we would > need to finally do something about the desktop situation (which first > landed in D-I Jessie Beta 2). Well, Blends and "the desktop situation" could be considered orthogonal. The main goal of a Blend is not primarily to tweak the desktop (even if this could be done). It is rather about the applications. In Debian Med we even have a cluster task which contains exclusively those packages which can be run without a graphical desktop (bio-cloud [2]). > Blends were first mentioned during a DC'14 talk in late August. To be precise: Blends (formerly Custom Debian Distributions - yes, I'm *not* responsible for this broken name :-() was mentioned on *any* DebConf I joined with exception of DebConf 0 where this idea was not yet born. If you scroll down my talks page[3] you stumble upon DebConf 1 in Bordeaux 2001 as first time presenting the idea on a DebConf. Any of my talks raised the question, whether there is a menu in the installer to a) get an easy installation method and b) propagate the Blends concept (which is obviously needed). It might have been the fault of people who care about Blends that they did not approached the Debian Boot team earlier, yes. The reason why at least I stayed away from this since 2003 (#186085) was that I have seen little chances to change the refusal. However, since recently some Blends of some more general interest like Debian Games and Debian GIS started or gained some traktion resp. the idea came up to rise this question on IRC in the DebConf talk. > At the > moment my personal feeling about this is that it looks a bit late, and > I'm almost certainly not going to drive such changes myself. I perfectly agree that you as the one person army keeping Debian Boot alive (hey, do you like the Blends born idea to prove this point[4]??) should not spend extra time cycles into the implementation. > I don't > have any strong incentive to prevent other people from working on this > though. (Of course, any work should happen sooner than later.) That's in fact a quite motivating incentive and I perfectly agree that we really should start rather yesterday than today. The thing is that it is not really clear to me, what we should do rather than adding the packages edu-tasks games-tasks gis-tasks junior-tasks med-tasks science-tasks debichem-tasks ezgo-tasks (multimedia-tasks is not ready according to their maintainer[5]) to the boot disks. Joey Hess as tasksel maintainer mentioned "limited amount of space in tasksel for blends" but this does not give a sensible hint of what exact action we should do now. I think currently eight addi
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi Andreas, Andreas Tille (2014-10-08): > On Sun, Oct 05, 2014 at 09:11:24PM +0200, Cyril Brulebois wrote: > > The Debian Installer team[1] is pleased to announce the second beta > > release of the installer for Debian 8 "Jessie". > > ... > > thanks for your report and your continuous work on the installer. > > I wonder what might be the opinion of the installer team about bug > #758116 which contains the suggestion to add Blends to the tasks > selection menu and whether we could do something to help with the > implementation. The bug report received a lot of agreement from people > working in different Blends but only one question[1] of Joey Hess > probably wearing his tasksel maintainer hat. For me it is not clear > whether this is an issue of deciding what Blend to include (Joey's > question was targeting into this direction) or whether you hesitate to > implement this at all. Since it is not clear whether you think this > kind of menu is sensible or not we did not yet mindet providing patches > or so to support your work. Some kind of statement could be motivating > to provide more work on the technical side. > > Kind regards and thanks again for your work on the installer > > Andreas. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#140 well to be honest the whole blend story came as a surprise. I think we identified quite early in the release cycle that we would need to finally do something about the desktop situation (which first landed in D-I Jessie Beta 2). Blends were first mentioned during a DC'14 talk in late August. At the moment my personal feeling about this is that it looks a bit late, and I'm almost certainly not going to drive such changes myself. I don't have any strong incentive to prevent other people from working on this though. (Of course, any work should happen sooner than later.) Of course, if blends support ends up not being merged for Jessie, I'm very sorry for people having participated in the discussion and their false hope. :( Mraw, KiBi. signature.asc Description: Digital signature
Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi Cyril, On Sun, Oct 05, 2014 at 09:11:24PM +0200, Cyril Brulebois wrote: > The Debian Installer team[1] is pleased to announce the second beta > release of the installer for Debian 8 "Jessie". > ... thanks for your report and your continuous work on the installer. I wonder what might be the opinion of the installer team about bug #758116 which contains the suggestion to add Blends to the tasks selection menu and whether we could do something to help with the implementation. The bug report received a lot of agreement from people working in different Blends but only one question[1] of Joey Hess probably wearing his tasksel maintainer hat. For me it is not clear whether this is an issue of deciding what Blend to include (Joey's question was targeting into this direction) or whether you hesitate to implement this at all. Since it is not clear whether you think this kind of menu is sensible or not we did not yet mindet providing patches or so to support your work. Some kind of statement could be motivating to provide more work on the technical side. Kind regards and thanks again for your work on the installer Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#140 -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141008094524.gc13...@an3as.eu
Re: Debian Installer Jessie Beta 2 release
Steven Chamberlain (2014-10-07): > There should have been several DEs listed in that menu to choose from; > seems okay to me, or is that choice only shown for Expert-mode installs? Please send follow-ups to #764277? Mraw, KiBi. signature.asc Description: Digital signature
Re: Debian Installer Jessie Beta 2 release
Hi! On 16:06, Baptiste Jammet wrote: > Testing debian-jessie-DI-b2-kfreebsd-amd64-netinst.iso under qemu, > if I only choose > « Graphical desktop environment », d-i don't install any DE, [...] There should have been several DEs listed in that menu to choose from; seems okay to me, or is that choice only shown for Expert-mode installs? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006234418.gf25...@squeeze.pyro.eu.org
Re: Debian Installer Jessie Beta 2 release
Hi, Baptiste Jammet (2014-10-06): > Testing debian-jessie-DI-b2-kfreebsd-amd64-netinst.iso under qemu, > if I only choose > « Graphical desktop environment », d-i don't install any DE, just > something like desktop-base. It seems that I have to choose > explicitly (Xfce in my specific case). > > I've seen default_desktop_for_arch() in > http://sources.debian.net/src/tasksel/3.28/default_desktop/ > but I don't know if it's used. (If not, you successfully get rid of > « default desktop » difficulty !) > Do I need to mention this in #764026, or it's not a desired feature ? please file a full installation report, including syslog: https://www.debian.org/releases/stable/amd64/ch05s04.html.en#problem-report We'll see. Mraw, KiBi. signature.asc Description: Digital signature
Re: Debian Installer Jessie Beta 2 release
Hi, Le 05/10/2014 21:11, Cyril Brulebois a écrit : Important changes in this release of the installer == [...] * A list of desktop environments is displayed in tasksel, making it easy to install another desktop environment (or several of them). Unfortunately that is currently a bit underdocumented (#764026). Testing debian-jessie-DI-b2-kfreebsd-amd64-netinst.iso under qemu, if I only choose « Graphical desktop environment », d-i don't install any DE, just something like desktop-base. It seems that I have to choose explicitly (Xfce in my specific case). I've seen default_desktop_for_arch() in http://sources.debian.net/src/tasksel/3.28/default_desktop/ but I don't know if it's used. (If not, you successfully get rid of « default desktop » difficulty !) Do I need to mention this in #764026, or it's not a desired feature ? Note that I didn't try linux kernel to compare, and it could be kfreebsd-specific. Baptiste -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2549dc84503c55b18ca015950351a...@mailoo.org
root-fs too small [was: Re: Debian Installer Jessie Beta 2 release]
Hello, Am Sonntag, den 05.10.2014, 21:11 +0200 schrieb Cyril Brulebois: > Feedback for this release > = > > We need your help to find bugs and further improve the installer, so > please try it. Installer CDs, other media and everything else you will > need are available at our web site[3]. I still can confirm #740330 "root-fs should be larger". You will only run into this problem when you autopartition and later you get a kernel update (e.g. 3.16-1 > 3.16-2 or coming kernel security updates). If / is too small a jessie+1 will run into this problem, too. Please raise the size. Thank you.:) -- Noël Köthe Debian GNU/Linux, www.debian.org signature.asc Description: This is a digitally signed message part
Debian Installer Jessie Beta 2 release
The Debian Installer team[1] is pleased to announce the second beta release of the installer for Debian 8 "Jessie". Important changes in this release of the installer == * Gnome is now the default desktop environment on Linux again. * A list of desktop environments is displayed in tasksel, making it easy to install another desktop environment (or several of them). Unfortunately that is currently a bit underdocumented (#764026). * Preliminary support for the arm64 and ppc64el architectures has been added. Other changes in this release of the installer == * brltty: Append the configuration inherited from d-i to the end of brltty.conf instead of overwriting it (which was thus losing the documentation for the user). * brltty: Enable accessibility in XFCE, LXDE and MATE sessions too. * busybox: Add support for /32 subnets in udhcpc script (#652573). * choose-mirror: Strip off any scheme part found at the start of mirror/*/hostname (#706191). * console-setup: Correct default keymap for South Korea (#756052). * console-setup: Use nepali keymap for Nepali and Tharu by default. * debian-installer: - Fix the PXE boot images built for kfreebsd, hurd (#759686). - Add fonts-lohit-guru-udeb to gtk images, fixing rendering for Punjabi (#761573). - Remove desktop selection from syslinux; now available in tasksel. - Keep Linux modules.builtin file in the initrd. - Fix lib location and search path for syslinux >= 5 (#756275). * fontconfig: Add conf.avail directory to the udeb, fixing broken Monospace font in graphical installer (#739011). * hw-detect: Improve driver injection disk support. * hw-detect: Move firmware installation code to pre-pkgsel.d * hw-detect: Correct detection of Macs needing to blacklist snd-aoa modules (#650588). * iso-scan: Do not error out when searching in folders with shell-special characters in their name (#640789). * lowmem: Update lowmem limits for linux-x86. * lowmem: Make the / ramfs fill the whole memory again (#759336). * netcfg: Do not kill_dhcp_client after setting the hostname and domain, otherwise Linux udhcpc will stop renewing its lease, and on other platforms dhclient will de-configure the network interface (#757711, #757988). * netcfg: Don't copy /etc/network/interfaces to /target if netcfg/target_network_config=ifupdown (#709017). * netcfg: Fix support for entering an ESSID manually, it was previously getting ignored (#757478). * preseed: Update auto-install/defaultroot for jessie. * preseed: Always disable locale & keyboard question when auto is enabled, even if no preseed file was given on boot, in case the dhcp server provides it (#759290). * rootskel: Update lowmem limit for gtk on linux-x86. * rootskel: Use a tmpfs for some directories to avoid running out of space in the fixed-size initrd on kfreebsd-* (#757985). * rootskel-gtk: Update gtk-set-font to learn a new mapping (Lohit Punjabi). Hardware support changes * libdebian-installer: arm64: Detect UEFI based systems as "efi" subarch. * libdebian-installer: Add ppc64 and ppc64el support. * linux: - Include preliminary support for arm64 and ppc64el. - udeb: Add ccm, ctr to crypto-modules (#761902). - [armhf] udeb: Add ehci-platform, ohci-platform and phy-sun4i-usb to usb-modules (#761591). - udeb: Add rsi_usb to nic-wireless-modules - udeb: Add ath6kl_sdio, libertas_cs, libertas_sdio, mwifiex_sdio, r8192u_usb, r8723au, rtl8188eu, rtl818x_pci, rtl8723be, rtl8821ae, spectrum_cs to nic-wireless-modules. - [armel/orion5x] udeb: Include mvmdio in nic-modules udeb. - udeb: Add new sound drivers to sound-modules (#756998). Known bugs in this release == * Firmware handling: udev no longer reports missing firmware (#725714), and patches for the kernel need polishing before we are able to restore support for loading missing firmware. * CD-ROM modules are missing on ppc64el, but the netboot flavour is working correctly. This will be fixed in the next release. Feedback for this release = We need your help to find bugs and further improve the installer, so please try it. Installer CDs, other media and everything else you will need are available at our web site[3]. Thanks == The Debian Installer team thanks everybody who has contributed to this release. 1. http://wiki.debian.org/DebianInstaller/Team 2. http://www.debian.org/devel/debian-installer/errata 3. http://www.debian.org/devel/debian-installer -- Cyril Brulebois on behalf of the Debian Installer Team signature.asc Description: Digital signature
