Re: Proposal for integration tests infrastructure

[Tim Flink]

On Fri, 24 Oct 2014 14:10:23 -0600
Tim Flink  wrote:

> On Wednesday, October 22, 2014 01:43:57 PM you wrote:
> > Fedora lacks integration testing (unit testing done during build is
> > not enough). Taskotron will be able to fill some gaps in the future,
> > so maintainers will be able to set-up various tasks after their
> > component is built. But even before this works we can benefit from
> > having the tests already available (and run them manually if
> > needed).

Bah, I skipped right over this part.

How much interest is there among contributors in having a system for
storing tasks which wouldn't be run or recorded in a central system?
It's an intriguing idea that would have benefits if enough people used
it.

For the folks who would be interested - can you give examples of the
kinds of checks/tasks which you would run in such a setup?

Tim


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: Proposal for integration tests infrastructure

[Tim Flink]

On Wednesday, October 22, 2014 01:43:57 PM you wrote:
> Fedora lacks integration testing (unit testing done during build is
> not enough). Taskotron will be able to fill some gaps in the future,
> so maintainers will be able to set-up various tasks after their
> component is built. But even before this works we can benefit from
> having the tests already available (and run them manually if needed).
> 
> Hereby, I'd like to get ideas and figure out answers for how and where
> to keep the tests. A similar discussion already took place before,
> which I'd like to continue in:
> https://lists.fedoraproject.org/pipermail/devel/2014-January/193498.html
> 
> And some short discussion already took place here as well:
> https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000570
> .html

Instead of cross-posting to several lists, I'm going to just reply here 
instead of copying/fragmenting the conversation more.

> Some high level requirements:
> * tests will be written by maintainers or broader community, not a
> dedicated team
> * tests will be easy to run on anybody's computer (but might be
> potentially destructive; some secure environment will not be part of
> tests)
> * tests will be run automatically after related components get built
> (probably by Taskotron)

Just to make sure I understand what you're talking about here, you're
talking about mechanical checks, right? Something that is run by a
program and returns a limited-state result (ie PASS/FAIL/UNKNOWN)?

I think that you've hit on a lot of what we have in mind for Taskotron,
to be honest.

The tasks in Taskotron are run by libtaskotron and outside of things
like posting results or having access to secrets, do not require any of
the other infrastructure components that make up an entire Taskotron
deployment. The parts of Taskotron outside of libtaskotron are
responsible for scheduling, reporting and managing the execution of
tasks.

Anyone can install libtaskotron, clone a task's git repository and
start running tasks. If this doesn't work in all reasonable cases, then
we have violated one of the core design principles of Taskotron and it
will be fixed.

By designing for git-repo-contained tasks, a set of people with proper 
permissions can change tasks in pretty much the same way that a group
of developers change source code.

> Where to keep tests?
> a/ in current dist-git for related components (problem with sharing
> parts of code, problem where to keep tests related for more
> components) b/ in separate git with similar functionality as dist-git
> (needs new infrastructure, components are not directly connected with
> tests, won't make mess in current dist-git)
> c/ in current dist-git but as ordinary components (no new
> infrastructure needed but components are not directly connected with
> tests)

I'm leaning somewhat towards a somewhat separate dist-git-ish solution
right now. By keeping it separate, we can't make a mess of the package
ACLs, don't need to worry about giving non-packagers access to the
dist-git repos and aren't adding a bunch of stuff to an already working
system.

I'd also like to see the tasks be easily accessible from checked out
dist-git repos. I'm not sure that submodules or subtrees are good
answers here but having the tasks appear as a subdirectory of dist-git
repos sounds like a good way to integrate things to me.

> How to deliver tests?
> a/ just use them directly from git (we need to keep some metadata for
> dependencies anyway)
> b/ package them as RPMs (we can keep metadata there; e.g. Taskotron
> will run only tests that have "Provides: ci-tests(mariadb)" after
> mariadb is built; we also might automate packaging tests to RPMs)

I'm of the opinion that keeping stuff in plain git is the best choice.
For this particular use case, I'm not aware of any advantages from
packaging checks as long as we're smart about updating git repos prior
to task execution and it's additional overhead - especially if we want
to have non-packagers involved in task creation and maintenance.

> Structure for tests?
> a/ similar to what components use (branches for Fedora versions)
> b/ only one branch
> Test maintainers should be allowed to behave the same as package
> maintainers do -- one likes keeping branches the same and uses "%if
> %fedora" macros, someone else likes specs clean and rather maintain
> more different branches) -- we won't find one structure that would
> fit all, so allowing both ways seems better.

I think that restricting stuff to a single branch is going to be too 
complicated and messy. The method of branching that is used in dist-git
seems to be pretty well accepted and IMHO it's a logical approach to
allowing per-version check differences without introducing a bunch of
mess and complexity to the tasks to be run.

> Which framework to use?
> People have no time to learn new things, so we should let them to
> write the tests in any language and just define some conventions how
> to run them.

Speci

[Test-Announce] Fedora 21 Beta to slip by one week

[Jaroslav Reznik]

Today at Go/No-Go meeting it was decided to slip Fedora 21 Beta release
by one week due to unresolved blocker bugs [1]. More details in meeting
minutes [2].

As a result, ALL MAJOR MILESTONES, and their dependent tasks, will be
pushed out by one week [3].

The next Go/No-Go meeting is on Thursday, Oct 30, 17:00 UTC at
#fedora-meeting-2 channel on FreeNode.

Jaroslav

[1] http://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist
[2] 
http://meetbot.fedoraproject.org/fedora-meeting-2/2014-10-24/f21_beta_gono-go_meeting.2014-10-24-17.01.html
[3] https://fedoraproject.org/wiki/Releases/21/Schedule
___
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: U2F and a review swap?

[Erinn Looney-Triggs]

On Friday, October 24, 2014 10:07:09 AM Andrew Lutomirski wrote:
> Has Fedora considered supporting U2F for its infrastructure.  IMO it's
> *much* nicer than standard Yubikeys.
> 
> On a related note, I will gladly swap a review for libu2f-host:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1155826
> 
> --Andy


This is just my two cents, and I have nothing to do with Fedora 
infrastructure, but given that u2f is only supported via chrome/chromium for 
right now I would venture a guess that it probably isn't the right solution. 
When it gets baked into Firefox etc. I would say that would be a much better 
time for it.

-Erinn

signature.asc
Description: This is a digitally signed message part.
-- 
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: Proposal for integration tests infrastructure

[John Dulaney]

Some thoughts:

>> Where to keep tests? a/ in current dist-git for related components
>> (problem with sharing parts of code, problem where to keep tests
>> related for more components) b/ in separate git with similar
>> functionality as dist-git (needs new infrastructure, components are
>> not directly connected with tests, won't make mess in current
>> dist-git) c/ in current dist-git but as ordinary components (no new
>> infrastructure needed but components are not directly connected
>> with tests)
>>
>> How to deliver tests? a/ just use them directly from git (we need
>> to keep some metadata for dependencies anyway) b/ package them as
>> RPMs (we can keep metadata there; e.g. Taskotron will run only
>> tests that have "Provides: ci-tests(mariadb)" after mariadb is
>> built; we also might automate packaging tests to RPMs)

To answer both of these, the plan is to keep taskotron tasks in their own
git repo; currently this is at (0).

To run the tasks, taskotron sets up a disposable task client and then git
clones the task to be run.  This solves the issue of delivery and allows
a continuous integration-like solution.

>> Structure for tests? a/ similar to what components use (branches
>> for Fedora versions) b/ only one branch Test maintainers should be
>> allowed to behave the same as package maintainers do -- one likes
>> keeping branches the same and uses "%if %fedora" macros, someone
>> else likes specs clean and rather maintain more different branches)
>> -- we won't find one structure that would fit all, so allowing both
>> ways seems better.

This is something we'll need to figure out, but, I suspect git branches will
be involved.

>> Which framework to use? People have no time to learn new things, so
>> we should let them to write the tests in any language and just
>> define some conventions how to run them.

You'll need to at least define the task in a yaml file, and output will need to
be TAP.  The example task is at (1).


> TAP (Test Anything Protocol) FTW. It really makes sense when you're
> trying to combine tests from multiple different languages, testing
> frameworks, etc.
>
> Stef
>

Indeed, which is why we settled on it.



John.



(0)  https://bitbucket.org/fedoraqa

(1)  https://bitbucket.org/fedoraqa/task-rpmlint
  
-- 
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: dnf vs yum

[Rahul Sundaram]

Hi

Of course, dnf repoquery for packages that depend on yum/yum-utils yielded
quite a few more packages.  So I have filed RFE's against all of them and
added them to the tracker and fixed the wiki references etc just to
complete this process

https://bugzilla.redhat.com/showdependencytree.cgi?id=1156491

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

It is possible, even likely that some packages just assumed yum/yum-utils
would always be there and didn't add an explicitly dependency.  Since some
base tools including mock still depend on yum by default in rawhide, we
wouldn't know about those hidden issues till those are ported
over/dependency on yum is dropped.

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

[PkgDB] limb updated perl-CGI-FormBuilder

[pkgdb]

user: limb created branch epel7 on package perl-CGI-FormBuilder

To make changes to this package see:
https://admin.fedoraproject.org/pkgdb/package/perl-CGI-FormBuilder
--
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

U2F and a review swap?

[Andrew Lutomirski]

Has Fedora considered supporting U2F for its infrastructure.  IMO it's
*much* nicer than standard Yubikeys.

On a related note, I will gladly swap a review for libu2f-host:

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

--Andy
-- 
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: Five Conferences in Fedora This Week! FUDCon Managua, LinuxCon EU, SeaGL, and upcoming FOSDEM and DevConf.cz (2014-10-24)

[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 24th, 2014:

This is a week with a lot of conference activity — today we have an
all-event 5tFTW.


FUDCon LATAM in Managua, Nicaragua
--

First up: our Latin American FUDCon is going on right now (yesterday,
today, and tomorrow). We already have some summary posts from Dennis
Gilmore (in English; and he’s planning to post more soon) and Luis
Bazan (in Spanish). More on this event next week!

  * https://fedoraproject.org/wiki/FUDCon:Managua_2014
  * https://ausil.us/wordpress/?p=79
  * http://lokomurdok.blogspot.com/2014/10/inicia-fudcon-managua-2014.html


LinuxCon EU 2014


Jiří Eischmann reports on Fedora’s presence at the Linux Foundation’s
LinuxCon Europe conference in Düsseldorf, Germany.

A quick quote:

> People were more interested in Fedora Server which is different from
> most events where people are mostly interested in Workstation, but
> it’s not surprising considering the audience. It really helps to
> advertise a specialized product because you can clearly say: if
> you’re interested in server OSes, this is what we have for you and it
> has these interesting features. That’s why I’m glad we have Fedora
> Server. From the marketing point of view, it’s much more appealing to
> have a solution (server product) than just a lego to build it. Quite
> a few people were interested in Fedora as a future of enterprise
> Linux because what they work with and care about is Red Hat
> Enterprise Linux.

… but I think the whole thing is interesting, especially if you’re
interested in how we promote Fedora and interact with the community at
this type of conference.

  * http://eischmann.wordpress.com/2014/10/22/fedora-linuxcon-europe-2014/


Seattle GNU/Linux Conference


Another one going on right now — SeaGL in Seattle, Washington. (From
the logo, looks like that’s “seagull” — cute!). Fedora hacker David Gay
(a.k.a. “oddshocks”, and one of the people behind Fedora Badges and
other projects) is speaking on Free Infrastructure later this
afternoon, sharing his experiences and answering questions. Attendance
is free, by the way, so if you’re in Seattle, it’s the obvious thing to
do with your weekend!

  * http://seagl.org/
  * https://badges.fedoraproject.org/
  * http://lanyrd.com/2014/seagl/sdfgfm/


FOSDEM 2015 Call for Papers
---

FOSDEM (Free and Open Source Software Developers’ European Meeting) is
a gigantic community-organized and oriented conference which takes
place in Brussels every year at the end of January / beginning of
February. Right now, 2015’s conference is in its planning phase, with a
“call for papers” (that is, open submission for talks) open now for
both developer rooms and lightning talks and booths.

Of particular interest to Fedora is the Distribution Devroom:

> The purpose of the distributions devroom is to offer a forum for all
> people interested in distribution issues to meet and collaborate on
> improving the distribution ecosystem. What are the upcoming
> challenges facing the distribution space? How can distribution
> maintainers collaborate better to solve cross-distribution issues?
> What are interesting developments helping distribution developers to
> excel in the distribution space?

If you have a Fedora-related idea, let’s talk about it and get to
planning! (The Fedora Ambassadors mailing list is a good place to
start.)

  * https://fosdem.org/2015/news/2014-09-30-accepted-devrooms/
  * https://fosdem.org/2015/news/2014-09-19-call-for-participation-part-two/
  * https://lists.fosdem.org/pipermail/fosdem/2014-October/002047.html
  * https://lists.fedoraproject.org/mailman/listinfo/ambassadors


DevConf.cz 2015 Call for Papers
---

Red Hat sponsors a conference in Brno, Czech Republic the week after
FOSDEM, and that too has an open Call for Papers. Continuing on the
success of last February’s event, the next DevConf.cz will feature an
entire Fedora Day — Jiří has details on his blog. Last year, there were
over 1000 attendees, and this year, the venue has been moved to
accommodate even more!

  * http://devconf.cz/content/call-participation-open
  * http://eischmann.wordpress.com/2014/10/23/fedora-day-devconf-cz-2015/

-- 
Matthew Millermat...@mattdm.org 
Fedora Project Leader  mat...@fedoraproject.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: dnf vs yum

[Tim Lauridsen]

>
> > "Drop" as in "use yum for that, but dnf for the new versions"? That
> > sounds reasonable.
>
> Well reality is f-r is mostly for checking *current* Fedora
> guidelines that in some cases apply only to rawhide. If someone is
> running f-r on a system from 4 years ago to verify current packaging
> guidelines I'd question their knowledge of the guidelines :-)
>
> It's not impossible to do...I just wonder about cost/value proposition
> of keeping the support and spending even more time on it.
>
>
f-r should proberly be working in current Fedora releases, F20, F21 &
Rawhide, some kind of compability wrapper could be need, some f-r check
code is the same and the wrapper can support yum-utils and dnf 5.x (F20)
and 6.x API (F21 & F22) (The cache setup is different)

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

Re: dnf vs yum

[Stanislav Ochotnicky]

On Fri 24 Oct 2014 05:35:00 PM CEST Matthew Miller wrote:
> On Fri, Oct 24, 2014 at 04:56:20PM +0200, Stanislav Ochotnicky wrote:
>> Thought we should really switch to actually use dnf api instead. Things
>> get complicated for us when we want to support EL6 then...Maybe we should
>> just drop EPEL6 support.
>
> "Drop" as in "use yum for that, but dnf for the new versions"? That
> sounds reasonable.

Well reality is f-r is mostly for checking *current* Fedora
guidelines that in some cases apply only to rawhide. If someone is
running f-r on a system from 4 years ago to verify current packaging
guidelines I'd question their knowledge of the guidelines :-)

It's not impossible to do...I just wonder about cost/value proposition
of keeping the support and spending even more time on it.

--
Stanislav Ochotnicky 
Business System Analyst, Hosted and Shared Services

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
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: dnf vs yum

[Matthew Miller]

On Fri, Oct 24, 2014 at 04:56:20PM +0200, Stanislav Ochotnicky wrote:
> Thought we should really switch to actually use dnf api instead. Things
> get complicated for us when we want to support EL6 then...Maybe we should
> just drop EPEL6 support.

"Drop" as in "use yum for that, but dnf for the new versions"? That
sounds reasonable.

-- 
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: dnf vs yum

[Rahul Sundaram]

On Fri, Oct 24, 2014 at 10:00 AM, Stanislav Ochotnicky  wrote:

> On Fri 24 Oct 2014 02:26:37 PM CEST Rahul Sundaram wrote:
> >
> > Bodhi-client,  fedpkg, python-meh, libreport-python, yum-utils depends on
> > yum and yum-utils itself is a dependency for fedora-review, lpf and
> > mock.
>
> FWIW fedora-review only requires yum-utils and that's only for
> repoquery
>

Right.   I have filed the following RFE's

Fedora-review
https://bugzilla.redhat.com/show_bug.cgi?id=1156479

Python-meh

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

libreport-python

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

Bodhi-client

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

lpf

https://bugzilla.rpmfusion.org/show_bug.cgi?id=3391

Tracker bug

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

Hope that helps

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: dnf vs yum

[Stanislav Ochotnicky]

On Fri 24 Oct 2014 04:27:37 PM CEST Tim Lauridsen wrote:
> On Fri Oct 24 2014 at 4:01:20 PM Stanislav Ochotnicky <
> sochotni...@redhat.com> wrote:
>
>> On Fri 24 Oct 2014 02:26:37 PM CEST Rahul Sundaram wrote:
>>
>> > Hi
>> >
>> > On Fri, Oct 24, 2014 at 7:58 AM, Vít Ondruch wrote:
>> >
>> >>
>> >> Yes, switch the defaults ASAP. Thanks
>> >>
>> >
>> > FWIW,   there is still considerable work left is switching over to dnf
>> > completely.
>> >
>> > Filtering out some minor details (based on my system),
>> >
>> > Bodhi-client,  fedpkg, python-meh, libreport-python, yum-utils depends on
>> > yum and yum-utils itself is a dependency for fedora-review, lpf and
>> > mock.
>>
>> FWIW fedora-review only requires yum-utils and that's only for
>> repoquery. Based on a quick glance at dnf repoquery module there are a
>> few things missing that we are using with repoquery:
>>  * -C (use cache only)
>>
>
> dnf repoquery can use standard dnf cmd option, so -C/--cacheonly can be
> used.

Ah, right my bad. But really...this will likely not be needed.

>
>>  * --resolve (resolves to packages that provide required symbols)
>>
>
> Not implemented in dnf repoquery yet, please open an RFE against
> dnf-plugins-core, with your usecase and I will look into it.


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

Thought we should really switch to actually use dnf api instead. Things
get complicated for us when we want to support EL6 then...Maybe we should
just drop EPEL6 support.

>> We also run 'yum makecache' so before all actual repoquery commands (that's
>> why we then use cache). This might not be needed with dnf since it
>> usually caches yum metadata and doesn't redownload on every query.
>>
>> Dnf repoquery also behaves differently than yum-utils repoquery. For
>> example:
>> $ repoquery --requires python
>> libc.so.6(GLIBC_2.0)
>> libdl.so.2
>> libm.so.6
>> libpthread.so.0
>> libpython2.7.so.1.0
>> libutil.so.1
>> python-libs(x86-32) = 2.7.5-14.fc20
>> rtld(GNU_HASH)
>> libc.so.6(GLIBC_2.2.5)(64bit)
>> libdl.so.2()(64bit)
>> libm.so.6()(64bit)
>> libpthread.so.0()(64bit)
>> libpython2.7.so.1.0()(64bit)
>> libutil.so.1()(64bit)
>> python-libs(x86-64) = 2.7.5-14.fc20
>> rtld(GNU_HASH)
>>
>> $ dnf repoquery --requires python
>> rtld(GNU_HASH)
>> libm.so.6
>> libpthread.so.0
>> libdl.so.2
>> libutil.so.1
>> libpython2.7.so.1.0
>> libc.so.6(GLIBC_2.0)
>> python-libs(x86-32) = 2.7.5-9.fc20
>> rtld(GNU_HASH)
>> libm.so.6()(64bit)
>> libpthread.so.0()(64bit)
>> libdl.so.2()(64bit)
>> libc.so.6(GLIBC_2.2.5)(64bit)
>> libpython2.7.so.1.0()(64bit)
>> libutil.so.1()(64bit)
>> python-libs(x86-64) = 2.7.5-9.fc20
>> rtld(GNU_HASH)
>> libm.so.6
>> libpthread.so.0
>> libdl.so.2
>> libutil.so.1
>> libpython2.7.so.1.0
>> libc.so.6(GLIBC_2.0)
>> python-libs(x86-32) = 2.7.5-14.fc20
>> rtld(GNU_HASH)
>> libm.so.6()(64bit)
>> libpthread.so.0()(64bit)
>> libdl.so.2()(64bit)
>> libc.so.6(GLIBC_2.2.5)(64bit)
>> libutil.so.1()(64bit)
>> libpython2.7.so.1.0()(64bit)
>> python-libs(x86-64) = 2.7.5-14.fc20
>>
>>
> Can reproduce this repoquery and dnf repoquery show the same for me
>
> https://docs.google.com/spreadsheets/d/1WwlO3Is0psbBuJrIY_fVOjWeF5Pi5PI5Ekiy1raUjbs/edit?usp=sharing

For me 2.7.5-9.fc20 is from fedora/20 repo and python-2.7.5-14.fc20 is
from updates/20. F21 doesn't have updates so maybe that's the reason why
your results look OK?

--
Stanislav Ochotnicky 
Business System Analyst, Hosted and Shared Services

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
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: dnf vs yum

[Tim Lauridsen]

On Fri Oct 24 2014 at 4:01:20 PM Stanislav Ochotnicky <
sochotni...@redhat.com> wrote:

> On Fri 24 Oct 2014 02:26:37 PM CEST Rahul Sundaram wrote:
>
> > Hi
> >
> > On Fri, Oct 24, 2014 at 7:58 AM, Vít Ondruch wrote:
> >
> >>
> >> Yes, switch the defaults ASAP. Thanks
> >>
> >
> > FWIW,   there is still considerable work left is switching over to dnf
> > completely.
> >
> > Filtering out some minor details (based on my system),
> >
> > Bodhi-client,  fedpkg, python-meh, libreport-python, yum-utils depends on
> > yum and yum-utils itself is a dependency for fedora-review, lpf and
> > mock.
>
> FWIW fedora-review only requires yum-utils and that's only for
> repoquery. Based on a quick glance at dnf repoquery module there are a
> few things missing that we are using with repoquery:
>  * -C (use cache only)
>

dnf repoquery can use standard dnf cmd option, so -C/--cacheonly can be
used.


>  * --resolve (resolves to packages that provide required symbols)
>

Not implemented in dnf repoquery yet, please open an RFE against
dnf-plugins-core, with your usecase and I will look into it.


> We also run 'yum makecache' so before all actual repoquery commands (that's
> why we then use cache). This might not be needed with dnf since it
> usually caches yum metadata and doesn't redownload on every query.
>
> Dnf repoquery also behaves differently than yum-utils repoquery. For
> example:
> $ repoquery --requires python
> libc.so.6(GLIBC_2.0)
> libdl.so.2
> libm.so.6
> libpthread.so.0
> libpython2.7.so.1.0
> libutil.so.1
> python-libs(x86-32) = 2.7.5-14.fc20
> rtld(GNU_HASH)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libdl.so.2()(64bit)
> libm.so.6()(64bit)
> libpthread.so.0()(64bit)
> libpython2.7.so.1.0()(64bit)
> libutil.so.1()(64bit)
> python-libs(x86-64) = 2.7.5-14.fc20
> rtld(GNU_HASH)
>
> $ dnf repoquery --requires python
> rtld(GNU_HASH)
> libm.so.6
> libpthread.so.0
> libdl.so.2
> libutil.so.1
> libpython2.7.so.1.0
> libc.so.6(GLIBC_2.0)
> python-libs(x86-32) = 2.7.5-9.fc20
> rtld(GNU_HASH)
> libm.so.6()(64bit)
> libpthread.so.0()(64bit)
> libdl.so.2()(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libpython2.7.so.1.0()(64bit)
> libutil.so.1()(64bit)
> python-libs(x86-64) = 2.7.5-9.fc20
> rtld(GNU_HASH)
> libm.so.6
> libpthread.so.0
> libdl.so.2
> libutil.so.1
> libpython2.7.so.1.0
> libc.so.6(GLIBC_2.0)
> python-libs(x86-32) = 2.7.5-14.fc20
> rtld(GNU_HASH)
> libm.so.6()(64bit)
> libpthread.so.0()(64bit)
> libdl.so.2()(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libutil.so.1()(64bit)
> libpython2.7.so.1.0()(64bit)
> python-libs(x86-64) = 2.7.5-14.fc20
>
>
Can reproduce this repoquery and dnf repoquery show the same for me

https://docs.google.com/spreadsheets/d/1WwlO3Is0psbBuJrIY_fVOjWeF5Pi5PI5Ekiy1raUjbs/edit?usp=sharing

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

Re: dnf vs yum

[Stanislav Ochotnicky]

On Fri 24 Oct 2014 02:26:37 PM CEST Rahul Sundaram wrote:

> Hi
>
> On Fri, Oct 24, 2014 at 7:58 AM, Vít Ondruch wrote:
>
>>
>> Yes, switch the defaults ASAP. Thanks
>>
>
> FWIW,   there is still considerable work left is switching over to dnf
> completely.
>
> Filtering out some minor details (based on my system),
>
> Bodhi-client,  fedpkg, python-meh, libreport-python, yum-utils depends on
> yum and yum-utils itself is a dependency for fedora-review, lpf and
> mock.

FWIW fedora-review only requires yum-utils and that's only for
repoquery. Based on a quick glance at dnf repoquery module there are a
few things missing that we are using with repoquery:
 * -C (use cache only)
 * --resolve (resolves to packages that provide required symbols)

We also run 'yum makecache' so before all actual repoquery commands (that's
why we then use cache). This might not be needed with dnf since it
usually caches yum metadata and doesn't redownload on every query.

Dnf repoquery also behaves differently than yum-utils repoquery. For
example:
$ repoquery --requires python
libc.so.6(GLIBC_2.0)
libdl.so.2
libm.so.6
libpthread.so.0
libpython2.7.so.1.0
libutil.so.1
python-libs(x86-32) = 2.7.5-14.fc20
rtld(GNU_HASH)
libc.so.6(GLIBC_2.2.5)(64bit)
libdl.so.2()(64bit)
libm.so.6()(64bit)
libpthread.so.0()(64bit)
libpython2.7.so.1.0()(64bit)
libutil.so.1()(64bit)
python-libs(x86-64) = 2.7.5-14.fc20
rtld(GNU_HASH)

$ dnf repoquery --requires python
rtld(GNU_HASH)
libm.so.6
libpthread.so.0
libdl.so.2
libutil.so.1
libpython2.7.so.1.0
libc.so.6(GLIBC_2.0)
python-libs(x86-32) = 2.7.5-9.fc20
rtld(GNU_HASH)
libm.so.6()(64bit)
libpthread.so.0()(64bit)
libdl.so.2()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libpython2.7.so.1.0()(64bit)
libutil.so.1()(64bit)
python-libs(x86-64) = 2.7.5-9.fc20
rtld(GNU_HASH)
libm.so.6
libpthread.so.0
libdl.so.2
libutil.so.1
libpython2.7.so.1.0
libc.so.6(GLIBC_2.0)
python-libs(x86-32) = 2.7.5-14.fc20
rtld(GNU_HASH)
libm.so.6()(64bit)
libpthread.so.0()(64bit)
libdl.so.2()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libutil.so.1()(64bit)
libpython2.7.so.1.0()(64bit)
python-libs(x86-64) = 2.7.5-14.fc20

No idea why it's this way though.

--
Stanislav Ochotnicky 
Business System Analyst, Hosted and Shared Services

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
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: Improving the offline updates user experience

[Miroslav Suchý]

On 10/24/2014 12:59 PM, Richard Hughes wrote:

853 must be close to
every package on your box...


Nope.
$ rpm -qa |wc -l
4337

--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
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: dnf vs yum

[Miroslav Suchý]

On 10/24/2014 01:33 PM, Rahul Sundaram wrote:

That would be a good reason to switch the default in Rawhide at this stage.


No. This is the *first* release with explicit DNF support.
Until now it was tested only by those who run mock directly from git checkout 
(that is maybe 3-5 people).
Now it is distributed as rpm (in rawhide, and for older releases in Copr) and is tested by those willing to modify 
site-defaults.cfg. And hopefully by those built application, which use mock.


I will swap the defaults, once I will be confident that the new feature works flawlessly. But that is not now. I really 
do not want to break Koji.


--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
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: dnf vs yum

[Rahul Sundaram]

Hi

On Fri, Oct 24, 2014 at 7:58 AM, Vít Ondruch wrote:

>
> Yes, switch the defaults ASAP. Thanks
>

FWIW,   there is still considerable work left is switching over to dnf
completely.

Filtering out some minor details (based on my system),

Bodhi-client,  fedpkg, python-meh, libreport-python, yum-utils depends on
yum and yum-utils itself is a dependency for fedora-review, lpf and
mock.I am only aware of the recent mock and yumex efforts.  I have no
idea if the rest of the projects are being prodded to switch over and
whether this is all being tracked somewhere.  If not, it should be.

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: Request new package

[Reindl Harald]

Am 24.10.2014 um 13:54 schrieb Richard Shaw:

On Tue, Oct 21, 2014 at 9:45 AM, Valerio Pachera mailto:siri...@gmail.com>> wrote:

[Service]
EnvironmentFile=/etc/conf.d/
sheep.conf
ExecStart=/usr/sbin/sheep --pidfile /var/run/sheep.pid ${SHEEP_OPTS}
${SHEEP_PATH}
PIDFile=/var/run/sheep.pid
Type=forking

Does sheep fork by default? Is there an option to make it not fork?

The reason I ask is that Type=simple should be preferred. Then there's
no PID file to track since it stays the same and it's preferred over
Type=forking which is mainly for sysvinit compatibility


that is only one side of the coin

the other side is the depending services have no idea in case of 
"Type=simple" if it has finished startup - that's why you don't see any 
such service in "systemd-analyze blame" - the startup is a "fire and 
forget" as long it don't terminate


see here:
https://bugzilla.redhat.com/show_bug.cgi?id=1126595#c1

after change clamd to "Type=forking" systemd knows when it's startup has 
finished because it forks after that and the After/Before of the milter 
works relieable


so have postfix depending on all milters the first time when Port 25 
accepts connections any other services are also in a sane state instead 
throw around temporary rejects because half of the infrastructure is not 
ready




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: dnf vs yum

[Vít Ondruch]

Dne 24.10.2014 v 13:43 Pierre-Yves Chibon napsal(a):
> On Fri, Oct 24, 2014 at 07:33:06AM -0400, Rahul Sundaram wrote:
>>Hi
>>On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote:
>>
>>  Proberly because dnf support is very new, so it will need some more real
>>  time use
>>
>>That would be a good reason to switch the default in Rawhide at this
>>stage.
> +1 there, after all DNF is planned to be made the default in F22 according to:
> http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
>
> Pierre

Yes, switch the defaults ASAP. Thanks


Vít
-- 
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: dnf vs yum

[Reindl Harald]

Am 24.10.2014 um 13:45 schrieb Corey Sheldon:

its in the repos and in the test release notes last i saw so use as you
feel and test it out and last i checked  while it is the cornerstone
feature not likely a blocker as yum is still working and IT is afterall
a fork of yum


first: stop top posting and place your signature in the middle of a thread

second: your comments after Rahul's "That would be a good reason" don't 
make any sense, he is right that new things which are planned to replace 
in the final GA release should be enabled in development


"it's in the repos so use as you feel" is with all respect nonsense, 
*you missed* the *koji* context - i have no use for koji here, but the 
Fedora infrastrucure and upstream development has



On Fri, Oct 24, 2014 at 7:42 AM, Reindl Harald:

Am 24.10.2014 um 13:38 schrieb Corey Sheldon:

Rawhide is far from "realtime use" in my book as that means
public use
not just developer/tester types


and how do you ever reach "public use" if it keeps disabled for
devel/testing?

On Fri, Oct 24, 2014 at 7:33 AM, Rahul Sundaram
mailto:methe...@gmail.com>

 On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote:

 Proberly because dnf support is very new, so it will
need some
 more real time use

 That would be a good reason to switch the default in
Rawhide at this
 stage.




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: Request new package

[Richard Shaw]

On Tue, Oct 21, 2014 at 9:45 AM, Valerio Pachera  wrote:

> [Service]
> EnvironmentFile=/etc/conf.d/
> sheep.conf
> ExecStart=/usr/sbin/sheep --pidfile /var/run/sheep.pid ${SHEEP_OPTS}
> ${SHEEP_PATH}
> PIDFile=/var/run/sheep.pid
> Type=forking
>

Does sheep fork by default? Is there an option to make it not fork?

The reason I ask is that Type=simple should be preferred. Then there's no
PID file to track since it stays the same and it's preferred over
Type=forking which is mainly for sysvinit compatibility.

Thanks,
Richard
-- 
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: dnf vs yum

[Corey Sheldon]

its in the repos and in the test release notes last i saw so use as you
feel and test it out and last i checked  while it is the cornerstone
feature not likely a blocker as yum is still working and IT is afterall a
fork of yum

Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
310.909.7672
www.facebook.com/1stclassmobileshine

On Fri, Oct 24, 2014 at 7:42 AM, Reindl Harald 
wrote:

>
>
> Am 24.10.2014 um 13:38 schrieb Corey Sheldon:
>
>> Rawhide is far from "realtime use" in my book as that means public use
>> not just developer/tester types
>>
>
> and how do you ever reach "public use" if it keeps disabled for
> devel/testing?
>
>  On Fri, Oct 24, 2014 at 7:33 AM, Rahul Sundaram >
>> On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote:
>>
>> Proberly because dnf support is very new, so it will need some
>> more real time use
>>
>> That would be a good reason to switch the default in Rawhide at this
>> stage.
>>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
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: dnf vs yum

[Pierre-Yves Chibon]

On Fri, Oct 24, 2014 at 07:33:06AM -0400, Rahul Sundaram wrote:
>Hi
>On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote:
> 
>  Proberly because dnf support is very new, so it will need some more real
>  time use
> 
>That would be a good reason to switch the default in Rawhide at this
>stage.

+1 there, after all DNF is planned to be made the default in F22 according to:
http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF

Pierre
-- 
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: dnf vs yum

[Reindl Harald]

Am 24.10.2014 um 13:38 schrieb Corey Sheldon:

Rawhide is far from "realtime use" in my book as that means public use
not just developer/tester types


and how do you ever reach "public use" if it keeps disabled for 
devel/testing?



On Fri, Oct 24, 2014 at 7:33 AM, Rahul Sundaram 



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: dnf vs yum

[Corey Sheldon]

Rawhide is far from "realtime use" in my book as that means public use not
just developer/tester types

Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
310.909.7672
www.facebook.com/1stclassmobileshine

On Fri, Oct 24, 2014 at 7:33 AM, Rahul Sundaram  wrote:

> Hi
>
> On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote:
>
>> Proberly because dnf support is very new, so it will need some more real
>> time use
>>
>
> That would be a good reason to switch the default in Rawhide at this
> stage.
>
> 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
>
-- 
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: dnf vs yum

[Rahul Sundaram]

Hi

On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote:

> Proberly because dnf support is very new, so it will need some more real
> time use
>

That would be a good reason to switch the default in Rawhide at this stage.

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: dnf vs yum

[Tim Lauridsen]

On Fri Oct 24 2014 at 1:23:27 PM Rahul Sundaram  wrote:

> Hi
>
> On Fri, Oct 24, 2014 at 6:51 AM, Tim Lauridsen  wrote:
>
>>
>> Mock still defaults to yum, but supports dnf also using
>> config_opts['package_manager']='dnf'
>>
>> So it makes sense to have a hard requirement on yum
>>
>
> Well the question is, why doesn't it default to dnf in Rawhide?
>
>
>
Proberly because dnf support is very new, so it will need some more real
time use before the default is switched

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

F-21 Branched report: 20141024 changes

[Fedora Branched Report]

Compose started at Fri Oct 24 07:15:02 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: dnf vs yum

[Rahul Sundaram]

Hi

On Fri, Oct 24, 2014 at 6:51 AM, Tim Lauridsen  wrote:

>
> Mock still defaults to yum, but supports dnf also using
> config_opts['package_manager']='dnf'
>
> So it makes sense to have a hard requirement on yum
>

Well the question is, why doesn't it default to dnf in Rawhide?

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: Bumping python-requests in f20?

[Kalev Lember]

On 10/23/2014 10:57 PM, Ralph Bean wrote:
> On Thu, Oct 23, 2014 at 01:16:29PM -0700, Ed Marshall wrote:
>> Is it API-compatible?
> 
> Not exactly 
> https://github.com/kennethreitz/requests/blob/master/HISTORY.rst#230-2014-05-16

I would personally say no to updating libraries to incompatible
versions. We already have way too much churn in F20; doing the update
would mean updating and retesting anything that uses python-requests.
And not just testing the packages in Fedora, this could also potentially
break 3rd party programs that people might have written in house.

Maybe just tell the users who were asking for an update to switch to
F21? It's really close now and I know several people who are using it
daily on their main workstations and are very happy with it.

-- 
Kalev
-- 
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 24 October 2014 15:00 UTC on #fedora-meeting

[Phil Knirsch]

Agenda:
 - Status buildrequires cleanup work (davids & nils!)
 - Revisit/update factory-reset/config subpackage
 - 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: 20141024 changes

[Fedora Rawhide Report]

Compose started at Fri Oct 24 05:15:03 UTC 2014
Broken deps for i386
--
[3Depict]
3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0
[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
[bash-argsparse]
bash-argsparse-1.6.1-2.fc22.noarch requires /bin/getopt
bash-argsparse-1.6.1-2.fc22.noarch requires /bin/getent
[cab]
cab-0.1.9-12.fc22.i686 requires cabal-dev
[collectd]
collectd-onewire-5.4.1-10.fc22.i686 requires libowcapi-2.9.so.7
[condor]
condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so
[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
[freeipa]
freeipa-server-4.1.0-2.fc22.i686 requires pki-ca >= 0:10.2.0-3
[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
[glances]
glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0
[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
[iwhd]
iwhd-1.6-11.fc22.i686 requires libmongoclient.so
[kmid2]
kmid2-2.4.0-7.fc22.i686 requires libdrumstick-file.so.0
kmid2-2.4.0-7.fc22.i686 requires libdrumstick-alsa.so.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.i686 requires libf77blas.so.3
libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1
[llvm]
llvm-ocaml-3.4-15.fc22.i686 requires ocaml(Pervasives) = 
0:4329e57fde14cc94b02a739d2595516b
[ltsp]
ltsp-client-5.4.5-8.fc21.i686 requires fuse-unionfs
ltsp-server-5.4.5-8.fc21.i686 requires cdialog
[meshmagick]
meshmagick-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1
meshmagick-libs-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1
[monodevelop-vala]
monodevelop-vala-2.8.8.1-6.fc21.i686 requires vala < 0:0.25.0
[netdisco]
netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay)
[nwchem]
nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1
[ocaml-cryptokit]
ocaml-cryptokit-1.9-6.fc22.i686 requires ocaml(Obj) = 
0:31e1329a4c3d9c2947b31f79b700fcfd
[ocaml-mysql]
ocaml-mysql-1.1.2-4.fc22.i686 requires ocaml(Obj) = 
0:31e1329a4c3d9c2947b31f79b700fcfd
[openshift-origin-msg-node-mcollective]
openshift-origin-msg-node-mcollective-1.18.0.1-2.fc21.noarch requires 
openshift-origin-msg-common
[opensips]
opensips-perl-1.10.1-2.fc21.i686 requires perl(:MODULE_COMPAT_5.18.2)
opensips-perl-1.10.1-2.fc21.i686 requires libperl.so.5.18
opensips-perlvdb-1.10.1-2.fc21.i686 requires perl(:MODULE_COMPAT_5.18.2)
opensips-perlvdb-1.10.1-2.fc21.i686 requires libperl.so.5.18
opensips-snmpstats-1.10.1-2.fc21.i686 requires 
perl(:MODULE_COMPAT_5.18.2)
[openslides]
openslides-1.3.1-3.fc21.noarch requires python-django < 0:1.5
[openvas-client]
openvas-client-3.0.3-8.fc20.i686 requires libopenvas_omp.so.6
openvas-client-3.0.3-8.fc20.i686 requires libopenvas_nasl.so.6
openvas-client-3.0.3-8.fc20.i686 requires libopenvas_misc.so.6
openvas-client-3.0.3-8.fc20.i686 requires libopenvas_hg.so.6
openvas-client-3.0.3-8.fc20.i686 requires libopenvas_base.so.6
[perdition]
perdition-2.1-1.fc22.i686

Re: Improving the offline updates user experience

[Reindl Harald]

Am 24.10.2014 um 12:02 schrieb Mathieu Bridon:

On Fri, 2014-10-24 at 12:00 +0200, Miroslav Suchý wrote:

I'm not updating daily. I upgraded my machine IIRC 2-3 weeks ago. So lets 
benchmark it and provide you real data.

My machine have classic magnetic disk, however in SW RAID1.
   Timing cached reads:   12236 MB in  2.00 seconds = 6124.59 MB/sec
   Timing buffered disk reads: 412 MB in  3.00 seconds = 137.12 MB/sec
Fedora 21, 16 GB RAM (2GB free), 8 CPU cores, swap available but none used

I run "dnf upgrade" and I have been offered 853 packages and 1.3 GB to download.
Download lasted 3mins 20secs.
Then installation started and since beginning "transaction started" till the 
end lasted exactly 53 minutes.
No specific package is blocking the process, dnf was chewing packages one by 
one in steady pace. Veryfing phase lasted
~4 minutes, so it means approximately 3 second per package, which is what I am 
seeing on screen.

And this is nothing exceptional. I see similar times across all machines I 
maintain. When I'm updating box of my mother
(old EeeBox, updating aprox every 3 months) then the time is usually 3 hours 
(however ~1 hour is just download phase).


More than anything, doesn't this just shows that we simply push way too
many updates in Fedora?


no

* first:  the above is Rawhide/Alpha
* second: the reason i run Fedora and not Debian/RHEL is fast updates
* third:  nobody should apply updates every 3 weeks
  but that above is Alpha and so no "production" machine



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: Improving the offline updates user experience

[Richard Hughes]

On 24 October 2014 11:00, Miroslav Suchý  wrote:
> I run "dnf upgrade" and I have been offered 853 packages and 1.3 GB to
> download.

I'm pretty sure F21 for the last few weeks is not representative of a
normal installed system over a 2 week period. 853 must be close to
every package on your box...

Richard
-- 
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: dnf vs yum

[Tim Lauridsen]

On Fri Oct 24 2014 at 12:46:41 PM Rahul Sundaram  wrote:

> Hi
>
> On Fri, Oct 24, 2014 at 3:51 AM, Michael Simacek  wrote:
>
>>
>> Mock-1.2 no longer depends on yum API and has been ported to use DNF.
>> So if you use the new version and set config_opts['package_manager']='dnf'
>> and also install dnf-plugins-core, you should be able to use it without
>> any problems.
>> But the dnf-yum (/usr/bin/yum being symlink to dnf) scenario is not
>> supported yet,
>> you have to explicitly tell it to use dnf, otherwise it won't work.
>> dnf and yum don't always behave the same and mock has to treat them a bit
>> differently. But the package itself still needs to depend on yum, because
>> even
>> if dnf-yum was supported, it doesn't pull in dnf-plugins-core package
>> which
>> contains builddep command.
>>
>
> I don't quite understand that explanation.  For rawhide, why doesn't mock
> drop the dependency on yum and add a dependency on dnf *and*
> dnf-plugins-core?
>
>
Mock still defaults to yum, but supports dnf also using
config_opts['package_manager']='dnf'

So it makes sense to have a hard requirement on yum

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

Re: dnf vs yum

[Rahul Sundaram]

Hi

On Fri, Oct 24, 2014 at 3:51 AM, Michael Simacek  wrote:

>
> Mock-1.2 no longer depends on yum API and has been ported to use DNF.
> So if you use the new version and set config_opts['package_manager']='dnf'
> and also install dnf-plugins-core, you should be able to use it without
> any problems.
> But the dnf-yum (/usr/bin/yum being symlink to dnf) scenario is not
> supported yet,
> you have to explicitly tell it to use dnf, otherwise it won't work.
> dnf and yum don't always behave the same and mock has to treat them a bit
> differently. But the package itself still needs to depend on yum, because
> even
> if dnf-yum was supported, it doesn't pull in dnf-plugins-core package which
> contains builddep command.
>

I don't quite understand that explanation.  For rawhide, why doesn't mock
drop the dependency on yum and add a dependency on dnf *and*
dnf-plugins-core?

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: Request new package

[Valerio Pachera]

2014-10-20 15:04 GMT+02:00 Richard Shaw :
> On a side note, I played around building a package and noticed that only a
> sysvinit file is provided.

Now we have initial systemd support in upstream (master branch).
-- 
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: Improving the offline updates user experience

[Mathieu Bridon]

On Fri, 2014-10-24 at 12:00 +0200, Miroslav Suchý wrote:
> I'm not updating daily. I upgraded my machine IIRC 2-3 weeks ago. So lets 
> benchmark it and provide you real data.
> 
> My machine have classic magnetic disk, however in SW RAID1.
>   Timing cached reads:   12236 MB in  2.00 seconds = 6124.59 MB/sec
>   Timing buffered disk reads: 412 MB in  3.00 seconds = 137.12 MB/sec
> Fedora 21, 16 GB RAM (2GB free), 8 CPU cores, swap available but none used
> 
> I run "dnf upgrade" and I have been offered 853 packages and 1.3 GB to 
> download.
> Download lasted 3mins 20secs.
> Then installation started and since beginning "transaction started" till the 
> end lasted exactly 53 minutes.
> No specific package is blocking the process, dnf was chewing packages one by 
> one in steady pace. Veryfing phase lasted 
> ~4 minutes, so it means approximately 3 second per package, which is what I 
> am seeing on screen.
> 
> And this is nothing exceptional. I see similar times across all machines I 
> maintain. When I'm updating box of my mother 
> (old EeeBox, updating aprox every 3 months) then the time is usually 3 hours 
> (however ~1 hour is just download phase).

More than anything, doesn't this just shows that we simply push way too
many updates in Fedora?


-- 
Mathieu

-- 
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: Improving the offline updates user experience

[Miroslav Suchý]

On 10/23/2014 12:57 PM, Reindl Harald wrote:

The upgrade can last one hour (more or less).


An hour?! Most of my offline updates take a few tens of seconds with
F21. Is this on fairly up-to-date SSD hardware? Are any specific
packages taking longer than the others?


an hour was surely exaggerated


Not at all.
I'm not updating daily. I upgraded my machine IIRC 2-3 weeks ago. So lets 
benchmark it and provide you real data.

My machine have classic magnetic disk, however in SW RAID1.
 Timing cached reads:   12236 MB in  2.00 seconds = 6124.59 MB/sec
 Timing buffered disk reads: 412 MB in  3.00 seconds = 137.12 MB/sec
Fedora 21, 16 GB RAM (2GB free), 8 CPU cores, swap available but none used

I run "dnf upgrade" and I have been offered 853 packages and 1.3 GB to download.
Download lasted 3mins 20secs.
Then installation started and since beginning "transaction started" till the 
end lasted exactly 53 minutes.
No specific package is blocking the process, dnf was chewing packages one by one in steady pace. Veryfing phase lasted 
~4 minutes, so it means approximately 3 second per package, which is what I am seeing on screen.


And this is nothing exceptional. I see similar times across all machines I maintain. When I'm updating box of my mother 
(old EeeBox, updating aprox every 3 months) then the time is usually 3 hours (however ~1 hour is just download phase).


--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
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: dnf vs yum

[Michael Simacek]

- Original Message -
> From: "Rahul Sundaram" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, October 6, 2014 10:00:54 AM
> Subject: Re: dnf vs yum
> 
> Hi
> 
> On Mon, Oct 6, 2014 at 3:52 AM, Marcin Juszkiewicz wrote:
> 
> 
> Too bad that it does not also say that it provides yum ;(
> 
> 09:52 root@pinkiepie-rawhide:mnt$ dnf install dnf-yum mock
> Error: package mock-1.1.41-3.fc22.noarch requires yum >= 2.4, but none
> of the providers can be installed
> 
> Because it doesn't provide yum. It only provides a command line api. Tools
> that depend on the yum API including mock won't work with dnf-yum. They
> actually need to be ported over just like yumex-dnf has.

Mock-1.2 no longer depends on yum API and has been ported to use DNF.
So if you use the new version and set config_opts['package_manager']='dnf'
and also install dnf-plugins-core, you should be able to use it without any 
problems.
But the dnf-yum (/usr/bin/yum being symlink to dnf) scenario is not supported 
yet,
you have to explicitly tell it to use dnf, otherwise it won't work.
dnf and yum don't always behave the same and mock has to treat them a bit
differently. But the package itself still needs to depend on yum, because even
if dnf-yum was supported, it doesn't pull in dnf-plugins-core package which
contains builddep command.

Michael Simacek

> 
> 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
-- 
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: Bumping python-requests in f20?

[Christopher Meng]

Incompatible though.

But without v2, some packages will not work. V2 should be pushed
already, but V1 is still used in f20.

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
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 Release Candidate 1 (RC1) Available Now!

[Andre Robatino]

As per the Fedora 21 schedule [1], Fedora 21 Beta Release Candidate 1
(RC1) is now available for testing. Content information, including
changes, can be found at
https://fedorahosted.org/rel-eng/ticket/6010#comment:11 . 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