Re: web-m and Fedora 14

[viragh]

The glyph coverage of those fonts is rather incomplete.
With the standard Hungarian encodings (either iso8859-2 or utf8) they are near 
to useless, unfortunately.

J. Virágh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libjpeg for F14

[Chris Jones]

Right, so they're still using libpng* but the more updated version. I read
the original post as not using libpng at all and using another library as an
alternative. Sorry, my misunderstanding.



-- 
Chris Jones
Photographic Imaging Professional and Graphic Designer
ABN: 98 317 740 240

Photo Resolutions - Photo Printing, Editing and Restorations
Web: http://photoresolutions.freehostia.com
Email: 


pub 2048R/8C088061 5/25/2010 Chris Jones 
Primary key fingerprint:  FAC6 F8E8 868C 8DAB 9DEA 7602 8252 65AD 8C08
8061

-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.10 (MingW32) - WinPT 1.4.3
Charset: UTF-8
Comment: Gnu Privacy Tools
Comment: Download at http://www.gnupt.de

mQENBEv7YxMBCADIYm1hzSAgJkzTfs0jvPNMdM23M5qCwgylKE6uCW7iTMke7vhM
lO1+2dMFBxplGHq33QRC0qyercYGtACUSb8BYOtHXZaYfM8E20HJHvXaWWFQBk3S
HGbUnzNO3NzU4pDGJoi5eBH4MkD5FEpkMe1s0Dw9UoWdkQRvMUYhBzGpXxUFz/W8
0uPkfZdeziYlZZ8lUxcw95GfqBbRKLoKYrP/jCBH9BeFNgixpeIiHYt8rHoEg9T1
N9tajw8aRJGJdIgZ6DNirDkFOpYWtSjj0dlDnMy9uPOcrdHlPDjZ0Sw4FrGyb9TR
KoeIpxk3vOlS6nP4HsWjagP0oZzqvdDf9UC1ABEBAAG0JkNocmlzIEpvbmVzIDxj
aHJpc2pvbmVzQGNvbWNlbi5jb20uYXU+iQE4BBMBAgAiBQJL+2MTAhsDBgsJCAcD
AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCCUmWtjAiAYcmtB/4wpRgf6SZ8H0uFEpIs
x6kxLEsTKzNcW4JNJVPLrSFzTQkslhn6gu+3NVS9qG0whpBVh/eThPVK/zBRzNvw
f5EfI09EKEeGJ9nnTWnVhDDJYnHFXC+w3dgDKv5C5VN1ARGiw8Eot7mgfSv5gcso
VwqA4/Jx3q34sLn7z5AMHa9TamlpffzQma+HqCjn37aaZcx1AGsLlCDVENJcyVKi
+lk8qWvB/1DhEVpSFFlrEouMxvUUWZp9kyT4sXcIuxMUpvPYzM5l7iYxqk6KhC0V
hhnfzDr/exOfLgVhkIzIY8ZR1zeErkQq4seLFJC/ZdpoD1L1acMJoMzwu+1HjmUv
VwtfuQENBEv7YxMBCADajxmRiD2en8fSD5dqa4MwjtNmSKOfzNY2a+a9+Y5VPPYM
irT5c78p6CPLQvgrfgTuPzENk+dsxiIQjyJCOATrrueIFExmBNon9sEEyVzHk9GU
DxdW6eAak5Nlr8qQwc7EpS+KiEwap/TJu/PgIYDg2rGpDGVmZnK5bAG4An2AJJ+n
8i9J/773pQs3iK3HZyjPqAb9Oy03gILRsUydTaj0wXc/5ELgV7UhBay9pc5tOoVV
39Ko9km3VsxeTfcMHcOc46n70tFzyOI/ntsG8GuIAuKAFcn1x8Kdst7no3VrozDT
uPMR+IxJeZ9JKGCz+U0zphecyCi59Ve/Ur77LDKrABEBAAGJAR8EGAECAAkFAkv7
YxMCGwwACgkQglJlrYwIgGF5Tgf/S/5pob7MROT8Q6wVQ3i939eiFUeoHYwO/5Et
DoJIKfXKJW0UHf/HMQt7OhXZSWJWhPX+S2dEPDuIr0QvmGUtRpiuziP8VFdxb6wD
iPm+InsSSSkSZwM+HzK504lXRr4oJgyuw5X/v3+LtfSL9aKHspP81/axP7q0fGiH
WTTuJmzylfBMrBeZD44E8+LFHcDJ7fBxlxXMKH6gdx3rF6AH2ejz1miW6ETbZiba
O5IDcCSuTiMmuqsiNblDp7p6F69tAykbkk5XWwJ/JLxpjOnqgMUBNNgPM2b5JLg2
EjsErAnezLn3XHqLZfCCkVhlKnQeMRmWaiQEJC7lso4rd3VA8w==
=ggBQ
-END PGP PUBLIC KEY BLOCK-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Headsup: ABI changing libebml bump coming to rawhide

[Hans de Goede]

Hi All,

A new libebml version is coming to a rawhide near you. This
version does not change the soname, yet the C++ ABI
is still changing 

So all packages using libebml will need to be rebuild:
[h...@localhost ~]$ sudo repoquery -q --whatrequires --alldeps libebml
libebml-0:0.7.8-3.fc12.x86_64
libebml-0:0.7.8-3.fc12.i686
libmatroska-0:0.8.1-5.fc12.i686
mkvtoolnix-0:3.3.0-1.fc13.x86_64
libmatroska-0:0.8.1-5.fc12.x86_64
vlc-core-0:1.0.6-1.fc13.i686
libebml-devel-0:0.7.8-3.fc12.x86_64
mkvtoolnix-gui-0:3.3.0-1.fc13.x86_64
vlc-core-0:1.0.6-1.fc13.x86_64
libebml-devel-0:0.7.8-3.fc12.i686

So summarizing:
libmatroska
mkvtoolnix
vlc-core

Need to be rebuild.

Regards,

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

Re: libjpeg for F14

[Alexander Larsson]

On Mon, 2010-05-24 at 13:24 +0100, Richard W.M. Jones wrote:
> On Sat, May 22, 2010 at 05:55:39PM +0200, Xose Vazquez Perez wrote:
> > 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
> > 
> 
> libjpeg has an odd upstream.  We needed some build fixes to be
> included for the Windows cross-compiler, but found the current
> upstream to be unresponsive (although at least they're making releases
> now ...)
> 
> There's also this project, to add hardware acceleration (SSE and so
> on) to libjpeg:
> 
> http://libjpeg-turbo.virtualgl.org/
> 
> If we're going to switch, maybe this is a good choice.

I did some profiling of this for the spice project, and it performed
very well. I would very much like this to be in fedora, either as a
separate library or as a replacement for libjpeg.

It is binary compatible with libjpeg, but contains some extra API not
supported by the normal libjpeg.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a war-weary voodoo gangster moving from town to town, helping folk in 
trouble. She's a transdimensional mutant college professor from the wrong side 
of the tracks. They fight crime! 

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

Re: libjpeg for F14

[Bastien Nocera]

On Tue, 2010-05-25 at 15:27 +0200, Alexander Larsson wrote:

> > There's also this project, to add hardware acceleration (SSE and so
> > on) to libjpeg:
> > 
> > http://libjpeg-turbo.virtualgl.org/
> > 
> > If we're going to switch, maybe this is a good choice.
> 
> I did some profiling of this for the spice project, and it performed
> very well. I would very much like this to be in fedora, either as a
> separate library or as a replacement for libjpeg.
> 
> It is binary compatible with libjpeg, but contains some extra API not
> supported by the normal libjpeg.

Which means you'll have to make a choice as to which one to support if
you want to handle JPEG files, and that we'll have to fix upgrades and
new installations to install the preferred one, as they would have the
same soname.

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

Re: libjpeg for F14

[Richard W.M. Jones]

On Tue, May 25, 2010 at 02:57:37PM +0100, Bastien Nocera wrote:
> On Tue, 2010-05-25 at 15:27 +0200, Alexander Larsson wrote:
> 
> > > There's also this project, to add hardware acceleration (SSE and so
> > > on) to libjpeg:
> > > 
> > > http://libjpeg-turbo.virtualgl.org/
> > > 
> > > If we're going to switch, maybe this is a good choice.
> > 
> > I did some profiling of this for the spice project, and it performed
> > very well. I would very much like this to be in fedora, either as a
> > separate library or as a replacement for libjpeg.
> > 
> > It is binary compatible with libjpeg, but contains some extra API not
> > supported by the normal libjpeg.
> 
> Which means you'll have to make a choice as to which one to support if
> you want to handle JPEG files, and that we'll have to fix upgrades and
> new installations to install the preferred one, as they would have the
> same soname.

Why couldn't we just replace libjpeg with the libjpeg-turbo upstream?
(For the primary architectures anyway).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Casey Dahlin]

On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
> On 05/23/2010 04:19 AM, Kevin Kofler wrote:
> > Lennart Poettering wrote:
> >> 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. ;-)
> > 
> > I, for one, think systemd should be the default ASAP.
> 
> Perhaps the first time I can recall that we have agreed. ;)
> 
> ~spot

Any particular reason on either of your parts?

Just about everything in systemd is either set to be in upstart (simpler
dependency syntax, xinetd-style service activation) or was discarded by it
years ago (cgroups are a dead end).

The assumption that just because its new means its more advanced is in this
case a bit misguided.

--CJD

> -- 
> 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: libjpeg for F14

[Adam Goode]

On 05/25/2010 10:09 AM, Richard W.M. Jones wrote:
> Why couldn't we just replace libjpeg with the libjpeg-turbo upstream?
> (For the primary architectures anyway).
> 

I think this is a great idea, libjpeg is the bottleneck for a lot of my
code.

One issue: are there C fallbacks for all the arch-specific code? It
would be great if secondary architectures could just use libjpeg-turbo
as well.


Adam



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20100525 changes

[Rawhide Report]

Compose started at Tue May 25 08:15:11 UTC 2010

Broken deps for i386
--
almanah-0.7.3-1.fc14.i686 requires libedataserver-1.2.so.12
1:anerley-0.1.8-4.fc14.i686 requires libedataserver-1.2.so.12
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
cjkuni-ukai-fonts-0.2.20080216.1-37.fc14.noarch requires 
cjkuni-fonts-common = 0:0.2.20080216.1-37.fc14
cjkuni-uming-fonts-0.2.20080216.1-37.fc14.noarch requires 
cjkuni-fonts-common = 0:0.2.20080216.1-37.fc14
contact-lookup-applet-0.17-3.1.fc14.i686 requires 
libedataserver-1.2.so.12
contacts-0.11-1.fc14.i686 requires libedataserver-1.2.so.12
dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11
deskbar-applet-2.30.0-1.1.fc14.i686 requires libedataserver-1.2.so.12
ekiga-3.2.6-3.fc14.i686 requires libedataserver-1.2.so.12
empathy-2.31.1-1.fc14.i686 requires libedataserver-1.2.so.12
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
evolution-sharp-0.21.1-6.fc14.i686 requires libedataserver-1.2.so.12
giggle-0.5-1.fc14.i686 requires libedataserver-1.2.so.12
gnome-launch-box-0.4-17.fc14.i686 requires libedataserver-1.2.so.12
gnome-panel-2.30.0-2.fc14.i686 requires libedataserver-1.2.so.12
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
gnome-python2-evolution-2.30.0-5.fc14.i686 requires 
libedataserver-1.2.so.12
jana-0.4.5-0.4.20090622gitb416a41.fc14.i686 requires 
libedataserver-1.2.so.12
kdebase-workspace-python-applet-4.4.80-1.fc14.i686 requires PyKDE4 >= 
0:4.4.80
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
1:libopensync-plugin-evolution2-0.22-4.fc14.i686 requires 
libedataserver-1.2.so.12
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
mail-notification-evolution-plugin-5.4-19.fc14.i686 requires 
libcamel-provider-1.2.so.15
mail-notification-evolution-plugin-5.4-19.fc14.i686 requires 
libcamel-1.2.so.15
mail-notification-evolution-plugin-5.4-19.fc14.i686 requires 
libedataserver-1.2.so.12
moblin-panel-myzone-0.0.13-3.fc14.i686 requires libedataserver-1.2.so.12
moblin-panel-people-0.0.10-5.fc14.i686 requires libedataserver-1.2.so.12
nautilus-sendto-2.28.4-2.fc14.i686 requires libedataserver-1.2.so.12
planner-eds-0.14.4-20.fc14.i686 requires libcamel-provider-1.2.so.15
planner-eds-0.14.4-20.fc14.i686 requires libcamel-1.2.so.15
planner-eds-0.14.4-20.fc14.i686 requires libedataserver-1.2.so.12

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
ruby-revolution-0.5-4.svn210.fc14.i686 requires libedataserver-1.2.so.12
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
syncevolution-1.0beta3-2.fc14.i686 requires libedataserver-1.2.so.12
tasks-0.16-3.fc14.i686 requires libedataserver-1.2.so.12
tracker-evolution-plugin-0.8.5-1.fc14.i686 requires 
libcamel-provider-1.2.so.15
tracker-evolution-plugin-0.8.5-1.fc14.i686 requires libcamel-1.2.so.15
tracker-evolution-plugin-0.8.5-1.fc14.i686 requires 
libedataserver-1.2.so.12
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
--
almanah-0.7.3-1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit)
1:anerley-0.1.8-4.fc14.i686 requires libedataserver-1.2.so.12
1:anerley-0.1.8-4.fc14.x86_64 requires libedataserver-1.2.so.12()(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()(64

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

[Lennart Poettering]

On Mon, 24.05.10 21:17, Jon Masters (jonat...@jonmasters.org) wrote:

> > > 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. 
> 
> This is not intended to start a flamewar.
> 
> I hadn't really heard about systemd, so I did some poking through your
> blog (http://0pointer.de/blog/projects/systemd.html ), which has a very
> lengthy amount on the subject, and thanks for writing that. There's even
> a section entitled "On upstart", which points out a few issues with
> Upstart and other things, such as SMF. But I'm still not really sure how
> to answer the first thing I thought of, which was along the lines of
> "why replace init yet again with something else when Upstart is just now
> getting some traction in the wider community?". 

Well, it would be much worse if we did this later on. The earlier the
better.

> Can you point us to where any background discussion has taken place
> with Upstart folks?

No, I cannot. Kay and I and a couple of others sat down at various LPC
and GUADEC and discussed what we would like to see in an init
system. And we had long discussions, but ultimately most of our ideas
were outright rejected by Scott, such as the launchd-style activation
and the cgroup stuff, two of the most awesome features in systemd
now. (That said, we actually managed to convince him on other points,
i.e. I believe we played a role in turning him from a D-Bus-hater into a
D-Bus-lover).

But anyway, these discussions did happen, over years. But there is no
recorded archive of that, no mailing list discussion I could point you
to, sorry. You can ask Kay and me and Scott about it though.

So we have discussed this with Scott in much detail, and we have
followed his development for a longer time. But in the end I just don't
think Upstart is the right thing, and fundamentally flawed and unlikely
to change direction, which is why we chose to start anew, and not just
"fix" Upstart. For more about that just read my blog story.

In summary, this is not coming out of the blue for Scott, we have
discussed that in length with him, but at one point we just saw that
Upstart is fundamentally not going to be what we have in mind, and so we
started a new experiment, and so far it turned out to have very
convincing results, if I may say in my humbleness.

> The thing is, I like some of the things Fedora re-invents differently.
> For example, dracut is quite nice (though there are too many initramfs
> creation tools available at this point, but then they do tend to be more
> distro specific), but IMO it is better to avoid redoing something at all
> costs unless driven by necessity of innovation. So assuming there's a
> nice backstory here, a need for Fedora to do something different, etc.
> then cool. But if there isn't, I'm much more weary of this.

Well, just read the core design and the feature list on our blog story,
and compare that with Upstart. And I am quite sure that if you grok the
awesomeness of the socket based activation that then you will no longer
wonder why systemd is the future and Upstart is not.

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

[Ilyes Gouta]

Hi,

SSE and friends are arch. specific and according to the feature list
the upstream is displaying, I don't think it would offer any other
benefits for the other archs.

There is one strong point that libjpeg-{6b, 8ab} inherited since it's
been there for a lof time: a *defacto* standard for JPEG
compression/decompression that has been heavily depolyed, used and
tested code for various application/, thoughtout the time, for more
than a decade! I think that's important and would enable it to keep
its place in the destribtion.

libjpeg-6b is at production level code, and it actually offers a
couple of ways to accelerate JPEG decoding by turning on the IDCT
level decimation (basically for free resize) and enabling YUV raw
decodes.

How about this: since libjpeg is picking momentum and there are
actually people updating the code base, why not push for a
libjpeg-turbo merge into the original ijg's code and get Fedora to
rebase on that unique source instead? That way ijg can test for any
regressions using their conformance tests.

Regards,
-Ilyes Gouta

On Tue, May 25, 2010 at 3:23 PM, Adam Goode  wrote:
> On 05/25/2010 10:09 AM, Richard W.M. Jones wrote:
>> Why couldn't we just replace libjpeg with the libjpeg-turbo upstream?
>> (For the primary architectures anyway).
>>
>
> I think this is a great idea, libjpeg is the bottleneck for a lot of my
> code.
>
> One issue: are there C fallbacks for all the arch-specific code? It
> would be great if secondary architectures could just use libjpeg-turbo
> as well.
>
>
> Adam
>
>
> --
> 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: systemd (Was Re: tmpfs for strategic directories)

[Lennart Poettering]

On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote:

> 
> On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
> > On 05/23/2010 04:19 AM, Kevin Kofler wrote:
> > > Lennart Poettering wrote:
> > >> 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. ;-)
> > > 
> > > I, for one, think systemd should be the default ASAP.
> > 
> > Perhaps the first time I can recall that we have agreed. ;)
> > 
> > ~spot
> 
> Any particular reason on either of your parts?
> 
> Just about everything in systemd is either set to be in upstart (simpler
> dependency syntax, xinetd-style service activation) or was discarded by it
> years ago (cgroups are a dead end).

Oh, is that so? 

Have you actually read the blog story I put together? 

Why do you say "cgroups are a dead end"? Sure, Scott claims that, but
uh, it's not the only place where he is simply wrong and his claims
baseless. In fact it works really well, and is one of the strong points
in systemd. I simply see no alternative for it. The points Scott raised
kinda showed that he never really played around with them.

Please read up on cgroups, before you just dismiss technology like that
as "dead end".

> The assumption that just because its new means its more advanced is in this
> case a bit misguided.

Well, please read the blog story. I know it's long, but it should be an
interesting read. The whole point of the blog story is to make clear the
reason systemd exists is purely technical, and that we think our design
is simply the better one.

We didn't do systemd for political reasons.

We didn't do systemd just to do things differently.

We did systemd because we thought that technically Upstart is
fundamentally flawed and misses out on so many opportunities.

And if you cannot see that then I can only beg you to read the blog
story, because it goes into much detail about all the technical
features.

Please, judge systemd on technical grounds, don't judge it on political,
or emotional grounds.

Thank you,

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

[Richard W.M. Jones]

On Tue, May 25, 2010 at 04:40:15PM +0100, Ilyes Gouta wrote:
> How about this: since libjpeg is picking momentum and there are
> actually people updating the code base, why not push for a
> libjpeg-turbo merge into the original ijg's code and get Fedora to
> rebase on that unique source instead?

The problem, as I said before, is that the libjpeg upstream is not
being developed in an open manner.

I've emailed Adam Tkac to bring his attention to this thread (he's
involved with libjpeg-turbo) and hopefully he'll bring some more up to
date information about this matter.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libjpeg for F14

[Richard W.M. Jones]

On Tue, May 25, 2010 at 10:23:45AM -0400, Adam Goode wrote:
> On 05/25/2010 10:09 AM, Richard W.M. Jones wrote:
> > Why couldn't we just replace libjpeg with the libjpeg-turbo upstream?
> > (For the primary architectures anyway).
> > 
> 
> I think this is a great idea, libjpeg is the bottleneck for a lot of my
> code.
> 
> One issue: are there C fallbacks for all the arch-specific code? It
> would be great if secondary architectures could just use libjpeg-turbo
> as well.

I had a quick scan of the build system, and it seems to me that on
non-x86 architectures it falls back to using C.  So it could be used
as a drop-in replacement for libjpeg.  Note that I've not tried
compiling it on a secondary arch.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libjpeg for F14

[Toshio Kuratomi]

On Tue, May 25, 2010 at 03:09:27PM +0100, Richard W.M. Jones wrote:
> On Tue, May 25, 2010 at 02:57:37PM +0100, Bastien Nocera wrote:
> > On Tue, 2010-05-25 at 15:27 +0200, Alexander Larsson wrote:
> > 
> > > > There's also this project, to add hardware acceleration (SSE and so
> > > > on) to libjpeg:
> > > > 
> > > > http://libjpeg-turbo.virtualgl.org/
> > > > 
> > > > If we're going to switch, maybe this is a good choice.
> > > 
> > > I did some profiling of this for the spice project, and it performed
> > > very well. I would very much like this to be in fedora, either as a
> > > separate library or as a replacement for libjpeg.
> > > 
> > > It is binary compatible with libjpeg, but contains some extra API not
> > > supported by the normal libjpeg.
> > 
> > Which means you'll have to make a choice as to which one to support if
> > you want to handle JPEG files, and that we'll have to fix upgrades and
> > new installations to install the preferred one, as they would have the
> > same soname.
> 
> Why couldn't we just replace libjpeg with the libjpeg-turbo upstream?
> (For the primary architectures anyway).
> 
The issue would be that it's a fork.  So libjpeg from the independent jpeg
group and libjpeg-turbo can gain incompatible API in isolation from each
other.  (The situtation seems a bit complex, there's three projects that
I can see working on libjpeg:

* libjpeg.sf.net -- working on API compatible updates to libjpeg-6b
* independent jpeg group (one person?) -- working on jpeg-8b and beyond
* libjpeg-turbo -- seems to be based on libjpeg-6b has speedups on modern
  x86 (w/SSE), licensed under the wxwindows license instead of BSD due to
  using code from that project.  (according to the README in libjpeg-turbo,
  wxwindows license is a less restrictive form of the LGPL -- it allows
  static linking without the resulting work having to take on the LGPL
  license.)

tgl, is this your understanding of the separate projects as well?

-Toshio


pgpfAJxSLmq6l.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 Tue, May 25, 2010 at 04:47:13PM +0100, Richard W.M. Jones wrote:
> On Tue, May 25, 2010 at 04:40:15PM +0100, Ilyes Gouta wrote:
> > How about this: since libjpeg is picking momentum and there are
> > actually people updating the code base, why not push for a
> > libjpeg-turbo merge into the original ijg's code and get Fedora to
> > rebase on that unique source instead?
> 
> The problem, as I said before, is that the libjpeg upstream is not
> being developed in an open manner.
> 
Licensing is also an issue here.  It's probably easier from licensing and
project management perspective to merge the ijg libjpeg into libjpeg-turbo
than vice versa.

> I've emailed Adam Tkac to bring his attention to this thread (he's
> involved with libjpeg-turbo) and hopefully he'll bring some more up to
> date information about this matter.
>
Sounds good.

-Toshio


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

Re: Font rendering in F13

[Adam Williamson]

On Sun, 2010-05-23 at 21:51 +0200, drago01 wrote:
> On Sun, May 23, 2010 at 9:11 PM, Gianluca Sforna  wrote:
> > On Sun, May 23, 2010 at 6:57 PM, Roberto Ragusa  
> > wrote:
> >>
> >> I'm well aware that many people have different tastes about font
> >> readability and that I'm probably out of the majority (who
> >> wants "like on Windows" rendering). This awareness was actually
> >> the reason of my post: to have guys remember that not everyone
> >> welcomes the bci.
> >>
> >
> > Actually, one of the first questions I get from users switching from
> > Ubuntu is why our fonts look worse than theirs.
> >
> > As of today, I haven't a good answer, if anyone knows better I'd
> > really love to hear where we differ and if/how we plan to close the
> > gap.
> 
> We neither do have the BCI nor the subpixel hinter enabled.
> 
> The patents for the former expired but apparently some fonts look
> worse with it so we decided to disable it.
> (I have been running with it enabled for years and for me stuff does
> look _way_ better with the bci ... but well this is a subjective
> thing).

AIUI, Microsoft fonts - Arial and the rest - are designed with BCI in
mind and look better that way. Free world fonts - Deja Vu and so on -
were designed with the autohinter in mind, and tend to look better that
way.

That's always been how it's looked to me as well, FWIW. Given that we
default to using free world fonts and can't ship Microsoft's fonts it
would seem sensible to default to the autohinter rather than the BCI, in
my opinion. I definitely prefer the autohinter's interpretation of the
fonts I usually use (Deja Vu / Vera).

I'd say the principle should be that we should use whichever
non-encumbered method gives the closest rendering to that intended by
the font designer of our default font set for any particular release.
-- 
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

FYI: python-sphinx-1.0 coming to rawhide soon

[Toshio Kuratomi]

This is just a heads up -- python-sphinx-1.0b1 has arrived.  hircus or
I will be updating rawhide to the new version soon -- which may cause your
documentation to stop building.  There are some incompatible changes in this
update, notably to the markup used for c functions and modules.  There is
a compatibility plugin that you can enable to take care of some of the
issues or you can port to the new "domains" syntax.

we probably will not be pushing this back to older versions of Fedora but
we'll have to see what the response is.  If we need to push out a compat
package for EPEL5 (python-sphinx1-1.0) then we'll have the possibility of
doing the same for older Fedora.

-Toshio


pgpLgqM3mVwlP.pgp
Description: PGP signature
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: rawhide report: 20100525 changes

[Yanko Kaneti]

On Tue, 2010-05-25 at 14:26 +, Rawhide Report wrote:

> llvm-2.7-2.fc14
> ---
> * Mon May 24 2010 Michel Salim  - 2.7-2
> - Exclude llm-gcc manpages
> - Turn on apidoc generation
> - Build with srcdir=objdir, otherwise clang doxygen build fails

 729768200 clang-apidoc-2.7-2.fc14.noarch.rpm
1513180272 llvm-apidoc-2.7-2.fc14.noarch.rpm

Please reconsider :/. This is big, even compared to the other doxygen
monstrosities out there.
Easily avoidable by removing graphviz from the build deps.

1513180272 llvm-apidoc-2.7-2.fc14.noarch.rpm
 729768200 clang-apidoc-2.7-2.fc14.noarch.rpm
 308665052 kdelibs-apidocs-4.4.80-1.fc14.noarch.rpm
 183951176 texlive-texmf-doc-2007-35.fc13.noarch.rpm
 159398728 asterisk-apidoc-1.6.2.8-0.1.rc1.fc14.x86_64.rpm
 143864764 mrpt-doc-0.8.0-0.3.20100102svn1398.fc14.x86_64.rpm
 118899072 cloudy-devel-doc-08.00-1.fc14.noarch.rpm
 115558504 qt-doc-4.7.0-0.14.beta1.fc14.noarch.rpm
  90590052 lilypond-doc-2.12.3-1.fc13.noarch.rpm
  66853332 libdap-doc-3.9.3-2.fc12.x86_64.rpm
  61305644 antlr3-C-docs-3.2-6.fc14.noarch.rpm
  52820224 bes-doc-3.7.2-3.fc12.x86_64.rpm

Roughly 10% of a particular arch tree footprint on the mirrors.


Yanko

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

Re: rawhide report: 20100525 changes

[Seth Vidal]

On Tue, 25 May 2010, Yanko Kaneti wrote:

> On Tue, 2010-05-25 at 14:26 +, Rawhide Report wrote:
>
>> llvm-2.7-2.fc14
>> ---
>> * Mon May 24 2010 Michel Salim  - 2.7-2
>> - Exclude llm-gcc manpages
>> - Turn on apidoc generation
>> - Build with srcdir=objdir, otherwise clang doxygen build fails
>
> 729768200 clang-apidoc-2.7-2.fc14.noarch.rpm
> 1513180272 llvm-apidoc-2.7-2.fc14.noarch.rpm
>
> Please reconsider :/. This is big, even compared to the other doxygen
> monstrosities out there.
> Easily avoidable by removing graphviz from the build deps.

+1

1.4GB is a massive pkg for just apidocs.


maybe worth referring to recent docs on the web somewhere?

-sv

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

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

[Jeff Spaleta]

On Tue, May 25, 2010 at 7:45 AM, Lennart Poettering
 wrote:
> Please, judge systemd on technical grounds, don't judge it on political,
> or emotional grounds.

"I'll publish the numbers of a 100% socket-activated boot soon."

I would love to have the necessary data to have an informed public
discussion on the technical merits which include some benchmarking and
some cookie cutter packages to play around with.  I want t be given a
chance to rig up some pathological poor performance systemd benchmarks
that you can publicly cut to shreds as part of the educational
process.

My one concern about the current discussion is that the decision to
move to systemd in the timeframe of F14 is being rushed ahead of the
aforementioned technical judgement.  I can understand your personal
enthusiasm for the move as you are intimately familiar with systemd.
But I'm not sure its adequate to rush ahead until we all have a better
feel on how this works in practise... and how much work its going to
take to convert all our existing packages to systemd styled startup.
The back and forth on your blog between yourself and Tim Waugh about
cups service activation, for example, is something I think we all need
to understand.  I think there is a lot buried in that discussion about
how complex some of our existing services are going to look under
systemd styled configuration.

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

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

[Jesse Keating]

On Tue, 2010-05-25 at 09:00 -0800, Jeff Spaleta wrote:
> On Tue, May 25, 2010 at 7:45 AM, Lennart Poettering
>  wrote:
> > Please, judge systemd on technical grounds, don't judge it on political,
> > or emotional grounds.
> 
> "I'll publish the numbers of a 100% socket-activated boot soon."
> 
> I would love to have the necessary data to have an informed public
> discussion on the technical merits which include some benchmarking and
> some cookie cutter packages to play around with.  I want t be given a
> chance to rig up some pathological poor performance systemd benchmarks
> that you can publicly cut to shreds as part of the educational
> process.
> 
> My one concern about the current discussion is that the decision to
> move to systemd in the timeframe of F14 is being rushed ahead of the
> aforementioned technical judgement.  I can understand your personal
> enthusiasm for the move as you are intimately familiar with systemd.
> But I'm not sure its adequate to rush ahead until we all have a better
> feel on how this works in practise... and how much work its going to
> take to convert all our existing packages to systemd styled startup.
> The back and forth on your blog between yourself and Tim Waugh about
> cups service activation, for example, is something I think we all need
> to understand.  I think there is a lot buried in that discussion about
> how complex some of our existing services are going to look under
> systemd styled configuration.
> 
> -jef

Right now, it's not about speed.  Speed is one thing, and somewhat
important.  But doing it right is also important.  Make it right, then
make it fast, because if you try to make it fast first, you'll often be
doing it wrong.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Simo Sorce]

On Tue, 25 May 2010 09:00:58 -0800
Jeff Spaleta  wrote:

> On Tue, May 25, 2010 at 7:45 AM, Lennart Poettering
>  wrote:
> > Please, judge systemd on technical grounds, don't judge it on
> > political, or emotional grounds.
> 
> "I'll publish the numbers of a 100% socket-activated boot soon."
> 
> I would love to have the necessary data to have an informed public
> discussion on the technical merits which include some benchmarking and
> some cookie cutter packages to play around with.  I want t be given a
> chance to rig up some pathological poor performance systemd benchmarks
> that you can publicly cut to shreds as part of the educational
> process.
> 
> My one concern about the current discussion is that the decision to
> move to systemd in the timeframe of F14 is being rushed ahead of the
> aforementioned technical judgement.  I can understand your personal
> enthusiasm for the move as you are intimately familiar with systemd.
> But I'm not sure its adequate to rush ahead until we all have a better
> feel on how this works in practise... and how much work its going to
> take to convert all our existing packages to systemd styled startup.
> The back and forth on your blog between yourself and Tim Waugh about
> cups service activation, for example, is something I think we all need
> to understand.  I think there is a lot buried in that discussion about
> how complex some of our existing services are going to look under
> systemd styled configuration.

I second that.

I'd like to remember that there are *many* upstreams are going to
resistant to this change. A lot of upstream projects need to be
compatible to a lot of Linux and Unix systems, even old ones, so before
they move they want guarantee that this is really going to be the next
thing. That means that until most distributions start using systemd
they are not going to do the work.

So before it is rushed in it is paramount that tests are done with
those application s that will not have systemd support and make sure
there is not going to be regressions there.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Font rendering in F13

[Ilyes Gouta]

Hi,

> That's always been how it's looked to me as well, FWIW. Given that we
> default to using free world fonts and can't ship Microsoft's fonts it
> would seem sensible to default to the autohinter rather than the BCI, in
> my opinion. I definitely prefer the autohinter's interpretation of the
> fonts I usually use (Deja Vu / Vera).

I think it all boils down to this question:

Do we want Fedora to provide full support for the TrueType standard
(actually file format is much more appropriate) or not?

> I'd say the principle should be that we should use whichever
> non-encumbered method gives the closest rendering to that intended by
> the font designer of our default font set for any particular release.

>From what I know, the FreeType API doesn't allow to switch from one
method to another on a per-font basis. But to move on and completely
disable such a feature (bci) is a hefty price to pay. Would be nice if
we could build a kind of a whitelist where bci would be used against
this and that font and disabled otherwise.

-Ilyes Gouta

On Tue, May 25, 2010 at 5:17 PM, Adam Williamson  wrote:
> On Sun, 2010-05-23 at 21:51 +0200, drago01 wrote:
>> On Sun, May 23, 2010 at 9:11 PM, Gianluca Sforna  wrote:
>> > On Sun, May 23, 2010 at 6:57 PM, Roberto Ragusa  
>> > wrote:
>> >>
>> >> I'm well aware that many people have different tastes about font
>> >> readability and that I'm probably out of the majority (who
>> >> wants "like on Windows" rendering). This awareness was actually
>> >> the reason of my post: to have guys remember that not everyone
>> >> welcomes the bci.
>> >>
>> >
>> > Actually, one of the first questions I get from users switching from
>> > Ubuntu is why our fonts look worse than theirs.
>> >
>> > As of today, I haven't a good answer, if anyone knows better I'd
>> > really love to hear where we differ and if/how we plan to close the
>> > gap.
>>
>> We neither do have the BCI nor the subpixel hinter enabled.
>>
>> The patents for the former expired but apparently some fonts look
>> worse with it so we decided to disable it.
>> (I have been running with it enabled for years and for me stuff does
>> look _way_ better with the bci ... but well this is a subjective
>> thing).
>
> AIUI, Microsoft fonts - Arial and the rest - are designed with BCI in
> mind and look better that way. Free world fonts - Deja Vu and so on -
> were designed with the autohinter in mind, and tend to look better that
> way.
>
> That's always been how it's looked to me as well, FWIW. Given that we
> default to using free world fonts and can't ship Microsoft's fonts it
> would seem sensible to default to the autohinter rather than the BCI, in
> my opinion. I definitely prefer the autohinter's interpretation of the
> fonts I usually use (Deja Vu / Vera).
>
> I'd say the principle should be that we should use whichever
> non-encumbered method gives the closest rendering to that intended by
> the font designer of our default font set for any particular release.
> --
> 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
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Jeff Spaleta]

On Tue, May 25, 2010 at 9:09 AM, Jesse Keating  wrote:
> Right now, it's not about speed.  Speed is one thing, and somewhat
> important.  But doing it right is also important.  Make it right, then
> make it fast, because if you try to make it fast first, you'll often be
> doing it wrong.

He offered benchmarks early in the thread and told us to be patient
 anyways.

No its not about the "speed".  But if I'm reading the blog story
correctly, conversion from sysV to native systemd configuration should
have an observable in some sort of performance metric. I learn best
from constructing tangible pathelogical situations, watching it break,
and then poking at the twitching, smoldering pieces.

Like I said... we need to have more discussion a long the lines of
what I saw concerning how cups and other services will work in a
systemd setting. We have to have a feel for the complexity of
configuration.

We'll also need to have good examples showing the sysV and inetd
compatibility at work. Not that I don't trust what was written in the
blog story, but having tangible example of a parallel installable
systemd that used the existing SySV styled init scripts as a precursor
for a serious discussion is going to go a long way at helping the
signal to noise ratio. I didn't see the systemd packages in the people
space Richard pointed to.  Can someone point me to an updated url?

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

Re: Debug Python stacks revisited - experimental build in Rawhide, targetting Fedora 14

[David Malcolm]

On Mon, 2010-05-24 at 20:11 -0400, David Malcolm wrote:
> On Thu, 2010-05-20 at 15:37 -0400, David Malcolm wrote:

[snip]

> I'm working next on enabling more of the debug flags in the debug
> builds;  you can see status on the under-construction feature page here:
> https://fedoraproject.org/wiki/DaveMalcolm/DebugPythonStacks

I've now enabled WITH_TSC, with COUNT_ALLOCS, and CALL_PROFILE for both
python and python3 (see the wiki page above for the specific builds).

[da...@surprise devel]$ python3-debug
Python 3.1.2 (r312:79147, May 25 2010, 12:21:20) 
[GCC 4.4.3 20100422 (Red Hat 4.4.3-18)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys ; from pprint import pprint
[32089 refs]
>>> pprint(sys.getcounts())
[('ImportError', 2, 2, 1),
 ('_Helper', 1, 0, 1),
 ('_Printer', 3, 0, 3),
[snip]
 ('dict', 3671, 3325, 389),
 ('str', 16194, 12860, 3334),
 ('tuple', 13995, 12300, 1740)]
[32101 refs]

One issue is that COUNT_ALLOCS seems to unconditionally log debug
information to stdout on exit:
memoryview alloc'd: 2, freed: 2, max in use: 1
ImportError alloc'd: 2, freed: 2, max in use: 1
_Helper alloc'd: 1, freed: 1, max in use: 1
_Printer alloc'd: 3, freed: 3, max in use: 3

which is likely to break scripts that capture stdout from python
scripts.

It seems useful to have sys.getcounts(), so perhaps we should talk with
upstream and instead emit counts to stderr instead, or make this only
happen if an envvar is set, or simply omit it.

Thoughts?
Dave

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

Re: Non-responsive maintainer: Subhodip Biswas

[Christoph Wickert]

Am Montag, den 24.05.2010, 00:23 +0200 schrieb Robert Scheck:

> Request: I hereby would like to take over the package "ddclient".

As a FESCO member I hereby approve the takeover, but please wait 3 more
days for others to object.

Regards,
Christoph

-- 
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 Tue, 25.05.10 09:00, Jeff Spaleta (jspal...@gmail.com) wrote:

> 
> On Tue, May 25, 2010 at 7:45 AM, Lennart Poettering
> My one concern about the current discussion is that the decision to
> move to systemd in the timeframe of F14 is being rushed ahead of the
> aforementioned technical judgement.  I can understand your personal
> enthusiasm for the move as you are intimately familiar with systemd.
> But I'm not sure its adequate to rush ahead until we all have a better
> feel on how this works in practise... and how much work its going to
> take to convert all our existing packages to systemd styled startup.
> The back and forth on your blog between yourself and Tim Waugh about
> cups service activation, for example, is something I think we all need
> to understand.  I think there is a lot buried in that discussion about
> how complex some of our existing services are going to look under
> systemd styled configuration.

Yes, if we'd adopt systemd in F14, then this would indeed be very
quick. But as mentioned, I have not proposed it yet, and while I
currently leaning towards that yes, I will propose it, I'll make my mind
up later about this.

There is no need to convert all services to the native format
right-away. Even normal SysV scripts should boot a little faster with
systemd, since we parallelize them to the level the LSB headers allow
that.

systemd plus the current scripts makes things a bit faster, systemd plus
native unit files should make things quite a bit more faster.

If we chose to adopt it for F14 it would probably a good idea to have
native files for everything that is installed by default at least. I
have mostly written those files now, so this goal should not be too hard
to reach, if we can convince all the maintainers involved to include
them in their packages.

Regarding CUPS: systemd supports all triggers for service startup that
launchd supports, and Apple (who develops CUPS) is starting it via
launchd, on demand. Not sure how nicely CUPS-on-MacOS translates to
CUPS-on-Fedora, but we can do things at least as nicely as they are on
MacOS. There, CUPS is started whenever

1. a local printer is plugged in
2. a local client wants to access its services
3. there's a file in the printer queue, possibly from before the last reboot

We can translate those rules 1:1 for systemd. And then we could
optionally add one more rule:

4. start cups anyway, on boot.

That way we would still benefit from the fully parallelized bootup the
socket based activation allows, but of course lose the on-demand
nicety. Implementing rule #4 means adding a single symlink in
/etc/systemd/system. We could for example choose to not have that
symlink by default, but ask the administrator to create it if he sets up
a multiplexing print server the way Tim suggested.

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)

[Alexander Boström]

tis 2010-05-25 klockan 20:30 +0200 skrev Lennart Poettering:

> /etc/systemd/system. We could for example choose to not have that
> symlink by default, but ask the administrator to create it if he sets up
> a multiplexing print server the way Tim suggested.

Wouldn't it be started automatically anyway when something connects to
systemd's *:631 socket?

/Alexander


-- 
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 Tue, 25.05.10 13:15, Simo Sorce (sso...@redhat.com) wrote:

> > My one concern about the current discussion is that the decision to
> > move to systemd in the timeframe of F14 is being rushed ahead of the
> > aforementioned technical judgement.  I can understand your personal
> > enthusiasm for the move as you are intimately familiar with systemd.
> > But I'm not sure its adequate to rush ahead until we all have a better
> > feel on how this works in practise... and how much work its going to
> > take to convert all our existing packages to systemd styled startup.
> > The back and forth on your blog between yourself and Tim Waugh about
> > cups service activation, for example, is something I think we all need
> > to understand.  I think there is a lot buried in that discussion about
> > how complex some of our existing services are going to look under
> > systemd styled configuration.
> 
> I second that.
> 
> I'd like to remember that there are *many* upstreams are going to
> resistant to this change. A lot of upstream projects need to be
> compatible to a lot of Linux and Unix systems, even old ones, so before
> they move they want guarantee that this is really going to be the next
> thing. That means that until most distributions start using systemd
> they are not going to do the work.

They don't *need* to move. It's not an exclusive disjunction, that you'd
have to support either systemd or not systemd. You can easily support
both systemd activation and classic sysv from the same binary. The 10
daemons we have patched so far only needed about 10 lines of changes
each to become socket-activatable. And those changes are nops unless
$LISTEN_FDS is set.

Or in other words: moving to systemd is a gradual process, where for
every service we can decide indivdually how we want to do it:

1) continue use a classic sysv init script
2) provide a native unit file
3) provide a native unit file and do socket/bus based activation

And all that for the same binary.

As mentioned I have now patched the 10 daemons or so we ship by default
(and a few more) to become socket activatable. If we can merge those
upstream and into our packages we already are a big step ahead and
everything else can come later.

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)

[Jon Masters]

On Tue, 2010-05-25 at 17:45 +0200, Lennart Poettering wrote:

> Please, judge systemd on technical grounds, don't judge it on political,
> or emotional grounds.

I'm not trying to "judge" it at all. But when the first thing I really
hear about a project is "we should replace our init system", my ears
prick up and I start to dig to find out what the new thing is (which I
admit I had never heard of) and why the rush. I'll read your blog again,
and I'm sure you have good ideas, I'm just not keen to see us rush into
replacing the init system again without some good co-ordination (I'm not
just thinking with my RHEL hat on, but I admit to also thinking about
other users of the base bits in the future).

I'll shutup now and read your blog.

Jon.


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

shared-mime-info inconsistencies

[Michel Alexandre Salim]

According to http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#mimeinfo

packages should not depend on shared-mime-info, but instead only
update its database if it happens to be installed. I would expect
shared-mime-info to be pulled in by either specifying it in comps.xml
or as a dependency to gvfs (on GNOME) or its KDE equivalent, but
instead it is required by gnome-vfs2 (which should not pull it in
anymore, now that we have gvfs) as well as PackageKit, several
NetworkManager subpackages, and several other applications.

Should we consider these packaging bugs? I'd file the bugs and fix
them, but first we probably need to decide on what is the right way to
pull in shared-mime-info on a normal installation, and ensuring that a
fix does not break upgrades.

Thanks,

-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sali...@fedoraproject.org  | GPG key ID: 78884778
Jabber: hir...@jabber.ccc.de   | IRC: hir...@irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-- 
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 Tue, 25.05.10 09:42, Jeff Spaleta (jspal...@gmail.com) wrote:

> Like I said... we need to have more discussion a long the lines of
> what I saw concerning how cups and other services will work in a
> systemd setting. We have to have a feel for the complexity of
> configuration.
> 
> We'll also need to have good examples showing the sysV and inetd
> compatibility at work. Not that I don't trust what was written in the
> blog story, but having tangible example of a parallel installable
> systemd that used the existing SySV styled init scripts as a precursor
> for a serious discussion is going to go a long way at helping the
> signal to noise ratio. I didn't see the systemd packages in the people
> space Richard pointed to.  Can someone point me to an updated url?

OK, here's an example, for a relatively modern and clean daemon, the
dbus system bus. Its SysV init script is relatively simple (see
/etc/init.d/messagebus). And the configuration to make it socket-bus
activatable would be even simpler and look like this:

You'd have two units, one for the socket:

http://0pointer.de/public/dbus.socket

The contents should be pretty self-explanatory.

And one for the service itself, that is activated when the socket units
receives traffic:

http://0pointer.de/public/dbus.service

This one is pretty self-explanatory too I guess. It defines some
requirement and ordering dependencies, to make sure that dbus is started
after the initial base system is set up and after the socket itself is
set up. (Later on we might even drop part of those ordering
dependencies, since dbus could run much earlier at boot-up if it was
simply using an abstract namespace socket, instead of relying on a
writable /var. But that's another discussion)

(Oh, don't try to run actually use that .socket and .service file, you
need my patches that add --address to dbus daemon, and the special
"systemd:" address)

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 Tue, 25.05.10 20:38, Alexander Boström (a...@root.snowtree.se) wrote:

> 
> tis 2010-05-25 klockan 20:30 +0200 skrev Lennart Poettering:
> 
> > /etc/systemd/system. We could for example choose to not have that
> > symlink by default, but ask the administrator to create it if he sets up
> > a multiplexing print server the way Tim suggested.
> 
> Wouldn't it be started automatically anyway when something connects to
> systemd's *:631 socket?

Yes, absolutely.

Tim's point originally was about two things:

1) what if browsing for daemons takes a long time and hence starting
   cupsd only when somebody opens the print dialog might not 
   make some people happy if the print dialog is only populated with
   printers after a minute of searching or so. I personally believe that
   this is a problem of the browsing protocol, as mDNS/DNS-SD does not
   suffer by problems like this and should provide the list of printers
   in under a second in any case. (browsing protocols should probably
   query the network for printers only when somebody actually want to see the
   data and not alraedy in advance like cups native browsing protocol is
   currently doing, simply to minimize the traffic this
   generates)

2) What happens if a print server is merely a "router" for print jobs,
   and exclusively publishes *non-local* printers on the network for
   browsing. That machine wouldn't have any local printer then and starting the 
cups
   daemon on-demand would not suffice since the machine would have to
   announce the printer on the network first.

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: Packages depending on Yelp

[Matthew Garrett]

We discussed this issue at the fesco meeting today. The net outcome was 
that it's currently impractical to require that all packages that use 
yelp depend on it. However, requiring all yelp-using apps to integrate 
support for telling the user what's wrong may be unreasonable.

Long-term, it would be nice for this to integrate with PackageKit 
somehow. Short-term, the simplest solution would seem to be to provide a 
stub package that provides: yelp and a yelp binary, and then have that 
binary do nothing other than tell the user that they need to install 
yelp. Spins would then be at liberty to choose whether to provide the 
"real" yelp or the stub version. Once that's implemented dependencies 
can be added.

Does anyone have any objection to this approach?
-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Fedora-packaging] shared-mime-info inconsistencies

[Matthias Clasen]

On Tue, 2010-05-25 at 20:57 +0200, Michel Alexandre Salim wrote:
> According to 
> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#mimeinfo
> 
> packages should not depend on shared-mime-info, but instead only
> update its database if it happens to be installed. I would expect
> shared-mime-info to be pulled in by either specifying it in comps.xml
> or as a dependency to gvfs (on GNOME) or its KDE equivalent, but
> instead it is required by gnome-vfs2 (which should not pull it in
> anymore, now that we have gvfs) as well as PackageKit, several
> NetworkManager subpackages, and several other applications.
> 
> Should we consider these packaging bugs? I'd file the bugs and fix
> them, but first we probably need to decide on what is the right way to
> pull in shared-mime-info on a normal installation, and ensuring that a
> fix does not break upgrades.

There is a big difference between a package like gedit, which just adds
information about its supported mime types, and gvfs or PackageKit,
which rely on the mime database for a core part of their functionality.

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

Re: Packages depending on Yelp

[Matt McCutchen]

On Tue, 2010-05-25 at 20:22 +0100, Matthew Garrett wrote:
> We discussed this issue at the fesco meeting today. The net outcome was 
> that it's currently impractical to require that all packages that use 
> yelp depend on it. However, requiring all yelp-using apps to integrate 
> support for telling the user what's wrong may be unreasonable.
> 
> Long-term, it would be nice for this to integrate with PackageKit 
> somehow. Short-term, the simplest solution would seem to be to provide a 
> stub package that provides: yelp and a yelp binary, and then have that 
> binary do nothing other than tell the user that they need to install 
> yelp. Spins would then be at liberty to choose whether to provide the 
> "real" yelp or the stub version. Once that's implemented dependencies 
> can be added.
> 
> Does anyone have any objection to this approach?

We would have to ensure that (1) "yum install yelp" chooses the real
package rather than the stub and (2) the real package can be installed
on a system containing the stub without causing a file conflict.

An alternative would be to provide a wrapper script that runs yelp if
present or otherwise tells the user to install it, and have applications
require the wrapper package.  We could either give the wrapper script a
different name and patch all applications to run that name or rename the
real yelp executable and have all callers go through the wrapper.  I
don't see any way to avoid patching all the application packages to
require the wrapper package rather than "yelp", given that we want
installing "yelp" to actually install it but installing an application
to only install the wrapper.

-- 
Matt

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

Minutes/Summary for today's FESCo meeting (2010-05-25)

[Kevin Fenzi]

===
#fedora-meeting: FESCO (2010-05-25)
===


Meeting started by nirik at 19:00:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-05-25/fesco.2010-05-25-19.00.log.html

Meeting summary
---
* init process  (nirik, 19:00:01)

* #340 #Determine and approve F11 end of life date  (nirik, 19:01:33)
  * AGREED: new f11 eol date is 2010-06-25  (nirik, 19:03:45)

* #381 #yelp dependency of gnome desktop apps  (nirik, 19:04:17)
  * LINK: http://fpaste.org/406j/   (skvidal, 19:11:36)
  * ACTION: mjg59 will talk to yelp maintainer(s) and see about PK
integration and/or a yelp-yelp stub package  (nirik, 19:16:30)
  * AGREED: recommend currently NOT to add yelp dependencies. Will work
on longer term/better solution from here.  (nirik, 19:21:51)

* #351 Create a policy for updates - status report on implementation
  (nirik, 19:22:34)
  * AGREED: will re-enable critical path for f13 updates post release.
(nirik, 19:45:17)
  * ACTION: nirik will write up a announcement for fedora-devel about
critical path for f13 release.  (nirik, 19:47:34)

* Elections  (nirik, 19:49:14)
  * LINK: https://admin.fedoraproject.org/voting/   (nirik, 19:49:35)

* Fedora 13 release  (nirik, 19:52:58)

* FES report  (nirik, 19:56:34)
  * LINK: https://fedorahosted.org/fedora-engineering-services/report/6
(nirik, 19:56:39)

* Open Floor  (nirik, 20:07:15)

Meeting ended at 20:08:37 UTC.

Action Items

* mjg59 will talk to yelp maintainer(s) and see about PK integration
  and/or a yelp-yelp stub package
* nirik will write up a announcement for fedora-devel about critical
  path for f13 release.

--
19:00:01  #startmeeting FESCO (2010-05-25)
19:00:01  Meeting started Tue May 25 19:00:01 2010 UTC.  The chair is 
nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:01  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
19:00:01  #meetingname fesco
19:00:01  #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones 
cwickert mjg59
19:00:01  #topic init process
19:00:01  The meeting name has been set to 'fesco'
19:00:01  Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 
nirik notting pjones skvidal
19:00:07 * skvidal is here
19:00:12  hereish.
19:00:17 * pjones is here also, but not where skvidal is.
19:00:37  cwickert had to step away for a bit, and sends his regrets.
19:00:39  Here
19:00:42  pjones: but I bet you wish you were - durham being as cool 
as it is
19:00:52  nirik: I bet he didn't send all that many regrets
19:00:58  oh yeah, durham is awesome.
19:01:05 * notting is here
19:01:12  Present.
19:01:22  ok, lets go ahead and dive in...
19:01:24  I recall the years I worked in durham, surrounded by the EPA. 
 Great time.
19:01:31 * dgilmore 
19:01:33  #topic #340 #Determine and approve F11 end of life date
19:01:33  .fesco 340
19:01:37  nirik: #340 (Determine and approve F11 end of life date) - 
FESCo - Trac - https://fedorahosted.org/fesco/ticket/340
19:01:41  The ticket that keeps on giving. ;)
19:01:58  f13 pushed out a week with it's slip.
19:01:59  +1 to slipping it another week to match the final F13 
release slip.
19:01:59 * dgilmore says leave it as is but doesnt care if we extend it
19:02:04  do we want to push f11 eol out more too?
19:02:46  I'm ok with pushing it out as well... doesn't matter too much, 
but we should provide it the +1month
19:03:09 * notting is ok with making it match the final release date.
19:03:24 * skvidal is fine with it, too
19:03:25  Yes, I'm +1 to slipping it one more week
19:03:32  +1 slip
19:03:45  #agreed new f11 eol date is 2010-06-25
19:04:00  +1 to slip
19:04:14  ok, lets discuss the yelp thing next, and save the updates 
doom for last.
19:04:17  #topic #381 #yelp dependency of gnome desktop apps
19:04:17  .fesco 381
19:04:18  nirik: #381 (yelp dependency of gnome desktop apps) - FESCo - 
Trac - https://fedorahosted.org/fesco/ticket/381
19:04:43  Basically, it's impossible to fit yelp and its 
dependencies on the KDE Live CD.
19:04:44  so, the two alternatives here are: yelp deps so help works in 
all the apps that use it, or no deps to avoid bloat
19:04:53  Even if it switches to webkitgtk, that won't be of much 
help to us.
19:05:09  So all the stuff which is dragged onto the KDE spin 
CANNOT require yelp.
19:05:15  It's just technically not possible.
19:05:15 * nirik nods.
19:05:22  can the functionality yelp provides be done generically 
that it will work with whatever browser is installed
19:05:27  say via alternatives
19:05:30  dgilmore: it's based off a gconf key
19:05:31  or something like that
19:05:42  notting: ewww
19:06:03  Yelp docs don't work in any other viewer.
19:06:14  I don't mind the offering to install it when you select help, 
but thats not implemented.
19:06:19  They're docbook-based just like KDE's help format, but 
they use docbook differently. :-(
19:06:23  So they're not compaitb

Re: libjpeg for F14

[Genes MailLists]

On 05/25/2010 09:27 AM, Alexander Larsson wrote:
>
>> There's also this project, to add hardware acceleration (SSE and so
>> on) to libjpeg:
>>
>> http://libjpeg-turbo.virtualgl.org/


   PLease also don't forget the applications which are provided by
libjpeg such as jpegtran et al ..

   Are they all included in the turbo version ?

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

Re: Packages depending on Yelp

[James Antill]

On Tue, 2010-05-25 at 15:58 -0400, Matt McCutchen wrote:
> On Tue, 2010-05-25 at 20:22 +0100, Matthew Garrett wrote:
> > We discussed this issue at the fesco meeting today. The net outcome was 
> > that it's currently impractical to require that all packages that use 
> > yelp depend on it. However, requiring all yelp-using apps to integrate 
> > support for telling the user what's wrong may be unreasonable.
> > 
> > Long-term, it would be nice for this to integrate with PackageKit 
> > somehow. Short-term, the simplest solution would seem to be to provide a 
> > stub package that provides: yelp and a yelp binary, and then have that 
> > binary do nothing other than tell the user that they need to install 
> > yelp. Spins would then be at liberty to choose whether to provide the 
> > "real" yelp or the stub version. Once that's implemented dependencies 
> > can be added.
> > 
> > Does anyone have any objection to this approach?
> 
> We would have to ensure that (1) "yum install yelp" chooses the real
> package rather than the stub and (2) the real package can be installed
> on a system containing the stub without causing a file conflict.
> 
> An alternative would be to provide a wrapper script that runs yelp if
> present or otherwise tells the user to install it, and have applications
> require the wrapper package.  We could either give the wrapper script a
> different name and patch all applications to run that name or rename the
> real yelp executable and have all callers go through the wrapper.  I
> don't see any way to avoid patching all the application packages to
> require the wrapper package rather than "yelp", given that we want
> installing "yelp" to actually install it but installing an application
> to only install the wrapper.

 With the latest compare_providers¹ this should be fairly easy. We just
have yelp-nothing (Provides: yelp) which installs a simple binary that
says yelp isn't there and a "yelp" package which is the real thing.
 Then "yum install yelp" will install the pkg. yelp, and "yum install
blah" will install yelp-nothing as a dep.


¹ http://yum.baseurl.org/wiki/CompareProviders

-- 
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.28
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libjpeg for F14

[Richard W.M. Jones]

On Tue, May 25, 2010 at 04:47:29PM -0400, Genes MailLists wrote:
> On 05/25/2010 09:27 AM, Alexander Larsson wrote:
> >
> >> There's also this project, to add hardware acceleration (SSE and so
> >> on) to libjpeg:
> >>
> >> http://libjpeg-turbo.virtualgl.org/
> 
> 
>PLease also don't forget the applications which are provided by
> libjpeg such as jpegtran et al ..
> 
>Are they all included in the turbo version ?

Yes.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Font rendering in F13

[Matěj Cepl]

Dne 25.5.2010 18:17, Adam Williamson napsal(a):
> Free world fonts - Deja Vu and so on -
> were designed with the autohinter in mind, and tend to look better that
> way.

Not all of them ... I was chatting with the author of Iconoclasta and he 
admitted he developed the font on Windows and with BCI on his mind.

Matěj

-- 
Basically, the only ???intuitive??? interface is the nipple.  After
that, it's all learned.
 -- Bruce Ediger when discussing intuivity of Mac OS
http://groups.google.com/group/comp.sys.next.advocacy\
/msg/7fa8c580900353d0

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

CVS branches for F-11 closed

[Dennis Gilmore]

Hi All,

Since Fedora 13 was released today new CVS branches for F-11 will not be
allowed.  http://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL lists 
the policy in effect this means that F-11 is now in a maintenance only cycle,  
with EOL fast approaching,  the  EOL date was set to June 25th by FESCo ( 
http://meetbot.fedoraproject.org/fedora-
meeting/2010-05-25/fesco.2010-05-25-19.00.html ).

Dennis


signature.asc
Description: This is a digitally signed message part.
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Fedora-packaging] shared-mime-info inconsistencies

[Michel Alexandre Salim]

On Tue, May 25, 2010 at 9:50 PM, Matthias Clasen  wrote:
> On Tue, 2010-05-25 at 20:57 +0200, Michel Alexandre Salim wrote:
>> According to 
>> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#mimeinfo
>>
>> packages should not depend on shared-mime-info, but instead only
>> update its database if it happens to be installed. I would expect
>> shared-mime-info to be pulled in by either specifying it in comps.xml
>> or as a dependency to gvfs (on GNOME) or its KDE equivalent, but
>> instead it is required by gnome-vfs2 (which should not pull it in
>> anymore, now that we have gvfs) as well as PackageKit, several
>> NetworkManager subpackages, and several other applications.
> There is a big difference between a package like gedit, which just adds
> information about its supported mime types, and gvfs or PackageKit,
> which rely on the mime database for a core part of their functionality.
>
gvfs does not depend on shared-mime-info, though. gnome-vfs2 does (is
it needed?). Also, do the various NetworkManager packages need to
depend on s-m-i?

Thanks,

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

Re: Packages depending on Yelp

[Matt McCutchen]

On Tue, 2010-05-25 at 16:54 -0400, James Antill wrote:
> On Tue, 2010-05-25 at 15:58 -0400, Matt McCutchen wrote:
> > An alternative would be to provide a wrapper script that runs yelp if
> > present or otherwise tells the user to install it, and have applications
> > require the wrapper package.  We could either give the wrapper script a
> > different name and patch all applications to run that name or rename the
> > real yelp executable and have all callers go through the wrapper.  I
> > don't see any way to avoid patching all the application packages to
> > require the wrapper package rather than "yelp", given that we want
> > installing "yelp" to actually install it but installing an application
> > to only install the wrapper.
> 
>  With the latest compare_providers¹ this should be fairly easy. We just
> have yelp-nothing (Provides: yelp) which installs a simple binary that
> says yelp isn't there and a "yelp" package which is the real thing.
>  Then "yum install yelp" will install the pkg. yelp, and "yum install
> blah" will install yelp-nothing as a dep.

I feel like taking advantage of a yum feature to make the "yelp" name do
something different as a dependency than as a "yum install" argument is
a hack and will only cause confusion down the road, whereas changing the
application dependencies to yelp-nothing would be the right thing to do.

-- 
Matt

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

python 1.0 beta 1, with API changes, in Rawhide

[Michel Alexandre Salim]

Toshio and I currently have no plans to push this to any stable
releases yet, due to API changes. It is likely that 1.0 will be
released in time for Fedora 14, so if you use Sphinx for your
documentation needs, please test it against Rawhide's Sphinx 1.0 beta
and report any migration problem.

http://sphinx.pocoo.org/latest/changes.html#incompatible-changes

Best regards,

-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sali...@fedoraproject.org  | GPG key ID: 78884778
Jabber: hir...@jabber.ccc.de   | IRC: hir...@irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

python-sphinx 1.0 beta 1, with API changes, in Rawhide (was Re: python 1.0 beta 1, with API changes, in Rawhide)

[David Malcolm]

On Wed, 2010-05-26 at 01:08 +0200, Michel Alexandre Salim wrote:
> Toshio and I currently have no plans to push this to any stable
> releases yet, due to API changes. It is likely that 1.0 will be
> released in time for Fedora 14, so if you use Sphinx for your
> documentation needs, please test it against Rawhide's Sphinx 1.0 beta
> and report any migration problem.
> 
> http://sphinx.pocoo.org/latest/changes.html#incompatible-changes
> 
Thanks for the heads-up

Changing the Subject, from "python" to "python-sphinx" - for a moment I
was extremely confused and thought it was 1994 again :)

Dave

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

Re: python-sphinx 1.0 beta 1, with API changes, in Rawhide (was Re: python 1.0 beta 1, with API changes, in Rawhide)

[Michał Piotrowski]

2010/5/26 David Malcolm :
> On Wed, 2010-05-26 at 01:08 +0200, Michel Alexandre Salim wrote:
>> Toshio and I currently have no plans to push this to any stable
>> releases yet, due to API changes. It is likely that 1.0 will be
>> released in time for Fedora 14, so if you use Sphinx for your
>> documentation needs, please test it against Rawhide's Sphinx 1.0 beta
>> and report any migration problem.
>>
>> http://sphinx.pocoo.org/latest/changes.html#incompatible-changes
>>
> Thanks for the heads-up
>
> Changing the Subject, from "python" to "python-sphinx" - for a moment I
> was extremely confused and thought it was 1994 again :)

Me too :)

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

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

Re: python-sphinx 1.0 beta 1, with API changes, in Rawhide (was Re: python 1.0 beta 1, with API changes, in Rawhide)

[Michel Alexandre Salim]

2010/5/26 Michał Piotrowski :
> 2010/5/26 David Malcolm :
>> On Wed, 2010-05-26 at 01:08 +0200, Michel Alexandre Salim wrote:
>>> Toshio and I currently have no plans to push this to any stable
>>> releases yet, due to API changes. It is likely that 1.0 will be
>>> released in time for Fedora 14, so if you use Sphinx for your
>>> documentation needs, please test it against Rawhide's Sphinx 1.0 beta
>>> and report any migration problem.
>>>
>>> http://sphinx.pocoo.org/latest/changes.html#incompatible-changes
>>>
>> Thanks for the heads-up
>>
>> Changing the Subject, from "python" to "python-sphinx" - for a moment I
>> was extremely confused and thought it was 1994 again :)
>
> Me too :)
>
Apologies for the (rather hilarious) subject error. Serves me right
for sending an email past midnight...

Best regards,

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

Re: libjpeg for F14

[Genes MailLists]

On 05/25/2010 05:03 PM, Richard W.M. Jones wrote:

>>
>>PLease also don't forget the applications which are provided by
>> libjpeg such as jpegtran et al ..
>>
>>Are they all included in the turbo version ?
> 
> Yes.
> 

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

Re: libjpeg for F14

[Kevin Kofler]

Ilyes Gouta wrote:
> There is one strong point that libjpeg-{6b, 8ab} inherited since it's
> been there for a lof time: a *defacto* standard for JPEG
> compression/decompression that has been heavily depolyed, used and
> tested code for various application/, thoughtout the time, for more
> than a decade! I think that's important and would enable it to keep
> its place in the destribtion.
> 
> libjpeg-6b is at production level code, and it actually offers a
> couple of ways to accelerate JPEG decoding by turning on the IDCT
> level decimation (basically for free resize) and enabling YUV raw
> decodes.

This kind of arguments doesn't really make sense for Fedora. We should ship 
the best implementation, not the most "tried and true" one. Fedora is about 
advancing Free Software, not being conservative. If you see any concrete 
issues with libjpeg-turbo, do point them out. If not, we shouldn't refuse it 
just because it's not the same old stuff.

Something which is IMHO more important to consider is whether libjpeg-turbo 
is missing any improvements which are in the current IJG codebase, e.g. new 
APIs apps may start relying on at some point. (In that case, we need to 
either decide which to ship or ship both.)

Kevin Kofler

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

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

[Kevin Kofler]

Simo Sorce wrote:
> I'd like to remember that there are *many* upstreams are going to
> resistant to this change. A lot of upstream projects need to be
> compatible to a lot of Linux and Unix systems, even old ones, so before
> they move they want guarantee that this is really going to be the next
> thing. That means that until most distributions start using systemd
> they are not going to do the work.

So we just patch them in Fedora. This kind of integration work is what a 
distribution is for.

Kevin Kofler

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

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

[Kevin Kofler]

Lennart Poettering wrote:
> If we chose to adopt it for F14 it would probably a good idea to have
> native files for everything that is installed by default at least. I
> have mostly written those files now, so this goal should not be too hard
> to reach, if we can convince all the maintainers involved to include
> them in their packages.

I think that if the maintainers don't do it, it should just be done by a 
provenpackager. This is global distro integration and needs to be done at 
global distro level.

Kevin Kofler

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

banshee-1 hang during playing video overnight

[Luming Yu]

Hi there,

I happen to see a banshee-1 hang after it was accidentally left
repeatedly playing two videos (big-buck-bunny.ogv and kittens.ogv)
overnight.
Any insight and suggestions to the hang will be very appreciated.

Thanks,
Luming


 ├─bash(2726)───banshee-1(2731)─┬─{banshee-1}(2732)
│  ├─{banshee-1}(2733)
│  ├─{banshee-1}(2734)
│  ├─{banshee-1}(2735)
│  ├─{banshee-1}(2736)
│  ├─{banshee-1}(2737)
│  ├─{banshee-1}(2739)
│  ├─{banshee-1}(2740)
│  ├─{banshee-1}(2741)
│  ├─{banshee-1}(2743)
│  ├─{banshee-1}(2747)
│  ├─{banshee-1}(2748)
│  ├─{banshee-1}(2764)
│  ├─{banshee-1}(2765)
│  ├─{banshee-1}(2766)
│  ├─{banshee-1}(2806)
│  ├─{banshee-1}(2812)
│  └─{banshee-1}(2813)
(gdb) attach 2806

(gdb) bt
#0  0x00e27424 in __kernel_vsyscall ()
#1  0x004de85c in pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:169
#2  0x04b963d7 in gst_data_queue_push (queue=0xa771f18,
item=0xa8886a0) at gstdataqueue.c:417
#3  0x03593ee5 in gst_multi_queue_chain (pad=0xa6ff648,
buffer=0xaa4c690) at gstmultiqueue.c:1169
#4  0x054b4c45 in gst_pad_chain_data_unchecked (pad=0xa6ff648,
is_buffer=1, data=0xaa4c690) at gstpad.c:4122
#5  0x054b568f in gst_pad_push_data (pad=0xa941b00, is_buffer=1,
data=0xaa4c690) at gstpad.c:4351
#6  0x05be2238 in gst_ogg_demux_chain_peer (pad=0xa941b00,
packet=0xb113eff0, push_headers=0) at gstoggdemux.c:649
#7  0x05be5287 in gst_ogg_pad_submit_packet (pad=0xa941b00,
npackets=) at gstoggdemux.c:860
#8  gst_ogg_pad_stream_out (pad=0xa941b00, npackets=) at gstoggdemux.c:893
#9  0x05be6579 in gst_ogg_pad_submit_page (pad=0xa941b00,
page=0xb113f110) at gstoggdemux.c:965
#10 0x05be9772 in gst_ogg_demux_chain (pad=0xaa15268,
buffer=0xb75f16e0) at gstoggdemux.c:2878
#11 0x05bea0ac in gst_ogg_demux_loop_forward (pad=0xaa15268) at
gstoggdemux.c:2968
#12 gst_ogg_demux_loop (pad=0xaa15268) at gstoggdemux.c:3112
#13 0x054e1143 in gst_task_func (task=0xa969160) at gsttask.c:238
#14 0x054e27e8 in default_func (tdata=0xaa5bfb0, pool=0xa3db1d8) at
gsttaskpool.c:70
#15 0x005ac554 in ?? () from /lib/libglib-2.0.so.0
#16 0x005aa550 in ?? () from /lib/libglib-2.0.so.0
#17 0x004dab59 in start_thread (arg=0xb113fb70) at pthread_create.c:301
#18 0x0074ee8e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133

(gdb) detach
(gdb) attach 2812
(gdb) bt
#0  0x00e27424 in __kernel_vsyscall ()
#1  0x004de85c in pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:169
#2  0x054afeeb in handle_pad_block (pad=0xaa484b8) at gstpad.c:3959
#3  0x054b2557 in gst_pad_push_event (pad=0xaa484b8, event=0xaa582f0)
at gstpad.c:4876
#4  0x03906b8e in ?? () from /usr/lib/gstreamer-0.10/libgstflac.so
#5  0x054b1ec3 in gst_pad_send_event (pad=0xa9f74c0, event=0xaa582f0)
at gstpad.c:5043
#6  0x054b23ea in gst_pad_push_event (pad=0xaa304b0, event=0xaa582f0)
at gstpad.c:4899
#7  0x03594b82 in gst_single_queue_push_one (pad=0xaa304b0) at
gstmultiqueue.c:942
#8  gst_multi_queue_loop (pad=0xaa304b0) at gstmultiqueue.c:1101
#9  0x054e1143 in gst_task_func (task=0xaa42f40) at gsttask.c:238
#10 0x054e27e8 in default_func (tdata=0xaa64740, pool=0xa3db1d8) at
gsttaskpool.c:70
#11 0x005ac554 in ?? () from /lib/libglib-2.0.so.0
#12 0x005aa550 in ?? () from /lib/libglib-2.0.so.0
#13 0x004dab59 in start_thread (arg=0xaa7fcb70) at pthread_create.c:301
#14 0x0074ee8e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133


(gdb) detach
(gdb) attach 2813

(gdb) bt
#0  0x00e27424 in __kernel_vsyscall ()
#1  0x004e15c9 in __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:142
#2  0x004dc78b in _L_lock_800 () from /lib/libpthread.so.0
#3  0x004dc5b1 in __pthread_mutex_lock (mutex=0x9e18238) at
pthread_mutex_lock.c:61
#4  0x03eab997 in ?? () from /usr/lib/banshee-1/libbanshee.so
#5  0x00c10d0c in g_cclosure_marshal_VOID__OBJECT () from
/lib/libgobject-2.0.so.0
#6  0x00c02713 in g_closure_invoke () from /lib/libgobject-2.0.so.0
#7  0x00c1a275 in ?? () from /lib/libgobject-2.0.so.0
#8  0x00c1b8dc in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#9  0x00c1c037 in g_signal_emit () from /lib/libgobject-2.0.so.0
#10 0x05486b2a in gst_bin_add_func (bin=0xa6451c0, element=0xa714320)
at gstbin.c:1099
#11 0x05483254 in gst_bin_add (bin=0xa6451c0, element=0xa714320) at
gstbin.c:1162
#12 0x02c6c20d in ?? () from /usr/lib/gstreamer-0.10/

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

[Casey Dahlin]

On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
> On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote:
> 
> > 
> > On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
> > > On 05/23/2010 04:19 AM, Kevin Kofler wrote:
> > > > Lennart Poettering wrote:
> > > >> 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. ;-)
> > > > 
> > > > I, for one, think systemd should be the default ASAP.
> > > 
> > > Perhaps the first time I can recall that we have agreed. ;)
> > > 
> > > ~spot
> > 
> > Any particular reason on either of your parts?
> > 
> > Just about everything in systemd is either set to be in upstart (simpler
> > dependency syntax, xinetd-style service activation) or was discarded by it
> > years ago (cgroups are a dead end).
> 
> Oh, is that so? 
> 
> Have you actually read the blog story I put together? 
> 

Yes, but I'm going to go read it again just to be sure.

> Why do you say "cgroups are a dead end"? Sure, Scott claims that, but
> uh, it's not the only place where he is simply wrong and his claims
> baseless. In fact it works really well, and is one of the strong points
> in systemd. I simply see no alternative for it. The points Scott raised
> kinda showed that he never really played around with them.
> 
> Please read up on cgroups, before you just dismiss technology like that
> as "dead end".
> 

I did. When upstart was about to use them. 2 years ago. We chucked them by the
following LPC.

The problem we've found is that cgroups are too aggressive. They don't have a
notion of sessions and count too much as being part of your service, so you end
up with your screen session being counted as part of gdm.

This is why setsid was added to the netlink connector.

> > The assumption that just because its new means its more advanced is in this
> > case a bit misguided.
> 
> Well, please read the blog story. I know it's long, but it should be an
> interesting read. The whole point of the blog story is to make clear the
> reason systemd exists is purely technical, and that we think our design
> is simply the better one.
> 

So you have:

1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you
cared to submit the patch. We don't think its good enough by itself, hence the
rest of Upstart, but a socket activation subsystem that could reach as far as
systemd and even work standalone in settings where systemd can work is
perfectly within Upstart's scope. I'd be happy to firm up the design details
with you if you wanted to contribute patches.

2) Bus activation. Missed opportunity here to actually become the launchpoint
for activated services. I won't criticize that too much though, as its
usefulness is largely dependent on kernelspace DBus, which I've been trying to
bludgeon Marcel Holtmann into turning over to the public for a year now.

3) Cutting down on the forking by replacing some of the shell scripts... cool
   3a) With C code... really?

4) Process environment control. No complaints, and also nothing Upstart doesn't
want to do.

> We did systemd because we thought that technically Upstart is
> fundamentally flawed and misses out on so many opportunities.
> 

And we think the same of systemd.

> And if you cannot see that then I can only beg you to read the blog
> story, because it goes into much detail about all the technical
> features.
> 
> Please, judge systemd on technical grounds, don't judge it on political,
> or emotional grounds.
> 

Not to be specifically political, but did you ever consider submitting systemd
itself as a patch? Literally:

diff -pruN ~lennart/coding/upstart ~lennart/coding/systemd

And mail it to upstart-devel-list. I'm being a bit hyperbolic, but actually not
much. That would have been a valid move.

You should really come work with us. We're fun guys.

--CJD
-- 
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/26/2010 08:32 AM, Casey Dahlin wrote:
>
> I'd be happy to firm up the design details
> with you if you wanted to contribute patches.
>   

I would recommend that noone do that unless Canonical's drops it's
flawed copyright license agreement.

Rahul

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

Re: banshee-1 hang during playing video overnight

[Rakesh Pandit]

On 26 May 2010 08:16, Luming Yu wrote:
> Hi there,
>
> I happen to see a banshee-1 hang after it was accidentally left
> repeatedly playing two videos (big-buck-bunny.ogv and kittens.ogv)
> overnight.
> Any insight and suggestions to the hang will be very appreciated.
>

Please report it on bugzilla (if not already done) with all
information and follow up with maintainer.

-- 
Rakesh Pandit
https://fedoraproject.org/wiki/User:Rakesh
freedom, friends, features, first
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: banshee-1 hang during playing video overnight

[Luming Yu]

On Wed, May 26, 2010 at 11:48 AM, Rakesh Pandit  wrote:
> On 26 May 2010 08:16, Luming Yu wrote:
>> Hi there,
>>
>> I happen to see a banshee-1 hang after it was accidentally left
>> repeatedly playing two videos (big-buck-bunny.ogv and kittens.ogv)
>> overnight.
>> Any insight and suggestions to the hang will be very appreciated.
>>
>
> Please report it on bugzilla (if not already done) with all
> information and follow up with maintainer.
https://bugzilla.redhat.com/show_bug.cgi?id=595997
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel