Re: fedup performance

[Panu Matilainen]

On 07/03/2013 07:42 AM, Alex G. wrote:

On 07/02/2013 08:28 PM, Neal Becker wrote:

Not d/l speed related.  I just want to share.  I update a very fast 8 core
server, with a conventional disk drive.  Took 2-3 hours, not including d/l.

I update my laptop which has an ssd (and MORE packages).  Took 10-15 minutes.


I think this might simply have to do with rpm running ldconfig (a very
disk IO expensive operation) for a large number of packages. I'm not
sure yum/rpm has deferred ldconfig processing.

DISCLAIMER: I may be very wrong. Please don't quote me on this.


ldconfig gets run a lot yes, but its also really fast these days. 
fdatasync() which gets called even more (a lot more at that) seems like 
a more likely painpoint on upgrades.


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

Re: fedup performance

[Adam Williamson]

On 2013-07-02 22:25, Alex G. wrote:

On 07/03/2013 12:15 AM, Adam Williamson wrote:

On 2013-07-02 21:42, Alex G. wrote:

On 07/02/2013 08:28 PM, Neal Becker wrote:
Not d/l speed related.  I just want to share.  I update a very fast 
8

core
server, with a conventional disk drive.  Took 2-3 hours, not
including d/l.

I update my laptop which has an ssd (and MORE packages).  Took 10-15
minutes.

I think this might simply have to do with rpm running ldconfig (a 
very

disk IO expensive operation) for a large number of packages. I'm not
sure yum/rpm has deferred ldconfig processing.


rpm has the concept of %posttrans . Stuff in %posttrans is run after
*the entire transaction* has completed, not after *the specific 
package

install* has completed.

However, I think we can't put ldconfig in %posttrans, because what
happens if a package installed later relies on the ldconfig being
correct for a package installed earlier in the same transaction?


aptitude has something called "deferred ldconfig processing", and
annoyingly, aptitude updates faster than yum.


*mumble mumble* correlation *mumble* causation *mumble*
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedup performance

[Alex G.]

On 07/03/2013 12:15 AM, Adam Williamson wrote:
> On 2013-07-02 21:42, Alex G. wrote:
>> On 07/02/2013 08:28 PM, Neal Becker wrote:
>>> Not d/l speed related.  I just want to share.  I update a very fast 8
>>> core
>>> server, with a conventional disk drive.  Took 2-3 hours, not
>>> including d/l.
>>>
>>> I update my laptop which has an ssd (and MORE packages).  Took 10-15
>>> minutes.
>>>
>> I think this might simply have to do with rpm running ldconfig (a very
>> disk IO expensive operation) for a large number of packages. I'm not
>> sure yum/rpm has deferred ldconfig processing.
> 
> rpm has the concept of %posttrans . Stuff in %posttrans is run after
> *the entire transaction* has completed, not after *the specific package
> install* has completed.
> 
> However, I think we can't put ldconfig in %posttrans, because what
> happens if a package installed later relies on the ldconfig being
> correct for a package installed earlier in the same transaction?
> 
aptitude has something called "deferred ldconfig processing", and
annoyingly, aptitude updates faster than yum. I've always wondered how
yum/rpm can be smartized to speed things up this way. But this
discussion is for a brighter day.

>> DISCLAIMER: I may be very wrong. Please don't quote me on this.
> 
> Seconded =)
My name is Alexandru Gagniuc, and I approve this message. :)

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

Re: fedup performance

[Adam Williamson]

On 2013-07-02 21:42, Alex G. wrote:

On 07/02/2013 08:28 PM, Neal Becker wrote:
Not d/l speed related.  I just want to share.  I update a very fast 8 
core
server, with a conventional disk drive.  Took 2-3 hours, not including 
d/l.


I update my laptop which has an ssd (and MORE packages).  Took 10-15 
minutes.



I think this might simply have to do with rpm running ldconfig (a very
disk IO expensive operation) for a large number of packages. I'm not
sure yum/rpm has deferred ldconfig processing.


rpm has the concept of %posttrans . Stuff in %posttrans is run after 
*the entire transaction* has completed, not after *the specific package 
install* has completed.


However, I think we can't put ldconfig in %posttrans, because what 
happens if a package installed later relies on the ldconfig being 
correct for a package installed earlier in the same transaction?



DISCLAIMER: I may be very wrong. Please don't quote me on this.


Seconded =)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedup performance

[Alex G.]

On 07/02/2013 08:28 PM, Neal Becker wrote:
> Not d/l speed related.  I just want to share.  I update a very fast 8 core 
> server, with a conventional disk drive.  Took 2-3 hours, not including d/l.
> 
> I update my laptop which has an ssd (and MORE packages).  Took 10-15 minutes.
> 
I think this might simply have to do with rpm running ldconfig (a very
disk IO expensive operation) for a large number of packages. I'm not
sure yum/rpm has deferred ldconfig processing.

DISCLAIMER: I may be very wrong. Please don't quote me on this.

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

Re: More unhelpful update descriptions

[Alex G.]

On 07/01/2013 02:43 PM, Johannes Lips wrote:
> Richard W.M. Jones wrote:
>> Since this topic comes up every few months, and no one's pointed
>> out the obvious answer yet, I'll say it:
>>
>> * Instead of making up more rules, make the tooling better so
>> we don't have to repeat update descriptions in multiple places. *
> Wouldn't it make sense to perhaps apply different rules or policies for
> different types of packages? I mean we could focus on those applications
> a regular user sees, like all the Office, Internet and Multimedia apps.
> And make the rules for libs and all that stuff, normally only devs are
> interested in, less strict.
> So we always write update comments with the respective target audience,
> making them less technical for all the userspace applications and so on.
> On the other hand, bodhi probably can't distinguish between those two
> types of packages, or?
> 

More rules?

Alex

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

Re: More unhelpful update descriptions

[Adam Williamson]

On 2013-07-02 21:32, Michael Catanzaro wrote:

On Mon, 2013-07-01 at 14:54 -0700, Dan Mashal wrote:


There is already a perfect example of this.

https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19

Dan

I went through updates-testing looking for placeholder text (and will
never be doing that again, it's not fun). Of the 422 updates currently
in F19 testing, 12 have the placeholder text as a description:

https://admin.fedoraproject.org/updates/FEDORA-2013-12227/youtube-dl-2013.07.02-1.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-12197/skrooge-1.7.1-1.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-12191/libmwaw-0.1.10-1.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-12148/perl-Tapper-4.1.1-2.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-11891/mingw-libusbx-1.0.15-1.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-11820/bacula-5.2.13-12.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-11668/dvd
+rw-tools-7.1-13.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-9454/openstack-quantum-2013.1.1-5.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-7077/salt-api-0.8.1-0.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-6012/dnf-0.3.3-3.git91ba5e0.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-6947/vboot-utils-20130222gite6cf2c2-3.fc19

This one:
https://admin.fedoraproject.org/updates/FEDORA-2013-7094/liblangtag-0.5.0-1.fc19
probably should also not be released

Some of these have been sitting in testing since April, so a bit of
extra delay in resubmitting these updates should be tolerable.


I do sometimes wonder if we should have an auto-push for updates that 
sit in testing for *months*. It's not a dumping ground; if you 
explicitly don't want an update to go stable for some reason you should 
probably un-push it until it's ready...


By this point it seems to be the case that, realistically, we are never 
going to reach the auto-push threshold on some updates. And most updates 
get submitted with the default +3 auto-push, even though it's perhaps 
not appropriate for all updates.

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

Re: More unhelpful update descriptions

[Alex G.]

On 07/01/2013 01:25 PM, Adam Williamson wrote:
> On 2013-07-01 1:28, Richard W.M. Jones wrote:
>> Since this topic comes up every few months, and no one's pointed
>> out the obvious answer yet, I'll say it:
>>
>> * Instead of making up more rules, make the tooling better so
>> we don't have to repeat update descriptions in multiple places. *
> 
> You appear to be missing the contention made by me and others that the
> update description is not and should not be a simple repetition of any
> other content. It is not the RPM changelog. It is not the git commit
> log. It is not the upstream changelog.
> 

You can't change human nature: people may forget, people may be
uninspired at the moment, etc. Rather than correct(micromanage) the
behaviour of masses, it is much easier to accept the behaviour of masses.

People do not like to have to deal with RPM changelogs, Fedora SCM (git)
commit messages, update descriptions, etc, each with a different set of
rules. It is boring and error prone.

We shouldn't be surprised that update descriptions are crap. They are
just an annoyance for a lot of us, especially since we've put all that
information in a bunch of other places.

+2 to better tooling

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

Re: Announcing the release of Fedora 19 for ARM!

[Adam Williamson]

On 2013-07-02 18:44, Chris Murphy wrote:

On Jul 2, 2013, at 6:28 PM, John Reiser  wrote:


On 07/02/2013 Matthew Garrett wrote:

GNOME runs fine without hardware 3D support, but the llvmpipe code 
that

makes that possible segfaults on ARM.


Gnome3 Desktop is unusable on i686 with RV280 video card driven by 
llvmpipe.

XFCE and MATE *do* run just fine using the classic ati driver.


Well, even without llvmpipe, nouveau and a G84M [GeForce 8600M GT]
choke on Gnome 3 shipping with F19 but not F18. Gnome-shell and Xorg
hog 1/2 to more than a full core between them. I consider that
unusable for anything beyond light web browsing or the computer turns
into a combo hot plate / hair dryer.


Well, that's clearly a bug in the driver layer somewhere.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Michael Catanzaro]

On Mon, 2013-07-01 at 14:54 -0700, Dan Mashal wrote:
> 
> There is already a perfect example of this.
> 
> https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
> 
> Dan
I went through updates-testing looking for placeholder text (and will
never be doing that again, it's not fun). Of the 422 updates currently
in F19 testing, 12 have the placeholder text as a description:

https://admin.fedoraproject.org/updates/FEDORA-2013-12227/youtube-dl-2013.07.02-1.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-12197/skrooge-1.7.1-1.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-12191/libmwaw-0.1.10-1.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-12148/perl-Tapper-4.1.1-2.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-11891/mingw-libusbx-1.0.15-1.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-11820/bacula-5.2.13-12.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-11668/dvd
+rw-tools-7.1-13.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-9454/openstack-quantum-2013.1.1-5.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-7077/salt-api-0.8.1-0.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-6012/dnf-0.3.3-3.git91ba5e0.fc19
https://admin.fedoraproject.org/updates/FEDORA-2013-6947/vboot-utils-20130222gite6cf2c2-3.fc19

This one:
https://admin.fedoraproject.org/updates/FEDORA-2013-7094/liblangtag-0.5.0-1.fc19
probably should also not be released

Some of these have been sitting in testing since April, so a bit of
extra delay in resubmitting these updates should be tolerable.

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

Re: More unhelpful update descriptions

[Michael Catanzaro]

On Mon, 2013-07-01 at 14:54 -0700, Dan Mashal wrote:
> 
> There is already a perfect example of this.
> 
> https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
> 
> Dan
Thanks for pointing it out. I've filed more negative karma against this
update, but it needs even more to prevent it from going out.

In the interests of avoiding some sort of update description war, let's
reserve negative karma only for updates with the placeholder
description. Regardless of all else we've discussed, I think (or hope)
we all agree that the placeholder text is unacceptable.

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

Re: Announcing the release of Fedora 19 for ARM!

[Chris Murphy]

On Jul 2, 2013, at 6:28 PM, John Reiser  wrote:

> On 07/02/2013 Matthew Garrett wrote:
> 
>> GNOME runs fine without hardware 3D support, but the llvmpipe code that 
>> makes that possible segfaults on ARM.
> 
> Gnome3 Desktop is unusable on i686 with RV280 video card driven by llvmpipe.
> XFCE and MATE *do* run just fine using the classic ati driver.

Well, even without llvmpipe, nouveau and a G84M [GeForce 8600M GT] choke on 
Gnome 3 shipping with F19 but not F18. Gnome-shell and Xorg hog 1/2 to more 
than a full core between them. I consider that unusable for anything beyond 
light web browsing or the computer turns into a combo hot plate / hair dryer.


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

fedup performance

[Neal Becker]

Not d/l speed related.  I just want to share.  I update a very fast 8 core 
server, with a conventional disk drive.  Took 2-3 hours, not including d/l.

I update my laptop which has an ssd (and MORE packages).  Took 10-15 minutes.

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

Re: Announcing the release of Fedora 19 for ARM!

[John Reiser]

On 07/02/2013 Matthew Garrett wrote:

> GNOME runs fine without hardware 3D support, but the llvmpipe code that 
> makes that possible segfaults on ARM.

Gnome3 Desktop is unusable on i686 with RV280 video card driven by llvmpipe.
XFCE and MATE *do* run just fine using the classic ati driver.

  https://bugzilla.redhat.com/show_bug.cgi?id=946911
[R200][RV280] Fedora-Live-Desktop is too slow for interactive use
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

License change: PokerTH, GPLv2+ to AGPLv3+ with exceptions

[Adam Williamson]

Hey, folks. Another license issue I caught while bumping PokerTH. 
Somewhere between 0.8.3 and 0.9.4 (I can't be more precise as the 
earlier 0.9 releases no longer seem to be available and this fact was 
not noted in the changelog!), upstream changed the license from GPLv2+ 
to AGPLv3+. In 1.0, an exception for OpenSSL linking was added. So the 
license is now "AGPLv3+ with exceptions". I don't think this materially 
affects any other package. I am correcting the License: field in the 
1.0.1 package builds I'm currently doing.

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

Re: More unhelpful update descriptions

[Björn Persson]

Richard W.M. Jones wrote:
> %changelog -f 
> %changelog -g 

And, I suppose:

%changelog -s 
%changelog -c 
%changelog -m 
%changelog -h 
%changelog -a 
%changelog -b 

... and so on, right? And every time someone comes up with a new version
control system, RPM would grow support for a new protocol and a new
changelog format? OK, but what format should it read when the -f option
is used? I'm not aware of a formal standard format for hand-written
changelogs.

What should RPM do if it encounters a parse error in the upstream
changelog? Should it fail to build the package?

> %release_notes -f 

And what would that mean? Should that entire web page be copied into the
update announcement? Including stylesheets and images? Or should the
update announcement only contain a link to the release notes?

> The packager has to do two things (point RPM at the upstream changelog
> and the release notes), once, and the other tools should work from
> those forever more.

So you expect upstream to keep their release notes in an ever-growing
document at a static URL? Or do you expect them to adhere to a strict
pattern so that you can insert "%{version}" in the URL? How common are
those approaches? Some projects do release announcements in a blog-like
style without any particular pattern for the URLs.

> You could extend this later so it parses out specific version
> information from the release notes, but the above covers about 80% of
> it.

What language should it parse then? I'm not aware of a formal standard
format for release notes. All you can assume is that it will be some
kind of vaguely HTML-like tag soup. It may even be valid HTML, but HTML
doesn't contain anything that would help you extract the release notes
for a specific version.

Björn Persson


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

Re: Fedup Performance

[Herbert Rutledge]

On Tue, 2013-07-02 at 18:13 -0400, Herbert Rutledge wrote:

> Actually, I sort of knew that she had something to do with food, had
> diabetes, and was on TV from the covers of women's magazines on display
> at the checkout counter at the Rite Aid.  That was pretty much it.
> 

A thousand apologies.  I accidentally replied to the wrong message.  I
haven't done that in nearly twenty years.

To get back on topic, I actually used fedora-upgrade.  It was reasonably
fast and the upgrade went off without a hitch.


-- 
Herbert Rutledge, aka Train  | "To post is human; to flame, divine."
Reply-to: tr...@voicenet.com | ---Alexander Pope



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

Re: Announcing the release of Fedora 19 for ARM!

[Matthew Garrett]

On Tue, Jul 02, 2013 at 11:14:33PM +0100, Peter Robinson wrote:

> I agree but it's not exactly maintainer on x86, ARM or otherwise which
> was the point I made previously. The LLVM problem isn't necessarily
> just an ARM problem.

Not disagreeing, but the fact that you're the ones hitting it does mean 
it's likely to be you that gets to fix it.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[Peter Robinson]

On Tue, Jul 2, 2013 at 11:09 PM, Matthew Garrett  wrote:
> On Tue, Jul 02, 2013 at 10:49:18PM +0100, Peter Robinson wrote:
>
>> Not pretty but we're severely limited by resources and ability and
>> there's a reason we don't currently ship the a gnome build.
>
> LLVM is part of Fedora, and to the extent that it contains ARM-specific
> code it's the ARM porters' responsibility to deal with it. I don't think
> it's excessive to say that you really need someone with the ability to
> maintain something that's such a system-critical component.

I agree but it's not exactly maintainer on x86, ARM or otherwise which
was the point I made previously. The LLVM problem isn't necessarily
just an ARM problem.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedup Performance

[Herbert Rutledge]

On Tue, 2013-07-02 at 18:00 -0400, Mark Bidewell wrote:

> I am doing an upgrade from F18 to F19 using fedup  network and
> performance is very slow - 3+ hours on a 20 Mbit connection.  There
> seems to be about a 10-15 second delay between package downloads.  Is
> there a reason for this delay?

Actually, I sort of knew that she had something to do with food, had
diabetes, and was on TV from the covers of women's magazines on display
at the checkout counter at the Rite Aid.  That was pretty much it.

When the story broke, however, I did some research.  Her brother
maintains separate entrances and bathrooms for white and black
employees?  She must think she's shooting craps, but those look like
hand grenades to me.

I caught a couple of minutes of her cracker act, and act it certainly
is.  She brought this all on her head.

And the repercussions!  Companies are still dumping her, weeks later.
What a scam she was running!  I fully expect to hear that Alice Chalmers
and Anaconda Copper will be the next to drop her.

-- 
Herbert Rutledge, aka Train  | "To post is human; to flame, divine."
Reply-to: tr...@voicenet.com | ---Alexander Pope



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

Re: Announcing the release of Fedora 19 for ARM!

[Matthew Garrett]

On Tue, Jul 02, 2013 at 10:49:18PM +0100, Peter Robinson wrote:

> Not pretty but we're severely limited by resources and ability and 
> there's a reason we don't currently ship the a gnome build.

LLVM is part of Fedora, and to the extent that it contains ARM-specific 
code it's the ARM porters' responsibility to deal with it. I don't think 
it's excessive to say that you really need someone with the ability to 
maintain something that's such a system-critical component.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedup Performance

[Adam Williamson]

On 2013-07-02 15:00, Mark Bidewell wrote:

I am doing an upgrade from F18 to F19 using fedup  network and
performance is very slow - 3+ hours on a 20 Mbit connection.  There
seems to be about a 10-15 second delay between package downloads.  Is
there a reason for this delay?


Well, it's *release day*. Tends to be a busy time, mirror-wise.

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

Re: Announcing the release of Fedora 19 for ARM!

[Brendan Conoboy]

On 07/02/2013 02:49 PM, Peter Robinson wrote:

Yes... that would be great if the LLVM maintainer would step up and
help out with the issues oops we don't have one of those [1]!
Getting any form of support for LLVM on ARM has been like pushing shit
up hill and has been an issue for the 2.5 years I've been working on
ARM and I get the feeling that the people that deal with it do it for
the bits that affects them because they have to not because they want
to. Not pretty but we're severely limited by resources and ability and
there's a reason we don't currently ship the a gnome build. There was
also an upstream proposal in mesa to refactor mesa to better support
EGL but that appears to have died out so we're screwed there as
well...


If anybody would like to step up and take a swing at the LLVM on ARM 
issue it would be much appreciated.  Some of the BZ history is here:


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

Perhaps more importantly, we have an upstream bug filed here:

http://www.llvm.org/bugs/show_bug.cgi?id=15557

It's been sitting in the upstream queue as new since March- no attention 
has been given to it.


As Fedora has dropped soft float support on ARM, even a workaround like 
"make the default ARM ABI hard float" would likely be enough to make 
llvmpipe, and consequently gnome, operational again.


Meanwhile, if somebody has an example besides gnome where ARM coverage 
is falling short of x86 I'm all ears. 999 out of 1000 is pretty good.


Cheers,

--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedup Performance

[Mark Bidewell]

I am doing an upgrade from F18 to F19 using fedup  network and performance
is very slow - 3+ hours on a 20 Mbit connection.  There seems to be about a
10-15 second delay between package downloads.  Is there a reason for this
delay?

-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[Peter Robinson]

On Tue, Jul 2, 2013 at 10:36 PM, Matthew Garrett  wrote:
> On Tue, Jul 02, 2013 at 10:28:03PM +0100, Peter Robinson wrote:
>> On Tue, Jul 2, 2013 at 10:05 PM, Matthew Garrett  wrote:
>> > GNOME runs fine without hardware 3D support, but the llvmpipe code that
>> > makes that possible segfaults on ARM.
>>
>> gnome runs fine on ARM as well without llvmpipe support [1] and I can
>> use it as well on F-19 with a binary driver
>
> Sure, it'll run if you use non-Fedora components. Without the LLVM
> issue, it'd work in Fedora as well.

Yes... that would be great if the LLVM maintainer would step up and
help out with the issues oops we don't have one of those [1]!
Getting any form of support for LLVM on ARM has been like pushing shit
up hill and has been an issue for the 2.5 years I've been working on
ARM and I get the feeling that the people that deal with it do it for
the bits that affects them because they have to not because they want
to. Not pretty but we're severely limited by resources and ability and
there's a reason we don't currently ship the a gnome build. There was
also an upstream proposal in mesa to refactor mesa to better support
EGL but that appears to have died out so we're screwed there as
well...

[1] https://lists.fedoraproject.org/pipermail/devel/2012-May/166731.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[Matthew Garrett]

On Tue, Jul 02, 2013 at 10:28:03PM +0100, Peter Robinson wrote:
> On Tue, Jul 2, 2013 at 10:05 PM, Matthew Garrett  wrote:
> > GNOME runs fine without hardware 3D support, but the llvmpipe code that
> > makes that possible segfaults on ARM.
> 
> gnome runs fine on ARM as well without llvmpipe support [1] and I can
> use it as well on F-19 with a binary driver

Sure, it'll run if you use non-Fedora components. Without the LLVM 
issue, it'd work in Fedora as well.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[Peter Robinson]

On Tue, Jul 2, 2013 at 10:05 PM, Matthew Garrett  wrote:
> On Tue, Jul 02, 2013 at 04:38:30PM -0400, Jared K. Smith wrote:
>> On Tue, Jul 2, 2013 at 4:16 PM, Kalev Lember  wrote:
>>
>> > In particular, the GNOME image is missing. I would not say it has all
>> > the features of the primary architectures when it doesn't include the
>> > Fedora default desktop.
>> >
>>
>> This is mostly because of a lack of video drivers on ARM hardware, as I
>> understand it.   What good is producing a GNOME image if it requires video
>> drivers that don't yet exist, or aren't yet mature enough for serious use?
>
> GNOME runs fine without hardware 3D support, but the llvmpipe code that
> makes that possible segfaults on ARM.

gnome runs fine on ARM as well without llvmpipe support [1] and I can
use it as well on F-19 with a binary driver

[1] 
http://bloggingthemonkey.blogspot.co.uk/2013/06/freedreno-gnome-shell-on-nexus4a320.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[Peter Robinson]

On Tue, Jul 2, 2013 at 9:20 PM, Matthew Garrett  wrote:
> On Tue, Jul 02, 2013 at 10:16:45PM +0200, Kalev Lember wrote:
>> 2013-07-02 22:00, Dennis Gilmore wrote:
>> > I has them, they may not all work.
>>
>> In particular, the GNOME image is missing. I would not say it has all
>> the features of the primary architectures when it doesn't include the
>> Fedora default desktop.
>
> Right. I don't want to sound like I'm unimpressed by the ARM work in F19
> - it's been a fantastic amount of effort from all involved and it's
> shaping up nicely. But it's not at feature parity with the primary
> architectures yet, and I don't think we should be implying otherwise.

I don't disagree, it should probably read "Fedora ARM has the vast
majority the features of the primary architectures" and it does have
most of the features... the level of testing is vastly less and we're
still fixing things but then mainline isn't perfect and doesn't meet
all it's promises either if you want to start splitting hairs.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[drago01]

On Tue, Jul 2, 2013 at 11:21 PM, drago01  wrote:
> On Tue, Jul 2, 2013 at 11:20 PM, Peter Robinson  wrote:
>> On Tue, Jul 2, 2013 at 9:16 PM, Kalev Lember  wrote:
>>> 2013-07-02 22:00, Dennis Gilmore wrote:
>>>
 On Tue, 2 Jul 2013 20:18:06 +0100
 Matthew Garrett  wrote:

> On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:
>
>> Fedora ARM has all the features of the primary architectures
>
> Is this really accurate?
>

 I has them, they may not all work.
>>>
>>> In particular, the GNOME image is missing. I would not say it has all
>>> the features of the primary architectures when it doesn't include the
>>> Fedora default desktop.
>>
>> The gnome 3 feature works just fine on Fedora ARM if you have the
>> drivers that will support it. I have access to non open driverrs and
>> it works just fine but it doesn't currently work with the included
>> drivers. In theory there's some open drivers that might work but
>> they're not yet upstream.
>
> Well the software renderer does not work (llvmpipe) which is what
> Matthew is talking about.

btw. gnome aside the feature called "opengl" does not work at all.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[drago01]

On Tue, Jul 2, 2013 at 11:20 PM, Peter Robinson  wrote:
> On Tue, Jul 2, 2013 at 9:16 PM, Kalev Lember  wrote:
>> 2013-07-02 22:00, Dennis Gilmore wrote:
>>
>>> On Tue, 2 Jul 2013 20:18:06 +0100
>>> Matthew Garrett  wrote:
>>>
 On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:

> Fedora ARM has all the features of the primary architectures

 Is this really accurate?

>>>
>>> I has them, they may not all work.
>>
>> In particular, the GNOME image is missing. I would not say it has all
>> the features of the primary architectures when it doesn't include the
>> Fedora default desktop.
>
> The gnome 3 feature works just fine on Fedora ARM if you have the
> drivers that will support it. I have access to non open driverrs and
> it works just fine but it doesn't currently work with the included
> drivers. In theory there's some open drivers that might work but
> they're not yet upstream.

Well the software renderer does not work (llvmpipe) which is what
Matthew is talking about.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[Peter Robinson]

On Tue, Jul 2, 2013 at 9:16 PM, Kalev Lember  wrote:
> 2013-07-02 22:00, Dennis Gilmore wrote:
>
>> On Tue, 2 Jul 2013 20:18:06 +0100
>> Matthew Garrett  wrote:
>>
>>> On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:
>>>
 Fedora ARM has all the features of the primary architectures
>>>
>>> Is this really accurate?
>>>
>>
>> I has them, they may not all work.
>
> In particular, the GNOME image is missing. I would not say it has all
> the features of the primary architectures when it doesn't include the
> Fedora default desktop.

The gnome 3 feature works just fine on Fedora ARM if you have the
drivers that will support it. I have access to non open driverrs and
it works just fine but it doesn't currently work with the included
drivers. In theory there's some open drivers that might work but
they're not yet upstream.

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

Problem with abrt update on F18?

[Richard Shaw]

I saw this during the update:

Updating   : abrt-libs-2.1.5-1.fc18.x86_64
 10/76
cp: cannot create regular file
â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/environâ: No such file or
directory
cp: cannot create regular file
â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/mapsâ: No such file or
directory
cp: cannot create regular file
â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/countâ: No such file or
directory
cp: cannot create regular file
â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/hostnameâ: No such file or
directory
cp: cannot create regular file
â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/core_backtraceâ: No such file
or directory

Is it anything to worry about?

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

Re: Announcing the release of Fedora 19 for ARM!

[Matthew Garrett]

On Tue, Jul 02, 2013 at 04:38:30PM -0400, Jared K. Smith wrote:
> On Tue, Jul 2, 2013 at 4:16 PM, Kalev Lember  wrote:
> 
> > In particular, the GNOME image is missing. I would not say it has all
> > the features of the primary architectures when it doesn't include the
> > Fedora default desktop.
> >
> 
> This is mostly because of a lack of video drivers on ARM hardware, as I
> understand it.   What good is producing a GNOME image if it requires video
> drivers that don't yet exist, or aren't yet mature enough for serious use?

GNOME runs fine without hardware 3D support, but the llvmpipe code that 
makes that possible segfaults on ARM.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: vote for systemd: Nay (now working but still Voting Nay)

[Jean-Marc Pigeon]

Thanks Michal,
your answer was really positive and encourage me to proceed further.

So I have now an FC18 running within a container under an EL6.4 HOST
with kernel 3.9.4 (big smile).

Problems starts to unlock themselves as I decided to bypass
network.service altogether
starting network and sshd manually (ifup lo; ifup eth0;
/usr/sbin/sshd). Now able to
work in a quiet room with multiple screens available to poke around
and catch fast scrolling log messages.
(you should never forget about the poor sysadmin freezing in front of
the servers room console
when your software is reporting a problem and not able to run :-}).

As expected the problem stand on a very small detail (within /etc/fstab)

Not working
/vzgot  /   ext4defaults0 0
proc/proc   procdefaults0 0
sysfs   /syssysfs   defaults0 0
devpts  /dev/ptsdevpts  defaults0 0
tmpfs   /dev/shmtmpfs   defaults0 0

Working
#/vzgot /   ext4defaults0 0
proc/proc   procdefaults0 0
sysfs   /syssysfs   defaults0 0
devpts  /dev/ptsdevpts  defaults0 0
tmpfs   /dev/shmtmpfs   defaults0 0


The fact systemd was not able to cope with this /etc/fstab is quite
acceptable,
(even if upstart and init have no problem with it), The fact such
small trouble
drives systemd to an emergency state without reporting clearly is another
question. When the last prominent line before asking for maintenance
password is about, "Not able to exec /bin/plymouth, "
you are asking yourself in what mess am I in.
The fact that the line just below says, "Please see journal" but
journal is not available (empty)
just compound the effect.

 Once I was able to log via remote SSH in emergency.service mode, I
played with different services,
trying to "ignore-dependencies" but never got a clear message about
what was missing.
Success was more a lucky guess than the result from a structured approach.

So, no, sorry, systemd doesn't grade "production level" (not yet? or never?).

May I propose some way to improve it.
- journal should be accessible regardless of systemd status or trouble.
- when list-dependencies service is displayed, you should mark dependencies
   already running (or not successfully started?), think about the
poor sysadmin!.
- You should have a way to proceed in a 'step by step' boot mode
   (avoiding in parallel fast scrolling report)

- On a more philosophical side:
   * linking PID1 and systemd seems to me a problem (why it is
mandatory still escape me),
 you are limiting your trouble shooting context (double check
your design).
   * the fact systemd is catching more and more functionality to be
 working should trigger a loud alarm signal about your design
(did I understand
 today's mail correctly?, you can't use logrotate to
expire/archive journal :/ )


Bug:
- After a very quick check, there is maybe a bug the way systemd is
handling 'int reboot(int cmd);',
   I have the strong feeling systemd is not feeding WTERMSIG(status),
but it is very
   preliminary, I could be wrong


As your request,I can provide you with "vzgot", my container
application (which flavor/distribution RPM do you want?
src.rpm is available too). While not a fork of LXC, I think vzgot is
very close to LXC about the
way the container is started, difference is more about container
definition, with vzgot, you just need
a DNS resolution (for the container's IPs) and a config_list, linking
container name to a
distribution name, a template name and an architecture. With that
data, vzgot is
able to create a running container by itself. I tried to have the
container setup as lean,
simple and flexible as possible.

I put that project in sleep mode, because a trouble I reported 3 years ago
(a  syslog+printk cross leakage between HOST and containers) seems to
be very difficult to address within the kernel. But!... very good
news yesterday!, problem is fixed within kernel 3.10.0, maybe
it is time to work on vzgot again?.






Quoting Michal Schmidt :


On 07/02/2013 04:08 PM, Jean-Marc Pigeon wrote:

I was not expecting to have it fully working at the first attempt in my
own container design,


Would you be willing to provide some details about your container
design? Ideally including the code to allow others to reproduce the
problems you saw.

Have you seen these recommendations?:
http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/


but I was expecting systemd (using systemctl very detailed status) to give
 me a very good insight about issues which could occur.

The real goal was to learn how to use systemd components to diagnose an "in
 trouble" real system, a kind of flight simulator exercise, so that we
would be ready in the future to do quick diagnosis if one of our serve

Re: Announcing the release of Fedora 19 for ARM!

[Jóhann B. Guðmundsson]

On 07/02/2013 08:38 PM, Jared K. Smith wrote:
On Tue, Jul 2, 2013 at 4:16 PM, Kalev Lember > wrote:


In particular, the GNOME image is missing. I would not say it has all
the features of the primary architectures when it doesn't include the
Fedora default desktop.


This is mostly because of a lack of video drivers on ARM hardware, as 
I understand it.   What good is producing a GNOME image if it requires 
video drivers that don't yet exist, or aren't yet mature enough for 
serious use?


Yes, no openGL-ES support and that so called default does not accurately 
represent the community nor might not be default for much longer.


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

Re: Announcing the release of Fedora 19 for ARM!

[Jared K. Smith]

On Tue, Jul 2, 2013 at 4:16 PM, Kalev Lember  wrote:

> In particular, the GNOME image is missing. I would not say it has all
> the features of the primary architectures when it doesn't include the
> Fedora default desktop.
>

This is mostly because of a lack of video drivers on ARM hardware, as I
understand it.   What good is producing a GNOME image if it requires video
drivers that don't yet exist, or aren't yet mature enough for serious use?

--
Jared Smith
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[Matthew Garrett]

On Tue, Jul 02, 2013 at 10:16:45PM +0200, Kalev Lember wrote:
> 2013-07-02 22:00, Dennis Gilmore wrote:
> > I has them, they may not all work.
> 
> In particular, the GNOME image is missing. I would not say it has all
> the features of the primary architectures when it doesn't include the
> Fedora default desktop.

Right. I don't want to sound like I'm unimpressed by the ARM work in F19 
- it's been a fantastic amount of effort from all involved and it's 
shaping up nicely. But it's not at feature parity with the primary 
architectures yet, and I don't think we should be implying otherwise.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[Kalev Lember]

2013-07-02 22:00, Dennis Gilmore wrote:

> On Tue, 2 Jul 2013 20:18:06 +0100
> Matthew Garrett  wrote:
> 
>> On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:
>>
>>> Fedora ARM has all the features of the primary architectures
>>
>> Is this really accurate?
>>
> 
> I has them, they may not all work.

In particular, the GNOME image is missing. I would not say it has all
the features of the primary architectures when it doesn't include the
Fedora default desktop.

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

Re: Announcing the release of Fedora 19 for ARM!

[Adam Williamson]

On 2013-07-02 13:07, Jóhann B. Guðmundsson wrote:

On 07/02/2013 08:04 PM, Matthew Garrett wrote:

On Tue, Jul 02, 2013 at 03:00:43PM -0500, Dennis Gilmore wrote:

>On Tue, 2 Jul 2013 20:18:06 +0100
>Matthew Garrett  wrote:

> >On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:

> > >Fedora ARM has all the features of the primary architectures

> >Is this really accurate?

>
>I has them, they may not all work.
A feature that isn't 100% implemented (which includes it working) 
isn't

a feature.


More often than not features have been flagged 100% done without them
actually being 100% implemented ( or done for that matter )...


For instance, for F19, we have 
https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames , which in practice is about 5% implemented, because it just never really gets used:


https://fedoraproject.org/wiki/Common_F19_bugs#biosdevname-vs-systemd
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=965718
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[Jóhann B. Guðmundsson]

On 07/02/2013 08:04 PM, Matthew Garrett wrote:

On Tue, Jul 02, 2013 at 03:00:43PM -0500, Dennis Gilmore wrote:

>On Tue, 2 Jul 2013 20:18:06 +0100
>Matthew Garrett  wrote:

> >On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:

> > >Fedora ARM has all the features of the primary architectures

> >Is this really accurate?

>
>I has them, they may not all work.

A feature that isn't 100% implemented (which includes it working) isn't
a feature.


More often than not features have been flagged 100% done without them 
actually being 100% implemented ( or done for that matter )...


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

Re: Announcing the release of Fedora 19 for ARM!

[Matthew Garrett]

On Tue, Jul 02, 2013 at 03:00:43PM -0500, Dennis Gilmore wrote:
> On Tue, 2 Jul 2013 20:18:06 +0100
> Matthew Garrett  wrote:
> > On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:
> > > Fedora ARM has all the features of the primary architectures
> > Is this really accurate?
> 
> I has them, they may not all work.

A feature that isn't 100% implemented (which includes it working) isn't 
a feature.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing the release of Fedora 19 for ARM!

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 2 Jul 2013 20:18:06 +0100
Matthew Garrett  wrote:

> On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:
> 
> > Fedora ARM has all the features of the primary architectures
> 
> Is this really accurate?
> 

I has them, they may not all work.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlHTMXAACgkQkSxm47BaWfdLTwCfVmxxxsXuge55h+IjyUlpPsXN
05AAnRtqsbLDbKR0WEUb7FpqAzSiniuG
=4mZw
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Monitoring a mock build?

[Ben Harper]

On 07/02/2013 01:29 PM, Richard Shaw wrote:
On Tue, Jul 2, 2013 at 1:26 PM, Sandro Mani > wrote:


On 02.07.2013 20:22, Richard Shaw wrote:

I'm wondering if there's a better method of monitoring a mock
build other than:

# mock -r  --resultdir=/path/to/results 

^Z

# bg 1
# tail -f /path/to/build.log

I guess I could use two terminals, but I'd rather just have the
one up...

Richard



Wouldn't adding -v (i.e. verbose) to the mock command line
parameters do the job?


Never tried that before :) I'll give it a whirl.

Thanks,
Richard


I have started using tmux in all of my work flows, and I like having a 
different window for building a package and another for tailing logs.  I 
would also consider tmux or screen a must if you are building on a 
remote machine.


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

Re: Announcing the release of Fedora 19 for ARM!

[Matthew Garrett]

On Tue, Jul 02, 2013 at 10:33:26AM -0500, Dennis Gilmore wrote:

> Fedora ARM has all the features of the primary architectures

Is this really accurate?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Monitoring a mock build?

[Richard Shaw]

On Tue, Jul 2, 2013 at 1:26 PM, Sandro Mani  wrote:

>  On 02.07.2013 20:22, Richard Shaw wrote:
>
> I'm wondering if there's a better method of monitoring a mock build other
> than:
>
>  # mock -r  --resultdir=/path/to/results 
>
>  ^Z
>
>  # bg 1
> # tail -f /path/to/build.log
>
>  I guess I could use two terminals, but I'd rather just have the one up...
>
>  Richard
>
>
>  Wouldn't adding -v (i.e. verbose) to the mock command line parameters do
> the job?
>

Never tried that before :) I'll give it a whirl.

Thanks,
Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Monitoring a mock build?

[Sandro Mani]

On 02.07.2013 20:22, Richard Shaw wrote:
I'm wondering if there's a better method of monitoring a mock build 
other than:


# mock -r  --resultdir=/path/to/results 

^Z

# bg 1
# tail -f /path/to/build.log

I guess I could use two terminals, but I'd rather just have the one up...

Richard


Wouldn't adding -v (i.e. verbose) to the mock command line parameters do 
the job?


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

Monitoring a mock build?

[Richard Shaw]

I'm wondering if there's a better method of monitoring a mock build other
than:

# mock -r  --resultdir=/path/to/results 

^Z

# bg 1
# tail -f /path/to/build.log

I guess I could use two terminals, but I'd rather just have the one up...

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

Re: More unhelpful update descriptions

[Richard W.M. Jones]

On Mon, Jul 01, 2013 at 11:41:48PM +0200, Björn Persson wrote:
> Richard W.M. Jones wrote:
> > As I think I said pretty clearly, there are two streams of
> > documentation: the detailed changelogs and the release notes (which
> > summarise changes in a human-readable form for a whole release).
> > 
> > These should already exist, upstream.
> > 
> > No need for them to be duplicated, *if* we had better tooling.
> 
> Perhaps you would like to write an RFC specifying the Source Code,
> Changelogs and Release Notes Publishing Protocol and submit it to the
> IETF, so that there will be a sane way to automatically find and parse
> those changelogs and release notes? Or do you expect Bodhi to magically
> find and understand upstream release notes in a gazillion random
> locations and an unbounded number of formats? Or what exactly do you
> want the "better tooling" to do?

There's another thread from 1 year ago about this too:

https://lists.fedoraproject.org/pipermail/devel/2012-May/thread.html#167184

In brief:

%changelog -f 
%changelog -g 

%release_notes -f 

The packager has to do two things (point RPM at the upstream changelog
and the release notes), once, and the other tools should work from those
forever more.

You could extend this later so it parses out specific version
information from the release notes, but the above covers about 80% of it.

Rich.

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

Re: More unhelpful update descriptions

[Sandro Mani]

Hi,

What about the following idea autogenerate update descriptions for most
cases:

* If %{release} is 1, it's an upstream version update. By storing the url
to the upstream changelog (possibly appropriately parametrized with a
%{version} placeholder), bodhi would generate a description such as
"This update updates %{name} to version %{version}, for a list of changes,
please consult $url."

* If the bugs field is non-empty in the update-description, bodhi would
generate a description such as
"This update fixes the following bugs:
- $bugnr - $bugdescr
- ..."
(This text would be appended to the upstream-update text if %{release} is 1)

* If %{release} is > 1 and $bugs is empty, the update might be a simple
rebuild because of soname bumps, mass rebuilds, etc. In this cases, the rpm
changelog entries are probably the most informative descriptions, and bodhi
would just copy these for the update description.

Thoughts?

Best,
Sandro
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

[Adam Williamson]

On 2013-07-02 10:26, Jóhann B. Guðmundsson wrote:

On 07/02/2013 05:23 PM, Adam Williamson wrote:




I am still wondering where the QA resources to do this are going to 
magically spring from. Right now we have to deal with post-19 release 
emergencies, test updates for 17, 18 and 19, and work on rather a lot 
of improvements for the F20 cycle: we are trying to write Taskbot, we 
need to revise the Final release criteria, update the entire 
validation test case set, look over the Fedora 20 Change set to plan 
testing for significant Changes, plan the F20 Test Day cycle, and then 
we go right into F20 Alpha testing. Frankly, we are unlikely to 
achieve all of the above, never mind somehow finding time to 'curate' 
an F19.1 release. Grand plans are all very well, but they need to be 
based on a realistic assessment of available resources.


We could always enslave pony's ;)

JBG


Yes! Intern unicorns! WHY DID I NOT THINK OF THIS BEFORE

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

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

[Jóhann B. Guðmundsson]

On 07/02/2013 05:23 PM, Adam Williamson wrote:




I am still wondering where the QA resources to do this are going to 
magically spring from. Right now we have to deal with post-19 release 
emergencies, test updates for 17, 18 and 19, and work on rather a lot 
of improvements for the F20 cycle: we are trying to write Taskbot, we 
need to revise the Final release criteria, update the entire 
validation test case set, look over the Fedora 20 Change set to plan 
testing for significant Changes, plan the F20 Test Day cycle, and then 
we go right into F20 Alpha testing. Frankly, we are unlikely to 
achieve all of the above, never mind somehow finding time to 'curate' 
an F19.1 release. Grand plans are all very well, but they need to be 
based on a realistic assessment of available resources. 


We could always enslave pony's ;)

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

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

[Adam Williamson]

On 2013-07-01 6:47, Matthias Clasen wrote:

On Sat, 2013-06-29 at 13:59 -0400, Matthew Miller wrote:

On Sat, Jun 29, 2013 at 10:05:56AM -0600, Kevin Fenzi wrote:
> > I like the idea of 19.1 pretty unofficially or untested, which fix
> > some issues on mac installs. Which is basically someone run pungi
> > with new boot installer stuff.
> We are currently pretty unsetup for any kind of point releases.

I think this is an interesting longer-term idea to consider, 
especially once
we have the idea of batching non-critical updates in place. That batch 
makes

a pretty good starting place for point releases.



We already have a pretty decent tool for tracking what goes into the GA
release:
https://qa.fedoraproject.org/blockerbugs/milestone/19/final/buglist

I have been thinking recently that it is a pity to just turn this off
once the GA comes, and let updates flow in unchecked. The tool could
easily be used to control what goes into a batched, qa-ed f19.1 update.


I am still wondering where the QA resources to do this are going to 
magically spring from. Right now we have to deal with post-19 release 
emergencies, test updates for 17, 18 and 19, and work on rather a lot of 
improvements for the F20 cycle: we are trying to write Taskbot, we need 
to revise the Final release criteria, update the entire validation test 
case set, look over the Fedora 20 Change set to plan testing for 
significant Changes, plan the F20 Test Day cycle, and then we go right 
into F20 Alpha testing. Frankly, we are unlikely to achieve all of the 
above, never mind somehow finding time to 'curate' an F19.1 release. 
Grand plans are all very well, but they need to be based on a realistic 
assessment of available resources.


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

Re: More unhelpful update descriptions

[Rahul Sundaram]

Hi


On Tue, Jul 2, 2013 at 9:42 AM, Ryan Lerch wrote:

>
> is it possible for not the maintainer to be able to edit the update text
> of updates? I'm thinking, say, a member of the documentation team?
>

No but feel free to file a RFE against bodhi

https://fedorahosted.org/bodhi/

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

Re: New package written in Python, without python-*

[Toshio Kuratomi]

On Tue, Jul 02, 2013 at 02:45:45AM -0400, Bohuslav Kabrda wrote:
> - Original Message -
> > Hi everybody,
> > 
> > I have a question about the name of a new package and would like
> > everyone's opinion on this issue, because in our wiki
> > (http://fedoraproject.org/wiki/Features/PythonNamingDependingOnImplementation)
> > practically forces whatever is written in Python to have name:
> > python-% {name}, but I believe this is very bad for our users, if the
> > package is a tool, not a python module the user would like to use this
> > package:
> > 
Several notes aboout this:

* This proposed feature page hasn't yet been completed so it carries no
  official weight as of yet.  You should instead read the NamingGuidelines
  and Python guidelines pages as bkabrda points out.  (All current Packaging
  Guidelines live under the /wiki/Packaging: namespace.  Things outside of
  that are not official standards for packages at this time).
* If you're building a package that has both a python2 and a python3
  implementation then that's likely a sign that the usage as a python
  library is more important than you think.  It's probably wise to use the
  python-* naming convention then.

> > # Yum install python-% {name}
> > $ ./python-% {Name}-u xxx-p xxx-f file1.txt file2.txt
> > 
> > This is not the real purpose of the package, which aims to be a
> > tool for use by our users.
> > There are also packages in Fedora are tools that are written in
> > Python and is not named python-% {name}, eg fpaste
> > (https://apps.fedoraproject.org/packages/fpaste/sources/spec).
> > I created this ticket and transmit it to everyone to view and opine:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=980318
> > 
> 
> Hi,
> there is a note in the naming guidelines regarding this [1]:
> 
> If a new package is considered an "addon" package that enhances or adds a new 
> functionality to an existing Fedora package without being useful on its own, 
> its name should reflect this fact.
> 
> Therefore if you don't consider your package to be an addon (in this case, 
> addon would be a Python library), but an "application", you should name it 
> without the "python-" prefix.
> The way you chose to name your application seems perfectly fine to me.
> 

tldr; :  +1

The longer version:

Naming of packages of applications written in python often have a bit of
maintainer discretion.  Oftentimes a package will contain both a public
module (files exist in %python_sitelib or %python_sitearch) and a program
(something in /usr/bin that is run.) We tell maintainers to evaluate this
according to whether the package is primarily of use as a module (library of
python code) or as an application that end user's invoke.

Thus we have the "yum" package and "python-docutils" packages where the
maintainers have evaluated and chosen what they think is the best fit for
their particular packages.

The python-* naming convention can also be used in cases where the name of
the python package might otherwise conflict with another package.
For instance, python-pip and perl-pip even though user's are much more
likely to be using /usr/bin/pip than importing the pip module.

Finally, it isn't currently a requirement of the naming  guidelines but it
might be a good idea to use a Virtual Provide or split off a subpackage
where a package has a use case for both python modules and as an
application.  That way end users get what they expect when they yum install
python-gists or yum install gists.  (and note -- I can't think of any
packages that use a subpackage for this atm so that's likely overkill for
most things).

-Toshio


pgpAPGRBfDzry.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] Announcing the release of Fedora 19 for ARM!

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Fedora ARM Project is delighted to announce the release of Fedora 19
("Schrödinger's Cat"). Open the box and take a look for yourself!

Fedora is a leading-edge, free and open source operating system that
continues to deliver innovative features to many users, with a new
release about every six months.

Download it now:

http://fedoraproject.org/get-fedora-options#2nd_arches

Detailed information about this release can be seen in the release
notes:
http://fedoraproject.org/wiki/Architectures/ARM/F19_Release_Announcement

** What's New in Fedora 19 for ARM? **

The Fedora ARM Project takes great pride in being able to show off
features for all types of use cases, including traditional desktop
users, systems administration, development, and many more. But a few new
features are guaranteed to be seen by nearly anyone installing Fedora
and are improvements that deserve to be called out on their own. Fedora
ARM has all the features of the primary architectures along with a few
of our own.

A complete list with details of each new feature is available here:
http://fedoraproject.org/wiki/Releases/19/FeatureList

== Unified Kernel ==

The Fedora 19 kernel is now unified. This greatly reduces the number of
kernels we need to build, since they are no longer board dependent. to
enable this the kernel has adopted Device Tree to define the platform.
As a result of this work supporting new devices is much simpler and may
already work on boards we do not have direct access to.  If you get
Fedora 19 for ARM running on a new system we would love to hear about
it.

== X and graphical desktop support ==

We have added support for running X on the Trimslice in addition to
OMAP and Versatile Express based devices. Fedora 19 for ARM, comes with
images for Xfce, LXDE, Sugar on a Stick, KDE and Mate. Thanks to
initial-setup you create your user or set the root password on first
boot. 

== Improved release process ==

Due to infrastructure changes we have been able to keep closer parity
with keeping the builds in parity with those on the primary arches,
resulting in us following the milestone processes and release Fedora 19
for ARM on the same day as the Primary architecture release. This is a
First for us.

== Software floating point removal ==

As of Fedora 19 we no longer build armv5tel rpms. this means that
support for guruplugs and sheevaplugs stops with Fedora 18. Raspberry
Pi is being supported by an optimised build called pidora. 

*** Downloads, upgrades, documentation, and common bugs ***

Start by downloading Fedora 19 for ARM:
http://fedoraproject.org/get-fedora-options#2nd_arches

If you are upgrading from a previous release of Fedora, refer to:
http://fedoraproject.org/wiki/Upgrading

*** Documentation ***
Read the full release notes for Fedora 19, guides for several languages, and 
learn about known bugs and how to report new ones:
http://docs.fedoraproject.org/

Because of the number of changes to the installer, we particularly suggest 
taking a peek at the Installation Guide:
http://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/index.html

Fedora 19 common bugs are documented at:
http://fedoraproject.org/wiki/Architectures/ARM/F19_Release_Announcement#Known_Issues

This page includes information on several known bugs in the installer,
so we recommend reading it before installing Fedora 19.

*** Contributing ***

We can't build Fedora inside a box. We need your help! Bug reports are
especially helpful--if you encounter any issues, please report them!

Fedora is a fantastic, friendly community, and we have many ways in
which you can contribute, including documentation, marketing, design, 
QA, and development. 

To learn how to help us, visit:
http://join.fedoraproject.org/

*** Fedora 20 ***

Fedora 20 has been in active development for several months already. We plan to 
release it in November 2013, though the final schedule is part of the planning 
process and subject to change:

https://fedoraproject.org/wiki/Releases/20/Schedule

*** Contact information ***

If you are a journalist or reporter, you can find additional information here:

https://fedoraproject.org/wiki/Press

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlHS8soACgkQkSxm47BaWfdm9wCcDpNNffFJasVVLrsyTOjyIW3p
ZxEAn1IUF+ZgqkT0F1pk6LXp4N5+haeS
=qMGo
-END PGP 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

Retire some spacewalk packages in Epel and Fedora

[Miroslav Suchý]

Hi,
I plan to retire package spacewalk-admin in epel, because it requires
 spacewalk-base
 perl(RHN::SatelliteCert)
which are not in epel.

And I plan to retire
 spacewalk-web
in both Fedora and Epel, because it require perl(Spacewalk::Setup).

I do not have intention to package those missing deps and I do not use 
those packages any more. If you want to take over those package raise 
your voice.

--
Miroslav Suchy
Red Hat, Software Engineer
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: vote for systemd: Nay.

[Michal Schmidt]

On 07/02/2013 04:08 PM, Jean-Marc Pigeon wrote:

I was not expecting to have it fully working at the first attempt in my
own container design,


Would you be willing to provide some details about your container 
design? Ideally including the code to allow others to reproduce the 
problems you saw.


Have you seen these recommendations?:
http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/


but I was expecting systemd (using systemctl very detailed status) to give
   me a very good insight about issues which could occur.

The real goal was to learn how to use systemd components to diagnose an "in
   trouble" real system, a kind of flight simulator exercise, so that we
would be ready in the future to do quick diagnosis if one of our server
in a rack had trouble to boot or reboot with EL7.


Interesting excersise, but I am afraid by running it in a custom 
container design and running under a host that itself is not using 
systemd you uncovered an entirely different class of problems than what 
can happen when running it on the host.



This small exercise turned out very ugly very quickly, I worked very hard
trying all the tricks and bypass I could think about to collect data. To
my dismay I
was unable to get a predictable behaviour, nor reliable data from
systemd, even in the emergency.service mode.
After a while, I was forced to face it, systemd won't help me, not even
start the system in a minimal mode,
I was not able to go beyond kernel level with systemd in control,
services started were a total mess and container was totaly lock up,
with no exploitable data provided.


Not sure how much of it relates to container environments, but have you 
seen this?:

http://freedesktop.org/wiki/Software/systemd/Debugging/

My first goal when debugging issues like this would be to make sure I 
can see the debugging output of systemd itself (i.e. with log_level set 
to debug and log_target to something I can read - probably "console" in 
the case of a container).



(Quickly: we had interesting situation within the noisy and cold server
room using the emergency.service console
such as:
$ systemctl start systemd-journald.service
--> "unable to comply!" a dependency job for systemd-journald.service
failed, see journactl -xn.


This is when logging to "kmsg" (the dmesg buffer) or "console" can 
really help find out the problem.



I ended up asking myself 'what part of this puzzle am I missing?',
I digged around in Google about systemd and I was stunned by results, I
found
my concerns were already expressed multiple time with more talented
words than mine
and this as early as 2010. Since that time it is my understanding
systemd continuously try to resolve problems
by increasing its complexity and extending its dependencies and its
centrality.

this is wrong, this is very very wrong.
A program as complex as systemd can't be a mandatory PID1 in an open
environment as UNIX.


From the above paragraphs I get the feeling you may be missing the fact 
that not all of "systemd" runs in PID1. There are more components in the 
"systemd" project, such as journald, logind, ...  - they run as separate 
processes. There is some ambiguity when talking about "systemd". 
Sometimes it refers only to the service manager (PID1), and sometimes to 
the whole suite.



BTW and to go a little bit beyond the systemd case, since 1991,
FC18 is the very first distribution I was NOT successful in
installing on a plain hardware


I heard F19 was released today with an improved Anaconda :-)

Michal

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

vote for systemd: Nay.

[Jean-Marc Pigeon]

A few weeks ago, I received a bug report regarding a Fedora package of ours,
it was a request to have its init configuration migrated to systemd. A
quick search within our Fedora repo shows systemd has become available
starting with FC14, I guess it is about time we adapt our package. So we
did so. Service definition is simple enough and the documentation is well
done, it was really easy to use systemd to start our application daemon.
There is a small lack of functionality within service definition to do exactly
what we want at the installation configuration phase, but we've found
  a solution within systemd (which, while not perfect, works).

We now have our main RPM requiring a secondary sysvinit or systemd RPM
according to distribution flavor.
Nice and easy.

Reading about systemd features, I told myself, it could be the right tool
to wake up an old project of mine exploiting containers kernel features and
have the last Fedora (FC18) running within a container under a fresh
kernel (3.9.4).

This little project gave satisfactory results with various distributions when
I designed and tested it 2 years ago. First I checked it with a standard
  EL6.4 template (400 Megs) under this new kernel (3.9.4,  HOST
EL6.4) to see if my tool was
still operational. Everything went perfectly. I was ready to test
FC18. The selected
FC18 template is a very standard one (a 939 MBytes tgz file) which
(and this is a key factor) was proved to be fully working "as is" in an openvz
container (kernel 2.6.32-042stab076.8). "as is" means that Template
was never taylored
to be on openvz container (template is used out of the box in openvz
container) and could
be used to seed a working HOST too.

I was not expecting to have it fully working at the first attempt in
my own container design,
but I was expecting systemd (using systemctl very detailed status) to give
  me a very good insight about issues which could occur.

The real goal was to learn how to use systemd components to diagnose an "in
  trouble" real system, a kind of flight simulator exercise, so that we
would be ready in the future to do quick diagnosis if one of our
server in a rack
had trouble to boot or reboot with EL7.

If this exercise result is positive enough, why not try to install systemd
within our current deployment as systemd is sysvinit compatible?

The exercise will be considered a success if I was able to log in a
FC18 container
from a remote location via SSH, the SSH port protected by the
container own iptables
(a very minimal number of services started, a "safe haven" mode to
recover a system from trouble).

This small exercise turned out very ugly very quickly, I worked very hard
trying all the tricks and bypass I could think about to collect data.
To my dismay I
was unable to get a predictable behaviour, nor reliable data from
systemd, even in the emergency.service mode.
After a while, I was forced to face it, systemd won't help me, not
even start the system in a minimal mode,
I was not able to go beyond kernel level with systemd in control,
services started were a total mess and container was totaly lock up,
with no exploitable data provided.
(Quickly: we had interesting situation within the noisy and cold
server room using the emergency.service console
such as:
$ systemctl start systemd-journald.service
--> "unable to comply!" a dependency job for systemd-journald.service
failed, see journactl -xn.
$ journalctl -xn
--> "unable to comply!" No journal files were found
)


let's be blunt... from what I have seen:
In a perfect world, systemd is obviously a nice gadget,
in a real world, systemd is the perfect tools to transform a small
problem in a terminal "cascading failure" event.

I sent a private email to Lennart about my 'little concern', giving
more details and trying to explain as well as I could,
suggesting solutions (mainly for brainstorming purpose).

Lennart answered quickly, and rejected my "worries" with a wave of the hand.
To summarize, his answer was:
"systemd can work only as PID1, you are out of spec, we do not support
openvz, good luck".

Obviously, he didn't understand I wasN'T trying to run systemd on an
openvz kernel,
but rather on a plain 3.9.4 kernel neither was I requesting help to
have FC18 running inside the container,
I was rather pointing difficulties with systemd not able to cope with
"hostiles conditions" init process duty. Troubles are by definition
always 'out of spec'.

The part about "systemd can only works as PID1" increased my concerns
by an order of magnitude.
I ended up asking myself 'what part of this puzzle am I missing?',
I digged around in Google about systemd and I was stunned by results, I found
my concerns were already expressed multiple time with more talented
words than mine
and this as early as 2010. Since that time it is my understanding
systemd continuously try to resolve problems
by increasing its complexity and extending its dependencies and its
centrality.

this is wrong, this is very very wrong.
A pro

Announcing the release of Fedora 19!

[Robyn Bergeron]

The Fedora Project is delighted to announce the release of Fedora 19 
("Schrödinger's Cat"). Open the box and take a look for yourself!

Fedora is a leading-edge, free and open source operating system that continues 
to deliver innovative features to many users, with a new release about every 
six months.

Download it now:

http://fedoraproject.org/get-fedora

Detailed information about this release can be seen in the release notes:
http://docs.fedoraproject.org/en-US/Fedora/19/html/Release_Notes/

** What's New in Fedora 19? **

The Fedora Project takes great pride in being able to show off features for all 
types of use cases, including traditional desktop users, systems 
administration, development, the cloud, and many more. But a few new features 
are guaranteed to be seen by nearly anyone installing Fedora and are 
improvements that deserve to be called out on their own.

A complete list with details of each new feature is available here:
http://fedoraproject.org/wiki/Releases/19/FeatureList

== Make new things ==

Would you like to play? Whether you're a developer, maker, or just starting to 
learn about open source development, we have what you need to bring your ideas 
to reality. Here's a peek at some of our new tools:

* Developer's Assistant is a tool for new developers that helps you to get 
started on a code project by offering templates, samples, and toolchains for a 
variety of languages. And when you're finished, you can publish directly to 
GitHub! 

* 3D modelling and printing are supported with OpenSCAD, Skeinforge, SFACT, 
Printrun, RepetierHost, and other tool options. Get printing without having to 
download binary blobs or run Python code from git. 

* OpenShift Origin makes it easy for you to build your own 
Platform-as-a-Service (PaaS) infrastructure, allowing you to enable others to 
easily develop and deploy software.

* node.js is a popular Javascript-based platform for those building scalable 
network applications or real-time apps across distributed devices. 

* Ruby 2.0.0 moves into Fedora but keeps source-level backwards compatibility 
with your Ruby 1.9.3 software. We're also giving you a custom Ruby loader to 
use to easily switch interpreters.

* MariaDB offers a truly open MySQL implementation and is now the default MySQL 
option in Fedora.

== Deploy, Monitor, and Manage ==
You don't have to work so hard when your machines are doing it for you. 
Regardless of how many you have, Fedora 19 helps you boot-manage your systems 
and gives you the tools you need for diagnosis, monitoring, and logging.

* systemd Resource Control is one of many systemd enhancements in this release. 
It lets you modify your service settings without a reboot by dynamically 
querying and modifying resource control parameters at runtime. 

* Kerberos administrators no longer need their clients to sync their clocks or 
to have reverse DNS records carefully setup for services. Fedora 19 also 
includes Kerberos-enabled, LDAP replicated, two-factor authentication for 
FreeIPA. 

* Checkpoint & Restore lets you checkpoint and restore a process. It is useful 
for issues like process failure or moving a process to another machine for 
maintenance or load balancing. 

* OpenLMI is a common infrastructure for the management of Linux systems that 
makes remote management of machines much simpler. 

== Desktop Environments and Spins ==

GNOME 3.8 brings new applications such as clock and improvements to the desktop 
including privacy and sharing settings, ordered search, frequent applications 
overview, and additionally provides the ability to enable GNOME Classic 
("classic mode") for a user experience similar to GNOME 2 built out of a 
collection of GNOME Shell extensions.  Refer to 
https://help.gnome.org/misc/release-notes/3.8/ for more details. 

KDE Plasma Workspaces 4.10: A modern, stable desktop environment, KDE Plasma 
Workspaces 4.10 includes new features for printing and screenlocking, better 
indexing of files, and improved accessibility features.  Refer to 
http://www.kde.org/announcements/4.10/ for more details. 

MATE Desktop 1.6 introduces a large number of improvements to this traditional, 
GNOME 2-like desktop interface. Refer to 
http://mate-desktop.org/2013/04/02/mate-1-6-released/ for more details.

== Spins ==
Spins are alternate versions of Fedora.  In addition to various desktop 
environments for Fedora, spins are also available as tailored environments for 
various types of users via hand-picked application sets or customizations. 

Interest-specific Spins include the Design Suite Spin, the Robotics Spin, and 
the Security Spin, among others. Other available desktop environments, in 
addition to the GNOME 3.8 desktop which is shipped in the default version of 
Fedora 19, as well as those highlighted above, Xfce, Sugar on a Stick, and LXDE.

To see all of the Official Fedora 19 Release Spins, visit:
http://spins.fedoraproject.org 
 
Nightly composes of alternate Spins are available her

Re: More unhelpful update descriptions

[Ryan Lerch]

On Mon 01 Jul 2013 05:54:37 PM EDT, Dan Mashal wrote:

On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten  wrote:

Not sure if it makes any sense but maybe could we have something like
"freeze tag changes until desc is better".

I propose this because testers will not _really_ want to -1 karma, and
as a maintainer it might be a bit hard, but with a good reminder like
"not pushed to stable until desc is better" I would have made less
mistakes

yes not being reminded is not an excuse and such proposal would not save
time, still I believe it could help more than hurt



There is already a perfect example of this.

https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19

Dan


is it possible for not the maintainer to be able to edit the update 
text of updates? I'm thinking, say, a member of the documentation team?


regards,
ryanlerch
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: XEN and Fedora-19 domU

[Dario Faggioli]

On gio, 2013-06-27 at 13:35 +0200, Marcel J.E. Mol wrote:
> Either way is fine for me. I think it just good that xen works ok with f19, 
> as dom0 or as domU.
> 
Indeed, and it does quite well, as per mine and Konrad's testing, with
the fixes proposed in the bugreports Adam was mentioning, one of which
is your patch (thanks again).

Also, sorry for noticing this only now... I future, feel free to Cc me
and/or Konrad, and/or the xen@ (x...@lists.fedoraproject.org) mailing
list for Xen on Fedora related stuff. :-)

Regards,
Dario

-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



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

rawhide report: 20130702 changes

[Fedora Rawhide Report]

Compose started at Tue Jul  2 08:15:03 UTC 2013

Broken deps for x86_64
--
[avgtime]
avgtime-0-0.6.git20130201.fc20.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[contour]
contour-0.3-2.fc19.x86_64 requires libsolidcontrolifaces.so.4()(64bit)
contour-0.3-2.fc19.x86_64 requires libsolidcontrol.so.4()(64bit)
[derelict]
derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod
derelict-tcod-3-20.20130626gite70c293.fc20.x86_64 requires tcod
derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod
derelict-tcod-devel-3-20.20130626gite70c293.fc20.x86_64 requires tcod
[ekiga]
ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit)
[evolution-rss]
1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeutil.so()(64bit)
1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeshell.so()(64bit)
[gdb-heap]
gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17
[gnuplot]
gnuplot-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit)
gnuplot-minimal-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[gtkd]
gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60
gtkd-2.0.0-29.20120815git9ae9181.fc18.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[jboss-as]
jboss-as-7.1.1-19.fc20.noarch requires cxf-common >= 0:2.6.3
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[koji]
koji-vm-1.8.0-1.fc20.noarch requires python-virtinst
[kyua-cli]
kyua-cli-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit)
kyua-cli-tests-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit)
[lancet]
lancet-1.0.1-6.fc19.noarch requires ant-nodeps >= 0:1.7.1
[openbox]
gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel
gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires 
gnome-panel
[openlierox]
openlierox-0.59-0.11.beta10.fc20.x86_64 requires libgd.so.2()(64bit)
[ovirt-engine]
ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires 
classpathx-mail
[ovirt-guest-agent]
ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires 
libgdmsimplegreeter.so.1()(64bit)
[oyranos]
oyranos-libs-0.4.0-7.fc19.i686 requires libraw.so.5
oyranos-libs-0.4.0-7.fc19.x86_64 requires libraw.so.5()(64bit)
[perl-Bio-ASN1-EntrezGene]
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
[perl-Bio-SamTools]
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires 
perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq)
[perl-PDL]
perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit)
[python-TraitsBackendQt]
python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI
[rubygem-openshift-origin-common]
rubygem-openshift-origin-common-1.8.10-1.fc20.noarch requires 
rubygem(safe_yaml)
[rubygem-openshift-origin-node]
rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires 
rubygem(safe_yaml)
rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires 
openshift-origin-node-proxy
[rubygem-qpid]
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidtypes.so.1()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires 
libqpidmessaging.so.3()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidcommon.so.5()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidclient.so.5()(64bit)
[sagemath]
sagemath-core-5.9-5.fc20.i686 requires libgd.so.2
sagemath-core-5.9-5.fc20.x86_64 requires libgd.so.2()(64bit)
[scala]
scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library)
[spacewalk-web]
spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup)
[spring]
spring-94.1-1.fc20.x86_64 requires libassimp.so.2()(64bit)
[sumwars]
sumwars-0.5.6-12.fc20.x86_64 requires libenet-1.3.7.so()(64bit)
[tango]
tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60
tango-2-12.20120821git7b92443.fc19.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[vfrnav]
vfrnav-20130510-1.fc20.x86_64 requires libpolyclipping.so.8()(64bit)
vfrnav-utils-20130510-1.fc20.x86_64 requires 
libpolyclipping.so.8()(64bit)
[zarafa]
libmapi-7.0.13-1.fc19.i686 requires libicalss.so.0
libmapi-7.0.13-1.fc19.i686 requires libical.so.0
libmapi-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit)
libmapi-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit)
php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64
zarafa-ical-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit)
zarafa-ical-7.0.13-1.fc19

Re: Fedora Gooey Karma as GSOC project

[Kamil Paral]

> Hi,
> 
> On Wed, Jun 05, 2013 at 06:48:55PM +0200, Branislav Blaskovic wrote:
> 
> > My proposal [1] is available on fedoraproject wiki page where you can find
> > main features of this new tool.
> 
> > If you have any questions, please feel free to contact me here on mailing
> > list, off-list or br...@freenode.org.
> > 
> > [1]
> > https://fedoraproject.org/wiki/GSOC_2013/Student_Application_Blaskovic/Fedora_Gooey_Karma%284111%29
> 
> is this planned to be a replacement or an alternative to the command
> line tool?

An alternative.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reminder: Change Proposals Submission Deadline in two weeks

[Jaroslav Reznik]

Hi,
Change Proposals Submission Deadline is coming soon, in two weeks [1] - 
2013-07-16 - and there are only a few submissions (with only two system
wide changes accepted). Help us with Fedora 20 planning and development 
coordination!

See https://fedoraproject.org/wiki/Changes/Policy for current policy for
submissions and start a new proposal using this template
https://fedoraproject.org/wiki/Changes/EmptyTemplate

Let me know in case of any issues. Btw. I'm a bit behind with postponed 
Features migration, any help from the owners is welcomed!

[1] https://fedoraproject.org/wiki/Releases/20/Schedule

Thank you (and another thank you goes for Fedora 19 Features - we are
ready to release today ;-).

Jaroslav
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: find-lang.sh search path

[Michael Schwendt]

On Mon, 01 Jul 2013 23:28:00 +0200, Antonio Trande wrote:

> >> "pl" is the file name without extension (pl.qm). In .spec file:
> >> 
> >> ... %find_lang pl --with-qt %find_lang ru --with-qt ...
> >> 
> >> Are they correct ?
> > 
> > No.
> > 
> > Multiple invocations of %find_lang is a consecutive fault after
> > installing the locale files wrongly. You would run %find_lang once
> > only and give it the common name of the files to search for. Most
> > often that is the package %{name}:
> > 
> > https://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files
> 
> Indeed,
> > 
> but in this case locale files are not named %{name} and I
> don't know why language files (pl.qm and ru.qm) are not found. :)
> Also indicating just one file, I obtain ever same error.

Then let's not hack the paths, but find out why %find_lang doesn't
find the files. If %name is not part of the filenames, normally you
would need to add option --all-name, but there's a bug in RPM which
I've reopened: https://bugzilla.redhat.com/729336

-- 
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.8-300.fc19.x86_64
loadavg: 0.31 0.89 0.57
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel