[Test-Announce] 2017-01-09 @ 17:00 UTC - Fedora 26 Blocker Review

[Adam Williamson]

# F26 Blocker Review meeting
# Date: 2017-01-09
# Time: 17:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We currently have 4 proposed Alpha blockers, 1 proposed
Beta blocker and 1 proposed Final blocker to review, so it seems
like a good time to have the first Fedora 26 blocker review meeting.

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F26 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] 2017-01-09 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2017-01-09
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's time for the first meeting of 2017 tomorrow! Let's check in on all
our current work areas as we move forward towards Fedora 25.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Optical media test coverage discussion, redux
3. Trac -> Pagure migration status
4. Fedora 26 Test Day status
5. Fedora 25 Retrospective status
6. Relval-ng status
7. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Golang 1.8

[jfilak]

Brilliant! I was thinking about creating a proof of concept a posting it as 
a change myself.

However, I'm really busy with other projects, so I might miss F26.




Brad's suggestion made me happy, that's why I close the issue. Though, I 
would not

name the flag 'abrt' but 'tracebackcrash' or something like that. Its name 
should tell

users something about its effect.




I'm not sure how we package Go projects and how we build them, but my idea

is to include "--tags=tracebackcrash" in the build flags when running 
rpmbuild.

That means that we need to work with the rpm team and ask them to update

the default macros.




Will this change affect also gcc-go? I'm afraid that we need to come up with
 

something similar for gcc-go too, right?







Regards,
Jakub








-- Původní zpráva --
Od: Jakub Cajka 
Komu: Development discussions related to Fedora 
Datum: 5. 1. 2017 16:38:03
Předmět: Re: F26 System Wide Change: Golang 1.8

"



- Original Message -
> From: jfi...@fedoraproject.org
> To: "Development discussions related to Fedora" 
> Sent: Wednesday, December 14, 2016 7:18:32 AM
> Subject: Re: F26 System Wide Change: Golang 1.8
> 
> I agree with Zbyzsek on this.
> 
> What about to carry a tiny down-stream patch until this issue is fixed:
> https://github.com/golang/go/issues/18304
> 
> 
> Jakub
> 
> 

Suggestion by Brad Fitzpatrick in the upstream issue seems as reasonable 
implementation to me. Also it make possible opt-out/opt-in, if there will be
need for it.
I will work on implementing/testing it along with the re-base(including 
update to packaging macros and Go guidelines draft) and I will update the 
change proposal to reflect it ASAP.

Sorry for longer notice I have been offline though the end of the year,

JC

> 
> 
> -- Původní zpráva --
> Od: Zbigniew Jędrzejewski-Szmek 
> Komu: Development discussions related to Fedora
> 
> Datum: 13. 12. 2016 19:35:01
> Předmět: Re: F26 System Wide Change: Golang 1.8
> 
> 
> On Tue, Dec 13, 2016 at 01:06:29PM -0500, Jakub Cajka wrote:
> > > can we enable coredumping for Go programs by default - i.e. set
> > > GOTRACEBACK=
> > > crash?
> > > 
> > > Currently, Go terminate a process that panic and prints out an error
> > > message on stderr.
> > > 
> > > This approach does not provide much room for automatic Go panic
> > > detection.
> > 
> > It should be possible without any significant side effects apart from
> > generating cores and traces. But to enable this, I believe, it would 
need
> > alteration to the default system env.
> 
> Would it be possible? What is the package providing the default env vars?
> 
> systemd has DefaultEnvironment= in /etc/systemd/system.conf, but it is
> supposed to be used to create local overrides, and doesn't work well
> for this case (it's %config(noreplace) among other problems). In general
> setting global env vars does not work.
> 
> Instead, it would be nicer to modify the go runtime to default to a 
coredump
> if GOTRACEBACK= is not set. This would cover more cases and would not 
pollute
> the environment for users who are not using go.
> 
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
"___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Kevin Kofler]

Matthew Miller wrote:
> But if that's *all* we do, we're going to be a footnote in history.

I don't buy this sort of alarmist bulldung that keeps being claimed with no 
evidence whatsoever to justify radical changes to what Fedora is all about, 
such as:
* promoting proprietary drivers (making them easier to use, adding them to
  GNOME Software, etc.), which contradicts our Freedom principle,
* moving away from integrated packages (which are what a distribution is all
  about) towards modules and containers (which, incidentally, also make it
  easier to deliver non-free blobs),
etc.

The same kind of alarmist nonsense was floated back in the day by the 
Linspire folks towards distributions such as Fedora and Debian that refused 
to embrace proprietary software. Look where Fedora and Debian are now (alive 
and thriving) and where Linspire is now (long dead).

I think that by destroying what Fedora is all about, we will become a 
footnote in history. On the other hand, sticking to our principles (Freedom) 
and to our technical strengths (an integrated distribution of integrated 
packages) will keep us relevant for a long time to come.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1410277] perl-Net-HTTP-6.12 is available

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
perl-Net-HTTP-6.12-1.fc24 has been pushed to the Fedora 24 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-2017-ccdb1b024e

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

[Bug 1410162] perl-PDL-2.17.0-1.fc26 FTBFS: tests segfaut on 64-bit PowerPC

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-PDL-2.16.0-2.fc24 has been pushed to the Fedora 24 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-2017-75eb9845f8

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

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

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 789  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
 432  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
 404  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ce45574ab6   
libbsd-0.8.3-2.el5


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

beakerlib-1.12-1.el5
rear-2.00-1.el5

Details about builds:



 beakerlib-1.12-1.el5 (FEDORA-EPEL-2017-ad9586422e)
 A shell-level integration testing library

Update Information:

added rlIsCentOS similar to rlIsRHEL, bz1214190




 rear-2.00-1.el5 (FEDORA-EPEL-2017-be56f3c626)
 Relax-and-Recover is a Linux disaster recovery and system migration tool

Update Information:

For a changelog see the rear-release-notes.txt file.

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[Bug 1410962] perl-TestML-0.53 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Created attachment 1238142
  --> https://bugzilla.redhat.com/attachment.cgi?id=1238142=edit
Rebase-helper rebase-helper-debug.log log file.
See for details and report the eventual error to rebase-helper
https://github.com/phracek/rebase-helper/issues.

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

[Bug 1410962] perl-TestML-0.53 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
Patches were not touched. All were applied properly

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

[Bug 1410962] perl-TestML-0.53 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Patching or scratch build for perl-TestML-0.52 failed.

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

[Bug 1410962] New: perl-TestML-0.53 is available

[bugzilla]

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

Bug ID: 1410962
   Summary: perl-TestML-0.53 is available
   Product: Fedora
   Version: rawhide
 Component: perl-TestML
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.53
Current version/release in rawhide: 0.52-5.fc25
URL: http://search.cpan.org/dist/TestML/

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

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

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

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

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

[Bug 1410277] perl-Net-HTTP-6.12 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #11 from Fedora Update System  ---
perl-Net-HTTP-6.12-1.fc25 has been pushed to the Fedora 25 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-2017-1cf36c5723

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

[Bug 1410279] perl-RDF-Trine-1.015 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-RDF-Trine-1.015-1.fc25 has been pushed to the Fedora 25 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-2017-b85ab25db7

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

[Bug 1410162] perl-PDL-2.17.0-1.fc26 FTBFS: tests segfaut on 64-bit PowerPC

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #8 from Fedora Update System  ---
perl-PDL-2.16.0-2.fc25 has been pushed to the Fedora 25 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-2017-499e3ba8d4

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

[Bug 1410641] perl-XXX-0.31 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-XXX-0.31-1.fc25 has been pushed to the Fedora 25 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-2017-2964893414

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

Re: Changing default "docker" storage to to Overlay2 in Fedora 26

[Alec Leamas]

Hi!

Is there a local convention that discussion about containers is using 
top-posting?


"Curious"

--alec

On 06/01/17 23:12, Vivek Goyal wrote:

There is more conversation on this issue here.

https://pagure.io/atomic-wg/issue/186

I wished there was a single thread of conversation on this instead of
separate conversation for per product variant.

Thanks
Vivek

On Fri, Jan 06, 2017 at 02:05:49PM -0500, Daniel J Walsh wrote:

Upstream docker is moving to overlay2 by default for its storage.  We
plan on following suit.  Their are some performance advantages of
overlay2 over devicemapper in memory sharing, which we would like to
take advantage of.   We now have SELinux support for Overlay  file
systems, so the security should be just as good.

Note: Overlay is not a Posix Compliant file system, so their could be
problems with your containers running on overlay, so
we want to make sure it is fairly easy to switch back to devicemapper.

Devicemapper out of the box, on Fedora Workstation, currently defaults
to loopback devices for storage, which has a performance penalty, but
this was the only way we were able to get docker to work right away.
Switching to overlay2 will cause the storage to be shared with / and
will eliminate this performance overhead.   This is the way we will ship
Fedora Workstation.

On Fedora atomic host and Fedora server we have been storing
devicemapper storage on a separate partition.  We plan on doing the same
thing with overlay2.  This means separate device will be mounted on
/var/lib/docker.  This will make it easier for someone to switch back to
devicemapper, if overlay2 has problems.

Upgraded systems will not be effected.

If you want to switch from one storage to another take a look at the
`atomic storage` commands.

We will write up release notes to cover this change. Along with a blog
explaining the commands to switch back and forth.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changing default "docker" storage to to Overlay2 in Fedora 26

[Vivek Goyal]

There is more conversation on this issue here.

https://pagure.io/atomic-wg/issue/186

I wished there was a single thread of conversation on this instead of
separate conversation for per product variant.

Thanks
Vivek

On Fri, Jan 06, 2017 at 02:05:49PM -0500, Daniel J Walsh wrote:
> Upstream docker is moving to overlay2 by default for its storage.  We
> plan on following suit.  Their are some performance advantages of
> overlay2 over devicemapper in memory sharing, which we would like to
> take advantage of.   We now have SELinux support for Overlay  file
> systems, so the security should be just as good.
> 
> Note: Overlay is not a Posix Compliant file system, so their could be
> problems with your containers running on overlay, so
> we want to make sure it is fairly easy to switch back to devicemapper.
> 
> Devicemapper out of the box, on Fedora Workstation, currently defaults
> to loopback devices for storage, which has a performance penalty, but
> this was the only way we were able to get docker to work right away. 
> Switching to overlay2 will cause the storage to be shared with / and
> will eliminate this performance overhead.   This is the way we will ship
> Fedora Workstation.
> 
> On Fedora atomic host and Fedora server we have been storing
> devicemapper storage on a separate partition.  We plan on doing the same
> thing with overlay2.  This means separate device will be mounted on
> /var/lib/docker.  This will make it easier for someone to switch back to
> devicemapper, if overlay2 has problems.
> 
> Upgraded systems will not be effected. 
> 
> If you want to switch from one storage to another take a look at the
> `atomic storage` commands.
> 
> We will write up release notes to cover this change. Along with a blog
> explaining the commands to switch back and forth.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changing default "docker" storage to to Overlay2 in Fedora 26

[Igor Gnatenko]

On Fri, Jan 6, 2017 at 9:29 PM, Daniel J Walsh  wrote:
> https://fedoraproject.org/wiki/Changes/DockerOverlay2
Thanks! Note, that you will need to send it for wrangler.
>
>
> On 01/06/2017 02:27 PM, Igor Gnatenko wrote:
>
> Shouldn't this be submitted as a change?
>
> This would bring much more visibility to users of Fedora and even outside.
>
> -Igor Gnatenko
>
> On Jan 6, 2017 8:13 PM, "Daniel J Walsh"  wrote:
>>
>> Upstream docker is moving to overlay2 by default for its storage.  We
>> plan on following suit.  Their are some performance advantages of
>> overlay2 over devicemapper in memory sharing, which we would like to
>> take advantage of.   We now have SELinux support for Overlay  file
>> systems, so the security should be just as good.
>>
>> Note: Overlay is not a Posix Compliant file system, so their could be
>> problems with your containers running on overlay, so
>> we want to make sure it is fairly easy to switch back to devicemapper.
>>
>> Devicemapper out of the box, on Fedora Workstation, currently defaults
>> to loopback devices for storage, which has a performance penalty, but
>> this was the only way we were able to get docker to work right away.
>> Switching to overlay2 will cause the storage to be shared with / and
>> will eliminate this performance overhead.   This is the way we will ship
>> Fedora Workstation.
>>
>> On Fedora atomic host and Fedora server we have been storing
>> devicemapper storage on a separate partition.  We plan on doing the same
>> thing with overlay2.  This means separate device will be mounted on
>> /var/lib/docker.  This will make it easier for someone to switch back to
>> devicemapper, if overlay2 has problems.
>>
>> Upgraded systems will not be effected.
>>
>> If you want to switch from one storage to another take a look at the
>> `atomic storage` commands.
>>
>> We will write up release notes to cover this change. Along with a blog
>> explaining the commands to switch back and forth.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>



-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Linux subsystem on Windows machine

[M. Edward (Ed) Borasky]

Nice!!

On Fri, Jan 6, 2017 at 1:47 AM Vít Ondruch  wrote:

>
>
> Dne 6.1.2017 v 10:03 Martin Bříza napsal(a):
> > On Fri, 06 Jan 2017 10:01:01 +0100, Vít Ondruch 
> > wrote:
> >
> >>
> >>
> >> Dne 5.1.2017 v 20:11 M. Edward (Ed) Borasky napsal(a):
> >>>
> >>>
> >>>
> >>>
> >>> And speaking of Wine, how come the Windows 10 Linux subsystem only
> >>> runs Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows
> >>> machine?
> >>
> >> Just FYI:
> >>
> >>
> >> http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora
> >>
> >>
> >> Vít
> >
> > I think that doesn't work anymore. But there's this project that
> > should work now [0], while being more user friendly and versatile.
> >
> > [0] https://github.com/RoliSoft/WSL-Distribution-Switcher
>
> Thanks for pointing this out. I knew I saw something more advanced, but
> already forgot what it was ;) I am not windows user mysefl ...
>
>
> Vít
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
-- 
How many people can stand on the shoulders of a giant before the giant
collapses?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Matthew Miller]

On Fri, Jan 06, 2017 at 07:14:58PM +0100, Kevin Kofler wrote:
> > This is a good point; we're already pretty much awful on this point,
> > and let's not make it worse. (On the other hand, modularity has the
> > potential to help significantly on this point, as you should't need
> > detailed metadata about what's _inside_ a module at runtime in normal
> > circumstances.)
> 
> At that point, we stop being a distribution and become a salad bar of
> bits and pieces that may or may not work together, where both look
> and feel integration and functional features will end up disabled
> because they would depend on libraries from another module, and that
> each contain their own redundant copies of the same libraries. I
> think that is a huge step backwards, and if actually fully
> implemented, will likely force me to switch to a different
> distribution.

Analogies are always tricky, but I think that's definitely the wrong
one here. Right now what we have is a casserole, where we bake every
ingredient together in the same way - in the same dish at the same
temperature for the same time. With that approach, you're always going
to get some ingredients which ... don't work so well.

What we're exploring with Modularity is offering a menu of different
dishes - and, yeah, it might be a menu where you can't order the
goulash and the chocolate pudding on the same plate.

This is a change, but sometimes change is okay. This change reflects a
very, very real shift in IT, which containers have accelerated but which
really took off over a decade ago (!) with datacenter virtualization.
Not only does one not need all of the stuff running in one namespace,
but it's best practice _to not to_. We spend a lot of effort optimizing
for that everything-cooked-together dish, which increasingly people do
not even want.

As I've said since the first "Rings" proposal, if people in Fedora want
to continue working on the casserole, and feel like that's an important
and valuable thing, *awesome*. But if that's *all* we do, we're going
to be a footnote in history.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changing default "docker" storage to to Overlay2 in Fedora 26

[Daniel J Walsh]

https://fedoraproject.org/wiki/Changes/DockerOverlay2


On 01/06/2017 02:27 PM, Igor Gnatenko wrote:
> Shouldn't this be submitted as a change? 
>
> This would bring much more visibility to users of Fedora and even outside.
>
> -Igor Gnatenko
>
> On Jan 6, 2017 8:13 PM, "Daniel J Walsh"  > wrote:
>
> Upstream docker is moving to overlay2 by default for its storage.  We
> plan on following suit.  Their are some performance advantages of
> overlay2 over devicemapper in memory sharing, which we would like to
> take advantage of.   We now have SELinux support for Overlay  file
> systems, so the security should be just as good.
>
> Note: Overlay is not a Posix Compliant file system, so their could be
> problems with your containers running on overlay, so
> we want to make sure it is fairly easy to switch back to devicemapper.
>
> Devicemapper out of the box, on Fedora Workstation, currently defaults
> to loopback devices for storage, which has a performance penalty, but
> this was the only way we were able to get docker to work right away.
> Switching to overlay2 will cause the storage to be shared with / and
> will eliminate this performance overhead.   This is the way we
> will ship
> Fedora Workstation.
>
> On Fedora atomic host and Fedora server we have been storing
> devicemapper storage on a separate partition.  We plan on doing
> the same
> thing with overlay2.  This means separate device will be mounted on
> /var/lib/docker.  This will make it easier for someone to switch
> back to
> devicemapper, if overlay2 has problems.
>
> Upgraded systems will not be effected.
>
> If you want to switch from one storage to another take a look at the
> `atomic storage` commands.
>
> We will write up release notes to cover this change. Along with a blog
> explaining the commands to switch back and forth.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changing default "docker" storage to to Overlay2 in Fedora 26

[Igor Gnatenko]

Shouldn't this be submitted as a change?

This would bring much more visibility to users of Fedora and even outside.

-Igor Gnatenko

On Jan 6, 2017 8:13 PM, "Daniel J Walsh"  wrote:

> Upstream docker is moving to overlay2 by default for its storage.  We
> plan on following suit.  Their are some performance advantages of
> overlay2 over devicemapper in memory sharing, which we would like to
> take advantage of.   We now have SELinux support for Overlay  file
> systems, so the security should be just as good.
>
> Note: Overlay is not a Posix Compliant file system, so their could be
> problems with your containers running on overlay, so
> we want to make sure it is fairly easy to switch back to devicemapper.
>
> Devicemapper out of the box, on Fedora Workstation, currently defaults
> to loopback devices for storage, which has a performance penalty, but
> this was the only way we were able to get docker to work right away.
> Switching to overlay2 will cause the storage to be shared with / and
> will eliminate this performance overhead.   This is the way we will ship
> Fedora Workstation.
>
> On Fedora atomic host and Fedora server we have been storing
> devicemapper storage on a separate partition.  We plan on doing the same
> thing with overlay2.  This means separate device will be mounted on
> /var/lib/docker.  This will make it easier for someone to switch back to
> devicemapper, if overlay2 has problems.
>
> Upgraded systems will not be effected.
>
> If you want to switch from one storage to another take a look at the
> `atomic storage` commands.
>
> We will write up release notes to cover this change. Along with a blog
> explaining the commands to switch back and forth.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Applications with AppData and not visible in the software center

[Richard Hughes]

On 6 January 2017 at 02:16, Ben Rosser  wrote:
> It turns out that I am very silly, and, when writing the appstream
> file for tilp2, never changed "comical.desktop" in the template here
> [1] to "tilp.desktop".
> ...whoops! I can, uh, fix that.

:)

> However, interestingly, it seems that "appstream-util validate-relax
> --nonet" doesn't seem to care. It happily validates tilp2's appstream
> information [2], which is why I never noticed this at the time. I
> would think that "referenced desktop file doesn't exist on system"
> should at least be a warning or something when validating?

Well, to do a full validation we need to search for the icon, look for
the desktop file and validate the appdata file. This is what you can
do with:

$ appstream-util check-root

Although it's best used in the package build system, e.g. for RPM you can do:

DESTDIR=%{buildroot} appstream-util check-root

It's lightly tested, so it if works or breaks please let me know.

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changing default "docker" storage to to Overlay2 in Fedora 26

[Vivek Goyal]

On Fri, Jan 06, 2017 at 02:05:49PM -0500, Daniel J Walsh wrote:
> Upstream docker is moving to overlay2 by default for its storage.  We
> plan on following suit.  Their are some performance advantages of
> overlay2 over devicemapper in memory sharing, which we would like to
> take advantage of.   We now have SELinux support for Overlay  file
> systems, so the security should be just as good.
> 
> Note: Overlay is not a Posix Compliant file system, so their could be
> problems with your containers running on overlay, so
> we want to make sure it is fairly easy to switch back to devicemapper.

Yes, idea is basically that with overlay2 continuously improving upstream,
it might be at a stage where pros of overlay2 might outweight its cons
for lot of people. And if does not, then provide and easy way for
users to switch back to devicemapper.

With overlay2 being default, it will also provide with some data about
how well it works for various workloads.

Vivek

> On Fedora atomic host and Fedora server we have been storing
> devicemapper storage on a separate partition.  We plan on doing the same
> thing with overlay2.  This means separate device will be mounted on
> /var/lib/docker.  This will make it easier for someone to switch back to
> devicemapper, if overlay2 has problems.
> 
> Upgraded systems will not be effected. 
> 
> If you want to switch from one storage to another take a look at the
> `atomic storage` commands.
> 
> We will write up release notes to cover this change. Along with a blog
> explaining the commands to switch back and forth.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Changing default "docker" storage to to Overlay2 in Fedora 26

[Daniel J Walsh]

Upstream docker is moving to overlay2 by default for its storage.  We
plan on following suit.  Their are some performance advantages of
overlay2 over devicemapper in memory sharing, which we would like to
take advantage of.   We now have SELinux support for Overlay  file
systems, so the security should be just as good.

Note: Overlay is not a Posix Compliant file system, so their could be
problems with your containers running on overlay, so
we want to make sure it is fairly easy to switch back to devicemapper.

Devicemapper out of the box, on Fedora Workstation, currently defaults
to loopback devices for storage, which has a performance penalty, but
this was the only way we were able to get docker to work right away. 
Switching to overlay2 will cause the storage to be shared with / and
will eliminate this performance overhead.   This is the way we will ship
Fedora Workstation.

On Fedora atomic host and Fedora server we have been storing
devicemapper storage on a separate partition.  We plan on doing the same
thing with overlay2.  This means separate device will be mounted on
/var/lib/docker.  This will make it easier for someone to switch back to
devicemapper, if overlay2 has problems.

Upgraded systems will not be effected. 

If you want to switch from one storage to another take a look at the
`atomic storage` commands.

We will write up release notes to cover this change. Along with a blog
explaining the commands to switch back and forth.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Brendan Conoboy]

On 01/06/2017 08:14 AM, Neal Gompa wrote:
[snip]

Much of what I would have said has been said by Oron (some of this
I've said in earlier parts of this thread, as well).  But the bigger
thing is that it makes it much easier to bootstrap new architectures
for Fedora, too, as we can start from libraries and build up to
applications relatively easily. It doesn't completely solve the issue,
as there would still be some conflicts, but it makes it a lot less
challenging. Enabling things like being able to do test and
development with arbitrary architectures would be a huge boon, as
well.

[snip]

Yes, beyond Oron's focus on embedded development the general reality 
is that it is a plain useful mechanism for using OS+architecture to do 
work on a different OS+architecture.  We could really have used 
something like this for the armhfp bootstrap, or the aarch64 
bootstrap, or the ppc64le bootstrap.  Add in the judicious use of qemu 
as the suse team does and making something new is considerably less 
hard.  X32, ilp32, mips, etc all face chicken-and-egg problems in 
bootstrap that this simplifies.  Who knows what will be next?


Multilib is likewise useful for backward compatibility across major 
releases and distributions.  If third party software vendors only had 
to qualify their software on one release of one distribution with the 
expectation that it would run on all because the dynamic libraries 
were available on all it would be a real win for Linux as a whole. 
The fact we don't have that is part of what is driving container adoption.


--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Kevin Kofler]

Matthew Miller wrote:
> This is a good point; we're already pretty much awful on this point,
> and let's not make it worse. (On the other hand, modularity has the
> potential to help significantly on this point, as you should't need
> detailed metadata about what's _inside_ a module at runtime in normal
> circumstances.)

At that point, we stop being a distribution and become a salad bar of bits 
and pieces that may or may not work together, where both look and feel 
integration and functional features will end up disabled because they would 
depend on libraries from another module, and that each contain their own 
redundant copies of the same libraries. I think that is a huge step 
backwards, and if actually fully implemented, will likely force me to switch 
to a different distribution.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Kevin Kofler]

Stephen Gallagher wrote:
> As Bill pointed out, things "just work" for users right now and that's
> something we'd like to avoid breaking. However, that does *not* mean that
> it is trivial to do on the build side. We're currently building out an
> entirely new infrastructure to support modules; we'd like to take a look
> at what we did the first time and see if (with more experience and
> hindsight) we can do a better job now, and ideally one we can share
> between the two approaches.

What was never discussed was whether modules are something worth rebuilding 
"an entirely new infrastructure" to begin with. I disagree that they are 
even a desirable feature to begin with, they just fragment and thus dilute 
the Fedora platform, and have the potential to seriously hurt integration 
across the distribution and increase code duplication and its resulting 
bloat.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Kevin Kofler]

Oron Peled wrote:
>  * With old, non-multiarch scheme:
>- Library packages compiled natively on ARM would be under /usr/lib.
>- But they cannot be installed on the build machine, so I can
>  cross-compile applications against them.
>- The workaround was to unpack them, relocate the libraries, headers,
>  etc to the prefix expected by cross compiler (e.g:
>  /opt/toolchain/) and repack the result into an "all" architecture
>  package.

The right way to do cross toolchains is to cross-build sysrooted packages 
from source in dedicated cross packages, which is how the Fedora cross 
toolchains work. Mixing binaries for completely different machines in the 
same directory tree, which will not even run on the host machine (or at 
best, very slowly through software emulation), strikes me as a horrible 
hack.

The de-facto standard for cross compilers (i.e., what, e.g., the GNU 
toolchain supports out of the box and defaults to) is /usr/$triplet 
(sysroot), not /usr/lib/$triplet (multiarch). And that is for a reason, 
because the former can accomodate /usr/$triplet/bin, /usr/$triplet/libexec 
etc. easily (or even /usr/$triplet/usr/bin etc. if desired, though in the 
current UsrMove world, those would likely be at most symlinks to the 
non-/usr variant), the latter cannot.

>  * With multiarch distribution (Debian/jessie in my case):
>- Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu
>  *regardless* if they were built natively or cross-compiled.
>- These packages may be co-installed on my development host and be used
>  by the cross compiler.
>- So I have an ARM repository, everything built (natively + cross) is
>  uploaded there and I can pull library dependencies into my build
>  environment.
>- And the *exact* same binary packages installed on the ARM target are
>  installed and being used by the cross compilers.

That will not work with Fedora packages, for a simple reason: Fedora 
packages often contain both executables and libraries. For multilib (which 
does not support the cross-compilation use case you mentioned), RPM 
automatically resolves the conflict between different ELF executables by 
"coloring" them with their architecture and then preferring one "color" over 
the other. E.g., it is clear that x86_64 binaries shall always be preferred 
over i686 ones, because if you have both, you are on a 64-bit system and 
will almost always want the native ones. But if RPM sees an x86 binary and 
an ARM binary, it will have absolutely no way to decide which one to prefer, 
so it will just raise a file conflict and you will not be able to install 
the package.

For Debian multiarch to work, we would also have to introduce Debian's 
aggressive subpackaging of libraries, which is IMHO not an improvement.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Kevin Kofler]

Neal Gompa wrote:
> I'd be happier if we just moved 32-bit libraries into /usr/lib32. That
> way /usr/lib can be only noarch libs (like noarch Python things, and
> stuff).

Noarch stuff should NOT be in /usr/lib to begin with! True noarch stuff 
should be in /usr/share. Arch-colored binaries should be in /usr/libexec.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Tom Hughes]

On 06/01/17 13:33, Stephen Gallagher wrote:

On 01/06/2017 08:04 AM, Jakub Jelinek wrote:

On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote:


For anyone who isn't familiar with this topic, you might find Debian's
documentation useful:

https://wiki.debian.org/Multiarch

One could take it a step further and actually have target triplets the
convey OS version of the libraries instead of the generic "-redhat-linux"
part of the tuple.  With a little rpath abuse apps compiled for F25 could
find their shared libraries in an F25 specific directory and multiple
versions of the same package could be installed at the same time, for
different OS versions.  This goes beyond Fedora, too: apps compiled for
Debian could find their shared libraries in a Debian specific directory,
even though it's a Fedora system that is booted.  A lot of fiddly details
and hand waving go here, but the end result would be really useful.


Noo!  Debian Multiarch is FHS incompatible, too ugly to live with and
doesn't bring benefits, it is just different.
Please don't introduce this into Fedora.


I added it to this list because it came up several times in the earlier thread.
I'm not sold on it. I'm CCing the people who suggested it directly to ask them
to chime in with what advantages they feel it would provide.


So to be honest I hadn't really expected Fedora to make the change but 
it was certainly the first thing that came to mind from the email subject.


If we were starting now to support multilib then I would certainly 
suggest that the Debian design is the better one but whether it's enough 
of an improvement to merit the pain of changing is a rather different 
question.


My reasons for thinking it's better are much the same as what other 
people have already said - that it treats all arches as equals and 
scales readily to whatever is needed rather than just bolting on a 
single 32/64 bit split as a kind of special case.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ZoneMinder retired from Fedora, moving to RPM Fusion.

[Chuck Anderson]

I have now retired zoneminder in master and fixed the depencency bug
for F25.  The zmrepo maintainer has joined Fedora and RPM Fusion and
will be maintaining the package in RPM Fusion.

Review requests and relevent bugs here:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4393
https://bugzilla.redhat.com/show_bug.cgi?id=1409869
https://bugzilla.redhat.com/show_bug.cgi?id=1409866
https://bugzilla.redhat.com/show_bug.cgi?id=1409803
https://bugzilla.redhat.com/show_bug.cgi?id=1409658
https://bugzilla.redhat.com/show_bug.cgi?id=1408872

On Sat, Dec 17, 2016 at 11:27:10PM -0500, Chuck Anderson wrote:
> I have orphaned zoneminder on all branches.
> 
> It has a number of bugs and crash reports in ABRT.  It now has broken
> deps:
> 
> zoneminder has broken dependencies in the rawhide tree:
> On x86_64:
>   zoneminder-1.28.1-6.fc25.x86_64 requires php-mysql
> On armhfp:
>   zoneminder-1.28.1-6.fc25.armv7hl requires php-mysql
> On ppc64le:
>   zoneminder-1.28.1-6.fc25.ppc64le requires php-mysql
> On aarch64:
>   zoneminder-1.28.1-6.fc25.aarch64 requires php-mysql
> On ppc64:
>   zoneminder-1.28.1-6.fc25.ppc64 requires php-mysql
> On i386:
>   zoneminder-1.28.1-6.fc25.i686 requires php-mysql
> Please resolve this as soon as possible.
> 
> I recommend anyone who was using it to instead use the zmrepo version.
> That version can/does use ffmpeg, so it supports more newer cameras.
> 
> If someone really wants this to stay in Fedora and/or EPEL, feel free
> to take it but I recommend starting over with the zmrepo src.rpm.  I
> was able to complete a zmrepo build with the ffmpeg, X10, and vlc
> requirements removed, but there are several missing requirements for
> CPAN modules that would need to be added.  I can provide my
> uncompleted work on this to anyone who is interested.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packages seeking new point of contact

[Jon Ciesla]

On Fri, Jan 6, 2017 at 10:55 AM, Kevin Fenzi  wrote:

> Greetings.
>
> rpms/php-pear-OLE -- Package for reading and writing OLE containers (
> master f25 f24 el6 el5 )
>
>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
Taken because moodle.

-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2017-01-06)

[Josh Boyer]

===
#fedora-meeting: FESCO (2017-01-06)
===


Meeting started by jwb at 16:00:18 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2017-01-06/fesco.2017-01-06-16.00.log.html
.



Meeting summary
---
* #1646 No appropriate sudo directory for user scripts  (jwb, 16:02:21)
  * LINK: https://pagure.io/fesco/issue/1646   (jwb, 16:02:21)
  * AGREED: FESCo does not support extending the set of paths to include
a custom script path (+7: 0: -0)  (jwb, 16:09:29)

* #1657 Unresponsive maintainer: ke4qqq  (jwb, 16:09:49)
  * LINK: https://pagure.io/fesco/issue/1657   (jwb, 16:09:50)
  * LINK: https://admin.fedoraproject.org/pkgdb/packager/ke4qqq/
(nirik, 16:11:43)
  * AGREED: FESCo agrees to orphan ke4qqq's packages and give sheepdog
to the reporter (+7:0:-0)  (jwb, 16:13:27)

* #1635 F26 Self Contained Changes  (jwb, 16:14:44)
  * LINK: https://pagure.io/fesco/issue/1635   (jwb, 16:14:44)
  * LINK: https://fedoraproject.org/wiki/Changes/golang-buildmode-pie
(jwb, 16:18:14)
  * LINK:
https://fedoraproject.org/wiki/Changes/FontconfigCacheDirChange
(jwb, 16:19:30)
  * AGREED: Defer golang PIE change until more data on performance
impact is available (7:0:-1)  (jwb, 16:27:13)
  * AGREED: FESCo defers the fontconfig cache change so that it can
gather more information (8:0:-0)  (jwb, 16:37:28)

* #1664 Orphaning of rrati's packages  (jwb, 16:38:02)
  * LINK: https://pagure.io/fesco/issue/1664   (jwb, 16:38:02)
  * AGREED: contact rrati and offer to orphan their packages or assist
them in doing so (8:0:-0)  (jwb, 16:40:19)

* #1663 How strongly should we recommend systemd sandboxing features?
  (jwb, 16:42:09)
  * LINK: https://pagure.io/fesco/issue/1663   (jwb, 16:42:09)
  * AGREED: jsmith to take initial stab at a concrete proposal and
present something in one month.  Help welcome (8:0:-0)  (jwb,
16:53:52)

* Next Week's Chair  (jwb, 16:54:00)
  * AGREED: dgilmore to chair next week  (jwb, 16:54:40)

* Open Floor  (jwb, 16:54:43)
  * Reminder that voting in Fedora elections (FESCo, Council, FAmSCo)
starts on January 10th  (jwb, 16:56:08)

Meeting ended at 16:57:05 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* jwb (92)
* sgallagh (42)
* dgilmore (38)
* jsmith (33)
* nirik (30)
* maxamillion (29)
* kalev (26)
* zodbot (13)
* paragan (9)
* Rathann (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Packages seeking new point of contact

[Kevin Fenzi]

Greetings. 

Per: https://pagure.io/fesco/issue/1657

there's a number of packages that are looking for a new maintainer now: 

rpms/blktap -- Blktap Userspace Tools + Library ( el6 )
rpms/ehcache-parent -- Ehcache Parent ( master f25 f24 )
rpms/ehcache-sizeof-agent -- Ehcache Size Of Agent ( master f25 f24 el6 )
rpms/perl-RT-Extension-CommandByMail -- Change metadata of a RT ticket via 
email ( el6 el5 )
rpms/php-IDNA_Convert -- Provides conversion of internationalized strings 
to UTF8 ( master f25 f24 epel7 el6 el5 )
rpms/php-channel-htmlpurifier -- Adds htmlpurifier channel to PEAR ( master 
f25 f24 el6 el5 )
rpms/php-fpdf -- PHP class to generate PDF Files ( master f25 f24 el6 el5 )
rpms/php-gettext -- Gettext emulation in PHP ( el6 el5 )
rpms/php-htmlpurifier-htmlpurifier -- Standards-compliant HTML filter 
library ( master f25 f24 el6 )
rpms/php-nusoap -- SOAP Toolkit for PHP ( master f25 f24 el6 el5 )
rpms/php-pear-File-Bittorrent2 -- Decode and Encode data in Bittorrent 
format ( master f25 f24 el6 el5 )
rpms/php-pear-OLE -- Package for reading and writing OLE containers ( 
master f25 f24 el6 el5 )
rpms/php-pear-Spreadsheet-Excel-Writer -- Package for generating Excel 
spreadsheets ( master f25 f24 el6 el5 )
rpms/php-simplepie -- A simple Atom/RSS parsing library for PHP ( master 
f25 f24 epel7 el6 el5 )
rpms/phpFlickr -- PHP client for the Flickr web service ( master f25 f24 
el6 el5 )
rpms/phpesp -- PHP-based survey web application ( master f25 f24 el6 el5 )
rpms/postal -- Tools for benchmarking mail servers ( master f25 f24 el6 el5 
)
rpms/pywbem -- Python2 WBEM Client and Provider Interface ( master f25 f24 
el6 el5 )
rpms/sahana -- Sahana is a free open source disaster management application 
( master f25 f24 el6 el5 )
rpms/sheepdog -- The Sheepdog Distributed Storage System for KVM/QEMU ( 
master f25 f24 el6 )
rpms/spew -- I/O performance measurement and load generation tool ( master 
f25 f24 el6 el5 )
rpms/xenserverjava -- Java SDK for XenServer ( master f25 f24 el6 )
rpms/xml-maven-plugin -- Maven XML Plugin ( master f25 f24 )
rpms/zapplet -- Zenoss Tray Applet ( master f25 f24 )
rpms/zikula -- Zikula is a free open source Web Application Framework ( el6 
el5 )
rpms/zikula-module-News -- Manages news articles on your Zikulasite ( el6 
el5 )

Please feel free to take any that interest you. 

kevin


pgpzKgXpTTCAu.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Igor Gnatenko]

On Jan 6, 2017 5:16 PM, "Neal Gompa"  wrote:

On Fri, Jan 6, 2017 at 10:17 AM, Oron Peled  wrote:
> On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote:
>
>> ...
>
>> * I do not see any practical advantage of Debian multiarch over FHS
>
>> multilib.
>
>
>
> Good question, multiarch is a huge win for *embedded* developers.
>
>
>
> Let me give real life example from my $day job:
>
> * We build stuff for arm and x86_64 (I ignore our legacy platforms
>
> like x86, ppc, whatnot...)
>
>
>
> * We cross compile most stuff (faster), but not everything is easily
>
> cross-compilable:
>
> - Notorious examples are libraries with their own code-generation tools.
>
> - Examples: thrift, dbus-c++ (you need to *run* built tools)
>
> - So we build some packages natively (either on real ARM or in chroot with
> qemu-user-static).
>
>
>
> * With old, non-multiarch scheme:
>
> - Library packages compiled natively on ARM would be under /usr/lib.
>
> - But they cannot be installed on the build machine, so I can
cross-compile
>
> applications against them.
>
> - The workaround was to unpack them, relocate the libraries, headers, etc
>
> to the prefix expected by cross compiler (e.g: /opt/toolchain/) and
>
> repack the result into an "all" architecture package.
>
>
>
> * With multiarch distribution (Debian/jessie in my case):
>
> - Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu
>
> *regardless* if they were built natively or cross-compiled.
>
> - These packages may be co-installed on my development host and be used
>
> by the cross compiler.
>
> - So I have an ARM repository, everything built (natively + cross) is
> uploaded
>
> there and I can pull library dependencies into my build environment.
>
> - And the *exact* same binary packages installed on the ARM target are
>
> installed and being used by the cross compilers.
>
>

Much of what I would have said has been said by Oron (some of this
I've said in earlier parts of this thread, as well).  But the bigger
thing is that it makes it much easier to bootstrap new architectures
for Fedora, too, as we can start from libraries and build up to
applications relatively easily. It doesn't completely solve the issue,
as there would still be some conflicts, but it makes it a lot less
challenging. Enabling things like being able to do test and
development with arbitrary architectures would be a huge boon, as
well.

That being said, I would be in remiss to indicate that platform
libdirs (what Debian calls multiarch libdirs) are able to be
implemented in a backwards-compatible way. Debian was able to pull it
off because they originally used /lib32 and /lib64, but migrated to
/lib/i386-linux-gnu and /lib/x86_64-linux-gnu (while creating symlinks
to point to them). We should be able to do the same.

If we touch this thing I would like to have /usr/lib/triple. At this moment
we don't have good cross-compiler support and this would help us (at least
to some degree).


The main break will be that /usr/lib will no longer contain archful
data, and that's going to be a difference no matter how you slice it.
We could elect to do /usr/lib32 and that would still be an improvement
of the situation over what we have now, but it's still a break (though
not necessarily one that will break third party applications).

If we don't want to do full platform libdirs, I would really like us
to move 32-bit libraries to /usr/lib32. It would just be much cleaner
on the filesystem that way.

If we do full platform libdirs, I would like us to have the symlinks
for /usr/lib32 and /usr/lib64 to point to the correct places, too.

--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1410774] perl-PDL-Graphics-PLplot-0.71-3.fc26 FTBFS

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||CPAN 119740



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

[Bug 1410774] perl-PDL-Graphics-PLplot-0.71-3.fc26 FTBFS

[bugzilla]

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



--- Comment #4 from Petr Pisar  ---
It happens even if I disable GSL support in PDL that is problematic on PowerPC.

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

Re: 2017-01-05 @ 18:00 UTC - Outage for qadevel.cloud replacement (for real this time)

[Tim Flink]

On Thu, 5 Jan 2017 18:07:10 -0700
Tim Flink  wrote:

> On Thu, 5 Jan 2017 10:42:09 -0700
> Tim Flink  wrote:
> 
> > I realize this is a little last minute but persona has been
> > completely shut down now (so auth is no longer possible) and the
> > last issue that was preventing migration was taken care of
> > yesterday.  
> 
> The outage is complete and phabricator has been successfully migrated
> to
> 
> https://phab.qa.fedoraproject.org/
> 
> Note the new hostname - you should be redirected to the new host if
> you use the old url, though.
> 
> I've changed the .arcconfig files for the taskotron-related repos. I
> think that I got the develop branch for everything but if you see one
> I missed, please fix it.

One thing that I forgot to mention - I had to mess around with the
database a bit to make the transition smooth and not require 10 steps
for everyone to be able to log in again. Part of that was assuming that
phab usernames are identical to FAS usernames.

If your phab username does not match your FAS username, let me know. I
can fix that but until I do fix it, you won't be able to log in.

Tim


pgpPTF4TKKMGq.pgp
Description: OpenPGP digital signature
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

[Bug 1410774] perl-PDL-Graphics-PLplot-0.71-3.fc26 FTBFS

[bugzilla]

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



--- Comment #3 from Petr Pisar  ---
This is the minimal reproducer:

use PDL;
use PDL::Config;
use PDL::Graphics::PLplot;

my $dev = 'xfig';

# Test shade plotting (low level interface)
plsdev ($dev);
plsfnam ("test12.$dev");
plspage (0,0, 600,600, 0,0);
plinit();
pladv (0);
plvpor(0.1, 0.9, 0.1, 0.9); 
plwind (-1, 1, -1, 1);
plpsty(0); 

my $nx = 35;
my $ny = 46;
my $x = (sequence($nx) - ($nx/2))/($nx/2);
my $y = (sequence($ny) - ($ny/2))/(($ny/2) - 1.0);
my $xv = $x->dummy(1, $y->nelem);
my $yv = $y->dummy(0, $x->nelem);
my $z = -sin(7*$xv) * cos (7*$yv) + $xv**2 - $yv**2;
my $nsteps = 15;
my ($zmin, $zmax) = $z->minmax;
my $clevel = ((sequence($nsteps)*(($zmax - $zmin)/($nsteps-1))) + $zmin);
my $xmap = ((sequence($nx)*(2/($nx-1))) + -1); # map X coords linearly to -1 to
1
my $ymap = ((sequence($ny)*(2/($ny-1))) + -1);
my $grid = plAllocGrid ($xmap, $ymap);
plshades($z, -1, 1, -1, 1,
 $clevel, 2,
 0, 0, 1, 
 0, \, $grid);

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

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Neal Gompa]

On Fri, Jan 6, 2017 at 10:17 AM, Oron Peled  wrote:
> On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote:
>
>> ...
>
>> * I do not see any practical advantage of Debian multiarch over FHS
>
>> multilib.
>
>
>
> Good question, multiarch is a huge win for *embedded* developers.
>
>
>
> Let me give real life example from my $day job:
>
> * We build stuff for arm and x86_64 (I ignore our legacy platforms
>
> like x86, ppc, whatnot...)
>
>
>
> * We cross compile most stuff (faster), but not everything is easily
>
> cross-compilable:
>
> - Notorious examples are libraries with their own code-generation tools.
>
> - Examples: thrift, dbus-c++ (you need to *run* built tools)
>
> - So we build some packages natively (either on real ARM or in chroot with
> qemu-user-static).
>
>
>
> * With old, non-multiarch scheme:
>
> - Library packages compiled natively on ARM would be under /usr/lib.
>
> - But they cannot be installed on the build machine, so I can cross-compile
>
> applications against them.
>
> - The workaround was to unpack them, relocate the libraries, headers, etc
>
> to the prefix expected by cross compiler (e.g: /opt/toolchain/) and
>
> repack the result into an "all" architecture package.
>
>
>
> * With multiarch distribution (Debian/jessie in my case):
>
> - Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu
>
> *regardless* if they were built natively or cross-compiled.
>
> - These packages may be co-installed on my development host and be used
>
> by the cross compiler.
>
> - So I have an ARM repository, everything built (natively + cross) is
> uploaded
>
> there and I can pull library dependencies into my build environment.
>
> - And the *exact* same binary packages installed on the ARM target are
>
> installed and being used by the cross compilers.
>
>

Much of what I would have said has been said by Oron (some of this
I've said in earlier parts of this thread, as well).  But the bigger
thing is that it makes it much easier to bootstrap new architectures
for Fedora, too, as we can start from libraries and build up to
applications relatively easily. It doesn't completely solve the issue,
as there would still be some conflicts, but it makes it a lot less
challenging. Enabling things like being able to do test and
development with arbitrary architectures would be a huge boon, as
well.

That being said, I would be in remiss to indicate that platform
libdirs (what Debian calls multiarch libdirs) are able to be
implemented in a backwards-compatible way. Debian was able to pull it
off because they originally used /lib32 and /lib64, but migrated to
/lib/i386-linux-gnu and /lib/x86_64-linux-gnu (while creating symlinks
to point to them). We should be able to do the same.

The main break will be that /usr/lib will no longer contain archful
data, and that's going to be a difference no matter how you slice it.
We could elect to do /usr/lib32 and that would still be an improvement
of the situation over what we have now, but it's still a break (though
not necessarily one that will break third party applications).

If we don't want to do full platform libdirs, I would really like us
to move 32-bit libraries to /usr/lib32. It would just be much cleaner
on the filesystem that way.

If we do full platform libdirs, I would like us to have the symlinks
for /usr/lib32 and /usr/lib64 to point to the correct places, too.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1410774] perl-PDL-Graphics-PLplot-0.71-3.fc26 FTBFS

[bugzilla]

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



--- Comment #2 from Petr Pisar  ---
It does not crash when running under gdb or when executed from vim. Maybe some
kind of a race condition.

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

[Bug 1410774] perl-PDL-Graphics-PLplot-0.71-3.fc26 FTBFS

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
The t/plplot.t crashes when executing "3D color plot, low level interface" test
when calling plshades() Perl subroutine:

#0  pltr1 (x=19.590623970008657, y=1, tx=0x3fffe3c621e8, ty=0x3fffe3c621f0,
pltr_data=0x1dde5cc0) at /usr/src/debug/plplot-5.11.1/src/plcont.c:896
#1  0x3fff8fe41cc4 in plshade_int (f2eval=,
f2eval_data=, defined=0x0, nx=, ny=, xmin=-1, xmax=, 
ymin=-1, ymax=, shade_min=,
shade_max=, sh_cmap=1, sh_color=0, sh_width=2, min_color=0,
min_width=, max_color=0, 
max_width=, fill=0x3fff8fe2df10 , rectangular=1,
pltr=0x3fff8fe1af00 , pltr_data=0x1dde5cc0,
UNUSED_c2eval_data=, 
c2eval=) at /usr/src/debug/plplot-5.11.1/src/plshade.c:666
#2  0x3fff8fe42b00 in plfshades (zops=0x3fff8fe80fd0 ,
zp=0x1001ddfc5c0, nx=, ny=, defined=0x0, xmin=-1,
xmax=1, ymin=-1, ymax=1, 
clevel=0x1001ddfb0a0, nlevel=15, fill_width=2, cont_color=0, cont_width=0,
fill=0x3fff8fe2df10 , rectangular=1, pltr=0x3fff8fe1af00 ,
pltr_data=0x1dde5cc0)
at /usr/src/debug/plplot-5.11.1/src/plshade.c:262
#3  0x3fff8fe42ee8 in c_plshades (a=0x1001ddfc5c0, nx=,
ny=, defined=0x0, xmin=, xmax=,
ymin=, 
ymax=, clevel=0x1001ddfb0a0, nlevel=15,
fill_width=, cont_color=0, cont_width=,
fill=0x3fff8fe2df10 , rectangular=1, 
pltr=0x3fff8fe1af00 , pltr_data=0x1dde5cc0) at
/usr/src/debug/plplot-5.11.1/src/plshade.c:211
#4  0x3fff8fef7ce4 in pdl_plshades_pp_readdata (__tr=0x1001de05d60) at
PLplot.xs:29263
#5  0x3fff905c1c24 in pdl__ensure_trans (trans=0x1001de05d60,
what=) at pdlapi.c:1227
#6  0x3fff905c3010 in pdl_make_trans_mutual (trans=0x1001de05d60) at
pdlapi.c:849
#7  0x3fff8ff19fac in XS_PDL_plshades_pp (my_perl=,
cv=) at PLplot.xs:56457
#8  0x3fff90f1c8fc in Perl_pp_entersub (my_perl=0x1001cb80010) at
pp_hot.c:3987
#9  0x3fff90f13508 in Perl_runops_standard (my_perl=0x1001cb80010) at
run.c:41
#10 0x3fff90e87124 in S_run_body (oldscope=,
my_perl=) at perl.c:2483
#11 perl_run (my_perl=0x1001cb80010) at perl.c:2406
#12 0x1de8 in main (argc=, argv=,
env=) at perlmain.c:116

The crash is in plplot library when dereferencing grid variable, debugger
states the pointer is inaccessible:

void
pltr1( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data )
{
PLINT   ul, ur, vl, vr;
PLFLT   du, dv;
PLFLT   xl, xr, yl, yr;

PLcGrid *grid = (PLcGrid *) pltr_data;
PLFLT   *xg   = grid->xg;
PLFLT   *yg   = grid->yg;
PLINT   nx= grid->nx;
→   PLINT   ny= grid->ny;

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

Re: Proposal: Rethink Fedora multilib support

[Stephen John Smoogen]

On 5 January 2017 at 19:29, Josh Boyer  wrote:
> On Thu, Jan 5, 2017 at 4:40 PM, Japheth Cleaver  
> wrote:
>> On 1/5/2017 9:12 AM, Jonathan Wakely wrote:
>>>
>>> On 05/01/17 09:56 -0700, Chris Murphy wrote:

 Teamviewer comes in an i686 only package for Fedora. So is there going
 to be this interim approach, and then yet another change when they're
 expected to use FlatPak? That's a lot of changes... And are these two
 approaches compatible with the other platforms they target, or are
 they just likely to drop the one it stops working on?

 I can hardly imagine Teamviewer is the only 32-bit only GUI program.
>>>
>>>
>>> There are all sorts of proprietary programs like Skype that are only
>>> provided as 32-bit packages (there's a "skypeforlinux" package which
>>> is 64-bit but it's an "alpha" release).
>>>
>>> Maybe it would work fine from inside a 32-bit container, I have no
>>> idea, but we should be careful not to make it harder for normal users
>>> to install and use software distributed outside Fedora. And not make
>>> it harder for ISVs to provide RPMs that work on Fedora with minimal
>>> effort.
>>
>>
>> I feel like if this happens it will hasten the day when those of us
>> primarily working in EL-variant land have to consider a need for a new,
>> EL-forward, RPM-based open source "community" OS.
>
> Can you elaborate why you think that?  Particularly the "EL-forward"
> part.  I don't understand how Stephen's line of thinking is not
> EL-forward.
>

I think it is because EL-forward means different things to different people.

1. Developer definition. EL-Forward is looking towards how something
will work in EL-next.
2. Enterprise operations. EL-Forward is looking towards how to take
something in current Fedora and move it forward to the version of
Enterprise you have deployed. [From a developer point of view it is
moving it backwards but it is because we are driving in two different
directions.]

A large amount of Enterprise ops people have to work in environments
with 30% of the systems being EL-5, 50% of the systems being EL-6 and
20% being EL-7. They have to both make corporate apps work with
ancient code bases but also get apps that need later items to make
things work. The work flow for this is

1. Find it in an 'approved' repo. [This was in the past EPEL but less
so due to aging items.]
2. Take the latest Fedora rpm and recompile/mangle the bits until it
works on EL5/EL6.
3. Get a bunch of tar-balls and make them work... but pay for the
upgrade problems later.

If they have problems in 2 or 1 they feed that back as bug reports and
considered that how they pushed Fedora forward. At some point they
would get to be able to install EL-8 and would have packages they knew
worked in Fedora from say Fedora-30 that would work for what they
needed.

Why does this not look forward to them?
1) They are still primarily having to deal with 32 bit applications.
2) They are only getting to virtualize their main environments. Yes
they have some systems somewhere in the giant bank IT that are
containered and that admin gets trotted out at docker con as the
forward way the world is working but 99% of the operations staff is
having to deal with an OS which is going to be EOL in 3 months and is
only now getting a budget which says they can move it to EL6. [They
can't move it to EL7 because the vendor still hasn't produced a
version of XYZ that 'works with systemd' (eg it relys on some initd
hack that they don't know how to fix to start up).]
3) Containers don't look baked yet. People are still arguing about how
to upgrade/update them.. the ones they google to see how it works of
them say they are read only but have instructions of 'install an ssh
and then log in and make these changes to really get it to work' etc
etc. Maybe Fedora will deliver all the packages in Fedora 27 with
docker formatting.. and maybe Fedora 28 will use a completely new
one..
4) The oracles they rely on to say this is how things are done in
Linux haven't agreed yet. The usual rule from previous technology
changes is don't bet on what the markets are using.. see what one
Linus uses for N months and if he doesn't like it see what he replaces
it with as that will be the way things go. [This is usually from
people who were burned deploying enterprise CVS, SVN, HG, BZR
solutions to have them all replaced with git in the last 5 years..
older admins have other Linus did it this way and everyone went that
way too.. the fact that Linus didn't have a tantrum and replace
systemd was pretty much the "ok it looks like this is the way things
are going"]

So if the OS they rely on to grab/build packages no longer offers a
way they can consume them (it has to be in a container which you will
need to run in your EL5/6 environment somehow..) then it can look like
the OS is no longer wanting EL to use it.

And it doesn't matter how much Red Hat says it is banking on

Re: Best practices for getting CFLAGS/LDFLAGS etc.

[Pavel Raiskup]

On Friday, January 6, 2017 3:24:46 PM CET Florian Weimer wrote:
> On 01/06/2017 03:20 PM, Pavel Raiskup wrote:
> > On Friday, January 6, 2017 3:02:22 PM CET Florian Weimer wrote:
> >>> Wouldn't it suffice to put PYTHON= at the end? autotools' configure
> >>> scripts accept such assignments (and even remember them in
> >>> config.status etc).
> >>
> >> Indeed, this looks like a reasonable solution.
> >
> > Is %configure only for auto-tooled configure?
> 
> Pretty much, the ./configure script must be sufficiently compatible.
> 
> > It could cause FTBFS otherwise.
> 
> It's something that has to be applied to the SPEC file anyway, so it's 
> not something that involves a global switch causing widespread breakage.

Sorry I should have catch this before -- sounds really reasonable.

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Oron Peled]

On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote:
> ...
> * I do not see any practical advantage of Debian multiarch over FHS
>   multilib.

Good question, multiarch is a huge win for *embedded* developers.

Let me give real life example from my $day job:
 * We build stuff for arm and x86_64 (I ignore our legacy platforms
   like x86, ppc, whatnot...)

 * We cross compile most stuff (faster), but not everything is easily
   cross-compilable:
   - Notorious examples are libraries with their own code-generation tools.
   - Examples: thrift, dbus-c++ (you need to *run* built tools)
   - So we build some packages natively (either on real ARM or in chroot with 
qemu-user-static).

 * With old, non-multiarch scheme:
   - Library packages compiled natively on ARM would be under /usr/lib.
   - But they cannot be installed on the build machine, so I can cross-compile
 applications against them.
   - The workaround was to unpack them, relocate the libraries, headers, etc
 to the prefix expected by cross compiler (e.g: /opt/toolchain/) and
 repack the result into an "all" architecture package.

 * With multiarch distribution (Debian/jessie in my case):
   - Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu
 *regardless* if they were built natively or cross-compiled.
   - These packages may be co-installed on my development host and be used
 by the cross compiler.
   - So I have an ARM repository, everything built (natively + cross) is 
uploaded
 there and I can pull library dependencies into my build environment.
   - And the *exact* same binary packages installed on the ARM target are
 installed and being used by the cross compilers.

This is by far better and cleaner than the multilib, but:
 * It is a very big change, far wider in scope than just library directories.
   (pkg-config, cross-compilers, dynamic linking, rpath, packaging tools, etc.)
 * Debian introduced it in Debian/wheezy (~2012) but the real benefits were
   reaped only since Debian/jessie (~2015) when many libraries were already
   pre-built as multiarch and Debian shipped a multiarch aware cross-compilers.
 * So, I'm ambivalent here -- multiarch is great, but it's a big change and
   I'm not sure it's worth it *for Fedora users*.
 * Meanwhile, I'll keep using Fedora (KDE) as my personal workstation/server OS
   but develop everything at $day job on Debian (KDE) and for Debian (targets).

Long live Linux ;-)

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron

"Debugging is at least twice as hard as writing the program in the 
first place.  So if your code is as clever as you can possibly make 
it, then by definition you're not smart enough to debug it." 
 -- Brian Kernighan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora rawhide compose report: 20170106.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20170105.n.0
NEW: Fedora-Rawhide-20170106.n.0

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

Size of added packages:  53.09 MiB
Size of dropped packages:0.00 B
Size of upgraded packages:   1.43 GiB
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   20.11 MiB
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-armhfp-Rawhide-20170105.n.0-sda.raw.xz
Image: LXDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20170105.n.0-sda.raw.xz

= ADDED PACKAGES =
Package: asgp-1.0.18-5.fc26
Summary: A 2D shooter on rails
RPMs:asgp asgp-data
Size:49620576 bytes

Package: blueberry-1.1.9-1.fc26
Summary: Bluetooth configuration tool
RPMs:blueberry
Size:1235294 bytes

Package: ghc-enclosed-exceptions-1.0.2-3.fc26
Summary: Catch exceptions within an enclosed computation
RPMs:ghc-enclosed-exceptions ghc-enclosed-exceptions-devel
Size:266424 bytes

Package: highcontrast-qt-0.1-1.fc26
Summary: HighContrast theme for Qt-based applications
RPMs:highcontrast-qt highcontrast-qt4 highcontrast-qt5
Size:2360752 bytes

Package: lxqt-build-tools-0.3.1-1.fc26
Summary: Packaging tools for LXQt
RPMs:lxqt-build-tools
Size:181980 bytes

Package: pantheon-terminal-0.4.0.3-2.fc26
Summary: The terminal of the 21st century
RPMs:pantheon-terminal
Size:980784 bytes

Package: python-aiohttp-negotiate-0.11-1.fc26
Summary: Add-on for Python aiohttp library to support Negotiate authentication
RPMs:python3-aiohttp-negotiate
Size:12490 bytes

Package: screenshot-tool-0.1.1-2.fc26
Summary: Simple screen capture tool
RPMs:screenshot-tool
Size:520852 bytes

Package: snap-photobooth-0.3.0.1-6.fc26
Summary: Fast and beautiful camera app
RPMs:snap-photobooth
Size:486396 bytes


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  adwaita-qt-0.97-2.fc26
Old package:  adwaita-qt-0.97-1.fc26
Summary:  Adwaita theme for Qt-based applications
RPMs: adwaita-qt adwaita-qt4 adwaita-qt5
Size: 2418740 bytes
Size change:  1484 bytes
Changelog:
  * Thu Jan 05 2017 Rex Dieter <rdie...@fedoraproject.org> - 0.97-2
  - drop hardcoded Requires: qt4/qt5-qtbase


Package:  antimony-0.9.3-0.3.20161128git41a770.fc26
Old package:  antimony-0.9.3-0.2.20161128git41a770.fc26
Summary:  Computer-aided design CAD tool
RPMs: antimony
Size: 3006540 bytes
Size change:  -67976 bytes
Changelog:
  * Thu Jan 05 2017 Antonio Trande  
0.9.3-0.3.2016070741a770
  - Conformed to new rules for scriptlets


Package:  apache-commons-parent-42-2.fc26
Old package:  apache-commons-parent-42-1.fc26
Summary:  Apache Commons Parent Pom
RPMs: apache-commons-parent
Size: 27770 bytes
Size change:  -240 bytes
Changelog:
  * Thu Jan 05 2017 Michael Simacek <msima...@redhat.com> - 42-2
  - Remove profiles for plugins that are useless in package builds


Package:  beakerlib-1.12-1.fc26
Old package:  beakerlib-1.11-2.fc24
Summary:  A shell-level integration testing library
RPMs: beakerlib beakerlib-vim-syntax
Size: 158076 bytes
Size change:  11084 bytes
Changelog:
  * Wed Jan 04 2017 Dalibor Pospisil <dapos...@redhat.com> - 1.12-1
  - added rlIsCentOS similar to rlIsRHEL, bz1214190
  - added missing dependencies, bz1391969
  - make rlRun use internal variables with more unique name, bz1285804
  - fix rlRun exitcodes while using various switches, bz1303900
  - make sure the output of rlRun while using -s is completely written to the 
file, bz1361246
  - rlFileRestore now better distinquish betwwen various errorneous situations, 
bz1370453
  - rlService* won't be blocked be less(1) while systemctl redirection is in 
place, bz1383303
  - rlWaitForSocket --close now waits for actuall closure, bz1388422
  - variable LibraryDir variable is created for all imported 
libraries, holding the path to the library source, bz1074487
  - all logging messages are now printed to stderr, bz1171881
  - wildcard %doc inclusion in spec, bz1206173
  - prevent unbound variables, bz1228264
  - new functions rlServiceEnabled/rlServiceDisable for enabling/disabling 
services, bz1234804
  - updated documentation for rlImport -all, bz1246061
  - rlAssertNotEquals now accept empty argument, bz1303618
  - rlRun now uses better filename for output log, bz1314700
  - fixed cosmetic discrepancy in log output, bz1374256
  - added documentation reference for bkrdoc, bz843823
  - added documentation of the testwatcher feature, bz1218169
  - rlServiceRestore can restore all saved services in no parameter provided, 
bz494318
  - rlCheckMount take mount options (ro/rw) into consideration, bz1191627
  - added documentation for LOG_LEVEL variable, bz581816


Pa

[389-devel] Please review: Ticket 49055 - Refactor create_test.py

[Simon Pichugin]

Hi team,
please, review my new patch for ds.

https://fedorahosted.org/389/ticket/49055
https://fedorahosted.org/389/attachment/ticket/49055/0001-Ticket-49055-Refactor-create_test.py.patch

Thanks,
Simon


signature.asc
Description: PGP signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-IO-Socket-SSL (perl-IO-Socket-SSL-2.043-1.fc26). "Update to 2.043 (..more)"

[notifications]

From 6a30f8ffc4824bb1233527a394d3003b4def97a0 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Fri, 6 Jan 2017 14:34:50 +
Subject: Update to 2.043
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- New upstream release 2.043
  - Enable session ticket callback with Net::SSLeay ≥ 1.80
  - Make t/session_ticket.t work with OpenSSL 1.1.0; with this version the
session no longer gets reused if it was not properly closed, which is now
done using an explicit close by the client
- Update patches as needed
---
 ...-SSL-2.041-use-system-default-SSL-version.patch | 36 
 ...-SSL-2.041-use-system-default-cipher-list.patch | 98 --
 ...-SSL-2.042-use-system-default-SSL-version.patch | 36 
 ...-SSL-2.042-use-system-default-cipher-list.patch | 98 ++
 perl-IO-Socket-SSL.spec| 14 +++-
 sources|  2 +-
 6 files changed, 146 insertions(+), 138 deletions(-)
 delete mode 100644 IO-Socket-SSL-2.041-use-system-default-SSL-version.patch
 delete mode 100644 IO-Socket-SSL-2.041-use-system-default-cipher-list.patch
 create mode 100644 IO-Socket-SSL-2.042-use-system-default-SSL-version.patch
 create mode 100644 IO-Socket-SSL-2.042-use-system-default-cipher-list.patch

diff --git a/IO-Socket-SSL-2.041-use-system-default-SSL-version.patch 
b/IO-Socket-SSL-2.041-use-system-default-SSL-version.patch
deleted file mode 100644
index 7d7c0af..000
--- a/IO-Socket-SSL-2.041-use-system-default-SSL-version.patch
+++ /dev/null
@@ -1,36 +0,0 @@
 lib/IO/Socket/SSL.pm
-+++ lib/IO/Socket/SSL.pm
-@@ -98,7 +98,7 @@ my $algo2digest = do {
- # global defaults
- my %DEFAULT_SSL_ARGS = (
- SSL_check_crl => 0,
--SSL_version => 'SSLv23:!SSLv3:!SSLv2', # consider both SSL3.0 and SSL2.0 
as broken
-+SSL_version => '',
- SSL_verify_callback => undef,
- SSL_verifycn_scheme => undef,  # fallback cn verification
- SSL_verifycn_publicsuffix => undef,  # fallback default list verification
-@@ -2220,7 +2220,7 @@ sub new {
- 
- my $ssl_op = $DEFAULT_SSL_OP;
- 
--my $ver;
-+my $ver = '';
- for (split(/\s*:\s*/,$arg_hash->{SSL_version})) {
-   m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1(?:_?[12])?))$}i
-   or croak("invalid SSL_version specified");
 lib/IO/Socket/SSL.pod
-+++ lib/IO/Socket/SSL.pod
-@@ -960,11 +960,12 @@ protocol to the specified version.
- All values are case-insensitive.  Instead of 'TLSv1_1' and 'TLSv1_2' one can
- also use 'TLSv11' and 'TLSv12'.  Support for 'TLSv1_1' and 'TLSv1_2' requires
- recent versions of Net::SSLeay and openssl.
-+The default SSL_version is defined by the underlying cryptographic library.
- 
- Independent from the handshake format you can limit to set of accepted SSL
- versions by adding !version separated by ':'.
- 
--The default SSL_version is 'SSLv23:!SSLv3:!SSLv2' which means, that the
-+For example, 'SSLv23:!SSLv3:!SSLv2' means that the
- handshake format is compatible to SSL2.0 and higher, but that the successful
- handshake is limited to TLS1.0 and higher, that is no SSL2.0 or SSL3.0 because
- both of these versions have serious security issues and should not be used
diff --git a/IO-Socket-SSL-2.041-use-system-default-cipher-list.patch 
b/IO-Socket-SSL-2.041-use-system-default-cipher-list.patch
deleted file mode 100644
index 1c8531d..000
--- a/IO-Socket-SSL-2.041-use-system-default-cipher-list.patch
+++ /dev/null
@@ -1,98 +0,0 @@
 lib/IO/Socket/SSL.pm
-+++ lib/IO/Socket/SSL.pm
-@@ -106,10 +106,10 @@ my %DEFAULT_SSL_ARGS = (
- SSL_npn_protocols => undef,# meaning depends whether on server or 
client side
- SSL_alpn_protocols => undef,   # list of protocols we'll accept/send, for 
example ['http/1.1','spdy/3.1']
- 
--# https://wiki.mozilla.org/Security/Server_Side_TLS, 2016/04/20
--# "Old backward compatibility" for best compatibility
--# .. "Most ciphers that are not clearly broken and dangerous to use are 
supported"
--SSL_cipher_list => 
'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP',
-+# Use system-wide default cipher list to support use of 

pghmcfc uploaded IO-Socket-SSL-2.043.tar.gz for perl-IO-Socket-SSL

[notifications]

91a49211c8aea107bdcfd886b276e3329f3e62fccce94c1700cd881d2282236b1f5714263dd4a9a3192c9f0bac0b73e11a0e19d18949855252994ed400462886
  IO-Socket-SSL-2.043.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-IO-Socket-SSL/IO-Socket-SSL-2.043.tar.gz/sha512/91a49211c8aea107bdcfd886b276e3329f3e62fccce94c1700cd881d2282236b1f5714263dd4a9a3192c9f0bac0b73e11a0e19d18949855252994ed400462886/IO-Socket-SSL-2.043.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-IO-Socket-SSL (master). "Update to 2.043 (..more)"

[notifications]

From 6a30f8ffc4824bb1233527a394d3003b4def97a0 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Fri, 6 Jan 2017 14:34:50 +
Subject: Update to 2.043
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- New upstream release 2.043
  - Enable session ticket callback with Net::SSLeay ≥ 1.80
  - Make t/session_ticket.t work with OpenSSL 1.1.0; with this version the
session no longer gets reused if it was not properly closed, which is now
done using an explicit close by the client
- Update patches as needed
---
 ...-SSL-2.041-use-system-default-SSL-version.patch | 36 
 ...-SSL-2.041-use-system-default-cipher-list.patch | 98 --
 ...-SSL-2.042-use-system-default-SSL-version.patch | 36 
 ...-SSL-2.042-use-system-default-cipher-list.patch | 98 ++
 perl-IO-Socket-SSL.spec| 14 +++-
 sources|  2 +-
 6 files changed, 146 insertions(+), 138 deletions(-)
 delete mode 100644 IO-Socket-SSL-2.041-use-system-default-SSL-version.patch
 delete mode 100644 IO-Socket-SSL-2.041-use-system-default-cipher-list.patch
 create mode 100644 IO-Socket-SSL-2.042-use-system-default-SSL-version.patch
 create mode 100644 IO-Socket-SSL-2.042-use-system-default-cipher-list.patch

diff --git a/IO-Socket-SSL-2.041-use-system-default-SSL-version.patch 
b/IO-Socket-SSL-2.041-use-system-default-SSL-version.patch
deleted file mode 100644
index 7d7c0af..000
--- a/IO-Socket-SSL-2.041-use-system-default-SSL-version.patch
+++ /dev/null
@@ -1,36 +0,0 @@
 lib/IO/Socket/SSL.pm
-+++ lib/IO/Socket/SSL.pm
-@@ -98,7 +98,7 @@ my $algo2digest = do {
- # global defaults
- my %DEFAULT_SSL_ARGS = (
- SSL_check_crl => 0,
--SSL_version => 'SSLv23:!SSLv3:!SSLv2', # consider both SSL3.0 and SSL2.0 
as broken
-+SSL_version => '',
- SSL_verify_callback => undef,
- SSL_verifycn_scheme => undef,  # fallback cn verification
- SSL_verifycn_publicsuffix => undef,  # fallback default list verification
-@@ -2220,7 +2220,7 @@ sub new {
- 
- my $ssl_op = $DEFAULT_SSL_OP;
- 
--my $ver;
-+my $ver = '';
- for (split(/\s*:\s*/,$arg_hash->{SSL_version})) {
-   m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1(?:_?[12])?))$}i
-   or croak("invalid SSL_version specified");
 lib/IO/Socket/SSL.pod
-+++ lib/IO/Socket/SSL.pod
-@@ -960,11 +960,12 @@ protocol to the specified version.
- All values are case-insensitive.  Instead of 'TLSv1_1' and 'TLSv1_2' one can
- also use 'TLSv11' and 'TLSv12'.  Support for 'TLSv1_1' and 'TLSv1_2' requires
- recent versions of Net::SSLeay and openssl.
-+The default SSL_version is defined by the underlying cryptographic library.
- 
- Independent from the handshake format you can limit to set of accepted SSL
- versions by adding !version separated by ':'.
- 
--The default SSL_version is 'SSLv23:!SSLv3:!SSLv2' which means, that the
-+For example, 'SSLv23:!SSLv3:!SSLv2' means that the
- handshake format is compatible to SSL2.0 and higher, but that the successful
- handshake is limited to TLS1.0 and higher, that is no SSL2.0 or SSL3.0 because
- both of these versions have serious security issues and should not be used
diff --git a/IO-Socket-SSL-2.041-use-system-default-cipher-list.patch 
b/IO-Socket-SSL-2.041-use-system-default-cipher-list.patch
deleted file mode 100644
index 1c8531d..000
--- a/IO-Socket-SSL-2.041-use-system-default-cipher-list.patch
+++ /dev/null
@@ -1,98 +0,0 @@
 lib/IO/Socket/SSL.pm
-+++ lib/IO/Socket/SSL.pm
-@@ -106,10 +106,10 @@ my %DEFAULT_SSL_ARGS = (
- SSL_npn_protocols => undef,# meaning depends whether on server or 
client side
- SSL_alpn_protocols => undef,   # list of protocols we'll accept/send, for 
example ['http/1.1','spdy/3.1']
- 
--# https://wiki.mozilla.org/Security/Server_Side_TLS, 2016/04/20
--# "Old backward compatibility" for best compatibility
--# .. "Most ciphers that are not clearly broken and dangerous to use are 
supported"
--SSL_cipher_list => 
'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP',
-+# Use system-wide default cipher list to support use of 

Broken dependencies: perl-ZeroMQ

[buildsys]

perl-ZeroMQ has broken dependencies in the rawhide tree:
On x86_64:
perl-ZeroMQ-0.23-13.fc25.x86_64 requires libzmq.so.1()(64bit)
On armhfp:
perl-ZeroMQ-0.23-13.fc25.armv7hl requires libzmq.so.1
On ppc64le:
perl-ZeroMQ-0.23-13.fc25.ppc64le requires libzmq.so.1()(64bit)
On aarch64:
perl-ZeroMQ-0.23-13.fc25.aarch64 requires libzmq.so.1()(64bit)
On ppc64:
perl-ZeroMQ-0.23-13.fc25.ppc64 requires libzmq.so.1()(64bit)
On i386:
perl-ZeroMQ-0.23-13.fc25.i686 requires libzmq.so.1
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-ZMQ-LibZMQ3

[buildsys]

perl-ZMQ-LibZMQ3 has broken dependencies in the rawhide tree:
On x86_64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.x86_64 requires libzmq.so.3()(64bit)
On armhfp:
perl-ZMQ-LibZMQ3-1.19-5.fc25.armv7hl requires libzmq.so.3
On ppc64le:
perl-ZMQ-LibZMQ3-1.19-5.fc25.ppc64le requires libzmq.so.3()(64bit)
On aarch64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.aarch64 requires libzmq.so.3()(64bit)
On ppc64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.ppc64 requires libzmq.so.3()(64bit)
On i386:
perl-ZMQ-LibZMQ3-1.19-5.fc25.i686 requires libzmq.so.3
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-ZMQ-LibZMQ2

[buildsys]

perl-ZMQ-LibZMQ2 has broken dependencies in the rawhide tree:
On x86_64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.x86_64 requires libzmq.so.1()(64bit)
On armhfp:
perl-ZMQ-LibZMQ2-1.09-9.fc25.armv7hl requires libzmq.so.1
On ppc64le:
perl-ZMQ-LibZMQ2-1.09-9.fc25.ppc64le requires libzmq.so.1()(64bit)
On aarch64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.aarch64 requires libzmq.so.1()(64bit)
On ppc64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.ppc64 requires libzmq.so.1()(64bit)
On i386:
perl-ZMQ-LibZMQ2-1.09-9.fc25.i686 requires libzmq.so.1
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-OpenOffice-UNO

[buildsys]

perl-OpenOffice-UNO has broken dependencies in the rawhide tree:
On armhfp:
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires libuno_cppu.so.3
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_cppu.so.3(LIBO_UDK_4.4)
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_cppu.so.3(UDK_3.1)
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_cppu.so.3(UDK_3_0_0)
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_cppuhelpergcc3.so.3
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires libuno_sal.so.3
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_sal.so.3(UDK_3_0_0)
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_salhelpergcc3.so.3
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
On ppc64le:
perl-Data-Alias-1.20-2.fc24.ppc64le requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.ppc64le requires perl(:MODULE_COMPAT_5.22.1)
On aarch64:
perl-Data-Alias-1.20-2.fc24.aarch64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.aarch64 requires perl(:MODULE_COMPAT_5.22.1)
On ppc64:
perl-Data-Alias-1.20-2.fc24.ppc64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.ppc64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

[Florian Weimer]

On 01/06/2017 03:20 PM, Pavel Raiskup wrote:

On Friday, January 6, 2017 3:02:22 PM CET Florian Weimer wrote:

Wouldn't it suffice to put PYTHON= at the end? autotools' configure
scripts accept such assignments (and even remember them in
config.status etc).


Indeed, this looks like a reasonable solution.


Is %configure only for auto-tooled configure?


Pretty much, the ./configure script must be sufficiently compatible.


It could cause FTBFS otherwise.


It's something that has to be applied to the SPEC file anyway, so it's 
not something that involves a global switch causing widespread breakage.


Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Alien-ROOT

[buildsys]

perl-Alien-ROOT has broken dependencies in the rawhide tree:
On aarch64:
perl-Alien-ROOT-5.34.36.1-2.fc26.noarch requires root-core
On ppc64:
perl-Alien-ROOT-5.34.36.1-2.fc26.noarch requires root-core
On ppc64le:
perl-Alien-ROOT-5.34.36.1-2.fc26.noarch requires root-core
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

[Pavel Raiskup]

On Friday, January 6, 2017 3:02:22 PM CET Florian Weimer wrote:
> > Wouldn't it suffice to put PYTHON= at the end? autotools' configure
> > scripts accept such assignments (and even remember them in
> > config.status etc).
> 
> Indeed, this looks like a reasonable solution.

Is %configure only for auto-tooled configure?  It could cause FTBFS otherwise.

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

[Florian Weimer]

On 01/06/2017 01:59 PM, Thomas Moschny wrote:

2017-01-05 14:01 GMT+01:00 Florian Weimer :

On 01/05/2017 11:58 AM, Michael Schwendt wrote:


On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:


It would also be nice if:

  PYTHON=/usr/bin/python3 %configure

didn't (silently) do the wrong thing by default.  For a long time we
shipped a nbdkit-python3 package which was using python2, and that was
found to be the cause.



And the configure script didn't accept the external definition of $PYTHON,
I guess. What could the %configure macro do about it?
If you look at "rpm -E %configure", anything it does wouldn't help, if
the parameters are ignore or don't make it into the Makefiles.



I suspect the problem is that the PYTHON=… setting is only applied to the
first shell command in the %configure expansion.  It's not the configure
invocation, just a plain variable assignment, so PYTHON is set, but not
exported to subprocesses (such as the future invocation of ./configure).

There is probably some shell hackery we could use to avoid that, but I don't
think more magic should be the goal.


Wouldn't it suffice to put PYTHON= at the end? autotools' configure
scripts accept such assignments (and even remember them in
config.status etc).


Indeed, this looks like a reasonable solution.

Thanks,
Florian


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

stevetraylen changed xavierb's 'commit' permission on perl-Crypt-SMIME (el6) to 'Approved'

[notifications]

stevetraylen changed xavierb's 'commit' permission on perl-Crypt-SMIME (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Crypt-SMIME/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

stevetraylen changed xavierb's 'commit' permission on perl-Crypt-SMIME (master) to 'Approved'

[notifications]

stevetraylen changed xavierb's 'commit' permission on perl-Crypt-SMIME (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Crypt-SMIME/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

stevetraylen changed xavierb's 'commit' permission on perl-Crypt-SMIME (epel7) to 'Approved'

[notifications]

stevetraylen changed xavierb's 'commit' permission on perl-Crypt-SMIME (epel7) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Crypt-SMIME/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

stevetraylen changed xavierb's 'commit' permission on perl-Crypt-SMIME (f25) to 'Approved'

[notifications]

stevetraylen changed xavierb's 'commit' permission on perl-Crypt-SMIME (f25) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Crypt-SMIME/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Matthew Miller]

On Fri, Jan 06, 2017 at 02:45:15PM +0100, drago01 wrote:
> because out of sync repositories. + Minor annoyances like additional
> (duplicated) meta data that you have to deal with (bandwidth, time to
> install packages / updates).

This is a good point; we're already pretty much awful on this point,
and let's not make it worse. (On the other hand, modularity has the
potential to help significantly on this point, as you should't need
detailed metadata about what's _inside_ a module at runtime in normal
circumstances.)

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Stephen Gallagher]

On 01/06/2017 08:45 AM, drago01 wrote:
> On Fri, Jan 6, 2017 at 2:24 PM, Stephen Gallagher  wrote:
>> On 01/06/2017 08:07 AM, drago01 wrote:
>>> On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher  
>>> wrote:
 On 01/06/2017 01:08 AM, drago01 wrote:
>
> Two suggestions were raised as alternatives to the container approach:
>
> * Switch to using the Debian style of multi-arch layout, which 
> instead of
> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to 
> this would
> include the emergence of a de-facto standard for system layout 
> between the major
> distributions.
>
> * Ship only one arch in the repositories and allow users to trivially 
> enable the
> repositories for other arches through DNF if they have need.
>
>
>
> *  Keep things as they are, which means things keep to "just work" (tm)

 As Bill pointed out, things "just work" for users right now and that's 
 something
 we'd like to avoid breaking. However, that does *not* mean that it is 
 trivial to
 do on the build side.
>>>
>>> That may be, but shifting the complexity to the user is simply not an
>>> option that we should seriously consider.
>>
>> You keep saying that, without describing what complexity you think is going 
>> to
>> hit the user.
> 
> Having to configure / setup / handle containers to run regular
> application is added complexity compared to simply running the
> applications.
> I think we both agree here because it is obvious ;)
> 

Reread this thread, please. This is the suggested non-container approach to
solve the problem.


>> I mean, if we shifted to the two-repo approach and shipped the
>> multi-arch repo as on-by-default, would the user experience change in any
>> visible way?
> 
> Not to the same extent as the container solution but yes it would.
> Multilib is not about just having a repo with every single package as
> 32bti version.
> It is mostly libraries + a few selected ones.
> As others have pointed you could accidentally get mixed packages
> because out of sync repositories. + Minor annoyances like additional
> (duplicated)
> meta data that you have to deal with (bandwidth, time to install
> packages / updates).

By "others", I'll note you are referring to me :)

Yes, but those are solvable problems. I'm thinking at this point that solving
those on the server-side might be a better (and more maintainable, long-term)
strategy than the hacks we have today.






signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[drago01]

On Fri, Jan 6, 2017 at 2:24 PM, Stephen Gallagher  wrote:
> On 01/06/2017 08:07 AM, drago01 wrote:
>> On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher  
>> wrote:
>>> On 01/06/2017 01:08 AM, drago01 wrote:

 Two suggestions were raised as alternatives to the container approach:

 * Switch to using the Debian style of multi-arch layout, which instead 
 of
 /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to 
 this would
 include the emergence of a de-facto standard for system layout between 
 the major
 distributions.

 * Ship only one arch in the repositories and allow users to trivially 
 enable the
 repositories for other arches through DNF if they have need.



 *  Keep things as they are, which means things keep to "just work" (tm)
>>>
>>> As Bill pointed out, things "just work" for users right now and that's 
>>> something
>>> we'd like to avoid breaking. However, that does *not* mean that it is 
>>> trivial to
>>> do on the build side.
>>
>> That may be, but shifting the complexity to the user is simply not an
>> option that we should seriously consider.
>
> You keep saying that, without describing what complexity you think is going to
> hit the user.

Having to configure / setup / handle containers to run regular
application is added complexity compared to simply running the
applications.
I think we both agree here because it is obvious ;)

> I mean, if we shifted to the two-repo approach and shipped the
> multi-arch repo as on-by-default, would the user experience change in any
> visible way?

Not to the same extent as the container solution but yes it would.
Multilib is not about just having a repo with every single package as
32bti version.
It is mostly libraries + a few selected ones.
As others have pointed you could accidentally get mixed packages
because out of sync repositories. + Minor annoyances like additional
(duplicated)
meta data that you have to deal with (bandwidth, time to install
packages / updates).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Stephen Gallagher]

On 01/06/2017 08:04 AM, Jakub Jelinek wrote:
> On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote:
>> On 01/05/2017 02:08 PM, Stephen Gallagher wrote:
>> [snip]
>>> == multi-arch layout ==
>>> * Moving the locations of all of the system libraries would potentially 
>>> still
>>> break third-party applications that were compiled to expect libraries to be 
>>> in
>>> the /usr/lib[64] paths. This would be a similar problem to the UsrMove 
>>> change
>>> and would likely be solved the same way; by maintaining symlinks in the old
>>> locations for some reasonable migration period. Given the enormous number of
>>> packages involved and the fact that it's not a simple directory rename, we 
>>> may
>>> need to add a hack into rpmbuild to automatically generate these symlinks 
>>> in the
>>> old location.
>>>
>>> * Switching to this layout might give a false (or possibly accurate, in some
>>> cases) impression that one could expect Debian/Ubuntu packages to function 
>>> "out
>>> of the box" on Fedora (if using something like Alien). Education is key 
>>> here.
>> [snip]
>>
>> For anyone who isn't familiar with this topic, you might find Debian's
>> documentation useful:
>>
>> https://wiki.debian.org/Multiarch
>>
>> One could take it a step further and actually have target triplets the
>> convey OS version of the libraries instead of the generic "-redhat-linux"
>> part of the tuple.  With a little rpath abuse apps compiled for F25 could
>> find their shared libraries in an F25 specific directory and multiple
>> versions of the same package could be installed at the same time, for
>> different OS versions.  This goes beyond Fedora, too: apps compiled for
>> Debian could find their shared libraries in a Debian specific directory,
>> even though it's a Fedora system that is booted.  A lot of fiddly details
>> and hand waving go here, but the end result would be really useful.
> 
> Noo!  Debian Multiarch is FHS incompatible, too ugly to live with and
> doesn't bring benefits, it is just different.
> Please don't introduce this into Fedora.

I added it to this list because it came up several times in the earlier thread.
I'm not sold on it. I'm CCing the people who suggested it directly to ask them
to chime in with what advantages they feel it would provide.

As to the FHS? It's a standard in the same way that CIM is a standard: it's a
great starting point and we try to stay as close as possible to it, but if it
doesn't meet our needs, we'll work around it.





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Debugging random suspend?

[Roberto Ragusa]

On 01/04/2017 06:55 AM, John Reiser wrote:

> One of the causes of Suspend is the hardware generating the signal for
> "the laptop lid has been closed."  Look at the boot messages ("dmesg"
> or "journalctl -b") for info on the power switch, the lid switch, etc.
> 

Or low battery level.
If the battery is incorrectly reported at 1% or 0% for an instant, suspend 
could be triggered.

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Stephen Gallagher]

On 01/06/2017 08:07 AM, drago01 wrote:
> On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher  wrote:
>> On 01/06/2017 01:08 AM, drago01 wrote:
>>>
>>> Two suggestions were raised as alternatives to the container approach:
>>>
>>> * Switch to using the Debian style of multi-arch layout, which instead 
>>> of
>>> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this 
>>> would
>>> include the emergence of a de-facto standard for system layout between 
>>> the major
>>> distributions.
>>>
>>> * Ship only one arch in the repositories and allow users to trivially 
>>> enable the
>>> repositories for other arches through DNF if they have need.
>>>
>>>
>>>
>>> *  Keep things as they are, which means things keep to "just work" (tm)
>>
>> As Bill pointed out, things "just work" for users right now and that's 
>> something
>> we'd like to avoid breaking. However, that does *not* mean that it is 
>> trivial to
>> do on the build side.
> 
> That may be, but shifting the complexity to the user is simply not an
> option that we should seriously consider.

You keep saying that, without describing what complexity you think is going to
hit the user. I mean, if we shifted to the two-repo approach and shipped the
multi-arch repo as on-by-default, would the user experience change in any
visible way?




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Build of asgp failed since update to libclaw-1.7.4-16.fc25

[Martin Gansser]

don't know if this output is importend ?

[root@fc25 tmp]# claw-config --libs
-L/usr/lib64/ 

[root@fc25 tmp]# claw-config application --libs
-L/usr/lib64/ -lclaw_application -lclaw_logger

[root@fc25 tmp]# claw-config dynamic_library --libs
-L/usr/lib64/ -lclaw_dynamic_library -ldl

[root@fc25 tmp]# claw-config all --libs 
-L/usr/lib64/ -lclaw_application -lclaw_logger -lclaw_dynamic_library -ldl 
-lclaw_configuration_file -lclaw_graphic -lpng -lz -ljpeg -lclaw_logger 
-lclaw_net -lclaw_tween

[root@fc25 tmp]# claw-config --cflags
-I/usr/include/ -DCLAW_JPEG_SUPPORT -DCLAW_PNG_SUPPORT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[drago01]

On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher  wrote:
> On 01/06/2017 01:08 AM, drago01 wrote:
>>
>> Two suggestions were raised as alternatives to the container approach:
>>
>> * Switch to using the Debian style of multi-arch layout, which instead of
>> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this 
>> would
>> include the emergence of a de-facto standard for system layout between 
>> the major
>> distributions.
>>
>> * Ship only one arch in the repositories and allow users to trivially 
>> enable the
>> repositories for other arches through DNF if they have need.
>>
>>
>>
>> *  Keep things as they are, which means things keep to "just work" (tm)
>
> As Bill pointed out, things "just work" for users right now and that's 
> something
> we'd like to avoid breaking. However, that does *not* mean that it is trivial 
> to
> do on the build side.

That may be, but shifting the complexity to the user is simply not an
option that we should seriously consider.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Stephen Gallagher]

On 01/06/2017 07:33 AM, Jonathan Wakely wrote:
> On 05/01/17 14:42 -0500, Randy Barlow wrote:
>> On Thu, 2017-01-05 at 17:02 +, Jonathan Wakely wrote:
>>> Which definitely changes how software is built.
>>
>> Containers also change the way software must be written in some cases,
>> since they expect there to be one main process and don't expect that
>> main process to interact with other "main" processes on the system.
>> There are some program architectures that aren't well suited to be run
>> in containers since containers expect programs to work in specific
>> ways. I don't think they are general enough to cover all use cases.
>>
>> I also expect that users will not appreciate being forced to use
>> containers if they want to keep being able to do things they can do
>> today. Offering it to them as an option rather than the only solution
>> is probably a friendlier approach.
> 
> 
> That would certainly be a problem if the proposal was to run each
> 32-bit application in its own container environment, but I think the
> suggestion is to have a single 32-bit container used by all 32-bit
> software. With that approach all the 32-bit software would be able to
> interact with the rest of the 32-bit system, there wouldn't be
> segregation between them.
> 


Yes, I was unclear about this, but that was where I was going with it. A single
32-bit container whose purpose was to share the 32-bit runtime. That being said,
the counter-proposal of figuring out how to keep the layout the same as today
but keeping the content in separate repositories is compelling and I'm
investigating that further.


> But we would need to consider how a 32-bit application starts other
> programs via things like xdg-open. Would you have to have a 32-bit
> browser installed so that you could click on links in 32-bit
> applications? Would xdg-utils have to be installed on the system
> twice, once in the 64-bit host and once in the 32-bit container? And
> install things like Firefox and image viewers twice?

Very good questions and I don't have all the answers right now, but again, I
think the "separate repository" solution might be closer, as the end result
should keep things in the same hierarchy.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Neal Gompa]

On Fri, Jan 6, 2017 at 8:04 AM, Jakub Jelinek  wrote:
> On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote:
>> On 01/05/2017 02:08 PM, Stephen Gallagher wrote:
>> [snip]
>> > == multi-arch layout ==
>> > * Moving the locations of all of the system libraries would potentially 
>> > still
>> > break third-party applications that were compiled to expect libraries to 
>> > be in
>> > the /usr/lib[64] paths. This would be a similar problem to the UsrMove 
>> > change
>> > and would likely be solved the same way; by maintaining symlinks in the old
>> > locations for some reasonable migration period. Given the enormous number 
>> > of
>> > packages involved and the fact that it's not a simple directory rename, we 
>> > may
>> > need to add a hack into rpmbuild to automatically generate these symlinks 
>> > in the
>> > old location.
>> >
>> > * Switching to this layout might give a false (or possibly accurate, in 
>> > some
>> > cases) impression that one could expect Debian/Ubuntu packages to function 
>> > "out
>> > of the box" on Fedora (if using something like Alien). Education is key 
>> > here.
>> [snip]
>>
>> For anyone who isn't familiar with this topic, you might find Debian's
>> documentation useful:
>>
>> https://wiki.debian.org/Multiarch
>>
>> One could take it a step further and actually have target triplets the
>> convey OS version of the libraries instead of the generic "-redhat-linux"
>> part of the tuple.  With a little rpath abuse apps compiled for F25 could
>> find their shared libraries in an F25 specific directory and multiple
>> versions of the same package could be installed at the same time, for
>> different OS versions.  This goes beyond Fedora, too: apps compiled for
>> Debian could find their shared libraries in a Debian specific directory,
>> even though it's a Fedora system that is booted.  A lot of fiddly details
>> and hand waving go here, but the end result would be really useful.
>
> Noo!  Debian Multiarch is FHS incompatible, too ugly to live with and
> doesn't bring benefits, it is just different.
> Please don't introduce this into Fedora.

I'd be happier if we just moved 32-bit libraries into /usr/lib32. That
way /usr/lib can be only noarch libs (like noarch Python things, and
stuff).



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Jakub Jelinek]

On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote:
> On 01/05/2017 02:08 PM, Stephen Gallagher wrote:
> [snip]
> > == multi-arch layout ==
> > * Moving the locations of all of the system libraries would potentially 
> > still
> > break third-party applications that were compiled to expect libraries to be 
> > in
> > the /usr/lib[64] paths. This would be a similar problem to the UsrMove 
> > change
> > and would likely be solved the same way; by maintaining symlinks in the old
> > locations for some reasonable migration period. Given the enormous number of
> > packages involved and the fact that it's not a simple directory rename, we 
> > may
> > need to add a hack into rpmbuild to automatically generate these symlinks 
> > in the
> > old location.
> > 
> > * Switching to this layout might give a false (or possibly accurate, in some
> > cases) impression that one could expect Debian/Ubuntu packages to function 
> > "out
> > of the box" on Fedora (if using something like Alien). Education is key 
> > here.
> [snip]
> 
> For anyone who isn't familiar with this topic, you might find Debian's
> documentation useful:
> 
> https://wiki.debian.org/Multiarch
> 
> One could take it a step further and actually have target triplets the
> convey OS version of the libraries instead of the generic "-redhat-linux"
> part of the tuple.  With a little rpath abuse apps compiled for F25 could
> find their shared libraries in an F25 specific directory and multiple
> versions of the same package could be installed at the same time, for
> different OS versions.  This goes beyond Fedora, too: apps compiled for
> Debian could find their shared libraries in a Debian specific directory,
> even though it's a Fedora system that is booted.  A lot of fiddly details
> and hand waving go here, but the end result would be really useful.

Noo!  Debian Multiarch is FHS incompatible, too ugly to live with and
doesn't bring benefits, it is just different.
Please don't introduce this into Fedora.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

[Thomas Moschny]

2017-01-05 14:01 GMT+01:00 Florian Weimer :
> On 01/05/2017 11:58 AM, Michael Schwendt wrote:
>>
>> On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:
>>
>>> It would also be nice if:
>>>
>>>   PYTHON=/usr/bin/python3 %configure
>>>
>>> didn't (silently) do the wrong thing by default.  For a long time we
>>> shipped a nbdkit-python3 package which was using python2, and that was
>>> found to be the cause.
>>
>>
>> And the configure script didn't accept the external definition of $PYTHON,
>> I guess. What could the %configure macro do about it?
>> If you look at "rpm -E %configure", anything it does wouldn't help, if
>> the parameters are ignore or don't make it into the Makefiles.
>
>
> I suspect the problem is that the PYTHON=… setting is only applied to the
> first shell command in the %configure expansion.  It's not the configure
> invocation, just a plain variable assignment, so PYTHON is set, but not
> exported to subprocesses (such as the future invocation of ./configure).
>
> There is probably some shell hackery we could use to avoid that, but I don't
> think more magic should be the goal.

Wouldn't it suffice to put PYTHON= at the end? autotools' configure
scripts accept such assignments (and even remember them in
config.status etc).

- Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Stephen Gallagher]

On 01/06/2017 01:08 AM, drago01 wrote:
> 
> Two suggestions were raised as alternatives to the container approach:
> 
> * Switch to using the Debian style of multi-arch layout, which instead of
> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this 
> would
> include the emergence of a de-facto standard for system layout between 
> the major
> distributions.
> 
> * Ship only one arch in the repositories and allow users to trivially 
> enable the
> repositories for other arches through DNF if they have need.
> 
> 
> 
> *  Keep things as they are, which means things keep to "just work" (tm)

As Bill pointed out, things "just work" for users right now and that's something
we'd like to avoid breaking. However, that does *not* mean that it is trivial to
do on the build side. We're currently building out an entirely new
infrastructure to support modules; we'd like to take a look at what we did the
first time and see if (with more experience and hindsight) we can do a better
job now, and ideally one we can share between the two approaches.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Stephen Gallagher]

On 01/05/2017 10:35 PM, Bill Nottingham wrote:
> Stephen Gallagher (sgall...@redhat.com) said: 
>> The main reason for this is trying to simplify the module-building process. 
>> We
>> really don't want to attempt to build both arches within the same buildroot 
>> for
>> most of the reasons we've established in this extended conversation. My first
>> proposal was one possible approach for this, but this second idea would solve
>> the same problem, possibly with less jarring impact.
> 
> While I fully understand how our current multilib system is a mess for the
> build and release process (being in certain respects responsible), I'm leery
> of using that to make drastic changes.
> 
> The whole point of building an OS/module/etc for users is to keep the
> complexity on the build side and out of the users hands - they don't care
> whether half the packages switched from autoconf to meson, whether twenty
> things are now written in Rust, or whether the entire python stack jumped
> minor (or major!) versions.  They just want the system to upgrade and the
> software they use to keep working.
> 
> If the multilib change only brings benefits to our build process and breaks
> user cases without offering significant benefits to them, I can't see the
> justification for it until we can offer end-user benefits (... ostree?).

Part of the situation is that we're building a new build process to deal with
modules. In that situation, we're trying to avoid some of the complexity that
has grown up over the years with our traditional build system. What my goal is
here is to figure out a strategy that can work for both efforts so we don't have
two completely different workarounds for the same problem.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Bastien Nocera]

- Original Message -
> On 05/01/17 14:42 -0500, Randy Barlow wrote:
> >On Thu, 2017-01-05 at 17:02 +, Jonathan Wakely wrote:
> >> Which definitely changes how software is built.
> >
> >Containers also change the way software must be written in some cases,
> >since they expect there to be one main process and don't expect that
> >main process to interact with other "main" processes on the system.
> >There are some program architectures that aren't well suited to be run
> >in containers since containers expect programs to work in specific
> >ways. I don't think they are general enough to cover all use cases.
> >
> >I also expect that users will not appreciate being forced to use
> >containers if they want to keep being able to do things they can do
> >today. Offering it to them as an option rather than the only solution
> >is probably a friendlier approach.
> 
> 
> That would certainly be a problem if the proposal was to run each
> 32-bit application in its own container environment, but I think the
> suggestion is to have a single 32-bit container used by all 32-bit
> software. With that approach all the 32-bit software would be able to
> interact with the rest of the 32-bit system, there wouldn't be
> segregation between them.
> 
> But we would need to consider how a 32-bit application starts other
> programs via things like xdg-open. Would you have to have a 32-bit
> browser installed so that you could click on links in 32-bit
> applications? Would xdg-utils have to be installed on the system
> twice, once in the 64-bit host and once in the 32-bit container? And
> install things like Firefox and image viewers twice?

I wonder how that would work when 1) you need access outside the sandbox
(say to play audio through PulseAudio, which needs an ALSA 32-bit plugin),
or 2) the 32-bit binary is a plugin (remember 32-bit Flash inside Firefox
with the nppluginwrapper?).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1410774] New: perl-PDL-Graphics-PLplot-0.71-3.fc26 FTBFS

[bugzilla]

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

Bug ID: 1410774
   Summary: perl-PDL-Graphics-PLplot-0.71-3.fc26 FTBFS
   Product: Fedora
   Version: rawhide
 Component: perl-PDL-Graphics-PLplot
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com



perl-PDL-Graphics-PLplot-0.71-3.fc26 fails to build in F26 because tests fail
on 64-bit PowerPC:

t/plplot.t  
All 15 subtests passed 
sh: line 1: 28335 Segmentation fault  (core dumped) perl -Mblib ./t/x09.pl
-dev svg -o x09p.svg -fam > /dev/null 2>&1
#   Failed test 'Script ./t/x09.pl ran successfully'
#   at t/plplot_library_tests.t line 68.
#   Failed test 'Output file x09p.svg.2 matches C output'
#   at t/plplot_library_tests.t line 74.
sh: line 1: 28730 Segmentation fault  (core dumped) perl -Mblib ./t/x22.pl
-dev svg -o x22p.svg -fam > /dev/null 2>&1
#   Failed test 'Script ./t/x22.pl ran successfully'
#   at t/plplot_library_tests.t line 68.
#   Failed test 'Output file x22p.svg.1 matches C output'
#   at t/plplot_library_tests.t line 74.
# Looks like you failed 4 tests of 221.
t/plplot_library_tests.t .. 
Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/221 subtests 
Test Summary Report
---
t/plplot.t  (Wstat: 139 Tests: 15 Failed: 0)
  Non-zero wait status: 139
  Parse errors: No plan found in TAP output
t/plplot_library_tests.t (Wstat: 1024 Tests: 221 Failed: 4)
  Failed tests:  67, 69, 122-123
  Non-zero exit status: 4
Files=2, Tests=236, 41 wallclock secs ( 0.05 usr  0.01 sys + 13.73 cusr  1.06
csys = 14.85 CPU)
Result: FAIL

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

Re: Proposal: Rethink Fedora multilib support

[Jonathan Wakely]

On 05/01/17 14:42 -0500, Randy Barlow wrote:

On Thu, 2017-01-05 at 17:02 +, Jonathan Wakely wrote:

Which definitely changes how software is built.


Containers also change the way software must be written in some cases,
since they expect there to be one main process and don't expect that
main process to interact with other "main" processes on the system.
There are some program architectures that aren't well suited to be run
in containers since containers expect programs to work in specific
ways. I don't think they are general enough to cover all use cases.

I also expect that users will not appreciate being forced to use
containers if they want to keep being able to do things they can do
today. Offering it to them as an option rather than the only solution
is probably a friendlier approach.



That would certainly be a problem if the proposal was to run each
32-bit application in its own container environment, but I think the
suggestion is to have a single 32-bit container used by all 32-bit
software. With that approach all the 32-bit software would be able to
interact with the rest of the 32-bit system, there wouldn't be
segregation between them.

But we would need to consider how a 32-bit application starts other
programs via things like xdg-open. Would you have to have a 32-bit
browser installed so that you could click on links in 32-bit
applications? Would xdg-utils have to be installed on the system
twice, once in the 64-bit host and once in the 32-bit container? And
install things like Firefox and image viewers twice?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-Mouse (perl-Mouse-2.4.6-1.fc26). "Update to 2.4.6 (..more)"

[notifications]

From cbbd5570812fde303db0131813f04f92f8450ecb Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Fri, 6 Jan 2017 11:31:36 +
Subject: Update to 2.4.6

- New upstream release 2.4.6
  - Fix test for older Perls (GH#68)
  - Define macros for older Visual Studio compiler (GH#66)
- Simplify find command using -empty and -delete
---
 .gitignore  |  2 +-
 auto.ini| 11 ---
 perl-Mouse.spec | 21 ++---
 sources |  2 +-
 4 files changed, 16 insertions(+), 20 deletions(-)
 delete mode 100644 auto.ini

diff --git a/.gitignore b/.gitignore
index 30ebe7c..0380cd0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,2 @@
 /Mouse-[0-9.]*.tar.gz
-/Mouse-v2.4.5.tar.gz
+/Mouse-v[0-9.]*.tar.gz
diff --git a/auto.ini b/auto.ini
deleted file mode 100644
index 3249301..000
--- a/auto.ini
+++ /dev/null
@@ -1,11 +0,0 @@
-[add_build_requires]
-; "soft" requires
-perl(Class::Method::Modifiers)=0
-perl(MRO::Compat)=0
-; testing
-perl(Moose)=0
-perl(Test::Deep)=0
-perl(Test::Output)=0
-perl(Path::Class)=0
-perl(IO::File)=0
-perl(IO::String)=0
diff --git a/perl-Mouse.spec b/perl-Mouse.spec
index a839edc..7c53a2d 100644
--- a/perl-Mouse.spec
+++ b/perl-Mouse.spec
@@ -1,12 +1,14 @@
 Name:   perl-Mouse
 Summary:Moose minus the antlers
-Version:2.4.5
-Release:7%{?dist}
+Version:2.4.6
+Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Mouse
-Source0:
http://search.cpan.org/CPAN/authors/id/S/SY/SYOHEX/Mouse-v%{version}.tar.gz 
+Source0:
http://search.cpan.org/CPAN/authors/id/S/SY/SYOHEX/Mouse-v%{version}.tar.gz
 # Module Build
+BuildRequires:  coreutils
+BuildRequires:  findutils
 BuildRequires:  perl
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
@@ -14,7 +16,6 @@ BuildRequires:  perl(Devel::PPPort) >= 3.19
 BuildRequires:  perl(ExtUtils::ParseXS)
 BuildRequires:  perl(Fatal)
 BuildRequires:  perl(File::Basename)
-BuildRequires:  perl(File::Copy)
 BuildRequires:  perl(File::Find)
 BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(Module::Build::XSUtil)
@@ -119,8 +120,8 @@ perl Build.PL --installdirs=vendor
 
 %install
 ./Build install --destdir=%{buildroot} --create_packlist=0
-find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
-%{_fixperms} %{buildroot}
+find %{buildroot} -type f -name '*.bs' -empty -delete
+%{_fixperms} -c %{buildroot}
 
 %check
 ./Build test
@@ -167,6 +168,12 @@ find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm 
-f {} ';'
 %{_mandir}/man3/Test::Mouse.3*
 
 %changelog
+* Fri Jan  6 2017 Paul Howarth  - 2.4.6-1
+- Update to 2.4.6
+  - Fix test for older Perls (GH#68)
+  - Define macros for older Visual Studio compiler (GH#66)
+- Simplify find command using -empty and -delete
+
 * Fri Sep 02 2016 Petr Pisar  - 2.4.5-7
 - Enable optional test with Data::Dump::Steamer (bug #1231204)
 
@@ -334,7 +341,7 @@ find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm 
-f {} ';'
 - add perl_default_filter
 - we're no longer noarch
 - auto-update to 0.47 (by cpan-spec-update 0.01)
-- added a new br on perl(Devel::PPPort) 
+- added a new br on perl(Devel::PPPort)
 - added a new br on perl(ExtUtils::ParseXS)
 - added a new br on perl(XSLoader) (version 0.1)
 - added a new req on perl(Scalar::Util) (version 1.14)
diff --git a/sources b/sources
index a9e2fff..16820ea 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2183f5bc16c7d37df5cf1dacf8ef88a1  Mouse-v2.4.5.tar.gz
+SHA512 (Mouse-v2.4.6.tar.gz) = 
3427891a5249f701768342e97af4db6c6b2c1fd186f5286f13a585647581e7d3d27bd13507db00153d5446d278ada3f7bbcbeae862dc304f6094b5358c75e96f
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mouse.git/commit/?h=perl-Mouse-2.4.6-1.fc26=cbbd5570812fde303db0131813f04f92f8450ecb
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1410723] perl-Mouse-2.4.6 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||p...@city-fan.org
   Fixed In Version||perl-Mouse-2.4.6-1.fc26
 Resolution|--- |RAWHIDE
   Assignee|emman...@seyman.fr  |p...@city-fan.org
Last Closed||2017-01-06 07:08:14



--- Comment #2 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17178302

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

pghmcfc pushed to perl-Mouse (master). "Update to 2.4.6 (..more)"

[notifications]

From cbbd5570812fde303db0131813f04f92f8450ecb Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Fri, 6 Jan 2017 11:31:36 +
Subject: Update to 2.4.6

- New upstream release 2.4.6
  - Fix test for older Perls (GH#68)
  - Define macros for older Visual Studio compiler (GH#66)
- Simplify find command using -empty and -delete
---
 .gitignore  |  2 +-
 auto.ini| 11 ---
 perl-Mouse.spec | 21 ++---
 sources |  2 +-
 4 files changed, 16 insertions(+), 20 deletions(-)
 delete mode 100644 auto.ini

diff --git a/.gitignore b/.gitignore
index 30ebe7c..0380cd0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,2 @@
 /Mouse-[0-9.]*.tar.gz
-/Mouse-v2.4.5.tar.gz
+/Mouse-v[0-9.]*.tar.gz
diff --git a/auto.ini b/auto.ini
deleted file mode 100644
index 3249301..000
--- a/auto.ini
+++ /dev/null
@@ -1,11 +0,0 @@
-[add_build_requires]
-; "soft" requires
-perl(Class::Method::Modifiers)=0
-perl(MRO::Compat)=0
-; testing
-perl(Moose)=0
-perl(Test::Deep)=0
-perl(Test::Output)=0
-perl(Path::Class)=0
-perl(IO::File)=0
-perl(IO::String)=0
diff --git a/perl-Mouse.spec b/perl-Mouse.spec
index a839edc..7c53a2d 100644
--- a/perl-Mouse.spec
+++ b/perl-Mouse.spec
@@ -1,12 +1,14 @@
 Name:   perl-Mouse
 Summary:Moose minus the antlers
-Version:2.4.5
-Release:7%{?dist}
+Version:2.4.6
+Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Mouse
-Source0:
http://search.cpan.org/CPAN/authors/id/S/SY/SYOHEX/Mouse-v%{version}.tar.gz 
+Source0:
http://search.cpan.org/CPAN/authors/id/S/SY/SYOHEX/Mouse-v%{version}.tar.gz
 # Module Build
+BuildRequires:  coreutils
+BuildRequires:  findutils
 BuildRequires:  perl
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
@@ -14,7 +16,6 @@ BuildRequires:  perl(Devel::PPPort) >= 3.19
 BuildRequires:  perl(ExtUtils::ParseXS)
 BuildRequires:  perl(Fatal)
 BuildRequires:  perl(File::Basename)
-BuildRequires:  perl(File::Copy)
 BuildRequires:  perl(File::Find)
 BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(Module::Build::XSUtil)
@@ -119,8 +120,8 @@ perl Build.PL --installdirs=vendor
 
 %install
 ./Build install --destdir=%{buildroot} --create_packlist=0
-find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
-%{_fixperms} %{buildroot}
+find %{buildroot} -type f -name '*.bs' -empty -delete
+%{_fixperms} -c %{buildroot}
 
 %check
 ./Build test
@@ -167,6 +168,12 @@ find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm 
-f {} ';'
 %{_mandir}/man3/Test::Mouse.3*
 
 %changelog
+* Fri Jan  6 2017 Paul Howarth  - 2.4.6-1
+- Update to 2.4.6
+  - Fix test for older Perls (GH#68)
+  - Define macros for older Visual Studio compiler (GH#66)
+- Simplify find command using -empty and -delete
+
 * Fri Sep 02 2016 Petr Pisar  - 2.4.5-7
 - Enable optional test with Data::Dump::Steamer (bug #1231204)
 
@@ -334,7 +341,7 @@ find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm 
-f {} ';'
 - add perl_default_filter
 - we're no longer noarch
 - auto-update to 0.47 (by cpan-spec-update 0.01)
-- added a new br on perl(Devel::PPPort) 
+- added a new br on perl(Devel::PPPort)
 - added a new br on perl(ExtUtils::ParseXS)
 - added a new br on perl(XSLoader) (version 0.1)
 - added a new req on perl(Scalar::Util) (version 1.14)
diff --git a/sources b/sources
index a9e2fff..16820ea 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2183f5bc16c7d37df5cf1dacf8ef88a1  Mouse-v2.4.5.tar.gz
+SHA512 (Mouse-v2.4.6.tar.gz) = 
3427891a5249f701768342e97af4db6c6b2c1fd186f5286f13a585647581e7d3d27bd13507db00153d5446d278ada3f7bbcbeae862dc304f6094b5358c75e96f
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mouse.git/commit/?h=master=cbbd5570812fde303db0131813f04f92f8450ecb
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc uploaded Mouse-v2.4.6.tar.gz for perl-Mouse

[notifications]

3427891a5249f701768342e97af4db6c6b2c1fd186f5286f13a585647581e7d3d27bd13507db00153d5446d278ada3f7bbcbeae862dc304f6094b5358c75e96f
  Mouse-v2.4.6.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Mouse/Mouse-v2.4.6.tar.gz/sha512/3427891a5249f701768342e97af4db6c6b2c1fd186f5286f13a585647581e7d3d27bd13507db00153d5446d278ada3f7bbcbeae862dc304f6094b5358c75e96f/Mouse-v2.4.6.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Build of asgp failed since update to libclaw-1.7.4-16.fc25

[Michael Schwendt]

On Fri, 06 Jan 2017 09:07:55 -, Martin Gansser wrote:

> See koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=17175933
> 
> An update of libclaw had to be done because of a problem with mock, see
> Https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JKVA4N45H5U2VNZ5KALSP6QNNA44V6H3/
> 
> error message:
> [  5%] Linking CXX executable ../../bin/andy-super-great-park
> cd 
> /home/martin/rpmbuild/BUILD/asgp-90d6d90e3196d387dc58f028a04e75af2281e513/asgp/launcher/src
>  && /usr/bin/cmake -E cmake_link_script 
> CMakeFiles/andy-super-great-park.dir/link.txt --verbose=1
> /usr/bin/c++   -O2 -g -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
> --param=ssp-buffer-size=4 -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic  -DNDEBUG  
>  -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> CMakeFiles/andy-super-great-park.dir/code/launcher.cpp.o 
> CMakeFiles/andy-super-great-park.dir/code/main.cpp.o  -o 
> ../../bin/andy-super-great-park  -L/usr/lib64/bear  -L/usr/lib64/libjpeg.so  
> -L/usr/lib64/libpng.so  
> -L/home/martin/rpmbuild/BUILD/asgp-90d6d90e3196d387dc58f028a04e75af2281e513/asgp/bin
>   -L/usr/include/bear/bear-engine/bin -rdynamic -lbear_engine 
> -lclaw_application -lclaw_logger 
> -Wl,-rpath,/usr/lib64/bear:/usr/lib64/libjpeg.so:/usr/lib64/libpng.so:/home/martin/rpmbuild/BUILD/asgp-90d6d90e3196d387dc58f028a04e75af2281e513/asgp/bin:/usr/include/bear/bear-engine/bin:
>  
> /usr/lib64/bear/libbear_engine.so: undefined reference to 
> `claw::tween::single_tweener::single_tweener(double, double, double, 
> boost::function, boost::function)'
> collect2: error: ld returned 1 exit status

> ps: build in rawhide is fine: 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=17169650
> 
> how can i solve the problem ?

Very likely by linking also with -lclaw_tween and not only the other two
libclaw libs.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of perl-Module-Install-DOAPChangeSets

[notifications]

pkgdb_updater updated: description of perl-Module-Install-DOAPChangeSets

https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-DOAPChangeSets/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl (master). "Remove bundled Math-BigRat"

[notifications]

From 9338edd12693f7f8f9e4f4fcb96cce23a72d2710 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 6 Jan 2017 10:27:13 +0100
Subject: Remove bundled Math-BigRat

---
 perl.spec | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/perl.spec b/perl.spec
index 77db289..01a2deb 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1871,7 +1871,6 @@ Conflicts:  perl < 4:5.22.0-348
 
 %description Math-BigInt-FastCalc
 This package provides support for faster big integer calculations.
-%endif
 
 %package Math-BigRat
 Summary:Arbitrary big rational numbers
@@ -1891,6 +1890,7 @@ Conflicts:  perl < 4:5.22.0-348
 %description Math-BigRat
 Math::BigRat complements Math::BigInt and Math::BigFloat by providing support
 for arbitrary big rational numbers.
+%endif
 
 %package Math-Complex
 Summary:Complex numbers and trigonometric functions
@@ -4854,12 +4854,12 @@ popd
 %{archlib}/Math
 %{archlib}/auto/Math
 %{_mandir}/man3/Math::BigInt::FastCalc.*
-%endif
 
 %files Math-BigRat
 %dir %{privlib}/Math
 %{privlib}/Math/BigRat.pm
 %{_mandir}/man3/Math::BigRat.*
+%endif
 
 %files Math-Complex
 %dir %{privlib}/Math
@@ -5272,6 +5272,7 @@ popd
 %changelog
 * Fri Jan 06 2017 Petr Pisar  - 4:5.24.0-383
 - Remove bundled Math-BigInt-FastCalc (bug #1408463)
+- Remove bundled Math-BigRat (bug #1408467)
 
 * Mon Dec 19 2016 Petr Pisar  - 4:5.24.0-382
 - Fix a crash in optimized evaluation of "or ((0) x 0))" (RT#130247)
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl.git/commit/?h=master=9338edd12693f7f8f9e4f4fcb96cce23a72d2710
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl (master). "Remove bundled bignum"

[notifications]

From 98fe061fe3378d1ef708824df7846dbe4a5b7a06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 6 Jan 2017 10:36:37 +0100
Subject: Remove bundled bignum

---
 perl.spec | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/perl.spec b/perl.spec
index 01a2deb..0edd27b 100644
--- a/perl.spec
+++ b/perl.spec
@@ -627,10 +627,9 @@ Conflicts:  perl < 4:5.20.1-310
 %description B-Debug
 Walk Perl syntax tree and print debug information about op-codes. See
 B::Concise and B::Terse for other details.
-%endif
 
 %package bignum
-Summary:Use BigInts and BigFloats transparently
+Summary:Transparent big number support for Perl
 Group:  Development/Libraries
 License:GPL+ or Artistic
 Epoch:  0
@@ -650,7 +649,6 @@ Conflicts:  perl < 4:5.22.0-348
 This package attempts to make it easier to write scripts that use BigInts and
 BigFloats in a transparent way.
 
-%if %{dual_life} || %{rebuild_from_scratch}
 %package Carp
 Summary:Alternative warn and die for modules
 Epoch:  0
@@ -4257,7 +4255,6 @@ popd
 %dir %{privlib}/B
 %{privlib}/B/Debug.pm
 %{_mandir}/man3/B::Debug.3*
-%endif
 
 %files bignum
 %{privlib}/bigint.pm
@@ -4271,7 +4268,6 @@ popd
 %{_mandir}/man3/bignum.*
 %{_mandir}/man3/bigrat.*
 
-%if %{dual_life} || %{rebuild_from_scratch}
 %files Carp
 %{privlib}/Carp
 %{privlib}/Carp.*
@@ -5273,6 +5269,7 @@ popd
 * Fri Jan 06 2017 Petr Pisar  - 4:5.24.0-383
 - Remove bundled Math-BigInt-FastCalc (bug #1408463)
 - Remove bundled Math-BigRat (bug #1408467)
+- Remove bundled bignum (bug #1409585)
 
 * Mon Dec 19 2016 Petr Pisar  - 4:5.24.0-382
 - Fix a crash in optimized evaluation of "or ((0) x 0))" (RT#130247)
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl.git/commit/?h=master=98fe061fe3378d1ef708824df7846dbe4a5b7a06
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl (master). "Remove bundled Math-BigInt-FastCalc"

[notifications]

From 260c5ba45cd2b048ce00aeb2bfe0fd40257a3c13 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 6 Jan 2017 10:15:16 +0100
Subject: Remove bundled Math-BigInt-FastCalc

---
 perl.spec | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/perl.spec b/perl.spec
index c1c866f..77db289 100644
--- a/perl.spec
+++ b/perl.spec
@@ -28,7 +28,7 @@
 Name:   perl
 Version:%{perl_version}
 # release number must be even higher, because dual-lived modules will be 
broken otherwise
-Release:382%{?dist}
+Release:383%{?dist}
 Epoch:  %{perl_epoch}
 Summary:Practical Extraction and Report Language
 Group:  Development/Languages
@@ -1855,14 +1855,14 @@ Conflicts:  perl < 4:5.22.0-347
 
 %description Math-BigInt
 This provides Perl modules for arbitrary-size integer and float mathematics.
-%endif
 
 %package Math-BigInt-FastCalc
 Summary:Math::BigInt::Calc XS implementation
 Group:  Development/Libraries
 License:GPL+ or Artistic
 Epoch:  0
-Version:0.40
+# Version normalized to dot format
+Version:0.400
 Requires:   %perl_compat
 %if %{defined perl_bootstrap}
 %gendep_perl_Math_BigInt_FastCalc
@@ -1871,6 +1871,7 @@ Conflicts:  perl < 4:5.22.0-348
 
 %description Math-BigInt-FastCalc
 This package provides support for faster big integer calculations.
+%endif
 
 %package Math-BigRat
 Summary:Arbitrary big rational numbers
@@ -4848,12 +4849,12 @@ popd
 %{_mandir}/man3/Math::BigInt.*
 %{_mandir}/man3/Math::BigInt::Calc.*
 %{_mandir}/man3/Math::BigInt::CalcEmu.*
-%endif
 
 %files Math-BigInt-FastCalc
 %{archlib}/Math
 %{archlib}/auto/Math
 %{_mandir}/man3/Math::BigInt::FastCalc.*
+%endif
 
 %files Math-BigRat
 %dir %{privlib}/Math
@@ -5269,6 +5270,9 @@ popd
 
 # Old changelog entries are preserved in CVS.
 %changelog
+* Fri Jan 06 2017 Petr Pisar  - 4:5.24.0-383
+- Remove bundled Math-BigInt-FastCalc (bug #1408463)
+
 * Mon Dec 19 2016 Petr Pisar  - 4:5.24.0-382
 - Fix a crash in optimized evaluation of "or ((0) x 0))" (RT#130247)
 - Fix a memory leak in IO::Poll (RT#129788)
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl.git/commit/?h=master=260c5ba45cd2b048ce00aeb2bfe0fd40257a3c13
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Fedora Linux subsystem on Windows machine

[Vít Ondruch]

Dne 6.1.2017 v 10:03 Martin Bříza napsal(a):
> On Fri, 06 Jan 2017 10:01:01 +0100, Vít Ondruch 
> wrote:
>
>>
>>
>> Dne 5.1.2017 v 20:11 M. Edward (Ed) Borasky napsal(a):
>>>
>>>
>>>
>>>
>>> And speaking of Wine, how come the Windows 10 Linux subsystem only
>>> runs Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows
>>> machine?
>>
>> Just FYI:
>>
>>
>> http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora
>>
>>
>> Vít
>
> I think that doesn't work anymore. But there's this project that
> should work now [0], while being more user friendly and versatile.
>
> [0] https://github.com/RoliSoft/WSL-Distribution-Switcher

Thanks for pointing this out. I knew I saw something more advanced, but
already forgot what it was ;) I am not windows user mysefl ...


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchbugzilla' permission on perl-bignum (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on perl-bignum (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-bignum/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'approveacls' permission on perl-bignum (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'approveacls' permission on perl-bignum (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-bignum/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-bignum (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on perl-bignum (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-bignum/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'commit' permission on perl-bignum (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'commit' permission on perl-bignum (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-bignum/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Math-BigRat (master). "Correct a typo in a comment"

[notifications]

From 73e5c9e78708fb2c74a6600a013796f9798e1571 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 6 Jan 2017 10:21:37 +0100
Subject: Correct a typo in a comment

---
 perl-Math-BigRat.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-Math-BigRat.spec b/perl-Math-BigRat.spec
index 93a5ecf..6e57102 100644
--- a/perl-Math-BigRat.spec
+++ b/perl-Math-BigRat.spec
@@ -1,5 +1,5 @@
 Name:   perl-Math-BigRat
-# Keep 4-digit version to compete for perl.spec
+# Keep 4-digit version to compete with perl.spec
 Version:0.2611
 Release:1%{?dist}
 Summary:Arbitrary big rational numbers
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Math-BigRat.git/commit/?h=master=73e5c9e78708fb2c74a6600a013796f9798e1571
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Math-BigRat (master). "Import"

[notifications]

From 3ec52e43e9f010178aae0ee31aef2d3d019ef24c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 6 Jan 2017 10:20:25 +0100
Subject: Import

---
 .gitignore|  1 +
 perl-Math-BigRat.spec | 64 +++
 sources   |  1 +
 3 files changed, 66 insertions(+)
 create mode 100644 perl-Math-BigRat.spec

diff --git a/.gitignore b/.gitignore
index e69de29..2d34463 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Math-BigRat-0.2611.tar.gz
diff --git a/perl-Math-BigRat.spec b/perl-Math-BigRat.spec
new file mode 100644
index 000..93a5ecf
--- /dev/null
+++ b/perl-Math-BigRat.spec
@@ -0,0 +1,64 @@
+Name:   perl-Math-BigRat
+# Keep 4-digit version to compete for perl.spec
+Version:0.2611
+Release:1%{?dist}
+Summary:Arbitrary big rational numbers
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/Math-BigRat/
+Source0:
http://www.cpan.org/authors/id/P/PJ/PJACKLAM/Math-BigRat-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  findutils
+BuildRequires:  make
+BuildRequires:  perl
+BuildRequires:  perl-generators
+BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
+# Run-time:
+BuildRequires:  perl(:VERSION) >= 5.6.0
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(Math::BigFloat)
+BuildRequires:  perl(Math::BigInt) >= 1.999718
+BuildRequires:  perl(overload)
+# Tests:
+BuildRequires:  perl(Exporter)
+BuildRequires:  perl(lib)
+# Math::Complex not used
+# Scalar::Util not used
+BuildRequires:  perl(Test::More) >= 0.82
+# Optional tests:
+# Module::Signature not used and not helpful
+# Socket not used
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:   perl(Math::BigInt) >= 1.999718
+Conflicts:  perl < 4:5.22.0-348
+
+%description
+Math::BigRat complements Math::BigInt and Math::BigFloat by providing
+support for arbitrary big rational numbers.
+
+%prep
+%setup -q -n Math-BigRat-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -delete
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%license LICENSE
+%doc BUGS CHANGES README TODO
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Dec 23 2016 Petr Pisar  0.2611-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..6019fbc 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+SHA512 (Math-BigRat-0.2611.tar.gz) = 
11e9b3dabeb196db835d58fec10fdb9d5d2c3a0498377d25645cdab1720682933aecbe516579cbfc0acee28bfcb930a3f7468af979987d9c3d6984dfa8f1584a
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Math-BigRat.git/commit/?h=master=3ec52e43e9f010178aae0ee31aef2d3d019ef24c
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar uploaded Math-BigRat-0.2611.tar.gz for perl-Math-BigRat

[notifications]

11e9b3dabeb196db835d58fec10fdb9d5d2c3a0498377d25645cdab1720682933aecbe516579cbfc0acee28bfcb930a3f7468af979987d9c3d6984dfa8f1584a
  Math-BigRat-0.2611.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Math-BigRat/Math-BigRat-0.2611.tar.gz/sha512/11e9b3dabeb196db835d58fec10fdb9d5d2c3a0498377d25645cdab1720682933aecbe516579cbfc0acee28bfcb930a3f7468af979987d9c3d6984dfa8f1584a/Math-BigRat-0.2611.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'approveacls' permission on perl-Math-BigRat (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'approveacls' permission on perl-Math-BigRat (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Math-BigRat/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-Math-BigRat (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on perl-Math-BigRat 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Math-BigRat/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org