Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[Chris Adams]

Once upon a time, Bruno Wolff III  said:
> On Sat, Jul 02, 2016 at 00:48:14 +0200,
>  Michael Scherer  wrote:
> >So that's rather fast to explain. Libero.it use this SPF record:
> 
> Isn't SPF tied to the envelope sender address and not the From:
> header?

Yes.  Like I said earlier, the problem is DMARC, which is based on the
header From: address.  libero.it has the following DMARC policy record:

"v=DMARC1\; p=quarantine\; rua= mailto:dmarc_agg_...@libero.it, 
mailto:dmarc_...@auth.returnpath.net\; "

So, their policy says that non-conforming messages should be quarantined
by receivers of those messages.  Mailing lists that don't rewrite the
header From: address will cause messages from domains with DMARC
policies of quarantine or reject to be a problem for mail servers that
apply DMARC policies.
-- 
Chris Adams 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Neal Gompa]

On Fri, Jul 1, 2016 at 3:58 PM, Tomas Orsava  wrote:
> Oh, sorry, I didn't look at the user name :)
>
> Could you please expand on what you have written here?
> I'm not sure I follow you entirely.

So, the "problem" with --majorver-provides occurs when either of the
two conditions are true:

* There's no dependency on a specific version of the Python ABI
("python(abi) = X.Y") in the modules
* There's more than one package providing a python implementation per
major version. (i.e. a package providing "python(abi) = 3.4" and
"python(abi) = 3.5")

In either case, you wind up in a scenario where it's possible to BR a
module that would be mismatched to the Python implementation. That is,
the module would be installed in a path that doesn't match the Python
implementation. Thus, the package would be effectively broken, since
it won't work.

However, in Mageia (which is where a variant of this dependency
generator is already used), we've never had this problem because
there's a dependency that forces it to match to the proper Python
implementation (Requires on "python(abi) = X.Y").

And this generator has an additional protection (that doesn't exist in
the Mageia one) in that generated requires use
"pythonX.Ydist(CANONICAL_NAME)" no matter what.

As for the interpreter running the dependency generator, it defaults
to whatever /usr/bin/python is, unless you override it.

-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[Bruno Wolff III]

On Sat, Jul 02, 2016 at 00:48:14 +0200,
 Michael Scherer  wrote:

So that's rather fast to explain. Libero.it use this SPF record:


Isn't SPF tied to the envelope sender address and not the From: header? 
The messages do have an envelope sender address for the list, so I don't 
think SPF should be triggering this problem. SPF is an issue with forwarding 
where the envelope sender address is preserved. (Though it can be written 
if you are willing to relay stuff back to the original sender.)

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

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

Oh, sorry, I didn't look at the user name :)

Could you please expand on what you have written here?
I'm not sure I follow you entirely.

- Original Message -
From: "Neal Gompa" 
To: "Development discussions related to Fedora" 
Sent: Friday, July 1, 2016 5:43:46 PM
Subject: Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

On Fri, Jul 1, 2016 at 8:34 AM, Tomas Orsava  wrote:
> I'm sorry, I could have expanded on it.
>
> The difference is that if we enable --majorver-provides than there's no way
> we can ship more than one Minor version per a Major version [0].
>
> With macros, however, we have no problem shipping two minor versions, and
> the macros will continue to work, pointing to the one we treat as the
> main/default one. We can then also create macros for the additional minor
> version as well.
>
>
> [0] "The option '--majorver-provides' is intended for use
> if only one Python stack per major version will be
> available at a given time, as unexpected results may
> occur if there are multiple independent Python stacks
> per major version available." [1]
>

Yes, I wrote that comment.

The "unexpected" behavior in question is that if you have more than
one stack and you don't have some other constraint, the depsolver
could consider it an equal provider and install the wrong version of
the module for the version of python you want to use to build your
software/package. IMO, if the "python(abi)" requirement is matched
everywhere, it should function no differently than how it does today
when we do builds/rebuilds from one python version to the next. It's
probably worth testing to be sure, though...

The generated dependencies will all be major+minor specific, though.

You'll also probably want to enforce that the dep generator uses
python3 (as I did in my backport testing package[1]), since it uses
the unversioned python shebang by default.

[1]: https://copr.fedorainfracloud.org/coprs/ngompa/rpm-depgen-pythondistdeps/

-- 
真実はいつも一つ！/ Always, there's only one truth!
--
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

Re: new DNF for everyone

[Stephen John Smoogen]

On 1 July 2016 at 17:54, Neal Gompa  wrote:
> On Jul 1, 2016 2:36 PM, "Stephen John Smoogen"  wrote:
>>
>> Do you want to drop dnf from epel since it is so old?
>>
>
> It's required for mock to work for Fedora and Mageia build targets on RHEL
> and CentOS.
>

Ah ok. Thanks for that info. Is the version in EPEL workable for those
build targets or is it broken due to age?

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



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

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[Michael Scherer]

On Fri, Jul 01, 2016 at 05:02:58PM -0500, Michael Catanzaro wrote:
> On Fri, 2016-07-01 at 16:19 -0400, Dan Book wrote:
> > Nobody is blocking you. But aside from this one instance I went
> > digging
> > through my spam folder, I do not see your messages, and I suspect
> > many
> > others do not either. Communication doesn't work if you can't reach
> > the
> > audience, quite literally in this case. But if you don't care, then
> > that's
> > all.
> > -Grinnz
> 
> I checked my spam folder. All of gil's mails have been going there.
> There is this helpful message:
> 
> "Why is this message in Spam? It has a from address in libero.it but
> has failed libero.it's required tests for authentication."
> 
> There is documentation for this:
> 
> https://support.google.com/mail/answer/1366858
> 
> which points to:
> 
> https://dmarc.org/overview/
> 
> I don't understand email, but I suspect gil's problem has something to
> do with that.

So that's rather fast to explain. Libero.it use this SPF record:

$ host -t TXT  libero.it
libero.it descriptive text "v=spf1 ip4:212.48.25.128/25 ip4:212.48.14.160/27 
include:srs.bis.na.blackberry.com include:srs.bis.eu.blackberry.com 
include:srs.bis.ap.blackberry.com include:mail.zendesk.com -all"

basically, if the mail do not come from zendesk or blackberry servers, or from 
the
ranges 212.48.25.128/25 or 212.48.14.160/27, the provider (libero.it) say 
this is a fake mail and a spam (the -all).

A quick look at the headers of mail send by Gil show that indeed, the mail 
do not come from any of the servers authorized to send mail 
on behalf of libero.it.

Ergo, Gmail tag that as spam, because Libero.it say to do so in explicit
and standard respecting way.

So either libero.it change the SPF record, or Gil start to to use libero.it
SMTP, or use a different email in the 'from' header.

We can't really ask to all providers (ie, more than gmail) who use SPF to not 
listen 
to libero.it constraints, for obvious reasons (like "libero.it is fully
authorized to do what they see fit with their domain" being the first one).

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

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[gil]

Il 02/07/2016 00:02, Michael Catanzaro ha scritto:

P.S. gil, keep in mind that we're not going to see your replies.

I can not care less. better that way
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[Neal Gompa]

On Fri, Jul 1, 2016 at 3:02 PM, Michael Catanzaro  wrote:
> On Fri, 2016-07-01 at 16:19 -0400, Dan Book wrote:
>> Nobody is blocking you. But aside from this one instance I went
>> digging
>> through my spam folder, I do not see your messages, and I suspect
>> many
>> others do not either. Communication doesn't work if you can't reach
>> the
>> audience, quite literally in this case. But if you don't care, then
>> that's
>> all.
>> -Grinnz
>
> I checked my spam folder. All of gil's mails have been going there.
> There is this helpful message:
>
> "Why is this message in Spam? It has a from address in libero.it but
> has failed libero.it's required tests for authentication."
>
> There is documentation for this:
>
> https://support.google.com/mail/answer/1366858
>
> which points to:
>
> https://dmarc.org/overview/
>
> I don't understand email, but I suspect gil's problem has something to
> do with that.
>
> Michael
>
> P.S. gil, keep in mind that we're not going to see your replies. ;)

I took a look at the various emails in this thread, and gil's
responses have the following information in the headers:

Received: from localhost.localdomain ([151.60.59.123])
by smtp-33.iol.local with SMTP
id J1zHbqsAiP9dYJ1zHbpzMg; Fri, 01 Jul 2016 19:12:20 +0200
x-libjamoibt: 1601

The information indicates that somewhere along the line, there's an
unauthenticated server doing its own mail transport in the chain. It
also adds a tag that is unique to emails from him, of which I'm unsure
whether it's legit or some kind of tag injection. libero.it also
passes its own information of what servers it considers are valid MTA
sources for its email.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Self Introduction: Kristof Szabo

[Kristof Szabo]

Hi,

I've just raised to my first package review request for ZeroTier (network 
virtualization software) under 
https://bugzilla.redhat.com/show_bug.cgi?id=1352169. 

I think it makes sense if I introduce myself: I'm Kristof Szabo, I live in 
Germany/Düsseldorf, I come from Hungary/Budapest. I'm a consultant, I work as 
solution architect for datacenter IT and cloud services.  My LinkedIn profile 
contains a lot information, feel free to visit it, I don't want to overload 
anybody with the details.

Creating/submitting the package has several drivers: 1. the current binary 
packages distributed on zerotier.com don't fit into a normal package management 
eco-system, they are binary tar.gz packed with an install script 
(consequently:) 2. no SRPMs are distributed, enabling compile time extra 
features requires build from source tarball 3. update management/software 
distribution is not ensured.

Kind regards,
Kristof
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

[Richard W.M. Jones]

On Fri, Jul 01, 2016 at 01:42:40PM -0400, Solomon Peachy wrote:
> With very few exceptions (eg Gigabyte's mostly-unobtainable MP30-AR0 or 
> some locked-down appliance-type servers) they've all been ultra-dense 
> high-end boxes (dozens of cores per U) priced into the stratosphere or 
> glorified cell phone devkits (eg Tegra-based stuff) that don't sport 
> enough memory (or other expandability) to run a modern desktop OS.

While I generally agree with what you're saying, I just want to point
out a few systems that are available now.

The Gigabyte MP30-AR0 can be purchased, eg from
https://www.xcase.co.uk/server-motherboards/gigabyte-mp30-ar0-with-appliedmicror-x-gene1r-processor.html

It's basically an X-Gene 1 which is 3+ years old at this point (made
on an even older process) so don't expect dazzling performance, but
this is still a reliable workhorse for development.  It boots the
upstream kernel, takes up to 128 GB of RAM, and has UEFI
(unfortunately not out of the box).  I have one, and I can stuff a
dozen virtual machines, mixed armv7 & aarch64, without it breaking
into a sweat.

Just appeared a few days ago is this one:
http://www.cnx-software.com/2016/06/26/599-softiron-overdrive-1000-server-is-powered-by-amd-opteron-a1100-64-bit-arm-processor/
Quad core AMD Opteron (codename Seattle, Cortex A57).  A bit cheaper
than the Gigabyte.  UEFI out of the box and comes with SUSE installed.

Finally the LeMaker Cello (also quad core AMD Seattle) is maybe/
possibly/probably going to ship this month, at least according to an
email that they sent out a couple of days ago.  If and when I ever get
it I'll write about it on my blog, https://rwmj.wordpress.com/

I think the aarch64 situation - while hardly ideal - is much better
than POWER.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[Michael Catanzaro]

On Fri, 2016-07-01 at 16:19 -0400, Dan Book wrote:
> Nobody is blocking you. But aside from this one instance I went
> digging
> through my spam folder, I do not see your messages, and I suspect
> many
> others do not either. Communication doesn't work if you can't reach
> the
> audience, quite literally in this case. But if you don't care, then
> that's
> all.
> -Grinnz

I checked my spam folder. All of gil's mails have been going there.
There is this helpful message:

"Why is this message in Spam? It has a from address in libero.it but
has failed libero.it's required tests for authentication."

There is documentation for this:

https://support.google.com/mail/answer/1366858

which points to:

https://dmarc.org/overview/

I don't understand email, but I suspect gil's problem has something to
do with that.

Michael

P.S. gil, keep in mind that we're not going to see your replies. ;)
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: new DNF for everyone

[Neal Gompa]

On Jul 1, 2016 2:36 PM, "Stephen John Smoogen"  wrote:
>
> Do you want to drop dnf from epel since it is so old?
>

It's required for mock to work for Fedora and Mageia build targets on RHEL
and CentOS.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: new DNF for everyone

[Stephen John Smoogen]

Do you want to drop dnf from epel since it is so old?

On 1 July 2016 at 13:06, Honza Šilhan  wrote:
> Hi,
>
> DNF is in EPEL for more than one year, unfortunately there was still
> the old DNF-0.6.4 version. Over that time in DNF were implemented a
> lot of great features and plenty of bugs have been fixed. DNF
> (especially its libraries) could not be updated in EPEL repository
> because of its policy. Now we have prepared fresh DNF-1.1.9 for RHEL 7
> and CentOS 7 users in our COPR repository [1].
>
> In order to install DNF follow the instructions here [2].
>
>
> Honza
>
> [1] 
> https://copr.fedorainfracloud.org/coprs/g/rpm-software-management/dnf-stack-el7/
> [2] http://dnf.baseurl.org/2016/07/01/fresh-dnf-for-rhel-7-and-centos-7/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



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

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[gil]

Il 01/07/2016 22:19, Dan Book ha scritto:
Nobody is blocking you. But aside from this one instance I went 
digging through my spam folder, I do not see your messages, and I 
suspect many others do not either. Communication doesn't work if you 
can't reach the audience, quite literally in this case. But if you 
don't care, then that's all.

-Grinnz

for all my packages, if necessary, each may file a bug?
when I am available @ # fedora-java all can contact me?
I do not see the problem
perhaps gmail has not provided a button for cleaning the spam folder?
I do not want to return to this topic again
regards

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

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[Dan Book]

>
> repeat my self for last time: is not a my problem.
> if you want block another time my fedora account, please,
> take a seat
> regards
> .g
>

Nobody is blocking you. But aside from this one instance I went digging
through my spam folder, I do not see your messages, and I suspect many
others do not either. Communication doesn't work if you can't reach the
audience, quite literally in this case. But if you don't care, then that's
all.
-Grinnz
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[Corey 'linuxmodder' Sheldon]

Inline replies.


On 07/01/2016 05:12 PM, gil wrote:
>
>
>
> Il 01/07/2016 18:41, Jeffrey Ollie ha scritto:
>> Gil, you don't seem to realize that this isn't *our* spam problem,
>> it's *yours*. It's pretty much guaranteed that all of your email sent
>> to the Fedora mailing lists ends up in the spam folder of people that
>> use GMail. There are probably many other providers that do the same.
>> And due to the way that GMail is marking your mail as spam, there's
>> nothing that GMail users can do to change that.
>>
I use gmail and have for Fedora MLs and have no issues Gil But I also
spent teh time to talk to Gmail about  having  previously greylisted
senders whitelisted on their end on ALL 4 of my gmails,  Also I went to
use a fwding alias where it was still an issue,  Maybe you should too.
>>
>> You're lucky that a few of us are conscientious enough to look
>> through our spam folder for your emails (as well of a few other
>> Fedora contributors that get their email routed to the spam folder on
>> a consistent basis). Most of the Fedora contributors that use GMail
>> probably don't bother.
>>
> then use you another provider
Or use a work or  secondary email as a fwd alias  as I mentioned  above.
>> As has been explained a number of times to you, only you (or your
>> email provider) can fix this. You seem to want to be a good Fedora
>> contributor, but whenever someone tries to discuss the issue with
>> you, you've proven to be hostile and uncaring. No one has asked you
>> to switch to another email provider, you just need to have the one
>> you use fix the issues that have been described to you.
>>
>> -- 
>> Jeff Ollie
> repeat my self for last time: is not a my problem.
> if you want block another time my fedora account, please,
> take a seat

We on our end are  not  blocking you its the fact that Gmail has a very
iffy at  times grey-listing  behavior
> regards
> .g
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

-- 

Corey W. Sheldon
PGP: 
0x5A88E539 / C006 564F FA67 CDEA E29B F202 8B4E 8943 5A88 E539
0xD2264944 / 6292 9ABD 6374 6AA7 6D4B 730F 5927 6298 D226 4944
Find me elsewhere: https://gist.github.com/linux-modder/ac5dc6fa211315c633c9

Confidentiality Note:  This message is intended for use only by the individual 
or entity to which it is addressed and may contain information that is 
privileged, confidential, and
exempt from disclosure under applicable law.  If the reader of this message is 
not the intended recipient or the employee or agent responsible for delivering 
the message to the 
intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited.  If you 
have received this communication 
in error, please contact the sender immediately and destroy the material in its 
entirety, whether electronic or hard copy.



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

Re: About dnf failing to honore conditional level in comps.xml

[Luya Tshimbalanga]

On 24/06/16 02:36 AM, Honza Šilhan wrote:
>> From: "Luya Tshimbalanga" 
>>
>> dnf has issues at honoring conditional levels written on comps.xml.
>>
>> As a result, some packages will not be installed by either anaconda or
>> livemedia build system.
>>
>> I have already submitted a bug report on the subject [1] but it was too
>> deep to fix for Fedora 24.
>>
>> By the time of applying the workaround, the freeze was in the process
>> and the suggested change to manually update the kickstart and some
>> comps.xml came too late. That was the case with Design Suite and
>> surprisingly other groups. Currently, the document from fedora-comps[2]
>> fails to take account that problem caused by dnf.
>>
>> Now the focus is for Fedora 25, will be fix come in time so such problem
>> will not occur again?
> Hi,
>
> this is on radar in DNF team while having high priority. It should be fixed
> for F25.
>
> Honza
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Thanks for the head-up, Honza.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

[Josh Boyer]

On Fri, Jul 1, 2016 at 1:42 PM, Solomon Peachy  wrote:
> On Fri, Jul 01, 2016 at 11:35:27AM -0500, Bruno Wolff III wrote:
>> If I could afford it, I'd pay a significant premium to get a Talos board.
>> But as it is, I'm going to be stuck using second hand, pretty old computers
>> for the foreseeable future.
>
> And even though "significant premium" is a polite understatement in this
> case, the Talos was the cheapest [proposed] POWER8 solution by a
> substantial margin.
>
> I've also been quite disappointed in the AArch64 offerings so far.
>
> With very few exceptions (eg Gigabyte's mostly-unobtainable MP30-AR0 or
> some locked-down appliance-type servers) they've all been ultra-dense
> high-end boxes (dozens of cores per U) priced into the stratosphere or
> glorified cell phone devkits (eg Tegra-based stuff) that don't sport
> enough memory (or other expandability) to run a modern desktop OS.

So the thing is, I'm genuinely curious why you would want to run a
desktop OS on either architecture.

From a development perspective, they likely are not going to be wide
enough to attract a ton of manufacturer attention in the
laptop/desktop form factors.  They're a niche market at best, likely
to be filled by Chromebooks in the aarch64 case.  As a developer,
you'd be targeting ChromeOS or Android in that case, not plain Linux.
Certainly not Windows.  All of that seems rather speculative for
making it an attractive development target for a desktop OS and
applications that run on one.

From a manufacturer perspective, you aren't going to make
laptop/desktop boards.  The margins on that would be extremely small,
or your product would be so expensive nobody would buy it.  What
you're going to do is focus on things where you can get
bang-for-the-buck.  Either a consolidation play in the datacenter or
in a massive scale-out workload that's energy efficient.  In either
case, you make the big expensive machines or you make smaller boards
that can expand out in a rack.  That leads to a datacenter/cloud
market.

Cloud instances are relatively cheap, and can be paid for by the hour.
I would think we'd want to focus our efforts around good Cloud and
Server Editions for these architectures.  Doing so attracts both
manufacturers and developers at the same time.

Sure, it would be neat to have a desktop solution and I'm not saying
we shouldn't try there.  I simply think that unlike x86_64, it is
likely the least important thing to focus on because the hardware
won't really be suitable and the developer market is going to be
mostly focused elsewhere for these architectures.

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

Re: Anyone know how to contact maintainer Salimma?

[Avram Lubkin]

Thanks Haïkel. I'll take you up on that if needed, but assuming I don't
hear from him soon, I'll put in a request to take over the package. Sphinx
sees a lot of development, so we need to make sure we keep the latest
maintained in rawhide. The current version is from March 2015.


On Thu, Jun 30, 2016 at 5:20 AM, Haïkel  wrote:

> 2016-06-30 4:59 GMT+02:00 Avram Lubkin :
> >
> > I've been trying to contact Salimma, Michel Alexandre Salim, for the last
> > month. I've been trying to update python-sphinx which hasn't had an
> update
> > since last fall. Worked through all of the issues, but maintainer hasn't
> > responded to commit request, email, or bug reports.
> >
> > Bug report for newest version of Sphinx with needinfo flag.
> > https://bugzilla.redhat.com/show_bug.cgi?id=1323202
> >
> > Anyone have any info?
> >
>
> I see builds from him june, 8 in Koji so he shouldn't be far away.
> Meanwhile, you can send me your patch or add it in the bugzilla and
> I'll apply it in rawhide as provenpackager.
>
>
> >
> > Thanks
> >
> >
> > --
> > 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
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

[Solomon Peachy]

On Fri, Jul 01, 2016 at 11:35:27AM -0500, Bruno Wolff III wrote:
> If I could afford it, I'd pay a significant premium to get a Talos board.
> But as it is, I'm going to be stuck using second hand, pretty old computers
> for the foreseeable future.

And even though "significant premium" is a polite understatement in this 
case, the Talos was the cheapest [proposed] POWER8 solution by a 
substantial margin.

I've also been quite disappointed in the AArch64 offerings so far.

With very few exceptions (eg Gigabyte's mostly-unobtainable MP30-AR0 or 
some locked-down appliance-type servers) they've all been ultra-dense 
high-end boxes (dozens of cores per U) priced into the stratosphere or 
glorified cell phone devkits (eg Tegra-based stuff) that don't sport 
enough memory (or other expandability) to run a modern desktop OS.

/rant

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.


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

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[gil]

Il 01/07/2016 18:41, Jeffrey Ollie ha scritto:
Gil, you don't seem to realize that this isn't *our* spam problem, 
it's *yours*. It's pretty much guaranteed that all of your email sent 
to the Fedora mailing lists ends up in the spam folder of people that 
use GMail. There are probably many other providers that do the same. 
And due to the way that GMail is marking your mail as spam, there's 
nothing that GMail users can do to change that.




You're lucky that a few of us are conscientious enough to look through 
our spam folder for your emails (as well of a few other Fedora 
contributors that get their email routed to the spam folder on a 
consistent basis). Most of the Fedora contributors that use GMail 
probably don't bother.



then use you another provider
As has been explained a number of times to you, only you (or your 
email provider) can fix this. You seem to want to be a good Fedora 
contributor, but whenever someone tries to discuss the issue with you, 
you've proven to be hostile and uncaring. No one has asked you to 
switch to another email provider, you just need to have the one you 
use fix the issues that have been described to you.


--
Jeff Ollie

repeat my self for last time: is not a my problem.
if you want block another time my fedora account, please,
take a seat
regards
.g
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] new DNF for everyone

[Honza Šilhan]

Hi,

DNF is in EPEL for more than one year, unfortunately there was still the old
DNF-0.6.4
version. Over that time in DNF were implemented a lot of great features and
plenty of bugs
have been fixed. DNF (especially its libraries) could not be updated in EPEL
repository
because of its policy. Now we have prepared fresh DNF-1.1.9 for RHEL 7 and
CentOS 7 users
in our COPR repository [1].

In order to install DNF follow the instructions here [2].


Honza

[1] 
https://copr.fedorainfracloud.org/coprs/g/rpm-software-management/dnf-stack-el7/
[2] http://dnf.baseurl.org/2016/07/01/fresh-dnf-for-rhel-7-and-centos-7/
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-de...@lists.fedoraproject.org

new DNF for everyone

[Honza Šilhan]

Hi,

DNF is in EPEL for more than one year, unfortunately there was still
the old DNF-0.6.4 version. Over that time in DNF were implemented a
lot of great features and plenty of bugs have been fixed. DNF
(especially its libraries) could not be updated in EPEL repository
because of its policy. Now we have prepared fresh DNF-1.1.9 for RHEL 7
and CentOS 7 users in our COPR repository [1].

In order to install DNF follow the instructions here [2].


Honza

[1] 
https://copr.fedorainfracloud.org/coprs/g/rpm-software-management/dnf-stack-el7/
[2] http://dnf.baseurl.org/2016/07/01/fresh-dnf-for-rhel-7-and-centos-7/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

HeadsUp: NSS 3.25 released and on it's way to fedora

[Elio Maldonado]

Last week NSS 3.25 was released and it's now on Rawhide and it's now 
slowly making it's to fedora stable branches.


The upstream release notes are at 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.25_release_notes. 
Though it's a minor release it's one with many changes that will require 
careful testing. The Bodhi update is at 
https://bodhi.fedoraproject.org/updates/FEDORA-2016-e6b6475fa1
The last upgrade to nss-3.24 caused a regression that wasn't detected 
until it had gone to stable. This time I have disabled automated karma 
so it gets well tested.


Thanks in advance,

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

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[Jeffrey Ollie]

On Fri, Jul 1, 2016 at 8:42 AM, gil  wrote:

> Il 01/07/2016 01:54, Joel Rees ha scritto:
>
> To keep this off-list as much as possible, the rant is here:
> http://reiisi.blogspot.com/2016/07/to-gil-tim-fedora-et-al.html
>
> (The blame lies elsewhere. I wish I had the network and social cred to
> get a real movement started, away from the current faceless CA system
> and towards a different identity assurance system that depends on
> actual, existing day-to-day trust relationships.)
>
> hi
> as i wrote in the past i dont care about your spam problems
> i dont want to use other providers ... so bored ...
> you dont have something else more interesting to write? No?
> then I'm not interested, i think i will add between unwelcome contact your
> email
>

Gil, you don't seem to realize that this isn't *our* spam problem, it's
*yours*. It's pretty much guaranteed that all of your email sent to the
Fedora mailing lists ends up in the spam folder of people that use GMail.
There are probably many other providers that do the same. And due to the
way that GMail is marking your mail as spam, there's nothing that GMail
users can do to change that.

You're lucky that a few of us are conscientious enough to look through our
spam folder for your emails (as well of a few other Fedora contributors
that get their email routed to the spam folder on a consistent basis). Most
of the Fedora contributors that use GMail probably don't bother.

As has been explained a number of times to you, only you (or your email
provider) can fix this. You seem to want to be a good Fedora contributor,
but whenever someone tries to discuss the issue with you, you've proven to
be hostile and uncaring. No one has asked you to switch to another email
provider, you just need to have the one you use fix the issues that have
been described to you.

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

Re: multi-CPU optimization inside a distribution

[Bruno Wolff III]

On Fri, Jul 01, 2016 at 00:34:02 -0400,
 Gerald Henriksen  wrote:


To get developers they need to get a CPU/motherboard combination out
for under $1000, likely closer to $500, as these will be purchases as
a secondary system to "play with" because there is no direct way to
make money as a POWER developer (this also applies to Aarch64, which
is also looking rather absent).


There is another reason to get the power8 Talos board and that is that you 
get source code for the firmware and there is a reduced chance of a 
deliberate backdoor and bugs that are discovered will br fixable. You don't 
get that with recent Intel or AMD systems.


This doesn't solve problems with firmware in storage systems. They also 
weren't able to include complete documentation related to some parts used 
because of NDAs.


This is still a significant change, and if people want to see hardware 
makers move in this direction voting with your wallet helps.


If I could afford it, I'd pay a significant premium to get a Talos board. 
But as it is, I'm going to be stuck using second hand, pretty old computers 
for the foreseeable future.

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

Summary/Minutes from today's FESCo Meeting (2016-07-01)

[Parag Nemade]

===
#fedora-meeting: FESCO (2016-07-01)
===


Meeting started by paragan at 16:01:02 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2016-07-01/fesco.2016-07-01-16.01.log.html
.



Meeting summary
---
* init process  (paragan, 16:01:02)

* Next week's chair  (paragan, 16:11:17)
  * jsmith will chair for next week meeting (2016-07-08)  (paragan,
16:13:26)

* Open Floor  (paragan, 16:13:55)
  * no quorum today, postpone meeting to next week  (paragan, 16:14:48)

Meeting ended at 16:15:41 UTC.


Action Items



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


People Present (lines said)
---
* paragan (19)
* zodbot (8)
* jsmith (7)
* kalev (3)
* number80 (2)
* sgallagh (0)
* nirik (0)
* jwb (0)
* maxamillion (0)
* dgilmore (0)


Generated by `MeetBot`_ 0.1.4
--
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

[Adam Samalik]

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. :-)

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

-- 

Adam Šamalík
---
Associate Software Engineer
Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide-20160701.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Cloud_base raw-xz i386
Atomic raw-xz x86_64
Kde raw-xz armhfp
Minimal raw-xz armhfp
Workstation live x86_64

Failed openQA tests: 21/78 (x86_64), 2/16 (i386)

ID: 24327   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/24327
ID: 24329   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/24329
ID: 24338   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/24338
ID: 24345   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/24345
ID: 24367   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/24367
ID: 24368   Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/24368
ID: 24369   Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/24369
ID: 24370   Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/24370
ID: 24371   Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/24371
ID: 24372   Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/24372
ID: 24373   Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/24373
ID: 24374   Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/24374
ID: 24375   Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/24375
ID: 24376   Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/24376
ID: 24378   Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/24378
ID: 24380   Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/24380
ID: 24381   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/24381
ID: 24392   Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/24392
ID: 24397   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/24397
ID: 24401   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/24401
ID: 24412   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/24412
ID: 24413   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/24413
ID: 24415   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/24415

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

ID: 24328   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/24328
ID: 24333   Test: x86_64 KDE-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/24333
ID: 24334   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/24334
ID: 24366   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/24366
ID: 24414   Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/24414

Passed openQA tests: 49/78 (x86_64), 12/16 (i386)

Skipped openQA tests: 3 of 94
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Neal Gompa]

On Fri, Jul 1, 2016 at 8:34 AM, Tomas Orsava  wrote:
> I'm sorry, I could have expanded on it.
>
> The difference is that if we enable --majorver-provides than there's no way
> we can ship more than one Minor version per a Major version [0].
>
> With macros, however, we have no problem shipping two minor versions, and
> the macros will continue to work, pointing to the one we treat as the
> main/default one. We can then also create macros for the additional minor
> version as well.
>
>
> [0] "The option '--majorver-provides' is intended for use
> if only one Python stack per major version will be
> available at a given time, as unexpected results may
> occur if there are multiple independent Python stacks
> per major version available." [1]
>

Yes, I wrote that comment.

The "unexpected" behavior in question is that if you have more than
one stack and you don't have some other constraint, the depsolver
could consider it an equal provider and install the wrong version of
the module for the version of python you want to use to build your
software/package. IMO, if the "python(abi)" requirement is matched
everywhere, it should function no differently than how it does today
when we do builds/rebuilds from one python version to the next. It's
probably worth testing to be sure, though...

The generated dependencies will all be major+minor specific, though.

You'll also probably want to enforce that the dep generator uses
python3 (as I did in my backport testing package[1]), since it uses
the unversioned python shebang by default.

[1]: https://copr.fedorainfracloud.org/coprs/ngompa/rpm-depgen-pythondistdeps/

-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

I'm sorry, I could have expanded on it.

The difference is that if we enable --majorver-provides than there's no 
way we can ship more than one Minor version per a Major version [0].


With macros, however, we have no problem shipping two minor versions, 
and the macros will continue to work, pointing to the one we treat as 
the main/default one. We can then also create macros for the additional 
minor version as well.



[0] "The option '--majorver-provides' is intended for use
if only one Python stack per major version will be
available at a given time, as unexpected results may
occur if there are multiple independent Python stacks
per major version available." [1]

[1] 
https://github.com/rpm-software-management/rpm/commit/29abb07fbf6b9ea255bd26e492c104eac8d2370f


On 07/01/2016 02:23 PM, Neal Gompa wrote:

On Fri, Jul 1, 2016 at 2:48 AM, Tomas Orsava  wrote:

Hi Neal!

I believe you will be able to use a macro for that so that dependencies are not 
tied to specific minor versions. I.e. something like:

(Build)Requires: python%{python3_version}dist(somemodule)

Of course that isn't very neat, so maybe 2 macros could be provided that would 
work thus:

(Build)Requires: %python2dist somemodule
(Build)Requires: %python3dist somemodule

That would solve the issue but still allow Fedora to possibly ship 2 different 
minor versions of Python 3 for example.


What makes that different from just enabling the --majorver-provides
and allowing people to use "python3dist(somemodule)" or
"python2dist(somemodule)"?

That said, it's not out of the question to be able to work that way,
as Ruby works similarly in openSUSE (since their system allows them to
support more than one version of ruby in parallel if they want) and
libraries work that way in Mageia.



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

berrange pushed to perl-Sys-Virt (master). "Update to 2.0.0 release (..more)"

[notifications]

From f09cdcdbe55a71fc8a4ddd9b7b782f5c6addd76e Mon Sep 17 00:00:00 2001
From: "Daniel P. Berrange" 
Date: Fri, 1 Jul 2016 15:43:56 +0100
Subject: Update to 2.0.0 release

Signed-off-by: Daniel P. Berrange 
---
 perl-Sys-Virt.spec | 5 -
 sources| 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/perl-Sys-Virt.spec b/perl-Sys-Virt.spec
index 00670fa..20e4c3d 100644
--- a/perl-Sys-Virt.spec
+++ b/perl-Sys-Virt.spec
@@ -1,5 +1,5 @@
 Name:   perl-Sys-Virt
-Version:1.3.5
+Version:2.0.0
 Release:1%{?dist}
 Summary:Represent and manage a libvirt hypervisor connection
 License:GPLv2+ or Artistic
@@ -64,6 +64,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul  1 2016 Daniel P. Berrange  - 2.0.0-1
+- Update to 2.0.0 release
+
 * Tue Jun  7 2016 Daniel P. Berrange  - 1.3.5-1
 - Update to 1.3.5 release
 
diff --git a/sources b/sources
index 08a8a46..df7c67f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-99e30db38ab15ade3ba13ff85bf580ec  Sys-Virt-1.3.5.tar.gz
+1ed5b87f443fc069566ad6918c73fb7f  Sys-Virt-2.0.0.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Sys-Virt.git/commit/?h=master=f09cdcdbe55a71fc8a4ddd9b7b782f5c6addd76e
--
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

berrange uploaded Sys-Virt-2.0.0.tar.gz for perl-Sys-Virt

[notifications]

1ed5b87f443fc069566ad6918c73fb7f  Sys-Virt-2.0.0.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Sys-Virt/Sys-Virt-2.0.0.tar.gz/md5/1ed5b87f443fc069566ad6918c73fb7f/Sys-Virt-2.0.0.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: Schedule for Friday's FESCo Meeting (2016-07-01)

[Parag Nemade]

Hi,

On Fri, Jul 1, 2016 at 7:54 PM, Josh Boyer  wrote:
> On Fri, Jul 1, 2016 at 4:08 AM, Parag Nemade  wrote:
>>
>> #topic #1592 Redefinition of what constitutes a secondary/alternate
>> architecture in Fedora
>> .fesco 1592
>> https://fedorahosted.org/fesco/ticket/1592
>
> I honestly don't think this is ready for a meeting yet.  While I'm
> mostly in support of it, the proposal needs more discussion both in
> the ticket and very likely on this list.  It is absolutely not ready
> to be voted on.

I agree with you but as ticket was filed with meeting keyword and
having only 2 easy tickets on Agenda, I thought to pick this and see
if we can discuss it a bit. I can see its not ready for voting.

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

Re: Schedule for Friday's FESCo Meeting (2016-07-01)

[Josh Boyer]

On Fri, Jul 1, 2016 at 4:08 AM, Parag Nemade  wrote:
>
> #topic #1592 Redefinition of what constitutes a secondary/alternate
> architecture in Fedora
> .fesco 1592
> https://fedorahosted.org/fesco/ticket/1592

I honestly don't think this is ready for a meeting yet.  While I'm
mostly in support of it, the proposal needs more discussion both in
the ticket and very likely on this list.  It is absolutely not ready
to be voted on.

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

Re: [OT] Tim, Gil, et. al. (e-mail address settings)

[gil]

Il 01/07/2016 01:54, Joel Rees ha scritto:

To keep this off-list as much as possible, the rant is here:

http://reiisi.blogspot.com/2016/07/to-gil-tim-fedora-et-al.html

(The blame lies elsewhere. I wish I had the network and social cred to
get a real movement started, away from the current faceless CA system
and towards a different identity assurance system that depends on
actual, existing day-to-day trust relationships.)

hi
as i wrote in the past i dont care about your spam problems
i dont want to use other providers ... so bored ...
you dont have something else more interesting to write? No?
then I'm not interested, i think i will add between unwelcome contact 
your email

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

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

Hi Jason!

Ticket created: https://fedorahosted.org/fpc/ticket/635

Tomas

- Original Message -
From: "Jason L Tibbitts III" 
To: devel@lists.fedoraproject.org
Sent: Thursday, June 30, 2016 6:33:48 PM
Subject: Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

> "JR" == Jaroslav Reznik  writes:

JR> * Proposal owners: Prepare a draft for the Fedora Packaging
JR>   Guidelines for Python

Please open a ticket with FPC sooner rather than later, even if the
draft isn't ready/started.

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

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Neal Gompa]

On Fri, Jul 1, 2016 at 2:48 AM, Tomas Orsava  wrote:
> Hi Neal!
>
> I believe you will be able to use a macro for that so that dependencies are 
> not tied to specific minor versions. I.e. something like:
>
> (Build)Requires: python%{python3_version}dist(somemodule)
>
> Of course that isn't very neat, so maybe 2 macros could be provided that 
> would work thus:
>
> (Build)Requires: %python2dist somemodule
> (Build)Requires: %python3dist somemodule
>
> That would solve the issue but still allow Fedora to possibly ship 2 
> different minor versions of Python 3 for example.
>

What makes that different from just enabling the --majorver-provides
and allowing people to use "python3dist(somemodule)" or
"python2dist(somemodule)"?

That said, it's not out of the question to be able to work that way,
as Ruby works similarly in openSUSE (since their system allows them to
support more than one version of ruby in parallel if they want) and
libraries work that way in Mageia.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20160701.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20160630.n.0
NEW: Fedora-Rawhide-20160701.n.0

= SUMMARY =
Added images:0
Dropped images:  4
Added packages:  3
Dropped packages:1
Upgraded packages:   129
Downgraded packages: 0

Size of added packages:  483.09 KiB
Size of dropped packages:59.85 KiB
Size of upgraded packages:   2.07 GiB
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   -92.25 MiB
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Mate live i386
Path: Spins/i386/iso/Fedora-MATE_Compiz-Live-i386-Rawhide-20160630.n.0.iso
Image: Astronomy_KDE live i386
Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20160630.n.0.iso
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20160630.n.0.iso
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20160630.n.0.iso

= ADDED PACKAGES =
Package: php-pecl-apcu-bc-1.0.3-3.fc25
Summary: APCu Backwards Compatibility Module
RPMs:php-pecl-apcu-bc
Size:59606 bytes

Package: python-unidiff-0.5.2-2.fc25
Summary: Python library to parse and interact with unified diffs (patches)
RPMs:python2-unidiff python3-unidiff
Size:43012 bytes

Package: rubygem-nio4r-1.2.1-2.fc25
Summary: New IO for Ruby
RPMs:rubygem-nio4r rubygem-nio4r-doc
Size:392068 bytes


= DROPPED PACKAGES =
Package: php-pear-Services-Weather-1.4.7-7.fc24
Summary: This class acts as an interface to various online weather-services
RPMs:php-pear-Services-Weather
Size:61290 bytes


= UPGRADED PACKAGES =
Package:  CBFlib-0.9.5.15-1.fc25
Old package:  CBFlib-0.9.5.14-3.fc24
Summary:  Crystallographic Binary File and Image Library
RPMs: CBFlib CBFlib-devel
Size: 5196344 bytes
Size change:  -19364 bytes
Changelog:
  * Wed Jun 29 2016 Orion Poplawski <or...@cora.nwra.com> - 0.9.5.15-1
  - Update to 0.9.5.15


Package:  ETL-1.1.10-0.20160624gitd4e547.fc25
Old package:  ETL-0.04.17-5.fc24
Summary:  Extended Template Library
RPMs: ETL-devel
Size: 396578 bytes
Size change:  460 bytes
Changelog:
  * Fri Jun 24 2016 Jon Ciesla <limburg...@gmail.com> - 
1.1.10-0.20160624gitd4e547
  - Latest upstream.


Package:  Field3D-1.7.2-2.fc25
Old package:  Field3D-1.7.2-1.fc25
Summary:  Library for storing voxel data
RPMs: Field3D Field3D-devel
Size: 5916208 bytes
Size change:  304 bytes
Changelog:
  * Wed Jun 29 2016 Orion Poplawski <or...@cora.nwra.com> - 1.7.2-2
  - Rebuild for hdf5 1.8.17


Package:  NetworkManager-libreswan-1.2.4-1.fc25
Old package:  NetworkManager-libreswan-1.2.2-1.fc25
Summary:  NetworkManager VPN plug-in for IPsec VPN
RPMs: NetworkManager-libreswan NetworkManager-libreswan-gnome
Size: 468612 bytes
Size change:  43116 bytes
Changelog:
  * Thu Jun 30 2016 Thomas Haller <thal...@redhat.com> - 1.2.4-1
  - Update to 1.2.4 release
  - Move base VPN plugin library to base libreswan package
  - Don't require nm-connection-editor anymore


Package:  ViTables-2.1-15.fc25
Old package:  ViTables-2.1-14.fc24
Summary:  Viewer for Hierarchical Datafiles (HDF5)
RPMs: ViTables ViTables-doc
Size: 2365248 bytes
Size change:  -2380 bytes
Changelog:
  * Wed Jun 29 2016 Orion Poplawski <or...@cora.nwra.com> - 2.1-15
  - Rebuild for hdf5 1.8.17


Package:  adwaita-qt-0.4-3.fc25
Old package:  adwaita-qt-0.4-2.fc25
Summary:  Adwaita theme for Qt-based applications
RPMs: adwaita-qt adwaita-qt-common adwaita-qt4 adwaita-qt5
Size: 635732 bytes
Size change:  948 bytes
Changelog:
  * Thu Jun 30 2016 Jan Grulich <jgrul...@redhat.com> - 0.4-3
  - Properly fix missing menubar in QtCreator


Package:  amavisd-new-2.11.0-3.fc25
Old package:  amavisd-new-2.11.0-2.fc25
Summary:  Email filter with virus scanner and spamassassin support
RPMs: amavisd-new amavisd-new-snmp amavisd-new-snmp-zeromq 
amavisd-new-zeromq
Size: 989880 bytes
Size change:  456 bytes
Changelog:
  * Thu Jun 30 2016 Juan Orti Alcaine <jo...@fedoraproject.org> 2.11.0-3
  - Additional systemd hardening (RHBZ#1351354)


Package:  ansible-lint-3.1.1-1.fc25
Old package:  ansible-lint-3.1.0-1.fc25
Summary:  Best practices checker for Ansible
RPMs: ansible-lint
Size: 43014 bytes
Size change:  264 bytes
Changelog:
  * Thu Jun 30 2016 Parag Nemade  - 3.1.1-1
  - Upstream release 3.1.1


Package:  apache-poi-3.14-3.fc25
Old package:  apache-poi-3.14-2.fc25
Summary:  The Java API for Microsoft Documents
RPMs: apache-poi apache-poi-javadoc
Size: 14019964 bytes
Size change:  -1836 bytes
Changelog:
  * Wed Jun 29 2016 gil cattaneo <punto...@libero.it> 3.14-3
  - removed some test failures


Package:  armadillo-7.200.2-3.fc25
Old package:  armadillo-7.200.2-1.fc25
Summary:  Fast C++ matrix 

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 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)
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)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Algorithm-Permute

[buildsys]

perl-Algorithm-Permute has broken dependencies in the rawhide tree:
On x86_64:
perl-Algorithm-Permute-0.12-21.fc24.x86_64 requires 
libperl.so.5.22()(64bit)
perl-Algorithm-Permute-0.12-21.fc24.x86_64 requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Algorithm-Permute-0.12-21.fc24.i686 requires libperl.so.5.22
perl-Algorithm-Permute-0.12-21.fc24.i686 requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Algorithm-Permute-0.12-21.fc24.armv7hl requires libperl.so.5.22
perl-Algorithm-Permute-0.12-21.fc24.armv7hl requires 
perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

--
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 Self Contained Change: Erlang 19

[Jaroslav Reznik]

= Proposed Self Contained Change: Erlang 19 =
https://fedoraproject.org/wiki/Changes/Erlang_19

Change owner(s):
* Peter Lemenkov 
* Fedora Erlang SIG 
* Randy Barlow 
* Jeremy Cline 

== Detailed Description ==
Upgrade Erlang to version 19 which brings a lot of good stuff. Just a few 
highlights:

* A new state machine behavior - gen_statem.
* An experimental plugin to mnesia which allows using expernal storage 
solutions (leveldb, for example) - mnesia_ext.
* Cryptographic functions speedups.
* Even better dirty NIF schedulers [1].
* Experimental support for Unix Domain Sockets which opens a door for native 
Journald, systemd-notify, D-Bus implementations.

Aside from this, we plan to improve quality of Erlang and related packages. 
These are shortcomings we want to address:

* We should enable so-called dirty NIF scheduler [1] which is still disabled 
currently.
* Every daemon written in Erlang has its own logging solution which doesn't 
use neither syslog nor Journald. We should start switching them to Journald.
* We should add ability to use D-Bus via erlang-dbus library.
* Further improve Erlang Packaging Guidelines [2].

== Scope ==
* Proposal owners:
** Upgrade Erlang to the latest version (19.0.1) [3].
** We must rebuild every package which requires NIF or Driver version (listed 
below in the [[#Dependencies|Dependencies]] section) against Erlang 19.x.y.
** Every Erlang daemon's systemd unit must require epmd.socket.
** Consider allowing EPMD implementation switching. Erlang is about choice!
** We need to fill new review request for erlang-ejournald [4]
*** We have to fill new review request for erlang-lager_journald_backend [5]
** We need to fill new review request for erlang-dbus [6]
** Add another default directory to look for Erlang *.beam files.
** Upgrade outdated packages:
*** Riak [7]
 Riak has has been retired. We have to re-add it back.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines:
** We should promote officially Erlang Packaging Guidelines [2].

[1] https://medium.com/@jlouis666/erlang-dirty-scheduler-overhead-6e1219dcc7
[2] User:Peter/Erlang_Packaging_Guidelines
[3] https://bugzilla.redhat.com/1348957
[4] https://github.com/travelping/ejournald
[5] https://github.com/travelping/lager_journald_backend
[6] https://github.com/lizenn/erlang-dbus
[7] https://apps.fedoraproject.org/packages/riak
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ppisar changed ppisar's 'watchbugzilla' permission on perl-libintl (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-libintl (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-libintl/
--
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 ppisar's 'approveacls' permission on perl-libintl (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-libintl (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-libintl/
--
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 owner of perl-libintl (el5) to 'ppisar'

[notifications]

ppisar changed owner of perl-libintl (el5) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-libintl/
--
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 ppisar's 'watchcommits' permission on perl-libintl (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-libintl (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-libintl/
--
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 ppisar's 'commit' permission on perl-libintl (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-libintl (el5) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-libintl/
--
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-Log-Log4perl (el5) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on perl-Log-Log4perl (el5) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Log-Log4perl/
--
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 'watchbugzilla' permission on perl-Log-Log4perl (el5) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Log-Log4perl (el5) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Log-Log4perl/
--
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 ppisar's 'watchcommits' permission on perl-Log-Log4perl (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-Log-Log4perl (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Log-Log4perl/
--
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 ppisar's 'commit' permission on perl-Log-Log4perl (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-Log-Log4perl (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Log-Log4perl/
--
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 ppisar's 'watchbugzilla' permission on perl-Log-Log4perl (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-Log-Log4perl (el5) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Log-Log4perl/
--
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 owner of perl-Log-Log4perl (el5) to 'ppisar'

[notifications]

ppisar changed owner of perl-Log-Log4perl (el5) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-Log-Log4perl/
--
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 ppisar's 'approveacls' permission on perl-Log-Log4perl (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-Log-Log4perl (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Log-Log4perl/
--
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 'watchbugzilla' permission on perl-Config-Simple (el5) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Config-Simple 
(el5) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Config-Simple/
--
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-Config-Simple (el5) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on perl-Config-Simple (el5) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Config-Simple/
--
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 ppisar's 'approveacls' permission on perl-Config-Simple (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-Config-Simple (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Config-Simple/
--
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 ppisar's 'watchcommits' permission on perl-Config-Simple (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-Config-Simple (el5) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Config-Simple/
--
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 ppisar's 'watchbugzilla' permission on perl-Config-Simple (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-Config-Simple (el5) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Config-Simple/
--
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 owner of perl-Config-Simple (el5) to 'ppisar'

[notifications]

ppisar changed owner of perl-Config-Simple (el5) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-Config-Simple/
--
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 ppisar's 'commit' permission on perl-Config-Simple (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-Config-Simple (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Config-Simple/
--
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 Self Contained Change: IBus Emoji Typing

[Jaroslav Reznik]

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

ppisar changed ppisar's 'commit' permission on perl-Apache-DBI (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-Apache-DBI (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'watchcommits' permission on perl-Apache-DBI (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-Apache-DBI (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'approveacls' permission on perl-Apache-DBI (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-Apache-DBI (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'watchbugzilla' permission on perl-Apache-DBI (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-Apache-DBI (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'watchcommits' permission on perl-Apache-DBI (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-Apache-DBI (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'watchbugzilla' permission on perl-Apache-DBI (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-Apache-DBI (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 owner of perl-Apache-DBI (el6) to 'ppisar'

[notifications]

ppisar changed owner of perl-Apache-DBI (el6) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'approveacls' permission on perl-Apache-DBI (epel7) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-Apache-DBI (epel7) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 owner of perl-Apache-DBI (el5) to 'ppisar'

[notifications]

ppisar changed owner of perl-Apache-DBI (el5) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'watchcommits' permission on perl-Apache-DBI (epel7) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-Apache-DBI (epel7) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'approveacls' permission on perl-Apache-DBI (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-Apache-DBI (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'commit' permission on perl-Apache-DBI (el6) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-Apache-DBI (el6) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'watchbugzilla' permission on perl-Apache-DBI (epel7) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-Apache-DBI (epel7) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 ppisar's 'commit' permission on perl-Apache-DBI (epel7) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-Apache-DBI (epel7) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 owner of perl-Apache-DBI (epel7) to 'ppisar'

[notifications]

ppisar changed owner of perl-Apache-DBI (epel7) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI/
--
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 carlgeorge's 'commit' permission on perl-Proc-Daemon (el5) to 'Obsolete'

[notifications]

ppisar changed carlgeorge's 'commit' permission on perl-Proc-Daemon (el5) to 
'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/perl-Proc-Daemon/
--
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 ppisar's 'approveacls' permission on perl-Proc-Daemon (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-Proc-Daemon (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Proc-Daemon/
--
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 ppisar's 'watchbugzilla' permission on perl-Proc-Daemon (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-Proc-Daemon (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Proc-Daemon/
--
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 owner of perl-Proc-Daemon (el5) to 'ppisar'

[notifications]

ppisar changed owner of perl-Proc-Daemon (el5) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-Proc-Daemon/
--
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 ppisar's 'watchcommits' permission on perl-Proc-Daemon (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-Proc-Daemon (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Proc-Daemon/
--
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 ppisar's 'commit' permission on perl-Proc-Daemon (el5) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-Proc-Daemon (el5) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Proc-Daemon/
--
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 ppisar's 'watchbugzilla' permission on perl-JSON-Any (epel7) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchbugzilla' permission on perl-JSON-Any (epel7) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-JSON-Any/
--
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 ppisar's 'watchcommits' permission on perl-JSON-Any (epel7) to 'Approved'

[notifications]

ppisar changed ppisar's 'watchcommits' permission on perl-JSON-Any (epel7) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-JSON-Any/
--
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 owner of perl-JSON-Any (epel7) to 'ppisar'

[notifications]

ppisar changed owner of perl-JSON-Any (epel7) to 'ppisar'
https://admin.fedoraproject.org/pkgdb/package/perl-JSON-Any/
--
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 ppisar's 'approveacls' permission on perl-JSON-Any (epel7) to 'Approved'

[notifications]

ppisar changed ppisar's 'approveacls' permission on perl-JSON-Any (epel7) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-JSON-Any/
--
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 ppisar's 'commit' permission on perl-JSON-Any (epel7) to 'Approved'

[notifications]

ppisar changed ppisar's 'commit' permission on perl-JSON-Any (epel7) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-JSON-Any/
--
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: Looking for a proven packager

[Jonathan Wakely]

On 01/07/16 10:57 +0100, Jonathan Wakely wrote:

On 30/06/16 16:27 +, Christopher wrote:

On Thu, Jun 30, 2016 at 4:35 AM Peter Robinson  wrote:


On Thu, Jun 30, 2016 at 9:30 AM, Igor Gnatenko 
wrote:

First thing you should do is to send your patch upstream. If upstream
will say "it's good patch", I will help you to get it in Fedora before
upstream will release new version. Unfortunately it's not possible in
other way.


In the hadoop case it might not be valid to do that as the version in
Fedora is quite out of date compared to upstream.



Fedora's version may be out of date, but I suspect that this particular
part of Hadoop's code is not fast moving, and would still be relevant to
even their latest versions. At the very least, it's worth an attempt to
contact them upstream first.

I do have an interest in updating Fedora's packaged version of Hadoop, and
if the patch is good, it'd be nice to have it in upstream so we don't have
to keep it around when we move to the newer version. So, even if they
aren't willing to support the patch for our version, if they're willing to
support it in any of their latest supported versions, I'd be fine keeping
the backported patch until we upgrade.

As I said in the BZ, I just don't have the expertise to evaluate the patch
myself to know if it's good or if it's going to cause problems. A +1 from
upstream, a proven packager, or the secondary arch team, would be
sufficient for me.


A security expert and a proven packager have evaluated it, and pointed
out two bugs in the code.

That's minus two so far, how many do you need?


Oh, I see they've been responded to.  The aliasing problem might be
pre-existing, but is still wrong.

I guess if someone else wants to approve it I don't care.

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

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

[notifications]

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

https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-Copyright/
--
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

pkgdb_updater updated: description of perl-Scalar-Does

[notifications]

pkgdb_updater updated: description of perl-Scalar-Does
https://admin.fedoraproject.org/pkgdb/package/perl-Scalar-Does/
--
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

pkgdb_updater updated: description, upstream_url of perl-Module-Install-RDF

[notifications]

pkgdb_updater updated: description, upstream_url of perl-Module-Install-RDF
https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-RDF/
--
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

pkgdb_updater updated: description of perl-MooX-Struct

[notifications]

pkgdb_updater updated: description of perl-MooX-Struct
https://admin.fedoraproject.org/pkgdb/package/perl-MooX-Struct/
--
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

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

[notifications]

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

https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-Contributors/
--
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

pkgdb_updater updated: description, upstream_url of perl-forks

[notifications]

pkgdb_updater updated: description, upstream_url of perl-forks
https://admin.fedoraproject.org/pkgdb/package/perl-forks/
--
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

pkgdb_updater updated: description of perl-lexical-underscore

[notifications]

pkgdb_updater updated: description of perl-lexical-underscore
https://admin.fedoraproject.org/pkgdb/package/perl-lexical-underscore/
--
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

pkgdb_updater updated: summary, description of perl-Gtk2-Ex-PodViewer

[notifications]

pkgdb_updater updated: summary, description of perl-Gtk2-Ex-PodViewer
https://admin.fedoraproject.org/pkgdb/package/perl-Gtk2-Ex-PodViewer/
--
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: Looking for a proven packager

[Jonathan Wakely]

On 30/06/16 16:27 +, Christopher wrote:

On Thu, Jun 30, 2016 at 4:35 AM Peter Robinson  wrote:


On Thu, Jun 30, 2016 at 9:30 AM, Igor Gnatenko 
wrote:
> First thing you should do is to send your patch upstream. If upstream
> will say "it's good patch", I will help you to get it in Fedora before
> upstream will release new version. Unfortunately it's not possible in
> other way.

In the hadoop case it might not be valid to do that as the version in
Fedora is quite out of date compared to upstream.



Fedora's version may be out of date, but I suspect that this particular
part of Hadoop's code is not fast moving, and would still be relevant to
even their latest versions. At the very least, it's worth an attempt to
contact them upstream first.

I do have an interest in updating Fedora's packaged version of Hadoop, and
if the patch is good, it'd be nice to have it in upstream so we don't have
to keep it around when we move to the newer version. So, even if they
aren't willing to support the patch for our version, if they're willing to
support it in any of their latest supported versions, I'd be fine keeping
the backported patch until we upgrade.

As I said in the BZ, I just don't have the expertise to evaluate the patch
myself to know if it's good or if it's going to cause problems. A +1 from
upstream, a proven packager, or the secondary arch team, would be
sufficient for me.


A security expert and a proven packager have evaluated it, and pointed
out two bugs in the code.

That's minus two so far, how many do you need?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

Hi Neal!

I believe you will be able to use a macro for that so that dependencies are not 
tied to specific minor versions. I.e. something like:

(Build)Requires: python%{python3_version}dist(somemodule)

Of course that isn't very neat, so maybe 2 macros could be provided that would 
work thus:

(Build)Requires: %python2dist somemodule
(Build)Requires: %python3dist somemodule

That would solve the issue but still allow Fedora to possibly ship 2 different 
minor versions of Python 3 for example.

Tomas

- Original Message -
From: "Neal Gompa" 
To: "Development discussions related to Fedora" 
Sent: Thursday, June 30, 2016 2:31:51 PM
Subject: Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

On Thu, Jun 30, 2016 at 5:20 AM, Jaroslav Reznik  wrote:
> = Proposed System Wide Change: Automatic Provides for Python RPM Packages =
> https://fedoraproject.org/wiki/Changes/
> Automatic_Provides_for_Python_RPM_Packages
>
> Change owner(s):
> * Tomas Orsava 
> * Miro Hroncok 
> * Email: python-ma...@redhat.com
>
> Upon building Python packages containing packaging metadata, RPM will
> automatically detect the standardized name of the software (i.e. dist name,
> name on PyPI) in the canonical format [1] and create a virtual Provides tag
> with the value pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python
> version. RPM may also detect dependencies of the software from the metadata
> and automatically require them using the same syntax.
>
> == Detailed Description ==
> If during the building of a Python package RPM encounters .egg-info, .egg-link
> or .dist-info files (provided in Python Wheels and Eggs), it will read the
> standardized name of the software (i.e. dist name, name on PyPI) in the
> canonical format and create a virtual Provides tag with the value
> pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python version. Note that
> the canonical format can differ slightly from the name displayed, for example,
> on PyPI.[1]
>
> RPM will also detect dependencies of the software from the aforementioned
> metadata files and automatically require them using the format
> pythonX.Ydist(). However, because these files don't always contain the full
> list of requirements (which are either in setup.py or requirements.txt), the
> dependency generator will not be conclusive.
>
> All Python packages will need to be rebuilt so that the virtual Provides tags
> are generated and can be used by users, scripts and the requires generator.
>
> == Scope ==
> * Proposal owners: Prepare a draft for the Fedora Packaging Guidelines for
> Python
>
> * Maintainers of the RPM package: Backport the functionality from upsteram to
> Fedora. — Already done thanks to Florian Festi [2]
>
> * Release engineering: Targeted rebuild of Python packages. Ticket [3].
>
> * List of deliverables: All Fedora deliverables will be affected, but only in
> a very minor way that in no way jeopardizes their delivery.
>
> * Policies and guidelines: Fedora Packaging Guidelines for Python need to be
> updated after the implementation so users know how to take advantage of the
> change.
>
> * Trademark approval: Not needed for this Change
>
> [1] https://fedoraproject.org/wiki/Changes/
> Automatic_Provides_for_Python_RPM_Packages#cite_note-canonical-0

It's awesome that this is finally going to make it into Fedora.
However, I strongly advise you have the --majorver-provides enabled
along with the default one, because that way, spec files can be
written in such a way that they can have BuildRequires that aren't
specific to a minor version of Python. The dependency generator
*always* uses the pythonX.Ydist(CANONICAL_NAME) format for generated
dependencies. The addition of pythonXdist(CANONICAL_NAME) Provides
just makes it easier to have BuildRequires for them so that mass
changes for spec files aren't required on every Y version bump.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
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: Replication after full online init

[Ludwig Krispenz]

On 07/01/2016 04:08 AM, William Brown wrote:

On Thu, 2016-06-30 at 14:53 -0700, Noriko Hosoi wrote:

On 06/30/2016 12:45 AM, Ludwig Krispenz wrote:

Hi William,

the reason that after  a total init the consumer does not have the
latest state of the supplier RUV and is receiving updates based on the
RUV at start of the total init is independent of the modrdn problem.
When a supplier is performing a total init it is still accepting
changes, the total init can take a while and there are scenarios where
an entry which is already sent is updated before total init finishes.
We cannot loose these changes.

OK...  Then, RUV needs to be created at the time when the supplier
starts online init?

The test case would be something like this?
1. run online init on the supplier.
2. do some operation like move entries against the supplier while the
online init is still running on the consumer.
3. do some operation which depends upon the previous operation done in
the step 2.
4. check the consumer is healthy or not.

Isn't it a timestamp issue from which operation should be replayed after
the total update?  Regardless of the way how to fix 48755, unless the
step 2 operation(s) are replayed after the online init is done, the
consumer could get broken/inconsistent?


It's not the "post init" operations I'm worried about.

It's that operations that were part of the init to the consumer are
replayed from the changelog.

Operations that occurred after the init starts, definitely still need to
be replayed, and this makes sense.

Lets say we have:

1 - insert A
2 - insert ou=B
3 - modrdn A under ou=B
4 - insert C
xx <<-- We start to transmit the data here.
if we start the total update here, the supplier will send its RUV in the 
start repl request, it will be set as RUV in the consumer after total 
init is complete.

it skips to send the ruv entry

so mods 1-4 will not be replayed

5 - modrdn C


Once the online init is complete, the master replays the log from event
1 -> 5 to the consumer, even though it should now be up to date at
position 4.

it is


Previously we could not guarantee this because in the scenario above, A
would have sorted before ou=B, by would not be able to be applied
because the consumer hadn't seen B yet. So after the init, the consumer
would have B and C, but not A, so we had to replay 1 -> 4 to fix this
up.

So I am suggesting that when we begin the online init we set the RUV of
the consumer to match the CSN of the master at the moment we begin the
transmission of data, so that we only need to replay event 5+, rather
than 1->5+

Does that make sense?

yes, and I think that is what it is doing now





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


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

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