public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "'MOESSBAUER, Felix' via isar-users" <isar-users@googlegroups.com>
To: "isar-users@googlegroups.com" <isar-users@googlegroups.com>,
	"Kiszka, Jan" <jan.kiszka@siemens.com>
Subject: Re: [PATCH 2/2] debianize: warn if package maintainer is default or empty
Date: Thu, 22 Jan 2026 09:18:07 +0000	[thread overview]
Message-ID: <2f6a354bf1c859ed38213c240746dd815adf20d7.camel@siemens.com> (raw)
In-Reply-To: <dba0c001-5f37-4a6b-8dc2-16ce4546dcc6@siemens.com>

On Wed, 2026-01-21 at 19:21 +0100, Jan Kiszka wrote:
> On 21.01.26 18:40, 'Felix Moessbauer' via isar-users wrote:
> > The debian policies require that the package maintainer is filled
> > with someone that can be contacted. Checks of the SBOM of various layers
> > have shown that often the maintainer is not explicitly set, probably
> > because we provide a default.
> > 
> > As a change of the default maintainer might create a lot of downstream
> > changes, we introduce a warning instead. Later on, we can remove the
> > default and just assert that it is set.
> 
> Indeed, this is likely creating at least a lot of warning noise for
> packages that are not maintained like Debian packages because they are
> proprietary. I'm not yet sure it will be helpful to enforce other pseudo
> addresses for those.

In the past this remained mostly unnoticed, as maintainer data is not
part of the manifest file and also not relevant for the license
clearing itself (still it was wrong). This changed with in introduction
of SBOMs as now this data is used downstream and by that more care
needs to be taken.

Anyways, even the isar docs request you to put in a proper string
instead of the default.

> 
> Maybe we should define some alternative placeholder that verbosely
> documents that this packages is proprietary, and different contact
> channels apply? Would still create noise in the transition.

No. Just because we rebuild something does not mean it is proprietary.
Only the isar user can decide what value to put in there. If you really
want to have a setting as you just proposed, just set the MAINTAINER at
a higher level (e.g. by providing the default value in the local.conf).
This is already supported today.

Nonetheless, for SBOMs we have the garbage in -> garbage out situation.
That's why I prefer to start with good data instead of downstream
papering over.

Felix

> 
> Jan
> 
> > 
> > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > ---
> >  meta/classes-recipe/debianize.bbclass | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/meta/classes-recipe/debianize.bbclass b/meta/classes-recipe/debianize.bbclass
> > index a629feba..a255dd28 100644
> > --- a/meta/classes-recipe/debianize.bbclass
> > +++ b/meta/classes-recipe/debianize.bbclass
> > @@ -25,7 +25,16 @@ MAINTAINER ??= "Unknown maintainer <unknown@example.com>"
> >  
> >  DEBIANIZE_BUILD_DEPENDS ?= "debhelper-compat (= ${DEBIAN_COMPAT}), ${DEBIAN_BUILD_DEPENDS}"
> >  
> > +deb_check_maintainer() {
> > +	if [ -z "${MAINTAINER}" ]; then
> > +		bbwarn "MAINTAINER is empty. Please set a valid maintainer."
> > +	elif echo "${MAINTAINER}" | grep -q "@example.com"; then
> > +		bbwarn "MAINTAINER contains '@example.com'. Please set a valid maintainer."
> > +	fi
> > +}
> > +
> >  deb_add_changelog() {
> > +	deb_check_maintainer
> >  	changelog_v="${CHANGELOG_V}"
> >  	timestamp="${DEBIAN_CHANGELOG_TIMESTAMP}"
> >  	if [ -f ${S}/debian/changelog ]; then
> > @@ -84,6 +93,7 @@ deb_create_control[vardeps] += "DEBIANIZE_BUILD_DEPENDS \
> >                                  DEBIAN_RULES_REQUIRES_ROOT \
> >                                  DEBIAN_STANDARDS_VERSION"
> >  deb_create_control() {
> > +	deb_check_maintainer
> >  	# Add Source section
> >  	cat << EOF > ${S}/debian/control
> >  Source: ${BPN}
> 
> -- 
> Siemens AG, Foundational Technologies
> Linux Expert Center

-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/2f6a354bf1c859ed38213c240746dd815adf20d7.camel%40siemens.com.

      reply	other threads:[~2026-01-22  9:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-21 17:40 [PATCH 1/2] set valid maintainer in isar-ddi-definitions 'Felix Moessbauer' via isar-users
2026-01-21 17:40 ` [PATCH 2/2] debianize: warn if package maintainer is default or empty 'Felix Moessbauer' via isar-users
2026-01-21 18:21   ` 'Jan Kiszka' via isar-users
2026-01-22  9:18     ` 'MOESSBAUER, Felix' via isar-users [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f6a354bf1c859ed38213c240746dd815adf20d7.camel@siemens.com \
    --to=isar-users@googlegroups.com \
    --cc=felix.moessbauer@siemens.com \
    --cc=jan.kiszka@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox