Re: [HEADS-UP] systemd is now the default init system in rawhide
Greetings. first it seems that systemd-sysvinit needs to add a: Provides: sysvinit-userspace To avoid the current conflicts/upgrade problems: ---> Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed --> Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit --> Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit Error: systemd-sysvinit conflicts with upstart-sysvinit I built a local systemd-sysvinit and updated and did some testing. First it seems that my boot would fail. It was unable to find or run a 'default.target' and would hang. Unfortunately it advises you to check the logs, but since syslog isn't up yet and you can't do anything to look at dmesg thats not very helpfull. ;( If there is no /etc/systemd/system/default.target could we fall back to a single user target? Also, in my switchover, I got no getty's setup by default. Happily I was able to figure out how to add them here by looking at the FAQ (once I found it. ;) Does systemd allow you to query for root password before doing single user? With upstart/sysvinit you can do a 'chkconfig --list | grep 3:on' or the like to get a in order list of services. Is there something similar for systemd? I ask because I see people who have problems booting and often can see the last service that did work before the hang, then can look at the order and find out the trouble service. If systemd is just starting them all, is there any way to debug what one didn't finish or was next in the order? The shutdown/reboot commands don't seem to wall by default or output anything. You type them and the machine goes down. Could you at least add a "Shutting down system at 2010-07-25 xx;xx;xx" or something? With sysvinit/upstart the command would return back to a prompt and you could logout or do some few things before the machine was totally down. It's anoying to have to kill your ssh manually instead of being able to logout gracefully. Whats the status on selinux integration? We must get that working before release if it's going to be default... As a side note, "systemd" is an unfortunate name, google wise. It took me a while to find it's home page for the FAQ. ;( Anyhow, I sure hope we can get all the issues ironed out in time for F14. If not, we can always try again next cycle. I personally really want to make sure things are as stable and working and clear as we can make them before committing to making this default. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
update-mime-database in /sbin?
On Sat, 2010-07-24 at 17:48 -0400, Matthew Miller wrote: > On Sat, Jul 24, 2010 at 01:39:20PM -0700, Matt McCutchen wrote: > > > Still belongs in /sbin, unless it's meant to actually be executed directly > > > by end-users. > > No. If that were the criterion, update-mime-database would belong > > in /sbin . > > It looks like it probably _does_. From the gnome.org docs: > > Understanding how to refresh the MIME database is important for > administrators who wish to add new MIME types to the system, or otherwise > modify information about a MIME type. The application update-mime-database > is intended for this purpose. No, because unprivileged users may want to run update-mime-database in their own software installation prefix that they have wired up to $XDG_DATA_DIRS. I do this myself. You may point out that ldconfig is in /sbin. That's because the dynamic linker currently does not support caches in custom prefixes, but such support would be a natural enhancement that I would request if it became important to me. > But that's a long thread I don't want to sidetrack this with. And so I started a separate thread. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 14 Alpha Blocker Meeting #2 Recap
Date: 2010-07-23 Meeting summary --- * roll call (poelcat, 16:00:07) * https://bugzilla.redhat.com/show_bug.cgi?id=597858 (poelcat, 16:04:23) * LINK: https://bugzilla.mozilla.org/show_bug.cgi?id=506693 (mcepl, 16:08:09) * ACTION: https://bugzilla.redhat.com/show_bug.cgi?id=597858 approved blocker, remove F14Blocker, request feedback from maintainer (poelcat, 16:09:48) * https://bugzilla.redhat.com/show_bug.cgi?id=613695 (poelcat, 16:13:14) * https://bugzilla.redhat.com/show_bug.cgi?id=597858 (poelcat, 16:16:08) * ACTION: https://bugzilla.redhat.com/show_bug.cgi?id=597858 approved blocker, remove F14Blocker, request feedback from maintainer, contact Martin Stránský to get a better idea of the future of this bug (poelcat, 16:17:16) * https://bugzilla.redhat.com/show_bug.cgi?id=613695 (poelcat, 16:18:01) * ACTION: https://bugzilla.redhat.com/show_bug.cgi?id=613695 should be back in ASSIGNED, or VERIFIED->CLOSED next week (poelcat, 16:19:14) * https://bugzilla.redhat.com/show_bug.cgi?id=615443 (poelcat, 16:19:36) * ACTION: https://bugzilla.redhat.com/show_bug.cgi?id=615443 approved blocker, add jkeating to CC, monitor the nightlies for the next week and try to keep track of exactly what's broken in each (poelcat, 16:27:04) * we've certainly confirmed the problem exists and is widespread ... need some love to further isolate+diagnose (poelcat, 16:27:15) * https://bugzilla.redhat.com/show_bug.cgi?id=616090 (poelcat, 16:29:12) * ACTION: https://bugzilla.redhat.com/show_bug.cgi?id=616090 jlaska will retest this with the new rawhide acceptance images when they land (poelcat, 16:30:52) * #topic https://bugzilla.redhat.com/show_bug.cgi?id=617115 (poelcat, 16:31:28) * https://bugzilla.redhat.com/show_bug.cgi?id=617115 (jlaska, 16:38:32) * ACTION: https://bugzilla.redhat.com/show_bug.cgi?id=617115 ApprovedBlocker, add "the world" to the CC list so we can get some more help attention and help on this critical issue (poelcat, 16:39:24) * open discussion (poelcat, 16:39:40) Meeting ended at 16:45:53 UTC. Action Items * https://bugzilla.redhat.com/show_bug.cgi?id=597858 approved blocker, remove F14Blocker, request feedback from maintainer * https://bugzilla.redhat.com/show_bug.cgi?id=597858 approved blocker, remove F14Blocker, request feedback from maintainer, contact Martin Stránský to get a better idea of the future of this bug * https://bugzilla.redhat.com/show_bug.cgi?id=613695 should be back in ASSIGNED, or VERIFIED->CLOSED next week * https://bugzilla.redhat.com/show_bug.cgi?id=615443 approved blocker, add jkeating to CC, monitor the nightlies for the next week and try to keep track of exactly what's broken in each * https://bugzilla.redhat.com/show_bug.cgi?id=616090 jlaska will retest this with the new rawhide acceptance images when they land * https://bugzilla.redhat.com/show_bug.cgi?id=617115 ApprovedBlocker, add "the world" to the CC list so we can get some more help attention and help on this critical issue Action Items, by person --- * jlaska * https://bugzilla.redhat.com/show_bug.cgi?id=616090 jlaska will retest this with the new rawhide acceptance images when they land * **UNASSIGNED** * https://bugzilla.redhat.com/show_bug.cgi?id=597858 approved blocker, remove F14Blocker, request feedback from maintainer * https://bugzilla.redhat.com/show_bug.cgi?id=597858 approved blocker, remove F14Blocker, request feedback from maintainer, contact Martin Stránský to get a better idea of the future of this bug * https://bugzilla.redhat.com/show_bug.cgi?id=613695 should be back in ASSIGNED, or VERIFIED->CLOSED next week * https://bugzilla.redhat.com/show_bug.cgi?id=615443 approved blocker, add jkeating to CC, monitor the nightlies for the next week and try to keep track of exactly what's broken in each * https://bugzilla.redhat.com/show_bug.cgi?id=617115 ApprovedBlocker, add "the world" to the CC list so we can get some more help attention and help on this critical issue Minutes: http://meetbot.fedoraproject.org/fedora-bugzappers/2010-07-23/fedora-bugzappers.2010-07-23-16.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-bugzappers/2010-07-23/fedora-bugzappers.2010-07-23-16.00.txt Log: http://meetbot.fedoraproject.org/fedora-bugzappers/2010-07-23/fedora-bugzappers.2010-07-23-16.00.log.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
tangent! [was Re: [HEADS-UP] systemd is now the default init system in rawhide]
On Sat, Jul 24, 2010 at 01:39:20PM -0700, Matt McCutchen wrote: > > > Without looking too closely I believe systemd eventually seeks to replace > > > things like gnome-session daemon. It has session management in mind as > > > well as system. > > Still belongs in /sbin, unless it's meant to actually be executed directly > > by end-users. > No. If that were the criterion, update-mime-database would belong > in /sbin . It looks like it probably _does_. From the gnome.org docs: Understanding how to refresh the MIME database is important for administrators who wish to add new MIME types to the system, or otherwise modify information about a MIME type. The application update-mime-database is intended for this purpose. But that's a long thread I don't want to sidetrack this with. -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using LLVM for build package instead gcc, why not?
On Sat, Jul 24, 2010 at 1:09 PM, Horst H. von Brand wrote: > Jonathan MERCIER wrote: >> LLVM itself could allow for much greater flexibility in programming >> language choice. It can allow for anyone to take any language and output >> it in bytecode, machine code, javavm code and so on. Sounds like that bastard technology, CIL -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 07/24/2010 04:39 PM, Matt McCutchen wrote: > On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: >> On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: Why is the systemd executable in /bin instead of /sbin? >>> Without looking too closely I believe systemd eventually seeks to replace >>> things like gnome-session daemon. It has session management in mind as >>> well as system. >> >> Still belongs in /sbin, unless it's meant to actually be executed directly >> by end-users. > > No. If that were the criterion, update-mime-database would belong > in /sbin . > I suspect the argument is likely the other way round - namely its replacing init - therefore probably belongs in /sbin - no ? Oh - and may also do user session management as an additional feature in addition to being the init daemon ... gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 2.7 rebuild: maintainer help needed (please!)
Am Fri, 23 Jul 2010 14:07:50 -0400 schrieb David Malcolm : > Please can you review the list and see if there's anything that needs > fixing in your packages. > > Many of these are due to dependencies failing (or not being available > in the buildroot); this typically manifests with a failure in > "root.log", with some of the deps wanting python2.6, which isn't > available anymore. mpi4py was waiting for openmpi, now successful: http://koji.fedoraproject.org/koji/taskinfo?taskID=2348517 Same for pypar: http://koji.fedoraproject.org/koji/taskinfo?taskID=2348597 Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: > On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: > > > Why is the systemd executable in /bin instead of /sbin? > > Without looking too closely I believe systemd eventually seeks to replace > > things like gnome-session daemon. It has session management in mind as > > well as system. > > Still belongs in /sbin, unless it's meant to actually be executed directly > by end-users. No. If that were the criterion, update-mime-database would belong in /sbin . -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: > > Why is the systemd executable in /bin instead of /sbin? > Without looking too closely I believe systemd eventually seeks to replace > things like gnome-session daemon. It has session management in mind as > well as system. Still belongs in /sbin, unless it's meant to actually be executed directly by end-users. -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using LLVM for build package instead gcc, why not?
Jonathan MERCIER wrote: > LLVM itself could allow for much greater flexibility in programming > language choice. It can allow for anyone to take any language and output > it in bytecode, machine code, javavm code and so on. Sorry, but many interpreted languages (like Python, Perl, even emacs LISP) have their own bytecode (for good reasons, most of the time) and their own compilers to said bytecode. JVM is a _terrible_ architecture (somebody quipped it was carefully designed to be impossible to implement efficiently), other bytecodes are even more tailored for their respective languages. So this isn't _that_ great an idea. > If we can rip out > the multitude of compilers on different architectures and replace it > with one compiler base that does many different languages people might > start picking languages based on their merits rather than support (since > it just needs LLVM support to be supported). This idea was behind a dream of an universal intermediate language (UIL or some such). The problem is that designing such an UIL is extremely hard to do (and wasn't done because of that): You have to encode enough of the source code to be useful for the back end, and hide enough of the target to make the frontend truly target-independent; all the while not leaving too much hard work for the backend. Consider the variety of source languages you want to use: Perl (dynamic, heavily text based), C (static, "high level assembly language"), C++ (machine-near object oriented), Java (with guarantees that nothing can go too far off), functional languages like Haskell or Scheme, stuff like Erlang, ... > If we could swap out old C compilers for a more generic LLVM compiler > for core components like the kernel, Won't happen until clang generates much better code than GCC; in the meanwhile it'll have to grok all GCC extensions. > userspace libs Ditto (mostly) > and so on. In the > future people might just make the decision to move to D since the > architecture is all there and all their old code works but they get all > the new features. Would need compatilility shims to extant C libraries. Plus people won't just rewrite years of work if it isn't for _massive_ advantages (twice as fast or one tenth of the bugs for little work). > Think of Linux distros being built entirely on LLVM. > There are also the other advantages such as dumping in JIT compilers and > automatic threading in LLVM to take advantage of the many processors > systems are starting to get. Automatic paralelization is still a just a glint in researcher's eyes, some 50 years later... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100724 changes
Rawhide Report wrote:
> systemd-4-3.fc14
>
> * Sat Jul 24 2010 Lennart Poettering - 4-3
> - Add libselinux to build dependencies
>
> * Sat Jul 24 2010 Lennart Poettering - 4-2
> - Use the right tarball
>
> * Sat Jul 24 2010 Lennart Poettering - 4-1
> - New upstream release, and make default
Hummm... _sure_ it doesn't break badly? Last time I tried Gnome was
completely hosed, and normal shudown got stuck.
> upstart-0.6.5-7.fc14
>
> * Sat Jul 24 2010 Casey Dahlin - 0.6.5-7
> - Make upgrades work correctly now that -sysvinit is split off
>
> * Sat Jul 24 2010 Lennart Poettering - 0.6.5-6
> - Split off -sysvinit to make Upstart parallel installable with systemd
Doesn't work. On my systemd-virgin machine systemd isn't installed, and
upstart isn't updated due to conflicts with systemd (or perhaps among
*-sysvinit).
In none of my two machines do {systemd,upstart}-sysvinit get
installed/updated, due to conflicts.
Will need freshen up on broken-rawhide-fu before rebooting.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 2.7 rebuild: maintainer help needed (please!)
2010/7/23 David Malcolm : > I've been running mass rebuilds of python-using packages against python > 2.7 [1] > > We're now down to 202 failing builds, so I'm attaching a by-maintainer > report on them. kwizart (1): python-kaa-display You can re-submit mine, it was waiting for pygame which just succeeded yesterday. Thx Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Using LLVM for build package instead gcc, why not?
LLVM itself could allow for much greater flexibility in programming language choice. It can allow for anyone to take any language and output it in bytecode, machine code, javavm code and so on. If we can rip out the multitude of compilers on different architectures and replace it with one compiler base that does many different languages people might start picking languages based on their merits rather than support (since it just needs LLVM support to be supported). If we could swap out old C compilers for a more generic LLVM compiler for core components like the kernel, userspace libs and so on. In the future people might just make the decision to move to D since the architecture is all there and all their old code works but they get all the new features. Think of Linux distros being built entirely on LLVM. There are also the other advantages such as dumping in JIT compilers and automatic threading in LLVM to take advantage of the many processors systems are starting to get. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Sat, Jul 24, 2010 at 09:10:24AM -0400, Brandon Lozza wrote:
> On Sat, Jul 24, 2010 at 2:54 AM, Jesse Keating wrote:
> > Hey all! It's that time again, we're gearing up to branch for Fedora 14
> > this coming Tuesday! There is a major twist this time around, we're
> > going to attempt a roll out of dist-git!
> --snipped---
>
> I'm just curious but would this allow someone to more easily fork the
> distro? (think of stuff like Mint)
The ability to fork {packages|kernels|distros} is a good thing. It
keeps the software lively and keeps the purveyors of software honest.
I enjoyed reading Rick Moen's essay on the subject:
http://linuxmafia.com/faq/Licensing_and_Law/forking.html
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100724 changes
On Sat, Jul 24, 2010 at 11:43:25AM +, Rawhide Report wrote: > coccinelle-0.2.3-0.rc6.fc14.x86_64 requires ocaml(Ast_cocci) = > 0:5ca197135ff27773239a7db221755543 > coccinelle-0.2.3-0.rc6.fc14.x86_64 requires ocaml(Ast_c) = > 0:adbfffd2c4e2ca8bf9edbb70a6b1b370 > coccinelle-0.2.3-0.rc6.fc14.x86_64 requires ocaml(Token_c) = > 0:ecf19d3c1019a1f5608f1c9e11060c08 > coccinelle-0.2.3-0.rc6.fc14.x86_64 requires ocaml(Type_cocci) = > 0:ac1b032e5952df0152c941c6875d8596 > coccinelle-0.2.3-0.rc6.fc14.x86_64 requires ocaml(Common) = > 0:fc4cb31160459b46d7a79a1c7cf1c581 This should be fixed now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 2.7 rebuild: maintainer help needed (please!)
We worked with upstream and they have come up with a patch which fixes Coccinelle. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
Sounds really amazing! We're watching for the deployment! :) -Ilyes Gouta On Sat, Jul 24, 2010 at 2:10 PM, Brandon Lozza wrote: > On Sat, Jul 24, 2010 at 2:54 AM, Jesse Keating wrote: >> Hey all! It's that time again, we're gearing up to branch for Fedora 14 >> this coming Tuesday! There is a major twist this time around, we're >> going to attempt a roll out of dist-git! > --snipped--- > > I'm just curious but would this allow someone to more easily fork the > distro? (think of stuff like Mint) > -- > 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: Fedora 14 branching and dist-git roll out
On Sat, Jul 24, 2010 at 2:54 AM, Jesse Keating wrote: > Hey all! It's that time again, we're gearing up to branch for Fedora 14 > this coming Tuesday! There is a major twist this time around, we're > going to attempt a roll out of dist-git! --snipped--- I'm just curious but would this allow someone to more easily fork the distro? (think of stuff like Mint) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
ons 2010-07-21 klockan 11:48 -0700 skrev Jesse Keating: > The other option is to make the dist translation change on the other > branches too, so that future f12 and f13 builds have a dist of ".f12" > and ".f13" I was just going to suggest this. f1x means built from git, fc1x means cvs. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100724 changes
Compose started at Sat Jul 24 08:15:20 UTC 2010 Broken deps for x86_64 -- BackupPC-3.1.0-14.1.fc14.noarch requires perl-suidperl PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) almanah-0.7.3-2.fc14.x86_64 requires libecal-1.2.so.7()(64bit) almanah-0.7.3-2.fc14.x86_64 requires libebook-1.2.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) coccinelle-0.2.3-0.rc6.fc14.x86_64 requires ocaml(Ast_cocci) = 0:5ca197135ff27773239a7db221755543 coccinelle-0.2.3-0.rc6.fc14.x86_64 requires ocaml(Ast_c) = 0:adbfffd2c4e2ca8bf9edbb70a6b1b370 coccinelle-0.2.3-0.rc6.fc14.x86_64 requires ocaml(Token_c) = 0:ecf19d3c1019a1f5608f1c9e11060c08 coccinelle-0.2.3-0.rc6.fc14.x86_64 requires ocaml(Type_cocci) = 0:ac1b032e5952df0152c941c6875d8596 coccinelle-0.2.3-0.rc6.fc14.x86_64 requires ocaml(Common) = 0:fc4cb31160459b46d7a79a1c7cf1c581 dates-0.4.11-3.fc14.x86_64 requires libecal-1.2.so.7()(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) deskbar-applet-2.30.0-1.1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) ekiga-3.2.7-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) giggle-0.5-2.fc14.i686 requires libebook-1.2.so.9 giggle-0.5-2.fc14.x86_64 requires libebook-1.2.so.9()(64bit) glabels-2.2.8-2.fc14.x86_64 requires libebook-1.2.so.9()(64bit) glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10 glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit) gnome-python2-brasero-2.31.1-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.31.1-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evolution-2.31.1-1.fc14.x86_64 requires libecal-1.2.so.7()(64bit) gnome-python2-evolution-2.31.1-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) gnome-python2-totem-2.31.1-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnomeradio-1.8-6.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) grads-2.0.a7.1-0.3.fc13.x86_64 requires libdap.so.10()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples lekhonee-gnome-0.11-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit) libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgtk-java-2.8.7-13.fc13.i68
Re: Can anyone contact Balint Christian (rezso)?
On 21 July 2010 13:31, Sven Lankes wrote: > Hi all, > > Following the process > > https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > > Is someone able to get in touch with Christian Balint (rezso)? No, I had no luck so ended up getting co-maintainer of mapnik due to the same issues. Regards -- Christopher Brown -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri 23 July 2010 18:26:29 Lennart Poettering wrote: [snip] > - You can boot into either of them by setting the "init=" kernel cmdline > option according to your wishes. If you pass "init=/bin/systemd" you > will boot into systemd, if you pass "init=/sbin/upstart" you will boot > into upstart (note the /sbin vs. /bin!) [snip] > If systemd does not work for you and you need a temporary fix, pass > "init=/bin/upstart" on the kernel command line. Hmmm? :) -- 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: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)
On 07/07/10 20:16, Thomas Spura wrote: > To get such a button, to apply for becoming real maintainership makes > this possible and is the easiest way, because it doesn't need e.g. a > fast track procedure or anyone agreeing from fesco or anyone to change > it manually in pkgdb. > > When you have another solution for this, let me hear. :) I have an idea that people who spent the hard yards to create a package/improve it enough to get into fedora are proud of their accomplishment - for non-prolific packagers, like my self, having yourself listed as maintainer can be a bit of status symbol. Having to officially say I don't want that any more would not be easy. It would be good if the package db grew a history of (co)maintainers: Package developed: 2007-06-01 fschepsi Retired maintainers: 2009-12-06 -> 2010-04-13 bcandoit 2008-07-01 -> 2009-09-13 jbloggers Anymay, just wanting to put a view from a basic (<10 packages) maintainer. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
