Rawhide Report wrote:
> New package SevenZip
> Java SDK for LZMA
Why was this approved and imported with that name when we clearly agreed on
this list that the name needs to be changed?
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
are some (really baroque) ways to hack around this, ask rdieter for
details, he's done it a couple times.
That said, the most reliable solution is not to turn a directory into a
symlink in the first place. Is this really necessary?
Kevin Kofler
--
fedora-devel-list mailing list
fedora
ke taking a Java binding or reimplementation
of Phonon and packaging it as "Amarok".
The name also fails to reflect the fact that you're only packaging the Java
version of the SDK. Given that the upstream LZMA SDK also supports C, C++
and C#, the Java one should really have "java
Tom "spot" Callaway wrote:
> kde-i18n-Spanish
> kde-l10n-Spanish
Is this problem limited to Spanish?
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
else? Unfortunately, that's the
impression I'm getting. :-(
> Involve the design team as well.
One of the most vocal people from the websites team in the discussions so
far is also one of the main design team members, so AFAICT it's already
involved.
Kevin Kofler
--
d send a self-addressed stamped envelope to
obtain it on one of those self-destructing CDs? ;-)
This is starting to feel like a hierarchical and very undemocratic society.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
eover all the features I mention were driven within Fedora.
And how is this relevant to the user? The user cares about what features
they're getting, not who has written the code for them.
> KDE does lack integration with them.
That word doesn't mean what you seem to think it means.
e LXDE spin is a fairly new spin. I don't know why it's not on
> spins.fedoraproject.org at the moment off the top of my head.
Because it hasn't gotten approved yet. So this situation is likely to
improve (making it hidden on spins.fedoraproject.org like XFCE and the
specialized
at he want. Give him enough information and he
> will decide.
Plus, I'd put the dash after KDE, not before KDE.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
. In fact, from a
mathematical standpoint, ALL voting systems are flawed, so things cannot be
fully democratic, only more or less so.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
27;s per definition
undemocratic.
> Now, instead of accepting that this how the system works we've spent
> nearly 3 days arguing about a decision which is DONE.
Decisions can be revised. If you aren't open to feedback from the community,
you are a bad representative.
Kevin Ko
t to be great. Getting continuously criticized along with other
fellow SIG members (most of which are also unpaid volunteers) for
supposedly not doing enough when we're even doing things the GNOME
maintainers are not doing (such as new version backports, both stable ones
in official updates and
DE SIG, nor to the work
of the XFCE, LXDE and Sugar SIGs for that matter).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
the issue. Kinda like a trial (at least in Europe) gets
reopened if further evidence is discovered.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ed them, I decided to go back to gnome.)
Well, the KDE desktop can be used without the apps and vice-versa.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
7;s what those who do the work (the Infrastructure team)
> decided to use. That's the same for the Desktop team.
>
> It doesn't take any policy to change this fact. It takes people
> willing to do the job where it needs to happen, in the right team.
>
> Just my thou
do it in our spare time?
What we're scoffing at is that some people are, in fact, treating them
differently, see e.g. the continuous "Where are your full-time employees?"
bullsh*t used by some people who will recognize themselves to discredit the
mostly-volunteer KDE SIG.
Kev
d the
KDE live image to remain mirrored over HTTP/FTP. And it also deserves to be
listed on the official download page!
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ht. I think you need to tune
down your brain's "spam filter". :-)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ty members would be dumb enough to
vote for instantly losing around 30% of our users.
> Maybe we should have Survivor: Desktop, where we can vote KDE off the
> island.
Was that supposed to be funny? It's not...
Kevin Kofler
--
fedora-devel-list mailing list
fedo
k I spent on Debian and Ubuntu
> ought to demonstrate that. I care enough about Fedora that I spend a
> significant amount of time working on it outside my paid hours. Many of
> the contributions I've made to Fedora are entirely out of the scope of
> my job, but I do it because I care
Ricky Zhou wrote:
> On 2009-06-29 01:13:07 AM, Kevin Kofler wrote:
>> The thing is, that's exactly the type of design GNOME is using and KDE is
>> rejecting, so you will never get KDE people to approve of this. And thus
>> following that policy makes our download page
ing" are a tradeoff)
KDE focuses on configurability. You won't get a KDE developer to agree to
not give the user any options.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Matthias Clasen wrote:
> Now I guess it would be my turn to feel insulted, and stamp my foot,
> because I do the majority of the stable Gnome updates. And yes, they do
> exist.
At the rate of one update per month to every GNOME package?
Kevin Kofler
--
fedora-devel-list mai
o think it means.
>
> I understand perfectly well what it means. It's just that you aren't
> willing to accept that they are integration gaps.
You're calling things "integration" which are just features, e.g.
fingerprint reading.
Kevin Kofler
--
fe
(within
>> Fedora), like sugar, XFCE, LXDE, etc...
>
> .. and this makes it even more important to make the right decision.
> Would it be right to provide a long list of desktop environments and
> live cd's associated within the download page or upfront within the
> inst
to improve over their design, in particular by
adding links to info pages about the desktops and 32 vs. 64 bit right next
to the respective choice. But removing choice is not an improvement.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/m
on't think I picked the
wrong packages for a comparison. (If you think I did, feel free to suggest
others.)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Josh Boyer wrote:
> It is not obvious to me without seeing comparison data as to why it's such
> a good thing to have numerous stable updates.
It's a good thing because those updates fix bugs, update translations and in
some cases add features.
Kevin Kofler
--
fedora-de
n just made it worse by splitting the efforts on KNetworkManager
into 2 separate codebases.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
and jreznik know him personally, so I'm
sure they'll package it (or get the author to package it) as soon as they
feel it's ready.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Ondřej Vašík wrote:
> As binaries will probably always differ
Differing ELF binaries are not a problem (RPM special-cases those),
differing shell scripts or symlinks are.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listi
at the qt package does and put the binaries
into %{_bindir} and the symlinks into the %{_libdir} subdirectory instead.
That way the conflicts will be handled by the standard ELF coloring.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/m
Jaroslav Reznik wrote:
> "I don't care" really scares me. If you don't care then system
> installation or using with live CD is not a job for you!
+1, and that's why the current design which is optimized for people who
don't care is broken.
Kevin K
>
> Anyone object? :P
I personally prefer a presentation like openSUSE's which shows all the
choices right from the beginning, I'm not a big fan of wizard-style
interfaces.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
downloading an operating system, you should be expected to care about
what you're getting.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
;t work with the implementations
which were Free Software at the time (GCJ/Classpath-based stuff).
I'm not familiar with the JavaScript story, but if he really recommended
against using it, there was certainly a valid reason.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-
should be listed first.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
rol (so
it's even more proprietary than the average proprietary software). If
you're using a proprietary web app, you're NOT using Free Software, but
proprietary software, even if the browser you're using is Free Software.
Kevin Kofler
--
fedora-devel-list mailing list
" argument just makes no sense
when you look at the facts. KDE is NOT poorly supported in Fedora. Our
manpower is limited (and yes, the way we present KDE is one of the reasons
for that!), but not insufficient.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
missing entirely on get-fedora-all, there's only a GNOME foot logo hinting
at it there. And in many places (documentation, ML discussions etc.) the
spins get referred to only by their title, so it makes a difference whether
that information is part of the title or just of some description w
t not a
random single voter's opinion (which will not match the opinions of the
other voters anyway, also considering that I also voted for myself).
Your counterexample is badly chosen.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mail
... which is bad. Users should get the x86_64 version by default if they
don't know what they have, it's the one which should be tried first, if it
doesn't work, they can always get the legacy version.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
d
Xubuntu). ;-) Maybe we should write a U Desktop Environment just to give
them trouble. ^^
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
basically what openSUSE is doing) MIGHT be borderline tolerable, but I
think even that is silly. Even a bad default (i.e. GNOME ;-) ) is better
than a random one.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
them by providing an information page listing
common 32-bit and 64-bit CPUs linked on the download page), they learn
their lesson. "Think before you download a huge ISO!"
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
want to use, we can't
ship them all, along with their respective -devel packages, on one spin.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
we
get big updates, not just minimal security patches. KSplice can't handle
that kind of updates. It can only handle small patches which don't change
any data structures. So the official Fedora kernel updates will never be
suitable to be distributed through KSplice.
Kevin Kofler
for the above purpose is very
> much questionable.
And many people who aren't using GNU/Linux yet will be running 32-bit
Window$ on their 64-bit CPU, so it'll report 32-bit.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ra kernels
(because they get big changes which ksplice cannot handle), unless you
start from the GA kernel and only backport security fixes, which makes the
kernel you provide become completely different from the current Fedora
kernel over time.
Kevin Kofler
--
fedora-devel-list mailin
crash.
Try Digikam.
su -c "yum install digikam"
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I'll do what I can to get it up for a revote based on the
feedback from this thread.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
different distro for each Desktop Environment.
... +1. :-)
That said, Kubuntu and Xubuntu aren't really completely separate either,
they're just marketed as such. They're really just spins from the same
repository. The way they're marketed as "separate" is really silly.
hould this kind of
> situation be handled?
You have to tell us what we need to change in KDE and give us the necessary
time to adapt, even if it means you have to wait for Fedora 13 to push this
change.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
tegration into browsers and how it ends up used. It basically hides
proprietary software in what users perceive as "content".
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ant to listen to my arguments, you were
just eager to shoot my proposal down no matter what.
> But hey, thanks for the unfounded assertion that everyone who voted
> against it was operating under false assumptions, and they could not
> possibly have any rational reasons for disagreeing with
assumption, as normally when
there's more than one asdf, you don't just say "asdf Edition", but "Foo
asdf Edition" to distinguish it from "Bar asdf Edition".
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ow having a desktop environment
with the same first letter as another would be a problem for Ubuntu as
well.
That said, I do agree that having our spins presented as separate projects
is not the way to go.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www
aving to do with it as well (but no, I
don't use tinfoil hats or similar nonsense ;-) )). Home users with record
uptimes are a small minority, even if there are probably many of those on
this list.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https:/
first place. Just breaking
other packages with an incompatible change without giving them a chance to
adapt is the quickest way to degrade Fedora's quality.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
is: what if the unmount fails due to open files? Your
suggestion to just kill the applications sounds really broken to me. A
forced unmount at kernel level and failing any attempts to further access
that file just like what happens when an NFS mount goes offline sounds like
a better solution to m
eases.
Some software may need the new version to build.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
) If you're talking about torrent.fp.o, the descriptions on that are so
> bad that there are a whole host of things that need fixed before one
> filename.
Still, having "GNOME" in the name would at least make it automatically show
up there and everywhere else.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
) If you're talking about torrent.fp.o, the descriptions on that are so
> bad that there are a whole host of things that need fixed before one
> filename.
Still, having "GNOME" in the name would at least make it automatically show
up there and everywhere else.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
would happen at boot.
The paper or web page (I don't remember exactly) I've read talked about this
limitation. But maybe that information is outdated or this is just for
automatically generating the fixes and you can do more complex stuff by
manually writing fixup code.
Kevin Kofler
Frank Schmitt wrote:
> I think most people hibernate or suspend when they go to sleep.
Those people must be trusting their hardware and software (drivers in
particular) a lot more than I do. ;-)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
ht
; more than
I'm "for CMake". It's just that in the past I could just say "don't use
autotools", now I have an actual alternative to suggest.)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
hat that's partly due to us not always being
> emphatic about warning them of it. Sometimes it feels like failure.
Maybe the last update to any EOL distro should be a firstboot-like tool
which just gives 3 options:
* Run preupgrade
* Wipe all hard disks
* Turn off computer
Kevin Ko
Seth Vidal wrote:
> yum install system-autodeath
That just turns off networking (so then how do you preupgrade from there?
And it lets people keep running their obsolete stuff forever in their
closet) and it has to be explicitly installed.
Kevin Kofler
--
fedora-devel-list mailing l
Jochen Schmitt wrote:
> Am 01.07.2009 17:16, schrieb Kevin Kofler:
>> Those people must be trusting their hardware and software (drivers in
>> particular) a lot more than I do. ;-)
> This behaviour is not right in the time of climatic change.
Whose behavior? Turning the compu
ee (and I like how this has been the default in CMake since forever),
but we were told that this is no good for Fedora because we should have the
full command lines in build.log so we can check for the optflags.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
um is a serious regression and we need a
matching Anaconda update ASAP.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Peter Robinson wrote:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113
Unrelated to this issue, but please use "make V=1" so we see the actual
build command lines in the build.log (see the thread about the new
automake).
Kevin Kofler
--
fedora-devel-list mailin
he World in 80 Days (which is in the public domain)
as well? What exact criteria make Dive into Python OK and Around the World
in 80 Days not?
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Miroslav Lichvar wrote:
> kdeedu-4.2.95-1.fc12
kdeedu only uses readline in KAlgebra which is GPLv2+ (and only in the
command-line version ("calgebra") at that), so no problems there. (I also
verified that "calgebra" doesn't use any GPL v2 only libraries.)
Ke
going to help editline and thus a BSD-licensed implementation.)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
they're in a
directory containing special characters.
> at least many that use motif or the athena widget set.
Those applications are obsolete by definition.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Bojan Smojver wrote:
> Now that .1 is out, is there anything in particular stopping F-11 from
> having this kernel?
And why is F10 still stuck on 2.6.27? 2.6.29 has been in updates-testing for
ages now.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
Pete Zaitcev wrote:
> It sure was a fabulous debut as a maintainer for Andreas (according
> to changelog he took over from Jakub).
Hey, we all make mistakes, it's no use insulting people over it! Was that
sarcastic remark really necessary?
Kevin Kofler
--
fedora-devel-list m
Conrad Meyer wrote:
> Unrelated, but I think this sort of phobia of regenerating an
> auto-generated script just goes to show how completely broken autotools
> is.
+1, "auto-generated source code" is an oxymoron, this design is really
broken.
Kevin Kofler
--
fedora
cial permissions). The GPL requires you to edit the preferred form for
modification, which is definitely NOT a generated file.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
patching a generated file is dirty,
can be hard to do depending on what you want to patch, leads to patches
which can't be upstreamed and, if the source code is GPLed, violates the
GPL.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
f -i -f" with
the latest autotools updates of the version of Fedora I'm currently running
and ignore all the warnings.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ow with it on some extreme
testcases.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Matej Cepl wrote:
> Ralf Corsepius, Fri, 03 Jul 2009 21:29:46 +0200:
>> I thought, we banned all non-utf-8 aware packages?
>
> And BTW zsh has been fixed not to corrupt non-ASCII filenames?
Bash FTW! :-p
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-
nd-Of-Life for a given release and 3 releases to
> choose from -certainly a lot more time then 1 month and 2 releases to
> choose from.
They already have 7 months of time to move to the next version. It's just if
they absolutely want to skip a version that they only have 1 month.
Sam Varshavchik wrote:
> How exactly would that violate the GPL?
You aren't patching the actual source code.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
supported after
all. And no QA, if it breaks, you get to keep the pieces. Again, it's
unsupported, that means what it means. I still think it's better than not
getting any security fixes at all.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ssed off as such
(which is why the autotools are broken by design: it's a mistake to
encourage shipping generated files in a source tarball).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
the issue for all subsequent builds of CMake-using software (unless my
fix is incompatible and I have to introduce a "policy" for it, then they
need to opt in to the fix). If I fix a bug in the autotools, some software
may never pick it up, and the one that will may take years to pick it
top using autoconf because it is not designed for
doing things right.
And in fact KDE did just that (they moved to CMake and nobody at KDE is
missing the autotools, quite the opposite!) and several other projects
followed suit.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Sam Varshavchik wrote:
> Gee, I didn't know that rediffing is a mandatory step.
It is when your patch no longer applies after you upgraded the package to a
new upstream version.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com
John Poelstra wrote:
> This checkpoint is important to know if currently accepted features are
> on track for a successful Fedora 12 landing or if contingency plans need
> to be considered at Feature Freeze as we prepare for the Alpha release.
… for the what? ;-)
Kev
ailing list for this renaming
proposal has been overwhelmingly negative, but maybe that was just me
getting a wrong impression? Personally, I don't care strongly about the
naming anyway, be it "beta", "alpha", "test1" or whatever. :-)
Kevin Kofler
--
f
r me, this design is inherently broken, just like bundling libraries is
(and Fedora has policies banning the latter in most cases), for the same
reasons (bugs getting copied to all packages), and I fail to see any
advantage of that way of working.
Kevin Kofler
--
fedora-
to the scripts needed at all.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
y with a lot fewer irrelevant changes
like line number changes or changes in aclocal snippets (because upstream
WILL regenerate the file, not surgically edit it!), so it's a lot less
likely to produce fuzz.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list
individual packages for upgrading is just unsupportable.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Jeroen van Meeuwen wrote:
> "Fedora End-Of-Sales" or something (please avoid the Legacy or LTS names).
End-Of-Sales doesn't make a lot of sense for something which isn't sold…
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https:/
e" away. So what's the point of generating POSIX shell code
into each and every tarball?
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
201 - 300 of 604 matches
Mail list logo
