Re: No more deltarpms by default

[Gerald B. Cox]

On Fri, Oct 17, 2014 at 9:58 AM, Tom Rivers  wrote:

> My point was to say Linux users are usually more tech savvy than XBox and
> Playstation users.  If they say they have a high speed connection and they
> don't and that decision ends up costing them more money in ISP costs, then
> that's on them.  Still, that's really not the crux of what I've been trying
> to say.


That wasn't quite my point.  What I was attempting to convey is that people
with high bandwidth connections would be choosing that option because they
would believe it would be "more better" - regardless of whether or not they
cared much about speeding up their updates.  I would venture to say for the
vast majority of users, any time savings really doesn't matter.  They just
don't care.  However, choosing that option would have real implications
upstream.  All of a sudden more repositories would be called upon to
deliver full RPMs... that is alot more bandwidth, which translates to $$$.
Regardless of whether or not it is a university or even Redhat... everyone
has a budget, and they would be concerned about increased costs.  Many
people don't understand networks; they think it's just an unlimited
resource that is free.  Nothing more could be further from the truth.  When
people see the costs they say WTF and quickly change their tune.  I
understand that thankfully DNF will keep Presto as the default; but if the
issue is revisited people need to realize it isn't just about them - there
are implications upstream - and I believe if they were presented the bill,
they would quickly say "oh, it's not  that important to wait an extra few
minutes to have my updates applied".

The bottom line is Presto needs to be improved.  That is the solution.  In
the meantime if people want to download full RPMs they are free to change
the option themselves - and they should be happy it isn't default; because
if it were and everyone was downloading full RPMs they would most likely
see that repository circuits become saturated and their downloads would
come screeching to a halt.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self Introduction: Piotr Popieluch

[Piotr Popieluch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

My name is Piotr Popieluch and live in the Hague in the Netherlands. I
work as a Unix sysadmin with focus on monitoring. I manage rhel boxes
professionally and use Fedora on my laptop. Because of this I want to
give back and want to become a Fedora package maintainer.

I've packaged two packages, python-structlog and graphite-api which
depends on the former. I need a sponsor.

python-structlog: https://bugzilla.redhat.com/show_bug.cgi?id=1154213
graphite-api: https://bugzilla.redhat.com/show_bug.cgi?id=1154218

I've done one unofficial review:
https://bugzilla.redhat.com/show_bug.cgi?id=1151759

Kind regards,


Piotr


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUQZr6AAoJEPHEApzE46n5CHwQAJVmvPbXE3ha0Z+ksc65znBE
2+Q4aAoPkoiQQvfkG6svSqSeMm4qgwHlLjx2qKqZa8mwYfbUdJTb82xzyQL46nyn
iocPlaml3n9wHWBWV2dqhKCHsOfckpoyYHlnKDT+9veHVD0GPZR6zqoF1lFhGgwf
kLWIvBmPQrXIRT/iQoxxmV/SByivHVbXuwlouBDaeeTAsFojvinHwboTA9dHyMra
hzvu67BpqtWHA+bfg47J0ITzqk747uDKzbESfgBxgTd2ZaipWI7918h/HhVhxaCp
0gHdqDwmp09Tbz04Fnuo/ttM25Cbg+Jo2G9phXy6wGhu+A8e/9iPwvMbBQP4oX+A
u1eSV5m9szar8UMAuE6brZj4iafLRdUu7ANjIgYU6k12c7Vlo97YthWoIv9YBSoH
W57aXelqYlikXlPGjt3tkFQcC/yqYBjkdmdnHtcLFKedqy3KyDzlGIWM+09ED8wF
pl+O5KJjEZxVzS+bmicEa+9XqMhhsbmEB6xO7tf6XgeDyy3hcUECyu7PKOgYjTDf
VbeVC2uHOKQ7IDnW8fVBmPXIChSnYFkmELtxXWe0vKOEwK5xhI5ff2g13wcUc6id
4AswWnZVVIb5jtqZ62xAe4ZyVX2BoWWSi52oMkpGzx4wfm4Hc2WKDD3j2FiWPSbs
tkSpG/EFwh5STP0mfxX/
=m6KS
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 21 Beta Test Compose 4 (TC4) Available Now!

[Andre Robatino]

As per the Fedora 21 schedule [1], Fedora 21 Beta Test Compose 4 (TC4)
is now available for testing. Content information, including changes,
can be found at https://fedorahosted.org/rel-eng/ticket/6010#comment:7 .
Please see the following pages for download links (including delta ISOs)
and testing instructions. Normally dl.fedoraproject.org should provide
the fastest download, but download-ib01.fedoraproject.org is available
as a mirror (with an approximately 1 hour lag) in case of trouble. To
use it, just replace "dl" with "download-ib01" in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Workstation and Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Server:

https://fedoraproject.org/wiki/Test_Results:Current_Server_Test

Cloud:

https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test

Summary:

https://fedoraproject.org/wiki/Test_Results:Current_Summary

Ideally, all Alpha and Beta priority test cases for each of these test
pages [2] should pass in order to meet the Beta Release Criteria [3].
Help is available on #fedora-qa on irc.freenode.net [4], or on the test
list [5].

Create Fedora 21 Beta test compose (TC) and release candidate (RC)
https://fedorahosted.org/rel-eng/ticket/6010

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://admin.fedoraproject.org/mailman/listinfo/test





signature.asc
Description: OpenPGP digital signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

5tFTW: Fedora Council, L10N Zanata, FUDCon LATAM, Taskotron, and Retrace improvements (2014-10-17)

[Matthew Miller]

Reposted from .

Fedora is a big project, and it’s hard to keep up with everything that
goes on. This series highlights interesting happenings in five
different areas every week. It isn’t comprehensive news coverage — just
quick summaries with links to each. Here are the five things for
October 17th, 2014:


Introducing the Fedora Council
--

Last week, the Fedora Project Board unanimously approved its
replacement, a new top-level leadership and governance body we’re
calling the *Fedora Council*. Read more about it in John Rose’s
announcement message, and our previous Fedora Magazine article about
upcoming elections.

This didn’t happen overnight — Christoph Wickert, Toshio Kuratomi, Josh
Boyer, and others have been talking about this and working on related
proposals for the last couple of years, and Toshio and Haïkel Guémar
led a great session at Flock — Fedora’s big annual planning conference
— this August. We’ve been thinking about and discussing what to do ever
since, and now it’s time to put the result into action!

  * http://fedoraproject.org/wiki/Board
  * http://fedoramagazine.org/fedora-governance-proposal-approved/
  * http://fedoramagazine.org/fedora-council-elections-coming-soon/
  * http://flock2014.sched.org/event/9d2f47d741d92f1ddf559bb918dcb2d1


Translation team switches to Zanata
---

Fedora’s L10N team — the *L-10-N* is short for localization, because
there are 10 missing letters there — does an amazing job of translating
our software to dozens of different languages. (If you’re a Fedora user
who speaks a language other than English, this is a great and fun way
to get involved, by the way — see the steps to join in the Fedora
Localization Guide.)

All of this work is accomplished using some specialized tools. For a
long time, Fedora has used Transifex, a project by Dimitris Glezos
which actually grew out of Fedora. Unfortunately, recent versions of
Transifex are not open source. As a project, we always prefer to work
with open source tools whenever possible, and the L10N team started a
project to migrate to a different and completely free and open source
tool, Zanata.

Last week, all translation teams for different languages discussed and
voted whether to move ahead with this, and the result was 19 “Go” votes
and none against. With the active contributor community overwhelmingly
in favor, it’s an easy decision to go forward, and according to the
plan, the new “stage 1″ service should be live any day now.

  * https://fedoraproject.org/wiki/L10N
  * https://fedoraproject.org/wiki/L10N/Guide
  * https://www.transifex.com/
  * https://fedoraproject.org/wiki/L10N_Move_To_Zanata
  * http://zanata.org/
  * https://lists.fedoraproject.org/pipermail/trans/2014-October/011635.html


FUDCon Managua 2015
---

This year’s FUDCon — that’s Fedora User and Developer Conference — in
Latin America will in in Managua, Nicaragua next week. Organizer
Neville Cross tipped off 5tFTW with a few particularly interesting
notes:

- Robotics will rock FUDCon: Valentin Basel will present on a
  Fedora-based robot, and lead a session on building from parts.
  (See this video from FUDCon Panamá 2011.)

- Small computers will be big: the FUDCon team is bringing
  Raspberry Pi and Arduino boards to demonstrate.

- FUDCon on TV: The Fedora revolution *will* be televised!

  * http://roadtofudconlatam.org/robotic-will-rock-fudcon/
  * https://www.youtube.com/watch?v=S0Q9aMywkg8
  * http://roadtofudconlatam.org/small-computers-will-be-big-at-fudcon/
  * http://roadtofudconlatam.org/fudcon-and-fedora-on-tv/


New QA Automation framework goes live
-

As I’m sure everyone knows by now, the Fedora 21 cycle has been one of
our longest ever. We did this on purpose, and one of the primary
reasons was to give our Quality Assurance team time to work on tooling
and infrastructure rather than just cycling through tests over and
over. This has borne fruit, and our new QA automation framework
Taskotron has gone live, replacing AutoQA] for checks on package
updates.

Right now, the effect on end users and developers is very small, but
the change will enable many more important features in the near future,
including user-submitted tests to run automatically. This will
increasingly offload repetitive testing tasks so that humans time can
be focused where it’s most valuable, resulting in an even better Fedora
going forward.

  * https://fedoraproject.org/wiki/QA
  * http://fedoraproject.org/wiki/Taskotron
  * https://lists.fedoraproject.org/pipermail/test/2014-October/123327.html


Upgraded Retrace Server includes CentOS collaboration
-

This is another infrastructure thing which sounds kind like it might be
boring but which also will pay off in a better, more bug-free Fedora.
The Retrace/ABRT Server debugging tool which generates u

[Test-Announce] PSA: Don't install kernels with grubby 8.35-6.fc21 - they won't boot

[Adam Williamson]

Hi, folks. I've just noticed that grubby 8.35-6.fc21 made it to the
updates-testing repository. That build has a rather bad bug - when it
writes grub entries it will likely leave out the 'initrd16' (or just
'initrd', depending how old your system is) line, which will probably
mean the kernel won't boot.

So, best downgrade to 8.35-4.fc21 (from the 'fedora' repo) or upgrade to
8.35-7.fc21
(https://admin.fedoraproject.org/updates/FEDORA-2014-12932/grubby-8.35-7.fc21 , 
should hit updates-testing soon, you can get it from koji or with 'bodhi -D 
FEDORA-2014-12932' for now) before installing any kernels.

If you do wind up with a grubby 8.35-6 installed kernel which won't
boot, don't panic. You can manually add the required line by copying
from the line for an older kernel and just changing the filename
appropriately - it should come right under the 'linux' / 'linux16' line.

You can also just boot an older kernel, remove the newer kernel, upgrade
or downgrade grubby, and install the newer kernel again.

Sorry for the trouble!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Rahul Sundaram]

On Fri, Oct 17, 2014 at 2:44 PM, Tom Rivers wrote:

>
> I suppose I'm having trouble understanding that when you started this
> thread with:ble by default for many users.  dnf should enable this
> configuration by default as well"


Yes, that was true when I posted it.  As a result of this discussion,  the
situation was resolved.   So the discussion had already achieved its
purpose a while back.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Tom Rivers]

On 10/17/2014 14:24, Rahul Sundaram wrote:
Deltarpms is again enabled by default in Dnf a while back if you read 
the bug report.   Everything else has been an tangent, yes.


I suppose I'm having trouble understanding that when you started this 
thread with:


On 10/6/2014 04:41, Rahul Sundaram wrote:
One of the long standing features that were enabled by default in yum 
is support for delta rpms.  dnf developers have disabled this and I 
think this change deserves a broader discussion


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



You wrote "dnf developers have disabled this and I think this change 
deserves a broader discussion."  I went back and read your original post 
on the bug report you referenced and you said this:


"Since Fedora 12 or so (my blog post on this at 
http://mether.wordpress.com/2009/10/01/fedora-12-and-yum-presto-plugin/) 
deltarpm support has been available by default for many users.  dnf 
should enable this configuration by default as well"


I even went back and read your blog post.  I honestly don't understand.  
You say it needs to be enabled at first and now say that it's already 
enabled.  Color me confused, my friend.


Regardless, I don't think anyone, including you and I, wants to expend 
more bandwidth on tangential non-issues.  If you say this is handled, 
then that's fine by me.  I just wanted to be sure that everyone's 
bandwidth/processor issues were being adequately addressed.



Tom
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

civil discussion on fedora lists

[Matthew Miller]

On Fri, Oct 17, 2014 at 06:24:03PM +0200, Ralf Corsepius wrote:
> >Everyone: please remember the code of conduct here, and advance the
> >conversation in a productive way or take it elsewhere. Thank you.
> Well, then please explain, how you expect people to express
> fundamental disagreement with somebody's rationale, if one thinks a
> person's/party's rationale is irrational and non-applicable?

When you find yourself thinking that, it's probably time to step back and
pause for a bit. Our basic assumption should be that everyone collaborating
here is a rational person with intelligent input. You can take a fresh look
and re-read what is being said. If you feel like a point being made still
doesn't make sense, one option is to simply not respond. But if you do want
to continue, again, start from the assumption that the other person means
well.

You can say something like "I'm not sure I understand the point you are
making. Particularly, I don't see how __ follows. Can you explain
that in more depth?"

And conversely, if you feel like your position isn't being listened to, try
"I guess I'm not making myself very clear. Let me try to restate Does
this make more sense?"

You don't need to agree in the end, but you can get a better understanding,
and unlike a back-and-forth email jousting match, it can be helpful for
people reading along as well.

In both cases, if you've tried and it's not getting anywhere, consider
whether it's valuable to keep going. What will be accomplished? It might be
better to just move on to something else, or, if a big decision is at stake,
present your case in a different forum. (A concrete, reasoned proposal to
FESCo, for example.)

Constructive discussion even when we disagree is fundamental to the Fedora
approach — it is our Friends foundation. We do an awesome job of living up
to it in many aspects of the project, and it's time to try a lot harder on
the mailing lists, too.



-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Rahul Sundaram]

Hi

On Fri, Oct 17, 2014 at 2:17 PM, Tom Rivers  wrote:

>
> I would really like to know how you can equate that with my original
> point:  "Hey, maybe instead of throwing Presto under the bus.."


We aren't though.  Deltarpms is again enabled by default in Dnf a while
back if you read the bug report.   Everything else has been an tangent,
yes.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Tom Rivers]

On 10/17/2014 13:19, Rahul Sundaram wrote:
For the last time, my point is that:  "smart" and "stupid" is not 
determined by whether a user understands bandwidth/processor 
considerations.


I completely understand that not comprehending all of the complexities 
of bandwidth/processor considerations doesn't make one stupid.  I agree 
wholeheartedly with you.  However, you are going off on a tangent again 
that really has nothing to do with the point I was trying to make.


I would really like to know how you can equate that with my original 
point:  "Hey, maybe instead of throwing Presto under the bus we could 
discuss the option of giving users the choice to determine how much 
bandwidth/processor resources to throw at system updates instead."  At 
least then we wouldn't be throwing out something that significantly 
benefits those who DO pay a lot of money and DO have low bandwidth 
connections to the Internet.


It's a simple compromise: keep things configured as efficiently as 
possible while still allowing those who want to open up the throttle to 
do just that.



Tom
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Reindl Harald]

Am 17.10.2014 um 19:45 schrieb drago01:

1) deltarpms -> low bandwidth use but takes a while to apply the updates
2) no deltarpms -> high bandwidth use but faster updates application.

So now people suggest the user (or the distro) has to either choose 1) or 2) ...
What I am suggesting is adding a third option:

3) Use less bandwidth *and* apply updates fast (by fixing deltarpm).
So if we have 3) the choice between 1) and 2) does not make much sense


but we *do not have* option 3 without change fundamentally how things 
are implemented, so yes - it would be fine - but decisions are already 
made by what we *have now* by *disable* it as default


so just stop arguing in theory when the topic is about what is possible



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)

[Peter Robinson]

On Fri, Oct 17, 2014 at 5:59 PM, Richard W.M. Jones  wrote:
> On Thu, Oct 16, 2014 at 04:47:29PM +0200, Mathieu Bridon wrote:
>> >> [cduce]
>> >>cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 
>> >> 0:ebd368022fd2bc7b305a42902efa4c90
>>
>> This fails to rebuild:
>>   https://koji.fedoraproject.org/koji/taskinfo?taskID=7881630
>
> This was waiting for an upstream fix.  I have not checked the current
> status however.
>
>> >> [ocaml-pa-do]
>> >>ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 
>> >> 0:ebd368022fd2bc7b305a42902efa4c90
>>
>> This fails to rebuild:
>>   https://koji.fedoraproject.org/koji/taskinfo?taskID=7881760
>
> This package is supposed to be orphaned and/or retired.

It looks like the "fedpkg retire" was done in F-22, and not F-21.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[drago01]

On Fri, Oct 17, 2014 at 6:50 PM, Reindl Harald  wrote:
>
> Am 17.10.2014 um 17:07 schrieb drago01:
>
>> On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius 
>> wrote:
>>>
>>> On 10/17/2014 04:24 PM, Tom Rivers wrote:


 On 10/17/2014 10:05, drago01 wrote:
>
>
> Because it makes no sense and pushes it to the user. The os (i.e we)
> should handle that. In that case we should do both 1) have lower
> bandwith requirements (i.e use deltas) *and* 2) have fast installation
> of updates. Those two goals are not mutually exclusive. Its just the
> current implementation that is lacking. So instead of messing with
> questions during the installation we should just fix that.



 If the proper configuration can be determined automagically,
>>>
>>>
>>> Well a package installer can't have the knowledge which would be required
>>> to
>>> determine such a decision.
>>>
>>> E.g. though a user could be connected via a fast connection he may have a
>>> limited download contingent or could be charged at a high rate per
>>> download
>>> volume.
>>>
>>> I.e. I don't see a possibility but to leave the final decision to the
>>> user.
>>
>>
>> Did you even read my mail? The point is there shouldn't be a choice to
>> be made in the first place. Which makes "how to choose what" moot.
>
>
> so how do you imagine that decision happens later?
> the user deliberate makes the change?
>
> don't get me wrong but than you have no expierience about the ordinary
> users, they don't do anything, even not react if someone alerts them about a
> hacked mailaccount abused for spam-sending over days and after security
> warnings about Heartbleed and "please change your passwords" another one
> choses his first name as new secure password
>
> *that* is what you can expect from users and if you work in the IT and have
> a different expierience go out every morning and kiss them!

I have no idea what your mail has anything to do with that but I try
to explain it one more time.
Currently we have

1) deltarpms -> low bandwidth use but takes a while to apply the updates
2) no deltarpms -> high bandwidth use but faster updates application.

So now people suggest the user (or the distro) has to either choose 1) or 2) ...

What I am suggesting is adding a third option:

3) Use less bandwidth *and* apply updates fast (by fixing deltarpm).

So if we have 3) the choice between 1) and 2) does not make much sense.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

review swap : libmozjpeg

[Rahul Sundaram]

Hi

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

Let me know if anyone is interested.  Thanks!

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Rahul Sundaram]

Hi

On Fri, Oct 17, 2014 at 1:03 PM, Tom Rivers wrote:

>  If you deconstruct the sentence you quoted above, it boils down to the
> subject "users" and the predicate "aren't".  Therefore I said quite
> specifically that users ARE NOT "too stupid to understand
> bandwidth/processor considerations."  The inverse of that statement is the
> users ARE "smart enough to understand bandwidth/processor considerations."
>

For the last time, my point is that:  "smart" and "stupid" is not
determined by whether a user understands bandwidth/processor considerations.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: LLVM 3.5 rebase

[Sergio Pascual]

2014-10-17 16:00 GMT+02:00 Peter Robinson :

> On Fri, Oct 17, 2014 at 2:56 PM, Adam Jackson  wrote:
> > Yep, this again.  I'm just as thrilled as you are.  3.5 is necessary for
> > proper ppc64le support, as well as some minor radeonsi features in Mesa.
>
> And massively improved aarch64 support
>
> > One problem this time around appears to be python-llvmpy, which appears
> > to have decided that llvm 3.2/3.3 are the only versions it will support:
> >
> >
> https://github.com/llvmpy/llvmpy/commit/1e141931b874dd0bc3d8e9d801b949939430ad4e
> >
> > We're already shipping it built against 3.4, so that's truly charming.
> > I'm open to suggestions here.
>
> It doesn't look, with a basic repoquery test, that anything in the
> core distro needs python-llvmpy so my general feeling is to query
> upstream to see what their intentions are regarding support of newer
> releases and if they don't intend to keep up then just drop
> python-llvmpy at least for the time being unless the Fedora maintainer
> plans to fix it RSN.
>


I initially had intentions to package numba, and other pyhton goodies that
depend
on python-llvmpy, but I haven't worked on it on a very long time.

So I'm OK with retiring python-llvmpy if a patch doesn't appear soon.
in the tracking bug for 3.5
https://github.com/llvmpy/llvmpy/issues/106

Sergio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Tom Rivers]

On 10/17/2014 11:29, Rahul Sundaram wrote:

On Fri, Oct 17, 2014 at 11:09 AM, Tom Rivers wrote:

I didn't call them stupid - in fact I suggested just the opposite.
Go back and read what I wrote.


I did.  You said "My point is that users aren't too stupid to 
understand bandwidth/processor considerations".  I am just saying even 
if one doesn't understand these considerations, they aren't stupid.




If you deconstruct the sentence you quoted above, it boils down to the 
subject "users" and the predicate "aren't".  Therefore I said quite 
specifically that users ARE NOT "too stupid to understand 
bandwidth/processor considerations."  The inverse of that statement is 
the users ARE "smart enough to understand bandwidth/processor 
considerations."


More to the point, I went on to bolster the notion that Linux users are 
capable of understanding what's at play by saying this:  "These are 
Linux users after all."  That sentence is meant to infer that using 
Linux requires a decent amount of skill, something that again goes 
against the notion that I have somehow called them stupid.


Overall, the entire point of me advocating that users should be asked 
whether they want to endure large amounts of bandwidth/processor usage 
during system updates is predicated on the notion that they CAN answer 
the question intelligently.  It would make absolutely no sense to posit 
querying users if they couldn't respond intelligently.


Please don't persist in asserting I'm saying people are stupid.  It 
quite simply is not the case.



Tom
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Tom Rivers]

On 10/17/2014 12:11, Gerald B. Cox wrote:
I think you're setting up a false equivalency here.  There is a 
difference between the requirements of say an XBOX or Playstation user 
and that of updating a Fedora system.  If given the choice, most 
people will say "Yes, I have a high speed connection... turn it on, 
it's more better.  They won't give it a second thought.


My point was to say Linux users are usually more tech savvy than XBox 
and Playstation users.  If they say they have a high speed connection 
and they don't and that decision ends up costing them more money in ISP 
costs, then that's on them.  Still, that's really not the crux of what 
I've been trying to say.


We should be looking for ways to improve the performance of 
Presto...not just throwing it over the wall and assume that the 
network will handle it.


I completely agree.  My comments on this topic were meant solely to 
counter the notion that it must be completely abandoned, low 
bandwidth/high-cost bandwidth users be damned.  I was merely trying to 
illustrate that there may be a way to make everyone happy.



Tom
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)

[Richard W.M. Jones]

On Thu, Oct 16, 2014 at 04:47:29PM +0200, Mathieu Bridon wrote:
> >> [cduce]
> >>cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 
> >> 0:ebd368022fd2bc7b305a42902efa4c90
> 
> This fails to rebuild:
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=7881630

This was waiting for an upstream fix.  I have not checked the current
status however.

> >> [ocaml-pa-do]
> >>ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 
> >> 0:ebd368022fd2bc7b305a42902efa4c90
> 
> This fails to rebuild:
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=7881760

This package is supposed to be orphaned and/or retired.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Reindl Harald]

Am 17.10.2014 um 17:07 schrieb drago01:

On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius  wrote:

On 10/17/2014 04:24 PM, Tom Rivers wrote:


On 10/17/2014 10:05, drago01 wrote:


Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do both 1) have lower
bandwith requirements (i.e use deltas) *and* 2) have fast installation
of updates. Those two goals are not mutually exclusive. Its just the
current implementation that is lacking. So instead of messing with
questions during the installation we should just fix that.



If the proper configuration can be determined automagically,


Well a package installer can't have the knowledge which would be required to
determine such a decision.

E.g. though a user could be connected via a fast connection he may have a
limited download contingent or could be charged at a high rate per download
volume.

I.e. I don't see a possibility but to leave the final decision to the user.


Did you even read my mail? The point is there shouldn't be a choice to
be made in the first place. Which makes "how to choose what" moot.


so how do you imagine that decision happens later?
the user deliberate makes the change?

don't get me wrong but than you have no expierience about the ordinary 
users, they don't do anything, even not react if someone alerts them 
about a hacked mailaccount abused for spam-sending over days and after 
security warnings about Heartbleed and "please change your passwords" 
another one choses his first name as new secure password


*that* is what you can expect from users and if you work in the IT and 
have a different expierience go out every morning and kiss them!




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[drago01]

On Fri, Oct 17, 2014 at 5:52 PM, Ralf Corsepius  wrote:
> On 10/17/2014 05:07 PM, drago01 wrote:
>>
>> On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius 
>> wrote:
>>>
>>> On 10/17/2014 04:24 PM, Tom Rivers wrote:


 On 10/17/2014 10:05, drago01 wrote:
>
>
> Because it makes no sense and pushes it to the user. The os (i.e we)
> should handle that. In that case we should do both 1) have lower
> bandwith requirements (i.e use deltas) *and* 2) have fast installation
> of updates. Those two goals are not mutually exclusive. Its just the
> current implementation that is lacking. So instead of messing with
> questions during the installation we should just fix that.



 If the proper configuration can be determined automagically,
>>>
>>>
>>> Well a package installer can't have the knowledge which would be required
>>> to
>>> determine such a decision.
>>>
>>> E.g. though a user could be connected via a fast connection he may have a
>>> limited download contingent or could be charged at a high rate per
>>> download
>>> volume.
>>>
>>> I.e. I don't see a possibility but to leave the final decision to the
>>> user.
>>
>>
>> Did you even read my mail? The point is there shouldn't be a choice to
>> be made in the first place. Which makes "how to choose what" moot.
>
> Did you read my mail? I say, "no choice" is inapplicable, non-useful, naive
> non-sense.

You missed the point again. Making a choice only makes sense between
mutually exclusive choices. In case you can have both (given a better
implementation) the goal should be that.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Qt 5 Fedora 21 packages

[Erik Schilling]

On 16/10/14 16:27, Kevin Kofler wrote:
> Michael Schwendt wrote:
>> Some confusion here trying to use Fedora's Qt 5 packages, and it seems
>> they cannot be use quickly.
> 
> Depends on the build system you (or the upstream project you're packaging) 
> use:
> * CMake: just works
> * qmake: call qmake-qt5 and it'll find all the rest just fine
> * qbs: hopefully just works too, but not tested by me yet

Qbs needs an intial manual configuration at the moment. But the
auto-detection creates profiles for each qt version. So if you compile
you either have set a default profile before or specify the profile name
on the commandline.

Semi-OT: Qbs review request for fedora pending:
https://bugzilla.redhat.com/show_bug.cgi?id=979124
(I will try to update it to the latest release today)

Regards,
Erik
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Ralf Corsepius]

On 10/17/2014 06:00 PM, Matthew Miller wrote:

Everyone: please remember the code of conduct here, and advance the
conversation in a productive way or take it elsewhere. Thank you.


Well, then please explain, how you expect people to express fundamental 
disagreement with somebody's rationale, if one thinks a person's/party's 
rationale is irrational and non-applicable?


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Gerald B. Cox]

On Fri, Oct 17, 2014 at 7:24 AM, Tom Rivers  wrote:

> If the proper configuration can be determined automagically, then by all
> means just do it.  My point is that users aren't too stupid to understand
> bandwidth/processor considerations.  The configuration of how much
> bandwidth/processor time will be involved in one configuration versus
> another is not rocket science.  These are Linux users after all.  I
> completely reject the notion that there isn't a simple way to phrase the
> configuration of how the system is update. After all, setting up a secure
> wireless connection is much more difficult and these same users do it every
> day.


I think you're setting up a false equivalency here.  There is a difference
between the requirements of say an XBOX or Playstation user and that of
updating a Fedora system.  If given the choice, most people will say "Yes,
I have a high speed connection... turn it on, it's more better.  They won't
give it a second thought.

Consider the upstream consequences of that.  The bandwidth requirements of
repositories and mirrors will increase.  They will need to make the
decision of whether to upgrade their circuits or just let them become
saturated.  Ask a CIO what they think about circuit costs.  They always
want to either reduce or defer upgrades.  These things aren't free.

We should be looking for ways to improve the performance of Presto...not
just throwing it over the wall and assume that the network will handle it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Jon]

On Mon, Oct 6, 2014 at 8:07 AM, Stephen Gallagher  wrote:

[ . . . ]

>
> It would be nice to see if we can find ways to improve the performance
> of the deltarpm reconstruction instead. Much of the time is spent on
> compression/decompression tasks which *should* be massively parallel; we
> should be able to speed this up by taking advantage of additional cores
> (and hyperthreading) on the system, for example. Another option might be
> not to bother recompressing the RPMs but instead just install an
> uncompressed RPM (and possibly recompress it out of band if we needed to
> keep it in the cache).
>

export XZ_OPT=T0

If that were enabled in the environment the XZ compression phase would
be significantly faster.

-- 

-Jon Disnard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Matthew Miller]

Everyone: please remember the code of conduct here, and advance the
conversation in a productive way or take it elsewhere. Thank you.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Ralf Corsepius]

On 10/17/2014 05:07 PM, drago01 wrote:

On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius  wrote:

On 10/17/2014 04:24 PM, Tom Rivers wrote:


On 10/17/2014 10:05, drago01 wrote:


Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do both 1) have lower
bandwith requirements (i.e use deltas) *and* 2) have fast installation
of updates. Those two goals are not mutually exclusive. Its just the
current implementation that is lacking. So instead of messing with
questions during the installation we should just fix that.



If the proper configuration can be determined automagically,


Well a package installer can't have the knowledge which would be required to
determine such a decision.

E.g. though a user could be connected via a fast connection he may have a
limited download contingent or could be charged at a high rate per download
volume.

I.e. I don't see a possibility but to leave the final decision to the user.


Did you even read my mail? The point is there shouldn't be a choice to
be made in the first place. Which makes "how to choose what" moot.
Did you read my mail? I say, "no choice" is inapplicable, non-useful, 
naive non-sense.



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Review swap

[Jerry James]

On Fri, Oct 17, 2014 at 1:30 AM, Tim Lauridsen  wrote:
> I will take it later today, if nobody beat me to it :)

Thank you, Tim.  Let me know what I can do for you, whether it be a
review or something else.  Regards,
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Rahul Sundaram]

Hi

On Fri, Oct 17, 2014 at 11:09 AM, Tom Rivers  wrote:

I didn't call them stupid - in fact I suggested just the opposite. Go back
> and read what I wrote.
>

I did.  You said "My point is that users aren't too stupid to understand
bandwidth/processor considerations".  I am just saying even if one doesn't
understand these considerations, they aren't stupid.

>
> Pre-installation, post-installation, whatever is best.  I simply advocated
> asking a question because users are smart enough to handle it.
>

Well, it is a configuration option.   If one wants to tweak it, they can do
so.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Tom Rivers]

On 10/17/2014 10:43, Rahul Sundaram wrote:
Wile users might be able to handle such questions (I would avoid 
calling them stupid even otherwise)


I didn't call them stupid - in fact I suggested just the opposite. Go 
back and read what I wrote.


, it is contrary to the goals of the installer.  The Fedora installer 
is explicitly designed to do the absolute minimum necessary to get the 
installation up and running.   Everything else should be handled post 
installation.


Pre-installation, post-installation, whatever is best.  I simply 
advocated asking a question because users are smart enough to handle it.



Tom
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[poma]

On 06.10.2014 16:46, Jaroslav Reznik wrote:
> - Original Message -
>>
>>
>>
>> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
>>> On 6 October 2014 09:41, Rahul Sundaram  wrote:
 Hi

 One of the long standing features that were enabled by default in yum is
 support for delta rpms.  dnf developers have disabled this and I think
 this
 change deserves a broader discussion

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

>>>
>>> "I have an internet flatrate at 150 mbs, and downloading the full rpms
>>> is ALOT faster than the the work that the delta rpms requires."
>>>
>>> Wow. Good to see normal users are taken into account. The main
>>> argument from a distro point of view is reducing load on servers, but
>>> I don't know many people on 150Mbs either. Heck, I've just tested my
>>> work janet connection and that's <100Mbs in our office. At home 8Mbps
>>> is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit
>>> seconds, where the very slow transfer speed declines exponentially as
>>> the connection progresses.)
>>
>>
>> The deltarpms were meant to serve two purposes
>>
>> 1) (lesser) Address the needs of users in developing countries (where
>> Fedora is fairly popular) and bandwidth concerns are very considerable.
>> Many of these users have connections that are either metered or
>> extremely slow, so deltarpms provides a way to get the data to them more
>> economically. This of course can be handled with a non-default option,
>> so we can talk about making that more discoverable if we disable them by
>> default.
> 
> This is a good point but even in developing countries internet access is
> getting better and better. A few years ago installation DVD was the only
> way how to access Fedora repo. It's not requested anymore. But yeah, I do
> not live there.
> 

https://lists.fedoraproject.org/pipermail/test/2013-December/119412.html
Rejy, speak!


poma


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[drago01]

On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius  wrote:
> On 10/17/2014 04:24 PM, Tom Rivers wrote:
>>
>> On 10/17/2014 10:05, drago01 wrote:
>>>
>>> Because it makes no sense and pushes it to the user. The os (i.e we)
>>> should handle that. In that case we should do both 1) have lower
>>> bandwith requirements (i.e use deltas) *and* 2) have fast installation
>>> of updates. Those two goals are not mutually exclusive. Its just the
>>> current implementation that is lacking. So instead of messing with
>>> questions during the installation we should just fix that.
>>
>>
>> If the proper configuration can be determined automagically,
>
> Well a package installer can't have the knowledge which would be required to
> determine such a decision.
>
> E.g. though a user could be connected via a fast connection he may have a
> limited download contingent or could be charged at a high rate per download
> volume.
>
> I.e. I don't see a possibility but to leave the final decision to the user.

Did you even read my mail? The point is there shouldn't be a choice to
be made in the first place. Which makes "how to choose what" moot.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1154078] perl-Net-CUPS-0.61-18.fc22 FTBFS: The version of the Common Unix Printing System installed on your system is too old for this module to work properly.

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||p...@city-fan.org
   Fixed In Version||perl-Net-CUPS-0.61-19.fc22
 Resolution|--- |RAWHIDE
   Assignee|psab...@redhat.com  |p...@city-fan.org
Last Closed||2014-10-17 11:06:41



--- Comment #1 from Paul Howarth  ---
Build done: http://koji.fedoraproject.org/koji/taskinfo?taskID=7895757

The FTBFS was due to a version check in Makefile.PL that did not take into
account the major version number.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=aUWddIrOcp&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: No more deltarpms by default

[Ralf Corsepius]

On 10/17/2014 04:24 PM, Tom Rivers wrote:

On 10/17/2014 10:05, drago01 wrote:

Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do both 1) have lower
bandwith requirements (i.e use deltas) *and* 2) have fast installation
of updates. Those two goals are not mutually exclusive. Its just the
current implementation that is lacking. So instead of messing with
questions during the installation we should just fix that.


If the proper configuration can be determined automagically,
Well a package installer can't have the knowledge which would be 
required to determine such a decision.


E.g. though a user could be connected via a fast connection he may have 
a limited download contingent or could be charged at a high rate per 
download volume.


I.e. I don't see a possibility but to leave the final decision to the user.

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Rahul Sundaram]

Hi

On Fri, Oct 17, 2014 at 10:24 AM, Tom Rivers  wrote:

>
> If the proper configuration can be determined automagically, then by all
> means just do it.  My point is that users aren't too stupid to understand
> bandwidth/processor considerations.  The configuration of how much
> bandwidth/processor time will be involved in one configuration versus
> another is not rocket science.


Wile users might be able to handle such questions (I would avoid calling
them stupid even otherwise), it is contrary to the goals of the installer.
The Fedora installer is explicitly designed to do the absolute minimum
necessary to get the installation up and running.   Everything else should
be handled post installation.  The reason is that additional complexity
increases the chances of bugs in that codebase and installer issues cannot
be fixed post release easily and can delay the releases.  Pushing it to end
users is also often the easy way out and almost always the wrong solution.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: el6 builds failing

[Kevin Fenzi]

On Fri, 17 Oct 2014 16:17:39 +0200
Jan Chaloupka  wrote:

> Working now

FYI, this is usually due to an update landing in our repos and koji
hasn't done a regen on it yet so it's trying to get the old package
version. 

It should sort itself out on the next newrepo. 

kevin
--
> 
> On 10/17/2014 02:50 PM, Jan Chaloupka wrote:
> > Hi,
> >
> > an hour ago I was able to build
> > golang-github-mitchellh-mapstructure package for el6:
> > http://koji.fedoraproject.org/koji/packageinfo?packageID=19293
> >
> > Now it fails (some of my scratch builds):
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=7894679
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=7894716
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=7894880
> >
> > Trying to scratch build another package (already build in el6
> > again): http://koji.fedoraproject.org/koji/taskinfo?taskID=7894763
> >
> > With the same result = fail. The spec files has not changed.
> >
> > Error message from mock_output.log:
> > http://kojipkgs.fedoraproject.org/repo/rhel/rhel-x86_64-server-6/getPackage/libxml2-2.7.6-14.el6_5.2.x86_64.rpm:
> >  
> > [Errno 14] HTTP Error 404 - Not Found
> > Trying other mirror.
> >
> >
> > Error downloading packages:
> >   libxml2-2.7.6-14.el6_5.2.x86_64: failed to retrieve 
> > libxml2-2.7.6-14.el6_5.2.x86_64.rpm from build
> > error was [Errno 14] HTTP Error 404 - Not Found
> >
> > Is there some maintenance of el6 branch packages?  Or some server
> > is down?
> >
> > Thanks
> > Jan
> 



signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Tom Rivers]

On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we) 
should handle that. In that case we should do both 1) have lower 
bandwith requirements (i.e use deltas) *and* 2) have fast installation 
of updates. Those two goals are not mutually exclusive. Its just the 
current implementation that is lacking. So instead of messing with 
questions during the installation we should just fix that. 


If the proper configuration can be determined automagically, then by all 
means just do it.  My point is that users aren't too stupid to 
understand bandwidth/processor considerations.  The configuration of how 
much bandwidth/processor time will be involved in one configuration 
versus another is not rocket science.  These are Linux users after all.  
I completely reject the notion that there isn't a simple way to phrase 
the configuration of how the system is update. After all, setting up a 
secure wireless connection is much more difficult and these same users 
do it every day.



You customers would be *way* happier if stuff would just work without 
having them to mess with options until the correct configuration is 
found. Asking the user is the last resort when everything else fails. 


We configure the system for them whenever possible, so that's precisely 
what we do.  When it comes to a subjective decision about the way the 
system operates after we've implemented additional functionality, we 
always preserve the way the system works and offer an option to change 
it if they so desire.


By the way, considering we have a vast majority of our clients still 
with us and have kept them happy from the WANG 2200 days, through Xenix, 
SCO Unix, and on to Windows and Linux all these years from when we first 
opened our doors in 1985, I'd say we're doing a good job.



Tom
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: el6 builds failing

[Jan Chaloupka]

Working now

On 10/17/2014 02:50 PM, Jan Chaloupka wrote:

Hi,

an hour ago I was able to build golang-github-mitchellh-mapstructure 
package for el6:

http://koji.fedoraproject.org/koji/packageinfo?packageID=19293

Now it fails (some of my scratch builds):
http://koji.fedoraproject.org/koji/taskinfo?taskID=7894679
http://koji.fedoraproject.org/koji/taskinfo?taskID=7894716
http://koji.fedoraproject.org/koji/taskinfo?taskID=7894880

Trying to scratch build another package (already build in el6 again):
http://koji.fedoraproject.org/koji/taskinfo?taskID=7894763

With the same result = fail. The spec files has not changed.

Error message from mock_output.log:
http://kojipkgs.fedoraproject.org/repo/rhel/rhel-x86_64-server-6/getPackage/libxml2-2.7.6-14.el6_5.2.x86_64.rpm: 
[Errno 14] HTTP Error 404 - Not Found

Trying other mirror.


Error downloading packages:
  libxml2-2.7.6-14.el6_5.2.x86_64: failed to retrieve 
libxml2-2.7.6-14.el6_5.2.x86_64.rpm from build

error was [Errno 14] HTTP Error 404 - Not Found

Is there some maintenance of el6 branch packages?  Or some server is 
down?


Thanks
Jan


--
Jan Chaloupka
--
* Software Engineer  *
* ENG Base Operating Systems *
* Red Hat Czech, s. r. o.*
* UTC+1 (CET), jchaloup  *

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[drago01]

On Fri, Oct 17, 2014 at 2:53 PM, Tom Rivers  wrote:
> On 10/17/2014 05:09, Reindl Harald wrote:
>>
>> on a 56kbit modem you don't want to download the full RPMs and on a
>> 150Mbit line the download will always be faster than rebuild the RPM
>
>
> Perhaps this has already been suggested, but why not ask a question during
> the installation of the OS?

Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that.
In that case we should do both 1) have lower bandwith requirements
(i.e use deltas) *and*
2) have fast installation of updates.

Those two goals are not mutually exclusive. Its just the current
implementation that is lacking.
So instead of messing with questions during the installation we should
just fix that.


> Also, for what it's worth, for the past 25+ years I've been part of a
> development team that writes code for products like a physician practice
> management system and software that automates wholesale distributors.
> Anytime we introduce a new configuration option we try to offer as much
> choice as possible without taking functionality away from those that expect
> it to remain the way it is.  Choice is key in this process and every time
> we've embraced it our customers have been happiest.

You customers would be *way* happier if stuff would just work without
having them
to mess with options until the correct configuration is found.

Asking the user is the last resort when everything else fails.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: LLVM 3.5 rebase

[Peter Robinson]

On Fri, Oct 17, 2014 at 2:56 PM, Adam Jackson  wrote:
> Yep, this again.  I'm just as thrilled as you are.  3.5 is necessary for
> proper ppc64le support, as well as some minor radeonsi features in Mesa.

And massively improved aarch64 support

> One problem this time around appears to be python-llvmpy, which appears
> to have decided that llvm 3.2/3.3 are the only versions it will support:
>
> https://github.com/llvmpy/llvmpy/commit/1e141931b874dd0bc3d8e9d801b949939430ad4e
>
> We're already shipping it built against 3.4, so that's truly charming.
> I'm open to suggestions here.

It doesn't look, with a basic repoquery test, that anything in the
core distro needs python-llvmpy so my general feeling is to query
upstream to see what their intentions are regarding support of newer
releases and if they don't intend to keep up then just drop
python-llvmpy at least for the time being unless the Fedora maintainer
plans to fix it RSN.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

LLVM 3.5 rebase

[Adam Jackson]

Yep, this again.  I'm just as thrilled as you are.  3.5 is necessary for
proper ppc64le support, as well as some minor radeonsi features in Mesa.

One problem this time around appears to be python-llvmpy, which appears
to have decided that llvm 3.2/3.3 are the only versions it will support:

https://github.com/llvmpy/llvmpy/commit/1e141931b874dd0bc3d8e9d801b949939430ad4e

We're already shipping it built against 3.4, so that's truly charming.
I'm open to suggestions here.

- ajax

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Tom Rivers]

On 10/17/2014 05:09, Reindl Harald wrote:
on a 56kbit modem you don't want to download the full RPMs and on a 
150Mbit line the download will always be faster than rebuild the RPM


Perhaps this has already been suggested, but why not ask a question 
during the installation of the OS?  For example, during the installation 
process it may be possible to simply ask the user whether they want to 
set themselves up for full downloads or not. Based on the answer to the 
question, you can choose delta RPMS or not.  It is also possible to put 
something in the output of running an update that says to some effect, 
"If you want to limit bandwidth usage, adjust the settings here>."  Those are just two examples of how it may 
be possible to have the best of both worlds.  Anyone who has played 
video games over the past couple of decades knows that questions about 
one's Internet connection speed are the norm during 
installation/configuration so perhaps it makes sense to implement 
something similar in this instance.


Also, for what it's worth, for the past 25+ years I've been part of a 
development team that writes code for products like a physician practice 
management system and software that automates wholesale distributors.   
Anytime we introduce a new configuration option we try to offer as much 
choice as possible without taking functionality away from those that 
expect it to remain the way it is.  Choice is key in this process and 
every time we've embraced it our customers have been happiest.



Tom
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

el6 builds failing

[Jan Chaloupka]

Hi,

an hour ago I was able to build golang-github-mitchellh-mapstructure 
package for el6:

http://koji.fedoraproject.org/koji/packageinfo?packageID=19293

Now it fails (some of my scratch builds):
http://koji.fedoraproject.org/koji/taskinfo?taskID=7894679
http://koji.fedoraproject.org/koji/taskinfo?taskID=7894716
http://koji.fedoraproject.org/koji/taskinfo?taskID=7894880

Trying to scratch build another package (already build in el6 again):
http://koji.fedoraproject.org/koji/taskinfo?taskID=7894763

With the same result = fail. The spec files has not changed.

Error message from mock_output.log:
http://kojipkgs.fedoraproject.org/repo/rhel/rhel-x86_64-server-6/getPackage/libxml2-2.7.6-14.el6_5.2.x86_64.rpm: 
[Errno 14] HTTP Error 404 - Not Found

Trying other mirror.


Error downloading packages:
  libxml2-2.7.6-14.el6_5.2.x86_64: failed to retrieve 
libxml2-2.7.6-14.el6_5.2.x86_64.rpm from build

error was [Errno 14] HTTP Error 404 - Not Found

Is there some maintenance of el6 branch packages?  Or some server is down?

Thanks
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Base] Base Design WG agenda meeting 17 October 2014 15:00 UTC on #fedora-meeting

[Phil Knirsch]

Agenda:
 - Status buildrequires cleanup work (davids & nils!)
 - Open Floor

Thanks & regards, Phil

--
Philipp Knirsch  | Tel.:  +49-711-96437-470
Manager Core Services| Fax.:  +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch 
Wankelstrasse 5  | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rawhide report: 20141017 changes

[Fedora Rawhide Report]

Compose started at Fri Oct 17 05:15:02 UTC 2014
Broken deps for i386
--
[3Depict]
3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0
[Agda]
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[PyQuante]
PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 
0:1.1.6-2.fc21
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[audtty]
audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.i686 requires libjson.so.0
[cab]
cab-0.1.9-12.fc22.i686 requires cabal-dev
[condor]
condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so
[darcs]
darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
darcs-2.8.4-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
darcs-2.8.4-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-darcs-2.8.4-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-darcs-2.8.4-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-darcs-devel-2.8.4-5.fc22.i686 requires 
ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-darcs-devel-2.8.4-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[debconf]
debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2)
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[django-recaptcha]
django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
[dnssec-check]
dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14
dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-5.fc22.i686 requires libedelib.so
edelib-devel-2.1-5.fc22.i686 requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires 
hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7
[flush]
flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires 
libvala-0.24.so.0
[ghc-hjsmin]
ghc-hjsmin-0.1.4.7-3.fc22.i686 requires 
libHSoptparse-applicative-0.9.0-ghc7.6.3.so
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[gorm]
gorm-1.2.18-5.fc20.i686 requires libgnustep-gui.so.0.23
[hadoop]
hadoop-common-2.4.1-5.fc22.noarch requires commons-httpclient
[hledger]
ghc-hledger-0.19.3-5.fc22.i686 requires 
libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-hledger-0.19.3-5.fc22.i686 requires 
libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-hledger-0.19.3-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-hledger-devel-0.19.3-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
hledger-0.19.3-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
hledger-0.19.3-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[idris]
idris-0.9.9.1-3.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
idris-0.9.9.1-3.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
idris-0.9.9.1-3.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
idris-0.9.9.1-3.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[iwhd]
iwhd-1.6-11.fc22.i686 req

Re: No more deltarpms by default

[Andre Robatino]

Roberto Ragusa  robertoragusa.it> writes:

> Are compressed rpms completely impossible to diff efficiently by rsync?

In a word, yes. They're already compressed, so it's unlikely there would be
any matching blocks between old and new rpms for rsync to take advantage of.
(You can verify this by trying a local rsync between two different versions
of a large RPM.)


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: enhancing crypto policies for other languages than C

[Petr Pisar]

On 2014-10-16, Nikos Mavrogiannopoulos  wrote:
>  The currently proposed fedora maintainer instructions for the
> system-wide crypto policy are mainly for the C language. Could some
> experienced in other languages (e.g., ruby/python) propose some text for
> them?
>
> https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies
>
I descibed handling some Perl modules there.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F-21 Branched report: 20141017 changes

[Fedora Branched Report]

Compose started at Fri Oct 17 07:15:03 UTC 2014
Broken deps for armhfp
--
[PyQuante]
PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[audtty]
audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0
[avro]
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client
[cduce]
cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[cp2k]
cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[django-recaptcha]
django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-5.fc21.armv7hl requires libedelib.so
edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl 
requires hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires 
libtorrent-rasterbar.so.7
[flush]
flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7
[freesteam]
freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires 
libascend.so.1
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires 
libvala-0.24.so.0
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires 
libmetacity-private.so.0
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[libghemical]
libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3
libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1
[ltsp]
ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs
ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog
[meshmagick]
meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1
meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires 
libOgreMain.so.1.8.1
[monodevelop-vala]
monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0
[netdisco]
netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay)
[ocaml-pa-do]
ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[openslides]
openslides-1.3.1-3.fc21.noarch requires python-django < 0:1.5
[openstack-nova]
openstack-nova-compute-2014.1.2-1.fc21.noarch requires 
libvirt-daemon-xen
[openvas-client]
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6
[perl-RT-Authen-ExternalAuth]
perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3
[perl-RT-Extension-CommandByMail]
perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires 
perl(RT::Interface::Email)
[pipelight-selinux]
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight
[pootle]
pootle-2.1.6-8.fc21.noarch requires python-django14
[python-askbot-fedmsg]
python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot
[python-coffin]
python-coffin-0.3.7-3.fc21.noarch requires python-django14
[python-django-addons]
python-django-addons-0.6.6-2.fc21.noarch requires python-django14
[python-django-longerusername]
python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch 
requires python-django14
[rubygem-linecache19]
rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0
[rubygem-rubigen]
rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) < 
0:3.2.0
[rubygem-ruby-debug-base19]
rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires libru

Re: Can you help with making fonts awesome in Fedora 21?

[pravin....@gmail.com]

On 16 October 2014 15:14, Richard Hughes  wrote:

> If you maintain a font in Fedora, or are a provenpackager, I could
> really need your help this weekend. Basically, we want to implement
> AppStream metadata[1] for all the fonts we want to show in the
> software center. I've already made a good start, and now other people
> are starting to help as well, so I'm pretty sure we can get the
> majority finished for next week when we can submit a mega-update of
> updated fonts.
>
> I've started a shared spreadsheet here:
>
> https://docs.google.com/spreadsheets/d/1o2sPWF7PEe6BKnBeZUI23m51nfFHUMx61IRsdNDozig/edit#gid=0
> with what needs doing -- if you can help, please put your FAS name in
> the second column and get building. If any fonts are missing that you
> think belong in the software center please feel free to add them.
>
> It's really easy to add content for fonts. This is an example with
> multiple subpackages:
>
> http://pkgs.fedoraproject.org/cgit/silkscreen-fonts.git/commit/?id=32acdd5aa900ad732c023a73f7cd269a136f0957
> and fonts with only one package are even easier, e.g.
>
> http://pkgs.fedoraproject.org/cgit/oflb-brett-fonts.git/commit/?id=72ff3099f733949f9526221b47a63eff9b9b969d
>

Thanks for templates :)

Will be very helpful if you can add "how to test" information as well. i.e.
after local install package will appear in gnome-software something in bit
detail.

Regards,
Pravin Satpute
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Reindl Harald]

Am 17.10.2014 um 10:55 schrieb Roberto Ragusa:

On 10/06/2014 07:25 PM, Reindl Harald wrote:


the last discussions suggested that the result needs to be *identical* to the 
full RPM downloaded for not break signatures


Bizarre design; the signature should protect the content (uncompressed), not
the transport method (compressed)


no - it is a smart design besides the topic

the whole RPM package is signed and so you can verify the integrity 
without unpack it first - the history showed security flaws more than 
once just uncompress untrusted archives


https://www.google.at/search?q=attack+uncompress

and it is a smart design in general:
RPM don't need to know anything about deltarpms the way it is 
implemented just because RPM has not to deal with that and only faces 
the rebuilt package





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Reindl Harald]

Am 17.10.2014 um 10:49 schrieb Roberto Ragusa:

On 10/06/2014 07:57 PM, Reindl Harald wrote:


oh no - don't tie all together for reasons which did not destory the world over 
years - it is a damned good design that the part dealing with rpm packages 
don't need to know anything aboutt delta rpms because the normal packages are 
created before that step


And, going further on the same road... why don't we just find a way to
locally produce the original rpm by downloading through rsync?
Are compressed rpms completely impossible to diff efficiently by rsync?
(losing a bit of compression efficiency could be acceptable if rpms
became rsyncable)


to rsync something you need both files

no we (users) don't want the installed rpms stored forever as package to 
support this nor do we want anything else than RPM for package 
management/integrity, otherwise we (the users) could have chosen Debian


so please don't suggest technical background changes
if it ain't broken don't fix it
the switch exists and is useful

on a 56kbit modem you don't want to download the full RPMs and on a 
150Mbit line the download will always be faster than rebuild the RPM




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Roberto Ragusa]

On 10/06/2014 07:25 PM, Reindl Harald wrote:

> the last discussions suggested that the result needs to be *identical* to the 
> full RPM downloaded for not break signatures

Bizarre design; the signature should protect the content (uncompressed), not
the transport method (compressed).

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1153977] perl-Module-Path-0.15 is available

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
This is a bug-fix release suitable for F ≥ 21.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=gY6tuQnFuR&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: No more deltarpms by default

[Roberto Ragusa]

On 10/06/2014 07:57 PM, Reindl Harald wrote:
> 
> oh no - don't tie all together for reasons which did not destory the world 
> over years - it is a damned good design that the part dealing with rpm 
> packages don't need to know anything aboutt delta rpms because the normal 
> packages are created before that step
> 

And, going further on the same road... why don't we just find a way to
locally produce the original rpm by downloading through rsync?
Are compressed rpms completely impossible to diff efficiently by rsync?
(losing a bit of compression efficiency could be acceptable if rpms
became rsyncable)

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

[Ian Malone]

On 8 October 2014 12:35, Miloslav Trmač  wrote:

Been away for a week and come back to this nonsense. Why put so much
effort into arguing *against* having the right interpreter listed at
the top of a script. Seems pretty perverse to insist it should be
/bin/sh to maintain a conflation that's unique to RH.

> - Original Message -
>> On 6 October 2014 17:28, Miloslav Trmač  wrote:
>> > - Original Message -
>> >> > usage/requirement as well.  Bringing the benefits of supporting dash to…
>> >> > the satisfaction of pedantically using the POSIX /bin/sh path as
>> >> > frequently as possible?
>> >>
>> >> Also known as portability, compatibility
>> >
>> > Upstreams can be interested in cross-distro portability and compatibility.
>> > I don’t see much benefit for Fedora and Fedora’s users.
>> >
>>
>> Fedora is never upstream? Ever?
>
> The cases where Fedora is both a distribution and upstream happen, but in 
> these cases the difference doesn’t matter.  It’s the other cases, where the 
> roles are separate, that allow us to judge where the benefit, effort and 
> policy should be allocated.
>

Fedora is upstream for packaging and remixes. I tried to illustrate
that, but you've cut it from the quotes.

>> >> and transparency.
>> >
>> > Perhaps for changing the #! line; adding yet another programming language
>> > to the OS would make it more complex and thus _reduce_ transparency.
>>
>> Not another programming language, one that is already being used.
>
> If they have so different features and syntax that people writing scripts 
> need to be aware of this, they are different languages.  Or to put it the 
> other way, if they were the same languages then assumption that /bin/sh is 
> bash couldn’t matter.
>

And they're not the same, which is what the whole discussion about, so
it does matter.

>> >> Do we
>> >> encourage people to turn compiler warnings off?
>> >
>> > No, but most compiler warnings are useful _for increasing quality
>> > noticeable to users of Fedora_.  A warning about use of a bash construct
>> > when we are using bash doesn’t help us help users.
>>
>> Getting dependencies right isn't helpful?
>
> That’s what I said, and I think I said why.  If you think that changing 
> dependencies, when it would change neither behavior nor on-disk contents is 
> helpful, could you explain how?
>

Because they're the true dependencies.
Anyway I'm off to change gcc to a link to g++ on my systems because
they're close enough it shouldn't matter.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: enhancing crypto policies for other languages than C

[Petr Pisar]

On 2014-10-16, Nikos Mavrogiannopoulos  wrote:
>  The currently proposed fedora maintainer instructions for the
> system-wide crypto policy are mainly for the C language. Could some
> experienced in other languages (e.g., ruby/python) propose some text for
> them?
>
> https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies
>
Could you explain why replacing the cipher list is better than
removing the call?

Could you explain why the PROFILE= syntax is not documented in
ciphers(1) (referred from SSL_CTX_set_cipher_list(3)).

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Django-1.7 for Fedora 21

[Matthias Runge]

On 16/10/14 15:32, Stephen Gallagher wrote:

> There are no Django applications that are part of the install sets of
> any of the Products or Spins so far as I am aware, so the risk to the
> Project deliverable dates would be minimal. I'd suggest bringing it to
> FESCo for a more complete risk-analysis, but I'd argue that we'd be
> better off shipping python-django as 1.7 and also the python-django16
> package in Fedora 21.

I opened a ticket:

https://fedorahosted.org/fesco/ticket/1357

Matthias
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Review swap

[Tim Lauridsen]

> I am still in need of a reviewer.  Who can help me out?  I'm willing
> to review for you in exchange.
> --
>

I will take it later today, if nobody beat me to it :)

Tim
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct