Re: unretiring llvm7.0

On Sun, May 31, 2020 at 12:44 AM Andy Mender wrote: > If I understand correctly, the sudden disappearance of llvm7.0 means that > now ghc is in danger as a package, because it's missing the toolchain > needed to build & package it? > llvm is only a ghc requirement for arm archs. Currently

unretiring llvm7.0

In March llvm7.0 which had been orphaned for some reason, got retired. Unfortunately I missed the warning mails that Miro sent here. llvm7.0 is needed for aarch64 ghc:8.8, and for ghc-8.8.3 planned for F33. So I would like to unretire llvm7.0. Thanks, Jens

unretire gnu hello

Hello, I plan to unretire the GNU hello package. (Apparently it was retired in 2012 just because the former maintainer didn't want to add "Provides: bundled(gnulib)".) Though it is fairly trivial it is a minimal system sanity package and executable tool, with gettext internationalization now

plan to retire llvm3.9 from f31+

Hi, llvm3.9 provides an old version of llvm and I think it is no longer needed by anything as of current F31. It failed the mass rebuild: so it seems a reasonable time to retire it now. So just a heads-up that we are thinking to retire llvm3.9 before the final f31 freeze. Jens

Re: gettext retired, rawhide broken

On Fri, Aug 9, 2019 at 7:38 AM Fabio Valentini wrote: > Can somebody please unretire and fix gettext? It was just automatically > retired because it didn't build successfully since fedora 29. And now the > world is broken. > Thanks - I think it has been taken care of for now. Jens

Re: Does anybody care about gettext?

On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko < ignatenkobr...@fedoraproject.org> wrote: > Well, it was retired because it did not built since F30 mass rebuild… > I went ahead and built it with the testsuite disabled for now: I suppose any Proven Packager could also have done, but yeah normally

ghc alternatives and triggers

Hi, Any objections to dropping the alternatives for runhaskell and hsc2hs in Rawhide at this time? https://bugzilla.redhat.com/show_bug.cgi?id=1640056 Also a heads-up that I am planning to move to rpm triggers in ghc-compiler for updating the ghc-pkg cache instead of the current post/postun

Re: Langpacks and the packages needed to display/input a language

On Tue, Jun 18, 2019 at 3:07 AM Jason L Tibbitts III wrote: > >>>>> "JP" == Jens-Ulrik Petersen writes: > I install a generic minimal system via kickstart (booted using the > Server PXE images and using the Everything repositories) and then after > the r

Re: Langpacks and the packages needed to display/input a language

Jason, can you explain in more details (bug report is also fine) how exactly you are installing? (Because for both Workstation/Silverblue, and Server I believe, we install fonts and input methods for Korean (and other langs like Japanese) by default anyway - so actually no need to install

new pkgtreediff tool

Hi, I made a little tool called pkgtreediff to compare package trees (directories of rpm files). See https://github.com/juhp/pkgtreediff#readme for more details. I hope some people here may find it useful. Fedora and Epel7 builds are available in <

Re: fedora-img-dl: a tool for downloading Fedora iso's and images

On Mon, Apr 15, 2019 at 5:55 PM Dan Čermák wrote: > cool project! I see a certain overlap with fedora-mediawriter though, as > that one can download ISOs too. > Okay, thanks, my own use-case is more downloading Live images for local testing. I've skimmed the sources (is this upstream: >

Re: fedora-img-dl: a tool for downloading Fedora iso's and images

On Tue, Apr 16, 2019 at 12:58 AM Adam Williamson wrote: > I already basically wrote this: > https://pagure.io/fedora-qa/fedfind Wow, very cool, looks comprehensive, thanks. I see it even downloads composed images from Koji. Jens ___ devel mailing

fedora-img-dl: a tool for downloading Fedora iso's and images

Hi, I made a small cli tool for downloading Fedora iso's etc. It can download rawhide, branched, beta, and released isos (eg Workstation Live etc), and even WS Live respins (support for spins coming later). You can try it now from <

Re: The state of Zanata Python client (Python 3 support)

Thanks to Sundeep, who has already started and worked on this. So hopefully we will have a working py3 zanata-python-client for F30+ soon. :-) See https://github.com/zanata/zanata-python-client/pull/52 Jens On Tue, Mar 5, 2019 at 9:56 PM Martin Kolman wrote: > Hi, > I come from the tha

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Fri, Feb 15, 2019 at 11:30 PM Vít Ondruch wrote: > As long as we have no idea if the other maintainers are active, I am > strongly against the automation. I've been there. Followed nor > responsive policy just to find out later that instead of orphaning the > package, next inactive maintainer

Re: Is zh_Hans a valid locale name?

Any reason not to use the more standard glibc locale name: zh_CN? I don't think glibc (or gettext) knows about zh_Hans, let alone zh-Hans. I think what Tom says is basically correct: zh-Hans is a CLDR locale name. Jens On Thu, Feb 14, 2019 at 11:42 PM Randy Barlow wrote: > I recently added

Re: Orphaned packages to be retired

On Mon, Feb 11, 2019 at 5:44 PM Vít Ondruch wrote: > Dne 11. 02. 19 v 4:33 Jens-Ulrik Petersen napsal(a): > > I have to say I am not really enjoying this ongoing aggressive package > retirement process. > If packages are not broken and needed by other packages, then I don

Re: Orphaning: llvm5.0, clang5.0, llvm6.0, clang6.0

I can take llvm5.0: I already requested unorphaning from releng. llvm5.0 is needed on ARM by ghc:8.4 and ghc:8.6 needs llvm6.0. Jens ps (It *might* be possible to bump some of those for ghc but I don't really have the extra time needed for that.) On Tue, Jan 29, 2019 at 6:27 AM Tom Stellard

Re: Orphaned packages to be retired

On Tue, Feb 5, 2019 at 4:27 AM Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for > sure > that the package should be retired, please do so now with a proper reason: >

Re: Orphaned packages need new maintainers (will be retired in 3 weeks)

Sigh, I just saw this... I have been super-busy and missed the mails unfortunately. On Fri, Nov 30, 2018 at 9:16 PM Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for > sure that the

Re: F30 Self-Contained Change proposal: Ibus-typing-booster default for Indian languages

On Mon, Jan 28, 2019 at 8:04 AM Owen Taylor wrote: > I see that I have ibus-typing-booster installed, but I don't see any > sign of it in the GNOME "Region & Language" panel input source > selection. Does ibus-typing-booster look like one input support for > each supported language, or does it

Re: langpacks (Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks)

On Mon, 14 Jan 2019, 16:01 Nicolas Mailhot Le 2019-01-11 19:33, Tomasz Kłoczko a écrit : > > On Fri, 11 Jan 2019 at 13:37, Jakub Jelinek wrote: > > > >>> So in 107 current Fedora specs are used %lang() macros. > >>> Probably some of them can be removed by proper use %find_lang. > >> > >> The

Re: langpacks (Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks)

On Fri, Jan 11, 2019 at 2:41 AM Tomasz Kłoczko wrote: > Funny (and scary) is that anaconda provides function to choose exact > languages support when system is installed but nothing is added to > /etc/rpm/macros to really make this choice real. > %find_lang macro takes care of tagging some files

Re: langpacks (Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks)

On Fri, Jan 11, 2019 at 2:41 AM Tomasz Kłoczko wrote: > On Wed, 9 Jan 2019 at 21:07, Ben Cotton wrote: > >> >> https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_Langpacks >> Language support groups in Comps file will get replaced by langpacks >> package. With this Change

Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks

On Fri, Jan 11, 2019 at 2:38 AM wrote: > Will gnome-control-center be able to install missing language packs and > input sources? > What about gnome-initial-setup? > Good questions but that is outside the scope of this Change. :-) Eventually we would like that to be the case yes - but

Re: Minimum fonts required for Fedora en_US

On Tue, Dec 25, 2018 at 11:22 PM Danishka Navin wrote: > What are the minimum fonts required for Fedora 28/29 with en_US locale? > Danishka, can you give more context for your question? Over 450 fonts available in the fonts group. > The @fonts group only installs 36 fonts by default. ;) :)

retiring gettext-commons (java/maven FTBFS)

Heads-up that I intend to retire 'gettext-commons' which no longer builds and I believe is not used by anything in the distro. If that is not the case please shout out, otherwise I will try to drop it by the end of this week. Thanks, Jens ___ devel

ghc module and Haskell static linked executables

Hi, A heads-up that I am planning to move Haskell executables to static linking in F30. This to improve the experience with the new ghc module: currently most of the Haskell executables (except hscolour and hedgewars I believe) are dynamically linked which conflicts with modular ghc, making it

Re: Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

Hi Zbigniew, nice to meet you at Flock. On Thu, Aug 23, 2018 at 5:30 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot > > == Summary == > glibc-minimal-langpack is added to @Buildsystem group and installed > into the minimal buildroot

Re: Orphaned Packages in rawhide (2018-08-27)

On Tue, Aug 28, 2018 at 9:43 PM Vít Ondruch wrote: > > ghc-pretty-show (maintained by: mathstuf) > > ghc-pretty-show-1.6.16-1.fc29.i686 requires js-jquery1 = > 1.12.4-6.fc29 > I opened https://github.com/yav/pretty-show/issues/32 for this: so this will likely get fixed for

[EPEL-devel] Re: libbibutils 6.6 update with soname bump in epel7

Thanks, Tuomo, good catch! I had forgotten to do this. I filed a separate update for ghc-rpm-macros for this - since releasing it is less urgent and I would like to test it more carefully. Jens On Mon, 30 Jul 2018, 09:01 Tuomo Soini, wrote: > On Sat, 28 Jul 2018 12:29:56 +0900 > Jens

[EPEL-devel] Re: libbibutils 6.6 update with soname bump in epel7

(adding epel-devel too) Vasiliy, I have decoupled ghc-hs-bibutils from bibutils in epel7 now too, so you shouldn't need to worry about it anymore. Thanks for maintaining Fedora bibutils! Jens On Wed, Jul 25, 2018 at 8:00 PM Vascom wrote: > Jens-Ulrik, > Add me as co-maintainer to this

Re: libbibutils 6.6 update with soname bump in epel7

(adding epel-devel too) Vasiliy, I have decoupled ghc-hs-bibutils from bibutils in epel7 now too, so you shouldn't need to worry about it anymore. Thanks for maintaining Fedora bibutils! Jens On Wed, Jul 25, 2018 at 8:00 PM Vascom wrote: > Jens-Ulrik, > Add me as co-maintainer to this

Re: libbibutils 6.6 update with soname bump in epel7

Sorry for the late reply - I only noticed this mail yesterday. On Wed, Jul 25, 2018 at 6:40 PM Vascom wrote: > Hi, > I am updating libbibutils to 6.6. It has soname bump from 5 to 6 in EPEL 7 > repo. > Yeah unfortunately libbibutils bumps soname every minor release... > Need update dependent

Re: tool to order packages by build dependencies (rpmbuild-order)

On Fri, Jul 27, 2018 at 1:21 PM Michal Novotny wrote: > On Fri, Jul 27, 2018 at 4:56 AM Jens-Ulrik Petersen > wrote: > >> On Fri, Jul 27, 2018 at 12:54 AM Jens-Ulrik Petersen >> wrote: >> >>> I should test some larger package sets to see how well rpmbuild-o

Re: tool to order packages by build dependencies (rpmbuild-order)

On Fri, Jul 27, 2018 at 12:54 AM Jens-Ulrik Petersen wrote: > I should test some larger package sets to see how well rpmbuild-order > scales too... > BTW are there any tarballs of all the fedora spec files available somewhere these days? Of course I could download srpms, or bette

Re: tool to order packages by build dependencies (rpmbuild-order)

On Fri, Jul 27, 2018 at 12:42 AM Jeff Johnson wrote: > There are easier ways to accomplish build ordering using tsort(1) and a > minor amount of scripting with the same simplifying assumptions your > program is making: > 1) no cycles > 2) every package provides its own name > 3) every package

Re: tool to order packages by build dependencies (rpmbuild-order)

On Thu, Jul 26, 2018 at 7:10 PM Nicolas Mailhot wrote: > Le 2018-07-26 07:20, Jens-Ulrik Petersen a écrit : > > https://github.com/juhp/rpmbuild-order > > It works by reading the BRs in spec files of the packages you want to > > build, generating a graph of their interde

Re: tool to order packages by build dependencies (rpmbuild-order)

On Thu, Jul 26, 2018 at 6:53 PM Igor Gnatenko < ignatenkobr...@fedoraproject.org> wrote: > On Thu, Jul 26, 2018 at 11:44 AM Jens-Ulrik Petersen > wrote: > >> On Thu, Jul 26, 2018 at 2:44 PM Igor Gnatenko < >> ignatenkobr...@fedoraproject.org> wrote: &

Re: tool to order packages by build dependencies (rpmbuild-order)

On Thu, Jul 26, 2018 at 3:58 PM David Tardon wrote: > On Thu, 2018-07-26 at 14:20 +0900, Jens-Ulrik Petersen wrote: > > You can try it from my copr repo: > > https://copr.fedorainfracloud.org/coprs/petersen/rpmbuild-order > > - nothing provides > libHSex

Re: tool to order packages by build dependencies (rpmbuild-order)

On Thu, Jul 26, 2018 at 2:44 PM Igor Gnatenko < ignatenkobr...@fedoraproject.org> wrote: > So… Since I have hard times understanding code, I will just ask questions > here: > * Does it use libsolv? I guess not. > * Does it handle rich dependencies? I guess not. > It only uses BuildRequires

tool to order packages by build dependencies (rpmbuild-order)

Hi, This is an early announcement about a tool called 'rpmbuild-order' I made to sort RPM-based packages in build dependency order. I am not sure if such a tool exists already? Certainly some tools like `mockchain` can already order builds in this way, but I don't know of such a standalone

looking for new owner for 'bibutils'

Hi, Does any Packager want to take over or comaintain the bibutils package? I am not really interested in maintaining it any longer since I no longer have a package that needs it. Let me know if you want to help. Thanks, Jens ___ devel mailing list

Re: /etc/profile.d/lang.sh -- still needed?

On Tue, May 15, 2018 at 12:19 AM, David Kaspar [Dee'Kej] wrote: > does anybody know if the files /etc/profile.d/lang.{csh,sh} are still used > these days, and what for? > Do we still need them in Fedora? > They are needed for example to not run Asian and Middle Eastern

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

Thanks Chris for the follow up. I also wanted to go for OTC fonts, but both Akira Tagoh and Owen Taylor who are fonts rendering experts advised against switching this late in the cycle to the .ttc fonts in case there are any serious regressions for any apps (we are not aware of any yet but there

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

On Tue, Apr 10, 2018 at 9:11 AM, Kevin Kofler wrote: > And IMHO the KDE and LXQt Spins should revert to shipping only > wqy-microhei-fonts and no other CJK fonts. They never promised CJK support > beyond "we can bring up SOME rendering for every character of the typical >

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

On Sat, Mar 31, 2018 at 7:35 PM, Nicolas Mailhot < nicolas.mail...@laposte.net> wrote: > Le vendredi 30 mars 2018 à 16:45 +0900, Akira TAGOH a écrit : > > The problem on this workaround is that we need an exception for > > packaging because the packaging guidelines mentions we must package > >

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

On Fri, Mar 30, 2018 at 1:22 AM, Adam Williamson wrote: > On Thu, 2018-03-29 at 16:12 +0200, Kevin Kofler wrote: > > wqy-microhei-fonts is very effective, but unfortunately it only covers > > Simplified Chinese and the syllabic parts of Japanese and Korean, not the >

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

Hi, I fixed: bibutils eb emacspeak hugs98 scim-hangul wmctrl Jens ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ghc 8.2 now in Rawhide

The Haskell SIG is pleased to announce that the ghc Haskell compiler has been updated from 8.0.2 to 8.2.2 in Fedora Rawhide (for more information see http://fedoraproject.org/wiki/Changes/GHC_8.2). Most Haskell packages have already been updated and/or rebuilt. A few remaining excepts are:

Re: retiring git-annex

On Mon, Jun 12, 2017 at 3:43 AM, Dusty Mabe wrote: > > I will post more details tomorrow then. > > I saw a link to a copr come through, but not much on how to get > git-annex fixed in Fedora proper. Any info for that? Sorry for the delay... I just added some details here:

Re: retiring git-annex

I created a git-annex copr: https://copr.fedorainfracloud.org/coprs/petersen/git-annex/ ​ Jens ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: retiring git-annex

0, Björn 'besser82' Esser > > wrote: > > > Am 27.05.2017 um 15:13 schrieb Jens-Ulrik Petersen: > > > > Hi, > > > > > > > > I think we need to retire git-annex from Fedora (the current > > > > version is very old and has security issues)

retiring git-annex

Hi, I think we need to retire git-annex from Fedora (the current version is very old and has security issues), since to build current versions needs adding a lot of new Haskell dependencies to Fedora. Currently noone has expressed interested in doing this... I plan to make a copr repo later at

Re: Fedora 26 Mass Branching

f27 builds in Koji are getting tagged with .fc26 currently, so I suggest holding off on rawhide builds for now that you also want to push to f26 until this is fixed. Jens On Wed, Mar 1, 2017 at 4:25 PM, Mohan Boddu wrote: > Hi All, > > Fedora 26 has now been branched, please

Re: Fedora rawhide compose report: 20170228.n.0 changes

Hi, ghc-8.0.2 went into F26/Rawhide yesterday! https://fedoraproject.org/wiki/Changes/GHC_8.0 There is still some minor clean-up ongoing to fix some remaining breakage: > [Agda] > ghc-Agda-2.4.2.5-3.fc26.x86_64 requires >

Re: Fedora 25 compose report: 20161010.n.0 changes

On Tue, Oct 11, 2016 at 12:08 AM, Fedora Branched Report < rawh...@fedoraproject.org> wrote: > [Agda] > [darcs] > [ghc-boxes] > [ghc-hakyll] > [ghc-happstack-server] > [ghc-hledger-lib] > [ghc-scotty] > [ghc-shelly] > [ghc-snap-core] > [ghc-snap-server] > [ghc-warp] > [haskell-platform] >

Re: Fedora rawhide compose report: 20160720.n.0 changes

I have retired the following packages: [bluetile] > [ghc-cmdtheline] > [ghc-concrete-typerep] > [ghc-glade] > [ghc-lambdabot-utils] > [ghc-monad-unify] > [haddock] > which should help to reduce the noise a bit in the next rawhide report. For the remaining Haskell breakage: [Agda] >

headsup: ghc-7.10.3 went into Rawhide

Hi! On behalf of the Fedora Haskell SIG, I am happy to announce that finally GHC 7.10 (7.10.3) has gone into Rawhide for F25. This is a new major release (though ghc-8.0.1 is already out for a little time now). The push comes also with a bunch of version updates including pandoc-1.17. You can

Re: Orphaned Packages in branched (2016-05-18)

On Thu, May 19, 2016 at 6:01 AM, wrote: > ghc-hakyll petersen, haskell-sig, mathstuf 12 > weeks ago > I would like to keep Hakyll in Fedora but unfortunately I think this can't be easily fixed for f24, due to the version bump of pandoc and old

Re: Orphaned Packages in rawhide (2015-09-07)

Removing rubygem-rgen (→ yum-utils, puppet → mock → koji → ...) doesn't look good... On Mon, Sep 7, 2015 at 4:13 PM, wrote: > Depending on: rubygem-rgen (47), status change: 2015-08-31 (0 weeks ago) > puppet (maintained by: kanarip, domcleal, gchamoul, georgiou, >

Re: Proposal: Drop comps

On Wed, Jul 15, 2015 at 8:39 PM, Vít Ondruch vondr...@redhat.com wrote: Do you think this is the way how regular users install software? I think a lot of people install yum groups. It is a pretty useful functionality IMO. If meta-packages become a viable replacement for comps then we can

<    1   2