Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-10-23 Thread Neal Gompa
On Fri, Oct 23, 2020 at 4:05 PM Clement Verna  wrote:
>
>
>
> On Fri, 23 Oct 2020 at 19:55, Neal Gompa  wrote:
>>
>> On Fri, Oct 23, 2020 at 1:07 PM Clement Verna  
>> wrote:
>> >
>> >
>> >
>> > On Fri, 23 Oct 2020 at 17:20, Miro Hrončok  wrote:
>> >>
>> >> On 10/23/20 2:45 PM, Aleksandra Fedorova wrote:
>> >> > Sorry, but you just need to accept the fact that some _early
>> >> > development_ work in Fedora can happen without your decision on it.
>> >>
>> >> I except (and accept) that most of the development work in Fedora happens
>> >> without my decision on it.
>> >>
>> >> I would like you on the other hand to accept that major changes in Fedora 
>> >> are
>> >> coordinated trough the change process and ELN is part of Fedora.
>> >
>> >
>> > This for me highlights the fact that our change process is not adapted to 
>> > all parts of Fedora, in particular parts that need to move faster than the 
>> > 6 month releases. I have in mind the Container base image, Fedora CoreOS 
>> > and ELN, IMO these artefact depends more on the content (the set of 
>> > packages included in them) rather then knowing which version of Fedora 
>> > release they are based on.
>> > The Container base image and Fedora CoreOS are releasing every couple 
>> > weeks, ELN is just a rolling release, I think it is unfair to ask to 
>> > follow a change request system that is design for release that happen 
>> > every 6 months.
>> >
>> > I think we either need a new change request system that is light enough to 
>> > allow these group to iterate and make changes every week or so, or we need 
>> > to trust the people involved in these groups to make the best decisions 
>> > for the Fedora they care about and to also notify anyone that would be 
>> > impacted by these changes.
>> >
>>
>> I think you're missing the point. When ELN was approved, the intent
>> was to build Rawhide in a RHEL-ish configuration continuously.
>
>
> I agree that I missed that point because honestly it does not interest me. 
> What I am seeing is that we have a group of people that are interested in 
> experimenting and doing things differently in Fedora (The ELN SIG) and so far 
> every time their trials are met with a lot of push back. I personally don't 
> care if ELN is not what was communicated originally as long as it brings 
> value to the people working on it, and it does not make other people live 
> worse.
>
> There is so much energy spent pointing fingers at each other, it is really 
> demoralizing :(, Personally If I was in the ELN SIG I would feel unwelcome 
> and unwanted in Fedora, and would really consider just quitting trying to do 
> anything new in this community.
>

This is a very odd way to take this. Yes, Fedora is a great and large
community. And one thing that makes us successful is that we're good
at defining scope and following through on ideas and concepts to
evolve the Linux platform.

But it's not a free-for-all. Using one way everyone expects you to do
things as a way to do something else entirely will take people by
surprise. Even more so when it's completely unprecedented.

For example, even Rawhide gating stuff[1] went through the Changes
process. Setting up ELN itself[2] went through that process. Factory
2.0 and Pagure[3] went through that. And so on.

What you're advocating for is something along the lines of the
openSUSE model where people just announce and do it. In my experience,
that is how you paralyze people into being unable to figure out how to
coordinate and scale change effort, while simultaneously making it
difficult for newer folks to find a path to make their mark in the
community.

And there is *nothing* that stops the Change process for working in a
rolling context other than people don't think of doing it.

There's actually nothing wrong with this idea in itself, because at
the crux of it is that there is a desire to have a side-tag to build
gcc11 with a limited compose to regression test and further evaluate
the development of GCC earlier. This is something I'd like to have
available for more things, and it's a great idea. But there is
basically no reason to stuff it into ELN other than it already exists
as a gap in our existing process. Instead, I'd like to have that
formally approved by FESCo in a way that releng would make a dedicated
side tag for it and allow OSCI to be configured for mini-composes for
the purpose of assisting in GCC development. Then it can be a regular
part of GCC rebase processes.



[1]: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
[2]:

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-10-23 Thread Neal Gompa
On Fri, Oct 23, 2020 at 1:07 PM Clement Verna  wrote:
>
>
>
> On Fri, 23 Oct 2020 at 17:20, Miro Hrončok  wrote:
>>
>> On 10/23/20 2:45 PM, Aleksandra Fedorova wrote:
>> > Sorry, but you just need to accept the fact that some _early
>> > development_ work in Fedora can happen without your decision on it.
>>
>> I except (and accept) that most of the development work in Fedora happens
>> without my decision on it.
>>
>> I would like you on the other hand to accept that major changes in Fedora are
>> coordinated trough the change process and ELN is part of Fedora.
>
>
> This for me highlights the fact that our change process is not adapted to all 
> parts of Fedora, in particular parts that need to move faster than the 6 
> month releases. I have in mind the Container base image, Fedora CoreOS and 
> ELN, IMO these artefact depends more on the content (the set of packages 
> included in them) rather then knowing which version of Fedora release they 
> are based on.
> The Container base image and Fedora CoreOS are releasing every couple weeks, 
> ELN is just a rolling release, I think it is unfair to ask to follow a change 
> request system that is design for release that happen every 6 months.
>
> I think we either need a new change request system that is light enough to 
> allow these group to iterate and make changes every week or so, or we need to 
> trust the people involved in these groups to make the best decisions for the 
> Fedora they care about and to also notify anyone that would be impacted by 
> these changes.
>

I think you're missing the point. When ELN was approved, the intent
was to build Rawhide in a RHEL-ish configuration continuously. This
particular plan defeats what ELN was communicated as because now
there's a major deviation where people can't really participate and
it's not much benefit for everyone else. Moreover, GCC 11 *will* land
in Rawhide, so why not just push it there now? A Change proposal for
GCC 11 still makes sense because it's *for* Fedora in the end too.

> I also would like to point out that the Fedora's project mission statement is 
> to explicitly allow such group to be empowered to make their decisions, at 
> least this is what I understand in the following
>
> ```
> Fedora creates an innovative platform for hardware, clouds, and containers 
> that enables software developers and community members to build tailored 
> solutions for their users.
> ```
>




-- 
真実はいつも一つ!/ 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: F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)

2020-10-23 Thread Neal Gompa
On Fri, Oct 23, 2020 at 1:39 AM Chris Murphy  wrote:
>
> On Thu, Oct 22, 2020 at 5:35 PM Chris Adams  wrote:
> >
> > Once upon a time, Brian C. Lane  said:
> > > I tried :) It ends up that there are users who boot the install.img with
> > > fips=1 which means it needs to be present. It was removed for a bit, and
> > > then I reverted the removal:
> > >
> > > https://github.com/weldr/lorax/commit/3c745aed8d535cae8430161192e0a1505c212c89
> >
> > Ah.  Well, it was worth a try.  Since /boot and /usr/lib/modules are on
> > the same filesystem (in the particular case of the installer rootfs),
> > could they at least be hardlinked?  Although theoretically compressing
> > it should save that space I guess.
>
> Pretty sure mksquashfs automatically dedups files by hardinking them
> but only if we remove the nested ext4 file system. A so-called "plain
> squashfs" image. That's a feature proposal for Fedora 34.
>
> > And there's still the ISO duplication between images/pxelinux and
> > isolinux vmlinuz+initrd.img.  I think the initrd.img might have been
> > different at one point, but it seems like that was a very long time ago.
>
> GRUB and U-BOOT can directly read squashfs. If only syslinux/isolinux
> could do that, everything could be on the squashfs file and deduped.
> I'm not sure it's possible (still) for UEFI and BIOS GRUB to co-exist
> on one media, hence using isolinux to boot BIOS.
>
> ISO 9660 doesn't support hardlinks or symlinks. UDF supports both. But
> I think xorriso doesn't support UDF and also I'm not sure isolinux can
> boot UDF either. GRUB can.
>

Could we just drop syslinux/isolinux and use GRUB there? Other
distributions have done that because of how much of a pain syslinux
is. And it would make the ISO setup a lot less special...



-- 
真実はいつも一つ!/ 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: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-10-22 Thread Neal Gompa
On Thu, Oct 22, 2020 at 1:28 PM Florian Weimer  wrote:
>
> * Miro Hrončok:
>
> >> It is also not the only one, which we can handle through ELN. We were
> >> considering the update of the baseline of the x86 cpu's to be such a
> >> feature, but then it was discarded. The other example would be the
> >> Default Module Streams setup.
> >
> > Should we expect an eln branch for redhat-rpm-config as well, or this
> > is still under consideration?
>
> See the earlier announcement about the z13 baseline change in ELN.  Once
> we have GCC 11 in ELN, further baseline changes may be forthcoming.
> These changes can all be implemented using %{?rhel} conditionals.  I do
> not see a need for a redhat-rpm-config eln branch as the result of these
> requirements.
>
> I do not think the Fedora Change process applies to parts of %{?rhel}
> conditionals that are inactive in Fedora.  In principle, it would make
> my life easier if such changes had to pass public Fesco-like review, but
> I feel it's too late for such a policy change for the Fedora 34 and 35
> cycles.

The Fedora 34 change submission deadline isn't until January, so
there's plenty of time.



-- 
真実はいつも一つ!/ 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: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-10-22 Thread Neal Gompa
On Thu, Oct 22, 2020 at 9:03 AM Vitaly Zaitsev via devel
 wrote:
>
> On 22.10.2020 14:53, Neal Gompa wrote:
> > Why are you not just doing this in Rawhide?
>
> Finally they made the right decision. F32 was built by a completely
> broken version of GCC, full of regressions.
>
> As a Fedora maintainer, I don't want to be a GCC alpha tester again,
> even in Rawhide. Release candidate versions are okay, but trunk is not.
>

That would be bad, since the only reason GCC releases are even as good
as they are is because they get tested with rebuilding the corpus of
Fedora Rawhide software. That's why we merge them in so early in the
first place.



-- 
真実はいつも一つ!/ 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: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-10-22 Thread Neal Gompa
On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova  wrote:
>
> Hi, all,
>
> this is the informational message, no action required.
>
> Upon agreement between gcc maintainers and ELN SIG we would like to
> switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
>
> Though ELN is defined as the buildroot where Fedora Rawhide code is
> rebuilt into EL-like environment, in the ELN proposal we also
> mentioned that ELN can be used to test certain buildroot-related
> features on the side so it doesn't block Fedora Rawhide development.
>
> We think that GCC11 is one such feature, where we can benefit from
> testing it first on a small subset of the Fedora content in a separate
> environment.
>
> We would like to invite everyone to join this effort.
>
> The work is currently tracked on Github:
> https://github.com/fedora-eln/eln/issues/8
>
> Once GCC11 is merged to the eln tag in koji, one would be able to use
> it via, for example, mock or container environment:
> quay.io/fedoraci/fedora:eln-x86_64
>
> For more info on ELN please refer to ELN Docs (as soon as I update
> them, which hopefully happens later today):
>
> https://docs.fedoraproject.org/en-US/eln/
>

Why are you not just doing this in Rawhide? I feel like we've been
screwed now because the whole point was that ELN branches weren't
going to exist, and now we have one in the most important package!




--
真実はいつも一つ!/ 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: [ELN] Missing /usr/bin/bzr in ELN (solved, but open questions)

2020-10-21 Thread Neal Gompa
On Wed, Oct 21, 2020 at 7:45 PM Miro Hrončok  wrote:
>
> On 10/21/20 10:10 PM, Neal Gompa wrote:
> > On Wed, Oct 21, 2020 at 3:00 PM Miro Hrončok  wrote:
> >> 1) Why is breezy not in the ELN compose, but is in the Koji buildroot?
> >
> > It's defined as a buildroot only package:
> > https://github.com/minimization/content-resolver-input/blob/master/configs/eln-buildroot-workload.yaml
>
> I wonder why. git blame suggests this is automated somehow.
>

Hmm, that's a good question...

> >> 2) As pip's maintainer, should I've been notified about the missing 
> >> dependency?
> >
> > Probably not, I think the idea was that ELN SIG would manage that 
> > exclusively.
>
> So I should stop caring?
>

I think you should still care, because in practice I don't think it's
working out that way.

> >> 3) When I fix breezy, should I resubmit the eln rebuilds of pip and Python?
> >>
> >
> > No. Just submit to Rawhide and the Jenkins job for ELN will take care
> > of it for you after it succeeds in Rawhide.
>
> Python and pip succeeded in rawhide already, this is an ELN-only fix.
>

I mean that their bot listens for packages built in Rawhide and
triggers a rebuild automatically for ELN.



-- 
真実はいつも一つ!/ 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: [ELN] Missing /usr/bin/bzr in ELN (solved, but open questions)

2020-10-21 Thread Neal Gompa
On Wed, Oct 21, 2020 at 3:00 PM Miro Hrončok  wrote:
>
> Hello,
>
> I've realized recently that the Python 3.9.0 final build failed in ELN:
>
> python3.9-3.9.0-1.eln104:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1620970
>
> The build failure was:
>File
> "/tmp/tmpip_uvs06/pip-20.1.1-py2.py3-none-any.whl/pip/_vendor/toml/decoder.py",
> line 47
>  TIME_RE = re.compile("([0-9]{2}):([0-9]{2}):([0-9]{2})(\.([0-9]{3,6}))?")
>   ^
> SyntaxError: invalid escape sequence \.
>
> I wondered why did this happen in ELN only and not in Rawhide.
> The reason is: in Rawhide we have pip 20.2.2 which contains the fix of this 
> problem.
>
> So I investigated further and realized pip in ELN was not updated because the
> build is failing. The failure is:
>
>  No matching package to install: '/usr/bin/bzr'
>
> In Fedora, the executable is provided by breezy:
>
> $ repoquery --repo=rawhide -l breezy | grep /usr/bin
> /usr/bin/brz
> /usr/bin/bzr
> /usr/bin/bzr-receive-pack
> /usr/bin/bzr-upload-pack
> /usr/bin/git-remote-brz
> /usr/bin/git-remote-bzr
>
> However, breezy is not included in ELN at all:
>
> $ repoquery --repo=eln-\* breezy
> (nothing)
>
> Despite the fact that it is in:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-43fde95e1f
>
> I can however see it in the ELN Koji buildroot:
>
> $ repoquery --repo=kojieln breezy
> breezy-0:3.0.2-4.eln103.x86_64
>
> Yet it doesn't have the proper file:
>
> $ repoquery --repo=kojieln -l breezy | grep /usr/bin
> /usr/bin/brz
> /usr/bin/bzr-receive-pack
> /usr/bin/bzr-upload-pack
> /usr/bin/git-remote-brz
>
>
> I have discovered this is caused by a Fedora-only %if conditional in the spec 
> file:
>
>
>  # https://fedoraproject.org/wiki/Changes/ReplaceBazaarWithBreezy
>  %if 0%{?fedora} >= 32
>  %bcond_without replace_bzr
>  %else
>  %bcond_with replace_bzr
>  %endif
>
> I'll fix the conditional to make it RHEL-aware. However I have several 
> questions:
>
> 1) Why is breezy not in the ELN compose, but is in the Koji buildroot?

It's defined as a buildroot only package:
https://github.com/minimization/content-resolver-input/blob/master/configs/eln-buildroot-workload.yaml

> 2) As pip's maintainer, should I've been notified about the missing 
> dependency?

Probably not, I think the idea was that ELN SIG would manage that exclusively.

> 3) When I fix breezy, should I resubmit the eln rebuilds of pip and Python?
>

No. Just submit to Rawhide and the Jenkins job for ELN will take care
of it for you after it succeeds in Rawhide.



-- 
真実はいつも一つ!/ 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: glibc troubles in rawhide?

2020-10-20 Thread Neal Gompa
On Tue, Oct 20, 2020 at 6:44 PM Jeff Law  wrote:
>
>
> On 10/20/20 4:41 PM, Jerry James wrote:
> > On Tue, Oct 20, 2020 at 4:38 PM Fabio Valentini  
> > wrote:
> >> Looks like the most recent glibc update in rawhide broke some stuff,
> >> including running dnf:
> > That looks like the same problem I wrote about this morning:
> >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5EL4U5DXCNAA3HSTRPR2XJGJWAGBZ2Z/
> >
> > If I'm reading the change correctly, everything referencing those
> > symbols just needs a rebuild ... but that might be a significant chunk
> > of the distribution.
>
> Upstream glibc is almost certainly putting them back ;-)  I think ftimes
> already went back in and the others are under discussion right now.
>

This is a serious violation of glibc's stated promise of infinite
backwards compatibility. How in the world did this slip through? Can
we use our gating system to kick back builds that are obviously broken
that even the package manager stops working?

Also, I'm surprised that reinstating symbols needs any discussion at
all. The removals obviously have to be reverted, per their own
infinite backwards compatibility promise.



--
真実はいつも一つ!/ 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: Orphaned packages (including pdc-client) looking for new maintainers

2020-10-20 Thread Neal Gompa
On Tue, Oct 20, 2020 at 3:11 PM Miro Hrončok  wrote:
>
> On 10/20/20 9:08 PM, Brandon Nielsen wrote:
> > I would be interested in taking celt071 if nobody else wants it. I use 
> > Mumble
> > regularly.
>
> See also https://pagure.io/fesco/issue/2478#comment-695972
>

I adopted it before seeing this comment, and then orphaned it again
afterward. Whoops!



-- 
真実はいつも一つ!/ 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: Schedule for Wednesday's FESCo Meeting (2020-10-14) + Proposal to Cancel

2020-10-13 Thread Neal Gompa
On Tue, Oct 13, 2020 at 3:01 PM Fabio Valentini  wrote:
>
> Since there are no open tickets that are tagged with "meeting" and no new
> tickets are in need of synchronous discussion IMO, I propose to cancel
> tomorrow's meeting, and would chair next week's meeting instead.
>
> The usual (empty) schedule and announcements are listed below.
>

I'm fine with that.



-- 
真実はいつも一つ!/ 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: Introducing vim-default-editor subpackage - replace nano as a default editor if wanted

2020-10-12 Thread Neal Gompa
On Mon, Oct 12, 2020 at 8:43 AM Vitaly Zaitsev via devel
 wrote:
>
> On 12.10.2020 14:16, Neal Gompa wrote:
> > 2. Having subpackages like this that conflict by name is going to get
> > crazy really fast, so we need a virtual name to make RPM only permit
> > one of them at a time.
>
> Btw, why not to use the Alternatives system for the default text editor,
> like Debian/Ubuntu does?
>

Using alternatives or using swappable packages would achieve the same
result, and the latter doesn't require scriptlets to work 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: Introducing vim-default-editor subpackage - replace nano as a default editor if wanted

2020-10-12 Thread Neal Gompa
On Mon, Oct 12, 2020 at 5:25 AM Zdenek Dohnal  wrote:
>
> Hi,
>
> thanks to Pawel Marciniak's pull request [1] I'm happy to announce
> vim-default-editor subpackage, which easily sets/removes Vim as the
> default editor by installing/uninstalling the subpackage.
>
> Because of nano was selected as a default editor since Fedora 33+, the
> new subpackage conflicts with nano-default-editor subpackage to ensure
> the correct behavior. It means the dnf transaction needs to use
> '--allowerasing' option when installing vim-default-editor is going to
> be installed and nano-default-editor is already installed and vice versa.
>
> Vim's NVR which introduced the subpackage is 2:8.2.1815-2, the build
> containing the subpackage will go into updates for F31+ tomorrow.
>
> Enjoy when it comes to the updates!
>
> [1] https://src.fedoraproject.org/rpms/vim/pull-request/11
>

There are two significant problems with this package:

1. It doesn't work for Fish, since Fish doesn't actually *read*
profile.d (did you look at how nano-default-editor *actually* set
things up?)

2. Having subpackages like this that conflict by name is going to get
crazy really fast, so we need a virtual name to make RPM only permit
one of them at a time.


And really, why do you need this instead of just uninstalling the
nano-default-editor package? Vim is the POSIX default already...



-- 
真実はいつも一つ!/ 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: interest in debuginfod as fedora service

2020-10-05 Thread Neal Gompa
On Mon, Oct 5, 2020 at 11:21 AM Frank Ch. Eigler  wrote:
>
> Hi -
>
> If you never use debuggers, tracing tools, profilers, crash dump
> analysis tools, go ahead and skip this note!
>
> If you're still reading, you know you sometimes need debuginfo for the
> packages you're working with.  And you probably know that
> % sudo debuginfo-install
> is still the official way of getting at it.  But did you know that we
> have a better way?
>
> DEBUGINFOD has been a part of elfutils since late 2019.  It can serve
> debuginfo and source code for your own or for other people's binaries
> to a whole gamut of tools.  (GDB 10 will include support too!)  It
> works across HTTP, no root, no manual debuginfo-install, no big
> downloads, no big deal.  There are even some public servers that have
> some Fedora content already, as well as from other distros.  This page
> covers more about the client & server situation:
>
>   https://sourceware.org/elfutils/Debuginfod.html
>
> You can try it today against our test server:
>
>   % export DEBUGINFOD_URLS=https://debuginfod.elfutils.org/
>   % export DEBUGINFOD_PROGRESS=1
>   % # $debugger-type-tool /path/to/program
>   % eu-stack -v -p $$
>   % stap -L 'process.function("*").call' -c /bin/ls
>
>
> The problem is that Fedora itself doesn't run a server, and our test
> server can afford to carry only a subset of debuginfo/debugsource rpms
> & architectures.  So, fedora developers / users cannot get at all the
> info, or from an official source.  I wonder if it's time to get one
> set up.  If there is interest, I'd be happy to start discussing
> logistics with fedora infrastructure folks.
>

This sounds great, I'd love to see this rolled out. Please file a
ticket in fedora-infrastructure:
https://pagure.io/fedora-infrastructure/issues




--
真実はいつも一つ!/ 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: new dnf mode of listing upgraded packages

2020-10-05 Thread Neal Gompa
On Mon, Oct 5, 2020 at 9:15 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On rawhide:
> $ sudo dnf upgrade
> 
>  PackageArch   Version 
> Repository  Size
> 
> Installing:
>  kernel-corex86_64 5.9.0-0.rc7.20201002git.24.fc34 
> fedora-rawhide-kernel-nodebug
>   
>  32 M
>  kernel-modules x86_64 5.9.0-0.rc7.20201002git.24.fc34 
> fedora-rawhide-kernel-nodebug
>   
>  30 M
> Upgrading:
>  NetworkManager x86_64 1:1.26.2-2.fc34 
> rawhide2.2 M
>  replacing  NetworkManager.x86_64 1:1.26.2-1.fc34.1
>  NetworkManager-libnm   x86_64 1:1.26.2-2.fc34 
> rawhide1.6 M
>  replacing  NetworkManager-libnm.x86_64 1:1.26.2-1.fc34.1
>  NetworkManager-teamx86_64 1:1.26.2-2.fc34 
> rawhide 31 k
>  replacing  NetworkManager-team.x86_64 1:1.26.2-1.fc34.1
>  NetworkManager-wifix86_64 1:1.26.2-2.fc34 
> rawhide 99 k
>  replacing  NetworkManager-wifi.x86_64 1:1.26.2-1.fc34.1
>  OpenIPMI-libs  x86_64 2.0.29-1.fc34   
> rawhide524 k
>  replacing  OpenIPMI-libs.x86_64 2.0.28-6.fc33
>  abrt   x86_64 2.14.4-2.fc34   
> rawhide497 k
>  replacing  abrt.x86_64 2.14.2-5.fc33
>  abrt-addon-ccppx86_64 2.14.4-2.fc34   
> rawhide132 k
>  replacing  abrt-addon-ccpp.x86_64 2.14.2-5.fc33
>  abrt-addon-kerneloops  x86_64 2.14.4-2.fc34   
> rawhide 50 k
>  replacing  abrt-addon-kerneloops.x86_64 2.14.2-5.fc33
>  abrt-addon-pstoreoops  x86_64 2.14.4-2.fc34   
> rawhide 26 k
>  replacing  abrt-addon-pstoreoops.x86_64 2.14.2-5.fc33
>  abrt-addon-vmcore  x86_64 2.14.4-2.fc34   
> rawhide 37 k
>  replacing  abrt-addon-vmcore.x86_64 2.14.2-5.fc33
>  abrt-addon-xorgx86_64 2.14.4-2.fc34   
> rawhide 41 k
>  replacing  abrt-addon-xorg.x86_64 2.14.2-5.fc33
>  abrt-cli   x86_64 2.14.4-2.fc34   
> rawhide 16 k
>  abrt-dbus  x86_64 2.14.4-2.fc34   
> rawhide 72 k
>  replacing  abrt-dbus.x86_64 2.14.2-5.fc33
>
> Most packages that are upgraded are shown as "replacing" themselves. This is
> technically true, but this mode of listing is very verbose. But not all 
> packages
> that are upgraded are listed like that, so I think there must be some 
> additional
> variable I'm missing?
>
> (This output takes a lot of space and is hard to scan quickly, so I can't say 
> I
> quite like it.)
>
> (dnf-4.2.23-2.fc33.noarch)
>

"replacing" stanzas show up if Obsoletes are declared. That's how DNF
tells you something is Obsoleting something else.



-- 
真実はいつも一つ!/ 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: %set_build_flags problem in rpm spec file

2020-10-03 Thread Neal Gompa
On Sat, Oct 3, 2020 at 11:09 AM Vitaly Zaitsev via devel
 wrote:
>
> On 03.10.2020 16:54, Neal Gompa wrote:
> > Instead of "%set_build_flags" or "%?set_build_flags", do the following:
>
> Don't forget about the different package names in Fedora and openSUSE.
>
> Maintainers can use something like this to avoid this problem:
>
> BuildRequires: cmake(Foo)
> BuildRequires: pkgconfig(foo)

That's true. Thankfully this is rarer with -devel packages, but yes,
using generic common names like pkgconfig(), cmake(), perl(), rubygem(), and
others will help this considerably.



--
真実はいつも一つ!/ 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: %set_build_flags problem in rpm spec file

2020-10-03 Thread Neal Gompa
On Sat, Oct 3, 2020 at 10:18 AM Vitaly Zaitsev via devel
 wrote:
>
> On 03.10.2020 15:47, Ruki Wang wrote:
> > I try `%?set_build_flags` and it works fine.
>
> No, it will not. This command will just force RPM to ignore errors. No
> actual build flags will be forwarded.
>
> You need to create separate SPEC files for Fedora and openSUSE.
>

That's not even close to true. The solution is quite simple for
handling openSUSE Leap.

Instead of "%set_build_flags" or "%?set_build_flags", do the following:

%if 0%{?suse_version} && 0%{?suse_version} < 1550
export CFLAGS="%{optflags}"
export CXXFLAGS="%{optflags}"
%else
%set_build_flags
%endif



-- 
真実はいつも一つ!/ 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: %set_build_flags problem in rpm spec file

2020-10-03 Thread Neal Gompa
On Sat, Oct 3, 2020 at 2:45 AM Miro Hrončok  wrote:
>
> On 03. 10. 20 5:04, Ruki Wang wrote:
> > Hi, every one.
> >
> > I am making rpm spec and doing tests on copr.
> >
> > But on opensuse-leap-15.1-*, %set_build_flags still causes some problems.
> >
> >
> > + %set_build_flags
> > /var/tmp/rpm-tmp.9RYL8i: line 32: fg: no job control
> > error: Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)
> >  Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)
> >
> >
> > Links:
> >
> > https://copr.fedorainfracloud.org/coprs/waruqi/xmake/build/1693007/
> > https://download.copr.fedorainfracloud.org/results/waruqi/xmake/opensuse-leap-15.2-x86_64/01693007-xmake/builder-live.log.gz
> > 
> >
> > Buzilla:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1882871
> >
> > Does anyone know the reason for this? Thanks!
> > 
>
> Yes. The reason is openSUSE and Fedora are different. and they don't have our 
> macro.
>
> A quick "make it build" action would be to add ?:
>
>  %?set_build_flags
>
> However, the openSUSE build might not have the proper flags.
>

It's because %set_build_flags was introduced in RPM 4.15, and openSUSE
Leap 15.x uses RPM 4.14. Moreover, openSUSE Leap 15.1 predates the
introduction of the macro even upstream. It was not backported into
openSUSE Leap 15.2 either, so the macro just doesn't exist in openSUSE
Leap yet.

The macro was backported to RHEL 8 during its development, so it
exists there despite it using RPM 4.14 as well.




--
真実はいつも一つ!/ 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: PPC64LE vs PowerPCLE64

2020-10-02 Thread Neal Gompa
On Fri, Oct 2, 2020 at 2:10 PM Greg Hellings  wrote:
>
> I built an RC1 of my package into Rawhide about 3 weeks ago. I tried to build 
> RC3 today, but the build failed on the final steps. My package includes a 
> Python wrapper with Swig and the following file:
>
> %{python3_sitearch}/_Sword.cpython-%{python3_version_nodots}*-%{_arch}-linux-gnu*.so
>
> %{_arch} is "ppc64le" as expected. But today, koji can't find the file. 
> Looking through the logs[0] I see this line in the install step:
>
> copying 
> build/lib.linux-ppc64le-3.9/_Sword.cpython-39-powerpc64le-linux-gnu.so -> 
> /builddir/build/BUILDROOT/sword-1.9.0RC3-1.fc34.ppc64le/usr/lib64/python3.9/site-packages
>
> So now the generated file is "powerpc64le", but %{_arch} is still ppc64le. 
> That .so file gets generated and built during a "python setup.py 
> build/install" process. I'm not naming that file anywhere in the spec. So has 
> the naming scheme intentionally changed for Python bindings? Or is this a bug 
> that I should escalate and report somewhere? Upstream in the library I'm 
> packaging? Upstream in Fedora? Python?
>

This change is from this Fedora 34 Change:
https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names

There are new macros defined for this, indicated here:
https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names#New_Macros



-- 
真実はいつも一つ!/ 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: systemd-resolved

2020-10-01 Thread Neal Gompa
On Thu, Oct 1, 2020 at 11:45 AM Vitaly Zaitsev via devel
 wrote:
>
> On 01.10.2020 16:54, Petr Menšík wrote:
> > But DNS over TLS does not bring you more privacy usually.
>
> It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy
> on you and sell the collected data to third parties.
>

They also completely break most VPNs and corporate network setups, so...



-- 
真実はいつも一つ!/ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-10-01 Thread Neal Gompa
On Thu, Oct 1, 2020 at 9:06 AM Peter Robinson  wrote:
>
> On Thu, Oct 1, 2020 at 1:53 PM Neal Gompa  wrote:
> >
> > On Thu, Oct 1, 2020 at 8:34 AM Peter Robinson  wrote:
> > >
> > > On Wed, Sep 30, 2020 at 9:27 PM Neal Gompa  wrote:
> > > >
> > > > On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher  
> > > > wrote:
> > > > >
> > > > > On 9/30/20 2:19 PM, Michael Catanzaro wrote:
> > > > > > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher  
> > > > > > wrote:
> > > > > >> And what about places where NetworkManager isn't used?  (Just 
> > > > > >> because
> > > > > >> it's the default, doesn't mean that it's used everywhere.)
> > > > > >
> > > > > > NetworkManager is used everywhere by default. If you want to 
> > > > > > disable it,
> > > > > > you have to do manual work to do that. If you do manual work to 
> > > > > > disable
> > > > > > NetworkManager, you can also do manual work to disable 
> > > > > > systemd-resolved.
> > > > >
> > > > > Indeed, but I was responding to this:
> > > > >
> > > > > On 9/30/20 1:35 PM, Neal Gompa wrote:
> > > > >  > Please, no more package splitting. And NetworkManager is used 
> > > > > across
> > > > >  > all variants of Fedora, so resolved should be installed in all 
> > > > > places
> > > > >  > where NetworkManager is used.
> > > > >
> > > > > Which (to my reading) says that because NetworkManager is the 
> > > > > *default*
> > > > > everywhere (even though it can be uninstalled), systemd-resolved 
> > > > > should
> > > > > be *installed* everywhere (and should not be uninstallable).  I don't
> > > > > follow that logic.
> > > >
> > > > There are not a ton of advantages for splitting it, since it's only a
> > > > couple of binaries averaging 2MB with a few unit files. Given that we
> > > > require it for default NetworkManager configurations now, there's not
> > > > a lot of value in making that complicated. Splitting has a cost too,
> > > > in the form of extra metadata, upgrade paths, etc.
> > > >
> > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
> > > > variants, as shipped today, *MUST* use NetworkManager.
> > > > NetworkManager's configuration will use resolved as a local resolver.
> > > > Anything baked into an OSTree cannot be removed anyway.
> > > >
> > > > And like it or not, all our legacy network configuration mechanisms
> > > > are deprecated and *will be removed eventually*.
> > > >
> > > > Literally the only reason networkd was split out was because Fedora
> > > > CoreOS was chainsawing it out at image build time and making it
> > > > impossible for people to use it. To be frank, I do not want more
> > > > permutations this low in the stack. It makes life incredibly difficult
> > > > for figuring out working network setups.
> > > >
> > > > My reply was aimed at Peter saying he'd like to not ship resolved, and
> > > > I'm saying that we should *not* do that, because it makes things even
> > > > harder and more complicated.
> > >
> > > So you're saying that if this doesn't work for IoT and actively causes
> > > deployment problems, potentially across millions of devices, we can't
> > > turn it off, change the option and have to basically suck it up and
> > > deal with all the problems? Well that makes Fedora completely
> > > unappealing and I feel against the project of people being able to
> > > choose. It will make people go elsewhere and frankly so will I!
> >
> > If there are problems with our configuration for your use-case, the
> > idea is to actually report the issue and/or fix them. It's not like we
> > don't have systemd engineers in Fedora. If there is some fatal flaw,
> > then I would *love* to know, but so far, there doesn't seem to be one.
> >
> > And throwing around "millons of devices" as a reason for me to care
> > about IoT more than anything else is not a good way for me to care
> > more about you. You can't prove it to me, and it's easy to prove more
> > devices *not* running it than running it.
>
> It's not a way "to care about I

Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-10-01 Thread Neal Gompa
On Thu, Oct 1, 2020 at 8:34 AM Peter Robinson  wrote:
>
> On Wed, Sep 30, 2020 at 9:27 PM Neal Gompa  wrote:
> >
> > On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher  wrote:
> > >
> > > On 9/30/20 2:19 PM, Michael Catanzaro wrote:
> > > > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher  
> > > > wrote:
> > > >> And what about places where NetworkManager isn't used?  (Just because
> > > >> it's the default, doesn't mean that it's used everywhere.)
> > > >
> > > > NetworkManager is used everywhere by default. If you want to disable it,
> > > > you have to do manual work to do that. If you do manual work to disable
> > > > NetworkManager, you can also do manual work to disable systemd-resolved.
> > >
> > > Indeed, but I was responding to this:
> > >
> > > On 9/30/20 1:35 PM, Neal Gompa wrote:
> > >  > Please, no more package splitting. And NetworkManager is used across
> > >  > all variants of Fedora, so resolved should be installed in all places
> > >  > where NetworkManager is used.
> > >
> > > Which (to my reading) says that because NetworkManager is the *default*
> > > everywhere (even though it can be uninstalled), systemd-resolved should
> > > be *installed* everywhere (and should not be uninstallable).  I don't
> > > follow that logic.
> >
> > There are not a ton of advantages for splitting it, since it's only a
> > couple of binaries averaging 2MB with a few unit files. Given that we
> > require it for default NetworkManager configurations now, there's not
> > a lot of value in making that complicated. Splitting has a cost too,
> > in the form of extra metadata, upgrade paths, etc.
> >
> > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
> > variants, as shipped today, *MUST* use NetworkManager.
> > NetworkManager's configuration will use resolved as a local resolver.
> > Anything baked into an OSTree cannot be removed anyway.
> >
> > And like it or not, all our legacy network configuration mechanisms
> > are deprecated and *will be removed eventually*.
> >
> > Literally the only reason networkd was split out was because Fedora
> > CoreOS was chainsawing it out at image build time and making it
> > impossible for people to use it. To be frank, I do not want more
> > permutations this low in the stack. It makes life incredibly difficult
> > for figuring out working network setups.
> >
> > My reply was aimed at Peter saying he'd like to not ship resolved, and
> > I'm saying that we should *not* do that, because it makes things even
> > harder and more complicated.
>
> So you're saying that if this doesn't work for IoT and actively causes
> deployment problems, potentially across millions of devices, we can't
> turn it off, change the option and have to basically suck it up and
> deal with all the problems? Well that makes Fedora completely
> unappealing and I feel against the project of people being able to
> choose. It will make people go elsewhere and frankly so will I!

If there are problems with our configuration for your use-case, the
idea is to actually report the issue and/or fix them. It's not like we
don't have systemd engineers in Fedora. If there is some fatal flaw,
then I would *love* to know, but so far, there doesn't seem to be one.

And throwing around "millons of devices" as a reason for me to care
about IoT more than anything else is not a good way for me to care
more about you. You can't prove it to me, and it's easy to prove more
devices *not* running it than running it.

To be blunt, I expect IoT environments to be even worse off in terms
of taking advantage of DNS security features, because they often rely
on mobile networks (which don't have any DNS security features) and
tunnels over those networks (which usually can't have DNS security
features) to communicate. In that case, what we have here would
improve that situation for you.




--
真実はいつも一つ!/ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-09-30 Thread Neal Gompa
On Wed, Sep 30, 2020 at 5:27 PM Matthew Miller  wrote:
>
> On Wed, Sep 30, 2020 at 04:32:07PM -0400, Neal Gompa wrote:
> > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
> > > (rpm)ostree variants are Fedora variants - please don't using phrasing 
> > > implying otherwise.
> > > IOW you just say: *all* Fedora variants use NetworkManager.
> > They are not the same. Regular Fedora is considerably more
> > customizable post-installation than OSTree-based variants. That's why
> > I made that point.
>
> "All Fedora variants, both with ostree and without..." maybe? OSTree-based
> variants are also "regular Fedora".
>

I would only even remotely consider agreeing with that premise for
Silverblue. Neither Fedora CoreOS nor Fedora IoT qualify for that, in
my view, since they completely sidestep the normal release engineering
process, don't use the same repositories, and have the power to
include and exclude packages from the total available package set at
their leisure.

There is no expectation with those variants that anything you do will
necessarily show up there. Heck, Fedora CoreOS is reverting a
system-wide change in its variant (SQLite rpmdb), and had previously
also reverted another one (cgroup v2). The merits of those changes
aside, this makes the experience materially different than everything
else we have.



-- 
真実はいつも一つ!/ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-09-30 Thread Neal Gompa
On Wed, Sep 30, 2020 at 4:45 PM PGNet Dev  wrote:
>
> anyone else more confused?
>
> On 9/30/20 1:26 PM, Neal Gompa wrote:
> > And like it or not, all our legacy network configuration mechanisms
> > are deprecated and*will be removed eventually*.
>
> is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct 
> dependency on systemd-resolved -- considered 'legacy'?
>

NetworkManager never uses networkd. But when I refer to legacy setups,
I'm referring to everything related to ifcfg and legacy
network-scripts.

Insofar as networkd goes, I wouldn't consider it legacy, but I would
also not consider it contemporary, since nobody bothered to make it
useful enough to support all the cases that Wicked and NetworkManager
support.

> > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
>  variants, as shipped today, *MUST* use NetworkManager.
>
> how 'bout I turn the question around ...
>
> what specific steps must be done POST- F32->F32 upgrade to
>
> (1) not use NetworkManager
> (2) not use systemd-resolved
>
> (3) return/preserve local configs for systemd-networkd & 'enterprise' 
> (own resolver) DNS configs?
>
> ?
>
> > Regular Fedora is considerably more
>  customizable post-installation than OSTree-based variants.
>
> For those of us that don't live the lingo, it's not exactly clear 
> what 'Regular Fedora' is.
>

Regular Fedora variants are installed via normal package management
actions and have full granularity. RPM-OSTree reduces the granularity
of the operating system to a singular image that you layer on top. But
you cannot pull out stuff from the image.

> Is there _any_ variant of Fedora that's immune now, and in the planned 
> future, from "use NetworkManger" and (therefore) systemd-resolved?
>
> Iiuc, the upgrades WILL install/enable systemd-resolved; that's post-upgrade 
> maintenance that apparently needs to be planned for -- as long as its still 
> doable.
>
> If/when does that no longer remain an option?

If you want to deactivate resolved and use something else, you can.
If you did so prior to upgrading to F33, that will persist. Only users
who didn't do anything would get the change.

One of my machines uses dnsmasq and I have NetworkManager configured
with that. That does not break with the move to Fedora 33, since I set
it up that way. I'm sure there are people running NetworkManager with
unbound, and I expect that to stay working 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-09-30 Thread Neal Gompa
On Wed, Sep 30, 2020 at 4:29 PM Colin Walters  wrote:
>
>
>
> On Wed, Sep 30, 2020, at 4:26 PM, Neal Gompa wrote:
>
> > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
>
> (rpm)ostree variants are Fedora variants - please don't using phrasing 
> implying otherwise.
>
> IOW you just say: *all* Fedora variants use NetworkManager.
>

They are not the same. Regular Fedora is considerably more
customizable post-installation than OSTree-based variants. That's why
I made that point.


-- 
真実はいつも一つ!/ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-09-30 Thread Neal Gompa
On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher  wrote:
>
> On 9/30/20 2:19 PM, Michael Catanzaro wrote:
> > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher  wrote:
> >> And what about places where NetworkManager isn't used?  (Just because
> >> it's the default, doesn't mean that it's used everywhere.)
> >
> > NetworkManager is used everywhere by default. If you want to disable it,
> > you have to do manual work to do that. If you do manual work to disable
> > NetworkManager, you can also do manual work to disable systemd-resolved.
>
> Indeed, but I was responding to this:
>
> On 9/30/20 1:35 PM, Neal Gompa wrote:
>  > Please, no more package splitting. And NetworkManager is used across
>  > all variants of Fedora, so resolved should be installed in all places
>  > where NetworkManager is used.
>
> Which (to my reading) says that because NetworkManager is the *default*
> everywhere (even though it can be uninstalled), systemd-resolved should
> be *installed* everywhere (and should not be uninstallable).  I don't
> follow that logic.

There are not a ton of advantages for splitting it, since it's only a
couple of binaries averaging 2MB with a few unit files. Given that we
require it for default NetworkManager configurations now, there's not
a lot of value in making that complicated. Splitting has a cost too,
in the form of extra metadata, upgrade paths, etc.

Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
variants, as shipped today, *MUST* use NetworkManager.
NetworkManager's configuration will use resolved as a local resolver.
Anything baked into an OSTree cannot be removed anyway.

And like it or not, all our legacy network configuration mechanisms
are deprecated and *will be removed eventually*.

Literally the only reason networkd was split out was because Fedora
CoreOS was chainsawing it out at image build time and making it
impossible for people to use it. To be frank, I do not want more
permutations this low in the stack. It makes life incredibly difficult
for figuring out working network setups.

My reply was aimed at Peter saying he'd like to not ship resolved, and
I'm saying that we should *not* do that, because it makes things even
harder and more complicated.




--
真実はいつも一つ!/ 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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-09-30 Thread Neal Gompa
On Wed, Sep 30, 2020 at 12:48 PM Peter Robinson  wrote:
>
> > Hi Zbyszek,
> > Would it make sense to do the same for systemd-resolved ?
> > Sounds like it has similar impact/scope wrt coreos.
>
> Yes please, I would like this for Edge/IoT too (both network/resolved)
> as there are use cases there where we'd like not to ship these too.
>

Please, no more package splitting. And NetworkManager is used across
all variants of Fedora, so resolved should be installed in all places
where NetworkManager is used.


-- 
真実はいつも一つ!/ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-30 Thread Neal Gompa
On Wed, Sep 30, 2020 at 12:15 PM PGNet Dev  wrote:
>
> Reading along, it's _at_best_ unclear what the eventual 'resolution' of this^ 
> is.
>
> What _is_ clear is that there's significant disagreement -- which, 
> unfortunately, has at times here become nasty & personal -- about needed vs 
> planned functionality, and, of late, regulatory compliance.
>
> And, iiuc, though obviously very much up in the air, this is all relevant to 
> F33 release, coming in weeks?
>
> Can someone please clarify, ideally with some level of certainty:
>
> If we've F32 systems in place, that do NOT use systemd-resolved &/or 
> NetworkManager, but rather our own/preferred DNS client implementations with 
> systemd-networkd,
>
> will a system *upgrade*, from F32 to F33, force/require any changes to those 
> configurations?  or will systems be left as-is, and we can expect 
> uninterrupted functionality?
>
> which of these proposed systemd-resolved system-wide changes are NON-optional 
> in _usage_?  can they _all_ be turned-off/disabled?
>
> bottom-line -- how much system breakage of existing infrastructure, if any, 
> should we be planning for with a F32 -> F33 upgrade path?

If you're not using NetworkManager, this change has _zero_ impact.


-- 
真実はいつも一つ!/ 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: F34 Change proposal: Debug Info LLDB Index (System-Wide change)

2020-09-29 Thread Neal Gompa
On Tue, Sep 29, 2020 at 4:29 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex
>
> == Summary ==
> Provide .debug_names debug info index for LLDB for clang-built
> binaries using: clang -gdwarf-5 -gpubnames
>
> Debuginfo index significantly accelerates loading of *.debug files by
> debugger. Fedora currently provides ELF section .gdb_index for
> [https://www.gnu.org/software/gdb/ GDB debugger].
> [https://lldb.llvm.org/ LLDB debugger] cannot use .gdb_index (as it is
> missing DIE offsets for more effective processing by LLDB) but LLDB
> can use .debug_names index.
>
> == Owner ==
> * Name: [[User:jankratochvil| Jan Kratochvil ]]
> * Email: jan.kratoch...@redhat.com
>
> == Detailed Description ==
>
> There are currently 3 formats of debug info index:
>
> * .gdb_index: It is currently produced in Fedora by GDB
> (/usr/bin/gdb-add-index), it is a part of rpmbuild process. It is
> compatible with GDB but incompatible with LLDB as it is missing
> essential DIE offsets needed by LLDB due to more effective (faster)
> reading of DWARF by LLDB.
>
> * .debug_names from GDB (augmentation "GDB\x00"): It can be produced
> by GDB (/usr/bin/gdb-add-index -dwarf-5) but its format is
> non-conforming to [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5
> standard]. LLDB expects DWARF-5 standard compliant .debug_names and
> therefore it is incompatible with this format. It can be expected GDB
> will fix the conformance in the future. Currently GDB .debug_names
> format has no advantage over GDB .gdb_index format.
>
> * .debug_names from clang (augmentation "LLVM0700"): It can be
> produced by clang (clang -gdwarf-5 -gpubnames) for LLDB. It is
> conforming to [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5
> standard], one can expect GDB will be able to read it in the future.
>
> It would be good to produce index from GCC by GDB and to produce index
> from clang by clang as the compatibility inside the same toolchain is
> best tested and supported. Using index across toolchains (index from
> GDB by LLDB or index from clang by GDB) should theoretically work but
> in practice there exist subtle differences in interpretation of more
> complicated DWARF constructs. It would be best to fix those but that
> will be always an afterthought.
>

Why don't you add an lldb-add-index tool to generate LLVM indexes for
LLDB? Then we just invoke it as part of the buildroot policy setup and
get both GDB and LLDB indexes? This proposal seems to be particularly
destructive to GDB users to favor LLDB.

I personally don't use LLDB for *anything*, since I think it's not a
particularly good debugger right now, and I would not be happy if the
performance of debugging clang-built things with GDB degraded.

>
>
> == Benefit to Fedora ==
> * Faster startup of LLDB debugger using Fedora system *.debug files.
>
> == Scope ==
> * Proposal owners: It affects all clang-built packages generating
> *-debuginfo.rpm.
> * Other developers: none
> * Policies and guidelines: All the needed changes should be done in
> [https://src.fedoraproject.org/rpms/redhat-rpm-config
> redhat-rpm-config]. The [https://src.fedoraproject.org/rpms/dwz dwz
> package] can be then retired.
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: The size differences are only for
> *-debuginfo.rpm which is outside of scope of the listed objectives.
>
>
> Currently the change will affect only packages using:
>  %global toolchain clang
> Those are currently only these packages being built by clang and using
> this %toolchain framework: dotnet3.1 libcxxabi mtxclient nheko simde
> wine
>
> FIXME: Which other Fedora packages are being built by clang?
>
> == Upgrade/compatibility impact ==
> Existing tools not supporting .debug_names will just ignore the
> additional ELF section. The only issue is current GDB would get
> confused by the clang .debug_names as it expects .debug_names to be in
> its incompatible GDB format - FIXME: Provide a GDB bugfix patch.
>
> Also each *-debuginfo.rpm has to exactly match NVRA of its binary
> package the Fedora change compatibility is not applicable.
>
> == How To Test ==
> GDB should not get affected by the new .debug_names index from clang.
>
> LLDB should load Fedora system *.debug files faster. LLDB
> functionality should not be affected by the index from clang (that is
> a part of LLVM development/testsuite).
>
> "llvm-dwarfdump -debug-names *.debug" should show: Augmentation: 'LLVM0700'
>
> == User Experience ==
> No user visible change. This affects what tools can developers use.
>

Developers are users. Please include what improvements they will get
from this change here.

> == Dependencies ==
> This Change is dependent on how is decided 
> [[Changes/DebugInfoStandardization]].
>

Why? That change is only about dwz, this is about adding indexes for
LLDB to use.

> This Change is dependent on RHEL-5 F-34 feature expected to be filed
> by Mark Wielaard.
>

I assume you mean RHEL-9 here. 

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-09-29 Thread Neal Gompa
On Tue, Sep 29, 2020 at 7:32 PM Jeff Law  wrote:
>
>
> On 9/28/20 8:50 AM, Jan Kratochvil wrote:
> >
> > DWARF standard sometimes makes mistakes, for example .debug_pubnames and
> > .debug_pubtypes were never really usable and DWARF-5 removed them. It may be
> > perfectly possible the DWZ extension of DWARF-5 will be removed in DWARF-6 
> > or
> > future DWARF standards as it turns out it is not worth the format 
> > complexity.
> > That some text has been accepted into the DWARF standard does not mean much.
> Sure.  We all make mistakes and standards bodies are no different. If
> you feel strongly that it was a mistake, then get involved in the
> process and try to correct it.
> >
> > It is all about engineering effort. I agree if the support of DWZ was 
> > trivial
> > (or there were unlimited engineering resources) then DWZ is really better 
> > than
> > -fdebug-types-section (except it would need a DWZ tool with less bugs and
> > better coding practices). But reality shows the DWZ support is not trivial
> > engineering resources for Fedora are very limited and so we have to decide
> > whether the serious effort to support DWZ is better spent on DWZ or on 
> > making
> > the debuggers better/really usable.
> >
> > Given how much you propose DWZ apparently the 3.3% Fedora distribution size
> > increase (if DWZ is dropped) is considered as too much. Obviously if the 
> > size
> > increase was just let's say 0.1% it would be acceptable to drop DWZ - do you
> > agree? So where is your size limit where the years-effort of supporting DWZ 
> > is
> > worth it? I would say my limit would be maybe 20%, far above the 3.3%.
>
> Putting my Red Hat hat on, I get pushback from PM on *any* size
> increases in the RHEL space.   While I often question the technical
> reasons behind why our customers are pushing for marginal (IMO)
> improvements, reality is they care.  As much as we'd like to be in a
> world were a 1% increase in distro size doesn't matter, that's not the
> actual world we live in.
>
> And our RHEL customers absolutey do care about the size of debuginfo
> becuause it affects link times.
>
>
> Anyway, I'll put my Fedora hat back on :-)
>
>

I feel like it's worth giving my perspective here as someone who has
done similar work in other distributions.

Because of how little debuginfo is used *in general*, every bit of
space saving matters. The dwz technology took so long to be adopted
because the rpm support never made it upstream. It took some poking
and prodding to finally get it upstreamed for RPM 4.14, and in doing
so, distros started using it because they were comfortable with
relying on the feature.

I don't think people realize how scary the debuginfo code actually is
for us "plebs" wanting to support it while having no knowledge or hope
of understanding the depths of it all. It's a very esoteric system.
Most of the distributions were unwilling to pull in an out-of-tree
patch out of fear of being stuck supporting it alone. For RPM
distributions, once it was mainlined, that fear was gone. The Debian
distribution family had the benefit of being able to reimplement the
whole system initially based on how it works in Fedora for them, and
once they did that, it was inherited by that entire branch of Linux
distributions.

I personally worked on enabling advanced debuginfo generation features
in rpm for OpenMandriva when I helped migrate them to RPM 4.14 and
DNF[1]. The only real trouble was with Clang being broken with split
debuginfo+debugsource with Clang/LLVM 7[2], which was fixed after
upgrading to Clang/LLVM 10[3].

The quality of life improvements with advanced rpm debuginfo
generation and dwz have made it tremendously easier for me and others
to be able to ship debuginfo data for more packages. And as developers
*need* that data to be able to... well, debug things, it comes in
handy having it everywhere.

I have also helped with bringing this to other distributions, but I
feel that my story here with OpenMandriva is particularly important
since we seem to be having a tug-of-war between the GCC and LLVM
toolchain teams.

[1]: https://www.openmandriva.org/en/news/article/switching-to-rpmv4
[2]: 
https://github.com/OpenMandrivaSoftware/rpm-openmandriva-setup/commit/a54ffd78b1eaeb1752cb7894ffdb266fb5b85311
[3]: 
https://github.com/OpenMandrivaSoftware/rpm-openmandriva-setup/commit/5b432a2d3d1c9c4aefbab04f937aed8b8c4618d8

[...]
>
> > By that LLVM dead DIES reduction talk I wanted to just show apparent nobody
> > cares too much about few percents of the *-debuginfo.rpm size - otherwise it
> > would be already coded/used. Or if there wasn't DWZ Fedora could already
> > switch to DWARF-5 which saves probably more size than DWZ does.
>
> I wasn't even aware we had dead dies.  THat doesn't mean I don't care,
> it just means I wasn't aware.  Others may be aware, but have higher
> priority items on their TODO lists.  Stating that "nobody cares too much
> ..." isn't helpful.
>

For the record, Mark has started 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-29 Thread Neal Gompa
On Tue, Sep 29, 2020 at 5:44 PM Michael Catanzaro  wrote:
>
> On Tue, Sep 29, 2020 at 11:33 pm, Graham Leggett 
> wrote:
> > To step in here, regulatory compliance is a non optional requirement
> > around the world.
> >
> > Regulatory compliance applies to everybody in a jurisdiction, there
> > is no such thing as a “specialized deployment” or environments
> > where it “will not matter”. Compliance doesn’t care about an
> > arbitrary freeze.
> >
> > This is not a technical decision.
>
> This is either a very strange misunderstanding, or trolling. I will
> assume positive intent. Internet RFCs are not regulatory requirements.
> If you're aware of some government regulation that requires us to
> forward RRSEC records, I would be very surprised, but please do let us
> know.
>

Also, in case folks weren't aware, IETF RFCs are *intentionally* not
described as standards. They are designed to be subject to revision at
more or less any time. That's why they are titled as a "Request for
Comments" (or RFC). The fact that they are used as standards
documentation is sort of the nature of how things developed from an
era where it was impossible to publish standards for free
(organizations like the ISO require paying money for standards
documentation).

But this also has the consequence that IETF RFCs do not have a
requirement to be evaluated in the context of others and determined to
be fully satisfiable along others. That is, it's possible to have
mutually exclusive RFCs for a system that you have to implement.

So please keep that in mind when considering discussing DNS.



-- 
真実はいつも一つ!/ 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: F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)

2020-09-29 Thread Neal Gompa
On Tue, Sep 29, 2020 at 4:30 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/CompressKernelFirmware
>
> == Summary ==
> Compress Kernel Firmwares to reduce on disk size
>
> == Owner ==
> * Name: [[User:pbrobinson| Peter Robinson]]
> * Email: [mailto:pbrobin...@fedoraproject.org| pbrobin...@fedoraproject.org]
>
> == Detailed Description ==
>
> Since the linux 5.3 kernel there has been support for loading firmware
> from xz compressed firmware. The upstream linux-firmware respository
> is now over 900Mb, not including other kernel firmware that are in
> Fedora but come from other sources. By compessing the firmware with
> "xz -C crc32", the only option currently supported in the kernel, we
> can reduce the ondisk size of the firmware by almost half.
>

I vaguely recall that there was some effort to add zstd support to
compress kernel stuff. Could we consider using that for this instead
of xz? Or is that still only for kernel modules?


-- 
真実はいつも一つ!/ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-29 Thread Neal Gompa
On Tue, Sep 29, 2020 at 7:48 AM Björn Persson  wrote:
>
> Lennart Poettering wrote:
> > On Mo, 28.09.20 22:54, Björn Persson (Bjorn@rombobjörn.se) wrote:
> >
> > > It can work in company-scope if the company has competent network
> > > admins. My local DNS server at home resolves local hostnames to private
> > > IPv4 addresses in the 192.168/16 block. Clients on the Internet see
> > > another view. Both views are DNSsec-signed, and validation works fine.
> > > There's no reason why this setup wouldn't work on a corporate network.
> > > The key is to use a domain that is actually registered to the company,
> > > not some made-up TLD like "internal" or whatever the incompetent
> > > network admins come up with.
> >
> > You never take your laptop outside to a cafe or so? You never
> > connected it to something that is not your home or office network?
>
> A cafe is company-scope? I'm not sure whether that counts as moving the
> goalposts or changing the subject, but neither is a constructive way to
> discuss a technical topic.
>

If you're a remote employee, it absolutely is. And especially in this
pandemic, this kind of thing is now the *default* experience.



-- 
真実はいつも一つ!/ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Neal Gompa
On Mon, Sep 28, 2020 at 1:20 PM Chuck Anderson  wrote:
>
> On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > > * Andrew Lutomirski:
> > >
> > > > Paul may well have been mixing different things here, but I don't
> > > > think you answered the one that seems like the most severe problem:
> > > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > > supplied by the upstream server.  One might reasonably debate whether
> > > > Fedora's default DNS resolver configuration should validate DNSSEC,
> > > > but I think it should honor the DO bit in client requests and return
> > > > DNSSEC data.
> > >
> > > FWIW, this is .
> >
> > In an ideal world, we would just implement this missing functionality.
> > It's definitely on the TODO list, and there has been some preparatory
> > work done, but so far nobody found the time. If this is judged necessary,
> > we'll raise the priority of that work. Nevertheless, I don't think it is
> > such high priority — the number of people using DNSSEC is not too large,
> > and they are generally power-users who understand how to specify a different
> > server. So while definitely annoying, I didn't consider this a deal-breaker.
>
> DNSSEC is not meant for power-users, and it doesn't require specifying
> "a different server".
>
> I thought Fedora was supposed to be First?  How can it be if Fedora
> chooses to use/configure software by default that is missing critical
> DNSSEC functionality and breaks DNS standards?

DNSSEC is broken by design for most users. For example, I literally
cannot use it because my corporate VPN does not provide DNSSEC support
because the DNS server software doesn't support it. If I didn't know
what to look for, I'd just say Fedora is broken. Same goes for DoT and
DoH.


-- 
真実はいつも一つ!/ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Neal Gompa
On Mon, Sep 28, 2020 at 11:57 AM Paul Wouters  wrote:
>
> On Mon, 28 Sep 2020, Tom Hughes via devel wrote:
>
> > On 28/09/2020 15:57, Marius Schwarz wrote:
> >>  Am 28.09.20 um 13:47 schrieb Zbigniew Jędrzejewski-Szmek:
> >>>  DNSSEC support in resolved can be enabled through resolved.conf.
> >>  Why isn't that the default, if this resolver can do it?
> >
> > Because DNSSEC is a disaster area and if you try and use it
> > on random networks you're going to get failed lookups on a
> > reasonable number - it's fine if you're on a known network
> > with decent upstream servers but once you start going out
> > and using random WiFi hotspots and things it's a very
> > different story.
>
> And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now
> being deployed. And why browsers are, contrary to Michael Catanzaro's
> wrong claim, overriding the system DNS already. See Mozilla's TRR
> program https://wiki.mozilla.org/Trusted_Recursive_Resolver and
> Google's chrome https://www.chromium.org/developers/dns-over-https
>

Michael is not wrong. We are, in fact, forcing Firefox to respect
system DNS settings in Fedora. But if you use Mozilla's builds, you
will have this problem. Same goes for Chrome/Chromium.




-- 
真実はいつも一つ!/ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-09-25 Thread Neal Gompa
On Fri, Sep 25, 2020 at 7:26 AM Ryan  wrote:
>
> > == Benefit to Fedora ==
> > * Better compatibility with existing debugging and tracing tools,
> > primarily [https://lldb.llvm.org/ LLDB].
>
> Thanks for your work on this Ben and Jan, Just as an interested user, use of 
> the DWZ format significantly limits Swift development on Fedora, as it is 
> impossible to debug with LLDB when using system libraries.
>

But that's fixable since there's a patchset to make LLDB understand
dwz, which was not submitted upstream for unstated reasons.


-- 
真実はいつも一つ!/ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-09-25 Thread Neal Gompa
On Fri, Sep 25, 2020 at 3:08 AM Florian Weimer  wrote:
>
> * Jan Kratochvil:
>
> > On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
> >> Then that certainly means that Ubuntu uses this too, since they reuse
> >> the dbgsym subpackage generation for the ddeb system they have now.
> >
> > I am not much familiar with Debian/Ubuntu but I cannot find any use of DWZ
> > there:
> >   https://packages.ubuntu.com/groovy/amd64/bluez-dbg/download
> >   llvm-dwarfdump -color=0 
> > bluez-dbg_5.55-0ubuntu1_amd64/data/usr/lib/debug/.build-id/*/*.debug|grep 
> > DW_TAG_partial_unit
> >
> > This debuginfo package has been built 2020-09-15.
>
> This is not a -dbgsym package, so it probably has been created by a
> different procedure.  I do not know how Ubuntu distributes their -dbgsym
> packages.  An example from Debian with .dwz paths is here:
>
> <http://debug.mirrors.debian.org/debian-debug/pool/main/a/alsa-utils/alsa-utils-dbgsym_1.2.3-1_amd64.deb>
>

Ubuntu *definitely* has it. Checking "alsa-utils" from Ubuntu 20.04
shows dwz data.

Cf. 
http://ddebs.ubuntu.com/pool/main/a/alsa-utils/alsa-utils-dbgsym_1.2.2-1ubuntu1_amd64.ddeb


-- 
真実はいつも一つ!/ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-09-24 Thread Neal Gompa
On Thu, Sep 24, 2020 at 2:04 PM Stephen John Smoogen  wrote:
>
>
>
> On Thu, 24 Sep 2020 at 13:44, Jan Kratochvil  
> wrote:
>>
>> On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
>> > Then that certainly means that Ubuntu uses this too, since they reuse
>> > the dbgsym subpackage generation for the ddeb system they have now.
>>
>> I am not much familiar with Debian/Ubuntu but I cannot find any use of DWZ
>> there:
>> https://packages.ubuntu.com/groovy/amd64/bluez-dbg/download
>> llvm-dwarfdump -color=0 
>> bluez-dbg_5.55-0ubuntu1_amd64/data/usr/lib/debug/.build-id/*/*.debug|grep 
>> DW_TAG_partial_unit
>>
>> This debuginfo package has been built 2020-09-15.
>>
>> (Besides that this proposal is not based on whether Debian uses DWZ or not.)
>
>
> The original language of the proposal said no other distribution used DWZ, 
> and that the format was not adopted and should be removed. So it comes across 
> that it is based on whether Debian, Ubuntu, etc use it.
>
> ```
> As the format did
> not get widespread and the tool is not much maintained it became
> burden to make existing debugging tools compatible with Fedora debug
> info.
> 
> Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and
> SuSE OSes) and so its support is missing in tools like
> [https://lldb.llvm.org/ LLDB],
> [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]
> or binutils readelf. -fdebug-types-section is used internally by
> Google (produced by clang). Debian does not store any debug info
> archives. Ubuntu uses neither -fdebug-types-section nor DWZ.
>
> ```
>

For the record, the reason why it was hard to broaden adoption is that
the patch wasn't upstreamed into rpm itself until RPM 4.14's release:
https://rpm.org/wiki/Releases/4.14.0.html

That was only three years ago, and in the span of that time, it's gone
from only Fedora using it to almost everyone using it now.

> Just stick to the following:
>
> The tool is not easily maintained, and has become a burden to make existing 
> debugging tools, namely llvm, compatible with this method.
>
> Also expect that cross-distribution support is going to be important. No 
> distribution is an island entire of itself; and few 'customers' use just one 
> distribution. If a lot of distributions have been using this because Fedora 
> had been and it was easier to work out things.. then work is going to be 
> needed to get them to work together..
>

I do not feel that this is a valid premise either, since the reason
for no dwz support in LLDB is because nobody contributed it. I'm
slightly surprised that Red Hat's debuginfo engineers hadn't already
contributed support for it into LLDB. I wonder if the reason for that
was the mistaken impression that dwz wasn't broadly used.


-- 
真実はいつも一つ!/ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-09-24 Thread Neal Gompa
On Thu, Sep 24, 2020 at 1:13 PM Peter Pentchev  wrote:
>
> On Thu, Sep 24, 2020 at 01:01:17PM -0400, Neal Gompa wrote:
> > On Thu, Sep 24, 2020 at 12:00 PM Ben Cotton  wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
> > >
> > > == Summary ==
> > > Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
> > > not get widespread and the tool is not much maintained it became
> > > burden to make existing debugging tools compatible with Fedora debug
> > > info.
> > >
> > > == Owner ==
> > > * Name: [[User:jankratochvil| Jan Kratochvil ]]
> > > * Email: jan.kratoch...@redhat.com
> > >
> > >
> > > == Detailed Description ==
> > >
> > > Debug info files *.debug contained in *-debuginfo.rpm are very big in
> > > general (x86_64 Fedora 32 distribution has debug/ directory of 82GB
> > > while all its other files are only 75GB). There exist several methods
> > > how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18
> > > started using DWZ tool (from [[Features/DwarfCompressor]]) while
> > > [https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html
> > > Google implemented] the same goal in a different way called
> > > -fdebug-types-section.
> > >
> > > Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and
> > > SuSE OSes) and so its support is missing in tools like
> > > [https://lldb.llvm.org/ LLDB],
> > > [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]
> > > or binutils readelf. -fdebug-types-section is used internally by
> > > Google (produced by clang). Debian does not store any debug info
> > > archives. Ubuntu uses neither -fdebug-types-section nor DWZ.
> > >
> >
> > This is not true. Debian started producing -dbgsym packages and
> > putting them in a separate repository years ago:
> > https://wiki.debian.org/AutomaticDebugPackages
> >
> > dwz is used by virtually all RPM based distributions now, including
> > OpenMandriva (a clang-based distro). I know this because I implemented
> > it. :)
> >
> > I do not know whether Debian has started using dwz by default because
> > I haven't dug into how the -dbgsym package generation works in detail.
>
> Most of the packages that use recent versions of debhelper (the tool
> that automates many steps of the Debian packaging) have run dwz for
> the past couple of years. I do not have any statistics though.
>

Then that certainly means that Ubuntu uses this too, since they reuse
the dbgsym subpackage generation for the ddeb system they have now.

So it sounds like the underlying premise of this whole Change is
flawed, since everyone has been using dwz without telling the
dwz developers. :)




--
真実はいつも一つ!/ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-09-24 Thread Neal Gompa
On Thu, Sep 24, 2020 at 12:00 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
>
> == Summary ==
> Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
> not get widespread and the tool is not much maintained it became
> burden to make existing debugging tools compatible with Fedora debug
> info.
>
> == Owner ==
> * Name: [[User:jankratochvil| Jan Kratochvil ]]
> * Email: jan.kratoch...@redhat.com
>
>
> == Detailed Description ==
>
> Debug info files *.debug contained in *-debuginfo.rpm are very big in
> general (x86_64 Fedora 32 distribution has debug/ directory of 82GB
> while all its other files are only 75GB). There exist several methods
> how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18
> started using DWZ tool (from [[Features/DwarfCompressor]]) while
> [https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html
> Google implemented] the same goal in a different way called
> -fdebug-types-section.
>
> Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and
> SuSE OSes) and so its support is missing in tools like
> [https://lldb.llvm.org/ LLDB],
> [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]]
> or binutils readelf. -fdebug-types-section is used internally by
> Google (produced by clang). Debian does not store any debug info
> archives. Ubuntu uses neither -fdebug-types-section nor DWZ.
>

This is not true. Debian started producing -dbgsym packages and
putting them in a separate repository years ago:
https://wiki.debian.org/AutomaticDebugPackages

dwz is used by virtually all RPM based distributions now, including
OpenMandriva (a clang-based distro). I know this because I implemented
it. :)

I do not know whether Debian has started using dwz by default because
I haven't dug into how the -dbgsym package generation works in detail.



--
真実はいつも一つ!/ 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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-21 Thread Neal Gompa
On Mon, Sep 21, 2020 at 9:05 AM Vitaly Zaitsev via devel
 wrote:
>
> On 21.09.2020 14:30, Neal Gompa wrote:
> > Do you
> > seriously think that the bugs there won't get fixed? Some of them
> > already *have* been fixed in Plasma 5.19.
>
> A very annoying bug[1] with broken keyboard layout switcher must be a
> blocker. Not everyone here lives in English-speaking countries.
>
> [1]: https://bugs.kde.org/show_bug.cgi?id=390079

Yes, I know of it. My systems have multiple languages activated too.
It works right now, but the indicator telling you which mode you're in
is broken at the moment.




--
真実はいつも一つ!/ 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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-21 Thread Neal Gompa
On Mon, Sep 21, 2020 at 8:28 AM Vitaly Zaitsev via devel
 wrote:
>
> On 21.09.2020 13:19, Neal Gompa wrote:
> > KDE upstream has a
> > specific "goal" to get Wayland support to first-class status:
> > https://community.kde.org/Goals/Wayland
>
> https://community.kde.org/Plasma/Wayland_Showstoppers
>

Okay, and? There's five months between now and beta freeze. Do you
seriously think that the bugs there won't get fixed? Some of them
already *have* been fixed in Plasma 5.19.



-- 
真実はいつも一つ!/ 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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-21 Thread Neal Gompa
On Mon, Sep 21, 2020 at 7:11 AM Ondrej Mosnacek  wrote:
>
> On Mon, Sep 21, 2020 at 12:22 PM Pavel Raiskup  wrote:
> > On Thursday, September 10, 2020 6:00:09 PM CEST Ondrej Mosnacek wrote:
> > > On Thu, Sep 10, 2020 at 12:58 PM Neal Becker  wrote:
> > > > Might be interesting to try logging in as a new user to see if some 
> > > > older kde settings are messing things up.
> > >
> > > That's definitely possible... However this is a single-user machine
> > > and I don't really feel like creating a new user :)
> > >
> > > If I find some time I'll try it on my other laptop and/or dig deeper...
> >
> > Ondrej, what Fedora version are you on?  The change claims:
> >
> >   With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a
> >   point where nearly all commonly used features in the desktop and all
> >   major applications function in the Plasma Wayland environment on all
> >   major GPUs (including NVIDIA with the proprietary driver).
> >
> > I'd consider a move to F34 just to test early, but even F34 still seems to
> > have 5.19.90.
>
> I was trying it on F32. I was ready to see various annoyances, since
> the proposal says that a lot of issues will be only fixed in F34, but
> I hoped that in F32 the desktop will at least look normal when I log
> in :)
>
> >
> > The change says:
> >
> >   How To Test
> >   ===
> >   Log into a KDE Plasma desktop. Do any activity you would normally do in
> >   your daily desktop use: launching applications, configuring displays,
> >   etc. Things should work the same way under Wayland as they used to
> >   under X.
> >
> > Even a simple link to step-by-step howto would help.  How much sense does
> > it have to test F32/F33?
>
> Probably not much :) I was just curious to see how good/bad the
> situation is currently on F32. From the optimistic wording in the
> change request I imagined that most things already work and the latest
> releases only fix some final annoyances... but maybe this is more true
> about F33 than F32, or I just have some weirdness in my existing
> configuration...
>

I'm personally running Plasma Wayland on a couple of computers now on
Plasma 5.18 on Fedora 32. To do so, all you need to do is install
"plasma-workspace-wayland" and select the "Plasma (Wayland) (Wayland)
(Wayland)" session (yes really, the text is fixed with Plasma 5.19)
from the SDDM drop down.

You'll be missing all the remaining "basic" features implemented into
kwin-wayland like middle click paste and screencasting support, but
those will become available with Plasma 5.20. KDE upstream has a
specific "goal" to get Wayland support to first-class status:
https://community.kde.org/Goals/Wayland

My desire is to activate it as default in Rawhide as soon as possible
and start working with KDE upstream to hammer things out throughout
the entire development cycle for Fedora 34. We will probably wind up
shipping Plasma 5.21 or Plasma 5.22 for Fedora 34 GA, and getting
testing and such going as early as possible will help get the actual
target release for Fedora 34 in good shape for Plasma Wayland.

But of course, if by the time we get to beta freeze and it's too
buggy, we'll flip the default back to Xorg while shipping both as
options on the media and try again for Fedora 35.


-- 
真実はいつも一つ!/ 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: btrfs / booting alternative OS versions from subvolumes

2020-09-19 Thread Neal Gompa
On Sat, Sep 19, 2020 at 5:48 AM Daniel Pocock  wrote:
>
>
> I noticed another thread about subvolumes already exists, I'm starting
> this one for the very specific topic of installing multiple root
> filesystems as subvolumes
>
> Examples: Fedora 33 in one subvolume, Fedora rawhide in another
> subvolume, Fedora 33 32-bit in another subvolume, maybe RHEL in a
> subvolume too
>
> Can this be supported by the installer?
>
> Can it be supported by grub?
>
> If somebody installs their OS to the top level of their btrfs today, can
> they pivot that into a subvolume later?
>
> All these OS installs would shared some things like /home

If all the operating systems support working with the same grub and
support Btrfs with the features enabled in the filesystem, yes.

The only known issue I'm aware of is that Fedora 33 GRUB cannot boot
Fedora 32 or RHEL 8 because the bootloader spec implementation changed
and it no longer supports variables inside of file snippets.

(Obviously, I'm ignoring the fact that RHEL 8 doesn't support Btrfs normally...)




--
真実はいつも一つ!/ 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: btrfs and default page sizes (4k vs 64k)

2020-09-18 Thread Neal Gompa
On Fri, Sep 18, 2020 at 10:07 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Sep 16, 2020 at 02:09:42PM -0400, Neal Gompa wrote:
> > I'm annoyed in general that we still have problems like this, and I'm
> > even more annoyed that I basically have no way to even test or deal
> > with these things. We *still* do not have packager test machines, so I
> > can't even figure out how to craft a workaround if there is one (and I
> > suspect one is possible).
>
> We do: 
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers.
> There's one ppc64le on that list.
>

They were all down, last I checked a month ago. But it seems like the
ppc64le one is back online now. :)



-- 
真実はいつも一つ!/ 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: btrfs and default page sizes (4k vs 64k)

2020-09-18 Thread Neal Gompa
On Fri, Sep 18, 2020 at 8:19 AM Daniel Pocock  wrote:
>
>
>
> On 16/09/2020 21:29, Josef Bacik wrote:
> > On 9/16/20 3:18 PM, Eugene Syromiatnikov wrote:
> >> On Wed, Sep 16, 2020 at 03:04:45PM -0400, Josef Bacik wrote:
> >>> At the time we tied the fs blocksize to the
> >>> page size, because it was unlikely that a user would mkfs a fs on one
> >>> arch
> >>> and move it over to another arch.
> >>
> >> But one doesn't need "another arch" for page size to change; many
> >> architectures (arm, mips, powerpc, sparc, to name a few) support multiple
> >> page sizes.
> >
> > Sure, but again you are not likely to change page size for an existing
> > system. The decision early on was to forgo this particular ability for
> > simplicity, and then we would revisit the decision later on.  It's been
> > a while and there's still not been enough demand to justify the work
> > until recently.  Thanks,
>
>
> This is messy but important
>
> Is it possible for Fedora to offer two flavours of the kernel package,
> like Debian?  There, I created a -4k flavour so it builds two kernel
> packages, one with 4k and the other with 64k.  They can both be
> installed on the same machine and one or the other selected in the grub
> menu on each boot.  Either can mount an ext4 root but obviously they
> can't share the same btrfs root, only the one that created it can mount
> that root.
>
> Once an alternative kernel is available, people need an installer/rescue
> ISO including that kernel.  This may mean making both permutations
> available as different installer ISOs, or including two kernels in the
> same ppc64el
>
> Installer logic: If somebody is using ANY non-4k page size, on any
> architecture, it would be useful to display a pop-up window with a
> warning about btrfs before they create their root filesystem.  This will
> save a lot of trouble for people.  They might not realize there is a
> problem until they've been using the system for a few days and then they
> have to reinstall it again.
>
> Finally, if both page sizes are available, it is desirable to do a build
> of every package for every page size.  Some packages appear to sense the
> page size at compile time and assume it will always be the same at
> runtime.  This is unfortunate.  Maybe reproducible builds techniques can
> be used to build each package on two different page sizes, detect if the
> binary differs and if so, suggest checking for hard-coded page size.
>

I think all of this effort required is why we probably *won't* do that.

I would be interested in seeing what kind of performance differences
there are between 4K page sizes and 64K page sizes, but I don't
particularly want to make ppc64le change back to 4K page sizes, simply
because there's not much point to it. POWER systems are still largely
unavailable to people and that's not going to change anytime soon.

As for a warning, I do not have the cycles to do that. As it stands,
if I'm going to put my limited contributing energy into something,
it'd probably be to help upstream fix the problem with non-4K page
sizes in the first place. Since you're interested in this problem,
perhaps you could help upstream with testing the patches and writing
code to fix this? Especially since it sounds like you have hardware
and use-cases to test this with.





-- 
真実はいつも一つ!/ 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: btrfs and default page sizes (4k vs 64k)

2020-09-16 Thread Neal Gompa
On Wed, Sep 16, 2020 at 2:15 PM Daniel P. Berrangé  wrote:
>
> On Wed, Sep 16, 2020 at 02:09:42PM -0400, Neal Gompa wrote:
> > I'm annoyed in general that we still have problems like this, and I'm
> > even more annoyed that I basically have no way to even test or deal
> > with these things. We *still* do not have packager test machines, so I
> > can't even figure out how to craft a workaround if there is one (and I
> > suspect one is possible).
>
> QEMU can emulate a virtual machine for any of the Fedora arches. It won't
> be fast like native, but that shouldn't be a fundamental blocker for a
> bit of adhoc debugging / testing of something that isn't performance
> critical.
>

Right, though on my Fedora 32 machine I can't create btrfs volumes in
QEMU. That's fixed in F33, but my machine that ran F33 kinda died last
week. :(

I guess I'll upgrade one of the machines hanging around...




--
真実はいつも一つ!/ 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: btrfs and default page sizes (4k vs 64k)

2020-09-16 Thread Neal Gompa
On Wed, Sep 16, 2020 at 2:05 PM Tom Seewald  wrote:
>
> > On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler  > wrote:
> >
> > I hate to break it to you, but this problem is not just in
> > filesystems, it's in basically everything in the kernel. And we've had
> > variations of problems like this for years (endianness, page size,
> > pointer size, single bit vs multi-bit booleans, etc.). I've personally
> > been bitten by all of these issues in some way. This comes from the
> > fact that there's no such thing as "internal implementation detail of
> > the kernel" by design. This is the "joy" of the monorepo
> > "design"
> > where everything leaks into everything else.
> >
> > This didn't become a serious problem until Red Hat made the
> > unfortunate (though not realized at the time) mistake of switching to
> > 64k pages for ARM and POWER. We got that change in Fedora for POWER
> > but not ARM. It has led to all kinds of unfortunate problems that are
> > gradually being worked on and fixed upstream.
> >
> > Coming back to Btrfs specifically, there is work underway upstream to
> > resolve this issue. My (semi-blind) estimate is that we'll see a fix
> > in Linux 5.11, but Josef (cc'd to this email) may know more about it.
> >
> >
> >
> > --
> > 真実はいつも一つ!/ Always, there's only one truth!
>
> Frankly I'm disappointed that the response is to deflect criticism of btrfs 
> by claiming that this is an expected issue with the kernel, and then placing 
> the blame on Red Hat for using a larger page size. To my knowledge page size 
> differences aren't an issue on ext4 or xfs as they default to using a 4kb 
> block size, so saying that "it's in basically everything in the kernel" is at 
> best inaccurate and at worst intentionally misleading.

I *expect* issues in general for stuff like this to come up when it
comes to knobs like this being turned. That does not excuse the fact
this issue exists. And it is true that all kinds of things are
impacted by those kinds of changes.

That said, there *is* work going on to resolve it *now*. I have even
asked upstream to consider just forcing 4K sizes going forward since
that is easy enough for everything to handle.

I'm annoyed in general that we still have problems like this, and I'm
even more annoyed that I basically have no way to even test or deal
with these things. We *still* do not have packager test machines, so I
can't even figure out how to craft a workaround if there is one (and I
suspect one is possible).



-- 
真実はいつも一つ!/ 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: btrfs and default page sizes (4k vs 64k)

2020-09-16 Thread Neal Gompa
On Wed, Sep 16, 2020 at 10:32 AM Eric Sandeen  wrote:
>
> On 9/15/20 7:29 PM, Neal Gompa wrote:
> > On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler  wrote:
> >>
> >> Daniel Pocock wrote:
> >>> One issue I've come across is that a btrfs filesystem can only be used
> >>> on hosts with the same page size as the host that created the filesystem
> >>
> >> Ewww! That alone should disqualify btrfs as a default file system!
> >>
> >> Why does a file system depend on the kernel page size? The kernel page size
> >> is an internal implementation detail of the kernel, whereas a file system
> >> ought to be a stable interchange format that is compatible across all
> >> machines.
> >>
> >> It is unfortunate that this showstopper was not mentioned when the switch 
> >> to
> >> btrfs by default was proposed.
>
> I'm not sure that it would have been deemed any more important than other
> concerns which were raised at the time, TBH.
>
> > I hate to break it to you, but this problem is not just in
> > filesystems, it's in basically everything in the kernel. And we've had
> > variations of problems like this for years (endianness, page size,
> > pointer size, single bit vs multi-bit booleans, etc.). I've personally
> > been bitten by all of these issues in some way. This comes from the
> > fact that there's no such thing as "internal implementation detail of
> > the kernel" by design. This is the "joy" of the monorepo "design"
> > where everything leaks into everything else.
>
> That's simply not accurate.  Handling 32/64 bit interfaces, endianness, etc
> are long-solved problems.  Longstanding lack of design or support for
> sub-page block support in a filesystem is not /at all/ the same thing.
>
> Are there occasional endianness bugs, pointer size bugs, etc?  Sure.
> But that's different from "We did not design this."
>

Almost every filesystem was not originally designed for mixing page
sizes, endianness, etc. These issues *have* been fixed over time, for
sure. But it is not worth it for me or anyone else to go into a blame
game. Is it unfortunate that Btrfs didn't have that? Sure. Did I know
this was a problem? No, because I have no access to POWER systems,
like almost everyone else here. And ARM, the other architecture we
have, does not use 64K page sizes in Fedora (though it does in RHEL,
and that is pretty much considered a mistake there, as it didn't take
off, caused interop and performance issues, and added complexity where
it was unneeded).

> > This didn't become a serious problem until Red Hat made the
> > unfortunate (though not realized at the time) mistake of switching to
> > 64k pages for ARM and POWER. We got that change in Fedora for POWER
> > but not ARM. It has led to all kinds of unfortunate problems that are
> > gradually being worked on and fixed upstream.
>
> Sub-page block support in filesystems is not a wild, esoteric, unexpected
> feature.
>
> It's something that is generally available in nearly every other widely used
> Linux filesystem.  It's not accurate to suggest that this is some unexpected
> side effect of page size choice, or that 64k pages were somehow a "mistake"
> now that this btrfs compatibility issue has been made more obvious.
>
> btw, Fedora has shipped kernels with 64k pages for almost a decade:
>
> commit 737c9c7da818f1da0bdf3f6a0dda5c38a3cba769
> Author: Josh Boyer 
> Date:   Fri Sep 9 11:21:22 2011 -0400
>
> Change to 64K page size for ppc64 kernels (rhbz 736751)
>

I am aware that we shipped them for a long time. They are a mistake
for many other reasons unrelated to Btrfs. Regardless, the choice was
made and things have been fixed over time for it. There is already a
patch set being reviewed[1] for the first stage of mixed page support.

[1]: 
https://lore.kernel.org/linux-btrfs/12ecf2f9-c262-8b00-2165-486684ba2...@suse.com/T/



--
真実はいつも一つ!/ 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: btrfs and default page sizes (4k vs 64k)

2020-09-15 Thread Neal Gompa
On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler  wrote:
>
> Daniel Pocock wrote:
> > One issue I've come across is that a btrfs filesystem can only be used
> > on hosts with the same page size as the host that created the filesystem
>
> Ewww! That alone should disqualify btrfs as a default file system!
>
> Why does a file system depend on the kernel page size? The kernel page size
> is an internal implementation detail of the kernel, whereas a file system
> ought to be a stable interchange format that is compatible across all
> machines.
>
> It is unfortunate that this showstopper was not mentioned when the switch to
> btrfs by default was proposed.
>

I hate to break it to you, but this problem is not just in
filesystems, it's in basically everything in the kernel. And we've had
variations of problems like this for years (endianness, page size,
pointer size, single bit vs multi-bit booleans, etc.). I've personally
been bitten by all of these issues in some way. This comes from the
fact that there's no such thing as "internal implementation detail of
the kernel" by design. This is the "joy" of the monorepo "design"
where everything leaks into everything else.

This didn't become a serious problem until Red Hat made the
unfortunate (though not realized at the time) mistake of switching to
64k pages for ARM and POWER. We got that change in Fedora for POWER
but not ARM. It has led to all kinds of unfortunate problems that are
gradually being worked on and fixed upstream.

Coming back to Btrfs specifically, there is work underway upstream to
resolve this issue. My (semi-blind) estimate is that we'll see a fix
in Linux 5.11, but Josef (cc'd to this email) may know more about 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: compat-openssl11 vs openssl1.1

2020-09-15 Thread Neal Gompa
On Tue, Sep 15, 2020 at 6:35 PM Michel Alexandre Salim
 wrote:
>
> On Tue, 2020-09-15 at 14:10 -0400, Simo Sorce wrote:
> > On Tue, 2020-09-15 at 13:46 -0400, Neal Gompa wrote:
> > >
> > > The compat- prefix is no longer allowed. Instead we should be using
> > > versioned package names.
> >
> > Why?
> > The "compat-" prefix clearly indicated the .so was provided
> > exclusively
> > for backward binary compatibility and shouldn't be relied upon in
> > other
> > packages.
> >
> Provided ${libname}-devel pulls the latest, main version instead of one
> of the older versions, hopefully there is no confusion which version is
> meant to be used?
>
> (That being said, when using other virtual provides such as
> 'pkgconfig(pcname)' it doesn't matter whether the package is versioned
> or prefixed with compat- anyway, as that won't make a difference from
> the call site).
>
> > A bare name conveys nothing and risk introducing dependencies later
> > instead of slowly draining out dependencies until it can be removed
> > again.
> >
> > > So if we're changing the old one, it'll become openssl1.0 to comply
> > > with current guidelines.
> >
> > I think having a package named openssl1.0 or openssl1.1 would lead to
> > more confusion, not less.
> >
> > Simo.
> >
> >
> Anyone familiar with how this works in practice for Debian (and
> derivatives) and, IIRC, Mageia? They've been using versioned packages
> for years so if there are potential confusions they ought to have
> encountered them before.
>

Mageia, openSUSE, and Debian all require versioned packaging for
libraries in all cases. It works perfectly fine. There's no confusion
or anything the package manager or whatever. In the Fedora case, it
looks odd to see it, but since it's only for legacy libraries, it's
fine.

Something that Mageia and openSUSE do sometimes is just not ship a
-devel package if the library is only there for runtime backwards
compatibility. That's something we could do for openssl1.0 and
eventually openssl1.1.



-- 
真実はいつも一つ!/ 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: Changing the desktop background image of a GNOME based lab to match Fedora

2020-09-15 Thread Neal Gompa
On Tue, Sep 15, 2020 at 2:41 PM Miro Hrončok  wrote:
>
> Hello,
>
> There is a Fedora Python Classroom Lab:
>
> https://labs.fedoraproject.org/python-classroom/
>
> It has a GNOME based live / installable option. It has the default GNOME 
> desktop
> background.
>
> What are the necessary steps to use the Fedora's default background?
> (Both on the live system and on the installed one.)
>

Add back the fedora-workstation-backgrounds package to
fedora-python-classroom-gnome-common.ks. It's currently excluded since
you remove the entirety of the workstation product group.




--
真実はいつも一つ!/ 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: compat-openssl11 vs openssl1.1

2020-09-15 Thread Neal Gompa
On Tue, Sep 15, 2020 at 2:29 PM Michael Catanzaro  wrote:
>
> On Tue, Sep 15, 2020 at 1:46 pm, Neal Gompa  wrote:
> > openssl1.0
>
> It reached EOL in December 2019. Probably time to remove it from Fedora?
>

Ideally, yes, but I think some things still use it, and I think it
tracks the RHEL 7 openssl package now.



-- 
真実はいつも一つ!/ 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: compat-openssl11 vs openssl1.1

2020-09-15 Thread Neal Gompa
On Tue, Sep 15, 2020 at 1:36 PM Nathanael D. Noblet  wrote:
>
> On Tue, 2020-09-15 at 19:26 +0200, Tomas Mraz wrote:
> > I've submitted a new compat-openssl11 package for review but it was
> > pointed out to me that according to the new format of the naming for
> > compat packages it should be named openssl1.1. However there already
> > is
> > a compat-openssl10 package.
> >
> > What is more important? Consistency between those two compat packages
> > or strictly following the naming rules for the new package?
> >
>
> My 2 cents would be consistency. If others disagree, perhaps compat-
> openssl10 should be renamed to compat-openssl1.0 and obsolete the old
> compat-openssl10? Its annoying to try to find the magic name something
> has based on something else... python-foo vs Foo-python etc.

The compat- prefix is no longer allowed. Instead we should be using
versioned package names.

So if we're changing the old one, it'll become openssl1.0 to comply
with current guidelines.


-- 
真実はいつも一つ!/ 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: compat-openssl11 vs openssl1.1

2020-09-15 Thread Neal Gompa
On Tue, Sep 15, 2020 at 1:27 PM Tomas Mraz  wrote:
>
> Hi Fedora developers,
>
> we need to introduce temporarily a compat package for OpenSSL as it is
> going to be rebased to the 3.0 version in Rawhide once the 3.0 release
> is stable.
>
> The 3.0 version should not break API from the 1.1.1, it just breaks the
> ABI, so rebuilds should be quite easy. Of course there might be minor
> breakage and adjustments needed especially for the language bindings.
> But anyway to help with the transition there should temporarily be a
> compat package with the openssl-1.1.1.
>
> I've submitted a new compat-openssl11 package for review but it was
> pointed out to me that according to the new format of the naming for
> compat packages it should be named openssl1.1. However there already is
> a compat-openssl10 package.
>
> What is more important? Consistency between those two compat packages
> or strictly following the naming rules for the new package?
>

Please name it the new way. Otherwise we'll never finish switching over.


-- 
真実はいつも一つ!/ 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: Kubernetes Development SIG

2020-09-15 Thread Neal Gompa
On Tue, Sep 15, 2020 at 9:44 AM Leonardo Rossetti  wrote:
>
> Hello all,
>
> I would like to present a Kubernetes Development SIG.
>
> I initially thought of an "operator SIG" but I think a wider SIG about 
> programming components and services with Kubernetes APIs and internal 
> components made more sense (inspired by the "Programming Kubernetes" book).
>
> I am using some of the fields/titles described in this document [1] as the 
> proposal template.
>
> Proposal Name
> 
>
> SIG: Kubernetes Development
>
> Summary
> ===
>
> A SIG for people interested in using, developing, extending kubernetes for 
> Fedora components and services.
>

This sounds interesting. I'd be interested in participating in this.



-- 
真実はいつも一つ!/ 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: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

2020-09-14 Thread Neal Gompa
On Mon, Sep 14, 2020 at 2:34 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Mon, Sep 14, 2020 at 10:10:30AM -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches
> >
> > == Summary ==
> >
> > This Change proposal aims to enable shipping Rust crate packages
> > (rust-$CRATE_NAME) on release branches of fedora.
> > Currently, they are only available for rawhide, which makes building
> > Rust packages for release branches difficult.
>
> Should the update policy for rust-devel packages be relaxes in stable
> releases to allow updates to follow rawhide, at least if there are
> no major breaking changes?
>
> Current update policy states that major version changes should be avoided
> in after stable release. But rust upstreams tend to move quickly, so having
> ~1 year old packages in stable Fedora might not be too useful to build
> newest upstreams. It might make sense to allow the rust-*-devel packages
> to be updated more aggressively.
>

This is probably a good idea.



-- 
真実はいつも一つ!/ 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: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

2020-09-14 Thread Neal Gompa
On Mon, Sep 14, 2020 at 10:11 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches
>
> == Summary ==
>
> This Change proposal aims to enable shipping Rust crate packages
> (rust-$CRATE_NAME) on release branches of fedora.
> Currently, they are only available for rawhide, which makes building
> Rust packages for release branches difficult.
>
> == Owner ==
>
> * Name: [[User:decathorpe| Fabio Valentini]]
> * Email: 
>
>
> == Detailed Description ==
>
> Following the general upwards trend in the Rust language's popularity,
> more and more applications and services in fedora are written in Rust.
> This includes some CoreOS services, PARSEC, some nice command line
> tools (e.g. ripgrep, bat, fedora-update-feedback, ...), and parts of
> the GNOME stack.
> However, because rust crate packages are currently only available on
> rawhide, packaging rust applications for release branches is difficult
> and involves more steps than usual.
>
> This Change proposal aims to bring Rust packaging in line with the
> normal packaging workflows in fedora.
>
> In particular, the following additional steps will become obsolete:
>
> * use koji side tags for *every package build* on release branches
> * manual tagging and untagging of koji buildroot contents
>
> Instead, rust packages can be built like any other package in fedora.
>
>
> == Benefit to Fedora ==
>
> This Change lowers the bar for contributing to the Rust stack in
> fedora, because it will no longer be a special case that involves
> additional steps.
>
> It will also make it possible to build Rust packages for release
> branches locally in mock without the need for custom mock buildroot
> configurations and / or third-party repositories.
>
> == Scope ==
>
> * Proposal owner(s):
> ** one-off change: submit PR to revert the special-case handling for
> rust-* packages in the mass branching releng script
> ** ongoing effort: help package maintainers with merging changes from
> rawhide (where appropriate) and creating compat packages (when
> necessary) - this is made easier by the strong SemVer compatibility
> guarantees of Rust crates
>
> * Other developers:
>
> Initially, there is no impact on other developers.
> However, as soon as fedora 34 is branched, building Rust applications
> on that release branch will be easier than without this change.
> This will require packagers to merge rawhide updates into release
> branches when appropriate (again, bringing Rust packaging in line with
> the rest of fedora).
>
> I also expect there to be reduced load on koji due less side tags
> being in use concurrently, which will benefit all package maintainers
> in fedora.
>
> * Release engineering: [https://pagure.io/releng/issue/9753 #9753]
>
> Release engineering will need to remove special-case handling of
> rust-* packages from their mass branching script before
> f34 is branched off of rawhide.
>
> * Policies and guidelines:
>
> The Rust packaging Guidelines will need small adaptations.
>
> They are already outdated, so Change owner(s) will update them to the
> current state of Rust packaging regardless.
>
> * Trademark approval: N/A (not needed for this Change)
>
> * Alignment with Objectives:
>
> The fedora IoT Edition promotes PARSEC, which is comprised of Rust
> packages - its package maintainers will benefit from being able to
> update and build those packages faster and more easily for release
> branches.
>
> == Upgrade/compatibility impact ==
>
> There will be no impact on upgrades from previous fedora releases,
> since Rust crate packages will only be available for those users for
> the first time.
>
> If for some reason a user installed rust-*-devel packages
> manually after downloading them from the rawhide repositories, they
> will be gracefully upgraded.
>
> == How To Test ==
>
> Users should be able to build Rust applications for fedora 34 without
> workarounds or special steps (both in mock locally and in koji - both
> scratch and non-scratch builds).
>
> == User Experience ==
>
> Users should not notice this change. However, I expect some
> application updates to be available for release branches faster, since
> it will be easier for package maintainers to create them.
>
> == Dependencies ==
>
> N/A (this only affects the Rust package stack and has no external 
> dependencies)
>
> == Contingency Plan ==
>
> * Contingency mechanism: untag and block rust-* packages
> in the f34 tag in koji (help from releng / a koji admin required),
> revert mass branching script changes before f35 branch point
> * Contingency deadline: Final Freeze (removing packages from koji will
> no longer be possible after this point)
> * Blocks release? No (the initial Change is small and does not
> negatively affect release process)
> * Blocks product? N/A
>
> == Documentation ==
>
> The Packaging Guidelines for Rust will be updated to reflect this Change.
>
> == Release Notes ==
>
> TBD
>

+10

This will make life so 

[EPEL-devel] Re: Proposing an EPEL packaging SIG

2020-09-11 Thread Neal Gompa
On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood  wrote:
>
> Michel Alexandre Salim  writes:
>
> > * Have an expedited flow where this SIG can request EPEL branches and
> > admin access to packages if there are no response from package
> > maintainers for a set period (3 days? 1 week?)
> >   * whether it should be full admin access or whether such access
> > should be scoped to epel* branches can be discussed. Full admin would
> > make it possible to adjust the spec in Rawhide to be more EPEL
> > friendly, for example
>
> Unless I've missed something, we still don't have per-branch ACLs in
> dist-git.
>
> I don't think it's okay to force maintainers to give you admin or commit
> to their packages just because you want them in EPEL.
>
> (I'm also not one of the kind of people who really like having one spec
> file for all versions of the package, but I know others disagree with me
> on this.  Certainly if hypothetically I didn't want to maintain an EPEL
> package I wouldn't want its logic /also/ foisted on me in rawhide.)
>

We have per-branch ACLs in Dist-Git since early August. The
collaborator role in Pagure lets you grant people commit access for
specific branches.



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


Re: Proposing an EPEL packaging SIG

2020-09-11 Thread Neal Gompa
On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood  wrote:
>
> Michel Alexandre Salim  writes:
>
> > * Have an expedited flow where this SIG can request EPEL branches and
> > admin access to packages if there are no response from package
> > maintainers for a set period (3 days? 1 week?)
> >   * whether it should be full admin access or whether such access
> > should be scoped to epel* branches can be discussed. Full admin would
> > make it possible to adjust the spec in Rawhide to be more EPEL
> > friendly, for example
>
> Unless I've missed something, we still don't have per-branch ACLs in
> dist-git.
>
> I don't think it's okay to force maintainers to give you admin or commit
> to their packages just because you want them in EPEL.
>
> (I'm also not one of the kind of people who really like having one spec
> file for all versions of the package, but I know others disagree with me
> on this.  Certainly if hypothetically I didn't want to maintain an EPEL
> package I wouldn't want its logic /also/ foisted on me in rawhide.)
>

We have per-branch ACLs in Dist-Git since early August. The
collaborator role in Pagure lets you grant people commit access for
specific branches.



-- 
真実はいつも一つ!/ 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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

2020-09-10 Thread Neal Gompa
On Thu, Sep 10, 2020 at 9:34 PM John M. Harris Jr  wrote:
>
> On Thursday, September 10, 2020 1:36:18 AM MST alcir...@posteo.net wrote:
> > On Thu, 2020-09-10 at 01:02 -0700, John M. Harris Jr wrote:
> >
> > >
> > >
> > > A quick reminder that we're about to release with the system
> > > configured to use
> > > Google DNS when no DNS servers are configured. If privacy is valued
> > > at all,
> > > this needs to be addressed before release.
> >
> >
> >
> > These DNS addresses are bundled upstream in systemd. And they are used
> > in the event of a misconfiguration of your network settings, isn't it?
> > However they are easily customizable in /etc/systemd/resolved.conf
> > (FallbackDNS option)
> >
> > And for the records: https://github.com/systemd/systemd/issues/8782
> >
> > The same thing is true for system time and date (systemd default to
> > Google NTP servers). But as far as I can see it is already addressed
> > here
> > https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_329
>
> Regardless of Lennart's personal views, this is something that definitely
> merits some attention, and perhaps to be fixed before go-live. They're used
> whenever there are no configured DNS servers, not in the event of
> misconfiguration. Perhaps we should update /etc/systemd/resolved.conf to
> include "FallbackDNS=" system-wide? That would fix this behavior, for sure,
> and prevent the privacy issue for our users.
>

I'd rather have fallback DNS than no DNS by default.

> Why in the world would systemd have anything to do with NTP? We still use
> ntpd, do we not? Checking my system.. Nope, but it's chronyd. Still not
> systemd.
>

timesyncd is a simple NTP client for minimal Linux systems. We don't
use it, because chronyd is miles better.

> Also, looks like systemd is adding itself as a user and group database? This
> is probably a bug. Right?
>
> https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_655
>

No. nss-systemd has been a thing for many years. It was added so that
DynamicUsers= functionality for systemd units would work.




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


Re: The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-10 Thread Neal Gompa
On Thu, Sep 10, 2020 at 2:04 PM Daniel P. Berrangé  wrote:
>
> On Thu, Sep 10, 2020 at 01:37:41PM -0400, Neal Gompa wrote:
> > On Thu, Sep 10, 2020 at 1:30 PM Daniel P. Berrangé  
> > wrote:
> > >
> > > On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> > > > On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> > > > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> > > > >
> > > > > > 4.  The benefit we want to preserve from modules is to maintain 
> > > > > > packages
> > > > > > with varying expectation of quality, specifically separating the
> > > > > > build-time-only vs runtime dependencies.  e.g. in that case that a 
> > > > > > web
> > > > > > server like Eclipse Jetty is required as a dep for testing another
> > > > > > component during the build, we want to be able to use and build that
> > > > > > component, without being indefinitely on the hook for security 
> > > > > > errata.
> > > > > > (The build dependency tree is particularly complex for Maven and
> > > > > > involves many examples of packages with frequent and high severity
> > > > > > vulnerabilies)
> > > > >
> > > > > What are you doing different in terms of supporting deps in the module
> > > > > that reduces the security errata burden, compared to non-modular 
> > > > > builds ?
> > > > >
> > > > > It feels like if we have some policy that is creating unsustainable
> > > > > maint burden wrt non-modular packaging, we should re-examine this
> > > > > policy rather than trying to workaround it by going modular, which
> > > > > creates a different kind of maint burden.
> > > > >
> > > > In non-modular Fedora all packages that we have in Fedora build system 
> > > > (Koji)
> > > > are tagged into Fedora repositories and made available to all users on 
> > > > their
> > > > computers for any purpose. That implies that all packages in Fedora 
> > > > build system
> > > > must be fully supported including addressing all security issues.
> > > >
> > > > In modular Fedora that's (effectively) not true. Packages that only 
> > > > exist
> > > > for the sake of building other packages (i.e. build-only dependencies) 
> > > > can be
> > > > retained in the Fedora build system and never left it. That means those
> > > > packages are never made available to Fedora users and thus a service 
> > > > level for
> > > > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > > > integration, not tests, no API/ABI stability. The only requirement is 
> > > > that
> > > > they can be built and used for building other packages.
> > >
> > > So conceptually, one way we can solve this problem by implementing a way
> > > to mark certain non-modular RPMs as "build root only" packages and thus
> > > composing them into a separate "build root" yum repo, that is not enabled
> > > by default except in the build system.
> > >
> >
> > This is an anti-feature and I personally will not support any effort
> > to offer this in Fedora. That is just one step removed from not
> > shipping it at all to people, and I don't want it to be easy for us to
> > make that kind of decision.
>
> We already have this feature in Fedora via Modularity. If it is unacceptable
> for Fedora, we shouldn't do it in modules either, while if it is acceptable,
> then we should allow it for non-modular content.

It's not allowed there either. You are not supposed to do that, *period*.


-- 
真実はいつも一つ!/ 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: The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-10 Thread Neal Gompa
On Thu, Sep 10, 2020 at 1:30 PM Daniel P. Berrangé  wrote:
>
> On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> > On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> > >
> > > > 4.  The benefit we want to preserve from modules is to maintain packages
> > > > with varying expectation of quality, specifically separating the
> > > > build-time-only vs runtime dependencies.  e.g. in that case that a web
> > > > server like Eclipse Jetty is required as a dep for testing another
> > > > component during the build, we want to be able to use and build that
> > > > component, without being indefinitely on the hook for security errata.
> > > > (The build dependency tree is particularly complex for Maven and
> > > > involves many examples of packages with frequent and high severity
> > > > vulnerabilies)
> > >
> > > What are you doing different in terms of supporting deps in the module
> > > that reduces the security errata burden, compared to non-modular builds ?
> > >
> > > It feels like if we have some policy that is creating unsustainable
> > > maint burden wrt non-modular packaging, we should re-examine this
> > > policy rather than trying to workaround it by going modular, which
> > > creates a different kind of maint burden.
> > >
> > In non-modular Fedora all packages that we have in Fedora build system 
> > (Koji)
> > are tagged into Fedora repositories and made available to all users on their
> > computers for any purpose. That implies that all packages in Fedora build 
> > system
> > must be fully supported including addressing all security issues.
> >
> > In modular Fedora that's (effectively) not true. Packages that only exist
> > for the sake of building other packages (i.e. build-only dependencies) can 
> > be
> > retained in the Fedora build system and never left it. That means those
> > packages are never made available to Fedora users and thus a service level 
> > for
> > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > integration, not tests, no API/ABI stability. The only requirement is that
> > they can be built and used for building other packages.
>
> So conceptually, one way we can solve this problem by implementing a way
> to mark certain non-modular RPMs as "build root only" packages and thus
> composing them into a separate "build root" yum repo, that is not enabled
> by default except in the build system.
>

This is an anti-feature and I personally will not support any effort
to offer this in Fedora. That is just one step removed from not
shipping it at all to people, and I don't want it to be easy for us to
make that kind of decision.

It *barely* makes sense in RHEL and CentOS and has massively screwed
up things for CentOS SIGs (which are, with the exception of the Virt
SIG, all Red Hat teams) by making it impossible for the *projects* to
build their stuff on CentOS.

> Modularity is being used because it is the only solution that is available
> today, not because it is a good/desired solution.
>

Whether modularity is a good or bad solution is beside the point. The
problem here is that there is effectively zero official work in Fedora
by the numerous Java teams at Red Hat. With how much Red Hat is
involved in the Java ecosystem, Fedora should be a freaking paradise
for Java users and developers. It's almost the worst experience by a
fair margin due to lack of development and improvement in the tooling
and infrastructure to support the Java ecosystem.

Even *Rust* is a better experience than Java, and Rust is mostly
managed by Igor (with tiny bits from me, Josh, and a few others).




--
真実はいつも一つ!/ 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: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

2020-09-10 Thread Neal Gompa
On Thu, Sep 10, 2020 at 7:33 AM Richard Hughes  wrote:
>
> On Thu, 10 Sep 2020 at 10:17, Tom Hughes  wrote:
> > > Speaking from personal experience, I've wasted days over the last
> > > decade trying to debug a locally installed system service that was not
> > > working where there were no messages in any of the logs (e.g. no AVCs)
> > > -- and turning off selinux at runtime magically fixed the problem.
> >
> > Some selinux rules are marked to not generate AVCs...
>
> Why!? There's sometimes no log output anywhere obvious that a syscall
> or something was blocked. It's the reason I turn off selinux on my
> work development machine, and I've often wasted *hours* of my life on
> code "doing something impossible" over the last decade until a neuron
> at the back of my brain remembers "you've not yet turned off selinux"
> and then when I "sudo setenforce 0" it works, and I can't actually
> file a bug as there's no indication of what selinux actually blocked
> or why.
>

Because Red Hat customers put the SELinux policy developers into
no-win situations: they complain about AVC denials that don't actually
significantly break anything in *their* app and often just disable
SELinux in those scenarios. Red Hat wants customers to use it and not
freak out all the time, so these kinds of things get added because it
is very hard to come up with the right rules for all cases and there's
not enough time to work on that.

(I know for a fact that more than a few dontaudit rules were the
result of those kinds of conversations, because I witnessed them)




--
真実はいつも一つ!/ 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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-09 Thread Neal Gompa
On Wed, Sep 9, 2020 at 10:09 AM Neal Becker  wrote:
>
> I have tested kde/wayland on F32 but have hit a roadblock.  We are all 
> working from home and need to share screens.  Using google chrome, on X11 
> when I
> try to share an app window (which is my usual choice) there are no problems, 
> but on wayland only some of the windows are given as choices to share.  I 
> haven't
> found any particular pattern to which windows are listed (is it just from 
> certain desktops?)  I believe this isn't chrome specific (have to retest).
>
> Where can I report this issue?
>

Try here: 
https://bugs.kde.org/enter_bug.cgi?product=kwin=wayland-generic



-- 
真実はいつも一つ!/ 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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-08 Thread Neal Gompa
On Tue, Sep 8, 2020 at 12:57 PM Silvia Sánchez  wrote:
>
> Yes, I don't see KDE Wayland sufficiently mature to actually work as a 
> default.  It needs more work and testing.
>
> On Tue, 8 Sep 2020 at 18:33, Robert-André Mauchin  wrote:
>>
>> Please no, KWin Wayland makes my system crash as soon as I connect my second
>> screen, and does not support essential functions like Kwin scripting, make
>> Yakuake look terrible and the whole stuff feels buggy as hell.
>> Every time I used it thes past years, it felt buggy and in an unfinished
>> state, it was like being the tester of an alpha version.
>>

A lot of work has gone into solidifying the experience upstream, and
I'm currently running Plasma 5.18.5 on F32 (on Intel GPU system) and
Plasma 5.19.5 on F33 (on NVIDIA GPU system) and things are working
pretty well so far. The plan is to do the switch in Rawhide early and
work with KDE upstream to knock out the remaining issues to offer a
solid experience with the Plasma release we ship with Fedora 34 GA.
Based on the timelines, we're probably looking at 5.22 for F34 GA, but
I want to make the switch as part of importing the 5.20 beta next week
and give feedback ASAP.

The problem with the current situation is that if we *don't* do this,
there's no pressure to push things forward upstream and get everything
*working*. Doing this will force focus and priority to get everything
working. This strategy was employed to get GNOME Wayland in good shape
and we're in a better place now than GNOME was when the switch was
made in Fedora 25.




--
真実はいつも一つ!/ 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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-08 Thread Neal Gompa
On Tue, Sep 8, 2020 at 11:56 AM Erich Eickmeyer
 wrote:
>
> Hi Ben,
>
> On 9/8/2020 8:28 AM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma
> >
> > == Summary ==
> > Change the default session selection in SDDM to prefer the
> > Wayland-based KDE Plasma Desktop session over the X11-based one.
> >
> > == Owner ==
> > * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
> > [[User:Jgrulich|Jan Grulich]]
> > * Email: ngomp...@gmail.com, rdie...@gmail.com, jgrul...@redhat.com
> > * Product: KDE Spin
> > * Responsible WG: KDE SIG
> >
> >
> > == Detailed Description ==
> >
> > With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a
> > point where nearly all commonly used features in the desktop and all
> > major applications function in the Plasma Wayland environment on all
> > major GPUs (including NVIDIA with the proprietary driver). Starting
> > with Plasma 5.20 in Fedora 34, we will change the default
> > configuration for Wayland and X11 Plasma sessions so that Wayland is
> > preferred and used by default, while permitting the X11 session to be
> > selected as the alternative desktop environment option.
> >
> > == Feedback ==
> >
> >  Is Wayland ready? 
> > Wayland has been used by default for Fedora Workstation (which uses
> > GNOME) since Fedora 25. And while it was somewhat immature initially,
> > today it is a very rock-solid experience on virtually everything
> > Fedora Workstation runs on. The change in Fedora 25 kickstarted the
> > drive to get everything working on Wayland, and the Workstation team
> > succeeded beyond their wildest dreams. Firefox has been Wayland-native
> > by default since Fedora 31 as well.
> >
> > On the KDE side, serious work into supporting Wayland started shortly
> > after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
> > much broader stack in its toolkit, and it has taken longer to get to a
> > usable state. With the Plasma 5.20 release, the Wayland protocol for
> > screencasting as well as middle-click paste finally are supported,
> > completing the required feature set for switching to Wayland by
> > default.
> >
> >  What about NVIDIA? 
> > Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
> > driver on Wayland. It needs to be manually activated, which will be
> > taken care of by the kwin-wayland-nvidia package. So the
> > expectation is that all major GPUs will work just fine.
> >
> >  Why not keep using X11? 
> > The fact of the matter is, Xorg is in
> > [https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/
> > "hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
> > development on it has basically stopped beyond the most critical of
> > fixes. Combined with the rapid maturation of the Wayland session in
> > KDE Plasma, this is the best time to make the switch and push things
> > over the edge for the KDE ecosystem in the same way that Fedora
> > Workstation did for the GNOME ecosystem.
> >
> > == Benefit to Fedora ==
> > Fedora has long been a leader in advancing the adoption of the Wayland
> > protocol as part of the overall strategy to improve the Linux
> > graphical software stack. Much of the quality of Wayland for GNOME can
> > be attributed to the work done by the Fedora Workstation WG as part of
> > advancing the GNOME platform. It is now the KDE SIG's turn to do the
> > same for the KDE platform. By making this change, we are helping push
> > the adoption forward for newer, more streamlined, and overall more
> > actively developed graphics technology for the KDE ecosystem.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Modify {{package|kwin}} to switch to Wayland
> > *** Split out /usr/bin/kwin_x11 to the
> > kwin-x11 subpackage.
> > *** Make {{package|kwin}} require kwin-wayland and
> > recommend kwin-x11
> > *** Add kwin-wayland-nvidia subpackage which contains
> > /usr/lib/environment.d/10-kwin-wayland-nvidia.conf to set
> > $KWIN_DRM_USE_EGL_STREAMS to 1. This package
> > will have have a Supplements dependency (kwin-wayland and
> > kmod-nvidia).
> > ** Modify {{package|plasma-workspace}} to switch to Wayland
> > *** Rename /usr/share/xsessions/plasma.desktop to
> > /usr/share/xsessions/plasma-xorg.desktop, subpackage it
> > out as plasma-workspace-xorg, and have it require
> > kwin-x11
> > *** Rename /usr/share/wayland-sessions/pla

Re: BTRFS, relatime vs. noatime

2020-09-07 Thread Neal Gompa
On Mon, Sep 7, 2020 at 8:30 AM Kamil Paral  wrote:
>
> On Sun, Sep 6, 2020 at 1:37 AM Chris Murphy  wrote:
>>
>> But if you've got a snapshot once per day, times ten days, and this kind of 
>> aggressive search function touching every file? Maybe an extra 1-2G of 
>> metadata being pinned
>
>
> I don't follow. If you have one master copy and 10 snapshots, and you change 
> the metadata on the master copy, why would it generate more metadata (than 
> when having a single snapshot)? All those snapshots can share the same 
> metadata block (provided the file wasn't changed in the meantime) and just 
> the master copy would get a new metadata block. So it should be the same 
> amount of newly written blocks, regardless of how many snapshots you have. 
> What am I missing?

When you have snapshots, you initially share all the same blocks.
However, as you continue to make changes, fewer of the blocks are
shared as new blocks are allocated for new changes. This is also true
for metadata, except that this situation results in the filesystem
making new instances of the metadata for most of its files. However,
because you have snapshots, the old instances cannot be deleted
either. Thus, you wind up with essentially a new copy of the
filesystem metadata. This is amplified as you take more snapshots.

This is the *expensive* part of snapshots and the part that people
don't necessarily realize: when you take a snapshot, you're asking for
the preservation of the entire filesystem tree, with all its data. If
you take a snapshot, then change the atimes of all the files, take a
snapshot again, then change the atimes again, you wind up having two
whole unshared instances of the filesystem snapshotted. It's
essentially the worst case scenario for filesystem metadata.

Of course, this is cheap to *make*, but expensive to *keep* as you run
out of space due to just having so many unique copies of filesystem
metadata. This is why it's often recommended that atimes are switched
off on parts of the filesystem you wish to aggressively snapshot. For
example, most of the time you don't really care about atimes for /usr
and /etc, so you can turn atimes off for that, while leaving it on for
/var and /home.

Now, we are not setting up snapshotting automatically in Fedora like
openSUSE does, so there's not as much pressure to deal with it now.
But if we make a straightforward way for people to set up
snapshotting, then part of that strategy needs to include dealing with
that problem.



-- 
真実はいつも一つ!/ 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: BTRFS, relatime vs. noatime

2020-09-05 Thread Neal Gompa
On Sat, Sep 5, 2020 at 8:30 AM Neal Becker  wrote:
>
>
> If BTRFS is to become fedora default, we should consider this?
>
> "BTRFS relatime vs. noatime - Huge Performance Difference - linux" 
> https://www.reddit.com/r/linux/comments/imgler/btrfs_relatime_vs_noatime_huge_performance/?utm_source=amp_medium=_content=post_body
>

It's something that's being looked at, see
https://pagure.io/fedora-btrfs/project/issue/9



-- 
真実はいつも一つ!/ 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: About the Future of Communishift

2020-09-04 Thread Neal Gompa
On Fri, Sep 4, 2020 at 7:10 AM clime  wrote:
>
> On Fri, 4 Sep 2020 at 12:59, clime  wrote:
> >
> > On Fri, 4 Sep 2020 at 12:48, Aoife Moloney  wrote:
> > >
> > > Good Morning Everyone,
> > >
> > > I wanted to share with you some information regarding the current
> > > state and future of Communishift. The infrastructure team presented on
> > > this project back in 2019 during Nest [1] [2], and since then, we have
> > > deployed it, started using it and had to shut it down for
> > > the colo-move.
> > >
> > > As a number of people have noted, it has not come back up yet, and
> > > during Nest this year, we had hinted that communishift is not going to
> > > come back alive looking
> > > the same as when we shut it down, and that is unfortunately true.
> > >
> > > The idea for communishift was to give to anyone in the community a place 
> > > where
> > > they could run any application they wish to provide to the community.
> > > This was a proper place where Joe and Jane could offer the service foo to 
> > > the
> > > foo SIG without engaging the infrastructure's team responsibility to keep 
> > > the
> > > service up and running. The infrastructure team would have been able to 
> > > say:
> > > "well the openshift cluster is running, so if the app isn't, talk to the
> > > application maintainer, there is nothing we can do about it".
> > >
> > > Basically, it gave a place where we could experiment with new apps
> > > without adding too
> > > much work to the infrastructure team.
> > >
> > > However, the General Data Protection Regulation (GDPR) [3] and the 
> > > California
> > > Consumer Privacy Act (CCPA) [4] basically makes the Fedora Infrastructure 
> > > team
> > > (and thus Red Hat) responsible for the content hosted by any services 
> > > running in
> > > our infrastructure. In other words, the Fedora Infrastructure team would 
> > > be
> > > responsible to answer all GDPR/CCPA related requests and requirements for 
> > > any
> > > and all services running in communishift (services that the team has 0 
> > > knowledge
> > > about, that's the whole goal of communishift).
> > >
> > > For these reasons communishift is not going to come back to life in the 
> > > same way
> > > it was shut down for the colo move.
> > >
> > > We have not given up on the original idea though (ie: providing a place 
> > > where
> > > community members can deploy applications without adding work on the
> > > infrastructure team), however, as with anything involving legal, this is 
> > > going
> > > to be a slow process. We will share any information as soon as we are 
> > > able.
> > >
> > >
> > > We're sorry for the inconvenience this causes, we really would like the
> > > situation to be different but we also appreciate these regulations for 
> > > what they
> > > are (protecting our personal information) so we want to respect them.
> > >
> > >
> > > Hoping this clarifies the situation around communishift a bit.
> > >
> > > Aoife, Kevin & Pingou
> > >   - On behalf of the Fedora Infrastructure team
> >
> > Hello Aoife,
> >
> > is it working right now so that I can deploy my community app there or
> > currently not working at all?
>
> Or better...is there at least some alternative or some way to deploy a
> community app
> these days? Or currently none. :)
>

My read of this is that right now, there will be no way for the
community to run applications in Fedora Infrastructure in a way that
CPE can be divorced from it completely. That is because their goal of
running only OpenShift and then not caring about what's inside is
legally not possible.

Consequently, when the OpenShift cluster returns (if it even does, I
am unsure that it will, since running multiple OpenShift clusters
doesn't make sense anymore), it will require a vetting process of some
kind (that has yet to be created) to ensure that CPE is comfortable
with partial responsibility of the application, since they need to
care about the data it stores.

So, I guess... wait and see?



--
真実はいつも一つ!/ 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 33 Beta - Possible Blocker?

2020-09-02 Thread Neal Gompa
On Wed, Sep 2, 2020 at 2:23 PM Matthew Miller  wrote:
>
> On Thu, Aug 27, 2020 at 02:52:25PM -0700, Erich Eickmeyer wrote:
> > This is just very disappointing [3]. Unless there is a huge delay in
> > the beta timeline due to *actual* blockers, we've got no beta to
> > test since this is 1-2 weeks out due to further testing needed [2].
> > So, unless this minor Koji release gets expedited, I've done a ton
> > of hard work and nothing to show for it.
>
> Yeah, disappointing our spins maintainers like this isn't living up to our
> goals. Can this particular thing be worked-around in the kickstart %post for
> beta, instead of using `bootloader --append`?
>

There's a FBR (freeze break request) to patch all the builders to fix
this problem[1], but I don't know if it has been applied yet.

[1]: 
https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/7M3DLZCPKOKTMJGHJE3Z54LLPWRVEVYS/



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

2020-09-02 Thread Neal Gompa
On Wed, Sep 2, 2020 at 6:05 AM Vít Ondruch  wrote:
>
>
> Dne 01. 09. 20 v 19:54 Tom Hughes via devel napsal(a):
> > On 01/09/2020 18:29, kevin wrote:
> >
> >> Just to make sure folks know, the retrace server being down is not this
> >> teams fault, it's ours (infrastructure). We planned to just have it down
> >> for a week or less when moving it to RDU, but it turned out that
> >> datacenter move was not at all what we hoped for and it's been down much
> >> longer than intended.
> >>
> >> That said, we have a machine up now there and it's just needing
> >> configuration/setup to get the service back up and running. :)
> >> So, hopefully soon it will again be online.
> >
> > Hasn't it effectively been down for like a year anyway? What was
> > the last release it could actually retrace? 30? or was it 31?
>
>
> The retrace server was not able to handle the backtraces since we
> started to use zstd to compress RPMs.
>

That stopped being a valid reason back in April, since RHEL 8 supports
zstd compressed RPMs with the RHEL 8.2 release.


-- 
真実はいつも一つ!/ 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: systemd-resolved

2020-09-01 Thread Neal Gompa
On Tue, Sep 1, 2020 at 10:51 PM Nico Kadel-Garcia  wrote:
>
> On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr  
> wrote:
> >
> > On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote:
> > > On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
> > >  wrote:
> > >
> > > > Michael,
> > > >
> > > > The file is /etc/nsswitch.conf.
> > >
> > >
> > > You're wasting everyone's time with these low-effort spam posts.
> >
> > I don't see how this could possibly be spam. This is where the file is, is 
> > it
> > not?
> >
> > > Lest  anyone become confused, there is a big warning at the top of that 
> > > file
> > > warning you that it is managed by authselect, and that manual changes
> > > will be overwritten.
> >
> > I don't know what you're talking about here. Am I missing something? Is 
> > this a
> > F33 Change? Exact content of my /etc/nsswitch:
>
> Stated in the file or not, it is in fact edited by authconfig,
> sometimes as part of RPM installation. Manual editing of it is not and
> has never been stable without setting up some kind of configuration
> management to restore RPM based modifications. Been there, done that,
> with one of those 10-year solo admins who decided to hand-edit tweaks
> but refused to permit management of the file.
>
> And oh, "files" always comes first because local config files should
> always take priority over upstream network based services.

authconfig is dead. But yes, nsswitch is managed by authselect.



-- 
真実はいつも一つ!/ 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: Make nano the default editor

2020-08-30 Thread Neal Gompa
On Sun, Aug 30, 2020 at 8:15 PM Chris Murphy  wrote:
>
> Fedora-Silverblue-ostree-x86_64-33-20200830.n.0.iso does not have nano
> on the install media itself. Is it intentional?
>

It's supposed to be there, but I don't know how Silverblue is
"defined" so it would be pulled in. I thought it'd get it from the
comps groups...




--
真実はいつも一つ!/ 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 33 Beta - Possible Blocker?

2020-08-26 Thread Neal Gompa
On Wed, Aug 26, 2020 at 10:08 PM Erich Eickmeyer
 wrote:
>
> HI all,
>
> Since the release of Koji 1.22, there has been a bug [1] blocking any
> Fedora Jam 33 or Rawhide iso images from being spun. As you can imagine,
> this is making me quite nervous. As it turns out, I'm waiting for Koji
> 1.22 to be released so that images can start building again. If this
> isn't done in time for beta, then that means Fedora Jam will be unable
> to participate in beta testing.
>

If you'd like this fix backported to Fedora's Koji instance ASAP, you
should file a ticket with the infrastructure team here:
https://pagure.io/fedora-infrastructure/issues

I did this for the Btrfs stuff a while back:
https://pagure.io/fedora-infrastructure/issue/9138

> The issue in question is caused because Jam adds "threadirqs" as a boot
> argument in addition to the normal boot arguments. This is a way to add
> some low-latency characteristics to a kernel that isn't otherwise a
> lowlatency kernel and is known to cut-down on xruns in audio production.
>
> However, one question came up as to if threadirqs is a default in the
> kernel configuration, but nobody could answer that. I was wondering if
> anyone on this list knew?
>

threadirqs are not default in the Fedora kernel, as far as I recall.

Contrary to popular belief, CONFIG_IRQ_FORCED_THREADING=y does not
default to threaded IRQs. It only enables the ability to turn them on
by passing "threadirqs" as a kernel parameter. Yes, I know this is
stupid and makes no sense, but Kconfigs are not designed to make
sense...

I don't know if there's a good reason for them _not_ to be on by
default, though. It doesn't really cause a significant impairment in
almost every case I can think of...

> I'm also going to be a little more intentional with working with the
> pipewire developers on figuring out jack compatibility issues during the
> F34 release cycle.
>

Isn't the idea that PipeWire would replace JACK and PulseAudio for
most, if not all, cases in the Fedora 34 timeframe? The pace of
development there seems to indicate some very intentional drive toward
that.



-- 
真実はいつも一つ!/ 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: Python spec template violates guidelines?

2020-08-26 Thread Neal Gompa
On Wed, Aug 26, 2020 at 6:25 PM Michel Alexandre Salim
 wrote:
>
> On Wed, 2020-08-26 at 15:16 -0700, Michel Alexandre Salim wrote:
> > On Wed, 2020-08-26 at 20:23 +0200, Miro Hrončok wrote:
> > >
> > > I don't really know who maintains `rpmdev-newspec python-foo` but
> > > the
> > > output
> > > (when I run this on Fedora 32) is really severely outdated beyond
> > > being any
> > > useful. I remember trying to update the template many years ago but
> > > got stuck at
> > > EPEL-compatibility issues.
> > >
> > Neal maintains rpmdevtools, both on src.fp.o and on Pagure
> >
> > I'll get a PR in to make the Python spec a bit more up to date. This
> > brings to mind that I've been intendeing to have a spec template and
> > a
> > packaging guideline for Lua for a while; that can go next.
> >
> So:
> F32 has rpmdevtools 8.10, which was first released... over three years
> ago
>
> * Sat Jan 14 2017 Ville Skyttä  - 8.10-1
>
> The spec in pagure is updated (including a patch Miro committed last
> year), but looks like it's only built for F33 and F34 right now.
>
> Neal, we should be able to release this for F32, right? Most packagers
> are likely to still be on it rather than on the recently branched F33
> so it probably would save some review time.
>

I am not releasing rpmdevtools 9.x to F32 or older because I've
changed default behaviors for 9.0 and replaced the spectool
implementation.



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


Re: Python spec template violates guidelines?

2020-08-26 Thread Neal Gompa
On Wed, Aug 26, 2020 at 6:25 PM Michel Alexandre Salim
 wrote:
>
> On Wed, 2020-08-26 at 15:16 -0700, Michel Alexandre Salim wrote:
> > On Wed, 2020-08-26 at 20:23 +0200, Miro Hrončok wrote:
> > >
> > > I don't really know who maintains `rpmdev-newspec python-foo` but
> > > the
> > > output
> > > (when I run this on Fedora 32) is really severely outdated beyond
> > > being any
> > > useful. I remember trying to update the template many years ago but
> > > got stuck at
> > > EPEL-compatibility issues.
> > >
> > Neal maintains rpmdevtools, both on src.fp.o and on Pagure
> >
> > I'll get a PR in to make the Python spec a bit more up to date. This
> > brings to mind that I've been intendeing to have a spec template and
> > a
> > packaging guideline for Lua for a while; that can go next.
> >
> So:
> F32 has rpmdevtools 8.10, which was first released... over three years
> ago
>
> * Sat Jan 14 2017 Ville Skyttä  - 8.10-1
>
> The spec in pagure is updated (including a patch Miro committed last
> year), but looks like it's only built for F33 and F34 right now.
>
> Neal, we should be able to release this for F32, right? Most packagers
> are likely to still be on it rather than on the recently branched F33
> so it probably would save some review time.
>

I am not releasing rpmdevtools 9.x to F32 or older because I've
changed default behaviors for 9.0 and replaced the spectool
implementation.



-- 
真実はいつも一つ!/ 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: Release criteria proposal: networking requirements

2020-08-25 Thread Neal Gompa
On Tue, Aug 25, 2020 at 8:33 PM Michael Catanzaro  wrote:
>
> On Tue, Aug 25, 2020 at 4:11 pm, Adam Williamson
>  wrote:
> > Do NetworkManager and its current KDE and GNOME front ends support it
> > currently?
>
> Rumor has it that KDE has this working!

The rumor is true! WireGuard has been supported in plasma-nm since Plasma 5.14.

It'd be nice to add validation for WireGuard to the criteria, but do
we have a WireGuard VPN to test with?

> But GNOME doesn't support it yet. Help welcome in these bugs:
>
> https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/982
> https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2989
>
> Now, does wireguard work with systemd-resolved? *shrug* dunno!

It *should* work, since that part is managed by NetworkManager...


-- 
真実はいつも一つ!/ 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: What is the real value of Release and %changelog metadata?

2020-08-25 Thread Neal Gompa
On Tue, Aug 25, 2020 at 3:26 PM kevin  wrote:
>
> On Tue, Aug 25, 2020 at 12:57:34PM -0400, Neal Gompa wrote:
> > On Tue, Aug 25, 2020 at 12:54 PM Matthew Miller
> >  wrote:
> > >
> > > On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote:
> > > > That makes it extra steps to see changelogs on a not-installed package.
> > > > I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog foo"
> > > > (for example, to see what is changed since my installed version).
> > > > Converting to an installed file means I would have to extract the RPM
> > > > (possibly after manually downloading) and find it under a different
> > > > directory for every RPM - much less convenient.
> > >
> > > A dnf plugin could be made which shows metadata like this from
> > > src.fedoraproject.org or bodhi or some other source.
> > >
> >
> > That's not helpful beyond Fedora, though. When it's forked into RHEL
> > or CentOS, that changelog history from Fedora is preserved today. RHEL
> > forks Fedora at the git level, so generated changelogs from Git will
> > still work, and since CentOS gets SRPM imports into its Dist-Git,
> > they'll be flattened into %changelog sections as appropriate. But if
> > we rely on a web service to get changelogs, we screw over that
> > particular transition path.
>
> Sure, but how often is that changelog:
>
> "Updated to 10.0.1"
>
> or
>
> "Fixed typo"
>
> I pretty much stopped reading changelogs a while back.
> Looking at the upstream NEWS or announcement is better for releases, and
> just looking at the git commits is better for isolating some change in
> packaging.

I do the opposite. I almost never read upstream news or changelog
files. They just don't matter in most cases when I'm trying to figure
out problems. Those timelines in the packaging changelogs are a good
record of how the package itself has evolved, and sure, most of the
time it's just updating to a new version, but those checkpoints are
useful too.

And in the Fedora -> RHEL -> CentOS case, we do not have those
relationships with Git commits, so the changelog entries are the only
way to figure out packaging deltas and such.



--
真実はいつも一つ!/ 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: What is the real value of Release and %changelog metadata?

2020-08-25 Thread Neal Gompa
On Tue, Aug 25, 2020 at 12:54 PM Matthew Miller
 wrote:
>
> On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote:
> > That makes it extra steps to see changelogs on a not-installed package.
> > I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog foo"
> > (for example, to see what is changed since my installed version).
> > Converting to an installed file means I would have to extract the RPM
> > (possibly after manually downloading) and find it under a different
> > directory for every RPM - much less convenient.
>
> A dnf plugin could be made which shows metadata like this from
> src.fedoraproject.org or bodhi or some other source.
>

That's not helpful beyond Fedora, though. When it's forked into RHEL
or CentOS, that changelog history from Fedora is preserved today. RHEL
forks Fedora at the git level, so generated changelogs from Git will
still work, and since CentOS gets SRPM imports into its Dist-Git,
they'll be flattened into %changelog sections as appropriate. But if
we rely on a web service to get changelogs, we screw over that
particular transition 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: Proposed Modular Policy for Fedora ELN

2020-08-24 Thread Neal Gompa
On Mon, Aug 24, 2020 at 10:17 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> We use fedora-obsolete-packages to remove packages from end-user systems.
> Users can opt-out of installation of fedora-obsolete-packages and retain
> packages that would be obsoleted [*].
>
> The same mechanism could be used RHEL, for example by having 
> 'rhel-is-up-to-date.rpm'
> installed by default, with newer versions doing the obsoletes for packages
> that have been dropped. Users *may* stop the upgrade of rhel-is-up-to-date,
> but then they know their system is using outdated packages. DNF will even
> nicely tell them which ones.
>
> This is: a) simple, b) well-understood, c) already implemented.
>
> Zbyszek
>
> [*] Right now fedora-obsolete-packages has 
> Provides:libsolv-self-destruct-pkg(),
> so this muddies the situation a bit. Let's assume that the packages in RHEL
> would not have that set.

Note that exclusion should also work even with the self-destruct
property, since exclusion means it no longer gets computed in solver
transactions at all.




--
真実はいつも一つ!/ 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: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird

2020-08-24 Thread Neal Gompa
On Mon, Aug 24, 2020 at 8:52 AM Fabio Valentini  wrote:
>
> On Mon, Aug 24, 2020 at 2:45 PM Neal Gompa  wrote:
> >
> > On Mon, Aug 24, 2020 at 8:42 AM Fabio Valentini  
> > wrote:
> > >
> > [...]
> > > - appliance-tools is newer in 32 than in 33:
> > >   0:010.1-1.fc32 > 0:010.0-3.fc33
> >
> > Something is wrong here, as Bodhi automatically submitted it yesterday
> > to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f6a9b16a4
>
> It's possible that the repo mirror I hit hasn't gotten this update push yet.
> I'll re-run the script later (or the day after tomorrow, after the
> beta freeze) and file bugs for the remaining downgrades.
>

No, something is definitely wrong, because last night's F33 compose
also had the same problem. I literally released that to attempt to fix
image builds yesterday and it wasn't even used.


-- 
真実はいつも一つ!/ 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: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird

2020-08-24 Thread Neal Gompa
On Mon, Aug 24, 2020 at 8:42 AM Fabio Valentini  wrote:
>
[...]
> - appliance-tools is newer in 32 than in 33:
>   0:010.1-1.fc32 > 0:010.0-3.fc33

Something is wrong here, as Bodhi automatically submitted it yesterday
to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f6a9b16a4


-- 
真実はいつも一つ!/ 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: non-verbose %ctest

2020-08-21 Thread Neal Gompa
On Fri, Aug 21, 2020 at 4:55 PM Christoph Junghans  wrote:
>
> Hi,
>
> The new %ctest macro generates so much output, it sometimes makes it
> hard to find the actual failure. Especially with gtest, where you have
> many tests in one executable and multiple executables run at the same
> time..
>
> Is there a way to drop the "--verbose" option?
> "%ctest --quiet" works but suppresses all outputs.
> "%ctest --no-verbose" does nothing.
> I would just like the normal "ctest --output-on-failure" behavior back.
>

Originally, there was no --verbose option passed to ctest when I added
the %ctest macro precisely because of that reason, but CMake
maintainers added it afterward. I suspect they prefer it that way,
since it's all typically just stuffed into a log and they want *all
the output*.

Maybe file a bug report asking for the option to removed from the
default parameters passed to ctest?




--
真実はいつも一つ!/ 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-review fails due to no annobin in mock

2020-08-21 Thread Neal Gompa
On Fri, Aug 21, 2020 at 5:15 AM Artur Iwicki  wrote:
>
> Today I tried reviewing some Python packages:
> - x-tile: https://bugzilla.redhat.com/show_bug.cgi?id=1861020
> - python-iptools: https://bugzilla.redhat.com/show_bug.cgi?id=1870907
>
> And the mock build done by fedora-review failed. The error message I got was:
> > line XX: fg: no job control
> Which means that RPM didn't recognize the "%py3_build" macro and left it 
> as-is, so bash then saw "%" and tried to do job control and failed.
>
> I checked the logs for both failed reviews, and looking at root.log, neither 
> review installed python3-rpm-macros, which is where "%py3_build" and 
> "%py3_install" come from. Now, looking at python3.9.spec, there's this bit:
> > Requires: (python3-rpm-macros if rpm-build)
>
> So right now I'm inclined to think that maybe when fedora-review calls mock, 
> and mock installs BuildRequires, it doesn't install them in the rpm-build 
> context? This would explain both the Python and the C/C++ failures, since 
> like python3-rpm-macros, annobin isn't required for "user" builds, but is 
> used for RPM builds.

That's a little bizarre, because rpm-build should be installed in the
mock environment (otherwise, how does rpmbuild work?), so
python3-rpm-macros should get installed.


-- 
真実はいつも一つ!/ 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: Koji doesn't work due 'No space left on device'

2020-08-20 Thread Neal Gompa
On Thu, Aug 20, 2020 at 8:08 AM Zdenek Dohnal  wrote:
>
> Hi all,
>
> Koji seems to be broken now. Builds/scratch builds fail with:
>
> Fault: : [Errno 28] No space left on device:
> '/mnt/koji/work/tasks/6134/49706134'">
>
> Links to build:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=49706133
>
> Do we have a ticket for this outage?
>

Yes, we do.

The releng ticket: https://pagure.io/releng/issue/9701
The fedora-infra ticket: https://pagure.io/fedora-infrastructure/issue/9253

Unfortunately, NetApp storage quota needs to be raised, which is
outside of Fedora Infra control:
https://pagure.io/fedora-infrastructure/issue/9254



--
真実はいつも一つ!/ 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: Bumping library soname in F33?

2020-08-18 Thread Neal Gompa
On Tue, Aug 18, 2020 at 10:13 AM Richard Hughes  wrote:
>
> Hi all,
>
> I maintain a library that's bumped soname upstream (libxmlb) that is
> used just by gnome-software and fwupd in Fedora. Both users would just
> need recompiling against the new ABI as they already have the right
> #ifdefs in place. I'm intending to do this for F34 now it's been
> branched, but is F33 also okay to update this point? The ABI bump
> allows gnome-software to start about 40% faster and to use a less
> memory when idle. It's not really a feature as I understand it, just a
> case of updating a library with two deps.
>

Yes, since you own all the consumers. go for it, just announce it on the list.


-- 
真実はいつも一つ!/ 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: Debug doxygen generated files with different names in noarch package

2020-08-17 Thread Neal Gompa
On Mon, Aug 17, 2020 at 5:25 PM Richard Shaw  wrote:
>
> On Fri, Aug 14, 2020 at 6:07 PM Rich Mattes  wrote:
>>
>> I downloaded the i686-generated doc package,
>> dir_dd208edd458824e9eaf902c6da16200d.html is the directory that contains
>> zipios-config.h.  That file is generated from a template by CMake, and
>> is located in the root of the build folder (which is now
>> %{_vpath_builddir}.  So it's going to be different on every arch.  I'm
>> also seeing the file path to zipios-config.h that includes the
>> %{_vpath_builddir} folder in the some of the images generated for the
>> dependency graphs.
>>
>> Your above patch is filtering out CMAKE_CURRENT_BINARY_DIR, which I
>> think points the doc/ subdirectory of the build tree, since the doxyfile
>> is configured in the doc/CMakeLists.txt, not the root CMakeLists.txt.
>> Perhaps try using @PROJECT_BINARY_DIR@ instead.
>
>
> I tried adding both the _CURRENT_ and base paths for both SOURCE and BINARY 
> to no avail...
>
>
>>
>> Is it possible to override %{_vpath_builddir} to just be "build" on all
>> architectures (e.g. "%global _vpath_builddir build" at the top of a spec?)
>
>
> Perhaps, but then I might as well disable it because that's what I had in 
> place until I was forced to change it... Bah.
>

I spent a bit of time trying to get doxygen to not incorporate the
build dir into its hashes, but gave up and overrode %_vpath_builddir
instead.

Here's the commit:
https://src.fedoraproject.org/rpms/zipios/c/37e97cc5aa53b53865852a888d7f6261dac49f96?branch=master

I did a scratch build and that worked:
https://koji.fedoraproject.org/koji/taskinfo?taskID=49493357

Real build is occurring right now:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1594316




--
真実はいつも一つ!/ 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: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

2020-08-15 Thread Neal Gompa
On Sat, Aug 15, 2020 at 11:30 AM Paul Howarth  wrote:
>
> On Sat, 15 Aug 2020 16:28:47 +0200
> Fabio Valentini  wrote:
> > - autoreconf fails because %build needs a newer shell (protobuf):
> >
> > /usr/bin/autoconf: This script requires a shell more modern than all
> > /usr/bin/autoconf: the shells that I found on your system.
> > /usr/bin/autoconf: Please tell bug-autoc...@gnu.org about your system,
> > /usr/bin/autoconf: including any error possibly output before this
> > /usr/bin/autoconf: message. Then install a modern shell, or manually
> > run /usr/bin/autoconf: the script under such a shell if you do have
> > one. autoreconf: /usr/bin/autoconf failed with exit status: 1
> >
> > - shell not executing stuff in backticks `command foo` but returns
> > empty string (tonto):
> > `build-classpath foo` # this doesn't work?
> >
> >
> > I'm getting the sinking feeling that RPM scriptlets are broken? Do
> > they get run in the wrong shell? sh instead of bash maybe?
> >
> > I'm grasping at straws here, but all those build failures are starting
> > to be really disruptive to the work that I'm actually trying to do ...
>
> I had an issue with a configure script wanting a more modern shell. I
> tried running mock with --isolation-simple and it stopped complaining.
> Maybe that would help you too?
>

Running in simple isolation fixes it for me. This makes me think that
this was broken by the following change listed in the current Rawhide
glibc[1]:

- Linux: Use faccessat2 to implement faccessat (bug 18683)

I suspect that this change is not compatible with nspawn, which is
mock's default mode of operation.

[1]: https://koji.fedoraproject.org/koji/buildinfo?buildID=1592537

-- 
真実はいつも一つ!/ 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: Non-responsive maintainer check for bochecha

2020-08-14 Thread Neal Gompa
On Fri, Aug 14, 2020 at 6:03 PM Michael Catanzaro  wrote:
>
>
> Hi,
>
> I believe Mathieu is temporarily unavailable. If you don't hear back
> soon, it makes sense to proceed with nonresponsive maintainer procedure
> if you want to take over the buildstream package, or ask a
> provenpackager to help.
>
> (Also note the buildstream package is mostly useless without
> bst-external, which is unfortunately not packaged in Fedora because
> upstream requested it not be packaged)
>

Wait, what?! Why would we respect such a request and package something
that's "mostly useless" then?


-- 
真実はいつも一つ!/ 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: Unannounced soname bump: libreport

2020-08-14 Thread Neal Gompa
On Fri, Aug 14, 2020 at 11:12 AM Fabio Valentini  wrote:
>
> On Fri, Aug 14, 2020 at 5:01 PM Michael Schwendt  wrote:
> >
> > On Fri, 14 Aug 2020 16:37:28 +0200, Fabio Valentini wrote:
> >
> > > > As a side note, the update now has arch specific BuildRequires, so the 
> > > > SRPM
> > > > cannot be rebuilt on anything but .
> > > >
> > > > https://koschei.fedoraproject.org/package/libreport?collection=f33
> > >
> > > Aaaw ... stuff like this makes me sad :(
> >
> > What makes me sad is the poorly maintained package %changelog. Instead of
> > summing up changes to the RPM package, it sums up changes internal to
> > libreport. It does not list any of the spec file changes.
> >
> > A massive commit to the package without any %changelog entry:
> > https://src.fedoraproject.org/rpms/libreport/c/246d3174118e03cbb345f1d434f3fbe11864b015?branch=master
>
> True. This is bad :( This is also the commit that added %{?_isa} to
> BuildRequires. WHYYY
>
> > And later the addition of a %changelog entry that doesn't cover any of the
> > package changes.
>
> It's also for the wrong version (2.13-2 instead of 2.14-2) ... which
> was fixed in the next commit, with another Release bump. :(

As far as I know, libreport is directly synced from the
libreport.spec.in in the libreport git repo on GitHub:
https://github.com/abrt/libreport/blob/master/libreport.spec.in

I am unsure if ABRT folks are even reviewing stuff going on in Dist-Git...




-- 
真実はいつも一つ!/ 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: EarlyOOM +ZRAM Only

2020-08-14 Thread Neal Gompa
On Fri, Aug 14, 2020 at 7:34 AM John M. Harris Jr  wrote:
>
> On Wednesday, August 12, 2020 1:16:34 PM MST Przemek Klosowski via devel
> wrote:
> > On 8/12/20 2:27 PM, Sergio Belkin wrote:
> >
> > > Hi!
> > > I 've just had a problem using EarlyOOM + ZRAM. I haven't a disk-based
> > > swap partition.
> > > I was using mainly Zoom (desktop app) + Firefox + VirtualBox (Debian
> > > with 4GB of RAM), and EarlyOOM killed Zoom in the middle of a call :(
> >
> >
> > This is weird---your swap was 100% full, and ram almost full, and yet
> > killing 4GB VirtualBox didn't seem to free up memory. I suspect some
> > sort of measurement or reporting error---if these numbers were accurate,
> > EarlyOOM did have a reason to panic and kill zoom. BTW, zoom taking 721
> > MiB is crazy.
> >
> > One possibility that comes to mind is that there's a process not
> > mentioned in the log (some system process???) that keeps allocating
> > memory as soon as it is freed by EarlyOOM, so killing the processes does
> > not result in increasing free memory (the first column).
> >
> > 399 of 15887 MiB ( 2.51%) SIGTERM "Web Content": badness 315, VmRSS 313 MiB
> > 397 of 15887 MiB ( 2.50%) SIGTERM "Web Content": badness 304, VmRSS 80 MiB
> > 379 of 15887 MiB ( 2.39%) SIGTERM "Web Content": badness 303, VmRSS 74 MiB
> > 335 of 15887 MiB ( 2.11%) SIGTERM "Web Content": badness 303, VmRSS 70 MiB
> > 315 of 15887 MiB ( 1.98%) SIGTERM "Web Content": badness 301, VmRSS 27 MiB
> > 288 of 15887 MiB ( 1.81%) SIGTERM "VirtualBoxVM":badness 212, VmRSS 4244
> > MiB 337 of 15887 MiB ( 2.13%) SIGTERM "zoom":badness 36, VmRSS 721
> > MiB
> > Note how the full log helpfully mentions the actual tresholds for
> > SIGTERM: mem 2.52%, swap 10%, Where does 2.52 come from, pray?
>
> Are you kidding? The system still had over a quarter of a gigabyte of free
> RAM. There's no reason to start killing off processes at that point. That's
> tons of free memory. To put that into perspective, that's enough free memory
> to store over 1000 average-length novels directly in memory.
>

It's also enough to store 1/8th of a significantly complex Electron
process. It's *not enough*. Text is a terrible comparison when we're
working with programs.



-- 
真実はいつも一つ!/ 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: Deprecation of Anaconda boot parameters without inst. prefix

2020-08-13 Thread Neal Gompa
On Thu, Aug 13, 2020 at 9:43 AM  wrote:
>
> On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote:
> > On Thu, 13 Aug 2020 at 08:58, Fabio Valentini 
> > wrote:
> > > On Thu, Aug 13, 2020 at 2:16 PM  wrote:
> > > > Hello everyone,
> > > >
> > > > Anaconda team has decided to deprecate use of Anaconda kernel
> > > > boot
> > > > parameters without 'inst.' prefix. As you may already know you
> > > > can
> > > > specify Anaconda kernel boot parameters both with and without
> > > > 'inst.'
> > > > prefix (e.g. 'inst.repo=' or 'repo='). This deprecation means
> > > > that when
> > > > you use Anaconda option without the 'inst.' prefix you will now
> > > > get a
> > > > warning. We are *not* disabling parameters without a prefix yet.
> > > >
> > > > The reason for this is keep running into parameter conflicts with
> > > > other
> > > > projects. As an example there is 'debug' parameter for both
> > > > kernel and
> > > > us, so when you want to enable kernel debugging in installation
> > > > environment you will also enable Anaconda debug mode.
> > > >
> > > > Because of this I have created the following pull request for
> > > > Anaconda:
> > > >
> > > > https://github.com/rhinstaller/anaconda/pull/2786
> > > >
> > > >
> > > > In case you have any objections please start discussion either on
> > > > the
> > > > pull request or here.
> > > >
> > > >
> > > > Best regards,
> > > > Jirka
> > >
> > > This may be a stupid question, but why are parameter namespaced
> > > with
> > > "inst." and not with "anaconda."? Is this a historical artifact?
> > > "inst" is a pretty generic term as well, and "anaconda" would
> > > definitely not lead to parameter overloading on the kernel cmdline.
> > >
> >
> > I think inst was meant to be universal so that debian etc could use
> > it. However I will say if I have to type 20 anaconda.= on
> > a serial terminal like I have to for the inst.= I will
> > quickly be looking for any other installer to use. I regularly end up
> > with enough redraw problems because the line went over whatever SOL
> > or
> > the HTML-console thinks a line should be and clearing the entire line
> > so I can't see what I am typing.
>
> I wasn't in the team when the decision to use `inst.` was made.
> However, I agree with Stephen that it's just shorter and some people
> have to write this a lot and lot of times. Also, it could be used for
> multiple installers if they want to.
>

It was intended to be a standard interface. And I'm pretty sure these
flags were created at around the same time that Anaconda was being
ported to Debian and having a generic prefix meant that
debian-installer could implement it. I don't know if d-i today
actually *does* have these, but I'm pretty sure that was the reason.

Though the cross-installer compatibility idea inspired the creation of
kickseed[1] for Debian and Ubuntu years later, too..

[1]: https://launchpad.net/kickseed

-- 
真実はいつも一つ!/ 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: Draft of New Python Packaging Guidelines - 0.2

2020-08-12 Thread Neal Gompa
On Wed, Aug 12, 2020 at 12:02 PM Petr Viktorin  wrote:
>
> On 2020-08-12 17:22, Neal Gompa wrote:
> > On Wed, Aug 12, 2020 at 11:19 AM Petr Viktorin  wrote:
> >>
> >> On 2020-08-12 16:53, Neal Gompa wrote:
> >>> On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin  
> >>> wrote:
> >>>>
> >>>> I'll move some discussion here, where it doesn't become part of the
> >>>> document:
> >>>>
> >>>>>
> >>>>> On 2020-08-11 14:19, Petr Viktorin wrote:
> >>>>>> These Guidelines represent a major rewrite and paradigm shift, and not
> >>>>>> all packages are updated to reflect this.
> >>>>>> Older guidelines are still being kept up to date, and existing packages
> >>>>>> **MAY** use them instead of this document:
> >>>>>> * 201x-era [Python packaging
> >>>>>> guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/)
> >>>>>> (for packages that use e.g. `%py3_install` or `setup.py install`)
> >>>>>> * [Python 2
> >>>>>> appendix](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages)
> >>>>>> (for e.g. `%py2_install`) (Python 2 packages require a FESCo 
> >>>>>> exception.)
> >>>>
> >>>> @Conan-Kudo:
> >>>>> Is there something you've done here to make the new macros 
> >>>>> unequivocally better? Do you have automated flavor builds, for example? 
> >>>>> Right now there is no effective difference.
> >>>>
> >>>>
> >>>> The new macros allow other build tools than just setuptools.
> >>>> They also use upstream metadata for BuildRequires & file lists.
> >>>>
> >>>> Of course, where possible the changes were backported to the existing
> >>>> macros. I don't necessarily see the macros as the main thing that
> >>>> changes. But when you look at a specfile, you can usually tell what
> >>>> conventions it uses by what macros you see.
> >>>>
> >>>
> >>> Those are all nice things, for sure. I think it'd be important to
> >>> spell that out somewhere.
> >>
> >> Do you mean providing a summary of the changes between the existing
> >> guidelines and these?
> >>
> >
> > Yes. Also indicating the *why* for pyproject stuff is useful within
> > the context of why the old macros are deprecated.
>
> Is that necessary for the beta release of the packaging guidelines?
> (i.e. when they would be in effect, but optional?)
>
> You're asking for quite a lot of work around describing a document that
> might still change.
>
>

I am only asking for what makes sense if the document as it stands
were to be finalized.

> >>>>>> ## PyPI parity
> >>>>>>
> >>>>>> Every Python package in Fedora **SHOULD** also be available
> >>>>>> on [the Python Package Index](https://pypi.org) (PyPI).
> >>>>>>
> >>>>>> The command `pip install PROJECTNAME` **MUST** install the same package
> >>>>>> (possibly in a different version),
> >>>>>> install nothing,
> >>>>>> or fail with a reasonable error message.
> >>>>>>
> >>>>>> If this is not the case, the packager **MUST** contact upstream about 
> >>>>>> this.
> >>>>>> The goal is to get the project name registered or blocked on PyPI,
> >>>>>> or to otherwise ensure the rule is followed.
> >>>>>>
> >>>>>> To block a project name on PyPI, email
> >>>>>> [ad...@pypi.org](mailto:ad...@pypi.org),
> >>>>>> giving the project name and explaining the situation
> >>>>>> (for example: the package cannot currently be installed via `pip`).
> >>>>>> You can ask questions and discuss the process at the [Python
> >>>>>> Discourse](https://discuss.python.org/t/block-names/4045).
> >>>>>>
> >>>>>>> NOTE: Project names that were in Fedora but not on PyPI
> >>>>>>> when these guidelines were proposed
> >>>>>>> are *blocked* from being uploaded to PyPI.
> >>>>>>> This prevents potential trolls from ta

Re: Draft of New Python Packaging Guidelines - 0.2

2020-08-12 Thread Neal Gompa
On Wed, Aug 12, 2020 at 11:19 AM Petr Viktorin  wrote:
>
> On 2020-08-12 16:53, Neal Gompa wrote:
> > On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin  wrote:
> >>
> >> I'll move some discussion here, where it doesn't become part of the
> >> document:
> >>
> >>>
> >>> On 2020-08-11 14:19, Petr Viktorin wrote:
> >>>> These Guidelines represent a major rewrite and paradigm shift, and not
> >>>> all packages are updated to reflect this.
> >>>> Older guidelines are still being kept up to date, and existing packages
> >>>> **MAY** use them instead of this document:
> >>>> * 201x-era [Python packaging
> >>>> guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/)
> >>>> (for packages that use e.g. `%py3_install` or `setup.py install`)
> >>>> * [Python 2
> >>>> appendix](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages)
> >>>> (for e.g. `%py2_install`) (Python 2 packages require a FESCo exception.)
> >>
> >> @Conan-Kudo:
> >>> Is there something you've done here to make the new macros unequivocally 
> >>> better? Do you have automated flavor builds, for example? Right now there 
> >>> is no effective difference.
> >>
> >>
> >> The new macros allow other build tools than just setuptools.
> >> They also use upstream metadata for BuildRequires & file lists.
> >>
> >> Of course, where possible the changes were backported to the existing
> >> macros. I don't necessarily see the macros as the main thing that
> >> changes. But when you look at a specfile, you can usually tell what
> >> conventions it uses by what macros you see.
> >>
> >
> > Those are all nice things, for sure. I think it'd be important to
> > spell that out somewhere.
>
> Do you mean providing a summary of the changes between the existing
> guidelines and these?
>

Yes. Also indicating the *why* for pyproject stuff is useful within
the context of why the old macros are deprecated.

> >>>> ## PyPI parity
> >>>>
> >>>> Every Python package in Fedora **SHOULD** also be available
> >>>> on [the Python Package Index](https://pypi.org) (PyPI).
> >>>>
> >>>> The command `pip install PROJECTNAME` **MUST** install the same package
> >>>> (possibly in a different version),
> >>>> install nothing,
> >>>> or fail with a reasonable error message.
> >>>>
> >>>> If this is not the case, the packager **MUST** contact upstream about 
> >>>> this.
> >>>> The goal is to get the project name registered or blocked on PyPI,
> >>>> or to otherwise ensure the rule is followed.
> >>>>
> >>>> To block a project name on PyPI, email
> >>>> [ad...@pypi.org](mailto:ad...@pypi.org),
> >>>> giving the project name and explaining the situation
> >>>> (for example: the package cannot currently be installed via `pip`).
> >>>> You can ask questions and discuss the process at the [Python
> >>>> Discourse](https://discuss.python.org/t/block-names/4045).
> >>>>
> >>>>   > NOTE: Project names that were in Fedora but not on PyPI
> >>>>   > when these guidelines were proposed
> >>>>   > are *blocked* from being uploaded to PyPI.
> >>>>   > This prevents potential trolls from taking them,
> >>>>   > but it also blocks legitimate owners.
> >>>>   > If your package is affected, contact the Python SIG
> >>>>   > or [file a PyPA
> >>>> issue](https://github.com/pypa/pypi-support/issues/new?labels=PEP+541=pep541-request.md=PEP+541+Request%3A+PROJECT_NAME)
> >>>>
> >>>>   > and mention `@encukou`.
> >>>>
> >>>> This is necessary to protect users,
> >>>> avoid confusion,
> >>>> and enable automation as Fedora and upstream ecosystems grow more
> >>>> integrated.
> >>>>
> >>>> As always, [specific exceptions can be granted by the Packaging
> >>>> Committee](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy).
> >>
> >>
> >> @Conan-Kudo:
> >>> This is not reasonable to ask of packagers to do. Such a check is 
> >>> difficult to do, and the

Re: Draft of New Python Packaging Guidelines - 0.2

2020-08-12 Thread Neal Gompa
On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin  wrote:
>
> I'll move some discussion here, where it doesn't become part of the
> document:
>
> >
> > On 2020-08-11 14:19, Petr Viktorin wrote:
> >> These Guidelines represent a major rewrite and paradigm shift, and not
> >> all packages are updated to reflect this.
> >> Older guidelines are still being kept up to date, and existing packages
> >> **MAY** use them instead of this document:
> >> * 201x-era [Python packaging
> >> guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/)
> >> (for packages that use e.g. `%py3_install` or `setup.py install`)
> >> * [Python 2
> >> appendix](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_python_2_packages)
> >> (for e.g. `%py2_install`) (Python 2 packages require a FESCo exception.)
>
>
> @Conan-Kudo:
> > Is there something you've done here to make the new macros unequivocally 
> > better? Do you have automated flavor builds, for example? Right now there 
> > is no effective difference.
>
>
> The new macros allow other build tools than just setuptools.
> They also use upstream metadata for BuildRequires & file lists.
>
> Of course, where possible the changes were backported to the existing
> macros. I don't necessarily see the macros as the main thing that
> changes. But when you look at a specfile, you can usually tell what
> conventions it uses by what macros you see.
>

Those are all nice things, for sure. I think it'd be important to
spell that out somewhere.

> >
> >> ## PyPI parity
> >>
> >> Every Python package in Fedora **SHOULD** also be available
> >> on [the Python Package Index](https://pypi.org) (PyPI).
> >>
> >> The command `pip install PROJECTNAME` **MUST** install the same package
> >> (possibly in a different version),
> >> install nothing,
> >> or fail with a reasonable error message.
> >>
> >> If this is not the case, the packager **MUST** contact upstream about this.
> >> The goal is to get the project name registered or blocked on PyPI,
> >> or to otherwise ensure the rule is followed.
> >>
> >> To block a project name on PyPI, email
> >> [ad...@pypi.org](mailto:ad...@pypi.org),
> >> giving the project name and explaining the situation
> >> (for example: the package cannot currently be installed via `pip`).
> >> You can ask questions and discuss the process at the [Python
> >> Discourse](https://discuss.python.org/t/block-names/4045).
> >>
> >>  > NOTE: Project names that were in Fedora but not on PyPI
> >>  > when these guidelines were proposed
> >>  > are *blocked* from being uploaded to PyPI.
> >>  > This prevents potential trolls from taking them,
> >>  > but it also blocks legitimate owners.
> >>  > If your package is affected, contact the Python SIG
> >>  > or [file a PyPA
> >> issue](https://github.com/pypa/pypi-support/issues/new?labels=PEP+541=pep541-request.md=PEP+541+Request%3A+PROJECT_NAME)
> >>
> >>  > and mention `@encukou`.
> >>
> >> This is necessary to protect users,
> >> avoid confusion,
> >> and enable automation as Fedora and upstream ecosystems grow more
> >> integrated.
> >>
> >> As always, [specific exceptions can be granted by the Packaging
> >> Committee](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy).
>
>
> @Conan-Kudo:
> > This is not reasonable to ask of packagers to do. Such a check is difficult 
> > to do, and there is no particularly compelling reason for making everything 
> > written in Python using Python build system available in PyPI. Unless you 
> > plan to provide an automated system to inform PyPI of these things, this is 
> > not only unreasonable, it is unenforceable.
>
> A lot of stuff in the guidelines is unenforceable, so let's focus on the
> "unreasonable" part.
>
> There is no reason to have everything available on PyPI, but I do
> believe it's reasonable to *reserve the name* in such cases.
>
> Here's a reason why I want this:
>
> The issue here is that Python tools have access to project names. For
> example, I can get the version of Requests using:
>
>  >>> from importlib.metadata import version
>  >>> version('requests')
> '2.22.0'
>
> Things like this are only useful if we use a common namespace. Upstream,
> that namespace *is* PyPI; there's little we can do about that.
> If project names mean something else in Fedora than in the wider
> ecosystem, we'll get user confusion at best.
>
> (If you use a private package index, like they do at CERN or some
> closed-source shops, there can be some collisions -- but in that case
> there's a limited number of software authors and users, and a lot more
> control over the package set. Conflicts in global repositories of
> free/open-source software are much harder to manage.)
>
>
>
> Lately, I think about another way to handle this: packages that aren't
> on PyPI could not ship the .dist-info at all, and so, they would not
> have things like `python3dist(...)` provides. They'd only be usable with
> Fedora tooling, not 

Re: Help needed to fix a FTBFS (shaderc)

2020-08-08 Thread Neal Gompa
On Sat, Aug 8, 2020 at 3:47 PM Robert-André Mauchin  wrote:
>
> On Saturday, 8 August 2020 17:27:54 CEST you wrote:
> >
> > And so on.
> > Tons of errors regarding undefined reference to glslang::.
> > I don't know if this is due to a new Glslang or if something has been
> > changed wrt the build system, or if system-wide libraries are not supported
> > anymore.
> >
> > Any help for figuring out what happened would be greatly appreciated.
> >
> > Best regards,
> >
> > Robert-André
> >
>
> I have the same issue with another FTBFS, soundkonverter:
>
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:215: undefined reference to `TagLib::String::String(char
> const*, TagLib::String::Type)'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:215: undefined reference to `TagLib::String::~String()'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:216: undefined reference to `TagLib::String::String(char
> const*, TagLib::String::Type)'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:216: undefined reference to `TagLib::String::~String()'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:217: undefined reference to `TagLib::String::String(char
> const*, TagLib::String::Type)'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:217: undefined reference to `TagLib::String::~String()'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:220: undefined reference to `TagLib::String::String(char
> const*, TagLib::String::Type)'
> /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function
> `readXiphTags(TagLib::Ogg::XiphComment*)':
> /usr/include/c++/10/bits/stl_function.h:386: undefined reference to
> `TagLib::String::operator<(TagLib::String const&) const'
> /usr/bin/ld: /usr/include/c++/10/bits/stl_function.h:386: undefined reference
> to `TagLib::String::operator<(TagLib::String const&) const'
> /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function
> `readXiphTags(TagLib::Ogg::XiphComment*)':
> /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/MetaReplayGain.cpp:
> 220: undefined reference to `TagLib::String::~String()'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:222: undefined reference to `TagLib::String::String(char
> const*, TagLib::String::Type)'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:222: undefined reference to `TagLib::String::~String()'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:223: undefined reference to `TagLib::String::String(char
> const*, TagLib::String::Type)'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:223: undefined reference to `TagLib::String::~String()'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:224: undefined reference to `TagLib::String::String(char
> const*, TagLib::String::Type)'
> /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> MetaReplayGain.cpp:224: undefined reference to `TagLib::String::~String()'
> /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function
> `TagLib::Map::~Map() [clone .lto_priv.0]':
> /usr/include/c++/10/bits/stl_pair.h:211: undefined reference to
> `TagLib::StringList::~StringList()'
> /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o:/usr/include/c++/10/
> bits/stl_pair.h:211: undefined reference to `TagLib::String::~String()'
>
> Is it related to the cmake change? Am I missing something obvious?
>

That looks like failures related to LTO?



-- 
真実はいつも一つ!/ 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: Test machines for s390x?

2020-08-06 Thread Neal Gompa
On Thu, Aug 6, 2020 at 2:00 PM Adam Williamson
 wrote:
>
> On Thu, 2020-08-06 at 13:42 -0400, Robbie Harwood wrote:
> > Elliott Sales de Andrade  writes:
> >
> > > Hi,
> > >
> > > Now that ppc64 is gone, s390x is the only big-endian architecture
> > > left. Bugs around endianness are not usually difficult to fix, _if_ I
> > > can debug it and see where exactly the problem is. However, this
> > > requires a tedious guess-a-patch, try a scratch build, check the
> > > result, rinse and repeat.
> > >
> > > Mock (with --forcearch) is completely useless for this. The programs
> > > just crash during the build in such a way that I can't even use
> > > `catchsegv`, and gdb is unusable in the container. And besides, the
> > > programs don't actually crash on real s390x anyway..
> > >
> > > Just like we have test machines for other less used architectures [1],
> > > I am wondering if there is some way we can spin up a test machine for
> > > s390x?
> > >
> > > [1] 
> > > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
> >
> > It's very strange to me that having test hardware available isn't a
> > requirement for being a Primary architecture, or for that architecture
> > being present in koji.  IMO we should change that going forward.
>
> s390x isn't a primary arch. It's an alternative arch.
>
> https://fedoraproject.org/wiki/Architectures

That page is out of date. All architectures are effectively primary
now, since failures for any arch block builds from releasing in Koji.



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


Summary/Minutes from yesterday's FESCo Meeting (2020-08-05)

2020-08-06 Thread Neal Gompa
=
#fedora-meeting-2: FESCO (2020-08-05)
=


Meeting started by King_InuYasha at 14:03:44 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-08-05/fesco.2020-08-05-14.03.log.html
.



Meeting summary
---
* init process  (King_InuYasha, 14:06:21)

* #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros -
  Detached rpm changelogs  (King_InuYasha, 14:09:43)
  * LINK:
https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz
(nirik, 14:23:20)
  * LINK: https://paste.centos.org/view/f4ffc88f   (sgallagh, 14:24:48)
  * proposal 1: accept #2440 sans detached changelogs (+5, 1, -2)
(King_InuYasha, 15:05:37)
  * proposal 2: accept #2440 with detached changelogs (+0, 1, -7)
(King_InuYasha, 15:07:01)
  * AGREED: : accept #2440 sans detached changelogs, that is detached
changelogs are not allowed for Fedora  (King_InuYasha, 15:07:50)
  * proposal 1: accept #2440 sans detached changelogs (+5, 2, -2)
(King_InuYasha, 15:08:45)
  * AGREED: : accept #2440 sans detached changelogs, that is detached
changelogs are not allowed for Fedora  (King_InuYasha, 15:09:11)

* Next week's chair  (King_InuYasha, 15:09:50)
  * ACTION: mhroncok will chair next meeting  (King_InuYasha, 15:10:29)

* Open Floor  (King_InuYasha, 15:10:36)

* #2452 F33 Self-Contained Change: Policy for Modules in Fedora and
  Fedora ELN  (King_InuYasha, 15:20:16)
  * AGREED: sgallagh will update the policy PR accordingly, notify
devel@, and we'll discuss next week  (King_InuYasha, 15:48:43)

* Open Floor  (King_InuYasha, 15:49:02)

Meeting ended at 15:50:03 UTC.




Action Items

* mhroncok will chair next meeting




Action Items, by person
---
* mhroncok
  * mhroncok will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* King_InuYasha (117)
* mhroncok (77)
* sgallagh (64)
* zbyszek (47)
* dcantrell (44)
* nirik (29)
* decathorpe (27)
* zodbot (15)
* cverna (10)
* ignatenkobrain (5)
* cyberpear (2)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)




Generated by `MeetBot`_ 0.1.4

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




-- 
真実はいつも一つ!/ 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: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

2020-08-06 Thread Neal Gompa
On Thu, Aug 6, 2020 at 7:12 AM Richard Shaw  wrote:
>
> On Thu, Aug 6, 2020 at 5:35 AM Neal Gompa  wrote:
>>
>> On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm  wrote:
>> >
>> > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa  wrote:
>> > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa  wrote:
>> > > > > You are not supposed to use %__cmake_builddir.
>> > >
>> > > It is not documented, and eventually will be removed. So don't rely on
>> > > it. If you want to change the build directory, set %_vpath_builddir
>> > > instead.
>> >
>> > Well, just make it documented ?
>> >
>>
>> The %_vpath_builddir macro is *already* documented:
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/
>
>
> Ok, that helps, but it's rather non-intuitive that it's not with the CMake 
> packaging guidelines. A link would be nice from there would be nice.
>

It is linked from the CMake packaging guidelines page, the hyperlink labeled
"Defining source and build directories" points to that page.




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


  1   2   3   4   5   6   7   8   9   10   >