Re: debian installer images for LS-XHL/LS-CHLv2
Am 2014-04-02 18:24, schrieb Martin Michlmayr: * Michael Walle [2014-04-02 17:20]: any preferences here? i'd prefer a preseed file as long as i don't need any conditional behaviour. Could you point me to a board which already uses a preseed file? Eg. in which repository should this file be added? Take a look at e.g. debian-installer/build/config/armel/iop32x/network-console/ss4000e.cfg At the moment, all Kirkwood images are generated from one file (kirkwood/network-console.cfg), which doesn't work if you want to include different preseed files for different machines. However, I don't see a problem with adding a new .cfg file under armel/kirkwood for your device, which can then include a PRESEED directive. FYI, i've filed bugs #744714 (oldsys-preseed), #744715 (network-console) and #744716 (debian-installer). -- michael -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2d6d9760e397f5965c6a4941ee8a4...@walle.cc
Re: Dropping armel/ixp4xx
On Mon, 2014-04-14 at 12:28 +0200, G.K. wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 14/04/2014 03:02, Ben Hutchings wrote: > > The ixp4xx kernel is now too big to fit in the flash partitions: > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=armel&ver=3.14-1~exp1&stamp=1397151242 > > As fot IOP32X, why stopping support as we can install out from the flash (USB > stick is a good alternative) ? Show me the code. Ben. > > I intend to disable this flavour for the next upload of 3.14 and remove > > it for 3.15 if no-one provides a configuration fix. > > Then we only need to change flashkernel ? -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Re: Dropping armel/ixp4xx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/04/2014 03:02, Ben Hutchings wrote: > The ixp4xx kernel is now too big to fit in the flash partitions: > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=armel&ver=3.14-1~exp1&stamp=1397151242 As fot IOP32X, why stopping support as we can install out from the flash (USB stick is a good alternative) ? > I intend to disable this flavour for the next upload of 3.14 and remove > it for 3.15 if no-one provides a configuration fix. Then we only need to change flashkernel ? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534bb838.4010...@gk2.fr
Re: Dropping armel/ixp4xx
Le lundi 14 avril 2014 à 02:02 +0100, Ben Hutchings a écrit : > The ixp4xx kernel is now too big to fit in the flash partitions: > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=armel&ver=3.14-1~exp1&stamp=1397151242 > > I intend to disable this flavour for the next upload of 3.14 and remove > it for 3.15 if no-one provides a configuration fix. Would this change arch minimum requirement (-march=armv4t) ? Jérémy. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1397467217.29197.2.camel@imac.chaumes
Re: ConcurrencyKit (libck0 package) on ARM?
Hi, On Thu, Apr 10, 2014 at 03:56:41PM +0200, Daniel Pocock wrote: > Upstream says that armel can't be supported: > https://groups.google.com/d/msg/concurrencykit/I34MWr_mK8Q/sKeh1Ro3eAYJ > Should I go back to the Ganglia community and suggest moving away from > ConcurrencyKit? In case ConcurrencyKit developers are not interested in portablity, I suggest to Ganglia community to add a portable fallback in case ck is not available. > Could anybody with more ARM expertise than myself provide any more > feedback to upstream about how this package could work in Debian? Looking at ck sources briefly, ck could possibly have a backend based on gcc atomic builtins[0]. It would not be very fast, but should be guaranteed to work on debian archs. > As a compromise, we could ensure the Ganglia agent (gmond) builds > without this dependency but the data collection server (gmetad package) > would only build on i386 or amd64 I think anyone seriously interested in ganglia would be using armhf (or in future arm64), which already works with ck. So this compromise could indeed work, at least as long as ganglia upstream keeps gmond portable. Riku [0] http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html > > -- > To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/5346a319.60...@pocock.pro -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140414065949.ga32...@afflict.kos.to
