Re: Multirelease effort: Moving to Python 3

[Bohuslav Kabrda]

- Original Message -
> On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
> > 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
> 
> I have a concern about bloating @core and by extension the cloud image.
> Right now, python is about 5% of the total on-disk usage. I'd hate to see
> that go to 10%. Therefore, I'd like to see a goal of making the transition
> for usage in the base cloud image go entirely from python2 to python3 in
> one release cycle.
> 
> (Roughly, that's @core + cloud-init, which isn't currently on your list.)
> 

Doing everything in one shot sounds reasonable from this POV, I'll try to put 
this into my plan (I'll go through cloud-init the same way I went through 
livecd and post my findings here).

> 
> --
> Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  

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

[Bohuslav Kabrda]

- Original Message -
> On Fri, Jul 19, 2013 at 08:20:02AM +0200, Marcela Mašláňová wrote:
> > On 07/19/2013 05:44 AM, Toshio Kuratomi wrote:
> > >
> > >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.
> > >
> > >
> > >
> > Why do you want to use old version as default? That's very
> > conservative approach for Fedora ;-)
> 
> This is the wrong mental model of the relationship between python2 and
> python3.  As a comparison this argument is akin to saying, "C is the old
> version of C++.  We should be porting all our code to use the C++ compiler
> in Fedora"  C is much more compatible to C++ than python2 is to python3 so
> this would be a less drastic change.
> 
> python2 and python3 are separate languages.  There is a lot of similarity
> between the two and with recent enough versions of python2 (2.7) and python3
> (python3.4) and some external libraries (python-six) and by sticking to some
> specific coding styles ( http://python3porting.com/noconv.html ) and by
> sometimes resorting to having separate files for some python2-specific
> routines vs python3-specific routines you can write code that is valid and
> runs under either language.  That does not mean that they are the same
> language.
> 

The problem is that you're basically saying "my mental model is the right one", 
which is not necessarily true for everyone (and not necessarily true 
generally). Taking your arguments a bit further, Python 2.6 and 2.7 are 
different languages too, since there are some backward incompatible additions 
to Python 2.7.

> > 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.
> > 
> I am wholeheartedly in favor of "working on it".  But things like switching
> the default /usr/bin/python are not "working on it".  Those are backwards
> incompatible, end user visible, changes of expectations that we do not need
> to implement now in order to be a leader.  When people invoke python, they
> expect python2.  When they want python3, they expect to type python3 to get
> that.  At the moment, causing /usr/bin/python to invoke python3 is just
> going to cause confusion and end user confusion (arch is the only linux
> distro that sets /usr/bin/python to point to python3).
> 
> As an example here, let's suppose that we were to stop shipping firefox by
> default and started shipping chromium instead.  Would we make
> /usr/bin/firefox invoke /usr/bin/chromium?  Would we have a firefox icon
> that started chromium when clicked?  When applied here, it does seem to make
> more sense for end user's to notice that there isn't a firefox icon and
> either consciously open up a different web browser or else install firefox
> to get their preferred browsing experience, right?  /usr/bin/python is the
> same way.  People have tons of scripts on their systems with
> #!/usr/bin/python shebang lines.  If we change /usr/bin/python to
> point to /usr/bin/python3 then we'll force them to deal with either porting,
> going through all their scripts and replacing them with /usr/bin/python2, or
> switching to another distribution which doesn't change the meanings of  well
> known interpreter paths for no gain.
> 

Again, this is all based on your "mental model" and on your assumption that it 
is the correct one. I just don't agree.

> All this is not to say that there might not be a time in the future when it
> makes sense to have python3 assume the /usr/bin/python name.  However, that
> time is *after* the collective user consciousness has stopped using
> /usr/bin/python, not before.  When we can go to pycon and talks are assumed
> to be targeting python3 rather than python2.  After people wanting to do
> a simple calculation on the CLI stop doing /usr/bin/python -c 'print 5 + 6'.
> This is probably after alternate python implementations like pypy and jython
> either die off or finally make the switch to implementing python3.  My guess
> is this will be after there's a RHEL release that includes /usr/bin/python3
> in the default install since RHEL and CentOS are major parts of our
> ecosystem and will have to be able to use the python3 syntax on both their
> RHEL servers and Fedora machines.  To some extent, this also depends on what
> other large distros set as their expectations: Debian and Ubuntu currently
> point /usr/bin/python to python2.  AFAIK, only Arch is pointing to python3.
> My

Re: Grepping through all Fedora specfiles?

[Ralf Corsepius]

On 07/22/2013 11:39 AM, Ville Skyttä wrote:

Hello,

I'd like to grep through all specfiles (and preferably also patches and
sources in git) for rawhide, this time related to the unversioned
docdirs F20 feature, and sometimes for other reasons. Hopefully there's
a better way than to fedpkg clone all packages one at a time... does
anyone know of one?

Back in CVS times there were downloadable daily checkout seed tarballs
which were excellent for this purpose, but I don't think such things
exist nowadays, do they?


For similar purposes, I have been using the CSV table returned by
"https://admin.fedoraproject.org/pkgdb/lists/bugzilla?tg_format=plain";

I am downloading the CSV-table and then use scripts to filter the CSV 
into lists and subsequently to feed them into further scripts for 
further processing.


Ralf

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

Re: Why does so much virt stuff depend on glusterfs?

[Chris Murphy]

On Jul 22, 2013, at 6:26 PM, Matthew Miller  wrote:

> On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
>> Today in Absurd Dependency Bingo:
>>> glusterfs   x86_64 3.4.0-2.fc19 @updates-testing 
>>> 4.7 M
> [...]
>>> qemu-common x86_64 2:1.4.2-4.fc19   @updates-testing 
>>> 624 k
> 
> $ rpm -q --changelog qemu-common
> [...]
> * Wed May 15 2013 Cole Robinson  - 2:1.4.1-2
> - Enable gluster support
> 
> And then all the rest just falls out from there because they require qemu.
> 
> 
>>> vinagre x86_64 3.8.2-1.fc19 @side
>>> 3.0 M
> 
> (This one requires spice.)
> 
> At 4.7M glusterfs isn't exactly tiny, and is another one of these things
> that's not so useful unless configured (even though that's awesomely easy);
> maybe the libs could be split out?

glusterfs is included on Desktop/live install media. And it produces a big red 
FAIL in systemctl status listing by default. It seemed at first this was due to 
an avc denial, but that's since been fixed, yet the failure to start by default 
remains.

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


Chris Murphy
-- 
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 7/22/13, Adam Williamson  wrote:
> On Mon, 2013-07-22 at 15:23 +0200, Florian Weimer wrote:
>> On 07/22/2013 12:31 PM, T.C. Hollingsworth wrote:
>> > On Mon, Jul 22, 2013, Florian Weimer  wrote:
>> >> Can we please use a different name, like "webdata"?  The term "asset"
>> >> seems
>> >> to scare some people.
>> >
>> > Huh?  It's a pretty common industry term for "static bits used as
>> > dependencies for websites". I've never heard of anyone being scared
>> > of it.
>>
>> The term has a completely different meaning in the fields of law and
>> accounting.
>
> Fortunately we're making an operating system, not prosecuting a case or
> auditing anyone's accounts, so that does not seem to present a problem.

Indeed.  Also you'll notice that upthread we agreed to change the
directory to /usr/share/web-assets just to reduce any potential
confusion here.

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

Re: F20 System Wide Change: No Default Sendmail

[Oron Peled]

Hi,

On Monday 22 July 2013 21:15:14 Lennart Poettering wrote:
> The point I am trying to make is that if you have something that is
> vulnerable to a DoS attack you need to have a strategy to handle
> that.

A very simple strategy exists -- alias root's mail to a regular user.

I previously said it should be done during installation for usability
reasons -- now you've just added another good reason.

Please note that this is relevant even for the suggested world
of "non-MTA-by-default", because some people (horror, shock, awe)
may actually install one.
(unless DoS traps are OK for non-default installed packages...)

Bye,

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron
"Linux: like the air you breathe, ubiquitous and free"

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

Re: F20 System Wide Change: No Default Sendmail

[Oron Peled]

Hi,

On Monday 22 July 2013 20:33:32 Lennart Poettering wrote:
> On Sun, 21.07.13 01:50, Oron Peled (o...@actcom.co.il) wrote:
> > OK, I won't count mailx and mutt because we talk about different audience,
> > should we open bug-reports for the rest? (kmail? evolution?)
> 
> Goog luck filing bugs against Thunderbird, GMail and Zimbra to add
> support for local mail queue reading...

Hmmm... I didn't know any of them was installed by *default*.
After all, the issue is *default* setup, isn't it?

[bit-off-topic: unlike the others you mentioned, Thunderbird is a local MUA.
 Not being able to process any local mailbox (mbox/maildir/whatever)
 was the primary reason I never used it -- I cannot afford loosing
 almost 20 years of email history, much less convert it to some HTML
 based private format]

> > Cron was already mentioned, but every one seem to ignore the fact that
> > regular users don't have permission to read system logs.
> 
> journald actually splits out user logs and use filesystem ACLs to ensure
> that the user gets read access to his own logs. This doesn't work for
> syslog (and also not if cron first collects all logs and then logs them
> as root).

[thanks for referring to this issue. In a separate sub-thread I complained
 about not being addressed before seeing this mail]

There are two issues however:
 * The log-splitting of journald is really nice feature. But it doesn't
   work for cron:
$ echo '* * * * * /bin/echo "Test output from cron"' | \
 crontab '-'# than wait a minute
$ journalctl# only shows crontab, not the cron output
$ su -
# journalctl# Cron output is properly shown.

   So this issue is still outstanding (but I'll bet you knew that)

 * Logs are inherently line-oriented (which is very good for their
   intended use case). However, many cron-jobs produce various reports
   which are multi-line in their nature -- not a very good fit.

IMO a reasonable path may be:
 * Not installing MTA at all for the *minimal* case.

 * Install MTA for the default case (especially desktops).

 * In that case, no SMTP port listening is needed. The default use
   case is about the ability to deliver messages by piping them
   to the MTA. No application/tool that I know of, tries to notify
   by sending to STMP on localhost (am I wrong here?)

 * Automatic mail-alias of root to the installing user will go a long
   way to make it more visible/useful.

 * Adding local mailbox as default configuration of MUA's (at least
   those installed by default for desktops) is even better.

Bye,

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron
Linux:  If you're not careful, you might actually learn something.
-- Allen Wong

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

Re: F20 System Wide Change: No Default Sendmail

[Lennart Poettering]

On Tue, 23.07.13 03:14, Oron Peled (o...@actcom.co.il) wrote:

> On Monday 22 July 2013 21:00:36 Lennart Poettering wrote:
> > If you argue from the viewpoint of how universially available an API is
> > to make it "standard", then I would like to remind you that there are
> > probably more Ubuntu installations in the world thatn Fedora
> > installations, and they haven't included any MTA by default in 6 years
> > or so.
> 
> Finally I know what I was missing all these years ;-)
> 
> [sorry, it was just too good, though you have a valid point]
> 
> BTW: nobody ever answered how desktop users are supposed to read the
>  output of their cron-jobs (they don't have permissions to read logs).

Actually, if you'd look closely it has been answered 3 times now,
already, just on this thread.

Lennart

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

Re: Why does so much virt stuff depend on glusterfs?

[Matthew Miller]

On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
> Today in Absurd Dependency Bingo:
> >  glusterfs   x86_64 3.4.0-2.fc19 @updates-testing 
> > 4.7 M
[...]
> >  qemu-common x86_64 2:1.4.2-4.fc19   @updates-testing 
> > 624 k

$ rpm -q --changelog qemu-common
[...]
* Wed May 15 2013 Cole Robinson  - 2:1.4.1-2
- Enable gluster support

And then all the rest just falls out from there because they require qemu.


> >  vinagre x86_64 3.8.2-1.fc19 @side
> > 3.0 M

(This one requires spice.)

At 4.7M glusterfs isn't exactly tiny, and is another one of these things
that's not so useful unless configured (even though that's awesomely easy);
maybe the libs could be split out?

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

[Matthew Miller]

On Tue, Jul 23, 2013 at 03:14:32AM +0300, Oron Peled wrote:
> BTW: nobody ever answered how desktop users are supposed to read the
>  output of their cron-jobs (they don't have permissions to read logs).

They do have permissions to read journal entries that come from their
userid. 

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

Why does so much virt stuff depend on glusterfs?

[Adam Williamson]

Today in Absurd Dependency Bingo:


> Dependencies Resolved
> 
> 
>  Package Arch   Version  Repository
> Size
> 
> Removing:
>  glusterfs   x86_64 3.4.0-2.fc19 @updates-testing 4.7 
> M
> Removing for dependencies:
>  glusterfs-api   x86_64 3.4.0-2.fc19 @updates-testing  88 
> k
>  glusterfs-fuse  x86_64 3.4.0-2.fc19 @updates-testing 233 
> k
>  gnome-boxes x86_64 3.8.3-1.fc19 @fedora  4.1 
> M
>  libcacard   x86_64 2:1.4.2-4.fc19   @updates-testing  81 
> k
>  libvirt x86_64 1.0.5.4-1.fc19   @updates-testing 0.0 
>  
>  libvirt-daemon  x86_64 1.0.5.4-1.fc19   @updates-testing 4.5 
> M
>  libvirt-daemon-config-network   x86_64 1.0.5.4-1.fc19   @updates-testing 0.0 
>  
>  libvirt-daemon-config-nwfilter  x86_64 1.0.5.4-1.fc19   @updates-testing 6.1 
> k
>  libvirt-daemon-driver-interface x86_64 1.0.5.4-1.fc19   @updates-testing  93 
> k
>  libvirt-daemon-driver-libxl x86_64 1.0.5.4-1.fc19   @updates-testing 197 
> k
>  libvirt-daemon-driver-lxc   x86_64 1.0.5.4-1.fc19   @updates-testing 219 
> k
>  libvirt-daemon-driver-network   x86_64 1.0.5.4-1.fc19   @updates-testing 126 
> k
>  libvirt-daemon-driver-nodedev   x86_64 1.0.5.4-1.fc19   @updates-testing  93 
> k
>  libvirt-daemon-driver-nwfilter  x86_64 1.0.5.4-1.fc19   @updates-testing 159 
> k
>  libvirt-daemon-driver-qemu  x86_64 1.0.5.4-1.fc19   @updates-testing 919 
> k
>  libvirt-daemon-driver-secretx86_64 1.0.5.4-1.fc19   @updates-testing  76 
> k
>  libvirt-daemon-driver-storage   x86_64 1.0.5.4-1.fc19   @updates-testing 192 
> k
>  libvirt-daemon-driver-uml   x86_64 1.0.5.4-1.fc19   @updates-testing 115 
> k
>  libvirt-daemon-driver-xen   x86_64 1.0.5.4-1.fc19   @updates-testing 226 
> k
>  libvirt-daemon-kvm  x86_64 1.0.5.4-1.fc19   @updates-testing 0.0 
>  
>  libvirt-daemon-qemu x86_64 1.0.5.4-1.fc19   @updates-testing 0.0 
>  
>  qemux86_64 2:1.4.2-4.fc19   @updates-testing 0.0 
>  
>  qemu-common x86_64 2:1.4.2-4.fc19   @updates-testing 624 
> k
>  qemu-imgx86_64 2:1.4.2-4.fc19   @updates-testing 1.9 
> M
>  qemu-kvmx86_64 2:1.4.2-4.fc19   @updates-testing 0.0 
>  
>  qemu-system-alpha   x86_64 2:1.4.2-4.fc19   @updates-testing 4.1 
> M
>  qemu-system-arm x86_64 2:1.4.2-4.fc19   @updates-testing 5.2 
> M
>  qemu-system-crisx86_64 2:1.4.2-4.fc19   @updates-testing 2.8 
> M
>  qemu-system-lm32x86_64 2:1.4.2-4.fc19   @updates-testing 2.8 
> M
>  qemu-system-m68kx86_64 2:1.4.2-4.fc19   @updates-testing 3.8 
> M
>  qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   @updates-testing 5.6 
> M
>  qemu-system-mipsx86_64 2:1.4.2-4.fc19   @updates-testing  21 
> M
>  qemu-system-or32x86_64 2:1.4.2-4.fc19   @updates-testing 2.7 
> M
>  qemu-system-ppc x86_64 2:1.4.2-4.fc19   @updates-testing  18 
> M
>  qemu-system-s390x   x86_64 2:1.4.2-4.fc19   @updates-testing 3.1 
> M
>  qemu-system-sh4 x86_64 2:1.4.2-4.fc19   @updates-testing 7.5 
> M
>  qemu-system-sparc   x86_64 2:1.4.2-4.fc19   @updates-testing 7.3 
> M
>  qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   @updates-testing 2.7 
> M
>  qemu-system-x86 x86_64 2:1.4.2-4.fc19   @updates-testing  11 
> M
>  qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   @updates-testing 5.6 
> M
>  qemu-user   x86_64 2:1.4.2-4.fc19   @updates-testing  52 
> M
>  spice-glib  x86_64 0.20-2.fc19  @updates-testing 1.2 
> M
>  spice-gtk   x86_64 0.20-2.fc19  @updates-testing 134 
> k
>  spice-gtk-pythonx86_64 0.20-2.fc19  @updates-testing  52 
> k
>  spice-gtk3  x86_64 0.20-2.fc19  @updates-testing 228 
> k
>  vinagre x86_64 3.8.2-1.fc19 @side3.0 
> M
>  virt-managernoarch 0.10.0-1.fc19@updates-testing 3.6 
> M
>  virt-viewer x86_64 0.5.6-1.fc19 @updates-testing 990 
> k

WAT?
-- 
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: No Default Sendmail

[Oron Peled]

On Monday 22 July 2013 21:00:36 Lennart Poettering wrote:
> If you argue from the viewpoint of how universially available an API is
> to make it "standard", then I would like to remind you that there are
> probably more Ubuntu installations in the world thatn Fedora
> installations, and they haven't included any MTA by default in 6 years
> or so.

Finally I know what I was missing all these years ;-)

[sorry, it was just too good, though you have a valid point]

BTW: nobody ever answered how desktop users are supposed to read the
 output of their cron-jobs (they don't have permissions to read logs).

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron
"write your own operating system.  It has worked every time for me"
   -- Linus Thorvalds

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

Re: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Matthew Miller]

On Mon, Jul 22, 2013 at 12:13:25PM -0600, Eric Smith wrote:
> But it's not an objective of Fedora to have long-term-stable releases
> suitable for running servers!  No one in their right mind runs any
> rapid development distribution (not just Fedora) on critical
> infrastructure.

I'd like to qualify this a little bit. Some people certainly do, including
in such surprising places as high-frequency trading, and in other places as
a base for virtualization across many servers. Maybe these people aren't
exactly in their right minds, and these are certainly special cases, but
Fedora *is* really used in critical infrastructure.




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

[Lennart Poettering]

On Mon, 22.07.13 19:29, Matthew Miller (mat...@fedoraproject.org) wrote:

> On Tue, Jul 23, 2013 at 12:36:19AM +0200, Lennart Poettering wrote:
> > journald is in theory fine with 2^64 bytes per message. In practice (due
> > to the CPU cost of compressing large blobs with XZ while we write it to
> > disk) a few MB should be fine. Also, cronie will split up the messages
> > by line anyway if it logs to syslog instead of sendmail.
> 
> That seems less good -- is there a way to reassemble the messages.

It does have clear advantages though: You can get a live view into the
output of a long-running job. If you queue everything up and only submit
it as one blob then the job would be completely opaque until complete.

With systemd's own job handling we generally only use line-by-line
loggin, but provide useful tools to then view them as one continous
stream ("journalctl -u foobar.service -o cat" for example).

But anyway, the journal doesn't make any restrictions. Whatever
philosophy services like cron prefer on this, we handle either.

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 Sendmail

[Matthew Miller]

On Tue, Jul 23, 2013 at 12:36:19AM +0200, Lennart Poettering wrote:
> journald is in theory fine with 2^64 bytes per message. In practice (due
> to the CPU cost of compressing large blobs with XZ while we write it to
> disk) a few MB should be fine. Also, cronie will split up the messages
> by line anyway if it logs to syslog instead of sendmail.

That seems less good -- is there a way to reassemble the messages.

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

[Lennart Poettering]

On Mon, 22.07.13 15:26, Robert Nichols (rnicholsnos...@comcast.net) wrote:

> On 07/22/2013 11:36 AM, Lennart Poettering wrote:
> > I am pretty sure that most of the stuff we currently mail
> >(like the log output of cron jobs) simply makes no sense as mail, and
> >should much rather be treated exactly like all other log output. There's
> >nothing special really about cron that would make it so much better
> >suitable for sending out its logs per mail, rather then just log them.
> 
> How many megabytes can the log system reasonably accept in a single message?
> The output from a cron job can be a lot more than what anyone would
> consider to be a reasonable log message.

journald is in theory fine with 2^64 bytes per message. In practice (due
to the CPU cost of compressing large blobs with XZ while we write it to
disk) a few MB should be fine. Also, cronie will split up the messages
by line anyway if it logs to syslog instead of sendmail.

Lennart

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

Re: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Adam Williamson]

On Mon, 2013-07-22 at 12:13 -0600, Eric Smith wrote:
> On Mon, Jul 22, 2013 at 10:52 AM, "Jóhann B. Guðmundsson"
>  wrote:
> > On 07/22/2013 04:41 PM, Stephen Gallagher wrote:
> >> They chose to use a _downstream_ distribution. RHEL *is* Fedora, it's
> >> just a Fedora that's been hardened and held to a certain level of
> >> ABI/API compatibility.
> > Which is my point exactly instead of helping increasing the overall quality
> > of Fedora the infrastructure decide to run to another distribution.
> >
> > RHEL != Fedora
> 
> But it's not an objective of Fedora to have long-term-stable releases
> suitable for running servers!  No one in their right mind runs any
> rapid development distribution (not just Fedora) on critical
> infrastructure.

Is _that_ why the nice men in white coats keep showing up and taking me
away to the bouncy bouncy room?!
-- 
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

[slic3r/f19] (3 commits) ...Filter perl(Wx::GLCanvas) from requires, it's optional and not yet in Fedora

[Miro Hrončok]

Summary of changes:

  2cba691... New upstream release (*)
  6eb46fe... New upstream release 0.9.10b (*)
  4806989... Filter perl(Wx::GLCanvas) from requires, it's optional and  (*)

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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Peter MacKinnon]

Shout out to my fellow Flocker, Matt...

 Original Message 
Subject: RFC: Proposal for a more agile "Fedora.next" (draft of my 
Flock talk)

Date: Mon, 22 Jul 2013 09:38:54 -0400
From: Matthew Miller 
Reply-To: Development discussions related to Fedora 


To: Fedora Development List 



Obviously, no-bundled-libs is a crucial part of the packaging guidelines
today. As a sysadmin, I know why it's important. This is not just a noble
goal, but also something that pragmatically makes systems better. But, 
it's
also keeping us from having software that people really use in Fedora. 
Chef
and Hadoop are two big examples. This hurts us more than it helps the 
world.

So, in some areas, we need a different approach.



The Big Data SIG is trying to adapt Hadoop 2.x into Fedora for F20 
, and I'll be sharing our 
insights on this at Flock  in a couple of 
weeks. In Matt's conceptual architecture I suppose Hadoop Common would 
live in the Ring 2-to-3 orbit somewhere. It is a core in it's own right 
(it provides a distributed, replicated file system) in that there is an 
every growing software ecosystem that has emerged around it, and the SIG 
would like Fedora to be the OS of choice for that ecosystem. Stable 
enough for deployment but a feature-rich, current and productive 
environment for the developers in that evolving ecosystem. The Hadoop 
runtime is an orchestration of JVM-based daemons which can be viewed as 
system-level services, thus an obvious candidate for well-defined 
integration with Fedora via packaging: correct permissions, systemd 
scripts, logs, etc.


However, the root of that core is a set of older and deprecated Java 
dependencies (e.g., Jetty 6, Tomcat 5.5) which are expressed via the 
Apache Maven build tool. The "quick and dirty" label used by another 
poster of a VERY popular build tool like Maven does it a disservice. The 
fact is that it is exceedingly popular in the Java development community 
and has been for some time. Anyway, the challenge for this project is 
the reconciliation of it's stable dependencies versus the ever-changing 
bleeding edge that is typically found in the latest Fedora release. A 
lot of our efforts so far have been the various API and build 
specification changes necessary to try to make Hadoop fit into Fedora.


So far, so good...sort of. We can make the basic use case and tests work 
with the modified dependencies but in doing so we risk giving up parity 
with the Apache baseline (including the JRE) and potentially lose out to 
other so-called "dirty RPMs". Ideally, we wouldn't be forced into some 
of these adaptations and compromises if there were Fedora packaging 
alternatives that would give us (a SIG ring?) more control over the 
bundles needed by Hadoop as opposed to the ones mandated by the latest 
Fedora release. Make no mistake: patches are fed from the SIG to the 
Hadoop community to try to bump the versions there. But the upstream 
project can't and won't chase an ever-vanishing point in the distance. 
They view their lower dependencies much like a stable OS such as RHEL 
and change should be deliberated there.


I feel like Matt has at least kick-started the discussion around how 
Fedora could evolve to support orthogonal dependency models that more 
readily adapt to external projects like Hadoop. Not that our SIG has any 
profound answers. :-)


Thus, we are very interested in _any_ packaging architecture proposals 
that could help relieve our initiative's pain points, and look forward 
to further constructive discussion of the same.


My $0.02,
\Pete


--
Peter MacKinnon
MRG Grid/Big Data
Red Hat Inc.
Raleigh, NC

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

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

[Frank Ch. Eigler]

vgoyal wrote:

> [...]
>> Have you considered a non-cryptographic solution, like a physical
>> presence check to (temporarily) disable Secure Boot so that the
>> kexec restriction no longer applies?  [...]
>
> I think kyle has a patch which will allow disabling secureboot
> restriction if one is on console. [...]

Considering that kexec/kdump events get triggered asynchronously
(whenevery the kernel panics), someone cannot be assumed to be sitting
physically at the terminal, ready to press a sysrq to make that
secureboot-disabling transition.  (One wouldn't want to press
sysrq-foo too early, since AIUI it's a one-way transition.)

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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Matthew Miller]

On Mon, Jul 22, 2013 at 11:45:22AM -0600, Kevin Fenzi wrote:
> > we need the policies to make this ring part of Fedora. So, a
> > practical follow-up to this proposal would be a committee to design
> > the policies for Ring 2 and how they work.
> Sure. Of course you mean, design the policies and get feedback and then
> get approval from fesco/Board. ;) 

Absolutely. I am in no way suggesting we _also_ redesign the governance
model. Such a committee would be authorized by FESCO and work together with
the FPC.


> > I expect that for practical use, five might be available but users
> > would pick one. (Or in some cases two -- one for managing the base
> > and one for what's on top of that.)
> Well, or you are going to have to use whatever the SIG/whatever uses
> right? so, base with rpms, then add some other rpms, then a SCL for
> something, then you need some gems, etc. 

That might happen on a system very overloaded for multiple purposes.
Generally, I don't think we'd want to encourage it, just like we don't
encourage 'everything' installs now.

> Well, with my infrastructure hat on, I'd be first talking about
> infrastructure resources. Say a SIG formed around gitlab, and said: We

Let me interrupt right there. :) I'm not suggesting that we have sigs around
particular applications. SIGs would be (as they are now, actually) around
the different langage stacks and environments.

On the gem example in specific, I don't think there would be any win in
converting _our_ infrastructure to making gems. Instead, we'd work to build
greater trust in upstream, so that we'd have the same level of confidence
that a signed gem from rubygems.org is licensed properly, free of malware,
and traceable to the owner as we do for current Fedora RPMs. Then, we could
have more transparent gem-to-rpm tools (or even use RPMs possibly generated
by rubygems.org with Fedora as a target) for the install-as-root cases, and
possibly eventually develop infrastructure around Bundler for managing gems
with trusted signatures, regardless of their proximate install source. But
in any case, we'd start small and build up to it.


> So, IMHo, if we go the route of allowing/shipping/maintaining non rpm
> collections, we should be very clear up front what resources could be
> expected. 

Right -- very little.


> > Hopefully some of the Software Collections people can elaborate more
> > on what they need. I think "built in and distributed with Fedora
> > infrastructure" is roughly what I mean.
> I'd prefer a setup where some SIG defines a collection somehow and end
> users can grab that and build the collection locally and use it. Then
> support for that would fall on the SIG that created the definition. 

I think this is an okay first direction, but I don't think it delivers
enough of what people need.


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

Re: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Jóhann B. Guðmundsson]

On 07/22/2013 08:17 PM, Toshio Kuratomi wrote:

>

Well, I did what you asked and I don't know what you are getting at.
So I suppose either your instructions were unclear or you just wanted
me to see that the FPC subpackage guidelines work as designed.


So you installed a sub package ( or simply used one of the components 
that does not follow FPG and ships the initscript not in a separated 
package )


Now take me through the next steps when you chose to use that legacy 
sysv initscript instead of the shipped unit that came with the parent 
package and ensured that usage across updates/updates of the both the 
parent and sub package...


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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Mateusz Marzantowicz]

On 22.07.2013 15:38, Matthew Miller wrote:
>
> I've been involved to some small degree with Fedora since the beginning.
> This is a project and a Linux distribution which I love, and which I know
> everyone reading this also cares about deeply. We don't want to break what
> is successful and works.
>
>
>   But...
>   ---
>   * We need to be more than that
>   * Not widely used by RHEL users
Because it lacks reliability of RHEL. This needs to be enhanced.
>   * Not so great for building on...
Because it lacks high quality developer's documentation for all this new
pieces of software that it contains not to mention that this pieces are
swapped in and out too often.
>   * Including Red Hat's own stuff
>   * We're not seen as relevant...
>   * Let alone exciting
>
> Whenever I go to a tech meetup or talk to someone from a new startup
> company, their developers are inevitably using a different (usually
> proprietary) desktop OS, plus a non-Fedora distribution on their code. We're
> being left behind and left out. It doesn't matter how theoretically great we
> are if we end up with no users.
>
>
>   The Idea
>   ---
>   Focus core distro as platform, include layers of modular enabling
>   technologies, and provide room for special interest groups to create
>   solutions within the Fedora circle.
I think it's good approach for OS development to stay focused on rock
solid "core" that is reliable and doesn't break. Then all other rings
mentioned below in your proposal are easier to manage and could
sometimes break in some way. But "core" does never break form F(n) to
F(n+1). Sadly I encounter lot of regressions in Fedora that I don't in
other distros. If something works in one version of F it should not
break in the next one.

> So there we have it. Comments and discussion,  please!
>

I think it's one of the most reasonable proposals since decade that
occurred to Fedora.


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

Re: F20 System Wide Change: No Default Sendmail

[Robert Nichols]

On 07/22/2013 11:36 AM, Lennart Poettering wrote:

 I am pretty sure that most of the stuff we currently mail
(like the log output of cron jobs) simply makes no sense as mail, and
should much rather be treated exactly like all other log output. There's
nothing special really about cron that would make it so much better
suitable for sending out its logs per mail, rather then just log them.


How many megabytes can the log system reasonably accept in a single message?
The output from a cron job can be a lot more than what anyone would
consider to be a reasonable log message.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.

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

Re: [AutoQA] #439: depcheck crashes almost every time post fc17 (was: depcheck crashes almost every time on fc19)

[AutoQA]

#439: depcheck crashes almost every time post fc17
+---
 Reporter:  tflink  |   Owner:
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:  Depcheck
Component:  tests   |  Resolution:
 Keywords:  |  Blocked By:
 Blocking:  |
+---

Comment (by tflink):

 I think that the config changed fixed this. I cloned a depcheck job after
 updating autoqa-stg01 and the job passed this time!
 * [http://autoqa-stg.fedoraproject.org/results/240338-debug_user/ before
 fix]
 * [http://autoqa-stg.fedoraproject.org/results/240362-debug_user/ after
 fix]

 I'm going to leave the fix in stg for a while to make sure it stays
 working before pushing to git

 {{{
 diff --git a/tests/depcheck/depcheck_lib.py
 b/tests/depcheck/depcheck_lib.py
 index aedda8a..e600323 100644
 --- a/tests/depcheck/depcheck_lib.py
 +++ b/tests/depcheck/depcheck_lib.py
 @@ -132,6 +132,7 @@ def do_mash(pkgdir, arches, distname=None):
  dist = mash.config.MashDistroConfig()
  parser = RawConfigParser()
  mash_conf = '''[%s]
 +output_subdir = %s
  rpm_path = %s
  strict_keys = False
  multilib = True
 @@ -143,7 +144,7 @@ delta = False
  source = False
  arches = %s
  keys =
 -''' % (distname, pkgdir, arches)
 +''' % (distname, distname, pkgdir, arches)
  parser.readfp(StringIO.StringIO(mash_conf))
  dist.populate(parser, distname, conf)
  conf.distros.append(dist)
 }}}

-- 
Ticket URL: 
AutoQA 
Automated QA project
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Jóhann B. Guðmundsson]

On 07/22/2013 08:04 PM, Chris Adams wrote:

Once upon a time, "Jóhann B. Guðmundsson"  said:

On 07/22/2013 06:13 PM, Eric Smith wrote:

On Mon, Jul 22, 2013 at 10:52 AM, "Jóhann B. Guðmundsson"
 wrote:

   No one in their right mind runs any
rapid development distribution (not just Fedora) on critical
infrastructure.

That's your opinion and I'm sure many in the server sub-community
disagree with that statement.

It is the opinion of many professional system adminstrators.


Which with that statement of his especially dismiss a whole sub 
community of us.


Well good for them many professional system adminstrators.



I have had no problem deploying Fedora and using Fedora in critical
infrastructural in similar fashion as Andy wrote on his blog [1]

Creating throw-away instances and replacing them every 6 months


13months be more accurate at least I myself have never gone 6 months nor 
have recommended it.



  may be
okay for the rapid-development web designers, but most real system
adminstrators have more than enough work to do than to re-test their
application stack for new deployments every 6 months.  I build servers
to last for years so that I don't have to touch them again for a long
time.



As do I on daily bases and have for years I have also designed and 
deployed agile infrastructure myself and where asked to .


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

Re: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Toshio Kuratomi]

On Mon, Jul 22, 2013 at 12:33 PM, "Jóhann B. Guðmundsson"
 wrote:
> On 07/22/2013 05:53 PM, Toshio Kuratomi wrote:
>>
>> On Mon, Jul 22, 2013 at 04:47:12PM +, "Jóhann B. Guðmundsson" wrote:
>>>
>>> On 07/22/2013 04:34 PM, Toshio Kuratomi wrote:

 This was actually not the rationale.  The rationale was that it wasn't
 harmful to Fedora and so if individual maintainers felt that it was
 something that they wanted to ship they could.
>>>
>>> Did the FPC even bother to test what they had approved in practices?
>>> ( Do they in general? )
>>>
>>> Have you tried installing an legacy sysv initscript file and using
>>> after it has been replaced with a native systemd unit.
>>>
>> The sysv initscripts subpackages are not for use with systemd.  They are
>> for
>> use at places that use systemv init scripts.
>
>
> So is it safe for me to assume what you are getting at here to use with
> other init system than systemd right?
>
> If that is the case look at those what <30 components ship legacy sysv
> initscript along side their native systemd unit counterpart and tell me if
> you can deliver bootable Fedora using either sysv or upstart from those
> components.
>
> Needless to say that reasoning/arguments does not hold water..
>
If by does not hold water, you mean fails to convince you, then that's
fine.  If by fails to hold water you mean, does not have any validity
then I'm afraid you're wrong.  As I said, we saw no reason to ban the
scripts as they are not causing harm.  If maintainers want to ship
them because they perceive them to be useful to people who are not
running systemd then we did not want to stand in their way.  If you
want to argue about whether they are useful or not, take that portion
up with the maintainers of the individual packages.  If you have a
case of harm done by having the subpackages available, then that could
go to the FPC.

>
>>   When the guidelines were
>> initially written, having both installed was tested and they didn't cause
>> problems for systemd (although having both installed and still using
>> systemd
>> was seen as not the use case for having the subpackages).  Has something
>> changed in the systemd code since then that changes that equation?
>>
>
> No and this has nothing to do with systemd.
>
> Again try to use what you approved and are so reluctant to remove and or
> change.
>
> Install a sub package containing a legacy sysv initscript and try to replace
> that legacy sysv initscript with the unit file it has been replaced with and
> remember perform update/upgrades on the components at the same time, then
> tell me if you still think we should be shipping legacy sysv initscripts
> once they have been migrated instead of dropping them to avoid confusion and
> crappy user experience for everybody that try to think they can still (
> easily ) use it.
>
> And there is no need for you to reply to this response on this thread until
> you have done the above because you will not understand what I'm getting at
> until you try this for yourself.
>
Well, I did what you asked and I don't know what you are getting at.
So I suppose either your instructions were unclear or you just wanted
me to see that the FPC subpackage guidelines work as designed.

So, thanks!
-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Billy Crook]

On Mon, Jul 22, 2013 at 11:41 AM, Lennart Poettering
 wrote:
> On Fri, 19.07.13 13:17, Billy Crook (billycr...@gmail.com) wrote:
>> Sendmail stays in Default unless there is compelling reason to switch to
>> postfix, exim, meta1, etc.  Those users who wish to remove it are welcome
>> to do so.  Nobody is stopping them. The default configuration of sendmail
>> poses no problem to users who are unaware of it.
>
> Not true. I eats my cron logs and other stuff and I have no way to get
> the stuff out of it again with the core install...

If that's not hyperbole, then please clarify what "eats" refers to.
Or just take the 30 seconds or so to setup the MTA correctly, and all
of that stuff will be waiting for you in your inbox.  If you don't
want it mixed with human-originated mail, as some have complained,
then use filters to auto sort your mail.


>> Please voice yourself at meetings in #fedora-devel if this is important to
>> you.
>
> Yes, please, post a lot of "+1" messages. They contribute so positively
> (I mean, literally!) to any discussion. "+1" messages are really good
> for making a point as they contain so much additional arguments nobody
> has heard or read before. It's almost as constructive posting "+1"s, as
> it is posting sarcastic comments about their pointlessness...

There's not much else to do when it seems a lot of otherwise very
intelligent people still don't get it.  I'm certain that you are all
aware of how useful an MTA can be.  Choosing to cut it off rather than
properly configuring it, is rather un-fedora-like.  Why not remove
ipv6 support, since gosh it's hard too and who configures it?  And it
doesn't work for most people without explicit configuration.

Removing it (even just from the Default install) is wrong.


On Mon, Jul 22, 2013 at 12:28 PM, Matthew Miller
 wrote:
> On Mon, Jul 22, 2013 at 06:53:24PM +0200, Nicolas Mailhot wrote:
>> What makes cron and smtpd work well together is that they both perform
>> async background computing. And many cron messages are not "logs" they're
>> notifications of an event the cron is polling for, or submission of job
>> results.
>
> Honest, non-loaded question here. Do you really find them default cron
> output mode helpful? You suggested earlier that I dislike cron's e-mail
> output, and while I hadn't brought up likes or dislikes before, I really
> don't find it so great. To me, it just fills up my mailbox with:
>
>Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
>Jul 02 AnacronAnacron job 'cron.daily' on bigcomputer.home.
...
>Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
>
> If I did want e-mail output -- which I used to, before I had proper alerting
> set up, so as I mentioned before I totally recognize that use case -- I
> really would like it with a meaningful subject line, which means even when
> running out of cron, the jobs should actually call sendmail or /usr/bin/mail
> directly with pretty-formatted output. (And thus, have an explicit
> dependency on an MTA, and also basically have the expectation that they're
> running on a system which will be properly configured for its environment,
> however that happens.)

If you are getting a message from a cronjob, it is a pretty good
indicator that something went wrong, and you need to take action to
correct it.  So yes.  It's pretty important.Depending on cronjobs
to send notifications on their own failures, is poor design because if
they have failed, they could easily fail to notify.  This is why
cron's (albeit ugly) notifications when a job turns up stdout/err, are
valuable.


On Mon, Jul 22, 2013 at 1:58 PM, Nicolas Mailhot
 wrote:
> I do not
> think cron jobs that output something every time they are run just in case
> are nice.

I agree.  Those are usually, crappy cronjobs and should be fixed to
work like most unix tools, and output only on failure.

> I do not think the way we let systems install without a configured smtp
> backend is good. If cron mails were actually pushed by default the bad
> crons would be fixed before doing any real damage. A lot of the problems
> people complain of here are the direct product of not configuring the smtp
> backend a install time for years.

EXACTLY.  Improving the INSTALLER and firstlogin experience is what is
needed here, NOT removing MTA.

> I do not think the default cron message envelope is any good. It does not
> make enough effort to identify the system and cron job which is failing,
> and is not localized.

This is another area to improve.  Again NOT removing MTA, but using it smarter.

> I do think the only widely deployed vendor-agnostic remote messaging
> infrastructure is the mail infrastructure. All the other solutions require
> always-on receiving nodes, that end-users can not afford.
> https://admin.fedoraproject.org/mailman/listinfo/devel

Mail has its faults, but is the best option that is universally
available.  Let's build upon it rather than abandoning it.

i.e.: If mes

Re: F20 System Wide Change: Web Assets

[Adam Williamson]

On Mon, 2013-07-22 at 15:23 +0200, Florian Weimer wrote:
> On 07/22/2013 12:31 PM, T.C. Hollingsworth wrote:
> > On Mon, Jul 22, 2013, Florian Weimer  wrote:
> >> Can we please use a different name, like "webdata"?  The term "asset" seems
> >> to scare some people.
> >
> > Huh?  It's a pretty common industry term for "static bits used as
> > dependencies for websites". I've never heard of anyone being scared
> > of it.
> 
> The term has a completely different meaning in the fields of law and 
> accounting.

Fortunately we're making an operating system, not prosecuting a case or
auditing anyone's accounts, so that does not seem to present a problem.
-- 
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: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Chris Adams]

Once upon a time, "Jóhann B. Guðmundsson"  said:
> On 07/22/2013 06:13 PM, Eric Smith wrote:
> >On Mon, Jul 22, 2013 at 10:52 AM, "Jóhann B. Guðmundsson"
> > wrote:
> >>On 07/22/2013 04:41 PM, Stephen Gallagher wrote:
> >>>They chose to use a _downstream_ distribution. RHEL *is* Fedora, it's
> >>>just a Fedora that's been hardened and held to a certain level of
> >>>ABI/API compatibility.
> >>Which is my point exactly instead of helping increasing the overall quality
> >>of Fedora the infrastructure decide to run to another distribution.
> >>
> >>RHEL != Fedora
> >But it's not an objective of Fedora to have long-term-stable releases
> >suitable for running servers!
> 
> Says who?

Says history.  Fedora extended-support releases were tried and failed.

> >   No one in their right mind runs any
> >rapid development distribution (not just Fedora) on critical
> >infrastructure.
> 
> That's your opinion and I'm sure many in the server sub-community
> disagree with that statement.

It is the opinion of many professional system adminstrators.

> I have had no problem deploying Fedora and using Fedora in critical
> infrastructural in similar fashion as Andy wrote on his blog [1]

Creating throw-away instances and replacing them every 6 months may be
okay for the rapid-development web designers, but most real system
adminstrators have more than enough work to do than to re-test their
application stack for new deployments every 6 months.  I build servers
to last for years so that I don't have to touch them again for a long
time.

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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Jóhann B. Guðmundsson]

On 07/22/2013 07:59 PM, Chris Adams wrote:

Once upon a time, "Jóhann B. Guðmundsson"  said:

On 07/22/2013 06:52 PM, Chris Adams wrote:

Once upon a time, "Jóhann B. Guðmundsson"  said:

On 07/22/2013 03:38 PM, Matthew Miller wrote:

On Mon, Jul 22, 2013 at 02:28:52PM +, "Jóhann B. Guðmundsson" wrote:

Should be made less RHEL we want people to use Fedora not RHEL

Candidly, we want people to use both.

We being you and the rest of the Red Hat's employees working in the
project?

"We" being Fedora.

Well I'm pretty sure your "We" there is not representive for the
whole Fedora community...

I'm pretty sure yours is not representative either.  Now we both have
claims that can't be backed up.

You seem to have some kind of issue with Red Hat and its employees.

So me having my own opinions which does not align with Red Hat has
now become an issue with Red Hat and it's employees.

I do not (nor have I ever) work for Red Hat.


I never said you did




Last time I checked this project still allowed freedom of speech.

There is nothing constructive in your recurring attacks against Red Hat.
They don't do anything to further Fedora, so they don't belong here.


Make it clear to me how I was attacking him by responding to his claim?




  I
don't know (or really care) why, but please stop throwing rocks at them
on the Fedora mailing lists.


He states "Candidly, we want people to use both."

I have absolutely no interest in our users base being using Fedora +
RHEL and us our community work being called RHEL test bed users in
the process.

I'm only interesting in our userbase using Fedora, Red Hat can
increase their contributor base by simply hiring them we do not...

Red Hat is the primary sponsor of the Fedora Project,


Yes they are as sponsor and?


and they base RHEL
on Fedora's development.


Irrelevant that's their chose


One of the Fedora goals is "First", which
brings rapid development.


We have not lived up to that foundation for quite some time.


   That level of development is inherently not
appropriate for some types of installations, especially infrastructure
servers.


That's arguable


  In those cases, it makes more sense for people who like the
environment of Fedora (rpm, yum, etc.) to use a slower-changing platform
like RHEL (or the community rebuilds like CentOS).


Yes if you require long term APIs and ABIs stability then using RHEL is 
best choice out there.




Some people tried to do a Fedora extended-life release, and there just
wasn't sufficient community support to keep it functional.  Fedora can't
try to be all things to all people;


I disagree

We have long outcrown the "defaults" as a project so Fedora should not 
try to be anything other then the platform for sub-communities to build 
and thrive or die upon and as such it is all things to all people where 
it matters.


JBG
--
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 Sun, 2013-07-21 at 20:46 -0400, Ding Yi Chen wrote:
> 
> - Original Message -
> > On Thu, 2013-07-18 at 21:37 -0400, Ding Yi Chen wrote:
> > 
> > > > 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?
> > 
> > I doubt Jesse would say that, and if he did, he'd be wrong: it's a
> 
> He did, see this and the thread Regarding install options:
> http://www.redhat.com/archives/rhl-devel-list/2008-October/msg01277.html

Um. You could have qualified your statement with 'in 2008'. That was the
old anaconda UI. We have been using a new one for two releases.
-- 
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: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Chris Adams]

Once upon a time, "Jóhann B. Guðmundsson"  said:
> On 07/22/2013 06:52 PM, Chris Adams wrote:
> >Once upon a time, "Jóhann B. Guðmundsson"  said:
> >>On 07/22/2013 03:38 PM, Matthew Miller wrote:
> >>>On Mon, Jul 22, 2013 at 02:28:52PM +, "Jóhann B. Guðmundsson" wrote:
> >>Should be made less RHEL we want people to use Fedora not RHEL
> >Candidly, we want people to use both.
> We being you and the rest of the Red Hat's employees working in the
> project?
> >>>"We" being Fedora.
> >>Well I'm pretty sure your "We" there is not representive for the
> >>whole Fedora community...
> >I'm pretty sure yours is not representative either.  Now we both have
> >claims that can't be backed up.
> >
> >You seem to have some kind of issue with Red Hat and its employees.
> 
> So me having my own opinions which does not align with Red Hat has
> now become an issue with Red Hat and it's employees.

I do not (nor have I ever) work for Red Hat.

> Last time I checked this project still allowed freedom of speech.

There is nothing constructive in your recurring attacks against Red Hat.
They don't do anything to further Fedora, so they don't belong here.

> >  I
> >don't know (or really care) why, but please stop throwing rocks at them
> >on the Fedora mailing lists.
> >
> 
> He states "Candidly, we want people to use both."
> 
> I have absolutely no interest in our users base being using Fedora +
> RHEL and us our community work being called RHEL test bed users in
> the process.
> 
> I'm only interesting in our userbase using Fedora, Red Hat can
> increase their contributor base by simply hiring them we do not...

Red Hat is the primary sponsor of the Fedora Project, and they base RHEL
on Fedora's development.  One of the Fedora goals is "First", which
brings rapid development.  That level of development is inherently not
appropriate for some types of installations, especially infrastructure
servers.  In those cases, it makes more sense for people who like the
environment of Fedora (rpm, yum, etc.) to use a slower-changing platform
like RHEL (or the community rebuilds like CentOS).

Some people tried to do a Fedora extended-life release, and there just
wasn't sufficient community support to keep it functional.  Fedora can't
try to be all things to all people; in cases where people like Fedora
but it can't meet their needs, pointing them to RHEL/CentOS, and trying
to help those projects, makes sense (as opposed to telling them to go
download some other distribution).

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

Re: [AutoQA] #439: depcheck crashes almost every time on fc19

[AutoQA]

#439: depcheck crashes almost every time on fc19
+---
 Reporter:  tflink  |   Owner:
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:  Depcheck
Component:  tests   |  Resolution:
 Keywords:  |  Blocked By:
 Blocking:  |
+---

Comment (by tflink):

 I started digging into this more when I saw the same crash on the f18
 clients. I think it is due a change in mash that is looking for config
 values which we weren't setting:
 * [https://bugzilla.redhat.com/show_bug.cgi?id=668326 rhbz 668326]
 *
 
[https://git.fedorahosted.org/cgit/mash/commit/mash/__init__.py?id=e6579e356e4e00dd52c2cc4e01b0f2b0387d0779
 mash change]

 The fix appears to be simple (set output_subdir in mash config for
 do_mash() in depcheck_lib.py), I'm going to test a bit more before pushing
 a fix

-- 
Ticket URL: 
AutoQA 
Automated QA project
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: F20 System Wide Change: No Default Sendmail

[Adam Williamson]

On Mon, 2013-07-22 at 21:10 +0200, Nicolas Mailhot wrote:
> Le Lun 22 juillet 2013 20:23, Adam Williamson a écrit :
> 
> > Just before this one gets any worse: it was Nicolas Mailhot who started
> > talking about banks sending email for some reason, not Miloslav.
> 
> Please do not attribute me what I didn't write. I didn't bring banks in
> the discussion.

Oh, sorry, that's right - you cited 'Google and Amazon', and someone
extended the example later.
-- 
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: Web Assets

[Robert Marcano]

On 07/22/2013 11:11 AM, Nicolas Mailhot wrote:


Le Lun 22 juillet 2013 17:07, Robert Marcano a écrit :


Fonts has licenses, some of them require the license to be shown or the
copyright displayed, some fonts has the copyright added to their
metadata, I don't find for example that gnu-free-serif-fonts says on
it's metadata that is GPL+3 with exceptions.


I'd say that when a font requires some communication of licensing
downstream, but forgets to put its own license in the font metadata,
that's an upstream problem. Upstream can not complain Fedora didn't work
hard enough about something it didn't do itself.


I disagree, they added the license file to the downloaded package. If 
you extend that way of thinking, then if executables doesn't have 
license metadata it isn't my problem that I publish them on my web server




It's another thing when the licensing actually prohibits distribution, but
we don't have those in Fedora, and people that deploy such fonts in Fedora
can write deny apache rules themselves (though providing a sample of tuch
a rule would be good)


The real problem with publishing things is that if I distribute binaries 
of many things I must follow the license, some say I need to distribute 
sources, some say that I need to distribute a copy of the license, etc. 
Making files downloadable by default adds to the distributor more work 
(legal) because they must comply with their licenses. So if I put an 
open service of an Apache licensed web application, I will start 
distributing fonts with other licenses without ever noticing, for 
example GPL+3 (nothing against any license, only examples of the things 
people should care when distributing free/open licensed code/assets)




Regards,



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

Re: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Jóhann B. Guðmundsson]

On 07/22/2013 06:13 PM, Eric Smith wrote:

On Mon, Jul 22, 2013 at 10:52 AM, "Jóhann B. Guðmundsson"
 wrote:

On 07/22/2013 04:41 PM, Stephen Gallagher wrote:

They chose to use a _downstream_ distribution. RHEL *is* Fedora, it's
just a Fedora that's been hardened and held to a certain level of
ABI/API compatibility.

Which is my point exactly instead of helping increasing the overall quality
of Fedora the infrastructure decide to run to another distribution.

RHEL != Fedora

But it's not an objective of Fedora to have long-term-stable releases
suitable for running servers!


Says who?


   No one in their right mind runs any
rapid development distribution (not just Fedora) on critical
infrastructure.


That's your opinion and I'm sure many in the server sub-community 
disagree with that statement.


I have had no problem deploying Fedora and using Fedora in critical 
infrastructural in similar fashion as Andy wrote on his blog [1]




If you think Fedora should somehow transition into being a good
distribution for critical infrastructure, you'll have to propose some
radical changes to Fedora to make that happen.



I have already done so that request I filed a while back and is buried 
in the locked board tracker


1.http://groveronline.com/2013/06/fedora-for-servers/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-POE-Component-SimpleLog] Perl 5.18 rebuild

[Petr Pisar]

commit feb12f3eb5da6a71e9fecf2405d40e76e6a854f8
Author: Petr Písař 
Date:   Mon Jul 22 21:54:11 2013 +0200

Perl 5.18 rebuild

 perl-POE-Component-SimpleLog.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE-Component-SimpleLog.spec 
b/perl-POE-Component-SimpleLog.spec
index 910d494..e12562a 100644
--- a/perl-POE-Component-SimpleLog.spec
+++ b/perl-POE-Component-SimpleLog.spec
@@ -1,6 +1,6 @@
 Name:   perl-POE-Component-SimpleLog
 Version:1.05
-Release:12%{?dist}
+Release:13%{?dist}
 Summary:A simple logging system for POE 
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -54,6 +54,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 1.05-13
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 1.05-12
 - 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-Mail-IMAPClient] Perl 5.18 rebuild

[Petr Pisar]

commit f0da96ed198f3f835a1628ff836099cb854e7eb6
Author: Petr Písař 
Date:   Mon Jul 22 21:53:47 2013 +0200

Perl 5.18 rebuild

 perl-Mail-IMAPClient.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 44a68ad..bc1c436 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.33
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 3.33-2
+- Perl 5.18 rebuild
+
 * Tue May 21 2013 Nick Bebout  - 3.33-1
 - Upgrade to 3.33
 
--
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-Razor-Agent] Perl 5.18 rebuild

[Petr Pisar]

commit c233d863d79520f779d9b384c2e14d3ea5269880
Author: Petr Písař 
Date:   Mon Jul 22 21:53:47 2013 +0200

Perl 5.18 rebuild

 perl-Razor-Agent.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Razor-Agent.spec b/perl-Razor-Agent.spec
index 0222654..22a0a0c 100644
--- a/perl-Razor-Agent.spec
+++ b/perl-Razor-Agent.spec
@@ -4,7 +4,7 @@
 Summary:   Use a Razor catalogue server to filter spam messages
 Name:  perl-Razor-Agent
 Version:   2.85
-Release:   13%{?dist}
+Release:   14%{?dist}
 License:   Artistic 2.0
 Group: Applications/Internet
 URL:   http://razor.sourceforge.net/
@@ -76,6 +76,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man*/*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 2.85-14
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 2.85-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-POE-Test-Loops] Perl 5.18 rebuild

[Petr Pisar]

commit f984eb5dfa5af4c99c81f09dee0dacac03073389
Author: Petr Písař 
Date:   Mon Jul 22 21:42:16 2013 +0200

Perl 5.18 rebuild

 perl-POE-Test-Loops.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE-Test-Loops.spec b/perl-POE-Test-Loops.spec
index 8e14b9b..34fc56e 100644
--- a/perl-POE-Test-Loops.spec
+++ b/perl-POE-Test-Loops.spec
@@ -1,7 +1,7 @@
 Name:   perl-POE-Test-Loops
 Summary:Reusable tests for POE::Loop authors
 Version:1.351
-Release:4%{?dist}
+Release:5%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/R/RC/RCAPUTO/POE-Test-Loops-%{version}.tar.gz
 
@@ -92,6 +92,9 @@ make test
 %{_mandir}/man1/poe-gen-tests.1.gz
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 1.351-5
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 1.351-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Jóhann B. Guðmundsson]

On 07/22/2013 06:52 PM, Chris Adams wrote:

Once upon a time, "Jóhann B. Guðmundsson"  said:

On 07/22/2013 03:38 PM, Matthew Miller wrote:

On Mon, Jul 22, 2013 at 02:28:52PM +, "Jóhann B. Guðmundsson" wrote:

Should be made less RHEL we want people to use Fedora not RHEL

Candidly, we want people to use both.

We being you and the rest of the Red Hat's employees working in the
project?

"We" being Fedora.

Well I'm pretty sure your "We" there is not representive for the
whole Fedora community...

I'm pretty sure yours is not representative either.  Now we both have
claims that can't be backed up.

You seem to have some kind of issue with Red Hat and its employees.


So me having my own opinions which does not align with Red Hat has now 
become an issue with Red Hat and it's employees.


Last time I checked this project still allowed freedom of speech.


  I
don't know (or really care) why, but please stop throwing rocks at them
on the Fedora mailing lists.



He states "Candidly, we want people to use both."

I have absolutely no interest in our users base being using Fedora + 
RHEL and us our community work being called RHEL test bed users in the 
process.


I'm only interesting in our userbase using Fedora, Red Hat can increase 
their contributor base by simply hiring them we do not...


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

[perl-IO-Socket-SSL] Perl 5.18 rebuild

[Petr Pisar]

commit e7382a4aba56fee7b7de3f5347a0342de69a0e58
Author: Petr Písař 
Date:   Mon Jul 22 21:52:10 2013 +0200

Perl 5.18 rebuild

 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 12044dd..62a9487 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
+* Mon Jul 22 2013 Petr Pisar  - 1.95.3-2
+- Perl 5.18 rebuild
+
 * Mon Jul 22 2013 Paul Howarth  - 1.95.3-1
 - Update to 1.953
   - Precedence fixes for IO::Socket::SSL::Utils (CPAN RT#87052)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F20 System Wide Change: No Default Syslog

[Lennart Poettering]

On Fri, 19.07.13 20:12, Miloslav Trmač (m...@volny.cz) wrote:

> On Wed, Jul 17, 2013 at 2:20 PM, "Jóhann B. Guðmundsson"
>  wrote:
> > On 07/17/2013 12:05 PM, Richard W.M. Jones wrote:
> >>
> >> On Wed, Jul 17, 2013 at 09:21:39AM +, "Jóhann B. Guðmundsson" wrote:
> >>>
> >>> On 07/17/2013 12:58 AM, Ding Yi Chen wrote:
> 
>  You still have not addressed the third party programs and scripts
>  that monitor /var/log/messages
> >>>
> >>> We honestly cant keep progress and cleanup in the distribution back
> >>> out of fear of breaking some third party programs.
> >>
> >> Irrespective of whether journald is good or bad, this is a dumb
> >> argument.
> >
> > Dumb I see so you have established a time frame for us how long we should
> > hold back progress  in the project and or you have devised an implementation
> > plan on features and cleanups with a rate that a third party can keep up
> > with in the distribution, maybe even chosen which third parties we wait for
> > and which we dont?
> 
> Progress does not that frequently depend on removing older
> functionality.  Specifically in this case, removing rsyslog does not
> make journal in any way better.

It certainly makes *Fedora* better though, by making the core less
redundant and decreasing its footprint.

> The same thinking applies to individual sets of APIs and other
> interfaces: write the new implementation, write a compatibility layer
> for old users that replaces the old implementation, write a test suite
> of the compatibility layer (... or just use the test suite of the
> implementation thing that you should have already), keep the
> compatibility layer shipped and running and forget about the
> transition.  Writing a compatibility layer is roughly the same kind of
> work as porting applications, so with any interface that has at least
> a handful of users a single compatibility layer should in fact be less
> work.  With this approach, it's not at all obvious that one shouldn't
> aim for a backward compatibility 100 years back[1][2].
> Mirek

Note that the journal provides this compatbility layer to a fairly
comprehensive degree. We speak the syslog protocol natively so that log
clients don't have to be updated. We provide a pretty much perfect
identical output to /var/log/messages as default from journalctl. We
make it easy to to get the exact files /var/log/messages by forwarding
everything to syslog instantly if it is running.

However, we also go one step further: eventually we remove the old
implementation from the default installation. That's a very gentle push
only, because the old stuff is trivially easy to get back, simply by
installing rsyslog again.

Lennart

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

[perl-Mail-SPF] Perl 5.18 rebuild

[Petr Pisar]

commit 0d6b722c92559d7ff3e809ceaf83196d4b43bb5d
Author: Petr Písař 
Date:   Mon Jul 22 21:36:51 2013 +0200

Perl 5.18 rebuild

 perl-Mail-SPF.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Mail-SPF.spec b/perl-Mail-SPF.spec
index b6b2718..b5c01d1 100644
--- a/perl-Mail-SPF.spec
+++ b/perl-Mail-SPF.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-SPF
 Version:2.9.0
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Object-oriented implementation of Sender Policy Framework
 License:BSD
 Group:  Development/Libraries
@@ -69,6 +69,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 2.9.0-2
+- Perl 5.18 rebuild
+
 * Mon Jul 22 2013 Paul Howarth  - 2.9.0-1
 - Update to 2.9.0
   - Default to querying only TXT type RRs
--
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-POE-Component-Client-DNS] Perl 5.18 rebuild

[Petr Pisar]

commit 3ea5b41135b58488f7d1e6a98c515820d226d444
Author: Petr Písař 
Date:   Mon Jul 22 21:35:50 2013 +0200

Perl 5.18 rebuild

 perl-POE-Component-Client-DNS.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE-Component-Client-DNS.spec 
b/perl-POE-Component-Client-DNS.spec
index 86ccd67..64686e1 100644
--- a/perl-POE-Component-Client-DNS.spec
+++ b/perl-POE-Component-Client-DNS.spec
@@ -1,6 +1,6 @@
 Name:   perl-POE-Component-Client-DNS
 Version:1.053
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Non-blocking/concurrent DNS queries using Net::DNS and POE
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/POE-Component-Client-DNS
@@ -55,6 +55,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 1.053-2
+- Perl 5.18 rebuild
+
 * Fri Apr 19 2013 Petr Šabata  - 1.053-1
 - 1.053 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-POE-Filter-Transparent-SMTP] Perl 5.18 rebuild

[Petr Pisar]

commit 5508d301669d6611f240b716e1753c5f148c008e
Author: Petr Písař 
Date:   Mon Jul 22 21:35:50 2013 +0200

Perl 5.18 rebuild

 perl-POE-Filter-Transparent-SMTP.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE-Filter-Transparent-SMTP.spec 
b/perl-POE-Filter-Transparent-SMTP.spec
index c980c63..47e8311 100644
--- a/perl-POE-Filter-Transparent-SMTP.spec
+++ b/perl-POE-Filter-Transparent-SMTP.spec
@@ -1,6 +1,6 @@
 Name:   perl-POE-Filter-Transparent-SMTP
 Version:0.2
-Release:16%{?dist}
+Release:17%{?dist}
 Summary:A POE filter for SMTP
 
 # note license definition in Makefile.PL
@@ -52,6 +52,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 0.2-17
+- Perl 5.18 rebuild
+
 * Sun Feb 17 2013 Yanko Kaneti  - 0.2-16
 - BR: perl(ExtUtils::MakeMaker). Fix bogus changelog date.
 
--
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: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Jóhann B. Guðmundsson]

On 07/22/2013 05:53 PM, Toshio Kuratomi wrote:

On Mon, Jul 22, 2013 at 04:47:12PM +, "Jóhann B. Guðmundsson" wrote:

On 07/22/2013 04:34 PM, Toshio Kuratomi wrote:

This was actually not the rationale.  The rationale was that it wasn't
harmful to Fedora and so if individual maintainers felt that it was
something that they wanted to ship they could.

Did the FPC even bother to test what they had approved in practices?
( Do they in general? )

Have you tried installing an legacy sysv initscript file and using
after it has been replaced with a native systemd unit.


The sysv initscripts subpackages are not for use with systemd.  They are for
use at places that use systemv init scripts.


So is it safe for me to assume what you are getting at here to use with 
other init system than systemd right?


If that is the case look at those what <30 components ship legacy sysv 
initscript along side their native systemd unit counterpart and tell me 
if you can deliver bootable Fedora using either sysv or upstart from 
those components.


Needless to say that reasoning/arguments does not hold water..


  When the guidelines were
initially written, having both installed was tested and they didn't cause
problems for systemd (although having both installed and still using systemd
was seen as not the use case for having the subpackages).  Has something
changed in the systemd code since then that changes that equation?



No and this has nothing to do with systemd.

Again try to use what you approved and are so reluctant to remove and or 
change.


Install a sub package containing a legacy sysv initscript and try to 
replace that legacy sysv initscript with the unit file it has been 
replaced with and remember perform update/upgrades on the components at 
the same time, then tell me if you still think we should be shipping 
legacy sysv initscripts once they have been migrated instead of dropping 
them to avoid confusion and crappy user experience for everybody that 
try to think they can still ( easily ) use it.


And there is no need for you to reply to this response on this thread 
until you have done the above because you will not understand what I'm 
getting at until you try this for yourself.


JBG


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

Re: F20 System Wide Change: No Default Sendmail

[Lennart Poettering]

On Mon, 22.07.13 19:19, Miloslav Trmač (m...@volny.cz) wrote:

> On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering
>  wrote:
> > On Mon, 22.07.13 18:43, Miloslav Trmač (m...@volny.cz) wrote:
> >
> >> On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
> >>  wrote:
> >> > On Fri, 19.07.13 20:22, Miloslav Trmač (m...@volny.cz) wrote:
> >> >
> >> >> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
> >> >>  wrote:
> >> > Where "expected to do" means effectively route it to /dev/null?
> >>
> >> It's actually less similar to /dev/null than log files are - log files
> >> are rotated and deleted, mail stays in the mail boxes until explicitly
> >> deleted (or space runs out).
> >
> > Well, so it's even a DoS... Just find some trigger to generate a lot of
> > mails to root and /var will eventually fill up, even beyond those 10%
> > reserved for root, since well, mail to root is accounted to root...
> 
> My concern about this proposal doesn't actually depend on local
> delivery, it _could_ go to /dev/null by default for all I care.

What a crappy API is that?

> I'll note, however, that "this is a DoS" is rarely a convincing
> argument - the only practical way to combat a DoS is to impose some
> kind of limit, which is just a DoS of a different kind.  You get to
> choose _what_ kinds of DoS your computer will be subject to, but with
> finite CPU power and storage you can't avoid DoS situations.

The point I am trying to make is that if you have something that is
vulnerable to a DoS attack you need to have a strategy to handle
that. You need to keep the attack local, isolated as much as you can
from the rest of the system and other clients. A strategy of "hey, yeah,
let's queue this all up and allow unprivileged clients to bring down the
entire system by easily flooding /var" is a bad strategy, an
embarrassingly bad one. It's a DoS that is the opposite of local.

> And, philosophically, silently losing data is generally much worse
> than requiring manual intervention for the system to run when space
> runs out.  (Not that the mails we sent by default are _that_ valuable,
> though.)
> Mirek

If we drop data we definitely always need to keep track of that and
account it, no doubt. (journald does keep track of messages dropped via
per-service/per-priority ratelimit, and it will tell you how far back
history in the logs reach)

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 Sendmail

[Nicolas Mailhot]

Le Lun 22 juillet 2013 20:52, Lennart Poettering a écrit :

> This is not a valid argument. We cannot keep extending the core all the
> time by adding more and more redundant components to them, just because
> we believe this will cause APIs to be tested.

No one is asking to extend the core. You are asking to redefine it that's
not the same.

> Also, what kind of a picture does this paint of the Fedora project
> anyway? Only stuff we install by default matters and is tested?

Not configuring what we install does not paint a good image of the
project. OTOH, the MTAs themselves are several orders of magnitude more
robust than all the other bits we install (including, right now, systemd).
So the picture is clearly mixed.

-- 
Nicolas Mailhot

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

Re: F20 System Wide Change: No Default Sendmail

[Nicolas Mailhot]

Le Lun 22 juillet 2013 20:23, Adam Williamson a écrit :

> Just before this one gets any worse: it was Nicolas Mailhot who started
> talking about banks sending email for some reason, not Miloslav.

Please do not attribute me what I didn't write. I didn't bring banks in
the discussion.

-- 
Nicolas Mailhot

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

Re: F20 System Wide Change: No Default Sendmail

[Nicolas Mailhot]

Le Lun 22 juillet 2013 20:40, Lennart Poettering a écrit :

> I find it quite amazing that you actually use multiple different MUAs in
> parallel. I mean, most people stick to one MUA usually, maybe two. But
> you make it sound as if you need to access your emails through 5 or 10
> or so, so that it is really worth making this kind of low-level
> configuration change.

Well, if the various MUAs shipped in Fedora didn't periodically suffer
from bugs, I wouldn't need to switch regularly (actually since I installed
squirrelmail I don't need switching anymore. It just works, and does not
think duplicating every mail in a private store to simulate pop3 behaviour
is a requisite. So I just point it to the system maildir)

> It's also hardly something we can suggest people to actively do. User
> credentials should not leak into the system like that. If two users send
> emails on the same host, then the SMTP delivery needs to provide proper
> authentication to the mail gateway attributing the individual mails to
> the right user.

I didn't write anything else. What I did write is that, at this point in
time, it's probably easier to add the 'send as different used depending on
the system user' to the central MTA (and make smtp an actual system
service) than to try to fix all the MUAs Fedora ships.

-- 
Nicolas Mailhot

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

[perl-Gtk2-Ex-Dialogs] Perl 5.18 rebuild

[Petr Pisar]

commit 5f9e05c234a64f327da28785023b55561f3284e5
Author: Petr Písař 
Date:   Mon Jul 22 21:00:11 2013 +0200

Perl 5.18 rebuild

 perl-Gtk2-Ex-Dialogs.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Gtk2-Ex-Dialogs.spec b/perl-Gtk2-Ex-Dialogs.spec
index 02b47bc..998d2cd 100644
--- a/perl-Gtk2-Ex-Dialogs.spec
+++ b/perl-Gtk2-Ex-Dialogs.spec
@@ -1,6 +1,6 @@
 Name:   perl-Gtk2-Ex-Dialogs
 Version:0.11
-Release:15%{?dist}
+Release:16%{?dist}
 Summary:Useful tools for GNOME2/GTK2 Perl GUI design
 License:LGPLv2+
 Group:  Development/Libraries
@@ -55,6 +55,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 0.11-16
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 0.11-15
 - 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-Test-POE-Server-TCP] Perl 5.18 rebuild

[Petr Pisar]

commit 0b4e9f3bf59b4936530f422dbcb4b17a24949b82
Author: Petr Písař 
Date:   Mon Jul 22 21:00:14 2013 +0200

Perl 5.18 rebuild

 perl-Test-POE-Server-TCP.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-POE-Server-TCP.spec b/perl-Test-POE-Server-TCP.spec
index 0ca9fd0..8e2f486 100644
--- a/perl-Test-POE-Server-TCP.spec
+++ b/perl-Test-POE-Server-TCP.spec
@@ -1,6 +1,6 @@
 Name:   perl-Test-POE-Server-TCP
 Version:1.16
-Release:7%{?dist}
+Release:8%{?dist}
 Summary:POE Component providing TCP server services for test cases
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -58,6 +58,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 1.16-8
+- Perl 5.18 rebuild
+
 * Sun Feb 17 2013 Yanko Kaneti  1.16-7
 - BR: perl(ExtUtils::MakeMaker)
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Class-C3-Componentised] Perl 5.18 rebuild

[Petr Pisar]

commit be75cfb150bed202cf62ef805a556ee346690884
Author: Petr Písař 
Date:   Mon Jul 22 21:00:15 2013 +0200

Perl 5.18 rebuild

 perl-Class-C3-Componentised.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Class-C3-Componentised.spec b/perl-Class-C3-Componentised.spec
index 03b284e..cced66e 100644
--- a/perl-Class-C3-Componentised.spec
+++ b/perl-Class-C3-Componentised.spec
@@ -1,6 +1,6 @@
 Name:   perl-Class-C3-Componentised
 Version:1.001000
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:Load mix-ins or components to your C3-based class
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -59,6 +59,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 1.001000-6
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 1.001000-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Gnome2] Perl 5.18 rebuild

[Petr Pisar]

commit 005268c5d1ecb9f8ccf01a2d4dc2a03461159d79
Author: Petr Písař 
Date:   Mon Jul 22 21:00:14 2013 +0200

Perl 5.18 rebuild

 perl-Gnome2.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Gnome2.spec b/perl-Gnome2.spec
index 22a6fdb..c4a98de 100644
--- a/perl-Gnome2.spec
+++ b/perl-Gnome2.spec
@@ -1,6 +1,6 @@
 Name:   perl-Gnome2
 Version:1.042
-Release:14%{?dist}
+Release:15%{?dist}
 Summary:Perl interface to the 2.x series of the GNOME libraries
 License:LGPLv2
 Group:  Development/Libraries
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 1.042-15
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 1.042-14
 - 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-Regexp-Assemble-Compressed] Perl 5.18 rebuild

[Petr Pisar]

commit ce4debf8f8f654e21de0356a4754be633779
Author: Petr Písař 
Date:   Mon Jul 22 21:00:11 2013 +0200

Perl 5.18 rebuild

 perl-Regexp-Assemble-Compressed.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Regexp-Assemble-Compressed.spec 
b/perl-Regexp-Assemble-Compressed.spec
index 1bfa3d7..140e84c 100644
--- a/perl-Regexp-Assemble-Compressed.spec
+++ b/perl-Regexp-Assemble-Compressed.spec
@@ -1,7 +1,7 @@
 Name:   perl-Regexp-Assemble-Compressed
 Summary:Assemble more compressed Regular Expression
 Version:0.02
-Release:2%{?dist}
+Release:3%{?dist}
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Regexp-Assemble-Compressed/
 Source0:
http://www.cpan.org/authors/id/T/TA/TANIGUCHI/Regexp-Assemble-Compressed-%{version}.tar.gz
@@ -49,6 +49,9 @@ make test
 
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 0.02-3
+- Perl 5.18 rebuild
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 0.02-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F20 System Wide Change: No Default Sendmail

[Lennart Poettering]

On Mon, 22.07.13 16:04, Miloslav Trmač (m...@volny.cz) wrote:

> On Sun, Jul 21, 2013 at 9:20 PM, Matthew Miller  wrote:
> > On Sun, Jul 21, 2013 at 04:09:32PM +0200, Reindl Harald wrote:
> >> the problem i see is when things like MTA and rsyslog are
> >> removed from the defualt install many pakcgers will less
> >> care about them in the future nor test how well it works
> >
> > That's a separate issue. MTAs and syslog are going to be needed for many
> > very important use cases for years to come. That doesn't mean we need to
> > install them by default.
> 
> It's not really separate.
> 
> We don't have any canonical developer documentation that says what is
> or isn't a part of the OS, and "good" Linux applications are expected
> to use; we only have traditions, word of mouth, and de-facto
> standards. In this situation, what is or isn't enabled by default and
> shipped by default matters more than saying "are going to be needed
> for years to come" - the actions speak louder than the words.
> 
> Think of these debates as attempts to, after all the years, agree on
> and write down what the traditions and de-facto standards actually
> are.
> Mirek

If you argue from the viewpoint of how universially available an API is
to make it "standard", then I would like to remind you that there are
probably more Ubuntu installations in the world thatn Fedora
installations, and they haven't included any MTA by default in 6 years
or so.

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 Sendmail

[Nicolas Mailhot]

Le Lun 22 juillet 2013 19:28, Matthew Miller a écrit :
> On Mon, Jul 22, 2013 at 06:53:24PM +0200, Nicolas Mailhot wrote:
>> What makes cron and smtpd work well together is that they both perform
>> async background computing. And many cron messages are not "logs"
>> they're
>> notifications of an event the cron is polling for, or submission of job
>> results.
>
> Honest, non-loaded question here. Do you really find them default cron
> output mode helpful?

I think sending all cron output by email is useful, in the sense that it
pushes errors for the user to fix instead of failing silently (or with
another line in the system logs no one will read since they're swamped by
gdm, networkmanager and a few other chatty system services). I do not
think cron jobs that output something every time they are run just in case
are nice.

I do not think the way we let systems install without a configured smtp
backend is good. If cron mails were actually pushed by default the bad
crons would be fixed before doing any real damage. A lot of the problems
people complain of here are the direct product of not configuring the smtp
backend a install time for years.

I do not think the default cron message envelope is any good. It does not
make enough effort to identify the system and cron job which is failing,
and is not localized.

I do think neither the transient GNOME notifications, nor burying events
in logs only root can consult are appropriate except for the most routine
and uninteresting events.

I do not think that for regular output (ie job results, intended
notifications not script crashes) direct cron to smtpd is ideal. The best
path should be
app/cron/script → backend notification center (evaluation of all system
notifications, standard formatting, localization, triaging)
→ (routing)
→ consumer (DE notification center, logs, specialized
apps, human in MUA)

with in many cases routing = smtpd → imap box → remote consumer. There can
be different imap boxes for each human user of the system, for the
operator of the system (operator can be it-knowledgeable nephew,
it-slave-boyfriend, helpdesk or central monitoring/alert system). Some of
them can be consulted via the DE notification GUI, not necessarily by a
MUA (just requires defining how you serialize notifications in mail
attachment, and teaching the notification center to read an imap box and
remove each message when the user confirms he's done with it, and leave it
in the remote mailbox for future processing otherwise)

A lot of notifications do not require immediate action. What they do
require is some action in the future. For those I do want them to hang out
on an imap server till I take care of them, and I definitely do not want
to be only able to see them when I log in on the exact system they
originated from, or only at the notification time.

I do think the only widely deployed vendor-agnostic remote messaging
infrastructure is the mail infrastructure. All the other solutions require
always-on receiving nodes, that end-users can not afford.

I do think the notification infrastructure needs to be able to handle the
results produced by user crontabs, and the entry points need to be simple
enough the crontab user does not have to think about them.

I do think the basic app (something) smtp architecture is sound, even if
it does need some refreshing and formatting cleanup. I do think that
commodisation will result in multiple computing nodes in every home, and
that being able to push notifications to a machine-agnostic store will
prove just as compelling end-user-side as it was in university campuses
when cron was first wed with sendmail.

-- 
Nicolas Mailhot

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

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

[Kyle McMartin]

On Mon, Jul 22, 2013 at 02:54:41PM -0400, Vivek Goyal wrote:
> On Fri, Jul 19, 2013 at 06:08:48PM +0200, Florian Weimer wrote:
> 
> [..]
> > Have you considered a non-cryptographic solution, like a physical
> > presence check to (temporarily) disable Secure Boot so that the
> > kexec restriction no longer applies?  This could be a fallback
> > option if the original plan turns out to be too brittle/complex.
> 
> I think kyle has a patch which will allow disabling secureboot
> restriction if one is on console. I will have to look into details
> and see how can I make use of it in kexec code to relax signature
> restrictions if user is on physical console.
> 

http://pkgs.fedoraproject.org/cgit/kernel.git/tree/devel-sysrq-secure-boot-20130717.patch

It still needs a bit of work for edge cases, but seems to work ok
in some simple VM testing.

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

Re: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Toshio Kuratomi]

On Mon, Jul 22, 2013 at 03:13:28PM +, "Jóhann B. Guðmundsson" wrote:
> On 07/22/2013 02:52 PM, Toshio Kuratomi wrote:
> >On Mon, Jul 22, 2013 at 02:28:52PM +, "Jóhann B. Guðmundsson" wrote:
> >>What better time to move epel out of Fedora since is really not
> >>related to Fedora et all but is strictly for downstream distribution
> >>based upon us to use ( like RHEL and it's clones )
> >>
> >I'm not sure what you think needs to be "moved out of Fedora".  Governance
> >of EPEL is separate.  Packagers are allowed to be independent.  in your
> >previous post you mention the word "infrastructure".  If you're just talking
> >about the fact that epel shares the same koji, bodhi, git, etc with Fedora,
> >I'm not sure what harm those do to us right now and I can see a large amount
> >of benefit in terms of the manpower required to maintain those systems.
> 
> For Epel yes, for RHEL yes for Fedora no
> 
For Fedora, yes as well.  The Fedora Infrastructure team uses EPEL for their
boxes so they'd likely still be the ones who maintained a separate system.
If a separate system took more of their time then that would cut into their
time spent working on Fedora itself.

> >Could you please go into what is troubling you more?
> 
> Reluctant changes and cleanups to components and their spec files and
> our packing guidelines due to them being maintained in Epel and RHEL.
> 
Cleanups and changes sounds like a social problem rather than a technical
one.  I think you'll have this issue as long as the same maintainer is
concerned with both Fedora and EPEL/RHEL.  I mean you mention RHEL and RHEL
already lives in a separate system so it doesn't seem to have helped.

Packaging Guidelines themselves are written for Fedora.  We note where
EPEL/RHEL need something different where applicable.

-Toshio


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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Chris Adams]

Once upon a time, "Jóhann B. Guðmundsson"  said:
> On 07/22/2013 03:38 PM, Matthew Miller wrote:
> >On Mon, Jul 22, 2013 at 02:28:52PM +, "Jóhann B. Guðmundsson" wrote:
> Should be made less RHEL we want people to use Fedora not RHEL
> >>>Candidly, we want people to use both.
> >>We being you and the rest of the Red Hat's employees working in the
> >>project?
> >"We" being Fedora.
> 
> Well I'm pretty sure your "We" there is not representive for the
> whole Fedora community...

I'm pretty sure yours is not representative either.  Now we both have
claims that can't be backed up.

You seem to have some kind of issue with Red Hat and its employees.  I
don't know (or really care) why, but please stop throwing rocks at them
on the Fedora mailing lists.

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

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

[Vivek Goyal]

On Fri, Jul 19, 2013 at 06:08:48PM +0200, Florian Weimer wrote:

[..]
> Have you considered a non-cryptographic solution, like a physical
> presence check to (temporarily) disable Secure Boot so that the
> kexec restriction no longer applies?  This could be a fallback
> option if the original plan turns out to be too brittle/complex.

I think kyle has a patch which will allow disabling secureboot
restriction if one is on console. I will have to look into details
and see how can I make use of it in kexec code to relax signature
restrictions if user is on physical console.

[CC kyle]

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

Re: F20 System Wide Change: No Default Sendmail

[Lennart Poettering]

On Sun, 21.07.13 16:09, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> Am 21.07.2013 16:05, schrieb Matthew Miller:
> > On Sun, Jul 21, 2013 at 08:58:39AM +0200, Nicolas Mailhot wrote:
> >> it. Yet the "something better" never materialized. When I had a disk go
> >> wrong lately I was notified by the big ugly legacy system. I had *zero*
> >> notification by all the "better" systems that were given as "evidence".
> >> Because the "better" systems do not exist. None of the 'smtpd is legacy"
> >> complainers have actually tried to solve the (remote) notification
> >> problem, none of them actually understand the reliability and operational
> >> constrains, or that being to define message routing (via aliases,
> > 
> > Sure they do. I can't imagine an installation of any size (eg more than 2
> > systems) not using Nagios, Icigna, or some other alerting system.
> > 
> > If you're in the narrow case between a desktop system and an installation
> > where real monitoring and alerting is worth it, install an MTA
> 
> the problem i see is when things like MTA and rsyslog are
> removed from the defualt install many pakcgers will less
> care about them in the future nor test how well it works

This is not a valid argument. We cannot keep extending the core all the
time by adding more and more redundant components to them, just because
we believe this will cause APIs to be tested. It's the wrong approach in
every way. As we all know the current sendmail setup means mails are
lost in a /dev/null-like mail spool nobody reads. So we know right now
that the current situation is certainly really broken. What have we done
so far about it? Just ignored it, and continued to let the mail spools
run over with mails that are ignored. The few people who cared didn't
mind because they were the ones who reconfigured the aliases file or the
entire MTA in a way that actually made it useful. But that's a pretty
borked situation and unfair to everybody not in the know...

You get your stuff well-tested by removing redundancy, by making your
stuff interesting to people and by making sure people who care test
it. It's not enough just put on a system where nobody cares about it. It
didn't fix the local MTA situation in the past 10 years and it won't in
the next.

Also, what kind of a picture does this paint of the Fedora project
anyway? Only stuff we install by default matters and is tested? If that
was the case the only answer could be to drop all
non-installed-by-default packages from the dirstro... - but that would
just be so wrong

Lennart

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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Jóhann B. Guðmundsson]

On 07/22/2013 03:38 PM, Matthew Miller wrote:

On Mon, Jul 22, 2013 at 02:28:52PM +, "Jóhann B. Guðmundsson" wrote:

Should be made less RHEL we want people to use Fedora not RHEL

Candidly, we want people to use both.

We being you and the rest of the Red Hat's employees working in the
project?

"We" being Fedora.


Well I'm pretty sure your "We" there is not representive for the whole 
Fedora community...


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

Re: F20 System Wide Change: No Default Sendmail

[Lennart Poettering]

On Mon, 22.07.13 18:50, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote:

> 
> Le Lun 22 juillet 2013 18:29, Lennart Poettering a écrit :
> 
> > If you want to centralize system configuration, rather then services,
> > then go ahead and do, that, but actually centralize *the configuration*,
> > not the service. In particular, because a centralized client-side SMTP
> > service is a really questionnable thing on today's Internet where SMTP
> > delivery connections are almost always authenticated by a *user* id. Due
> > to that they are generally much better configured in the MUA which
> > actually run in the user context instead of a system service which lacks
> > all that and where no infrastructure exists for supplying user
> > authentication information.
> 
> Actually, with the various Fedora MUAs I've used, it ended up being easier
> to configure them to use local MTA as relay than to try to convince them
> individually to do anything more complex than 'non-encrypted smtp without
> auth' (when the options existed they changed every few MUA versions and I
> got tired of re-parametring them all the time). Bonus point is that
> changing the relay options fixes all MUAs in one go, I got free logging of
> the MUA activity, and a send queue that does not depend on running the MUA
> when the network comes back.

I find it quite amazing that you actually use multiple different MUAs in
parallel. I mean, most people stick to one MUA usually, maybe two. But
you make it sound as if you need to access your emails through 5 or 10
or so, so that it is really worth making this kind of low-level
configuration change.

It's also hardly something we can suggest people to actively do. User
credentials should not leak into the system like that. If two users send
emails on the same host, then the SMTP delivery needs to provide proper
authentication to the mail gateway attributing the individual mails to
the right user. You lose that by always going via your local MTA. It
certainly works for single-user systems but this generally not how we do
things on Linux, where user and system configuration in general and
authentication credentials in particular are strictly isolated.

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 Sendmail

[Lennart Poettering]

On Sun, 21.07.13 01:50, Oron Peled (o...@actcom.co.il) wrote:

> On Friday 19 July 2013 15:46:25 Adam Williamson wrote:
> > ... We don't set up any mail reader to read this mail out of the box.
> 
> OK, I won't count mailx and mutt because we talk about different audience,
> should we open bug-reports for the rest? (kmail? evolution?)

Goog luck filing bugs against Thunderbird, GMail and Zimbra to add
support for local mail queue reading...

> > No app is very likely to know your user name and send mail to you.
> 
> Cron was already mentioned, but every one seem to ignore the fact that
> regular users don't have permission to read system logs.

journald actually splits out user logs and use filesystem ACLs to ensure
that the user gets read access to his own logs. This doesn't work for
syslog (and also not if cron first collects all logs and then logs them
as root).

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 Sendmail

[Lennart Poettering]

On Sat, 20.07.13 18:05, Lars E. Pettersson (l...@homer.se) wrote:

> On 07/15/2013 07:54 PM, Lennart Poettering wrote:
> >Well, we don't even install any MUA by default currently that would read
> >local mail spools.  Effectively, this means that currently the log output
> >of cronjobs is more or less lost.
> 
> A user normally installs a MUA of their choice as one of the first
> things they do, so that a MUA is not installed by default should not
> be an issue. I.e. the output is not lost.

Well, assuming people use the local machine for reading their mails, and
not Thunderbird or so and not GMail and so on, or Zimbra or whatever
else people actually read mails with these days... None of these even do
local message reading.

> >By ensuring all logs go to the normal
> >log stream there's a much better chance of not losing messages...
> 
> The problem is that this data can be quite voluminous. Perhaps a bad
> thing to clog up the logs with that?

Emails due to base64 encoding usually increase everything by 4/3, which
is certainly worse.

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 Sendmail

[Chris Murphy]

On Jul 22, 2013, at 10:25 AM, Adam Williamson  wrote:
> 
> 
>> Even running the latest and greatest rawhide nothing desktop-side
>> caught a very basic event like a failing disk!
> 
> GNOME Disks is supposed to pop up a notification when SMART reports
> pre-fail status for a disk, I think. I suppose it's possible that's
> broken on the GNOME side somehow.

Difficult to test. ;-)

GNOME Disks will poll for SMART info when it's run manually. As for 
notifications when the app isn't running, I'm not sure how this would work 
without a daemon running that polls on a schedule. Same for mdadm created RAID 
arrays. Neither mdadm or smartd are configured out of the box to issue 
notifications, and when they are so configured, both depend on email as the 
mechanism.

I consistently get notifications from Gnome Shell if I use LVM (integrated) 
RAID, but presently anaconda doesn't create this form of RAID. Instead it uses 
mdadm to create an explicit md device, then creates LVM on that. Whereas the 
integrated approach, the raid level is an attribute of the LV (it does use the 
md driver code, but it doesn't depend on mdadm for creation or monitoring) with 
its own LVM monitoring daemon.

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

Re: F20 System Wide Change: No Default Sendmail

[Adam Williamson]

On Mon, 2013-07-22 at 19:09 +0200, Miloslav Trmač wrote:
> On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering
>  wrote:
> > On Mon, 22.07.13 18:43, Miloslav Trmač (m...@volny.cz) wrote:
> >
> >> On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
> >>  wrote:
> >> >> Application that want to log shoud log.  Applications that want to
> >> >> send e-mail should send e-mail.  My bank's monthly statement would be
> >> >> rather useless in the bank's splunk archive.
> >> >
> >> > Sure, but your bank web site probably doesn't send its mails out with
> >> > only tools of the default install?
> >>
> >> "What is in the default install" is, as argued elsewhere, also an
> >> implicit documentation of "how things are done".
> >
> > But it is totally bogus to claim that banks would suddenly stop sending
> > you notifcations by email just because Fedora doesn't install sendmail
> > by default. I mean, come on, you are not trying to be honest here, and
> > you know it.
> 
> Sure, if you twist my words into saying something I didn't say...  "I
> mean, come on, you are not trying to be honest here, and you know it."
> 
> The question is _how_ to send the e-mail, not _whether_.

Just before this one gets any worse: it was Nicolas Mailhot who started
talking about banks sending email for some reason, not Miloslav.
-- 
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: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Eric Smith]

On Mon, Jul 22, 2013 at 10:52 AM, "Jóhann B. Guðmundsson"
 wrote:
> On 07/22/2013 04:41 PM, Stephen Gallagher wrote:
>> They chose to use a _downstream_ distribution. RHEL *is* Fedora, it's
>> just a Fedora that's been hardened and held to a certain level of
>> ABI/API compatibility.
> Which is my point exactly instead of helping increasing the overall quality
> of Fedora the infrastructure decide to run to another distribution.
>
> RHEL != Fedora

But it's not an objective of Fedora to have long-term-stable releases
suitable for running servers!  No one in their right mind runs any
rapid development distribution (not just Fedora) on critical
infrastructure.

If you think Fedora should somehow transition into being a good
distribution for critical infrastructure, you'll have to propose some
radical changes to Fedora to make that happen.

It is a Good Thing that RHEL != Fedora. If RHEL did rapid development
instead of long term stable, people wouldn't buy it.  If Fedora did
long term stable instead of rapid development, we'd need yet another
distribution to do the rapid development.

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

[Bug 987118] New: perl-5.18: File handles modified with binmode ':unix' leak

[bugzilla]

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

Bug ID: 987118
   Summary: perl-5.18: File handles modified with binmode ':unix'
leak
   Product: Fedora
   Version: rawhide
 Component: perl
  Assignee: mmasl...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: cw...@alumni.drew.edu, iarn...@gmail.com,
jples...@redhat.com, ka...@ucw.cz,
mmasl...@redhat.com,
perl-de...@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com, rc040...@freenet.de,
tcall...@redhat.com

File handle will leak the close() call if has been modified with binmode to
':unix' layer.

[test@fedora-20 tmp]$ cat test
for my $x (1 .. 1) {
open my $temp, '>', "/tmp/t" or die "$!";
binmode $temp, ":unix";
close $temp;
}
[test@fedora-20 tmp]$ perl ./test 
Too many open files at ./test line 2.

Reported to upstream
.

-- 
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=UDC1hZzy1Y&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 Self Contained Change: Plasma-nm

[Lukáš Tinkl]

Dne 22.7.2013 17:45, Adam Williamson napsal(a):

On Tue, 2013-07-16 at 13:25 +0200, Jaroslav Reznik wrote:

= Proposed Self Contained Change: Plasma-nm =
https://fedoraproject.org/wiki/Changes/Plasma-nm

Change owner(s): Jan Grulich , Lukáš Tinkl


Replace current network applet in KDE with a new one and bring the latest news
in NetworkManager to KDE.

== Detailed description ==
Plasma-nm is a new plasma applet for network management in KDE which uses the
latest KDE technologies. It supports all connection types from NetworkManager
like bonding, bridging etc. and it's simplier to maintain it than the old one.
It absoletes the old network applet which is hardly maintainable.

== Scope ==
This feature affects only KDE. The only necessary action is to remove and
obsolete the kde-plasma-networkmanagement package and ensure that kde-plasma-
nm is installed by default.


What is the schedule for this Change? As with other significant changes
to release-blocking DEs, it'd be very much preferable to have it in by
Alpha.



We plan to do the (first) official release by the end of this week and 
immediately import it into fedora git repos. Rawhide has contained git 
snapshots until now.


--
Lukáš Tinkl 
Software Engineer - KDE desktop team, Brno
KDE developer 
Red Hat Inc.   http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Toshio Kuratomi]

On Mon, Jul 22, 2013 at 04:47:12PM +, "Jóhann B. Guðmundsson" wrote:
> On 07/22/2013 04:34 PM, Toshio Kuratomi wrote:
> >This was actually not the rationale.  The rationale was that it wasn't
> >harmful to Fedora and so if individual maintainers felt that it was
> >something that they wanted to ship they could.
> 
> Did the FPC even bother to test what they had approved in practices?
> ( Do they in general? )
> 
> Have you tried installing an legacy sysv initscript file and using
> after it has been replaced with a native systemd unit.
>
The sysv initscripts subpackages are not for use with systemd.  They are for
use at places that use systemv init scripts.  When the guidelines were
initially written, having both installed was tested and they didn't cause
problems for systemd (although having both installed and still using systemd
was seen as not the use case for having the subpackages).  Has something
changed in the systemd code since then that changes that equation?

-Toshio


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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Kevin Fenzi]

On Mon, 22 Jul 2013 13:03:45 -0400
Matthew Miller  wrote:

> [the following has much trimming as I reply to specific points.
> Hopefully I haven't over-trimmed]

No worries. I will do trimming as well. 

> > >   * Can override versions of software at lower tier
> > >   * Can overlap with software from other stacks
> > >   * Not necessarily even RPM
> > >   * Different lifecycle (but shared release cadence)
> > > Big stuff here.
> > I think these things would lead to a lot of Chaos. 
> 
> One model I have for this kind of disruption is the Innovation Schools
> process in Massachusetts. (Since I have kids in elementary school...)
> This is an in-school-system alternative to a charter school, where an
> individual public school can be established (or converted) to do
> things differently from district policies. Here, there are six
> different "areas of autonomy", allowed and in each case you have to
> list which autonomy you're asking for -- in the school case,
> curriculum, scheduling, staffing, etc. Here, it'd be the examples
> above and whatever else. This is the point on a different slide that
> we need the policies to make this ring part of Fedora. So, a
> practical follow-up to this proposal would be a committee to design
> the policies for Ring 2 and how they work.

Sure. Of course you mean, design the policies and get feedback and then
get approval from fesco/Board. ;) 
> 
> > Person with one package management system always knows whats
> > installed. Person with 5 is never sure. 
> 
> I expect that for practical use, five might be available but users
> would pick one. (Or in some cases two -- one for managing the base
> and one for what's on top of that.)

Well, or you are going to have to use whatever the SIG/whatever uses
right? so, base with rpms, then add some other rpms, then a SCL for
something, then you need some gems, etc. 

I just don't see how this could be supportable in the long run, unless
we were very clear and narrow what could overlap and who is supporting
it. 

> > Do we need a more formal definition of a SIG? Right now it's...
> > anyone who calls themselves that. 
> 
> Possibly.
> 
> > How do we handle resources for these Rings? 
> 
> Can you define "resources" more specifically in this context?

Well, with my infrastructure hat on, I'd be first talking about
infrastructure resources. Say a SIG formed around gitlab, and said: We
need a buildsystem to build gems and sign them, mirror and distribute
them and an updates system for updating them. If we can't use our
existing infrastructure since it's rpm centric, someone would have to
write this code, test it, deploy it and maintain it. It would need
machines and mirror space and release engineering and qa and a bunch of
things. We simply don't have that in existance and negative cycles to
create and maintain such a thing. 

The next thing someone will say is: "Oh, each sig can write and
maintain their own thing". Thats bad for lots of reasons. Many SIGs
wouldn't have the person power to write and maintain things, or the
experence doing so, or the desire to maintain them in a secure and
sustainable manner, etc. 

So, IMHo, if we go the route of allowing/shipping/maintaining non rpm
collections, we should be very clear up front what resources could be
expected. 

> > I like the idea, but I worry about calling all these things "Fedora"
> > before they are really worthy of it, or before we know the scope of
> > them. I like the idea of providing some place or resources as we can
> > for them and let them hash out if they can come up with a
> > supportable/sustainable model, then they could be considered for
> > moving further into the Fedora ecosystem. 
> 
> Here, I'm appealing to the broad charter given by Fedora's mission,
> which is "The Fedora Project's mission is to lead the advancement of
> free and open source software and content as a collaborative
> community."
> 
> The distribution itself as we make it today is much narrower than
> that. There's plenty of room under the umbrella for us to include
> things in Fedora outside of what we do now.

Sure, I don't disagree, as long as what these things are is clear and
not "Fedora the OS". 

...snip...

> > > Second, we can make some changes to allow Software Collections to
> > > be built for Fedora. There's more we can do with OpenShift. And
> > > we can build up the Fedora Formulas idea. Basically, let's do all
> > > that.
> > What do you mean by 'built for fedora' here? ;) 
> 
> Hopefully some of the Software Collections people can elaborate more
> on what they need. I think "built in and distributed with Fedora
> infrastructure" is roughly what I mean.

I'd prefer a setup where some SIG defines a collection somehow and end
users can grab that and build the collection locally and use it. Then
support for that would fall on the SIG that created the definition. 

If we build them ourselves, that to my mind implies that we need
infrastructure changes, releng buy in and qa buy in to test

Re: F20 System Wide Change: No Default Sendmail

[Alexander Boström]

mån 2013-07-22 klockan 18:36 +0200 skrev Lennart Poettering:

> Despite that I am pretty sure that most of the stuff we currently mail
> (like the log output of cron jobs) simply makes no sense as mail, and
> should much rather be treated exactly like all other log output. There's
> nothing special really about cron that would make it so much better
> suitable for sending out its logs per mail, rather then just log them.

Yeah, as a sysadmin I'm mostly annoyed by services that send mail and
expect someone to have time to read them. Give me a current status that
can be monitored as appropriate (desktop notifications, Nagios etc) and
logs so I can go back and see what went wrong.

Also, I think people who are new to this stuff are much more likely to
look for logs than for mail ("what, computers can have mail on them?")
when they're trying to figure out what's happening.

It is however a bit scary if the behavior of cron changes when someone
installs an MTA. I think -s should be the default, but MAILTO= should
have precedence over -s.

/Alexander


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

Re: F20 System Wide Change: No Default Sendmail

[Matthew Miller]

On Mon, Jul 22, 2013 at 06:53:24PM +0200, Nicolas Mailhot wrote:
> What makes cron and smtpd work well together is that they both perform
> async background computing. And many cron messages are not "logs" they're
> notifications of an event the cron is polling for, or submission of job
> results.

Honest, non-loaded question here. Do you really find them default cron
output mode helpful? You suggested earlier that I dislike cron's e-mail
output, and while I hadn't brought up likes or dislikes before, I really
don't find it so great. To me, it just fills up my mailbox with:

   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 AnacronAnacron job 'cron.daily' on bigcomputer.home.
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  /opt/seas/sbin/sync-NIS
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  TMPDIR=`mktemp -d /tmp
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro
   Jul 02 Cron DaemonCron  /etc/15m.local
   Jul 02 Cron DaemonCron  /etc/15m.local
   Jul 02 Cron DaemonCron  /etc/15m.local
   Jul 02 Cron DaemonCron  /etc/15m.local
   Jul 02 Cron DaemonCron  ionice -c3 run-parts /etc/cro

If I did want e-mail output -- which I used to, before I had proper alerting
set up, so as I mentioned before I totally recognize that use case -- I
really would like it with a meaningful subject line, which means even when
running out of cron, the jobs should actually call sendmail or /usr/bin/mail
directly with pretty-formatted output. (And thus, have an explicit
dependency on an MTA, and also basically have the expectation that they're
running on a system which will be properly configured for its environment,
however that happens.)

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

[Alexey I. Froloff]

On Mon, Jul 22, 2013 at 06:50:17PM +0200, Nicolas Mailhot wrote:
> Actually, with the various Fedora MUAs I've used, it ended up being easier
> to configure them to use local MTA as relay
If you are able to configure the MTA of your choice, then you
will be able to install that MTA when you need it.  Default
settings are not usable for anything other than local delivery.

-- 
Regards,--
Sir Raorn.   --- http://thousandsofhate.blogspot.com/


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

Re: F20 System Wide Change: No Default Sendmail

[Miloslav Trmač]

On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering
 wrote:
> On Mon, 22.07.13 18:43, Miloslav Trmač (m...@volny.cz) wrote:
>
>> On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
>>  wrote:
>> > On Fri, 19.07.13 20:22, Miloslav Trmač (m...@volny.cz) wrote:
>> >
>> >> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
>> >>  wrote:
>> > Where "expected to do" means effectively route it to /dev/null?
>>
>> It's actually less similar to /dev/null than log files are - log files
>> are rotated and deleted, mail stays in the mail boxes until explicitly
>> deleted (or space runs out).
>
> Well, so it's even a DoS... Just find some trigger to generate a lot of
> mails to root and /var will eventually fill up, even beyond those 10%
> reserved for root, since well, mail to root is accounted to root...

My concern about this proposal doesn't actually depend on local
delivery, it _could_ go to /dev/null by default for all I care.

I'll note, however, that "this is a DoS" is rarely a convincing
argument - the only practical way to combat a DoS is to impose some
kind of limit, which is just a DoS of a different kind.  You get to
choose _what_ kinds of DoS your computer will be subject to, but with
finite CPU power and storage you can't avoid DoS situations.

And, philosophically, silently losing data is generally much worse
than requiring manual intervention for the system to run when space
runs out.  (Not that the mails we sent by default are _that_ valuable,
though.)
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Kevin Fenzi]

On Mon, 22 Jul 2013 09:38:54 -0400
Matthew Miller  wrote:



I do agree that "Core" will cause some people to blink, but I realize
it's just a label. We could call it "Base" or "Platform" Or "OS" or
"bob", it doesn't bother me too much. 

>   What's a Ring?
>   ---
>   * Rings give SIGs a way to replace the default expectations with
> their own

A lot of the proposals and posts I have seen lately have talked about
giving SIGs more power and ability to do what they want. However,
traditionally in Fedora SIGs have been very loosely setup and it's
not clear to me how active most of them are. I could be wrong, but it
kind of sounds like people are wanting to shove off work to SIGs that
may or may not exist or be able to do the work. 

>   * Separate policies may apply to each ring
>   * But also, also, we need community, policies, and infrastructure
> to make them _part of Fedora_
> 
> So, there's nothing really magical about the circles. The main idea
> is that we need to make room for more exploration within Fedora
> beyond the traditional idea of how a Linux distribution is put
> together, and this is a model for describing how and where that can
> work.
> 
> We still need global Fedora policies, but they'll apply differently
> to each ring. In Ring 2, SIGs will be given a lot of room to develop
> their own rules, but in Ring 1, not so much. Different environments
> and stacks within Ring 2 may have different individual policies from
> each other, but there will also be general policies for Ring 2 which
> are different from those for Ring 1, and of course global policies
> that apply to the whole thing (e.g., no proprietary code).
> 
>   Possible Examples
>   --- 
>   * Possible example: bundled libs okay, but must be documented

ok. 

>   * Can override versions of software at lower tier
>   * Can overlap with software from other stacks
>   * Not necessarily even RPM
>   * Different lifecycle (but shared release cadence)
> 
> Big stuff here.

I think these things would lead to a lot of Chaos. 
 
> Obviously, no-bundled-libs is a crucial part of the packaging
> guidelines today. As a sysadmin, I know why it's important. This is
> not just a noble goal, but also something that pragmatically makes
> systems better. But, it's also keeping us from having software that
> people really use in Fedora. Chef and Hadoop are two big examples.
> This hurts us more than it helps the world. So, in some areas, we
> need a different approach.

I might be open to relaxing that somehow... 
> 
> Overriding other parts of the distribution is crucial, and I'll talk a
> little bit more about different approaches and what they mean in a
> little bit.

It might be important to some, but it also means a lot more work. ;) 

> Some approaches may even move beyond RPM packaging. This can mean
> focusing on "language native" package formats like Jars, Gems, and
> Eggs; or it can mean moving to a Git-based distribution model for
> some parts of the distro.

Person with one package management system always knows whats
installed. Person with 5 is never sure. 
 
> And, different lifecycle: a SIG may decide that Ruby 1.9.x support
> should continue for some number of years and maintain that stack
> against different Fedora Core releases. We do this already in some
> ways, but having a clear split makes it feel more natural and will
> make developers feel more confident.

I suppose.  
> 
>   SIG-centric
>   ---
>   * SIGs will form "bubbles" within this ring, possibly varying from
> packaging guidelines in order to meet needs. 
>   * Change management will also be SIG-focused.
> 
> Fedora already largely works this way. We just need more of it. If we
> can be more flexible about what it means to participate in Fedora, we
> can increase the intersection with upstream communities.

Do we need a more formal definition of a SIG? Right now it's... anyone
who calls themselves that. 

How do we handle resources for these Rings? 

If they aren't using rpms, how are reviews done, packages imported to
where, built where, signed where, etc? What about conflicts between
rings? 

>   Fedora Commons
>   ---
>   * The collection of packages outside Core following traditional
> policies and practices
>   * We're not throwing that away
>   * Many people continue to be interested in this model
>   * Shared by other parts of Ring 2 where possible
> 
> This is a special bubble within Ring 2. In fact, on Day 0, it still
> is _all of_ Ring 2. The name here is mean to evoke Creative Commons;
> we can discuss other possibilities too, of course. 
> 
> 
>   Many Ways!
>   ---
>   * Software Collections
>   * Stacks 2.0
>   * OpenShift Cartridges
>   * Fedora Formulas
>   * Traditional Packaging
> 
> There are many different approaches people are working on right now.
> I don't know which will ultimately be best. We want to enable the
> experimentation, so we can find what succeeds. Some of these things
> aren't beautiful, but if we can invite them in anyway, they can

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Jaroslav Reznik]

- Original Message -
> >   SIG-centric
> >   ---
> >   * SIGs will form "bubbles" within this ring, possibly varying from
> > packaging guidelines in order to meet needs.
> >   * Change management will also be SIG-focused.
> > 
> > Fedora already largely works this way. We just need more of it. If we
> > can be more flexible about what it means to participate in Fedora, we
> > can increase the intersection with upstream communities.
> 
> Do we need a more formal definition of a SIG? Right now it's... anyone
> who calls themselves that.
> 
> How do we handle resources for these Rings?

Resources were the first thing that came to my mind when I read this -
I'm definitely fan of well defined "core" Fedora, even in the meaning
of meta distribution which coudl be used for other project. It would be 
worth to implement it and we should be able to implement this within 
Fedora. But with my current job hat on - I can't imagine implementing 
the whole proposal to create a similar experience we do today - products.
Most of SIGs are one man show, even release engineering is mostly one man
show, same for all other teams, Fedora QA is pretty big team compared
to other Fedora teams but still - releasing even one kind of Fedora,
with same release day, same lifecycle is a barely manageable without
investments (aka more automation - not only for QA etc.). Same for 
development... I understand proposal as - this is the way how we can
get more contributors, even from upstreams but it's the question if
they would be interested in.

Btw. I'm not saying it's impossible - but it could be pretty hard.
Also we still don't have an answer for "what should be Fedora" and
even now we have 10 different and pretty conflicting visions ;-).

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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Jóhann B. Guðmundsson]

On 07/22/2013 02:06 PM, Remi Collet wrote:

Le 22/07/2013 15:38, Matthew Miller a écrit :


   Wait, did you just say Fedora _Core_?

   Yes I did.

   But, this is not a return to the old Core + Extras, because the line is
   drawn based on _what_ and _how_ rather than on who works for what company.

Whatever explanation which can be given, "Core" is just the worst name
to be used.

For me, The merge Core + Extras => "Fedora" is just the most significant
step for fedora project as a real community distro.

Getting back to "Core" (even with a different definition) is just
something I'd like to avoid because will be considered like a huge
regression.

Ex : I'm so disgusted that I don't ever have desire to read the rest of
the doc.


He's just speaking of base/coreOS we can call it whatever we like once 
we have agreed which components it's actually made up of.


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

Re: F20 System Wide Change: No Default Sendmail

[Alexey I. Froloff]

On Mon, Jul 22, 2013 at 06:36:41PM +0200, Lennart Poettering wrote:
> Let's not forget: this is not about removing software from the
> distro. This is just about removing it from the default install, since
> the current way it is set up by default it just eats up messages
> silently, with not indication of error and no useful tools installed to
> actually get the messages out of it again.
Instead of having MTA, I'd rather have tool that can collect and
show such "mails".  There are machines (like my and wife's
laptops) that are not supposed to send emails.  They doesn't even
have MUA installed.  All these emails are wasted and not being
rotated.

In 2013 you can't just start sending mails around with default
MTA settings, so not installing and MTA by default is a good
solution.

-- 
Regards,--
Sir Raorn.   --- http://thousandsofhate.blogspot.com/


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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Matthew Miller]

On Mon, Jul 22, 2013 at 11:12:16AM -0600, Chris Murphy wrote:
> > Whenever I go to a tech meetup or talk to someone from a new startup
> > company, their developers are inevitably using a different (usually
> > proprietary) desktop OS, plus a non-Fedora distribution on their code.
> > We're being left behind and left out. It doesn't matter how
> > theoretically great we are if we end up with no users.
> It comes down to the proprietary OS "just works." Top on the list: lack of
> video problems on proprietary OS's compared to linux. Next, I'll guess
> it's HCI related, in that the world's users have decided interaction via
> GUI is not merely preferred, but required. If CLI is required, it's
> disqualifying (e.g. there's no GUI means of upgrading from Fedora 18 to
> 19).

Probably true. I'm not suggesting we bet it all on going after the desktop
market. Everything else aside, OS X (and Android/ChromeOS, for that matter)
have a significant advantage in having hardware that they're essentially
bundled with, and we're just plain not going to have that. We've got a
desktop team with significant investment in Fedora, and I think as a
distribution we should support them, but it's the target where the code is
being deployed that I'm really interested in. (If we can create some 
interested there through a better desktop experience too, though, I'm all
for it.)

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

[Lennart Poettering]

On Sat, 20.07.13 09:00, Robert Nichols (rnicholsnos...@comcast.net) wrote:

> On 07/15/2013 09:14 AM, Lennart Poettering wrote:
> >This feature is about not doign local mail delivery by default, by not
> >installing any MTA. Instead you find the log output of cronjobs at the
> >same place as you find any other log output, the journal/syslog, for
> >example accessible via:
> >
> >journalctl -u crond
> >
> >or
> >
> >systemctl status crond
> >
> >(the latter will only show you 10 log lines by default, the former all
> >of them. You can pass "-n 100" to either to see the 100 latest ones)
> 
> You are thinking only about error output from cron jobs.  Regular
> output from cron jobs can be quite voluminous. Is it reasonable to send
> 15 to 20 Kilobytes to the journal (root's logwatch job currently sends
> that much every day)? How about a couple of JPGs (graphs of resource
> usage)?

The journal supports 2^64 sized binary objects to be stored in it. It
currently will get a bit slow if you actually send a lot of data sind it
first needs to XZ compress the blobs before writing them to disk and
that will stall operation for that time, but a few 100K (or even MB) in
a single message should be no problem.

(Note that the way cron's mail support works you cannot use it directly
to send JPEGs...)

Lennart

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

[389-devel] please review: Ticket 47440 - Fix compilation warnings

[Lukas Slebodnik]

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

https://fedorahosted.org/389/attachment/ticket/47440/0001-Fix-compilation-warnings.patch
https://fedorahosted.org/389/attachment/ticket/47440/0002-Use-right-prototype-for-auxprop_lookup-in-sasl-plugi.patch
https://fedorahosted.org/389/attachment/ticket/47440/0003-Do-not-include-config.h-to-public-headers.patch
https://fedorahosted.org/389/attachment/ticket/47440/0004-Explicitly-specify-that-a-function-requires-no-argum.patch
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Miloslav Trmač]

On Mon, Jul 22, 2013 at 7:03 PM, Matthew Miller
 wrote:
>> Person with one package management system always knows whats
>> installed. Person with 5 is never sure.
>
> I expect that for practical use, five might be available but users would
> pick one. (Or in some cases two -- one for managing the base and one for
> what's on top of that.)
Would users actually have a choice?  The packaging system to use is
dictated by how the stack is shipped, isn't it?
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Chris Murphy]

On Jul 22, 2013, at 7:38 AM, Matthew Miller  wrote:

> Whenever I go to a tech meetup or talk to someone from a new startup
> company, their developers are inevitably using a different (usually
> proprietary) desktop OS, plus a non-Fedora distribution on their code. We're
> being left behind and left out. It doesn't matter how theoretically great we
> are if we end up with no users.

It comes down to the proprietary OS "just works." Top on the list: lack of 
video problems on proprietary OS's compared to linux. Next, I'll guess it's HCI 
related, in that the world's users have decided interaction via GUI is not 
merely preferred, but required. If CLI is required, it's disqualifying (e.g. 
there's no GUI means of upgrading from Fedora 18 to 19).

Mac users are particularly fussy about the polish of the UI/X, not just that 
one is offered. Windows users likewise depends on the GUI for all things, but 
they're significantly more tolerant of exceptionally bad UI/UX. In any case, 
attracting a larger number of Windows and Mac users, it seems to me, will 
require a considerable change in emphasis on UI/UX standards.



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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Matthew Miller]

On Mon, Jul 22, 2013 at 04:30:32PM +0200, Miloslav Trmač wrote:
> How do I package and ship an application that depends on two or more
> stacks (e.g. uses a database, has a web frontend and perhaps also a
> local GUI) if the stacks the application depends on can have
> overlapping and therefore probably (necessarily?) conflicting
> software, different lifecycles and packaging methods?

I'm not suggesting a crazy free-for-all. If you have an application which
depends on multiple stacks, you would want to select one technology for all
of those stacks -- OpenShift cartridges, or Software Collections, or Fedora
Formulas. If you want to use a cartridge for one and a software collection
for the other, I don't think there's any expectation that this would work.

This is also why I had "environments" as a higher ring in earlier versions
of the slides. When you're making your development or package-and-ship
decision, you want to be thinking about the environment in which it will run
and then the implementation technology decision comes from that.

> > This is a special bubble within Ring 2. In fact, on Day 0, it still is
> > _all of_ Ring 2. The name here is mean to evoke Creative Commons; we can
> > discuss other possibilities too, of course.
> What happens when a RPM (presumably) package from Fedora Commons
> depends on infrastructure that decides to move to a stack and stop
> using RPM?

The same thing that happens in Fedora now when someone decides to stop
maintaining an RPM.

> > In the future, a namespace approach
> > could even make /usr/bin/python be Python 3 for some processes but not for
> > the core OS.
> (Namespaces are an administration nightmare because paths suddenly
> don't mean what they seem to mean.)

That's why "in the future". That particular idea is something some people
are exploring but which needs a lot of details worked out. I think we should
encourage the exploration, though.

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

Re: EPEL (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Jóhann B. Guðmundsson]

On 07/22/2013 04:08 PM, Stephen Gallagher wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/22/2013 11:58 AM, "Jóhann B. Guðmundsson" wrote:

Our Fedora infrastructure team should be using Fedora it's an
disgrace to the community for them not doing so.


That's something else that this policy could potentially addresses,
frankly. The reason our infrastructure team doesn't use Fedora is
because upgrading critical infrastructure every six months is simply
infeasible. If we adopt this plan where we have a fairly solid core,
then we could build essentially a Fedora Infra SIG that could then
have a custom server build for maintaining the build infrastructure
and hosting pieces. Right now, Fedora is not the right platform for
that, but maybe we could identify that as one of the goals of this
project. Would you be interested in participating in that SIG and help
design it?


Ofcourse


Just keep that documentation out of our wiki ( or in epel's own
under epels own domain or lock tide within red hat docs )  since
that has nothing to do with Fedora and having it there only
confuses Fedora packagers


There are arguments to be made for keeping EPEL's documentation
separate, sure. But the simple fact is that in most cases, they differ
by less than 1% and it's more economical to keep them both up to date
if they're just the same page with effectively an #ifdef.

As for cruft in the spec files, why not bring a proposal to the FPC to
update the packaging guidelines stating that Fedora spec files must
not contain RHEL/EPEL macros? Then the git branches would be
maintained separately and the spec files might be more easily read.


Because I have reach the conclusion that bringing anything up with FPC 
is just waste of everyone's time


From their decision making ( which often to me make no sense ) to the 
time it takes for them to approve and implementing changes to the 
packaging guidelines ( even from "concrete" proposals ) are absurd and 
more often then not takes longer time than to actually implement the 
requested change on affected components which makes it impossible to try 
to schedule ones free time to make those changes even scheduling to make 
those changing within our development cycle.


A far more efficient approach is to adapt an ack/nack/patch approach on 
the packing community mailinglist and dissolve FPC.


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

Re: Webapps denying all outside access by default?

[Nicolas Mailhot]

Le Lun 22 juillet 2013 15:40, Matthew Miller a écrit :
> On Mon, Jul 22, 2013 at 01:16:30AM -0600, Ken Dreyer wrote:
>> I do agree that the .rpmnew thing is annoying, and I wish there was a
>> better way to handle that.
>
> I think in general, packaging webapps into RPM is of low value. I've tried
> to use these packages in production several times over the years, and
> inevitably become frustrated and which I'd just installed from upstream as
> upstream expects.

I have the reverse experience. More to the point, with my former startup
operator hat on, I would say that packaged webapps is the only reason a
startup would be interested in Fedora (though to be honest it would
probably run at least part of its infra on centos)

-- 
Nicolas Mailhot

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

Re: F20 System Wide Change: No Default Sendmail

[Lennart Poettering]

On Mon, 22.07.13 18:43, Miloslav Trmač (m...@volny.cz) wrote:

> On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
>  wrote:
> > On Fri, 19.07.13 20:22, Miloslav Trmač (m...@volny.cz) wrote:
> >
> >> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
> >>  wrote:
> >> > On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote:
> >> >> However, having the /usr/sbin/sendmail API available to applications
> >> >> is valuable - it brings a significant system administration benefit of
> >> >> centralizing the SMTP configuration.
> >> >
> >> > What does it mean to "have available"?
> >> Just that.  The binary exists and does what it is expected to do.
> >
> > Where "expected to do" means effectively route it to /dev/null?
> 
> It's actually less similar to /dev/null than log files are - log files
> are rotated and deleted, mail stays in the mail boxes until explicitly
> deleted (or space runs out).

Well, so it's even a DoS... Just find some trigger to generate a lot of
mails to root and /var will eventually fill up, even beyond those 10%
reserved for root, since well, mail to root is accounted to root...

This is not helping your case. It just makes it worse.

> > If features only work after configuration (in articular non-trivial
> > configuration like this case) then it should not be part of the default
> > install.
> 
> That a feature needs configuration does not automatically exclude it
> from the default installation - removing a package from the default
> installation and telling users to install it back is just window
> dressing and asking them to do unnecessary extra work.

No, because only a smaller fraction of installs would actually end up
installing a local MTA.

> >> Application that want to log shoud log.  Applications that want to
> >> send e-mail should send e-mail.  My bank's monthly statement would be
> >> rather useless in the bank's splunk archive.
> >
> > Sure, but your bank web site probably doesn't send its mails out with
> > only tools of the default install?
> 
> "What is in the default install" is, as argued elsewhere, also an
> implicit documentation of "how things are done".

But it is totally bogus to claim that banks would suddenly stop sending
you notifcations by email just because Fedora doesn't install sendmail
by default. I mean, come on, you are not trying to be honest here, and
you know it.

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 Sendmail

[Subhendu Ghosh]

On Fri, Jul 19, 2013 at 1:37 PM, Miloslav Trmač  wrote:

> However, having the /usr/sbin/sendmail API available to applications
> is valuable - it brings a significant system administration benefit of
> centralizing the SMTP configuration.
>


Then the app packaging can have a dependency on sendmail.

But it doesn't not require sendmail to be in the _default_ installation.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Miloslav Trmač]

On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering
 wrote:
> On Mon, 22.07.13 18:43, Miloslav Trmač (m...@volny.cz) wrote:
>
>> On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
>>  wrote:
>> >> Application that want to log shoud log.  Applications that want to
>> >> send e-mail should send e-mail.  My bank's monthly statement would be
>> >> rather useless in the bank's splunk archive.
>> >
>> > Sure, but your bank web site probably doesn't send its mails out with
>> > only tools of the default install?
>>
>> "What is in the default install" is, as argued elsewhere, also an
>> implicit documentation of "how things are done".
>
> But it is totally bogus to claim that banks would suddenly stop sending
> you notifcations by email just because Fedora doesn't install sendmail
> by default. I mean, come on, you are not trying to be honest here, and
> you know it.

Sure, if you twist my words into saying something I didn't say...  "I
mean, come on, you are not trying to be honest here, and you know it."

The question is _how_ to send the e-mail, not _whether_.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Matthew Miller]

On Mon, Jul 22, 2013 at 09:21:39AM -0600, Kevin Fenzi wrote:
> I do agree that "Core" will cause some people to blink, but I realize
> it's just a label. We could call it "Base" or "Platform" Or "OS" or
> "bob", it doesn't bother me too much. 

Ah yes, Fedora Bob. Just in line with what Microsoft is doing!
http://news.cnet.com/8301-10805_3-57593736-75/bill-gates-says-microsoft-bob-will-make-a-comeback/

:)

[the following has much trimming as I reply to specific points. Hopefully I
haven't over-trimmed]

> >   * Rings give SIGs a way to replace the default expectations with
> > their own
> A lot of the proposals and posts I have seen lately have talked about
> giving SIGs more power and ability to do what they want. However,
> traditionally in Fedora SIGs have been very loosely setup and it's
> not clear to me how active most of them are. I could be wrong, but it
> kind of sounds like people are wanting to shove off work to SIGs that
> may or may not exist or be able to do the work. 

True. Some of these things I expect to grow as we enable them. I don't think
it will be there immediately. 


> >   * Can override versions of software at lower tier
> >   * Can overlap with software from other stacks
> >   * Not necessarily even RPM
> >   * Different lifecycle (but shared release cadence)
> > Big stuff here.
> I think these things would lead to a lot of Chaos. 

One model I have for this kind of disruption is the Innovation Schools
process in Massachusetts. (Since I have kids in elementary school...) This
is an in-school-system alternative to a charter school, where an individual
public school can be established (or converted) to do things differently
from district policies. Here, there are six different "areas of autonomy",
allowed and in each case you have to list which autonomy you're asking for
-- in the school case, curriculum, scheduling, staffing, etc. Here, it'd be
the examples above and whatever else. This is the point on a different slide
that we need the policies to make this ring part of Fedora. So, a practical
follow-up to this proposal would be a committee to design the policies for
Ring 2 and how they work.


> Person with one package management system always knows whats
> installed. Person with 5 is never sure. 

I expect that for practical use, five might be available but users would
pick one. (Or in some cases two -- one for managing the base and one for
what's on top of that.)

> Do we need a more formal definition of a SIG? Right now it's... anyone
> who calls themselves that. 

Possibly.

> How do we handle resources for these Rings? 

Can you define "resources" more specifically in this context?




> I like the idea, but I worry about calling all these things "Fedora"
> before they are really worthy of it, or before we know the scope of
> them. I like the idea of providing some place or resources as we can
> for them and let them hash out if they can come up with a
> supportable/sustainable model, then they could be considered for moving
> further into the Fedora ecosystem. 

Here, I'm appealing to the broad charter given by Fedora's mission, which is
"The Fedora Project's mission is to lead the advancement of free and open
source software and content as a collaborative community."

The distribution itself as we make it today is much narrower than that.
There's plenty of room under the umbrella for us to include things in Fedora
outside of what we do now.

> > It may be useful as we think about the different approaches to think
> > about the different philosophies they take. For example, there are
> > two different ways to "override" something. One is to actually
> > replace it — for example, your Fedora Formula may
> > replace /usr/bin/python with Python 3. The other is to install
> > multiple versions in parallel — using multi-versioned RPMs, or
> > Software Collections for whole stacks. In the future, a namespace
> > approach could even make /usr/bin/python be Python 3 for some
> > processes but not for the core OS.
> I think of these things as completely valid, but something end users
> would be doing. Couldn't we provide the tools and setup to easily allow
> people to do this, but let them do whatever they need for their needs? 

Absolutely. I think the Formulas approach is particularly suited to that; we
can provide the basic tools, and hopefully a collaborative library of
packaged solutions, but we don't necessarily provide the bits.


> The problem with doing this stuff as an OS, IMHO, is that there's a
> combitorial explosion in support and maintenance. 

*nod* Need more clarity in what combinations are sensible / supported.


> > if we take @standard + @core, that gives 430 packages from 330
> > SRPMs... but recursively following the build deps explodes that to
> > 3915 packages from 1800 SRPMs. That's smaller than the 13.7K SRPMs in
> > all of Fedora, but bigger than would be ideal for the Core. And it's
> > probably not really the package set we want. So, I'd like to look a

Re: F20 System Wide Change: No Default Sendmail

[Nicolas Mailhot]

Le Lun 22 juillet 2013 18:29, Lennart Poettering a écrit :

> If you want to centralize system configuration, rather then services,
> then go ahead and do, that, but actually centralize *the configuration*,
> not the service. In particular, because a centralized client-side SMTP
> service is a really questionnable thing on today's Internet where SMTP
> delivery connections are almost always authenticated by a *user* id. Due
> to that they are generally much better configured in the MUA which
> actually run in the user context instead of a system service which lacks
> all that and where no infrastructure exists for supplying user
> authentication information.

Actually, with the various Fedora MUAs I've used, it ended up being easier
to configure them to use local MTA as relay than to try to convince them
individually to do anything more complex than 'non-encrypted smtp without
auth' (when the options existed they changed every few MUA versions and I
got tired of re-parametring them all the time). Bonus point is that
changing the relay options fixes all MUAs in one go, I got free logging of
the MUA activity, and a send queue that does not depend on running the MUA
when the network comes back.

To be sure, it would be cleaner it the connexion user when relaying
depended on the system user that emitted the message. I've not checked if
it was possible or easy to do it.

Regards,

-- 
Nicolas Mailhot

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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Matthew Miller]

On Mon, Jul 22, 2013 at 04:40:14PM +0200, drago01 wrote:
> > Whenever I go to a tech meetup or talk to someone from a new startup
> > company, their developers are inevitably using a different (usually
> > proprietary) desktop OS, plus a non-Fedora distribution on their code.
> > We're being left behind and left out. It doesn't matter how
> > theoretically great we are if we end up with no users.
> I don't see how your proposal solves any of those issues. You are
> actually splitting Fedora into multiple
> distributions which makes it even worse (more fragmentation, not
> really something you can target etc etc).

Right now, we have a unified system which we pretty much guarantee cannot be
targeted at all. It's moving too fast at every level.

This proposal is for a solid core which can be targeted by software stacks,
which can be targeted by developers.

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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Miloslav Trmač]

On Mon, Jul 22, 2013 at 3:38 PM, Matthew Miller
 wrote:
> This is a draft of the proposal I'm presenting at Flock, "An Architecture
> for a More Agile Fedora" ().
(The more high-level comment.)

This essentially explicitly gives up on the idea of "Fedora" or,
implicitly, "Linux" as a "platform"^W/"deployment target"/"ecosystem"
== "something you write applications for", and replaces it with,
basically "the kernel+libc that other deployment targets/ecosystems
can use to run".

It gives up on "Fedora" or "Linux" as a general competitor to Windows;
Fedora becomes "just one of the commodity systems one can run Rails
4.0.x/Rails 3.2.x/node.js/JBoss/GNOME OS on".


We've been slowly and silently moving in the proposed direction of
comparatively fragmented and independent ecosystems for some time,
just because there wasn't a consensus on doing the opposite.  We do
have a choice of the direction, however.

Should we, do we want to, (and even, can we at all) get this project
on the same page behind a single coherent Fedora operating system
(from the users' point of view) and deployment target / API (from the
developers' point of view)?  Or are we already "doomed" into
supporting the fragmenting ecosystems best as we can?
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Nicolas Mailhot]

Le Lun 22 juillet 2013 18:36, Lennart Poettering a écrit :
>  There's
> nothing special really about cron that would make it so much better
> suitable for sending out its logs per mail, rather then just log them.

What makes cron and smtpd work well together is that they both perform
async background computing. And many cron messages are not "logs" they're
notifications of an event the cron is polling for, or submission of job
results.

-- 
Nicolas Mailhot

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

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/22/2013 11:34 AM, Bruno Wolff III wrote:
> On Mon, Jul 22, 2013 at 11:27:08 -0400, Matthew Miller
>  wrote:
>> 
>> Running two instances to get two sets of services has been the
>> best practice since about 1995. :)
> 
> When you have money. For hobbiests that may not always apply.

Virtualization (especially free virt in the OS, like KVM) has pretty
much trivialized that concern.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHtUn4ACgkQeiVVYja6o6NKogCgqv+N73c7LVcz3e4kesJdQO0I
OoQAn3eat8HnuBKodbCsJ8SsMp6T6LxV
=n3eN
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel