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

So, my definition of default is "all system tools use Python 3, it is the only 
Python that gets to minimal buildroot/minimal Fedora installation" - that means:
- livecd can still ship Python 2
- /usr/bin/python points to Python 3
  - Please note, that the pep you're referring to also states that "python 
should refer to the same target as python2 but may refer to python3 on some 
bleeding edge distributions", so this wouldn't really be going against the pep.

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

If you look at the minimal mock buildroot for rawhide now, the only thing that 
is drawing in Python is gdb because of it's Python bindings (if I'm not 
mistaken). So compiling GDB against Python 3, which should work with newest 
gdb, will accomplish this AFAICS.

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

DNF is a continuous effort. I believe that DNF will provide it's Python 3 
bindings sooner than in F22, so Anaconda devels can simultaneously do porting 
to Python 3 as well as to DNF. IMO this is good thing, since they will just do 
one big rewrite instead of two smaller.

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

IMO we should switch this for F21, since livecd ships Python 3 anyway, so the 
switch doesn't have to happen in one point, but can be continuous.

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

This is really the last step, that is somehow tied what you mentioned as a 
reaction to 3) - going through the rest of packages on DVD and then whole 
distro. This will take few more releases I guess, but it is not that important 
as sorting out livecd.

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

Re: Multirelease effort: Moving to Python 3

[Marcela Mašláňová]

On 07/19/2013 05:44 AM, Toshio Kuratomi wrote:


On Jul 18, 2013 5:42 PM, "Michael Catanzaro" mailto:mike.catanz...@gmail.com>> wrote:
 >
 > On Thu, 2013-07-18 at 09:53 -0700, Toshio Kuratomi wrote:
 > > /usr/bin/python should refer to python2 --
 > > http://www.python.org/dev/peps/pep-0394/  I'd be -1 to changing this
 > But when python2 is no longer installed by default, surely you want to
 > get a python prompt when you type 'python'?

Yes, and for a long time, I'm going to want to get a python2 prompt.
Which means installing the package for python2, not having python3 start
on that case.



Why do you want to use old version as default? That's very conservative 
approach for Fedora ;-)
Upstream plans to support it until 2015 (maybe little longer). Fedora 
needs to be prepared for such step, so it's the right time to start 
working on it.


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

Re: F20 System Wide Change: Web Assets

[T.C. Hollingsworth]

On Thu, Jul 18, 2013 at 1:13 PM, Robert Marcano
 wrote:
> 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

Good point!  That's something I hadn't considered.

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

First of all, regardless of whether or not the shared directory exists
web applications are permitted by the draft guidelines to use symlinks
or Apache's Alias directive to make web assets available in their
namespace.  This makes migration a lot easier in many cases.

But we don't have to kill of the shared directory just to work around
this.  We can just whitelist fonts installed from the Fedora package
collection and blacklist the rest unless the sysadmin specifically
enables them.

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

Re: Rawhide tree now includes install images

[Bruno Wolff III]

On Wed, Jul 17, 2013 at 08:23:10 -0400,
  Kamil Paral  wrote:

> Is there still a plan to do builds of the normal install iso,
> analagous to the nightly composes for live images?

Yep. Dennis was going to look into doing some kind of weekly dvd iso
compose.


I'm not sure DVD is worthwhile, and it will add quite some extra bandwidth for 
mirrors.


In the context I was asking about, it wouldn't get mirrored.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Multirelease effort: Moving to Python 3

[Andrew McNabb]

On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
> 
> 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)

Renaming the python package to python2 kind of makes sense, but renaming
the python3 package to python seems needlessly confusing.  Wouldn't it
make sense to just keep python2 and python3 side by side without
ambiguity until some long future date when python2 disappears?


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

Re: Multirelease effort: Moving to Python 3

[Toshio Kuratomi]

On Jul 18, 2013 5:42 PM, "Michael Catanzaro" 
wrote:
>
> On Thu, 2013-07-18 at 09:53 -0700, Toshio Kuratomi wrote:
> > /usr/bin/python should refer to python2 --
> > http://www.python.org/dev/peps/pep-0394/  I'd be -1 to changing this
> But when python2 is no longer installed by default, surely you want to
> get a python prompt when you type 'python'?

Yes, and for a long time, I'm going to want to get a python2 prompt.  Which
means installing the package for python2, not having python3 start on that
case.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Ding Yi Chen]

- Original Message -

> Hi

> On Thu, Jul 18, 2013 at 9:43 PM, Ding Yi Chen wrote:

> > http://doc.opensuse.org/documentation/html/openSUSE/opensuse-tuning/cha.tuning.logfiles.html
> 

> > Looks like they either still have /var/log/messages,
> 
> > or their documentation team are lazy.
> 

> Be careful about such assumptions. There are bugs in the Fedora documentation
> as well and you wouldn't want anyone implying that the Fedora docs team is
> lazy. If you want to actually confirm, download the ISO and check.

> Rahul

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
Thanks for point this out. 

I am sorry if any one is offended. 

(Download ISO and check? No, I am lazy.) 

-- 
Ding-Yi Chen 
Software Engineer 
Internationalization Group 
DID: +61 7 3514 8239 
Email: dc...@redhat.com 

Red Hat, Asia-Pacific Pty Ltd 
Level 1, 193 North Quay 
Brisbane 4000 
Office: +61 7 3514 8100 
Fax: +61 7 3514 8199 
Website: www.redhat.com 

Red Hat, Inc. 
Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC 
Twitter: Red Hat APAC | Red Hat ANZ 
LinkedIn: Red Hat APAC | JBoss APAC 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Ding Yi Chen]

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

And we don't force anyone to keep rsyslog, you can just remove rsyslog
and you have everything as you love it.


-- 
Ding-Yi Chen
Software Engineer
Internationalization Group
DID: +61 7 3514 8239
Email: dc...@redhat.com

Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8100
Fax: +61 7 3514 8199
Website: www.redhat.com

Red Hat, Inc.
Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC
Twitter: Red Hat APAC | Red Hat ANZ
LinkedIn: Red Hat APAC | JBoss APAC
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Ding Yi Chen]

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

In that setting, users usually start with default choose the packages they 
EXPLICITLY
want to install/remove, they are very likely to assume that the rest of the 
system environment,
including /var/log/messages will still be there.

Besides, rsyslog is in core, which is hidden from users and most of them are 
unaware what the
rsyslog actually do and generated.

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

Do some web search, and you will find out there are handful utility let you 
read ext4 partitions.

I've used http://www.fs-driver.org/ and it can read ext3 partitions, BTW.

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

Didn't I say I don't care other daemons output to any other files (including 
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.

Did I claim that all distros and OSes have /var/log/messages? DOS and Windows 
don't have it.
Happy now?

Let's talk about the system that do have and use /var/log/messages, like Fedora 
19 and RHEL6.
How do you deal with the programs that write for either or both that use 
/var/log/messages.

Do a 
grep -cslR '/var/log/messages' /usr

you will have a brief idea what's the problem size.


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

Please note that RHEL6 and RHEL5 are still in their life cycle.
And they are unlikely to have journalctl.

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

The problem is, to you, /var/log/messages is redundant, but for others,
it is not. 
By the react of the mailling list and the results from grep the system,
it is still used by those.

Are you sure you are not going to break those? Have you tested those?

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

Yes, right, you simply let those programs and documents lost their portability. 
:-P

-- 
Ding-Yi Chen
Software Engineer
Internationalization Group
DID: +61 7 3514 8239
Email: dc...@redhat.com

Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8100
Fax: +61 7 3514 8199
Website: www.redhat.com

Red Hat, Inc.
Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBos

Re: F20 System Wide Change: No Default Syslog

[Rahul Sundaram]

Hi


On Thu, Jul 18, 2013 at 9:43 PM, Ding Yi Chen  wrote:

>
>
>
> http://doc.opensuse.org/documentation/html/openSUSE/opensuse-tuning/cha.tuning.logfiles.html
>
> Looks like they either still have /var/log/messages,
> or their documentation team are lazy.
>

Be careful about such assumptions.  There are bugs in the Fedora
documentation as well and you wouldn't want  anyone implying that the
Fedora docs team is lazy.   If you want to actually confirm, download the
ISO and check.

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

Re: F20 System Wide Change: No Default Syslog

[Ding Yi Chen]

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

http://doc.opensuse.org/documentation/html/openSUSE/opensuse-tuning/cha.tuning.logfiles.html

Looks like they either still have /var/log/messages,
or their documentation team are lazy.
-- 
Ding-Yi Chen
Software Engineer
Internationalization Group
DID: +61 7 3514 8239
Email: dc...@redhat.com

Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8100
Fax: +61 7 3514 8199
Website: www.redhat.com

Red Hat, Inc.
Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC
Twitter: Red Hat APAC | Red Hat ANZ
LinkedIn: Red Hat APAC | JBoss APAC
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Ding Yi Chen]

- Original Message -
> john.flor...@dart.biz (john.flor...@dart.biz) said:
> > > 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.

Taking your words seriously, the most sensible default is only install the core,
nothing else. 

You want network? install network drivers,
GUI? install desktop environment/WM.
Show your languages? Install language support.

For Next->Next->Ok type of users,
this "default" will lead them just a .. core.
No pretty GUI. :-)


> 
> Exactly - adding to the minimal install is generally always a supported
> operation.  Removing from the minimal install is always a 'buyer beware'
> or 'you get both pieces' operation.

Didn't Jesse Keating said something like we don't offer minimal install
other than uncheck the all boxes?

Default is just an environment that most people expected to have,
its much bigger that the minimal install. 

> 
> (Also, I do wonder if those who suggest unchecking rsyslog *in anaconda*
> do regular interactive installs. That's not been offered for quite some time
> now outside of kickstart.)

That's because it is in core, which is always hidden from users.
You can move it to standard and make it default.


-- 
Ding-Yi Chen
Software Engineer
Internationalization Group
DID: +61 7 3514 8239
Email: dc...@redhat.com

Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8100
Fax: +61 7 3514 8199
Website: www.redhat.com

Red Hat, Inc.
Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC
Twitter: Red Hat APAC | Red Hat ANZ
LinkedIn: Red Hat APAC | JBoss APAC
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Virtual provides for files in /var/log

[Matthew Miller]

On Thu, Jul 18, 2013 at 04:35:22PM -0400, Bill Nottingham wrote:
> Yes, it's just that if we're moving these packages from being broken in a
> non-default, administrator-configured configuration to being broken in the
> out-of-the-box configuration, it might be worthwhile to know that ahead of
> time, or know if there's a way to have them indicate that they now require
> the non-default configuration.

I think that the updated
https://fedoraproject.org/wiki/Changes/NoDefaultSyslog#Dependencies
is a pretty good representation of the packages in the distribution that
actually might be affected.

It's basically the case that we've NEVER had good tools for dealing with
log messages. Epylog was the closest to interesting, but the devoper (hi
Konstantin!) lost interest. So, we've got a handful of little utilities.
We'll probably discover a few more than the above list, but I doubt that
there's even _two_ handfuls.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
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

[Matthew Miller]

On Thu, Jul 18, 2013 at 01:34:40PM -0700, Adam Williamson wrote:
> Sure, but that's part of ntp, and we're supposed to be using chrony as
> Fedora's default time sync software now. It just seems untidy for
> anaconda to configure chrony but need to use a part of ntp (ntpdate or
> sntp) to test server functionality.


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


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

Re: Multirelease effort: Moving to Python 3

[Michael Catanzaro]

On Thu, 2013-07-18 at 09:53 -0700, Toshio Kuratomi wrote:
> /usr/bin/python should refer to python2 --
> http://www.python.org/dev/peps/pep-0394/  I'd be -1 to changing this
But when python2 is no longer installed by default, surely you want to
get a python prompt when you type 'python'?


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

Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 support

[Hans de Goede]

Hi All,

I'm very happy to announce the first release (r1) of my Fedora 19 ARM
remix images for Allwinner A10, A10s, A13 and A20 based devices. This
release is based on the official Fedora 19 Final for ARM images,
with u-boot and kernel(s) from the linux-sunxi project:
http://linux-sunxi.org/

Besides all the goodies from Fedora-19, this release also contains
the following new items on the Allwinner / sunxi front:

-Support for the new dual core A20 soc (tested with cubieboard2),
 this is based on forward porting the core machine code + various
 drivers from allwinners 3.3 kernel source dump to the sunxi-3.4
 sources. The following has been ported / is supported:
 -uarts
 -mmc controllers
 -ehci and ohci usb controllers (usb controllers 1 and 2, controller
  0 is an otg controller and is not supported yet.
 -video output block (hdmi, vga, lcd, composite out)
 -i2c controllers
 -axp pmic including cpu voltage scaling
 -rtc
 -sound: analog in/out, hdmi audio, spdif out (spdif untested)
 -ethernet controller (emac)
 -sata controller
 Note any functional blocks in the SOC which are not explictly
 listed as supported above are not supported atm
-Support for a couple of new boards (38 boards in total now)

You can download it here:
http://scotland.proximity.on.ca/contrib-images/hansg/Fedora-19-a10-armhfp-r1.img.xz

sha1sum: a179afafd77c26c7022392d2fa72e3fd221dd33a

It is important to read the README, the image standard comes without
u-boot pre-loaded since u-boot is board specific. The image includes
a user-friendly simple script to install the right u-boot for
your board, but if you simply xzcat the image to an sdcard, and then
boot your device with the sdcard, things will *not* work.

See the README for a list of currently supported boards.

Known Issues:
-Many boards don't have an rtc (A10 and A20 have a builtin one),
 or at least no battery backup for it, resulting in the date
 + time being wrong.
-If the date is of by more then a couple of months, "yum update"
 won't work because certificate validation fails for the https
 connection yum tries to make. So if yum fails to get its repodata
 first check (and fix) your date
-The regular (host not otg) usb-port on A10s based boards can be a
 bit quirky. It is best to plug in a hub even when using only one
 device, otherwise the device may not be recognized. If this happens,
 after adding a hub, often a power-cycle is needed too.
-The wifi chip on the Auxtek-T004 hdmi-stick is unsupported atm

Enjoy,

Hans


And to make sure everyone reads the README, let me print it here
in full:

Fedora 19 ARM for Allwinner A10, A10s, A13 and A20 devices README
-

Quickstart guide


1) Insert an sdcard, note any data on the card will be destroyed!
2) Make sure the card is not mounted, run "mount" and if the card shows
   up in the output umount its partitions
3) Write the img file to the card, ie as root do:
   xzcat Fedora-19-a10-armhfp-r1.img.xz > /dev/mmcblk0
   sync
4) The card is not yet ready for use! Since the A10 u-boot is board
   specific, the image comes without any uboot install, follow the next
   steps to install the right u-boot for your board
5) Remove the card, and re-insert it. The uboot partition should get
   automatically mounted, if not mount it manually,
6) As root (or through sudo) run: /select-board.sh, ie:
   sudo /run/media/hans/uboot/select-board.sh

   If you've dialog installed the select-board.sh script will prompt for
   your board. If you don't have dialog installed, it will print the list
   of supported boards. Lookup your board and re-run the script with the
   shortname for your board as argument, ie:
   sudo /run/media/hans/uboot/select-board.sh mk802
7) umount the uboot and rootfs partitions, ie:
   umount /run/media/hans/uboot
   umount /run/media/hans/rootfs
8) Your sdcard is now ready for use
9) *Before* powering up your A10 device connect it to an hdmi or dvi monitor
10) When first booting from the sdcard inserted Fedora will automatically
   reboot once, this is part of the process to resize the root partition to
   fill the entire sdcard and is normal behavior.
11) After the automatic reboot Fedora will start with the initial-setup wizard:
   11a) Configure networking, note:
* If you've an A10 board with wired ethernet and you want to use dhcp
  you don't need to do anything.
* If you've an A20 board, your ethernet will have a random mac-address,
  so if you want to configure a static ip-address and want it to stick
  across reboots, go to the ethernet-tab, select the mac-address field
  and delete its contents, so that the static ip address you're
  configuring does not get tied to the random mac-address.
   11b) Setup the time zone
   11c) Set a root password
   11d) Create a user
12) Log in as the just created user
13) Enjoy Fedora on your A10 device


Supported Devices:
--

Fedor

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

[Chris Adams]

Once upon a time, Adam Williamson  said:
> Sure, but that's part of ntp, and we're supposed to be using chrony as
> Fedora's default time sync software now. It just seems untidy for
> anaconda to configure chrony but need to use a part of ntp (ntpdate or
> sntp) to test server functionality.

Well, you are wanting two different things: a clock manager and a
one-shot NTP server tester.

You could always use check_ntp from Nagios plugins for the one-shot. :)
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Adam Williamson]

On Thu, 2013-07-18 at 10:59 -0400, 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.

Yes, that is indeed the decision we are trying to make. The point is
that for _either_ side to describe the _other_ side as trying to 'force'
anything on anyone is disingenuous.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: Virtual provides for files in /var/log

[Bill Nottingham]

Panu Matilainen (pmati...@laiskiainen.org) said: 
> 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.

Yes, it's just that if we're moving these packages from being broken in a
non-default, administrator-configured configuration to being broken in the
out-of-the-box configuration, it might be worthwhile to know that ahead of
time, or know if there's a way to have them indicate that they now require
the non-default configuration.

I guess it's the equivalent of marking packages that don't work unless
SELinux is enabled, or don't work unless the firewall is off. There are
likely better ways to fix them.

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

[perl-Test-Kwalitee] Update to 1.09

[Paul Howarth]

commit a56d7c46143a553b5a169de05ed02182a8aa80d9
Author: Paul Howarth 
Date:   Thu Jul 18 21:31:09 2013 +0100

Update to 1.09

- New upstream release 1.09
  - The has_test_pod, has_test_pod_coverage tests have been removed - they 
are
classified as 'extra', and have been largely considered to be a bad idea
anyway (these are often shipped as, and ought to be, in xt/)
  - The extractable test has been removed, as it does nothing in dists 
before
there is a tarball present
  - New tests have been added: all standard kwalitee tests that can be run 
on a
bare distribution without a tarball
- BR: perl(Capture::Tiny) for test suite

 perl-Test-Kwalitee.spec |   14 +-
 sources |2 +-
 2 files changed, 14 insertions(+), 2 deletions(-)
---
diff --git a/perl-Test-Kwalitee.spec b/perl-Test-Kwalitee.spec
index 53876fc..3cc1767 100644
--- a/perl-Test-Kwalitee.spec
+++ b/perl-Test-Kwalitee.spec
@@ -1,5 +1,5 @@
 Name:  perl-Test-Kwalitee
-Version:   1.08
+Version:   1.09
 Release:   1%{?dist}
 Summary:   Test the Kwalitee of a distribution before you release it
 License:   GPL+ or Artistic
@@ -15,6 +15,7 @@ BuildRequires:perl(Module::CPANTS::Analyse) >= 0.87
 BuildRequires: perl(namespace::clean)
 BuildRequires: perl(Test::Builder) >= 0.88
 # Test Suite
+BuildRequires: perl(Capture::Tiny)
 BuildRequires: perl(File::Temp)
 BuildRequires: perl(Test::CheckDeps) >= 0.006
 BuildRequires: perl(Test::Deep)
@@ -48,6 +49,17 @@ perl Build.PL --installdirs=vendor
 %{_mandir}/man3/Test::Kwalitee.3pm*
 
 %changelog
+* Thu Jul 18 2013 Paul Howarth  - 1.09-1
+- Update to 1.09
+  - The has_test_pod, has_test_pod_coverage tests have been removed - they are
+classified as 'extra', and have been largely considered to be a bad idea
+anyway (these are often shipped as, and ought to be, in xt/)
+  - The extractable test has been removed, as it does nothing in dists before
+there is a tarball present
+  - New tests have been added: all standard kwalitee tests that can be run on a
+bare distribution without a tarball
+- BR: perl(Capture::Tiny) for test suite
+
 * Tue Jul 16 2013 Paul Howarth  - 1.08-1
 - Update to 1.08
   - Documentation fixed to reflect which indicators are actually available
diff --git a/sources b/sources
index 85aedc8..c7802f4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-dfd19b68d48c7a0e9a74b25a2b48990e  Test-Kwalitee-1.08.tar.gz
+0dde5511d67dd592ca8490ff9c6984ea  Test-Kwalitee-1.09.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: Remove deprecated calls of using ntpdate in favor of ntpd

[Adam Williamson]

On Thu, 2013-07-18 at 09:39 +0200, Miroslav Lichvar wrote:

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

Sure, but that's part of ntp, and we're supposed to be using chrony as
Fedora's default time sync software now. It just seems untidy for
anaconda to configure chrony but need to use a part of ntp (ntpdate or
sntp) to test server functionality.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: F20 System Wide Change: Visible Cloud

[Adam Williamson]

On Wed, 2013-07-17 at 18:08 -0400, Matthew Miller wrote:
> On Wed, Jul 17, 2013 at 02:12:03PM -0700, Adam Williamson wrote:
> > > So, to put a number on it, does that mean _at_ the change freeze and 
> > > branch
> > > which is "no earlier than 2013-08-06"?
> > As things stand, yeah. I think for F19 we actually started doing TCs
> > earlier, but certainly by then.
> 
> Okay, cool. I wil draft up a minor revision to the existing EC2 test case
> and create one in the same vein for OpenStack.
> 
> Do you think those tests are too much for alpha? 

It doesn't seem unreasonable.

> The most simple proposal is
> simply to make those the alpha criteria and not, yet at least, develop
> anything more for further. (I'll also look through the existing criteria and
> note any where a cloud image note might be appropriate.) Alternately, we
> could make those the beta critera and have "we can generate an image at all"
> as alpha, at least for this time around. (What with it being the first time
> we'll properly _have_ an image at alpha.)

I think we could give that a shot.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

File Test-Kwalitee-1.09.tar.gz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-Test-Kwalitee:

0dde5511d67dd592ca8490ff9c6984ea  Test-Kwalitee-1.09.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: Virtual provides for files in /var/log

[Matthew Miller]

On Thu, Jul 18, 2013 at 04:11:47PM -0400, Bill Nottingham wrote:
> > 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.

Oooh, clever!


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

[Bill Nottingham]

john.flor...@dart.biz (john.flor...@dart.biz) said: 
> > 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.

Exactly - adding to the minimal install is generally always a supported
operation.  Removing from the minimal install is always a 'buyer beware'
or 'you get both pieces' operation.

(Also, I do wonder if those who suggest unchecking rsyslog *in anaconda*
do regular interactive installs. That's not been offered for quite some time
now outside of kickstart.)

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

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

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

[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

[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

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

[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

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

[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

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

[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

[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

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

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

[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

[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

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

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

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

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

[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

[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

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

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

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

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

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

[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

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

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

[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

[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

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

[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

[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

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

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

[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

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

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

[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

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

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

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

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

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

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

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

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