ck-list-sessions shows active = false
by darrell pfeifer
Using rawhide and gdm-2.26.1-13.fc12.i586 when I do a ck-list-sessions I see
Session4:
unix-user = '500'
realname = 'darrell pfeifer'
seat = 'Seat5'
session-type = ''
active = FALSE
x11-display = ':0'
x11-display-device = ''
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2009-07-06T15:56:08.908744Z'
login-session-id = ''
Currently almost all my device-related functionality is not working
(including pulseaudio, mounting usb sticks, starting virtual machines). In
addition, polkit-gnome-authorization and polkit-gnome-authorization are
crashing.
Am I on the right track thinking that the problem is gdm related?
darrell
14 years, 10 months
Re: Feature proposal: Extended Life Cycle Support
by Ding Yi Chen
----- "John5342" <john5342(a)googlemail.com> wrote:
> > Firstly, not all people turn the automatic upgrade on.
> > Secondly, there are folks use rpm -hiv or build from srpm.
> > In that case, they are more likely to spot the bugs.
>
> I am not talking about upgrades. I am talking about updates. Most
> people just run updates when packagekit (or similar) tells them to.
> In
> a proper release updates are released together. In Denture they will
> be updated out of order and from various different releases. As for
> people rebuilding from srpms etc they represent a minority and it is
> in any case irrelevant.
What you said is true, but since what Denture is for unsupported
released, which is unlikely getting any updated. Your case is not suitable
for unsupported release.
> > If what you said is completely true, I would not even bother to
> propose Denture. :-)
>
> What i said is plain and simple fact. The scenario i mentioned is one
> of several points of failure. I am not suggesting it is a problem
> with Denture itself but it is a problem with the real world. Thats just
> life.
But the fact does not cover all packages, so that's why I need Denture,
and take the risk. That's also life. :-)
> This isn't about whether Y-1.3 will be pulled in. If you do what the
> vast majority of users do then you will get the equivelant of yum
> update. Regardless of whether X-1.3 explicitly specifies Y-1.3. Y-1.3
> will still be updated siply because there is a later version. When
> you
> update using Denture however you could easily end up with X-1.3 and
> Y-1.2 for any number of reasons.
Yes I could hit the bump, so are the guys that using source build and other distribution
which have not yet put Y-1.3 to their repos.
> > So do other package managers.
> > Tell me, why are you so sure that the current version packages
> > don't break the system secretly and user and the package managers
> > has no way of knowing until it is too late?
>
> If you read all i wrote then you will find that has been answered
> thoroughly already.
I also states my justification why the packages should
specify the exact depended versions.
> You have found the exceptions there. Try looking at some others.
I see. What I mainly need Denture help is for end-user applications.
I am not quite sure about using Denture for library or toolkit directly.
> I am sure even your dependency versions become stale. Taking your
> example of dvdauthor
> BuildRequires: libpng-devel
> BuildRequires: flex
> BuildRequires: bison
> BuildRequires: fribidi-devel
> BuildRequires: freetype-devel
> BuildRequires: GraphicsMagick-devel
> BuildRequires: autoconf automake gettext-devel
>
> In a single release you perhaps can be pretty sure that the versions
> in the build root are good enough to satisfy dvdauthor. If on the
> other hand you end up with a version of one of these packages from a
> previous release due to blacklisting then things may well start to
> break.
>
> Would you however insist that all of these are bugs?
Mmm,
BuildRequires: libdvdread-devel >= 0.9.4-4
BuildRequires: libxml2-devel >= 2.6.0
Without these, dvdauthor might break even within current release.
You were saying that version is not important? :-)
Nevertheless, you raise a valid point that version information
is sometime unavailable or unreliable.
But this can be overcome by a datafile that stores correct version.
> The result could be great but i can be pretty sure that the actually
> stability of a partially updated system is probably much worse than
> rawhide and people who are happy with that level of stability would
> ore than likely just prefer actual recent release
For people who requires absolute stable, they can just use CentOS/
RHEL and totally ignore Denture.
Denture is for the people that need to keep some critical packages,
but wouldn't mind to take some risk. :-)
> I like the idea because the concept is great. The idea that you can
> run whatever version of whatever package you want and get the best of
> all worlds is a nice dream but unfortunately i also know that it is
> only a dream and in real life it simply can't work because the huge
> requirements that Denture would place on packaging just can't be
> done.
"Whatever" is possibly the problem.
Denture only eats what it can eat. :-)
According to my experience, some of the dreams can come true.
> When i was working on my project i quickly realised that for the
> reasons i have been trying to explain (falling on deaf ears
> apparently).
Please don't assume that I am not aware your concerns.
Did you see my answers about them?
> I really wish you all the best. I really do. I would love to be
> surprised and see it work but i won't be holding my breath. Good
> luck!
Thanks!
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
14 years, 10 months
Re: Feature proposal: Extended Life Cycle Support
by Ding Yi Chen
----- "John5342" <john5342(a)googlemail.com> wrote:
> 2009/7/7 Ding-Yi Chen <dchen(a)redhat.com>:
> >
> > 於 二，2009-07-07 於 14:44 +0100，John5342 提到：
> >> 2009/7/7 Ding-Yi Chen <dchen(a)redhat.com>:
> >> >
> >> > Any comments?
> >>
> >> In theory your proposal sounds great but i see just one major flaw
> >> that probably doesn't have a solution. Your idea of packages being
> >> built based on dependencies should work great apart from the fact
> that
> >> most packages don't tend to have hard dependencies on versions.
> >> Hypothetically in F11 package X-1.2.X relies on package Y-1.2.
> Later
> >> in the release cycle Y-1.3 is released followed later by X-1.3.
> Eve
> >> though X-1.3 actually requires Y-1.3 the maintainer probably never
> >> thinks to update the required version (assuming there even was one
> in
> >> the first place). Now your system can easily fail. It picks X-1.3
> from
> >> F-11 (because thats the latest one) but Y-1.3 isn't allowed
> (because
> >> one of its dependencies is black listed) so it falls back to Y-1.2
> >> which was the latest in F-10. Everything builds fine because they
> are
> >> source compatible but Y-1.2 doesnt have a crucial bug fixed. Now
> your
> >> software is broken.
> >
> > All systems have bugs and may break. So you don't use any of them?
> :-)
>
> Of course all systems have bugs. However some are minor whilst others
> are so much work to make them usable that they are simply not worth
> it. Stuff that requires constant user intervention to cope with
> scenarios that cannot be automated is one such major issue.
>
> > The scenario you raised could happen if not so many people use the
> > package X. Otherwise, it would likely be spot by people who use
> > yum update X, as Y-1.3 is not dragged in.
> > Given X-1.3 is broken without Y-1.3, thus bug will likely be spot.
>
> Wouldn't be spotted until it is used in your system. It wouldn't be
> used during standard usage because in a normal release both would be
> updated at the same time (or at least in the right order) so the
> scenario never happens.
Firstly, not all people turn the automatic upgrade on.
Secondly, there are folks use rpm -hiv or build from srpm.
In that case, they are more likely to spot the bugs.
> > Well, Y depends on black-listed packages doesn't mean Y cannot be
> > upgraded at all. As long as the the newer Y does not require higher
> > version of black-listed packages.
>
> Of course Y can be updated but not necessarily to the required
> version. If the world was perfect all versions of packages would
> contain the exact versions required for things to work and your
> proposed system would either update fine or refuse to with a message
> if a dependency is blacklisted or unavailable as a recent enough
> version.
>
> However unfortunately for the same reasons i stated already virtually
> no package will state the dependant versions accurately enough to do
> what you want.
If what you said is completely true, I would not even bother to propose Denture. :-)
> > But if black-listed packages requires Y, or Y is black-listed,
> > then Y will not be upgraded.
> > In those cases, it is expected behavior that X should not be
> upgraded to
> > X-1.3 because Y cannot be upgraded to Y-1.3.
>
> That is of course assuming X-1.3 has an explicit dependency on Y-1.3.
> It would be lovely if all packages has these versioned dependencies
> and a lot have automatically due to things like sonames but take the
> scenario where the soname is the same but the presence of the bug is
> not.
If X-1.3 does not specify Y-1.3 as dependency, I don't think
yum update X will pull Y-1.3, even with the current version.
Not to mention people who use rpm directly or build from srpm.
So please file bug to X, don't blame Denture.
> > Yes, you find out the limitation of Denture, but no,
> > Denture is not broken. :-)
>
> Denture is not broken. Unfortunately though Denture only works in the
> ideal world. In reality though scenarios like i just mentioned happen
> all the time (along with many other similar issues) and the scenario
> i
> mentioned would break the users system and Denture has no way of
> knowing until it is too late.
So do other package managers.
Tell me, why are you so sure that the current version packages
don't break the system secretly and user and the package managers
has no way of knowing until it is too late?
>
> >> Believe it or not i actually tried something similar for some of
> my
> >> internal servers and i like the idea but its impossible to get the
> >> dependencies right which makes the whole idea a no go.
> >
> > Believe it or not I actually tried something similar,
> > but by hand though.
> >
> > I agree some maintainers does not accurately specify the
> dependency.
> > but it is not beyond fix.
>
> It is not some. It is more like most. How many packages do you see
> with the following for every single requires and build requires:
> BuildRequires: X-devel = X.X.X-X
> Requires: X = X.X.X-X
After a quick peek of the packages I maintain or am interested in:
7 packages provide the version info of each dependency.
5 packages provide the version info for some critical package (see dvdauthor.spec for example).
5 packages does not specified it at all. 3 of which are man-pages :-)
Only 15% of the packages (exclude the man-pages) does not provide any version information.
It may show the laziness of upstream or maintainer, but most of the case,
it's meant to work with older version.
> And packagers shouldnt have to.
What? Why? Does it logical to expect a stable system if
critical dependency information is missing?
> apart from anything else it would
> mean
> that every single time somebody rebuilds a package all packages that
> depend on it would need rebuilding even if the update is binary
> compatible yet at the same time the only way to stop the scenario i
> mentioned from happening is to do exactly that.
Yes, but let the computer to the rebuilding while you enjoy the result. :-)
Is a rebuilding bad thing? According to my FreeBSD experience, not at all.
> During a normal release bugs are easily spotted and fixed and
> scenarios like i mentioned will mostly never even happen anyway but
> mixing packages from different releases will potentially create an
> infinite number of combinations and almost certainly break.
If this is true, then Denture can happily live with it.
Almost certainly break? You mentioned that
you did have similar system, if it almost certainly break,
how come you still like the idea?
BTW, mind sharing your program? :-)
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
14 years, 10 months
Re: Feature proposal: Extended Life Cycle Support
by Ding Yi Chen
----- "John5342" <john5342(a)googlemail.com> wrote:
> 2009/7/8 Ding Yi Chen <dchen(a)redhat.com>:
> >
> I don't think this has anything to do with motivation. You have an
> idea and on the face of it it sounds great but even the greatest
> ideas
> can be doomed by the details. If you don't believe me (or Kevin) then
> go for it and when you get to the details you will see exactly what
> we
> are talking about. We are simply trying to save you the time.
You have good deed. But it does not help by simply saying everything break.
As I do have some example to break your claim. :-)
I would like to know, specifically, what packages did you tried
and optionally, why did they fail?
> And if you develop ad-hoc logic (which i had too) which is required
> for it to come even close to working then who is going to maintain
> the
> data that drives this ad-hoc logic? If you think the users will then
> you are likely wrong because the same people who are capable of
> helping with this will find it less effort just to use the latest
> release and build some compatibility packages for the older stuff.
If nobody is willing to provide sufficient data for the ad-hoc logic,
then those packages should be black-listed.
> First of all that largely wouldnt be possible for your proposal. You
> also cant account for differences between releases (different
> releases
> can have the same version but entirely different features and
> dependencies).
I actually encountered the dependency issue you stated.
but I've solved that before, and I don't think it is impossible to convert
my steps to code.
> Also minimum versions probably aren't enough. You would
> also need maximum versions to make your proposal work.
I've consider that (thus the data file that keep the "correct" dependency),
but thanks anyway.
You may asked how this data file be generated.
Well, at infant stage, it needs to be filled by the early adopters
who crush into bugs. You are free to join the data file building.
Don't use Denture if you are uncomfortable with that.
> You clearly don't know how many ways a package can fail. There are a
> lot of subtle advantages provided by the flow of updates during a
> release but Denture will be completely and utterly outside those
> comfortable walls.
Package fails in old releases and current releases. But it's not end of world.
Either file bug reports, fix it yourself, find alternative ones that do the same
thing, or live with it.
Given it's experimental nature, don't use Denture on the packages that is critical
to your life, job or other thing you value much.
Use Denture on the packages that, "It's good to have, but can live without it."
Perhaps that's why I haven't yet got bitten by extra bugs.
> If you really want a run down of some of the issues you will run into
> i can provide although i don't think the list is the place for them.
Please mail me the issues that you encountered. Appreciated.
>
> I can also tell you the far simpler and more effective solution i
> came
> up with for your use case. It is also a frankly much more efficient
> use of the time. Instead create a program to generate side by side
> installable packages. Then you can use the latest release with all
> its
> features but your old programs that works better on an older Fedora
> has all the libs it needs to run. The whole concept is more
> efficient,
> easier to test, less likely to break systems, less dependent on the
> user, the type of user in your use case could deal with it more
> easily, etc and it also covers most of your use cases on your blog.
I am interested in what you said, what do you mean "side by side"?
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
14 years, 10 months
EPEL Bug Day July 11, 2009 0-23:59 UTC
by Michael Stahnke
EPEL bug day is fast approaching and we are looking for your help. This is a
chance to get involved with EPEL and help make the overall product a little
better.
Goal: Reduce or update bugs from EPEL.
Strategy: The vast majority of EPEL bugs have been classified loosely into
three categories.
* ActualBug -- A real bug, often times with upstream software issues, or
perhaps packaging dependencies. To triage, see if you can reproduce, ask for
more input, and in general see what can be done to fix it.
* PackageBranch -- This is a request to get something into EPEL that currently
isn't there. To triage, see if the package has been branched in CVS. Perhaps
the maintainer simply hasn't built it yet. Or, if it requires dependencies,
contact the maintainer for those dependencies, open another bug, and create the
proper relationship between them.
* UpdatePackage -- Requests to update packages can be difficult in EPEL, but
each should be evaluated. Ask for reasons why the update is required (security
is an extremely valid reason). Sometimes the old version is no longer
maintained upstream, etc. Keep in mind that updates that cause breakage should
at least be mentioned on the epel-announce mailing list.
Feel free to take a bug and help out. It's a 24 hour event, and we have about
135 bugs. If we can get 6 bugs an hour triage and updated, that would be all of
them.
Event coordination and collaboration will occur in #epel on irc.freenode.net.
(Also you don't have to wait until July 11 to start)
More Information:
* https://fedoraproject.org/wiki/EPEL_Bug_Day_July_2009
Current Bug List
* http://tr.im/epelbugs
14 years, 10 months
Re: an update to automake-1.11?
by Sam Varshavchik
Kevin Kofler writes:
> Sam Varshavchik wrote:
>> That's great, and if this discussion was about cmake, then this would be a
>> valid point. But, this thread is not about cmake.
>
> That CMake has this feature implies that the autotools suck for not having
> it and forcing you to patch the configure script for your usecase.
Indeed. Here's an idea -- why don't you mass mail the maintainers of all the
autotools-using projects you can find on Sourceforge, and be sure to tell
them how much autotools suck, and how better CMake is. I'm sure they will
appreciate your helpful suggestions.
14 years, 10 months
Re: Do we need split media CDs for F12?
by Robert 'Bob' Jensen
----- "Jesse Keating" <jkeating(a)redhat.com> wrote:
> And this is what pisses me off, and why I say you're holding us
> hostage.
> Whether or not it is a good idea to continue to produce them, you
> don't
> care, you're just going to do it anyway. Great way to run a project.
>
Jesse,
Both Fedora Project and Fedora Unity have users that want, need or download in error CD media. The simple difference in the future of CD media is that we, Fedora Unity, are choosing to not remove the users freedom of choice. Giving users freedom of choice is how we run our project. We have faith that Fedora Project will do what it feels is best for it's contributors and resources. Independent of what Fedora Project does we also will do what we feel is best for our users and also keep in mind our resources. No one should feel they are being held hostage. Without the hard work Fedora Project puts in to a release and the subsequent updates Fedora Unity could not produce any media. I feel it is in our best interest to work together to resolve issues, I have always felt this way, unfortunately history has shown that this is not often possible. I keep hoping it will someday happen.
- Bob
------------------------------------------------------------------------
| Robert 'Bob' Jensen || Fedora Unity Founder |
| bob(a)fedoraunity.org || http://fedoraunity.org/ |
| http://bjensen.fedorapeople.org/ |
| http://blogs.fedoraunity.org/bobjensen |
------------------------------------------------------------------------
14 years, 10 months
