Bug#787298: (no subject)
Chef is already doing this where the bento boxes are provisionerless and the vagrant-omnibus plugin installs the version of Chef to your liking. This! Definitely the way to go. Is there anything required of the box for that solution to work, or is all you need apt-get? On Tue, Jun 2, 2015 at 12:33 AM Chris Fordham ch...@fordham-nagy.id.au wrote: On 02/06/2015 7:12 AM, Emmanuel Kasper emman...@libera.cc wrote: The other point is that including (either) provisioner takes us further from the standard Debian image. BTW, Was is actually a standard Debian image ? To the best of my knowledge, I would define it as all the packages with Priority: required and important. According to the Debian Jessie installation guide [1], the *standard* task is also recommended. In server/containers environments it makes sense to restrict the list of packages installed. However the main aim of the Vagrant Virtualbox base boxes,are shareable development environments. In this kind of setup, I would expect the usual comfort of the debian experience, having for instance a mail server to send stuff, bash-completion or patch installed, all packages with come with the standard priority. So I am in favor of installing this task, which will bring aptitude as a side effect. Concerning the inclusion/removal of providers via specific boxes, why not. [1] https://www.debian.org/releases/jessie/i386/apbs04.html.en Section: Package selection Base boxes should be both provisionerless as well as stock as possible. Vagrant plugins should be used to look after installing provisioners such as your an ansible, puppet etc. Chef is already doing this where the bento boxes are provisionerless and the vagrant-omnibus plugin installs the version of Chef to your liking. -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/556cc9f9.9020...@libera.cc
Bug#787298: (no subject)
On Tue, Jun 2, 2015 at 8:19 AM Anders Ingemann and...@ingemann.de wrote: Chef is already doing this where the bento boxes are provisionerless and the vagrant-omnibus plugin installs the version of Chef to your liking. This! Definitely the way to go. Is there anything required of the box for that solution to work, or is all you need apt-get? On Tue, Jun 2, 2015 at 12:33 AM Chris Fordham ch...@fordham-nagy.id.au wrote: On 02/06/2015 7:12 AM, Emmanuel Kasper emman...@libera.cc wrote: The other point is that including (either) provisioner takes us further from the standard Debian image. BTW, Was is actually a standard Debian image ? To the best of my knowledge, I would define it as all the packages with Priority: required and important. According to the Debian Jessie installation guide [1], the *standard* task is also recommended. In server/containers environments it makes sense to restrict the list of packages installed. However the main aim of the Vagrant Virtualbox base boxes,are shareable development environments. In this kind of setup, I would expect the usual comfort of the debian experience, having for instance a mail server to send stuff, bash-completion or patch installed, all packages with come with the standard priority. So I am in favor of installing this task, which will bring aptitude as a side effect. Concerning the inclusion/removal of providers via specific boxes, why not. [1] https://www.debian.org/releases/jessie/i386/apbs04.html.en Section: Package selection Base boxes should be both provisionerless as well as stock as possible. Vagrant plugins should be used to look after installing provisioners such as your an ansible, puppet etc. Chef is already doing this where the bento boxes are provisionerless and the vagrant-omnibus plugin installs the version of Chef to your liking. -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/556cc9f9.9020...@libera.cc I apologize for top posting btw. Still getting used to the new google inbox :-)
Bug#787301: cloud.debian.org: Vagrant base box does not follow passwordless sudo recommendations
Interesting. How/when was the image generated? The vagrant plugin for bootstrap-vz uses (ALL): https://github.com/andsens/bootstrap-vz/blob/c94e172ea19f9e44314272deb3137d74253c9411/bootstrapvz/plugins/vagrant/tasks.py#L70 On Sun, May 31, 2015 at 9:06 AM Martey Dodoo bugs.debian@marteydodoo.com wrote: Package: cloud.debian.org Severity: important In Vagrant's base box recommendations at https://docs.vagrantup.com/v2/boxes/base.html, they recommend using the following configuration for password-less sudo: vagrant ALL=(ALL) NOPASSWD: ALL However, the current Vagrant base boxes for Debian use: vagrant ALL=NOPASSWD:ALL This has the side effect of making commands that use sudo with a different user account (e.g. `sudo -u postgres psql`) ask for a password, which can cause certain provisioning commands to fail. -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150531070205.15475.46983.reportbug@highcastle
Bug#787298: (no subject)
I think we are in need of some kind of policy here. The idea of those images is that you can download them and they are ready-to-use (which means pre-installing software). This is in direct conflict with Debian branded images, because we want them to be as close to the standard distribution as possible. Vagrant supports multiple config management tools - should we split the images up so that there are flavours (including vanilla - nothing pre-installed)? The maintenance effort would of course be multiplied because of that. I don't really have a preference either way, but this is not the first time this challenge has arisen and we might be in need of some general guidelines. On Sun, May 31, 2015 at 11:30 AM Marcin Kulisz deb...@kulisz.net wrote: I think that I won't agree that vagrant default box should include those packages. Simple explanations are: 1. it will take us further from standard Debian img 2. Ansible is not the only config mgmt soft which is used and to include at least the most popular will bloat base box very significantly (puppet, chef, salt, cfengine and more) So, I'd say keeping those away from base image and allowing users to install them in their own images is better idea then enforcing one over others or installing all and having bloated base box. -- |_|0|_| | |_|_|0| Heghlu'Meh QaQ jajVam | |0|0|0| kuLa - | gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3
Bug#785457: cloud.debian.org: AMI don't need getty
On 18 May 2015 at 15:43, Ognyan Kulev ogn...@ognyankulev.com wrote: I'm a little confused, we should already be doing that for AWS images: https://github.com/andsens/bootstrap-vz/blob/f3be3e4543a37ef1af7b2b5193a8bb7b590d1b79/bootstrapvz/common/tasks/boot.py#L31 systemd does not use the /etc/inittab file. I am aware. Hence this file: https://github.com/andsens/bootstrap-vz/blob/f3be3e4543a37ef1af7b2b5193a8bb7b590d1b79/bootstrapvz/common/assets/systemd/logind.conf It is copied into the system when jessie or above is bootstrapped.
Bug#785457: cloud.debian.org: AMI don't need getty
but the reality is that getty processes exist in the official Jessie HVM AMI Ooh! And I know why :-) The HVM AMIs are generated from James Brombergers fork, which most likely does not have those adjustments. OK, the issue here is then that James and I need to get together and figure out this merge (which is rather big, hence the delay).
Bug#785457: (no subject)
On 18 May 2015 at 11:08, Marcin Kulisz deb...@kulisz.net wrote: I suppose it make sens on AWS to ditch getty process only issue I see with this it's taking us a bit further (like diverge more) from the 'default Debian image' and this may cause some issues. -- |_|0|_| | |_|_|0| Heghlu'Meh QaQ jajVam | |0|0|0| kuLa - | gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 I'm a little confused, we should already be doing that for AWS images: https://github.com/andsens/bootstrap-vz/blob/f3be3e4543a37ef1af7b2b5193a8bb7b590d1b79/bootstrapvz/common/tasks/boot.py#L31
Bug#746394: Please consider shipping pre-built images in Debian packages
On 29 July 2014 15:30, Olivier Berger olivier.ber...@telecom-sudparis.eu wrote: Hi. Charles Plessy ple...@debian.org writes: One reason why bootstrap-vz exists is that broader frameworks such as Debian-Installer have more constraints and are harder to learn and maintain. In particular, Debian-Installer does not run as a simple command that prepares a tarball on a user's hard drive; it is a minimal Debian system that runs by itself. But I think that attempts to build larger frameworks than bootstrap-vz will end up re-inventing an installer for Debian. So for a Grand Unification I recommend to work on Debian-Installer directly. With respect to docker (in the context of #746394), I think that the providing of images should be much lighter than what the Debian installer usually does. AFAIU, docker containers are meant to be very lightweight, compared to installing on real hardware, and whereas it would be sad to reinvent the wheels the d-i is already providing, I think that much of its work is to detect hardware and configure appropriately, which is completely useless in the context of docker, since there's no hardware emulation, no real virtual machine, just a chroot-like container (LXC based), at least in the usual use of docker containers based on LXC running over Linux. So bootstrap-vz running debootstrap is probably much of what we need for a bootstrap-vz Docker provider, I guess (and the devil which is in the details). Hope this makes sense. Best regards, -- Olivier BERGER olivier.ber...@it-sudparis.eu - OpenPGP: 5819D7E8 Ingénieur Recherche - Dept INF - TMSP (http://www.it-sudparis.eu) -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tt4z412@olivierberger.com So bootstrap-vz running debootstrap is probably much of what we need for a bootstrap-vz Docker provider, I guess (and the devil which is in the details). I agree. Also a note about lightweightness, using --variant=minbase in a little bootstrap-vz test scenario I was to get the base install down to 98MB (this includes networking and all the basics). It would be interesting to see if people know some tricks on how to get that number down even further. Anders
Bug#746394: Please consider shipping pre-built images in Debian packages
On 1 May 2014 00:59, Chris Fordham ch...@fordham-nagy.id.au wrote: Personally, I'd prefer that we use packer instead of bootstrap-vz ( https://github.com/andsens/bootstrap-vz) to build official Debian images of which should be published on http://cdimage.debian.org or the more appropriate file server for users to download. On Thu, May 1, 2014 at 4:21 AM, Miguel Landaeta nomad...@debian.orgwrote: On Tue, Apr 29, 2014 at 09:59:49PM +0200, Jan Wagner wrote: Did you have a look into /usr/share/docker.io/contrib/mkimage-debootstrap.sh? You can generate your own image via debootstrap. And what debian-cloud team? (CCing them) I don't know if that it's outside of the tasks of the team (what do you think guys?) but it would be nice if you can provide properly maintained and signed images? I'm a member of that team (I'm almost inactive although) but maybe we can contribute with that. For example, I have a very simple image in my web page[1] generated with debootstrap and signed with my key since is the only one I trust so far to play around with docker. 1. http://people.debian.org/~nomadium/docker/images/ -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 Faith means not wanting to know what is true. -- Nietzsche Could you elaborate on *why* you prefer packer? What are the advantages over bootstrap-vz? As I see it right now, I'd like to ask the question whether you could send packer via email or whether it would fit on a floppy (if you catch my drifthttps://www.youtube.com/watch?v=SricpmKQd3U ). Anders
Bug#743892: please include security.debian.org in sources.list
On 8 April 2014 02:48, Jonathan Landis j...@calibersecurity.com wrote: Package: cloud.debian.org The heartbleed bug has created a situation in which servers must be upgraded immediately. At the moment the default mirrors listed in the Debian Wheezy AMI image don't have the patches yet, but security.debian.orgdoes. So users of the existing image have to update sources.list on each of their servers if they want to get patched ASAP. Is there any reason not to include security.debian.org in sources.list by default? -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53434779.2010...@calibersecurity.com Is there any reason not to include security.debian.org in sources.list by default? Not really. There is a hanging PR at https://github.com/andsens/bootstrap-vz/pull/33 It's hanging because I never got an answer to my question: What's the difference between: http://security.debian.org/ wheezy/updates ... and http://http.debian.net/ wheezy-updates ... ? I am pretty sure only the first one should be there, but I can't for the life of me figure out why wheezy-updates was added. Is it a bogus source? The source is herehttps://github.com/andsens/bootstrap-vz/blob/399dfa3fa0bc792fb1b8adc633a9e5fefe3b05d7/bootstrapvz/common/tasks/apt.py#L31 .
Bug#743892: please include security.debian.org in sources.list
On 8 April 2014 09:28, Charles Plessy ple...@debian.org wrote: Le Tue, Apr 08, 2014 at 09:02:12AM +0200, Anders Ingemann a écrit : It's hanging because I never got an answer to my question: What's the difference between: http://security.debian.org/ wheezy/updates ... and http://http.debian.net/ wheezy-updates ... ? Sorry for this... Short answer: they are different, and the ressemblance is only coincidental. Each lines indicate an URL and a distribution. http://http.debian.net/ is a mirror of the Debian archive. The wheezy-updates distribution is there to together with wheezy, wheezy-backports, jessie, sid, etc. It contains the packages that will be part of the next point update. This inlcudes security updates, but not immediately after their release. http:/security.debian.org/ is not a section of the Debian archive, it is an archive on its own. If I remember correctly, the rationale for using a separate archive is that for a quick diffusion of security updates, it was better to avoid the lag caused by the mirroring of the regular archive. For wheezy, the distribution to pick is wheezy/updates. Both lines are really needed. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan Aha! Thanks for the detailed explanation Charles. I'll merge this tonight and put it in the master branch. Have a nice day I will ;-)
Bug#743892: please include security.debian.org in sources.list
Already merged about an hour ago ;-) Anders On 8 April 2014 16:57, Bromberger, James jame...@amazon.com wrote: I’ve pushed a patch to bootstrap-vz that should fix this; pending review and merge req pull by Anders. James James Bromberger *|* Solution Architect | Amazon Web Services *E: *jame...@amazon.com* P:* +61 422 166 708 *T:*@JamesBromberger *From:* Jimmy Kaplowitz [mailto:jkaplow...@google.com] *Sent:* Tuesday, 8 April 2014 5:22 PM *To:* Anders Ingemann; 743...@bugs.debian.org *Cc:* Jonathan Landis *Subject:* Bug#743892: please include security.debian.org in sources.list The http.debian.net source is presumably the wheezy version of this: http://www.debian.org/News/2011/20110215 - Jimmy On Tue, Apr 8, 2014 at 12:02 AM, Anders Ingemann and...@ingemann.de wrote: On 8 April 2014 02:48, Jonathan Landis j...@calibersecurity.com wrote: Package: cloud.debian.org The heartbleed bug has created a situation in which servers must be upgraded immediately. At the moment the default mirrors listed in the Debian Wheezy AMI image don't have the patches yet, but security.debian.org does. So users of the existing image have to update sources.list on each of their servers if they want to get patched ASAP. Is there any reason not to include security.debian.org in sources.list by default? -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53434779.2010...@calibersecurity.com Is there any reason not to include security.debian.org in sources.list by default? Not really. There is a hanging PR at https://github.com/andsens/bootstrap-vz/pull/33 It's hanging because I never got an answer to my question: What's the difference between: http://security.debian.org/ wheezy/updates ... and http://http.debian.net/ wheezy-updates ... ? I am pretty sure only the first one should be there, but I can't for the life of me figure out why wheezy-updates was added. Is it a bogus source? The source is herehttps://github.com/andsens/bootstrap-vz/blob/399dfa3fa0bc792fb1b8adc633a9e5fefe3b05d7/bootstrapvz/common/tasks/apt.py#L31 .
Bug#696805: Suggested fix to blank hostname bug
On 29 January 2014 02:38, Jimmy Kaplowitz jkaplow...@google.com wrote: Set the hostname to localhost in build-debian-cloud. The standard set_hostname logic in /sbin/dhclient-script will override this just fine, but it should fix the log clutter. - Jimmy Good idea. I already do it for the vagrant plugin: https://github.com/andsens/build-debian-cloud/blob/WIP-python/plugins/vagrant/tasks.py#L51 It should probably just be refactored so that you can set it under system in the manifest.
Bug#697490: Fixed
A helpful finn fixed it: https://github.com/andsens/ec2debian-build-ami/commit/6fd56203c7f0b2df18ce4fc247a2c0d9a8ee5b6b Anders
Bug#697490: cloud: 697490: use sudoers.d
You are right, sudoers.d should be used, this would also fix the problem with wheezy, where my sed command does not work, because the layout of the file has changed. Anders On 6 January 2013 10:16, Charles Plessy ple...@debian.org wrote: forwarded 697490 https://github.com/andsens/ec2debian-build-ami/issues/43 quit Le Sun, Jan 06, 2013 at 07:58:25PM +1100, Chris Fordham a écrit : Did you test that with setting DEBIAN_FRONTEND=noninteractive first ? No, I am running the upgrade interactively, and I would like to be able to answer relevant questions if any. Therefore, if it is possible to have good defaults that remove the need for some of the existing questions, it will leave more time and focus for the remaining ones. I have forwarded my suggestion on GitHub's page for ec2debian-build-ami. Let's see Anders' response. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130106091622.gc13...@falafel.plessy.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697490: cloud: 697490: use sudoers.d
On 6 January 2013 18:48, Thomas Goirand z...@debian.org wrote: On 01/07/2013 12:00 AM, Ian Campbell wrote: On Sun, 2013-01-06 at 17:53 +0900, Charles Plessy wrote: The only other interruption is the following debconf question from libc6: Restart services during package upgrades without asking? I wonder if it would make sense to preseed it ? This question isn't specific to the cloud images or the use of ec2debian-build-ami, is it? IIRC you get asked the same thing with a native system install with d-i or debootstrap created chroots. If there is an issue with the priority of this question then that seems like something which should be raised with the libc6 package maintainer, not overridden/workedaround by downstream tools. Ian. I don't think it goes against the Debian policy to preseed stuff if we believe it's adapted to the use case. That's what blends are all about. I see these AMI images as a matching case. Though this is not a strong opinion that I have, I do understand your view. Thomas -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e9b8d1.2020...@debian.org It's a simple fix really: https://github.com/andsens/ec2debian-build-ami/blob/master/plugins/admin-user-tasks/create-user#L8 I will gladly accept a pull request to the master branch on github, provided the stuff has been thoroughly tested. Otherwise you can send it to the development branch. But I haven't read the whole thread. There seems to be something going on with libc6, does that belong in this thread? Anders -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697490: cloud: 697490: use sudoers.d
On 6 January 2013 22:55, Chris Fordham chris.ford...@rightscale.com wrote: This is a good example of why template-based configuration is better used rather than regex/stream based editing. well. d'uh! :-P I did not know about sudoers.d when I wrote it, otherwise I can assure you that we wouldn't be talking about this to begin with ;-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696803: cloud.debian.org: Please set a default locale.
On 27 December 2012 12:08, Charles Plessy ple...@debian.org wrote: Package: cloud.debian.org Severity: normal Dear James and Anders, Our official images are configured with the en_US.UTF-8 locale generated, but on the other hand there is no default. As a consequence, when I log in by SSH, the locale of my remote computer is used, and since it is not English, it triggers problems such as error messages and crashes (tracd). Since en_US.UTF-8 is already on the system, maybe the most straightforward way is to make it the default ? (I heard about C.UTF-8 on #522776, but it does not seem to be available in /etc/locale.gen). Have a nice day, -- Charles Plessy Illkirch-Graffenstaden, France -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121227110802.gb12...@falafel.plessy.net I was not aware that I did not set the default. I guess my terminal transmits the one I generate, so I never encountered the error. How do I do that? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696805: cloud.debian.org: startpar: service(s) returned failure: hostname.sh ... failed!
On 27 December 2012 12:26, Charles Plessy ple...@debian.org wrote: Package: cloud.debian.org Severity: normal Hi all, there is one failed error message in the boot messages of our official instances ran on the AWS. startpar: service(s) returned failure: hostname.sh ... failed! I am not sure if it has practical consequences... -- Charles -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121227112640.gc12...@falafel.plessy.net I know, I know :-) : https://github.com/andsens/ec2debian-build-ami/issues/21 It annoys me so much, but I can't do anything about it unfortunately, it's a bug in the script, a workaround would become quite awkward. I am not sure whether it is fixed in wheezy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696154: cloud.debian.org: Please install 'less' by default on official Debian AMIs.
On 27 December 2012 11:28, Charles Plessy ple...@debian.org wrote: Le Tue, Dec 18, 2012 at 03:14:02PM +0100, Stefano Zacchiroli a écrit : On Mon, Dec 17, 2012 at 02:11:52PM -0800, Clint Byrum wrote: How is it a slippery slope if it is driven by data? Seriously, figure out a way to ask users what they want. popcon isn't going to be all that useful here becuase of the wild diversity of systems that exist in popcon. But you can certainly just ask users to list any optional packages that they'd like to see on images. Or have a subset of popcon just for cloud images. Data is always good to have so, sure, let's find out ways to do that. But I urge to figure out how to gather data that distinguish the wishes that are cloud-specific wrt the others. For everything that is not cloud specific, I think we should strive to make the corresponding improvements where they belong, i.e. in Debian default installation choices. And I'm sure there is room for improvements there, because there is always room for improvement :-) Here, I think we should be mostly concerned for cloud-specific needs and, sure enough, we should add them to the pre-built images we offer. Hi all, I think that the Debian defaults should be based on common practice. In that sense, I think that we should first work out a package list that suits our needs, and only after, if we can demonstrate that it is of general interest, propose that it may be reflected on Debian's standards. It would be tempting to use package priorities, with important representing the bare minimum discussed earlier, and standard representing the images that are ready to use for some simple tasks. However, this would mean downgrading the priority of exim4 and raising the priority of openssh. I do not volunteer to lead this discussion... I think that this rules out bothering debian-b...@lists.debian.org until we have a good record of providing images that are used broadly, except perhaps to propose a new tasksel task (or more if relevant). We therefore need a good definition of what is minimal, in terms of packages and in terms of image size. For instance, on the Amazon cloud, the size of instances is defined in gigabytes, and our images are currently configured to use 8 Gb volumes by default. For the cloud-specific part, the defintion of what is minimal also needs some arguments, that can for instance justify why we ship systems with ssh by default and not other packages, as it is equally easy to install them with user metadata. Lastly, there are packages like less, or psmisc (/usr/bin/killall), that have a neglectable footprint in terms of cost and security. I understand the argument of slippery slope, but if we consider the 8 Gb images discussed above, there is enough space to install some of them. If we all agree that the contents of the images is not set on stone (that is, we can remove less when it proves to be deleterious to some users), why not satisfying our current users (including myself), instead of focusing on the leanest solution, that I think is likely to attract less users. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121227102816.ga12...@falafel.plessy.net Up until this instance the counter arguments had me swayed, but you do make some good points. I am currently writing my master thesis, so I do not have the time to participate in any discussions right now, I will follow the discussions though and happily implement whatever you guys decide :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696154: cloud.debian.org: Please install 'less' by default on official Debian AMIs.
Most certainly, I have a standard-packages plugin which is supposed to install the packages one would expect to see in a base install. This plugin also installs less. I think I should remove vim and emacs from it though. You can see the list here: https://github.com/andsens/ec2debian-build-ami/blob/master/plugins/standard-packages-tasks/add-standard-packages I also have a ticket on github for this: https://github.com/andsens/ec2debian-build-ami/issues/19 I'm not sure where the discussion for standard packages should be continued, should we just keep it in bugs.debian? Anders On 17 December 2012 12:34, Charles Plessy ple...@debian.org wrote: Package: cloud.debian.org Severity: wishlist Hi James and Anders, the less package is lighter than 200 kB and does not pull extra packages when installed. Would it be possible to have it by default in the official Debian AMIs ? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121217113420.15602.5570.reportbug@chouca.igloo
