In F16 and rawhide the PackageKit koji build is failing with This
file was generated using the moc from 4.7.2. It cannot be used with
the include files from this version of Qt. (The moc has changed too
much.) when it gets to building the PackageKit-qt library.
See
On 1 August 2011 15:24, Jaroslav Reznik jrez...@redhat.com wrote:
It's not very good idea to ship pre-generated moc files, better to
autogenerate them during the build-time. PackageKit is using automake,
so it's a little bit more difficult but possible, check for example [1].
Right, I *think*
On 2 August 2011 14:54, Laurent Rineau
laurent.rineau__fed...@normalesup.org wrote:
Yes. MOC files are generated files like .o files. The difference is that it is
generated *source* files. MOC files are with a version of Qt is not guaranted
to be usable with another one x.y.z, even if only the
On 19 August 2011 13:35, Steve Grubb sgr...@redhat.com wrote:
All security guidance says turn off or get rid of avahi. We really don't want
to
require it just to print.
Then security is flying in the face of usability.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
On 23 August 2011 01:32, Lennart Poettering mzerq...@0pointer.de wrote:
This is something we should
set for a number of services which never should get network access, like
upower, dbus, or colord.
As the upstream for two of those, what do I need to do? At the moment
both upower and colord are
On 23 August 2011 12:01, Lennart Poettering mzerq...@0pointer.de wrote:
I'll blog about it and use colord as an example. I'll ping you when I
have done that.
Legend, thanks.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 24 August 2011 01:35, JB jb.1234a...@gmail.com wrote:
...do not expect them to accept your sick world domination drive
...and this is why some upstream developers have unsubscribed from
fedora-devel list. Ever wonder why people like David Zeuthen
unsubscribed? People like you.
I'm also ---
Not really a big problem, but I got this in my daily updates check:
(zif:836): Zif-WARNING **: found multiple provides for perl(DynaLoader) ~ :
(zif:836): Zif-WARNING **:
1. perl-ExtUtils-MakeMaker-6.57.5-187.fc16.noarch (updates-testing)
(zif:836): Zif-WARNING **: 2.
On 7 September 2011 16:31, Jesse Keating jkeat...@j2solutions.net wrote:
It is intentional that both the base perl package and the split off package
provide the same things, they are expecting n-v-r ordering to sort it out.
Sure, but I couldn't see why something that is involved with creating
On 7 September 2011 01:02, Adam Williamson awill...@redhat.com wrote:
Is this a Bodhi bug? Or does FESCo expect voluntary compliance /
case-by-case enforcement of this policy?
I'm guilty of this too; when I file an update that's not getting
enough karma (after a few weeks) then I give it a spin
On 8 September 2011 05:03, Joachim Backes joachim.bac...@rhrk.uni-kl.de wrote:
gnome-tweak-tool
Current, high level.
gconf-editor
Legacy.
dconf-editor
Current, low level.
gconftool-2
Legacy.
gnome-session-properties
Kinda current.
Richard
--
devel mailing list
On 8 September 2011 03:13, Andre Robatino robat...@fedoraproject.org wrote:
If a packager repeatedly submits +1 for updates which turn out later couldn't
possibly have worked in actual testing, then their karma privileges could be
revoked.
Makes sense to me.
Richard.
--
devel mailing list
I'm intending to build a new version of libmash in rawhide. The only
user I'm aware of is gnome-color-manager, which I'll also also
rebuild.
Thanks,
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 16 September 2011 18:43, seth vidal skvi...@fedoraproject.org wrote:
having different tools is not acceptable. Especially when one of them is
not even remotely covering the use cases of our actual users.
Installing 205 new i686 packages when updating the system is not acceptable.
I think
2011/9/16 Miloslav Trmač m...@volny.cz:
How about the 1126 members of the packager group - i.e. most of us -
that would have to create and maintain packages compatible with two
different systems?
That's nonsense, sorry. Zif is quite capable of using the same
metadata as yum and performing the
On 16 September 2011 20:07, Jef Spaleta jspal...@gmail.com wrote:
A methodology I could use to then verify suboptimal performance of any number
of depsolving policies for myself in my own testing.
This is what I've come up with already:
On 16 September 2011 20:02, Richard W.M. Jones rjo...@redhat.com wrote:
Is Zif a SAT solver?
No, but I've been playing a few times with libsatsolver in the past year or so.
We could really use a SAT solver to replace the current yum depsolver.
SAT is pretty awesome, and there are some pretty
On 16 September 2011 20:32, Jef Spaleta jspal...@gmail.com wrote:
local: the package installed
Yup, the installed store.
remote: the available provider(s) that satify the transaction requirements?
The packages available in remote stores.
transaction: command performed
Yup.
config: system
On 16 September 2011 20:46, Jef Spaleta jspal...@gmail.com wrote:
Are you sure you didn't cut it down so much that you are hiding problems
that your depsolving rules don't solve well? Did you throw out someone's
baby with all that bathwater?
Perhaps I did; the tests were made intentionally
On 17 September 2011 02:36, Kevin Kofler kevin.kof...@chello.at wrote:
So you came up with this really complex heuristic in a vain attempt to
always do the right thing without requiring changes to the packages, and now
it does a completely wrong thing which would be straightforward to avoid,
On 17 September 2011 10:38, Richard W.M. Jones rjo...@redhat.com wrote:
Yeah, it looks possible.
The very fact that you're exposing a C API and a library is a
promising start, even if it didn't yet do specifically what I needed.
Would it be easier if I provided a GIR file so you can just use
On 17 September 2011 11:05, Richard W.M. Jones rjo...@redhat.com wrote:
I don't mind as long as it's callable from other languages (either
using generated bindings like GIR or using hand written bindings).
I've just pushed:
commit 4132eb5a40e1a6a85358e96f7adfd3cf56e8ef3f
Author: Richard Hughes
On 17 September 2011 11:59, Rahul Sundaram methe...@gmail.com wrote:
I think zif needs to be command line compatible and support delta RPMs
The former should work pretty well. If I've missed any obvious aliases
yell and I'll add them. The latter is 80% implemented, but I don't use
delta-rpms
On 17 September 2011 13:56, Kevin Kofler kevin.kof...@chello.at wrote:
Richard Hughes wrote:
And Python too, I suppose?
Sure. I'd welcome any python dudes to write a small program in
examples/ just to test if the GIR annotations are complete enough.
Richard.
--
devel mailing list
devel
On 17 September 2011 23:06, Jef Spaleta jspal...@gmail.com wrote:
zif as packaged in F15 is returning with
Zif in F15 is a really old version, and F16 is the first release where
I'm going to support zif. The latest upstream release is 0.2.3 and I
think the version in F15 is much older than that
On 18 September 2011 19:22, Panu Matilainen pmati...@laiskiainen.org wrote:
I'm talking about means of having all the rpm-related tools use the same
abstract dependency resolution algorithm though an API. Whether that is
/in/ rpm, or something that rpm itself /uses/ (and possibly further
On 19 September 2011 01:46, Kevin Kofler kevin.kof...@chello.at wrote:
Well, looks like we also need a rebuild of PackageKit-zif against the new
soname (libzif.so.3, the package in F15 is built against libzif.so.2), so I
think the repo is the best solution if we want people to be able to test
On 19 September 2011 17:41, Jef Spaleta jspal...@gmail.com wrote:
I've installed this zif from koji and I'm still not able to complete a zif
install paprefs transaction with realworld F15 configured public repository
set, whereas all the yum based tools: yum. repoquery etc... complete as
On 1 October 2011 12:02, Hans de Goede hdego...@redhat.com wrote:
I would like to suggest to change the default power policy to never suspend
while on AC power.
That's what it was supposed to be, but due to an oversight on my part
the wrong keys were being set. I've fixed this upstream in
On 3 October 2011 08:57, Richard Hughes hughsi...@gmail.com wrote:
That's what it was supposed to be, but due to an oversight on my part
the wrong keys were being set. I've fixed this upstream in
https://bugzilla.gnome.org/show_bug.cgi?id=660395 -- which will of
course be included in 3.2.1
On 12 October 2011 17:44, Kevin Fenzi ke...@scrye.com wrote:
All existing users of the Fedora Account System (FAS) at
https://admin.fedoraproject.org/accounts are required to change their
password and upload a NEW ssh public key before 2011-11-30.
I have to upload a *new* public key? Why
On 16 October 2011 19:00, JB jb.1234a...@gmail.com wrote:
pk-command-not-found [OPTION...]
We fixed this quite a long time ago. Perhaps upgrading to F15 or F16
might be a good idea?
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
2011/11/7 Michał Piotrowski mkkp...@gmail.com:
Out of curiosity I wanted to ask, why do I need colord on my system?
Checkout http://www.freedesktop.org/software/colord/ for details about
the project.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
On 25 November 2011 23:31, Rex Dieter rdie...@math.unl.edu wrote:
These? app-install (and friends) still pending review it seems,
https://bugzilla.redhat.com/show_bug.cgi?id=488962
https://bugzilla.redhat.com/show_bug.cgi?id=488968
If the objections truly have been dropped, I'd be happy to
-desktop if it's really important.
Thanks.
Richard Hughes
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 19 August 2010 16:46, seth vidal skvi...@fedoraproject.org wrote:
Yesterday someone was talking about installing apps in fedora and how it
was hard to figure out what to install/try b/c there were too much STUFF
in fedora. They suggested an ‘app store’ like functionality. I explained
that
On 29 August 2010 15:07, seth vidal skvi...@fedoraproject.org wrote:
I realized after this that I don't even need it the pkgTags db that we
already generate has the information needed b/c all the apps are tagged
with 'Application'. So no separate program is needed to generate the app
metadata
Linux has traditionally shown the user packages to update and install,
which is great for administrators, but sucks hard for end users. How
many times have you been prompted with an update list that asks you to
decide whether to update something you have no idea about[1]?
Mo illustrated[2] a few
On 7 September 2010 12:57, Rahul Sundaram methe...@gmail.com wrote:
Thoughts on making the software center less distro specific? Couldn't
the UI be grafted on top of the PK api?
app-install is completely distro-neutral. GNOME PackageKit and
KPackageKit get the same kind of data from
2010/9/7 Miloslav Trmač m...@volny.cz:
Um, do I understand this correctly that e.g. a kernel update usually
won't get installed because it belongs in system infrastructure and
few packages depend on kernel?
By default, all updates will be selected, even those in the system
infrastructure
On 7 September 2010 14:11, seth vidal skvi...@fedoraproject.org wrote:
okay - I'll bite - why do we want to make it less distro-specific?
For the same reason as pirut and pup were replaced. Fedora is *not* a
big enough ecosystem to drive fully localized and feature rich user
experiences. Working
On 7 September 2010 14:39, seth vidal skvi...@fedoraproject.org wrote:
Except we don't seem to do that. Over half of all commits to PK are from
you. The next closest committer has 6% of commits. If I exclude the
backends and translations then PK is written almost exclusively by you.
I'm not
On 7 September 2010 15:23, James Antill ja...@fedoraproject.org wrote:
Are you having any discussions about applications like postfix, or is
version 2 going to be just GUI stuff?
Postfix is not an application. Applications have translated desktop
files and icons.
I assume you have a plan
On 7 September 2010 17:20, Nicolas Mailhot nicolas.mail...@laposte.net wrote:
??? This was done 100% Fedora-side (not that I mind if it were adopted
by other distros)
Incorrect. It was done on the Fedora transifex instance, but I know
from fact that a few of the translators are from other
On 7 September 2010 17:32, Matthias Clasen mcla...@redhat.com wrote:
And BTW a request at the time was to extend it with font previews to get
a font store (because for fonts, gfx preview is really relevant and
not eye candy) and it never happened :(
If you send a patch it might !
A patch
On 8 September 2010 13:16, Adam Williamson awill...@redhat.com wrote:
First off, I think this is a great idea and very much needed, thanks for
working on it.
Cool, thanks. Some positive feedback at last! Too... much... stop... energy...
On the cross-distro front, is Canonical / Ubuntu
On 9 September 2010 09:52, Nicolas Mailhot nicolas.mail...@laposte.net wrote:
It needs works both packagekit-side and font packaging side, but there is
absolutely no way I'm going to expand energy on pushing the packaging changes
through FPC other font packagers if there is no buy-in
On 13 September 2010 08:36, Hans de Goede hdego...@redhat.com wrote:
But Adam is not the only one I love this idea too! And I would like to
think there are other silent admirers of this idea too!
Cool, thanks.
I've even considered taken the review for the app data package and approving
it,
On 13 September 2010 21:49, James Antill ja...@fedoraproject.org wrote:
So Seth spent half a day implementing a proof of concept:
http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/
Translations?
Icons?
Offline queries?
Co-operating with other distros?
Formal database
On 13 September 2010 20:42, Kevin Fenzi ke...@scrye.com wrote:
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic.
Could
On 14 September 2010 23:01, Kevin Fenzi ke...@scrye.com wrote:
21:33:35 nirik The other 2 items I had were:
21:33:56 nirik application installer issues
21:33:57 nirik https://bugzilla.redhat.com/show_bug.cgi?id=488968
21:34:04 nirik and
21:34:05 nirik BuildIdBuild infrastructure
21:34:06
On 16 September 2010 09:57, drago01 drag...@gmail.com wrote:
Lets say we ever want to implement this
https://bugzilla.gnome.org/show_bug.cgi?id=612628 (or any similar
feature in another upstream project)
without a cross distro way to get the application data (icons, names,
etc. ) it would be
On 16 September 2010 20:05, Colin Walters walt...@verbum.org wrote:
Personally I'd much prefer some nice asynchronous GObject API
somewhere for this, rather than parsing SQLite directly. PackageKit
seems like as good a place as any for this.
app-install in git master has a GObject library,
On 17 September 2010 08:01, FlorianFesti ffe...@redhat.com wrote:
Can someone please elaborate a bit what pieces of information are really
needed? The .desktop files as a whole?
Information we use in app-install:
TABLE translations:
STRING application_id Name of the desktop file, with no
On 17 September 2010 13:36, Arthur Pemberton pem...@gmail.com wrote:
Wouldn't that require the tool to download every package just to get
the embedded information.
Yes, that's what my generator tool does. Of course, it only downloads
the packages that contain .desktop files (which we can tell
On 17 September 2010 15:28, Bill Nottingham nott...@redhat.com wrote:
Not if it's provided in the RPM header in a way where it can be easily
stuffed into the metadata or a similar place.
Bear in mind: 'n' applications per package, where 'n' can be a large
number. This means you have to come up
On 23 September 2010 08:37, drago01 drag...@gmail.com wrote:
Well this cycle there was on the way to gnome3 and back situation,
which caused a lot of churn (even upstream).
For what it's worth, the GNOME will we, won't we on a few different
issues (GApplication, GTK3, etc) has cost a lot of
All three of my newly released GNOME 2.32.0 projects failed to build
on koji (f14) today:
http://koji.fedoraproject.org/koji/getfile?taskID=2491737name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=2491754name=build.log
On 27 September 2010 19:58, Jaroslav Skarvada jskar...@redhat.com wrote:
The character class must be inside bracketed expression, thus double
brackets, please see man grep. The new grep-2.7 checks for this common fault:
Right, but you could argue it's a regression as the behavior changed.
On 27 September 2010 21:04, Jesse Keating jkeat...@j2solutions.net wrote:
Unless this change was made in f14. That is not acceptable for f14 at this
stage.
I'm using dist-f14.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 28 September 2010 18:06, Kevin Kofler kevin.kof...@chello.at wrote:
Bill Nottingham wrote:
Exactly... this is way late to be introducing this into Fedora 14. Any
reason it can't be held for F15? (Bug filed to this effect.)
The old behavior of that expression is not what the code probably
Could someone please review this package please:
https://bugzilla.redhat.com/show_bug.cgi?id=631763
I need it as a dependency in the next version of PackageKit. I can
bribe with beer if required. Thanks.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
On 1 October 2010 13:24, Michal Schmidt mschm...@redhat.com wrote:
I've taken it for review.
Thanks dude.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 2 October 2010 09:51, Richard W.M. Jones rjo...@redhat.com wrote:
..., then (sometimes, not always) displays some sort of
error[1].
Yes, it's fixed upstream, apologies. There's a new release on Monday
which will be pushed to F14.
Richard
--
devel mailing list
devel@lists.fedoraproject.org
On 4 October 2010 11:32, Jaroslav Skarvada jskar...@redhat.com wrote:
You can force grep-2.7 to silently process it (above mentioned way, same as
with older greps) by setting POSIXLY_CORRECT
environment variable. But all such REs are probably typos
Dude, that's so not the point. I have a f14
On 5 October 2010 05:30, Orion Poplawski or...@cora.nwra.com wrote:
Are we really stuck with gdm/kdm/lxdm/...dm
implementing it?
No, I think what we need to do is to teach GPM how to turn off the
internal panel when docked and with the lid closed. The only missing
piece is for the kernel to
On 5 October 2010 09:55, FlorianFesti ffe...@redhat.com wrote:
Sorry for my may be naive question: Why do we need to know if we are
docked or not. Isn't there exactly the same situation if the external
Monitor is directly connected to the laptop? If there is an external
monitor and the lid is
On 2 October 2010 11:23, Richard Hughes hughsi...@gmail.com wrote:
On 2 October 2010 09:51, Richard W.M. Jones rjo...@redhat.com wrote:
..., then (sometimes, not always) displays some sort of
error[1].
Yes, it's fixed upstream, apologies. There's a new release on Monday
which will be pushed
On 5 October 2010 15:51, Brandon Lozza bran...@pwnage.ca wrote:
It really wouldn't be a fork at all. From what I can tell it's a build
flag that can be enabled or disabled and automatically takes out the
trademark and copyright artwork. People just don't want to remove the
branding because
On 5 October 2012 16:19, Jiri Eischmann eischm...@redhat.com wrote:
1) Software Center based on PackageKit by Matthias
2) Light Software Center - a new app based on PackageKit from the
beginning
3) Apper already supports AppStream [2]
Basically, Fedora needs to ship Appstream metadata and
On 16 October 2012 15:11, Kalev Lember kalevlem...@gmail.com wrote:
If anybody wants to add builds to the GNOME 3.6.1 update, now is the
time to do it. Like usual, please use the spreadsheet:
Cheers for doing this. I'm off until next week on paternity leave, so
I really appreciate you wrangling
On 30 October 2012 18:45, Adam Williamson awill...@redhat.com wrote:
so if were to try and switch back to oldui at
this point, we'd have to go through the whole process of adjusting the
code for the changes to dracut again, quite apart from any other issues.
I don't understand how fixing up
In https://fedoraproject.org/wiki/Features/OfflineSystemUpdates we've
implemented doing the package updates at first-boot time. This makes a
lot of the hard-to-fix problems a lot easier. The question then
becomes, how do we make the OS Update process even smarter? A simple
check would be to see if
On 14 November 2012 16:27, Bill Nottingham nott...@redhat.com wrote:
If you're using the yum backend, it already has support for this
via a plugin.
Yes, I'm using yum but this problem applies for other distros too.
snapper's just a wrapper around the other commandline tools, right? We
do
I'm here asking advice. PackageKit used to ship subpackages of
PackageKit-glib, PackageKit-glib-devel, PackageKit-qt, and
PackageKit-qt-devel amoung others.
Upstream PackageKit-Qt has been split out into another separate
project as it had different API and ABI promises to PackageKit-glib
and it
On 26 November 2012 15:19, Rex Dieter rdie...@math.unl.edu wrote:
I'll help with the review, if still needed.
Yes please, all help very welcome. I want to get the new version of PK
into F18 if possible, as it's got quite a few nice fixes that people
want.
Imo, the Obsoletes/Provides should
On 27 November 2012 15:22, Zdenek Pavlas zpav...@redhat.com wrote:
Or, maybe it's PackageKit, trying to fetch changelogs
of updated packages, without updating primary metadata first?
Plausible, given PK tries to use a larger cache time than yum by default.
Richard.
--
devel mailing list
On 19 December 2012 19:46, Reindl Harald h.rei...@thelounge.net wrote:
as example the colord crap pulls X11 deps on
servers because you install Imagemagick which is a COMMANDLINE
tool in the first front
It does? That's a bug if that's true. colord is the simple mapping
daemon and doesn't know
On 10 January 2013 17:07, Kevin Fenzi ke...@scrye.com wrote:
If someone wants to go fix it, please do, otherwise I will later
today. ;)
Opps, sorry. I've got a little baby to keep amused this afternoon, so
If someone could jump in and push a fix with a rebuild I would be very
grateful. Thanks.
On 10 January 2013 20:23, Kevin Fenzi ke...@scrye.com wrote:
It's a archfull package obsoleting/providing a noarch package.
We could split out a colord-profiles subpackage (noarch) and make
colord dep on colord-profiles if that makes things easier.
Richard.
--
devel mailing list
On 10 January 2013 20:58, Kalev Lember kalevlem...@gmail.com wrote:
But the better solution I was thinking of is to split colord packaging
into two: one package with the shared library (colord-libs) and another
package with the daemon (colord). With a setup like this, only the
library
On 10 January 2013 23:55, Kalev Lember kalevlem...@gmail.com wrote:
It's 'mash' that decides what gets multilibbed. If I read it right, it
multilibs packages that install files that match the libdir/*.so.*
pattern, plus a number of hardcoded special cases. It's a bit like
magic, we'll see how
I've tried to build colord for f18 a few times now. It builds locally
fine, but when run on Koji it gets killed: make[3]: ***
[FOGRA28L_webcoated.icc] Killed
It only seems to happen when the print profiles are being created,
which do take some time to complete. It probably takes about 20
minutes
On 11 January 2013 09:13, Dan Horák d...@danny.cz wrote:
I'd say it's the OOM killer in kernel what kills your processes. Do the
generators run in parallel?
No, serially. I've just submitted a scratch build that uses ulimit
-Sv 50 which will cause the profiles to be built in chunks rather
On 11 January 2013 10:21, Ralf Corsepius rc040...@freenet.de wrote:
builds verbose
Good idea. Do I just do this or is there some Fedora macro?
@@ -87,10 +91,10 @@ This may be useful for CMYK soft-proofing or for
extra device support.
--disable-examples \
On 11 January 2013 11:32, Ralf Corsepius rc040...@freenet.de wrote:
Then its configure script likely honors --disable-silent-rules
That works a treat, thanks.
In both cases, it's worth contacting upstream to tell them about the
harmfulness of silent make rules
Well, I am upstream :) When I'm
2010/1/15 Matt Domsch matt_dom...@dell.com:
ohm-0.1.1-9.39.20091215git.fc11.src.rpm
https://bugzilla.redhat.com/show_bug.cgi?id=539200
This should be a dead package, upstream is no longer being maintained.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
On 30 January 2010 07:33, Kevin Kofler kevin.kof...@chello.at wrote:
The current PackageKit policy in F12 updates still allows upgrading (as
opposed to installing or removing, not sure about downgrading, does
PackageKit even support that?)
No, PackageKit won't let you downgrade a package.
Is
On 2 February 2010 15:12, Sebastian Vahl deadbaby...@googlemail.com wrote:
* setroubleshoot introduced a hard dependency on gnome-packagekit (#561001)
* The dependency should be made generic or setroubleshoot has to be removed
from KDE spin.
Is it just a dep on the PackageKit session API? If
2010/2/9 Parag N(पराग़) panem...@gmail.com:
when one of my package fails to build? Should I ask upstream to
hardcode required DSO names in Makefile or we need to modify CFLAGS in
%build section?
Most of the time upstream (myself included) just forgets to add a
library at the end of the LDADD
On 17 February 2010 01:48, Dariusz J. Garbowski thufo...@yahoo.co.uk wrote:
Features/ColorManagement describes per-screen / per-output support. I have a
dual monitor setup here
(potentially even triple-monitor if I could setup SurroundView with on-board
Radeon and discrete
Radeon card). I
On 26 February 2010 22:54, Kevin Fenzi ke...@scrye.com wrote:
- If stable pushes were more restricted, perhaps that would get us more
testing? If someone required a newer version and could easier
install/test from updates-testing and provide feedback, don't we all
win? Perhaps we could have
On 4 March 2010 13:17, Kevin Kofler kevin.kof...@chello.at wrote:
But of course the GNOME spin works (for some definition of works, they
also have a PackageKit issue which was declared not a blocker –
For the record, it is a yum-langpacks issue.
If you're running an up to date gnome-packagekit
On 4 March 2010 19:59, Kevin Kofler kevin.kof...@chello.at wrote:
I think we
really need to be more conservative about what version of our default
updating tool we include in our releases (and in fact pushing PackageKit 0.6
as a post-release enhancement update once the issues with it are
The latest sos update is not signed:
[hugh...@hughsie-t61 packages]$ rpm -qp sos-1.9-1.fc12.noarch.rpm
warning: sos-1.9-1.fc12.noarch.rpm: Header V3 RSA/SHA256 Signature,
key ID 57bbccba: NOKEY
This causes PackageKit to barf. How come this update was pushed
without a signature and all the other
On 8 March 2010 10:59, Michael Schwendt mschwe...@gmail.com wrote:
That means you don't have the key installed:
This is a fresh F13 pre-alpha spin, updated last a few days ago.
$ rpm -Kv sos-1.9-1.fc12.noarch.rpm
sos-1.9-1.fc12.noarch.rpm:
Header V3 RSA/SHA256 signature: OK, key ID
On 8 March 2010 11:44, Michal Nowak mno...@redhat.com wrote:
Past months I spent investigating `gold' - the new GNU linker
and how it now works with stock Fedora packages.
Using gold, I get:
/usr/bin/ld: --no-add-needed: unknown option
/usr/bin/ld: use the --help option for usage information
On 8 March 2010 19:47, Adam Williamson awill...@redhat.com wrote:
Is there a sekrit PK mode you can use to get such output, does anyone
know? Maybe if I just launch it from a console...
No, but I could do such a thing if you file an enhancement bug.
Richard.
--
devel mailing list
As some of you may know, DeviceKit-power has been renamed to upower.
If you depend on the former, you need to change your rawhide spec
files to depend on the latter. DeviceKit-power will cease to be a
package in devel in a few minutes.
I've not made any changes to F13 branches, as it's too close
On 15 March 2010 15:38, Bruno Wolff III br...@wolff.to wrote:
On Mon, Mar 15, 2010 at 15:17:20 +,
Richard Hughes hughsi...@gmail.com wrote:
As some of you may know, DeviceKit-power has been renamed to upower.
If you depend on the former, you need to change your rawhide spec
files
1 - 100 of 634 matches
Mail list logo
