[rpms/perl-IO-Handle-Util] New Commits To "rpms/perl-IO-Handle-Util" (f29)

[pagure]

The following commits were pushed to the repo rpms/perl-IO-Handle-Util on branch
f29, which you are following:
a58be23ad69c2e2f09cbf32352f3553c7d97446eRalf CorsépiusUpdate to 0.02. 
Switch to Build.PL. Rework deps. Modernize spec.



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-IO-Handle-Util/commits/f29
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[389-devel] please review: Ticket 49926 - Add replication functionality to UI

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/49976
___
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: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[rpms/perl-IO-Handle-Util] New Commits To "rpms/perl-IO-Handle-Util" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-IO-Handle-Util on branch
master, which you are following:
a58be23ad69c2e2f09cbf32352f3553c7d97446eRalf CorsépiusUpdate to 0.02. 
Switch to Build.PL. Rework deps. Modernize spec.



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-IO-Handle-Util/commits/master
___
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://getfedora.org/code-of-conduct.html
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: Profiling discussion

[William Brown]

On Fri, 2018-10-12 at 21:39 -0400, Mark Reynolds wrote:
> On 10/10/18 6:57 PM, William Brown wrote:
> > On Wed, 2018-10-10 at 16:26 +0200, thierry bordaz wrote:
> > > Hi William,
> > > 
> > > Thanks for starting this discussion.
> > > Your email raise several aspects (How, for whom,..) and I think a
> > > way
> > > to
> > > start would be to write down what we want.
> > > A need is from a given workload to determine where we are
> > > spending
> > > time
> > > as a way to determine where to invest.
> > > An other need is to collect metrics at operation level.
> > 
> > Aren't these very similar? The time we invest is generally on
> > improving
> > a plugin or a small part of an operation, to make the operation as
> > a
> > whole faster.
> > 
> > So if we can report on an individual operation, we can write a tool
> > similar to log-conv.pl, but for performance metrics that displays
> > trends of operations that are not performaning well, then we can
> > find
> > examples of operations and why.
> > 
> > >   From the how perspective, we can rely on external tools
> > > (stap+scripts),
> > > or internal tool (like the plugin you described+scripts). Of
> > > course
> > > we
> > > can also do some enhancements inside DS (like adding probes) to
> > > help
> > > external tools. I have no strong opinion if an approach is better
> > > than
> > > the other but I think it also depends what you want to perform.
> > 
> > I think that it would be great if the tools we use internal to the
> > team, were accessible outside to admins of ds. That way when we get
> > reports for performance concerns, we have a standardised way of
> > looking
> > at this. It's going to mean our workflow is the same between
> > internal
> > development and profiling, as for external reports, and it will
> > force
> > us to have all the information we need in that one place.
> > 
> > I think as a coarse first metric internal event timings is probably
> > want we want first. After that we can continue to extend from
> > there?
> > 
> > As for the how, perhaps we can put something on the Operation
> > struct
> > for appending and logging events and turning those into metrics?
> > 
> > As mentioned you could use stap too with defined points for
> > tracing,
> > but that limits us to linux only?
> 
> Whatever tools we use doesn't really concern me - as long as we get
> good 
> data.  Somewhere we have old reports from stap pointing out lock 
> contention problem areas, but we should really rerun all of those
> tests 
> with the current code base. 

I think those tests did not properly check atomic usage nor different
lock types ... 

>  As for improving performance I think we 
> should first address the major issues found by the existing tools
> (stap 
> and friends) - specifically the lock contention problems (config, 
> connections, attr syntax checking, etc).  Once these are addressed
> then 
> we can start adding probes/internal structs to fine tune other
> aspects 
> of the server.

I think the information we have from current tools isn't complete, and
it doesn't help us when people give us reports of the server being
slow. We really need to invest in observability into performance, so
that long term we get better views into what exactly the issues are.
That's why I think we should look at this tooling/logging first. 

> 
> Improving performance will be the primary focus for 389-ds-base-
> 1.4.1, 
> and we should be able invest a good amount of time into this
> effort.  
> Getting nunc-stans stable falls into this category as well (it
> should 
> actually be addressed first).

There is a patch awaiting review for this topic ... :) 

> 
> Mark
> 
> > 
> > > best regards
> > > thierry
> > > 
> > > On 10/08/2018 12:37 PM, William Brown wrote:
> > > > Hi there,
> > > > 
> > > > In a ticket Thierry and I mentioned that we should have a quick
> > > > discussion about ideas for profiling and what we want it to
> > > > look
> > > > like and what we need. I think it’s important we improve our
> > > > observation into the server so that we can target improvements
> > > > correctly,
> > > > 
> > > > I think we should know:
> > > > 
> > > > * Who is the target audience to run our profiling tools?
> > > > * What kind of information we do want?
> > > > * Potential solution for the above.
> > > > 
> > > > With those in mind I think that Thierry suggested STAP scripts.
> > > > 
> > > > * Target audience - developers (us) and some “highly
> > > > experienced”
> > > > admins (STAP is not the easiest thing to run).
> > > > * Information - STAP would largely tell us timing and possibly
> > > > allows some variable/struct extraction. STAP does allow us to
> > > > look
> > > > at connection info too a bit easier.
> > > > 
> > > > I would suggest an “event” struct, and logging service
> > > > 
> > > > At the start of an operation we create an event struct. As we
> > > > enter
> > > > - exit a plugin we can append timing information, and the
> > > > plugin
> > > > 

[389-devel] Re: Profiling discussion

[Mark Reynolds]

On 10/12/18 9:52 PM, William Brown wrote:

On Fri, 2018-10-12 at 21:39 -0400, Mark Reynolds wrote:

On 10/10/18 6:57 PM, William Brown wrote:

On Wed, 2018-10-10 at 16:26 +0200, thierry bordaz wrote:

Hi William,

Thanks for starting this discussion.
Your email raise several aspects (How, for whom,..) and I think a
way
to
start would be to write down what we want.
A need is from a given workload to determine where we are
spending
time
as a way to determine where to invest.
An other need is to collect metrics at operation level.

Aren't these very similar? The time we invest is generally on
improving
a plugin or a small part of an operation, to make the operation as
a
whole faster.

So if we can report on an individual operation, we can write a tool
similar to log-conv.pl, but for performance metrics that displays
trends of operations that are not performaning well, then we can
find
examples of operations and why.


   From the how perspective, we can rely on external tools
(stap+scripts),
or internal tool (like the plugin you described+scripts). Of
course
we
can also do some enhancements inside DS (like adding probes) to
help
external tools. I have no strong opinion if an approach is better
than
the other but I think it also depends what you want to perform.

I think that it would be great if the tools we use internal to the
team, were accessible outside to admins of ds. That way when we get
reports for performance concerns, we have a standardised way of
looking
at this. It's going to mean our workflow is the same between
internal
development and profiling, as for external reports, and it will
force
us to have all the information we need in that one place.

I think as a coarse first metric internal event timings is probably
want we want first. After that we can continue to extend from
there?

As for the how, perhaps we can put something on the Operation
struct
for appending and logging events and turning those into metrics?

As mentioned you could use stap too with defined points for
tracing,
but that limits us to linux only?

Whatever tools we use doesn't really concern me - as long as we get
good
data.  Somewhere we have old reports from stap pointing out lock
contention problem areas, but we should really rerun all of those
tests
with the current code base.

I think those tests did not properly check atomic usage nor different
lock types ...

Not sure, haven't looked at stap or the older reports in some time.



  As for improving performance I think we
should first address the major issues found by the existing tools
(stap
and friends) - specifically the lock contention problems (config,
connections, attr syntax checking, etc).  Once these are addressed
then
we can start adding probes/internal structs to fine tune other
aspects
of the server.

I think the information we have from current tools isn't complete, and
it doesn't help us when people give us reports of the server being
slow. We really need to invest in observability into performance, so
that long term we get better views into what exactly the issues are.
That's why I think we should look at this tooling/logging first.
Yes perhaps, but the issues reported by these tools are still valid - 
although they might not be the main culprits as you are suggesting.



Improving performance will be the primary focus for 389-ds-base-
1.4.1,
and we should be able invest a good amount of time into this
effort.
Getting nunc-stans stable falls into this category as well (it
should
actually be addressed first).

There is a patch awaiting review for this topic ... :)
I know, I have asked for this patch to be tested internally, but that 
hasn't happened yet.  I will follow up on that next week!
  


Mark


best regards
thierry

On 10/08/2018 12:37 PM, William Brown wrote:

Hi there,

In a ticket Thierry and I mentioned that we should have a quick
discussion about ideas for profiling and what we want it to
look
like and what we need. I think it’s important we improve our
observation into the server so that we can target improvements
correctly,

I think we should know:

* Who is the target audience to run our profiling tools?
* What kind of information we do want?
* Potential solution for the above.

With those in mind I think that Thierry suggested STAP scripts.

* Target audience - developers (us) and some “highly
experienced”
admins (STAP is not the easiest thing to run).
* Information - STAP would largely tell us timing and possibly
allows some variable/struct extraction. STAP does allow us to
look
at connection info too a bit easier.

I would suggest an “event” struct, and logging service

At the start of an operation we create an event struct. As we
enter
- exit a plugin we can append timing information, and the
plugin
itself can add details (for example, backend could add idl
performance metrics or other). At the end of the operation, we
log
the event struct as a json blob to our access log associated to
the
conn/op.

* Target - anyone, it’s a log level. 

Re: Fedora 29 Final Go/No-Go meeting

[Adam Williamson]

On Fri, 2018-10-12 at 19:52 -0700, Adam Williamson wrote:
> On Fri, 2018-10-12 at 20:08 -0600, Trever L. Adams wrote:
> > On 10/12/18 9:27 AM, Ben Cotton wrote:
> > > Dear all,
> > > 
> > > The Go/No-Go meeting for the Fedora 29 Final release will be held on
> > > Thursday, 2018-10-18 at 17:00 UTC in #fedora-meeting-1. For more
> > > information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting
> > > 
> > > View the meeting on Fedocal at
> > > https://apps.fedoraproject.org/calendar/Fedora%20release/2018/10/18/#m9379
> > > 
> > I am not part of the groups that are at these meetings. Please, consider
> > Bug #1636811 about FreeRadius. It is a simple fix.
> 
> Anyone is free to show up to these meetings (and any other Fedora
> meeting), but the go/no-go is too late to be considering non-blocker
> fixes.

Oh, also, as a packager, you certainly count as part of "Development".
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 29 Final Go/No-Go meeting

[Adam Williamson]

On Fri, 2018-10-12 at 20:08 -0600, Trever L. Adams wrote:
> On 10/12/18 9:27 AM, Ben Cotton wrote:
> > Dear all,
> > 
> > The Go/No-Go meeting for the Fedora 29 Final release will be held on
> > Thursday, 2018-10-18 at 17:00 UTC in #fedora-meeting-1. For more
> > information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting
> > 
> > View the meeting on Fedocal at
> > https://apps.fedoraproject.org/calendar/Fedora%20release/2018/10/18/#m9379
> > 
> I am not part of the groups that are at these meetings. Please, consider
> Bug #1636811 about FreeRadius. It is a simple fix.

Anyone is free to show up to these meetings (and any other Fedora
meeting), but the go/no-go is too late to be considering non-blocker
fixes.

You can propose the bug for an FE if you like, by just making it block
'FinalFreezeException', or using
https://qa.fedoraproject.org/blockerbugs/propose_bug . But there needs
to be a reason the fix has to go into the compose, rather than just
going out as a 0-day update: is freeradius included in and usable frm
any of the live images, for instance?

There will be a blocker/FE review meeting on Monday, so any proposals
will be considered then.
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 29 Final Go/No-Go meeting

[Trever L. Adams]

On 10/12/18 9:27 AM, Ben Cotton wrote:
> Dear all,
>
> The Go/No-Go meeting for the Fedora 29 Final release will be held on
> Thursday, 2018-10-18 at 17:00 UTC in #fedora-meeting-1. For more
> information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting
>
> View the meeting on Fedocal at
> https://apps.fedoraproject.org/calendar/Fedora%20release/2018/10/18/#m9379
>
I am not part of the groups that are at these meetings. Please, consider
Bug #1636811 about FreeRadius. It is a simple fix.




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

[389-devel] Re: Profiling discussion

[William Brown]

On Fri, 2018-10-12 at 21:39 -0400, Mark Reynolds wrote:
> On 10/10/18 6:57 PM, William Brown wrote:
> > On Wed, 2018-10-10 at 16:26 +0200, thierry bordaz wrote:
> > > Hi William,
> > > 
> > > Thanks for starting this discussion.
> > > Your email raise several aspects (How, for whom,..) and I think a
> > > way
> > > to
> > > start would be to write down what we want.
> > > A need is from a given workload to determine where we are
> > > spending
> > > time
> > > as a way to determine where to invest.
> > > An other need is to collect metrics at operation level.
> > 
> > Aren't these very similar? The time we invest is generally on
> > improving
> > a plugin or a small part of an operation, to make the operation as
> > a
> > whole faster.
> > 
> > So if we can report on an individual operation, we can write a tool
> > similar to log-conv.pl, but for performance metrics that displays
> > trends of operations that are not performaning well, then we can
> > find
> > examples of operations and why.
> > 
> > >   From the how perspective, we can rely on external tools
> > > (stap+scripts),
> > > or internal tool (like the plugin you described+scripts). Of
> > > course
> > > we
> > > can also do some enhancements inside DS (like adding probes) to
> > > help
> > > external tools. I have no strong opinion if an approach is better
> > > than
> > > the other but I think it also depends what you want to perform.
> > 
> > I think that it would be great if the tools we use internal to the
> > team, were accessible outside to admins of ds. That way when we get
> > reports for performance concerns, we have a standardised way of
> > looking
> > at this. It's going to mean our workflow is the same between
> > internal
> > development and profiling, as for external reports, and it will
> > force
> > us to have all the information we need in that one place.
> > 
> > I think as a coarse first metric internal event timings is probably
> > want we want first. After that we can continue to extend from
> > there?
> > 
> > As for the how, perhaps we can put something on the Operation
> > struct
> > for appending and logging events and turning those into metrics?
> > 
> > As mentioned you could use stap too with defined points for
> > tracing,
> > but that limits us to linux only?
> 
> Whatever tools we use doesn't really concern me - as long as we get
> good 
> data.  Somewhere we have old reports from stap pointing out lock 
> contention problem areas, but we should really rerun all of those
> tests 
> with the current code base.

I think those tests did not properly check atomic usage nor different
lock types ... 

>   As for improving performance I think we 
> should first address the major issues found by the existing tools
> (stap 
> and friends) - specifically the lock contention problems (config, 
> connections, attr syntax checking, etc).  Once these are addressed
> then 
> we can start adding probes/internal structs to fine tune other
> aspects 
> of the server.

I think the information we have from current tools isn't complete, and
it doesn't help us when people give us reports of the server being
slow. We really need to invest in observability into performance, so
that long term we get better views into what exactly the issues are.
That's why I think we should look at this tooling/logging first so that
our time is well spent when we make fixes.

> 
> Improving performance will be the primary focus for 389-ds-base-
> 1.4.1, 
> and we should be able invest a good amount of time into this
> effort.  
> Getting nunc-stans stable falls into this category as well (it
> should 
> actually be addressed first).

There is a patch awaiting review for this topic ... :) 

> 
> Mark
> 
> > 
> > > best regards
> > > thierry
> > > 
> > > On 10/08/2018 12:37 PM, William Brown wrote:
> > > > Hi there,
> > > > 
> > > > In a ticket Thierry and I mentioned that we should have a quick
> > > > discussion about ideas for profiling and what we want it to
> > > > look
> > > > like and what we need. I think it’s important we improve our
> > > > observation into the server so that we can target improvements
> > > > correctly,
> > > > 
> > > > I think we should know:
> > > > 
> > > > * Who is the target audience to run our profiling tools?
> > > > * What kind of information we do want?
> > > > * Potential solution for the above.
> > > > 
> > > > With those in mind I think that Thierry suggested STAP scripts.
> > > > 
> > > > * Target audience - developers (us) and some “highly
> > > > experienced”
> > > > admins (STAP is not the easiest thing to run).
> > > > * Information - STAP would largely tell us timing and possibly
> > > > allows some variable/struct extraction. STAP does allow us to
> > > > look
> > > > at connection info too a bit easier.
> > > > 
> > > > I would suggest an “event” struct, and logging service
> > > > 
> > > > At the start of an operation we create an event struct. As we
> > > > enter
> > > > - exit a plugin we can append 

[389-devel] Re: Profiling discussion

[Mark Reynolds]

On 10/10/18 6:57 PM, William Brown wrote:

On Wed, 2018-10-10 at 16:26 +0200, thierry bordaz wrote:

Hi William,

Thanks for starting this discussion.
Your email raise several aspects (How, for whom,..) and I think a way
to
start would be to write down what we want.
A need is from a given workload to determine where we are spending
time
as a way to determine where to invest.
An other need is to collect metrics at operation level.

Aren't these very similar? The time we invest is generally on improving
a plugin or a small part of an operation, to make the operation as a
whole faster.

So if we can report on an individual operation, we can write a tool
similar to log-conv.pl, but for performance metrics that displays
trends of operations that are not performaning well, then we can find
examples of operations and why.


  From the how perspective, we can rely on external tools
(stap+scripts),
or internal tool (like the plugin you described+scripts). Of course
we
can also do some enhancements inside DS (like adding probes) to help
external tools. I have no strong opinion if an approach is better
than
the other but I think it also depends what you want to perform.

I think that it would be great if the tools we use internal to the
team, were accessible outside to admins of ds. That way when we get
reports for performance concerns, we have a standardised way of looking
at this. It's going to mean our workflow is the same between internal
development and profiling, as for external reports, and it will force
us to have all the information we need in that one place.

I think as a coarse first metric internal event timings is probably
want we want first. After that we can continue to extend from there?

As for the how, perhaps we can put something on the Operation struct
for appending and logging events and turning those into metrics?

As mentioned you could use stap too with defined points for tracing,
but that limits us to linux only?


Whatever tools we use doesn't really concern me - as long as we get good 
data.  Somewhere we have old reports from stap pointing out lock 
contention problem areas, but we should really rerun all of those tests 
with the current code base.  As for improving performance I think we 
should first address the major issues found by the existing tools (stap 
and friends) - specifically the lock contention problems (config, 
connections, attr syntax checking, etc).  Once these are addressed then 
we can start adding probes/internal structs to fine tune other aspects 
of the server.


Improving performance will be the primary focus for 389-ds-base-1.4.1, 
and we should be able invest a good amount of time into this effort.  
Getting nunc-stans stable falls into this category as well (it should 
actually be addressed first).


Mark




best regards
thierry

On 10/08/2018 12:37 PM, William Brown wrote:

Hi there,

In a ticket Thierry and I mentioned that we should have a quick
discussion about ideas for profiling and what we want it to look
like and what we need. I think it’s important we improve our
observation into the server so that we can target improvements
correctly,

I think we should know:

* Who is the target audience to run our profiling tools?
* What kind of information we do want?
* Potential solution for the above.

With those in mind I think that Thierry suggested STAP scripts.

* Target audience - developers (us) and some “highly experienced”
admins (STAP is not the easiest thing to run).
* Information - STAP would largely tell us timing and possibly
allows some variable/struct extraction. STAP does allow us to look
at connection info too a bit easier.

I would suggest an “event” struct, and logging service

At the start of an operation we create an event struct. As we enter
- exit a plugin we can append timing information, and the plugin
itself can add details (for example, backend could add idl
performance metrics or other). At the end of the operation, we log
the event struct as a json blob to our access log associated to the
conn/op.

* Target - anyone, it’s a log level. Really easy to enable (Think
mailing list or user support, can easily send us diagnostic logs)
* Information - we need a bit more work to structure the “event”
struct internally for profiling, but we’d get timings and possibly
internal variable data as well in the event.


I think these are two possible approaches. STAP is less invasive,
easier to start now, but harder to extend later. Logging is more
accessible to users/admins, easier to extend later, but more work
to add now.

What do we think?


—
Sincerely,

William


___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@lists.fedoraproject
.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidel
ines
List Archives: 

Re: Installation image layout

[Chris Murphy]

On Fri, Oct 12, 2018 at 3:44 PM, Chris Murphy  wrote:
> On Fri, Oct 12, 2018 at 4:30 AM, Marek Marczykowski-Górecki
>  wrote:
>> On Thu, Oct 11, 2018 at 09:24:08PM -0600, Chris Murphy wrote:
>
>>> I'm pretty sure the original reason was the default live install use
>>> dd to block copy the root file system into the fedora-root LV, and
>>> then resized the LV and ext4 file system.
>>
>> How is it done now?
>
> On Live media installs, anaconda does:
>
> rsync -pogAXtlHrDx --exclude /dev/ --exclude /proc/ --exclude /sys/
> --exclude /run/ --exclude /boot/*rescue* --exclude /etc/machine-id
> /mnt/install/source/ /mnt/sysimage
>
> On DVD and netinstalls, I'm guessing based on packaging.log that it's
> a dnf+rpm installation even though I never see a dnf or rpm process in
> either top or ps. In any case, the rpm packages are directly on the
> iso9660 file system, not baked into the

One other thing that really hogs system resources for some reason, is
one of the loopback mount devices, I think loop1 which is root.img,
hogs nearly 100% CPU for the duration of the installation for LiveOS
media. I don't know why, but it might be worth benchmarking nbd based
mounts for comparison. The installation turns my computers into hair
dryers. The installation process bottleneck should be reading the
compressed root image, not CPU.



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

Re: Installation image layout

[Marek Marczykowski-Górecki]

On Fri, Oct 12, 2018 at 03:44:38PM -0600, Chris Murphy wrote:
> On Fri, Oct 12, 2018 at 4:30 AM, Marek Marczykowski-Górecki
>  wrote:
> > On Thu, Oct 11, 2018 at 09:24:08PM -0600, Chris Murphy wrote:
> >> Why does efiboot.img have a 32MiB limit?
> >
> > Because "32MB should be enough for everybody"...
> > Long story short, "El Torito" boot catalog structure have 16-bit field
> > for image size (expressed in 512-bytes sectors). For details see here:
> > https://wiki.osdev.org/El-Torito
> > https://web.archive.org/web/20180112220141/https://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf
> > (page 10)
> 
> OK. On Fedora 28 media, efiboot.img is ~9.2 MiB and does not contain
> either the kernel or initramfs.

I know, this particular problem was specific to Qubes OS, where
kernel+initramfs needed to be on ESP, because of Xen+EFI limitation
(basically kernel needs to be loaded through through UEFI instead of
by grub, so it needs to live on something that UEFI understands). And
actually recent Xen version doesn't have this limitation anymore (at
least in theory...). This is just a bit of context from where it all
got here, much less relevant today.

(...)

> > Full story:
> > https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-135988806
> >
> > I've spent a lot of time debugging this, because mkisofs doesn't
> > complain about it, just silently overflow higher bits to adjacent field,
> > which results in weird results, depending on where you boot it. Adding
> > isohybrid to the picture doesn't make it easier (there, higher bits are
> > truncated, or actually not copied to the MBR partition table, as wasn't
> > part of the original field).
> 
> 
> I think we're stuck with isohybrid for a while. Having UEFI and BIOS
> bootloaders, along with isohybrid supporting both as well as Macs, all
> on one media image, that can be burned to optical media and written to
> a USB stick - is hugely beneficial.

I have no problem with isohybrid alone. It's major hack, but definitely
worth it.

> The compose process takes about 12 hours. That every ISO for all the
> editions, and the spins, and the VM images, for all archs. Even having
> separate UEFI and BIOS images, or splitting out Macs with their own
> image, it'll increase compose times and complexity across the board.

And also complexity for the users - which image to download. I totally
understand why it is beneficial.

(...)

> >> I did give all of these things some thought a long time ago when I ran
> >> into a lorax hack by Will Woods who used Btrfs as the root.img file
> >> system, I'm not sure why it was used. But it gave me the idea of using
> >> a few features built into Btrfs specifically for this use case:
> >>
> >> - seed/sprout feature can be used with zram block device for volatile
> >> overlay; and used with a blank partition on the stick for persistent
> >> overlay. Discovery is part of the btrfs kernel code.
> >>
> >> - Since metadata and data is always checksummed on every read, we
> >> wouldn't have to depend on the slow and transient ISO checksum
> >> (rd.live.check which uses checkisomd5) which likewise breaks when
> >> creating a stick with livecd-iso-to-disk.
> >>
> >> - Btrfs supports zstd compression. I did some testing and squashfs is
> >> still a bit more efficient because it compresses fs metadata, whereas
> >> Btrfs only compresses data extents.
> >>
> >> The gotcha here is the resulting image isn't going to be bit for bit
> >> reproducible: UUIDs and time stamps are strewn throughout the file
> >> system (similar to ext4 and XFS), but any sufficiently complex file
> >> system is going to have this problem.
> >
> > I wouldn't worry about _files_ timestamps that much - in most cases this is
> > solvable problem by elaborate enough find+touch[4]. But that's not all
> > obviously, there are various timestamps in superblock, and other
> > metadata. The most problematic part in "normal" filesystems, using
> > kernel driver is inode allocation, block allocation etc. This greatly
> > depends on timing, ordering, specific kernel version etc.
> > See [5] for details.
> 
> 
> mkfs.btrfs has --rootdir and --shrink features to pre-allocate a
> volume with files at mkfs time; I have no idea to what degree it
> depends on kernel code. 

Probably not at all, given it works as non-root user too.
I've tried to run it twice on the same directory (and with the same
--uuid) on 32MB of data and got different images (~2000 lines of hexdump
diff). Could be some timestamps, could be something else.

> The main benefit with this is it's really easy
> to implement full checksum matching for metadata and data on every
> read, and user space ends up with EIO instead of corrupt data, and
> super clear kernel complaints. And such corruption whether on optical
> or USB sticks, is common. Even the more rare case of a stick that
> passes md5 checksum, can later have transient and silent corruption
> that ends up showing up in weird ways.
> 
> It's 

Re: Installation image layout

[Adam Williamson]

On Fri, 2018-10-12 at 15:44 -0600, Chris Murphy wrote:
> On Fri, Oct 12, 2018 at 4:30 AM, Marek Marczykowski-Górecki
>  wrote:
> > On Thu, Oct 11, 2018 at 09:24:08PM -0600, Chris Murphy wrote:
> > > I'm pretty sure the original reason was the default live install use
> > > dd to block copy the root file system into the fedora-root LV, and
> > > then resized the LV and ext4 file system.
> > 
> > How is it done now?
> 
> On Live media installs, anaconda does:
> 
> rsync -pogAXtlHrDx --exclude /dev/ --exclude /proc/ --exclude /sys/
> --exclude /run/ --exclude /boot/*rescue* --exclude /etc/machine-id
> /mnt/install/source/ /mnt/sysimage
> 
> On DVD and netinstalls, I'm guessing based on packaging.log that it's
> a dnf+rpm installation even though I never see a dnf or rpm process in
> either top or ps. In any case, the rpm packages are directly on the
> iso9660 file system, not baked into the

anaconda uses dnf's python interface, it does not *run* 'dnf'.

https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/payload/dnfpayload.py
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 29-20181012.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 11/133 (x86_64), 1/2 (arm)

ID: 294742  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/294742
ID: 294756  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/294756
ID: 294759  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/294759
ID: 294768  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/294768
ID: 294779  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/294779
ID: 294797  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/294797
ID: 294801  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/294801
ID: 294819  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/294819
ID: 294833  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/294833
ID: 294836  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/294836
ID: 294858  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/294858
ID: 294875  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/294875

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

ID: 294763  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/294763
ID: 294764  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/294764
ID: 294790  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/294790
ID: 294847  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/294847

Passed openQA tests: 114/133 (x86_64), 22/24 (i386)

Skipped openQA tests: 1 of 159
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Installation image layout

[Chris Murphy]

On Fri, Oct 12, 2018 at 4:30 AM, Marek Marczykowski-Górecki
 wrote:
> On Thu, Oct 11, 2018 at 09:24:08PM -0600, Chris Murphy wrote:

>> I'm pretty sure the original reason was the default live install use
>> dd to block copy the root file system into the fedora-root LV, and
>> then resized the LV and ext4 file system.
>
> How is it done now?

On Live media installs, anaconda does:

rsync -pogAXtlHrDx --exclude /dev/ --exclude /proc/ --exclude /sys/
--exclude /run/ --exclude /boot/*rescue* --exclude /etc/machine-id
/mnt/install/source/ /mnt/sysimage

On DVD and netinstalls, I'm guessing based on packaging.log that it's
a dnf+rpm installation even though I never see a dnf or rpm process in
either top or ps. In any case, the rpm packages are directly on the
iso9660 file system, not baked into the



>> Why does efiboot.img have a 32MiB limit?
>
> Because "32MB should be enough for everybody"...
> Long story short, "El Torito" boot catalog structure have 16-bit field
> for image size (expressed in 512-bytes sectors). For details see here:
> https://wiki.osdev.org/El-Torito
> https://web.archive.org/web/20180112220141/https://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf
> (page 10)

OK. On Fedora 28 media, efiboot.img is ~9.2 MiB and does not contain
either the kernel or initramfs. The kernel and initramfs are found on
the iso9660 file system at images/pxeboot/ and also at isolinux/ where
GRUB UEFI uses the former, and isolinux BIOS uses the latter. Both
initrd's are 65M so they're already too big to go into bootefi.img -
and they kinda need to be because this particular initramfs is built
by dracut with --nohostonly flag so that hopefully we can boot
anything. (Curiously, the initramfs is 65M on DVD/netinstall and 50M
on LiveOS - I don't have an explanation for that. I'm looking at
Fedora 28 release images.)

From my understanding, efiboot.img only would need to contain shim,
grubia32, grubx64 and supporting bootloader only files.

BTW, trivia: Fedora's installer creates EFI System partitions that are
always FAT16. So far as I know, no computer has complained, only
humans. FAT12/16 is OK for removable media but the spec pretty clearly
expects FAT32 for ESPs on permanent installs. The installer team
doesn't want to use mkfs flags, they expect the defaults to work
unless they don't work, and they do work, so FAT16 it is.



> Full story:
> https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-135988806
>
> I've spent a lot of time debugging this, because mkisofs doesn't
> complain about it, just silently overflow higher bits to adjacent field,
> which results in weird results, depending on where you boot it. Adding
> isohybrid to the picture doesn't make it easier (there, higher bits are
> truncated, or actually not copied to the MBR partition table, as wasn't
> part of the original field).


I think we're stuck with isohybrid for a while. Having UEFI and BIOS
bootloaders, along with isohybrid supporting both as well as Macs, all
on one media image, that can be burned to optical media and written to
a USB stick - is hugely beneficial.

The compose process takes about 12 hours. That every ISO for all the
editions, and the spins, and the VM images, for all archs. Even having
separate UEFI and BIOS images, or splitting out Macs with their own
image, it'll increase compose times and complexity across the board.
I'm not sure which happens first: the end to optical media booting
support; or dropping support for BIOS and/or old Apple EFI Macs (only
this year did they start using UEFI, rather than their own variant of
Intel EFI pre-UEFI, so it'll take some time to see how that shakes out
which also involves whether and how Secure Boot can ever be supported
on Macs).

This talks a bit about isohybrid and all the very clever hacks
involved to make Fedora boot practically anything with a single ISO
9660 image. (I'm being x86_64 arch specific when I say that.)

https://mjg59.dreamwidth.org/11285.html



>>
>> I did give all of these things some thought a long time ago when I ran
>> into a lorax hack by Will Woods who used Btrfs as the root.img file
>> system, I'm not sure why it was used. But it gave me the idea of using
>> a few features built into Btrfs specifically for this use case:
>>
>> - seed/sprout feature can be used with zram block device for volatile
>> overlay; and used with a blank partition on the stick for persistent
>> overlay. Discovery is part of the btrfs kernel code.
>>
>> - Since metadata and data is always checksummed on every read, we
>> wouldn't have to depend on the slow and transient ISO checksum
>> (rd.live.check which uses checkisomd5) which likewise breaks when
>> creating a stick with livecd-iso-to-disk.
>>
>> - Btrfs supports zstd compression. I did some testing and squashfs is
>> still a bit more efficient because it compresses fs metadata, whereas
>> Btrfs only compresses data extents.
>>
>> The gotcha here is the resulting image isn't going to be bit for bit

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 125  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c   
unrtf-0.21.9-8.el6
  63  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f21474267b   
condor-8.6.11-1.el6
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6bc3a525a2   
libmad-0.15.1b-26.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-83a8fcf606   
gnutls30-3.5.19-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-972fa9738c   
php-horde-nag-4.2.19-1.el6


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

holland-1.1.8-2.el6

Details about builds:



 holland-1.1.8-2.el6 (FEDORA-EPEL-2018-94ec6e1b9e)
 Pluggable Backup Framework

Update Information:

Latest upstream change xtrabackup require to /usr/bin/xtrabackup

ChangeLog:

* Thu Oct 11 2018 Pete Travis  - 1.1.8-2
- Latest upstream
- change requires for xtrabackup subpackage to path to allow for alternative 
sources

References:

  [ 1 ] Bug #1638464 - holland-xtrabackup dependency issues in version 1.1.7 on 
EL7
https://bugzilla.redhat.com/show_bug.cgi?id=1638464
  [ 2 ] Bug #1638541 - holland-1.1.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1638541

___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 125  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a   
unrtf-0.21.9-8.el7
  75  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a   
bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7
  58  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
  50  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3a3c72c5e5   
chromium-68.0.3440.106-3.el7
  31  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3492a96896   
myrepos-1.20180726-1.el7
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc87c43cdd   
libbson-1.3.5-6.el7
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c906338b6b   
libmad-0.15.1b-26.el7
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f13feb5e4b   
sensible-utils-0.0.12-2.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-59650a08fe   
zchunk-0.9.11-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aa0030f9a1   
php-horde-nag-4.2.19-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e8e2e2acac   
strongswan-5.7.1-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6e8b488d2   
clamav-0.100.2-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a9ac6a18d2   
libgit2-0.26.7-1.el7


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

GMT-5.4.4-3.el7
holland-1.1.8-2.el7
knot-2.6.9-2.el7

Details about builds:



 GMT-5.4.4-3.el7 (FEDORA-EPEL-2018-b299d8284b)
 Generic Mapping Tools

Update Information:

- Update to 5.4.4 - Fix finding coastline data files

ChangeLog:

* Thu Oct 11 2018 Orion Poplawski  - 5.4.4-3
- Install coastline data location config file (bug #1545256)
* Tue Jul 31 2018 Florian Weimer  - 5.4.4-2
- Rebuild with fixed binutils
* Sun Jul 29 2018 Orion Poplawski  - 5.4.4-1
- Update to 5.4.4
* Thu Jul 12 2018 Fedora Release Engineering  - 
5.4.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

References:

  [ 1 ] Bug #1545256 - gmt   cannot find  gshhg files
https://bugzilla.redhat.com/show_bug.cgi?id=1545256
  [ 2 ] Bug #1596968 - GMT-5.4.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1596968




 holland-1.1.8-2.el7 (FEDORA-EPEL-2018-b4e4b3f3f1)
 Pluggable Backup Framework

Update Information:

Latest upstream change xtrabackup require to /usr/bin/xtrabackup

ChangeLog:

* Thu Oct 11 2018 Pete Travis  - 1.1.8-2
- Latest upstream
- change requires for xtrabackup subpackage to path to allow for alternative 
sources

References:

  [ 1 ] Bug #1638464 - holland-xtrabackup dependency issues in version 1.1.7 on 
EL7
https://bugzilla.redhat.com/show_bug.cgi?id=1638464
  [ 2 ] Bug #1638541 - holland-1.1.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1638541




 knot-2.6.9-2.el7 (FEDORA-EPEL-2018-79d6867298)
 High-performance authoritative DNS server

Update Information:

Knot DNS 2.6.9 (2018-08-14) ===  Improvements:
-  - Added zone wire size to zone loading log message  - Added debug
log message for each unsuccessful remote address operation  Bugfixes: -
- Zone not flushed after re-signing during zone load #594  - Server crashes when
committing empty zone transaction  - Incoming IXFR with on-slave signing
sometimes leads to memory corruption #595

ChangeLog:

* Mon Oct  1 2018 Tomas Krizek  - 2.6.9-1
Knot DNS 2.6.9 (2018-08-14)
===

Improvements:
-
 - Added zone wire size to zone loading log message
 - Added debug log message for each unsuccessful remote address operation

Bugfixes:
-
 - Zone not flushed after re-signing during zone load #594
 - Server crashes when committing empty zone transaction
 - Incoming IXFR with on-slave signing sometimes leads to memory 

Re: Attempting to contact unresponsive maintainers:

[Kevin Fenzi]

On 10/4/18 5:41 PM, Kevin Fenzi wrote:
> Greetings, we've been told that the email addresses for these package
> maintainers are no longer valid. I'm starting the unresponsive
> maintainer policy to find out if they are still interested in
> maintaining their packages (and if so, have them update their email
> addresses in FAS).
> 
> If they're not interested in maintaining or we can't locate them in 1
> week, I'll have FESCo orphan the packages so that others can take them
> over.
> 
> If you have a way to contact these maintainers, please let them know
> that we'd appreciate knowing what to do with their packages. Thanks!
> 
> tdabasin:
> 
> python-urllib2_kerberos [product: Fedora]
> python-zope-testing [product: Fedora EPEL]
> rubygem-taskjuggler [product: Fedora]
> python-xpyb [product: Fedora]
> python-xpyb [product: Fedora EPEL]
> python-rtkit [product: Fedora]
> python-rtkit [product: Fedora EPEL]

I have now orphaned:

rubygem-taskjuggler
python-xpyb
python-rtkit

Feel free to file a releng ticket if you want any of those.

kevin



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

Re: updates not pushed stable prior to f29 freeze

[Adam Williamson]

On Fri, 2018-10-12 at 14:12 -0400, Matthew Miller wrote:
> On Fri, Oct 12, 2018 at 08:43:30AM -0700, Adam Williamson wrote:
> > > This is even more augmented for installer related updates that unlike
> > > say Firefox fewer people are likely to be even able to test. Also it's
> > > still not possible for maintainers with disjoint commit rights to submit
> > > a shared updated without having to go bother a proven packager to do it
> > > for them.
> > This is really your problem, and it doesn't have a lot to do with
> > delays or anything like that, it's just that testing installer updates
> > is hard, period.
> 
> Just for clarity, I'm pretty sure Adam means "this problem is really the one
> you have", not "hey, buddy, this is *your* problem, not ours".  :)

OH! Yes, most definitely. Sorry, I didn't even notice that ambiguity.
:) Yes, I meant "*THIS* is your problem", not "This is *YOUR* 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Yet another gargantuan mathematical software update

[Jerry James]

On Sun, Oct 7, 2018 at 7:33 AM Till Hofmann  wrote:
> FYI: gazebo is currently FTBFS because player is FTBFS. I looked into
> player and fixed two smaller issues [1], but it's still FTBFS [2]. It
> looks like it's still requiring python2 but uses the default python3
> during build and then fails. So it needs to be migrated to python3...

Okay, I will skip gazebo ... and fawkes too, then, right?  Thanks,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Yet another gargantuan mathematical software update

[Jerry James]

On Sun, Oct 7, 2018 at 4:20 AM Nicolas Mailhot
 wrote:
> Thanks a lot for the huge piece of work!
> IIRC, there are a few math Go packages in the pipeline, that use *las
> too, not sure if they’ve reached rawhide yet or not (the guys who
> package them do not use the math stuff themselves, its just here as a
> dep for something else).

Good to know.  I will keep an eye out for them.  Thank you,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about sagemath

[Jerry James]

On Fri, Oct 5, 2018 at 2:48 AM Miro Hrončok  wrote:
> How can I help with the python3 transition?

I need some help after all.  Cythonizing of src/sage/arith/long.pxd is
failing like so:

Error compiling Cython file:

...

from cpython.object cimport Py_SIZE
from cpython.int cimport PyInt_AS_LONG
from cpython.long cimport PyLong_AsLong
from cpython.number cimport PyNumber_Index, PyIndex_Check
from cpython.longintrepr cimport PyLongObject, PyLong_SHIFT, digit
^


sage/arith/long.pxd:22:0: 'cpython/longintrepr/PyLongObject.pxd' not found


There is exactly one use of PyLongObject, on line 211:

cdef const digit* D = (x).ob_digit

This code is translating between gmp mpz_t objects and python
integers.  The error seems to be due to a change in cython, not in
python itself.  Still, I'm not sure how to fix the code so that cython
will accept it.

This is from Includes/cpython/longintrepr.pxd in Cython 0.28.4, which
does not trigger the above error:

ctypedef struct PyLongObject:
digit* ob_digit

This is from the same file in Cython 0.29~rc2-1, which does trigger
the above error:

ctypedef class __builtin__.py_long [object PyLongObject]:
cdef digit* ob_digit

If one of you python experts out there could tell me how the sagemath
code needs to change to get access to x's ob_digit, I would appreciate
it very much.  Thank you,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30: Deprecating /etc/sysconf/nfs

[Stephen Gallagher]

On Fri, Oct 12, 2018 at 2:48 PM Steve Dickson  wrote:
>
> Hello,
>
> A few years back there was a movement the NFS community
> to consulate all nfs configuration into one file
> call /etc/nfs.conf... See nfs.conf(5)
>
> Maybe stupidly, I've maintain backwards compatibility
> for that last couple Fedora releases. I think it is
> time to go to the single file configuration, since
> the development on Fedora 29 is winding down and
> it's winding up for Fedora 30.
>
> On fresh rawhide installs /etc/sysconfig/nfs will still
> be installed but with direction to use /etc/nfs.conf
>
> If /etc/sysconfig/nfs does exists the configuration will
> *not* be overridden... but the systemd scripts will
> no longer use that file to do any configuration.
>
> We are working tool that will convert sysconfig/nfs
> configs into nfs.conf configs... It is not clear
> how I'm going to package it since it is something
> I do not want to support forever... but only time will tell.
>
> I'm not sure what will break, but pretty sure something
> is going to break. ;-) I'm steved on freenode and OFTC
> IRC channels... feel ping me...
>


Steve, please file a Change Proposal[1] for Fedora 30 to submit to
FESCo so we can help coordinate this.

[1] https://fedoraproject.org/wiki/Changes/Policy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 30: Deprecating /etc/sysconf/nfs

[Steve Dickson]

Hello,

A few years back there was a movement the NFS community
to consulate all nfs configuration into one file 
call /etc/nfs.conf... See nfs.conf(5)

Maybe stupidly, I've maintain backwards compatibility
for that last couple Fedora releases. I think it is
time to go to the single file configuration, since
the development on Fedora 29 is winding down and
it's winding up for Fedora 30.

On fresh rawhide installs /etc/sysconfig/nfs will still
be installed but with direction to use /etc/nfs.conf

If /etc/sysconfig/nfs does exists the configuration will
*not* be overridden... but the systemd scripts will
no longer use that file to do any configuration.

We are working tool that will convert sysconfig/nfs
configs into nfs.conf configs... It is not clear
how I'm going to package it since it is something
I do not want to support forever... but only time will tell.

I'm not sure what will break, but pretty sure something
is going to break. ;-) I'm steved on freenode and OFTC
IRC channels... feel ping me...

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

[Bug 1638635] Upgrade perl-bignum to 0.51

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-bignum-0.51-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-2018-ed27d0729c

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: updates not pushed stable prior to f29 freeze

[Matthew Miller]

On Fri, Oct 12, 2018 at 08:43:30AM -0700, Adam Williamson wrote:
> > This is even more augmented for installer related updates that unlike
> > say Firefox fewer people are likely to be even able to test. Also it's
> > still not possible for maintainers with disjoint commit rights to submit
> > a shared updated without having to go bother a proven packager to do it
> > for them.
> This is really your problem, and it doesn't have a lot to do with
> delays or anything like that, it's just that testing installer updates
> is hard, period.


Just for clarity, I'm pretty sure Adam means "this problem is really the one
you have", not "hey, buddy, this is *your* problem, not ours".  :)

-- 
Matthew Miller

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

Fedora 29 compose report: 20181012.n.0 changes

[Fedora Branched Report]

OLD: Fedora-29-20181011.n.0
NEW: Fedora-29-20181012.n.0

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

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

Size change of upgraded packages:   -12.20 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  python-blivet-1:3.1.1-2.fc29
Old package:  python-blivet-1:3.1.1-1.fc29
Summary:  A python module for system storage configuration
RPMs: blivet-data python3-blivet
Size: 960.14 KiB
Size change:  -232 B
Changelog:
  * Mon Oct 08 2018 Vojtech Trefny  - 3.1.1-2
  - Fix options for ISCSI functions (#1632656) (vtrefny)


Package:  rtkit-0.11-20.fc29
Old package:  rtkit-0.11-19.fc29
Summary:  Realtime Policy and Watchdog Daemon
RPMs: rtkit
Size: 322.07 KiB
Size change:  -11.97 KiB
Changelog:
  * Tue Oct 09 2018 Zbigniew J??drzejewski-Szmek  - 0.11-20
  - Modernize a bit and fix BuildRequires (#1637496)



= 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[rpms/perl-File-Remove] New Commits To "rpms/perl-File-Remove" (f27)

[pagure]

The following commits were pushed to the repo rpms/perl-File-Remove on branch
f27, which you are following:
f031d0f4ce72b42b794a162d8f69f8a6e727d09fRalf CorsépiusCleanup merger.
5141e716484e7cb1ac868c570f8e4026d50dd693Ralf CorsépiusCleanup merger.
dcf7e15fcebf3f571919e59a04ef1c3972fc5c33Ralf CorsépiusUpdate to 1.58. 
Modernize spec.
383fce0ba8f170f737050670214b854b5e5b1956Fedora Release Engineering- 
Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
6138d4ef2f0c590b80187c2dcc5aecdd2f27f248Jitka PlesnikovaPerl 5.28 
rebuild
98bbe091477cd874b0f22f2df83a111be448289bPetr Písařcpan.org addresses 
moved to MetaCPAN 
8af7fb49e77eeccb328ef47306c353a01e9a5b6cFedora Release Engineering- 
Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-File-Remove/commits/f27
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: updates not pushed stable prior to f29 freeze

[Adam Williamson]

On Fri, 2018-10-12 at 17:33 +0200, Martin Kolman wrote:
> On Fri, 2018-10-12 at 16:04 +0200, Kalev Lember wrote:
> > On 10/12/2018 03:51 PM, Rex Dieter wrote:
> > > Stephen Gallagher wrote:
> > > 
> > > > On Fri, Oct 12, 2018 at 9:39 AM Rex Dieter  wrote:
> > > > > I've 2 bodhi updates that were submitted for batched/stable prior to 
> > > > > the
> > > > > freeze, will these get pushed prior to release?  I'd hoped so.
> > > > > 
> > > > 
> > > > Freeze was entered at 2018-10-09 00:00 UTC.
> > > 
> > > Ok, that's much earlier than I thought.  Thanks for the clarification.
> > 
> > The start of the freeze is a long standing confusion. This is something
> > where we could do much better. Could FESCo change the release schedule
> > so that instead of saying that a freeze starts on Tuesday at 00:00,
> > change it to say Monday at 23:59? That would be so much clearer and
> > remove all ambiguity.
> Another issue is the all the delays any state changes introduce in the bodhi 
> updates
> (push to updates, push to stable, etc.). Coupled with the updates being locked
> during the pushes and being repushed & all karma lost if any package is added 
> or changed,
> I would say it is often almost impossible to actually get an updated to 
> stable during the
> non-freeze periods.

This is clearly an exaggeration, as in practice we get hundreds of
updates landing during the non-freeze periods.

> This is even more augmented for installer related updates that unlike say 
> Firefox fewer people
> are likely to be even able to test. Also it's still not possible for 
> maintainers with disjoint
> commit rights to submit a shared updated without having to go bother a proven 
> packager to do it for them.

This is really your problem, and it doesn't have a lot to do with
delays or anything like that, it's just that testing installer updates
is hard, period.

I'm working on an openQA test to try and mitigate this, but it's
blocked by a weird lorax bug that I keep not having time to investigate
because other stuff gets set on fire (by all those 'stable' updates
that you think aren't happening :>)

> In the end it more and more looks like it is better to get all changes and 
> non-critical bug fixes in
> via Rawhide and only bother with branched updates for critical blocking 
> issues, rather than trying to fix as 
> many issues as possible before GA.

If you have an installer update that you want to get out during a non-
freeze period, just poke us (QA) and ask. We will take the time to
build an image and test it. If you don't poke us, we may not, because I
don't have an alert set for anaconda updates showing up, or anything
like that - we may not even notice it.
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Testing / feedback request: DNF 3 crashes

[Adam Williamson]

On Fri, 2018-10-12 at 09:07 +0200, Miroslav Suchý wrote:
> Dne 11.9.2018 v 21:26 Adam Williamson napsal(a):
> > Can anyone who is still struggling with DNF crashes on *basic*
> > operations on F29 or Rawhide please reply, and provide a few details on
> > what you're seeing and any workarounds or fixes you've found?
> 
> Obviously:
> https://retrace.fedoraproject.org/faf/reports/?opsysreleases=20=127_names=dnf%2Cdnf-plugins-core=__None_occurrence_daterange=2018-09-29%3A2018-10-12_occurrence_daterange=_by=last_occurrence
> 
> This is for last 14 days.

A lot of those look like they're basically:

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

All the ones that wind up in line 729 of libdnf/transaction.py are
likely that.

Some of the others look interesting, but without a bug report it's hard
to know what they might be :/
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: updates not pushed stable prior to f29 freeze

[Martin Kolman]

On Fri, 2018-10-12 at 16:04 +0200, Kalev Lember wrote:
> On 10/12/2018 03:51 PM, Rex Dieter wrote:
> > Stephen Gallagher wrote:
> > 
> > > On Fri, Oct 12, 2018 at 9:39 AM Rex Dieter  wrote:
> > > > 
> > > > I've 2 bodhi updates that were submitted for batched/stable prior to the
> > > > freeze, will these get pushed prior to release?  I'd hoped so.
> > > > 
> > > 
> > > Freeze was entered at 2018-10-09 00:00 UTC.
> > 
> > Ok, that's much earlier than I thought.  Thanks for the clarification.
> 
> The start of the freeze is a long standing confusion. This is something
> where we could do much better. Could FESCo change the release schedule
> so that instead of saying that a freeze starts on Tuesday at 00:00,
> change it to say Monday at 23:59? That would be so much clearer and
> remove all ambiguity.
Another issue is the all the delays any state changes introduce in the bodhi 
updates
(push to updates, push to stable, etc.). Coupled with the updates being locked
during the pushes and being repushed & all karma lost if any package is added 
or changed,
I would say it is often almost impossible to actually get an updated to stable 
during the
non-freeze periods.

This is even more augmented for installer related updates that unlike say 
Firefox fewer people
are likely to be even able to test. Also it's still not possible for 
maintainers with disjoint
commit rights to submit a shared updated without having to go bother a proven 
packager to do it for them.

In the end it more and more looks like it is better to get all changes and 
non-critical bug fixes in
via Rawhide and only bother with branched updates for critical blocking issues, 
rather than trying to fix as 
many issues as possible before GA.
> 
> Thanks,
> Kalev
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Testing / feedback request: DNF 3 crashes

[Adam Williamson]

On Fri, 2018-10-12 at 07:38 +0200, Tomasz Torcz wrote:
> On Thu, Oct 11, 2018 at 04:23:03PM -0700, Adam Williamson wrote:
> > > fwiw, I just ran into https://bugzilla.redhat.com/show_bug.cgi?id=1632177
> > > after a dnf system-upgrade and it crashed at least the dnf
> > > history/update/remove commands (whenever it started dependency 
> > > resolution):
> > 
> > Thanks for the note, it seems 3.6 / 0.20 did not fix all these problems
> > :/ I have nominated that bug as a Final blocker.
> 
>   The https://bugzilla.redhat.com/show_bug.cgi?id=1600917 looks like a
>  duplicate of above big. It also have some info and example of
>  crash-inducing history database.

They both have that (see comment #2 of 1632177). I'll mark it as 'see
also' and let dmach decide if they're dupes. thanks!
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 29 Final Go/No-Go meeting

[Ben Cotton]

Dear all,

The Go/No-Go meeting for the Fedora 29 Final release will be held on
Thursday, 2018-10-18 at 17:00 UTC in #fedora-meeting-1. For more
information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting

View the meeting on Fedocal at
https://apps.fedoraproject.org/calendar/Fedora%20release/2018/10/18/#m9379

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Fedora 29 Final Go/No-Go meeting

[Ben Cotton]

Dear all,

The Go/No-Go meeting for the Fedora 29 Final release will be held on
Thursday, 2018-10-18 at 17:00 UTC in #fedora-meeting-1. For more
information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting

View the meeting on Fedocal at
https://apps.fedoraproject.org/calendar/Fedora%20release/2018/10/18/#m9379

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Self Introduction: Casper Meijn

[Casper Meijn]

Hi, my name is Casper.
I am a software developer by trade and in my free time I am developing 
an open-source application [1].
During the development I noticed that the library I use (KDSoap) is not 
available in Fedora. I want to contribute to Fedora by packaging this 
library and later the application itself.


The review request for KDSoap can be found at 
https://bugzilla.redhat.com/show_bug.cgi?id=1638824


[1] https://gitlab.com/caspermeijn/onvifviewer

Best regards,

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

Re: updates not pushed stable prior to f29 freeze

[Stephen John Smoogen]

On Fri, 12 Oct 2018 at 10:05, Kalev Lember  wrote:
>
> On 10/12/2018 03:51 PM, Rex Dieter wrote:
> > Stephen Gallagher wrote:
> >
> >> On Fri, Oct 12, 2018 at 9:39 AM Rex Dieter  wrote:
> >>>
> >>> I've 2 bodhi updates that were submitted for batched/stable prior to the
> >>> freeze, will these get pushed prior to release?  I'd hoped so.
> >>>
> >>
> >> Freeze was entered at 2018-10-09 00:00 UTC.
> >
> > Ok, that's much earlier than I thought.  Thanks for the clarification.
>
> The start of the freeze is a long standing confusion. This is something
> where we could do much better. Could FESCo change the release schedule
> so that instead of saying that a freeze starts on Tuesday at 00:00,
> change it to say Monday at 23:59? That would be so much clearer and
> remove all ambiguity.
>

One could say it is currently at Monday 23:59:59.99... if
that helps.



--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: updates not pushed stable prior to f29 freeze

[Kalev Lember]

On 10/12/2018 03:51 PM, Rex Dieter wrote:

Stephen Gallagher wrote:


On Fri, Oct 12, 2018 at 9:39 AM Rex Dieter  wrote:


I've 2 bodhi updates that were submitted for batched/stable prior to the
freeze, will these get pushed prior to release?  I'd hoped so.



Freeze was entered at 2018-10-09 00:00 UTC.


Ok, that's much earlier than I thought.  Thanks for the clarification.


The start of the freeze is a long standing confusion. This is something
where we could do much better. Could FESCo change the release schedule
so that instead of saying that a freeze starts on Tuesday at 00:00,
change it to say Monday at 23:59? That would be so much clearer and
remove all ambiguity.

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

Re: updates not pushed stable prior to f29 freeze

[Rex Dieter]

Stephen Gallagher wrote:

> On Fri, Oct 12, 2018 at 9:39 AM Rex Dieter  wrote:
>>
>> I've 2 bodhi updates that were submitted for batched/stable prior to the
>> freeze, will these get pushed prior to release?  I'd hoped so.
>>
> 
> Freeze was entered at 2018-10-09 00:00 UTC.

Ok, that's much earlier than I thought.  Thanks for the clarification.

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

Re: updates not pushed stable prior to f29 freeze

[Stephen Gallagher]

On Fri, Oct 12, 2018 at 9:39 AM Rex Dieter  wrote:
>
> I've 2 bodhi updates that were submitted for batched/stable prior to the
> freeze, will these get pushed prior to release?  I'd hoped so.
>

Freeze was entered at 2018-10-09 00:00 UTC.

> https://bodhi.fedoraproject.org/updates/FEDORA-2018-dba61d0d49
>

Submitted for stable at 2018-10-09 13:41:17 UTC

So that was almost fourteen hours after the Freeze.

> https://bodhi.fedoraproject.org/updates/FEDORA-2018-5c15f3cff6
>
Submitted for stable at 2018-10-09 13:41:12 UTC

Same problem.


At this point, you should would need a Freeze Exception, but those are
pretty huge updates...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

updates not pushed stable prior to f29 freeze

[Rex Dieter]

I've 2 bodhi updates that were submitted for batched/stable prior to the 
freeze, will these get pushed prior to release?  I'd hoped so.

https://bodhi.fedoraproject.org/updates/FEDORA-2018-dba61d0d49

https://bodhi.fedoraproject.org/updates/FEDORA-2018-5c15f3cff6

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

[rpms/perl-File-Remove] New Commits To "rpms/perl-File-Remove" (f28)

[pagure]

The following commits were pushed to the repo rpms/perl-File-Remove on branch
f28, which you are following:
5141e716484e7cb1ac868c570f8e4026d50dd693Ralf CorsépiusCleanup merger.
dcf7e15fcebf3f571919e59a04ef1c3972fc5c33Ralf CorsépiusUpdate to 1.58. 
Modernize spec.
383fce0ba8f170f737050670214b854b5e5b1956Fedora Release Engineering- 
Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
6138d4ef2f0c590b80187c2dcc5aecdd2f27f248Jitka PlesnikovaPerl 5.28 
rebuild
98bbe091477cd874b0f22f2df83a111be448289bPetr Písařcpan.org addresses 
moved to MetaCPAN 



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-File-Remove/commits/f28
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-File-Remove] New Commits To "rpms/perl-File-Remove" (f29)

[pagure]

The following commits were pushed to the repo rpms/perl-File-Remove on branch
f29, which you are following:
dcf7e15fcebf3f571919e59a04ef1c3972fc5c33Ralf CorsépiusUpdate to 1.58. 
Modernize spec.



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-File-Remove/commits/f29
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Installation image layout

[Marek Marczykowski-Górecki]

On Thu, Oct 11, 2018 at 09:24:08PM -0600, Chris Murphy wrote:
> On Thu, Oct 11, 2018 at 6:37 PM, Marek Marczykowski-Górecki
>  wrote:
> > Hi all!
> >
> > I'm new on this list. I work on Qubes OS, where Fedora is used as a base
> > distribution.
> >
> > While trying to build the installation image in reproducible manner[1],
> > I found the current installation image have unusual layout. Quoting
> > dracut.cmdline manual page:
> >
> >squashfs.img  |  Squashfs from LiveCD .iso downloaded via 
> > network
> >   !(mount)
> >   /LiveOS
> >   |- rootfs.img  |  Filesystem image to mount read-only
> >!(mount)
> >/bin  |  Live filesystem
> >/boot |
> >/dev  |
> >...   |
> >
> > This rootfs.img layer makes the image build very much unreproducible.
> > Why is it even there? Bare squashfs.img layer should be enough. Then,
> > mount overlayfs over it (I see there is even some partial support for it
> > in dmsquash-live). Most other Live systems I've seen use just squashfs +
> > overlayfs (or aufs if kernel is older), so it's commonly tested
> > configuration. I *guess* it's there for historical reason, from before
> > aufs/overlayfs being available. Is there any other reason for that?
> 
> I'm pretty sure the original reason was the default live install use
> dd to block copy the root file system into the fedora-root LV, and
> then resized the LV and ext4 file system.

How is it done now?

> There have also been a
> number of squashfs improvements since that decision so there might
> have been limitations with squashfs that ext4 didn't have (I'm
> thinking xattr were long supported in ext4 before squashfs, and maybe
> capabilities?)
> 
> >
> > If there is no other reason, I propose to drop this and have
> > installer/live filesystem directly in squashfs.img. This have multiple
> > benefits:
> >  - it's much easier to make the image build process reproducible (see
> >below)
> >  - less complexity, both in the build and in the boot (the whole
> >dmsquash-live dracut module can be replaced with <20 line
> >function[2]
> >  - smaller initramfs (which is extremely important if needed to be
> >included in efiboot.img, which can't be larger than 32MB)
> >  - slightly faster boot time (device-mapper is slow)
> >
> > What do you think?
> 
> Whatever we do should take into account the persistent root and
> persistent home use cases, specifically:
> https://github.com/livecd-tools/livecd-tools/blob/master/tools/livecd-iso-to-disk.sh
> 
> --overlay-size-mb
> --home-size-mb
> 
> A particular criticism of the device-mapper solution currently being
> used is in that script: it blows up. Literally it's WORM, and deleting
> files simply dereferences them, it doesn't free up pool space, so it
> is inevitable that the pool will fill up, and when it does it blows up
> the file system, and it can't be repaired. All you can do is reset the
> overlay which means deleting all changes and starting over.
> 
> At least one of our spins, SOAS, depends on livecd-iso-to-disk for
> creating their final installation because it's predicated on running
> Fedora SOAS from a stick.
> 
> Why does efiboot.img have a 32MiB limit?

Because "32MB should be enough for everybody"...
Long story short, "El Torito" boot catalog structure have 16-bit field
for image size (expressed in 512-bytes sectors). For details see here:
https://wiki.osdev.org/El-Torito
https://web.archive.org/web/20180112220141/https://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf
(page 10)

Full story:
https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-135988806

I've spent a lot of time debugging this, because mkisofs doesn't
complain about it, just silently overflow higher bits to adjacent field,
which results in weird results, depending on where you boot it. Adding
isohybrid to the picture doesn't make it easier (there, higher bits are
truncated, or actually not copied to the MBR partition table, as wasn't
part of the original field).

> > As for the reproducibility, I've made changes to lorax (including
> > dropping rootfs.img layer), anaconda, pungi and createrepo and this all
> > allows to build bit-by-bit identical image, given the same input (rpm
> > packages, pungi configuration, $SOURCE_DATE_EPOCH variable[3]). Well,
> > almost - there is an issue with efiboot.img, but I already have a
> > solution, just not pushed it yet.
> >
> > You can find all the pull requests collected here:
> > https://github.com/QubesOS/qubes-installer-qubes-os/pull/26
> >
> > I'll work further to make the changes merged upstream.
> >
> > [1] https://reproducible-builds.org/
> > [2] 
> > https://github.com/QubesOS/qubes-installer-qubes-os/pull/26/commits/332be8e1e3e1006013772528078914f491d14c1f
> > [3] https://reproducible-builds.org/specs/source-date-epoch/
> 
> Cool! Well you've already done most of 

Re: Fedora 29 Beta - Cannot add printer

[Zdenek Dohnal]

Hi,

What type of printer do you want to add (ethernet/usb/wifi)? I tried to
add ethernet and usb types in my clean F29 virtual machine and both worked.

If the printer is usb or it is in the same network as your PC, then you
should see it in CUPS web api when you try to add new printer (on
localhost:631, when cups.service is running - tab Administration, 'Add
new printer').

If you can add printer through CUPS web api, then the issue will be in
gnome-control-center.

On 10/12/18 12:28 AM, Gilles Dubreuil wrote:
> Added screenshot
>
>
> On 12/10/18 09:27, Gilles Dubreuil wrote:
>> Hi,
>>
>> Using default Gnome shell on Wayland I cannot add a printer.
>>
>> In Gnome settings, after pressing "unlock" and "add" button and than
>> selecting a driver, a pop up message "Failed to add new printer"
>> There are no messages in system journal.
>>
>> PS: I've SELinux in permissive mode just in case.
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C



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

[rpms/perl-File-Remove] New Commits To "rpms/perl-File-Remove" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-File-Remove on branch
master, which you are following:
dcf7e15fcebf3f571919e59a04ef1c3972fc5c33Ralf CorsépiusUpdate to 1.58. 
Modernize spec.



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-File-Remove/commits/master
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/amavisd-new] New Commits To "rpms/amavisd-new" (f28)

[pagure]

The following commits were pushed to the repo rpms/amavisd-new on branch
f28, which you are following:
4a3450262b1df62bb1843e8c31a66b63ff8b436cJuan Orti AlcaineVersion 2.11.1
1b3449d93b926e45303d59106f47fa246f0c8883Fedora Release Engineering- 
Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/amavisd-new/commits/f28
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/amavisd-new] New Commits To "rpms/amavisd-new" (f29)

[pagure]

The following commits were pushed to the repo rpms/amavisd-new on branch
f29, which you are following:
4a3450262b1df62bb1843e8c31a66b63ff8b436cJuan Orti AlcaineVersion 2.11.1



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/amavisd-new/commits/f29
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638642] Upgrade perl-Math-BigInt-FastCalc to 0.5008

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Math-BigInt-FastCalc-0
   ||.500.800-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-10-12 04:50:21



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-Math-BigInt-FastCalc] New Commits To "rpms/perl-Math-BigInt-FastCalc" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Math-BigInt-FastCalc on 
branch
master, which you are following:
0f6a08668789eb75b4448f062fe93f906ae6876fJitka Plesnikova0.5008 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Math-BigInt-FastCalc/commits/master
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/amavisd-new] New Commits To "rpms/amavisd-new" (master)

[pagure]

The following commits were pushed to the repo rpms/amavisd-new on branch
master, which you are following:
4a3450262b1df62bb1843e8c31a66b63ff8b436cJuan Orti AlcaineVersion 2.11.1



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/amavisd-new/commits/master
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638642] Upgrade perl-Math-BigInt-FastCalc to 0.5008

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|ppi...@redhat.com   |jples...@redhat.com



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638641] Upgrade perl-Math-BigInt to 1.9998.14

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Math-BigInt-1.9998.14-
   ||1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-10-12 04:32:39



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-Math-BigInt] New Commits To "rpms/perl-Math-BigInt" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Math-BigInt on branch
master, which you are following:
ed8e043ef4ce96c307d99f9b0c177d706ddfb84dJitka Plesnikova1.999814 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Math-BigInt/commits/master
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638641] Upgrade perl-Math-BigInt to 1.9998.14

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|ppi...@redhat.com   |jples...@redhat.com



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638635] Upgrade perl-bignum to 0.51

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-bignum-0.51-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-ed27d0729c

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638635] Upgrade perl-bignum to 0.51

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-bignum-0.51-1.fc30



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-bignum] New Commits To "rpms/perl-bignum" (f29)

[pagure]

The following commits were pushed to the repo rpms/perl-bignum on branch
f29, which you are following:
d172193a7d680f0485ae85374ec1359e4196caa1Jitka Plesnikova0.51 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-bignum/commits/f29
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-bignum] New Commits To "rpms/perl-bignum" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-bignum on branch
master, which you are following:
d172193a7d680f0485ae85374ec1359e4196caa1Jitka Plesnikova0.51 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-bignum/commits/master
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638635] Upgrade perl-bignum to 0.51

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|ppi...@redhat.com   |jples...@redhat.com



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638643] Upgrade perl-Math-BigInt-GMP to 1.6006

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Math-BigInt-GMP-1.6006
   ||-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-10-12 03:10:16



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-Math-BigInt-GMP] New Commits To "rpms/perl-Math-BigInt-GMP" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Math-BigInt-GMP on 
branch
master, which you are following:
b817df16e236a59163b28df3f1c409b3e805d729Jitka Plesnikova1.6006 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Math-BigInt-GMP/commits/master
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Testing / feedback request: DNF 3 crashes

[Miroslav Suchý]

Dne 11.9.2018 v 21:26 Adam Williamson napsal(a):
> Can anyone who is still struggling with DNF crashes on *basic*
> operations on F29 or Rawhide please reply, and provide a few details on
> what you're seeing and any workarounds or fixes you've found?


Obviously:
https://retrace.fedoraproject.org/faf/reports/?opsysreleases=20=127_names=dnf%2Cdnf-plugins-core=__None_occurrence_daterange=2018-09-29%3A2018-10-12_occurrence_daterange=_by=last_occurrence

This is for last 14 days.

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

[Bug 1638643] New: Upgrade perl-Math-BigInt-GMP to 1.6006

[bugzilla]

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

Bug ID: 1638643
   Summary: Upgrade perl-Math-BigInt-GMP to 1.6006
   Product: Fedora
   Version: rawhide
 Component: perl-Math-BigInt-GMP
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, st...@silug.org



Latest Fedora delivers 1.6005 version. Upstream released 1.6006. When you have
free time, please upgrade it

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638642] New: Upgrade perl-Math-BigInt-FastCalc to 0.5008

[bugzilla]

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

Bug ID: 1638642
   Summary: Upgrade perl-Math-BigInt-FastCalc to 0.5008
   Product: Fedora
   Version: rawhide
 Component: perl-Math-BigInt-FastCalc
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest Fedora delivers 0.5007 version. Upstream released 0.5008. When you have
free time, please upgrade it

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638641] New: Upgrade perl-Math-BigInt to 1.9998.14

[bugzilla]

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

Bug ID: 1638641
   Summary: Upgrade perl-Math-BigInt to 1.9998.14
   Product: Fedora
   Version: rawhide
 Component: perl-Math-BigInt
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest Fedora delivers 1.9998.13 version. Upstream released 1.9998.14. When you
have free time, please upgrade it

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1636858] Upgrade perl-HTTP-BrowserDetect to 3.19

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

Summary|Upgrade |Upgrade
   |perl-HTTP-BrowserDetect to  |perl-HTTP-BrowserDetect to
   |3.18|3.19



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1638635] New: Upgrade perl-bignum to 0.51

[bugzilla]

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

Bug ID: 1638635
   Summary: Upgrade perl-bignum to 0.51
   Product: Fedora
   Version: rawhide
 Component: perl-bignum
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest Fedora delivers 0.50 version. Upstream released 0.51. When you have free
time, please upgrade it

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org