Fedora 14 branching and dist-git roll out

Hey all! It's that time again, we're gearing up to branch for Fedora 14 this coming Tuesday! There is a major twist this time around, we're going to attempt a roll out of dist-git! Dist-git is our replacement for the CVS system we are currently using. This is a pretty big deal, but we're going t

Re: [HEADS-UP] systemd is now the default init system in rawhide

On Fri, Jul 23, 2010 at 10:54:50PM -0500, Garrett Holmstrom wrote: > On 7/23/2010 20:26, Lennart Poettering wrote: > > - You can boot into either of them by setting the "init=" kernel cmdline > >option according to your wishes. If you pass "init=/bin/systemd" you > >will boot into systemd,

Re: [HEADS-UP] systemd is now the default init system in rawhide

On Fri, Jul 23, 2010 at 08:04:48PM -0700, darrell pfeifer wrote: > On Fri, Jul 23, 2010 at 18:26, Lennart Poettering wrote: > > > Heya, > > > > I have just uploaded a new systemd and a new upstart package which make > > systemd the default init system for Rawhide. The scheme I followed makes > > s

Re: [HEADS-UP] systemd is now the default init system in rawhide

On 7/23/2010 20:26, Lennart Poettering wrote: > - You can boot into either of them by setting the "init=" kernel cmdline >option according to your wishes. If you pass "init=/bin/systemd" you >will boot into systemd, if you pass "init=/sbin/upstart" you will boot >into upstart (note the

Re: [HEADS-UP] systemd is now the default init system in rawhide

On Fri, Jul 23, 2010 at 18:26, Lennart Poettering wrote: > Heya, > > I have just uploaded a new systemd and a new upstart package which make > systemd the default init system for Rawhide. The scheme I followed makes > sure that in case systemd actually breaks systems there is an easy path > back t

[HEADS-UP] systemd is now the default init system in rawhide

Heya, I have just uploaded a new systemd and a new upstart package which make systemd the default init system for Rawhide. The scheme I followed makes sure that in case systemd actually breaks systems there is an easy path back to upstart. And here's how it works: - "upstart" and "systemd" are no

Re: Non-responsive maintainer fast track procedure for libsndfile

On Fri, 23 Jul 2010, Orcan Ogetbil wrote: > I sent him an email as you asked, once again. And didn't get a > response, once again. Good morning. Sorry for the non-responsiveness. Work has been kinda taxing for some time now... Someone pointed me at the discussion here.

rpms/perl-GD-SecurityImage/F-13 import.log, NONE, 1.1 perl-GD-SecurityImage.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

Author: eseyman Update of /cvs/pkgs/rpms/perl-GD-SecurityImage/F-13 In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv27805/F-13 Modified Files: .cvsignore sources Added Files: import.log perl-GD-SecurityImage.spec Log Message: Initial import. --- NEW FILE import.log ---

rpms/perl-GD-SecurityImage/devel import.log, NONE, 1.1 perl-GD-SecurityImage.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

Author: eseyman Update of /cvs/pkgs/rpms/perl-GD-SecurityImage/devel In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv27523/devel Modified Files: .cvsignore sources Added Files: import.log perl-GD-SecurityImage.spec Log Message: Initial import. --- NEW FILE import.log --

Re: Outage: Updates - 2010-07-28 16:00->22:00 UTC

On Fri, Jul 23, 2010 at 16:46, Stephen John Smoogen wrote: > There will be an outage starting at 2010-07-21 16:00 UTC, which will That should be Wednesday 2010-07-28 > last approximately 6 hours. Outages will be small but noticeable for > small segments as systems are updated and rebooted. > > T

Outage: Updates - 2010-07-28 16:00->22:00 UTC

There will be an outage starting at 2010-07-21 16:00 UTC, which will last approximately 6 hours. Outages will be small but noticeable for small segments as systems are updated and rebooted. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or r

Upcoming rebuilds: Rebuilding publictestXX and .stg. servers

Ok its time to start rebuilding the various publictest and .stg. environment to make sure that the systems are 'sound'. I would like to get this started next week with the publictest systems and then the week after with the .stg. systems. The systems that have been in use lately seem to be: public

Re: Python 2.7 rebuild: maintainer help needed (please!)

David Malcolm wrote, at 07/24/2010 03:07 AM +9:00: > mtasaka (1): > wallpapoz Was waiting for gnome-python2 rebuild. Now succeeded. http://koji.fedoraproject.org/koji/buildinfo?buildID=186114 Regards, Mamoru -- devel mailing list d

Re: Python 2.7 rebuild: maintainer help needed (please!)

On Fri, Jul 23, 2010 at 02:07:50PM -0400, David Malcolm wrote: > python-cherrypy2 This appears to be busted with python-2.7. I vaguely think that it was also busted with later versions of python-2.6 but I'm not 100% sure. If someone wants to take a look at this, I won't be back for another h

Re: Non-responsive maintainer fast track procedure for libsndfile

On Thu, Jul 15, 2010 at 1:17 AM, Kevin Fenzi wrote: > On Wed, 14 Jul 2010 20:42:57 -0400 > Orcan Ogetbil wrote: > >> I have got news. The other day, my ACL request (that I made last >> year!) for F-10  was approved by ixs. 1 minute later, it was set back >> to Awaiting Review. >> >> Anyone have any

Re: Python 2.7 rebuild: maintainer help needed (please!)

On Fri, 2010-07-23 at 20:31 +0100, Richard W.M. Jones wrote: > On Fri, Jul 23, 2010 at 02:07:50PM -0400, David Malcolm wrote: > > rjones (1): > > > href="http://koji.fedoraproject.org/koji/taskinfo?taskID=2344290";>coccinelle > > Even the latest upstream version seems to be incompatible with Pyt

Re: Reminder: Fedora 14 Feature Freeze is Next Week (2010-07-27)

On Wed, 21 Jul 2010 08:49:04 +0200 Peter Czanik wrote: > Hello, > > 2010-07-21 06:18 keltezéssel, John Poelstra írta: > > Feature Freeze means that all accepted feature for the release are > > *significantly* "feature complete", ready for testing, and have a > > current status. > > > What d

Re: Python 2.7 rebuild: maintainer help needed (please!)

On Fri, Jul 23, 2010 at 02:07:50PM -0400, David Malcolm wrote: > rjones (1): > href="http://koji.fedoraproject.org/koji/taskinfo?taskID=2344290";>coccinelle Even the latest upstream version seems to be incompatible with Python 2.7. I'll take a closer look at the problems and if I can fix them, s

Re: Python 2.7 rebuild: maintainer help needed (please!)

On Fri, 2010-07-23 at 14:07 -0400, David Malcolm wrote: [snip] > If the failure happens in "build.log" you may have to do some > investigation/patching. Sometimes it's as simple as a hardcoded "2.6" > in a %files manifest that needs to be generalized (e.g. to "2.*") > > Some notes on Python 2.6

Re: Weird libprojectM C++ segfaults

> http://mschwendt.fedorapeople.org/audacious-plugins-2.2-34.fc13.projectMlinked.src.rpm > > That's the current F-13 package with only a minor modification: > Pulse Audio output plugin is linked with -lprojectM and doesn't use > the API in any way: > > $ audacious > [CTRL+Q] > Segmentation fault

Re: Python 2.7 rebuild: maintainer help needed (please!)

On Fri, Jul 23, 2010 at 2:07 PM, David Malcolm wrote: > I've been running mass rebuilds of python-using packages against python > 2.7 [1] > > We're now down to 202 failing builds, so I'm attaching a by-maintainer > report on them. > cmake needs to be rebuilt. There is a line in /usr/share/cmake/Mo

[Bug 502358] Review Request: mojomojo - Catalyst & DBIx::Class powered Wiki

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=502358 manuel wolfshant changed: What|Removed |Added --

Re: Weird libprojectM C++ segfaults

On Fri, 23 Jul 2010 13:38:22 -0400, Orcan wrote: > Can you tell us what nvr of libprojectM you are using? Meanwhile, it's 2.0.1-7.fc13 (just fetched from updates-testing). > There was a > bug I fixed in 2.0.1-7, which caused crashes due to wrong font paths > set in the code. Since we are not bu

Python 2.7 rebuild: maintainer help needed (please!)

I've been running mass rebuilds of python-using packages against python 2.7 [1] We're now down to 202 failing builds, so I'm attaching a by-maintainer report on them. Please can you review the list and see if there's anything that needs fixing in your packages. Many of these are due to dependenc

Re: [HEADS-UP] systemd for F14 - the next steps

On Fri, 23 Jul 2010 13:33:23 -0400 Cole Robinson wrote: > Granted, the user's conclusion in the first situation is bogus, but if > someones first interaction with the new system is confusion and > unnecessary readjustment of long held interface expectations, it's > going to cause a lot of frictio

Re: [HEADS-UP] systemd for F14 - the next steps

On Fri, Jul 23, 2010 at 11:33, Cole Robinson wrote: > On 07/21/2010 10:42 PM, Lennart Poettering wrote: >> On Wed, 21.07.10 22:13, Chuck Anderson (c...@wpi.edu) wrote: >> >>> >>> Well, there is some merit in the already stated argument for having >>> good UI design.  In this example, you could hav

Re: Weird libprojectM C++ segfaults

On Fri, Jul 23, 2010 at 12:57 PM, Michael Schwendt wrote: > Two crash backtraces in this mail. Does anyone have an idea what might be > wrong there? > > Simply linking any Audacious plugin with -lprojectM leads to a segfault on > application exit. In other words, even if the library is not used but

[Bug 614980] non-responsive maintainer

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=614980 --- Comment #1 from Chris Weyl 2010-07-23 13:33:24 EDT --- I'm going to be (and have been) rather busy for a while -- over the

Re: [HEADS-UP] systemd for F14 - the next steps

On 07/21/2010 10:42 PM, Lennart Poettering wrote: > On Wed, 21.07.10 22:13, Chuck Anderson (c...@wpi.edu) wrote: > >> >> Well, there is some merit in the already stated argument for having >> good UI design. In this example, you could have used long-standing >> precedent of using -v -vv -vvv (o

Weird libprojectM C++ segfaults

Two crash backtraces in this mail. Does anyone have an idea what might be wrong there? Simply linking any Audacious plugin with -lprojectM leads to a segfault on application exit. In other words, even if the library is not used but just linked with, app exit segfaults. That's an indication that so

Re: [HEADS-UP] systemd for F14 - the next steps

On 07/22/2010 07:16 PM, Lennart Poettering wrote: > On Fri, 23.07.10 00:55, Rahul Sundaram (methe...@gmail.com) wrote: > >> >> On 07/23/2010 12:10 AM, Lennart Poettering wrote: >>> Kay and I have discussed this now. We agreed to fold systemd-install >>> into systemctl entirely, and replace --reali

Re: [HEADS-UP] systemd for F14 - the next steps

On Fri, Jul 23, 2010 at 01:31:47PM +0200, Lennart Poettering wrote: > For simplicity's sake we thought it would be smart to ensure that the > unit names are actually identical to the unit configuration files they > are configured in on disk. i.e. you'll find the configuration for a unit > "foobar.s

Re: [HEADS-UP] systemd for F14 - the next steps

tor 2010-07-22 klockan 15:12 -0400 skrev Simo Sorce: > The nss_sss and pam_sss clients know to immediately give up if the > sockets are not there because that means that sssd is not up yet. > If I were to use socket activation instead that service would bring > sssd up unnecessarily early, before

Re: [HEADS-UP] systemd for F14 - the next steps

tor 2010-07-22 klockan 18:48 +0200 skrev Miloslav Trmač: > I don't know whether this currently happens with Fedora, but it is not > at all irrelevant and systemd could indeed make the situation much > worse. A typical problem in the past has been that starting dbus includes looking at users and g

[Bug 502358] Review Request: mojomojo - Catalyst & DBIx::Class powered Wiki

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=502358 --- Comment #19 from Iain Arnell 2010-07-23 10:46:09 EDT --- Wow, Dan is fast! Today's rawhide already has selinux policy labels

Re: [HEADS-UP] systemd for F14 - the next steps

Horst H. von Brand wrote: > Let's go off into a tangent: > > Just booted my x86_64 rawhide box (up to date) into systemd. SELinux is > enforcing. Boot worked, but the machine got stuck on shudown. Had to power off. Thanks $DEITY for journalling filesystems... I saw comments on selinux-policy-ta

Re: [HEADS-UP] systemd for F14 - the next steps

Lennart Poettering wrote: > On Thu, 22.07.10 21:30, Horst H. von Brand (vonbr...@inf.utfsm.cl) wrote: > > Lennart Poettering wrote: > > > On Thu, 22.07.10 15:19, Simo Sorce (sso...@redhat.com) wrote: > > > > [...] > > Sorry, but what if the configuration got screwed up, and > > just won't star

Re: [HEADS-UP] systemd for F14 - the next steps

On Fri, Jul 23, 2010 at 01:42:03PM +0200, Lennart Poettering wrote: > On Fri, 23.07.10 07:15, Toshio Kuratomi (a.bad...@gmail.com) wrote: > > > > Yes, unless you aks the init system to reload. > > > > > So we don't want to do systemd-install enable in most spec files. > > Dunno. > > There are

Re: [HEADS-UP] systemd for F14 - the next steps

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/22/2010 11:31 PM, Horst H. von Brand wrote: > Let's go off into a tangent: > > Just booted my x86_64 rawhide box (up to date) into systemd. SELinux is > enforcing. > > Boot works, but not graphical boot. > > The output from the rc scripts is m

Re: [HEADS-UP] systemd for F14 - the next steps

Let's go off into a tangent: Just booted my x86_64 rawhide box (up to date) into systemd. SELinux is enforcing. Boot works, but not graphical boot. The output from the rc scripts is messed up ([OK] in gray, not green; not at the end of the line but at the start of the next). Several fail. X doe

Re: [HEADS-UP] systemd for F14 - the next steps

On Fri, Jul 23, 2010 at 01:25:23AM +0200, Lennart Poettering wrote: > On Thu, 22.07.10 17:51, Horst H. von Brand (vonbr...@inf.utfsm.cl) wrote: > > > > Kay and I have discussed this now. We agreed to fold systemd-install > > > into systemctl entirely, and replace --realize by --now. Also, we'll >

Re: Partial mass rebuild for Python 2.7 coming soon (I hope)

On 22/07/2010 17:28, David Malcolm wrote: > louizatakk (1): > python-pgu > I fixed the .spec file, it should work properly now, but I can't build on Koji to check. I first built it on devel, and I then tried on the target dis

rawhide report: 20100723 changes

Compose started at Fri Jul 23 08:15:20 UTC 2010 Broken deps for x86_64 -- BackupPC-3.1.0-14.1.fc14.noarch requires perl-suidperl PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requ

Re: [HEADS-UP] systemd for F14 - the next steps

On Fri, 23.07.10 07:15, Toshio Kuratomi (a.bad...@gmail.com) wrote: > > Yes, unless you aks the init system to reload. > > > So we don't want to do systemd-install enable in most spec files. Dunno. There are three levels of installation thinkable: 1) on package installation a .service file is

Re: [HEADS-UP] systemd for F14 - the next steps

On Thu, 22.07.10 23:25, Simo Sorce (sso...@redhat.com) wrote: > > I think this scheme is really simply now, as the operations issued are > > first class commands, and no switches necessary. Also, the verbs here > > are 1:1 from the LSB specs, and hence should offer no surprises to > > anybody. > >

Re: [HEADS-UP] systemd for F14 - the next steps

On Fri, Jul 23, 2010 at 01:49:12AM +0200, Lennart Poettering wrote: > On Thu, 22.07.10 19:41, Toshio Kuratomi (a.bad...@gmail.com) wrote: > > > > if [ $1 -eq 1 ] ; then > > > # For new installations, hook unit file into the appropriate > > > places via symlinks > > > /usr/bin/syst

Re: [HEADS-UP] systemd for F14 - the next steps

On Fri, Jul 23, 2010 at 01:49:12AM +0200, Lennart Poettering wrote: > On Thu, 22.07.10 19:41, Toshio Kuratomi (a.bad...@gmail.com) wrote: > > > > if [ $1 -eq 1 ] ; then > > > # For new installations, hook unit file into the appropriate > > > places via symlinks > > > /usr/bin/syst

Re: Partial mass rebuild for Python 2.7 coming soon (I hope)

Am Thu, 22 Jul 2010 22:37:56 -0500 schrieb Conan Kudo (ニール・ゴンパ) : > I just got a new report from Koji saying there were errors recorded in > root.log for the build of OggConvert on the PPC machines. > > http://koji.fedoraproject.org/koji/getfile?taskID=2344902&name=root.log From root.log: DEBUG