On Sat, Sep 18, 2021 at 02:17:59PM +0530, open infra wrote:

Hi,

How build a package A where it has a circular dependent package B (where package B is depend on package A).

It depends.
Do you have a question about specific packages? And why do you need to
build them?

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmFFql4tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh kqEP/3ivtida6vrDysrqgL362pCh7LXQNCvsMkVd4baGJPp1ezAanxyirIhM9FCw ImDNusUHbhhrRA6+oK61hAxjKG/8lxDdvpTo7yqL0lIsnC8VePBOGseQxYtJD+op 9JUQCYHsr7ooIm3rlSCxPpHveSU6xWq8HteocvBX43b8s8dktEAPHMzPo5w22NIr YIWttTtguiTIg5rxcEAuTg73t3xhPhIFbbxoEagJhRQqc/JEUp0QGA8vBblFDLl6 dX+HpKVig9Aa7tc70HT252KQS5dcxnQS21ReZV7gO2ww77EP4jBBfHr+XM5mWTsU +Q0Tdx9K8M5u10PRYpHq7jSxymO6X1+NfzEeWoCMeZtI9830Cf8mu59hxOTvxKYb 2I8tpbDhe41luH5Vw4eOciB+MSG4OaKwdeV/jzu/kfohXpCJw2a9Zd2HOfv0kDQs wcdYxbuC36zQpE48GpPdh1j8/xu/dxwY6B5wIA4oNirJexJxyeEgG1tVQcafoXSx Bw49XZVL5AhmriTZUQRSA4fBvoEhKfypwx+6ymrfxpDBVmonxzhHubDcWdlj1gkO RmJBbNI3T+SsApgX2kuIsSnhqyF24LvMYOhfbbmVj/oXX8LLQcz9X0C5xKLAEwLe +Rk1pmSUIoKz5vYFWbnKQ5sZVDlfWdbn34hEFkCTcgmkQBW3
=VBtt
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

How build a package A where it has a circular dependent package B (where package B is depend on package A).

Regards,
Danishka

<div dir="ltr">Hi,<div><br></div><div>How build a package  A where it has a circular dependent package B (where package B is depend on package A).</div><div><br></div><div>Regards,</div><div>Danishka<br><div><br></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-09-18 14:17 +0530, open infra wrote:

Hi,
How build a package  A where it has a circular dependent package B (where
package B is depend on package A).

Once they are both in the archive it's not a problem. You just
specifiy the dependencies and build each against the version of the
other currently in the archive.

For the initial bootstrap you can use whatever local bootstrap is
expedient, then do binary uploads of one before a normal source upload
of the other.

It's a good idea to encode the bootstrap into the package dependencies
if you can, e.g. if a build excluding some feature removes the
circular dependency in a package, so you can do that minimal build of
A first, then build B then build 'full' A. This is what 'build
profiles' are for: https://wiki.debian.org/BuildProfileSpec

Doing this keeps debian bootstrappable for new architectures, and
helps you if you need to re-do the bootstrap of the pair again (e.g
due to major api changes in both packages together).

We don't have a way of doing a profiled build in the archive, but you
can upload a version of A that forces the minimal build (and doesn't
mention the 'B' dependency), let that build, then upload B and (once
built OK) upload a full A.

Sometimes people use 'foo-bootstrap' package names so that the
minimal and full versions of a package can be distinguished.

HTH

Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmFFrJwACgkQ+4YyUahv nkfNkRAAs3f2Ltq4IxYoMLzrsbUsH0Ja11K8JGXjsPP/WyOv9nTJKXCp7qQHMVzm EFOjOHkYM/PTcSZpw4Kb9Z4a2M08BqZFIz+Pbt7vpd58Cf+St24QpcRYJPBnRPyL 3O7Ujt6BGTTrt80iQg6u10zOAovpgT86UWPeDvYXocXV6XEzEfL+dzHm3krgiWul Q3r5NFtn8hKvpbElWs/odpPkPVyQUvjDeO3oBWbIUI1H8ctqHpiklg+O4fXlRMUx okZ3hrdtTUKSZELZwKZxVLebKp4S16zf61A2gHAneO45FaAkceBMunVu7Ts2cOwV eTz/+FyxfQwrp1YK2XJu0LxRqL05F1wGj1U+Uz5bKa8PdnmAcX2fZlo+VCp/VwV0 wUw2VX/ZmwyRsa+05pn5cb9VvXYdRHrCQNo2sEKK/7ABZK0e7yNbnB74Ap/DTbvU UzPRU55ODVdxADB3MjYcRmsrZwyLH4RC6ygbT3fT8tqtjvA86tRcIXkKm9hJMbdz xY9yFe1z3cBdP4NwfHs8+w52EwItzHvslSjt/tFK/McRJsHMtK7N1WYvNpubWuT5 wkc6/56dM9Q2eJOfOvoSz8rP1fCg+lwVgLzApvlsnVH33UgHcojx0olwCr+vGBwr YPmRLkgZ3Vpa3mIP3xNzstcnwQDtGB9A9DQSApHnRJcNlcisdY4=
=bbdp
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Sep 18, 2021 at 02:17:59PM +0530, open infra wrote:

How build a package A where it has a circular dependent package B (where package B is depend on package A).

You try not to, at all costs.

Bastian

--
A woman should have compassion.
-- Kirk, "Catspaw", stardate 3018.2

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-09-18 13:59:17 +0500 (+0500), Andrey Rahmatullin wrote:

On Sat, Sep 18, 2021 at 02:17:59PM +0530, open infra wrote:

How build a package A where it has a circular dependent package
B (where package B is depend on package A).

It depends. Do you have a question about specific packages? And
why do you need to build them?

As I understand it, the context here is bootstrapping a new "edge
networking" focused Debian derivative with a number of third-party
patches to existing source packages:

http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012058.html

https://docs.starlingx.io/specs/specs/stx-6.0/approved/starlingx_2008846_debian_build.html

In this particular case, because it's not a full-blown port to a new
processor architecture or anything, it seems like it shouldn't all
need to be bootstrapped entirely from scratch. Ideally, many of the
build dependencies could be satisfied initially from unadulterated
packages already available in Debian, and then replaced with custom
patched versions once any problem dependency cycles have been
broken.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmFF+PZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WClcWhAAt144bDJnThsE9vD/FY1MbcoeUUECUpt2APcKk1eaPMYS0jcYNORckzQs b8d4LXFnIDkZet5ss5hiuXPpL4JHKkIAchVxsFa1J2X+AnZoJbjae8K2G+j/wtVy zC5HEGLiYAaXsZQrY8NB2TjtQfMyeglKlochMpkk2XTvYDKzLQHAOvXxk7mvMbF6 LpuK50r/vDEx0Vejs6fcv6kNIfCQAAyAnSWJzfRbwI2F1xLAcC1tUAYevCAkojnn Uh8Bjn0kyzIte2xIDdvqZswLyPTm04vFBi7JKyXvEnz+a917BXBxRggayIMYxXgi SMSgw2bP+RuvMhbtJVdOPOgbqPr9FrzAAYx7Xm/wBGUVXVFNVch6hZ1UwbWx5Gxt 8hbQkT5lvmZ6c7zmeV30BwA7Xn122xSABhxxm6OSzLKWLsaXGuUw+VVfp+HcvE3H PYRj5bsNFSZAIxtg6IKCHJu0bbuCLlaj8xFzhPNyyPiewGmV3gIK9BcgYJ5AbY4Z siYZcVQLPBdXtskFEv5WoPjMob07yax+duLP9uftcUklaCOcMSEB7p2aBeMmFk3P KmFSW/xUXbmPDTHfKn5LBmfHXuF77sgJ+ry6OL/kaRxIdX5wHq818k55M6smnlI1 liE0GTU+8bewj8b1H/gk10R+xoYRc1AFIBEzo6Bg15wJlib91uc=
=jumS
-----END PGP SIGNATURE-----

--- SoupGate-Win32

On Sat, Sep 18, 2021 at 8:48 AM open infra wrote:

How build a package A where it has a circular dependent package B (where package B is depend on package A).

Jeremy Stanley pointed out that this is for the StarlingX project,
please consider merging StarlingX changes back to Debian and our
upstream projects and contributing new packages back into Debian
itself.

https://lists.debian.org/msgid-search/20210918143436.55h6b2i2z6hppwvc@yuggoth.org
http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012058.html
https://docs.starlingx.io/specs/specs/stx-6.0/approved/starlingx_2008846_debian_build.html
https://mentors.debian.net/intro-maintainers

As others have pointed out, build profiles are the answer for
resolving circular build dependencies.

--
bye,
pabs

https://wiki.debian.org/PaulWise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jeremy,

Yes, this is about use of Debian builds in the starlingx.

Regards,
Danishka

On Sat, Sep 18, 2021 at 8:05 PM Jeremy Stanley <fungi@yuggoth.org> wrote:

On 2021-09-18 13:59:17 +0500 (+0500), Andrey Rahmatullin wrote:

On Sat, Sep 18, 2021 at 02:17:59PM +0530, open infra wrote:

How build a package A where it has a circular dependent package
B (where package B is depend on package A).

It depends. Do you have a question about specific packages? And
why do you need to build them?

As I understand it, the context here is bootstrapping a new "edge
networking" focused Debian derivative with a number of third-party
patches to existing source packages:

http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012058.html

https://docs.starlingx.io/specs/specs/stx-6.0/approved/starlingx_2008846_debian_build.html

In this particular case, because it's not a full-blown port to a new processor architecture or anything, it seems like it shouldn't all
need to be bootstrapped entirely from scratch. Ideally, many of the
build dependencies could be satisfied initially from unadulterated
packages already available in Debian, and then replaced with custom
patched versions once any problem dependency cycles have been
broken.
--
Jeremy Stanley

<div dir="ltr"><div>Hi Jeremy,</div><div><br></div><div>Yes, this is about use of Debian builds in the starlingx.<br></div><div><br></div><div>Regards,</div><div>Danishka<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On
Sat, Sep 18, 2021 at 8:05 PM Jeremy Stanley &lt;<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2021-
09-18 13:59:17 +0500 (+0500), Andrey Rahmatullin wrote:<br>
&gt; On Sat, Sep 18, 2021 at 02:17:59PM +0530, open infra wrote:<br>
&gt; &gt; How build a package  A where it has a circular dependent package<br> &gt; &gt; B (where package B is depend on package A).<br>
&gt; <br>
&gt; It depends. Do you have a question about specific packages? And<br>
&gt; why do you need to build them?<br>

As I understand it, the context here is bootstrapping a new &quot;edge<br> networking&quot; focused Debian derivative with a number of third-party<br> patches to existing source packages:<br>

<a href="http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012058.html" rel="noreferrer" target="_blank">http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012058.html</a><br>

<a href="https://docs.starlingx.io/specs/specs/stx-6.0/approved/starlingx_2008846_debian_build.html" rel="noreferrer" target="_blank">https://docs.starlingx.io/specs/specs/stx-6.0/approved/starlingx_2008846_debian_build.html</a><br>

In this particular case, because it&#39;s not a full-blown port to a new<br> processor architecture or anything, it seems like it shouldn&#39;t all<br>
need to be bootstrapped entirely from scratch. Ideally, many of the<br>
build dependencies could be satisfied initially from unadulterated<br>
packages already available in Debian, and then replaced with custom<br>
patched versions once any problem dependency cycles have been<br>
broken.<br>
-- <br>
Jeremy Stanley<br>
</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-09-19 01:24:17 +0000 (+0000), Paul Wise wrote:
[...]

Jeremy Stanley pointed out that this is for the StarlingX project,
please consider merging StarlingX changes back to Debian and our
upstream projects and contributing new packages back into Debian
itself.

[...]

According to meeting minutes from last week, it looks like that is
either already happening or at least planned/intended:

http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012048.html

* Debian patches going upstream:
https://review.opendev.org/q/topic:%22debian-build%22+(status:open%20OR%20status:merged)

[...]

* Building bridge to the Debian community now that the patches
are going upstream now that some of the patches are being
posted to upstream community.
* Currently will accumlate the technical debt, but will build
bridge to the community members, and get those technical debt
upstream.
* Challenge with pushing patches to Debian community is to get
the maintainer to understand the why of the patches, or the
solution of an issue, so that they will accept it.

[...]

But I agree, if they aren't already it would be great to see them
pitch in with maintaining things in Debian they're relying on, as
well as posting patches in the BTS or Salsa with rationale for
modifications they're carrying.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmFHM5dfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCn9Bg/+J9B1r/KuhEeifnAYsZnV2fBaVnJhqRkD1UoA0cQfnyk44jhlb3kQphyg bYoPBRbCbJgmK3YTcJFYvfjs/tiraEEMIjzaFLIwXx50EMoNVpfySxG2uTTy8i04 8b94d2tHIQNOBGSXhBU9QCKwR6nK6BAhfmS8/GjiGPto6LjPoES+0+IC/XmrDlbn 6BO/RUIy4Vw+2TRJIaiP70LsqUnkaIsa6jXNiq7WEaB1rKjbuH1JWlfK6sNTnJMQ g3RJVdkqxa53NgmTJ3dLZ+ihThoUwJJ1F5J9wW2PXqSJTVc0wmigioBK4nHYkDgA lsZDDanmITaLGqJeUwpATpuq67pSeyRgAXMzF1fjezW8OZI3lyQWldzceQDrgXzw nQhjEYG+ItxyrcjX8ZTS3559z5bERByPvLsiX+SKZLwyySmq45sms1xZD2oGB3Vx K0f4xWiFM2BZqn+nk9vFDNebK5erom3ksA4UyISd9QivwXWrLl3bsyaAfA/Y3Z5D HeqbOICNEtGVU1WVFR/fAltcwwDFXRXWZcOnZjKOjBQrokt8c6ByH5rXjssGjVLl ZGHEwnPvXy0oc1/mrrkHjWJlmoRbcPzH68c7uczGVEQ6uS5OKnxxmMg1NkUXIAn0 IxKrfwdQNbGhcJtWl4N8I8KuzsimzE1x+BWDqjHHuqtMlr+CoSg=
=xrWA
-----END PGP SIGNATURE-----

--- SoupGate-Win32

On 2021-09-19 01:24:32 +0000 (+0000), Paul Wise wrote:

On Sat, Sep 18, 2021 at 2:35 PM Jeremy Stanley wrote:

[...]

http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012058.html

Hmm, this site has a confusing way of not supporting https.

[...]

Thanks for the feedback! Other than simply not currently supporting
HTTPS (after all, it's an HTTP URL), what was confusing about the
way it didn't? Or are you just saying you're confused that there's
still a site on the Web which doesn't serve HTTPS?

Unrelated to the subject, but asking since I'm one of the sysadmins
for the OpenDev Collaboratory which includes this server which hosts
a number of Mailman 2.x mailing lists for a variety of F/LOSS
projects including StarlingX. We do have plans to switch the static
archive sites for them to HTTPS, but it hasn't seemed like an
especially high priority because the security model for MM2 is
pretty nonexistent, so the idea is to do it while we're rewriting
all the configuration management for a migration to MM3 which
actually benefits from the additional transport security in
meaningful ways. If there's a reason we should prioritize an HTTPS implementation there over other work, then I'll see about separating
out that particular task from the larger effort.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmFHL7RfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCmMdA/9EYwVgincVgMtxvlgEse33lkpg4J+OVSX0qhi5JgYZgMtHnn3xxoRy7T9 swKnDE/TbSlBMFN2Ty/66RsNWAjC+9yBtRorn35xoCDUpXu4RxC2l73yi3NcKOry qbAUdUiwGmDESAmVTUxI7L3T4XIwtGuRMWmbFFaLoWs2/hLIBU3ZlgRabUD6Kv4o zg7rVlk/SUk3q3H+Y4S5dtASXXHtU+ZgddAxjeck4yQslJsBiLrTu46Qn9iD/8sm h4ulQySCvdnQaSJ2g9l7gPt0u1HitBOV65J0hE5eYrN2lxZTJ+7BQotGR0WiLVNN w91G5ZmnlM3j5PZpLoyYXYLAgycZZhfaKGPVMowC6rvDeo8fXMLiC8VeBIth6Uu6 VwVOanXHlhjteWGe44j1ZYHnj5r8BWL2dyR/NyPncovMVfsRYcCrCRI+C08roD2A J9KkEyd96NTdBuQ3FEI71aEAvabge+v54RDALAvoTad5LRjTRM4ISPDgPowh9ThY Ps6e8LzDXdiXRcJIptgGhjNv/pXEYaA4YM6NYlZYUk4UyJTbd4SDq29EKRJE0BUz JLeYMy+uTRJYq8XSeuuBogI0cUHaYMDiaoJAb5PH5//89FIwMAJ2pwlRFTZBmc6o LnhjQ6S9OkIPRWDLACmhbeNFbHMm1UuzNxkRhgz72qz9Xp8sdO0=
=C60z
-----END PGP SIGNATURE-----

--- SoupGate-Win32

On 9/19/21 2:57 PM, Jeremy Stanley wrote:

On 2021-09-19 01:24:17 +0000 (+0000), Paul Wise wrote:
[...]

Jeremy Stanley pointed out that this is for the StarlingX project,
please consider merging StarlingX changes back to Debian and our
upstream projects and contributing new packages back into Debian
itself.

[...]

According to meeting minutes from last week, it looks like that is
either already happening or at least planned/intended:

http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012048.html

* Debian patches going upstream:
https://review.opendev.org/q/topic:%22debian-build%22+(status:open%20OR%20status:merged)

[...]

* Building bridge to the Debian community now that the patches
are going upstream now that some of the patches are being
posted to upstream community.
* Currently will accumlate the technical debt, but will build
bridge to the community members, and get those technical debt
upstream.
* Challenge with pushing patches to Debian community is to get
the maintainer to understand the why of the patches, or the
solution of an issue, so that they will accept it.

[...]

But I agree, if they aren't already it would be great to see them
pitch in with maintaining things in Debian they're relying on, as
well as posting patches in the BTS or Salsa with rationale for
modifications they're carrying.

In all logic, considering what starlingx is, if they had the intention
to upstream some patches, I should have known, no? Well, so far, they
didn't get in touch...

My mum always says: the road to hell is paved with good intentions. :)
[1]

Cheers,

Thomas Goirand (zigo)

[1] Not sure if I translated this one well. And assume good faith:
nothing intended but entertaining the readers here...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-09-19 21:34:43 +0200 (+0200), Thomas Goirand wrote:
[...]

In all logic, considering what starlingx is, if they had the intention
to upstream some patches, I should have known, no? Well, so far, they
didn't get in touch...

My mum always says: the road to hell is paved with good intentions. :)
[1]

Cheers,

Thomas Goirand (zigo)

[1] Not sure if I translated this one well. And assume good faith:
nothing intended but entertaining the readers here...

Assuming you mean patches to OpenStack components, they've been
working together with the upstream project teams there for a few
years to integrate their changes and have mostly reached parity as
far as I understand. What's left is changes to system libraries,
kernel configurations, and so on, to tune low-level performance
characteristics for their specific deployment targets.

Up until very recently, they've been purely a CentOS fork, but with
Red Hat announcing a shift in focus for CentOS and the fact that
they hadn't completed a switch from CentOS 7 to 8 yet, they've
decided that having a more stable alternative basis for their
distribution might be in their best interests... but they've only
just begun to investigate what building a Debian derivative might
mean for them (for example, they've been relying on OpenSuse's OBS
to build all their distro packages up till now, and that may not be
a great fit for trying to build forks of fundamentally interrelated
Debian packages).
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmFHm3ZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCko1RAAoBteKYUcz0eVZugFleC1axb1t4XmvTKthU+v/8H1TFJ+FOEm7dKMTKwk U7EDIrzZiLxKOPPNJBHtGDSHjr4+wC0Se4HtAvPm5jI0+hkg010Hl9AaVIh5zrlS WRG61wcyTk18Edy0HX/dYnrlZA3dJBBzrJ1KT3MPc/gCLTxAhnlureodplExp22V NN1hZLt9PCCfJdL36g+ZZ5O7q1lRTTPKJrtHISqKVlb9rSWdbtGQ8mRWp5btfeJH mSZyGCy8CTaxBUqhFZYUmKPmEzKmRJvaq0PqudM44SS+PRMoqI2aYVh25juzcn+8 vmDheBANbrmYQ2RZMRqIOkmH6hAdUzbqEci/uGHz168+g7tcDsZPLFwMSY22ZHN7 62bJF+jynIVkOUnITc/oVeT7W185KvrDnu1ny4ttMW+nUf1NsxqOihxg0L6PWn3P VVnqEaPGdv38VOydxp+zjRfaMMiZWChScVzsjvyzzpYbBeD9A7dGACcBFPb80ESP 5apGIkuzxaqmS2qOTGvisVwzm8zf/F37N4ua6ds8x3pQqqZ7tUYo3XHcPtwMbupr /ZbPTLR0eBGcJ5skEZeDAr33YKb6/RIjWa+I0H7Mb0XBslsJdwAUbPQkhAD/EiYP 3/TZ/stTHlmLx2iQ2qwEvFxtzmCqHTYCfiF6vOLtNGbdfVDD84U=
=ZXO4
-----END PGP SIGNATURE-----

--- SoupGate-Win32

On Sun, Sep 19, 2021 at 12:57 PM Jeremy Stanley wrote:

According to meeting minutes from last week, it looks like that is
either already happening or at least planned/intended:

http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012048.html

Excellent, that is good to see. In addition to pushing packaging
patches to Debian, they need to work with our upstreams too,
especially the Linux kernel community.

But I agree, if they aren't already it would be great to see them
pitch in with maintaining things in Debian they're relying on, as
well as posting patches in the BTS or Salsa with rationale for
modifications they're carrying.

It sounds like they are using the Pulp tool for creating binary
archives (including apt). I note that Pulp isn't in Debian yet,
hopefully they consider packaging it. It sounds like they might also
be using Aptly (typoed as Apily?), the upstream project for that was
quite unmaintained, some folks stepped in but more are needed.

https://wiki.debian.org/DebianRepository/Setup#Pulp
https://pulpproject.org/
https://github.com/aptly-dev/aptly/issues/920

--
bye,
pabs

https://wiki.debian.org/PaulWise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Paul,

On Mon, 2021-09-20 at 02:11 +0000, Paul Wise wrote:

On Sun, Sep 19, 2021 at 12:40 PM Jeremy Stanley wrote:

On 2021-09-19 01:24:32 +0000 (+0000), Paul Wise wrote:

On Sat, Sep 18, 2021 at 2:35 PM Jeremy Stanley wrote:

Normally one would get "Connection refused" when connecting to a port
that isn't open, but at this site one gets "No route to host", as if
there is no network path to reach the host, which is clearly not true
since the HTTP port works. I wasn't aware it is even possible to have different routing for each TCP port, I guess this is a feature of
OpenStack?

If the packet reached the host that would be strange. Still it is possible to configure that by iptables.

But for devices on the path that are configured to do some processing, this is normal behaviour - e.g. Cisco A9K routers would generate a "No route to host" for filtered ports, no matter that there is "Port is filtered" message. Also all kind of re-directors/load balancers/etc. would do the same for ports that are not configured and they do not know how to route the packet.

It is a common networking concept to route packets via different paths based on ports, protocols or any other non-destination address based criteria - "policy based routing" or PBR for short...

Hope that helps,
b.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmFH99cACgkQE2VyCRPS 8i3GbA//TBkntlkhe0e6mewudnbgy00UW6QMAKRR/EqxnY+0cPtiPUNf7P96Pbkl zW6ztXs24dfijxE8YOyBVGbJ3Yj0lM9hhL5Hf6Dt8i42kSlswYAaf1TC1eKPUbqf QT3Yu092/XWXt0CRW5dJMV2fw2y1vzHyQC5shPxOMnW14JtdSxpqLlsSqkch2VqJ 6fLosSUHzp/55FlxXqsA+BPsNG0PBNILlQl+9KvHdopcTNwGMX3ly0xx67TIUgx1 oMm7LflgfuHtKNGrOqdah/mi383DYtK1/vu++IXqw7+UCm8sQnsIlwovFQ2Oi4Mg ex8UgwMDCGITK/yvavdoCWfXU21Uel/vd2AITgovOBL7A8pXJUpf87ONiWI2AxNU t4+9NfPmsozZpW/tTpsVV4Nbpg4V4yBaaBUh7Vl23fKJRVPXqlHzZHNX3L02BHT5 2lqJzSaVn8woAiJzqmEecVUSrhYR/nL0+m0AubKh+0NNXzifcf2m6m52GJF3XIfU NK4Rffdso5kF+R4yXmXubhlME0uGleSSHZM/qTaUpCfY+qlQ/IwNGuHTHanDfLqp l2mag3Fx7AIdGuLYs4IFvgjmO9qa22rRY/8ztwBrSi35EJXvPAByi55NKsYn77UV 4l/wyws2DUaS659ecm81jp8hGJdpRW6atkgHCmBgwbvEjRUz+5M=
=aEjH
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-09-20 02:18:48 +0000 (+0000), Paul Wise wrote:
[...]

they need to work with our upstreams too, especially the Linux
kernel community.

[...]

A majority of the contributors to StarlingX are currently employed
at Wind River and Intel, and I think both organizations already have
a few people involved in upstream Kernel development, so hopefully
that's not a stretch for them.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmFIkd9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCkaAw/+MRIydGg/Szqd4JYcUTG8O5QGKFEKZbFrHu+jbuy2To2wrsHNy/dJ3CZU j4hwz/jAazvZ5UafkJxsQkMbE8aSOm2SBqeU1p5gwktyDK+vg0A8bzQxHMQNzi+p wiC0dUXtDXyeNa/w92BNfJxbtynUmturJQO/rNG2I0XcImFEF+lvV4wH9jr16jLX HlarjRvcsmD4tlRa3IjPjG/KtfrBPxckHAP7EfKttHL7yeKi0Joz0y+GYc/U6MA5 FWnKXR7SipNjYexp6T9ZTED3Hv++AEmkTiHrl+AZl5vQNkt5UPws4apPgfFhebG2 s4Z0oab50OF3Y6EsCi0PrJq/w386PQaU21l+LCwRtCrOiAifHYXNDWIxXNQmrqWK jRZYxbvIhWO74n9O891xqCHouveUmxpFivAFFKPxUpIsZ1IE7u45t6PTqK+LJ2QF 9F0xdGeLGfWFPZTMj8AIDG32rJyPE5Z5GMID+J7EEJ8WM0V/2fZOe6cCWwCP7Qmf 6Uw5dzUoDqSRGxYESNqj/oETZ1B2F8qLpX8THlbysYJdHS0hN4vD5cp1ADhLSHyN aYnHDgrm18JaqmgwpRaz3NP0HAd2yx3bZYmK8CoN/i9YrKIf2xvPBy8HKLCPNdlf PhioY+3QKYWUAmdFvjZv/AKniRio9MQ+XtaeLORcCnzYCoqYLLo=
=IEF7
-----END PGP SIGNATURE-----

--- SoupGate-Win32