Re: Unannounced SONAME bump: libglade-2.so.6() (glade)

[Igor Gnatenko]

Thank you Kalev!

If that soname bump is needed, please rebuild glade and all affected
packages in a side tag next time.

Thanks!

On Thu, May 7, 2020 at 7:19 AM Kalev Lember  wrote:
>
> On Thu, May 7, 2020 at 6:56 AM Igor Gnatenko 
>  wrote:
>>
>> Hello,
>>
>> it seems that glade-3.36.0-1.fc33 changes SONAME from libglade-2.so.6
>> to libglade-2.so.12.
>
>
> Yes, sorry, already untagged from rawhide. I'll investigate what's up with 
> the soname bump and rebuild dependent packages if it was intentional.
>
> Kalev
> ___
> 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
___
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

Unannounced SONAME bump: libglade-2.so.6() (glade)

[Igor Gnatenko]

Hello,

it seems that glade-3.36.0-1.fc33 changes SONAME from libglade-2.so.6
to libglade-2.so.12.

That is breaking:

* anaconda-widgets-devel (anaconda) -
https://bugzilla.redhat.com/show_bug.cgi?id=1832687
* anjuta - https://bugzilla.redhat.com/show_bug.cgi?id=1832688
* gnome-builder - https://bugzilla.redhat.com/show_bug.cgi?id=1832689
* libhandy-devel (libhandy) -
https://bugzilla.redhat.com/show_bug.cgi?id=1832690
* libxfce4ui-devel (libxfce4ui) -
https://bugzilla.redhat.com/show_bug.cgi?id=1832691

And packages which depend on them.

P.S. Consider using side tags for such updates:
https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/
___
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

Re: OCaml packages in Rawhide are broken for long time

[Igor Gnatenko]

I have opened bugs for affected packages. Unfortunately did not
exclude ocaml-bin-prot, but feel free to just change status to
ASSIGNED and fix it as soon as you can.

On Mon, May 4, 2020 at 4:54 PM Jerry James  wrote:
>
> On Sun, May 3, 2020 at 1:47 AM Igor Gnatenko
>  wrote:
> > Is anybody planning to fix bunch of FTI (Fails To Install) ocaml
> > packages in rawhide?
>
> Richard tried an update to an OCaml 4.11 prerelease last week to
> address some RISC-V problems.  Unfortunately, the ocaml-camlp5 package
> needed some changes for the new OCaml version, so it failed to build,
> leaving it and everything that depends on it uninstallable.  Richard
> sent notification to this list of the issue, and of the fact that
> camlp5 changes are available so he would try again today:
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/SA6PBGIQ2QXSBWXCGBPMR52O2FGH3I3U/
>
> If you're talking about ocaml-bin-prot, I have some package reviews
> ready to go for its missing dependencies.  I'm just waiting for the
> OCaml 4.11 situation to shake out, and then I'll submit them for
> review, allowing us to finally get ocaml-bin-prot back into shape.
>
> If you're talking about something else, perhaps you could specify what it is.
> --
> Jerry James
> http://www.jamezone.org/
> ___
> 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
___
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

OCaml packages in Rawhide are broken for long time

[Igor Gnatenko]

Hello,

Is anybody planning to fix bunch of FTI (Fails To Install) ocaml
packages in rawhide?
___
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

Non-responsive maintainer check for trondham

[Igor Gnatenko]

Hello,

Anybody knows how to contact Trond?

I have sent him an email last week, but no response (neither in bugzilla).

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1827995
___
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

Issue with booting on latest kernels (EFI_DISABLE_PCI_DMA related)

[Igor Gnatenko]

Hello,

I have ThinkPad T480s and after latest kernel upgrades on Rawhide I
see something like:

```
exit_boot() failed!
efi_main() failed!
```

Right after grub and then system reboots.

I found on the internet that passing `efi=no_disable_early_pci_dma`
could help and it actually did!

Anybody else saw this issue? Any ideas if this could be worked around
in Fedora kernel?

https://bugzilla.kernel.org/show_bug.cgi?id=206789
-- 
-Igor Gnatenko
___
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

Re: Rawhide python-rpm-generators news: small speedup + %python_provide not needed in most cases

[Igor Gnatenko]

Nice job, Miro!

Thanks a lot for working on this.

On Fri, Apr 3, 2020 at 8:45 PM Miro Hrončok  wrote:
>
> Hello Python packagers.
>
> I have just updated python-rpm-generators to python-rpm-generators-11-1.fc33 
> in
> Rawhide. It uses some fresh stuff from RPM 4.16 and will not be backported to
> older releases.
>
>
> The python(abi) requirement is now added from a RPM Lua macro, instead of by
> executing a Shell script. This is a bit faster especially for packages with a
> lot of files. For 10 000 files in one package, the speedup is roughly from ~80
> to ~2 seconds (time of the entire package build incl. creating the files from 
> a
> Python script). That is a lot, but most of the real packages have much less
> files, so I am afraid you won't feel it.
>
>
> More importantly, %python_provide is not needed for package names.
> Until now, we needed to this:
>
>  %package -n python3-foo
>  ...
>  %{?python_provide:%python_provide python3-foo}
>
> This adds automatic provides "python-foo" (and since recently, also
> "python38-foo" for forwards/backwards compatibility with EL). This now happens
> automagically. Any package called "python3-..." will have those provides added
> implicitly by the Python generators when they are in the buildroot
> (python3-devel brings those in, so for Python packages this means always).
>
> This automation was possible due to the speedup mentioned above, doing it the
> pre-RPM.16 way would be very slow, because the generator is called for every
> packaged file (which is still the case now, but it can now be a Lua macro). 
> The
> ~2 seconds from above include this new feature.
>
> There are 2 cases where manual %python_provide calls are still needed:
>
> 1. Metapackages without files
>
> No files => no dependency generator. (I recommend to %ghost the
> dist-info/egg-info directory in such packages to workaround this -- we plan to
> add more good stuff regarding Python [extras] that will require this anyway.)
>
> 2. Virtual provides
>
> The dependency generator can see the (sub)package's name, but not any other
> virtual provides. When you do:
>
>  %package -n python3-%{pypi_name}
>  Provides: python3-%{legacy_name} = %{version}-%{release}
>
> You are still supposed to add:
>
>  %{?python_provide:%python_provide python3-%{legacy_name}}
>
> (Also note that %python_provide adds obsoletes for older python-foo versions,
> that was useful when we renamed everything from python-foo to python2-foo and
> when we changed the "default" from python2- to python3-. We are keeping the
> Obsoletes in the macro (for now), but I have decided to not automatically
> generate the Obsoletes based on the package name. A) I don't consider them
> really needed in Fedora 33 any more and B) an idea of implicit obsoletes 
> doesn'T
> sound very intriguing to me. This is a decision that may be revisited later if
> it's bringing unforeseen trouble.)
>
> You don't need to to actively remove the macro from your spec files, it does 
> no
> harm. If you prefer to maintain a single spec, keep it there until Fedora 32
> goes EOL (and EPEL 8 if that's your target). The guidelines always recommended
> using it the safe way (%{?python_provide:...}), so even if it ceases to exist 
> in
> the future, it can remain in specs. There is no plan to remove it in any near 
> or
> distant future, as it is still needed for the virtual provides. The generators
> also use it internally (for DRY and consistent results).
>
> If you'll get into trouble because of this, let us know and we'll fix it.
>
> I'll make a note for myself to update the Python packaging guidelines.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Re: Rawhide update from side tag pending for 2 days

[Igor Gnatenko]

I agree, if this would not happen then everything would just blow up.

On Wed, Apr 8, 2020 at 8:33 AM Clement Verna  wrote:
>
>
>
> On Tue, 7 Apr 2020 at 23:38, Mohan Boddu  wrote:
>>
>> I guess it should be a fixed in bodhi. But for now you can remove the
>> builds that it's complaining about in the update.
>>
>> https://github.com/fedora-infra/bodhi/issues/3991
>
>
> Answered in the ticket, but I think Bodhi is behaving correctly there. When 
> trying to merge the side tag, if Bodhi find a more recent build in the target 
> tag it will push back the update to pending and comment on the update that 
> there are more recent builds in the target tag. Then it is up to the packager 
> to resolve the conflict (either rebuild the conflicting packages or remove 
> them from the update).
>
>>
>>
>> On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones  wrote:
>> >
>> >
>> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
>> >
>> > This one is a Rawhide update from a side tag, submitted on Sunday
>> > morning which has been in pending for 2 days.  (As it's Rawhide it's
>> > supposed to spend 0 days in testing.)  Is there any problem with it,
>> > or do we just have to wait longer?  It is blocking builds of other
>> > packages.
>> >
>> > Rich.
>> >
>> > --
>> > Richard Jones, Virtualization Group, Red Hat 
>> > http://people.redhat.com/~rjones
>> > Read my programming and virtualization blog: http://rwmj.wordpress.com
>> > virt-df lists disk usage of guests without needing to install any
>> > software inside the virtual machine.  Supports Linux and Windows.
>> > http://people.redhat.com/~rjones/virt-df/
>> > ___
>> > 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
>> ___
>> 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
>
> ___
> 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
___
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

Re: Bodhi 5.2.0 deployed in production.

[Igor Gnatenko]

Hello Clement,

On Mon, Mar 23, 2020 at 10:30 AM Clement Verna  wrote:
>
> Hi all,
>
> I have just deployed Bodhi 5.2.0 in production. This version should improve 
> the performance of updates creation since the expansive task of tagging 
> builds in koji has been moved to an async process using a celery workers.
> Also this version will also allow the use of side-tags to all releases (ie 
> not limited to rawhide anymore).

I'll test this ASAP.

> For a more detail view of the changes you can consult the release notes [0].
>
> I would like to thanks everyone that has contributed to this release [1].
>
> Thanks
> Clément
>
> [0] - https://bodhi.fedoraproject.org/docs/user/release_notes.html
> [1] - 
> https://bodhi.fedoraproject.org/docs/user/release_notes.html#contributors
> ___
> 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
___
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

HEADS UP: rust-psm license change (ISC/Apache-2.0 → MIT/Apache-2.0)

[Igor Gnatenko]

Effective since version 0.1.7.

-- 
-Igor Gnatenko
___
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

Re: Non-responsive maintainer: pwalter

[Igor Gnatenko]

This would be nice. It is blocking from upgrading tokei and bunch of
other Rust-based packages in F31.

I am out of time and not willing to do anything related to pushing new
libgit2 in F31, so would be happy to assist anybody who will pick this
work up.
On Sat, Mar 21, 2020 at 10:45 AM Fabio Valentini  wrote:
>
> On Sat, Mar 21, 2020, 09:42 Neal Gompa  wrote:
> >
> > Hello all,
> >
> > I've been trying to get in touch with Pete Walter for a few months now
> > w.r.t. python-pygit2[0]. Unfortunately, he hasn't been responding to
> > my emails[1][2][3] (he was CC'd to all of those) or the bug I filed
> > requesting pygit2 for EPEL 8[4].
> >
> > I've also filed the requisite non-responsive maintainer check bug:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1815734
> >
> > Does anyone know how to get in touch with him?
>
> You could try to resubmit Igor's libgit2-0.99 update to f31+f32, that
> seems to have got his attention ...
>
> Fabio
>
> >
> > [0]: https://src.fedoraproject.org/rpms/python-pygit2
> > [1]: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GFQVBB5GLGYNBVYRUBEJN5ZSZXDCF4V5/
> > [2]: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FCGFN5475HL37JL3W6MNLX4SAUCBTPUE/
> > [3]: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LBO6PQBZNYONMTFKSWLF6HAGY2KAXV43/
> > [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1803544
> >
> > --
> > 真実はいつも一つ！/ 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
> ___
> 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
___
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

Re: Reducing broken dependencies in fedora (32) repositories

[Igor Gnatenko]

No. All dependencies and such are in Fedora Build System and kept there as
any other package.

On Wed, Mar 11, 2020, 14:10 Peter Robinson  wrote:

> On Wed, Mar 11, 2020 at 12:58 PM Randy Barlow
>  wrote:
> >
> > On 3/9/20 11:53 AM, Fabio Valentini wrote:
> > > Source-only rust packages (those only shipping noarch -devel
> > > subpackages) have been untagged from f32 on purpose by Igor. For
> > > reasons I disagree with:)
> >
> > I too wish that we kept the Rust devel packages in stable releases. I am
> > unable to build updates for my Rust packages by myself since their
> > dependencies have been untagged. I recently noticed that a license tag
> > was wrong in my Rust packages, and I had to ask for administrator help
> > to get it fixed since I don't have permissions to set up the side tags
> > and get the crates tagged into them.
> >
> > I will admit that I don't understand the reasoning behind the decision
> > to remove these packages from non-rawhide releases. Igor, could you tell
> > us why this is done?
>
> Is there also a possible license issue here, license depending, that
> it's not a reproducible build?
> ___
> 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
>
___
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

Re: Reducing broken dependencies in fedora (32) repositories

[Igor Gnatenko]

We could if somebody will commit on maintaining those packages in stable
releases, keep them always updated, insert proper Obsoletes and create
compat packages all the time.

The good news are that Koji maintainers implemented necessary configuration
and when new version will be released and deployed in infra, anybody will
be able to update them in stable using SOP.

On Mon, Mar 9, 2020, 18:40 Zbigniew Jędrzejewski-Szmek 
wrote:

> On Mon, Mar 09, 2020 at 04:53:25PM +0100, Fabio Valentini wrote:
> > On Mon, Mar 9, 2020 at 4:42 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote:
> > > >
> https://pagure.io/fedora-health-check/blob/master/f/reports/report-32.md
> > > > Report with testing repos enabled:
> > > >
> https://pagure.io/fedora-health-check/blob/master/f/reports/report-32-testing.md
> > >
> > > I see a lot of rust packages on this list, but I can't quite figure out
> > > what is wrong:
> > >
> > > For rust-zram-generator, mock says:
> > >  Problem 1: nothing provides requested (crate(failure/default) >=
> 0.1.0 with crate(failure/default) < 0.2.0)
> > >  Problem 2: nothing provides requested (crate(failure_derive/default)
> >= 0.1.0 with crate(failure_derive/default) < 0.2.0)
> > >  Problem 3: nothing provides requested (crate(rust-ini/default) >=
> 0.13.0 with crate(rust-ini/default) < 0.14.0)
> > >
> > > But rust-failure-0.1.6-1.fc32 is the last build in F32 and it has
> > > rust-failure+derive-devel-0.1.6-1.fc32.noarch.rpm which has
> > > Provides: crate(failure/derive) = 0.1.6.
> > >
> > > I'm confused why it's not getting picked up.
> > >
> > > Oh, I see now:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1416018
> > > has Tags: f31-build-side-17673 f31-build-side-17691
> > >   f31-build-side-17821 f31-build-side-19481
> f32-build-side-19483 f33
> > > but not f32.
> > >
> > > Igor, Josh?
> >
> > Source-only rust packages (those only shipping noarch -devel
> > subpackages) have been untagged from f32 on purpose by Igor. For
> > reasons I disagree with :)
> > So all the missing dependencies in rust packages (that are shipping
> > binaries) on f32 are there because there are no source-only rust
> > packages on f32 at all ...
>
> Hi Igor,
>
> can we please revisit this decision? We need rust-*-devel to do package
> reviews, rebuilds, and whatnot.
>
> Zbyszek
> ___
> 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
>
___
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

Re: GNOME 3.35.92 megaupdate

[Igor Gnatenko]

It is basically the same. The only difference is that name of the tag.

On Mon, Mar 2, 2020 at 3:18 PM Kalev Lember  wrote:
>
>
> On 3/2/20 15:04, Richard Shaw wrote:
> > On Mon, Mar 2, 2020 at 7:57 AM Kalev Lember  > > wrote:
> >
> >
> > Hi all,
> >
> > I am putting together a megaupdate for GNOME 3.35.92. If you are
> > helping
> > with builds, please wait until we have the f32-gnome side tag
> > (requested
> > in https://pagure.io/releng/issue/9292) and then do the F32 builds with
> > 'fedpkg build --target f32-gnome'. I'll collect all the builds tagged
> > with f32-gnome for the megaupdate and submit them to Bodhi all together.
> >
> >
> > I thought you could just use 'fedpkg request-side-tag [...]" at this point?
>
> Yes, but this is meant for short lived side tags, not for something that
> we keep around for months to coordinate updates between a number of people.
>
> --
> Kalev
> ___
> 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
___
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

HEADS UP: libgit2 0.99.x is coming to Rawhide

[Igor Gnatenko]

Hello,

The libgit2 finally gets closer to 1.0 release, so this is one of
"pre-releases". Of course, this involves soname bump :)

The API should not be broken compared to 0.28.x, so I'm going to
rebuild everything in side tag and then submit update for all the
affected packages at once.

Stay tuned.
___
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

[EPEL-devel] Ansible & Python 3 in EPEL7

[Igor Gnatenko]

Hey folks,

We recently started to use Ansible more and we are using some ansible
collection which is not compatible with Python 2.

Are there any plans to switch Ansible to Python 3 in EPEL7 or are
there any recommendations what to do in such cases as we have?
-- 
-Igor Gnatenko
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Include non-RPM content in buildroot

[Igor Gnatenko]

Hi Martin,

I was quite busy lately so did not have time to reply.

(Most of the time I'll speak for Rust ecosystem below)

On Fri, Feb 21, 2020 at 4:06 PM Martin Sehnoutka  wrote:
>
> Hi,
>
> before I write the proposal itself I just want to stress the fact that
> it isn’t my intention to change the current packaging workflow and
> definitely not the user experience. Also if you have C or Python
> packages it would not affect your work at all (I’m not familiar with all
> interpreted languages in Fedora, but I guess it is similar to Python and
> therefore it is not affected by the problems I am going to describe).

I disagree, Python has same registry (PyPI) as Rust does (crates.io)
and. Of course, there are different problems in different ecosystems,
but approach should be same to all.

>
> First of all, let me describe the problem I see in our Fedora ecosystem
> with relation to Go and Rust language ecosystems. More specifically in
> the relation between RPM buildroot and packages in these ecosystems.
> Both of these languages follow the idea that packages should be small
> and only have a limited set of features. Developers then use a lot of
> these packages to write the final executable that is meant for end-users
> [1]. Also both of these languages use static linking of the final
> binaries meaning that Fedora users don’t install RPM packages of these
> libraries as they are already baked inside of the binary [2].

Technically, we can do dynamic linking. The problem is that there is
no stable ABI, so even rebuild of the same sources with different
version of compiler can result into a different thing.

I can't speak for Go, but in Rust the crate (aka library) can be used
(compiled) with different features. So we would either need to produce
libraries with all combinations of those features set or ship one big
library with all of them included. That would mean, the dependency set
will grow and most likely we won't save any space, or even worse,
waste it. Until some amount of packages which are common on all
systems, of course.

By the way, Haskell has very similar problem, they just put hashes all
over the place to ensure that all packages are rebuilt.

>
> The 1st problem is that if we want to build RPMs of the final
> executables the way we do now, we need to package all these small
> libraries into RPM even though they are just build dependencies and
> users never install RPMs of these libraries. Many of these RPMs are
> automatically generated from the upstream packages meaning that we don’t
> do anything except for unpacking the upstream package (e.g. plain
> tarball in case of crates.io)  and then we package the same into RPM.
> This process is unfortunately not fully automated and therefore requires
> a certain amount of human effort.

As others pointed out, we do audit licenses. But apart from that, we also do:
1) cargo build and cargo test to ensure that the crate actually works
2) Try to patch them to rely on latest version of crates
3) Add patches to use system versions of libraries (libcurl,
oniguruma, libssh2, …)

We did found many issues related to 32bit, endianess and even when
bumping version of dependency, you can find that there is actual bug
in the code of crate
(https://github.com/budziq/rust-skeptic/pull/116#issuecomment-590009805)

>
> To sum up the previous paragraph, I don’t think it is necessary to
> repackage upstream tarball into a downstream RPM.

If it is automated, why do you think so? If you have different
ecosystems, being able to check something across all ecosystems in the
same way (aka using just rpm instead of pip, cargo, go, …).

>
> The 2nd problem is present only in the Rust ecosystem (as far as my
> knowledge goes). Cargo, the official package manager for Rust, can
> handle the scenario where an executable depends on a single library in
> two different versions [3]. Dnf, on the other hand, will not install two
> versions of the same RPM package. What we do now is, that we patch the
> affected executables and libraries to only use the newest versions
> everywhere. This is again an additional maintenance cost and we create
> differences from upstream, because these patches are not necessarily
> merged. See this as an example:
> https://src.fedoraproject.org/rpms/rust-bstr/blob/master/f/rust-bstr.spec#_17
> https://github.com/BurntSushi/bstr/pull/23

As others, pointed out - we can (and we do) compat packages.

What do you propose to do if there is, let's say vulnerability in the
version some crate depends on and upstream is not responsibe?

95+% of our patches are merged into upstreams sooner or later
(excluding dead upstreams).

>
> To sum up the 2nd problem: we are using dnf instead of the upstream
> package manager to install dependencies. These two approaches can be
> incompatible (and they are in case of Rust).

That's not exactly true, we do mirror what Cargo does with RPM. And
that works pretty well.

>
> The 3rd problem I see is that issues like this are 

Re: Ideas and proposal for removing changelog and release fields from spec file

[Igor Gnatenko]

On Mon, Feb 24, 2020, 18:38 Miro Hrončok  wrote:

> On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> > However, for the release field, we are struggling a little bit more, two
> options
> > are more appealing to us:
>
> Can we please have a "git is the only source of truth" version of this?
> I.e.
> "Compute the release field from the number of commits since the last
> version
> change" in the document. It seem to only have one con (breaks if two
> builds are
> triggered from the same commit) which is the status quo.
>
> If you need to rebuild for a libpingouisawesome soname bump, you just do
> an
> empty commit with the explanation.
>
> If you merge that empty commit to a branch that did not need it, it would
> have a
> bogus changelog entry (status quo). If you care, you would not merge but
> cherry-pick anything thta comes next (which is now much easier given the
> benefit
> of not having the %changelog and release).
>
> With the proposed solution that includes "successful build count" you
> always
> bump and build even if it is not needed and also you make the release
> number
> depend on a specific build system, which I think is kinda wrong.
>
> i.e. if you do two "fedpkg build" in a row without a commit, I think that
> the
> second one should still fail with "already been build" kind of message.
>

What if build environment has changed?


> --
> 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
>
___
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

Re: Announcement: EPEL Steering Committee Changes

[Igor Gnatenko]

Then who is the best person?

On Wed, Feb 19, 2020, 07:11 John M. Harris Jr  wrote:

> On Tuesday, February 18, 2020 10:35:26 AM MST Stephen John Smoogen wrote:
> > Hi,
> >
> > It has been a pleasure for me to be a part of and help lead the
> > EPEL steering committee for the last couple of years. It has not
> > always been smooth sailing but I have found it an enjoyable experience.
> >
> > However, as you may know the Fedora project will be moving to a
> > different data-center later this spring (from Phoenix to northern
> > Virginia). Being involved in the planning and implementation of this
> > project, I do not think that I will be able to give EPEL the time
> > investment it deserve for the next 6 to 9 months. With EPEL-8 still
> > ramping up and the various opportunities with modularity, I do
> > not think it is a fair that EPEL suffers from this lack of time.
> >
> > As such, I would like to step down as chair/member of the steering
> > committee and nominate Troy Dawson as my replacement. Troy formerly
> > worked on Scientific Linux and has worked on OpenShift and other
> > projects at Red Hat for the last several years.  It is clear he has a
> > good eye on the concerns and problems enterprise users have. Recently,
> > Troy helped get the initial RHEL-8 and EPEL-8 out the door with
> > multiple builds and updates to various macro files.
> >
> > Once the move is completed and the close down of the old site is done,
> > I look forward to getting involved again in EPEL.
>
> Based on this, I'm not so sure that Troy is the best person to take that
> place
> within EPEL's Steering Committee. As an enterprise admin, RHEL8 has been
> nothing but a nightmare to deal with because of Modularity. I know Troy
> didn't
> singlehandedly sign off on that nonsense, but, as he is a member of the
> Modularity team, this is not a good sign for what's to come.
>
> --
> John M. Harris, Jr.___
> 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
>
___
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

How to write License field for packages bundling mutliple others

[Igor Gnatenko]

In Rust world we package all crates as source code in -devel packages.
Then we use them to build the real applications.

Some time ago, someone noticed that we don't put licenses of those
-devel packages into a resulting RPM with app which is fair.

However, I'm not entirely sure how to properly write the License tag.
What should be there if -devel packages have:

* ASL 2.0
* ASL 2.0 or Boost
* ASL 2.0 or MIT
* ISC
* MIT
* (MIT or ASL 2.0) and BSD
* Unlicense or MIT

Is it correct to put License: ISC and MIT and ASL 2.0 and BSD?
___
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

Re: How to get proper nsswitch.conf?

[Igor Gnatenko]

Hi Florian,

By "proper" I mean something supported and pristine so that I don't
end up with debugging weird problems. Some people name it "default".

I don't need anything special, just the one which should be by default
in Fedora Workstation.

On Thu, Feb 13, 2020 at 5:25 PM Florian Weimer  wrote:
>
> * Igor Gnatenko:
>
> > I've noticed that glibc ships one nsswitch.conf, but then it is
> > entirely overridden by authselect... What is the proper way of getting
> > proper nsswitch.conf on the system?
>
> authselect is not the only package editing nsswitch.conf, other packages
> do it as well.  I have lost track.
>
> Unfortunately, Fedora does not have a ban against scriptlets editing
> configuration files.
>
> Anyway, what do you mean by “proper”?  It really depends on what you
> need, and also on personal preferences.
>
> Thanks,
> Florian
___
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

How to get proper nsswitch.conf?

[Igor Gnatenko]

Hello,

I've noticed that glibc ships one nsswitch.conf, but then it is
entirely overridden by authselect... What is the proper way of getting
proper nsswitch.conf on the system?
___
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

Re: Packaging of Ansible collections

[Igor Gnatenko]

The goal is to be able to use ansible with collections installed via
RPM without having to connect to the internet.

On Mon, Feb 10, 2020 at 4:45 PM Bill Nottingham  wrote:
>
> Igor Gnatenko (ignatenkobr...@fedoraproject.org) said:
> > Hello,
> >
> > Did anybody had an experience of packaging Ansible collections into an RPM?
> >
> > I guess if would be enough to put the files somewhere under
> > /usr/share/ansible, but not sure. Also I'm not sure what download URL could
> > be used.
>
> What is the goal of downstream collection packaging here - what collections
> are you looking to package and why?
>
> Bill
> ___
> 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
___
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

Packaging of Ansible collections

[Igor Gnatenko]

Hello,

Did anybody had an experience of packaging Ansible collections into an RPM?

I guess if would be enough to put the files somewhere under
/usr/share/ansible, but not sure. Also I'm not sure what download URL could
be used.
___
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

Re: satyr soname bump

[Igor Gnatenko]

What does it mean "us? I see that ABRT has broken dependencies in
rawhide. I would appreciate if you could use side tag to build new
version + rebuild all packages which depend on it in there.

On Thu, Feb 6, 2020 at 3:15 PM Ernestas Kulik  wrote:
>
> satyr 0.30 was built with a bumped soname. AFAIK, this will only affect
> us, but for anyone else out there - beware.
>
> --
> Ernestas Kulik
> Associate Software Engineer - Base Operating Systems (Core
> Services/ABRT)
> Red Hat Czech, s.r.o.
> ___
> 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
___
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

Re: Any issues booting Rawhide kernel-5.6.0-0.rc0.git1.2.fc32.x86_64?

[Igor Gnatenko]

I have the same issue since 5.5.0 release kernel. Latest one which
works for me is 5.5.0-rc6.git3.2.

I was not sure how to debug this, so I did not submit a bug report.

I have this issue on the ThinkPad T480s with latest firmwares and so on.


On Thu, Feb 6, 2020 at 2:10 PM Richard W.M. Jones  wrote:
>
> I tried out this kernel:
>
> - kernel-5.6.0-0.rc0.git1.2.fc32.x86_64
>
> It gets to grub, lets you select the kernel, but apparently no
> further.  It's kind of frustrating to debug because either it produces
> *no* messages at all even in verbose mode, or else it's screwing up
> the display somehow so that nothing can be seen.
>
> I moved back to kernel-5.5.0-0.rc6.git2.1.fc32.x86_64 which boots
> fine, so I don't think it's a UEFI or grub issue.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> ___
> 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
___
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

How to package a web service (nginx vs httpd)

[Igor Gnatenko]

Hello,

I am working on packaging
[netbox](https://github.com/netbox-community/netbox/) which is
basically web service which is run via gunicorn and then it is up to
admin to decide whether he wants to use nginx, httpd or anything else.

Do we have somewhere written best practices how to package such things?
___
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

Re: Ideas for better development processes when maintaining hundreds of packages

[Igor Gnatenko]

It would be nice if you could look into existing code instead of writing
new one: https://github.com/ignatenkobrain/git-rpm-changelog

On Tue, Jan 28, 2020, 12:43 Pierre-Yves Chibon  wrote:

> On Tue, Jan 28, 2020 at 09:03:09AM +, Richard W.M. Jones wrote:
> > I always think that Fedora works fine if you maintain 1-5 packages.
> > It's possible to maintain 20 with a lot of work.  And if you want to
> > maintain 100+ (things like the ocaml-* set that I help to maintain)
> > then you have to write your own automation.  Could we do things
> > better?  No one asked for them, but here are my ideas ...
> >
> > ---
> >
> > * kill the %changelog
> >
> > Please, let's kill it, and generate it from the git changelog.
> > I'm glad to see there's a proposal to do this.
> >
> > A general principle I'm following here is a packager should never
> > be asked to enter the same information twice.
>
> There are a few tricky things about this, but overall I think it's doable
> and
> some of the tricky things may just be things we just have to accept as
> being
> different from the current situation.
>
> We are playing a bit of a proof of concept of what a RPM changelog
> generated
> from git logs could look like. The outcome of this is at:
> https://pagure.io/Fedora-Infra/generate_changelog/tree/master
>
> Feel free to poke at it and see how it behaves.
>
> The script only considers:
> - the last two years of commits
> - commits touching either the spec file or patches (ending with .patch)
>
> We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the current
> commit that should be ignored), as well as a way to say: [Replace XXX] to
> be
> able to replace an existing commit message, but that's not there yet.
>
> One of the thing that may change is that we may end up with changelog
> entry that
> do not have a corresponding nvr at the end.
> The python script above shows that, it'll only add the v-r in the
> changelog when
> either one of them changed, if they are the same, it doesn't specify them.
>
> Another aspect that is getting trickier is:
> - update to 1.1-1
>   
> - fix missing BR
>   
> - spec clean up
>
> 3 commits, can all be either on 3 different days but could also be on the
> same
> day. Could be from 3 different people, but could also be from the same
> person.
> So we could have 3 commits, on 1 day from 1 person, two of which would make
> sense to group together (update to 1.1-1 and fix missing BR) and one that
> shouldn't since the build succeeded before that and thus the -1 that goes
> out to
> the mirror will not have this clean up entry.
> The current approach we took is: we have 3 entries in the changelog (and
> only
> one has the v-r specified). It's not ideal, but we don't quite see how to
> solve
> this question yet.
> If the "spec clean up" contains "[ignore]", that question is solved, but
> if we
> replace "spec clean up" with "Drop sub-package foo" then we do not have a
> good
> idea on how to consolidate the commit messages into a single changelog
> entry.
> Suggestions welcome :)
>
>
> > * committing to git should build the package
> >
> > Is there a reason why this wouldn't be the case?
>
> That was part of the proposal we debated last fall and there seemed to be
> much
> more people against this than I thought there would be.
> Maybe we could start with having an opt-in approach.
>
> > * commit groups of packages together
> >
> > One reason why automatic commit -> build might not be desirable is if
> > you're trying to build a group of packages in a side tag.  In my
> > opinion this means we should allow groups of packages to be committed
> > together.  (Unfortunately because we chose to put every package in its
> > own git repo, the obvious way to do this can't work, but we could
> > still have a "ChangeId:" header in the commit message that ties
> > packages together).
> >
> > The packages should be built in build dependency order into a side
> > tag, and the side tag turned into an update, with no further
> > involvement from the packager unless something fails to build.
> >
> > This change on its own would solve the main problem that
> > affects people maintaining large sets of packages.
>
> If we use a magic word to support opt-into automating commit -> build, we
> could
> get partly there.
> BuildIn: Fedora, EPEL
> BuildIn: 
> BuildIn: rawhide
> ...
>
> > * “Fixes:” etc headers in git
> >
> > RHEL already does this.  It should be possible to add special headers
> > to the commit message to automatically close bugs, ie:
> >
> >   $ git commit -m "ocaml: Update to version 4.10.0
> >   Fixes: RHBZ#12345"
> >
> > Note the build, update and bug closing would happen completely
> > automatically, assuming there was no build or test failure.
>
> We clearly don't have a good mapping from commit messages to bugzilla.
> dist-git has the info, either in the rpm changelog or in the git commit
> messages
> koji has only the info of the git commit it was triggered from
> bodhi works at the 

Re: koji / bodhi issues status update

[Igor Gnatenko]

No, that's not true. Anybody can tag their builds into a
f31-updates-candidate and such tags.

On Fri, Jan 10, 2020 at 4:03 AM Sérgio Basto  wrote:
>
> On Thu, 2020-01-09 at 09:17 +0100, Pierre-Yves Chibon wrote:
> > On Wed, Jan 08, 2020 at 10:32:42PM +, Sérgio Basto wrote:
> > > Hi, a little "by the way" , I think if koji fails to tag the build
> > > or
> > > anything else, the final result should be failed, to avoid
> > > inconsistencies. I opened an issue on koji [1]
> > > [1]
> > > https://pagure.io/koji/issue/1895
> >
> > We'll see how it goes, however I am not enthusiastic about this idea,
> > tagging a
> > build is a much shorter task than doing a full rebuild (think
> > LibreOffice or
> > something along those lines that takes 1h+ to build, the tagging
> > operation is
> > done in seconds).
> > I agree that build without tags are harder to debug, especially if
> > you do not
> > know what to look for, but once you do and know how to fix, it's a
> > much quicker
> > solution.
>
> Let me disagree with your arguments, in two points .
>
> - Save time, if we count the times losses and gains, I think we didn't
> save time. quite the opposite, because we have to review all builds,
> search for all inconsistencies, etc ...
>
> - Second point is the fix, the fix just can be done by one admin , i.e.
> an regular user without admin permissions can't tag the build and the
> workaround is build another release which is an ugly solution.
>
> Best regards,
> --
> Sérgio M. B.
> ___
> 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
___
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

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Igor Gnatenko]

So this just means that packages do not respect the environment. What about
fixing them instead of trying to hack the environment?

On Wed, Jan 8, 2020, 23:53 Tom Stellard  wrote:

> On 12/23/2019 11:59 AM, Tom Stellard wrote:
> > On 12/21/2019 02:30 PM, Tomasz Kłoczko wrote:
> >>
> >>
> >> On Sat, 21 Dec 2019 at 00:37, Neal Gompa  ngomp...@gmail.com>> wrote:
> >> [..]
> >>
> >> I believe it's also used by the %cmake and %meson macros.
> >>
> >>
> >> Yep.
> >> Look on the output of the “rpm -E %cmake” and you will find that to
> switch to other C and C++ compilers all what you need to do is redefine
> %__cc and %__cxx macros,
> >
> > I'm not seeing this, at least with the current rawhide build, but I
> > patched cmake to enable this in the latest mass rebuild that I'm doing.
> > I'll post numbers on how effective using __cc and __cxx are once it's
> > complete.
> >
>
> I completed a rebuild of all rawhide with the following modifications:
>
> 1. Added this to %set_build_flags
>
> CC="${CC:-%{__cc}}" ; export CC ; \
> CXX="${CXX:-%{__cxx}}"; export CXX ; \
>
> 2. Added %set_build_flags to %cmake macro
>
> 3. Remove -fstack-clash-protection and add -Qunused-arguments flags to
> %optflags
>
> 4. Set these macros:
>
> config_opts['macros']['%__cc'] = "clang"
> config_opts['macros']['%__cxx'] = "clang++"
> config_opts['macros']['%__cpp'] = "clang-cpp"
> config_opts['macros']['%build_cflags'] = optflags
> config_opts['macros']['%build_cxxflags'] = optflags
>
>
> Here are the results:
>
> Packages Built: 4228
> Built with clang: 2695
> Built with gcc: 1533
>
> Based on grep'ing logs, around 320 of the packages built with gcc invoke
> gcc using cc or c++.  It's hard to know the exact number though, because
> I'm not sure if all packages echo their build steps and also my grep
> expressions
> may not have caught everything.
>
> I suspect that if I can find some way to set the CC and CXX environment
> variables for all builds, not just ones using autoconf, cmake or meson,
> that might help cut down on the number of packages that still use gcc.
> I'm just not quite sure how to implement this yet, but I'm looking into
> it.
>
> -Tom
>
>
> > -Tom
> >
> >> The same is with %configure and %meson,
> >>
> >> In other words you can switch NOW from non-root account to other
> compiler without execution update-alternatives from root.
> >>
> >> In other words this proposal is pointless.
> >>
> >> kloczek
> >> --
> >> --
> >> Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH*
> > ___
> > 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
> >
> ___
> 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
>
___
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

Re: Upgrading libffi

[Igor Gnatenko]

If you push changes to the dist-git, I can handle builds and rebuilds.

On Wed, Jan 8, 2020, 19:58 Kevin Fenzi  wrote:

> On Tue, Jan 07, 2020 at 10:20:59AM -0500, Anthony Green wrote:
> > Neal Gompa  writes:
> >
> > > RPM does not use libffi at all.
> >
> > My bad.. rpmbuild, through it's use of gdb, which requires python, which
> > requires libffi.  So my naive use of mock to try to build a new version
> > of libffi and all of it's dependencies fail.
> >
> > > That said, it's quite easy to do a
> > > rebuild of libffi's reverse dependencies in a side-tag and then merge
> > > it back in.
> >
> > Ok, I suppose I'm willing to try, but I have no idea what a side-tag is.
> > Repoquery tells me there are 192 packages that depend directly on
> > libffi.
> >
> > > You can always ask for help from releng or other folks
> > > around here to help get it done.
> >
> > Could somebody please walk me through the first few steps?  Maybe start
> > by explaining side tags?
>
> A side tag is a tag in koji where you can build things and they don't
> affect other packagers/the real buildroot/tags.
>
> In your libffi master checkout:
>
> fedpkg request-side-tag
>
> and it should give you a tag you can build things into.
>
> Unfortunately since things in the buildroot depend on libffi, you can't
> just simply build the new libffi and then rebuild everything in the side
> tag, because after you build the new libffi there, the buildroot would
> break.
>
> You can make a compat package, but if everything is fine to move to the
> new one thats overkill. I don't know if there's anything guideline wise
> about this, but easiest might be to add a compat subpackage in the
> existing libffi package where you simply copy the old so files from the
> existing build in the buildroot, then rebuild against the new libfii in
> the side tag, then drop the compat subpackage. I suppose you could also
> add both old and new libffi source to the libffi package and build them
> both (old to compat), rebuild in side tag and drop the old
> sources/compat.
>
> Does that make sense?
>
> If you don't want to/have time to do it, perhaps file a releng ticket
> and we can coordinate folks to do it there.
>
> 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
>
___
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

Re: Heads up: Updating Python RPM dependency generators

[Igor Gnatenko]

Ugh, that is a bug in the generator. It should do something like ((x
with y) or (z with 0)).

On Fri, Jan 3, 2020 at 10:26 AM Miro Hrončok  wrote:
>
> On 02. 01. 20 9:59, Miro Hrončok wrote:
> > Hello, this is just a heads up that we are about to update the Python RPM
> > dependency generators to support versions like 1.2.*, the ~= operator etc.
> >
> > See the PR:
> >
> > https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/4
> >
> > The code is tested and no backwards incompatible breakage is anticipated 
> > (some
> > requirements might end up being a bit different thou). If you get a weird
> > behavior or broken deps because of this, please report here or trough 
> > bugzilla.
>
>
> https://koschei.fedoraproject.org/package/python-matplotlib?collection=f32
>
> Cannot chain different ops: (python3.8dist(pyparsing) >= 2.0.1 with
> python3.8dist(pyparsing) < 2.1.2 or python3.8dist(pyparsing) >= 2.1.2.0 with
> python3.8dist(pyparsing) < 2.1.6 or python3.8dist(pyparsing) >= 2.1.6.0 with
> python3.8dist(pyparsing) < 2.0.4 or python3.8dist(pyparsing) >= 2.0.4.0)
>
>
> https://koschei.fedoraproject.org/package/python-sphinx?collection=f32
>
> Cannot chain different ops: (python3.8dist(babel) < 2 or python3.8dist(babel) 
> >=
> 2.0 with python3.8dist(babel) >= 1.3)
>
> --
> 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

Re: peek package

[Igor Gnatenko]

But what about users which actually have ffmpeg installed? Do you think
they don't deserve having peek in menu?

On Fri, Jan 3, 2020, 04:02 John M. Harris Jr  wrote:

> On Wednesday, January 1, 2020 7:34:27 PM MST Leigh Scott wrote:
> > > Why we should drop such useful app just because it doesn't work on
> > > Cinnamon? It works on GNOME without ffpmeg and rpm fusion repo, see
> > > screenshot [1].
> >
> >
> > Please prevent your useless app from displaying in cinnamon menu, I'm
> sure
> > Mate, XFCE and LXDE would also like it removed from their menus as well.
>
> > Add this to it's desktop file!
> >
> > 'OnlyShowIn=Gnome'
>
> Agreed, I'd like to see it removed from Plasma's menu by default as well.
>
> --
> John M. Harris, Jr.
> Splentity
>
> ___
> 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
>
___
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

Re: Fedora 32 System-Wide Change proposal: Move fonts language Provides to Langpacks

[Igor Gnatenko]

I think it would be useful to mention in the change page that
langpacks-core-* already depend on "good quality font". If that is
already there, I apologize.

Another thing which is not mentioned on the change page is that you
are going to drop Requires: font(:lang=…) from fontconfig (otherwise
it is going to pull all langpacks-core-* packages).

Otherwise I'm happy with this change since this will finally solve the
problem where you install some game like teeworlds, get some fonts
pulled in and autoremove will never remove it since fontconfig depend
on font(:lang=xx) and libsolv never auto-removes "alternative"
packages. So you never remove fonts unless explicitly ask DNF to do
so.

On Thu, Jan 2, 2020 at 4:17 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/FontLanguageProvidesToLangpacks
>
> == Summary ==
> Move `Provides: font(:lang=...)` from fonts packages into the
> `langpacks` package,
> giving predictable default fonts for language scripts.
>
> === Motivation ===
> Currently fonts packages has auto-generated `font(:lang=...)`
> provides, which can be used as a dependency identifier to satisfy font
> coverage required for a certain language requirement. This is used by
> GTK application to install missing fonts via PackageKit for example.
> However in practice it has not been very useful since usually there
> are assorted multiple fonts that provide the language coverage and so
> an arbitrary fonts of unknown quality would get selected, so the
> mechanism is not unreliable.
>
> This change uses instead the default fonts chosen in `langpacks` for
> each language, to give reliable predictable default fonts for each
> language and improve the user application experience around fonts.
>
> == Owner ==
> * Name: [[User:Tagoh| Akira TAGOH]], [[User:Pnemade| Parag Nemade]]
> * Email: ta...@redhat.com, pnem...@redhat.com
>
>
> == Detailed Description ==
> The language based metadata for fonts packages was introduced in
> Fedora 11.  The idea being to provide a mechanism to find and install
> a font for missing glyphs through PackageKit and was useful for
> minority languages which might be missing default installed fonts
> packages.  But the user experience was generally not terribly good.
>
> Users cannot predict which fonts will be installed. This often leads
> to poor fonts choices installed, particularly for languages with too
> many available fonts such as English, since the first font found
> lexically will be arbitrarily chosen with gurantee of quality or
> expected style.
> This random dependency resolution sometimes introduces highly
> unexpected results too - for example a font from an external
> repository may get chosen by chance. This would be particularly
> problematic when composing ISOs, eg when including EPEL.
>
> So this Changes proposal aims to improve the user experience around
> font dependencies by moving the meta-provides the `langpacks` package
> instead. Langpacks contains various dependencies to use for certain
> languages, including dependencies for default fonts. so it will
> resolve the above issues.
>
> Specifically speaking, currently font provides are generated like this:
> 
> $ fc-query -f %{=pkgkit}  /usr/share/fonts/dejavu/DejaVuSans.ttf
> font(dejavusans)
> font(:lang=aa)
> font(:lang=ab)
> ...
> 
>
> and at the build time, it is transformed to:
> 
> Provides: font(dejavusans)
> Provides: font(:lang=aa)
> Provides: font(:lang=ab)
> ...
> 
>
> After this proposal, the above result will be:
> 
> Provides: font(dejavusans)
> 
>
> and then add `Provides: font(:lang=...)` line to corresponding
> sub-packages langpacks-core-*.
>
> So asking for a font for a certain language through PackageKit will be
> achieved by langpacks-core-* instead of a random font package.
>
> == Benefit to Fedora ==
> This proposal will provide reliable, predictable, and consistent font
> dependencies.
>
> == Scope ==
> * Proposal owners:
> ** Update fontconfig to drop `font(:lang=...)` from the alias of the
> formatter for `%{=pkgkit}`
> ** Add a line of `Provides: font(:lang=...)` to each
> `langpacks-core-...`. For instance, `Provides: font(:lang=hi)` needs
> to be added to `langpacks-core-hi`.
>
> * Other developers: Release Engineers needs to rebuild all fonts
> packages with the updated fontconfig package.
> * Release engineering: [https://pagure.io/releng/issue/9132 #9132]
> * Policies and guidelines: None
> * Trademark approval: None
>
>
> == Upgrade/compatibility impact ==
> Some packages may be installed after upgrading if corresponding
> langpacks-core-* packages isn't yet installed.
>
> == How To Test ==
> # Check that langpacks-core-* provide corresponding `font(:lang=...)`
> using `rpm -q --provides`.
> # Check that fonts packages no longer provide `font(:lang=...)`.
> # Check that langpacks-core-* pulls in the default expected font for
> the language.
>
> == User Experience ==
> Users should see better fonts chosen for languages when they install a
> font to cover a 

Re: Updating pytest to 5: ~30 packages FTBFS

[Igor Gnatenko]

These 2 packages will break:

python-pikepdf-1.7.0-2.fc32.src: (python3dist(pytest) >= 3.10.1 with
python3dist(pytest) < 5)
python3-pytest-relaxed-1.1.5-1.fc32.noarch: python3.8dist(pytest) < 5


On Thu, Jan 2, 2020 at 5:09 PM Miro Hrončok  wrote:
>
> Hello,
>
> I'd like to get pytest updated to 5.x in rawhide.
>
> https://src.fedoraproject.org/rpms/pytest/pull-request/15
>
> Several deprecated things were removed from that version and 31 packages fail 
> to
> build from source with pytest 5 (while building fine with pytest 4).
>
>
> The packages are built in:
>
> http://copr.fedorainfracloud.org/coprs/churchyard/pytest-4/
> http://copr.fedorainfracloud.org/coprs/churchyard/pytest-5/
>
> I would appreciate your help with fixing the packages.
>
>
>
> Several notable packages:
>
> scipy fix: https://src.fedoraproject.org/rpms/scipy/pull-request/15
> python-requests upstream fix: https://github.com/psf/requests/issues/5304
>
> python-ipyparallel and
> python-daskbuild somehow weirdly, maybe they will finish.
>
> python-pytest-* - there might be some newer versions available that work
>
>
>
> All packages:
>
> Maintainers by package:
> ansible  kevin toshio wzzrd
> fabric   orphan
> pylast   peter
> python-atomicwrites  mathstuf mbaldessari
> python-beanbag   sochotni
> python-behavechurchyard pschindl
> python-billiard  fab mrunge ngompa pingou pjp rmarko sundaram
> python-colcon-bazel  cottsay
> python-dask  qulogic
> python-flask codeblock fcami hguemar hushan
> python-flask-caching lbrabec
> python-flask-sqlalchemy hguemar kumarpraveen pjp ralph sundaram tflink
> python-hpack eclipseo
> python-html5lib  churchyard pjp sagitter salimma sundaram
> python-invokepghmcfc
> python-ipyparallel   ellert
> python-lz4   jgu orion
> python-mako  abompard bowlofeggs cverna ignatenkobrain kylev lmacken
> python-mdp   zbyszek
> python-paramiko  athmane ignatenkobrain ivazquez orion pghmcfc sgallagh
> python-pdir2 carlwgeorge
> python-pyrsistentdecathorpe devrim itamarjp
> python-pytest-covcstratak orion ttomecek
> python-pytest-faulthandler dkrejci lbalhar
> python-pytest-lazy-fixture ankursinha
> python-pytest-relaxed athmane
> python-pytest-xdist  swt2c
> python-requests  abompard cstratak jcline ralph sagarun
> python-testinfra wakko666
> python-whitenoisepiotrp
> scipycstratak jspaleta orion tomspur ttomecek
>
> Packages by maintainer:
> abompard   python-mako python-requests
> ankursinha python-pytest-lazy-fixture
> athmanepython-paramiko python-pytest-relaxed
> bowlofeggs python-mako
> carlwgeorge python-pdir2
> churchyard python-behave python-html5lib
> codeblock  python-flask
> cottsaypython-colcon-bazel
> cstratak   python-pytest-cov python-requests scipy
> cverna python-mako
> decathorpe python-pyrsistent
> devrim python-pyrsistent
> dkrejcipython-pytest-faulthandler
> eclipseo   python-hpack
> ellert python-ipyparallel
> fabpython-billiard
> fcami  python-flask
> hguemarpython-flask python-flask-sqlalchemy
> hushan python-flask
> ignatenkobrain python-mako python-paramiko
> itamarjp   python-pyrsistent
> ivazquez   python-paramiko
> jcline python-requests
> jgupython-lz4
> jspaleta   scipy
> kevin  ansible
> kumarpraveen python-flask-sqlalchemy
> kylev  python-mako
> lbalharpython-pytest-faulthandler
> lbrabecpython-flask-caching
> lmackenpython-mako
> mathstuf   python-atomicwrites
> mbaldessari python-atomicwrites
> mrunge python-billiard
> ngompa python-billiard
> orion  python-lz4 python-paramiko python-pytest-cov scipy
> orphan fabric
> peter  pylast
> pghmcfcpython-invoke python-paramiko
> pingou python-billiard
> piotrp python-whitenoise
> pjppython-billiard python-flask-sqlalchemy python-html5lib
> pschindl   python-behave
> qulogicpython-dask
> ralph  python-flask-sqlalchemy python-requests
> rmarko python-billiard
> sagarunpython-requests
> sagitter   python-html5lib
> salimmapython-html5lib
> sgallagh   python-paramiko
> sochotni   python-beanbag
> sundaram   python-billiard python-flask-sqlalchemy python-html5lib
> swt2c  python-pytest-xdist
> tflink python-flask-sqlalchemy
> tomspurscipy
> toshio ansible
> ttomecek   python-pytest-cov scipy
> wakko666   python-testinfra
> wzzrd  ansible
> zbyszekpython-mdp
>
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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: 

Re: Updating pytest to 5: ~30 packages FTBFS

[Igor Gnatenko]

These 2 packages will break:

python-pikepdf-1.7.0-2.fc32.src: (python3dist(pytest) >= 3.10.1 with
python3dist(pytest) < 5)
python3-pytest-relaxed-1.1.5-1.fc32.noarch: python3.8dist(pytest) < 5


On Thu, Jan 2, 2020 at 5:09 PM Miro Hrončok  wrote:
>
> Hello,
>
> I'd like to get pytest updated to 5.x in rawhide.
>
> https://src.fedoraproject.org/rpms/pytest/pull-request/15
>
> Several deprecated things were removed from that version and 31 packages fail 
> to
> build from source with pytest 5 (while building fine with pytest 4).
>
>
> The packages are built in:
>
> http://copr.fedorainfracloud.org/coprs/churchyard/pytest-4/
> http://copr.fedorainfracloud.org/coprs/churchyard/pytest-5/
>
> I would appreciate your help with fixing the packages.
>
>
>
> Several notable packages:
>
> scipy fix: https://src.fedoraproject.org/rpms/scipy/pull-request/15
> python-requests upstream fix: https://github.com/psf/requests/issues/5304
>
> python-ipyparallel and
> python-daskbuild somehow weirdly, maybe they will finish.
>
> python-pytest-* - there might be some newer versions available that work
>
>
>
> All packages:
>
> Maintainers by package:
> ansible  kevin toshio wzzrd
> fabric   orphan
> pylast   peter
> python-atomicwrites  mathstuf mbaldessari
> python-beanbag   sochotni
> python-behavechurchyard pschindl
> python-billiard  fab mrunge ngompa pingou pjp rmarko sundaram
> python-colcon-bazel  cottsay
> python-dask  qulogic
> python-flask codeblock fcami hguemar hushan
> python-flask-caching lbrabec
> python-flask-sqlalchemy hguemar kumarpraveen pjp ralph sundaram tflink
> python-hpack eclipseo
> python-html5lib  churchyard pjp sagitter salimma sundaram
> python-invokepghmcfc
> python-ipyparallel   ellert
> python-lz4   jgu orion
> python-mako  abompard bowlofeggs cverna ignatenkobrain kylev lmacken
> python-mdp   zbyszek
> python-paramiko  athmane ignatenkobrain ivazquez orion pghmcfc sgallagh
> python-pdir2 carlwgeorge
> python-pyrsistentdecathorpe devrim itamarjp
> python-pytest-covcstratak orion ttomecek
> python-pytest-faulthandler dkrejci lbalhar
> python-pytest-lazy-fixture ankursinha
> python-pytest-relaxed athmane
> python-pytest-xdist  swt2c
> python-requests  abompard cstratak jcline ralph sagarun
> python-testinfra wakko666
> python-whitenoisepiotrp
> scipycstratak jspaleta orion tomspur ttomecek
>
> Packages by maintainer:
> abompard   python-mako python-requests
> ankursinha python-pytest-lazy-fixture
> athmanepython-paramiko python-pytest-relaxed
> bowlofeggs python-mako
> carlwgeorge python-pdir2
> churchyard python-behave python-html5lib
> codeblock  python-flask
> cottsaypython-colcon-bazel
> cstratak   python-pytest-cov python-requests scipy
> cverna python-mako
> decathorpe python-pyrsistent
> devrim python-pyrsistent
> dkrejcipython-pytest-faulthandler
> eclipseo   python-hpack
> ellert python-ipyparallel
> fabpython-billiard
> fcami  python-flask
> hguemarpython-flask python-flask-sqlalchemy
> hushan python-flask
> ignatenkobrain python-mako python-paramiko
> itamarjp   python-pyrsistent
> ivazquez   python-paramiko
> jcline python-requests
> jgupython-lz4
> jspaleta   scipy
> kevin  ansible
> kumarpraveen python-flask-sqlalchemy
> kylev  python-mako
> lbalharpython-pytest-faulthandler
> lbrabecpython-flask-caching
> lmackenpython-mako
> mathstuf   python-atomicwrites
> mbaldessari python-atomicwrites
> mrunge python-billiard
> ngompa python-billiard
> orion  python-lz4 python-paramiko python-pytest-cov scipy
> orphan fabric
> peter  pylast
> pghmcfcpython-invoke python-paramiko
> pingou python-billiard
> piotrp python-whitenoise
> pjppython-billiard python-flask-sqlalchemy python-html5lib
> pschindl   python-behave
> qulogicpython-dask
> ralph  python-flask-sqlalchemy python-requests
> rmarko python-billiard
> sagarunpython-requests
> sagitter   python-html5lib
> salimmapython-html5lib
> sgallagh   python-paramiko
> sochotni   python-beanbag
> sundaram   python-billiard python-flask-sqlalchemy python-html5lib
> swt2c  python-pytest-xdist
> tflink python-flask-sqlalchemy
> tomspurscipy
> toshio ansible
> ttomecek   python-pytest-cov scipy
> wakko666   python-testinfra
> wzzrd  ansible
> zbyszekpython-mdp
>
>
> --
> 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: 

Re: Fedora 32 System-Wide Change proposal: Golang 1.14

[Igor Gnatenko]

Do we really need to rebuild all thousand of packages given that most
of them are providing only noarch devel packages with sources? Don't
we need to rebuild only those which provide binaries?

On Thu, Jan 2, 2020 at 4:17 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/golang1.14
>
> == Summary ==
> Rebase of Golang package to upcoming version 1.14 in Fedora 32,
> including rebuild of all dependent packages(pre-release version of Go
> will be used for rebuild, if released version will not be available at
> the time of the mass rebuild).
>
> == Owner ==
> * Name: [[User:Jcajka| Jakub Čajka]]
> * Email: jca...@redhat.com
>
> == Detailed Description ==
>
> Rebase of Golang package to upcoming version 1.14 in Fedora 32. Golang
> 1.14 is schedule to be released in Feb 2020.
> Due to current nature and state of Go packages, rebuild of dependent
> package will be required to pick up the changes.
>
> == Benefit to Fedora ==
>
> Staying closely behind upstream by providing latest release of golang,
> which includes performance improvements and improvements in support
> for currently supported platforms among other bug fixes and new
> features. For complete list of changes see upstream change notes at
> https://tip.golang.org/doc/go1.14 . In result Fedora will be providing
> solid development platform for Go language.
>
> == Scope ==
> * Proposal owners: Rebase golang package in f32, help with resolving
> possible issues found during package rebuilds.
>
> * Other developers: Fix possible issues, with help from golang maintainers.
> * Release engineering: Rebuild of dependent packages as part of
> planned mass-rebuild. Tracking ticket
> https://pagure.io/releng/issue/9136
> * Policies and guidelines: N/A
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
> None
>
> == How To Test ==
> ;0.
> :a)Install golang 1.14 from rawhide and use it to build your
> application(s)/package(s).
> :b)Scratch build against rawhide.
> ;1.
> :Your application/package built using golang 1.14 should work as expected.
>
> == User Experience ==
> None
>
> == Dependencies ==
> 
> dnf repoquery -q  --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'golang'
> dnf repoquery -q  --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'compiler(go-compiler)'
> dnf repoquery -q  --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'compiler(golang)'
> dnf repoquery -q  --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'go-rpm-macros'
> 
> 
> Omitted due to the number of packages listed ~1100.
> 
>
> Not all of listed require re-build as they might not ship binaries
> and/or do not use golang compiler during build, but only use Go rpm
> macros that pull it in to every build root.
>
> == Contingency Plan ==
> * Contingency mechanism:Reverting to  golang version 1.13.X if
> significatnt issues are discovered.
> * Contingency deadline: Beta Freeze(?)
> * Blocks release? No
> * Blocks product? No
>
> == Documentation ==
> https://tip.golang.org/doc/go1.14
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org
___
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

Re: Fedora 32 System-Wide Change proposal: Systemd presets for user units

[Igor Gnatenko]

Do we have list of affected packages / services? I'd be more
comfortable if we would have list of these and explicitly enabled
mandatory ones so that we don't break composes and such.

On Thu, Jan 2, 2020 at 4:15 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units
>
> == Summary ==
>
> System units are managed through presets
> [https://fedoraproject.org/wiki/Features/PackagePresets since F18] and
> by policy, presets are carried by the fedora-release package. This
> policy is now extended to user units.
>
> == Owner ==
> * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
> * Email: zbyszek at in waw pl
>
> == Detailed Description ==
>
> The preset mechanism for user units was already in place, but we were
> missing the actual preset files, and the default was "enable *"
> instead of "disable *" as for system services.
>
> Systemd will now provide a
> /usr/lib/systemd/user-preset/99-default-disable.preset that marks user
> services as disabled by default. Any user services which should be
> enabled will be to get an appropriate preset in
> /usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific
> file. Most packages already call into the preset mechanism, but those
> which don't will be adjusted to do that.
>
> This is essentially a fix for
> https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good
> reason to treat user services different than system services in this
> regard. On the systemd side this change is very simple, but all
> packages that provide user units need to be reviewed to check if they
> are enabled after the change if appropriate.
>
> == Benefit to Fedora ==
>
> User and system services are handled in the same way.
>
> Local configuration may be used to override which services should be
> enabled after upgrade. In particular, "local" in this context may mean
> "per-spin" or "per-user".
>
> == Scope ==
> * Proposal owners:
> ** review all packages that provide user services in Fedora and submit
> PRs when changes are needed
> ** add a new presets file to the fedora-release package for user units
> ** submit a proposal to FPC to update the guidelines (essentially to
> say "... and the same for user services.").
>
> * Other developers:
> ** FPC: review (and accept ;)) the guidelines changes
> ** other maintainers: verify that units in their packages are enabled
> or not as appropriate after package installation
>
> * Release engineering: n/a
>
> * Policies and guidelines: a pull request will be submitted
>
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Should not be user visible. Some units which are are currently enabled
> by mistake will not be enabled anymore on new installations.
>
> == How To Test ==
> Install a new system (or uninstall and reinstall some packages).
> Verify that the appropriate units are enabled for the user session.
>
> == User Experience ==
> N/A
>
> == Dependencies ==
> N/A
>
> == Contingency Plan ==
>
> * Contingency mechanism: Revert the changes.
>
> * Contingency deadline: beta freeze
> * Blocks release? No
> * Blocks product? No
>
> == Documentation ==
> A pull request for the packaging guidelines will be submitted.
>
> == Release Notes ==
> Not needed.
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org
___
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

Re: Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction

[Igor Gnatenko]

I really love this idea because users (sysadmins) will get the ability
to *not* restart some production-critical services on upgrade if they
decide so without rebuilding package with removed scriptlets.

I don't have suggestions about syntax, but whatever systemd upstream
comes up with is good for me.

On Thu, Jan 2, 2020 at 4:16 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_transaction
>
> == Summary ==
>
> Scriptlets to restart each service that should be restarted in each
> rpm package will be replaced by a declaration in the unit file and an
> rpm transaction trigger that fires at the end and restarts all
> services.
>
> == Owner ==
> * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
> * Email: zbyszek at in waw pl
>
>
> == Detailed Description ==
>
> Currently, when packages containing systemd services are upgraded,
> they are restarted through %post scriptlets in each package. In other
> words, the scriptlets specify which services should be restarted and
> actually run the command to restart the service. An alternative
> mechanism will be provided, whereby the unit file contains a setting
> which specifies that the service should be restarted on upgrade, and a
> %transfiletrigger in the systemd package will restart all services
> marked so in upgraded packages at the end of transaction.
>
> To mark a services as "restart on upgrade" the unit file should
> contain an option to mark it so. This can be either in the main
> .service file, or e.g. in a drop-in file in
> /usr/lib/systemd/system/.service.d/needs-restart.conf.
> The exact name of the option should be something like
> X-restart-on-upgrade=true|false. I'll take the proposal
> for discussion in systemd upstream, since this is something that could
> be used across distributions, and then the "X-" prefix could be
> dropped and/or the name changed.
>
> == Benefit to Fedora ==
>
> Which services should be restarted is specified declaratively and the
> number of scriptlets is reduced.
>
> Admins may easily override this by providing appropriate drop-ins of
> their own of higher priority.
>
> Services are restarted after the transaction is finished, all
> libraries have been upgraded, and systemd configuration reloaded. This
> solves https://bugzilla.redhat.com/show_bug.cgi?id=1614751, but also a
> more general problem: a service may be restarted before any of its
> dependencies (files and static content and whatnot) have been
> upgraded, and while some contents from the old rpm are still on disk.
> Restarting after all packages have been upgraded avoids this issue.
>
> In the future, restarting of services shall also be extended to user
> managers (i.e. to restart all user services after the packages
> providing those services have been upgraded). This is not part of this
> proposal, but moving the information what to restart into systemd
> units makes this much easier.
>
> == Scope ==
> * Proposal owners:
> ** implement the relevant bits in the systemd package
> ** submit a proposal to FPC
> ** convert a subset of packages
>
> * Other developers:
> ** FPC: review (and accept ;)) the guidelines changes
> ** other maintainers: convert other packages
>
> * Release engineering: n/a
>
> * Policies and guidelines: a pull request will be submitted
>
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> This change should be backwards compatible, i.e. unconverted packages
> can be still installed on new systems, and services will be restarted
> on upgrade like before. Converted packages may be installed on older
> systems but will not get restarted on upgrades.
>
> == How To Test ==
> This change should be mostly invisible to users. Check that during
> upgrades services are restarted and that no warnings are emitted.
>
> == User Experience ==
> N/A
>
> == Dependencies ==
> N/A
>
> == Contingency Plan ==
>
> * Contingency mechanism: Revert to previous mechanism. This will
> require a revert of changes to the spec file and a rebuild of the
> package.
>
> * Contingency deadline: beta freeze
> * Blocks release? No
> * Blocks product? No
>
> == Documentation ==
> TBD.
>
> == Release Notes ==
> Not needed.
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: peek package

[Igor Gnatenko]

The problem with this approach is that when you install ffmpeg, it still
won't be shown in those DEs.

On Thu, Jan 2, 2020, 01:57 Kevin Fenzi  wrote:

> On Wed, Jan 01, 2020 at 09:13:28PM -, Artem Tim wrote:
> > > "All package dependencies (build-time or runtime, regular, weak or
> otherwise)
> > > MUST ALWAYS be satisfiable within the official Fedora repositories."
> >
> > >
> https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/
> >
> > > "As with regular dependencies, weak dependencies MUST be satisfiable
> > > within the official Fedora repositories."
> >
> > > Also, the gstreamer1-plugins-ugly Recommends needs removed along with
> > > ffmpeg.
> >
> > Removed 'gstreamer1-plugins-ugly' and 'ffpmeg' as weak deps, just
> commented them as tip.
> >
> > > Failing that perhaps adjust the desktop file to add a
> > > But does it work only in Wayland sessions?
> >
> > Works on both Xorg and Wayland session.
>
> Then OnlyShowIN=Gnome in the desktop file seems like a possible
> solution.
>
> 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
>
___
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

Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Igor Gnatenko]

Always before upgrade to a new *major* version of distribution, you
are supposed to read release notes. This will be noted there and you,
as a user, can explicitly disable it after upgrade. Or even ship your
own preset which would override system's one.

On Fri, Dec 20, 2019 at 8:12 AM John M. Harris Jr  wrote:
>
> On Thursday, December 19, 2019 11:59:54 PM MST Chris Murphy wrote:
> > On Thu, Dec 19, 2019 at 8:40 PM Stuart D. Gathman 
> > wrote:
> > >
> > >
> > > On Thu, 19 Dec 2019, Ben Cotton wrote:
> > >
> > >
> > >
> > > > https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer
> > > >
> > > >
> > > >
> > > > == Summary ==
> > > > Enabling fstrim.timer will cause fstrim.service to execute weekly,
> > > > which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet`
> > >
> > >
> > >
> > > > == How To Test ==
> > > > The low level function of systemd timers, fstrim.service, and fstrim
> > > > command are well understood and tested already, all Fedora needs to
> > > > test is that the timer is enabled following clean installation and
> > > > upgrades:
> > >
> > >
> > >
> > > After the initial change of defaults, the fstrim.timer SHOULD NOT be
> > > re-enabled on subsequent updates if a user (who like me prefers choosing
> > > when to run fstrim on which filesystem) has disabled it.
> >
> >
> > It's an interesting question. I'm not sure what the upgrade policy is
> > for vendor presets. Because there's a general expectation of getting
> > new features upon upgrade, without having to do a clean install, I
> > think this one should be enabled on upgrades. But I'm not sure how to
> > make sure F32>F33 upgrade does not reenable if the user has disabled
> > it; but still enable it with F31>F33 since Fedora supports upgrades
> > that skip one release. So yeah, I need to figure that out.
> >
> > As for customizations to fstrim.timer, the original from /usr should
> > be copied and put into /etc, and customized. That shouldn't be
> > replaced on an upgrade. The fstrim.timer in /usr of course could be
> > replaced, like anything else. Same for fstrim.service in case you want
> > to trim all mounted file systems instead of just fstab.
>
> Well, this isn't a "new feature", and I'm not sure it's a good idea to just
> enable this randomly during the update from F31 to F32. Personally, I wouldn't
> do it, because it's not something the user's preferences for can actually be
> accounted for. For example, I don't use trim for a number of reasons, and I
> wouldn't want to find that it was enabled on me at some point.
>
> --
> John M. Harris, Jr.
> Splentity
>
> ___
> 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
___
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

Re: Fedora 32 System-Wide Change proposal: LTO by default for package builds

[Igor Gnatenko]

Hi Jeff,

On Thu, Dec 19, 2019 at 10:50 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/LTOByDefault
>
> == Summary ==
> This is a proposal to enable link time optimization (LTO) of packages
> built with rpmbuild by default.  It's an over-simplification, but
> think of LTO as deferring analysis, optimization and code generation
> until creation of an executable or dynamic shared object.
>
> This is implemented by adding the option "-flto" the injected flags in
> redhat-rpm-config.  There will be a simple way for packages to opt-out
> of LTO.
>
> == Owner ==
> * Name: Jeff Law
> * Email: l...@redhat.com
>
> == Detailed Description ==
> Programs built with rpmbuild and which honor flags injection via
> redhat-rpm-config will be built with LTO by default.  A simple opt-out
> mechanism will be provided for packages which use features that are
> not LTO compatible.
>
> The LTO bytecode itself will not be distributed as it is not stable
> from one GCC release to the next.  This is enforced by stripping the
> LTO bytecode from any installed .o/.a files.  We'll use bits SuSE has
> already written for redhat-rpm-config to implement this.
>
> Minor changes are desirable to the %configure macro in
> redhat-rpm-config to fix common code idioms used by autoconf generated
> scripts which are compromised by the additional optimization enabled
> by LTO.  Minor updates to various packages will be needed to opt-out
> of LTO or fix bugs exposed by LTO.
>
> == Benefit to Fedora ==
>
> The primary benefits of building with LTO enabled are smaller, faster
> executables/DSOs.  A secondary benefit is LTO allows deeper analysis
> of package source code at compile time which can improve various GCC
> diagnostics and thus improve our ability to catch bugs at compile time
> such as uninitialized objects, buffer overflows, unterminated strings,
> restrict violations, etc.

It would be very nice to get more specific analysis data. Like running
some benchmarks of big applications, size comparisons (of binaries and
libraries) and compile time.

> This change also brings us back on-par with SuSE who enabled LTO by
> default for their free distribution earlier in 2019.

You probably should have said openSUSE rather here.

>
> == Scope ==
> * Proposal owners:
> The primary change is to redhat-rpm-config to add LTO to the default
> compile/link flags as well as a conditional which allows easy opt-out
> on a package by package basis.  Additionally the post-build scripts
> need to strip the LTO bytecodes from any installed .o/.a files.

What does that mean? Which post-build scripts are needed and where
that needs to be done? How does it affect build time?

> Additionally, we know there are many packages with configure scripts
> that are compromised by LTO.  I have tweaks to the %configure macro in
> redhat-rpm-config which fixes the vast majority of these problems with
> a few simple sed scripts on the generated output.  Like the basic
> support for injecting the LTO flags, this will require coordination
> with the redhat-rpm-config maintainers.  Packages which call configure
> directly and have compromised tests will need a one line change to
> their .spec files to fix their configure scripts.

"simple sed scripts" are probably not so simple :)

> Some packages will need to opt-out of using LTO at this time.  The
> most common case are packages that use symbol versioning or toplevel
> ASM statements.  While there is a new mechanism to make LTO work with
> symbol versioning, I don't think any packages have been updated to use
> that mechanism.  This will require a one line change to 50-75 packages
> (my script to find these is still running).

Hmm, I think we have bunch of packages (more than 75 of them) which
use symbol versioning. Would be useful to give some links in the
change proposal to "how to update to use that mechanism".

> Finally, some packages will fail to build with LTO due to deeper
> analysis for compile-time diagnostics catching programming mistakes
> that have gone unnoticed until now.  I'll obviously be working with
> package maintainers on all of these issues.
>
> Note that even though the changes are fairly well localized in
> redhat-rpm-config and a small number of packages, the real scope of
> this change is much larger since it affects all packages in the
> distribution that are compiled with GCC and which honor the flags
> injection by redhat-rpm-config.
>
>
> * Other developers:
> As I mentioned, I'm happy to contact package owners that need to
> modify their packages and suggest how their package needs to be fixed.
> As a multi-decade GCC developer, I'm particularly well suited to
> describe LTO, its limitations and how LTO impacts the diagnostics from
> GCC to any package owner that needs additional information.
>
> I'm also capable and available to address any GCC issues that we may
> arise as a result of this change.  I don't expect much of the latter
> as SuSE has already enabled this feature for their 

Re: Spdlog update to 1.4.2

[Igor Gnatenko]

Did you check if they do?

On Wed, Dec 18, 2019, 10:21 Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> Hello.
>
> I'm going to update spdlog package to version 1.4.2 in Rawhide. This is
> not a header-only library anymore.
>
> This update can break dependent packages if they don't use
> cmake/pkgconfig to import spdlog.
>
> --
> Sincerely,
>   Vitaly Zaitsev (vit...@easycoding.org)
> ___
> 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
>
___
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

Summary/Minutes for today's FESCo meeting (2019-12-09)

[Igor Gnatenko]

=
#fedora-meeting-1: FESCO (2019-12-09)
=


Meeting started by ignatenkobrain_ at 15:00:17 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-12-09/fesco.2019-12-09-15.00.log.html
.



Meeting summary
---
* init process  (ignatenkobrain_, 15:00:28)

* #2295 Update FESCo membership with elections results, possibly setup
  new meeting time  (ignatenkobrain_, 15:04:13)
  * AGREED: Keep this time for next ~2mo and then possibly run
whenisgood (+8, 0, -0)  (ignatenkobrain_, 15:09:18)

* #2285 Make Eclipse Installable  (ignatenkobrain_, 15:09:22)
  * AGREED: 1) eclipse module doesn't get a default stream in f31,
creating a Common Issues entry is recommended 2) adding default
stream for eclipse module for f32 can be put on discussion via
Fedora Change process 3) FESCo will identify work items on the
policy enforcement for default streams content (+8, 0, -0)
(ignatenkobrain_, 15:32:47)
  * LINK:
https://docs.fedoraproject.org/en-US/modularity/installing-modules/
doesn't actually answer this question, I think.  (zbyszek, 15:33:52)
  * ACTION: decathorpe will try to help fixing non-modular eclipse in
F31  (ignatenkobrain_, 15:44:31)

* #2291 F32 System-Wide Change: Disallow Empty Password By Default
  (ignatenkobrain_, 15:44:41)
  * AGREED: Reject this Change and amend our policy to do an instant
reject when ticket gets -7 (+9, 0, -0)  (ignatenkobrain_, 15:51:00)
  * ACTION: zbyszek to update docs to reflect this  (ignatenkobrain_,
15:51:17)

* Next week's chair  (ignatenkobrain_, 15:51:26)
  * ACTION: contyk will chair next meeting  (ignatenkobrain_, 15:52:07)
  * The next meeting will be on 16th of Dec and then on Jan. 6. There
will be still voting in the tickets and auto-approvals.
(ignatenkobrain_, 15:55:36)

* Open Floor  (ignatenkobrain_, 15:55:56)

Meeting ended at 16:12:17 UTC.




Action Items

* decathorpe will try to help fixing non-modular eclipse in F31
* zbyszek to update docs to reflect this
* contyk will chair next meeting




Action Items, by person
---
* contyk
  * contyk will chair next meeting
* decathorpe
  * decathorpe will try to help fixing non-modular eclipse in F31
* zbyszek
  * zbyszek to update docs to reflect this
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* ignatenkobrain_ (90)
* dcantrell (74)
* sgallagh (65)
* contyk (37)
* zbyszek (26)
* nirik (25)
* decathorpe (25)
* zodbot (20)
* mhroncok (19)
* bookwar (15)
* mbooth (15)
* bcotton (1)
* ignatenkobrain (0)
* dcantrel (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot



On Mon, Dec 9, 2019 at 3:17 PM Igor Gnatenko
 wrote:
>
> Following is the list of topics that will be discussed in the
> FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
> irc.freenode.net.
>
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
>
> or run:
>   date -d '2019-12-09 15:00 UTC'
>
>
> Links to all issues to be discussed can be found at:
> https://pagure.io/fesco/report/meeting_agenda
>
> = Discussed and Voted in the Ticket =
>
> Nonresponsive maintainer: huwang
> https://pagure.io/fesco/issue/2287
> APPROVED (+4, 0, -0)
>
> F32 System-Wide Change: Freeze after branching until compose is ready
> https://pagure.io/fesco/issue/2288
> APPROVED (+5/+7, 0, -0)
>
> F32 Self-Contained Change: Build Python with
> -fno-semantic-interposition for better performance
> https://pagure.io/fesco/issue/2290
> APPROVED (+7, 0, -0)
>
> = Followups =
>
> #topic #2285 Make Eclipse Installable
> https://pagure.io/fesco/issue/2285
>
> = New business =
>
> #topic #2291 F32 System-Wide Change: Disallow Empty Password By Default
> https://pagure.io/fesco/issue/2291
>
> #topic #2295 Update FESCo membership with elections results, possibly
> setup new meeting time
> https://pagure.io/fesco/issue/2295
>
> = Open Floor =
>
> For more complete details, please visit each individual
> issue.  The report of the agenda items can be found at
> https://pagure.io/fesco/report/meeting_agenda
>
> If you would like to add something to this agenda, you can
> reply to this e-mail, file a new issue at
> https://pagure.io/fesco, e-mail me directly, or bring it
> up at the end of the meeting, during the open floor topic. Note
> that added topics may be deferred until the following meeting.
___
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

Re: moving bugzilla overrides to dist-git

[Igor Gnatenko]

It would be nice if we would implement "approval" system while doing
this. Like if you set somebody as override, that person must click
"accept". Same way to change it, the old person must click "accept".

Of course, pagure admin should be able to override this, based on
FESCo tickets and such.

On Mon, Dec 9, 2019 at 3:14 PM Pierre-Yves Chibon  wrote:
>
> On Mon, Dec 09, 2019 at 08:46:28AM -0500, Neal Gompa wrote:
> > On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp  wrote:
> > >
> > > Hi,
> > >
> > > We are currently working on getting rid of the git repo at 
> > > fedora-scm-requests [1] which is nowadays only used to store the 
> > > overrides of the default assignee in bugzilla (for example to allow 
> > > different default assignee for Fedora and EPEL).
> > >
> > > I am working on porting this mechanism to dist-git itself (much like we 
> > > did for the anitya integration a few weeks ago).
> > >
> > >  We are thinking on providing a simple text field to submit FAS username 
> > > or email to override the default assignee, the big question is then, who 
> > > should be allowed to update this field ?
> > >
> > > Should the main admin be able to set someone else as assignee ?
> > >
> > > If there is already an override assignee, who should be allowed to change 
> > > that ?
> > >
> > > If there's no override assignee set, can everyone become it or is that up 
> > > to the main admin of the component to decide and set ?
> > >
> >
> > I think in this case, it should be the main admin who can change this.
>
> The main admin (and infra/releng) only, or all the admins of the project?
>
>
> Pierre
> ___
> infrastructure mailing list -- infrastruct...@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-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/infrastruct...@lists.fedoraproject.org
___
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

Schedule for Mondays's FESCo Meeting (2019-12-09)

[Igor Gnatenko]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2019-12-09 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

Nonresponsive maintainer: huwang
https://pagure.io/fesco/issue/2287
APPROVED (+4, 0, -0)

F32 System-Wide Change: Freeze after branching until compose is ready
https://pagure.io/fesco/issue/2288
APPROVED (+5/+7, 0, -0)

F32 Self-Contained Change: Build Python with
-fno-semantic-interposition for better performance
https://pagure.io/fesco/issue/2290
APPROVED (+7, 0, -0)

= Followups =

#topic #2285 Make Eclipse Installable
https://pagure.io/fesco/issue/2285

= New business =

#topic #2291 F32 System-Wide Change: Disallow Empty Password By Default
https://pagure.io/fesco/issue/2291

#topic #2295 Update FESCo membership with elections results, possibly
setup new meeting time
https://pagure.io/fesco/issue/2295

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

Replace NNN with the issue numbers and add in Title of issues.
___
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

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

[Igor Gnatenko]

Thanks for CCing me (maintainer of protobuf here), I am particularly
not happy that some module (which is not even called protobuf, but
some random Java #$%! with ripped out python support overrides my
builds).

I have put a proposal into a FESCo ticket.

On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok  wrote:
>
> Today I've attempted to run "dnf upgrade".
>
> It has the following in it:
>
> Upgrading:
> protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
>
> Enabling module streams:
>   ant
>   eclipse
>   maven
>
>
> I don't consider this behavior adequate for a released Fedora version.
>
> As a maintainer of dependent packages (Cura stack) I have tested and built it
> against the nonmodular protobuf. What just happened here and how do I track 
> it down?
>
> dnf doesn't even tell me what module is this in. I suppose eclipse.
>
> However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
>
> --
> 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
___
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

SSL_DEFAULT_CIPHER_LIST vs PROFILE=DEFAULT vs no set_cipher_list()

[Igor Gnatenko]

https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/#_cc_applications
says that I need to patch application (if it does not have config
file) to use "PROFILE=SYSTEM" as the argument to the cipher list.

However, when I was looking into the library which uses this function
(rust-openssl), I found following piece of code:

/// Creates a new builder for TLS connections.
///
/// The default configuration is subject to change, and is
currently derived from Python.
pub fn builder(method: SslMethod) -> Result {
let mut ctx = ctx(method)?;
ctx.set_default_verify_paths()?;
ctx.set_cipher_list(

"DEFAULT:!aNULL:!eNULL:!MD5:!3DES:!DES:!RC4:!IDEA:!SEED:!aDSS:!SRP:!PSK",
)?;
setup_verify( ctx);

Ok(SslConnectorBuilder(ctx))
}

https://github.com/sfackler/rust-openssl/blob/9ba802ad437447ac71f99d89653b35072bf5ccd9/openssl/src/ssl/connector.rs#L62-L74

Then I looked at CPython and found that it does this:

/* Ignored in SSLContext constructor, only used to as
_ssl.DEFAULT_CIPHER_STRING */
  #define PY_SSL_DEFAULT_CIPHER_STRING SSL_DEFAULT_CIPHER_LIST

And then it just ignores call to SSL_CTX_set_cipher_list().

So my question would be: Should I patch rust-openssl to use
PROFILE=DEFAULT or I should just remove that call entirely? It is not
very clear to me from the guidelines. Also since I want to get this
upstream, which option is more portable?
___
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

Re: Suggestion for Fedora change proposal: -Bsymbolic-functions default in LDFLAGS

[Igor Gnatenko]

Do you have some benchmark results and/or some statistics related to
the file size?

On Wed, Dec 4, 2019 at 2:09 PM Paulo César Pereira de Andrade
 wrote:
>
>   Hi,
>
>   Idea about @subject started with ongoing customer support case that
> originated https://bugzilla.redhat.com/show_bug.cgi?id=1778236
> [Problems linking to zlib corrected if zlib is linked with 
> -Bsymbolic-functions]
> when doing some research, it appears Ubuntu has it by default for
> some time.
>
>   This is currently only a suggestion and/or request for comments.
> Some extra detail in https://bugzilla.redhat.com/show_bug.cgi?id=1778234
> [Request For Comments: -Bsymbolic-functions in LDFLAGS by default]
>
>   Basically, there would be a few issues, most times in broken code,
> and the valid cases could be worked around removing -Bsymbolic-functions.
>
>   The biggest advantages are far less relocations, for example, that
> should mean faster load time, and avoids several issues with symbols
> being clobbered by symbols from another library.
>
> Thanks!
> Paulo
> ___
> 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
___
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

Re: Looking for a co-maintainer for timew: will sponsor + mentor

[Igor Gnatenko]

Hey,

Add me as maintainer. I maintain taskwarrior which is very related :)

On Tue, Dec 3, 2019, 16:28 Ankur Sinha  wrote:

> Hello,
>
> I am looking for a co-maintainer to help maintain timew
> (timewarrior[1]). The package is not very complex. There is only one bug
> against timew at the moment:
>
> 1775965 – timew-1.2.0 is available:
> https://bugzilla.redhat.com/show_bug.cgi?id=1775965
>
> Since I'm focussing on Neuroscience tools, I'd like to be able to share
> the maintenance responsibilities for other general tools.
>
> I am also happy to sponsor and mentor if someone wants to join the
> packagers group[2]. I will help you gain/learn (among other skills)[3]:
>
> - a good understanding of the Free Software Philosophy.
> - a good understanding of the Fedora community's philosophy.
> - a good understanding of the Fedora community's code of conduct.
> - a good understanding of how source code is licensed.
> - a good understanding of the packaging guidelines.
> - a good understanding of the package review process.
> - a good understanding of the package maintainer policies.
> - a good understanding of how rpms are built.
>
> [1] https://timewarrior.net/
> [2]
> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer
> [3] https://fedoraproject.org/wiki/User:Ankursinha/PackagerSponsor
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> 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
>
___
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

RFC: Branch requests from non-maintainers

[Igor Gnatenko]

Hello,

3 months ago, Miro opened releng ticket[0] raising question whether
non-maintainers (of some specific packages) being able to request
branches.

However, it never went anywhere outside of that ticket.

I'd like to ask people on this mailing list a few questions. Let's say
we have some theoretical package and it has only one maintainer in
src.fp.o.

* Should any other packager (not that maintainer) be able to request
new branches on that repo?
* Should provenpackager be able to do the same request?


[0] https://pagure.io/releng/issue/8844
___
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

Re: RFC: Modularity Simplified

[Igor Gnatenko]

On Mon, Dec 2, 2019 at 9:13 AM Nicolas Mailhot via devel
 wrote:
>
> Le 2019-12-02 08:38, Igor Gnatenko a écrit :
> > On Mon, Dec 2, 2019 at 8:28 AM Nicolas Mailhot via devel
>
> >> Having all build elements in the package repos themselves is the CORE
> >> feature that makes the “share” community dimension of Fedora work.
> >> Anyone
> >> can take the packages and do whatever he wants with them (audit,
> >> rebuild,
> >> modify), in any rpm build infra (koji, copr, mock, rpmbuild, obs)
> >> without
> >> depending on the Fedora build infra of the year.
> >
> > It would be nice, however please return back to the reality. Many of
> > packages are FTBFS (e.g. some BRs do not exist anymore (due to the
> > dependency update)). So this does not work in practice.
>
> That’s just a combination of bad tooling, and therefore bad enforcement,
> and people promising castles in the cSure, buloud that would not require any
> human effort.
>
> The only reason people work on the project is that by and large, the
> FTBS part is marginal. Make it a normal state, and it will grow, and the
> distribution will die.

Thanks to Miro, this part is now enforced, though some individuals
still do not understand importance of this :/

I am not saying this should not improve. I am just saying that this is
where we are and we have had this problem before. And we never had
this goal (to make distribution self-contained), as a project.

> Regards,
>
> --
> Nicolas Mailhot
> ___
> 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
___
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

Re: RFC: Modularity Simplified

[Igor Gnatenko]

On Mon, Dec 2, 2019 at 8:58 AM Nicolas Mailhot via devel
 wrote:
>
> Le 2019-12-02 07:47, Igor Gnatenko a écrit :
> > Hi Neal,
> >
> > On Sat, Nov 30, 2019 at 11:58 PM Neal Gompa  wrote:
>
> >> I think we need to recognize that we've done some poor optimization
> >> for the majority of packager workflows. Even if we consider modules,
> >> the vast majority of components will never be modularized. Moreover,
> >> we already know that the overwhelming majority of specs are managed
> >> identically across branches.
> >
> > Yeah, indeed. I think this (optimization of packager workflows) was
> > never an explicit goal of people working on Modularity.
>
> And for that reason alone, it should have been sent directly back to
> the drawing board.

It really depends on a goal. If the goal is to provide simple parallel
availability, then there is nothing to complain about. Modularity
simply has (had?) different goal.

> Creating new tooling, without trying to optimize the workflow of the
> intended users of the tooling, was always doomed to have no user
> adoption community-side.

As Neal mentioned, it was developed inside Red Hat for the Red Hat
needs (and arguably Fedora needs too).

> Making tooling for fairies, because you can redefine at will what the
> fairies want, and no actual fairy will ever materialize to contradict
> you, is easier design-side. But, it’s 100% a gamble that can (and most
> often will) misfire.
>
> Regards,
>
> --
> Nicolas Mailhot
> ___
> 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
___
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

Re: RFC: Modularity Simplified

[Igor Gnatenko]

On Mon, Dec 2, 2019 at 8:48 AM Nicolas Mailhot via devel
 wrote:
>
> Le 2019-12-02 08:17, Igor Gnatenko a écrit :
>
> > I simply can't. If somebody gets a package into repo just because he
> > wants to build foo, it is probably not very reasonable to ask them to
> > "properly" maintain it.
>
> It is very reasonable to expect anyone building in Fedora, reusing the
> work of countless other Fedora contributors, to produce things in a
> form others can build and contribute upon.

Yes, it is reasonable to reuse the work. But it is not reasonable to
expect the person who added something into Fedora is willing to fix
all bugs and properly maintain it. The whole point I'm trying to make
is that all packages are "community supported", however some of them
are more supported and some of them can be / are supported less.

> That’s free software 101.
>
> Building communities takes time and energy and has no immediate benefit.
> But, long-term, it's the most efficient way to do things (the “free
> software development model” Red Hat suits love to congratulate
> themselves
> on; it’s a development model, not just a bunch of licenses and
> deployment
> formats).

I am not sure why you mention RH here.

> Promoting Kleenex packaging, is ultimately self-defeating for Fedora. It
> does not create the community synergy, that makes working within a
> distribution worthwhile.
>
> The only people it makes happy are the devs that loathed any community
> or
> distribution engagement in the first place.
>
> Regards,
>
> --
> Nicolas Mailhot
> ___
> 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
___
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

Re: RFC: Modularity Simplified

[Igor Gnatenko]

On Mon, Dec 2, 2019, 04:43 Kevin Kofler  wrote:

> Igor Gnatenko wrote:
> > 1. Do we want to package multiple streams only for "leaf" software or
> > any kind of it?
> > I believe that we need both, and we do support both. However, it might
> > not look as nice as it could:
> > * Need to create multiple repos for different "streams"
> > * Need to maintain epel7/epel8/f30/f31/master branches
> > * Package names have to be "mangled" (e.g. mozjs38, mozjs60) and it is
> > manual work
>
> Your proposal addresses these, but skips the same requirement the current
> Modularity also fails to address by design, i.e.:
>
> > * However, those are supposed to be (according to the guidelines)
> > parallel-installable (and not be conflicting in any way)
>
> In particular, your proposal suggests:
>
> > * Packages produced from nodejs.src have Provides: stream(nodejs)
> > stream(nodejs:9) and Conflicts: stream(nodejs) so that it is
> > explicitly not possible to install 9 and 10 at the same time
>
> which explicitly excludes the parallel installability. So I do not see how
> it addresses the main drawback Modularity has compared to compatibility
> packages.
>
> (Note: The sentence as stated also means that the package Conflicts with
> itself, which will probably also badly confuse some tools, but that is a
> technical detail that should be fixable. It is the underlying concept of
> Conflicting with all other versions that is the real issue.)
>
> Your proposal is essentially a proposal to automate the creation of
> versioned (with suffixed Name) compatibility packages, but it excludes the
> most essential part of the compatibility package pattern, the one that
> makes
> it suited for this use case unlike the current Modularity. So I fail to
> see
> how it addresses in any way the issues we are having with the current
> Modularity.
>

Oh yeah, this is not only the thing I'm proposing. People want to have
"stream branch" and build from it to all Fedora and EPEL and I thought that
it was clear however it was not. Basically part of the proposal is to have
let's say branches by major version which builds into all releases.

You suggest to change the packaging guidelines to match the technical
> limitations of your proposed technology:
>
> > * Packaging guidelines should be adopted to accept conflicting
> > packages and tooling should be improved to show the conflicts and how
> > to resolve them
>
> but the guideline that compatibility packages should not conflict exists
> for
> a strong reason, and removing the guideline will not make the issues that
> lead to its existence magically go away.
>
> Non-default versions of non-leaf packages MUST be parallel installable
> with
> the default version for the distribution to be consistent and for users to
> be allowed to freely choose their applications without arbitrary conflicts.
>
> Otherwise (i.e., if parallel installability is not implemented), what you
> write:
>
> > Using some examples from previous threads, why does bugzilla have to be
> > built against 2 different versions of perl and users could choose? I
> think
> > maintainer should choose one version of perl and let bugzilla use it.
>
> is just not true. If the 2 different versions of Perl cannot coexist,
> building Bugzilla against only one version is not possible without making
> Bugzilla incompatible with anything built against the other version.
>
> I agree that we should only build each package against one version of Perl
> (the distribution default wherever possible, otherwise the most suitable
> version), but that requires that the users can actually install more than
> one version at the same time.
>
> But going back to your questions and answers:
>
> > 2. Do we want to support buildtime-only packages?
> > I would rather generalize this category as "less-supported packages".
>
> This is getting dangerously close to the strawman antipattern: you are
> modifying the question before answering it. That said, you then add:
>
> > Obviously, for packages which are used in runtime need a proper
> > support as we do today for all packages to share work
>
> which limits the scope to build-time-only packages again. So why did you
> attempt to modify it above?
>
> > I maintain 800+ Rust packages and very often I need to update them to
> > an incompatible version. In Rawhide I just do it, update all dependent
> > packages to use new version, and if I can't do that for some reason,
> > create "compat" package. Obviously, all patches are sent to the
> > upstream.
> > Upstreams are removing features, I need to

Re: RFC: Modularity Simplified

[Igor Gnatenko]

On Mon, Dec 2, 2019 at 8:28 AM Nicolas Mailhot via devel
 wrote:
>
> Le 2019-12-02 07:23, Igor Gnatenko a écrit :
> > On Tue, Nov 26, 2019 at 9:23 PM Nicolas Mailhot via devel
> >  wrote:
> >>
> >> Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit :
>
> >> > And we can't actually
> >> > have multiple versions of a package with same name (without "mangled"
> >> > names) in a repo due to the way how our buildsystem works (and not
> >> > only buildsystem, with some caveats).
> >>
> >> I suppose you're talking about filename here, because we certainly
> >> have
> >> packages that provide the same thing today. Anyway, this looks a lot
> >> less complex to fix than all the complexity modularity has already
> >> created.
> >
> > No, I am talking about package name here. Koji always takes latest
> > build for buildroot per name. So if you build foo-1-1 and then
> > foo-2-1, only the latter one will be in buildroot. Also tools like
> > pungi (compose tool) always takes latest version and nothing else.
>
> Actually, in that case, it would be better to have a foo-1 and foo-2
> package names. That's how the Go macros do it:
> 1. major version ends up in the package name name=foo-
> 2. if for some stupid reason there is a need for a specific code state
> within a major version, name=compat-foo--
>
> >> > I need to deal with Obsoletes but I
> >> > simply can't continuously add new Obsoletes into the
> >> > fedora-obsolete-packages.
> >>
> >> Then make the module build infra generate a garbage collector rpm per
> >> stream. That's the kind of repetitive thing it's supposed to handle.
> >
> > Do you have some idea how to do that?
>
> Make the module multibuild thinguie write a generated package list on
> each
> run; save the list  with the module descriptor in a git repo; on next
> run,
> add everything not re-generated to a modulename-obsoletes package.

I meant more how to do it technically, in Koji :)

> >> Anyway, this kind of package needs to exist and be supported as long
> >> as
> >> the resulting repo contains leaf packages built from it. Otherwise,
> >> you're breaking the security audit chain.
> >
> > No, I don't. They still exist in Koji
>
> That's academic. Downstream users do not get a koji copy, they get a
> copy
> of produced repos at a particular date. Please don't start shoving into
> deep koji corners materials that should end up in package repos. As long
> as things exist as Fedora packages, all their build chain must exist in
> Fedora package repos (with eventual minor version updates)
>
> Having all build elements in the package repos themselves is the CORE
> feature that makes the “share” community dimension of Fedora work.
> Anyone
> can take the packages and do whatever he wants with them (audit,
> rebuild,
> modify), in any rpm build infra (koji, copr, mock, rpmbuild, obs)
> without
> depending on the Fedora build infra of the year.

It would be nice, however please return back to the reality. Many of
packages are FTBFS (e.g. some BRs do not exist anymore (due to the
dependency update)). So this does not work in practice. It would be
cool to get to the point where Fedora repos are self-hosted, but we
are quite far from this.

> Regards,
>
> --
> Nicolas Mailhot
> ___
> 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
___
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

Re: RFC: Modularity Simplified

[Igor Gnatenko]

Hi Kevin,

On Mon, Dec 2, 2019 at 4:43 AM Kevin Kofler  wrote:
>
> Igor Gnatenko wrote:
> > 1. Do we want to package multiple streams only for "leaf" software or
> > any kind of it?
> > I believe that we need both, and we do support both. However, it might
> > not look as nice as it could:
> > * Need to create multiple repos for different "streams"
> > * Need to maintain epel7/epel8/f30/f31/master branches
> > * Package names have to be "mangled" (e.g. mozjs38, mozjs60) and it is
> > manual work
>
> Your proposal addresses these, but skips the same requirement the current
> Modularity also fails to address by design, i.e.:
>
> > * However, those are supposed to be (according to the guidelines)
> > parallel-installable (and not be conflicting in any way)
>
> In particular, your proposal suggests:
>
> > * Packages produced from nodejs.src have Provides: stream(nodejs)
> > stream(nodejs:9) and Conflicts: stream(nodejs) so that it is
> > explicitly not possible to install 9 and 10 at the same time
>
> which explicitly excludes the parallel installability. So I do not see how
> it addresses the main drawback Modularity has compared to compatibility
> packages.

Yes, however maintainer of nodejs does not want to rename binaries and
patch sources to be parallel-installable. And today, we would block
adding such "compat" package into the repositories. I agree it would
be nice to have them parallel-installable, but I don't think we need
to force it onto all packages.

> (Note: The sentence as stated also means that the package Conflicts with
> itself, which will probably also badly confuse some tools, but that is a
> technical detail that should be fixable. It is the underlying concept of
> Conflicting with all other versions that is the real issue.)
>
> Your proposal is essentially a proposal to automate the creation of
> versioned (with suffixed Name) compatibility packages, but it excludes the
> most essential part of the compatibility package pattern, the one that makes
> it suited for this use case unlike the current Modularity. So I fail to see
> how it addresses in any way the issues we are having with the current
> Modularity.

We have different problems with modularity, like:

* Whole new tooling which has its own inputs/outputs (and many times
it actually does not work)
* Overcomplication of dependency solving (even after so many years,
DNF still can't handle it properly)
* Different workflow from standard packages which hurts
discoverability and maintainability (basically it creates small
distros within one distro)

and many more.

> You suggest to change the packaging guidelines to match the technical
> limitations of your proposed technology:
>
> > * Packaging guidelines should be adopted to accept conflicting
> > packages and tooling should be improved to show the conflicts and how
> > to resolve them
>
> but the guideline that compatibility packages should not conflict exists for
> a strong reason, and removing the guideline will not make the issues that
> lead to its existence magically go away.
>
> Non-default versions of non-leaf packages MUST be parallel installable with
> the default version for the distribution to be consistent and for users to
> be allowed to freely choose their applications without arbitrary conflicts.

I believe that exactly one of the reasons why Modularity has been
created. It requires patching of source code and renaming binaries and
sometimes it is not trivial amount of work. And at the end of the day,
most of the people probably don't need installed multiple versions of
a package at the same time (e.g. nodejs).

> Otherwise (i.e., if parallel installability is not implemented), what you
> write:
>
> > Using some examples from previous threads, why does bugzilla have to be
> > built against 2 different versions of perl and users could choose? I think
> > maintainer should choose one version of perl and let bugzilla use it.
>
> is just not true. If the 2 different versions of Perl cannot coexist,
> building Bugzilla against only one version is not possible without making
> Bugzilla incompatible with anything built against the other version.

Sure, we just have to accept this until perl is made
parallel-installable. Which may or may not happen, but if I have
choice between "only one version of perl and no bugzilla" or "two
conflicting versions of perl and bugzilla using non-default version of
perl", I will choose latter. Unfortunately reality is not perfect.

> I agree that we should only build each package against one version of Perl
> (the distribution default wherever possible, otherwise the most suitable
> version), but that requires that the users can 

Re: RFC: Modularity Simplified

[Igor Gnatenko]

Hi Neal,

On Sat, Nov 30, 2019 at 11:58 PM Neal Gompa  wrote:
>
> On Tue, Nov 26, 2019 at 10:59 AM Igor Gnatenko
>  wrote:
> >
> > Hello fellows,
> >
> > After last publication on LWN about Fedora Modularity mess, I think it
> > is time to describe the idea I was proposing internally with few other
> > folks (Adam Samalik, Brian Exelbierd) back in the RH times.
> >
> > Before I actually go deep, I'll try to answer main questions to myself
> > (so that you can understand why I am proposing this particular thing).
> >
> > 1. Do we want to package multiple streams only for "leaf" software or
> > any kind of it?
> > I believe that we need both, and we do support both. However, it might
> > not look as nice as it could:
> > * Need to create multiple repos for different "streams"
> > * Need to maintain epel7/epel8/f30/f31/master branches
> > * Package names have to be "mangled" (e.g. mozjs38, mozjs60) and it is
> > manual work
> > * However, those are supposed to be (according to the guidelines)
> > parallel-installable (and not be conflicting in any way)
> > Doing git merge / git cherry-pick and maintaining many git remotes
> > requires some advanced git knowledge and a time. And we can't actually
> > have multiple versions of a package with same name (without "mangled"
> > names) in a repo due to the way how our buildsystem works (and not
> > only buildsystem, with some caveats).
> > We do have some kind of a solution for multiple releases building from
> > one branch (package.cfg), however this work has been never finished,
> > thus there are many problems with this approach.
> >
>
> I think we need to recognize that we've done some poor optimization
> for the majority of packager workflows. Even if we consider modules,
> the vast majority of components will never be modularized. Moreover,
> we already know that the overwhelming majority of specs are managed
> identically across branches.

Yeah, indeed. I think this (optimization of packager workflows) was
never an explicit goal of people working on Modularity.

> In these cases, we can make fedpkg better for handling this. There's
> no reason that people can't have a single master branch and only
> branch for distro releases as needed.
>
> I'm trying this workflow myself with libeconf[1], but unfortunately
> fedpkg doesn't handle this model well right now. I proposed a
> particular feature request for this[2], but there might be other ways
> to make this work. The current approach for package.cfg is terribly
> broken, though.

It definitely needs more thinking and probably requires more concrete
proposal how it should work overall. Not just "if package.cfg is
there, parse it and build for targets specified in there". I'm also
not entirely sure if we should encode this information in the git repo
as a file because it is not possible to query this information (e.g.
to find out which branches build where) and do checks (e.g. that you
don't build 1.x and 2.x in the f31 and you choose not to mangle
names).

> As for the name mangling, I think this is a relatively minor issue for
> supporting multiple versions of software. There *are* things we could
> do to minimize this, but it's not a good point to focus on right now.
>
> [1]: https://src.fedoraproject.org/rpms/libeconf
> [2]: https://pagure.io/fedpkg/issue/352
>
> > 2. Do we want to support buildtime-only packages?
> > I would rather generalize this category as "less-supported packages".
> > I maintain 800+ Rust packages and very often I need to update them to
> > an incompatible version. In Rawhide I just do it, update all dependent
> > packages to use new version, and if I can't do that for some reason,
> > create "compat" package. Obviously, all patches are sent to the
> > upstream.
>
> I think we should categorically disallow
> build-time-only/buildroot-only packages. They don't make sense in a
> Fedora context and make it impossible to share resources. What's worse
> with this model as it is currently implemented is that nobody can
> figure out whether there are buildroot-only packages involved, and
> multiple maintainers of packages basically can't happen.

Well, if we make easier builds for multiple targets (without pushing 5
times, creating 10 overrides and waiting for repos) and relax update
policy for such packages, then I definitely don't mind having them in
the main repo.

> Re-introducing those buildroot-only packages back into the main
> package collection gives people an opportunity to depend on them
> freely and co-maintain them. Now, we can't force anyone to co-maintain
> packages, but as we see with the l

Re: RFC: Modularity Simplified

[Igor Gnatenko]

Hey Michal,

On Sat, Nov 30, 2019 at 5:08 PM clime  wrote:
>
> Hey Igor,
>
> On Tue, 26 Nov 2019 at 17:00, Igor Gnatenko
>  wrote:
> >
> > Hello fellows,
> >
> > After last publication on LWN about Fedora Modularity mess, I think it
> > is time to describe the idea I was proposing internally with few other
> > folks (Adam Samalik, Brian Exelbierd) back in the RH times.
> >
> > Before I actually go deep, I'll try to answer main questions to myself
> > (so that you can understand why I am proposing this particular thing).
> >
> > 1. Do we want to package multiple streams only for "leaf" software or
> > any kind of it?
> > I believe that we need both, and we do support both. However, it might
> > not look as nice as it could:
> > * Need to create multiple repos for different "streams"
> > * Need to maintain epel7/epel8/f30/f31/master branches
> > * Package names have to be "mangled" (e.g. mozjs38, mozjs60) and it is
> > manual work
> > * However, those are supposed to be (according to the guidelines)
> > parallel-installable (and not be conflicting in any way)
> > Doing git merge / git cherry-pick and maintaining many git remotes
> > requires some advanced git knowledge and a time. And we can't actually
> > have multiple versions of a package with same name (without "mangled"
> > names) in a repo due to the way how our buildsystem works (and not
> > only buildsystem, with some caveats).
> > We do have some kind of a solution for multiple releases building from
> > one branch (package.cfg), however this work has been never finished,
> > thus there are many problems with this approach.
> >
> > 2. Do we want to support buildtime-only packages?
> > I would rather generalize this category as "less-supported packages".
> > I maintain 800+ Rust packages and very often I need to update them to
> > an incompatible version. In Rawhide I just do it, update all dependent
> > packages to use new version, and if I can't do that for some reason,
> > create "compat" package. Obviously, all patches are sent to the
> > upstream.
> > Upstreams are removing features, I need to deal with Obsoletes but I
> > simply can't continuously add new Obsoletes into the
> > fedora-obsolete-packages. And what for if they are used only during
> > build of other, more important, packages? Why do I have to spend time
> > with upgradepaths? I definitely want some mechanism which will tell to
> > user that "THIS PACKAGE IS NOT FULLY SUPPORTED."
> > Obviously, for packages which are used in runtime need a proper
> > support as we do today for all packages to share work (that's the
> > place where I agree with Kevin Kofler.)
> >
> > 3. Can we have different lifecycles for the software in Fedora?
> > Right now we have to keep all versions of software which was there at
> > GA point. And from the updates repo. We never remove packages
> > entirely. That said, if package was there at GA time, it will have to
> > be "supported" until the end of that Fedora release.
> > I don't think we can (should?) do much in this regard. If we make
> > packages to build from "stream" branch, we can put an information to
> > that branch that this package should be built for all distributions
> > (Fedora, EPEL) until this date. Or even store this info somewhere else
> > like PDC (yes, I know we want to kill it). fedpkg build will take this
> > into account and submit proper builds. And we can design some API in
> > infra which would tell until when some particular stream of a package
> > is supported. Much like it is done with Fedora releases & GNOME
> > Software.
> >
> > 4. Do we want to have some kind of "stream expansion" where software
> > builds against all Pythons, Perls and whatnot?
> > I think this should be conscious choice of a distribution, and in
> > specific cases, maintainer. Using some examples from previous threads,
> > why does bugzilla have to be built against 2 different versions of
> > perl and users could choose? I think maintainer should choose one
> > version of perl and let bugzilla use it. Being able to build
> > combinations of software is definitely nice, but I don't think this
> > should be standard practice. openSUSE does that with ruby and python
> > (they build all modules automatically for all versions) and I like
> > this. But having all packages built against all is just combinatoric
> > explosion. Given how many updates have feedback in Bodhi, I'm pretty
> > sure 99% of com

Re: RFC: Modularity Simplified

[Igor Gnatenko]

On Tue, Nov 26, 2019 at 9:23 PM Nicolas Mailhot via devel
 wrote:
>
> Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit :
>
> Hi, Igor
>
>
> > And we can't actually
> > have multiple versions of a package with same name (without "mangled"
> > names) in a repo due to the way how our buildsystem works (and not
> > only buildsystem, with some caveats).
>
> I suppose you're talking about filename here, because we certainly have
> packages that provide the same thing today. Anyway, this looks a lot
> less complex to fix than all the complexity modularity has already
> created.

No, I am talking about package name here. Koji always takes latest
build for buildroot per name. So if you build foo-1-1 and then
foo-2-1, only the latter one will be in buildroot. Also tools like
pungi (compose tool) always takes latest version and nothing else.

> > I need to deal with Obsoletes but I
> > simply can't continuously add new Obsoletes into the
> > fedora-obsolete-packages.
>
> Then make the module build infra generate a garbage collector rpm per
> stream. That's the kind of repetitive thing it's supposed to handle.

Do you have some idea how to do that?

> Anyway, this kind of package needs to exist and be supported as long as
> the resulting repo contains leaf packages built from it. Otherwise,
> you're breaking the security audit chain.

No, I don't. They still exist in Koji and if needed, it can be
"reproduced". It simply keeps packages which were used in buildroot of
any build. Definitely it is more complicated than this, but that's how
it works in short.

> > Are we trying to create
> > technologies which would be very extensible and used in other
> > distributions instead of solving some specific problems?
>
> In my experience, solving specific problems should come first. You
> won't get any adoption elsewhere without showing some practical benefit
> Fedora-side, and chasing all-encompasing mythical beasts is a great way
> to burn time and money without ever delivering anything.
>
> >
> > * If desired, packages can depend on a specific stream via Requires:
> > stream(nodejs:10) without actually depending on nodejs (this requires
> > some small piece of code in libsolv)
>
> Why the heck would you want that? Packages should not depend on stream
> anymore than they depend on a release as a whole. They should depend on
> something specifically inside a stream. And that's just a
> Requires: something with stream(streamname)

yeah, sure. I just wanted to point out that we *can* do that, not that
we *need* to actually do it.

> > * All standard Conflicts/Requires/Obsoletes/… will simply work
>
> Yes, please make it back a single unified rpm-level dependency graph
> instead of separate module universes that don't behave with one another
> or with the main distro stream.
>
> That would be totally AWESOME
>
> Regards,
>
> --
> Nicolas Mailhot
> ___
> 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
___
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

Re: RFC: Modularity Simplified

[Igor Gnatenko]

On Tue, Nov 26, 2019 at 6:35 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> As a meta-goal, we should break up "Modularity" into a number of
> separate components, some build-side, some client-side. Modularity
> suffers greatly from trying to encode everything into one document.
> This greatly raises the complexity of the task and makes it hard to
> consider alternative proposals for various parts.
>
> Let's consider them separately:
>
> 1. what to build against what branches
>
> You said:
> > * each has package.cfg or some alternative which specifies what is the
> > EOL and/or for which releases to build
>
> Right now we use dist-git branches for this. Having a package.cfg
> might sound easier , but the caveat is that building against different
> branches requires tweaks sometimes. So we immediately hit a choice: do
> we want a single branch and the %ifdef mess, or multiple branches and
> the cherry picking troubles.

Yeah, but if there is clear map between branches & builds stored
somewhere, it could be quite convenient for both. If you say "I want
to have separate branches", then you still have f31/f32 while you
should be able to say "I have 2.x branch and it is going to be built
in all releases". That should be easily discoverable.

> Right now, big disadvantage of multiple branches is that %changelogs
> and Release bumps introduce trivial conflicts. I think we should
> explore the proposals (incl. your and Neal's) to make this better.
> Fixing this would be good also for normal packaging, because it'd remove
> one or two more steps that need to be done every time.

Yeah, at the current job I'm exploring something similar so when I get
some time, I'll try to write proposal.

> We should explore both directions, i.e. package.conf and easier branches.

+1

> We should experiment with better/easier control of what to build
> where. This would benefit normal packaging too. Right now our tooling
> is just hard to use, with multiple commands in different tools needed
> to start builds, schedule updates, control koji status, etc. We need
> changes for "normal" packages as much as for "streams".

+1

> 2. how to deliver rpms to users and how to let them control installed versions
>
> > How I would imagine having multiple streams:
> > * rpms/nodejs has multiple branches - 10, 11, 12
> > * in all of them, nodejs.spec exists as-is without "mangled" name
> > (just with different versions and such)
> > * when builds are submitted, Koji automatically adds suffix to a main
> > package and subpackages containing branch name
> > * during the rpmbuild, extra provides are added (for the unversioned
> > names and indication of a stream) and conflicts (possibly depending on
> > some macro which user can disable) automatically
>
> Yes. The crucial part is that the rpms that are delivered are
> just normal rpms. All the complications are kept on the build-side
> and the client side doesn't need to care if this magic happened, the
> same result could have been achieved with manually mangled spec file.
>
> > * If software needs to specify that it wants 9 ≤ nodejs ≤ 11 it can
> > describe this in standard way (Requires: (nodejs >= 9 with nodejs <=
> > 11)) and one will be picked up automatically
> > ...
> > * All standard Conflicts/Requires/Obsoletes/… will simply work
>
> Yes. More of "just normal packages".
>
> > * If user wants to switch from 9 to 10, he can run `dnf swap nodejs9 
> > nodejs10`
> > * If that requires some conflicting dependency to be switched, it will
> > be switched automatically
> > * Packages produced from nodejs.src have Provides: stream(nodejs)
> > stream(nodejs:9) and Conflicts: stream(nodejs) so that it is
> > explicitly not possible to install 9 and 10 at the same time
> > * If desired, packages can depend on a specific stream via Requires:
> > stream(nodejs:10) without actually depending on nodejs (this requires
> > some small piece of code in libsolv)
> > * In the very similar way, user can lock themselves to a specific
> > stream by writing some conf file which DNF would read (if point above
> > is implemented, about just tens of lines of the code in libdnf, or
> > even libsolv can be teached about that as well)
> > * DNF can be teached about these special things so that you can
> > automatically swap conflicting dependencies, but lock yourself to some
> > streams of a package
>
> ... and here I'm not sure. I'm not convinced we need to try to manage
> all this like that. We already have packages which Conflict, or specify
> conflicting Requires, and the user gives a dnf command, and a certain
> transaction is prepared for them. The transaction will occasionally
> specify a list of rpms to remove. If the user doesn't like this, they can
> cancel and give a different command.

This would imply that we have --allowerasing set by default, but we
don't... And probably we should not since it is dangerous (a bit?).

> Specifically, some streams might conflict, other might not, etc.
> We could have a macro 

Re: RFC: Modularity Simplified

[Igor Gnatenko]

On Sat, Nov 30, 2019 at 9:28 PM Kevin Fenzi  wrote:
>
> On Tue, Nov 26, 2019 at 05:35:27PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > As a meta-goal, we should break up "Modularity" into a number of
> > separate components, some build-side, some client-side. Modularity
> > suffers greatly from trying to encode everything into one document.
> > This greatly raises the complexity of the task and makes it hard to
> > consider alternative proposals for various parts.
> >
> > Let's consider them separately:
> >
> > 1. what to build against what branches
> >
> > You said:
> > > * each has package.cfg or some alternative which specifies what is the
> > > EOL and/or for which releases to build
> >
> > Right now we use dist-git branches for this. Having a package.cfg
> > might sound easier , but the caveat is that building against different
> > branches requires tweaks sometimes. So we immediately hit a choice: do
> > we want a single branch and the %ifdef mess, or multiple branches and
> > the cherry picking troubles.
>
> Yeah, this is a difficult thing to answer, since there's people in both
> camps right now happy with either end, and lots in between.
> >
> > Right now, big disadvantage of multiple branches is that %changelogs
> > and Release bumps introduce trivial conflicts. I think we should
> > explore the proposals (incl. your and Neal's) to make this better.
> > Fixing this would be good also for normal packaging, because it'd remove
> > one or two more steps that need to be done every time.
>
> +1
>
> > We should explore both directions, i.e. package.conf and easier branches.
> >
> > We should experiment with better/easier control of what to build
> > where. This would benefit normal packaging too. Right now our tooling
> > is just hard to use, with multiple commands in different tools needed
> > to start builds, schedule updates, control koji status, etc. We need
> > changes for "normal" packages as much as for "streams".
>
> I wonder if we couldn't explore using tags for this.
> ie, if you tag a commit in a specific way it tells the system what to
> build, what to run ci on, etc.

IMO we should be building and testing all commits automatically unless
maintainer put some comment like "[skip ci]" in the commit message.

> ...snip...
> >
> > A different proposal: we add a new rpm flag (maybe as a special
> > Requires: line) that specifies that a package is only supported as a
> > build-time dependency. DNF could then gain a trivial patch that
> > it would ask the user "Do you want to install those unsupported packages?
> > If you do, please do not file bugs, because ...".
> > The advantages:
> > a) packages are available for local builds and downstream rebuilds
> > b) no problem with mock and koji being different
> > c) we avoid any perception of "welding down the engine hood".
> >
> > This would just acknowledge the truth that there are many packages
> > in Fedora that are not supported beyond an occasional version bump
> > and rebuild, giving better transparency for the users in general.
>
> Well, if we are doing that, couldn't we just not add bugzilla components
> for them? But perhaps we do want the bugs, even if the package isn't
> 'maintained' wouldn't it still be good to know about bugs?

I think we still should create BZ (or have it opt-out and have issues
on pagure?) because it is useful to get bugreports about some CVE and
whatnot.

> ...snip...
> > I think we should allow "rolling" versions more widely, like we do with
> > firefox, the kernel, spam blockers, and probably some other things.
> > As long some piece software is most backwards compatible, I think we'd
> > be better of abandoning the strict guidelines we have now.
> > This depends on each specific package though.
>
> Yes, I think this very much depends on the package.
>
> 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
___
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

Re: Announcing new anitya integration and de-orphaning process

[Igor Gnatenko]

Because it is really hard to run two systems at the same time and keep them
synced?

On Thu, Nov 28, 2019, 14:43 Mat Booth  wrote:

> On Tue, 26 Nov 2019 at 17:21, Pierre-Yves Chibon 
> wrote:
> >
> > Good Morning Everyone,
> >
> > Tomorrow we are planning on deploying a new version of pagure and
> > pagure-dist-git on production.
>
>
> Great stuff. I still don't understand why pkgdb was allowed to go away
> before the replacements reached feature parity.
> ___
> 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
>
___
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

Re: Do we need a "No broken deps" Objective?

[Igor Gnatenko]

Last time I checked, it was basically checking only the first part of
"with" richop. I believe it is still broken the same way.

On Thu, Nov 28, 2019, 17:33 Fabio Valentini  wrote:

> On Mon, Nov 25, 2019 at 2:08 PM Igor Gnatenko
>  wrote:
> >
> > Hey Fabio,
>
> (snip)
>
> > There is a problem with the code. You seem to run either repoquery or
> > repoclosure inside. However, that does not really check rich
> > dependencies correctly.
>
> To follow up on this: It turns out DNF's repoclosure *does* correctly
> report broken dependencies, even for rich dependencies (or it's not as
> broken as we thought).
> Checking a random sample of the reported "broken rich dependencies"
> manually, it turned out every single one I checked was *actually
> unsatisfiable*, and not caused by a DNF / repoclosure bug.
>
> Fabio
>
> > Do you want to check for FTI/FTBFS or that all dependencies are
> > present in Fedora?
> >
> > On Mon, Nov 25, 2019 at 1:23 PM Fabio Valentini 
> wrote:
> > >
> > > Hi everybody,
> > >
> > > I'm a bit concerned about the growing number of broken dependencies in
> > > fedora, which leads to non-installable (FTI) and un-buildable (FTBFS)
> > > packages. For rawhide [0], I see almost 400 source packages and almost
> > > 200 x86_64 packages with broken deps. Especially the number of source
> > > packages with broken dependencies has steadily been growing since 29.
> > >
> > > With a bit of effort, a lot of these broken packages could be fixed
> > > quite easily, but it would still need a coordinated effort by a group
> > > of people. I think an Objective would fit for that purpose.
> > >
> > > Fabio
> > >
> > > PS: Feel free to browse the data in the linked pagure repo. I'm
> > > regenerating it daily with the latest state of all fedora branches. If
> > > somebody is interested in getting notified about any of their packages
> > > getting broken deps (for example, in -testing, before things get
> > > broken in stable), I can work out some kind of automatic (opt-in)
> > > notification system :)
> > >
> > > [0]:
> https://pagure.io/fedora-health-check/blob/master/f/reports/report-rawhide.md
> > > ___
> > > 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
> > ___
> > 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
> ___
> 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
>
___
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

Re: Is 50+ RPM Subpackages too extreme?

[Igor Gnatenko]

No, 50 is perfectly fine. As others mentioned, we have much bigger amount
of them in texlive.

If those are like plugins which may or may not require other packages, I
would split them. And probably put Recommends in the main package for the
most used ones.

On Wed, Nov 27, 2019, 02:58 Chris  wrote:

> Hi guys,
>
> I just wanted to poll you for some advice.  My notification tool I
> maintain supports more than 50+ services now, but the only package
> isolation I do within 2 RPMs.  One for the actual CLI (for admin's who want
> to use it) and the other is for the backend library (for Devs). I only ask
> because each supported service is very modular.
>
> I kind of like the way nagios-plugins breaks apart it's check_scripts into
> many sub-packages, but 50+ subpackages seems a bit extreme... or is it? It
> certainly seems like a bit of a nightmare to maintain; it would be one very
> large .spec file.
>
> You can see the directory structure here on GitHub:
> https://github.com/caronc/apprise
>
> Effectively every single file in "apprise/plugins/Notify*.py" is it's own
> plugin-able module.  You can add/remove content into here and the tool
> adapts. Thus the sub-packages would only include 1 file per RPM.
>
> Is it advisable to go this route? I presume there is no easy way to
> transition without breaking users existing setup? I don't know what the d/l
> stats are; so there may not be a large enough audience to even need to
> worry about this?
>
> What are your thoughts and/or advice?
> ___
> 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
>
___
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

RFC: Modularity Simplified

[Igor Gnatenko]

Hello fellows,

After last publication on LWN about Fedora Modularity mess, I think it
is time to describe the idea I was proposing internally with few other
folks (Adam Samalik, Brian Exelbierd) back in the RH times.

Before I actually go deep, I'll try to answer main questions to myself
(so that you can understand why I am proposing this particular thing).

1. Do we want to package multiple streams only for "leaf" software or
any kind of it?
I believe that we need both, and we do support both. However, it might
not look as nice as it could:
* Need to create multiple repos for different "streams"
* Need to maintain epel7/epel8/f30/f31/master branches
* Package names have to be "mangled" (e.g. mozjs38, mozjs60) and it is
manual work
* However, those are supposed to be (according to the guidelines)
parallel-installable (and not be conflicting in any way)
Doing git merge / git cherry-pick and maintaining many git remotes
requires some advanced git knowledge and a time. And we can't actually
have multiple versions of a package with same name (without "mangled"
names) in a repo due to the way how our buildsystem works (and not
only buildsystem, with some caveats).
We do have some kind of a solution for multiple releases building from
one branch (package.cfg), however this work has been never finished,
thus there are many problems with this approach.

2. Do we want to support buildtime-only packages?
I would rather generalize this category as "less-supported packages".
I maintain 800+ Rust packages and very often I need to update them to
an incompatible version. In Rawhide I just do it, update all dependent
packages to use new version, and if I can't do that for some reason,
create "compat" package. Obviously, all patches are sent to the
upstream.
Upstreams are removing features, I need to deal with Obsoletes but I
simply can't continuously add new Obsoletes into the
fedora-obsolete-packages. And what for if they are used only during
build of other, more important, packages? Why do I have to spend time
with upgradepaths? I definitely want some mechanism which will tell to
user that "THIS PACKAGE IS NOT FULLY SUPPORTED."
Obviously, for packages which are used in runtime need a proper
support as we do today for all packages to share work (that's the
place where I agree with Kevin Kofler.)

3. Can we have different lifecycles for the software in Fedora?
Right now we have to keep all versions of software which was there at
GA point. And from the updates repo. We never remove packages
entirely. That said, if package was there at GA time, it will have to
be "supported" until the end of that Fedora release.
I don't think we can (should?) do much in this regard. If we make
packages to build from "stream" branch, we can put an information to
that branch that this package should be built for all distributions
(Fedora, EPEL) until this date. Or even store this info somewhere else
like PDC (yes, I know we want to kill it). fedpkg build will take this
into account and submit proper builds. And we can design some API in
infra which would tell until when some particular stream of a package
is supported. Much like it is done with Fedora releases & GNOME
Software.

4. Do we want to have some kind of "stream expansion" where software
builds against all Pythons, Perls and whatnot?
I think this should be conscious choice of a distribution, and in
specific cases, maintainer. Using some examples from previous threads,
why does bugzilla have to be built against 2 different versions of
perl and users could choose? I think maintainer should choose one
version of perl and let bugzilla use it. Being able to build
combinations of software is definitely nice, but I don't think this
should be standard practice. openSUSE does that with ruby and python
(they build all modules automatically for all versions) and I like
this. But having all packages built against all is just combinatoric
explosion. Given how many updates have feedback in Bodhi, I'm pretty
sure 99% of combination won't be tested (or even installed?) ever.

5. Are we still trying to be a Linux distribution or we are just
letting people to do whatever they want in our infrastructure?
This question bothers me from time to time and I don't have answer.
For example, Modularity is very flexible and I very often find people
saying that you can expand this and that, but in Fedora we limit its
usefulness. Do we actually need to develop something like this
(knowing in advance that probably nobody outside of Fedora/RHEL will
be using this software / technology)? Are we trying to create
technologies which would be very extensible and used in other
distributions instead of solving some specific problems? If former,
why don't we talk to others about things in advance and not getting
other people to work on these cool things?

===

How I would imagine having multiple streams:
* rpms/nodejs has multiple branches - 10, 11, 12
* in all of them, nodejs.spec exists as-is without "mangled" name

Re: Do we need a "No broken deps" Objective?

[Igor Gnatenko]

Hey Fabio,

There is a problem with the code. You seem to run either repoquery or
repoclosure inside. However, that does not really check rich
dependencies correctly.

Do you want to check for FTI/FTBFS or that all dependencies are
present in Fedora?

On Mon, Nov 25, 2019 at 1:23 PM Fabio Valentini  wrote:
>
> Hi everybody,
>
> I'm a bit concerned about the growing number of broken dependencies in
> fedora, which leads to non-installable (FTI) and un-buildable (FTBFS)
> packages. For rawhide [0], I see almost 400 source packages and almost
> 200 x86_64 packages with broken deps. Especially the number of source
> packages with broken dependencies has steadily been growing since 29.
>
> With a bit of effort, a lot of these broken packages could be fixed
> quite easily, but it would still need a coordinated effort by a group
> of people. I think an Objective would fit for that purpose.
>
> Fabio
>
> PS: Feel free to browse the data in the linked pagure repo. I'm
> regenerating it daily with the latest state of all fedora branches. If
> somebody is interested in getting notified about any of their packages
> getting broken deps (for example, in -testing, before things get
> broken in stable), I can work out some kind of automatic (opt-in)
> notification system :)
>
> [0]: 
> https://pagure.io/fedora-health-check/blob/master/f/reports/report-rawhide.md
> ___
> 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
___
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

Re: Modularity and the system-upgrade path

[Igor Gnatenko]

Yes, but what you have described is basically to create 2 streams of
perl-Sys-Virt module. Which is probably not what normal people want.
Creating module for one package is the worst idea ever.

Sure, bundling perl-Sys-Virt into the libvirt module would solve the
problem, but then what's the point of modules? You will be building
libvirt itself then multiple times due to the stream expansion.

On Tue, Nov 19, 2019 at 11:38 AM Petr Pisar  wrote:
>
> On 2019-11-15, Igor Gnatenko  wrote:
> > On Fri, Nov 15, 2019, 17:38 Petr Pisar  wrote:
> >> On 2019-11-15, Daniel P  Berrang=C3=A9  wrote:
> >> >
> >> > Consider if we move the virtualization stack (QEMU & Libvirt) into a
> >> > module with two streams, one libvirt 5.8.0 and one libvirt 6.1.0.
> >> >
> >> > Now we want to build Perl bindings for libvirt. We'll need the
> >> > corresponding version of perl-Sys-Virt either 5.8.0 or 6.1.0,
> >> > built for each virt module stream, but also built for each Perl
> >> > module stream 5.26 / 5.30. eg the combinatorial expansion
> >> >
> >> >  -   perl-Sys-Virt 5.8.0   with libvirt 5.9.0 with perl 5.26
> >> >  -   perl-Sys-Virt 5.8.0   with libvirt 5.9.0 with perl 5.30
> >> >  -   perl-Sys-Virt 6.1.0   with libvirt 6.1.0 with perl 5.26
> >> >  -   perl-Sys-Virt 6.1.0   with libvirt 6.1.0 with perl 5.30
> [...]
> > The problem described by Daniel was that Perl module should be different
> > version when building against 5.x libvirt.
> >
> >> Example: Let's say you have libvirt module with 5.8.0 and 6.1.0 streams
> >> and perl module with 5.26 and 5.30 streams. If you add perl-Sys-Virt
> >> into a new module, you write a modulemd file for it like this:
> >>
> >> - buildrequiers:
> >> libvirt: [5.8.0, 6.1.0]
> >> perl: [5.26, 5.30]
> >> platform: [f32]
> >>   requires:
> >> libvirt: [5.8.0, 6.1.0]
> >> perl: [5.26, 5.30]
> >> platform: [f32]
> >>
> You are right. Then either you put perl-Sys-Virt 5.8.0 into
> a perl-Sys-Virt:5.8.0 stream with this dependency specification:
>
> - buildrequiers:
> libvirt: [5.9.0]
> perl: [5.26, 5.30]
> platform: [f32]
>   requires:
> libvirt: [5.9.0]
> perl: [5.26, 5.30]
> platform: [f32]
>
> and perl-Sys-Virt 6.1.0 package into perl-Sys-Virt:6.1.0 stream with:
>
> - buildrequiers:
> libvirt: [6.1.0]
> perl: [5.26, 5.30]
> platform: [f32]
>   requires:
> libvirt: [6.1.0]
> perl: [5.26, 5.30]
> platform: [f32]
>
> Or you put perl-Sys-Virt package into libvirt module and for
> libvirt:5.9.0 stream you write:
>
> - buildrequiers:
> perl: [5.26, 5.30]
> platform: [f32]
>   requires:
> perl: [5.26, 5.30]
> platform: [f32]
>
> and for libvirt:6.1.0 stream you do the same.
>
> What approach you want to choose probably depends on compatibility
> among perl-Sys-Virt package versions and among libvirt versions. And how
> often they are released.
>
> I.e. if you can rebase perl-Sys-Virt inside libvirt stream because
> perl-Sys-Virt does not break ABI, then it makes sense to keep it inside
> libvirt module. That's because public ABI of a module should not change
> inside a stream.
>
> You can also consider how expensive is to build, test and deliver the
> libvirt module. If e.g. building perl-Sys-Virt were much quicker than
> building libvirt, and there were plenty of perl streams, then it would
> make sense to move perl-Sys-Virt package into its own module.
>
> I think it's a similar problem as to when bundle all dependencies into
> one package and when to aim for splitting it into muliple independent
> packages.
>
> -- Petr
> ___
> 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
___
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

Re: Modularity and the system-upgrade path

[Igor Gnatenko]

On Fri, Nov 15, 2019, 17:38 Petr Pisar  wrote:

> On 2019-11-15, Daniel P  Berrangé  wrote:
> > On Fri, Nov 15, 2019 at 02:53:08PM -, Petr Pisar wrote:
> >> On 2019-11-15, John M. Harris Jr  wrote:
> >> > On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote:
> >> >> Example: I have Perl 5.26 as a default version. I have Perl 5.30 as
> an
> >> >> laternative version. Now I want to package Bugzilla that's written in
> >> >> Perl. How do you package Bugzilla so that it works with Perl 5.26 as
> >> >> well as with Perl 5.30?
> >> >
> >> > This sounds like a bug in Modularity.
> >>
> >> Modularity can achieve it when both Perls are packaged as a module. I'm
> >> only showing why we need default stream if we want modules.
> >
> > I'm interested in how this should work when two different modules
> > interact, and we need a language binding across both modules.
> >
> > Consider if we move the virtualization stack (QEMU & Libvirt) into a
> > module with two streams, one libvirt 5.8.0 and one libvirt 6.1.0.
> >
> > Now we want to build Perl bindings for libvirt. We'll need the
> > corresponding version of perl-Sys-Virt either 5.8.0 or 6.1.0,
> > built for each virt module stream, but also built for each Perl
> > module stream 5.26 / 5.30. eg the combinatorial expansion
> >
> >  -   perl-Sys-Virt 5.8.0   with libvirt 5.9.0 with perl 5.26
> >  -   perl-Sys-Virt 5.8.0   with libvirt 5.9.0 with perl 5.30
> >  -   perl-Sys-Virt 6.1.0   with libvirt 6.1.0 with perl 5.26
> >  -   perl-Sys-Virt 6.1.0   with libvirt 6.1.0 with perl 5.30
> >
> True, you have 4 combinations.
>
> > which module would the perl-Sys-Virt builds live in ?
> >
> > If perl-Sys-Virt is part of the virt module, IIUC we'd only be
> > able to build it for one specific perl module stream.
> >
> > If perl-Sys-Virt is part of the perl module, IIUC we'd only be
> > able to build it for one specific virt module stream
> >
> > It looks to me like we have to create a new module just to hold
> > the perl-Sys-Virt package, and give this 4 streams, to cover the
> > combinatorial expansion of the perl & virt module streams. Is
> > this right ?
> >
> No. Modularity solves this combination problem with "stream expansion".
> Sources for such module exists only once, you submit them for building
> with fedpkg only once, but a build systems computes all combinations
> (this the stream expansion) and schedules a build for each of the
> combination. That will result in multiple module builds with the same
> module name, stream, version, but differing with a special
> discriminator called "context".
>

The problem described by Daniel was that Perl module should be different
version when building against 5.x libvirt.

Example: Let's say you have libvirt module with 5.8.0 and 6.1.0 streams
> and perl module with 5.26 and 5.30 streams. If you add perl-Sys-Virt
> into a new module, you write a modulemd file for it like this:
>
> - buildrequiers:
> libvirt: [5.8.0, 6.1.0]
> perl: [5.26, 5.30]
> platform: [f32]
>   requires:
> libvirt: [5.8.0, 6.1.0]
> perl: [5.26, 5.30]
> platform: [f32]
>
> "fedpkg module-build" on it will spawn 4 builds. Even you don't have to
> enumerate the streams and let the module build system to figure out it
> automatically and expand for all existing:
>
> - buildrequiers:
> libvirt: []
> perl: []
> platform: []
>   requires:
> libvirt: []
> perl: []
> platform: []
>
> Or you can put perl-Sys-Virt into libvirt module and write into libvirt
> modulemd of each of the libvirt streams:
>
> - buildrequiers:
> perl: []
> platform: []
>   requires:
> perl: []
> platform: []
>
> You can see these modules in RHEL or CentOS. E.g. perl-DBD-Pg module
> <
> https://git.centos.org/modules/perl-DBD-Pg/blob/c8-stream-3.7/f/perl-DBD-Pg.yaml
> >.
>
> When installing the module, DNF makes sure to select a proper context
> for libvirt and perl you have already selected. If it happened that you
> built it only for Perl 5.26, but you have already enabled Perl 5.24 on
> your system, DNF will report an error that 5.26 module is needed but it
> is disabled.
>
> > And we'd have to do create more modules for every other language
> > binding we ship (ocaml, python, ruby, etc) if the language runtime
> > uses modules.
> >
> You can put all the bindings into one module. Or each binding into its
> own module. Whatever fits your needs better.
>
> -- Petr
> ___
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email 

Re: What are the benefits of default modular streams over non-modular packages?

[Igor Gnatenko]

On Fri, Nov 15, 2019 at 3:38 PM Joe Orton  wrote:
>
> On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote:
> > Where is the end-user benefit with the modular default stream? I don't see
> > it either, sorry.
>
> It's not clear to me how those examples are related to my argument,
> which I could summarize as:
>
> a) multiple module streams have a benefit to users, and
> b) default streams have a benefit to package owners.

You quoted Miro above, "end-user benefit". He is not talking about
packaging experience here, which is pretty bad with modules.

> > > This comes at a high cost to package owners if we have to keep
> > > non-modular packages - we have to maintain, build, and test X streams
> > > plus Y non-modular release branch builds for each component, rather than
> > > just X streams.
> >
> > Yes. This is the benefit of the default modular stream for the modular
> > maintainers. I have never questioned it.
>
> OK great, though it is a bit surprising to hear in a thread which you
> started explicitly to question the benefits of default modular streams.
>
> > In my opinion (and that is my very subjective opinion, but based on
> > experience) the cost of that difference is otherwise paid by everybody else.
> >
> > The group of everybody else is very much bigger than the group of modular
> > maintainers. Hence, I'd approve such trade off.
>
> So it's clear to me that you see that packagers chosing default streams
> over non-modular packages impose external costs on the rest of the
> distro (packagers and/or users?) somehow.  This thread was supposed to
> focus on benefits, and these vague claims about costs and trade-offs
> seem speculative, but maybe you could expand on that a bit?
>
> Perhaps this stuff is obvious to others already.  In RHEL8 while we have
> certainly hit various problems with modularity at least I don't recall
> my teams hitting major issues with default streams being available for
> non-modular packages.

Because they just have to do it, they don't have option to choose
technology. They get paid to do their job.

>
> Regards, Joe
> ___
> 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
___
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

Re: Modularity: The Official Complaint Thread

[Igor Gnatenko]

Except that modular packages shadow non-modular so instead of getting
proper package you will have broken dependency.

On Fri, Nov 15, 2019, 10:03 Nicolas Mailhot via devel <
devel@lists.fedoraproject.org> wrote:

> Le 2019-11-14 22:01, Stephen Gallagher a écrit :
> > On Thu, Nov 14, 2019 at 4:00 PM Miro Hrončok 
> > wrote:
> >>
> >> On 14. 11. 19 21:32, Stephen Gallagher wrote:
> >> >I proposed earlier around the major
> >> > upgrade rebuilds (letting us set other modules as `buildrequires:` of
> >> > `python: [ ]` for stream expansion) without actually having to build
> >> > the complete python stack in the modules. That might be a really
> >> > convenient strategy, honestly.
> >>
> >> Convenient to achieve what exactly?
> >>
> >
> > To achieve an easy way to deal with modular rebuilds for new Python 3
> > versions.
>
> How is that different, exactly, from adding a
> Provides: module(modulename)
> for in-module packages
>
> and letting packagers use a normal dep syntax like
> (foo with module(modulename))
> whenever they want to express they want the module version of a
> particular dep?
>
> Except for adding the opaque module object to the mix that obscures all
> dependency chain checks?
>
> Regards,
>
> --
> Nicolas Mailhot
> ___
> 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
>
___
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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Igor Gnatenko]

On Thu, Nov 14, 2019 at 7:48 PM Stephen Gallagher  wrote:
>
> On Thu, Nov 14, 2019 at 12:12 PM Miro Hrončok  wrote:
> >
> > On 09. 10. 19 22:46, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
> > >
> > > Enable module default streams in the buildroot repository for modular
> > > and non-modular RPMs.
> > >
> > > == Summary ==
> > > This Change (colloquially referred to as "Ursa Prime") enables the
> > > Koji build-system to include the RPM artifacts provided by module
> > > default streams in the buildroot when building non-modular (or
> > > "traditional") RPMs.
> >
> > I have one more technical concern.
> >
> > Suppose a packager decides to package the "mycoolapp" software as a 
> > non-modular
> > package. "mycoolapp" is written in Python, it builds again non-modular 
> > Python,
> > currently 3.8, it requires "python(abi) = 3.8" on runtime.
> >
> > The packager decides to use avocado in %check. Avocado comes from a module, 
> > it
> > requires "python(abi) = 3.8" as well, because the modular package was built 
> > with
> > Python 3.8. Avocado is in the bulidroot, so everything works.
> >
> > The Python maintainers (that includes me) decide to update to Python 3.9 in
> > Fedora 33. They request a side tag to do that. They update the python3 to 
> > 3.9
> > and they mass rebuild all non-modular Python packages in it. "mycoolapp" 
> > cannot
> > resolve build dependencies because avocado requires "python(abi) = 3.8".
> >
> > The Python maintainers need to detect this and figure out what happened.
> > Then, the Python maintainers need to either:
> >
> >   1. Exclude "mycoolapp" from the rebuild. That is possible until dozens of
> > other packages require "mycoolapp".
> >
> >   2. Ask the avocado maintainers to rebuild their module in the side tag 
> > and ask
> > releng to add the side-tag-built module into the side-tag buildroot (if it 
> > is
> > even possible).
> >
> >   3. Modify the spec of "mycoolapp" to temporarily disable %check and loose 
> > the
> > avocado dependency.
> >
> > Or is there some other way?
> >
>
> Does Python actually break ABI on minor releases? So a full rebuild is
> required for that case?
>
> What we would probably need to do is tag the python39 build into the
> modular buildroot for the appropriate platform and then rebuild
> avocado while that was in the buildroot.

That would mean, each release - bunch of additional manual work.

> Another option would be to create a `python3` module stream for each
> minor release and make one of them the default stream for the side-tag
> so the non-modular versions could be built against that. Then the
> avocado module would set its dependencies to be:
> ```
> buildrequires:
>   platform: [ ]
>   python3: [ ]
> ```
> (Read: build for all streams of python for all available platforms).
> Then whenever the default stream of python3 changes over in Rawhide,
> avocado would follow because it was already built for the next
> version.

This implies that Python maintainers want to deal with Modularity
which I believe is not the case.

> ___
> 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
___
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

Re: Modularity: The Official Complaint Thread

[Igor Gnatenko]

On Tue, Nov 12, 2019, 14:13 Aleksandra Fedorova  wrote:

> Hi,
>
> On Tue, Nov 12, 2019 at 10:50 AM Dominik 'Rathann' Mierzejewski
>  wrote:
> >
> > Hi.
> > I've been silent so far, while mostly agreeing with the "let's just drop
> > Modularity" proposal. This post hit a nerve, so I felt compelled to
> reply.
> >
> > On Monday, 11 November 2019 at 19:24, Stephen Gallagher wrote:
> > > On Mon, Nov 11, 2019 at 1:15 PM Robbie Harwood 
> wrote:
> > [...]
> > > > It's really frustrating to be repeatedly told we're not arguing in
> good
> > > > faith and then see things like this (from today's fesco meeting [1]):
> > > >
> > > > 15:48:07  Can we please stop pretending like "start
> over
> > > > from scratch" is a real option?
> > > >
> > > > Starting from scratch should be an option.  Removing modularity
> entirely
> > > > should be an option.  Of course, so should be using modularity as it
> > > > exists (or modifying it), but if we don't have those first two as
> > > > options when there are proponents, this isn't a real technical
> > > > discussion.
> > >
> > > That quote is not fully in context, but that's entirely fair because I
> > > didn't include enough context during the FESCo meeting. I apologize
> > > for that. (Also, as you can tell from the rest of the log, I was
> > > getting frustrated by that point).
> > >
> > > When I said it's not a real option, I did not include any of my
> > > reasoning (thus Begging the Question as you rightly point out). My
> > > reasoning is basically this:
> > >
> > > * Everyone on the Modularity Team is being paid by Red Hat to work on
> > > Modularity.
> > > * Red Hat Enterprise Linux 8 shipped with Modularity.
> > > * The Modularity Team is responsible for maintaining that in RHEL 8
> > > regardless of what happens in Fedora.
> >
> > None of the above should matter for the purpose of selecting the best
> > technical solution to the current issues, even if it means admitting
> > that Modularity as currently implemented is causing too many issues that
> > can't be fixed in reasonable time and abandoning it altogether.
> >
> > > * A full redesign in Fedora is not realistically possible with the
> > > people and resources we have available to us while also maintaining
> > > the current implementation for ten years.
> >
> > Then just drop it. SCLs are an example of a Red Hat-only solution.
> > Modularity tried to do better and failed in Fedora, so let it remain Red
> > Hat-only, too, while an even better solution is invented. Or, perhaps,
> > as various folks have been saying, maybe Fedora just doesn't need SCLs,
> > Modularity or any similar solutions. Let Red Hat cater to its corporate
> > customers and experiment with Red Hat-specific solutions in CentOS and
> > let Fedora not be constrained by what makes sense only in a LTS
> enterprise
> > distribution.
> >
> > > * Therefore we are focused on trying to get the current implementation
> > > into better shape (and/or finding a safe migration strategy to a new
> > > solution) rather than start from an entirely green field.
> >
> > If you mean "we, the Modularity team" then I can understand, but still
> > the option to just drop the whole thing from Fedora looks more appealing
> > than just wasting more time and effort on piling up technical debt.
> > Sound arguments were made against some of the stated goals of Modularity
> > like private buildroot packages and the rest can be implemented using
> > the existing tools. I fail to see what advantages Modularity has brought
> > us so far, while the disadvantages are pretty clear.
>
> I am going to disagree on several points here:
>
> 1) I don't think Modularity is about being LTS and "enterprisy".
> Lifecycle differences are not the only feature Modularity provides.
>
> I see Modularity as a tool which bridges the gap between container
> world and a packaged distribution.
>
> Without modularity we have a base system with its limitations and the
> explosion of containerized solutions which currently go through their
> teen-age phase, denying the good old known practices and reinventing
> wheels in terms of packaging, sharing, deduplication of effort and
> security audit.
>
> Modularity allows us to use packaging approaches in a more flexible
> but still controlled and maintained way. It creates building blocks
> for containerized environments.
> I think it is the way to go for Flatpacks, cloud images and other
> layered solutions to use runtimes built on top of packaged streams,
> rather than custom configurations.
>
> And I think it is in scope of Fedora to drive this process to
> normalize the currently chaotic container world.
>
> 2) I don't think Modularity is a failure in its current state.
>
> Yes, we do have a problem of default streams. There are several
> reasons for that.
>
> One thing i find interesting is that: we were very cautious on tech
> implementation side, delaying certain technical tools and solutions,
> while we were not cautious enough on the 

Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Igor Gnatenko]

Hey Nick,

Is this change about stopping any builds which do not pass annocheck
test from going to stable repository or just adding new check in
there? If latter, I don't think it qualifies as a system-wide change.

On Wed, Oct 30, 2019 at 10:05 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/ANNOBIN-used-by-bodhi
>
> = Annobin Used By Bodhi =
>
> == Summary ==
> Use the annocheck program from the annobin package to produce an
> analysis of the security hardening of a compiled package when
> reviewing a Bodhi update.
>
> == Owner ==
> * Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
> * Email: ni...@redhat.com
>
> == Detailed Description ==
> The annobin package provides two components, a plugin for gcc that
> records details about how a program was compiled and an analyser that
> uses this information to produce a report on the security hardening
> status of the compiled program.  Currently the plugin is being used as
> part of the build process for Fedora packages (when they are built
> using gcc), but the analysing program is not being run.  This proposal
> is to have the analyser (called annocheck) run when creating
> information for review by the Bodhi update process, possibly allowing
> an update to be delayed until the security issues are addressed.
>
> The analyser currently looks for the following items:
>
> *  Lazy binding must not have been enabled via the linker option "-z
> lazy".  Instead the @option{-z now} option must have been used.
>
> * The program must not have a stack in an executable region of memory.
>
> * The relocations for the GOT table must be read only.
>
> * No program segment should have all three of the read, write and
> execute permission bits set.
>
> * There should be no relocations against executable code.
>
> * The runpath information used to locate shared libraries at runtime
> must only include directories rooted at /usr.
>
> * The program must have been compiled with the
> -fstack-protector-strong option enabled, and with -D_FORTIFY_SOURCE=2
> specified.  It must also have been compiled at at least optimisation
> level 2.
>
> * Dynamic executables must have a dynamic segment.
>
> * Shared libraries must have been compiled with -fPIC or-fPIE but not -static.
>
> * Dynamic executables must have been compiled with -fPIE and linked with -pie.
>
> * Program which use exception handling must have been compiled with
> -fexceptions enabled and with -D_GLIBCXX_ASSERTIONS specified.
>
> * If available the -fstack-clash-protection must have been used.
>
> * If available the -fcf-protection=full must have been used.
>
> * For i686 binaries, the -mstackrealign option must have been specified.
>
> * The program must have been compiled with the -D_FORTIFY_SOURCE=2
> command line option specified.
>
> * The program must have been compiled with at least -O2 optimisation enabled.
>
> * The program must not have any relocations that are held in a writable 
> section.
>
> * For x86_64 binaries, check that -fcf-protection has been enabled.
>
>
> Note - I do not know *how* to add a run of the annocheck program to
> the Bodhi process.  This change request is about asking that such a
> thing be added.
>
> == Benefit to Fedora ==
>
> Establishing good security practices when building packages will help
> Fedora remain a front running Linux distribution.  By providing a way
> to review the security hardening status of packages, this update will
> help to ensure that these practices continue.
>
> Note - the intention is that if this change is successful, and useful,
> then a future change request would be made to include the security
> checking as part of the actual package build process, and to have
> packages fail to complete building if they do not pass the security
> checks.
>
> == Scope ==
> * Proposal owners:
> In theory there is very little that I can do personally.  I do not
> have the knowledge to change the Bodhi process myself, so I will have
> to rely upon someone else to do that.  I am familiar with the annobin
> package however, so any changes that are needed to it I will be happy
> to make.
>
>
> * Other developers:
> Add an invocation of the annocheck program to the Bodhi build approval
> process and make its output available to reviewers.
> Annocheck can be invoked simply as "annocheck " although
> there are a set of command line options to extend and modify its
> behaviour.  Annocheck understands the rpm file format, as well as
> shared and static libraries and executable binaries.  It can also be
> helpful to provide annocheck with access to the debug information for
> a binary or rpm, if that has been placed into a separate file.
>
>
> * Release engineering: https://pagure.io/fedora-ci/general/issue/78
>
> No mass rebuild is required.
>
> * Policies and guidelines:
> It is desirable that the packaging guidelines be updated to describe
> the security hardening features examined by annocheck.  (If they are
> not already mentioned in the 

Re: Introducing Square 1

[Igor Gnatenko]

Have you tried using https://github.com/fedora-modularity/depchase?
That basically does what you are doing and with some small changes it
can perform much more things.

On Tue, Oct 29, 2019 at 3:27 PM Troy Dawson  wrote:
>
> On Mon, Oct 28, 2019 at 2:58 PM Peter Robinson  wrote:
> >
> > On Mon, Oct 28, 2019 at 8:00 PM Troy Dawson  wrote:
> > >
> > > I would like to introduce a plan I call Square 1 [1][2]
> > >
> > > There are two goals to Square 1.
> > > The first is to get, and keep, the core buildroot[3] packages, 
> > > self-hosting[4].
> > > The second is to get the list of core buildroot packages as small as 
> > > possible.
> >
> > Why can't this be done as part of the minimisation objective? To have
> > yet another project with another name and another focus and set of
> > tools just appears to be a little bizarre
> >
>
> I'd love for it to fold into the Minimization project.
> That project has a better name, and Adam is much more familiar with
> getting things done properly in Fedora.
> Currently, the Minimization project is geared towards only binaries,
> and not the source dependencies.  It is still getting setup and on
> it's feet.  I'm worried that throwing source and dependency tree's at
> it will knock it down before Minimizations infrastructure is in place.
>
> But, I'm looking at when we need to get started for RHEL9, and I've
> seen how slow things can take when dealing with Fedora dependencies,
> and it has me concerned.  I'd like to get the discussion started now,
> so hopefully we have some things figured out and possibly working by
> the time it is needed.
>
> Is the name confusing?  Yep.  But Square1 is all I could think of at the time.
> Can/Should this be merged into Minimization?  Yes, that is my hope.
> Or, at least a good part of it get's merged in there.  Eventually.
>
> > > What are the benefits to Square 1?
> > > More stable release and less failed builds.
> > > If we are able to shrink binaries, faster koji builds.
> > > Smoother initial creation of RHEL 9.[5]
> > >
> > > What are the milestones to get these benefits?
> > > - Get initial list of "core binaries"
> > > - write/find software that will find binary/source dependencies
>
> I've been looking at the dnf plugins, specifically builddep.
> If we can get that to be recursive, that would help tremendously.
>
> Looking at the plugins, we should also be able to help the
> Minimization project get their list of packages in a usable format.
> Currently they are installing all their packages (I believe in a
> container), and then grabbing the rpm database from that.  I think we
> should be able to make a plugin that generates the list of packages
> that would be installed, and instead of installing them, generates an
> repo and/or rpm database.
>
> > > - write/find software that will track binary/source dependencies
> > > - write/find/setup automation that finds and tracks binary/source
> > > dependencies, so people can easily see what has changed over time.
> > > - work with package maintainers to trim down binary/source dependencies
> > > -- trimming out "extra" package languages.  (ex: perl for a
> > > minor script, when everything is in python.)
> > > -- trimming functionality and/or moving functionality to sub-packages
> > > or separate package.
> > > - integrate these tests into the rawhide gating system, to alert when
> > > new dependencies have been added.
> > >
> > > Much of this work overlaps with the Fedora Minimization efforts.[6]
> > > Square 1 hopes to utilize, rather than duplicate, their efforts.  And
> > > maybe some tools created for Square 1 can help the minimization
> > > efforts.
> > >
> > > Thoughts?
> > > Ideas?
> > > Comments?
> > >
> > > Troy Dawson
> > >
> > > [1] - Square 1 is at the heart of Ring Zero
> > > [2] - This has nothing to do with the company or software with a
> > > similar sounding name.
> > > [3] - The core buildroot is the packages in @buildsys-build, and
> > > everything needed to build those packages.
> > > [4] - self-hosting is the ability to build all the packages on themselves.
> > > [5] - Yep, I said it.  We're already looking at RHEL 9.
> > > [6] - https://docs.fedoraproject.org/en-US/minimization/
> ___
> 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
___
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: 

Schedule for Mondays's FESCo Meeting (2019-10-28)

[Igor Gnatenko]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2019-10-28 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =
FESCo blocker bug: Broken upgrades via libgit2
https://pagure.io/fesco/issue/2230
AGREED (+5, 1, -1), all issues were already resolved

Nonresponsive maintainer: Benjamin Pereto bpereto
https://pagure.io/fesco/issue/2242
AGREED (+2, 0, -0)

Python 2 exception for autodownloader
https://pagure.io/fesco/issue/2248
APPROVED (+6, 0, -0)

Python 2 Exception for mozjs60
https://pagure.io/fesco/issue/2249
APPROVED (+6, 0, -0)

General Python 2 exception for packages that only BR the interpreter
https://pagure.io/fesco/issue/2250
APPROVED (+6, 0, -0)

F32 Self-Contained Change: Replace Bazaar with Breezy
https://pagure.io/fesco/issue/2251
APPROVED (+5, 0, -0)

F32 System-Wide Change: Free Pascal Compiler 3.2.0
https://pagure.io/fesco/issue/2252
APPROVED (+7, 0, -0)

= New business =

#topic #2255 F32 System-Wide Change: Modules in non-Modular Buildroot
https://pagure.io/fesco/issue/2255

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
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

Re: Modularity and all the things

[Igor Gnatenko]

On Wed, Oct 23, 2019 at 7:07 PM Matthew Miller  wrote:
>
> On Wed, Oct 23, 2019 at 12:44:06PM -0400, Randy Barlow wrote:
> > On Wed, 2019-10-23 at 14:41 +0200, Petr Šabata wrote:
> > > We currently don’t have any other proposal that would fulfill the vision
> > > of our Objective and the needs of our users.
> > How do the proposals I've mentioned not fulfill the goals?
>
> Are you proposing to _do_ those things, or proposing that someone else
> oughta?

I agree with Lukas that this is unfair. As we talked on the Flock,
that means only people working @ RH can do such things since they have
dedicated time.

But I would definitely like to do some work in this regard, however, I
can't find full list of things we would like to achieve.

* Do we want to support "buildroot-only" packages?
* Do we want to build streams against all combinations (aka
py{2,3}+nodejs{8,9,10}+fedora{30,31,32} would result into 18 builds of
a packages)?

Those are just few points where I don't know answer. But if you can
provide list of all things we would like to achieve, I can definitely
come up with some proposal.

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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
___
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

Re: Modularity and all the things

[Igor Gnatenko]

Hey Petr,

First of all, thanks for writing this up, much appreciated.

On Wed, Oct 23, 2019 at 2:52 PM Petr Šabata  wrote:
>
> Starting a new thread since the old one is hard to navigate at this point.
>
> Modularity is a distribution-level change and requires some mindset
> shift from packagers and users alike. I understand the concerns some
> people have, feeling it’s something new and half-baked that is being
> forced on them.

I entirely agree with you here. Though I'm not sure if "requires
mindset shift" is good.

> We’re an open source community and in order to drive innovation, we
> need to be able to try new approaches and technologies in the open,
> not develop them without any input and hands-on experience behind
> closed doors, later serving them on a silver plate. The feedback we’re
> getting is extremely valuable, but some of it is too narrowly focused
> on one specific problem area and not taking into account the other
> aspects, requirements, or goals that we’re pursuing. Our objective is
> still to deliver multiple versions, or variants, of our content across
> releases or even distributions (think EPEL or CentOS). And it’s a good
> one.
>
> The concept of default streams was introduced to make modularity
> invisible to anyone who has no interest in alternatives and wants the
> system to operate as it historically has. Whether a specific package
> is delivered via a module or not shouldn’t matter. (This does not mean
> it should be hidden, just that it should have no practical difference
> to the system.) This applies to both buildroots and runtime, leaving
> the choice of whether to modularize or not to the maintainer.
> Obviously, the implementation is falling short in this regard right
> now, but we have solutions in development or under design. This
> includes making the default streams available in the non-modular
> buildroot via Ursa Prime or tracking the module enablement intent in
> our software management stack, as Stephen suggested in the original
> post.
>
> While these issues are being resolved, we are considering temporarily
> disallowing default streams in Fedora. I don’t want to abandon the
> idea completely, as doing so reduces the motivation to actually build
> modules and reap the benefits they might provide.

This basically makes modularity not useful for many things:

1. People will have to have different workflows between "default"
version (standard workflow, as we have today) and "modular" version.
Also that means, on the distribution upgrade maintainers will have to
do many things to remove modular stream, add old one and upgrade
non-modular version. This is also not only about maintainers, but end
users too:

FXX: fish 3.x is non-modular, stream 4.x exists
FXX+1: fish 4.x is non-modular, stream 3.x exists

* If user wants to stay on 3.x, he needs to enable stream explicitly
*after* upgrade and then downgrade the package (which is actually
unsupported).
* If user wants to stay on 4.x, he needs to enable stream explicitly
during FXX (which is totally fine), but after upgrade he has to
explicitly disable it.

Obviously you can have 3.x stream for FXX and 4.x for FXX+1, but that means:

* Maintainer has to maintain that version *twice* (modular and
non-modular version)
* Nobody can guarantee that those will be compatible

2. In Rust we use modularity to build bunch of packages, filter
buildroot-only packages and ship only one user-facing RPM. If we
remove default stream, people won't be ever able to do `dnf install
ripgrep'. This is worst UX we can provide.

> Yes, modularity still has some additional development ahead. We need
> to improve the software management stack experience; we need to
> revisit our release engineering SOPs; we need to stabilize and boost
> performance of our infrastructure; and last but not least, we need to
> improve the packager experience, providing more features to make the
> creation of modules easier, as well as guidance, best practices and
> policies that make it easy to collaborate. These changes are similar
> to those for other useful but disruptive technologies that Fedora has
> successfully introduced in the past.

I think problems with modularity is not about packager experience or
some missing features (e.g. I'm waiting for some features for 1+
years, but that's not crucial). The problem is that we don't have
well-defined *user* experience.

Do you think you will be able to come up with some exhaustive
documentation how installation/upgrades/downgrades/switches/whatnot
should look like in modularity? I would imagine you need at least 70
"test-cases" for simple things.

> I do believe we all intend the best, even if we sometimes disagree. We
> currently don’t have any other proposal that would fulfill the vision
> of our Objective and the needs of our users. The input here helps us
> re-focus on the most acute pain points but the manpower and control we
> have is also rather limited. If you want to and can help with the
> 

[EPEL-devel] Re: HEADS UP: epel-rpm-macros now makes python mangling shebangs to python3.6

[Igor Gnatenko]

No need to apologize, noone ever can know all possible problems in advance.

On Mon, Oct 21, 2019, 19:41 Stephen John Smoogen  wrote:

> On Mon, 21 Oct 2019 at 12:59, Igor Gnatenko
>  wrote:
> >
> > Hello EPEL maintainers and users,
> >
> > I've found today that epel8 builds are mangling python shebangs to
> > platform-python (which is somewhat internal implementation of python
> > for internal RHEL needs). So depending on that is quite problematic
> > and will break at some point.
> >
> > + PYTHON3=/usr/libexec/platform-python
> > + /usr/lib/rpm/redhat/brp-mangle-shebangs
> > mangling shebang in /usr/local/bin/attach_volume.py from
> > /usr/bin/python3 to #!/usr/libexec/platform-python
> >
> > After changes, it will mangle it to the /usr/bin/python3.6
> >
> > Thanks to Miro Hrončok for working with me and now we have a fix which
> > is awaiting for karma in bodhi[0]. Please give it a try.
> >
> > [0] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b4e9aea40d
>
> Whoops. I apologize for not catching this earlier.
>
>
> > --
> > -Igor Gnatenko
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

[EPEL-devel] HEADS UP: epel-rpm-macros now makes python mangling shebangs to python3.6

[Igor Gnatenko]

Hello EPEL maintainers and users,

I've found today that epel8 builds are mangling python shebangs to
platform-python (which is somewhat internal implementation of python
for internal RHEL needs). So depending on that is quite problematic
and will break at some point.

+ PYTHON3=/usr/libexec/platform-python
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
mangling shebang in /usr/local/bin/attach_volume.py from
/usr/bin/python3 to #!/usr/libexec/platform-python

After changes, it will mangle it to the /usr/bin/python3.6

Thanks to Miro Hrončok for working with me and now we have a fix which
is awaiting for karma in bodhi[0]. Please give it a try.

[0] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b4e9aea40d
-- 
-Igor Gnatenko
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Unresponsive maintainer: smooge Fwd: [Bug 1451148] libmaxminddb-1.3.2 is available

[Igor Gnatenko]

Feel free to assign it to me and I'll try to make an update to it as
soon as possible.

On Sun, Oct 20, 2019, 16:47 Stephen John Smoogen  wrote:

> So I am declaring myself an unresponsive maintainer on the
> libmaxminddb and would like someone else to take this package.
>
> libmaxminddb is part of the replacement of the GeopIP packages to work
> with their new database. I took the package because it was orphaned
> and at the time I figured I could pick this up.
>
> I have not been able to and I am not sure I could make updates to 1.32
> in anything other than rawhide now. If anyone knows this package and
> would like to take it over.. please contact me and I will add you to
> the list. If not I plan to orphan the package after F31 is released.
>
> -- Forwarded message -
> From: 
> Date: Sat, 25 May 2019 at 02:01
> Subject: [Bug 1451148] libmaxminddb-1.3.2 is available
> To: 
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1451148
>
> Peter Borsa  changed:
>
>What|Removed |Added
>
> 
>  CC||peter.bo...@gmail.com
>
>
>
> --- Comment #4 from Peter Borsa  ---
> Any update?
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
>
>
> --
> Stephen J Smoogen.
> ___
> 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
>
___
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

Re: [Mindshare] Re: [Ambassadors] FOSDEM

[Igor Gnatenko]

I'll happy to help with that. Where do I start?

On Sun, Oct 20, 2019, 11:32 Brian (bex) Exelbierd 
wrote:

>
>
> On Fri, Oct 18, 2019 at 3:37 PM Aleksandra Fedorova 
> wrote:
>
>> On Fri, Oct 18, 2019 at 2:37 PM Aniket Pradhan
>>  wrote:
>> >
>> > Hello Ankur, Matthew and Brian!
>> >
>> > > > > Is there anyone interested in owning this?  If so, can you put
>> together a
>> > > > > proposal for Mindshare?
>> >
>> > > They have a research track this year, so it'll be great to get some
>> > > NeuroFedora presence there.
>> >
>> > I would love to represent Fedora and Neuro-Fedora at FOSDEM this year.
>> > Although I have no prior experience of "owning" up a booth, so am
>> > unsure what my responsibilities would be.
>>
>> +1 here
>>
>> I will be at FOSDEM and I am willing to spend most of my time at the
>> booth as usual.
>> But it is going to be hard for me to deal with swag for example, as I
>> don't see myself carrying the box of t-shirts to Brussels by train.
>
>
> Don’t worry about physically transporting the swag to Brussels. I’ll take
> care of that. We will most likely do a shard swag object again and sipplemt
> it with small stuff.
>
> Booth ownership involves messaging (important!) and logistics like
> staffing and hotel rooms (usually coordinated with my help).
>
> Regards,
>
> bex
>
>
>
>>
>> > If you could elaborate a bit
>> > more about it, I would be happy to submit a proposal for the same on
>> > Mindshare. If anyone else would be leading, I would be happy to help
>> > as well. :D
>>
>> --
>> Aleksandra Fedorova
>> bookwar
>> ___
>> 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
>>
> --
> Brian "bex" Exelbierd (he/him/his)
> Fedora Community Action & Impact Coordinator
> @bexelbie | http://www.winglemeyer.org
> bexel...@redhat.com | b...@pobox.com
> ___
> 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
>
___
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

Re: FOSDEM

[Igor Gnatenko]

I'm happy to help. Also I can get swag from Brno (though the flight
ticket might be more expensive).

I was there last year so I still remember how to do it more or less :)

On Wed, Oct 16, 2019 at 6:32 PM Brian (bex) Exelbierd
 wrote:
>
> Hi All,
>
> I haven't heard anyone mention FOSDEM yet.  Booth applications are due soon 
> and I'd like to see us coordinate again with our friends in CentOS.  Is there 
> anyone interested in owning this?  If so, can you put together a proposal for 
> Mindshare?
>
> regards,
>
> bex
> --
> Brian "bex" Exelbierd (he/him/his)
> Fedora Community Action & Impact Coordinator
> @bexelbie | http://www.winglemeyer.org
> bexel...@redhat.com | b...@pobox.com
> ___
> 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
___
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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Igor Gnatenko]

On Thu, Oct 10, 2019 at 12:52 AM Miro Hrončok  wrote:
>
> On 09. 10. 19 22:46, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
> >
> > Enable module default streams in the buildroot repository for modular
> > and non-modular RPMs.
> >
> > == Summary ==
> > This Change (colloquially referred to as "Ursa Prime") enables the
> > Koji build-system to include the RPM artifacts provided by module
> > default streams in the buildroot when building non-modular (or
> > "traditional") RPMs.
> >
> > == Owner ==
> > * Name: [[User:Sgallagh| Stephen Gallagher]]
> > * Email: sgall...@redhat.com
> > * Responsible WG: Modularity WG
> >
> > == Detailed Description ==
> > As a major part of the Modularity design, we have a concept of default
> > module streams. These streams are built as modules, but the RPM
> > artifacts they deliver are intended to be used just like non-modular
> > RPMS. The aspirational goal is that a user of the system who never
> > executes a module-specific command (such as `dnf module install
> > nodejs:8`) should experience no meaningful changes in behavior from
> > how they would interact with a completely non-modular system. In
> > practice, this may mean that the informational output of package
> > managers may indicate that modules are being enabled and used, but a
> > user that does not have a specific reason to interact with the
> > selection of a module stream should have that managed on their behalf.
>
> If this is the goal of default modular streams, wouldn't it be in fact much
> easier to keep the default versions as urisne packages?

That means, you have 2 different workflows: for default version and
for an additional one.
When branching happens, instead of just updating one file which points
to the new default, you would have to create new stream, retire the
one which is about to become default and update package in
non-modular.

> > Similarly, the experience for package maintainers of non-modular
> > packages should be unaffected by an RPM dependency moving from the
> > non-modular repository into a default module stream. Up to the
> > present, this has not been the case; no module stream content has been
> > available in the non-modular buildroot for other packages to consume.
> > Koji builds of non-modular RPMs have had only the other non-modular
> > RPMs from that release available to their buildroots. In contrast,
> > building on local systems has access to both the non-modular RPMs and
> > the RPMs from any of the default module streams. With this Change,
> > Koji builds will have the same behavior and be able to depend on
> > content provided by default module streams. It also enables the same
> > behavior for Modular builds: the `platform` stream will now include
> > the contents of the default module streams for each release and do not
> > need to be explicitly specified in the modulemd `buildrequires`.
>
> What I miss in the description is:
>
> 1. How does this thing actually work? is there an additional repository 
> composed
> from the default streams available in Koji only?
>
> 2. How are conflicts between packages from the default streams and ursine
> package be handled?
>
> 3. What is the local experience if the packager is using mock. What if they 
> are
> using rpmbuild directly?
>
> 4. How are we handling default streams with dependencies on non-default 
> streams
> of other modules?
>
> > ...
> > == Scope ==
> > * Proposal owners:
> > # Update Packaging Guidelines with
> > [https://pagure.io/modularity/issue/146#comment-600328 requirements]
> > for module default streams
> > # Create a Pungi configuration to generate the buildroot from the
> > default module streams.
> > # Include `default_modules_scm_url` in the platform virtual module 
> > specification
> > # Configure Koji tags for inheriting the new modular-defaults
> > buildroot into the standard buildroot
> >
> > * Other developers:
> >
> > Packagers of default module streams will be required to conform to the
> > [https://pagure.io/modularity/issue/146#comment-600328 policy]
> > regarding visibility of stream artifacts. Any default module stream
> > that is not in compliance by one week before Beta Freeze will cease to
> > be a default stream.
>
> What are the packagers of ursine packages that are shadowed by their modular
> counterparts supposed to do here (assuming such shadowing happens)?
>
> What are the packagers of modular packages that are shadowed by their ursine
> counterparts supposed to do here (assuming such shadowing happens)?
>
> > ...
> > == How To Test ==
> > # Build a modular stream
> > # Make that stream a default stream (or a buildroot override)
> > # Build a non-modular RPM that requires an artifact RPM from the modular 
> > stream.
>
> How can I test this as an ursine package maintainer assuming I have build
> dependencies that were ursine packages but now will be form modules?
>
> > ...
> > == Contingency Plan ==
> > * Contingency mechanism: 

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Igor Gnatenko]

> https://pagure.io/releng/issue/8880 - Include default_modules_scm_url in 
> platform 31 virtual module

platform *f32*?

Other than that, it would be nice to have more specific rules *when*
and *how* modules are checked to conform to the guidelines…


On Wed, Oct 9, 2019 at 10:51 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
>
> Enable module default streams in the buildroot repository for modular
> and non-modular RPMs.
>
> == Summary ==
> This Change (colloquially referred to as "Ursa Prime") enables the
> Koji build-system to include the RPM artifacts provided by module
> default streams in the buildroot when building non-modular (or
> "traditional") RPMs.
>
> == Owner ==
> * Name: [[User:Sgallagh| Stephen Gallagher]]
> * Email: sgall...@redhat.com
> * Responsible WG: Modularity WG
>
> == Detailed Description ==
> As a major part of the Modularity design, we have a concept of default
> module streams. These streams are built as modules, but the RPM
> artifacts they deliver are intended to be used just like non-modular
> RPMS. The aspirational goal is that a user of the system who never
> executes a module-specific command (such as `dnf module install
> nodejs:8`) should experience no meaningful changes in behavior from
> how they would interact with a completely non-modular system. In
> practice, this may mean that the informational output of package
> managers may indicate that modules are being enabled and used, but a
> user that does not have a specific reason to interact with the
> selection of a module stream should have that managed on their behalf.
>
> Similarly, the experience for package maintainers of non-modular
> packages should be unaffected by an RPM dependency moving from the
> non-modular repository into a default module stream. Up to the
> present, this has not been the case; no module stream content has been
> available in the non-modular buildroot for other packages to consume.
> Koji builds of non-modular RPMs have had only the other non-modular
> RPMs from that release available to their buildroots. In contrast,
> building on local systems has access to both the non-modular RPMs and
> the RPMs from any of the default module streams. With this Change,
> Koji builds will have the same behavior and be able to depend on
> content provided by default module streams. It also enables the same
> behavior for Modular builds: the `platform` stream will now include
> the contents of the default module streams for each release and do not
> need to be explicitly specified in the modulemd `buildrequires`.
>
> Note: This Change does not address the other major Modularity issue we
> are facing around distribution upgrades with differing default
> streams. When discussing this Change, please keep that topic separate.
>
> == Benefit to Fedora ==
>
> This will simplify the lives of package maintainers in Fedora in two
> primary ways. I'll use a hypothetical example of the Node.js
> interpreter and a JSApp package which is capable of running on Node.js
> 10 or 12 (but requires newer features than are provided by Node.js 8).
> Additionally, the JSApp package requires the same versions of Node.js
> at build-time.
>
> * Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
> streams. The `nodejs:10` stream is set as the default stream.
> * Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
> streams. The `nodejs:10` stream is set as the default stream.
> * Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
> `nodejs:12` stream is set as the default stream. The `nodejs:14`
> stream will likely become available during the F31 lifetime.
> * Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
> `nodejs:12` stream is set as the default stream. The `nodejs:14`
> stream will likely become available during the F32 lifetime.
>
> On Fedora 29 through 31, the Node.js package maintainer needs to build
> the `nodejs:10` package both as a module and as a non-modular RPM in
> the distribution so that the JSApp package can be built. With this
> Change, the Node.js package maintainer in Fedora 32+ will only need to
> build the various Node.js streams and make one of them the default
> stream. The packages from it will then be added to the buildroot for
> non-modular packages. This will also make the packaging process
> somewhat more efficient, as the maintainer needs only to manage the
> module stream and the MBS will build it for all configured platforms.
>
> Similarly, from the perspective of dependent maintainers, there will
> no longer be anxiety about needing to move their package to a module
> if one or more of their dependencies drops their non-modular version
> in favor of a default stream. Their builds will continue to work as
> they do today.
>
> == Scope ==
> * Proposal owners:
> # Update Packaging Guidelines with
> [https://pagure.io/modularity/issue/146#comment-600328 requirements]
> for module default streams

Re: Minimization Objective report

[Igor Gnatenko]

On Wed, Sep 25, 2019 at 6:01 PM Adam Samalik  wrote:
>
> This is the Minimization Objective [0] update.
>
> Status: Discovery phase
>
> == Regular meeting canceled ==
>
> We have decided to cancel the regular Minimization Team Meeting [1] as we 
> prefer async discussions on #fedora-devel and de...@lists.fp.o. This makes it 
> more inclusive to people with other commitments or being in timezones that 
> prevent them attending the meeting at that specific time.
>
> == systemd-sysusers vs. containers ==
>
> We don't want Systemd in containers [2], but we recognise this is a 
> container-specific problem. So we're asking other groups — Containers SIG and 
> people working with OpenShift — for how they're approaching this problem.
>
> == Feedback Pipeline ==
>
> Feedback Pipeline [3] is now automated, refreshing every day.
>
> It also now includes sizes of individual packages in all reports, as well as 
> a timestamp.
>
> == pcre -> pcre2 ==
>
> Moving grep (one of the last packages using pcre) to pcre2. [4]

I'm curious if we should simply replace grep by ripgrep :)

> == How to get involved ==
>
> See if there is anything interesting to you on action plan [42], or reach
> out with something you think is useful but is missing there. Open a ticket
> in the tracker [43] or discuss in #fedora-devel on IRC.
>
> Cheers,
> Adam
>
>
> [0] Objective: https://docs.fedoraproject.org/en-US/minimization/
> [1] Meeting canceled: https://pagure.io/minimization/issue/14
> [2] systemd-sysusers vs. containers: https://pagure.io/minimization/issue/13
> [3] Feedback Pipeline: https://minimization.github.io/reports/
> [4] switching grep to pcre2: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1755491
> [42] Action plan: 
> https://docs.fedoraproject.org/en-US/minimization/action-plan/
> [43] Issue tracker: https://pagure.io/minimization/issues
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
> ___
> 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
___
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

Re: Major update to LLVM appearing in F31 without any communication, appears to violate update policy

[Igor Gnatenko]

Well, we have updated LLVM to next major version even before
mid-cycle. Since it is important for graphics stack. Compatibility
package was always created. On the other hand, it requires proper
coordination with other package maintainers.

tl;dr I think it is fine to do rebase before F31 Final, but it should
have been communicated properly and not just building package and
submitting update/override.

On Thu, Sep 26, 2019 at 8:11 PM Adam Williamson
 wrote:
>
> We are currently in the "Beta to Pre Release" phase of the release
> cycle. The updates policy for this phase -
> https://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release -
> says:
>
> "From this point onwards maintainers MUST[1]:
>
> Avoid Major version updates, ABI breakage or API changes if at all
> possible."
>
> However, it seems a major new release of LLVM is appearing in F31 at
> present, and AFAIK there has been no discussion or communication about
> this at all.
>
> LLVM 9 is currently in the buildroot, and an update with a very short
> description has been submitted:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-b83bd6b46c
>
> (it just says "Update for LLVM 9 rebase.", which is odd since it *is*
> the LLVM 9 rebase).
>
> There is no Change for this, I can't find a mail about it anywhere,
> it's just been sort of dumped in. Is there enough grounds for dumping
> in a major new LLVM and violating the update policy at this point in
> the F31 release?
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> 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
___
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

Re: Fedora 32 Self-Contained Change proposal: Better Thermal Management for the Workstation

[Igor Gnatenko]

On Mon, Sep 23, 2019 at 4:22 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/ThermalManagementWS
>
> == Summary ==
> Better thermal management and peak performance on Intel CPUs by
> including thermald in the default install.
>
> == Owner ==
> * Name: [[User:benzea| Benjamin Berg]]
> * Email: bb...@redhat.com
>
> * Name: [[User:ckellner| Christian J. Kellner]]
> * Email: ckell...@redhat.com
> * Product: Workstation
> * Responsible WG: Workstation
>
> == Detailed Description ==
>
> Modern Intel-based systems provide sensors and methods to monitor and
> control temperature of its CPUs. The Thermal daemon will use those
> sensors to monitor the temperature and use the best available method
> to keep the CPU in the right temperature envelop. On certain systems
> this is needed to reach the maximal performance. For optimal
> performance a per-model thermald configuration should be created, this
> can either be done by using dptfxtract (available from rpmfusion) or
> we could ship static configuration files for a set of known models.

So what are we going to do about this in F32? Are we going to create
configuration files or we will provide some page how to create it
yourself? Does Intel provide one?

> For a more details explanation please consult Intel's
> [https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon
> introduction] to thermald.
>
> == Benefit to Fedora ==
>
> Better out-of-the-box experience due to improved cooling methods and
> performance on Intel systems.
>
> == Scope ==
> * Proposal owners:
>  - Include the thermald package in the default Workstation install
>  - Optionally provide patches for thermald to be able to read hardware
> specific configuration data
>  - Optionally collect hardware specific configuration data and ship it
>
> * Other developers: N/A (not a System Wide Change)
> * Release engineering:
> * Policies and guidelines: N/A (not a System Wide Change)
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> N/A (not a System Wide Change)
>
> == How To Test ==
>
> Install the packages and use e.g. turbostat to monitor the
> performance. Improvements may only be visible if the non-free
> dptfxtract package is also installed.

So what is the point of a change if improvements are visible only if
non-free package is installed?

> == User Experience ==
>  - Better performance on certain hardware
>  - Better cooling of CPUs on certain hardware
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org
___
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

HEADS UP: License change for rust-adler32

[Igor Gnatenko]

Since 1.0.4 it is lizensed under "Zlib" while previously it was "BSD and Zlib".
___
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

Re: f32/rawhide, nothing provides module(platform:f31)

[Igor Gnatenko]

Well,

Whatever you set in the defaults, DNF ignores that on the update.

https://pagure.io/releng/fedora-module-defaults/blob/master/f/libgit2.yaml
https://pagure.io/releng/fedora-module-defaults/blob/f31/f/libgit2.yaml

On Mon, Sep 2, 2019 at 9:08 AM Miroslav Suchý  wrote:
>
> Dne 30. 08. 19 v 18:25 Adam Williamson napsal(a):
> > Not. If you're getting it on an installed system that you're upgrading,
>
> Yes.
>
> > you probably need to manually switch the libgit2 module from the 0.27
> > stream to the 0.28 stream, that should clear it up.
>
> No. 0.27 is the platform default on F30. If the default should be different 
> on F31 then maintainer (cc igor), through
> rel-eng, should change it:
>   
> https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-defaults/
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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

Is Modularity (MBS) dead?

[Igor Gnatenko]

Hello,

Being one of the biggest users of Modularity (more than 25 modules)
I'm surprised that:

1) Many builds are stuck for more than half a month
(https://mbs.fedoraproject.org/module-build-service/1/module-builds/5639,
13 Aug)
2) F32 branching was not handled well, basically all Rust modules
can't be built due to wrong way of branching
(https://pagure.io/releng/issue/8718)
3) New modules (even which contain just one component) don't start
even after 30 minutes
(https://mbs.fedoraproject.org/module-build-service/1/module-builds/6151)

So did I miss some announcement that Modularity is RIP and nobody
should use it or just nobody cares about it and I should find more
reliable way to deliver Rust apps?
-- 
-Igor Gnatenko
___
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

Re: Fedora Workstation and disabled by default firewall

[Igor Gnatenko]

Red Hat is written as two separate words. So you can put some work
into learning that :)

Anyhow, why does user need to learn what port is? Can you imagine your
grandma / grandfather learning how to open some port on the firewall?

On Tue, Aug 27, 2019 at 3:05 PM Dan Book  wrote:
>
> On Tue, Aug 27, 2019 at 8:10 AM  wrote:
>>
>> On Tue, Aug 27, 2019 at 4:22 AM, John Harris  wrote:
>>
>> No, that is not how this works, at all. First, let's go ahead and address 
>> the idea that "if the firewall blocks it, the app breaks, so it's the 
>> firewall's fault": It's not. If the firewall has not been opened, that just 
>> means it can't be accessed by remote systems until you EXPLICITLY open that 
>> port, with the correct protocol, on your firewall. That's FINE. That's how 
>> it's designed to work. There's nothing wrong with that. This means that the 
>> system administrator (or owner, if this is some individual's personal 
>> system) must allow the port to be accessed remotely, before the app can be 
>> reached remotely, increasing the security of the system.
>>
>>
>> You've already lost me here. Sorry, but we do not and will not install a 
>> firewall GUI that exposes complex technical details like port numbers. 
>> Expecting users to edit firewall rules to use their apps is ridiculous and 
>> I'm not really interested in debating it.
>>
>> If the user is capable of editing firewall rules and wants to do so, that 
>> user can surely also change the policy to not open all these ports. Yes?
>
>
> That Gnome is intentionally sabotaging users and thinks they are too stupid 
> to understand a port number associated with a service is just another example 
> why I wish that Fedora and Redhat would put work into alternative desktops.
>
> -Dan
> ___
> 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
___
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

Re: Koschei branching?

[Igor Gnatenko]

Hi Nico,

you can check it here: https://apps.fedoraproject.org/koschei/

You can see Fedora Rawhide, Fedora 30, Fedora 29 and EPEL7, but there
is no Fedora 31 which kinda indicates that Koschei has not been
updated yet.

On Mon, Aug 26, 2019 at 3:31 AM Nico Kadel-Garcia  wrote:
>
> On Sun, Aug 25, 2019 at 8:33 AM Igor Gnatenko
>  wrote:
> >
> > I see that there is no Fedora 31. Is anybody working on creating that
> > and moving rawhide forward to 32?
>
> I think you need to take a look at the current Fedora repositories,
> you'll find fedora 31 packages and find that the rawhide package are
> labeled "fc32".
> _
> ___
> 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
___
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

Re: gnustep-base 1.26.0

[Igor Gnatenko]

Not `unrar`, but `unar` :)

On Sun, Aug 25, 2019 at 2:38 PM Antonio Trande  wrote:
>
> 'unrar' is a RPMFusion package.
>
> On 25/08/19 14:16, Igor Gnatenko wrote:
> > gnustep-base-libs-1.25.0-14.fc31.x86_64
> > openvpn-auth-ldap-2.0.3-28.fc31.x86_64
> > libgnustep-base.so.1.25()(64bit)
> >  raidem-0.3.1-39.fc31.x86_64
> >  libgnustep-base.so.1.25()(64bit)
> >  unar-1.10.1-12.fc31.x86_64
> >  libgnustep-base.so.1.25()(64bit)
> >
> > You'd need to rebuild unar too.
> >
> > On Sun, Aug 25, 2019 at 1:01 PM Antonio Trande  
> > wrote:
> >>
> >> Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=37267892
> >>
> >> On 25/08/19 12:38, Antonio Trande wrote:
> >>> Hi all.
> >>>
> >>> 'gnustep-base' package will be pushed on Rawhide in 10 days.
> >>>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x6e0331dd1699e4d7
> GPG key server: https://keys.openpgp.org/
>
___
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

Koschei branching?

[Igor Gnatenko]

I see that there is no Fedora 31. Is anybody working on creating that
and moving rawhide forward to 32?
___
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

Re: gnustep-base 1.26.0

[Igor Gnatenko]

gnustep-base-libs-1.25.0-14.fc31.x86_64
openvpn-auth-ldap-2.0.3-28.fc31.x86_64
libgnustep-base.so.1.25()(64bit)
 raidem-0.3.1-39.fc31.x86_64
 libgnustep-base.so.1.25()(64bit)
 unar-1.10.1-12.fc31.x86_64
 libgnustep-base.so.1.25()(64bit)

You'd need to rebuild unar too.

On Sun, Aug 25, 2019 at 1:01 PM Antonio Trande  wrote:
>
> Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=37267892
>
> On 25/08/19 12:38, Antonio Trande wrote:
> > Hi all.
> >
> > 'gnustep-base' package will be pushed on Rawhide in 10 days.
> >
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x6e0331dd1699e4d7
> GPG key server: https://keys.openpgp.org/
>
> ___
> 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
___
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

Re: Requesting F31 branches

[Igor Gnatenko]

I think Gwyn needs to update fedscm-admin.

On Wed, Aug 14, 2019, 17:52 Robert-André Mauchin  wrote:

> Hello,
>
> What does this error means when requesting F31 branches:
>
> > Invalid body, keys: sls missing
>
> https://pagure.io/releng/fedora-scm-requests/issue/15093
>
> This is cryptic, can anyone explain what is the issue?
>
> Best regards,
>
> Robert-André
>
> ___
> 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
>
___
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

RFC: Drop lz4-static

[Igor Gnatenko]

Hello,

I found out that nothing in Fedora depends on lz4-static (neither
runtime nor buildtime). Is anybody using it or I'm free to drop it?

Any thoughts?
___
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

RANT: compton-ng…

[Igor Gnatenko]

https://bugzilla.redhat.com/show_bug.cgi?id=1738293

How did it pass review?

> Obsoletes:  compton

Silently doing Obsoletes of an active package and doing so even
without version which is prohibited by the Packaging Guidelines.
Really?

> cp -a yshui-%{appname}-%{test_shortcommit}/subprojects/test.h 
> /builddir/build/BUILD/%{appname}-%{version}/subprojects/

I am not sure if it is written anywhere, but hardcoding
/builddir/whatsoever is so bad…

> %meson --buildtype=release

There is specific reason why we have --buildtype=plain in %meson
macro, because with release buildtype, debuginfo is unusable…

> # Enable LTO
> %global optflags%{optflags} -flto=$(nproc)
> %global build_ldflags   %{build_ldflags} -flto

Have anybody ever talked to the RPM folks about proper way of enabling
LTO for builds? This specific way of setting it makes build
non-reproducible.
___
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

Re: License correction in teckit-2.5.9-2.fc31

[Igor Gnatenko]

This is horrifying :) Curious how much time it took to figure that out..

On Mon, Aug 12, 2019, 14:21 Petr Pisar  wrote:

> After unretiring teckit I reviewed the sources and corrected a license
> tag from
>
> LGPLv2+ or CPL
>
> to
>
> (LGPLv2+ or CPL) and (LGPLv2+ or GPLv2+ or MPLv2.0 or MPLv1.1)
>
> -- Petr
> ___
> 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
>
___
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