y?
Yes, but having a spin with them already on it is much simpler for its
target audience. (That said, I wouldn't use it since they moved away from
KDE to GNOME. :-/ If I needed FEL, I'd rather either groupinstall their
comps group on a KDE spin install or install individual apps.)
t; on advisory-board. Is there a particular
> reason you did not respond there?
Probably because it's yet another mailing list most maintainers don't read?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
s should be able to do. I'd certainly help
getting things to build if I'm not extremely busy with other stuff.) If not,
I guess we have no other choice than dropping support for the module with
the new kernel.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
ht
Koji
that the unexpanded macros show up, but also in the shipped SRPMs!
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
FPC guideline, as I don't see why we should block it. Valid reasons
have been given for why this is bad and Nicolas's counterarguments just boil
down to laziness.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
#x27;compliance
> with 2010 guidelines is planified after full-distro compliance with 2008
> guidelines is done' game.
You don't have to enforce this, we can assign any provenpackager to do so.
For new packages, it should be part of the review checklist.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
s.
PS: This was already discussed in the 2010-01-08 FESCo meeting and we agreed
the unexpanded macros are a problem and tasked the FPC to come up with a
guideline to ban them. So I don't see why we'd block the guideline now.
Nicolas's arguments don't convince me at
so present). It was decided that this was not worth the effort and that
using macros in SRPMs in this way is not something we want to support.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
th it as sys-admin.
>
> Worse, in this case, I feel the Fedora community is being abused to
> evaluate a semi-functional piece of SW's "yet uncooked" concepts.
+1. ABRT is just broken in so many ways it's not even funny and should never
have been shipped in its curren
ght thing to do.
+1, in fact that's the biggest design failure in ABRT (in its current state)
and basically makes it useless. Gathering backtraces is something that needs
to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not
distributions.
Kevin Kofler
--
d
seless.
There's no way I can fix the dozens of crashes in Gnash myself.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
E), the next release with
the fix will be pushed soon anyway.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Michael Schwendt wrote:
> As a last resort, software could get retired and removed from "The
> Product".
I'm not sure not shipping something at all is better for the user than
shipping it with bugs, even if they never get fixed. Often even a buggy
software is better than no
ot;-devel" is not enough to
give you the SRPM name).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
sked around on IRC and
> their mailing lists, but there didn't seem to be any solutions.
You could probably try to rebuild the updates you need within your personal
repo, then your builds should pick them up. But indeed this really sucks.
Kevin Kofler
--
devel mailing list
devel
reason why the KoPeR proposal went nowhere.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
days, as all the
other stuff using the Kipi framework has moved on to KDE 4). And it's not
like its featureset is unique (it's just an image viewer). I'd recommend
that users of ShowImg migrate to Gwenview or some other actively maintained
image viewer.
Kevin Kofler
--
d
umber of affected packages (which surprised even
me, it's even worse than I had expected), and that any attempt to discuss
this further was met with "we've already moved on to the next feature".)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ing to traceroute, build.opensuse.org appears to be in Nürnberg,
Germany, not in the USA.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Till Maas wrote:
> This sounds like it should have been retired instead of only orphaned.
> Do you happen to know, why it wasn't retired?
Because the Fedora maintainer for the package was AWOL and didn't bother
retiring it. It will be retired now if nobody picks it up.
ut postponing it to F14 would at
least give packagers time to fix their packages.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
; you can submit the changes into rawhide quite soon and
> everybody has time enough to work on it.
+1. Why does this get rushed into F13 the day of the feature freeze?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ck whether some of
them would better be retired altogether, which is understandable.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
tion from pre-branch Rawhide"
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
am, they don't
seem to understand what "backwards compatibility" means. That doesn't mean
it's a good idea to break code like this.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
so enables -fms-
extensions by default (in C, this allows at least unnamed struct/union
fields). I haven't been updating TIGCC's GCC in a while, but I'm sure that
if I do, there'll be another bunch of such patches to add. And that's only
for C, g++ is much worse.)
de"
Sadly, this proposal got rejected. :-( (My own vote was the only one in
favor of my proposal.)
So any complaints about the breakage should be directed at FESCo.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
e an
obsolete KDE. :-(
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
anyway, even if you use those
installer-DVD-only respins, and installing from the KDE Live CD is
recommended.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
moment,
I'm not complaining that they aren't shipping 4.4.0. I'm complaining that
they're shipping 4.3.4 when 4.3.5 is current in the stable updates.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
the GNU project (which GCC is supposed to be a
part of) to make it easy to compile code with other compilers!
> Do you consider vendor lock-in through embrace-and-extend tactics to be a
> good thing when a free software project does it?
Yes, see above.
Kevin Kofler
--
dev
Ryan Rix wrote:
> On Wed 10 February 2010 7:00:42 pm Kevin Kofler wrote:
>> It's not in the interest of the GNU project (which GCC is supposed to be
>> a part of) to make it easy to compile code with other compilers!
>
> If that is the case it is extremely short si
getting them now, and the longer we take, the more complaints we get).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
silly, ld now gratuitously
errors on "undefined" symbols which would be found just fine at runtime. I
really don't see why ld is implementing different semantics than the runtime
ld.so.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.f
27;t think anything else is
> likely to be using that library. Having three libraries doing almost the
> same thing seems excessive.
Yeah, please package the LZMA SDK as lzma-sdk, the sooner we can get an
LZMA-enabled squashfs, the better! (The KDE spin could really use the
ll, I don't think we should wait just to
wait. ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ime, creating a -libs package appeared to be
> incompatible with the licensing. [Today "LZMA SDK is placed in
> the public domain".]
Could we build a lzma-upx-static subpackage out of the LZMA SDK SRPM
shipping a lzma-upx.a built with UPX's adaptations and which UPX would
for this concept yet, and we've just been
> calling it "Pending".
Nextrelease? It clearly says what it is and it'd allow us to give that
NEXTRELEASE state in Bugzilla which is currently almost never used (except
for reviews because the guidelines say to use it) a useful purpo
tical at all
use functions from libm such as floor, so this separation looks pretty much
obsolete (and in fact several other systems, such as Window$, don't
implement it, and libm is either absent or a dummy to make -lm work).
Kevin Kofler
--
devel mailing list
devel@lists.fedorap
Orcan Ogetbil wrote:
> This implies that you rarely do package reviews. Busted!! :)
I usually use scratch builds for reviews. Only quick reviews of dependency
chains need local builds.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.
at POT is up-to-date with latest strings.
Please note that this applies ONLY to packages translated by the Fedora
Localization Project. Upstream projects have different translation schedules
and string freezes.
Kevin Kofler
--
devel mailing list
devel@lists.fedorapr
-lived the "no default xorg.conf" idea was, now we get
default xorg.conf.d snippets. :-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
For
GNOME, the touchpad UI has been installed by default for a while now.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
tatic repos pointed to the right location.
Why not use dist-f14?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
d!
> I think we still need to be able to treat F-13 different than in the
> released branches, at least before beta freeze. If we need to do things
> in rawhide first and only push these changes to F-13 afterwards, a
> feature with a tight schedule like Xfce 4.8 is lost. That's ju
> to stable, because a qt override is in the buildroot.
The solution there is to talk to us, we can get the Qt 4.6 stuff off the
buildroot for a while so he can build his bugfix update. That's what
#fedora-kde is for. (IRC is the best communication method for this stuff
because it's r
ey were required to fix a bug, API change in something like kdebase-
workspace which doesn't have a guaranteed API/ABI (requiring e.g. kdeplasma-
addons to be built against the latest kdebase-workspace) etc.
XFCE may be similar.
Kevin Kofler
--
devel mailing list
devel@lists.fe
13 branch existing. But I guess the decision has already
been made.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
changes! Please only push updates if you have actual user-visible
changes.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
hat said, if the SVN snapshot fixes some important bug, I'd consider
pushing it, depending on how long it is until the release.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
zones.
I think that'd be a good idea. My tag requests for buildroot overrides
usually only get processed when rdieter is up, even if I file them in the
rel-eng Trac. ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
n different special tags. Depending
on which of the builds "wins", one or the other dependency will be broken)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
same time,
we coordinate builds and buildroot overrides on IRC and then I end up going
to sleep an hour or two *after* him. ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it use wildcards to select the files to copy in,
e.g. libntfs-3g.so.*, instead of hardcoding the exact names? That way you
wouldn't have to care about this kind of file deps at all, it'd just work
always.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://adm
en it can't be avoided.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
much better than having the package
uninstallable every other day as it is now).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ave a similar format and same permissions but do
> not create this warning.
>
> What am I doing wrong?
Check the library's DT_SONAME field, it should be libxmlrpc.so.3, not
libxmlrpc.so (which I suspect it is).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ce*, or else
> they have said that they want to be nagged.
I also think that makes sense, but the PolicyKit 1 developers don't. :-(
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I'd suspect a parallel make race.
Try building without smp_mflags.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
message was
not clear enough. Please double-check before you hit that "push to stable"
button! Thanks in advance.
We will look into using some less dangerous process (special build tags?) for
future Qt updates as this is just not working, but for now please be careful.
Ke
ou aren't building against a newer Qt from a buildroot override!), Qt
4.6.2 is now queued for the stable updates (it was decided in today's KDE
SIG meeting to push the big Qt 4.6.2 / KDE 4.4.0 / SIP 4.10 update set out),
so this particular version bump should no longer be a sour
the modified update for the next push.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
and we may well try out this approach with KDE 4.4.1.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ones is)
looks quite sensible to me.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kevin Fenzi wrote:
> This would of course need to be a new package that would either not
> conflict with or simply obsolete/replace the existing man-db package,
> right?
I'd say Obsoletes/Provides is the best solution.
Kevin Kofler
--
devel mailing list
devel@lists.fed
F12, but not F13. As
F13 is frozen, it will NOT automatically pick up a build, you need to push
it through Bodhi as well (and stuff pushed at this time will end up in the
F13 release, not in updates). So you're breaking the upgrade path. Please
also push this to F13 in Bodhi.
Kevin
issues, or get more features when rebuilt against a newer Qt.
But as you did not include a Bugzilla reference nor any other form of
rationale, I can't figure out why you rebuilt this particular application.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraprojec
y to
rebuild anything. Sadly, binary compatibility has been lackluster in recent
times. :-( )
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Matthew Garrett wrote:
> What do those numbers mean?
They're documented in the specs.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
st agree with
me, please reply so the other FESCo members don't think it's just me!
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Christof Damian wrote:
> Will there be a minimum number of days a package has to stay in testing?
I have no idea. I'm against any minimum number of days, but I'm against the
whole proposal anyway.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproj
s
>> very low.
>
> The possibility to publish hot-fixes is most important.
+1. Not being able to push those out quickly would really suck.
>> * A trivial bugfix (like a one-line diff), tested and confirmed to fix
>> the bug by at least one person. The risk of breakage is
identical.
Well, I'm not sure this is a big factor in this particular case. The
conflict of interest is more apparent in other situations, e.g. good luck
getting a broken upstream default fixed if upstream is also the Fedora
packager. (See e.g. spatial Nautilus, for which it took years for
, then why should the fix have to go
through testing? It can't make things worse if the app is already broken,
and clearly nobody is using both updates-testing and that app.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
g an update if nobody cares?
Because the people who don't run updates-testing care and complained about
the issue? Because you don't know how many more users are having the issue
and not bothering to report it (and of course if they don't even bother
reporting the issue, they
table anyway. For a one-line fix, that's usually
more than enough (and when it's not, the maintainer knows why, e.g. if that
one line enabled a 1-line feature).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
r
even FESCo as long as 1 FESCo member is enough to approve it, not a vote.
And no, I wouldn't blanket-approve everything as I have been accused of in
the meeting, please quit the paranoia!)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedorapr
enter updates-testing. Even if pushes become more frequent, it can still
happen if testing is called for on a fast medium like IRC and the fix
touches many people.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
drago01 wrote:
> On Fri, Feb 26, 2010 at 1:43 PM, Michael Schwendt
> wrote:
>> [...]
>> Unconvincing, though. History has shown that some packagers still managed
>> to push new packages that suffered from broken deps [..]
>
> Well than the review process faile
ly
> haven't done enough packaging -- though seeing who is in FESCo, it looks
> quite strange to me since some members are seasoned packagers and some
> even were here before bodhi.
Yeah, it quite surprised me that I was the only one seeing a need for this
feature in FESCo!
stalled).
That won't solve the problem that people aren't using updates-testing in the
first place. We can't force them to.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Jesse Keating wrote:
> On Fri, 2010-02-26 at 14:55 +0100, Kevin Kofler wrote:
>> > The possibility to publish hot-fixes is most important.
>>
>> +1. Not being able to push those out quickly would really suck.
>
> What sucks more is recent "hot-fixes" whic
. Only the
newer Plague setups (EPEL, RPM Fusion) included a testing repo.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
erent target audience, they're conservative
users who resist change and who are used to bugs staying unfixed for a very
long time if they're not considered critical enough. What works for that
audience does NOT work for Fedora's user base.
Kevin Kofler
-
ree that banning direct stable pushes even for security updates
would be even more insane.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Josh Boyer wrote:
> There is no proposed policy yet. What you are replying to is Kevin's take
> on a discussion that was supposed to lead to a policy being drafted.
Yet it would almost have been voted with no clear policy, it was just mjg59
pointing that out which stopped that.
kagers could be talked to.
Yes, there too, it's a people problem, it needs a social solution. Technical
"solutions" will cause both false positives and false negatives and just
cause more trouble.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it, you have to, we voted it through already" is
not transparent.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
omewhat more likely to be affected than bugfixes to existing ones.) Most
often what works on Fedora n also works on Fedora m. It's not like the
reviewer tested on Slackware or OS X. ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
now
> after seeing so many policies and rules for maintaining packages for
> Fedora releases.
This is not policy yet, we still have a hope of stopping the madness!
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Jesse Keating wrote:
> On Fri, 2010-02-26 at 16:17 +0100, Kevin Kofler wrote:
>> Most
>> often what works on Fedora n also works on Fedora m. It's not like the
>> reviewer tested on Slackware or OS X. ;-)
>
> "Most often". Sure, that seems good enough t
ners clearly cannot do it
> themselves.
No, it means we need to educate our maintainers better so they can make the
right judgement on a case by case basis (as they're getting it wrong in some
rare occasions), not overzealously ban everything.
Kevin Kofler
--
deve
RA-2010-0968
> (since 2010-01-24)
IMHO you've waited way too long on these already, I hit "push to stable"
after a week of no negative feedback on my updates. If nobody complains,
that's probably because it's working fine.
Kevin Kofler
-
ey'd use something
else. There are plenty of conservative or semi-conservative (à la Ubuntu:
new stuff in releases, few to no updates to releases) distros out there. Why
should we be another one?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedor
people should use a more conservative distribution. Try CentOS maybe.
Frequent updates are an integral part of the Fedora experience.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
g out the baby with the bathwater by dropping that. If we blow up
our niche, we have no place to live anymore. But enough metaphors, the point
is that if we do everything the same way as Ubuntu, there will be no reason
for people to use Fedora over Ubuntu.
Kevin Kofler
--
devel mail
to be a reason to push something. Updates for a new
upstream release of the "fix crash on OS X" type have no business being
pushed (duh). But most often, those updates DO fix bugs which affect Fedora.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
make sure future updates of the same type can get
closer scrutiny. (Apparently one characteristic was touching config files,
which seems to be a flag to me, config files by definition vary from system
to system.) But banning all direct stable pushes surely isn't the answer.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
broken and which also doesn't
break things for users, e.g. cause surprise backwards-incompatible changes
to config file formats, data formats etc. Except for the occasional (very
rare) screwup, our stable updates are like that. Even updates-testing is
already too bleeding-edgy.
between us and Ubuntu. (I know there's also the
licensing stuff, like Ubuntu bundling proprietary drivers, but that's not
that big a difference in practice, it's not like those drivers cannot be
easily removed (or added, yuck!).)
Kevin Kofler
--
devel ma
501 - 600 of 4625 matches
Mail list logo
