Plan for tomorrow's FESCo meeting (2010-06-01)

2010-05-31 Thread Kevin Fenzi
Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 19:00UTC (3pm EDT) in #fedora-meeting on
irc.freenode.net.

= Followups = 

#topic #351 Create a policy for updates - status report on implementation
https://fedorahosted.org/fesco/ticket/351

= New business =

#topic Elect Chair
#topic New meeting time?
#topic #385 Zim / zim package issues.
#topic #382 Implementing Stable Release Vision

= Fedora Engineering Services tickets = 

https://fedorahosted.org/fedora-engineering-services/report/6

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. 

kevin


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

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

2010-05-31 Thread Rahul Sundaram
On 05/23/2010 05:21 AM, Lennart Poettering wrote:
> On Sun, 23.05.10 00:04, Ilyes Gouta (ilyes.go...@gmail.com) wrote:
>
> Heya,
>
>   
>> So how fast is a systemd boot (with all the changes to the scripts)
>> compared to the current F13 setup? How about a ratio?
>> 
> Please be patient. To quote myself: "I'll publish the numbers of a 100%
> socket-activated boot soon."
>   

To get the ball rolling, I have written up a feature proposal and filed
a review request

https://fedoraproject.org/wiki/Features/systemd

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

It probably requires a lot more work but it is a start. 

Rahul

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


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

2010-05-31 Thread Lennart Poettering
On Sat, 29.05.10 21:00, Roberto Ragusa (m...@robertoragusa.it) wrote:

> 
> Kevin Kofler wrote:
> 
> > Roberto Ragusa wrote:
> >> I need to change firewalls rules and routing rules in the middle of the
> >> init scripts, because I have a multihomed internet connection and remote
> >> filesystems and I need the firewall closed and then opened in a way which
> >> is dependent on the IP I got from the ISP
> > Ugh! Are you sure there's no better solution?!
> 
> Kevin, this is not an exactly real scenario, but I wanted to say that
> sometimes it is useful to *hack* something in the middle of the init
> script for some reason.

And this is why systemd allows you to do that. You can patch the
.service files the way you want, and can hook shell scripts into various
places, if you want to. And on top of this it adds a couple of debug
helpers such as interactive, serialized boot-up and proper tracing of
what is being executed.

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)

2010-05-31 Thread Lennart Poettering
On Sat, 29.05.10 19:48, Roberto Ragusa (m...@robertoragusa.it) wrote:

> 
> Kevin Kofler wrote:
> > Jeremy Sanders wrote:
> >>
> >> You're suggesting hammering shut the insides of linux to stop people
> >> playing around and reducing freedom - sounds like you want Fedora to be
> >> like the products of other large propitiatory systems.
> > 
> > C code can be changed too, if really needed. But the point is that it 
> > should 
> > not be necessary to edit code at all to get what's needed.
> 
> Well, I really do not want to flame anyone, but please consider that
> the guy proposing the change already gave us pulseaudio, which promised the
> "it will do anything you do now, just easier" feature too.

Ah, turning this into something personal. Love you too.

> We then discovered that some _trivial_ things where lost:
> - having multiple independent sound cards
> - having control of the mixer
> - having sound with no user logged in
> ... should I also mention latency, CPU usage, stability,...?

You seem to have no idea what you are talking about. But anyway, let's
not turn this into a discussion about PA. Don't need another one of those.

> Linux must NOT be Windows.
> Linux must NOT be OS X.

Well I for one think we can learn a lot from the competition. Open your
eyes. There's a lot of good stuff in those other OS worlds, particularly
in the designs of MacOS X. There's still so much they do better than we
do. 

Lennart

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


Re: Fedora rawhide FTBFS status 2010-05-27 i386

2010-05-31 Thread Ralf Corsepius
On 05/31/2010 07:44 PM, Matt Domsch wrote:
> Fedora Fails To Build From Source Results for i386
> using rawhide from 2010-05-27
>
> This is a full rebuild, the first for Fedora 14's rawhide.  The
> builders all have Fedora 13 installed.

> OpenSceneGraph-2.8.2-3.fc12 (build/make) corsepiu

From
http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/OpenSceneGraph-2.8.2-3.fc12.src.rpm/result/build.log:

extracting debug info from 
/builddir/build/BUILDROOT/OpenSceneGraph-2.8.2-3.fc14.i386/usr/lib/osgPlugins-2.8.2/osgwrapper_osgVolume.so
extracting debug info from 
/builddir/build/BUILDROOT/OpenSceneGraph-2.8.2-3.fc14.i386/usr/lib/osgPlugins-2.8.2/osgwrapper_osgViewer.so
extracting debug info from 
/builddir/build/BUILDROOT/OpenSceneGraph-2.8.2-3.fc14.i386/usr/lib/osgPlugins-2.8.2/osgwrapper_osgUtil.so
/usr/lib/rpm/find-debuginfo.sh: line 90:  3300 Bus error 
(core dumped) eu-strip --remove-comment $g -f "$1" "$2"
error: Bad exit status from /var/tmp/rpm-tmp.1Jia6Z (%install)
RPM build errors:
 Bad exit status from /var/tmp/rpm-tmp.1Jia6Z (%install)
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.

?!?

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


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

2010-05-31 Thread Lennart Poettering
On Sat, 29.05.10 19:27, Roberto Ragusa (m...@robertoragusa.it) wrote:

> 
> Kevin Kofler wrote:
> > Jon Masters wrote:
> >> Didn't we "decide" that Fedora was intended for more technical users? I
> >> don't see many technical users crying out for a hammered shut init
> >> system where they feel like they have to go to their auto mechanic to
> >> attach the right magic dongle to fix it when it breaks.
> > 
> > A really TECHNICAL user has no trouble editing a C program. :-)
> 
> On a router?
> With no gcc installed?
> And with no disk space to install gcc?
> And with no network available? (because, you know, I'm fixing the router
> which is failing to boot properly)

Guys, nobody wants to take away configuration options. You can edit the
.service files too, and readjust things. You can even plug in shell
scripts here and there and wherever it suits you.

There are not plans to make configuration of systemd depndent on gcc or
gdb. That is completely made up.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 19:45, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote:

> 
> Le dimanche 23 mai 2010 à 00:34 +0200, Lennart Poettering a écrit :
> 
> > ATM everything looks rosy. I just finished porting over all F13
> > installed-by-default daemons to socket activation, and a few more (and
> > the patches are good enough to be upstreamable).
> 
> For this kind of stuff I strongly suggest you do not limit yourself to
> F13 installed-by-default daemons (which are mostly well-behaved C/C++
> desktop-oriented code) but pass the reality check of converting
> important server daemons (postfix, apache, bind...) and non C/C++
> services (jboss or tomcat in java, amavisd-new or something else in
> perl, etc)

Well, I'd argue that for server software like that neither the
lazy-loading of daemons nor fast booting is really crucial. It's OK if a
server takes a bit longer to boot. It's way less important than for a
desktop or laptop. The focus of the service activation work should be on
services needed by desktop systems I guess. For everything else the
implicit activation is handy too, but not as crucial.

> Otherwise you'll replay the networkmanager drama with part of the Fedora
> users going the new laptop way, part refusing to even look at it because
> it can not translate in the server stuff they need at work, and everyone
> being very sad, unhappy, and angry at others.

Well, while network configuration is certainly very important for server
setups, super-fast booting and lazy-loading of daemons 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: systemd (Was Re: tmpfs for strategic directories)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 13:37, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:

> 
> On 05/26/2010 12:07 PM, Adam Williamson wrote:
> 
> >> It is not like you want to edit the scripts all the time, so there is
> >> no reason for them being scripts.
> >
> > I beg to differ. I've had to create or modify initscripts quite often,
> > either as a sysadmin or a packager. If this is now going to require C
> > coding skills, I'm not going to be able to do it. I don't think it's
> > safe to assume that everyone who needs to write or modify an initscript
> > is going to know C. What about people who write apps that need
> > initscripts in some other language?
> 
> It could work out if systemd provided access to a system() equivalent 
> which could then execute an arbitrary script.

You can easily hook shell scripts into .service files via stuff like
ExecStartPre=/some/shell/script which will then be executed before the
actual daemon is forked off.

> I think one good argument for redoing initscripts is that they are so
> repetitive: most of the content is fairly standard: initialization, 
> argument  parsing, case $1 in start) stop), etc etc. ; stuff that might 
> as well be done in the common framework.

That is true. Most scripts are 1:1 copies of the init script template of
our guidelines.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote:

> This suggests to me that environment variables isn't the right way to do 
> this. 
> Environment variables are good for parameters that should be available to 
> many 
> processes. Command line parameters are better when the parameter is only 
> meant 
> for one specific process. I can see how looking up two environment variables 
> may be a smaller patch than adding a parameter to the program's command line 
> parser, but I still think it should be done with command line
> parameters.

This is a valid point and we have pondered this for a while and in the
end decided to use environ[] instead of argv[], simply because this
allows us to use the same code for handling it in all daemons, while
handling --listen-fds=xxx in argv would work for some daemons, but not
for others. (i.e. some don't do long getopt, others do it with one dash
only). Also, quite a few projects (rsyslog for example) implement socket
handling in loadable modules, where we have no access to argv[] but do
have access to environ[].

> LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the 
> original daemon is restarted but its children live on, then later some 
> descendant process may get the same PID as the original daemon, and may try 
> to 
> handle LISTEN_FDS. The risk may be low, but I always prefer a solution that 
> is 
> guaranteed to work over one that mostly works.

Well, this is purely theoretical, since LISTEN_FDS should normally only
be set for daemons that can actually handle this and hence as long as
these are running none of their children can get the same PID.

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: Fedora rawhide FTBFS status 2010-05-27 i386

2010-05-31 Thread Matt Domsch
On Mon, May 31, 2010 at 06:04:46PM -0400, Orcan Ogetbil wrote:
> On Mon, May 31, 2010 at 5:31 PM, Matt Domsch wrote:
> > On Mon, May 31, 2010 at 09:58:12PM +0100, Mat Booth wrote:
> >> On 31 May 2010 18:44, Matt Domsch wrote:
> >> >
> >> > xerces-j2-2.9.0-3.fc13 (build/make) mbooth
> >>
> >>
> >> What do I need to do if a scratch build for rawhide succeeds?
> >>
> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=2220859
> >
> > Nothing for now. ??I'm rebuilding all the failed builds, w/o using
> > tmpfs for buildroot. ??If that clears up the problem, I won't file bugs
> > against your packages.
> >
> 
> Please also rebuild the pkgconfig segfaulted builds (see the issue
> Mamoru pointed out) too if possible. I don't know how many there are
> overall but I have at least two such failures (ardour,
> fluidsynth-dssi).

Now that this fixed pkgconfig is in rawhide, I'll update and restart
the build with today's rawhide.

Here are the previous failures easily attributed to pkgconfig
segfaults.  This is a simple grep -i pkg.config | grep -i segmentation
of the build.log files.  These may be ignored as FTBFS for now.

i386 pkgconfig segfault failures:
abiword-2.8.4-1.fc14.src.rpm
almanah-0.7.3-1.fc14.src.rpm
anjuta-2.30.0.0-2.fc14.src.rpm
balsa-2.4.7-2.fc14.src.rpm
beagle-0.3.9-19.fc14.src.rpm
bitmap-1.0.3-7.fc13.src.rpm
bluefish-2.0.0-2.fc14.src.rpm
chemical-mime-data-0.1.94-7.fc12.src.rpm
claws-mail-3.7.6-1.fc14.1.src.rpm
claws-mail-plugins-3.7.6-1.fc14.src.rpm
clutter-1.2.8-1.fc14.src.rpm
clutter-gesture-0.0.2-2.fc13.src.rpm
clutter-gst-1.0.0-1.fc14.src.rpm
compat-libgda-3.1.2-3.fc12.src.rpm
ConsoleKit-0.4.1-5.fc13.src.rpm
crda-1.1.1_2009.11.25-3.fc14.src.rpm
dalston-0.1.12-1.fc14.src.rpm
ekiga-3.2.6-4.fc14.src.rpm
epiphany-extensions-2.30.1-2.fc14.src.rpm
evolution-2.31.2-1.fc14.src.rpm
firefox-3.6.3-4.fc14.src.rpm
fluidsynth-dssi-1.0.0-2.fc12.src.rpm
GConf2-2.31.3-1.fc14.src.rpm
gedit-2.31.1-1.fc14.src.rpm
gedit-plugins-2.31.1-1.fc14.src.rpm
gegl-0.1.2-2.fc14.src.rpm
gjs-0.6-1.fc14.src.rpm
gmrun-0.9.2-22.fc14.src.rpm
gnome-applets-2.30.0-1.fc14.src.rpm
gnome-color-manager-2.30.1-1.fc14.src.rpm
gnome-media-2.30.0-2.fc14.src.rpm
gnome-menus-2.30.0-2.fc14.src.rpm
gnome-packagekit-2.30.1-1.fc14.src.rpm
gnome-phone-manager-0.65-5.fc12.src.rpm
gnome-speech-0.4.25-3.fc12.src.rpm
gnome-themes-extras-2.22.0-5.fc12.src.rpm
gnome-user-share-2.30.0-1.fc14.src.rpm
gnome-vfs2-2.24.3-1.fc14.src.rpm
gnumeric-1.10.0-1.fc14.src.rpm
gssdp-0.7.2-1.fc14.src.rpm
gstreamer-0.10.29-1.fc14.src.rpm
gstreamer-plugins-bad-free-0.10.18.3-1.fc14.src.rpm
gstreamer-plugins-base-0.10.29-1.fc14.src.rpm
gtk2-2.21.0-1.fc14.src.rpm
gtksourceview2-2.10.1-1.fc14.src.rpm
guile-gnome-platform-2.16.1-4.fc12.src.rpm
gvfs-1.6.1-3.fc14.src.rpm
ibus-1.3.3-1.fc14.src.rpm
iw-0.9.19-2.fc14.src.rpm
kmplayer-0.11.2b-1.fc14.src.rpm
libbeagle-0.3.9-5.fc12.src.rpm
libchamplain-0.4.5-1.fc14.src.rpm
libdmapsharing-1.9.0.13-1.fc13.src.rpm
libdrm-2.4.20-1.fc14.src.rpm
libgda-4.1.4-1.fc14.src.rpm
libgtkhotkey-0.2.1-3.fc13.src.rpm
libinfinity-0.4.1-1.fc14.src.rpm
libopensync-0.22-5.fc12.src.rpm
libsoup22-2.2.105-8.fc13.src.rpm
libsoup-2.30.1-1.fc14.src.rpm
libtranslate-0.99-23.fc14.src.rpm
libxcb-1.5-1.fc13.src.rpm
libxfce4ui-4.7.2-1.fc14.src.rpm
libxklavier-5.0-1.fc13.src.rpm
libxnm-0.1.3-3.fc12.src.rpm
meiga-0.3.2-1.fc13.src.rpm
menu-cache-0.3.2-1.fc14.src.rpm
mingw32-atk-1.29.3-1.fc13.src.rpm
mingw32-enchant-1.5.0-4.fc12.src.rpm
mingw32-glibmm24-2.23.2-1.fc14.src.rpm
mingw32-gtk2-2.19.6-1.fc14.src.rpm
mingw32-gtk-vnc-0.3.8-6.fc12.src.rpm
moserial-2.28.0-2.fc13.src.rpm
NetworkManager-0.8.1-0.1.git20100510.fc14.src.rpm
ochusha-0.6.0.1-0.7.cvs20090728T0130.fc13.1.src.rpm
openvrml-0.18.5-2.fc14.src.rpm
ORBit2-2.14.18-1.fc14.src.rpm
pango-1.28.0-1.fc14.src.rpm
pulseaudio-0.9.21-6.fc13.src.rpm
puzzles-8887-2.fc13.src.rpm
pyclutter-1.0.2-1.fc14.src.rpm
pygoocanvas-0.14.1-2.fc14.src.rpm
pygtk2-2.17.0-3.fc13.src.rpm
seahorse-plugins-2.30.1-1.fc14.src.rpm
seamonkey-2.0.4-1.fc14.src.rpm
sunbird-1.0-0.21.20090916hg.fc14.src.rpm
sylpheed-3.0.0-4.fc14.src.rpm
syncevolution-1.0beta3-2.fc14.src.rpm
tango-icon-theme-0.8.90-2.fc12.src.rpm
tango-icon-theme-extras-0.1.0-4.fc12.src.rpm
telepathy-farsight-0.0.13-1.fc13.src.rpm
totem-2.30.2-2.fc14.src.rpm
viewnior-1.0-1.fc14.src.rpm
viking-0.9.91-3.fc13.src.rpm
vips-7.20.7-2.fc14.src.rpm
webkitgtk-1.2.0-1.fc14.src.rpm
xesam-glib-0.5.0-3.fc12.src.rpm
xine-lib-1.1.18.1-1.fc14.src.rpm
xmms-pulse-0.9.4-8.fc12.src.rpm
xpad-4.0-6.fc14.src.rpm


x86_64 pkgconfig segfault failures:
bitmap-1.0.3-7.fc13.src.rpm
cairomm-1.8.4-1.fc13.src.rpm
chemical-mime-data-0.1.94-7.fc12.src.rpm
evolution-2.31.2-1.fc14.src.rpm
gnome-applets-2.30.0-1.fc14.src.rpm
gtk2-2.21.0-1.fc14.src.rpm
mingw32-gtk2-2.19.6-1.fc14.src.rpm
pygoocanvas-0.14.1-2.fc14.src.rpm
tango-icon-theme-0.8.90-2.fc12.src.rpm
tango-icon-theme-extras-0.1.0-4.fc12.src.rpm
totem-2.30.2-2.fc14.src.rpm


-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO
-- 
devel mailing list
devel@

Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.

2010-05-31 Thread Chen Lei
2010/6/1 Ryan Rix :
> On Mon 31 May 2010 1:55:26 pm Paul Wouters wrote:
>> since that's the preference
>> of the maintainer, which violates fedora packagaging policies
>
> Then a provenpackager should fix it regardless of whether the maintainer "is
> too busy to fix it." and even then, they shouldn't be maintaining packages
> they are too busy to fix! That's just as bad as blatently refusing to fix
> this issue.
>
> --
> Ryan Rix
> == http://hackersramblings.wordpress.com | http://rix.si/ ==
> == http://rix.si/page/contact/ if you need a word         ==
>

The maintainer refuse some others to co-maintain tor package or help
him to solve this issue. It's a bit complicated to fix this, fedora
policy seems don't permit provenpackagers to commit a package if the
maintainer are very unwilling to do so. It should be decided by fesco
in which condition that a provenpackager can commit a package
regardless the unwillingness of the package owner.


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

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

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 18:02, Scott James Remnant (sc...@canonical.com) wrote:

> On Wed, 2010-05-26 at 18:14 +0200, Lennart Poettering wrote:
> 
> > Oh come on. Thanks for turning this into something personal.
> > 
> You did that last week - I got forwarded logs from #systemd.  That's
> probably why I wasn't in a great mood with you this morning ;-)

Not sure what you are referring to.

> I'm not sure there's any point in technical discussion about the
> relative merits of our two approaches at this point, since you've
> already *written* systemd and you're already pushing for inclusion in
> distributions, and I'm continuing to develop Upstart and already have it
> in distributions.

Well, the members of this mailing list are definitely interested in the
relative merits of both systems, since it is people on this mailing list
who in the end will have to come up with an informed decision about
systemd adoption in Fedora.

I mean, I have been writing novels here about how awesome systemd is
(and how upstart isn't ;-)). If you think that Fedora would make a
big mistake in adopting systemd, then please point out why, I am pretty
sure people will listen if you keep things technical.

It's always good to hear both sides when a decision needs to be made.

> So what we've ended up with is two different systems, and one can assume
> that roughly half the distributions will end up with one, and another
> half with the other.

Well. We'll see about that.

> At least we have the common standard of the LSB Init Scripts that both
> will support.

Well, it would be good if we'd have more than that. Since you want to
support socket-based activation too now in Upstart it would be great if
we could also come to an agreement on the $LISTEN_FD iface and similar.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 14:47, Simo Sorce (sso...@redhat.com) wrote:

> > environment variables are normally inherited when forking/execing. We
> > want to make sure that only the process we actually start ourselves
> > parses and handles LISTEN_FDS. We want to avoid that if this daemon
> > might spawn some other process, it might get confused into handling
> > LISTEN_FDS, although that env var wasn't actually intended for it.
> > 
> > And hence we say that LISTEN_PID should be verified first, and only if
> > it matches LISTEN_FDS should be handled.
> 
> If you are mandating behavior in daemons, wouldn't it be simpler to
> mandate the daemon unsets LISTEN_FDS ?

Yes, our reference implementation actually does that. But we didn't want
to rely on that, simply because handling the environ[] array is so messy,
since memory allocation is not clear and the whole thing is not
thread-safe. In many case environ[] should probably be considered a
read-only data structure during runtime.

> If I replace the process with a script, or the dameon runs other
> processes LISTEN_PID is going to be wrong anyway, not sure how useful
> it really is.

Nah, as long as the script calls exec() in the end it should be fine, as
the PID isn't changed on exec(). Note that for the purpose of
baby-sitting it is kinda nice to know which process is the main process
of a daemon, hence needless fork()ing on startup sucks anyway, and
should better not be done if we can.

> You are assuming that the process you run is always going to be *the*
> daemon. I think it is an unrealistic assumption to make.

Oh, its very much realistic I think. It holds for every single of the 10
daemons or so from the default F13 install and beyond I have patched so
far.

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: using DAG's (or some other) zsync for test releases

2010-05-31 Thread Andre Robatino
On second thought, I should have posted this to the test list, so I forwarded it
there.  Sorry.



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


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

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 12:27, Adam Williamson (awill...@redhat.com) wrote:

> > The plan is to reduce what is currenlty done in files like
> > /etc/init.d/messagebus to files like
> > http://0pointer.de/public/dbus.service.
> > 
> > And those files you can edit just fine, and reconfigure.
> 
> There's no need to yell, you only explained that a couple of minutes
> ago, before I wrote the above mail. From your blog post, it sounded very
> much like compiled initscripts were what you were proposing.
> 
> This seems perfectly reasonable, but at the same time, when you explain
> it this way, it doesn't seem like anything that needs a new init system
> to happen. You can move stuff into the daemons themselves no matter what
> init system you're using, and it seems like upstart would be open to
> moving appropriate things into the init system. That does seem like a
> perfectly sensible thing to do, though, so I hope it happens, whatever
> init system we wind up with.

Well. Sure. Upstart can copy every feature we have. But while all of
this is still in the future for Upstart we already have implemented a
fair bit of it in systemd.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 13:08, Colin Walters (walt...@verbum.org) wrote:

> >> I beg to differ. I've had to create or modify initscripts quite often,
> >> either as a sysadmin or a packager. If this is now going to require C
> >> coding skills, I'm not going to be able to do it. I don't think it's
> >> safe to assume that everyone who needs to write or modify an initscript
> >> is going to know C. What about people who write apps that need
> >> initscripts in some other language?
> >
> > THERE ARE NO PLANS TO SHIP COMPILED INIT SCRIPTS OR ANYTHING LIKE THAT!
> >
> > The plan is to reduce what is currenlty done in files like
> > /etc/init.d/messagebus to files like
> > http://0pointer.de/public/dbus.service.
> 
> Also:
> 
> > Description=D-Bus System Bus
> 
> This seems unnecessary.  Can we default to the name of the script?  If
> this isn't translated, I don't see how it's more interesting than just
> "dbus".

Later on this shall be translatable, the same way as the Comment field
of .desktop files.

And if you omit this option we'll already default to the unit name, the
way you suggsted.

> 
> > Requires=basic.target sockets.target dbus.socket
> > After=basic.target sockets.target dbus.socket
> 
> What does this goop mean and why is it necessary?

basic.target encapsulates the early boot process (kinda the same stuff
rc.sysinit currently does). The Requires= make sure that this is pulled
in by dbus.service. The After= makes sure that it has finished before we
fork dbus.

And ignore the sockets.target/dbus.socket stuff, that I had in there for
debugging only. It's not necessary, and completely redundant. It will
not be in the final version of this .service file.

The reason why basic.target is explicitly mentioned in the .service file
is that we want to handle early boot and normal daemon start-up with the
same .service files. This is different from launchd for example, where
early boot is basically a shell script handled completely independently
and differently from normal services. I think we need more flexibility
there, simply because we have to cover way more than Apple has to when
it comes to plugging something into early boot. The price for that is
that normal daemons that are started in "late boot", have to add these
Requires= and After= lines for basic.target. 

This felxible design has various other advantages too, for example we
can blur the destinction between early and late boot a bit and remove
the synchronization point that seperates them, for selected services.

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


using DAG's (or some other) zsync for test releases

2010-05-31 Thread Andre Robatino
I downloaded DAG's EL5 x86_64 RPM for zsync from

http://dag.wieers.com/rpm/packages/zsync/

and installed on x86_64 F13.  There were no extra dependencies required,
so I just used rpm -Uvh to install.  It seems to work fine.  Would it be
acceptable to use a third-party version such as this to produce and post
.zsync files when a new TC/RC is available?  Having zsync would allow
testers to generate the install CD set from the install DVD without
significant extra downloading, meaning more testing for split media.  I
wrote a simple howto on using rsync for this:

https://fedoraproject.org/wiki/Draft:Converting_Between_Install_Disc_Sets_Using_Rsync

and the same procedure would work using zsync, if it was available for
test releases.  Right now it can only be used for what's on the main
mirrors (Alpha, Beta, Final), since some of those provide rsync.



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

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

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 12:57, Colin Walters (walt...@verbum.org) wrote:

> 
> On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering
>  wrote:
> >
> > http://0pointer.de/public/dbus.service.
> 
> Note the ExecStartPre here, like most daemons, is conceptually busted.
>  There's no reason we shouldn't lay that file down once when the OS is
> installed, and not check it every boot.  Or alternatively, just move
> the uuid generation into the daemon itself.

I think it kinda makes sense to to leave the uuid generating for the
first boot, simply to make it easy to generate a hdd image during
installation which can tzhen be booted from various machines, where each
of them will then get its own uuid.

But yes, I too think that dbus itself should just create that uuid on
startup.


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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 09:01, Jeff Spaleta (jspal...@gmail.com) wrote:

> 
> On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering
>  wrote:
> > Well, that depends on configuration.
> 
> > In systemd you can choose individually for each unit whether you want to
> > allow it to continue run processes on shut down, whether you want the
> > main process killed, the process group to be killed or the cgroup to be
> > killed.
> 
> Do you have a service file example yet in systemd git that can be used
> to get an understanding of the various configuration options which
> determine what gets killed and what doesn't?

Nope, not really.

But it is as easy as this: when we stop a service the "KillMode=" option
controls whether and how any processes remaining after the "ExecStop="
command (if there is such a command, and if there are any processes left)
is killed.

KillMode=control-group → the entire cgroup is shot down
KillMode=process-group → only the process group of the process we forked is 
shot down 
KillMode=process → only the process we forked is shot down
KillMode=none → nothing is shot down

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 08:19, Jeff Spaleta (jspal...@gmail.com) wrote:

> 
> On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering
>  wrote:
> > In systemd you can choose individually for each unit whether you want to
> > allow it to continue run processes on shut down, whether you want the
> > main process killed, the process group to be killed or the cgroup to be
> > killed.
> 
> So in other words... we are going to have a knockdown dragout over
> default unit config for a systemd enabled gdm and for anything that
> allows shell loginsjust not today.

I don't think the will be much fuss about this, as I personally think
that we should continue with the current behaviour here, and support
screen out-of-the-box.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 10:16, Casey Dahlin (cdah...@redhat.com) wrote:

> > Who is "we"?
> > 
> 
> Upstart has about 1.7 developers. The 1 is Scott, myself and Johann Kiviniemi
> fight over the .7.

the bzr history tells a different story.

> 
> > > 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.
> > 
> > Well, how exactly you set up the groups is up to you, but the way we do
> > it in systemd is stick every service in a seperate cgroup, plus every
> > user in a seperate one, too. Some examples:
> 
> > 
> > And so on.
> > 
> 
> Someone else already pointed out the issues here.

Hmm, where?

> > enforcement for your services, since you simply have no cgroups. And no
> > nice interfacing with the other libcgroup tools either.
> 
> There's no reason Upstart couldn't offer cgroups for resource limits, its
> just passed them up as a process supervision mechanism. And they are broken 
> for
> the screen case, though perhaps that could be fixed in the kernel.

They are not broken for the screen case, and there is no fixing in the
kernel necessary.

Scott is simply a bit confused about cgroups, there is no screen problem.

> > Well, for once, it would be nice to judge things due to actually
> > existign features, not of big plans nobody is working on as you
> > apparently admit outright.
> > 
> 
> You worked on it, and finished it. You just didn't do it within Upstart. The
> manpower was there it was just misapplied.

Well, in my blog story I tried to explain why we started anew, instead
of "fixing" Upstart. Won't repeat this here.

> > And then, the socket activtion is nice for various reasons, and
> > lazy-loading is just one of them. The bigger advantage is that it does
> > automatic dependency handling -- which of course is nothign that really
> > fits into upstart's design, since that is based on "events" not
> > dependencies -- events are just broken, as I might note. And adding
> > dependency would turn around upstart's design, making it a completely
> > different beast.
> > 
> 
> Event-driven in Upstart's case just talks about the internal operation of
> Upstart. Its rather exposed in current iterations but its just a design
> philosophy. You can implement "dependencies" within it, though in the past
> Upstart has been hesitant with the term because it tends to imply a
> dependency-solving algorithm, where as Upstart provides its dependencies
> reactively, in response to change.

Ah, if events are hidden from the outside in upcoming versions, then
Upstart will become a completely different beast, and reinvent itself
another time completely. Are you sure Upstart is really ready for use if
every version is a complete redesign of what was before, and a departure
from the core design paradigm that the old versions followed?

> > Yes, really. MacOS could do it, and so can we. Its not that hard. And as
> > I my add here I already hacked up a big part of it now for the servcies
> > we start by default.
> > 
> 
> Good for Apple? Maybe now they can design a better kernel? This is linux. We
> configure our systems here.

Well, no need to shut your eyes that Apple is really good at some
things. We should learn from them where it is a good idea. And here they
are a positive example we can be inspired of.

> > OK, I am listening. What's flawed about systemd? I wrote very detailed
> > explanation why Upstart is just wrong in its core design. Please be so
> > kind and be more specific if you claim the same abotu systemd, because
> > otherwise all you are doing is spreading FUD.
> > 
> 
> Apart from the issue of circular dependencies, which I know you've
> already had
> explained to you, I'd like to see how you intend to manage, say

Circular dependencies? I don't think I heard that from you ever. Please
explain?

I mean, dependencies are dependencies. Whether they are configured manually
or implicitly doesn't have any effect on the fact that they are there or
not there. So if there is a dep loop with systemd in place there is a
dep loop without systemd too.

So please, elaborate on this, and tell me exactly what you mean by this.

> Veritas clustering products. Like it or not there are systems out
> there running software that's unstable, not open source, written by
> people who don't like you, will /never/ take your socket passing patch
> and would probably find clever ways to break or do it wrong if they
> did (yes, because of a 10-line patch).

And, so? They can stay sysv init scripts just fine.

> Upstart doesn't ask anything of the userspace it intends to manage, and that
> userspace is a harsher place than you seem to realize.

Neither do we ask anything. Socket actviation is cool, and a nice way to
make things more robust and faster. But it's an optional
feature. You don't have to use it. We support classic non-socket
activation 

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

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 12:49, Matthew Miller (mat...@mattdm.org) wrote:

> 
> On Wed, May 26, 2010 at 06:39:43PM +0200, drago01 wrote:
> > Again the sysadmin case just implies that something *else* is broken.
> 
> Sure. As a distribution, we don't have control over upstream projects and
> their assumptions for daemon startup, shutdown, status, etc. Sometimes, they
> want odd things.
> 
> > Well if changing over to C does only get rid of this "disease" it
> > would be enough of a gain.
> > It would force broken apps to be fixed, and let admins edit
> > *configuration* files and not source code.
> 
> If you think you can get every open source / free software project to agree
> on completely consistent behavior, or if you can create a text-format config
> file for your compiled daemon handler which handles every unanticipated
> case, well, okay. But it seems unlikely. (And that's not even considering
> running non-free software, which, while something I try to avoid, is a
> reasonable real-world use.)

Well, if we cannot get rid of all shell scripts that is fine. If we can
get rid of 90% of them a lot is achieved already. And to me it looks
much more like > 98% of the scripts that can be removed without
ill-effect if systemd is used.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 09:53, Andrew Parker (andrewpar...@bigfoot.com) wrote:

> >> I couldn't agree more. They need to be scripts, considering how seldom
> >> they actually run it makes even less sense to chase down optimization in
> >> them by making them compiled.
> >
> > -21 million.
> >
> > Scripts are a crutch to avoid properly designed daemons and
> > configuration systems.  I never edit initscripts to "configure"
> > daemons, because they would just be overwritten at the next package
> > upgrade.  Configuration should be separate from code.
> 
> I don't edit them, but I do frequently look at  them to see what
> they're doing/why they aren't doing something/what config files i can
> add/edit to change behaviour etc.
> 
> actually, i do edit them sometimes to add a temporary "-x" to them.
> sure as heck beats gdb.

But the question is whether it beats systemd's kernel opts such as
"systemd.confirm_spawn=" or "systemd.log_level=", which are much more
useful to debug or trace the start-up of services.

And again, nobody said anything of replacing the current shell scripts
with identical equivalents written in C. There will be no shell-to-C
compiler or any such madness.

Lennart

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


Re: tmpfs for strategic directories

2010-05-31 Thread Lennart Poettering
On Sun, 30.05.10 00:38, Xose Vazquez Perez (xose.vazq...@gmail.com) wrote:

> 
> On 05/22/2010 11:06 PM, Lennart Poettering wrote:
> 
> > On Sat, 22.05.10 18:30, Xose Vazquez Perez (xose.vazq...@gmail.com) wrote:
> >
> >>
> >> Is it worth using tmpfs for some directories(/var/run, lock...) ?
> >
> > Yes. But this requires some changes all across the distro, just have a
> > look at the output of "rpm -qf /var/run/*".
> >
> > That said most apps are fixed by now and don't choke when their subdir
> > in /var/run goes away on reboot, since both SUSE and Ubuntu are using
> > tmpfs on /var/run, and have done most of the work. So at this point this
> > should be mostly packaging work (%ghost in .spec files!), not
> > programming work to make /var/run compatible with tmpfs.
> 
> I hope to see it in f14 with upstart, and/or systemd.
> 
> > (And as a side note: systemd by default puts a tmpfs to both /var/run
> > and /var/lock).
> 
> It would be wonderful to see systemd in rawhide, and let people play 
> with it.

To make that happen somebody needs to propose that for F14, and work on
it, and file the necessary bugs. It won't happen on its own.

Anyone wants to pick this up?

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 09:08, Seth Vidal (skvi...@fedoraproject.org) wrote:

> > Scripts are a crutch to avoid properly designed daemons and
> > configuration systems.  I never edit initscripts to "configure"
> > daemons, because they would just be overwritten at the next package
> > upgrade.  Configuration should be separate from code.
> 
> And given my experience dealing with actual real-world designed daemons 
> and other such things, I'd say we've shown no ability to 'properly' design 
> them and won't be showing that anytime soon. So since we have to live in 
> the world, let's not go shooting our feet off.

Well, this sounds like an ad for systemd:

since it is hard to get writing daemons right, we have tought systemd a
lot of tricks so that what you need to do for proper daemonizations is
near to zero. systemd can do a lot of stuff for you, the forking, the
supervising, the dropping of privs, the setting up of a clean working
environment and more. Also, PID files are unnecessary with systemd. In
effect writing a daemon becomes very easy then, because the environment
will be set up completely for you right-away.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 19:54, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote:

> 
> Le mercredi 26 mai 2010 à 19:39 +0200, Alexander Boström a écrit :
> > ons 2010-05-26 klockan 10:01 +0100 skrev James Findley:
> > 
> > > It's really not at all uncommon for me to need to modify an init script. 
> > >   There would be much rage if in order to do this I had to download the 
> > > SRPM, extract the init code, figure out what I needed to change, modify 
> > > it, recompile then install.
> > 
> > Various ways to deal with that:
> > 
> > 1. Change the Exec=/usr/libexec/food to
> > ExecStart=/usr/local/sbin/foodwrapper
> 
> Won't work since one of the main things current scripts do is run some
> code as root, and some other code as the target user.

We already cover for that. You can set "PermissionsStartOnly=yes" in the
.service file. Then, only the program specified in ExecStart= will be
started with reduced permissions (i.e. with dropped priviliges, reduced
caps, yadda yadda), and everything in ExecStartPre= and friends will run
as normal root user.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 19:39, Alexander Boström (a...@root.snowtree.se) wrote:

> 
> ons 2010-05-26 klockan 10:01 +0100 skrev James Findley:
> 
> > It's really not at all uncommon for me to need to modify an init script. 
> >   There would be much rage if in order to do this I had to download the 
> > SRPM, extract the init code, figure out what I needed to change, modify 
> > it, recompile then install.
> 
> Various ways to deal with that:
> 
> 1. Change the Exec=/usr/libexec/food to
> ExecStart=/usr/local/sbin/foodwrapper

Yes, that works well.

> 
> 2. Add some hook support in the systemd config files.

We actually have that in place already. You can hook in as many shell
scripts as you want, like this:

ExecStartPre=/some/shell/script/to/run/before/the/daemon
ExecStartPost=/some/shell/script/to/run/after/the/daemon
ExecStopPre=...
ExecStopPost=...

> 3. Add support for switching specific services back to using the
> initscript even when booting with systemd.

You can easily do that, simply by renaming the .service file.

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)

2010-05-31 Thread Lennart Poettering
On Thu, 27.05.10 10:13, Chris Adams (cmad...@hiwaay.net) wrote:

> 
> Once upon a time, Kevin Kofler  said:
> > Editing the code is the wrong way to make "simple local changes".
> 
> That is only true if you can anticipate every task every system admin
> will ever need to do with your tools.
> 
> I've edited init scripts for multiple reasons.  For example, I have
> multiple instances of some daemons running, so I'll make multiple copies
> of the init script and edit as needed for config/PID file locations,
> etc.

Just because we want to do more stuff in C then in shell it doesnt mean
things become less editable or configurable. So, when you previously
edited the init script, you can now edit the (much shorter and simpler)
.service file, adjusting the various options it offers you. If you
previously maintained a modified copy of an existing init script, you
can now just have a modified copy of a .service file. There's really
nothing that changes here.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 14:57, Emmanuel Seyman (emmanuel.sey...@club-internet.fr) 
wrote:

> 
> * Ola Thoresen [26/05/2010 14:39] :
> >
> > Would it not be more fruitful to discuss _why_ you (we?) need to edit 
> > the initscripts?  Describe what functionality is missing or wrong in the 
> > default ones?
> 
> Editing environnement variables and indicating which specific interfaces
> I want the daemon to listen on for requests are the only real-world
> cases that come to my mind straight away.

You can just edit the .service file instead. I'd even argue that editing
a .service file is much nicer than editing a shell script, simply
because it is shorter and seperates control flow from configuration.

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)

2010-05-31 Thread Lennart Poettering
On Thu, 27.05.10 07:15, Matthew Miller (mat...@mattdm.org) wrote:

> 
> On Thu, May 27, 2010 at 10:10:35AM +0200, Harald Hoyer wrote:
> > We mainly speek about rc.sysinit, which most of you don't touch, because it 
> > would be overwritten the next initscripts update anyway.
> 
> I would never touch it with a permanent change, but I definitely make
> debugging changes to it often enough. That's not down to it being a shell
> script though; it's because it's a crufty mess.

Two things:

if we replace stuff like sysinit by proper C code things become less
fragile and hence you need to debug less.

and secondly, bash is actually a pretty shitty debugger, especially when
there are a lot of scripts running in parallel. For debugging purposes
we should offer better tools, and some of that we already implemneted:
if you pass "systemd.confirm_spawn=1" on the kernel command line you
have the option to single-step through a serialized startup. Tools like
that I believe are much more appropriate for debugging the startup
process.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 14:08, Jon Masters (jonat...@jonmasters.org) wrote:

> > I couldn't agree more. They need to be scripts, considering how seldom 
> > they actually run it makes even less sense to chase down optimization in 
> > them by making them compiled.
> 
> I *very* strongly agree also. I do change init scripts, but even more
> than this, I see a growing trend for Linux systems to be less friendly
> to user modification. We are not so smart that we should do this.

Well, we won't take anything away from you:

if we add an option to systemd itself, for something that was previously
done manually in the init script, then this is just that: an option you
can configure as much as you want, simply by editing the .service file.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 17:41, Bill Nottingham (nott...@redhat.com) wrote:

> 
> James Findley (s...@gmx.com) said: 
> > Actually the blog post is proposing exactly that, as I read it.  And it 
> > seems not only that lots of other people read it the same way, but some 
> > even agree with it.
> > 
> > So I'm not sure I see how this is going off into the weeds - if 
> > transitioning some/all initscripts to C is a genuine goal of the author 
> > of the project, on which he is not prepared to budge, then that is 
> > likely to have bearing on its adoption into fedora, and rightly so.
> 
> What I took from it is that code like this from rc.sysinit:
> 
> ...
> if [ ! -e /proc/mounts ]; then
> mount -n -t proc /proc /proc
> mount -n -t sysfs /sys /sys >/dev/null 2>&1
> fi
> ...
> 
> really doesn't need to be there. If you're redesigning the init system,
> rather than keeping compatibility with ancient stupid sysvinit, there's
> no reason that shell code is needed for this; init should Just Do It when
> it starts. In fact, I'm pretty sure recent upstart releases do the same
> thing. I'm sure we can find more examples if we look.

Yes, this is exactly what I meant.

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)

2010-05-31 Thread Lennart Poettering
On Wed, 26.05.10 15:42, James Findley (s...@gmx.com) wrote:

> > It is completely clear that there needs to be some flexibility in any
> > init system to cater to real-world services.
> >
> > But it is also clear that there is a difference between gobs of shell
> > script and nice and clean files like the ones you find in /etc/init.
> 
> 
> Actually the blog post is proposing exactly that, as I read it.  And it 
> seems not only that lots of other people read it the same way, but some 
> even agree with it.

No, this is not what is meant.

So, the plan is (and much of this is actually implemented already) is to
go through /etc/init.d and similar directories, and look at every script
individually. Then, figure out the common parts, and see if we can
perhaps implement that elsewhere and in C at some other place.

Example: /etc/rc.sysinit mounts a lot of API filesystems (such as /proc,
/sys, /dev). We can do that already in the init system, very early
during boot, in C. If we do this (and we did) the code is much shorter,
and nicer, and does not require forking or anything.

Another example: /etc/init.d/autofs loads the autofs4 module and sets up
permissions on /dev/autofs. Wouldn't it be nicer if this would be done
outside of a shell script? And so we decided to do that and moved this
into udev and module-init-tools: instead of loading the module manually
and setting up the device nodes manually we just create the device nodes
in advance and apply permissions to it via udev rules (like any other
device node) and then autoload the autofs module on first access. (and
this has already hit rawhide by now iirc)

Another example: /etc/init.d/btseed and .../bttrack include some
amazingly evil code to fake daemonization of a process with & and
disown, as well as privilege dropping in shell. We can cover that much
nicer in systemd, and provide the right and clean daemonization it needs
out of the box. And so we added just that to systemd itself. (i.e. there
is a User= and option in the .service files and a Type= option that
allows you to tell systemd to do the necessary daemonization properly.)

And a fourth example: if you look at /etc/init.d/cups you'll find some
code in there that tries to make sure that sun RPC doesn't take away the
CUPS port numbers. (It also retriggers the printers in the udev sysfs
tree, which seems to be very wrong, i really wonder what that is
for. Anybody please enlighten me?) But the port number issue can easily
be fixed by systemd allocating the port number right-away, and this we
can easily cover in plain C in systemd itself via .socket units. And
that's what we did.

So, in summary: we go through the shell scripts and figure out
piece-by-pice whether we can find a better, perhaps more generic place for
it. And the right place could vary: it could be systemd itself (maybe a
new option in .service is sufficient, like the Type= or User= option
mentioned above) or udev or module-init-tools, or
in the daemon code itself. 

And suddenly, after you did this you notice that in those shell scripts
the only thing that remains is boilerplate code, more often than not
just the simple code copied 1:1 from the fedora reference init
script. And the boilerplate code is redundant if you use native .service
files.

So, there are no plans at all to replace the shell scripts 1:1 with
their equivalents written in C. There will not be a shell-to-C compiler
or anything like that. What we want to do (and already did for quite a
few daemons now), is to replace many of the shell hacks by C code at
better, more generic places of basic OS.

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: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.

2010-05-31 Thread Ryan Rix
On Mon 31 May 2010 1:55:26 pm Paul Wouters wrote:
> since that's the preference
> of the maintainer, which violates fedora packagaging policies

Then a provenpackager should fix it regardless of whether the maintainer "is 
too busy to fix it." and even then, they shouldn't be maintaining packages 
they are too busy to fix! That's just as bad as blatently refusing to fix 
this issue.

-- 
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word ==


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: Fedora rawhide FTBFS status 2010-05-27 x86_64

2010-05-31 Thread Till Maas
On Mon, May 31, 2010 at 04:11:25PM -0500, Matt Domsch wrote:

> Doh.  This is a result of using tmpfs for the buildroots.  There are a
> few such failures, which I'll rebuild in the next run w/o using tmpfs.
> Odd, as using tmpfs should have started overflowing into swap, which
> doesn't appear to have happened.

The way the tmpfs plugin for mock on F12 is written and the way it was
used in the rebuild, it will only provide a filesystem with half the RAM
size as available space. The only way to change this on F12 is to
manually patch /usr/lib/python2.6/site-packages/mock/plugins/tmpfs.py
and add  "-o", "size=Xg" to mountCmd to provide X gigabytes of space.

Regards
Till


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

Re: Fedora rawhide FTBFS status 2010-05-27 i386

2010-05-31 Thread Orcan Ogetbil
On Mon, May 31, 2010 at 5:31 PM, Matt Domsch wrote:
> On Mon, May 31, 2010 at 09:58:12PM +0100, Mat Booth wrote:
>> On 31 May 2010 18:44, Matt Domsch wrote:
>> >
>> > xerces-j2-2.9.0-3.fc13 (build/make) mbooth
>>
>>
>> What do I need to do if a scratch build for rawhide succeeds?
>>
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=2220859
>
> Nothing for now.  I'm rebuilding all the failed builds, w/o using
> tmpfs for buildroot.  If that clears up the problem, I won't file bugs
> against your packages.
>

Please also rebuild the pkgconfig segfaulted builds (see the issue
Mamoru pointed out) too if possible. I don't know how many there are
overall but I have at least two such failures (ardour,
fluidsynth-dssi).

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

Re: Fedora rawhide FTBFS status 2010-05-27 i386

2010-05-31 Thread Matt Domsch
On Mon, May 31, 2010 at 09:58:12PM +0100, Mat Booth wrote:
> On 31 May 2010 18:44, Matt Domsch  wrote:
> >
> > xerces-j2-2.9.0-3.fc13 (build/make) mbooth
> 
> 
> What do I need to do if a scratch build for rawhide succeeds?
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2220859

Nothing for now.  I'm rebuilding all the failed builds, w/o using
tmpfs for buildroot.  If that clears up the problem, I won't file bugs
against your packages.

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Fedora rawhide FTBFS status 2010-05-27 x86_64

2010-05-31 Thread Matt Domsch
On Mon, May 31, 2010 at 03:54:53PM -0400, Braden McDaniel wrote:
> On Mon, 2010-05-31 at 12:43 -0500, Matt Domsch wrote:
> Fedora Fails To Build From Source Results for x86_64
> > using rawhide from 2010-05-27
> > 
> > This is a full rebuild, the first for Fedora 14's rawhide.  The
> > builders all have Fedora 13 installed.
> > 
> > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
> 
> This seems to be diagnosing a good deal more than broken
> BuildRequires...

Yep.  Over the past 4 years I've been doing this, it's grown to detect
quite a few failure modes; broken BuildRequires was only the first of
the tests implemented.  I just never changed the directory name. :-)

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel



Re: Fedora rawhide FTBFS status 2010-05-27 x86_64

2010-05-31 Thread Matt Domsch
On Mon, May 31, 2010 at 06:53:41PM +0100, Peter Robinson wrote:
> On Mon, May 31, 2010 at 6:51 PM, Dan Hor??k  wrote:
> > Matt Domsch pe v Po 31. 05. 2010 v 12:43 -0500:
> >> Fedora Fails To Build From Source Results for x86_64
> >> using rawhide from 2010-05-27
> >>
> And there are a number of packages of mine listed there that I have
> built fine in rawhide in the last couple of days.

that's fine and expected.  When I file bugs, I intentionally exclude
packages that have been built in rawhide since I started my run.
Unfortunately, my run takes a few days (~30 hours for the first pass,
and ~12 hours for each of the next 2 passes to try those that have
failed earlier - I'm only sending notes about those that still
remain).  I need to see about not reporting in this email those
packages that have succeeded in koji since I took my rawhide snapshot
to start with...

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Fedora rawhide FTBFS status 2010-05-27 x86_64

2010-05-31 Thread Matt Domsch
On Mon, May 31, 2010 at 07:51:52PM +0200, Dan Hor?k wrote:
> Matt Domsch pe v Po 31. 05. 2010 v 12:43 -0500: 
> > Fedora Fails To Build From Source Results for x86_64
> > using rawhide from 2010-05-27
> > 
> > This is a full rebuild, the first for Fedora 14's rawhide.  The
> > builders all have Fedora 13 installed.
> > 
> > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
> 
> Matt, there can be false positives, please check the logs for "no space
> left on device", it happened at least for codeblocks.

Doh.  This is a result of using tmpfs for the buildroots.  There are a
few such failures, which I'll rebuild in the next run w/o using tmpfs.
Odd, as using tmpfs should have started overflowing into swap, which
doesn't appear to have happened.

Sorry for the noise.

i386 builds:
boost-1.41.0-10.fc14.src.rpm
gcompris-9.3-1.fc14.src.rpm
ghc-6.12.2-1.fc14.src.rpm
java-1.6.0-openjdk-1.6.0.0-37.b17.fc13.src.rpm
kdeedu-4.4.80-1.fc14.src.rpm
kde-l10n-4.4.3-1.fc14.src.rpm
libguestfs-1.3.16-6.fc14.src.rpm
mingw32-qt-4.6.2-1.fc14.src.rpm
plplot-5.9.5-7.fc13.src.rpm
ppl-0.10.2-10.fc12.src.rpm
qemu-0.12.3-6.fc14.src.rpm
QuantLib-1.0.1-3.fc14.src.rpm
spicebird-0.7.1-1.fc11.src.rpm
thunderbird-3.0.4-3.fc14.src.rpm
vegastrike-data-0.5.0-5.src.rpm
xulrunner-1.9.2.3-1.fc14.src.rpm


x86_64 builds:
asio-1.4.1-2.fc12.src.rpm
boost-1.41.0-10.fc14.src.rpm
ceph-0.20-1.fc14.src.rpm
codeblocks-8.02-10.fc13.src.rpm
eclipse-emf-2.5.0-4.fc12.src.rpm
ember-0.5.6-4.fc13.src.rpm
gcompris-9.3-1.fc14.src.rpm
gnash-0.8.7-1.fc14.src.rpm
java-1.6.0-openjdk-1.6.0.0-37.b17.fc13.src.rpm
kde-i18n-3.5.10-12.fc13.src.rpm
kde-l10n-4.4.3-1.fc14.src.rpm
kdelibs3-3.5.10-23.fc13.src.rpm
kdenetwork-4.4.80-1.fc14.src.rpm
koffice-2.2.0-1.fc14.src.rpm
libguestfs-1.3.16-6.fc14.src.rpm
llvm-2.7-3.fc14.src.rpm
lordsawar-0.1.7-1.fc14.src.rpm
mingw32-qt-4.6.2-1.fc14.src.rpm
openarena-0.8.5-1.fc13.src.rpm
OpenSceneGraph-2.8.2-3.fc12.src.rpm
PyQt4-4.7.3-2.fc14.src.rpm
qt-4.7.0-0.14.beta1.fc14.src.rpm
QuantLib-1.0.1-3.fc14.src.rpm
seamonkey-2.0.4-1.fc14.src.rpm
spicebird-0.7.1-1.fc11.src.rpm
sunbird-1.0-0.21.20090916hg.fc14.src.rpm
warzone2100-2.3.0-1.fc14.src.rpm
webkitgtk-1.2.0-1.fc14.src.rpm
xulrunner-1.9.2.3-1.fc14.src.rpm


-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Fedora rawhide FTBFS status 2010-05-27 i386

2010-05-31 Thread Mat Booth
On 31 May 2010 18:44, Matt Domsch  wrote:
>
> xerces-j2-2.9.0-3.fc13 (build/make) mbooth


What do I need to do if a scratch build for rawhide succeeds?

http://koji.fedoraproject.org/koji/taskinfo?taskID=2220859


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


Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.

2010-05-31 Thread Paul Wouters
On Mon, 31 May 2010, Ryan Rix wrote:

> Airing out our dirty laundry for our users to see is not something that we
> should allow or promote. I'm all for reporting errors, but b*tching to
> users? No. I'm going to file a bug on this if someone else has not.

It's been filed many times, duplicated many times, closed many times.

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

I am sure there are more instances of reporting this bug.

Fixing init scripts and %post is now left in the state "maintainer is too
busy to fix". In the past I already offered co-maintainership or taking
over the package due to my close relationship with upstream. It's a lame
excuse for leaving it in the current state, since that's the preference
of the maintainer, which violates fedora packagaging policies.

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


Re: Fedora rawhide FTBFS status 2010-05-27 x86_64

2010-05-31 Thread Braden McDaniel
On Mon, 2010-05-31 at 12:43 -0500, Matt Domsch wrote:
Fedora Fails To Build From Source Results for x86_64
> using rawhide from 2010-05-27
> 
> This is a full rebuild, the first for Fedora 14's rawhide.  The
> builders all have Fedora 13 installed.
> 
> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/

This seems to be diagnosing a good deal more than broken
BuildRequires...

> openvrml-0.18.5-2.fc14 (build/make) braden

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I../src/libopenvrml 
-I../src/libopenvrml -I../src/local/libopenvrml-dl 
-DOPENVRML_LIBDIR_=\"/usr/lib64\" 
-DOPENVRML_PKGDATADIR_=\"/usr/share/openvrml\" 
-DOPENVRML_PKGLIBDIR_=\"/usr/lib64/openvrml\" 
-DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_VECTOR_SIZE=30 
-I/usr/lib/jvm/java/include -I/usr/lib/jvm/java/include/linux -DNDEBUG 
-I/usr/include/freetype2 -pthread -I/usr/include/libxml2 -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic -fvisibility=hidden 
-fvisibility-inlines-hidden -Wno-missing-braces -Wno-strict-aliasing 
-Wno-unused-variable -c libopenvrml/openvrml/script.cpp  -fPIC -DPIC -o 
libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-script.o
{standard input}: Assembler messages:
{standard input}:71597: Warning: end of file not at end of a line; newline 
inserted
{standard input}:72206: Error: expected comma after name 
`_ZNK5boost6spirit7classic16assertive_parserIN8openvrml16vrml_parse_errorENS1_14functor_parserINS3_12int32_parser5parseINS1_7scannerINS1_10multi_passISt19istreambuf_iteratorIcSt11char_traitsIcEENS1_19multi_pass_policies14input'
 in .size directive
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See  for instructions.

Ouch.  I'm not sure if this is Random Badness or not; but i386 failed,
too; so maybe it's the same thing.  Nope.  While it *might* have the
same problem, i386 didn't get past configure:

checking for GIO... ./configure: line 21460: 19388 Segmentation fault   
   (core dumped) ( $PKG_CONFIG --exists --print-errors "gio-2.0" ) 2>&5
./configure: line 21476: 19392 Segmentation fault  (core dumped) ( 
$PKG_CONFIG --exists --print-errors "gio-2.0" ) 2>&5
no

Well, that's... interesting.

If there were disc space issues (as Dan Horák suggests), that could
result in some rather exotic errors.

-- 
Braden McDaniel 

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

Re: Fedora rawhide FTBFS status 2010-05-27 i386

2010-05-31 Thread Ville Skyttä
On Monday 31 May 2010, Matt Domsch wrote:

> javasqlite-20100131-1.fc13 (build/make) scop

https://bugzilla.redhat.com/show_bug.cgi?id=598221
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.

2010-05-31 Thread Ryan Rix
On Sat 29 May 2010 11:10:35 pm Matthew Miller wrote:
> And this one is: packages should not print out messages complaining about
> the state of other packages in Fedora. That's not the right process for
> solving those issues. If redhat-lsb is broken, there's a procedure for
> dealing with that, and it isn't "give confusing warnings to the end
> users!"

+1

Airing out our dirty laundry for our users to see is not something that we 
should allow or promote. I'm all for reporting errors, but b*tching to 
users? No. I'm going to file a bug on this if someone else has not.

It's pretty non-excellent of this package's maintainer, but judging by his 
previous actions I am not surprised. He has shown in the past that he has no 
qualms with breaking the "be excellent to eachother" rule.

Ryan

-- 
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word ==


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: Fedora rawhide FTBFS status 2010-05-27 x86_64

2010-05-31 Thread Toshio Kuratomi
I updated python-sphinx in rawhide this morning to fix the issue seen here::

http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/bzr-2.2-0.5.b1.fc14.src.rpm/result/build.log

sphinx-build -b html -d _build/doctrees   . _build/html
Running Sphinx v1.0b1
loading translations [es]... done
loading pickled environment... not yet created
building [html]: targets for 4 source files that are out of date
updating environment: 4 added, 0 changed, 0 removed
reading sources... [ 25%] index
reading sources... [ 50%] mini-tutorial/index
reading sources... [ 75%] quick-reference/index
reading sources... [100%] user-guide/index
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [ 25%] index
Exception occurred:
  File "/usr/lib/python2.6/site-packages/sphinx/writers/html.py", line 482, in 
depart_title
_('Permalink to this headline'))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 34: 
ordinal not in range(128)


This can occur if your package uses python-sphinx to build documentation
*and* the package is building documentation in a language that is translated
in sphinx.  I doubt that this is a large number of packages but I thought
I should mention it in case other people see it too.

-Toshio


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

Re: Fedora rawhide FTBFS status 2010-05-27 i386

2010-05-31 Thread Mamoru Tasaka
Nathanael D. Noblet wrote, at 06/01/2010 03:03 AM +9:00:
> On 05/31/2010 11:44 AM, Matt Domsch wrote:
>> Fedora Fails To Build From Source Results for i386
>> using rawhide from 2010-05-27
>>
>> This is a full rebuild, the first for Fedora 14's rawhide.  The
>> builders all have Fedora 13 installed.
>>
>> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
>
>> barry-0.17-0.1.20100329git.fc14 (build/make) quantumburnz,gnat
>
>
> Looking at the build logs
>
> In file included from BackupWindow.cc:22:
> BackupWindow.h:22:19: error: gtkmm.h: No such file or directory
> BackupWindow.h:23:24: error: libglademm.h: No such file or directory
>
> It seems that it is missing gtkmm24-devel and a few other of the
> required BuildRequires that are in the spec. Its a bit odd since it only
> fails to build on i386... x86_64 no FTBFS...
>
> Ideas?
>

Well, from
http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/pkgconfig-0.24-5.fc14.src.rpm/
maybe pkgconfig-0.24-5.fc14 is used for this build test. This pkgconfig
can cause segfault somewhat easily, so if build uses the result of "pkg-config 
--cflags"
(and when pkg-config segfaults), needed header files cannot be included and
build can fail.
This issue is fixed in -6.fc14 and the newest pkgconfig is 0.25-1.fc14 (see 
changelog).

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


Re: Fedora rawhide FTBFS status 2010-05-27 i386

2010-05-31 Thread Nathanael D. Noblet
On 05/31/2010 12:03 PM, Nathanael D. Noblet wrote:
> Looking at the build logs
>
> In file included from BackupWindow.cc:22:
> BackupWindow.h:22:19: error: gtkmm.h: No such file or directory
> BackupWindow.h:23:24: error: libglademm.h: No such file or directory
>
> It seems that it is missing gtkmm24-devel and a few other of the
> required BuildRequires that are in the spec. Its a bit odd since it only
> fails to build on i386... x86_64 no FTBFS...
>
> Ideas?
>

Also a mock build for both arches completes successfully...

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


Re: Fedora rawhide FTBFS status 2010-05-27 i386

2010-05-31 Thread Nathanael D. Noblet
On 05/31/2010 11:44 AM, Matt Domsch wrote:
> Fedora Fails To Build From Source Results for i386
> using rawhide from 2010-05-27
>
> This is a full rebuild, the first for Fedora 14's rawhide.  The
> builders all have Fedora 13 installed.
>
> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/

> barry-0.17-0.1.20100329git.fc14 (build/make) quantumburnz,gnat


Looking at the build logs

In file included from BackupWindow.cc:22:
BackupWindow.h:22:19: error: gtkmm.h: No such file or directory
BackupWindow.h:23:24: error: libglademm.h: No such file or directory

It seems that it is missing gtkmm24-devel and a few other of the 
required BuildRequires that are in the spec. Its a bit odd since it only 
fails to build on i386... x86_64 no FTBFS...

Ideas?

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


Re: libjpeg for F14

2010-05-31 Thread Ilyes Gouta
Hi Adam,

> it also contains bunch of
> pure algorithmic enhancements so even if target platform doesn't
> support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg.

Can you please give some details on this point?

-Ilyes Gouta

On Mon, May 31, 2010 at 4:33 PM, Adam Tkac  wrote:
> 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.
>
> This is pretty big issue.
>
>> 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.
>
> Sorry for late response, this mail got lost in my queue.
>
> libjpeg-turbo is a fork of the original libjpeg-6b release created
> and maintained by VirtualGL and TigerVNC developers. Main focus is on
> performance and API+ABI compatibility with libjpeg. Although
> libjpeg-turbo contains MMX/SSE acceleration it also contains bunch of
> pure algorithmic enhancements so even if target platform doesn't
> support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg.
> When SSE is used then libjpeg and libjpeg-turbo performance is simply
> incomparable. And there are still number of areas for optimizations,
> for example on we are currently using only half of SSE registers on
> 64bit platforms.
>
> About the merge of this code with the original ijg's code. Yes, I must
> admit it is possible but personally I don't like it much. In my
> opinion libjpeg-turbo is far more ahead than libjpeg so it's easier
> for us to incorporate libjpeg changes to libjpeg-turbo. And I'm not
> able to find CVS/SVN/git repository of the libjpeg code.
>
> In my opinion if will be great benefit for Fedora to simply replace
> libjpeg by libjpeg-turbo. It works fine on secondary architectures
> and if processor doesn't support MMX/SSE then it falls back to
> non-ASM code (which is still faster than libjpeg code, as I wrote
> above).
>
> Btw this library is used since Fedora 11 in tigervnc package for JPEG
> compression/decompression and it works without any problem on all
> supported platforms (x86, x86_64, ppc, ppc64) and also on s390(x).
>
> So, if I summarize pros and cons for libjpeg-turbo:
>
> +: _really_ faster than libjpeg
>   more portable
>   more open than IJG code
>   API/ABI compatible with libjpeg (AFAIK)
>   works on all platforms (not only on SSE capable platforms)
>
> -: not developed by IJG :)
>
> I'm going to create a Fedora feature for this task.
>
> Regards, Adam
>
> --
> Adam Tkac, Red Hat, Inc.
> --
> 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: cpio: Bad magic

2010-05-31 Thread Harry Rickards
On 31 May 2010 18:49, Panu Matilainen  wrote:
> On Mon, 31 May 2010, Harry Rickards wrote:
>
>> Hi,
>>
>> When building my package with rpmbuild, I'm getting the following error:
>>
>> error: create archive failed on file
>> /builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3/AUTHORS:
>> cpio: Bad magic
>>
>> I've tried reinstalling cpio and glibc, and I've got enough space
>> left. I can view AUTHORS fine with cat, and even compress it with
>> cpio. The strange part is, this error also occurs when using koji -
>> see the build log at
>> http://koji.fedoraproject.org/koji/getfile?taskID=2220058&name=build.log.
>>
>> The source rpm is at
>> http://hotfile.com/dl/45779573/83852f4/lives-1.3.3-1.fc13.src.rpm.html.
>>
>> Any help is appreciated!
>
> The error message is wonderfully obscure, but the actual problem is here:
>
> Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.XGPmZR
> + umask 022
> + cd /builddir/build/BUILD
> + cd lives-1.3.3
> +
> DOCDIR=/builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3
> + export DOCDIR
> + rm -rf
> /builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3
> + /bin/mkdir -p
> /builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3
> + cp -pr avi_encoder.py.1 build-lives-rfx-plugin.1
> build-lives-rfx-plugin-multi.1 dirac_encoder.py.1 gif_encoder.py.1 lives.1
> mkv_encoder.py.1 mng_encoder.py.1 ogm_encoder.py.1 smogrify.1
> theora_encoder.py.1
> /builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3
> + exit 0
>
> %doc wipes out anything else in the doc directory, in this case AUTHORS
> and probably something else too, so when rpm tries to put the files into
> the cpio archive it fails because the files don't exist. You need to use
> either %doc or manual directory ownership of the doc directory, you can't
> mix them.
>
> And of course the whole thing is just stupid behavior from rpm, the only
> excuse for this is "it's always been like that"...
>


Thanks for finding the problem! In the wiki, at
http://fedoraproject.org/wiki/How_to_create_an_RPM_package#.25files_prefixes,
it does talk about this problem but doesn't anywhere say that it comes
up with this error. I'm very new to Fedora packaging so probably not
the best person to do it, but would someone be able to update the wiki
to say that this 'gotcha' creates a cpio bad magic error?

Thanks


-- 
Harry Rickards - ha...@linux.com
Vote Lib Dem - Building a fairer Britain - http://libdems.org.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Fedora rawhide FTBFS status 2010-05-27 x86_64

2010-05-31 Thread Peter Robinson
On Mon, May 31, 2010 at 6:51 PM, Dan Horák  wrote:
> Matt Domsch píše v Po 31. 05. 2010 v 12:43 -0500:
>> Fedora Fails To Build From Source Results for x86_64
>> using rawhide from 2010-05-27
>>
>> This is a full rebuild, the first for Fedora 14's rawhide.  The
>> builders all have Fedora 13 installed.
>>
>> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
>
> Matt, there can be false positives, please check the logs for "no space
> left on device", it happened at least for codeblocks.

And there are a number of packages of mine listed there that I have
built fine in rawhide in the last couple of days.

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

Re: Fedora rawhide FTBFS status 2010-05-27 x86_64

2010-05-31 Thread Dan Horák
Matt Domsch píše v Po 31. 05. 2010 v 12:43 -0500: 
> Fedora Fails To Build From Source Results for x86_64
> using rawhide from 2010-05-27
> 
> This is a full rebuild, the first for Fedora 14's rawhide.  The
> builders all have Fedora 13 installed.
> 
> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/

Matt, there can be false positives, please check the logs for "no space
left on device", it happened at least for codeblocks.


Dan


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

Re: cpio: Bad magic

2010-05-31 Thread Panu Matilainen
On Mon, 31 May 2010, Harry Rickards wrote:

> Hi,
>
> When building my package with rpmbuild, I'm getting the following error:
>
> error: create archive failed on file
> /builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3/AUTHORS:
> cpio: Bad magic
>
> I've tried reinstalling cpio and glibc, and I've got enough space
> left. I can view AUTHORS fine with cat, and even compress it with
> cpio. The strange part is, this error also occurs when using koji -
> see the build log at
> http://koji.fedoraproject.org/koji/getfile?taskID=2220058&name=build.log.
>
> The source rpm is at
> http://hotfile.com/dl/45779573/83852f4/lives-1.3.3-1.fc13.src.rpm.html.
>
> Any help is appreciated!

The error message is wonderfully obscure, but the actual problem is here:

Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.XGPmZR
+ umask 022
+ cd /builddir/build/BUILD
+ cd lives-1.3.3
+ 
DOCDIR=/builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3
+ export DOCDIR
+ rm -rf 
/builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3
+ /bin/mkdir -p 
/builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3
+ cp -pr avi_encoder.py.1 build-lives-rfx-plugin.1 
build-lives-rfx-plugin-multi.1 dirac_encoder.py.1 gif_encoder.py.1 lives.1 
mkv_encoder.py.1 mng_encoder.py.1 ogm_encoder.py.1 smogrify.1 
theora_encoder.py.1 
/builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3
+ exit 0

%doc wipes out anything else in the doc directory, in this case AUTHORS 
and probably something else too, so when rpm tries to put the files into 
the cpio archive it fails because the files don't exist. You need to use 
either %doc or manual directory ownership of the doc directory, you can't 
mix them.

And of course the whole thing is just stupid behavior from rpm, the only 
excuse for this is "it's always been like that"...

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


Fedora rawhide FTBFS status 2010-05-27 i386

2010-05-31 Thread Matt Domsch
Fedora Fails To Build From Source Results for i386
using rawhide from 2010-05-27

This is a full rebuild, the first for Fedora 14's rawhide.  The
builders all have Fedora 13 installed.

Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/


51 Open Bugs which now build, and can be marked CLOSED RAWHIDE:
apanov-heuristica-fonts: [u'565136']
audex: [u'555453']
btrfs-progs: [u'565112']
cairo-clock: [u'564959']
clisp: [u'539088']
clutter-gtk: [u'539122']
collectd: [u'564943']
comedilib: [u'555459']
dbxml-perl: [u'555452']
dbxml: [u'555494']
eboard: [u'565137']
fedora-security-guide-en-US: [u'538934']
fence-virt: [u'565111']
florence: [u'564675']
gdm: [u'539144']
ghostscript-fonts: [u'565206']
gnome-netstatus: [u'564852']
griv: [u'565081']
harminv: [u'565036']
hdf: [u'538896']
healpy: [u'564726']
itpp: [u'565156']
keepassx: [u'539011']
krb5-auth-dialog: [u'555498']
kst: [u'539056']
libvirt-qpid: [u'565139']
mpqc: [u'565030']
openwsman: [u'564916']
paperbox: [u'564997']
perl-HTML-FormFu-Model-DBIC: [u'564664']
plexus-appserver: [u'564825']
plexus-bsh-factory: [u'564981']
plexus-xmlrpc: [u'564880']
PySBIG: [u'565051']
python-krbV: [u'555442']
python-nss: [u'565044']
razertool: [u'564813']
rpm: [u'565223']
schroot: [u'564770']
scitools: [u'564781']
showimg: [u'539025']
springlobby: [u'564795']
subversion-api-docs: [u'538966']
synce-kde: [u'539195']
synce-trayicon: [u'564881']
tasque: [u'539146']
tex-musixtex: [u'564757']
UnihanDb: [u'538948']
virt-ctrl: [u'538891']
xca: [u'565073']
zfs-fuse: [u'565076']

Total packages: 9285
Number failed to build: 672
Number expected to fail due to ExclusiveArch or ExcludeArch: 17
Leaving:  655

Of those expected to have worked...
Without a bug filed: 536
--
AcetoneISO2-2.2.1-2.fc13 (build/make) spot
ConsoleKit-0.4.1-5.fc13 (build/make) mccann
Django-1.2.1-1.fc14 (build/make) smilner,dmalcolm,salimma,smilner
E-1.0.002-4.fc11 (build/make) dwheeler
GConf2-2.31.3-1.fc14 (build/make) rstrode,walters
GtkAda-2.14.0-4.fc13 (build/make) gemi,rombobeorn
NetworkManager-0.8.1-0.1.git20100510.fc14 (build/make) dcbw,dcbw
ORBit2-2.14.18-1.fc14 (build/make) mclasen
OpenGTL-0.9.13-1.fc13 (build/make) rdieter
OpenSceneGraph-2.8.2-3.fc12 (build/make) corsepiu
PyQt4-4.7.3-2.fc14 (build/make) rdieter,dmalcolm,than
QuantLib-1.0.1-3.fc14 (build/make) spot
R-BSgenome-1.14.2-1.fc12 (build/make) pingou
R-BSgenome.Celegans.UCSC.ce2-1.3.16-1.fc13 (build/make) pingou
R-Biostrings-2.14.12-1.fc14 (build/make) pingou
R-IRanges-1.4.16-1.fc14 (build/make) pingou
R-RScaLAPACK-0.6.1-2.fc14 (build/make) spot
Thunar-1.0.2-1.fc14 (build/make) kevin,cwickert,pertusus
TnL-07-12.fc13 (build/make) jwrdegoede
TurboGears-1.0.9-3.fc13 (build/make) lmacken,fschwarz,toshio
abiword-2.8.4-1.fc14 (build/make) uwog
adonthell-0.3.5-0.8.fc12 (build/make) bochecha
aiksaurus-1.2.1-21.fc12 (build/make) uwog
aimage-3.2.4-1.fc13 (build/make) kwizart
airsnort-0.2.7e-15.fc12 (build/make) awjb
alltray-0.70-5.fc13 (build/make) sundaram,huzaifas,luceliofreitas
almanah-0.7.3-1.fc14 (build/make) th0br0
amarok-2.3.0.90-1.fc14 (build/make) rdieter,kaboon,rdieter,thomasj,tuxbrewr
apache-commons-exec-1.0.1-2.fc13 (build/make) melmorabity
ardour-2.8.7-1.fc13 (build/make) green,jwrdegoede,oget
asterisk-sounds-core-1.4.16-3.fc13 (build/make) jcollie,itamarjp
asunder-1.9.3-1.fc14 (build/make) szpak
atlas-3.8.3-15.fc13 (build/make) deji,deji
audacious-plugin-fc-0.4-3 (build/make) mschwendt
audacity-1.3.11-0.1.beta.fc13 (build/make) gemi,dtimms
autofs-5.0.5-27.fc14 (build/make) jmoyer,iankent
avahi-0.6.25-7.fc14 (build/make) lennart,lennart
bacula-5.0.1-1.fc14 (build/make) 
ixs,dnovotny,fschwarz,jgorig,kanarip,limb,mmcgrath,rvokal
bakery-2.6.3-4.fc14 (build/make) hguemar
balsa-2.4.7-2.fc14 (build/make) pawsa
barry-0.17-0.1.20100329git.fc14 (build/make) quantumburnz,gnat
beagle-0.3.9-19.fc14 (build/make) nushio,psytux
bibletime-2.5-3.fc14 (build/make) anderson,deji
bit-0.4.90-10.fc12 (build/make) rvinyard
bitmap-1.0.3-7.fc13 (build/make) kasal,pertusus
blackbox-0.70.1-14 (build/make) thias
blokkal-0.1.2-1.fc13.1 (build/make) thomasj
bluefish-2.0.0-2.fc14 (build/make) pghmcfc
boost-1.41.0-10.fc14 (build/make) bkoz,denisarnaud,pertusus,pmachata
bsf-2.4.0-5.fc14 (build/make) pcheung
buildbot-0.7.12-1.fc13 (build/make) giallu,dmalcolm,smilner
bzr-2.2-0.5.b1.fc14 (build/make) toshio,hno,jzeleny,shahms,toshio
cairomm-1.8.4-1.fc13 (build/make) rvinyard
canorus-0.7-4.R1177.20090904svn.fc13 
(missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking)
 oget
cas-0.15-1.fc12.1 (build/make) astokes
cdcollect-0.6.0-10.fc13 (build/make) sharkcz
cegui-0.6.2-5.fc13 (build/make) jwrdegoede,atorkhov,bruno
cellwriter-1.3.4-3.fc12 
(missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking)
 limb
cfdg-2.2.1-1.fc13 
(missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking)
 limb
cfdg-fe-0.1-4.fc12 
(missing_DSO_to_linker__http://fedor

Fedora rawhide FTBFS status 2010-05-27 x86_64

2010-05-31 Thread Matt Domsch
Fedora Fails To Build From Source Results for x86_64
using rawhide from 2010-05-27

This is a full rebuild, the first for Fedora 14's rawhide.  The
builders all have Fedora 13 installed.

Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/


51 Open Bugs which now build, and can be marked CLOSED RAWHIDE:
apanov-heuristica-fonts: [u'565136']
audex: [u'555453']
btrfs-progs: [u'565112']
cairo-clock: [u'564959']
clisp: [u'539088']
clutter-gtk: [u'539122']
collectd: [u'564943']
comedilib: [u'555459']
dbxml-perl: [u'555452']
dbxml: [u'555494']
eboard: [u'565137']
fedora-security-guide-en-US: [u'538934']
fence-virt: [u'565111']
florence: [u'564675']
gdm: [u'539144']
ghostscript-fonts: [u'565206']
gnome-netstatus: [u'564852']
griv: [u'565081']
harminv: [u'565036']
hdf: [u'538896']
healpy: [u'564726']
itpp: [u'565156']
keepassx: [u'539011']
krb5-auth-dialog: [u'555498']
kst: [u'539056']
libvirt-qpid: [u'565139']
mpqc: [u'565030']
openwsman: [u'564916']
paperbox: [u'564997']
perl-HTML-FormFu-Model-DBIC: [u'564664']
plexus-appserver: [u'564825']
plexus-bsh-factory: [u'564981']
plexus-xmlrpc: [u'564880']
PySBIG: [u'565051']
python-krbV: [u'555442']
python-nss: [u'565044']
razertool: [u'564813']
rpm: [u'565223']
schroot: [u'564770']
scitools: [u'564781']
showimg: [u'539025']
springlobby: [u'564795']
subversion-api-docs: [u'538966']
synce-kde: [u'539195']
synce-trayicon: [u'564881']
tasque: [u'539146']
tex-musixtex: [u'564757']
UnihanDb: [u'538948']
virt-ctrl: [u'538891']
xca: [u'565073']
zfs-fuse: [u'565076']

Total packages: 9284
Number failed to build: 572
Number expected to fail due to ExclusiveArch or ExcludeArch: 29
Leaving:  543

Of those expected to have worked...
Without a bug filed: 419
--
AcetoneISO2-2.2.1-2.fc13 (build/make) spot
Django-1.2.1-1.fc14 (build/make) smilner,dmalcolm,salimma,smilner
GConf2-2.31.3-1.fc14 (build/make) rstrode,walters
GtkAda-2.14.0-4.fc13 (build/make) gemi,rombobeorn
NetworkManager-0.8.1-0.1.git20100510.fc14 (build/make) dcbw,dcbw
OpenGTL-0.9.13-1.fc13 (build/make) rdieter
OpenSceneGraph-2.8.2-3.fc12 (build/make) corsepiu
PyQt4-4.7.3-2.fc14 (build/make) rdieter,dmalcolm,than
QuantLib-1.0.1-3.fc14 (build/make) spot
R-BSgenome-1.14.2-1.fc12 (build/make) pingou
R-BSgenome.Celegans.UCSC.ce2-1.3.16-1.fc13 (build/make) pingou
R-Biostrings-2.14.12-1.fc14 (build/make) pingou
R-IRanges-1.4.16-1.fc14 (build/make) pingou
R-RScaLAPACK-0.6.1-2.fc14 (build/make) spot
Thunar-1.0.2-1.fc14 (build/make) kevin,cwickert,pertusus
TnL-07-12.fc13 (build/make) jwrdegoede
TurboGears-1.0.9-3.fc13 (build/make) lmacken,fschwarz,toshio
alltray-0.70-5.fc13 (build/make) sundaram,huzaifas,luceliofreitas
almanah-0.7.3-1.fc14 (build/make) th0br0
amarok-2.3.0.90-1.fc14 (build/make) rdieter,kaboon,rdieter,thomasj,tuxbrewr
apache-commons-exec-1.0.1-2.fc13 (build/make) melmorabity
ardour-2.8.7-1.fc13 (build/make) green,jwrdegoede,oget
asterisk-sounds-core-1.4.16-3.fc13 (build/make) jcollie,itamarjp
atlas-3.8.3-15.fc13 (build/make) deji,deji
audacious-plugin-fc-0.4-3 (build/make) mschwendt
audacity-1.3.11-0.1.beta.fc13 (build/make) gemi,dtimms
autofs-5.0.5-27.fc14 (build/make) jmoyer,iankent
avahi-0.6.25-7.fc14 (build/make) lennart,lennart
bacula-5.0.1-1.fc14 (build/make) 
ixs,dnovotny,fschwarz,jgorig,kanarip,limb,mmcgrath,rvokal
bakery-2.6.3-4.fc14 (build/make) hguemar
bareftp-0.3.2-1.fc14 (build/make) itamarjp
bibletime-2.5-3.fc14 (build/make) anderson,deji
bit-0.4.90-10.fc12 (build/make) rvinyard
bitmap-1.0.3-7.fc13 (build/make) kasal,pertusus
bless-0.6.0-5.fc13 (build/make) drago01
blokkal-0.1.2-1.fc13.1 (build/make) thomasj
bluefish-2.0.0-2.fc14 (build/make) pghmcfc
boo-0.9.2.3383-3.fc13 (build/make) pfj,palango
boost-1.41.0-10.fc14 (build/make) bkoz,denisarnaud,pertusus,pmachata
bsf-2.4.0-5.fc14 (build/make) pcheung
buildbot-0.7.12-1.fc13 (build/make) giallu,dmalcolm,smilner
bzr-2.2-0.5.b1.fc14 (build/make) toshio,hno,jzeleny,shahms,toshio
cairomm-1.8.4-1.fc13 (build/make) rvinyard
canorus-0.7-4.R1177.20090904svn.fc13 
(missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking)
 oget
cas-0.15-1.fc12.1 (build/make) astokes
cdcollect-0.6.0-10.fc13 (build/make) sharkcz
cegui-0.6.2-5.fc13 (build/make) jwrdegoede,atorkhov,bruno
cellwriter-1.3.4-3.fc12 
(missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking)
 limb
ceph-0.20-1.fc14 (build/make) josef,boodle,tremble
cfdg-2.2.1-1.fc13 
(missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking)
 limb
cfdg-fe-0.1-4.fc12 
(missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking)
 limb
chemical-mime-data-0.1.94-7.fc12 (build/make) belegdol
chipmunk-4.1.0-8.fc13 
(missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking)
 limb
chktex-1.6.4-4.fc11 (build/make) sergiopr,pertusus
chmsee-1.1.0-1.fc14 (build/make) bbbush,pertusus
choqok-0.9.55-15.fc14 (build/make) tejas
chro

Re: libjpeg for F14

2010-05-31 Thread Tom Lane
Toshio Kuratomi  writes:
> 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?

[ sorry for slow response ]  libjpeg-turbo is news to me, but as far as
the other two go:

* the sf.net project was started to produce ABI-compatible updates of
libjpeg 6b, but I'm beginning to despair of ever seeing a release from
them.

* libjpeg7/8/etc is pretty much one person, and I'm not terribly happy
with the direction that that's going either.  Guido doesn't seem to be
very concerned with even file-level compatibility, let alone source-code
compatibility (libjpeg7 is known to have broken multiple dependent
packages), and he's also not worrying much about patent issues.  The
move to add arithmetic-coding support seems a bad idea on at least two
of those grounds, and it doesn't even buy that much in file size.

I suppose this is all my fault for having let libjpeg languish for so
many years, but that's water under the bridge now.  If the libjpeg-turbo
group is doing active development and is taking care not to break things
unnecessarily, I'm happy to see them become the forefront of libjpeg
development.  Especially if it means I don't have to do the work ;-)

regards, tom lane
ex-organizer, Independent JPEG Group
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: libjpeg for F14

2010-05-31 Thread Orcan Ogetbil
On Mon, May 31, 2010 at 12:16 PM, Adam Tkac wrote:
> On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote:
>>
>> I'm going to create a Fedora feature for this task.
>
> Done. You can check
> http://fedoraproject.org/wiki/Features/libjpeg-turbo.
>

Thanks. Is there an SRPM we can give it a test?

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


Re: libjpeg for F14

2010-05-31 Thread Adam Tkac
On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote:
> 
> I'm going to create a Fedora feature for this task.

Done. You can check
http://fedoraproject.org/wiki/Features/libjpeg-turbo.

Regards, Adam

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


cpio: Bad magic

2010-05-31 Thread Harry Rickards
Hi,

When building my package with rpmbuild, I'm getting the following error:

error: create archive failed on file
/builddir/build/BUILDROOT/lives-1.3.3-1.fc13.x86_64/usr/share/doc/lives-1.3.3/AUTHORS:
cpio: Bad magic

I've tried reinstalling cpio and glibc, and I've got enough space
left. I can view AUTHORS fine with cat, and even compress it with
cpio. The strange part is, this error also occurs when using koji -
see the build log at
http://koji.fedoraproject.org/koji/getfile?taskID=2220058&name=build.log.

The source rpm is at
http://hotfile.com/dl/45779573/83852f4/lives-1.3.3-1.fc13.src.rpm.html.

Any help is appreciated!

Thanks

-- 
Harry Rickards - ha...@linux.com
Vote Lib Dem - Building a fairer Britain - http://libdems.org.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Can anyone contact torque/perl-PBS maintainer.

2010-05-31 Thread Steve Traylen
Following the process

https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Is someone able to get in touch with maintainer of torque and perl-PBS.

Fedora id = garrick

Bug https://bugzilla.redhat.com/show_bug.cgi?id=590487 details the
previous attempts made over the last couple of weeks.

Steve Traylen.


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


Re: Request: Magit 0.8 packaging

2010-05-31 Thread H . Guémar
magit is already packaged as emacs-magit
https://admin.fedoraproject.org/pkgdb/acls/name/emacs-magit

Check this with the maintainer, if you're interested by maintaining
it, ask co-maintainership.

best regards,

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


Re: Request: Magit 0.8 packaging

2010-05-31 Thread Rakesh Pandit
On 31 May 2010 20:32, Chen Lei wrote:
> 2010/5/31  :
>>
>> Wishful thinking: the new Magit mode v. 0.8 (Git interface for Emacs)
>> will soon be packaged for Fedora.
>>
>> http://philjackson.github.com/magit/
>>
>
> You can package it for fedora by your self
>
> http://fedoraproject.org/wiki/PackageMaintainers/Join
>
> http://fedoraproject.org/wiki/Packaging:Emacs
>
>

And in case you are not interested in packaging yourself, add it here:
http://fedoraproject.org/wiki/PackageMaintainers/WishList

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

2010-05-31 Thread Adam Tkac
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.

This is pretty big issue.

> 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.

Sorry for late response, this mail got lost in my queue.

libjpeg-turbo is a fork of the original libjpeg-6b release created
and maintained by VirtualGL and TigerVNC developers. Main focus is on
performance and API+ABI compatibility with libjpeg. Although
libjpeg-turbo contains MMX/SSE acceleration it also contains bunch of
pure algorithmic enhancements so even if target platform doesn't
support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg.
When SSE is used then libjpeg and libjpeg-turbo performance is simply
incomparable. And there are still number of areas for optimizations,
for example on we are currently using only half of SSE registers on
64bit platforms.

About the merge of this code with the original ijg's code. Yes, I must
admit it is possible but personally I don't like it much. In my
opinion libjpeg-turbo is far more ahead than libjpeg so it's easier
for us to incorporate libjpeg changes to libjpeg-turbo. And I'm not
able to find CVS/SVN/git repository of the libjpeg code.

In my opinion if will be great benefit for Fedora to simply replace
libjpeg by libjpeg-turbo. It works fine on secondary architectures
and if processor doesn't support MMX/SSE then it falls back to
non-ASM code (which is still faster than libjpeg code, as I wrote
above).

Btw this library is used since Fedora 11 in tigervnc package for JPEG
compression/decompression and it works without any problem on all
supported platforms (x86, x86_64, ppc, ppc64) and also on s390(x).

So, if I summarize pros and cons for libjpeg-turbo:

+: _really_ faster than libjpeg
   more portable
   more open than IJG code
   API/ABI compatible with libjpeg (AFAIK)
   works on all platforms (not only on SSE capable platforms)

-: not developed by IJG :)

I'm going to create a Fedora feature for this task.

Regards, Adam

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


Re: perl 5.12 status

2010-05-31 Thread Marcela Mašláňová
On 05/28/2010 03:19 PM, Iain Arnell wrote:
> 2010/5/12 Marcela Mašláňová :
>>
>> Today list of packages is little shorter (114):
>
> Did you only rebuild perl-* packages? Checking whatrequires
> 'perl(:MODULE_COMPAT_5.10.?)' gives me 164 distinct src packages in
> dist-f14-perltest (out of 1570 in total that require MODULE_COMPAT).
>
> You want to throw these at your rebuild script in -perltest to shake
> out any remaining difficulties? I know at least one of these is
> failing (clc-intercal - I'm sure I'm in for a fun time trying to fix
> that one).

I used some terribly complicated repoquery which produced list of 1447
packages for rebuild.
I've found some which still didn't pass. The list is attached. There might
be some false positives.
I hadn't time last few weeks, but this week I want to update perl to 5.12.1
and fix at least part of list.

The future goal is nominate perl 5.12.1 as a Fedora feature to make perl
more visible for common users.

perl-Archive-RPM
perl-Catalyst-Controller-BindLex
perl-Catalyst-View-JSON
perl-CatalystX-Component-Traits
perl-Class-C3-Adopt-NEXT
perl-Config-Model-CursesUI
perl-Data-Alias
perl-Data-Visitor
perl-DateTime-Format-Strptime
perl-DBI-Dumper
perl-Devel-LexAlias
perl-Fedora-Bugzilla
perl-File-ChangeNotify
perl-forks
perl-GDGraph3d
perl-GSSAPI
perl-HTTP-Server-Simple-Mason
perl-IO-Compress-Bzip2
perl-libxml-perl
perl-MasonX-Request-WithApacheSession
perl-MooseX-Params-Validate
perl-Net-GitHub
perl-Olson-Abbreviations
perl-Padre
perl-PDL
perl-PDL-Graphics-PLplot
perl-POE-Component-Client-HTTP
perl-POE-Component-Server-Bayeux
perl-POE-Component-Server-SimpleHTTP
perl-POE-Component-Server-SOAP
perl-POE-Component-Server-XMLRPC
perl-Pugs-Compiler-Rule
perl-Socket-GetAddrInfo
perl-SVG-Parser
perl-SVN-Mirror
perl-Test-AutoBuild
perl-Test-WWW-Selenium
perl-WebService-Validator-CSS-W3C
perl-YAML-LibYAML
zarafa


>
>
> 389-ds-base-1.2.6-0.4.a4.fc14
> ack-1.86-4.fc13
> amanda-2.6.1p2-3.fc14
> asterisk-1.6.2.8-0.1.rc1.fc14
> backup-manager-0.7.8-6.fc13
> clamtk-4.26-1.fc14
> claws-mail-plugins-3.7.6-1.fc14
> clc-intercal-0-0.3.1._94._2.fc13
> clive-2.2.11-1.fc14
> cluster-3.0.12-2.fc14
> code2html-0.9.1-6.fc13
> conmux-0.0-9.493svn.fc13
> cpanspec-1.78-4.fc13
> cpan-upload-2.2-6.fc13
> crypto-utils-2.4.1-26
> cyrus-imapd-2.3.16-3.fc14
> dahdi-tools-2.1.0.2-9.fc13
> dnssec-tools-1.6-3.fc14
> docbook2X-0.8.8-6.fc13
> dxcc-20080225-8.fc14
> epylog-1.0.3-11.fc13
> exim-4.71-3.fc14
> fcgi-2.4.0-12.fc13
> foomatic-4.0.4-11.fc14
> freeradius-2.1.9-1.fc14
> frozen-bubble-2.2.0-5.fc13
> gg2-2.3.0-16.fc14
> gitolite-1.5-1.fc14
> globus-common-11.4-1.fc14
> globus-gram-job-manager-scripts-2.5-1.fc14
> globus-gram-protocol-9.7-1.fc14
> gnumeric-1.10.0-1.fc14
> gpsdrive-2.10-0.8.20100508svn.fc14
> GraphicsMagick-1.3.12-1.fc14
> graphviz-2.26.0-2.fc13
> grepmail-5.3034-3.fc13
> grid-packaging-tools-3.2-21.fc13
> gscan2pdf-0.9.30-6.fc14
> hyperestraier-1.4.13-6.fc13
> ikiwiki-3.20100504-1.fc14
> ImageMagick-6.6.0.2-8.fc14
> imvirt-0.9.0-0.2.pre1.fc14
> inkscape-0.48-0.2.20100505bzr.fc14
> inn-2.5.1-3.fc13
> innotop-1.6.0-5.fc13
> irssi-0.8.15-1.fc14
> JSDoc-1.10.2-9.fc13
> krazy2-2.9-4.20090928svn.fc13
> lcgdm-1.7.4.4-2.fc14
> libconcord-0.21-8.fc13
> liboping-1.3.4-1.fc14
> libprelude-1.0.0-3.fc14
> libpreludedb-1.0.0-3.fc14
> maatkit-5899-1.fc14
> mailgraph-1.14-6.fc13
> mapserver-5.6.3-1.fc14
> mod_perlite-0.10-2.fc13
> mr-0.48-1.fc14
> munin-1.4.4-1.fc14
> MySQL-zrm-2.1.1-6.fc13
> nagios-3.2.1-3.fc14
> NaturalDocs-1.4-5.fc13
> netcdf-perl-1.2.4-4.fc13
> net-snmp-5.5-12.fc13
> nginx-0.7.65-1.fc13
> nocpulse-common-2.1.19-1.fc13
> ocaml-cil-1.3.7-5.fc13
> ocaml-perl4caml-0.9.5-12.fc13
> ocsinventory-1.3.2-1.fc14
> ocsinventory-agent-1.1.2-1.fc13
> OpenIPMI-2.0.18-1.fc14
> openser-1.3.4-12.fc13
> opensips-1.6.2-3.fc14
> openwsman-2.2.3-3.fc14
> p0rn-comfort-0.0.4-9.fc13
> pacemaker-1.1.2-1.fc14
> pcsc-perl-1.4.8-2.fc13
> perl-Archive-RPM-0.05-1.fc13
> Perlbal-1.75-1.fc14
> perlbrew-0.06-2.fc14
> perl-Catalyst-Controller-BindLex-0.05-4.fc13
> perl-Catalyst-View-JSON-0.26-2.fc13
> perl-CatalystX-Component-Traits-0.14-3.fc14
> perl-CGI-Application-PSGI-1.00-1.fc14
> perl-CGI-Compile-0.11-1.fc14
> perl-Class-C3-Adopt-NEXT-0.12-3.fc13
> perl-Config-Model-CursesUI-1.103-3.fc11
> perl-Crypt-SMIME-0.09-3.fc14
> perl-Data-Alias-1.07-6.fc13
> perl-Data-Visitor-0.26-1.fc13
> perl-DateTime-Format-Strptime-1.1000-1.fc13
> perl-DBI-Dumper-2.01-8.fc12
> perl-Devel-LexAlias-0.04-6.fc13
> perl-Dir-Self-0.10-1.fc14
> perl-ExtUtils-CChecker-0.03-1.fc14
> perl-Fedora-Bugzilla-0.13-2.fc13
> perl-File-ChangeNotify-0.12-2.fc14
> perl-forks-0.33-5.fc14
> perl-GDGraph3d-0.63-12.fc13
> perl-GSSAPI-0.26-4.fc13
> perl-HTTP-Server-Simple-Mason-0.13-2.fc13
> perl-IO-Compress-Bzip2-2.005-6.fc12
> perl-libxml-perl-0.08-10.fc13
> perl-MasonX-Request-WithApacheSession-0.30-8.fc13
> perl-mogilefs-server-2.30-4.fc13
> perl-MooseX-Params-Validate-0.13-1.fc14
> perl-Net-GitHub-0.20-1.fc14
> perl-Olson-Abbreviations-0.02-1.fc14
> 

Re: Problem with elipse in Fedora 13

2010-05-31 Thread Michal Schmidt
On Mon, 31 May 2010 11:08:53 -0300 Casimiro de Almeida Barreto wrote:
> BTW, since I upgraded to F13 (from F12) I've had some abrtd anoying
> error messages and they're related to access to USB . It has been
> reported already but I'd like to know if someone else has had the same
> problem. Transcript follows:
> 
> [ cut here ]
> WARNING: at fs/fs-writeback.c:597 writeback_inodes_wb+0x202/0x30e()
> [...]

Known bug, should be fixed in the kernel in updates-testing. Give it a
try.
https://bugzilla.redhat.com/show_bug.cgi?id=593669
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Request: Magit 0.8 packaging

2010-05-31 Thread Chen Lei
2010/5/31  :
>
> Wishful thinking: the new Magit mode v. 0.8 (Git interface for Emacs)
> will soon be packaged for Fedora.
>
> http://philjackson.github.com/magit/
>

You can package it for fedora by your self

http://fedoraproject.org/wiki/PackageMaintainers/Join

http://fedoraproject.org/wiki/Packaging:Emacs


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


Request: Magit 0.8 packaging

2010-05-31 Thread mhuhtala

Wishful thinking: the new Magit mode v. 0.8 (Git interface for Emacs)  
will soon be packaged for Fedora.

http://philjackson.github.com/magit/


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


Re: banshee-1 hang during playing video overnight

2010-05-31 Thread Luming Yu
On Mon, May 31, 2010 at 10:37 PM, Michal Schmidt  wrote:
> On Mon, 31 May 2010 14:42:21 +0800 Luming Yu wrote:
>> Hmm, I must have filed the bug into wrong category since nothing
>> happened with the problem..
>
> It's been 5 days since you filed the bug, 2 of them weekend.
> Surely you must realize that Fedora is not RHEL and that there's not
> guaranteed upper bound on the response time.
>
> Also from your description I get the feeling that the bug is not that
> severe, or is it? Did it crash only once, or is it reliably
> reproducible? If you can reproduce it, please tell so in the bugreport.

I heard the bug from one of my friends, and reproduced and confirmed
it happened to me too. So I'm pretty sure it's reproducible. I have left
the hung banshee there and suspend the system, and waiting on expert's input to
proceed forward.. i.e. I'm ready to provide info from an already-hang banshee..

>
>> Took a deeper look at the back trace, now
>> it looks more like a gstreamer problem... any suggestion on that? (I
>> can't move https://bugzilla.redhat.com/show_bug.cgi?id=595997 to
>> right place)
>
> Don't you have an "edit" link shown next to "Component: banshee"?
> I think the reporter of a bug can always edit the component but maybe
> I'm wrong about that.
>

You are right, I must have used IE , I'm sorry about that.

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


Re: Problem with elipse in Fedora 13

2010-05-31 Thread shmuel siegel

On 5/31/2010 5:08 PM, Casimiro de Almeida Barreto wrote:

Em 31-05-2010 09:33, Andrew Overholt escreveu:

Hi Casimiro,

   

I've got the following problem with eclipse after update to F13: upon launch it
freezes at initial banner&  uses about 80% of CPU time.
 

Please file a bug at bugzilla.redhat.com and we can work through it there.

Thanks,

Andrew
   

Hello,

Apparently I have the problem solved. First of all, the listing had 
all that modules because when eclipse refused to start I assumed 
something was lacking and behave just like a n00b (yum install 
"eclipse-*" kind of thing). So, it happened prior of having all those 
modules installed. Anyways, what I did was to uninstall eclipse & 
everything related, to remove .eclipse and workspace (inherited from 
F12), re-install eclipse and bring back old content. And it worked.


Apparently it was a problem with what was before & what was updated. 
As error cannot be reproduced there's little sense in filling a bug.
yes there is a reason to file the bug report. The upgrade should have 
been seamless. Something like this has happened to many people on many 
eclipse updates. Maybe there is something in your scenario that would 
give the maintainer a clue. At worst, the bug will be closed as 
insufficient information.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: banshee-1 hang during playing video overnight

2010-05-31 Thread Michal Schmidt
On Mon, 31 May 2010 14:42:21 +0800 Luming Yu wrote:
> Hmm, I must have filed the bug into wrong category since nothing
> happened with the problem..

It's been 5 days since you filed the bug, 2 of them weekend.
Surely you must realize that Fedora is not RHEL and that there's not
guaranteed upper bound on the response time.

Also from your description I get the feeling that the bug is not that
severe, or is it? Did it crash only once, or is it reliably
reproducible? If you can reproduce it, please tell so in the bugreport.

> Took a deeper look at the back trace, now
> it looks more like a gstreamer problem... any suggestion on that? (I
> can't move https://bugzilla.redhat.com/show_bug.cgi?id=595997 to
> right place)

Don't you have an "edit" link shown next to "Component: banshee"?
I think the reporter of a bug can always edit the component but maybe
I'm wrong about that.

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


Re: Problem with elipse in Fedora 13

2010-05-31 Thread Casimiro de Almeida Barreto
Em 31-05-2010 09:33, Andrew Overholt escreveu:
> Hi Casimiro,
>
>   
>> I've got the following problem with eclipse after update to F13: upon launch 
>> it
>> freezes at initial banner & uses about 80% of CPU time.
>> 
> Please file a bug at bugzilla.redhat.com and we can work through it there.
>
> Thanks,
>
> Andrew
>   
Hello,

Apparently I have the problem solved. First of all, the listing had all
that modules because when eclipse refused to start I assumed something
was lacking and behave just like a n00b (yum install "eclipse-*" kind of
thing). So, it happened prior of having all those modules installed.
Anyways, what I did was to uninstall eclipse & everything related, to
remove .eclipse and workspace (inherited from F12), re-install eclipse
and bring back old content. And it worked.

Apparently it was a problem with what was before & what was updated. As
error cannot be reproduced there's little sense in filling a bug.

BTW, since I upgraded to F13 (from F12) I've had some abrtd anoying
error messages and they're related to access to USB . It has been
reported already but I'd like to know if someone else has had the same
problem. Transcript follows:

[ cut here ]
WARNING: at fs/fs-writeback.c:597 writeback_inodes_wb+0x202/0x30e()
Hardware name: System Product Name
Modules linked in: cbc cryptoloop vfat fat usb_storage tcp_lp fuse
ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc p4_clockmod
xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6
uinput nvidia(P) snd_intel8x0 snd_ac97_codec ac97_bus snd_seq ttm
snd_seq_device drm_kms_helper gspca_ov519 snd_pcm drm gspca_main ppdev
i2c_algo_bit parport_pc videodev snd_timer parport sis900 video
v4l1_compat mii output snd joydev i2c_core soundcore snd_page_alloc
microcode aes_i586 aes_generic xts gf128mul dm_crypt sata_sis
ata_generic pata_acpi pata_sis [last unloaded: nouveau]
Pid: 4402, comm: flush-253:2 Tainted: PW 
2.6.33.4-95.fc13.i686.PAE #1
Call Trace:
[] warn_slowpath_common+0x65/0x7c
[] ? writeback_inodes_wb+0x202/0x30e
[] warn_slowpath_null+0xd/0x10
[] writeback_inodes_wb+0x202/0x30e
[] wb_writeback+0x103/0x162
[] ? call_rcu+0x8/0xa
[] ? wb_clear_pending+0x6a/0x6f
[] wb_do_writeback+0x65/0x128
[] bdi_writeback_task+0x28/0x84
[] ? bdi_start_fn+0x0/0xa3
[] bdi_start_fn+0x55/0xa3
[] ? bdi_start_fn+0x0/0xa3
[] kthread+0x5f/0x64
[] ? kthread+0x0/0x64
[] kernel_thread_helper+0x6/0x10

Also, upgrading from F12 to F13 messed with the network "connections
manager" applet both in KDE and GNOME... took a while to have it back.

Best regards,

Casimiro Barreto

PS: F13 looks really fine. Pitty kmod-nvidia-173xx -PAE still not available.


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

Re: Problem with elipse in Fedora 13

2010-05-31 Thread Andrew Overholt
Hi Casimiro,

> I've got the following problem with eclipse after update to F13: upon launch 
> it
> freezes at initial banner & uses about 80% of CPU time.

Please file a bug at bugzilla.redhat.com and we can work through it there.

Thanks,

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


rawhide report: 20100531 changes

2010-05-31 Thread Rawhide Report
Compose started at Mon May 31 08:15:10 UTC 2010

Broken deps for i386
--
almanah-0.7.3-1.fc14.i686 requires libedataserver-1.2.so.12
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
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
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-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
iaxclient-devel-2.1-0.5.beta3.fc13.i686 requires liboggz.so.1
iaxclient-devel-2.1-0.5.beta3.fc13.i686 requires 
liboggz.so.1(liboggz.so.0.2)
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
libannodex-0.7.3-13.fc13.i686 requires liboggz.so.1
libannodex-0.7.3-13.fc13.i686 requires liboggz.so.1(liboggz.so.0.2)
libfishsound-tools-0.9.1-4.fc12.i686 requires liboggz.so.1
libfishsound-tools-0.9.1-4.fc12.i686 requires 
liboggz.so.1(liboggz.so.0.2)
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
mod_annodex-0.2.2-11.fc12.i686 requires liboggz.so.1

plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch 
requires jakarta-commons-logging-javadoc
qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18
rubygem-right_aws-1.10.0-3.fc14.noarch requires 
rubygem(right-http_connection) >= 0:1.2.4
sonic-visualiser-1.7.1-1.fc13.i686 requires liboggz.so.1
sonic-visualiser-1.7.1-1.fc13.i686 requires liboggz.so.1(liboggz.so.0.2)
syncevolution-1.0beta3-2.fc14.i686 requires libedataserver-1.2.so.12
tasks-0.16-3.fc14.i686 requires libedataserver-1.2.so.12
themonospot-gui-qt-0.1.3-6.fc14.i686 requires mono(qt-dotnet) = 
0:4.5.0.0
themonospot-gui-qt-0.1.3-6.fc14.i686 requires libqyotoshared.so.1
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:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit)
dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit)
deskbar-applet-2.30.0-1.1.fc14.x86_64 requires 
libedataserver-1.2.so.12()(64bit)
giggle-0.5-1.fc14.i686 requires libedataserver-1.2.so.12
giggle-0.5-1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit)
gnome-launch-box-0.4-17.fc14.x86_64 requires 
libedataserver-1.2.so.12()(64bit)
gnome-phone-manager-0.65-5.fc12.x86_64 requires 
libedataserver-1.2.so.11()(64bit)
gnome-phone-manager-telepathy-0.65-5.fc12.x86_64 requires 
libedataserver-1.2.so.11()(64bit)
gnome-python2-evolution-2.30.0-5.fc14.x86_64 requires 
libedataserver-1.2.so.12()(64bit)
iaxclient-devel-2.1-0.5.beta3.fc13.i686 requires liboggz.so.1
iaxclient-devel-2.1-0.5.beta3.fc13.i686 requires 
liboggz.so.1(liboggz.so.0.2)
iaxclient-devel-2.1-0.5.beta3.fc13.x86_64 requires liboggz.so.1()(64bit)
iaxclient-devel-2.1-0.5.beta3.fc13.x86_64 requires 
liboggz.so.1(liboggz.so.0.2)(64bit)
kobby-1.0-0.3.b4.fc13.x86_64 requires libinfinity-0.3.so.0()(64bit)
kobby-1.0-0.3.b4.fc13.x86_64 requires libinftext-0.3.so.0()(64bit)
libannodex-0.7.3-13.fc13.i686 requires liboggz.so.1
libannodex-0.7.3-13.fc13.i686 requires liboggz.so.1(liboggz.so.0.2)
libannodex-0.7.3-13.fc13.x86_64 requires liboggz.so.1()(64bit)
libannodex-0.7.3-13.fc13.x86_64 requires 
liboggz.so.1(liboggz.so.0.2)(64bit)
libfishsound-tools-0.9.1-4.fc12.x86_64 requires liboggz.so.1()(64bit)
libfishsound-tools-0.9.1-4.fc12.x86_64 requires 
liboggz.so.1(liboggz.so.0.2)(64bit)
libqinfinity-1.0-0.2.b4.fc13.i686 requires libinfinity-0.3.so.0
libqinfinity-1.0-0.2.b4.fc13.i686 requires libinftext-0.3.so.0
libqinfinity-1.0-0.2.b4.fc13.x86_64 requires 
libinfinity-0.3.so.0()(64bit)
libqinfinity-1.0-0.2.b4.fc13.x86_64 requires 
libinftext-0.3.so.0()(64bit)
mod_annodex-0.2.2-11.f

Re: Meego in Fedora repos?

2010-05-31 Thread Chen Lei
2010/5/31 Peter Robinson :
> Thanks for the offer. The initial release of qt-mobility seems to need
> 4.6.x and does compile against the Qt in Fedora. I presume they'll
> bring it up to support 4.7 sometime before long. I'm still reviewing
> the requirements so I'm not exactly sure what they are but I'll
> certainly let you know when I know more.
>
> Peter
> --

I somehow a bit worry about meego spin in fedora when considering some
compents in meego are forked, now mutter-mbl conflicts with mutter, it
may be unacceptable for F14 which will use gnome3 as default desktop.


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


Re: Meego in Fedora repos?

2010-05-31 Thread Peter Robinson
Hi Kevin,

On Mon, May 31, 2010 at 1:23 AM, Kevin Kofler  wrote:
> Peter Robinson wrote:
>> Not decided about the handset side of things yet. The vast majority of
>> the components from "MeeGo Core" are already in rawhide (and F-13 for
>> that matter). Most of the Netbook UX stuff is. Some of the handset
>> stuff can't yet compile on rawhide due to newer QT components but
>> it'll be a couple of months before we see most of the handset UI
>> components so there's no point looking at it until that point in time.
>
> If you need any help on the Qt side, please contact us at the KDE SIG, we'll
> help you out with it.
>
> I'll note that we already have Qt 4.7 Beta in Rawhide and will import
> RC/final stuff once it's ready. (We could also import a git snapshot if
> really needed.) I presume you'll also need Qt Mobility packaged and
> imported? Is there anything else you need from Qt?

Thanks for the offer. The initial release of qt-mobility seems to need
4.6.x and does compile against the Qt in Fedora. I presume they'll
bring it up to support 4.7 sometime before long. I'm still reviewing
the requirements so I'm not exactly sure what they are but I'll
certainly let you know when I know more.

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