2010/1/15 Matt Domsch :
> 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
https://admin.fedoraproject.org/mailman/list
On 30 January 2010 07:33, Kevin Kofler 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 the bureaucracy in
On 2 February 2010 15:12, Sebastian Vahl 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 so can't we just
add a vi
On 2 February 2010 15:44, Till Maas wrote:
> While you are fixing PackageKit dependencies, can you also remove the
> PackageKit-yum-plugin dependency from PackageKit? The plugin seems not
> to be necessary, as it can be disabled in
> /etc/yum/pluginconf.d/refresh-packagekit.conf and still the gnom
in
fedora-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 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 all the resources to do
On 29 August 2010 15:07, seth vidal 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 at all.
What about ap
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 d
On 7 September 2010 12:57, Rahul Sundaram 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 app-install for each
distro
2010/9/7 Miloslav Trmač :
> 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 group.
Rich
On 7 September 2010 14:11, seth vidal 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 with other distros mean
On 7 September 2010 14:39, seth vidal 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 sure I get your logic. Lo
On 7 September 2010 15:23, James Antill 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 for making this repodat
On 7 September 2010 16:39, James Antill wrote:
> However this is very much the same problem as a user trying to find
> "sql server" and getting results like "voms-mysql-plugin" etc. If you
> intentionally ignore this problem, it just means even more work in the
> long term as we have to change th
On 7 September 2010 17:20, Nicolas Mailhot 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 distros, who
have no interest i
On 7 September 2010 17:32, Matthias Clasen 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 would be lov
On 8 September 2010 13:16, Adam Williamson 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 officially involved in
>
On 9 September 2010 09:52, Nicolas Mailhot 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 packagekit-side to
> make use of
On 13 September 2010 08:36, Hans de Goede 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, but then decided
On 13 September 2010 21:49, James Antill 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 schema?
Call me biased,
On 13 September 2010 20:42, Kevin Fenzi 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 you discuss
On 14 September 2010 23:01, Kevin Fenzi wrote:
> 21:33:35 The other 2 items I had were:
> 21:33:56 application installer issues
> 21:33:57 https://bugzilla.redhat.com/show_bug.cgi?id=488968
> 21:34:04 and
> 21:34:05 BuildIdBuild infrastructure
> 21:34:06 https://fedorahosted.org/fedora-infra
On 16 September 2010 09:57, drago01 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 a maintenance
On 16 September 2010 15:01, James Antill wrote:
> Err ... PackageKit is currently the cross distro. way to work with
> distro. package managers, nothing outside of that layer should ever know
> (or care) where the data is coming from and how it gets updated etc.
PackageKit is a _package_ abstrac
On 16 September 2010 20:05, Colin Walters 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, although it does n
On 17 September 2010 08:01, FlorianFesti 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 extension)
STRING app
On 17 September 2010 13:36, Arthur Pemberton 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 from the
metadat
On 17 September 2010 15:28, Bill Nottingham 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 with an interesti
On 17 September 2010 16:39, FlorianFesti wrote:
> open the payload and unpack the content of the desktop files...
I got told by infrastructure this would take too much bandwidth and
too much time to do on each compose. Apparently the link between the
machine doing the compose and the mirror is sl
On 23 September 2010 08:37, drago01 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 developer time,
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=2491737&name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=2491754&name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=2491800&name
On 27 September 2010 19:58, Jaroslav Skarvada 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.
Could somebody please
On 27 September 2010 21:04, Jesse Keating 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 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 expected,
> it ju
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
https://admin.fedoraproject.org
On 1 October 2010 13:24, Michal Schmidt 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 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
https://admin.fe
On 27 September 2010 20:31, Richard Hughes wrote:
> Right, but you could argue it's a regression as the behavior changed.
> Could somebody please fix docbook-utils, otherwise all the GNOME koji
> builds are going to fail.
All my F14 builds are still failing with:
docbook2man z
On 4 October 2010 11:32, Jaroslav Skarvada 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 srpm that built f
On 5 October 2010 05:30, Orion Poplawski 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 export some kind of s
On 5 October 2010 09:55, FlorianFesti 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 closed don't w
On 2 October 2010 11:23, Richard Hughes wrote:
> On 2 October 2010 09:51, Richard W.M. Jones wrote:
>> ..., then (sometimes, not always) displays some sort of
>> error[1].
>
> Yes, it's fixed upstream, apologies. There's a new release on Monday
> w
On 5 October 2010 15:51, Brandon Lozza 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 they presume they
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 http://koji.fedoraproject.org/k
On 1 August 2011 15:24, Jaroslav Reznik 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* I'm doing the ri
On 2 August 2011 14:54, Laurent Rineau
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 .z version number is
> changed.
Ag
On 19 August 2011 13:35, Steve Grubb 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
https://admin.fedoraproj
On 23 August 2011 01:32, Lennart Poettering 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 system activated
On 23 August 2011 12:01, Lennart Poettering 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 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 ---> <--- this close to
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. perl-4:5.14.1-187.fc16
On 7 September 2011 16:31, Jesse Keating 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
makefiles would provide
On 7 September 2011 01:02, Adam Williamson 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 in a *fresh* VM
a
On 8 September 2011 05:03, Joachim Backes 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
devel@lists.fedoraproject.org
https://admin.fe
On 8 September 2011 03:13, Andre Robatino 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
devel@lists.fedoraproject.
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 17:36, seth vidal wrote:
> Here is how yum does comparison between multiple package providing the
> same thing:
> http://yum.baseurl.org/wiki/CompareProviders
I don't think that works for all cases; surely "grid-certificates = 2"
wins over "grid-certificates = 1" in all cases
On 16 September 2011 18:43, seth vidal 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 I'm going to suggest to
2011/9/16 Miloslav Trmač :
> 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 same func
On 16 September 2011 20:07, Jef Spaleta 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:
https://github.com/hughsie/zif/tree/master/data/tests/transactions
Richard
On 16 September 2011 20:02, Richard W.M. Jones 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 clever guys who
On 16 September 2011 20:32, Jef Spaleta 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 state like w
On 16 September 2011 20:46, Jef Spaleta 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 simple.
> If
On 17 September 2011 02:36, Kevin Kofler 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,
> and suddenly it's th
On 17 September 2011 07:21, Richard W.M. Jones wrote:
> ... and no way to access yum information from anything other than
> Python, which makes it harder to use more professional programming
> languages and yum data together. I had to write a whole bit of code
> that spawned a Python process to g
On 17 September 2011 10:38, Richard W.M. Jones 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
gobject-introspe
On 17 September 2011 11:05, Richard W.M. Jones 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: Richar
On 17 September 2011 11:59, Rahul Sundaram 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 myself and it was lef
On 17 September 2011 13:56, Kevin Kofler 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@lists.fedora
On 17 September 2011 23:06, Jef Spaleta 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 IIRC.
> I was hop
On 18 September 2011 19:22, Panu Matilainen 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
> exports via its own API) i
On 19 September 2011 01:46, Kevin Kofler 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
> this. Richard, what
On 19 September 2011 17:41, Jef Spaleta 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
> expected.
> Guys w
On 1 October 2011 12:02, Hans de Goede 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
https://bugzilla.gnome.
On 3 October 2011 08:57, Richard Hughes 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
On 12 October 2011 17:44, Kevin Fenzi 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 should I have two
On 16 October 2011 19:00, JB 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
https://admin.fedoraproject.org/mailman/listinfo/devel
On 24 April 2011 19:24, Ilyes Gouta wrote:
> I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=699263
I've commented on this, and closed it NOTABUG. Sorry.
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
In a move that will surprise few, I'm retiring hal-info in devel and
orphaned it in f15. If hal gets blocked for f16, then I'll do the same
for hal-info.
The only thing that requires hal-info is hal, and libmtp-hal.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedor
I made a mistake yesterday, and pushed PackageKit-0.6.14-1 without
doing all the self checks. This build broke getting the updates list
which is kind of a bad thing for a package manager... I've built
PackageKit-0.6.14-2 to fix the issue and pushed it to
f15-updates-testing and rawhide. The broken
On 12 May 2011 12:41, Camilo Mesias wrote:
> So, reading between the lines, is it fair to say that Ubuntu seem to
> have chosen a display manager to avoid dbus and consolekit?
I'm pretty sure Ubuntu chose it because it's not gdm.
Differentiation FTW.
Richard.
--
devel mailing list
devel@lists.
On 23 June 2011 01:19, Matt Domsch wrote:
> Fedora Fails To Build From Source Results for i386
> using rawhide from 2011-06-16
Most of my packages are failing like this:
In file included from /usr/include/pango-1.0/pango/pango-gravity.h:98:0,
from /usr/include/pango-1.0/pango/pa
On 8 February 2010 22:46, Kevin Kofler wrote:
> As a result, you'll be causing dozens of FTBFS bugs just before the feature
> freeze. I think this is entirely the wrong time in the release cycle to do
> such a change, if it is done at all.
I've been fixing upstream projects for weeks to build wit
2010/2/9 Parag N(पराग़) :
> 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 line, so all I had
On 17 February 2010 01:48, Dariusz J. Garbowski 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 don't see test ca
On 26 February 2010 22:54, Kevin Fenzi 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 PackageKit/
On 27 February 2010 19:31, Jeroen van Meeuwen wrote:
> This sounds interesting, was this a plugin or configuration setting?
> Could this be something people can opt-in to at first?
in /etc/PackageKit/PackageKit.conf, the idea was to set
CheckTestingRepos to true. I'm not sure the code is actually
On 28 February 2010 18:39, James Antill wrote:
> I can't think of any reason why you'd need, or want, to have
> updates-testing checks block any other GUI operation.
To show the list of newest updates to the user...
>> If we could speed up the dep checking and downloading, I agree it
>> would b
On 3 March 2010 21:45, Tom "spot" Callaway wrote:
> Here are the list of changes to the Fedora Packaging Guidelines:
I've done some updates, and now rpmlint reports:
argyllcms.spec: W: no-cleaning-of-buildroot %install
argyllcms.spec: W: no-buildroot-tag
Does rpmlint need an update?
Richard.
-
On 4 March 2010 13:17, Kevin Kofler 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 you get a nice
m
On 4 March 2010 19:59, Kevin Kofler 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 resolved
> and there is
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 a
On 8 March 2010 10:59, Michael Schwendt 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 57bbccba
> Header S
On 8 March 2010 11:44, Michal Nowak 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
collect2: ld retu
On 8 March 2010 19:47, Adam Williamson 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
devel@lists.fedoraproject.org
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 t
On 15 March 2010 15:38, Bruno Wolff III wrote:
> On Mon, Mar 15, 2010 at 15:17:20 +,
> Richard Hughes 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
On 14 April 2010 19:02, Adam Williamson wrote:
> AFAIK none of these are generic bugs. Handling AC plug/unplug is
> actually not as simple as it seems, and can vary from device to device
> (or, rather, ACPI implementation to ACPI implementation). So this is to
> a degree system-specific.
It's tot
On 18 April 2010 20:55, Ben Boeckel wrote:
> The wiki states that pm-utils is hal-free. Maybe the hard dep in the RPM needs
> looked at?
Ajax discovered that it pokes HAL in at least two places. We're
waiting for an upstream fix in the meantime.
Richard.
--
devel mailing list
devel@lists.fedora
On 21 April 2010 16:17, Adam Williamson wrote:
> I've been banging a gong about something like that for years; right now
> it's much too hard to know what you're supposed to do to make
> $RANDOM_GADGET that you just plugged in actually work, but we can hardly
> install the software for every USB d
1 - 100 of 655 matches
Mail list logo
