Hi guys,
sorry, I recall this was discussed on the mailing list in the past, but
I can't find the thread anymore.
I need to resurrect rgmanager package in Fedora. fedora-cvs still has
the package so it's only a matter of "re-importing" it into the devel/
branch.
What are the right steps to take?
Thanks in advance
Fabio
On Sun, 30 Aug 2009 07:13:54 +0000 (UTC), Elio wrote:
> Author: emaldonado
>
> Update of /cvs/extras/rpms/nss/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv14629
>
> Modified Files:
> nss.spec
> Log Message:
> Do not require sqlite for nss, it breaks nss-util install - bug 520277
>
>
> Index: nss.spec
> ===================================================================
> RCS file: /cvs/extras/rpms/nss/devel/nss.spec,v
> retrieving revision 1.105
> retrieving revision 1.106
> diff -u -p -r1.105 -r1.106
> --- nss.spec 29 Aug 2009 20:46:40 -0000 1.105
> +++ nss.spec 30 Aug 2009 07:13:53 -0000 1.106
> @@ -6,7 +6,7 @@
> Summary: Network Security Services
> Name: nss
> Version: 3.12.3.99.3
> -Release: 26%{?dist}
> +Release: 27%{?dist}
> License: MPLv1.1 or GPLv2+ or LGPLv2+
> URL: http://www.mozilla.org/projects/security/pki/nss/
> Group: System Environment/Libraries
> @@ -14,7 +14,6 @@ Requires: nspr >= %{nspr_version
> Requires: nss-util >= %{nss_util_version}
> Requires: nss-softokn >= %{nss_softokn_version}
> Requires: nss-softokn-freebl%{_isa} >= %{nss_softokn_version}
> -Requires: sqlite
Highly questionable!
Just by watching this diff and the commit comment, it cannot fix
anything. Why? All you changed is to drop an explicit dependency on
sqlite. If sqlite breaks nss-utils, it would still be broken on
installations where sqlite is available.
So, let's visit bug 520277:
| The two depends on libsqlite3.so() -- on 64-bit systems,
| libsqlite3.so()(64bit) but this is not available; sqlite only provides
| libsqlite3.so.0() and libsqlite3.so.0()(64bit)
You still have "BuildRequires: sqlite-devel", so nss does still build
with sqlite, doesn't it?
Yes, it does. The bad libsqlite3.so dependency (mentioned in the bug
report) is still present:
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1520459
hello,
Sqlite manager is now made an application not just an extension
http://sqlite-manager.googlecode.com/files/SQLiteManager_XR_0.5.2b3.zip
(it's supposed to be noarch since it uses python)
I can run it like this
xulrunner path/application.ini
but I tried to copy it to /usr/share/SQLiteManager/
then run as regular user
xulrunner /usr/share/SQLiteManager/application.ini
it did not work
I also tried
xulrunner --install-app /path/to/SQLiteManager_XR_0.5.2b3.zip
/usr/share/ SQLiteManager
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
> instead?
FWIW, this is the solution, I prefer.
Rahul
Hi all,
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 [1]), 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.
[1] http://www.fedoraproject.org/wiki/Features/MediaRepo
Thanks anyway,
Hedayat
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:
> http://gujin.sourceforge.net/
>
FWIW, Syslinux 4.00-preX supports ext4.
-hpa
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
full-blown project.
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?
--McD
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:
http://wiki.sugarlabs.org/go/Soas#Boot
This page is not even linked from it:
http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/USB_format
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
Devel <sugar-devel(a)lists.sugarlabs.org>
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.
-hpa
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/