On Fri, Aug 16, 2024 at 11:44:38AM +0200, Andreas Tille wrote:

In #829444 it has been proposed the addition of a new "layout" option to gbp.conf, which would tell git-buildpackage which layout to follow, allowing for a graceful migration.

I've been thinking about a different approach though. What about adding
a warning to git-buildpackage when `debian-branch` and `upstream-branch` are not set in gbp.conf? Compared to the `layout` option, it would have
the following benefits:
...
How does it sound to you? Am I missing something?

I prefer having no debian/gbp.conf at all in case the repository layout
would fit team policy. So the question is whether git-buildpackage can
cope with the old

master + upstream + pristine-tar
as well as
debian/latest + upstream/latest + pristine-tar

if no gbp.conf exists.

pristine-tar isn't the default either, so you need debian/gbp.conf if your
team uses it.
Unless I've missed some recent changes.

--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAma/ItAtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh XFAP/RZlgk+0vW+2L42NYE4pBAGyd3T9MAWIJRWNKbEtCo4Q1xG7yu/9wUh+52Nb 9JtH6AeTV4BdOHVBmZq8f5WhgvOaup/rMRHLjrEna+8+RrMCh/4r782vZ5CHY7C3 nkpYEbUgz/uOGZtPpa3VrKxeHvMV+PCnMc31t44RliQM1U5NIoPRcWVUoH9ARZVg n/wpDfvcJP8HcM8VTdWiBtIEcESt+f6VxKFuq5J//LOgrlgEn1o6lmntCZZsEKLp 8EOUcJuzU6h6Nx2CEVWfsBAh6t+79PrRrXHjYD492BTZNLblzlRVsStWHqYqpqkB AWKQENw7jRXGMwtZFqjKdu6/sDtNQD8XBWDQUboCFWrgOIlFcnrFJb0KLkiEvJdr D8p3odI0phb49O058yFtA2cBeCddxiORNTP3ZnVPr2S3mWYpBnXyTpBy4rddMyHQ lmQnjOmT5t81SQaQDV7nQTBEGOryJS8ivkexECSNobLjox+PasVRYgAdy+W8g6EG DZvtqE3zi4Vac8FmGUtPTyXwPOvZeHNvRXaS4OabxZZqqNkMvGue4h6U1LTRVJar bDW2AftqxT2tM9mUX+Dmmnf9fjuAuj9kWg/J9w9SsCt2/P4qgi+Qt07G/oWjOl9l 1Fg1JAj8iQE00gtG3++yKUvzO0OTVOdq/SRckA9Tv9K7OcjV
=g2zO
-----END PGP SIGNATURE-----

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

Please stop cross-posting to both bugtracker and d-devel.

Quoting Andreas Tille (2024-08-15 11:15:33)

considering that it makes sense to settle with DEP14[1] first before we
can decide about DEP18 I wonder what is finally needed to accept DEP14.
I think its cruxial to make git-buildpackage supporting DEP14 per
default[3] but I'm somehow sensing some hen-egg problem here what to do first. If DEP14 might be accepted the motivation to fix bug #829444
would be probably way higher.

I fail to see this as a chicken-egg problem: DEP14 do not depend on git-buildpackage supporting DEP14 with zero configuration.


Quoting Andreas Tille (2024-08-16 11:44:38)

I prefer having no debian/gbp.conf at all in case the repository
layout would fit team policy.

I understand that it would be lovely if git-buildpackage supported DEP14 without you needing to touch a thousand packages.

But do you really put on your DPL hat and raise that wishlist bug to a
matter for d-devel to debate and try solve?

Please do consider the simpler approach here:

Step one: Discuss on d-devel if DEP14 can be accepted as-is.

Step two: Discuss in bugreports how various tools might be improved for
as exciting a user experience with DEP14 as sensible for each tool.


Personally, I think DEP14 is usable as is, and look forward to have it
formally be declared done. I do not, however, understand the details of
the DEP procedures well, however, so look forward to feedback from
others beter understanding those details.

...but not details on git-buildpackage: Details on the formal DEP
procedures - unless those really are super intertwined. Until someone knowledgable on DEP procedures explains how that necessitates solving
specific tooling issues as well, please pretty please discuss tooling
details, like git-buildpackage migration handling and/or default
settings, at the appropriate bugreports *without* cross-posting to
d-devel.


Kind regards,

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============„28866690444792518=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAma/QiUACgkQLHwxRsGg ASE0Jw/+LEL82K4EAFnPsq3nU0ewlgi0KZdNdJG9dSfx2tGiMGDP3S84lWxQyqy2 p6wNS8kuTsrZOTRAuC7lfTWDgIt8AkGbkWQ9DOMxCot0gwSxFQUs+HYYCzeIaHOT yfO0hZRkBf6y8DE92O8Mg7YPfIpQxiJH/+coeK7k036U2SE6f8+bTKFwiq/UC5oa +E+gVm5lXNXikh6yMVPHA94D8M3iKxdScUzbsvOZhzElwSUnlKMuqhQgZwCs0k7w GU51SZFDqmdlx08zSV7Gtn5ni4jrTAyOu37gpf4eEi5LB1IgbHeCuQkAuL4bPhtA nHf3NOHRpWMDT7W2HM3ZmWbX1vmOiu0UNfrSiL1dR4OsH3iOfkcOwXDZwd+5dcWJ dHv5VCssyU5LvMf+iUFm2ai0WFxZ9IFXYdDHFdiv18bxeI6LjfSEC1e9AiHJvj1S cNp/XDjwLInLftO0FOIZXVUkSbH5oIQ+/YcsQf0u

Am Fri, Aug 16, 2024 at 02:58:40PM +0500 schrieb Andrey Rakhmatullin:

pristine-tar isn't the default either, so you need debian/gbp.conf if your team uses it.

That's correct but the teams I'm working in recommend something like:


Add the following to the configuration file ~/.gbp.conf or debian/gbp.conf:

[DEFAULT]
builder = ~/bin/git-pbuilder

pristine-tar = True
pbuilder-options=--source-only-changes

(for instance in Debian Med team policy[1])

Unless I've missed some recent changes.

You did not miss anything, My statement was incomplete.

Kind regards
Andreas.


[1] https://med-team.pages.debian.net/policy/

--
https://fam-tille.de

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

Hi Andrey,

Am Fri, Aug 16, 2024 at 07:17:52PM +0500 schrieb Andrey Rakhmatullin:

pristine-tar isn't the default either, so you need debian/gbp.conf if your
team uses it.

That's correct but the teams I'm working in recommend something like:

Add the following to the configuration file ~/.gbp.conf or debian/gbp.conf:

Putting team-specific settings into the global ~/.gbp.conf is a bad idea
in my opinion, but also you can set DEP14 branches there in the same
way...

Sure I can and probably would - but we need to decide about DEP-14 first.

Kind regards
Andreas.

--
https://fam-tille.de

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

On Fri, Aug 16, 2024 at 03:59:07PM +0200, Andreas Tille wrote:

Am Fri, Aug 16, 2024 at 02:58:40PM +0500 schrieb Andrey Rakhmatullin:

pristine-tar isn't the default either, so you need debian/gbp.conf if your team uses it.

That's correct but the teams I'm working in recommend something like:

Add the following to the configuration file ~/.gbp.conf or debian/gbp.conf:

Putting team-specific settings into the global ~/.gbp.conf is a bad idea
in my opinion, but also you can set DEP14 branches there in the same
way...

--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAma/X5AtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh QGsP/0yn8ej6Hgc1lmqnGKnpvlxmX5BmnLUE0iE34W/OCpNf8MgEe5D/+6vlITzs v5AjGu97kZHf5ZyagTWNhhnPF4U5Z0AIBzQ95DLcVBHd6hSp0LNH7N8uBBRkhIon ScDodecTcXE2/u3/HPJcSe3dhzBbaP1/vI6qLOuXcJvoP51AEVTu983JuR6AQAFp E9hAuNVvwA+AyNfowFv8OmXjq/+eq14y11weIy0rUPjPdrSnFb9hzvJcvezJw6nU Z4WOKEqEPTeke3VkuQZXvM5kJ0nP7XMfEO6MMXNp4owU0kt9D48vHno6ipUo9SCe pOP/9QUb3FFiGBZu94vO+KjRWM5YwcKri8n/i/6KykuK03pyATXXTEtDQs5uL/qQ s3+gLn1ZADGD3H7Wyf1RMUTXPeAB1p5bBd1jaPUmXl1WbwHRI7OhSj6Z/aH/DNN5 rQasQvyCn9ZFCOgipZx3/PRVSMy5kjG427hayRXarzBkv4gqnV2/SdHgd3ZBgepe QEuSkaRv58nozXl1r89NMXB5o77OE332QNC/SHy5IkEh2GnGVzS+JRvqHbGXq0B2 XR+jkuDDS5rorTnELcgF41GVIKFDPHJ3V68aNWaUsNTK0ByArvML64dulFmO0qZj lDbhpQ1ROXI2dZXPBwc/nrVsGZ+dMyIyaMbvLMzqPpp70lX8
=kQ0j
-----END PGP SIGNATURE-----

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

On Thu, 15 Aug 2024 11:15:33 +0200, Andreas Tille wrote:

So accepting DEP14 would mean a lot of work for me (at least
testing the suggested scripting solutions[4] carefully)

[…]

Are there any blockers to accept this DEP which I might have missed?

[4] https://lists.debian.org/debian-devel/2020/09/msg00168.html
https://lists.debian.org/debian-devel/2020/09/msg00172.html

IMO, and from discussions in the Debian Perl Group, the blocker is
the conversion of existing repos, both on salsa (which should be
doable via the API as suggested in the sketches mentioned above) and
also locally for hundreds of developer machines [git fails horribly
on the upstream/ → upstream/latest change].

Some notes are in https://gobby.debian.org/export/Teams/Perl/new-branch-layout from 2022; just to show that this is all not totally trivial …

Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-

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

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAma/xmRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgbFuRAAxnw6+Lj5p12cy0+zZ/HI7xcio4cYRS1YxBYFqPqnvdoZnZuLauKewT27 tW6xwR2hr0uM/2/2lGiISzBPZXdHKV0eWg5+A+3N9eX5a4pvaB0F+dlNjw7JbpDZ kWcgyZVW2JOliXDUJBavkSHlmcGMR1t84nLbG5MWWgBBA8/Hmf5w2/utHsJdDds5 WJ8OD91qZxdctkXLF+vWQgPAWGNGo9txx2SbMmCZb+FtBe/IA5jmS8+nbZEkwR5f yMIdPSt2/DaflZqQNu0biA0A6nWNPOROxi1bOhdpxoxTNIYB8Wq64AkTFAYM7ndV 96+RDQMVKioDMt+qB0cKH5wzXoG6JKyHzV4cjiwpZ25C1ibO/sFPzb/LulAzU61P HxrrmJEGXMUsxDYUY6pw4JZgUE2wxFcZBHA9Z44GyjpK4RMUlGrZoSHU4TgFd0fv dT/LQm1BD/YWvnCew4eNjk9Ej4XLTOslm3PbAfu87NPhnMdHeSbHOx5UzxvKLwbX
9xk3HhSx

Hi,

On 8/16/24 23:24, Andreas Tille wrote:

I tried to express: I'm more than willing to convert all packages where
I'm Uploader (most preferably) if DEP14 is accepted.

Would it make sense to try and convert a few packages to DEP14 first, to
see if this can actually be done and where the pitfalls are, before we
decide it should be done?

I think DEP14 has the same problem as all the other git mappings: it is incomplete. That doesn't mean it is useless, but it is a "we are using
git as a network file system" type of mapping, and I wonder if that is
where we want to be at.

Simon

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

Hi,

A couple of years ago I was thinking about implementing DEP-14 support in gbp, and my idea was that it should be as automatic as possible, with gbp.conf settings adjusting the automagically detected config if necessary.
E.g. if it sees master+upstream, it works as before. The presence of pristine-tar should enable it automatically (unless disabled in gbp.conf). If debian/* branches are found, DEP-14 is used, preferring debian/latest to debian/unstable to debian/sid to
debian/master to master. Similarly, pristine-lfs being there enables it, if both -tar and -lfs are there, checking out happens from both but committing goes to -lfs only.

Doing something like this would enable everyone to continue using their current schemes while allowing an easy way to migrate (just rename the branch and go ahead).

--
Cheers,
Andrej

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

Hi Andrej,

Quoting Andrej Shadura (2024-08-17 10:19:57)

A couple of years ago I was thinking about implementing DEP-14 support
in gbp, [...]

Please note that you are posting to the d-devel thread about DEP-14 in
general, not the debbugs issue about DEP-14 support in git-buildpackage.

I suggest that you repost the above to 829444@bugs.debian.org, so that
those particularly interested in that issue (now and in the future) can
easier locate your fine contribution to solving it.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============C65311061850379805=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbAXyoACgkQLHwxRsGg ASHEwg/8C4pxn+4BcUOuj+eDWUzeYd9kF3GR2HjVNnroPN8fVUznzdPg3qsZTki0 fP8kRYDx2sDFTMbZ/GW8l+itYEsv3POfHQpbQHX34K0dGi1WB72NOyQLxT/CRdaj 9BaBFrjb8EMAO3KcXqSXEAMxrzKDdcZz051tC6olj72WIqpcJp0oQqWTM9MwtLTJ +lPysxlHOiIZLPICmiR5Nss3WoqeZRv0jdR+E7Ou588BvyWT+ZvDqGxm9cFp3JYz O3Pdum5+PHVHx5wZZBlhSC59tYTJNEBaGTAXByEN5Wb3lRcbkJixY/cM4ImlYgJ0 DEbDR+yaFlR4cw5RgqtUwAt5gmx/8KthsdD9zRp/DyB5mkze4q+iBUakFpd8gb0C KUo+Uo0yJ1w192e6ITSFuRwb56y1IpeWKz52mXWZi3M8Fg5FGQt3c32+WX+qjiX3 zg2dJs8exKCZIl8ohKM+pngWbQ0xj6g8pPh3E7YA

On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote:

IMO, and from discussions in the Debian Perl Group, the blocker is
the conversion of existing repos, both on salsa (which should be
doable via the API as suggested in the sketches mentioned above) and
also locally for hundreds of developer machines [git fails horribly
on the upstream/ → upstream/latest change].

I want to echo this pain. When changing the layout it seems almost
better to start from scratch.

Additionally, in my opinion debian/latest is a mistake we should not
recommend.

Chris

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

Hi Chris,

Quoting Chris Hofstaedtler (2024-08-17 10:17:19)

On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote:

IMO, and from discussions in the Debian Perl Group, the blocker is
the conversion of existing repos, both on salsa (which should be
doable via the API as suggested in the sketches mentioned above) and
also locally for hundreds of developer machines [git fails horribly
on the upstream/ → upstream/latest change].

I want to echo this pain. When changing the layout it seems almost
better to start from scratch.

I have in the past found it confusing how to handle it, but now I find
it tolerable (and don't recognize the "better to start from scratch" judgement), after I figured out (as also hinted at in one of the links
by gregor) that you need to do the following, in that order:

1. unlock branch "upstream" on salsa
2. rename branch "upstream" → "upstream/latest" on salsa (or delete it)
3. rename branch "upstream" → "upstream/latest" locally
4. push local changes to salsa

(strictly speaking you can do step 3 before 1-2)

Additionally, in my opinion debian/latest is a mistake we should not recommend.

Please elaborate why you consider it a mistake. That's not obvious to
me.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============467230535842301986=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbAY6AACgkQLHwxRsGg ASFOtg/+IqQXFM3ijRy3W9dRLvoBpjeVMP2ihEC3O9j3gZMdNRgG03bAYhTBRSAM Ft7fWjCoO6r5NZPKi83g+Ld8Xedz9wfkc2cS3tK84cgB+n6KkO6laqf3ToyECOu1 O/0MiptIykGWcQfvjPHR1uNZeOua/wX0sxpItKFLLUk8xmbAmhxYO7Y7vvNifX/x F0QiM4LynMJYasiUvrJtMRqXEhkmPGTxSbOBDmAn2XqkHHTy4/BThNmUmwlMitfY Te1QdbIltGzE6baQ6qGYhXz8PAvCHzP2ue2SmN31hWG+czQsCI8o/oBq8SLasv16 Jir7XBr6E51jaO074/u5Mwtjdcouy1++95OQC2quhDFyQsrzMaLa+RuFIVi1tcwM PkrUmnjy3KpkefZXInTBWvEjN7gNIgQ8wvMT41HR1VGhks6RRrDIKKdFYq8Kmu9A 0wdsLeQ0bolhDZ37S3W3t/mJDyM1CvJuYaYacROx

That's correct but the teams I'm working in recommend something
like:

Add the following to the configuration file ~/.gbp.conf or
debian/gbp.conf:

Putting per-repository relevant settings into a global config and
not into the per-repo config seems to fly into the face of the DEP18
spirit.

Maybe there is no issue with changing git-buildpackage after all
then.

Chris

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

Hello,

On Sat, 17 Aug 2024 at 10:52, Andreas Tille <andreas@an3as.eu> wrote:

Any ideas how we can come up with some suggestion that will finally
enable us with some common reopsitory layout that enables automated conversion from any existing layout. IMHO we should move DEP-14
forward since having it an open suggestion for ages will not bring
any progress.

Thanks for bringing up this topic, I just wanted to share 8-year old
notes, when it was discussed the same topic and kind of acknowledged
at DebConf16:
- https://gobby.debian.org/export/debconf16/bof/gbp (entry https://gobby.debian.org/export/debconf16/bof/gbp)

Not sure why this didn't happen back then, probably further discussion
at #829444

Regards
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.

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

Am Sat, Aug 17, 2024 at 10:17:19AM +0200 schrieb Chris Hofstaedtler:

On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote:

IMO, and from discussions in the Debian Perl Group, the blocker is
the conversion of existing repos, both on salsa (which should be
doable via the API as suggested in the sketches mentioned above) and
also locally for hundreds of developer machines [git fails horribly
on the upstream/ → upstream/latest change].

I want to echo this pain. When changing the layout it seems almost
better to start from scratch.

Additionally, in my opinion debian/latest is a mistake we should not recommend.

OK, I admit I do not mind about the actual names that are used. I mind
about the fact that it makes sense to settle with some *common*
repository layout for all our repositories to make sure that someone who
wants to contribute to some random git repository feels home
immediately.

Sam said, gbp-buildpackage default is fine. If people agree here we
could change DEP-14 to simply use this (despite now lots of repositories
are featuring the currently suggested DEP-14 layout).

Gregor and Chris underline that the choice of the names in DEP-14 are
hard to convert. I'm fine with some better proposal.

For me DEP-14 is an attempt to settle with some common default. I
personally do not mind about the actual names. I guess its a
requirement to have some automated conversation (which could be even
done by Janitor for instance). If DEP-14 suggests something that fails
here its hard to accept for many (including myself).

Any ideas how we can come up with some suggestion that will finally
enable us with some common reopsitory layout that enables automated
conversion from any existing layout. IMHO we should move DEP-14
forward since having it an open suggestion for ages will not bring
any progress.

Kind regards
Andreas.

--
https://fam-tille.de

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

Hi

On Sat, 17 Aug 2024 at 10:59, Hector Oron <zumbi@debian.org> wrote:

Thanks for bringing up this topic, I just wanted to share 8-year old
notes, when it was discussed the same topic and kind of acknowledged
at DebConf16:
- https://gobby.debian.org/export/debconf16/bof/gbp (entry https://gobby.debian.org/export/debconf16/bof/gbp)

... of course I meant the entry "Switch defaults for 0.9.0?"

Regards
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.

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

Chris Hofstaedtler <zeha@debian.org> writes:

On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote:

IMO, and from discussions in the Debian Perl Group, the blocker is
the conversion of existing repos, both on salsa (which should be
doable via the API as suggested in the sketches mentioned above) and
also locally for hundreds of developer machines [git fails horribly
on the upstream/ → upstream/latest change].

I want to echo this pain. When changing the layout it seems almost
better to start from scratch.

Additionally, in my opinion debian/latest is a mistake we should not recommend.

+1

I'm happily working on packages with many different git styles, and I'm building packages for different suites and vendors: the 'debian/latest'
naming style has not contributed to my work flow.

I do understand the original rationale, I think, since it feels ugly to
put an experimental upload on a debian/unstable git branch.

However I think there are two kind of experimental uploads that are
different in nature:

1) uploads to experimental that test things intended for sid quite
soon (maybe architecture build testing like we just did for
'libmceliece'), and

2) complete odd-ball uploads that is known to break things, but
needed for some other experimentation that may be multi-months while
there could be uploads going into unstable (like we did for the Go
grpc package during the last months).

I believe for the use-case 1) it is better to use debian/unstable
immediately and for 2) it is better to have one branch debian/unstable
and one branch debian/experimental. I'm missing what positive effects
arise from using a debian/latest branch.

Maybe this could be clarified in DEP14 that 'debian/latest' is only
recommended for use instead of 'debian/unstable' for 1)-style uploads.
I still wonder if it is actually wortwhile to rescue 'debian/latest'
though. I've often used 'debian/unstable' instead for this purpose,
since the 1)-style uploads are not uncommon for me.

I think the core problem is that there really is no reasonable concept
of "latest" branch for a Debian package. There are just many different versions targetted at different suites or vendors, each of them having
their own meaning of what is latest.

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

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

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZsBjaBQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFoigkAP9tb9HqSU6k0TtZ27/1pBz36SfwcD/f HZL1KaWxyVL62QD/eOSa05b09RMEvqYCOrbxIJ4ZVHec6OrgbVNht0/J4gs=Cs5T
-----END PGP SIGNATURE-----

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

To: debian-devel@lists.debian.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------iGoB9ZwxxAiwqW2iSgF8y0SP
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SWwgMTcvMDgvMjAyNCAxMDo0NywgSm9uYXMgU21lZGVnYWFyZCBoYSBzY3JpdHRvOg0KPiBI aSBDaHJpcywNCj4NCj4gUXVvdGluZyBDaHJpcyBIb2ZzdGFlZHRsZXIgKDIwMjQtMDgtMTcg MTA6MTc6MTkpDQo+PiBPbiBGcmksIDE2IEF1ZyAyMDI0IDIzOjM2OjMxICswMjAwLCBncmVn b3IgaGVycm1hbm4gd3JvdGU6DQo+Pj4gSU1PLCBhbmQgZnJvbSBkaXNjdXNzaW9ucyBpbiB0 aGUgRGViaWFuIFBlcmwgR3JvdXAsIHRoZSBibG9ja2VyIGlzDQo+Pj4gdGhlIGNvbnZlcnNp b24gb2YgZXhpc3RpbmcgcmVwb3MsIGJvdGggb24gc2Fsc2EgKHdoaWNoIHNob3VsZCBiZQ0K Pj4+IGRvYWJsZSB2aWEgdGhlIEFQSSBhcyBzdWdnZXN0ZWQgaW4gdGhlIHNrZXRjaGVzIG1l bnRpb25lZCBhYm92ZSkgYW5kDQo+Pj4gYWxzbyBsb2NhbGx5IGZvciBodW5kcmVkcyBvZiBk ZXZlbG9wZXIgbWFjaGluZXMgW2dpdCBmYWlscyBob3JyaWJseQ0KPj4+IG9uIHRoZSB1cHN0 cmVhbS8g4oaSIHVwc3RyZWFtL2xhdGVzdCBjaGFuZ2VdLg0KPj4gSSB3YW50IHRvIGVjaG8g dGhpcyBwYWluLiBXaGVuIGNoYW5naW5nIHRoZSBsYXlvdXQgaXQgc2VlbXMgYWxtb3N0DQo+ PiBiZXR0ZXIgdG8gc3RhcnQgZnJvbSBzY3JhdGNoLg0KPiBJIGhhdmUgaW4gdGhlIHBhc3Qg Zm91bmQgaXQgY29uZnVzaW5nIGhvdyB0byBoYW5kbGUgaXQsIGJ1dCBub3cgSSBmaW5kDQo+ IGl0IHRvbGVyYWJsZSAoYW5kIGRvbid0IHJlY29nbml6ZSB0aGUgImJldHRlciB0byBzdGFy dCBmcm9tIHNjcmF0Y2giDQo+IGp1ZGdlbWVudCksIGFmdGVyIEkgZmlndXJlZCBvdXQgKGFz IGFsc28gaGludGVkIGF0IGluIG9uZSBvZiB0aGUgbGlua3MNCj4gYnkgZ3JlZ29yKSB0aGF0 IHlvdSBuZWVkIHRvIGRvIHRoZSBmb2xsb3dpbmcsIGluIHRoYXQgb3JkZXI6DQo+DQo+ICAg MS4gdW5sb2NrIGJyYW5jaCAidXBzdHJlYW0iIG9uIHNhbHNhDQo+ICAgMi4gcmVuYW1lIGJy YW5jaCAidXBzdHJlYW0iIOKGkiAidXBzdHJlYW0vbGF0ZXN0IiBvbiBzYWxzYSAob3IgZGVs ZXRlIGl0KQ0KDQpyZW5hbWUgYnJhbmNoIGluIHNhbHNhIHdvdWxkIGJlIHZlcnkgaGFuZHks IGkgc2VhcmNoZWQgZm9yIGl0IHdoZW4gaSANCmNvbnZlcnRlZCBzb21lIHJlcG9zaXRvcmll cyBidXQgaSBkaWRuJ3QgZmluZCBpdCwgY2FuIHlvdSB0ZWxsIG1lIGhvdyB0byANCmRvIGl0 IHBsZWFzZT8NCg0KY29udmVydGluZyAidXBzdHJlYW0iIGJyYW5jaCB0byAidXBzdHJlYW0v bGF0ZXN0IiBoYXMgYWx3YXlzIGdpdmVuIG1lIA0KcHJvYmxlbXMgYW5kIHdhc3RlZCBtb3Jl IHRpbWUsIHRoYXQgd291bGQgdGFrZSBhd2F5IG9uZSBwcm9ibGVtLg0KDQphbm90aGVyIHBy b2JsZW0gc2VlbXMgdG8gYmUgaWYgSSBoYWQgYW4gInVwc3RyZWFtIiBvcmlnaW4gKHdoaWNo IEkgdXNlIA0KdG8gY2hlcnJ5LXBpY2sgdXBzdHJlYW0gcGF0Y2hlcyB3aGVuIG5lZWRlZCks IHNpbmNlIHRoZW4gSSBwdXQgdGhlIA0KdXBzdHJlYW0gb3JpZ2luIGluIHRoZSBsb2NhbCBy ZXBvc2l0b3JpZXMgYXMgInVwc3RyZWFtX3JlcG8iIHRvIGF2b2lkIA0KcHJvYmxlbXMuDQoN CkkgdGhpbmsgZm9yIERFUC0xNCBpdCB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bCB0byBoYXZlIGEg aG93dG8gZm9yIHRoZSANCmNvbnZlcnNpb24gYW5kIGEgbGlzdCBvZiB1c2VmdWwgdGlwcyB0 byBhdm9pZCBwb3NzaWJsZSBwcm9ibGVtcw0KDQo+ICAgMy4gcmVuYW1lIGJyYW5jaCAidXBz dHJlYW0iIOKGkiAidXBzdHJlYW0vbGF0ZXN0IiBsb2NhbGx5DQo+ICAgNC4gcHVzaCBsb2Nh bCBjaGFuZ2VzIHRvIHNhbHNhDQo+DQo+IChzdHJpY3RseSBzcGVha2luZyB5b3UgY2FuIGRv IHN0ZXAgMyBiZWZvcmUgMS0yKQ0KPg0KPg0KPj4gQWRkaXRpb25hbGx5LCBpbiBteSBvcGlu aW9uIGRlYmlhbi9sYXRlc3QgaXMgYSBtaXN0YWtlIHdlIHNob3VsZCBub3QNCj4+IHJlY29t bWVuZC4NCj4gUGxlYXNlIGVsYWJvcmF0ZSB3aHkgeW91IGNvbnNpZGVyIGl0IGEgbWlzdGFr ZS4gIFRoYXQncyBub3Qgb2J2aW91cyB0bw0KPiBtZS4NCg0KPg0KPg0KPiAgIC0gSm9uYXMN Cj4NCg0K

--------------iGoB9ZwxxAiwqW2iSgF8y0SP--

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

wsF5BAABCAAjFiEELEHRfLe4S9D5+1GzaAZorpB/EB0FAmbAa0IFAwAAAAAACgkQaAZorpB/EB3g wRAAiwg29byiz8aTA5CGXhKyQeg+ABOEU+RjnkZSPldsjSAjmiJt6FI1sXlYwzU2xVPuT2BBhqoK 70Avdy1gXfEbjMtfMj/Zv2y9LvfB7Zyq99cBoFaR3+VjpKJIN5vjCkWew7q37PTK9idaB/K5E1Vx 9W2n/zxV3IgETadWc2SNrnRipIV+pOdkdy9VBkZBcD/6BAMtK9wfWhQBETss2BnNmN7trGj0QvB+ mYYkt/PhUFOV7AJXQYnzj6JG0v7asSXoUc2nHiwCfQTg+2WnbsAATXy49SdKDezqKTqzBqWwkACr x98BVarq4L2O23dmDgjPHGzOVXYUutWQ1zvOGzlFK29/rF5FYSikG7t2AnFi/A+Peug8SPgUHcU7 2EmjPDb0EJr09cU31VzmzWMvvEQ1+fRiwBBcKjsS4FK9eR5x4KG6JHdS8tiBym/FZH6J2fGuZj9A DbFVQLjOc/585SSBfiVAmwo2PyIIktMbVHqQ7qMaCWwPKnsqBq+fID/QEQZOOd6cs5e2dmgEaJQX Y539M3FUOUaHW6RvcRYFq2S9+uVL0LXkt78wEA0R1dfWjYIad4VAt/FSgb4lERglBcwTqP7x/ho6 ukO8TH5/T5N5xSbEq9GQH+DvTTL2M/B6kwYjkI9UtV4tcjgHXk396NMTHefyKV7O7sietP112/m4 CN8=
=7J7l
-----END PGP SIGNATURE-----

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

Quoting Fabio Fantoni (2024-08-17 11:20:01)

Il 17/08/2024 10:47, Jonas Smedegaard ha scritto:

Hi Chris,

Quoting Chris Hofstaedtler (2024-08-17 10:17:19)

On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote:

IMO, and from discussions in the Debian Perl Group, the blocker is
the conversion of existing repos, both on salsa (which should be
doable via the API as suggested in the sketches mentioned above) and
also locally for hundreds of developer machines [git fails horribly
on the upstream/ → upstream/latest change].

I want to echo this pain. When changing the layout it seems almost
better to start from scratch.

I have in the past found it confusing how to handle it, but now I find
it tolerable (and don't recognize the "better to start from scratch" judgement), after I figured out (as also hinted at in one of the links
by gregor) that you need to do the following, in that order:

1. unlock branch "upstream" on salsa
2. rename branch "upstream" → "upstream/latest" on salsa (or delete it)

rename branch in salsa would be very handy, i searched for it when i converted some repositories but i didn't find it, can you tell me how to
do it please?

I cannot (I sloppily drop the branch and the republish a moment later),
but please see the links mentioned by Gregor.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============ˆ38736667810377381=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbAdNYACgkQLHwxRsGg ASGsGw//XkW28F0kptwr7ickDt33MIJwZ2JL3r88uxoeXBIVTpCvYRfxULrrkXzj yg4aD5UuYpCpNQyn+5BVK9uu/hiyq3RPXwjJoH9VyZ3T4fuXZqANyIR5pyrs0NXP SXf3o3r5Ks4dF2//G2LyCR+bNV47F71SyKlr5qNUoDM2F4Carw//2QyXGcUwJipX j6I3Bu+TxQSdiRaIgdmt2qQBSpm8KQ32SPNIwng4Ly2G15hfYtqRMKXEOrsOnYe9 CnBDHSIj1qj+wHZ0t6AlnagM0RGl33kPdFGyppdDcqMKFuvbhrIAXjUzXukYJo9J kAUmsqSzlRALmD1YqJeBmhU9q9v4Bb7tJxV2KtaGPDIk3I+8QnQCuQlcM/xaUOuf HX/SDmAz68TDkaR8V93rAz/NGrJbxxiSXtp11AMDi2MvTqX/JnFiA4oZcnSdOUHy OPg3fUgPsKSmLM5SmtxjW/MmTNrrDQlwibeEgcf3

On Sat, 17 Aug 2024 10:47:36 +0200, Jonas Smedegaard wrote:

I have in the past found it confusing how to handle it, but now I find
it tolerable (and don't recognize the "better to start from scratch" judgement), after I figured out (as also hinted at in one of the links
by gregor) that you need to do the following, in that order:

1. unlock branch "upstream" on salsa
2. rename branch "upstream" → "upstream/latest" on salsa (or delete it)
3. rename branch "upstream" → "upstream/latest" locally
4. push local changes to salsa

Then you have an updated repo on salsa and an updated repo on your
machine. The problem is that for everyone else, who has a local clone
of the repo, the next `mr up' or `gbp pull' explodes.


Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-

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

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmbAfPhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgaK4A/+JYAWXVQeyHGJh1TaDmS8sHe98vB4Vgz/raCPNUgcPqH0XGMueLJBMDJb EFaDKHcU/s89nyPdFuQk9Zkb7dROgIeEul9FCNsiWp76FXJID3Q3PDrxsNSfXH5y OclsL5gL5egmNouopHWpshmHnFupWFBjhcIE61krd9+a0xJO3xpo8YBBTxyagCkP +DfvhVfdOVV0D+7su9K5DrHyQuZUhuYYzT2WxixF80ElXOclWxn04VQTTtrx3tZY dW/i889idYxFsAILE+iOtD0TWZLcwULsEPPzDkEDn1KLfVXhI/b5FIxZfl5OBMCq dYxpt3Ak1Qp8D6AANOKOvz9XfSiKSI/L3NcgCZBe+RuaV2RuyNjxCD3yk+quy412 3AA5WGZueu5jglefTy47mtU9+5CUORc2s8n6bGkWHrSCsXeAKXl3QYKlwof7sPzZ 8Q+Qtf3PXOaONnaep8AwbSiXrU4mrdmHsp2WhXvZjcs2LFWFdhZsMrnobVhLGIaJ
YKQBcXw9

Am Sat, Aug 17, 2024 at 10:33:58AM +0200 schrieb Chris Hofstaedtler:

Add the following to the configuration file ~/.gbp.conf or
debian/gbp.conf:

Putting per-repository relevant settings into a global config and
not into the per-repo config seems to fly into the face of the DEP18
spirit.

I'd perfectly follow the DEP-14/DEP-18 spirit since if we have some
common default any specifications inside team policies become void
and we can get rid of those settings in ~/.gbp.conf.

My personal preference would be if we make a pristine-tar branch default
since this is what I observed in the wide majority of cases.

Maybe there is no issue with changing git-buildpackage after all
then.

Yes.

Kind regards
Andreas.

--
https://fam-tille.de

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

Andrey Rakhmatullin <wrar@debian.org> writes:

On Sat, Aug 17, 2024 at 12:20:16PM +0200, Andreas Tille wrote:

My personal preference would be if we make a pristine-tar branch default
since this is what I observed in the wide majority of cases.

Note that there are different opionons whether pristine-tar is needed/viable/useful. There is at least one objective fact that it's hard
to keep working.

Did anyone consider a way to only store meta-information about the
source tarballs in the debian/ tree?

I'm thinking the SHA-256 checksum of the tarball should be recorded and
be part of the signed debian.tar.xz upload.

For example, libidn2's debian/source/artifact could contain:

Checksums-SHA256: 4c21a791b610b9519b9d0e12b8097bf2f359b12f8dd92647611a929e6bfd7d64 2155214 libidn2_2.3.7.orig.tar.gz

Or something like that.

If the debian/ tree contained a SHA-256 checksum of the upstream release artifact, it could be used to locate and retrieve the tarballs using any mechanism available, reducing the need for pristine-tar which is fragile
(how many checks that the checksum of the pristine-tar tarball matches
what's in the debian archive?).

It would also strengthen the integrity of the resulting archive, since
then there is some way to look at a *.debian.tar.* and git debian/ sub-directory and understand what the intended source code it applies to
are.

Manually curating the release artifact checksums is what many other
packaging systems do, and I think it is a good pattern.

/Simon

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

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZsCMtBQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFopKcAQDon03Nk+Cp+nGiHWJdfZZE5g+f+S66 SdxqNntbqF2zNwD/VVk031aFHeQqGOfFPf32gwexXZByiWk9P+PpZ+ZfSQo=
=Nrh0
-----END PGP SIGNATURE-----

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

On Sat, Aug 17, 2024 at 12:20:16PM +0200, Andreas Tille wrote:

My personal preference would be if we make a pristine-tar branch default since this is what I observed in the wide majority of cases.

Note that there are different opionons whether pristine-tar is needed/viable/useful. There is at least one objective fact that it's hard
to keep working.

--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmbAi10tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh HmkP/RI6H0ZZg6VlPYBkIwayphUHDBgKLr7iIKhGb/UuJk+1/HwVod16/rN8hj1K BqZcOwPJocXCgX84ESGk7MGr76T8YLQbHJjjCBd3xsmuwkgNAcxOW7Q1XisX5YkI 8e1k4eobUd/daTojPfhhyvSxVIlcxBdn0rAGkI5q15ft82tNjvgNccn9DvieJJrd ++4Qs2LyU/lWJZT+61I4yhT54Cd3IM/dBYSmNFu58gxCgx7dHjgoQBO1kW+lKT+y q9si28rFCA+Qf+I+U8sQW9+4YPS2ECG6Mc5KcHwuUutW6uiPEIRXy3fi7Z6VE04D FkgnR+9TLb6lr/F0WwJOkN3dsUmi1sjHZHtOcAIH1SNnZF4kfVGfp4E57LLw8QyV SZVzTQhLFDr0GonfJACshvaFTtAwStYhDMvnEtmgdgMoBJHLQVFD+Azyz36KqjG8 3ysy8nhH53ILf8c5+eSq5iQ77U7mYmtgPM5eyqSPhhGok3vlNBrrVxnuXYc/tfc0 Yo8eiZEfL6Un6AKYS3S36zo89HjgS5OerjBrAABMGCgfLEO4H4+1TBXMpubRNC8V SDqXgCqaZU0TbE8PuIaHKSmzvnDfVDzJbh3OcsMI5C5YzQAa095rIrScCzuNs0ZQ +SkWksxCsntNVeE9KBm69I7NdngPnKqJnK+a9UaFTC3eQ662
=TsVL
-----END PGP SIGNATURE-----

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

Additionally, in my opinion debian/latest is a mistake we should not recommend.

Please elaborate why you consider it a mistake. That's not obvious to
me.

"latest" is illnamed. What do you expect to find in a branch thats
called debian/latest?

Packaging for unstable? For experimental? What if both evolve in
parallel? Yes, some packages do that.

Chris

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

On Sat, 17 Aug 2024 at 22:45:59 +0200, Chris Hofstaedtler wrote:

"latest" is illnamed. What do you expect to find in a branch thats
called debian/latest?

Packaging for unstable? For experimental?

For experimental if there's currently a version in experimental (or if
there is about to be one in the near future), or unstable otherwise.

Some maintainers and teams strongly prefer to have one branch for either unstable or experimental, whichever is the current target for uploads
with the latest development. For example, the GNOME team does this:
a new upstream release from upstream's 'main' branch might go to either unstable or experimental, depending on its perceived stability, whether
it involves a SONAME bump or other transition, and where we are in the
Debian release cycle; but either way, it gets there via debian/latest.

If that's what is happening, then debian/latest is an appropriate name for
that single branch, but neither debian/unstable nor debian/experimental
would always be correct, because uploads from debian/latest can go in
either of those directions.

(In the GNOME team's case, if GNOME 47 prereleases are already in
debian/latest and experimental, but a new GNOME-46-based upload becomes necessary to fix bugs in testing/unstable and the GNOME-47-based release
isn't ready yet, we'll use a relatively short-lived debian/unstable or debian/trixie branch for that.)

What if both evolve in parallel? Yes, some packages do that.

If that's the case then using debian/latest for uploads to unstable would
be inappropriate, because those uploads are not, in fact, the latest.

There are two valid approaches to this. One is to use be debian/unstable
and debian/experimental (like I do in src:flatpak and src:dbus), and not
have a debian/latest branch at all. The other is to use debian/latest
for experimental, and debian/unstable (or possibly debian/trixie) for
uploads to unstable, more like way the GNOME team works.

DEP-14 allows either of those approaches.

smcv

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

Chris Hofstaedtler <zeha@debian.org> writes:

"latest" is illnamed. What do you expect to find in a branch thats
called debian/latest?

Packaging for unstable? For experimental? What if both evolve in
parallel? Yes, some packages do that.

We discussed this a lot during the drafting of DEP14, and the reason why
the standard allows either convention is that it depends on the package
and there were two separate perspectives with no consensus that one was universally better.

Maintainers of some packages that upload to unstable except during
freezes, during which they temporarily move into experimental, but
consider it the same line of development, and then move back into unstable after the release preferred debian/latest since it matched how they
thought about the line of development. People who maintained separate
unstable and experimental lines of development preferred debian/unstable
and debian/experimental.

Personally, I use debian/unstable but do experimental development in that
same branch if it's "targeting unstable," which is either the best or
worst of both worlds, depending on your perspective.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

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

Quoting Chris Hofstaedtler (2024-08-17 22:45:59)

Additionally, in my opinion debian/latest is a mistake we should
not recommend.

Please elaborate why you consider it a mistake. That's not obvious
to me.

"latest" is illnamed.

Thanks for that (small) elaboration.

What do you expect to find in a branch thats called debian/latest?

Packaging for unstable? For experimental? What if both evolve in
parallel? Yes, some packages do that.

I expect that the latest *long-term* changes to reside in debian/latest, whereas debian/unstable and debian/experimental I expect to contain
short-lived deviations. Just as is described in DEP-14.

I find that sensible: Sometimes I temporarily push my long-term work to experimental, and keep the git branch name. Except then maybe, while
that long-term work is still settling (maybe testsuite fails, or maybe
it is waiting for NEW queue approval) a need arise for a quick fix
targeted unstable, in which case I branch off as debian/unstable
temporararily.

Other times I make an experiment, i.e. something that I don't expect
will last, in which case I right away branch off as debian/experimental.


Kind regards,

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============`29861146307723222=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIyBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbBFlAACgkQLHwxRsGg ASHeGA/47VYiCLSAxRDOZ+4loWiHBnahFE36Xso+2HKRDM3ZXjmU45hlFizFuEiv 8ZtdsxefihMl7ZA7NXp2SqQeqwu1rIJ+SWJrIH/iAHlI2qQrL+R7V2uICEYBrKfV VMct8tS27Yd6Aa4iotzDlvxzDvQDlZSFAmEgNrUvpIjpZ4Sh6Yx75N7/BhujT311 EdNXTYwgWzisdmWY8w0QZKLZloSnrAeMGIn+dSMZHRm9wBYPObcgqc8oe1RCVsGo 4EiJ9R9DeV+25jq2B6fS5Xi0e1RD+TJBDekh/3lY5qNpS58dtjzYX9tUdy/Ibipq 0TnkP4jd0PkXIcQrcyPb/VWMmstwnmV7hc6mxUkfhGXCD+v1jIecyzue9E6Lx7bf j6KlXcSnFtPyxEkP/b0SecCFmj/0psdQpfGw7f+A/yNxt/ovS1B/HTzKVgYAF2zu JiD8QARuskB9TLgNpX0I6US6NATki+/zdEd+y7Uc

To: debian-devel@lists.debian.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------tmLXnY9jOlPNqeoJEZX5jIir
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SWwgMTcvMDgvMjAyNCAxMjowMCwgSm9uYXMgU21lZGVnYWFyZCBoYSBzY3JpdHRvOg0KPiBR dW90aW5nIEZhYmlvIEZhbnRvbmkgKDIwMjQtMDgtMTcgMTE6MjA6MDEpDQo+PiBJbCAxNy8w OC8yMDI0IDEwOjQ3LCBKb25hcyBTbWVkZWdhYXJkIGhhIHNjcml0dG86DQo+Pj4gSGkgQ2hy aXMsDQo+Pj4NCj4+PiBRdW90aW5nIENocmlzIEhvZnN0YWVkdGxlciAoMjAyNC0wOC0xNyAx MDoxNzoxOSkNCj4+Pj4gT24gRnJpLCAxNiBBdWcgMjAyNCAyMzozNjozMSArMDIwMCwgZ3Jl Z29yIGhlcnJtYW5uIHdyb3RlOg0KPj4+Pj4gSU1PLCBhbmQgZnJvbSBkaXNjdXNzaW9ucyBp biB0aGUgRGViaWFuIFBlcmwgR3JvdXAsIHRoZSBibG9ja2VyIGlzDQo+Pj4+PiB0aGUgY29u dmVyc2lvbiBvZiBleGlzdGluZyByZXBvcywgYm90aCBvbiBzYWxzYSAod2hpY2ggc2hvdWxk IGJlDQo+Pj4+PiBkb2FibGUgdmlhIHRoZSBBUEkgYXMgc3VnZ2VzdGVkIGluIHRoZSBza2V0 Y2hlcyBtZW50aW9uZWQgYWJvdmUpIGFuZA0KPj4+Pj4gYWxzbyBsb2NhbGx5IGZvciBodW5k cmVkcyBvZiBkZXZlbG9wZXIgbWFjaGluZXMgW2dpdCBmYWlscyBob3JyaWJseQ0KPj4+Pj4g b24gdGhlIHVwc3RyZWFtLyDihpIgdXBzdHJlYW0vbGF0ZXN0IGNoYW5nZV0uDQo+Pj4+IEkg d2FudCB0byBlY2hvIHRoaXMgcGFpbi4gV2hlbiBjaGFuZ2luZyB0aGUgbGF5b3V0IGl0IHNl ZW1zIGFsbW9zdA0KPj4+PiBiZXR0ZXIgdG8gc3RhcnQgZnJvbSBzY3JhdGNoLg0KPj4+IEkg aGF2ZSBpbiB0aGUgcGFzdCBmb3VuZCBpdCBjb25mdXNpbmcgaG93IHRvIGhhbmRsZSBpdCwg YnV0IG5vdyBJIGZpbmQNCj4+PiBpdCB0b2xlcmFibGUgKGFuZCBkb24ndCByZWNvZ25pemUg dGhlICJiZXR0ZXIgdG8gc3RhcnQgZnJvbSBzY3JhdGNoIg0KPj4+IGp1ZGdlbWVudCksIGFm dGVyIEkgZmlndXJlZCBvdXQgKGFzIGFsc28gaGludGVkIGF0IGluIG9uZSBvZiB0aGUgbGlu a3MNCj4+PiBieSBncmVnb3IpIHRoYXQgeW91IG5lZWQgdG8gZG8gdGhlIGZvbGxvd2luZywg aW4gdGhhdCBvcmRlcjoNCj4+Pg0KPj4+ICAgIDEuIHVubG9jayBicmFuY2ggInVwc3RyZWFt IiBvbiBzYWxzYQ0KPj4+ICAgIDIuIHJlbmFtZSBicmFuY2ggInVwc3RyZWFtIiDihpIgInVw c3RyZWFtL2xhdGVzdCIgb24gc2Fsc2EgKG9yIGRlbGV0ZSBpdCkNCj4+IHJlbmFtZSBicmFu Y2ggaW4gc2Fsc2Egd291bGQgYmUgdmVyeSBoYW5keSwgaSBzZWFyY2hlZCBmb3IgaXQgd2hl biBpDQo+PiBjb252ZXJ0ZWQgc29tZSByZXBvc2l0b3JpZXMgYnV0IGkgZGlkbid0IGZpbmQg aXQsIGNhbiB5b3UgdGVsbCBtZSBob3cgdG8NCj4+IGRvIGl0IHBsZWFzZT8NCj4gSSBjYW5u b3QgKEkgc2xvcHBpbHkgZHJvcCB0aGUgYnJhbmNoIGFuZCB0aGUgcmVwdWJsaXNoIGEgbW9t ZW50IGxhdGVyKSwNCj4gYnV0IHBsZWFzZSBzZWUgdGhlIGxpbmtzIG1lbnRpb25lZCBieSBH cmVnb3IuDQo+DQo+ICAgLSBKb25hcw0KPg0KSSB0cmllZCB1c2luZyBzYWxzYSBjbGkgdG9v bCBmcm9tIEdyZWdvciBsaW5rIGJ1dCByZW5hbWUgb2YgdXBzdHJlYW0gDQpicmFuY2ggZmFp bGVkLg0KDQpJIGRpZCB0aGlzIHRyeWluZyBvbiBvbmUgcHJvamVjdDoNCg0Kc2Fsc2EgLS1n cm91cCBjaW5uYW1vbi10ZWFtIHByb3RlY3RfYnJhbmNoIHhhcHAgbWFzdGVyIG5vDQpzYWxz YSAtLXZlcmJvc2UgLS1ncm91cCBjaW5uYW1vbi10ZWFtIHJlbmFtZV9icmFuY2ggeGFwcCAN Ci0tc291cmNlLWJyYW5jaD1tYXN0ZXIgLS1kZXN0LWJyYW5jaD1kZWJpYW4vbGF0ZXN0DQoj IHRoaXMgZmFpbGVkIHRvIGRlbGV0ZSBtYXN0ZXIsIGNoYW5nZWQgZGVmYXVsdCBicmFuY2gg ZnJvbSBzYWxzYSANCndlYnNpdGUgKGluIFNldHRpbmdzLT5SZXBvc2l0b3J5KSBhbmQgZGVs ZXRlZCBtYXN0ZXIgYnJhbmNoIChmcm9tIHdlYnNpdGUpDQpzYWxzYSAtLWdyb3VwIGNpbm5h bW9uLXRlYW0gcHJvdGVjdF9icmFuY2ggeGFwcCBkZWJpYW4vbGF0ZXN0IG0gZA0KDQojIGFm dGVyIHRoZXNlIHRoZSBjb252ZXJzaW9uIGZyb20gbWFzdGVyIHRvIGRlYmlhbi9sYXRlc3Qg c2VlbXMgY29ycmVjdCwgDQpyZW5hbWUgb2YgdXBzdHJlYW0gYnJhbmNoIGluc3RlYWQgZmFp bHMNCg0Kc2Fsc2EgLS12ZXJib3NlIC0tbm8tZmFpbCAtLWdyb3VwIGNpbm5hbW9uLXRlYW0g cmVuYW1lX2JyYW5jaCB4YXBwIA0KLS1zb3VyY2UtYnJhbmNoPXVwc3RyZWFtIC0tZGVzdC1i cmFuY2g9dXBzdHJlYW0vbGF0ZXN0DQpzYWxzYSBpbmZvOiBjaW5uYW1vbi10ZWFtIGlkIGlz IDI5OTINCnNhbHNhIGluZm86IFByb2plY3QgeGFwcCA9PiBjaW5uYW1vbi10ZWFtL3hhcHAN CnNhbHNhIGluZm86IGNpbm5hbW9uLXRlYW0veGFwcCBpZCBpcyAxNzcxMA0Kc2Fsc2EgaW5m bzogQ29uZmlndXJpbmcgeGFwcA0Kc2Fsc2Egd2FybjogQnJhbmNoIHJlbmFtZSBoYXMgZmFp bGVkIGZvciB4YXBwDQpzYWxzYSBpbmZvOiBFcnJvciBQT1NUaW5nIA0KaHR0cHM6Ly9zYWxz YS5kZWJpYW4ub3JnL2FwaS92NC9wcm9qZWN0cy8xNzcxMC9yZXBvc2l0b3J5L2JyYW5jaGVz IChIVFRQIA0KNDAwKTogQmFkIFJlcXVlc3QgeyJtZXNzYWdlIjoiRmFpbGVkIHRvIGNyZWF0 ZSBicmFuY2ggJ3Vwc3RyZWFtL2xhdGUuLi4gDQphdCAvdXNyL3NoYXJlL3Blcmw1L0RldnNj cmlwdHMvU2Fsc2EvcmVuYW1lX2JyYW5jaC5wbSBsaW5lIDI2Lg0KDQpFcnJvciBhYm92ZSBv biBTaWQgd2l0aCBkZXZzY3JpcHRzIDIuMjMuNyBidXQgSSB0cmllZCBhbHNvIG9uIG9sZGVy IHN5c3RlbQ0KDQpTb21lb25lIGhhZCByZW5hbWUgb2YgdXBzdHJlYW0gYnJhbmNoIHdvcmtp bmc/DQoNCg==

--------------tmLXnY9jOlPNqeoJEZX5jIir--

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

wsF5BAABCAAjFiEELEHRfLe4S9D5+1GzaAZorpB/EB0FAmbB/FMFAwAAAAAACgkQaAZorpB/EB29 ZRAAosDEbCHXpqbKQ61iSzOIT8Ukf9b9IFqDx2yJwGhWPTjHaYf+ZEvfJaLUAZuzqFu/10+GIVCH 6UsUQG+m1JU5gzWh2C3lHAC5fzWH3DQSqUNJb4c4a1XYW5vpsMbVdZtYDbaezqTl4CTuXFas9OQy bMBOhlRo785Z4kYvnnfXqsw+Q5U7j+zt/IDC6zhp420pRkeCSK4wXO/cTZe8FwkQjHHU7DoEXuka BFVheudMa1xAzOQJT/x/AZLatwUb0ke+7V4KZK9BWYIEQKMeJwjULxRmcJqB73pPLqI09IeDXVdt 2Z39EEnvGyqoem+S5XmLSB9L7puU2402BgSJ1ZXc2DtnqESHNc8e1jqgDf8cg527qeDUAuQaWYgu QZgXTQXlkIdROSDre/2EBwKdLsn3zw9Pa+cUIU3X4betcTwbYKDlTslu8ajnhV2JPAzTiw09jJQK LIAuyeRz6qhHjLwrfFCO/nC2ls92uxnYpDUQlaLRVST8qg55TFd3QTavhBigPjRFkOX5WMyKuntE VJfux1JKvT9K2dbbZn9SnhuFL70LpjrAP4b22v8Q2NcufS+b1yHoIu64znXdjgCqsdIDytofH8aR W7Mm2ZpTOoU+Xl8k8hi8cu3JNFbv8dcIiyXjMPX3qKf12OjmulvQJh2bleK+fm0mEn+Gnc3INR0e Dno=
=LBPx
-----END PGP SIGNATURE-----

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

To: debian-devel@lists.debian.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------reXjxzgtsjQLLUzrsnqJkw53
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SWwgMTgvMDgvMjAyNCAxNTo1MSwgRmFiaW8gRmFudG9uaSBoYSBzY3JpdHRvOg0KPiBJbCAx Ny8wOC8yMDI0IDEyOjAwLCBKb25hcyBTbWVkZWdhYXJkIGhhIHNjcml0dG86DQo+PiBRdW90 aW5nIEZhYmlvIEZhbnRvbmkgKDIwMjQtMDgtMTcgMTE6MjA6MDEpDQo+Pj4gSWwgMTcvMDgv MjAyNCAxMDo0NywgSm9uYXMgU21lZGVnYWFyZCBoYSBzY3JpdHRvOg0KPj4+PiBIaSBDaHJp cywNCj4+Pj4NCj4+Pj4gUXVvdGluZyBDaHJpcyBIb2ZzdGFlZHRsZXIgKDIwMjQtMDgtMTcg MTA6MTc6MTkpDQo+Pj4+PiBPbiBGcmksIDE2IEF1ZyAyMDI0IDIzOjM2OjMxICswMjAwLCBn cmVnb3IgaGVycm1hbm4gd3JvdGU6DQo+Pj4+Pj4gSU1PLCBhbmQgZnJvbSBkaXNjdXNzaW9u cyBpbiB0aGUgRGViaWFuIFBlcmwgR3JvdXAsIHRoZSBibG9ja2VyIGlzDQo+Pj4+Pj4gdGhl IGNvbnZlcnNpb24gb2YgZXhpc3RpbmcgcmVwb3MsIGJvdGggb24gc2Fsc2EgKHdoaWNoIHNo b3VsZCBiZQ0KPj4+Pj4+IGRvYWJsZSB2aWEgdGhlIEFQSSBhcyBzdWdnZXN0ZWQgaW4gdGhl IHNrZXRjaGVzIG1lbnRpb25lZCBhYm92ZSkgYW5kDQo+Pj4+Pj4gYWxzbyBsb2NhbGx5IGZv ciBodW5kcmVkcyBvZiBkZXZlbG9wZXIgbWFjaGluZXMgW2dpdCBmYWlscyBob3JyaWJseQ0K Pj4+Pj4+IG9uIHRoZSB1cHN0cmVhbS8g4oaSIHVwc3RyZWFtL2xhdGVzdCBjaGFuZ2VdLg0K Pj4+Pj4gSSB3YW50IHRvIGVjaG8gdGhpcyBwYWluLiBXaGVuIGNoYW5naW5nIHRoZSBsYXlv dXQgaXQgc2VlbXMgYWxtb3N0DQo+Pj4+PiBiZXR0ZXIgdG8gc3RhcnQgZnJvbSBzY3JhdGNo Lg0KPj4+PiBJIGhhdmUgaW4gdGhlIHBhc3QgZm91bmQgaXQgY29uZnVzaW5nIGhvdyB0byBo YW5kbGUgaXQsIGJ1dCBub3cgSSBmaW5kDQo+Pj4+IGl0IHRvbGVyYWJsZSAoYW5kIGRvbid0 IHJlY29nbml6ZSB0aGUgImJldHRlciB0byBzdGFydCBmcm9tIHNjcmF0Y2giDQo+Pj4+IGp1 ZGdlbWVudCksIGFmdGVyIEkgZmlndXJlZCBvdXQgKGFzIGFsc28gaGludGVkIGF0IGluIG9u ZSBvZiB0aGUgbGlua3MNCj4+Pj4gYnkgZ3JlZ29yKSB0aGF0IHlvdSBuZWVkIHRvIGRvIHRo ZSBmb2xsb3dpbmcsIGluIHRoYXQgb3JkZXI6DQo+Pj4+DQo+Pj4+IMKgwqAgMS4gdW5sb2Nr IGJyYW5jaCAidXBzdHJlYW0iIG9uIHNhbHNhDQo+Pj4+IMKgwqAgMi4gcmVuYW1lIGJyYW5j aCAidXBzdHJlYW0iIOKGkiAidXBzdHJlYW0vbGF0ZXN0IiBvbiBzYWxzYSAob3IgDQo+Pj4+ IGRlbGV0ZSBpdCkNCj4+PiByZW5hbWUgYnJhbmNoIGluIHNhbHNhIHdvdWxkIGJlIHZlcnkg aGFuZHksIGkgc2VhcmNoZWQgZm9yIGl0IHdoZW4gaQ0KPj4+IGNvbnZlcnRlZCBzb21lIHJl cG9zaXRvcmllcyBidXQgaSBkaWRuJ3QgZmluZCBpdCwgY2FuIHlvdSB0ZWxsIG1lIA0KPj4+ IGhvdyB0bw0KPj4+IGRvIGl0IHBsZWFzZT8NCj4+IEkgY2Fubm90IChJIHNsb3BwaWx5IGRy b3AgdGhlIGJyYW5jaCBhbmQgdGhlIHJlcHVibGlzaCBhIG1vbWVudCBsYXRlciksDQo+PiBi dXQgcGxlYXNlIHNlZSB0aGUgbGlua3MgbWVudGlvbmVkIGJ5IEdyZWdvci4NCj4+DQo+PiDC oCAtIEpvbmFzDQo+Pg0KPiBJIHRyaWVkIHVzaW5nIHNhbHNhIGNsaSB0b29sIGZyb20gR3Jl Z29yIGxpbmsgYnV0IHJlbmFtZSBvZiB1cHN0cmVhbSANCj4gYnJhbmNoIGZhaWxlZC4NCj4N Cj4gSSBkaWQgdGhpcyB0cnlpbmcgb24gb25lIHByb2plY3Q6DQo+DQo+IHNhbHNhIC0tZ3Jv dXAgY2lubmFtb24tdGVhbSBwcm90ZWN0X2JyYW5jaCB4YXBwIG1hc3RlciBubw0KPiBzYWxz YSAtLXZlcmJvc2UgLS1ncm91cCBjaW5uYW1vbi10ZWFtIHJlbmFtZV9icmFuY2ggeGFwcCAN Cj4gLS1zb3VyY2UtYnJhbmNoPW1hc3RlciAtLWRlc3QtYnJhbmNoPWRlYmlhbi9sYXRlc3QN Cj4gIyB0aGlzIGZhaWxlZCB0byBkZWxldGUgbWFzdGVyLCBjaGFuZ2VkIGRlZmF1bHQgYnJh bmNoIGZyb20gc2Fsc2EgDQo+IHdlYnNpdGUgKGluIFNldHRpbmdzLT5SZXBvc2l0b3J5KSBh bmQgZGVsZXRlZCBtYXN0ZXIgYnJhbmNoIChmcm9tIA0KPiB3ZWJzaXRlKQ0KPiBzYWxzYSAt LWdyb3VwIGNpbm5hbW9uLXRlYW0gcHJvdGVjdF9icmFuY2ggeGFwcCBkZWJpYW4vbGF0ZXN0 IG0gZA0KPg0KPiAjIGFmdGVyIHRoZXNlIHRoZSBjb252ZXJzaW9uIGZyb20gbWFzdGVyIHRv IGRlYmlhbi9sYXRlc3Qgc2VlbXMgDQo+IGNvcnJlY3QsIHJlbmFtZSBvZiB1cHN0cmVhbSBi cmFuY2ggaW5zdGVhZCBmYWlscw0KPg0KPiBzYWxzYSAtLXZlcmJvc2UgLS1uby1mYWlsIC0t Z3JvdXAgY2lubmFtb24tdGVhbSByZW5hbWVfYnJhbmNoIHhhcHAgDQo+IC0tc291cmNlLWJy YW5jaD11cHN0cmVhbSAtLWRlc3QtYnJhbmNoPXVwc3RyZWFtL2xhdGVzdA0KPiBzYWxzYSBp bmZvOiBjaW5uYW1vbi10ZWFtIGlkIGlzIDI5OTINCj4gc2Fsc2EgaW5mbzogUHJvamVjdCB4 YXBwID0+IGNpbm5hbW9uLXRlYW0veGFwcA0KPiBzYWxzYSBpbmZvOiBjaW5uYW1vbi10ZWFt L3hhcHAgaWQgaXMgMTc3MTANCj4gc2Fsc2EgaW5mbzogQ29uZmlndXJpbmcgeGFwcA0KPiBz YWxzYSB3YXJuOiBCcmFuY2ggcmVuYW1lIGhhcyBmYWlsZWQgZm9yIHhhcHANCj4gc2Fsc2Eg aW5mbzogRXJyb3IgUE9TVGluZyANCj4gaHR0cHM6Ly9zYWxzYS5kZWJpYW4ub3JnL2FwaS92 NC9wcm9qZWN0cy8xNzcxMC9yZXBvc2l0b3J5L2JyYW5jaGVzIA0KPiAoSFRUUCA0MDApOiBC YWQgUmVxdWVzdCB7Im1lc3NhZ2UiOiJGYWlsZWQgdG8gY3JlYXRlIGJyYW5jaCANCj4gJ3Vw c3RyZWFtL2xhdGUuLi4gYXQgDQo+IC91c3Ivc2hhcmUvcGVybDUvRGV2c2NyaXB0cy9TYWxz YS9yZW5hbWVfYnJhbmNoLnBtIGxpbmUgMjYuDQo+DQo+IEVycm9yIGFib3ZlIG9uIFNpZCB3 aXRoIGRldnNjcmlwdHMgMi4yMy43IGJ1dCBJIHRyaWVkIGFsc28gb24gb2xkZXIgDQo+IHN5 c3RlbQ0KPg0KPiBTb21lb25lIGhhZCByZW5hbWUgb2YgdXBzdHJlYW0gYnJhbmNoIHdvcmtp bmc/DQo+DQpmaXhlZCBkb2luZyB0aGlzIHdvcmthcm91bmQ6DQoNCnNhbHNhIC0tdmVyYm9z ZSAtLW5vLWZhaWwgLS1ncm91cCBjaW5uYW1vbi10ZWFtIHJlbmFtZV9icmFuY2ggeGFwcCAN Ci0tc291cmNlLWJyYW5jaD11cHN0cmVhbSAtLWRlc3QtYnJhbmNoPXVwc3RyZWFtLXRtcA0K DQpzYWxzYSAtLXZlcmJvc2UgLS1uby1mYWlsIC0tZ3JvdXAgY2lubmFtb24tdGVhbSByZW5h bWVfYnJhbmNoIHhhcHAgDQotLXNvdXJjZS1icmFuY2g9dXBzdHJlYW0tdG1wIC0tZGVzdC1i cmFuY2g9dXBzdHJlYW0vbGF0ZXN0DQoNCmFmdGVyIHNhdyB0aGlzIA0KKGh0dHBzOi8vZ29i YnkuZGViaWFuLm9yZy9leHBvcnQvVGVhbXMvUGVybC9uZXctYnJhbmNoLWxheW91dCkgcHJv YmFibHkgDQp3aXRoIC0tcmVuYW1lLWhlYWQgY2FuIGF2b2lkIGVycm9yIG9uIG1hc3RlciBk ZWxldGUgYW5kIG1ha2UgdGhlIA0KcHJvY2VkdXJlIGZhc3RlciAobm90IHRlc3RlZCBub3cp DQoNCg==

--------------reXjxzgtsjQLLUzrsnqJkw53--

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

wsF5BAABCAAjFiEELEHRfLe4S9D5+1GzaAZorpB/EB0FAmbDeU8FAwAAAAAACgkQaAZorpB/EB2c wBAAgCGn0UkczBQkaNq+/nh0dnpDfBmw8gp6/oKjhO2r4nDK+xNyEWrZtffeHrfs2DPQpxAoRG+x 8uSou4zn+ctic6bjr5+FgQIZTL1v18V32VTT6q3Uu5sXGNReWrHscqiwGV0EiRRXdWeVNYvyNjsx 9fUFM8v3+pCaYuiHNQpjrHM/XGiElAdU0GhhMujRa1pTjha69PJ6dLRViaRMwg2t92BeJnWKJqTs MZ+VwU3syZJwT8QGAWK83c2+YSynbXLK8xzUO+GNww33lWlm4NCsAQHDPdvzN8hDQpNhNz6Vlow9 7WuNTg0fXL2NM1JYaRQOqSTFKtieEM/qkDw9JghwOlHJQkhAU58ykha9YrnJstCuVkoPg7O6m3WF HB8lwklg53n82F3BL8wv3KRh8orOErsO+DdbV2BXZUpUdZq1OvQTV/mL+kEIjdpbrkfJDyVVnOAX Ag3yLQ8tqZAY4I0G4PI/ooI9iMLcYj+cvKS4HwkyeAtS7IYL1gXxqKjPHIAdTu2Ksi53xUZXVn9w 7IRdEyecGfQnJNAdNLEHCwL0HT/Ow3icuG1XiKrTSxpq38stQlD0e1IvI/75mETH37WAQll48ufP A89pOQVyX2A8VRnu6S0Py0PtvdGgp3nJvxtXq6p4r5h2ZxSnjE2/u9cxV2CuM2FaMxswgjkRnlaL 100=
=LWu9
-----END PGP SIGNATURE-----

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