Sqlite manager is now made an application not just an extension
(it's supposed to be noarch since it uses python)
I can run it like this
but I tried to copy it to /usr/share/SQLiteManager/
then run as regular user
it did not work
I also tried
xulrunner --install-app /path/to/SQLiteManager_XR_0.5.2b3.zip
and it won't run
so what is the right way to make an rpm for it ?
On 08/30/2009 10:33 PM, Rex Dieter wrote:
> Anyway, I'm open to suggestions on how to better achive what we want
> here. Maybe drop the kde-plasma-folderview dep, and just add to comps
FWIW, this is the solution, I prefer.
Currently, Fedora package management is one of the most annoying part of
Fedora experience for new desktop users (at least for those without
fast, always available internet connection). For such users, Fedora
package management "Just Doesn't Work"! I've almost never been able to
demonstrate using fedora package management tools for a fresh Fedora
install without the need to use command line, editing yum configuration
file(s), killing current running yum/package kit instance(s), installing
some small rpm packages using rpm command instead of using yum or
graphically, etc. And sometimes, I found it better to download yum
metadata using another application and copying the downloaded file to
yum cache; or even completely skip yum and use rpm and manually resolve
dependencies when they are not too much!
First, I've some suggestions/requests which doesn't seem to need much
work, and then some ideas which I'd like to know your opinions about.
1. Since Fedora 4, Fedora doesn't support installing software from DVD
"out of the box". Fedora 8 is an exception here. Currently, it seems
that the work is almost done (99% completed as in ), and fixing the
remaining 1% doesn't seem to need much work but unfortunately it seems
that it is stopped. I think requesting a small collaboration between the
feature owner, PolicyKit and/or GIO people is not too much.
2. Maybe yum could be a bit more forgiving about inaccessible
repositories when running. Consider this case: a new offline user
installs Fedora, and then runs "Add/Remove Software". Currently, if he
clicks on "all packages", he'll see an error message that yum is unable
to contact fedora repository. I think it is better to show a warning to
user about being unable to contact online repositories and then show all
installed packages + the packages from all accessible repositories.
IMHO it is much more reasonable than expecting the user to disable all
such repositories in such cases (yum/packagekit can be a bit more
intelligent and do it itslef).
Now, some ideas:
3. AFAIK, currently yum's primary database file contains information
about packages, and all of the files in directories such as /usr/bin and
/usr/lib, so that it can resolve package and file level dependencies.
Isn't it possible to move file level information outside primary db
(e.g. to primary_file_deps.db) and translate internal dependencies from
file level dependencies to package level dependencies when creating
repositories? (So that provides and requires tables in primary db only
contain package references rather than file references?). It might be
even possible to do it for dependencies outside repository; for example
when creating updates repository, you can introduce fedora repository to
createrepo, so it can translate all of the file level dependencies of
updates packages also.
4. Even if the above solution is possible and can reduce the size of
primary db, it won't solve the main problem: for large repositories,
you'll need to download large database files. You'll need to download
extra database files on some use cases anyway. So, it can be said that
currently yum doesn't scale well.
What do you think about it: we can implement parts of yum at the server
side (e.g. a web service), and do queries online. The client can submit
queries to online repositories, aggregate the results (+using local
repositories by itself) and do appropriate actions. It can also store
received data to be used when offline or while they are valid. It'll be
completely backward compatible with the current clients: those who use
the old method can download repositories themselves, like what they do now.
It is possible to think about further details and design it completely,
but I want to know about your opinions about the whole idea.
El Sat, 29-08-2009 a las 10:25 -0400, Luke Faraone escribió:
> Well, the USB format idea was left unimplemented as we (I) couldn't
> get it working, but we should probably take a look at makebootfat to
> achieve the same goals.
Or just use parted instead of fdisk to wipe the MBR and create it from
scratch. It does the right thing on the USB sticks I tried.
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
Jonas Smedegaard wrote:
> Also, the bootloader Gujin contains a stripped-down driver for ext4 so
> might be interesting for a fast-booting USB setup:
FWIW, Syslinux 4.00-preX supports ext4.
Alex Hudson wrote:
> Living in a European milieu I generally prefer my page sizes to be set
> to the likes of A4. One thing which keeps aggravating me is the myriad
> places where I keep having to repeat to the computer my preference.
And then in Publican, you get A4 and it is a major pain to switch to letter.
If you want something that isn't "approximately" A4 sized it gets to be a
Do we even have an inventory of places where page size matters? And then,
are those that "get it right" actually using some standard source, or do
they simply use a different default?
El Sat, 29-08-2009 a las 15:17 +0200, Jonas Smedegaard escribió:
> BTW, are all these details about USB booting being collected somewhere
> on a wiki page?
it would be great if someone could expand this paragraph:
This page is not even linked from it:
A few months ago, I got this useful piece of information which makes a
lot of previously unbootable machines work:
--------- Mensaje reenviado --------
De: H. Peter Anvin <hpa(a)zytor.com>
Para: Bernie Innocenti <bernie(a)codewiz.org>
Cc: syslinux(a)zytor.com, Jeremy Katz <katzj(a)redhat.com>, Development
discussions related to Fedora Core <fedora-devel-list(a)redhat.com>, Sugar
Asunto: Re: Unbootable machine
Fecha: Mon, 01 Jun 2009 22:10:37 -0700
Bernie Innocenti wrote:
> On 06/02/09 03:43, H. Peter Anvin wrote:
>> Bernie Innocenti wrote:
>>> Disk /dev/sdb: 2055 MB, 2055208960 bytes
>>> 221 heads, 2 sectors/track, 9081 cylinders
>> I don't know where fdisk, the Linux kernel, or whatever come up with
>> these kinds of geometries. They're almost universally non-bootable.
> Ok, I wiped mbr and made fdisk create a new one:
> Disk /dev/sdb: 2055 MB, 2055208960 bytes
> 64 heads, 62 sectors/track, 1011 cylinders
Equally weird. The only "standard" ones are 64 heads, 32 sectors and
255 heads, 63 sectors.
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
I have had to patch the code for cpqarrayd to get it working under
Fedora 11. It was failing with a stack smashing exception. I have fixed
this by replacing stack structures with dynamic allocation. Where should
I send the patch ... the last development on this was in 2007 so it is
probably not being maintained, although I will try to contact the author.
If you had read what I wrote originally, I said I wrote this for me and
simply released it in the hopes that others could benefit as well. So in my
case I was/am the user and it does exactly what I want of it.
On Aug 28, 2009 6:04 PM, "Milos Jakubicek" <xjakub(a)fi.muni.cz> wrote:
Dne 28.8.2009 23:33, Adam Miller napsal(a):
> > On Thu, Aug 27, 2009 at 5:16 PM, Milos Jakubicek<xjakub(a)fi.muni.cz>
wrote: > <snip> >> >> I'm ...
Well, imo the point is that we should try to enable the users to get to the
desired package info page (from which they can access
builds/updates/sources/bugs) in shortest possible time, therefore I've
implemented the suggestions (which, if running on a reliable box, provide an
instant way how to ensure one type the package name properly). Otherwise, as
I described: entering a nonexisting package results into search, otherwise
you'll get to the package page in pkgdb.
-- fedora-devel-list mailing list fedora-devel-list(a)redhat.com