Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Jul 18, 2013 12:22 AM, "James Hogarth"  wrote:
> Oh how do you get your logs to read in windows from your lvm/ext4/btrfs
filesystems currently in a disk boot scenario?

Using ext2fsd:
http://www.ext2fsd.com

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

Re: F20 Self Contained Change: Vagrant

[Vít Ondruch]

Dne 17.7.2013 21:19, Julian C. Dunn napsal(a):
On Wed, Jul 17, 2013 at 3:10 PM, Matthew Miller 
mailto:mat...@fedoraproject.org>> wrote:


On Wed, Jul 17, 2013 at 02:34:40PM -0400, Julian C. Dunn wrote:


> https://github.com/brianmario/yajl-ruby/pull/113
> I talked with our engineering folks about using stdlib JSON but
they prefer
> YAJL, for a number of reasons I won't go into here. It would
also be a huge
> change for us with little return.

Okay. Anything we can do to get the de-vendorization patch moving?


It looks tough. The patch that Josef and Vit worked on is against the 
yajl-ruby 2.0 branch (an unreleased version). I'll let Josef/Vit chime 
in here with more details about what's in there.


- Julian



There is one missing method in upstream YAJL in comparison to bundled 
version. I am afraid we cannot move forward without upstream interaction :/


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

Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd

[Miroslav Lichvar]

On Wed, Jul 17, 2013 at 01:48:04PM -0700, Adam Williamson wrote:
> On Wed, 2013-07-17 at 13:44 -0700, Adam Williamson wrote:
> > On Wed, 2013-07-17 at 16:09 +0200, Miroslav Lichvar wrote:
> > 
> > > > e. Why isn't this functionality being added to chrony, rather than 
> > > > bouncing us back to ntpd?
> > > 
> > > Which functionality exactly? Both ntpd and chronyd (in default
> > > configuration) let the kernel sync the RTC. 
> > 
> > The ability to invoke chronyd in a way that mimics ntpdate. This thread
> > has turned up that you can invoke *ntpd* in this way: ntpd -q -g -x. But
> > no-one has yet provided an equivalent invocation for chronyd, and I
> > could not figure one out from the manpage.

chronyd doesn't have an "ntpdate" mode. I think that could be a
useful feature and I'll see if it can be added.

> > Aside from anything else, anaconda requires something like this to be
> > available in order to check whether an NTP server is valid and
> > available: a simple, one-off command which will 'return true' in some
> > obvious way if the specified server exists and responds correctly, and
> > 'return false' if it doesn't. For now it is using ntpdate; I suppose we
> > could switch it to ntpd, but it would make an awful lot more sense if
> > chronyd could do this.
> 
> In fact, now I look at it, ntpd as it stands cannot replace ntpdate for
> anaconda's purposes, because anaconda calls ntpdate with the -q option,
> which means "query only, do not set the clock" - obviously, this is
> appropriate when we just want to test the functionality of an NTP
> server. ntpd does not have an equivalent option.

The sntp tool can be used instead of ntpdate to test if an NTP server
is responding.

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

Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd (fwd)

[Miroslav Lichvar]

On Wed, Jul 17, 2013 at 01:56:13PM -0400, Paul Wouters wrote:
> Okay, so perhaps chrony should be extended to use a "saved clock" as a
> time source on boot if available, and save the time in a file regularly,
> if it does not do so already.

I'd say that should be a new separate service run on boot and
shutdown. As we have learned in the other thread, the chronyd service
can't even know if it's started for the first time after boot and
should restore the time from the file, or was just restarted.

> ObPetPeve: The complete chrony documentation is supplied in texinfo format.

Is texinfo no longer considered acceptable? The documentation is
included also as plain text in /usr/share/doc/chrony-1.28/chrony.txt
if you don't like the info format.

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

Re: F20 System Wide Change: No Default Syslog

[James Hogarth]

> > Oh how do you get your logs to read in windows from your lvm/ext4/btrfs
filesystems currently in a disk boot scenario?
>
> Using ext2fsd:
> http://www.ext2fsd.com
>

... I'd suggest you read that page and then look at my question and think
real hard...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Virtual provides for files in /var/log

[Vít Ondruch]

Dne 18.7.2013 01:02, Lennart Poettering napsal(a):

So, maybe, instead of dropping the "Provides syslog" thing from
journald, maybe we should add an explicit "syslog-files" dependency (or
something named like that) and then make the classic syslog
implementations provide that and the packages which actually need
/var/log/messages pull that it?

Lennart



So why there are files in /var/log and there is not obvious package, 
which creates them (unless you want to guess by name)? Shouldn't all 
package, which creates log in /var/log have some virtual provide to make 
it obvious? Why not do it properly/consistently?


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

Re: F20 System Wide Change: Visible Cloud

[Florian Weimer]

On 07/16/2013 06:09 PM, Kevin Fenzi wrote:

On Tue, 16 Jul 2013 10:55:40 +0200
Florian Weimer  wrote:


On 07/15/2013 12:34 PM, Daniel P. Berrange wrote:


I'm not suggesting we need to rebuild images for every update, but
at a minimum, when we issue CVE / security errata that affects an
image, I'd expect us to also rebuild and publish new cloud images
pretty much synchronously.


Secure Boot support could benefit from image respins as well, if we
ever start blacklisting kernels which threaten (our interpretation
of) the Secure Boot security model.  Right now, this isn't necessary
because other distributions allegedly grant unrestricted ring 0
access by design, but this might change in the future.


If we do decide to do this, it would need releng/infra/qa/fesco buyin at
least. I suspect it would also require more people stepping up in those
areas to make it happen (unless we were willing to delay new releases to
push out new security related images for existing releases).


Sure, we're certainly lucky that we don't have to do this yet.  It will 
be interesting to see which side (restrictive vs permissive mode after 
booting) wins in the end.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Virtual provides for files in /var/log

[Mathieu Bridon]

On Thu, 2013-07-18 at 10:34 +0200, Vít Ondruch wrote:
> Dne 18.7.2013 01:02, Lennart Poettering napsal(a):
> > So, maybe, instead of dropping the "Provides syslog" thing from
> > journald, maybe we should add an explicit "syslog-files" dependency (or
> > something named like that) and then make the classic syslog
> > implementations provide that and the packages which actually need
> > /var/log/messages pull that it?
> >
> > Lennart
> >
> 
> So why there are files in /var/log and there is not obvious package, 
> which creates them (unless you want to guess by name)? Shouldn't all 
> package, which creates log in /var/log have some virtual provide to make 
> it obvious? Why not do it properly/consistently?

Why a virtual provides, can't they just %ghost their log files?


-- 
Mathieu

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

Re: Virtual provides for files in /var/log

[Vít Ondruch]

Dne 18.7.2013 10:42, Mathieu Bridon napsal(a):

On Thu, 2013-07-18 at 10:34 +0200, Vít Ondruch wrote:

Dne 18.7.2013 01:02, Lennart Poettering napsal(a):

So, maybe, instead of dropping the "Provides syslog" thing from
journald, maybe we should add an explicit "syslog-files" dependency (or
something named like that) and then make the classic syslog
implementations provide that and the packages which actually need
/var/log/messages pull that it?

Lennart


So why there are files in /var/log and there is not obvious package,
which creates them (unless you want to guess by name)? Shouldn't all
package, which creates log in /var/log have some virtual provide to make
it obvious? Why not do it properly/consistently?

Why a virtual provides, can't they just %ghost their log files?




That would be the best of course, unfortunately: 
https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies


But may be YUM/DNF can be improved in this area

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

Re: Virtual provides for files in /var/log

[Mathieu Bridon]

On Thu, 2013-07-18 at 10:56 +0200, Vít Ondruch wrote:
> Dne 18.7.2013 10:42, Mathieu Bridon napsal(a):
> > On Thu, 2013-07-18 at 10:34 +0200, Vít Ondruch wrote:
> >> Dne 18.7.2013 01:02, Lennart Poettering napsal(a):
> >>> So, maybe, instead of dropping the "Provides syslog" thing from
> >>> journald, maybe we should add an explicit "syslog-files" dependency (or
> >>> something named like that) and then make the classic syslog
> >>> implementations provide that and the packages which actually need
> >>> /var/log/messages pull that it?
> >>>
> >>> Lennart
> >>>
> >> So why there are files in /var/log and there is not obvious package,
> >> which creates them (unless you want to guess by name)? Shouldn't all
> >> package, which creates log in /var/log have some virtual provide to make
> >> it obvious? Why not do it properly/consistently?
> > Why a virtual provides, can't they just %ghost their log files?
> >
> >
> 
> That would be the best of course, unfortunately: 
> https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies
> 
> But may be YUM/DNF can be improved in this area

Right, but that's only if you need to express a file requirement.

Your point above was that every package which drops a file in /var/log
(e.g httpd) should have virtual-provides for them.

But I don't think there's ever any reason to require the
file /var/log/https/error_log

On the other hand, Lennart's original mail above was about syslog
implementations, not "all package, which creates log in /var/log".


-- 
Mathieu

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

Re: F20 System Wide Change: No Default Syslog

[Ralf Corsepius]

On 07/18/2013 06:36 AM, Michael Catanzaro wrote:

On Wed, 2013-07-17 at 14:58 +0200, Lennart Poettering wrote:

We ask this constantly on Fedora. Because Fedora is where innovation is
supposed to take place, not where things are stay frozen in carbonite
forever.

(And let's never forget that Fedora is not the pioneer here. ArchLinux
went journal-only already. We are not actually the innovators here, we
just follow.)


I believe openSUSE 12.3 does not install syslog anymore either. (I think
they decided they did not want to log everything twice? :) Fedora's
following this time.


Is this of any importance? May be you should think about the reasons we 
are using Fedora and are not using openSUSE.


That said Fedora should draw its own decisions and not try to be an 
imitation cult.


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

Re: F20 System Wide Change: No Default Syslog

[James Hogarth]

On 18 July 2013 10:17, Ralf Corsepius  wrote:
>
>
> Is this of any importance? May be you should think about the reasons we
> are using Fedora and are not using openSUSE.
>
> That said Fedora should draw its own decisions and not try to be an
> imitation cult.
>


Well given that one of the cases complaining against the change stated how
they liked how they could grab a linux system and grep /var/log/messages
and it's a defacto standard that shouldn't change and so on  yes I'd
say that would be of importance as a counter point.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Virtual provides for files in /var/log

[Vít Ondruch]

Dne 18.7.2013 11:13, Mathieu Bridon napsal(a):

On Thu, 2013-07-18 at 10:56 +0200, Vít Ondruch wrote:

Dne 18.7.2013 10:42, Mathieu Bridon napsal(a):

On Thu, 2013-07-18 at 10:34 +0200, Vít Ondruch wrote:

Dne 18.7.2013 01:02, Lennart Poettering napsal(a):

So, maybe, instead of dropping the "Provides syslog" thing from
journald, maybe we should add an explicit "syslog-files" dependency (or
something named like that) and then make the classic syslog
implementations provide that and the packages which actually need
/var/log/messages pull that it?

Lennart


So why there are files in /var/log and there is not obvious package,
which creates them (unless you want to guess by name)? Shouldn't all
package, which creates log in /var/log have some virtual provide to make
it obvious? Why not do it properly/consistently?

Why a virtual provides, can't they just %ghost their log files?



That would be the best of course, unfortunately:
https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies

But may be YUM/DNF can be improved in this area

Right, but that's only if you need to express a file requirement.

Your point above was that every package which drops a file in /var/log
(e.g httpd) should have virtual-provides for them.

But I don't think there's ever any reason to require the
file /var/log/https/error_log

On the other hand, Lennart's original mail above was about syslog
implementations, not "all package, which creates log in /var/log".




It was especially about /var/log/messages which should be by Lennart's 
proposal replaced by "syslog-files" virtual provide. How am I supposed 
to know what does this virtual provide means? So I propose to come with 
some generic, understandable way how to let other packages depend on 
some file in /var/log if they need (I left out the question "how common 
case it is" on purpose) and avoid the need of inefficient file 
dependency for this purpose.



Vít


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

Developers guide for Fedora Linux

[Mateusz Marzantowicz]

Hello,

I'm writing some apps for Linux, from time to time. I'd like to know if
there is any comprehensive developers guide for Fedora. I see lot of
changes are made to Fedora (and maybe soon RHEL) like no syslog by
default, systemd machinery, etc. How can one use all that new exciting
features and APIs in their own programs? Please, enlighten me with some
(preferably official) resources e.g. about logging using journald in
C/C++ or Python/Perl.


Thanks in advance,
Mateusz Marzantowicz
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Denys Vlasenko]

On 07/17/2013 06:49 PM, "Jóhann B. Guðmundsson" wrote:
> On 07/17/2013 03:48 PM, Denys Vlasenko wrote:
>> Note that the argument comes from the same group of people
>> who pushed for mounting tmpfs on /run and /tmp.
> 
> So you prefer to have a fragile boot code to empty /run and do you want to be 
> consistent with what other distribution suse/debian/arch and solaris are 
> doing?
> 
> If you want to disable tmp on tmpfs simple run|"||systemctl mask tmp.mount" 
> |||
> 
>> My machine:
>>
>> # df -h
>> Filesystem  Size  Used Avail Use% Mounted on
>> tmpfs   3.9G  4.5M  3.9G   1% /run
>> tmpfs   3.9G  4.9M  3.9G   1% /tmp
>>
>> 10 megs of *RAM* consumed.
>>
>> My /var/log/messages is 12 megabytes at the moment.
>>
>> These same people feel offended by "wasted" 12 megs of *disk space*?
>> Please...
> 
> Yes 10 megs of *RAM* consumed by *you* on *your* machine based on *your* setup
> 
> Same folders on my fully updated always running F18 work laptop
> 
> tmpfs   1.9G  1.2M  1.9G   1% /run
> tmpfs   1.9G  372K  1.9G   1% /tmp
> 
> less then 2MB of *RAM* consumed
> 
> du -hs /var/log/ --exclude=/var/log/journal
> 6.1M/var/log/
> 
> And 6.1M of wasted diskspace on my SSD
> 
> And your point being?

My point is that it is hypocritical to decry a
"huge performance cost" of /var/log/messages
one day and next day eat many megabytes of RAM and
claim that "it's not a big deal".
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Tk-EntryCheck] Perl 5.18 rebuild

[Petr Pisar]

commit e660bdd828bafcb07ae30c85c9f5718cccff0485
Author: Petr Písař 
Date:   Thu Jul 18 12:08:08 2013 +0200

Perl 5.18 rebuild

 perl-Tk-EntryCheck.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Tk-EntryCheck.spec b/perl-Tk-EntryCheck.spec
index a511705..30cf04f 100644
--- a/perl-Tk-EntryCheck.spec
+++ b/perl-Tk-EntryCheck.spec
@@ -1,6 +1,6 @@
 Name:   perl-Tk-EntryCheck
 Version:0.04
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:Interface to Tk::Entry for controlling its length and content
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -49,6 +49,9 @@ test -e ok
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 18 2013 Petr Pisar  - 0.04-5
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 0.04-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_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

Re: Developers guide for Fedora Linux

[Bohuslav Kabrda]

- Original Message -
> Hello,
> 
> I'm writing some apps for Linux, from time to time. I'd like to know if
> there is any comprehensive developers guide for Fedora. I see lot of
> changes are made to Fedora (and maybe soon RHEL) like no syslog by
> default, systemd machinery, etc. How can one use all that new exciting
> features and APIs in their own programs? Please, enlighten me with some
> (preferably official) resources e.g. about logging using journald in
> C/C++ or Python/Perl.
> 
> 
> Thanks in advance,
> Mateusz Marzantowicz

Hi Mateusz,
me with few other people are currently working on a project that you might find 
interesting - devassistant [1], [2].
Basically, it's all about setting development environment (installing 
dependencies, kickstarting projects) in various languages/framework. If you'd 
like to get more info and you can't find it in the docs, feel free to ping me.

Thanks,
Slavek.

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[1] https://developer-assistant.readthedocs.org/en/latest/
[2] https://github.com/bkabrda/devassistant
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Algorithm-Merge] Perl 5.18 rebuild

[Petr Pisar]

commit 43f6afcac7d01b5f9e376922ff84a2303679
Author: Petr Písař 
Date:   Thu Jul 18 12:12:19 2013 +0200

Perl 5.18 rebuild

 perl-Algorithm-Merge.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Algorithm-Merge.spec b/perl-Algorithm-Merge.spec
index 3804336..27ab353 100644
--- a/perl-Algorithm-Merge.spec
+++ b/perl-Algorithm-Merge.spec
@@ -1,6 +1,6 @@
 Name:   perl-Algorithm-Merge
 Version:0.08
-Release:11%{?dist}
+Release:12%{?dist}
 Summary:Three-way merge and diff
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 18 2013 Petr Pisar  - 0.08-12
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 0.08-11
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_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

Re: F20 System Wide Change: No Default Syslog

[Denys Vlasenko]

On 07/18/2013 12:40 AM, Lennart Poettering wrote:
> On Wed, 17.07.13 17:50, Denys Vlasenko (dvlas...@redhat.com) wrote:
> 
>> On 07/17/2013 05:21 PM, john.flor...@dart.biz wrote:
>>>
 From: scl...@netwolves.com
>>>
 This seems like such a specious argument. Maybe it made sense when
 we were talking about disk drives
 that were megabytes in size, but now we have 500 gigabyte drives
 usually as a minimum.
>>>
>>> You don't ever work with embedded systems, do you?
>>
>> If you are running systemd on a embedded system, you are clearly
>> not concerned about saving space :)
> 
> There are actually quite a few embedded devices running systemd these
> days. Wind generators, outer space telescopes, cars, toys, quite a lot
> of other stuff. We do get reports about this from time to time.

Did I say systemd can't be run on an embedded device?

I said that if one runs systemd on a embedded system, then
this device isn't seriously resource constrained.

Do you see that these two statements are not the same?

> So, no snarky comments about embedded devices, please, it's entirely
> inappropriate.

What's inappropriate is giving instructions to others what they can,
or can not say.

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

Re: Developers guide for Fedora Linux

[drago01]

On Thu, Jul 18, 2013 at 11:59 AM, Mateusz Marzantowicz
 wrote:
> Hello,
>
> e.g. about logging using journald in
> C/C++ or Python/Perl.

You can still use syslog() or even just printf(), print(), puts(),
cout << ... etc
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Data-Section-Simple] Perl 5.18 rebuild

[Petr Pisar]

commit e605b5a4f685317c043a7e67e5fb68b2fab12741
Author: Petr Písař 
Date:   Thu Jul 18 12:44:53 2013 +0200

Perl 5.18 rebuild

 perl-Data-Section-Simple.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Data-Section-Simple.spec b/perl-Data-Section-Simple.spec
index e2b2a37..20f197d 100644
--- a/perl-Data-Section-Simple.spec
+++ b/perl-Data-Section-Simple.spec
@@ -3,7 +3,7 @@
 
 Name:  perl-Data-Section-Simple
 Version:   0.05
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Read data from __DATA__
 License:   GPL+ or Artistic
 Group: Development/Libraries
@@ -58,6 +58,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/Data::Section::Simple.3pm*
 
 %changelog
+* Thu Jul 18 2013 Petr Pisar  - 0.05-2
+- Perl 5.18 rebuild
+
 * Tue Jun 11 2013 Paul Howarth  - 0.05-1
 - Update to 0.05
   - Use MakeMaker
--
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-Tk-CursorControl] Perl 5.18 rebuild

[Petr Pisar]

commit a0e765d6d8ef1310318d2b22873eb23f3cc2ff66
Author: Petr Písař 
Date:   Thu Jul 18 12:44:50 2013 +0200

Perl 5.18 rebuild

 perl-Tk-CursorControl.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Tk-CursorControl.spec b/perl-Tk-CursorControl.spec
index 2ea9f63..16ef862 100644
--- a/perl-Tk-CursorControl.spec
+++ b/perl-Tk-CursorControl.spec
@@ -1,6 +1,6 @@
 Name:   perl-Tk-CursorControl
 Version:0.4
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:Manipulate the mouse cursor programmatically
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -54,6 +54,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 18 2013 Petr Pisar  - 0.4-6
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 0.4-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_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

[perl-Cache-FastMmap] Perl 5.18 rebuild

[Petr Pisar]

commit e26fc4704eaa0b55d40cdc70c781a7cea5b920ef
Author: Petr Písař 
Date:   Thu Jul 18 12:45:03 2013 +0200

Perl 5.18 rebuild

 perl-Cache-FastMmap.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Cache-FastMmap.spec b/perl-Cache-FastMmap.spec
index cefd706..66a2d34 100644
--- a/perl-Cache-FastMmap.spec
+++ b/perl-Cache-FastMmap.spec
@@ -1,6 +1,6 @@
 Name:   perl-Cache-FastMmap
 Version:1.40
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:Uses an mmap'ed file to act as a shared memory interprocess 
cache
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -53,6 +53,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 18 2013 Petr Pisar  - 1.40-5
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 1.40-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_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

[perl-NetPacket-LLC] Perl 5.18 rebuild

[Petr Pisar]

commit 0b5c8c4570caa4f1eaf2c25be2a5be6a3c6f871b
Author: Petr Písař 
Date:   Thu Jul 18 12:45:12 2013 +0200

Perl 5.18 rebuild

 perl-NetPacket-LLC.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-NetPacket-LLC.spec b/perl-NetPacket-LLC.spec
index 6ff9c20..99b794c 100644
--- a/perl-NetPacket-LLC.spec
+++ b/perl-NetPacket-LLC.spec
@@ -1,6 +1,6 @@
 Name:   perl-NetPacket-LLC
 Version:0.01
-Release:7%{?dist}
+Release:8%{?dist}
 Summary:Assemble and disassemble IEEE 802.3 LLC protocol packets
 License:Artistic clarified
 Group:  Development/Libraries
@@ -48,6 +48,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 18 2013 Petr Pisar  - 0.01-8
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 0.01-7
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_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

Re: F20 System Wide Change: No Default Syslog

[Lennart Poettering]

On Wed, 17.07.13 22:08, Ding Yi Chen (dc...@redhat.com) wrote:

> > Well, this won't "break" systems as the change is only for new
> > installations. Existing systems will stay exactly as they are, rsyslog
> > stays installed, and will work as always.
> 
> 1. What if they update the system like this:
>Backed up user data/script -> Fresh install -> Restore user data/script
>For that, it won't work.

In such a case, you already need to manually reinstall all packages you
need beyond the default set after the reinstallation. The fewest
people probably stick to exactly the set of packages we install by
default for their systems. rsyslog is now one more of those packages you
need to reinstall after your system is back up.

> 2. Like other already point out, Windows/Fedora dual boot.
>You can see /var/log/messages from Windows, but how can you get
>journalctl output in Windows?

Well, as pointed out before, "journalctl" on Windows helps little if you
cannot access the Linux partitions in the first place, because they are
ext4 or btrfs.

> > > Please update your knowledge, see:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428097
> > > 
> > > They have /var/log/messages, yes, it might be different with ours.
> > > But yes, they have that.
> > 
> > So, they store different stuff in it. The interesting stuff is mostly in
> > daemon.log on Debian. So with your suggested program you'd miss out all
> > the interesting bit son Debian. This stuff is certainly not standardized
> > on Unix systems...
> 
> a) If debian output the thing I want in /var/log/messages anyway, why should 
> I care
>whether other daemon output in other files?

Well, most likely it won't include the interesting bits, because they
are in daemon.log.

I mean, you claim that all distros have /var/log/messages and that
that's where the interesting stuff goes. And that is simply not true. No
ifs, it's just simply not true.

> b) If my environment only contains RHEL and Fedora, why should I care how 
> Debian, Arch and Ubuntu
>handle their logs?

Well, "journalctl" has been available for some time already on Fedora,
and will be in RHEL7 too, so you shouldn't be too concerned there.

> > > Innovation should not be the cost of reliability and portability.
> > 
> > This change touches neither. /var/log/messages already isn't standard in
> > whether it exists at all, and what it contains, so we certainly don't
> > make "portability" worse...
> 
> Something is not standard does not mean nobody using it.

No it doesn't. Every package in the Fedora archive is used by somebody,
but that doesn't mean we install *all* packages always. We try to
install a default set that tries neither to be minimal, nor to include
everything possible. Something that one can work with and that has
little redundancy.

> Especially it is there quite a long time.
> Remove it simply break their expectation and scripts.
> For that, you do make the portability worse.

No, not true by any definition of the word "portability".

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Lennart Poettering]

On Wed, 17.07.13 22:35, Ding Yi Chen (dc...@redhat.com) wrote:

> This should be simpler than forcing those stubborn mind (such as me) to 
> change,
> No?

We don't force anyone. You can just install rsyslog and you have
everything as you love it. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd

[Bastien Nocera]

- Original Message -
> On Wed, 17 Jul 2013, Chris Adams wrote:
> 
> > Once upon a time, Jaroslav Reznik  said:
> >> ntpdate is slowly being depricated. STIG enhancements for RHEL 6 penalize
> >> systems that make use of ntpdate. Also documentation from the NSA
> >> Hardening
> >> Guidelines as well as CIS Hardening documentation recommends disabling the
> >> use
> >> of ntpd as a full-time daemon.
> 
> > The NTP project has been trying to deprecate ntpdate for a long time
> > now,
> 

> 
> Additionally, with systems without a realtime clock, like the raspberry
> pi,

> Finally, for an easy fix for rebooting raspberry pi and co,


The Raspberry Pi can't run an unmodified Fedora (eg. we don't produce any 
binaries that
can run on its CPU). Is there supported hardware that has that problem?

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

Re: F20 System Wide Change: No Default Syslog

[Lennart Poettering]

On Wed, 17.07.13 23:36, Michael Catanzaro (mike.catanz...@gmail.com) wrote:

> On Wed, 2013-07-17 at 14:58 +0200, Lennart Poettering wrote:
> > We ask this constantly on Fedora. Because Fedora is where innovation is
> > supposed to take place, not where things are stay frozen in carbonite
> > forever.
> > 
> > (And let's never forget that Fedora is not the pioneer here. ArchLinux
> > went journal-only already. We are not actually the innovators here, we
> > just follow.)
> 
> I believe openSUSE 12.3 does not install syslog anymore either. (I think
> they decided they did not want to log everything twice? :) Fedora's
> following this time.

They do still install syslog. ArchLinux doesn't anymore however.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Virtual provides for files in /var/log

[Lennart Poettering]

On Thu, 18.07.13 10:34, Vít Ondruch (vondr...@redhat.com) wrote:

> Dne 18.7.2013 01:02, Lennart Poettering napsal(a):
> >So, maybe, instead of dropping the "Provides syslog" thing from
> >journald, maybe we should add an explicit "syslog-files" dependency (or
> >something named like that) and then make the classic syslog
> >implementations provide that and the packages which actually need
> >/var/log/messages pull that it?
> >
> >Lennart
> >
> 
> So why there are files in /var/log and there is not obvious package,
> which creates them (unless you want to guess by name)? Shouldn't all
> package, which creates log in /var/log have some virtual provide to
> make it obvious? Why not do it properly/consistently?

So, you suggest using "Requires: /var/log/messages" and "Provides:
/var/log/messages" as indication for this, and the %ghost
/var/log/messages in the packages in question?

Sounds good to me! Matthew?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd

[Peter Robinson]

>> > Once upon a time, Jaroslav Reznik  said:
>> >> ntpdate is slowly being depricated. STIG enhancements for RHEL 6 penalize
>> >> systems that make use of ntpdate. Also documentation from the NSA
>> >> Hardening
>> >> Guidelines as well as CIS Hardening documentation recommends disabling the
>> >> use
>> >> of ntpd as a full-time daemon.
>>
>> > The NTP project has been trying to deprecate ntpdate for a long time
>> > now,
>>
> 
>>
>> Additionally, with systems without a realtime clock, like the raspberry
>> pi,
> 
>> Finally, for an easy fix for rebooting raspberry pi and co,
>
>
> The Raspberry Pi can't run an unmodified Fedora (eg. we don't produce any 
> binaries that
> can run on its CPU). Is there supported hardware that has that problem?

Yes, most of the dev boards don't have batteries. PandaBoard, Beagle* etc.

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

Re: Virtual provides for files in /var/log

[Vít Ondruch]

Dne 18.7.2013 14:19, Lennart Poettering napsal(a):

On Thu, 18.07.13 10:34, Vít Ondruch (vondr...@redhat.com) wrote:


Dne 18.7.2013 01:02, Lennart Poettering napsal(a):

So, maybe, instead of dropping the "Provides syslog" thing from
journald, maybe we should add an explicit "syslog-files" dependency (or
something named like that) and then make the classic syslog
implementations provide that and the packages which actually need
/var/log/messages pull that it?

Lennart


So why there are files in /var/log and there is not obvious package,
which creates them (unless you want to guess by name)? Shouldn't all
package, which creates log in /var/log have some virtual provide to
make it obvious? Why not do it properly/consistently?

So, you suggest using "Requires: /var/log/messages" and "Provides:
/var/log/messages" as indication for this, and the %ghost
/var/log/messages in the packages in question?

Sounds good to me! Matthew?

Lennart



I would suggest it, but it is not recommended by guidelines :( so I 
suggest some (not yet) standardized virtual provide, which will be more 
descriptive than "syslog-files"



Vít


[1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Virtual provides for files in /var/log

[Lennart Poettering]

On Thu, 18.07.13 14:23, Vít Ondruch (vondr...@redhat.com) wrote:

> Dne 18.7.2013 14:19, Lennart Poettering napsal(a):
> >On Thu, 18.07.13 10:34, Vít Ondruch (vondr...@redhat.com) wrote:
> >
> >>Dne 18.7.2013 01:02, Lennart Poettering napsal(a):
> >>>So, maybe, instead of dropping the "Provides syslog" thing from
> >>>journald, maybe we should add an explicit "syslog-files" dependency (or
> >>>something named like that) and then make the classic syslog
> >>>implementations provide that and the packages which actually need
> >>>/var/log/messages pull that it?
> >>>
> >>>Lennart
> >>>
> >>So why there are files in /var/log and there is not obvious package,
> >>which creates them (unless you want to guess by name)? Shouldn't all
> >>package, which creates log in /var/log have some virtual provide to
> >>make it obvious? Why not do it properly/consistently?
> >So, you suggest using "Requires: /var/log/messages" and "Provides:
> >/var/log/messages" as indication for this, and the %ghost
> >/var/log/messages in the packages in question?
> >
> >Sounds good to me! Matthew?
> >
> >Lennart
> >
> 
> I would suggest it, but it is not recommended by guidelines :( so I
> suggest some (not yet) standardized virtual provide, which will be
> more descriptive than "syslog-files"
>
> Vít
> 
> [1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies

I guess this comment doesn't apply if we explicitly add Provides:
/var/log/messages to all packages that provide the file. Hmm, or maybe
no, I don't grok RPM well enough...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F20 Self Contained Change: Enlightenment

[Jaroslav Reznik]

= Proposed Self Contained Change: Enlightenment =
https://fedoraproject.org/wiki/Changes/Enlightenment

Change owner(s): Rahul Sundaram , Christopher 
Meng , Dan Mashal 

Enlightenment 0.17 a new stable release has been released after 12 years or so 
of development. As many desktops are being landed on Fedora, Integrating 
Enlightenment in Fedora can not only enlarge the number of available desktops 
in Fedora, but also improve user experiences and give users another choice of 
Desktop Environment. 

== Detailed description ==
Enlightenment 0.17 (a.k.a E17) is the next generation of graphical desktop 
shell from the Enlightenment project. When you first run it and get past the 
initial setup wizard, you should end up with a desktop not unlike the above. 
It is a very traditional UNIX/X11 style desktop, because that is what E 
primarily is and attempts to be, BUT with a bunch of bells, whistles and 
modernities that were never there, as well as a different core design 
philosophy. There seems to be some obsession with Window Manager vs. Desktop 
Environment debates. It doesn't much matter what you call it. It manages 
windows. It does compositing. It manages files. It launches applications. It 
handles UI and system settings.

Before we go any further, it is time to clean up some common misconceptions.

* First, Enlightenment is not new. It is OLD.
* It predates larger desktop environments like GNOME or XFCE. It is just 
barely younger than KDE.
* It never started life as an attempt to "be a full desktop environment".
* It started life as simply a window manager. This was back towards the latter 
part of 1996, and its first 0.1 release came in the first part of 1997. It was 
a 
window manager with some extras to scratch the itch that "everything was gray 
bevels and UIs had to be plain to be functional or useful, and that 
computers/X11 were not capable of more".
* It handily proved that to be wrong. It could manage function AND form more 
flexibly than anything else, and to this date is still in an enviable position 
of flexibility in both behavior features and in terms of visuals. In fact, its 
Achilles heel simply may be that it has too many options and too much 
flexibility. Some of the extras filled in the gaps, like setting wallpaper, 
that 
was always done by 3rd party tools and not the window manager at the time. If 
you are after a constrained and simple UI, then Enlightenment (E) is not for 
you. It can be configured to be plain and simple if you try, or to be buzzing 
with activity and complexity, but this is up to you. Its default is somewhere 
in between these to give you a taste of what it can do on both ends of the 
spectrum. 

The default look is not what you are stuck with. Enlightenment was the first 
Window Manager (WM) to introduce themes in X11 (pre-packaged sets of data that 
you just grab and select, providing you with a vast new look and feel). Today 
in Enlightenment, these themes come as "Edje" files (.edj), and are pre-
packaged data files containing all images, layout, animation etc. that you may 
need. They never get "unpacked". They are used "live as-is", and only the data 
needed from the file is sourced and decoded, so even if the theme is massive, 
only the pieces needed at any one time are decoded into memory, which is 
normally a fraction of the actual file size. They are also live data and need 
to be there while E17 runs as it is forever digging bits of data out of these 
files as it needs it. It is an accepted fact that the default look will not be 
for everyone. It tries to strike a balance of being unique (not mimicking some 
other desktop look), yet still being stylish. It is meant to echo some of the 
past from where Enlightenment comes from, and yet roll in modern effects and 
feels. It sacrifices some "usability" for look, yet tries to keep a balance and 
still be functional. It will not be for everyone, but it is hoped that it 
keeps you mostly happy until you find other themes that exactly meet your 
visual needs. You will find this as an on-going philosophy in Enlightenment. 
One size does NOT fit all. That's what options are for. Thats why we have 
themes. Do not have the misconception that what you see is what you are stuck 
with. You are expected to experiment and discover what is good for you. Maybe 
the default is fine. Maybe it is not. That's why we pioneered themes and spent 
immense amounts of time making them nicely packaged, efficient and powerful 
enough to fine-tune almost any aspect of the UI. 

== Scope ==
Just package every dependency and promise that they can be reviewed 'PASS'.

* Proposal owners: Package all dependencies and push them to review queue. 
* Other developers: Keep existed dependency packages updated, make sure the 
default backgrounds and theme is available. 
* Release engineering: Nothing here currently. If there are sufficient 
interests 
and participation, a Fedora Enlightenment spin could be released. 
* Policies and guideline

Re: F20 System Wide Change: No Default Syslog

[Michael Catanzaro]

On Thu, 2013-07-18 at 14:17 +0200, Lennart Poettering wrote:
> > I believe openSUSE 12.3 does not install syslog anymore either. (I
> think
> > they decided they did not want to log everything twice? :) Fedora's
> > following this time.
Hm OK.  They definitely dropped it from the default install late last
year (caused a bit of a stir) and from a quick check online it looked
like they had not reversed that choice, but I didn't check an actual
system.


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

rawhide report: 20130718 changes

[Fedora Rawhide Report]

Compose started at Thu Jul 18 08:15:02 UTC 2013

Broken deps for x86_64
--
[MUMPS]
MUMPS-4.10.0-9.fc20.i686 requires libmpi_f77.so.1
MUMPS-4.10.0-9.fc20.x86_64 requires libmpi_f77.so.1()(64bit)
MUMPS-examples-4.10.0-9.fc20.x86_64 requires libmpi_f77.so.1()(64bit)
[aws]
aws-2.11.0-16.fc20.i686 requires libxmlada_unicode.so.4.3w
aws-2.11.0-16.fc20.i686 requires libxmlada_schema.so.4.3w
aws-2.11.0-16.fc20.i686 requires libxmlada_sax.so.4.3w
aws-2.11.0-16.fc20.i686 requires libxmlada_input_sources.so.4.3w
aws-2.11.0-16.fc20.i686 requires libxmlada_dom.so.4.3w
aws-2.11.0-16.fc20.x86_64 requires libxmlada_unicode.so.4.3w()(64bit)
aws-2.11.0-16.fc20.x86_64 requires libxmlada_schema.so.4.3w()(64bit)
aws-2.11.0-16.fc20.x86_64 requires libxmlada_sax.so.4.3w()(64bit)
aws-2.11.0-16.fc20.x86_64 requires 
libxmlada_input_sources.so.4.3w()(64bit)
aws-2.11.0-16.fc20.x86_64 requires libxmlada_dom.so.4.3w()(64bit)
aws-tools-2.11.0-16.fc20.x86_64 requires 
libxmlada_unicode.so.4.3w()(64bit)
aws-tools-2.11.0-16.fc20.x86_64 requires 
libxmlada_schema.so.4.3w()(64bit)
aws-tools-2.11.0-16.fc20.x86_64 requires libxmlada_sax.so.4.3w()(64bit)
aws-tools-2.11.0-16.fc20.x86_64 requires 
libxmlada_input_sources.so.4.3w()(64bit)
aws-tools-2.11.0-16.fc20.x86_64 requires libxmlada_dom.so.4.3w()(64bit)
[blacs]
blacs-openmpi-1.1-49.fc20.x86_64 requires libmpi_f77.so.1()(64bit)
[cp2k]
cp2k-openmpi-2.4-3.fc20.x86_64 requires libmpi_f90.so.1()(64bit)
cp2k-openmpi-2.4-3.fc20.x86_64 requires libmpi_f77.so.1()(64bit)
[derelict]
derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod
derelict-tcod-3-20.20130626gite70c293.fc20.x86_64 requires tcod
derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod
derelict-tcod-devel-3-20.20130626gite70c293.fc20.x86_64 requires tcod
[devtodo2]
devtodo2-2.1-5.20120711git8dee6.fc20.x86_64 requires libgo.so.3()(64bit)
[dnf]
dnf-0.3.9-1.giteff4c49.fc20.noarch requires python-librepo = 0:0.0.4
dnf-0.3.9-1.giteff4c49.fc20.noarch requires python-hawkey = 0:0.3.14
[dragonegg]
dragonegg-3.3-2.fc20.x86_64 requires gcc = 0:4.8.1-4.fc20
[ga]
ga-openmpi-5.1.1-3.fc20.x86_64 requires libmpi_f90.so.1()(64bit)
ga-openmpi-5.1.1-3.fc20.x86_64 requires libmpi_f77.so.1()(64bit)
[gdb-heap]
gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17
[gitifyhg]
gitifyhg-0.8.2-2.fc20.noarch requires python-path
[glabels]
glabels-3.0.1-8.fc20.x86_64 requires libcamel-1.2.so.43()(64bit)
[glusterfs]
glusterfs-ufo-3.4.0-2.fc20.noarch requires openstack-swift-proxy = 
0:1.8.0
glusterfs-ufo-3.4.0-2.fc20.noarch requires openstack-swift-object = 
0:1.8.0
glusterfs-ufo-3.4.0-2.fc20.noarch requires openstack-swift-container = 
0:1.8.0
glusterfs-ufo-3.4.0-2.fc20.noarch requires openstack-swift-account = 
0:1.8.0
glusterfs-ufo-3.4.0-2.fc20.noarch requires openstack-swift = 0:1.8.0
[gnome-photos]
gnome-photos-3.9.4-1.fc20.x86_64 requires gnome-online-miners
[gr-air-modes]
gr-air-modes-0-0.13.20130409gitf25d21f5.fc20.i686 requires 
libgruel-3.6.5.so.0.0.0
gr-air-modes-0-0.13.20130409gitf25d21f5.fc20.i686 requires 
libgnuradio-core-3.6.5.so.0.0.0
gr-air-modes-0-0.13.20130409gitf25d21f5.fc20.x86_64 requires 
libgruel-3.6.5.so.0.0.0()(64bit)
gr-air-modes-0-0.13.20130409gitf25d21f5.fc20.x86_64 requires 
libgnuradio-core-3.6.5.so.0.0.0()(64bit)
[gr-osmosdr]
gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.i686 requires 
libgruel-3.6.5.so.0.0.0
gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.i686 requires 
libgnuradio-fcd-3.6.5.so.0.0.0
gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.i686 requires 
libgnuradio-core-3.6.5.so.0.0.0
gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.x86_64 requires 
libgruel-3.6.5.so.0.0.0()(64bit)
gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.x86_64 requires 
libgnuradio-fcd-3.6.5.so.0.0.0()(64bit)
gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.x86_64 requires 
libgnuradio-core-3.6.5.so.0.0.0()(64bit)
gr-osmosdr-devel-0.0.1-3.20130403gite85c68d9.fc20.i686 requires 
pkgconfig(gnuradio-core)
gr-osmosdr-devel-0.0.1-3.20130403gite85c68d9.fc20.x86_64 requires 
pkgconfig(gnuradio-core)
[gtkd]
gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60
gtkd-2.0.0-29.20120815git9ae9181.fc18.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[indi-apogee]
indi-apogee-1.0-11.fc20.x86_64 requires libcfitsio-3.340.so.0()(64bit)
[jboss-as]
jboss-as-7.1.1-19.fc20.noarch requires cxf-common >= 0:2.6.3
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[koji]
koji-vm-1.8.0-1.fc20.noarch requires python-virtinst
[kstars]
   

Re: Virtual provides for files in /var/log

[Panu Matilainen]

On 07/18/2013 03:28 PM, Lennart Poettering wrote:

On Thu, 18.07.13 14:23, Vít Ondruch (vondr...@redhat.com) wrote:


Dne 18.7.2013 14:19, Lennart Poettering napsal(a):

On Thu, 18.07.13 10:34, Vít Ondruch (vondr...@redhat.com) wrote:


Dne 18.7.2013 01:02, Lennart Poettering napsal(a):

So, maybe, instead of dropping the "Provides syslog" thing from
journald, maybe we should add an explicit "syslog-files" dependency (or
something named like that) and then make the classic syslog
implementations provide that and the packages which actually need
/var/log/messages pull that it?

Lennart


So why there are files in /var/log and there is not obvious package,
which creates them (unless you want to guess by name)? Shouldn't all
package, which creates log in /var/log have some virtual provide to
make it obvious? Why not do it properly/consistently?

So, you suggest using "Requires: /var/log/messages" and "Provides:
/var/log/messages" as indication for this, and the %ghost
/var/log/messages in the packages in question?

Sounds good to me! Matthew?

Lennart



I would suggest it, but it is not recommended by guidelines :( so I
suggest some (not yet) standardized virtual provide, which will be
more descriptive than "syslog-files"

Vít

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies


I guess this comment doesn't apply if we explicitly add Provides:
/var/log/messages to all packages that provide the file. Hmm, or maybe
no, I don't grok RPM well enough...


Well the guideline is really just a recommendation for optimizing yum 
behavior, nothing more. But yes, an explicit "Provides: /some/path" goes 
into the main repository metadata so resolving a dependency on that path 
doesn't require downloading the big bad file lists.


- Panu -


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

Re: F20 System Wide Change: No Default Syslog

[Nicolas Mailhot]

Le Mar 16 juillet 2013 18:42, Lennart Poettering a écrit :
> On Tue, 16.07.13 18:09, Till Maas (opensou...@till.name) wrote:
>
>> On Tue, Jul 16, 2013 at 01:43:04PM +0200, Lennart Poettering wrote:
>> > On Tue, 16.07.13 09:42, Till Maas (opensou...@till.name) wrote:
>> >
>> > > > journalctl only supports local time specifications when you
>> > > > specify calendar times. Unfortunately there's no nice API to map
>> > > > calendar times that include time zone specifications back to UTC,
>> in
>> > > > particular because the time zone names are not unique...
>> > > > While it will be hard to support arbitrary timezone specs in
>> --since= it
>> > > > should be relatively easy to support UTC in addition to the local
>> > > > timezone. Added this to the TODO list.
>> > >
>> > > You only need to add or subtract hours and minutes from the local
>> time,
>> > > because ISO 8601 dates contain the UTC offset:
>> > >
>> > > | $ date --iso-8601=seconds
>> > > | 2013-07-15T22:37:04+0200
>> >
>> > Well, we can certainly add support for such numeric timezone specs
>> > (added to the TODO list), but I have my doubts that this is actually
>> > what people want to use in their day-to-day use, given that the
>> numbers
>> > are hard to remember.
>>
>> Thank you.
>>
>> > I am pretty sure that most folks would like to specify symbolic
>> timezone
>> > names, but that's hard to do due to lack of APIs for that, and the
>> > non-uniqueness of the names.
>>
>> I guess for most use cases using the local time zone is enough.
>>
>> Btw. can journalctl output ISO 8601 dates instead of the US formated
>> date without a year? I really expected journalctl to cleanup this as
>> well.
>
> In the default output we stay true to the formatting that has been used
> in /var/log/messages since always.
>
> We currently do not use the ISO date format anywhere, it's not really
> readable, I think.

It's not really readable because you're not used to seeing it. You're not
used to seeing it because you (and others) have invented custom
alternatives. Seems a self-inflicted problem to me (just like most of the
"UTF-8 is too complex, it's simpler to use _pet-endoding_" were)

> Great way to serialize dates, recurring and duration
> events to ascii strings for computers to read, but not really for
> humans.
>
> Note that in all other places we tend to use date format like this: "Tue
> 2013-07-16 18:41:57 CEST" Which is close to ISO, but not ISO.

While replacing T with space is common (even though it will break field
tokenization in many apps) Tue is a pure Englicism (useless in most parts
of the world) and CEST will break interoperability (since people love to
invent new names for time zones. That's why the ISO numeric adjustment is
way saner).

Also "tend to" means "I'm not consistent and other apps and people can not
rely on any specific convention when dealing with me"

-- 
Nicolas Mailhot

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

Re: F20 System Wide Change: No Default Syslog

[John . Florian]

> From: mzerq...@0pointer.de
> 
> On Wed, 17.07.13 11:48, Bill Nottingham (nott...@redhat.com) wrote:
> 
> > john.flor...@dart.biz (john.flor...@dart.biz) said: 
> > > >   You can provide binary path (_EXE=) by ”journalctl 
/usr/sbin/sshd”.
> > > 
> > > Yes, but that's of little help with applications using interpreted 
> > > languages (e.g., python).  I want to match on the name of the python 

> > > program, not python itself.
> > 
> > journalctl _COMM= works for me on F19.
> 
> Also, to mention this explicitly: there is command line completion for
> this. I.e. type "journalctl _CO", press Tab, and it will autocomplete to
> "journalctl _COMM=", then press Tab Tab and it shows you a list of all
> values that so far have been recorded.
> 
> This is realy, really useful actually.

Huh.  Given how it seems that I hit Tab nearly every other keystroke I'm 
surprised I hadn't stumbled onto that yet.  Probably because I haven't 
gotten much into the habit of filtering with these terms.  I'm still so 
pleased just having -u (and the wonderful extra info conveyed via color) 
that it's hard to grumble about much else.  :-)

I may have avoided these largely because I knew it would take time to 
learn the various names.  But now I know I can "journalctl _ " 
and have an instant refresher.  Thanks for such a well-done tool.

--
John Florian


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

Re: F20 System Wide Change: No Default Syslog

[Chris Adams]

Once upon a time, "Jóhann B. Guðmundsson"  said:
> Currently we are shipping around 550 - 600 components that ship
> services/daemons most but probably not all can use syslog but may
> not be configured to do so which may or may not be affect by the act
> of changing to binary logger I guess depending on which IETF syslog
> standards that binary logger supports?

Lots of programs don't use syslog because it isn't sufficient for their
needs.  For some, there is not liable to be any common logging setup
that will work for them.

However, as I've said repeatedly, your "yum whatprovides" check is flat
wrong, and so is your repeated 550-600 components claim.  If you look at
the number of packages that provide something in /var/log (rather than
your bogus "number of entries under /var/log" check), it comes to a much
smaller number.

I come up with 216 packages (in F18) that put files under /var/log.
However, even that number is inflated; some of those are not an issue.
A few examples:

- setup: has /var/log/lastlog
- util-linux: also has /var/log/lastlog
- initscripts: has /var/log/{w,b}tmp
- pam: has /var/log/tallylog
- ntp: puts stats in /var/log/ntpstats
- sendmail: puts stats in /var/log/mail

That's just a few I recognize and/or am familiar with.  I'm sure there
are others that provide something under /var/log that have absolutely no
issue related to logging (/var/log is sometimes used as a catch-all for
"things that change a lot").

Please stop with the 600 package "scare" number.

> And as we all know log files are used for audits, for evidence in
> legal actions, for incident response, to reduce liability, and for
> various legal and regulatory compliance reasons so so we need to
> look into  log alerting and parsing tools like but not limited
> to...||

That is a completely different requirement; if you want to look at
auditable logging, that is way outside the scope of rsyslog vs.
journald (since neither is any different with respect to security).
Bringing that into a discussion of whether to remove syslog is far more
off-topic than bikeshedding about the journalctl output, options, etc.

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

Re: Fixing proxy support in Fedora (was Re: Orphaning few packages)

[David Woodhouse]

On Fri, 2013-06-07 at 01:19 +0800, Christopher Meng wrote:
> On Thu, Jun 6, 2013 at 6:55 PM, David Woodhouse  wrote:
> > On Wed, 2013-06-05 at 12:08 +0800, Christopher Meng wrote:
> >> libproxy taken.
> >
> > I'm also very interested in libproxy. Would you mind if I comaintain it?
> 
> Please request the commit privilege if you want to maintain it. That's all...

I've just pushed a 0.4.11-5 build to rawhide with support for PacRunner
(which is also now in Fedora now).

So there's a libproxy-pacrunner subpackage, like all the other
subpackages, that will do nothing but query PacRunner.

I'm separately working on fixing NetworkManager to actually *tell*
PacRunner the current proxy configuration, as derived from the network
connection (either automatically or via manual per-connection settings).

But it's actually relatively simple to hack around that for now with a
NM dispatcher script. Having libproxy-pacrunner available is the
important missing piece of the puzzle for now.

I'd like to push this as a Fedora 19 update too; do you have any
objections? It shouldn't make *any* difference to anyone who doesn't
install it. 

I note that Colin's update to use mozjs17 is sitting in the F19 tree but
not pushed as an update. We should be pushing that out too, right?

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Virtual provides for files in /var/log

[Lennart Poettering]

On Thu, 18.07.13 15:47, Panu Matilainen (pmati...@laiskiainen.org) wrote:

> >>I would suggest it, but it is not recommended by guidelines :( so I
> >>suggest some (not yet) standardized virtual provide, which will be
> >>more descriptive than "syslog-files"
> >>
> >>Vít
> >>
> >>[1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies
> >
> >I guess this comment doesn't apply if we explicitly add Provides:
> >/var/log/messages to all packages that provide the file. Hmm, or maybe
> >no, I don't grok RPM well enough...
> 
> Well the guideline is really just a recommendation for optimizing
> yum behavior, nothing more. But yes, an explicit "Provides:
> /some/path" goes into the main repository metadata so resolving a
> dependency on that path doesn't require downloading the big bad file
> lists.

Hmm, Panu, but who does this exactly work? If at least one package
explicitly provides /some/path, and some others only implicitly provide
it, is the big bad file list download skipped? 

Which would mean either *none* of the providers shall explicitly provide
the file (which would be slow), or *all* of the provides explicitly
provide the file? If some would explicitly provide it, and others only
implicitly, then things would be broken?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Ralf Corsepius]

On 07/17/2013 03:35 PM, Chuck Anderson wrote:

On Wed, Jul 17, 2013 at 03:30:20PM +0200, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jul 17, 2013 at 08:56:45AM -0400, Chuck Anderson wrote:

Is there a way to read binary journals from non-Linux OSes?

Compiling journalctl on UINXy OSes should not be too much of a problem.
You'd need dbus >= 1.4.0, libcap, liblzma (if used by the journal files
in question). Not trivial but certainly doable.

Zbyszek


I was more thinking of the typical home use case, where a user has
installed Fedora alongside Windows or Mac OS.
My use case is using a different Linux distro for trouble shooting, 
either installed alongside Fedora[1] or booting it from usb-stick/CD/DVD 
[2] or external HD[3].


Ralf

[1] Often older versions of Fedora or CentOS.
[2] e.g. systemrescuecd
[3] There has been a time, I carried around a customized CentOS 
installation on external HD just for troubleshooting.



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

Re: F20 System Wide Change: No Default Syslog

[Jóhann B. Guðmundsson]

On 07/18/2013 01:30 PM, Chris Adams wrote:

However, as I've said repeatedly, your "yum whatprovides" check is flat
wrong, and so is your repeated 550-600 components claim.  If you look at
the number of packages that provide something in /var/log (rather than
your bogus "number of entries under /var/log" check), it comes to a much
smaller number.


I dont know why you continue to claim that I'm dealing with bullshit 
numbers


F18 units, sys V initscripts thus services/daemons

$  repoquery --whatprovides '/usr/lib/systemd/system/*' --qf "%{name}" | 
sort -u | wc -l

569

Legacy sysv initscrips

$ repoquery --whatprovides '/etc/rc.d/init.d/*' --qf "%{name}" | sort -u 
| egrep -v '(-sysvinit|-initscript|-sysv)$' | wc -l

166

Total number of units/sysV initscripts/daemon in F18 = 762

You running

$ repoquery --whatprovides '/var/log/*' --qf "%{name}" | sort -u | wc -l
219

Only proves that out of that 762 only 219 of those might be providing 
files /var/log ( while in fact that number ain't accurate in relation to 
unit,services and daemons )


Let's shave off 200 units due to them not being type service units and 
multiple units or legacy sysv inscription might be shipped in the same 
package which gives you 550 - 600 components range I was talking about...


Go through those 550 - 600 components and see how many of those for 
example are shipping log files, logrotation and logwatch files when they 
should or should not...


JBG

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

Summary of accepted Fedora 20 Changes - week 29

[Jaroslav Reznik]

Greeting!
This is a summary of accepted Fedora 20 Changes by FESCo for week 29 
(2013-07-17 meeting).

= System Wide Changes =
* Fedora 20 Boost 1.54 Uplift - 
https://fedoraproject.org/wiki/Changes/F20Boost154 announced on 2013-07-08 
https://lists.fedoraproject.org/pipermail/devel/2013-July/184929.html

* ARM as primary Architecture - 
https://fedoraproject.org/wiki/Changes/ARM_as_Primary announced on 2013-07-09 
https://lists.fedoraproject.org/pipermail/devel/2013-July/184962.html

FESCo resolution: Build ARM on primary infrastructure. Whether it is released 
as a primary Fedora 20 or as 'Fedora 20 for ARM' depends on how well it 
fulfills release criteria and functionality criteria closer to release time. 

= Self Contained Changes =
* Hadoop - ​https://fedoraproject.org/wiki/Changes/Hadoop announced on 
2013-07-10 
​https://lists.fedoraproject.org/pipermail/devel/2013-July/185026.html

* Shared Certificate Tools - ​
https://fedoraproject.org/wiki/Changes/SharedCertificateTools announced on 
2013-07-10 
​https://lists.fedoraproject.org/pipermail/devel/2013-July/185027.html

* SDDM as the default KDE DM - ​
https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM announced on 
2013-07-10 
​https://lists.fedoraproject.org/pipermail/devel/2013-July/185118.html

* KDE Plasma Workspaces 4.11 - ​https://fedoraproject.org/wiki/Changes/KDE411 
announced on 2013-07-11 (one day less but no complaints raised on devel list) 
​https://lists.fedoraproject.org/pipermail/devel/2013-July/185132.html

* Yesod Web Framework - ​
https://fedoraproject.org/wiki/Changes/YesodWebFramework announced on 
2013-07-11 (one day less but no complaints raised on devel list) ​
https://lists.fedoraproject.org/pipermail/devel/2013-July/185141.html

* ARM on x86 with libvirt/virt-manager - ​
https://fedoraproject.org/wiki/Changes/Virt_ARM_on_x86 announced on 2013-07-11 
(one day less but no complaints raised on devel list) ​
https://lists.fedoraproject.org/pipermail/devel/2013-July/185151.html

* VM Snapshot UI with virt-manager - ​
https://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots announced on 
2013-07-11 (one day less but no complaints raised on devel list) ​
https://lists.fedoraproject.org/pipermail/devel/2013-July/185152.html
___
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

[389-devel] Jenkins build is back to normal : 389-ds-base #75

[jenkins]

See 

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

Re: F20 System Wide Change: No Default Syslog

[Lennart Poettering]

On Thu, 18.07.13 14:56, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote:

> > In the default output we stay true to the formatting that has been used
> > in /var/log/messages since always.
> >
> > We currently do not use the ISO date format anywhere, it's not really
> > readable, I think.
> 
> It's not really readable because you're not used to seeing it. You're not
> used to seeing it because you (and others) have invented custom
> alternatives. Seems a self-inflicted problem to me (just like most of the
> "UTF-8 is too complex, it's simpler to use _pet-endoding_" were)

No, it's not readable, because it's just not readable. It doesn't
include whitespace as separators, which could help people to read the
string. It also doesn't include day of week information which is highly
interesting to most people.

But anyway, I understand you like ISO, and think it is readable. I don't
agree, but we just have to agree to disagree on this one. It might
thrill you though to learn that I just commited a patch by Tomasz that
adds an ISO output mode to journalctl. "journalctl -o short-iso" is your
friend.

And the nice thing: you can actually switch forth and back with this at
display time! Instead of choosing your date format before the log files
are written, you can actually choose at display time! How awesome is
that?

> > Great way to serialize dates, recurring and duration
> > events to ascii strings for computers to read, but not really for
> > humans.
> >
> > Note that in all other places we tend to use date format like this: "Tue
> > 2013-07-16 18:41:57 CEST" Which is close to ISO, but not ISO.
> 
> While replacing T with space is common (even though it will break field
> tokenization in many apps) Tue is a pure Englicism (useless in most parts
> of the world) and CEST will break interoperability (since people love to
> invent new names for time zones. That's why the ISO numeric adjustment is
> way saner).

The "Tue" is actually in your local language based on system
locale. Hence for you "mar." or so.

> Also "tend to" means "I'm not consistent and other apps and people can not
> rely on any specific convention when dealing with me"

Well, if you think we are generally confused and unreliable folks, then
go ahead and think that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing proxy support in Fedora (was Re: Orphaning few packages)

[Nicolas Chauvet]

2013/7/18 David Woodhouse 

> On Fri, 2013-06-07 at 01:19 +0800, Christopher Meng wrote:
> > On Thu, Jun 6, 2013 at 6:55 PM, David Woodhouse 
> wrote:
> > > On Wed, 2013-06-05 at 12:08 +0800, Christopher Meng wrote:
> > >> libproxy taken.
> > >
> > > I'm also very interested in libproxy. Would you mind if I comaintain
> it?
> >
> > Please request the commit privilege if you want to maintain it. That's
> all...
>
> I've just pushed a 0.4.11-5 build to rawhide with support for PacRunner
> (which is also now in Fedora now).
>
> So there's a libproxy-pacrunner subpackage, like all the other
> subpackages, that will do nothing but query PacRunner.
>
> I'm separately working on fixing NetworkManager to actually *tell*
> PacRunner the current proxy configuration, as derived from the network
> connection (either automatically or via manual per-connection settings).
>
> But it's actually relatively simple to hack around that for now with a
> NM dispatcher script. Having libproxy-pacrunner available is the
> important missing piece of the puzzle for now.
>

Should the dispatcher script be provided by the libproxy-pacrunner
sub-package ? Or NM ?

There is probably a need to have theses sub-packages properly installed by
default ?
(with the appropriate plugins). Does having particular package set by
default should be a feature ?

Nicolas (kwizart)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-MIME-tools] Rebuilt for perl 5.18

[Jochen Schmitt]

commit cc078c0a934a4bde68749d755308870bdf856be3
Author: Jochen Schmitt 
Date:   Thu Jul 18 16:52:25 2013 +0200

Rebuilt for perl 5.18

 perl-MIME-tools.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-MIME-tools.spec b/perl-MIME-tools.spec
index 5f2d251..eccfab5 100644
--- a/perl-MIME-tools.spec
+++ b/perl-MIME-tools.spec
@@ -1,7 +1,7 @@
 Summary:   Modules for parsing and creating MIME entities in Perl
 Name:  perl-MIME-tools
 Version:   5.504
-Release:   1%{?dist}
+Release:   2%{?dist}
 Group: Development/Libraries
 License:   GPL+ or Artistic
 URL:   http://search.cpan.org/dist/MIME-tools/
@@ -114,6 +114,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/MIME::Words.3pm*
 
 %changelog
+* Thu Jul 18 2013 Jochen Schmitt  - 5.504-2
+- Rebuilt for perl 5.18
+
 * Thu Jan 31 2013 Paul Howarth  - 5.504-1
 - Update to 5.504
   - Fix encoding of MIME parameters that contain a quoted string: "like \"this"
--
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

File Class-ErrorHandler-0.02.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for perl-Class-ErrorHandler:

b516490ce7cf919d690f40f68c59a37c  Class-ErrorHandler-0.02.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

Re: F20 System Wide Change: No Default Syslog

[Steve Clark]

On 07/18/2013 08:09 AM, Lennart Poettering wrote:

On Wed, 17.07.13 22:35, Ding Yi Chen (dc...@redhat.com) wrote:


This should be simpler than forcing those stubborn mind (such as me) to change,
No?

We don't force anyone. You can just install rsyslog and you have
everything as you love it.

Lennart


Or you can de-install rsyslog and have everything as you love it.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Class-ErrorHandler] 0.02 bump

[Petr Pisar]

commit afbacc6001dd6c8decf3944dff55cc2eb38fe54d
Author: Petr Písař 
Date:   Thu Jul 18 16:56:30 2013 +0200

0.02 bump

 .gitignore   |1 +
 perl-Class-ErrorHandler.spec |   25 +
 sources  |2 +-
 3 files changed, 23 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6ad6516..d33b66f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 Class-ErrorHandler-0.01.tar.gz
+/Class-ErrorHandler-0.02.tar.gz
diff --git a/perl-Class-ErrorHandler.spec b/perl-Class-ErrorHandler.spec
index fc13bf8..a0f6051 100644
--- a/perl-Class-ErrorHandler.spec
+++ b/perl-Class-ErrorHandler.spec
@@ -1,15 +1,29 @@
 Name:   perl-Class-ErrorHandler
-Version:0.01
-Release:18%{?dist}
+Version:0.02
+Release:1%{?dist}
 Summary:Class::ErrorHandler Perl module
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Class-ErrorHandler/
-Source0:
http://www.cpan.org/authors/id/B/BT/BTROTT/Class-ErrorHandler-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/T/TO/TOKUHIROM/Class-ErrorHandler-%{version}.tar.gz
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
+BuildRequires:  perl
+BuildRequires:  perl(Config)
+BuildRequires:  perl(Cwd)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-BuildRequires: perl-Pod-Perldoc
+BuildRequires:  perl(ExtUtils::MM_Unix)
+BuildRequires:  perl(ExtUtils::Manifest)
+BuildRequires:  perl(Fcntl)
+BuildRequires:  perl(File::Find)
+BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(File::Temp)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(vars)
+BuildRequires:  perl-Pod-Perldoc
+# Tests:
+BuildRequires:  perl(base)
+BuildRequires:  perl(Test)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
 %description
@@ -49,6 +63,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 18 2013 Petr Pisar  - 0.02-1
+- 0.02 bump
+
 * Thu Jul 18 2013 Petr Pisar  - 0.01-18
 - Perl 5.18 rebuild
 
diff --git a/sources b/sources
index 69c6571..cac7588 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6a07ad34dfcdf510677f92e47643976d  Class-ErrorHandler-0.01.tar.gz
+b516490ce7cf919d690f40f68c59a37c  Class-ErrorHandler-0.02.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-SMTP-SSL] REbuilt to perl 5.18

[Jochen Schmitt]

commit 2ff4c38eeca6f7fc859ba9c0b5463b520798ddbb
Author: Jochen Schmitt 
Date:   Thu Jul 18 17:02:39 2013 +0200

REbuilt to perl 5.18

 perl-Net-SMTP-SSL.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Net-SMTP-SSL.spec b/perl-Net-SMTP-SSL.spec
index c23a6ec..0371a4a 100644
--- a/perl-Net-SMTP-SSL.spec
+++ b/perl-Net-SMTP-SSL.spec
@@ -1,6 +1,6 @@
 Name: perl-Net-SMTP-SSL
 Version: 1.01
-Release: 13%{?dist}
+Release: 14%{?dist}
 Summary: SSL support for Net::SMTP
 Group: Development/Libraries
 License: GPL+ or Artistic
@@ -43,6 +43,9 @@ make %{?_smp_mflags} test
 %{_mandir}/man3/Net::SMTP::SSL.3*
 
 %changelog
+* Thu Jul 18 2013 Jochen Schmitt  - 1.01-14
+- REbuilt to perl 5.18
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 1.01-13
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_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

Re: Virtual provides for files in /var/log

[Matthew Miller]

On Thu, Jul 18, 2013 at 02:19:30PM +0200, Lennart Poettering wrote:
> So, you suggest using "Requires: /var/log/messages" and "Provides:
> /var/log/messages" as indication for this, and the %ghost
> /var/log/messages in the packages in question?
> Sounds good to me! Matthew?

My main concern with this is that it's a lie. That file only exists because
of the default configuration. In many cases, rsyslog will be configured to
either write different files, or most likely, to write no local files at all
as all data is forwarded. And, as discussed in another subthread, I expect
this last configuration to be more and more common. So, not just a lie, but
a lie which may actually make it harder to use rsyslog in ways other than
the default.

In an ideal view, it makes most sense to provide the rsyslog default
configuration in a subpackage which puts the /var/log/messages and
/var/log/secure conf files in /etc/rsyslog.d -- then, this subpackage would
provide those files. Unfortunately, in order to preserve behavior on
upgrade, the main package would have to depend on this, kind of making the
distinction moot.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[John . Florian]

> From: scl...@netwolves.com
> 
> On 07/18/2013 08:09 AM, Lennart Poettering wrote:
> On Wed, 17.07.13 22:35, Ding Yi Chen (dc...@redhat.com) wrote:
> 

> This should be simpler than forcing those stubborn mind (such as me)to 
change,
> No?

> 
> We don't force anyone. You can just install rsyslog and you have
> everything as you love it. 
> 
> Lennart
> 

> Or you can de-install rsyslog and have everything as you love it.

Which makes more sense: take a default and modify it via composition ... 
or take a default and modify it via decomposition?

I'd always choose the former, regardless of the case or how convenient it 
was to me.

--
John Florian

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

[perl-IO-Socket-SSL] Rebuilt for perl 5.18

[Jochen Schmitt]

commit 715fbf7cf8cce61d1d12399053fcbf8dbd573827
Author: Jochen Schmitt 
Date:   Thu Jul 18 17:11:29 2013 +0200

Rebuilt for perl 5.18

 perl-IO-Socket-SSL.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index b662cbe..9dae04c 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -4,7 +4,7 @@
 
 Name:  perl-IO-Socket-SSL
 Version:   %{rpmversion}
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Perl library for transparent SSL
 Group: Development/Libraries
 License:   GPL+ or Artistic
@@ -74,6 +74,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/IO::Socket::SSL::Utils.3pm*
 
 %changelog
+* Thu Jul 18 2013 Jochen Schmitt  - 1.95.2-2
+- Rebuilt for perl 5.18
+
 * Fri Jul 12 2013 Paul Howarth  - 1.95.2-1
 - Update to 1.952
   - Fix t/acceptSSL-timeout.t on Win32 (CPAN RT#86862)
--
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: F20 System Wide Change: No Default Syslog

[Billy Crook]

On Thu, Jul 18, 2013 at 9:59 AM, Steve Clark  wrote:

>  On 07/18/2013 08:09 AM, Lennart Poettering wrote:
>
> On Wed, 17.07.13 22:35, Ding Yi Chen (dc...@redhat.com) wrote:
>
>
>  This should be simpler than forcing those stubborn mind (such as me) to 
> change,
> No?
>
>  We don't force anyone. You can just install rsyslog and you have
> everything as you love it.
>
> Lennart
>
>
>  Or you can de-install rsyslog and have everything as you love it.
>

+1

At long last, someone has come up with the most concise, sane solution to
this.  Thanks Steve.

Someone should really document how to uninstall syslog.  Knowing how could
have saved a lot of people a lot of time
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Multirelease effort: Moving to Python 3

[Bohuslav Kabrda]

Hi all,
as a new Fedora Python maintainer, I have set myself a goal of moving Fedora to 
Python 3 as a default. This is going to be a multirelease effort that is going 
to affect lots of Fedora parts. Since we will need to switch default package 
manager from Yum to DNF (which is supposed to work with Python 3), we will need 
to wait for that. I've been told that DNF should be default in F22, so that's 
my target, too. That should also give everyone else plenty of time to work on 
other essential packages to make this happen.

Here is my analysis/proposal:
Before switching, we need to make sure that everything "important" (*) is 
Python 3 compatible. There are three steps I see in this transition:
1) Getting rid of Python 2 in mock minimal buildroot.
2) Porting Anaconda to Python 3.
3) Making all livecd packages depend on Python 3 by default (and eventually 
getting rid of Python 2 from livecd) - this will also require switching from 
Yum to DNF as a default, that is supposed to support Python 3.
( 4) Making as much of the remaining packages Python 3 compatible )

In past few days, I've been going through packages that are part of the above 
steps. I have reported numerous bugs asking upstream and/or Fedora maintainers 
for help with porting to Python 3. We have some spare cycles in our small 
Python packaging team, that we will try to provide to whoever needs them most, 
but we're limited and we'll have to rely on the upstreams to do most of the 
work. I'm attaching a document with list of packages that need porting with 
some notes/links to opened bugs. Sometime soon, I'll open a tracking bug for 
this, so that everyone can see where we are quickly.
(*) I call these "important" packages (in terms of being important for the 
Python 3 switch)

>From packaging point of view, this will probably require:
1) Renaming python package to python2
2) Renaming python3 package to python
3) Switching the %{?with_python3} conditionals in specfiles to %{?with_python2} 
(we will probably create a script to automate this, at least partially)


FAQ:
Q: Why do we need to switch to Python 3?
A: Because Python 2 is old, slower, less pythonic, doesn't get any more 
functionality and it won't be that long before the official upstream support 
ends [1]

Q: How do I port to Python 3?
A: There are tons of tutorials and howtos about porting and the differencies in 
general. E.g. [2] (general), [3] (c-extensions)

Q: What about Python 2?
A: We will maintain that at least as long as upstream supports it. After that, 
I'd prefer dropping it, but since I know there will be people wanting to keep 
it around, I'll gladly give the maintenance to someone else.


I'll be glad to answer all your questions and discuss the above points. Nothing 
is set into stone and I'd love to hear your ideas and comments.
Thanks for reading this through!
Slavek.

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[1] http://www.python.org/dev/peps/pep-0373/
[2] http://docs.python.org/dev/howto/pyporting.html
[3] http://docs.python.org/3/howto/cporting.htmlminimal buildroot:
- gdb - OK?: http://www.gnu.org/software/gdb/download/ANNOUNCEMENT (since gdb 
itself depends on this, we will just need to switch to building with Python 3)

anaconda:
- (anaconda itself and all of its subpackages)
- anaconda-yum-plugins - XXX requires yum => would require the same 
functionality from dnf
- authconfig - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=984907
 - python-newt - TODO - 
https://bugzilla.redhat.com/show_bug.cgi?id=963839
 - pygtk2 - XXX - not for Python 3, will need to port to PyGObject
- firewalld - TODO - https://fedorahosted.org/firewalld/ticket/9
- python-slip - TODO - https://fedorahosted.org/python-slip/ticket/1
- iscsi-initiator-utils - TODO - 
https://bugzilla.redhat.com/show_bug.cgi?id=985321
- langtable-python - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=985317
- libuser-python - TODO - https://fedorahosted.org/libuser/ticket/13
- pykickstart - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=985310
- pyparted - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=985308
- python-IPy - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=985307
- python-babel - TODO - http://babel.edgewall.org/ticket/209
- python-blivet - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=985301
- python-cryptsetup - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=985297
- python-meh - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=985294
- python-nss - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=985290
- python-pwquality - TODO - https://fedorahosted.org/libpwquality/ticket/2
- python-pyblock - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=985295
- python-urlgrabber - TODO - https://bugzilla.redhat.com/show_bug.cgi?id=985288
- python-pycurl - TODO - 
https://github.com/p/pycurl/pull/28 (is this the official upstream?)
livecd (without anaconda):
- rpm-python - TODO - https://bugzilla.redhat.com

Re: F20 Self Contained Change: Vagrant

[Matthew Miller]

On Thu, Jul 18, 2013 at 09:27:43AM +0200, Vít Ondruch wrote:
> There is one missing method in upstream YAJL in comparison to
> bundled version. I am afraid we cannot move forward without upstream
> interaction :/

It looks like upstream was previously responsive but isn't to this one for
some reason?

If we're confident that the feature will get into upstream when the
unreleased version finally comes out, and if this is really the last
blocker, we may be able to get an exception to the bundled libraries policy.
(This is one of the listed cases for a possible exception.)


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Thu, Jul 18, 2013 at 1:56 AM, James Hogarth  wrote:
>
>> > Oh how do you get your logs to read in windows from your lvm/ext4/btrfs
>> > filesystems currently in a disk boot scenario?
>>
>> Using ext2fsd:
>> http://www.ext2fsd.com
>>
>
> ... I'd suggest you read that page and then look at my question and think
> real hard...

Maybe your question is poorly stated, then.

What I thought you asked was how to read Linux log files from a
Windows installation, e.g., when Linux fails to boot.  In the past
I've been able to do that using ext2fsd without much difficulty. I
used that method when I wasn't able to boot a rescue or live CD, and
the last resort would have been to pull the hard drive from the
machine and use a different computer to inspect it.   But if
/var/log/messages is not made available by default, then using ext2fsd
won't work, and other methods become more difficult also.

My main complaint is that removing the default syslog to
/var/log/messages makes it harder for me to diagnose broken machines
that OTHER people have set up, because those other people aren't going
to have installed a non-default syslog daemon.  Certainly if it's a
machine I'm installing, I'll know to install syslog.

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

Re: F20 System Wide Change: No Default Syslog

[Matthew Miller]

On Thu, Jul 18, 2013 at 09:51:32AM -0600, Eric Smith wrote:
> What I thought you asked was how to read Linux log files from a
> Windows installation, e.g., when Linux fails to boot.  In the past
> I've been able to do that using ext2fsd without much difficulty. I
> used that method when I wasn't able to boot a rescue or live CD, and
> the last resort would have been to pull the hard drive from the
> machine and use a different computer to inspect it.   But if
> /var/log/messages is not made available by default, then using ext2fsd
> won't work, and other methods become more difficult also.

I think this case is relatively obscure, but as with RHEL6, it would be nice
to have a journal file viewer for Windows.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Jóhann B. Guðmundsson]

On 07/18/2013 03:55 PM, Matthew Miller wrote:

On Thu, Jul 18, 2013 at 09:51:32AM -0600, Eric Smith wrote:

What I thought you asked was how to read Linux log files from a
Windows installation, e.g., when Linux fails to boot.  In the past
I've been able to do that using ext2fsd without much difficulty. I
used that method when I wasn't able to boot a rescue or live CD, and
the last resort would have been to pull the hard drive from the
machine and use a different computer to inspect it.   But if
/var/log/messages is not made available by default, then using ext2fsd
won't work, and other methods become more difficult also.

I think this case is relatively obscure, but as with RHEL6, it would be nice
to have a journal file viewer for Windows.




Why not read this files on another Fedora host ( or some other distro 
that uses systemd )?

What's the reason for this hard dependency on Windows?

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

Re: F20 System Wide Change: No Default Syslog

[Olav Vitters]

On Thu, Jul 18, 2013 at 12:23:33PM +0200, Denys Vlasenko wrote:
> What's inappropriate is giving instructions to others what they can,
> or can not say.

Even better would be to take this sort of stuff off list asap.

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

File Crypt-Twofish-2.17.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for perl-Crypt-Twofish:

bb6e7ec9ff6db6aea27dce7175a852e2  Crypt-Twofish-2.17.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-Crypt-Twofish] 2.17 bump

[Petr Pisar]

commit b6ffb8eecc682c0cf50230405d1625717735ea5c
Author: Petr Písař 
Date:   Thu Jul 18 18:06:49 2013 +0200

2.17 bump

 .gitignore  |1 +
 perl-Crypt-Twofish.spec |   19 +--
 sources |2 +-
 3 files changed, 19 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 322854c..370dc97 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 Crypt-Twofish-2.14.tar.gz
 /Crypt-Twofish-2.15.tar.gz
+/Crypt-Twofish-2.17.tar.gz
diff --git a/perl-Crypt-Twofish.spec b/perl-Crypt-Twofish.spec
index 68556f4..e2fce76 100644
--- a/perl-Crypt-Twofish.spec
+++ b/perl-Crypt-Twofish.spec
@@ -1,14 +1,26 @@
 Name:   perl-Crypt-Twofish
-Version:2.15
-Release:3%{?dist}
+Version:2.17
+Release:1%{?dist}
 Summary:Twofish Encryption Algorithm
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Crypt-Twofish/
 Source0:
http://www.cpan.org/authors/id/A/AM/AMS/Crypt-Twofish-%{version}.tar.gz
+BuildRequires:  perl
+BuildRequires:  perl(Config)
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(File::Spec)
+# Run-time:
+BuildRequires:  perl(Carp)
 BuildRequires:  perl(Crypt::CBC)
+BuildRequires:  perl(DynaLoader)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(vars)
+# Tests:
+BuildRequires:  perl(Benchmark)
+BuildRequires:  perl(Test)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+Requires:   perl(Crypt::CBC)
 
 %{?perl_default_filter}
 
@@ -43,6 +55,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 18 2013 Petr Pisar  - 2.17-1
+- 2.17 bump
+
 * Thu Jul 18 2013 Petr Pisar  - 2.15-3
 - Perl 5.18 rebuild
 
diff --git a/sources b/sources
index 1af65c7..c73208e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0a4a9c1eccc622a31af58bddb2e7bd31  Crypt-Twofish-2.15.tar.gz
+bb6e7ec9ff6db6aea27dce7175a852e2  Crypt-Twofish-2.17.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

Re: F20 Self Contained Change: X2Go - Reviewers needed

[Orion Poplawski]

On 07/16/2013 05:11 AM, Jaroslav Reznik wrote:

= Proposed Self Contained Change: X2Go =
https://fedoraproject.org/wiki/Changes/X2Go

Change owner(s): Orion Poplawski 

The X2Go [1] project has taken over development of the old NX libraries and
has developed new clients and server code around it. We will move to use the
X2Go NX library in Fedora and include the full X2Go suite.

== Detailed description ==
The current nx package in Fedora is based on the last open source release from
NoMachine. NoMachine is no longer developing nx as an open source project. The
X2Go project has taken the nx code and is maintaining it as well as developing
new client and server code around it.

== Scope ==
* Review the new nx-libs package which will replace the current nx package.
* Confirm that existing packages that use nx work with the new package (if they
worked before).
* Review and include the rest of the X2Go suite:
** x2goserver

[1] http://x2go.org/


There are going to be a bunch of reviews needed to get this in.  The first, 
nx-libs is a bit of a doozy although I think it is quite close.  The rest are 
hopefully pretty simple.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-IO-Socket-IP: 1/2] Disable the SO_REUSEPORT test; koji builders don't support this feature yet

[Petr Šabata]

commit 15f3e4b4da773b56ab952f5c805b9c2d8d0ac7ce
Author: Petr Šabata 
Date:   Thu Jul 18 18:08:30 2013 +0200

Disable the SO_REUSEPORT test; koji builders don't support this feature yet

 IO-Socket-IP-so_reuseport.patch |   12 
 perl-IO-Socket-IP.spec  |7 ++-
 2 files changed, 18 insertions(+), 1 deletions(-)
---
diff --git a/IO-Socket-IP-so_reuseport.patch b/IO-Socket-IP-so_reuseport.patch
new file mode 100644
index 000..9cf625b
--- /dev/null
+++ b/IO-Socket-IP-so_reuseport.patch
@@ -0,0 +1,12 @@
+diff --git a/t/11sockopts.t b/t/11sockopts.t
+index 02f733c..e11051a 100644
+--- a/t/11sockopts.t
 b/t/11sockopts.t
+@@ -28,6 +28,7 @@ TODO: {
+ SKIP: {
+# Some OSes don't implement SO_REUSEPORT
+skip "No SO_REUSEPORT", 1 unless defined eval { SO_REUSEPORT };
++   skip "Koji builders don't support SO_REUSEPORT", 1;
+ 
+my $sock = IO::Socket::IP->new(
+   LocalHost => "127.0.0.1",
diff --git a/perl-IO-Socket-IP.spec b/perl-IO-Socket-IP.spec
index d1ae8ac..fccb2ee 100644
--- a/perl-IO-Socket-IP.spec
+++ b/perl-IO-Socket-IP.spec
@@ -1,11 +1,12 @@
 Name:   perl-IO-Socket-IP
 Version:0.21
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Drop-in replacement for IO::Socket::INET supporting both IPv4 
and IPv6
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/IO-Socket-IP/
 Source0:
http://www.cpan.org/authors/id/P/PE/PEVANS/IO-Socket-IP-%{version}.tar.gz
+Patch0: IO-Socket-IP-so_reuseport.patch
 BuildArch:  noarch
 BuildRequires:  perl
 BuildRequires:  perl(base)
@@ -33,6 +34,7 @@ arguments and methods are provided in a backward-compatible 
way.
 
 %prep
 %setup -q -n IO-Socket-IP-%{version}
+%patch0 -p1
 
 %build
 perl Build.PL installdirs=vendor
@@ -53,6 +55,9 @@ rm -f t/21nonblocking-connect-internet.t
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 18 2013 Petr Šabata  - 0.21-2
+- Disable the SO_REUSEPORT test; koji builders don't support this feature yet
+
 * Mon Apr 29 2013 Petr Šabata  - 0.21-1
 - 0.21 bump
 
--
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-IO-Socket-IP] (2 commits) ...5.18 rebuild merge

[Petr Šabata]

Summary of changes:

  15f3e4b... Disable the SO_REUSEPORT test; koji builders don't support 
  f50cbc9... 5.18 rebuild merge
--
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-IO-Socket-IP: 2/2] 5.18 rebuild merge

[Petr Šabata]

commit f50cbc947dc66a63ae139f24ba7d2d0151a6c540
Merge: 15f3e4b cc37780
Author: Petr Šabata 
Date:   Thu Jul 18 18:09:47 2013 +0200

5.18 rebuild merge

 perl-IO-Socket-IP.spec |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --cc perl-IO-Socket-IP.spec
index fccb2ee,e416077..791cd5a
--- a/perl-IO-Socket-IP.spec
+++ b/perl-IO-Socket-IP.spec
@@@ -1,6 -1,6 +1,6 @@@
  Name:   perl-IO-Socket-IP
  Version:0.21
--Release:2%{?dist}
++Release:3%{?dist}
  Summary:Drop-in replacement for IO::Socket::INET supporting both IPv4 
and IPv6
  License:GPL+ or Artistic
  Group:  Development/Libraries
@@@ -55,9 -53,9 +55,12 @@@ rm -f t/21nonblocking-connect-internet.
  %{_mandir}/man3/*
  
  %changelog
- * Thu Jul 18 2013 Petr Šabata  - 0.21-2
++* Thu Jul 18 2013 Petr Šabata  - 0.21-3
 +- Disable the SO_REUSEPORT test; koji builders don't support this feature yet
 +
+ * Thu Jul 18 2013 Petr Pisar  - 0.21-2
+ - Perl 5.18 rebuild
+ 
  * Mon Apr 29 2013 Petr Šabata  - 0.21-1
  - 0.21 bump
  
--
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: F20 System Wide Change: No Default Syslog

[James Hogarth]

On 18 July 2013 16:51, Eric Smith  wrote:

>
>
> Maybe your question is poorly stated, then.
>
> What I thought you asked was how to read Linux log files from a
> Windows installation, e.g., when Linux fails to boot.


This is indeed the question - so given you understood it so it seems I
would say that it was not poorly stated.


>  In the past I've been able to do that using ext2fsd without much
> difficulty.


This will not work depending on ext4 options, if LVM is in use or if BTRFS
is used which is of course now supported as an option in the installer.



> I used that method when I wasn't able to boot a rescue or live CD,


Then you were not using it with a default installed Fedora anyway which has
a default of LVM in place



> and the last resort would have been to pull the hard drive from the
> machine and use a different computer to inspect it.


That or live media is the best option in general... I know above you said
you couldn't use a live CD and I'm quite curious as to why.



> But if /var/log/messages is not made available by default, then using
> ext2fsd
> won't work, and other methods become more difficult also.
>
>
It already won't work for a default installed Fedora ... there is no
difference.



> My main complaint is that removing the default syslog to
> /var/log/messages makes it harder for me to diagnose broken machines
> that OTHER people have set up, because those other people aren't going
> to have installed a non-default syslog daemon.  Certainly if it's a
> machine I'm installing, I'll know to install syslog.
>

Well fortunately you pay attention to these lists so you know to look at
the README and if /var/log/messages is not there (or if Fedora in general
now) you should use journalctl instead...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary of accepted Fedora 20 Changes - week 29

[Matthew Miller]

On Thu, Jul 18, 2013 at 03:56:15PM +0200, Jaroslav Reznik wrote:
> * ARM as primary Architecture - 
> https://fedoraproject.org/wiki/Changes/ARM_as_Primary announced on 2013-07-09 
> https://lists.fedoraproject.org/pipermail/devel/2013-July/184962.html

I just want to highlight the next sentence for anyone who is just skimming:


> FESCo resolution: Build ARM on primary infrastructure. Whether it is
> released as a primary Fedora 20 or as 'Fedora 20 for ARM' depends on how
> well it fulfills release criteria and functionality criteria closer to
> release time.

Effectively, this creates a pragmatic process for becoming a primary arch.
We start moving it in practice towards being primary, and as problems are
discovered and fixed, we get closer to the end goal, and eventually when
we're there, we have a new primary architecture.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Matthew Miller]

On Thu, Jul 18, 2013 at 03:54:49PM +, "Jóhann B. Guðmundsson" wrote:
> >>I've been able to do that using ext2fsd without much difficulty. I
> >>used that method when I wasn't able to boot a rescue or live CD, and
> >>the last resort would have been to pull the hard drive from the
> >>machine and use a different computer to inspect it.   But if
> >>/var/log/messages is not made available by default, then using ext2fsd
> >>won't work, and other methods become more difficult also.
> >I think this case is relatively obscure, but as with RHEL6, it would be nice
> >to have a journal file viewer for Windows.
> Why not read this files on another Fedora host ( or some other
> distro that uses systemd )?
> What's the reason for this hard dependency on Windows?

I think the use case here is dual-boot system where the Fedora installation
is somehow broken but the Windows boot works. 

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

privileges in Koji

[Ken Dreyer]

I'm going through the "co-maintain to sponsor" process this week with
blakegardner on the gearmand package. Gearmand was recently orphaned,
and I've picked it up in order to work with blakegardner on the EL5
branch. I sponsored Blake in FAS yesterday, and I was surprised to see
that he was able to issue a build to Koji for the gearmand package
today, before he even applied for privileges in pkgdb.

Was that a fluke? I would not have expected him (or anyone who's not a
provenpackager) to be able to issue builds against a package for which
they have no pkgdb ACL.

For what it's worth, Blake's build was against the same Git hash
(c5c9d037dfbaabaef6eca1c0c76b84d9e286f999) as the previous (f19)
build. Only the dist tag has changed. So no commits were pushed.
gearmand just has a f20 dist tag now.

http://koji.fedoraproject.org/koji/buildinfo?buildID=435630

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

Re: Multirelease effort: Moving to Python 3

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
> Hi all,
> as a new Fedora Python maintainer, I have set myself a goal of
> moving Fedora to Python 3 as a default.
That's a worthy goal!

> From packaging point of view, this will probably require:
> 1) Renaming python package to python2
> 2) Renaming python3 package to python
> 3) Switching the %{?with_python3} conditionals in specfiles to 
> %{?with_python2} (we will probably create a script to automate this, at least 
> partially)

But that seems like pointless busywork and churn. Sure, when python3
is ubiquitous, those checks can be dropped or reversed... But right
now it would be better to focus on actual python3 versions of all
packages — we're not there yet.

Zbyszek
-- 
they are not broken. they are refucktored
   -- alxchk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: privileges in Koji

[Rex Dieter]

Ken Dreyer wrote:

> I'm going through the "co-maintain to sponsor" process this week with
> blakegardner on the gearmand package. Gearmand was recently orphaned,
> and I've picked it up in order to work with blakegardner on the EL5
> branch. I sponsored Blake in FAS yesterday, and I was surprised to see
> that he was able to issue a build to Koji for the gearmand package
> today, before he even applied for privileges in pkgdb.
> 
> Was that a fluke?

It's not a fluke. Currently, acl's only limit *commits*, not builds.

-- rex

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

Re: F20 System Wide Change: No Default Syslog

[Jóhann B. Guðmundsson]

On 07/18/2013 04:23 PM, Matthew Miller wrote:

On Thu, Jul 18, 2013 at 03:54:49PM +, "Jóhann B. Guðmundsson" wrote:

I've been able to do that using ext2fsd without much difficulty. I
used that method when I wasn't able to boot a rescue or live CD, and
the last resort would have been to pull the hard drive from the
machine and use a different computer to inspect it.   But if
/var/log/messages is not made available by default, then using ext2fsd
won't work, and other methods become more difficult also.

I think this case is relatively obscure, but as with RHEL6, it would be nice
to have a journal file viewer for Windows.

Why not read this files on another Fedora host ( or some other
distro that uses systemd )?
What's the reason for this hard dependency on Windows?

I think the use case here is dual-boot system where the Fedora installation
is somehow broken but the Windows boot works.



If you have physical access to the machine you should be able to access 
those journal files from within dracut shell.

If not that something we need to look at and solve I would think.

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

Re: Virtual provides for files in /var/log

[Lennart Poettering]

On Thu, 18.07.13 11:11, Matthew Miller (mat...@fedoraproject.org) wrote:

> On Thu, Jul 18, 2013 at 02:19:30PM +0200, Lennart Poettering wrote:
> > So, you suggest using "Requires: /var/log/messages" and "Provides:
> > /var/log/messages" as indication for this, and the %ghost
> > /var/log/messages in the packages in question?
> > Sounds good to me! Matthew?
> 
> My main concern with this is that it's a lie. That file only exists because
> of the default configuration. In many cases, rsyslog will be configured to
> either write different files, or most likely, to write no local files at all
> as all data is forwarded. And, as discussed in another subthread, I expect
> this last configuration to be more and more common. So, not just a lie, but
> a lie which may actually make it harder to use rsyslog in ways other than
> the default.
> 
> In an ideal view, it makes most sense to provide the rsyslog default
> configuration in a subpackage which puts the /var/log/messages and
> /var/log/secure conf files in /etc/rsyslog.d -- then, this subpackage would
> provide those files. Unfortunately, in order to preserve behavior on
> upgrade, the main package would have to depend on this, kind of making the
> distinction moot.

Well, I am not sure it's really a "lie". It's reasonably close to the
truth, and it would be agood thing anyway if the syslog implementation
would own /var/log/messages at least as %ghost. I mean, people can
always reconfigure things, and muck around with how things are set up
and break stuff. That's OK, people should be able to do that. 

I think this should really be considered a documentation problem: in the
default rsyslog.conf ship a few comments explaining that
/var/log/messages is kinda considered API by some other packages, and
that the user should only alter its configuration if he knows what he
does.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Lennart Poettering]

On Thu, 18.07.13 17:11, James Hogarth (james.hoga...@gmail.com) wrote:

> On 18 July 2013 16:51, Eric Smith  wrote:
> 
> >
> >
> > Maybe your question is poorly stated, then.
> >
> > What I thought you asked was how to read Linux log files from a
> > Windows installation, e.g., when Linux fails to boot.
> 
> 
> This is indeed the question - so given you understood it so it seems I
> would say that it was not poorly stated.
> 
> 
> >  In the past I've been able to do that using ext2fsd without much
> > difficulty.
> 
> 
> This will not work depending on ext4 options, if LVM is in use or if BTRFS
> is used which is of course now supported as an option in the
> installer.

Actually, it's worse. The driver requires you to turn of driver
signature verification of Windows. That's just a huge mess. (Also, it
doesn't support the current Windows version).

I don't think that using ext2fsd is possible "without much
difficulty". It's great that such a tool exists, but it's a hacker tool,
for somebody who is willing to alter his Windows installations in
non-trivial ways.

I am pretty sure that just downloading an ISO of the latest Fedora
livecd and dd'ing it to an USB disk is a ton more fun that the ext2fsd
dance, and is a lot more comprehensive with its LVM, LUKS, btrfs support
that pretty much just works.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Multirelease effort: Moving to Python 3

[Toshio Kuratomi]

On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
> Hi all,
> as a new Fedora Python maintainer, I have set myself a goal of moving
> Fedora to Python 3 as a default.

I'm not sure we want to make python3 default depending on what your
definition of default is.

/usr/bin/python should refer to python2 --
http://www.python.org/dev/peps/pep-0394/  I'd be -1 to changing this

The python package itself should probably also remain python2 due to
dependencies and expectations from other distros and documentation --
I think I'd be -1 to changing this

The Fedora live images contain only python3, not python2 -- I'd be heavily
in favour of this. +1

> This is going to be a multirelease effort
> that is going to affect lots of Fedora parts. Since we will need to switch
> default package manager from Yum to DNF (which is supposed to work with
> Python 3), we will need to wait for that. I've been told that DNF should
> be default in F22, so that's my target, too. That should also give
> everyone else plenty of time to work on other essential packages to make
> this happen.

Getting there at the same time as we get to DNF sounds like a good timeline.
(But see my note on anaconda below).  +1

> Here is my analysis/proposal:
> Before switching, we need to make sure that everything "important" (*) is 
> Python 3 compatible. There are three steps I see in this transition:
> 1) Getting rid of Python 2 in mock minimal buildroot.

I'm not sure about this one as it will cause a lot of package churn.  It
might be a necessary pain pointi or it might be a pain point we want to
defer until later in our porting efforts.  Have to think about it more.

> 2) Porting Anaconda to Python 3.

+1 -- unfortunately, this probably depends on DNF So we may need to push
DNF in F22 and anaconda compatible with python3 in F23.

> 3) Making all livecd packages depend on Python 3 by default (and eventually 
> getting rid of Python 2 from livecd) - this will also require switching from 
> Yum to DNF as a default, that is supposed to support Python 3.

+1 -- this is what I see as the eventual goal (or perhaps, livecd python2
free followed by DVD python2 free followed by distro python2 free).


3.5) Switch tools that could target either python2 or python3 to target
python3.  Currently the packaging guidelines say to target python2 to
control dep proliferation and because that's the most supported by the
larger python ecosystem.  We should switch the recommendation when our
minimal environment must have python3 but does not need to have python2.

> ( 4) Making as much of the remaining packages Python 3 compatible )
> 

We could talk quite a bit on this point -- How active do we want to be with
the things that aren't in one of the essential buckets from further up.  We
could defer thinking about this until after we get the livecd python2-free,
though.

> In past few days, I've been going through packages that are part of the above 
> steps. I have reported numerous bugs asking upstream and/or Fedora 
> maintainers for help with porting to Python 3. We have some spare cycles in 
> our small Python packaging team, that we will try to provide to whoever needs 
> them most, but we're limited and we'll have to rely on the upstreams to do 
> most of the work. I'm attaching a document with list of packages that need 
> porting with some notes/links to opened bugs. Sometime soon, I'll open a 
> tracking bug for this, so that everyone can see where we are quickly.
>
> (*) I call these "important" packages (in terms of being important for the 
> Python 3 switch)
>
Cool.  A list of packages that are on the livecd is good.  One thing to
remember, though, is that the current Python Guidelines specify that we are
not to ship python3 versions of packages if upstream is not going to support
us in that effort:
https://fedoraproject.org/wiki/Packaging:Python#Subpackages

We could change that but I'm not 100% behind the idea of changing it.  As
stated in the Guidelines: 

"
[...]doing this on our own in Fedora is essentially creating a fork. That has
a large burden for maintaining the code, fixing bugs, porting when a new
version of upstream's code appears, managing a release schedule, and other
tasks normally handled by upstream. It's much better if we can cooperate
with upstream to share this work than doing it all on our own.
"

Luckily, in recent years I've only encountered a few upstreams that are
unwilling to look at python3 patches.  Most upstreams are amenable to
taking patches that establish python3 compatibility.  We just need to remain
clear that we have to work upstream to get these python3 versions into
fedora, not do it in our packages without upstream being on board.

> From packaging point of view, this will probably require:
> 1) Renaming python package to python2
> 2) Renaming python3 package to python

-1: What are the benefits of this as the cost of this is very high in
several ways:
* updating our dependencies
* dive

Re: Multirelease effort: Moving to Python 3

[Bohuslav Kabrda]

- Original Message -
> On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
> > Hi all,
> > as a new Fedora Python maintainer, I have set myself a goal of
> > moving Fedora to Python 3 as a default.
> That's a worthy goal!
> 
> > From packaging point of view, this will probably require:
> > 1) Renaming python package to python2
> > 2) Renaming python3 package to python
> > 3) Switching the %{?with_python3} conditionals in specfiles to
> > %{?with_python2} (we will probably create a script to automate this, at
> > least partially)
> 
> But that seems like pointless busywork and churn. Sure, when python3
> is ubiquitous, those checks can be dropped or reversed... But right
> now it would be better to focus on actual python3 versions of all
> packages — we're not there yet.
> 

Yes, current efforts should be directed to porting for Python 3, the packaging 
points I mentioned will really be the very last step.
Thanks,
Slavek.

> Zbyszek
> --
> they are not broken. they are refucktored
>-- alxchk

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Virtual provides for files in /var/log

[Orion Poplawski]

On 07/18/2013 06:19 AM, Lennart Poettering wrote:

On Thu, 18.07.13 10:34, Vít Ondruch (vondr...@redhat.com) wrote:


Dne 18.7.2013 01:02, Lennart Poettering napsal(a):

So, maybe, instead of dropping the "Provides syslog" thing from
journald, maybe we should add an explicit "syslog-files" dependency (or
something named like that) and then make the classic syslog
implementations provide that and the packages which actually need
/var/log/messages pull that it?

Lennart



So why there are files in /var/log and there is not obvious package,
which creates them (unless you want to guess by name)? Shouldn't all
package, which creates log in /var/log have some virtual provide to
make it obvious? Why not do it properly/consistently?


So, you suggest using "Requires: /var/log/messages" and "Provides:
/var/log/messages" as indication for this, and the %ghost
/var/log/messages in the packages in question?

Sounds good to me! Matthew?

Lennart



But what is going to require /var/log/messages?  Programs like logwatch and 
logrotate can operate on *any* file in /var/log (or elsewhere for that 
matter).  They can be useful without /var/log/messages.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 895022] Test-Email-0.07 is avaliable

[bugzilla]

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

Ralf Corsepius  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |WONTFIX
Last Closed|2013-03-09 11:42:41 |2013-07-18 13:30:40

-- 
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=9jZBbeZJRD&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: Virtual provides for files in /var/log

[Lennart Poettering]

On Thu, 18.07.13 11:30, Orion Poplawski (or...@cora.nwra.com) wrote:

> On 07/18/2013 06:19 AM, Lennart Poettering wrote:
> >On Thu, 18.07.13 10:34, Vít Ondruch (vondr...@redhat.com) wrote:
> >
> >>Dne 18.7.2013 01:02, Lennart Poettering napsal(a):
> >>>So, maybe, instead of dropping the "Provides syslog" thing from
> >>>journald, maybe we should add an explicit "syslog-files" dependency (or
> >>>something named like that) and then make the classic syslog
> >>>implementations provide that and the packages which actually need
> >>>/var/log/messages pull that it?
> >>>
> >>>Lennart
> >>>
> >>
> >>So why there are files in /var/log and there is not obvious package,
> >>which creates them (unless you want to guess by name)? Shouldn't all
> >>package, which creates log in /var/log have some virtual provide to
> >>make it obvious? Why not do it properly/consistently?
> >
> >So, you suggest using "Requires: /var/log/messages" and "Provides:
> >/var/log/messages" as indication for this, and the %ghost
> >/var/log/messages in the packages in question?
> >
> >Sounds good to me! Matthew?
> >
> >Lennart
> >
> 
> But what is going to require /var/log/messages?  Programs like
> logwatch and logrotate can operate on *any* file in /var/log (or
> elsewhere for that matter).  They can be useful without
> /var/log/messages.

logrotate certainly shouldn require this, as in its defualt config it
does not reference /var/log/messages at all.

logwatch probably should require it as long as it doesn't "speak
journal", as the data its rules look for is in /var/log/messages.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Thu, Jul 18, 2013 at 9:54 AM, "Jóhann B. Guðmundsson"
 wrote:
> Why not read this files on another Fedora host ( or some other distro that
> uses systemd )?
> What's the reason for this hard dependency on Windows?

Because I was about six hundred miles away from my office, didn't want
to take the user's computer apart if I could avoid it, and didn't have
a drive dock to hook up the user's drive to my laptop.  The user had
Windows available on the machine, so I took advantage of it to figure
out what was wrong with Linux and fix it.

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

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Thu, Jul 18, 2013 at 10:11 AM, James Hogarth  wrote:
> Then you were not using it with a default installed Fedora anyway which has
> a default of LVM in place

I don't remember why there wasn't LVM. I don't remember whether I was
the one that installed Linux on that machine in the first place.  I
might have been.

> That or live media is the best option in general... I know above you said
> you couldn't use a live CD and I'm quite curious as to why.

The machine didn't have a working optical drive.  If I'd had a live
image on USB that probably would have worked.  If I hadn't been
hundreds of miles from the nearest computer store, I'd have just
bought another optical drive, or a drive dock, or a cable to use the
optical drive out of my laptop, or any number of things that would
have made it easier to solve the problem.  I was motivated to try to
solve it using only what happened to be at hand.

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

Re: F20 System Wide Change: No Default Syslog

[James Hogarth]

On 18 Jul 2013 18:42, "Eric Smith"  wrote:
>
>
> Because I was about six hundred miles away from my office, didn't want
> to take the user's computer apart if I could avoid it, and didn't have
> a drive dock to hook up the user's drive to my laptop.  The user had
> Windows available on the machine, so I took advantage of it to figure
> out what was wrong with Linux and fix it.
>

Without sounding too blunt I hope this does sound like we're entering the
territory of "lack of planning on your part does not constitute and
emergency on mine" as I have to occasionally remind people at work...

This is such an extreme use case and as pointed out by Lennart as well is
not viable on current systems anyway without huge hoop jumping...

This hack of a workaround you attempted once can no way realistically be
considered a blocker to this as it's so far off a support matrix it's
almost comical to suggest it as such...

You could have used his windows partition to download a live CD and use
that as a less fragile solution that would be less likely to cause
filesystem corruption and work with a default fedora on lvm and so on...
Which as pointed out your workaround would not.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 986004] New: Update perl-CPAN-Meta-YAML to 0.008

[bugzilla]

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

Bug ID: 986004
   Summary: Update perl-CPAN-Meta-YAML to 0.008
   Product: Fedora EPEL
   Version: el6
 Component: perl-CPAN-Meta-YAML
  Severity: low
  Assignee: p...@city-fan.org
  Reporter: p...@apocalyptech.com
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-de...@lists.fedoraproject.org

perl-CPAN-Meta-YAML's version in EPEL is currently 0.003, whereas the latest is
0.008.  It looks like simply changing the version number in the .spec file is
enough - there were no errors and it seems to work fine that way.  I could
attach a .patch for that small change if you like, of course.

-- 
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=bmk0naKX9h&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: F20 System Wide Change: No Default Syslog

[Lars Seipel]

On Wed, Jul 17, 2013 at 04:23:54PM -0500, Billy Crook wrote:
> What about a special filesystem mounted at /var/log or filesystem trickery
> therein that presents contents similar to what everyone expects, backed out
> of journalctl and its storage then?

It's probably straightforward to write a FUSE filesystem that grabs the
needed information from journalctl when read. Mount it somewhere under
/run and set up /var/log/messages as a symlink to the corresponding
file.

But I don't see the point. Just install rsyslog. It's not going away any
time soon.

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

Re: F20 System Wide Change: No Default Syslog

[Nicolas Mailhot]

Le Jeu 18 juillet 2013 19:56, James Hogarth a écrit :

> Without sounding too blunt I hope this does sound like we're entering the
> territory of "lack of planning on your part does not constitute and
> emergency on mine" as I have to occasionally remind people at work...
>
> This is such an extreme use case and as pointed out by Lennart as well is
> not viable on current systems anyway without huge hoop jumping...

Without sounding too blunt, this is business as usual from a repair
end-user system point of view. I had dozens of such "oh btw can you fix my
system" experiences

-- 
Nicolas Mailhot

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

EPEL intent up update libgearman in Fedora and

[Ken Dreyer]

The gearmand package was recently orphaned for all branches. I've
taken over maintenance, and Blake and I intend to push the latest
upstream gearmand (1.1.8) to Fedora and EPEL 5 and 6.

This will involve an ABI break from the current EPEL libgearmand
package (0.14), although no packages in EPEL depend on libgearman or
gearmand.

In Fedora, the one package that depends on libgearman is the
php-pecl-gearman package. In my research, this package should not
require a rebuild, since Fedora will only be going from 1.1.2 ->
1.1.8.

Generally speaking, our intent with this update is three-fold:
- Update gearmand so that we do not have to scramble the ABI breakage
if a CVE were to be issued.
- Update gearmand to allow for persistent storage. Without this
feature, gearmand's functionality is limited.
- Update libgearman to allow for the eventual inclusion of
php-pecl-gearman in EL6/5.

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

Re: F20 System Wide Change: No Default Syslog

[James Hogarth]

On 18 July 2013 19:26, Nicolas Mailhot  wrote:

>
> Without sounding too blunt, this is business as usual from a repair
> end-user system point of view. I had dozens of such "oh btw can you fix my
> system" experiences
>
>
Yeah I've been there in the past ... which is why I have spare USB pen
drives in my rucksack - some empty some with a live instance already on
there...

And if going to diagnose/repair a Linux system it'd be sane to grab a
centos and fedora live instance before heading out ...

It's just part of the toolset - just as screwdrivers and so on are as well
for many engineers ...

I've also been there with dodgy hacky workarounds to deal with strange
stuff - but I wouldn't expect it to weight in an argument for something
like this ...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Lars Seipel]

On Wed, Jul 17, 2013 at 12:31:56PM -0400, Steve Clark wrote:
> What about scripts that use /usr/bin/logger? Do messages generated by this 
> utility
> end up in the journal? Or php scripts, or programs using syslog(3).

Yes, everything using standard syslog facilities ends up in the journal.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Nicolas Mailhot]

Le Jeu 18 juillet 2013 20:34, James Hogarth a écrit :

> I've also been there with dodgy hacky workarounds to deal with strange
> stuff - but I wouldn't expect it to weight in an argument for something
> like this ...

Why not? In the imperfect world we live in, I'm quite sure they comprise a
large part of the home linux market. Linux is solid server-side but the
desktop-side is far from there (and has been busy dismantling the bits
that made server linux reliable)

-- 
Nicolas Mailhot

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

Re: F20 System Wide Change: Enable kdump on secureboot machines

[Miloslav Trmač]

On Thu, Jul 11, 2013 at 1:40 PM, Jaroslav Reznik  wrote:
> = Proposed System Wide Change: Enable kdump on secureboot machines =
> https://fedoraproject.org/wiki/Changes/Kdump_with_secureboot

> == Detailed description ==
> /sbin/kexec prepares a binary blob, called purgatory. This code runs at
> priviliged level between kernel transition. With secureboot enabled, no
> unsigned code should run at privilige level 0, hence kexec/kdump is currently
> disabled if secureboot is enabled.
>
> One proposed way to solve the problem is that sign /sbin/kexec utility. And
> upon successful signature verification, allow it to load kernel, initramfs, 
> and
> binary blob. /sbin/kexec will verify signatures of kernel being loaded before
> it asks running kernel to load it.

For someone like me unfamiliar with kdump architecture, wouldn't it be
possible to generate all relevant blobs (kdump kernel/initrd, ...) at
kernel build time and sign them using essentially the existing module
signing mechanism, and let the _kernel_ do all signature verification?
 Then /sbin/kexec wouldn't have to be trusted at all.

> === Build and ship ima-evm-utils package ===
> /sbin/kexec will be signed by evmctl. This utility will put an xattr
> security.ima on /sbin/kexec file and kernel will leverage IMA infrastructure 
> in
> kernel to verify signature of /sbin/kexec upon execution.

(My motivation for the above question is that I view IMA (and any
approach based on verifying only a pre-specified subset of files) as
rather suspect, and that dm-verity makes much more sense to me for
enforcing a "trusted base OS".  This doesn't automatically mean that
kdump shouldn't be using IMA, however I fear that once we start for
one binary, calls to verify more of userspace using IMA will be
difficult to resist.)
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] Please review: [389 Project] #47367: ldapdelete returns non-leaf entry error while trying to remove a leaf entry

[Noriko Hosoi]

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

https://fedorahosted.org/389/attachment/ticket/47367/0001-Ticket-47367-phase-1-ldapdelete-returns-non-leaf-ent.2.patch
git patch file (master) - phase1: ported from 1.2.11
The difference from 1.2.11:
[urp.c]
  2) The urp calling timing was moved from SLAPI_PLUGIN_BE_TXN_PRE_* to
  SLAPI_PLUGIN_BE_PRE_*.  (Note: SLAPI_PLUGIN_BE_PRE_* is also in the
  backend transaction.)  This is necessary since urp needs to be done
  prior to parent checking.
[ldbm_add.c] Moved SLAPI_PLUGIN_BE_PRE_ADD_FN inside of the transaction.
  Other operations are already calling SLAPI_PLUGIN_BE_PRE function at the
  timing.

https://fedorahosted.org/389/attachment/ticket/47367/0002-Ticket-47367-phase-2-ldapdelete-returns-non-leaf-ent.patch
git patch file (master) - phase2
Fix description:
1) Make sure add/modify/modrdn/delete plug-in callbacks return
SLAPI_PLUGIN_SUCCESS (==0) on SUCCESS and SLAPI_PLUGIN_FAILURE
(==-1) on FAILURE.  And set error code to SLAPI_RESULT_CODE in
pblock, if any.
2) replication: eliminated multimaster_betxnpreop_* which were
used for calling urp.  Urp needs to be processed at bepreop
timing.

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

Re: F20 System Wide Change: Enable kdump on secureboot machines

[Matthew Garrett]

On Thu, Jul 18, 2013 at 08:51:36PM +0200, Miloslav Trmač wrote:
> On Thu, Jul 11, 2013 at 1:40 PM, Jaroslav Reznik  wrote:
> > = Proposed System Wide Change: Enable kdump on secureboot machines =
> > https://fedoraproject.org/wiki/Changes/Kdump_with_secureboot
> 
> > == Detailed description ==
> > /sbin/kexec prepares a binary blob, called purgatory. This code runs at
> > priviliged level between kernel transition. With secureboot enabled, no
> > unsigned code should run at privilige level 0, hence kexec/kdump is 
> > currently
> > disabled if secureboot is enabled.
> >
> > One proposed way to solve the problem is that sign /sbin/kexec utility. And
> > upon successful signature verification, allow it to load kernel, initramfs, 
> > and
> > binary blob. /sbin/kexec will verify signatures of kernel being loaded 
> > before
> > it asks running kernel to load it.
> 
> For someone like me unfamiliar with kdump architecture, wouldn't it be
> possible to generate all relevant blobs (kdump kernel/initrd, ...) at
> kernel build time and sign them using essentially the existing module
> signing mechanism, and let the _kernel_ do all signature verification?
>  Then /sbin/kexec wouldn't have to be trusted at all.

The short version of that is no, because kdump needs to build some code 
at runtime. Upstream have refused to revisit that design decision.

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

Away on vacation and for Guadec

[Hans de Goede]

Hi All,

I'll be away on vacation Jul 18 - 26 (and not reading email),
and I'll be at Guadec Jul 31 - Aug 7 (and sporadically reading
my email).

So if you're trying to reach me and I'm not responding immediately,
that is why. I'll catch up with email, bugs, etc. when I return.

Regards,

Hans

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

Re: F20 System Wide Change: Web Assets

[Robert Marcano]

On 07/16/2013 06:24 AM, Jaroslav Reznik wrote:
...


Additionally the following symlinks will be provided:

* /usr/share/javascript -> /usr/share/assets/javascript
* /usr/share/fonts -> /usr/share/assets/fonts (so any Fedora font package can
be used as a web font)




Not all fonts installed had the same licensing requirement, people 
install fonts from other places that are not as careful as Fedora with 
the licenses. It is problematic if someone install a non free font to be 
used on their desktop application and automatically the font is shared 
on the network because he installed a web application on their machine


If some web applications needs a font it must create the symlink of that 
font on that package

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

Re: Virtual provides for files in /var/log

[Panu Matilainen]

On 07/18/2013 04:42 PM, Lennart Poettering wrote:

On Thu, 18.07.13 15:47, Panu Matilainen (pmati...@laiskiainen.org) wrote:


I would suggest it, but it is not recommended by guidelines :( so I
suggest some (not yet) standardized virtual provide, which will be
more descriptive than "syslog-files"

Vít

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies


I guess this comment doesn't apply if we explicitly add Provides:
/var/log/messages to all packages that provide the file. Hmm, or maybe
no, I don't grok RPM well enough...


Well the guideline is really just a recommendation for optimizing
yum behavior, nothing more. But yes, an explicit "Provides:
/some/path" goes into the main repository metadata so resolving a
dependency on that path doesn't require downloading the big bad file
lists.


Hmm, Panu, but who does this exactly work? If at least one package
explicitly provides /some/path, and some others only implicitly provide
it, is the big bad file list download skipped?

Which would mean either *none* of the providers shall explicitly provide
the file (which would be slow), or *all* of the provides explicitly
provide the file? If some would explicitly provide it, and others only
implicitly, then things would be broken?


Hmm, good question. I've no idea what yum does in that situation.
Most other depsolvers (have to) always download the full filelists 
anyway, making the point moot, but since yum tries to avoid it... My 
*guess* is that yum would go downloading the full filelists anyway when 
the path is outside the "common paths" stored in the primary metadata 
directly.


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

Re: Virtual provides for files in /var/log

[Bill Nottingham]

Matthew Miller (mat...@fedoraproject.org) said: 
> My main concern with this is that it's a lie. That file only exists because
> of the default configuration. In many cases, rsyslog will be configured to
> either write different files, or most likely, to write no local files at all
> as all data is forwarded. And, as discussed in another subthread, I expect
> this last configuration to be more and more common. So, not just a lie, but
> a lie which may actually make it harder to use rsyslog in ways other than
> the default.
> 
> In an ideal view, it makes most sense to provide the rsyslog default
> configuration in a subpackage which puts the /var/log/messages and
> /var/log/secure conf files in /etc/rsyslog.d -- then, this subpackage would
> provide those files. Unfortunately, in order to preserve behavior on
> upgrade, the main package would have to depend on this, kind of making the
> distinction moot.

You don't need rsyslog to require rsyslog-put-your-files-here-config, you
just need both of them to have Obsoletes for the versions before the split.

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

Re: Virtual provides for files in /var/log

[Panu Matilainen]

On 07/18/2013 06:11 PM, Matthew Miller wrote:

On Thu, Jul 18, 2013 at 02:19:30PM +0200, Lennart Poettering wrote:

So, you suggest using "Requires: /var/log/messages" and "Provides:
/var/log/messages" as indication for this, and the %ghost
/var/log/messages in the packages in question?
Sounds good to me! Matthew?


My main concern with this is that it's a lie. That file only exists because
of the default configuration. In many cases, rsyslog will be configured to
either write different files, or most likely, to write no local files at all
as all data is forwarded. And, as discussed in another subthread, I expect
this last configuration to be more and more common. So, not just a lie, but
a lie which may actually make it harder to use rsyslog in ways other than
the default.


So... /var/log/messages is not guaranteed to be there even now, because 
it depends on rsyslog configuration. So any packages which cannot handle 
missing /var/log/messages are broken already in a non-default (but 
probably not all that uncommon) config, and nobody is crying out about that.


This whole logfile provides/requires thing seems mostly like a solution 
in search of a problem to me.


- Panu -

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