date:20130909


On 09/09/2013 11:48 AM, Kamil Paral wrote:

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

It should have been a prerequisite for dracut host-only feature.


It's nonsense having an full blown rescue environment as an requirement 
for dracut-hostonly feature.


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: Retiring libeio

2013-09-09 Thread Paul Howarth


On 08/09/13 08:48, Michael Schwendt wrote:

On Sat, 7 Sep 2013 18:03:48 -0700, T.C. Hollingsworth wrote:


I adopted libeio back when Node.js still bundled it to aid in the unbundling
effort, but upstream "fixed" the bundling problem here by no longer using
libeio for anything.


That explains a bit more!

libeio is bundled within perl-IO-AIO at Fedora

   http://search.cpan.org/~mlehmann/IO-AIO-4.18/AIO.pm

and is built as a private AIO.so lib.

I've tried to find out why there haven't been any libeio releases to download,
although it's at version 4.18 already. The home page says it's Beta. The cvs
snapshot contains doc files that refer to libev (that one is at 4.15), which
is a separate package (also at Fedora). The source also bundles ecb.h, which
refers to libecb from the same author. That's "libecb" at Fedora.


I'd be quite happy if someone would take perl-IO-AIO off my hands. My 
only interest in it is as an (optional) backend and test dependency of 
perl-AnyEvent, which I co-maintain - I picked it up when a previous 
maintainer orphaned it.


If someone is keen to look after the bundling issue, I'll be happy to 
hand over the package. Otherwise, it looks like a lot of hassle and I'll 
probably end up orphaning it and letting nature take its course.


Paul.

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

[Bug 1005669] perl-HTTP-Body: remote command-injection flaw in HTTP::Body::Multipart versions 1.08 and later

2013-09-09 Thread bugzilla

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
External Bug ID||CPAN 88342



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

Re: Default boot/root filesystem

2013-09-09 Thread Josef Bacik

On Sat, Sep 7, 2013 at 6:40 PM, "Jóhann B. Guðmundsson"
 wrote:
> On 09/07/2013 10:35 PM, Eric Sandeen wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 9/6/13 5: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 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.
>>
>> If people want to switch the Fedora default to XFS, I'll gladly file
>> the feature.  :)
>>
>
> Given that we could not kill lvm as an default and switch to ext4 until
> btrfs was in ready enough shape to improve the desktop experience I doubt
> that feature would pass the acks of the shadow of the storage and filesystem
> monks that appeared from nowhere at that time...
>
> In a 21 century distro the sub community would decide which default
> filesystem would be their preference to deliverer the best out of the box
> experience for their product but hey rings to rule them all and hobbits too.
>

I'd like to see this become a reality, that way I don't have to deal
with the bureaucracy that is the fedora feature process to make btrfs
the default, I can just make my own spin for people who want to try it
out and when it becomes stable enough the other spins can integrate it
if they so choose.  Thanks,

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

On 09/09/2013 02:35 PM, Josef Bacik wrote:

>In a 21 century distro the sub community would decide which default
>filesystem would be their preference to deliverer the best out of the box
>experience for their product but hey rings to rule them all and hobbits too.
>

I'd like to see this become a reality, that way I don't have to deal
with the bureaucracy that is the fedora feature process to make btrfs
the default, I can just make my own spin for people who want to try it
out and when it becomes stable enough the other spins can integrate it
if they so choose.  Thanks,

The ring proposal is made up of the old outdated mentality so I'm not 
seeing that dream becoming reality but I dont think there is actually 
anything to prevent this from a technical point of view ( as in 
limitation in anaconda/lorax )

The Desktop sig cannot do this and KDE probably not since those are 
release blocking desktop however the Gnome SIG might as well as the 
other spins.

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

PostgreSQL 9.3 in Fedora 20?

2013-09-09 Thread Michał Piotrowski

Hi,

I know that currently Fedora 20 is in feature freeze state. But Alpha
version is still not released and PosgreSQL developers released new latest
and greates version
http://www.postgresql.org/docs/9.3/static/release-9-3.html with cool
features. Are there chances to get this version for F20?

-- 
Best regards,
Michal

http://eventhorizon.pl/
-- 
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

2013-09-09 Thread Till Maas

On Sat, Sep 07, 2013 at 05:35:05PM -0500, Eric Sandeen wrote:

> If people want to switch the Fedora default to XFS, I'll gladly file
> the feature.  :)

Why is XFS better than ext4. When I checked a few months ago, XFS did
not even support shrinking, but only growing. Even now there seems to be
only xfs_growfs on F19, but no tool to shrink it.

Regards
Till
-- 
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: PostgreSQL 9.3 in Fedora 20?

2013-09-09 Thread Bruno Wolff III


On Mon, Sep 09, 2013 at 17:19:54 +0200,
  Michał Piotrowski  wrote:

Hi,

I know that currently Fedora 20 is in feature freeze state. But Alpha
version is still not released and PosgreSQL developers released new latest
and greates version
http://www.postgresql.org/docs/9.3/static/release-9-3.html with cool
features. Are there chances to get this version for F20?


Database guys are pretty conservative. Based on the past (though Tom 
isn't doing the updates for Fedora any more), the release needed to be 
out before beta. Currently there is just an RC for 9.3, so it may or may not 
end up being released before F20 beta. Normally the postgres maintainer 
hasn't gambled on a release happening and built postgres RCs or Betas 
for rawhide hoping that things don't slip.

--
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: Fedora/Redhat and perfect forward secrecy



Am 09.09.2013 12:55, schrieb Florian Weimer:
> On 09/09/2013 11:58 AM, Andrew Haley wrote:
>> On 09/07/2013 12:52 AM, Gregory Maxwell wrote:
>>> 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.
>>
>> Hmm.  Isn't non-ECDH PFS just straight integer (mod N) Diffie-Hellman?
> 
> Yes, it is.
> 
>> And that's what is insanely slow?
> 
> I don't get it, either

google "dhe versus ecdhe performance"

http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
>> Let’s focus on the server part. Enabling DHE-RSA-AES128-SHA cipher suite
>> hinders the performance of TLS handshakes by a factor of 3. Using
>> ECDHE-RSA-AES128-SHA instead only adds an overhead of 27%. However, if we
>> use the 64bit optimized version, the cost is only 15%

is that enough to understand why nobody on this world is using DHE and so your
"Current Fedora supports perfect forward secrecy just fine" is *far* away
from the reality?

it does not help much support forward secrecy in a way *nobody* else on this
planet is supporting it and so you repsonse below is uneducated - period

 Original-Nachricht 
Betreff: Re: Fedora/Redhat and perfect forward secrecy
Datum: Mon, 26 Aug 2013 11:07:29 +0200
Von: Florian Weimer 
An: Development discussions related to Fedora 
Kopie (CC): Reindl Harald , Mailing-List fedora-users 


On 08/24/2013 11:38 AM, Reindl Harald wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=319901
>
> 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)

Current Fedora supports perfect forward secrecy just fine.  It's just
that web server operators routinely refuse to offer it.  (The situation
is different with mail servers.)  Operational benefits look rather
marginal to me.  It may discourage interested parties from requesting
server private keys, but even that isn't assured.



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: PostgreSQL 9.3 in Fedora 20?

2013-09-09 Thread Honza Horak


On 09/09/2013 05:37 PM, Bruno Wolff III wrote:

On Mon, Sep 09, 2013 at 17:19:54 +0200,
   Michał Piotrowski  wrote:

Hi,

I know that currently Fedora 20 is in feature freeze state. But Alpha
version is still not released and PosgreSQL developers released new
latest
and greates version
http://www.postgresql.org/docs/9.3/static/release-9-3.html with cool
features. Are there chances to get this version for F20?


Database guys are pretty conservative. Based on the past (though Tom
isn't doing the updates for Fedora any more), the release needed to be
out before beta. Currently there is just an RC for 9.3


Not exactly, 9.3 was officially released today.

Honza


, so it may or may
not end up being released before F20 beta. Normally the postgres
maintainer hasn't gambled on a release happening and built postgres RCs
or Betas for rawhide hoping that things don't slip.


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



Am 09.09.2013 14:11, schrieb Jóhann B. Guðmundsson:
> On 09/09/2013 11:48 AM, Kamil Paral wrote:
>>> 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...
>> It should have been a prerequisite for dracut host-only feature.
> 
> It's nonsense having an full blown rescue environment as an requirement for 
> dracut-hostonly feature

i think you misread the post - IMHO the intention was that once again
a feature with zero benefit was acknowledged without caseful think about
the negative impact

maybe the "dracut-hostonly" feature was nonsense at all to save how many 
seconds at boot?
the ones who like it and knowing what they are doing used it long ago
the ones with less technical background have more potential problems now



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: PostgreSQL 9.3 in Fedora 20?



Am 09.09.2013 17:37, schrieb Bruno Wolff III:
> On Mon, Sep 09, 2013 at 17:19:54 +0200,
>   Michał Piotrowski  wrote:
>> Hi,
>>
>> I know that currently Fedora 20 is in feature freeze state. But Alpha
>> version is still not released and PosgreSQL developers released new latest
>> and greates version
>> http://www.postgresql.org/docs/9.3/static/release-9-3.html with cool
>> features. Are there chances to get this version for F20?
> 
> Database guys are pretty conservative. Based on the past (though Tom isn't 
> doing the updates for Fedora any more),
> the release needed to be out before beta. Currently there is just an RC for 
> 9.3, so it may or may not end up being
> released before F20 beta

http://www.heise.de/open/meldung/PostgreSQL-9-3-veroeffentlicht-1953017.html
in english: it is released



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

[Owner-change] Fedora packages ownership change

2013-09-09 Thread nobody

Change in ownership over the last 168 hours
===

15 packages were orphaned
-
perl-NOCpulse-Gritch [EL-5,EL-6,devel,f18,f19,f20] was orphaned by msuchy
 Perl throttled email notification for Spacewalk
 https://admin.fedoraproject.org/pkgdb/acls/name/perl-NOCpulse-Gritch
perl-NOCpulse-Debug [EL-5,EL-6,devel,f18,f19,f20] was orphaned by msuchy
 Perl debug output package
 https://admin.fedoraproject.org/pkgdb/acls/name/perl-NOCpulse-Debug
fmtools [EL-5,EL-6,f18] was orphaned by kwizart
 Simple Video for Linux radio card programs
 https://admin.fedoraproject.org/pkgdb/acls/name/fmtools
iwl4965-firmware [EL-5] was orphaned by kwizart
 Firmware for IntelÂ® PRO/Wireless 4965 A/G/N network adaptors
 https://admin.fedoraproject.org/pkgdb/acls/name/iwl4965-firmware
perl-NOCpulse-SetID [EL-5,EL-6,devel,f18,f19,f20] was orphaned by msuchy
 Provides api for correctly changing user identity
 https://admin.fedoraproject.org/pkgdb/acls/name/perl-NOCpulse-SetID
oyranos [devel,f20] was orphaned by kwizart
 The Oyranos Colour Management System (CMS)
 https://admin.fedoraproject.org/pkgdb/acls/name/oyranos
nocpulse-common [EL-5,EL-6,devel,f18,f19,f20] was orphaned by msuchy
 NOCpulse common
 https://admin.fedoraproject.org/pkgdb/acls/name/nocpulse-common
spacewalk-admin [devel,f18,f19,f20] was orphaned by msuchy
 Various utility scripts and data files for RHN Satellite installations
 https://admin.fedoraproject.org/pkgdb/acls/name/spacewalk-admin
perl-NOCpulse-CLAC [EL-5,EL-6,devel,f18,f19,f20] was orphaned by msuchy
 NOCpulse Command Line Application framework for Perl
 https://admin.fedoraproject.org/pkgdb/acls/name/perl-NOCpulse-CLAC
tinyfugue [EL-5,EL-6] was orphaned by jussilehtola
 A MU* client
 https://admin.fedoraproject.org/pkgdb/acls/name/tinyfugue
perl-NOCpulse-Object [EL-5,EL-6,devel,f18,f19,f20] was orphaned by msuchy
 NOCpulse Object abstraction for Perl
 https://admin.fedoraproject.org/pkgdb/acls/name/perl-NOCpulse-Object
qmforge [devel,f18,f19,f20] was orphaned by jussilehtola
 Analysis tools for quantum mechanical calculations
 https://admin.fedoraproject.org/pkgdb/acls/name/qmforge
iwl5000-firmware [EL-5] was orphaned by kwizart
 Firmware for IntelÂ® PRO/Wireless 5000 A/G/N network adaptors
 https://admin.fedoraproject.org/pkgdb/acls/name/iwl5000-firmware
perl-NOCpulse-Utils [EL-5,EL-6,devel,f18,f19,f20] was orphaned by msuchy
 NOCpulse utility packages
 https://admin.fedoraproject.org/pkgdb/acls/name/perl-NOCpulse-Utils
guake [f17] was orphaned by pingou
 Drop-down terminal for GNOME
 https://admin.fedoraproject.org/pkgdb/acls/name/guake

11 packages unorphaned
--
pfrankliunorphaned : flex [devel,f18,f19,f20]
pfrankliunorphaned : byacc [devel,f18,f19,f20]
cicku   unorphaned : PyMca [devel,f19,f20]
pmachataunorphaned : make [devel,devel,f18,f19,f20]
cicku   unorphaned : gausssum [devel,f19,f20]
jskarvadunorphaned : graphviz [EL-5,devel,f18,f19,f20]
limbunorphaned : nx [f18,f19]
lnykryn unorphaned : initscripts [devel,f18,f19,f20]
pfrankliunorphaned : bison [devel,f18,f19,f20]
mizdebskunorphaned : saxon [f18]
pfrankliunorphaned : tzdata [devel,f18,f19,f19,f20]

3 packages were retired

faenza-icon-theme [EL-6,devel,f14,f15,f16,f17,f18,f19,f20] was retired by heffer
 icon theme for Equinox GTK theme
 https://admin.fedoraproject.org/pkgdb/acls/name/faenza-icon-theme
freenx-client [devel,f20] was retired by limb
 Free client libraries and binaries for the NX protocol
 https://admin.fedoraproject.org/pkgdb/acls/name/freenx-client
python-netaddr [EL-6] was retired by jeckersb
 Network address manipulation, done Pythonically
 https://admin.fedoraproject.org/pkgdb/acls/name/python-netaddr

9 packages changed owner

limbgave to landgraf   : mupdf [EL-6]
limbgave to landgraf   : jbig2dec [EL-6]
limbgave to pwouters   : qrencode [EL-6]
limbgave to hobbes1069 : qt5-qtjsbackend [EL-6]
limbgave to hobbes1069 : qt5-qtdeclarative [EL-6]
limbgave to hobbes1069 : qt5-qtmultimedia [EL-6]
kevin   gave to fab: srm [EL-6]
ausil   gave to s4504kr: open-cobol [devel,f20]
limbgave to hobbes1069 : qt5-qtbase [EL-6]


Sources: https://github.com/pypingou/fedora-owner-change
-- 
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?

2013-09-09 Thread Remi Collet

Le 09/09/2013 17:51, Florian Müllner a écrit :
> On Mon, Sep 9, 2013 at 5:36 PM, Remi Collet  wrote:
>> Le 06/09/2013 11:33, Richard Hughes a écrit :
>>> [1] http://people.freedesktop.org/~hughsient/appdata/
>>
>> I don't see any localization information in those specifications...
> 
> From the above link: "Questions: [...] How do I translate this data?"

Sorry, but this need more explanation / sample / howto.

As I understand, localization is not planned for 3.10.

Sorry, but without translation, I just think this is a NO-GO for me.

Remi.

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

2013-09-09 Thread Eric Sandeen

On 9/9/13 10:56 AM, Till Maas wrote:
> On Sat, Sep 07, 2013 at 05:35:05PM -0500, Eric Sandeen wrote:
> 
>> If people want to switch the Fedora default to XFS, I'll gladly file
>> the feature.  :)
> 
> Why is XFS better than ext4. When I checked a few months ago, XFS did
> not even support shrinking, but only growing. Even now there seems to be
> only xfs_growfs on F19, but no tool to shrink it.

There is no universal "better" so I won't argue that point.  TBH,
ext4 is probably more performant for the most common types of
machines, storage, and workloads under typical Fedora .

XFS really shines as things get bigger - bigger storage, more cpus,
more memory, more spindles.

As for shrink, you are right - there is no xfs shrink.

(OTOH, I have seen a fair bit of damage done by ext4 shrink, so I'm
not so sure lack of shrink should count *against* xfs) ;)

-Eric

> Regards
> Till
> 

-- 
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: PostgreSQL 9.3 in Fedora 20?

2013-09-09 Thread Pavel Raiskup

> I know that currently Fedora 20 is in feature freeze state. But Alpha
> version is still not released and PosgreSQL developers released new latest
> and greates version
> http://www.postgresql.org/docs/9.3/static/release-9-3.html with cool
> features. Are there chances to get this version for F20?

Personaly, I would update the version in fc20 also, if there were done
proper testing through bodhi..  Could anybody help with testing?

So if there were no complaints, I would try to prepare the update tomorrow
probably.

Pavel

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

2013-09-09 Thread Florian Müllner

On Mon, Sep 9, 2013 at 5:36 PM, Remi Collet  wrote:
> Le 06/09/2013 11:33, Richard Hughes a écrit :
>> [1] http://people.freedesktop.org/~hughsient/appdata/
>
> I don't see any localization information in those specifications...

From the above link: "Questions: [...] How do I translate this data?"
-- 
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: Fedora/Redhat and perfect forward secrecy

2013-09-09 Thread Paul Wouters


On Mon, 9 Sep 2013, Reindl Harald wrote:


I don't get it, either


google "dhe versus ecdhe performance"

http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

Let’s focus on the server part. Enabling DHE-RSA-AES128-SHA cipher suite
hinders the performance of TLS handshakes by a factor of 3. Using
ECDHE-RSA-AES128-SHA instead only adds an overhead of 27%. However, if we
use the 64bit optimized version, the cost is only 15%


is that enough to understand why nobody on this world is using DHE and so your
"Current Fedora supports perfect forward secrecy just fine" is *far* away
from the reality?


Not for me. I thought TLS was latency bound. The above "factor 3" does
not state whether TLS client/server were in the same LAN (or even VMs on
the same host).

For the client, clearly CPU is not the limiting factor. For regular TLS
servers, this should also not matter. For fully loaded TLS servers or
TLS accelerators, the factor 3 on the CPU load will matter, but we're
talking clusters of machines here. Dropping in a few extra machines
shouldn't be that hard to give your patent-encumbered endusers PFS.


it does not help much support forward secrecy in a way *nobody* else on this
planet is supporting it and so you repsonse below is uneducated - period


Ignoring the obvious legal (and now potential backdoor) problems with
ECC is also not very educated.

Paul


 Original-Nachricht 
Betreff: Re: Fedora/Redhat and perfect forward secrecy
Datum: Mon, 26 Aug 2013 11:07:29 +0200
Von: Florian Weimer 
An: Development discussions related to Fedora 
Kopie (CC): Reindl Harald , Mailing-List fedora-users 


On 08/24/2013 11:38 AM, Reindl Harald wrote:

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

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)


Current Fedora supports perfect forward secrecy just fine.  It's just
that web server operators routinely refuse to offer it.  (The situation
is different with mail servers.)  Operational benefits look rather
marginal to me.  It may discourage interested parties from requesting
server private keys, but even that isn't assured.



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


Am 09.09.2013 18:38, schrieb Jared K. Smith:
> On Mon, Sep 9, 2013 at 8:19 AM, Reindl Harald  > wrote:
> 
> i think you misread the post - IMHO the intention was that once again
> a feature with zero benefit was acknowledged without caseful think about
> the negative impact
> 
> And I think you once again exaggerate, Harald.  Just because the feature 
> doesn't offer benefits to you does not
> mean it isn't useful at all. 

ironically i am using HostOnly and used it long before the "feature" was 
proposed

so your argumentation is wrong and you should try to realize that i am often
not against things because they are a problem for *me* but because they are
not a wise idea in the big picture and in case of ordinary users

personally i can deal with most things - many don' as well they don't
understand documentations how to solve a problem or in the worst case
have no access to the documentation because the machine don't boot

> Given that it's fairly easy to switch between the various modes, I think that
> essentially proves that those who made the change thought through the 
> possible negative impacts, and made it fairly
> easy for a systems administrator to choose how they're like their system to 
> work.

oh yeah, teel this the ordinary user which is not a systems administratot

> To drive the point home to its logical conclusion -- we're never going to 
> have *one* Fedora configuration that
> works perfectly for everyone

but we had init-ramdisks which worked for *more* users after whatever chnages
now Fedora switched to a more fragile default - the word "feature" for me
implies a benefit - i can't se a benefit in decisions making a OS setup
more windows-like "oh you changed your hardware, i won#t boot" while
this is a problem for the ordinary user and at the same time the educated
one doe snot need the default to save 1-2 seconds at boot while he is aware
about the impact



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: Fedora/Redhat and perfect forward secrecy



Am 09.09.2013 18:12, schrieb Paul Wouters:
> On Mon, 9 Sep 2013, Reindl Harald wrote:
>>> I don't get it, either
>>
>> google "dhe versus ecdhe performance"
>>
>> http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
 Let’s focus on the server part. Enabling DHE-RSA-AES128-SHA cipher suite
 hinders the performance of TLS handshakes by a factor of 3. Using
 ECDHE-RSA-AES128-SHA instead only adds an overhead of 27%. However, if we
 use the 64bit optimized version, the cost is only 15%
>>
>> is that enough to understand why nobody on this world is using DHE and so 
>> your
>> "Current Fedora supports perfect forward secrecy just fine" is *far* away
>> from the reality?
> 
> Not for me. I thought TLS was latency bound. The above "factor 3" does
> not state whether TLS client/server were in the same LAN (or even VMs on
> the same host).

it does not matter, the world measures CPU load here

> For the client, clearly CPU is not the limiting factor

if you stay on topic you realize that this does not matter
you can't do PFS to *any* major website these days

> For regular TLS servers, this should also not matter. For fully loaded TLS 
> servers or TLS accelerators, the factor 3 on the CPU load will matter, but 
> we're talking clusters of machines here. Dropping in a few extra machines
> shouldn't be that hard to give your patent-encumbered endusers PFS.

*you* are talking clusters here

>> it does not help much support forward secrecy in a way *nobody* else on this
>> planet is supporting it and so you repsonse below is uneducated - period
> 
> Ignoring the obvious legal (and now potential backdoor) problems with
> ECC is also not very educated

we are speaking about the real world, not about therory

*you can't* do PFS to *any* relevant target because nobody
offers negotiation with DHE - so stay on topic and as long
nothing is *proven* ignore it while it *is* proven that
PFS  doe snot work with Redhat/Fedora systems to the rest
of the world



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: PostgreSQL 9.3 in Fedora 20?

2013-09-09 Thread Bruno Wolff III


On Mon, Sep 09, 2013 at 17:41:51 +0200,
  Reindl Harald  wrote:


http://www.heise.de/open/meldung/PostgreSQL-9-3-veroeffentlicht-1953017.html
in english: it is released


Yeah, I just saw that.

Given that it is released it seems reasonable to get it into F20 and F21. 

We are past the alpha freeze deadline, so it shouldn't go into F20 until 
after that is over. But there should be plenty of time to notice odd issues 
before beta.

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

2013-09-09 Thread Jared K. Smith

On Mon, Sep 9, 2013 at 8:19 AM, Reindl Harald wrote:

> i think you misread the post - IMHO the intention was that once again
> a feature with zero benefit was acknowledged without caseful think about
> the negative impact
>

And I think you once again exaggerate, Harald.  Just because the feature
doesn't offer benefits to you does not mean it isn't useful at all. Given
that it's fairly easy to switch between the various modes, I think that
essentially proves that those who made the change thought through the
possible negative impacts, and made it fairly easy for a systems
administrator to choose how they're like their system to work.

To drive the point home to its logical conclusion -- we're never going to
have *one* Fedora configuration that works perfectly for everyone.
Instead, we're going to have some level of configuration to make it as
painless as possible to allow competent administrators to configure their
systems in a manner that works best for them.  Is the way you reconfigure
the initrd file ideal?  I'd probably argue that it isn't ideal, but works
well enough for now.  But could I in all honesty say that the feature has
no benefit, and that the developer(s) who made the change didn't think
about the possible negative impacts?  No, I can't.

--
Jared Smith
-- 
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: [389-devel] RFC: New Design: Fine Grained ID List Size

2013-09-09 Thread Rich Megginson

On 09/09/2013 02:27 AM, Ludwig Krispenz wrote:

On 09/07/2013 05:02 AM, David Boreham wrote:

On 9/6/2013 8:49 PM, Nathan Kinder wrote:
This is a good idea, and it is something that we discussed briefly
off-list. The only downside is that we need to change the index
format to keep a count of ids for each key. Implementing this isn't
a big problem, but it does mean that the existing indexes need to be
updated to populate the count based off of the contents (as you
mention above).

I don't think you need to do this (I certainly wasn't advocating
doing so). The "statistics" state is much the same as that proposed
in Rich's design. In fact you could probably just use that same
information. My idea is more about where and how you use the
information. All you need is something associated with each index
that says "not much point looking here if you're after something
specific, move along, look somewhere else instead". This is much the
same information as "don't use a high scan limit here".

In the short term, we are looking for a way to be able to improve
performance for specific search filters that are not possible to
modify on the client side (for whatever reason) while leaving the
index file format exactly as it is. I still feel that there is
potentially great value in keeping a count of ids per key so we can
optimize things on the server side automatically without the need
for complex index configuration on the administrator's part. I think
we should consider this for an additional future enhancement.

I'm saying the same thing. Keeping a cardinality count per key is way
more than I'm proposing, and I'm not sure how useful that would be
anyway, unless you want to do OLAP in the DS ;)
we have the cardinality of the key in old-idl and this makes some
searches where parts of the filter are allids fast.

I'm late in the discussion, but I think Rich's proposal is very
promising to address all the problems related to allids in new-idl.

We could then eventually rework filter ordering based on these
configurations. Right now we only have a filter ordering based on
index type and try to postpone "<=" or similar filter as they are
known to be costly, but this could be more elaborate.

An alternative would be to have some kind of index lookup caching. In
the example in ticket 47474 the filter is
(&(|(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(objectClass=organization)(objectClass=organizationalUnit)(objectClass=groupOf
Names)(objectClass=groupOfUniqueNames)(objectClass=group))(c3sUserID=EndUser078458))"
and probably only the "c3sUserID=x" part will change, if we cache
the result for the (&(|(objectClass=... part, even if it is expensive,
it would be done only once.

Thanks everyone for the comments. I have added Noriko's suggestion:
http://port389.org/wiki/Design/Fine_Grained_ID_List_Size

David, Ludwig: Does the current design address your concerns, and/or
provide the necessary first step for further refinements?

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

Re: Fedora/Redhat and perfect forward secrecy

2013-09-09 Thread Gregory Maxwell

On Mon, Sep 9, 2013 at 9:12 AM, Paul Wouters  wrote:
> For the client, clearly CPU is not the limiting factor. For regular TLS
> servers, this should also not matter. For fully loaded TLS servers or
> TLS accelerators, the factor 3 on the CPU load will matter, but we're
> talking clusters of machines here. Dropping in a few extra machines
> shouldn't be that hard to give your patent-encumbered endusers PFS.

The difference between DHE and ECDH in TLS is a difference of
supporting supporting about 3,000 connections per second and
supporting something like 800 connections per second (somewhat vague
numbers, opeenssl speed won't bench DH apparently, it's somewhat
slower than RSA encrypt due to the exponentiation by large secret
values).

And this is comparing apples and oranges 256bit ECDSA (conjectured
security involving a best attack 2^128) against DH-1024 (only 80 bit
conjectured security). Comparing with DH-1024 is sort of silly because
people do not consider 80 bit security adequate anymore.  The
comparison with 3072 bit DH is down to more like 200 connections per
second.

But again, and sorry to reiterate but it seems to be have been missed:
 ~No one actually supports the old DHE PFE, and offering it breaks
some clients.  So regardless of the speed concerns, a choice to not
support ECDH is a choice to not have PFS at all, at least on public
facing webservers.

> Ignoring the obvious legal (and now potential backdoor) problems with
> ECC is also not very educated.

I am certainly not ignoring legal concerns. While there are some
patented EC cryptographic techniques, the basic infrastructure
including ECDH over prime fields was first published back in 1984 and
is not patentable.

The IETF has published an extensive RFC covering the foundations of
ECC which carefully shows to-old-to-be-patentable direct citations:
http://tools.ietf.org/html/rfc6090

If Redhat is aware of a specific patent concern here, they're keeping
it secret from the public. The continued claims that there are legal
issues here behind basic support really don't make a lot of sense,
especially considering the functionality in RHEL.

(I would also note that the support in RHEL somewhat oddly support
_only_ the parameters from the NSA, which doesn't quite play into the
expressed concern about backdoors)
-- 
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: PostgreSQL 9.3 in Fedora 20?

2013-09-09 Thread Michał Piotrowski

Hi,


2013/9/9 Pavel Raiskup 

> > I know that currently Fedora 20 is in feature freeze state. But Alpha
> > version is still not released and PosgreSQL developers released new
> latest
> > and greates version
> > http://www.postgresql.org/docs/9.3/static/release-9-3.html with cool
> > features. Are there chances to get this version for F20?
>
> Personaly, I would update the version in fc20 also, if there were done
> proper testing through bodhi..  Could anybody help with testing?
>

Yes, of course I can help with testing.


>
> So if there were no complaints, I would try to prepare the update tomorrow
> probably.
>
> Pavel
>
>


-- 
Best regards,
Michal

http://eventhorizon.pl/
-- 
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)

2013-09-09 Thread Darryl L. Pierce

On Sat, Sep 07, 2013 at 12:17:57AM +0200, Reindl Harald wrote:
> Am 06.09.2013 20:26, schrieb Darryl L. Pierce:
> > 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

My response is more along the lines of "if it's worth posting about in a
mailing list, it's worth filing a bug to get it fixed". 

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


pgpe4L7E7PZfC.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: 19 (Schrödinger’s Cat)

2013-09-09 Thread Darryl L. Pierce

On Fri, Sep 06, 2013 at 07:07:46PM -0400, Rahul Sundaram wrote:
> 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/

+1

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


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

[Bug 1006000] New: perl-Pod-Spell-1.06 is available

2013-09-09 Thread bugzilla

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

Bug ID: 1006000
   Summary: perl-Pod-Spell-1.06 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Pod-Spell
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-de...@lists.fedoraproject.org



Latest upstream release: 1.06
Current version/release in Fedora Rawhide: 1.05-4.fc20
URL: http://search.cpan.org/dist/Pod-Spell/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

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

[Bug 1006001] New: perl-Socket-2.012 is available

2013-09-09 Thread bugzilla

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

Bug ID: 1006001
   Summary: perl-Socket-2.012 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Socket
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-de...@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 2.012
Current version/release in Fedora Rawhide: 2.011-1.fc20
URL: http://search.cpan.org/dist/Socket/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

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

Re: Fedora/Redhat and perfect forward secrecy

2013-09-09 Thread Paul Wouters


On Mon, 9 Sep 2013, Gregory Maxwell wrote:


I am certainly not ignoring legal concerns. While there are some
patented EC cryptographic techniques, the basic infrastructure
including ECDH over prime fields was first published back in 1984 and
is not patentable.

The IETF has published an extensive RFC covering the foundations of
ECC which carefully shows to-old-to-be-patentable direct citations:
http://tools.ietf.org/html/rfc6090

If Redhat is aware of a specific patent concern here, they're keeping
it secret from the public. The continued claims that there are legal
issues here behind basic support really don't make a lot of sense,
especially considering the functionality in RHEL.


[not speaking for Red Hat]

You seem to believe only valid legal claims can put Red Hat in court.


(I would also note that the support in RHEL somewhat oddly support
_only_ the parameters from the NSA, which doesn't quite play into the
expressed concern about backdoors)


[again not speaking for Red Hat, no idea of any arrangements]

I can come up with various commercial non-conspiracy theories for this.
For example, who pays the lawyers when a patent troll arrives.

Paul
--
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: Fedora/Redhat and perfect forward secrecy

2013-09-09 Thread Gregory Maxwell

On Mon, Sep 9, 2013 at 11:46 AM, Paul Wouters  wrote:
> [not speaking for Red Hat]
> You seem to believe only valid legal claims can put Red Hat in court.

Of course not.

Though I'm not aware of anyone making any claims at all over basic
non-specially optimized ECDH on prime fields. Perhaps RedHat is,
though if certicom/rim is out patent trolling on the basic stuff it
would be a shame to keep it a secret: They should take the goodwill
loss they deserve if they're going around claiming to own techniques
published in the mid 80s.

You're going to have a lot of software to remove if the _possibility_
of someone putting RedHat in court is the bar here. There are a _LOT_
more patents on compilers than on elliptic curve cryptography.

Or just patents on simple arithmetic optimizations, lets see US6073150
assigned to Sun.
This one patents computing the absolute value of a signed number using
masking by sign extension: E.g.

Set  mask = x>>(sizeof(x)*sizeof(char)-1);  absx = (x^mask)-mask.

Oh looky looky, GCC in Fedora 19 on x86_64 compiles "int x; x =
abs(x);" to this:

sarl$31, %eax
xorl%eax, -4(%rbp)
subl%eax, -4(%rbp)

Good thing nothing in Fedora uses abs() and that Sun's patent's would
never be held by a potentially hostile company so you don't have to
depend on the fact that this technique was published eons before the
patent 
(http://web.archive.org/web/19961201174141/www.x86.org/ftp/articles/pentopt/PENTOPT.TXT),
since that the invalidity of the claim can't be ensured to keep RedHat
out of court.

...

And this is an example where we actually do the stuff that is
patented. I do not believe there are any granted but invalid patents
that would preclude using basic ECDH over prime fields.  Maybe there
are and RedHat has heard of some, but if so the world would certainly
like to know that someone actual had a concrete risk here and this
wasn't someone just pattern matching "ECC = Patents ZOMG!" in a way
that they don't go "Compilers = Patents ZOMG!".
-- 
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: Wider feedback requested on two changes to our base/core defaults

On Mon, 09.09.13 19:42, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

> On 09/09/2013 07:30 PM, Lennart Poettering wrote:
> >On Wed, 21.08.13 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
> >
> >>And I have come across a bit of scalability issue due to us
> >>defaulting to using short hostnames in login and command prompt when
> >>creating OS containers in any real numbers.
> >I am pretty sure we should continue to default to "short" hostnames,
> >i.e. not fqdns.
> 
> I am pretty sure we should not since continuing to use short
> hostname is the worst option of them all since it collides with
> other "short" hostnames on your network.

So, then tell me. Which fixed fqdn shall I assign to my laptop then? The
laptop moves around all the time, connects to different networks, so
which is the right fqdn? And no, I am not changing the hostname all the
time...

Again, there are reasons to use the fqdn, but for the general case and
as default it's not a good choice.

>  Lennart I'm not sure what kind of modern system you are using which
> you can just pick up and walk around with your
> containers/vm's/servers between networks but feel free to slide one
> of those modern system to me and I'll happily bring that modern
> system of yours to the next administrative level ;)

Johann, they are called laptops.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
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: Wider feedback requested on two changes to our base/core defaults

On Wed, 21.08.13 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

> And I have come across a bit of scalability issue due to us
> defaulting to using short hostnames in login and command prompt when
> creating OS containers in any real numbers.

I am pretty sure we should continue to default to "short" hostnames,
i.e. not fqdns.

The thing is simply that in today's world hosts might appear on multiple
networks and domains at the same time, and that dynamically, and not
necessarily using IP or exposed via DNS. The domain suffix hence is
frequently something that is more interface or state dependent rather
than strictly host dependent. For example, the same host might have an
mdns hostname in .local as well as one ISP assigned hostname on ppp0 and
a hand chosen name on the LAN interface eth0. They might all share the
same non-qualified name, but are hightly like to have different
suffixes. Extending on that: sometimes a machine might be entirely
disconnected, an fqdn then makes very little sense, because it suggests
a world-wide reachable name which is misleading.

Enforcing a fixed fqdn for a a machine for its entire lifetime is
like enforcing a single fixed IP address for it -- i.e. a setup that
certainly makes sense but is probably not the common case for the vast
majority of modern systems.

Also, the hostname of the system is not only used for IP purposes. For
example bluetooth uses it too, and the shell displays it and whatnot.

In systemd's hostname support (as exposed via /etc/hostname, hostnamed,
hostnamectl, ...) we hence generally prefer non-fqdn names, however do
accept fqdns too. Server centric software like IPA requires FQDNs
though (which I personally think is a poor choice, but whatever...)

If an ISP wants to set up multiple containers he should probably make
sure on his own that the hostnames are unique on the container host, he
can manually choose fqdns for that, or even use his own scheme, for
example "customer23-host47" or whatever works for him... 

We try to find good defaults that work for everybody, not just specific
ISP setups. ISP setups tend to be fairly static, and hence
simple. However, static setups are generally just a boring special case
of dynamic setups, hence we generally implement things to cover that
well...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
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: Wider feedback requested on two changes to our base/core defaults


On 09/09/2013 07:53 PM, Ian Malone wrote:

I'd like to add myself as another datapoint for 'uses different
users', and often via ssh. In any case, that bash prompt trick surely
only works if applied to all user profiles or all systems being used.


They already are quite different between *nixes,shell variants and linux 
distro's which is why the skilled administrator would overwrite *his* 
preference over the default while *our* default would be clearly 
displaying the fqdn of the host to avoid any kind of administrative 
mishaps.


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

2013-09-09 Thread Elad Alfassa

On Mon, Sep 9, 2013 at 6:59 PM, Remi Collet wrote:

> Le 09/09/2013 17:51, Florian Müllner a écrit :
> > On Mon, Sep 9, 2013 at 5:36 PM, Remi Collet 
> wrote:
> >> Le 06/09/2013 11:33, Richard Hughes a écrit :
> >>> [1] http://people.freedesktop.org/~hughsient/appdata/
> >>
> >> I don't see any localization information in those specifications...
> >
> > From the above link: "Questions: [...] How do I translate this data?"
>
> Sorry, but this need more explanation / sample / howto.
>
> As I understand, localization is not planned for 3.10.
>
> Sorry, but without translation, I just think this is a NO-GO for me.
>
> Remi.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>


Hey Remi.
3.10 *will* support localization. Patches already landed.

https://git.gnome.org/browse/gnome-software/commit/?id=5b5d58c4abde7229f39246ccf3e42bb04d68bd15
https://github.com/hughsie/fedora-appstream/commit/6683d10503a592ac02ec9cf9671c817b2077e82e

If you have any specific questions (after reading both commit messages),
we'll be happy to answer them.
-- 
-Elad Alfassa.
-- 
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: Wider feedback requested on two changes to our base/core defaults

On Wed, 21.08.13 21:06, Simo Sorce (s...@redhat.com) wrote:

> > I would like us to change our default to use long hostname instead as in 
> > the fqdn or "container01.ackme.com" and would love any kind of feed back 
> > in that regard ( why we should not default to that ).
> 
> +1 always good to show the full name IMO, at least at the ssh/shell
> level, let the pretty graphical UIs be more lax and try to prettify
> things.

If you want that, then simply use the fqdn as hostname in
/etc/hostname. However, in the general case its a bad idea, since the
suffix might depend on the available network connectivity and might need
a DNS lookup and we certainly shouldn't delay the local login prompt for
a DNS lookup...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
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: Wider feedback requested on two changes to our base/core defaults


On 09/09/2013 08:05 PM, Lennart Poettering wrote:

On Mon, 09.09.13 19:42, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


On 09/09/2013 07:30 PM, Lennart Poettering wrote:

On Wed, 21.08.13 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


And I have come across a bit of scalability issue due to us
defaulting to using short hostnames in login and command prompt when
creating OS containers in any real numbers.

I am pretty sure we should continue to default to "short" hostnames,
i.e. not fqdns.

I am pretty sure we should not since continuing to use short
hostname is the worst option of them all since it collides with
other "short" hostnames on your network.

So, then tell me. Which fixed fqdn shall I assign to my laptop then? The
laptop moves around all the time, connects to different networks, so
which is the right fqdn? And no, I am not changing the hostname all the
time...


You dont your gnome terminal header as well as other desktop application 
should present you with the pretty hostname you set on your laptop.



Johann, they are called laptops.



This proposal is not about laptops or tablets or general desktop use 
cases but about sane server defaults


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: Wider feedback requested on two changes to our base/core defaults

2013-09-09 Thread Ian Malone

On 22 August 2013 15:50, Ondrej Vasik  wrote:
> On Thu, 2013-08-22 at 08:21 -0500, Chris Adams wrote:
>> Once upon a time, "Jóhann B. Guðmundsson"  said:



>> - The "user@" is mostly useless; if you su/sudo to root, the character
>>   at the end of the prompt changes from $ to #.  The only time I would
>>   be interested in seeing user@ is if I've su/sudo to a user (other than
>>   root) that doesn't match the login user for this TTY; on Linux this
>>   can be as easy as the following bit of bash:
>>
>>   local user=""
>>   if [ "$UID" != 0 -a ! -O /proc/self/fd/0 ]; then
>>   user='\u@'
>>   fi
>>   PS1="$user"'\h \W\$ '
>
> Good suggestion, I like it - and maybe it would make sense to change the
> default to this if wider audience will agree on that.
> Still I don't agree that this is useless - I usually have several
> terminals with ssh connection and they are differentiated in user (e.g.
> per tool I'm using on that machine). Having only hostname will make it
> harder for me (as the hostnames differ only in number). Most of the
> users probably don't have this scenario, so I'm a bit toward to +1 here.
>

I'd like to add myself as another datapoint for 'uses different
users', and often via ssh. In any case, that bash prompt trick surely
only works if applied to all user profiles or all systems being used.

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

Re: Wider feedback requested on two changes to our base/core defaults


On 09/09/2013 07:30 PM, Lennart Poettering wrote:

On Wed, 21.08.13 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


And I have come across a bit of scalability issue due to us
defaulting to using short hostnames in login and command prompt when
creating OS containers in any real numbers.

I am pretty sure we should continue to default to "short" hostnames,
i.e. not fqdns.



I am pretty sure we should not since continuing to use short hostname is 
the worst option of them all since it collides with other "short" 
hostnames on your network.




The thing is simply that in today's world hosts might appear on multiple
networks and domains at the same time, and that dynamically, and not
necessarily using IP or exposed via DNS. The domain suffix hence is
frequently something that is more interface or state dependent rather
than strictly host dependent. For example, the same host might have an
mdns hostname in .local as well as one ISP assigned hostname on ppp0 and
a hand chosen name on the LAN interface eth0. They might all share the
same non-qualified name, but are hightly like to have different
suffixes. Extending on that: sometimes a machine might be entirely
disconnected, an fqdn then makes very little sense, because it suggests
a world-wide reachable name which is misleading.


Yes it does makes sense and quite frankly using short hostname is the 
worst option of them all we would be better using ip and or no hostname 
et all rather then to continue to use short hostnames.




Enforcing a fixed fqdn for a a machine for its entire lifetime is
like enforcing a single fixed IP address for it -- i.e. a setup that
certainly makes sense but is probably not the common case for the vast
majority of modern systems.


?

 Lennart I'm not sure what kind of modern system you are using which 
you can just pick up and walk around with your containers/vm's/servers 
between networks but feel free to slide one of those modern system to me 
and I'll happily bring that modern system of yours to the next 
administrative level ;)


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

2013-09-09 Thread Matthias Clasen

On Mon, 2013-09-09 at 23:08 +0300, Elad Alfassa wrote:

> 
> 
> 3.10 *will* support localization. Patches already landed.
> 
> https://git.gnome.org/browse/gnome-software/commit/?id=5b5d58c4abde7229f39246ccf3e42bb04d68bd15
> https://github.com/hughsie/fedora-appstream/commit/6683d10503a592ac02ec9cf9671c817b2077e82e
> 
> 
> If you have any specific questions (after reading both commit
> messages), we'll be happy to answer them.
> 

To expand on that, 

http://blogs.gnome.org/hughsie/files/2013/09/gnome-software-pt_br.png 

shows translated appdata for bijiben, and

https://git.gnome.org/browse/bijiben/tree/data/bijiben.appdata.xml.in
https://git.gnome.org/browse/bijiben/tree/data/Makefile.am
https://git.gnome.org/browse/bijiben/tree/po/POTFILES.in

shows how this is set up, using intltool for the extraction and merging
of translations.

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

2013-09-09 Thread Richard Shaw

On Sat, Sep 7, 2013 at 6:43 AM, Daniel J Walsh  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/07/2013 06:14 AM, Richard Hughes wrote:
> > On 7 September 2013 11:03, Daniel J Walsh  wrote:
> >> Why not open bugzillas with the packages with .Desktop files to do this?
> >
> > Valid question, although that would be opening ~800 bugs and I'm not sure
> > that's a terribly useful thing to do. If you think it would be useful, I
> > can look at either doing this, or providing a list of packages to someone
> > that's done this kind of thing before. Ideas welcome. Thanks.
> >
> > Richard.
> >
> Ok, I did not know it was that many.  My main reason for asking, is I am
> more
> likely to miss this email or even if I read it forget about it then I am
> on a
> bugzilla.


Any way to scan sources to see which projects are already providing the
file but just not being packaged?

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?

2013-09-09 Thread Michael Catanzaro

On Mon, 2013-09-09 at 17:59 +0200, Remi Collet wrote:
> Sorry, but this need more explanation / sample / howto.
> 
> As I understand, localization is not planned for 3.10.
> 
> Sorry, but without translation, I just think this is a NO-GO for me.
> 
> Remi.
Translations are now supported, see
http://blogs.gnome.org/hughsie/2013/09/09/gnome-software-talking-your-language/

Maybe 5% of GNOME apps have internationalized their appdata; most are
indeed shipping English-only for the time being in accordance with
Richard's advice.


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Some Spacewalk packages orphaned

2013-09-09 Thread Till Maas

On Mon, Sep 09, 2013 at 10:00:49AM +0200, Miroslav Suchý wrote:
> Hi,
> I orphaned following packages in Fedora (and EPEL):
> nocpulse-common
> perl-NOCpulse-CLAC
> perl-NOCpulse-Debug
> perl-NOCpulse-Gritch
> perl-NOCpulse-Object
> perl-NOCpulse-SetID
> perl-NOCpulse-Utils
> spacewalk-admin
> 
> They transitively need new package, which is not yet in Fedora. And
> since I do not use Spacewalk anymore I will not try to get that
> missing dependency into Fedora.

Most if not all packages depend on a package I recently retired,
therefore because it did not build for two releases. Since the packages
cannot be installed on F20+, I will retire the packages in F20+ as well,
unless someone wants to pick them up.

Regards
Till
-- 
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: Some Spacewalk packages orphaned

2013-09-09 Thread Till Maas

On Mon, Sep 09, 2013 at 10:59:56PM +0200, Till Maas wrote:

> Most if not all packages depend on a package I recently retired,
> therefore because it did not build for two releases. Since the packages

Actually they depend on a retired package, that I blocked, because it
was not blocked. But the implications are the same:

> cannot be installed on F20+, I will retire the packages in F20+ as well,
> unless someone wants to pick them up.

Regards
Till
-- 
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-Net-Patricia] Update to 1.21

2013-09-09 Thread Orion Poplawski

commit 106f800a565df3e4bea251adabe4878cac471f42
Author: Orion Poplawski 
Date:   Mon Sep 9 15:06:03 2013 -0600

Update to 1.21

 .gitignore |1 +
 perl-Net-Patricia.spec |7 +--
 sources|2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index cf6f4c8..766c385 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Net-Patricia-1.17_01.tar.gz
 /Net-Patricia-1.18_81.tar.gz
 /Net-Patricia-1.19.tar.gz
 /Net-Patricia-1.20.tar.gz
+/Net-Patricia-1.21.tar.gz
diff --git a/perl-Net-Patricia.spec b/perl-Net-Patricia.spec
index b9f8ef2..c3aad3a 100644
--- a/perl-Net-Patricia.spec
+++ b/perl-Net-Patricia.spec
@@ -1,6 +1,6 @@
 Name:   perl-Net-Patricia
-Version:1.20
-Release:4%{?dist}
+Version:1.21
+Release:1%{?dist}
 Summary:Patricia Trie perl module for fast IP address lookups
 License:Distributable, see COPYING
 Group:  Development/Libraries
@@ -61,6 +61,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Mon Sep 9 2013 Orion Poplawski  - 1.21-1
+- Update to 1.21
+
 * Sat Aug 03 2013 Fedora Release Engineering  
- 1.20-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
 
diff --git a/sources b/sources
index d6968a8..bc85f2b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d5499f5bc1d6c36538a84153095ea11f  Net-Patricia-1.20.tar.gz
+6335733b1f217d388015863c9fc0468d  Net-Patricia-1.21.tar.gz
--
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

[perl-Net-Patricia] Fix changelog dates

2013-09-09 Thread Orion Poplawski

commit 89d8d2b6d59f321519f6101cc49cd08801a5dbcf
Author: Orion Poplawski 
Date:   Mon Sep 9 15:08:07 2013 -0600

Fix changelog dates

 perl-Net-Patricia.spec |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/perl-Net-Patricia.spec b/perl-Net-Patricia.spec
index c3aad3a..eb98537 100644
--- a/perl-Net-Patricia.spec
+++ b/perl-Net-Patricia.spec
@@ -94,7 +94,7 @@ rm -rf $RPM_BUILD_ROOT
 * Fri Nov 26 2010 Philip Prindeville  - 1.19-1
 - 1.18_81 re-released as 1.19
 
-* Sun Nov 15 2010 Philip Prindeville  - 1.18_81-1
+* Sun Nov 14 2010 Philip Prindeville  - 1.18_81-1
 - new upstream verion, maintenance fix
   - improve parameter checking
   - handle undef as $data parameter to add()
@@ -125,7 +125,7 @@ rm -rf $RPM_BUILD_ROOT
 * Tue May 04 2010 Marcela Maslanova  - 1.16-2
 - Mass rebuild with perl-5.12.0
 
-* Fri Feb 24 2010 Philip Prindeville  - 1.16-1
+* Wed Feb 24 2010 Philip Prindeville  - 1.16-1
 - new upstream version, official release
 
 * Fri Jan  8 2010 Stepan Kasal  - 1.15_07-1
--
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

[perl-Net-Patricia] License changed to GPLv2+

2013-09-09 Thread Orion Poplawski

commit c047e2c19dd92d138b9dbfc452977925d2ca3d35
Author: Orion Poplawski 
Date:   Mon Sep 9 15:17:34 2013 -0600

License changed to GPLv2+

 perl-Net-Patricia.spec |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
---
diff --git a/perl-Net-Patricia.spec b/perl-Net-Patricia.spec
index eb98537..36e6d04 100644
--- a/perl-Net-Patricia.spec
+++ b/perl-Net-Patricia.spec
@@ -2,7 +2,7 @@ Name:   perl-Net-Patricia
 Version:1.21
 Release:1%{?dist}
 Summary:Patricia Trie perl module for fast IP address lookups
-License:Distributable, see COPYING
+License:GPLv2+
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Net-Patricia/
 Source0:
http://www.cpan.org/modules/by-module/Net/Net-Patricia-%{version}.tar.gz
@@ -55,7 +55,7 @@ rm -rf $RPM_BUILD_ROOT
 
 %files
 %defattr(-,root,root,-)
-%doc Changes COPYING README
+%doc Changes COPYING README libpatricia/copyright
 %{perl_vendorarch}/auto/*
 %{perl_vendorarch}/Net*
 %{_mandir}/man3/*
@@ -63,6 +63,7 @@ rm -rf $RPM_BUILD_ROOT
 %changelog
 * Mon Sep 9 2013 Orion Poplawski  - 1.21-1
 - Update to 1.21
+- License changed to GPLv2+
 
 * Sat Aug 03 2013 Fedora Release Engineering  
- 1.20-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
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

New testng 6.8.7

2013-09-09 Thread punto...@libero.it


hi

If there are no dissenting opinions
update testng to 6.8.7
regards
gil


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

2013-09-09 Thread Remi Collet

Le 06/09/2013 11:33, Richard Hughes a écrit :

> [1] http://people.freedesktop.org/~hughsient/appdata/
> [2] https://github.com/hughsie/fedora-appstream/tree/master/appdata-extra

I don't see any localization information in those specifications...

Isn't this supposed to be a user-friendly feature ?

Remi.
-- 
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: New testng 6.8.7

2013-09-09 Thread 80

2013/9/9 punto...@libero.it 

>  hi
>
> If there are no dissenting opinions
> update testng to 6.8.7
> regards
> gil
>
>
Is it a bugfix release or does it bring some disruptive changes ?
In the former case, you need not to ping this list about it, in the latter,
you need to be more explicit or provide some links.
Else, it's pretty useless to expect your fellow packager to provide you any
valuable opinions.

You might want to forward this to the java-devel list too (lower traffic
and a more targeted audience).

best regards,
H.
-- 
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: Release Ownership for oyranos

2013-09-09 Thread Richard Shaw

On Sun, Sep 8, 2013 at 3:55 AM, Nicolas Chauvet  wrote:

> Hi,
>
> I've released ownership for oyranos which currently FTBFS in f20.
> I will not have time to fix in the f20 time frame, so it might be blocked
> or even retired if none volunteer to maintain it.
>
> There will be a need to update elektra first, then if one in interested in
> this package, libXcm and xcm are also of interested. I can keep theses for
> the moment.
>

I'm assuming there's no good alternative? I looked into it a bit and
oyranos seems to do for images and OpenImageIO does for video...

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

New testng 6.8.7

2013-09-09 Thread punto...@libero.it


hi

If there are no dissenting opinions
update testng to 6.8.7
regards
gil


<>-- 
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: Wider feedback requested on two changes to our base/core defaults

2013-09-09 Thread Simo Sorce

On Mon, 2013-09-09 at 21:30 +0200, Lennart Poettering wrote:
> On Wed, 21.08.13 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
> 
> > And I have come across a bit of scalability issue due to us
> > defaulting to using short hostnames in login and command prompt when
> > creating OS containers in any real numbers.
> 
> I am pretty sure we should continue to default to "short" hostnames,
> i.e. not fqdns.
> 
> The thing is simply that in today's world hosts might appear on multiple
> networks and domains at the same time, and that dynamically, and not
> necessarily using IP or exposed via DNS. The domain suffix hence is
> frequently something that is more interface or state dependent rather
> than strictly host dependent. For example, the same host might have an
> mdns hostname in .local as well as one ISP assigned hostname on ppp0 and
> a hand chosen name on the LAN interface eth0. They might all share the
> same non-qualified name, but are hightly like to have different
> suffixes. Extending on that: sometimes a machine might be entirely
> disconnected, an fqdn then makes very little sense, because it suggests
> a world-wide reachable name which is misleading.
> 
> Enforcing a fixed fqdn for a a machine for its entire lifetime is
> like enforcing a single fixed IP address for it -- i.e. a setup that
> certainly makes sense but is probably not the common case for the vast
> majority of modern systems.
> 
> Also, the hostname of the system is not only used for IP purposes. For
> example bluetooth uses it too, and the shell displays it and whatnot.
> 
> In systemd's hostname support (as exposed via /etc/hostname, hostnamed,
> hostnamectl, ...) we hence generally prefer non-fqdn names, however do
> accept fqdns too. Server centric software like IPA requires FQDNs
> though (which I personally think is a poor choice, but whatever...)
> 
> If an ISP wants to set up multiple containers he should probably make
> sure on his own that the hostnames are unique on the container host, he
> can manually choose fqdns for that, or even use his own scheme, for
> example "customer23-host47" or whatever works for him... 
> 
> We try to find good defaults that work for everybody, not just specific
> ISP setups. ISP setups tend to be fairly static, and hence
> simple. However, static setups are generally just a boring special case
> of dynamic setups, hence we generally implement things to cover that
> well...

Kerberos and x509 both require FQDNs.
It makes no sense to stick to short names for servers, and having a FQDN
on a laptop does not hurt anything (a FreeIPA enrolled laptop must have
a FQDN anyway as it uses the keytab to do validation).

If you want pretty names, it is just FINE, just *show* pretty name to
the desktop, but the underlying system needs a fqdn, and you have no
issue using it, and you know it because you wrote a nss module that can
return automagically always 127.0.0.x for the machine hostname,
regardless of DNS or /etc/hosts, so we do not really have an issue with
resolving the machine own host name.

So can you please stop breaking servers just to show 'pretty' names ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: Wider feedback requested on two changes to our base/core defaults

On Mon, 09.09.13 18:30, Simo Sorce (s...@redhat.com) wrote:

> Kerberos and x509 both require FQDNs.
> It makes no sense to stick to short names for servers, and having a FQDN
> on a laptop does not hurt anything (a FreeIPA enrolled laptop must have
> a FQDN anyway as it uses the keytab to do validation).

So, which fqdn do I configure my laptop to?

> So can you please stop breaking servers just to show 'pretty' names ?

I am breaking anything? That is news to me... The tools allows fqdn, as
I wrote. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
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: Wider feedback requested on two changes to our base/core defaults

2013-09-09 Thread Ian Malone

On 9 September 2013 20:53, "Jóhann B. Guðmundsson"  wrote:
> On 09/09/2013 07:53 PM, Ian Malone wrote:
>>
>> I'd like to add myself as another datapoint for 'uses different
>> users', and often via ssh. In any case, that bash prompt trick surely
>> only works if applied to all user profiles or all systems being used.
>
>
> They already are quite different between *nixes,shell variants and linux
> distro's which is why the skilled administrator would overwrite *his*
> preference over the default while *our* default would be clearly displaying
> the fqdn of the host to avoid any kind of administrative mishaps.
>

Thank you for the put down. However, firstly I'm not referring to the
fqdn issue, but the mention of dropping user name and secondly I'm not
the administrator of all the systems I use. I was simply trying to
provide some user input here.

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

does mc really require perl*?

2013-09-09 Thread Felix Miata

I did a TC5 minimal install last night, which omitted mc, my most used 
cmdline tool. So:


# yum install mc
... installing for dependencies:
gpm-libs (which I never ever use)
perl* (29 packages)...

Seriously? What does mc need perl for?

I installed mc plus gpm-libs with rpm --nodeps, and it works.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Wider feedback requested on two changes to our base/core defaults

2013-09-09 Thread Simo Sorce

On Tue, 2013-09-10 at 00:35 +0200, Lennart Poettering wrote:
> On Mon, 09.09.13 18:30, Simo Sorce (s...@redhat.com) wrote:
> 
> > Kerberos and x509 both require FQDNs.
> > It makes no sense to stick to short names for servers, and having a FQDN
> > on a laptop does not hurt anything (a FreeIPA enrolled laptop must have
> > a FQDN anyway as it uses the keytab to do validation).
> 
> So, which fqdn do I configure my laptop to?

It depends on your environment of course.

My personal laptop is configured with a fqdn in the FreeIPA domain I use
at home. My Red Hat laptop is configured with a domain name under
redhat.com, whatever makes sense.

If you have nothing feel free to go and just put a one component
hostname, or append .localdomain all the same

The point is: do not force the hostname to be one component.

> > So can you please stop breaking servers just to show 'pretty' names ?
> 
> I am breaking anything? That is news to me... The tools allows fqdn, as
> I wrote. 

you said:

> Enforcing a fixed fqdn for a a machine for its entire lifetime is
> like enforcing a single fixed IP address for it -- i.e. a setup that
> certainly makes sense but is probably not the common case for the vast
> majority of modern systems.

First of all, names are abstract and this comparison makes little sense,
a fqdn has no bearing on where a machine is located and its reachability
unlike IP addresses.

> The domain suffix hence is
> frequently something that is more interface or state dependent rather
> than strictly host dependent. For example, the same host might have an
> mdns hostname in .local as well as one ISP assigned hostname on ppp0
> and
> a hand chosen name on the LAN interface eth0.

And even less sense makes changing a machine name just because you are
roaming on some untrusted network. What 'random dhcp server' thinks is
my hostname is totally irrelevant to me, and certainly you do not want
to change the hostname based on what network you are on, as it may
contain anything including offensive names or whatever.
Besides changing the hostname may simply break stuff.
What a PTR resolution say is meaningless in 99% of the cases for roaming
machines, and very often for non-moving servers too, they should just be
completely ignored in most setups.

> Also, the hostname of the system is not only used for IP purposes. For
> example bluetooth uses it too, and the shell displays it and whatnot.

Poor choice on the part of these programs if finding a fqdn there is not
of their liking.

> In systemd's hostname support (as exposed via /etc/hostname,
> hostnamed,
> hostnamectl, ...) we hence generally prefer non-fqdn names, however do
> accept fqdns too.

Windows also prefers non fqdn names ... but for *display* only.
Underneath you find they always have a short machine name and a domain
or workgroup they belong to even if the workgroup is just the default
silly WORKGROUP name.

I am all for showing just the short name in some UI, that's just fine, I
have a bigger problem when I have to jump through hoops to set the fqdn
as the default behavior of the tool that set the hostname when I try to
set my.client.ipa is to turn my fqdn into my_client_ipa which A) is not
what I asked, B) makes no sense and C) is a silly transformation with no
discernible benefit that I can think of, might as well return an error,
it would cause less issues.

> Server centric software like IPA requires FQDNs
> though (which I personally think is a poor choice, but whatever...)

On what ground do you say it is a poor choice ?
Did it ever occur to you that there is *no* choice ?

FreeIPA distributes both keytabs and x509 certs to *clients*, and those
need stable names, it's just how the technology is), but it is not a big
problem because we *also* empower the client to use secure dynDNS to
change their name in the FreeIPA DNS server so that it always point to
whatever IP address they have.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: Wider feedback requested on two changes to our base/core defaults