Orphaning my packages...
by Truch, Matthew
I need to orphan all of my packages. In most cases, it would be great if
someone (or more) could pick them up. Let me know if you'd like any of them
and I'll release them to you.
cfitsio -- Library for manipulating FITS data files Already has
co-maintainers; perhaps they want to step up?
getdata -- Library for reading and writing dirfile data An excellent and
easy to package data library. Upstream is extremely responsive.
hpic -- Healpix manipulation binaries and library Could be orphaned; not
used much anymore, but is trivial to maintain.
kst -- A data viewing program for KDE A great program for plotting data
(especially live data). Currently in Fedora is the 1.x branch of kst; 2.0
has been released; I have a spec file ready but haven't had the time to push
it though.
slimdata -- Tools and library for reading and writing slim compressed data This
package also gets little use, but it is easy to maintain.
11 years, 10 months
leaving packages "python-gdata" and "googlecl"
by Adam Goode
I don't have time to maintain python-gdata nor googlecl. python-gdata
seems well covered, so I will just remove myself.
googlecl has a single other maintainer for all but EPEL. I will remove
myself there as well, but it would be good if others could take
maintainership, especially for EPEL.
Thanks,
Adam
11 years, 10 months
Unplanned OUTAGE: buildsystem (2011-06-01)
by Kevin Fenzi
During reboots and updates yesterday, the filesystem for the
buildsystem was written to from two seperate places at the same time.
A snapshot was taken of the filesystem and a fsck started.
Builds were completing normally and the filesystem was functioning,
until about 08:11UTC when the filesystem switched to read-only.
Builds since that time have failed.
We have disabled the builder hosts for now (submitted jobs will queue
up and wait for their return) until the file system check is completed.
You can follow progress of this issue in:
https://fedorahosted.org/fedora-infrastructure/ticket/2800
Sorry for the inconvenience.
kevin
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 10 months
UID_MIN & GID_MIN changed
by Peter Vrabec
Hi all,
I'd like to inform you that I have changed UID_MIN & GID_MIN from 500 to 1000
in upgraded shadow-utils.
Where?
/etc/login.defs.
shadow-utils-4.1.4.3-1.fc16
I suppose UID/GID_MIN=1000 is more common(other distros, upstream). We are not
in situation that 500 IDs for system accounts ought to be enough for anybody.
Actually, it was not 500.It was 299 because range 0-200 is for reserved IDs.
There are 799 non reserved IDs for system accounts available after this
change.
Regards,
Peter.
11 years, 10 months
9base in Fedora?
by Petr Sabata
Hi list,
I've been thinking about packaging 9base [1], a port of Plan 9 userspace tools,
for Fedora. I'm interested in opinions on what style is "better" and why.
The problem is most of 9base binaries (and their manpages) have the same
name as their coreutils (and other) equivalents, therefore we need to install
them to somewhere else. Upstream suggests installing all its directories (bin,
share, lib, ...) into /usr/local. This is not acceptable for obvious reasons.
Options:
#1, aka the Gentoo way
Gentoo installs its 9base package into /usr/plan9, basically not touching
9base files at all. This collides with FHS and therefore would require an
exception in Packaging Guidelines.
#2, aka the Debian way
Debian installs its 9base package into /usr/lib. Well, most of it. They
also prefix all the manpages with 'plan9-', not the binaries, though.
This placement (provided we use %{_libdir}) introduces issues for Plan
9 rc shell scripts and their shebangs.
#3, aka the Fedora way?
Should we do this in some other way?
I personally like the #1 better since it's more clean (except for the required
FHS exception) and more or less aligned with upstream.
[1] http://tools.suckless.org/9base
--
# Petr Sabata
11 years, 10 months
Same noarch update to several releases?
by Bruno Wolff III
I am co-maintaining boswars-addons which has been setup to not use dist
as part of the versions, since the package is noarch and the same build
is usable accross releases. It's 48 MB, so it has been considered large
enough to be worth not triggering updates when updating between Fedora
releases.
So now I want to get the same update into F13, F14, F15 and rawhide.
Is there a reasonable way to do this? I think I can get it into F13
and rawhide, but I am not sure how to get the same build into multiple
updates repos for released versions. Can I do this one at a time? So
that after it has made it all the way to updates in one release, to
start again in another using manual tagging into updates-pending before
using bodhi again?
11 years, 10 months