biosdevname v0.3.4
by Matt Domsch
biosdevname, now version 0.3.4.
The main visible change is that port indices now start at 1 rather
than 0, when assigned by biosdevname (such as falling back to PIRQ)
rather explicitly assigned by BIOS. This is in keeping with how the
indices are assigned by BIOS on Dell and HP servers.
em<port> where port starts at 1
pci<slot>#<port> where port starts at 1
As a side effect, the first VMware Workstation guest NIC now appears as pci3#1
because the virtual machine BIOS exposes the device as being in a PCI
slot via PIRQ.
This also drops an explicit dependency check on a particular udev
version. That version was supposed to properly handle parallel
conflicting renames when swizzling within the ethX namespace, but as
we've discovered, that doesn't always work. The udev in RHEL5 is
older than what we were specifying, but it works just fine, so no more
check.
Furthermore, if biosdevname somehow messes up (either through its own
bug or because of a buggy BIOS), and would assign the same name to two
different devices, it won't try to assign names to either (who knows
which is correct?). You can see the duplciates when running with the
-d debug option.
Grab it here:
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.4.tar.gz
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.4.tar.g...
git://linux.dell.com/biosdevname.git
I built this today for Fedora rawhide (will be 15), and I encourage
other distributions to pick it up as well.
shortlog:
Matt Domsch (5):
require any udev
Return nothing if duplicate names would be assigned.
Don't assign names to unknown devices
only supress duplicates, not all names if any duplicates exist
start with port index 1, not index 0
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
13 years, 4 months
Re: Broken dependencies: RabbIT
by Pavel Alexeev
Hello, guys.
I receive quoted message and can't understand doesn't RHEL 6 contain
java?? What I should do with it?
14.12.2010 21:16, buildsys(a)fedoraproject.org wrote:
> RabbIT has broken dependencies in the epel-6 tree:
> On ppc64:
> RabbIT-4.1-9.el6.noarch requires java>= 1:1.6.0
> Please resolve this as soon as possible.
>
>
13 years, 4 months
Orphaning trac-spamfilter-plugin
by Jesse Keating
This plugin did not work as I had hoped it would, and I have no use for
it anymore.
pghmcfc was a co-maintainer, and is welcome to take it over, more
co-maintainers welcome as well.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
13 years, 4 months
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Here are the latest set of changes to the Fedora Packaging Guidelines:
---
A new page has been added which describes how to deal with bundled
libraries when you find them in your package:
https://fedoraproject.org/wiki/Packaging/Treatment_Of_Bundled_Libraries
---
Some clarification has been added to the sections dealing with bundled
libraries, specifically that:
In this RPM packaging context, the definition of the term 'library'
includes: compiled third party source code resulting in shared or static
linkable files, interpreted third party source code such as Python, PHP
and others. At this time JavaScript intended to be served to a web
browser is specifically exempted from this but this will likely change
in the future.
https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system...
Also, a note was added to make it clear that multiple licensing
scenarios may be a good indicator of a bundled library situation:
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Multiple_Lic...
---
A section has been added to the Packaging:Guidelines#Changelog entry
describing the acceptable methods of having multiple changelog entries
per release:
https://fedoraproject.org/wiki/Packaging:Guidelines#Multiple_Changelog_En...
---
A new example of a reason an exception for bundling libraries might be
granted has been added to the guidelines. If the library is being
bundled because it is a snapshot of a newer release of the library
needed for new features, you may have grounds for an exception. See the
complete policy for details on when an exception might be granted for
this reasoning.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Needing_unr...
---
Fedora has always implied that the update path from Fedora release to
Fedora release and from Fedora release to updates should be maintained
but there wasn't an explicit statement in the Guidelines. Well, there
is now.
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning
---
The guidelines have been updated to indicate that %doc files must not
have executable permissions.
https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation
---
The section on Requiring Base Package was clarified, as the original
language involving -libs packages may have been confusing:
https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Steven Garcia, Nils Philippsen, FESCo and all of the
members of the FPC, for assisting in drafting, refining, and passing
these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~spot
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
13 years, 4 months
Orphaning all of my packages :(
by Mary Ellen Foster
Other people -- you know who you are, and thank you! :) -- have
already been doing updates to my various (mostly java-related)
packages in Fedora. However, just to make it formal: due to a
combination of work and personal circumstances, I've had very few
cycles for keeping up with Fedora since last spring or, and I don't
see that changing any time in the near future.
So, I'd like to open up any packages associated with my userid (mef)
in the PackageDB for anyone who can give them more love. Is there an
easier way to accomplish this in the package DB than clicking
"Relinquish Ownership" on each package release individually?
I hope to have more time for Fedora stuff again sometime later in the
new year ...
MEF
--
Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/
Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab
School of Mathematical and Computer Sciences, Heriot-Watt University
Heriot-Watt University is a Scottish charity registered under charity
number SC000278
13 years, 4 months
Safest way to go from x86 to x86_64
by Paul F. Johnson
Hi,
My main box decided to snuff it last week (motherboard and processor decided
to fry). My erstwhile friend in the computer shop I use has said that he has
a nice 64 bit processor and motherboard going for a small amount of money.
The problem I have is that if I go the 64 bit route then I'll need to
install the 64 bit OS (I can stay 32 bit, but what's the point with 8Gb of
memory).
Is there a safe way to install the x86_64 system over the 32 bit version and
then clean off the 32 bit stuff that is no longer needed? If I was using
f14, I'd just trash the drive and then install, but I've got things how I
want them under rawhide.
I've not done this before, so advice before I do it would be appreciated.
TTFN
Paul
13 years, 4 months
Re: A GUI tool for Fedora Packagers
by Severin Gehwolf
----- "Mat Booth" <fedora(a)matbooth.co.uk> wrote:
> > That is what I am also thinking. As it was said earlier, that a
> stand
> > alone version for Fedora Eclipse Packager can be made, we should
> start
> > working on that. The code already exists for the backend. We can
> > design a GUI with gtk+ and put all the features in a simple to use
> > interface.
> >
>
> Well, the GUI already exists as an Eclipse IDE plug-in, my suggestion
> was to just turn that into an Eclipse Rich Client Platform
> application
> (read up on Eclipse RCP to see what I mean.) I believe that is also
> what Chris Aniszczyk hinted at. There's really no need to redesign it
> from scratch!
Mat is right. IMO an RCP app would be the way to go if there's a desire
for a stripped down interface. It would certainly avoid reinventing the
wheel :)
Let me know if you are interested in contributing to Eclipse Fedora
Packager. Help would be very much appreciated.
Cheers,
Severin
13 years, 4 months
A GUI tool for Fedora Packagers
by Ratnadeep Debnath
Hi,
I've been thinking for sometime now for a GUI for the Fedora Packagers. There are some steps during the packaging life cycle which needs to be repeated again and again. So, I was thinking of having some kind of one click system for updating the packages, like submitting for a koji scratch build, uploading the packages, updating bug request, etc.
I want to create a desktop app for this. If some steps have already in this regard, I would like to contribute to it, else I will start working on this project.
Thanks,
Regards,
rtnpro,
http://ratnadeepdebnath.wordpress.com/
---sent from Nokia C5---
13 years, 4 months