I currently own a few packages related to my old abortive attempt to
build Unity for Fedora. I don't have time to maintain these or any
direct interest in them - they were just Unity building blocks to me.
I'm orphaning these packages:
bamf
compiz-plugins-main (for f16 only)
dee
libindicator
Only one package depends on any of these: gwibber depends on dee. So
someone interested in gwibber might want to pick up dee. It's not a
difficult package to maintain, but I don't have any real interest in it.
Other than that, I don't see that there's any reason anyone would want
to pick these up, but maybe someone does. compiz itself was retired some
time back - I should have orphaned compiz-plugins-main at the same time,
but never did. I don't recall how I wound up owning it. It only appears
to be 'alive' for F16 anyhow.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
I'm trying to take over the work Jonas Courteau started earlier this
year (see below) in regards to getting Opscode Chef into Fedora.
To start, I'd like to assume responsibility for the above orphaned
packages in Fedora, which are dependencies for Chef. I am already a
Fedora Packager but I can't seem to "Take Ownership" of said packages
in the package DB. Can anyone assist?
- Julian
On Mon, May 21, 2012 at 10:36 PM, Jonas Courteau <rpms(a)courteau.org> wrote:
> My apologies; the links on that were wrong. Big copy/paste error on my
> part; not a good start!
>
> The main package, rubygem-chef is at
> https://bugzilla.redhat.com/show_bug.cgi?id=823352, and the other
> packages are linked off of there.
>
> A little bit about myself: I'm a network administrator who has been
> using CentOS extensively for around 5 years, and Chef for about 3
> years. As part of this, I've done a fair amount of packaging of
> various software for our internal repository using mock and the EPEL
> packaging guidelines. A large part of my early packaging efforts
> involved packaging assorted Ruby gems.
>
> Recently, I've been working with opscode to get Chef packaged up for
> Fedora (and EPEL, in the future). There was a previous abortive
> attempt to get Chef into Fedora but the volunteer involved at the time
> had other requirements on his time. I'm looking to maintain this
> package (and its requirements) on a long-term basis, since there is a
> fair bit of demand to have Chef be a bit more widely available.
>
> Please let me know if you have any further questions, or if you have
> any suggestions on proceeding from here.
>
> Thanks!
> Jonas Courteau
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(originally posted to test@; Adam Williamson suggested it might be
more appropriate here)
Ever since I started tracking Fedora 18, Google Music Manager is no
longer installable, and now Oracle's Virtual Box cannot be installed
either (both from upstream Yum repositories).
https://bugzilla.redhat.com/show_bug.cgi?id=870655
In both cases, RPM and yum aborts with file conflicts -- /lib/modules
for VirtualBox and /usr/bin for google-musicmanager.
While, granted, these are upstream packaging bugs and those
directories should not be owned by the corresponding packages (they
are owned by filesystem), is there any reason why the same RPMs
install just fine previously?
(and if anyone knows who to contact at Google and Oracle's VBox team
respectively, that'd be great -- I tried contacting the Music Manager
team but the email listed in the RPM bounces, and the support reps
that respond through official channels don't even know what Linux is,
they sent me screenshot-grabbing instructions for Windows and Mac...)
Apologies if this s a dupe, I could only find one relevant thread
regarding file conflicts and that's regarding Samba 3 vs Samba 4 -
those apply to files whereas the file conflicts here are really about
directories.
Best regards,
- --
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQjCvWAAoJEEr1VKujapN6N3cH/3FrXhxeCBrs3CwWpeSaZVbr
GBCVZg/vZ06uQqc0/1v8pfsZKXQ24UNxmlqmKnfAsW2GHXq2vwS6cBfd+I/phjZi
Z+mmw8wIAMaGm2ihbe8WK6f2tzzq/1jPggri7ofria3/c0EcqaNoLIiQrokAJTKo
l5rb46R4isaKzrDO7ijzl8vMhBT4NOo3ASD0P8w0YcTSZISehrHwEw8U/4Bzb6dC
7yPHsodmlGUrPTuzzlXBFfAkfG68T0Ws9QaC4aMpHcYlrK7lOXA4h+BLv/KPN/so
ByFKJiN6Hm/a96TjtqJgfrzLuFy/TGV9+RBRYapg0CHSBWehvhpT0sTSkiKLTIY=
=x1kZ
-----END PGP SIGNATURE-----
Hi,
I am trying to package slic3r -> it is a perl noarch package, but it
requires a lot of arch specific perl modules.
The Requires section form spec file:
Requires: perl(XML::SAX)
Requires: perl(Growl::GNTP)
Requires: perl(Net::DBus)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`";
echo $version))
https://github.com/hroncok/SPECS/blob/master/slic3r.spec
The rest of Requires are automatically added.
When I built the package and add it to the repository together with
required packages I made, it requires arch mishmash on a 64bit system:
Install:
slic3r noarch myrepo
Install requires:
perl-Boost-Geometry-Utils i686 myrepo
perl-Class-Accessor noarch
perl-Class-Method-Modifiers noarch
perl-Crypt-CBC noarch
perl-Devel-Symdump noarch
perl-Digest-SHA x86_64
perl-Digest-SHA1 x86_64
perl-File-HomeDir noarch
perl-File-Which noarch
perl-Growl-GNTP noarch myrepo
perl-JSON noarch
perl-Language-Expr noarch myrepo
perl-Math-Clipper i686 myrepo
perl-Math-ConvexHull noarch myrepo
perl-Math-Expression-Evaluator noarch myrepo
perl-Math-Factor-XS i686 myrepo
perl-Math-Geometry-Voronoi i686 myrepo
perl-Math-Libm x86_64 myrepo
perl-Math-NumSeq noarch myrepo
perl-Math-PlanePath noarch myrepo
perl-Math-Prime-XS i686 myrepo
perl-Math-Symbolic noarch
perl-Module-Load noarch
perl-Module-Util noarch
perl-Moo noarch
perl-Net-DBus x86_64
perl-Params-Validate x86_64
perl-Parse-RecDescent noarch
perl-Pod-Coverage noarch
perl-Regexp-Grammars noarch
perl-Role-Tiny noarch
perl-SVG noarch
perl-Test-Pod noarch
perl-Test-Pod-Coverage noarch
perl-Test-Simple noarch
perl-UUID-Tiny noarch myrepo
perl-Wx x86_64
perl-XML-Twig noarch
perl-boolean noarch
perl-constant-defer noarch myrepo
perl-libintl x86_64
perl-parent noarch
perl-strictures noarch
Lines with myrepo are made by me, you can see specs here:
https://github.com/hroncok/SPECS/
As you can see, it installs 64bit required packages from officail
repositories, but it installs 32bit packages from mine (64bit packages
also exists, that's not the problem).
It installs slic3r, but it won't work, as it looks up its't arch
specific modules in 64bit directories.
If I manually run
yum install perl-Boost-Geometry-Utils perl-Math-Clipper
perl-Math-Factor-XS perl-Math-Geometry-Voronoi perl-Math-Prime-XS
slic3r
It works as expected (install 64bit packages).
What should I as a packager do, to avoid this situation?
Thank you very much.
Miro Hrončok
Jabber: miro(a)hroncok.cz
Telefon: +420777974800