Re: F25 Self Contained Change: IBus Emoji Typing

2016-07-07 Thread Takao Fujiwara 

On 07/08/16 00:25, Mike FABIAN-san wrote:

Bastien Nocera  さんはかきました:


Re-send to the change owner

- Original Message -

= Proposed Self Contained Change: IBus Emoji Typing  =
https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing

Change owner(s):
* Takao Fujiwara 

The IBus core will provide the Emoji Unicode typing with the IBus XKB
engines.

== Detailed Description ==
IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now
we
think the similar implementation for the Emoji typging. With IBus XKB
engines,
Emoji typing will be provided with the Emoji annotations [1] following Ctrl-
Shift-e.

== Scope ==
* Proposal owners:
 - IBus core provide the dictionary of the Emoji typing.
 - IBus XKB engines load the Emoji dictionary.

* Other developers: N/A

* Release engineering: N/A
 - List of deliverables: N/A

* Policies and guidelines: N/A

* Trademark approval: N/A

[1] http://unicode.org/emoji/charts/index.html#col-annotations


Will this use:
https://github.com/lalomartins/ibus-uniemoji/
?


I don’t think so, it is supposed to work in all xkb engines of
ibus-typing booster, this is not a seperate engine like ibus-uniemoji.


Sorry, I missed the email.
I expect to use emoji not to switch the IBus engines.
Actually ibus-anthy already implements emoji typing in Japanese.

This implementation enables emoji typing in English with any IBus XKB engines.
I also evaluated ibus-uniemoji:
http://unicode.org/pipermail/unicode/2016-June/003781.html
http://unicode.org/pipermail/unicode/2016-July/003786.html

Now IBus XKB engine uses both en.xml for annotations and emoji.json for 
categories and ascii aliases.




It would be great if this feature used the emoji fonts directly, so we
can use colour icons:
http://www.hadess.net/2016/05/blog-backlog-post-1-emoji.html


The font shown in this blog seems to be one the fonts contained in the
nodejs-emojione package which Fujiwara San is packaging for this change
request.

There seem to be some problems with the font though:

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

But freetype nicely displays it in colour:

https://bugzilla.redhat.com/show_bug.cgi?id=1350700#c3
https://bugzilla.redhat.com/attachment.cgi?id=1176850


I think it would be a desktop font setting?
It would be strange for me if IBus lookup table and text applications show the 
different fonts.

Fujiwara




Cheers
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[389-devel] Re: Logging performance improvement

2016-07-07 Thread William Brown 
On Thu, 2016-07-07 at 09:25 -0400, Mark Reynolds wrote:
> William,
> 
> Yes this looks great, but I think we should apply this to the audit and
> errors log as well.  We always have the problem of enabling verbose
> error logging because of the severe performance impact it has
> (especially since the errors log is not buffered).  Having all the logs
> using this model would be very useful for DS users and the support team.

I was planning to use this for *all* our logging subsystems. Not just
access. I want to consolidate and simplify this area of the code.


> >
> > This is looking a great idea. You are proposing to use liblfds to
> > communicate with the log write. Do you think dbus would be an other
> > option ? Would it help external mechanism to collect the DS logs ?

There is no reason that the log event after it comes out the queue can't
be sent to:

* Directory Server logs
* Syslog
* Splunk
* Someone's email
* pipe / dbus / something else to an external process.

I still am against journald as an option, due to it's technical
limitations. 


> >
> > thanks
> > thierry
> >
> > On 07/01/2016 03:52 AM, William Brown wrote:
> >> Hi,
> >>
> >> I've been thinking about this for a while, so I decided to dump my
> >> thoughts to a document. I think I won't get to implementing this for a
> >> while, but it would really help our server performance.
> >>
> >> http://www.port389.org/docs/389ds/design/logging-performance-improvement.html
> >>
> >>
> >>
> >> --
> >> 389-devel mailing list
> >> 389-devel@lists.fedoraproject.org
> >> https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
> >
> >
> >
> > --
> > 389-devel mailing list
> > 389-devel@lists.fedoraproject.org
> > https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
> 

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

2016-07-07 Thread Richard W.M. Jones 
On Wed, Jul 06, 2016 at 02:52:34PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 06, 2016 at 02:11:31PM +0200, Petr Lautrbach wrote:
> > On 07/04/2016 05:34 PM, Richard W.M. Jones wrote:
> > > I don't exactly know where to post this, but I guess I have everyone's
> > > attention on this thread.
> > > 
> > > Attached are patches which work for me.  They could really do with
> > > review from someone who knows what they're doing.  They also need much
> > > more testing than I've done, but I'll be doing that myself later.
> > > 
> > > The first patch (against libselinux) sets SELinux to Permissive mode
> > > early in boot if the /.autorelabel file is found (or autorelabel on
> > > the command line).
> > 
> > I don't think it's a good idea to change the library this way. It would
> > add another configuration point where the mode can be changed and it
> > would depend on the service (which can be even masked) from other
> > package and if this service didn't clear /.autorelabel the system would
> > stay in permissive mode.
> 
> That patch is the answer to the (repeated) bug reports that relabelling
> fails if enforcing=1 and the labels are sufficiently messed up.
> Doing the relabel in permissive mode, without ever going to enforcing
> mode, seems like the most reliable way out in this case. Starting in
> enforcing mode first, and then switching back to permissive later
> is a complication that increased chances of failure.

Upstream SELinux have comprehensively rejected this approach.  They do
not want to have the presence of /.autorelabel cause SELinux to
permissive mode.

We might carry my patch downstream (in fedora-selinux.git) but I don't
know who manages that repository or where to post patches for it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

nfs-ganesha -stable request stalled

2016-07-07 Thread Kaleb KEITHLEY 

Hi,

Would someone please give the nfs-ganesha-2.4.0-0.8dev21.fc24 a kick?

I've had two other updates pushed to -stable since, and they've gone
through. Been waiting ~4 days now.

Status page says the update is locked and can't be modified, but I don't
know why.

Thanks,

--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[389-devel] please review: Ticket 48743 - Admin Console enables unsupported Ciphers by default

2016-07-07 Thread Mark Reynolds 
https://fedorahosted.org/389/ticket/48743

https://fedorahosted.org/389/attachment/ticket/48743/0001-Ticket-48743-idm-console-framework-disable-fortezza-.patch

Do not enable fortezza ciphers by default in console

https://fedorahosted.org/389/attachment/ticket/48743/0001-Ticket-48743-If-a-cipher-is-disabled-do-not-attempt-.patch

Do not check if disabled ciphers exist
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

Re: F25 System Wide Change: KillUserProcesses=yes by default

2016-07-07 Thread Jan Kurik 
On Thu, Jul 7, 2016 at 8:46 PM, Garrett Holmstrom
 wrote:
> On 2016-07-07 05:13, Jan Kurik wrote:
>>
>> == Scope ==
>> * Proposal owners:
>> - work upstream to clarify what is the best way for programs to mark
>> themselves to survive logout
>> - update the documentation with more explanations and examples, as we
>> learn what people find confusing in the current scheme of things
>> - evaluate a "permissive" mode for KillUserProcesses, to make it
>> easier to debug processes which stay around after a session terminates
>> - remove the compile-time override in the systemd package
>> - work with upstream authors and Fedora maintainers of programs like
>> screen and tmux to implement the ability to automatically start them
>> in a way that survives a user session, and if the system policy does
>> not allow that, to warn the user.
>>
>> * Other developers:
>> - cooperate on the last item from previous point
>> - identify additional services which need to adapt to the changed default.
>>
>> Different services might merit different handling here: some might be
>> updated them to start through the non-session-specific dbus instance,
>> some might need documentation changes, while others possibly should be
>> handled like tmux and screen.
>>
>> * Release engineering: N/A
>>
>> * List of deliverables: N/A (not a System Wide Change)
>
>
> But this is a system-wide change.  Is the intention to fill out this list as
> people learn what needs to be changed?

That is my fault as I overlooked this. It is fixed now on the wiki.

Regards,
Jan

> --
> Garrett Holmstrom
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Heads up: issue with Intel microcode update and some Skylake based machines

2016-07-07 Thread Adam Williamson 
On Thu, 2016-07-07 at 11:46 -0400, Josh Boyer wrote:
> We've had a rash of reports of kernels not booting on some Skylake based
> machines recently.  After working these, we've determined that a recent
> Intel microcode update somehow conflicts with something in the system
> firmware for these machine, causing a complete failure to boot after grub
> loads the kernel.
> 
> Some of these systems have a firmware update (BIOS/UEFI) that restores
> functionality even with the microcode being loaded.  Other systems do not
> yet at this time.  If you experience a boot hang on a Skylake based
> machine, you can try and determine if the microcode is at fault by
> specifying 'dis_ucode_ldr' on the kernel command line.  That prevents the
> kernel from loading the microcode during the early boot.
> 
> The issue is mostly being tracked here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1353103
> 
> Some of the machines involved are:
> 
> Lenovo Thinkpad T460
> Lenovo Thinkpad x260
> Lenovo Yoga 260
> ASUS Zenbook UX305CA
> Samsung Notebook 9

I've blogged about this (so it'll reach planet) and posted to G+.
There's also a forum thread for 'failure to boot with kernel 4.6' where
we're pretty sure at least some of the reporters are hitting this bug:

https://www.happyassassin.net/2016/07/07/psa-failure-to-boot-after-kernel-update-on-skylake-systems/
https://plus.google.com/u/0/+AdamWilliamsonFOSS/posts/Dp7qD3H5s2V
http://forums.fedoraforum.org/showthread.php?t=310467
-- 

Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: KillUserProcesses=yes by default

2016-07-07 Thread Garrett Holmstrom 

On 2016-07-07 05:13, Jan Kurik wrote:

== Scope ==
* Proposal owners:
- work upstream to clarify what is the best way for programs to mark
themselves to survive logout
- update the documentation with more explanations and examples, as we
learn what people find confusing in the current scheme of things
- evaluate a "permissive" mode for KillUserProcesses, to make it
easier to debug processes which stay around after a session terminates
- remove the compile-time override in the systemd package
- work with upstream authors and Fedora maintainers of programs like
screen and tmux to implement the ability to automatically start them
in a way that survives a user session, and if the system policy does
not allow that, to warn the user.

* Other developers:
- cooperate on the last item from previous point
- identify additional services which need to adapt to the changed default.

Different services might merit different handling here: some might be
updated them to start through the non-session-specific dbus instance,
some might need documentation changes, while others possibly should be
handled like tmux and screen.

* Release engineering: N/A

* List of deliverables: N/A (not a System Wide Change)


But this is a system-wide change.  Is the intention to fill out this 
list as people learn what needs to be changed?


--
Garrett Holmstrom
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Test-Announce] Fedora QA Onboarding Call 2016-07-08 1700-1900 UTC

2016-07-07 Thread Adam Williamson 
Hey All,

This is a gentle reminder that we have a Fedora QA onboarding call on
Fri 2016-07-08 at 1700-1900 UTC.  We will focus on helping the new
contributors to start contributing right away. The meeting will be on
Hangouts, with a 'piratepad'[1] for text notes and chat. The agenda is
already on the piratepad and is designed to ensure that newcomers can
follow along and make the most of the call without any pre-requisites.

To join the call, just open the piratepad. The Hangouts URL will be
posted there 10 minutes before the meeting starts. Piratepad is a
collaborative text editor with a chat system. You can enter your
nickname at top-right and choose a color. Then you can chat by typing
in the 'Chat:' box at bottom-right, and make edits to the text on the
left hand side - please be polite about editing other people's text and
not typing too much!

Let's make the most of tomorrow's session and make Fedora better!

[1] http://piratepad.nl/yCH1St3wOr

[sorry if this is a dupe for anyone: Sumantro sent this mail once
already and it appeared in the archives, but it seemed not to reach a
lot of people's inboxes, so I'm re-sending it to see if that helps.]
-- 

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
https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Heads up: issue with Intel microcode update and some Skylake based machines

2016-07-07 Thread Josh Boyer 
We've had a rash of reports of kernels not booting on some Skylake based
machines recently.  After working these, we've determined that a recent
Intel microcode update somehow conflicts with something in the system
firmware for these machine, causing a complete failure to boot after grub
loads the kernel.

Some of these systems have a firmware update (BIOS/UEFI) that restores
functionality even with the microcode being loaded.  Other systems do not
yet at this time.  If you experience a boot hang on a Skylake based
machine, you can try and determine if the microcode is at fault by
specifying 'dis_ucode_ldr' on the kernel command line.  That prevents the
kernel from loading the microcode during the early boot.

The issue is mostly being tracked here:
https://bugzilla.redhat.com/show_bug.cgi?id=1353103

Some of the machines involved are:

Lenovo Thinkpad T460
Lenovo Thinkpad x260
Lenovo Yoga 260
ASUS Zenbook UX305CA
Samsung Notebook 9

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

2016-07-07 Thread Mike FABIAN 
Bastien Nocera  さんはかきました:

> Re-send to the change owner
>
> - Original Message -
>> = Proposed Self Contained Change: IBus Emoji Typing  =
>> https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing
>> 
>> Change owner(s):
>> * Takao Fujiwara 
>> 
>> The IBus core will provide the Emoji Unicode typing with the IBus XKB
>> engines.
>> 
>> == Detailed Description ==
>> IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now
>> we
>> think the similar implementation for the Emoji typging. With IBus XKB
>> engines,
>> Emoji typing will be provided with the Emoji annotations [1] following Ctrl-
>> Shift-e.
>> 
>> == Scope ==
>> * Proposal owners:
>>  - IBus core provide the dictionary of the Emoji typing.
>>  - IBus XKB engines load the Emoji dictionary.
>> 
>> * Other developers: N/A
>> 
>> * Release engineering: N/A
>>  - List of deliverables: N/A
>> 
>> * Policies and guidelines: N/A
>> 
>> * Trademark approval: N/A
>> 
>> [1] http://unicode.org/emoji/charts/index.html#col-annotations
>
> Will this use:
> https://github.com/lalomartins/ibus-uniemoji/
> ?

I don’t think so, it is supposed to work in all xkb engines of
ibus-typing booster, this is not a seperate engine like ibus-uniemoji.

> It would be great if this feature used the emoji fonts directly, so we
> can use colour icons:
> http://www.hadess.net/2016/05/blog-backlog-post-1-emoji.html

The font shown in this blog seems to be one the fonts contained in the
nodejs-emojione package which Fujiwara San is packaging for this change
request.

There seem to be some problems with the font though:

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

But freetype nicely displays it in colour:

https://bugzilla.redhat.com/show_bug.cgi?id=1350700#c3
https://bugzilla.redhat.com/attachment.cgi?id=1176850

> Cheers
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

-- 
Mike FABIAN 
☏ Office: +49-69-365051027, internal 8875027
睡眠不足はいい仕事の敵だ。
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Modularity] BPO - the great UI that shows you everything

2016-07-07 Thread Ralph Bean 
On Fri, Jul 01, 2016 at 06:14:00PM +0200, Adam Samalik wrote:
> Thanks for the response. I agree, asking you "I am building something I
> haven't described, how do you want to use it?" might have not been the best
> idea... So please, let me try that again and better. :-)

Thanks Adam :)

> I have created a wiki page [1] that briefly describes the BPO component,
> what data would be available, and the main three possible functions.
> 
> 
> 
> >
> > * Should there be a 'developer' or 'end user' type here? Ie, is it
> >   expected that they would want to look at this to see what the latest
> >   version of some module they care about is, or if there's new ones
> >   that might be coming along soon? Or is that another tool?
> >
> It would be probably both. But I would focus mainly on developers in the
> early stage. Later, there might be something similar to what you described
> for the end user.
> 
> 
> >
> > * Depending again on the kinds of things this can report on,
> >   infrastructure might be interested in it. Could we query it via
> >   nagios to let us know about problems in module building or testing ?
> >
> If you would use something like this, I would be happy to include it in the
> BPO.
> 
> 
> >
> > * Modules can depend on other modules right? If so, a way to see that
> >   tree of dependencies in building would be nice (ie, moduleA depends
> >   on moduleB, and moduleB is currently rebuilding for foo, moduleA
> >   should show that it's pending rebuilding after that, etc)
> >
> Yes. This should also be there.
> 
> 
> 
> [1] https://fedoraproject.org/wiki/Modularity/BPO

Here are some thoughts on the context.

Currently, when a packager packages a new upstream release, then build
it for rawhide and then they think "what stable releases to I want to
also build and ship this for?"  Maybe all of them?  Maybe just F24?
The point is that the packager thinks about it, knows what they're
doing, and then does it.

Then, about 24 hours later, releng scoops up whatever has been done.

- For rawhide, pungi builds the repos and ships it out.
- For stable releases, bodhi mashes repos, and ships them out.

The most grizzled veterans will rightly balk when I say, "it's easy to
know what state an update is in."  But.. it's more or less linear.
Was it patched but not built?  Was it built but not added to an
update?  Was it in an update but not yet pushed?  Is it pushed but not
yet on the secondary mirrors?  Etc..

In the Modularity Working Group (for various reasons) we're talking
about building automation services on top of koji that will
automatically rebuild modules based on new available components (these
are rpms) (and only sometimes, based on policy).

Furthermore, we're hoping to break some of the releng tasks (like the
24 hour nightly compose/push) out into ad hoc tasks that happen
alongside, shortly after builds of intermediary components are done
(triggered by message bus events).

So, that's hard to do.  We're working on trying to get it right.  One
side effect of deploying it is that it's going to be super confusing
for packagers to look at this whole thing and figure out what state a
patch is in.  Say I patched a CVE in component X.  Has it been rebuilt
into modules L, M, and N?  Did it fail in module O's buildroot?  If
those have been built, which have been shipped?  That's all from the
developer standpoint who starts from a patch.  Release engineering
would want a similar kind of question to be answerable:  if we have a
patch that fixes CVE blah-blah-blah, has that been built into all the
artifacts we ship now?  Can we say that we've fixed it across the
board so we can write a press release?

We'll have data scattered all over the place that, when put together,
can answer questions like this:  some in koji, some in PDC, some in
bodhi, some in mirrormanager.  The idea here is to make this 'BPO'
service (the Build Pipeline Overview service) something that can make
those questions easily answerable in one place.

In architecture terms, it is like a 'data mart' (convenient access to
data that comes from the 'data warehouse', which is bigger and harder
to interface with).


signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

gscan2pdf license corrected

2016-07-07 Thread Petr Pisar 
I corrected gscan2pdf license declaration in 1.3.9-3.fc25 build
from (GPLv3) to (GPLv3 and GPLv2 and LGPLv2+).

-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

2016-07-07 Thread Bastien Nocera 
Re-send to the change owner

- Original Message -
> = Proposed Self Contained Change: IBus Emoji Typing  =
> https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing
> 
> Change owner(s):
> * Takao Fujiwara 
> 
> The IBus core will provide the Emoji Unicode typing with the IBus XKB
> engines.
> 
> == Detailed Description ==
> IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now
> we
> think the similar implementation for the Emoji typging. With IBus XKB
> engines,
> Emoji typing will be provided with the Emoji annotations [1] following Ctrl-
> Shift-e.
> 
> == Scope ==
> * Proposal owners:
>  - IBus core provide the dictionary of the Emoji typing.
>  - IBus XKB engines load the Emoji dictionary.
> 
> * Other developers: N/A
> 
> * Release engineering: N/A
>  - List of deliverables: N/A
> 
> * Policies and guidelines: N/A
> 
> * Trademark approval: N/A
> 
> [1] http://unicode.org/emoji/charts/index.html#col-annotations

Will this use:
https://github.com/lalomartins/ibus-uniemoji/
?

It would be great if this feature used the emoji fonts directly, so we
can use colour icons:
http://www.hadess.net/2016/05/blog-backlog-post-1-emoji.html

Cheers
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: Better Switchable Graphics Support

2016-07-07 Thread Bastien Nocera 


- Original Message -
> = Proposed Self Contained Change: Better Switchable Graphics Support =
> https://fedoraproject.org/wiki/Changes/BetterSwitchableGraphicsSupport
> 
> Change owner(s):
> * Hans de Goede 
> 
> All modern laptops have a gpu integrated into their processor (the
> igpu), some models also have a more powerful dedicated gpu (dgpu),
> this is called switchable graphics. The goal of this feature is to
> improve Fedora's support for such laptops.
> 
> 
> == Detailed Description ==
> By default all apps will run on the more energy efficient igpu and the
> OS can choose to switch to the dgpu when more gpu-power is necessary,
> trading battery time for graphics performance. On most laptops the
> default gpu can be changed to the dgpu so that everything will always
> run on the dgpu.
> 
> Linux support for switchable graphics currently is not very good. E.g.
> on many laptops some of the external connectors are only connected to
> the dgpu and to be able to use those external connectors without
> issues users need to change the default gpu to the dgpu, resulting in
> a hot running laptop and the battery draining much faster.
> 
> The goal of this feature is to improve switchable graphics support
> under Linux, allowing the igpu to be used as default, allowing maximum
> batter life, while keeping everthing working normally. Specifically
> the following should all work: external outputs, suspend / resume
> (including suspend/resume with external monitors connected / while
> docked) and suspending the dgpu when not used.

Yep, all this should be automatic.

> A secondary goal is to allow people to run graphically demanding
> programs on the dgpu by starting them with "DRI_PRIME=1 program", note
> that since we do not support dynamic reclocking of nvidia GPUs this
> will not always result in a performance improvement.

I have some WIP code for gnome-shell to allow that, and it would detect
whether prime is available through a D-Bus service (which also runs a
few hacks for some devices):
https://github.com/hadess/switcheroo-control

> == Scope ==
> * Proposal owners: Fix switchable-graphics related kernel and xorg
> bugs, ensure gnome-control-panel "Displays" setting works properly on
> switchable-graphics setups
> 
> * Other developers: GNOME control-panel developers (if changes are
> necessary there)

Shouldn't be necessary, though it would be nice if the display adapters
available trickled down from the switcheroo D-Bus service all the way
to gnome-session and then the Details panel in GNOME.

See also:
https://wiki.gnome.org/Design/OS/DualGPU

Cheers
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-07-07 Thread Daniel P. Berrange 
On Thu, Jul 07, 2016 at 09:48:24AM -0400, Jeff Moyer wrote:
> "Daniel P. Berrange"  writes:
> 
> > More typical though is that you have a directory containing an fullish
> > install tree of a non-native architecture and you just want to chroot
> > into that. When doing such a chroot, the qemu-$ARCH emulator must be
> > present inside the chroot too. ie the x86_64 build of /usr/bin/qemu-arm
> > must be present inside at /my/chroot/for/fedora-arm/usr/bin/qemu-arm.
> 
> Hi, Dan,
> 
> Is this work from James Bottomley at all relevant?
> 
> http://comments.gmane.org/gmane.linux.file-systems/105033
> http://blog.hansenpartnership.com/constructing-architecture-emulation-containers/

He's describing exactly the kind of approach that is common on other
distros and that I want to work on Fedora too. His instructions are
assuming use of a statically linked qem-$ARCH emulator too.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[389-devel] Please review 48906: Allow nsslapd-db-locks to be configurable online

2016-07-07 Thread thierry bordaz 

https://fedorahosted.org/389/attachment/ticket/48906/0002-Ticket-48906-Allow-nsslapd-db-locks-to-be-configurab.patch

https://fedorahosted.org/389/ticket/48906
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-07-07 Thread Jeff Moyer 
"Daniel P. Berrange"  writes:

> More typical though is that you have a directory containing an fullish
> install tree of a non-native architecture and you just want to chroot
> into that. When doing such a chroot, the qemu-$ARCH emulator must be
> present inside the chroot too. ie the x86_64 build of /usr/bin/qemu-arm
> must be present inside at /my/chroot/for/fedora-arm/usr/bin/qemu-arm.

Hi, Dan,

Is this work from James Bottomley at all relevant?

http://comments.gmane.org/gmane.linux.file-systems/105033
http://blog.hansenpartnership.com/constructing-architecture-emulation-containers/

Cheers,
Jeff
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[389-devel] Re: Logging performance improvement

2016-07-07 Thread Mark Reynolds 
William,

Yes this looks great, but I think we should apply this to the audit and
errors log as well.  We always have the problem of enabling verbose
error logging because of the severe performance impact it has
(especially since the errors log is not buffered).  Having all the logs
using this model would be very useful for DS users and the support team.

Thanks,

Mark


On 07/07/2016 06:03 AM, thierry bordaz wrote:
> Hi William,
>
> This is looking a great idea. You are proposing to use liblfds to
> communicate with the log write. Do you think dbus would be an other
> option ? Would it help external mechanism to collect the DS logs ?
>
> thanks
> thierry
>
> On 07/01/2016 03:52 AM, William Brown wrote:
>> Hi,
>>
>> I've been thinking about this for a while, so I decided to dump my
>> thoughts to a document. I think I won't get to implementing this for a
>> while, but it would really help our server performance.
>>
>> http://www.port389.org/docs/389ds/design/logging-performance-improvement.html
>>
>>
>>
>> --
>> 389-devel mailing list
>> 389-devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
>
>
>
> --
> 389-devel mailing list
> 389-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[Bug 1353238] Please update XSLoader to 0.22

2016-07-07 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1353238



--- Comment #3 from Paul Howarth  ---
(In reply to Petr Pisar from comment #1)
> This XSLoader issue will obtain a CVE identifier probably
> .

I suspected as much.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1353238] Please update XSLoader to 0.22

2016-07-07 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1353238



--- Comment #2 from Fedora Update System  ---
perl-5.22.2-361.fc24 has been submitted as an update to Fedora 24.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-485dff6060

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1353238] Please update XSLoader to 0.22

2016-07-07 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1353238



--- Comment #1 from Petr Pisar  ---
This XSLoader issue will obtain a CVE identifier probably
.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-Const-Fast (el6) to 'Approved'

2016-07-07 Thread notifications 
ppisar changed perl-sig's 'watchcommits' permission on perl-Const-Fast (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1353238] Please update XSLoader to 0.22

2016-07-07 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1353238

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-5.24.0-371.fc25



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

F25 System Wide Change: KillUserProcesses=yes by default

2016-07-07 Thread Jan Kurik 
= Proposed System Wide Change: KillUserProcesses=yes by default =
https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_default

Change owner(s):
* Zbigniew Jędrzejewski-Szmek 

Set the default policy to terminate processes in session scope when
the user logs out. Specifically, systemd-logind's KillUserProcesses
setting, which currently is set to "no" to override the upstream
default, will be removed to follow the upstream default of "yes".


== Detailed Description ==
Since the introduction of systemd-logind a few years back, when a
session is created, systemd hooks into the PAM session creation step
to move the process that starts the session into a separate cgroup.
This means that processes which are started as part of the session can
be reliably tracked, even if they detach from the terminal and
daemonize. When a user session terminates, various processes started
as part of the user session (initally) remain alive. When the session
is terminated, remaining processes receive a HUP signal (*), which can
be and often is ignored.

Under the proposed setting of KillUserProcesses=yes, systemd will
forcibly terminate (using SIGTERM and then SIGKILL) all processes
which are part of the session scope (the cgroup created for the login
session) when the user logs out. In order for a process to avoid being
killed it has to be part of a different systemd unit. For user
processes this can be achieved in two primary ways: by starting the
unit as a service (e.g. 'systemd-run --user /usr/bin/foo', or creating
a dedicated user service unit), or by telling systemd to create a new
scope unit to encompass a specific process (e.g. 'systemd-run --user
--scope /usr/bin/foo', or making a dbus call to create a scope unit
directly). This step can be integrated directly into programs when
this makes sense for their primary use case, e.g. screen.

(*) Whether SIGHUP is sent depends on a few factors: bash sends it
children, tcsh does not, and the kernel also sends SIGHUP to processes
which have a terminal open.


== Scope ==
* Proposal owners:
- work upstream to clarify what is the best way for programs to mark
themselves to survive logout
- update the documentation with more explanations and examples, as we
learn what people find confusing in the current scheme of things
- evaluate a "permissive" mode for KillUserProcesses, to make it
easier to debug processes which stay around after a session terminates
- remove the compile-time override in the systemd package
- work with upstream authors and Fedora maintainers of programs like
screen and tmux to implement the ability to automatically start them
in a way that survives a user session, and if the system policy does
not allow that, to warn the user.

* Other developers:
- cooperate on the last item from previous point
- identify additional services which need to adapt to the changed default.

Different services might merit different handling here: some might be
updated them to start through the non-session-specific dbus instance,
some might need documentation changes, while others possibly should be
handled like tmux and screen.

* Release engineering: N/A

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines:
- a Fedora Magazine article or similar to publicize the change would be nice

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 Self Contained Change: Better Switchable Graphics Support

2016-07-07 Thread Jan Kurik 
= Proposed Self Contained Change: Better Switchable Graphics Support =
https://fedoraproject.org/wiki/Changes/BetterSwitchableGraphicsSupport

Change owner(s):
* Hans de Goede 

All modern laptops have a gpu integrated into their processor (the
igpu), some models also have a more powerful dedicated gpu (dgpu),
this is called switchable graphics. The goal of this feature is to
improve Fedora's support for such laptops.


== Detailed Description ==
By default all apps will run on the more energy efficient igpu and the
OS can choose to switch to the dgpu when more gpu-power is necessary,
trading battery time for graphics performance. On most laptops the
default gpu can be changed to the dgpu so that everything will always
run on the dgpu.

Linux support for switchable graphics currently is not very good. E.g.
on many laptops some of the external connectors are only connected to
the dgpu and to be able to use those external connectors without
issues users need to change the default gpu to the dgpu, resulting in
a hot running laptop and the battery draining much faster.

The goal of this feature is to improve switchable graphics support
under Linux, allowing the igpu to be used as default, allowing maximum
batter life, while keeping everthing working normally. Specifically
the following should all work: external outputs, suspend / resume
(including suspend/resume with external monitors connected / while
docked) and suspending the dgpu when not used.

A secondary goal is to allow people to run graphically demanding
programs on the dgpu by starting them with "DRI_PRIME=1 program", note
that since we do not support dynamic reclocking of nvidia GPUs this
will not always result in a performance improvement.



== Scope ==
* Proposal owners: Fix switchable-graphics related kernel and xorg
bugs, ensure gnome-control-panel "Displays" setting works properly on
switchable-graphics setups

* Other developers: GNOME control-panel developers (if changes are
necessary there)

* Release engineering: N/A (not a System Wide Change)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 Self Contained Change: Transdiff

2016-07-07 Thread Jan Kurik 
= Proposed Self Contained Change: Transdiff =
https://fedoraproject.org/wiki/Changes/Transdiff

Change owner(s):
*Sundeep Anand 

Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience. Transdiff is a python program to run on
products installations for tracking translations with project upstream
and generate diff reports.

== Detailed Description ==
Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience. Transdiff is a python program to run on
products installations for tracking translations with project upstream
and generate diff reports.

== Scope ==
* Proposal owners: Complete script and package it for Fedora.

* Other developers: N/A (not a System Wide Change)

* Release engineering: N/A (not a System Wide Change)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 Self Contained Change: Ibus-typing-booster multilingual support

2016-07-07 Thread Jan Kurik 
= Proposed Self Contained Change: Ibus-typing-booster multilingual support =
https://fedoraproject.org/wiki/Changes/Ibus-typing-booster_multilingual_support

Change owner(s):
* Mike Fabian 
* Pravin Satpute 

Use more then one language in a single engine of ibus-typing-booster.

== Detailed Description ==
Ibus-typing-booster has recently been improved to use several
languages at once in a single engine, see the documentation for
multilingual input . But although that already works, it is not
obvious how to set it up, the graphical setup tool currently only
supports the special case of using British English in addition to the
main language of the current engine. For other combinations of
languages and/or transliteration methods one has to use dconf on the
command line to set it up. That is quite inconvenient. Therefore, this
proposal suggests to change the setup tool to make multilingual setup
easy.

== Scope ==
* Proposal owners:
Improve the ibus-typing-booster setup tool to make multilingual setup easy.

* Other developers: N/A

* Release engineering: N/A

* List of deliverables: N/A

* Policies and guidelines: N/A

* Trademark approval: N/A
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

Fedora rawhide compose report: 20160707.n.0 changes

2016-07-07 Thread Fedora Rawhide Report 
OLD: Fedora-Rawhide-20160706.n.0
NEW: Fedora-Rawhide-20160707.n.0

= SUMMARY =
Added images:0
Dropped images:  8
Added packages:  8
Dropped packages:11
Upgraded packages:   144
Downgraded packages: 0

Size of added packages:  140.06 MiB
Size of dropped packages:18.74 MiB
Size of upgraded packages:   520.15 MiB
Size of downgraded packages: 0.00 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20160706.n.0.iso
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20160706.n.0.iso
Image: Xfce live i386
Path: Spins/i386/iso/Fedora-Xfce-Live-i386-Rawhide-20160706.n.0.iso
Image: Cinnamon live i386
Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-Rawhide-20160706.n.0.iso
Image: Scientific_KDE live i386
Path: Labs/i386/iso/Fedora-Scientific_KDE-Live-i386-Rawhide-20160706.n.0.iso
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20160706.n.0.iso
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20160706.n.0.iso
Image: SoaS live i386
Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20160706.n.0.iso

= ADDED PACKAGES =
Package: giac-1.2.2-5.63.fc25
Summary: Computer Algebra System, Symbolic calculus, Geometry
RPMs:giac giac-devel giac-doc giac-xcas pgiac
Size:31894950 bytes

Package: jmake-1.3.8.8-1.20150716git7761ee3.fc25
Summary: Make utility for large Java projects
RPMs:jmake jmake-javadoc
Size:192920 bytes

Package: libunity-7.1.4-3.20151002.fc25
Summary: Library for integrating with Unity and Plasma
RPMs:libunity libunity-devel python3-libunity
Size:1343178 bytes

Package: licensecheck-3.0.1-1.fc25
Summary: Simple license checker for source files
RPMs:licensecheck
Size:36182 bytes

Package: mame-0.175-1.fc25
Summary: Multiple Arcade Machine Emulator
RPMs:mame mame-data mame-data-software-lists mame-tools
Size:113335960 bytes

Package: nodejs-path-to-regexp-1.2.1-3.fc25
Summary: Express style path to RegExp utility
RPMs:nodejs-path-to-regexp
Size:15014 bytes

Package: perl-Pod-Constants-0.19-1.fc25
Summary: Include constants from POD
RPMs:perl-Pod-Constants
Size:22034 bytes

Package: python-i3ipc-1.2.0-1.fc25
Summary: An improved Python library to control i3wm
RPMs:python2-i3ipc
Size:21090 bytes


= DROPPED PACKAGES =
Package: YafaRay-0.1.1-14.fc25
Summary: A free open-source raytracing render engine
RPMs:YafaRay YafaRay-blender
Size:2021196 bytes

Package: bashdb-4.3_0.9-3.fc24
Summary: BASH debugger, the BASH symbolic debugger
RPMs:bashdb
Size:233122 bytes

Package: gqradio-1.9.2-15.fc23
Summary: Skinned radio tuner
RPMs:gqradio
Size:1014492 bytes

Package: gtkwhiteboard-1.3-11.fc24
Summary: GTK Wiimote Whiteboard
RPMs:gtkwhiteboard
Size:133050 bytes

Package: kradio4-4.0.6-15.fc24
Summary: V4L/V4L2-Radio Application for KDE4
RPMs:kradio4
Size:10851654 bytes

Package: libXaw3dXft-1.6.2d-3.fc24
Summary: An extended version of Xaw3d with support for UTF8
RPMs:libXaw3dXft libXaw3dXft-devel
Size:637520 bytes

Package: partimage-0.6.9-12.fc24
Summary: Partition imaging utility, much like Ghost
RPMs:partimage partimage-server
Size:888580 bytes

Package: php-idn-1.2c-14.fc24
Summary: PHP API for GNU LibIDN
RPMs:php-idn
Size:85550 bytes

Package: pydb-1.26-14.fc24
Summary: Extended Python Debugger
RPMs:emacs-pydb pydb
Size:236976 bytes

Package: rurple-1.0-0.13.rc3.fc24
Summary: A Python Learning Environment
RPMs:rurple
Size:986074 bytes

Package: xpaint-2.9.10.3-4.fc24
Summary: An X Window System image editing or paint program
RPMs:xpaint
Size:2558742 bytes


= UPGRADED PACKAGES =
Package:  NetworkManager-openconnect-1.2.3-0.20160606git5009f9.fc25
Old package:  NetworkManager-openconnect-1.2.2-1.fc25
Summary:  NetworkManager VPN plugin for openconnect
RPMs: NetworkManager-openconnect NetworkManager-openconnect-gnome
Added RPMs:   NetworkManager-openconnect-gnome
Size: 1326092 bytes
Size change:  89358 bytes
Changelog:
  * Wed Jul 06 2016 David Woodhouse <dw...@infradead.org> - 
1.2.3-0.20160606git5009f9
  - Update to 1.2.3 prerelease
  - Split GNOME support into separate package (#1088672)
  - Add Juniper support (#1340495)


Package:  abi-dumper-0.99.16-1.fc25
Old package:  abi-dumper-0.99.15-2.fc25
Summary:  Tool to dump ABI of an ELF object containing DWARF debug info
RPMs: abi-dumper
Size: 39294 bytes
Size change:  -7416 bytes
Changelog:
  * Wed Jul 06 2016 Richard Shaw <hobbes1...@gmail.com> - 0.99.16-1
  - Update to latest upstream release.


Package:  abi-tracker-1.8-1.fc25
Old package:  abi-tracker-1.7-1.fc25
Summary:  Tool to visualize ABI changes timel

F25 System Wide Change: Fedora Media Writer as Primary Downloadable

2016-07-07 Thread Jan Kurik 
= Proposed System Wide Change: Fedora Media Writer as Primary Downloadable =
https://fedoraproject.org/wiki/Changes/FedoraMediaWriterAsPrimaryDownloadable

Change owner(s):
* Martin Briza 
* Jiri Eischmann 


The new Fedora Media Writer that is being finished has an overhauled,
more user friendly interface. Because USB sticks are the most common
way to install Fedora, it should be the primary download option. It
cover the whole installation media creation, it lets the user pick the
right flavor of Fedora, downloads its image, and copies it to a USB
drive.
This Change inherits the LiveUSBCreator change. Fedora Media Writer is
a rewrite of the current liveusb-creator package in C++, using most of
the functional parts of the old project and its complete user
interface.


== Detailed Description ==
Fedora Media Writer is a new tool that be much easier to use than the
existing tools (see mockups). It should cover the complete work flow
of creating an installation media. It provides information
(descriptions, screenshots,...) about flavors and variants of Fedora
to help the user to pick the right one for their usage, downloads the
ISO, and copies it to a USB flash disk. The goal of this change is to
provide this tool as the primary download option on getfedora.org and
create a mechanism to store and update information (descriptions,
screenshots,...) for the tool. This requires work not only from the
change owners, but also from other groups (websites, design,
marketing, releng teams).


== Scope ==
* Proposal owners:
- Fedora Media Writer for Linux (Copr and Flatpak coming soon, should
we create a deb package, too?)
- Fedora Media Writer for Windows
- Fedora Media Writer for Mac OS X

* Other developers:
the websites team has to update the download page to make FMW the
primary download option.

* Marketing and design:
the design team has to work with websites team on necessary changes to
the download page.
the marketing has to provide information for FMW including
descriptions and screenshots (screenshots of Workstation are currently
missing)

* QA:
adjust tests and test result matrices

* Release engineering:
- Plan the process of building Windows and MacOS packages
- Handle the distribution of the releases
- (Probably) establish a way how to pass Fedora release data to the
tool - related to the release information from Marketing

* Policies and guidelines:
The Media Writer tool is helping with new installations. Existing
installations are not affected.

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 Self Contained Change: Better Switchable Graphics Support

2016-07-07 Thread Jan Kurik 
= Proposed Self Contained Change: Better Switchable Graphics Support =
https://fedoraproject.org/wiki/Changes/BetterSwitchableGraphicsSupport

Change owner(s):
* Hans de Goede 

All modern laptops have a gpu integrated into their processor (the
igpu), some models also have a more powerful dedicated gpu (dgpu),
this is called switchable graphics. The goal of this feature is to
improve Fedora's support for such laptops.


== Detailed Description ==
By default all apps will run on the more energy efficient igpu and the
OS can choose to switch to the dgpu when more gpu-power is necessary,
trading battery time for graphics performance. On most laptops the
default gpu can be changed to the dgpu so that everything will always
run on the dgpu.

Linux support for switchable graphics currently is not very good. E.g.
on many laptops some of the external connectors are only connected to
the dgpu and to be able to use those external connectors without
issues users need to change the default gpu to the dgpu, resulting in
a hot running laptop and the battery draining much faster.

The goal of this feature is to improve switchable graphics support
under Linux, allowing the igpu to be used as default, allowing maximum
batter life, while keeping everthing working normally. Specifically
the following should all work: external outputs, suspend / resume
(including suspend/resume with external monitors connected / while
docked) and suspending the dgpu when not used.

A secondary goal is to allow people to run graphically demanding
programs on the dgpu by starting them with "DRI_PRIME=1 program", note
that since we do not support dynamic reclocking of nvidia GPUs this
will not always result in a performance improvement.



== Scope ==
* Proposal owners: Fix switchable-graphics related kernel and xorg
bugs, ensure gnome-control-panel "Displays" setting works properly on
switchable-graphics setups

* Other developers: GNOME control-panel developers (if changes are
necessary there)

* Release engineering: N/A (not a System Wide Change)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 Self Contained Change: Transdiff

2016-07-07 Thread Jan Kurik 
= Proposed Self Contained Change: Transdiff =
https://fedoraproject.org/wiki/Changes/Transdiff

Change owner(s):
*Sundeep Anand 

Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience. Transdiff is a python program to run on
products installations for tracking translations with project upstream
and generate diff reports.

== Detailed Description ==
Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience. Transdiff is a python program to run on
products installations for tracking translations with project upstream
and generate diff reports.

== Scope ==
* Proposal owners: Complete script and package it for Fedora.

* Other developers: N/A (not a System Wide Change)

* Release engineering: N/A (not a System Wide Change)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 Self Contained Change: Ibus-typing-booster multilingual support

2016-07-07 Thread Jan Kurik 
= Proposed Self Contained Change: Ibus-typing-booster multilingual support =
https://fedoraproject.org/wiki/Changes/Ibus-typing-booster_multilingual_support

Change owner(s):
* Mike Fabian 
* Pravin Satpute 

Use more then one language in a single engine of ibus-typing-booster.

== Detailed Description ==
Ibus-typing-booster has recently been improved to use several
languages at once in a single engine, see the documentation for
multilingual input . But although that already works, it is not
obvious how to set it up, the graphical setup tool currently only
supports the special case of using British English in addition to the
main language of the current engine. For other combinations of
languages and/or transliteration methods one has to use dconf on the
command line to set it up. That is quite inconvenient. Therefore, this
proposal suggests to change the setup tool to make multilingual setup
easy.

== Scope ==
* Proposal owners:
Improve the ibus-typing-booster setup tool to make multilingual setup easy.

* Other developers: N/A

* Release engineering: N/A

* List of deliverables: N/A

* Policies and guidelines: N/A

* Trademark approval: N/A
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

jplesnik pushed to perl (master). "Do not let XSLoader load relative paths (bz #1353238)"

2016-07-07 Thread notifications 
From 690183398177fb96326841c2bf11b7bfcf85 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 7 Jul 2016 13:30:02 +0200
Subject: Do not let XSLoader load relative paths (bz #1353238)

---
 2-Don-t-let-XSLoader-load-relative-paths.patch | 237 +
 perl.spec  |  11 +-
 2 files changed, 247 insertions(+), 1 deletion(-)
 create mode 100644 perl-5.25.2-Don-t-let-XSLoader-load-relative-paths.patch

diff --git a/perl-5.25.2-Don-t-let-XSLoader-load-relative-paths.patch 
b/perl-5.25.2-Don-t-let-XSLoader-load-relative-paths.patch
new file mode 100644
index 000..b5559d8
--- /dev/null
+++ b/perl-5.25.2-Don-t-let-XSLoader-load-relative-paths.patch
@@ -0,0 +1,237 @@
+From 08e3451d7b3b714ad63a27f1b9c2a23ee75d15ee Mon Sep 17 00:00:00 2001
+From: Father Chrysostomos 
+Date: Sat, 2 Jul 2016 22:56:51 -0700
+Subject: [PATCH 1/4] =?UTF-8?q?Don=E2=80=99t=20let=20XSLoader=20load=20rel?=
+ =?UTF-8?q?ative=20paths?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[rt.cpan.org #115808]
+
+The logic in XSLoader for determining the library goes like this:
+
+my $c = () = split(/::/,$caller,-1);
+$modlibname =~ s,[\\/][^\\/]+$,, while $c--;# Q basename
+my $file = "$modlibname/auto/$modpname/$modfname.bundle";
+
+(That last line varies by platform.)
+
+$caller is the calling package.  $modlibname is the calling file.  It
+removes as many path segments from $modlibname as there are segments
+in $caller.  So if you have Foo/Bar/XS.pm calling XSLoader from the
+Foo::Bar package, the $modlibname will end up containing the path in
+@INC where XS.pm was found, followed by "/Foo".  Usually the fallback
+to Dynaloader::bootstrap_inherit, which does an @INC search, makes
+things Just Work.
+
+But if our hypothetical Foo/Bar/XS.pm actually calls
+XSLoader::load from inside a string eval, then path ends up being
+"(eval 1)/auto/Foo/Bar/Bar.bundle".
+
+So if someone creates a directory named ‘(eval 1)’ with a naughty
+binary file in it, it will be loaded if a script using Foo::Bar is run
+in the parent directory.
+
+This commit makes XSLoader fall back to Dynaloader’s @INC search if
+the calling file has a relative path that is not found in @INC.
+---
+ dist/XSLoader/XSLoader_pm.PL | 25 +
+ dist/XSLoader/t/XSLoader.t   | 27 ++-
+ 2 files changed, 51 insertions(+), 1 deletion(-)
+
+diff --git a/dist/XSLoader/XSLoader_pm.PL b/dist/XSLoader/XSLoader_pm.PL
+index 8a8852e..749f72d 100644
+--- a/dist/XSLoader/XSLoader_pm.PL
 b/dist/XSLoader/XSLoader_pm.PL
+@@ -91,6 +91,31 @@ print OUT <<'EOT';
+ my $modpname = join('/',@modparts);
+ my $c = () = split(/::/,$caller,-1);
+ $modlibname =~ s,[\\/][^\\/]+$,, while $c--;# Q basename
++# Does this look like a relative path?
++if ($modlibname !~ m|^[\\/]|) {
++# Someone may have a #line directive that changes the file name, or
++# may be calling XSLoader::load from inside a string eval.  We cer-
++# tainly do not want to go loading some code that is not in @INC,
++# as it could be untrusted.
++#
++# We could just fall back to DynaLoader here, but then the rest of
++# this function would go untested in the perl core, since all @INC
++# paths are relative during testing.  That would be a time bomb
++# waiting to happen, since bugs could be introduced into the code.
++#
++# So look through @INC to see if $modlibname is in it.  A rela-
++# tive $modlibname is not a common occurrence, so this block is
++# not hot code.
++FOUND: {
++for (@INC) {
++if ($_ eq $modlibname) {
++last FOUND;
++}
++}
++# Not found.  Fall back to DynaLoader.
++goto \::bootstrap_inherit;
++}
++}
+ EOT
+ 
+ my $dl_dlext = quotemeta($Config::Config{'dlext'});
+diff --git a/dist/XSLoader/t/XSLoader.t b/dist/XSLoader/t/XSLoader.t
+index 2ff11fe..1e86faa 100644
+--- a/dist/XSLoader/t/XSLoader.t
 b/dist/XSLoader/t/XSLoader.t
+@@ -33,7 +33,7 @@ my %modules = (
+ 'Time::HiRes'=> q| ::can_ok( 'Time::HiRes' => 'usleep'  ) |,  # 5.7.3
+ );
+ 
+-plan tests => keys(%modules) * 3 + 9;
++plan tests => keys(%modules) * 3 + 10;
+ 
+ # Try to load the module
+ use_ok( 'XSLoader' );
+@@ -125,3 +125,28 @@ XSLoader::load("Devel::Peek");
+ EOS
+ or ::diag $@;
+ }
++
++SKIP: {
++  skip "File::Path not available", 1
++unless eval { require File::Path };
++  my $name = "phooo$$";
++  File::Path::make_path("$name/auto/Foo/Bar");
++  open my $fh,
++">$name/auto/Foo/Bar/Bar.$Config::Config{'dlext'}";
++  close $fh;
++  my $fell_back;
++  local *XSLoader::bootstrap_inherit = sub {
++$fell_back++;
++# Break out of the calling subs
++goto the_test;
++  };
++  eval

[389-devel] Re: Logging performance improvement

2016-07-07 Thread thierry bordaz 

Hi William,

This is looking a great idea. You are proposing to use liblfds to 
communicate with the log write. Do you think dbus would be an other 
option ? Would it help external mechanism to collect the DS logs ?


thanks
thierry

On 07/01/2016 03:52 AM, William Brown wrote:

Hi,

I've been thinking about this for a while, so I decided to dump my
thoughts to a document. I think I won't get to implementing this for a
while, but it would really help our server performance.

http://www.port389.org/docs/389ds/design/logging-performance-improvement.html



--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org


--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[Bug 1353374] perl-DBD-MySQL-4.034 is available

2016-07-07 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1353374

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-DBD-MySQL-4.034-1.fc25
 Resolution|--- |RAWHIDE
Last Closed||2016-07-07 05:52:18



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik pushed to perl-DBD-MySQL (master). "4.034 bump"

2016-07-07 Thread notifications 
From 46496ade34b29d6aa79d572938e8031c8408fb57 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 7 Jul 2016 11:47:35 +0200
Subject: 4.034 bump

---
 .gitignore  |  1 +
 perl-DBD-MySQL.spec | 18 +++---
 sources |  2 +-
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/.gitignore b/.gitignore
index b8b2c74..4decb43 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ DBD-mysql-4.017.tar.gz
 /DBD-mysql-4.031.tar.gz
 /DBD-mysql-4.032.tar.gz
 /DBD-mysql-4.033.tar.gz
+/DBD-mysql-4.034.tar.gz
diff --git a/perl-DBD-MySQL.spec b/perl-DBD-MySQL.spec
index 4f26f12..90acbd7 100644
--- a/perl-DBD-MySQL.spec
+++ b/perl-DBD-MySQL.spec
@@ -1,11 +1,11 @@
 Name:   perl-DBD-MySQL
-Version:4.033
-Release:3%{?dist}
+Version:4.034
+Release:1%{?dist}
 Summary:A MySQL interface for Perl
 Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/DBD-mysql/
-Source0:
http://www.cpan.org/authors/id/C/CA/CAPTTOFU/DBD-mysql-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/M/MI/MICHIELB/DBD-mysql-%{version}.tar.gz
 BuildRequires:  mariadb, mariadb-devel, zlib-devel
 BuildRequires:  coreutils
 BuildRequires:  findutils
@@ -15,7 +15,7 @@ BuildRequires:  perl-generators
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(Config)
 BuildRequires:  perl(Data::Dumper)
-BuildRequires:  perl(DBI) >= 1.08
+BuildRequires:  perl(DBI) >= 1.609
 BuildRequires:  perl(DBI::DBD)
 BuildRequires:  perl(DynaLoader)
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -25,6 +25,7 @@ BuildRequires:  perl(File::Path)
 BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(Getopt::Long)
 BuildRequires:  perl(strict)
+BuildRequires:  perl(utf8)
 BuildRequires:  perl(warnings)
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Provides:   perl-DBD-mysql = %{version}-%{release}
@@ -42,7 +43,7 @@ management system.
 # Correct file permissions
 find . -type f | xargs chmod -x
 
-for file in lib/DBD/mysql.pm ChangeLog; do
+for file in lib/DBD/mysql.pm Changes; do
   iconv -f iso-8859-1 -t utf-8 <$file >${file}_
   touch -r ${file}{,_}
   mv -f ${file}{_,}
@@ -54,7 +55,7 @@ make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -type f -name .packlist -delete
 find %{buildroot} -type f -name '*.bs' -empty -exec rm -f {} ';'
 %{_fixperms} %{buildroot}/*
 
@@ -64,13 +65,16 @@ find %{buildroot} -type f -name '*.bs' -empty -exec rm -f 
{} ';'
 
 %files
 %license LICENSE
-%doc ChangeLog eg README.pod TODO
+%doc Changes README.pod
 %{perl_vendorarch}/Bundle/
 %{perl_vendorarch}/DBD/
 %{perl_vendorarch}/auto/DBD/
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 07 2016 Jitka Plesnikova  - 4.034-1
+- 4.034 bump
+
 * Sun May 15 2016 Jitka Plesnikova  - 4.033-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index ee32f4b..d786597 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7bbaf2ce32e137d0e6045402c550d86c  DBD-mysql-4.033.tar.gz
+769026e585e0fabf4deda18b4322e02a  DBD-mysql-4.034.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DBD-MySQL.git/commit/?h=master=46496ade34b29d6aa79d572938e8031c8408fb57
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata changed psabata's 'watchcommits' permission on perl-Const-Fast (f24) to 'Obsolete'

2016-07-07 Thread notifications 
psabata changed psabata's 'watchcommits' permission on perl-Const-Fast (f24) to 
'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata changed psabata's 'watchbugzilla' permission on perl-Const-Fast (master) to 'Obsolete'

2016-07-07 Thread notifications 
psabata changed psabata's 'watchbugzilla' permission on perl-Const-Fast 
(master) to 'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata changed psabata's 'watchbugzilla' permission on perl-Const-Fast (el6) to 'Obsolete'

2016-07-07 Thread notifications 
psabata changed psabata's 'watchbugzilla' permission on perl-Const-Fast (el6) 
to 'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata changed psabata's 'watchcommits' permission on perl-Const-Fast (el6) to 'Obsolete'

2016-07-07 Thread notifications 
psabata changed psabata's 'watchcommits' permission on perl-Const-Fast (el6) to 
'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata changed psabata's 'watchcommits' permission on perl-Const-Fast (f23) to 'Obsolete'

2016-07-07 Thread notifications 
psabata changed psabata's 'watchcommits' permission on perl-Const-Fast (f23) to 
'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/perl-Const-Fast/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik uploaded DBD-mysql-4.034.tar.gz for perl-DBD-MySQL

2016-07-07 Thread notifications 
769026e585e0fabf4deda18b4322e02a  DBD-mysql-4.034.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-DBD-MySQL/DBD-mysql-4.034.tar.gz/md5/769026e585e0fabf4deda18b4322e02a/DBD-mysql-4.034.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1352894] perl-ExtUtils-HasCompiler-0.016 is available

2016-07-07 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1352894

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-ExtUtils-HasCompiler-0
   ||.016-1.fc25
 Resolution|--- |RAWHIDE
Last Closed||2016-07-07 03:43:27



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik pushed to perl-ExtUtils-HasCompiler (master). "0.016 bump"

2016-07-07 Thread notifications 
From 75ad553acf774e328a783c867f7f758f29a86217 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 7 Jul 2016 09:24:59 +0200
Subject: 0.016 bump

---
 .gitignore | 1 +
 perl-ExtUtils-HasCompiler.spec | 8 ++--
 sources| 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 07f4ac0..30496fd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /ExtUtils-HasCompiler-0.012.tar.gz
 /ExtUtils-HasCompiler-0.013.tar.gz
 /ExtUtils-HasCompiler-0.014.tar.gz
+/ExtUtils-HasCompiler-0.016.tar.gz
diff --git a/perl-ExtUtils-HasCompiler.spec b/perl-ExtUtils-HasCompiler.spec
index d41a770..8016a29 100644
--- a/perl-ExtUtils-HasCompiler.spec
+++ b/perl-ExtUtils-HasCompiler.spec
@@ -1,6 +1,6 @@
 Name:   perl-ExtUtils-HasCompiler
-Version:0.014
-Release:2%{?dist}
+Version:0.016
+Release:1%{?dist}
 Summary:Check for the presence of a compiler
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/ExtUtils-HasCompiler/
@@ -22,6 +22,7 @@ BuildRequires:  perl(File::Basename)
 BuildRequires:  perl(File::Spec::Functions)
 BuildRequires:  perl(File::Temp)
 # Tests
+# ExtUtils::CBuilder - optional
 BuildRequires:  perl(Test::More)
 Requires:   perl(DynaLoader)
 Requires:   perl(ExtUtils::Mksymlists)
@@ -52,6 +53,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 07 2016 Jitka Plesnikova  - 0.016-1
+- 0.016 bump
+
 * Sat May 14 2016 Jitka Plesnikova  - 0.014-2
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index f0954b1..5004840 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e270d1004c5b746fce6a11e2ed97595f  ExtUtils-HasCompiler-0.014.tar.gz
+95fe7b4d286924a3abc16803bc82f1fa  ExtUtils-HasCompiler-0.016.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-ExtUtils-HasCompiler.git/commit/?h=master=75ad553acf774e328a783c867f7f758f29a86217
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik uploaded ExtUtils-HasCompiler-0.016.tar.gz for perl-ExtUtils-HasCompiler

2016-07-07 Thread notifications 
95fe7b4d286924a3abc16803bc82f1fa  ExtUtils-HasCompiler-0.016.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-ExtUtils-HasCompiler/ExtUtils-HasCompiler-0.016.tar.gz/md5/95fe7b4d286924a3abc16803bc82f1fa/ExtUtils-HasCompiler-0.016.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: F25 System Wide Change: Unicode 9.0 support

2016-07-07 Thread pravin....@gmail.com 
missed this email :(

On 5 July 2016 at 23:19, Alexander Ploumistos 
wrote:

> Is there any point in updating fonts in rawhide to their Unicode 9.0
> versions, before the change is implemented?
>

With Unicode 9.0 update libraries will be updated with latest UCD stuff.


>
> Besides the font checking tools that do not know of Unicode 9.0 (or 8, I
> think), will anything important break after such an update?
>

There is no harm or even issues updating fonts prior to this change. Only
issue that might happen is, particular character not get required support
from harfbuzz and pango, since they do not know character properties and
how to render them.

Thanks,
Pravin Satpute
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org