Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

> 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 this

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

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 cou

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

> 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 >

Re: Schedule for Tuesday's FESCo Meeting (2023-06-13) - #inaction Edition

> 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 re

Re: updating cmark to 0.30

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 Fedora

Re: Unowned system directories

> /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: https://docs.fedoraproject.org/en-US/project/

Re: ibus-typing-boster - testcase instruction error

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: https://docs.fedor

Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow

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: https://docs.fedoraproject.org/en-US/project/code-of-cond

Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow

> 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. :-) https://hackage.haskell.org/p

llvm35 package for F23

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, e

updating f22 llvm to 3.5.2 release?

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

Re: Removing packages that have broken dependencies in F22 tree

> 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 he

Re: rawhide report: 20150323 changes

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

Re: rawhide report: 20150302 changes

> [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 > l

Re: rawhide report: 20150217 changes

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 ne

Re: F-22 Branched report: 20150215 changes

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: http:/

Re: F-22 Branched report: 20150214 changes

[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 bus

Re: rawhide report: 20150210 changes

> 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 co

Re: rawhide report: 20150210 changes

> > 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 ma

Re: rawhide report: 20150210 changes

> ghc(array-0.5.0.0-737cbb51757a43319cad7f20f341524e) : : | : : > gcc-5.0.0-0.9.fc22 > -- : > ghc-7.8.4-41.fc22 > - > * Mon Feb 09 2015 Jens Petersen - 7.8.4-41 > - update the arm64 patch for 7.8.4 > - all archs have bindir/ghci Oh dear - gcc5 change

ghc-7.8 now in Fedora Rawhide

The Fedora Haskell SIG is pleased to announce the arrival of GHC 7.8 in Fedora 22 Rawhide (development tree). - the GHC version is 7.8.4: we are no longer following haskell-platform strictly - Around 125 Haskell packages have been updated to new versions, including pandoc-1.13.2. See

introducing alternatives into a package

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

Re: rawhide report: 20141118 changes

> 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 yesterd

help with review of llvm34

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 wi

Re: LLVM 3.5 rebase

> 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 shou

Re: LLVM 3.5 rebase

> 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

Re: LLVM 3.5 rebase

> 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

Agenda for Env-and-Stacks WG meeting (2014-11-05)

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 https://ad

Re: LLVM 3.5 rebase

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 compi

Re: Fedora 21 Changes Freeze in two weeks - 2014-07-08

> 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 ( > http://www.codesynthesis.com/pipe

Re: rawhide report: 20140608 changes

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 wron

Re: Spec files in Rawhide using ExclusiveArch: %{ocaml_arches}

> > >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 https://admin

Re: F21 Self Contained Change: Playground repository

> 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 https://admin.fedoraproject.org/m

Re: F21 Self Contained Change: Playground repository

> 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 x8

packages in EPEL that are retired in Fedora

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, bu

Re: rawhide report: 20140404 changes

> 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 devel@lists.fedoraproje

Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20

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

Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20

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 co

Re: hierarchical comps groups proposal

> 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. > > S

Re: hierarchical comps groups proposal

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 tha

hierarchical comps groups proposal

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 (

Re: Fedora Working Groups: Call for Self-Nominations

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

Re: rawhide report: 20130623 changes

> [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

Re: headsup ghc-7.6.3 coming soon to rawhide

> 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. :

headsup ghc-7.6.3 coming soon to rawhide

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 devel@list

Re: F-19 Branched report: 20130328 changes

> [gnome-applets] > [gnome-panel] Have these not been blocked yet? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Seeking primary maintainer for LLVM

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 maintai

Re: headsup for llvm-3.2

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] http://koji.fe

Re: headsup for llvm-3.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 llv

headsup for llvm-3.2

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 plan

Re: Proposed F19 Feature: Cinnamon as Default Desktop

How about doing a Cinnamon Spin at least for F19? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora ARM VFAD - 2013-01-23

> 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 https

Re: [Help Wanted] Which package provide the System Module for rawhide

> 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 need

Re: rawhide report: 20121120 changes

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

headsup: ghc-7.4.2 and haskell-platform-2012.4 coming soon to rawhide

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 featu

emacspeak: hearing for a new owner

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 h

Re: redhat-rpm-config and rpm-build (fwd)

> 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 p

[headsup] Haskell Platform 2012.2 coming soon to Rawhide

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 th

[headsup] ghc-7.4.1 coming to a rawhide near you soon

Hi, This is just a headsup that ghc-7.4.1 is going into F18 rawhide. [1] After that all ghc based Haskell packages will need to be rebuilt. This major new version has a lot of new features and performance improvements [2], also incidently including registerized compilation support on ARM using llv

Re: Unity For Fedora (As in OpenSUSE or Arch)

> 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

Re: Unity For Fedora (As in OpenSUSE or Arch)

> 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 th

Re: Packages with inactive owners orphaned and inactive comaintainers removed

> 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

comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in

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 meta-section. So for F17 I'd like to remove them all from comps, this will simplify comps a lot and if we can also remo

Re: Any takers for package stardict...

- 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

Headsup: haskell ghc-7.0.4 going into rawhide

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 rebu

Re: What is the status of Features/YumLangpackPlugin?

> > 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

Re: What is the status of Features/YumLangpackPlugin?

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 > >

Re: Haskell packaging questions

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 w

Re: Announcing the release of Fedora 15 Beta!!

> > * 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

Re: Announcing the release of Fedora 15 Beta!!

> 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 si

Re: Mass Rebuild and Mass branching status update

> 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

Re: Mass Rebuild and Mass branching status update

> ... 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

Re: [Fedora-haskell-list] rawhide report: 20110111 changes

> 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 usel

Re: rawhide report: 20110111 changes

> 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 gh

Re: headsup: ghc 7 lands in rawhide

- "Adam Williamson" wrote: > On Sun, 2010-11-28 at 21:43 -0500, Jens Petersen wrote: > > - "Adam Williamson" wrote: > > > Agreed. I really don't see a reason to break so many packages, > even > > > if it is 'only Rawhide&

Re: [Fedora-haskell-list] headsup: ghc 7 lands in rawhide

> 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 https://admin.fedoraproje

Re: headsup: ghc 7 lands in rawhide

- "Adam Williamson" 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 engage some of the

Re: headsup: ghc 7 lands in rawhide

- "John Reiser" 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 interrupting you t

Re: headsup: ghc 7 lands in rawhide

- "Bruno Wolff III" 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

headsup: ghc 7 lands in rawhide

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 depen

Re: rawhide report: 20101107 changes

> 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 libHSffi-ghc6.

Re: [Fedora-haskell-list] Taking ownership of haddock

- 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

this week's i18n meeting

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. T

Fwd: Input Method Bugs Day

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.--- Begin Message --- Hi, We are organising Input Method bugs day on 1st September 2010. On this day we need your help to triage IM

Re: package review checklist

> 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

Re: [Fedora-haskell-list] headsup: ghc-6.12.3

- "Bruno Wolff III" 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 automaticall

Re: [Fedora-haskell-list] headsup: ghc-6.12.3

- "Bruno Wolff III" 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 shouldn'

Re: headsup: ghc-6.12.3

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 devel@lists.fedoraproje

Re: [Fedora-haskell-list] rawhide report: 20100622 changes

- "Bruno Wolff III" wrote: > Jens Petersen 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:/

Re: rawhide report: 20100622 changes

- "Josh Boyer" wrote: > > > 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. Thanks Josh for the suggestion - I opened https:/

headsup: ghc-6.12.3

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 https://admin.fedo

gettext-0.18 built

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 https://admin.fedoraproject.org/

Re: Call for Participation - Fedora 13 Talking Points

- "Paul W. Frields" wrote: > On Mon, Feb 22, 2010 at 10:06:09PM -0500, Jens Petersen wrote: > > Perhaps I missed it but I didn't see any clear indication that > > a Talking Point has to be a Feature. Is that the case? > > It doesn't. A Talking Po

today's i18n meeting

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 https

Re: Call for Participation - Fedora 13 Talking Points

Perhaps I missed it but I didn't see any clear indication that a Talking Point has to be a Feature. Is that the case? Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

moving to weekly i18n meetings

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

Re: yum-langpacks and comps

- "Bill Nottingham" 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. &

Re: Orphaning Candidate packages for removal due to FTBFS, implications

- "Seth Vidal" wrote: > which is why All we're suggesting is filing a bug and/or some other > kind of notification that says "are you alive". To clarify, only for FTBFS, right? Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

tomorrow's i18n meeting

A reminder of tomorrow's biweekly i18n meeting: https://fedoraproject.org/wiki/I18N/Meetings/2010-01-19 Please follow up if you have a topic for discussion. Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: yum-presto and comps

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 yum-langpacks live? Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraprojec

  1   2   >