Re: Recommended laptop for FC5, was: glxgears
On Mon, 1 Jun 2009, Richard W.M. Jones wrote: On Mon, Jun 01, 2009 at 12:30:44PM -0400, Seth Vidal wrote: On Mon, 1 Jun 2009, Richard W.M. Jones wrote: On Mon, Jun 01, 2009 at 12:07:45PM -0400, Seth Vidal wrote: The biggest problem is gonna be uploading it over my *$!* ADSL connection. I wasn't looking for hosting, just for somewhere to store the tracker. It's my understanding (possibly incorrect) that the initial seed and the tracker are separate things which don't need to be kept at the same location. They don't and if you want us to serve as the tracker but NOT as primary seed then I think that can be worked out, too. Essentially you'd make a .torrent file with our tracker info in it - send us the .torrent file. We'll drop it in the holding path for the tracker and, ultimately, for our seed. so we'd start downloading it, too. or, alternatively, I could see about setting up a tracker-only non-seed path for our current tracker so that we could just track but not seed. Provided your seed would be doing all the bit-pushing work :) Yes. Thanks. I'm going to do a bit more research on making a torrent file. /usr/bin/maketorrent-console \ http://torrent.fedoraproject.org:6969/announce file_or_dir_to_torrent -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Udev issues in today's coming rawhide
On Thu, 2006-03-02 at 10:24 -0400, John DeDourek wrote:
>
> Harald Hoyer wrote:
> > Olivier Galibert wrote:
> >
> >> On Wed, Mar 01, 2006 at 11:55:02PM -0800, Jesse Keating wrote:
> >>
> >>> We're attempting to fix a problem in udev where /dev/cdrom creation is a
> >>> race between multiple optical devices in a system. To work around this
> >>> we will enumerate the devices as /dev/cdrom-hdc or /dev/cdrom-hdb.
> >>> However for compatibility reasons, we'll still create a /dev/cdrom, and
> >>> the last device found wins the race.
> >>
> >>
> >>
> >> And no /dev/cdrom1, etc. Compatibility is for the weak, I presume?
> >
> >
> > enumeration is not possible anymore... we should now have
> > /dev/cdrom-{devname}
> >
> Hmmm. To quote "Greg Kroah-Hartman", from the paper "udev -- A
> Userspace Imlementation of devfs", Proceeedings of the Linux Symosium,
> July 23th-26th, 2003, Ottawa, Ontario, Canada:
> "This paper will discuss udev, a program ... allows for features
> that were previously not able to be done through devfs alone, such
> as: Persistent naming for devices when they move around the
> device tree."
agreed. calling them "hda" is really really bad, it makes them bus
dependant again
better would be to use UUID's, or at least vendor identification strings
etc from the device. We need to NOT tie these device names to underlying
accidental device numbers. That is a major major step back.
Re: Udev issues in today's coming rawhide
On Thu, 2006-03-02 at 10:13 -0500, John Thacker wrote: > On Thu, Mar 02, 2006 at 03:39:21PM +0100, Arjan van de Ven wrote: > > better would be to use UUID's, or at least vendor identification strings > > etc from the device. We need to NOT tie these device names to underlying > > accidental device numbers. That is a major major step back. > > Wouldn't vendor identification strings, at least by themselves, still > cause problems when people have two identical model devices? That's > fairly rare for CDROM devices but not unheard of. From what I understand > of the output of udevinfo, it doesn't look like a UUID is exported > as an environment variable the way that the vendor id strings are. > I don't claim to understand everything, though, and of course it could > be changed as well. > > My understanding anyway is that the old method still somewhat depended > the underlying accidental device numbers, at least when it came to > deciding which was /dev/cdrom and which was /dev/cdrom1. but so does the new one! For example on one of my test boxes, it depends on if I have a USB stick inserted.. if it is at boot, sda is my usb stick and sdb is my sata disk, and sdc my cd writer. if it's not, sda is my disk and sdb my cd writer. Now add USB cd writers to the mix and it's clear that such device names are not persistent at all and utterly useless for identification. (and since USB goes via my kvm, this device order is potentially different each time I switch my kvm to this machine) while you can have 2 of the same type, the problem is at least less than before, not bigger than before as is the case with the proposed "solution".
Re: 2GB swap partition limit?
> But top, free and gnome-system-monitor all report that my swap space is 2GB > (more precisely, 1.9GB). IIRC, there was a 2GB limit partition for the swap > size in the past, but I thought this has been overcame. there is no principle 2Gb limit since the 2.4 kernels (RHL 7.1 for those who still remember that one). So either the tools that report are broken (eg using the wrong data types) or the tools that set things up are somehow.. but it'd be odd if it was this later since it for sure used to work.
Re: Request: boot rescue environment from USB key
On Wed, 2006-03-08 at 23:19 -0500, Jesse Keating wrote: > On Wed, 2006-03-08 at 22:57 -0500, Philippe Rigault wrote: > > If one wants to boot Fedora Core from a USB key (using diskboot.img from > > the > > images directory), it is currently only possible to run the installer, but > > not a rescue environment. > > > > It would be very helpful to be able to boot a rescue environment from an > > USB > > key. > > > > Is that doable easily ? > > I'm reasonably certain that if you boot the diskboot.img with 'rescue' > as a boot option, you'll get a rescue environment. In fact, I just > tested it and it does work. it only works if your USB device uses a partition table. The USB devices that don't use a partition table do not work in this way. At least that's my experience from last week trying to rescue my firewall from a dead disk
Re: kernel versioning
On Fri, 2006-03-10 at 09:44 +0100, Axel Thimm wrote: > Hi, > > upstream kernels that are release candidates or git sub-rcs etc. are > versioned in FC/RHEL based on the previous stable kernel release, > e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15. > > I generally think that's a good idea (e.g. it *is* 2.6.15 with patches > towards 2.6.16 and not yet 2.6.16, and the user is not confused that > he's already running 2.6.16). > > But tons of kernel module projects check on the version of the kernel > and trigger different code bits. These projects depend on the > versioning to decide whether some features exist or not. there is no good solution ;( because even if it said 2.6.16... that's not enough. the api is still changing and you'd get patches like "fedora claims 2.6.16 but it's not, so now we need to back down one level". So your proposal would trade the issue from one side, for an issue from the other side. Depending on where in the release cycle the exact cut is, either can be worse (eg the earlier the cut the more accurate 2.6.15 would be, the later the cut the more accurate 2.6.16) So all in all... I think this is just an evil that external modules need to live with as price for being external; it's effectively just the same price they pay for the non-stable kernel API in general.
Re: Request: boot rescue environment from USB key
On Fri, 2006-03-10 at 11:11 -0500, Jesse Keating wrote: > On Fri, 2006-03-10 at 08:45 +0100, Arjan van de Ven wrote: > > it only works if your USB device uses a partition table. The USB devices > > that don't use a partition table do not work in this way. > > At least that's my experience from last week trying to rescue my > > firewall from a dead disk > > Hrm, how else would you use the diskboot.img? I always just backup the > contents of my usb key, then dd if=diskboot.img of=/dev/sdX where X is > my usb fob. Works for me every time... you can do better ;) copy vmlinuz/initrd.img from the rescue image syslinux that to the disk, with proper syslinux.cfg then cp the rest of the iso to the usb stick as well and .. voila. Ought to work.. except for the case where anaconda can't deal with usb sticks without partition table
Re: Request: boot rescue environment from USB key
On Fri, 2006-03-10 at 11:37 -0500, Jesse Keating wrote: > On Fri, 2006-03-10 at 17:31 +0100, Arjan van de Ven wrote: > > > > you can do better ;) > > > > copy vmlinuz/initrd.img from the rescue image > > syslinux that to the disk, with proper syslinux.cfg > > then cp the rest of the iso to the usb stick as well > > and .. voila. Ought to work.. except for the case where anaconda can't > > deal with usb sticks without partition table > > Suppose that works. It's almost as much work to do that than to > backup / restore the existing content. I think we'd accept patches to > anaconda to handle this usage case.. (: as I said it already works. Except that anaconda as whole didn't think usb sticks come in 2 varieties: partitioned and unpartitioned. It assumed only partitioned. (fwiw gnome's HAL has the same defect)
Re: Request: boot rescue environment from USB key
On Fri, 2006-03-10 at 12:29 -0500, Jeremy Katz wrote: > On Fri, 2006-03-10 at 18:25 +0100, Arjan van de Ven wrote: > > as I said it already works. > > Except that anaconda as whole didn't think usb sticks come in 2 > > varieties: partitioned and unpartitioned. It assumed only partitioned. > > Which part of anaconda? I know I wrote code at least once to handle > both cases. the part that tries to find stage2.img; it refuses to look at the usb stick if there's no partition table. (disclaimer: this was with the fc5test3 images, it can be that you fixed it since)
Re: kernel versioning
> HAVE_SOCK_ZAPPED > NET_26_12_SKALLOC > HAVE_SOCK_SECURITY > HAVE_SKB_NF_DEBUG > SYSCTL_IPSEC_DEFAULT_TTL > HAVE_TSTAMP > HAVE_INET_SK_SPORT > > Unfortunately, I really have no idea how to better do this, unless fedora > ships some kernel header so at least all software projects could just > re-use the same defines and all projects wouldn't have to re-invent the > wheel. Because so far, we usually find out only after a kernel api broke. well API changes are one of the prices you pay for being an outside module, and is not unique to Fedora. The entire kernel development model is setup for having everything in one repo, and everything outside that is just painful. See that as incentive to get your code merged ;)
Re: No more selinux-policy-*-sources
> Not an answer to your question but there's an interesting discussion on > AppArmor and SELinux in Dan Walsh's blog: > > http://danwalsh.livejournal.com/424.html maybe it's time to accept that SELinux as technology is doomed. Not because the code is bad, but because it's Just Too Complex(tm). Complexity kills, and I think the time it is taking to get to the point where at least less than 99% of the people turns selinux off first thing is waay too long already. Maybe it's a matter of focus; sometimes I get the impression the focus is to give more coverage rather than to get the existing coverage to the point where people use it... but maybe the later is just so much work and so time consuming that it takes more time to get it than it takes the codebase to change again.
Re: No more selinux-policy-*-sources
> > I'm over-simplifying, but the main source of complexity in the current > SELinux environment is its comprehensive nature. None of the security > models currently used in SELinux is particularly complex. The MLS > security model is counter-intuitive, but it's also not currently used > ;-P As it stands, the confusing areas of SELinux itself mostly reside > at the intersection between the different models (i.e. how DAC identity > and SELinux identity interact, how roles and types relate, etc.) and > with the myriad of object classes and associated permissions. which is because the policy design seems to keep starting from the wrong place. That policy design is aimed for a "strict" policy. Even the so called targeted policy tries to work in a strict way. With this I mean it tries to be too fine grained. Far too fine grained. But that is easy to say without having to say what it should look like then... So maybe something like this: Create several high level classes for binaries * CanDoAll: no limitations at all (this already exists as unrestricted today) * NormalBinary: "modern" normal but simple binary; no executable stack, no dlopen allowed, no textrels, no writable executable memory * NoExec: like "NormalBinary" but doesn't do system/exec to launch other applications * NoNetworking: like NoExec but application is not doing anything network-ish (eg connect/bind/accept etc) these last 2 classes I bet will cover 95% of /usr/bin already. What is more, most of the requirements can be validated at build time (just by looking at which glibc functions get called) You can argue that this doesn't cover the hard cases, like ssh and apache. And you know what, that would be right. Apache is just a really really complex beast, given that it accepts 3rd party plugins and has a near-turing-complete configurability. To me the later means that any attempt to in detail describe what the application is allowed to do for the general population is doomed from the start. That leaves 3 options 1) Have a policy generator that reads httpd.conf and based on that creates the policy 2) Give apache very broad permissions 3) Work from the other angle, forbid it to do certain bad things. So instead of enumerating all the possible things you can do, you enumerate the things it cannot do. The traditional argument for MAC is "but you can't enumerate all the bad things so lets say what it CAN do". My counter argument is that you can't enumerate what it can do either, and that telling it obvious things it can't do is at least a step forward. 1) and 3) are not exclusive.
Re: No more selinux-policy-*-sources
> 5) They don't want enhanced security. I suspect this is a sizable >number of people. or rather, they don't care as long as it doesn't get in the way at all.
Re: No more selinux-policy-*-sources
On Tue, 2006-03-14 at 12:30 -0500, Stephen Smalley wrote: > On Tue, 2006-03-14 at 17:45 +0100, Arjan van de Ven wrote: > > which is because the policy design seems to keep starting from the wrong > > place. That policy design is aimed for a "strict" policy. Even the so > > called targeted policy tries to work in a strict way. > > > > With this I mean it tries to be too fine grained. Far too fine grained. > > > > But that is easy to say without having to say what it should look like > > then... So maybe something like this: > > > > Create several high level classes for binaries > > > > * CanDoAll: no limitations at all > > (this already exists as unrestricted today) > > * NormalBinary: "modern" normal but simple binary; > > no executable stack, no dlopen allowed, no textrels, > > no writable executable memory > > * NoExec: like "NormalBinary" but doesn't do system/exec to launch > > other applications > > * NoNetworking: like NoExec but application is not doing anything > > network-ish (eg connect/bind/accept etc) > > > > these last 2 classes I bet will cover 95% of /usr/bin already. > > What is more, most of the requirements can be validated at build time > > (just by looking at which glibc functions get called) > > > > You can argue that this doesn't cover the hard cases, like ssh and > > apache. And you know what, that would be right. Apache is just a really > > really complex beast, given that it accepts 3rd party plugins and has a > > near-turing-complete configurability. > > > > To me the later means that any attempt to in detail describe what the > > application is allowed to do for the general population is doomed from > > the start. That leaves 3 options > > 1) Have a policy generator that reads httpd.conf and based on that > > creates the policy > > 2) Give apache very broad permissions > > 3) Work from the other angle, forbid it to do certain bad things. So > > instead of enumerating all the possible things you can do, you enumerate > > the things it cannot do. The traditional argument for MAC is "but you > > can't enumerate all the bad things so lets say what it CAN do". My > > counter argument is that you can't enumerate what it can do either, and > > that telling it obvious things it can't do is at least a step forward. > > > > 1) and 3) are not exclusive. > > Go read: > http://www.ranum.com/security/computer_security/editorials/dumb/ So it seems we disagree some ;-) Lets gets some individual statements out then: 1) It's not feasible to enumerate all the bad things that can happen. I think we both agree on this based on your reaction. 2) For something as complex as apache (extremely configurable and used that way in practice all the time, as well as full of plugins with an active 3rd party plugin ecosystem), it is equally impossible to enumerate all the things it needs to be able to do statically and upfront. At least without ending up with an effective "everything goes" policy which is useless. I'm guessing you don't agree with this. 3) If you try anyway, and a situation you didn't think of happens because the admin configures it that way, the complexity of the policy that resulted is such that the admin no longer has a chance to fix it himself. Even when the admin might fix a simple 5 line policy situation (for example by relabling his new app as "does network" from "does no network"), expecting the admin to fix up a highly complex policy without creating wide open holes is a losing battle. Best case is he disables the lot and realizes he needs to keep his apache highly uptodate. Worst case is he thinks he's safe and never updates. I'm guessing you also don't agree with this. So that leaves a few options: * dynamic policy that adjusts to the configuration this is going to be of the same order of complexity as the configuration options are in the first place. * keep the policy simple but allow more than strictly needed, yet disallow things that are highly out of bound. The parallel to firewalls has been made several times. But in fact the linux firewall does exactly this; the "related" ruleset is a dynamic behavior that allows more than strictly would be needed to be allowed, yet it's an effective way to keep things tight when you know they can be.
re: speed up Firefox start by a factor of 3 on x86
On Fri, 2006-03-17 at 08:38 +0100, Gianluca Cecchi wrote: > On Thu, 16 Mar 2006 17:35:03 -0800 John Reiser wrote: > >In contrast, Firefox always starts in 5 seconds or less on a kernel > which places > >the vDSO intelligently: > I read the long list of your reports at the bugzilla page, with the > many details and test cases provided, but apart the beginning, you > pratically received no feedback at all (at least inside bugzilla > itself): only periodically that "having merged with upstream kernel, > more than thousands of changes, so please test again and let know..." > I think you had better to submit your considerations to upstream kernel list. > In this way if accepted, they would be naturally incorporated also in fedora. > I'm not a kernel expert so sorry if this doesn't fit for you. > Juest my 0.02 euros... > that's not going to fly since this is a fix to a fedora specific patch ;)
Re: Wild and crazy times for the development tree
On Mon, 2006-03-20 at 18:08 +0100, Ralf Ertzinger wrote: > Hi. > > On Mon, 20 Mar 2006 11:59:57 -0500, Jeremy Katz wrote: > > > to grab the fedora-release package from the FC5 release instead. If > > you want to keep testing and helping to develop things for Fedora > > Core 6, expect for some fun to pop up as always. > > Sooo... what are we going to break first? > I would love to see the -fstack-protector support for the kernel go in..
Re: Wild and crazy times for the development tree
On Mon, 2006-03-20 at 13:00 -0500, Richard Hally wrote: > Arjan van de Ven wrote: > > On Mon, 2006-03-20 at 18:08 +0100, Ralf Ertzinger wrote: > >> Hi. > >> > >> On Mon, 20 Mar 2006 11:59:57 -0500, Jeremy Katz wrote: > >> > >>> to grab the fedora-release package from the FC5 release instead. If > >>> you want to keep testing and helping to develop things for Fedora > >>> Core 6, expect for some fun to pop up as always. > >> Sooo... what are we going to break first? > >> > > > > I would love to see the -fstack-protector support for the kernel go in.. > > > What does the schedule look like for FC6? > I would like to see a 5 month schedule: personally I think the current 9 month schedule wasn't too bad (ok the end slipped too much but lets ignore that bit); it gives enough time to do fundamental improvements. For fc6 it would be nice if boot speed was further improved for example, and since initscripts are tricky and need lots of testing... a bit of extra time would be neat
Re: weird characters installing netscape 7
On Wed, 2006-03-22 at 11:24 +0100, Gianluca Cecchi wrote: > I have some Dell 5324 network switches. > To manage them via web, with firefox or epiphany I get the message > "The following browsers are supported : > Microsoft Internet explorer 5.5 and above > Netscape Version 7.1 and above > " it's probably easiest to get one of those plugins that allow you to override the browser ident string and fake to be IE :)
Re: What I HATE about F11
On Sun, 14 Jun 2009 18:34:52 +0100 > > I think this is actually a problem that needs solving. We have > several network services that are either installed by default or > might be expected to be part of a standard setup, but which don't > work because of the default firewall rules. The Anaconda people have > (sensibly, IMHO) refused to simply add further exceptions to the > firewall policy. there is an interesting issue; if you poke a hole in your firewall for all the ports that are listening automatically. you might as well not have a firewall in the first place... -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Sun, 14 Jun 2009 19:49:01 +0200 drago01 wrote: > If you need to login as root into X to "set up the system" you are > doing something wrong. yet you may need this to fix some earlier goof. not allowing the root user to do what he wants/needs to do is obnoxious in that sense; when you need something like this, the system is NOT operating in a normal way, and yet the owner thinks he can fix his system as a last resort this way. (while there is no real security upside to ban root from doing things he can enable in the case the system is not yet hosed) -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Sun, 28 Jun 2009 20:20:27 +0200 Kevin Kofler wrote: > Seth Vidal wrote: > > I think we have a handful of vocal opponents. > > Where have you seen a hand with thousands of fingers? ;-) > > > luckily we don't have to implement every whim that the majority or > > a vocal group yells about. > > If you go against the wishes of the majority, that's per definition > undemocratic. I always thought of Fedora being more of a meritocracy than a democracy. or in other words "code / effort talks more than words". -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, 30 Jun 2009 14:56:44 +0100 Matthew Garrett wrote: > ACPI docking stations are mildly complicated creatures that require > the OS to handle part of the undocking process. We're currently doing > this entirely within the kernel, but this has the significant > downside that there's no way to handle cleanly unmounting any block > devices that are contained within the dock - they'll simply vanish. > > I've been working with David Zeuthen to flesh out proper desktop > support for this, and we're now at the point where there's not a > great deal of code to write to get this working cleanly. > Unfortunately this requires a certain level of integration between > the kernel and the desktop - something has to prompt the user about > unmounting the device and then trigger the completion of the undock. > The kernel still handles the actual ACPI execution, but policy now > lives in the desktop. > > Once this code is ready I'd like to change the kernel defaults to > allow this. The problem is that this will cause a reduction in > functionality for desktops that don't have this integration. How > should this kind of situation be handled? > how common are docking stations in practice? (as opposed to port extenders) -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ASPM enabled by default - mild potential for breakage
On Thu, 16 Jul 2009 22:28:57 +0100 Matthew Garrett wrote: > I've just flicked ASPM (Active State Power Management - runtime power > saving on PCIe hardware) on by default, and it'll be that way in the > next rawhide kernel build. There's the potential for some buggy > hardware to be upset by this. If your system no longer boots or some > hardware doesn't work, try booting with the > are you sure you want to do this? the bios is supposed to set this up already... ... except on chipsets where there's known hw issues (first generations) (including ICH7's etc) so enabling it by force is maybe not always a good idea. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add Moblin Desktop group to comps
On Thu, 20 Aug 2009 18:06:33 +0100 Peter Robinson wrote: > Depends on which bits you look at. Most of the packages are based on > Fedora packages, the whole lot is built using the suse build system. Depends on how you look at it ;-) A bit less than half our packages are created using specbuilder, from a small ini file. For a bunch of these we did borrow the Fedora description of the package. You can expect Moblin to increasingly use specbuilder going forward (including tools we're developing right now to create as much of the specbuilder metadata as possible straight from the upstream tarbal). > The NM/connman is an interesting split. The Moblin OS uses Connman for everything networking. This is a different architecture than what Fedora does, where Fedora has /etc/sysconfig and other scripts that do part of the work etc. At first this looks like a minor change, but it's kinda fundamental. I'm not saying that the Fedora style is bad, it's just not what we picked for the Moblin OS, and it's probably not what Fedora would have done had they started from scratch. > > What we really do need is some more directed coordination between > > the two projects. > > That would be fabulous, but only time will tell. Moblin and Fedora have rather different objectives. I'd be happy to work together on areas of joint interest, but I don't see the OSes as a whole converge, rather they will diverge even more than they already have. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add Moblin Desktop group to comps
On Thu, 20 Aug 2009 09:32:25 -0700 Jesse Keating wrote: > On Thu, 2009-08-20 at 17:22 +0100, Peter Robinson wrote: > > Hi All, > > > > I would like to add a group for the Moblin Desktop. My proposed > > patch is below and feedback is welcome. > > Is "Moblin" a trademark of anybody? yes I don't know the exact details, but afaik there's very liberal permissions for the trademark, as long as you pass the compliance tests... -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add Moblin Desktop group to comps
On Sat, 22 Aug 2009 12:31:55 -0700 Arjan van de Ven wrote: > On Thu, 20 Aug 2009 09:32:25 -0700 > Jesse Keating wrote: > > > On Thu, 2009-08-20 at 17:22 +0100, Peter Robinson wrote: > > > Hi All, > > > > > > I would like to add a group for the Moblin Desktop. My proposed > > > patch is below and feedback is welcome. > > > > Is "Moblin" a trademark of anybody? > > yes > > > I don't know the exact details, but afaik there's very liberal > permissions for the trademark, as long as you pass the compliance > tests... I should mention that I actually don't know if/how the trademark works; I do not that it's zero hassle for those that pass the compliance test (which is very similar to the lsb testsuite) -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add Moblin Desktop group to comps
On Sat, 22 Aug 2009 15:39:36 -0400 Michel Salim wrote: > On Sat, 2009-08-22 at 12:04 -0700, Arjan van de Ven wrote: > > On Thu, 20 Aug 2009 18:06:33 +0100 > > Peter Robinson wrote: > > > > > Depends on which bits you look at. Most of the packages are based > > > on Fedora packages, the whole lot is built using the suse build > > > system. > > > > Depends on how you look at it ;-) > > > > A bit less than half our packages are created using specbuilder, > > from a small ini file. For a bunch of these we did borrow the Fedora > > description of the package. You can expect Moblin to increasingly > > use specbuilder going forward > > (including tools we're developing right now to create as much of the > > specbuilder metadata as possible straight from the upstream tarbal). > > > Is specbuilder made available anywhere? I browsed the git repository > but it's not listed there. Given the length of Fedora's current > packaging checklist, it would be something that would be great if we > can borrow it. > hmmm it's in git. I'll check on Monday with our sysadmin to see why it's not visible -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Sat, 28 Nov 2009 00:32:04 +0100 drago01 wrote: > On Fri, Nov 27, 2009 at 11:29 PM, Felix Miata > wrote: > > On 2009/11/28 03:01 (GMT+0530) Rahul Sundaram composed: > > > >> Huh? Your perspective just seems very odd. In a year, if we don't > >> have a composited desktop by default in Fedora, I would be very > >> very surprised. Just watch. > > > > Good thing all puters don't depend on batteries for power. > > It does not matter how often people repeat that (and even if KDE has > an option to "disable composting to save power") just running a > composite manager should NOT require any more power. > If it does it is just broken. In fact it should use LESS power if done > right (less wakeups because you don't have to update the whole screen > every time something changes), > > Let me say this again a cm DOES NOT require more power than a non > composited desktop. (notice the NOT) sadly I am no longer convinced you are correct. But to each their own. in the long run we'll end up with whatever solution is best, whichever it is. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
