Message ID | CAJGKYO6ijYqooyoKG1mgbH5ysFKbqsL0RMHpXCDkEad+gGkYAA@mail.gmail.com |
---|---|
State | Superseded, archived |
Headers | show |
Series | dpkg class sbuild allows extra arguments by vars | expand |
Again can you please send you patches in a way that they can actually be reviewed in a mail based workflow. You have conducted reviews yourself already so you should know how things should work. Am Tue, 3 Jan 2023 20:58:15 +0100 schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>: > Hi all, > > Sometimes it is necessary to add some extra commands or arguments to > sbuild but create a class into an upper layer just for this breaks > the updates. So, this patch allows setting extra parameters through > two variables. > > Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com> > --- > meta/classes/dpkg.bbclass | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > https://github.com/ilbers/isar/commit/7e72921747aedf588af492be95fb0b91ad70f455 I can not reply to that nor to a specific line in the attachment. So this can not be reviewed ... and therefore not approved. I would have comments on this one that would likely require you to send a v2. But i will just say NACK, because you deny the review again after being asked countless times to send your patches in a proper way. Henning
On Tue, 3 Jan 2023 at 21:26, Henning Schild <henning.schild@siemens.com> wrote: > > Again can you please send you patches in a way that they can actually > be reviewed in a mail based workflow. I send the patches with git-send but they went in moderation and usually remain there. Tomorrow, I will search for another open SMTP server hoping that the m-list will accept it but I am desperate to find one that suits the stringent anti-spam rules of google. > You have conducted reviews yourself already so you should know how > things should work. ...and everytime, I send a patch I always let people here remember about the problem. For compensation, I started to add this link > > > > https://github.com/ilbers/isar/commit/7e72921747aedf588af492be95fb0b91ad70f455 > Best regards, R-
Am Tue, 3 Jan 2023 22:39:55 +0100 schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>: > On Tue, 3 Jan 2023 at 21:26, Henning Schild > <henning.schild@siemens.com> wrote: > > > > Again can you please send you patches in a way that they can > > actually be reviewed in a mail based workflow. > > I send the patches with git-send but they went in moderation and > usually remain there. > Tomorrow, I will search for another open SMTP server hoping that the > m-list will accept it but I am desperate to find one that suits the > stringent anti-spam rules of google. Maybe we start with your problem here and help you use the SMTP servers from google. My guess is that you might be struggling with 2FA. And doing an internet search on how to use plain SMTP on gmail might also give you the solution. Using any other SMTP server you will likely get problems with SPF, DKIM, DMARC forcing you to send emails "From" the domain of that other server. In which case git-send-email would put a secondary "From" into the commit message so that git-am on the other side will get the real author email. But best try to use googles SMTP servers, that is for sure possible and not too hard once you found the solution. Henning > > You have conducted reviews yourself already so you should know how > > things should work. > > ...and everytime, I send a patch I always let people here remember > about the problem. > For compensation, I started to add this link > > > > > > > https://github.com/ilbers/isar/commit/7e72921747aedf588af492be95fb0b91ad70f455 > > > > > > > Best regards, R-
On Wed, 4 Jan 2023 at 08:54, Henning Schild <henning.schild@siemens.com> wrote: > > Am Tue, 3 Jan 2023 22:39:55 +0100 > schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>: > > > On Tue, 3 Jan 2023 at 21:26, Henning Schild > > <henning.schild@siemens.com> wrote: > > > > > > Again can you please send you patches in a way that they can > > > actually be reviewed in a mail based workflow. > > > > I send the patches with git-send but they went in moderation and > > usually remain there. > > Tomorrow, I will search for another open SMTP server hoping that the > > m-list will accept it but I am desperate to find one that suits the > > stringent anti-spam rules of google. > > Maybe we start with your problem here and help you use the SMTP servers > from google. My guess is that you might be struggling with 2FA. And > doing an internet search on how to use plain SMTP on gmail might also > give you the solution. > It is not possible to authenticate on SMTP with 2FA. In the past there was the option to create an app credential to send e-mail but this option has been removed. So, all the how-to like this would simply not work anymore https://blog.revathskumar.com/2019/08/git-send-patch-using-send-email-and-gmail.html > Using any other SMTP server you will likely get problems with SPF, > DKIM, DMARC forcing you to send emails "From" the domain of that other > server. In which case git-send-email would put a secondary "From" into > the commit message so that git-am on the other side will get the real > author email. In fact, Google Groups intercept such a e-mail and tag it as SPAM both in the web application (on the reader side) and in the m-list incoming rules. > > But best try to use googles SMTP servers, that is for sure possible and > not too hard once you found the solution. > Finally, I used a regular SMTP from an internet provider. However, It costs me a domain name fee. Best regards, R-
Am Thu, 5 Jan 2023 18:43:40 +0100 schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>: > On Wed, 4 Jan 2023 at 08:54, Henning Schild > <henning.schild@siemens.com> wrote: > > > > Am Tue, 3 Jan 2023 22:39:55 +0100 > > schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>: > > > > > On Tue, 3 Jan 2023 at 21:26, Henning Schild > > > <henning.schild@siemens.com> wrote: > > > > > > > > Again can you please send you patches in a way that they can > > > > actually be reviewed in a mail based workflow. > > > > > > I send the patches with git-send but they went in moderation and > > > usually remain there. > > > Tomorrow, I will search for another open SMTP server hoping that > > > the m-list will accept it but I am desperate to find one that > > > suits the stringent anti-spam rules of google. > > > > Maybe we start with your problem here and help you use the SMTP > > servers from google. My guess is that you might be struggling with > > 2FA. And doing an internet search on how to use plain SMTP on gmail > > might also give you the solution. > > > > It is not possible to authenticate on SMTP with 2FA. In the past there > was the option to create an app credential to send e-mail but this > option has been removed. So, all the how-to like this would simply not > work anymore > > https://blog.revathskumar.com/2019/08/git-send-patch-using-send-email-and-gmail.html > > > Using any other SMTP server you will likely get problems with SPF, > > DKIM, DMARC forcing you to send emails "From" the domain of that > > other server. In which case git-send-email would put a secondary > > "From" into the commit message so that git-am on the other side > > will get the real author email. > > In fact, Google Groups intercept such a e-mail and tag it as SPAM both > in the web application (on the reader side) and in the m-list incoming > rules. > > > > > But best try to use googles SMTP servers, that is for sure possible > > and not too hard once you found the solution. > > > > Finally, I used a regular SMTP from an internet provider. However, It > costs me a domain name fee. you could try msmtp and google again, if application credentials do not work anymore ... you need to dance the oauth2 dance ... Or you stay with a provider that does not enforce so much security on you that in the end you can not send mail from the campfire in the cave ;) Henning > Best regards, R-
On Thu, 5 Jan 2023 at 19:31, Henning Schild <henning.schild@siemens.com> wrote: > > Am Thu, 5 Jan 2023 18:43:40 +0100 > schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>: > > > On Wed, 4 Jan 2023 at 08:54, Henning Schild > > <henning.schild@siemens.com> wrote: > > > > > > Am Tue, 3 Jan 2023 22:39:55 +0100 > > > schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>: > > > > > > > On Tue, 3 Jan 2023 at 21:26, Henning Schild > > > > <henning.schild@siemens.com> wrote: > > > > > > > > > > Again can you please send you patches in a way that they can > > > > > actually be reviewed in a mail based workflow. > > > > > > > > I send the patches with git-send but they went in moderation and > > > > usually remain there. > > > > Tomorrow, I will search for another open SMTP server hoping that > > > > the m-list will accept it but I am desperate to find one that > > > > suits the stringent anti-spam rules of google. > > > > > > Maybe we start with your problem here and help you use the SMTP > > > servers from google. My guess is that you might be struggling with > > > 2FA. And doing an internet search on how to use plain SMTP on gmail > > > might also give you the solution. > > > > > > > It is not possible to authenticate on SMTP with 2FA. In the past there > > was the option to create an app credential to send e-mail but this > > option has been removed. So, all the how-to like this would simply not > > work anymore > > > > https://blog.revathskumar.com/2019/08/git-send-patch-using-send-email-and-gmail.html > > > > > Using any other SMTP server you will likely get problems with SPF, > > > DKIM, DMARC forcing you to send emails "From" the domain of that > > > other server. In which case git-send-email would put a secondary > > > "From" into the commit message so that git-am on the other side > > > will get the real author email. > > > > In fact, Google Groups intercept such a e-mail and tag it as SPAM both > > in the web application (on the reader side) and in the m-list incoming > > rules. > > > > > > > > But best try to use googles SMTP servers, that is for sure possible > > > and not too hard once you found the solution. > > > > > > > Finally, I used a regular SMTP from an internet provider. However, It > > costs me a domain name fee. > > you could try msmtp and google again, if application credentials do not > work anymore ... you need to dance the oauth2 dance ... > > Or you stay with a provider that does not enforce so much security on > you that in the end you can not send mail from the campfire in the cave > ;) > The problem has been solved as you can see here: Message ID<20230104185604.2542129-1-roberto.foglietta@gmail.com> Created on:4 January 2023 at 19:56 (Delivered after 5 seconds) From:roberto.foglietta@gmail.com Using git-send-email 2.34.1 To:isar-users@googlegroups.com Subject:[PATCH] rootfs class lock undefined in corner cases fix DKIM:'PASS' with domain googlegroups.com Learn more It was a very simple problem to solve but it required a smart internet provider that gives domain names for a reasonable price and allows users to do magic with the SMTP mangling rules. The key information is "what is the name of that internet provider?" If you take a look at that e-mail, can you discover it? LOL Best regards, R-
In mail from Tuesday, 3 January 2023 22:58:15 +03 user Roberto A. Foglietta wrote: > Hi all, > > Sometimes it is necessary to add some extra commands or arguments to sbuild > but create a class into an upper layer just for this breaks the updates. > So, this patch allows setting extra parameters through two variables. > > Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com> > --- > meta/classes/dpkg.bbclass | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > https://github.com/ilbers/isar/commit/7e72921747aedf588af492be95fb0b91ad70f4 > 55 Can't respond on specific line in the patch due to attachment form, but it would be better not to modify existing lines but just add new ones, like: --no-apt-update \ + ${DPKG_SBUILD_EXTRA_ARGS_PRE} \ --chroot-setup-commands=... It's a bit more readable. At first glance I wrongly tried to understand how it's related to "--no-apt- update" and "--debbuildopts"... :) You could send v2 or I can modify it on my side while testing / merging.
On Wed, 25 Jan 2023 at 13:27, Uladzimir Bely <ubely@ilbers.de> wrote: > > In mail from Tuesday, 3 January 2023 22:58:15 +03 user Roberto A. Foglietta > wrote: > > Hi all, > > > > Sometimes it is necessary to add some extra commands or arguments to sbuild > > but create a class into an upper layer just for this breaks the updates. > > So, this patch allows setting extra parameters through two variables. > > > > Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com> > > --- > > meta/classes/dpkg.bbclass | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > https://github.com/ilbers/isar/commit/7e72921747aedf588af492be95fb0b91ad70f4 > > 55 > > Can't respond on specific line in the patch due to attachment form, but it > would be better not to modify existing lines but just add new ones, like: > > --no-apt-update \ > + ${DPKG_SBUILD_EXTRA_ARGS_PRE} \ > --chroot-setup-commands=... > > It's a bit more readable. Two variables are useless, I realised. One in the middle is the optimal compromise. Remove the _PRE in append, it does not make sense anymore. > You could send v2 or I can modify it on my side while testing / merging. I am doing, just give me the time to rebase it on the next. Best, R-
From 7e72921747aedf588af492be95fb0b91ad70f455 Mon Sep 17 00:00:00 2001 From: "Roberto A. Foglietta" <roberto.foglietta@gmail.com> Date: Tue, 3 Jan 2023 20:53:00 +0100 Subject: [PATCH] dpkg class sbuild allows extra arguments by vars Sometimes it is necessary to add some extra commands or arguments to sbuild but create a class into an upper layer just for this breaks the updates. So, this patch allows setting extra parameters through two variables. Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com> --- meta/classes/dpkg.bbclass | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass index 7822b14..bf60a5b 100644 --- a/meta/classes/dpkg.bbclass +++ b/meta/classes/dpkg.bbclass @@ -23,6 +23,9 @@ do_prepare_build_append() { env > ${DPKG_PREBUILD_ENV_FILE} } +DPKG_SBUILD_EXTRA_ARGS_PRE ?= "" +DPKG_SBUILD_EXTRA_ARGS_POST ?= "" + # Build package from sources using build script dpkg_runbuild[vardepsexclude] += "${SBUILD_PASSTHROUGH_ADDITIONS}" dpkg_runbuild() { @@ -104,7 +107,7 @@ dpkg_runbuild() { sbuild -A -n -c ${SBUILD_CHROOT} --extra-repository="${ISAR_APT_REPO}" \ --host=${PACKAGE_ARCH} --build=${SBUILD_HOST_ARCH} ${profiles} \ --no-run-lintian --no-run-piuparts --no-run-autopkgtest --resolve-alternatives \ - --no-apt-update \ + --no-apt-update ${DPKG_SBUILD_EXTRA_ARGS_PRE} \ --chroot-setup-commands="echo \"Package: *\nPin: release n=${DEBDISTRONAME}\nPin-Priority: 1000\" > /etc/apt/preferences.d/isar-apt" \ --chroot-setup-commands="echo \"APT::Get::allow-downgrades 1;\" > /etc/apt/apt.conf.d/50isar-apt" \ --chroot-setup-commands="rm -f /var/log/dpkg.log" \ @@ -112,7 +115,7 @@ dpkg_runbuild() { --finished-build-commands="rm -f ${deb_dir}/sbuild-build-depends-main-dummy_*.deb" \ --finished-build-commands="cp -n --no-preserve=owner ${deb_dir}/*.deb -t ${ext_deb_dir}/ || :" \ --finished-build-commands="cp /var/log/dpkg.log ${ext_root}/dpkg_partial.log" \ - --debbuildopts="--source-option=-I" \ + --debbuildopts="--source-option=-I" ${DPKG_SBUILD_EXTRA_ARGS_POST} \ --build-dir=${WORKDIR} --dist="isar" ${DSC_FILE} sbuild_dpkg_log_export "${WORKDIR}/rootfs/dpkg_partial.log" -- 2.34.1
Hi all, Sometimes it is necessary to add some extra commands or arguments to sbuild but create a class into an upper layer just for this breaks the updates. So, this patch allows setting extra parameters through two variables. Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com> --- meta/classes/dpkg.bbclass | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) https://github.com/ilbers/isar/commit/7e72921747aedf588af492be95fb0b91ad70f455