Re: conclusion: F15 / systemd / user-experience
On 06/14/2011 05:57 AM, Somebody in the thread at some point said: Fedora could well benefit from switching to a rolling release model as well (no not rawhide - a controlled rolling release much as the kernel development follows). I've been living from rawhide on my main laptop for a few years, from my POV the existing setup where rawhide never stops and it branches off before the release is ideal already. I sometimes get the equivalent of a crossword puzzle to do on the next boot after an update to get it up again, but at least it keeps me aware of major developments. Since the upstream projects never stop either, capturing that reality in rawhide in packagable form as a first step all the time seems like it must be part of a good solution. BTW I am very happy someone is grasping the nettle of sysvinit, keep up the good work everybody! -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On Tuesday, June 14, 2011 06:51:18 AM Genes MailLists wrote: On 06/13/2011 08:14 PM, Kevin Kofler wrote: Henrik Wejdmark wrote: I have been with this distro since RH4 and have had a great time doing so. Almost every upgrade has been really smooth with only a few minor setbacks like an odd broken dependency that was easily fixed, but F15 is the end for me. I think Karl summed it up pretty well. We can't always agree with every decision, but as our license fees are less than substantial :) we have to live with (semi-)democratic decisions. I have chosen 3), not because of systemd (which I like), but GNOME3 There is no need to run away from Fedora because of GNOME 3. We also have KDE Plasma, Xfce, LXDE and some other choices available for you. And you'll probably have to get familiar with one of those options sooner or later anyway, GNOME 2 is a dead end. Kevin Kofler FYI - I switched to KDE - the current version is pretty nice - small learning curve - and I found I prefer it to Gnome 2 even (def prefer to Gnome 3). I spent a little time but not too long - it does everything I need pretty well (I have multiple apps, terminals etc in different workspaces). Its a nice refreshing update from Gnome 2 and clearly is not trying to compete with Android - which already won the phone UI ... and quite possible the tablet UI as well, tho that looks a little more penetrable to me market wise. They are of course trying to beat Android and iOS ;-) But a different approach is taken - not a one UX suits every needs but for desktops there's desktop user iterface, for netbook there's netbook one (you can try it but be warned - it's Gnome-shell step brother in some terms ;-) and now I'm trying to package Plasma Active for tablets - another different UI. But shares most of code and most of Plasmoids so it looks similar, behaves similar but targets different form factor device. I can't promise Plasma Active now as it depends on KDE Platform 4.7 (slowly pushing it to Rawhide) and for some reasons it crashes for me on top of these builds... But as Kevin pointed out - all three alternative spins are very decent ones. And Gnome Shell is not a bad for a first release especially. Jaroslav Enjoy whatever you decide to do ... -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.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 Mon, 2011-06-13 at 21:44 -0400, Simo Sorce wrote: I wouldn't bother much if it would be just one tiny bit of strange code in systemd, but it is FAR from being the only such code. There are lots of similar stuff, and it's not accidental. It is definitely not accidental, but unless you have bugs to file, I don't think complain generically about systemd architecture here is any productive. Where, in your opinion, is the place to discuss systemd architecture? We discussed systemd for quite a while here and it certainly far from perfect, for some things probably not even good yet. But its time to file bugs for real problems, not time for bike shedding on architectural decision that have been taken quite a while ago. I disagree, and I find the attitude we are developers, you are idiot both quite common and quite wrong. I am a developer too, do you want me to treat *you* this way too when you will have trouble with my software? -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Tue, Jun 14, 2011 at 3:05 AM, Orcan Ogetbil oget.fed...@gmail.com wrote: On Mon, Jun 13, 2011 at 2:48 AM, Michal Schmidt wrote: On Sun, 12 Jun 2011 22:14:27 -0400 Orcan Ogetbil wrote: Having a quick look at the link and at the steps to reproduce the bug gave me shivers. Are we really sure that systemd is ready? I mean, I don't even call my code alpha if it can't parse a slash correctly. Strictly speaking, it parses the slash correctly and it's a bug in /bin/mount. But I understand that's hardly a consolation for those who are affected by this bug. Right, if it was working before and stopped working now, pointing fingers at this point will not help the situation. Such a trivial scenario could have been tested and fixed by the author of the code before it was released to public. I hope this will stay as worst bug in systemd (or triggered by systemd, however you want to put it). Well you can't expect him to test every possible scenario (no matter how trivial it is). I never saw an fstab with a trailing slash so I wouldn't have though about testing it either. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What is the status of Features/YumLangpackPlugin?
On Tuesday 14 June 2011 01:05:57 Kevin Kofler wrote: And NNTP(S)? This list is gatewayed as gmane.linux.redhat.fedora.devel on news.gmane.org (NNTP) and snews.gmane.org (NNTPS), you can use any Usenet News client (e.g. KNode) to read and post to this list. Kevin Kofler (who is using KNode to post this message) I tried knode years ago but the messages composing and reading part was too old and baroque when compared with kmail. Since the outage with this work setup would be less than one week I decided that it was not worth any effort to take a temporary workaround, :-) -- José Abílio -- 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/14/2011 12:50 PM, Denys Vlasenko wrote: On Mon, 2011-06-13 at 21:44 -0400, Simo Sorce wrote: I wouldn't bother much if it would be just one tiny bit of strange code in systemd, but it is FAR from being the only such code. There are lots of similar stuff, and it's not accidental. It is definitely not accidental, but unless you have bugs to file, I don't think complain generically about systemd architecture here is any productive. Where, in your opinion, is the place to discuss systemd architecture? systemd upstream list as I has been pointed out a few times http://lists.freedesktop.org/mailman/listinfo/systemd-devel I disagree, and I find the attitude we are developers, you are idiot both quite common and quite wrong. I am a developer too, do you want me to treat *you* this way too when you will have trouble with my software? I don't think you are helping yourself with the antagonistic approach you have taken. If I had trouble with your software, I would start by asking questions on why things the way they are rather than immediately start telling you, the way you have written it is entirely wrong. 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 Mon, 13.06.11 18:01, Denys Vlasenko (dvlas...@redhat.com) wrote: On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote: On Mon, 13.06.11 15:27, Denys Vlasenko (dvlas...@redhat.com) wrote: kmod_setup(); === ??? We load a couple of kernel modules which systemd needs, and are sometimes compiled as module only and which cannot be autoloaded for a reason or another. This is ipv6, autofs4, unix.ko, and we load them explicitly so that we can use them. You assume that everyone uses IPv6. This is not true. No I am not. You can still blacklist the ipv6 module if you want to via the normal modprobe blacklisting mechanisms. (As mentioned, systemd passes -b to the modprobe command line to ensure that). I explicitly said that in a previous mail. hostname_setup(); === ??? We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. (none) is what the bash makes from empty hostname, which is the default. We just fill in one. Just because systemd sets up a hostname at boot it doesnt mean it couldn't be changed dynamically later on. In fact if you are into dynamic hostnames you should send me a big cake for my birthday as thank you, because I give you stuff like this for F16: https://fedoraproject.org/wiki/Features/nssmyhostname http://www.freedesktop.org/wiki/Software/systemd/hostnamed Why do you set up stuff no one asked you to? Yeah, I explained that already. machine_id_setup(); === ??? Similar to the hostname we ensure that the machine id is always initialized, and has the same lifetime and validity guarantees as the hostname. i.e. that it is simply usable by *every* process started, regardless when. Point me at one program which uses machine id. I never saw one. And anyway, why do you set up stuff no one asked you to? /etc/machine-id is a generalization of the D-Bus machine id, which is used by quite a number of programs directly and indirectly. With systemd we try to make this available globally and independently of D-Bus and add new semantics for stateless systems. plymouth_running()? Plymouth? Systemd knows about plymouth? Why? Because we need to constantly send updates to it. It's a trivial socket operation. It's a trivial thing and spawning a separate process to send those updates each and every single time is a major waste of resources and basically doubles the processes we have to spawn at boot. Plymouth is not a part of Unix. Init process has no business knowing about distro specific stuff like that. Well, since you appear to have invented Unix I think we simply have to disagree here. This is an antithesis to modular, Unix way of doing things. Just because you can turn each trivial operation into a separate binary you shouldn't necessarily do that. Where did I propose turning everything into a separate binary? Well, I say calling sethostname() is a syscall we should simply do in PID 1 and then forget about, but you want this in a separate process (hence separate binary). It is what makes your system slow and heavy-weight. Insisting that we invoke sethostname() in a separate process is just stupid. I am mean, come on, think about it. It is *ONE* system call to the the hostname with sethostname(). Invoking /bin/hostname instead is at least 40 or so (and many of those quite heavy weight). And really, why are we even discussing the frickin hostname like this? Because it's a perfect example of a thing init process has no business doing. Ever. The lightness of the syscall is irrelevant. For example, you also do modprobing of various things, which is far from being just one syscall, so this argument is moot. Well, I guess we simply have to disagree. My interest is a tighly integrated, small, minimal, lightweight system. Yours seem to be a big, archaic, chaotic, redundant, resource intensive system. But that's fine. Do you know what mono means? It's greek and means one. And lithic means stone. And if systemd communicates with Plymouth, then this is not monolothic at all, since systemd and ply are two processes, not one. Init process should not have intrinsic knowledge about splash screens! systemd knows nothing about splash screens. All it does is send status updates to Plymouth. This is basic idea of modularity. This is how Unix always worked.
Re: systemd: please stop trying to take over the world :)
On Mon, 13.06.11 17:19, Matthew Garrett (mj...@srcf.ucam.org) wrote: On Mon, Jun 13, 2011 at 05:13:39PM +0100, Peter Robinson wrote: On Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett mj...@srcf.ucam.org wrote: The point of providing a platform is that developers can make certain assumptions about available functionality. It's no longer reasonable to treat IPv6 as an optional part of the internet, any more than it's reasonable to consider IPv4 as optional. But if you don't want it, simply don't build it. I believe the ipv6 module is going to be built in soon anyway. http://lists.fedoraproject.org/pipermail/kernel/2011-June/003105.html I'd assumed that Dennis was talking about non-Fedora environments, since ipv6 hasn't been meaningfully optional in Fedora for ages. Note that ipv6-less systems are explicitly supported by systemd, by means of blacklisting the kmod in the modprobe configuration. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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 Tue, Jun 14, 2011 at 01:13:01AM +0200, Kevin Kofler wrote: Denys Vlasenko wrote: Try rm /usr/sbin/console-kit-daemon. Works like a charm. Randomly removing pieces of installed packages has never been supported. I think the console-kit-daemon service can be disabled, but xinit prefixes xsession with ck-xinit-session which seems to start the daemon on demand. It would be nice if xinit could be configured to not use it. Same for ssh-agent. -- Miroslav Lichvar -- 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 Mon, 13.06.11 18:01, Miloslav Trmač (m...@volny.cz) wrote: On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering mzerq...@0pointer.de wrote: plymouth_running()? Plymouth? Systemd knows about plymouth? Why? Because we need to constantly send updates to it. It's a trivial socket operation. It's a trivial thing and spawning a separate process to send those updates each and every single time is a major waste of resources and basically doubles the processes we have to spawn at boot. The long-term question here is what happens when Plymouth is replaced by something different, first in one specialist distribution, later by one major distribution (perhaps Fedora), and only much later by most distributions?. Will systemd only support the new thing, forcing the slower distributions to backport patches? Will systemd support both systems, and over time become burdened with compatibility code? Something else? As usual, we'll decide case-by-case and as I know myself and the triviality of this code we'd probably support both for a while and then drop the old code a bit later. Historically, each distribution had its own system integration scripts that supported only the tools the distribution cared about, so there never was a single project fighting with the matrix of N distributions x M implementations of major features. With systemd we have a very strict policy: we want to gently push the distros to standardize on the same components for the base system. That means that if you use ply and systemd together you get the best features but you can still use them independently too. It's loosely coupled, but we do want to get people to use this combination and no other by offering them the best support for this combination. (Also, most of them don't emit useful info on --help...) They aren't user binaries. They are in /lib/systemd, not /usr/bin... But they do implement user-visible functionality, and have user-visible /proc/cmdline options. Yes, old initscripts didn't document the behavior either, but the sysadmin (who, for better or worse, pretty much has to be able to read shell code) could find them and could understand and debug the boot process by reading /etc/rc.*. I think that asking the sysadmin to read the C code of systemd to understand the boot process and how it can be configured is rather excessive. I think systemd documentation is much better than the documentation of most other open source projects. If we missed something in the documentation please file a bug and we'll fix it. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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 Mon, 13.06.11 18:18, Denys Vlasenko (dvlas...@redhat.com) wrote: On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote: On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko dvlas...@redhat.com 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. Sloppy attitude like this is the reason just about any daemon (more and more of which pop up like mushrooms in every new release, I must add) eats at least a few megabytes of RAM. It's quite pathetic, really. You can easily tell which software was developed earlier just by looking at its memory usage. Example from my machine: Good old ssh-agent: 404 kbytes. Shiny new dconf-service: 2452 kbytes. Shinier newer polkitd: 2836 kbytes. e-addressbook-factory: 5488 kbytes. Of course. What did you think. *Addressbook*! (Empty one in my case). No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :( ~11MB equals ~8 cents of RAM ... so meh. Are you volunteering to buy more RAM for every Fedora user? ;) As mentioned this is primarily the SELinux policy we load. I wished libselinux would optimize memory usage transparently, but even without any changes in libselinux we should be able to optimize this a bit. Yes, using SELinux makes your boot a bit slower and consumes more resources, there is no news in that, and there's also no news in the fact that we can optimize this a bit when we are aware of it. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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 Mon, 13.06.11 18:18, Denys Vlasenko (dvlas...@redhat.com) wrote: On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote: On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko dvlas...@redhat.com 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. Sloppy attitude like this is the reason just about any daemon (more and more of which pop up like mushrooms in every new release, I must add) eats at least a few megabytes of RAM. It's quite pathetic, really. You can easily tell which software was developed earlier just by looking at its memory usage. Example from my machine: Good old ssh-agent: 404 kbytes. Shiny new dconf-service: 2452 kbytes. Shinier newer polkitd: 2836 kbytes. e-addressbook-factory: 5488 kbytes. Of course. What did you think. *Addressbook*! (Empty one in my case). No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :( ~11MB equals ~8 cents of RAM ... so meh. Are you volunteering to buy more RAM for every Fedora user? ;) As mentioned this is primarily the SELinux policy which we load into RAM. I wished libselinux would optimize resource usage transparently a bit better, but even without that we should be able to optimize this a bit in the way systemd loads the policy. SELinux makes boot slower and uses more resources, there is no news in that. There's also no news in the fact that we can definitely optimize its impact wherever we are aware of it. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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 Mon, 13.06.11 19:02, Denys Vlasenko (dvlas...@redhat.com) wrote: On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote: On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. I just tried it. So far flames don't shoot out of my notebook. Wow, that's convincing proof. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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 Mon, 13.06.11 22:46, Denys Vlasenko (dvlas...@redhat.com) wrote: In this case you are not better/worse than before, once the network will come up you'll add a script to change the hostname. Setting it earlier in systemd makes no difference. You continue to avoid answering my question: WHY systemd, a service management tool, bothers with setting hostname? It's not its task! As mentioned already: so that all userspace can rely on a valid hostname to be set. Which makes things much nicer for early boot logging as one example. And then there is simplicity, because you need no further configured service deps and you use less resources too, and it's simpler to read the sources, and faster, and more robust. Slide 6: We can now boot a system shell-free IOW: shell is bad, my new shiny toy is good. Oh god. If you had listened you'd have understood that my aim is to deemphasize shell in the boot process, not as an interactive tool or scripting tool. It's about the boot process, and nothing but the boot process. And as a matter of fact in all my talks I explicitly underline that fact. You are FUDding, and it's not helpful. Slide 14: systemd is an Init System systemd is a Platform systemd is a platform? Really? What next? systemd is an Aircraft Carrier? That is not a technical argument, but just FUDing. Of course, systemd is not an aircraft carrier. If all arguments you can come up with are made up arguments then you have no arguments at all. If you want to criticise systemd, then do it on technical grounds, not FUDing with things I never said and you sucked out of your fingers. More to the point: Lennart can call his program whatever he wants, even Nuclear Submarine. The point is: some people might disagree with having service management tool with Napoleonic aspirations. For one, I do! Good for you then. Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. Yeah, it's not the right tool for the boot process. Doesn't mean it wasn't useful for interactive use or for scripting. Just not the right tool for the boot process. Since you seem to have trouble understanding that, let me repeat it a couple of times: shell is not the best tool to accomplish a quick and reliable bootup. shell is not the best tool to accomplish a quick and reliable bootup. shell is not the best tool to accomplish a quick and reliable bootup. shell is not the best tool to accomplish a quick and reliable bootup. shell is not the best tool to accomplish a quick and reliable bootup. Slide 79: Substantial coverage of basic OS boot-up tasks, including fsck, mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots, cryptsetup, ... That's what I refer to by taking over the world. Well, I just refer to that as systemd as a platform for building an OS from. Note that neither slides, nor this email thread produced an explanation WHY all this stuff is thrown together into one project. In fact those slides you refer to explain all that. If you don't listen and don't want to read, then I cannot help you. One last try with different words, nonetheless: simplicity, speed, robustness, compactness, functionality. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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 Tue, 14.06.11 09:20, Denys Vlasenko (dvlas...@redhat.com) wrote: On Mon, 2011-06-13 at 21:44 -0400, Simo Sorce wrote: I wouldn't bother much if it would be just one tiny bit of strange code in systemd, but it is FAR from being the only such code. There are lots of similar stuff, and it's not accidental. It is definitely not accidental, but unless you have bugs to file, I don't think complain generically about systemd architecture here is any productive. Where, in your opinion, is the place to discuss systemd architecture? systemd is being discussed on the systemd mailing list and on the IRC channel. This is much like most projects are discussed on their respective mailing lists and IRC channels, and you should know that. We discussed systemd for quite a while here and it certainly far from perfect, for some things probably not even good yet. But its time to file bugs for real problems, not time for bike shedding on architectural decision that have been taken quite a while ago. I disagree, and I find the attitude we are developers, you are idiot both quite common and quite wrong. Oh come on. I have wide open ears. If people make constructive suggestions we listen, and we change things. We'll not change everything, and not without very good reasons, but claiming we wouldn't listen is just insulting. I am pretty sure you you will find a bunch of people who will testify that we implemented a feature they requested on this ML, on bz, at a conference, on IRC or some other place for them. Or we fixed a bug for them, or we even changed behaviour of systemd in one way or another on their request. Making a good case, being polite and convincing gets you a long way. systemd is developed in the open. You can easily participate in various ways. However, if you come overly late to the party, are insulting and demanding, imply we are idiots OR SHOUT ALL THE TIME, then we might be less willing to consider your requests. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi v0.8 in production
On 2011-06-13, Petr Pisar ppi...@redhat.com wrote: On 2011-06-10, Luke Macken lmac...@redhat.com wrote: * Buildroot Override Management http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides Excuse me for my low knowledge, what is good for? [...] Also the bodhi(1) from bodhi-client-0.8.0-1.fc15.noarch does not describe the option at all. Could somebody enlighten me? Thank all of you for clarification. I've opened ticket for bodhi https://fedorahosted.org/bodhi/ticket/615 to document it and attached patch for manual page there. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hallo to all, my name is Mario Santagiuliana, I am an Italian medical student. I start to use Fedora from the first release, then I upgrade to Fedora Core 3 and so on. I am a member of the Italian L10n team. I am a collaborator of fedoraonline.it, the Italian portal for Fedora community (linked in fedoracommunity.org). I start to become a packages mantainer because I want to give to Fedora and Users other not packaged software that can be useful and that can be improved. I start from akonadi-googledata: https://bugzilla.redhat.com/show_bug.cgi?id=711058 I want to package disper too: https://bugzilla.redhat.com/show_bug.cgi?id=712579 for that package I need a little help to understand something, I will contact the IRC channel in future. Other info about me can be found here: Fedorapeople: http://marionline.fedorapeople.org/ Fedora Wiki: http://fedoraproject.org/wiki/User:Marionline My personal website: http://www.marionline.it Have a nice day P.S. sorry for my English -- Mario Santagiuliana www.marionline.it signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 13.06.11 17:41, Miloslav Trmač (m...@volny.cz) wrote:
On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Mon, 13.06.11 14:27, Matthew Garrett (mj...@srcf.ucam.org) wrote:
It's a directory for arch-dependent stuff that should only exist once on
a system, whereas lib is for arch-dependent stuff that may exist for
multiple architectures on one system. I have no opinion on whether that
distinction is important.
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
Surely the 32-bit files don't belong to /usr/lib64?
Mirek
Oh, well, let me clarify this: the executable binaries are actually not
subarch-dependent: i.e. a 32bit process can spawn both 64bit and 32bit
binaries, and a 64bit process can spawn both, too. That means there is
no need to ship both versions of a binary, and while *arch-dependent* an
executable binary is not *subarch-dependent*. That means private
binaries unconditionally belong in /usr/lib, regardless for which
subarch they are compiled and you need only one version of them.
So putting this all together:
/usr/lib is for arch-dependent stuff, including the libraries of the
primary arch, and all subarch-independent private executable
binaries. Libraries for secondary archs (subarchs) are then but in
/usr/lib{64,arch}/.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What is the status of Features/YumLangpackPlugin?
You can use the internal identifier (which is never translated), yum groupinstall development-tools In F15, yum grouplist lists the identifier after each translation. For earlier releases I think you may have to lowercase the English and replace space by a hyphen? In the worst case one can check comps... Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 13.06.11 11:52, Simo Sorce (s...@redhat.com) wrote:
On Mon, 2011-06-13 at 17:41 +0200, Miloslav Trmač wrote:
On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Mon, 13.06.11 14:27, Matthew Garrett (mj...@srcf.ucam.org) wrote:
It's a directory for arch-dependent stuff that should only exist once on
a system, whereas lib is for arch-dependent stuff that may exist for
multiple architectures on one system. I have no opinion on whether that
distinction is important.
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
Surely the 32-bit files don't belong to /usr/lib64?
I thinkLennart is saying that on a 64 bit system they would have to go
to /usr/lib32
No, there is no /usr/lib32.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 13.06.11 13:25, Matthew Miller (mat...@mattdm.org) wrote:
On Mon, Jun 13, 2011 at 05:36:00PM +0200, Lennart Poettering wrote:
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
Gentoo is the only distro which is so confused to put binaries that
belong into /usr/lib into /usr/lib64 just because they are compiled for
64bit. But that's just because they are confused.
Errr, what?
Fedora has the same confusion.
No. For example: on Fedora the udev private binaries are in /lib/udev/
(where they belong). Gentoo is confused and puts them in /lib64/udev/
instead (which is broken).
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Tue, 14.06.11 00:31, Kevin Kofler (kevin.kof...@chello.at) wrote:
Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
The distinction between stuff which belongs into %{_libdir}, which is
different for 32-bit vs. 64-bit, vs. stuff which always goes to the same
place and where only one copy should be installed.
Well, but in which way is arch-dependent non-executable data any
different from private binaries? I see no reason why one should live in
libdir, and the other in libexecdir.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Hi, Of course my target is Scilab :) [https://bugzilla.redhat.com/show_bug.cgi?id=472639] but before that I also need jhdf (hdf-java) and hdf-view. Le lundi 13 juin 2011 à 12:37 +0100, José Matos a écrit : On Thursday 09 June 2011 15:54:14 Clément David wrote: Hi, My name is Clément DAVID (aka davidcl) and I'm a french software developer. I'm currently working on Scilab [1]. Welcome to Fedora. :-) I'm interested to become a packager for Scientific application or just software toys :). My first package has been approved (thanks to Alexander Kurtakov) [2] and build by koji [3]. Just curious, what is the scientific software that you interested to see packaged in Fedora other than naturally scilab? :-) My FAS name is davidcl. -- davidcl -- José Abílio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unresponsive maintainer: cvsgraph
Hi folks, Anyone knows how to contact cvsgraph maintainer (Marek Mahut)? Bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=709923 I already built the package for EL6, but don't have enough karma to put it in bodhi. It's a requirement for viewvc, which I maintain. -- Bojan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Hi, Thanks for the suggestion but I don't use this software, thus it might be hard to test :). -- davidcl Le lundi 13 juin 2011 à 13:44 +0200, Johannes Lips a écrit : Welcome to fedora, I am glad that you managed to get jlatexmath into fedora. If you are interested in mind-mapping there is a nice freemind plugin [1] to include LaTeX formulas into mind-maps which makes use of jlatexmath. If you are interested in packaging this little piece of software. I would be glad to help out if possible/necessary. ;-) johannes (irc-nick: hannes|) [1] https://github.com/Alxa/LaTeXMath-Freemind-Plugin On 06/13/2011 01:37 PM, José Matos wrote: On Thursday 09 June 2011 15:54:14 Clément David wrote: Hi, My name is Clément DAVID (aka davidcl) and I'm a french software developer. I'm currently working on Scilab [1]. Welcome to Fedora. :-) I'm interested to become a packager for Scientific application or just software toys :). My first package has been approved (thanks to Alexander Kurtakov) [2] and build by koji [3]. Just curious, what is the scientific software that you interested to see packaged in Fedora other than naturally scilab? :-) My FAS name is davidcl. -- davidcl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
2011/6/13 Kevin Kofler kevin.kof...@chello.at: Reindl Harald wrote: and even on a new setup this should be a decision of the user at the very beginning what init-system he wants to us No, the choice of this kind of core under-the-hood system components should be a decision of the distribution. To the user, it should be only an implementation detail. To the software on the distribution, it should matter that they can rely on the core system components being what they are and not have a user replace something as central as the init system. I think it makes no sense whatsoever to even OFFER upstart in F15+ as we are doing. I don't see any valid reason why you'd use it over systemd. From experience... i prefer having two tools available atleast to do every single job (especially when they exist) because then i have an easy fallback if one fails. Having upstart installed on rawhide during the f15 rawhide cycles was quite helpful to work around boot bugs on the fly without having to debug stuff or ending up with a nonbooting system (which makes it hard to dig up ml threads with workarounds, or up or downgrading packages). As long as someone maintains it i see no reason to exclude upstart completly from the repos. kind regards, Rudolf Kastl rhce rhca rhcss rhcx rhci Red Hat Inc. You complain about some bugs in systemd, those should be reported as bugs and fixed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
On 06/14/2011 03:15 PM, Rudolf Kastl wrote: From experience... i prefer having two tools available atleast to do every single job (especially when they exist) because then i have an easy fallback if one fails. Having upstart installed on rawhide during the f15 rawhide cycles was quite helpful to work around boot bugs on the fly without having to debug stuff or ending up with a nonbooting system (which makes it hard to dig up ml threads with workarounds, or up or downgrading packages). As long as someone maintains it i see no reason to exclude upstart completly from the repos. What do you about glibc bugs? Do you want to get them fixed or include alternatives? Having alternatives for each of the core components is a costly affair. it isn't just about maintaining upstart. It is also having to deal with two different type of init configuration scattered across the system, differences in handling many things including /etc/iniittab and /etc/fstab, having to maintain init scripts or upstart configuration files in all the different packages in addition to the systemd unit files and testing them regularly in the development cycle to ensure that changes we make for systemd doesn't impact negatively on upstart and so on. This is just silly. We have to draw the line somewhere Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On 14 June 2011 09:42, Mario Santagiuliana fed...@marionline.it wrote: Hallo to all, my name is Mario Santagiuliana, I am an Italian medical student. I start to use Fedora from the first release, then I upgrade to Fedora Core 3 and so on. I am a member of the Italian L10n team. I am a collaborator of fedoraonline.it, the Italian portal for Fedora community (linked in fedoracommunity.org). I start to become a packages mantainer because I want to give to Fedora and Users other not packaged software that can be useful and that can be improved. I start from akonadi-googledata: https://bugzilla.redhat.com/show_bug.cgi?id=711058 I want to package disper too: https://bugzilla.redhat.com/show_bug.cgi?id=712579 for that package I need a little help to understand something, I will contact the IRC channel in future. Other info about me can be found here: Fedorapeople: http://marionline.fedorapeople.org/ Fedora Wiki: http://fedoraproject.org/wiki/User:Marionline My personal website: http://www.marionline.it Have a nice day P.S. sorry for my English -- Mario Santagiuliana www.marionline.it Hi, As a medical student you may be interested in the activities of the Fedora Medical Special Interest Group: http://fedoraproject.org/wiki/SIGs/FedoraMedical Regards, Mat -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
2011/6/14 Ralf Corsepius rc040...@freenet.de:
On 06/14/2011 12:26 AM, Kevin Kofler wrote:
Haïkel Guémar wrote:
I spent some time yesterday talking with opensuse guys on irc, since
/usr/libexec has not been blessed by FHS
libexecdir is GNU Standards for ages (decades).
It's supposed to be kind of an auxilliary bindir, to hide away
programs, users are not supposed to execute directly.
It's formal definition[1] is
cite
libexecdir
The directory for installing executable programs to be run by other
programs rather than by users. This directory should normally be
‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you
are using Autoconf, write it as ‘@libexecdir@’.)
The definition of ‘libexecdir’ is the same for all packages, so you
should install your data in a subdirectory thereof. Most packages
install their data under ‘$(libexecdir)/package-name/’, possibly within
additional subdirectories thereof, such as
‘$(libexecdir)/package-name/machine/version’.
/cite
In Fedora, we treat libexecdir as optional and allow packages to install
such non-user programs to %libdir/subdir/ instead, primarily for
historical reasons.
Actually, libexec can be interpreted as being a libdir with the multilib
suffix exec (just like 64 is one),
Multilib subdirs are arbitrary directory names. There is no convention
of them being named lib*.
You might not have tripped over such them on intel based platforms, but
are very common on other architectures/OSes.
Ralf
[1] http://www.gnu.org/prep/standards/standards.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Do we agree that until FHS canonicalize libexecdir, libexecdir is the
recommended location for helper scripts and that /usr/{lib,share} are
*tolerated* (ie: not configurable, requires non-upstream-able
intrusive patch etc ...) ? In consequence, we should then update
packaging guidelines to explicitely state this.
http://bugs.linuxfoundation.org/show_bug.cgi?id=101
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
My laptop can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16 - the boot process just stops at random points and CPU usage goes high. systemd-28-3.fc16 and kernel-3.0-0.rc2.git0.2.fc16 - did not have this behavior. The only possible way to boot is to add selinux=0. Especially for Daniel J Walsh, the addition of enforcing=0 doesn't make any difference - boot stops. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
On 14/06/11 11:02, Lucas wrote: snip The only possible way to boot is to add selinux=0. Especially for Daniel J Walsh, the addition of enforcing=0 doesn't make any difference - boot stops. Thanks. Last time I had similar problem, ended up: rpm -e --nodeps selinux-policy selinux-policy-targeted yum install selinux-policy selinux-policy-targeted touch /.autorelabel; reboot and then all was ok. ymmv. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer: cvsgraph
On Tue, 14 Jun 2011 19:16:16 +1000, BS wrote: Hi folks, Anyone knows how to contact cvsgraph maintainer (Marek Mahut)? Bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=709923 I already built the package for EL6, but don't have enough karma to put it in bodhi. It's a requirement for viewvc, which I maintain. Wrong terminology used here. Karma in bodhi is unrelated to who can publish updates there. You've requested commit access for cvsgraph EPEL 6 in pkgdb, and Marek would need to approve that request. http://bugz.fedoraproject.org/cvsgraph https://admin.fedoraproject.org/pkgdb/acls/name/cvsgraph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On 06/14/2011 11:57 AM, 80 wrote:
2011/6/14 Ralf Corsepiusrc040...@freenet.de:
On 06/14/2011 12:26 AM, Kevin Kofler wrote:
Haïkel Guémar wrote:
I spent some time yesterday talking with opensuse guys on irc, since
/usr/libexec has not been blessed by FHS
libexecdir is GNU Standards for ages (decades).
It's supposed to be kind of an auxilliary bindir, to hide away
programs, users are not supposed to execute directly.
It's formal definition[1] is
cite
libexecdir
The directory for installing executable programs to be run by other
programs rather than by users. This directory should normally be
‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you
are using Autoconf, write it as ‘@libexecdir@’.)
The definition of ‘libexecdir’ is the same for all packages, so you
should install your data in a subdirectory thereof. Most packages
install their data under ‘$(libexecdir)/package-name/’, possibly within
additional subdirectories thereof, such as
‘$(libexecdir)/package-name/machine/version’.
/cite
In Fedora, we treat libexecdir as optional and allow packages to install
such non-user programs to %libdir/subdir/ instead, primarily for
historical reasons.
[1] http://www.gnu.org/prep/standards/standards.html
Do we agree that until FHS canonicalize libexecdir, libexecdir is the
recommended location for helper scripts and that /usr/{lib,share} are
*tolerated* (ie: not configurable, requires non-upstream-able
intrusive patch etc ...) ?
Well, I would agree to tolerating /usr/lib/package/ (Which btw is the
current defacto rule in Fedora practice) but would disagree otherwise,
because
- /usr/share (aka datadir) is reserved for arch-independent data, i.e.
should not contain executables and programs.
- /usr/lib (according to the GNU coding standards) should not contain
programs.
- $(libdir)/package/ basically is a package's private play-ground and
therefore may also contain programs and scripts.
In consequence, we should then update
packaging guidelines to explicitely state this.
sigh/ some people seem to need written rules for everything, for what
generations of people before them took for granted ;)
Ralf
--
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 Tue, 2011-06-14 at 09:42 +0200, Lennart Poettering wrote: On Mon, 13.06.11 18:01, Denys Vlasenko (dvlas...@redhat.com) wrote: Maybe. It's not up to a piece of software to decide. In Unix, admins should have power to decide, not programs. Programs provide the means, they don't dictate policies. Dude, systemd requires the functionality of the three modules it loads explicitly. systemd requires ipv6. And you pitch systemd to be used by embedded devices. Do you really think all embedded devices will be happy with having such an arbitrary requirement? Heck, I know embedded device people who remove even ipv4! I think systemd is much more optimized that what existed previously. (what else is parallelization but optimization?) I bet with you that a systemd system (modulo SELinux) can be built in a way that uses much less resources and boot time than one built on Upstart. I never used upstart. I used daemontools. I bet you can't beat *that* on resource front. Boot time is comparable. daemontools does not support socket activation for parallelizing execution of servers with its clients. So yes, we can beat *that*. I said you can't beat *that* on resource front. On resource front. Can you beat it on resource front? I mean, this is like comparing apples and oranges. systemd gives you an OS building box, daemontools nothing but a service supervisor. Which is what I *like* about daemontools. It's Unix way to be nothing but a tool for one purpose, ans serve it well. If you use daemontools you also need an init system, and boot scripts, and everything else. So yeah, if you compare systemd and daemontools+sysvinit+initscripts then, hell yeah, I can beat that. This is not true. daemontools can be set up in a way than most init scripts are no longer necessary. It also achieves parallelized start. It can also be used as an init replacement, but unlike systemd, it does not make it a requirement. On my home machine I use a separate init (which does only child reaping), daemontools, and a very small set of init scripts (yes, horror, shell scripts). It starts in about 3 seconds. The system fully booted to text mode uses 20 megs of RAM total, all processes plus kernel, but excluding fs cache. You can't beat that. In fact, you are yet to reply why systemd uses eleven megs of RAM all by itself. daemontools don't do socket activation, therefore I'm not proposing we use daemontools instead of systems. IOW, I do not claim that daemontools is a better service management tool that systemd. I do argue that deamontools goal to provide ONLY service management instead of being shampoo and conditioner in one pack is a better approach. Hmm? systemd is an init system, so it is of course PID 1. Again. *Why it has to have PID 1* to spawn and control services? Can you please answer this? Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized processes. Why service daemon needs to receive death notifications from daemonized processes? -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer: cvsgraph
Michael Schwendt mschwendt at gmail.com writes: Wrong terminology used here. Karma in bodhi is unrelated to who can publish updates there. You've requested commit access for cvsgraph EPEL 6 in pkgdb, and Marek would need to approve that request. http://bugz.fedoraproject.org/cvsgraph https://admin.fedoraproject.org/pkgdb/acls/name/cvsgraph Er, I don't really care, as long the package lands in EL6, so that viewvc lands there too. PS. Marek responded to the bug report, so we are going to get it fixed there. -- Bojan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
I've installed XFCE. It was easy to install, and it works sanely (unlike GNOME 3 / Unity). 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/14/2011 11:17 AM, Somebody in the thread at some point said: Hi - Dude, systemd requires the functionality of the three modules it loads explicitly. systemd requires ipv6. And you pitch systemd to be used by embedded devices. Do you really think all embedded devices will be happy with having such an arbitrary requirement? Heck, I know embedded device people who remove even ipv4! IPv6 is optional though, Lennart says you can blacklist the module. If it acts gracefully if IPv6 is not builtin or installable by module then all is well. Embedded as an argument needs a lot of care. It means several very different things, but many of those things are out of scope for Fedora, eg, ARM7. (Use busybox there ^^) For what's left, eg ARM9+ that you can run normal Linux and Fedora on, ipv6 is going to be workable if the memory allows. Looking a year or two ahead, where Embedded will extend to Cortex A15 quad core, and IPv6 will presumably have gained traction, the tradeoffs involved with cutdown environments like busybox / dropbear and IPv4-only are going to start being harder to accept. So while it's super healthy to press system tools on bloat, it is quite possible to deploy the Embedded argument to go too far and conflict with what Fedora is and trying to do overall -- and what other Embedded guys will want from it in future. Embedded is generally converging towards the kind of full strength systems we use on x86 today. -Andy -- 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 Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote: On Mon, 13.06.11 22:46, Denys Vlasenko (dvlas...@redhat.com) wrote: Slide 6: We can now boot a system shell-free IOW: shell is bad, my new shiny toy is good. Oh god. If you had listened you'd have understood that my aim is to deemphasize shell in the boot process You go quite farther than that. We can now boot a system shell-free. *Shell-free*. You are not saying driving boot process by shell scripts is slow because ... ... ... (an argument I would agree with), you are aiming at *eliminating* shell scripts from boot process. Slide 14: systemd is an Init System systemd is a Platform systemd is a platform? Really? What next? systemd is an Aircraft Carrier? That is not a technical argument, but just FUDing. No, it is a technical argument. I am saying that this is not how things are supposed to be done in Unix. I am saying that you are trying to incorporate as much stuff as possible into systemd, and I think it's wrong. You don't like me saying this? Well, not a surprise. I also don't like when people tell me that I'm wrong. Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. Yeah, it's not the right tool for the boot process. Doesn't mean it wasn't useful for interactive use or for scripting. Just not the right tool for the boot process. Since you seem to have trouble understanding that, let me repeat it a couple of times: shell is not the best tool to accomplish a quick and reliable bootup. Can shell play a part in the boot process, or is it now completely banished? I don't know, is something like this acceptable in the new world of systemd? ulimit -d $((16*1024*1024)) exec my_favorite_program some_opts Slide 79: Substantial coverage of basic OS boot-up tasks, including fsck, mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots, cryptsetup, ... That's what I refer to by taking over the world. Well, I just refer to that as systemd as a platform for building an OS from. Note that neither slides, nor this email thread produced an explanation WHY all this stuff is thrown together into one project. In fact those slides you refer to explain all that. If you don't listen and don't want to read, then I cannot help you. One last try with different words, nonetheless: simplicity, speed, robustness, compactness, functionality. Good that you don't include modularity any more. At least one of my arguments reached through, it seems. Let's take a look at each of them: simplicity - I don't see it speed - yes robustness - actually yes, your code seems to be good in that area compactness - no functionality - too much of it. I'd call it bloat I would also add monolithic and inflexible. Sorry. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 706878] perl-Mojolicious-1.43 is available
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=706878 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Mojolicious-1.42 is|perl-Mojolicious-1.43 is |available |available --- Comment #3 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-06-14 06:33:31 EDT --- Latest upstream release: 1.43 Current version in Fedora Rawhide: 1.42 URL: http://search.cpan.org/dist/Mojolicious/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
On 06/14/2011 02:10 PM, Frank Murphy wrote: On 14/06/11 11:02, Lucas wrote: snip The only possible way to boot is to add selinux=0. Especially for Daniel J Walsh, the addition of enforcing=0 doesn't make any difference - boot stops. Thanks. Last time I had similar problem, ended up: rpm -e --nodeps selinux-policy selinux-policy-targeted yum install selinux-policy selinux-policy-targeted touch /.autorelabel; reboot and then all was ok. ymmv. In my case relabeling did not help at all. -- 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 Tue, 2011-06-14 at 11:31 +0100, Andy Green (林安廸) wrote: Dude, systemd requires the functionality of the three modules it loads explicitly. systemd requires ipv6. And you pitch systemd to be used by embedded devices. Do you really think all embedded devices will be happy with having such an arbitrary requirement? Heck, I know embedded device people who remove even ipv4! IPv6 is optional though, Lennart says you can blacklist the module. If it acts gracefully if IPv6 is not builtin or installable by module then all is well. Embedded as an argument needs a lot of care. It means several very different things, but many of those things are out of scope for Fedora, eg, ARM7. (Use busybox there ^^) For what's left, eg ARM9+ that you can run normal Linux and Fedora on, ipv6 is going to be workable if the memory allows. Looking a year or two ahead, where Embedded will extend to Cortex A15 quad core, and IPv6 will presumably have gained traction, the tradeoffs involved with cutdown environments like busybox / dropbear and IPv4-only are going to start being harder to accept. I talk to a lot of embedded people. Tiny machines are not going to disappear anytime soon - they just go into smaller and smaller gadgets. For example, there are still a noticeable segment of NOMMU CPUs, meaning if you really target embedded, you need to learn how to live with vfork only. You can't just handwave embedded away by assuming that embedded will get big enough for me to not really care about optimizing for size. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 713111] perl-Date-Manip-6.24 is available
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=713111 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|mmasl...@redhat.com |psab...@redhat.com -- 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: systemd: please stop trying to take over the world :)
On 06/14/2011 04:13 PM, Denys Vlasenko wrote: I talk to a lot of embedded people. Tiny machines are not going to disappear anytime soon - they just go into smaller and smaller gadgets. For example, there are still a noticeable segment of NOMMU CPUs, meaning if you really target embedded, you need to learn how to live with vfork only. You can't just handwave embedded away by assuming that embedded will get big enough for me to not really care about optimizing for size. Since ipv6 is really optional in systemd, why are you even arguing about this at all, anymore? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Date-Manip-6.24.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Date-Manip: 4655901191bce84d8e089b6c9d542e1e Date-Manip-6.24.tar.gz -- 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: systemd: please stop trying to take over the world :)
On Tue, 14.06.11 12:17, Denys Vlasenko (dvlas...@redhat.com) wrote: On Tue, 2011-06-14 at 09:42 +0200, Lennart Poettering wrote: On Mon, 13.06.11 18:01, Denys Vlasenko (dvlas...@redhat.com) wrote: Maybe. It's not up to a piece of software to decide. In Unix, admins should have power to decide, not programs. Programs provide the means, they don't dictate policies. Dude, systemd requires the functionality of the three modules it loads explicitly. systemd requires ipv6. No it doesn't. All it does is make use of IPv6 if it is available (where available means: if compiled in to the kernel or compiled as kmod and not blacklisted). It requires the kernel module to be loaded properly at boot to make use of that, hence it will try loading it, unless it is explicitly blacklisted. And you pitch systemd to be used by embedded devices. Yes, I do. Do you really think all embedded devices will be happy with having such an arbitrary requirement? Heck, I know embedded device people who remove even ipv4! I said multiple times explicitly that systemd explicitly supports IPv6-less systems. If you use daemontools you also need an init system, and boot scripts, and everything else. So yeah, if you compare systemd and daemontools+sysvinit+initscripts then, hell yeah, I can beat that. This is not true. It is. daemontools can be set up in a way than most init scripts are no longer necessary. It also achieves parallelized start. This is bogus. It can also be used as an init replacement, but unlike systemd, it does not make it a requirement. On my home machine I use a separate init (which does only child reaping), daemontools, and a very small set of init scripts (yes, horror, shell scripts). It starts in about 3 seconds. The system fully booted to text mode uses 20 megs of RAM total, all processes plus kernel, but excluding fs cache. Good for you, but what does that have to do with Fedora? You can't beat that. In fact, you are yet to reply why systemd uses eleven megs of RAM all by itself. Hey, read my mails: SELinux policy, SELinux policy, SELinux policy, SELinux policy, SELinux policy. Hmm? systemd is an init system, so it is of course PID 1. Again. *Why it has to have PID 1* to spawn and control services? Can you please answer this? Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized processes. Why service daemon needs to receive death notifications from daemonized processes? To be able to supervise them? That's a key feature of supervision of services: that you know when a daemon is gone, and know the exit code and whether it crashed or not. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Is not it easy to remove everything from: default.target basic.target graphical.target ... and then add whatever we want to start or to execute or mount? I do not really care what systemd CAN do, but really care what it is doing on my system. So, may be some cleaning will be the wise solution. One would like to eat fish Eat one's cake and have it И волки сыты и овцы целы. -- 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/14/2011 11:43 AM, Somebody in the thread at some point said: For what's left, eg ARM9+ that you can run normal Linux and Fedora on, ipv6 is going to be workable if the memory allows. Looking a year or two ahead, where Embedded will extend to Cortex A15 quad core, and IPv6 will presumably have gained traction, the tradeoffs involved with cutdown environments like busybox / dropbear and IPv4-only are going to start being harder to accept. I talk to a lot of embedded people. Tiny machines are not going to disappear anytime soon - they just go into smaller and smaller gadgets. Me too... I think maybe considerations valid at the low-end devices you know very well are blinding you a bit to how applicable those considerations are, eg -- For example, there are still a noticeable segment of NOMMU CPUs, meaning if you really target embedded, you need to learn how to live with vfork only. ... NOMMU and ARM7 that can't run Fedora are to discussions about architecture of Fedora. You can't just handwave embedded away by assuming that embedded will get big enough for me to not really care about optimizing for size. My point was that pressure against bloat is good. But when I look at compromises made in stuff commonly used in ARM7 / cross world, I wouldn't want to see that happening in Fedora in the name of a debloating jihad that simply doesn't matter on most of the platforms it targets. Still, I hope this thread at least reminded people that it doesn't hurt to have a modest memory footprint ^^ -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
2011/6/14 Rahul Sundaram methe...@gmail.com: On 06/14/2011 03:15 PM, Rudolf Kastl wrote: From experience... i prefer having two tools available atleast to do every single job (especially when they exist) because then i have an easy fallback if one fails. Having upstart installed on rawhide during the f15 rawhide cycles was quite helpful to work around boot bugs on the fly without having to debug stuff or ending up with a nonbooting system (which makes it hard to dig up ml threads with workarounds, or up or downgrading packages). As long as someone maintains it i see no reason to exclude upstart completly from the repos. What do you about glibc bugs? Do you want to get them fixed or include alternatives? its been many years since i have seen a glibc bug that makes my system completly unbootable. i have had various issues during the last devel cycle where my system wouldnt boot anymore and upstart was a good shorttime fallback. having an alternative doesent mean that bugs should be covered instead fixed. i never proposed this and i am not sure why you start off like that on me. Having alternatives for each of the core components is a costly affair. it isn't just about maintaining upstart. It is also having to deal with two different type of init configuration scattered across the system, differences in handling many things including /etc/iniittab and /etc/fstab, having to maintain init scripts or upstart configuration files in all the different packages in addition to the systemd unit files and testing them regularly in the development cycle to ensure that changes we make for systemd doesn't impact negatively on upstart and so on. This is just silly. We have to draw the line somewhere I never proposed having alternatives for each of the core systems either... There is already a viable alternative that works. inittab contains atm exactly one line... the one with the default runlevel... and /etc/fstab can be parsed differently if there are changes. Also i do not understand the Argument with the unit files... they are systemd related. upstart isnt affected. Since upstart isnt installed by default anyways it also doesent matter for critical path. Got a hard time to follow your argumentation there. SystemV init scripts are already present and work quite well aswell. This is just silly. Not commenting that. We have to draw the line somewhere Draw your line ;) kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
On 06/14/2011 04:36 PM, Rudolf Kastl wrote: I never proposed having alternatives for each of the core systems either... There is already a viable alternative that works. inittab contains atm exactly one line... the one with the default runlevel... and /etc/fstab can be parsed differently if there are changes. systemd doesn't use /etc/inittab and upstart uses it. So you have to account for the differences and test them. Also i do not understand the Argument with the unit files... they are systemd related. upstart isnt affected. Since upstart isnt installed by default anyways it also doesent matter for critical path. Got a hard time to follow your argumentation there. SystemV init scripts are already present and work quite well aswell. You miss the point. Packages are already dropping init scripts and converting to using systemd unit files. To maintain upstart compatibility you have to continue to maintain sys init scripts in addition to systemd unit files and again make sure they don't diverge and they both work equivalently. Who is volunteering for that? 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/14/2011 04:06 AM, Lennart Poettering wrote: On Mon, 13.06.11 19:02, Denys Vlasenko (dvlas...@redhat.com) wrote: On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote: On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. I just tried it. So far flames don't shoot out of my notebook. Wow, that's convincing proof. Lennart One question - does systemd run /etc/rc.local script? If not where do I put my own little things I want to happen at boot up. -- 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: effective communication and effective free software
On Mon, 2011-06-13 at 13:35 -0400, Adam Jackson wrote: On 6/13/11 12:18 PM, Denys Vlasenko wrote: Sloppy attitude like this is the reason just about any daemon (more and more of which pop up like mushrooms in every new release, I must add) eats at least a few megabytes of RAM. I'd have more empathy for your position if you'd made even a cursory investigation into what that memory was being used for. To be clear, this is an observation about how you're presenting your argument. The original post reads mostly as this looks like it's doing too much, because of these things that I don't understand but I just _know_ they're not necessary, Yes, this is essentially correct. so obviously this is all crap and everyone who's working on it should be ashamed. To be sure, I reviewed my mail which started the thread. I didn't say anything like that. Would you rather make a good OS, or have internet arguments about why we're making a bad OS? Well, I would like to do something which will make future Fedora releases to go into better direction than F15 went. Of course I want to make a good OS. It's not that easy though, because OS can't be written by one person, therefore we need to work together, and different people have different ideas what is good. Worse still, computer guys in general (me included) are not masters of communication... If you approach a project by saying I've found that we're burning a lot of memory here, and I don't quite understand why, but it seems to be related to the frobnitz component, that's productive. It shows that you're concerned with quality, and that you've put some effort into understanding how things are already structured, even if you don't have a solution. It's a sign that you have some skin in the game (apologies if that idiom doesn't translate well). You are right. However, I can participate in only so much open source projects before my day stops fitting into 24 hours. Should I not comment at all on any projects where I don't have time to become a contributor? Instead, when you say things like: It's quite pathetic, really. You can easily tell which software was developed earlier just by looking at its memory usage. ... the message is that you're not, in fact, invested, that you're perfectly happy to just switch back to twm because you don't need all that fancy stuff. I am not really that far in geek field to go back to using software from 1980s. I do think that progress is needed. How can I express a point the software becomes more bloated in general and I think it's wrong? The options which you seem to advocate is to spend three weeks digging in the sources of dozens of projects and present my findings where exactly it happens. There is a few problems with it: One, it is far too time-consuming. I do have more useful things to do, I really do. For one, I can work on fixing one of 40+ open bugs in *my* project. Second, no one would listen. I know it *because it was already done*. My colleague Jaroslav Reznik tells me a story about a guy who spend lots of time investigating and prepared a presentation Why KDE is bloated where he did exactly that: presented concrete examples where KDE fumbles badly on memory consumption front. Guess what: a few years later the presentation is still relevant, because KDE people did not act on the data. So yes, you are right that most likely Lennart will simply ignore everything I say. I disagree, though, that being extra nice and/or investing more time into deeply investigating systemd code and trying to become a co-developer would meaningfully change the outcome. I tried this several times with various projects. I know when it makes sense to do it, and this is not such case. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What is the status of Features/YumLangpackPlugin?
2011/6/14 Itamar Reis Peixoto ita...@ispbrasil.com.br: where I can get a list of internal identifiers yum grouplist -v shows them. -- Thomas Moschny thomas.mosc...@gmail.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 Tue, 14.06.11 12:36, Denys Vlasenko (dvlas...@redhat.com) wrote: On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote: On Mon, 13.06.11 22:46, Denys Vlasenko (dvlas...@redhat.com) wrote: Slide 6: We can now boot a system shell-free IOW: shell is bad, my new shiny toy is good. Oh god. If you had listened you'd have understood that my aim is to deemphasize shell in the boot process You go quite farther than that. We can now boot a system shell-free. *Shell-free*. Yupp, and this is one of the reasons why we boot so fast and can boot a reasonably comprehensive userspace in less than one second. A shell-free boot doesn't mean there wasn't any /bin/sh anymore. I mean, I use bash all the time, it's a key way how I interface with my machine. I use it in build scripts and everything, and I have no plans at all to remove it from that and doing that would be crazy. But in the boot process? I don't think it is the best tool for the job, and unnecessary, and if we deemphasize or remove it from the boot process we have a lot to win. You are not saying driving boot process by shell scripts is slow because ... ... ... (an argument I would agree with), you are aiming at *eliminating* shell scripts from boot process. Yes, I want to deemphasize the shell in the boot process, and ideally remove it entirely from the boot process. Slide 14: systemd is an Init System systemd is a Platform systemd is a platform? Really? What next? systemd is an Aircraft Carrier? That is not a technical argument, but just FUDing. No, it is a technical argument. I am saying that this is not how things are supposed to be done in Unix. I am saying that you are trying to incorporate as much stuff as possible into systemd, and I think it's wrong. You don't like me saying this? Well, not a surprise. I also don't like when people tell me that I'm wrong. Wow, you honestly believe that suggesting systemd would turn into an aircraft carrier is a technical argument? Must be good stuff you are smoking... I think we'll just have to agree to disagree and leave it at that. Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. Yeah, it's not the right tool for the boot process. Doesn't mean it wasn't useful for interactive use or for scripting. Just not the right tool for the boot process. Since you seem to have trouble understanding that, let me repeat it a couple of times: shell is not the best tool to accomplish a quick and reliable bootup. Can shell play a part in the boot process, or is it now completely banished? I don't know, is something like this acceptable in the new world of systemd? systemd will not take /bin/sh away from you. It will just give you the right tools so that you don't need it anymore for booting, thus saving resources, making things faster and more robust. We will continue to support SysV init scripts for a long time, for compatibility reasons, and you'll always be able to plug a shell script into the ExecStart= line of a systemd service file, if you want to. ulimit -d $((16*1024*1024)) exec my_favorite_program some_opts Sure you can do that, systemd will not take that away from you. However, we offer you a nicer, more descriptive, more homogenous way to do that in the service file itself, simply by using LimitDATA= in the service file. Easier to use, more descriptive, faster and involves no shell. In fact those slides you refer to explain all that. If you don't listen and don't want to read, then I cannot help you. One last try with different words, nonetheless: simplicity, speed, robustness, compactness, functionality. Good that you don't include modularity any more. At least one of my arguments reached through, it seems. Uh? systemd is modular. Absolutely, you can choose the parts you want and the ones you don't, which is handy for embedded uses. If you however ask why we integrate a lot of previously separate stuff in systemd, then answering to make it modular would be kinda bogus. systemd is absolutely modular, but modularity is not a reason for integrating things the way we do. Oh, and the list above why we do this is not complete anyway, there's a lot I could still add as reasons why we integrate things like this. For example we want to use systemd as gentle push for the distros using it to unify, standardize and de-balkanize the basic set of components of the OS. Let's take a look at each of them: simplicity - I don't see it What's so hard to understand, that with systemd you need 10 basic packages to build a minimal system, and without systemd you need 50. systemd is hence much simpler to understand. (these are not exact numbers) speed - yes robustness - actually yes, your code seems to be good in that area compactness - no Oh hell, absolutely. It's much
Re: systemd: please stop trying to take over the world :)
On Tue, 14.06.11 07:14, Steve Clark (scl...@netwolves.com) wrote: On 06/14/2011 04:06 AM, Lennart Poettering wrote: On Mon, 13.06.11 19:02, Denys Vlasenko (dvlas...@redhat.com) wrote: On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote: On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. I just tried it. So far flames don't shoot out of my notebook. Wow, that's convincing proof. Lennart One question - does systemd run /etc/rc.local script? If not where do I put my own little things I want to happen at boot up. Yes, it does run that on Fedora by default. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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 Tue, 2011-06-14 at 09:53 +0200, Lennart Poettering wrote: Changing a machine hostname at random times is just asking for trouble. Well, but it has been used in the past, and as definitely something we should support in one way or another. Never said we shouldn't allow it to change, just that if you do some things may break in more or less evident ways. Which is why we have this: https://fedoraproject.org/wiki/Features/nssmyhostname and http://www.freedesktop.org/wiki/Software/systemd/hostnamed and there are even people working on sending out change notifications from /proc/sys/kernel/hostname in the kernel. What's the problem of having a specific hostname set up at boot time ? The user might want to change it? Does setting it at boot time prevent you from changing it later ? DHCP wants to change it? Name conflict in the local network, and Avahi wants to change it? Of course, the latter we don't necessarily want to do by default, but they are valid uses. There is always good reasons to change it at one time or another, none of these say it is a bad idea to set it early though. In general I see 3 categories of machine: - diskless machines that needs to get the hostname from DHCP as they have no local configuration storage whatsoever - personal, un-managed machines that can change name on a whim. - managed machines, that may have keytabs and can never change name but use things like dynDNS instead to tell other machines where they are. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
On 06/14/2011 07:08 AM, Rahul Sundaram wrote: On 06/14/2011 04:36 PM, Rudolf Kastl wrote: I never proposed having alternatives for each of the core systems either... There is already a viable alternative that works. inittab contains atm exactly one line... the one with the default runlevel... and /etc/fstab can be parsed differently if there are changes. systemd doesn't use /etc/inittab and upstart uses it. So you have to account for the differences and test them. Also i do not understand the Argument with the unit files... they are systemd related. upstart isnt affected. Since upstart isnt installed by default anyways it also doesent matter for critical path. Got a hard time to follow your argumentation there. SystemV init scripts are already present and work quite well aswell. You miss the point. Packages are already dropping init scripts and converting to using systemd unit files. To maintain upstart compatibility you have to continue to maintain sys init scripts in addition to systemd unit files and again make sure they don't diverge and they both work equivalently. Who is volunteering for that? Rahul You already are maintaining multiple UI systems which seem to me to be much more complex than two different init systems. -- 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: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
On 06/14/2011 04:56 PM, Steve Clark wrote: You already are maintaining multiple UI systems which seem to me to be much more complex than two different init systems. Not the same thing at all. Maintenance of desktop environments doesn't affect people outside a few people who do that. If I don't care about fluxbox, I can ignore it completely. Maintaining two init systems actively affects everyone who has a init script in their packages which is a lot more. This is non-trivial and I don't see why I should volunteer to test both a init script and a equivalent systemd unit file. If someone is interested in maintaining upstart for current Fedora 15 and above, they should take care of this entirely and I will do it for one init system which is the default one. 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 Tue, 2011-06-14 at 13:14 +0200, Lennart Poettering wrote: On Tue, 14.06.11 12:36, Denys Vlasenko (dvlas...@redhat.com) wrote: On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote: On Mon, 13.06.11 22:46, Denys Vlasenko (dvlas...@redhat.com) wrote: Slide 6: We can now boot a system shell-free IOW: shell is bad, my new shiny toy is good. Oh god. If you had listened you'd have understood that my aim is to deemphasize shell in the boot process You go quite farther than that. We can now boot a system shell-free. *Shell-free*. Yupp, and this is one of the reasons why we boot so fast and can boot a reasonably comprehensive userspace in less than one second. Wrong. Running shell scripts per se is not a significant slowdown. daemontools does it all the time. It just *runs them in parallel*. Performing system initialization *from* shell scripts *is* significant slowdown, because writing parallelized init in shell, correctly, is not easy. A shell-free boot doesn't mean there wasn't any /bin/sh anymore. I mean, I use bash all the time, it's a key way how I interface with my machine. I use it in build scripts and everything, and I have no plans at all to remove it from that and doing that would be crazy. I never thought you want to do that. No argument here. But in the boot process? I don't think it is the best tool for the job, and unnecessary, and if we deemphasize or remove it from the boot process we have a lot to win. I don't think this is the only your motivation. You want to acquire as much turf as possible. Killing shell scripts everywhere in init process and requiring everyone to use systemd's way to set ulimit and whatnot etc will give you significant amounts of authority and power. Packaging people will be forced to come to you and ask for this and that (anything they could do in shell scripts, but not they can't). This will feel good, right? You will be such an important guy! I don't see any other reason for the crusade to eliminate shell scripting from boot process. You are too clever to actually believe that shell script start time is the biggest problem in boot time. systemd will not take /bin/sh away from you. It will just give you the right tools so that you don't need it anymore for booting, thus saving resources, making things faster and more robust. We will continue to support SysV init scripts for a long time, for compatibility reasons, and you'll always be able to plug a shell script into the ExecStart= line of a systemd service file, if you want to. ulimit -d $((16*1024*1024)) exec my_favorite_program some_opts Sure you can do that, systemd will not take that away from you. However, we offer you a nicer, more descriptive, more homogenous way to do that in the service file itself, simply by using LimitDATA= in the service file. Easier to use, more descriptive, faster and involves no shell. Exactly as I suspected. Your new shiny way is better than our stupid old way. Except that I was quite happy with the old stupid way of setting data segment limit. I don't want to learn new way just to stroke your oversized ego by being forced to do it your way. daemontools has it right: it doesn't force me to abandon what worked so well for 40 years. It allowed me to run a service by writing a small shell script which can set, say, ulimit. Or cd to a directory. Or chroot. Or export a variable. Or mkdir /var/run/FOO... -- vda -- 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 Tue, 2011-06-14 at 12:53 +0200, Lennart Poettering wrote: daemontools can be set up in a way than most init scripts are no longer necessary. It also achieves parallelized start. This is bogus. Amazingly deep argument. Can you do better than this? Hmm? systemd is an init system, so it is of course PID 1. Again. *Why it has to have PID 1* to spawn and control services? Can you please answer this? Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized processes. Why service daemon needs to receive death notifications from daemonized processes? To be able to supervise them? That's a key feature of supervision of services: that you know when a daemon is gone, and know the exit code and whether it crashed or not. This is bogus (c) Lennart. You can't know that because you have no idea that dead process with pid N is a daemon you started for service FOO. Because when you started it, its pid was not N (if it really did daemonize). With sufficient amount of nutty hackery it may be possible to figure is out, but it will be either racy, or will require labeling (process groups? session ids? cgroups?) which, in general, is not reliable: processes can escape from that. Much saner solution is to simply require controlled processes to not daemonize. (Today it is a common practice to equip every daemon with a don't daemonize switch for this, so it's not a problem.) This way, service management tool will get death notifications in a natural way, via its parent-child relationship with the service process. -- vda -- 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 Tue, Jun 14, 2011 at 01:42:42PM +0200, Denys Vlasenko wrote: (anything they could do in shell scripts, but not they can't). This will feel good, right? You will be such an important guy! I think most lurkers have understood you seem to have some personal issues with Lennart. Please still show some respect or continue in private please. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hi, my name is Heiko Adams, I am a professional Windows (please don't blame me for that :D) Software developer and Fedora user since several years. A filed a review request for flyback (https://bugzilla.redhat.com/show_bug.cgi?id=713122) because it was the only backup software I found which allows restoring the backups without running the software itself. If there are still questions feel free to ask ;-) -- Regards Heiko Adams -- 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 Tue, 14.06.11 07:25, Simo Sorce (s...@redhat.com) wrote: What's the problem of having a specific hostname set up at boot time ? The user might want to change it? Does setting it at boot time prevent you from changing it later ? No, systemd will initialize it at boot and is happy if you change it later. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On 06/14/2011 05:35 PM, Heiko Adams wrote: Hi, my name is Heiko Adams, I am a professional Windows (please don't blame me for that :D) Software developer and Fedora user since several years. A filed a review request for flyback (https://bugzilla.redhat.com/show_bug.cgi?id=713122) because it was the only backup software I found which allows restoring the backups without running the software itself. If there are still questions feel free to ask ;-) Welcome. I have set your review request to block FE_NEEDSPONSOR. Follow http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
2011/6/14 Ralf Corsepius rc040...@freenet.de: Well, I would agree to tolerating /usr/lib/package/ (Which btw is the current defacto rule in Fedora practice) but would disagree otherwise, because - /usr/share (aka datadir) is reserved for arch-independent data, i.e. should not contain executables and programs. - /usr/lib (according to the GNU coding standards) should not contain programs. - $(libdir)/package/ basically is a package's private play-ground and therefore may also contain programs and scripts. ok. sigh/ some people seem to need written rules for everything, for what generations of people before them took for granted ;) Ralf We should at least document exceptions to best practices so we can confine them in a small corner. :) Dark corners are basically fractal — no matter how much you illuminate, there's always a smaller but darker one. - Brian Kernighan (one third of the holy *nixy trinity) H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/14/2011 06:37 AM, Lucas wrote: On 06/14/2011 02:10 PM, Frank Murphy wrote: On 14/06/11 11:02, Lucas wrote: snip The only possible way to boot is to add selinux=0. Especially for Daniel J Walsh, the addition of enforcing=0 doesn't make any difference - boot stops. Thanks. Last time I had similar problem, ended up: rpm -e --nodeps selinux-policy selinux-policy-targeted yum install selinux-policy selinux-policy-targeted touch /.autorelabel; reboot and then all was ok. ymmv. In my case relabeling did not help at all. Lucas if you run yum reinstall selinux-policy-targeted Do you see any errors? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk33Vj4ACgkQrlYvE4MpobOYeACg51MLMsEAv7zHa5eA9huIfy5j W9UAniSBc++XHIDiGK0rVqjo/vXOvseB =XgKn -END 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 :)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/14/2011 04:00 AM, Lennart Poettering wrote: On Mon, 13.06.11 18:18, Denys Vlasenko (dvlas...@redhat.com) wrote: On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote: On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko dvlas...@redhat.com 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. Sloppy attitude like this is the reason just about any daemon (more and more of which pop up like mushrooms in every new release, I must add) eats at least a few megabytes of RAM. It's quite pathetic, really. You can easily tell which software was developed earlier just by looking at its memory usage. Example from my machine: Good old ssh-agent: 404 kbytes. Shiny new dconf-service: 2452 kbytes. Shinier newer polkitd: 2836 kbytes. e-addressbook-factory: 5488 kbytes. Of course. What did you think. *Addressbook*! (Empty one in my case). No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :( ~11MB equals ~8 cents of RAM ... so meh. Are you volunteering to buy more RAM for every Fedora user? ;) As mentioned this is primarily the SELinux policy we load. I wished libselinux would optimize memory usage transparently, but even without any changes in libselinux we should be able to optimize this a bit. Yes, using SELinux makes your boot a bit slower and consumes more resources, there is no news in that, and there's also no news in the fact that we can optimize this a bit when we are aware of it. Lennart I just released an updated version of libselinux that will no longer do the dups check on loading file labeling. Testing with matchpathcon, I see a four time speed up on loading the file context file. Basically from 1 Second down to .25 seconds. The memory problem is just the share number of file context that we are loading, each line of the file_context file is a regex. Currently the file_context file on my Rawhide machine is 4209 lines. If we can determine the only file context that systemd will need, based on directories we can eliminate some of the regexes. For example if we just loaded paths that begin with /var, /tmp, /dev, we would drop the regexs down to 1500. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk33Wb0ACgkQrlYvE4MpobNmgQCgw65ed5f489YvTnB4XZ6fMbxG X+0AnRi2iUSSuqsb/GzIPeXg5lLh8Cr1 =L1oe -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Mon, Jun 13, 2011 at 11:25 PM, drago01 drag...@gmail.com wrote: Well you can't expect him to test every possible scenario (no matter how trivial it is). I never saw an fstab with a trailing slash so I wouldn't have though about testing it either. Same here. I actually spent a good chunk of my _volunteer_ testing time budget pre-release poking at systemd's capabilities for handling auto mounting because I really want to make use of it... and I didn't hit this bug. I guess I'm just conditioned to write my fstab entries a certain way. And if I've been conditioned to write them a certain way, it's not shocking that the mount command has an implicit assumption about the format as well. So in an effort to turn the corner of this and make a constructive discussion. Is directory path handling with regard to trailing slashes something worth adding as an autoQA test target in the future?Not just for mount but for a group of commands? Something worth considering? I'm happy to write the initial test script if this is something that makes sense to try to automate. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Dne 14.6.2011 14:05, Heiko Adams napsal(a): my name is Heiko Adams, I am a professional Windows (please don't blame me for that :D) No blame! We are sorry for you ;) Welcome on board! Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 713111] perl-Date-Manip-6.24 is available
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=713111 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Date-Manip-6.24-1.fc16 Resolution||RAWHIDE Last Closed||2011-06-14 09:18:12 -- 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: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 11:25 +0100, Richard W.M. Jones wrote: I've installed XFCE. It was easy to install, and it works sanely (unlike GNOME 3 / Unity). And you can add some interesting tools around xfce which enhance,imo, its operation. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
Am 14.06.2011 15:15, schrieb Jeff Spaleta: Is directory path handling with regard to trailing slashes something worth adding as an autoQA test target in the future?Not just for mount but for a group of commands? Something worth considering? I'm happy to write the initial test script if this is something that makes sense to try to automate. i think this would be a good idea PHP (my main language) is fighting with traling slash or not troubles over all the years, but there is nothing to stop the boot-process and systemd is a very different level of software signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: conclusion: F15 / systemd / user-experience
On 06/13/2011 11:57 PM, Genes MailLists wrote: Fedora could well benefit from switching to a rolling release model as well (no not rawhide - a controlled rolling release much as the kernel development follows). I ran rolling release distros on my laptops for a while - Gentoo, then Debian Testing. I came to the conclusion about 3 years ago that, personally, a rolling release does not work for me, even though Debian Testing is very reliable. If I have a rolling release, I am regularly looking for what's new, trying it out, and tinkering with my system. This distracts me from getting my actual work done. Having real stable releases allows me to consolidate this exploration and tinkering in a week or two twice a year, and I can always source-install or backport the few applications where I do have a legit need for more recent versions (although 6 months is generally often enough for upgrading them). Now, this is just me and my psychology. But the 6-month release cycle is very good for me, and I think many people likely benefit from consolidating update adjustment into regular intervals. - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Ralf Corsepius wrote: Multilib subdirs are arbitrary directory names. There is no convention of them being named lib*. There is, it's written in the FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL But I don't see anything banning qual=exec there! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Ralf Corsepius wrote: Multilib subdirs are arbitrary directory names. There is no convention of them being named lib*. PS: Actually this: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLTQUALGTALTERNATEFORMATLIBRARI is the relevant reference for /usr/libqual (the other one was for /libqual). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Lennart Poettering wrote: Well, but in which way is arch-dependent non-executable data any different from private binaries? I see no reason why one should live in libdir, and the other in libexecdir. Arch-dependent libraries need to be multilib (both in lib and lib64), for executables, only one copy is needed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Tue, Jun 14, 2011 at 5:32 AM, Reindl Harald h.rei...@thelounge.net wrote: i think this would be a good idea PHP (my main language) is fighting with traling slash or not troubles over all the years, but there is nothing to stop the boot-process and systemd is a very different level of software Let's be clear...the bug was actually in mount...not systemd. And the fix has been committed for the mount binary according the bug ticket against the utils-linux package. So the problem has been solved very quickly after the _correct_ developers were notified via the established bug tracking mechanism. And its a weird bug for mount...not what I would have expected. Simple test outside of systemd for everyone falling along using a ntfs disk I just happened to have. First using an entry like this without a slash /dev/sdb1 /mnt ntfsdefaults0 0 mount /mnt and mount /mnt/ both work and the drive mounts Second using an entry like this with a slash /dev/sdb1 /mnt/ ntfsdefaults0 0 mount /mnt fails to mount with an error and mount /mnt/ succeeds What my very simple test shows is that this is totally inconsistent behavior on the part of mount in handling trailing slashes or the lack thereof. There's no good reason why that 1 failure should be happening especially when clearly the mount binary is internally manipulating trailing slashes in some cases. If it wasn't then I should have gotten a failure in the first case. Reindi, If you want to be passionate and be upset about system breakage, that is absolutely your right to do so. But I caution you that you are not channeling your passion effectively. I hope in the future you budget some time as a volunteer to be involved in the pre-release testing so you can help catch problems prior to release. I also hope you learn to be less aggressive when discussing issues with people with whom you don't have an established working relationship. And please, avoid prejudicing a new component of the software stack when things like this happen. New code typically does a better job at tickling implicit assumptions than experienced sysadmins and testers. In this case, mount is broken, and has been broken for years, and we've all been living with that brokenness and not realizing it because we've conditioned ourselves to interact with mount in a way that avoids the breakage. Please, lay the blame at the feet of the correct piece of software. In this case the mount binary is behaving inconsistently and has undocumented quirks that have gone unfixed for YEARS until this bug was filed and fixed. FIXED...I can't stress that enough...the fix has already been committed and we are just waiting for packages now. All systemd was doing was breaking an _undocumented_ _implicit_ _assumption_ that the mount command was using to map mount cmdline mountpoints to fstab entry mountpoints. Mount was assuming that when an fstab entry had a trailing slash then the mount cmdline mntpoint argument would also have a trailing slash and mount was failing when the trailing slash was missing in the cmdline argument. Is there a good reason for mount to do this? I can't think of one so far noone has defended mount's behavior in this regard. And as far as I know its not a documented behavior of mount. And since its not documented there was no reason that anyone (including the systemd authors) could know that stripping the trailing slash when parsing the fstab entry would cause mount to fail. Doubly so when the slash is missing mount processes cmndline mountpoints with trailing slashes without issue. Undocumented implicit assumptions are _bugs_ that cause all sorts of problem up and down the software stack. Spending days and days and days complaining about the piece of software that runs into such an implicit assumption is not the way to work through the problem. Identifying the software with the implicit assumption and either getting it documented or fixed to behave in a consistent, programmatic, robust manner is _always_ the proper way forward. This will be my last response to you on any of these threads. And while I understand why you are upset, and I respect your right to be upset over this issue, I am extremely disappointed in the choices you have made in expressing your opinions on the matter. I will not reward you further with interaction and attention until such time that its clear that you've learned how to tempter your emotion and can approach discussion over problems with more humility and less aggression. Good day, -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On 06/14/2011 04:02 PM, Kevin Kofler wrote: Ralf Corsepius wrote: Multilib subdirs are arbitrary directory names. There is no convention of them being named lib*. There is, it's written in the FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL This has nothing to do with multilibs. FWIW: On most non-intel/non-linux targets, all multilibs are below /usr/lib and are not prefixed with lib*. Ralf -- 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 Tue, 2011-06-14 at 14:08 +0200, Lennart Poettering wrote: On Tue, 14.06.11 07:25, Simo Sorce (s...@redhat.com) wrote: What's the problem of having a specific hostname set up at boot time ? The user might want to change it? Does setting it at boot time prevent you from changing it later ? No, systemd will initialize it at boot and is happy if you change it later. As I thought, then I see no problem here. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Miroslav Lichvar wrote: I think the console-kit-daemon service can be disabled, but xinit prefixes xsession with ck-xinit-session which seems to start the daemon on demand. It would be nice if xinit could be configured to not use it. ConsoleKit is not optional (at least in Fedora 7 to 15). You won't be able to access your hardware without it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Tue, Jun 14, 2011 at 10:10 AM, Jeff Spaleta wrote: On Tue, Jun 14, 2011 at 5:32 AM, Reindl Harald wrote: i think this would be a good idea PHP (my main language) is fighting with traling slash or not troubles over all the years, but there is nothing to stop the boot-process and systemd is a very different level of software Let's be clear...the bug was actually in mount...not systemd. And the fix has been committed for the mount binary according the bug ticket against the utils-linux package. So the problem has been solved very quickly after the _correct_ developers were notified via the established bug tracking mechanism. And its a weird bug for mount...not what I would have expected. Simple test outside of systemd for everyone falling along using a ntfs disk I just happened to have. First using an entry like this without a slash /dev/sdb1 /mnt ntfs defaults 0 0 mount /mnt and mount /mnt/ both work and the drive mounts Second using an entry like this with a slash /dev/sdb1 /mnt/ ntfs defaults 0 0 mount /mnt fails to mount with an error and mount /mnt/ succeeds What my very simple test shows is that this is totally inconsistent behavior on the part of mount in handling trailing slashes or the lack thereof. There's no good reason why that 1 failure should be happening especially when clearly the mount binary is internally manipulating trailing slashes in some cases. If it wasn't then I should have gotten a failure in the first case. Reindi, If you want to be passionate and be upset about system breakage, that is absolutely your right to do so. But I caution you that you are not channeling your passion effectively. I hope in the future you budget some time as a volunteer to be involved in the pre-release testing so you can help catch problems prior to release. I also hope you learn to be less aggressive when discussing issues with people with whom you don't have an established working relationship. And please, avoid prejudicing a new component of the software stack when things like this happen. New code typically does a better job at tickling implicit assumptions than experienced sysadmins and testers. In this case, mount is broken, and has been broken for years, and we've all been living with that brokenness and not realizing it because we've conditioned ourselves to interact with mount in a way that avoids the breakage. Please, lay the blame at the feet of the correct piece of software. In this case the mount binary is behaving inconsistently and has undocumented quirks that have gone unfixed for YEARS until this bug was filed and fixed. FIXED...I can't stress that enough...the fix has already been committed and we are just waiting for packages now. All systemd was doing was breaking an _undocumented_ _implicit_ _assumption_ that the mount command was using to map mount cmdline mountpoints to fstab entry mountpoints. Mount was assuming that when an fstab entry had a trailing slash then the mount cmdline mntpoint argument would also have a trailing slash and mount was failing when the trailing slash was missing in the cmdline argument. Is there a good reason for mount to do this? I can't think of one so far noone has defended mount's behavior in this regard. And as far as I know its not a documented behavior of mount. And since its not documented there was no reason that anyone (including the systemd authors) could know that stripping the trailing slash when parsing the fstab entry would cause mount to fail. Doubly so when the slash is missing mount processes cmndline mountpoints with trailing slashes without issue. I understand the inconsistency and it is indeed a bug in mount. Nevertheless you are missing the point. If X worked before (X=mounting at boot with fstab containing trailing slashes), and stops working now because of the change Y I made, I am responsible for fixing X or Y. The question of 'which one contains the bug' is irrelevant for the user. Some folks think that this is a corner case and it is easy to miss. I think that this is a fundamental mistake and this should be one of the first things a programmer should learn. It pretty much compares a physicist forgetting F=ma. Well, we all do mistakes. Unfortunately, it caused problems for at least a couple people. Hopefully the programmer learned his lesson. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
On 06/14/2011 04:38 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/14/2011 06:37 AM, Lucas wrote: On 06/14/2011 02:10 PM, Frank Murphy wrote: On 14/06/11 11:02, Lucas wrote: snip The only possible way to boot is to add selinux=0. Especially for Daniel J Walsh, the addition of enforcing=0 doesn't make any difference - boot stops. Thanks. Last time I had similar problem, ended up: rpm -e --nodeps selinux-policy selinux-policy-targeted yum install selinux-policy selinux-policy-targeted touch /.autorelabel; reboot and then all was ok. ymmv. In my case relabeling did not help at all. Lucas if you run yum reinstall selinux-policy-targeted Do you see any errors? Just checked it. Yum reinstalled selinux-policy-targeted, then relabeling, then reboot and process stops on: Starting Remount Root FS. And nothing more, no errors, systemd hung. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
On Tue, 14.06.11 18:48, Lucas (macach...@gmail.com) wrote: Do you see any errors? Just checked it. Yum reinstalled selinux-policy-targeted, then relabeling, then reboot and process stops on: Starting Remount Root FS. And nothing more, no errors, systemd hung. Boot with systemd.log_level=debug systemd.log_target=kmsg rd_NO_PLYMOUTH plymouth.enable=0 on the kernel cmdline, and paste the last output generated output on the console somewhere, possibly take a photo of it, and upload it somewhere. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
On Tue, Jun 14, 2011 at 6:32 AM, Orcan Ogetbil oget.fed...@gmail.com wrote: I understand the inconsistency and it is indeed a bug in mount. Nevertheless you are missing the point. If X worked before (X=mounting at boot with fstab containing trailing slashes), and stops working now because of the change Y I made, I can't remember seeing ever seeing an fstab that uses trailing slashes in an operational system that I've had access to. We don't auto-generate trailing slash mount points entries in fstab. I didn't even _think_ to test it when I was doing my due diligence for systemd testing during pre-release. And since I know I'm smarter than everyone involved with systemd development put together, it would be unfair of me to expect them to have caught this So why have I never seen a trailing slash on an operational fstab mount point on a linux system? Why don't we generate trailing slash mountpoints automatically in our default fstab config on install? Most likely, because experienced sysadmins over the years have probably conditioned themselves to avoid using trailing slash entries because of mount's existing cmdline quirk and everyone's been too busy/lazy to file the bug to get mount fixed. Until you run into it on the cmdline yourself, its not noticable. And even then its easier to just fix your custom mountpoints and remove the slash. I am responsible for fixing X or Y. Fixed.The utils-linux developers have fixed it very quickly once someone actually filed a bug. The question of 'which one contains the bug' is irrelevant for the user. Sure...I'm not saying otherwise. But this isn't a user list. This is a devel list and we are having a discussion about development. From a user perspective it just needs to get fixed...and it is going to get fixed with an updated utils-linux as soon as possible. From a strict user perspective problem solved. Some folks think that this is a corner case and it is easy to miss. I didn't think to test it. Did you test it? There is no evidence what-so-ever that anyone actually tested this prior to release. And as far as I know the person who ran into this is the only person on the planet who writes trailing slash fstab entries. And since we..in Fedora...don't populate fstab entries by default in the install or live images with trailing slashes there's no _expectation_ that this will be tested as part of QA testing. I'm going to re-iterate that. QA has finite resources and a narrowly defined testing mandate. Syntax quirks of this nature which are not used in the install targets will not be found prior to release without the help of people out in the userbase who are willing to volunteer and test their real world setups which diverge from the default configs. If trailing slashes were so common as to not be thought of as a corner-case then it is reasonable to assume someone would have hit this prior to release and shouted about it on one of the lists. Didn't happen. I think that this is a fundamental mistake and this should be one of the first things a programmer should learn. It pretty much compares a physicist forgetting F=ma. Well, we all do mistakes. Speaking as a PhD physicist who develops and maintains software for experimental research that an international collaboration of PhD physicists and students blindly rely on in order to do science without being expected to understanding how the actual hardware or software works in detail... I think you are very wrong. Simply put, F=ma is well documented. Mount's slash handling behavior is undocumented. If its undocumented behavior there is no expectation that it can be tested or verified. Unfortunately, it caused problems for at least a couple people. Hopefully the programmer learned his lesson. Sure a couple of people, who did not invest in the pre-release testing process. I hope those couple of people learned their lesson. -jef -- 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/14/2011 06:36 AM, Denys Vlasenko wrote: You go quite farther than that. We can now boot a system shell-free. *Shell-free*. You are not saying driving boot process by shell scripts is slow because ... ... ... (an argument I would agree with), you are aiming at *eliminating* shell scripts from boot process. I think the key word here is 'can': Lennart is saying that shell is slow and unreliable and systemd allows you to engineer a streamlined boot process that brings all the necessary parts of the system up without the shell. He's not eliminating the possibility of using shell for any additional stuff, if that's what you want---just like you can get it to run a telnetd service, you should be able to run '/bin/sh myscript' service. Slide 14: systemd is an Init System systemd is a Platform I am saying that this is not how things are supposed to be done in Unix. I am saying that you are trying to incorporate as much stuff as possible into systemd, and I think it's wrong. [...] I would also add monolithic and inflexible. Sorry. You argue that it should be possible to tailor systemd to bring up a different system than Lennart imagined. It seems to me that it's reasonable that you need a different systemd, then. There are several ways of approaching this, from the most crude to most elegant: - edit the part of systemd where Lennart starts the services and compile your own version - reconfigure via compile-time conditionals - reconfigure at run-time via loadable modules, like the kernel I think that currently systemd is not configurable in the second and third sense. I agree with you that it be more in the Unix way for it to be configurable. I wonder if it's worth the effort to make it run-time configurable, even if it could use some existing run-time modular infrastructure, e.g. from the kernel. -- 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 Tue, Jun 14, 2011 at 04:36:25PM +0200, Kevin Kofler wrote: Miroslav Lichvar wrote: I think the console-kit-daemon service can be disabled, but xinit prefixes xsession with ck-xinit-session which seems to start the daemon on demand. It would be nice if xinit could be configured to not use it. ConsoleKit is not optional (at least in Fedora 7 to 15). You won't be able to access your hardware without it. You can still manage permissions of the devices by other means, which may fit better your use cases. I have edited the xinitrc-common script, but it's not marked as config, so the change is lost after every xorg-x11-xinit update. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Am 14.06.2011 16:36, schrieb Kevin Kofler: Miroslav Lichvar wrote: I think the console-kit-daemon service can be disabled, but xinit prefixes xsession with ck-xinit-session which seems to start the daemon on demand. It would be nice if xinit could be configured to not use it. ConsoleKit is not optional (at least in Fedora 7 to 15). You won't be able to access your hardware without it so tell me why our main server runs without even for usb-devices? fedora 9 - 14 /etc/rc.local # nobody needs killall console-kit-daemon 2 /dev/null /dev/null [root@arrakis:~]$ ps aux | grep -i console root 13685 0.0 0.0 105440 864 pts/1S+ 17:36 0:00 grep --color -i console signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary
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=712886 --- Comment #2 from prayt...@gmail.com 2011-06-14 11:36:09 EDT --- [aprayther@apray-chs-e6420 ~]$ asciio Using setup directory:'/usr/share/perl5/vendor_perl/App/Asciio/setup/' no handler for input '000 + KEY_Control_L'. no handler for input 'C00 + KEY_Alt_L'. And while i was quite confident that i did try .txt as an extension, alas i must not have because it works great when i do. if you could help me out with the key control, that would be cool. -- 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
[Bug 713001] EPEL override bug
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=713001 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||WORKSFORME Last Closed||2011-06-14 11:46:54 -- 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
OpenBUGS program has a pre-compiled )S library from MS Windows. Any possibility to package it?
I decided to try to help the cause of Bayesian statistics and the open source effort of the OpenBUGS group (http://www.openbugs.info/w/) by making some packages. In case you are not a statistically-inclined person, it is worth knowing that Bayesian Updating with Gibbs Sampling (BUGS) has caused something of a methodological landslide since the early 1990s, helping scholars to model processes that were thought to be too difficult. In Linux, we do not have access to the OpenBUGS GUI, which I've built deb and rpm packages for RedHat, Fedora and Ubuntu. They are available in my webspace and in the project. I wish these could be in the official linux repositories, but I've not tried to put these into an official repository because there are 2 problems that seem prohibitive. First, the (now open) code for OpenBugs is written in Object Pascal and it requires a compiler framework called Black Box which is, as far as I can understand, available only for MS Windows. The OpenBUGS team compiles that library, and then for linux we use some accessor scripts to send jobs to it. This, of course, goes against the packaging policy that pre-compiled libraries are prohibited. I was wondering if there could be an exception here, since the code is actually available and open. This is more reasonable than re-packaging the closed Nvidia drivers, for example. Second, there is a little packaging problem for 64 bit systems. The library that is provided is only 32 bit, and to build it for a 64 bit system, there is a somewhat confusing situation. The library itself gets put into /usr/lib, which is supposed to be for 64 bit libraries. And to make the whole thing package up in a workable way, the arch ends up saying the packge is x86_64, even though it is only 32 bit. To run OpenBUGS on a 64 bit system, one h as to install the 32bit libc packages. I've built the RPM on a 32bit system, it comes out with the proper x86 target in the file name,but that package will not instlal on the 64 bit systems. Should it? (As I said, I can build the package on the 64 bit system, and it comes out with a 64 bit file name, but it is really 32 bits.). Oh, bother, this is confusing to me, I can't imagine your situation. http://pj.freefaculty.org/Fedora/14/i386/kups/packages/ On the other hand, the ones I build on a 64 bit system: Show up with 64bit names even though they are 32 bit programs: http://pj.freefaculty.org/Fedora/14/x86_64/openbugs-3.2.1-1.x86_64.rpm In the current Fedora framework, I can't understand if that is supposed to happen. -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenBUGS program has a pre-compiled )S library from MS Windows. Any possibility to package it?
I decided to try to help the cause of Bayesian statistics and the open source effort of the OpenBUGS group (http://www.openbugs.info/w/) by making some packages. In case you are not a statistically-inclined person, it is worth knowing that Bayesian Updating with Gibbs Sampling (BUGS) has caused something of a methodological landslide since the early 1990s, helping scholars to model processes that were thought to be too difficult. In Linux, we do not have access to the OpenBUGS GUI, which I've built deb and rpm packages for RedHat, Fedora and Ubuntu. They are available in my webspace and in the project. I wish these could be in the official linux repositories, but I've not tried to put these into an official repository because there are 2 problems that seem prohibitive. First, the (now open) code for OpenBugs is written in Object Pascal and it requires a compiler framework called Black Box which is, as far as I can understand, available only for MS Windows. The OpenBUGS team compiles that library, and then for linux we use some accessor scripts to send jobs to it. This, of course, goes against the packaging policy that pre-compiled libraries are prohibited. I was wondering if there could be an exception here, since the code is actually available and open. This is more reasonable than re-packaging the closed Nvidia drivers, for example. f it's actually open, build from source. If it won't build from source due to a missing dependency, include that in Fedora, built from source. If that's not possible because something it needs isn't open, I don't see how this can be allowed. -J Second, there is a little packaging problem for 64 bit systems. The library that is provided is only 32 bit, and to build it for a 64 bit system, there is a somewhat confusing situation. The library itself gets put into /usr/lib, which is supposed to be for 64 bit libraries. And to make the whole thing package up in a workable way, the arch ends up saying the packge is x86_64, even though it is only 32 bit. To run OpenBUGS on a 64 bit system, one h as to install the 32bit libc packages. I've built the RPM on a 32bit system, it comes out with the proper x86 target in the file name,but that package will not instlal on the 64 bit systems. Should it? (As I said, I can build the package on the 64 bit system, and it comes out with a 64 bit file name, but it is really 32 bits.). Oh, bother, this is confusing to me, I can't imagine your situation. http://pj.freefaculty.org/Fedora/14/i386/kups/packages/ On the other hand, the ones I build on a 64 bit system: Show up with 64bit names even though they are 32 bit programs: http://pj.freefaculty.org/Fedora/14/x86_64/openbugs-3.2.1-1.x86_64.rpm In the current Fedora framework, I can't understand if that is supposed to happen. -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenBUGS program has a pre-compiled )S library from MS Windows. Any possibility to package it?
On Tue, 2011-06-14 at 10:54 -0500, Jon Ciesla wrote: I decided to try to help the cause of Bayesian statistics and the open source effort of the OpenBUGS group (http://www.openbugs.info/w/) by making some packages. In case you are not a statistically-inclined person, it is worth knowing that Bayesian Updating with Gibbs Sampling (BUGS) has caused something of a methodological landslide since the early 1990s, helping scholars to model processes that were thought to be too difficult. In Linux, we do not have access to the OpenBUGS GUI, which I've built deb and rpm packages for RedHat, Fedora and Ubuntu. They are available in my webspace and in the project. I wish these could be in the official linux repositories, but I've not tried to put these into an official repository because there are 2 problems that seem prohibitive. First, the (now open) code for OpenBugs is written in Object Pascal and it requires a compiler framework called Black Box which is, as far as I can understand, available only for MS Windows. The OpenBUGS team compiles that library, and then for linux we use some accessor scripts to send jobs to it. This, of course, goes against the packaging policy that pre-compiled libraries are prohibited. I was wondering if there could be an exception here, since the code is actually available and open. This is more reasonable than re-packaging the closed Nvidia drivers, for example. f it's actually open, build from source. If it won't build from source due to a missing dependency, include that in Fedora, built from source. If that's not possible because something it needs isn't open, I don't see how this can be allowed. Agreed, it sounds like the necessity of linking against a closed-source library is going to be unacceptable for Fedora proper. However, this is the sort of project that might be acceptable in RPM Fusion. http://www.rpmfusion.org/ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proven Packager help requested with mdadm bug 710646
http://bugzilla.redhat.com/show_bug.cgi?id=710646 mdadm needs a fix to work with the new kernel versioning for 3.0 kernels. Milan Broz has a proposed patch and has asked for commit access to mdadm and no action has been taken by the package owner in over a week since the proposed patch has been posted. Not having this fix breaks booting if you have software raid arrays. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On 06/14/2011 07:31 AM, seth vidal wrote: On Tue, 2011-06-14 at 11:25 +0100, Richard W.M. Jones wrote: I've installed XFCE. It was easy to install, and it works sanely (unlike GNOME 3 / Unity). And you can add some interesting tools around xfce which enhance,imo, its operation. Does it have anything like vino where you can share your current running desktop via VNC? like in Gnome, that's probably my biggest check against it as I have to often vnc to a remote users session to show them something... -- Nathanael d. Noblet t 403.875.4613 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proven Packager help requested with mdadm bug 710646
On Tue, Jun 14, 2011 at 11:06:47AM -0500, Bruno Wolff III wrote: http://bugzilla.redhat.com/show_bug.cgi?id=710646 mdadm needs a fix to work with the new kernel versioning for 3.0 kernels. Milan Broz has a proposed patch and has asked for commit access to mdadm and no action has been taken by the package owner in over a week since the proposed patch has been posted. Not having this fix breaks booting if you have software raid arrays. I've sent another email to dledford asking for this, if I don't hear back by the end of the day, I'll fix it myself. --Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
On Tue, Jun 14, 2011 at 06:48:43PM +0400, Lucas wrote: Just checked it. Yum reinstalled selinux-policy-targeted, then relabeling, then reboot and process stops on: Starting Remount Root FS. And nothing more, no errors, systemd hung. Are you sure it's not doing an fsck? (There's an open bug for that.) -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On 06/14/2011 11:24 AM, Genes MailLists wrote: On 06/14/2011 12:27 PM, Nathanael D. Noblet wrote: On 06/14/2011 07:31 AM, seth vidal wrote: On Tue, 2011-06-14 at 11:25 +0100, Richard W.M. Jones wrote: I've installed XFCE. It was easy to install, and it works sanely (unlike GNOME 3 / Unity). And you can add some interesting tools around xfce which enhance,imo, its operation. Does it have anything like vino where you can share your current running desktop via VNC? like in Gnome, that's probably my biggest check against it as I have to often vnc to a remote users session to show them something... I found vino to be so slow as to be almost unusable - regular vnc works way better .. I'd think you'd only need to put the usual info into the xorg.conf file like always for the server side ... but we really need something like rdp - which hopefully we'll get when wayland settles down .. pixel scraping is not the way to go. Its worked super well for me (though less well with GNOME3's effects etc)... Can you point me to what you mean by the usual info into xorg.conf? to be clear, I don't want to run *my* session over VNC. I want to be able to connect to a remote users *current* session to see and control their computer (while they see what I'm doing)... Does your message still apply? -- Nathanael d. Noblet t 403.875.4613 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Lennart Poettering (mzerq...@0pointer.de) said: I thinkLennart is saying that on a 64 bit system they would have to go to /usr/lib32 No, there is no /usr/lib32. Correct. /usr/lib is 32-bit libraries, /usr/lib64 is 64-bit libraries. (*) My objection to putting 64-bit helper binaries in /usr/lib/app would merely be the problems with configuration that that may imply; such a change may not be transparent to packages. Bill (*) We are ignoring Itanium and Alpha for this conversation, because, well... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :) = vnc
On 06/14/2011 02:32 PM, Nathanael D. Noblet wrote: On 06/14/2011 11:24 AM, Genes MailLists wrote: Its worked super well for me (though less well with GNOME3's effects etc)... Can you point me to what you mean by the usual info into xorg.conf? to be clear, I don't want to run *my* session over VNC. I want to be able to connect to a remote users *current* session to see and control their computer (while they see what I'm doing)... Does your message still apply? Yes it does - you'll need the vnc server package on the end you want to view/control ... # # Minimal xorg.conf for vnc on root display # Section Screen Identifier Screen0 Option passwordfile /usr/local/etc/vnc/password EndSection Section Module Load vnc EndSection Password file is created using vncpassword if I remember correctly. I assume its either local intranet - or you've ssh tunneled port 5900 to be visible on your client machine where you're running vncviewer if your doing this over the internet. regards gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
Le mardi 14 juin 2011 à 22:06 +0400, Lucas a écrit : May be I know what is going on. May be I did something. FYI I have the same problem on my box. Was waiting for fixed 3.0 kernel packages to report a bug. I suspect some kernel/systemd mismatch -- Nicolas Mailhot -- 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 (dvlas...@redhat.com) said: In this case you are not better/worse than before, once the network will come up you'll add a script to change the hostname. Setting it earlier in systemd makes no difference. You continue to avoid answering my question: WHY systemd, a service management tool, bothers with setting hostname? It's not its task! It's part of the task of booting the system. For example, rc.sysinit, in order: 1) mount assorted psuedo-filesystems 2) print a welcome message 3) start udev a.) set clock b.) initialize console settings c.) bring up loopback 4) load ancient legacy module scripts 5) run sysctl 6) set hostname ... whole bunch of other stuff after this elided ... None of these were user-modifiable actions; attempting to change any of these is a void-your-warranty-you-get-all-pieces action. So, in migrating to systemd, we have an opportunity to examine each of these actions that's done at boot, and decide the most appopriate place for it. For the above items, 1, 2, 3a, 3c, and 6 are done in systemd itself. 3, 3b, 4, and 5 are done as standard systemd units. If you're seriously arguing that we should have instead made all these things configurable, I'm not really interested - they weren't before, and making them configurable isn't really useful for making a standardized OS platform. If you want to discuss which is done in which place during startup, we can do that, but at that point we're arguing over details which aren't all that relevant. Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. It's a needless pejorative, yes. But it doesn't change the fact that shell is highly overused in our prior boot process. ~1000 lines of initscripts + functions to cover what is essentially 'exec atd' is overkill, and isn't really needed. Slide 79: Substantial coverage of basic OS boot-up tasks, including fsck, mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots, cryptsetup, ... That's what I refer to by taking over the world. Yes, it's obviously taking over the world by: - changing where fsck is called from point A to point B - changing where mount is called from point A to point B - loading policy from init, *just as it was with SysVinit* - adding features to support initrd-less boots (which we didn't have before) - handling shutdown (WTF is your init system supposed to do if not this?) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
