Re: Shouldn't we have process for removing zombie packages?

2020-09-18 Thread Vít Ondruch

Dne 18. 09. 20 v 12:37 Petr Pisar napsal(a):
> On Fri, Sep 18, 2020 at 10:42:00AM +0200, Vít Ondruch wrote:
>> This is not about nagging maintainer for the purpose of nagging them.
>>
> Filing the requests en mass is exactly nagging for nagging.


This might be misunderstanding, but I have never proposed filling
request en mass. I have proposed to have process to remove package when
somebody is in doubt it provides any value.


>  But
>
>> I feel exhausted seeing again and again packages which are very likely
>> broken,
> if the package is broken, then file a bug. That's a completely different
> case.
>
>> serving no purpose.
> That's a strong assertion. I hope that you know that a non-existance is not
> getting proved by claiming "I think there is none". But again, if you don't
> like the package, file a bug with the explanation why you think it should be
> removed.
>
>> I feel exhausted seeing that these packages pull in dependency chains which
>> are not possible to be updated or removed due to them.
>>
> If you need to update the dendency, then update the dependency and report
> a bug against the then broken package. See openssl package for an example.
>
> All I want to say that these issues should be handled case by case. There
> should be a reason for each of them and the bug report should be tailored to
> that case.


I agree with that and proposing that once the bug is filled, there
should be a way for the reporter to finish the job what the reporting of
bug starts. So your worries are not justified.


Vít


> But pushing the work of a responsible bug report from the reporter
> to the assignee is wrong.
>
> -- Petr
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Shouldn't we have process for removing zombie packages?

2020-09-18 Thread Vít Ondruch

Dne 18. 09. 20 v 10:24 Petr Pisar napsal(a):
> On Thu, Sep 17, 2020 at 09:09:51PM +0200, Vít Ondruch wrote:
>> Dne 17. 09. 20 v 18:29 Kevin Fenzi napsal(a):
>>> Well, many maintainers don't touch packages that keep working and don't
>>> need updates or bugfixes.
>> That is perfectly fine and I expect that in such cases, the maintainer
>> would step up and responded to BZ, explained situation and intentions,
>> everything would be documented and we could move on. But maintainers
>> also does not touch packages, because the keep building and that is
>> different situation.
>>
> I think that nagging maintainers with "Do you want to keep your package in
> Fedora" question is too burdensome for the maintainers and a disservice for
> the users.


This is not about nagging maintainer for the purpose of nagging them.


>
>>> So, if we know the package doesn't work, we
>>> should file a bug on it. If not, I am not sure if we should try and
>>> remove such packages. 
>> Just out of curiosity, I filed this bug:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1880144
>>
>> I used to see a lot of similar packages in Ruby land. Nowadays, they are
>> finally gone, because somebody used the non-responsive maintainer policy
>> in the end. But I don't want to use non-responsive maintainer policy,
>> because I think some package does not serve it purpose anymore.
>>
> How exactly does a presence of that package offend you?


Maybe because I am maintainer of ruby and rubygem-sinatra and I do care
if packages which depends on them keep working? And just FTR, I came to
rubygem-sinatra-rabbit checking that rubygem-haml is broken. Please note
that I am not maintainer of that package, but I do care about Ruby in
Fedora in general.


> That relengs have to
> rebuild it twice a year? That you have to download the few kilobytes in
> repodata? That when you change Ruby packaging standards, you have to patch the
> spec file?
>
> I think that a package should be removed for a real issue that it causes. Not
> because of its age.


I agree, and "old" was not the best term. "zombie" is much better
probably. I used that term right in the first paragraph of the original
email. It already got lost here. I update the subject to be more clear.


>
>> Actually, maintaining 200 packages myself, it might happen that some of
>> them are in zombie state. I would not mind if they were called out via
>> this process.
>>
> Then start with yourself. Go and file bugs for your 200 packages. Then review
> whether they are used by Fedora users. Be ware that Fedora packager is not
> a Fedora user. And then close the bugs or retire the packages. And then come
> and tell us how much fruitful it was and how much productive you were.
>
> If you feel exhausted by maintaingin the 200 packages, then orphan them.
> Fedora already has a process for dealing with unmaintained packages.
> A spoiler: Eventually they will be removed from the distribution.


You get it wrong. I feel exhausted seeing again and again packages which
are very likely broken, serving no purpose. I feel exhausted seeing that
these packages pull in dependency chains which are not possible to be
updated or removed due to them.


Vít




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Shouldn't we have process for removing old packages?

2020-09-17 Thread Vít Ondruch

Dne 17. 09. 20 v 18:29 Kevin Fenzi napsal(a):
> On Thu, Sep 17, 2020 at 12:39:28PM +0200, Vít Ondruch wrote:
>> Looking at rubygem-sinatra-rabbit [1], I wonder if we should not have
>> process for removing "zombie" packages.
>>
>> The issue with this package is that while it keeps building, it is very
>> likely not working. The `%check` suite is disable for ages already.
>> Upstream is dead. I know I could open BZ questioning the utility of such
>> packages and maybe I would get some answer or maybe I would not get any
>> answer. The thing is that if the package was properly maintained, the
>> test suite would not be disabled, the package would be updated to recent
>> packaging standards and what not. But that have not happened past
>> several years. Therefore I doubt I would get any reasonable answer in BZ
>> ticket.
> Well, many maintainers don't touch packages that keep working and don't
> need updates or bugfixes.


That is perfectly fine and I expect that in such cases, the maintainer
would step up and responded to BZ, explained situation and intentions,
everything would be documented and we could move on. But maintainers
also does not touch packages, because the keep building and that is
different situation.


> So, if we know the package doesn't work, we
> should file a bug on it. If not, I am not sure if we should try and
> remove such packages. 


Just out of curiosity, I filed this bug:

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

I used to see a lot of similar packages in Ruby land. Nowadays, they are
finally gone, because somebody used the non-responsive maintainer policy
in the end. But I don't want to use non-responsive maintainer policy,
because I think some package does not serve it purpose anymore.

Actually, maintaining 200 packages myself, it might happen that some of
them are in zombie state. I would not mind if they were called out via
this process.


Vít




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Shouldn't we have process for removing old packages?

2020-09-17 Thread Vít Ondruch
Looking at rubygem-sinatra-rabbit [1], I wonder if we should not have
process for removing "zombie" packages.

The issue with this package is that while it keeps building, it is very
likely not working. The `%check` suite is disable for ages already.
Upstream is dead. I know I could open BZ questioning the utility of such
packages and maybe I would get some answer or maybe I would not get any
answer. The thing is that if the package was properly maintained, the
test suite would not be disabled, the package would be updated to recent
packaging standards and what not. But that have not happened past
several years. Therefore I doubt I would get any reasonable answer in BZ
ticket.

Anyway, the process could be like:

1) Open BZ ticket questioning utility of such packages, blocking some
"ZOMBIE" tracker.

2) Ask opinion on fedora-devel.

3) If there were no negative responses in the ticket (or some other
activity making sure the package is in good shape) for one month, the
package would get orphaned.

4) The package could be later collected as orphaned package.

I know we have unresponsive maintainer policy, but I don't care much if
somebody is responsive or not, I care about specific packages. At the
end, if the packages are removed one by one, there won't be need for
unresponsive maintainer call.


Vít


P.S. take the rubygem-sinatra-rabbit just as an example, there are other
packages which are in zombie state which I stumble upon now and then.



[1] https://src.fedoraproject.org/rpms/rubygem-sinatra-rabbit

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaning rubygem-erubis

2020-09-17 Thread Vít Ondruch
Hi,

I have orphaned rubygem-erubis. It is dead upstream for almost 10 years
and it is FTBFS with every major version of Ruby. There is available
rubygem-erubi, which is properly maintained and most of the projects
already switched. The only remaining dependency in Fedora is
rubygem-asciidoctor, where there is upstream fix available and I have
prepared PR backporting the fix into Fedora [1]. It is time to let this
package go.


Vít



[1] https://src.fedoraproject.org/rpms/rubygem-asciidoctor/pull-request/4
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proposing an EPEL packaging SIG

2020-09-14 Thread Vít Ondruch

Dne 14. 09. 20 v 15:01 Vít Ondruch napsal(a):
> Dne 14. 09. 20 v 12:03 Pierre-Yves Chibon napsal(a):
>> On Mon, Sep 14, 2020 at 10:35:18AM +0200, Vít Ondruch wrote:
>>> Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a):
>>>> On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote:
>>>>> Reading this proposal and with the EPEL8 experience, where there was not
>>>>> even wiki page, where I could state that I don't care about EPEL and I
>>>>> had to reply into every BZ independently, wouldn't it make sense to move
>>>>> EPEL into its own dist-git namespace?
>>>>>
>>>>> I guess that in the CVS days, having EPEL branch was fine. During PkgDB
>>>>> days, where we could assign maintainer to each branch, it was still
>>>>> fine. But since we lost this ability, isn't it time to rethink the
>>>>> setup?
>>>> We have the ability back, see the answers from Neal Gompa.
>>> Well, yes, right. But apparently, it is not fully working. E.g. looking
>>> at Ruby [1], it says I am EPEL maintainer while there is certainly not
>>> EPEL branch. Also, there might be EPEL maintainer (actually Pagure lists
>>> just BZ assignee), but I am not sure if they are listed between
>>> "members" or not. I cannot set my preferred default. So there is still
>>> lot to desire.
>> You're speaking about the bugzilla overrides, that in practice are entirely
>> separated from granting access to the epel* branches to someone.
>> If you go on the project's settings, click to add an user or group, you'll 
>> see
>> the "collaborator" access level with which you can give someone commit access
>> on one or more branches (comma separated or using a pattern, for example 
>> epel*).
>
> Ok, nice. Didn't know this because one could find it by accident.
>
> Trying this, I immediately got "Fatal Error (500)" and now I can 


can't obviously.


Vít

> access settings. So now I'd appreciate if you can fix
> https://src.fedoraproject.org/rpms/rubygem-gem2rpm/settings for me.
>
> Anyway, I don't want to manage collaborators. I want anybody to maintain
> EPEL packages without me knowing about it.
>
>
> Vít
>
>
>>
>> Pierre
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Proposing an EPEL packaging SIG

2020-09-14 Thread Vít Ondruch

Dne 14. 09. 20 v 12:03 Pierre-Yves Chibon napsal(a):
> On Mon, Sep 14, 2020 at 10:35:18AM +0200, Vít Ondruch wrote:
>> Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a):
>>> On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote:
>>>> Reading this proposal and with the EPEL8 experience, where there was not
>>>> even wiki page, where I could state that I don't care about EPEL and I
>>>> had to reply into every BZ independently, wouldn't it make sense to move
>>>> EPEL into its own dist-git namespace?
>>>>
>>>> I guess that in the CVS days, having EPEL branch was fine. During PkgDB
>>>> days, where we could assign maintainer to each branch, it was still
>>>> fine. But since we lost this ability, isn't it time to rethink the
>>>> setup?
>>> We have the ability back, see the answers from Neal Gompa.
>>
>> Well, yes, right. But apparently, it is not fully working. E.g. looking
>> at Ruby [1], it says I am EPEL maintainer while there is certainly not
>> EPEL branch. Also, there might be EPEL maintainer (actually Pagure lists
>> just BZ assignee), but I am not sure if they are listed between
>> "members" or not. I cannot set my preferred default. So there is still
>> lot to desire.
> You're speaking about the bugzilla overrides, that in practice are entirely
> separated from granting access to the epel* branches to someone.
> If you go on the project's settings, click to add an user or group, you'll see
> the "collaborator" access level with which you can give someone commit access
> on one or more branches (comma separated or using a pattern, for example 
> epel*).


Ok, nice. Didn't know this because one could find it by accident.

Trying this, I immediately got "Fatal Error (500)" and now I can access
settings. So now I'd appreciate if you can fix
https://src.fedoraproject.org/rpms/rubygem-gem2rpm/settings for me.

Anyway, I don't want to manage collaborators. I want anybody to maintain
EPEL packages without me knowing about it.


Vít


>
>
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Proposing an EPEL packaging SIG

2020-09-14 Thread Vít Ondruch

Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote:
>> Reading this proposal and with the EPEL8 experience, where there was not
>> even wiki page, where I could state that I don't care about EPEL and I
>> had to reply into every BZ independently, wouldn't it make sense to move
>> EPEL into its own dist-git namespace?
>>
>> I guess that in the CVS days, having EPEL branch was fine. During PkgDB
>> days, where we could assign maintainer to each branch, it was still
>> fine. But since we lost this ability, isn't it time to rethink the
>> setup?
> We have the ability back, see the answers from Neal Gompa.


Well, yes, right. But apparently, it is not fully working. E.g. looking
at Ruby [1], it says I am EPEL maintainer while there is certainly not
EPEL branch. Also, there might be EPEL maintainer (actually Pagure lists
just BZ assignee), but I am not sure if they are listed between
"members" or not. I cannot set my preferred default. So there is still
lot to desire.

From this POV, the separate namespace could have more advantages.


>
>> I think this would give more power to EPEL SIG and give relieve
>> to Fedora packagers.
> What you are saying would make sense if there was only the EPEL SIG.
> But we also have plenty of packagers who do care about their EPEL packages,


Do we know the ratio? I am not saying that we don't but I don't see
"plenty" to be anything we should base any decision.


> and they would be inconvenienced by such a split. It seems that there
> are even people who like to keep one spec file for all branches, incl.
> EPEL.


People still might have locally one repository with two remotes, so I
probably missing what is the point here. Having to pull EPEL branch or
not is also difference, but I don't see we should adding this into equation.


Vít



[1] https://src.fedoraproject.org/rpms/ruby

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proposing an EPEL packaging SIG

2020-09-14 Thread Vít Ondruch
Reading this proposal and with the EPEL8 experience, where there was not
even wiki page, where I could state that I don't care about EPEL and I
had to reply into every BZ independently, wouldn't it make sense to move
EPEL into its own dist-git namespace?

I guess that in the CVS days, having EPEL branch was fine. During PkgDB
days, where we could assign maintainer to each branch, it was still
fine. But since we lost this ability, isn't it time to rethink the
setup? I think this would give more power to EPEL SIG and give relieve
to Fedora packagers.


Vít


Dne 11. 09. 20 v 20:52 Michel Alexandre Salim napsal(a):
> Hello all,
>
> Following up from last week's EPEL Steering Committee meeting, I'm
> presenting a proposal to create a dedicated SIG to make it easier to
> get Fedora packages into EPEL and keep them maintained.
>
> Using the Fedora Changes Process template for this to help structure
> the proposal, though this is not really a Fedora Change.
>
> == Summary ==
>
> Have a dedicated SIG for packagers who are interested in making more
> Fedora packages available for EPEL releases.
>
> == Owner ==
> * Name: [[User:salimma|Michel Salim]]
> * Email: 
>
> == Detailed Description ==
>
> RHEL/CentOS releases are branched off from Fedora; since RHEL 8 this
> happens every 3 years. Only a subset of Fedora packages get shipped as
> part of RHEL, as Red Hat provides support on these packages for their
> paying customers; EPEL (Extra Packages for Enterprise Linux) fills in
> the gap; this is similar to the old split between Fedora Core and
> Extras.
>
> EPEL packages are maintained in dist-git as additional branches on
> Fedora packages; however, unlike with Fedora releases, where by default
> a package gets branched for any new Fedora release, EPEL branches are
> only created if one of the package maintainers request it (it's opt-
> in).
>
> The rationale is that many Fedora packagers do not specifically care
> about EL, and with their long release cycles the maintenance burden is
> higher (e.g. upgrading to fix a security vulnerability might not be
> possible if the newer fixed version has unmet dependencies, so
> backporting the fix might be required). EL is more often used server
> side too, so the average Fedora packager is not expected to be an EL
> user.
>
> This poses a problem for those of us who rely on packages in EPEL --
> e.g. Fedora Infrastructure, and many corporate deployments. Right now
> the process is as such:
>
> * An org starts rolling out the new version of EL
> * It turns out a given package is not available in EPEL
> * Bug filed requesting that package be branched and built
> * Worst case scenario, no response and we need to use the non-
> responsive maintainer flow
> * That package might have other unmet dependencies, so repeat this
> cycle several times
> * Wait for each of these packages to go through the update system
> * For organizations that have their own internal mirrors, they now need
> to sync the new packages
>
> There are several changes we can make to both streamline the process,
> and not increase the maintenance burden on the (other) maintainers of
> these packages:
>
> * Have an EPEL SIG modeled after the SIGs centered around programming
> language stacks (e.g. Python, Haskell, Java)
> * 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
> * Members of the EPEL SIG can then branch these packages early when the
> next EL release is branched
> * The member of the SIG doing the branching should be designated as the
> primary EPEL assignee for that package
>
> One deviation we might want to have from how Python SIG works is... we
> probably don't want to encourage packagers to add this EPEL SIG as a
> comaintainer preemptively, but only as needed.
>
> == Benefit to Fedora ==
> === Smoother infra upgrades ===
> Upgrading the Fedora infrastructure will get easier over time, as more
> of the necessary EPEL packages become co-maintained by the EPEL SIG,
> which reduces the amount of time needed to get these packages available
> on new releases.
>
> === Packager experience ===
> Reduced burden on Fedora package maintainers who are not interested in
> EPEL - the choice is now either:
> * One of the existing maintainers does the work of branching and
> building
> * The requestee gets added as a maintainer and does it
> * The request stalls because the requestee is not a packager
>
> === More involvement by CentOS-using organizations ===
> With the EPEL SIG, we should encourage organizations with a long-term
> need for EPEL to get their members / employees added to this SIG, so
> scenarios #2 and #3 basically becomes this:
>
> * 

Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

2020-09-11 Thread Vít Ondruch

Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a):
> * Tom Hughes via devel:
>
>> On 11/09/2020 07:13, Ondrej Dubaj wrote:
>>
>>> There seemed to be no big reason for moving the libraries to the
>>> main package in the past, so I consider f34 as a good candidate for
>>> such a change. It would be great, if  you share your opinions and
>>> concerns for this topic.
>> Tom Lane has explained the reason on the ticket, it's because the
>> library is often dlopened by a client application instead of being
>> linked to.


"often" is relative. I see this mentioned for following packages:


java-1.5.0-ibm-jdbc

java-1.6.0-sun-jdbc

java-1.5.0-bea-jdbc


Which probably shares common history and at least one of them admitted
the mistake [1] and started to use the versioned .so file.

So are there any other cases?


> Yes, that is sufficient reason not to do the move.  Third-party
> applications will break.


And they should be fixed. I understand there is never the right time to
fix this, but if not now, then when?


> Some people also really dislike installing
> *-devel packages in production, so there might not be an easy fix for
> them.
>
> The library probably should not have a versioned soname in the first
> place, with backwards compatibility achieved by different means.  But
> that does not matter now.
>
> Thanks,
> Florian


Vít


[1] https://bugzilla.redhat.com/show_bug.cgi?id=215777#c24

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

2020-09-11 Thread Vít Ondruch

Dne 10. 09. 20 v 17:32 Michael Catanzaro napsal(a):
>
> On Thu, Sep 10, 2020 at 9:24 am, Vít Ondruch  wrote:
>> Hi Michael,
>>
>> Could you please provide more details? This is content of my
>> nsswitch.conf:
>>
>>
>> ~~~
>>
>> $ grep mdns4_minimal /etc/authselect/user-nsswitch.conf
>> hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
>> ~~~
>>
>>
>> How that happened? From what version of what package it happened? Why
>> should I do some changes manually and they are not handled
>> automatically?
>
> You're completely missing resolved from your hosts line, so you'll get
> legacy name resolution behavior via nss-dns (which is what Ubuntu does).
>
> There were multiple different bugs here, so it's a bit hard to keep
> track of them all. systemd package was being too cautious about
> deleting /etc/resolv.conf, so some users wound up with
> /etc/resolv.conf managed by NetworkManager even though systemd is
> running, which was not what I had intended. Plus we originally planned
> for resolved to handle mDNS resolution instead of avahi, but we
> discovered that it doesn't work as expected. We have hacky scripts in
> the systemd and nss-mdns packages to manage the hosts line, plus it's
> managed by authselect itself. They all have to agree on expected
> configuration and it's all a bit fragile. The systemd package script
> is careful to only touch this line if the order matches the previous
> Fedora default configuration, so we have to choose between
> automatically reordering the nss modules to fix this for users of F33
> pre-beta, vs. clobbering intentional configuration changes for users
> who actually wanted the hosts line to be different. If this had
> reached stable releases, then we'd really have to do that clobbering,
> but it didn't, so seems best to be more conservative here. These
> scripts would not be needed if we could add systemd nss modules and
> nss-mdns to the nsswitch.conf provided by the glibc package.


Thank you for the details.

And now I wonder, is there a way to restore the pristine state of these
files without touching them directly (with exception of deleting them)?
E.g.:

~~~

$ rm /etc/authselect/user-nsswitch.conf

$ sudo dnf reinstall authselect

~~~

Also I don't understand why I have files on my system which are not
owned by anything:

~~~

$ rpm -qf /etc/authselect/user-nsswitch.conf
file /etc/authselect/user-nsswitch.conf is not owned by any package

~~~

How are these files created for fresh system?

And also, is there long term vision to prevent issues, that nobody
really knows who edited which configuration file? I understand that
there is some legacy, multiple projects involved, etc. but I don't want
to care about random configuration files in /etc.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-11 Thread Vít Ondruch

Dne 11. 09. 20 v 11:03 Hans de Goede napsal(a):
>
>
> On 9/11/20 10:16 AM, Mikolaj Izdebski wrote:
>
>> Another, more concrete example: core Ant doesn't have any dependencies
>> beyond JDK. It is easy to build and maintain, yet very functional. On
>> the other hand, full Ant with all the optional tasks depends on more
>> than 200 Java packages. For the purpose of building all packages that
>> I am interested in, core Ant with JUnit tasks (total of 3 packages) is
>> sufficient. Functionalities of Ant like sending emails or image
>> processing are obviously not needed in this case. If building other
>> packages is the only use of Ant then it can be maintained much more
>> easily (3 instead of ~250 packages). But when Ant is ursine package in
>> Fedora then it should be the full Ant - we can't claim to deliver Ant
>> to users while it is just part of it. Eclipse in Fedora requires full
>> Ant too.
>
> So if you say that you only need the minimal Ant, and I guess many
> packages only need the minimal Ant to build, then why not have
> an ant-minimal package, like we have a vim-minimal ?
>
> Now I guess that vim-minimal and "proper" vim are both build from the
> same source-rpm; and normally we never allow 2 srpms with the same
> upstream sources in them. But I think that in this case we could make
> an exemption where there is a separate pkg-git and srpm for an
> ant-minimal
> which you would maintain.
>
> And then the community / java-sig can maintain the full Ant as I believe
> is already happening since we do have an ant packaged in Fedora 33 atm.


How this reduce the workload? As far as I understand, there is currently
Ant minimal in module and full featured Ant as ursine package and both
companies complain (more or less) that they want to do less.

And of course one of the ideas of modularity were that you have one
repository, actually one branch, and from there you build Ant for module
and the same Ant as a ursine package, but apparently, there are
different needs. Therefore Ant has to be maintained twice.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-11 Thread Vít Ondruch

Dne 11. 09. 20 v 8:43 Petr Pisar napsal(a):
> On Thu, Sep 10, 2020 at 09:59:05PM +, Zbigniew Jędrzejewski-Szmek wrote:
>> For Maven packaging the appeal of Modularity is clearly the privatization of
>> the dependency tree, which obviously undercuts the ecosystem of packages.
>>
> You are right that bundling is one of the features of Modularity and that this
> freedom undermines an integration effort on the Fedora distribution level.
>
> But bundling is not the only appeal for Maven maintainers. If I can speek for
> Mikolaj, then another appeal is sharing a module among multiple Fedora
> releases. Because byte-compiled Java code is portable, it is possible to build
> a module on Fedora 31 and have the same module build available on Fedora 34.
> This saves the module maintainers from the burden of rebuilding the Java
> packages for each Fedora and Modularity is the first place that actuallty can
> leverage this Java feature.
>

While the idea of sharing between Fedora is nice, it won't work in
practice. There is more then just "byte-compiled Java code is portable".
This allows you to ship certain set of the packages, but it won't allow
you to easily update any single package. You have always consider the
API changes, dependency changes and if the update of the package, which
you would do on Rawhide and would be perfectly fine, won't break other
parts of F31 ecosystem. The choice is not any easier.

If on the other hand the F31 was left in the state when it was branched
+ applying fixes, the Rawhide would be free to update the packages.

Not mentioning that keeping the one set of packages is possibly against
the idea of Fedora update policy [1].


Vít



[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

2020-09-10 Thread Vít Ondruch
Hi Michael,

Could you please provide more details? This is content of my nsswitch.conf:


~~~

$ grep mdns4_minimal /etc/authselect/user-nsswitch.conf
hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
~~~


How that happened? From what version of what package it happened? Why
should I do some changes manually and they are not handled automatically?


Thx


Vít


Dne 09. 09. 20 v 21:08 Michael Catanzaro napsal(a):
> Hi,
>
> I've you've installed or upgraded to Fedora 33 (or to rawhide) prior
> to today, your /etc/nsswitch and /etc/resolv.conf are probably in a
> broken state that requires manual intervention to resolve. This has
> caused breakage for mDNS and VPN users [1][2][3]. Apologies for this
> breakage. Anyone installing with current nightly images or upgrading
> as of today should be OK, so users installing F33 beta or upgrading
> from F32 to F33 beta will be unaffected.
>
> To fix /etc/nsswitch.conf, edit the hosts line in
> /etc/authselect/user-nsswitch.conf to look like this:
>
> hosts:  files mdns4_minimal [NOTFOUND=return] resolve
> [!UNAVAIL=return] myhostname dns
>
> Then run:
>
> # authselect apply-changes
>
> Then, fix /etc/resolv.conf:
>
> # rm /etc/resolv.conf
> # ln -s ../run/systemd/resolve/stub-resolv.conf
>
> And restart NetworkManager:
>
> # systemctl restart NetworkManager.service
>
> Michael
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1873856
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1867830
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1863041
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

2020-09-09 Thread Vít Ondruch
Generally, I would appreciate if the proposal was more readable to
casual Fedora user/developer. I don't think there is clearly described
the current state and what is going to be changed. Also, there is a lot
of unclear terminology, e.g. I don't have idea what are "LSM hooks".
"Migrate users to using ''selinux=0''" probably refers to kernel command
line, but why it is not mentioned in the summary.


Thanks


Vít


Dne 08. 09. 20 v 17:28 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
>
> == Summary ==
> Remove support for SELinux runtime disable so that the LSM hooks can
> be hardened via read-only-after-initialization protections.
>
> Migrate users to using ''selinux=0'' if they want to disable SELinux.
>
> == Owner ==
> * Name: [[User:plautrba| Petr Lautrbach]]
> * Email: plaut...@redhat.com
> * Name: [[User:omos| Ondrej Mosnacek]]
> * Email: omosn...@redhat.com
>
>
> == Detailed Description ==
> Support for SELinux runtime disable via ''/etc/selinux/config'' was
> originally developed to make it easier for Linux distributions to
> support architectures where adding parameters to the kernel command
> line was difficult.
> Unfortunately, supporting runtime disable meant we had to make some
> security trade-offs when it comes to the kernel LSM hooks.
>
> Marking the kernel LSM hooks as read only provides some very nice
> security benefits, but it does mean that we can no longer disable
> SELinux at runtime.
> Toggling between enforcing and permissive mode while booted will
> remain unaffected and it will still be possible to disable SELinux by
> adding ''selinux=0'' to the kernel command line via the boot loader
> (GRUB).
>
> System with ''SELINUX=disabled'' in ''/etc/selinux/config'' will come
> up with ''/sys/fs/selinuxfs'' unmounted,
> userspace will detect SELinux as disabled. Internally SELinux will be
> enabled but not initialized so that there will be no SELinux checks
> applied.
>
> NOTE: Runtime disable is considered deprecated by upstream, and using
> it will become increasingly painful (e.g. sleeping/blocking) through
> future kernel releases until eventually it is removed completely.
> Current kernel reports the following message during runtime disable:
> ''SELinux:  Runtime disable is deprecated, use selinux=0 on the kernel
> cmdline''
>
> Additional info:
>
> * https://lwn.net/Articles/666550
> * 
> https://lore.kernel.org/selinux/159110207843.57260.5661475689740939480.stgit@chester/
> * 
> https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t
>
> == Benefit to Fedora ==
> Marking the LSM hooks as read-only provides extra security hardening
> against certain attacks, e.g. in case an attacker gains ability to
> write to random kernel memory locations, with support for disable
> SELinux runtime (''CONFIG_SECURITY_SELINUX_DISABLE=y'') they have a
> bigger chance to turn off (parts of) SELinux permission checking.
>
> == Scope ==
> * Proposal owners:
> ** Make sure the kernel is built with
> ''CONFIG_SECURITY_SELINUX_DISABLE'' disabled.
> ** Make sure the relevant documentation is updated in a way that
> ''selinux=0'' on kernel command line is the preferred way to disable
> SELinux.
> *** 
> https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/
> *** ''selinux(8)'' man page
> ** Make sure [https://github.com/rhinstaller/anaconda/ the installer]
> uses the kernel command line instead of ''/etc/selinux/config'' to
> disable SELinux.
> ** Optional: 
> [https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/selinux.py
> ''selinux'' Ansible module] should warn that SELinux needs to be
> disabled using ''selinux=0''.
> ** Optional: [https://github.com/linux-system-roles/selinux
> linux-system-roles.selinux] should disable SELinux using
> ''selinux=0''.
>
> * Other developers: N/A
> * Release engineering: https://pagure.io/releng/issue/9742
> * Policies and guidelines: N/A
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> Users should not be directly affected by this change.
>
> == How To Test ==
> # Install a kernel built with ''CONFIG_SECURITY_SELINUX_DISABLE''
> disabled, e.g. from
> https://copr.fedorainfracloud.org/coprs/omos/drop-selinux-disable/.
> # Confirm that SELinux is disabled when ''selinux=0'' is used on
> kernel command line.
> # Confirm that userspace considers SELinux disabled when
> ''SELINUX=disabled'' is used in ''/etc/selinux/config''.
> # Confirm that userspace considers SELinux disabled when there is no
> ''/etc/selinux/config''.
> # Confirm that the system works as expected in all previous cases.
>
> == User Experience ==
> There's no visible change for users with SELinux enabled.
>
> Users with ''SELINUX=disabled'' in ''/etc/selinux/config'' and without
> ''selinux=0'' on kernel command line might notice that `ps Z` command
> uses ''kernel'' domain for processes, while with 

Re: Non-responsive maintainer: domcleal

2020-09-03 Thread Vít Ondruch

Dne 02. 09. 20 v 17:19 Robbie Harwood napsal(a):
> Vít Ondruch  writes:
>
>> Hi Robbie,
>>
>> I wonder if you had some intentions with the packages,
> If you're asking if I plan to take them, I do not.


Thx for clarification. Since the first ticket was rubygem- it just
caught my attention.


Vít


>   They have been
> orphaned, so anyone interested can pick them up.  (They should refer to
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers
> which has the full process.)
>
>> be cause at lest the 3 down bellow looks to be required by other
>> packages and they are now in danger of being removed from Fedora.
> That's a problem that needs to be fixed.  But now it *can* be fixed,
> instead of those packages building on a house of cards.
>
> Thanks,
> --Robbie



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Non-responsive maintainer: domcleal

2020-09-02 Thread Vít Ondruch


Dne 02. 09. 20 v 15:18 Greg Hellings napsal(a):
> Vit, et al,
>
> My professional need for rubygems ended a while back, and I have no
> personal investment into Ruby.


That is perfectly fine.


> So I would prefer not to take on more Ruby packages as I don't pay
> much attention to the space.


But if rubygem-unicode-display_width is going to be retired due to being
orphaned, your rubygem-terminal-table package is going to be in trouble.
I think it is your responsibility to do something about it (even if it
should be just orphaning). Nevertheless, rubygem-jekyll maintainers
might be interested to take over your rubygem-terminal-table, because
this is the dependency chain:

rubygem-unicode-display_width <= rubygem-terminal-table <= rubygem-jekyll


Vít



>
> --Greg
>
> On Wed, Sep 2, 2020 at 3:38 AM Vít Ondruch  <mailto:vondr...@redhat.com>> wrote:
>
> Hi Robbie,
>
> I wonder if you had some intentions with the packages, be cause at
> lest
> the 3 down bellow looks to be required by other packages and they are
> now in danger of being removed from Fedora.
>
> Adding on CC Pavel, Dan and Greg who might be interested in some
> of them.
>
>
> Vít
>
>
> Dne 01. 09. 20 v 20:30 Miro Hrončok napsal(a):
> > On 01. 09. 20 19:40, Robbie Harwood wrote:
> >> You may remove me from these packages or orphan them as you see
> fit. I
> >> don't plan on making any more contributions.
> >
> > Done.
> >
> > domcleal is main admin of rpms/rubygem-Ascii85
> >   domcleal is no longer the main admin of rpms/rubygem-Ascii85
> >   domcleal is no longer watching rpms/rubygem-Ascii85
> > domcleal is main admin of rpms/rubygem-ruby-rc4
> >   domcleal is no longer the main admin of rpms/rubygem-ruby-rc4
> >   domcleal is no longer watching rpms/rubygem-ruby-rc4
> > domcleal is main admin of rpms/rubygem-unicode-display_width
> >   domcleal is no longer the main admin of
> > rpms/rubygem-unicode-display_width
> >   domcleal is no longer watching rpms/rubygem-unicode-display_width
> >
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Vít Ondruch

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.


Vít


>
> Tom
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: domcleal

2020-09-02 Thread Vít Ondruch
Hi Robbie,

I wonder if you had some intentions with the packages, be cause at lest
the 3 down bellow looks to be required by other packages and they are
now in danger of being removed from Fedora.

Adding on CC Pavel, Dan and Greg who might be interested in some of them.


Vít


Dne 01. 09. 20 v 20:30 Miro Hrončok napsal(a):
> On 01. 09. 20 19:40, Robbie Harwood wrote:
>> You may remove me from these packages or orphan them as you see fit. I
>> don't plan on making any more contributions.
>
> Done.
>
> domcleal is main admin of rpms/rubygem-Ascii85
>   domcleal is no longer the main admin of rpms/rubygem-Ascii85
>   domcleal is no longer watching rpms/rubygem-Ascii85
> domcleal is main admin of rpms/rubygem-ruby-rc4
>   domcleal is no longer the main admin of rpms/rubygem-ruby-rc4
>   domcleal is no longer watching rpms/rubygem-ruby-rc4
> domcleal is main admin of rpms/rubygem-unicode-display_width
>   domcleal is no longer the main admin of
> rpms/rubygem-unicode-display_width
>   domcleal is no longer watching rpms/rubygem-unicode-display_width
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [HOWTO] Keep using Rawhide after branching

2020-08-28 Thread Vít Ondruch

Dne 28. 08. 20 v 19:09 Adam Williamson napsal(a):
> On Fri, 2020-08-28 at 18:51 +0200, Vít Ondruch wrote:
>> Dne 25. 08. 20 v 16:25 Petr Menšík napsal(a):
>>> No, unfortunately the key is there, but the package is incomplete.
>>>
>>> If you have enabled gpg signatures verification, it would fail. At least
>>> it does to me.
>>>
>>> Check it with:
>>>
>>> rpm -ql fedora-gpg-keys | grep fedora-34-$(arch)
>>>
>>> It just does not provide correct key.
>>
>> Actually, yesterday I did update of another system with my approach and
>> you are right that the fedora-gpg-keys-33-0.9 did not contained the
>> proper links to the key. However, the fedora-gpg-keys-33-0.10 works just
>> fine (not really sure what caused the difference).
> The change to archmap in this commit:
> https://src.fedoraproject.org/rpms/fedora-repos/c/5f02f474842d23a0217c1118893f508009236c18?branch=f33
> which landed between 0.9 and 0.10 (the versioning was fixed up in the
> next commit).


Thx, right, I have missed that. Pretty confusing series of commits :(


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [HOWTO] Keep using Rawhide after branching

2020-08-28 Thread Vít Ondruch

Dne 25. 08. 20 v 16:25 Petr Menšík napsal(a):
> No, unfortunately the key is there, but the package is incomplete.
>
> If you have enabled gpg signatures verification, it would fail. At least
> it does to me.
>
> Check it with:
>
> rpm -ql fedora-gpg-keys | grep fedora-34-$(arch)
>
> It just does not provide correct key.


Actually, yesterday I did update of another system with my approach and
you are right that the fedora-gpg-keys-33-0.9 did not contained the
proper links to the key. However, the fedora-gpg-keys-33-0.10 works just
fine (not really sure what caused the difference). I did precisely:


~~~

$ sudo dnf update --disablerepo=rawhide --enablerepo=fedora
fedora-gpg-keys --release 33

$ sudo dnf update fedora-repos\* --release 34

~~~


Vít


>  The same issue is there for f31
> and f32. When you create platform link yourself, then you can upgrade
> without turning off signature verification.
>
> I got mad it always breaks and prepared automated test [1]. Hope next
> time rolling rawhide would be possible. I report issue with that every
> release and got tired of it. It is a bit better now, but not great.
>
> 1. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/76
> 2. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/77
>
>
> On 8/25/20 12:16 PM, Vít Ondruch wrote:
>> Dne 25. 08. 20 v 11:40 Petr Menšík napsal(a):
>>> Hi Vít,
>>>
>>> Unfortunately your workaround does not on my rawhide container. I think
>>> the problem is in missing gpg keys from fedora-gpg-keys, which do not
>>> contain also architecture specific keys.
>>>
>>> # rpm -q fedora-repos fedora-repos-rawhide fedora-gpg-keys
>>> fedora-repos-33-0.9.noarch
>>> fedora-repos-rawhide-33-0.9.noarch
>>> fedora-gpg-keys-33-0.9.noarch
>>>
>>> # sudo dnf -y --enablerepo=updates --enablerepo=rawhide update
>>> fedora-gpg-keys
>>
>> The `--enablerepo=rawhide` is the issue IMO.
>>
>> You should understand, that Rawhide up to the branching point was F33
>> and signed by F33 key. So first you need to update to at least
>> fedora-gpg-keys-33-0.9.noarch.rpm (and note the '33' there), which is
>> signed by known F33 key but already contains the F34 key. Since that
>> point you can use F34 packages signed by F34 key.
> No, it should have worked this way, but it did not. Made pull request
> for f32 update [2]. It should be done also for f31, if there is still
> time for that.
>
>>
>> Vít
>>
>>
>>> Last metadata expiration check: 0:54:22 ago on Tue Aug 25 10:24:53 2020.
>>> Dependencies resolved.
>>> =
>>>  Package   Architecture
>>> Version  Repository Size
>>> =
>>> Upgrading:
>>>  fedora-gpg-keys   noarch
>>> 34-0.2   rawhide   105 k
>>>
>>> Transaction Summary
>>> =
>>> Upgrade  1 Package
>>>
>>> Total size: 105 k
>>> Downloading Packages:
>>> [SKIPPED] fedora-gpg-keys-34-0.2.noarch.rpm: Already downloaded
>>>
>>> warning:
>>> /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/fedora-gpg-keys-34-0.2.noarch.rpm:
>>> Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
>>> Fedora - Rawhide - Developmental packages for the next Fedora release
>>>  1.6 MB/s | 1.6 kB 00:00
>>> GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
>>> (0x9570FF31) is already installed
>>> The GPG keys listed for the "Fedora - Rawhide - Developmental packages
>>> for the next Fedora release" repository are already installed but they
>>> are not correct for this package.
>>> Check that the correct key URLs are configured for this repository..
>>> Failing package is: fedora-gpg-keys-34-0.2.noarch
>>>  GPG Keys are configured as:
>>> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
>>> The downloaded packages were saved in cache until the next successful
>>> transaction.
>>> You can remove cached packages by executing 'dnf clean packages'.
>>> Error: GPG check FAILED
>>>
>>> I ha

Re: Does ELN SIG have some issue tracker?

2020-08-26 Thread Vít Ondruch

Dne 25. 08. 20 v 19:09 Aleksandra Fedorova napsal(a):
> Hi, Vit,
>
> On Tue, Aug 25, 2020 at 11:21 AM Vít Ondruch  wrote:
>> Looking at the ELN SIG page [1], there is no contact information, no ML,
>> no issue tracker. I would like to discuss bootstrapping issues such as
>> [2], but there is no place to provide any feedback. Is this group
>> working under cover?
>>
>> (Using the minimization tracker [3], where a lot of ELN stuff appears to
>> end up, does not feel appropriate).
> Thank you for the question.
>
> The ELN wiki page is outdated, I am working on moving the content to
> ELN Docs site [1] right now. I will add contact and contribution info
> there as well.
>
> The minimization tracker [2] is indeed better suited for the content
> set discussions.
>
> For generic ELN topics please use issues in https://github.com/fedora-eln/eln


Thx, I have created issuen #1 there ;)


https://github.com/fedora-eln/eln/issues/1


Vít


>
> [1] https://docs.fedoraproject.org/en-US/eln/
> [2] https://github.com/minimization/content-resolver-input
>
>> Vít
>>
>>
>> [1] https://fedoraproject.org/wiki/ELN
>>
>> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1599965
>>
>> [3] https://github.com/minimization/
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [HOWTO] Keep using Rawhide after branching

2020-08-25 Thread Vít Ondruch

Dne 25. 08. 20 v 11:40 Petr Menšík napsal(a):
> Hi Vít,
>
> Unfortunately your workaround does not on my rawhide container. I think
> the problem is in missing gpg keys from fedora-gpg-keys, which do not
> contain also architecture specific keys.
>
> # rpm -q fedora-repos fedora-repos-rawhide fedora-gpg-keys
> fedora-repos-33-0.9.noarch
> fedora-repos-rawhide-33-0.9.noarch
> fedora-gpg-keys-33-0.9.noarch
>
> # sudo dnf -y --enablerepo=updates --enablerepo=rawhide update
> fedora-gpg-keys


The `--enablerepo=rawhide` is the issue IMO.

You should understand, that Rawhide up to the branching point was F33
and signed by F33 key. So first you need to update to at least
fedora-gpg-keys-33-0.9.noarch.rpm (and note the '33' there), which is
signed by known F33 key but already contains the F34 key. Since that
point you can use F34 packages signed by F34 key.


Vít


> Last metadata expiration check: 0:54:22 ago on Tue Aug 25 10:24:53 2020.
> Dependencies resolved.
> =
>  Package   Architecture
> Version  Repository Size
> =
> Upgrading:
>  fedora-gpg-keys   noarch
> 34-0.2   rawhide   105 k
>
> Transaction Summary
> =
> Upgrade  1 Package
>
> Total size: 105 k
> Downloading Packages:
> [SKIPPED] fedora-gpg-keys-34-0.2.noarch.rpm: Already downloaded
>
> warning:
> /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/fedora-gpg-keys-34-0.2.noarch.rpm:
> Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
> Fedora - Rawhide - Developmental packages for the next Fedora release
>  1.6 MB/s | 1.6 kB 00:00
> GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
> (0x9570FF31) is already installed
> The GPG keys listed for the "Fedora - Rawhide - Developmental packages
> for the next Fedora release" repository are already installed but they
> are not correct for this package.
> Check that the correct key URLs are configured for this repository..
> Failing package is: fedora-gpg-keys-34-0.2.noarch
>  GPG Keys are configured as:
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: GPG check FAILED
>
> I have complained two release before and this is still the same. It
> always break on new release. The only option now is to install it by
> hand from koji, where it is not yet signed (yuck!)
>
> # dnf install
> https://kojipkgs.fedoraproject.org//packages/fedora-repos/34/0.2/noarch/fedora-gpg-keys-34-0.2.noarch.rpm
>
> Then your commands would work, followed by normal upgrade.
>
> Filled bug #1872248 for it. It should finally work without user even
> fiddling with gpg keys manually. Is there some pressure to keep users
> from using rawhide?
>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1872248
>
> On 8/17/20 1:42 PM, Vít Ondruch wrote:
>> Just as a reminder to all Rawhide users, this is the easiest way to keep
>> using Rawhide after branching:
>>
>>
>> ~~~
>>
>> $ sudo dnf update fedora-gpg-keys
>>
>> $ sudo dnf update fedora-repos --release 34
>>
>> ~~~
>>
>>
>> Unfortunately, there has been no progress on [1] during past months.
>>
>>
>>
>> Vít
>>
>>
>>
>>  [1] https://pagure.io/releng/issue/7445
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Does ELN SIG have some issue tracker?

2020-08-25 Thread Vít Ondruch
Looking at the ELN SIG page [1], there is no contact information, no ML,
no issue tracker. I would like to discuss bootstrapping issues such as
[2], but there is no place to provide any feedback. Is this group
working under cover?

(Using the minimization tracker [3], where a lot of ELN stuff appears to
end up, does not feel appropriate).


Vít


[1] https://fedoraproject.org/wiki/ELN

[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1599965

[3] https://github.com/minimization/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Proposed Modular Policy for Fedora ELN

2020-08-24 Thread Vít Ondruch

Dne 20. 08. 20 v 20:17 Stephen Gallagher napsal(a):
>
> However, ELN has a mission to be a bridge to future RHEL and that
> distribution has committed to default streams as a business necessity
> for multiple reasons (among them support lifecycle which is much
> harder to address via non-modular content).
>
>

If there is any functionality provided by modularity to help address the
lifecycle, then it is not used in Fedora nor RHEL AFAIK. Therefore it
should be considered failure and it would be better if it was removed
from specs altogether.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned rubygem-dealayed_job{,_active_record}

2020-08-20 Thread Vít Ondruch
Hi,

I don't have any use for rubygem-dealayed_job and
rubygem-dealayed_job_active_record, therefore I orphaned them.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Very strange compiler/linker related build failures in rawhide

2020-08-20 Thread Vít Ondruch
Hi Jeff,


Dne 27. 07. 20 v 14:28 Vít Ondruch napsal(a):
> Dne 27. 07. 20 v 12:25 Vít Ondruch napsal(a):
>> Dne 24. 07. 20 v 21:01 Jeff Law napsal(a):
>>> On Fri, 2020-07-24 at 20:52 +0200, Vít Ondruch wrote:
>>>> The LTO break Ruby on various platforms.
>>>>
>>>>
>>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=47582573
>>>>
>>>> vs
>>>>
>>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=47621733
>>>>
>>>> (Note these are my experimental builds testing single test case).
>>> I haven't gotten a clean ruby build with or without LTO.
>> Ruby builds just fine on x86_64 according to Koschei:
>>
>> https://koschei.fedoraproject.org/package/ruby?
>>
>>
>>>   So I haven't
>>> investigated Ruby for any LTO specific failures.
>>>
>>>> The only difference is redhat-rpm-config 162-1.fc33 => 163-1.fc33.
>>>> Adding `%define _lto_cflags %{nil}` helped to recover, but if it was at
>>>> least behaving the same on all platforms :/
>>>>
>>>>
>>>> And this is Koschei failure: 
>>>> https://koschei.fedoraproject.org/package/ruby?
>>>>
>>>> Looking at the full test suite, it seems it causes some troubles to
>>>> SIGSEV signal handler (Ruby spawns subprocess and kills it).
>>> Does the signal handler modify any global variables?
>> I am afraid there happens a lot of interesting stuff. This is the method
>> responsible for printing the output which likely fails:
>>
>> https://github.com/ruby/ruby/blame/master/vm_dump.c#L920
>>
>> But the issue might be that the signal handler itself might be somehow
>> modified and the modification fails. This is the default signal handler:
>>
>> https://github.com/ruby/ruby/blob/master/signal.c#L1137
>>
>>
>>>   That's been a common source
>>> of issues I've seen.
>> I am afraid I'll need to open some upstream ticket to help with answers
>> to questions like this :/
>
> https://bugs.ruby-lang.org/issues/17052


I have upstream response. From the ticket above:


~~~

It seems the generated DWARF section is broken. For instance
addr2line(1) also fails to understand it.

% nm ./miniruby | fgrep -w rb_f_kill | LC_ALL=C addr2line -e ./miniruby
addr2line: Dwarf Error: Could not find abbrev number 64.
??:?
:?

When you kill LTO option the above one liner must show "signal.c:423" or
something.

vo.x (Vit Ondruch) is it possible for you to ask this to linker people
instead? As addr2line(1) is also affected, it is hard for me to think we
are the ones who is doing something wrong.

~~~


HTH


Vít


>
>
> Vít
>
>
>>
>> Vít
>>
>>
>>> jeff
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned rubygem-{rubypants,org-ruby}

2020-08-18 Thread Vít Ondruch
Hi,

I have orphaned rubygem-rubypants and rubygem-org-ruby, because I have
not any use for these.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[HOWTO] Keep using Rawhide after branching

2020-08-17 Thread Vít Ondruch
Just as a reminder to all Rawhide users, this is the easiest way to keep
using Rawhide after branching:


~~~

$ sudo dnf update fedora-gpg-keys

$ sudo dnf update fedora-repos --release 34

~~~


Unfortunately, there has been no progress on [1] during past months.



Vít



 [1] https://pagure.io/releng/issue/7445

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: failed to do fedpkg import

2020-08-17 Thread Vít Ondruch

Dne 16. 08. 20 v 15:53 Fabio Valentini napsal(a):
>
> Also I'm not sure why you're running import again, when the package
> already exists.


`import` is the best way how to upload sources + add/remove patches from
dist-git. I would suggest everybody to `import` instead of
`new-sources`/`upload`.


Vít


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: A few questions about rpmdev-bumpspec tool

2020-08-13 Thread Vít Ondruch

Dne 13. 08. 20 v 12:41 Qiyu Yan napsal(a):
> Hello all,
>
> I have some problem with rpmdev-bumpspec recently.
>
> In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
> use time+date in the changelog it generates[1], while the packaging
> guidelines have not been updated accordingly[2], should the guideline
> be updated to the rpmdev-bumpspec change?


I don't like this change and asked revert:


https://pagure.io/rpmdevtools/issue/63


Vít


>
> I am packaging fcitx5 using forge macros, and upstream have never
> tagged a version, in this case, I am packaging like this [3] (The
> snapshot dates and git short commit hashesin changelog is manually
> added). With this spec file, I noticed that when I try to use
> rpmdev-bumpspec to generate a changelog, it will give things like this
> [4].
>
> You can see that, in case of using forge, rpmdev-bumpspec can't
> include either snapshot dates nor git short commit hashes, will this
> be fine (and we can ignore the warning from rpmlint when ran on the
> built packages, and start the review process) or I should always
> manually include snapshot dates and git commit hashes in the
> changelog. Or I should wait for this change [5] to be done and ignore
> all changelog things? (and submit for review then?)
>
> Thanks.
>
> [1]: https://pagure.io/rpmdevtools/c/d205ad9cfc4b7123acd573e028f8c4521ec79300
> [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
> [3]: 
> https://github.com/karuboniru/fcitx5-fedora/blob/master/fcitx5/fcitx5.spec
> [4]: 
> https://github.com/karuboniru/fcitx5-fedora/blob/972fd2e2e84e6ca136a9c5f4f8ad20653cca3594/fcitx5/fcitx5.spec
> [5]: 
> https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
> --
> And the snapshot dates generated on my machine and copr can be
> different, I think this is related to time zone (I am in UTC+8), I
> don't think it is a bug, but I hope this will be improved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: LTO and the F33 mass rebuild

2020-08-12 Thread Vít Ondruch

Dne 11. 08. 20 v 18:43 Kevin Fenzi napsal(a):
> On Sun, Aug 09, 2020 at 10:06:49PM -0600, Jeff Law wrote:
>> On Sun, 2020-08-09 at 12:02 +0200, Fabio Valentini wrote:
>>> On Sun, Aug 9, 2020 at 12:03 AM Jeff Law  wrote:
 So I've done two passes over the F33 build failures here:

 https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html
>>> Hi Jeff,
>>>
>>> Thanks for looking at the failures, it's really appreciated!
>>>
>>> Be aware that the f33-failures.html page is not complete though, since
>>> packages for which there was an attempted rebuild *after* the mass
>>> rebuild are removed from the list, whether the builds succeeded or
>>> not. So it's possible that you missed builds that fail for LTO-related
>>> issues, just because they're no longer showing up in the list. The
>>> list of bugs blocking the F33FTBFS bug in bugzilla [0] might be
>>> helpful here. And the f33-need-rebuild list [1] should give you a
>>> complete picture of everything that has not successfully been rebuilt
>>> for f33 yet.
>> ACK.  I'm poking at the f33-need-rebuild.html list a bit.  THere's a lot of 
>> noise
>> in there -- things that haven't been built in a long time.  Anyway, I'll keep
>> poking around.
>>
>> It would be helpful if there was a clean way to download failed log files and
>> such in batches so that I could run tools on them to look for common things 
>> that
>> don't need my attention (like all the cmake failures).  As it stands I have 
>> to do
>> an insane amount of clickies to get to some basic data.
> It's been proposed to enable the koji 'save-failed-tree' plugin:
> https://pagure.io/releng/issue/8243


It could be so much better for FTBFS bugs after mass rebuild ...


Vít


>
> It might help for this sort of thing, as it lets you get a complete tar
> of the entire tree. 
>
> I'll look into it more after we have staging koji back...
>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned rubygem-wikicloth

2020-08-07 Thread Vít Ondruch
Hi everybody,

I don't have any use for rubygem-wikicloth, therefore I orphaned the
package.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103 failed to build

2020-08-06 Thread Vít Ondruch

Dne 06. 08. 20 v 11:26 Aleksandra Fedorova napsal(a):
> Hi,
>
> On Thu, Aug 6, 2020 at 5:01 AM Orion Poplawski  wrote:
>> So, I'm getting one of these messages every couple of hours and I'd
>> really rather not.  Who do I need to talk to about it?
> You can talk about it with the ELN SIG [1] or Fedora CI SIG [2]. Mail
> thread on devel works, we recommend to use [ELN] as a tag in the
> subject


Nice, so some ELN folks could finally answer this thread for example:


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/U4TY26R3S65E474FUKGKB6H4JOCIEITY/


Also, it would be useful if ELN team worked on reducing the amount of
Ruby packages which are regularly rebuilt, it would help to reduce the
amount of notifications I receive.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

2020-08-05 Thread Vít Ondruch

Dne 04. 08. 20 v 21:38 Michael Catanzaro napsal(a):
> On Tue, Aug 4, 2020 at 10:31 am, Chris Murphy
>  wrote:
>> Should we go back to the old workaround for F33? Madness for one more
>> release? And then drop the madness once there's a dnf solution?
>
> We could, but we have installed so many other things that it's
> becoming quite hard to keep track of them all, and if we're going to
> have a workaround for any one package I would recommend we use the
> same workaround for them all. And that's the merge request I have
> above. And for that to work, we would need to require that anyone
> touching comps also add a corresponding Recommends: in fedora-release.
> That would be unfortunate.


Wouldn't it be better to replace this part of comps by soft
dependencies? I quite don't understand why we have not dropped comps (at
leas for the use case of installation basic OS) when we got soft
dependencies in RPM.

Admittedly, the soft dependencies would be repeatedly installed compared
to comps, but now you are asking DNF to actually install the content of
comps repetitively. So there won't be difference at the end.


Vít


>
> I'd rather have a proper dnf fix in place for F33.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

2020-08-05 Thread Vít Ondruch

Dne 04. 08. 20 v 20:58 Vitaly Zaitsev via devel napsal(a):
> On 04.08.2020 16:45, Vít Ondruch wrote:
>> I think the "don't use autoremove" is better suggestion ATM, because I
>> don't really want to keep earlyoom on the system in case there is
>> systemd-oomd or whatever should be the successor.
> You can always easily swap one package to another:
>
> sudo dnf swap earlyoom systemd-oomd --allowerasing
>

I know I can swap packages and what not, but primarily I want to keep my
system in "default" state, mostly following the changes Fedora
contributors are proposing. So if the proposal is to have earlyoom
installed by default, then it is surprising it might not be installed.
This situation should be fixed generally without me changing anything.
And that is the reason I bumped this thread.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

2020-08-04 Thread Vít Ondruch

Dne 04. 08. 20 v 16:05 Vitaly Zaitsev via devel napsal(a):
> On 04.08.2020 15:48, Michael Catanzaro wrote:
>> In the meantime, if you want to keep earlyoom, don't use autoremove.
> sudo dnf mark install earlyoom
>

I think the "don't use autoremove" is better suggestion ATM, because I
don't really want to keep earlyoom on the system in case there is
systemd-oomd or whatever should be the successor.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

2020-08-04 Thread Vít Ondruch
Yesterday, I have updated my Rawhide and wondered why `dnf autoremove`
would want to remove earlyoom just to discover that soft dependency in
earlyoom was dropped [1] and hence nothing requires earlyoom and DNF is
free to remove this package (and it is possibly not installed anymore on
upgraded systems).

Therefore I wonder what is the status of EarlyOOM. Should I let the
package go? If not, then the situation should be fixed somehow, probably
either by reverting the revert or adding the dependency into
fedora-release as was proposed elsewhere.


Vít


[1]
https://src.fedoraproject.org/rpms/earlyoom/c/a6d0f45a3524830642a4120704e8d295598f8ec3?branch=master


Dne 03. 01. 20 v 20:18 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to kill off. The idea is to recover from out of
> memory situations sooner, rather than the typical complete system hang
> in which the user has no other choice but to force power off.
>
>
> == Owner ==
> * Name: [[User:chrismurphy| Chris Murphy]]
> * Email: bugzi...@colorremedies.com
>
> == Detailed Description ==
> Workstation working group has discussed "better interactivity in
> low-memory situations" for some months. In certain use cases,
> typically compiling, if all RAM and swap are completely consumed,
> system responsiveness becomes so abysmal that a reasonable user can
> consider the system "lost", and resorts to forcing a power off. This
> is objective a very bad UX. The broad discussion of this problem, and
> some ideas for near term and long term solutions, is located here:
>
> Recent long discussions on "Better interactivity in low-memory situations"
> https://pagure.io/fedora-workstation/issue/98
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/
>
> Fedora editions and spins, have the in-kernel OOM (out-of-memory)
> manager enabled. The manager's concern is keeping the kernel itself
> functioning. It has no concern about user space function or
> interactivity. This proposed change attempts to improve the user
> experience, in the short term, by triggering the in-kernel process
> killing mechanism, sooner. Instead of the system becoming completely
> unresponsive for tens of minutes, hours or days, the expectation is an
> offending process (determined by oom_score, same as now) will be
> killed off within seconds or a few minutes. This is an incremental
> improvement in user experience, but admittedly still suboptimal. There
> is additional work on-going to improve the user experience further.
>
> Workstation working group discussion specific to enabling earlyoom by default
> https://pagure.io/fedora-workstation/issue/119
>
> Other in-progress solutions:
> https://gitlab.freedesktop.org/hadess/low-memory-monitor
>
> Background information on this complicated problem:
> https://www.kernel.org/doc/gorman/html/understand/understand016.html
> https://lwn.net/Articles/317814/
>
> == Benefit to Fedora ==
>
> There are two major benefits to Fedora:
>
> * improved user experience by more quickly regaining control over
> one's system, rather than having to force power off in low-memory
> situations where there's aggressive swapping. Once a system becomes
> unresponsive, it's completely reasonable for the user to assume the
> system is lost, but that includes high potential for data loss.
>
> * reducing forced poweroff as the main work around will increase data
> collection, improving understanding of low memory situations and how
> to handle them better
>
>
> == Scope ==
> * Proposal owners:
> a. Modify 
> {{code|https://pagure.io/fedora-comps/blob/master/f/comps-f32.xml.in}}
> to include earlyoom package for Workstation.
> b. Modify 
> {{code|https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-workstation.preset}}
> to include:
> 
> # enable earlyoom by default on workstation
> enable earlyoom.service
> 
>
> * Other developers:
> Restricted to Workstation edition, unless other editions/spins want to opt-in.
>
> * Release engineering: [https://pagure.io/releng/issues #9141] (a
> check of an impact with Release Engineering is needed) 
>
> * Policies and guidelines: N/A
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
> earlyoom.service will be enabled on upgrade. An upgraded system should
> exhibit the same behaviors as a clean installed system.
>
> == How To Test ==
> * Fedora 30/31 users can test today, any edition or spin:
> {{code|sudo dnf install earlyoom}}
> {{code|sudo systemctl enable --now earlyoom}}
>
> And then attempt to cause an out of memory situation. Examples:
> {{code|tail /dev/zero}}
> {{code|https://lkml.org/lkml/2019/8/4/15}}
>
> * Fedora Workstation 32 (and Rawhide) users will see this service is
> already enabled. It can be toggled with  {{code|sudo 

Re: Fedora 33 Mass Rebuild

2020-08-04 Thread Vít Ondruch
Mohan,

Could you please check the script filling out the FTBFS tickets is doing
the right thing?

There was reported this ticket against Ruby:

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

But I have rebuild Ruby already on Friday 31st:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1567804

while the ticket references some failed ELN build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=48384772


Thanks


Vít


Dne 02. 08. 20 v 0:57 Mohan Boddu napsal(a):
> Hi all,
>
> Per the Fedora 33 schedule[1] we started a mass rebuild for Fedora 33
> on Jul 27th 2017. We did a mass rebuild for Fedora 33 for the changes listed 
> in:
>
> https://pagure.io/releng/issue/9616
>
> Mass rebuild was done in a side tag (f33-rebuild) and moved over to f33.
>
> Failures can be seen
> https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html
>
> Things still needing rebuilt
> https://kojipkgs.fedoraproject.org/mass-rebuild/f33-need-rebuild.html
>
> 18002 builds have been tagged into f33, there are currently 2811 failed
> builds that need to be addressed by the package maintainers.
>
> Mass rebuildling of modules and FTBFS bugs will be filed shortly.
>
> Please be sure to let releng know if you see any bugs in the
> reporting. You can contact releng in #fedora-releng on freenode, by
> dropping an email to our list[2] or filing an issue in pagure[3]
>
> Regards,
> Mohan Boddu.
>
> [1] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
> [2] 
> https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
> [3] https://pagure.io/releng/
>
> On Wed, Jul 22, 2020 at 10:59 AM Mohan Boddu  wrote:
>> Hi all,
>>
>> The mass rebuild is postponed to next Monday 27th July 2020 since a
>> couple of changes haven't landed yet.
>>
>> For more information, please look at https://pagure.io/fesco/issue/2451
>>
>> We will keep you posted if anything changes.
>>
>> Thanks.
>>
>> On Mon, Jul 20, 2020 at 5:38 PM Mohan Boddu  wrote:
>>> Mohan Boddu 
>>>
>>> 4:32 PM (1 hour ago)
>>> to devel-announce
>>> Hi all,
>>>
>>> Per the Fedora 33 schedule[1] we will start a mass rebuild for Fedora 33
>>> on Jul 22nd 2020. We will run a mass rebuild for Fedora 33 for the
>>> changes listed in:
>>>
>>> https://pagure.io/releng/issues?status=Open=mass+rebuild
>>>
>>> Mass rebuild will be done in a side tag (f33-rebuild) and moved over
>>> when completed.
>>>
>>> Failures can be seen
>>> https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html
>>>
>>> Things still needing rebuilt
>>> https://kojipkgs.fedoraproject.org/mass-rebuild/f33-need-rebuild.html
>>>
>>> FTBFS bugs will be filed shortly.
>>>
>>> Please be sure to let releng know if you see any bugs in the
>>> reporting. You can contact releng in #fedora-releng on freenode, by
>>> dropping an email to our list[2] or filing an issue in pagure[3]
>>>
>>> Regards,
>>> Mohan Boddu.
>>>
>>> [1] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
>>> [2] 
>>> https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
>>> [3] https://pagure.io/releng/
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: module build: BuildrootError: could not init mock buildroot

2020-08-03 Thread Vít Ondruch

Dne 02. 08. 20 v 0:21 Kevin Fenzi napsal(a):
> On Fri, Jul 31, 2020 at 04:05:20PM +0200, Jun Aruga wrote:
>> Hi,
>> Sometimes once per a few times,  I faced the following weird build
>> error when building Ruby modules.
>> Did you see it? Known issue?
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=48194471
>> BuildrootError: could not init mock buildroot, mock exited with status
>> 20; see root.log for more information
>>
>> https://kojipkgs.fedoraproject.org//work/tasks/4473/48194473/root.log
>>   => looks ok.
>> https://kojipkgs.fedoraproject.org//work/tasks/4473/48194473/build.log
>>   => empty.
>>
> Weird. The actual error is: 
> "ERROR: Could not find useradd in chroot, maybe the install failed?"


It seems there is nothing installed into build root  except of
module-build-macros-0.1-1.module_f30+8976+2502a8ed.noarch, that does not
appear to be enough to have `useradd` present in the build root.

So isn't this the relevant part of root.log which could give a hint?

~~~

DEBUG util.py:621:  No match for group package "rpm-build"
DEBUG util.py:621:  No match for group package "fedpkg-minimal"
DEBUG util.py:621:  No match for group package "shadow-utils"
DEBUG util.py:621:  No match for group package "gnupg2"
DEBUG util.py:621:  No match for group package "bash"
DEBUG util.py:621:  No match for group package "glibc-minimal-langpack"
DEBUG util.py:621:  No match for group package "redhat-rpm-config"
DEBUG util.py:621:  No match for group package "fedora-release"

~~~


Vít


>
> But that sounds like what happens when it didn't install the build rpms
> in there. 
>
> Can you try again now? we fixed a major issue with mbs, which I wouldn't
> think was related to this, but who knows... 
>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Minimal Mock's buildroot

2020-08-03 Thread Vít Ondruch
Quite some stuff from the list are "soft" dependencies of rpmbuild, e.g.
the compression algorithms. May be we should have discussion if we
should have BR on the decompression library, or if the BR could be
autogenerated.


Vít



Dne 02. 08. 20 v 22:06 Miroslav Suchý napsal(a):
> As part of
>   https://github.com/rpm-software-management/mock/issues/382
> I found that the very minimal spec file can be built only using:
>* shadow-utils - mock needs /usr/sbin/useradd from this package
>* rpm-build - mock needs /usr/bin/rpmbuild
>* glibc-minimal-langpack - this is optional, but helps to avoid
>   installation of huge glibc-all-langpacks.
> in buildroot. Everything else is transitively installed.
>
> Though the list of those transitive dependencies is quite long (see end of 
> this mail).
> It may come handy to minimization team. I see there some low-hanging fruits:
>  * why gdb-minimal, quile, dwz (needed for debuginfos) - especially when gcc 
> has to be explicitly stated?
>  * do we really need alternatives in minimal buildroot?
>  * do we really need zip and unzip in minimal buildroot?
> But every change in minimal buildroot needs lots of administrative work 
> (fesco, fepco, communication with packagers
> affected by change). I currently do not have will to work on this. So this is 
> merely FYI and for anyone willing to
> continue to work on this.
>
> List of transitive dependencies.
>
> alternatives-1.11-6.fc32.x86_64
> audit-libs-3.0-0.19.20191104git1c2f876.fc32.x86_64
> basesystem-11-9.fc32.noarch
> bash-5.0.11-2.fc32.x86_64
> binutils-gold-2.34-2.fc32.x86_64
> binutils-2.34-2.fc32.x86_64
> bzip2-libs-1.0.8-2.fc32.x86_64
> bzip2-1.0.8-2.fc32.x86_64
> ca-certificates-2020.2.40-3.fc32.noarch
> coreutils-common-8.32-3.fc32.1.x86_64
> coreutils-8.32-3.fc32.1.x86_64
> cpio-2.13-4.fc32.x86_64
> crypto-policies-20191128-5.gitcd267a5.fc32.noarch
> curl-7.69.1-1.fc32.x86_64
> cyrus-sasl-lib-2.1.27-4.fc32.x86_64
> diffutils-3.7-4.fc32.x86_64
> efi-srpm-macros-4-4.fc32.noarch
> elfutils-default-yama-scope-0.179-1.fc32.noarch
> elfutils-libelf-0.179-1.fc32.x86_64
> elfutils-libs-0.179-1.fc32.x86_64
> elfutils-0.179-1.fc32.x86_64
> expat-2.2.8-2.fc32.x86_64
> fedora-gpg-keys-32-1.noarch
> fedora-release-common-32-1.noarch
> fedora-release-32-1.noarch
> fedora-repos-32-1.noarch
> file-libs-5.38-2.fc32.x86_64
> filesystem-3.14-2.fc32.x86_64
> file-5.38-2.fc32.x86_64
> findutils-4.7.0-3.fc32.x86_64
> fonts-srpm-macros-2.0.3-1.fc32.noarch
> fpc-srpm-macros-1.3-1.fc32.noarch
> gawk-5.0.1-7.fc32.x86_64
> gc-8.0.4-3.fc32.x86_64
> gdb-minimal-9.1-3.fc32.x86_64
> ghc-srpm-macros-1.5.0-2.fc32.noarch
> glibc-all-langpacks-2.31-2.fc32.x86_64
> glibc-common-2.31-2.fc32.x86_64
> glibc-2.31-2.fc32.x86_64
> gmp-6.1.2-13.fc32.x86_64
> gnat-srpm-macros-4-11.fc32.noarch
> go-srpm-macros-3.0.8-5.fc32.noarch
> grep-3.3-4.fc32.x86_64
> guile-2.0.14-19.fc32.x86_64
> gzip-1.10-2.fc32.x86_64
> keyutils-libs-1.6-4.fc32.x86_64
> krb5-libs-1.18-1.fc32.x86_64
> libacl-2.2.53-5.fc32.x86_64
> libarchive-3.4.2-1.fc32.x86_64
> libattr-2.4.48-8.fc32.x86_64
> libbrotli-1.0.7-10.fc32.x86_64
> libcap-ng-0.7.10-2.fc32.x86_64
> libcap-2.26-7.fc32.x86_64
> libcom_err-1.45.5-3.fc32.x86_64
> libcurl-7.69.1-1.fc32.x86_64
> libdb-utils-5.3.28-40.fc32.x86_64
> libdb-5.3.28-40.fc32.x86_64
> libffi-3.1-24.fc32.x86_64
> libgcc-10.0.1-0.11.fc32.x86_64
> libgomp-10.0.1-0.11.fc32.x86_64
> libidn2-2.3.0-2.fc32.x86_64
> libmetalink-0.1.3-10.fc32.x86_64
> libnghttp2-1.40.0-2.fc32.x86_64
> libpkgconf-1.6.3-3.fc32.x86_64
> libpsl-0.21.0-4.fc32.x86_64
> libselinux-3.0-3.fc32.x86_64
> libsemanage-3.0-3.fc32.x86_64
> libsepol-3.0-3.fc32.x86_64
> libsigsegv-2.11-10.fc32.x86_64
> libssh-config-0.9.3-2.fc32.noarch
> libssh-0.9.3-2.fc32.x86_64
> libstdc++-10.0.1-0.11.fc32.x86_64
> libtasn1-4.16.0-1.fc32.x86_64
> libtool-ltdl-2.4.6-33.fc32.x86_64
> libunistring-0.9.10-7.fc32.x86_64
> libverto-0.3.0-9.fc32.x86_64
> libxcrypt-4.4.16-1.fc32.x86_64
> libxml2-2.9.10-3.fc32.x86_64
> libzstd-1.4.4-2.fc32.x86_64
> lua-libs-5.3.5-7.fc32.x86_64
> lz4-libs-1.9.1-2.fc32.x86_64
> mpfr-4.0.2-3.fc32.x86_64
> ncurses-base-6.1-15.20191109.fc32.noarch
> ncurses-libs-6.1-15.20191109.fc32.x86_64
> ncurses-6.1-15.20191109.fc32.x86_64
> nim-srpm-macros-3-2.fc32.noarch
> ocaml-srpm-macros-6-2.fc32.noarch
> openblas-srpm-macros-2-7.fc32.noarch
> openldap-2.4.47-4.fc32.x86_64
> openssl-libs-1.1.1d-7.fc32.x86_64
> patch-2.7.6-12.fc32.x86_64
> pcre2-syntax-10.34-9.fc32.noarch
> pcre2-10.34-9.fc32.x86_64
> pcre-8.44-1.fc32.x86_64
> perl-srpm-macros-1-34.fc32.noarch
> pkgconf-m4-1.6.3-3.fc32.noarch
> pkgconf-pkg-config-1.6.3-3.fc32.x86_64
> pkgconf-1.6.3-3.fc32.x86_64
> popt-1.16-19.fc32.x86_64
> publicsuffix-list-dafsa-20190417-3.fc32.noarch
> python-srpm-macros-3-55.fc32.noarch
> p11-kit-trust-0.23.20-1.fc32.x86_64
> p11-kit-0.23.20-1.fc32.x86_64
> qt5-srpm-macros-5.13.2-2.fc32.noarch
> readline-8.0-4.fc32.x86_64
> redhat-rpm-config-150-1.fc32.noarch
> 

Orphaned rubygem-fast_gettext

2020-07-29 Thread Vít Ondruch
Hi,

I have orphaned rubygem-fast_gettext, because I have no use for it,
neither anything else depends on it.


VĂ­t
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaning ruby-ldap

2020-07-28 Thread Vít Ondruch
I don't have any use for ruby-ldap package. It is not in the best
condition. While it probably works, it does not follow the best
practices and it would deserve to be replaced by rubygem-ldap if
somebody considering to keep it in Fedora.

Anyway, I have orphaned it.


VĂ­t
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Very strange compiler/linker related build failures in rawhide

2020-07-27 Thread Vít Ondruch

Dne 27. 07. 20 v 12:25 Vít Ondruch napsal(a):
> Dne 24. 07. 20 v 21:01 Jeff Law napsal(a):
>> On Fri, 2020-07-24 at 20:52 +0200, Vít Ondruch wrote:
>>> The LTO break Ruby on various platforms.
>>>
>>>
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=47582573
>>>
>>> vs
>>>
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=47621733
>>>
>>> (Note these are my experimental builds testing single test case).
>> I haven't gotten a clean ruby build with or without LTO.
>
> Ruby builds just fine on x86_64 according to Koschei:
>
> https://koschei.fedoraproject.org/package/ruby?
>
>
>>   So I haven't
>> investigated Ruby for any LTO specific failures.
>>
>>> The only difference is redhat-rpm-config 162-1.fc33 => 163-1.fc33.
>>> Adding `%define _lto_cflags %{nil}` helped to recover, but if it was at
>>> least behaving the same on all platforms :/
>>>
>>>
>>> And this is Koschei failure: https://koschei.fedoraproject.org/package/ruby?
>>>
>>> Looking at the full test suite, it seems it causes some troubles to
>>> SIGSEV signal handler (Ruby spawns subprocess and kills it).
>> Does the signal handler modify any global variables?
>
> I am afraid there happens a lot of interesting stuff. This is the method
> responsible for printing the output which likely fails:
>
> https://github.com/ruby/ruby/blame/master/vm_dump.c#L920
>
> But the issue might be that the signal handler itself might be somehow
> modified and the modification fails. This is the default signal handler:
>
> https://github.com/ruby/ruby/blob/master/signal.c#L1137
>
>
>>   That's been a common source
>> of issues I've seen.
>
> I am afraid I'll need to open some upstream ticket to help with answers
> to questions like this :/


https://bugs.ruby-lang.org/issues/17052


Vít


>
>
> Vít
>
>
>> jeff
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: List of long term FTBFS packages to be retired in August

2020-07-27 Thread Vít Ondruch

Dne 26. 07. 20 v 13:44 Miro Hrončok napsal(a):
> On 29. 06. 20 17:49, Vít Ondruch wrote:
>> Dne 29. 06. 20 v 17:21 Miro Hrončok napsal(a):
>>> js-jquery1 nodejs-sig, patches, vondruch   Fedora 30
>>> js-jquery2 vondruch    Fedora 30
>>> js-sizzle  nodejs-sig, patches, vondruch   Fedora 30
>>>
>> I was ranting about js-jquery (and js-sizzle is dependency of js-jquery)
>> on this list already several times. I picked it up just to keep it alive
>> in whatever state, because bundling it everywhere won't make things
>> better. So is there anybody who would like to give it some love? Or
>> should I let the packages finally go and let everybody else to bundle
>> whatever they want?
>
> Since the packages are on their way to retirement, I've taken a look.
>
> 1) I see that most of the build dependencies of js-jquery1/js-jquery2
> are gone.
>
> 2) I see that all the FTBFS bugs are ASSIGNED without a single
> response about a plan to fix the problem. From your emails it seems
> the plan was always to "do nothing".
>
> 3) I see that both jqueries have several moderate CVEs open without a
> single response for months. From your "in whatever state" staement it
> seems the plan was to never fix those. The packages would need to be
> buildable in the first place in order to be able to fix them.
>
> Arguably, the benefit of having an unbundled dependency is mostly gone
> when the library is not maintained at all. It seems safer if other
> packages bundle and when they have a CVE open, the maintainers can
> evaluate the impact of the problem on their package. Even if 100
> packages bundle jquery and only 10 of them evaluate the impact of CVEs
> and/or fix the CVEs in their packages, the situation is better than now.


I think this is a bit optimistic POV. I think that in most of the
packages, there won't be even "bundled(jquery)" which would let the SRT
report the proper trackers. But I hope you are right and I am wrong :)


>
> So yes, please let the packages go.

I will.



Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Very strange compiler/linker related build failures in rawhide

2020-07-27 Thread Vít Ondruch

Dne 24. 07. 20 v 21:01 Jeff Law napsal(a):
> On Fri, 2020-07-24 at 20:52 +0200, Vít Ondruch wrote:
>> The LTO break Ruby on various platforms.
>>
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=47582573
>>
>> vs
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=47621733
>>
>> (Note these are my experimental builds testing single test case).
> I haven't gotten a clean ruby build with or without LTO.


Ruby builds just fine on x86_64 according to Koschei:

https://koschei.fedoraproject.org/package/ruby?


>   So I haven't
> investigated Ruby for any LTO specific failures.
>
>>
>> The only difference is redhat-rpm-config 162-1.fc33 => 163-1.fc33.
>> Adding `%define _lto_cflags %{nil}` helped to recover, but if it was at
>> least behaving the same on all platforms :/
>>
>>
>> And this is Koschei failure: https://koschei.fedoraproject.org/package/ruby?
>>
>> Looking at the full test suite, it seems it causes some troubles to
>> SIGSEV signal handler (Ruby spawns subprocess and kills it).
> Does the signal handler modify any global variables?


I am afraid there happens a lot of interesting stuff. This is the method
responsible for printing the output which likely fails:

https://github.com/ruby/ruby/blame/master/vm_dump.c#L920

But the issue might be that the signal handler itself might be somehow
modified and the modification fails. This is the default signal handler:

https://github.com/ruby/ruby/blob/master/signal.c#L1137


>   That's been a common source
> of issues I've seen.


I am afraid I'll need to open some upstream ticket to help with answers
to questions like this :/


Vít


>
> jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Very strange compiler/linker related build failures in rawhide

2020-07-24 Thread Vít Ondruch
The LTO break Ruby on various platforms.


https://koji.fedoraproject.org/koji/taskinfo?taskID=47582573

vs

https://koji.fedoraproject.org/koji/taskinfo?taskID=47621733

(Note these are my experimental builds testing single test case).


The only difference is redhat-rpm-config 162-1.fc33 => 163-1.fc33.
Adding `%define _lto_cflags %{nil}` helped to recover, but if it was at
least behaving the same on all platforms :/


And this is Koschei failure: https://koschei.fedoraproject.org/package/ruby

Looking at the full test suite, it seems it causes some troubles to
SIGSEV signal handler (Ruby spawns subprocess and kills it).


Vít



Dne 24. 07. 20 v 10:31 Fabio Valentini napsal(a):
> Hi all,
>
> I'm starting to see various very strange kinds of build failures in
> rawhide, that seem to have started with either of these updates (or a
> combination of them):
>
> - annobin 9.21-1.fc33 → 9.22-1.fc33
> - binutils 2.34.0-6.fc33 → 2.34.0-7.fc33
> - elfutils 0.179-2.fc33 → 0.180-2.fc33
> - glibc 2.31.9000-13.fc33 → 2.31.9000-14.fc33
>
> These rawhide updates all happened at roughly the same time, so it's
> difficult to say which one of them is to blame (if any of them).
>
> One error I've seen in libreoffice is a gcc / annobin segfault:
>
> [build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
> *** WARNING *** there are active plugins, do not report this as a bug
> unless you can reproduce it without enabling any plugins.
> Event| Plugins
> PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
> PLUGIN_START_UNIT| annobin: Generate global annotations
> PLUGIN_ALL_PASSES_START  | annobin: Generate per-function annotations
> PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbol
> /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
> destructor 'virtual DemoWin::RenderThread::~RenderThread()':
> /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
> internal compiler error: Segmentation fault
>  1733 | join();
>   |  ^
>
> Other errors look like this one from switchboard-plug-onlineaccounts:
>
> src/libonline-accounts.so.p/Authentification/Server.c: In function
> ‘online_accounts_server_on_bus_acquired’:
> src/libonline-accounts.so.p/Authentification/Server.c:498:2: error:
> function ‘__errno_location’ is initialized like a variable
>   498 |  gint errno = 0;
>   |  ^~~~
>
> Where errno is neither __errno_location, nor a function, but a gint??
>
> Other failures I've seen end up with linker failures, line these, from
> postgresql:
>
> ld: undefined reference to `postgresql_subtrans__checkpoint__start_semaphore'
>
> Does somebody have a clue what's going on here? It's currently
> blocking rawhide composes because libreoffice fails to build /
> install.
>
> See also: https://pagure.io/releng/failed-composes/issue/1571
>
> Thanks,
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

2020-07-24 Thread Vít Ondruch
Just FTR, I don't think I am going to reveal too much saying that for
RHEL9, the sentiment is (at least in the context of Ruby, Node.js and
Python) that we are very likely not going to use default streams. Plain
old RPMs do mostly the same job.

In this context, I'd be more than happy if the documentation discouraged
use of the default streams. Something along these lines: "Modularity
have default stream feature, but use it with caution only if you know
what you do and what is the impact."


Vít


Dne 09. 07. 20 v 20:00 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/ModularPolicy
>
> == Summary ==
> Establish a set of rules for Modular content in Fedora to ensure an
> optimal user and packager experience.
>
> == Owner ==
> * Name: [[User:Sgallagh| Stephen Gallagher]]
> * Email: sgall...@redhat.com
>
> == Detailed Description ==
> Over the last several months, members of the Modularity WG and FESCo
> have been working to establish a policy for module inclusion in
> Fedora. We now have a proposal that FESCo requested be taken to the
> Fedora community via the Change Proposal.
>
> There is a preview of the new policy available at
> https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/
>
>
> == Benefit to Fedora ==
> This policy makes explicit what packagers can and cannot do with
> Modules in Fedora, which should avoid future issues like those that
> were seen during the Fedora 31 and Fedora 32 cycles.
>
> == Scope ==
> * Proposal owners:
> The proposal is written, so minimal work remains. We may need to make
> revisions or clarifications based on public feedback.
>
> * Other developers: N/A (not a System Wide Change)
> * Release engineering: N/A
> N/A (not a System Wide Change)
>
> == How To Test ==
> N/A (not a System Wide Change)
>
> == User Experience ==
> N/A this is not a user-facing change.
>
> == Dependencies ==
> N/A (not a System Wide Change)
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) N/A (not a
> System Wide Change)
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? N/A (not a System Wide Change)
>
> == Documentation ==
> N/A (not a System Wide Change)
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Modularity Improvements Objective

2020-07-24 Thread Vít Ondruch

Dne 24. 07. 20 v 14:25 Petr Pisar napsal(a):
> On Fri, Jul 24, 2020 at 01:44:07PM +0200, Daniel Mach wrote:
>> There's a Modularity Improvements Objective draft available[1].
>>
>> The Objective summarizes the work that is in progress already as well as
>> highlights our plans for Fedora 34.
>>
>> We're planning to fix the current modularity in Fedora 33 and 34.
>> We may look into alternatives or bigger design changes in Fedora 35 and
>> later.
>>
>> You can find more details in the Objective document[1].
>>
>> - Daniel
>>
>> [1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020
> I hope that you find resources to properly maintain MBS.


+1

This document seems to focus on "DNF" side of thing, while completely
missing the infrastructure side. E.g. MBS, dist-git, mass rebuilds, etc.


Vít


>  Currently (last two
> weeks) it cannot build the modules
> .
>
> -- Petr
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

2020-07-22 Thread Vít Ondruch

Dne 22. 07. 20 v 14:55 Stephen Gallagher napsal(a):
> On Mon, Jul 13, 2020 at 1:06 PM Vít Ondruch  wrote:
>> Is this just about the specific URL or also about the "Naming Policy"?
> The Naming Policy is not currently under discussion in this proposal.
> Only the URL provided in the Change Proposal is applicable right now.
>
> If you want to submit a suggested improvement for the Naming Policy,
> please file an issue or send a PR to
> https://pagure.io/fedora-docs/modularity/


Done:

https://pagure.io/fedora-docs/modularity/pull-request/88


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 in 6th gear

2020-07-17 Thread Vít Ondruch
Thx to everybody who submitted the change proposal. It is nice that
people follow the process instead of just pushing something into Fedora
without sharing with wider audience.


Vít


Dne 16. 07. 20 v 19:52 Zbigniew Jędrzejewski-Szmek napsal(a):
> In the FESCo meeting summary email sent out today there were 10
> changes approved. I had the feeling that this is more than usual,
> so I took a look at the wiki.
>
> Tally (systemd-wide and self-contained):
> F20: 14 + 22
> F21: 28 + 34
> F22: 21 + 15
> F23: 12 +  7
> F24: 20 + 23
> F25:  9 + 11
> F26: 17 + 22
> F27: 20 + 15
> F28: 31 + 19
> F29: 23 + 20
> F30: 25 + 24
> F31: 21 + 21
> F32: 23 + 20
> F33: 40 + 18 (and growing)
>
> Seems that this be a busy release :)
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

2020-07-13 Thread Vít Ondruch
Is this just about the specific URL or also about the "Naming Policy"?

I am asking, because I already had a lot of arguments about the
branching on this list and various different places but this guideline
still insist that "using upstream major versions as branches is
recommended". This is not acceptable, because this works just for
simplest cases, such as there is module "nodejs" shipping single package
"nodejs". It does not work for even slightly more complex cases when
module "nodejs" includes not just "nodejs" package, but also lets say
"npm" package. Having Node.js versioned brachnes in "npm" is wrong. Not
mentioning that if I'll have "mynodejs" module, using both "nodejs" and
"npm" and probably also other packages, the versions will be already
occupied by "nodejs" module.

IOW, the modular packages must live in "module-version" branches by
default. This avoids conflicts and provides more understanding why "npm"
package has some branches.


Vít


Dne 09. 07. 20 v 20:00 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/ModularPolicy
>
> == Summary ==
> Establish a set of rules for Modular content in Fedora to ensure an
> optimal user and packager experience.
>
> == Owner ==
> * Name: [[User:Sgallagh| Stephen Gallagher]]
> * Email: sgall...@redhat.com
>
> == Detailed Description ==
> Over the last several months, members of the Modularity WG and FESCo
> have been working to establish a policy for module inclusion in
> Fedora. We now have a proposal that FESCo requested be taken to the
> Fedora community via the Change Proposal.
>
> There is a preview of the new policy available at
> https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/
>
>
> == Benefit to Fedora ==
> This policy makes explicit what packagers can and cannot do with
> Modules in Fedora, which should avoid future issues like those that
> were seen during the Fedora 31 and Fedora 32 cycles.
>
> == Scope ==
> * Proposal owners:
> The proposal is written, so minimal work remains. We may need to make
> revisions or clarifications based on public feedback.
>
> * Other developers: N/A (not a System Wide Change)
> * Release engineering: N/A
> N/A (not a System Wide Change)
>
> == How To Test ==
> N/A (not a System Wide Change)
>
> == User Experience ==
> N/A this is not a user-facing change.
>
> == Dependencies ==
> N/A (not a System Wide Change)
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) N/A (not a
> System Wide Change)
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? N/A (not a System Wide Change)
>
> == Documentation ==
> N/A (not a System Wide Change)
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: List of long term FTBFS packages to be retired in August

2020-07-03 Thread Vít Ondruch
Would you mind to follow this page to get sponsored?

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Also, it would be probably good to join the Node.js SIG to coordinate
and start contributing via PRs.

While I could sponsor you, I don't think I'd be good mentor for node
packaging. Sorry.


Vít


Dne 02. 07. 20 v 13:42 Alexandre de Farias napsal(a):
> In fact, I am not at this time.
>
> On Wed, 2020-07-01 at 15:38 +0200, Vít Ondruch wrote:
>> Hi Alexandre,
>>
>> Thank you for your offer. I just wonder, are you sponsored into
>> packager group?
>>
>>
>>
>> Vít
>>
>>
>>
>>
>>
>> Dne 29. 06. 20 v 17:57 alexandrebfar...@gmail.com napsal(a):
>>> I'm interested in helping with those NodeJS packages. 
>>>
>>> -- 
>>> Alexandre de Farias / etinin
>>>
>>> On Mon, Jun 29, 2020, 12:50 Vít Ondruch 
>>> wrote:
>>>> Dne 29. 06. 20 v 17:21 Miro Hrončok napsal(a):
>>>>> js-jquery1 nodejs-sig, patches, vondruch   Fedora
>>>> 30
>>>>> js-jquery2 vondruchFedora
>>>> 30
>>>>> js-sizzle  nodejs-sig, patches, vondruch   Fedora
>>>> 30
>>>> I was ranting about js-jquery (and js-sizzle is dependency of js-
>>>> jquery)
>>>> on this list already several times. I picked it up just to keep
>>>> it alive
>>>> in whatever state, because bundling it everywhere won't make
>>>> things
>>>> better. So is there anybody who would like to give it some love?
>>>> Or
>>>> should I let the packages finally go and let everybody else to
>>>> bundle
>>>> whatever they want?
>>>>
>>>>
>>>>
>>>> Vít
>>>>
>>>> ___
>>>> devel mailing list -- devel@lists.fedoraproject.org
>>>> To unsubscribe send an email to 
>>>> devel-le...@lists.fedoraproject.org
>>>> Fedora Code of Conduct: 
>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>> List Guidelines: 
>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> List Archives: 
>>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>>>
>>>
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: 
>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: 
>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?

2020-07-02 Thread Vít Ondruch
I just met something which might be of similar nature. Recent FF
78.0-1.fc33.x86_64 fails to start with older glibc:


~~~

$ firefox
XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
/usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np,
version GLIBC_2.32
Couldn't load XPCOM.

~~~


Update of glibc from glibc-2.31.9000-13.fc33.x86_64 to
glibc-common-2.31.9000-16.fc33.x86_64 resolved the issue. Nevertheless
issues like this are unexpected. There should be something, what would
force glibc update if FF requires more recent one.


Vít


Dne 01. 07. 20 v 6:57 Florian Weimer napsal(a):
> * Alex Scheel:
>
>> Is Fedora Rawhide unstable at the moment, pending a mass rebuild?
>>
>> I've seen a lot of random problems related to pthreads at the
>> moment, such as:
>>
>> 16/78 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...Child 
>> aborted***Exception:   0.99 sec
>> FINE: CryptoManager: loading JSS library
>> FINE: CryptoManager: loaded JSS library from java.library.path
>> java: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion 
>> `mutex->__data.__owner == 0' failed.
>>
>>
>> Another, different stack trace here (pthreads fails to lock,
>> triggering a bug in opencryptoki):
>>
>> https://pagure.io/dogtagpki/issue/3181#comment-661911
> I don't see why this would be fixed by a mass rebuild.
>
> This is probably some sort of memory corruption: something has
> overwritten the mutex data structure, and glibc happens to detect that.
>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: List of long term FTBFS packages to be retired in August

2020-07-01 Thread Vít Ondruch
Hi Alexandre,

Thank you for your offer. I just wonder, are you sponsored into packager
group?


Vít



Dne 29. 06. 20 v 17:57 alexandrebfar...@gmail.com napsal(a):
> I'm interested in helping with those NodeJS packages. 
>
> -- 
> Alexandre de Farias / etinin
>
> On Mon, Jun 29, 2020, 12:50 Vít Ondruch  <mailto:vondr...@redhat.com>> wrote:
>
>
> Dne 29. 06. 20 v 17:21 Miro Hrončok napsal(a):
> > js-jquery1 nodejs-sig, patches, vondruch   Fedora 30
> > js-jquery2 vondruch    Fedora 30
> > js-sizzle  nodejs-sig, patches, vondruch   Fedora 30
> >
>
> I was ranting about js-jquery (and js-sizzle is dependency of
> js-jquery)
> on this list already several times. I picked it up just to keep it
> alive
> in whatever state, because bundling it everywhere won't make things
> better. So is there anybody who would like to give it some love? Or
> should I let the packages finally go and let everybody else to bundle
> whatever they want?
>
>
>
> Vít
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> <mailto:devel-le...@lists.fedoraproject.org>
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: List of long term FTBFS packages to be retired in August

2020-06-29 Thread Vít Ondruch

Dne 29. 06. 20 v 17:21 Miro Hrončok napsal(a):
> js-jquery1 nodejs-sig, patches, vondruch   Fedora 30
> js-jquery2 vondruch    Fedora 30
> js-sizzle  nodejs-sig, patches, vondruch   Fedora 30
>

I was ranting about js-jquery (and js-sizzle is dependency of js-jquery)
on this list already several times. I picked it up just to keep it alive
in whatever state, because bundling it everywhere won't make things
better. So is there anybody who would like to give it some love? Or
should I let the packages finally go and let everybody else to bundle
whatever they want?



Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-06-26 Thread Vít Ondruch

Dne 26. 06. 20 v 15:17 Ben Cotton napsal(a):
> On Fri, Jun 26, 2020 at 9:14 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
>> On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:
>>> Which is better? default or defaults? I don't have a preference.
>> I went with "-defaults" in this case because the package provides "the
>> default configuration", i.e. "defaults".
>>
>> This doesn't translate exactly to the nano case, which is about making
>> the program the default "plugin" in another program (git).
>>
> What about something like "default-editor"?


Shouldn't it be independent package then? Or shouldn't all editors have
subpackage like this?


Vít


>  That way it's more obvious
> from the name what it actually does. If we later decide to change the
> default editor, we update that package (and spins/labs, power users,
> etc can exclude that package in kickstarts if they don't want it)
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2020-06-24 Thread Vít Ondruch
I wonder if there is PR with the implementation somewhere or is this
just dry theoretical discussion O:-)



Vít


Dne 19. 06. 20 v 23:11 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
>
> == Summary ==
> This change will update all spec files in Fedora that use make and
> replace the make invocations with either the %make_build or
> %make_install macros.
>
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email: mailto:tstel...@redhat.com>>
>
>
> == Detailed Description ==
>
> The goal of this change is to standardize the usage of make in
> Fedora.  All make invocations in spec files that don't use the install
> target will be modified to use the %make_build macro, and all make
> invocations that use the install target will be updated to use the
> %make_install macro.  Any additional arguments to make that are not
> included in either the %make_build and %make_install will be preserved.
>
> The %make_build macro enables parallel make builds using the -j
> option.  In case a package does not build correctly with parallel
> make, then parallel make will be disabled for that package by
> redefining the %_smp_mflags macro like this:
>
>   %global _smp_mflags -j1
>
> All changes will be submitted to dist-git repositories via pull
> requests.  Pull requests will be merged after 1 week if there are no
> objections or earlier if approved by the package maintainers.
>
> A script will be used to apply the necessary changes to the spec
> files, and the result will be manually inspected before being merged.
>
> All packages updated by this change request will be rebuilt after the
> spec file changes are merged.
>
> Some packages already use the %make_build and %make_install macros. 
> These packages will be left unchanged.
>
> == Benefit to Fedora ==
> * Reduced build times: Using the %make_build macros enables parallel
> make builds which will reduce build times for Fedora packages.
>
> * This will make it easier to enforce consistent build flag usage
> across all of Fedora.
>
> == Scope ==
> * Proposal owners: Update spec files and submit pull requests and do
> new package builds.  Optional: Merge pull requests (Proposal Owner
> would need to request to be added to provenpackagers group)
>
> * Other developers: Package owners may merge pull requests and submit
> new builds if they want, but this is not required for them.  A member
> of the provenpackagers group will be needed to merge pull requests.
> * Release engineering: [https://pagure.io/releng/issues/9533 #9533]
>
> * Policies and guidelines: Package guidelines already specify that
> packages should use these macros when possible.  Documentation will be
> updated to clarify that %make_build should be used for all make
> invocations (besides make install), and also with instructions for
> packages that fail to build with parallel make.
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> No impact.
>
> == How To Test ==
> End-users will not notice any changes.
>
> == Dependencies ==
> No real dependencies, each package can be updated independently.
>
> == Contingency Plan ==
> * Contingency mechanism: None.  If not all packages are updated in
> time, then the work can continue into the next release. 
> * Contingency deadline: All work will be done in the rawhide branch,
> and will not be backported into the f33 branch once it is created, so
> whatever gets done before the branch date will make it into the release. 
> * Blocks release? No
>
> == Documentation ==
> The packaging guidelines will be updated as described in the Scope
> Section.
>
>
>
> -- 
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Vít Ondruch

Dne 24. 06. 20 v 17:04 Neal Gompa napsal(a):
> On Wed, Jun 24, 2020 at 10:45 AM Vít Ondruch  wrote:
>>
>> Dne 24. 06. 20 v 15:47 Miro Hrončok napsal(a):
>>> On 24. 06. 20 14:41, Vít Ondruch wrote:
>>>> Having python27 and python36 modules is fail, because these should be
>>>> 2.7 and 3.6 streams of python module.
>>> Oh. We are so sorry for the failure. Could you please report is as a
>>> bug in RHEL 8 and explain why it is a problem?
>>>
>> If you have not stripped the context, it would be more obvious.
>>
>> There is no philosophical (or design?) reason to not have Python 2.7 and
>> 3.6 streams in one module. There are just technical reasons, such as
>> that you want to install them in parallel which is not possible.
>>
> My CentOS 8.2 system with Python 2.7, 3.6, and 3.8 all simultaneously
> installed disagrees with this statement. Modularity makes no effort to
> hide the complexity of parallel installability. It only helps make
> clearer how to handle availability of multiple sets of content from a
> repository. Parallel installability is up to the module author.


Is it? Does modularity allow to install multiple streams if they don't
collide? IOW if there was python module with non colliding 2.7 and 3.6
streams, would I be able to simply run:


~~~

$ sudo dnf module enable python 2.7

$ sudo dnf module enable python 3.6

$ python2.7 -V

Python 2.7.5

$ python3.6 -V

Python 3.6.8

~~~


Reading following resources, I don't think it is possible, but I might
be wrong:


https://docs.fedoraproject.org/en-US/modularity/architecture/consuming/

https://docs.fedoraproject.org/en-US/modularity/using-modules-switching-streams/


If the above is really possible, I would like to see the documentation
extended to cover such scenario.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Packager Dashboard available for testing

2020-06-24 Thread Vít Ondruch

Dne 24. 06. 20 v 11:24 Josef Skladanka napsal(a):
> First of all, thanks for the feedback!
>
> On Wed, Jun 24, 2020 at 10:28 AM Vít Ondruch  wrote:
>> Would it be possible to change the "reset" to something like "set
>> all/unset all". When I wanted to know what actually "orphaned" means, I
>> had to click on every option, which is not very convenient.
> We'll absolutely discuss it. Do you think that once Zbyszek's RFE is
> implemented, this would be solved for you?


I think it would be much better, but it would still not be possible to
start with blank table (what is actually antonym to filter, because that
was the first word which come to my mind).


>
>> Also, I am not sure about the "provenpackager" group. Should it be
>> displayed? Should it do something?
> We are already "discarding" some groups, seems like provenpackagers
> just slipped the cut. if provenpackagers group owns no packages


The group owns all or nothing, depends on POV. The "provenpackager"
group should actually display all packages, but that would be unbearable
I guess.


> , I
> think we could/should just cut it too. Frantisek/Lukas - WDYT?
>> Actually the whole "groups" section is a bit confusing. I am not sure
>> what the radio buttons do (I am aware about the hints, but they don't
>> make the situation better understandable to me).
> I honestly absolutely agree it is not ideal. We have tried many
> iterations of the hints, and this is by far the best we've came up
> with.
> The idea behind the filters is this:
>  - "blind eye icon" - if selected, you won't see any packages owned by
> the group, even if you are the "primary maintainer" (forgive my,
> probably wrong, terminology)
>  - "single person icon" - when picked, only packages "belonging to the
> group" that you are the "owner"/"primary maintainer" are shown
>  - "three people icon" - if this option is selected, packages from the
> group are shown even if you don't own them
>
> We'd be happy for any suggestions you might have, on how to make this
> comprehensible.


I think the problem is the radio button. Since this is not filter, but
something which adds packages, then there should be toggle enabling and
disabling the group instead of the eye. Then there could be
toggle/checkbox "show all", which unchecked would mean show only my
packages.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Vít Ondruch

Dne 24. 06. 20 v 15:47 Miro Hrončok napsal(a):
> On 24. 06. 20 14:41, Vít Ondruch wrote:
>> Having python27 and python36 modules is fail, because these should be
>> 2.7 and 3.6 streams of python module.
>
> Oh. We are so sorry for the failure. Could you please report is as a
> bug in RHEL 8 and explain why it is a problem?
>

If you have not stripped the context, it would be more obvious.

There is no philosophical (or design?) reason to not have Python 2.7 and
3.6 streams in one module. There are just technical reasons, such as
that you want to install them in parallel which is not possible.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Vít Ondruch

Dne 20. 06. 20 v 23:40 Neal Gompa napsal(a):
> On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr  
> wrote:
>> On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
>>> TL;DR benefits of modularity for Fedora:
>>>
>>> * Automating build chains for producing artifacts
>>> * Straightforward mechanism of producing non-rpm artifacts using our
>>> existing tooling (modules -> flatpaks/containers/etc.)
>> Both of these have nothing to do with Modularity, and can be done with
>> existing RPMs.
>>
> They have everything to do with Modularity, because that layer is
> where that stuff was implemented. Modularity was the result of the
> efforts involved with Factory 2.0, which gave us a lot of improvements
> in our build infrastructure tooling for the first time since 2007.
> Most of that rolled out in 2017, a full ten years after the last
> revamp of our infrastructure.
>
>>> * Path to provide alternative versions of stacks that don't natively
>>> multiversion (Nodejs, Perl, PHP, etc.)
>> Modularity doesn't support installing multiple versions of the same software.
>> It's one of the key issues with the tech.
>>
> Modules can be designed to be parallel installable if the underlying
> software natively supports that.


I think you are freely interchange "modules" and "module streams". While
modules can indeed parallel installable, the module streams cannot even
if the underlying software natively supports that and even if the RPMs
don't collide.


> For example, Python works that way
> now, and thus in RHEL there are parallel versions of Python shipped as
> modules. It doesn't change the nature of the software.


Having python27 and python36 modules is fail, because these should be
2.7 and 3.6 streams of python module.


Vít


>
> But it makes it easier to make multiple complete, yet conflicting,
> collections of a language stack.
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Bodhi 5.4.0 in production

2020-06-24 Thread Vít Ondruch

Dne 23. 06. 20 v 15:08 Clement Verna napsal(a):
>
>
> On Tue, 23 Jun 2020 at 12:32, Vít Ondruch  <mailto:vondr...@redhat.com>> wrote:
>
>
> Dne 23. 06. 20 v 9:23 Hans de Goede napsal(a):
> > Hi,
> >
> > On 6/22/20 9:53 AM, Clement Verna wrote:
> >> Hi all,
> >>
> >> I have just deployed Bodhi 5.4.0
> >> (https://github.com/fedora-infra/bodhi/releases) in production. We
> >> were running 5.2.2 so that deployment brings the improvement
> and bug
> >> fixes from 5.3.0 and 5.4.0 (see release notes)
> >>
> >> One high level feature worth noting :
> >>
> >> * you can now associate BZ tickets to the automatically created
> >> rawhide updates. The bugs mentioned with the format
> "fix(es)|close(s)
> >> (fedora|epel|rh|rhbz)#BUG_ID"  in the changelog will be
> associated to
> >> the update and automatically closed.
>
>
> It should also support "Resolves":
>
>
> 
> https://github.com/fedora-infra/bodhi/commit/f2f8413ffcb749fff512f226b0bcee9182a969be
>
>
> >> More info
> >>
> 
> https://github.com/fedora-infra/bodhi/blob/develop/docs/user/automatic_updates.rst#associate-bugs-to-automatic-updates
> >
> > I tried using this:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-21cac06005
> >
> > And the bug got associated with the update in bodhi, but the bug
> > did not get closed when the update hit stable ?
>
>
> It does not appear to work:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-08b74be230
>
> The update is not referenced in BZ as the F32 update:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-5dd98b41e7
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1849708#c2
>
>
> Yeah this is similar to Fabio's case and having a ":"  in the string.


Hm, I thought that the `(?:\:)` part of RegExp would accept ":"? But I
might read it wrong.


Vít


>  
>
>
>
>
> Vít
>
>
> >
> > Regards,
> >
> > Hans
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> > To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> <mailto:devel-le...@lists.fedoraproject.org>
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> >
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> <mailto:devel-le...@lists.fedoraproject.org>
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Vít Ondruch

Dne 23. 06. 20 v 14:02 Josh Boyer napsal(a):
> On Tue, Jun 23, 2020 at 7:56 AM Miro Hrončok  wrote:
>> On 23. 06. 20 13:43, Josh Boyer wrote:
>>> On Tue, Jun 23, 2020 at 7:36 AM Miro Hrončok  wrote:
 On 23. 06. 20 13:29, Josh Boyer wrote:
>> (It*may*  be possible to automatize this, but not as easily as with
>> singular packages. And considering that non-modularized packages
>> need to be handled too, there will be at least two paths.)
>>
>> - (hypothetically) if we have default modules in eln, and work is done
>> in those modules and skipping rawhide (for example by not building 
>> the
>> packages in rawhide), we have an unpleasant situation where eln and
>> rawhide diverge.
> This is a very tenuous strawman.  You could also run into a case where
> ELN forbids modules or default module streams and the maintainers
> simply choose not to maintain anything in Fedora at all.  That's far
> worse than divergence in my opinion.
 When ELN was proposed and discussed, separate eln branches were proposed by
 several Fedora and RHEL maintainers. It was dismissed, and it was said
 repeatedly that rawhide/ELN divergence MUST be avoided. I wonder if that
 requirement has changed.
>>> Divergence where?  At the source level?  Why would the existence of a
>>> default module in ELN cause divergence at the source level?  It
>>> wouldn't.  The rawhide sources would be used for the module build in
>>> ELN.
>> I ma concerned about divergence at source level. Modules in Fedora are built
>> from stream branches. Rawhide content is built from the "master" branch. 
>> This is
>> the first time I've heard that rawhide sources would be used for the module
>> build in ELN and it certainly makes the entire thing more appealing. I've
>> already asked about this in:
>>
>> https://pagure.io/fesco/issue/2390#comment-659188
> Hmm.  I have introduced confusion.  My apologies for that, and let me 
> rephrase.
>
> First, I was talking about the sources themselves, not necessarily the
> branches.  If you look at a single package, its source doesn't really
> change when it's built as a stand-alone RPM, or a modular RPM.  It's
> just a package.  Therefore, there isn't divergence at the source
> level.  If the same version of the source is used in rawhide and ELN,
> then I don't see divergence.


This would be true if module was supposed to support only single Fedora
version. If module supports multiple versions, this cannot be further
from reality. And in the context of ELN, this is the later case.


Vít


>
> Secondly, I did not mean to imply there were concrete plans to build
> modules from the rawhide branch in Fedora.  I should have said
> "could", not "would".  However, if that's an approach that makes
> things better in some ways then perhaps it should be looked at in
> earnest as a compromise?
>
> josh
>
>>> If you mean at the binary level, then I have no idea how anyone
>>> possibly thinks ELN and Rawhide are the same because ELN is built with
>>> entirely different flags, settings, etc.
>> No, I don't.
>>
> Fortunately, I think neither are
> actually likely and this part of the conversation seems like it's
> pointless to debate.
 This has happened in the past when Fedora had default modular streams. 
 Whether
 likely or not to repeat, we have experience with the problem, so the 
 discussion
 is not pointless at all.
>>> You seem to be concerned less about divergence and more about
>>> abandonment of packages in Fedora, at least in ways counter to how the
>>> default distribution is built.  You could come up with some guidelines
>>> on usage of ELN modules that require existing content to be maintained
>>> as it is in Fedora if that's what you want to ensure.  It's onerous
>>> and causes extra work, but allows people to do their work in the open.
>>> However, if you prevent that from happening entirely, you run the risk
>>> of them abandoning the packages entirely which is counter to your goal
>>> (I think).
>> I can totally support that. Thanks.
>>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: Fedora Packager Dashboard available for testing

2020-06-24 Thread Vít Ondruch

Dne 24. 06. 20 v 9:31 Josef Skladanka napsal(a):
> On Wed, Jun 24, 2020 at 9:15 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
>> RFE: would it be possible to make the icons in the header clickable
>> (the part where there's the ladybug, zapf, blocks, wrench, etc), so that
>> we'd get redirected to that list of issues (e.g. FTI bugs)?
> It also dawned on me that you might have missed the filtering options
> which are already present - it is a bit more cumbersome for the
> specific use case you presented, but if you click on the little Gear
> icon on the right side of the header, you could use the switches to
> filter out just the bugs/prs/... already


Would it be possible to change the "reset" to something like "set
all/unset all". When I wanted to know what actually "orphaned" means, I
had to click on every option, which is not very convenient.

Also, I am not sure about the "provenpackager" group. Should it be
displayed? Should it do something?

Actually the whole "groups" section is a bit confusing. I am not sure
what the radio buttons do (I am aware about the hints, but they don't
make the situation better understandable to me).


Vít


>
> The RFE you proposed would just do that much faster, though!
>
> Josef
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Bodhi 5.4.0 in production

2020-06-23 Thread Vít Ondruch

Dne 23. 06. 20 v 9:23 Hans de Goede napsal(a):
> Hi,
>
> On 6/22/20 9:53 AM, Clement Verna wrote:
>> Hi all,
>>
>> I have just deployed Bodhi 5.4.0
>> (https://github.com/fedora-infra/bodhi/releases) in production. We
>> were running 5.2.2 so that deployment brings the improvement and bug
>> fixes from 5.3.0 and 5.4.0 (see release notes)
>>
>> One high level feature worth noting :
>>
>> * you can now associate BZ tickets to the automatically created
>> rawhide updates. The bugs mentioned with the format "fix(es)|close(s)
>> (fedora|epel|rh|rhbz)#BUG_ID"  in the changelog will be associated to
>> the update and automatically closed.


It should also support "Resolves":


https://github.com/fedora-infra/bodhi/commit/f2f8413ffcb749fff512f226b0bcee9182a969be


>> More info
>> https://github.com/fedora-infra/bodhi/blob/develop/docs/user/automatic_updates.rst#associate-bugs-to-automatic-updates
>
> I tried using this:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-21cac06005
>
> And the bug got associated with the update in bodhi, but the bug
> did not get closed when the update hit stable ?


It does not appear to work:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-08b74be230

The update is not referenced in BZ as the F32 update:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-5dd98b41e7

https://bugzilla.redhat.com/show_bug.cgi?id=1849708#c2


Vít


>
> Regards,
>
> Hans
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-19 Thread Vít Ondruch

Dne 18. 06. 20 v 21:40 Stephen Gallagher napsal(a):
> On Thu, Jun 18, 2020 at 3:34 PM John M. Harris Jr  
> wrote:
>> The issues I've seen so far affect both Fedora and RHEL, but have gotten a 
>> bit
>> better in Fedora. For example, a major concern that has been much worse in
>> Fedora than RHEL, for obvious reasons:
>>
>> One month you can do a fresh install, install a package that, as it turns 
>> out,
>> is a module for some reason.
>>
>> Then you install a fresh system the next month, install the same package.
>> Perform a dnf update on the previous system, and you'll find that you have a
>> different version of the package installed, because you're tracking a
>> different version of a default stream.
>>
> Can you give an example of where you've seen this? Because our
> policies in Fedora forbid changing a default stream in a released
> Fedora. There were a couple exceptions around Java/Maven and libgit2
> in the past due to their default streams being broken


Sorry, but I don't remember this as "their default streams being
broken". AFAIR, there were multiple applications trying to use different
version of libgit2 at the same time which is not possible. That is
problem of modules design, not problem of the specific default stream as
you put it.


Vít


>  and causing
> issues, but other than those extreme cases, this should never happen
> in a stable release. (On Rawhide, that's a different story and if
> that's what you're describing, that's a known issue and is being
> tracked as part of the upgrade path work.)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2020-06-17 Thread Vít Ondruch

Dne 16. 06. 20 v 14:46 Michael Catanzaro napsal(a):
> On Tue, Jun 16, 2020 at 2:03 pm, Kamil Paral  wrote:
>> The person proposing this Change should supply some video showcasing
>> this, or a very detailed description, otherwise people will have very
>> varying ideas of how this works and looks.
>
> $ sudo dnf install f32-backgrounds-animated
>
> Select the animated background in gnome-control-center and see for
> yourself how it works. :) It's an XML file that describes state
> transitions between static images. Usually only the colors vary,
> transitioning to darker colors at night, lighter colors in the
> morning, standard colors during daytime.


Wasn't the animated background default in RHEL6? If not, then it was
definitely optional.


Vít


>
>
> Fedora has supported this for as long as I remember, we just haven't
> used it by default in a long time. (I think we actually shipped an
> animated background by default once before a while back, though it's
> been long enough that I don't remember that for certain.)
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2020-06-17 Thread Vít Ondruch

Dne 16. 06. 20 v 14:38 Christopher Engelhard napsal(a):
> I can't speak to the implementation of this, but I am in favour of the
> approach in general, with one caveat: I think it is important to
> implement this in a way that makes it possible for users to keep
> *individual* retired packages around. Blacklisting
> fedora-retired-packages is too broad a brush from the user perspective,
> and will make it much harder to identify problems.


Do we have weak obsoletes? :)


Vít


>
> A question regarding this: What would happen if an update to
> fedora-retired-packages obsoletes a package that is present on my system
> but listed in dnf's excludepkgs?
>
> Christopher
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2020-06-17 Thread Vít Ondruch

Dne 17. 06. 20 v 9:15 Till Hofmann napsal(a):
>
> On 6/16/20 9:56 AM, Vít Ondruch wrote:
>> Also, I wonder what is wrong with "dnf autoremove", which is supposed to
>> remove unused leaf packages, which were not explicitly installed?
> On my system, it removed grub2-efi and made the system unbootable. So
> I'm not sure running this as part of the system upgrade would be a good
> idea.
>
> [I'll dig into this and see if I need to file a bug]


Thx, fixing issues like this is what we should aim at. I myself noticed
several times some package like (or maybe precisely this package)
grub2-efi was removed, but my system was always fine after that.

I know that several times, I had to use "dnf mark install" to prevent
some package from being removed, because I knew I want such package. So
there are definitely some gaps, but we should fix them. I am afraid that
neither `fedora-retired-packages` will ask you for not removing some
package.


Vít


>
> Kind regards,
> Till
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package

2020-06-17 Thread Vít Ondruch

Dne 17. 06. 20 v 0:21 Miro Hrončok napsal(a):
> On 16. 06. 20 11:57, Vít Ondruch wrote:
>> Not mentioned that weak dependencies are disabled in Mock.
>
> I don't understand why would the user need fedora-repos-modular
> automatically pulled into mock when they install fedora-repos there.
> Could you please elaborate?
>

Quoting the original email which started this sub-thread:


> Dne 15. 06. 20 v 22:10 Ben Cotton napsal(a):
>> We install/keep fedora-repos-modular by default, users (admins) can
>> uninstall it if desired. No defaults are changed
>
> How you manage to have it installed by default? It is not obvious from
the linked PR to me.
> I just want to be sure it will be installed when @buildsys-build group
is installed. Otherwise some mock builds may fail.
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys



Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package

2020-06-16 Thread Vít Ondruch

Dne 16. 06. 20 v 11:04 Miro Hrončok napsal(a):
> On 16. 06. 20 10:03, Panu Matilainen wrote:
>> Yeah it's a hard dependency of fedora-release-common. I suppose one
>> possibility would be adding a recommends on fedora-repos-modular to
>> fedora-release-common, but weak dependencies have an annoying
>> tendency to creep back in when you're not looking, a kickstart/comps
>> defaults are nicer in that regard.
>
> I was originally thinking that fedora-repos should recommend
> fedora-repos-modular, but due to the annoying nature of getting
> recommends back on every upgrade of the related package I abandoned
> the idea.
>
> Relevant dnf bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=1699672
>

Not mentioned that weak dependencies are disabled in Mock.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2020-06-16 Thread Vít Ondruch
I have sympathy for such proposal, but the implementation does not
respect all the possible corner cases.

1) It does not reflect, that this is not just about retired packages,
but also (or mainly?) about subpackages, which we don't retire.

2) The point (1) is closely related to -debuginfo packages topic [1]
which I re-raised recently with not as much attention as I would like.

Also, I wonder what is wrong with "dnf autoremove", which is supposed to
remove unused leaf packages, which were not explicitly installed?


Vít



[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RBC7I5IQDD7R7CREKYTWLIVY6PZIWOTQ/


Dne 15. 06. 20 v 21:47 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
>
> == Owner ==
> * Name: [[User:msuchy| Miroslav Suchý]]
> * Email: msu...@redhat.com
>
> == Detailed Description ==
> Right now `fedora-obsoletes-package` retires packages which cause an
> issue during an upgrade. We do nothing about all other retired
> packages. Now imagine the following story (it already happened many
> times):
>
> We have package "foo". It is a leaf package. No one requires it. It
> uses just basic libraries.
> A user installs it during F32 lifetime.
>
> Around F35 the upstream dies. Around F37 Fedora maintainer retires the
> package (or orphan and it later become retired).
>
> Because the package is a leaf package, it causes no pain during
> upgrade F37->F38. Not even during upgrade to F39, F40, F41, F42. And
> then during upgrade to F43 it suddenly causes a problem. But because
> it is .fc37 everyone will hesitate to add it
> fedora-obsolete-packages.fc43.
>
> Additionally, during F38-F43, users may expect that their system is
> fully updated and they have no security issues. But it is not true
> about package "foo", which no one maintains. And users are not aware
> of that because he does not follow fedora-devel mailing list.
> Obviously.
>
> What I propose is: As part of the retirement process we add the to
> fedora-retired-packages:
>   Obsoletes: foo < %{latestversion+1}
> And during upgrade from F37->F38 the package will be removed.
>
> If the user wants to preserve the package (e.g., because it moved to
> Copr), he simply uninstalls and protects the installation of
> fedora-retired-packages. But that will be an informed decision.
>
> The benefits are:
>  * we do not leave unmaintained packages on a user's machine.
>  * We make sure that archaic packages do not break upgrade between two
> versions of Fedora.
>
> == Feedback ==
>
> After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
> discussion with fedora-obsolete-package maintainer] I filed this
> Change proposal to include a wider audience.
>
> See relevant 
> [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UTHLSBCLDTFOVEDVQR4XOMNKBJXSHOTF/#Z5D77LVDWWTO7HSP43MYQ7F5MKL6D6TK
> thread on devel mailing list].
>
> == Benefit to Fedora ==
>  * We do not leave unmaintained packages on a user's machine.
>  * We make sure that archaic packages do not break upgrade between two
> versions of Fedora.
>
> == Scope ==
> * Proposal owners:
>
> Create package `fedora-retired-packages` as sub-package of
> `fedora-obsolete-packages`
> [https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
> Edit 
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages
> guidelines with:
>
> The retired package should be obsoleted by one of:
>
>  * fedora-obsoleted-packages - if the package can cause problem during
> upgrade to next version of Fedora
>  * fedora-retired-packages - in all other cases
>
> It is enough to open an issue on
> https://src.fedoraproject.org/rpms/fedora-obsolete-packages
>
> * Other developers:
> No other work should be necessary.
>
> * Release engineering:
> This is optional. I may work with rel-eng to change
> https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_packages.rst
> to automatically create PR for `fedora-obsolete-packages`
>
> * Policies and guidelines: As stated above
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages
> will need an update.
>
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> During an upgrade, all retired packages will be automatically removed.
>
> User may opt-out by:
> 
> $ cat /etc/dnf/dnf.conf
> [main]
> ...
> exclude=fedora-retired-packages
> 
>
>
> == How To Test ==
> 1. Upgrade to next version of Fedora.
> 2. Check all retired packages are removed.
>
> == User Experience ==
>  - Packages that are no longer maintained are removed during a
> distribution upgrade.
>
> == Dependencies ==
> This update has no dependencies on any other package.
>
> == Contingency Plan ==
> * Contingency mechanism: Drop `fedora-retired-package`. Or remove
> `Obsoletes` from this 

Re: [ELN] Opt out python2.7 from ELN

2020-06-10 Thread Vít Ondruch
You should probably open PR modifying this file:

https://github.com/minimization/content-resolver-input/blob/master/configs/view-eln.yaml

But I would expect that somebody else from the ELN provided more prompt
guidance on questions like these ...


Vít


Dne 08. 06. 20 v 16:49 Miro Hrončok napsal(a):
> Hello,
>
> as a maintainer of the python2.7 package I was surprised to see it
> being built for ELN and I like to start a discussion on whether and
> how can I opt out this deprecated package from ELN.
>
> Since there is no tracker or dedicated mailing list, I am following
> the advice given somewhere else on devel, to use this list, possibly
> with the [ELN] marker in subject.
>
> Thanks,
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-packaging] Re: Let's standardize the way to disable tests during RPM build?

2020-06-09 Thread Vít Ondruch

Dne 09. 06. 20 v 13:33 Miro Hrončok napsal(a):
> On 09. 06. 20 12:21, Vít Ondruch wrote:
>> That won't be different for what was the original question here, i.e.
>> conditionally disable tests. bconds are what we have for better or
>> worse.
>>
>> And really, this seems about bootstrapping not disabling tests, which
>> are not completely different, but nobody can objects bootstrapping,
>> while disabling tests might be good just to improve build speed and
>> nothing else. That should never happen in production environment IMO.
>
> FTR the discussion here is about packages that already have a
> bcond/macro to disable tests -- Tomáš proposed a common way of doing
> it. This discussion is not about adding new conditionals to packages
> that don't have them.
>
> Whether or not disabling tests has legitimate use cases is out of
> scope here. It happens. We just want it to be more predictable when
> dealing with packaging in bulk.
>
> As a metaphor (arguably not a very good one), imagine combustion motor
> vehicles. They pollute the environment. We are proposing to introduce
> colored emission stickers.


While we have already some other kind of stickers which could be reused.

The proposal was to optionally disable test. When somebody asked why,
the answer was bootstrapping. But we know how to handle bootstrapping.
So shouldn't somebody spend time changing the test conditionals to
bootstrapping conditionals, because that seems to be the use case?

Or if you have different use case, then you probably want to explain it.


Vít


> You are discussing whether we should have such vehicles at all. While
> such discussion is certainly legitimate, it is out of scope. Sure, if
> we discard all gasoline- and diesel-powered cars and switch to
> electric or bicycles or perpetuum mobile, we don't have to put the
> energy into the emission stickers project. But how likely is that?
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-packaging] Re: Let's standardize the way to disable tests during RPM build?

2020-06-09 Thread Vít Ondruch

Dne 09. 06. 20 v 12:12 Nicolas Mailhot napsal(a):
> Le mardi 09 juin 2020 à 12:08 +0200, Vít Ondruch a écrit :
>> Just FTR, we have bootstrapping guidelines  
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
>>
> Those suffer from
> 1. the horrible bcond logic inversion that trips pretty much everyone
> all the time.


That won't be different for what was the original question here, i.e.
conditionally disable tests. bconds are what we have for better or worse.

And really, this seems about bootstrapping not disabling tests, which
are not completely different, but nobody can objects bootstrapping,
while disabling tests might be good just to improve build speed and
nothing else. That should never happen in production environment IMO.


> 2. the fact you can not ask koji or mock for a bootstrapped build, you
> have to change the spec manually
>

You can set them in modules and I think Koji can set them:

https://pagure.io/koji/issue/416

Not mentioning that there is almost always way to provide some macro
file, e.g. there is no reason for python bootstrapping all the packages
to not ship some macro in `/usr/lib/macros.d/macros.python-bootstrap`.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-packaging] Re: Let's standardize the way to disable tests during RPM build?

2020-06-09 Thread Vít Ondruch

Dne 05. 06. 20 v 17:24 Tomas Orsava napsal(a):
> On 6/5/20 4:46 PM, Richard W.M. Jones wrote:
>> On Fri, Jun 05, 2020 at 04:38:03PM +0200, Miro Hrončok wrote:
>>> On 05. 06. 20 16:26, Richard W.M. Jones wrote:
 On Fri, Jun 05, 2020 at 04:10:20PM +0200, Tomas Orsava wrote:
> Hi,
> I think it would be useful to have a standard way of disabling the
> running of tests during RPM build (in the %check section of a spec
> file).
>
> I see a lot of packages already having %bcond's or other macro
> definitions to archieve this, but each package has their own way,
> there's no real standard. Thus you have to first look into the spec,
> locate the appropriate %bcond or macro name and only then you can
> disable the tests.
>
> I would like to propose two approaches:
>
> (a) Add a *SHOULD* rule to the guidelines that specifies what is the
> preferred way to conditionalize the tests.
>
> (b) Or, if that's too strong, mention in the guidelines the common
> methods that are being used (e.g. %bcond tests and %bcond check) so
> that new packagers have something to use.
 What's the motivation for disabling tests globally?
>>> Bootstrapping mostly.
>> For the RISC-V bootstrap we used rpmbuild directly (before Koji and
>> its dependencies had been ported), and added --nocheck.  However once
>> Koji was working we built packages properly with checks enabled.
>>
>> How often do we bootstrap Fedora from scratch?  Wholly new
>> architectures are rare.  Are there other events that require
>> bootstrapping from scratch?
>
> Not necessarily bootstrapping from scratch, this is useful for
> bootstrapping of anything in Fedora.


Just FTR, we have bootstrapping guidelines:


https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping


Vít



>
> Fod example, Python now releases on a yearly schedule, and
> bootstrapping it is a huge undertaking involving thousands of components.
>
>
> And most importantly, the reason tests are disabled during
> bootstrapping is missing dependencies. Those have to be
> conditionalized by some %bcond or macro, and `--nocheck` doesn't help.
>
> Tomas
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2020-06-05 Thread Vít Ondruch

Dne 05. 06. 20 v 9:52 Kevin Kofler napsal(a):
> Ben Cotton wrote:
>> == Summary ==
>> Fedora has historically forced packages to build with GCC unless the
>> upstream project for the package only supported Clang/LLVM.  This
>> change proposal replaces that policy with one where compiler selection
>> for Fedora follows the package's upstream preferences.
>>
>> == Owner ==
>> * Name: Jeff Law
>> * Email: l...@redhat.com
> I am opposed to this change. Chromium and Firefox build fine with GCC. I 
> think that a distribution should be built with a consistent toolchain 
> wherever possible.
>
> Last I checked, there were several reasons why GCC is preferred over 
> Clang/LLVM in Fedora. And if that should ever change (or have changed 
> already), then switching the systemwide default (reversing the rules, i.e., 
> using GCC only for those packages that do not build with Clang) should be 
> envisioned. But as far as I know, that is not the case at this time, 
> considering runtime performance, security features, etc.
>
> I do not see why we should allow yet another special case for Firefox, nor 
> why we should let random packages make their own choice of compiler and risk 
> running into hidden binary incompatibilities. We have a system compiler for 
> a reason.


Just FTR, there are technical (and security) reasons why we might
consider switching Ruby from GCC to Clang in the future:


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


Vít


> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Adding Obsoletes to generated -debuginfo packages ?

2020-06-04 Thread Vít Ondruch

Dne 04. 06. 20 v 11:25 Igor Raits napsal(a):
> On Thu, 2020-06-04 at 10:56 +0200, Vít Ondruch wrote:
> > Dne 03. 06. 20 v 19:29 Igor Raits napsal(a):
> >> On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote:
> >>> Other possibility is to modify DNF to not touch such packages.
> >>> Not
> >>> sure
> >>> if that would be better. Or is there already some functionality
> >>> which
> >>> would exclude the package from dnf transaction, something like:
> >>
> >>> ~~~
> >>> # This package won't be installed, but will obsolete other
> >>> packages
> >>> Provides: libsolv-self-destruct-pkg()
> >>
> >>> ~~~
> >>
> >>> we use in fedora-obsolete-packages?
> >>
> >> Since they do not block the upgrades, does it really matter?
>
>
> > They block updates. The subpackage -debuginfo requires the main
> > package.
>
> I don't think that it is true anymore, starting with Fedora 27.
> https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
>
> ❯ sudo dnf repoquery --repo=rawhide-debuginfo --requires gnome-shell-
> debuginfo --quiet | wc -l
> 0


gnome-shell is not subpackage but main package.


Try this:


~~~

$ rpm -qpR
https://kojipkgs.fedoraproject.org//packages/ruby/2.7.1/131.fc33/x86_64/ruby-libs-debuginfo-2.7.1-131.fc33.x86_64.rpm
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
ruby-debuginfo(x86-64) = 2.7.1-131.fc33

$ rpm -qpP
https://kojipkgs.fedoraproject.org//packages/ruby/2.7.1/131.fc33/x86_64/ruby-debuginfo-2.7.1-131.fc33.x86_64.rpm
debuginfo(build-id) = 03222f2590f7d7b09b1b7bb6587ece4dc89c84a4
ruby-debuginfo = 2.7.1-131.fc33
ruby-debuginfo(x86-64) = 2.7.1-131.fc33
~~~

If we decided to drop the ruby-libs subpackage for whatever reason, the
ruby-debuginfo would not be possible to update.


Vít


>
> > While there is update for the main package, there is obviously not
> > update for the subpackages. Therefore the subpackage -debuginfo
> > packages
> > will block the upgrade forever. This is the same issue why we have
> > fedora-obsolete-packages. However the difference is that we typically
> > don't care about -debuginfos, because they are magically generated
> > and
> > they are always parallel installable.
>
>
> >> However, I
> >> agree that DNF removing packages that are not present in upgrade
> >> repo
> >> and blocking the upgrade, should be removed automatically.
>
>
> > Actually, the -debuginfo package could be possibly treated as
> > installonly packages. But even install only packages are updated, if
> > I
> > am not mistaken. So it would be probably better if DNF completely
> > ignored them.
>
>
> > Vít
>
>
> >>
> >>
> >>> Vít
> >>
> >>
> >>
> >>> Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a):
> >>>> Because was bitten by this and there is not clear guideline, I
> >>>> have
> >>>> tried to draft something here:
> >>>>
> >>>> https://pagure.io/packaging-committee/pull-request/988
> >>>>
> >>>>
> >>>> Vít
> >>>>
> >>>>
> >>>> Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a):
> >>>>> In libvirt we recently deleted a driver for the legacy Xen
> >>>>> toolstack.
> >>>>>
> >>>>> This was shipped in a libvirt-daemon-driver-xen RPM.
> >>>>>
> >>>>> I am able to add an "Obsoletes: libvirt-daemon-driver-xen <
> >>>>> 4.3.0"
> >>>>> line to the libvirt-daemon-driver-libxl RPM, which gives
> >>>>> clean
> >>>>> upgrade path for users.
> >>>>>
> >>>>> If they have the libvirt-daemon-driver-xen-debuginfo RPM
> >>>>> installed
> >>>>> though that still breaks the upgrade.
> >>>>>
> >>>>> How can I get the auto-generated libvirt-daemon-driver-libxl-
> >>>>> debuginfo
> >>>>> RPM to have an "Obsoletes: libvirt-daemon-driver-xen-
> >>>>> debuginfo <
> >>>>> 4.3.0"
> >>>>> statement ? It seems impossible, meaning users with debuginfo
> >>>>> have a
> >>>>> broken upgrade path. An unfortunate consequence of switchi

Re: Adding Obsoletes to generated -debuginfo packages ?

2020-06-04 Thread Vít Ondruch

Dne 03. 06. 20 v 19:29 Igor Raits napsal(a):
> On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote:
> > Other possibility is to modify DNF to not touch such packages. Not
> > sure
> > if that would be better. Or is there already some functionality which
> > would exclude the package from dnf transaction, something like:
>
> > ~~~
> > # This package won't be installed, but will obsolete other packages
> > Provides: libsolv-self-destruct-pkg()
>
> > ~~~
>
> > we use in fedora-obsolete-packages?
>
> Since they do not block the upgrades, does it really matter?


They block updates. The subpackage -debuginfo requires the main package.
While there is update for the main package, there is obviously not
update for the subpackages. Therefore the subpackage -debuginfo packages
will block the upgrade forever. This is the same issue why we have
fedora-obsolete-packages. However the difference is that we typically
don't care about -debuginfos, because they are magically generated and
they are always parallel installable.


> However, I
> agree that DNF removing packages that are not present in upgrade repo
> and blocking the upgrade, should be removed automatically.


Actually, the -debuginfo package could be possibly treated as
installonly packages. But even install only packages are updated, if I
am not mistaken. So it would be probably better if DNF completely
ignored them.


Vít


>
>
> > Vít
>
>
>
> > Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a):
> >> Because was bitten by this and there is not clear guideline, I have
> >> tried to draft something here:
> >>
> >> https://pagure.io/packaging-committee/pull-request/988
> >>
> >>
> >> Vít
> >>
> >>
> >> Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a):
> >>> In libvirt we recently deleted a driver for the legacy Xen
> >>> toolstack.
> >>>
> >>> This was shipped in a libvirt-daemon-driver-xen RPM.
> >>>
> >>> I am able to add an "Obsoletes: libvirt-daemon-driver-xen <
> >>> 4.3.0"
> >>> line to the libvirt-daemon-driver-libxl RPM, which gives  clean
> >>> upgrade path for users.
> >>>
> >>> If they have the libvirt-daemon-driver-xen-debuginfo RPM
> >>> installed
> >>> though that still breaks the upgrade.
> >>>
> >>> How can I get the auto-generated libvirt-daemon-driver-libxl-
> >>> debuginfo
> >>> RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo <
> >>> 4.3.0"
> >>> statement ? It seems impossible, meaning users with debuginfo
> >>> have a
> >>> broken upgrade path. An unfortunate consequence of switching to
> >>> seprate
> >>> -debuginfo per sub-RPM.
> >>>
> >>> Regards,
> >>> Daniel
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct:
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines:
> >> https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> >>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Adding Obsoletes to generated -debuginfo packages ?

2020-06-03 Thread Vít Ondruch
Other possibility is to modify DNF to not touch such packages. Not sure
if that would be better. Or is there already some functionality which
would exclude the package from dnf transaction, something like:

~~~
# This package won't be installed, but will obsolete other packages
Provides: libsolv-self-destruct-pkg()

~~~

we use in fedora-obsolete-packages?


Vít



Dne 03. 06. 20 v 18:23 Vít Ondruch napsal(a):
> Because was bitten by this and there is not clear guideline, I have
> tried to draft something here:
>
> https://pagure.io/packaging-committee/pull-request/988
>
>
> Vít
>
>
> Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a):
>> In libvirt we recently deleted a driver for the legacy Xen toolstack.
>>
>> This was shipped in a libvirt-daemon-driver-xen RPM.
>>
>> I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0"
>> line to the libvirt-daemon-driver-libxl RPM, which gives  clean
>> upgrade path for users.
>>
>> If they have the libvirt-daemon-driver-xen-debuginfo RPM installed
>> though that still breaks the upgrade.
>>
>> How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo
>> RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0"
>> statement ? It seems impossible, meaning users with debuginfo have a
>> broken upgrade path. An unfortunate consequence of switching to seprate
>> -debuginfo per sub-RPM.
>>
>> Regards,
>> Daniel
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Adding Obsoletes to generated -debuginfo packages ?

2020-06-03 Thread Vít Ondruch
Because was bitten by this and there is not clear guideline, I have
tried to draft something here:

https://pagure.io/packaging-committee/pull-request/988


Vít


Dne 03. 05. 18 v 12:10 Daniel P. Berrangé napsal(a):
> In libvirt we recently deleted a driver for the legacy Xen toolstack.
>
> This was shipped in a libvirt-daemon-driver-xen RPM.
>
> I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0"
> line to the libvirt-daemon-driver-libxl RPM, which gives  clean
> upgrade path for users.
>
> If they have the libvirt-daemon-driver-xen-debuginfo RPM installed
> though that still breaks the upgrade.
>
> How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo
> RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0"
> statement ? It seems impossible, meaning users with debuginfo have a
> broken upgrade path. An unfortunate consequence of switching to seprate
> -debuginfo per sub-RPM.
>
> Regards,
> Daniel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Bodhi: "how to install" is supposed to work?

2020-06-03 Thread Vít Ondruch

Dne 03. 06. 20 v 11:03 Alessio napsal(a):
> On Wed, 2020-06-03 at 10:54 +0200, Vít Ondruch wrote:
>> Dne 02. 06. 20 v 9:32 Alessio napsal(a):
>>> In Bodhi there is a dnf command in the "How to install" section, in
>>> order to install the package to test. Something like:
>>>
>>> sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-
>>> 2020-
>>> 81a3b3df7d
>>>
>>> Is it supposed to work? Because every time I tried it, it didn't
>>> work.
>> Could you please provide more details about "it didn't work". Reading
> It doesn't install anything: "Nothing to do."


If this is the actual message, this should really be updated. If it said
at least something as "advisory FEDORA-
2020-81a3b3df7d was not found in metadata", it would be more helpful. I
think it would be good to open BZ ticket against DNF suggesting this to
improve. Bodhi is trying to be helpful but DNF not at all.


Vít


>
> But as clarified in this thread, it is a mirror propagation issue. Need
> to wait, then it works.
>
>
> A.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Has something changed with RPMS?

2020-06-03 Thread Vít Ondruch

Dne 02. 06. 20 v 19:26 Richard W.M. Jones napsal(a):
> On Tue, Jun 02, 2020 at 12:44:17PM +0200, Florian Weimer wrote:
>> * Panu Matilainen:
>>
>>> Lets start with the basics:
>>> - is sqlite even involved - it will only be used on rawhide builds if
>>> mock bootstrap is used
>>> - does it make a difference if you override _db_backend to bdb/sqlite
>>> from mock config / cli define
>>> - a reproducer please (eg, what package is considerably slower to
>>> build than before, and by how much)
>> And: Does the difference reproduce when building on tmpfs?
> Good time to say that you can use an NBD loopback to mock-build either
> on a userspace ramdisk or backed by a disk but discarding flush
> requests.  The performance is indistinguishable from tmpfs (and much
> more flexible in other ways).  I did some benchmarking a couple of
> weeks ago:
>
>   https://www.redhat.com/archives/libguestfs/2020-May/msg00053.html
>   https://www.redhat.com/archives/libguestfs/2020-May/msg00074.html
>
> Easy set up is:
>
>   # rm -f /tmp/sock
>   # nbdkit -U /tmp/sock memory 100G
>   # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 4
>   # mkfs.xfs /dev/nbd0
>   # mount /dev/nbd0 /var/lib/mock
>
> or using http://libguestfs.org/nbdkit-tmpdisk-plugin.1.html:
>
>   # rm -f /tmp/sock
>   # nbdkit -U /tmp/sock tmpdisk size=100G
>   # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 1
>   # mount /dev/nbd0 /var/lib/mock
>
> or (requires bleeding edge nbdkit):
>
>   # rm -f /tmp/sock
>   # lvcreate -L 100G -n tmp /dev/fedora
>   # nbdkit -U /tmp/socket --filter=fua fuamode=discard file /dev/fedora/tmp
>   # nbd-client -b 512 -unix /tmp/sock /dev/nbd0 -connections 4
>   # mkfs.xfs /dev/nbd0
>   # mount /dev/nbd0 /var/lib/mock
>
> Rich.
>

NBD kit is definitely interesting piece of technology, but I think there
is missing quite a bit to be as easy as you say and there is definitely
a lot of missing information, e.g. does the setup persist reboots? It
would be probably more interesting, if it was mock plugin the same way
tmpfs or lvm plugins are.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Bodhi: "how to install" is supposed to work?

2020-06-03 Thread Vít Ondruch

Dne 02. 06. 20 v 9:32 Alessio napsal(a):
> In Bodhi there is a dnf command in the "How to install" section, in
> order to install the package to test. Something like:
>
> sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-
> 81a3b3df7d
>
> Is it supposed to work? Because every time I tried it, it didn't work.


Could you please provide more details about "it didn't work". Reading
the rest of the thread, there were some valuable suggestions how to
improve Bodhi, but shouldn't we improve DNF instead? E.g. if there is
`--advisory` option specified on command line, it would provide the message:

~~~

"It takes some time to distribute updates. If the above command does
not install anything, please try again later. It should normally not
take longer than _."

~~~

already suggested in other parts of this thread. Also DNF could be smart
enough to compare the state of Bodhi and mirrors (but I am not sure if
the `FEDORA-2020-81a3b3df7d` metadata are part of the repo or if the
Bodhi is already queried for them or not).


Vít


> In addition a package received a negative karma due to that ^_^;
>
> Ciao,
> A.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Upcoming fedoraproject Datacenter move reminder and plans

2020-06-03 Thread Vít Ondruch
Just wonder, will there be any convenient way to remind me that the
service is down for a reason? E.g. redirect to status page. It would be
probably harder for all the CLI utilities we are using, but maybe
something which should be addressed as well.


Vít


Dne 02. 06. 20 v 18:40 Kevin Fenzi napsal(a):
> Greetings.
>
> As previously announced, fedoraproject is moving many of it's servers
> from one datacenter (phx2 near phoenix, arizona, usa) to another (iad2:
> near arlington, virginia, usa).
>
> As we move from the old datacenter to the new, we will have a temporary
> reduction in capacity. The new datacenter has a smaller, less-redundant,
> lower-capacity version of our infrastructure. Over the next two weeks,
> we will migrate services to it so that we can finish moving out of the
> old datacenter.
>
> After everything is moved from the old datacenter, many of the servers
> there will be shipped to the new datacenter and then re-added to bring
> us back to full redundency and capacity. 
>
> Out detailed checklist for these migrations is available at
> https://hackmd.io/@fedorainfra2020/rJpsA4FLL
>
> To summarize what we are moving when: 
>
> 2020-06-03 wed: The fedoraproject master mirrors will move to IAD2. A
> very small outage may be noticed as dns changes. There may be some
> mirroring slowdowns as we work out bugs.
>
> 2020-06-04 thu: Our internal ansible control host and the fedoraproject
> wiki will move. The wiki will be down for a few hours.
>
> 2020-06-05 fri: Our meeting minutes archive
> (https://meetbot.fedoraproject.org) and our freenode irc bot (zodbot).
> These two services will see a hour outage or less.
>
> 2020-06-07 sun: We will pause for the next week adding new packages and
> unretiring packages to avoid problems. 
>
> 2020-06-08 mon: Our fedora-messaging bus and gateways to it
> (github2fedmsg, bugzilla2fedmsg), mirrormanager, product definition
> center (pdc), and our identity and authentication systems. Messages over our
> message bus may be slow or missing and users may be unable to login at
> various times as we migrate services over. 
>
> Additionally, we will be stopping services that will not be back until
> later in the month. 
> These include: 
>  * Fedocal
>  * Badges
>  * Nuancier
>  * koschei
>  * simple-koji-ci
>  * All staging services (*.stg.fedoraproject.org)
>
> 2020-06-09 tue: The build and packaging ecosystem. This includes koji,
> src.fedoraproject.org, osbs, odcs, container registries, bodhi (updates
> system). During this day maintainers should avoid builds/updates if at
> all possible as they may or may not work at various times. 
>
> 2020-06-10 wed: Various small apps (mdapi, anitya, waiverdb, greenwave,
> etc), mailman/lists.fedoraproject.org, and our datagrepper/datanommer
> services. Mailing lists will be down for several hours as data is
> migrated. Datagrepper will be down for most of the day as it's database
> is moved. Other services will be down for short amounts of time while
> they are moved.
>
> 2020-06-11 thu: Various small site building apps (docs building, fedora
> websites building, reviewstats, blockerbugs) and elections will be
> moved. elections will be up until the currently running elections
> complete. (GO VOTE! https://elections.fedoraproject.org)
>
> 2020-06-12 fri: Catch up and fix issues day, along with re-enabling
> package unretirements/new packages, and other 'paused' items.
>
> The week after this servers will be shipped and the week after that we
> expect to start setting them up and getting them re-added. During this
> time, we may have to make further changes to what services are available
> in order to deal with load changes. 
>
> If you have any questions or concerns, please file an infrastructure
> ticket ( https://pagure.io/fedora-infrastructure) or come talk to us in
> #fedora-admin on irc.freenode.net. 
>
> Finally, I'd like to ask everyone to be patient as we do this move. I
> know that it's painful when you are unable to contibute something when
> you have time to do so, but rest assured that we are trying to migrate
> things as quickly and smoothly as we can.
>
> Thanks.
>
> kevin
>
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> 

Orphaning invokebinder + coro-mock

2020-06-02 Thread Vít Ondruch
Hi,

Since JRuby was retired, I am orphaning invokebinder and coro-mock,
which used to be dependencies of JRuby. I don't think anything else
depends on them. Also, they were not touched in several years.


VĂ­t
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 price of FHS

2020-05-23 Thread Vít Ondruch
It would be possible to install individual RPMs into paths such as:

~~~

/pkgs/programA_version1
/pkgs/libX_version1 contains

~~~

but I wonder how would you imagine the glue above this structure to make
the programA_version1 to use the libX_version1?


Vít


Dne 22. 05. 20 v 21:50 Paul Dufresne via devel napsal(a):
> The File Hierarchy Standard (FHS), is a standard that define where the
> files of a package should be placed in the root directory of the
> systems. It probably did not change much since the beginning of Unix,
> and it make files be placed where users, developers and administrators
> expect them to be.
>
> The main disadvantage of it, is making hard to have multiple active
> versions of a package, because the likelihood of the multiple
> versions, to have the same preferred place in the hierarchy for some
> files.
>
> On other way of seeing this disadvantage, is the fact that in a system
> using FHS, new versions of packages often break other programs...
> because using FHS force you to erase the old package to put a new one
> in it's place... so that programs that were dependent on the old
> version cannot use the old version because it is not there anymore.
>
> You probably only realize all this, when you use a distribution like
> NixOS, that have let FHS go away, to make every binary package to be
> in their own directory. This solve the problem of multiple active
> versions of a package, and allows different packages to depend on
> different versions of a package. This also allows normal users to
> install package, just for them... or shared if many users install the
> same version of a program.
>
> Well... I was not so happy with NixOS. In part because binary packages
> are considered, a cache version of a built packages. In the past,
> often the binary cache was not having the built version of a package,
> and it had to build it from sources... which is long, especially if
> you have an older computer. I am unsure why this seems to be less
> problematic now than in the past.
>
> The other problem I had with NixOS, was the strange Nix syntax of
> packages. That I did not seems to get it. Now... with time, the more I
> am exposed to it, the less it seems strange. Still, I wanted a more
> traditional Linux distribution. I had thought that the fact that
> Fedora support modules, that it could be a bit like NixOS. Only
> recently, when someone suggested that we could use modules to have
> different versions of Python, avoiding the problem of new versions
> breaking old versions, did I really realized that Fedora modules does
> not allow multiple active versions of a module to be installed at the
> same time... so that Fedora modules does not help much with the
> problem of new packages needing to replace older versions, so breaking
> packages that were dependent on old versions.
>
> To be clear, the fact to be able to have multiple versions does not
> means that NixOS have many different versions for each packages. For
> some reasons, they try as much as possible to keep just one version of
> each package... but while upgrading... they may keep the older version
> a while. This reduce friction with other packages.
>
> Now like I said, Nix use a very different syntax and tools for
> defining packages. But I don't think you have to adopt it to have most
> of the advantages of Nix. And I believe it would be possible to keep
> the current use of .spec files in such a way of doing things.
>
> That said, I realize that what I am proposing, is more like a fork of
> Fedora, than a proposed change, as letting FHS is such a big change.
> And I am, sadly, not really suggesting that I want to begin such a
> endeavor. For me, it probably means I will begin to move to using more
> NixOS than Fedora. But I had the feeling that it could be useful for
> Fedora, to realize, and evaluate the price they pay for using the File
> Hierarchy Standard.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: FTBFS bug not reassigned

2020-05-18 Thread Vít Ondruch

Dne 17. 05. 20 v 1:25 Benjamin Lowry napsal(a):
> I recently adopted flatbuffers, which was orphaned due to an open FTBFS
> in F32 [1]. I've fixed the spec, rebuilt, and made an update in bodhi,
> but I'm unable to close the FTBFS bug because it hasn't been reassigned
> to me. What should I do? Am I supposed to be able to edit this bug? I'm
> in the editbugs group... -ben
>
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1799345


I have assigned the bug to you. I hope it helps and it won't postpone
fix of the root cause of this issue.


Vít





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orhpaning rubygem-inflecto

2020-05-15 Thread Vít Ondruch
This package is deprecated upstream, nothing depends on it and I have no
use for it, therefore I orphaning the package.


VĂ­t

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Re-Launching the Java SIG

2020-05-14 Thread Vít Ondruch

Dne 14. 05. 20 v 11:53 Michal Srb napsal(a):
> Hello,
>
> On Tue, May 12, 2020 at 12:57 PM Felix Schwarz
> mailto:fschw...@fedoraproject.org>> wrote:
>
>
> Am 12.05.20 um 12:32 schrieb Ty Young:
> > Right, I figured it was some Fedora policy and not up to you. I
> suppose I
> > should have been more clear there. Sorry for any confusion, it
> was aimed at
> > the Fedora project as a whole as this is a Fedora issue.
>
> This is not a Fedora issue but a consequence of Fedora's core
> values. You not
> agree with it but "building from source" is so fundamental that it
> does not
> make sense to even start a discussion about it on fedora-devel.
>
> I suggest you read up on the rationale behind that policy (which
> is why I
> linked the policy document in the first place).
>
>
> I agree that building from sources is the right thing to do. However,
> let me play devil's advocate here :)
>
> What makes Java apps different from other language ecosystems is that
> Java apps never share dependencies. There is no concept of
> "system-wide" 3rd-party Java libraries that would be automatically
> added to classpath when JVM starts.


And now how is this different to different language ecosystems? All
languages I have ever worked with has this attitude, more or less. The
Linux distributions are fighting against this but with various success.
With Java, Fedora is failing ATM.

And if the bundling is not happening on language level, then we are back
to bundling in containers and flatpacks and what not.


Vít


> I realize that this is technically possible to achieve, but that is
> not how people use it. If you want to distribute your Java app, you
> just bundle it with all its dependencies into a beefy tarball and ship it.
> And if Java apps never share dependencies, then developers are not
> really forced to keep up with latest versions of libraries. Nobody can
> update the non-existent system-wide Java library that would break
> their application. They are in control.
>
> Since there is no standard place for shared Java libraries on your
> laptop, how can you use the packaged Java libraries and develop
> software against them? Sure, you can hack it and make it work on your
> Fedora 32 machine, but your custom Makefile is not guaranteed to work
> on Fedora 31 or later on 33. And your colleague that is on CentOS is
> out of luck of course. And so are all your potential external
> contributors on their MacBooks and Ubuntus.
> What I am trying to say in this paragraph is that shipping (in RPMs)
> and maintaining individual build-only Java libraries is, at least in
> my opinion, questionable.
>
> Fedora and other linux distributions are trying to do the right thing,
> but things like Java apps simply don't fit in. What Java app
> developers are doing may not be the best thing, but it's been like
> that for ~20 years, and it seems to be "good enough" for the majority
> of people involved (well, developers at least).
> Fedora alone is too insignificant to change it I am afraid.
>
> However, with all that being said. I do like "dnf install my-java-app"
> better than unpacking some tarballs somewhere.
>
> And finally, here comes the "devil's advocate" part of my email.
>
> * building Java libraries and apps from sources?
>   * +1, no doubt about this
> * building Java libraries and apps from sources in a controlled and
> reproducible environment?
>   * yes, please
> * building Java libraries and apps from sources from SRPMs?
>   * do we really need the RPM overhead here?
> * shipping (in RPMs) and maintaining Java libraries that are not
> runtime dependencies of Java applications that we want to have in Fedora?
>   * nope, why? build such build-only dependencies from sources, make
> sure they are OK license-wise, but do not ship them to users (as
> explained above, they are not very useful for developers anyway)
>
> We can do license reviews, we can build from sources, but we don't
> necessarily have to do all this in RPMs.
> We can do all the right things, store (our binary) results in a
> language-native way, which would be a Maven repository controlled by
> Fedora in this case, and then simply wrap our good binary JARs into
> RPMs, without rebuilding them all the time.
>
> Note having such language-native repository full of good and reviewed
> Java libraries would mean that developers that care about such things
> could actually start using it instead of the official Maven
> repository. And they wouldn't be tied to a specific version of Fedora
> or Linux.
>
> I don't think this would go against the current packaging policy, it
> just would be *a ton" of work :)
>
> This email turned out to be way longer than I expected it to be, but
> Java packaging is a complicated topic.
>
> Thanks,
> Michal
>  
>
>
> I understand that missing components/features due to the source
> requirement
> are annoying but Fedora (and other distros) decided to take the
> "high 

Re: Proposal: Revise FESCo voting policy

2020-05-13 Thread Vít Ondruch

Dne 13. 05. 20 v 15:08 Miro Hrončok napsal(a):
> On 13. 05. 20 14:45, Vít Ondruch wrote:
>
>> But then everybody felt strong that it is not possible, because if there
>> was not official body approving this, that could be end of the world. So
>> now, when we have that body, it gives blank approvals, because the
>> members of the body cannot get themselves educated about the
>> problematic? Can somebody explain me what is the reason for the process
>> then?
>
> Unfortunately, I don't full-time working week to dedicate to FESCo to
> reasonable educate myself on *all* proposed changes and sometimes, I
> decide to abstain. Does this mean I am disqualified of being a good
> FESCo member?


I understand. And luckily it doesn't regularly that FESCo is not
decisive. But when it happens, then there should probably happen some
kind of selfreflection. I think that it is enough if one of the
abstainers take the time to get deeper understanding. It might be also
fault of the proposal which is not clear enough to give enough insights.

The "Revise FESCo voting policy" kind of selfreflection is unexpected.


>
>
>> My proposal is that FESCo should put their stuff together and provide
>> reasonable ruling or it should completely dissolve, because it proves
>> itself useless. There are no reasons for the committee to gather
>> together just to provide rubber stamps to changes.
>
> It reads a bit harsh to call all the time I actually do spend on FESCo
> stuff useless :(
>

Sorry, I exaggerated the proposal and I didn't want to offend anybody.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Proposal: Revise FESCo voting policy

2020-05-13 Thread Vít Ondruch

Dne 12. 05. 20 v 14:22 Aleksandra Fedorova napsal(a):
> Hi,
>
> On Tue, May 12, 2020 at 10:19 AM Vít Ondruch  wrote:
>>
>> Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
>>> Hi,
>>>
>>> On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher  
>>> wrote:
>>>> During today's FESCo meeting, we encountered an unusual voting
>>>> situation for the first time: Four FESCo members voted in favor (+1)
>>>> of a measure and five FESCo members opted to abstain (0) for various
>>>> reasons. However, the FESCo voting policy currently reads: "A majority
>>>> of the committee (that is, five out of nine) is required to pass a
>>>> proposal in a meeting." As a result, we were actually at an impasse
>>>> until two of the FESCo members opted to change their votes to +1 to
>>>> resolve the confusion.
>>>>
>>>> It was subsequently suggested that we revise the policy to avoid this
>>>> pitfall in the future. I volunteered to put together a proposal for
>>>> how this could work and send it to the Fedora Development list for
>>>> discussion. I propose the following changes to the FESCo voting
>>>> policy:
>>>>
>>>> * To pass any measure, a majority — defined as the greater of half the
>>>> eligible votes (rounded up) — must vote in favor of the measure. The
>>>> standard set of eligible votes is one vote per FESCo member. No
>>>> measure may pass without at least one vote in favor.
>>>>
>>>> * Abstaining from a vote (aka "voting 0") is considered to have
>>>> removed that FESCo member's vote from the set of eligible votes. This
>>>> must be done explicitly and is never to be assumed from lack of
>>>> communication.
>>>>
>>>> A practical effect of the new abstention rule is that if two FESCo
>>>> members abstain, the measure would then require only a +4 vote to
>>>> pass. (A single abstention would still require a +5 vote).
>>> I don't like this idea.
>>>
>>> I think if FESCo members don't have enough data or understanding to
>>> vote on the topic, this means that FESCo needs to put more effort in
>>> it.
>>>
>>> Find some subject matter experts in the community, make additional
>>> steps to learn the subject.
>>> Or, when topic has no technical foundation but more of the personal
>>> preference, bring it for a full community vote.
>>>
>>> In the end FESCo supposed to channel the community voice.
>>> If FESCo can not make a decision, it means delegation of the decision
>>> to FESCo by community failed. So let's go back to community?
>>>
>>> So how about the alternative:
>>> if FESCo can't come up with the decision, it announces the stalled
>>> decision to fedora-announce and requests help. Better summary, more
>>> arguments, etc..
>>>
>>> This would encourage people who are against the change to participate.
>>
>> I agree with Aleksandra up until here.
>>
>>
>>> And if there are no such people to provide convincing arguments
>>> against the change in a reasonable time frame, than FESCo decides in
>>> favor of the submitter.
>>
>> I disagree here. If such proposal does not have enough support, then it
>> should not be accepted and should be revisited/abandoned/rejected. I
>> cannot imagine any even hypothetical situation where the opposite was
>> beneficial.
> The proposal has at least support of its owners, who stepped in and
> spent some time describing the idea.
>
> If there are no convincing reasons against this proposal, then it is
> their opinion, which matters. They have an idea, and they are willing
> to do the job and take the responsibility.
> I don't see the reason to block it then.


When the change process was established, I always proposed that the
change should be always pre-approved by default. The changes would be
judged by the amount of feedback received on ML after their
announcement. If somebody had strong concerns, it would be possible to
bring this change to be judged by FESCo.

But then everybody felt strong that it is not possible, because if there
was not official body approving this, that could be end of the world. So
now, when we have that body, it gives blank approvals, because the
members of the body cannot get themselves educated about the
problematic? Can somebody explain me what is the reason for the process
then?

My proposal is that FESCo should put their stuff together and provide
reasonable rulin

Re: Retired packages with maintainers

2020-05-12 Thread Vít Ondruch

Dne 12. 05. 20 v 20:26 Vít Ondruch napsal(a):
> Dne 12. 05. 20 v 14:51 Miro Hrončok napsal(a):
>> On 12. 05. 20 8:49, Pierre-Yves Chibon wrote:
>>> Finally, does everyone agree about the original request: "remove all
>>> maintainers
>>> of retired packages"? Or should we bring this to FESCo?
>> If the procedure is "remove all maintainers if all branches are
>> retired or EOL" than yes, this is a good thing. However, not sure if
>> worth spending energy on. What are the benefits over status quo?
>>
> For example to be able to see if some packager is active or not? Why the
> Pagure user page [1] should show that somebody maintains some package
> while it is actually not true? In this specific case, there are listed 4
> EOL packages.

Forget to mention, that this page is overview also for myself, if I
should something let go.

And also, since we have lost the ability to manage user privileges per
branch, it is not possible to retire package and remove yourself from
it, because then it would not be possible to maintain the stable
branches. There should be other mechanism to remove the maintainers once
the last branch gets EOL, but there is non AFAIK.


Vít


>
> If you think it is not worth spending the time to provide the correct
> information, then maybe this whole page should be removed from Pagure,
> because it has no value ATM.
>
>
>
> [1] https://src.fedoraproject.org/user/skottler/projects
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Retired packages with maintainers

2020-05-12 Thread Vít Ondruch

Dne 12. 05. 20 v 14:51 Miro Hrončok napsal(a):
> On 12. 05. 20 8:49, Pierre-Yves Chibon wrote:
>> Finally, does everyone agree about the original request: "remove all
>> maintainers
>> of retired packages"? Or should we bring this to FESCo?
>
> If the procedure is "remove all maintainers if all branches are
> retired or EOL" than yes, this is a good thing. However, not sure if
> worth spending energy on. What are the benefits over status quo?
>

For example to be able to see if some packager is active or not? Why the
Pagure user page [1] should show that somebody maintains some package
while it is actually not true? In this specific case, there are listed 4
EOL packages.

If you think it is not worth spending the time to provide the correct
information, then maybe this whole page should be removed from Pagure,
because it has no value ATM.



[1] https://src.fedoraproject.org/user/skottler/projects

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Proposal: Revise FESCo voting policy

2020-05-12 Thread Vít Ondruch

Dne 12. 05. 20 v 10:18 Vít Ondruch napsal(a):
> Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
>> Hi,
>>
>> On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher  
>> wrote:
>>> During today's FESCo meeting, we encountered an unusual voting
>>> situation for the first time: Four FESCo members voted in favor (+1)
>>> of a measure and five FESCo members opted to abstain (0) for various
>>> reasons. However, the FESCo voting policy currently reads: "A majority
>>> of the committee (that is, five out of nine) is required to pass a
>>> proposal in a meeting." As a result, we were actually at an impasse
>>> until two of the FESCo members opted to change their votes to +1 to
>>> resolve the confusion.
>>>
>>> It was subsequently suggested that we revise the policy to avoid this
>>> pitfall in the future. I volunteered to put together a proposal for
>>> how this could work and send it to the Fedora Development list for
>>> discussion. I propose the following changes to the FESCo voting
>>> policy:
>>>
>>> * To pass any measure, a majority — defined as the greater of half the
>>> eligible votes (rounded up) — must vote in favor of the measure. The
>>> standard set of eligible votes is one vote per FESCo member. No
>>> measure may pass without at least one vote in favor.
>>>
>>> * Abstaining from a vote (aka "voting 0") is considered to have
>>> removed that FESCo member's vote from the set of eligible votes. This
>>> must be done explicitly and is never to be assumed from lack of
>>> communication.
>>>
>>> A practical effect of the new abstention rule is that if two FESCo
>>> members abstain, the measure would then require only a +4 vote to
>>> pass. (A single abstention would still require a +5 vote).
>> I don't like this idea.
>>
>> I think if FESCo members don't have enough data or understanding to
>> vote on the topic, this means that FESCo needs to put more effort in
>> it.
>>
>> Find some subject matter experts in the community, make additional
>> steps to learn the subject.
>> Or, when topic has no technical foundation but more of the personal
>> preference, bring it for a full community vote.
>>
>> In the end FESCo supposed to channel the community voice.
>> If FESCo can not make a decision, it means delegation of the decision
>> to FESCo by community failed. So let's go back to community?
>>
>> So how about the alternative:
>> if FESCo can't come up with the decision, it announces the stalled
>> decision to fedora-announce and requests help.


Actually, it should be also useful if position of each abstaining FESCo
member was explained. Because for myself, I can interpret 5 people
abstaining just as a lack of understanding of the issue and nothing else.


Vít


>>  Better summary, more
>> arguments, etc..
>>
>> This would encourage people who are against the change to participate.
>
> I agree with Aleksandra up until here.
>
>
>> And if there are no such people to provide convincing arguments
>> against the change in a reasonable time frame, than FESCo decides in
>> favor of the submitter.
>
> I disagree here. If such proposal does not have enough support, then it
> should not be accepted and should be revisited/abandoned/rejected. I
> cannot imagine any even hypothetical situation where the opposite was
> beneficial.
>
>
> Vít
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Proposal: Revise FESCo voting policy

2020-05-12 Thread Vít Ondruch

Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
> Hi,
>
> On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher  wrote:
>> During today's FESCo meeting, we encountered an unusual voting
>> situation for the first time: Four FESCo members voted in favor (+1)
>> of a measure and five FESCo members opted to abstain (0) for various
>> reasons. However, the FESCo voting policy currently reads: "A majority
>> of the committee (that is, five out of nine) is required to pass a
>> proposal in a meeting." As a result, we were actually at an impasse
>> until two of the FESCo members opted to change their votes to +1 to
>> resolve the confusion.
>>
>> It was subsequently suggested that we revise the policy to avoid this
>> pitfall in the future. I volunteered to put together a proposal for
>> how this could work and send it to the Fedora Development list for
>> discussion. I propose the following changes to the FESCo voting
>> policy:
>>
>> * To pass any measure, a majority — defined as the greater of half the
>> eligible votes (rounded up) — must vote in favor of the measure. The
>> standard set of eligible votes is one vote per FESCo member. No
>> measure may pass without at least one vote in favor.
>>
>> * Abstaining from a vote (aka "voting 0") is considered to have
>> removed that FESCo member's vote from the set of eligible votes. This
>> must be done explicitly and is never to be assumed from lack of
>> communication.
>>
>> A practical effect of the new abstention rule is that if two FESCo
>> members abstain, the measure would then require only a +4 vote to
>> pass. (A single abstention would still require a +5 vote).
> I don't like this idea.
>
> I think if FESCo members don't have enough data or understanding to
> vote on the topic, this means that FESCo needs to put more effort in
> it.
>
> Find some subject matter experts in the community, make additional
> steps to learn the subject.
> Or, when topic has no technical foundation but more of the personal
> preference, bring it for a full community vote.
>
> In the end FESCo supposed to channel the community voice.
> If FESCo can not make a decision, it means delegation of the decision
> to FESCo by community failed. So let's go back to community?
>
> So how about the alternative:
> if FESCo can't come up with the decision, it announces the stalled
> decision to fedora-announce and requests help. Better summary, more
> arguments, etc..
>
> This would encourage people who are against the change to participate.


I agree with Aleksandra up until here.


> And if there are no such people to provide convincing arguments
> against the change in a reasonable time frame, than FESCo decides in
> favor of the submitter.


I disagree here. If such proposal does not have enough support, then it
should not be accepted and should be revisited/abandoned/rejected. I
cannot imagine any even hypothetical situation where the opposite was
beneficial.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-07 Thread Vít Ondruch

Dne 06. 05. 20 v 20:39 clime napsal(a):
> On Wed, 6 May 2020 at 13:21, Fabio Valentini  wrote:
>> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch  wrote:
>>>
>>> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
>>>> On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek  wrote:
>>>>
>>>> Hi Tomas,
>>>>
>>>> I'll respond below with some of my experiences and opinions ...
>>>>
>>>>> Let’s talk about dist-git, as a place where we work. For us,
>>>>> packagers, it’s a well-known place. Yet for newcomers, it may take a
>>>>> while to learn all the details. Even though we operate with projects
>>>>> in a dist-git repository, the layout doesn’t resemble the respective
>>>>> upstream project.
>>>>>
>>>>> There is a multitude of tasks we tend to perform in a dist-git repo:
>>>>> * Bumping a release field for sake of a rebuild.
>>>>> * Updating to the latest upstream release.
>>>>> * Resolving CVEs.
>>>>> * Fixing bugs by…
>>>>>   * Changing a spec file.
>>>>>   * Pulling a commit from upstream.
>>>>>   * Or even backporting a commit.
>>>>> * And more...
>>>>>
>>>>> For some tasks, the workflow is just fine and pretty straightforward.
>>>>> But for the other, it’s very gruesome - the moment you need to touch
>>>>> patch files, the horror comes in. The fact that we operate with patch
>>>>> files, in a git repository, is just mind-boggling to me.
>>>>>
>>>>> Luckily, we have tooling which supports the repository layout -
>>>>> `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can
>>>>> easily inspect the source tree or make sure your local change builds.
>>>>>
>>>>> Where am I getting with this?
>>>>>
>>>>> Over the years there have been multiple tools created to improve the
>>>>> development experience:
>>>>> rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
>>>>> the way Fedora kernel developers work on kernel [k]).
>>>> (snip)
>>>>
>>>>> In the packit project, we work in source-git repositories. These are
>>>>> pretty much upstream repositories combined with Fedora downstream
>>>>> packaging files. An example: I recently added a project called nyancat
>>>>> [n] to Fedora. I have worked [w] on packaging the project in the
>>>>> GitHub repo and then just pushed the changes to dist-git using packit
>>>>> tooling. These source-git repositories can live anywhere: we have
>>>>> support for GitHub right now and are working on supporting pagure.
>>>>>
>>>>> Would there be an interest within the community, as opt-in, to have
>>>>> such source-git repositories created for respective dist-git
>>>>> repositories? The idea is that you would work in the source-git repo
>>>>> and then let packit handle synchronization with a respective dist-git
>>>>> repo. Our aim is to provide the contribution experience you have in
>>>>> GitHub when working on your packages. Dist-git would still be the
>>>>> authoritative source and a place where official builds are done - the
>>>>> source-git repo would work as a way to collaborate. We also don’t have
>>>>> plans right now to integrate packit into fedpkg.
>>>> So, in my experience, source-git might be a workable solution for
>>>> packages with *big* downstream modifications. However, for everything
>>>> else, I think it's a way to make it easy to accrue technical debt and
>>>> to do cargo-culting with downstream patches.
>>>>
>>>> The vast majority of packages has *no patches* (or at most, one or two
>>>> of them)
>> (snip)
>>
>>> I don't really want to argue with this point, I tend to agree. Just out
>>> of interest, do we have some statistics to support this? O:-)
>> I did not have any stats when I wrote this, but now I do.
>> Parsing the rawhide spec files from [0] for lines matching
>> "^Patch[0-9]*:[ \t]*.*$", I get the following distribution:
>>
>> number of patches: number of packages
>> total: 21970
>> 0: 15638
>> 1: 3287
>> 2: 1232
>> 3: 598
>> 4: 325
>> 5: 221
>> 6: 154
>> 7: 97
>> 8: 83
>> 9: 57
>> 10:

Re: Is dist-git a good place for work?

2020-05-06 Thread Vít Ondruch

Dne 06. 05. 20 v 16:15 Robbie Harwood napsal(a):
> Vít Ondruch  writes:
>
>> Dne 05. 05. 20 v 21:26 Robbie Harwood napsal(a):
>>> Tomas Tomecek  writes:
>>>
>>>> Thank you all for raising all the questions and concerns.
>>>>
>>>> Before I reply, I'd like to stress that we are still in a prototype
>>>> phase - not everything is solved (clearly) and at this point, we
>>>> experiment with the workflow mostly.
>>>>
>>>> Luckily, force-pushes are not allowed in dist-git,
>>> That's a "current state of affairs" statement, not an ideal, as I
>>> understand it.  Assuming that force-pushes aren't allowed means we'll
>>> never be able to have, e.g., non-distro branches (for testing etc.)
>>> that we can force push.
>>>
>>> This has been a pain point with RHEL dist-git; among other things, it
>>> means that branches can't be deleted.
>> That this is problem only when you cannot use PRs. If you can use PRs,
>> pushing some random branches into remote git repo is the biggest sin
>> IMO, because while you might delete the branch in remote repo once it
>> is not needed, I have this branch very likely pulled to my repo and
>> the amount of branches in my local repo I have no clue about just
>> rises. So if deleting branches was a point of RHEL dist-git, then this
>> is sad news for me. Pushing branches was probably useful in CVS days,
>> but that should not be the case anymore.
> Well, your workflow is not my workflow.


Probably. But applying CVS workflow to Git workflow with PR is probably
not the best idea.


>
> I very often have to ship test builds (bugfixes, new features,
> compatibility testing, ...).  Yes, the build itself goes in COPR most of
> the time (or scratch on brewkoji), but the source needs to live
> somewhere - and I'd prefer it be "not just my laptop".


Right, then can live in your fork and that does not necessarily means
your local copy. More likely it is remote as it commonly understood.


>
> A branch disappearing on the remote doesn't break anything.  You don't
> lose your local copy.  Even a force push is pretty easy to adjust to
> (git reset or git rebase).  This happens all the time for development
> branches and I honestly doubt you notice.  Force pushes are only a
> problem if you're basing work on the branch.


I am not concerned about remote branches disappearing. I am concerned
about the complete opposite, when the remote branches appearing in my
local copy and not disappearing once the remote copies go.


>
> But sure, maybe I'm sinning by doing my job.  More pull requests won't
> help either way.


Honestly, this is not necessarily about PRs, but about work
organization. I would argue the doing pushes into your fork or into the
origin makes no difference for the workflow. At the end the changes has
to appear somehow in the origin/master and PR is just one of the mechanisms.

But doing pushes into origin/somebranch might have negative impact on my
workflow which is not what I like.

It has also negative impact on yourself, because then you want to be
able to force push to delete or update the branch, while in my fork, it
is not concern at all, because I am free to do there whatever I want,
including force push.


Vít





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-06 Thread Vít Ondruch

Dne 06. 05. 20 v 13:20 Fabio Valentini napsal(a):
> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch  wrote:
>>
>> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
>>> On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek  wrote:
>>>
>>> Hi Tomas,
>>>
>>> I'll respond below with some of my experiences and opinions ...
>>>
>>>> Let’s talk about dist-git, as a place where we work. For us,
>>>> packagers, it’s a well-known place. Yet for newcomers, it may take a
>>>> while to learn all the details. Even though we operate with projects
>>>> in a dist-git repository, the layout doesn’t resemble the respective
>>>> upstream project.
>>>>
>>>> There is a multitude of tasks we tend to perform in a dist-git repo:
>>>> * Bumping a release field for sake of a rebuild.
>>>> * Updating to the latest upstream release.
>>>> * Resolving CVEs.
>>>> * Fixing bugs by…
>>>>   * Changing a spec file.
>>>>   * Pulling a commit from upstream.
>>>>   * Or even backporting a commit.
>>>> * And more...
>>>>
>>>> For some tasks, the workflow is just fine and pretty straightforward.
>>>> But for the other, it’s very gruesome - the moment you need to touch
>>>> patch files, the horror comes in. The fact that we operate with patch
>>>> files, in a git repository, is just mind-boggling to me.
>>>>
>>>> Luckily, we have tooling which supports the repository layout -
>>>> `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can
>>>> easily inspect the source tree or make sure your local change builds.
>>>>
>>>> Where am I getting with this?
>>>>
>>>> Over the years there have been multiple tools created to improve the
>>>> development experience:
>>>> rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
>>>> the way Fedora kernel developers work on kernel [k]).
>>> (snip)
>>>
>>>> In the packit project, we work in source-git repositories. These are
>>>> pretty much upstream repositories combined with Fedora downstream
>>>> packaging files. An example: I recently added a project called nyancat
>>>> [n] to Fedora. I have worked [w] on packaging the project in the
>>>> GitHub repo and then just pushed the changes to dist-git using packit
>>>> tooling. These source-git repositories can live anywhere: we have
>>>> support for GitHub right now and are working on supporting pagure.
>>>>
>>>> Would there be an interest within the community, as opt-in, to have
>>>> such source-git repositories created for respective dist-git
>>>> repositories? The idea is that you would work in the source-git repo
>>>> and then let packit handle synchronization with a respective dist-git
>>>> repo. Our aim is to provide the contribution experience you have in
>>>> GitHub when working on your packages. Dist-git would still be the
>>>> authoritative source and a place where official builds are done - the
>>>> source-git repo would work as a way to collaborate. We also don’t have
>>>> plans right now to integrate packit into fedpkg.
>>> So, in my experience, source-git might be a workable solution for
>>> packages with *big* downstream modifications. However, for everything
>>> else, I think it's a way to make it easy to accrue technical debt and
>>> to do cargo-culting with downstream patches.
>>>
>>> The vast majority of packages has *no patches* (or at most, one or two
>>> of them)
> (snip)
>
>> I don't really want to argue with this point, I tend to agree. Just out
>> of interest, do we have some statistics to support this? O:-)
> I did not have any stats when I wrote this, but now I do.
> Parsing the rawhide spec files from [0] for lines matching
> "^Patch[0-9]*:[ \t]*.*$", I get the following distribution:
>
> number of patches: number of packages
> total: 21970
> 0: 15638
> 1: 3287
> 2: 1232
> 3: 598
> 4: 325
> 5: 221
> 6: 154
> 7: 97
> 8: 83
> 9: 57
> 10: 41
> 11: 27
> 12: 26
> 13: 25
> 14: 13
> 15: 13
> 16: 14
> 17: 15
> 18: 5
> 19: 8
> 20: 2
> 21: 11
> 22: 2
> 23: 4
> 24: 4
> 25: 5
> 26: 3
> 27: 4
> 28: 5
> 29: 5
> 30: 2
> 31: 6
> 32: 4
> 33: 3
> 34: 1
> 35: 4
> 37: 2
> 38: 1
> 41: 1
> 42: 2
> 46: 1
> 47: 1
> 48: 3
> 49: 1
> 50: 2
> 51: 1

  1   2   3   4   5   6   7   8   9   10   >