devel November 2009

devel@lists.stg.fedoraproject.org

330 participants
291 discussions

F12 install stops at screen switch (language select)
by Jos Vos 25 Nov '09

25 Nov '09

Hi, I had the crazy idea to try F12 again on an IBM system (SurePOS 565, specific Point-of-Sale hardware, with 82915G/GV/910GL), on which RHEL4 was the last RHEL/Fedora version I could install without problems (see also https://bugzilla.redhat.com/show_bug.cgi?id=339361 for some comments about RHEL5 on this system). Well, while graphics didn't work at some point in older releases (I don't remember which Fedora I tried last, maybe F9 or F10), now the install stops even earlier, just after: running /sbin/loader detecting hardware waiting for ... Then the screen blanks (instead of showing the language selection) and I can't do anything more than CTRL-ALT-DEL. Any suggestions? Thanks, -- -- Jos Vos <jos(a)xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204

5 8

Bug in python?
by Christoph Höger 25 Nov '09

25 Nov '09

Hi, while I was investigating an offlineimap bug, the following happened quite often: File "/usr/lib64/python2.6/threading.py", line 497, in __bootstrap self.__bootstrap_inner() File "/usr/lib64/python2.6/threading.py", line 575, in __bootstrap_inner self.__stop() File "/usr/lib64/python2.6/threading.py", line 586, in __stop self.__block.notify_all() File "/usr/lib64/python2.6/threading.py", line 289, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib64/python2.6/threading.py", line 277, in notify self._note("%s.notify(): no waiters", self) File "/usr/lib64/python2.6/threading.py", line 68, in _note current_thread().name, format) File "/usr/lib64/python2.6/threading.py", line 808, in currentThread return _DummyThread() File "/usr/lib64/python2.6/threading.py", line 788, in __init__ self._Thread__started.set() File "/usr/lib64/python2.6/threading.py", line 378, in set self.__cond.notify_all() File "/usr/lib64/python2.6/threading.py", line 289, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib64/python2.6/threading.py", line 277, in notify self._note("%s.notify(): no waiters", self) File "/usr/lib64/python2.6/threading.py", line 68, in _note current_thread().name, format) File "/usr/lib64/python2.6/threading.py", line 808, in currentThread return _DummyThread() File "/usr/lib64/python2.6/threading.py", line 788, in __init__ self._Thread__started.set() File "/usr/lib64/python2.6/threading.py", line 378, in set self.__cond.notify_all() File "/usr/lib64/python2.6/threading.py", line 289, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib64/python2.6/threading.py", line 277, in notify self._note("%s.notify(): no waiters", self) File "/usr/lib64/python2.6/threading.py", line 68, in _note current_thread().name, format) File "/usr/lib64/python2.6/threading.py", line 808, in currentThread return _DummyThread() File "/usr/lib64/python2.6/threading.py", line 788, in __init__ self._Thread__started.set() File "/usr/lib64/python2.6/threading.py", line 378, in set self.__cond.notify_all() File "/usr/lib64/python2.6/threading.py", line 289, in notifyAll .... Looks to me like calling _DummyThread() every time and then printing a debug output is a bad idea, right?

1 0

heads-up: Oracle db-4.8.24 in rawhide
by Jindrich Novy 25 Nov '09

25 Nov '09

Hi, this is a short announce that there is a new db4 in rawhide for a while now. Please modify your package accordingly and consider rebuild. Older db-4.7.25 is now moved to compat-db so no broken dependencies should occur. If your package uses the /usr/bin/db* utilities please consider immediate rebuild as these are not present in the compat-db package. Thanks, Jindrich -- Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/

2 1

Old/compat package naming
by Lubomir Rintel 24 Nov '09

24 Nov '09

Hi, Alexander pointed out that I was suggesting a wrong name for Saxon 9 package [1]. In fact there's a couple of packages in repositories now that violate the naming policy [2] in the very same way. Apart from wondering what does Devrim think about renaming the existing saxon package, I'm wondering what do others (especially the maintainers of those other packages) think about renaming their packages? [1] https://bugzilla.redhat.com/show_bug.cgi?id=532664#c7 [2] https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages… The affected packages are these: antlr 2.7.7-5.fc11 antlr3 3.1.1-7.fc11 automake 1.11-2.fc11 automake17 1.7.9-12 glib 1:1.2.10-32.fc11 glib2 2.20.5-1.fc11 gtk+ 1:1.2.10-68.fc11 gtk2 2.16.6-2.fc11 gtksourceview 1:1.8.5-6.fc11 gtksourceview2 2.6.2-1.fc11 junit 3.8.2-5.4.fc11 junit4 4.5-4.1.fc11 Regards, Lubo -- Flash is the Web2.0 version of blink and animated gifs. -- Stephen Smoogen

5 5

PackageKit policy: background and plans
by Owen Taylor 24 Nov '09

24 Nov '09

I wanted to provide an update to the list on the current thinking about the PackageKit policy issue from the perspective of the people working on the core desktop packages and on the desktop user experience. There was informal meeting earlier today with Richard Hughes, and myself, and a couple of people who could provide help with big-picture Fedora issues like Bill Nottingham and Jesse Keating, to try and figure out if there were obvious steps to take in the short term. Obviously there are lots and lots of people who care deeply about this, and there are discussions that need to continue, but with the delay in getting packages built, tested, and pushed out, we thought there were advantages to jump-starting things. If there was something obvious, then it made sense for the package maintainer (Richard) to just do it. I'm writing this mail somewhat by default: the people who really matter are the maintainers of the relevant packages, but Richard has gone to bed, and David Zeuthen and Matthias Clasen are on vacation this week. I'll try to reflect what they would say; much of it is certainly my own personal take on things instead. - Owen Where the Fedora 12 policy came from ==================================== In Fedora 9, 10, and 11, the first time a user tried to install a package from the Fedora repositories, they would be prompted for a root password, with a checkbox to remember that permission for the future. (Before Fedora 9, you had to enter the root password every time.) We weren't really fully happy with this; this was basically asking the user to construct their own security policy. And not only that, but do it dialog-by-dialog, permission-by-permission as they tried to set up their Fedora system and get on with their life. >From a more general perspective, the end effect of putting up a lot of dialogs: +-------------------------------+ | | | < A complicated explanation > | | | | Root password [ ] | | | | [ OK ] | +-------------------------------+ is that you are training users to blindly enter the root password and hit OK, *not* something that enhances the overall security of the system. There is an obvious better way to do this, which is to figure out what the appropriate roles are for the system: adminstrative users, non-adminstrative users, etc., and let the person maintaining system decide who gets what role. So, David Zeuthen did a major redesign of PolicyKit to move it from the old "remembered permissions" policy, to a model where users could be assigned different roles. See: https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.ht… For some more details about how it works. The idea was that the change in PolicyKit would be accompanied by a default set of roles, and a nice user interface for assigning users to roles. Unfortunately, with the constraints of time, it became clear that this all (and especially the GUI) wasn't going to be there for Fedora 12. So, PackageKit needed a fixed policy for all users. For each action (install signed packages, install unsigned packages, remove packages, etc.), it needed to allow, deny, or ask for the root password. Among the decisions Richard made was allowing all users to install signed packages from the Fedora repositories. This was clearly the right behavior for the common case of a single-user system, where the only user is also the administrator. And it seemed pretty safe: Fedora isn't supposed to have packages in it that are dangerous to install. (For example, by policy, all network services must be off by default and not enabled by simply installing a package.) The reaction (why that probably wasn't the best choice) ======================================================= There's obviously been a lot of feedback on this list and in other forums about this approach. And a lot of good points have brought up. Probably the most important one is a bit obvious in hindsight: Fedora is used on a wide variety of systems, and in some of those - like a shared home system with parents and young children, or like a computer lab system - there are some users who shouldn't be able to change what is installed on the system. Even if installing those packages isn't a security hole. The other thing that is clear from the discussion is that we didn't do nearly enough communication about the change. I think was partly because the changes *weren't* finished. A rewrite of PolicyKit wasn't a feature in itself; the feature would have been the accounts dialog, which we didn't do for Fedora 12. But clearly the changes we did do had some major impacts that needed to be advertised. And while there are great low-level docs with all the details about PolicyKit configuration (see polkit(8) for a starting point to the docs), we didn't have the simple instructions for changing basic system policy. Moving forward from here ======================== After talking things through a bit, the consensus was that we need to take a course that's conservative for Fedora 12. To do something that is safe for almost all uses of Fedora, if a bit less convenient. So, what Richard is planning is an update to PackageKit that changes the policy so that the root password will be required for package installation. We should have this out in fedora-updates quite soon; hopefully tomorrow. Once we get that out, we'll also make sure that there is documentation available about how you can configure some users to be able to install software without having to type the root password every time. In upcoming Fedora releases, we expect to finish both the default set of policy roles and the user interface components to provide the full experience that was originally planned. Executive summary ================= We'll make an update to the F12 PackageKit, so that the root password is required to install packages.

25 51

PolicyKit and syslog
by Matthew Miller 24 Nov '09

24 Nov '09

One of the important features of sudo is its ability to log elevated-access actions to syslog. Userhelper similarly logs actions, like so: "userhelper[26491]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'mattdm'". PolicyKit serves a similar function, but doesn't seem to log anything. In fact, the only use of syslog appears to be in polkit-agent-helper-1, which logs in two possible situations -- when called with the wrong number of arguments and when stdin is a tty. (Most other things it fprintfs to stderr.) I'm not bringing this up to complain -- I just want to make sure that I'm not missing something (which happens more often than it should; *sigh*). If I'm not missing something, is this something anyone is working on already or has existing plans for? -- Matthew Miller <mattdm(a)mattdm.org> Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences

3 14

Improve the way rpm decides what is newer
by Christian Iseli 24 Nov '09

24 Nov '09

Hi folks, I also got bitten by the "FC11 packages 'newer' than FC12" hickup, and while going through the yum remove/add maneuver I pondered: - is there ever a time when, while upgrading from Fedora n to Fedora n+1 I would expect a package .fcn to be kept instead of getting the .fcn+1 instance ? My answer was: no So I wondered if there would be a simple way to make this happen regardless of whether a maintainer blunders and gets things slightly out of sync between the 2 or 3 current Fedora releases. I did not find a real easy way, but one way which does not seem too hard to implement would be to introduce one additional tag in a package named something like VendorRelease. Then, given package A and B we could implement the "what is newer" comparison as follows: A.Vendor <=> B.Vendor || A.VendorRelease <=> B.VendorRelease || A.Epoch <=> B.Epoch || A.Version <=> B.Version || A.Release <=> B.Release The VendorRelease, Epoch, Version and Release would be implemented using the usual, current comparison method. The Vendor comparison would be taken from a config file, where the admin can decide what is the preferred Vendor tag. We might thus be able to solve the old dispute of having repotags by punting it into the hands of the user. If the user is happy to take newer versioned packages from some third party repo, he can just define both Vendors as equal in the config file. This would also allow getting rid of Epochs from one Fedora release to the next, since a newer VendorRelease would trump the non-null Epoch. I'm a bit afraid this might degenerate into another flame fest, but having slept on it I still think this idea has some merit. So putting on my asbestos underpants and waiting to see what will come out of this... Cheers, Christian

15 31

Re: Fedora 12 x86 DVD images
by Andre Robatino 24 Nov '09

24 Nov '09

Jesse Keating wrote: > Yes, we may rename the Live images to i386. When they were first > introduced, we had both an i586 and an i686 kernel in Fedora, and the > Live images were only usable on i686, they had no i586. Now that > we don't have i586 anymore, we can change the live image name > to i386. It was too late to do this for F12 at the time > somebody suggested it. That makes everything consistent, but creates the same user confusion for live images that presently exists for install images. Since uname isn't strictly adhered to even now, why not just change the install labels to i686 instead?

1 0

Re: Fedora 12 x86 DVD images
by Andre Robatino 24 Nov '09

24 Nov '09

Michael Cronenworth wrote: > Should there be a RFE bug or rel-eng ticket created so this > e-mail thread is not for nothing? It's been discussed since > the beginning of time AFAIK. There's already one: https://fedorahosted.org/rel-eng/ticket/2476 which was closed as "wontfix".

1 0

Re: Fedora 12 x86 DVD images
by Andre Robatino 24 Nov '09

24 Nov '09

Adam Williamson wrote: > it doesn't change the fact that, logically speaking, either the DVD or > CD images is wrong. Or at least, less right. I can see no sustainable > argument that they should be different. The same is true for the directory labels (i386/ for install images and i686/ for live images). BTW, the live image directory was originally i386/ in F7, and then changed to i686/ for F8 and later (although the ISO name was always i686).

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2009