On 17 June 2012 18:49, Richard W.M. Jones rjo...@redhat.com wrote:
You're asserting that dbus-daemon etc cannot be restarted, but without
saying why.
Okay, I'll say why. The core protocol was never designed to support
the dbus-daemon being restarted.
The current design may make restarting
Hi!
The mclazy.py script is doing a great job of building all the tarballs
that come from ftp.gnome.org that adhere to the official gnome
numbering scheme. This means we can build an entire gnome point update
automatically in about an afternoon whereas before it used to take
days of manual work.
I'm going to manage the GNOME 3.4.2 mega-update again for this
release, as it's much easier to QA in one update than 30. If you're
doing a GNOME 3.4.2 build please add it to the speadsheet
https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc
and I'll add it to
On 20 April 2012 07:41, Toshio Kuratomi a.bad...@gmail.com wrote:
As for the poll -- The Board has heard a lot of people asking to remove code
names but is unsure if thats just because thats the group that happen to
subscribe to the mailing list in question.
When have you ever heard I'm
On 16 April 2012 10:13, Milan Crha mc...@redhat.com wrote:
it will be kind of you to not touch packages you do not own, especially
those which are actively maintained. The way you did it breaks build
the package like normal from your instructions.
In the same way I've emailed for your two
On 16 April 2012 11:32, Milan Crha mc...@redhat.com wrote:
Maybe he's just _currently_ busy, sleeping (consider different
timezones) and so on? Anyway, I never asked to have those packages part
of the auto-build list, and never was asked for acceptance. This is
easily distinguishable, isn't
If you're maintaining a GNOMEish package and you want it included in
the 3.4.1 release, please build the package like normal and then add
the build ID to:
https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc
Most of the packages released on ftp.gnome.org with
On 14 April 2012 22:31, Debarshi Ray rishi...@lostca.se wrote:
What about using a page on https://fedoraproject.org/wiki/ ?
Unless I'm mistaken, you can't have more than one person editing a
wiki page at the same time. Seeing as there's normally 3 or 4 of us
building packages simultaneously, it
On 26 March 2012 20:31, Kevin Kofler kevin.kof...@chello.at wrote:
Let's also mention our mass-update script:
https://fedorahosted.org/kde-settings/browser/scripts
which may or may not be of interest.
Very much of interest, thanks. I spent a couple of hours and wrote
mclazy, i.e. I'm lazy and
At the moment the GNOME updates in Fedora are a bit of chaotic affair.
They mostly work, but only because of people like mclasen who spend
hours and hours building packages and putting everything together
manually. For 3.3.92 I experimented doing a mega-update and trying to
get all the 3.3.92
On 26 March 2012 11:58, Peter Robinson pbrobin...@gmail.com wrote:
It would be nice if the rawhide stream was built at the same time as
well as not doing so has the effect of people trying to work with
rawhide as well get random failures and in the process of building
F-17 and rawhide on ARM a
On 7 February 2012 17:40, Josh Boyer jwbo...@gmail.com wrote:
The scrub commands weren't added in btrfs-progs until October of last year.
The version F16 and rawhide has is just too old to contain that support.
That worries me a little, seeing how we're pressing on with btrfs by
default for
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
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 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
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 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 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 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 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 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 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
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 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
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 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 ---
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 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 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
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 23 June 2011 01:19, Matt Domsch matt_dom...@dell.com 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
On 12 May 2011 12:41, Camilo Mesias cam...@mesias.co.uk 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
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
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
On 24 April 2011 19:24, Ilyes Gouta ilyes.go...@gmail.com 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
On 16 March 2011 17:16, Michel Alexandre Salim
sali...@fedoraproject.org wrote:
I wonder why gimp depends on hal directly. For scanner, perhaps?
It was for tablet support, but the code could never have worked. We've
dropped the hal and gnome-vfs2 deps from gimp in rawhide now.
Richard.
--
On 16 March 2011 03:12, Peter Robinson pbrobin...@gmail.com wrote:
That package is obsolete anyway as well so the apps should be
migrating away, I doubt that will be for F-15.
Agreed.
I think it's also sane to retire gnome-vfs2 for F16 too.
Richard.
--
devel mailing list
I'm planning to orphan the hal and hal-info packages in F15 and and
retire them in rawhide.
HAL has been dead upstream for 3 years now, and all development has
moved into udev, and the u* daemons like upower, udisks and urfkill.
The original maintainer and most of the original team want HAL dead.
On 15 March 2011 13:21, Kalev Lember ka...@smartlink.ee wrote:
The list above is missing some packages that depend on hal-libs. Below
should be a more complete list of the builds that need
one of the hal subpackages:
Eeek, thanks.
gnome-device-manager-0.2-6.fc15
I *think* this is dead
On 7 February 2011 20:59, Bill Nottingham nott...@redhat.com wrote:
Orphan smolt
Don't we still use this by default on all spins?
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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 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 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
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 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
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 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
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 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 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 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 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 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
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 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
-desktop if it's really important.
Thanks.
Richard Hughes
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hey,
If you're a proventester (or whatever they are called now) please can
you test https://admin.fedoraproject.org/updates/gnome-packagekit-2.30.3-1.fc13
-- it's got a few nice bugfixes including one which is a crasher and
is generating a fair amount of dupes.
Thanks.
Richard.
--
devel
On 13 July 2010 17:26, drago01 drag...@gmail.com wrote:
Yeah updating (core!) packages like PackageKit without even testing it
with the default setup *is* indeed unacceptable.
I did test it with SELinux enabled, but I don't run enforcing as it
gets in my way as a developer. There was no
On 2 July 2010 17:00, Toshio Kuratomi a.bad...@gmail.com wrote:
They were granted access to all perl-packages, because they are @RH.
Probably because it is their paid job to work on these packages.
Ralf, you need to stop repeating this particular line when I have repeatedly
told you that
On 1 July 2010 16:07, Adam Williamson awill...@redhat.com wrote:
This would make more sense if PK was a fedora-tool - but PK is targeted
to be cross-distro - and integrating bodhi-reporting would not be
cross-distro.
So, if you want to make this work we'll need someway to plugin AROUND
PK.
On 22 June 2010 18:14, Jan Vcelak jvce...@redhat.com wrote:
Some services might require the library when /usr is not mounted. e.g. nut
(UPS management daemon, bz #453704) needs it at shutdown time.
What on earth is NUT doing to the UPS at shutdown time?
Richard.
--
devel mailing list
On 23 June 2010 09:50, Tomasz Torcz to...@pipebreaker.pl wrote:
“/sbin/upsdrvctl is used as the near final step in /etc/init.d/halt to command
That's completely bogus. You really don't want to just power down the
machine like that -- it might lead to disk corruption and is certainly
not a good
On 23 June 2010 13:33, Rob Crittenden rcrit...@redhat.com wrote:
You're misunderstanding what this does. It doesn't cut power to the
computer while its on. The process looks something like:
- nut signals the UPS to shut down in x seconds (default 120)
- nut halts the machine
- after x
I'm asking for a reviewer for the lcms2 package:
https://bugzilla.redhat.com/show_bug.cgi?id=590387
lcms2 is going to be required by gnome-color-manager in the next few
weeks, and will also be required by the next version of imagemagick.
lcms2 is the new version of lcms, the ubiquitous color
On 8 June 2010 16:11, Frank Murphy frankl...@gmail.com wrote:
Both rebuilt on my x86_64 Rawhide
also rebuilt gcm to suit
http://koji.fedoraproject.org/koji/buildinfo?buildID=176385
I've built a git snapshot of dconf and it should be in rawhide tomorrow.
Richard.
--
devel mailing list
501 - 600 of 634 matches
Mail list logo
