> I've been actually using dnf5 daily and while it's a little rough
> around the edges it seems usable enough.
I agree, I would like to see dnf5 staying in rawhide.
Otherwise I don't think it will receive sufficient testing.
> (1) The allow_vendor_change option makes things strange. I think
Dejavu was default font in Fedora for many many years, so many packages still
rely/assume it.
Likely more than necessary, eg in current Fedora Rawhide...
$ sudo dnf repoquery -q --whatrequires dejavu-sans-fonts | grep -v i686 | wc -l
43
After the new `default-fonts` Change for Fedora 39, one
> I would like to point to a problem with the current config regarding Arabic
> font.
> For Arabic text, The dejavu sans is still being displayed in many webpages in
> firefox
> instead of the noto sans.
> However, when switching the system language to arabic, firefox correctly
> displays noto
> Members of the Fedora Engineering Steering Committee (FESCo) would like to
> express their gratitude to Ben "#action bcotton" Cotton for his tireless work
> as - both the most recent and last - Fedora Program Manager (FPgM). We were
> surprised to learn that his role had been eliminated in the
Thanks for this feedback.
Not sure what happened :-( but I am rebuilding them now (mkvtoolnix was
expected).
Cheers, Jens
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> /var/cache/ibus
I filed a bug for this one.
Thanks, Jens
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I think python3-enchant is sufficient anyway: I updated the wiki page to
reflect that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I added a `master-rename` command to fbrnch too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
> On Fri, Feb 05, 2021 at 03:35:27PM +0100, Vít Ondruch wrote:
> The issue being that if one of the step fails in one of your clones, the
> entire
> loop will stop and won't run another time :/
I wrote a little tool called `lsfrom` for restarting such scripting. :-)
Hi,
I prepared a llvm35 package for Fedora 23
(like the llvm34 package for F22) needed
for ghc-7.10 on armv7 (and eventually armv8),
since llvm-3.6 in Rawhide is too new.
https://bugzilla.redhat.com/show_bug.cgi?id=1223673
Note like llvm34, this package only includes
llvm itself and not clang,
Hi,
I opened https://bugzilla.redhat.com/show_bug.cgi?id=1221923
about this too but thought it would be good to ask here.
F22 currently has llvm-3.5.0 (F23 is now on 3.6.0):
I believe there is a newer 3.5.2 bugfix release -
would it make sense to make a F22 update for that?
Is there any expected
leksah petersen, haskell-sig
Yes, this needs 8 new dependencies which I haven't
had time to post reviews for yet:
https://bugzilla.redhat.com/show_bug.cgi?id=1074907#c18
leksah is a Haskell IDE - I don't use it myself or
know many people who do, but if someone is willing
to
Sorry for the ghc breakage in rawhide - this was caused
by a rebuild of ghc against ghc-rpm-macros which caused
ghc-*-devel not to contain Haskell dependency information.
I plan to put more checks in place to avoid this happening again.
This should be fixed now in Rawhide with ghc-7.8.4-42.2.fc23
[Agda]
ghc-Agda-2.3.2.2-5.fc22 requires libHSzlib-0.5.4.1-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22 requires libHSxhtml-3000.2.1-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22 requires libHSvector-0.10.0.1-ghc7.6.3.so
[Agda-stdlib]
ghc-agda-lib-ffi-0.0.2-5.fc22.i686 requires
An update on ghc-7.8 progress:
[Agda]
[Agda-stdlib]
Newer Agda which builds with ghc-7.8 needs some new deps:
equivalence, data-hash, boxes, STMonadTrans, and tf-random - QuickCheck =
2.7.5.
Possibily it could also be moved to Copr if there is little interest.
[cab]
Newer cab needs newer
BTW why is the arch order of the branched report and the rawhide report
different?
Compose started at Sun Feb 15 07:15:03 UTC 2015
Broken deps for armhfp
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
Am 14.02.2015 um 17:02 schrieb Jens Petersen:
AFAICT now the ABI changes are due to -40 having
been built with make -j16 on i686 and x86_64.
In future I will use -j4 or less again
don't get me wrong but if the number of threads of the complier changes
ABI of the result the problem
ghc-7.8.4-41.fc22
-
Oh dear - gcc5 changes all the ghc library ABI hashes.
Sorry my initial hunch seems incorrect.
AFAICT now the ABI changes are due to -40 having
been built with make -j16 on i686 and x86_64.
In future I will use -j4 or less again.
Jens
--
devel mailing
[i686]
requires ghc(base-4.7.0.2-6d16fd65767daf67b7606bd63b471328)
[x86_64]
requires ghc(base-4.7.0.2-cb23b5265b6e147094c0cd9ac819acb1)
I fixed the ghc ABI hash breakage (caused by ghc-7.8.4-40 - ghc-7.8.4-41) for
F22 and F23
so the next reports should be better, and also got
.fc22
--
:
ghc-7.8.4-41.fc22
-
* Mon Feb 09 2015 Jens Petersen peter...@redhat.com - 7.8.4-41
- update the arm64 patch for 7.8.4
- all archs have bindir/ghci
Oh dear - gcc5 changes all the ghc library ABI hashes.
All the Haskell packages needs to be rebuilt for F22
Hi,
http://fedoraproject.org/wiki/Packaging:Alternatives explains how
alternatives should be done in Fedora, however it does not seem to
address the case of converting an existing package to use alternatives.
Specifically the problem arises when a file is changed to become a %ghost.
It seems rpm
alex-3.0.5-37.fc21 requires libHSbase-4.6.0.1-ghc7.6.3.so
:
:
Sorry for all the missing ghc libHS* provides...: this happened
while rebuilding ghc to use llvm34 to get it to work again on ARM,
due to some recent dependency generation changes in ghc-rpm-macros.
I already fixed this
Hi,
Recently llvm was bumped to 3.5 in Rawhide.
This breaks ghc on armv7 so I created a review request
for llvm34 for ghc to use for its llvm backend.
Can someone please help review the package?
https://bugzilla.redhat.com/show_bug.cgi?id=1161014
Until llvm34 is available no Haskell packages
I think the only way for ARM ghc is to do an llvm34 package.
(I don't know when ghc will support 3.5 - perhaps for 7.10 which
is now in development?) ghc only needs llvm.armv7hl (and llvm-libs).
I went ahead and created a llvm34 package.
https://bugzilla.redhat.com/show_bug.cgi?id=1161014
I don't think compat-llvm34 would save you. ghc emits llvm ir directly,
then invokes llc to compile it; /usr/bin/llc would only be provided by
llvm, not by the compat package which would be just the old library.
I was assuming it would provide all of llvm34 (minus clang34). :)
I think the
That's only going to work if llvm34 renames all of its binaries, and ghc
is changed to invoke the renamed ones, right? Otherwise the 3.4 and 3.5
versions of /usr/bin/llc will conflict.
Hmm yes I guess I should go the whole way...
My initial lazy plan was just that ghc-compiler.armv7hl
should
WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 9:00 Boston,
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.
= Topics =
* Follow-ups
* Integration tests
* Election planning
* Chairman for next meeting
* Open Floor
--
devel mailing list
devel@lists.fedoraproject.org
llvm-3.5 seems to break Haskell programs compiled with ghc on ARM badly.
Perhaps I should just barge ahead with a compat-llvm34?
Adam: this would be very welcome for ghc
(ghc only needs llvm - not any clang bits).
Otherwise currently we can't build any Haskell packages in Rawhide
because
Hi,
I read the log from last weeks EPEL meeting [1].
It is great to see discuss happening on (codename:) EPIC. :-)
At Flock at the EPEL.next session there was mention of using
branches/tags per minor EL version for EPIC for greater long term flexibility,
which I thought sounded pretty
This requirement seems to be just in the fedora spec file -- it doesn't seem
to be part of the upstream. From the man page, this is set with the '-fn'
flag at runtime. I didn't look at xmonad, but there's nothing inherently in
dmenu which seems to need it. I removed terminus-fonts with
Hi Christopher,
Quite frankly, it's no needed as a MUST. You could let users to
install. When I claimed over this package months ago, it's already
there.
I could drop this requires, but I need time to verify the conf file
and make sure dmenu works still(no major changes in the display).
terminus-fonts is required by dmenu, which in turn is needed by xmonad.
https://bugzilla.redhat.com/show_bug.cgi?id=1097424
terminus-fonts was part of RHEL 6 but was dropped from RHEL 7.
I have been asking ndim (the package contact, CC'ed)
about adding terminus-fonts to EPEL 7 several times now
terminus-fonts is required by dmenu, which in turn is needed by xmonad.
https://bugzilla.redhat.com/show_bug.cgi?id=1097424
:
Sorry please ignore this - I just noticed there already is a epel7 branch
and I just built terminus-fonts-4.38-3.el7.
So happy ending...
Thanks to whoever created
I'm not very familiar with the Fedora release schedule and how closely
related it is with gcc, but in the odb package that I'm the maintainer for
there appears to be a bug with the devirtualization that is claimed to be on
the roadmap for a fix in 4.9.1 (
This is largely my fault, but I think I have fixed all of:
... requires libHStext-0.11.3.1-ghc7.6.3.so
with a new build of ghc-text and most of
... requires libHSnetwork-2.4.1.2-ghc7.6.3.so
with a ghc-network build, which I believe leaves just 13 packages linked
against the wrong
Some OCaml spec files do the following:
ExclusiveArch: %{ocaml_arches}
This is always incorrect for several reasons:
Is %{ocaml_arches} used for anything?
In case not, maybe better to remove it?
Jens
--
devel mailing list
devel@lists.fedoraproject.org
I own some packages in EPEL what have been retired for a while
from Fedora, but I want to re-introduce to Fedora.
I have a question about this:
Do retired Fedora packages which are still active/exist in EPEL
require a re-review to be unretired in Fedora?
Until now I assumed the answer was yes,
However, earlier this year it also started using another, as far as I
know locally created buildsystem. GN at first was not buildable from
source at all. However, it seems that they have improved this and you
can now build it from source on x86_64 (only).
That sounds problematic - why x86_64
BTW shake [1] seems to be able to handle ninja [2].
I posted a review request for it recently. [3]
Erm, okay it seems GN generates ninja files
rather than building them so shake probably doesn't
help here.
--
devel mailing list
devel@lists.fedoraproject.org
It is definitely useful, but I wish there was some way of excluding
long-standing problems that no one cares to fix.
It might be nice if there was a counter for how many weeks
they have been broken, though probably a bit harder to implement.
Jens
--
devel mailing list
Hi,
Just a heads up that ghc-7.6.3 (Haskell compiler) from F20 was built
for EPEL 7 Beta last week. Lot of building of Haskell packages still
to be done there.
Current EPEL versions are:
EPEL5: ghc-7.0.4 (recently updated)
EPEL6: ghc-7.0.4 (updated in 2012; update to 7.4.2 planned)
EPEL7:
Hi Adam,
We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so
long before F21 and (among other goodies) it enables OpenGL 3.3 on some
newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets
a little awkward: the OpenGTL package only works up to LLVM
Hi,
We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so
long before F21 and (among other goodies) it enables OpenGL 3.3 on some
newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets
a little awkward: the OpenGTL package only works up to LLVM 3.3.
One
My concern would be how deeply woven the current format is into our tools -
it's yum, PK, DNF, anaconda, and all the tools built on top of it. It's
exposed in kickstart. It's expected to be handled by older versions on
upgrade, or even by mock when constructing arbitrary build roots.
So
Hi,
I would like to suggest the idea of adding support for
hierarchical comps groups to Fedora.
The idea is make yum groups in comps more modular,
ie groups could require other groups not just packages;
at this time I don't think it would require any GUI changes.
Currently comps is quite linear
Hi,
2014-03-05 9:40 GMT+01:00 Jens Petersen peter...@redhat.com :
I would like to suggest the idea of adding support for
hierarchical comps groups to Fedora.
(I'm not going to contribute actual work on this anyway, but) do we actually
need that complexity?
I am not sure how complex
Hi,
This a headsup that there is a ghc refresh update for EPEL 5 now in testing:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12484/ghc-7.0.4-45.3.el5,cabal-install-0.10.2-6.1.el5
This updates ghc from 6.12.3 to a bit more recent stable release,
which is also the currently the
I feel this is a an exciting evolution for Fedora.
At the same time of course it will be a big change,
and there could be some risk of the increased complexity
fragmenting Fedora development somewhat, but it should
FESCo to scale to support the needs of these separate
products better.
I know this
[ghc-Agda]
I opened a ticket asking releng to block this newly retired package.
[hedgewars]
Bruno rebuilt this yesterday - thanks!
Jens
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I am planning to start pushing all the version
updates and rebuilds soon to F20 Rawhide.
This is now done and in record time!
(I think it is first time I managed to rebuild
everything (all 220+ packages modulo xmobar) in under 24 hours.)
So next rawhide report should be normal again I hope. :)
Hi
Basically nearly all the changes for ghc-7.6.3 and the new approved
Haskell Packaging Guidelines are already tested and staged in pkg git
master branches, and I am planning to start pushing all the version
updates and rebuilds soon to F20 Rawhide.
Thanks, Jens
--
devel mailing list
Thank Michel,
I will be reducing my involvement in packaging LLVM -- I am no longer
regularly using it, the work required to keep it up-to-date is
relatively straightforward, but there are several deficiencies that I
feel others are better positioned to address:
I am happy to help maintain
Ok, llvm-3.2 is now in F19 Rawhide. [1]
Mesa, gambas3, and OpenGTL have been rebuilt, which
should take care of libllvm dependencies,
except for pure which no longer seems [2] to build with libedit [3]. :-|
Jens
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5031762
[2]
Are there any plans to bring this to F18?
Good question
There was talk about bringing 3.1 to F17 including some support from
the Mesa guys but then nothing actually happened. I would really
like it if I could go through F18 without having to build my own
private parallel installable llvm
Hi,
I spend a little time recently working on the llvm package trying
to fix a few Fedora bugs that have been open for a while...
I also think we should really get llvm-3.2 into Fedora 19.
I have done a few tests and scratch builds in
https://bugzilla.redhat.com/show_bug.cgi?id=903100
and am
How about doing a Cinnamon Spin at least for F19?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3) ghc - using LLVM as compiler, as a result incorrect triplet
Not sure what this is referring to: ghc ARM devel for F18 is
basically done (except for a few minor libs appearing
in the Branch report that need rebuilding) and working fine.
Maybe this is referring to this Rawhide llvm issue
Main.hs:31:8:
Could not find module `System'
It is a member of the hidden package `haskell98-2.0.0.1'.
Use -v to see a list of the files searched for.
It may be nice, if anyone can tell me in which package I
could find the missed System module.
I had a look and kaya needed
Rebuilds for ghc-7.4.2 are basically done since yesterday,
ie the major deps breakage should be over now.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
commit ef7b982deaa94db3f0c9f0571913ff6cabe45b40
Author: Jens Petersen peter...@redhat.com
Date: Tue Nov 20 15:59:25 2012 +0900
fix epoch back to 2
perl-DateTime.spec |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/perl-DateTime.spec b/perl-DateTime.spec
Hi,
The Haskell SIG will soon be updating ghc to 7.4.2 and the just released
haskell-platform-2012.4.0.0. At the same time there will be a big bunch
of pending version updates for various Haskell packages. As usual this
will require rebuilding all the packages.
Apart from bugfixes, a nice
Hi,
For a long time - well since pre-Fedora history ;) -
I have maintained the emacspeak package
(see https://code.google.com/p/emacspeak/).
In the past I generally found time to update it for
each Fedora release (it is not really much work)
but I don't actually use it myself at all or have
the
yum install rpm-build should install an rpmbuild version that works
as expected for fedora. Currently, it does not because it is missing the
dependancy on redhat-rpm-config.
Well I tend to agree: it would be the least surprising behaviour for most
fedora packagers.
Though I understand the
Hi,
Just a quick heads-up that haskell-platform in Rawhide
will be soon be updated to the new 2012.4 release. [1]
As usual there will be quite a bit of dependency breakage
while all the reverse dependencies get rebuilt:
I have already tested it locally and committed
required changes to git. At
See https://bugzilla.redhat.com/show_bug.cgi?id=693233 (pkgreview for nux)
for some slightly more recent status details.
At the end of November I actually did some /very/ rough packaging of unity
(at the time I actually wanted unity-2d but it already required unity
then as was pointed out, and
I don't think I'm going out on a limb if I say that this doesn't look
like Unity will hit Fedora repos anytime soon. You may look at
repos.fedorapeople.org, though.
As far as I remember Adam Williamson once looked at the feasibility
of packaging Unity for Fedora. Don't know what was the
The list of orphaned packages is here:
https://fedorahosted.org/fedora-infrastructure/attachment/ticket/3046/to-be-orphaned.txt
I took ownership of the haskell packages of bos: I had already been maintaining
for a while anyway as comaintainer.
And it makes more sense that one person owns all
Hi,
yum-langpacks has been working pretty well now for a while in Fedora,
but all langpacks are still listed conditionally in comps' language support
groups
in addition to the langpacks meta-section.
So for F17 I'd like to remove them all from comps,
this will simplify comps a lot and if we can
- Original Message -
i want to relinquish ownership. Any takers for package stardict.
Though not offically a comaintainer, Jens has been active on it
recently and might be a good candidate.
Well ok, I have picked it up for now, but someone else wants
to help comaintain or own it
Just a heads-up that ghc-7.0.4 bugfix release is going into rawhide.
Unfortunately there will be some dependency breakage while
library packages get rebuilt but hopefully it should only last
a few days and I expect things should be back to normal again by next week.
Once people can help with
You can use the internal identifier (which is never translated),
yum groupinstall development-tools
In F15, yum grouplist lists the identifier after each translation.
For earlier releases I think you may have to lowercase the English
and replace space by a hyphen? In the worst case one can
José Matos wrote:
1) This feature will also allow firefox and thunderbird to earn
langpacks as they deserve.
Yes that was my hope but it needs acceptance from the fedora mozilla
packagers...
Support and encouragement is welcome.
In F15 asking
yum list *langpack*
shows that only
koffice
Very late reply... sorry it took me rather longer
finally to finish the new packaging draft than I had hoped.
Wouldn't it be more clear if cabal2spec generated the %files and
%packages sections rather than using a really complicated macro? As a
reviewer, I feel like there is no way to tell
* Updates to popular languages. Python 3.2, Rails 3.0.3, and
OCaml 3.12 are all included in Fedora 15.
If we are going to mention OCaml then to be fair
can we please also mention GHC 7.0.2,
which is major new version upgrade since F14?
Ok that is probably me failing to follow the feature
Coders have lots of new development tools to try out, including:
* Updates to popular languages. Python 3.2, Rails 3.0.3, and
OCaml 3.12 are all included in Fedora 15.
If we are going to mention OCaml then to be fair
can we please also mention GHC 7.0.2,
which is major new version upgrade
... so, given that I've used fedpkg co -B to create a working tree
with a subdirectory per branch, what's the incantation to get an f15/
subdirectory added to that tree? I hope there's a better answer than
rm -rf and re-clone.
This is what I am doing:
for i in *; do
if [ -d $i -a -d
The first pass though the mass rebuild has been completed
Thanks and congrats!
list of all things not built yet at
http://ausil.fedorapeople.org/rebuild.html
there is ~400 packages that rpm-4.9.0 failed to parse the spec files.
Are there any more details about the errors?
Jens
--
devel
I am still trying to track down what changes in rawhide
[..] caused ghc ABI hashes to mysteriously change.
In the meantime since it is taking longer to resolve than
I had hoped I am requesting an exception from FESCo
to untag the latest broken ghc build from rawhide
since it is not useless
ghc-Boolean-0.0.1-4.fc15.x86_64 requires ghc(base-4.3.0.0) =
0:d6f599ffb7445762058e21fe7a79b625
:
ghc-mtl-devel-2.0.1.0-1.fc15.i686 requires ghc-devel(base-4.3.0.0) =
0:b91367e4fa5bd47d8e75958171ad21b7
ghc-mtl-devel-2.0.1.0-1.fc15.x86
[Message truncated]
Apologies for the ongoing ghc
- Adam Williamson awill...@redhat.com wrote:
On Sun, 2010-11-28 at 21:43 -0500, Jens Petersen wrote:
- Adam Williamson awill...@redhat.com wrote:
Agreed. I really don't see a reason to break so many packages,
even
if it is 'only Rawhide'. Was there a reason all these rebuilds
- Bruno Wolff III br...@wolff.to wrote:
I need ghc-hslogger rebuilt in order to rebuild hedgewars.
It is in dist-f15-build now, so you can go ahead.
Thanks, Jens
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
- John Reiser jrei...@bitwagon.com wrote:
How can this testing take place when a very long list of dependencies
has not yet appeared in rawhide?
Well I meant after the rebuilds were completed, but
the majority of the packages had already been rebuilt
at the time of writing. Which one was
- Adam Williamson awill...@redhat.com wrote:
Agreed. I really don't see a reason to break so many packages, even
if it is 'only Rawhide'. Was there a reason all these rebuilds could not
be completed in the tag?
Well mostly me being a slacker (I only rebuilt 50+ packages)
and hoping to
The only remaining pending rebuilds I am aware
of now are xmobar and hedgewars (which Bruno is working on).
Ok, I missed one more: ghc-feldspar-language,
which like xmobar also seems to need a little work for ghc7.
--
devel mailing list
devel@lists.fedoraproject.org
Hi,
I have just moved ghc-7.0.1 and a large set
of Haskell ghc package rebuilds into dist-f15
(from dist-f15-ghc).
The main stacks have been rebuilt: darcs,
haskell-platform, xmonad, and gtk2hs.
Rebuilds still pending include xmobar, hlint,
and various libraries (currently with one or less
alex-2.3.3-1.fc14.x86_64 requires libHSffi-ghc6.12.3.so()(64bit)
:
ghc-Boolean-0.0.1-2.fc15.x86_64 requires libHSffi-ghc6.12.3.so()(64bit)
:
:
ghc-zlib-0.5.2.0-4.fc14.x86_64 requires libHSffi-ghc6.12.3.so()(64bit)
:
xmobar-0.11.1-4.fc15.x86_64 requires
- lakshminaras2...@gmail.com wrote:
I intend to take ownership of haddock package. It is required for one other
package (leksah, an IDE for Haskell) that I am planning to submit.
Yes, I think that is fine.
You will need to submit haddock for package review since it has been retired
We have the regular weekly i18n project meeting scheduled for tomorrow.
https://fedoraproject.org/wiki/I18N/Meetings/2010-09-30
If you have some agenda topic to discuss particularly for F14,
or package updates you want to highlight, etc, please add to
the agenda page or follow up to this mail.
Reminder about the Input Method Bugs Day being
organized by fedora-i18n tomorrow.
We will be working on triaging and clearing bugs
at #fedora-i18n on freenode.---BeginMessage---
Hi,
We are organising Input Method bugs day on 1st September 2010. On
this day we need your help to triage IM
Should someone write up a draft for an official package review
checklist, and have FPC update it when guidelines change? (I guess by
writing this email I just volunteered myself...)
How about scripting and packaging it? Then one could just run it on
the final srpm for review. Of course the
- Bruno Wolff III br...@wolff.to wrote:
Probably kaya and hedgewars should be rebuilt too.
I'll bump hedgewars once the update shows up.
I am not seeing a conflict with hedgewars after the update. So for now
at least, I don't think hedgewars needs to be rebuilt.
Right, there
- Bruno Wolff III br...@wolff.to wrote:
I'll probably be doing one in F14 to get the latest upstream release,
once I get a bit of a lull. So there should be one before release.
Cool
You should not need those Requires since they are for shared libs.
Rpm would generate them for you
Just to update I finished rebuilding all the ghc packages in dist-f14-ghc
over the weekend and they should appear in the next rawhide push.
Probably kaya and hedgewars should be rebuilt too.
Please report or let me know of any problems.
Thanks, Jens
--
devel mailing list
- Bruno Wolff III br...@wolff.to wrote:
Jens Petersen peter...@redhat.com wrote:
This is now done - so all rebuilds need to be done in the
dist-f14-ghc buildroot.
Today's rawhide still seems broken. The report indicates that ghc has
been removed from rawhide:
http
- Josh Boyer jwbo...@gmail.com wrote:
snip a ridiculous amount of ghc deps
If you're going to bump ghc, maybe you should request a build tag so
you can
bump it and rebuild all the deps before it hits rawhide. See the
massive perl update in this report for a case of this working.
I built ghc-6.12.3 for F14. This will require rebuilding all
ghc library packages, which I and the Haskell SIG will be doing
over the coming days - the meantime please bear with us with
the broken dependencies...
Thanks,
Jens
--
devel mailing list
devel@lists.fedoraproject.org
Headsup that I built gettext-0.18.1.1 for rawhide
and also a build for f13 updates-testing.
https://admin.fedoraproject.org/updates/gettext-0.18.1.1-0.1.fc13
Please report any problem in bugzilla or Bodhi.
Jens
--
devel mailing list
devel@lists.fedoraproject.org
You can find the minutes and log of today's i18n meeting at:
https://fedoraproject.org/wiki/I18N/Meetings/2010-02-25
Main topics were f13 relnotes, f13 bugs, and splitting Simplified
and Traditional Chinese again for comps and fonts.
Jens
--
devel mailing list
devel@lists.fedoraproject.org
We have had biweekly fedora i18n project meetings for a good while now.
Then we added a separate weekly input-methods meeting and more
recently a i18n fonts meeting. In an attempt to rationalize
the number of meetings I am proposing now that instead
we move to one main weekly fedora i18n meeting
- Bill Nottingham nott...@redhat.com wrote:
Jens Petersen (peter...@redhat.com) said:
I meant to add that the reason this came up was I was trying to work
out where to put yum-langpacks in comps: yum-presto being one of the
reference packages I searched for.
So where can/should
1 - 100 of 101 matches
Mail list logo
