date:20100818

On Wed, Aug 18, 2010 at 01:10:29PM +0200, Adam Tkac wrote:
> Fedora Engineering Services
> (http://fedoraproject.org/wiki/Fedora_Engineering_Services) received
> request to get rid of file requires outside of the primary paths
> (https://fedorahosted.org/fedora-engineering-services/ticket/31).
> 
> Your package directly requires file outside of the primary paths so
> every time when your package is going to be installed/updated complete
> filelists for the distribution have to be downloaded.
> 
> If you prefer to fix your package yourself, please send me a mail till
> end of this week. Otherwise I will fix your package.
> 
> List of affected packages is attached.
> 
> Regards, Adam
> 
> -- 
> Adam Tkac, Red Hat, Inc.

> rjones libguestfs 

I have no intention of changing this.  It's done for a perfectly
good reason described here:

http://lists.fedoraproject.org/pipermail/devel/2010-April/134663.html

[Unless someone is actually willing to do the large amount of work
required to change this (see above) and ensure that performance isn't
affected by the change.]

In addition, I think the reason for doing this is specious.  This
doesn't affect anyone except libguestfs users, and no one has yet
complained to me about the overhead of having to download filelists
while installing libguestfs.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Get rid of file requires outside of the primary paths

2010-08-18 Thread seth vidal

On Wed, 2010-08-18 at 12:24 +0100, Richard W.M. Jones wrote:
> On Wed, Aug 18, 2010 at 01:10:29PM +0200, Adam Tkac wrote:
> > Fedora Engineering Services
> > (http://fedoraproject.org/wiki/Fedora_Engineering_Services) received
> > request to get rid of file requires outside of the primary paths
> > (https://fedorahosted.org/fedora-engineering-services/ticket/31).
> > 
> > Your package directly requires file outside of the primary paths so
> > every time when your package is going to be installed/updated complete
> > filelists for the distribution have to be downloaded.
> > 
> > If you prefer to fix your package yourself, please send me a mail till
> > end of this week. Otherwise I will fix your package.
> > 
> > List of affected packages is attached.
> > 
> > Regards, Adam
> > 
> > -- 
> > Adam Tkac, Red Hat, Inc.
> 
> > rjones libguestfs 
> 
> I have no intention of changing this.  It's done for a perfectly
> good reason described here:
> 
> http://lists.fedoraproject.org/pipermail/devel/2010-April/134663.html
> 
> [Unless someone is actually willing to do the large amount of work
> required to change this (see above) and ensure that performance isn't
> affected by the change.]
> 
> In addition, I think the reason for doing this is specious.  This
> doesn't affect anyone except libguestfs users, and no one has yet
> complained to me about the overhead of having to download filelists
> while installing libguestfs.

I am a libguestfs user and I'm complaining. It means I have to schlep
down a bunch of extra info on every update of libguestfs and that sucks
on my bandwidth.

-sv


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

F-14 Branched report: 20100818 changes

2010-08-18 Thread Branched Report

Compose started at Wed Aug 18 13:15:15 UTC 2010

Broken deps for x86_64
--
CGAL-3.6.1-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
CGAL-3.6.1-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_system-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_program_options-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_serialization-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_regex-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_iostreams-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_system-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_program_options-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_iostreams-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_serialization-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_regex-mt.so.1.41.0()(64bit)
Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6
Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so
PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so
PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit)
PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit)
QuantLib-test-1.0.1-3.fc14.x86_64 requires 
libboost_unit_test_framework.so.1.41.0()(64bit)
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2
1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit)
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
avogadro-1.0.1-2.fc14.x86_64 requires 
libboost_python-mt.so.1.41.0()(64bit)
avogadro-libs-1.0.1-2.fc14.i686 requires libboost_python-mt.so.1.41.0
avogadro-libs-1.0.1-2.fc14.x86_64 requires 
libboost_python-mt.so.1.41.0()(64bit)
bastet-0.43-7.fc13.x86_64 requires 
libboost_program_options.so.1.41.0()(64bit)
cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10
cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
easystroke-0.5.3-1.fc14.x86_64 requires 
libboost_serialization-mt.so.1.41.0()(64bit)
ekg2-python-0.2-0.12.rc1.fc14.x86_64 requires 
libpython2.6.so.1.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libedata-book-1.2.so.2()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-1.2.so.17()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libgtkhtml-editor.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libebook-1.2.so.9()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-provider-1.2.so.17()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit)
fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10
fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit)
frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10
frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
fuse-encfs-1.5-12.fc14.i686 requires libboost_filesystem-mt.so.1.41.0
fuse-encfs-1.5-12.fc14.i686 requires libboost_serialization-mt.so.1.41.0
fuse-encfs-1.5-12.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
fuse-encfs-1.5-12.fc14.x86_64 requires 
libboost_serialization-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_system-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_program_options-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.

[389-devel] Please Review: (620927) Allow multiple membership attributes for one memberof attribute in memberof plugin

2010-08-18 Thread Nathan Kinder

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

https://bugzilla.redhat.com/attachment.cgi?id=439237&action=edit

https://bugzilla.redhat.com/attachment.cgi?id=439237&action=diff
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Upcoming Fedora 14 Tasks

2010-08-18 Thread Orion Poplawski

Perhaps it makes sense to be posting F-15 tasks as well?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upcoming Fedora 14 Tasks

2010-08-18 Thread John Poelstra

Orion Poplawski said the following on 08/16/2010 08:39 PM Pacific Time:
> Perhaps it makes sense to be posting F-15 tasks as well?
>

What would the Fedora 15 tasks be besides, "Do awesome stuff in the 
'rawhide' branch?" :-)

I can certainly draft a Fedora 15 version of the schedule if people are 
already curious where the dates will land.

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

Re: Upcoming Fedora 14 Tasks

2010-08-18 Thread Orion Poplawski

On 08/18/2010 10:06 AM, John Poelstra wrote:
> Orion Poplawski said the following on 08/16/2010 08:39 PM Pacific Time:
>> Perhaps it makes sense to be posting F-15 tasks as well?
>>
>
> What would the Fedora 15 tasks be besides, "Do awesome stuff in the
> 'rawhide' branch?" :-)

That might be it - but part of our new early branch system is so F-15 
development starts happening now.  Periodic reminders of that may be helpful. 
  Just a thought.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F14 Question: AVerMedia AVerTV Volar Black HD/-A850 availability

2010-08-18 Thread Adam Williamson

On Wed, 2010-08-18 at 05:40 -0400, Jaroslav Skarvada wrote:
> > So I copied dvb-usb-af9015.fw from some UBUNTU installation to
> > /lib/firmware, and I could watch digital TV with kaffeine.
> >
> > So my question: would it be possible to support that stick in >= F15
> > versions?
> 
> AFAIK this firmware seems not to be free.

Fedora accepts non-free firmware, but it must be freely redistributable
and meet some other requirements.

http://fedoraproject.org/wiki/Licensing#Binary_Firmware

If this firmware meets those, there exists a SIG to help get it
packaged:

http://fedoraproject.org/wiki/Firmware
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Creating private branches under fedpkg/git

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/4/10 3:01 PM, M A Young wrote:
> What is the policy on creating private branches under fedpkg/git? Can it 
> be done by anyone with acl commit or do you need special permissions?
> 
> My interest is that I had a private branch of the kernel package under CVS 
> which I used to build pvops enabled kernels so that the more adventurous 
> could use a Fedora based Domain-0 kernel with xen. However this branch 
> hasn't been copied across (presumably because of the difficulties in 
> transfering the kernel package) though I could easily continue from a new 
> branch if that is appropriate.
> 
>   Michael Young

The way it works now, if a maintainer has at least commit access to the
master branch (eg rawhide) they can create any top level branches they
want, so long as it doesn't conflict with the naming scheme of our
release branches (f??/master, el?/master, olpc?/master).  Outside of
that, if you have commit access to a specific branch, but not master,
you are allowed to create branches within that name space, eg if you
have commit rights to f13 but not master, you can create branches under
f13/.  Again you cannot conflict with f13/master.

However, since git allows you to create local branches at will without
any restrictions, one has to ask if it is still necessary to have a
remote branch for your work.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxsKUQACgkQ4v2HLvE71NXpMQCeMPidJkbFTsFOIffaGRXgcIPc
Hx8AoJLVsPgIFoovTrgc4K/xjsYrWkC9
=WpXr
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RCS keywords rewritten in dist-git conversion?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/5/10 8:02 AM, Paul Howarth wrote:
> On 02/08/10 20:53, Jesse Keating wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 08/02/2010 11:55 AM, Adam Goode wrote:
>>> Didn't want this to get lost, thanks for fixing this on IRC, but I don't
>>> have an f14 branch now.
>>
>> Got that fixed for ya.
> 
> Same thing (RCS keywords rewritten) happened with 
> php-5.3.3-aconf26x.patch in the php repo. Can that be fixed too please?
> 
> Paul.

Have any changes been made to the php repo since the conversion?  If so,
it'd be better to just grab the old patch from CVS and replace the one
in git.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxsKe0ACgkQ4v2HLvE71NVM+ACgkjZXm1K7endmnAaLBvMSmRCM
bxUAoLF5jbIUSbXUCB6XFIlwSFXUD7U0
=9fN5
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Release bumps scripts caution

2010-08-18 Thread Bruno Wolff III

Release bump scripts bumping release version numbers for prereleases should
be handled more carefully or they can cause update problems later on.
For example xorg-x11-drv-ati-6.13.1-0.20100705git37b348059.fc14 got bumped
to xorg-x11-drv-ati-6.13.1-1.20100705git37b348059.fc14 and then later
xorg-x11-drv-ati-6.13.1-0.2.20100705git37b348059.fc14.

Perhaps release bump scripts should be adding something to the end of the
string so as not to break prelease version numbers.

If they aren't already checking for version information after the dist-tag,
that is another potential place for breakage, though not generally a problem
for rawhide where mass rebuilds with scripts are typically done.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg local redefines %fedora macro

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/9/10 6:54 AM, Petr Pisar wrote:
> Hello,
> 
> while working on `nas' package I found `fedpkg local' redefines
> `fedora' macro to value `1'. Dist-cvs `make local' does not do that.
> Original source for %fedora is /etc/rpm/macros.dist. See the strace:
> 
> $ strace -fqv -eexecve fedpkg local
> [...]
> execve("/bin/rpm", ["rpm", "--define", "_sourcedir
> /home/petr/fedora/nas", "--define", "_specdir /home/petr/fedora/nas",
> "--define", "_builddir /home/petr/fedora/nas", "--define", "_srcrpmdir
> /home/petr/fedora/nas", "--define", "_rpmdir /home/petr/fedora/nas",
> "--define", "dist .fc15", "--define", "fedora 15", "--define", "fedora
> 1", "-q", "--qf", "%{VERSION} ", "--specfile",
> "/home/petr/fedora/nas/nas.spec"],...)
> 
> You can check it with this simple spec file:
> 
> %if 0%{?fedora} > 8
> echo TRUE %{?fedora}
> %else
> echo FALSE %{?fedora}
> %endif
> 
> -- Petr
> 
> 
> 

This was fixed in the latest build of fedpkg.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxsLMQACgkQ4v2HLvE71NUdlQCeJfpgXI0uhN9h5AllEFRAaGHa
tmEAn0n9Ul4e1ZfEH+LtJsa9dDfJmjQj
=6/ip
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Release bumps scripts caution

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/18/10 11:49 AM, Bruno Wolff III wrote:
> Release bump scripts bumping release version numbers for prereleases should
> be handled more carefully or they can cause update problems later on.
> For example xorg-x11-drv-ati-6.13.1-0.20100705git37b348059.fc14 got bumped
> to xorg-x11-drv-ati-6.13.1-1.20100705git37b348059.fc14 and then later
> xorg-x11-drv-ati-6.13.1-0.2.20100705git37b348059.fc14.
> 
> Perhaps release bump scripts should be adding something to the end of the
> string so as not to break prelease version numbers.
> 
> If they aren't already checking for version information after the dist-tag,
> that is another potential place for breakage, though not generally a problem
> for rawhide where mass rebuilds with scripts are typically done.

This likely happened because the original release string was non-conformant.

It should have originally been:

xorg-x11-drv-ati-6.13.1-0.1.20100705git37b348059.fc14

in which case the script would have bumped it to

xorg-x11-drv-ati-6.13.1-0.2.2010705git

So in this case it appears it was a garbage in / garbage out issue.

The bump script lives in releng git repo (git.fedorahosted.org/releng if
anybody wants to hack on it.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxsLsEACgkQ4v2HLvE71NXKYACdFUGNlqTTr9Wla+txM7IsZykm
ES0An2DxRvqXq4C+q4/Uyuv6OM7XbsKg
=dRjo
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Release bumps scripts caution

2010-08-18 Thread Bruno Wolff III

On Wed, Aug 18, 2010 at 12:04:33 -0700,
  Jesse Keating  wrote:
> 
> This likely happened because the original release string was non-conformant.

I missed that. After that happened it looks like the release string did get
changed to be conformant.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Release bumps scripts caution

2010-08-18 Thread Michael Schwendt

On Wed, 18 Aug 2010 12:04:33 -0700, Jesse wrote:

> The bump script lives in releng git repo (git.fedorahosted.org/releng if
> anybody wants to hack on it.

Sure about that? All I could find there was a reference to rpmdev-bumpspec
(part of "rpmdevtools" package nowadays). The older script's home is "fedora"
cvs (= not the pkg cvs), but the version in rpmdevtools is more up-to-date.
And yes, it handles several release versioning schemes including some odd ones.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Release bumps scripts caution

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/18/10 12:24 PM, Michael Schwendt wrote:
> On Wed, 18 Aug 2010 12:04:33 -0700, Jesse wrote:
> 
>> The bump script lives in releng git repo (git.fedorahosted.org/releng if
>> anybody wants to hack on it.
> 
> Sure about that? All I could find there was a reference to rpmdev-bumpspec
> (part of "rpmdevtools" package nowadays). The older script's home is "fedora"
> cvs (= not the pkg cvs), but the version in rpmdevtools is more up-to-date.
> And yes, it handles several release versioning schemes including some odd 
> ones.

Oops.  I had though it was there, but I'm wrong.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxsNCcACgkQ4v2HLvE71NVCVQCguUHYA8F5dUHbJN5lsifKQwmE
BtIAoITnKkIinfGWWPwR+1joMaCIMSnY
=EbZJ
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New bodhi release in production

2010-08-18 Thread Kevin Kofler

Adam Williamson wrote:
> To me, that reads more like a problem with the update submission system
> than anything. I'd like to see far fewer restrictions on it (just like
> I'd like for koji), so you could edit the existing update to add your
> packages. This same issue exists even without feedback requirements.

Editing isn't what I want though, I want to have a newer update in testing 
while keeping the old one not obsolete because it should go out to stable 
ASAP. Bodhi only allows this if it's already queued for stable when the new 
update is submitted, otherwise it automatically obsoletes the old one.

>> The non-critpath packages still have a hard +1 requirement.
> 
> Indeed, but that's not a difficult standard to meet.

That's what I dispute. Especially if you expect people to actually meet the 
testing criteria for a +1. (It's easy and fast to just "swap +1 votes" or 
something like that, but it defeats the purpose of the process.)

>>  where 1 must be a proventester (which is really
>> ridiculous, why isn't a proventester enough?).
> 
> A single tester can often miss an issue, it's good to have at least two
> pairs of eyes.

Only 2 testers can often miss an issue, it's good to have at least 3 pairs 
of eyes.
Only 3 testers can often miss an issue, it's good to have at least 4 pairs 
of eyes.
Only 4 testers can often miss an issue, it's good to have at least 5 pairs 
of eyes.
… (ad infinitum)

Where do we stop? NO amount of testers will catch ALL issues.

In addition, the maintainer certainly won't submit something he thinks is 
broken, so the proventester is already a second pair of eyes.

Each time we decide that one person is not enough (but n are needed), we 
multiply the required manpower to do any work by a factor n! This is not 
something to be taken lightly. We DO NOT HAVE the manpower for this kind of 
QA. It takes VERY LONG to get any kind of positive karma for anything. 
(Negative one can sometimes be gotten quite fast, just screw up blatantly 
enough. ;-) )

And FWIW, I also dislike the fact that our QA process focuses almost 
exclusively on testing (well, there will be AutoQA too soon, but the manual 
checks will still be limited to just testing). I have found proofreading 
(even self-proofreading, but proofreading by another person can be even more 
effective) to be a much more effective form of QA than testing. I have found 
many issues when proofreading changes (both mine and other people's, and 
both for RPM specfiles and actual code) which would almost certainly never 
have been caught through testing (but were still real issues). I always 
proofread my changes before I commit them and I also proofread the specfile 
changes done by comaintainers. IMHO, that should already be sufficient 
ground for validating the resulting update, but according to our process I'm 
not supposed to +1 an update I have "only" proofread the changes of and not 
also tested. (That also reminds me of Knuth's "Beware of bugs in the above 
code; I have only proved it correct, not tried it.". :-) ) It often takes 
much less time to proofread the spec changes than to do testing with any 
kind of reasonable coverage (especially for something like KDevelop), and it 
is much more likely to find issues (because you just can't test everything: 
For example, how many testers actually check for unowned directories? A 
trained proofreader catches these quite reliably, especially if the change 
being proofread is the one making the directory unowned. And do you really 
think you can exhaustively test ALL the features of a powerful application? 
Proofreading can evidence that you broke one (e.g. by dropping a required 
BuildRequires), or that you made only trivial changes extremely unlikely to 
break anything at all). Also a FYI: Often it is also useful to have a look 
at the build.log in addition to the specfile, that will evidence complaints 
by the package's build system (CMake, autoconf-generated configure or 
whatever) about missing optional build requirements (and thus missing 
features). Those are again issues which testing generally does not catch.

> AFAIK, as long as we keep pushing builds through to updates-testing while
> the main repo (which is filled from the dist-f14 tag) is frozen for RC
> composes, there isn't really a problem, as you can keep pushing fixes into
> updates-testing, build things on top of other things there, however you
> like.

Well, now that we basically force everything through testing (though there 
can theoretically still be stuff which gets queued for stable before 
reaching testing if karma comes really quickly), it is not such a big 
problem anymore, but before, we had the paradoxical situation where urgent 
fixes queued directly for stable did not become available whereas 
unimportant stuff went out to testing just fine. :-/ Banning direct stable 
pushes entirely strikes me as the entirely wrong solution for this issue, 
basically solving the wrong problem.

> except that systemd

Re: New bodhi release in production

2010-08-18 Thread Kevin Kofler

Thomas Janssen wrote:
> I'm part of the KDE SIG. I will apply today for proventester to become
> the KDE proventester.

Actually, Rex Dieter already started the application process, so you'll 
probably become "a" KDE proventester, not "the" KDE proventester. ;-)

But the more proventesters we have, the better!

Kevin Kofler

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

Re: New bodhi release in production

2010-08-18 Thread Thomas Janssen

On Wed, Aug 18, 2010 at 9:51 PM, Kevin Kofler  wrote:
> Thomas Janssen wrote:
>> I'm part of the KDE SIG. I will apply today for proventester to become
>> the KDE proventester.
>
> Actually, Rex Dieter already started the application process, so you'll
> probably become "a" KDE proventester, not "the" KDE proventester. ;-)

I'm glad to see you still know how to make friends ;) BTW I'm already
"a" proventester.
Another BTW, if you think you have to write "something", a simple
'thank you for stepping up' would have been enough.

-- 
LG Thomas

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

Re: New bodhi release in production

2010-08-18 Thread Kevin Kofler

Thomas Janssen wrote:
> Another BTW, if you think you have to write "something", a simple
> 'thank you for stepping up' would have been enough.

Well, yes, thank you for stepping up, your help is very much appreciated! I 
didn't mean to offend you!

(And thanks to Rex Dieter as well, by the way.)

Kevin Kofler

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

Re: RCS keywords rewritten in dist-git conversion?

2010-08-18 Thread Paul Howarth

On Wed, 18 Aug 2010 11:43:57 -0700
Jesse Keating  wrote:
> On 8/5/10 8:02 AM, Paul Howarth wrote:
> > On 02/08/10 20:53, Jesse Keating wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 08/02/2010 11:55 AM, Adam Goode wrote:
> >>> Didn't want this to get lost, thanks for fixing this on IRC, but
> >>> I don't have an f14 branch now.
> >>
> >> Got that fixed for ya.
> > 
> > Same thing (RCS keywords rewritten) happened with 
> > php-5.3.3-aconf26x.patch in the php repo. Can that be fixed too
> > please?
> > 
> > Paul.
> 
> Have any changes been made to the php repo since the conversion?  If
> so, it'd be better to just grab the old patch from CVS and replace
> the one in git.

No changes: the heads of the f12, f13, f14 and master branches all
point to the "dist-git conversion" commit.

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

Re: Upcoming Fedora 14 Tasks

2010-08-18 Thread Adam Williamson

On Wed, 2010-08-18 at 10:43 -0600, Orion Poplawski wrote:
> On 08/18/2010 10:06 AM, John Poelstra wrote:
> > Orion Poplawski said the following on 08/16/2010 08:39 PM Pacific Time:
> >> Perhaps it makes sense to be posting F-15 tasks as well?
> >>
> >
> > What would the Fedora 15 tasks be besides, "Do awesome stuff in the
> > 'rawhide' branch?" :-)
> 
> That might be it - but part of our new early branch system is so F-15 
> development starts happening now.  Periodic reminders of that may be helpful. 
>   Just a thought.

We could combine both. I mean, Fedora isn't above a little levity. You
could run a schedule with both the planned 'serious' dates for the F15
schedule, plus stuff like - maybe two months before F15 Alpha freeze -
'Your awesome new feature should have stopped eating babies by now'...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: RCS keywords rewritten in dist-git conversion?

2010-08-18 Thread Garrett Holmstrom

Paul Howarth wrote:
> No changes: the heads of the f12, f13, f14 and master branches all
> point to the "dist-git conversion" commit.

In case it matters, these branches point to two completely separate 
commits; f12 has an entirely different history from f13, f14, and master 
as far as git is concerned.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Creating private branches under fedpkg/git

2010-08-18 Thread M A Young

On Wed, 18 Aug 2010, Jesse Keating wrote:

> However, since git allows you to create local branches at will without
> any restrictions, one has to ask if it is still necessary to have a
> remote branch for your work.

I did end up creating a branch in the Fedora system because it was the 
only way I could get koji to build directly from git.

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

Re: Get rid of file requires outside of the primary paths

On Wed, Aug 18, 2010 at 08:02:13AM -0400, seth vidal wrote:
> I am a libguestfs user and I'm complaining. It means I have to schlep
> down a bunch of extra info on every update of libguestfs and that sucks
> on my bandwidth.

This is basically a hard problem to solve. We rely on copying files
directly from the host into our appliance, so we rely on file
dependencies. We could change it so we didn't need file dependencies,
but that would cause silent breakage on updates. Actually our file
dependencies currently are conservative and don't cover all the files
really required (just libraries), so if we extended them to cover
completely what was needed and avoid all possible breakage, we'd need
more of them, not less.

Can we make filelists smaller and thus easier to download? The
current Rawhide filelists.sqlite is 84MB (uncompressed). Within the
filelists table the only "compression" as such is the use of a single
row for multiple files in the same directory, plus the compression
applied to the database as a whole when it is downloaded.

There are data structures which are suited to storing lists of strings
with a common prefix. The obvious one would be a prefix tree (trie):

http://en.wikipedia.org/wiki/Trie

However I tried (ha ha) an implementation of a trie (below) for
storing a simple list of filenames, and it didn't do better than plain
gzip at compressing the filenames. Though *in theory* it should work
better, so probably I'm doing something wrong.

http://www-tsujii.is.s.u-tokyo.ac.jp/~hillbig/tx.htm

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Get rid of file requires outside of the primary paths

On Wed, Aug 18, 2010 at 10:43:16PM +0100, Richard W.M. Jones wrote:
> http://en.wikipedia.org/wiki/Trie

This one too:
http://en.wikipedia.org/wiki/Radix_tree

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

On Wed, Aug 04, 2010 at 12:10:11AM +0200, Lennart Poettering wrote:
 > Heya,
 > 
 > just a little heads up for when you upgrade a rawhide system that is a
 > few weeks old to current rawhide: since we changed the way how some of
 > the default symlinks of systemd are created you will end up with an
 > installation that lacks many of the necessary symlinks -- but only if
 > you upgrade from a systemd version from older rawhide to current
 > rawhide. It's really only a problem in this case. It is not a problem
 > with fresh F14 installations, and it is not a problem with upgrades from
 > F13. The fix is easy: after upgrading just run this command as root and
 > the missing links should be created:
 > 
 > # systemctl enable ge...@.service prefdm.service getty.target 
 > rc-local.service remote-fs.target
 > 
 > And that should make things work again.

even after doing this, I still haven't managed to get a single box running 
systemd.
They all hang after complaining that it failed to load configuration for 
default.target
(and a bunch of other services like distcache, livesys-late, cman)

It tells me to see the logs for details, but there's not a single message
from systemd in the logs.

as an aside: it also prints out some bogus messages about autofs and ipv6 being
missing. if you could remove those, that would likely save some pointless bug 
reports.

Dave

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

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

On Wed, 18.08.10 18:15, Dave Jones (da...@redhat.com) wrote:

>  > # systemctl enable ge...@.service prefdm.service getty.target 
> rc-local.service remote-fs.target
>  > 
>  > And that should make things work again.
> 
> even after doing this, I still haven't managed to get a single box running 
> systemd.
> They all hang after complaining that it failed to load configuration for 
> default.target
> (and a bunch of other services like distcache, livesys-late, cman)

Have you seen the two follow-up messages I posted to this one? You need
to create the default.target link as well. See those two mails for details.

> It tells me to see the logs for details, but there's not a single message
> from systemd in the logs.

There should be an explanation in dmesg, that it cannot find default.target.

> as an aside: it also prints out some bogus messages about autofs and ipv6 
> being
> missing. if you could remove those, that would likely save some pointless bug 
> reports.

Well, systemd by default uses autofs for certain "API" vfs mounts, such
as binfmt_misc: we create the mount point and only when it is accessed
we actually mount the file system on it. This has the effect that we'll
load the binfmt kernel module only when somebody actaully writes
something to the fs. i.e. we make the mount points availabale all the
time in the file system, but the backing module is not necessarily
loaded. Something similar applies to a couple of other non-essential
virtual "API" file systems. 

When systemd initializes we will initialize autofs too (by opening
/dev/autofs), and that will fail if the module is not loaded (and the
usual module-autoloading won't work for the autofs device node since
udev isn't around yet, and the device node is hence not created yet).

systemd also configures the lo network device by default as part of
early bootup, as part of its normal startup code (in C). here too module
autoloading doesn't work, since configuring an ipv6 address on lo will
not cause the protocol module to be loaded.

So, in summary, we have to modprobe autofs and ipv6 manually before we
go on with the startup, and given that this is how it is I don't think
it makes much sense compiling them as a module anymore. It's similarly
pointless as compiling unix.ko as a module, or the RTC module. It just
slows down the boot and will be loaded into the kernel anyway. And
that's why we complain.

(note that systemd will still boot if autofs and ipv6 aren't available
at all, it's not essential and we actually do honour the modprobe
blacklist)

Lennart

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

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

On Thu, Aug 19, 2010 at 12:32:01AM +0200, Lennart Poettering wrote:
 > On Wed, 18.08.10 18:15, Dave Jones (da...@redhat.com) wrote:
 > 
 > >  > # systemctl enable ge...@.service prefdm.service getty.target 
 > > rc-local.service remote-fs.target
 > >  > 
 > >  > And that should make things work again.
 > > 
 > > even after doing this, I still haven't managed to get a single box running 
 > > systemd.
 > > They all hang after complaining that it failed to load configuration for 
 > > default.target
 > > (and a bunch of other services like distcache, livesys-late, cman)
 > 
 > Have you seen the two follow-up messages I posted to this one? You need
 > to create the default.target link as well. See those two mails for details.

ah, missed that in the noise. thanks. 

 > > It tells me to see the logs for details, but there's not a single message
 > > from systemd in the logs.
 > 
 > There should be an explanation in dmesg, that it cannot find default.target.

at the stage that it stopped, I guess syslog wasn't running, so it never made
it into the boot logs. 

 > > as an aside: it also prints out some bogus messages about autofs and ipv6 
 > > being
 > > missing. if you could remove those, that would likely save some pointless 
 > > bug reports.
 > 
 > Well, systemd by default uses autofs for certain "API" vfs mounts, such
 > as binfmt_misc: we create the mount point and only when it is accessed
 > we actually mount the file system on it. This has the effect that we'll
 > load the binfmt kernel module only when somebody actaully writes
 > something to the fs. i.e. we make the mount points availabale all the
 > time in the file system, but the backing module is not necessarily
 > loaded. Something similar applies to a couple of other non-essential
 > virtual "API" file systems. 
 > 
 > When systemd initializes we will initialize autofs too (by opening
 > /dev/autofs), and that will fail if the module is not loaded (and the
 > usual module-autoloading won't work for the autofs device node since
 > udev isn't around yet, and the device node is hence not created yet).

this seems like a rube goldberg machine to me, but ok.
 
 > systemd also configures the lo network device by default as part of
 > early bootup, as part of its normal startup code (in C). here too module
 > autoloading doesn't work, since configuring an ipv6 address on lo will
 > not cause the protocol module to be loaded.
 >
 > So, in summary, we have to modprobe autofs and ipv6 manually before we
 > go on with the startup, and given that this is how it is I don't think
 > it makes much sense compiling them as a module anymore. It's similarly
 > pointless as compiling unix.ko as a module, or the RTC module. It just
 > slows down the boot and will be loaded into the kernel anyway. And
 > that's why we complain.
 > 
 > (note that systemd will still boot if autofs and ipv6 aren't available
 > at all, it's not essential and we actually do honour the modprobe
 > blacklist)

we had to revert the ipv6=y change for rhel6 because someone showed that it's
actually costly in high performance networking cases where ipv6 isn't even used.
rhel7 may be a long ways away, but eventually, systemd will have to
be made to handle that case, so it may as well get it right from the start.

There will always be use cases for disabling ipv6, so building it in
seems ill advised.

Dave

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

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

On Wed, 18.08.10 18:45, Dave Jones (da...@redhat.com) wrote:

> 
> On Thu, Aug 19, 2010 at 12:32:01AM +0200, Lennart Poettering wrote:
>  > On Wed, 18.08.10 18:15, Dave Jones (da...@redhat.com) wrote:
>  > 
>  > >  > # systemctl enable ge...@.service prefdm.service getty.target 
> rc-local.service remote-fs.target
>  > >  > 
>  > >  > And that should make things work again.
>  > > 
>  > > even after doing this, I still haven't managed to get a single box 
> running systemd.
>  > > They all hang after complaining that it failed to load configuration for 
> default.target
>  > > (and a bunch of other services like distcache, livesys-late, cman)
>  > 
>  > Have you seen the two follow-up messages I posted to this one? You need
>  > to create the default.target link as well. See those two mails for details.
> 
> ah, missed that in the noise. thanks. 
> 
>  > > It tells me to see the logs for details, but there's not a single message
>  > > from systemd in the logs.
>  > 
>  > There should be an explanation in dmesg, that it cannot find 
> default.target.
> 
> at the stage that it stopped, I guess syslog wasn't running, so it never made
> it into the boot logs. 

Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so
nothing should get lost -- as long as you manage to get a shell somehow.

BTW, as a side note: a simply fix to bypass the problem with a missing
default.target is to pass "5" on the kernel command line. This will then
boot into gdm regardless whether default.target exists or not.

the git version of systemd will automatically enter signle user mode if
default.target is missing or borked.

>  > When systemd initializes we will initialize autofs too (by opening
>  > /dev/autofs), and that will fail if the module is not loaded (and the
>  > usual module-autoloading won't work for the autofs device node since
>  > udev isn't around yet, and the device node is hence not created yet).
> 
> this seems like a rube goldberg machine to me, but ok.

Well, we have autofs support anyway, and using it is very simple in
systemd, and given that these API mounts are optional and backed by
seldomly used kernel modules this seemed like a sensible thing to do
these things. This way all those ugly scripts which manually modprobe
and mount the respective modules can go away, everything is available in
the file system namespace right-away and even the privileges problem is
gone.

Lennart

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

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

On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote:
 
 > >  > > It tells me to see the logs for details, but there's not a single 
 > > message
 > >  > > from systemd in the logs.
 > >  > 
 > >  > There should be an explanation in dmesg, that it cannot find 
 > > default.target.
 > > 
 > > at the stage that it stopped, I guess syslog wasn't running, so it never 
 > > made
 > > it into the boot logs. 
 > 
 > Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so
 > nothing should get lost -- as long as you manage to get a shell somehow.
 > 
 > BTW, as a side note: a simply fix to bypass the problem with a missing
 > default.target is to pass "5" on the kernel command line. This will then
 > boot into gdm regardless whether default.target exists or not.
 > 
 > the git version of systemd will automatically enter signle user mode if
 > default.target is missing or borked.
 
So I got it booting after creating the default.target symlink, but the network
no longer comes up automatically (nor services dependant upon it, like sshd).
Did I miss another mail ?

Dave

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

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

On Wed, 18.08.10 19:00, Dave Jones (da...@redhat.com) wrote:

>  > Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so
>  > nothing should get lost -- as long as you manage to get a shell somehow.
>  > 
>  > BTW, as a side note: a simply fix to bypass the problem with a missing
>  > default.target is to pass "5" on the kernel command line. This will then
>  > boot into gdm regardless whether default.target exists or not.
>  > 
>  > the git version of systemd will automatically enter signle user mode if
>  > default.target is missing or borked.
>  
> So I got it booting after creating the default.target symlink, but the network
> no longer comes up automatically (nor services dependant upon it, like sshd).
> Did I miss another mail ?

The NM packages didn't properly enable its service. dcbw has already
fixed this now, but it isn't in f14 yet.

You should be able to work around this by invoking "systemctl enable
NetworkManager.service" and "systemctl start NetworkManager.service".

Lennart

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

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

On Wed, Aug 18, 2010 at 07:00:16PM -0400, Dave Jones wrote:
 > On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote:
 >  
 >  > >  > > It tells me to see the logs for details, but there's not a single 
 > message
 >  > >  > > from systemd in the logs.
 >  > >  > 
 >  > >  > There should be an explanation in dmesg, that it cannot find 
 > default.target.
 >  > > 
 >  > > at the stage that it stopped, I guess syslog wasn't running, so it 
 > never made
 >  > > it into the boot logs. 
 >  > 
 >  > Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so
 >  > nothing should get lost -- as long as you manage to get a shell somehow.
 >  > 
 >  > BTW, as a side note: a simply fix to bypass the problem with a missing
 >  > default.target is to pass "5" on the kernel command line. This will then
 >  > boot into gdm regardless whether default.target exists or not.
 >  > 
 >  > the git version of systemd will automatically enter signle user mode if
 >  > default.target is missing or borked.
 >  
 > So I got it booting after creating the default.target symlink, but the 
 > network
 > no longer comes up automatically (nor services dependant upon it, like sshd).
 > Did I miss another mail ?

related to this I guess  ?

[   44.659412] init[1]: Failed to load configuration for 
NetworkManager-by-dbus.service: No such file or directory
[   44.659596] init[1]: D-Bus activation failed for 
NetworkManager-by-dbus.service: Invalid argument

Dave

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

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

On Wed, 18.08.10 19:35, Dave Jones (da...@redhat.com) wrote:

> 
> On Wed, Aug 18, 2010 at 07:00:16PM -0400, Dave Jones wrote:
>  > On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote:
>  >  
>  >  > >  > > It tells me to see the logs for details, but there's not a 
> single message
>  >  > >  > > from systemd in the logs.
>  >  > >  > 
>  >  > >  > There should be an explanation in dmesg, that it cannot find 
> default.target.
>  >  > > 
>  >  > > at the stage that it stopped, I guess syslog wasn't running, so it 
> never made
>  >  > > it into the boot logs. 
>  >  > 
>  >  > Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so
>  >  > nothing should get lost -- as long as you manage to get a shell somehow.
>  >  > 
>  >  > BTW, as a side note: a simply fix to bypass the problem with a missing
>  >  > default.target is to pass "5" on the kernel command line. This will then
>  >  > boot into gdm regardless whether default.target exists or not.
>  >  > 
>  >  > the git version of systemd will automatically enter signle user mode if
>  >  > default.target is missing or borked.
>  >  
>  > So I got it booting after creating the default.target symlink, but the 
> network
>  > no longer comes up automatically (nor services dependant upon it, like 
> sshd).
>  > Did I miss another mail ?
> 
> related to this I guess  ?
> 
> [   44.659412] init[1]: Failed to load configuration for 
> NetworkManager-by-dbus.service: No such file or directory
> [   44.659596] init[1]: D-Bus activation failed for 
> NetworkManager-by-dbus.service: Invalid argument

Yupp,

Lennart

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

Fedora 14 Alpha Declared GOLD

2010-08-18 Thread John Poelstra

At the Go/No-Go meeting a few minutes ago the Fedora 14 Alpha release 
was declared GOLD. Thank you to everyone who contributed to making it 
happen!

All the details of the meeting can be found here:

Minutes: 
http://meetbot.fedoraproject.org/fedora-meeting/2010-08-19/fedora-meeting.2010-08-19-00.00.html
Minutes (text): 
http://meetbot.fedoraproject.org/fedora-meeting/2010-08-19/fedora-meeting.2010-08-19-00.00.txt
Log: 
http://meetbot.fedoraproject.org/fedora-meeting/2010-08-19/fedora-meeting.2010-08-19-00.00.log.html
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RCS keywords rewritten in dist-git conversion?

2010-08-18 Thread Mr. Teo En Ming (Zhang Enming) of Singapore

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/18/10 1:31 PM, Paul Howarth wrote:
> On Wed, 18 Aug 2010 11:43:57 -0700
> Jesse Keating  wrote:
>> On 8/5/10 8:02 AM, Paul Howarth wrote:
>>> On 02/08/10 20:53, Jesse Keating wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 08/02/2010 11:55 AM, Adam Goode wrote:
> Didn't want this to get lost, thanks for fixing this on IRC, but
> I don't have an f14 branch now.

 Got that fixed for ya.
>>>
>>> Same thing (RCS keywords rewritten) happened with 
>>> php-5.3.3-aconf26x.patch in the php repo. Can that be fixed too
>>> please?
>>>
>>> Paul.
>>
>> Have any changes been made to the php repo since the conversion?  If
>> so, it'd be better to just grab the old patch from CVS and replace
>> the one in git.
> 
> No changes: the heads of the f12, f13, f14 and master branches all
> point to the "dist-git conversion" commit.
> 
> Paul.

Ok, I think I have this repo re-converted.  Give it a test run and let
me know.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxsfk4ACgkQ4v2HLvE71NWwqgCeNtVDecy3f+Di8agxzHZDolCH
xzEAn2/mh/JVBznPs8Zp8Df0PiSLKWj7
=56OQ
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Xen-devel] Xen patches merged to upstream Linux 2.6.36, plans for 2.6.37?


Dear Pasi, Xen developers, and Han Weidong of Intel Corporation,

I have made a video demonstrating Intel IGD (primary VGA adapter) VGA 
passthrough to Windows XP Home Edition HVM domU virtual machine with Xen 
4.0.1-rc6-pre and Jeremy Fitzhardinge's pv-ops dom0 kernel 2.6.32.19 on 
18 August 2010 Wednesday at 5:38 P.M. Singapore Time. The video 
demonstrates a very long time lag (approximately 3-5 minutes) before 
Windows XP Home Edition HVM virtual machine starts booting after 
executing the command "xm create winxphome32". WinXP Home Edition HVM 
domU is unable to load the SoundMAX audio driver and re-detects Intel HD 
Audio, and eventually crashes with a Blue Screen of Death (BSOD).


I have just finished uploading the video to my Youtube account (19 
August 2010 Thursday 9:16 A.M. Singapore Time).


Please watch my video at the following link/URL:

http://www.youtube.com/watch?v=mL4C_InwZH8

At the time of this writing, there are 21 uploaded videos in my Youtube 
account.


Please visit

http://www.youtube.com/user/enmingteo

Thank you very much.

Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Citizenship: Singapore Citizen/Singaporean
Facebook account: Teo En Ming (Zhang Enming)
Facebook link:http://www.facebook.com/profile.php?id=10750083982
Facebook photos:
http://www.facebook.com/profile.php?id=10750083982#!/profile.php?id=10750083982&v=photos
  

Facebook videos:
http://www.facebook.com/profile.php?id=10750083982&v=app_2392950137  

Mobile Phone (Starhub pre-paid): +65-8369-2618
Windows Live Messenger:teoenming at hotmail.com  

Location: Bedok Reservoir Road, Singapore
ZIP: 470103
My Open Letter (Plea for Medical Help/Assistance) to World Leaders:-
http://lists.mcs.anl.gov/pipermail/mpich-discuss/2010-August/007693.html
http://lists.fedoraproject.org/pipermail/users/2010-August/380213.html
http://mythtv.org/pipermail/mythtv-users/2010-August/294733.html






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

Re: Get rid of file requires outside of the primary paths

2010-08-18 Thread Matt McCutchen

On Wed, 2010-08-18 at 22:43 +0100, Richard W.M. Jones wrote:
> On Wed, Aug 18, 2010 at 08:02:13AM -0400, seth vidal wrote:
> > I am a libguestfs user and I'm complaining. It means I have to schlep
> > down a bunch of extra info on every update of libguestfs and that sucks
> > on my bandwidth.
> 
> This is basically a hard problem to solve.  We rely on copying files
> directly from the host into our appliance, so we rely on file
> dependencies.  We could change it so we didn't need file dependencies,
> but that would cause silent breakage on updates.

There are plenty of other kinds of breakage that cannot be caught by RPM
dependencies.  Why do you insist on using RPM dependencies to catch this
kind, rather than testing and communication with the maintainers of the
packages you depend on?

The benefit of catching a moved file at RPM install time rather than in
testing has to be weighed against the cost for all your users to
download the file list.

-- 
Matt

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

[HEADS-UP] python-numarray will be retired for devel/f14 in 3 days

2010-08-18 Thread Chen Lei

numarray is being phased out and replaced by numpy for 4 years, two
packages will be affected after retiring python-numarray in fedora,
however both of them can also work file with numpy.

repoquery --alldeps --whatrequires python-numarray
python-numarray-0:1.5.2-10.fc14.x86_64
HippoDraw-devel-0:1.21.1-12.fc15.i686
HippoDraw-devel-0:1.21.1-12.fc15.x86_64
HippoDraw-python-0:1.21.1-12.fc15.x86_64
scitools-extras-0:0.6-4.fc14.noarch
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] python-numarray will be retired for devel/f14 in 3 days

2010-08-18 Thread Chen Lei

2010/8/19 Chen Lei :
> numarray is being phased out and replaced by numpy for 4 years, two
> packages will be affected after retiring python-numarray in fedora,
> however both of them can also work file with numpy.
>
> repoquery --alldeps --whatrequires python-numarray
> python-numarray-0:1.5.2-10.fc14.x86_64
> HippoDraw-devel-0:1.21.1-12.fc15.i686
> HippoDraw-devel-0:1.21.1-12.fc15.x86_64
> HippoDraw-python-0:1.21.1-12.fc15.x86_64
> scitools-extras-0:0.6-4.fc14.noarch
>
Typo:

s/file/fine

Regrads,
Chen Lei
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Javascript JIT in web browsers

2010-08-18 Thread Matt McCutchen

On Tue, 2010-08-17 at 21:31 +0200, Kevin Kofler wrote: 
> Adam Williamson wrote:
> > Shipping a Firefox with no ability to use Javascript would be more or
> > less equal to not shipping it, frankly. No-one would use the thing.
> 
> What I suggest is just to use the same old JavaScript interpreter we have 
> used before the JIT was introduced, which they undoubtedly keep working for 
> those platforms which don't have JIT support available at all. That doesn't 
> mean no JavaScript support, just a performance impact which is probably 
> negligible on most sites

Gmail makes very heavy use of JavaScript, so I bet the difference there
is significant.  There may be Free Software web applications for which
the same is true, I'm just not familiar with them.  I know you won't
believe me; someone who knows how will have to perform a test.

> and much better security.

You haven't convinced me of this.  Are vulnerabilities that let one
inject enough code to exploit the JIT (particularly after the SELinux
patch) really that easy to find?  But others have a better understanding
of attacks in machine code than I do.

-- 
Matt

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

Re: Get rid of file requires outside of the primary paths