Plan for tomorrow's FESCo meeting (2010-06-01)
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)
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)
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)
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
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)
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)
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)
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)
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
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/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)
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)
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
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)
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)
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
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)
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)
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)
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)
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)
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)
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
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)
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)
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)
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)
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)
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)
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)
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)
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)
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.
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
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
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
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
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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/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
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
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
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
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
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
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
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/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?
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
