Re: Proposed F19 Feature: Fedora Upgrade - using yum

[Bill Nottingham]

Miroslav Suchý (msu...@redhat.com) said: 
> On 01/23/2013 07:50 PM, Lennart Poettering wrote:
> >The thing is that doing on-line updates only works for stuff you can
> >restart, and that doesn't mind that things are not atomically
> >updated. However, much (most?) of our code isn't like that. Anybody who
> 
> What could not be restarted? And what we can do to fix that?
> 
> If this work for Debian/Ubuntu, why it could not work for Fedora?

Essentially, the idea of a major release is to do the sorts of upgrades
that don't work cleanly on a running system. Examples would be:

- mysql database version upgrade (or similar upgrades that require
  a format conversion)
- switching out the system python interpreter version
- switching from a static /dev to udev
- switching init systems
- switching a script from being sysv to being a systemd service
- refactoring of a systemd service if necessary
- /usr move
- introduction of changes that require a new kernel subsystem mount
  point, or the move of one (/selinux to /sys/fs/selinux, for example)

None of these things are things that will work perfectly reliably in an
on-line upgrade mechanism.

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

Re: Start of systemd timers after install/update of a package

[Bill Nottingham]

Tomas Mraz (tm...@redhat.com) said: 
> On Thu, 2013-01-24 at 16:03 +0100, Jochen Schmitt wrote: 
> > Hello,
> > 
> > I have tried to migrating the cron jobs of the inn package to systemd 
> > timers.
> > Unfortunately, I have got the following problem. After a install/update of 
> > the
> > package the timer will only start the service unit only once time. The 
> > service
> > was not started after the configure period was expired. But when I have 
> > restart
> > the system, it's works as expected.
> > 
> > So I would to ask, what I have to concern when I want to migrate to systemd 
> > timers.
> 
> I think that massive migration of services from cron to systemd timers
> is very premature and should be actively at least discouraged by
> packaging directives.

I'm somewhat skeptical of the benefit of migration in general. I'm really
skeptical that the place you start reducing the dependency load is inn. 

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

Re: Proposed F19 Feature: MEMSTOMP

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/MEMSTOMP =
> https://fedoraproject.org/wiki/Features/MEMSTOMP
> 
> Feature owner(s): Jeff Law 
> 
> Include the MEMSTOMP DSOs in Fedora 19 to enable developers to more quickly 
> detect certain library calls which result in undefined behaviour due to 
> overlapping memory arguments.
> 
> == Detailed description ==
> MEMSTOMP is a DSO which can be preloaded by an application to detect calls to 
> library routines with overlapping memory arguments. Specifically MEMSTOMP 
> will 
> detect calls to the following routines with overalapping memory arguments:
> 
> [w]memcpy, str[n]cat, wcs[n]cat, str[n]cpy, wcs[n]cpy, [w]mempcpy, memccpy, 
> stp[n]cpy
> 
> While valgrind can detect these cases, using a DSO such as MEMSTOMP can be 
> significantly faster.
> 
> The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited 
> to the backtrace code which is not thread safe and may need to be 
> disabled/rewritten. 

I assume this could be done as a system-wide LD_PRELOAD if desired?

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

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Orion Poplawski (or...@cora.nwra.com) said: 
> I'm not trying to disparage this work, it seems reasonable (although
> I've been bitten by a lot of crappy software assuming network
> devices are named eth#, but it's able to be turned off, so meh).

We went through most of the things we shipped back when biosdevname was
first introduced and filed a *lot* of bugs to get all those cases fixed,
so we *should* be much better there. (Can't speak to third-party software,
obviously).

If any of those fixes involved merely adding the biosdevname namespaces to
whitelists instead of properly getting device names, well, I'm not
*supposed* to promote an attitude of violence, but...

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

Re: Proposed F19 Feature: MEMSTOMP

[Bill Nottingham]

Chris Adams (cmad...@hiwaay.net) said: 
> Once upon a time, Bill Nottingham  said:
> > Jaroslav Reznik (jrez...@redhat.com) said: 
> > > The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is 
> > > limited 
> > > to the backtrace code which is not thread safe and may need to be 
> > > disabled/rewritten. 
> > 
> > I assume this could be done as a system-wide LD_PRELOAD if desired?
> 
> I would guess that "the backtrace code which is not thread safe" would
> mean you couldn't safely do it system-wide.

Well, it's already killing the process at that point - I assumed he meant
that the backtrace would be unreliable in the presence of threads.

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

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Matthew Miller (mat...@fedoraproject.org) said: 
> > But I guess we simply have a different definition of a user here. Your
> > definition is probably closer to what the page calls "admins", which is
> > covered by the next lines in the feature page, which you didn't paste:
> 
> Right. For Fedora, developers and admins are an important subset of users.
> 
> > "As biosdevname is installed by default ...  most administrators won't
> > see this either. "
> 
> If the new scheme really is better, we should suck it up and make the whole
> change. It'd be better to do what we can to make that transition easier --
> like using similar names were possible -- than to have a weird mixed state.

So, thinking - if we were to go this route, I think we'd want a clean
break, where we don't use biosdevname at all if we're using this.

The simplest way to do that would be:
- change biosdevname to not be installed by default
- enable these rules only on install, not on upgrade
both of which are pretty easily doable.

To quote the documentation, of the device name formats:

 * Two character prefixes based on the type of interface:
 *   en -- ethernet
 *   wl -- wlan
 *   ww -- wwan
 *
 * Type of names:
 *   o  -- on-board device index number
 *   s[f][d]   -- hotplug slot index number
 *   x-- MAC address
 *   ps[f][d] -- PCI geographical location
 *   ps[f][u][..][c][i]
 * -- USB port number chain

What concerns would people have with this naming? Off the top of my head:

- wwan devices aren't always discoverable (they can show up as ethernet)
- devices that biosdevname considers emX via enumeration/guessing would
  now have enpXsY, which could be considered 'uglier'

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

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Miloslav Trmač (m...@volny.cz) said: 
> On Wed, Jan 23, 2013 at 8:59 PM, Jaroslav Reznik  wrote:
> > = Features/SystemdPredictableNetworkInterfaceNames =
> > https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames
> >
> > Feature owner(s):  Kay Sievers 
> >
> > The udevd service has a long history of providing predicatable names for 
> > block
> > devices and others. For Fedora 19 we'd like to provide the same for network
> > interfaces, following a similar naming scheme, but only as fallback if not
> > other solution such as biosdevname is installed or the administrator 
> > manually
> > defined network interface names via udev rules or the old network scripts.
> 
> 71-biosdevname.rules only handles KERNEL=="eth*"; so am I correct that
> it doesn't affect "wlan*" names at all?
> 
> If "wlan*" is not controlled by biosdevname, what happens to them in
> this proposal in the default installation?  Will they remain unchanged
> because biosdevname is installed, or will they be changed because
> biosdevname doesn't assign them a name?

The latter.

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

Re: Proposed F19 Feature: Fedora Upgrade - using yum

[Bill Nottingham]

Lennart Poettering (mzerq...@0pointer.de) said: 
> I'll wait your patches for the kernel to allow seamless upgrades of the
> kernel without reboots.

Sure, just have a ksplice server that generates splices for each new kernel
build relative to the previous one, and your upgrade process downloads all of
the series of splices and applies them. Voila!

The ksplice series from 2.6.18 to 3.7 will be loads of fun.

Bill

(NOTE: THIS IS NOT A SERIOUS IDEA.)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Oron Peled (o...@actcom.co.il) said: 
> IMO, my following proposal is only feasible if (and it's a big iff),
> the number of system calls and library functions that accept a network
> interface name is not large [things like if_nameindex(), the "ifreq" 
> ioctl()'s, etc.]
> 
> If that's the case, we can map "predictable" names to traditional ones
> in user-space, on the entry to said library functions, or entry
> to the said glibc syscall wrappers.

The problem is that explicitly because network devices have never been
enumerable in /dev before, every single utility does it themeselves.
Mostly by trawling /sysfs these days, but still... attempting to move
to an alternate naming scheme library could/would break everything that
only knows how to enumerate the kernel devices.

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

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Jiri Popelka (jpope...@redhat.com) said: 
> On 01/25/2013 04:25 PM, Marcela Mašláňová wrote:
> >I agree. The scope says no impact, but who knows how many packages
> >depend on hardcoded names.
> 
> I hope most of them has been already fixed with
> https://bugzilla.redhat.com/show_bug.cgi?id=682334

We could certainly explode and scan the code again if need be.

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

Re: stop service ; remove some files ; start service in RPM %postun ?

[Bill Nottingham]

Jan-Frode Myklebust (janfr...@tanso.net) said: 
> I have an rpm package where I need to stop the running service, remove
> some files and start the service again depending on which package
> version was already installed. I assume I need to do this in %postun,
> where we normally do condrestart, but I don't know how to check the
> version of the previously installed package. Could someone help me
> here / does anybody have examples doing something similar ?
> 
> For sysv-init i guess it should be trivial to check "service $name
> status" to see if it was running, and then stop/start it. But what's
> the equivalent for systemd ? Currently I use
> %systemd_postun_with_restart, but that needs to be split up so that I
> can delete the files while the service is down..

I'm curious - why would you need to do this? Seems somewhat fragile to 
be doing automatically on upgrade.

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

Re: Proposed F19 Feature: GLIBC 2.17

[Bill Nottingham]

Florian Weimer (fwei...@redhat.com) said: 
> See 
> for code snippets to implement in the change in a
> backwards-compatible fashion.  Unfortunately, glibc upstream
> insistent on renaming before making the symbol official.

I'm a little confused by the 'unfortunately' here - if apps are using a
private symbol, they should expect that they may need to change later.

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

Re: Proposed F19 Feature: High Availability Container Resources

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/ High Availability Container Resources =
> https://fedoraproject.org/wiki/Features/High_Availability_Container_Resources
> 
> Feature owner(s): David Vossel  
> 
> The Container Resources feature allows the HA stack (Pacemaker + Corosync) 
> residing on a host machine to extend management of resources into virtual 
> guest instances (KVM/LXC). 
> 
> == Detailed description ==
> This feature is in response to the growing desire for high availability 
> functionality to be extended outside of the host into virtual guest 
> instances. 
> Pacemaker is currently capable of managing virtual guests, meaning Pacemaker 
> can start/stop/monitor/migrate virtual guests anywhere in the cluster, but 
> Pacemaker has no ability to manage the resources that live within the virtual 
> guests. At the moment these virtual guests are very much a black box to 
> Pacemaker.
> 
> The Container Resources feature changes this by giving Pacemaker the ability 
> to reach into the virtual guests and manage resources in the exact same way 
> resources are managed on the host nodes. Ultimately this gives the HA stack 
> the ability to manage resources across all the nodes in cluster as well as 
> any 
> virtual guests that reside within those cluster nodes. 

Does this require the management to live on the virtual host, or can it be
done entirely remotely with the cluster management server residing elsewhere
and talking to all the virtual guest instances directly?

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

Re: Proposed F19 Feature: Simplify Java/Maven Packaging using XMvn

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/XMvn =
> https://fedoraproject.org/wiki/Features/XMvn
> 
> Feature owner(s): Stanislav Ochotnicky 
> 
> Introduce new Maven packaging tooling with new macros, automated install 
> section and more.

I would assume that, even with approval, there's no way to stage these
changes before the mass rebuild?

Does this also allow for automating/autogenerating a list of build provides?

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

Re: Proposed F19 Feature: Developers Assistant

[Bill Nottingham]

Michael Scherer (m...@zarb.org) said: 
> Le lundi 28 janvier 2013 à 15:27 +0100, Jan Zelený a écrit :
> 
> > 
> > Currently we are working on some proof-of-concept stuff. But as an example, 
> > you 
> > can imagine a script for creation of C program templates. You will specify 
> > directory where it should create the program and (possibly) some specifics, 
> > like "I want to use threads" or "I need glib support".
> > 
> > On output of that script you will have a template of C program with 
> > Makefile 
> > and you can start coding right away, no need for preparing the environment 
> > first.
> 
> Something like https://wiki.ubuntu.com/Quickly ?
> 
> Some work have been started by Mathieu bridon and Didier Roche for
> quickly on Fedora a few years ago. Not sure where it went, but this
> would be easier to use it rather than start from scratch.

Do we know whether our target users for these quick-onroad scripts are using
the commandline vs something like Eclipse? Just curious where the
bang-for-the-buck is.

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

Re: Proposed F19 Feature: OpenAttestation

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/OpenAttestation =
> https://fedoraproject.org/wiki/Features/OpenAttestation
> 
> Feature owner(s): Gang Wei  
> 
> Provide fedora packages for OpenAttestation to support Trusted Compute 
> Pools(TCP) feature in OpenStack since Folsom release & in future oVirt 
> releases. 

Wow, TCP is a horribly unfortunate acronym collision.

> == Detailed description ==
> This feature would include mostly packaging OpenAttestation project for 
> fedora.
> 
> * the source package will be named oat
> * the binary packages will include oat-appraiser & oat-client 

If you're attempting to create a framework that attests the integrity
of systems for use by 'trusted' software, it would (in theory) only be as
secure as its weakest link. Given that... PHP?

How does it intend to attest the OS in a rapidly updating Fedora environment?
Just the kernel + initramfs? An image-based checksum such as what is used in
ChromeOS?

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

Re: Proposed F19 Feature: Simplify Java/Maven Packaging using XMvn

[Bill Nottingham]

Stanislav Ochotnicky (sochotni...@redhat.com) said: 
> > I would assume that, even with approval, there's no way to stage these
> > changes before the mass rebuild?
> 
> There's too many packages I guess. It's likely we won't be able to transition
> *all* packages. If we manage to convert core let's say 300-400 I'll be happy 
> and
> consider this all a success since that will mean we'll test the code in most
> possible situations.
> 
> Some simple packages could be converted automatically, but verification might
> actually ake longer than just doing it manually :-)

OK. Do we have an examples of 'common things you might need to know to
migrate your packages', 'how to verify your migrated package', etc? (Then again,
if it's just going to be a few people in the Java SIG doing most of the 
migrations,
it may not be necessary.)

> At this point I'm happy with automatic requires (which will likely keep us
> occupied to make sure unnecessary stuff doesn't creep in everywhere)

Nah, that never happens! :)

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

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Miloslav Trmač (m...@volny.cz) said: 
> >> That's always the hope, and then we meet the cold reality, where someone
> >> just patched 'em1' into everything and hoped that was good enough. But
> >> sure, 'damn the torpedoes' is a viable approach too. I guess I was just
> >> kind of hoping F19 would be a release without yet more churn in the core
> >> system where we could try and stabilize things a bit.
> >>
> > I agree. The scope says no impact, but who knows how many packages depend on
> > hardcoded names.
> 
> It's not only "em1" mistakenly hard-coded in applications; it's user's
> saved configuration, scripts etc., where often there is no practical
> alternative to "hard-coding".

I would assume that it would only be for new installs, not for upgrades.

It might be worth considering that we keep the one special case and
change the 'eno' prefix in udev to 'em'... this will help some.

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

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Tomasz Torcz (to...@pipebreaker.pl) said: 
> > It might be worth considering that we keep the one special case and
> > change the 'eno' prefix in udev to 'em'... this will help some.
> 
>   This could be dangerous.  If I understand right, there is not guarantee
> "em1" would become "eno1" in 100% of cases.  Iptables saved config would
> still need to be checked and verified.

It won't, but having it be the same in the case where it *does* have
the same idea as biosdevname of 'first embedded interface', it could be
useful to have the same name.

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

Re: Proposed F19 Feature: AnacondaNewUI Followup

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> * Make system-config-kickstart work again. The removal of 
> iw/GroupSelector.py from anaconda caused it to break. (#859928)

Is this via replacing s-c-ks with anaconda itself, pulling the package
selection spoke into s-c-ks, or...?

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

Re: Proposed F19 Feature: systemd features

[Bill Nottingham]

Miloslav Trmač (m...@volny.cz) said: 
> Some years ago all hardware data was moved out of various separate
> packages into the "hwdata" package (even if it meant moving it out of
> the original upstream source).  The feature page doesn't even mention
> the hwdata package.  AFAICS this
> 
> 1) Duplicates the data.
>   1a) Will the two databases be kept in sync?  How will that happen?

It pulls from upstream at build time, from reading the code.

> 2) Breaks the hwdata-vs-code separation that was created earlier.
> What were the reasons of the separation, and why are they no longer
> applicable now?

It would be useful to be able to update this without updating systemd...
is there any reason the perl generator for this can't be moved to hwdata
itself and have *that* pull the upstream versions on build?

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

Re: Proposed F19 Feature: systemd features

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/SystemdMessageCatalog =
> https://fedoraproject.org/wiki/Features/SystemdMessageCatalog
> 
> Feature owner(s): Lennart Poettering 
> 
> Logging is essential for finding and tracking down system problems. Just 
> finding 
> and tracking them down however is seldom enough to actually get them fixed. 
> With Journal Message Catalogs we want to link helpful meta information 
> directly to many log messages applications generate, keyed off an ID 
> identifying the type of message. This localized meta information can help the 
> user to fix the problem, refer him to additional documentation, or even 
> inform 
> him where to get further help. 

This is interesting, in that it's a feature that's occasionally requested
by various users and administrators. However, this is rather limited in
that only systemd stuff is using it now, and it's tied to the journal API.

Do we know 1) if anything else is going to start tagging messages in this
way (the kernel, other programs, etc.) 2) if it's possible to set the
MESSAGE_ID in some other structured way?

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

Re: Proposed F19 Feature: Dracut HostOnly

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/DracutHostOnly =
> https://fedoraproject.org/wiki/Features/DracutHostOnly
> 
> Feature owner(s): Harald Hoyer 
> 
> Only create "host-only" initramfs images. A generic fallback image should be 
> installed by anaconda on installation/update and never ever be removed.  
> 
> == Detailed description ==
> Current initramfs images contain most of the kernel drivers to boot from any 
> hardware. This results in a very big initramfs, which takes a long time to 
> load on system start and a long time to create on kernel updates. Switching 
> to 
> host-only will improve the situation. To cope with hardware change, a boot 
> entry "Rescue System" should be installed with a full fledged initramfs also 
> containing debug tools. This boot entry can then be used to recover from 
> hardware changes and also from unforseen software failure after updates.

Do we actually have agreement on the anaconda/lorax side for the changes
required here?

What happens if the updated system (due to userspace, SELinux policy, what
have you) moves beyond something that can be properly rescued?

Will there be a fedup module to regenerate the rescue image on OS upgrade?

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

Re: Proposed F19 Feature: Enterprise / distributed two-factor authentication

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/EnterpriseTwoFactorAuthentication =
> https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication
> 
> Feature owner(s): Daniel Pocock 
> 
> Provide a flexible solution for two-factor authentication on a distributed 
> basis, suitable for enterprise and SSO. 
> 
> == Detailed description ==
> Most OTP solutions for two-factor authentication require some kind of storage 
> backend for counters or other volatile data. Early implementations work with 
> flat files on a single host. dynalogin was created to bring stability and 
> flexibility, storing counters in just about any type of database. Other 
> solutions such as totp-cgi have similar goals (although it only mentions 
> Postgres support, whereas dynalogin can use MySQL thanks to UNIXODBC). 
> dynalogin has been successfully integrated with the SimpleID provider for 
> OpenID authentication. 

I'd really prefer this be retitled in a way that more clearly defines what
it is (i.e., Add SimpleIDandDynalogin2FA). As you can see from the responses,
the definition of what is 'Enterprise' lies in the beholder.

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

Re: Proposed F19 Feature: Add LVM Thin provisioning support to the yum-fs-snapshot plugin

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/YumFsSnapshotThinpSupport =
> https://fedoraproject.org/wiki/Features/YumFsSnapshotThinpSupport
> 
> Feature owner(s):  Ondrej Kozina , Mike Snitzer 
> 
>  
> For the purposes of system rollback: Provide the ability to create a snapshot 
> of all thinly provisioned LVM2 volumes associated with FS mount points that 
> are relevant to a yum transaction. 
> 
> == Detailed description ==
> Yum's fs-snapshot plugin already has support for LVM2's old snapshots. LVM2's 
> new thinp snapshots offer much more performance and ease administration. It 
> is 
> desirable to have the life-cycle of snapshots that are created by yum's fs-
> snapshot plugin be managed by the snapper utility. As such it could be that 
> the yum fs-snapshot plugin is extend to provide a wrapper around snapper for 
> the creation of thinp based snapshots. 

Is this actually useful if anaconda doesn't set up the system to use the
thinp pool to begin with? (Because it doesn't.)

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

Re: Proposed F19 Feature: Trusted Network Connect (TNC)

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/Trusted Network Connect (TNC) =
> https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29
> 
> Feature owner(s): Avesh Agarwal  
> 
> This feature provides Trusted Network Connect(TNC) framework that can be used 
> to assess and verify clients' posture (or integrity measurements or 
> configuration) and its compliance to a predefined policy with existing 
> network 
> access control (NAC) solutions.

Is this intended to be integrated into NetworkManager?

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

Re: Proposed F19 Feature: systemd features

[Bill Nottingham]

Kay Sievers (k...@vrfy.org) said: 
> The hwdb is drop-in directory based, which means:
>   - additionally installed data overwrites shipped data
>   - stuff with the same file name in /etc/ disables stuff in /usr/lib/
> 
> Users can just install update packages, or add their own files, which
> will not conflict with the default shipped data.

That's really not what we need, though - we have standing requests
in That Other OS for regular updates of the hardware database as used
by the tools, and having to spin systemd for this is way overkill.

> > 1) Duplicates the data.
> >   1a) Will the two databases be kept in sync?  How will that happen?
> 
> No. In the long run the old textual files will no longer be used. It
> was a really bad idea from the start to parse several megabytes of
> ever-growing text files for every query submitted; it was showing up
> as CPU spikes in all sort of profiles. That model of implementing
> low-level operating system tools should just not be continued in the
> future. The systemd hwdb data can be queried almost for free.

Realistically, it's new textual files, replacing old textual files, which
are then compiled into a binary file. I'm not sure why there's the
intermediate step of a second textual format, but there is.

> > 2) Breaks the hwdata-vs-code separation that was created earlier.
> > What were the reasons of the separation, and why are they no longer
> > applicable now?
> 
> It's just not needed because of the /usr/lib/ etc/ and drop-in
> directory overwrite logic, that works for all other default vs.
> custom/update settings.

That method implies the administrator wants to do the update without
touching the code - what we have now is the *distributor* wants to
do the update without touching the code. And for that case, packaging
it seperately is simpler.

> It could go into another package when things have settled down, but
> there will be lots of other data in the same database shipped by
> systemd itself, like keymaps, power settings whitelists, which we
> cannot really and should not move out to a generic package.

... which, again, is not something you want to be updating the main
systemd package all the time for.

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

Re: Proposed F19 Feature: Trusted Network Connect (TNC)

[Bill Nottingham]

Avesh Agarwal (avaga...@redhat.com) said: 
> >Is this intended to be integrated into NetworkManager?
>
> There is no such plan with this feature as right now the focus is to
> get the functionality right, but this is something that may be done
> in future fedora releases.

Given that NM is the networking stack by default, and the traditional
network scripts have no support for wpa_supplicant... how is this supposed
to work out of the box, then?

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

Re: Proposed F19 Feature: systemd features

[Bill Nottingham]

Kay Sievers (k...@vrfy.org) said: 
> > Realistically, it's new textual files, replacing old textual files, which
> > are then compiled into a binary file. I'm not sure why there's the
> > intermediate step of a second textual format, but there is.
> 
> Because the original text file is a hack and a format specific to the
> PCI/USB IDs, and makes no sense at all for a generic hwdb.

pci:v0010*
 ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc

It's not like that's that much more of a generic format. :)

> >> It could go into another package when things have settled down, but
> >> there will be lots of other data in the same database shipped by
> >> systemd itself, like keymaps, power settings whitelists, which we
> >> cannot really and should not move out to a generic package.
> >
> > ... which, again, is not something you want to be updating the main
> > systemd package all the time for.
> 
> Which, again, is not needed at all, as mentioned above. :)

Is it strictly needed? No.

Is it needlessly making the problem worse? Yes.

Either you're intending for the lifetime of your OS to be shipping systemd
updates that update the base data set, or you're intending to be shipping
updated data sets in a separate package. Given systemd's churn rate, the
first seems impractical, and if you're doing the second, why not split it
out to begin with? (Much like the preset files.)

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

Re:

[Bill Nottingham]

G.Wolfe Woodbury (redwo...@gmail.com) said: 
> > The kernel nowadays comes with built-in support for the vast majority of
> > all common storage hardware anyway, because AHCI is pretty universally
> > established. Outside of servers non-AHCI controllers practically don't
> > exist anymore.
> 
> This is simply not true.
> 
> There are hundreds of thousands of older desktops that are not
> technically servers that have lots of older interfaces.
> 
> To say that non-AHCI controllers don't matter is to place a dignificant
> barrier to use or adoption of Linux or Fedora.

AHCI dates to before when RHEL 5 was released in 2007. We also build
in ATA_PIIX, which covers a large number of generations before that.

Does hardware exist that's not covered by this? Of course. However,
I'd also bet that those installing Fedora on that hardware are those
that are capable of rebuilding an initramfs if they move an existing
system to such hardware.

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

Re: Proposed F19 Feature: Trusted Network Connect (TNC)

[Bill Nottingham]

Avesh Agarwal (avaga...@redhat.com) said: 
> >Right now it is done using wpa_supplicant provided cli.
>
> Just to clarify a little bit further, wpa_supplicant provided cli
> takes care of authentication and tnc's end point assessment. Once it
> is done, NM or network scripts takes care of setting up networking
> as usual. I have not checked if the current support of
> wpa_supplicant in NM is enough for this.

My concern is with it being something that has to be massaged on the
commandline by hand. I'm not sure it should be presented as a 'Feature'
to the users if it's not integrated into how the system normally works.

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

Re: Proposed F19 Feature: systemd features

[Bill Nottingham]

Kay Sievers (k...@vrfy.org) said: 
> > Either you're intending for the lifetime of your OS to be shipping systemd
> > updates that update the base data set,
> 
> I don't intend to ship update packages in the context of systemd, we
> can just update the data in the package like we add patches for other
> fixes, in case we need an update. In the end PCI+USB IDs are just
> pretty boring names for humans, not used in the system itself. What
> makes them so special? It really sounds more like cosmetic care, than
> a real technical need to update these more often than we will need to
> update systemd anyway.
> 
> > or you're intending to be shipping
> > updated data sets in a separate package.
> 
> We can just do that, but still could ship the default data in the main 
> package.

Would we be moving the other data to this model as well? I note that in
F18 we ended up building systemd many many times just to update keymap
conversions; it's wasteful in terms of builds and updates for users to be
updating all of systemd just to add a new French keymap conversion, or
to add a quirk just for some new laptop.

The point is, we've done this in the past where we shipped the data with
the tools, and we very quickly moved to shipping the data separate - it's
cleaner, allows for just updating the data when necessary, and it forces
people to keep their API & ABI for accessing it stable. :)

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

Re: Proposed F19 Feature: Network Team driver - Update for new features

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/TeamDriverUpdate =
> https://fedoraproject.org/wiki/Features/TeamDriverUpdate
> 
> Feature owner(s): Jiri Pirko 
> 
> Network Team driver allows multiple network interfaces to be teamed together 
> and act like a single one. This update adds several kind of new features to 
> it.
> 
> == Detailed description ==
> The goal is to extend current Team driver experience in Fedora. In order to 
> do 
> that, following features will be implemented:
> 
> * ARP link validation over VLAN
> * Transmit hashing involving L4 headers
> * Support for NICs which do now allow mac change on run
> * Load balancing support for incoming traffic
> * Corrected carrier detection

These seem like reasonable changes for the team driver, but I'm not seeing
how this merits a full Feature compared to the feature for its initial
addition.

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

Re: Proposed F19 Feature: Developers Assistant

[Bill Nottingham]

Jan Zelený (jzel...@redhat.com) said: 
> I've already started to work on that as well. Currently I'm putting together 
> topics from Fedora wiki that are eligible to be on such page, either as they 
> are or with some (rather minor) modifications.
> 
> I'd like them to be structured, easy to comprehend and most importantly as 
> short as possible.
> 
> If you know any such topic, feel free to let me know.

Does this go all the way into "libraries you should use" and "libraries you
shouldn't"?

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

Re: Proposed F19 Feature: Dracut HostOnly

[Bill Nottingham]

Miloslav Trmač (m...@volny.cz) said: 
> On Tue, Jan 29, 2013 at 4:53 PM, Dennis Gilmore  wrote:
> > even loading a 20mb initramfs from a sdcard on a slow
> > arm box doesnt take that long, and id personally much rather be able to
> > change hardware or yank the drive  and put it into a different box
> > without worrying about making sure i have the right initramfs bits in
> > place. at least to me the costs outweigh the benefits. the grub timeout
> > on my laptop/desktops is longer than the time it takes to load the
> > initramfs.
> 
> This actually suggests a different way to achieve the same result:
> Teach grub to preload the kernel and initrd while waiting for the
> timeout.  That gives us _even better_ speedup, and doesn't sacrifice
> the generic usability of the initrd.

Well, if the plan is to not timeout, that won't help. But it could be
interesting. Although, everything I've heard about the grub code makes
me entirely concerned when something that amounts to 'introduce threads'
is suggested.

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

Re: Proposed F19 Feature: systemd features

[Bill Nottingham]

Marcela Mašláňová (mmasl...@redhat.com) said: 
> I would say that work even before. If I should say according to
> number of bugs, not many users were using specific SElinux contexts
> for cronjob tasks.
> 
> No objection to this feature, it might be very powerful for some
> use-cases. I'm afraid of situation, when half of cronjobs will be
> converted and half stay as is. Poor admins.

So, here's where policy could be helpful. What should and shouldn't migrate?

Right now, it's used by:
- systemd itself (obviously OK)
- mrtg (optionally, not by default - in fact, this whole service is kind of
  a mess)
- inn (eh)

Current cron users are:
afraid-dyndns
amavisd-new
apt
arm4
atop
autotrust
awstats
backup-manager
bcfg2
cacti
checkdns
clamav-unofficial-sigs
clamav-update
clement
cronie
cronie-anacron
cronie-noanacron
crontabs
crypto-utils
cyrus-imapd
dbmail
denyhosts
dmraid-events-logwatch
dnf
drupal6
drupal7
dspam
dwatch
epylog
etckeeper
exim
exim-greylist
fetch-crl
freeipa-server
ghc-compiler
globus-gram-audit
glpi
glpi-mass-ocs-import
hplip
hylafax+
indefero
leafnode
libvirt-sandbox
lightsquid
limph-hostagent
logcheck
logrotate
logwatch
ltsp-server
mailman
man-db
mcelog
mdadm
mldonkey-server
mlocate
moodle
munin
newscache
nordugrid-arc-gridmap-utils
nsd
ocsinventory-agent
olpc-update
opendnssec
openshift-origin-cartridge-cron-1.4
openshift-origin-msg-node-mcollective
openvas-scanner
ovirt-engine
ovirt-node
PackageKit-cron
pam_shield
polipo
prelink
queuegraph
rancid
rkhunter
rpm-cron
safekeep-server
sagator-core
sipwitch
slrn-pull
spamassassin
squidGuard
squirrelmail
subscription-manager
sysstat
system-autodeath
sysusage
tmpwatch
tripwire
unbound-libs
vdsm
vdsm-reg
vnstat
webacula
webalizer
WebCalendar
x509watch
yum-cron
zfs-fuse

I would be tempted to say:
  "Anything running at a core system level where a dependence on a separate
cron daemon may be unwanted (or a bad idea) should be migrated, and nothing
else for now until we have a clearer perspective on the future."

Given that list that would be migration of:
mcelog
mdadm
ovirt-node
prelink (?)
tmpwatch
vdsm-*

But I'm open to other ideas.

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

Re: Proposed F19 Feature: systemd features

[Bill Nottingham]

Colin Walters (walt...@verbum.org) said: 
> On Tue, 2013-01-29 at 14:30 -0500, Bill Nottingham wrote:
> 
> > This is interesting, in that it's a feature that's occasionally requested
> > by various users and administrators. However, this is rather limited in
> > that only systemd stuff is using it now, and it's tied to the journal API.
> 
> Actually, we're using it in GNOME too:
> 
> http://git.gnome.org/browse/gnome-session/commit/?id=9ec4deede968ad55d18340109c5aa9f6416de13d

Looking at this in the current implemenation...

I understand that this doesn't work unless everything is documented. But...

Jan 30 22:07:01 nostromo.devel.redhat.com systemd[1]: Starting Sendmail Mail 
Transport Client...
-- Subject: Unit sm-client.service has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation:
-- 
http://www.freedesktop.org/wiki/Software/systemd/catalog/7d4958e842da4a758f6c1cdc7b36dcc5
-- 
-- Unit sm-client.service has begun starting up.

... this is a really verbose way of adding no additional information.
Similar example here:

Jan 31 09:22:15 nostromo.devel.redhat.com systemd-sleep[4298]: System
resumed.
-- Subject: System sleep state suspend left
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation:
-- 
http://www.freedesktop.org/wiki/Software/systemd/catalog/8811e6df2a8e40f58a94cea26f8ebf14
-- 
-- The system has now left the suspend sleep state.


Jan 31 09:22:15 nostromo.devel.redhat.com systemd[1]: Time has been changed
-- Subject: Time change
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation:
-- 
http://www.freedesktop.org/wiki/Software/systemd/catalog/c7a787079b354eaaa9e77b371893cd27
-- 
-- The system clock has been changed to REALTIME microseconds after January
-- 1st, 1970.

A substitution bug! (Unless it's really supposed to reference a
meta-variable that isn't part of the message).

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

Re: Proposed F19 Feature: Developers Assistant

[Bill Nottingham]

Jan Zelený (jzel...@redhat.com) said: 
> > Does this go all the way into "libraries you should use" and "libraries you
> > shouldn't"?
> 
> Well, that's slightly advanced topic but I think we can arrange something 
> like 
> advanced section on the Developers' portal.
> 
> Is this already somewhere on the Fedora wiki?

No, it would be useful information to have.

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

Re: Command line arguments depend on locale

[Bill Nottingham]

Simo Sorce (s...@redhat.com) said: 
> > You should *always* set LC_ALL=C when running an external command from
> > another program (and most probably from a shell script too).
> 
> Except when you shouldn't ...
> 
> If you are getting arguments that are locale dependent changing the
> locale will do you more harm than good, so now you need to parse
> arguments before changing locale, assuming you know what the locale of
> the arguments is and how to translate them to the C locale.
> 
> System commands should probably not change their syntax based on locale.
> Ping can very well document that the -i argument takes an interval using
> C locale and not do locale dependent parsing. It would be much more
> robust and if you are good enough to use the -i switch you probably know
> how to type 0.1 instead of 0,1 (or whatever format is in your locale) as
> well.

Right, output should be locale specific. Input command line args... seems
specious.

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

Re: Command line arguments depend on locale

[Bill Nottingham]

Matthias Clasen (mcla...@redhat.com) said: 
> - Original Message 
> > 
> > Right, output should be locale specific. Input command line args...
> > seems
> > specious.
> 
> Until you put a pipe between and turn the outputs of command a into inputs of 
> command b...

But, as said earlier, it's common admin practice to use LC_ALL=C for
command pipes and screenscraping. It's certainly not (at least, I thought)
common practice that they need to do this for things they pass on
the command line.

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

Re: Proposed F19 Feature: Apache OpenOffice

[Bill Nottingham]

Martin Sourada (martin.sour...@gmail.com) said: 
> > I'm an Ambassador and this proposal is confusing me.
> > We have LibreOffice in our repositories; I think that bring back
> > Apache OpenOffice generates only confusion between users, not freedom
> > of choice.
> > 
> The confusion is already there in Windows world, linux user should be
> more capable of treating it as freedom of choice instead of confusion.
> Also, since Apache took over OpenOffice.org and put it out of
> incubation, it seems the development has been progressing rather well
> and in a different direction than LibreOffice. While both started from
> the same point, they're going to be different office suites with
> different feature sets, different UIs, different devs, etc.
> 
> I think it's beneficial to provide Fedora users with the choice of
> installing either, or even both, provided there's enough interest
> among the devs to make it so. From a user point of view, I think the 
> main manpower for F19 should go into getting it into repos and solving 
> *all* conflicts. They should be parallel installable and should not
> conflict even at runtime with each other. Especially the runtime
> conflicts would be really confusing to (some of) our users.

Oh, geez, 'choice' again.
 (c.f. http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html)

I mean, if someone wants to package AOO, more power to them, I guess. But
the idea that having a random user who says "hey, I need to edit an office doc"
should choose between LibreOffice and AOO (and Abiword, and Scribus, and 
Calligra,
and ...) when they don't have the information in front of them to make that
decision in a coherent fashion is not what I think we should be doing, any
more than dropping unfamiliar users to a screen where they pick between
GNOME/KDE/Cinnamon/MATE/XFCE/LXDE/Blackbox/WindowMaker/Sawfish/E17/TWM is
a good idea. 

It feels like designing a system for people who choose and compare software,
as opposed to desinging a system for people to *use* software. Pick a set
of defaults and make them great - don't punt it all to the user.

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

Re: Proposed F19 Feature: NetworkManager Bridging Support

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Features/NetworkManagerBridging =
> https://fedoraproject.org/wiki/Features/NetworkManagerBridging
> 
> Feature owner(s):  Pavel Šimerda , Dan Williams  at redhat dot com> 
> 
> NetworkManager should be able to configure bridge interfaces with commonly 
> used 
> options and recognize their existing configuration on startup without 
> disrupting their operation.
> 
> == Detailed description ==
> A bridge connects two or more physical or virtual network interfaces to allow 
> network traffic to flow between the two interfaces at a low level. Bridging 
> is 
> commonly used to connect Virtual Machines to the outside world; a bridge 
> interface is created, to which a physical interface (typically ethernet) is 
> assigned as a slave, and a virtual interface (typically TAP) is created and 
> also assigned to the bridge as a slave, and then given to the Virtual 
> Machine. 
> Thus traffic from one or more VMs can be combined and sent out of the machine 
> via the physical interface.
> 
> This setup is currently done either manually using ifcfg files and 
> ifup/ifdown, 
> or by a tool like libvirt/netcf. NetworkManager should be able to configure 
> bridge interfaces and their slaves with the same functionality as provided by 
> libvirt, and should recognize and not disrupt existing bridge connections 
> when 
> it starts up. 

This (and the bonding feature) could stand to be more clearly stated how it
differs from http://fedoraproject.org/wiki/Features/NMEnterpriseNetworking.
From reading it, it implies that it's making the configuration of them
first-class NM citizens throughout NM's interfaces, as opposed to just
handling manually configured ones.

Bill


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

Re: polkit changes in f19

[Bill Nottingham]

Peter Robinson (pbrobin...@gmail.com) said: 
> On Thu, Jan 31, 2013 at 6:57 PM, Matthias Clasen  wrote:
> > I just realized that there is a change to the way polkit is packaged in f19 
> > that spin maintainers should be aware of: the polkit package is just the 
> > service, which only provides the default policy as specified in the action 
> > definitions now. If you want or need support for js rules, you need to pull 
> > in the polkit-js-engine package. I've just made this change for the desktop 
> > spin.
> 
> It would probably have been useful if you'd emailed the spins list
> about there changes.

Probably got lost b/c the change was made in F-19 in November. Oops.

> Also is there any documentation as to why we'd need the
> polkit-js-engine what functionality it provides, and more importantly
> what we'd lose by not including it?

That's what's used to process rules files (replacing .pkla files).
See the rules sections of
http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
for details. If you don't include it, you can't add/modify your own
rules.

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

Re: Proposed F19 Feature: OpenAttestation

[Bill Nottingham]

Wei, Gang (gang@intel.com) said: 
> > If you're attempting to create a framework that attests the integrity
> > of systems for use by 'trusted' software, it would (in theory) only be as
> > secure as its weakest link. Given that... PHP?
> 
> I am not sure whether PHP is the weakest link, but the integrity checking 
> done 
> by OpenAttestation is to ensure the system is running the expected software 
> like BIOS/OS/etc. As to whether the expected software is secure enough it is 
> another story.
> 
> > How does it intend to attest the OS in a rapidly updating Fedora
> > environment? Just the kernel + initramfs? An image-based checksum such
> > as what is used in ChromeOS?
> 
> By far, just kernel + initramfs. Every time the kernel/initramfs got updated, 
> the Know Good Value in OpenAttestation Server should be updated to take new 
> kernel/initramfs as "trusted" one.

Hm, I guess that's OK as far as the feature goes, but that doesn't give me
a lot of good feelings about the level of trust to ascribe to the
OS that's being booted by that kernel & initramfs.

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

Re: Proposed F19 Feature: systemd features

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johan...@gmail.com) said: 
> On 01/31/2013 03:51 PM, Bill Nottingham wrote:
> >I would be tempted to say:
> >   "Anything running at a core system level where a dependence on a separate
> >cron daemon may be unwanted (or a bad idea) should be migrated, and nothing
> >else for now until we have a clearer perspective on the future."
> >
> >Given that list that would be migration of:
> >mcelog
> >mdadm
> >ovirt-node
> >prelink (?)
> >tmpwatch
> >vdsm-*
> >
> >But I'm open to other ideas.
> 
> Am I supposed to assume you are working migrating this?

I was asked people to take a look at what the functionality can do, what
it may mean to migrate, and what we want to offer to our users, in the
short and in the long term.

The thing about migrating SysV services is that we didn't have to at
the start, and yet they'd still work, in systemd, without change.
(For the most part).

And admins could use the old tools adminms were used to in SysV land
(/sbin/service, chkconfig, etc) with systemd, and they'd work and
give them consistent output for both the native services, and the ones
they hadn't got around to migrating yet.

Here, while systemd has basically subsumed the functionality of
cron (minus user jobs), it hasn't subsumed any of the infrastructure -
there's no compat.

In any case, to look at 'we have this functionality... now what':

1) migrate some cron jobs

Then, system scheduled tasks are in two places. Admins can learn and
cope, and have to go looking in multiple places and remember which tools
to deal with which scheduled task type. It's not ideal. And if we do
so, it's good to have some clear criteria to help admins decide where
to find what they're looking for. You started working here - you
suggested 'ones that come with daemons/services', I looked, and
thought perhaps 'ones that live at a level below
everything else, including the ones below daemons and services'. It's
just different ideas as to where to draw the line.

But it's still not a great interface to have users end up in - two
infrastructures running in parallel.

2) migrate all

This is cleaner, inasmuch as we can tell everyone "hey, everything
is over here now". But it's still a full break of interfaces and
paradigms, and it easily devolves to #1 as soon as something doesn't
get done, or new stuff is added. (After all, we can't remove support
for cron-format jobs.)

3) introduce compatibility

The cron and at interfaces aren't complex at all. It shouldn't be
too hard to have a generator that reads crontab and cron.*, and
the at queue, and creates the approprate timer files for systemd,
in the same way that the fstab & sysv generators run. We could
even have new versions of the crontab and at commands that do the
right thing.

That's extra work that would need to be done, and we would
have to actually be obsoleting cron here (can't have two things
running the same jobs), so it's obviously not F19 material. We'd
also need a mechanism for user jobs. But if this is where we want
the system to end up, this is what we start working towards and
writing code for. Once that lands, transitioning can actually be
done much more smoothyl with less user disruption, and having
different jobs in different formats doesn't hurt nearly as much.

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

Re: Proposed F19 Feature: Virtio RNG

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> Feature owner(s): Cole Robinson , Amit Shah 
> 
> 
> Provide a paravirtual random number generator to virtual machines, to prevent 
> entropy starvation in guests.  
> 
> == Detailed description ==
> The linux kernel collects entropy from various non-deterministic hardware 
> events, like mouse and keyboard input, and network traffic. This entropy is 
> then 
> exposed through /dev/random, commonly used by cryptographic applications that 
> need true randomness to maintain security. However if more entropy is being 
> consumed than is being produced, we have entropy starvation: reading from 
> /dev/random will block, which can cause a denial of service. A common example 
> here is use of /dev/random by SSL in various services.
> 
> VirtIO RNG (random number generator) is a paravirtualized device that is 
> exposed as a hardware RNG device to the guest. Virtio RNG just appears as a 
> regular hardware RNG to the guest, which the kernel reads from to fill its 
> entropy pool. This effectively allows a host to inject entropy into a guest 
> via 
> several means: The default mode uses the host's /dev/random, but a physical 
> HW 
> RNG device or EGD (Entropy Gathering Daemon) source can also be used. 

What exactly feeds /dev/random in the guest in the cases where this doesn't
exist, and how do we cope with this obviously making /dev/random exhaustion
in the host much more likely? (Other than assume that a HW RNG is in the
host.)

Given FIPS paranoia about RNG sources, does this have knock-on effects in
the FIPS compliance of guests depending on how it's fed in the host?

Bill

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

Re: Proposed F19 Feature: Virtio RNG

[Bill Nottingham]

Matthew Garrett (mj...@srcf.ucam.org) said: 
> This patchset means that there's a /dev/hwrng available in the guest, so 
> you still need to run something like rngd to mix that into the kernel's 
> entropy pool.

Speaking of, why is it a thing that we need a separate userspace daemon
to dump data from kernel bucket A (/dev/hwrng) into kernel bucket B
(the entropy pool)?

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

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Matt Domsch (matt_dom...@dell.com) said: 
> The RHEL model of disabling biosdevname by some hardware
> vendors, at installtime, is not accounted for in the current proposal.

I find this model pretty broken - if we want to have clear semantics
that are easily explainable to users and admins, we don't want the
namespaces being used to be conditional on the hardware vendor (other
than insasmuch as they have proper information in their bios.) I know
how RHEL 6 did it, but that was a matter of expediency with late change.

> I agree, that's the right approach, which is why Dell pushed to get
> the SMBIOS and PCI specifications amended to put explicit per-device
> information into there.  I hope we can work together to do likewise
> for cases coming up now that aren't currently addressed.
> 
> If we can solve the installtime naming convention choice to not
> eliminate biosdevname, be able to disable systemd/udevd naming, and
> have the default be possible on a per-system-vendor basis, and solve
> the NPAR/SR-IOV/Mellanox naming problems, then I can support this
> proposal.  Without fixing these shortcomings though, my customers will
> have a fit at me.

If you're agreeing that biosdevname should be limited to type9/type41
(if I'm reading you right), and if the systemd/udev names still use those
fields, what parts of biosdevname are you still requiring? The actual
namespace used, or something else?

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

Re: Proposed F19 Feature (exception): Kolab 3

[Bill Nottingham]

Christoph Wickert (christoph.wick...@gmail.com) said: 
>  3. The feature submission deadline was poorly communicated. First
> the schedule was only preliminary, then it was finalized, but
> this changed not announced. The announcement about the final
> feature submission freeze was only one day before the actual
> freeze.

The feature submisson deadline was never preliminary. The schedule was
not finalized until after all features were submitted.

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

Re: 64-bit stat (or not) in 32-bit Fedora binaries

[Bill Nottingham]

Florian Weimer (fwei...@redhat.com) said: 
> On 02/18/2013 10:33 PM, Eric Sandeen wrote:
> 
> >XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let 
> >inode numbers creep past 2^32 as well.
> >
> >While most applications don't care one bit about st_ino returned from a 
> >stat() call, the sad fact is that you'll get EOVERFLOW from stat32 if the 
> >inode number is too big to fit in 32 bits, even if you just wanted to get 
> >the file size.
> >
> >I have a script (http://sandeen.net/misc/summarise_stat.pl) which Greg Banks 
> >wrote; it can check a path or list of filenames for binaries which contain 
> >non-64bit-safe stat calls.  A quick look over my F18 install finds the 
> >situation to be only slightly in favor of executables using 64-bit variants:
> 
> I ran a search for '__xstat', '__lxstat', '__fxstat' against current
> Fedora 18 (using https://github.com/fweimer/symboldb/) and found the
> attached list of packages.
> 
> There are 2179 packages which reference the 32-bit interfaces, 1375
> which reference the 64-bit interfaces, and 186 packages reference
> both.
> 
> If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes
> pretty close to an ABI bump.  But considering the numbers, I wonder
> if it's the right thing to do if we need to cope with 64-bit inode
> numbers.

It's kind of a shame we just did the mass rebuild, if we're
going to have to do part of it again if we change this.

Or we could just stop building 32-bit support.

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

Re: 64-bit stat (or not) in 32-bit Fedora binaries

[Bill Nottingham]

Miloslav Trmač (m...@volny.cz) said: 
> That would be very useful.
> 
> 1) Easy: run a script to find affected packages and auto-file bugs.
> 2) Fairly possible: get at least the important packages fixed in F19
> (or, 1+2: change default build configuration to cover most packages,
> and rebuild.)
> 
> 3) Difficult to do right now? set up an automated test to ensure new
> packages are also covered and there are no regressions.

4) What do we do with 3rd-party apps that now spontaneously fail and
we can't get them rebuilt?

(Not a huge concern for Fedora, but something we need to at least think
about so we can message it.)

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

Re: Schedule for Wednesday's FESCo Meeting (2013-02-20)

[Bill Nottingham]

Josh Boyer (jwbo...@gmail.com) said: 
> On Tue, Feb 19, 2013 at 7:39 PM, Miloslav Trmač  wrote:
> > Following is the list of topics that will be discussed in the FESCo
> > meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on
> > irc.freenode.net.
> >
> > Links to all tickets below can be found at:
> > https://fedorahosted.org/fesco/report/9
> 
> I'm going to be late to the FESCo meeting today.  I've voted in all of
> the tickets on the agenda, so that should hopefully cover everything.

I'm not going to be at the meeting, AFAICT. I put votes in all the tickets
as well.

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

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Matt Domsch (matt_dom...@dell.com) said: 
> On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote:
> > > If we can solve the installtime naming convention choice to not
> > > eliminate biosdevname, be able to disable systemd/udevd naming, and
> > > have the default be possible on a per-system-vendor basis, and solve
> > > the NPAR/SR-IOV/Mellanox naming problems, then I can support this
> > > proposal.  Without fixing these shortcomings though, my customers will
> > > have a fit at me.
> > 
> > If you're agreeing that biosdevname should be limited to type9/type41
> > (if I'm reading you right), and if the systemd/udev names still use those
> > fields, what parts of biosdevname are you still requiring? The actual
> > namespace used, or something else?
> 
> I'd prefer if we didn't force users through another namespace change.
> I took a lot of flack for changing the namespace once.  From their
> perspective, it's still udev doing the renaming, only now the code
> moved from a udev helper into udev itself.

True; the users likely don't care other than how they enable/disable it.

> I'd like to see the SR-IOV & NPAR devices handled.  Those aren't
> represented in type9/type41, and their commonplace on Dell systems.
> 
> I'd like to see the Dell-specific PCI VPD-R code from biosdevname
> included in udev, as that's used to map multi-port devices to port
> numbers.  Those aren't represented in type9/type41, and they're
> commonplace on Dell systems.

OK.

> I'd like to see kernel driver work to be sure every multi-port driver
> with the same PCI b/d/b/f sets dev_id.  That isn't necessarily true
> today, which makes it hard to trust.  biosdevname needs this too,
> until such a time as it's dead.

Do we have a list of these, or is it a matter of doing a driver audit?
CC'ing gospo.

> So, aside from the naming convention change (which, hey, if someone
> else takes the pain for making that change again, not me or my company
> - go nuts!), the rest is straightforward technical and code can be
> cribbed if desired from biosdevname or just rewritten.

OK, thanks. Let's see what we can do here. My concern is the conflict
between trying to cover all of the cases, and trying to avoid writing
documentation that is a lot of "if your device is , then your
name is Y or Z depending on which commandline you booted with when you
installed.'

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

Re: [ACTION REQUIRED] Retiring packages for Fedora 19

[Bill Nottingham]

Martin Sourada (martin.sour...@gmail.com) said: 
> On Sun, 24 Feb 2013 11:19:43 +0100 
> Bill Nottingham wrote:
> 
> > Removing: notification-daemon
> > clementine requires notification-daemon = 0.7.6-2.fc19
> > gnome-session requires notification-daemon = 0.7.6-2.fc19
> > guake requires notification-daemon = 0.7.6-2.fc19
> > notification-daemon-engine-nodoka requires notification-daemon =
> > 0.7.6-2.fc19
> Is that actually needed still? MATE has its own, gnome-shell (and
> probably Cinnamon as well) uses something different, XFCE has its own,
> gnome fallback goes EOL in F19... I see LXDE installs it, but it could
> probably switch to one of the alternatives?

Looking over guake, I believe it just requires *a* notification daemon;
Pierre-Yves can say for sure. gnome-session looks obsolete, and the
nodoka theme could obviously be removed with it.

Christoph may be able to speak to what LXDE could do with an alternate
notification daemon, but he's travelling at least today.

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

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Kay Sievers (k...@vrfy.org) said: 
> On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek  wrote:
> 
> >> > I'd like to see kernel driver work to be sure every multi-port driver
> >> > with the same PCI b/d/b/f sets dev_id.  That isn't necessarily true
> >> > today, which makes it hard to trust.  biosdevname needs this too,
> >> > until such a time as it's dead.
> 
> >> Do we have a list of these, or is it a matter of doing a driver audit?
> >> CC'ing gospo.
> 
> > Right now almost no drivers actually set dev_id.  In fact mlx4_en,
> > cxgb4, and sfc seem to be the only ones right now.  If we feel like this
> > a requirement there will be work on the kernel side to add this.
> 
> This only matters if there are multiple devices created by a driver
> for one and the same pci device. Like when we have only one entry in
> lspci, but multiple interfaces of the same type having this one device
> as a parent.
> 
> Is this really common? I would expect this is a very rare exception.

It definitely happens with some drivers, because I remember back in the
ancient ancient kudzu days having to hack in a fix for this.

The guilty driver in that initial case was Chelsio cxgb3, so it apparently
would need fixed per above.

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

Re: Orphaning the-board

[Bill Nottingham]

Peter Robinson (pbrobin...@gmail.com) said: 
> On Thu, Feb 28, 2013 at 3:54 AM, Cosimo Cecchi  wrote:
> > Hi all,
> >
> > The "the-board" project hasn't seen almost any development upstream and it
> > currently doesn't build in rawhide due to previous gjs API changes.
> > I just don't have the time to try and reviving it these days, so I'll orphan
> > the package.
> 
> I spoke to the upstream maintainer about this the other day. I suggest
> you actually retire it properly rather than just orphan it, if
> development picks up it can be re-reviewed.

"Fedora Board member suggests Fedora retire the-board", film at 11.

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

Re: dietlibc

[Bill Nottingham]

Toshio Kuratomi (a.bad...@gmail.com) said: 
> I recalled this set of issues too from my previous time in fesco but I
> didn't find the meeting logs with the information.  I did find this meeting
> log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070531
> 
> where fesco voted to disallow static linking to dietlibc but deferred the
> question of linking to dietlibc at all.
> 
> On that question, I would tend to agree with patrice's email that we've
> moved towards certain core systems being too core to let people use an
> alternative in Fedora (although alternatives may be provided).  Examples are
> kernel (no kmods) and C compiler (IIRC, there was discussion about building
> with clang that resolved in at least a decision on the list to use gcc).
> 
> There is a line somewhere as to what is "core enough" to warrant this
> treatment but I think it's reasonable to think that the libc implementation
> falls on the same side as the C compiler.

I'd agree here - note that these 4 were also packages maintained by
the former maintainer of dietlibc... it would reasonably be simple just
for the new maintainer to fix that as part of picking them up.

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

[ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update

[Bill Nottingham]

Before we branch for Fedora 19, as is custom, we will block currently
orphaned packages and packages that have failed to build since Fedora 17.

The following packages are currently orphaned, or fail to build. If
you have a need for one of these packages, please pick them up.
If no one claims any of these packages, they will be blocked before
we branch for Fedora 19. That is currently scheduled to happen on
or around March 12.

Package HippoDraw (orphan)
Package PyPE (orphan)
Package Temperature.app (orphan)
Package afraid-dyndns (orphan)
Package alsamixer-dockapp (orphan)
Package aplus-fsf (fails to build)
Package aswvdial (orphan)
Package auto-nng (orphan)
Package bamf (orphan)
comaintained by: jspaleta
Package blazeblogger (orphan)
Package bouncycastle-tsp (orphan)
Package bzr-explorer (orphan)
Package c2050 (orphan)
Package c2070 (orphan)
Package canto (orphan)
Package certmaster (orphan)
comaintained by: alikins
Package compton (orphan)
Package cputnik (orphan)
Package dasher (orphan)
Package eclipse-m2m-qvtoml (fails to build)
Package eclipse-mercurial (fails to build)
comaintained by: overholt
Package em8300 (orphan)
Package emacs-ecb (orphan)
Package emacs-rpm-spec-mode (orphan)
Package emacs-slime (orphan)
Package email2trac (fails to build)
Package fcron (orphan)
Package ganymed-ssh2 (orphan)
comaintained by: akurtakov
Package gkrellm-weather (orphan)
Package global (orphan)
Package gmyth (orphan)
Package gnome-mag (orphan)
Package griffith (orphan)
Package gtksourceview2-sharp (fails to build)
Package guimup (orphan)
Package haildb (orphan)
Package inamik-tableformatter (orphan)
Package javacsv (orphan)
Package jopt-simple (orphan)
Package libdrizzle (orphan)
Package libgnomecups (orphan)
Package libindicator (orphan)
comaintained by: jspaleta
Package libopensync-plugin-sunbird (orphan)
comaintained by: awjb
Package lx (orphan)
Package mimetic (orphan)
Package mingw-openjpeg (orphan)
comaintained by: epienbro
Package mlmmj (orphan)
Package mtpfs (orphan)
Package nagios-plugins-rhev (fails to build)
Package ncpfs (orphan)
Package nitrogen (orphan)
Package notification-daemon (orphan)
Package obapps (orphan)
Package ocaml-cmigrep (orphan)
Package pbm2l2030 (orphan)
Package pbm2l7k (orphan)
Package pclock (orphan)
Package perl-Bio-Graphics (orphan)
comaintained by: alexlan
Package perl-Fedora-Bugzilla (orphan)
comaintained by: mmaslano
Package perl-bioperl (orphan)
comaintained by: alexlan
Package perl-bioperl-run (orphan)
comaintained by: alexlan
Package pidgin-gfire (orphan)
Package polkit-gnome (orphan)
Package python-GeoIP (orphan)
Package python-chm (orphan)
Package python-drizzle (orphan)
Package python-wsgi-jsonrpc (orphan)
Package rubygem-acts-as-list (orphan)
Package spicebird (orphan)
Package sympy (orphan)
Package trac-agilo-plugin (orphan)
comaintained by: kevin
Package util-vserver (orphan)
Package vdr-skins (orphan)
Package vdr-text2skin (orphan)
Package vdr-wapd (orphan)
Package volpack (orphan)
Package wmSun (orphan)
Package wmbinclock (orphan)
Package wmblob (orphan)
Package wmcalc (orphan)
Package wmcore (orphan)
Package wmcube (orphan)
Package wmdrawer (orphan)
Package wmeyes (orphan)
Package wmnet (orphan)
Package wmpuzzle (orphan)
Package wmsystemtray (orphan)
Package wmtictactoe (orphan)
Package wmtop (orphan)
Package wmwave (orphan)
Package wmweather (orphan)
Package xml-writer (orphan)

List of deps left behind by packages which are orphaned or fail to build:

Removing: bamf
bamf-qt requires bamf-devel = 0.2.104-4.fc18
gnome-pie requires libbamf3.so.0
gnome-pie requires bamf3-devel = 0.2.104-4.fc18

Removing: bouncycastle-tsp
itext requires bouncycastle-tsp = 1.46-6.fc19
itext-core requires bouncycastle-tsp = 1.46-6.fc19

Removing: c2050
printer-filters requires c2050 = 0.3b-7.fc19

Removing: c2070
printer-filters requires c2070 = 0.99-10.fc19

Removing: certmaster
func requires certmaster = 0.28-5.fc19

Removing: gmyth
gstreamer-plugins-bad-free requires gmyth-devel = 0.7.1-20.fc19
gstreamer-plugins-bad-free-extras requires libgmyth.so.0

Removing: jopt-simple
springframework requires jopt-simple = 3.3-8.fc19

Removing: libgnomecups
libgnomeprint22 requires libgnomecups-1.0.so.1
libgnomeprint22 requires libgnomecups-devel = 0.2.3-12.fc18

Removing: lx
printer-filters requires lx = 20030328-9.fc19

Removing: ncpfs
medusa requires libncp.so.2.3
medusa requires ncpfs-devel = 2.2.6-18.fc19
medusa requires libncp.so.2.3(NCPFS.2.2.0.17)
medusa requires libncp.so.2.3(NCPFS_2.2.0.19)
medusa requires libncp.so.2.3(NCPFS_2.2.1)

Removing: notification-daemon
gnome-session requires notification-daemon = 0.7.6-2.fc19
notification-daemon-engine-nodoka requires notification-daemon = 
0.7.6-2.fc19

Removing: pbm2l2030
printer-filters requires pbm2l2030 = 1.4-10.fc19

Removing: pbm2l7k
printer-filters req

Re: RFC: Fedora revamp proposal

[Bill Nottingham]

seth vidal (skvi...@fedoraproject.org) said: 
> On Tue, 05 Mar 2013 13:28:58 -0500
> Colin Walters  wrote:
> 
> > On Tue, 2013-03-05 at 13:17 -0500, seth vidal wrote:
> > 
> > > If the issue was only 'newer is better' then rpm can easily get
> > > around it. Hell, so can yum, now.
> > 
> > But koji, createrepo and such can't, right?
> 
> 
> createrepo is version agnostic. It cares not at all.
> 
> koji can build whatever, too.. I'm not sure how those are related here.

Well, on the koji side there are build concerns, but that's somewhat
separate from giving users something they can stay on stably.

We don't ship in a way that easily allows this though, now. Admittedly,
this is due to the sheer *amount* of stuff involved in just maintaining
single versions of things, and how much that would jump if we started
having multiple versions available all the time. That being said,
as long as we're willing to take the hit in disk space & repodata size,
and we're willing to nuke deltas from orbit (they won't scale to this,
sorry), we could certainly support having multiple versions of everything
available for easier rollback.

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

Re: RFC: Fedora revamp proposal

[Bill Nottingham]

Colin Walters (walt...@verbum.org) said: 
> On Tue, 2013-03-05 at 16:58 -0500, Bill Nottingham wrote:
> 
> > We don't ship in a way that easily allows this though, now. Admittedly,
> > this is due to the sheer *amount* of stuff involved in just maintaining
> > single versions of things, and how much that would jump if we started
> > having multiple versions available all the time. 
> 
> To be clear, I am not suggesting multiple versions.  The suggestion is
> that the old version of mesa overrides the new version and the tests
> (and users) get it.
> 
> Pretend like we bumped the Epoch.

That requires more tooling changes, of course. (Or really dirty tricks
in the repodata).

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

Re: Non responsive state for systemd

[Bill Nottingham]

Steve Clark (scl...@netwolves.com) said: 
> Well you can be as sarcastic as you want but I have been using UNIX/Linux
> since 1985 and never had init hang or die on me.

sysvinit and systemd have linked against libselinux since SELinux policy was
introduced. upstart only didn't because policy was loaded in the initramfs
then, which was arguably a mistake.

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

[ACTION REQUIRED] [FINAL NOTICE] Retiring packages for Fedora 19

[Bill Nottingham]

Before we branch for Fedora 19, as is custom, we will block currently
orphaned packages and packages that have failed to build since Fedora 17.

The following packages are currently orphaned, or fail to build. If
you have a need for one of these packages, please pick them up.
If no one claims any of these packages, they will be blocked before
we branch for Fedora 19. That is currently scheduled to happen on
or around 3AM GMT on March 12. (i.e., about 11 hours from now.)

Package HippoDraw (orphan)
Package PyPE (orphan)
Package Temperature.app (orphan)
Package afraid-dyndns (orphan)
Package alsamixer-dockapp (orphan)
Package aplus-fsf (fails to build)
Package aswvdial (orphan)
Package auto-nng (orphan)
Package bamf (orphan)
comaintained by: jspaleta
Package blazeblogger (orphan)
Package c2050 (orphan)
Package c2070 (orphan)
Package canto (orphan)
Package certmaster (orphan)
comaintained by: alikins
Package compton (orphan)
Package cputnik (orphan)
Package dasher (orphan)
Package eclipse-m2m-qvtoml (fails to build)
Package eclipse-mercurial (fails to build)
comaintained by: overholt
Package em8300 (orphan)
Package emacs-ecb (orphan)
Package email2trac (fails to build)
Package fcron (orphan)
Package gkrellm-weather (orphan)
Package global (orphan)
Package gnome-mag (orphan)
Package griffith (orphan)
Package gtksourceview2-sharp (fails to build)
Package guimup (orphan)
Package haildb (orphan)
Package inamik-tableformatter (orphan)
Package javacsv (orphan)
Package libdrizzle (orphan)
Package libgnomecups (orphan)
Package libopensync-plugin-sunbird (orphan)
comaintained by: awjb
Package lx (orphan)
Package mimetic (orphan)
Package mingw-openjpeg (orphan)
comaintained by: epienbro
Package mlmmj (orphan)
Package mtpfs (orphan)
Package nagios-plugins-rhev (fails to build)
Package ncpfs (orphan)
Package nitrogen (orphan)
Package obapps (orphan)
Package ocaml-cmigrep (orphan)
Package pbm2l2030 (orphan)
Package pbm2l7k (orphan)
Package pclock (orphan)
Package perl-Bio-Graphics (orphan)
comaintained by: alexlan
Package perl-Fedora-Bugzilla (orphan)
comaintained by: mmaslano
Package perl-bioperl (orphan)
comaintained by: alexlan
Package perl-bioperl-run (orphan)
comaintained by: alexlan
Package pidgin-gfire (orphan)
Package python-chm (orphan)
Package python-drizzle (orphan)
Package python-wsgi-jsonrpc (orphan)
Package rubygem-acts-as-list (orphan)
Package spicebird (orphan)
Package trac-agilo-plugin (orphan)
comaintained by: kevin
Package util-vserver (orphan)
Package vdr-skins (orphan)
Package vdr-text2skin (orphan)
Package vdr-wapd (orphan)
Package volpack (orphan)
Package wmSun (orphan)
Package wmbinclock (orphan)
Package wmblob (orphan)
Package wmcalc (orphan)
Package wmcore (orphan)
Package wmcube (orphan)
Package wmdrawer (orphan)
Package wmeyes (orphan)
Package wmnet (orphan)
Package wmpuzzle (orphan)
Package wmsystemtray (orphan)
Package wmtictactoe (orphan)
Package wmtop (orphan)
Package wmwave (orphan)
Package wmweather (orphan)
Package xml-writer (orphan)

List of deps left behind by packages which are orphaned or fail to build:

Removing: bamf
bamf-qt requires bamf-devel = 0.2.104-4.fc18
gnome-pie requires libbamf3.so.0
gnome-pie requires bamf3-devel = 0.2.104-4.fc18

Removing: certmaster
func requires certmaster = 0.28-5.fc19

Removing: libgnomecups
libgnomeprint22 requires libgnomecups-1.0.so.1
libgnomeprint22 requires libgnomecups-devel = 0.2.3-12.fc18

Removing: ncpfs
medusa requires libncp.so.2.3
medusa requires ncpfs-devel = 2.2.6-18.fc19
medusa requires libncp.so.2.3(NCPFS.2.2.0.17)
medusa requires libncp.so.2.3(NCPFS_2.2.0.19)
medusa requires libncp.so.2.3(NCPFS_2.2.1)

Removing: perl-bioperl
perl-Bio-ASN1-EntrezGene requires perl(Bio::Index::AbstractSeq)
perl-Bio-SamTools requires perl(Bio::PrimarySeq)
perl-Bio-SamTools requires perl(Bio::SeqFeature::Lite)

Removing: python-chm
archmage requires python-chm = 0.8.4-14.fc19
chm2pdf requires python-chm = 0.8.4-14.fc19

Removing: python-wsgi-jsonrpc
python-windmill requires python-wsgi-jsonrpc = 0.2.9-3.fc19

Removing: volpack
amide requires volpack-devel = 1.0c7-7.fc19
amide requires libvolpack.so.1

The script that generated this page can be found at 
http://git.fedorahosted.org/cgit/releng/tree/scripts/find-unblocked-orphans.py
There you can also report bugs and RFEs.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Improving the Fedora boot experience

[Bill Nottingham]

Björn Persson (bjorn@rombobjörn.se) said: 
> Matthias Clasen wrote:
> > - Turn off the graphical grub screen
> > 
> > Even if we are not able to suppress the boot menu entirely, or having a 
> > clean boot menu like this: 
> > https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png,
> >  avoiding the graphical screen will be a win in terms of reduced visual 
> > noise.
> 
> What would there be instead? A text-mode boot menu? Or nothing at all
> displayed unless the user happens to know to press some key at the
> right moment?

Ideally, we'd detect whether the previous boot failed in some way and only
offer the menu then, or if the user chooses to reboot into the menu.
(There's still some systemd/grub interaction work required for both of
these.)

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

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for Fedora 19

[Bill Nottingham]

Bill Nottingham (nott...@redhat.com) said: 
> Before we branch for Fedora 19, as is custom, we will block currently
> orphaned packages and packages that have failed to build since Fedora 17.
> 
> The following packages are currently orphaned, or fail to build. If
> you have a need for one of these packages, please pick them up.
> If no one claims any of these packages, they will be blocked before
> we branch for Fedora 19. That is currently scheduled to happen on
> or around 3AM GMT on March 12. (i.e., about 11 hours from now.)

The following packages have been retired:

HippoDraw
Temperature.app
afraid-dyndns
alsamixer-dockapp
aplus-fsf
aswvdial
auto-nng
bamf
blazeblogger
c2050
c2070
canto
certmaster
compton
cputnik
em8300
emacs-ecb
fcron
gkrellm-weather
global
gnome-mag
griffith
guimup
haildb
inamik-tableformatter
javacsv
libdrizzle
libopensync-plugin-sunbird
lx
mimetic
mingw-openjpeg
mlmmj
mtpfs
nagios-plugins-rhev
ncpfs
nitrogen
obapps
ocaml-cmigrep
pbm2l2030
pbm2l7k
pclock
perl-Bio-Graphics
perl-Fedora-Bugzilla
perl-bioperl
perl-bioperl-run
pidgin-gfire
python-chm
python-drizzle
python-wsgi-jsonrpc
rubygem-acts-as-list
spicebird
trac-agilo-plugin
util-vserver
vdr-skins
vdr-text2skin
vdr-wapd
volpack
wmSun
wmbinclock
wmblob
wmcalc
wmcore
wmcube
wmdrawer
wmeyes
wmnet
wmpuzzle
wmsystemtray
wmtictactoe
wmtop
wmwave
wmweather
xml-writer
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Schedule for today's FESCo meeting (2013-03-13)

[Bill Nottingham]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC (2:00pm EST, 19:00 CET) in #fedora-meeting on
irc.freenode.net.

(Apologies for the delay, was out ill yesterday.)

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

= New business =

#topic #1095 Fedora 20 schedule proposal
.fesco 1095
https://fedorahosted.org/fesco/ticket/1095

#topic #1096 Rawhide Rebase to Fedora 19 in Bugzilla
.fesco 1096
https://fedorahosted.org/fesco/ticket/1096

#topic #1094 tomcat6 deprecation (fasttrack)
.fesco 1094
https://fedorahosted.org/fesco/ticket/1094

#topic #1098 F19 Features - Progress on Feature Freeze
.fesco 1098
https://fedorahosted.org/fesco/ticket/1098

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Summary/minutes for today's FESCo meeting (2013-03-13)

[Bill Nottingham]

===
#fedora-meeting: FESCO (2013-03-13)
===


Meeting started by notting at 18:00:48 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-03-13/fesco.2013-03-13-18.00.log.html
.

Meeting summary
---
* init process  (notting, 18:00:55)

* #1095 Fedora 20 schedule proposal  (notting, 18:05:12)
  * motion to ratify proto-schedule did not pass  (notting, 19:07:27)

* #1096  Rawhide Rebase to Fedora 19 in Bugzilla  (notting, 19:08:01)
  * AGREED: rebasing of rawhide bugs to f19 (and later releases for each
subsequent release) is approved (+:5, -:0, 0:0)  (notting, 19:12:14)

* #1094 tomcat6 deprecation (fasttrack)  (notting, 19:13:06)
  * AGREED: wait one week and revisit (+:6, -:0, 0:0)  (notting,
19:16:29)

* #1098 F19 Features - Progress on Feature Freeze  (notting,
  19:16:45)
  * LINK: https://fedoraproject.org/wiki/Feature_Freeze_Policy   (nirik,
19:29:53)
  * AGREED: send e-mail to all the feature owners on this ticket saying
that they have 1 week to get their feature testable and their page
updated. vote next week on what to drop (+:6, -:0, 0:0)  (notting,
19:37:00)

* Next Week's Chair  (notting, 19:39:00)
  * nirik will chair next week  (notting, 19:43:00)

* Open Floor  (notting, 19:48:58)
  * LINK: https://fedoraproject.org/wiki/Releases/Rawhide   (nirik,
19:51:12)
  * rawhide pages on the wiki at
https://fedoraproject.org/wiki/Releases/Rawhide have been updated -
please send feedback to nirik  (notting, 19:53:04)

Meeting ended at 19:55:33 UTC.

Action Items


Action Items, by person
---
* **UNASSIGNED**
  * (none)

People Present (lines said)
---
* jwb (93)
* jreznik (92)
* pjones (87)
* nirik (82)
* notting (62)
* mitr (45)
* sgallagh (32)
* t8m (29)
* adamw (26)
* zodbot (8)
* drago01 (6)
* netSys (1)
* abadger1999 (1)
* NeatBasis (1)
* mmaslano (0)

Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
18:00:48  #startmeeting FESCO (2013-03-13)
18:00:48  Meeting started Wed Mar 13 18:00:48 2013 UTC.  The chair is 
notting. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:48  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
18:00:55  #meetingname fesco
18:00:55  The meeting name has been set to 'fesco'
18:00:55  #chair abadger1999 jwb mitr mmaslano notting nirik pjones 
t8m sgallagh
18:00:55  Current chairs: abadger1999 jwb mitr mmaslano nirik notting 
pjones sgallagh t8m
18:00:55  #topic init process
18:01:06  here
18:01:07 * nirik waves. morning everyone.
18:01:36  hello.
18:01:43  Hello
18:02:30  Hi
18:02:45  I'm here, but I have a hard stop in 45 minutes
18:03:16  hello
18:03:40  that's 7. mmaslano said she wasn't making it. abadger1999?
18:04:11  notting: I'm not really here either
18:04:51  ok then
18:05:12  #topic #1095 Fedora 20 schedule proposal
18:05:29  .fesco 1095
18:05:33  notting: #1095 (Fedora 20 schedule proposal) – FESCo - 
https://fedorahosted.org/fesco/ticket/1095
18:05:35 * jreznik is around and given the timeframe...
18:05:37 * nirik re-reads the last comment there.
18:06:51 * nirik would be ok with the 2013-11-12 release.
18:07:02  sure
18:07:11  i know end of nov is problematic, but i'm not too keen about 
pulling it too much further in
18:07:45  well if you factor in slips beginning of nov means end of 
novv
18:07:49  for a 19.1, or 20.1 I think we need more groundwork... because 
things like rawhide is building fc20 rpms... would those be confusing in a 19.1 
release?
18:07:52  while end means mid dec
18:07:53  notting: I'm also more inclined for the end of november, 
11-12 is really the earliest
18:07:55  drago01: yeah
18:08:09  wait, what?
18:08:12  Factoring in slips, end of November probably means early 
January...
18:08:14  I prefer to have 2 weeks at least in case we slip. (no, we 
would never do that)
18:08:21  are we seriously discussing .1 releases somehow?
18:08:27  sgallagh, not necessarily
18:08:29  jwb: it was an aside in the ticket.
18:08:29  nirik: x.y is not only about the next releases but about the 
whole model of stable releases and what we support etc.
18:08:39  nirik, which abadger1999 said wasn't serious
18:08:43  sorry to have dragged it in.
18:09:03  anyhow, I think 11-12 makes sense, as it gives us some room 
before holidays.
18:09:08  i wouldn't expect us to start discussing .1 until we're well 
into 20
18:09:17  er, sorry.  planning 20
18:09:33  sure
18:10:25  I agree with 11-12, I think we can't go earlier and have 
enough dev/testing time, but I don't think we can go much later and avoid 
slipping into the major holidays
18:10:48 * nirik nods
18:10:54  sgallagh: really, earlier is suicide, later is really too 
close to holidays
18:11:49  so in case of the GA on 11-12 - all other dates are adjusted the 
same way?
18:12:07  or except the Feature Submission deadline?
18:12:37  sor

Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]

[Bill Nottingham]

Miloslav Trmač (m...@volny.cz) said: 
> On Mon, Mar 18, 2013 at 6:30 PM, Honza Horak  wrote:
> > In case of MySQL/mariadb (just for demonstration) the config file would
> > contain say:
> > MySQL   +1
> > mariadb -1
> > which would tell yum to prioritize MySQL.
> >
> > I'm sure that there are several other use cases for such utility. It would
> > bring a bit more complexity on the one hand, but would decrease ambiguity in
> > specific cases on the other hand.
> >
> > Any ideas about such tool/plugin?
> 
> I'm not following the MySQL/mariadb packaging discussion in full
> detail - however, if we got to the point of discussing special yum
> plugins, wouldn't it be much simpler to
> 
> * Modify the 10 packages that require mysql-server, the 19 packages
> that require mysql, the 3 packages that require mysql-libs (all F18
> counts) to require mariadb-* explicitly instead of using the virtual
> provide
> 
> * Make sure that only mariadb-libs, not Oracle MySQL, Provides: the
> libmysqlclient soname?
> 
> That's about 35 packages to touch, and all but one of them trivial
> modifications.

This does sound much simpler, IMO.

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

Re: fedora release name problem

[Bill Nottingham]

J. Randall Owens (jrowens.fed...@ghiapet.net) said: 
> On 03/19/2013 09:22 AM, Richard W.M. Jones wrote:
> > On Tue, Mar 19, 2013 at 01:08:35PM -, Paul Flo Williams wrote:
> >> What do you mean, if and when? I can already see the next Release Name
> >> page shaping up with
> >>
> >> "Motörhead's Moshpit is a name with non ASCII alphanumeric characters,
> >> like ..."
> > 
> > I'm voting for ☃.
> 
> Me, I'm pulling for "the release formerly known as Schrödinger's Cat".

Well, if you're going to yank the decided on release name, might as well just
call it \0.

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

Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Bill Nottingham]

Andrew Lutomirski (l...@mit.edu) said: 
> On Mon, Jan 5, 2015 at 10:36 AM, Miloslav Trmač  wrote:
> >> While I think you are right in some cases like cashier, isn't this
> >> discussion really about the Fedora Workstation?! Since for this the
> >> target user is a developer, can we just agree that in this case the user
> >> needs both CLI and GUI apps (although some developers certainly sticks
> >> to one of them).
> >
> > The gist is that
> > * Nobody _should_ need to use a terminal: non-developers¹ don’t need it, 
> > and developers deserve a better environment.  It’s “only” a matter of 
> > writing lots of new software.  AFAICT Workstation would in some ideal 
> > future want to get to this state.  (And non-Linux operating systems are 
> > getting closer and closer to this ideal over time.)
> 
> Having watched people develop under Mac OS X, they have really shiny
> things to play with.  Xcode is pretty, and there are whole pile of
> nice editors and such to use.  Heck, even Firefox and Chromium are
> gradually turning into developer tools as opposed to just being
> browsers and debuggers.
> 
> Nonetheless, the productive Mac OS X developers I know all have
> something like an entire desktop devoted to just running terminals.
> 
> Given that no one, on any OS I've ever seen*, has come up with
> something better than a terminal for running scripts, watching log
> messages scroll by, using fancy shell commands, etc., I think that
> expecting Fedora to magically solve all these problems is both overly
> optimistic and is an entirely inappropriate assumption to base the OS
> design on.

I'm not sure that GNOME Software is the right place to solve this, though -
if I'm using the terminal to build things:

- I shouldn't be searching for grep/sed/awk - those are part of the base
  operating system, and should be treated as such.
- I shouldn't be searching for gcc, gcc-c++, make, etc. as separate
  promoted to GNOME Software applications; those should be treated as part
  of a development kit that's installed and updated as a unit, any more than
  I should be searching for libgweather or libdrm as part of installing a
  desktop app.
- Even searching for -devel packages implies a "target == host" build
  sensibility that is relevant mostly to those developing Fedora, and
  not to most of those developers that I run into on a day-to-day basis
  (and likely not the developers we're targeting.) They're interested
  in using mock along with system libraries for RHEL/CentOS, using
  pip/npm/rubygems, etc. 

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

Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Bill Nottingham]

Hedayat Vatankhah (hedayat@gmail.com) said: 
> 
> /*Bill Nottingham */ wrote on Tue, 6 Jan 2015 11:39:27
> -0500:
> ><...>
> >- Even searching for -devel packages implies a "target == host" build
> >   sensibility that is relevant mostly to those developing Fedora, and
> >   not to most of those developers that I run into on a day-to-day basis
> >   (and likely not the developers we're targeting.) They're interested
> >   in using mock along with system libraries for RHEL/CentOS, using
> >   pip/npm/rubygems, etc.
>
> So you mean that Fedora target developers are either using dynamic
> languages, or they develop native software for RHEL/CentOS?! So you believe
> that "target == rhel/centos"? And native software developers for *modern*
> distros are not targets? This is really offending. RHEL/CentOS themselves
> should mainly target their developers. I guess that most of the developers
> you run into are working for RedHat.

... Not at Red Hat now, but what I'm saying is that the developers I
interact with are targeting mainly Ubuntu LTS and CentOS/RHEL, even if their
devel platform is Fedora.  It goes back to uses of Fedora in production -
while Fedora Server certainly wants to change this, most all of the
*deployed* server systems that people are targeting for their code aren't
Fedora.  Once you assume that you want to support the use case of developers
using Fedora to develop for things that aren't Fedora, I just feel
that worrying about a package tool for installing -devel packages pales in
trying to streamline the workflows the developers needs around using things
like mock and jenkins as build tools, and test environments that aren't even
local to the machine at all, whether they involve virtualization,
containers, or remote cloud services.

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

Re: Deleting f20-gnome-3-12 copr

[Bill Nottingham]

Pete Travis (li...@petetravis.com) said: 
> On Jan 7, 2015 6:00 AM, "Richard Hughes"  wrote:
> >
> > I'm planning to delete
> > https://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ this
> > week. The original description always had "This COPR will be updated
> > until Fedora 21 has been released or until the entropy death of the
> > universe, whichever happens first." so I don't altogether feel too
> > guilty about abandoning it. Does anyone have any objections or wants
> > to volunteer to take it over before I delete the repo?
> >
> > Richard
> > --
> 
> While recognizing the massive maintenance burden of this COPR, I suspect
> the majority of objections will come from the enthusiast end user type -
> you know, the ones that are so eager to try the new thing they read about
> that they blow right past the description.  This COPR received a lot of
> publicity; fedoramagazine articles, social media, blog posts, etc.

While I'm not volunteeering to maintain this, I do ask - what is the reason
for deleting it vs. just leaving it around in a EOL state where it's not being
updated? We don't remove EOL releases, for example.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bill Nottingham]

Tom Hughes (t...@compton.nu) said: 
> > On a more general note I think a lot of people are assuming we're all
> > horrible evil people, trying to subvert the One True Fedora Way. This
> > is exceptionally poisonous and needs to stop, otherwise Fedora should
> > to drop both the "Friends", "Features" and the "First" in its motto.
> 
> I'm not necessarily concerned about subverting (or "changing" as I would
> prefer to think of it) the One True Fedora Way, if there are good reasons to
> do so and it improves things.
> 
> I'm more concerned that there will no longer be One True Fedora Way.
> 
> By which I mean that there will no longer be one way to update a Fedora
> system because workstations and servers have to be managed in completely
> different ways.
> 
> In other words that it's no longer possible to use clusterssh to run "dnf
> update" on twenty machines at once because each one is now a special
> snowflake that requires it's own approach to updating things - possibly even
> a mix of approaches if a developer's workstation needs "server updates" to
> update postgres and apache and "workstation updates" to update gcc and
> firefox.

Why clusterssh when you can Ansible? But I digress.

This situation already exists, though - each of these systems are already
snowflakes if they're user-maintained:
- some apps installed via RPMs connected to Fedora repos
- some from COPRS
- some from Random RPM Downloaded From Third-Party Website
- some from npm/pip
- containers from arbitrary registries.
- curlsh stuff
- things built from source

If the only answer Fedora has for this is "convince everyone to only build
RPMs using system reo components"... that's fighting a rear-guard battle
that has already been lost.  I don't think supporting Flatpak apps is
necessarily any worse than what already has to happen with all of the above.

Bill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Working Groups: Call for Self-Nominations

[Bill Nottingham]

Miloslav Trmač (m...@volny.cz) said: 
> On Sat, Oct 19, 2013 at 9:27 PM, Kevin Kofler  wrote:
> > Miloslav Trmač wrote:
> >> No, the intent was very much to change what the resulting desktop
> >> prioritizes.  Quite a few FESCo members would be rather disappointed
> >> if the new Workstation ended up just an unchanged GNOME[1].
> > [snip]
> >> [1] As opposed to any of 1) non-GNOME, 2) GNOME changed by Fedora, 3)
> >> GNOME upstream changing.  I don't know enough to say whether any of
> >> these variants is generally preferred within FESCo.
> >
> > 2 features which would have changed that have been proposed over time:
> > https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default
> > https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop
> > Both have been rejected by FESCo.
> 
> Repeating myself, "I don't know enough to say whether any of these
> variants is generally preferred within FESCo.".

And I would argue that having the user interface swing wildly in design &
implementation based on "the current composition of an elected board that is
refreshed in part every six months" is not the sort of situation that Fedora
would want to be in anyway.

(Of course, if it was, that would add an entirely different feel to the
elections.  Vote now in next month's elections to bring on people to
completely change the proposed product split? Candidates running on 23
products instead of 3?) 

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

Re: communications and community [was Re: Lack of response about sponsorship]

[Bill Nottingham]

Kevin Fenzi (ke...@scrye.com) said: 
> > As a first step, I suggest clearing up the intended usage of "devel"
> > list. There's too much traffic on that list. 792 messages so far in
> > October. Even if one uses filtering, the recurring task of skimming
> > over the devel list folder is tiresome, since it's not the only list
> > one is subscribed to. Not even meetings logs are posted to
> > devel-announce list, however.
> 
> Good idea. What items could we move to announce that would be more
> useful for folks that don't have as much time/energy to skim the main
> list?
> 
> fesco meeting agenda/minutes? (note that this would be weekly, so
> increase the announce list a good deal)
> Any other things that would be better as announcements?

I would think that if we are in a situation where people who do development
don't subscribe to the devel list because of 'energy' reasons
(disillusionment, feelings of either a) pointlessness b) fait-accompli,
etc.), then just moving things to -announce is not actually solving the
problem.

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

Schedule for Wednesday's (today's) FESCo meeting (2013-10-30)

[Bill Nottingham]

(Apologies for the lateness.)

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2013-10-30 18:00 UTC'

NOTE: Due to DST switches in certain locales, please double check the
meeting time in your area.

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1170 Working Group call for volunteers
.fesco 1170
https://fedorahosted.org/fesco/ticket/1170

#topic #1180 Build virt-preview in Koji
.fesco 1180
https://fedorahosted.org/fesco/ticket/1180

= New business =

#topic #1185 Enable "-Werror=format-security" by default
.fesco 1185
https://fedorahosted.org/fesco/ticket/1185

#topic #1186 FESCo liason role in WGs
.fesco 1186
https://fedorahosted.org/fesco/ticket/1186

#topic #1187 Packagers should be not be allowed to ignore RH bugzilla
.fesco 1187
https://fedorahosted.org/fesco/ticket/1187

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Summary/Minutes for Wednesday's (today's) FESCo meeting (2013-10-30)

[Bill Nottingham]

===
#fedora-meeting: FESCO (2013-10-30)
===


Meeting started by notting at 18:01:19 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-10-30/fesco.2013-10-30-18.01.log.html
.

Meeting summary
---
* init process  (notting, 18:01:26)
  * AGREED: meeting stays at 1800UTC until further notice (+:9)
(notting, 18:11:21)

* #1170 Working Group call for volunteers  (notting, 18:11:47)
  * AGREED: base design WG approved (+:8, -:1)  (notting, 18:27:56)
  * nirik to open a ticket to track working group governance proposals
(notting, 18:29:17)

* #1185 Enable "-Werror=format-security" by default  (notting, 18:29:50)
  * AGREED: defer pending results of mass rebuild (+;8, -0, 0:0)
(notting, 18:32:40)
  * AGREED: defer pending results of mass rebuild (+;9, -0, 0:0)
(notting, 18:33:30)
  * AGREED: ask gcc to make warning part of -Wall now, defer enabling it
as an error until the mass rebuild test is done (+:7, -:0, 0:0)
(notting, 18:38:28)

* #1186 FESCo liason role in WGs  (notting, 18:40:31)
  * AGREED: require that the fesco liason on a WG is always a member of
that WG's decision making body (+:8, 0:0, -:0  (pjones, 18:48:28)
  * AGREED: WGs can decide how the FESCo liason is selected, including
the possibility of asking FESCo to select. (As FESCo is above the
WGs, FESCo could ask WGs to re-choose.) (+:8, -:0, 0:0)  (notting,
19:03:03)

* #1187 Packagers should be not be allowed to ignore RH bugzilla
  (notting, 19:03:20)
  * AGREED: let people come to fesco on a package-by-package basis if
they think there are package maintenance issues (+:7, -:0, 0:0)
(notting, 19:20:04)
  * if the person filing the ticket has specific issues, he should bring
them up, as per:
https://fedoraproject.org/wiki/Package_maintainer_responsibilities
(pjones, 19:20:41)
  * Note that handling bugs is part of package maintainership, per
https://fedoraproject.org/wiki/Package_maintainer_responsibilities
(notting, 19:22:04)

* next week's chair  (notting, 19:22:36)
  * abadger1999 to chair next week's meeting  (notting, 19:23:14)

* Open Floor  (notting, 19:23:22)
  * LINK:
http://fedoraproject.org/wiki/Board/Possible_Future_of_Fedora_Governance
(old and drafty)  (nirik, 19:28:41)

Meeting ended at 19:35:04 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* notting (88)
* pjones (75)
* sgallagh (63)
* nirik (61)
* abadger1999 (44)
* jwb (43)
* mattdm (38)
* mitr (34)
* t8m (22)
* Viking-Ice (18)
* pknirsch (18)
* zodbot (13)
* mmaslano (12)
* frankieonuonga (3)
* handsome_pirate (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
18:01:19  #startmeeting FESCO (2013-10-30)
18:01:19  Meeting started Wed Oct 30 18:01:19 2013 UTC.  The chair is 
notting. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:19  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
18:01:22  Hello
18:01:26  #meetingname fesco
18:01:26  The meeting name has been set to 'fesco'
18:01:26  #chair abadger1999 mattdm mitr mmaslano notting nirik pjones 
t8m sgallagh
18:01:26  #topic init process
18:01:26  Current chairs: abadger1999 mattdm mitr mmaslano nirik 
notting pjones sgallagh t8m
18:01:28  hey.
18:01:35 * nirik runs to get coffee, back in a minute
18:01:46 * mattdm has coffee in hand
18:02:11  I'm around; closing out the Server WG meeting
18:02:31  I'll be leaving in 55 minutes to start the cloud wg meeting :)
18:03:19  hello.
18:03:33 * abadger1999 shows up
18:03:42  mattdm: sgallagh: so this is becoming an increasingly bad 
time slot then, eh?
18:04:05  pjones: It works for me; I like having an upper limit on 
the Server WG slot
18:04:10  pjones or we could keep this meeting to an hour :)
18:04:19  is that everyone except mmaslano?
18:04:27  looks like it
18:04:30  but for the cloud wg, this week probably isn't representative
18:04:46  (not sure if we will even be able to find a regular time)
18:05:21  hi
18:05:43  also, US changes time next week...
18:05:44  ok, i believe that's everyone.
18:05:45  Before we get started.
18:05:52  nirik: beat me to it
18:06:33  (and eu changed already)
18:06:43  is everyone ok with the meeting staying at 1800UTC , with 
their local time shifted back?
18:06:51  I am ok with that
18:06:57  actually I prefer that
18:07:13  sure.
18:07:17 * nirik hates timezones
18:07:44  i slightly prefer the later time but either works
18:07:48  Works for me.
18:07:50  yeah, it's okay
18:07:56 * t8m hates DST
18:08:01  So that moves it to 1:00 EDT next week?
18:08:05  err, EST
18:08:11  if we stay at 18UTC, we might ask the server and cloud WG's to 
also stay if they don't want to overlap
18:08:23  sgallagh: right
18:08:29  t8m: don't we all
18:08:36  In the case of the Server W

Re: gnome software shell search provider? [Re: Is Gnome Software ready for primetime?]

[Bill Nottingham]

Richard Hughes (hughsi...@gmail.com) said: 
> On 1 November 2013 14:53, Matthew Miller  wrote:
> > Okay, thanks. This is really cool good stuff. Guess it's time to update my
> > other laptop to Rawhide. :)
> 
> For those less brave, I've uploaded a screenshot here:
> http://people.freedesktop.org/~hughsient/temp/gnome-software-shell-search.png
> 
> Also, if you want to try this out on F20, you can use the rawhide
> gnome-software package if you also update glib2-* from rawhide. If you
> do this and file bugs, they will be ignored. :)

So if it has a session service, and a shell provider integration, does that
mean we do overlays/highlighting on applications with updates pending in the
shell, right-click->update in the app menu list, and other fun stuff like that?

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

Re: Draft Product Description for Fedora Workstation

[Bill Nottingham]

Christian Fredrik Kalager Schaller (cscha...@redhat.com) said: 
> Hi everyone,
> Attached is the draft PRD for the Workstation working group. The
> proposal tries to be relatively high level and focus on goals and
> principles, but I have included some concrete examples at times to try
> to provide some clarity on how the goals and principles could play out
> in practice.
> 
> I hope the community at large will take the time to read through it and
> provide feedback so that when the working group meet next we can use
> that feedback to start tuning in on the final form of the PRD.
> 
> Also in the name of openness, before I sent this here, I showed the PRD
> draft to key stakeholders and decision makers inside Red Hat, to ensure
> that we have the necessary support for these plans to get the kind of
> engineering resources allocated from Red Hat we will need to pull this
> off. 

Something that doesn't seem specified here is any sort of a design style or
guide for how apps used in the Workstation should generally be built and
function.  Is there intended to be that sort of standard?

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

Re: unaccessability

[Bill Nottingham]

Rahul Sundaram (methe...@gmail.com) said: 
> > I guess the main obstacle here is that there isn't really a good
> > criterion which is as clear-cut as "installs a (non-NoDisplay)
> > .desktop file" => "this is a user-visible gui application" for gui
> > applications - mutt certainly is a user application, sshd clearly is
> > not, zsh ... maybe?
> 
> Why do you want to differentiate between Mutt and sshd?

Because the purpose it was designed for was to install *applications*.

sshd is not an application, at least not in the terms that the software was
designed to handle.

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

Re: unaccessability

[Bill Nottingham]

Richard Vickery (richard.vicker...@gmail.com) said: 
> A thought as we move into the future: if we continue with the installer,
> end users may one day forget about the yum command and all the awesome
> packages out there; they may forget about the command line altogether.

We've been shipping a graphical package install tool since before we shipped
yum.  (As awesome as glint and glitter were) I, for one, am not going to
worry about this particular slippery slope.

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

Re: [Base] Summary/Minutes from today's Base WG meeting (2013-11-08)

[Bill Nottingham]

Dennis Gilmore (den...@ausil.us) said: 
> Meeting started by pknirsch at 15:00:59 UTC. The full logs are available
> at
> http://meetbot.fedoraproject.org/fedora-meeting/2013-11-08/fedora_base_design_working_group.2013-11-08-15.00.log.html

Apologies for not making the meeting. Some comments

>   * LINK: http://fpaste.org/52688/38392758/   (pknirsch, 16:19:54)
>   * Base definition: installer, compose tools, minimal install (for some
> definition there), and functionality the majority products want to
> use  (pknirsch, 16:21:30)

My concern with this, as a base design, is that the current implementation
of anaconda leads to a dependency tree that is *not* small; it's much larger
than the minimal install, as it extends to storage tools, NetworkManager,
graphical toolsets, and other items. (You could even arguably pull in X and
in the future wayland.)

It's not a *bad* thing to have as a base design - I could make the argument
that changes in that base (NM, X, etc.) are all things that should be
coordinated as a layer under the separate products. But it does give a wider
area of coverage than may be expected.

(Also, stabilizing the build dependencies therein. Wheee.)

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

Re: How to handle non-free parts of a free software project

[Bill Nottingham]

Manuel Faux (manuel.f...@conf.at) said: 
> I want to give the option to manually download the file, if one accepts
> the non-free license of Oracle. Which file system path would be
> appropriate to be prepared for that file? I would not feel comfortable
> to add the file to add the file inside /usr/lib/jvm/... or something.

This came up tangentially in the OpenH264 discussions - if you're intending
to have mechanisms to automatically download non-free code to the system,
please check with FESCo on how you intend to do this and handle it.

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

Re: [RFC] mesa 10.0 stack in F20

[Bill Nottingham]

Igor Gnatenko (i.gnatenko.br...@gmail.com) said: 
> Hey, folks!
> 
> Actually 9.2.3 doesn't built on armv7 (FDO #71573) and I think more
> better for new release to get updated mesa stack. Probably mesa 9.2.4
> will also has this bug.
> 
> What do you say about this idea?

It's post-beta, post-GFX-test-week. While I'd defer to the driver team, I'm
not sure that a mesa rebase at this point in the schedule makes sense.

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

Re: [Base] Fedora Base Design Working Group (2013-11-29) meeting minutes and logs

[Bill Nottingham]

Phil Knirsch (pknir...@redhat.com) said: 
> Meeting ended Fri Nov 29 16:15:57 2013 UTC. Information about
> MeetBot at http://wiki.debian.org/MeetBot .
> Minutes: 
> http://meetbot.fedoraproject.org/fedora-meeting/2013-11-29/fedora_base_design_working_group.2013-11-29-15.00.html
> Minutes (text): 
> http://meetbot.fedoraproject.org/fedora-meeting/2013-11-29/fedora_base_design_working_group.2013-11-29-15.00.txt
> Log: 
> http://meetbot.fedoraproject.org/fedora-meeting/2013-11-29/fedora_base_design_working_group.2013-11-29-15.00.log.html

In regards to generating the selfhosting package set...

pungi --greedy=none --multilib=none --selfhosting -G -c  2>&1 | tee pungi.log

You can either wait for it to download all the RPMs, or kill it and grep the
list of RPMs out of the log.

And yes, everything explodes in build requirements, starting with gcc
itself.

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

Re: FTBFS if "-Werror=format-security" flag is used

[Bill Nottingham]

mrnuke (mr.nuke...@gmail.com) said: 
> > Because packagers will just ignore it [...]
> > 
> I think this is a childish argument, but let's take it. So what? You're
> going to start stepping on people's lawns and change things just because
> you want to impose your greater good?

Wow, nice mixed metaphor. Package maintenance is not a person's private
domain; it's where we're signing up to maintain things as part of a
community *as a service to the users that use what we produce*. Now, people
do have different views on how some of these things may be handled, but the
goals of Fedora have never been to focus primarily on the convenience of the
packager - that's rather shortsighted.

The point is to ensure that the software we provide to *users* doesn't
contain security holes due to accident, intransigence, or other reasons.

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

Re: ABRT in the comps group 'standard'

[Bill Nottingham]

Miroslav Suchý (msu...@redhat.com) said: 
> On 12/06/2013 01:59 PM, Václav Pavlín wrote:
> >I think abrt serves as good source of info in case of unexpected crashes, 
> >which is quite important to have stable
> >system. So although being puzzled is not very nice, being disappointed by 
> >crashing applications is much worse from my
> >point of view.
> >
> >So try to look at it from broader perspective - I see more benefits in 
> >having abrt installed.
> 
> While this is true - my mother have no clue what Bugzilla means, and
> even what is bug report - well in her term it is phone call to me
> "Son, some weird box pop up, what should I do? I already hit Esc and
> Enter and it still sit there".

Well...

1) the abrt GUI is already included in multiple desktop environments
2) this request is about putting the daemon/recording functionality in the 
standard
install; the GUI integration is a separate package

In short: I do not think this proposed change affects the behavior of any of the
desktops in terms of crash popups.

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

Re: Schedule for Wednesday's FESCo Meeting (2013-12-18)

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johan...@gmail.com) said: 
> 
> On mið 18.des 2013 13:43, Jaroslav Reznik wrote:
> >Hi,
> >could you please add EOL process as the topic for this meeting?
> >As Fedora 20 was released, we should send Fedora 18 warning asap
> >and I'd like to sort it out. We're running out of time.
> 
> Can we now assume that since FESCO has started fiddling with QA
> community process that it will handle all triaging from now on?

FESCo handles issues explicitly raised to it. (In this case, it was reported
that the message given on EOL bugs tells the reporter & CC'd users to do
somemthing they don't have bugzilla permissions to do.)

We have been working in the ticket with jreznik, who had been actually doing
the EOL process. (See 
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora{18,19,20}.)

As noted in the ticket, it was not FESCo's intent to take over any process;
just work with the issue and with the people doing it. It's possible the
reporter could have contacted bugzappers directly instead - in that case, it
would certainly be useful for bugzappers' wiki page to have up to date
instructions, rather than a seemingly defunct meeting.

Bill

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

Re: Inter-WG coordination: Stable application runtimes

[Bill Nottingham]

Chris Murphy (li...@colorremedies.com) said: 
> > Really, this should be solved in upstream projects so you can expect a
> > stable library API across distribution boundaries. Doing it in Fedora is
> > not actually solving the problem.
> 
> Thanks for the response.
> 
> Is it really upstream causing the problem in the first place? Or is it the
> distributions, who have always selected what library versions they will
> package, while also proscribing packaged libraries in applications, along
> with the insistence that it's the distribution package maintainer who
> decides what ships, not the developer?

A little from column A, a little from column B. You have well used and
promoted library stacks like Boost, which don't bother with ABI
compatibilty at all. OpenSSL used to do this as well, so did Berkley DB.

When you have library stacks like these, a distribution policy of 'always
ship the latest' *is* going to exacerbate the problem for any users.

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

Re: Schedule for Wednesday's FESCo Meeting (2013-12-18)

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johan...@gmail.com) said: 
> >So, instead of complaining about a process here, is there some actual
> >suggestion, input or proposal in reference to problem you would like to
> >provide?
> 
> This is and always has been taken care of by the QA community so
> needless to say we ( QA community ) will take care of it.

So, all I can go by is the bugzappers housekeeping page for each release,
where every single commit to the page or action item listed in the page
has been one of:

- Robyn
- Spot
- John Poelstra
- Jaroslav
- Kevin

since Fedora 15, at least.

Furthermore, the Housekeeping SOP page itself has not undergone a meaningful
(i.e, name replacement) update since 2010.

If the QA community is running the updating and execution of this process,
they are doing it very very quietly in other people's names, and I see no
reason to assume malice when someone went to the people that are actually
*written* in the wiki as having the action items to run the process.

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

Re: Problem changing symlink to directory with %pretrans scriptlet

[Bill Nottingham]

Richard Fearn (richardfe...@gmail.com) said: 
> On 28 December 2013 16:43, Bruno Wolff III  wrote:
> > https://fedoraproject.org/wiki/Packaging:Guidelines#The_.25pretrans_scriptlet
> > Notes that you need to use lua in pretrans scriptlets, not shell commands.
> 
> Thanks. I've already seen that. It doesn't seem to make any difference
> whether it's a bash scriptlet or a lua scriptlet, though; irrespective
> of what language is used to delete the symlink, the problem still
> occurs.
> 
> > I haven't found an example for you to copy, but note there are still some
> > cases where changing symlinks to directories or vise versa won't work with
> > rpm (https://bugzilla.redhat.com/show_bug.cgi?id=975909).
> 
> I think deleting the symlink manually may be revealing a problem in
> rpm. It seems to treat /usr/share/javadoc/test-1/
> hello (from the old
> package) and /usr/share/javadoc/test/hello (from the new package) as
> the same thing. Since the new package is installing
> /usr/share/javadoc/test/hello, it therefore decides to 'skip' the old
> 'hello' file, rather than 'erase' it.
> 
> I'm not sure yet why these two paths are considered to be the same...

I believe (but can't confirm ATM) that file disposition checks (i.e., which
files are added/removed/replaced) happen before pretrans scripts. So if
you're using pretrans scripts to change paths that were valid
pre-transaction to something else, weird results may happen.

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

Re: [Base] Proposal for buildrequires cleanup janitorial initiative

[Bill Nottingham]

Miloslav Trmač (m...@volny.cz) said: 
> >> During last weeks Base WG discussion about package set and self hosting
> >> of Base we came to a point where especially the self hosting of Base
> >> would currently look absurd as we'd require more than 2000 components to
> >> do so.
> >
> > Once you reduce the size of this set, do you forsee actually *enforcing*
> > this in some way?  For example, by having separate package repositories?
> >
> > If not, what's the point of this initiative?
> 
> Actually, even more generally - why a self-hosting Base at all?  It
> would clearly be absurd for the kernel to be self-hosting, and clearly
> we want "the Fedora universe" to be self-hosting.  Why is it
> worthwhile to have Base self-hosting?

Well, if we want 'the Fedora universe' to be self-hosting, where should
the compiler portion that implements the bottom layer of that live?

If it doesn't make sense in Cloud (definitely not), Server (maybe), or
Workstation (maybe)... then that either leaves Base, or a world where you're
building Base (and WS, and Server, and Cloud) using tools from 'the
universe' that itself is trying to build on Base. 

e.g., if base defines & standardizes on the minimal set of build packages,
that Server/WS/Cloud can then use to build themselves (or selectively
override), and the universe can then use (or selectively override), it
creates a clean heirarchy.

If the build environment instead lives in the Universe, and all of Base, and
Server/WS/Cloud use it... that makes Fedora still (in some respects) one big
package repo, and the products more like spins than actual separate products.

Whether the first of these is actually *doable* cleanly is still up in the
air, but I think that's some of the idea behind it.

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

Re: dnf versus yum

[Bill Nottingham]

Matthew Miller (mat...@fedoraproject.org) said: 
> I'm a little lost in the thread, but do you mean that yum's protected
> packages functionality is undocumented? If that is what you mean, check the
> man page. It says:
> 
>   protected_packages  This  is  a list of packages that yum should
>   never completely remove. They are  protected  via  Obsoletes  as
>   well as user/plugin removals.
> 
>   The  default  is:  yum  glob:/etc/yum/protected.d/*.conf  So any
>   packages which should be protected can do so by including a file
>   in /etc/yum/protected.d with their package name in it.
> 
>   Also  if  this  configuration  is set to anything, then yum will
>   protect the package corresponding to the running version of  the
>   kernel.

While documented, I do find this last bit of behavior extremely odd and
non-intuitive. (And hardcoded, no less.)

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

Re: F20: Puppet depchain pulls in Java

[Bill Nottingham]

Martin Langhoff (martin.langh...@gmail.com) said: 
> Puppet (the client side, at least) should be installable with
> relatively thin deps, so it can manage lightweight hosts...
> 
> I am having trouble disentangling which deps to file a bug against;
> maybe virt-what ?

You need to make sure your transaction is pulling in classic ruby
rather than jruby.

# repoquery  -q --whatprovides "ruby(runtime_executable)"
jruby-0:1.7.2-5.fc20.noarch
ruby-0:2.0.0.353-16.fc20.i686
ruby-0:2.0.0.353-16.fc20.x86_64

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

Re: Fedora Server PRD Draft and call for participation

[Bill Nottingham]

Stephen Gallagher (sgall...@redhat.com) said: 
> The first deliverable that the Fedora Server Working Group was tasked
> with was the production of a Product Requirements Document. This
> document is intended to provide a high-level view of the goals and
> primary deliverables of the Fedora Server distribution. A great deal
> of discussion has gone on during the weekly Working Group meetings as
> well as on the mailing list.

Admittedly late, but...

Vision

Fedora Server is the preferred [community] platform for system
administrators and developers seeking to deploy applications and services
that use the latest technology on a stable foundation with effective
resource utilization. 

How does this differentiate from the market position of CentOS (community
platform for deploying apps and services on a stable platform)? Do we care
if it doesn't?

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

Re: Environment and Stacks PRD

[Bill Nottingham]

Marcela Mašláňová (mmasl...@redhat.com) said: 
> Environment and Stacks Working Group approved the first version of
> PRD. Feel free to comment what is missing or what should be altered.
> 
> https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document

I don't see anything necessarily bad in what's written here, but the document
seems to jump very quickly from the Vision statement into an itemized list
of what appear to be work items, without an overarching framework or story
linking the two. (Maybe moving the user stories up helps here, maybe not.)
It seems hard to measure success against the vision for the group, as
opposed to just measuring the success as 'implemented task/goal X'.

Also, while it says that "[t]his document does not dictate implementation
details", the tasks and goals section does go into the weeds, especially in
the SCL & DevAssistant sections.

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

[perl-HTML-TableExtract/epel7] (3 commits) ...Fix requires.

[Bill Nottingham]

Summary of changes:

  51dda63... Perl 5.18 rebuild (*)
  567181b... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*)
  f5efb4b... Fix requires.

(*) 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

[perl-HTML-TableExtract] Fix requires.

[Bill Nottingham]

Summary of changes:

  f5efb4b... Fix requires. (*)

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

Re: Fedora.next in 2014 -- Big Picture and Themes

[Bill Nottingham]

Josh Boyer (jwbo...@fedoraproject.org) said: 
> I wasn't being dismissive.  I have seen no plans to alter the core of
> how Fedora, at a package level, is built.  In fact, if I did see a
> proposal that said "we're not going to ship repositories or RPMs" I'd
> be pretty damned upset, and I wouldn't support that.

To be fair, I do recall Matt's original rings proposal discussing a
core, different stacks on top of that, a 'commons' repository of packages, 
and things like COPRs on the outside.  While it's not proposing moving
away from repositories or RPMs, I did read that proposal as moving
away from the current paradigm of One Big Repo Of Everything in favor
of potentially multiple smaller repos. In that paradigm, things would
change somewhat for users even if they were ignoring the N products.

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

Re: I want to turn on a part of the kernel to make SELinux checking more stringent.

[Bill Nottingham]

Daniel J Walsh (dwa...@redhat.com) said: 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I wrote a systemd unit file to enable it, and to allow a user to disable the
> feature if he wants.

... why is this not a sysctl?

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

Re: Shipping package metadata in a package

[Bill Nottingham]

Richard Hughes (hughsi...@gmail.com) said: 
> I'm after some advice / ideas. When you install Fedora 20/21 and then
> launch gnome-software it has to go and download some metadata before
> it can show anything. This is a pretty bad first experience,
> considering subsequent runs of gnome-software just open straight away.
> GNOME Software operates on the logic that *any* version of the
> metadata is better than nothing, and only refreshes once a week when
> the user is idle.

(I assume that this is different than the normal repository metadata.)

I think starting this at some point during the initial-setup process or
during the gnome-software first startup is fine is fine ; I've seen many
other application stores that have this behavior where the first run is
slower than subsequent runs.  It could even be messaged in the UI - have it
start a tour of gnome-software on first run that shows the user how the
interface works & so on, as a distraction while the data is downloading.

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