Re: [RFC] Switching to SPDX in license tags

[Neal Gompa]

On Thu, Jul 9, 2015 at 8:08 AM, Josh Boyer 
wrote:

> On Thu, Jul 9, 2015 at 8:03 AM, Haïkel  wrote:
> > Hi,
> >
> > I would like to get feedback from Fedora Legal and also my fellow
> > contributors about considering
> > SPDX.
> >
> > SPDX (Software Package Data Exchange) is a specification hosted by the
> > Linux Foundation defining
> > a standard format for communicating components, licenses and
> > copyrights associated with a software package.
> > https://spdx.org/
> >
> > It would make it much easier collaborating with other distributions
> > and upstream projects.
> >
> > On a more practical side, it would mean standardizing on SPDX short
> > identifier to design licenses
> > and exceptions in all our packages.
> > https://spdx.org/spdx-license-list
> >
> > Your feedback?
>
> Can you elaborate on how you envision this working?  SPDX appears to
> work best when upstream projects integrate it and maintain it
> themselves.  Doing that downstream is possible, but it sounds both
> time consuming and easy to get wrong or stale.
>
> josh
>
>
​I certainly wouldn't mind standardizing our License tags against this, as
one of the distributions I am making packages for in my day job that uses
RPM already uses this format. But like Josh said, a good part of what SPDX
is about is getting projects themselves to communicate copyright and
licensing in this form. I think it's infeasible to expect that. The extent
of what we can do is provide useful information within the package that is
somewhat SPDX compliant.

I don't know if the nature of Linux distributions even would allow to make
it fully compliant.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: RPM Weak Dependencies and the install media compose process

[Neal Gompa]

On Fri, Jul 10, 2015 at 8:05 AM, Stephen Gallagher 
wrote:

>
> From my perspective, there are three ways that we could choose to go:
>
> 1) Follow the default DNF behavior: Requires: and Recommends: packages
> are included on the install media (and therefore also installed
> together onto the target system)
>
>
​I think this option makes the most sense, as it captures the current
behavior of DNF into the composition process. I honestly do not believe it
would make sense to allow the default behavior to differ from DNF,
especially as the vast majority of composes now are live images, making it
basically impossible to customize pre-install.​



> 2) Include *all* dependencies - Requires, Recommends and Suggests - on
> the install media. The installer would still follow DNF defaults, so
> the target system would get only the Requires and Recommends packages
> unless the Suggests: packages are explicitly selected (which will also
> require the creation of additional comps.xml changes to include the
> Suggests packages)
>
>
​While I appreciate the idea for completeness, I do not think this would go
over well as we update our packages to actually utilize weak dependencies
efficiently. However, I would be in favor of a kickstart parameter that
could switch on and off the inclusion of recommended and suggested packages
in a compose.

For example, in the %packages section, "--no_recommended_packages" and
"--add_suggested_packages" switches could be handy to alter the default
behavior to whatever a composer would want.



> 3) Include only Requires: dependencies by default and require spin
> -kickstarts owners to explicitly add any Recommends or Suggests
> packages that they also want to include. Packages added explicitly will
> be installed as described in 2) (requiring additional comps.xml changes
> to include Suggests stuff)
>
>
This is absolutely foolhardy, as we are fully deviating from ​how DNF
behaves and enshrining the hacks with comps that we simply do not need
anymore.
​


>
> Note that at the moment, DNF itself does not have a configuration
> option to tweak the default install behavior, so 'dnf install'
> effectively treats Recommends the same way as Requires (but 'dnf
> remove' will treat them differently, of course). I discussed this with
> the DNF developers this morning and they hope to have a configuration
> option and/or command-line argument available to change this behavior
> before Beta Freeze, so we should still be able to ship F23 with any of
> the above options.
>
>
​Excellent!​



> I think the best time to make these decisions is now, well in advance
> of the Alpha Freeze so we have time to make adjustments as needed.
> Thank you for reading to the end, I know the above has been a wall-o'
> -text.
>

​I completely agree, as the earlier we can decide on these things, the
better we'll all be. Thank you for bringing it up!



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is %autosetup another unwanted baby of Fedora?

[Neal Gompa]

x27;re trying to
make it easier for people to learn our system and use it well. And things
like horribly written packages come out of inadequate documentation and
lack of mentorship. The latter is a people problem that's difficult to
solve, but the former is much more easily solved once we actually know
*what* RPM can do and how to illustrate it.


-- 
Neal Gompa (FAS: ngompa)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Drop comps

[Neal Gompa]

On Tue, Jul 14, 2015 at 4:13 AM, Vít Ondruch  wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Can we just drop comps entirely (or at least trim them down
> significantly)? I know that this will not happen from day to day, but I see
> the comps just as an ugly workaround for missing weak dependencies, which
> we have now.
>
>
> Vít
>
>
>
>
> Dne 10.7.2015 v 14:05 Stephen Gallagher napsal(a):
> > (Please keep the conversation on the devel list; I'm CCing it the rel
> > -eng list to make sure all the relevant people see the initial message)
> >
> > This past week, the Fedora Packaging Committee approved the use of
> > "weak dependencies" in Fedora. What this means is that RPM packages can
> > now have three levels of dependency-resolution: Requires, Recommends
> > and Suggests.
> >  * Requires: the requested package cannot function without this
> > additional package installed
> >  * Recommends: the requested package can function in some minimal
> > capacity without this additional package installed, but the majority of
> > installations will want it for full productivity. These are usually
> > core plugins for the primary package. DNF defaults to installing
> > Recommends: dependencies automatically.
> >  * Suggests: the requested package can easily function without this
> > additional package. This module may provide some less-common
> > functionality that a user might want. DNF defaults to *not* installing
> > Suggests: packages automatically.
> >
> > Traditionally, we have only supported "Requires" dependencies and thus
> > the creation of install media (Live and otherwise) has been relatively
> > straightforward: we create a kickstart file that is fed into the
> > compose process containing a list of packages and groups that we want
> > installed onto the target system and the compose process automatically
> > pulls in all of the dependencies. However, with the advent of weak
> > dependencies, we have new questions that need answering about how this
> > compose process should work. (We also need to investigate what exactly
> > happens with the tools we have today - some of which still use yum, not
> > DNF - when weak dependencies are added to the mix).
> >
> > From my perspective, there are three ways that we could choose to go:
> >
> > 1) Follow the default DNF behavior: Requires: and Recommends: packages
> > are included on the install media (and therefore also installed
> > together onto the target system)
> >
> > 2) Include *all* dependencies - Requires, Recommends and Suggests - on
> > the install media. The installer would still follow DNF defaults, so
> > the target system would get only the Requires and Recommends packages
> > unless the Suggests: packages are explicitly selected (which will also
> > require the creation of additional comps.xml changes to include the
> > Suggests packages)
> >
> > 3) Include only Requires: dependencies by default and require spin
> > -kickstarts owners to explicitly add any Recommends or Suggests
> > packages that they also want to include. Packages added explicitly will
> > be installed as described in 2) (requiring additional comps.xml changes
> > to include Suggests stuff)
> >
> >
> > Note that at the moment, DNF itself does not have a configuration
> > option to tweak the default install behavior, so 'dnf install'
> > effectively treats Recommends the same way as Requires (but 'dnf
> > remove' will treat them differently, of course). I discussed this with
> > the DNF developers this morning and they hope to have a configuration
> > option and/or command-line argument available to change this behavior
> > before Beta Freeze, so we should still be able to ship F23 with any of
> > the above options.
> >
> > I think the best time to make these decisions is now, well in advance
> > of the Alpha Freeze so we have time to make adjustments as needed.
> > Thank you for reading to the end, I know the above has been a wall-o'
> > -text.
> >
> >
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVpMSzAAoJEAzgnueZF7h8epkP/0LH9wzwx5XjS41lOnG3cr5C
> 2O5fEOwODffCa6une0tiJDTLvXLyx9BthEKClRHImpNFEVXg9QGGYurWbqhRfeJA
> Zvc1Wzuvlf2s5iNEMFw7c8S1s3FK4/ytX4hMSx5F/9RAENq/qKxKEUU6BjiP6RxF
> qP7e5yaN+y6QEuogWe2j4caqD/mfP8ZhanrvHO/KAOv8a+OAp0LZXF4uuHbfxfak
> 0OJw2/q9oKoO8ww5CiNJdRk+vMEXnIOT9XzMdqcpV5/GzKt42wNFqusT84Shvih2
> nl2PB6Wh1rPL8oUwmQsWToEpoN0Zjh7FDVqZcbn4ja7depmJ0ub0cNTl4eJ+1AJc
> fc5c+pZ5qLUKokTOvk708yy5pq2HbByqBTeBHxG51YwLZd2bUlZBQbyfadfM66Z3
> FzyiEEjxA+V/mm0VXoA1kuEN1+8BnW25atifnvTLcGs5doGnEivDogaCDi8GDdCt
> dR/ZLPCJySNcZJPROfrlKWd6PSUfX/M3bzdaBJcIQL/klO45dYTGolxyr0R/Muf5
> B/apLMsVTyLE8Qp4HpmcmjKft1rgXNAHpe3EyXD39dhrtbpmZyMYwjO029yYAi6R
> tQa2ISnuQO1hMv78A5KhseKMyHv4XKgeMaXwwdpKExZh2u8otgCBZXYq/G7MiMWc
> 3UQOteXvXhgWXjW5y7m4
> =EPjN
> -END PGP SIGNATURE-
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/cod

Re: Proposal: Drop comps

[Neal Gompa]

On Tue, Jul 14, 2015 at 6:23 AM, Vít Ondruch  wrote:

>  Dne 14.7.2015 v 11:49 Neal Gompa napsal(a):
> > On Tue, Jul 14, 2015 at 4:13 AM, Vít Ondruch  <mailto:vondr...@redhat.com> >wrote: > >
>
> Can we just drop comps entirely (or at least trim them down
> significantly)? I know that this will not happen from day to day, but I see
> the comps just as an ugly workaround for missing weak dependencies, which
> we have now.
>
>
> Vít
>
>
>
>  > > > If we did that, we'd need to switch to some other means of
> grouping packages. ​Borrowing a bit from how the Debian/Ubuntu folks do
> things, probably massive virtual packages/metapackages would work well for
> this purpose. ​Or perhaps a "type" of package that defines groups to
> provide a similar function to metapackages without requiring garbage empty
> tarballs.
> One advantage of comps/groups was that it allowed to uninstall particular
> packages, where if you used Require at the same place, it would be all or
> nothing. For example, rubyonrails group would be better to express by
> Suggests dependencies then to have the group in comps. Not mentioning that
> Gnome Software can handle meta package while it does not handle groups (if
> I am not mistaken).
>
> Vít
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​It should be possible to convert over to metapackages, but it would
probably make sense to convert a few groups and see how it should be shaken
out. Remember, we're a bit new to this weak dependency resolution thing! ;)​


-- 
Neal Gompa (FAS: ngompa)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Hosting End-Of-Life Fedora Base images?

[Neal Gompa]

On Mon, Jul 20, 2015 at 3:33 PM, Chris Murphy 
wrote:

> Isn't it true the install media ISOs are available indefinitely? And
> if so the security cat is already out of the bag, so that's not a very
> good argument. I'd say if we wanted to do something better it would be
> an image that's usable for both VM and containers, and would be the
> state of that version at the time it went EOL, i.e. it has all
> available updates baked into it. And then de-emphasize the original
> ISO as the way to run older versions of Fedora.
>
>
> Chris Murphy
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​I tend to agree with the rest of the choir here in saying we shouldn't
make it easier for people to use EOL releases. It will likely add
unnecessary burdens onto us and our systems when people come to ask about
EOL Fedora releases in Docker. Not to mention, we should be encouraging
people to move up, not stay put.

Honestly, I think if people need a platform that lasts a long time, they
should be looking at CentOS with EPEL, SCLs, and/or other repos depending
on what they need.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving our processes for new contributors.

[Neal Gompa]

On Tue, Jul 21, 2015 at 8:44 AM, Miroslav Suchý  wrote:

> Dne 11.7.2015 v 23:38 Jonathan Underwood napsal(a):
> > Thoughts from the COPR folks?
>
> I like the idea of adding Copr as intermediate step for new contributors.
> Copr is outer ring of Fedora and it definitely
> make sense for newbies to go from outer ring to ring0. Step by step.
>
> Additionally we have in plan to run fedora-review consequently after each
> build, which hopefully will lead to better
> quality of spec files and resulting RPMs.
>
>
> Regarding long wait for sponsor: We have little over 120 sponsors right
> now. And there is little over 210 reviews
> waiting for sponsors.
> If every sponsor would take 2 reviews right now, the queue would be empty.
> So our current process still can work.
> However I am aware that sponsoring somebody is very irregular task. I am
> sponsor too. It happen that I sponsor 2
> contributors in one month, but sometimes there are months where I focus on
> something else and I forgot on my sponsor
> duties. I assume other sponsors have it similar.
> I would welcome if somebody can write cron script which would mine data
> from BZ and send me email that:
>
> Dear sponsor,
> it seems that you did not sponsor anybody for 3 months. We have 120 new
> contributors waiting for sponsor.
> Please consider taking some bug from:
>   https://bugzilla.redhat.com/show_bug.cgi?id=177841
>
> Sincerely your Watchmen
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

In principle, I agree that Copr is probably a good proving ground, but Copr
needs a lot of work right now to make that doable. It's extraordinarily
slow right now, and builders don't have the level of availability needed to
support it being part of the review process. It needs to become as good as
OpenSUSE's Open Build Service and Canonical's PPAs before we can have any
serious usage of it for this kind of work.

-- 
Neal Gompa (FAS: ngompa)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora developer portal - proof of concept

[Neal Gompa]

On Tue, Jul 21, 2015 at 9:57 AM, Jonathan Wakely  wrote:

> On 21/07/15 15:45 +0200, Petr Hracek wrote:
>
>> Feel free to send us any comment or improvements. We would like to
>> improve Fedora for developers.
>> Just contents are missing.
>>
>
> Under "The latest stable runtimes and frameworks Packaged in Fedora
> and ready to use!" would it be worth mentioning C and C++?
>
> GCC 5 is the first compiler to default to the latest C11 standard, and we
> ship more of the latest C++ standard library extensions than any
> other compiler.
>
> There's a lot happening in that space, and not everyone gets excited
> by shiny dynamic languages ;-)
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


​Personally, I'm a little uncomfortable with the phrasing "Fedora is made
for developers". It implies that we don't do anything to make it great for
non-developers, which is not true at all. ​Is there a better way we can
word this?


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving our processes for new contributors.

[Neal Gompa]

On Tue, Jul 21, 2015 at 11:32 AM, Kevin Fenzi  wrote:

> On Tue, 21 Jul 2015 16:23:34 +0200
> Miroslav Suchý  wrote:
>
> > Dne 21.7.2015 v 15:23 Neal Gompa napsal(a):
> > > It's extraordinarily slow right now, and builders don't have the
> > > level of availability needed to support it being part of the review
> > > process.
> >
> > While this was true in past, this changed a lot in past two months.
> > Occasionally we have issues with PPC64LE builders as they are quite
> > new to us. However Intel builders are very stable and there is lot of
> > them there now (28 right now). You can hardly see some queue there.
> > All task are processed immediately.
>
> Yeah, I was going to ask for more details about this also.
>
> Where do you see the slowness in the process? Uploading? Building?
>
> kevin
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Accessing the Copr site is as slow as trying to search our Bugzilla (which
is very slow indeed). Opening up pages describing Copr repos is slow too. I
occasionally get browser timeouts accessing Copr. As for builds, those seem
to be okay, but everything else is obnoxiously slow.

If I want to be *really* nitpicky, it's also not picking up my
libravatar.org avatar either. ​

​And it's definitely not my internet connection, as I can easily pull down
a Fedora Server DVD ISO in less than 10 minutes.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving our processes for new contributors.

[Neal Gompa]

On Wed, Jul 22, 2015 at 6:45 AM, Miroslav Suchý  wrote:

> Dne 21.7.2015 v 19:28 Neal Gompa napsal(a):
> >
> > ​ Accessing the Copr site is as slow as trying to search our Bugzilla
> (which is very slow indeed). Opening up pages
> > describing Copr repos is slow too. I occasionally get browser timeouts
> accessing Copr. As for builds, those seem to be
> > okay, but everything else is obnoxiously slow.
>
> This issue was identified and fixed 2 weeks ago. Is it really slow for you
> even in these days?
>
> > If I want to be /really/ nitpicky, it's also not picking up my
> libravatar.org <http://libravatar.org> avatar either. ​
>
> Your email in Copr is ng@fedoraproject.org, while your email is
> stored in FAS is your gmail email.
> I assume that your libravatar is not showing because you do not have
> libravatar associated with your @fedoraproject.org
> email alias.
> However I wonder why Copr have different email from FAS. Copr update email
> from FAS every time you log into Copr. So
> unless you change it recently and not logged into Copr since then it
> should not be different.
>
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​These issues were present *the very moment* I wrote the email, because I
literally went to the Copr site and set up a project to verify the issues
just before sending the email.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Neal Gompa]

On Tue, Jul 28, 2015 at 5:37 AM, Florian Festi  wrote:

> On 07/28/2015 09:43 AM, Lubos Kardos wrote:
> > Support in rpm is not enough but libsolv supports rich deps since the
> version
> > 0.6.9 too thus rich deps work also in hawkey and dnf if the version
> 0.6.9 or
> > a newer version of libsolv is installed.
>
> Right now only AND and OR is supported by libsolv. Implementation of IF
> ELSE is still pending.
>
> Also we still need to settle to a final syntax for the operators [1].
> Unfortunately there is no consensus among the other packaging formats
> what to use. Right now rpm accepts 3 different styles:
>  * AND OR IF ELSE
>  * & | ? :
>  * && || ? :
> But the final release will only support on of them. As soon as the alpha
> stops eating babies that's a discussion we need to have.
>
> So for now they are more a tech preview in Fedora but we want to get
> them operational til the release. This still means that they are not
> supposed to be used in F23 as they may only completely work very late.
> Also there is still a lot of paper work to do for the packaging policy.
>
> I expect that both Boolean Deps and File Triggers won't be introduced in
> one go but there will be multiple Fedora Features introducing them one
> use case at a time. E.g. one feature per file trigger replacing one kind
> of scriptlets. Boolean dependencies being used for language packs being
> one Feature/Package Policy section and other use cases being others.
>
> This may start in the F24 time frame - especially for some urgent corner
> cases - but my guess is that this will rather take multiple releases.
>
> Florian
>
> [1] http://rpm.org/wiki/PackagerDocs/BooleanDependencies
>
> --
>
> Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael
> O'Neill, Charles Peters
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Is there a reason why we can't maintain all three kinds? Also, why in the
world are bitwise operation operators supported for logical operations? I'd
be okay with maintaining options 1 and 3, to be honest. ​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gpg keys of older/newer fedora versions

[Neal Gompa]

On Wed, Aug 5, 2015 at 8:41 AM, Ryan S. Brown  wrote:

> On 08/01/2015 03:25 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sat, Aug 01, 2015 at 10:40:45AM -0600, Kevin Fenzi wrote:
> >> On Fri, 17 Jul 2015 17:28:48 +
> >> Zbigniew Jędrzejewski-Szmek  wrote:
> >>
> >>> [In light of https://bugzilla.redhat.com/show_bug.cgi?id=1241383]
> >>>
> >>> 'dnf install --installroot=... --releasever=XX dnf' can be used to
> >>> bootstrap a Fedora chroot. The only snag is that --nogpg is often
> >>> recommended, because fedora-repos only provides the GPG keys for the
> >>> current and next release.
> >>>
> >>> It would be convenient (and safe!) to provide keys for past and
> >>> future releases, so such bootstrapping can be done without either
> >>> importing the keys manually and/or using --nogpg.
> >>>
> >>> I thought I'd ask here first: is there a strong reason *not* to
> >>> include those keys?
> >>
> >> So, I missed this thread, but saw it from the bug filed:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1246701
> >>
> >> Several things here:
> >>
> >> * If we ship gpg keys for old eol Fedora releases, aren't we
> >>   encouraging people to setup things we no longer support?
> > I never asked for keys from EOL releases. I think keys should
> > be removed after EOL.
> >
> >> * If we only ship supported releases in each fedora-repos package, it
> >>   means more churn for that package for everyone as when a release goes
> >>   EOL we would need to push a new update that removes the old EOL key.
> > Is "everyone" the users or they maintainers of fedora-repos.rpm?
> > The "churn" is really tiny: the package is small, and this happens
> > only twice a year, so I dont' think users will notice or care. As for
> > the maintainers: I know it is a bit of extra work. I'm trying to ask
> > nicely :)
> >
> >> * As till pointed out, mock seems to already carry these keys, so some
> >>   coordination here seems like a good idea no matter what we do. ;)
> > Yeah. One issue I see is that mock seems to be always trailing with
> > the updates. Mock in F22 now has
> > /etc/pki/mock/RPM-GPG-KEY-fedora-19-primary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-19-secondary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-20-primary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-20-secondary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-21-primary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-21-secondary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-22-primary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-22-secondary
> > The version in updates-testing removes keys for F19 and F20,
> > and adds keys for F23. It has chroot definitions to match those keys.
> > *If* mock was relying on fedora-repos to carry they keys, it would
> > be possible to have chroots without a matching key. I don't
> > know if that would be good (EOL chroots stop working as expected) or
> > bad (EOL chroots stop working unexpectedly).
>
> I disagree that including the keys for EOL'd releases counts as
> "encouraging" people to use old stuff. If someone has a reason to be
> building RPMs for something way-old, I think it'd be nice for us to keep
> those GPG keys available for them.
>
> Speaking only for myself, whenever I have to build something for a very
> old box, the last thing I want is mock giving me grief about not having
> a GPG key that old.
>
> >> * Can you describe the use case here a bit more? Why wouldn't you use
> >>   mock (which has the keys already) to make a chroot?
> > I want to use dnf to create containers, e.g. for running with
> > systemd-nspawn. Sometimes for installation of Fedora on a disk
> > to bootstrap a new machine. In either way, it is a one-time
> > operation where the result is permanent.
> >
> > mock is about repeatedly creating chroots tailored for rpm building...
> > The underlying installation mechanism is pretty much the same,
> > but that's about it.
> >
> > Zbyszek
> >
>
> --
> Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​As someone who is regularly using mock to build RPMs for various Fedora
releases for $DAYJOB as well as for packages that I submit to Fedora
Project, I would prefer if the ability to build RPMs for older releases is
preserved (even EOL ones). As for the container things, it'd be interesting
if mock could use DNF+nspawn for that work in the future, and if that means
splitting out GPG keys and such into a package that both DNF and mock can
use, that would be great.

I personally don't think that having mock being able to build for older
releases would encourage the view that Fedora supports older releases.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up: F23 products/spins, weak rpm dependencies, and you

[Neal Gompa]

On Wed, Aug 5, 2015 at 10:38 AM, Adam Jackson  wrote:

> In Fedora 23, rpm has grown support for weak dependencies (Recommends:
> and Suggests: tags). However, the compose tools have not been ported to
> dnf/libsolv yet, which means these tags will have no effect at image
> compose time.
>
> This has implications for spin kickstarts: the set of packages included
> in media derived from a kickstart will be a subset of the packages you
> would see installed by passing the kickstart package/group list to dnf.
> As a result, any packages that you want to see included on the
> generated media must be either explicitly listed in the kickstart, or
> brought in with Requires: from another package. Technically this is not
> different from previous Fedora releases, but it is different from what
> you might get from using F23's dnf to compute a package list.
>
> Product and spin kickstart maintainers are advised to double-check the
> package manifests for the produced media to ensure all packages they
> want included actually are included.
>
> - ajax
> ___
> devel-announce mailing list
> devel-annou...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel-announce
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


​Are the compose tools going to match DNF's behavior in package dependency
resolution in the near future?​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up: F23 products/spins, weak rpm dependencies, and you

[Neal Gompa]

On Wed, Aug 5, 2015 at 12:28 PM, Brian C. Lane  wrote:

> On Wed, Aug 05, 2015 at 10:38:07AM -0400, Adam Jackson wrote:
> > In Fedora 23, rpm has grown support for weak dependencies (Recommends:
> > and Suggests: tags). However, the compose tools have not been ported to
> > dnf/libsolv yet, which means these tags will have no effect at image
> > compose time.
>
> To clarify the state of things a bit -- lorax is already using DNF (and
> python3) so anything creating a boot.iso or a DVD based on the boot.iso
> will use DNF to select the packages.
>
> livecd-creator is still yum and python2 based. I have no plans to change
> this, it's time for us to switch to using Anaconda via
> livemedia-creator so that we can keep the installation logic in one
> maintainable place.
>
> rel-eng is still using livecd-creator for Fedora 23. Hopefully
> livemedia-creator koji integration will be working for Fedora 24. In the
> meantime you can still use livecd-creator.
>
> Anaconda is using DNF by default and is also python3 for Fedora 23 so
> any package based installations will use DNF.
>
> livemedia-creator documentation is here:
> https://rhinstaller.github.io/lorax/livemedia-creator.html
>
> And I've written a blog post here:
> https://www.brianlane.com/creating-live-isos-with-livemedia-creator.html
>
> --
> Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA
> (PST8PDT)
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​What keeps us from completing livemedia-creator Koji integration for
Fedora 23? And what of the state of pungi?​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ncurses update to 6.0

[Neal Gompa]

On Aug 5, 2015 2:55 AM, "Miroslav Lichvar"  wrote:
>
> On Tue, Aug 04, 2015 at 10:09:34AM -0600, Stephen John Smoogen wrote:
> > On 4 August 2015 at 04:33, Miroslav Lichvar  wrote:
> > > As for updating the ncurses package, my current plan is to build the
> > > libs in both ABIs (so there are four builds total with the wide and
> > > narrow versions), use the ncurses-libs subpackage for the new ABI 6
> > > libs and create a new subpackage for ABI 5 libs. What would be a good
> > > name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5,
> > > or something else?
> > >
> >
> > Are you looking to do this for F23 branch and rawhide or just rawhide
> > and have it land in F24 when it is ready? Or is that still to be
> > determined.
>
> I was thinking about doing this in rawhide only with no
> ncurses-specific rebuilds. After the next mass rebuild everything
> that didn't FTBFS should be using the ABI 6 libs.
>
> --
> Miroslav Lichvar
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

If you can provide both versions, I don't see a reason to not provide it in
Fedora 23 branch too. We could just not force a rebuild in the branch and
do that only in rawhide.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Metadata signing for rawhide

[Neal Gompa]

In the rpm-ecosystem mailing list, Michael Schroeder from SUSE brought up
that we don't sign the metadata for the rawhide repository

and it would be nice if it was signed so that he could be sure that the
mirrors didn't "do funny things".

Is there a reason we don't sign the rawhide repodata? Forgive me for my
ignorance, but do we sign repository metadata at all, and if so, how do we
do it I'd like to do that for my own repos too.

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is it time to allow Chromium in Fedora?

[Neal Gompa]

On Tue, Aug 11, 2015 at 2:41 PM, Gerald B. Cox  wrote:

>
> On Tue, Aug 11, 2015 at 11:28 AM, Chris Adams  wrote:
>
>> What packaging exceptions are being made for Firefox?
>
>
> They can be found here:
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​I think if we're willing to grant such an exception to Firefox, we should
be willing to extend the same to Chromium. That is, of course, provided
that we can actively work towards cutting away at bundled libraries and
getting the engine switched from FFmpeg to GStreamer. Right now, the effort
to switch from ffmpeg to GStreamer is being done largely by Samsung
, and I think that
variant of Chromium is much more appealing due to the pluggable codec
framework in GStreamer. I'd rather not have Fedora ship Chromium ​with a
gimped ffmpeg if we didn't have to, but it would be acceptable if using
Samsung's efforts to offer GStreamer support isn't appealing right now and
that the bundled ffmpeg libraries are split out into a subpackage.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is it time to allow Chromium in Fedora?

[Neal Gompa]

On Tue, Aug 11, 2015 at 5:07 PM, Chris Adams  wrote:

> Once upon a time, Gerald B. Cox  said:
> > On Tue, Aug 11, 2015 at 11:28 AM, Chris Adams  wrote:
> > > What packaging exceptions are being made for Firefox?
> >
> > They can be found here:
> > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>
> So FF bundles a small number of libraries, and has an exception because
> of an "active security team".
>
> How many libraries does Chromium bundle?  How many people are working on
> it?  Sounds like spot is the only person working on packaging.
>
> --
> Chris Adams 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Chromium/Chrome also has a very active security team, so if that's the
reason for allowing it with Firefox, it could also be allowed for the same
reason.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Is it time to allow Chromium in Fedora?

[Neal Gompa]

On Wed, Aug 12, 2015 at 11:14 AM, Matthew Miller 
wrote:

> On Tue, Aug 11, 2015 at 10:11:39PM -0400, Gary Gatling wrote:
> > > I realize we have our guidelines and we're not Debian, Suse or
> Ubuntu...
> > > and that's a good thing.  But, if we're making exceptions for Firefox
> > > because of it's popularity shouldn't we do the same for Chromium.
> > I agree with Gerald. If there are exceptions for firefox due to
> popularity
> > then chromium deserves the same bundling exceptions. Otherwise we are not
> > being fair.
>
> It's important to note that "popularity" is not the sole reason for
> exceptions for Firefox. Overall, everyone should review the existing
> discussion in the guidelines about bundling exceptions and consider how
> this might fit in (possibly including revisions if they make sense):
>
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Some_reasons_you_might_be_granted_an_exception
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> --
> packaging mailing list
> packag...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging


​While it is true that Chromium does indeed bundle a lot more than Firefox
does, I think they've also been putting in quite a bit of work into
actually solving this problem[0]. To be absolutely fair to Chromium, they
recognized the issue very quickly after they started making Linux releases.
On top of the fact that Chromium development moves extremely quickly[1] and
they appear to be quite responsive on security issues and work hard to
design the application to be secure in itself[2]. If I remember correctly,
it was Chromium's rapid development pace that triggered Firefox's own
development practices to change[3].

I think that it's hard for us to continue to ignore Chromium, too. Despite
everything, Chrome is preferred web browser by Fedorans second to Firefox,
and not by a wide margin with Google+ users and a somewhat wide margin with
Facebook users[4]. I imagine the lack of Chromium in Fedora is pretty much
the reason for low usage and Firefox being default the reason for it
remaining the top browser.

If there's a huge stopper of some kind, we should engage with the Chromium
folks more directly on solving it. I don't know exactly what that would
involve, but we should do something about it, I think.

[0]: https://code.google.com/p/chromium/issues/detail?id=28287
[1]: https://www.chromium.org/getting-involved/dev-channel​
[2]: https://www.chromium.org/Home/chromium-security
[3]:
http://www.computerworld.com/article/2506843/desktop-apps/firefox-follows-chrome-lead--eyes-faster-releases.html
[4]:
https://eischmann.wordpress.com/2015/07/31/most-popular-web-browsers-among-fedora-users/


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

[Neal Gompa]

On Fri, Aug 14, 2015 at 8:48 AM, Petr Stodulka  wrote:

>
>
> On 14.8.2015 14:38, Wei-Lun Chao wrote:
>
>> Hi,
>>
>> Is there already any discussion about:
>> rename arch name "noarch" to "all"
>> rename arch name "x86_64" to "amd64"
>> rename package name "kernel-PAE" to "kernel"
>> and even rename package name "kernel" to "linux"
>>
> IMO really bad idea in all cases.
>
> Petr
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Out of all of those suggestions, the only one that might have any real
value would be renaming "kernel" to "linux", but only if we were interested
in introducing other FOSS kernels as options into the distribution. At this
time, I seriously doubt anyone wants to do this...​



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

[Neal Gompa]

On Sat, Aug 15, 2015 at 3:18 PM, Sérgio Basto  wrote:

> On Sáb, 2015-08-15 at 21:22 +0800, Christopher Meng wrote:
> > On 8/14/15, Wei-Lun Chao  wrote:
> > > Hi,
> > >
> > > Is there already any discussion about:
> > > rename arch name "noarch" to "all"
> > > rename arch name "x86_64" to "amd64"
> > > rename package name "kernel-PAE" to "kernel"
> > > and even rename package name "kernel" to "linux"
> >
> > noarch doesn't mean all, and what's 'all' exactly? All archs? All
> > Fedora versions?
> >
> > x86_64 and amd64 are just some Debianish still, perhaps last straw to
> > show amd somewhere or whatever?
>
> yeah, Debian names are all wrong , so I'd suggest do the opposite ,
> Debian (and Ubuntu) change "all" to "noarch" , "amd64" to "x86_64" and
> "linux" to "kernel" .
> BTW: Debian also should change the apache package name to httpd, Apache
> is an organization not a web server, the web server of Apache is the
> httpd.
>
> Best regards,
> --
> Sérgio M. B.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​To be fair, Debian's use of "linux" over "kernel" is because they actually
support another kernel (the FreeBSD kernel). If the Fedora Project wanted
to add FreeBSD kernel support (which, as far as I know, we don't), then we
would have to talk about how to deal with that issue. Though even then,
it's pretty easy, since all we would have to do is change kernel and
kernel-devel into virtual packages that kernel-linux or kernel-freebsd
would be able to satisfy.

The usage of "all" in Debian is largely because the way they treat
architecture independent data differs from how we do it in Fedora. They try
to ensure the architecture independent data is fully reusable across all
architectures they support, while the nature of our packages mean that
"noarch" could differ among architectures and basically means that it
doesn't have any binary data.

The naming of httpd and bind and a whole bunch of other packages in Debian
is somewhat annoying, since it doesn't really respect upstream's wishes,
but whatever...​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Same comand names in /usr/bin and /usr/sbin

[Neal Gompa]

On Sun, Aug 16, 2015 at 7:25 PM, Reindl Harald 
wrote:

>
> Am 17.08.2015 um 01:22 schrieb Nico Kadel-Garcia:
>
>> On Sun, Aug 16, 2015 at 6:24 PM, Nico Kadel-Garcia 
>> wrote:
>>
>>> On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald 
>>> wrote:
>>>

 Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:

>
> It's a basic violation of the ordinary segregation between "/bin" as
> ordinary user tools" and "/sbin" as sysadmin tools to start mixing
> them, and much more confusing to have the same program name in both.
> And it's frankly easy to avoid. "mock", for example, should rename
> "/.sbin/mock" to something else to avoid command line confusion
>

 nonsense

 ./sbin/ is nowehre in the FHS
 ./sbin/ is not below/usr
 ./sbin is not protected ReadOnlyDirectories=/usr

 /usr/lib/appname and /usr/libexec exists

>>>
>>> /sbin isn't a separate filesystem, it is a subdirectory of "/", and
>>> it's explicitly mentioned at
>>> http://www.pathname.com/fhs/2.2/fhs-3.14.html as requiring copies or
>>> symlinks to certain specific, long-stable program names. Let me quote
>>> that document:
>>>
>>
>> Ahhh, I am sorry, I may have contributed to the confusion by mistyping
>> "/sbin" as ""/.sbin". I'm on a new email interface, and am having some
>> difficulty with "overwriting" as opposed to my preferred default
>> "insertion" for editing. But that was my own fault
>>
>
> the same nonsense
>
> /sbin is the same as /usr/sbin for a long time now
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Quoting in FHS 3.0
 (which is
really the one we should be looking at):​

*The following commands, or symbolic links to commands*... (Sect 3.16.2)
[...]
*The following files, or symbolic links to files*... (Sect 3.16.3)

(From FHS chapter 3.16 "/sbin: System binaries"
)

Thus, it sounds like FHS is okay with the idea of */sbin* being symlinked
to some other directory. Ultimately, FHS doesn't appear to mandate that the
folder and its contents must physically exist there, only that they are
present to enable "*booting, restoring, recovering, and/or repairing the
system*" (Sect 3.16.1).

The split between */sbin* and */bin* was largely for providing a logical
division of core administrative functions and the rest of the stuff
installed. Frankly, I don't see how that matters so much anymore. FHS
doesn't even recommend walling off access to */sbin*, either.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Build root prepared by DNF is way larger

[Neal Gompa]

Do we have a switch or configuration option for that yet?
On Aug 18, 2015 5:27 PM, "Heiko Adams"  wrote:

> Am Dienstag, den 18.08.2015, 14:54 -0400 schrieb Matthew Miller:
>
> > Hmmm. I think that for the buildroot case, we probably want DNF to
> > _not_ installer Recommended packages.
>
> That makes sense to me.
> --
> Regards,
> Heiko Adams
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Rawhide plans

[Neal Gompa]

On Wed, Aug 19, 2015 at 1:29 PM, Bill Nottingham  wrote:

> Rex Dieter (rdie...@math.unl.edu) said:
> > Kevin Fenzi wrote:
> >
> > > * Matt opened a thread on the marketing list about renaming rawhide. It
> > > sounds like most people would prefer us to make the changes first,
> > > then and only then look at renaming.
> >
> > s/renaming/rebranding/
> >
> > I personally would prefer the name be preserved if at all possible, but
> if
> > the marketing gurus feel otherwise, so be it.
>
> Certainly agree with making the changes first - if a name has a bad
> reputation because of how things have worked in the past, if you don't
> fix those things, that reputation will just move right onto the new name...
>
> Bill
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​One thing I would like to see is that Fedora's development code could
reach a state where something like openSUSE's Tumbleweed would be possible.
If we could take daily/weekly/biweekly snapshots of the repositories for
people to use as a rolling release like the way the openSUSE folks ​are
doing, I think that would go a long way to enabling a higher scale of
testing of code that makes it into Fedora releases. I don't want use to let
go of normal releases, but I feel that the people who want to have that
"rolling" model should be able to from Fedora and expect a reasonable level
of things working.

If we're able to do something like this, the "rawhide" name could certainly
stay for the development code, but a new name for these snapshots would be
appropriate.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi 2 now live

[Neal Gompa]

On Sun, Aug 23, 2015 at 6:32 PM, Jonathan Wakely  wrote:

> On 23/08/15 16:36 -0400, Rahul Sundaram wrote:
>
>> Hi
>>
>> On Sun, Aug 23, 2015 at 4:23 PM, Kevin Kofler wrote:
>>
>> No, sorry, but that is not true. I wrote those update notes in the Bodhi 1
>>> web interface, so of course I looked at the resulting formatting. Bodhi 1
>>> interpreted that syntax as a list, not as a single paragraph. This is a
>>> change in Bodhi 2 (and IMHO, for the worse, though if there's some
>>> official
>>> Markdown spec that says it should be that way, meh…).
>>>
>>
>>
>> Markdown has no official spec.  The closest you can get is commonmark.
>> Fairly sure, the current parsing is more "correct".
>>
>> http://commonmark.org/
>>
>
> Some Markdown implementations require the blank line before the list
> (StackOverflow's does), but CommonMark doesn't:
>
>  In CommonMark, a list can interrupt a paragraph. That is, no blank
>  line is needed to separate a paragraph from a following list:
>  http://spec.commonmark.org/0.21/#example-246
>
> So the current parsing doesn't match CommonMark.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​The current parsing model seems to work the same way as most other
Markdown enabled systems do (GitHub, BitBucket, Reddit, etc.), where an
empty line is required just before a list or some other block to work. I
always thought it was supposed to be that way, since it looks like
that on Daring
Fireball's spec ,
too.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Do you know how many 64-bit architectures Fedora has?

[Neal Gompa]

On Mon, Aug 24, 2015 at 9:12 AM, Marcin Juszkiewicz  wrote:

> Hi
>
> During last few days I fetched over 26 thousand of Fedora package
> repositories. Plan to go though all spec files and submit some patches
> mainly related to my aarch64 work.
>
> We live in a world where most of Linux systems are either 32 or 64 bit.
> But do you know how many 64-bit architectures Fedora and RHEL have?
>
> According to spec files we have at least 8 while current Fedora has 1
> primary and 4 secondary ones.
>
> x86-64 is main one which most of developers use for everything
> aarch64 is my favourite secondary one
> ppc64 is probably fastest one
> ppc64le is little endian version of previous
> s390x is fridge size mainframe (is such small exist)
>
> Specs also mention ia64 (not supported Itanium), alpha (I have some
> friends who still own them but do not run), sparc64/sparcv9 (even Debian
> got rid of sparc support).
>
> But why I write?
>
> Because there are lot of code like:
>
> %ifarch x86_64 ppc64 ia64 s390x sparc64
> USE_64=1
> %endif
>
> Where is should be:
>
> %if 0%{?__isa_bits} == 64
>  USE_64=1
> %endif
>
> Which works since RHEL6 (from what I know). And it automatically covers
> all 64-bit architectures not only those which maintainer remembers.
>
> So please do me a favour and take a look at your packages and adapt their
> spec files. Otherwise sooner or later such patch may land in bugtracker but
> instead I could fix some other package at same time.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


​Oh, yes! I was trying to find something like this all weekend for my Copr
for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on
64-bit systems, but on 32-bit systems it should remain /usr/lib.

You just made my day. ​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Do you know how many 64-bit architectures Fedora has?

[Neal Gompa]

On Mon, Aug 24, 2015 at 9:26 AM, Marcin Juszkiewicz  wrote:

> W dniu 24.08.2015 o 15:18, Neal Gompa pisze:
>
>> ​ Oh, yes! I was trying to find something like this all weekend for my
>> Copr for reprepro. I have to make a patch to access apt-methods in
>> /usr/lib64 on 64-bit systems, but on 32-bit systems it should remain
>> /usr/lib.
>>
>> You just made my day. ​
>>
>
> You know that %_libdir is what you want? /usr/lib on 32bit, /usr/lib64 on
> 64bit.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

I'm well aware. The buildsystem is fine. It's the code that's the problem.

On Mon, Aug 24, 2015 at 9:27 AM, Daniel P. Berrange 
wrote:

> On Mon, Aug 24, 2015 at 09:18:16AM -0400, Neal Gompa wrote:
> >
> > ​Oh, yes! I was trying to find something like this all weekend for my
> Copr
> > for reprepro. I have to make a patch to access apt-methods in /usr/lib64
> on
> > 64-bit systems, but on 32-bit systems it should remain /usr/lib.
> >
> > You just made my day. ​
>
> You should not really assume that all 64-bit architectures use /usr/lib64
> either - %{_libdir} expands to the right directory path per architecture.
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Well, the problem is that ​the path to apt-methods is hardcoded in
reprepro itself. Thankfully, it's in a #define, but I don't know of a good
way to fix it beyond just replacing the #define for 64-bit systems. ​If
someone can suggest a better way than how I'm doing it now, I'm all ears,
because I hate this patch[0].

[0]:
http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/mirrorer/reprepro.git/tree/reprepro-use-lib64-on-64bit-systems.patch


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Do you know how many 64-bit architectures Fedora has?

[Neal Gompa]

On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely  wrote:

> On 24/08/15 14:39 +0100, Jonathan Wakely wrote:
>
>> On 24/08/15 09:31 -0400, Neal Gompa wrote:
>>
>>> ​Well, the problem is that ​the path to apt-methods is hardcoded in
>>> reprepro itself. Thankfully, it's in a #define, but I don't know of a
>>> good
>>> way to fix it beyond just replacing the #define for 64-bit systems. ​If
>>> someone can suggest a better way than how I'm doing it now, I'm all ears,
>>> because I hate this patch[0].
>>>
>>> [0]:
>>>
>>> http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/mirrorer/reprepro.git/tree/reprepro-use-lib64-on-64bit-systems.patch
>>>
>>
>> You could add -DSTD_METHOD_DIR=%{_libdir}/apt/methods to the compiler
>> flags.
>>
>
> Oops, to keep the quotes it would be
>
>  -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Would that override the in-code #define statement?​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Do you know how many 64-bit architectures Fedora has?

[Neal Gompa]

On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely 
wrote:

> On 24/08/15 10:06 -0400, Neal Gompa wrote:
>
>> On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely 
>> wrote:
>>
>>> Oops, to keep the quotes it would be
>>>
>>>  -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
>>>
>>
>> ​Would that override the in-code #define statement?​
>>
>
> Yes, because the #define is guarded by:
>
> #ifndef STD_METHOD_DIR
>
> so if it's defined on the command line then it won't get defined in
> main.c
>
> But whether you alter the #define in main.c or set it on the
> command-line, using %{_libdir} seems better than /usr/lib64.
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​How do I append to the CFLAGS at the %configure statement?​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Do you know how many 64-bit architectures Fedora has?

[Neal Gompa]

On Mon, Aug 24, 2015 at 10:31 AM, Reindl Harald 
wrote:

>
> Am 24.08.2015 um 16:27 schrieb Neal Gompa:
>
>> On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely > <mailto:jwak...@redhat.com>>wrote:
>>
>> On 24/08/15 10:06 -0400, Neal Gompa wrote:
>>
>> On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely
>> mailto:jwak...@redhat.com>> wrote:
>>
>> Oops, to keep the quotes it would be
>>
>>   -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
>>
>>
>> ​Would that override the in-code #define statement?​
>>
>>
>> Yes, because the #define is guarded by:
>>
>> #ifndef STD_METHOD_DIR
>>
>> so if it's defined on the command line then it won't get defined in
>> main.c
>>
>> But whether you alter the #define in main.c or set it on the
>> command-line, using %{_libdir} seems better than /usr/lib64.
>>
>> ​How do I append to the CFLAGS at the %configure statement?​
>>
>
> you don't need
>
> export CFLAGS="%{optflags} yourstuff"
> export CXXFLAGS="%{optflags}  yourstuff"
> %configure ...
>
> P.S.: please don't quote the list-footer
>
>
​Thanks.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: when DEP-3 compliant patches in Fedora?

[Neal Gompa]

On Fri, Aug 28, 2015 at 8:44 AM, Florian Weimer  wrote:

> On 08/28/2015 02:11 PM, Marcin Juszkiewicz wrote:
> > Hi
> >
> > I am building software for misc distributions for over 11 years. And so
> > far Fedora packages are the worst of those I played with (mostly
> > OpenEmbedded and Debian).
> >
> > Why? Because patches are mess. Let's take random one:
> >
> > @@ -108,7 +108,7 @@
> >  M = int(max(r, g, b))
> >  m = int(min(r, g, b))
> >  val = (2 * M + r + g + b) / 5
> > -p[:] = (val + r) / 2, (val + g) / 2, (val + b) / 2
> > +#p[:] = (val + r) / 2, (val + g) / 2, (val + b) / 2
> >  if alpha[y][x] >= 250:
> >  alpha[y][x] = 255 - (M - m) * 3 / 4
> >  del pixels
> >
> > Who knows what it does and why? For some reason it has a name '64bitfix'
> > but why it is needed? Did upstream ever saw it? No idea.
> >
> > In Debian (or in OpenEmbedded) it is solved by implementing DEP-3 [1]
>
> In reality, here's what the Debian version of this patch looks like:
>
> <
> http://sources.debian.net/src/monsterz/0.7.1-8/debian/patches/010_64-bit-alignment-issues-with-python2.5.diff/
> >
>
> I'm not sure if it's all that more helpful, to be honest.  It does not
> follow DEP-3, sure, but neither do many other Debian packages.  Even
> some critical server packages still do not have any broken-out patches
> at all.
>
> (In general, if there is no upstream to contribute such fixes to, it's
> probably best not to ship such software at all.)
>
> --
> Florian Weimer / Red Hat Product Security
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​If patches are exported from Mercurial or Git, y​ou'd have all the
information you'd want. However, most people I know aren't working from the
hg/git repository when making packages. That said, I would seriously hope
there would be comments in the spec indicating why the patch is needed. I
know that when I have to make patches to packages, I will put comments
right above the patch source line with information about the patch.



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sane ownCloud alternatives (was: Re: Looking for new maintainer: ownCloud (Fedora / EPEL))

[Neal Gompa]

On Mon, Aug 31, 2015 at 9:54 AM, Martin Kolman  wrote:

> On Mon, 2015-08-31 at 12:13 +0200, Matěj Cepl wrote:
> > On 2015-08-31, 07:05 GMT, Pierre-Yves Chibon wrote:
> > > > Again, if it works for Adam (or anybody else) it is awesome, but
> > > > I would strongly discourage anybody who is not willing to invest
> > > > substntial amount of a sweat equity from packaging the package
> > > > for Fedora/EPEL.
> > >
> > > Not entirely sure if you meant packaging radicale, but if that is
> > > the case,
> > > radicale is already packaged in Fedora and epel 6 and 7.
> >
> > OK, perhaps I was more afraid that many people will read Adam’s
> > email as “ownCloud is crap, Radicale rulez, let’s jump on that
> > wagon everybody!”. Radicale is a minefield, and if your path
> > happens to avoid the disaster than you may feel it works well.
> > However, one step from the safe path and you are doomed (e.g.,
> > using Thunderbird).
> That kinda reminds me - is there some sane ownClooud alternative or at
> least a project aiming to become one ?
>
> While a have seen various projects dubbed "ownCloud alternative" they
> usually just aim for a small part of what ownCloud does - for example
> Seafile seems to target file sync, sharing and file based collaboration
> and the Radicale project mentioned above does just address book
> syncing.
>
> So is there no sane "full ownCloud alternative" that integrates:
> * file sync
> * calendars
> * contacts
> * task lists
> * collaborative document editing
> * plugin/extension API (preferably with support for Python plugins ;-)
> )
> into one UI/account/framework ?
>
> >
> > Best,
> >
> > Matěj
> >
> > --
> > http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
> > GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
> >
> > SCSI is *not* magic. There are *fundamental* *technical*
> > reasons why you have to sacrifice a young goat to your SCSI
> > chain every now and then.
> > -- John F. Woods
> >
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


​As far as I know, ownCloud stands alone in offering the functionality it
does.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Neal Gompa]

On Thu, Sep 10, 2015 at 12:42 PM, Adam Williamson <
adamw...@fedoraproject.org> wrote:

> On Thu, 2015-09-10 at 11:02 -0500, Jason L Tibbitts III wrote:
> > > > > > > "SG" == Stephen Gallagher  writes:
> >
> > SG> Right now, we have a policy that essentially forbids source code
> > SG> from being bundled into a package.
> >
> > Technically we only care if that bundled code is actually compiled
> > in.
>
> I don't think that's the case. The text in the main guidelines page is
> rather broad:
>
> "Fedora packages should make every effort to avoid having multiple,
> separate, upstream projects bundled together in a single package.
> However, when this is unavoidable, packagers must apply for a Bundling
> Exception with the Fedora Packaging Committee."
>
> That just says 'multiple, separate upstream projects' (nothing about
> being 'compiled in'), and implies that absolutely any such case can
> only be included with an explicit 'Bundling Exception'.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
>
​In fact, I had this thrown against me when I tried to package a web
application a few years ago for Fedora. Sure, it led to me packaging
tinymce and tinymce-spellchecker (which are now the banes of my existence
because I don't know what to do with them), but there was nothing I could
do to get the upstream development to make things better. I chugged along
for *three years on that package*, but I eventually gave up on it. I'm
slightly bitter about that, but at the same time
​ I recognize that we need to make the effort to unbundle as much as
possible.

We should definitely inject some more pragmatism into our policy, though.
It's extremely difficult for certain classes of applications to make it
into Fedora because the architecture makes it really difficult to comply
(web applications, sandbox environment application platforms, etc.).

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Neal Gompa]

On Fri, Sep 11, 2015 at 9:03 AM, Zdenek Kabelac  wrote:

> Dne 11.9.2015 v 14:46 Germano Massullo napsal(a):
>
>> I have read the whole discussion and I would like to share my opinion,
>> even if I think it could be a bit off-topic.
>> Given that Fedora community alone, cannot educate every upstream
>> developer about unbundling, and considering that it is a problem that
>> interests all main Linux distributions: I think that Fedora community
>> could (and should) propose to other Linux distribution communities to
>> make a general effort to kindly ask upstream devs to reconsider their
>> work, enforcing unbundling.
>> This will take years, but I think it is a way we should cover.
>>
>>
> How Fedora wants to educate 'upstream' when it rather fails on many levels
> when we talk about library handling.
>
> Fault #1
>
> Fedora badly supports multiple libraries of different version - i.e.
> typically full rebuild of whole repo is made when new library is introduced
> - which is typically quite bad idea (and this is not just because of simple
> version change requires reload of many GB of packages)
> (I've already complained that usage of rawhide & rpmfusion is getting
> silly)
>
>
>
> Fault #2
>
> Version of libraries is wrongly handled on packaging level as well as on
> build level and many library packages are not correctly versioned - so if
> someone believe there is some use of  libname.so.major.minor.patch - for
> RPM it's mostly useless and if symbols are not properly version inside
> library, dependency will simply not work -  and just adding 'constant'
> version string to every symbol inside library will not make this work
>
> Zdenek
>
>
​I get the feeling this is related to Fedora not aggressively using
versioned package names for libraries, or at least enabling some kind
parallel installing capability. SUSE used to follow a policy similar to our
current one, but switched due to the insanity and impracticality. Mageia
also uses a policy almost identical to SUSE's.

For an example, here's SUSE's policy:
https://en.opensuse.org/openSUSE:Shared_library_packaging_policy​

​I've been meaning to ask about why we don't do this for a while now, but
it seems like now is a good of a time as any...​



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Neal Gompa]

On Sun, Sep 13, 2015 at 10:05 AM, Sérgio Basto  wrote:

> On Sex, 2015-09-11 at 22:41 +, Jóhann B. Guðmundsson wrote:
> >
> > On 09/11/2015 09:09 PM, Orion Poplawski wrote:
> > > What does Fedora users gain with "dnf
> > > install rails" or "dnf install ipython" versus "gem install rails" and
> "pip
> > > install ipython"?
> >
> > This indeed is very good question.
>
> I don't think so , if foo package have a security hole , dnf update will
> have an update when pip or gem install don't .
> Other big reason is if you need foo package to build foo2 package ,
> system doesn't know the existence of foo package with pip or gem ,
> neither can force the installation of it when is in a another system.
>
>
>
> > I'm not sure how things are elsewhere in the world but in the case of
> > gem's on a rock in the middle of the north atlantic ocean , everybody is
> > using bundler with nobody wanting to go back to non existing or not
> > current gem's in distributions and or having to manually chase down
> > components and resolve their dependency's.
> >
> > They prefer spending that time actually hacking or drinking beer or both.
> >
> > JBG
>
> --
> Sérgio M. B.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Personally, I think there's still a lot of value to the Linux distribution
model, especially in regards to security and sanity (which unbundling
enables). However, unlike in the early days where distributions worked with
these communities more and had a lot more say in the development of
mechanisms in which libraries are used, newer frameworks, environments,
programming languages are being developed in environments where ​the
developer has (perhaps somewhat rightly) assumed that the distribution
wouldn't care to be an enabler for their platform.

My personal view is that this has happened along the shift from
Mandrake/Red Hat/SUSE to Debian/Ubuntu as the popular distribution
families. The former cares a lot more about upstream integration than the
latter. Take for example Debian's systemd package (I mention this because I
got bitten by it). It actually applies a bunch of patches that effectively
change much of its behavior in regressive ways. As one example,
systemd-udevd is patched to enable a racey behavior because the fix was
considered regressive in functionality. There are tons of other examples
out there. As the Debian/Ubuntu environment became more popular, so did
bundling in non webapp software. It's much more difficult to get software
into a globally usable form in that environment, and their people aren't
pushing as hard as we do for that.

Additionally, it's quite difficult to get new software into the
Debian/Ubuntu main distribution, which practically compels developers to
think in different ways to get what they need to get hacking. Consequently,
we now have languages like Go that don't even have a concept of shared
libraries. Things *must* be statically linked in order to work. Even if a
language like Go did have it, it would be impractical for users of Go
programs to be able to run them on Debian/Ubuntu because the distribution
doesn't pull in new stuff mid-cycle like Fedora, openSUSE, and Mageia do.
Of course, there are tools like the Open Build Service, but they are
cumbersome to use unless you have a large team of people working on it.

And of course, there are purpose-built languages like PHP and JavaScript
that lack built in functionality to support system modules. No one has
developed a model that would enable people to be able to use
system-packaged PHP libraries. With the advent of Node.js and PHP's
(slowly) growing system manipulation capabilities, the onus has
increasingly fallen on the distribution folks to get involved and develop
systems that usefully enable system module models while retaining the
necessary flexibility whenever it's needed.

In the PHP land, Composer somewhat gets you there, because it utilizes PHP
namespacing capabilities to allow modules and libraries from the vendor
directory. However, if someone were to build something that consumed
composer.json/composer.lock data to depsolve at build to fill in Requires
and generate the necessary loader data automatically, we might find PHP
applications becoming easier to deal with. Eventually, it'd be nice to have
something like %composer_install that reads the information, locates them
in the system, and constructs the necessary loader information, and perhaps
even installs the project code, though that might be tricky to pull off.

Node.js' npm is inspired in part by CPAN and PEAR, and I imagine that it
imposes some constraints that make it easier to unbundle, but I don't know
for sure, since I haven't worked with it.

I know that Fedora is working on a new developer portal site, but I don't
know to what extent that Fedora/Red Hat does outreach and collaboration to
development communi

Re: Proposal to reduce anti-bundling requirements

[Neal Gompa]

On Tue, Sep 15, 2015 at 6:08 AM, Ian Malone  wrote:

> On 15 September 2015 at 10:11, Jóhann B. Guðmundsson 
> wrote:
> >
> >
> > On 09/15/2015 08:41 AM, Ian Malone wrote:
> >>
> >> On 14 September 2015 at 16:47, Jóhann B. Guðmundsson <
> johan...@gmail.com>
> >> wrote:
> >>
> >>> They simply have welcomed their new container overlords and are using
> >>> only
> >>> the recommended upstream method for installing for their application (
> >>> pip,gem etc since developers can use the upstream support community for
> >>> those ) in those container images, followed by a strong attitude of use
> >>> it (
> >>> their produced container/vm image not some downstream shipped/provided
> >>> "package" ) or "take your freedom of choice and get lost, we are done
> >>> trying
> >>> to support and play the "X-factor of linux distributions" game. "
> >>>
> >>> And once the "market" has ( started ) taken a stance ( moving away from
> >>> downstream provided package of their components since it does not work
> >>> due
> >>> to the fragmentation in the linux ecosystem ) it's irrelevant what I
> >>> think
> >>> or you think or distributions think or implement locally beside
> providing
> >>> the underlying structure to run their application for the sole purpose
> of
> >>> being relevant as an platform for deployment ( which today is basically
> >>> any
> >>> distribution that ships systemd ).
> >>>
> >> Ultimately that is going to be self limiting, you can only do it while
> >> the most fundamental components are playing by the old rules. I can
> >> think of a few research software packages (in the sense of software
> >> packages, not fedora packages) which are so tied to particular
> >> underlying libraries that getting them to work in the same environment
> >> is a real pain (various ones that bundle underlying libraries and have
> >> their own setups that force that on the whole system because they
> >> can't even get linking right). Now you can containerise that, but
> >> eventually you are going to have to have containers within containers,
> >> and somewhere in there will be a piece of rotting software.
> >>
> >
> > It's self limiting with or without containers is it not? besides there is
> > rotting piece of software littered all across the software galaxy even in
> > Fedora so that's nothing new.
> > ( which is to be expected for a distribution that has more components
> than
> > the require manpower to maintain them properly, inefficient deprecation
> and
> > clean up procedures etc. )
> >
> > In the end containers wont solve all the world problems and there exist
> use
> > cases outside it just as it was with virtualization but at the moment
> it's
> > want the market wants.
> >
>
> What I mean is they're not a magic solution, and this approach is
> beginning to burn up the accumulated benefit of years of discipline
> over this stuff. Currently you can see the software that has problems,
> and an over-dependence on bundling libraries is often a sign that a
> project is a bit flaky, containerisation allows that to be hidden. It
> does have plenty of legitimate uses of course.
>
> --
> imalone
> http://ibmalone.blogspot.co.uk
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​I've already seen people use containers to do things like this, and use it
as an excuse not to make sure the code can gracefully handle newer versions
of dependencies when introduced. At $DAYJOB, I had to push hard for a
program we shipped to continue to not bundle in libraries because there
were people that thought it would magically make things work across
everything. Of course, that's not the case because while the interfaces to
the libraries we used were stable, the interfaces they used weren't
necessarily so.

Those kinds of things start showing up once you start bundling libraries by
default. And then what do you do? Do you keep bundling? Where does it end?
What about namespace conflicts with system versions? Do you alter the code
for all of them (as bundler did) to incorporate it? These are the kinds of
things that make it not a happy place to be...


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaning tinymce, tinymce-spellchecker

[Neal Gompa]

I packaged tinymce and tinymce-spellchecker years ago in an effort to get
another package in. That effort was unsuccessful and I don't really have
the desire to continue "owning" them, as I cannot make sense of it enough
to keep maintaining them. I should have done this a long time ago.

If anyone is interested in taking over tinymce or tinymce-spellchecker,
please file requests for them.

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: llvm 3.7 for rawhide and then f23

[Neal Gompa]

On Mon, Sep 21, 2015 at 6:00 AM, Kamil Paral  wrote:

> > Given that we are now post-Beta for F23, it seems a little late in the
> > cycle to be introducing a new llvm runtime. Is it guaranteed to be
> > backwards-compatible?
>
> OTOH, having OpenGL 4 support in Fedora 23 (at least for certain cards) is
> a strong marketing point. Personally I'm very much looking forward to
> finally playing some of those modern games.
>
>
​Yes please on the OpenGL 4 support! :)​




-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Neal Gompa]

On Tue, Sep 22, 2015 at 5:36 AM, Matej Stuchlik  wrote:

> - Original Message -
> > From: "drago01" 
> > To: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> > Sent: Tuesday, September 22, 2015 11:20:27 AM
> > Subject: Re: Fedora 23 cloud image (and, for that matter, minimal
> anything) bloat
> >
> > On Tue, Sep 22, 2015 at 11:07 AM, Matej Stuchlik 
> wrote:
> > > [...]
> > > When it comes to python3, one way to shave off ~9MiB from
> python3-libs, and
> > > possibly quite a bit more overall, would be to not install both
> optimized
> > > and
> > > unoptimized bytecode, as we do now, but just the unoptimized one (the
> > > performance
> > > hit should be very small).
> >
> > How small is "very small" ? Have you measured it?
> > I don't think 9MB of disk space is worth taking a performance hit for ...
>
> The only difference between unoptimized and "optimized" bytecode should be
> that
> the latter is missing all docstrings, has disable asserts and sets
> __debug__ to False,
> I can't imagine this being significant, performance wise.
>
> That said I do not plan on doing this before I measure the performance
> difference and
> discuss it on python-sig and python-linux.
>
> Also note that it's possibly not just 9MB. For instance python3-boto, also
> on this list, would
> save 4.7MB, python3-pip 2.9MB. In general most python packages could go
> down in size by ~20-30%.
>
> Matt
>
>
​However, this approach would break with Python 3.5 (where pyo data is
merged into *.pyc data), so I would consider it an ill-advised approach
anyway.​ It may work for F23, but it won't work for F24, and then we'd be
back to square one again.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: package naming question: IT++

[Neal Gompa]

On Tue, Sep 22, 2015 at 6:44 AM, Jonathan Wakely  wrote:

> On 22/09/15 10:40 +0200, Marco Driusso wrote:
>
>> So I think we have two options:
>> 1) use 'itpp' as the name of the package, which corresponds to the
>> include dir name, but not to the lib file name (libitpp.so); in this
>>
>
> All libraries start with "lib" but that doesn't mean the package that
> provides a library should do.
>
> Look at the output of rpm -qf /usr/lib64/lib* and you'll see most of
> them are not called "libxxx" just because they install a file called
> "libxxx.so".  e.g. gtk3 installs libgtk-3
>
> The project is called IT++, it installs headers in  and
> installs libitpp.so, so itpp seems the most natural name.
>
>
>
If this wasn't a library that's linked at compile time, I would suggest
also including a "Provides: libitpp" line in there too, but I think that's
not necessary, since packages that would depend on it would use the library
dependency "libitpp.so.8" instead, which there should be an automatic
Provides generated in the itpp package.

Basically, RPM does nice things for you, so you don't have to care (as
much) about this kind of stuff.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Neal Gompa]

On Tue, Sep 22, 2015 at 9:46 AM, Dennis Gilmore  wrote:

> Fedora 23 Beta Release Announcement
> ===
>
> The Fedora 23 Beta is here, right on schedule for our planned
> October final release! Want to help make Fedora 23 be the best
> release ever, or just want to get a sneak peek? Download the
> prerelease from our Get Fedora site and give it a whirl:
>
> -   Get Fedora 23 Beta Workstation — a reliable, user-friendly, and
> powerful operating system for your laptop or desktop computer
> https://getfedora.org/en/workstation/prerelease/
>
> -   Get Fedora 23 Beta Server — make use of the very latest
> server-based technologies available in the open source community
> https://getfedora.org/en/server/prerelease/
>
> -   Get Fedora 23 Beta Cloud — build scale-out computing and utilize
> the next generation of container deployment technology
> https://getfedora.org/en/cloud/prerelease/
>
> -   Get Fedora 23 Beta Spins — alternative desktops for Fedora
> https://spins.fedoraproject.org/prerelease
>
> -   Get Fedora 23 Beta Labs — curated bundles of purpose-driven
> software and content
> https://labs.fedoraproject.org/prerelease
>
>
> What is the Beta release?
> -
>
> The Beta release contains all the exciting features of Fedora 23's
> editions in a form that anyone can help test. This testing, guided
> by the Fedora QA team, helps us target and identify bugs. When
> these bugs are fixed, we make a Beta release available. A Beta
> release is code-complete and bears a very strong resemblance to the
> third and final release. The final release of Fedora 23 is expected
> in October.
>
> We need your help to make Fedora 23 the best yet, so please take
> some time to download and try out the Beta and make sure the things
> that are important to you are working. If you find a bug, please
> report it – every bug you uncover is a chance to improve the
> experience for millions of Fedora users worldwide.
>
> Together, we can make Fedora rock-solid. We have a culture of
> coordinating new features and pushing fixes upstream as much as
> feasible, and your feedback will help improve not only Fedora but
> Linux and free software on the whole.
>
>
> Fedora-Wide Changes
> ---
>
> Fedora 23 includes a number of changes that will improve all of the
> editions. For example, Fedora 23 makes use of compiler flags to
> improve security by "hardening" the binaries against memory
> corruption vulnerabilities, buffer overflows, and so on. This is a
> "behind the scenes" change that most users won't notice through
> normal use of a Fedora edition, but will help provide additional
> system security.
>
> Likewise, Fedora 23 has disabled SSL3 and RC4 by default due to
> known vulnerabilities in the protocols. This means all applications
> that use GNUTLS and OpenSSL libraries have had the SSL3 protocol
> and RC4 cipher disabled.
>
> Fedora 23 comes with the latest version of Mono 4. This means a big
> improvement because we were stuck with an ancient version of Mono
> (2.10) for too long. All packages within Fedora that are based on
> Mono have been adjusted and rebuilt, to target the 4.5 version of
> the .Net framework. Mono 4 does not support solutions targeting
> v1.0, v2.0 or v3.5 of .Net, but usually they can be easily upgraded
> to v4.5.
>
> Fedora 23 Beta also includes support for Unicode 8.0, which
> includes new emojis, and improvements in sorting Unicode text and
> processing non-ASCII URLs.
>
>
> Fedora Server
> -
>
> The Fedora Server release includes a number of interesting changes
> and additions.
>
> The rolekit service now supports setting up three roles. In
> addition to the previously supported Domain Controller (powered by
> FreeIPA abd Database Server (powered by PostgreSQL) roles, Fedora
> Server 23 features a cache server for web applications (powered by
> memcached).
>
> Rolekit can also now be used from the anaconda kickstart by passing
> the `--deferred` arguments to `rolectl`. For example: `rolectl
> deploy domaincontroller --name=example.com --deferred` will
> instruct the system to deploy the Domain Controller role on the
> next boot.
>
> The Cockpit Admin Interface in Fedora Server has several big
> improvements as well.
>
> -   Support for SSH key authentication
> -   Support for configuring user accounts with their authorized keys.
> -   Basic cluster dashboard for driving Kubernetes on Fedora Server
> and Fedora Atomic Host.
> -   Set the imezone for your Fedora Server from the Cockpit User
> Interface (UI).
> -   Cockpit has also been made safe to use with multipath disks.
>
>
> Fedora Workstation
> --
>
> While there's a lot going on under the hood, desktop users are also
> going to find Fedora 23 Beta pretty exciting for all the obvious
> goodness coming to the desktop. The easiest way to experience the
> preview of these technologies is to download and try the Fe

Re: python: dropping the .py files [was Re: Fedora 23 cloud image (and, for that matter, minimal anything)] bloat

[Neal Gompa]

On Fri, Sep 25, 2015 at 3:25 PM, Vít Ondruch  wrote:

> Dne 25.9.2015 v 16:15 Mathieu Bridon napsal(a):
> > (it is invaluable for learning and
> > debugging purposes to be able to read/edit the code).
>
> Come on, this is not an argument. We don't install source code for any
> other language which produces some binary libraries except Python while
> you cannot deny that it would be invaluable for the same purposes. I
> understand you sentiment, but I rather appreciate Orion's position, let
> me quote: "But that said, I'd be happy to install -pysource sub-package
> in order to do it."
>
>
> Vít
>
>
​If it's possible to auto-generate -pysource subpackages like we do with
debuginfo packages, then I would certainly welcome it. If my understanding
is correct, Python module importing works fine with only *.pyc files,
right?​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

createrepo_c and DeltaRPMs...

[Neal Gompa]

Hello all,

I don't know if many have actually tried to use createrepo_c to generate
repositories with DeltaRPMs in it, but it hasn't actually been working
(much to my surprise when trying to use the tool for some repositories at
work). So, I filed a bug about it, like any responsible user of Fedora
stuff[0]

At the beginning of the week, I figured out why it wasn't working and made
a fix. That fix is documented in the bug, and in the GitHub repository pull
request[1]. I hoped that it would be in sometime this week, but it isn't
yet. So, I've decided to push the build I've been using locally to Copr[2],
and provide that for those who may need it until createrepo_c has its
DeltaRPM support enabled again.

Hopefully this will be useful to others who want to use createrepo_c and
have DeltaRPMs in their repositories.

Best wishes to all!

[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1261031
[1]: https://github.com/rpm-software-management/createrepo_c/pull/37
[2]: https://copr.fedoraproject.org/coprs/ngompa/createrepo_c/

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf is completly broken

[Neal Gompa]

On Sun, Sep 27, 2015 at 7:38 AM, Reindl Harald 
wrote:

>
>
> Am 27.09.2015 um 11:27 schrieb Richard W.M. Jones:
>
>> This is quite tiresome.  dnf clearly isn't "completely broken".  It
>> may have a bug, but the correct place to put that is in Bugzilla.
>>
>
> a package manager which pretends "nothing to do" after rm -rf
> /var/cache/dnf/* while there are two fresh builds is by definition broken
>
>
​My question to you is... why are you doing "rm -rf /var/cache/dnf/*"​? Why
not just do "sudo dnf  --refresh"? That forces DNF to actually look
at everything again. If your goal is to clean everything out, then "sudo
dnf clean all" would do the trick too (which also worked in the yum days).


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf is completly broken

[Neal Gompa]

On Sun, Sep 27, 2015 at 11:43 AM, Reindl Harald 
wrote:

>
>
> Am 27.09.2015 um 13:57 schrieb Neal Gompa:
>
>> On Sun, Sep 27, 2015 at 7:38 AM, Reindl Harald wrote:
>>
>> Am 27.09.2015 um 11:27 schrieb Richard W.M. Jones:
>>
>> This is quite tiresome.  dnf clearly isn't "completely broken".
>> It
>> may have a bug, but the correct place to put that is in Bugzilla.
>>
>>
>> a package manager which pretends "nothing to do" after rm -rf
>> /var/cache/dnf/* while there are two fresh builds is by definition
>> broken
>>
>> ​My question to you is... why are you doing "rm -rf /var/cache/dnf/*"​?
>> Why not just do "sudo dnf  --refresh"? That forces DNF to
>> actually look at everything again. If your goal is to clean everything
>> out, then "sudo dnf clean all" would do the trick too (which also worked
>> in the yum days)
>>
>
> how often do you ask that question again?
>
>
​I ask it because sometimes people are doing things that are a fat-finger
away from being really bad when it isn't necessary.​ If there are better
and safer ways to do things, I usually ask why they aren't using them.
Sometimes there's a good reason, other times there isn't. As for the
frequency in which I ask it, usually not that often anymore, but it used to
come up more often.


> a empty "/var/cache/yum|dnf" is a by definition and unconditional empty
> cache


​Perhaps so, but how is DNF supposed to know it's empty? When it hits and
has a file not found? I know that when I do a "dnf clean all", it removes
the solv cache and the metadata cache and writes a file into /var/cache/dnf
that indicates that the data has expired, which prompts DNF to pull
everything on the next run.



> why should i trust a software obviously not working with the basic
> commands right in case of other ones?
>
> ​
​Maybe because it isn't obvious. Frankly, "rm -rf /var/cache/dnf/*" is a
bad idea most of the time. ​Sledgehammers aren't needed here. :)



> and BTW we are not a Ubuntu - what's up with all that "sudo" stuff - if i
> am root then i am root, that's it
>
>
​Erm, we've had the option in Fedora to set up sudo at install time for
quite a while now. I've used it all the time because I rarely need to be
superuser beyond an action or two. Sure, I could just switch to root, but I
don't need to unless I'm doing a lot of actions that require superuser
privileges in quick succession. You can replace it with "su -c" or you can
just use it as a marker to indicate you need to be root for it.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Neal Gompa]

On Wed, Sep 30, 2015 at 8:35 AM, Stephen Gallagher 
wrote:

> Just to circle around here (in case people don't read my reply to the
> FESCo meeting agenda), I'm making the following revised proposal[1] to
> FESCo which may or may not be discussed at today's meeting (given that
> it was submitted late):
>
>
> === Mandatory ===
> * The Fedora Base Working Group has been tasked with defining the base
> platform of Fedora since its inception. As part of this proposal, we
> set a deadline for them to provide (and maintain) a specific list of
> critical path packages. The critical path set is ''not'' required to be
> self-hosting.
> * Working Groups for the separate Editions '''may''' voluntarily add
> packages into the critical path atop the Base WG requirements.
> * All packages in the critical path '''must''' obey the current strict
> bundling rules.
> * All packages not in the critical path whose upstreams allow them to
> be build against system libraries '''must''' be built against system
> libraries.
> * All packages not in the critical path whose upstreams have no
> mechanism to build against system libraries '''must''' be contacted
> publicly about a path to supporting system libraries. If upstream
> refuses, this must be recorded in a link included in the spec file.
> * All packages not in non-critical path whose upstreams have no
> mechanism to build against system libraries '''may''' opt to carry
> bundled libraries, but if they do, they '''must''' include {{{Provides:
> bundled() = }}} in their RPM spec file.
>
> === Strongly Recommended ===
> * Packages in the critical path should be re-reviewed every two years
> (possibly as a Flock workshop) to avoid unintentional divergence from
> the policies.
>
>
>
> [1] https://fedorahosted.org/fesco/ticket/1483
>

​I think this policy is an excellent compromise among all the forces. It
certainly continues to push the unbundling agenda (which is good), but it
makes it easier for us to be flexible and introduce packages that it may be
difficult initially to unbundle. Once it's in Fedora and people are using
it, we can gain some larger degree of influence to push for saner policies
regarding libraries and other kinds of bundled software, on a case by case
basis.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Neal Gompa]

On Wed, Sep 30, 2015 at 10:52 AM, Ralf Corsepius 
wrote:

> On 09/30/2015 04:25 PM, Reindl Harald wrote:
>
>> the opposite is more likely: people trying to avoid the FPC burden now
>>
> can declare it without fearing somebody takes notice and points out a
>> violation
>>
> If they don't care or are not aware about the consequences of their
> bundling?
>
> Like I've said many times before, I feel Fedora needs a serious
> vulnerability in a widespread bundled or static library, such that people
> finally comprehend the harm of bundling.
>
> Ralf
>
>
​Are you saying ​we're doing our job too well, so people don't see the
advantages of the effort anymore?


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf is completly broken

[Neal Gompa]

On Sun, Oct 4, 2015 at 10:24 AM, Germano Massullo <
germano.massu...@gmail.com> wrote:

> In past days I experienced the following problem
> "dnf install" exits if there is a non existing package in the requested
> packages list"
> https://bugzilla.redhat.com/show_bug.cgi?id=1268606
>
>
​Do you have "
strict=True
" in
/etc/dnf/dnf.conf
?​



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Pushing the extra AppData files into Rawhide

[Neal Gompa]

On Wed, Apr 1, 2015 at 4:34 AM, David Timms  wrote:

> On 01/04/15 12:54, Bill Nottingham wrote:
> > David Timms (dti...@iinet.net.au) said:
> ...
> > I thought about trying to reliably parse major/minor/subminor versions in
> > bash, and track it against where things were implemented. But then just
> went
> > the lazy route:
> >
> > if appstream-util --help | grep -q replace-screenshots ; then
> >   ... do stuff here ...
> > fi
>
> Even with little sleep, I find that understandable, Bill. Thanks very much.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Is it alright to just commit it as an extra package source existing within
the package script sources repo (like how we handle patches) until we can
get it upstreamed?​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: qt5 as default?

[Neal Gompa]

On Mon, Apr 20, 2015 at 10:33 PM, Orion Poplawski 
wrote:

> Obviously upstream support will mainly dictate this, but is there any
> distro wide sense yet if one should consider Qt5 as the preferred default
> over Qt4 for a given Fedora release?
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA DivisionFAX: 303-415-9702
> 3380 Mitchell Lane  or...@cora.nwra.com
> Boulder, CO 80301  http://www.cora.nwra.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


​Wouldn't this basically happen when KDE 5 comes into the picture? That's
how it usually goes, I thought.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Mono 4

[Neal Gompa]

On Sun, May 17, 2015 at 11:52 PM, Moez Roy  wrote:

> Mono is updated in Rawhide. Can a proven-packager run a script to
> rebuild all the packages that require mono.
>
> -Thanks.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​With mono-2.x not able to build in Fedora 22, and zero mono-based
applications on the critical path (that is, none are required for any given
spin), could mono 4 be pushed out to F22 in updates along with working
builds of all the mono-dependent packages? I'd rather not see Fedora 22 be
without any mono support for the entirety of its life cycle...


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Mono 4

[Neal Gompa]

On Mon, May 18, 2015 at 4:42 AM, Peter Robinson 
wrote:

> On Mon, May 18, 2015 at 7:06 AM, Neal Gompa  wrote:
> > On Sun, May 17, 2015 at 11:52 PM, Moez Roy  wrote:
> >>
> >> Mono is updated in Rawhide. Can a proven-packager run a script to
> >> rebuild all the packages that require mono.
> >>
> >> -Thanks.
> >> --
> >> devel mailing list
> >> devel@lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/devel
> >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> >
> >
> > With mono-2.x not able to build in Fedora 22, and zero mono-based
> > applications on the critical path (that is, none are required for any
> given
> > spin), could mono 4 be pushed out to F22 in updates along with working
> > builds of all the mono-dependent packages? I'd rather not see Fedora 22
> be
> > without any mono support for the entirety of its life cycle...
>
> No, there's a lot of packages with mono bindings that are on the
> critical path, avahi for example, this is WAY to invasive for F-22.
>
> Peter
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​But the bindings themselves aren't used in the critical path. We don't
even bundle mono into any spin anymore. We couldn't even if we wanted to
because mono-2.x isn't building in F22.​ If these Timotheus and others can
pull together the fixes needed to get all the packages up and going again,
could it not be pushed as a post-F22 release update?


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Mono 4

[Neal Gompa]

On Mon, May 18, 2015 at 8:49 AM, Peter Robinson 
wrote:

> >> >> Mono is updated in Rawhide. Can a proven-packager run a script to
> >> >> rebuild all the packages that require mono.
> >> >>
> >> >> -Thanks.
> >> >> --
> >> >> devel mailing list
> >> >> devel@lists.fedoraproject.org
> >> >> https://admin.fedoraproject.org/mailman/listinfo/devel
> >> >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> >> >
> >> >
> >> > With mono-2.x not able to build in Fedora 22, and zero mono-based
> >> > applications on the critical path (that is, none are required for any
> >> > given
> >> > spin), could mono 4 be pushed out to F22 in updates along with working
> >> > builds of all the mono-dependent packages? I'd rather not see Fedora
> 22
> >> > be
> >> > without any mono support for the entirety of its life cycle...
> >>
> >> No, there's a lot of packages with mono bindings that are on the
> >> critical path, avahi for example, this is WAY to invasive for F-22.
> >>
> >> Peter
> >> --
> >> devel mailing list
> >> devel@lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/devel
> >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> >
> >
> > But the bindings themselves aren't used in the critical path. We don't
> even
>
> They're not used but they're built against the version of mono in Fedora
>
> > bundle mono into any spin anymore. We couldn't even if we wanted to
> because
> > mono-2.x isn't building in F22. If these Timotheus and others can pull
> > together the fixes needed to get all the packages up and going again,
> could
> > it not be pushed as a post-F22 release update?
>
> No, it's extremely unlikely, we generally don't rebase entire dev
> stacks post release for good reason, it's very invasive
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​So we won't have mono stuff working for F22 then?​



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: RFC: LiveUSB Creator Revamped

[Neal Gompa]

It's not nonsense to be able to put Server Product on USB. I've installed
Fedora Server on servers that way myself. Not so sure about Cloud images,
though. Those generally get uploaded to somewhere else to be used.

On Thu, May 28, 2015 at 8:31 AM, Martin Bříza  wrote:

> On Thu, 28 May 2015 14:28:17 +0200, Martin Bříza 
> wrote:
>
>  Hi everyone,
>>
>> for quite a while, I've been working on implementation of a new, revamped
>> UI, designed by Jakub Steiner for the LiveUSB Creator [0]. Currently, me
>> and Luke are slowly moving to merge the changes back into the master branch
>> of the tree. Some stuff is not done, like descriptions of the images or
>> final look of the icons but the really important things are already there.
>>
>> I'm writing here to ask you guys for input on what you think about how it
>> looks like now. I've set up a Copr repository [1] and put a Windows package
>> together [2].
>> I'm open to all kinds of feature requests, bug reports, any kind of input
>> that comes to your minds.
>> The Copr version still contains just udisks support. Udisks2 will be
>> added ASAP (when I rebase my branch against master and build the package
>> again).
>>
>> Specifically, what we'd love to settle is: what to do with the main
>> screen with the three promoted images. Obviously, putting a Server or Cloud
>> Product on a USB drive is a nonsense. One could argue the tool at least
>> downloads the images for you, though.
>>
>> Cheers,
>> Martin
>>
>> [0] https://github.com/lmacken/liveusb-creator/tree/feature/new-ui
>> [1] https://copr.fedoraproject.org/coprs/mbriza/unstable/build/94636/
>> [2a] https://mbriza.fedorapeople.org/liveusb-creator.zip
>> [2b] http://ma.rtinbriza.cz/w/liveusb-creator.zip
>>
>
> Also, to see it without actually installing it, there's just a little bit
> outdated screencap:
> https://mbriza.fedorapeople.org/liveusb-6.ogv
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Reviving Fedora MIPS

[Neal Gompa]

On Mon, Jun 1, 2015 at 4:10 PM, Michal Toman  wrote:

> Greetings everyone,
>
> you might know me from my former work on ABRT, or later Power and s390.
> For the last few months however, I have been collaborating with
> Imagination Technologies to bring back Fedora for MIPS.
>
> A brief history - some effort to bootstrap Fedora for MIPS has been done
> around Fedora 11/12/13, but died afterwards because of lack of interest.
> Even though the RPMs were labelled with mips64el architecture, they were
> using the hybrid n32 ABI with 32-bit pointers and 64-bit data, rather
> than the full 64-bit n64 ABI.
>
> Since we decided to go with n64 rather than n32, we have tried to
> bootstrap the distribution from scratch (well, almost) to see how much
> problems we will run into. I need to say that I was very surprised that
> a majority of packages build fine with no or just minor tweaks to
> specfiles and very few packages do require actual code patching.
>
> Anyway, we have now arrived into a state where Fedora mips64el userspace
> can be booted and played with. I have created a QEMU image [1] and all
> the packages and repositories are available from mipsfedora.imgtec.com
> [2]. I have also created some wiki pages [3] briefly describing what we
> are doing and will continue to expand them in the following days to be
> more detailed.
>
> Apart from mips64el, we have lately started working on 32-bit mipsel, to
> be ran on the Creator CI20 Borad [4]. This is basically 3 months behind
> mips64el so there are no significant results yet, but hopefully will be
> soon.
>
> Future plans are, naturally, to turn MIPS into a fully-fledged secondary
> architecture, deploy koji-shadow, compose releases and do everything
> other secondary archs do. Build hardware is likely to be donated by
> Imagination Technologies.
>
> Any help would be appreciated, especially in the area of kernel, u-boot
> and some specific languages - haskell, erlang, ocaml etc. I have already
> been playing with some of those and there is a list of issues on the wiki.
>
> Hopefully you will like Fedora MIPS back
>
> Regards,
> Michal
>
> [1] http://mipsfedora.imgtec.com/development/22/mips64el/images/20150601/
> [2] http://mipsfedora.imgtec.com/development/22/mips64el/
> [3] https://fedoraproject.org/wiki/Architectures/MIPS/2015Bootstrap
> [4] http://community.imgtec.com/platforms/creator-ci20/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


​I'm very pleased to see Fedora MIPS make a return. While I personally do
not own any MIPS hardware at this time, I'd definitely love to play with
Fedora MIPS if I can get some hardware to use.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: git perl-less build?

[Neal Gompa]

Has anyone written a Python git client based on dulwich
 that could be used in Atomic? If I
remember correctly, we still include Python in Atomic images...

On Wed, Jun 3, 2015 at 7:19 AM, Colin Walters  wrote:

> On Wed, Jun 3, 2015, at 05:23 AM, Petr Stodulka wrote:
> > Hi folks,
> >
> > I have this request on bugzilla [0] for perl-less build of git due to
> > large dependency on Perl modules, which is unwanted for atomic.
> >
> > I am not sure that's good idea.
> > With this change we will create places for error messages about missing
> > perl modules and that's something what we don't want.
>
> I think we could design things so that existing users got git-perl on
> upgrades.
>
> > E.g. missing git-add--interactive will bring one unusable option which
> > will cause error message like this. I have two other bugs where I solve
> > similar troubles. Separate whole git-add doesn't make sense. So if this
> > is good trade off approved by others, OK, we can do that, with notice
> > that some error messages can appear.
>
> Right, I think were this package to exist, users would understand that
> it doesn't have all of the git functionality.
>
> Mainly, what's desired is the ability to do `git clone`, and other
> read-only
> operations like `git checkout`, etc.
>
> WRT Atomic, it's quite common to store Dockerfiles in git.  So here,
> you want to `git clone` + `docker build -t blah .`.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: virt-manager - libappindicator-gtk3 - remmina

[Neal Gompa]

On Wed, Jun 3, 2015 at 6:09 AM, Jaroslav Reznik  wrote:

> - Original Message -
> > On 3 June 2015 at 11:28, Pavel Alexeev < pa...@hubbitus.info > wrote:
> ​​
>
> > If I remember correctly there was a time when people were discussing
> about
> > bringing Unity in Fedora. This did not happen, and actually the library
> is
> > pretty useless as there is no libappindicator consumer right now. I'm not
> > sure it's worth investigating.
>
> ​​
>
>
> For Unity, a bit OT here. Long time ago I had working Unity 2D (nice
> lightweight desktop, a few lines of QML code) for Fedora but then they
> merged it with GTK version it was impossible to continue. Now with switch
> to QML, it might be possible again.
>
> Jaroslav
>
> >
> > Regards,
> > --Simone
> >
> >
> > --
> > You cannot discover new oceans unless you have the courage to lose sight
> of
> > the shore (R. W. Emerson).
> >
> > http://xkcd.com/229/
> > http://negativo17.org/
> >
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


​I had been personally looking into attempting to package Unity as well
(for the challenge!), but I don't think I could maintain the Unity packages
alone. My time is split pretty heavily as it is...​ I'd love to work with
anyone who wants to try to do this again.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Unresponsive maintainer for libiscsi

[Neal Gompa]

Hello all,

I've been trying to get in touch with Paulo Bonzini (bonzini) about the
version of libiscsi in Fedora. I've not been able to get ahold of him by
his Red Hat email address, Bugzilla, or IRC.

Has anyone been able to contact him?

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fedup for F23 and beyond

[Neal Gompa]

Uhh, this might be a stupid question, but what actually prevents us
from integrating the FedUp process into install media (that is, not
live images)? I mean, yeah, it's nice that we can do upgrades online,
but what about when the system we need to upgrade doesn't necessarily
have online access? I'd like to be able to trigger the upgrade
environment from install media (like with a Fedora Server ISO).

Likewise, being able to upgrade from a netinstall ISO by triggering
the environment would be cool too. I don't know how practical it would
be, but it'd be nice if it could be done...

On Wed, Jun 3, 2015 at 7:14 AM, Richard Hughes  wrote:
> On 3 June 2015 at 11:55, Petr Hracek  wrote:
>> Does it mean that using systemd Offline Updates there will not be a "Zero"
>> downtime feature.
>> Except rebooting because of kernel upgrade?
>
> Well, we'll certainly be using offline updates to do the actual transaction.
>
>> Will there be any possibility to inform user if API or ABI issues are
>> discovered after an upgrade?
>
> We won't be able to do the update if there are package conflicts.
> We're aiming to show the apps that are problems and offer to remove
> them, but we can't work magic.
>
>> E.g Database was changed and needs to be fixed after the upgrade?
>
> This needs to be done in the rpm post scripts.
>
>> QT and GUI for upgrade would be awesome?
>> Do you have any draft already?
>
> There are several mockups for GNOME Software already; these need more
> work but are almost there. I'm almost certain we'll be using
> gnome-software at least for the workstation spin although they'll of
> course be a command line tool to schedule to upgrade. I've been asked
> to spend some time to integrate bits of Wills work into PackageKit,
> which I'll start to do in a couple of weeks time.
>
> Richard
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fedup for F23 and beyond

[Neal Gompa]

On Sun, Jun 7, 2015 at 3:30 PM, Will Woods  wrote:
> On Sun, 2015-06-07 at 07:41 -0400, Neal Gompa wrote:
>> Uhh, this might be a stupid question, but what actually prevents us
>> from integrating the FedUp process into install media (that is, not
>> live images)? I mean, yeah, it's nice that we can do upgrades online,
>> but what about when the system we need to upgrade doesn't necessarily
>> have online access? I'd like to be able to trigger the upgrade
>> environment from install media (like with a Fedora Server ISO).
>
> Nothing, really - it's *better* if you have access to the updates repos
> during the upgrade, but it's technically feasible to do the upgrade
> from local media/repos.
>
> To make that work, you'd need:
>
> a) a way to easily enable the media as a repo, and then
> b) run DNF in offline mode (so it's OK with the unreachable network
> repos), and then
> c) ensure that the media will be mounted in the same place after reboot
> (e.g. by adding it to /etc/fstab) so the upgrade can proceed.
>
> (this workflow might even work with the current dnf-plugin-fedup, but I
> haven't tried it...)
>
> So, yeah, the last one is the trickiest part. It's very hard to be
> certain about whether a given filesystem path will be there when you
> reboot. So we either need to just leave that up to the user, or write
> mount units for *everything* on the system and hope that systemd
> figures it out after we reboot.
>
> (It's on my TODO list, since the fedup supported this with --device,
> but.. I just don't have spare time right now.)
>
> -w
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

From my view, if you're booting from an ISO already, wouldn't you be
able to consider that in a state in which you could just do the
upgrade? Couldn't Anaconda just drive DNF through the upgrade process?
When you're booting from the ISO, you've already mounted the local
filesystem and package repositories, so you could use it from there. I
would figure that DNF is already configured for offline mode during
anaconda installs as it is (unless, of course, you tell it to grab
updates from the Internet). Unless I'm missing something really big, I
don't see why you need to reboot when you're already offline and using
the Fedora install media boot environment to do an upgrade.

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

DKMS is not installing the right kernel-devel package

[Neal Gompa]

Hey all,

I've noticed that when dkms is installed, it's not grabbing the right
kernel-devel package as a dependency. Instead, it grabs
kernel-debug-devel. This occurs on Fedora 21 and 22, and I'm not sure
why. If I install kernel-devel first, everything is fine. Otherwise,
it grabs the wrong kernel-devel and DKMS modules don't build.

I filed a bug for it on RHBZ too:
https://bugzilla.redhat.com/show_bug.cgi?id=1228897

Anyone have any idea why this is happening and a way to work around it?

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DKMS is not installing the right kernel-devel package

[Neal Gompa]

On Wed, Jun 10, 2015 at 8:44 AM, Dan Book  wrote:

>
>
> On Wed, Jun 10, 2015 at 2:12 AM, Thorsten Leemhuis 
> wrote:
>
>> Dan Book wrote on 09.06.2015 22:01:
>> > This has also been a problem for several releases with the akmods from
>> > rpmfusion.
>>
>> There was always a problem; there where just less people running into
>> it, because yum/dnf installed "kernel-devel" most of the time, which
>> matched the kernel that was running on most systems; but quite a few
>> x86-32 users ran into problems afaics, as kernel-PAE get's installed
>> there sometimes and hence they needed kernel-PAE-devel.
>>
>> Mosts of the docs and howtos on the net don't mention that, which leads
>> to confused and frustrating users; those in the end might be one of
>> multiple problems why they switch to another distribution.
>>
>> > I think the more "correct" solution (read to the end) would
>> > be to somehow prioritize the kernel-devel package (possibly multiple)
>> > that matches the installed kernel(s).
>>
>> That's not a solution, that's solving the problem for some users and
>> ignoring others (those that use kernel-PAE for example).
>>
>
> "The kernel-devel package that matches the installed kernel(s)" would
> include kernel-PAE-devel matching kernel-PAE, in this fantasy land I
> invented.
>
>
>>
>> > [...]
>>
>> CU
>> thl
>>
>
> -Dan
>
>
>>
>> > On Tue, Jun 9, 2015 at 3:41 PM, Thorsten Leemhuis > > <mailto:fed...@leemhuis.info>> wrote:
>> >
>> > On 09.06.2015 21:04, Neal Gompa wrote:
>> > > I've noticed that when dkms is installed, it's not grabbing the
>> right
>> > > kernel-devel package as a dependency.
>> >
>> > Because that's not possible with ordinary dependencies (might be
>> > possible with soft dependencies [Suggests, Enhances etc]) unless we
>> > change something in the kernel packaging (see below).
>> >
>> > > Instead, it grabs
>> > > kernel-debug-devel. This occurs on Fedora 21 and 22, and I'm not
>> sure
>> > > why.
>> >
>> > Because all kernel*devel package provide kernel-devel iirc.
>> >
>> > > Anyone have any idea why this is happening and a way to work
>> around it?
>> >
>> > Create something like a meta-package "kernel-devel-all" that
>> depends on
>> > all available kernel-devel packages (kernel-devel, kernel-PAE-devel,
>> > kernel-debug-devel, ...) for the arch in question; then add
>> "Requires:
>> > kernel-devel-all" to the akmods and dkms packages. That's messy and
>> > creates overhead for users, but that's afaics the only way it will
>> work
>> > for everyone; otherwise you'll always run into situations where a
>> > kernel-devel package for one kernel variant gets installed while
>> you are
>> > running different variant. Example: You get kernel-devel via some
>> > dependency in akmods or dkms; but you are running kernel-PAE on your
>> > i686 machine, so building modules with akmods or dkms will fail, as
>> > that's requires kernel-PAE-devel.
>> >
>> > HTH; CU, knurd
>> > --
>> > devel mailing list
>> > devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org
>> >
>> > https://admin.fedoraproject.org/mailman/listinfo/devel
>> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>> >
>> >
>> >
>> >
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

What about some kind of virtual provides defined in repos/rpm/somewhere
that would automatically grab the kernel-devel package associated with the
*exact* kernel that is running at the time yum/dnf is installing a program
that depends on it? That would allow for things like DKMS to function
properly, since they'll have what they need to build kernel modules. Going
forward, kernel upgrades will also drag in the appropriate kernel-devel
packages to match, keeping things sane.

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Can soft dependencies help to get the proper kernel-devel packages? (Was: Soft- Re: DKMS is not installing the right kernel-devel package)

[Neal Gompa]

On Fri, Jun 12, 2015 at 8:40 AM, Radek Holy  wrote:

>
>
> - Original Message -
> > From: "Thorsten Leemhuis" 
> > To: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> > Sent: Friday, June 12, 2015 2:19:10 PM
> > Subject: Can soft dependencies help to get the proper kernel-devel
> packages?  (Was: Soft- Re: DKMS is not installing
> > the right kernel-devel package)
> >
> > Josh Boyer wrote on 12.06.2015 13:55:
> > > On Fri, Jun 12, 2015 at 7:24 AM, Neal Gompa 
> wrote:
> > > [...]
> > > As I said, there are no great solutions here.
> >
> > A "works most of the time"-solution would be: Install kernel-devel by
> > default. But I'm not seriously suggesting that, because I fully agree:
> > It's not a great solution.
> >
> > Did anyone(¹) look at soft dependencies in rpm? Can they make our
> > tools install the kernel-devel packages in the variants that match the
> > kernel variants installed? I suspect they are made to solve problems
> > like this, but I'm not sure; and I don't know how far soft dependencies
> > are supported in out current stack of packaging tools.
> >
> > CU
> > knurd
> >
> > (¹) no, I'm not looking at you Josh
>
> AFAIK, it is discussed these days whether weak dependencies can be used to
> express package preferences:
> https://fedoraproject.org/wiki/PackagingDrafts/WeakDependencies IIRC,
> there were some concerns but I don't remember what was the conclusion.
> --
> Radek Holý
> Associate Software Engineer
> Software Management Team
> Red Hat Czech
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Soft/weak dependencies are allowed, according to FESCo
<https://fedorahosted.org/fesco/ticket/1203#comment:6>. The main problem
would be how to structure it to trigger appropriately for this case. Is it
even possible to generate a soft dependency at install time?​ Otherwise,
how do we ensure the "right" one is picked?


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Can soft dependencies help to get the proper kernel-devel packages? (Was: Soft- Re: DKMS is not installing the right kernel-devel package)

[Neal Gompa]

On Fri, Jun 12, 2015 at 9:18 AM, Ralf Corsepius  wrote:
> On 06/12/2015 02:48 PM, Neal Gompa wrote:
>
>> Soft/weak dependencies are allowed, according to FESCo
>
> It doesn't matter much what FESCO says of believes in this case.
>
> ATM, neither is the technical infrastructure is in place (it is evolving)
> nor are impact/consequences clear not are the prototypical use-cases of
> soft/weak-deps clear.
>
> @Thorsten: I do not think, weak/soft-deps are of use in your case.
> Unfortunatley, I do not have solution, either.
>
> Ralf
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

What do you mean by the technical infrastructure for it is lacking?

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Can soft dependencies help to get the proper kernel-devel packages? (Was: Soft- Re: DKMS is not installing the right kernel-devel package)

[Neal Gompa]

On Fri, Jun 12, 2015 at 9:41 AM, Ralf Corsepius  wrote:
> On 06/12/2015 03:23 PM, Neal Gompa wrote:
>>
>> On Fri, Jun 12, 2015 at 9:18 AM, Ralf Corsepius 
>> wrote:
>>>
>>> On 06/12/2015 02:48 PM, Neal Gompa wrote:
>>>
>>>> Soft/weak dependencies are allowed, according to FESCo
>>>
>>>
>>> It doesn't matter much what FESCO says of believes in this case.
>>>
>>> ATM, neither is the technical infrastructure is in place (it is evolving)
>>> nor are impact/consequences clear not are the prototypical use-cases of
>>> soft/weak-deps clear.
>>>
>>> @Thorsten: I do not think, weak/soft-deps are of use in your case.
>>> Unfortunatley, I do not have solution, either.
>
>
>> What do you mean by the technical infrastructure for it is lacking?
>
>
> E.g. /usr/bin/rpm still lacks the --what* command-line options corresponding
> to soft/weak deps.
>
> This issue was mentioned the rpm maintainer in an FPC meeting (IIRC, 3 weeks
> ago), when we were discussing soft/weak-deps but nothing seems to have
> happened since.
>
> Therefore I just (I could have done so earlier, but have been on vacation)
> filed an RFE against rpm:
> https://bugzilla.redhat.com/show_bug.cgi?id=1231247
>
>
> Ralf
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Doesn't libsolv/hawkey handle this within itself, though?


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DKMS is not installing the right kernel-devel package

[Neal Gompa]

On Mon, Jun 15, 2015 at 4:28 AM, Miloslav Trmač  wrote:
>> On Fri, Jun 12, 2015 at 7:24 AM, Neal Gompa  wrote:
>> > What about some kind of virtual provides defined in repos/rpm/somewhere 
>> > that
>> > would automatically grab the kernel-devel package associated with the exact
>> > kernel that is running at the time yum/dnf is installing a program that
>> > depends on it? That would allow for things like DKMS to function properly,
>> > since they'll have what they need to build kernel modules. Going forward,
>> > kernel upgrades will also drag in the appropriate kernel-devel packages to
>> > match, keeping things sane.
>>
>> That would help DKMS at the cost of breaking rpmfusion, koji, or any
>> other scenario where you want to build a kernel module for a kernel
>> that isn't running.  The kernel-devel package is meant to be flexible
>> enough so that you can install it without having anything close to the
>> same kernel version actually running.
>
> I don’t think this would break the model: there would be no changes to 
> packaging kernel-devel, you would still be able to install 
> kernel-devel-$whateverversion, but a magic (dnf install 
> ^kernel-devel-current) or “Requires: ^kernel-devel-current” would refer to a 
> specific one.
>
>
>> It's worth pointing out that the Fedora DKMS package could implement
>> the logic you suggest in DKMS itself.  Then it would either fail if
>> the relevant kernel-devel isn't installed (or kernel-PAE-devel, etc).
>> However, that still doesn't really make it an automated working
>> solution and still requires manual intervention to actually get it
>> installed.
>
> It is actually already fairly easy to usefully (but not reliably) automate 
> this, copying an ugly hack from Chrome packaging, something like
>> %post dkms
>> the_details=…
>> echo 'dnf install kernel-devel-$the_details' | at now+1minute
>
>> As I said, there are no great solutions here.
>
> Yeah, the above is another example of that ☺
>Mirek
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

So why not implement something like kernel-devel-current? DKMS and
those who depend on the running kernel's kernel-devel can use it,
while the rest don't have to...

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DKMS is not installing the right kernel-devel package

[Neal Gompa]

On Mon, Jun 15, 2015 at 8:01 AM, Josh Boyer  wrote:
> On Mon, Jun 15, 2015 at 4:28 AM, Miloslav Trmač  wrote:
>>> On Fri, Jun 12, 2015 at 7:24 AM, Neal Gompa  wrote:
>>> > What about some kind of virtual provides defined in repos/rpm/somewhere 
>>> > that
>>> > would automatically grab the kernel-devel package associated with the 
>>> > exact
>>> > kernel that is running at the time yum/dnf is installing a program that
>>> > depends on it? That would allow for things like DKMS to function properly,
>>> > since they'll have what they need to build kernel modules. Going forward,
>>> > kernel upgrades will also drag in the appropriate kernel-devel packages to
>>> > match, keeping things sane.
>>>
>>> That would help DKMS at the cost of breaking rpmfusion, koji, or any
>>> other scenario where you want to build a kernel module for a kernel
>>> that isn't running.  The kernel-devel package is meant to be flexible
>>> enough so that you can install it without having anything close to the
>>> same kernel version actually running.
>>
>> I don’t think this would break the model: there would be no changes to 
>> packaging kernel-devel, you would still be able to install 
>> kernel-devel-$whateverversion, but a magic (dnf install 
>> ^kernel-devel-current) or “Requires: ^kernel-devel-current” would refer to a 
>> specific one.
>
> I'm not understanding what you're suggesting here.
>
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Essentially, a virtual provides called "kernel-devel-current" would
always resolve to grab the kernel-devel package that corresponds with
the running kernel, be it kernel-PAE, kernel-debug, or kernel (or for
things like the Raspberry Pi 2, kernel-rpi2 or whatever it would be
named). Other things that are safe with "kernel-devel" alone can still
use that, preserving existing behavior when doing so.

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 Self Contained Change: Cloud Systemd Networkd

[Neal Gompa]

I know this is a little off-topic, but why don't we use systemd-networkd in
Fedora proper as a replacement for the ifcfg scripts when NetworkManager
isn't desired? Or at least provide it as an alternative option to
NetworkManager and ifcfg scripts in general?

On Tue, Jun 23, 2015 at 2:34 AM, Jan Kurik  wrote:

> = Proposed Self Contained Change: Cloud Systemd Networkd =
> https://fedoraproject.org/wiki/Changes/Cloud_Systemd_Networkd
>
> Change owner(s): Kushal Das 
>
> We will use systemd-networkd to configure network in Cloud base image.
>
> == Detailed Description ==
> systemd-networkd is a system daemon that manages network configurations.
> It detects and configures network devices as they appear. Cloud base image
> will use systemd-networkd for its network.
>
> systemd is a default package in Fedora, and we can use its latest feature
> to control the network configurations. We will remove the hacks we have in
> the current kickstart file, and use systemd tools for network configuration.
>
> == Scope ==
> * Proposal owners: The Cloud base image.
> * Other developers: N/A (not a System Wide Change)
> * Release engineering: N/A (not a System Wide Change)
> * Policies and guidelines: N/A (not a System Wide Change)
> * Trademark approval: N/A (not needed for this Change)
>
> --
> Jan Kuřík
> ___
> devel-announce mailing list
> devel-annou...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel-announce
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Btrfs as default filesystem for Fedora 23?

[Neal Gompa]

Hey all,

Over the last few months (since Fedora 22 beta's release), I've been using
Btrfs as my daily driver filesystem across a multitude of machines. After
Fedora 22 released, I tried it with RAID 5 and RAID 6 enabled on a few
machines with fantastic success (there aren't even any scary warnings about
being experimental anymore!).

Admittedly, my tests have been specific to my needs (media center storage,
workstations, laptops with SSDs, etc.), but it appears to work really well
now.

Also, with kernel 4.1 imported into rawhide, we've now got performance
improvements for large (>20TB) filesystems (though it's been plenty fast
for my 48TB array).

As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming
the default in Fedora 23
.
At this point, I'm personally convinced that it is certainly ready and
doable for F23.

Perhaps other guys with more experience on this stuff could chime in with
feedback/information/etc, but it feels like we should start the process to
get everything ready for Btrfs being default in Fedora 23.

The question now is: as a distribution, where are we on this? The tools
seem to work, the filesystem appears stable, and I've not been able to
cause the filesystem to corrupt itself with any kind of user error or cause
it to keel over. So, what's left?

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Btrfs as default filesystem for Fedora 23?

[Neal Gompa]

On Tue, Jun 23, 2015 at 2:38 PM, Gerald B. Cox  wrote:

>
> On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa  wrote:
>
>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
>> becoming the default in Fedora 23
>> <https://lists.fedoraproject.org/pipermail/devel/2014-October/203058.html>
>>
>> . At this point, I'm personally convinced that it is certainly ready and
>> doable for F23.
>>
>
> Well actually he said his "plan" was to push for F23.  I've been using
> btrfs raid 6 for several years now and have been lucky I haven't
> encountered any issues - but if you subscribe to the mailing list you'll
> see others haven't been quite as lucky.  I'm sure he'll propose it once he
> believes it is ready.  When proposing a default change it is prudent to be
> cautious. In the meantime it's there to use for early adopters; and the
> more people who test the faster issues will be identified and corrected.
> Just be sure you've taken the proper precautions ;-)
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Certainly, but with none of the features in Btrfs actually emitting scary
"experimental" warnings anymore, and even all features working in btrfs
RAID 5/6 now, I think we should really start pushing it to more people. Or
at least develop some kind of test plan to prove the "worthiness" of using
it as default. We must have something, ne?


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Btrfs as default filesystem for Fedora 23?

[Neal Gompa]

On Tue, Jun 23, 2015 at 4:20 PM, Stephen John Smoogen 
wrote:

> On 23 June 2015 at 14:15, Neal Gompa  wrote:
> > On Tue, Jun 23, 2015 at 2:38 PM, Gerald B. Cox  wrote:
> >>
> >>
> >> On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa  wrote:
> >>>
> >>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
> >>> becoming the default in Fedora 23
> >>>
> >>> . At this point, I'm personally convinced that it is certainly ready
> and
> >>> doable for F23.
> >>
> >>
> >> Well actually he said his "plan" was to push for F23.  I've been using
> >> btrfs raid 6 for several years now and have been lucky I haven't
> encountered
> >> any issues - but if you subscribe to the mailing list you'll see others
> >> haven't been quite as lucky.  I'm sure he'll propose it once he
> believes it
> >> is ready.  When proposing a default change it is prudent to be
> cautious. In
> >> the meantime it's there to use for early adopters; and the more people
> who
> >> test the faster issues will be identified and corrected.  Just be sure
> >> you've taken the proper precautions ;-)
> >>
> >>
> >> --
> >> devel mailing list
> >> devel@lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/devel
> >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> >
> >
> > Certainly, but with none of the features in Btrfs actually emitting scary
> > "experimental" warnings anymore, and even all features working in btrfs
> RAID
> > 5/6 now, I think we should really start pushing it to more people. Or at
> > least develop some kind of test plan to prove the "worthiness" of using
> it
> > as default. We must have something, ne?
> >
>
> So if there are problems who is going to deal with the users, diagnose
> the issues and fix them? Those are going to be the people who will
> need to push for this feature if they think it is ready or not. I
> would start by finding out who they are, talking with them and then
> looking at what time frame they think the feature would be ready.
>
>
> --
> Stephen J Smoogen.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​That is precisely why I'm asking on this list. I don't know who those
people are, and this is really the best place I know of to start contact
and those discussions.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Btrfs as default filesystem for Fedora 23?

[Neal Gompa]

On Tue, Jun 23, 2015 at 9:07 PM, Stephen John Smoogen 
 wrote:

> On 23 June 2015 at 18:40, Neal Gompa  wrote:
> >
> >
> > That is precisely why I'm asking on this list. I don't know who those
> people
> > are, and this is really the best place I know of to start contact and
> those
> > discussions.
> >
> >
>
> My apologies.. my tone was not helpful. You are correct that asking
> here is where to start. I think the groups who would be able to help
> answer would be
>
> 1. Kernel team
> 2. QA team
> 3. Anaconda team
> 4. Workstation/Server/Cloud or just one if it were to be only on one
> product.
>
​
I suspect that engaging every one of those would probably be the right way
to go, since we need to figure out suitability across the board as the
default. Every group would have different criteria, which is why we have
differing filesystem defaults across the board now.

​On Tue, Jun 23, 2015 at 11:28 PM, M. Edward (Ed) Borasky 
 wrote:

> On Tue, Jun 23, 2015 at 1:15 PM, Neal Gompa  wrote:
>
> > Certainly, but with none of the features in Btrfs actually emitting scary
> > "experimental" warnings anymore, and even all features working in btrfs
> RAID
> > 5/6 now, I think we should really start pushing it to more people. Or at
> > least develop some kind of test plan to prove the "worthiness" of using
> it
> > as default. We must have something, ne?
>
> Bingo! We need
>
> a. Pass/fail performance criteria
> b. Pass/fail data loss criteria
> c. Pass/fail security criteria
>
> and code to drive them all. My area of expertise is strictly
> performance. I'd be happy to contribute tests and analysis, although I
> suspect Phoronix may have everything needed.
>
> Let's say a three-way bakeoff - btrfs, ext4 and xfs (since IIRC xfs is
> a default in some RHEL configurations). Let me know if you want me to
> resurrect any of my 2009 stuff on disk performance.
>
>
​Fedora does have Phoronix's test suite in our repositories, so that can be
used for performance tests, but additional specific tests may be of value
too.

I'm not sure how to test for security. As far as I know, encryption is
usually handled by other tools underneath the filesystem (LUKS/dm-crypt) or
above it (ecryptfs).

​A design for data integrity tests would probably be a good idea. A
coworker of mine at my day job and I did some ad-hoc tests with fio in our
spare time to test Btrfs' capabilities on RAID 56 with a multi-disk Btrfs
filesystem and yanked disks, faking damage and replacement to see how the
system recovered using the functions available. From our ad-hoc tests, it
looked pretty damn good. I could talk to him and see if we could formalize
it a bit and bring it to Fedora for use in data integrity tests. But it may
not be enough, so perhaps other folks have some ideas here on data
integrity tests?

On Wed, Jun 24, 2015 at 3:42 AM, Ian Malone  wrote:

> On 24 June 2015 at 04:28, M. Edward (Ed) Borasky  wrote:
> > On Tue, Jun 23, 2015 at 1:15 PM, Neal Gompa  wrote:
> >
> >> Certainly, but with none of the features in Btrfs actually emitting
> scary
> >> "experimental" warnings anymore, and even all features working in btrfs
> RAID
> >> 5/6 now, I think we should really start pushing it to more people. Or at
> >> least develop some kind of test plan to prove the "worthiness" of using
> it
> >> as default. We must have something, ne?
> >
> > Bingo! We need
> >
> > a. Pass/fail performance criteria
> > b. Pass/fail data loss criteria
> > c. Pass/fail security criteria
> >
>
> And advice for end users on btrfs management. People trying it out
> already are going to be more enthusiastic about understanding
> filesystems than the typical user. Also considering whether anything
> will be broken by the change, for example, df reporting inaccurate
> numbers may have knock on effects.
>
>
​I would be happy to help with that. In fact, I actually gave a talk on
Btrfs and using it
<http://files.meetup.com/13432052/mtg2015-06-03-intro-to-btrfs.pdf> at my
local Linux Users' Group in Norwalk, CT and helped other people there to
start using it. Developing a plan and documentation on how to use Btrfs
effectively is probably a good idea.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 33 Self-Contained Change proposal: Drop mod_php

[Neal Gompa]

On Fri, May 29, 2020 at 4:01 AM John M. Harris Jr  wrote:
>
> On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote:
> > Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
> >
> > > Please do not drop mod_php. It is NOT the case that "php-fpm is already
> > > used  but most users of httpd and nginx without any issue."
> >
> >
> > php-fpm is the default configuration for httpd and nginx for few versions
> >
> > nginx ONLY uses php-fpm
> >
> > mod_php is httpd only and prefork mode only
> > so without threaded MPM and without http2 support
> >
> > Please describe issues, I don't have any bug report about this.
> >
> > Remi
>
> Yes, nginx only uses php-fpm. But that has nothing to do with mod_php.
>
> The default doesn't matter, there's absolutely no reason to take away the
> sysadmin's choice here. There are at least 40 servers I personally am
> responsible for where I see no reason to move from mod_php to php-fpm, for
> example. If you don't want to maintain it, I'd be happy to do so. Many third
> party packages expect mod_php, and nearly all documentation for configuring
> httpd for Fedora, CentOS and RHEL goes through the use of mod_php. There is
> just no reason to break this. People who want php-fpm will stick with it, and
> others will continue to use mod_php as we have for the last decade+. Many
> servers do not need http2, or other new features. Many of us have something
> that works, and we'd like to keep it working.
>

As an (oft forgotten!) member of the PHP SIG, I'd like to point out
that part of what we're supposed to do is ship a PHP stack that
minimizes footguns and security nightmares. The PHP stack doesn't make
this easy as it is, and it's been relatively well-known for a while
now that running the interpreter in the same process as the webserver
is a bad idea. Virtually all other programming languages have made
that change in various forms: Python now works through WSGI or ASGI,
Perl uses either PSGI or CGI, Ruby operates through either Unicorn or
Puma typically, and for the past ten years, PHP has strongly
recommended using FastCGI or CGI over mod_php.

It is absolutely a good idea to take away this choice from our builds
when the advice from framework developers, ecosystem experts, and the
upstream developers is to *not* use mod_php. Fedora is in the business
of providing sane defaults and a high-quality package collection. Part
of the quality is removing footguns when they don't need to exist
anymore. We haven't shipped mod_php as the default setup for Apache +
php for several years now, as part of a plan to eventually get rid of
it.



-- 
真実はいつも一つ！/ 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

Re: Proposal: Install gparted to Live installers

[Neal Gompa]

On Thu, Jun 4, 2020 at 12:53 PM Michael Catanzaro  wrote:
>
>
> I don't think we actually have the technical capability to ship it in
> live media without also installing it by default on the installed
> system.
>
> It currently has to run as root, which is not acceptable, so would
> require some work to split out privileged operations into a separate
> backend process and use polkit for authentication. I think it would
> make more sense to focus on improving Disks to do what you need rather
> than rewriting GParted.
>

Not that I wouldn't mind seeing GNOME Disks improved, wouldn't
blivet-gui help here, since it's the same partitioning engine Anaconda
offers, with a gparted-style interface?



-- 
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Neal Gompa]

On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel
 wrote:
>
> On 05.06.2020 09:52, Kevin Kofler wrote:
> > I am opposed to this change. Chromium and Firefox build fine with GCC. I
> > think that a distribution should be built with a consistent toolchain
> > wherever possible.
>
> Clang is much better than GCC nowadays. It has better architecture,
> support lots of optimizations and analyzers.
>
> GCC is a legacy compiler. It should be completely replaced by Clang in
> the nearest future.
>

Having worked in a distribution that uses Clang by default
(OpenMandriva), I can say that this is *not true*. Switching from GCC
to Clang cost OpenMandriva a lot of performance. It also cost them a lot of
security hardening at the compiler level. GCC-built binaries are still
better, and remain better as long as people are continually using and
developing for it.

This change appears to largely be driven by the maintainers of web
browser packages that upstream have no GCC validation and it has to be
done in Fedora downstream. I know Chromium is a lost cause (Google
couldn't possibly care any less than they do now, especially since
they don't even care about Python 2 being EOL), but has anyone talked
to Mozilla about introducing GCC-based CI for Firefox code? I assume
they have a CI infrastructure that's relatively pluggable.

Note that having stuff mix compilers is also a bad idea because LTO is
compatible across the two compilers. If you want to use LTO, you need
to use the same compiler across the chain, or stuff will break.

I would rather see us still *strongly prefer* GCC rather than allowing
this to be freely changeable at a whim.



--
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Neal Gompa]

On Fri, Jun 5, 2020 at 8:26 AM Neal Gompa  wrote:
>
> On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel
>  wrote:
> >
> > On 05.06.2020 09:52, Kevin Kofler wrote:
> > > I am opposed to this change. Chromium and Firefox build fine with GCC. I
> > > think that a distribution should be built with a consistent toolchain
> > > wherever possible.
> >
> > Clang is much better than GCC nowadays. It has better architecture,
> > support lots of optimizations and analyzers.
> >
> > GCC is a legacy compiler. It should be completely replaced by Clang in
> > the nearest future.
> >
>
> Having worked in a distribution that uses Clang by default
> (OpenMandriva), I can say that this is *not true*. Switching from GCC
> to Clang cost OpenMandriva a lot of performance. It also cost them a lot of
> security hardening at the compiler level. GCC-built binaries are still
> better, and remain better as long as people are continually using and
> developing for it.
>
> This change appears to largely be driven by the maintainers of web
> browser packages that upstream have no GCC validation and it has to be
> done in Fedora downstream. I know Chromium is a lost cause (Google
> couldn't possibly care any less than they do now, especially since
> they don't even care about Python 2 being EOL), but has anyone talked
> to Mozilla about introducing GCC-based CI for Firefox code? I assume
> they have a CI infrastructure that's relatively pluggable.
>
> Note that having stuff mix compilers is also a bad idea because LTO is
> compatible across the two compilers. If you want to use LTO, you need
> to use the same compiler across the chain, or stuff will break.
>

Yay thinkos... I mean that LTO is *not* compatible across the two compilers.



-- 
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Neal Gompa]

On Fri, Jun 5, 2020 at 10:24 AM Richard W.M. Jones  wrote:
>
> On Fri, Jun 05, 2020 at 08:27:13AM -0400, Neal Gompa wrote:
> > On Fri, Jun 5, 2020 at 8:26 AM Neal Gompa  wrote:
> > >
> > > On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel
> > >  wrote:
> > > >
> > > > On 05.06.2020 09:52, Kevin Kofler wrote:
> > > > > I am opposed to this change. Chromium and Firefox build fine with 
> > > > > GCC. I
> > > > > think that a distribution should be built with a consistent toolchain
> > > > > wherever possible.
> > > >
> > > > Clang is much better than GCC nowadays. It has better architecture,
> > > > support lots of optimizations and analyzers.
> > > >
> > > > GCC is a legacy compiler. It should be completely replaced by Clang in
> > > > the nearest future.
> > > >
> > >
> > > Having worked in a distribution that uses Clang by default
> > > (OpenMandriva), I can say that this is *not true*. Switching from GCC
> > > to Clang cost OpenMandriva a lot of performance. It also cost them a lot 
> > > of
> > > security hardening at the compiler level. GCC-built binaries are still
> > > better, and remain better as long as people are continually using and
> > > developing for it.
> > >
> > > This change appears to largely be driven by the maintainers of web
> > > browser packages that upstream have no GCC validation and it has to be
> > > done in Fedora downstream. I know Chromium is a lost cause (Google
> > > couldn't possibly care any less than they do now, especially since
> > > they don't even care about Python 2 being EOL), but has anyone talked
> > > to Mozilla about introducing GCC-based CI for Firefox code? I assume
> > > they have a CI infrastructure that's relatively pluggable.
> > >
> > > Note that having stuff mix compilers is also a bad idea because LTO is
> > > compatible across the two compilers. If you want to use LTO, you need
> > > to use the same compiler across the chain, or stuff will break.
> > >
> >
> > Yay thinkos... I mean that LTO is *not* compatible across the two compilers.
>
> Does this change conflict with:
>
> https://fedoraproject.org/wiki/LTOByDefault
>
> ?

Yes. We cannot reasonably implement this and that feature.



-- 
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: swap on zram

[Neal Gompa]

On Fri, Jun 5, 2020 at 2:09 PM John M. Harris Jr  wrote:
>
> On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote:
> > On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel
> >  wrote:
> >
> > >
> > >
> > > On 04.06.2020 22:30, Ben Cotton wrote:
> > >
> > > > Swap is useful, except when it's slow. zram is a RAM drive that uses
> > > > compression. Create a swap-on-zram during start-up. And no longer use
> > > > swap partitions by default.
> > >
> > >
> > >
> > > I'm strongly against this, because zram will replace disk swap and
> > > disable hibernation, which is very useful on laptops.
> >
> >
> > Already discussed in the 'support hibernation' thread.
> >
> > Most laptops today have UEFI Secure Boot enabled by default and
> > therefore hibernation isn't possible. And even when the laptop doesn't
> > have Secure Boot enabled, there's a forest of bugs. It works for some
> > people and not others. It was working for me on one laptop in
> > February, consistently doesn't work now and I haven't gotten a reply
> > yet from upstream about the problem.
>
> It may be true that most laptops have "Secure Boot" enabled, but not those
> running Fedora. We don't have numbers to support that claim, and most devices
> require "Secure Boot" to be disabled,  or to have the mode changed so that it
> accepts new keys, to install Fedora.
>

This is not true. Fedora installs perfectly fine on Secure
Boot-enabled systems without any change to the enrolled keys. Our shim
package is signed by a key that has been required to be trusted for
virtually all x86 PCs for the past several years.

The *only* case where Secure Boot must be disabled for the proper
functioning of a PC today is if you use the NVIDIA proprietary
drivers, because nobody is helping RPM Fusion set up a mechanism to
sign their driver and load the key into the kernel for trust.



-- 
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Neal Gompa]

On Fri, Jun 5, 2020 at 3:50 PM Simo Sorce  wrote:
>
> On Fri, 2020-06-05 at 11:50 -0400, Josh Boyer wrote:
> > On Fri, Jun 5, 2020 at 8:27 AM Neal Gompa  wrote:
> > > On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel
> > >  wrote:
> > > > On 05.06.2020 09:52, Kevin Kofler wrote:
> > > > > I am opposed to this change. Chromium and Firefox build fine with 
> > > > > GCC. I
> > > > > think that a distribution should be built with a consistent toolchain
> > > > > wherever possible.
> > > >
> > > > Clang is much better than GCC nowadays. It has better architecture,
> > > > support lots of optimizations and analyzers.
> > > >
> > > > GCC is a legacy compiler. It should be completely replaced by Clang in
> > > > the nearest future.
> > > >
> > >
> > > Having worked in a distribution that uses Clang by default
> > > (OpenMandriva), I can say that this is *not true*. Switching from GCC
> > > to Clang cost OpenMandriva a lot of performance. It also cost them a lot 
> > > of
> > > security hardening at the compiler level. GCC-built binaries are still
> > > better, and remain better as long as people are continually using and
> > > developing for it.
> > >
> > > This change appears to largely be driven by the maintainers of web
> > > browser packages that upstream have no GCC validation and it has to be
> >
> > Stop this.  This change is driven by the Red Hat toolchain team
> > directly, at their own realization that Fedora's compiler policy is
> > out of line with upstream reality today.  They suggested it, they
> > submitted it, and they are driving it.  Chromium is used as an example
> > only.  Please stop gaslighting why Changes are being submitted in
> > Fedora.
> >
> > Focus on the technical merits all you want.
>
> Hi Josh,
> I think (not sure, but I do) that you misread Neal message as accusing
> the Fedora packagers of Chromium, while I think Neal was blaming
> Chromium upstream for not caring about anything bug clang and making
> life hard downstream.
>

Precisely this. I was not accusing Fedorans of anything. And I still
think that the main motivation for the RH Tools team to propose this
is because of those specific upstreams. This stuff doesn't come out of
a vacuum after all.

> I do not know what is what at this point, but please let's all try to
> read positive intent first and explain each other.
>

I was particularly confused and hurt by the accusation, especially
since I almost never interact with Josh even when I want to. :(



--
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: swap on zram

[Neal Gompa]

On Tue, Jun 9, 2020 at 12:21 AM John M. Harris Jr  wrote:
>
> On Monday, June 8, 2020 5:03:20 PM MST Kevin Kofler wrote:
> > Lennart Poettering wrote:
> >
> > > Well, if you don#t want that behaviour don't use the partition type
> > > UUIDs from the "discoverable partition spec" for your partitions.
> > >
> > > It's how these type uuids are defined:
> > >
> > > https://systemd.io/DISCOVERABLE_PARTITIONS/
> > >
> > > By using these partition type uuids you basically say: "please
> > > automatically mount me, thank you".
> >
> >
> > Uh, no. Any tools that create a partition table will use that UUID if I
> > create a swap partition. That's all that UUID really means: "this is a
> > GNU/Linux swap partition". You unilaterally redefined it to mean that the
> > partition should be automatically mounted even if I deliberately keep it
> > commented out in /etc/fstab. That conflicts with the original definition of
> >  that UUID, which is followed by all the partitioning tools out there.
> > I have had the systemd-auto-gpt-generator masked on all my systems for years
> >  (ever since I found out about its existence), and it will remain that
> > way, sorry.
> >
> > I was really angry back when I looked at the KSensors statistics, noticed
> > that the swap space was twice as large as expected, and realized that
> > systemd has decided to mount my spare swap partition on my SSD behind my
> > back and hence been using up my SSD behind my back for months. Thankfully,
> > the SSD still works years later, looks like I caught it early enough. (You
> > can be glad that you have that warranty disclaimer in the license, in any
> > case…) Ever since, systemd-auto-gpt-generator is masked.
>
> I wonder if we could get that masked in Fedora Server and KDE Spin,
> potentially along with homed, userdb, repart (Who in the world thought this
> was a good idea?), resolved, networkd, systemd-xdg-autostart-generator (you've
> got to be kidding with these generators.. that's the DE's job, not the init
> system), systemd-sysusers, systemd-growfs, and an ever growing list of absurd
> things thrown into an init system.
>
> These things are not discoverable at all. This stuff really needs to stop
> trying to guess what the user/sysadmin wants to do.
>

What makes you think the stuff we had before was discoverable? I can
tell you right now that it definitely wasn't. These newer things have
the advantage of coherent documentation, unified interfaces, and
consistent availability across distributions. The amount of effort to
discover and leverage this functionality is dramatically lower than
what it was a decade ago with the older things. It's a lot easier to
not accidentally break things, too!

I would not support rolling back all this functionality, and I
personally heavily use all of this across my servers and desktops.



--
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: swap on zram

[Neal Gompa]

On Tue, Jun 9, 2020 at 5:25 AM Kevin Kofler  wrote:
>
> John M. Harris Jr wrote:
> > I wonder if we could get that masked in Fedora Server and KDE Spin,
> > potentially along with homed, userdb, repart (Who in the world thought
> > this was a good idea?), resolved, networkd,
> > systemd-xdg-autostart-generator (you've got to be kidding with these
> > generators.. that's the DE's job, not the init system), systemd-sysusers,
> > systemd-growfs, and an ever growing list of absurd things thrown into an
> > init system.
>
> Are all those things enabled in Fedora by default? repart and growfs sound
> particularly scary to me. How do they even decide what partitions they want
> to create or grow? I definitely do not want systemd to mess with my
> partitions, even if it does not delete anything!
>

These modules are used specifically for cloud variants so that on
first boot, we can reconfigure VM images to match the storage setup
requested with cloud-init/ignition. We don't use repart or growfs in
Server Edition or desktop variants.


-- 
真実はいつも一つ！/ 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

Re: Fedora Jam switch to GNOME

[Neal Gompa]

On Wed, Jun 10, 2020 at 12:10 PM  wrote:
>
> Hi all,
>
> I'm considering moving Fedora Jam from KDE Plasma to GNOME. There are
> multiple reasons for this, and I think part of it would be beneficial
> to the overall GNOME and Fedora communities as it would be a way to be
> helping improve the situation in GNOME that exist as the biggest
> objections from the community of musicians and Linux audio enthusiasts
> in the overall community.
>
> The biggest objections are resource usage, since the more resources
> that are in use, the more it tends to interfere with real-time audio
> processes, causing buffer overruns and/or underruns. These overruns and
> underruns are known as Xruns. The fewer Xruns, the better, as Xruns
> cause pops during recording. When doing real-time audio work, you want
> to have as low of latency as possible which requires as small of a
> buffer as possible. The goal is to have a small buffer to get minimal
> latency while avoiding Xruns.
>
> Unfortunately, GNOME has, since 3.0, traditionally interfered with
> these processes and caused Xruns. My goal, by moving Fedora Jam from
> Plasma to GNOME, is to help GNOME improve this situation.
>

I would personally be very sad if Fedora Jam switched from KDE to
GNOME. To me, KDE has always been the home for creatives, and it shows
with the excellent Qt/KDE based software for auditory and visual
creativity. From my perspective, KDE is the environment that creative
people can feel at home in.

> The other reason for switching away from Plasma is the overall negative
> attitude I see from Fedora KDE users and former Fedora KDE
> contributors. It seems to be an attitude against the progress of
> improving the Linux desktop for the better, and simply complaining. I
> know some of this attitude comes from Red Hat dropping KDE from being a
> desktop in REHL, among other changes. That attitude is regressive, and
> does nothing to help the community if all you do is complain. I could
> name names, but for the sake of the "Friends" foundation, I will not.
>

As a Fedora KDE user, I hope I'm not lumped in that bucket. :)

While I am *deeply* disappointed at Red Hat for removing KDE from
RHEL, that is mostly because people seem to think KDE is no good
because Red Hat dropped it rather than it being due to lack of
engineers to support it.

However, one thing I have been very disappointed about is the attitude
of some folks who are not actively involved or contributing to Fedora
KDE disparaging virtually everyone else and the work they do. In
general, it's very much against our tenants, our expectation of being
excellent to each other, and our philosophy as a community.

As a member of many major groups in Fedora, including the KDE SIG, I
do not personally tolerate such disparagement. If there is a technical
foundation for disagreement, then there's something to discuss, but
personally attacking people is never okay. If I have the ability to do
something about it, I will.

> Anyhow, I'd love to see a discussion about this as well as any guidance
> toward making this change. I know there would have to be a new
> kickstart along with Koji pointing toward said kickstart. I could make
> the kickstart, but I think I'd need Koji to look for it.
>

The mechanics of making such a change are fairly straightforward:
change the fedora-jam KS to switch from the KDE base to the GNOME base
in the fedora-kickstarts repository:
https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-jam_kde.ks

You'll need to re-rationalize your customizations on top of that, but
it's doable.


-- 
真実はいつも一つ！/ 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

Re: Fedora Jam switch to GNOME

[Neal Gompa]

On Wed, Jun 10, 2020 at 1:29 PM  wrote:
>
> Hi Kalev,
>
> On Wed, 2020-06-10 at 19:20 +0200, Kalev Lember wrote:
> > Hi Erich,
> >
> > I think this is a great idea -- thanks for getting the discussion
> > started!
> >
> > I've always found it weird that the Jam spin is based on another
> > desktop, different from what Fedora Workstation uses. I think it
> > makes a lot of sense to switch over and try to improve the audio
> > issues in GNOME. We have a lot of Fedora developers who are also
> > GNOME upstream developers and this should create nice synergies.
> >
> > As you may be aware, Wim Taymans has been working on pipewire that
> > Workstation ships with, with the goal of improving the audio and
> > video experience in Fedora Workstation and GNOME and Linux desktop in
> > general. The Jam spin switching to GNOME makes a lot of sense in this
> > context -- that way the Jam users can quickly give feedback on any
> > pipewire issues and feature requests, hopefully improving the overall
> > situation quickly.
> >
> > Good idea and +1 from me.
> >
> > --
> > Kalev
> >
>
> Thanks. That's exactly what has spurred this conversation. I've been
> having conversations in off-list threads about pipewire. I'm highly
> interesed in doing work on this, and I think perhaps this would be the
> best way to collaborate and get feedback from the overall community of
> musicians and audion enthusiasts.
>
> So, perhaps a conversation can be had to create a second kickstart for
> GNOME and keep the KDE kickstart?
>
> But, that's the goal: to get users to give feature requests and issues
> to pipewire. I am not sure that can be adequately accomplished in KDE
> Plasma.
>

I'd be concerned about the viability of PipeWire if we don't have work
going upstream in KDE to leverage it, though. The majority of creative
software is Qt5/KF5 based, and not having PipeWire support first class
in that ecosystem would be massively damaging to the quality of the
offering. That's less about GNOME vs KDE and more about PipeWire still
needing work to be broadly adopted.



-- 
真実はいつも一つ！/ 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

Re: Mailman3

[Neal Gompa]

On Sun, Jun 14, 2020 at 2:39 AM Lars Bjørndal  wrote:
>
> Hello list
>
> It seems that  is managed by Mailman 3.
> In the repo, however, only the core package are available, and not
> the other components. What's the rationale behind that?
>

It's being worked on as part of
https://pagure.io/fedora-infrastructure/issue/8455

If you'd like to help, it would be appreciated! :)



-- 
真実はいつも一つ！/ 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

Re: Easier way to autogenerate Provides?

[Neal Gompa]

On Mon, Jun 15, 2020 at 7:46 AM Richard W.M. Jones  wrote:
>
> We autogenerate RPM Requires/Provides in a few projects, and it's
> quite nice.  eg: supermin-devel has:
>
>   $ rpm -ql supermin-devel
>   /usr/lib/rpm/fileattrs/supermin.attr
>   /usr/lib/rpm/supermin-find-requires
>
> and this means other packages that contain supermin appliances can
> simply put their appliance in a particular directory matching the name
> "*/supermin.d/packages/" and (since they have to BuildRequire
> supermin-devel anyway) RPM will create the correct dependencies
> automatically.
>
> Great!  But ...
>
> I'd like to use it to autogenerate nbdkit plugin Provides, where the
> presence of a file named something like %{_libdir}/nbdkit/plugins/*.so
> should generate a Provides with the plugin name, eg:
>
>   $ rpm -qf --provides /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so
>   nbdkit-curl-plugin = 1.21.7-1.fc33
>
> Right now we list them explicitly:
>
>   https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_161
>
> The problem is all the current plugins exist in nbdkit itself.  nbdkit
> is not a BuildRequire of nbdkit, so it cannot provide RPM rules for
> itself.  Doing so would create a nasty circular dependency that makes
> bootstrapping awkward.
>
> I could create a subpackage with the RPM rules, which is still a
> circular dependency but at least the subpackage would be noarch and
> wouldn't depend on anything else.
>
> This is getting complicated - is there some easier thing I'm missing here?
>

I *think* you can include your own Provides generator script and just
define the macros in the spec like you would in an attr file, and it
should work.

Something like so:

%__nbdkitplugins_provides %{SOURCE11}
%__nbdkitplugins_path ...



-- 
真実はいつも一つ！/ 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

Re: Easier way to autogenerate Provides?

[Neal Gompa]

On Mon, Jun 15, 2020 at 7:49 AM Neal Gompa  wrote:
>
> On Mon, Jun 15, 2020 at 7:46 AM Richard W.M. Jones  wrote:
> >
> > We autogenerate RPM Requires/Provides in a few projects, and it's
> > quite nice.  eg: supermin-devel has:
> >
> >   $ rpm -ql supermin-devel
> >   /usr/lib/rpm/fileattrs/supermin.attr
> >   /usr/lib/rpm/supermin-find-requires
> >
> > and this means other packages that contain supermin appliances can
> > simply put their appliance in a particular directory matching the name
> > "*/supermin.d/packages/" and (since they have to BuildRequire
> > supermin-devel anyway) RPM will create the correct dependencies
> > automatically.
> >
> > Great!  But ...
> >
> > I'd like to use it to autogenerate nbdkit plugin Provides, where the
> > presence of a file named something like %{_libdir}/nbdkit/plugins/*.so
> > should generate a Provides with the plugin name, eg:
> >
> >   $ rpm -qf --provides /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so
> >   nbdkit-curl-plugin = 1.21.7-1.fc33
> >
> > Right now we list them explicitly:
> >
> >   https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_161
> >
> > The problem is all the current plugins exist in nbdkit itself.  nbdkit
> > is not a BuildRequire of nbdkit, so it cannot provide RPM rules for
> > itself.  Doing so would create a nasty circular dependency that makes
> > bootstrapping awkward.
> >
> > I could create a subpackage with the RPM rules, which is still a
> > circular dependency but at least the subpackage would be noarch and
> > wouldn't depend on anything else.
> >
> > This is getting complicated - is there some easier thing I'm missing here?
> >
>
> I *think* you can include your own Provides generator script and just
> define the macros in the spec like you would in an attr file, and it
> should work.
>
> Something like so:
>
> %__nbdkitplugins_provides %{SOURCE11}
> %__nbdkitplugins_path ...
>
>

Blech, I mean:

%global __nbdkitplugins_provides ...
%global __nbdkitplugins_path ...



-- 
真実はいつも一つ！/ 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

Re: Requesting changes/updates to Fedora kde spin page

[Neal Gompa]

On Mon, Jun 15, 2020 at 8:50 AM Harsh Jain  wrote:
>
> Hey everyone ,
> I recently downloaded the fedora kde spin and noticed there were some 
> differences among the apps that came with it . On the site [1] the web 
> browser that comes with the spin is told to be konqueror , but firefox and 
> falkon are included in the spin instead . I think there were other apps that 
> are shown on the site but are not there in the spin .
> I request that the web page be changed/updated to display the correct set of 
> apps .
>
> Should I be filing a bug for this ?
>
> [1]-https://spins.fedoraproject.org/kde/
>

The site is managed here: https://pagure.io/fedora-websites

You can file a bug there. :)



-- 
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Neal Gompa]

On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler  wrote:
>
> Ben Cotton wrote:
> > == Summary ==
> > %cmake macro will be adjusted (-B parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org, besse...@fedoraproject.org,
> > ngomp...@gmail.com
>
> How does this affect the many packages that already build in a separate
> build folder manually? There are even several specfile templates that
> contain the boilerplate for that.
>

If they build a separate folder manually and are already using the
VPATH macros, then there's no change. If they're using a different
structure, we can adapt them to the standard VPATH macros, and do
other adjustments as needed.

> And why is it worth making a potentially incompatible change to the %cmake
> macro when it can already be done with the existing one?
>

Defaults matter. And upstreams complain about us not doing out of tree
builds by default. Some projects even intentionally break in-source
builds and packagers shouldn't struggle to figure out how to do the
right thing in that circumstance.

There's also interest in making it straightforward for bigger CMake
builds to use Ninja instead of Make for performance.

Other RPM distributions have made this change with very little pain,
this just brings us in-line with the rest of the RPM distributions.



-- 
真実はいつも一つ！/ 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

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Neal Gompa]

On Mon, Jun 15, 2020 at 4:11 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground
>
> == Summary ==
> Fedora Workstation 33 uses animate background as default.
>
> == Owner ==
> * Name: [[User:luya| Luya Tshimbalanga]]
> * Email: luyaATfedoraproject.org
> * Product: Workstation
>
>
> == Detailed Description ==
>
> Starting from Release 33, Fedora Workstation uses default animated
> background as a visual showcase. Spins and lab maintainers running on
> desktop environment unable to support animated wallpaper will be able
> to select a different frame from the default (and variant) background.
>
> == Benefit to Fedora ==
>
> Fedora Workstation will showcase its animated background seamlessly as 
> default.
>
> Does this improve specific Spins or Editions?
>   Design Suite Labs, which is based from Workstation, and
> Fedora Silverblue will take advantage of its change. Other Spins and
> Labs will remains unaffected unless their respective maintainers wish
> to use the default animated background.
>
>
> == Scope ==
> * Proposal owners:
> Fedora Workstation may need a slight increase of its ISO file size in
> order to implement the animated backgrounds which are in PNG format.
> Each frame from animation will be selectable from the Background
> Settings.
>

So I'm confused here, does anyone know why the animated wallpapers
don't work in KDE Plasma or any other desktop? I personally love
animated wallpapers and I'd like to see this on my KDE Plasma desktop
too...



-- 
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Neal Gompa]

On Mon, Jun 15, 2020 at 10:25 PM Kevin Kofler  wrote:
>
> Neal Gompa wrote:
> > If they build a separate folder manually and are already using the
> > VPATH macros, then there's no change. If they're using a different
> > structure, we can adapt them to the standard VPATH macros, and do
> > other adjustments as needed.
>
> The common idiom in KDE packages is:
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %{cmake_kf5} ..
> popd
>
> So:
> 1. Are you going to apply this change also to %{cmake_kf5} or just plain
>%cmake?

Yeah, this will get applied to %cmake_kf5 as well.

> 2. If a construct like this is used, I guess we will end up with a VPATH
>inside %{_target_platform}? So the -debugsource package will have a
>nested structure like Russian matrioshka puppets or Chinese boxes?
>

%_vpath_builddir already is set to %_target_platform, so we'd just
swap one for the other.

> > Defaults matter. And upstreams complain about us not doing out of tree
> > builds by default. Some projects even intentionally break in-source
> > builds and packagers shouldn't struggle to figure out how to do the
> > right thing in that circumstance.
>
> It is unfortunate that some upstreams (including parts of KDE) are doing
> this. This is a very pointless and unhelpful thing to do. I see no benefit
> from disallowing in-source builds, it is just a simple special case and
> normally requires no extra code to support.
>

CMake themselves do not recommend doing in-source builds (and they've
already warned that this will eventually stop working). Meson doesn't
even permit it. These days, Autotools is the weird exception that
mostly mandates in-source builds.



-- 
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Neal Gompa]

On Mon, Jun 15, 2020 at 3:48 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
>

This whole process is unnecessary. You're basically asking for
autoremove behavior to occur as part of a distro-sync action. This
boils down to an RFE to the DNF team to extend the distro-sync action
used by system-upgrade to optionally be able to do autoremove at the
same time, and make the system-upgrade plugin actually *do* that by
default.

Let's focus on doing it that way, instead.




--
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Neal Gompa]

On Tue, Jun 16, 2020 at 6:30 AM Iñaki Ucar  wrote:
>
> On Tue, 16 Jun 2020 at 03:09, Neal Gompa  wrote:
> >
> > On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler  wrote:
> > >
> > > How does this affect the many packages that already build in a separate
> > > build folder manually? There are even several specfile templates that
> > > contain the boilerplate for that.
> > >
> >
> > If they build a separate folder manually and are already using the
> > VPATH macros, then there's no change. If they're using a different
> > structure, we can adapt them to the standard VPATH macros, and do
> > other adjustments as needed.
>
> What if you need several builds with several flags? E.g., something like
>
> %build
> %cmake -B flag1 -DFLAG=1
> %make_build -C flag1
> %cmake -B flag2 -DFLAG=2
> %make_build -C flag2
>
> %install
> %make_install -C flag1
> %make_install -C flag2
>

That still works, CMake processes the _last_ -B set, just like Meson.
So if you redefine it later, then everything still works.



-- 
真実はいつも一つ！/ 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

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Neal Gompa]

On Tue, Jun 16, 2020 at 8:46 AM Michael Catanzaro  wrote:
>
> On Tue, Jun 16, 2020 at 2:03 pm, Kamil Paral  wrote:
> > The person proposing this Change should supply some video showcasing
> > this, or a very detailed description, otherwise people will have very
> > varying ideas of how this works and looks.
>
> $ sudo dnf install f32-backgrounds-animated
>
> Select the animated background in gnome-control-center and see for
> yourself how it works. :) It's an XML file that describes state
> transitions between static images. Usually only the colors vary,
> transitioning to darker colors at night, lighter colors in the morning,
> standard colors during daytime.
>
> Fedora has supported this for as long as I remember, we just haven't
> used it by default in a long time. (I think we actually shipped an
> animated background by default once before a while back, though it's
> been long enough that I don't remember that for certain.)
>

We did back in Fedora 7, if I recall correctly. :)


-- 
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Neal Gompa]

On Tue, Jun 16, 2020 at 9:17 AM Kevin Kofler  wrote:
>
> Michael Catanzaro wrote:
> > Kevin, the goal is to *simply* these packages:
> >
> > mkdir -p %{_target_platform}
> > pushd %{_target_platform}
> > %cmake 
> > popd
> >
> > It's four lines. We get to simplify it down to one line. Proposal
> > owners are provenpackagers and say they will try to fix affected
> > packages. Fine by me?
>
> In the real world, it will end up as:
>
> %if 0%{?fedora} > 32 || 0%{?rhel} > 8
> %cmake
> %else
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %cmake ..
> popd
> %endif
>

You can also do "%cmake -B %{_vpath_builddir}" and that will work on
old and new distro releases alike.


-- 
真実はいつも一つ！/ 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

Re: RHEL 9 and modularity

[Neal Gompa]

On Thu, Jun 18, 2020 at 8:45 AM Josh Boyer  wrote:
>
> Hello Fedora Community!
>
> I am a long-time Fedora Community member, and may be familiar to many
> through previous FESCo or devel list discussions and passionate
> debates.  However I write to you today with a different community hat
> on, as a lead Architect for Red Hat Enterprise Linux.  The RHEL
> organization has been following the modularity discussions within
> Fedora, particularly around ELN, and often the question of what plans
> we have for modularity in RHEL 9 has come up.  Our Fedora Project Lead
> and a number of FESCo members have reached out and asked if we can
> provide some perspective here, and I am both happy and excited to have
> that opportunity.
>

Thank you for taking the opportunity to talk to us from the Red Hat
Enterprise Linux perspective. I greatly appreciate that and I hope
others respond kindly to this outreach with constructive feedback.

> As the Fedora Council has pointed out [1], we certainly acknowledge
> there are improvements to be made and have a team already working on
> them.  They recently outlined their plans in conjunction with our
> Product Management team in a Fedora Council call as well [2].  We’re
> continuing to invest time and effort in this packaging solution and
> are confident that the team can deliver against their plan.  It is
> somewhat of a new experience for all of us when Red Hat is direct with
> our product intentions, but we discussed the larger gaps we see with
> usage in RHEL and are putting our efforts towards solving those gaps
> with this plan.
>
> Modularity is important to RHEL and those efforts are already
> underway.  We will be leveraging modularity in RHEL 9 where it most
> makes sense.  This is primarily centered around our Application
> Streams concept, which has been well received by our customer base.
> Providing a consistent but improved experience is the base
> requirement, which allows us to have continuity from RHEL 8 to RHEL 9
> and lowers the hurdle for our customers when upgrading from one major
> version to another.
>

Personally, as a user of the Application Streams stuff in my
custom-built EL containers, it's very nice, and it works well for
providing the flexibility I've needed while having a fully supportable
stack of software. It's a bit less fun on regular servers and VM
environments, but I think this can improve.

> It is always good to push the boundaries and search for better ideas
> and improvements, and that is part of what makes Fedora great.  We are
> doing this in the context of the RHEL 9 release as well, so our near
> term timeline and requirements mean we are working on evolving
> modularity, not a revolution or a replacement.  We are excited by ELN,
> as it presents a possible space to allow those that want to continue
> to iterate on modules a place to do so without necessarily impacting
> the broader Fedora distribution in its entirety.  It is my personal
> hope that we can use that opportunity to improve modules and
> modularity in the open source, Fedora-first way we’d prefer.  Our near
> term effort to improve the existing modularity implementation ahead of
> RHEL 9 needs to occur, and we’d like to do that work in Fedora, rather
> than in closed product development.  Longer term, we are open to
> contributing to a better replacement that meets many of the same
> goals.  This is what makes our distribution ecosystem work well, and
> not having that upstream lessens the value we all get from such
> experimentation in the open.
>

Something that has been bothering me a bit is that there's a lot of
mixed messaging around ELN, even from Red Hatters.

Don't get me wrong: I *absolutely* want ELN to exist, and I like that
we're doing it. I *want* RHEL development happening in Fedora.

But I'm confused about the purpose of ELN. Is it intended to be the
development playground for Red Hatters? Or is it a community
initiative to support Fedora and Red Hat to come together on
developing RHEL? Or is it just a fake-RHEL built on Fedora to minimize
the burden of forking Fedora for making RHEL later? I had personally
hoped that ELN would be an opportunity to allow the Fedora community
and Red Hat to work together on building the future RHEL more
directly, but I am unsure of what it does or what it is for now.

As for iterating on modularity in Fedora through ELN, I think this is
a good idea. I want to see the implementation of modularity fleshed
out and the packager experience improved, and I think the only way to
do that is to actually use it and inflict all the pain on the people
who need it by not permitting weird hacky workarounds to make module
builds work. If something is broken, the standard code path has to be
fixed, and that's how I expect this will work. I'm already aware that
CentOS rebuilds of RHEL are not necessarily straightforward because
many hacky shortcuts are taken to build RHEL content and CentOS does
not have those in place.

However, I am con

Re: RHEL 9 and modularity

[Neal Gompa]

On Sat, Jun 20, 2020 at 5:31 AM Dan Čermák
 wrote:
>
> Josh Boyer  writes:
>
> > On Fri, Jun 19, 2020 at 2:54 PM David Cantrell  wrote:
> >>
> >> On Thu, Jun 18, 2020 at 08:44:39AM -0400, Josh Boyer wrote:
> >> >Hopefully that provides some context and helps FESCo and the wider
> >> >community understand where Red Hat is headed with modularity on the
> >> >Enterprise side.
> >>
> >> Around the idea and concept of modularity... what are the benefits to 
> >> Fedora,
> >> Fedora developers, and Fedora contributors?  Through the various 
> >> discussions
> >> on modularity, nothing solid in this regard has been presented.  If I am
> >> Fedora contributor now, what can modularity do for me?
> >>
> >> Most of the remainder of this thread talks about the problems with the
> >> implementation as it exists today and problems with other known options.
> >> Putting that aside for now, why should Fedora contributors care about
> >> modularity?
> >>
> >> Put another way, what does the developer experience look like for 
> >> modularity?
> >
> > These are good questions, but I feel like there has been about 2+
> > years of discussion and debate about what Fedora could get out of
> > modularity.
>
> Well, a short tl;dr; would certainly help, as I must admit that even
> after 2+ years of discussion I see very little incentive to modularize
> any of my packages.
>
> I see benefits of modularity for CentOS/RHEL, but not so clearly for
> Fedora (except for more special cases like sway, where we have the
> quickly evolving wlroots library and can thus deliver an up to date sway
> even for older Fedora releases).
>

TL;DR benefits of modularity for Fedora:

* Automating build chains for producing artifacts
* Straightforward mechanism of producing non-rpm artifacts using our
existing tooling (modules -> flatpaks/containers/etc.)
* Path to provide alternative versions of stacks that don't natively
multiversion (Nodejs, Perl, PHP, etc.)




--
真実はいつも一つ！/ 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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Neal Gompa]

On Sat, Jun 20, 2020 at 2:16 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Fri, Jun 19, 2020 at 05:11:43PM -0400, Ben Cotton wrote:
> > The %make_build macro enables parallel make builds using the -j option.  In
> > case a package does not build correctly with parallel make, then parallel
> > make will be disabled for that package by redefining the %_smp_mflags macro
> > like this:
> >
> >   %global _smp_mflags -j1
>
> That is rather unwiely, in particular because it's quite common for
> just *some* make invocations to fail in parallel mode. (E.g. the main
> build works, but doc build fails, or install, etc.)
>
> Why not specify the override for the individual invocation:
> %make_build -j1
> %make_install -j1
> %make_build -C docs -j1
>

I think I'd be more comfortable with making all "make %{?_smp_mflags}"
calls switch to "%make_build" and leaving the rest alone.

As for "make DESTDIR=%{buildroot} install" to "%make_install", I'm fine with it.

-- 
真実はいつも一つ！/ 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

Re: RHEL 9 and modularity

[Neal Gompa]

On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr  wrote:
>
> On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
> > TL;DR benefits of modularity for Fedora:
> >
> > * Automating build chains for producing artifacts
> > * Straightforward mechanism of producing non-rpm artifacts using our
> > existing tooling (modules -> flatpaks/containers/etc.)
>
> Both of these have nothing to do with Modularity, and can be done with
> existing RPMs.
>

They have everything to do with Modularity, because that layer is
where that stuff was implemented. Modularity was the result of the
efforts involved with Factory 2.0, which gave us a lot of improvements
in our build infrastructure tooling for the first time since 2007.
Most of that rolled out in 2017, a full ten years after the last
revamp of our infrastructure.

> > * Path to provide alternative versions of stacks that don't natively
> > multiversion (Nodejs, Perl, PHP, etc.)
>
> Modularity doesn't support installing multiple versions of the same software.
> It's one of the key issues with the tech.
>

Modules can be designed to be parallel installable if the underlying
software natively supports that. For example, Python works that way
now, and thus in RHEL there are parallel versions of Python shipped as
modules. It doesn't change the nature of the software.

But it makes it easier to make multiple complete, yet conflicting,
collections of a language stack.



-- 
真実はいつも一つ！/ 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

Re: RHEL 9 and modularity

[Neal Gompa]

On Sat, Jun 20, 2020 at 6:51 PM John M. Harris Jr  wrote:
>
> On Saturday, June 20, 2020 2:40:48 PM MST Neal Gompa wrote:
> > On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr 
> > wrote:
> > >
> > >
> > > On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
> > >
> > > > TL;DR benefits of modularity for Fedora:
> > > >
> > > >
> > > >
> > > > * Automating build chains for producing artifacts
> > > > * Straightforward mechanism of producing non-rpm artifacts using our
> > > > existing tooling (modules -> flatpaks/containers/etc.)
> > >
> > >
> > >
> > > Both of these have nothing to do with Modularity, and can be done with
> > > existing RPMs.
> > >
> > >
> >
> >
> > They have everything to do with Modularity, because that layer is
> > where that stuff was implemented. Modularity was the result of the
> > efforts involved with Factory 2.0, which gave us a lot of improvements
> > in our build infrastructure tooling for the first time since 2007.
> > Most of that rolled out in 2017, a full ten years after the last
> > revamp of our infrastructure.
>
> As far as I'm aware, flatpacks can be created without any Modules. Containers
> certainly can, we've been doing that for over a decade now without them.
>

Yes, they can, but it's a lot more painful to do so. The Modularity
tooling automates reusing the existing RPM packaging we have and
transforms them into building blocks used to produce a Flatpak
application bundle based on the Fedora runtime that people can use
easily on Fedora or any other distribution.

As for containers, the modularity tooling makes it possible to produce
base containers for various language stacks that look and feel like
native stacks provided by Fedora. You've probably never used any of
the RHEL UBI stuff, or any of the language stack containers built on
UBI. Those containers are *fantastic* to work with. My developer
friends find them a literal *joy* to use compared to the alternatives.
I want *that* in Fedora as well, so people can take advantage of the
fresher base and attract more developer-types to our community.

And Modularity makes that stuff possible in a reasonable way.

> > > > * Path to provide alternative versions of stacks that don't natively
> > > > multiversion (Nodejs, Perl, PHP, etc.)
> > >
> > >
> > >
> > > Modularity doesn't support installing multiple versions of the same
> > > software. It's one of the key issues with the tech.
> > >
> > >
> >
> >
> > Modules can be designed to be parallel installable if the underlying
> > software natively supports that. For example, Python works that way
> > now, and thus in RHEL there are parallel versions of Python shipped as
> > modules. It doesn't change the nature of the software.
> >
> > But it makes it easier to make multiple complete, yet conflicting,
> > collections of a language stack.
>
> Where the underlying software already supports it, you don't need Modules to
> do that, just regular old packages. See Python, for example. Modularity is not
> a requirement for that.
>

It is easy without modules for the interpreter, but it's a royal pain
to do it for *everything* (interpreter, language package manager, and
all associated Python modules). Modules provide a straightforward way
to define what that would look like and build that in a repeatable
manner. A Python stack is roughly ~4K source packages, with all kinds
of "fun" ordering requirements. The Modularity tooling provides a way
to do this sort of thing properly. Without Modularity, we've got
*nothing* to do that in a way that's reasonably automated and easy to
maintain.


-- 
真実はいつも一つ！/ 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

Re: RHEL 9 and modularity

[Neal Gompa]

On Sat, Jun 20, 2020 at 7:40 PM Nico Kadel-Garcia  wrote:
>
> On Thu, Jun 18, 2020 at 8:45 AM Josh Boyer  wrote:
>
> Modularity has been an interesting idea on paper, but not worth the
> effort. It should not be used for RHEL 9.
>

This is the wrong place to try to convince Red Hat otherwise. It's
also not going to happen. And frankly, I wouldn't want to.

> > It is always good to push the boundaries and search for better ideas
> > and improvements, and that is part of what makes Fedora great.  We are
> > doing this in the context of the RHEL 9 release as well, so our near
> > term timeline and requirements mean we are working on evolving
> > modularity, not a revolution or a replacement.  We are excited by ELN,
>
> Or: you could discard modularity for RHEL 9. My experience with recent
> Fedora releases and RHEL 8 has been that it's been destabilizing to
> active and to build environments, with no detectable benefit.
>
> Can you, or can anyone else, cite a single issue it has helped with?
> Especially one that was not better resolved with other existing
> deployment tools, such as /etc/alternatives or version pinning?

Yes, actually. The Nodejs and PHP language stacks, as they are shipped
in RHEL/CentOS 8, are tremendously useful in the current form.

From my perspective, there are two major advantages:

* The language stacks are maintained and operate consistently. What I
mean by this is that each variant of the PHP and Nodejs language
stacks presents the same, consistent interface. I can build on those
interfaces with one version and trivially move forward to the next one
when I'm ready.

* The module stream locking feature is useful in that I can trust that
updates will flow freely for those modules, and I don't have to fiddle
with any fragile configuration in the package manager to keep things
going as I desire. It gives me the necessary control to shift at *my*
pace while still trusting that the whole stack is supported.

Are there problems with it? Absolutely. It was a tremendous effort for
me to bring up modularity support in my internal infrastructure. But
once I got there, I was able to realize these benefits for my own
pipelines. There are still problems, and I've filed bug reports about
them and communicated to the various developers about them, but it's
on a "trending upward" path for me.

And I won't lie and say I don't want improvements. I want to be able
to leverage it more. I want improved packager ergonomics. I want
content reusability (builds across multiple modules to be reusable for
modular content instead of building for each module if the
configuration is effectively the same). And so on.

But I will *not* argue to drop it in RHEL (or even Fedora) because I
think it is useful in a lot of ways and has potential to really make
our lives better.



-- 
真実はいつも一つ！/ 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