XPost: linux.debian.devel.release, linux.debian.maint.boot

Hi,

Sorry to bother you again with such a question. This should be the last
of them, as I went through all the wishlist items (set up to track d-i
trixie things) people have been gathering lately.

We've had people prepare tasksel merge requests for two new desktop environments, Lomiri and Phosh. Long story short, submitters thought
filing merge requests would be enough, didn't ping the team through mail
or through the BTS before the soft freeze, and we're way past the “no
new package in testing” point. Oops! :(

https://salsa.debian.org/installer-team/tasksel/-/merge_requests/30 [Lomiri]
https://salsa.debian.org/installer-team/tasksel/-/merge_requests/29 [Phosh]

From what I've just gathered, both desktop environments are supposed to
be in a good shape already (i.e. we're not talking about building
something new, from scratch, with bad or unknown quality), and at least
one of them is planning on asking for an exception on the debian-edu
side anyway (for education-desktop-lomiri).

Unfortunately, https://lists.debian.org/debian-boot/2025/05/ seems to
be stuck at 12:20 GMT Sat May 24, so I cannot link to the mail thread…
The following would give you the thread though:

ssh master.debian.org -t mutt -f /home/debian/lists/debian-boot/debian-boot.202505
l lomiri <enter>


I'm very ambivalent about this: there was some kind of lack of noticing
on the installer team part (but then as I explained in one of my
follow-ups, I don't think it's fair to expect people to notice and/or
act on all bug reports in the first place, even less so on merge
requests), but also some kind of a failure on the submitter side, not
poking us before the soft freeze began…

Besides feeling a bit guilty about the situation, I don't have any
strong opinion regarding what to do, so I thought I'd ask what you
think, and go with whatever decision you come up with: if the release
team calls this “too late, no good reason to deviate from the freeze policy”, I'm perfectly fine with it; if the release team is fine with an exception, I'm happy to get that reviewed, merged, and uploaded.

In the worst case, if we were to discover some incredibly bad install experience for one or both of them, we could probably hide them from
the selection screen, without fiddling with the package list again.

[ I'm cc-ing debian-cd@ in case they have some arguments against those
possible additions. As mentioned in some other reply, I think the main desktop-related topic we've had in the past was when we were building
(some) desktop-specific images, but we're no longer doing that. ]


Thanks for your time, and sorry again for the extra ping.


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmgzUPMACgkQ/5FK8MKz VSCCVhAApc1SZIdgWr1E/ZfCk0377se/dePOiHiRNcKKuEi5wwJyk2xiNt6NUgyR LgJsrtdSDrE2wzs3PgQ9DrrDOOuJoIYvOkdR8JBn0YH1AjoKqHv3BTrXU5udazAk IncjrQDizS7Cgh5+BYPNCbwKUnVAe47iqrx2pnGn3xzzPtO9ilFUKHmKUrRQ9tAO f3GUa03HCnzMq8F4uyv4CgnUfhJh9eV/GJyDTF//Kc9tSaZjc/0WwoKN2AEWOUZp YYhOhbqv8FUhjgqKvY5RZW8FDncFWiq5Ksv2n9Lbpfocfvn5KrDb7BycOooWNmKd nKAuA+i6uqYQaqeMLOPiTsLdemrKVnDfasuJzdzYIwgd2D22Jyxvhin/TDlt1vUM OtmUup30tCQ+1f3m+iCjp1MRk9SNLkWJdqfNwu4aTzdNL6GqVXSQoMOR4WpoyGai wSPecozZUOyGYId0QbQnAAJaBJiySfFzogiBgwgk02vlFaYbpHsM/ssKvt47L5RR YMHKAky/G+/dKXOCM59fUKWAQiO9js3yDve1on3aEXsKicAzzS2PyoLmIce74WXV Ob+6dWSpZtO05htAiojf4lgX5hgR/TE9MsJHFPuXEtslJ6c8sQmVjkvduqy6SYEU M+VyM14NdaIEC87binlgQ6jCdawce2wdcv0HJyMaV9KPZi7XpqQ=
=XTRX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.devel.release, linux.debian.maint.boot

Hi,

Here's an update on this:

Cyril Brulebois <[email protected]> (2025-05-25):

From what I've just gathered, both desktop environments are supposed to
be in a good shape already (i.e. we're not talking about building
something new, from scratch, with bad or unknown quality), and at least
one of them is planning on asking for an exception on the debian-edu
side anyway (for education-desktop-lomiri).

(https://lists.debian.org/debian-boot/2025/05/msg00411.html)

----

There was some feedback by various team members, which led me to try and integrate both branches in a suitable way, and if a green light were to
be given, we should be ready:

- https://lists.debian.org/debian-boot/2025/05/msg00484.html
(proposed integration)
- https://lists.debian.org/debian-boot/2025/05/msg00486.html
(Guido Günther, for Phosh)
- https://lists.debian.org/debian-boot/2025/05/msg00496.html
(Mike Gabriel, for Lomiri)

Both teams seem to be fine with the results, and that should also
address initial concerns regarding automated testing (inserting new
desktop environments into random spots would require updating the tests
to ensure picking the right entry…):

- https://lists.debian.org/debian-boot/2025/05/msg00481.html

I'm very ambivalent about this: there was some kind of lack of noticing
on the installer team part (but then as I explained in one of my
follow-ups, I don't think it's fair to expect people to notice and/or
act on all bug reports in the first place, even less so on merge
requests), but also some kind of a failure on the submitter side, not
poking us before the soft freeze began…

Besides feeling a bit guilty about the situation, I don't have any
strong opinion regarding what to do, so I thought I'd ask what you
think, and go with whatever decision you come up with: if the release
team calls this “too late, no good reason to deviate from the freeze policy”, I'm perfectly fine with it; if the release team is fine with an exception, I'm happy to get that reviewed, merged, and uploaded.

I'm still ambivalent about this, and I still don't want to push in
either direction. I'll just mention that reviewing, merging, and
also adjusting… is all done as far as I'm concerned.

The remaining question is whether that's for trixie or forky.

In the worst case, if we were to discover some incredibly bad install experience for one or both of them, we could probably hide them from
the selection screen, without fiddling with the package list again.

I know how to show/hide and mark/unmark, in d-i and outside now… so I'm
now certain we can do that. :)

Thanks for your time, and sorry again for the extra ping.

Still true…


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmg1xVsACgkQ/5FK8MKz VSBHsQ//Tf0QRrDg4srcrWTAPOH5BwLOfXXPwnVm1rgod+wjq/q7IjtjxzO3wX/n 08lm/J5JdkTzy75gkREqW3kfID9T+aiLgdjVwc7OWoWxxf/jS4002hKJJ35uLgMZ DBFe1ZUDwP6w0Y1qMxWxecGX7HrclKmbOaZ1TmGhhC82fx6WYuw5Y/QiFsVRSlYr kIOVrIAH0yAu7vIiVkB4azQtXmGZfn3iVPyH0apTuLxLrBSxXJ8a68Hda9zvvuud avwCJkoHbWwMPwd5V5r68SHeZygTrBGYucY7ksAKP/oQAdu/4jQ9JBkUwcS63R5r 00A+j+dVf9fzYNVyt4jFNS7PpfbOJLzXJs8kA3CM6Cm05EggBrT4bocaaoEYDEXA gTTQwB/rxbUmk7XY1+IxcGQxn0MC7rvsfqNGHhEfWVr7hBvmDXunsMDWoOesDoYS TbvuzFmUy1zvQgx1996fTxhZJ6D86qpJnz+jzY3XNjbXWgSWWF0TaZdo86zvKpbe cdnjk9QZcMy+q6Wn6F1IVZjAbbvhIlifCCrTyLfh/Nl8UYPC7iWN3wZmKNXsGqRB 4wJEnVNmpTklS9fE+zBsOnNc8kRcYHL6LXY4F34Ih/AkcjqLlHGQFrJJc8ruGC8n LAD0rKk1F/k8LnH55zFmZtWsESNXAfjhwD0Mn6bBY/fhc4iDUt4=
=WhKn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.devel.release, linux.debian.maint.boot
To: [email protected]
Copy: [email protected]
Copy: [email protected]

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

SGksDQoNCk9uIDI3LTA1LTIwMjUgMTU6NTksIEN5cmlsIEJydWxlYm9pcyB3cm90ZToNCj4g SSdtIHN0aWxsIGFtYml2YWxlbnQgYWJvdXQgdGhpcywgYW5kIEkgc3RpbGwgZG9uJ3Qgd2Fu dCB0byBwdXNoIGluDQo+IGVpdGhlciBkaXJlY3Rpb24uIEknbGwganVzdCBtZW50aW9uIHRo YXQgcmV2aWV3aW5nLCBtZXJnaW5nLCBhbmQNCj4gYWxzbyBhZGp1c3RpbmfigKYgaXMgYWxs IGRvbmUgYXMgZmFyIGFzIEknbSBjb25jZXJuZWQuDQo+IA0KPiBUaGUgcmVtYWluaW5nIHF1 ZXN0aW9uIGlzIHdoZXRoZXIgdGhhdCdzIGZvciB0cml4aWUgb3IgZm9ya3kuDQoNCg0KSSdt IGFzc3VtaW5nIHRoYXQgaWYgd2Ugd2VyZSB0byBhY2NlcHQgdGhpcywgd2UnZCBlbmxhcmdl IHRoZSBrZXkgDQpwYWNrYWdlIHNldC4gTGV0J3Mgbm90IGRvIHRoYXQgdGhpcyBsYXRlIGlu IHRoZSBjeWNsZS4NCg0KUGF1bA0KDQo=

--------------xkwcgsD2f0nDU61EzsOfX8ma--

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

wsC7BAABCABvBYJoN16aCRCcXJnrBb11CkcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmeTakZbzDGTg6JMkX94wU7QXdii5f0KM6DJ70n92Cpg FxYhBFi2bUhza+k7BS3mcpxcmesFvXUKAABuwQgAp+aR/AiOEIoAEROcDdt2O4ml F0odqNJXmuUxGxaFV7H9RM/4Qo0nHi8VCAK2nU6Wsubnajl62rJp9WQzn0I7ylzJ v4eOtTxBcw/ZO01EZ3ca+bdKGVK0tB3/5beF4FmZXIS/3+5oeMAtunzlwgIh728h hSB4OQV7+kfNlbw21j1tzl6Qvz15f7Y0+SqcpK7Y2lKlfeyDsu2KNAsY3lXBDbR2 jkAh1oMnRqCh7RfGID6+4zbeHfSweaDWIqbYwYTnaIVXk0q+SvOLA4Mefu+eXIGC BQHPTRNA/+EePKnhoWW6DDlwCBl3WrVZGjEG0Qa81Eath7fu+AMQA/fOPGOCqw==
=9QEZ
-----END PGP SIGNATURE-----

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

XPost: linux.debian.devel.release, linux.debian.maint.boot

Hi Paul,

Paul Gevers <[email protected]> (2025-05-28):

On 27-05-2025 15:59, Cyril Brulebois wrote:

I'm still ambivalent about this, and I still don't want to push in
either direction. I'll just mention that reviewing, merging, and
also adjusting… is all done as far as I'm concerned.

The remaining question is whether that's for trixie or forky.

I'm assuming that if we were to accept this, we'd enlarge the key
package set. Let's not do that this late in the cycle.

To be honest I've tried to answer questions as best as I could when I
got asked whether dropping this or that package from the key package
set would be OK, but I've never wondered how it is built. A quick look
at https://udd.debian.org/cgi-bin/key_packages.yaml.cgi suggests all
desktop tasks are there:

kibi@tokyo:~$ awk '/^- reason: task-.*desktop / { print $3}' key_packages.yaml|sort -u
task-cinnamon-desktop
task-cyrillic-desktop
task-gnome-desktop
task-gnome-flashback-desktop
task-kde-desktop
task-lxde-desktop
task-lxqt-desktop
task-mate-desktop
task-xfce-desktop

(8 choices currently offered by pkgsel calling tasksel, plus
Cyrillic support for some reason.)

I'm not immediately understanding how those get in there based on
skimming over https://release.debian.org/key-packages.html and https://salsa.debian.org/qa/udd/-/blob/master/scripts/update-key-packages.pl

but I'd be very fine with *not* enlarging the key package set, and
having no specific “protection” against autoremovals for those two prospective new desktop environments.

If desktop tasks were indeed injected manually in the past, I suppose
it would be sufficient not to inject the new ones into the DB during
this cycle, and delay that until forky development opens?

If that's more complicated and/or generally just too late, that's also
fine with me. (Here I'm merely trying to understand the key packages
picture a little better, not trying to push harder.)


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmg3ZEMACgkQ/5FK8MKz VSC1+xAAjCQ3taX8FvJdHiRZpn+4K78bFCUqTDfQf5Fi0mL52O6fyyunrK/p8c87 MWs/vezLiXuFaWim9YZsA4txPEit9tWi5ffhSVSE8zfrWDpAsgnqPnBqgSwBav1H 63OUtGGENQIABAyyk3hHu5R6T4Kskwpz9QgRLW9Er3NBHAjBVS3gaFd/DIsNdI1R QjIVVAScpGo/TXIqq02XJ8TDl24jnR1TlUwAKMubE5OblODCxfwOv/lYDA3IhYWL EiuZEVzb+nFP1GD5yCHi+GcTk0ZC+vUr2EGCv9E1SYgbtLL1AzYFgZOERQyXKFrL 27/PmiX2714gDtsdwFzLLv2V3bYH1b9SQntqgqy3KXLM7qAUi4gohO4TTawFD8I7 fsD0JnlYKdknkpENUphIdooraqqTNOOIXH83lsDLKw+7N4QnIcjO45YaEUXNLf6u mzPsUzm5XWM8PPDZVSzzH57D9uFxt7pGufeRmAMxv2B9vJJm7dNsF3GDAQ1/Vq7F +7h90cuJfNfU0cMkCrvHXZMFFZUr9FuXumNzVCuDsBCLh0ukHyvbhVyPjWSWErpl HuG/Y26/FEwkVuybmS5fmctaPL208LuygW+QGoEy/0dodUaWbFDhMBojf4vBL3uI 3NhZdU+Yjrcsx+wHqKgMHUHWUfA/Me4gIacdYUKtYkTkaapUtpE=
=V7y9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.devel.release, linux.debian.maint.boot
Copy: [email protected]
Copy: [email protected]
Copy: [email protected]

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

SGksDQoNCk9uIDI4LTA1LTIwMjUgMjE6MzAsIEN5cmlsIEJydWxlYm9pcyB3cm90ZToNCj4g VG8gYmUgaG9uZXN0IEkndmUgdHJpZWQgdG8gYW5zd2VyIHF1ZXN0aW9ucyBhcyBiZXN0IGFz IEkgY291bGQgd2hlbiBJDQo+IGdvdCBhc2tlZCB3aGV0aGVyIGRyb3BwaW5nIHRoaXMgb3Ig dGhhdCBwYWNrYWdlIGZyb20gdGhlIGtleSBwYWNrYWdlDQo+IHNldCB3b3VsZCBiZSBPSywg YnV0IEkndmUgbmV2ZXIgd29uZGVyZWQgaG93IGl0IGlzIGJ1aWx0LiBBIHF1aWNrIGxvb2sN Cj4gYXQgaHR0cHM6Ly91ZGQuZGViaWFuLm9yZy9jZ2ktYmluL2tleV9wYWNrYWdlcy55YW1s LmNnaSBzdWdnZXN0cyBhbGwNCj4gZGVza3RvcCB0YXNrcyBhcmUgdGhlcmU6DQo+IA0KPiAg ICAgIGtpYmlAdG9reW86fiQgYXdrICcvXi0gcmVhc29uOiB0YXNrLS4qZGVza3RvcCAvIHsg cHJpbnQgJDN9JyBrZXlfcGFja2FnZXMueWFtbHxzb3J0IC11DQo+ICAgICAgdGFzay1jaW5u YW1vbi1kZXNrdG9wDQo+ICAgICAgdGFzay1jeXJpbGxpYy1kZXNrdG9wDQo+ICAgICAgdGFz ay1nbm9tZS1kZXNrdG9wDQo+ICAgICAgdGFzay1nbm9tZS1mbGFzaGJhY2stZGVza3RvcA0K PiAgICAgIHRhc2sta2RlLWRlc2t0b3ANCj4gICAgICB0YXNrLWx4ZGUtZGVza3RvcA0KPiAg ICAgIHRhc2stbHhxdC1kZXNrdG9wDQo+ICAgICAgdGFzay1tYXRlLWRlc2t0b3ANCj4gICAg ICB0YXNrLXhmY2UtZGVza3RvcA0KPiANCj4gKDggY2hvaWNlcyBjdXJyZW50bHkgb2ZmZXJl ZCBieSBwa2dzZWwgY2FsbGluZyB0YXNrc2VsLCBwbHVzDQo+IEN5cmlsbGljIHN1cHBvcnQg Zm9yIHNvbWUgcmVhc29uLikNCj4gDQo+IEknbSBub3QgaW1tZWRpYXRlbHkgdW5kZXJzdGFu ZGluZyBob3cgdGhvc2UgZ2V0IGluIHRoZXJlIGJhc2VkIG9uDQo+IHNraW1taW5nIG92ZXIg aHR0cHM6Ly9yZWxlYXNlLmRlYmlhbi5vcmcva2V5LXBhY2thZ2VzLmh0bWwgYW5kDQo+IGh0 dHBzOi8vc2Fsc2EuZGViaWFuLm9yZy9xYS91ZGQvLS9ibG9iL21hc3Rlci9zY3JpcHRzL3Vw ZGF0ZS1rZXktcGFja2FnZXMucGwNCg0KDQpJIHRoaW5rIGl0J3MgbGlrZSB0aGlzIChwa2dz ZWwgZG9lc24ndCBkZWNsYXJlIHRhc2stKmRlc2t0b3AgDQpkZXBlbmRlbmNpZXMgQUZBSUNU KToNCmQtaSAtPiBkZWJpYW4tZWR1LWluc3RhbGwgLT4gZGViaWFuLWVkdS1jb25maWcgLT4g ZWR1Y2F0aW9uLXRhc2tzIC0+IA0KdGFza3NlbCAoYW5kIGFzIHRhc2tzZWwgY29tZXMgZnJv bSBzcmM6dGFza3NlbCwgYWxsIGJpbmFyaWVzIGZyb20gaXQgYXJlIA0KYXV0b21hdGljYWxs eSBrZXkgWzFdKS4NCg0KSSB3b3VsZCAqbG92ZSogdG8gYXZvaWQgaGF2aW5nIGFsbCB0aGUg ZGVza3RvcHMgKGFuZCB3aGF0IHRoZXkgcHVsbCBpbikgDQppbiB0aGUga2V5IHBhY2thZ2Ug c2V0LCBidXQgSSBhbHNvIGRvbid0IHdhbnQgdG8gZG8gdGhhdCB3aGlsZSBtYWtpbmcgDQp5 b3VyIHdvcmsgaGFyZGVyIHdpdGhvdXQgYmVpbmcgYWxpZ25lZCBvbiB3aGF0IGJvdGggc2lk ZXMgZXhwZWN0IGZyb20gDQp0aGF0LiBJIHRoaW5rIG5vdyBpcyBub3QgYSBnb29kIG1vbWVu dCB0byBjaGFuZ2UgdGhlIGRlZmluaXRpb24gb2YgdGhlIA0Ka2V5IHBhY2thZ2Ugc2V0LiBH cmFoYW0gYW5kIEkgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgZGlmZmVyZW50IGRlZmluaXRpb25z IA0KYWxyZWFkeSwgYnV0IHRoYXQncyBmb3IgZm9ya3kuDQoNClBhdWwNCg0KWzFdIGh0dHBz Oi8vcmVsZWFzZS5kZWJpYW4ub3JnL2tleS1wYWNrYWdlcy5odG1sDQoNCg==

--------------I0nSYzYZaGHB8x1tXWaH4NPI--

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

wsC7BAABCABvBYJoN3AnCRCcXJnrBb11CkcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmd9v2AkMsjn1BuI9J4LqH7QBm2pPze9+ic5E9Acdrv3 ARYhBFi2bUhza+k7BS3mcpxcmesFvXUKAACNYggAjQMnsVUPOVsEuS6h2uGCdhtf ngVwiMLYMuUbA20yC7jXD2SZ2e1XAvTjLv77x7AwmX5TJ1Z0iV/AKD8mspFE5uPh WQyAZy1nLryxIyySENE6K2pfzsZQhWA8lJAR2V7stIoe5KfUYnvH85b/Y4Ws7FXT r0o2AHxbr4TmXcTiZrxPYmP2a6p8NpakcyYOPlMCLaH0Ra+AkGM6YY9H2233OxKJ ho00Z9OL5gGwydRxSxH3vIvwMtVWY/lGRADtE+cv34eW2It01btMXt98dwY8etAa 5A3rM6HGMZmAQ8aE+XocX1BjlQ+v4cCbdBEjZU39E9uncjHUVV0kKJW0lzWV8w==
=NAJx
-----END PGP SIGNATURE-----

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

XPost: linux.debian.devel.release, linux.debian.maint.boot

Paul Gevers <[email protected]> (2025-05-28):

I think it's like this (pkgsel doesn't declare task-*desktop dependencies AFAICT):

Right, it could never express such relationships: pkgsel is a udeb,
running tasksel (a deb) in /target, which lists/proposes a subset of its binaries (all debs) depending on the context.

d-i -> debian-edu-install -> debian-edu-config -> education-tasks -> tasksel (and as tasksel comes from src:tasksel, all binaries from it are automatically key [1]).

Right, the edu indirection looked like a weird thing but I couldn't find anything else/more obvious.

I would *love* to avoid having all the desktops (and what they pull
in) in the key package set, but I also don't want to do that while
making your work harder without being aligned on what both sides
expect from that. I think now is not a good moment to change the
definition of the key package set. Graham and I have been discussing different definitions already, but that's for forky.

Alright. I feel a little sad for Lomiri and Phosh maintainers but I'm
fully aware the timing (let's say on my part) looked way off already…
and considering we would need to adjust the logic around key packages
to accommodate these additions, at this stage of the release cycle,
that actually feels very wrong indeed.

Thanks for your feedback and for your explanations, much appreciated.


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmg3fX0ACgkQ/5FK8MKz VSDUcQ//Rzi+G6ERycN+70SRGZDRFjXTecWSNEVRstCPPuYlqLH9u1ckFSv5D/az t+oJd/ReWCJegWxQ5QdbzOi01qiy2kNc58K9lkE7LIPKPKXHRT4pBG8LxVSFnQzN roPV6oEwC2lWqlVPqBVJD9qg8RDLRVW+lnpJIsn/ZyUxaD254zgsxZl9BQjzk2zS zheo7puFiTHboNDT2hA4xtGIMY4GA6Jzjl8rTdTT0UUFPqHnx8nfb/InQ8R2Ee8v q11RY3edpKhn74oxHwGVls5Tw2XIF6ogl/DmFD0DMYAQxV5aOxUXxtEqD3uIoTyc vUeuAGgA9NSPxwBR8jPCpQUO5DIZA2cq1SrIqPDHs5N29/btUdmC57y9OatvBEWX rj2xPPIYzBxFlp3zR+td9Nn6jLjAE03pLr5IGE31aX135nYtI8GSzbXdkC2QLtXg mNMj3HR5IPsxwlPA0vM+yoP89iOjEi27D8QvgqHEm2aVUTTBCb2uQ0RDT3mqsCnD ak4injUGm+6gq8KScAE2sAey5W7jzB52cRdxFrpd88ZVDCMiYZncwAj/V69qS2HO 2UsaK89Qn5mZmclPmuHgEWaTeuF9eOX7lrlYplRiVSXvyfFM41dkDOchF0E+S2m5 +pckjUK+AUPDHiNIKKK6pR1lErNZVhOe6CrXzhOFgld3ai6Qm2M=
=PtzM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*