Re: %systemd_postun scriptlets need service files as an argument

[Zbigniew Jędrzejewski-Szmek]

On Tue, Oct 22, 2019 at 05:18:06AM +, Globe Trotter via devel wrote:
> Hi,
> Bugzilla is reporting the following error for the slim package:
> %systemd_postun scriptlets need service files as an argument
> I looked online a bit and could not find immediately what I should do here. 
> Could someone please point me to some suggestions/help?
> I do not want the package to be archived.

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

You call e.g. '%systemd_postun apache-httpd.service'. Is anything unclear
in that?

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

%systemd_postun scriptlets need service files as an argument

[Globe Trotter via devel]

Hi,
Bugzilla is reporting the following error for the slim package:
%systemd_postun scriptlets need service files as an argument
I looked online a bit and could not find immediately what I should do here. 
Could someone please point me to some suggestions/help?
I do not want the package to be archived.

Many 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

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-10-22 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open=Meeting).



Source: https://apps.fedoraproject.org/calendar/meeting/9480/

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

A new workflow for newcomers

[alciregi]

Hello, as you can read here [1], the Fedora Join SIG is experimenting a
new people focused workflow for newcomers.

In two words: people willing to contribute, instead of sending them
directly to wiki pages or documentation sites, we would like to discuss
with them and keep them in the wheel, while they discover the
community, and look for a place where they are useful and happy to
help.
This is not an enforcing process, of course. People can still directly
join (or ask to join) teams and follow SIG procedures as before. The
new workflow is meant to help people who do not know enough about how
Fedora works to take that step of joining a group and getting started
with tasks.

So, if you run into people that would like to contribute, but are
undecided and in need of help with where/how they should get started,
please address them to us[2].

Also, it'd be great if we can have more community members in these
channels to answer questions and curiosities coming from potential new
contributors. So please consider keeping an eye on them.

[1] 
https://communityblog.fedoraproject.org/fedora-join-is-trying-a-new-people-focused-workflow-for-newcomers/
[2] https://fedoraproject.org/wiki/Welcome

Thanks,
A.
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org

A new workflow for newcomers

[alciregi]

Hello, as you can read here [1], the Fedora Join SIG is experimenting a
new people focused workflow for newcomers.

In two words: people willing to contribute, instead of sending them
directly to wiki pages or documentation sites, we would like to discuss
with them and keep them in the wheel, while they discover the
community, and look for a place where they are useful and happy to
help.
This is not an enforcing process, of course. People can still directly
join (or ask to join) teams and follow SIG procedures as before. The
new workflow is meant to help people who do not know enough about how
Fedora works to take that step of joining a group and getting started
with tasks.

So, if you run into people that would like to contribute, but are
undecided and in need of help with where/how they should get started,
please address them to us[2].

Also, it'd be great if we can have more community members in these
channels to answer questions and curiosities coming from potential new
contributors. So please consider keeping an eye on them.

[1] 
https://communityblog.fedoraproject.org/fedora-join-is-trying-a-new-people-focused-workflow-for-newcomers/
[2] https://fedoraproject.org/wiki/Welcome

Thanks,
A.
___
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

[Bug 1763924] New: perl-Sys-Syslog-0.36 is available

[bugzilla]

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

Bug ID: 1763924
   Summary: perl-Sys-Syslog-0.36 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sys-Syslog
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.36
Current version/release in rawhide: 0.35-440.fc31
URL: http://search.cpan.org/dist/Sys-Syslog/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3354/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[389-devel] Re: Future of nunc-stans

[William Brown]

> On 22 Oct 2019, at 07:28, Mark Reynolds  wrote:
> 
> 
> On 10/9/19 10:00 PM, William Brown wrote:
>>> On 9 Oct 2019, at 19:55, Ludwig Krispenz  wrote:
>>> 
>>> Hi William,
>>> 
>>> I like your radical approach :-)
>>> 
>>> In my opinion our connection code is getting to complicated by maintaining 
>>> two different implementations in parallel -  not separated, but 
>>> intermangled (and even more complicated by turbo mode). So I agree we 
>>> should have only one, but which one ? In my opinion nunc stans is the 
>>> theoretically better approach, but nobody is confident enough to rely on 
>>> nunc stans alone. The conntable mode has its problems (especially if 
>>> handling many concurrent connections, and worse if they are established 
>>> almost at the same time)(otherwise we would not have experimented with nunc 
>>> stans), but is stable and for most of the use cases efficient enough.
>> I think you nailed it in one - we aren't confident in nunc-stans today, so 
>> let's keep what works and improve that. There are already many similar 
>> concepts - work queues, threads, even slapi_conn_t. I think that it would be 
>> possible to bring "nunc-stans ideas" into reworking and improvement to the 
>> current connection code instead.
>> 
>>> So reducing the complexity by removing nunc stans (and maybe also turbo 
>>> mode) and then do cleanup and try to improve the bottlenecks would be an 
>>> acceptable approach to me.
>> Agree. It also means we can make much smaller changes in an easier to 
>> control and test fashion I think.
>> 
>>> In my opinion the core of the problem of the "old" connection code is that 
>>> the main thread is handling new connections and already established 
>>> connections and so does iterate over the connection table. Using an event 
>>> model looks like the best way to handle this, but if it doesn't work we 
>>> need to look for other improvements without breaking things.
>>> Your suggestion to make the conn table data structure more lean and 
>>> flexible is one option. In sun ds, when I didn't know about event queues I 
>>> did split the main thread, one handling new connections and multiple to 
>>> handle established connections (parts of teh conn table) - reusing the 
>>> existing mechanisms, just splitting the load. Maybe we can also think in 
>>> this direction.
>> I think so too. We can certainly have some ideas about what actually does 
>> the polling vs what does accepting, or better, event management etc. There 
>> are some ideas to have smaller groups of workers too to improve thread 
>> locality and help improve concurrency too.
>> 
>> So maybe I'll put together a patch to remove nunc-stans soon then, and start 
>> to look at the existing connection code and options to improve that + some 
>> profiling.
>> 
>> I still would like to hear about my original question though as quoted 
>> below, I think Mark might have some comments :)
> 
> Why nunc-stans?  Because at the time we were terrible at handling many 
> connections, simultaneously and in large numbers.  C10K, etc.  Our 
> competitors performed much better in these scenarios than we did.  I recall 
> several customer cases complaining about "our performance verses theirs" in 
> regards to large numbers of connection.
> 
> So, moving forward, I agree with everyone here.  We should remove nunc-stans, 
> but as William said try to incorporate some of its concepts into our 
> connection code (eventually).  We should clean up the connection code as much 
> as possible, and remove turbo mode if it does not provide much value.

I think turbo mode was to try and shortcut returning to the conntable and then 
having the blocking on the connections poll because the locking strategies 
before weren't as good. I think there is still some value in turbo "for now" 
but if we can bring in libevent, then it diminishes because we become event 
driven rather than poll driven. 

>  The one thing that has been frustrating is how the connection code had 
> become very complicated and most of us no longer know how it works anymore.  
> It would be nice to get it to a state that is much more maintainable 
> (especially for engineers new to the code).

Given how much I've looked at it recently, I'm probably the closest to having 
an understanding of that code, but I certainly won't claim 100% expertise here. 

> 
> I think we should look at improving the connection table as previously 
> suggested, and we should add the additional polling thread that Ludwig 
> mentioned.  We know we will get added performance with just these two 
> changes.  Then we should stress and evaluate the new behavior, and if need be 
> we can look into more invasive/architectural changes and use some of the 
> ideology from nunc-stans.  (This also means we need a way to properly and 
> consistently test high connection load from multiple clients).

I think there are a few things we can do beside this. I think we could also 
split the thread pool into multiple 

[389-devel] Re: Future of nunc-stans

[Mark Reynolds]

On 10/9/19 10:00 PM, William Brown wrote:

On 9 Oct 2019, at 19:55, Ludwig Krispenz  wrote:

Hi William,

I like your radical approach :-)

In my opinion our connection code is getting to complicated by maintaining two 
different implementations in parallel -  not separated, but intermangled (and 
even more complicated by turbo mode). So I agree we should have only one, but 
which one ? In my opinion nunc stans is the theoretically better approach, but 
nobody is confident enough to rely on nunc stans alone. The conntable mode has 
its problems (especially if handling many concurrent connections, and worse if 
they are established almost at the same time)(otherwise we would not have 
experimented with nunc stans), but is stable and for most of the use cases 
efficient enough.

I think you nailed it in one - we aren't confident in nunc-stans today, so let's keep 
what works and improve that. There are already many similar concepts - work queues, 
threads, even slapi_conn_t. I think that it would be possible to bring "nunc-stans 
ideas" into reworking and improvement to the current connection code instead.


So reducing the complexity by removing nunc stans (and maybe also turbo mode) 
and then do cleanup and try to improve the bottlenecks would be an acceptable 
approach to me.

Agree. It also means we can make much smaller changes in an easier to control 
and test fashion I think.


In my opinion the core of the problem of the "old" connection code is that the 
main thread is handling new connections and already established connections and so does 
iterate over the connection table. Using an event model looks like the best way to handle 
this, but if it doesn't work we need to look for other improvements without breaking 
things.
Your suggestion to make the conn table data structure more lean and flexible is 
one option. In sun ds, when I didn't know about event queues I did split the 
main thread, one handling new connections and multiple to handle established 
connections (parts of teh conn table) - reusing the existing mechanisms, just 
splitting the load. Maybe we can also think in this direction.

I think so too. We can certainly have some ideas about what actually does the 
polling vs what does accepting, or better, event management etc. There are some 
ideas to have smaller groups of workers too to improve thread locality and help 
improve concurrency too.

So maybe I'll put together a patch to remove nunc-stans soon then, and start to 
look at the existing connection code and options to improve that + some 
profiling.

I still would like to hear about my original question though as quoted below, I 
think Mark might have some comments :)


Why nunc-stans?  Because at the time we were terrible at handling many 
connections, simultaneously and in large numbers.  C10K, etc.  Our 
competitors performed much better in these scenarios than we did.  I 
recall several customer cases complaining about "our performance verses 
theirs" in regards to large numbers of connection.


So, moving forward, I agree with everyone here.  We should remove 
nunc-stans, but as William said try to incorporate some of its concepts 
into our connection code (eventually).  We should clean up the 
connection code as much as possible, and remove turbo mode if it does 
not provide much value.  The one thing that has been frustrating is how 
the connection code had become very complicated and most of us no longer 
know how it works anymore.  It would be nice to get it to a state that 
is much more maintainable (especially for engineers new to the code).


I think we should look at improving the connection table as previously 
suggested, and we should add the additional polling thread that Ludwig 
mentioned.  We know we will get added performance with just these two 
changes.  Then we should stress and evaluate the new behavior, and if 
need be we can look into more invasive/architectural changes and use 
some of the ideology from nunc-stans.  (This also means we need a way to 
properly and consistently test high connection load from multiple clients).


Mark




The main question is *why* do we want it merged?
Is it performance? Recently I provided a patch that yielded an approximate ~30% 
speed up in the entire server through put just by changing our existing 
connection code.
Is it features? What features are we wanting from this? We have no complaints 
about our current threading model and thread allocations.
Is it maximum number of connections? We can always change the conntable to a 
better datastructure that would help scale this number higher (which would also 
yield a performance gain).

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: Review swap: python-graph-tool (Was: Re: Packaging graph-tool: help speeding up build)

[Ben Cotton]

On Mon, Oct 21, 2019, 03:32 Ankur Sinha  wrote:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1763597
>
I'll trade you for https://bugzilla.redhat.com/show_bug.cgi?id=1763261
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via releng issues:
https://pagure.io/releng/issues

Full report available at:
https://churchyard.fedorapeople.org/orphans-2019-10-21.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

alacarte  alexl, caillon, caolanm, 5 weeks ago
  johnp, mbarnes, orphan,
  rhughes, ssp
audio-convert-mod orphan   5 weeks ago
batti orphan   5 weeks ago
bibus orphan   0 weeks ago
bzr   orphan   3 weeks ago
cassandra acaringi, hhorak, jjanco,4 weeks ago
  orphan, rimolive
castor-maven-plugin   orphan   3 weeks ago
cbi-plugins   eclipse-sig, kdaniel, orphan,4 weeks ago
  rgrunber
chm2pdf   orphan   5 weeks ago
diffuse   cicku, fab, orphan   2 weeks ago
eclipse-dtp   eclipse-sig, galileo, kdaniel,   4 weeks ago
  mbooth, orphan
eclipse-ecf   eclipse-sig, kdaniel, orphan,4 weeks ago
  rgrunber
eclipse-eclemma   eclipse-sig, jerboaa, kdaniel,   4 weeks ago
  orphan, rgrunber
eclipse-egit-github   eclipse-sig, orphan  4 weeks ago
eclipse-linuxtoolseclipse-sig, jjohnstn, orphan,   4 weeks ago
  rgrunber
eclipse-moreunit  jerboaa, orphan  4 weeks ago
eclipse-mpc   eclipse-sig, kdaniel, orphan,4 weeks ago
  rgrunber
eclipse-mylyn arobinso, eclipse-sig,   4 weeks ago
  jjohnstn, kdaniel, orphan,
  rgrunber
eclipse-packagekiteclipse-sig, jerboaa, kdaniel,   4 weeks ago
  orphan, rgrunber
eclipse-pydev eclipse-sig, jjohnstn, orphan4 weeks ago
eclipse-swtboteclipse-sig, orphan  4 weeks ago
eclipse-tm-terminal   eclipse-sig, orphan  4 weeks ago
euca2ools orphan   5 weeks ago
extra166y orphan   0 weeks ago
felix-osgi-foundation orphan   0 weeks ago
freemedforms  nobrakal, orphan 4 weeks ago
func  alikins, orphan, robert, 5 weeks ago
  wakko666
gcc-python-plugin jakub, orphan5 weeks ago
ginfo orphan, stevetraylen 5 weeks ago
git-remote-bzrorphan   4 weeks ago
gnome-python2-extras  alexl, caillon, caolanm, 5 weeks ago
  gnome-sig, johnp, mikedep333,
  orphan, rhughes, rstrode, ssp
gnu-regexpdbhole, mizdebsk, orphan 3 weeks ago
gstreamer-python  company, orphan, tomspur 5 weeks ago
java-base64   orphan   4 weeks ago
jcsp  orphan   0 weeks ago
jetty-version-maven-pluginmizdebsk, orphan 4 weeks ago
js-excanvas   nodejs-sig, orphan, rathann, 3 weeks ago
  williamjmorenor
json_diff orphan   2 weeks ago
laditools orphan   5 weeks ago
leafnode  orphan   2 weeks ago
libfixposix   orphan  

Updates to the FTBFS policy

[Miro Hrončok]

Hello,

after the recent discussions, the Fedora's "Fails to Build From Source" policy 
[0] has been updated [1][2].


The changes include:


## The policy no longer requires e-mails to devel to orphan a package

This requirement made automation hard and resulted in most of the packages never 
being orphaned because almost nobody did this. The public e-mail about a certain 
package failing to build may have been seen as public shaming by some.



## Packages with NEW bugs will be orphaned after 8 weeks

Orphaning packages where the maintainers don't respond at all makes sure that 
all the dependent package maintainers are properly notified about the problem 
long before the package is retired.



## Not orphaned packages are only retired after they FTBFS for 13+ months

A week before Fedora N branching, packages that haven't built successfully at 
least on Fedora N-2 will be retired regardless of their FTBFS bug status.


This allows the maintainers to postpone the package retirement, but not 
indefinitely. It also enforces that even if the bugs are closed by mistake, we 
don't miss any packages.


The policy only allows the retirements to happen when there are several 
announcements about this on the devel list, with the list of packages. This 
makes sure nothing happens unexpectedly.




I hope the changes will help assure Fedora packages stay in an generally healthy 
state without (especially occasional) Fedora contributors feeling intimidated by 
the rules. In any case, if you feel you need help when your package fails to 
build, please don't hesitate to use the devel mailing list to reach out, as does 
the document describing Fedora packager responsibilities [3] suggests.


Thanks to everybody who was involved in this effort.

[0] 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

[1] https://pagure.io/fesco/issue/2244
[2] https://pagure.io/fesco/fesco-docs/pull-request/18
[3] 
https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org

Re: Add a rule to have a compose when Fedora branched

[Kevin Fenzi]

On Mon, Oct 14, 2019 at 11:59:30AM +0200, jkone...@redhat.com wrote:
> FYI: FESCO ticket was created
> 
> https://pagure.io/fesco/issue/2246

Yeah, and we had a bit more discussion there, which we probibly should
have just had here. ;) 

In particular bcotton asked how we avoid scheduling the branch date
"right after" flock:

"This is a good idea, but we'll need to figure out what it actually means.

How do we define "right after"?
The schedule is set well before Flock is planned, so would the expectation
be that Flock is scheduled to avoid this or that we should adjust the
release schedule after Flock is set? If we adjust the release schedule
how does that impact other milestones? Right now, all schedule milestonesi
are effectively anchored off the target release date. If we have to delay
the branch point to accommodate Flock, do we move the release date out
or do we compress other parts of the schedule?"

Igor said: 

"I'm strongly against this as a rawhide user. We should not block
rawhide by anything, we do snapshot of it at some point and stabilize it
instead."

So, any thoughts on those? I think we could perhaps drop the 'stop
rawhide composes until we get a branched' from the proposal anyhow, as
hopefully before too long we will have rawhide calling itself 'rawhide'
instead of the number and this should avoid a lot of the confusion that
happend this cycle with branching not being composed yet and rawhide
composing correctly. 

I am not sure how to avoid the flock dates. I guess could we add this in
as a factor on flock dates? We would have to communicate that to folks
planning flock. (The CAIC?)

Lets discuss it here a bit more until we have a more concrete thing for
fesco to vote on.

kevin


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

Re: Recommending proprietary software in Fedora

[Florian Weimer]

* Debarshi Ray:

> On Mon, Oct 14, 2019 at 07:19:02AM -0700, John M. Harris Jr wrote:
>> On Monday, October 14, 2019 6:12:18 AM MST mcatanz...@gnome.org wrote:
>> > On Mon, Oct 14, 2019 at 11:49 AM, John M. Harris Jr
>> > 
>> >  wrote:
>> > > It's good that we can
>> > > reference external repositories such as rpmfusion-free, in my opinion.
>> > 
>> > We actually cannot do that. It is prohibited because it would entail
>> > significant risk.
>> 
>> And proprietary software, in your opinion, does not?
>
> Depends. The answer to that question lies in the differences between
> how copyright and patent laws work.

But it leads to the strange situation that we can recommend to install
ffmpeg if it is bundled with some proprietary software, but cannot do so
if it is part of a free software repository.

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

Re: Recommending proprietary software in Fedora

[Debarshi Ray]

On Mon, Oct 14, 2019 at 07:19:02AM -0700, John M. Harris Jr wrote:
> On Monday, October 14, 2019 6:12:18 AM MST mcatanz...@gnome.org wrote:
> > On Mon, Oct 14, 2019 at 11:49 AM, John M. Harris Jr
> > 
> >  wrote:
> > > It's good that we can
> > > reference external repositories such as rpmfusion-free, in my opinion.
> > 
> > We actually cannot do that. It is prohibited because it would entail
> > significant risk.
> 
> And proprietary software, in your opinion, does not?

Depends. The answer to that question lies in the differences between
how copyright and patent laws 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

[Bug 1763515] perl-Module-CoreList-5.20191020 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Module-CoreList-5.20191020-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-af4d549d91

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763514] perl-CPAN-Perl-Releases-4.16 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-CPAN-Perl-Releases-4.16-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-0c5c93455f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via releng issues:
https://pagure.io/releng/issues

Full report available at:
https://churchyard.fedorapeople.org/orphans-2019-10-21.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

alacarte  alexl, caillon, caolanm, 5 weeks ago
  johnp, mbarnes, orphan,
  rhughes, ssp
audio-convert-mod orphan   5 weeks ago
batti orphan   5 weeks ago
bibus orphan   0 weeks ago
bzr   orphan   3 weeks ago
cassandra acaringi, hhorak, jjanco,4 weeks ago
  orphan, rimolive
castor-maven-plugin   orphan   3 weeks ago
cbi-plugins   eclipse-sig, kdaniel, orphan,4 weeks ago
  rgrunber
chm2pdf   orphan   5 weeks ago
diffuse   cicku, fab, orphan   2 weeks ago
eclipse-dtp   eclipse-sig, galileo, kdaniel,   4 weeks ago
  mbooth, orphan
eclipse-ecf   eclipse-sig, kdaniel, orphan,4 weeks ago
  rgrunber
eclipse-eclemma   eclipse-sig, jerboaa, kdaniel,   4 weeks ago
  orphan, rgrunber
eclipse-egit-github   eclipse-sig, orphan  4 weeks ago
eclipse-linuxtoolseclipse-sig, jjohnstn, orphan,   4 weeks ago
  rgrunber
eclipse-moreunit  jerboaa, orphan  4 weeks ago
eclipse-mpc   eclipse-sig, kdaniel, orphan,4 weeks ago
  rgrunber
eclipse-mylyn arobinso, eclipse-sig,   4 weeks ago
  jjohnstn, kdaniel, orphan,
  rgrunber
eclipse-packagekiteclipse-sig, jerboaa, kdaniel,   4 weeks ago
  orphan, rgrunber
eclipse-pydev eclipse-sig, jjohnstn, orphan4 weeks ago
eclipse-swtboteclipse-sig, orphan  4 weeks ago
eclipse-tm-terminal   eclipse-sig, orphan  4 weeks ago
euca2ools orphan   5 weeks ago
extra166y orphan   0 weeks ago
felix-osgi-foundation orphan   0 weeks ago
freemedforms  nobrakal, orphan 4 weeks ago
func  alikins, orphan, robert, 5 weeks ago
  wakko666
gcc-python-plugin jakub, orphan5 weeks ago
ginfo orphan, stevetraylen 5 weeks ago
git-remote-bzrorphan   4 weeks ago
gnome-python2-extras  alexl, caillon, caolanm, 5 weeks ago
  gnome-sig, johnp, mikedep333,
  orphan, rhughes, rstrode, ssp
gnu-regexpdbhole, mizdebsk, orphan 3 weeks ago
gstreamer-python  company, orphan, tomspur 5 weeks ago
java-base64   orphan   4 weeks ago
jcsp  orphan   0 weeks ago
jetty-version-maven-pluginmizdebsk, orphan 4 weeks ago
js-excanvas   nodejs-sig, orphan, rathann, 3 weeks ago
  williamjmorenor
json_diff orphan   2 weeks ago
laditools orphan   5 weeks ago
leafnode  orphan   2 weeks ago
libfixposix   orphan  

Re: Review swap (htslib)

[Jun Aruga]

Hi Zbigniew and Kevin

Many thanks for your explanation.
I clearly understand the htslib's situation now.

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

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

[Stephen John Smoogen]

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

Whoops. I apologize for not catching this earlier.


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



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

[Bug 1753401] [RFE] EPEL8 branch of perl-Class-Accessor-Lite

[bugzilla]

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



--- Comment #1 from Denis Fateyev  ---
Any updates?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Some Java packages looking for new maintainers

[Fabio Valentini]

Hello packagers,

The Stewardship SIG is currently providing only bare-minimum
maintenance for some packages, and none of our other packages depend
on these anymore. So, we're looking for someone to take better care of
them, preferably someone who actively uses them or maintains a package
that depends on them.

- apache-commons-configuration
- base64coder
- batik
- jboss-jsp-2.3-api
- parboiled
- pdfbox

For reference, these packages are directly dependent packages:

apache-commons-configuration:
- archaius
- hystrix

base64coder:
- datanucleus-core

batik:
- arduino
- clapham
- ditaa
- eclipse
- fop
- scilab

jboss-jsp-2.3-api:
- jboss-jsf-2.2-api
- jboss-jstl-1.2-api
- struts

parboiled:
- pegdown

pdfbox:
- fop
- javadocofflinesearch


If you received this email directly, you're a (co-)maintainer of one
of the packages listed above, and would probably be best qualified to
take care of the relevant dependency.

If you want to take any of these packages off our hands, fill out the
"package_adoption_request" template here:
https://www.pagure.io/stewardship-sig/new_issue

If nobody claims the packages within the next two weeks, we will
orphan them again, setting them on their course towards retirement in
about two months.

Thanks,
Fabio (decathorpe), for the Stewardship SIG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1761523] Upgrade perl-Test-TCP to 2.22

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



--- Comment #7 from Fedora Update System  ---
FEDORA-EPEL-2019-ead539271a has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ead539271a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Fedora-31-20191021.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/153 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-31-20191020.n.0):

ID: 473207  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/473207
ID: 473215  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/473215
ID: 473230  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/473230
ID: 473280  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/473280

Old failures (same test failed in Fedora-31-20191020.n.0):

ID: 473166  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/473166
ID: 473228  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/473228

Soft failed openQA tests: 2/153 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-31-20191020.n.0):

ID: 473205  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/473205
ID: 473284  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/473284

Passed openQA tests: 138/153 (x86_64)

Skipped non-gating openQA tests: 9 of 155

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.02 to 0.48
Previous test data: https://openqa.fedoraproject.org/tests/472927#downloads
Current test data: https://openqa.fedoraproject.org/tests/473195#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
System load changed from 1.69 to 1.24
Previous test data: https://openqa.fedoraproject.org/tests/472944#downloads
Current test data: https://openqa.fedoraproject.org/tests/473212#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used mem changed from 825 MiB to 918 MiB
System load changed from 1.84 to 2.01
Average CPU usage changed from 14.50952381 to 80.59047619
Previous test data: https://openqa.fedoraproject.org/tests/472946#downloads
Current test data: https://openqa.fedoraproject.org/tests/473214#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
Used mem changed from 790 MiB to 896 MiB
1 services(s) added since previous compose: pcscd.service
System load changed from 1.09 to 0.72
Average CPU usage changed from 73.75714286 to 20.62380952
Previous test data: https://openqa.fedoraproject.org/tests/473037#downloads
Current test data: https://openqa.fedoraproject.org/tests/473305#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1763515] perl-Module-CoreList-5.20191020 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Module-CoreList-5.20191020-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-860da0cc9e

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763514] perl-CPAN-Perl-Releases-4.16 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-CPAN-Perl-Releases-4.16-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-6fb1464afb

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

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

[Igor Gnatenko]

Hello EPEL maintainers and users,

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

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

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

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

[0] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b4e9aea40d
-- 
-Igor Gnatenko
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1762918] [RFE] EPEL-8 branch for perl-Email-Address-XS

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Email-Address-XS-1.04-6.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c19791e758

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1762255] perl-Sub-Override for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Sub-Override-0.09-20.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fd25f0e78a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1761155] Plans for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Class-Load-0.25-9.el8, perl-Class-Load-XS-0.10-10.el8 has been pushed to
the Fedora EPEL 8 testing repository. If problems still persist, please make
note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-806b43e9c5

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1c488e885d   
python-ecdsa-0.13.3-1.el8
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-942baf668f   
nsd-4.2.2-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

cros-guest-tools-1.0-0.19.20191015gita93ea04.el8
lightdm-1.30.0-3.el8
lua-basexx-0.4.0-2.el8
lua-binaryheap-0.4-1.el8
lua-cqueues-20190813-1.el8
lua-fifo-0.2-2.el8
lua-lpeg-patterns-0.5-2.el8
lua-luaossl-20190731-1.el8
lua-mmdb-0.2-2.el8
moreutils-0.63-1.el8
perl-Any-Moose-0.27-14.el8
perl-Class-Load-0.25-9.el8
perl-Class-Load-XS-0.10-10.el8
perl-Crypt-DH-GMP-0.00012-16.el8
perl-Email-Address-XS-1.04-6.el8
perl-Moose-2.2011-9.el8
perl-MooseX-Role-WithOverloading-0.17-15.el8
perl-MooseX-Types-0.50-9.el8
perl-Net-OpenID-Common-1.20-11.el8
perl-Net-OpenID-Server-1.09-14.el8
perl-Sub-Override-0.09-20.el8
python-ns1-python-0.12.0-1.el8
sslh-1.20-1.el8
tomoe-0.6.0-43.el8
zinnia-0.06-46.el8

Details about builds:



 cros-guest-tools-1.0-0.19.20191015gita93ea04.el8 (FEDORA-EPEL-2019-fc0108ac64)
 Chromium OS integration meta package

Update Information:

Add mesa-dri-drivers are a recommended package.    Update to latest master
release and remove cros-adapta theme due to missing dependencies.

ChangeLog:

* Fri Oct 18 2019 Jason Montleon jmont...@redhat.com 1.0-0.19.20191015gita93ea04
- Add recommends for mesa-dri-drivers
* Tue Oct 15 2019 Jason Montleon jmont...@redhat.com 1.0-0.18.20191015gita93ea04
- Update to upstream master
- Removed cros-adapta theme for CentOS 8 due to missing dependencies




 lightdm-1.30.0-3.el8 (FEDORA-EPEL-2019-3033b12900)
 A cross-desktop Display Manager

Update Information:

- Switch from /var/run to /run directory    - Build for epel8




 lua-basexx-0.4.0-2.el8 (FEDORA-EPEL-2019-2ed4d28f40)
 BaseXX encoding and decoding library for Lua

Update Information:

- import package from rawhide to EPEL8




 lua-binaryheap-0.4-1.el8 (FEDORA-EPEL-2019-489e6370ee)
 Binary heap implementation for Lua

Update Information:

- import package from rawhide to EPEL8




 lua-cqueues-20190813-1.el8 (FEDORA-EPEL-2019-2c9bcebc32)
 Stackable Continuation Queues for the Lua Programming Language

Update Information:

- new package imported from rawhide




 lua-fifo-0.2-2.el8 (FEDORA-EPEL-2019-933945923f)
 FIFO library for Lua

Update Information:

- import package from rawhide to EPEL8




 lua-lpeg-patterns-0.5-2.el8 (FEDORA-EPEL-2019-93ee722f14)
 A collection of LPEG patterns

Update Information:

- import package from rawhide to EPEL8




 lua-luaossl-20190731-1.el8 (FEDORA-EPEL-2019-e0f289ffb7)
 Most comprehensive OpenSSL module in the Lua universe

Update Information:

- import package from rawhide to EPEL8




 

[Bug 1761858] perl-Net-OpenID-Server for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Net-OpenID-Server-1.09-14.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3c535ff9fd

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1762022] perl-Crypt-DH-GMP for EL 8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Crypt-DH-GMP-0.00012-16.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-18632499bd

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1761491] Request to build perl-Moose for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Any-Moose-0.27-14.el8, perl-Moose-2.2011-9.el8,
perl-MooseX-Role-WithOverloading-0.17-15.el8, perl-MooseX-Types-0.50-9.el8 has
been pushed to the Fedora EPEL 8 testing repository. If problems still persist,
please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ba1007c402

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1762021] perl-Net-OpenID-Common for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Net-OpenID-Common-1.20-11.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-13b77ca98d

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Fedora 31 compose report: 20191021.n.0 changes

[Fedora Branched Report]

OLD: Fedora-31-20191020.n.0
NEW: Fedora-31-20191021.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Python_Classroom raw-xz armhfp
Path: 
Labs/armhfp/images/Fedora-Python-Classroom-armhfp-31-20191021.n.0-sda.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 17, 2019 at 11:57:48AM +0200, Christian Kellner wrote:
> First of all, sorry for replying so late, Benjman was quite busy with
> GNOME and sytemd user session transistion and is now on a longer PTO.
> 
> On Mon, 2019-09-23 at 16:29 +0200, Igor Gnatenko wrote:
> > So what are we going to do about this in F32? Are we going to create
> > configuration files or we will provide some page how to create it
> > yourself? Does Intel provide one?
> 
> The idea, as already mentioned by Hans in another thread, was to indeed
> to both: 1) to have a separate package that includes configuration
> files for different systems and then have thermald pick up the right
> configuration for current system. 2) Additionally we were discussing a
> way for users to submit such files to be included. But the this is an
> optional step and could be done later as well.
> 
> 
> > So what is the point of a change if improvements are visible only if
> > non-free package is installed?
> So above, shipping a "database", i.e. a package with per-model
> configuration data for popular laptop modules, should make that package
> useful even without the non-free package.

Hi Christian,

we discussed this change during the FESCo meeting today.

Please update the change page with a fuller discussion of what exactly
will be implemented, in particular the plan wrt. to the free and non-free
parts, and local and remote information storage.

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

[Bug 1763497] [RFE] EPEL-6 and EPEL-7 branches for perl-Feed-Find

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2019-c6f569ece7 has been submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c6f569ece7

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763494] [RFE] EPEL-7 branch for perl-Module-Util

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2019-88bd4e4eb0 has been submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-88bd4e4eb0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763495] [RFE] EPEL-7 branch for perl-DateTime-Format-Natural

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2019-88bd4e4eb0 has been submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-88bd4e4eb0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Summary/minutes for today's FESCo Meeting (2019-10-21)

[Zbigniew Jędrzejewski-Szmek]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-10-21/fesco.2019-10-21-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-10-21/fesco.2019-10-21-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-10-21/fesco.2019-10-21-15.00.log.html

Meeting summary
---
* init process  (zbyszek, 15:00:16)

* #2241 F32 Self-Contained Change: Better Thermal Management for the
  Workstation  (zbyszek, 15:01:28)
  * AGREED: Ask the change owners to fill in the change page, revisit in
two weeks (+9, 0, 0)  (zbyszek, 15:11:20)

* #2246 Create a rule to get newly Fedora branched composes sooner
  (zbyszek, 15:11:29)
  * ACTION: nirik to restart the discussion on fedora-devel  (zbyszek,
15:14:52)

* #2230 FESCo blocker bug: Broken upgrades via libgit2  (zbyszek,
  15:15:29)
  * AGREED: (+5, 1, -1)  (zbyszek, 15:34:03)
  * ACTION: nirik to ask kalev about workaround in
packagekit/gnome-software and block release on this fix. If it is
complicated, ignatenkobrain will create libgit2_0.28 package.
(zbyszek, 15:34:29)

* Next week's chair  (zbyszek, 15:36:10)
  * ACTION: ignatenkobrain_ to chair next meeting  (zbyszek, 15:37:46)

* Open Floor  (zbyszek, 15:37:53)
  * LINK: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
(nirik, 15:42:36)
  * LINK: https://docs.fedoraproject.org/en-US/ci/   (bookwar, 15:44:24)
  * LINK: https://github.com/fedora-infra/bodhi/issues/2322   (pingou,
15:44:36)

Meeting ended at 15:49:37 UTC.

Action Items

* nirik to restart the discussion on fedora-devel
* nirik to ask kalev about workaround in packagekit/gnome-software and
  block release on this fix. If it is complicated, ignatenkobrain will
  create libgit2_0.28 package.
* ignatenkobrain_ to chair next meeting
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: opencascade: How to deal with source downloads that require a login

[Miro Hrončok]

On 21. 10. 19 17:36, Miro Hrončok wrote:

On 21. 10. 19 17:17, Richard Shaw wrote:
I'm working on packaging opencasecade for Fedora as OCE (occt community 
edition) has not been updated in years.


Unfortunately while the occt license was updated to be truly open source they 
still require a login to download the source archive.


Is this a FOSS problem or just a technical/infra one? Obviously tools like 
downloading with spectools will fail...


The easy fix is to upload the source to somewhere everyone can get to it (My 
fedorapeople account?).


Use something like this:

# go to www and click xxx, than you can download this
Source0:    %{name}-%{version}.tar.xz


See also 
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_troublesome_urls



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

Re: opencascade: How to deal with source downloads that require a login

[Adam Williamson]

On Mon, 2019-10-21 at 10:17 -0500, Richard Shaw wrote:
> I'm working on packaging opencasecade for Fedora as OCE (occt community
> edition) has not been updated in years.
> 
> Unfortunately while the occt license was updated to be truly open source
> they still require a login to download the source archive.
> 
> Is this a FOSS problem or just a technical/infra one? Obviously tools like
> downloading with spectools will fail...

As long as the license is acceptable according to the Fedora list it's
not a problem.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: opencascade: How to deal with source downloads that require a login

[Miro Hrončok]

On 21. 10. 19 17:17, Richard Shaw wrote:
I'm working on packaging opencasecade for Fedora as OCE (occt community edition) 
has not been updated in years.


Unfortunately while the occt license was updated to be truly open source they 
still require a login to download the source archive.


Is this a FOSS problem or just a technical/infra one? Obviously tools like 
downloading with spectools will fail...


The easy fix is to upload the source to somewhere everyone can get to it (My 
fedorapeople account?).


Use something like this:

# go to www and click xxx, than you can download this
Source0:%{name}-%{version}.tar.xz

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

opencascade: How to deal with source downloads that require a login

[Richard Shaw]

I'm working on packaging opencasecade for Fedora as OCE (occt community
edition) has not been updated in years.

Unfortunately while the occt license was updated to be truly open source
they still require a login to download the source archive.

Is this a FOSS problem or just a technical/infra one? Obviously tools like
downloading with spectools will fail...

The easy fix is to upload the source to somewhere everyone can get to it
(My fedorapeople account?).

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

Re: Modularity and the system-upgrade path

[Stephen John Smoogen]

On Mon, 21 Oct 2019 at 11:08, Randy Barlow  wrote:
>
> On Mon, 2019-10-21 at 09:16 -0400, Stephen John Smoogen wrote:
> > The problem is that COPRs do not have any way of communicating with
> > each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I
> > grab
> > from copr-B and it has libfoo-2.3.2-2 then I am going to replace
> > copr-A's packages which may break what I wanted from there.
>
> Modularity also suffers from this problem.

I don't see it having this problem currently. I can either install one
or the other. I can not mix the two. It may not communicate to me why
I can't mix the two.. but it does stop me from shooting myself in the
foot.




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

Re: Modularity and the system-upgrade path

[Randy Barlow]

On Mon, 2019-10-21 at 14:00 +, Zbigniew Jędrzejewski-Szmek wrote:
> Packaging in Fedora is
> definitely harder than it used to be. We still haven't really
> recovered from
> pkgdb retirement, various infra tools don't have enough support, etc.
> No easy solutions to this problem either, but I think keeping
> packaging
> simple (or at least not more complicated than it currently is).

I agree - I think the retirement of pkgdb without suitable replacement
has made packaging harder when it already wasn't easy. This can't be
helpful towards the goal of growing our contributor base.


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

Re: Modularity and the system-upgrade path

[Stephen John Smoogen]

On Mon, 21 Oct 2019 at 09:37, Fabio Valentini  wrote:
>
> On Mon, Oct 21, 2019, 15:17 Stephen John Smoogen  wrote:
>>
>> On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
>>  wrote:
>> >
>> > On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
>> > > If I were to start from scratch on this, I would look at the simplest
>> > > solution I would want from Boltron. I want to make it so a package team 
>> > > can
>> > > make a set of packages in a repository and work out how I can interact 
>> > > with
>> > > other repositories. I also want to easily build that package set in ways 
>> > > to
>> > > work on different versions of an operating system.
>> >
>> > The question is whether this team wants to do the "heavy lifting"
>> > (which might or might not actually be very heavy), of integrating with
>> > the rest of the distro. If they don't, then Copr is the answer: it
>> > provides all the answers, including automatic rebuilds.
>> >
>>
>> The problem is that COPRs do not have any way of communicating with
>> each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I grab
>> from copr-B and it has libfoo-2.3.2-2 then I am going to replace
>> copr-A's packages which may break what I wanted from there. I am
>> saying that if we look at a way that they can clearly communicate
>> these problems to the user then we have fixed that.
>
>
> Why not specify those requirements in RPM Requires? That's what they are for.
>

Because this isn't about a package but a set of packages. I may not
know that you are going to use Repo-B.. but may have known about
Repo-C which did work. [Maybe it turns out that libfoo-2.3.2-2 in repo
C does work because it had a patch.]

The problem I am seeing is that with N thousand copr packages, you can
only express some amount of stuff in the packages themselves. In the
end there are parts which need to be expressed more abstractly higher
up. [I know I work with copr-X, I don't work with copr-Y.] etc.

This is a common problem which shows up because people have problems
they want to solve, they google to find a solution and htey cobble
together something from 10 different repositories which may or may not
have been designed to work together. [This will also happen in
container combinations etc so if we can help fix it here.. it can be
used elsewhere.]

The answers of 'well dont' do that', 'get them to put them in the OS',
etc etc have not worked for 20 years.

The idea of adding more packagers to the community hasn't worked
either.. even before pkgdb was retired.. there was no 'growth'.. there
was a set number of people who were active (they may not be the same
as now.. but the number was the same). I would say 350 active
packagers is our Dunbar number but that is getting far into the
pseudo-science weeds. Is that the number of packagers? No.. there are
a lot of people who will do a small set and have no interested outside
of that. Giving them the tools which can allow them to communicate
what their repo can and can not do seems like a good thing.

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

Re: Modularity and the system-upgrade path

[Randy Barlow]

On Mon, 2019-10-21 at 14:00 +, Zbigniew Jędrzejewski-Szmek wrote:
> The problem is hard. If there was an obvious solution, we wouldn't be
> having this discussion.

I've pointed out a few times that other distros have solved the "too
fast, too slow" problem. In at least one case, as long ago as 2004. I
see it as a solved problem and I don't understand why we are trying to
solve it again.


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

Re: Modularity and the system-upgrade path

[Randy Barlow]

On Mon, 2019-10-21 at 09:16 -0400, Stephen John Smoogen wrote:
> The problem is that COPRs do not have any way of communicating with
> each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I
> grab
> from copr-B and it has libfoo-2.3.2-2 then I am going to replace
> copr-A's packages which may break what I wanted from there.

Modularity also suffers from this problem.


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

[Bug 1763653] perl-Math-BigInt-1.999818 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Math-BigInt-1.9998.18-
   ||1.fc32
 Resolution|--- |RAWHIDE
   Assignee|ppi...@redhat.com   |jples...@redhat.com
Last Closed||2019-10-21 14:40:29



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Modularity and the system-upgrade path

[Orion Poplawski]

On 10/21/19 7:16 AM, Stephen John Smoogen wrote:

On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
 wrote:


On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:

If I were to start from scratch on this, I would look at the simplest
solution I would want from Boltron. I want to make it so a package team can
make a set of packages in a repository and work out how I can interact with
other repositories. I also want to easily build that package set in ways to
work on different versions of an operating system.


The question is whether this team wants to do the "heavy lifting"
(which might or might not actually be very heavy), of integrating with
the rest of the distro. If they don't, then Copr is the answer: it
provides all the answers, including automatic rebuilds.



The problem is that COPRs do not have any way of communicating with
each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I grab
from copr-B and it has libfoo-2.3.2-2 then I am going to replace
copr-A's packages which may break what I wanted from there. I am
saying that if we look at a way that they can clearly communicate
these problems to the user then we have fixed that.



FWIW, there is this old bug asking to express at least some kind of 
dependency between COPRs:

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

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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

[Bug 1763514] perl-CPAN-Perl-Releases-4.16 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-4.16-1.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-1999de2ae1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763515] perl-Module-CoreList-5.20191020 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Module-CoreList-5.20191020-1.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-f1dc5b736c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1762255] perl-Sub-Override for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2019-fd25f0e78a has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fd25f0e78a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763495] [RFE] EPEL-7 branch for perl-DateTime-Format-Natural

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|jples...@redhat.com |p...@city-fan.org



--- Comment #2 from Paul Howarth  ---
https://pagure.io/releng/fedora-scm-requests/issue/18613

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763497] [RFE] EPEL-6 and EPEL-7 branches for perl-Feed-Find

[bugzilla]

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



--- Comment #2 from Paul Howarth  ---
(In reply to Jitka Plesnikova from comment #1)
> I appreciate if you take care of the package for epel7.

https://pagure.io/releng/fedora-scm-requests/issue/18612

How about the el6 branch?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763494] [RFE] EPEL-7 branch for perl-Module-Util

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|jples...@redhat.com |p...@city-fan.org



--- Comment #2 from Paul Howarth  ---
https://pagure.io/releng/fedora-scm-requests/issue/18611

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763494] [RFE] EPEL-7 branch for perl-Module-Util

[bugzilla]

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



--- Comment #1 from Jitka Plesnikova  ---
I appreciate if you take care of the package for epel7.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763497] [RFE] EPEL-6 and EPEL-7 branches for perl-Feed-Find

[bugzilla]

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



--- Comment #1 from Jitka Plesnikova  ---
I appreciate if you take care of the package for epel7.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1763495] [RFE] EPEL-7 branch for perl-DateTime-Format-Natural

[bugzilla]

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



--- Comment #1 from Jitka Plesnikova  ---
I appreciate if you take care of the package for epel7.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Modularity and the system-upgrade path

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 21, 2019 at 03:36:53PM +0200, Fabio Valentini wrote:
> On Mon, Oct 21, 2019, 15:17 Stephen John Smoogen  wrote:
> 
> > On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
> > > > If I were to start from scratch on this, I would look at the simplest
> > > > solution I would want from Boltron. I want to make it so a package
> > team can
> > > > make a set of packages in a repository and work out how I can interact
> > with
> > > > other repositories. I also want to easily build that package set in
> > ways to
> > > > work on different versions of an operating system.
> > >
> > > The question is whether this team wants to do the "heavy lifting"
> > > (which might or might not actually be very heavy), of integrating with
> > > the rest of the distro. If they don't, then Copr is the answer: it
> > > provides all the answers, including automatic rebuilds.
> > >
> >
> > The problem is that COPRs do not have any way of communicating with
> > each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I grab
> > from copr-B and it has libfoo-2.3.2-2 then I am going to replace
> > copr-A's packages which may break what I wanted from there. I am
> > saying that if we look at a way that they can clearly communicate
> > these problems to the user then we have fixed that.
> >
> 
> Why not specify those requirements in RPM Requires? That's what they are
> for.

Exactly.

(Though, I don't think it is wise to build something complicated from
coprs — they are intended to allow the rules to be relaxed, but the obvious
corollary is that there is less stability and reliability. The rules we
have in the distro how packages must behave might be stiffling and annoying,
but they are there for a reason...)

> > Also there needs to be a way to communicate that an upgrade from F32
> > to F33 will break a system because copr-B has no F-33 packages.
> >
> 
> This already works somewhat, the only change that would be needed is
> setting skip_if_unavailable = false for COPR repos (I think they're set to
> true right now).
> 
> 
> > > If they do, and they invest in following the packaging guidelines and
> > > and the release cycles and whatever we say makes the package suitable
> > > for users and other packagers to build on, they get to put the package
> > > in the distro.
> > >
> >
> > From what I have heard over and over is that it isn't the packaging
> > guidelines which are a problem.. it is dealing with threads like this
> > or the continual drama churn we have. Investing in the OS means a lot
> > of emotional energy which a lot of people have no room for in our
> > current world. In some ways I see being able to bolt things into Coprs
> > as an escape from dealing with constant absolutes of 'your wrong!'
> > which most of our messages devolve to.

I consider our discussions to be technical and at a good level. Even
this thread: there have a been a few flare-ups, but that's just a handful,
and just people being tired and putting a few words in the wrong place
rather than any personal attack.

The problem is hard. If there was an obvious solution, we wouldn't be
having this discussion.

> >
> > The problem is that our current 20,000 packages is a LOT and most
> > software needs more than we actually have packaged. That means
> > continual growth, but our other needs of 'I need this as quickly as
> > possible', 'I expect you to have fixed all these things', etc are more
> > than most volunteers can deal with at this size. We end up shutting
> > down and yelling at each other because deep down we just want the
> > noise to stop.
> >
> 
> Yes, I agree, the current growth of the package set isn't sustainable if we
> don't also scale up the contributor base. I suspect that there are a few
> handfuls of packagers who maintain hundreds of packages, while the majority
> only maintains only a handful of packages. And relying on the
> "overcommitters" (pun intended) to keep the distro running isn't working so
> well.

I very much hope we can grow our packager base. Packaging in Fedora is
definitely harder than it used to be. We still haven't really recovered from
pkgdb retirement, various infra tools don't have enough support, etc.
No easy solutions to this problem either, but I think keeping packaging
simple (or at least not more complicated than it currently is).

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

Re: Modularity and the system-upgrade path

[Fabio Valentini]

On Mon, Oct 21, 2019, 15:17 Stephen John Smoogen  wrote:

> On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
> > > If I were to start from scratch on this, I would look at the simplest
> > > solution I would want from Boltron. I want to make it so a package
> team can
> > > make a set of packages in a repository and work out how I can interact
> with
> > > other repositories. I also want to easily build that package set in
> ways to
> > > work on different versions of an operating system.
> >
> > The question is whether this team wants to do the "heavy lifting"
> > (which might or might not actually be very heavy), of integrating with
> > the rest of the distro. If they don't, then Copr is the answer: it
> > provides all the answers, including automatic rebuilds.
> >
>
> The problem is that COPRs do not have any way of communicating with
> each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I grab
> from copr-B and it has libfoo-2.3.2-2 then I am going to replace
> copr-A's packages which may break what I wanted from there. I am
> saying that if we look at a way that they can clearly communicate
> these problems to the user then we have fixed that.
>

Why not specify those requirements in RPM Requires? That's what they are
for.


> Also there needs to be a way to communicate that an upgrade from F32
> to F33 will break a system because copr-B has no F-33 packages.
>

This already works somewhat, the only change that would be needed is
setting skip_if_unavailable = false for COPR repos (I think they're set to
true right now).


> > If they do, and they invest in following the packaging guidelines and
> > and the release cycles and whatever we say makes the package suitable
> > for users and other packagers to build on, they get to put the package
> > in the distro.
> >
>
> From what I have heard over and over is that it isn't the packaging
> guidelines which are a problem.. it is dealing with threads like this
> or the continual drama churn we have. Investing in the OS means a lot
> of emotional energy which a lot of people have no room for in our
> current world. In some ways I see being able to bolt things into Coprs
> as an escape from dealing with constant absolutes of 'your wrong!'
> which most of our messages devolve to.
>
> The problem is that our current 20,000 packages is a LOT and most
> software needs more than we actually have packaged. That means
> continual growth, but our other needs of 'I need this as quickly as
> possible', 'I expect you to have fixed all these things', etc are more
> than most volunteers can deal with at this size. We end up shutting
> down and yelling at each other because deep down we just want the
> noise to stop.
>

Yes, I agree, the current growth of the package set isn't sustainable if we
don't also scale up the contributor base. I suspect that there are a few
handfuls of packagers who maintain hundreds of packages, while the majority
only maintains only a handful of packages. And relying on the
"overcommitters" (pun intended) to keep the distro running isn't working so
well.

Fabio


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

Re: Modularity and the system-upgrade path

[Stephen John Smoogen]

On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
> > If I were to start from scratch on this, I would look at the simplest
> > solution I would want from Boltron. I want to make it so a package team can
> > make a set of packages in a repository and work out how I can interact with
> > other repositories. I also want to easily build that package set in ways to
> > work on different versions of an operating system.
>
> The question is whether this team wants to do the "heavy lifting"
> (which might or might not actually be very heavy), of integrating with
> the rest of the distro. If they don't, then Copr is the answer: it
> provides all the answers, including automatic rebuilds.
>

The problem is that COPRs do not have any way of communicating with
each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I grab
from copr-B and it has libfoo-2.3.2-2 then I am going to replace
copr-A's packages which may break what I wanted from there. I am
saying that if we look at a way that they can clearly communicate
these problems to the user then we have fixed that.

Also there needs to be a way to communicate that an upgrade from F32
to F33 will break a system because copr-B has no F-33 packages.

> If they do, and they invest in following the packaging guidelines and
> and the release cycles and whatever we say makes the package suitable
> for users and other packagers to build on, they get to put the package
> in the distro.
>

From what I have heard over and over is that it isn't the packaging
guidelines which are a problem.. it is dealing with threads like this
or the continual drama churn we have. Investing in the OS means a lot
of emotional energy which a lot of people have no room for in our
current world. In some ways I see being able to bolt things into Coprs
as an escape from dealing with constant absolutes of 'your wrong!'
which most of our messages devolve to.

The problem is that our current 20,000 packages is a LOT and most
software needs more than we actually have packaged. That means
continual growth, but our other needs of 'I need this as quickly as
possible', 'I expect you to have fixed all these things', etc are more
than most volunteers can deal with at this size. We end up shutting
down and yelling at each other because deep down we just want the
noise to stop.




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

Re: Fedora 32 System-Wide Change proposal: On-demand Side Tagsn

[Richard Shaw]

On Mon, Oct 21, 2019 at 2:23 AM Pierre-Yves Chibon 
wrote:

> On Sat, Oct 19, 2019 at 05:42:02PM -0700, Kevin Fenzi wrote:
> > On Sat, Oct 19, 2019 at 05:49:18PM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > > On Sat, Oct 19, 2019 at 03:52:03PM +0100, Richard W.M. Jones wrote:
> > > > On Fri, Oct 18, 2019 at 02:09:14PM -0400, Ben Cotton wrote:
> > > > > https://fedoraproject.org/wiki/Changes/OnDemandSideTags
> > > >
> > > > Nice idea.  Maybe I missed it, but I didn't see in the proposal if
> > > > there would be guidelines for naming the side tags so they don't
> > > > interfere with each other?
> > > >
> > > > For OCaml rebuilds they have been called ‘fNN-ocaml’ (NN = fedora
> > > > version), except where we needed to do further rebuilds in which case
> > > > we used ‘fNN-ocaml2’ etc.
> > >
> > > Good suggestion. I think even something like
> /-[-]
> > > could be a way to avoid accidental conflicts.
> >
> > The already implemented koji sidetag plugin and fedpkg integration lets
> > this be free-form, but you can search / list them by owner as well.
> >
> > So, yeah, fNN-something-descriptive would be good, and if you wanted to
> > coordinate you can list the user and ask them.
>
> The format adopted for rawhide gating is:
> fXX-build-side- where both X and Y are integers.
>
> Allowing arbitrary words in the side-tag names may results in security
> issues,
> cf: https://pagure.io/fedpkg/issue/329#comment-583078


The comment was only about usernames. I still think we need descriptive
text so at least the purpose of the side tag is clear.

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

Re: Modularity and the system-upgrade path

[Lukas Ruzicka]

>
>
>
> This has been working quite fine so far, so it would be bad to loose this
> capability, as the actual
> users in question are definitely not power users and will not be able to
> fix any of these issues
> by themselves.
>
>
+1, this was one of my points, too. I think that Fedora should be open for
users of all categories, not just
power users, but also newbies and similar species.



-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity and the system-upgrade path

[Martin Kolman]

On Fri, 2019-10-18 at 13:05 +0200, Lukas Ruzicka wrote:
> 
> > Or, even better (or worse): Sombody installs GIMP via GNOME Software,
> > 
> > and under the hood, dnf does its magic and installs gimp from the
> > 
> > module, which might depend on another, even non-default module, etc.
> > 
> > But then, what will happen when that module is EOL, and the user has
> > 
> > never even interacted with dnf, or modules? Will system upgrades break
> > 
> > and prompt the user to fix something they didn't even know existed,
> > 
> > and have never interacted with?
> 
> This has already happened. We have had complaints from people who had never
> installed any module, or used the "dnf module" command and they still ended 
> up with
> modules installed with a problem to upgrade their computers to F31.
This worries me quite a bit as people often install Fedora on computers of 
relatives and friendsin default configuration
& instruct the users to just "press the update button when it shows up".I've 
done that a couple times.
This has been working quite fine so far, so it would be bad to loose this 
capability, as the actualusers in question are
definitely not power users and will not be able to fix any of these issuesby 
themselves. 
Also from their point of view it's pretty much Fedora breaking if if a specific 
module is ta fault.And well, they are
not really wrong if a default Fedora install simply breaks upgrades at arandom 
point in the future...
>  
> > 
> > Fabio
> > 
> > 
> > 
> > > 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Stepping away from packaging (and request for owners)

[Jamie Nguyen]

I've been responding privately to people stepping up, to reduce noise.

Thank you to everyone who has volunteered so far :-)

FYI, nginx and tor/torsocks have new owners now. Felix (heffer) and
Marcel (maha) respectively.


Kind regards,

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

[Christopher Engelhard]

On 10/20/2019 11:28 AM, Zbigniew Jędrzejewski-Szmek wrote:
> Hi Christopher,
> 
> welcome to Fedora. sshguard review is more than enough for a first package,
> quite a complicated beast. I'll sponsor you into the packager group.
> 
> Zbyszek

Hi,
sorry for the late reply, I was away over the weekend. Thanks you for 
your trust, and again thanks to Michal Schorm, who was a big help during 
the review.

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

Re: Modularity and the system-upgrade path

[John M. Harris Jr]

On Thursday, October 17, 2019 4:28:27 PM MST Kevin Kofler wrote:
> Adam Williamson wrote:
> 
> > Of course if you just don't modularize FreeIPA at all you don't have
> > the kickstart problem, but then you *do* still have the 'we're stuck
> > shipping this one version of FreeIPA for the next seventy jillion
> > years' problem.
> 
> 
> That is purely a RHEL thing though. I do not see how this is relevant to the
>  discussion on whether to allow default streams *in Fedora*.

Even then, as a RHEL subscriber, I'd question its usefulness there. I use RHEL 
at work because I want a solid stable system without many changes in a release 
cycle. It makes is much easier with large deployments and high numbers of 
administrators/users, who may be resistant to change. Throwing a random new 
version of a package on there sounds like a nightmare.

Actually, I'm not even sure how I'd deploy modules in the environment that I 
support, because it doesn't have internet access. I usually just download the 
RHEL repo DVD and I'm good to go.

-- 
John M. Harris, Jr.
Splentity

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

Orphaning owncloud and nextcloud

[James Hogarth]

Hi all,

It's become clear that I haven't had the time I thought I'd have this past
year due to $life ...

These are in a bit of a broken state and right now I'd advise people that
need them to use upstream packages/containers.

I don't foresee sufficient time coming in the near future with family needs
in advance of hobbies like Fedora of course.

I'll give it a week or so for anyone to contact me who wants to pick them
up, otherwise I'll update pagure to assign them to "orphan"

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

Re: Modularity and the system-upgrade path

[Vít Ondruch]

Dne 18. 10. 19 v 17:04 Matthew Miller napsal(a):
> On Fri, Oct 18, 2019 at 01:03:24PM +0200, Lukas Ruzicka wrote:
>> Exactly ... this is what I believe, too. I think that Fedora users put
>> Fedora on their desktops and laptops to be creative in many ways of
>> creativity. Some make make music, some enhance pictures, some model in
>> Blender, cut videos, write documents. The majority, I dare to say, is not
>> interested in having several Inkscape versions, they want the newest yet
>> stable enough and they are satisfied with that.
> Well, maybe. Here's an actual Fedora story. A few releases ago, we had a
> designer working on a little animation promoting how trouble-free and
> painless Fedora updates are now (as a response to the "you should do an LTS,
> or a rolling release!" messages I often here).
>
> But, in the middle of making this, they updated themselves, and the new
> version of Inkscape dropped support for a feature (a file format, I think)
> that was very important to their work —  so they said that they couldn't
> continue making that ad in good conscience.
>
> If we had Inkscape as two streams, independent of the OS release, they could
> have opted to continue with the one that worked for them for a while longer
> at least.
>
>

... or the stream they used would go EOL at the same time they upgraded
and they would have no option. Even if it was not EOL, they would need
to fiddle with choosing the right module which is BTW not possible in
G-S if I am not mistaken.

I think we should be more careful about promoting modules and they
should be carefully considered.


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

Review swap: python-graph-tool (Was: Re: Packaging graph-tool: help speeding up build)

[Ankur Sinha]

Hello,

It finally built, and I have a review up here if anyone would like to
swap reviews:

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

Thanks for your help, everyone,

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Fedora 32 System-Wide Change proposal: On-demand Side Tagsn

[Pierre-Yves Chibon]

On Sat, Oct 19, 2019 at 05:42:02PM -0700, Kevin Fenzi wrote:
> On Sat, Oct 19, 2019 at 05:49:18PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sat, Oct 19, 2019 at 03:52:03PM +0100, Richard W.M. Jones wrote:
> > > On Fri, Oct 18, 2019 at 02:09:14PM -0400, Ben Cotton wrote:
> > > > https://fedoraproject.org/wiki/Changes/OnDemandSideTags
> > > 
> > > Nice idea.  Maybe I missed it, but I didn't see in the proposal if
> > > there would be guidelines for naming the side tags so they don't
> > > interfere with each other?
> > > 
> > > For OCaml rebuilds they have been called ‘fNN-ocaml’ (NN = fedora
> > > version), except where we needed to do further rebuilds in which case
> > > we used ‘fNN-ocaml2’ etc.
> > 
> > Good suggestion. I think even something like 
> > /-[-]
> > could be a way to avoid accidental conflicts.
> 
> The already implemented koji sidetag plugin and fedpkg integration lets
> this be free-form, but you can search / list them by owner as well. 
> 
> So, yeah, fNN-something-descriptive would be good, and if you wanted to
> coordinate you can list the user and ask them. 

The format adopted for rawhide gating is:
fXX-build-side- where both X and Y are integers.

Allowing arbitrary words in the side-tag names may results in security issues,
cf: https://pagure.io/fedpkg/issue/329#comment-583078


Pierre


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