Re: F21 System Wide Change: Wayland
On Tue, Apr 29, 2014 at 02:04:56PM +0200, Jaroslav Reznik wrote: This change is targeted at F21. For F20, we aim for having an experimental GNOME shell Wayland compositor available, without necessarily having all the surrounding desktop infrastructure ported. To avoid destabilizing the X compositor, mutter will ship two separate libraries, and gnome-shell will ship two binaries that will link against them. Concretely, we plan to have a separate mutter-wayland package. Looks like this hasn't been updated since F20. Should probably give a status report of how these F20 changes went off. Last I looked, gnome-wayland was there, but not terribly functional. --CJD pgpJvzcuap0I0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deprecate setjmp/longjmp? [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
On Mon, Apr 28, 2014 at 08:57:27AM -0400, Adam Jackson wrote: On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote: On 24/04/14 15:13, Lennart Poettering wrote: We probably should make setjmp()-freeness a requirement for all code included in Fedora. Would it be worth the effort, and how feasible is it anyway? I don't think it'd be worth the effort, and I think the burden of computing feasibility should rest with those who think it _is_ worth the effort. Well, we could consider banning it from new packages and just let attrition take care of the rest. --CJD pgpVidXejQmkv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On Thu, Apr 24, 2014 at 05:55:29PM +0200, Miloslav Trmač wrote: Hello, 2014-04-24 16:38 GMT+02:00 Lukáš Nykrýn lnyk...@redhat.com: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Are you sure? If you take an existing RPM that ships a sysv file, that's alone an indication that it probably hasn't been significantly reworked, so noone is likely to have added an explicit requires: on this part. For extra credit, make sure that this works correctly with LSB-compliant RPMs that do nothing not required by LSB. I may be wrong but I believe we could update our dependency-detection scripts to note when a package ships an init script and add the requirement automatically. As long as there's a mass rebuild between now and shipping that should take care of everyone. --CJD pgp0GQ_7Ia4Dx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 07:14:39PM +0100, Miloslav Trmač wrote: 1) Changing the mechanism would not resolve any of the questions discussed here. Systemd is a bit cleaner to admin, and turning the service off wouldn't make an oddity show up in rpm -qaV like moving a cron job aside would. 2) http://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html: * AGREED: Feature is approved. No packages should convert to using this feature yet. (7, 0, 0) (nirik, 20:26:31) Not sure if that applies in this case. It'd be dnf using a systemd feature, not systemd using a dnf feature. --CJD pgpVo2MZBpUXU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 07:44:58PM +0100, Tomasz Torcz wrote: There was a decision of not _migrating_ cronjobs to timer units yet. But I think we should ban _introducing_ new cronjobs. Instead, new periodic jobs should be introduced as timer units. That's assuming all cron jobs should become systemd timer units (Lennart himself has stated systemd timer units don't fully replace cron). --CJD pgpbtQ5fOwcrS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote: Well I believe Ubunto has been using this feature for years and maybe we should consider turning it on via systemd or a unit file. The breakage of AFD is not a legitimate reason for Fedora to turn it off. Why not add an LSM call, security_follow_restricted_link()? Then you could ship this protection with SELinux policy, and even turn it off per-label if specific applications need the old behavior. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
binKWT8x6c21S.bin Description: application/pgp-encrypted msg.asc Description: Binary data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Ok, apparently Mutt is a bit stupider than I thought. Let's try this again. On Thu, Mar 14, 2013 at 02:20:04PM -0400, Daniel J Walsh wrote: We already do, Good. but this protection does protect unconfined_t and for those who Maybe we're ready to except a confined user by default. Something very, very loose. would dare to disable SELinux. To hell with 'em. :) --CJD pgp0irRYb1paA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, Mar 12, 2013 at 11:52:40PM +0100, Nicolas Mailhot wrote: rescue system. (that's why safety jackets use flashy unfashionable colors) So we should make the boot loader use flashy unfashionable colors because it makes it more reliable? Ok that's silly, but it's also silly for safety jackets. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, Mar 12, 2013 at 08:01:54AM -0400, Nico Kadel-Garcia wrote: And the main lesson her is don't clutter the user interface with useless graphical eye candy. It makes the boot process require unnecessary system resources. The new Fedora installation setup is currently a *nightmare*. It works very poorly through low bandwidth remote connections, the graphics are poorly labeled and very confusing, and the spoke and hub model is a bit of big vision coneptual weirdness that is actively preventing people from wanting to touch Fedora. It's an *installer*, keeping it as lightweight and simple as possible with minimal graphics means that it will display better on small virtual system or remote KVM displays. But this has been discarded in favor or an overly bulky and complex system that is showing off what are quite fragile graphical features rather than simply doing the *job*. Citation needed. Anaconda has been graphical for ages, and has probably gotten lighter after the rewrite if anything. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Sat, Feb 09, 2013 at 11:34:34AM +, Ian Malone wrote: Gnome 2 slowly returned to the old behaviour in many ways. Gnome 3 is starting to do this. As someone who, I presume, does not like Gnome 3, and as someone who, I will wildly guess, shares the notion that GNOME devs are doing whatever they want and not listening to your use cases... ...are you certain... ...absolutely certain... ...that you'd like to be on record setting the precedent that GNOME 3 is admitting failure by compromising to your standards? --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Yum Groups as Objects
On Mon, Jan 28, 2013 at 10:26:01AM -0600, Bruno Wolff III wrote: On Mon, Jan 28, 2013 at 16:52:18 +0100, Kamil Dudka kdu...@redhat.com wrote: I have been always wondering why yum needs a special set of commands to manipulate groups of packages. What would be the downside of using just packages that install no files (a.k.a. meta-packages) instead of groups? Removing meta packages doesn't remove the dependencies. So you more or less have the same problem. It is easy to install groups, but tricky to remove them. I thought we'd been shipping remove-with-leaves by default for awhile now. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Mon, Jan 28, 2013 at 07:49:59PM +0100, Maros Zatko wrote: I've used gnome 2.x, when 3.x came out I had no other option than to (finally) switch to tiling since my beloved DE was gone and not going back. If you're the sort of person that wants a tiling window manager, then I think it's fair to ask you to install it yourself, thereby freeing up the default to serve a different audience. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Where are we going? (Not a rant)
On Mon, Dec 10, 2012 at 04:20:34PM -0500, Przemek Klosowski wrote: are not worth paying support for. I suggested to RedHat that they provide a graceful switch-over to CENTOS in such case: it's possible manually anyway, so it would be a nice gesture to do it automatically for customers who let the support expire. As is in our case, this doesn't even decrease the amount of support we purchase---it just gives us the flexibility to deploy new systems all the time. If CentOS were to take up that effort themselves (largely feasible for them to do technically) I'm sure Red Hat sales would wink in that direction in cases when they felt it was in the interest of Red Hat. Enough of that winking and eventually engineers at Red Hat's end would probably have an incentive to keep it working. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, May 24, 2012 at 09:28:16AM +0200, Alexander Larsson wrote: I'm at a loss to how to proceed with the MiniDebugInfo work. I have patches to rpmbuild that creates the compressed minidebuginfo putting them in the main binaries, and I have patches to gdb that reads the compressed debuginfo on demand. However, the whole thing is useless unless we agree that we want to enable this by default. It seems some people like the idea, whereas others disagree that its worth the increased binary size. It doesn't look like either side is gonna be able to convince the other side, so how do we get to a decision here? Just go do it. See who actually shows up to stop you. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, May 24, 2012 at 07:27:03PM +0200, Jan Kratochvil wrote: On Thu, 24 May 2012 19:20:15 +0200, Casey Dahlin wrote: Just go do it. See who actually shows up to stop you. I am sure this is significant enough distro change to require FESCo decision. Still cuts his workload down from convincing an open mailing list to convincing 7 people. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pyvnc2swf and vnc2flv
On Mon, Nov 28, 2011 at 12:18:01PM +0100, Jos Vos wrote: Hi, I was looking for a tool to record X/VNC session in a movie and found pyvnc2swf. But looking at the project's home page, http://www.unixuser.org/~euske/vnc2swf/index.html, I see that the development has been superseded by its successor, vnc2flv, http://www.unixuser.org/~euske/python/vnc2flv/index.html, since 2 years. Maybe Fedora should upgrade to this new version for F17. You should contact the maintainer directly and see if he will package the new app (or at the very least retire the old one so a new maintainer can obsolete it). --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Tue, Oct 04, 2011 at 04:17:08PM -0400, Martin Langhoff wrote: For fedora users, as others have mentioned, perhaps a UI that lets users test a couple of possible dpi values might be useful (for those users so inclined). It does have to cross a good chunk of the stack to work well, and seems like a lot of work to get right; but the xrandr improvements are a start. Windows used to have a gui that would show a ruler on your monitor and say hold a real ruler up to this and slide the slider until its the same size. Given what's been said about how windows handles DPI I can only wonder what it did, but it might be a nice thing to have. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)
Orphan rubygem-rcov Oh, missed that one. I'll definitely take that. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)
On Wed, Jul 20, 2011 at 03:41:28PM -0400, Casey Dahlin wrote: Orphan rubygem-rcov Oh, missed that one. I'll definitely take that. --CJD Never mind. It has been snatched up already. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16 (v3)
On Thu, Jul 14, 2011 at 03:39:13PM -0400, Bill Nottingham wrote: *snip* Orphan userspace-rcu I'll take that one. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
On Wed, Jul 06, 2011 at 02:43:43PM -0400, Casey Dahlin wrote: On Wed, Jul 06, 2011 at 11:23:06AM -0700, Jesse Keating wrote: I no longer have a need/care for these packages, they are up for grabs: contacts inotail I'll take inotail. --CJD Someone pointed out that this functionality is now available in tailf, so I don't think this package is necessary at all. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
On Wed, Jul 06, 2011 at 11:23:06AM -0700, Jesse Keating wrote: I no longer have a need/care for these packages, they are up for grabs: contacts inotail I'll take inotail. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what key between Ctrl Alt (was: GNOME3 and au revoir...)
On Fri, Jun 17, 2011 at 07:05:59AM -0800, Jeff Spaleta wrote: On Fri, Jun 17, 2011 at 6:42 AM, Jared K. Smith jsm...@fedoraproject.org wrote: It can be named... it's called the Super key. Well, at least mine is super, as it has a Fedora logo on it :-) That's a bad place for the Fedora logo... just like its a bad place for the Windows logo. What is needed is project-neutral label for that key so that GNOME and other interfaces can start referencing it in the documentation with having to work about vendor branding. If only the superman logo were public domain the superman symbol would be perfect. The key was actually around for a bit before there was a windows logo on it. It had a small diamond on it. --CJD -- 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 Fri, Jun 17, 2011 at 01:05:08PM -0400, Bernd Stramm wrote: I think it fails on #1: Makes it easy for users to focus on their current task and reduces distraction and interruption First, this point assumes that there is *one* current task. That is not how I work. I have one main task, and I keep an eye on some other things, like whose is in some chats, what comes up in twitter flows, etc. One could rephrase your complaint as I don't want to focus on my current task. So GNOME shell just isn't for you. --CJD -- 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 Fri, Jun 17, 2011 at 02:12:54PM -0400, Bernd Stramm wrote: One could do that, but that would be an idiotic thing to do. So one doesn't. Its what you said. You explicitly want to divide your attention between multiple tasks. GNOME shell is for people who don't want to do that. --CJD -- 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 Fri, Jun 17, 2011 at 02:32:12PM -0400, Bernd Stramm wrote: So Gnome Shell is not for a good many of the people who had been using Gnome before that. YES! I don't know why more people don't realize this: GNOME 2 was a mediocre interface for a lot of people. It COULD NOT be a good interface for the same number of people, and there is NOTHING wrong with them pruning their userbase to a subset which they can adequately serve. It is not good to counter a technical point with a personal attack, which is what you did. No I didn't. Different workloads require different ways of working. In my case, there is not just one task that requires 100% of my attention. There is one big, long term task that can tolerate short interruptions, and several smaller ones. This is a perfectly normal situation. That doesn't mean GNOME shell did not meet the goal you quoted. It means that goal contradicts your own goals. The goal was let the user focus on the current task. You want your focus less singularly distributed. Serving you brings them further from, not closer to, the goal as stated. --CJD -- 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, Jun 13, 2011 at 10:33:19AM +0200, Lennart Poettering wrote: Uh, and even much healthier than Upstart, which you seem to be a big fan of. Ohloh lists 3 patch authors. (But I figure that is out-of-date, it cannot be that low) I'm guessing its just ohloh having as much trouble operating launchpad as humans do. I know I have quite a large branch somewhere in there, but it usually takes me a good while to find evidence of it too. In general, though, someone else would have to understand what Upstart is supposed to be in order to contribute code. Since that is explicitly and by choice only documented in Scott's head, its kinda hard to do. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Reviews Needed
On Tue, Jun 07, 2011 at 03:12:19PM +0200, Kevin Kofler wrote: Tom Callaway wrote: pyrit: https://bugzilla.redhat.com/show_bug.cgi?id=691894 SARCASMOh great, because a tool to parasite wireless connections which the owners went out of the way to secure with the best available protocol is EXACTLY what we need…/SARCASM Use of this tool is probably against the law in most of the world. (Some countries even ban using unencrypted wireless networks without explicit permission.) And I fail to see any legitimate use for this tool. White hats and black hats require the exact same tools to do their job. Penetration testing is a huge part of what security researchers do. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UID_MIN GID_MIN changed
On Thu, May 26, 2011 at 08:52:34AM -0400, Simo Sorce wrote: On Thu, 2011-05-26 at 07:39 +0200, Alexander Boström wrote: ons 2011-05-25 klockan 12:37 -0500 skrev Dennis Gilmore: another issue that i thought of was existing ldap/nis systems that allocate regular users in the 500-1000 range when installing or upgrading if they use policies that probit system accounts from logging in will have users unable to login. As someone who admins such an LDAP setup I think the sooner the change is made the better. (If it had been changed long ago then it wouldn't have been a problem now.) Personally I think UIDs and their relation to user accounts should be treated as host-local. I also want a pony. It would be nice, but then there is NFS ... NFSv4 has UID mapping, and we were all supposed to start using it yesterday. My pony will have sparkles and rainbows. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is Rawhide supposed to be useful?
On Wed, May 11, 2011 at 04:23:00PM +0200, Michael Schwendt wrote: That conclusion is based on the assumption that somebody pushes completely broken stuff into Rawhide _knowingly_. Or that they push unproven code into rawhide carelessly. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is Rawhide supposed to be useful?
On Tue, May 10, 2011 at 01:07:22PM -0400, Adam Jackson wrote: X being broken in rawhide was in who knows how many peoples' ways, and even though it's provenpackager+ and even though all it would have taken was a mass driver rebuild, nobody even tried. Where _are_ you people? Why do I bother to open the ACLs on my packages if nobody's going to take advantage of it? Its a hard problem in human psychology (see diffusion of responsibility/the bystander effect). It'd be nice if there were some place we could list all of these tasks and allow people to grab them, regardless of what they maintain (sounds a bit like bugzilla really) to at least deter the sense of what if I do all this work and someone else fixes it before I commit? --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wireless-tools/net-tools are DEPRECATED
On Wed, May 04, 2011 at 02:26:10PM -0500, Dan Williams wrote: On Fri, 2011-04-29 at 19:21 -0400, Chuck Anderson wrote: On Fri, Apr 29, 2011 at 12:30:02PM -0500, Dan Williams wrote: Looking at the code, the 4-second delay is only used when the device is actually connected to something. State 3 == DISCONNECTED, state 2 == UNAVAILABLE, so it's performing as expected here. Were there actually an IP address assigned to 'nf' then the 4-second delay would be used. Given that nothing really happens to the device when it's DISCONNECTED anyway, the logs you see are pretty much a NOP for NM. I would really /love/ it if NM could log the human readable state names and reason codes, rather than the cryptic numbers. Done and rolled into the 0.8.999 (0.9-rc2) release: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c4b922ed2197657dc4091fb6782e9cb8f9644af5 https://admin.fedoraproject.org/updates/NetworkManager-0.8.999-1.fc15,NetworkManager-openswan-0.8.999-1.fc15,NetworkManager-openconnect-0.8.999-1.fc15,NetworkManager-pptp-0.8.999-1.fc15,NetworkManager-openvpn-0.8.999-1.fc15,NetworkManager-vpnc-0.8.999-1.fc15 Reason codes too. Just for you Chuck :) (that's a lie, it's been requested before but I figured since Chuck asked I might as well just do it) By me no less :P thanks for writing it. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote: With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work. Nathaniel You lose it for a couple of strange usecases though: 1) Moving from a card that is up to date in what it supports to an older card that isn't (rare). 2) Moving from one crappy ancient card to another (plausible, but still rare). The vesa driver should mean some workable video support in either case, and from there, if we were really, truly concerned, we could detect the need for the driver and prompt to install it. That's starting to sound like the bad old days of kudzu though, and I'd be surprised if anyone really felt this was worth that effort. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, Apr 12, 2011 at 02:01:26PM -0400, Nathaniel McCallum wrote: On Tue, 2011-04-12 at 13:57 -0400, Casey Dahlin wrote: On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote: With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work. Nathaniel You lose it for a couple of strange usecases though: 1) Moving from a card that is up to date in what it supports to an older card that isn't (rare). 2) Moving from one crappy ancient card to another (plausible, but still rare). The vesa driver should mean some workable video support in either case, and from there, if we were really, truly concerned, we could detect the need for the driver and prompt to install it. That's starting to sound like the bad old days of kudzu though, and I'd be surprised if anyone really felt this was worth that effort. I think losing it in those cases is probably acceptable. My thought is that the disk space for drivers is minimal, lets just support everything (or at least the current stuff) in a single install. My concern isn't moving to and/or between rare old cards. My concern is moving from nouveau to intel or radeon... The big drivers should definitely be installed on every system, regardless of its hardware. I believe (and maybe I've read this thread to quickly) that that will still be the case. Its only the drivers for old cards with smaller feature sets that are being moved at alll. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Beta RC1 Available Now!
On Fri, Apr 08, 2011 at 09:25:31PM +0100, mike cloaked wrote:
On Fri, Apr 8, 2011 at 9:19 PM, Jesse Keating jkeat...@redhat.com wrote:
On 4/8/11 12:14 PM, Christopher Aillon wrote:
Its the way we do it.
F13 is the earliest mention I can find mention of Beta RC on
devel-list. But that doesn't really change the validity of my
statement. It's confusing, and we should change it.
This is fair criticism. I believe I'm the one that started referring to
these composes as release candidates more vocally. We needed a way to
reference the succession of attempted composes for a release point, be
it Alpha, Beta, or GA. Calling them release candidates made sense to
me, however I can see how they could be confusing.
Would it make more sense to refer to these as Alpha Candidate, Beta
Candidate and Release Candidate ? ac{1,2,3}, bc{1,2}, rc1 ?
It does mean the name will change at each stage, but it should be more
descriptive as to what stage we're in.
How about the sequence:
Fn-Alpha-Pre.1 Fn-Alpha-Pre.2 . Fn-Alpha
Fn-Beta-Pre.1 Fn-Beta-Pre.2 Fn-Beta-Pre.3 Fn-Beta
Fn-RC1 Fn-RC2 Fn-RC3... Fn (=release)
That is certainly a different color bikeshed from the one Jesse
suggested :)
Its probably best that it be decided for certain /if/ we want to change
before we decide what the new naming convention be. Then we get the
inevitable bikeshedding argument out from under the actual issue that's
been raised here.
--CJD
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Thu, Feb 24, 2011 at 03:51:37PM -0500, Genes MailLists wrote: On 02/24/2011 01:32 PM, Matthew Garrett wrote: There are no essential services, which means any proposal that contains the phrase non-essential services is already unimplementable. HID services (keyboard/mouse) might be nice ... :-) :-) Not if you have a headless server. Also I don't think its absolutely necessary to have a service running to use the keyboard. There's no real usecases that want _no_ services running, and there's probably very few within Fedora proper that don't want things like udev (and then they're probably doing so much to the base install anyway that a bit of service reconfiguration is nothing), but technically Matthew is correct. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On Wed, Feb 23, 2011 at 11:54:58AM -0600, Eric Sandeen wrote: On 2/23/11 11:42 AM, Jesse Keating wrote: On 2/23/11 5:00 AM, Josef Bacik wrote: This would be a great thing in general since the default ext* image is shrunk down to be installed which creates a bad fs layout which has performance implications. Can you expand upon this more? The filesystem is shrunk down when the live image is built, but then once it is installed the fs is resized to fill out the physical disk / partition it is being installed to. Shrinking down the filesystem tends to scramble it a bit. All the allocator decisions that were made based on fs size at the time of install go out the window as resize2fs fills in every hole it can find to maximally compress the fs. Is there some sort of sparsifying defrag we could do after copying the image over? The dd-based install is so fast that we could actually afford another pass if we needed it IMHO. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Thu, Dec 23, 2010 at 09:11:46AM -0800, Fernando Lopez-Lezcano wrote: On 12/22/2010 12:56 PM, Casey Dahlin wrote: On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote: This is from Paul Davis, the main architect of Jack (I forwarded him your post): this isn't exactly correct. in /dev/shm on linux we have: (a) unix-domain sockets for non-RT communication with the server Perhaps these could become abstract domain sockets. Could you explain a bit perhaps? I'm not familiar with them... (or maybe you have a url I could surf to?) Basically, you put a \0 in front of the path when you bind the socket. So, for example, bind to \0/jack/socket. Yes, that looks weird, but it works. The socket will not appear anywhere in the filesystem, but can still be opened by using that wonky path from anywhere. When no longer referenced the socket will simply disappear. Here's a link, though it takes awhile to get to the point: http://blog.eduardofleury.com/archives/2007/09/13/ --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote: This is from Paul Davis, the main architect of Jack (I forwarded him your post): this isn't exactly correct. in /dev/shm on linux we have: (a) unix-domain sockets for non-RT communication with the server Perhaps these could become abstract domain sockets. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote: On Wed, Dec 15, 2010 at 07:21:25AM +0100, Lennart Poettering wrote: Jeez. Tha's just FUD. Of course we have discussed this openly with various folks. We haven't discussed this with you, Rich, personally, but well, I'll make a note now tht I'll DoS you now with every single choice we make, to get your blessing. What you don't understand is that you are throwing away the experience and knowledge of thousands of Unix system administrators. Almost of all of them do not even read this mailing list. Rich. I hate this argument. The experience and knowledge claim applies to everything we could possibly change. Change. Is. Going. To. Happen. This is technology. Good technical professionals learn new things quickly. So to all those thousands of Unix system administrators I suggest making a purchase here: http://www.saferacer.com/auto-racing-helmets/?cat=52 --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Thu, Dec 16, 2010 at 08:16:53PM +0100, Miloslav Trmač wrote: Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500: On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote: What you don't understand is that you are throwing away the experience and knowledge of thousands of Unix system administrators. Almost of all of them do not even read this mailing list. Rich. I hate this argument. The experience and knowledge claim applies to everything we could possibly change. Change.\nIs.\nGoing.\nTo.\nHappen. That's a too black-and-white view. Of course there is and will be change - what would we all be doing here if there were nothing to change, after all? The thing that needs to be appreciate is that every change has _costs_ on the user-base. I think the view I was presented with was too black-and-white. Richard began with essentially change is bad. I responded. You've really wholly replaced the argument I was reacting to. Which is a good thing. The conversation should have begun here. I can't quickly find out good numbers on the number of server users of Fedora and Fedora-derived distributions; based on http://www.centos.org/modules/newbb/viewtopic.php?topic_id=18728forum=14 , let's stipulate that there are 1,000,000 installations (which is almost certainly a huge understatement), with 10 servers per administrator on average, so 100,000 Linux system administrators. Better numbers would be welcome. http://fedoraproject.org/wiki/Statistics That's the best we have. Especially minor changes that don't bring any measurable benefit (perhaps making the system cleaner or making programmer's life more convenient) but require time from each user to adapt are better abandoned than implemented. Mirek Measurable != significant. Great programmers and architects have an instinct for something called defect avoidance. You can't measure it, since the unit would be number of bugs/bug-related outages and problems which never happened. Depending on your instincts on what that value might be, cleaner could be the single most important thing to improve in the entire distro. You can guess my own instincts on the subject. This sort of immeasurability is everywhere in computing. Its what causes most major corporate security breaches (well, we haven't had a security breach in awhile, I guess we don't need to spend so much on a security team.) Its what spawned the desperate rationalization all software has bugs, which is an excuse to not have to measure how well you avoid putting bugs in the code. For my part, I believe in trying to write software that can't break, even if I'm not always successful. Part of that effort is ripping off anything that's loose. If its purpose is questionable, or its exposed in a semantically iffy way, it needs to be ripped out. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
pdftk requires tomcat5?
Sizewise this didn't end up being an awful cost for me, but why on earth would this happen? Installing: pdftk x86_64 1.41-27.fc14 fedora 76 k Installing for dependencies: bouncycastlex86_64 1.45-1.fc13fedora 3.3 M bouncycastle-mail x86_64 1.45-1.fc13fedora 517 k bouncycastle-tspx86_64 1.45-1.fc13fedora 105 k itext x86_64 2.1.7-6.fc13 fedora 3.0 M javamailx86_64 1.4.3-2.fc13 fedora 925 k tomcat5-jsp-2.0-api noarch 5.5.27-7.4.fc12fedora 73 k tomcat5-servlet-2.4-api noarch 5.5.27-7.4.fc12fedora 114 k --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pdftk requires tomcat5?
On Mon, Nov 22, 2010 at 03:19:35PM -0500, Orcan Ogetbil wrote: On Mon, Nov 22, 2010 at 3:11 PM, Casey Dahlin wrote: Sizewise this didn't end up being an awful cost for me, but why on earth would this happen? Installing: pdftk x86_64 1.41-27.fc14 fedora 76 k Installing for dependencies: bouncycastle x86_64 1.45-1.fc13 fedora 3.3 M bouncycastle-mail x86_64 1.45-1.fc13 fedora 517 k bouncycastle-tsp x86_64 1.45-1.fc13 fedora 105 k itext x86_64 2.1.7-6.fc13 fedora 3.0 M javamail x86_64 1.4.3-2.fc13 fedora 925 k tomcat5-jsp-2.0-api noarch 5.5.27-7.4.fc12 fedora 73 k tomcat5-servlet-2.4-api noarch 5.5.27-7.4.fc12 fedora 114 k --CJD A little bugzilla search might help https://bugzilla.redhat.com/show_bug.cgi?id=650390 I just typed pdftk in the quick search box on bugzilla and hit enter. Somehow didn't think to check BZ for this sort of problem. Thanks for pointing that out though. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 04:27:48AM +, Matthew Garrett wrote: On Wed, Nov 17, 2010 at 11:26:31PM -0500, Benjamin Kreuter wrote: On Wednesday 17 November 2010 22:59:54 Matthew Garrett wrote: Pretty sure it doesn't point them out. It just breaks them. Using memcpy on overlapping ranges is undefined behavior; a crash is a pretty good way of pointing that out. Other undefined behavior causes a crash (last I checked): Flash isn't crashing. It just sounds like it's trapped in a flooded submarine. /me suddenly realizes that the Flash bug he's been encountering is the one being discussed in this thread. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 06:26:27PM -0500, Matthew Miller wrote: On Mon, Nov 15, 2010 at 11:15:38PM +, Jóhann B. Guðmundsson wrote: Well if you don't consider what Lennart mentioned [1] as a con against usage of lvm by default what pros do you see for having lvm by default for the novice end user? When the novice end user realizes that they made some poor storage decisions initially, they can, with a little learning, fix it without much hassle. I have a system which, for silly reasons, I did not use LVM, and then ended up having change a separately-mounted /usr, and now (in a sort of irony, considering this thread) can't shut down cleanly under systemd. Awesome. I'm not particularly attached to LVM as a specific technology, but we need something with equivalent functionality before we ditch it. It also takes a decision out of the mix when a user buys a new drive. They can just dump it in the volume group rather than having to learn how to place it at a mountpoint and migrate data (the actual commands are no big deal. Learning to weigh the costs and benefits of applying your new 1TB disk to /usr vs /home isn't). Its a usecase that matters to an interesting class of user: the petty power user. They help Aunt Tillie with her computer. They built their own computer. They think of themselves as quite tech-savvy. They are also liable to say things like If linux is so great why can't it even run normal programs? LVM is nice in that it accomodates this generally unpleasent sort of person (who is much improved by education and has the potential to become a great contributor once humbled and made willing to learn) though it does this by offering a temporary crutch. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 10:49:24PM +, Matthew Garrett wrote: On Mon, Nov 15, 2010 at 11:28:33PM +0100, Karel Klic wrote: Dne 15.11.2010 22:31, Matthew Garrett napsal(a): Further, what's the licensing situation here? If I have an application that (at runtime) is a mixture of GPLed and GPL-incompatible code, does sending this coredump to a remote service count as distribution? Interesting point. I do not know. What is the scope of this question? Can GPLed and GPL-incompatible code end up in the same coredump in Fedora installation without 3rd party software installed? It was reasonably likely in X until Synaptics got relicensed. I think we're fairly safe from a stock install point of view. We should probably detect when things we don't ship are linked in and put some measures in place to keep the user from inadvertently breaking copyright law (or worse, putting copyrighted material on our BZ so /we/ end up inadvertently breaking copyright law). --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Passing ownership of mingetty
On Thu, Nov 11, 2010 at 08:53:47PM +0100, Lennart Poettering wrote: On Wed, 10.11.10 21:33, Bernie Innocenti (ber...@codewiz.org) wrote: Hello Petr, I ended up being the owner of mingetty by chance, because I used to maintain it in the OLPC collection and the previous maintainer released the package. Do we really want to keep mingetty around? Your argument is sound, but this is still a bit off topic for this thread. Even if mingetty is retired it still needs a maintainer for another year until we retire F14 (unless we want to take a risk and try to swap it out in the public releases). I assume OLPC would have a similar issue. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nouveau gnome-shell (was: Re: Ubuntu moving towards Wayland)
On Wed, Nov 10, 2010 at 09:03:25AM -0500, Darryl L. Pierce wrote: On Tue, Nov 09, 2010 at 01:22:02PM -0800, Adam Williamson wrote: On Tue, 2010-11-09 at 21:05 +, Camilo Mesias wrote: I'm using the experimental 3d now with gnome shell. After a few days, it seems like it performs OK although it locks up for a few seconds now and then. It seems to recover and I can't see any obvious log messages around the time of the freeze. It does survive suspend/resume, which is great. My impression is that it runs slightly hotter than the nvidia driver but I could be imagining this (I don't have any figures). You're probably not. nouveau basically has no power management at present (it's under heavy development upstream, but I don't think ben's pulled any of it downstream yet). Does it support multiple monitor configurations? IOW, when I go to work I dock and use two external monitors. When I'm home I use either my laptop display or, when I'm in my home office, I attach a video dongle to connect to a widescreen monitor. Right now I use the nVidia config tool to select my monitor config on the fly and change to that. What would I use with the mesa driver? xrandr / system-config-display. I use nouveau with two monitors all the time. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote: And where does that sit in the architecture? Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way. Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 02:28:10PM -0500, Brian Wheeler wrote: On Tue, 2010-11-09 at 14:24 -0500, Casey Dahlin wrote: On Tue, Nov 09, 2010 at 02:14:32PM -0500, Brian Wheeler wrote: On Tue, 2010-11-09 at 14:05 -0500, Casey Dahlin wrote: On Tue, Nov 09, 2010 at 01:44:19PM -0500, Brian Wheeler wrote: And where does that sit in the architecture? Looking over the architecture page (2nd figure) it looks like the only way to get the kind of network transparency that X has under Wayland is to put the network between the Wayland client and Wayland Compositor. Which would mean that the passing of events has to be networkable from the start. If its put on top it ends up being the VNC model of doing things and that sucks in a big way. Basically you'd run an alternate compositor in your ssh session that would read out the buffers, compress them, and send them over the network instead of compositing them into a larger buffer and scanning them out. --CJD That's an interesting solution. If I logged into a remote machine would I have to run a separate compositor for every application or one per remote connection? I suppose the compositor could be started automatically if the wayland libraries looked for an env setting (the same way X looks for DISPLAY). When you did ssh --wayland, the remote ssh session daemon would start that special compositor and inject its address into the environment so things you launched under that session would use it. Then your ssh client would start a proxy wayland client to recieve the compressed buffers and create windows on your local wayland compositor. Best part is, if you composited the buffers beforehand and then sent the result as a giant window, you get VNC functionality, so you only need one protocol for both. I assume there would be a fallback method for older ssh clients? It would involve a bit more effort on the user's part (most of which could be rolled into a script) but you could set up the final scenario using present-day ssh assuming you had the wayland bits on both ends. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, Nov 09, 2010 at 09:03:38PM +, Richard W.M. Jones wrote: On Tue, Nov 09, 2010 at 01:43:06PM -0500, Adam Jackson wrote: - We lose network transparency! Well, sure, the protocol doesn't have that directly. You can still do vnc-like things trivially and with a modest amount of additional wayland protocol (or just inter-client conventions) you can do spice-like things. This is good, not bad, because efficient remoting protocols do not look like X. Now we get to design a good one, and in the meantime vnc-style remoting sure does go a long way towards being good enough. (But, we can't switch yet, because we don't even have vnc-style remoting yet; so we're not switching yet.) Just so we don't lose the point: VNC-style remoting is *not* a suitable alternative. Ajax is using VNC-style remoting to refer to a pixel-scraping remoting mechanism which would not necessarily include a root window and would in most cases function the same way as X forwarding. Seems to be a repeated confusion in this branch of the thread. --CJD Rich. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, Nov 06, 2010 at 10:57:27AM +, Richard W.M. Jones wrote: We want to ditch extremely useful, ground-breaking features because of tearing when scrolling in a browser window? [I do *not* see any of I actually read it as we want to ditch features that were groundbreaking in 1975 since the limits on technology from back then no longer mandate them and the advances in technology today are not as easily taken advantage of with those considerations. Not saying you're wrong, just offering another viewpoint. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Fri, Nov 05, 2010 at 11:12:09AM -0400, Matthias Clasen wrote: On Fri, 2010-11-05 at 02:11 +0100, Dennis Jacobfeuerborn wrote: Interesting move: http://www.markshuttleworth.com/archives/551 Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ Until recently, wayland required private branches of quite a few dependencies. But it should be possible to build wayland against F15 packages now, or at least it should be soon. If somebody wants to give this a try, I'd be happy to review packages. Last time I tried the big problem was Cairo-drm wasn't enabled in our cairo packages. Granted that was a while ago. Also I don't know the status of drivers other than Intel getting the page-flip ioctl in the kernel, which is the other major prerequisite. Wayland certainly still has a way to go before we can think about replacing X altogether, but many pieces of this puzzle have been falling into place, and with the increased interest (and hopefully contribution), we may see it happen sooner rather than later. The code definitely needed some more eyes last time I poked it. Its completely undocumented in most places, duplicates macro declarations across multiple files, and essentially implements its own version of point-to-point dbus (the politics there aren't quite so simple, as there may be an argument for Wayland doing its own IPC, even if it does seem rather too elaborate). I'd love to see things move this way though. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstart in rawhide
On Thu, Oct 14, 2010 at 11:36:53AM -0700, Adam Williamson wrote: On Thu, 2010-10-14 at 17:13 +0200, Petr Lautrbach wrote: Hello, systemd will be default init system in Fedora 15 and scripts infrastructure will be adapted to it. There is a plan to leave upstart in Fedora as non-official alternative. Why? Same reason initng is still around: someone's willing to do the work to maintain it. Specifically Petr (who I'll turn maintainership over to soon). --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 23, 2010 at 08:04:48PM -0700, darrell pfeifer wrote: On Fri, Jul 23, 2010 at 18:26, Lennart Poettering mzerq...@0pointer.dewrote: Heya, I have just uploaded a new systemd and a new upstart package which make systemd the default init system for Rawhide. The scheme I followed makes sure that in case systemd actually breaks systems there is an easy path back to upstart. And here's how it works: - upstart and systemd are now parallel installable. When you upgrade rawhide you will get both installed. (we'll drop upstart eventually, but during the testing phase i made sure to explicitly install both, so that there is a safe backup init system) Just gave it a try with the koji of moments ago. --- Package systemd-sysvinit.x86_64 0:4-3.fc14 set to be installed -- Processing Dependency: systemd = 4-3.fc14 for package: systemd-sysvinit-4-3.fc14.x86_64 -- Processing Dependency: upstart = 0.6.5-6.fc14 for package: systemd-sysvinit-4-3.fc14.x86_64 What?! --- Package systemd-units.x86_64 0:4-3.fc14 set to be updated -- Running transaction check --- Package systemd.x86_64 0:4-3.fc14 set to be installed --- Package upstart.x86_64 0:0.6.5-7.fc14 set to be updated -- Processing Dependency: sysvinit-userspace for package: Aand this is the other half of the problem. Change I made before Lennart was around to make a complementary change in the systemd package unfortunately. It shouldn't have caused a big issue except for the really bizzare dependency mentioned above. upstart-0.6.5-7.fc14.x86_64 -- Running transaction check --- Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed -- Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit -- Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit -- Finished Dependency Resolution Error: systemd-sysvinit conflicts with upstart-sysvinit Error: upstart-sysvinit conflicts with systemd-sysvinit You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest darrell -- 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: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 23, 2010 at 10:54:50PM -0500, Garrett Holmstrom wrote: On 7/23/2010 20:26, Lennart Poettering wrote: - You can boot into either of them by setting the init= kernel cmdline option according to your wishes. If you pass init=/bin/systemd you will boot into systemd, if you pass init=/sbin/upstart you will boot into upstart (note the /sbin vs. /bin!) Why is the systemd executable in /bin instead of /sbin? Without looking too closely I believe systemd eventually seeks to replace things like gnome-session daemon. It has session management in mind as well as system. --CJD -- 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: init script behaviour
On Tue, Jun 15, 2010 at 03:30:05PM +0300, Manuel Wolfshant wrote: On 06/15/2010 03:08 PM, Joe Orton wrote: *snip* Thoughts? Well, I'd say it depends on how we define the start part. fire and forget, start and make sure it was started or start and make sure it is running. I'd say fire and forget or something close for most sysv initscripts. If you want to do better you need a modern tool like systemd/upstart/etc. Trying to do it better in bash just makes for piles of ugly, and the weird failure modes and corner cases will usually end up being worse than the problem. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 02:01:35PM +0200, Tomasz Torcz wrote: On Wed, May 26, 2010 at 01:26:48PM +0200, Lennart Poettering wrote: The problem we've found is that cgroups are too aggressive. They don't have a notion of sessions and count too much as being part of your service, so you end up with your screen session being counted as part of gdm. The per-user cgroups are controlled via a PAM module. That way there's finally a nice way how we can reliably clean up behind a user when he logs out: we just kill his complete cgroup and he's gone. You are avoiding the question: what about screen sessions? Whole point of screen is to stay after logout, and by killing cgroup you nullify it. Precisely my point. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: s/redhat/system in package names
On Sat, May 08, 2010 at 01:10:18AM +0200, Xose Vazquez Perez wrote: hi, Long time ago, all *redhat* packages were renamed to system*. But three of them are still alive: redhat-lsb, redhat-menus and redhat-rpm-config Should they switch to system- ? -thanks- I think s/redhat/fedora/ is the better choice for these particular instances. --CJD -- «Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra; que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y dé pecho a mi valor.» -- 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
