On Wed, May 27, 2009 at 1:31 PM, Rahul Sundaram
wrote:
> Hi
>
> I did a quick survey from Fedora on what software Fedora users are using
> that is not available in the repo. Here are the results. If you find
> anything interesting, feel free to pick it up.
>
> https://fedoraproject.org/wiki/Packag
On Mon, Jun 01, 2009 at 11:53:12AM -0400, Seth Vidal wrote:
> On Mon, 1 Jun 2009, Richard W.M. Jones wrote:
(Obviously it'll be Fedora/free software-related content)
>>> You can always make a request to Infrastructure at
>>> https://fedorahosted.org/fedora-infrastructure/. We've hosted some
>
On Mon, 1 Jun 2009, Richard W.M. Jones wrote:
Large data sets derived from analysing the code in Fedora packages...
I was hoping to save the announcement til later.
For the purposes of this, big data files, derived from Fedora content
so under a free license of some sort, probably up to 30GB
Caroline Meeks wrote:
> Luke and Sasha are working on a new USB format that they feel will allow
> more machines to boot and support VM + Stick
>
> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/USB_format
>
> Perhaps the issue you are running into (which we have definitely seen
> before) is relat
mail
I already received back in 2006.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
kage for that sort of
binaries. Plus, /usr/bin is one of the directories covered by
primary.sqlite.bz2.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
sed for builds, and it's
also possible to create branches with names which look like build tags,
which also get through validation.)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Michael Schwendt wrote:
> The temporary work-around is to compile with
>
> -fno-var-tracking-assignments
We also need that for some of our KDE packages. GCC really needs to get
fixed!
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.r
addition to being a regression from our current CVS
setup, which does allow creating such branches)! Branching is really part of
what VCSs are for.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ed by Koji, so I
had to branch and rebuild a new one. I used the "create a branch with a name
which looks like a build tag to the tag validator" hack and branched
kde-plasma-networkmanagement-0_9-0_3_20090930svn_fc12_x, then built off that
branch.
Kevin Kofler
--
fedora-devel-l
Orcan Ogetbil wrote:
> Seriously, this "comment about the patch in the specfile" is a
> packaging requirement, not a personal request.
It's not a requirement, it's only a SHOULD. If there are good reasons not to
do it, it's OK not to do it.
Kevin Kofler
Bruno Wolff III wrote:
> It didn't help that the names changed for F12.
Yeah, I think that name change was a mistake, but sadly my proposal to
revert it was voted down in FESCo.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com
that the buildsystem will not allow any official
> (non-scratch) builds to happen from a private-* branch.
And as I wrote before, I don't like this at all, it's a regression from our
current workflow and it defeats the point of the much-touted easy branching
with git.
Kevin Kof
Jarod Wilson wrote:
> On 12/22/09 2:45 AM, Kevin Kofler wrote:
>> And as I wrote before, I don't like this at all, it's a regression from
>> our current workflow
>
> Define "our".
"Our current workflow" = what Fedora's current CVS setup
;s standards
with proprietary extensions).
As the patent license is non-Free, Moonlight still has to be considered non-
Free wherever software patents apply. So as far as I can tell, this is not
acceptable for Fedora, sorry. (But of course spot and/or RH Legal will have
the final
urce code???
Some of the generated C code is not that different from the above. IMHO
generated code does not belong into source tarballs at all.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
e the old package before installing the new one.
Actually, it installs the new package first, replacing any files from the
old one without reporting them as a conflict, then removes the files from
the old package which are not in the new one.
Kevin Kofler
--
fedora-devel-list
few of us rely on this in their workflow). One branch
per distro version is not enough.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
body competent in C# tried to patch
MonoDebugger to work with the new Mono.Cecil and failed due to some
unsurmountable obstacle. If none of you Mono SIG folks is fluent in C#, then
that's a problem that needs solving first of all.
Kevin Kofler
--
fedora-devel-list mailing list
fedo
y. Using old components
just because they're audited is not the Fedora way, sorry.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
hat at least conforms to our packaging guidelines, I think this is
still against Fedora policies, in particular the Fedora Objectives. We want
to ship the current software, not old audited one. Fedora is not a certified
distribution, it's an up-to-date distribution.
Kevin Kofler
aging practice at this point?
Yes. Common practice in Fedora is to just use current software and forget
about audits. Fedora is not a certified distribution.
> Any alternative suggestions?
See above.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Michael Schwendt wrote:
> What's wrong with ABRT?
My main beef with it is that it reports its crashes to the downstream bug
tracker when really the right people to fix them are the upstream
developers. KCrash/DrKonqi is much better there.
Kevin Kofler
--
fedora-devel-list
n just because
it went through some sort of formal audit and/or certification.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
veral different versions of the same library
in a distribution.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
SIG folks might pick these up if nobody else wants
them. I'm hereby forwarding this to the fedora-kde ML.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
things pass basic packaging-level QA (builds and has no broken
deps) does not and should not require signing up to sort out any and all
issues with the package.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
in
the .ks because we refused to add it to @kde-desktop as it has nothing to do
with KDE).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
asn't aware that it didn't actually work at all at this time
and I strongly doubt the rest of FESCo was either. It makes no sense to have
a packaging guideline mandate using something which doesn't work.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@
than you claim or the new PolicyKit is just not powerful enough
to support everything the old one did, both of which would be bad things).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
rted is the big effort (and a
working PolicyKit-kde is important for things like PackageKit).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
el, either from the listing
> locale string or the regional setting. So Aussies, Kiwi, Singaporean can
> use their own flags (instead of American flags), everybody is happy. :-)
Please propose these UI improvements to KDE upstream. They have nothing to
do with Fedora's policy on flags in
Michael Schwendt wrote:
> [And as long as there is no F11 GA repo yet, you need to enable rawhide
> manually.]
Actually no, as the mirrorlists redirect you automatically.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/li
ematic, creating it outside of the US would mean
favorable tax laws could be chosen as well. That said, RH may still get
into trouble for contributory infringement, and with a non-US foundation,
RH may even get accused of tax evasion, so I'm not that surprised they
aren't thrilled by the idea
ignore by default. Why not have both? In fact that's what
Debian is doing: Recommends is 1., Suggests is 2., and of course the
default can be changed (you can choose to drag everything in or to ignore
even Recommends). So why don't we do the same in RPM and Yum?
Kevin Kofler
--
Pavel Lisy wrote:
> I know but I am not member of centos list
Then subscribe there. That was a really lame excuse for posting CentOS
questions to a Fedora development list.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mail
ping
things like hardware MP3 players without a license (even if the MP3 codec
is implemented in software), some devices got confiscated at CeBit.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
then the burden should be
> on them to maintain the list of packages that don't comply, not
> Fedora.
+1
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
t to name RPM Fusion, because the
content in RPM Fusion is not illegal around here. Oops, how many times did
RPM Fusion appear in this paragraph? ;-)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
t
didn't make any sense, instead there should be no restrictions other than a
license compatible with that of the kernel, and of course the restrictions
applying to all packages).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mai
by
using a Bodhi grouped update, which would make this much less of an issue.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
st every time, even to the modules
FESCo had previously approved as kmods (em8300, sysprof). They now sit as
kmods in RPM Fusion.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
bly not even his second language, I don't think he means what you
think he means.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
hat KMS is disabled on these chipsets. You
> seem to be saying it is actually enabled by default?
That's not the last change, it's the change in -164. The changelog is not
properly ordered.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ple caring about it need to organize a fork as soon as possible.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Jussi Lehtola wrote:
> For instance, creationists might consider anything that has to do with
> evolution (such as evolution simulations or gene programs) as
> controversial
Or even the mail client which happens to be called "Evolution".
Kevin Kofler
--
fedora-deve
edora packagers to do the work for you.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
st? All I care about is that the order is consistent!
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
aveats about those cases seem correct, though.
IMHO, Suggests(post) should just be an error, it doesn't make any sense
whatsoever. Things needed in scriptlets need to be hard requirements.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
installed, but we
don't have to do anything if it isn't, because it means it doesn't need to
run in the first place". It doesn't make sense to Suggests(post) anything
there.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ant to use the proprietary codec pack from M$ (yuck!).
So it's no use arguing about whether Moonlight itself is patent-encumbered
or not.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
get date very closely. :-)
But I don't see those slips as a big issue in the first place.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
a work branch and targeted for a later
release.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Matthew Woehlke wrote:
> It's too bad fedora-test-list doesn't seem to be on gmane (or isn't
> named obviously; gmane.org is being too slow for me to ask about the
> mail address).
gmane.linux.redhat.fedora.testers
Kevin Kofler
--
fedora-devel-list mailin
't see why it should be
the maintainer's job to play the relaying monkey. We're not carrier
pigeons. We can't even CC the reporter on the upstream bug unless they
register an account there, and at that point they can just as well file the
bug themselves.
Kevin
as the best solution to make sure the
> issues get to where they need to be.
And I'll add that we KDE maintainers will reopen the bug if it gets closed
UPSTREAM, but we feel it needs to be fixed within Fedora. It's not like
mistakes can't be easily undone.
Kevin Kofler
ple our KDE
gets upgraded to a bugfix release about once a month).
As maintainers, we will also try to CC ourselves on those upstream bugs to
track their status, but utilimately it's the reporter who cares the most
about seeing his/her bug fixed.
Kevin Kofler
--
fedora-devel-list
are we
to know whether it's fixed or whether we just don't have enough information
on how to reproduce it?) and/or refuses to report the issue to the people
who're actually able to fix it.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ier, the point is that the
information is required, those "complicated" forms are there to request the
information we need.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
).
> This occasionally applies to developers - To normal users it usally
> doesn't apply, they want "to have their issue fixed".
Then they need to do what it takes to get their issue fixed. Talking to
upstream, helping with tracking the bug down etc. are all part of that.
are the cause why at least some people sense a
> foul taste when listening to them.
Then let's say: Report bugs, to the right place of course (usually
upstream)!
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
uess other codebases where bugs are
expected to be filed upstream (e.g. Evolution, which was also brought up in
this thread) are similar.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
; need a co-maintainer(s) or less packages.
So do you volunteer to be the bug forwarding monkey for KDE SIG?
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ssarily want to just hope upstream will fix.
Of course, critical showstoppers need to be tracked within the distro.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
oncerned the issue is
closed. As for those cases where the upstream maintainer is the same as the
Fedora maintainer, in those cases the maintainer will still have an open
bug, the upstream one, he/she doesn't need 2 of them either.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-dev
7;t need a
patched GConf at all.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
tion of the
final times needs to happen much earlier (though thankfully the tentative
times which got announced beforehand were the final ones anyway).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ponsible for reporting it to the appropriate place,
* or the user does not care about having the bug fixed, that's fine with me,
we can just close it, less work for me. ;-) If somebody actually cares,
he/she'll report it upstream. If nobody cares, why bother fixing it?
Kevin Kofler
ository.
We can build a patched package if there's a fix to try, but that doesn't
mean the user shouldn't be CCed on or the reporter of the upstream bug as
well, it just means we should be CCed too (which we usually are, unless we
forget for some reason, we're just human too).
eam is quite rude. The users are
getting something for free, it's not their right to complain about the gift
horse saying they wanted a pony instead.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
issue is
how upstream would validate the e-mail addresses we're entering in the CC
list if we forward our bug (including CC) into their Bugzilla instance.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
f the bug is important enough to block one of our trackers, we won't close
it UPSTREAM, we'll even try to fix it on our own (and then upstream our
fix) if upstream doesn't come up with a fix soon enough. But we can't
reserve that treatment to every single KDE bug, there are too man
n.) But
until that happens, there's no reason for the packager to be involved.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ust need to write one or more specfile(s) which
follow(s) our guidelines.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Michal Hlavinka wrote:
> Yes, but how will you notice reporter needs (your) help if bug is closed
> upstream?
By CCing ourselves on the upstream bug when we close ours.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/li
is a service we do to end users. If they don't want to use the
service the way we provide it, that's fine with me, we can just close their
stuff as INSUFFICIENT_DATA and move on.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
many bug reports to keep track of all of
them.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
racked in a random
distribution's bug tracker?
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
de closed bugs.
> Also by closing unresolved bugs you are inviting duplicate bug reports.
Because Bugzilla is broken. See above. Let's fix Bugzilla.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
address I use
on the KDE Bugzilla is the same showing up in the "From" header of this
mail). AFAIK, Rex (rdieter at math.unl.edu) also likes to be CCed on those
bugs.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
're also welcome to reopen bugs if upstream has a fix and you want us to
backport it (but please don't do this if the fixed release is coming soon
anyway and the bug is not critical).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
bably because there's
nothing to fix. So maintenance workload and required skills can vary a lot
from package to package.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
never ever report bugs
Your misunderstanding is there: it's US maintainers that are helping YOU
reporters by fixing your bugs. If you think you don't need our help because
you don't care about the bug anyway, we can just close it as
INSUFFICIENT_DATA and stop there.
Kevin Kofle
sue for %{?rhel} when
we'll reach RHEL 10, which will happen in more or less 8 years if RHEL
continues at its current pace.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
any video player.
But HTML 5 with patent-free codecs is clearly the solution we should all
fight for! (But hardcoded checks for only Firefox aren't!)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Jeremy Sanders wrote:
> %if 0%{?fedora} >= 8
That should be:
%if 0%{?fedora} >= 8 || 0%{?rhel} >= 6
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
w output selection is
implemented, they use a backend-specific "GStreamer sink" setting in
addition to the standard output device setting in the Phonon API, with the
result that, last I checked, it didn't work out of the box with our default
PulseAudio setup).
Kevin
tion, Skanlite, should really go into Fedora. There was a
review request, but it got closed because the submitter vanished.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Ankitkumar Rameshchandra Patel wrote:
> There is yet another dependency of "internet connection" here...
An Internet connection (and a reasonably fast one at that) is basically
required to use Fedora effectively.
Kevin Kofler
--
fedora-devel-list mailing list
fedo
in, like it is in KDE and MinGW, we're not calling
kde4-config each time to figure out where to put files!).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
p a semi-working Moonlight with
no audio/video support in Fedora rather than RPM Fusion? That makes no
sense whatsoever.
And as has been said in this thread, Moonlight itself is also
patent-encumbered.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.re
yersinia wrote:
> In @rpm5.org, yes.
rpm5.org is not the upstream for Fedora's RPM.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
crashing users' browsers.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ple, it will be expanded to "%if 010 <= 8 || 0 <= 5",
> which will be true because 0 is less than 5. (I'm assuming that "||" is
> the "or" operator from C.)
Right, this shouldn't be ||, it needs to be &&.
Kevin Kofler
--
fedora-
Fernando Lopez-Lezcano wrote:
> On Wed, 2009-04-29 at 00:40 +0200, Kevin Kofler wrote:
>> Neal Becker wrote:
>> > rpmdb: Program version 4.7 doesn't match environment version 4.5
>>
>> You need at least RPM 4.6 on the host systems to build Rawhide packages,
&g
ed by the user.)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
uild tool first to generate a proper one).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ply
being co-owned by PolicyKit-gnome is the easiest solution (even if
technically less clean than a gnome-filesystem package).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Colin Walters wrote:
> On Tue, Jun 9, 2009 at 11:22 AM, Kevin Kofler
> wrote:
>> The makefile could also be autogenerated from an unknown build tool
>
> Makefiles generated by e.g. automake have easily detectable patterns.
> Try "head Makefile".
I wrote "UN
Frank Ch. Eigler wrote:
> Kevin Kofler writes:
>
>> [...] If the bug is important enough to block one of our trackers,
>> we won't close it UPSTREAM, we'll even try to fix it on our own (and
>> then upstream our fix) if upstream doesn't come up with a
1 - 100 of 604 matches
Mail list logo
