From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6514907984160620544 X-Received: by 10.223.153.16 with SMTP id x16mr1404067wrb.24.1516905413587; Thu, 25 Jan 2018 10:36:53 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.193.79 with SMTP id r76ls2147759wmf.3.gmail; Thu, 25 Jan 2018 10:36:52 -0800 (PST) X-Google-Smtp-Source: AH8x224ztX/p5YWb07QPYHyo4Ii6qGTZ5Z4ozjIXU4y0p53POkhctPfDSyFSjAK3BLrpmDzJO/hA X-Received: by 10.28.196.66 with SMTP id u63mr1383168wmf.0.1516905412962; Thu, 25 Jan 2018 10:36:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516905412; cv=none; d=google.com; s=arc-20160816; b=PJJGioaDV6XyEomuPO+BsKJlL1sTFrcssL/zNrO4mviqEa9dGOyr5eRFGlsIVW6VzU 4nChuQgwDhkrHGy6gSWKt83gwEX4fNmifsQCcsX0jRvZGyYoT8o3k1ePWZzTsxv/ajH/ 327kmjQjBTlucFnzbsbVEDLC4hO6ACzzTaoveyLPh7IEgQHf9BHPo9OfmJ8OLIsZkSXG P4Guv9OpBI6sqJ4PtHx+c3/cvaTotECMm9SavVHEAZw3pzxRdJtqPx10jvuRed3cLZBb RIB0LFw9Syue6SEXSHYKpRB6qXfJsyay5FIfqMHbqQ3rtviDBSuf2xifPitH1DKP36RG xw6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:cc:references:to:subject :arc-authentication-results; bh=xeIajnm5OyvJ9b/oIzASf2HFbxRLjJIywGdQ++IU4R8=; b=E/8jFML6ajI+qlALe1iXvwT5eqhomEdgwOFYCTuLEKRBHTdUCkZrCzP0rWgbOOBBUb Mb2yaxkW2IIZ4humvqB10203UZ1qukWKgtI10aRZZ0blFi91wQq3xYR8D3U7eaP8HCyJ zkvfZPLmK9P/t3LKqX/wMf0FpUustYS/SnX7HlB4X7HsmGThYii9rglx5e/e/SEtmxXB /FKHGwhKQEe4L7JhyXR9eGqCNJKhGYE4mBW+fkKejNSnoCtS3dYJfYbgKYWMK3LwgDL8 GEJBVaHxea9vKCnYXsFb/iJMV01v9pU8Ib7KlArZTsojbHzcFEEB/jedR355FsxlSdbv PURA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id s81si197066wmd.2.2018.01.25.10.36.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 10:36:52 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w0PIapkB022412 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jan 2018 19:36:51 +0100 Received: from md1f2u6c.ww002.siemens.net (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id w0PIanTY020131; Thu, 25 Jan 2018 19:36:49 +0100 Subject: Re: Custom kernel build - best way to generate a package To: Benedikt Niedermayr References: <5e24fe4d-7592-45b4-daa4-690d6fc6823e@siemens.com> <2f42f0f6-335b-257a-e1ba-a07b9252594c@siemens.com> <5a6c68c4-6062-21f7-f80c-0721c21bb8b8@googlemail.com> Cc: isar-users From: Jan Kiszka Message-ID: Date: Thu, 25 Jan 2018 19:36:47 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <5a6c68c4-6062-21f7-f80c-0721c21bb8b8@googlemail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: VNkKrbprKyLh [re-adding the list] On 2018-01-25 19:24, Benedikt Niedermayr wrote: > Am 25.01.2018 um 13:56 schrieb Jan Kiszka: >> On 2018-01-25 09:50, [ext] Jan Kiszka wrote: >>> Hi all, >>> >>> as indicated before, I'm looking into providing a framework for isar to >>> help users with building their own kernel packages from un-debianized >>> kernel sources. I'm now scratching my head how to do that best. Options >>> I'Ve found so far: >>> >>> 1. make bindeb-pkg (from upstream kernel) >>> >>>     Downside: currently requires patches to feed in missing runtime >>>     dependencies of the generated package. Also, it seems this is not >>>     designed to create full replacements of the standard debian kernel >>>     packages. Might be an uphill battle on the long run. >>> >>> 2. Provide debian/ folder in isar so that dpkg_runbuild works >>> >>>     Question is here where to pick up the debian/ folder from. The >>>     original debian kernel package? The version that Frank once >>> create as >>>     demo [1] (BTW, how was it created?)? >>> >>> 3. make-kpkg >>> >>>     Still unclear to me what pros and cons are here. >> Just played with it, and it also generates packages that are not meant >> to be replacements of the standard debian kernel - incomplete deps. At >> least under jessie. >> >> Jan >> >>> Any comments / suggestions would be highly appreciated! >>> >>> Thanks, >>> Jan >>> >>> [1] >>> https://github.com/ilbers/linux/commit/b7ab449238b8e59943849a10c95d578aa01d70e7 >>> >>> > Hi, > > >> 2. Provide debian/ folder in isar so that dpkg_runbuild works > This would be my favorite one. Using a debian/ folder seems to be the > most generic solution. > > Because then we are able to use a generic class which creates debian > packages in general for any kind of software package. > > The  "make-kpkg" solution might work very good for the kernel itself.... > but only for the kernel. That represents a disadvantage for me. Well, this case is about the kernel itself, only. The control files needed to build the kernel are not reusable for other tasks. > > Are there any proposals or ideas for generic "debianization" of software > packages yet? I think when it comes to that point, we will realize that > the most generic way of creating > > debian packages will take precedence, since it comes with a generic > workflow. > > Otherwise we will have different solutions for different types of > software packages. > > > What I have implemented for know, was a generic debianization with: > > 1. Generate the debian control file (fill with dependencies to other > packages, built with Isar ) > > 2. Generate the debian "rules" makefile > > 3. Run dh_make > > 4. Run dpkg-buildpackage > > It's a generic workflow and can be applied to any software package. It > can also be turned off, if a software package already contains the > required files within its debian folder. > > > I will try to create patch series based on upstream Isar. For know its > "only" a working solution within my Isar fork. > But did you check dpkg-raw in upstream? It's not full debianization, but at least packaging of pre-existing files with some degree of customization. One should also be able to combine it with build steps prior to running the packaging, though purists say that this is better handled with real debian control files. Of course, whenever we can generalize common tasks, just parameterizing their details, that could be offered as class for reuse. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux