Richard W.M. Jones wrote:
As discussed, this list isn't quite correct, but it's the best
I've got at the moment.
We need to rebuild kdeedu too, it links statically against ocaml-facile.
(And ocaml-facile needs to be in the buildroot overrides for that.)
Kevin Kofler
--
devel mailing
Kevin Kofler wrote:
We need to rebuild kdeedu too, it links statically against ocaml-facile.
(And ocaml-facile needs to be in the buildroot overrides for that.)
Oops, actually, make that kalzium. kdeedu is now a metapackage, the apps are
built separately.
I'll take care of it.
Kevin
. It shows up on the web interface as filed by you, in any case.
I rebuilt kalzium and added it to your update a few hours ago, it has been
included in the current testing push.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
why we should be granting this type of exceptions.
libexec and share exist for a reason. Helper binaries need to be in libexec,
unit files in share, I think allowing systemd to dump everything (and in
particular 64-bit stuff) to lib is setting a horrible precedent.
Kevin Kofler
--
devel
those which switched to gold, which always behaves that way). It's
still not the default in upstream ld.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Jiri Moskovcak wrote:
- not sure if this is the right ml
It's not. ;-)
kmod-nvidia is definitely not in the official Fedora repos, it's in
rpmfusion
Right, thus this belongs to rpmfusion-devel.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
layout enforced
through systemd upstream, rather than having it diluted in the name of
consistency with other distros. And if it doesn't, it's too bad for the
other distros, why should we care?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
placed in /etc/; moving the binaries would break users'
configuration).
Guess what, the documentation needs to be updated.
Systemd as is does not conform to any sane file system structure. This MUST
be fixed, even if it means breaking compatibility.
Kevin Kofler
--
devel mailing list
did).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
PulseAudio to the latest version in an update.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
of newer ones.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
don't know any other suitable Free replacement for Arial Narrow.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
sometimes
have really horrible ideas about how their software should behave (by
default)).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
-nested list (because I don't use anything other than
Fedora anyway). Thankfully, grubby does that and I'm not rerunning grub2-
mkconfig at all.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
symbol versioning, so
upstreams are often reluctant to using it. :-(
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
with kickstarts). The next update of the
package legitimately owning the file will destroy any changes made to the
file (except if it was marked %config(noreplace), but files outside of /etc
must not be marked %config nor %config(noreplace) according to our packaging
guidelines).
Kevin
theater in an attempt to enforce monopolistic restrictions
(which are already being put into practice on ARM devices by the monopoly,
so it's not just a theoretical possibility).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
checking at all, no Restricted Boot needed.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is really a PITA to use, pinfo is much better.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
Likewise, this should be doable through /etc/kde.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
config may
be calling localectl or editing vconsole.conf directly.
KDE indeed doesn't do it systemwide. We really need system-config-keyboard
fixed! This should have been a release blocker. :-/
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
useful.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to kill anybody, whereas upgrade
path issues are bugs that must be fixed ASAP.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Paolo Bonzini wrote:
Of course (BTW the Automake maintainer now confirmed to me privately
that he'd accept such a patch), though it would probably would make
sense to put it in Fedora even before 1.13.2.
+1
It's time to stop breaking backwards compatibility willy nilly!
Kevin Kofler
!
And are we content to ship a completely nonfunctional placeholder image
which, maybe, if developers get around to pushing suitable updates, upgrades
into a working distribution? Some amount of functionality must be working in
GA, or it becomes a farce!
Kevin Kofler
--
devel mailing list
on.
FeaturePageObsolete? Which could carry any feature that was intentionally
withdrawn or that has been in FeaturePageIncomplete for too long.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
and
incompatible default, it's really insane that we shipped F18 with this
feature.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
increased by an order
of magnitude since Fedora's inception, and even 2 orders of magnitude
compared to older RHL releases.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
MiB
| Recommended RAM for graphical: 1152 MiB
A 12-fold increase since the inception of Fedora.
(For F18, the memory requirements are entirely undocumented in the release
notes.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Bill Nottingham wrote:
Honestly, I'd be curious as to whether we could get all the compatibility
testing done early enough, and packages changed, such that we could
consider dropping MySQL. It's just... cleaner.
+1
Shipping both is a mess we really want to avoid.
Kevin Kofler
providing the symbols is not enough due to the very change which is causing
the problems.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
vital /
common enough to block a release.
The problem is that gvfs also uses FUSE (AIUI, it can work without, but FUSE
mounting for the benefit of non-gvfs-enabled apps is enabled by default).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Steve Grubb wrote:
Digging into this further, if you run lsof, it hangs when it gets to
~/.gvfs:
It is possible to disable FUSE mounting in gvfs, see:
http://lists.fedoraproject.org/pipermail/users/2009-August/084569.html
Kevin Kofler
--
devel mailing list
devel
to work around that.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
New package font-manager
A font management application for the GNOME desktop environment
New package iwl5150-firmware
[and it ends here]
The report got truncated yet again. :-(
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
not the answer you were looking for. ;-)
libbsd sounds like a decent solution, probably the best you'll get due to
the conflict cited above.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
and I haven't seen any evidence
as to the contrary (again, the PackageKit example is not applicable because
the PackageKit maintainer did NOT have such a list to go by when he made his
change; there's no reason to believe he'd have made that change in spite of
it).
Kevin Kofler
Liu Yu Fei Eric wrote:
I noticed firefox was stuck on 3.5.6 for a rather long time.
What about 3.5.7 and the recently 3.6? They are even not in koji.
http://blog.famillecollet.com/post/2010/01/22/Firefox-3.6-en
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
policy as being necessary. We
have a set of guidelines, maintainers should follow them, why do we have to
police them? As I explained before, there is no evidence that this is
necessary or useful. The PackageKit issue was caused by lack of a policy,
not lack of enforcement.)
Kevin
sense for yum to reject --enablerepo=rawhide for
anything other than a full upgrade.)
This is what repositories like Remi's are for!
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
version of IcedTea with a new plugin which supports Firefox 3.6 is
being imported into Rawhide. This would have to be backported if Firefox 3.6
were to be pushed to F12.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
as expected due to dependencies and reverse dependencies.
(IMHO, it might make sense for yum to reject --enablerepo=rawhide for
anything other than a full upgrade.)
This is what repositories like Remi's are for!
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
it's
successful, you have to redo the build as a real build, so you waste one
build. With my workflow, you save that build. Saves both Koji resources and
your time. Also saves your time over local mock builds where you also have
this one wasted build problem.
Kevin Kofler
--
devel
that this are packages which were previously in Fedora and are being
resurrected.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
() work on a copied tuple
(the metadata updates flood is too racy IMO).
- Fix tuple_copy().
This style is not compliant with the Fedora packaging guidelines.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
, netinstall).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Nicolas Mailhot wrote:
Sure it is, it's changelog style #3 of
http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
No, it's not style #3. It's 2 or more style #3 entries collapsed into 1,
which is not one of the allowed formats.
Kevin Kofler
--
devel mailing list
devel
removed it in
Rawhide:
https://bugzilla.redhat.com/show_bug.cgi?id=561001
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
, then have comps defaults
conditionalized on the selection made there. Until/unless that happens, we
cannot recommend the installer-based spins to KDE users.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
drivers included in
Fedora.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
anybody to use the KDE options. Despite rumors to the
contrary, KDE carefully choses sane defaults. But you still get the option
to override them if they don't match what you like or what you need.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
to a system installed from the GNOME spin is
*supposed* to work! Removing GNOME, on the other hand, is near-impossible.
Hint: yum groupremove does not and cannot work for this purpose.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
Josh Boyer wrote:
On Wed, Feb 03, 2010 at 12:44:08AM -0800, Ryan Rix wrote:
On Tue 2 February 2010 9:10:13 pm Jesse Keating wrote:
What functionality has been lost here?
Working KDM, for one... Installing from the live DVD (as Kevin Kofler
mentioned earlier) is essentially broken if you want
something lightweight and/or netbook-oriented) to choose from as equal
first-class citizens.
(And FWIW, I really don't see why the Fedora Project insists on abusing the
word Desktop to mean GNOME.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
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.)
Kevin Kofler
--
devel mailing list
devel
. 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
expands to scriptlets and %files sections needs to
go where the scriptlets and %files sections belong, NOT in the Summary where
it will be wrong in the SRPM. The problem is that it's not only within Koji
that the unexpanded macros show up, but also in the shipped SRPMs!
Kevin Kofler
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
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
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 all.
Kevin Kofler
--
devel mailing list
devel
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
.
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 current state.
Kevin Kofler
--
devel mailing list
.
+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
--
devel mailing list
of crashes in Gnash myself.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
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 nothing.
Kevin
name).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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@lists.fedoraproject.org
https
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
-branch Rawhide
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
/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.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
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
. :-(
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
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 sighted of them.
That was a statement
).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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.fedoraproject.org/mailman/listinfo
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 saved
space!)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https
to
wait. ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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 purpose.
Kevin Kofler
--
devel mailing list
devel
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.org
, 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
dist-f14?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
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
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
be avoided.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
uninstallable every other day as it is now).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
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 source of trouble.
Kevin Kofler
--
devel
with KDE 4.4.1.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
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.fedoraproject.org
https
and 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
, 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.fedoraproject.org
https
, binary compatibility has been lackluster in recent
times. :-( )
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.fedoraproject.org
https
401 - 500 of 4304 matches
Mail list logo
