Re: Screen blackened

[David Beveridge]

On Sat, Sep 7, 2013 at 12:18 AM, Richard Vickery <
richard.vicker...@gmail.com> wrote:

> On Sep 5, 2013 7:12 PM, "David Beveridge"  wrote:
> >
> > On Thu, Sep 5, 2013 at 10:02 PM, Frankie Onuonga <
> frankie.onuo...@gmail.com> wrote:
> >>
> >> On Thu, Sep 5, 2013 at 8:33 AM, Samuel Sieb  wrote:
> >>>
> >>> On 09/04/2013 08:07 PM, Frankie Onuonga wrote:
> 
>  It is irritating to constantly have to adjust on every boot.
>  I think we need to work on it for sure.
> >>>
> >>> Try the kernel parameter I suggested earlier:
> >>> video.use_bios_initial_backlight=0
> >>
> >> tried it.
> >> Does not work for me.
> >
> >
> > nor me.  But I can just adjust the brightness on each boot with a 2
> finger keypress.
> > Seemed to appear when the kernel went to 3.10.x
> >
> Which keys?
>
> fn - F6 (more brightness symbol)
-- 
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: Default boot/root filesystem

[Ken Dreyer]

On Fri, Sep 6, 2013 at 8:41 PM, Chris Adams  wrote:
> Once upon a time, Sam Varshavchik  said:
>  I could certainly have been out of town, for a while, and missed
>> this. But, to the best of my knowledge, Fedora uses ext4 as the
>> default boot/root. Just sounds a bit strange to me, that this is
>> getting dumped into RHEL without tossing it into Fedora first, to
>> rattle around, and shake any bugs out, beforehand. Don't really have
>> an opinion either way, myself, I would just expect that something
>> like this would go into Fedora first.
>
> RHEL is a derivative downstream of Fedora but distinct from Fedora, not
> just "Fedora with support".  RHEL makes decisions that are not the same
> as Fedora's (that's one of the reasons the "Fedora is RHEL beta" meme is
> st00pid).  Not everything in RHEL is the same as it was in the Fedora
> version from which it was branched.

Sure, RHEL is distinct from Fedora, and they make different decisions,
etc. The original point still stands: it's puzzling that XFS may end
up as the default in RHEL 7 when it has never been the default for
even a single Fedora release.

The "Fedora is RHEL beta" meme may be slightly off-base, but I would
hardly call the meme st00pid. The meme persists so strongly because
there's an element of truth to it. Besides, why else would Red Hat
pour so much money into Fedora :)

- Ken
-- 
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: Default boot/root filesystem

[Rahul Sundaram]

Hi


On Fri, Sep 6, 2013 at 6:48 PM, Sam Varshavchik wrote:

> According to this:
>
> http://www.serverwatch.com/**server-news/where-is-red-hat-**
> enterprise-linux-7.html
>
> RHEL7 will use XFS for the default boot/root.
>
> I could certainly have been out of town, for a while, and missed this.
> But, to the best of my knowledge, Fedora uses ext4 as the default
> boot/root. Just sounds a bit strange to me, that this is getting dumped
> into RHEL
>

It didn't get dumped into RHEL.  Red Hat has been working on XFS for a very
long time and I assume they have gained enough experience and run enough
tests to be confident about their decisions.  You don't have to make it
default in Fedora in order for Red Hat to be able to use it that way for
the purpose of RHEL.   There are dozens and dozens of things that Red Hat
has introduced into RHEL first or changed the defaults from Fedora (postfix
instead of sendmail,  GFS,  GNOME Classic mode by default etc) and this is
just one of them.

If you steadfastly believed that Fedora is just a beta or whatever, then
you should be very surprised but otherwise this is just a routine thing.

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: Default boot/root filesystem

[Chris Adams]

Once upon a time, Sam Varshavchik  said:
 I could certainly have been out of town, for a while, and missed
> this. But, to the best of my knowledge, Fedora uses ext4 as the
> default boot/root. Just sounds a bit strange to me, that this is
> getting dumped into RHEL without tossing it into Fedora first, to
> rattle around, and shake any bugs out, beforehand. Don't really have
> an opinion either way, myself, I would just expect that something
> like this would go into Fedora first.

RHEL is a derivative downstream of Fedora but distinct from Fedora, not
just "Fedora with support".  RHEL makes decisions that are not the same
as Fedora's (that's one of the reasons the "Fedora is RHEL beta" meme is
st00pid).  Not everything in RHEL is the same as it was in the Fedora
version from which it was branched.

In this case, Red Hat has been pushing XFS as the "high-end" FS for RHEL
for years, although they sold it as an add-on (I can't remember if it is
even supported for the root FS in the installer).  They've been
supporting it as the preferred FS for large filesystems and some other
cases, so I assume they know what they are doing.

Fedora is looking to the future, and rather than switching to something
that is just another traditional FS (with some bells and whistles),
switching to btrfs.  The switch to btrfs as default isn't there yet, but
that is the direction I think Fedora is moving towards (one of these
days).

-- 
Chris Adams 
-- 
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: .lz sources?

[Susi Lehtola]

On Thu, 5 Sep 2013 18:18:47 -0500
Dennis Gilmore  wrote:
> Please also be very careful. I will have to update rpkg to know
> that .lz files need to be uploaded to the lookaside cache. it has a
> list of file extentions to upload to lookaside, if you are not super
> careful you could see yourself commiting the tarball to git.

What do you mean? Is there supposed to be some safeguard to prevent this
from happening? A new sponsoree of mine had no problems uploading
a .tar.gz to git a few months ago...
-- 
Susi Lehtola
Fedora Project Contributor
jussileht...@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

[389-devel] please review: Ticket 411 - RFE - modification optimizer

[Mark Reynolds]

https://fedorahosted.org/389/ticket/411

https://fedorahosted.org/389/attachment/ticket/411/0001-Ticket-411-RFE-mods-optimizer.patch

--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreyno...@redhat.com

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

Re: Fedora/Redhat and perfect forward secrecy

[Gregory Maxwell]

On Fri, Sep 6, 2013 at 2:31 PM, D. Hugh Redelmeier  wrote:
> | From: Reindl Harald 
> | Date: Sat, 24 Aug 2013 11:38:21 +0200
>
> | https://bugzilla.redhat.com/show_bug.cgi?id=3D319901
> |
> | looks like Redhat based systems are the only remaining
> | which does not support EECDHE which is a shame these
> | days in context of PRISM and more and more Ciphers
> | are going to be unuseable (BEAST/CRIME weakness)
>
> It might be the case that the NSA has their fingers in these ECC
> standards.
>
> Here's a Schneier article worth reading:
>   
> 
>
> In it, he recommends (among many other things):
>
> Prefer conventional discrete-log-based systems over elliptic-curve
> systems; the latter have constants that the NSA influences when
> they can.
>
> It could be (by accident) that Fedora is more secure due to patents!

The P-256r curve commonly used for ECDH the web has it's parameters
generated by a nothing-up-my-sleeve CSPRNG approach.  I doubt Bruce
was speaking of that... it he was, I think thats a pretty audacious
claim that requires some justification.

Regardless, I think that argument would be an ignorant one:
Approximately no one runs non-ECDH PFS on the web: it's insanely slow
and it breaks clients.  The choice is not between ECDH and RSA based
PFS, the choice is between ECDH and no PFS at all.  Right now Fedora
webservers have no PFS at all.  This can not be argued to be an
improvement.
-- 
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: 19 (Schrödinger’s Cat)

[Rahul Sundaram]

Hi


On Fri, Sep 6, 2013 at 6:17 PM, Reindl Harald wrote:

> don't get me wrong but i expect bugs viewable at every single boot
> as fixed without a specific report a
>

http://www.redhat.com/magazine/020jun06/features/bugzilla/

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

[perl-NetPacket/f18] (4 commits) ...Update to 1.4.1

[Jose Pedro Oliveira]

Summary of changes:

  a7b2ce5... Perl 5.18 rebuild (*)
  d875d86... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*)
  bde33ab... Update to 1.4.0 (*)
  36aa0c5... Update to 1.4.1 (*)

(*) This commit already existed in another branch; no separate mail sent
--
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

Default boot/root filesystem

[Sam Varshavchik]

According to this:

http://www.serverwatch.com/server-news/where-is-red-hat-enterprise-linux-7.html

RHEL7 will use XFS for the default boot/root.

I could certainly have been out of town, for a while, and missed this. But,  
to the best of my knowledge, Fedora uses ext4 as the default boot/root. Just  
sounds a bit strange to me, that this is getting dumped into RHEL without  
tossing it into Fedora first, to rattle around, and shake any bugs out,  
beforehand. Don't really have an opinion either way, myself, I would just  
expect that something like this would go into Fedora first.




pgp4H_2cXTN7C.pgp
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

[perl-Path-Tiny] Created tag perl-Path-Tiny-0.032-1.fc21

[Paul Howarth]

The lightweight tag 'perl-Path-Tiny-0.032-1.fc21' was created pointing to:

 903ae30... Update to 0.032
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: 19 (Schrödinger’s Cat)

[Reindl Harald]

Am 06.09.2013 20:26, schrieb Darryl L. Pierce:
> On Thu, Sep 05, 2013 at 11:26:39PM +0200, Reindl Harald wrote:
>> Am 05.09.2013 23:11, schrieb Darryl L. Pierce:
>>> On Thu, Sep 05, 2013 at 10:11:51PM +0200, Reindl Harald wrote:
 * there is *nothing* in this configuration referring to the release name
>>>
>>> /boot/grub2/grub.cfg is generated via the grub2-mkconfig script, which
>>> uses settings from /etc/default/grub.
>>>
>>> /etc/default/grub uses the content from /etc/system-release to set the
>>> distributor value:
>>>
>>>   GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
>>>
>>> /etc/system-release contains the name of the Fedora release.
>>>
>>> Did you change either /etc/default/grub or grub2-mkconfig?
>>
>> i simply edited /boot/grub2/grub.cfg
>> and after that i expect *nothing* to add the release name
>> *but* a lter kernel updates is adding it again
>>
>> i am using Fedor since "Fedora Core 3" and i am maintaining
>> more than 20 fedora setups and *before* F19 nobody and nothing
>> touched "grub.cfg" due kernel update slike F19
>>
>> and as shown before GRUB_DISTRIBUTOR does *not* contain this crap
>> [root@testserver:~]$ cat /etc/default/grub | grep DISTR
>> GRUB_DISTRIBUTOR="Fedora"
>>
>> this file should not matter as in the past
> 
> Have your filed a BZ? What's the BZ#?

don't get me wrong but i expect bugs viewable at every single boot
as fixed without a specific report and to be honest not existing
at all by a wiser release-name selection or drop the useless
release-names at all



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

[perl-Tree-DAG_Node/f20] Update to 1.15

[Paul Howarth]

Summary of changes:

  bfb8d61... Update to 1.15 (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Fedora/Redhat and perfect forward secrecy

[D. Hugh Redelmeier]

| From: Reindl Harald 
| Date: Sat, 24 Aug 2013 11:38:21 +0200

| https://bugzilla.redhat.com/show_bug.cgi?id=3D319901
| 
| looks like Redhat based systems are the only remaining
| which does not support EECDHE which is a shame these
| days in context of PRISM and more and more Ciphers
| are going to be unuseable (BEAST/CRIME weakness)

It might be the case that the NSA has their fingers in these ECC
standards.

Here's a Schneier article worth reading:
  


In it, he recommends (among many other things):

Prefer conventional discrete-log-based systems over elliptic-curve
systems; the latter have constants that the NSA influences when
they can.

It could be (by accident) that Fedora is more secure due to patents!
-- 
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: COPR

[Richard W.M. Jones]

On Fri, Sep 06, 2013 at 03:53:50PM -0400, Daniel J Walsh wrote:
> VM Wrapped with Svirt (SELinux), running a Container wrapped with SELinux,
> running mock...

I see we need another layer in libguestfs :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
-- 
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: COPR

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/06/2013 03:38 PM, Richard W.M. Jones wrote:
> On Fri, Sep 06, 2013 at 09:10:24PM +0200, 80 wrote:
>> No, it's less secure than kvm but it still provides better isolation than
>> a mere chroot.
> 
> It doesn't matter if it's more secure than a chroot, because that's not
> what we're talking about.  This is about whether you want 
> random-person-off-the-internet to upload any software they like and run it
> on your server, and you *do not* want to do that with either a chroot or a
> Linux container [even if OpenShift got away with it].
> 
> And ...
> 
>> Secure containers as dwalsh described is a worthy improvement.
> 
> ... SELinux labels will not make that situation any better, because an 
> exploit somewhere in the large kernel API bypasses SELinux.
> 
> Dan Walsh's two replies are much more nuanced than you understand.
> 
> Rich.
> 
> 
Yes in the hierarchy of Security, I would say.

VM Wrapped with Svirt (SELinux), running a Container wrapped with SELinux,
running mock...
VM Wrapped with Svirt (SELinux), running mock wrapped with SELinux
Container wrapped Selinux running mock
Mock wrapped with SELinux
Chroot
root access.

As many layers as you can get away with and still perform ok.  If we can get
VMs to start and
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIqMs4ACgkQrlYvE4MpobNd2wCgr4wQ1yQDeTI1rUekHUeO+SId
g3IAoN41bAHraRDyurIAxkkJXmWjkKlB
=laGL
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: .lz sources?

[Susi Lehtola]

On Fri, 6 Sep 2013 09:02:47 +0300
Ville Skyttä  wrote:
> On Thu, Sep 5, 2013 at 6:40 PM, Susi Lehtola
>  wrote:
> > investigating the FTBFS of ddrescue I noticed that upstream has
> > switched to releasing tarballs only in .lz compressed format. This
> > is currently not supported by rpmbuild.
> 
> Sure it is, at least in F-18+. It'll even work on EL6 because even
> though its rpmbuild doesn't support it, its tar handles lzipped
> tarballs transparently with just xf. But in any case you need
> "BuildRequires: lzip".

That's odd -- I could have sworn that it didn't work when I tried it on
Fedora 19. Looks like a heisenbug, now I don't see a problem anymore...
-- 
Susi Lehtola
Fedora Project Contributor
jussileht...@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: 19 (Schrödinger’s Cat)

[Sérgio Basto]

On Sex, 2013-09-06 at 10:18 +0200, Reindl Harald wrote: 
> 
> Am 06.09.2013 05:21, schrieb Matthew Garrett:
> > On Fri, Sep 06, 2013 at 12:33:40AM +0200, Reindl Harald wrote:
> > 
> >> whay is Fedora starting with this crap exatly with the
> >> release having a short-minded name with special chars
> >> not properly handeled by the whole OS?
> > 
> > You're sending email to the development mailing list, so you're 
> > presumably a developer. In which case, perhaps you'd be willing to spend 
> > the time that you're currently using to send angry mails to the list to 
> > improve grub's support for Unicode characters when using VGA text mode?
> 
> primary i send a mail to the devel-list because it is a fedora development
> problem making decisions for a release, find out very soon that this
> decision is technically problematic but insist on it and happy release
> 
> no idea how as a PHP developer i should change GRUB here nor the fact
> that F19 is ignoring my configurations and insists changing them

yep , grubby does install with his configuration .
vi /sbin/new-kernel-pkg
line 181
if [ -n "$banner" ]; then
title="$banner ($version)"
elif [ -f /etc/os-release ]; then
. /etc/os-release
title="$NAME ($version) $VERSION"
elif [ -f /etc/redhat-release ]; then
title="$(sed 's/ release.*$//' < /etc/redhat-release) ($version)"
else
title="Red Hat Linux ($version)"
fi 

I do know how set banner and I assume that is not set 
so next else if 
. /etc/os-release
you may change
title="$NAME ($version) $VERSION"  
to 
title="$NAME ($version)"
and you have your problem solved .

bottom line, this should be reported on bugzilla as an RFE , asking to
add to grubby a custom name ...

-- 
Sérgio M. B.

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

[Richard W.M. Jones]

On Fri, Sep 06, 2013 at 09:10:24PM +0200, 80 wrote:
> No, it's less secure than kvm but it still provides better isolation
> than a mere chroot.

It doesn't matter if it's more secure than a chroot, because that's
not what we're talking about.  This is about whether you want
random-person-off-the-internet to upload any software they like and
run it on your server, and you *do not* want to do that with either a
chroot or a Linux container [even if OpenShift got away with it].

And ...

> Secure containers as dwalsh described is a worthy improvement.

... SELinux labels will not make that situation any better, because an
exploit somewhere in the large kernel API bypasses SELinux.

Dan Walsh's two replies are much more nuanced than you understand.

Rich.


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
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: COPR

[80]

Le 6 sept. 2013 20:19, "Richard W.M. Jones"  a écrit :
>
> On Wed, Sep 04, 2013 at 04:29:27PM +0200, Lukas Zapletal wrote:
> > On Wed, Sep 04, 2013 at 09:04:10AM +0200, Miroslav Suchy wrote:
> > > Compare it to Copr and OBS approach, when package is build in VM and
> > > after that backend will retrieve the results from VM. So on builder
> > > (of OBS and COPR) is no sensitive information at all.
> >
> > Are we able to evaluate, how much slower this is? Currently Fedora Koji
> > is pretty fast, I usually get near-to-instant build pick-ups.
> >
> > I can imagine spawning a VM can be slower. At least when using full
> > QEMU/KVM. I see the point that containers/selinux and such technologies
> > can do better in here.
>
> Please measure this before making incorrect statements.
>
> I have done, and you should be able to boot up a Fedora VM in 3-5
> seconds on c.2010 Intel hardware (which is what libguestfs does).
> Alternately you can restore the VM from a saved image in even less
> time.
>
> There's no significant advantage to using containers for this.
> Containers are also *not* secure -- see Dan Berrange's reply a few
> days ago for the full details about that.
>

No,  it's less secure than kvm but it still provides better isolation than
a mere chroot.
Secure containers as dwalsh described is a worthy improvement.

> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
> Read my programming blog: http://rwmj.wordpress.com
> Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
> --
> 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: What to do with a noarch package that fails to build on ARM

[Andrew McNabb]

On Fri, Sep 06, 2013 at 10:31:55AM -0600, Kevin Fenzi wrote:
> 
> We have these: 
> https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
> that I can get you access to. 
> 
> I have some I want to make always available to packagers, but I am
> waiting on a firmware upgrade that will allow us to seperate out that
> traffic from all the other SOC's in that same chassis. 

That sounds like a fantastic resource for packagers.  Thanks a lot for
your help, which will hopefully make it possible to get this package
working again.

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
-- 
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: Screen blackened

[Frankie Onuonga]

On Fri, Sep 6, 2013 at 3:18 PM, Richard Vickery  wrote:

>
> On Sep 5, 2013 7:12 PM, "David Beveridge"  wrote:
> >
> > On Thu, Sep 5, 2013 at 10:02 PM, Frankie Onuonga <
> frankie.onuo...@gmail.com> wrote:
> >>
> >> On Thu, Sep 5, 2013 at 8:33 AM, Samuel Sieb  wrote:
> >>>
> >>> On 09/04/2013 08:07 PM, Frankie Onuonga wrote:
> 
>  It is irritating to constantly have to adjust on every boot.
>  I think we need to work on it for sure.
> >>>
> >>> Try the kernel parameter I suggested earlier:
> >>> video.use_bios_initial_backlight=0
> >>
>
Even more odd is that when i send output to my external monitor and put a
video on full screen the funs scream like the processor is doing so much
work.
Odd thing is it is not a HD clip. I have probably thrown worse a this
machine but fun does not come up that heavily.
Anyway such is such.



> >> tried it.
> >> Does not work for me.
> >
> >
> > nor me.  But I can just adjust the brightness on each boot with a 2
> finger keypress.
> > Seemed to appear when the kernel went to 3.10.x
> >
> Which keys?
>
>
> --
> 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: COPR

[Richard W.M. Jones]

On Wed, Sep 04, 2013 at 04:29:27PM +0200, Lukas Zapletal wrote:
> On Wed, Sep 04, 2013 at 09:04:10AM +0200, Miroslav Suchy wrote:
> > Compare it to Copr and OBS approach, when package is build in VM and
> > after that backend will retrieve the results from VM. So on builder
> > (of OBS and COPR) is no sensitive information at all.
> 
> Are we able to evaluate, how much slower this is? Currently Fedora Koji
> is pretty fast, I usually get near-to-instant build pick-ups.
> 
> I can imagine spawning a VM can be slower. At least when using full
> QEMU/KVM. I see the point that containers/selinux and such technologies
> can do better in here.

Please measure this before making incorrect statements.

I have done, and you should be able to boot up a Fedora VM in 3-5
seconds on c.2010 Intel hardware (which is what libguestfs does).
Alternately you can restore the VM from a saved image in even less
time.

There's no significant advantage to using containers for this.
Containers are also *not* secure -- see Dan Berrange's reply a few
days ago for the full details about that.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
-- 
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: 19 (Schrödinger’s Cat)

[Darryl L. Pierce]

On Thu, Sep 05, 2013 at 11:26:39PM +0200, Reindl Harald wrote:
> Am 05.09.2013 23:11, schrieb Darryl L. Pierce:
> > On Thu, Sep 05, 2013 at 10:11:51PM +0200, Reindl Harald wrote:
> >> * there is *nothing* in this configuration referring to the release name
> > 
> > /boot/grub2/grub.cfg is generated via the grub2-mkconfig script, which
> > uses settings from /etc/default/grub.
> > 
> > /etc/default/grub uses the content from /etc/system-release to set the
> > distributor value:
> > 
> >   GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
> > 
> > /etc/system-release contains the name of the Fedora release.
> > 
> > Did you change either /etc/default/grub or grub2-mkconfig?
> 
> i simply edited /boot/grub2/grub.cfg
> and after that i expect *nothing* to add the release name
> *but* a lter kernel updates is adding it again
> 
> i am using Fedor since "Fedora Core 3" and i am maintaining
> more than 20 fedora setups and *before* F19 nobody and nothing
> touched "grub.cfg" due kernel update slike F19
> 
> and as shown before GRUB_DISTRIBUTOR does *not* contain this crap
> [root@testserver:~]$ cat /etc/default/grub | grep DISTR
> GRUB_DISTRIBUTOR="Fedora"
> 
> this file should not matter as in the past

Have your filed a BZ? What's the BZ#?

-- 
Darryl L. Pierce 
http://mcpierce.fedorapeople.org/
"What do you care what people think, Mr. Feynman?"


pgpnnZPrBTRjw.pgp
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: Rawhide tree now includes install images

[Kevin Fenzi]

On Fri, 06 Sep 2013 11:24:38 +0200
poma  wrote:

> You've probably missed something in the title, so the correct one
> should be: "Rawhide tree now includes broken install images"
> Now, if someone is doing it just to fill the tree, for the sake of
> formality, thanks but no thanks.

Having daily composes of those images helps a great deal in seeing when
they are broken and fixing them. If we had no images we couldn't test
them at all. 

I advise you to investigate the failures and file bugs on them.
Sometimes things will be broken, thats why we test and get things
fixed. 

kevin




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: Rawhide tree now includes install images

[Lars Seipel]

On Fri, Sep 06, 2013 at 11:24:38AM +0200, poma wrote:
> You've probably missed something in the title, so the correct one should be:
> "Rawhide tree now includes broken install images"
> Now, if someone is doing it just to fill the tree, for the sake of
> formality, thanks but no thanks.

Why don't you find out what's broken then instead of ranting on the
list?

Lars
-- 
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: What to do with a noarch package that fails to build on ARM

[Kevin Fenzi]

On Fri, 6 Sep 2013 09:44:51 -0600
Andrew McNabb  wrote:

> I tried tracking down the problem using an ARM virtual machine using
> these instructions, but it was too slow in helping track down the
> failed tests (in fact, it had many more failed tests).
> 
> As a "temporary" measure, I then changed python-pexpect to no longer
> be a noarch package.  It looks like this will have a ripple effect,
> requiring python-ipython (an important package) to lose noarch.
> 
> At present, the upstream maintainer and myself have no way to track
> down the problem because no one has ARM hardware running Fedora.  So
> it could be a very long time before this is fixed.
> 
> Since ARM is a primary architecture but ARM hardware running Fedora is
> so rare, it would be nice if there were some way to give upstream
> maintainers access to ARM machines to track down bugs.

I just mailed you directly a few minutes ago about this. ;) 

We have these: 
https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
that I can get you access to. 

I have some I want to make always available to packagers, but I am
waiting on a firmware upgrade that will allow us to seperate out that
traffic from all the other SOC's in that same chassis. 

kevin


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: What to do with a noarch package that fails to build on ARM

[Andrew McNabb]

On Tue, Aug 20, 2013 at 04:19:27PM -0500, Andrew McNabb wrote:
> On Tue, Aug 20, 2013 at 10:13:10PM +0100, Peter Robinson wrote:
> > 
> > In terms of testing or debugging probably the easiest way is to spin up an
> > image under qemu emulation, it's not the fastest but it works pretty well.
> > If there's anything else I can help with feel free to ask.
> > 
> > http://fedoraproject.org/wiki/Architectures/ARM/F19/Installation#For_Versatile_Express_Emulation_with_QEMU
> 
> That's very good to know about, and it makes tracking this down seem
> less hopeless.

I tried tracking down the problem using an ARM virtual machine using
these instructions, but it was too slow in helping track down the failed
tests (in fact, it had many more failed tests).

As a "temporary" measure, I then changed python-pexpect to no longer be
a noarch package.  It looks like this will have a ripple effect,
requiring python-ipython (an important package) to lose noarch.

At present, the upstream maintainer and myself have no way to track down
the problem because no one has ARM hardware running Fedora.  So it could
be a very long time before this is fixed.

Since ARM is a primary architecture but ARM hardware running Fedora is
so rare, it would be nice if there were some way to give upstream
maintainers access to ARM machines to track down bugs.

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

EPEL xfce4 4.10.x xfce4-panel-4.10 el6 request

[PJ Welsh]

We seem to be running into an issue with the existing
xfce4-panel-4.8.3-2.el6. We seem to have the panel kernel panic crash
seeming related to xfce4-panel (homedir NFS + panel operation + andmaybe
Xen = random crash) on a fully updated CentOS 6.4. A couple of the (likely)
related bugs with the xfce4-panel-4.8.x era version include:
https://bugzilla.redhat.com/show_bug.cgi?id=827508
https://bugzilla.xfce.org/show_bug.cgi?id=7951

I would like to see if a re-basing to the xfce-4.10 is possible for the el6
based RPM's, please.

PJ
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: 19 (Schrödinger’s Cat)

[Reindl Harald]

Am 06.09.2013 05:21, schrieb Matthew Garrett:
> On Fri, Sep 06, 2013 at 12:33:40AM +0200, Reindl Harald wrote:
> 
>> whay is Fedora starting with this crap exatly with the
>> release having a short-minded name with special chars
>> not properly handeled by the whole OS?
> 
> You're sending email to the development mailing list, so you're 
> presumably a developer. In which case, perhaps you'd be willing to spend 
> the time that you're currently using to send angry mails to the list to 
> improve grub's support for Unicode characters when using VGA text mode?

primary i send a mail to the devel-list because it is a fedora development
problem making decisions for a release, find out very soon that this
decision is technically problematic but insist on it and happy release

no idea how as a PHP developer i should change GRUB here nor the fact
that F19 is ignoring my configurations and insists changing them





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

Re: Screen blackened

[Richard Vickery]

On Sep 5, 2013 7:12 PM, "David Beveridge"  wrote:
>
> On Thu, Sep 5, 2013 at 10:02 PM, Frankie Onuonga <
frankie.onuo...@gmail.com> wrote:
>>
>> On Thu, Sep 5, 2013 at 8:33 AM, Samuel Sieb  wrote:
>>>
>>> On 09/04/2013 08:07 PM, Frankie Onuonga wrote:

 It is irritating to constantly have to adjust on every boot.
 I think we need to work on it for sure.
>>>
>>> Try the kernel parameter I suggested earlier:
>>> video.use_bios_initial_backlight=0
>>
>> tried it.
>> Does not work for me.
>
>
> nor me.  But I can just adjust the brightness on each boot with a 2
finger keypress.
> Seemed to appear when the kernel went to 3.10.x
>
Which keys?
-- 
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: Dracut HostOnly or ConfigurationOnly?

[poma]

On 06.09.2013 11:38, Harald Hoyer wrote:
> On 09/06/2013 11:31 AM, Roberto Ragusa wrote:
>> On 09/06/2013 11:05 AM, poma wrote:
>>> On 05.09.2013 16:51, Harald Hoyer wrote:
>>>
 This Fedora release builds an initramfs tailored especially for your 
 computer
 hardware. If you change your machine or partitions or significant 
 hardware, you
 might have to boot with the "Rescue" boot entry and execute "dracut
 --regenerate-all". If you want your initramfs to be hardware independent,
 install the "dracut-nohostonly" rpm package. If you don't want rescue 
 images at
 all (like in virtual machines), install the "dracut-norescue" rpm package.

>>>
>>> Package over here, package over there.
>>> It's not so long ago called configuration.
>>> Now if we want to configure something, we install a package.
>>> Can someone package a pizza and send it here.
>>> Oh wait, I forgot about prosciutto.
>>> Install a prosciutto package, please.
>>
>> Using package installation as configuration is quite bizarre.
>>
>> Wasn't there a specific policy that installation and configuration
>> are two different things?
>> "You installed httpd, ok, so you have the stuff on your disk, but that
>> does not mean it will run at next reboot, you have to configure and
>> activate it explicitly".
>>
> 
> Well, because the initramfs was built in the %posttrans-action of the
> installation, pulling in the configuration to build a different kind of
> initramfs seemed the easiest way of doing kickstarts for me.
> 

If something is good for someone, why not recommend it to the others, right.
Urbi et Orbi.


poma


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

Fedora 20 schedule updates

[Jaroslav Reznik]

Hi,
as a few people has asked me for clarification - the schedule is on track,
we are Alpha frozen now from Sep 03. Based on FESCo decision [1], "no 
earlier than" part from official schedules has been already removed.

High level schedule: https://fedoraproject.org/wiki/Releases/20/Schedule
Detailed schedule: http://fedorapeople.org/groups/schedule/f-20/

For Fedocal - there's no way to import schedule automatically right now,
F19 was done manually by pingou. I'm going to add important milestones
there.

Jaroslav

[1] https://fedorahosted.org/fesco/ticket/1095


___
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
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dracut HostOnly or ConfigurationOnly?

[Jóhann B. Guðmundsson]

On 09/06/2013 10:15 AM, Jiri Eischmann wrote:

Can this not be done automatically? If the system fails to boot because
of significant hardware changes, it's an obvious option to regenerate
initramfs. I can't image a normal user go to the rescue mode and run
"dracut --regenerate-all". Not that it's difficult to do it, but the
discoverability of the solution is bad.


This has been discussed in the past and if we are going to head down 
that road we need a proper end user friendly UI rescue environment for 
the core/baseOS which automatically scans things for problem and 
proposes to fix that for the novice end user.


I'm pretty sure nobody is against this but as usual as someone has to do 
all that work...


JBG
--
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: Dell XPS 13 ("Sputnik") no longer working with fedora kernels >= 3.10

[Łukasz Jagiełło]

2013/9/5 Dennis Jacobfeuerborn 

> Working fine here.
>>
>> #v+
>> [root@p0x ~]# uname -a
>> Linux p0x 3.10.10-200.fc19.x86_64 #1 SMP Thu Aug 29 19:05:45 UTC 2013
>> x86_64 x86_64 x86_64 GNU/Linux
>> [root@p0x ~]# dmidecode | grep "Product Name"
>> Product Name: Dell System XPS L322X
>> #v-
>>
>
> Hm, what Firmware are you running (A07 here) and are you using UEFI?
>

 Version: A09

Yes, I'm using UEFI.

-- 
Łukasz Jagiełło
lukaszjagielloorg
-- 
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: AppData files in all application packages?

[Richard Hughes]

On 6 September 2013 11:16, Andrea Musuruane  wrote:
> As a first step to create such a database, can you reuse metadata avalable
> on Ohloh?

That's a good idea, but I suspect that mining all the data is a breach
of the acceptable use policy, and the licence of the data collected is
very unclear. It's also got quite a few Ohloh specific descriptions,
e.g. for Firefox: "If you stack this project, you should also stack
the Mozilla Core."

As a style note, it's a technical description, and for AppData there
are requirements on the kind of prose recommended, see
http://people.freedesktop.org/~hughsient/appdata/#description-format

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: Proposal: AppData files in all application packages?

[Andrea Musuruane]

Hi Richard,

On Fri, Sep 6, 2013 at 11:33 AM, Richard Hughes  wrote:

> Hi all. I'm the developer for PackageKit and gnome-software, the
> latter being the new software center we're hopefully including as a
> technical preview in Fedora 20.
>
> [...]
>
> At the moment, we use the information in the .desktop file to populate
> the AppStream data, but this is missing a few core things, for
> instance a long description, the upstream website for the application
> and any screenshots to show. All of the three being quite critical to
> assess an application before installing. To fix this I've created a
> tiny AppData specification [1] which is a subset of the AppStream
> specification. It's designed as a way to describe the application (not
> the package) so that data can be used in the AppStream data.
>

As a first step to create such a database, can you reuse metadata avalable
on Ohloh?

https://www.ohloh.net/p

It seems they already have much of what you need.

Bye,

Andrea.
-- 
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: Dracut HostOnly or ConfigurationOnly?

[Jiri Eischmann]

Harald Hoyer píše v Čt 05. 09. 2013 v 16:51 +0200:
> On 09/05/2013 04:10 PM, Vratislav Podzimek wrote:
> > Hello, everybody,
> > I'd like to know your opinion on one issue we have hit on live
> > installations due to the DracutHostOnly feature [1]. Long story short:
> > 1) Anaconda installs the kernel package
> > 2) installation of the kernel package triggers dracut to generate initrd
> > 3) dracut now generates so called "host-only" initrd, which, among the
> > other things, means, that it contains only one keymap -- the one that
> > was set in /etc/vconsole.conf at the time dracut was triggered to run
> > 4) Anaconda configures the installed system based on the values set
> > during the installation.
> > 
> > The actual result is that if users type in their LUKS password with a
> > keyboard layout different from 'us', let's say 'gb' they cannot type the
> > password again on boot, because the initrd has only the 'us' keymap (set
> > by default in the configuration file), even if there is
> > 'vconsole.keymap=gb' as a boot option. 
> > 
> > There are two basic approaches how to fix this on the installer side:
> > 1) write out keyboard configuration before packages are installed
> > 2) regenerate the initrd at the end of the installation
> > 
> > Both these solutions are not ideal from my point of view. And even if
> > one of them is accepted and applied, there would still be the problem
> > with systems, that have an initrd that blocks functionality of boot
> > options (maybe there are more than vconsole.keymap, I don't know).
> > 
> > So, is it a right thing to do to generate 3 MB smaller initrd's (the
> > summed up size of all keymaps) not supporting some boot options? Does
> > HostOnly mean the initrd works only with a specific host or that it
> > works only with a specific configuration of a specific host? I
> > understand having firmware for hardware that does not exist in the
> > system might be useless, but not supporting boot with a different
> > configuration options seems to me as a different thing.
> > 
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=994180
> > 
> 
> host only means, it only works on that machine (kernel modules) with that disk
> layout (including language and keymap for disk passwords).
> 
> https://fedoraproject.org/wiki/Features/DracutHostOnly#Release_Notes
> 
> This Fedora release builds an initramfs tailored especially for your computer
> hardware. If you change your machine or partitions or significant hardware, 
> you
> might have to boot with the "Rescue" boot entry and execute "dracut
> --regenerate-all".

Can this not be done automatically? If the system fails to boot because
of significant hardware changes, it's an obvious option to regenerate
initramfs. I can't image a normal user go to the rescue mode and run
"dracut --regenerate-all". Not that it's difficult to do it, but the
discoverability of the solution is bad.

Jiri

-- 
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: AppData files in all application packages?

[Elad Alfassa]

On Fri, Sep 6, 2013 at 12:33 PM, Richard Hughes  wrote:

> Hi all. I'm the developer for PackageKit and gnome-software, the
> latter being the new software center we're hopefully including as a
> technical preview in Fedora 20.
>
[snip]

>
> Thanks in advance!
>
> Richard
>
> [1] http://people.freedesktop.org/~hughsient/appdata/
> [2] https://github.com/hughsie/fedora-appstream/tree/master/appdata-extra
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

To add on Richard's notes, please note that we will appreciate testing,
suggestions, bug reports and general feedback.

Few more things I think you should know:

The metadata is DE-agnostic, which means that KDE (for example) could
implement their own software center using the same metadata as well, so by
adding appdata files you don't only help the GNOME spin of Fedora, but make
it possible for other desktops to use the same data for their own
application installers as well.


gnome-software is still in an early preview phase, so more features will be
added soon. (for example, an "addons" category to list fonts, codecs, and
so forth).

We already have someone working on support for firefox webapps, and I have
few more ideas in mind.
The pluggable architecture of gnome-software easily allows to add more
types of software sources - it's not just a frontend for packagekit!
We can easily add support for extensions from extensions.gnome.org,
or perhaps listing fedorapeople repos under the (not-yet-implemented)
addons category so people would be able to easily add them to their systems
without needing to use the CLI. (I still need to run this idea past the
designers for sanity-check).

I'm also trying to get in touch with Valve to make Steam integrate itself
into gnome-software (if installed).

We have been waiting for a proper app installer for years, and now it
finally happening. Exciting times ahead!

We need all the help we can get to make this as awesome as possible, so
please don't hesitate to contribute.

If you have already installed Fedora 20, go ahead and type "yum install
gnome-software" and give it a go!
-- 
-Elad Alfassa.
(elad661 on freenode, elad on gimpnet)
-- 
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: Dracut HostOnly or ConfigurationOnly?

[Harald Hoyer]

On 09/06/2013 11:31 AM, Roberto Ragusa wrote:
> On 09/06/2013 11:05 AM, poma wrote:
>> On 05.09.2013 16:51, Harald Hoyer wrote:
>>
>>> This Fedora release builds an initramfs tailored especially for your 
>>> computer
>>> hardware. If you change your machine or partitions or significant hardware, 
>>> you
>>> might have to boot with the "Rescue" boot entry and execute "dracut
>>> --regenerate-all". If you want your initramfs to be hardware independent,
>>> install the "dracut-nohostonly" rpm package. If you don't want rescue 
>>> images at
>>> all (like in virtual machines), install the "dracut-norescue" rpm package.
>>>
>>
>> Package over here, package over there.
>> It's not so long ago called configuration.
>> Now if we want to configure something, we install a package.
>> Can someone package a pizza and send it here.
>> Oh wait, I forgot about prosciutto.
>> Install a prosciutto package, please.
> 
> Using package installation as configuration is quite bizarre.
> 
> Wasn't there a specific policy that installation and configuration
> are two different things?
> "You installed httpd, ok, so you have the stuff on your disk, but that
> does not mean it will run at next reboot, you have to configure and
> activate it explicitly".
> 

Well, because the initramfs was built in the %posttrans-action of the
installation, pulling in the configuration to build a different kind of
initramfs seemed the easiest way of doing kickstarts for me.

This was done to avoid building the initramfs twice.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Proposal: AppData files in all application packages?

[Richard Hughes]

Hi all. I'm the developer for PackageKit and gnome-software, the
latter being the new software center we're hopefully including as a
technical preview in Fedora 20.

A few years ago distributions came together and created the AppStream
specification which was designed to be common between all
distributions and desktops. This data allowed us to describe
applications that were not yet installed, and also map them to package
names. The AppStream specification also allows us to include icons for
applications. Ubuntu and SuSE both adopted the standard, but for many
reasons Fedora didn't until now.

With this data means we can create a software center that looks as
good as the Chrome/Firefox store, but with all the existing
applications we have available to us in Fedora. It means we can give
people the software center they've been requesting for years. We're
not taking away yum/dnf/gnome-packagekit or any of the existing tools
that focus on packages, just adding a *new* application installer.

At the moment, we use the information in the .desktop file to populate
the AppStream data, but this is missing a few core things, for
instance a long description, the upstream website for the application
and any screenshots to show. All of the three being quite critical to
assess an application before installing. To fix this I've created a
tiny AppData specification [1] which is a subset of the AppStream
specification. It's designed as a way to describe the application (not
the package) so that data can be used in the AppStream data.

At the moment, about 50 upstream projects are already shipping AppData
files, and we've also got a few more which live in the fedora compose
tools repo [2] for 'featured' applications we want to look complete
for Fedora 20 launch. All the files in this repo have been submitted
upstream, so hopefully the number of "extra" files in that repo should
shrink to zero long term.

So, well done if you've read this far already. What I am asking all
you packagers for applications to do is:

 * Talk to the upstream maintainers, and try to convince them to write
and ship an .appdata.xml file -- this is the best option as it can be
translated in the future upstream, and the upstream maintainer can
control things like what screenshots are shipped. It also means the
data is shared with all the other distros.

* If your upstream is on life-support, dead, or just not interested in
shipping yet another file in the tarball you have two options. Either
ship an AppData file in the package itself, e.g. as a "Source2" and
install it in /usr/share/appdata in the RPM. If you do a build for f20
and make sure it's in before the F20 Beta then I'll automatically be
included in gnome-software. The other option is to submit a patch
against fedora-appstream itself, although I'd much prefer it in the
package as then you can make changes yourself if the project
description/screenshot changes.

In the context of AppStream, an application is a package that ships
one or more .desktop files, that include Name,Comment and also Icon. A
few applications are blacklisted if they are not included in the GUI
menus or if they are settings panels. For now it's quite restrictive,
but in the future we'll be considering other things as apps too, like
Chrome Store Apps and GNOME Shell Extensions.

Any questions, either grab me on irc 'hughsie' or reply to this email.
Be sure to read [1] as a lot of common questions are answered there.

Thanks in advance!

Richard

[1] http://people.freedesktop.org/~hughsient/appdata/
[2] https://github.com/hughsie/fedora-appstream/tree/master/appdata-extra
-- 
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: Dracut HostOnly or ConfigurationOnly?

[Roberto Ragusa]

On 09/06/2013 11:05 AM, poma wrote:
> On 05.09.2013 16:51, Harald Hoyer wrote:
> 
>> This Fedora release builds an initramfs tailored especially for your computer
>> hardware. If you change your machine or partitions or significant hardware, 
>> you
>> might have to boot with the "Rescue" boot entry and execute "dracut
>> --regenerate-all". If you want your initramfs to be hardware independent,
>> install the "dracut-nohostonly" rpm package. If you don't want rescue images 
>> at
>> all (like in virtual machines), install the "dracut-norescue" rpm package.
>>
> 
> Package over here, package over there.
> It's not so long ago called configuration.
> Now if we want to configure something, we install a package.
> Can someone package a pizza and send it here.
> Oh wait, I forgot about prosciutto.
> Install a prosciutto package, please.

Using package installation as configuration is quite bizarre.

Wasn't there a specific policy that installation and configuration
are two different things?
"You installed httpd, ok, so you have the stuff on your disk, but that
does not mean it will run at next reboot, you have to configure and
activate it explicitly".

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

Re: Rawhide tree now includes install images

[poma]

On 16.07.2013 18:53, Matthew Miller wrote:
> On Tue, Jul 16, 2013 at 10:41:22AM -0600, Kevin Fenzi wrote:
>> After consulting with various teams, release engineering has re-enabled
>> rawhide composes to create install images again. These images were
>> dropped as part of the 'no frozen rawhide' proposal several years ago. 
>> This allows users to use the latest boot.iso or pxe images to install
>> rawhide instances or point to rawhide as a install-able tree. 
> 
> This is awesome. Thanks Kevin!
> 

You've probably missed something in the title, so the correct one should be:
"Rawhide tree now includes broken install images"
Now, if someone is doing it just to fill the tree, for the sake of
formality, thanks but no thanks.


poma


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

Re: Dracut HostOnly or ConfigurationOnly?

[poma]

On 05.09.2013 16:51, Harald Hoyer wrote:

> This Fedora release builds an initramfs tailored especially for your computer
> hardware. If you change your machine or partitions or significant hardware, 
> you
> might have to boot with the "Rescue" boot entry and execute "dracut
> --regenerate-all". If you want your initramfs to be hardware independent,
> install the "dracut-nohostonly" rpm package. If you don't want rescue images 
> at
> all (like in virtual machines), install the "dracut-norescue" rpm package.
> 

Package over here, package over there.
It's not so long ago called configuration.
Now if we want to configure something, we install a package.
Can someone package a pizza and send it here.
Oh wait, I forgot about prosciutto.
Install a prosciutto package, please.


poma


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

Re: Dracut HostOnly or ConfigurationOnly?

[Vratislav Podzimek]

On Thu, 2013-09-05 at 15:52 +, "Jóhann B. Guðmundsson" wrote:
> On 09/05/2013 02:44 PM, Harald Hoyer wrote:
> > I concur and say:
> > 1) write out keyboard configuration before packages are installed
> > 1b) write out language configuration before packages are installed
> 
> Had we narrowed it down to only keyboard/language configuration since I 
> vaguely recall coming across other type of bugs that required initramfs 
> re-genartion straight after install to fix.
That's why I think re-generating initrd would be a better and more solid
solution, hopefully effective for a long time.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

-- 
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: Dracut HostOnly or ConfigurationOnly?

[Vratislav Podzimek]

On Thu, 2013-09-05 at 10:17 -0500, Michael Catanzaro wrote:
> On Thu, 2013-09-05 at 14:25 +, "Jóhann B. Guðmundsson" wrote:
> > On 09/05/2013 02:10 PM, Vratislav Podzimek wrote:
> > > 2) regenerate the initrd at the end of the installation
> > 
> > This is what should be done both for live and regular installs.
> > 
> > JBG
> > 
> The LUKS password issue is pretty serious.  Anyone know if there is a
> bug report for this?
https://bugzilla.redhat.com/show_bug.cgi?id=994180

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

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