Re: Question about dist-cvs make targets
On Thu, Jan 7, 2010 at 5:28 PM, Jesse Keating jkeat...@redhat.com wrote: unused-patches I use this one, but it's probably something that should just happen as part of a build sanity check, or even better make it harder to cause (the new dist-git setup might do this right?) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Thu, Dec 17, 2009 at 10:51 AM, James Antill ja...@fedoraproject.org wrote: How do you plan on restarting firefox? Or you just planning to kill() and get the user to restart? Trying to send a close button event to the app's windows is probably our best short-term approach; slightly longer term, we could have apps expose a standard interface for Quit (e.g. over dbus). Knowing how to restart is trickier, (though we could use the window-to-app mapping system we need for gnome 3 anyways) but it's also very simple in this case if we require that packages contain at most one .desktop file. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Thu, Dec 17, 2009 at 3:21 PM, Ewan Mac Mahon e...@macmahon.me.uk wrote: That would fail pretty badly in the case of Firefox with multiple windows open. True; there's nothing stopping us from adding something Firefox-specific as a short term measure, since how it does session saving is fairly unique right now (ideally we add a nice API for this to GTK+ which then has to be mirrored in XUL). Killing the process though has the downside of triggering the Well, that was embarassing... which is arguably a Firefox bug though. Anyways, the perfect is the enemy of the good, etc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Tue, Dec 15, 2009 at 5:40 PM, Richard Hughes hughsi...@gmail.com wrote: 2009/12/15 Seth Vidal skvi...@fedoraproject.org: Now, having said that - how would you feel if the updater stopped you before it ran and said you're running an app I'm trying to update, please close the app so I can update it. Would that be a pain or ok? That's exactly the PackageKit functionality I've added for packages like firefox, that explode internally when they get updated. The trick it to offer to close them down, and bring them back when done. This exists? Can you point me to the code? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora release criteria completely revised
On Wed, Dec 9, 2009 at 5:27 PM, Adam Williamson awill...@redhat.com wrote: This is what it was intended to mean, actually running apps I would have defined as 'login and use'. How would you suggest wording a clarification? Looking at it again, it's fairly clear that this just covers the desktop view, given criteria 12. So this looks fine, thanks! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora release criteria completely revised
Hi Adam, Looks really great in general! One specific comment, for Final 9; I think we need a more specific definition of and subsequent login. Does that mean that you just type your username/password and look at the default desktop? Are we scoping in any specific apps (firefox?) Under any specific use cases (websites, random plugins?). Any other apps? (I see just now someone else commented on this specific criteria, but instead asking about hardware). My take is we should just scope it to critpath (i.e. enough of the desktop to run packagekit), and have some sort of separate criteria/process for applications. On Mon, Dec 7, 2009 at 5:55 PM, Adam Williamson awill...@redhat.com wrote: During FUDCon, we've been working on revising the Fedora release criteria. John Poelstra had already fleshed out a structure and much of the final content, and we've been revising and tweaking it in conjunction with QA (myself, Will Woods and James Laska), release engineering (Jesse Keating), anaconda team (especially Denise Dumas and Peter Jones) and desktop team (Christopher Aillon and Matthias Clasen, who provided suggestions at an earlier stage). The new structure is based around a general page and specific pages for the Fedora 13 Alpha, Beta and Final releases (which have been written generically so they can easily be converted into pages for F14 and all future releases just by copying and pasting). You can find the criteria here: https://fedoraproject.org/wiki/Fedora_Release_Criteria https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria they should contain everything you need to know. We based most of the criteria around testing that was already being carried out but with no formal policy basis, with additional suggestions from the anaconda and desktop teams. We will follow these criteria for the Fedora 13 release process. So if you can see any problems or potential trouble with any of this, please do reply and let us know! Desktop team - can you please let us know of any additional things that you would expect to be working at each point during the release cycle? Note that only things that *must* be working at each point should be listed on these pages, not nice-to-haves. You must be able to commit to the idea that, if any criterion on the page is not met, we would slip the release in question. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Tue, Nov 24, 2009 at 1:42 PM, Jan Klepek jan.kle...@brandforge.sk wrote: What if package maintainer would need to followup on the issue? Last bug reported from abrt for subdownloader package was useless, there was not enough info that I could reproduce issue and I'm waiting if reporter will give me more info. With anonymous reports, I will not get info which I will need. https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01574.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. We could possibly do this even now inside PackageKit by always downloading the filelists data, and looking for a .desktop file. It'd be even better if we could get at the data inside the .desktop file, but that's not necessary for this. That leaves aside the packagekit-command-not-found feature for unix binaries, but that's more of a technical use case. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Sat, Nov 21, 2009 at 12:32 AM, Kevin Kofler kevin.kof...@chello.at wrote: Colin Walters wrote: You don't; the submitter of course should get a link to their crash report, and can perform the bugzilla promotion on their own if they have more to add. My experience is that fireforget reporting is rarely useful, especially if it comes from an automated tool where users rarely think of filling in ANY information other than the autogenerated stuff. We MUST be able to contact the reporter for more information. If they're not willing to answer needinfo requests, the report is basically useless. Look at it this way - it's *more* information than you had before, not less. And I personally have often been able to find a problem with no more than a traceback (especially given -debuginfo being installed, or an enthusiast/developer running code from revision control and thus having un-stripped binaries). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Thu, Nov 19, 2009 at 4:48 PM, Jesse Keating jkeat...@redhat.com wrote: On Thu, 2009-11-19 at 09:14 -0500, Owen Taylor wrote: It doesn't work practically: configuration for packages needs to live with the package. Putting gigantic amounts of configuration into the %post of a kickstart file quickly becomes unmanageable. And the idea that we make configuration changes in the %post of the kickstart really falls part badly once people start upgrading their install to the next version of Fedora. Which is why you do it with specifically selected policy packages, and not trying to write out files in %post. Create a set of policy packages that define certain user cases, and pick from those as you construct a spin. This makes sense to me; but there are details to work out. * Do we have any guidelines on what the policy should be in upstream source? Corresponding Fedora RPMs? * Do we have a fedora-default-policykit-policy? * How do we get this installed on upgrades? Code in preupgrade? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Hi, On Wed, Nov 18, 2009 at 12:08 PM, nodata l...@nodata.co.uk wrote: Yikes! When was it decided that non-root users get to play root? This is hardly the first uid 0 operation we've granted users access to in the operating system, and it won't be the last. For example, on a timesharing Unix system, non-uid 0 can't reboot the machine, but it's clearly silly to ask for a root password to reboot for the unmanaged case, so years ago the consolehelper system was added, and that privilege is currently given to users at a physical display for the machine. We've used the console concept as our only tool in this respect for a long time, and PolicyKit will ultimately replace all of it with a far more fine grained system. So you raise a reasonable issue, which is how do you know when the defaults change, or new privileges are added? We don't have a very good system for that now; ideally we would detect when new packages are added to @gnome-desktop that include PolicyKit policies, and use that as a basis for release notes type of thing. But, bottom line, if you're administering a Fedora-derived desktop, you will need to get familiar with PolicyKit, and you may need to tweak the defaults, which are more targeted for the self-managed case. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 1:48 PM, Chris Adams cmad...@hiwaay.net wrote: It seems the latest way of doing this is via PolicyKit. IMHO all PolicyKit configuration should be secure by default, secure is an meaningless term without reference to a deployment model and threat model, but let's assume here for reference that what you mean is that the shipped RPMs should be configured to not grant any additional privileges over that afforded to the traditional Unix timesharing model, and then the desktop kickstart modifies them. I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping? Right now, I see files /usr/share/PolicyKit/policy; I guess that's where this kind of thing comes from. How do I override the settings in one of these files? None of them are marked config, so I guess I don't edit them. Are there other places such policy can be set? See man PolicyKit.conf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
(Thanks for a constructive discussion by the way!) David, added you to CC for a question below: On Wed, Nov 18, 2009 at 2:31 PM, Chris Adams cmad...@hiwaay.net wrote: I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping? In an ideal world, everything that could grant elevated privilege would come without it, and the admin (or spin config files) could easily configure it back. Right. That obviously fails for things like /bin/ping, since that uses file permissions, and that's part of the RPM (and not configurable). However, ping has traditionally been run-able as a non-root user, and it is easily spotted with find. Right; I gave the specific example of ping because it's about the oldest most traditional Unix thing I could think of. The number of setuid programs is small these days, but several of them are now helpers that allow a wide-range of other programs access, again with minimal documentation (what is pulse/proximity-helper? why is nspluginwrapper/plugin-config setuid root?) Hm, this is off the top of my head, but I think the idea with nspluginwrapper is that you install the flash-plugin RPM (which has no idea about nspluginwrapper, and I think upstream is actively hostile to it actually), then restart firefox (as your user), but the installed flash plugin needs to be wrapped, so our firefox runs the setuid script to update the system plugin database. Not sure about proximity. Yes, we could clearly use more auditing here. I think anything that uses PolicyKit should ship with no elevated privileges by default, since it is configurable. So, that leaves us with the question of how to configure it for Fedora. A data point here is that the Fedora polkit package adds two Unix groups desktop_user_r and desktop_admin_r. However, it's unclear to me whether the expectation is that official Fedora consumables (i.e. desktop installer) would customize PolicyKit using these. David, what do you think about having Fedora RPMs have all defaults be no? And getting this change made upstream? We discussed this eariler, you replied here: http://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00266.html Do you still advocate doing this is achieved simply by editing PolicyKit.conf in the %post of the live cd creator. It's that simple really. ? We need to have some story for this, otherwise it's really confusing to everyone, from developers to admins, see e.g.: http://www.redhat.com/archives/rhl-devel-list/2009-August/msg00578.html It would be nice to also get consolehelper, but that is more complicated. I thought that was on the way out (to be replaced by PolicyKit), but I see there are still a number of things that use it (looking at the F11 desktop I'm on right now). Yeah, converting system-config- is going to take some time. The bigger issue is that much of the policy is not well documented, except in the XML files (which are pretty terse). The individual actions aren't documented well enough? Or the 1,000 meter view of all of the installed actions on a default desktop? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 3:20 PM, Jeff Spaleta jspal...@gmail.com wrote: I'm not sure enough sysadmins understand PolicyKit enough to confidently generate local policy edits. I think learning how to implement site specific PolicyKit best practises by modifying unwanted PackageKit's behavior is going to be a trial by fire introduction to PolicyKit policy editting for a lot of admins. We saw the same sort of learning curve frustration when hal policy was introduced that changed how hardware was handled. Having Yet Another access control system in HAL was precisely the reason PolicyKit was created, so administrators can have one place to find this stuff across the OS. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 5:18 PM, Jeff Garzik jgar...@pobox.com wrote: You forget we have botnets doing distributed cracking now. But...if you've cracked the root password, there are rather easier (and less audited) routes to trojaning the system than adding a third party yum repository and downloading your malicious RPM. And this enormous security hole of a policy change was done with next to /zero/ communication, making it likely that many admins will not even know they are vulnerable until their kids install a bunch of unwanted packages. I think you are correct that the change could have been documented better. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 7:36 PM, Jeff Garzik jgar...@pobox.com wrote: And it ignores that remote exploits are now much easier, because remote non-root exploit + package install == remote root exploit. No, the uid needs to have logged in through a physical console. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, Oct 22, 2009 at 4:50 PM, Jesse Keating jkeat...@redhat.com wrote: Rawhide as we know it, /pub/fedora/linux/releases/development/ will remain rawhide. We may even change the path to say rawhide, just to catch things up and well I like keeping mirrors on their toes. Rawhide will be a repository of developmental and experimental packages. Things being worked on for the future. It will /not/ be an installable tree, rather it will just be a repository of packages, to be added on to an already stable base, eg you'd install F12, and enable rawhide to test rawhide. This will significantly lower the complaints that rawhide isn't installable. So as I understand it there are a number of reasons why rawhide might not be installable, but broadly they fall into two major categories: * Anaconda * Critpath packages - Dependency/rebuild issues - Bugs in %posts (like the user/group one we ran into with dbus) - Core bugs (graphics drivers) It seems like we're basically just skipping Anaconda, since you won't be able to yum if there are depsolving issues (ok, modulo --skip-broken), and for the latter two you don't end up with a working system. Let me do a counter-proposal: We simply do not let showstopper regressions in the critpath stay in rawhide. If something in critpath has a showstopper, it halts all further commits to the entire critpath until it's resolved (either fixed, or reverted). The definition of showstopper might be AutoQA fails. And since AutoQA will have been doing some basic smoketesting of the installer, we have to be producing installer images as a side effect. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fwd: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Thu, Oct 15, 2009 at 4:48 PM, Dave Airlie airl...@redhat.com wrote: 2 months is too long for user apps maybe, for X.org or Mesa from what I can see for ever probably isn't long enough My guess is that it's relatively easy for a semi-technical person to be able to map back from a visible problem in a desktop app to a package name, and finally from a package back into the bodhi comments. But a lot of issues in the core OS from the kernel up to gnome-desktop can require extensive knowledge to diagnose, and we just can't expect as much feedback. Especially for critpath components that people might be more hesitant to update. Pages like this one: https://fedoraproject.org/wiki/How_to_debug_Xorg_problems are a big step forward, but we may need some way for people to give feedback about updates without having to debug enough to make a rough stab at kernel or xorg-x11-drv-intel or gnome-power-manager. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upload debug-like-info to Mozilla servers every update
On Wed, Oct 14, 2009 at 9:04 AM, Jan Horak jho...@redhat.com wrote: Mozilla prefers using their own system in this case. It has some pros, like user don't have to download debug packages (which is approx 80MB for each package). Building the symbols for Mozilla is also quite easy. They have everything prepared in their makefiles and their debug info is just one zip file. All we need is to put this zip file somewhere that mozilla could pull it (or we push it after package is released). This zip file should be left aside from regular rpm package (read unpublished). In that case I'd just make the mozilla spec file to put the .zip in the -debuginfo package. Then their crash handling code just needs to get the built RPM NVRA (it should probably be compiled in, but forking a rpm -q could work I guess), and their server side can fairly easily script a wget http://download.fedoraproject.org/.../mozilla-debuginfo-12345.rpm;. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help with debuging Xserver / Goes in an infinite loop
On Mon, Oct 5, 2009 at 4:06 PM, Adam Jackson a...@redhat.com wrote: Before typing in cont, of course. cont continues execution from where you're currently stopped. bt shows a backtrace of where you're currently stopped. If you're not planning to actively debug and just want a stack, i'd use: gstack $(pidof Xorg) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Fri, Oct 2, 2009 at 9:20 AM, Haïkel Guémar karlthe...@gmail.com wrote: *BSD, fellow GNU/Linux distro like Debian [...] are able to ship multiples python stacks In Debian's case of course there are actually *two* separate Python systems ;) http://wiki.debian.org/DebianPythonFAQ I didn't understand either and was quite confused trying to debug one of my Python applications on Debian, but if they're useful we might consider adopting one of them rather than reinventing another parallel install system. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NFS and slow boot
On Fri, Oct 2, 2009 at 6:53 PM, Steve Dickson ste...@redhat.com wrote: Is there any kind of a error being logged in /var/log/messages? Wild guess; nfs client service is trying to look up the hostname (possibly repeatedly), but it's broken. I think in F11 something regressed in anaconda/NetworkManager which no longer caused custom hostnames to be written to /etc/hosts. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Fri, Oct 2, 2009 at 8:19 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I brought up Debian's parallel install system before (I believe the last time python24 python2 python3 came up) and someone did a quick anaysis and said it wasn't a good idea. Fair enough, just wanted to be sure it was at least looked at. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 1, 2009 at 2:39 PM, David Malcolm dmalc...@redhat.com wrote: I'm not volunteering to put it into F12. I think that anyone wanting to push it into F12 needs to sign up for a lot of testing (brainstorming some testcases: can you still compile and build external modules with both 2 and 3 -devel subpackages installed? does every configure script pick up the correct version? etc) Which brings up a useful point in that the critical path has two components; the closure of their Requires, and the closure of their BuildRequires. However - this still seems like low risk to me because the builders only build with what's specified in BuildRequires, so you'd have to have quite a contortion to get python3-devel in there. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Fri, Sep 25, 2009 at 5:55 PM, Mike McGrath mmcgr...@redhat.com wrote: Wouldn't you rather lead the other distributions who already have that project goal? Let us lead, invent, whatever you want to call it. Let them refine and present to the 'ordinary people'. Let us play to our strengths, let them play to theirs. We win, they win, users win. I don't think that works; in general doing infrastructure work without reference to a user experience is going to result in a big mismatch between the desired UI and what's available. In this particular case it seems to me we want it to be a dynamic property; e.g. if I start an update while on my mobile broadband card, suspend in the middle of downloading, go to an office where I have a local mirror, well ideally I'd be able to check a box in the UI to toggle it (if it really mattered), or even better the system would use some heuristics. But obviously, you can't disable delta compression by doing a yum remove in the middle of your download... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: default fonts in Fedora
On Fri, Sep 18, 2009 at 3:40 PM, Rex Dieter rdie...@math.unl.edu wrote: As far as I can tell, gnome-desktop doesn't include explicit (default or otherwise) fonts either. I haven't dug through the dependency graph yet, but looking at fedora-livecd-desktop.ks: google-droid-sans-fonts google-droid-sans-mono-fonts google-droid-serif-fonts These are wrong and should be in the comps group. Looks like Matthias added them. I'll move them to comps now. Shouldn't a good/default set of monospace/sans/serif fonts get pulled in from somewhere, somehow? Am I missing something? I have no opinion personally on whether this should live in the package dependency graph (and if so, where). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
On Wed, Sep 16, 2009 at 10:06 AM, Benny Amorsen benny+use...@amorsen.dk wrote: Colin Walters walt...@verbum.org writes: I'd imagine that running the live Anaconda UI from inside the GDM X session wouldn't take significantly more resources than the Anaconda OS after creating an image that doesn't have games, etc. Images sound significantly more difficult to create and maintain than kickstart-files. I would really hate to lose kickstart. No one's suggesting replacing kickstart, actually I think we way undersell it. What I'm talking about is the mode where the image boots directly into Anaconda as a complete OS should instead be a live image with Anaconda as an application, which for the most part would be the same except you'd gain the ability to run say Firefox (or any other app; games), or do yum install during the install. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
On Mon, Sep 14, 2009 at 6:08 PM, Bill Nottingham nott...@redhat.com wrote: We've been describing that future for a while. In the meantime, having to actually install uninstalled versions of random software seems inefficient. Well, there are a few other virtues to having a larger image, namely: * Can use web browser to find out more information about applications (and in general, use other live tools) * De-duplicates the install path, allowing us to focus on streamlining one single path -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
On Mon, Sep 14, 2009 at 6:28 PM, Bill Nottingham nott...@redhat.com wrote: Colin Walters (walt...@verbum.org) said: * De-duplicates the install path, allowing us to focus on streamlining one single path Given the requirements for server installs (kickstart, etc.) I don't know that you can ever go to live-only (unless you really *shrink* the live image.) I'd imagine that running the live Anaconda UI from inside the GDM X session wouldn't take significantly more resources than the Anaconda OS after creating an image that doesn't have games, etc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
On Sun, Sep 13, 2009 at 6:53 PM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le 13/09/2009 20:29, Kevin Kofler a écrit : The DVD size would allow us to include more stuff, like translations (kde-l10n-*, those are fairly huge and there are many supported languages), input method support (the current GNOME live CDs include that, but we weren't able to fit it on the KDE ones), additional applications (there are plenty of nice KDE apps, and we might also consider including stuff like OO.o), maybe upstream wallpapers (not as the default, but as options). We've found the CD size to be very limiting. Well, the CD does not include most of the fonts we package. Not enough fonts is a recurrent user complaint (was moded up +5 insightful several times again when /. posted its “why users reject FLOSS apps” article). So I'd expect desktop livecds to address this. I think the cleanest way to fix this is to have a post-installation program for the Live CD image which offers to Complete your installation? and does the PackageKit equivalent of yum groupinstall corresponding comps group. (This is another reason why the kickstart files should only be subtraction-for-space from a comps group). The Live CD should basically be enough to bootstrap and get a good feel for the system and do basic tasks. This also moves us much closer to having 1 defined set of things in the installation instead of two wildly different things which is really broken from a QA/marketing/etc. standpoint. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
On Sun, Sep 13, 2009 at 7:46 PM, Aditya Patawari adi...@adityapatawari.com wrote: We thought of this earlier. Being a fedora ambassador when I go to promote fedora the most common problem I hear is that people are not able to get everything from repo due to bad internet connection Right, understood. What I'm arguing is that what you get when you install the Live DVD should actually be identical to the comps group. However if it's desired to fill the full 4 gigabytes (i.e. actually be DVD size), then I suggest what you do is pre-load a lot of stuff into the yum cache, but not actually install it. A bit of PackageKit work could expose to the interface only search cached stuff perhaps. Or maybe the UI already knows about http:// versus file://, and if you just made a repository which pointed at the mounted DVD? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Possible package...
On Fri, Sep 11, 2009 at 9:03 PM, Kevin Kofler kevin.kof...@chello.at wrote: Ben Boeckel wrote: Looking through the code, it looks like the #ifndef stuff for things called extensive hacks could cause some issues, but that's a cursory glance at it. I'm also not sure what to make of the patches for Qt in its repository. If they're serious patches, they should clone Qt on Gitorious and create merge requests. Fedora's Qt probably won't ship with them without some oversight that they aren't breaking things. At least part of their patches look like really awful hacks, e.g. they're making some of QtGui work without X11 to support their stuff being used in text mode despite using QtWebKit (which is normally a GUI component). Some of the patches also appear to break ABI compatibility. I'd try adding a shell script wrapper which just does: if test -z $DISPLAY; then exec xvfb-run /usr/libexec/foo/real-binary else exec /usr/libexec/foo/real-binary fi Then you just need a dep on xorg-x11-server-Xvfb Incidentally, I'd like to change the OS so that you *always* have a DISPLAY (and DBUS_SESSION_BUS_ADDRESS), the first step of which would probably just be a pam_session module that asks ConsoleKit if your uid currently has a login, and if so pulls those bits in. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On Wed, Sep 2, 2009 at 5:11 PM, Matthias Clasenmcla...@redhat.com wrote:
On Wed, 2009-09-02 at 17:04 +, Colin Walters wrote:
On Wed, Sep 2, 2009 at 4:38 PM, Matthias Clasenmcla...@redhat.com wrote:
After talking to the abrt guys, I've changed the desktop spin ks to
replace bug-buddy and kerneloops by abrt.
This change should be made in comps (as per my original attached
patch), not the kickstart. If we only change the kickstart then
people doing automatic kickstarted desktop installs will get a
divergent desktop which is not what we want.
Sure, I agree that we should also do this change in comps.
Ok, done. The comps change should be pulled into the kickstart
through so there shouldn't have been a need to change it as well.
Also I've attached a patch which should update the Obsoletes handling
to correspond with what we determined in discussion earlier; if one of
the ABRT people or a provenpackager could apply that'd be nice.
? clog
Index: abrt.spec
===
RCS file: /cvs/pkgs/rpms/abrt/devel/abrt.spec,v
retrieving revision 1.13
diff -u -r1.13 abrt.spec
--- abrt.spec 31 Aug 2009 12:55:40 - 1.13
+++ abrt.spec 2 Sep 2009 17:16:21 -
@@ -4,7 +4,7 @@
Summary: Automatic bug detection and reporting tool
Name: abrt
Version: 0.0.8
-Release: 1%{?dist}
+Release: 2%{?dist}
License: GPLv2+
Group: Applications/System
URL: https://fedorahosted.org/abrt/
@@ -56,6 +56,7 @@
Provides: abrt-applet = %{version}-%{release}
Obsoletes: abrt-applet 0.0.5
Conflicts: abrt-applet 0.0.5
+Obsoletes: bug-buddy
%description gui
GTK+ wizard for convenient bug reporting.
@@ -75,7 +76,7 @@
Group: System Environment/Libraries
Requires: %{name}-plugin-kerneloopsreporter = %{version}-%{release}
Requires: %{name} = %{version}-%{release}
-Conflicts: kerneloops
+Obsoletes: kerneloops
Obsoletes: abrt-plugin-kerneloops
%description addon-kerneloops
@@ -335,6 +336,10 @@
%defattr(-,root,root,-)
%changelog
+* Wed Sep 02 2009 Colin Walters watl...@verbum.org 0.0.8-2
+- Change Conflicts: kerneloops to be an Obsoletes so we do the right thing
+ on upgrades. Also add an Obsoletes: bug-buddy.
+
* Wed Aug 26 2009 Jiri Moskovcak jmosk...@redhat.com 0.0.8-1
- new version
- resolved: Bug 518420 - ordinary user's abrt-applet shows up for root owned crashes (npajkovs)
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Reboot madness? [Was: Re: dhclient and dhcp update require restart?]
On Wed, Sep 2, 2009 at 7:44 PM, Stephen John Smoogensmo...@gmail.com wrote: I think that the selling point is over-sold. It is true in many case for servers, but desktops are a much more interconnected system where updating something deep requires a lot of restarts.. and yes you could come up with a to probably deal with a good many of without a reboot... it is often faster to reboot the box than work out that you need to restart daemon-A then Y then Z and then A again It's a rather nuanced issue; the biggest distinction I see between the server versus (particularly unmanaged) desktops isn't the dependency stack so much as the level of knowledge/expertise in the system consumer. Most system administrators take training courses that tell them what the big list of semi human consumable UUIDs (package names) are and they are in a better position to be aware of the tradeoffs and when things can be restarted. Unmanaged desktop consumers have so such training, they just want the desktop to be reliable and work. As for the system-reboot versus login/logout; yes, such a distinction is something we would really like for PackageKit to have. It would be a bit tricky code to write to determine if an installed RPM has changed a currently installed X desktop app, but it's something we definitely need, and would be a great project for someone with some understanding of X11 and how PackageKit works to jump in and work on to improve the Linux desktop experience. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dhclient and dhcp update require restart?
On Tue, Sep 1, 2009 at 5:07 PM, Matthew Woehlkemw_tr...@users.sourceforge.net wrote: No, the easiest method is: The following updates require their respective services to be restarted for the updates to take effect. List of services. Proceed? [Yes] [No] I don't think it makes sense to treat everything that presently has an /etc/init.d script equally. For example, if cupsd has no queue, it's probably safe for it to just restart itself at some period of time. Probably the easiest way to implement this would be a flag in the init script which says whether it's safe to service restart on updates. For other things, an important question is whether the currently running desktop depends on it. If it does, it's not safe to have such a UI. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
ABRT for f12 status
Hi internets, I was looking at the current state of ABRT (I tested on F11). The core capturing seems to work well. In brief, I propose to apply the (attached) patch to comps-f12.xml.in. For upgrades, we'll need to add a Conflicts: bug-buddy, correct? ABRT is a big step forward from bug-buddy in that the crashes are stored sanely in a persistent manner, and it captures crashes in the core OS as well. Concerns: == Getting the Data == My main concern is ensuring that we get the data reliably to the eyes of Fedora developers. The current abrt-desktop virtual package[1] depends on abrt-plugin-bugzilla, which has a default BugzillaURL = https://bugzilla.redhat.com/. To be able to successfully submit data, you have to go to: Edit-Preferences, click Bugzilla, click Configure Plugin and enter a username/password; there's no provision for creating a Bugzilla account here. I suggest that Fedora infrastructure instead provide a service where the data in /var/cache/abrt can be submitted via HTTP post as a tarball, anonymously. Then the crash UI can be just A problem has been detected in [whatever]. Do you want to send this data to Fedora? [Submit] [ See Data ] [ Cancel ]: On the server side then we can later write tools to analyze the crash data (reuse kerneloops? socorro? write custom code?). Secondary concerns: == kernel/GNOME developer feedback == We should ensure Fedora is still sending crashes from the kernel to kerneloops.org; does ABRT handle this? Also, ideally on the server side there would be a web page where a GNOME developer (hi!) could go to http://crashes.fedoraproject.org/package/gnome-panel and see a list of crashes sorted by number. == Privacy == ABRT needs some explanation that the crash data may contain private information. We may need to restrict visibility of the data to only Fedora account holders by default or the like, to at least prevent any future effects like a Slashdot link to a trace where the submitter was viewing pornography or the like (yes, this happened with GNOME bugzilla). But in general, thanks for the work on ABRT, we should get this in by default for the F12 desktop target. [1] For RPM/dependency graph people: Why does this exist? I thought virtual packages were disallowed? Should just be in comps I think. Index: comps-f12.xml.in === RCS file: /cvs/pkgs/comps/comps-f12.xml.in,v retrieving revision 1.98 diff -u -r1.98 comps-f12.xml.in --- comps-f12.xml.in 27 Aug 2009 14:49:40 - 1.98 +++ comps-f12.xml.in 28 Aug 2009 21:13:54 - @@ -360,7 +360,7 @@ packagereq type=defaultfirstboot/packagereq packagereq type=defaultglx-utils/packagereq packagereq type=defaultgnome-packagekit/packagereq - packagereq type=defaultkerneloops/packagereq + packagereq type=defaultabrt-desktop/packagereq packagereq type=defaultkrb5-auth-dialog/packagereq packagereq type=defaultopenssh-askpass/packagereq packagereq type=defaultplymouth-system-theme/packagereq @@ -2462,7 +2462,6 @@ packagereq type=conditional requires=scimscim-bridge-gtk/packagereq packagereq type=defaultat-spi/packagereq packagereq type=defaultbrasero-nautilus/packagereq - packagereq type=defaultbug-buddy/packagereq packagereq type=defaultcheese/packagereq packagereq type=defaultcompiz-gnome/packagereq packagereq type=defaultdasher/packagereq -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On Fri, Aug 28, 2009 at 5:49 PM, drago01drag...@gmail.com wrote: On Fri, Aug 28, 2009 at 11:31 PM, Colin Walterswalt...@verbum.org wrote: Hi internets, I was looking at the current state of ABRT (I tested on F11). The core capturing seems to work well. In brief, I propose to apply the (attached) patch to comps-f12.xml.in. For upgrades, we'll need to add a Conflicts: bug-buddy, correct? No, you want Obsoletes: bug-buddy, so yum/anaconda will replace bug-buddy with abrt. Ok, thanks. Should then the current %package addon-kerneloops [...] Conflicts: kerneloops Also be changed to Obsoletes? -- 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, Aug 22, 2009 at 3:04 PM, Arjan van de Venar...@infradead.org wrote: 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. Do you see that as an inevitable consequence of the general purpose OS versus single-user mobile/embedded, or is it something where organizational or technological changes on one or both ends could turn the course towards divergence? I see a couple of different possible axes here: 1) Multi-user OS versus single-user mobile/embedded.: A *lot* of the stuff in the Fedora desktop stack both package wise and code wise is there to support multiple local users, like ConsoleKit and gdm (and to an extent PolicyKit), to how networking is setup in NetworkManager, etc. Clearly if we were to throw that out a lot of things would be significantly simpler and likely boot faster, but there's a large cost. 2) General purpose OS + release set versus targeted OS: Basically, do you block (or even slow) the release on a bug in say rsync or ocaml even if those things aren't dependencies of the UI or (any interesting) apps? 3) Backwards compatibility: The network scripts example you mentioned; remember that some things do depend on the way things work now, e.g. the virt-manager networking setup. There's also the system administrator training lost. 4) Minor infrastructural: The specbuilder example you gave is something I think Fedora would be interested in, but how applicable is it to the project? (I don't know, I'm asking) One thing that could answer a lot of my questions is; do you see Moblin as trending towards self-hosting from a developer perspective, or do you see it as depending on Linux distributions for that role? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 4:31 PM, Michel Salimmichael.silva...@gmail.com wrote: How much of the work done on online-desktop will be carried forward to this? In this context, the GNOME 3 shell will automatically track application usage data; more precisely, time spent with X focus in a window of the application, where application is defined as .desktop file. It's a bit away though. With nontrivial work this could be done for GNOME 2 as well (if someone was interested in porting the code, it lives in http://git.gnome.org/cgit/gnome-shell/tree/src/shell-app-monitor.c ). The current use of the data is just for shell-internal usage like sorting applications (in search results, session restart, etc.). If we wanted to use it as a basis for showing application popularity we'd need some way to opt-in to making your data public. My suggestion would be that we take the current Smolt screen in firstboot and turn it into a generic join Fedora Feedback page which turns on things like: * Smolt hardware profile * Sending of tracebacks to a crash collation server (for the love of all that is holy, not bugzilla) * Shell application usage data * Other stuff? In case anyone is feeling voyeuristic I've attached my current ~/.gnome2/shell/application_state file. application_state Description: Binary data -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 5:04 PM, Rahul Sundaramsunda...@fedoraproject.org wrote: fpaste, now a default package in Rawhide has a --sysinfo that collects a whole load of information that is commonly requested by people trying to help others in #fedora irc channel. Some of that available as part of a profile would be useful. Same output at http://fpaste.org/aU8r/ Yep, looks pretty useful. If we had a page in firstboot which turned on a cron script to HTTP POST that to a fedora infrastructure server, keyed off the smolt UUID on a weekly basis, I know I'd would opt in for sure, and I'm sure a lot of others would. The challenge here is to coherently explain to the user what's being sent, ensure privacy (you really don't want to send e.g. X window titles, and even process arguments can be sensitive). Also a challenge is that if you want to add something later you'd need some way to re-prompt the user which is kind of ugly. We should also probably restrict visibility of the data to aggregated only by default. -- 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, Aug 20, 2009 at 12:22 PM, Peter Robinsonpbrobin...@gmail.com wrote: Hi All, I would like to add a group for the Moblin Desktop. My proposed patch is below and feedback is welcome. Peter, thanks for all your work on packaging stuff, it's really great. I appreciate the work on introspection and gnome-shell a lot. Are you planning a Moblin spin? Or do see this as just having the packages in Fedora, and the final Moblin releases are done by that project? I'm a bit unsure of how far away Moblin is from the Fedora core OS right now; I know there's the NetworkManager/Connman split, but ignoring that, do you (or anyone) have an idea of how many patches to upstream projects they have to support the fast boot? How different is their early kernel boot, and what tradeoffs are involved? What we really do need is some more directed coordination between the two projects. -- 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, Aug 20, 2009 at 1:06 PM, Peter Robinsonpbrobin...@gmail.com wrote: Eventually I plan on having a moblin spin but not for F-12. The work in Fedora at the moment is separate to anything that is coming from Moblin. The advantage that Fedora will have that at the moment upstream Moblin doesn't support anything that isn't an Atom processor. So we should in the long term be able to support the older Celeron based Netbooks and possibly the VIA based ones or NVidia ones. Well, when talking about older hardware an important factor is to what extent the graphics chipset and driver can support the UI experience, not just the CPU. 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. The NM/connman is an interesting split. It seems suse is assisting the process from the build side of things but has written a NetworkManger moblin GUI that looks the same as the connman one sot they are interchangable. Obviously we'll use the NM one because NM is cool :-) Other than the 30 odd new packages needed for Moblin there doesn't seem to be massive convergence from the other core Fedora packages. Doesn't seem to be convergence? In fact there's some cross over for some of the gnome-shell stuff in that they use mutter and associated stuff. Right. We share quite a lot, but then again the devil's in the details as they say. From the rest of it AFAICT from the poking I've done they've replaced the standard init process with fastinit which I haven't even looked at. Its in their git repo though. Hmmm...Ok. I just typed up: https://fedoraproject.org/wiki/Moblin_Core_Merge Any help filling it in (especially from Moblin developers who may be lurking) would be appreciated! I'm particularly interested in how far we can get the default Fedora desktop's boot speed close to that of netbook experience, without breaking compatibility with any of the corner cases people expect from a general purposes OS like RAID. -- 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, Aug 20, 2009 at 2:46 PM, Adam Williamsonawill...@redhat.com wrote:
On Thu, 2009-08-20 at 13:37 -0400, Colin Walters wrote:
I'm particularly interested in how far we can get the default Fedora
desktop's boot speed close to that of netbook experience, without
breaking compatibility with any of the corner cases people expect from
a general purposes OS like RAID.
Mandriva went with a two-tier system for this: the fast init system
falls back to being slow when it runs into complex cases.
Sounds reasonable.
http://blog.crozat.net/2009/02/speedboot-explained.html
I know our boot speed guy has some plans to go in a similar direction
(he was telling me about this while we were preparing the F11 boot speed
test day).
The other thing I will say here is that it's very important for this
functionality[1] in particular to ensure we don't regress. It's
really easy for almost anything to come along (say, some new ISCSI
scanning, or a HAL probe or a font-scanner or...) and hit the boot
process and no one notices for quite a while.
Here's an example of the Ts test that Mozilla has which means
startup performance:
http://graphs.mozilla.org/graph.html#tests=[{%22test%22:%2216%22,%22branch%22:%221%22,%22machine%22:%2251%22}]
This comes from their Talos project: https://wiki.mozilla.org/StandaloneTalos
I'm not sure how difficult it is to set up. Now that we have nightly
livecd images though (thanks nirik all), that could be a useful
basis for something to feed into a Talos like system if it could be
run on infrastructure.
[1] Though this is of course true of a lot of other things like the
live CD size, logged-in desktop memory usage, etc.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Consistent PolicyKit system policy
On Mon, Aug 10, 2009 at 6:06 PM, Mathieu Bridon (bochecha)boche...@fedoraproject.org wrote: On Mon, Aug 10, 2009 at 15:42, Colin Walters wrote: On Mon, Aug 10, 2009 at 9:08 AM, Tim Waugh wrote: What is the goal of the default Fedora PolicyKit policy system-wide, and how can we check that PolicyKit mechanisms' default policies are adhering to it? Generally where I'd like to move to is where the RPM package defaults are appropriate for a shared computer lab PC, and the desktop spin kickstart modifies things as appropriate for the unmanaged home PC/laptop. I'm confused, does this mean that the desktop spin doesn't (or won't) use the RPM package defaults? Well, there are a variety of technical approaches; maybe instead the spin config is a desktop-spin-config RPM or something. But the point is that the CD downloaded from the website should be configured appropriately for unmanaged (or really self-managed) systems, but we need to be able to explain to administrators creating a managed desktop environment how to configure things. I think differentiating on RPM defaults versus spin config is a relatively clean way to do this, but other suggestions are welcome. If so, what about someone who install a « shared computer lab PC » using the desktop spin? After all, users of this « shared lab PC » need a desktop, so the admin could think the desktop spin is the most appropriate... Comps is the correct approach here; the GNOME Desktop Environment group is roughly equivalent to the spin, minus any customization. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Consistent PolicyKit system policy
On Tue, Aug 11, 2009 at 9:52 AM, Kevin Koflerkevin.kof...@chello.at wrote: Colin Walters wrote: Well, there are a variety of technical approaches; maybe instead the spin config is a desktop-spin-config RPM or something. But the point is that the CD downloaded from the website should be configured appropriately for unmanaged (or really self-managed) systems, but we need to be able to explain to administrators creating a managed desktop environment how to configure things. I think differentiating on RPM defaults versus spin config is a relatively clean way to do this, but other suggestions are welcome. That makes no sense. The default should be OK for all environments. And the current PackageKit setup works just fine for shared labs too. Well, we're mainly limping along with the root password approach, which is confusing for the unmanaged case. Things will become more different between the RPM config versus the desktop spin when that goes away. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Consistent PolicyKit system policy
On Mon, Aug 10, 2009 at 9:08 AM, Tim Waughtwa...@redhat.com wrote: What is the goal of the default Fedora PolicyKit policy system-wide, and how can we check that PolicyKit mechanisms' default policies are adhering to it? Generally where I'd like to move to is where the RPM package defaults are appropriate for a shared computer lab PC, and the desktop spin kickstart modifies things as appropriate for the unmanaged home PC/laptop. You could think of computer lab PC as very similar to the our heritage, the timesharing unix server case, except that it makes sense for say plugging in a USB key to do something useful. An example of something that would be different between the RPM package and desktop spin is the policy for software installation. In the RPM package it should be either none allowed or initiate updates only, whereas the desktop spin would allow clickthrough for arbitrary RPM installation. (This is mainly relevant in the future when we don't have a separate root password in important places in the UI flow). We don't do this at all now though =) For your particular case I think your current policy is the best we can do for all targets. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABI compliance checker
On Thu, Aug 6, 2009 at 10:35 AM, Andrey Ponomarenkosusa...@ispras.ru wrote: Hi, Colleagues, I'm software engineer from Institute for System Programing of Russian Academy of Sciences and we are developing a free lightweight tool for checking backward/forward binary compatibility of shared C/C++ libraries in OS Linux. It checks interface signatures and data type definitions in two library versions (headers and shared objects) and searches ABI changes that may lead to incompatibility. We have released 1.1 version of this tool and we'd like you to consider its usefulness for your project. This sounds very useful! Ideally, we would run this tool automatically for the OS core and ABI changes would require signoff of some sort, and unless absolutely necessary were reverted. Tools like this though are at their most effective when they catch changes upstream not long after they're committed, before downstreams have at some indeterminate time incremented integers in .spec files or equivalent to distribute the changes. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Wed, Aug 5, 2009 at 9:49 AM, Josephine Tannhäuserjosephine.tannhau...@googlemail.com wrote: Hi all. KDE 4.3 will come to F11 and F10. It's a cool thing. There aren't updates like this for Gnome. Why not? F10 with Gnome 2.26 sounds fine to me. Because a lot of GNOME works directly with (and depends on) the core OS., and we want a stable system. And really because we should rather invest effort in making sure that upgrades between major releases for the core OS and default desktop packages are nearly bulletproof, and in addition try to maintain a parallel-installable stable set of library packages for a set period of time. This would make it so that things outside the core are less likely to break due to core upgrades. I'm thinking concretely here of say a package like clutter which has switched 0.6 - 0.8 - 1.0 in the same clutter package is a bad idea once the core desktop depends on it, we'll need to parallel install. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Package Kit messages...
On Fri, Jul 31, 2009 at 3:43 PM, Richard Hugheshughsi...@gmail.com wrote: 2009/7/31 Nathanael Noblet nathan...@gnat.ca: But by 'log out' it really means reboot doesn't it? Not really. If you're running an old version of gimp, you can restart the process by logging out and logging back in, you don't have to reboot. PackageKit splits these up into about 5 categories, being: I just want to say this is great work, and was sorely needed. Do you know if there's anyone interested in working on installing updates before reboot/relogin? -- 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-07-31
On Sat, Aug 1, 2009 at 1:02 AM, Bastien Nocerabnoc...@redhat.com wrote: That's what Moblin does, and you can ask Peter Robinson how much of a pain it is. If we want to ask upstreams to do tarball releases, I don't see why we should be making assertions like that. It's only a pain because Fedora's infrastructure wasn't designed for it; instead it implements the world's least optimized and most painful revision control system of series-of-tarballs. If the infrastructure supported it directly, that would change the pain equation quite a bit. There is the detail that then you'd have to know how to run autogen.sh, but jhbuild already has that knowledge for a lot of the desktop core stack. Anyways this kind of thing can be incremental; just because infrastructure now supports pulling from git doesn't mean we'd need to have a field day editing .spec files to get everything to use it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Thu, Jul 30, 2009 at 12:00 PM, Doug Ledforddledf...@redhat.com wrote: Agree 1000%. As another kernel engineer that's done sound hardware amongst other things, if you want to duplicate hardware mixing in my CPU I'm going to toss you out on your ear. The amount of CPU PA wastes already drives me nuts. My CPU is intended for important things, like kernel compiles, not to be wasted unnecessarily on down mixing or up mixing an audio stream. So you personally own such hardware? It gets worse when you have a primary log in as yourself, and a secondary login for separate mail processing, and you want paplay to play a sound on certain emails, because it has to route the sound through pa means that if it even plays at all it plays rough and choppy Sound is hard; as I understand it this could be driver bugs, scheduling problems, etc. Lennart's done a lot of work on safely making the pulse process real-time, which you may or may not have yet. can't tell you how many times emails got delayed 12+ hours because they were waiting on paplay to finish playing a simple beep when they didn't own the console. Hmm...I'm confused about the setup here (why a secondary login for mail processing?) but that aside, probably paplay should have a --force option to avoid the delay. The reason pulse delays here is for things like music players where the target behavior is when you fast user switch, the music player app stops playing. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
On Thu, Jul 23, 2009 at 2:16 PM, Ahmed Kamalemail.ahmedka...@googlemail.com wrote: Hi, Here's a RFE for FireKit, a firewall desktop kit. The firewall is a longstanding messy problem, and I'm glad you're interested in tackling it. User Experience: === 1- Joe wants some help from his co-worker, he shares his Gnome desktop through vino. Vino kicks FireKit to ask Joe if he would like to open port 5900, and asks for a period of time. Joe selects yes, and chooses 30 minutes. FireKit instructs iptables to open that port, and waits for 30 mins. This doesn't make sense to me - if I enable user sharing, why should I have to enable it again? 2- Sally wants to share last night's photos with her team. She drops the photos in /var/www/html, and starts apache. There's gnome-user-share for this which would be easier out of the box. I don't think the desktop firewall scope should mix in support for Unix servers, i.e. anything that traditionally listens on a port 1024. Backing up a minute, in discussions among the desktop team and other people about this, one thing that came up as a specific problem with having no firewall at all was the public WiFi hotspot case. If for example I enable desktop sharing before leaving work, then head to the airport, and log on there to WiFi, you really don't want the desktop sharing still enabled. Nor likely do you want sshd. In most of the other cases I can think of though, the firewall is either a hindrance (trusted network at home or office), or pointless (connected via 3G modem). Which leads me to think that rather than being based on individual ports and time, we just need a nice way to globally toggle the firewall. And that could come down to marking networks as explicitly trusted in NetworkManager, say. So the user experience could be a bit more like this: 1) Joe is a salesperson who is visiting another company and connected to their public WiFi. He wants to enable desktop sharing so people not in the conference room can easily see his presentation. He goes into vino and selects sharing. Vino sends a dbus message to NetworkManager which says it's requesting a service. NetworkManager knows this network isn't yet trusted, and sends a message to nm-applet asking whether to make the network trusted or not. If the network transitions from untrusted to trusted, the firewall is disabled for the time he is connected to that network. This is a transient state - if Joe suspends his computer, shuts down, or connects to another network, the firewall goes back up. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
On Fri, Jul 24, 2009 at 11:39 AM, Adam Millermaxamill...@gmail.com wrote: Might we want to look at having firewall profiles such that different sets of rules can be applied based on environment? I'm uncomfortable to tying the solution for desktop sharing button doesn't actually work unless you run system-config-firewall to a profiles system for controlling individual ports based on network. Maybe the toggle under the hood is a profile and system-config-network knows about profiles, but I'm strongly against a big list of port numbers in the default UI flow. Also, is this planned to modify /etc/sysconfig/iptables and just restart the service or is the plan to take a FireStarter approach and be a substitute for /etc/sysconfig/iptables? I think that if you ever run system-config-firewall, you're a system administrator and that tool wins, and the desktop firewall toggle should be disabled. How exactly that's expressed in the config system I don't know. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
2009/7/24 Björn Persson bj...@xn--rombobjrn-67a.se: Colin Walters wrote: If for example I enable desktop sharing before leaving work, then head to the airport, and log on there to WiFi, you really don't want the desktop sharing still enabled. Nor likely do you want sshd. – Internal tech support, Randy Hacker speaking. – Hi Randy, Joe Salesman here. I'm at the airport. Something's wrong with my laptop. The screen just goes black when I try to start Open Office Impress. It worked fine yesterday. If I can't get it to work before I get to the customer's site I won't be able to show the presentation. – OK Joe, I'll SSH into your laptop and look at the logs. What's your current IP address? In this case, when the firewall is re-enabled, it would be enabled to whatever the system administrator has configured it to do. In other words if they added an explicit passthrough for port 22, that would continue to work. Joe might have file sharing enabled to share his documents with his colleagues in his own company, but just because Joe wants to let people see the presentation, that doesn't mean he wants anyone who might be connected to the customer's network to read all his documents. Hmm? How would they be able to read all his documents? In one known attack against the concept of trusted networks, an attacker configures his laptop to present itself as a WiFi access point and broadcast a large number of strategically chosen SSIDs. Then he sits down in a public place and waits for unsuspecting laptops to recognize the SSID of their home network and connect automatically. I believe NetworkManager's connection list is based on the pair of MAC address + SSID, not just SSID. Now yes, of course someone could discover the MAC and SSID of a particular access point at a company, then when a mobile worker goes to a coffee shop, fake being that network. But at this point we're getting into very targeted attacks. And I would argue that accepting this is a valid tradeoff versus the even more serious problem of people who disable the firewall to get things to work and then never re-enable it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
On Fri, Jul 24, 2009 at 1:35 PM, Colin Walterswalt...@verbum.org wrote: Joe might have file sharing enabled to share his documents with his colleagues in his own company, but just because Joe wants to let people see the presentation, that doesn't mean he wants anyone who might be connected to the customer's network to read all his documents. Hmm? How would they be able to read all his documents? Oh, I see what you're saying; if they enabled gnome-user-share to share documents at their main office. Hmm, yes. Ok, how about this - gnome-user-share and vino are by default tied to networks, rather than global. So instead of one global GConf key, they have per-network state stored either in /system/networking or based of some key in their own config. When the network changes, they adjust. If we do ship a firewall on by default, then yes we would need a way for these desktop apps to poke holes programatically. Which is kind of a mess...if Lennart wouldn't object too much maybe the code could live inside Avahi, since most of the things we want to enable are Avahi services. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Another thing to keep in mind that immediately post-installation there are going to be updates, which will at a minimum need desktop reset (fast reboot experience), or more likely system restart. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On Tue, Jul 14, 2009 at 7:38 AM, Douglas McClendondmc.fed...@filteredperception.org wrote: No, from a user experience perspective, a kexec 'warm' reboot is still a reboot. I could be wrong about that, or my interpretation of what kexec does (I've read about it often in LWN, but never knowingly used it). That's correct I believe, yes. If so, one way to describe the major benefit of my rebootless installer, is that you get to boot the livecd/usb environment, *then use it as such*, and at your option, desire, and convenience, decide to permanently install the LiveOS you have just been using and configuring, to disk. And of course when done, just pop out the livecd/usb, and your are done... and free to leave your system with a continuingly increasing uptime :) Wait, so it's persisting any changes you made to the target drive? That sounds quite cool actually, and I misunderstood the original post. Concretely with your change, if I've connected to a wireless network with NetworkManager, that would get saved in the target drive's configuration in gconf and be there next time I boot? I know with the live images one problem we have is that data can sort of randomly disappear if you're running close to the memory limit; if we go with your architecture we should probably special-case things like ~/.gconf so say the Firefox http disk cache doesn't blow away your wireless config. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non-blocking dbus server
On Fri, Jul 10, 2009 at 5:18 AM, Jiri Moskovcakjmosk...@redhat.com wrote: 3. when the work is finished send reply to the client - this is the part where I'm stuck, because I want to send the reply as return message to the matching method call, but the method call already returned when I started the thread. (So far I can achieve this by sending signal with return value as an argument, but I don't think this is a good solution). Your options are: 1) Method returns work item id, send a signal WorkDone with the id 2) Agent pattern, the server makes calls back to the client using its unique name. 3) Infinite timeouts on method calls is in dbus git master -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, Jul 2, 2009 at 9:30 AM, Colin Walterswalt...@verbum.org wrote: On Thu, Jul 2, 2009 at 9:20 AM, Peter Robinsonpbrobin...@gmail.com wrote: Interestingly with -ggdb it builds fine with out without -O0. That makes it a lot more likely to be a compiler flaw (though not guaranteed). Of course, it turns out this is very likely not a compiler flaw. Compiler authors everywhere are shocked I'm sure. See: http://bugzilla.gnome.org/show_bug.cgi?id=587823 And http://git.gnome.org/cgit/gobject-introspection/commit/?id=a1f5af4683b08892e87288ef4906782f4094703d -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, Jul 2, 2009 at 6:29 AM, Peter Robinsonpbrobin...@gmail.com wrote: Hi All, I've having some issues with a PPC64 build and was wondering if someone a bit more ppc savy could have a poke. A backtrace would be really useful here (remember to build with -ggdb -O0 for extra usefulness). The typelib code is fairly heavy on lowlevel C bit-twiddling so it's not unlikely this is an upstream issue. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, Jul 2, 2009 at 9:20 AM, Peter Robinsonpbrobin...@gmail.com wrote: Interestingly with -ggdb it builds fine with out without -O0. That makes it a lot more likely to be a compiler flaw (though not guaranteed). Does 'make check' pass in the source tree you built with -O0? A backtrace would still be great though. Try setting DEBUG=fcatch in the environment. Some day hopefully ABRT will come and do this transparently and automatically... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (A)synchronous file operations xdg-open
On Thu, Jul 2, 2009 at 2:30 PM, Jerry Jamesloganje...@gmail.com wrote: I am more and more of the opinion that xdg-open is simply the wrong tool for viewing/editing temporary files. It wasn't built for that use case, and the tools it invokes were not either. I think the easiest fix here is for the app not to delete the temporary file immediately after the helper exits. Just write it in $TMPDIR and let tempreaper come along and eat it later. -- 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 Fri, Jun 26, 2009 at 5:40 PM, Jesse Keatingjkeat...@redhat.com wrote: Looking even farther in the future to where we have AutoQA functioning, we can treat critical-path packages differently in the real rawhide. Packages outside of critical-path will have autoqa tests done on them in an informational only way, anything seen wrong will be alerted to the maintainer and they will fix it if/when they can. Packages within critical path that have autoqa failures can be prevented from entering the repo until somebody either fixes it and a build passes the tests, or a properly authorized account holder forces the build into the repo. Of course this is just a rough idea how it would work, we have to get autoqa working first. This all sounds pretty great. Is there more information on AutoQA other than the project here? https://fedorahosted.org/autoqa/ Where would the tests go? Inside the CVS branch directory for a package? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and malware, was: What I HATE about F11
On Thu, Jun 18, 2009 at 5:58 AM, Nils Philippsenn...@redhat.com wrote: On Tue, 2009-06-16 at 16:57 -0700, Adam Williamson wrote: Ve haf zer technology, already. :) it's just a case of adding code to more apps to take advantage of the awesomeness of PolicyKit, and I believe this is scheduled to happen. I still have one fairly serious gripe with PolicyKit: If one application acquires an authorization it automatically authorizes all other applications running on the same desktop -- and I think that is a potential attack vector for malware. I would really like it if PlicyKit would issue authorizations that are valid only for a specific application, i.e. a subject(==user)/tool/action (optional /object for bonus points?) combination instead of only subject/action. The point is here that PolicyKit is not a regression and does not open up any new security problems. It is a positive step forward because it gets us away from running entire GTK+ apps as uid 0, for example. Along with other benefits like giving a consistent story to admins about the interaction between the desktop and the system core. What you're asking for is not feasible without SELinux domains in play or a similar comprehensive approach. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Tue, Jun 9, 2009 at 11:22 AM, Kevin Koflerkevin.kof...@chello.at wrote:
Colin Walters wrote:
If such a thing were to be implemented it'd probably be good to use it
to clean out the wishlist in general, like handling %clean and even
%build automatically (e.g. if we see a configure script, just assume
to call %{configure}, see a Makefile, just assume to call make,
etc)
Uh, that will never work. Many configure scripts need options, even
makefiles can require options.
There are always exceptions. That doesn't mean one can't optimize for
the common case (and not just common, but what we want to push people
to do, which is consolidate build tools).
The makefile could also be autogenerated from an unknown build tool
Makefiles generated by e.g. automake have easily detectable patterns.
Try head Makefile.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Sat, Jun 6, 2009 at 6:01 AM, Panu Matilainenpmati...@laiskiainen.org wrote:
The hardest part is getting the design right the first time, there's no
changing an api that is exposed to packages.
It's definitely better to get things right the first time, but one
thing missing from the system now is any kind of versioning on the
macro API. It would seem fairly straightforward to have a global
SpecVersion: 2 type header that pulls in an updated set of macros
from a different directory.
If such a thing were to be implemented it'd probably be good to use it
to clean out the wishlist in general, like handling %clean and even
%build automatically (e.g. if we see a configure script, just assume
to call %{configure}, see a Makefile, just assume to call make,
etc)
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unowned files and directories
On Sat, May 23, 2009 at 1:46 PM, Thorsten Leemhuis fed...@leemhuis.info wrote: (¹) the list also leads to question like why are there /.dbus and /.pulse? My guess is some code in the installation process running as root with $HOME set to / is trying to connect to the DBus session bus. For compatibility with some unfortunate scenarios libdbus will attempt to auto-launch a bus using dbus-launch which will then create ~/.dbus. I assume pulse is similar (ideally pulse uses dbus, then we only have this bug once, but that's another discussion). Something trying to talk to the session bus sound familiar to anyone working on the installer? If we can set $HOME to /root that would sidestep most of the issues, alternatively in libdbus we could avoid autolaunching for root, since it should never be needed. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
