Re: moderated/held messages on mailing lists

[Richard W.M. Jones]

On Fri, May 21, 2010 at 05:42:38PM -0400, Seth Vidal wrote:
> On Fri, 21 May 2010, Richard W.M. Jones wrote:
> > On Fri, May 21, 2010 at 05:25:00PM -0400, Seth Vidal wrote:
> >> Hi Everyone,
> >>  If you are receiving this email then you are listed as the owner of a
> >> mailing list hosted by the fedora project. We've had a lot of messages
> >> sitting in the heldmsg queue in mailman. This is where messages that are
> >> being held for list admin or moderator approval go. They sit there
> >> FOREVER until someone discards them.
> >>
> >> With this in mind we'll be instituting a 1 month age out for these
> >> messages. If a message is in the heldmsg queue for longer than 1 month
> >> the message will be discarded.
> >>
> >> Most of these messages are from people (or spam bots) who are not
> >> subscribed to the list. If you would rather that messages from addresses
> >> not subscribed to the list were rejected instead of being held for
> >> approval, this is a configuration option in the mailing list admin pages
> >> available to you, the list owner.
> >>
> >> If you have questions on how to set that up please feel free to contact
> >> the fedora infrastructure folks.
> >
> > Is disk space so expensive these days?
> 
> It's not disk space it is actually crowded directories. Mailman puts them 
> all in one dir and directory access start to slow down when you have 21K 
> entries in them.

So the problem is not length of time, but number of messages in a
directory.  Why is the limit not set on number of messages, rather
than time?  Is there one directory for the whole of the Fedora mail
system, or one directory per mailing list?  Can individual mailing
lists opt for longer timeouts?

> Why did you cc this to the devel list? It wasn't sent there.

So this can be discussed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: moderated/held messages on mailing lists

[Michael Schwendt]

On Fri, 21 May 2010 16:41:14 -0500, Matt_Domsch wrote:

> It has nothing to do with disk space.  Sitting on a few hundred thousand spam 
> messages for no reason, that'll get ignored forever, and that slow mailman 
> down, serves no purpose.
> 
> If moderators want to actually moderate their lists for spam and 
> non-subscribers, they're welcome to do so.  But to be configured to moderate, 
> but never actually moderate, serves no purpose.
> 

Whose idea was it to enter moderated mailing lists as package owners
in pkgdb?

When sending mail to the package-owner Fedora aliases, for some packages
the mail is rejected by a mailing-list, for other packages it is aded to a
list's queue. Hopefully there's one human being receiving and reading the
incoming mail, or else the purpose of the package-owner aliases is defeated.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: web-m and Fedora 14

[Thorsten Leemhuis]

On 20.05.2010 18:42, Jesse Keating wrote:
> On Thu, 2010-05-20 at 14:25 +0100, Bastien Nocera wrote:
>> I'd expect most of the support to end up in F13 updates, so I'm not
>> sure a feature page really makes sense. 
> This happens with a lot of our features anyway, [...]

And that imho is quite bad for everyone involved, as it kind of makes
everyone unhappy afaics.

To explain: Journalists (even those that are familiar with Fedora) can't
know each and every details of Fedora and thus rely on those feature
pages quite a lot. So after reading
http://fedoraproject.org/wiki/Features/KDE44 (¹) they might write (for
example) something like "One of the new interesting things in Fedora 13
is KDE 4.4" .

But most people that already use KDE and Fedora 12 will know: that's
nothing new, I already got that version via updates weeks ago. So they
will think "the journalists is not well informed, I don't need to read
this article any further". Some might ever write to the journalist "you
wrote crap, this is nothing new". So he might be angry with the Fedora
project, as the information it provided misguided him. That might
influence his writing for later releases, which is not what we want.

CU
knurd

(¹) Yes, that page contains "Currently KDE 4.4.2 is packaged in the
devel and Fedora 13 branches and also shipped in updates to Fedora 11
and 12.". But journalists are busy people and might not have time to
read each and every feature page completely (and might miss is easily
if they do).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Features in new releases / updates

[Matt McCutchen]

On Sat, 2010-05-22 at 10:14 +0200, Thorsten Leemhuis wrote:
> On 20.05.2010 18:42, Jesse Keating wrote:
> > On Thu, 2010-05-20 at 14:25 +0100, Bastien Nocera wrote:
> >> I'd expect most of the support to end up in F13 updates, so I'm not
> >> sure a feature page really makes sense. 
> > This happens with a lot of our features anyway, [...]
> 
> And that imho is quite bad for everyone involved, as it kind of makes
> everyone unhappy afaics.
> 
> To explain: Journalists (even those that are familiar with Fedora) can't
> know each and every details of Fedora and thus rely on those feature
> pages quite a lot. So after reading
> http://fedoraproject.org/wiki/Features/KDE44 (¹) they might write (for
> example) something like "One of the new interesting things in Fedora 13
> is KDE 4.4" .
> 
> But most people that already use KDE and Fedora 12 will know: that's
> nothing new, I already got that version via updates weeks ago. So they
> will think "the journalists is not well informed, I don't need to read
> this article any further". Some might ever write to the journalist "you
> wrote crap, this is nothing new". So he might be angry with the Fedora
> project, as the information it provided misguided him. That might
> influence his writing for later releases, which is not what we want.

Has that ever actually happened?  As a Fedora user, I would tend to cut
journalists a lot of slack in the situation you describe.  The important
information is that the feature is a focus of current work and is worth
trying out if I think it might be useful to me; having the details of
availability in releases right is secondary.

Without addressing other reasons, I think keeping the situation simple
for journalists is a pretty weak reason not to add a feature to an
existing release via updates.

-- 
Matt

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

Re: Packages depending on Yelp

[Patrice Dumas]

On Fri, May 21, 2010 at 07:08:20AM +0530, Rahul Sundaram wrote:
> 
> That sounds like a bug.  Which applications are that way? 

I may not be the most qualified to answer that, but it seems to me
that the manuals are more or less docbook manuals, omf files are just metadata
for the manuals. So there may be some manuals distributed that way 
that are not associated with a button in an interface. In that case
the -doc package may be optional, and there should be no yelp dependency.
I recall that it was the case for gnash for some time. At least some of 
the manuals weren't associated with the user interface.

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

Re: moderated/held messages on mailing lists

[Frank Ch. Eigler]

 writes:

> It has nothing to do with disk space.  Sitting on a few hundred
> thousand spam messages for no reason, that'll get ignored forever,
> and that slow mailman down, serves no purpose.

But why would there be so many spam messages in need of manual
moderation?  Surely there is a spam filtering service enabled for
fedoraproject.org mailing lists.

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

Re: Font rendering in F13

[Ilyes Gouta]

Hi,

Will the bytecode interpreter in freetype be enabled for Fedora 14?

-Ilyes Gouta

On Wed, Mar 3, 2010 at 11:53 PM, Matthias Clasen  wrote:
> Hey,
>
> early in the F13 cycle, we enabled the bytecode interpreter in our
> freetype package, since the patents on that have expired last fall.
> Unfortunately, it turned out that many free fonts don't actually benefit
> from this, and actually look worse with the bci. The reason for that is
> that without the bci, freetype uses its autohinter on all fonts, but
> with the bci turned on, it only applies hints to fonts which have them,
> and leaves other fonts alone.
>
> Behdad investigated the situation, and we have a plan to fix this, but
> doing it properly requires enhancements in multiple places (freetype,
> fontconfig, pango), and will not be ready in time for F13.
>
> Therefore, we decided to turn the bci off again until the necessary
> changes are in place to use it only on fonts which benefit from it. This
> change went into freetype-2.3.11-3.fc13.
>
> If your fonts look subtly different tomorrow, this is why...
>
>
> Matthias
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20100517 changes

[Mattias Ellert]

fre 2010-05-21 klockan 19:55 -0500 skrev Matt Domsch:
> On Fri, May 21, 2010 at 08:40:12AM +0100, Richard W.M. Jones wrote:
> > On Fri, May 21, 2010 at 07:44:48AM +0200, Kevin Kofler wrote:
> > > Rawhide Report wrote:
> > > > mumble-1.2.2-8.fc14
> > > > ---
> > > > * Sun May 16 2010 Andreas Osowski  - 1.2.2-8
> > > > - Rebuild for protobuf ABI change
> > > > - Added redhat-lsb to the Requires for murmur
> > > 
> > > As already noted by Rahul Sundaram when this change was made in CVS, 
> > > redhat-
> > > lsb is NOT a valid dependency for a Fedora package,[...]
> > 
> > What happens if we want to run the /usr/bin/lsb_release command?
> > 
> > I needed that the other day, but when I saw the lsb_release is in
> > redhat-lsb which requires a vast number of libraries, I found an
> > alternate method.
> 
> Look in rawhide now.   The redhat-lsb SRPM has been split into
> multiple subpackages, including -graphics and -printing exactly so
> that you can Require: lsb   to get the initscript and lsb_release
> stuff, without also pulling in all the graphics and printing
> libraries.

This is a step in the right direction, but it is only half way. To be
useful lsb-core needs to be split of in a separate sub-package too, so
that the "initscript and lsb_release stuff" can be installed without
dragging in any random library dependencies. With the new version you
get rid of the graphics and printing libraries, but you still get a lot
of junk.

Mattias



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Font rendering in F13

[Xose Vazquez Perez]

On Wed, Mar 3, 2010 at 11:53 PM, Matthias Clasen  wrote:

> early in the F13 cycle, we enabled the bytecode interpreter in our
> freetype package, since the patents on that have expired last fall.
> Unfortunately, it turned out that many free fonts don't actually benefit
> from this, and actually look worse with the bci. The reason for that is
> that without the bci, freetype uses its autohinter on all fonts, but
> with the bci turned on, it only applies hints to fonts which have them,
> and leaves other fonts alone.

Are Xft/Cairo patched for ClearType ? 


-- 
If less is more than more, most is more than less.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Packaging Google Font Directory for Fedora 14

[Ilyes Gouta]

Hi,

Google released a set of high quality fonts as open source and I'm
wondering of those can be packaged and included for/in the next Fedora
14. Would that be possible?

http://code.google.com/p/googlefontdirectory/

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

Re: ImageMagick update

[Hans de Goede]

Hi,

On 05/17/2010 03:13 AM, Chen Lei wrote:
>
>
> 2010/5/16 Pavel Alexeev (aka Pahan-Hubbitus)  >
>
>
> About ABI breakage there separate problem in ImageMagick -
> 
> http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg736218.html
> So, upstream is not carefully there and I never can't guarantee what
> there no ABI breakage in any update...
>
> P.S. It seams it does not hit list, i post mail again. It is reason
> such big delay...
>
> --
>
> Normally, if the update is a pure bugfix release,  it's safe to update
> and don't need a rebuild, and you should update them on rawhide as well
> as stable branches to fix bugs
> If API/ABI is changed, only the following packages need a rebuild.
> Packages depends on ImageMagick itself actually don't need a rebuild
> even the API is changed.

Wrong, the main ImageMagick provides libs too, on F-13 the full list is:
[h...@localhost anaconda]$ repoquery -q --whatrequires 
'libMagickCore.so.2()(64bit)' 'libMagickWand.so.2()(64bit)' 
'libMagick++.so.2()(64bit)'
ruby-RMagick-0:2.13.1-1.fc13.1.x86_64
ImageMagick-djvu-0:6.5.8.10-6.fc13.x86_64
vips-tools-0:7.20.7-1.fc13.x86_64
rss-glx-0:0.9.1.p-2.fc13.x86_64
q-magick-0:7.11-6.fc12.x86_64
nip2-0:7.20.7-3.fc13.x86_64
ale-0:0.9.0.3-2.fc12.x86_64
zbar-0:0.10-2.fc13.x86_64
psiconv-0:0.9.8-5.fc12.x86_64
xastir-1:1.9.6-3.fc13.x86_64
ImageMagick-c++-0:6.5.8.10-6.fc13.x86_64
ImageMagick-perl-0:6.5.8.10-6.fc13.x86_64
vips-0:7.20.7-1.fc13.x86_64
autotrace-0:0.31.1-23.fc12.x86_64
inkscape-view-0:0.47-6.fc13.x86_64
k3d-0:0.8.0.1-1.fc13.x86_64
drawtiming-0:0.7.1-1.fc13.x86_64
dx-libs-0:4.4.4-15.fc13.x86_64
dx-0:4.4.4-15.fc13.x86_64
pfstools-0:1.8.1-1.fc13.x86_64
gdl-python-0:0.9-0.10.rc4.fc13.x86_64
oxine-0:0.7.1-6.fc13.x86_64
xine-lib-extras-0:1.1.18.1-1.fc13.x86_64
transcode-0:1.1.5-4.fc13.x86_64
ImageMagick-devel-0:6.5.8.10-6.fc13.x86_64
imageinfo-0:0.05-10.fc12.x86_64
vips-python-0:7.20.7-1.fc13.x86_64
calibre-0:0.6.42-1.fc13.x86_64
pfstools-imgmagick-0:1.8.1-1.fc13.x86_64
php-pecl-imagick-0:2.2.2-4.fc12.x86_64
inkscape-0:0.47-6.fc13.x86_64
php-magickwand-0:1.0.8-4.fc12.x86_64
k3d-0:0.7.11.0-6.fc13.x86_64
gdl-0:0.9-0.10.rc4.fc13.x86_64
zbar-0:0.10-2.fc13.x86_64
transcode-0:1.1.5-4.fc13.x86_64
ImageMagick-devel-0:6.5.8.10-6.fc13.x86_64
vips-python-0:7.20.7-1.fc13.x86_64
calibre-0:0.6.42-1.fc13.x86_64
ImageMagick-c++-0:6.5.8.10-6.fc13.x86_64
vips-tools-0:7.20.7-1.fc13.x86_64
rss-glx-0:0.9.1.p-2.fc13.x86_64
vips-0:7.20.7-1.fc13.x86_64
php-magickwand-0:1.0.8-4.fc12.x86_64
oxine-0:0.7.1-6.fc13.x86_64
nip2-0:7.20.7-3.fc13.x86_64
xine-lib-extras-0:1.1.18.1-1.fc13.x86_64
php-pecl-imagick-0:2.2.2-4.fc12.x86_64
inkscape-0:0.47-6.fc13.x86_64
k3d-0:0.8.0.1-1.fc13.x86_64
ImageMagick-c++-devel-0:6.5.8.10-6.fc13.x86_64
drawtiming-0:0.7.1-1.fc13.x86_64
pfstools-imgmagick-0:1.8.1-1.fc13.x86_64
gdl-python-0:0.9-0.10.rc4.fc13.x86_64
pfstools-0:1.8.1-1.fc13.x86_64
k3d-0:0.7.11.0-6.fc13.x86_64
inkscape-view-0:0.47-6.fc13.x86_64
gdl-0:0.9-0.10.rc4.fc13.x86_64


> repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick-c++
> ImageMagick-c++-0:6.6.0.2-8.fc14.i686
> ImageMagick-c++-0:6.6.0.2-8.fc14.x86_64
> inkscape-0:0.48-0.2.20100505bzr.fc14.x86_64
> ImageMagick-c++-devel-0:6.6.0.2-8.fc14.x86_64
> gdl-0:0.9-0.12.rc4.fc14.x86_64
> pfstools-imgmagick-0:1.8.1-1.fc14.x86_64
> drawtiming-0:0.7.1-1.1.fc14.x86_64
> pfstools-0:1.8.1-1.fc14.x86_64
> ImageMagick-c++-devel-0:6.6.0.2-8.fc14.i686
> k3d-0:0.8.0.1-1.fc14.x86_64
> gdl-python-0:0.9-0.12.rc4.fc14.x86_64
> inkscape-view-0:0.48-0.2.20100505bzr.fc14.x86_64
> BTW, some subpackages contain .la files, you should remove them in %install.
> e.g.

This is not necessarily good advice either:
1) As these la files are for plugins which are located outside of %{_libdir},
they do no harm
2) In the past there have been cases with plugins where the libraries plugins
loading mechanism relies on the .la files being present, that might very well
be the case here.

Regards,

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

Re: Packaging Google Font Directory for Fedora 14

[Horst H. von Brand]

Ilyes Gouta  wrote:

> Hi,
> 
> Google released a set of high quality fonts as open source and I'm
> wondering of those can be packaged and included for/in the next Fedora
> 14. Would that be possible?
> 
> http://code.google.com/p/googlefontdirectory/

You should look at , where the Fedora font
buffs hang out.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 234   Fax:  +56 32 2797513

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

rawhide report: 20100522 changes

[Rawhide Report]

Compose started at Sat May 22 08:15:37 UTC 2010

Broken deps for i386
--
SolarModel-2.1-7.fc14.i686 requires libIrrlicht.so.1.6
almanah-0.7.2-1.fc13.i686 requires libedataserver-1.2.so.11
almanah-0.7.2-1.fc13.i686 requires libedataserverui-1.2.so.8
anjal-0.3.2-2.fc14.i686 requires libedataserver-1.2.so.11
anjal-0.3.2-2.fc14.i686 requires libcamel-1.2.so.14
anjal-0.3.2-2.fc14.i686 requires libcamel-provider-1.2.so.14
anjal-0.3.2-2.fc14.i686 requires libedataserverui-1.2.so.8
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
clutter-gtkmm-0.9.4-3.fc12.i686 requires libcluttermm-0.9.so.3
clutter-gtkmm-devel-0.9.4-3.fc12.i686 requires pkgconfig(cluttermm-0.9)
dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11
evolution-couchdb-0.3.2-2.fc13.i686 requires libcamel-provider-1.2.so.14
evolution-couchdb-0.3.2-2.fc13.i686 requires libcamel-1.2.so.14
evolution-couchdb-0.3.2-2.fc13.i686 requires libedataserver-1.2.so.11
evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1
glabels-2.2.7-1.fc14.i686 requires libedataserver-1.2.so.11
gnome-launch-box-0.4-17.fc13.i686 requires libedataserver-1.2.so.11
gnome-phone-manager-0.65-5.fc12.i686 requires libedataserver-1.2.so.11
gnome-phone-manager-telepathy-0.65-5.fc12.i686 requires 
libedataserver-1.2.so.11
kobby-1.0-0.3.b4.fc13.i686 requires libinfinity-0.3.so.0
kobby-1.0-0.3.b4.fc13.i686 requires libinftext-0.3.so.0
libqinfinity-1.0-0.2.b4.fc13.i686 requires libinfinity-0.3.so.0
libqinfinity-1.0-0.2.b4.fc13.i686 requires libinftext-0.3.so.0

plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch 
requires jakarta-commons-logging-javadoc
qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18
rubygem-right_aws-1.10.0-3.fc14.noarch requires 
rubygem(right-http_connection) >= 0:1.2.4
sepostgresql-8.4.3-2582.fc14.i686 requires postgresql-server = 0:8.4.3
vfrnav-0.4-1.fc13.i686 requires libgps.so.18
vifir-0.4-2.fc14.i686 requires libgps.so.18
viking-0.9.91-3.fc13.i686 requires libgps.so.18



Broken deps for x86_64
--
SolarModel-2.1-7.fc14.x86_64 requires libIrrlicht.so.1.6()(64bit)
almanah-0.7.2-1.fc13.x86_64 requires libedataserverui-1.2.so.8()(64bit)
almanah-0.7.2-1.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit)
anjal-0.3.2-2.fc14.x86_64 requires libcamel-provider-1.2.so.14()(64bit)
anjal-0.3.2-2.fc14.x86_64 requires libedataserverui-1.2.so.8()(64bit)
anjal-0.3.2-2.fc14.x86_64 requires libcamel-1.2.so.14()(64bit)
anjal-0.3.2-2.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit)
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit)
clutter-gtkmm-0.9.4-3.fc12.i686 requires libcluttermm-0.9.so.3
clutter-gtkmm-0.9.4-3.fc12.x86_64 requires 
libcluttermm-0.9.so.3()(64bit)
clutter-gtkmm-devel-0.9.4-3.fc12.i686 requires pkgconfig(cluttermm-0.9)
clutter-gtkmm-devel-0.9.4-3.fc12.x86_64 requires 
pkgconfig(cluttermm-0.9)
dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit)
evolution-couchdb-0.3.2-2.fc13.x86_64 requires 
libcamel-provider-1.2.so.14()(64bit)
evolution-couchdb-0.3.2-2.fc13.x86_64 requires 
libcouchdb-glib-1.0.so.1()(64bit)
evolution-couchdb-0.3.2-2.fc13.x86_64 requires 
libcamel-1.2.so.14()(64bit)
evolution-couchdb-0.3.2-2.fc13.x86_64 requires 
libedataserver-1.2.so.11()(64bit)
glabels-2.2.7-1.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit)
gnome-launch-box-0.4-17.fc13.x86_64 requires 
libedataserver-1.2.so.11()(64bit)
gnome-phone-manager-0.65-5.fc12.x86_64 requires 
libedataserver-1.2.so.11()(64bit)
gnome-phone-manager-telepathy-0.65-5.fc12.x86_64 requires 
libedataserver-1.2.so.11()(64bit)
kobby-1.0-0.3.b4.fc13.x86_64 requires libinfinity-0.3.so.0()(64bit)
kobby-1.0-0.3.b4.fc13.x86_64 requires libinftext-0.3.so.0()(64bit)
libqinfinity-1.0-0.2.b4.fc13.i686 requires libinfinity-0.3.so.0
libqinfinity-1.0-0.2.b4.fc13.i686 requires libinftext-0.3.so.0
libqinfinity-1.0-0.2.b4.fc13.x86_64 requires 
libinfinity-0.3.so.0()(64bit)
libqinfinity-1.0-0.2.b4.fc13.x86_64 requires 
libinftext-0.3.so.0()(64bit)

plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch 
requires jakarta-commons-logging-javadoc
qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
rubygem-right_aws-1.10.0-3.fc14.noarch requires 
rubygem(right-http_connection) >= 0:1.2.4
sepostgresql-8.4.3-2582.fc14.x86_64 requires postgresql-server = 0:8.4.3

Re: Features in new releases / updates

[Thorsten Leemhuis]

On 22.05.2010 11:59, Matt McCutchen wrote:
> On Sat, 2010-05-22 at 10:14 +0200, Thorsten Leemhuis wrote:
>> On 20.05.2010 18:42, Jesse Keating wrote:
>>> On Thu, 2010-05-20 at 14:25 +0100, Bastien Nocera wrote:
 I'd expect most of the support to end up in F13 updates, so I'm not
 sure a feature page really makes sense. 
>>> This happens with a lot of our features anyway, [...]
>> And that imho is quite bad for everyone involved, as it kind of makes
>> everyone unhappy afaics.
>> To explain: [...]
> [...]
> Without addressing other reasons, I think keeping the situation simple
> for journalists is a pretty weak reason not to add a feature to an
> existing release via updates.

I didn't meant to imply this anywhere (in fact I think updates like that
are a really good thing and one things that makes Fedora better than
other distributions for me). I just wanted to express that it has
downsides to have a feature page for something that is not new at all.

CU
knurd

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

Re: ImageMagick update

[Chen Lei]

2010/5/22 Hans de Goede 

> Hi,
>
> On 05/17/2010 03:13 AM, Chen Lei wrote:
> >
> > repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick-c++
> > ImageMagick-c++-0:6.6.0.2-8.fc14.i686
> > ImageMagick-c++-0:6.6.0.2-8.fc14.x86_64
> > inkscape-0:0.48-0.2.20100505bzr.fc14.x86_64
> > ImageMagick-c++-devel-0:6.6.0.2-8.fc14.x86_64
> > gdl-0:0.9-0.12.rc4.fc14.x86_64
> > pfstools-imgmagick-0:1.8.1-1.fc14.x86_64
> > drawtiming-0:0.7.1-1.1.fc14.x86_64
> > pfstools-0:1.8.1-1.fc14.x86_64
> > ImageMagick-c++-devel-0:6.6.0.2-8.fc14.i686
> > k3d-0:0.8.0.1-1.fc14.x86_64
> > gdl-python-0:0.9-0.12.rc4.fc14.x86_64
> > inkscape-view-0:0.48-0.2.20100505bzr.fc14.x86_64
> > BTW, some subpackages contain .la files, you should remove them in
> %install.
> > e.g.
>
> This is not necessarily good advice either:
> 1) As these la files are for plugins which are located outside of
> %{_libdir},
> they do no harm
> 2) In the past there have been cases with plugins where the libraries
> plugins
> loading mechanism relies on the .la files being present, that might very
> well
> be the case here.
>
>
.
This is actually my fault:)  . ImageMagick strangely relies on those .la
files to load modules. Containing .la files in packages will pull in libtool
as dependency, can we filter it out?

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

Re: rawhide report: 20100517 changes

[Chen Lei]

2010/5/22 Mattias Ellert 

> fre 2010-05-21 klockan 19:55 -0500 skrev Matt Domsch:
> > On Fri, May 21, 2010 at 08:40:12AM +0100, Richard W.M. Jones wrote:
> > > On Fri, May 21, 2010 at 07:44:48AM +0200, Kevin Kofler wrote:
> > > > Rawhide Report wrote:
> > > > > mumble-1.2.2-8.fc14
> > > > > ---
> > > > > * Sun May 16 2010 Andreas Osowski  - 1.2.2-8
> > > > > - Rebuild for protobuf ABI change
> > > > > - Added redhat-lsb to the Requires for murmur
> > > >
> > > > As already noted by Rahul Sundaram when this change was made in CVS,
> redhat-
> > > > lsb is NOT a valid dependency for a Fedora package,[...]
> > >
> > > What happens if we want to run the /usr/bin/lsb_release command?
> > >
> > > I needed that the other day, but when I saw the lsb_release is in
> > > redhat-lsb which requires a vast number of libraries, I found an
> > > alternate method.
> >
> > Look in rawhide now.   The redhat-lsb SRPM has been split into
> > multiple subpackages, including -graphics and -printing exactly so
> > that you can Require: lsb   to get the initscript and lsb_release
> > stuff, without also pulling in all the graphics and printing
> > libraries.
>
> This is a step in the right direction, but it is only half way. To be
> useful lsb-core needs to be split of in a separate sub-package too, so
> that the "initscript and lsb_release stuff" can be installed without
> dragging in any random library dependencies. With the new version you
> get rid of the graphics and printing libraries, but you still get a lot
> of junk.
>
>Mattias



I'd rather like to suggest of forbidden using of initscript in redhat-lsb
for fedora packages. Despite of the depencencies issue, we can easily switch
from /etc/rc.d/init.d/functions to  /lib/lsb/init-functions and historically
/usr/lib/lsb/install_initd and /usr/lib/lsb/remove_initd is completely
broken for several time( See bugzilla). I cann't see any advantages of using
initscript in redhat-lsb instead of initsripts package.

But I'm also like to see splitting redhat-lsb into several subpackages,
it'll benefit a lot to some third-party packages/softwares which require
redhat-lsb. It's unacceptable to pull in some graphic libs for servers when
installing redhat-lsb  .

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

Re: Packages depending on Yelp

[Kevin Kofler]

Patrice Dumas wrote:
> I may not be the most qualified to answer that, but it seems to me
> that the manuals are more or less docbook manuals, omf files are just
> metadata for the manuals. So there may be some manuals distributed that
> way that are not associated with a button in an interface. In that case
> the -doc package may be optional, and there should be no yelp dependency.
> I recall that it was the case for gnash for some time. At least some of
> the manuals weren't associated with the user interface.

FYI, the Gnash manual doesn't build at all at the moment and hasn't for a 
while. You disabled it at some point, I tried reenabling it, it still 
failed, so it's still disabled. And the UI has never offered it.

Kevin Kofler

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

Re: rawhide report: 20100517 changes

[Kevin Kofler]

Chen Lei wrote:
> I'd rather like to suggest of forbidden using of initscript in redhat-lsb
> for fedora packages. Despite of the depencencies issue, we can easily
> switch from /etc/rc.d/init.d/functions to  /lib/lsb/init-functions and
> historically /usr/lib/lsb/install_initd and /usr/lib/lsb/remove_initd is
> completely broken for several time( See bugzilla). I cann't see any
> advantages of using initscript in redhat-lsb instead of initsripts
> package.

+1

Kevin Kofler

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

Re: moderated/held messages on mailing lists

[Kevin Kofler]

Richard W.M. Jones wrote:
> So the problem is not length of time, but number of messages in a
> directory.  Why is the limit not set on number of messages, rather
> than time?  Is there one directory for the whole of the Fedora mail
> system, or one directory per mailing list?  Can individual mailing
> lists opt for longer timeouts?

If your moderation delay is longer than a month, it's probably not worth 
moderating the message through anymore at that point. I think most people 
will expect moderation (i.e. acceptance/rejection) to happen within a week 
at the most.

Kevin Kofler

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

Re: rawhide report: 20100517 changes

[Kevin Kofler]

Richard W.M. Jones wrote:
> Unfortunately I couldn't find a really good way to differentiate
> between Debian from Ubuntu without using 'lsb_release -i'.

/etc/issue contains that information. It says something like:
Ubuntu 9.04 \n \l
(blank line)

By the way, that also works on Fedora, my /etc/issue says:
Fedora release 12 (Constantine)
Kernel \r on an \m (\l)
(blank line)
The first line is the same as the contents of /etc/redhat-release.

Kevin Kofler

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

libjpeg for F14

[Xose Vazquez Perez]

hi there,

Can it be updated to upstream version in rawhide ?

The libjpeg version(6b) in Fedora is quite old(27-Mar-1998).
And newer versions were released on:

Version 7   27-Jun-2009
Version 8   10-Jan-2010
Version 8a  28-Feb-2010
Version 8b  16-May-2010



libpng also needs some care, 1.4 tree was releasd on jan-2010:
http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt
http://www.libpng.org/pub/png/src/libpng-1.4.1-README.txt
http://www.libpng.org/pub/png/src/libpng-1.4.2-README.txt


But, the maintainer of the packages is not very receptive.

-thanks-

-- 
If less is more than more, most is more than less.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging Google Font Directory for Fedora 14

[Kevin Kofler]

Ilyes Gouta wrote:
> Google released a set of high quality fonts as open source and I'm
> wondering of those can be packaged and included for/in the next Fedora
> 14. Would that be possible?
> 
> http://code.google.com/p/googlefontdirectory/

Not all of those fonts were actually released by Google, most of them are 
just copied from somewhere else (which the Free Font licenses being used 
allow, of course). The Droid fonts were designed by Ascender Corp. under 
contract from Google, but as far as I know, most or all of the remaining 
ones don't originally come from Google.

Several of those fonts are already packaged in Fedora: I recognized at least 
the Droid fonts, Inconsolata, Vollkorn and Yanone Kaffeesatz. It would be 
nice and useful to have the remaining ones packaged as well.

Kevin Kofler

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

Re: rawhide report: 20100517 changes

[Till Maas]

On Sat, May 22, 2010 at 05:40:45PM +0200, Kevin Kofler wrote:
> Richard W.M. Jones wrote:
> > Unfortunately I couldn't find a really good way to differentiate
> > between Debian from Ubuntu without using 'lsb_release -i'.
> 
> /etc/issue contains that information. It says something like:
> Ubuntu 9.04 \n \l
> (blank line)
> 
> By the way, that also works on Fedora, my /etc/issue says:
> Fedora release 12 (Constantine)
> Kernel \r on an \m (\l)
> (blank line)
> The first line is the same as the contents of /etc/redhat-release.

This is not something one can rely on, because it is perfectly valid to
change these files.

Regards
Till


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

tmpfs for strategic directories

[Xose Vazquez Perez]

Is it worth using tmpfs for some directories(/var/run, lock...) ?

This is ubuntu /proc/mounts:

rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /dev devtmpfs rw,relatime,size=4092312k,nr_inodes=1023078,mode=755 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/disk/by-uuid/---- / ext4 
rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
none /var/run tmpfs rw,nosuid,relatime,mode=755 0 0
none /var/lock tmpfs rw,nosuid,nodev,noexec,relatime 0 0
none /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc 
rw,nosuid,nodev,noexec,relatime 0 0
gvfs-fuse-daemon /home/xuser/.gvfs fuse.gvfs-fuse-daemon 
rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

-- 
If less is more than more, most is more than less.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: tmpfs for strategic directories

[Lennart Poettering]

On Sat, 22.05.10 18:30, Xose Vazquez Perez (xose.vazq...@gmail.com) wrote:

> 
> Is it worth using tmpfs for some directories(/var/run, lock...) ?

Yes. But this requires some changes all across the distro, just have a
look at the output of "rpm -qf /var/run/*".

That said most apps are fixed by now and don't choke when their subdir
in /var/run goes away on reboot, since both SUSE and Ubuntu are using
tmpfs on /var/run, and have done most of the work. So at this point this
should be mostly packaging work (%ghost in .spec files!), not
programming work to make /var/run compatible with tmpfs.

(And as a side note: systemd by default puts a tmpfs to both /var/run
and /var/lock).

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: tmpfs for strategic directories

[Rahul Sundaram]

On 05/23/2010 02:36 AM, Lennart Poettering wrote:
>
> (And as a side note: systemd by default puts a tmpfs to both /var/run
> and /var/lock).
>   

So do you plan on getting it by default for Fedora 14?   :-)

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

Re: tmpfs for strategic directories

[Ilyes Gouta]

I'd love to play with it. Is systemd stable enough to try it on Fedora 13?

-Ilyes Gouta

On Sat, May 22, 2010 at 10:10 PM, Rahul Sundaram  wrote:
> On 05/23/2010 02:36 AM, Lennart Poettering wrote:
>>
>> (And as a side note: systemd by default puts a tmpfs to both /var/run
>> and /var/lock).
>>
>
> So do you plan on getting it by default for Fedora 14?   :-)
>
> Rahul
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

undefined reference to symbol 'SHA256_Init'

[Uwe Kubosch]

Hi all!

I am having trouble building zfs-fuse for F-13 and devel:

/usr/bin/ld: lib/libzfs/libzfs.a(libzfs_sendrecv.o): undefined reference to 
symbol 'SHA256_Init'
/usr/bin/ld: note: 'SHA256_Init' is defined in DSO /usr/lib64/libcrypto.so.10 
so try adding it to the linker command line
/usr/lib64/libcrypto.so.10: could not read symbols: Invalid operation

I have openssl-devel as a build dependency, but something has changed in F-13 
and devel to break the build.

Please, please, please help me fix this build.

--
With kind regards
Uwe Kubosch
Kubosch Consulting
u...@kubosch.no
http://kubosch.no/





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

Re: undefined reference to symbol 'SHA256_Init'

[Rahul Sundaram]

On 05/23/2010 03:04 AM, Uwe Kubosch wrote:
> Hi all!
>
> I am having trouble building zfs-fuse for F-13 and devel:
>   
> /usr/bin/ld: lib/libzfs/libzfs.a(libzfs_sendrecv.o): undefined reference to 
> symbol 'SHA256_Init'
> /usr/bin/ld: note: 'SHA256_Init' is defined in DSO /usr/lib64/libcrypto.so.10 
> so try adding it to the linker command line
> /usr/lib64/libcrypto.so.10: could not read symbols: Invalid operation
>   
>
> I have openssl-devel as a build dependency, but something has changed
> in F-13 and devel to break the build.
>

Refer to

http://fedoraproject.org/wiki/UnderstandingDSOLinkChange

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

Re: libjpeg for F14

[Bruno Wolff III]

On Sat, May 22, 2010 at 17:55:39 +0200,
  Xose Vazquez Perez  wrote:
> hi there,
> 
> Can it be updated to upstream version in rawhide ?

Normally you want to file an RFE bug against the package. That way the request
doesn't get lost. (It still might not get done right away.)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: NVR email I just sent

[Christopher Brown]

On 19 May 2010 18:01, Mike McGrath  wrote:
> Hello all, I just sent an email to several of you with the F12->F13
> updates list.  I included f13-updates-testing but forgot f13-updates so
> some of those in the list were false positives.   Below is an updated
> list.  Sorry about that.

> greater for f12: jokosher (snecker)
>  f12 = jokosher-1.0-0.12.20100503bzr.fc12.src
>  f13 = jokosher-1.0-0.11.20100503bzr.fc13.src

> greater for f12: log4net (snecker)
>  f12 = log4net-1.2.10-12.fc12.src
>  f13 = log4net-1.2.10-10.fc13.src

Done. Thanks for the heads-up.

Regards

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

systemd (Was Re: tmpfs for strategic directories)

[Lennart Poettering]

On Sun, 23.05.10 02:40, Rahul Sundaram (methe...@gmail.com) wrote:

> 
> On 05/23/2010 02:36 AM, Lennart Poettering wrote:
> >
> > (And as a side note: systemd by default puts a tmpfs to both /var/run
> > and /var/lock).
> >   
> 
> So do you plan on getting it by default for Fedora 14?   :-)

Well, I am certainly planning to have a package for it in F14. But
whether we can have it as default is to be seen. 

ATM everything looks rosy. I just finished porting over all F13
installed-by-default daemons to socket activation, and a few more (and
the patches are good enough to be upstreamable). I'll publish the
numbers of a 100% socket-activated boot soon. Codewise only very little
is missing to be fully ready for Fedora (in fact selinux support is the
only item really mattering on my todo list).

So far response from the community has been very positive, but we didn't
have a fedora-devel discussion about this yet, so we'll have to see
whether we can somehow make the broader community as enthusiastic about
the whole idea as I am. ;-)

(some of the systemd-related work in other projects already hit rawhide
btw, e.g. in udev)

A little bit down the road I'll make my mind up whether I plan to
suggest as a default for F14, and then propose that on
fedora-devel and FESCO. Stay tuned.

It would certainly be a shame though if other distros would ship systemd
by default before we do.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd (Was Re: tmpfs for strategic directories)

[Rahul Sundaram]

On 05/23/2010 04:04 AM, Lennart Poettering wrote:
>
> ATM everything looks rosy. I just finished porting over all F13
> installed-by-default daemons to socket activation, and a few more (and
> the patches are good enough to be upstreamable). I'll publish the
> numbers of a 100% socket-activated boot soon. Codewise only very little
> is missing to be fully ready for Fedora (in fact selinux support is the
> only item really mattering on my todo list).
>   

It would great to have a repo or something to try it out quickly and
provide some feedback.

Rahul

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

Re: tmpfs for strategic directories

[Lennart Poettering]

On Sat, 22.05.10 22:11, Ilyes Gouta (ilyes.go...@gmail.com) wrote:

> 
> I'd love to play with it. Is systemd stable enough to try it on Fedora 13?

Well, I guess you should really know what you do if you try that. 

That said, if you steal the libcgroup and udev version from rawhide
(which is unproblematic, as they have no further dependencies) you
should be able to compile systemd on F13 just fine. "make install"
should then set up everything for you so that you can boot with systemd
simply by passing "init=/usr/local/bin/systemd" on the kernel command
line. The glue file tarball mentioned on the blog story is not necessary
anymore.

However, if you try this you won't see too many changes from the normal
F13, simply because the whole system is booted up with the same shell
scripts as always, though we start the services a little bit more in
parallel and everything is neatly sorted into its own cgroup below
/cgroup/systemd and supervised by systemd.

The necessary changes to make the system boot up fully parallelized
using socket/bus based activation the way I explained on my blog story
currently exist only ony own harddisk. I'll publish them soonishly. But
since this involves patches to various packages (10 or so) this won't be
trivial to setup.

All that said, I do run my normal machines on systemd these days. And it
is fun and works well. 

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd (Was Re: tmpfs for strategic directories)

[Lennart Poettering]

On Sun, 23.05.10 04:10, Rahul Sundaram (methe...@gmail.com) wrote:

> 
> On 05/23/2010 04:04 AM, Lennart Poettering wrote:
> >
> > ATM everything looks rosy. I just finished porting over all F13
> > installed-by-default daemons to socket activation, and a few more (and
> > the patches are good enough to be upstreamable). I'll publish the
> > numbers of a 100% socket-activated boot soon. Codewise only very little
> > is missing to be fully ready for Fedora (in fact selinux support is the
> > only item really mattering on my todo list).
> >   
> 
> It would great to have a repo or something to try it out quickly and
> provide some feedback.

hughsie prepped some packages for systemd, but I cannot really tell you
right now where they are available.

Richard?

And I am not sure if my own yum-fu is good enough to provide you with a repo
which you can just install everything from, including the patched
daemons...

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: undefined reference to symbol 'SHA256_Init'

[Uwe Kubosch]

Thank you for your reply.  I was able to fix the immediate error by linking 
with libcrypto as suggested.

Now I get

gcc -o cmd/zdb/zdb -pipe -Wall -s cmd/zdb/zdb.o cmd/zdb/zdb_il.o 
cmd/zdb/ptrace.o lib/libavl/libavl.a lib/libnvpair/libnvpair-user.a 
lib/libumem/libumem.a lib/libzfs/libzfs.a lib/libzpool/libzpool-user.a 
lib/libzfscommon/libzfscommon-user.a lib/libuutil/libuutil.a 
lib/libsolcompat/libsolcompat.a -lrt -lpthread -ldl -lz -lm -laio -lssl -lcrypto
lib/libzfs/libzfs.a(libzfs_pool.o): In function `zpool_valid_proplist':
libzfs_pool.c:(.text+0x3355): undefined reference to `S_ISDIR'

This time there is no suggestion for what to link to.  Do you have a suggestion?


On May 22, 2010, at 11:37 PM, Rahul Sundaram wrote:

> On 05/23/2010 03:04 AM, Uwe Kubosch wrote:
>> Hi all!
>> 
>> I am having trouble building zfs-fuse for F-13 and devel:
>> 
>> /usr/bin/ld: lib/libzfs/libzfs.a(libzfs_sendrecv.o): undefined reference to 
>> symbol 'SHA256_Init'
>> /usr/bin/ld: note: 'SHA256_Init' is defined in DSO 
>> /usr/lib64/libcrypto.so.10 so try adding it to the linker command line
>> /usr/lib64/libcrypto.so.10: could not read symbols: Invalid operation
>> 
>> 
>> I have openssl-devel as a build dependency, but something has changed
>> in F-13 and devel to break the build.
>> 
> 
> Refer to
> 
> http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
> 
> Rahul

--
With kind regards
Uwe Kubosch
Kubosch Consulting
u...@kubosch.no
http://kubosch.no/





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

Re: systemd (Was Re: tmpfs for strategic directories)

[Ilyes Gouta]

Hey Lennart,

So how fast is a systemd boot (with all the changes to the scripts)
compared to the current F13 setup? How about a ratio?

-Ilyes Gouta

On Sat, May 22, 2010 at 11:40 PM, Rahul Sundaram  wrote:
> On 05/23/2010 04:04 AM, Lennart Poettering wrote:
>>
>> ATM everything looks rosy. I just finished porting over all F13
>> installed-by-default daemons to socket activation, and a few more (and
>> the patches are good enough to be upstreamable). I'll publish the
>> numbers of a 100% socket-activated boot soon. Codewise only very little
>> is missing to be fully ready for Fedora (in fact selinux support is the
>> only item really mattering on my todo list).
>>
>
> It would great to have a repo or something to try it out quickly and
> provide some feedback.
>
> Rahul
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: undefined reference to symbol 'SHA256_Init'

[Uwe Kubosch]

Never mind.  Missing #include 

On May 23, 2010, at 12:58 AM, Uwe Kubosch wrote:

> Thank you for your reply.  I was able to fix the immediate error by linking 
> with libcrypto as suggested.
> 
> Now I get
> 
> gcc -o cmd/zdb/zdb -pipe -Wall -s cmd/zdb/zdb.o cmd/zdb/zdb_il.o 
> cmd/zdb/ptrace.o lib/libavl/libavl.a lib/libnvpair/libnvpair-user.a 
> lib/libumem/libumem.a lib/libzfs/libzfs.a lib/libzpool/libzpool-user.a 
> lib/libzfscommon/libzfscommon-user.a lib/libuutil/libuutil.a 
> lib/libsolcompat/libsolcompat.a -lrt -lpthread -ldl -lz -lm -laio -lssl 
> -lcrypto
> lib/libzfs/libzfs.a(libzfs_pool.o): In function `zpool_valid_proplist':
> libzfs_pool.c:(.text+0x3355): undefined reference to `S_ISDIR'
> 
> This time there is no suggestion for what to link to.  Do you have a 
> suggestion?
> 
> 
> On May 22, 2010, at 11:37 PM, Rahul Sundaram wrote:
> 
>> On 05/23/2010 03:04 AM, Uwe Kubosch wrote:
>>> Hi all!
>>> 
>>> I am having trouble building zfs-fuse for F-13 and devel:
>>> 
>>> /usr/bin/ld: lib/libzfs/libzfs.a(libzfs_sendrecv.o): undefined reference to 
>>> symbol 'SHA256_Init'
>>> /usr/bin/ld: note: 'SHA256_Init' is defined in DSO 
>>> /usr/lib64/libcrypto.so.10 so try adding it to the linker command line
>>> /usr/lib64/libcrypto.so.10: could not read symbols: Invalid operation
>>> 
>>> 
>>> I have openssl-devel as a build dependency, but something has changed
>>> in F-13 and devel to break the build.
>>> 
>> 
>> Refer to
>> 
>> http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
>> 
>> Rahul
> 
> --
> With kind regards
> Uwe Kubosch
> Kubosch Consulting
> u...@kubosch.no
> http://kubosch.no/
> 
> 
> 
> 
> 
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

--
With kind regards
Uwe Kubosch
Kubosch Consulting
u...@kubosch.no
http://kubosch.no/





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

Re: systemd (Was Re: tmpfs for strategic directories)

[Lennart Poettering]

On Sun, 23.05.10 00:04, Ilyes Gouta (ilyes.go...@gmail.com) wrote:

Heya,

> So how fast is a systemd boot (with all the changes to the scripts)
> compared to the current F13 setup? How about a ratio?

Please be patient. To quote myself: "I'll publish the numbers of a 100%
socket-activated boot soon."

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libjpeg for F14

[Tom Lane]

Xose Vazquez Perez  writes:
> Can it be updated to upstream version in rawhide ?

I've been told (though this may well be inaccurate) that the LSB
requires libjpeg 6b.  If so, that would pose a problem for adopting
the non-ABI-compatible version 8.  In any case I'm not eager to force
a recompile of everything that depends on it ...

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd (Was Re: tmpfs for strategic directories)

[Richard Hughes]

On 22 May 2010 23:51, Lennart Poettering  wrote:
> hughsie prepped some packages for systemd, but I cannot really tell you
> right now where they are available.

systemd package available here: http://people.freedesktop.org/~hughsient/fedora/

The patched daemons are not available yet, so it doesn't yet work very
well. Caveat emptor.

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

Re: libjpeg for F14

[Toshio Kuratomi]

On Sat, May 22, 2010 at 10:23:05PM -0400, Tom Lane wrote:
> Xose Vazquez Perez  writes:
> > Can it be updated to upstream version in rawhide ?
> 
> I've been told (though this may well be inaccurate) that the LSB
> requires libjpeg 6b.  If so, that would pose a problem for adopting
> the non-ABI-compatible version 8.
>
We don't seem to have any policy, guidelines, or even any mailing list
discussions that I can recall that tell us to what extent LSB compliance is
something we have to watch out for in Fedora.  Perhaps we need to have that
discussion and then decide whether we need to parallel install 8b or not.

> In any case I'm not eager to force
> a recompile of everything that depends on it ...
> 
This is not at all a blocker criteria for rawhide at the beginning of the
release cycle We do practically whole distro rebuilds for gcc updates;
doing a rebuild for things that depend on libjpeg is not a big deal compared
to that.

-Toshio


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

Re: libjpeg for F14

[Toshio Kuratomi]

On Sat, May 22, 2010 at 10:23:05PM -0400, Tom Lane wrote:
> Xose Vazquez Perez  writes:
> > Can it be updated to upstream version in rawhide ?
> 
> I've been told (though this may well be inaccurate) that the LSB
> requires libjpeg 6b.  If so, that would pose a problem for adopting
> the non-ABI-compatible version 8.  In any case I'm not eager to force
> a recompile of everything that depends on it ...
>
Regarding the possibility of parallel installing, I just did a test compile
of jpeg-8b; Looks like it creates a library with SONAME of libjpeg.so.8 and
our current libjpeg which has libjpeg.so.62

-Toshio


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