Re: soname changing parted heading for rawhide

[Bill Nottingham]

Adam Williamson (awill...@redhat.com) said: 
> > [h...@localhost ~]$ sudo repoquery -q --whatrequires 
> > 'libparted-1.9.so.0()(64bit)'
> > qtparted-0:0.4.5-22.fc12.x86_64
> > DeviceKit-disks-0:009-3.fc12.x86_64 (now udisks)
> > gparted-0:0.4.8-1.fc12.x86_64
> > kde-partitionmanager-0:1.0.0-2.fc12.x86_64
> > libvirt-0:0.7.1-15.fc12.x86_64
> 
> nash also requires this, and has not yet been rebuilt. This also makes
> it basically impossible to update to Rawhide at present:
> 
> Error: Missing Dependency: libparted-1.9.so.0()(64bit) is needed by
> package nash-6.0.93-1.fc12.x86_64 (installed)
> 
> you can't exactly remove nash to let the update go through, since dracut
> and mkinitrd both depend on it.

dracut shouldn't require nash; mkinitrd has been blocked.

I suppose dracut needs to explicitly obsolete mkinitrd.

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

Re: Orphaning Candidate packages for removal due to FTBFS, implications

[Bill Nottingham]

Matt Domsch (matt_dom...@dell.com) said: 
> > With nobody handling the incoming bugzilla tickets. With some bug
> > reports having been killed in an automated way at dist EOL. And
> > worse if it turns out that packages which do build are unmaintained
> > nevertheless, with the same symptoms in bugzilla and in package scm.
> 
> We could easily create a new class of bugzilla ticket, say
> "MAINTAINED".  An automated process would generate such tickets,
> blocking F13MAINTAINED.  The ticket would ask the maintainer to close
> the ticket to remain the owner of the package.  Tickets still open
> after $SOMEDELAY would be candidates for orphan or non-responsive
> maintainer process.  Repeat at $SOMEINTERVAL, perhaps once per release
> cycle (more would be too onerous I think).

Ugh, this seems like it would just create a lot of make-work for the
common case where packages *are* maintained. Perhaps only do this
for packages that appear via some criteria (have not been built, have
not been committed to, have lots of bugs with no response, etc.), but
doing it for *every* package seems like overkill.

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

Re: yum-presto and comps

[Bill Nottingham]

Kevin Kofler (kevin.kof...@chello.at) said: 
> +1
> 
> In fact, we voted in FESCo that it should be added to one of the base groups 
> instead (@base, I guess). It makes no sense to have it in @gnome-desktop nor 
> in the KDE .ks file (which is where it is at the moment – for KDE, it's in 
> the .ks because we refused to add it to @kde-desktop as it has nothing to do 
> with KDE).

OK, fixed.

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

Re: yum-presto and comps

[Bill Nottingham]

Jens Petersen (peter...@redhat.com) said: 
> I meant to add that the reason this came up was I was trying to work out
> where to put yum-langpacks in comps: yum-presto being one of the reference
> packages I searched for.
> 
> So where can/should yum-langpacks live?

Probably in base. Now whether it would be default or optional

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

[RFC PATCH] use sulogin in single-user mode

[Bill Nottingham]

We have an existing bug where if you're in single-user mode, and
SELinux is active, various commands don't print to the console.
The root of this is the single-user shell isn't running in the
right SELinux context, as there's nothing to distinguish this from
the 'normal' shells run during bootup.

By far, the simplest fix is to run something that starts a shell
via a 'normal' login-ish mechanism. Hence, the attached patch
that switches to sulogin for single user mode.

However, this changes behavior that has existed since the dawn
of time in Red Hat/Fedora systems; with this change, single-user
mode would now require the root password. This is both when
booting with 'linux single/linux S', or going to runlevel 1
with 'telinit 1'.

Comments?

Bill
diff --git a/init/rcS-sulogin.conf b/init/rcS-sulogin.conf
index 4f1f1f1..60360aa 100644
--- a/init/rcS-sulogin.conf
+++ b/init/rcS-sulogin.conf
@@ -1,6 +1,6 @@
 # rcS-sulogin - "single-user" runlevel compatibility
 #
-# This task runs /bin/bash during "single-user" mode,
+# This task runs /sbin/sulogin during "single-user" mode,
 # then continues to the default runlevel.
 
 start on runlevel S
@@ -10,7 +10,7 @@ stop on runlevel [!S]
 console owner
 script
plymouth --hide-splash || true
-   exec /bin/bash
+   exec /sbin/sulogin
 end script
 post-stop script
if [ "$RUNLEVEL" = "S" ]; then
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [RFC PATCH] use sulogin in single-user mode

[Bill Nottingham]

Jon Ciesla (l...@jcomserv.net) said: 
> My thoughts exactly.  What are the less simple fixes that don't change 
> this behaviour?

Essentially, introducing new scripts solely for this purpose that can
be given a special label and some policy. It's a hack.

Note that you can still do without-password recovery with
init=/bin/bash.

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

Re: [RFC PATCH] use sulogin in single-user mode

[Bill Nottingham]

Chris Adams (cmad...@hiwaay.net) said: 
> How about moving /usr/bin/runcon to /bin and using that to call bash
> instead?

The problem is that the context it needs to run at isn't static; it
depends on the policy of the machine. Hence, you don't want to hardcode
a runcon call in the script.

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

Re: sysconfig ifcfg-* support for running custom post-up scripts per interface?

[Bill Nottingham]

Richard Zidlicky (r...@linux-m68k.org) said: 
> > .. just wondering why it's under /sbin and not under 
> > /etc/sysconfig/network-scripts/
> > 
> > It doesn't feel very good to add custom configuration under /sbin.
> 
> same opinion here. I have actually used this for a while, adds one more thing
> that needs be verified after system upgrades, not very nice. 

Realistically, the conglomeration of configuration and scripts in
/etc/sysconfing/network-scripts was never thought out well. But it's
not worth dealing with the historical baggage to change it now.

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

Re: sysconfig ifcfg-* support for running custom post-up scripts per interface?

[Bill Nottingham]

Tony Nelson (tonynel...@georgeanelson.com) said: 
> > > same opinion here. I have actually used this for a while, adds
> > > one more thing that needs be verified after system upgrades, not 
> > > very nice. 
> > 
> > Realistically, the conglomeration of configuration and scripts in
> > /etc/sysconfing/network-scripts was never thought out well. But it's
> > not worth dealing with the historical baggage to change it now.
> 
> Perhaps there should be a default /sbin/ifup-local script that 
> dispatches to /etc/sysconfig/network-scripts/ifup-local/?  
> It could contain useful comments, including that it is by default 
> replaceable as its target directory is empty by default.

... which would then try and overwrite any prior user-created files
in that place on upgrade.

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

Re: Multilib help?

[Bill Nottingham]

Richard W.M. Jones (rjo...@redhat.com) said: 
> Is there better documentation on how multilib works and how to resolve
> multilib problems than
> http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks ?  I
> understand that it uses various heuristics before it corrupts files,
> but those don't seem to be documented.
> 
> I just spent half a day tracking down a problem which turned out to be
> because multilib had corrupted a file, and I wish to solve this now
> once and for all.

'corrupted a file'? I'm really not sure what you mean here.

In any case, excessive verbiage follows:

...

Fedora, on certain architectures, supports multible binary ABIs.
This includes support for i386 on x86_64, and ppc64 on ppc.

Fedora supports these ABIs through a process called 'multi-arch'
or 'multilib', wherein the corresponding RPM packages for the secondary
arch are included along with their primary arch counterparts. These
packages are built via the same process as the primary arch packages,
and are identical to the packages that would be shipped in a 
release where that arch would be the primary arch.
 
The primary function of multilib support in Fedora is to provide a
runtime environment for applications to use. To satisfy this, packages
that provide runtime libraries are included for the secondary arch.

The secondary function of multilib support in Fedora is to provide
a development environment. To satisfy this, packages that provide
development headers are included for the secondary arch. However,
it should be noted that it is preferred to use a full system of
the appropriate architecture to do development where possible; this
can be done by using the 'mock' package to create an appropriate
chroot.

Multilib packages are intentionally not provided for system daemons
(for example, to run alternate-wordsize versions of Apache or
PostgreSQL.) If you need to run a non-default wordsize of a system
daemon, it is recommended that you install the system with a release
that supports that architecture as the primary architecture.

Not all packages produced by a particular source RPM are included as
multilib packages; only subpackages that implement runtime libraries
or development environments are included.

Whether or not multilib packages are installed by default is controlled by
the 'multilib_policy' configuration file parameter for yum. The default
value for Fedora of 'best' installs only packages for the primary
architecture. If this is changed to 'all' packages for all compatible
architectures will be installed by default. Note that this can only be
changed post-install; anaconda uses the default of only installing packages
for the primary arch.

You can still at any time install packages for a particular arch by passing
the architecture directly to yum. For example, running 'yum install
glibc.i686', or putting 'glibc.i686' in a kickstart %packages stanza, will
install the 32-bit x86 version of glibc.

When installed in parallel, multilib RPM packages may contain files that
live in common paths. When this happens, RPM uses the following algorithm:

- If the file in both packages is identical, installation is allowed
  and the file is written
- If the file in both packages is an ELF binary, the file used is the
  file in the package for the primary architecture
- If the file in both packages is not an ELF binary a RPM conflict is
  raised

If such conflicts are raised with packages in the Fedora tree, it can
be considered a packaging bug that needs to be fixed.

...

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

Re: Moving lspci and setpci from /sbin to /usr/sbin?

[Bill Nottingham]

Michal Hlavinka (mhlav...@redhat.com) said: 
> Do you think moving this is a bad idea? I think it should not break anything, 
> only problem can be with separate /usr partition but because of library in 
> /usr it would be already broken and I've not seen any complain about it ever.

Furthermore, most all of the information provided by lspci in a no-/usr
recovery situation can be found in /sys if absolutely necessary.

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

Re: abrt not working in current Rawhide?

[Bill Nottingham]

Adam Williamson (awill...@redhat.com) said: 
> Just checking if I'm the only one - I can't find a bug report, though
> I'll probably file one. abrt doesn't seem to work in current Rawhide.
> The daemon and applet both claim to be running, but I never get an abrt
> pop-up when anything crashes (which happens a lot in current Rawhide...)

Incompatiblity with the 2.6.32 kernel (it's in bugzilla).

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

Re: New merge review tickets being opened

[Bill Nottingham]

Jason L Tibbitts III (ti...@math.uh.edu) said: 
> Some Red Hat employees are opening new merge review tickets for packages
> which were in extras long before the big core-extras merge.  It looks
> like all of these packages are so old that the reviews predate the use
> of Red Hat's bugzilla for the purpose, and so those reviews were either
> done on the old mailing list or in the old fedora.us bugzilla (which I
> believe has been lost).
> 
> No Fedora policy requires that these packages be re-reviewed.  The
> evidence seems to point to some Red Hat policy requiring review tickets
> for these packages, although I can't seem to get a proper answer from
> someone who actually knows.

There is a new internal process that encourages that packages have
existing Fedora reviews. This is likely a consequence of that, although
it's certainly never mentioned directly in the process. (I'd suspect that
there is likely to be some uptick in merge review activity as well.)

> Given that the reviewers are currently
> overburdened and are barely able to keep up with existing submissions,
> plus the fact that we still have a few hundred of the original merge
> review tickets still open, I don't think that adding more to the pile is
> going to be remotely helpful.  If there's a Red Hat policy which
> requires this, then Red Hat should be taking care of this instead of
> leaving it to the overburdened Fedora community.  The fact that there's
> been no communication about it only adds insult to injury.
> 
> I propose that the 'Product' on these tickets be changed to something
> other than 'Fedora' so that they don't appear to be part of any Fedora
> process.  I'm happy to do that if someone can tell me which component to
> use.

How so? They're reviews of Fedora packages. If the queue's not being
processed quickly, the queue won't be processed quickly. If these reviews
need quick attention, then I suspect resources will need to be assigned
to them. If they don't, then they won't. I'm not convinced that adding
12 packages to the queue (the current count of these) is anything to
worry about, given that we get more new submissions than that per
week already without any other controls.

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

Re: --host=i386-redhat-linux-gnu --target=i686-redhat-linux-gnu ???

[Bill Nottingham]

Owen Taylor (otay...@redhat.com) said: 
> Looking at the build logs for F-12, e.g.:
> 
> http://kojipkgs.fedoraproject.org/packages/glib2/2.22.4/1.fc12/data/logs/i686/build.log
> 
> we seem to have things set up to run configure as:
> 
>  --build=i386-redhat-linux-gnu
>  --host=i386-redhat-linux-gnu
>  --target=i686-redhat-linux-gnu

This comes from the rpm %configure macro, which hasn't changed:

  ./configure --build=%{_build} --host=%{_host} \\\
--target=%{_target_platform} \\\

%{_host} is set by the rpm package in the macros file, %{_build} defaults
to the value of %{_host}. %{_target_platform} comes from --target on
the command line, plus the usual vendor/OS bits

--target is what is set by rpm/mock. I think it defaults to %{_host}
if it's not otherwise specified, but we specify it when building for i686,
as we could theoretically still build i386 packages.

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

Re: [RFC PATCH] use sulogin in single-user mode

[Bill Nottingham]

Chris Adams (cmad...@hiwaay.net) said: 
> One other note about this: this would break with a separate /usr and a
> failure in mounting /usr, because (at least in F12) /sbin/sulogin is
> linked against libfreebl3.so (which is in /usr/lib{,64}).  It looks like
> libfreebl3.so was moved from /lib{,64} in F11 to /usr/lib{,64} in F12,
> but the changelog doesn't say why.

This is being fixed.

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

Re: --host=i386-redhat-linux-gnu --target=i686-redhat-linux-gnu ???

[Bill Nottingham]

Panu Matilainen (pmati...@laiskiainen.org) said: 
> > %{_host} is set by the rpm package in the macros file, %{_build} defaults
> > to the value of %{_host}. %{_target_platform} comes from --target on
> > the command line, plus the usual vendor/OS bits
> >
> > --target is what is set by rpm/mock. I think it defaults to %{_host}
> > if it's not otherwise specified, but we specify it when building for i686,
> > as we could theoretically still build i386 packages.
> 
> Yup, and all wonderfully mixed up - rpm's idea of --target is something 
> completely different from what auto*foo from this century thinks of it. 
> Dunno if it ever was really valid but certainly not anymore.
> 
> rpm >= 4.8.0 no longer sets the --target on %configure but that's been 
> masked by the redhat-rpm-config version of %configure. That's been fixed 
> too as of today.

Is either %_host or %_build set based on --target?

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

Re: Board efforts: scope, concept, and permission?

[Bill Nottingham]

Toshio Kuratomi (a.bad...@gmail.com) said: 
> I think that the Fedora Project's target audience needs to be people who
> want to work on open source operating systems.  If you want to market the
> Fedora Project, that's the audience that needs to be addressed.
> 
> If you want to market a physical product, like the Fedora Desktop Spin, then
> that should be a decision made below the Board level.  Making a decision
> about the target audience of the various distributions that we have limits
> the choices of the people who want to work on open source operating systems.
> Making a target audience decision at the SIG level widens the choices as
> marketing/artistic/documentation/etc people can choose which audiences they
> want to address via which medium.

I don't find this completely workable. By decreeing this sort of non-target
for the project, and limiting Spin maintainers to only changes in the
package set, but not the packages themselves (as we do), you're essentially 
telling them they'll never be able to attack their target audience *well*.

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

Re: Board efforts: scope, concept, and permission?

[Bill Nottingham]

Toshio Kuratomi (a.bad...@gmail.com) said: 
> My other mail suggests that one way to work with this is to create new
> conflicting packages that are optimized for the different usages.  There's
> other ways as well but the general theme is that we need to be looking at
> ways to open up what people can do with the raw material of the Fedora
> Project to create their vision of a free software operating system rather
> than closing off what Fedora can be good for and making it so that certain
> visions are second class citizens that can only advance as long as they
> don't conflict with a different, specific vision.

Would that mean that users who don't start with one of these 'products'
get to magically try and choose which implementation of which they want?
Perhaps even mix and match, leaving QA and the developers to sort out
the results.

Furthermore, you then leave 'downstream' higher-level packages and
applications having to, for example, code to PolicyKit0, PolicyKit1, or
consolehelper, depending on what each 'product' use case might use. Or,
having to build their python extensions simultaneously for python2.4, python2.6,
and python3.0. These sorts of things would be extremely painful for
developers, and would bloat the QA matrix excessively.

Not to reduce the debate to too much of a soundbite, but it almost
seems like attempting to decide whether we want Fedora to be Debian,
or to be something useful for users of it. I'd always pick the latter...

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

Re: Board efforts: scope, concept, and permission?

[Bill Nottingham]

Adam Miller (maxamill...@fedoraproject.org) said: 
> > Furthermore, you then leave 'downstream' higher-level packages and
> > applications having to, for example, code to PolicyKit0, PolicyKit1, or
> > consolehelper, depending on what each 'product' use case might use. Or,
> > having to build their python extensions simultaneously for python2.4, 
> > python2.6,
> > and python3.0. These sorts of things would be extremely painful for
> > developers, and would bloat the QA matrix excessively.
> 
> I think the responsibility of these things should be placed upon the
> SIG members who perform the functions from within these different
> groups. Why not have a QA person from each SIG work together with the
> larger QA efforts instead of potentially against them?

Take a random downstream app. (Firefox is an example, but there are many
others.) Right now, it only needs to track a single version of python,
or a single auth framework, even if it may be used on any desktop or any
spin. The implication is that in some sort of future with SIG-specific
conflicting frameworks, this downstream app maintainer now must be familiar
with, and handle *all* of the frameworks, even though they're not
specifcally a part of any SIG. That's sort of a rotten thing to do to
Joe Random Maintainer. 

You could say that the SIG needs to then supply people to handle every
potential downstream app, but that's also not nice, and is going to lead
to fun coordination with updates.

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

Re: Board efforts: scope, concept, and permission?

[Bill Nottingham]

Adam Miller (maxamill...@fedoraproject.org) said: 
> On Tue, Feb 2, 2010 at 2:29 PM, Bill Nottingham  wrote:
> 
> > Take a random downstream app. (Firefox is an example, but there are many
> > others.) Right now, it only needs to track a single version of python,
> > or a single auth framework, even if it may be used on any desktop or any
> > spin. The implication is that in some sort of future with SIG-specific
> > conflicting frameworks, this downstream app maintainer now must be familiar
> > with, and handle *all* of the frameworks, even though they're not
> > specifcally a part of any SIG. That's sort of a rotten thing to do to
> > Joe Random Maintainer.
> >
> > You could say that the SIG needs to then supply people to handle every
> > potential downstream app, but that's also not nice, and is going to lead
> > to fun coordination with updates.
> 
> 
> I don't think that's an issue either, I'm not proposing we change
> anything such that it could cause problems.

Toshio was, and that's what I'm responding to.

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

Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Bill Nottingham]

Lennart Poettering (mzerq...@0pointer.de) said: 
> And here's another addition: you might also want to run this command
> when upgrading from older rwahide to current F-14/rawhide:
> 
>   # systemctl enable graphical.target
> 
> This makes sure the default.target link is created properly

I still believe that for this particular one (and a few of the others) we
should make the trivial changes to the spec to have it done automatically.

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

Re: [ACTION REQUIRED] orphaned packages in F-14

[Bill Nottingham]

Michael Schwendt (mschwe...@gmail.com) said: 
> > Unblocked orphan librsvg2
> 
> What's going on here?

The procedure used to be for various gnome-y packages in the days
before provenpackager to just assign a single maintainer and
a whole slew of co-maintainers, so anyone in the Desktop SIG could
update the package. I suspect what happened is then whoever drew
the straw of 'maintainer' for this package left Red Hat, so it
shows up as officially orphaned.

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

Re: [ACTION REQUIRED] orphaned packages in F-14

[Bill Nottingham]

Petr Pisar (ppi...@redhat.com) said: 
> > I suggest that these be just built without NAS support. NAS is basically an 
> > older competitor to PulseAudio with fewer features (it focuses on network 
> > transparency, which is just one of the things PulseAudio does), it is not 
> > compatible with PulseAudio, few to no people use it.
> >
> I agree NAS is very old audio system, but it has history. It works (or
> should work) across operating systems (do not think only about Linux).
> In addition it supports bidirectional sound transmission (from
> microphone).
> 
> PulseAudio is interresting project, but it's absolutely unusable on old
> slow hardware. Last time I checked it out on Pentium TSC (no MMX)
> running at 200 MHz, it consumed 20 % of CPU just in idle mode. While
> `playing', it congested CPU, printed some warnings about stream buffer
> overflow and terminated gracefully complaining about no CPU cycles. NAS
> or Esound work on the machine fluently.

Given that that's not the hardware target we're looking at in Fedora,
perhaps some effort could be spent in determining where the performance
issues lie in PA in an effort to fix the experience for everyone, rather than
maintaining parallel implementations that provide little benefit to the
userbase as a whole?

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

Re: Plan for tomorrow's FESCo meeting (2010-08-10)

[Bill Nottingham]

Michael Schwendt (mschwe...@gmail.com) said: 
> >   * LINK: http://fedoraproject.org/PackageReviewStatus/MERGE.html
> > (nirik, 19:59:05)
> >   * AGREED: : encourage provenpackagers to commit to rawhide fixes for
> > merge reviews. said pp's should not be the reviewer.
> 
> Pardon? What exactly is the problem here with a pp being the one to find
> an issue *and* commit the fix?

Just saying that the person to commit the fixes found in the review
should (IMO) not be the reviewer themselves, even if they happen to
be a provenpackager. It allows for a having a second set of eyes on the
changes in the case where the maintainer may not have responded.

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

Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Bill Nottingham]

Lennart Poettering (mzerq...@0pointer.de) said: 
> > Yes, that is correct.  An already built version on f15 will always be
> > "newer" than anything coming up from f14.
> 
> Can I "undo" such a build? I did that mostly because I forgot that the
> branching already happened when I built systemd the first time after the
> branching.

If the version in dist-f14 is newer, then yes, you can do

koji untag-pkg dist-f15 

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

Re: The slip down memory lane

[Bill Nottingham]

Matthias Clasen (mcla...@redhat.com) said: 
> >   This is a collective failure.
> 
> I'd like to question that premise. Why is it a failure if we adjust our
> release schedule to meet our release criteria ?

Well, ideally we'd be able to schedule such that we can accomplish
our release criteria within the defined schedule without having to
slip.

I can't help but note that the slips have become more frequent as we
started to actually *have* release criteria to test against. We
didn't slip nearly as much when we weren't testing it. (Whether that's
a good or bad thing is left as an exercise for the reader.)

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

Re: F14/F13 - system-config-display - should it work?

[Bill Nottingham]

Felix Miata (mrma...@earthlink.net) said: 
> So users of absent or dysfunctional DDC and/or EDID should be committed to
> 800x600 or 1024x768 @96DPI until they replace their (quality, antique, still
> working just fine) displays

Just as a point, if the EDID/DDC is dysfunctional, then I don't think that
really qualifies as 'quality' and 'working just fine'. Carry on...

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

Re: The slip down memory lane

[Bill Nottingham]

Jon Ciesla (l...@jcomserv.net) said: 
> I disagree that a clockwork release schedule is required for quality, or 
> even perceived quality.  If that's the sort of metric being looked at, 
> the user is probably best suited to RHEL, CentOS, etc.

It would be interesting to look at RHEL/CentOS to see how predictable
their release schedule actually is. I'd wager it's not that predictable
either.

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

Re: New bodhi release in production

[Bill Nottingham]

Toshio Kuratomi (a.bad...@gmail.com) said: 
> So I've kept my voice out of this... and hopefully, now that you know that
> it's not just hte KDE SIG, I can go back to doing so again.

... how does that help?

You've mentioned that you don't like 'this change' ... which part of it are
you referring to? The changes in what critical path entails? The change to
handling of non-critical path? The entire idea of bodhi? etc.

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

Re: New bodhi release in production

[Bill Nottingham]

Ryan Rix (r...@n.rix.si) said: 
> available (sometimes in front of it)... Yet even now, we can't keep up with 
> what (some of) our users want: the latest KDE, on KDE's release day, whether 
> it's a major release, or a point release. Yes, not every one of our users is 
> this way, but many are, and many use Fedora for this very reason. How do we 
> keep everyone happy?

I think the simplest way is to start with a stable repo, for those that want
that, and then build something on top of that? You can build some
faster-moving feature packages on top of a stable base for those that want
it. You can't do the reverse. (See the 'optional repo for feature updates' 
that's
in the propsal... I suspect that people would love help in getting that set up
and running sanely.)  

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

[ACTION REQUIRED, v2] orphaned packages in F-14

[Bill Nottingham]

The attached list shows currently orphaned packages in F-14. If they are
not claimed by the end of next week, they will be blocked, potentially
breaking dependencies (and causing more things to be blocked...)

If you already co-maintain the package, please step up and take it.
(If you don't, it may be assigned to you anyway.) Otherwise, volunteers would
be appreciated for those packages that other things require.

Bill

Orphan JSDoc
Orphan bzr-gtk
comaintained by: shahms
Orphan cdf
Orphan classworlds
comaintained by: dbhole
Orphan crun
Orphan django-authopenid
Orphan dom4j
comaintained by: dbhole
Orphan drgeo
Orphan drgeo-doc
Orphan drpython
Orphan dtdparser
comaintained by: dbhole
Orphan fet
comaintained by: fab
Orphan fish
comaintained by: oliver
Orphan gg2
Orphan gnome-vfsmm26
Orphan gnomecatalog
Orphan gperiodic
Orphan hsqldb
comaintained by: fnasser
Orphan impressive
Orphan isorelax
Orphan jlex
Orphan jrefactory
Orphan jzlib
Orphan kasablanca
comaintained by: tuxbrewr rdieter
Orphan kflickr
Orphan ldapjdk
Orphan libgnomecanvasmm26
Orphan libgnomemm26
Orphan libgnomeuimm26
Orphan libmspack
Orphan libpanelappletmm
Orphan libsigc++
Orphan lucene
Orphan mapbender
Orphan mapserver
comaintained by: devrim oliver
Orphan mediawiki-HNP
Orphan mediawiki-StubManager
Orphan minirpc
Orphan nettle
Orphan nodm
Orphan objectweb-anttask
Orphan ogdi
Orphan pAgenda
Orphan papercut
Orphan pastebin
Orphan php-channel-phpdb
Orphan php-pear-Phlickr
Orphan php-pear-creole
Orphan php-pear-pake
Orphan php-pear-propel_generator
Orphan php-pear-propel_runtime
Orphan pitivi
Orphan plexus-ant-factory
Orphan plexus-appserver
Orphan plexus-bsh-factory
Orphan plexus-compiler
Orphan plexus-runtime-builder
Orphan plexus-xmlrpc
comaintained by: fnasser
Orphan poker-engine
Orphan poker-eval
Orphan poker-network
Orphan poker2d
Orphan poker3d
Orphan poker3d-data
Orphan pycairo
Orphan pyfacebook
Orphan pyorbit
Orphan pypoker-eval
Orphan python-numarray
Orphan python-urllib2_kerberos
Orphan python-zc-lockfile
comaintained by: cheeselee
Orphan python-zdaemon
comaintained by: cheeselee
Orphan python-zope-event
comaintained by: cheeselee
Orphan python-zope-testing
comaintained by: cheeselee
Orphan qosmic
Orphan relaxngDatatype
comaintained by: dbhole
Orphan ruby-activerecord
Orphan spambayes
Orphan stardict-dic-en
comaintained by: kaio
Orphan stardict-dic-ja
comaintained by: kaio
Orphan stardict-dic-ru
comaintained by: kaio
Orphan stardict-dic-zh_CN
comaintained by: kaio
Orphan stardict-dic-zh_TW
comaintained by: kaio
Orphan taipeifonts
comaintained by: kaio
Orphan tanukiwrapper
comaintained by: devrim
Orphan tinyows
Orphan tomcat6
comaintained by: dwalluck akurtakov dknox
Orphan tpb
Orphan tremfusion
Orphan twitux
Orphan vgabios
Orphan windowlab
Orphan ws-jaxme
comaintained by: dbhole
Orphan x2vnc
Orphan xenwatch
Orphan xjavadoc
Orphan xmldb-api
comaintained by: dbhole
Orphan xmlrpc
comaintained by: devrim
Orphan xom
comaintained by: dbhole
Orphan xpp2
comaintained by: dbhole
Orphan xpp3
comaintained by: dbhole
Orphan xwnc

List of deps left behind by orphan removal:

Orphan: classworlds
intellij-idea requires classworlds = 1.1-4.fc12
maven-doxia requires classworlds = 1.1-4.fc12
maven-doxia-sitetools requires classworlds = 1.1-4.fc12
maven-surefire requires classworlds = 1.1-4.fc12
maven-wagon requires classworlds = 1.1-4.fc12
maven2 requires classworlds = 1.1-4.fc12
mercury requires classworlds = 1.1-4.fc12
modello requires classworlds = 1.1-4.fc12
plexus-ant-factory requires classworlds = 1.1-4.fc12
plexus-appserver requires classworlds = 1.1-4.fc12
plexus-archiver requires classworlds = 1.1-4.fc12
plexus-bsh-factory requires classworlds = 1.1-4.fc12
plexus-compiler requires classworlds = 1.1-4.fc12
plexus-container-default requires classworlds = 1.1-4.fc12
plexus-i18n requires classworlds = 1.1-4.fc12
plexus-resources requires classworlds = 1.1-4.fc12
plexus-velocity requires classworlds = 1.1-4.fc12
plexus-xmlrpc requires classworlds = 1.1-4.fc12

Orphan: dom4j
bolzplatz2006 requires dom4j = 1.6.1-5.fc12
eclipse-checkstyle requires dom4j = 1.6.1-5.fc12
freemarker requires dom4j = 1.6.1-5.fc12
itext requires dom4j = 1.6.1-5.fc12
itext-rups requires dom4j = 1.6.1-5.fc12
jaxen requires dom4j = 1.6.1-5.fc12
json-lib requires dom4j = 1.6.1-5.fc12
logback requires dom4j = 1.6.1-5.fc12
maven-eclipse-plugin requires dom4j = 1.6.1-5.fc12
maven-shared-model-converter requires dom4j = 1.6.1-5.fc12
saxon requires dom4j = 1.6.1-5.fc12
xstream requires dom4j = 1.6.1-5.fc12

Orphan: drgeo
drgeo-doc requires drgeo = 1.1.0-16.fc12

Orphan: dtdparser
modello requires dtdparser = 1.21-7.fc12

Orphan: gno

Re: systemd and filesystems with noauto

[Bill Nottingham]

Lennart Poettering (mzerq...@0pointer.de) said: 
> So, to turn this around. Do you think this behaviour is problematic? Can
> you make a good case for dropping this automatism? If so I'd be willing
> to do so.

Yes, 'noauto' has defined semantics of 'not automatically mounted at boot';
breaking that is bad.

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

Re: systemd and changes

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> So, I'm honestly asking: what are the odds that these few things are the
> only improvements that cause a disruptive change to user interaction? I
> don't think it's unreasonable to wonder if there are other changes which fit
> this category.

My concern with this line of thinking is that you're asking us to quantify
the unknown unknown, and define a time period of testing which is
'long enough' for us to catch all the unknown unknowns. This seems
impractical, in as much as it doesn't give us any clear criteria to define
success with.

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

Re: systemd and changes

[Bill Nottingham]

Mike McGrath (mmcgr...@redhat.com) said: 
> > My concern with this line of thinking is that you're asking us to quantify
> > the unknown unknown, and define a time period of testing which is
> > 'long enough' for us to catch all the unknown unknowns. This seems
> > impractical, in as much as it doesn't give us any clear criteria to define
> > success with.
> 
> It's just risk management.  I think we'd be better off acknowledging there
> are unknown unknowns and try to mitigate them.

Sure, but when you say 'we should hold off X period of time' in order to
mitigate unknown unknowns, how do you define 'X'? How do you know when it's
ready? All I'm seeing are appeals to gut feelings. We can all say that 'more
time == more testing', but how do you claim 'good enough'?

> ready.  Unfortunately that's not the path we seem to be on.  We unwisely
> seemed to declare it ready before anyone even saw it then we ignored what
> we didn't know as if we knew there were going to be no problems.  The sad
> thing is that's such an easy fix by making brand new features for core
> components like this opt in, even if it's just for a single release.

Having to support multiple boot paths for the system, making everyone
who gets odd bugs filed against kernel, dracut, plymouth, etc. triage them
isn't exactly an 'easy fix' - it *adds* complication to both paths.

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

systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

(intentionally breaking thread)

Toshio Kuratomi (a.bad...@gmail.com) said: 
> Maybe I should start a new thread since this isn't really a bug, but it is
> a blocker -- we need to get some packaging guidelines out for systemd.
> I think that the last message on the subject was this one:
> 
> http://lists.fedoraproject.org/pipermail/devel/2010-July/139483.html
> 
> Could I get a reply as to whether that looks right?

- At the moment, /bin/systemctl is in systemd-units. (I think this
  is a bug. Filed.)
- As long as we're still shipping upstart, the sysv scripts would still
  need included, and would still need to be set up with chkconfig the
  same way.

> As noted in the post, I'm not sure if the outlined procedure correctly
> implements level 1.

I believe it does.

> We should probably also have the scriptlets for implementing level 3 for the
> things basic to the system that require that.

My reading of your mail is different - the case we want to handle is case
#2 (installation of something that starts by default - dbus, NM, etc.)

As I understand it, they would be the same, with the addition of:

%post
if [ 0$1 -eq ]; then
/bin/systemctl enable 
fi

with foo.service having the appropriate [Install] stanza that says where it
should start up. As with SysV scripts, we generally do not start services
by default, so this is rare.

Case #3 that you mentioned is something I don't think we have in Fedora - 
we never start services on package installation.

This, however, is just packaging guidelines. From readng the thread, there
are many things that I think people would like covered with systemd before
they would feel comfortable with it. So, I'm going to attempt to quantify
what would need to be tested and verified. This document focuses on
backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes,
etc. welcome.

BOOTUP
- System boots successfully to GUI, when configured.
- System boots successfully to text mode, when configured.
- System properly handles being passed [1-5], 'single', 'S', 's', '-s',
  booting to the appropriate 'runlevel' (0 and 6 can still work,
  but they're sort of pointless anyway) When booted in this manner,
  '5' will bring up a GUI, and '3' will not.

SINGLE USER MODE
- Exiting single user mode properly returns to the default state.
- single-user mode output is correctly displayed on the console.
 
PLYMOUTH
- plymouth is shown on startup.
- plymouth is quit correctly.
- plymouth is shown on shutdown.
- 'esc' to show details still functions in plymouth.
- an equivalent to /var/log/boot.log still exists, and is populated
  (can be normal syslog)
- plymouth transition from grub -> boot -> X is seamless for KMS cards,
  similar to Fedora 13.

RUNTIME TOOLS
- telinit [0123456] does the proper thing.
- the 'runlevel' command displays correct output if we are in a target
  that is aliased to a runlevel.
- 'halt' shuts down, but does not poweroff.
-- 'halt' supports -p, to power off.
- 'poweroff' shuts down, and powers off.
- 'reboot' shuts down and reboots.
- 'halt', 'poweroff', 'reboot' all support '-f', to force the action.
- 'halt', 'poweroff', 'reboot' all properly log to utmp, wtmp, and
  the audit layer.
- 'shutdown' shall support the following arguments in a compatible manner:
  'r', 'h', 'H', 'P', 'c', 'k', .
- 'telinit' does not error when passed '[Qq]' (to reload its configuration)
  and '[Uu]' to re-exec itself. It can optionally make systemd do a similar
  action, if valid.
- init shall support a mechanism to re-exec itself to not cause dirty
  inodes on shutdown; initscripts will use this method on shutdown.
- the kbdrequest job currently in systemd will be disabled for final release.
- 'ctrl-alt-delete' will reboot the system.

PREFDM
- prefdm starts a configured display manager correctly.
- prefdm starts a installed display manager correctly without additional
  configuration.

CONSOLEKIT
- ConsoleKit properly logs system start, stop, and restart.
- The ConsoleKit shutdown/reboot/halt methods work as expected.
SERIAL CONSOLES
- Booting with a primary serial console (via console=) automatically
  sets up a getty on the console, and sets up securetty to allow for root
  login.
- (optional) Booting with secondary serial consoles does the same.

NON-SERIAL CONSOLES
- By default, 6 gettys will be started in text mode, on tty1-6. 5
  gettys will be started in GUI mode, on tty2-6.
- getty and X will not be started on the same tty.
- (optional) The number of ttys started can be configurable.

ERROR HANDLING
- SELinux automatic relabelling will still function.
- fsck will still function.
- Dropping to an emergency shell in the case where either of these fails
  shall still function.

SELINUX
- No AVCs from the init system in normal use.
- No AVCs when executing any of the cases specified here
- systemd shall still function if booted with selinux=0.

PACKAGING
- Guidelines for packaging systemd units shall be formalized.
- The behavior when both systemd unit

Re: Packages on which Thunderbird functionality depends!

[Bill Nottingham]

Stephen Gallagher (sgall...@redhat.com) said: 
> I'm not a Thunderbird maintainer, so I don't know how feasible this is,
> but perhaps we could create a subpackage like
> 'thunderbird-sound-support' that has the appropriate dependencies on it.
> Then at least someone doing a yum search on thunderbird would notice
> that and assume they probably wanted it (if they're hitting the same issue).

Just changing the package requires seems far simpler to me.

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

Re: F-14 Branched report: 20100824 changes

[Bill Nottingham]

Richard W.M. Jones (rjo...@redhat.com) said: 
> On Tue, Aug 24, 2010 at 04:42:17PM +, Branched Report wrote:
> > 1:libguestfs-1.5.2-4.fc14.i686 requires /lib/libxtables.so.4
> 
> This seems to be a warning about an older version than what's
> currently in F14:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=190165
> https://admin.fedoraproject.org/updates/libguestfs-1.5.2-7.fc14

That update is in updates-testing, not the final branched tree.

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

Re: Bodhi updates

[Bill Nottingham]

Stephen Gallagher (sgall...@redhat.com) said: 
> Bodhi updates can have multiple packages associated with a single update
> as long as they are on different branches. Why this restriction?
> 
> At least in the case of something like a security update, I would think
> that it would be beneficial to be able to push the update to all
> branches simultaneously.

The push process is not atomic across branches... you can, for, example,
as a releng member only push dist-f13-updates-testing.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> How about: 
> 
> - If /etc/inittab exists and contains an initdefault line, the default
>   target will be set accordingly.
> - any other non-comment, non-blank lines in /etc/inittab will be logged as
>   warnings.
> 
> This leaves a migration path (ditch the file completely) while maintaining
> some backwards compatibility. For a number of releases, the file can
> continue to exist with a warning in the comments and the release notes, and
> then eventually it can go away.

As stated in the bug, this would lead to a situation where you could
have both a initdefault line, and a default.target symlnk, that select
different things. How would you arbitrate?

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Miroslav Lichvar (mlich...@redhat.com) said: 
> On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote:
> > SERVICE HANDLING
> > - Running 'chkconfig  <(null)|on|off>' on a service managed by systemd
> >   will return the correct code/perform an appropriate action.
> 
> Also, if chkconfig --add called "systemctl enable" when the sysv
> script is enabled, most of the current scriptlets probably wouldn't
> need any changes. The status of systemd and sysv services would be
> required to stay in sync though.

They're not equivalent.

chkconfig --add does not change the state of a default-enabled service
that the administrator has disabled.

systemctl enable does change the state in this case.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Matthias Clasen (mcla...@redhat.com) said: 
> > BOOTUP
> > - System boots successfully to GUI, when configured.
> > - System boots successfully to text mode, when configured.
> > - System properly handles being passed [1-5], 'single', 'S', 's', '-s',
> >   booting to the appropriate 'runlevel' (0 and 6 can still work,
> >   but they're sort of pointless anyway) When booted in this manner,
> >   '5' will bring up a GUI, and '3' will not.
> 
> You mean 'being passed on the kernel cmdline', I assume ?

Yes.

> Do we consider interactive boot essential (I think not) ?

This seems rather complicated, given the parallel nature of how systemd
starts things.

> Should mention something about forced fsck, maybe.
> What about selinux relabeling ?

Booting with 'forcefsck', 'fastboot', and 'autorelabel' should continue to
function.

> > PACKAGING
> > - Guidelines for packaging systemd units shall be formalized.
> > - The behavior when both systemd units and SysV services are present on
> >   the system shall be defined. This includes defined behavior when a
> >   service appears to be 'enabled' for SysV links while 'disabled' for
> >   systemd (and vice-versa).
> > - The syntax of systemd units shall be frozen for the release (all future
> >   releases? Some set number of releases?)
> 
> Can you clarify this a bit ? I assume what we want is that future
> systemd releases remain backwards compatible with systemd units of
> today.

Yes. The idea is that if someone writes a systemd unit file today, they're
not going to need to change its syntax, or where they put it, or how they
enable it in future releases, unless they're changing it to use *new*
features of systemd.

> > GENERAL SANITY
> > - Booting a system shall achieve a similar result as booting in upstart:
> > -- The same set of services will be started.
> 
> I don't think this is a requirement on systemd, really. If we make
> changes to the default system configuration to not include a service in
> F14 that was included in F13, that is not a systemd problem. So, I think
> what you really mean here is: systemd will start all services that are
> configured to be included in the default install (and dependencies), but
> no others.

I meant 'as booting in upstart on the same release'. It's still an option
in the F-14 branched tree.

> > -- The services shall function the same.
> 
> This is again not really much of a systemd requirement.

It's a place where systemd can cause regressions due to the change in
how services are started. See the current (now fixed?) NetworkManager problems.

> > ORDERING
> > - rc.local will run as the final service on bootup.
> > - gettys will not start until after rc.local.
> 
> These two seem contradictory, at first sight...

I wasn't treating gettys as a service, but we can reword this.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

seth vidal (skvi...@fedoraproject.org) said: 
> > > You mean 'being passed on the kernel cmdline', I assume ?
> > > Do we consider interactive boot essential (I think not) ?
> > > Should mention something about forced fsck, maybe.
> > > What about selinux relabeling ?
> > 
> > I can't remember interactive boot ever working.
> 
> It always worked for me - and it saved my arse a number of times when a
> service starting up would go haywire and hang the system.

The keyboard shortcut has not worked reliably in quite a while (and
is already removed in F-14 - the command line option is there.)

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

Re: systemd and changes

[Bill Nottingham]

Lennart Poettering (mzerq...@0pointer.de) said: 
> BTW, was there a written down policy on how to package Upstart
> jobs/services?

Yes. It was "Don't". (Specifically because issues like this weren't
answered.)

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

Re: systemd and changes

[Bill Nottingham]

Till Maas (opensou...@till.name) said: 
> I did not want to imply that PulseAudio is useless. I doubt that you
> would have implemented it, if you did not have any use for it. Probably
> a lot of people who bought their soundcard without considering to buy
> one capable of hardware mixing will also benefit from it. But usually
> these people work not that actively in a FOSS community.

I suspect the vast majority of people in F/OSS (including Fedora) don't
buy sound cards, period, any more.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> > The intent is not to do so in the final release, AIUI. We're only
> > keeping it around during pre-release, so that if we decide we need to
> > fall back to upstart for final release, it's easy to do. As far as I
> > know, the plan is to decide later (presumably after beta) which one
> > we're going with, and dump the other.
> 
> Making a big change like that _after_ beta seems like an invitation to
> trouble, but I'll give the benefit of the doubt to you as the QA guy. So in
> that case, the requirement could simply be that at the time of the beta,
> they do basically the same things, or in cases where they do different
> things, it is 1) intentional *and* 2) documented.

My concern is with maintaining two init systems for the life of the release.
We have two potential situations:

- We decide to punt systemd by default to F-15.

In this case, maintaining systemd in F-14 actively hurts your ability to
fix it - you're punting it to F-15 so you can do more active development and
testing of it there. So, you'll have code in F-14 which either a) needs
constantly updated to match the testing codebase in F-15, possibly spreading
to other packages that interact with systemd, or b) is constantly out of date
and effectively unsupported/stillborn. So, in this case, I strongly suggest
only going with upstart in F-14, and systemd in F-15. (Perhaps set up
something on repos.fp.o for those that would want to test on F-14.)

- We decide to have systemd by default in F-14.

This case is a little different. However, if we're planning on dropping
upstart in F-15, does it help us to have it in F-14 to be maintained for the
life of the release, knowing that we're not planning on updating it,
ehancing it, or including it in a later release? It also causes problems for
documentation, in that all your documentation will have to have 'if upstart
do , if systemd do ', etc.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

seth vidal (skvi...@fedoraproject.org) said: 
> > I'll test it in rhel6 in just a sec.
> 
> Doesn't work in rhel6 :(

If you hold down the key long enough at the right time, it sort of works.
That's not really how we want to have it going forward, for obvious reasons.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Lennart Poettering (mzerq...@0pointer.de) said: 
> > - init shall support a mechanism to re-exec itself to not cause dirty
> >   inodes on shutdown; initscripts will use this method on shutdown.
> 
> This is bad. While we support this just fine I think it is a really bad
> idea to reexec init at shutdown. What's the point of this, can you elaborate 
> on
> this? This smells to me as a workaround for brokeness in older init
> systems, and I don't see a reason why reexecing itself would be
> necessary for systemd.

If the libraries or binaries used by systemd are replaced during runtime,
and it is not re-executed on shutdown, the filesystem will have busy inodes
on shutdown. (If you'd like to take the filesystem semantics up with the
kernel, feel free to tilt at that windmill.)

> Also, let's not forget that this requirement didn't exist for
> Upstart. Upstart always has been and still is unable to reexec itself.

upstart doens't support re-execution while maintaining internal state. It *does*
support minimal re-execution for this usage.

> > - (optional) Booting with secondary serial consoles does the same.
> 
> Hmm, could you elaborate on this? We have discussed this a couple of
> times upstream, and came to the conclusion that the only safe thing to
> do is to run a getty only on the main kernel console, i.e. where input
> is accepted from.

That's why it's optional... given that we don't do this now, it can be
dropped. (You'd be amazed at the number of bug reports we've gotten from
people who *think* we do this now, and are confused when it doesn't happen.)

> > PACKAGING
> > - Guidelines for packaging systemd units shall be formalized.
> 
> As pointed out elsewhere, I'd avoid this for F14.

Then we should put "don't" in the guidelines, instead. We need to set clear
expectations for package maintainers as to what they should be doing. (And
certainly not switching the state of their packages mid-release.)

> > SERVICE HANDLING
> > - Running 'chkconfig  <(null)|on|off>' on a service managed by systemd
> >   will return the correct code/perform an appropriate action.
> 
> Hmpff. I don't think this is a good idea. chkconfig should manage SysV
> scripts, and "systemctl enable" should manage systemd units. But
> interpolating this would create the impression the semantics were
> identical, although they really aren't.
> 
> What would make sense to add to chkconfig is something that checks
> whether a systemd unit is installed and then prints "Hey, you have a
> systemd unit installed, chkconfig won't do what you think it will do for
> this unit" or so.

This isn't good enough, IMO. chkconfig is a utility used by admins, scripts,
and packages in an automated fashion. Breaking their scripts is something
that should not be taken lightly. Making every script or utility that an
admin has have to have code for checking with chkconfig, and checking with
systemd, all in the same release, is pretty rude.

> > ORDERING
> > - rc.local will run as the final service on bootup.
> > - gettys will not start until after rc.local.
> > - prefdm will start coincident to gettys (earlier?)
> 
> Well, first of all, the first two items here obviously contradict. But
> putting that aside: I don't think speaking of ordering here these days
> really makes sense. Neither was it traditionally run as last thing of
> bootup (i.e. it was only synchronized against sysv scripts, not against
> upstart, inittab, dbus, cron, inetd services)

Correct, it was synchronized against SysV scripts. And, IMO, it should
stay that way. Principle of least surprise. If you want that reworded
as 'the final SysV service', that's not an issue.

> really. But I am not even too convinced about the prefdm/getty ordering,
> as this creates an unnecessary synchronization point for everybody, even
> though rc.local is empty (which it probably is for 99.9% of all
> people).

So, if the admin happens to add something to rc.local that needs
synchronization, instead of it working as it has been, he has to
rejigger the unit configuration? Ick.

> We want prefdm to start as early as possible.

That is a separate discussion that should be had once we have the basic
functionality verified and working, IMO. If we want to reorganize around
early login, we should do that as a coordinated effort in F-15, not as
an ad-hoc side-effect of the systemd configuration.

> > -- iSCSI /
> > -- LDAP user information
> > -- IPA/AD user information
> > -- NIS user information
> 
> Can't test any of this really. Wouldn't even know how to test this. I also
> don't want to be responsible for the fact taht nss-ldap is borked.

OK, so now you've stated 5 times in this mail some equivalent of
'that's not my package, it shouldn't be my problem, I don't want to be
responsible for this.'

I'm going to be blunt. I DON'T CARE.

It's about the integration into the system. Playing a blame game doesn't
help... if the system doesn't work, we can't ship that way. If there are enough
blockers in other packag

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Chris Adams (cmad...@hiwaay.net) said: 
> > > This is a very big change. chkconfig has worked for a long, long time. Its
> > > elegance and simplicity is one of the nice administrative features of Red
> > > Hat based distributes. People like it.
> > 
> > Yes, and they should continue to use it -- for sysv scripts.
> 
> I thought the last big discussion resulted in agreement that chkconfig
> and service should continue to work for all services.  Is that not the
> case?

service can, because it's pretty much a 1:1 mapping. (It's currently fixed
in git; it's telling you it's using systemctl while doing the appropriate
thing.)

chkconfig is different, because it's not a 1:1 mapping, and there are
different semantics involved. I'd like to have it working so that the
automated uses in scripts/frameworks work (checking whether a service is
enabled, for example), with the realization that everything it's used for
isn't going to be supported.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Lennart Poettering (mzerq...@0pointer.de) said: 
> Hmm, so this is about files that are deleted but still mapped by init,
> and which can only be deleted when init stops referencing them, but that
> is required to remount the fs r/o? Did I get this right?

Correct. 

> I am not really convinced that reexecing is the right answer for this
> problem. But well, since this already works anyway I guess this doesn't
> really matter too much.

It's the only answer I know of which doesn't require kernel changes.

> > > > PACKAGING
> > > > - Guidelines for packaging systemd units shall be formalized.
> > > 
> > > As pointed out elsewhere, I'd avoid this for F14.
> > 
> > Then we should put "don't" in the guidelines, instead. We need to set clear
> > expectations for package maintainers as to what they should be doing. (And
> > certainly not switching the state of their packages mid-release.)
> 
> Well, if we can agree on "don't, unless you contacted Lennart or [add
> list here] and he said it's OK" then I am fine with this.

That works for me.

> Well, if we can agree on "after all sysv services that include no proper
> ordering dependency information in the LSB headers", then I'd be fine
> with this. If sysv services contain LSB headers, we should follow the
> ordering it encodes, not come with implicit additional rules.

SysV services don't have a dependency concept of 'this needs to run
after me', AFAIK. So rc.local always implying 'I'm the last thing' isn't
something that could be stated correctly in mere LSB deps.

> > OK, so now you've stated 5 times in this mail some equivalent of
> > 'that's not my package, it shouldn't be my problem, I don't want to be
> > responsible for this.'
> > 
> > I'm going to be blunt. I DON'T CARE.
> 
> Yay, thanks that you don't care. You are aware that by putting
> everything on a single man's shoulders and then telling him "you don't
> care" you make him feel really welcome and make him wonder why he
> even bothers with this shit?

I'm not putting it on the shoulders of one man. I'm putting it on the
shoulders of *the project*. These are the issues that need to work;
these are the bugs that need to be fixed. If the scenarios have problems,
we'll assign bugs and go from there. But in *generating* the scenarios that
need to work, I'm not concerned with whose plate it falls on - it falls
on everyone's.

> > Sure, I suppose individual maintainers want to push their code over the 
> > wall and
> > then sit in their silo and claim 'that's not my problem' and 'someone else
> > needs to fix that', well, that's their right to be lame. But we, as Fedora,
> > as producers of a product that we ship to our users, don't have that luxury.
> 
> But you enable them to block out change. For example, if somebody
> refuses to merge a patch that adds a systemd equivalent for an upstart
> config hook he has, he can sink the whole systemd in fedora project. I
> am pretty sure some folks would be really happy to have that power...

That's what provenpackager and FESCo is for. We've forced patches to be
merged in the past. (Related to PA, if I remember right.)

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

Re: a note on order of arguements to systemctl command

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> I'm not saying that systemctl's syntax needs to be changed. I am saying,
> however, that it's important to get the service command working with
> systemctl so that people can use that instead.

FYI, this is done in git, will be built today/tomorrow.

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

Re: systemd or why will user fall away from fedora?

[Bill Nottingham]

dr johnson (d...@www.uk.linux.org) said: 
> That would be all grand and spiffy if it were actually faster bootup.
> 
> Bootchart here reports that systemd is 8 seconds *SLOWER* than upstart.  No
> idea why, but systemd just hangs for 8 seconds doing "nothing" that I can
> see.  No logs anywhere that are meaningful.  Default clean install from
> Alpha iso or Nightly livecd -- both do the same.

Can you file this, please? (Apologies if I missed it.)

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

Re: systemd v8 for rawhide?

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> On Thu, Aug 26, 2010 at 01:58:41AM +0200, Lennart Poettering wrote:
> > Sorry for breaking this (again), but with this in place things should be
> > at the appropriate places now for F14.
> 
> What about for Rawhide, where I'm testing all of this? It looks like the
> update was just built on F14.

rawhide's currently inheriting systemd from F-14; it will get the new
version when it gets to the stable tree.

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

Re: systemd v8 for rawhide?

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> > > What about for Rawhide, where I'm testing all of this? It looks like the
> > > update was just built on F14.
> > rawhide's currently inheriting systemd from F-14; it will get the new
> > version when it gets to the stable tree.
> 
> Really? I haven't been paying enough attention, I guess. Why don't inherited
> packages hit rawhide when they get to the testing tree? Seems like that'd
> help a lot with the testing!

There's the chance that things could go into updates-testing that never
get released. We could revisit this policy, though.

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

Re: If you cannot boot after installing systemd v8...

[Bill Nottingham]

M A Young (m.a.yo...@durham.ac.uk) said: 
> > Note that version 8-2 waiting in bodhi should now handle upgrades from
> > the alpha without problems.
> 
> Does it cope with the shutdown problem? After I updated systemd to 8 I 
> couldn't shut the computer down, because (if I am remembering 
> correctly) it couldn't find reboot.socket

Run 'systemctl daemon-reexec' to fix this.

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

Re: systemd v8 for rawhide?

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> I'm willing to sacrifice my stable rawhide desktop system in the name of
> getting Fedora more testing. Where should this discussion be had?

FESCo. rel-eng will implement it (it's a one-line koji command), but the
decision isn't really rel-eng's to make unilaterally.

https://fedorahosted.org/fesco/ticket/452

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

Re: applied, non-theoretical use of systemd

[Bill Nottingham]

Petrus de Calguarium (kwhisk...@gmail.com) said: 
> 1. I noticed that one can no longer (with v8-2) turn off the computer by 
> clicking the 
> 'turn off computer' button in KDE. I figured out, with help of recent 
> threads, that one 
> has to run: systemctl isolate poweroff.target. It worked. Is this the correct 
> way?

That is a way. The KDE button should still work - what is it actually doing?
(Generally, invoking shutdown/reboot/etc is probably the easiest way.)

> 2. I use privoxy as a proxy and dnsmasq for dns cacheing. Previously, I 
> issued: service 
> dnsmasq start ; service privoxy start. I presume I must now run: systemctl 
> start 
> dnsmasq.service ; systemctl start privoxy.service. Is this correct?

If you've got the latest packages, either should work.

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

Re: drop default MTA for Fedora 15

[Bill Nottingham]

Chris Adams (cmad...@hiwaay.net) said: 
> Once upon a time, Garrett Holmstrom  said:
> > While it may be debatable what benefit one might get from removing it 
> > from the default install, can we at least remove MTAs from @core to help 
> > make things easier for appliance folks?  One can still go in @base, 
> > which would make it continue to appear on all but the most minimal of 
> > installs.
> 
> Yeah, I just noticed tonight that sendmail is in both @Core and @Base
> (as well as @Mail Server).  Is there a particular reason it is in both?
> 
> Right now, it (or whatever the default provider of /usr/sbin/sendmail)
> should be in @Core, because cronie is mandatory and requires
> /usr/sbin/sendmail (until the rawhide version of cronie, which will log
> to syslog if there's no /usr/sbin/sendmail).
> 
> Why is sendmail also in @Base?

It was in @base. When @core was split off and cleaned up, but still needed a
MTA, it was added there so we had a consistent default.

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

Re: applied, non-theoretical use of systemd

[Bill Nottingham]

Petrus de Calguarium (kwhisk...@gmail.com) said: 
> So, the problem reduces to the Shut Off Computer button in KDE not working.

OK. So the question is ... what does this button do? Invoke 'halt'?
Invoke 'shutdown -h now'? Invoke ConsoleKit's Stop() method?

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

Orphan packages retired for F-14 (and rawhide)

[Bill Nottingham]

In accordance with the normal process, the following packages have been
orphaned for Fedora 14 and rawhide.

JSDoc
bzr-gtk
cdf
crun
django-authopenid
drpython
fedora-security-guide-en-US
fet
fish
gg2
gnomecatalog
gperiodic
impressive
kasablanca
kflickr
lazygal
libmspack
mapbender
mediawiki-HNP
mediawiki-StubManager
minirpc
nettle
nget
nodm
pAgenda
papercut
pastebin
php-channel-phpdb
php-pear-Phlickr
php-pear-creole
php-pear-pake
php-pear-propel_generator
php-pear-propel_runtime
poker-engine
poker-eval
poker-network
poker2d
poker3d
poker3d-data
pyfacebook
pypoker-eval
python-numarray
python-urllib2_kerberos
qosmic
tanukiwrapper
tinyows
tpb
tremfusion
twitux
windowlab
x2vnc
xenwatch

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

Re: fedora mission (was Re: systemd and changes)

[Bill Nottingham]

Gerard Braad (gbr...@fedoraproject.org) said: 
> > aggressively
> 
> I do not agree this strategy is wise or even the correct way. Certain
> Fedora versions dropped hardware support. We can't dictate people wht
> they can or can not do. I still know people who run old redhat
> releases (5.x) as there was m68k support.



Red Hat Linux as released on the FTP site/boxed sets never directly supported
m68k. There was a different product called 'Linux Rough Cuts', which were 
community
ports to various architectures - the example I know of included PPC, m68k,
MIPS, and UltraSparc (before UltraPenguin was merged in.)



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

Re: fedora mission (was Re: systemd and changes)

[Bill Nottingham]

Jeff Spaleta (jspal...@gmail.com) said: 
> On Tue, Aug 31, 2010 at 9:34 AM, Emmanuel Seyman
>  wrote:
> > Same goes for programs that scrape web pages (I'm thinking of gcstar but
> > I'm sure there are others). If the page layout changes, the page scraper
> > needs to be updated and that usually involves updating the package.
> 
> Yep.. gourmet does this to some extent as well for scrape recipes from
> specific sites as well as provide a generic web scraper for you to
> build your own recipe grabber.

That's gross. (I realize you're blocked on the sites you rely on, but
geez, can't you find sites with real APIs?)

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

Re: fedora mission (was Re: systemd and changes)

[Bill Nottingham]

Jeff Spaleta (jspal...@gmail.com) said: 
> On Tue, Aug 31, 2010 at 10:31 AM, Bill Nottingham  wrote:
> > That's gross. (I realize you're blocked on the sites you rely on, but
> > geez, can't you find sites with real APIs?)
> 
> It is what it is.  Though I do like being given credit for doing
> development work that I'm not actually responsible for. Makes me feel
> important.

It is not meant to be a complaint at you or a request for you to do more
work. It's a complaint at the state of the world. (Why not find the
biggest windmill of all to tilt at?)

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

Re: Starting Java SIG

[Bill Nottingham]

Stanislav Ochotnicky (sochotni...@redhat.com) said: 
> Agenda TBD, but for now the idea is to:
>  * go through Tasks listed on [1]

Can non-SIG members add tasks? If we have a Java SIG, I'd like there
to be some agreement on how to handle orphaned packages - right
now, we've got about 30 java packages orphaned in F-14. Some of them
have comaintainers, some of them have maintainers in rawhide. I can
go and reassign the packages to the comaintainers or the rawhide
maintainers, but it would be nice if people would voluntarily pick
them up.

Bill (list available if needed)

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

Re: systemd and changes

[Bill Nottingham]

Ben Boeckel (maths...@gmail.com) said: 
> I actually have a bug to file about that. The setting for NM_CONTROLLED
> is still set even if NetworkManager isn't installed. It (or Ananconda)
> should scrub the configs before installing the settings used during the
> install.

IMO, NM_CONTROLLED should *never* be written, and should only be
used by administrators where they feel it's necessary.

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

Re: Starting Java SIG

[Bill Nottingham]

Stanislav Ochotnicky (sochotni...@redhat.com) said: 
> I believe most of them have already been taken (by me, Alexander
> Kurtakov or someone else). But a list of the remainining would be nice
> of course.

Sure, here you go (obviously, some of this is more eclipse-focused rather
than core java):

Orphan backport-util-concurrent
comaintained by: akurtakov
Orphan batik
Orphan dtdparser
comaintained by: dbhole
Orphan eclipse
comaintained by: oliver akurtakov overholt
Orphan eclipse-demos
comaintained by: jjohnstn
Orphan eclipse-eclemma
Orphan eclipse-linuxprofilingframework
Orphan emma
Orphan hsqldb
comaintained by: fnasser
Orphan jrefactory
Orphan json
Orphan jython
Orphan ldapjdk
Orphan lucene
Orphan maven-archiver
comaintained by: akurtakov
Orphan maven-doxia-sitetools
comaintained by: akurtakov
Orphan maven-embedder
comaintained by: akurtakov
Orphan maven-enforcer-rule-api
comaintained by: akurtakov
Orphan objectweb-anttask
Orphan plexus-cli
Orphan plexus-mail-sender
Orphan plexus-naming
comaintained by: akurtakov
Orphan plexus-registry
comaintained by: akurtakov
Orphan plexus-resources
comaintained by: akurtakov
Orphan rome
comaintained by: akurtakov
Orphan sat4j
comaintained by: akurtakov
Orphan xjavadoc
Orphan xmlrpc3
Orphan xpp2
comaintained by: dbhole

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

Re: Twitter support broken in Pino

[Bill Nottingham]

Gianluca Sforna (gia...@gmail.com) said: 
> """
> Most FOSS client developers have simply chosen to embed their keys in
> their source code with the hope that Twitter won't notice. I was about
> to give up on Gwibber, but Canonical intervened on my behalf (special
> thanks to Ken VanDine) and negotiated a compromise with Twitter that
> will allow Gwibber to continue using the service.
> """
> 
> So I'm wondering if we can lobby the same exception for pino, which is
> the default client we ship in the desktop spin

The other option would be to switch to gwibber (which has been
un-desktop-couched in Fedora 14, so it theoretically won't bring in
nearly as much to the live image.

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

Re: Pino & twitter

[Bill Nottingham]

Alex Hudson (fed...@alexhudson.com) said: 
>   https://bugzilla.redhat.com/show_bug.cgi?id=629192
> 
> I read through my archive and all I can see is a short discussion
> proposing changing to gwibber.
> 
> Is anyone actively trying to get an exception for pino a la gwibber? Or
> should someone be taking up this cudgel?

I don't know, but I'd guess, that volunteers to get such an exception
would be helpful. You'd want to coordinate with pino upstream, of course.

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

Re: Pino & twitter

[Bill Nottingham]

Arun SAG (saga...@gmail.com) said: 
> >  >  
> > https://bugzilla.redhat.com/show_bug.cgi?id=629192
> 
> This bug is now a F14 blocker.

Nomintated as one; it needs to go through the normal review process.
And the fix for this may not involve fixing pino, if that proves
intractable.

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

Re: Twitter support broken in Pino

[Bill Nottingham]

Bill Nottingham (nott...@redhat.com) said: 
> The other option would be to switch to gwibber (which has been
> un-desktop-couched in Fedora 14, so it theoretically won't bring in
> nearly as much to the live image.

So, actual testing - building a livecd with gwibber instead of pino
brings in the following packages:

PyXML   4185378
python-sexy 61194
python-oauth50819
python-imaging  1381510
python-distutils-extra  133515
mx  6599955
libsexy 102616
gwibber 2367779

Resulting live image was 704MB. Note that not all of these
appear to *actually* be required by gwibber - bug 632621 filed.

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

Re: Broadcom wifi drivers in F-14?

[Bill Nottingham]

Ric Wheeler (rwhee...@redhat.com) said: 
> Can we use the firmware that they have for the existing broadcom wireless 
> driver?

'No' is what I've been told.

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

Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)

[Bill Nottingham]

Máirín Duffy (du...@fedoraproject.org) said: 
> Only 5 of the 9 FESCo members voted on this issue. If all 9 had voted,
> even with the current 3 for / 2 against vote, systemd could easily have
> enough votes for inclusion in F14. I have a couple of questions for you,
> FESCo, since I honestly don't know and maybe would feel more comfortable
> knowing:
> 
> - Has there been any consideration for formalizing the acceptable of
> absentee votes?

We have accepted absentee votes either sent to the FESCo list or noted
in the ticket before the meeting; in fact, noting votes in meeting item
tickets is the de-facto method of participating for members who can't
make it.

> - How many members must be present at a meeting for a voting decision to
> be considered valid?

5 out of 9 is considered quorum for the meeting, and 5 out of 9 is also
required for decisions.

> - Is it possible to collect the votes of the folks who were not present?

We could poll them. But the ticket has been open for ~1 week for them to
note their opinion; none of the not-present FESCo members have commented
to this point.

> Again, either way the decision goes - fine. It would be nice to hear
> from the FESCo members not present on how they feel about the decision,
> though.
> 
> Is anyone else feeling a little uncomfortable about the voting process,
> irregardless of its conclusion?

I said as much during the meeting.

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

Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)

[Bill Nottingham]

drago01 (drag...@gmail.com) said: 
> The only real issues pointed out where lack of documentation and
> system-config-service integration for native services.
> Neither that we have with upstart so not really a regression and thus
> warrant a reject.

system services have not been migrated to upstart. They have/had been
migrated to systemd, which makes this not an apples-to-apples comparison.

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

Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)

[Bill Nottingham]

Richard Hughes (hughsi...@gmail.com) said: 
> On 14 September 2010 23:01, Kevin Fenzi  wrote:
> > 21:33:35  The other 2 items I had were:
> > 21:33:56  application installer issues
> > 21:33:57  https://bugzilla.redhat.com/show_bug.cgi?id=488968
> > 21:34:04  and
> > 21:34:05  BuildIdBuild infrastructure
> > 21:34:06  https://fedorahosted.org/fedora-infrastructure/ticket/2387
> > 21:34:57  that needs more time, I'd say
> > 21:35:08  ok, will close out if no one has anything further...
> 
> Well, that was enlightening. Do you think someone from FESCo could
> write something about
> https://bugzilla.redhat.com/show_bug.cgi?id=488968 in the bug, and
> make a decision please.

Discussion on this was postponed due to a lack of time, nothing
more. Please, come to next week's meeting.

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

Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)

[Bill Nottingham]

Toshio Kuratomi (a.bad...@gmail.com) said: 
> Actually, iiuc, tomasz is talking about migrating sysv-init scripts to
> systemd unit files.  There is a blocker to doing that in F15 which is that
> lennart, notting, and walters (that I remember) are against doing a mass
> migration to unit files until after systemd has been running for at least
> one release.  This allows best practices for writing unit files to emerge
> and get codified in a packaging guideline.  Without information on how to
> write unit files well, we're not going to be porting scripts over.

My opinion is that we'd want some best practices, but that is more tied
to time and testing, not a specific number of releases.

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

Re: Linux and application installing

[Bill Nottingham]

Arthur Pemberton (pem...@gmail.com) said: 
> > Can someone please elaborate a bit what pieces of information are really
> > needed? The .desktop files as a whole?
> 
> Wouldn't that require the tool to download every package just to get
> the embedded information.

Not if it's provided in the RPM header in a way where it can be easily
stuffed into the metadata or a similar place. (After all, icons used to be
embedded in the package header, and they could be a lot bigger than desktop
files are.

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

Re: rawhide: upstart-sysvinit replacing systemd-sysvinit?

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> > I know, systemd got reverted for F-14. But unless I missed something,
> > the plan is/was to keep it the default for F-15, and in rawhide. This
> > means the package dependencies need to be different in rawhide please.
> 
> Ditto.

Will be fixed shortly.

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

Re: ImageMagick soname bump for F14

[Bill Nottingham]

Pavel Alexeev (aka Pahan-Hubbitus) (fo...@hubbitus.com.ru) said: 
>  16.09.2010 18:35, Orion Poplawski wrote:
> > Do we really want to do this, especially for a FTBS issue presumably 
> > against F15?
> >
> > https://admin.fedoraproject.org/updates/ImageMagick-6.6.4.1-13.fc14
> >
> Please excuse me what I did not ask early. Now I call to maintainers of
> dependent packages - please rebuild it against new version of ImageMagick.

Why? What's the point of a soname bump this late that affects this many
packages?

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

FYI: rawhide now requires systemd to boot by default

[Bill Nottingham]

While upstart is still in the repo, the initscripts package now pulls
in systemd and systemd-sysvinit.

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

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> It's not "some random day" - it's when you actually accept an update! It's 
> not 
> easy to estimate impact of update - but banning completely is not a solution 
> neither.

We do not give nearly enough information in our updates for the user to
make any informed decision here. Just tagging it as 'enhancement' isn't
enough. So, it most of the time does boil down to:

1) they accept updates in general, and they get it on some random day
2) they wonder, think updates may change things. Therefore updates are scary,
   and should be avoided by the user.

Neither of these are great.

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

Re: docbook and glibc breakage?

[Bill Nottingham]

Richard Hughes (hughsi...@gmail.com) said: 
> On 27 September 2010 19:58, Jaroslav Skarvada  wrote:
> > The character class must be inside bracketed expression, thus double 
> > brackets, please see man grep. The new grep-2.7 checks for this common 
> > fault:
> 
> Right, but you could argue it's a regression as the behavior changed.

Exactly... this is way late to be introducing this into Fedora 14. Any
reason it can't be held for F15? (Bug filed to this effect.)

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

Re: x86_64 as Fedora's primary platform

[Bill Nottingham]

Mike McGrath (mmcgr...@redhat.com) said: 
> > The Fedora web resources (e.g. http://fedoraproject.org/get-fedora )
> > continue to promote i686 installs over x86_64, the result being that
> > only a third of fedora users are on x86_64.
> >
> > When will the Fedora project begin recommending x86_64 as the
> > preferred option on the relevant hardware?
> >
> 
> FWIW, we have two measurements of x86_64 vs i686.
> 
> Smolt:
>   65% i686
>   35% x86_64
> 
> mirrors.fedoraproject.org:
>   70% i686
>   30% x86_64

What would be interesting is if there's any way at all to see which
of these stats is driving the other ... it's sort of a circular
relationship.

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

Re: Broken dependencies with Fedora 14 + updates-testing - 2010-09-27

[Bill Nottingham]

Michael Schwendt (mschwe...@gmail.com) said: 
> The following packages in the repository suffer from broken dependencies:
> 
> ==
> The results in this summary consider Test Updates!
> ==
> 
> package: perl-Finance-Quote-1.17-3.fc14.noarch from fedora-14-development-i386
>   unresolved deps:
>  perl(HTTP::Headers)
> 
> package: perl-Finance-Quote-1.17-3.fc14.noarch from 
> fedora-14-development-x86_64
>   unresolved deps:
>  perl(HTTP::Headers)

Huh? Did perl-libwww-perl disappear?

Bill

--
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: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Bill Nottingham]

Orcan Ogetbil (oget.fed...@gmail.com) said: 
> What I am trying to say is, a redesign of an interface _usually_ have
> valid reasons. Those users who don't want their menu items moving
> around want to live like automated machines. Forbidding such changes
> promotes lazyness.
> 
> If the update removes features that existed in previous version, that
> is another story. I support you forbidding this type of change.
> 
> But I really don't buy this "users shouldn't be disturbed by moving a
> button from left to right". If the user is disrupted to what they are
> used to, he needs to learn not to (be disrupted). Do we really want to
> serve a closed-for-learning community? :(

It's restricting the arbitrary application of change to the user to
times when they are well able to deal with it. If I'm running F-13
and trying to create a slide deck, and run into a crash, I want the
update for the crash to just fix that crash. Not fix that crash and
reorganize the slide interface so I need to relearn it for the slides
I'm in the middle of. If this change is restricted to the next
major release, I'm expecting some amount of change, and therefore are
better able to process it, we're better able to document it, and so
on.

Taking your suggestion to its extreme, we should promote learning and
resist automaton behavior by randomizing the menus at each click, changing
the default MTA once per release, and so on. 

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

Re: FAILED: BuildrootError: could not init mock buildroot

[Bill Nottingham]

Neal Becker (ndbeck...@gmail.com) said: 
>  FAILED: BuildrootError: could not init mock buildroot, mock exited with 
> status 30; see root.log for more information
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2506706
> 
> DEBUG util.py:260:  Error: Package: 4:perl-5.12.2-137.fc15.x86_64 (build)
> DEBUG util.py:260: Requires: libperl.so()(64bit)
> DEBUG util.py:260:   You could try using --skip-broken to work around the 
> problem
> DEBUG util.py:260:   You could try running: rpm -Va --nofiles --nodigest

Untagged.

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

Re: FAILED: BuildrootError: could not init mock buildroot

[Bill Nottingham]

Neal Becker (ndbeck...@gmail.com) said: 
> Thanks, what should I do next?

Wait for the build repo to regenerate and then resubmit.

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

Re: Summary/Minutes for today's FESCo meeting (2010-10-05)

[Bill Nottingham]

Matthew Garrett (mj...@srcf.ucam.org) said: 
> > But I cannot list all the RHEL6 bugs.
> 
> Why not? Strip partner names if necessary, but please make it possible 
> for people to decide whether a given update is a benefit to them.

Well, he could list them in the bug field, but bodhi would elide
them in the updates advisory. He could do double duty and list
them all in the changelog, but that's getting a bit extreme when 
it comes to 100 patches.

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

Re: Ubuntu 10.10's installer looks rather nice

[Bill Nottingham]

Matthias Clasen (mcla...@redhat.com) said: 
> That is certainly a big part of the problem. Anaconda does a _ton_ of
> crap that only very few users care about. And keeping all these minority
> features from falling apart is leaving you no time to polish the user
> experience for the large majority of users.

Correct. And any time it's suggested that certain parts of that crap
be removed to streamline things, people come screaming. (The discussion
about pruning the install methods is the one that comes to mind...
mm, nfsiso and hard drive installs.)

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

Re: Ubuntu 10.10's installer looks rather nice

[Bill Nottingham]

Chris Lumens (clum...@redhat.com) said: 
> >  - downloads updates in parallel too
> 
> Package updates?

1) Given that it's using yum, downloading multiple things in parallel
would need to be fixed there.
2) If it means downloading packages in the background while it does
other tasks, given that package selection is the final task in the
current workflow, it would require reordering the workflow to be
beneficial. (Which becomes a memory usage tradeoff.)

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

'milkymist' group in comps?

[Bill Nottingham]

1) When you added this to F14/F15/EL6, you added a typo; this
broke the F-14 branched compose and the EPEL updates push.
*Please* verify your changes before pushing.

2) Aside from that... how does this merit a separate group?

- We already have the electronic lab group
- If we add a group each for developing for any embedded/custom
  board, we're going to run into group explosion really quickly

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

Re: 'milkymist' group in comps?

[Bill Nottingham]

Chitlesh GOORAH (chitlesh.goo...@gmail.com) said: 
> Milkymist community builds and enhance their own toolchain (currently
> not fully supported by Fedora). They have contributors who contribute
> for tools such as gcc, qemu, other libraries (too software for FEL
> goals). They have many patches that need to push to upstream.
> Milkymist founder and I believe that we can collaborate as the
> milkmist community is situated between FEL and Fedora, in terms of
> tools and upstream patch-push. It is a win-win situation for everyone.

OK, that's clear. But I am worried that if we go down this road, we'll
eventually have 20 or 30 groups for different SoCs for embedded use,
and that seems like it will eventually be problematic. Is there some
generic moniker that could be used for this usage?

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

Re: A comps group for the Design Suite

[Bill Nottingham]

Ankur Sinha (sanjay.an...@gmail.com) said: 
> Since the design team is using a "design suite", would it be possible to
> please create a group in comps for the purpose? It would make
> installation of the design suite much easier for end users. 
> 
> The alternative is to create a meta package which isn't welcomed. 
> 
> This[1] is the tentative list of packages.
> 
> [1]http://fedoraproject.org/wiki/Design_Suite_Planning#Included

There appears to be a lot of overlap here with the graphics group
(and some with other groups). Perhaps it's best to just expand
that group into a more full-fledged design suite?

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

Re: 'milkymist' group in comps?

[Bill Nottingham]

Chitlesh GOORAH (chitlesh.goo...@gmail.com) said: 
> > OK, that's clear. But I am worried that if we go down this road, we'll
> > eventually have 20 or 30 groups for different SoCs for embedded use,
> > and that seems like it will eventually be problematic. Is there some
> > generic moniker that could be used for this usage?
> 
> To be honest that would be a great idea. But I don't know any other
> active and vibrant community like milkymist and openmoko alike. I
> suggest that, let it be like this. If it gets momentum and other HW
> communities pop in, we can rename it, I won't object.

Works for me.

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

Re: 'milkymist' group in comps?

[Bill Nottingham]

James Laska (jla...@redhat.com) said: 
> > 1) When you added this to F14/F15/EL6, you added a typo; this
> > broke the F-14 branched compose and the EPEL updates push.
> > *Please* verify your changes before pushing. 
> 
> How did the compose break?

The comps file in git failed to parse, such that the with-translations
comps file could not be made.

> Is this something that the autoqa
> rats_sanity test [sh|c]ould have caught?

No, this is well before the tree gets to that state. It would need to
be implemented as a check on git push.

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

Re: 'milkymist' group in comps?

[Bill Nottingham]

James Laska (jla...@redhat.com) said: 
> > No, this is well before the tree gets to that state. It would need to
> > be implemented as a check on git push.
> 
> We attempt to validate comps in this test using the comps.rng in git
> (see results logs posted earlier).  I'm not tremendously familiar with
> that part of the test, but I believe it should catch that?

You're validating it after the repo has already been made. In this case,
it was broken such that the repo couldn't even be made.

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

Re: A comps group for the Design Suite

[Bill Nottingham]

Nicu Buculei (nicu_fed...@nicubunu.ro) said: 
> > There appears to be a lot of overlap here with the graphics group
> > (and some with other groups). Perhaps it's best to just expand
> > that group into a more full-fledged design suite?
> 
> They are different things: the graphics group is the sum of all packages 
> about graphics, a "design suite" group would be a way for people to 
> install the Design Suite Spin (a collection of "best of breed" apps) if 
> they already have Fedora installed.

Right, but I'm saying that the "Design Suite" group might be more
appropriate in all cases.

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

Re: ethtool not in default system anymore?

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> On Tue, Oct 12, 2010 at 07:06:50PM -0500, Chris Adams wrote:
> > It looks like up through F12, initscripts required ethtool (so it was
> > definately installed by default).  I see this in the RPM changelog:
> 
> Still the case in RHEL5, FWIW.

I'm assuming you mean RHEL 6; it just seemed too big of a change to debut
in RHEL at the time we branched.  However, it has worked pretty well in
Fedora so far to just rely on the carrier attribute in sysfs.

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

Re: ethtool not in default system anymore?

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> On Wed, Oct 13, 2010 at 11:54:43AM -0400, Bill Nottingham wrote:
> > > > It looks like up through F12, initscripts required ethtool (so it was
> > > > definately installed by default).  I see this in the RPM changelog:
> > > Still the case in RHEL5, FWIW.
> > I'm assuming you mean RHEL 6; it just seemed too big of a change to debut
> > in RHEL at the time we branched.  However, it has worked pretty well in
> > Fedora so far to just rely on the carrier attribute in sysfs.
> 
> No, I mean in current RHEL5, ethtool is required by initscripts. Maybe that
> happened somewhere in one of the point releases?

The change to drop the required ethtool use in initscripts was in F-13...
it's not something that would be backported to RHEL 5 ever (and almost
certainly won't be backported to RHEL 6.)

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

Re: A comps group for the Design Suite

[Bill Nottingham]

Nicu Buculei (nicu_fed...@nicubunu.ro) said: 
> >> Do you mean getting rid of the "Graphics" group and creating a new
> >> "Design Suite" group?
> >>
> >> Is there a procedure for this? I mean like filing a ticket some place?
> >
> > I'm confused about the whole conversation. What exactly are you talking
> > about Bill when you refer to creating a new "comps" group?
> 
> When you run any other spin than the Design Suite the ability to run 
> "yum groupinstall design-suite" and automatically get *all* the goodies 
> provided by that spin.

Right, it would be (for Fedora 15, *not* 14) renaming the graphics grop
to the 'design suite' group, and adjusting the package list appropriately.

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

Re: rawhide report: 20101019 changes

[Bill Nottingham]

Peter Jones (pjo...@redhat.com) said: 
> Because we haven't decided to merge those together. That's really the only
> reason - there's no over-arching technical reason they need to be separate.
> It's entirely a historical consideration.

Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib,
and so on were just symlinks to /usr/bin, /usr/lib, and so on.

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

Re: rawhide report: 20101019 changes

[Bill Nottingham]

Cleaver, Japheth (jclea...@soe.sony.com) said: 
> A ton of this work was already done in initscripts through the use of the 
> /etc/sysconfig/readonly-root hooks. Isn't that already working well enough 
> now for that purpose, future systemd changes aside?

Given that it involves bind-mounting *files* in some cases (which imparts
some truly odd semantics that confuse programs), it's not quite enough for
generalizing to any use. It certainly can be made to work, though.

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