Pidgin Icons gone
by David Hunter
Since the demise of Gaim being replaced with pidgin, many of the old Icons
from gaim have been changed. Any way to get them back? or is it a change for
good? Is it a bug or known issue?
--
David Hunter
16 years, 11 months
yum-presto and $basearch
by Dan Horák
Hello Jonathan,
is it possible for yum-presto to interpret $basearch and $releasever
variables in its URLs in the config file?
Dan
16 years, 11 months
repotag in EPEL (was: Re: Plan for tomorrows (20070426) FESCO meeting)
by Thorsten Leemhuis
(this is a follow up to
https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00539.html
I'd like to move this part of the discussion here to fedora-devel to
make sure everyone can participate in this discussion -- that not the
case on fedora-maintainers as it's a closed list and moderators don't
let any non-contributors mail pass afaik; epel-devel-list seemsed like
the wrong place to discuss, as certain Fedora people that we need for
this discussion are not subscribed there afaik)
Brian Pepple schrieb:
> /topic FESCO-Meeting -- EPEL
There was no meeting this week afaics from looking at #fedora-meeting.
Other stuff: There was and still is a lot of political discussions on
the mailing list about EPEL not using a repotag. Political in the sense
of "Fedora/EPEL is bad/unfair to existing repos because it doesn't use a
repotag". See the archives at
https://www.redhat.com/archives/epel-devel-list/
for details.
Not using a repotag was a decision FESCo did already last fall; the EPEL
Steering Committee voted the same way recently, too. I was actually one
of those voting it down both times, too. Some of my reasons for doing
this were (in short, rough form below and all IMHO; btw, feel free to
simply skip the next five paras, the interesting stuff are below):
- we have nothing in place to properly use of a repotag everywhere; yes,
we could abuse disttag, but I dislike abusing something that is meant to
be used for something else; and the disttag in not used by all packages
-- a repotag IMHO mainly makes sense only if we really use it everywhere.
- there is a place in the rpm header already (%{vendor}) where a package
comes from. Maintaining a certain information in two places sounds wrong
to me and can lead to inconsistencies. The tools used should just
display the tag probably where relevant, and we should make sure it is
properly set.
- minor: disk space is cheap, but classic terminals are limited to 80
chars. Or, in other words: I dislike making each rpm name as displayed
by yum/rpm and other tools five chars longer for a repotag like ".epel"
as those chars can result in ugly output (line breaks)
- minor: there was a certain high member of both FESCo and the Packaging
Committee that strongly was against using repotags; I trust his opinion
in packaging issues a lot, and thus in parts addapted the was a reasons
I don't want to discuss those reasons I outlined above again in detail
here, as all those were discussed endlessly on mailing lists or IRC
channels already. It seems different people just have different
expectations and opinions in this area, and thus come to different
conclusions -- that's life and happens every day and (in general) is
something good. Feel free to reply to those four reasons I outlined
above and tell the world why thl and the reasons he gave are
stupid/wrong -- I probably won't reply to your reply, as that probably
doesn't lead anywhere productive; what I'm up to comes below, and that's
what I'd like to see discussed.
= Important part starts here =
>From a political standpoint EPEL looks quite bad in some peoples eyes
now due to not having a repotag. I think those people are making the
issue worse then it is. But well, seems it's quite important to them and
they make a lot of noise -- that will have negative impact on the fame
of Fedora; thus I'd say we have reached the point where FESCo and the
Board should back the decision to not use a repotag *or* (IMHO
preferred) we need to find a solution to make the situations at least
somehow acceptable for everyone involved.
So for the sake of cooperation and being nice to people that want a
repotag I'd like to propose the below solution in the hope that it is
acceptable for most people and even makes some people happy:
---
Use a repotag for EPEL4 and EPEL5 like this: add a "%define repotag foo"
in the buildsys, where foo expands to ".epel4" in EPEL4 and ".epel5" on
EPEL5; the repotag macro doesn't get defined in Fedora builders and thus
nothing will change when building a package for Fedora, even if it has a
%{?repotag} in %{release}.
Then enforce the use of "%{?repotag}" at the end of %{release} for all
packages in EPEL. To make that effective used in the repo it requires a
rebuild of all packages that are in EPEL already. Not nice and a bit of
work, but for the sake of making people happy let's just do it. The
added "%{?repotag}" in the release field must be allowed in Fedora spec
files, too, so people can easily copy spec files from Fedora to EPEL and
vice versa without having to modify them.
By Fedora 8 or Fedora 9 enhance the tools (rpm, yum, ...) to display a
the %{vendor} field in case of problems (for all packages that are
involved) and in popular queries. Then drop the repotag in EPEL6 and
later again, as it shouldn't be that much needed anymore
---
Did I miss anything?
Note note: it's just a idea I propose for discussion now; I'd like to
get feedback from the list over the next few days, get feedback from
FESCo in their meeting today (just feedback, don't vote on this yet
please, as this is still a decision the EPEL Steering Committee should
do, and I have no idea what the other think about it), from the
Packaging Committee in their meeting on Tuesday (they have to ACK the
new macro and it's use in both Fedora and EPEL spec files); then the
EPEL Steering Committee can finally discuss and decide in next weeks
meeting (next Wednesday) and we can all move on to our regular business
again and end this area that otherwise might end in "Fedora repowars --
the second season" otherwise?
CU
thl
16 years, 11 months
F7T4 install problems on VMware...
by Thomas M Steenholdt
Hi there...
I've been trying to install F7T4 on VMware workstation 6 (RC) but haven
been successful yet. Have tried both i386 and x86_64 and the same thing
happens every time. When anaconda has built dependencies and is ready to
proceed, anaconda bails, leaving a python backtrace on the screen. I
have the option to save the debug info to a floppy, but that doesn't
work either.
I just wanted to know if this is a known issue that I've missed. Perhaps
a problem with the not-yet-final VMware Workstation 6 or if I need to
file a bug.
/Thomas
16 years, 11 months
contributing a software through bugzilla
by Anton Kuznetsov
I submitted my software for review through bugzilla in order to
contribute the software to RedHat. A guy who checked the script told me
to fix some problems. I fixed all problems that he mentioned and sent
him new links of the software in the same bug report. I haven't heard
anything from him since April 16. Here is a question: do I need to
submit new links as a new bug report? if no...how long does it usually
take to review the software?
Thanks,
Anton
16 years, 11 months
Weird tooltips for OOo with regard to bold/italic
by Rodd Clarkson
If I put my mouse over the italic button in OOo and then move it over
the bold button, the tool tip for bold says italic. Move between the
two on the tool bar (and possibly other items) and both stay saying
italic.
Move off the tool bar and then back on, this time moving over bold first
and then the italic icon says bold.
Weird? Or just me being weird?
R.
--
"It's a fine line between denial and faith.
It's much better on my side"
16 years, 11 months
Change of historical behavior
by Dax Kelson
Just a FYI...
While updating some courseware I noticed a change in decades old UNIX
behavior on RHEL5/FC6. The behavior may not be super important, but I
wouldn't be surprised if somebody, somewhere gets bit by it.
The change is as follows.
Previously with disk quotas enabled if your hard block quota was reached
(or you were over your soft and the time had expired) but your
file/inode quota was not reached, you could still create empty files.
This is no longer the case. Observe:
$ quota
Disk quotas for user guru (uid 500):
Filesystem blocks quota limit grace files quota limit grace
/dev/sda8 2048* 0 2048 11 0 0
$ touch /tmp/newfile
touch: cannot touch `/tmp/newfile': Disk quota exceeded
My initial suspicion was that this is a side effect of RHEL5/FC6
mounting all filesystems with the acl and user_xattr options (done via
the default mount options field in the filesystem's super block),
however with testing this appears not to be case.
This came up because the lab exercise I was updating had a step along
the lines of "...now that you are 'over' quota run the command "touch
anewfile". Can you explain why that still works?...".
Dax Kelson
Guru Labs
16 years, 11 months
F7T4: HD-550 digital HDTV card
by Pat Kane
I just installed F7T4 on my DELL Dimension 1100 test box that has a HD-550
pcHDTV
card. The card is detected (see attached dmesg output), but the /dev/
entries are not
present. I mostly sure that this card worked on a stock FC6 system, should
I file
a bugz?
My Dimension seems to be running more hot/noisy with F7T4, anyone else
notice that?
Pat
16 years, 11 months
Installing F7-live cd
by Louis Garcia
Just downloaded live and not sure how to install it. I only see 3
options to run it.
-Thanks
16 years, 11 months
Slight schedule change
by Jesse Keating
Instead of deep freezing for F7 Final this Thursday, the release team has
decided to kick it out a week to next Thursday. This will give us a bit more
time to shake things out with the merger happening this Wed. and allow for
some builds for new BuildRequires (IE Core building against Extras) to happen
and be tested.
--
Jesse Keating
Release Engineer: Fedora
16 years, 11 months
