Re:
2011/6/11 Miloslav Trmač : > Hello, > On Sat, Jun 11, 2011 at 2:06 AM, Sergio Belkin wrote: >> ./configure LDFLAGS="-no-install" > >> configure:3659: gcc -no-install conftest.c >&5 >> gcc: error: unrecognized option '-no-install' > >> Do you have any idea? > > -no-install, which the command explicitly includes, is a libtool > option, but not a valid gcc option. I don't know why it is necessary > to use -no-install, but if you do need it, you can probably patch > Makefile* to include it in such a way that the operation of > ./configure is not disrupted. > Mirek > -- I've found an example here: It's useful if someone wants to avoid the wrappers generation (look at the end): http://www.flameeyes.eu/autotools-mythbuster/libtool/wrappers.html Perhaps ./configure LDFLAGS="-no-install" is somewhat "heterodox" -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:
Hello, On Sat, Jun 11, 2011 at 2:06 AM, Sergio Belkin wrote: > ./configure LDFLAGS="-no-install" > configure:3659: gcc -no-install conftest.c >&5 > gcc: error: unrecognized option '-no-install' > Do you have any idea? -no-install, which the command explicitly includes, is a libtool option, but not a valid gcc option. I don't know why it is necessary to use -no-install, but if you do need it, you can probably patch Makefile* to include it in such a way that the operation of ./configure is not disrupted. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Different behaviour on gcc 4.6?
2011/6/10 Kevin Kofler :
> Sergio Belkin wrote:
>> | int
>> | {
>> |
>> |;
>> |return 0;
>> | }
>
> This is not a valid C program. Maybe GCC 4.5 accepted this junk?! GCC 4.6 is
> right to error on it.
>
> Kevin Kofler
>
> --
Thanks Kevin, but not so fast ;) !
it was my fault, I've copied bad the snip, below is the right one,
and that is indeed a valid C program, please take a look (I wonder if
LDFLAGS="-no-install" is no more valid, perhaps someone may want to
test against some source) :
gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC)
configure:3618: $? = 0
configure:3607: gcc -V >&5
gcc: error: unrecognized option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3618: $? = 4
configure:3607: gcc -qversion >&5
gcc: error: unrecognized option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3618: $? = 4
configure:3638: checking whether the C compiler works
configure:3660: gcc -no-install conftest.c >&5
gcc: error: unrecognized option '-no-install'
configure:3664: $? = 1
configure:3702: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "UpTools"
| #define PACKAGE_TARNAME "UpTools"
| #define PACKAGE_VERSION "8.5.5"
| #define PACKAGE_STRING "UpTools 8.5.5"
| #define PACKAGE_BUGREPORT "bugs-upto...@palermo.edu"
| #define PACKAGE_URL ""
| #define PACKAGE "UpTools"
| #define VERSION "8.5.5"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3707: error: in `/tmp/UpTools-8.5.5':
configure:3709: error: C compiler cannot create executables
End of snippet
--
--
Sergio Belkin http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 06/11/2011 05:35 AM, Garrett Holmstrom wrote: > Why would many prospective contributors choose to work on KVM's > desktop usability when VirtualBox's is already superior? Because they like KVM and use it because of other advantages like performance? Because they disagree with handing copyright over to Oracle or contributing code under permissive licenses? They don't want to use third party kernel modules? There could be any number of reasons. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/11/2011 05:20 AM, Genes MailLists wrote: > Lets be blunt here - he pushed very very very hard on these very lists > to get systemd in - now its in F15 and there are problems - so no > punting please. Upstream and fedora are the same for syste That is a gross over simplification. Fedora is just one of the many distros integrating systemd and there are developers from other distros including Novell involved in systemd and contributing to it. If we start discussing every project where Red Hat is heaving involved, that list is long > [1] Yes he spoke with another distro - but no-one is using it. So its a > fedora only project until its picked up somewhere else - which has not > happened yet. That's not true. Mandriva 2011 is already including it by default. So is MeeGo. OpenSUSE has announced that it is using it by default in their next release. Not to mention other distros who have included it in their repos. It is far from a Fedora only project. The proper place for general discussions about systemd is http://lists.freedesktop.org/mailman/listinfo/systemd-devel Only Fedora specific bugs should be discussed here. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
It was for me until this morning. Virtual box killed it (beware of vb). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Different behaviour on gcc 4.6?
Sergio Belkin wrote:
> | int
> | {
> |
> |;
> |return 0;
> | }
This is not a valid C program. Maybe GCC 4.5 accepted this junk?! GCC 4.6 is
right to error on it.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Denys Vlasenko wrote: > Mem total:2035840 anon:431208 map:78924 free:419084 [snip] > 1 15384 11856 13664 1340 11752 0 132 /sbin/init So this singleton process is taking 0.76% of your RAM. What the heck are you complaining about? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning xine-lib, EOL'ing phonon-backend-xine
Rex Dieter wrote: > The labor of love that was maintaining xine-lib has passed, as it will no > longer be a dependency in f16's kde stack in any form. As such, I'm > orphaning it. Kevin Kofler has offered to take ownership, though I'd > venture he'd welcome any comaintainer assistance offered. FWIW, there's one third-party KDE-Platform-based application still using xine-lib for the foreseeable future: Kaffeine. That package was also orphaned, I picked it up too. > In a similar vein, phonon-backend-xine has officially been deprecated and > is no longer supported. We'll be EOL'ing this one soon. It's indeed time for that one to just go away, phonon-backend-gstreamer is now the better solution. I'm not going to attempt resurrecting phonon- backend-xine unless upstream suddenly changes their mind about the recommended Phonon backend again and brings it back from the ashes (but xine-lib itself would need a sudden reinjection of life as well). We've been doing the switch step by step: * Fedora 9, 10 and 11 installed only phonon-backend-xine by default. * Fedora 12, 13 and 14 installed both phonon-backend-xine and phonon- backend-gstreamer by default and defaulted to phonon-backend-xine. * Fedora 15 only installs phonon-backend-gstreamer by default. phonon- backend-xine is still in the repository, but will not be used by default even when installed. * Fedora 16 will only support phonon-backend-gstreamer. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 03:13 PM, Rahul Sundaram wrote: > what would be really nice is to redirect systemd discussions to its > upstream mailing list. Fedora devel is hardly the best place for it. > > Rahul Beg to differ - rather vehemently too - politely but vehemently. systemd is only available in fedora[1] - we are the test pigs for better or for worse - and there are most certainly bugs in fedora's systemd. Lets be blunt here - he pushed very very very hard on these very lists to get systemd in - now its in F15 and there are problems - so no punting please. Upstream and fedora are the same for systemd. Some bugs like sendmail failing to start have been there since September 2010 ( almost 9 months ... ) - people are reporting the same issue on F15 in the fedora lists ... who is fixing this stuff ? e.g. https://bugzilla.redhat.com/show_bug.cgi?id=692008 https://bugzilla.redhat.com/show_bug.cgi?id=633774 Ok so he's on vacation - this is a very core part of the OS - who is backing him up I wonder? Who else is on the project? Surely you're not saying there is no-one else working on systemd... and when LP is away/busy nothing will get done ... otherwise I strongly urge it be replaced by upstart asap. gene/ [1] Yes he spoke with another distro - but no-one is using it. So its a fedora only project until its picked up somewhere else - which has not happened yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Different behaviour on gcc 4.6?
Sorry, I was typing on a netbook :P and the mail it was sent without subject -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[no subject]
Hi,
I've noted a difference between f15 and f14 on the first one
mentioned, running the following it fails:
./configure LDFLAGS="-no-install"
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/tmp/UpTools-8.5.4':
configure: error: C compiler cannot create executables
See `config.log' for more details
On config.log
you can see:
gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC)
configure:3617: $? = 0
configure:3606: gcc -V >&5
gcc: error: unrecognized option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3617: $? = 4
configure:3606: gcc -qversion >&5
gcc: error: unrecognized option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3617: $? = 4
configure:3637: checking whether the C compiler works
configure:3659: gcc -no-install conftest.c >&5
gcc: error: unrecognized option '-no-install'
configure:3663: $? = 1
configure:3701: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "UpTools"
| #define PACKAGE_TARNAME "UpTools"
| #define PACKAGE_VERSION "8.5.4"
| #define PACKAGE_STRING "UpTools 8.5.4"
| #define PACKAGE_BUGREPORT "bugs-upto...@palermo.edu"
| #define PACKAGE_URL ""
| #define PACKAGE "UpTools"
| #define VERSION "8.5.4"
| /* end confdefs.h. */
|
| int
| {
|
| ;
| return 0;
| }
configure:3705: error: in `/tmp/UpTools-8.5.4':
configure:3707: error: C compiler cannot create executables
The same script doesn't fail on F14.
Do you have any idea?
Thanks in advance!
--
--
Sergio Belkin http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, Jun 10, 2011 at 12:11 PM, Richard W.M. Jones wrote: > Customers ask us to make the changes they want -- for server use and > scalability -- and KVM is absolutely the best in that area as a > result. See many recent benchmarks. > > Usability on single desktops is, well ... we do our best. > > If you want excellent desktop usability, then organize a group and > make the work and patches happen. Why would many prospective contributors choose to work on KVM's desktop usability when VirtualBox's is already superior? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
Quoting "Przemek Klosowski" : > > Make it one command: > > yum install > http://download.virtualbox.org/virtualbox/4.0.8/VirtualBox-4.0-4.0.8_71778_fedora15-1.x86_64.rpm > > (or VirtualBox-4.0-4.0.8_71778_fedora15-1.i686.rpm for 32-bit systems) > OMG, I am such a dick for not even thinking of that! The problem is, I use Ubuntu/APT also, so sometimes I can confuse myself as to which system (yum/apt) does what. Nice work. Cheers Chris Jones This message was sent using IMP, the Internet Messaging Program. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
Quoting "Thomas Sailer" : > > Also, I have a strange card reader which I would love to use under some > form of virtualisation, as the accompanying application only runs under > very old versions of windows. > > The card reader has the misfeature that it requires firmware to be > loaded by the PC. To get the firmware, it connects, waits about 4 > seconds, and if it doesn't get anything it disconnects and reconnects > again. Now qemu/kvm is currently much too slow for this, until the host > notices the USB device and hands it over to the guest, about 5-10sec > pass. > > Tom I'd suggest you purchase a new card reader. You do realize you can pick them up for around $10? If I had a card reader with that much drama just to get it to operate, it'd be out the door in no time! Cheers Chris Jones This message was sent using IMP, the Internet Messaging Program. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd memory usage
On Fri, 2011-06-10 at 15:55 -0400, Adam Jackson wrote: > On 6/10/11 9:07 AM, Denys Vlasenko wrote: > > > At the very least, I would like to see its memory consumption > > to go down substantially. > > Let's try to turn this into something constructive. I'll start with > David Malcolm's rather nifty, if unpolished, 'heap' plugin for gdb: > > https://fedorahosted.org/gdb-heap/wiki Woot! Fame at last! :) Various comments inline below... > Simply running the 'heap' command tells me that systemd is using 21M of > malloc'd data, and that about 11M of it is entirely within allocations > that are all 2064 bytes apiece. Everything else, in comparison, is > pretty insignificant: > > Domain KindDetailCount Allocated size > - --- --- -- > uncategorized 2064 bytes5,370 11,083,680 [...snip...] "uncategorized" means that gdb-heap doesn't know how to deal with bytes in question. If it's from a library, and you figure out what the above is, we could add a categorizer for it. > C string data 12,964 630,672 ... > TOTAL 127,119 21,934,576 > That's a pretty unusual size, 2064 bytes. That works out to 2048 + 16, > though, which are much more natural-sounding numbers. A quick > experiment with a demo program (allocate a 32-byte struct and then call > pause()) shows that the 16 is actually the overhead from malloc itself: > > Domain KindDetail Count Allocated size > - - -- > uncategorized48 bytes 1 48 > TOTAL 1 48 Yes: IIRC, the "size" is actually the offset to the next chunk. glibc's malloc allocates two size_t fields at the top of each chunk. > So now the problem is simply to find a 2048-sized allocation within > systemd, or one of its libraries. Anyone interested in a homework problem? gdb-heap has a search/querying feature: If you run : (gdb) heap select size == 2048 it will try to show addresses and partial hexdumps of the relevant buffers. (I _think_ so, but you might need 2064 instead). The addresses it reports are those of where the allocation begins (as seen by the program) i.e. it does the offset for you. Given an address, there's also a (gdb) hexdump ADDR command, which you can use to scroll through memory. If you stare at the hexdump you can sometimes figure out what the data is. If you think that an allocation is of some given type, you can also try casting the data, e.g.: (gdb) print *(some_struct*)ADDR and see if looks meaningful. Hope this is helpful. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 04:44 PM, mike cloaked wrote: > On Fri, Jun 10, 2011 at 8:13 PM, Rahul Sundaram wrote: >> On 06/11/2011 12:36 AM, mike cloaked wrote: >>> Would be nice to see the systemd author join this discussion? >> >> I am sure you can get answers when someone is off vacation. However >> what would be really nice is to redirect systemd discussions to its >> upstream mailing list. Fedora devel is hardly the best place for it. >> >> Rahul > > OK I guess we'll get more discussion when he comes back from his > holiday - sorry I was unaware of the vacation but thanks for > clarifying. > > I guess that your reference to moving to upstream indicates that > systemd is now sufficiently established that discussion of problems is > an upstream issue for bug triage/fixing? I would imagine that the user > list may have useful exchanges too but that it would be important to > get any issues moved upstream from there too? The most important > outcome is that bugs are fixed so whatever route is best for that > (including bugzilla of course) users should add input to. Hence links > to upstream for systemd are made available so that the best exposure > to recourse to resolution is optimised? > I hope discussions continue on Fedora lists as well. systemd impacts lots of fedora users who just read Fedora lists. I've subscribed to gnome, network manager, btrfs, virt, lvm, selinux, anaconda, kickstart, desktop, and etc. Sure, folks subscribe to more lists than that, but when you can't spend much timre reading the lists, having discussions concentrated in your distro of choice's lists frees up precious time to actively participate in testing. As a Fedora user and tester it is far easier to just peruse the Fedora lists. Once systemd settles in and is no longer viewed with suspicion, then maybe add upstream for the rare issue. Please don't be a wet blanket, folks, let the discussions continue here. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd memory usage
On Fri, 10 Jun 2011 15:55:14 -0400 Adam Jackson wrote: > Domain KindDetailCount Allocated size > - --- --- -- > uncategorized 2064 bytes5,370 11,083,680 Probably the SELinux file labelling database, all the regexes. Related to https://bugzilla.redhat.com/show_bug.cgi?id=709014#c2 Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide missed an implicit dependency for #!python
On Fri, 10 Jun 2011 13:59:18 +0300 Panu Matilainen wrote: > On 06/10/2011 02:28 AM, Josh Stone wrote: > > On 06/02/2011 01:26 PM, Josh Stone wrote: > >> Our dtrace script in systemtap-sdt-devel starts > >> "#!/usr/bin/python". Usually this leads to an implicit > >> "Requires: /usr/bin/python", but for some reason our rawhide build > >> did not get this. The F15, F14, and F13 builds from the same spec > >> required python as expected. > > [...] > >> Is this a bug? Or must we now explicitly require python? > > > > An output change in file-5.07 appears to have broken find-requires: > > https://bugzilla.redhat.com/show_bug.cgi?id=712251 > > > > And since file-5.07-2.fc15 is now in updates, I would expect this to > > cause even more problems going forward. > > Fixed now in rawhide rpm and an update for F15 is here: > https://admin.fedoraproject.org/updates/rpm-4.9.0-9.fc15 > > Please help testing to get this nasty regression fixed ASAP. > > ALL packages containing scripts which have been built while file-5.07 > has been in rawhide (since May 11th) & F15 (in updates-testing since > May 23rd) are affected and will have missing dependencies because of > this, requiring rebuilds to correct the situation. > > Thanks Josh for reporting this, and also apologies for missing your > initial mail on the subject, reacting then would've saved a week's > worth of broken builds :-/ Is there a way we can generate a list of builds affected? Is it everything? Or things that only have a specific type of requires? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Fri, Jun 10, 2011 at 09:23:54PM +0200, Haïkel Guémar wrote:
> Le 10/06/2011 18:56, Toshio Kuratomi a écrit :
> >
> > I don't actually see this. Could you point me to the quote and section?
> >
>
>
> "/usr/libincludes object files, libraries, and internal binaries that
> are not intended to be executed directly by users or shell scripts."
> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
>
Ah -- in your original mesage you said that FHS explicitly blessed /usr/lib
as a place for shell scripts... which is not what this is saying. However,
the description of internal binaries might fit the bill -- the FHS (and
Fedora's usage) of "binaries" is not always consistent. Sometimes it is
equivalent to "object files" and other times it is equivalent to
"executables". If we interpret this as "executable" then I think it works.
Note that this portion of the FHS is in direct conflict with the GNU Coding
standards which explicitly says not to use libdir in this way :-(
>
> > Additionally, the GNU Coding standards explicitly prohibit this (to be clear
> > the GNU coding standards are not definitive for Fedora like the FHS is at
> > this time; I'm including the quotation to show what current best practices
> > are in this regard):
> > """
> > ‘libdir’
> > The directory for object files and libraries of object code. Do not install
> > executables here, they probably ought to go in ‘$(libexecdir)’ instead.
> > """
> >
> > At similar weight is the fact that some programs currently violate the GNU
> > Coding Standard recommendation here. However, I can't think of one of those
> > off the top of my head that is a unix-y program so those may be more
> > workaround than paradigm setters.
> >
> good to know
>
> > Preference-wise, I would say $LIBEXECDIR; settable at build time to
> > /usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is
> > the best method here. Since we're talking scripts (architecture
> > independent), /usr/share may also make sense but I'm not a big fan of it.
> > If you can find me the piece of FHS that explicitly allows shell scripts in
> > /usr/lib I can figure out how that compares to using /usr/lib.
> >
> >
> > -Toshio
> +1
>
> I spent some time yesterday talking with opensuse guys on irc, since
> /usr/libexec has not been blessed by FHS, they won't move helpers from
> /usr/lib which is FHS-compliant location.
>
Is this stuff a GNU configure compiled program? Or does it have
a different build system? (You could point me at the tarball/review request
and I could take a look).
> I think that packaging guidelines should clarify this point, either we
> enforce the use of /usr/libexec (and current packages should be fixed)
> or we explicitely allow /usr/lib and/or /usr/share for helpers.
>
> Personnally, i don't feel like burdening the reviewee with a non-FHS
> compliant patch that has little chance to be upstreamed if it's not
> mandatory.
>
I just reread the thread where we discussed the pros and cons of libexecdir
and here's the take aways for when and why to use libexecdir:
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/25433/
1) Determine if the program cares about the wordsize of the helpers.
* Are the helper programs mandatorily architecture independent or could
they be arch dependent (ex: It's only convenient to write them in shell,
the helpers could be written in C and compiled instead).
* If it's only convenience, how likely is it that helpers would be written
in a compiled language? Would upstream consider it a bug if someone
wrote a helper in a compiled language?
2.a) If the program does not care about the wordsize, then options are
libexecdir or datadir.
* Of the two, libexecdir is mandatory if architecture-specific helpers are
allowed.
* libexecdir is likely better even if architecture-specific helpers are
not allowed as datadir is for data files and executable code is
something of a stretch to classify that way.
* Finally, see the last bullet of 2.b) for what the ramifications of using
%{_libdir} are and whether that's acceptable in this specific case.
2.b) If the program does care about wordsize, then you need to use %_libdir
which will either be /usr/lib or /usr/lib64 on Fedora. The application
(or config file) will need to be compiled/configured to know which path
to use based on compilation (note that this may require a patch to
upstream as well).
* If the program does not care about wordsize but you put it into
%{_libdir} anyway, you force helpers in separate packages/subpackages to
be packaged arch-specific even though the only difference is the path
pointed to by %{_libdir}. This is a pain but it's something that can
be survived as long as people realize that they have to do this. It
doesn't have as significant an impact if all of the helpers are in the
original package; helpers don't get added to by separat
Re: systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 9:44 PM, mike cloaked wrote: > I guess that your reference to moving to upstream indicates that > systemd is now sufficiently established that discussion of problems is > an upstream issue for bug triage/fixing? I would imagine that the user > list may have useful exchanges too but that it would be important to > get any issues moved upstream from there too? The most important > outcome is that bugs are fixed so whatever route is best for that > (including bugzilla of course) users should add input to. Hence links > to upstream for systemd are made available so that the best exposure > to recourse to resolution is optimised? > I also presume that by upstream you are referring to http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, 2011-06-10 at 15:06 -0500, Bruno Wolff III wrote: > On Fri, Jun 10, 2011 at 20:17:46 +0100, > "Richard W.M. Jones" wrote: > > > > Works very well for me, but: > > > > - Make sure you're running kernel-3.0-0.rc2.git0.2.fc16 with the > > ftrace bug fixed (thanks Kyle). > > Done. > > > - Make sure you upgrade module-init-tools *before* installing the 3.0 > > kernel. > > Done. > > > - Make sure you've got the latest udev. > > Done. > > Looks like I need to spend some time capturing the error and filling out > a bug report. > > Thank you everyone, for the feedback. I had problems too. I guess that is was something in the initramfs. I ended up removing the 3.0 kernels and then re-install it (yum update). That solved it for me Louis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 8:13 PM, Rahul Sundaram wrote: > On 06/11/2011 12:36 AM, mike cloaked wrote: >> Would be nice to see the systemd author join this discussion? > > I am sure you can get answers when someone is off vacation. However > what would be really nice is to redirect systemd discussions to its > upstream mailing list. Fedora devel is hardly the best place for it. > > Rahul OK I guess we'll get more discussion when he comes back from his holiday - sorry I was unaware of the vacation but thanks for clarifying. I guess that your reference to moving to upstream indicates that systemd is now sufficiently established that discussion of problems is an upstream issue for bug triage/fixing? I would imagine that the user list may have useful exchanges too but that it would be important to get any issues moved upstream from there too? The most important outcome is that bugs are fixed so whatever route is best for that (including bugzilla of course) users should add input to. Hence links to upstream for systemd are made available so that the best exposure to recourse to resolution is optimised? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 20:17:46 +0100, "Richard W.M. Jones" wrote: > > Works very well for me, but: > > - Make sure you're running kernel-3.0-0.rc2.git0.2.fc16 with the > ftrace bug fixed (thanks Kyle). Done. > - Make sure you upgrade module-init-tools *before* installing the 3.0 > kernel. Done. > - Make sure you've got the latest udev. Done. Looks like I need to spend some time capturing the error and filling out a bug report. Thank you everyone, for the feedback. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 15:09:02 -0400, "Clyde E. Kunkel" wrote: > > Couldn't tell you about lockups since if root is on anything with raid > underlying, dracut drops to a shell. You are on the bz: > > https://bugzilla.redhat.com/show_bug.cgi?id=710646 > > Hopefully, someone with apply the patch provided in the bz. I would if > I knew how and had access. I did a local build with the patch, so I get past that point. The person who made the patch requested commit access to mdadm, but it hasn't been approved yet. The lvm2 fix is already in rawhide. mdadm really should have a co-maintainer, this isn't the first time an important update has been delayed because the owner wasn't available. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd memory usage
On 6/10/11 9:07 AM, Denys Vlasenko wrote: > At the very least, I would like to see its memory consumption > to go down substantially. Let's try to turn this into something constructive. I'll start with David Malcolm's rather nifty, if unpolished, 'heap' plugin for gdb: https://fedorahosted.org/gdb-heap/wiki Simply running the 'heap' command tells me that systemd is using 21M of malloc'd data, and that about 11M of it is entirely within allocations that are all 2064 bytes apiece. Everything else, in comparison, is pretty insignificant: Domain KindDetailCount Allocated size - --- --- -- uncategorized 2064 bytes5,370 11,083,680 uncategorized 32 bytes 70,788 2,265,216 uncategorized 1072 bytes1,503 1,611,216 uncategorized 96 bytes 11,420 1,096,320 C string data 12,964 630,672 uncategorized 528 bytes1,067 563,376 uncategorized 528384 bytes1 528,384 uncategorized 272 bytes1,894 515,168 uncategorized 64 bytes6,342 405,888 uncategorized 48 bytes8,446 405,408 /* a bunch of stuff in between omitted */ uncategorized 2272 bytes1 2,272 uncategorized 1568 bytes1 1,568 uncategorized 800 bytes1 800 TOTAL 127,119 21,934,576 That's a pretty unusual size, 2064 bytes. That works out to 2048 + 16, though, which are much more natural-sounding numbers. A quick experiment with a demo program (allocate a 32-byte struct and then call pause()) shows that the 16 is actually the overhead from malloc itself: Domain KindDetail Count Allocated size - - -- uncategorized48 bytes 1 48 TOTAL 1 48 So now the problem is simply to find a 2048-sized allocation within systemd, or one of its libraries. Anyone interested in a homework problem? - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Le vendredi 10 juin 2011 à 21:23 +0200, Haïkel Guémar a écrit : > I spent some time yesterday talking with opensuse guys on irc, since > /usr/libexec has not been blessed by FHS, they won't move helpers from > /usr/lib which is FHS-compliant location. > I think that packaging guidelines should clarify this point, either we > enforce the use of /usr/libexec (and current packages should be fixed) > or we explicitely allow /usr/lib and/or /usr/share for helpers. Or better, since the FHS process has been re-started, people that feel strongly about something not covered by the current FHS version should just make the effort to push the changes they want in the next FHS revision. This way everyone else can just continue to require strict FHS compliance and not bother with special not-really-documented exceptions -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
Richard W.M. Jones wrote: > If you want excellent desktop usability, then organize a group and > make the work and patches happen. I knew this would be the response, but I do not hold it against you. If anyone wants to hire me and pay me to do this full-time job's worth of work I'd be glad to. ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Le 10/06/2011 18:56, Toshio Kuratomi a écrit : > > I don't actually see this. Could you point me to the quote and section? > "/usr/libincludes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts." http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA > Additionally, the GNU Coding standards explicitly prohibit this (to be clear > the GNU coding standards are not definitive for Fedora like the FHS is at > this time; I'm including the quotation to show what current best practices > are in this regard): > """ > ‘libdir’ > The directory for object files and libraries of object code. Do not install > executables here, they probably ought to go in ‘$(libexecdir)’ instead. > """ > > At similar weight is the fact that some programs currently violate the GNU > Coding Standard recommendation here. However, I can't think of one of those > off the top of my head that is a unix-y program so those may be more > workaround than paradigm setters. > good to know > Preference-wise, I would say $LIBEXECDIR; settable at build time to > /usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is > the best method here. Since we're talking scripts (architecture > independent), /usr/share may also make sense but I'm not a big fan of it. > If you can find me the piece of FHS that explicitly allows shell scripts in > /usr/lib I can figure out how that compares to using /usr/lib. > > > -Toshio +1 I spent some time yesterday talking with opensuse guys on irc, since /usr/libexec has not been blessed by FHS, they won't move helpers from /usr/lib which is FHS-compliant location. I think that packaging guidelines should clarify this point, either we enforce the use of /usr/libexec (and current packages should be fixed) or we explicitely allow /usr/lib and/or /usr/share for helpers. Personnally, i don't feel like burdening the reviewee with a non-FHS compliant patch that has little chance to be upstreamed if it's not mandatory. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 01:19:25PM -0500, Bruno Wolff III wrote: > The 3.0 kernels are not working for me. (A cpu lockup is reporting during > boot.) I am wondering if things are broken for everyone where I should > probably just wait for updates and try again, or if I should get a picture > of the traceback and file a bug? Works very well for me, but: - Make sure you're running kernel-3.0-0.rc2.git0.2.fc16 with the ftrace bug fixed (thanks Kyle). - Make sure you upgrade module-init-tools *before* installing the 3.0 kernel. - Make sure you've got the latest udev. - I'm only running them under KVM, not on baremetal. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/11/2011 12:36 AM, mike cloaked wrote: > Would be nice to see the systemd author join this discussion? I am sure you can get answers when someone is off vacation. However what would be really nice is to redirect systemd discussions to its upstream mailing list. Fedora devel is hardly the best place for it. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, Jun 10, 2011 at 02:13:39PM -0400, Neal Becker wrote: > Just to followup, to setup bridged net on kvm I need to reboot my server. > That's a non-starter. I would be very surprised if rebooting was really needed. (But conversely *not* very surprised if the instructions said you need to reboot because explaining how to do it without that is harder ...) In fact the instructions I'm reading say you need to restart the network service (not strictly necessary either). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, Jun 10, 2011 at 10:12:50AM -0500, Michael Cronenworth wrote: > Richard W.M. Jones wrote: > > They are available, but I think you have to build them yourself from > > source. All the information is here: > > This is not an argument for libvirt/kvm/qemu/spice but against. > > Here's some constructive advice: > > 1. Give the Red Hat virtualization tools one, unique name and package it > under that name. Having a new name for every new feature isn't helping > your cause. Call it "RHVM" even. Anything is better than the current > situation and I'm sure a marketing wizard would love to tackle this. > 2. Make guest additions dead simple to install. Having to compile them > with a Windows DDK is not dead simple. > 3. Transparent network access. Having to setup bridges or manually edit > config files is a big turn off to some folks. I know virt-manager has a > GUI for some operations, but I still see editing config files a > recommended method in recent mailing list postings. > 4. Support USB 2.0+ in a easy-to-use way. Under VB, I can just click on > a device I want to use, while the VM is running, and use it. When I'm > done, I uncheck the device, again, while the VM is running, and it > disconnects from the VM and returns for use to my Fedora box. > 5. Exporting VMs must be a two-click process. Not a 9 command, terminal > operation. Importing VMs must be just as easy. As they say, you get what you pay for. Customers ask us to make the changes they want -- for server use and scalability -- and KVM is absolutely the best in that area as a result. See many recent benchmarks. Usability on single desktops is, well ... we do our best. If you want excellent desktop usability, then organize a group and make the work and patches happen. 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: Are 3.0 kernels working for anyone?
On 06/10/2011 02:19 PM, Bruno Wolff III wrote: > The 3.0 kernels are not working for me. (A cpu lockup is reporting during > boot.) I am wondering if things are broken for everyone where I should > probably just wait for updates and try again, or if I should get a picture > of the traceback and file a bug? Couldn't tell you about lockups since if root is on anything with raid underlying, dracut drops to a shell. You are on the bz: https://bugzilla.redhat.com/show_bug.cgi?id=710646 Hopefully, someone with apply the patch provided in the bz. I would if I knew how and had access. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 11:54 AM, Jerry James wrote: > On Fri, Jun 10, 2011 at 12:19 PM, Bruno Wolff III wrote: >> The 3.0 kernels are not working for me. (A cpu lockup is reporting during >> boot.) I am wondering if things are broken for everyone where I should >> probably just wait for updates and try again, or if I should get a picture >> of the traceback and file a bug? > > I've been using today's x86_64 Rawhide kernel with no problems. I had > to attempt a boot 6 times before I finally got the i686 version off > the ground, though. Twice udev segfaulted during boot, and I got some > kind of lockup (perhaps what you are seeing) on the other 3 attempts. > But the 6th time, it worked great. > > Unlike Tom's experience, the gdm login screen looked fine for me on > both x86_64 and i686. > -- > Jerry James > http://www.jamezone.org/ Didn't mention: exclusively using x86_64 version. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 5:58 PM, Denys Vlasenko wrote: > On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote: >> On 06/10/2011 03:59 PM, Steve Clark wrote: >> > On 06/10/2011 09:36 AM, Michal Schmidt wrote: >> >> systemd does not take the system down when it crashes. It catches the >> >> signal, dumps core and freezes, but does not exit. >> >> ^^^ >> > So you just end up with a "froze" system instead of a crashed system >> >> No, only systemd freezes itself. Other processes continue running. > > systemd-26/src/main.c::crash() is the function which does it. > Assuming it will not recurse by crashing again, of course. It calls > log_error and assert_se, which go into log_dispatch(), which logs to > syslog, may try to write to klog, and whatnot... this doesn't look > too robust to me. > > But anyway. Assuming it successfully froze. Does it help? > Yes. How much? Well, it's better than instant oops which happens > when PID 1 exits, but reaping of processes reparented > to init will stop, which, for example, makes the hang from pid > exhaustion just a question of time. > > Ultimately, this stems from the decision to make systemd > to run as PID 1 process. Are there technical reasons for this? > Would be nice to see the systemd author join this discussion? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 12:19 PM, Bruno Wolff III wrote: > The 3.0 kernels are not working for me. (A cpu lockup is reporting during > boot.) I am wondering if things are broken for everyone where I should > probably just wait for updates and try again, or if I should get a picture > of the traceback and file a bug? I've been using today's x86_64 Rawhide kernel with no problems. I had to attempt a boot 6 times before I finally got the i686 version off the ground, though. Twice udev segfaulted during boot, and I got some kind of lockup (perhaps what you are seeing) on the other 3 attempts. But the 6th time, it worked great. Unlike Tom's experience, the gdm login screen looked fine for me on both x86_64 and i686. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 11:19 AM, Bruno Wolff III wrote: > The 3.0 kernels are not working for me. (A cpu lockup is reporting during > boot.) I am wondering if things are broken for everyone where I should > probably just wait for updates and try again, or if I should get a picture > of the traceback and file a bug? > -- "Boots for me" on Thinkpad X200 with SELinux enforcing. gdm-greeter screen is scrambled, but if I blindly enter login/password, gnome comes up just fine. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Are 3.0 kernels working for anyone?
The 3.0 kernels are not working for me. (A cpu lockup is reporting during boot.) I am wondering if things are broken for everyone where I should probably just wait for updates and try again, or if I should get a picture of the traceback and file a bug? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
Neal Becker wrote: > Dave Jones wrote: > >> On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote: >> > On Thu, Jun 09, 2011 at 08:01:06PM +1000, Chris Jones wrote: >> > >> > > I agree. As virtualization technology becomes more and more involved >> > > and frequent on users systems, particularly with advanced Linux users, >> > > I think there needs to be a strong focus on ensuring that all releases >> > > run in virtualized environments without any major issues. ie. >> > > Virtualbox. >> > > >> > > Perhaps a dedicated team among the developers who specialize in this >> > > area. >> > >> > I don't think there are any developers working on this area, where "this >> > area" is Virtualbox. We don't ship Virtualbox. We don't ship a kernel >> > that has any knowledge of Virtualbox. There's a good argument for having >> > this be part of the QA process and requiring that we boot in the common >> > virtualisation environments as part of the release criteria, but I don't >> > think we can realistically suggest that our virtualisation developers >> > (who work on code that has nothing to do with Virtualbox) be responsible >> > for that. >> >> I'm curious why virtualbox has gained so much inertia so quickly. >> Based solely on the number of kernel bug reports we get that seem to be >> related to it, I have almost zero confidence in it being reliable. >> >> Why are people choosing it over other solutions, and what can we change >> in qemu/kvm to get users using that instead ? >> >> Dave >> > > 1. Easy setup of networking (bridged). Just to followup, to setup bridged net on kvm I need to reboot my server. That's a non-starter. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning xine-lib, EOL'ing phonon-backend-xine
The labor of love that was maintaining xine-lib has passed, as it will no longer be a dependency in f16's kde stack in any form. As such, I'm orphaning it. Kevin Kofler has offered to take ownership, though I'd venture he'd welcome any comaintainer assistance offered. In a similar vein, phonon-backend-xine has officially been deprecated and is no longer supported. We'll be EOL'ing this one soon. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: protobuf .so version bump in Rawhide
Hello all, I've pushed the latest protobuf-2.4.1 to Rawhide, which bumps libprotobuf.so.6 to libprotobuf.so.7. This appears to affect the following "base" packages: * libcompizconfig * mozc * mumble * protobuf-c The primary maintainers of the above have been BCC'd. Thanks. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bodhi v0.8 in production
https://admin.fedoraproject.org/updates Frontend Web/Client Changes --- * Buildroot Override Management http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides * Make update notes mandatory (fesco#457) * Gracefully handle invalid update template values (#597) * Fixed a bug that would prevent people from editing updates Backend Changes --- * Support blacklisting certain users from receiving bodhi emails (for autoqa) * More robust handling of 'pending' koji tags (#594) * More configurable for non-Fedora deployments * Added more metrics to our report generator * # of updates that reach the stable karma threshold * # of updates that spent the minimum time in testing * # of proventester karma types * output: https://fedorahosted.org/fesco/ticket/517#comment:5 API Changes --- * Optimize our 'list' API when querying updates by bug number (#610) * Support adding comments without triggering email notifications (to prevent AutoQA spamming) signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: Bug 706472 - [console] java exception throw in UI, but user gets created
https://bugzilla.redhat.com/show_bug.cgi?id=706472 https://bugzilla.redhat.com/attachment.cgi?id=504157&action=diff https://bugzilla.redhat.com/attachment.cgi?id=504159 https://bugzilla.redhat.com/attachment.cgi?id=504157&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 9:07 AM, Denys Vlasenko wrote: > > It's the *fourth* largest process on my system! > > > # ldd `which systemd` 1) Looking at what libraries a binary links to a is a terrible way to optimize memory usage; try massif, say 2) It'd be a lot more productive to be positive and not phrase your message in such an antagonistic way (in fact, this message would probably be better on the systemd-devel mailing list) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 08:42 PM, Denys Vlasenko wrote: > On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote: >>> Why does systemd link against libpam? >>> systemd does logins now, not /bin/login or gdm or ...? >> >> to implement PAMName= (man systemd.exec) > > I don't see any users of this feature on my F15. > I searched with Google and come up empty too. > > But anyway, assuming it's a useful feature, why it has to be done by > systemd? > > I looked at implementation. > systemd-26/src/execute.c::setup_pam(): > > /* We set up PAM in the parent process, then fork. The child > * will then stay around until killed via PR_GET_PDEATHSIG or > * systemd via the cgroup logic. It will then remove the PAM > * session again. The parent process will exec() the actual > * daemon. We do things this way to ensure that the main PID > * of the daemon is the one we initially fork()ed. */ > > I don't see any attempt to free at least something in the child. > So, systemd forks a process with eleven megabyte of malloced stuff > to act just as a babysitter - wait for parent to die, call pam_end, > exit? > For how long will it hang around in the system - possibly days? > > Yes, COW, so not all of these eleven megabytes will be around... > ...at first, until parent execs, or modifies sufficiently many pages > so that most of them are copied. > > But memory consumption is not really the gist of my argument, it's: > why systemd tries to be all things for all people? > > Why it has to care about PAM? I think most tools which need it do it > themselves, and we can write a small, really small helper for those > which don't. > > >>> libwrap? systemd is a network application now too? >> >> to implement TCPWrapName= (man systemd.exec) > > Again, why it has to be done *by systemd*? > > > > > On Fri, 2011-06-10 at 10:09 -0400, Steve Clark wrote: >>> Yes, whatever happened to the *NIX philosophy of simple non-complex >> programs that did their job well. It has seemed to serve well since >> the 70's. > > Exactly my point. > It looks like it is the right time to think about upstart again. I will definitely check it out on rawhide. Thanks to OP for pointing on some difficulties. More important that it will be not so easy to clean that all up latter and we will get eventually unmanageable windows. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote: > On 06/10/2011 03:59 PM, Steve Clark wrote: > > On 06/10/2011 09:36 AM, Michal Schmidt wrote: > >> systemd does not take the system down when it crashes. It catches the > >> signal, dumps core and freezes, but does not exit. > >> ^^^ > > So you just end up with a "froze" system instead of a crashed system > > No, only systemd freezes itself. Other processes continue running. systemd-26/src/main.c::crash() is the function which does it. Assuming it will not recurse by crashing again, of course. It calls log_error and assert_se, which go into log_dispatch(), which logs to syslog, may try to write to klog, and whatnot... this doesn't look too robust to me. But anyway. Assuming it successfully froze. Does it help? Yes. How much? Well, it's better than instant oops which happens when PID 1 exits, but reaping of processes reparented to init will stop, which, for example, makes the hang from pid exhaustion just a question of time. Ultimately, this stems from the decision to make systemd to run as PID 1 process. Are there technical reasons for this? -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Thu, Jun 09, 2011 at 12:14:45PM +0200, 80 wrote: > Hi, > > I'm reviewing osc and osc-source_validators (osc is Opensuse Build > Service CLI, the latter a plugin to the former). > An issue arose about helpers script location: > 1) Fedora packaging guidelines suggests helpers *should go* > /usr/libexec for helpers ==> requires patching since osc search > helpers in /usr/lib > since it's not in FHS, it's almost certain that a patch won't be upstream-able > This would be the most proper location on Fedora. Note that many upstreams do take patches of this sort as long as the libexecdir is settable. libexecdir is a GNU Coding Standard directory; on Debian or other systems that disallow /usr/libexecdir, libexecdir gets set to /usr/lib. http://www.gnu.org/prep/standards/html_node/Directory-Variables.html > 2) FHS explicitely allows shell scripts in /usr/lib I don't actually see this. Could you point me to the quote and section? Additionally, the GNU Coding standards explicitly prohibit this (to be clear the GNU coding standards are not definitive for Fedora like the FHS is at this time; I'm including the quotation to show what current best practices are in this regard): """ ‘libdir’ The directory for object files and libraries of object code. Do not install executables here, they probably ought to go in ‘$(libexecdir)’ instead. """ At similar weight is the fact that some programs currently violate the GNU Coding Standard recommendation here. However, I can't think of one of those off the top of my head that is a unix-y program so those may be more workaround than paradigm setters. > 3) FHS doesn't forbid putting them in /usr/share as helpers could be > considered as "arch independent data" > > There are recent packages that choose options 2 && 3 (namely, systemd > and dracut). > According to me, guidelines doesn't enforce any of these options, and > choice is left to packager/reviewer appreciation, though you may > distinguish an order of precedence. > > So, what's the take of my fellow packagers on that particular matter ? > Preference-wise, I would say $LIBEXECDIR; settable at build time to /usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is the best method here. Since we're talking scripts (architecture independent), /usr/share may also make sense but I'm not a big fan of it. If you can find me the piece of FHS that explicitly allows shell scripts in /usr/lib I can figure out how that compares to using /usr/lib. -Toshio pgpJOiL9MbpJG.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote: > > Why does systemd link against libpam? > > systemd does logins now, not /bin/login or gdm or ...? > > to implement PAMName= (man systemd.exec) I don't see any users of this feature on my F15. I searched with Google and come up empty too. But anyway, assuming it's a useful feature, why it has to be done by systemd? I looked at implementation. systemd-26/src/execute.c::setup_pam(): /* We set up PAM in the parent process, then fork. The child * will then stay around until killed via PR_GET_PDEATHSIG or * systemd via the cgroup logic. It will then remove the PAM * session again. The parent process will exec() the actual * daemon. We do things this way to ensure that the main PID * of the daemon is the one we initially fork()ed. */ I don't see any attempt to free at least something in the child. So, systemd forks a process with eleven megabyte of malloced stuff to act just as a babysitter - wait for parent to die, call pam_end, exit? For how long will it hang around in the system - possibly days? Yes, COW, so not all of these eleven megabytes will be around... ...at first, until parent execs, or modifies sufficiently many pages so that most of them are copied. But memory consumption is not really the gist of my argument, it's: why systemd tries to be all things for all people? Why it has to care about PAM? I think most tools which need it do it themselves, and we can write a small, really small helper for those which don't. > > libwrap? systemd is a network application now too? > > to implement TCPWrapName= (man systemd.exec) Again, why it has to be done *by systemd*? On Fri, 2011-06-10 at 10:09 -0400, Steve Clark wrote: > > Yes, whatever happened to the *NIX philosophy of simple non-complex > programs that did their job well. It has seemed to serve well since > the 70's. Exactly my point. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Slim
On 06/10/2011 07:04 PM, Christoph Wickert wrote: > Am Donnerstag, den 09.06.2011, 13:40 +0400 schrieb Lucas: >> What kind of relation between Xfce maintainers and SLIM. > > The Fedora Xfce SIG considered SLIM but we didn't use it because (at > least at that time) it had some problems with ConsoleKit. > I use xfce since fedora 13 and slim also. I always had to do something to make it works. What are those problems with consolekit you mentioned? > We are still trying to get rid of GDM but we are more after LightDM now. > I have packaged it and it basically works on F>= 15, but the package > and LightDM requires some more work. > > I don't think that Xfce upstream has a relationship to SLIM in > particular because the project seems pretty much dead. > >> I always thought SLIM is just display manager, which can start >> whatever I want. > > That is correct, but you either need to configure the default desktop or > use the sylm-dynwm script. For more info have a look at > https://fedoraproject.org/wiki/LXDE#SLiM > > Regards, > Christoph > > I, personally, agree that GDM should be replaced, especially after someone decided to move "reboot" and "shutdown" to it. (I found it in Fedora XFCE spin), so now I am thinking how to allow "systemctl reboot" for normal user from xfce. I will check LightDM, but as long as slim works for me, I am going to use it. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, 2011-06-10 at 14:29 +0100, Richard W.M. Jones wrote: > There's a bug for these issues (no resolution though): > > https://bugzilla.redhat.com/show_bug.cgi?id=541230 My case was way more extreme, one core pretty much fully used by ksmd. It was with late F14, just before the release of F15. > It's also worth noting that there are lots of knobs to tune KSM in > /etc/ksmtuned.conf. More information is here: Yes, I eventually found out how to disable ksmd. I think that's not the point, the point is that kvm/qemu/virt-manager could be improved in the usability department. And that means it should do a reasonable job without the user first modify lots of tunables. virt-manager has gone a long way of making qemu/kvm a lot more useable, but there's still room for improvements: - I had occasional problems with the keyboard mapping - Storage management is not always logical to me, I didn't find out how to reuse an existing qcow2 image, so in the end I edited config files manually - USB is not really workable. Trying it just now with up2date F15 crashed qemu (guest rawhide) when trying to assign a host USB device to the guest Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 10/06/11 16:54, Michael Cronenworth wrote: > Tom Hughes on 06/10/2011 10:25 AM wrote: >> Actually building the driver (once I'd downloaded the 620Mb DDK) was >> quite easy. I'm still scratching my head over how to actually install it >> though ;-) >> >> That was only the graphics driver anyway - what I really want is the >> agent for the clipboard protocol. >> >> To be fair you can download both the drivers and the agent in prebuilt >> form at http://spice-space.org/download.html but only for 32 bit Windows >> at the moment. > > I'm not sure why you're using this argument as a positive thing. In VB > (or any third-party VM software) installing the guest additions for > 32-bit /and/ 64-bit OSes is as easy and clicking "Install" and > rebooting. No driver downloads. No config file editing. Until > libvirt/qemu/kvm/spice provide a similar solution there is no comparison. I wasn't trying to suggest that the current situation is perfect, just that it isn't always as bad as the DDK thing sounded. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
Tom Hughes on 06/10/2011 10:25 AM wrote: > Actually building the driver (once I'd downloaded the 620Mb DDK) was > quite easy. I'm still scratching my head over how to actually install it > though ;-) > > That was only the graphics driver anyway - what I really want is the > agent for the clipboard protocol. > > To be fair you can download both the drivers and the agent in prebuilt > form at http://spice-space.org/download.html but only for 32 bit Windows > at the moment. I'm not sure why you're using this argument as a positive thing. In VB (or any third-party VM software) installing the guest additions for 32-bit /and/ 64-bit OSes is as easy and clicking "Install" and rebooting. No driver downloads. No config file editing. Until libvirt/qemu/kvm/spice provide a similar solution there is no comparison. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 10/06/11 16:12, Michael Cronenworth wrote: > Richard W.M. Jones wrote: > >> They are available, but I think you have to build them yourself from >> source. All the information is here: > > 2. Make guest additions dead simple to install. Having to compile them > with a Windows DDK is not dead simple. Actually building the driver (once I'd downloaded the 620Mb DDK) was quite easy. I'm still scratching my head over how to actually install it though ;-) That was only the graphics driver anyway - what I really want is the agent for the clipboard protocol. To be fair you can download both the drivers and the agent in prebuilt form at http://spice-space.org/download.html but only for 32 bit Windows at the moment. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 6/10/11 10:39 AM, Mark Bidewell wrote: > To add to the point about graphics support there is also the fact that > GNOME3/Unity will only run with accelerated graphics which only > VirtualBox supports. I have Gnome 3 running with software GL. I'll probably be blogging about it soon, it's not quite in a mergeable state for Mesa yet but it's looking quite credible. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
Richard W.M. Jones wrote: > They are available, but I think you have to build them yourself from > source. All the information is here: This is not an argument for libvirt/kvm/qemu/spice but against. Here's some constructive advice: 1. Give the Red Hat virtualization tools one, unique name and package it under that name. Having a new name for every new feature isn't helping your cause. Call it "RHVM" even. Anything is better than the current situation and I'm sure a marketing wizard would love to tackle this. 2. Make guest additions dead simple to install. Having to compile them with a Windows DDK is not dead simple. 3. Transparent network access. Having to setup bridges or manually edit config files is a big turn off to some folks. I know virt-manager has a GUI for some operations, but I still see editing config files a recommended method in recent mailing list postings. 4. Support USB 2.0+ in a easy-to-use way. Under VB, I can just click on a device I want to use, while the VM is running, and use it. When I'm done, I uncheck the device, again, while the VM is running, and it disconnects from the VM and returns for use to my Fedora box. 5. Exporting VMs must be a two-click process. Not a 9 command, terminal operation. Importing VMs must be just as easy. Now, if you don't care to cater to "dumb" folk, then continue what you are doing. VirtualBox will continue to be used over anything Fedora offers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Election Results for FESCo and Fedora Board seats
I'm happy to announce the results of our recent round of elections for at-large seats on the Fedora Board and FESCo, and FAmSCo. The results are as follows: FESCo There were five FESCo seats up for election this cycle. A total of 200 ballots were cast in the FESCo election. Each of the eight candidates could receive up to 1600 votes (200 ballots multiplied by 8 candidates). Votes | Candidate -- 1120 | Kevin Fenzi (nirik) 1020 | Bill Nottingham (notting) 764 | Tomáš Mráz (t8m) 699 | Peter Jones (pjones) 567 | Stephen Gallagher (sgallagh) 535 | Kyle McMartin (kylem) 480 | Justin Forbes (jforbes) 398 | Iain Arnell (iarnell) The top five candidates were Kevin, Bill, Tomáš, Peter, and Stephen. Each will server a full two-term position on the Fedora Engineering Steering committee. * * * * * Fedora Board - There were three open seats on the Fedora Board this election cycle. A total of 204 ballots were cast. Due to the system of range voting that we use in Fedora elections, this means that each of the six candidates could receive up to 224 votes (204 ballots multiplied by 6 candidates). Votes | Candidate -- 833 | Rex Dieter (rdieter) 608 | Jon Stanley (jds2001) 607 | Peter Robinson (pbrobinson) 421 | Robert 'Bob' Jensen (EvilBob) 367 | Andrea Veri (averi) 274 | Zach Oglesby (zoglesby) I'm pleased to have Rex and Jon return as members of the Board, and welcome Peter to the Fedora Board as well. All three of these individuals will serve full two-term positions on the Fedora Board. -- Jared Smith Fedora Project Leader ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Slim
Am Donnerstag, den 09.06.2011, 13:40 +0400 schrieb Lucas: > What kind of relation between Xfce maintainers and SLIM. The Fedora Xfce SIG considered SLIM but we didn't use it because (at least at that time) it had some problems with ConsoleKit. We are still trying to get rid of GDM but we are more after LightDM now. I have packaged it and it basically works on F >= 15, but the package and LightDM requires some more work. I don't think that Xfce upstream has a relationship to SLIM in particular because the project seems pretty much dead. > I always thought SLIM is just display manager, which can start > whatever I want. That is correct, but you either need to configure the default desktop or use the sylm-dynwm script. For more info have a look at https://fedoraproject.org/wiki/LXDE#SLiM Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
>> Why are people choosing it over other solutions, and what can we change >> in qemu/kvm to get users using that instead ? >> >> Dave >> > > 1. Easy setup of networking (bridged). > 2. Support decent graphics mode in guests. (After installing guest > additions, a > winxp guest on fedora host can run in any graphics resolution. I don't think > qemu/kvm does this). > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > To add to the point about graphics support there is also the fact that GNOME3/Unity will only run with accelerated graphics which only VirtualBox supports. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 03:59 PM, Steve Clark wrote: > On 06/10/2011 09:36 AM, Michal Schmidt wrote: >> systemd does not take the system down when it crashes. It catches the >> signal, dumps core and freezes, but does not exit. >> ^^^ > So you just end up with a "froze" system instead of a crashed system No, only systemd freezes itself. Other processes continue running. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 09:07 AM, Denys Vlasenko wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that "typical" init, but I think using *eleven plus megabytes* of malloced space is a bit much. systemctl --all shows 258 units total on my machine, thus systemd uses ~40 *KILO*bytes of state per unit? I understand your desire to replace everything by systemd. I really do. syslogd, klogd, mount, fsck, and a dozen other things I forget or don't know. It's called "featuritis". Now I hear about plans to incorporate ConsoleKit into it (hearsay, so maybe it's not true). Look where it is now: Top: Mem total:2035840 anon:431208 map:78924 free:419084 slab:91624 buf:108040 cache:942336 dirty:196 write:0 Swap total:4095996 free:4095996 PID VSZ VSZRW RSS (SHR)*DIRTY (SHR) STACK COMMAND 1818 624m 365m 185m 13472 155m64 224 /usr/lib/firefox-4/firefox 1816 433m 189m 166m 17248 142m 0 204 evolution 1257 53672 40400 22664 6004 18336 4176 132 /usr/bin/Xorg 1 15384 11856 13664 1340 11752 0 132 /sbin/init ^ ^ 11.7 megs of malloc space 1839 275m 40224 24208 10572 11020 0 132 /usr/bin/gnome-terminal 1713 202m 45284 20308 9736 9604 576 132 /usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin 1843 171m 9448 20264 10012 8440 344 204 xchat 1770 152m 55672 19412 10972 6108 0 132 nautilus It's the *fourth* largest process on my system! # ldd `which systemd` linux-gate.so.1 => (0x00a6b000) libselinux.so.1 => /lib/libselinux.so.1 (0x414f6000) libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x41bc1000) libpthread.so.0 => /lib/libpthread.so.0 (0x0019a000) libudev.so.0 => /lib/libudev.so.0 (0x422c9000) libwrap.so.0 => /lib/libwrap.so.0 (0x420fa000) libpam.so.0 => /lib/libpam.so.0 (0x420e6000) libaudit.so.1 => /lib/libaudit.so.1 (0x420cc000) libcap.so.2 => /lib/libcap.so.2 (0x4152f000) librt.so.1 => /lib/librt.so.1 (0x00be8000) libc.so.6 => /lib/libc.so.6 (0x00295000) /lib/ld-linux.so.2 (0x00276000) libdl.so.2 => /lib/libdl.so.2 (0x00af6000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00f68000) libnsl.so.1 => /lib/libnsl.so.1 (0x0095c000) libattr.so.1 => /lib/libattr.so.1 (0x420c5000) Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? libattr? Does it mean it requires filesystem which implements extended attributes? If not, why does it use libattr then? libwrap? systemd is a network application now too? libaudit? What systemd has in common with audit? libdbus?... this is a lost battle I guess... I propose to stop for a second and optimize systemd down instead of trying to add even more bells and whistles to it. Or else you'll soon end up linking against every /lib/lib*.so* At the very least, I would like to see its memory consumption to go down substantially. It is an *init replacement*, not the replacement for everything. One of init's goal is to be *simple* and *stable*. Every new feature you add and library you link against works against that goal. To be honest, I doubt the wisdom of implementing service manager as an init process. There is no inherent reason why it has to be init - you can run it as *a child of init*, and keep init very simple. Then, if service manager would crash, at least it doesn't take system down with it... Yes, whatever happened to the *NIX philosophy of simple non-complex programs that did their job well. It has seemed to serve well since the 70's. -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 09:36 AM, Michal Schmidt wrote: On 06/10/2011 03:07 PM, Denys Vlasenko wrote: I understand your desire to replace everything by systemd. I really do. syslogd, klogd, mount, fsck, and a dozen other things I forget or don't know. You're exaggerating. Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? to implement PAMName= (man systemd.exec) libattr? Does it mean it requires filesystem which implements extended attributes? If not, why does it use libattr then? systemd uses libcap. libcap depends on libattr. libwrap? systemd is a network application now too? to implement TCPWrapName= (man systemd.exec) libaudit? What systemd has in common with audit? Start and stop of a service is an auditable event. http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html To be honest, I doubt the wisdom of implementing service manager as an init process. There is no inherent reason why it has to be init - you can run it as *a child of init*, and keep init very simple. Then, if service manager would crash, at least it doesn't take system down with it... systemd does not take the system down when it crashes. It catches the signal, dumps core and freezes, but does not exit. ^^^ So you just end up with a "froze" system instead of a crashed system Michal -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, Jun 10, 2011 at 08:22:37AM -0400, Neal Becker wrote: > 2. Support decent graphics mode in guests. (After installing guest > additions, a winxp guest on fedora host can run in any graphics > resolution. I don't think qemu/kvm does this). With SPICE, maximum resolution is 2560x1600. 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: F15 / VirtualBox
On Fri, Jun 10, 2011 at 08:08:26AM -0400, Genes MailLists wrote: >(i) Variable size image for the VM >- it grows to accommodate need Interested to know why sparse images or qcow2 don't fulfil your needs. These have been supported in KVM (and Xen) since forever. > (ii) Easy to duplicate VM image (with UUID change) > >So its easy to deploy images on same or different computers This is what I do: https://rwmj.wordpress.com/2010/09/24/tip-my-procedure-for-cloning-a-fedora-vm/ Also I'm still looking at what to do about the "virt-clone" tool: https://rwmj.wordpress.com/2011/05/11/virt-tools-survey-virt-clone/ > (iii) All VM data is stored in user home > > This means installing a new OS does not negatively impact VM's You can do this with KVM too. There is a performance penalty to using files (but VirtualBox has the same penalty). With old libvirt you had to set SELinux labels manually, but new versions do it for you. > (iv) Control over the network I actually prefer libvirt's default (private network with NAT) configuration. It's good for what I do which is testing lots of VMs. It's a lot better than Xen's default setting of "bugger up the network", or VMware's "first, install these binary drivers in your kernel" config. For production, I change libvirt to use a shared bridge by adjusting a couple of configuration files: http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 03:07 PM, Denys Vlasenko wrote: > I understand your desire to replace everything by systemd. > I really do. syslogd, klogd, mount, fsck, and a dozen other things > I forget or don't know. You're exaggerating. > Why does systemd link against libpam? > systemd does logins now, not /bin/login or gdm or ...? to implement PAMName= (man systemd.exec) > libattr? Does it mean it requires filesystem which implements > extended attributes? If not, why does it use libattr then? systemd uses libcap. libcap depends on libattr. > libwrap? systemd is a network application now too? to implement TCPWrapName= (man systemd.exec) > libaudit? What systemd has in common with audit? Start and stop of a service is an auditable event. http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html > To be honest, I doubt the wisdom of implementing service manager > as an init process. There is no inherent reason why it has to be init - > you can run it as *a child of init*, and keep init very simple. > Then, if service manager would crash, at least it doesn't > take system down with it... systemd does not take the system down when it crashes. It catches the signal, dumps core and freezes, but does not exit. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, Jun 10, 2011 at 02:30:46PM +0200, Thomas Sailer wrote: > On Fri, 2011-06-10 at 10:24 +0200, Tomasz Torcz wrote: > > > - it's memory deduplication reimplements what already in-kernel (for the > >sake of cross platform) > > Kernel deduplication runs amok on my machine. When I have two guests, > one Windows, one Rawhide, running under kvm/qemu, kernel deduplication > uses up one CPU core. For no benefit, I suspect there isn't much to > deduplicate between Windows and Rawhide. There's a bug for these issues (no resolution though): https://bugzilla.redhat.com/show_bug.cgi?id=541230 Originally I had ksmd turned off, but since ~ Fedora 14 I've not had any trouble with it at all. It's also worth noting that there are lots of knobs to tune KSM in /etc/ksmtuned.conf. More information is here: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization/chap-KSM.html Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 06/09/2011 07:44 PM, Chris Jones wrote: > Also, for those that may not be aware, Virtualbox can be installed in > just 2 commands in your Fedora system. Assuming you have wget installed. ... > ~$ su > wget > http://download.virtualbox.org/virtualbox/4.0.8/VirtualBox-4.0-4.0.8_71778_fedora15-1.x86_64.rpm > yum install VirtualBox-4.0-4.0.8_71778_fedora15-1.x86_64.rpm > Make it one command: yum install http://download.virtualbox.org/virtualbox/4.0.8/VirtualBox-4.0-4.0.8_71778_fedora15-1.x86_64.rpm (or VirtualBox-4.0-4.0.8_71778_fedora15-1.i686.rpm for 32-bit systems) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd: please stop trying to take over the world :)
Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that "typical" init, but I think using *eleven plus megabytes* of malloced space is a bit much. systemctl --all shows 258 units total on my machine, thus systemd uses ~40 *KILO*bytes of state per unit? I understand your desire to replace everything by systemd. I really do. syslogd, klogd, mount, fsck, and a dozen other things I forget or don't know. It's called "featuritis". Now I hear about plans to incorporate ConsoleKit into it (hearsay, so maybe it's not true). Look where it is now: Top: Mem total:2035840 anon:431208 map:78924 free:419084 slab:91624 buf:108040 cache:942336 dirty:196 write:0 Swap total:4095996 free:4095996 PID VSZ VSZRW RSS (SHR)*DIRTY (SHR) STACK COMMAND 1818 624m 365m 185m 13472 155m64 224 /usr/lib/firefox-4/firefox 1816 433m 189m 166m 17248 142m 0 204 evolution 1257 53672 40400 22664 6004 18336 4176 132 /usr/bin/Xorg 1 15384 11856 13664 1340 11752 0 132 /sbin/init ^ ^ 11.7 megs of malloc space 1839 275m 40224 24208 10572 11020 0 132 /usr/bin/gnome-terminal 1713 202m 45284 20308 9736 9604 576 132 /usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin 1843 171m 9448 20264 10012 8440 344 204 xchat 1770 152m 55672 19412 10972 6108 0 132 nautilus It's the *fourth* largest process on my system! # ldd `which systemd` linux-gate.so.1 => (0x00a6b000) libselinux.so.1 => /lib/libselinux.so.1 (0x414f6000) libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x41bc1000) libpthread.so.0 => /lib/libpthread.so.0 (0x0019a000) libudev.so.0 => /lib/libudev.so.0 (0x422c9000) libwrap.so.0 => /lib/libwrap.so.0 (0x420fa000) libpam.so.0 => /lib/libpam.so.0 (0x420e6000) libaudit.so.1 => /lib/libaudit.so.1 (0x420cc000) libcap.so.2 => /lib/libcap.so.2 (0x4152f000) librt.so.1 => /lib/librt.so.1 (0x00be8000) libc.so.6 => /lib/libc.so.6 (0x00295000) /lib/ld-linux.so.2 (0x00276000) libdl.so.2 => /lib/libdl.so.2 (0x00af6000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00f68000) libnsl.so.1 => /lib/libnsl.so.1 (0x0095c000) libattr.so.1 => /lib/libattr.so.1 (0x420c5000) Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? libattr? Does it mean it requires filesystem which implements extended attributes? If not, why does it use libattr then? libwrap? systemd is a network application now too? libaudit? What systemd has in common with audit? libdbus?... this is a lost battle I guess... I propose to stop for a second and optimize systemd down instead of trying to add even more bells and whistles to it. Or else you'll soon end up linking against every /lib/lib*.so* At the very least, I would like to see its memory consumption to go down substantially. It is an *init replacement*, not the replacement for everything. One of init's goal is to be *simple* and *stable*. Every new feature you add and library you link against works against that goal. To be honest, I doubt the wisdom of implementing service manager as an init process. There is no inherent reason why it has to be init - you can run it as *a child of init*, and keep init very simple. Then, if service manager would crash, at least it doesn't take system down with it... -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-PBS] Perl 5.14 mass rebuild
commit 4d7d2773aaae65d4fc4b2c142824d9c87cc3dd75
Author: Marcela Mašláňová
Date: Fri Jun 10 14:35:42 2011 +0200
Perl 5.14 mass rebuild
perl-PBS.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-PBS.spec b/perl-PBS.spec
index 0372c6d..a7abde8 100644
--- a/perl-PBS.spec
+++ b/perl-PBS.spec
@@ -1,6 +1,6 @@
Name: perl-PBS
Version:0.33
-Release:12%{?dist}
+Release:13%{?dist}
Summary:Perl binding for the Portable Batch System client library
Group: Development/Libraries
@@ -83,6 +83,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Fri Jun 10 2011 Marcela Mašláňová - 0.33-13
+- Perl 5.14 mass rebuild
+
* Tue Feb 08 2011 Fedora Release Engineering
- 0.33-12
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Newt] Perl 5.14 mass rebuild
commit 5b996572e5f94e81faea0fb17c4d679849caa698
Author: Marcela Mašláňová
Date: Fri Jun 10 14:35:15 2011 +0200
Perl 5.14 mass rebuild
perl-Newt.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Newt.spec b/perl-Newt.spec
index 8415f91..79eb48a 100644
--- a/perl-Newt.spec
+++ b/perl-Newt.spec
@@ -1,7 +1,7 @@
Summary: Perl bindings for the Newt library
Name: perl-Newt
Version: 1.08
-Release: 28%{?dist}
+Release: 29%{?dist}
Group: System Environment/Libraries
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
URL: http://search.cpan.org/~amedina/Newt-1.08/
@@ -62,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/Newt*
%changelog
+* Fri Jun 10 2011 Marcela Mašláňová - 1.08-29
+- Perl 5.14 mass rebuild
+
* Tue Feb 08 2011 Fedora Release Engineering
- 1.08-28
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Provenpackager help for razertool removal
Am Sonntag, den 05.06.2011, 13:19 +0200 schrieb Nicola Soranzo: > razertool package is dead upstream razercfg [1] it the successor of razertool. If somebody packages it up, it would be nice to have the package properly obsolete razertool. Regards, Christoph [1] http://bues.ch/cms/hacking/razercfg.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, 2011-06-10 at 10:24 +0200, Tomasz Torcz wrote: > - it's memory deduplication reimplements what already in-kernel (for the >sake of cross platform) Kernel deduplication runs amok on my machine. When I have two guests, one Windows, one Rawhide, running under kvm/qemu, kernel deduplication uses up one CPU core. For no benefit, I suspect there isn't much to deduplicate between Windows and Rawhide. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, 2011-06-10 at 08:50 +0100, Richard W.M. Jones wrote: > The other feature is USB passthrough. (KVM can do this, but IIRC it > only works for USB 1.1 devices and it's not integrated into the UI). Last time I tried I had to specify USB device and bus numbers. This is quite unusable, as they are not stable, when reconnecting the device usually gets another device number. Some way to specify USB devices by vendor/device ID or some Manufacturer/Product/Serial string is needed. Also, I have a strange card reader which I would love to use under some form of virtualisation, as the accompanying application only runs under very old versions of windows. The card reader has the misfeature that it requires firmware to be loaded by the PC. To get the firmware, it connects, waits about 4 seconds, and if it doesn't get anything it disconnects and reconnects again. Now qemu/kvm is currently much too slow for this, until the host notices the USB device and hands it over to the guest, about 5-10sec pass. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
Dave Jones wrote: > On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote: > > On Thu, Jun 09, 2011 at 08:01:06PM +1000, Chris Jones wrote: > > > > > I agree. As virtualization technology becomes more and more involved > > > and frequent on users systems, particularly with advanced Linux users, > > > I think there needs to be a strong focus on ensuring that all releases > > > run in virtualized environments without any major issues. ie. > > > Virtualbox. > > > > > > Perhaps a dedicated team among the developers who specialize in this > > > area. > > > > I don't think there are any developers working on this area, where "this > > area" is Virtualbox. We don't ship Virtualbox. We don't ship a kernel > > that has any knowledge of Virtualbox. There's a good argument for having > > this be part of the QA process and requiring that we boot in the common > > virtualisation environments as part of the release criteria, but I don't > > think we can realistically suggest that our virtualisation developers > > (who work on code that has nothing to do with Virtualbox) be responsible > > for that. > > I'm curious why virtualbox has gained so much inertia so quickly. > Based solely on the number of kernel bug reports we get that seem to be > related to it, I have almost zero confidence in it being reliable. > > Why are people choosing it over other solutions, and what can we change > in qemu/kvm to get users using that instead ? > > Dave > 1. Easy setup of networking (bridged). 2. Support decent graphics mode in guests. (After installing guest additions, a winxp guest on fedora host can run in any graphics resolution. I don't think qemu/kvm does this). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 06/09/2011 06:37 PM, Dave Jones wrote: > On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote: Long list already from others but a couple of other things that are nice (dont know if qemu has these today, but didn't used to) (i) Variable size image for the VM - it grows to accommodate need (ii) Easy to duplicate VM image (with UUID change) So its easy to deploy images on same or different computers (iii) All VM data is stored in user home This means installing a new OS does not negatively impact VM's (iv) Control over the network There are some cons - I have had it go crazy and exhaust memory - I have had problems deleting an intermediate snapshot causing troubles for later snapshots - but overall its easy to use and generally works. gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110610 changes
Compose started at Fri Jun 10 08:15:18 UTC 2011 Broken deps for x86_64 -- 389-admin-1.1.16-1.fc16.i686 requires libadmsslutil.so.1 389-admin-1.1.16-1.fc16.i686 requires libadminutil.so.1 389-admin-1.1.16-1.fc16.x86_64 requires libadmsslutil.so.1()(64bit) 389-admin-1.1.16-1.fc16.x86_64 requires libadminutil.so.1()(64bit) 389-dsgw-1.1.6-3.fc16.x86_64 requires libadmsslutil.so.1()(64bit) 389-dsgw-1.1.6-3.fc16.x86_64 requires libadminutil.so.1()(64bit) CGSI-gSOAP-1.3.4.0-2.fc15.i686 requires libvomsapi.so.0 CGSI-gSOAP-1.3.4.0-2.fc15.x86_64 requires libvomsapi.so.0()(64bit) OpenEXR_Viewers-1.0.2-3.fc15.x86_64 requires libfltk.so.1.1()(64bit) OpenEXR_Viewers-1.0.2-3.fc15.x86_64 requires libfltk_gl.so.1.1()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) alsa-tools-1.0.24.1-2.fc15.x86_64 requires libfltk.so.1.1()(64bit) amarok-2.4.1-2.fc16.x86_64 requires libmtp.so.8()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) clementine-0.7.1-1.fc16.x86_64 requires libmtp.so.8()(64bit) coda-vcodacon-6.9.5-4.fc15.x86_64 requires libfltk.so.1.1()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper ed2k_hash-gui-0.4.0-10.fc13.x86_64 requires libfltk.so.1.1()(64bit) emacs-common-mozc-1.1.717.102-2.fc16.x86_64 requires libprotobuf.so.6()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) flpsed-0.5.2-2.fc15.x86_64 requires libfltk.so.1.1()(64bit) gdb-heap-0.5-4.fc15.x86_64 requires glibc(x86-64) = 0:2.13.90 gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) gipfel-0.3.2-8.fc15.x86_64 requires libfltk_images.so.1.1()(64bit) gipfel-0.3.2-8.fc15.x86_64 requires libfltk.so.1.1()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libupnp.so.3()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libthreadutil.so.2()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-timer-2.1.4-2.fc15.x86_64 requires gnome-python2-applet >= 0:2.16 gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-device-manager-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-devel-0.2-6.fc15.i686 requires hal-devel >= 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.i686 requires pkgconfig(hal) gnome-device-manager-devel-0.2-6.fc15.x86_64 requires hal-devel >= 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.x86_64 requires pkgconfig(hal) gnome-device-manager-libs-0.2-6.fc15.i686 requires libhal.so.1 gnome-device-manager-libs-0.2-6.fc15.i686 requires hal >= 0:0.5.10 gnome-device-manager-libs-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-libs-0.2-6.fc15.x86_64 requires hal >= 0:0.5.10 gnome-netstatus-2.28.2-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdconduit.so.3()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotd.so.5()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdcm.so.4()(64bit) gnome-pilot-eds-2.91.92-1.fc16.x86_64 requires libcamel-1.2.so.23()(64bit)
Re: rawhide missed an implicit dependency for #!python
On 06/10/2011 02:28 AM, Josh Stone wrote: > On 06/02/2011 01:26 PM, Josh Stone wrote: >> Our dtrace script in systemtap-sdt-devel starts "#!/usr/bin/python". >> Usually this leads to an implicit "Requires: /usr/bin/python", but for >> some reason our rawhide build did not get this. The F15, F14, and F13 >> builds from the same spec required python as expected. > [...] >> Is this a bug? Or must we now explicitly require python? > > An output change in file-5.07 appears to have broken find-requires: > https://bugzilla.redhat.com/show_bug.cgi?id=712251 > > And since file-5.07-2.fc15 is now in updates, I would expect this to > cause even more problems going forward. Fixed now in rawhide rpm and an update for F15 is here: https://admin.fedoraproject.org/updates/rpm-4.9.0-9.fc15 Please help testing to get this nasty regression fixed ASAP. ALL packages containing scripts which have been built while file-5.07 has been in rawhide (since May 11th) & F15 (in updates-testing since May 23rd) are affected and will have missing dependencies because of this, requiring rebuilds to correct the situation. Thanks Josh for reporting this, and also apologies for missing your initial mail on the subject, reacting then would've saved a week's worth of broken builds :-/ - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Outage: Server Updates/Reboots - 2011-06-14 21:00 UTC
Outage: Server Updates/Reboots - 2011-06-14 21:00 UTC There will be an outage starting at 2011-06-14 21:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2011-06-14 21:00 UTC' Reason for outage: Another round of server updates and reboots. Note that these reboots will affect contributors/maintainers, but not end users. Affected Services: Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control Unaffected Services: BFO - http://boot.fedoraproject.org/ Bodhi - https://admin.fedoraproject.org/updates/ DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Docs - http://docs.fedoraproject.org/ Email system Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Hosted - https://fedorahosted.org/ Fedora Insight - https://insight.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Fedora Talk - http://talk.fedoraproject.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ Smolt - http://smolts.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Translation Services - http://translate.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/2823 Contact Information: Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, Jun 10, 2011 at 09:18:49AM +0100, Tom Hughes wrote: > On 10/06/11 09:12, Richard W.M. Jones wrote: > >On Fri, Jun 10, 2011 at 09:03:16AM +0200, tim.laurid...@gmail.com wrote: > > > >>- Running Windows application in a windows guest, runs very smooth, no > >>delay in updating the GUI. > > > >You should try new versions. I've never had a problem with delays > >updating the GUI, even in old versions. With SPICE support, access > >over the network beats everything. > > Spice is cool, I just wish there was an agent/drivers for 64 bit > Windows guests... They are available, but I think you have to build them yourself from source. All the information is here: http://spice-space.org/page/WinQXL#How_to_build_the_driver Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New cfitsio in rawhide
Hi, a new cfistio package (3.280) as landed in rawhide. Packages depending on cfitsio should be rebuilt. Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fwd: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY]
--- Begin Message --- Hi Folks, We are hosting a Fedora 15 hardfp Virtual Fedora Activity Day today, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). You can find a lot more detail here, along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110610 Jon. ___ arm mailing list a...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm --- End Message --- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Thu, Jun 09, 2011 at 06:37:19PM -0400, Dave Jones wrote: > I'm curious why virtualbox has gained so much inertia so quickly. > Based solely on the number of kernel bug reports we get that seem to be > related to it, I have almost zero confidence in it being reliable. > > Why are people choosing it over other solutions, and what can we change > in qemu/kvm to get users using that instead ? For me, I installed VB to check (then) Sun's Fishworks emulator, which was distributed as virtualbox image. Afterwards I stayed because: - my computer did not have VT-x/SVM (it's not relevant now, most computer have) - VB has 3D accell support for guest. Enough to test for example Ubuntu Unity, and I believe gnome-shell also. This is BIG advantage. - virt-manager storage management is IMO a mess. I created LVM LV for new virtual-machine, then went to virt-manager to add this as raw file and got lost. I know that I want raw file, but the gui is talking about raw files separately from LVM pools. - bridged networking works with standard F15 install. With virt-manager one need to disable NetworkManager. - USB passthrough works. - changing virtual CD media is easy and reliable - VB provides yum repos VirtualBox has disadvantages: - it doesn't use kvm-intel for hardware virtualisation. I cannot run KVM and VB at the same time. - it's memory deduplication reimplements what already in-kernel (for the sake of cross platform) -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 10/06/11 09:12, Richard W.M. Jones wrote: > On Fri, Jun 10, 2011 at 09:03:16AM +0200, tim.laurid...@gmail.com wrote: > >> - Running Windows application in a windows guest, runs very smooth, no >> delay in updating the GUI. > > You should try new versions. I've never had a problem with delays > updating the GUI, even in old versions. With SPICE support, access > over the network beats everything. Spice is cool, I just wish there was an agent/drivers for 64 bit Windows guests... Not that I have any real problem with a Windows guest and VNC graphics but it would be very nice to have working cut and paste. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, Jun 10, 2011 at 09:03:16AM +0200, tim.laurid...@gmail.com wrote: >- Local shared folders. to share files from Fedora host to windows >client. libvirt can do this now, and I think so can virt-manager (not checked). http://libvirt.org/formatdomain.html#elementsFilesystems I'm not sure if it's supported by Windows guests, which may be a deal-breaker. >- Save current state of guest, so I easy can switch clients with out >having to close the the client OS down. Snapshots are being added shortly. >- Running Windows application in a windows guest, runs very smooth, no >delay in updating the GUI. You should try new versions. I've never had a problem with delays updating the GUI, even in old versions. With SPICE support, access over the network beats everything. 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: F15 / VirtualBox
On Thu, Jun 9, 2011 at 11:37 PM, Dave Jones wrote: > On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote: > > On Thu, Jun 09, 2011 at 08:01:06PM +1000, Chris Jones wrote: > > > > > I agree. As virtualization technology becomes more and more involved > > > and frequent on users systems, particularly with advanced Linux users, > > > I think there needs to be a strong focus on ensuring that all releases > > > run in virtualized environments without any major issues. ie. > > > Virtualbox. > > > > > > Perhaps a dedicated team among the developers who specialize in this > area. > > > > I don't think there are any developers working on this area, where "this > > area" is Virtualbox. We don't ship Virtualbox. We don't ship a kernel > > that has any knowledge of Virtualbox. There's a good argument for having > > this be part of the QA process and requiring that we boot in the common > > virtualisation environments as part of the release criteria, but I don't > > think we can realistically suggest that our virtualisation developers > > (who work on code that has nothing to do with Virtualbox) be responsible > > for that. > > I'm curious why virtualbox has gained so much inertia so quickly. > Based solely on the number of kernel bug reports we get that seem to be > related to it, I have almost zero confidence in it being reliable. In the OLPC/Sugar world a lot of people use it on Windows/Mac because its non invasive, simple to use, free, universal on all platforms and they run Sugar on a Stick in a VM. > Why are people choosing it over other solutions, and what can we change > in qemu/kvm to get users using that instead ? Problem is that in the education space Sugar is aiming at (K-6) Mac and Windows is the primary OS. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 696725] RPM doesn't create /var/run/amavisd
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=696725 Matthias Haase changed: What|Removed |Added CC||matthias_ha...@bennewitz.co ||m --- Comment #7 from Matthias Haase 2011-06-10 03:49:03 EDT --- (In reply to comment #4) > Created attachment 501354 [details] > tmpfile.d file > > The fix seems to be to place this in /etc/tmpfile.d from the RPM. Is it > possible to get this added so that things work properly out of the box? Thank > you. I have this file added and that doesn't work. No creation of the missed directory in /var/run even at boot or using start|stop of amavisd. May be this is a timimg issue, I couldn't find out why. The only working solution at present is creating the missed directory inside of the start|stop script, as Trever wrote already. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F15 / VirtualBox
On Thu, Jun 09, 2011 at 06:37:19PM -0400, Dave Jones wrote: > I'm curious why virtualbox has gained so much inertia so quickly. > Based solely on the number of kernel bug reports we get that seem to be > related to it, I have almost zero confidence in it being reliable. > > Why are people choosing it over other solutions, and what can we change > in qemu/kvm to get users using that instead ? VirtualBox has a nice GUI which compares well with old versions of virt-manager. However virt-manager has come a very long way since and I'd urge people to try up-to-date versions. New Fedora comes with it as standard, or you can do: # yum install virt-manager to install everything required (including libvirt and KVM bits). The other feature is USB passthrough. (KVM can do this, but IIRC it only works for USB 1.1 devices and it's not integrated into the UI). 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://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Thu, Jun 09, 2011 at 04:30:07PM -0700, Dan Young wrote: > On Thu, Jun 9, 2011 at 3:59 PM, Stephen John Smoogen wrote: > > On Thu, Jun 9, 2011 at 18:37, Dave Jones wrote: > >> I'm curious why virtualbox has gained so much inertia so quickly. > >> Based solely on the number of kernel bug reports we get that seem to be > >> related to it, I have almost zero confidence in it being reliable. > > > > > > 1) It works in windows > > 2) It works in mac os-x > > 3) Oracle has put a lot of money/effort in pushing it via searches > > > > and probably a little of: > > > > 4) It is not from Red Hat. > > 5) Free as in beer Windows guest driver binaries? > > Acquiring these is non-obvious for KVM/libvirt virtio blk/net Windows > guest drivers unless you're a RHEL customer. http://alt.fedoraproject.org/pub/alt/virtio-win/ ? 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: F15 / VirtualBox
On Fri, Jun 10, 2011 at 12:37 AM, Dave Jones wrote: > > Why are people choosing it over other solutions, and what can we change > in qemu/kvm to get users using that instead ? > > I use Virtualbox on a laptop with Fedora 14 as host OS, I use for building and test installation of Windows application and for Running some windows only application (Lotus Domino Designer and Administrator) I use it for the following reasons: - The easy snapshot features, when doing a lot of package testing on Windows, I have to rollback to an earlier snapshot. - Local shared folders. to share files from Fedora host to windows client. - Nice GUI, Very easy to setup and manage new clients. - Save current state of guest, so I easy can switch clients with out having to close the the client OS down. - Running Windows application in a windows guest, runs very smooth, no delay in updating the GUI. I have tried the same stuff on kvm about a year ago, it was the possibility to share local host folders with the guests and when running windows applications (ex. Lotus Domino Designer) there was a little delay before the GUI was updated. Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
