date:20230629

Once the portables will be built in f37, the repacked binary in f37
and in f38 (39...)will be identical.
Rpms have some additional value - split to subpakcages, few symlinks
due to system integration, system tzdata, system crypto binding and so
on.

On Thu, 29 Jun 2023 at 22:20, Tom Stellard  wrote:
>
> On 6/29/23 13:07, Jiri Vanek wrote:
> > nn. You were right. There are going to be two separated packages.
> > Portable, built once in oldest live,  and "normal" which is going to
> > repack them for all and  shipp them.
> > My apologise for typo in last second change:
> > https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere=revision=681794=681791
> >
> > narrowed.
> >
>
> Ok, that makes sense now.
>
> My next question is what is the difference between the 
> java-xy-openjdk-portable package
> that is built on f37 and the repacked java-xy-openjdk package that is shipped 
> on f38.
> Are the bits inside the package exactly the same?
>
> -Tom
>
> > On Thu, 29 Jun 2023 at 21:16, Tom Stellard  wrote:
> >>
> >> On 6/29/23 11:06, Jiri Vanek wrote:
> >>> Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several
> >>> time in the proposal. Still the
> >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
> >>> adjusted
> >>>
> >>
> >> OK, I see.  I thought there were going to be two different packages. 
> >> java-xy-openjdk-portable
> >> and java-xy-openjdk.  Where java-xy-openjdk is the one that gets shipped 
> >> in Fedora and
> >> java-xy-openjdk-portable lives only in the side-tags.
> >>
> >> -Tom
> >>
> >>> Tahnx!
> >>>
> >>> On Thu, 29 Jun 2023 at 19:14, Tom Stellard  wrote:
> 
>  On 6/29/23 09:52, Jiri Vanek wrote:
> > Hi Tom!
> >
> > Thanx a lot of for input. Although I did my bes with the tagging, it
> > will be learning on the go.
> > I had adapted 
> > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
> > as you suggested. It is great improvement.
> >
> 
>  Thanks, this looks better.
> 
>  For step 5. should the first mention of java-xy-openjdk-portable actually
>  be java-xy-openjdk ?  Same question for step 7.
> 
>  -Tom
> 
> > Especially the config, I was not aware about. That woudl indeed help a 
> > lot.
> > The usage of pernament tag is someging I have to learn, but is
> > moreover necessary for proper srpm rebuil.
> >
> > TYVM!
> > J.
> >
> > On Wed, 28 Jun 2023 at 21:31, Tom Stellard  wrote:
> >>
> >> On 6/26/23 09:21, Aoife Moloney wrote:
> >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)
> >>>
> >>> This document represents a proposed Change. As part of the Changes
> >>> process, proposals are publicly announced in order to receive
> >>> community feedback. This proposal will only be implemented if approved
> >>> by the Fedora Engineering Steering Committee.
> >>>
> >>>
> >>> == Summary ==
> >>>
> >>> This is the last step in
> >>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> >>> effort. JDKs in fedora are already static, and we repack portable
> >>> tarballs into RPMs. Currently, the portable tarball is built for each
> >>> Fedora and EPEL version. Goal here is to build each JDK
> >>> (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in
> >>> all live Fedoras. If jdk is buitl in epel, it will be built in oldest
> >>> possible epel  and repacked in newer live epels.
> >>>
> >>>
> >>> == Owner ==
> >>> * Name: [[User:jvanek| Jiri Vanek]]
> >>>
> >>> * Email: jva...@redhat.com
> >>>
> >>>
> >>> == Detailed Description ==
> >>>
> >>> As described in
> >>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
> >>> during last year, packaging of JDKs had changed dramatically. As
> >>> described in the same wiki page and in individual sub changes and
> >>> devel threads, the primary reason for this is to lower maintenance and
> >>> still keep Fedora Java friendly.
> >>>
> >>> * In the first system wide change, we have changed the JDKs to build
> >>> properly as standalone, portable JDK - the way JDK is supposed to be
> >>> built. I repeat, we spent ten years by patching JDK to become properly
> >>> dynamic against system libs, and all patches went upstream, but this
> >>> has become a fight which can not be won.
> >>>
> >>> * As a second step we introduced portable RPMs, which do not have any
> >>> system integration, only build JDK and pack the final tarball in RPM
> >>> for Fedora use.
> >>>
> >>> * In third step - without any noise, just verified with fesco -
> >>> https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
>

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

On 6/29/23 10:42, Kevin Fenzi wrote:

On Thu, Jun 29, 2023 at 10:14:31AM -0700, Tom Stellard wrote:

On 6/29/23 09:52, Jiri Vanek wrote:

Hi Tom!

Thanx a lot of for input. Although I did my bes with the tagging, it
will be learning on the go.
I had adapted
https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
as you suggested. It is great improvement.

Thanks, this looks better.

For step 5. should the first mention of java-xy-openjdk-portable actually
be java-xy-openjdk ? Same question for step 7.

I don't think the fixed sidetag idea will work. (Unless you are planning
on doing something different with rawhide).

Bodhi won't let you make an update from a non sidetag tag, so you would
have to tag them into fN-updates-candidate, but then they would go one
by one into rawhide and not be tested/gated as a unit.

What the difference between a fixed side-tag and a normal side-tag from
bodhi's perspective?

-Tom

But of course we could do fixed tags for stable releases and have a
sidetag flow for rawhide, but that might make things more confusing.

kevin

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

On 6/29/23 13:07, Jiri Vanek wrote:

nn. You were right. There are going to be two separated packages.
Portable, built once in oldest live, and "normal" which is going to
repack them for all and shipp them.
My apologise for typo in last second change:
https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere=revision=681794=681791

narrowed.

Ok, that makes sense now.

My next question is what is the difference between the java-xy-openjdk-portable
package
that is built on f37 and the repacked java-xy-openjdk package that is shipped
on f38.
Are the bits inside the package exactly the same?

-Tom

On Thu, 29 Jun 2023 at 21:16, Tom Stellard wrote:

On 6/29/23 11:06, Jiri Vanek wrote:

Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several
time in the proposal. Still the
https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
adjusted

OK, I see. I thought there were going to be two different packages.
java-xy-openjdk-portable
and java-xy-openjdk. Where java-xy-openjdk is the one that gets shipped in
Fedora and
java-xy-openjdk-portable lives only in the side-tags.

-Tom

Tahnx!

On Thu, 29 Jun 2023 at 19:14, Tom Stellard wrote:

On 6/29/23 09:52, Jiri Vanek wrote:

Hi Tom!

Thanks, this looks better.

For step 5. should the first mention of java-xy-openjdk-portable actually
be java-xy-openjdk ? Same question for step 7.

-Tom

Especially the config, I was not aware about. That woudl indeed help a lot.
The usage of pernament tag is someging I have to learn, but is
moreover necessary for proper srpm rebuil.

TYVM!
J.

On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote:

On 6/26/23 09:21, Aoife Moloney wrote:

https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==

This is the last step in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
effort. JDKs in fedora are already static, and we repack portable
tarballs into RPMs. Currently, the portable tarball is built for each
Fedora and EPEL version. Goal here is to build each JDK
(8,11,17,21,latest (20)) only once, in oldest live Fedora repack in
all live Fedoras. If jdk is buitl in epel, it will be built in oldest
possible epel and repacked in newer live epels.

== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]

* Email: jva...@redhat.com

== Detailed Description ==

As described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
during last year, packaging of JDKs had changed dramatically. As
described in the same wiki page and in individual sub changes and
devel threads, the primary reason for this is to lower maintenance and
still keep Fedora Java friendly.

* In the first system wide change, we have changed the JDKs to build
properly as standalone, portable JDK - the way JDK is supposed to be
built. I repeat, we spent ten years by patching JDK to become properly
dynamic against system libs, and all patches went upstream, but this
has become a fight which can not be won.

* As a second step we introduced portable RPMs, which do not have any
system integration, only build JDK and pack the final tarball in RPM
for Fedora use.

* In third step - without any noise, just verified with fesco -
https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
integrated RPMs. Instead of this, normal RPMs BUildRequire portable
RPMs and just unpack it, and repack it.

Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
oldest live Fedora, and repack everywhere. java-latest-openjdk, which
contains latests STS JDK - currently 20, soon briefly 21 and a bit
after 22... If we would built java-latest-openjdk in oldest live EPEL
- epel8 now, we have verified, that such repacked JDKs works fine,
however repack from epel seem to not be acceptable, thus
ajva-latest-openjdk will be built twice - one in oldest live fedora,
and once in oldest live epel. Build forme oldest possible epel will be
repacked to that one or newer epels, and build from oldest live fedroa
to all fedoras.

=== theoretical tagging solution ===

1. request side tags for all releases
2. build the actual Java in the side tag for the oldest thing

Could you use the real package name here. I think that will make it easier
to understand. You can still put 'actual Java' in parens or something.

3. tag the result ot (2) to all side tags from (1)
4. waitrepo

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

nn. You were right. There are going to be two separated packages.
Portable, built once in oldest live,  and "normal" which is going to
repack them for all and  shipp them.
My apologise for typo in last second change:
https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere=revision=681794=681791

narrowed.

On Thu, 29 Jun 2023 at 21:16, Tom Stellard  wrote:
>
> On 6/29/23 11:06, Jiri Vanek wrote:
> > Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several
> > time in the proposal. Still the
> > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
> > adjusted
> >
>
> OK, I see.  I thought there were going to be two different packages. 
> java-xy-openjdk-portable
> and java-xy-openjdk.  Where java-xy-openjdk is the one that gets shipped in 
> Fedora and
> java-xy-openjdk-portable lives only in the side-tags.
>
> -Tom
>
> > Tahnx!
> >
> > On Thu, 29 Jun 2023 at 19:14, Tom Stellard  wrote:
> >>
> >> On 6/29/23 09:52, Jiri Vanek wrote:
> >>> Hi Tom!
> >>>
> >>> Thanx a lot of for input. Although I did my bes with the tagging, it
> >>> will be learning on the go.
> >>> I had adapted 
> >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
> >>> as you suggested. It is great improvement.
> >>>
> >>
> >> Thanks, this looks better.
> >>
> >> For step 5. should the first mention of java-xy-openjdk-portable actually
> >> be java-xy-openjdk ?  Same question for step 7.
> >>
> >> -Tom
> >>
> >>> Especially the config, I was not aware about. That woudl indeed help a 
> >>> lot.
> >>> The usage of pernament tag is someging I have to learn, but is
> >>> moreover necessary for proper srpm rebuil.
> >>>
> >>> TYVM!
> >>>J.
> >>>
> >>> On Wed, 28 Jun 2023 at 21:31, Tom Stellard  wrote:
> 
>  On 6/26/23 09:21, Aoife Moloney wrote:
> > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> >
> > == Summary ==
> >
> > This is the last step in
> > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> > effort. JDKs in fedora are already static, and we repack portable
> > tarballs into RPMs. Currently, the portable tarball is built for each
> > Fedora and EPEL version. Goal here is to build each JDK
> > (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in
> > all live Fedoras. If jdk is buitl in epel, it will be built in oldest
> > possible epel  and repacked in newer live epels.
> >
> >
> > == Owner ==
> > * Name: [[User:jvanek| Jiri Vanek]]
> >
> > * Email: jva...@redhat.com
> >
> >
> > == Detailed Description ==
> >
> > As described in
> > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
> > during last year, packaging of JDKs had changed dramatically. As
> > described in the same wiki page and in individual sub changes and
> > devel threads, the primary reason for this is to lower maintenance and
> > still keep Fedora Java friendly.
> >
> > * In the first system wide change, we have changed the JDKs to build
> > properly as standalone, portable JDK - the way JDK is supposed to be
> > built. I repeat, we spent ten years by patching JDK to become properly
> > dynamic against system libs, and all patches went upstream, but this
> > has become a fight which can not be won.
> >
> > * As a second step we introduced portable RPMs, which do not have any
> > system integration, only build JDK and pack the final tarball in RPM
> > for Fedora use.
> >
> > * In third step - without any noise, just verified with fesco -
> > https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
> > integrated RPMs. Instead of this, normal RPMs BUildRequire portable
> > RPMs and just unpack it, and repack it.
> >
> > Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
> > oldest live Fedora, and repack everywhere. java-latest-openjdk, which
> > contains latests STS JDK - currently 20, soon briefly 21 and a bit
> > after 22... If we would built java-latest-openjdk in  oldest live EPEL
> > - epel8 now, we have verified, that such repacked JDKs works fine,
> > however repack from epel seem to not be acceptable, thus
> > ajva-latest-openjdk will be built twice - one in oldest live fedora,
> > and once in oldest live epel. Build forme oldest possible epel will be
> > repacked to that one or newer epels, and build from oldest live fedroa
> > to all fedoras.
> >
> >

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

2023-06-29 Thread Simon de Vlieger


On 6/28/23 17:06, Adam Williamson wrote:

On Wed, 2023-06-28 at 13:01 +0200, Ondřej Budai wrote:

I already answered you here:
https://pagure.io/fedora-workstation/issue/384#comment-862709

TL;DR: Let's figure this out when we are migrating other artifacts. For
now, the blueprint will be empty/minimal.


Thanks a lot for engaging with the feedback. However, I'm not convinced
by that answer, and I would prefer to follow up here; I suspect
feedback to an issue in the workstation tracker might well not be
captured in the Change process.

I think the points discussed in the ticket (layering/inheritance, and
package removals) are critical and they need an answer to be figured
out *before* we start switching Fedora live images to be built with a
different tool. I don't see how it can be good for Fedora if we have
*some* live images built with livemedia-creator and *some* live images
built with Image Builder - but if we start converting images without
figuring out what to do about layering and package exclusions, that's
exactly what we risk.

We do really kinda need inheritance to maintain the live image
definitions sensibly. (Also, a related point Neal didn't mention: we
share some elements of configuration between the live images and the
aarch64 disk images, since both are defined by kickstarts in the
fedora-kickstarts repo.) And we really need package exclusions to keep
some images to a sensible size.

We don't necessarily need these things to be completely implemented in
order to switch Workstation over, I don't think, but I think we should
at least have a *plan* for them. And ideally a timeframe.


Hey Adam,

I've made a beginning with starting to track work ongoing on building 
Fedora within the projects that make up image builder. It's far from 
complete (I'm still backfilling with previous relevant issues and 
creating new issues) but it will give a bit better insight into options 
being considered and work being done to improve support for Fedora: 
https://github.com/orgs/osbuild/projects/3


I'm still working on making the plan more concrete but I think it's 
definitely feasible to, as a followup (likely for Fedora 40) allow 
blueprints to define excludes.


Still working on things related to inheritance, there's two ways of 
going about it. One is a direct support for including blueprint 
snippet(s) in other blueprints (this would be non-standard for the 
current TOML format that the languages are in). The other is more a 
mitigation and it would be to make it so that all current kickstarts can 
be defined without inheritance and then to later work that into a form 
where inheritance is brought back in.


Also, for understanding I've been diving through the kickstart 
repositories to define a common base set and interdependencies. I've 
graphed out the kickstart files and their relationships here: 
https://supakeen.fedorapeople.org/kickstart-graph.png it seems to have 
found some includes to kickstarts which no longer exist in the repositories!


Regards,

Simon

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

2023-06-29 Thread Davide Cavalca


On 2023-06-29 09:42, Adam Williamson wrote:

On Thu, 2023-06-29 at 02:22 -0400, Neal Gompa wrote:

And since Lorax (which is what we use
for live and ARM images) requires Anaconda to understand the target
system to install, it couldn't be used for creating these images
either because that requires teaching Anaconda about Apple Silicon
Macs.


Hmm, well, why don't we do that? It knows/knew about PPC Macs and Intel
Macs, after all...


This is planned, see https://pagure.io/fedora-asahi/project/issue/9 and 
https://pagure.io/fedora-asahi/project/issue/10. It's worth noting that 
these systems boot _very_ differently from standard aarch64 machines 
(see 
https://github.com/AsahiLinux/docs/wiki/Open-OS-Ecosystem-on-Apple-Silicon-Macs 
for details).


Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP


Yes, 14 days would be fine. Sehr gut.

--


*
David P. Both, RHCE
He/Him/His
*
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*
The value of any software lies in its usefulness
not in its price.

— Linus Torvalds
*

On Thu, 29 Jun 2023, Peter Boy wrote:


Date: Thu, 29 Jun 2023 14:53:20
From: Peter Boy 
Reply-To: Development discussions related to Fedora

To: David Both ,
Development discussions related to Fedora 
Subject: Re: UW-IMAP




Am 29.06.2023 um 18:15 schrieb David Both :

@Peter Boy:

I would truly appreciate your step-by-step guide. That would be
incredibly helpful. I'm sure I can figure out connecting it with
SendMail. There is lots of information out there but - as I said - it
needs some work.

If you make it CC-by-SA it should be unencumbered and I will be sure to
attribute that section to you. With your guide I would gladly use
Dovecot.

I do have a deadline. Do you have an estimate of when you might finish
the translation?

I know a little German from uni but not nearly enough to do a
translation.

Danke und guten Tag.

--


Das klingt schon mal gut.


Well, I’m quite flexible at the moment. Maybe I have to prepare some 
contribution to FLOCK, just in case a proposal would get accepted. It’s quite 
comfortable for me to do it in the next 14 days. If that’s OK for your 
deadline. Otherwise I would reorganize my planning a bit more. Generally it’s 
not so much work using DeepL and some fine-tuning. But I would like to update 
the text slightly and do a final test - just to be sure (and I have to do that 
anyway for the planned tutorial). And CC-by-SA is OK for me (I just don’t 
remember what we sign with FAS account).


Peter




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

On 6/29/23 11:06, Jiri Vanek wrote:

-Tom

Tahnx!

On Thu, 29 Jun 2023 at 19:14, Tom Stellard wrote:

On 6/29/23 09:52, Jiri Vanek wrote:

Hi Tom!

Thanks, this looks better.

For step 5. should the first mention of java-xy-openjdk-portable actually
be java-xy-openjdk ? Same question for step 7.

-Tom

Especially the config, I was not aware about. That woudl indeed help a lot.
The usage of pernament tag is someging I have to learn, but is
moreover necessary for proper srpm rebuil.

TYVM!
J.

On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote:

On 6/26/23 09:21, Aoife Moloney wrote:

https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)

== Summary ==

== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]

* Email: jva...@redhat.com

== Detailed Description ==

* As a second step we introduced portable RPMs, which do not have any
system integration, only build JDK and pack the final tarball in RPM
for Fedora use.

=== theoretical tagging solution ===

1. request side tags for all releases
2. build the actual Java in the side tag for the oldest thing

Could you use the real package name here. I think that will make it easier
to understand. You can still put 'actual Java' in parens or something.

3. tag the result ot (2) to all side tags from (1)
4. waitrepo them
5. build the repacked java packages in all the side tags from (1)

Same thing here, can you use the real package name.

6. untag the result of (2) from all the side tags from (1)
7. ship bodhi updates from side tags OR retag the builds to candidate tags
(and delete the side tags)

The build from (2) will be eventually garbage collected. To prevent that, it
might be re-tagged regularly. This is where releng might be able to help by
creating a long lived tag to tag this into for preserving.

Yes, we could make a 'fN-openjdk' tag and mark it protected... that part
would be easy enough.

I think this process could be improved if the side-tags in 1. are

Re: Orphaning packages (was LibreOffice packages)

2023-06-29 Thread Davide Cavalca


On 2023-06-29 18:09, Bastien Nocera wrote:

Do you want to pick up the rest of the libimobiledevice stack as well?
That's ifuse, libplist, libusbmuxd and usbmuxd.


I've just picked these up, thanks! Will work together with Neal on this 
stack as part of the Fedora Asahi SIG.


Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP

2023-06-29 Thread Peter Boy



> Am 29.06.2023 um 18:15 schrieb David Both :
> 
> @Peter Boy:
> 
> I would truly appreciate your step-by-step guide. That would be
> incredibly helpful. I'm sure I can figure out connecting it with
> SendMail. There is lots of information out there but - as I said - it
> needs some work.
> 
> If you make it CC-by-SA it should be unencumbered and I will be sure to
> attribute that section to you. With your guide I would gladly use
> Dovecot.
> 
> I do have a deadline. Do you have an estimate of when you might finish
> the translation?
> 
> I know a little German from uni but not nearly enough to do a
> translation.
> 
> Danke und guten Tag.
> 
> -- 

Das klingt schon mal gut.


Well, I’m quite flexible at the moment. Maybe I have to prepare some 
contribution to FLOCK, just in case a proposal would get accepted. It’s quite 
comfortable for me to do it in the next 14 days. If that’s OK for your 
deadline. Otherwise I would reorganize my planning a bit more. Generally it’s 
not so much work using DeepL and some fine-tuning. But I would like to update 
the text slightly and do a final test - just to be sure (and I have to do that 
anyway for the planned tutorial). And CC-by-SA is OK for me (I just don’t 
remember what we sign with FAS account).


Peter




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

Hi Kevin!
I'm unabel to answer that. First release will be a bit experiemntal
for sure. But final target is sure - to persist the underlying
portables and to  enable srpm rebuild as comfortably as possible.
As far rawhide itself, as it is unreleased distro, if no other paths
will remain,  rawhide may remian self building.  Aka using protbales
from rawhide to buidl rawhide's rpms.

Thax!



On Thu, 29 Jun 2023 at 19:43, Kevin Fenzi  wrote:
>
> On Thu, Jun 29, 2023 at 10:14:31AM -0700, Tom Stellard wrote:
> > On 6/29/23 09:52, Jiri Vanek wrote:
> > > Hi Tom!
> > >
> > > Thanx a lot of for input. Although I did my bes with the tagging, it
> > > will be learning on the go.
> > > I had adapted 
> > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
> > > as you suggested. It is great improvement.
> > >
> >
> > Thanks, this looks better.
> >
> > For step 5. should the first mention of java-xy-openjdk-portable actually
> > be java-xy-openjdk ?  Same question for step 7.
>
> I don't think the fixed sidetag idea will work. (Unless you are planning
> on doing something different with rawhide).
>
> Bodhi won't let you make an update from a non sidetag tag, so you would
> have to tag them into fN-updates-candidate, but then they would go one
> by one into rawhide and not be tested/gated as a unit.
>
> But of course we could do fixed tags for stable releases and have a
> sidetag flow for rawhide, but that might make things more confusing.
>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several
time in the proposal. Still the
https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
adjusted

Tahnx!

On Thu, 29 Jun 2023 at 19:14, Tom Stellard  wrote:
>
> On 6/29/23 09:52, Jiri Vanek wrote:
> > Hi Tom!
> >
> > Thanx a lot of for input. Although I did my bes with the tagging, it
> > will be learning on the go.
> > I had adapted 
> > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
> > as you suggested. It is great improvement.
> >
>
> Thanks, this looks better.
>
> For step 5. should the first mention of java-xy-openjdk-portable actually
> be java-xy-openjdk ?  Same question for step 7.
>
> -Tom
>
> > Especially the config, I was not aware about. That woudl indeed help a lot.
> > The usage of pernament tag is someging I have to learn, but is
> > moreover necessary for proper srpm rebuil.
> >
> > TYVM!
> >   J.
> >
> > On Wed, 28 Jun 2023 at 21:31, Tom Stellard  wrote:
> >>
> >> On 6/26/23 09:21, Aoife Moloney wrote:
> >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)
> >>>
> >>> This document represents a proposed Change. As part of the Changes
> >>> process, proposals are publicly announced in order to receive
> >>> community feedback. This proposal will only be implemented if approved
> >>> by the Fedora Engineering Steering Committee.
> >>>
> >>>
> >>> == Summary ==
> >>>
> >>> This is the last step in
> >>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> >>> effort. JDKs in fedora are already static, and we repack portable
> >>> tarballs into RPMs. Currently, the portable tarball is built for each
> >>> Fedora and EPEL version. Goal here is to build each JDK
> >>> (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in
> >>> all live Fedoras. If jdk is buitl in epel, it will be built in oldest
> >>> possible epel  and repacked in newer live epels.
> >>>
> >>>
> >>> == Owner ==
> >>> * Name: [[User:jvanek| Jiri Vanek]]
> >>>
> >>> * Email: jva...@redhat.com
> >>>
> >>>
> >>> == Detailed Description ==
> >>>
> >>> As described in
> >>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
> >>> during last year, packaging of JDKs had changed dramatically. As
> >>> described in the same wiki page and in individual sub changes and
> >>> devel threads, the primary reason for this is to lower maintenance and
> >>> still keep Fedora Java friendly.
> >>>
> >>> * In the first system wide change, we have changed the JDKs to build
> >>> properly as standalone, portable JDK - the way JDK is supposed to be
> >>> built. I repeat, we spent ten years by patching JDK to become properly
> >>> dynamic against system libs, and all patches went upstream, but this
> >>> has become a fight which can not be won.
> >>>
> >>> * As a second step we introduced portable RPMs, which do not have any
> >>> system integration, only build JDK and pack the final tarball in RPM
> >>> for Fedora use.
> >>>
> >>> * In third step - without any noise, just verified with fesco -
> >>> https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
> >>> integrated RPMs. Instead of this, normal RPMs BUildRequire portable
> >>> RPMs and just unpack it, and repack it.
> >>>
> >>> Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
> >>> oldest live Fedora, and repack everywhere. java-latest-openjdk, which
> >>> contains latests STS JDK - currently 20, soon briefly 21 and a bit
> >>> after 22... If we would built java-latest-openjdk in  oldest live EPEL
> >>> - epel8 now, we have verified, that such repacked JDKs works fine,
> >>> however repack from epel seem to not be acceptable, thus
> >>> ajva-latest-openjdk will be built twice - one in oldest live fedora,
> >>> and once in oldest live epel. Build forme oldest possible epel will be
> >>> repacked to that one or newer epels, and build from oldest live fedroa
> >>> to all fedoras.
> >>>
> >>> === theoretical tagging solution ===
> >>>
> >>> 1. request side tags for all releases
> >>> 2. build the actual Java in the side tag for the oldest thing
> >>
> >> Could you use the real package name here.  I think that will make it easier
> >> to understand.  You can still put 'actual Java' in parens or something.
> >>
> >>> 3. tag the result ot (2) to all side tags from (1)
> >>> 4. waitrepo them
> >>> 5. build the repacked java packages in all the side tags from (1)
> >>
> >> Same thing here, can you use the real package name.
> >>
> >>> 6. untag the result of (2) from all the side tags from (1)
> >>> 7. ship bodhi updates from side tags OR retag the builds to candidate 
> >>> tags
> >>>(and delete the side tags)
> >>>
> >>> The build from (2) will be eventually garbage collected. To prevent that, 
> >>> it
> >>> might be re-tagged regularly. This is where

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

2023-06-29 Thread Kevin Fenzi

On Thu, Jun 29, 2023 at 10:14:31AM -0700, Tom Stellard wrote:
> On 6/29/23 09:52, Jiri Vanek wrote:
> > Hi Tom!
> > 
> > Thanx a lot of for input. Although I did my bes with the tagging, it
> > will be learning on the go.
> > I had adapted 
> > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
> > as you suggested. It is great improvement.
> > 
> 
> Thanks, this looks better.
> 
> For step 5. should the first mention of java-xy-openjdk-portable actually
> be java-xy-openjdk ?  Same question for step 7.

I don't think the fixed sidetag idea will work. (Unless you are planning
on doing something different with rawhide). 

Bodhi won't let you make an update from a non sidetag tag, so you would
have to tag them into fN-updates-candidate, but then they would go one
by one into rawhide and not be tested/gated as a unit.

But of course we could do fixed tags for stable releases and have a
sidetag flow for rawhide, but that might make things more confusing.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-06-29 Thread Frederic Berat

On Thu, Jun 29, 2023 at 6:41 PM Todd Zullinger  wrote:

> Carlos O'Donell wrote:
> > On 6/26/23 18:47, Jeff Law wrote:
> >> What Red Hat has done may be technically legal and perhaps good for
> >> its business.  However, to me it's ethically unconscionable.   Those
> >> who know me know I'm not an zealot, but I do have a baseline set of
> >> ethical values and Red Hat crossed that line.
> >
> > Why is it ethically unconscionable? There is a lot of confusion around
> > what has happened and why. What you are saying, and what actually
> happened
> > don't line up in my mind :-)
>
> Something I'm having trouble with is Red Hat's position that
> you can choose to be a customer or to exercise your rights
> under the GPL, but you cannot be both.
>
>
Receiving GPL software doesn't give you the right to receive support for
it. It never did, and never will. If that you were in capacity to enforce
any developer that ever provided you a specific version of a software to
give you all future version that you would need in the future, that would
contradict fundamental rights: "You should also have the freedom to make
modifications and use them privately in your own work or play, without even
mentioning that they exist." [1]

Or said the other way around, the fact that Red Hat gives you a binary, and
the sources associated with it doesn't oblige Red Hat to give support for
it nor any future modified version of it. This support obligation is only
tight to the support contract you may have with Red Hat which it may choose
to cancel in any conditions that it sees fit (in accordance to the said
contract). The rupture of this contract does not deprive you from your
rights on the previously received binaries/sources in any way.

[1] https://www.gnu.org/philosophy/free-sw.en.html#redistribute


> I don't know how to view that as anything other than
> sacrificing the spirit of F/OSS to help the books.
>
I am sympathetic to the odd/difficult nature of running a
> business based on F/OSS.  Until now I thought Red Hat was
> doing it pretty well.
>
> I thought Jeff's message was well written.  I am still
> struggling with whether I should take the same path. :(
>
> --
> Todd
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

On 6/29/23 09:52, Jiri Vanek wrote:

Hi Tom!

Thanks, this looks better.

For step 5. should the first mention of java-xy-openjdk-portable actually
be java-xy-openjdk ? Same question for step 7.

-Tom

Especially the config, I was not aware about. That woudl indeed help a lot.
The usage of pernament tag is someging I have to learn, but is
moreover necessary for proper srpm rebuil.

TYVM!
J.

On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote:

On 6/26/23 09:21, Aoife Moloney wrote:

https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)

== Summary ==

== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]

* Email: jva...@redhat.com

== Detailed Description ==

* As a second step we introduced portable RPMs, which do not have any
system integration, only build JDK and pack the final tarball in RPM
for Fedora use.

=== theoretical tagging solution ===

1. request side tags for all releases
2. build the actual Java in the side tag for the oldest thing

Could you use the real package name here. I think that will make it easier
to understand. You can still put 'actual Java' in parens or something.

3. tag the result ot (2) to all side tags from (1)
4. waitrepo them
5. build the repacked java packages in all the side tags from (1)

Same thing here, can you use the real package name.

6. untag the result of (2) from all the side tags from (1)
7. ship bodhi updates from side tags OR retag the builds to candidate tags
(and delete the side tags)

Yes, we could make a 'fN-openjdk' tag and mark it protected... that part
would be easy enough.

I think this process could be improved if the side-tags in 1. are permanent
side-tags,
and step 6 is skipped. That would make it easier to rebuild the packages from
step 5 if needed.

Also, can you put a config file in the dist-git repos to tell fedpkg which
target
to build against? I thought I remembered seeing that feature in the past. If
so,
then you could configure the dist-gits for the repacked javas to automatically
build
from those side-tags, which I think would be a lot easier for package
maintainers and
may help make automated rebuilds possible.

-Tom

including portable srpms in release

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-06-29 Thread Paolo Bonzini


On 6/26/23 18:47, Jeff Law wrote:

What Red Hat has done may be technically legal and perhaps good for
its business.


Something I'm having trouble with is Red Hat's position that
you can choose to be a customer or to exercise your rights
under the GPL, but you cannot be both.


The thing is, many people are learning this only now, because things 
indeed have become tougher for people who prepare the RHEL rebuilds, but 
this is not new.  _Nothing_ in the service agreement or in any other 
legal document has changed since last week, the exact same terms have 
been applicable to the extended-support branches since the beginning of 
RHEL.  In fact, as Frank pointed out elsewhere, this is something that 
other companies have been doing for decades as well.


For all the people that are complaining only now that the free beer part 
is taken away, I can't help thinking that it's a bit disingenuous to 
make it about "free as in freedom", when that clause has existed forever.


(As an aside, the service agreement also mentions that any open source 
license overrides the service agreement if needed.  So by definition 
this might be void but it certainly is not a GPL violation).


Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

Hi Tom!

Thanx a lot of for input. Although I did my bes with the tagging, it
will be learning on the go.
I had adapted 
https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution
as you suggested. It is great improvement.

Especially the config, I was not aware about. That woudl indeed help a lot.
The usage of pernament tag is someging I have to learn, but is
moreover necessary for proper srpm rebuil.

TYVM!
 J.

On Wed, 28 Jun 2023 at 21:31, Tom Stellard  wrote:
>
> On 6/26/23 09:21, Aoife Moloney wrote:
> > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> >
> > == Summary ==
> >
> > This is the last step in
> > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> > effort. JDKs in fedora are already static, and we repack portable
> > tarballs into RPMs. Currently, the portable tarball is built for each
> > Fedora and EPEL version. Goal here is to build each JDK
> > (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in
> > all live Fedoras. If jdk is buitl in epel, it will be built in oldest
> > possible epel  and repacked in newer live epels.
> >
> >
> > == Owner ==
> > * Name: [[User:jvanek| Jiri Vanek]]
> >
> > * Email: jva...@redhat.com
> >
> >
> > == Detailed Description ==
> >
> > As described in
> > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
> > during last year, packaging of JDKs had changed dramatically. As
> > described in the same wiki page and in individual sub changes and
> > devel threads, the primary reason for this is to lower maintenance and
> > still keep Fedora Java friendly.
> >
> > * In the first system wide change, we have changed the JDKs to build
> > properly as standalone, portable JDK - the way JDK is supposed to be
> > built. I repeat, we spent ten years by patching JDK to become properly
> > dynamic against system libs, and all patches went upstream, but this
> > has become a fight which can not be won.
> >
> > * As a second step we introduced portable RPMs, which do not have any
> > system integration, only build JDK and pack the final tarball in RPM
> > for Fedora use.
> >
> > * In third step - without any noise, just verified with fesco -
> > https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
> > integrated RPMs. Instead of this, normal RPMs BUildRequire portable
> > RPMs and just unpack it, and repack it.
> >
> > Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
> > oldest live Fedora, and repack everywhere. java-latest-openjdk, which
> > contains latests STS JDK - currently 20, soon briefly 21 and a bit
> > after 22... If we would built java-latest-openjdk in  oldest live EPEL
> > - epel8 now, we have verified, that such repacked JDKs works fine,
> > however repack from epel seem to not be acceptable, thus
> > ajva-latest-openjdk will be built twice - one in oldest live fedora,
> > and once in oldest live epel. Build forme oldest possible epel will be
> > repacked to that one or newer epels, and build from oldest live fedroa
> > to all fedoras.
> >
> > === theoretical tagging solution ===
> >
> >1. request side tags for all releases
> >2. build the actual Java in the side tag for the oldest thing
>
> Could you use the real package name here.  I think that will make it easier
> to understand.  You can still put 'actual Java' in parens or something.
>
> >3. tag the result ot (2) to all side tags from (1)
> >4. waitrepo them
> >5. build the repacked java packages in all the side tags from (1)
>
> Same thing here, can you use the real package name.
>
> >6. untag the result of (2) from all the side tags from (1)
> >7. ship bodhi updates from side tags OR retag the builds to candidate 
> > tags
> >   (and delete the side tags)
> >
> > The build from (2) will be eventually garbage collected. To prevent that, it
> > might be re-tagged regularly. This is where releng might be able to help by
> > creating a long lived tag to tag this into for preserving.
> >
> > Yes, we could make a 'fN-openjdk' tag and mark it protected... that part
> > would be easy enough.
> >
>
> I think this process could be improved if the side-tags in 1. are permanent 
> side-tags,
> and step 6 is skipped.  That would make it easier to rebuild the packages from
> step 5 if needed.
>
> Also, can you put a config file in the dist-git repos to tell fedpkg which 
> target
> to build against?  I thought I remembered seeing that feature in the past.  
> If so,
> then you could configure the dist-gits for the repacked javas to 
> automatically build
> from those side-tags, which I think would be a lot easier for

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-06-29 Thread Todd Zullinger

Carlos O'Donell wrote:
> On 6/26/23 18:47, Jeff Law wrote:
>> What Red Hat has done may be technically legal and perhaps good for
>> its business.  However, to me it's ethically unconscionable.   Those
>> who know me know I'm not an zealot, but I do have a baseline set of
>> ethical values and Red Hat crossed that line.
> 
> Why is it ethically unconscionable? There is a lot of confusion around
> what has happened and why. What you are saying, and what actually happened
> don't line up in my mind :-)

Something I'm having trouble with is Red Hat's position that
you can choose to be a customer or to exercise your rights
under the GPL, but you cannot be both.

I don't know how to view that as anything other than
sacrificing the spirit of F/OSS to help the books.

I am sympathetic to the odd/difficult nature of running a
business based on F/OSS.  Until now I thought Red Hat was
doing it pretty well.

I thought Jeff's message was well written.  I am still
struggling with whether I should take the same path. :(

-- 
Todd

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP


@Peter Boy:

I would truly appreciate your step-by-step guide. That would be
incredibly helpful. I'm sure I can figure out connecting it with
SendMail. There is lots of information out there but - as I said - it
needs some work.

If you make it CC-by-SA it should be unencumbered and I will be sure to
attribute that section to you. With your guide I would gladly use
Dovecot.

I do have a deadline. Do you have an estimate of when you might finish
the translation?

I know a little German from uni but not nearly enough to do a
translation.

Danke und guten Tag.

--


*
David P. Both, RHCE
He/Him/His
*
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*
The value of any software lies in its usefulness
not in its price.

— Linus Torvalds
*

On Thu, 29 Jun 2023, Peter Boy wrote:


Date: Thu, 29 Jun 2023 11:38:42
From: Peter Boy 
Reply-To: Development discussions related to Fedora

To: David Both ,
Development discussions related to Fedora 
Subject: Re: UW-IMAP

Hi,


Am 29.06.2023 um 16:27 schrieb David Both :

...
I also spent about 4 days trying to get Dovecot to work with SendMail in
a test VM setup. I'm either missing one or more important bits or its
just too complex for me. None of the docs I have found anywhere has a
complete start-to-finish picture. I find no accurate list of here's
exactly what needs to be in place and configured in this way to make it
work. The docs I find are incomplete because they assume much about my
knowledge or just skip parts that are needed. Others are just plain
wrong after trying them.


Just in case you decide for dovecot (which would be preferable, IMHO), I could 
contribute a step-by-step guide to create a workable configuration of dovecot 
(it is Part of a solution for a rather full-fledged mail service). However, the 
instructions use Postfix, not Sendmail. But because the connection runs via 
milter, the replacement with Sendmail should not be a difficult.

At the moment everything is (still) in German. But I have to translate it 
anyway, because I want to create a tutorial for Fedora Server from it.




[1] http://www.both.org/?page_id=1183


What a coincidence, actually found this in my ePub library (though still 
unread, sorry :-) ).



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

2023-06-29 Thread Miro Hrončok


On 29. 06. 23 17:57, Carlos O'Donell wrote:

On 6/29/23 00:44, Miro Hrončok wrote:

On 29. 06. 23 0:31, Carlos O'Donell wrote:

Can we allow users to create a minimal installation by hand, while still 
complying
with PEP-615 for default installs?

The size savings for a minimal container that is UTC-only would be quite 
valuable
for Fedora minimal containers.

Yes, but see the rest of my email.



Just for clarity, and 3-way-communication:

(a) You are concerned about the UTC case failing today.


I am. It seems that without tzdata, we cannot even use UTC in Python.


(b) You would like to see an upstream patch to python to detect missing tzdata 
and report something like:

 ZoneInfoNotInstalledError: 'No time zone information installed on the 
system, you can only use UTC'


Yes.


(c) You would like to ensure UTC works even without tzdata installed.


Indeed.


(d) You don't want to carry a downstream patch, but you would be OK with a 
backported upstream patch?


I don't. Probably OK, depending on the size of it, but I don't expect this to 
be super complex.



Does that match your expectations?


All 4 points match my expectations 100%, but I also have another one:

(e) The Python Maint team currently has no capacity to drive this upstream in 
the Fedora 39 development cycle. We are in the middle of the Python 3.12 rebase.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

2023-06-29 Thread Bastien Nocera

Do you want to pick up the rest of the libimobiledevice stack as well? That's 
ifuse, libplist, libusbmuxd and usbmuxd.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-06-29 Thread Leon Fauster via devel


Am 29.06.23 um 17:49 schrieb Carlos O'Donell:

On 6/26/23 18:47, Jeff Law wrote:

What Red Hat has done may be technically legal and perhaps good for
its business.  However, to me it's ethically unconscionable.   Those
who know me know I'm not an zealot, but I do have a baseline set of
ethical values and Red Hat crossed that line.


Why is it ethically unconscionable? There is a lot of confusion around
what has happened and why. What you are saying, and what actually happened
don't line up in my mind :-)




Well, lets start just (and that alone is reprehensible) with untrue 
sentences  that just miscredited the open EL-community (open 
EL-community == all without RH and RH customers). Its just a slap in the 
face of contributers, EPEL maintainers (non @redhat.com owners) and so 
on ...

This is just done to have a bigger gap in the reasoning argumentation.
This is FUD tactic and dignityless for RH. They have reasonable 
arguments to do what they do, but the "style" is ethically unconscionable.



--
Leon

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

2023-06-29 Thread Stephen Smoogen

On Thu, 29 Jun 2023 at 10:48, Bastien Nocera  wrote:

> Hello,
>
> As part of the same process outlined in Matthias Clasen's "LibreOffice
> packages" email, my upstream and downstream work on desktop Bluetooth,
> multimedia applications (namely totem, rhythmbox and sound-juicer) and
> libfprint/fprintd is being stopped, and all the rest of my upstream and
> downstream work will be reassigned depending on Red Hat's own priorities,
> as I am transferred to another team.
>
>
1. Thank you for all the work you have done on these and other packages in
Fedora. The Bluetooth stack is not easy.
2. Thank you for announcing this early and allowing a quick transfer.
3. Good luck with the new team, they are lucky to have you.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

On 6/28/23 19:54, Michael Catanzaro wrote:
> Because Recommends and Supplements are installed by default, we need
> to be careful and use them sparingly, only when it really makes sense
> for some package to be pulled in for almost all users of another
> package. Thus far, Fedora and RHEL have done a good job of this,
> primarily because we were very late to the weak dep party and have
> had much more time to learn best practices and much less time to
> screw up. This is in contrast to some other distros where it's common
> for users to disable weak deps to avoid "bloat." We don't ever want
> our Recommends/Supplements to be considered bloat. (That's what
> Suggests/Enhances is for. :) And since they're not bloat, they should
> be respected when building most non-minimal images.

I agree.

Do you consider the removal of tzdata to be a valuable use of Recommends?

It is my opinion that glibc should Recommends: tzdata because it frees up an 
optional
~8MiB of zoneinfo that will never be used by UTC-only microservice workloads. 
It is
a further refinement of having really small containers with LANG=C.UTF-8/C and 
TZ=UTC.

Some spec files will need BuildRequires: tzdata, because their %check and 
testsuite
run needs it. In addition to this we should continue to adopt Fedora CI and 
test the
results as required in an installed scenario (with or without tzdata as your 
package
might need to test).

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

2023-06-29 Thread Jeffrey Stewart


I've picked up low-memory-monitor

On 6/29/23 08:46, Neal Gompa wrote:

On Thu, Jun 29, 2023 at 10:48 AM Bastien Nocera  wrote:

Hello,

As part of the same process outlined in Matthias Clasen's "LibreOffice 
packages" email, my upstream and downstream work on desktop Bluetooth, multimedia 
applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being 
stopped, and all the rest of my upstream and downstream work will be reassigned depending 
on Red Hat's own priorities, as I am transferred to another team.

While it's possible that some of the maintenance will stay with me in the new 
team, I've not yet been told which team I would be joining.

Here is a list of Fedora packages which I maintained or co-maintained which I 
won't be able to contribute to anymore:
apfs-fuse
bluez
codespell
eosrei-emojione-fonts
geocode-glib
gnome-bluetooth
gnome-epub-thumbnailer
gnome-kra-ora-thumbnailer
gnome-user-share
gom
grilo
grilo-plugins
ifuse
iio-sensor-proxy
libfprint
libglib-testing
libimobiledevice
libpeas
libplist
libportal
libusbmuxd
low-memory-monitor
malcontent
power-profiles-daemon
sloccount
switcheroo-control
totem
totem-pl-parser
umockdev
usbmuxd


I've picked up libimobiledevice as I need it for Fedora Asahi work.




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

On 6/29/23 00:44, Miro Hrončok wrote:
> On 29. 06. 23 0:31, Carlos O'Donell wrote:
>> Can we allow users to create a minimal installation by hand, while still 
>> complying
>> with PEP-615 for default installs?
>>
>> The size savings for a minimal container that is UTC-only would be quite 
>> valuable
>> for Fedora minimal containers.
> Yes, but see the rest of my email.
> 

Just for clarity, and 3-way-communication:

(a) You are concerned about the UTC case failing today.

(b) You would like to see an upstream patch to python to detect missing tzdata 
and report something like:

ZoneInfoNotInstalledError: 'No time zone information installed on the 
system, you can only use UTC'

(c) You would like to ensure UTC works even without tzdata installed.

(d) You don't want to carry a downstream patch, but you would be OK with a 
backported upstream patch?

Does that match your expectations?

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

On 6/27/23 20:21, Kevin Kofler via devel wrote:
> Practical cross-compilation to a completely different architecture needs 
> sysroots anyway. That way, one can also easily target a different 
> distribution on a different (or even the same) architecture, not just Fedora 
> on a different architecture.

+100

And assembling those sysroots is not straight forward.

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

On 6/26/23 18:47, Jeff Law wrote:
> What Red Hat has done may be technically legal and perhaps good for
> its business.  However, to me it's ethically unconscionable.   Those
> who know me know I'm not an zealot, but I do have a baseline set of
> ethical values and Red Hat crossed that line.

Why is it ethically unconscionable? There is a lot of confusion around
what has happened and why. What you are saying, and what actually happened
don't line up in my mind :-)

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

2023-06-29 Thread Neal Gompa

On Thu, Jun 29, 2023 at 10:48 AM Bastien Nocera  wrote:
>
> Hello,
>
> As part of the same process outlined in Matthias Clasen's "LibreOffice 
> packages" email, my upstream and downstream work on desktop Bluetooth, 
> multimedia applications (namely totem, rhythmbox and sound-juicer) and 
> libfprint/fprintd is being stopped, and all the rest of my upstream and 
> downstream work will be reassigned depending on Red Hat's own priorities, as 
> I am transferred to another team.
>
> While it's possible that some of the maintenance will stay with me in the new 
> team, I've not yet been told which team I would be joining.
>
> Here is a list of Fedora packages which I maintained or co-maintained which I 
> won't be able to contribute to anymore:
> apfs-fuse
> bluez
> codespell
> eosrei-emojione-fonts
> geocode-glib
> gnome-bluetooth
> gnome-epub-thumbnailer
> gnome-kra-ora-thumbnailer
> gnome-user-share
> gom
> grilo
> grilo-plugins
> ifuse
> iio-sensor-proxy
> libfprint
> libglib-testing
> libimobiledevice
> libpeas
> libplist
> libportal
> libusbmuxd
> low-memory-monitor
> malcontent
> power-profiles-daemon
> sloccount
> switcheroo-control
> totem
> totem-pl-parser
> umockdev
> usbmuxd
>

I've picked up libimobiledevice as I need it for Fedora Asahi work.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP

2023-06-29 Thread Peter Boy

Hi,

> Am 29.06.2023 um 16:27 schrieb David Both :
> 
> ...
> I also spent about 4 days trying to get Dovecot to work with SendMail in
> a test VM setup. I'm either missing one or more important bits or its
> just too complex for me. None of the docs I have found anywhere has a
> complete start-to-finish picture. I find no accurate list of here's
> exactly what needs to be in place and configured in this way to make it
> work. The docs I find are incomplete because they assume much about my
> knowledge or just skip parts that are needed. Others are just plain
> wrong after trying them.

Just in case you decide for dovecot (which would be preferable, IMHO), I could 
contribute a step-by-step guide to create a workable configuration of dovecot 
(it is Part of a solution for a rather full-fledged mail service). However, the 
instructions use Postfix, not Sendmail. But because the connection runs via 
milter, the replacement with Sendmail should not be a difficult.

At the moment everything is (still) in German. But I have to translate it 
anyway, because I want to create a tutorial for Fedora Server from it. 


> 
> [1] http://www.both.org/?page_id=1183

What a coincidence, actually found this in my ePub library (though still 
unread, sorry :-) ).



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

2023-06-29 Thread Ali Alawami

Update: Apparently, this problem doesn't exist on new install/liveusb because 
dejavu is not installed so I found out that on my system I have VLC which has a 
dependency on dejavu..
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

2023-06-29 Thread Ali Alawami

Thanks everyone for this work.

I would like to point to a problem with the current config regarding Arabic 
font.
For Arabic text, The dejavu sans is still being displayed in many webpages in 
firefox instead of the noto sans.
However, when switching the system language to arabic, firefox correctly 
displays noto sans arabic which is huge improvment.
But if the system/gnome language is set to english, dejavu is frequently used 
to display some arabic texts in firefox

The problem with dejavu sans for Arabic is being incredibly ugly and borderline 
unreadable when bolded.

For example:
-at fedoraproject.org/ar most text exhibit this problem, firefox is using 
dejavu to render arabic instead of noto sans when the system/gnome language is 
english
-Youtube video titles
-Most text at podcast.google.com
-Wikipedia.org DOESN'T seem to suffer from this problem, It displays noto sans 
arabic regardless whether the system language is Arabic or English. (TLDR: this 
is the desired behavior)

Picture example of the problem: where the first pic shows FFx rendering the 
text using noto, the second pic it's using dejavu for arabic.
https://imgur.com/a/x97tCp9

Is this solvable?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP

2023-06-29 Thread Solomon Peachy via devel

On Thu, Jun 29, 2023 at 10:27:49AM -0400, David Both wrote:
> I also spent about 4 days trying to get Dovecot to work with SendMail in
> a test VM setup. I'm either missing one or more important bits or its
> just too complex for me. 

I've been running a dovecot + sendmail setup on Fedora for over 15 
years. Of the two, sendmail (or rather, making it robust against 
incoming spam) has proven to be a far greater ongoing headache; dovecot 
has pretty much JustWorked(tm).

At the end of the day the only coordination between dovecot and sendmail 
(+procmail) is ensuring they both are set up to use the same place for 
the users' mail spool.

So I'm curious as to the problems you're running into with dovecot 
specifically, and I may be able to help.

(I switched from UW-IMAP to dovecot to facilitate a migration to Maildir)

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
Dowling Park, FL  speachy (libra.chat)

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaning packages (was LibreOffice packages)

2023-06-29 Thread Bastien Nocera

Hello,

As part of the same process outlined in Matthias Clasen's "LibreOffice 
packages" email, my upstream and downstream work on desktop Bluetooth, 
multimedia applications (namely totem, rhythmbox and sound-juicer) and 
libfprint/fprintd is being stopped, and all the rest of my upstream and 
downstream work will be reassigned depending on Red Hat's own priorities, as I 
am transferred to another team.

While it's possible that some of the maintenance will stay with me in the new 
team, I've not yet been told which team I would be joining.

Here is a list of Fedora packages which I maintained or co-maintained which I 
won't be able to contribute to anymore:
apfs-fuse
bluez
codespell
eosrei-emojione-fonts
geocode-glib
gnome-bluetooth
gnome-epub-thumbnailer
gnome-kra-ora-thumbnailer
gnome-user-share
gom
grilo
grilo-plugins
ifuse
iio-sensor-proxy
libfprint
libglib-testing
libimobiledevice
libpeas
libplist
libportal
libusbmuxd
low-memory-monitor
malcontent
power-profiles-daemon
sloccount
switcheroo-control
totem
totem-pl-parser
umockdev
usbmuxd

Regards
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP

2023-06-29 Thread Dominik 'Rathann' Mierzejewski

Hello, David.

On Thursday, 29 June 2023 at 14:57, David Both wrote:
> I have noticed that uw-imap is no longer in the Fedora repo and that the
> last was F33. I like it far better than the other options because it is
> the IMAP server that best "does one things and does it well." It also
> requires the least amount of configuration and it just works so it also
> meets the KISS test.
> 
> I am willing to take it on to fix the problems that prevent it being
> properly built and to ensure that it continues to be available for
> future Fedora releases.
> 
> I can take the F33 RPM, and a couple libs from F33, install them on F38
> and it works very well. So I know that much. Hopefully it will be as
> simple as getting it to build and packaging it.

Fedora packaging and runtime environment have evolved significantly
since F33, but I wouldn't expect getting it to build on modern Fedora to
be too difficult. Most issues will probably come from GCC being more
strict. You should make it follow system crypto policy, too.

> My objectives are in sequence:
> 
> 1. Fork uw-imap and give it a new name. I would keep the current
> "provides" as uw-mail for compatibility.

You can also contact the original authors and ask if you can take over
maintenance. :)

> 2. Get it to build and install along with xinetd which is still
> required for it.
> 
> 3. Migrate it to systemd as quickly as possible.

3a. Port to OpenSSL 3 as quickly as possible.

> 4. Learn a lot!
> 
> 5. Don't change anything else unless absolutely necessary. That means no
> new "features."
> 
> 6. Fix any newly encountered bugs.
> 
> 7. Build a small team to keep it going in the future.

Sounds like a great plan. Good luck!

[...]
> I am looking at the github repo, but is it the best/most recent? I will
> try to figure out how to take that over and will go from there.

There's a repo on GitHub with the latest sources and Fedora's patches
applied on top: https://github.com/uw-imap/imap . Are you referring to
this one?

It looks like the official website was last available between Oct 28th,
2019 and Dec 22nd, 2019. This is the last functional capture at
archive.org:
https://web.archive.org/web/20191028114408/http://www.washington.edu/imap/

Reaching out to maintainers in other distros might be worthwile, too.

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP


OK - I had no idea about any of that drama.

I did find Panda IMAP and a couple others.

I also spent about 4 days trying to get Dovecot to work with SendMail in
a test VM setup. I'm either missing one or more important bits or its
just too complex for me. None of the docs I have found anywhere has a
complete start-to-finish picture. I find no accurate list of here's
exactly what needs to be in place and configured in this way to make it
work. The docs I find are incomplete because they assume much about my
knowledge or just skip parts that are needed. Others are just plain
wrong after trying them.

I know I don't have a lot of cruft to get in the way because I can use
the last snapshot before I started trying to install IMAP.

Although I am trying to do this for my own SendMail server, I am also
trying to find a simple IMAP server I can use for the email chapters in
the next edition of my books[1], "Using and Administering Linux." That's
why I really want something easy and simple.

I've also looked at Courier as it seems a simple AIO but that's not part
of any current Fedora repo. I might check it out in more detail for my
book.

Anyway - thanks for the responses. I appreciate knowing that history.


[1] http://www.both.org/?page_id=1183

--


*
David P. Both, RHCE
He/Him/His
*
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*
The value of any software lies in its usefulness
not in its price.

— Linus Torvalds
*

On Thu, 29 Jun 2023, Nico Kadel-Garcia wrote:


Date: Thu, 29 Jun 2023 09:42:13
From: Nico Kadel-Garcia 
Reply-To: Development discussions related to Fedora

To: Development discussions related to Fedora 
Subject: Re: UW-IMAP

On Thu, Jun 29, 2023 at 9:18 AM Marcin Juszkiewicz
 wrote:


W dniu 29.06.2023 o 14:57, David Both pisze:

I have noticed that uw-imap is no longer in the Fedora repo and that the
last was F33. I like it far better than the other options because it is
the IMAP server that best "does one things and does it well." It also
requires the least amount of configuration and it just works so it also
meets the KISS test.


UW IMAP development ended in 2008. Development of Panda IMAP (successor)
ended in 2012 when Mark Crispin died.

https://github.com/jonabbey/panda-imap holds complete public history.

I would rather go Dovecot rather than revive 11 years old project. Did
setup of it once, about 10 years, and it serves my private mail since then.


uw-imap got pretty weird, with Mark Crispin getting very, very upset
and accusing people of stealing his university's code if they merely
*pointed to* off-shore repositories where SSL patches were published
and could be legally imported without running into US export laws. He
had SSL hooks which he refused to publish, except for his university's
internal use. The arguments got *weird*, and heated, and some of us
were very grateful to be able to switch to dovecot and avoid the
issues.

David, have you tried dovecot as a "simple IMAP server"?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

2023-06-29 Thread Michael J Gruber

I took care of lensfun, which was not quite as much fun as it sounds:

https://src.fedoraproject.org/rpms/lensfun/pull-request/4

Could use a pair of critical python packager eyeballs, though ;-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 Cinnamon Desktop - LIGHTDM.SERVICE FAIL..!!!!

2023-06-29 Thread Leigh Scott

> Fedora 38 Cinnamon Desktop  - LIGHTDM.SERVICE FAIL..  after last 
> update 
> don't know how to fix it   
> 
> please fix / test / update ...

It works fine here.
I haven't updated lightdm since f38 release so I doubt the issue is caused by 
lightdm.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP

2023-06-29 Thread Nico Kadel-Garcia

On Thu, Jun 29, 2023 at 9:18 AM Marcin Juszkiewicz
 wrote:
>
> W dniu 29.06.2023 o 14:57, David Both pisze:
> > I have noticed that uw-imap is no longer in the Fedora repo and that the
> > last was F33. I like it far better than the other options because it is
> > the IMAP server that best "does one things and does it well." It also
> > requires the least amount of configuration and it just works so it also
> > meets the KISS test.
>
> UW IMAP development ended in 2008. Development of Panda IMAP (successor)
> ended in 2012 when Mark Crispin died.
>
> https://github.com/jonabbey/panda-imap holds complete public history.
>
> I would rather go Dovecot rather than revive 11 years old project. Did
> setup of it once, about 10 years, and it serves my private mail since then.

uw-imap got pretty weird, with Mark Crispin getting very, very upset
and accusing people of stealing his university's code if they merely
*pointed to* off-shore repositories where SSL patches were published
and could be legally imported without running into US export laws. He
had SSL hooks which he refused to publish, except for his university's
internal use. The arguments got *weird*, and heated, and some of us
were very grateful to be able to switch to dovecot and avoid the
issues.

David, have you tried dovecot as a "simple IMAP server"?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 Cinnamon Desktop - LIGHTDM.SERVICE FAIL..!!!!

2023-06-29 Thread Artur Frenszek-Iwicki

Any more details?
Anything interesting inside /var/log/lightdm?

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP

2023-06-29 Thread Marcin Juszkiewicz


W dniu 29.06.2023 o 14:57, David Both pisze:

I have noticed that uw-imap is no longer in the Fedora repo and that the
last was F33. I like it far better than the other options because it is
the IMAP server that best "does one things and does it well." It also
requires the least amount of configuration and it just works so it also
meets the KISS test.


UW IMAP development ended in 2008. Development of Panda IMAP (successor) 
ended in 2012 when Mark Crispin died.


https://github.com/jonabbey/panda-imap holds complete public history.

I would rather go Dovecot rather than revive 11 years old project. Did 
setup of it once, about 10 years, and it serves my private mail since then.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 38 Cinnamon Desktop - LIGHTDM.SERVICE FAIL..!!!!

2023-06-29 Thread André Verwijs

Fedora 38 Cinnamon Desktop  - LIGHTDM.SERVICE FAIL..  after last update 
don't know how to fix it   

please fix / test / update ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Successful Mail Delivery Report

2023-06-29 Thread Mail Delivery System

This is the mail system at host mailman01.iad2.fedoraproject.org.

Your message was successfully delivered to the destination(s)
listed below. If the message was delivered to mailbox you will
receive no further notifications. Otherwise you may still receive
notifications of mail delivery errors from other systems.

   The mail system

: delivery via spamassassin: delivered via
spamassassin service
Reporting-MTA: dns; mailman01.iad2.fedoraproject.org
X-Postfix-Queue-ID: 94C8646586863
X-Postfix-Sender: rfc822; perl-devel@lists.fedoraproject.org
Arrival-Date: Thu, 29 Jun 2023 12:59:52 + (UTC)

Final-Recipient: rfc822; perl-devel@lists.fedoraproject.org
Original-Recipient: rfc822;perl-devel@lists.fedoraproject.org
Action: relayed
Status: 2.0.0
Diagnostic-Code: X-Postfix; delivery via spamassassin: delivered via
spamassassin service
Return-Path: 
Received: from smtp-mm-cc-rdu01.fedoraproject.org (smtp-mm-cc-rdu01.vpn.fedoraproject.org [192.168.1.55])
	by mailman01.iad2.fedoraproject.org (Postfix) with ESMTP id 94C8646586863
	for ; Thu, 29 Jun 2023 12:59:52 + (UTC)
Received: from lists.fedoraproject.org (unknown [45.12.253.131])
	by smtp-mm-cc-rdu01.fedoraproject.org (Postfix) with ESMTP id 2FB4F5A3E8
	for ; Thu, 29 Jun 2023 12:59:52 + (UTC)
From: lists.fedoraproject.org 
To: perl-devel@lists.fedoraproject.org
Subject: NOTE: perl-devel@lists.fedoraproject.org =?UTF-8?B?VmVyaWZpY2F0aW9uICjwn5OrIEFjdGlvbiBSZXF1aXJlZCk=?=
Date: 29 Jun 2023 14:59:51 +0200
Message-ID: <20230629145951.fa80a6179a322...@lists.fedoraproject.org>
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

UW-IMAP