Re: Is zh_Hans a valid locale name?

I think "zh_CN" is specified by ISO 639-1 and ISO 3166-1, and "zh-Hans" is used mainly in Unicode CLDR. The default locale for Simplified Chinese is "zh_CN.UTF-8". When gettext or glibc lookup the locale data, it will do some conversion to match from "zh_CN.UTF-8" locale to "zh_CN". But I

Re: python-cherrypy vs python3-cherrypy - can we keep just one?

On Thu, Feb 14, 2019 at 11:24:51PM +0100, Felix Schwarz wrote: > Am 14.02.19 um 23:15 schrieb Ken Dreyer: > > In that case, we can retire python3-cherrypy and move all development > > to python-cherrypy, right? > > We could, sure. But why bother? > I don't have strong feelings about either

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

OK, thanks Dan and Lennart for explanation. I also think it would be better to make this happen in the systemd RPM. It feel more suitable place for these kind of settings. Jirka On Thu, 2019-02-14 at 13:59 -0500, Daniel Walsh wrote: > Ok I guess this will not effect anaconda, just affect

Re: [Scitech] openmpi 3.1.3?

On Tue, Feb 12, 2019 22:13:59 -0700, Orion Poplawski wrote: > I'm thinking about trying to sneak in openmpi 3.1.3 before the f30 branch. > My COPR rebuilds have been looking pretty good lately so I hope it will go > fairly smoothly. Does anyone have any objections? I'm planning on starting >

Failing builds on Rawhide GCC 9

Hello, I'm doing daily builds of kakoune (vim-like editor) on COPR and it is failing for the last 23 days on Rawhide. This is happening only on Rawhide. It looks like this could be a problem with switching to GCC 9. The last successful build was on GCC 8 but there was time when my API token

Re: Review swap: newsboat

On Fri, Feb 15, 2019 at 5:04 PM J. Scheurich wrote: > > Hi, > > > I have packaged terminal RSS/Atom reader newsboat [1] for Fedora, and I > > would like to have it reviewed [2] (ideally before F30 beta). Any > > volunteers? > > I would review it (unclear, if i have the rights (i have a fedora >

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

Hi, On 15-02-19 12:51, Mikolaj Izdebski wrote: On Fri, Feb 15, 2019 at 12:11 PM Hans de Goede wrote: I will take sdljava as bolzplatz relies on it. I do not know how / why this was orphaned. This package has 2 other admin's in the user/group settings. If this was done automatically it would

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

On Fr, 15.02.19 13:42, Zygmunt Krynicki (m...@zygoon.pl) wrote: > > The "devices" cgroup controller is generally not available on > > cgroupsv2. However, there's now a set of bpf hook-ups that you can use > > instead and provide pretty much equivalent functionality. (systemd > > supports them

Fedora rawhide compose report: 20190215.n.0 changes

OLD: Fedora-Rawhide-20190214.n.0 NEW: Fedora-Rawhide-20190215.n.0 = SUMMARY = Added images:0 Dropped images: 4 Added packages: 6 Dropped packages:4 Upgraded packages: 137 Downgraded packages: 0 Size of added packages: 17.94 MiB Size of dropped packages

Fedora Rawhide-20190215.n.0 compose check report

Missing expected images: Atomichost qcow2 x86_64 Atomichost raw-xz x86_64 Compose FAILS proposed Rawhide gating check! 10 of 47 required tests failed, 9 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 26/143 (x86_64), 3/24

Re: Review swap: newsboat

On 15. 02. 19 17:01, J. Scheurich wrote:> I would review it (unclear, if i have the rights (i have a fedora > account, but i don't know, if this is sufficent for a offical review)) > in return for white_dune fedora sponsoring... I'm not able to sponsor new packagers, sorry. In the meantime, the

Re: Heads up: significant change to fs.protected_regular and fs.protected_fifos sysctls with systemd 241

On to, 14 helmi 2019, Adam Williamson wrote: On Thu, 2019-02-14 at 12:16 -0800, Adam Williamson wrote: Hey folks! Just wanted to give the list a heads-up about a significant change I've just found out about in systemd 241. There are a couple of sysctls that were apparently introduced with

Re: Failing builds on Rawhide GCC 9

On 15/02/19 15:31 +, Jonathan Wakely wrote: On 15/02/19 09:56 +0100, jkone...@redhat.com wrote: Hello, I'm doing daily builds of kakoune (vim-like editor) on COPR and it is failing for the last 23 days on Rawhide. This is happening only on Rawhide. It looks like this could be a problem

Re: Review swap: newsboat

Hi, I have packaged terminal RSS/Atom reader newsboat [1] for Fedora, and I would like to have it reviewed [2] (ideally before F30 beta). Any volunteers? I would review it (unclear, if i have the rights (i have a fedora account, but i don't know, if this is sufficent for a offical review)) in

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

On Fri, Feb 15, 2019 at 10:43 AM Miro Hrončok wrote: > > On 13. 02. 19 15:32, Fabio Valentini wrote: > > On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer wrote: > >> > >> * Fabio Valentini: > >> > >>> In the past few weeks, it has come up regularly that future > >>> "module-only" packages are

OpenMPI 3.1.3 rebuilds (mostly) complete

The rebuilds of the OpenMPI deps are (mostly) complete. Some issues: c2pk - http://koji.fedoraproject.org/koji/buildinfo?buildID=1210124 Looks like a missing dep on python-setuptools somewhere, perhaps in fypp: BUILDSTDERR: Traceback (most recent call last): BUILDSTDERR: File

Re: Failing builds on Rawhide GCC 9

On 15/02/19 09:56 +0100, jkone...@redhat.com wrote: Hello, I'm doing daily builds of kakoune (vim-like editor) on COPR and it is failing for the last 23 days on Rawhide. This is happening only on Rawhide. It looks like this could be a problem with switching to GCC 9. The last successful build

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

Dne 15. 02. 19 v 14:22 Emmanuel Seyman napsal(a): > * Hans de Goede [15/02/2019 12:09] : >> And automatic scripts really just should hand it over to the first >> co-maintainer >> in the list. As long as we have no idea if the other maintainers are active, I am strongly against the automation.

Re: Failing builds on Rawhide GCC 9

Hello Jonathan, Thanks a lot for your help and for the bug link. Jirka On Fri, 2019-02-15 at 15:33 +, Jonathan Wakely wrote: > On 15/02/19 15:31 +, Jonathan Wakely wrote: > > On 15/02/19 09:56 +0100, jkone...@redhat.com wrote: > > > Hello, > > > > > > I'm doing daily builds of kakoune

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

On Fr, 15.02.19 12:55, Zygmunt Krynicki (m...@zygoon.pl) wrote: > I’m happy to work on this issue once it becomes „pressing” and once > the prerequisites are available. If F30 disables v1 entirely and has > a kernel where we can get device, freezer and pid controllers then > it’s „just” a matter

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

* Fabio Valentini: > On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer wrote: >> >> * Fabio Valentini: >> >> > In the past few weeks, it has come up regularly that future >> > "module-only" packages are orphaned (and hence will soon be retired), >> > and nobody stepped up to fix this issue -

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

On 15. 02. 19 14:14, Neal Gompa wrote: On Fri, Feb 15, 2019 at 7:46 AM Florian Weimer wrote: * Fabio Valentini: On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer wrote: * Fabio Valentini: In the past few weeks, it has come up regularly that future "module-only" packages are orphaned (and

Re: Is zh_Hans a valid locale name?

I have filed an upstream ticket about this, in case anyone is interested in participating there: https://github.com/dino/dino/issues/524 signature.asc Description: This is a digitally signed message part ___ devel mailing list --

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

> Wiadomość napisana przez Lennart Poettering w dniu > 15.02.2019, o godz. 13:02: > > On Fr, 15.02.19 12:55, Zygmunt Krynicki (m...@zygoon.pl) wrote: > >> I’m happy to work on this issue once it becomes „pressing” and once >> the prerequisites are available. If F30 disables v1 entirely and

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

On 2/15/19 6:55 AM, Zygmunt Krynicki wrote: > > >> Wiadomość napisana przez Neal Gompa > > w dniu 15.02.2019, o godz. 12:51: >> >> On Fri, Feb 15, 2019 at 4:11 AM Zbigniew Jędrzejewski-Szmek >> mailto:zbys...@in.waw.pl>> wrote: >>> >>> On Thu, Feb 14, 2019 at 08:10:09AM

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

On Fri, Feb 15, 2019 at 4:11 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Feb 14, 2019 at 08:10:09AM -0500, Daniel Walsh wrote: > > I have opened a Change Request to change the defaults for Fedora 31 to > > Cgroups V2. I am looking for what packages will be affected by this > > change.

Re: Assertion in stl_vector.h

On Thursday, 14 February 2019 at 16:00, Christoph Junghans wrote: > On Wed, Feb 13, 2019 at 1:35 PM Christoph Junghans wrote: > > > > Hi, > > > > I am trying to debug https://bugzilla.redhat.com/show_bug.cgi?id=1674863 > > however I cannot reproduce the issue locally using mock: > >

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

On Fri, Feb 15, 2019 at 7:46 AM Florian Weimer wrote: > > * Fabio Valentini: > > > On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer wrote: > >> > >> * Fabio Valentini: > >> > >> > In the past few weeks, it has come up regularly that future > >> > "module-only" packages are orphaned (and hence will

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

On Fri, Feb 15, 2019 at 12:11 PM Hans de Goede wrote: > I will take sdljava as bolzplatz relies on it. > > I do not know how / why this was orphaned. This package has > 2 other admin's in the user/group settings. If this was done > automatically it would be nice if we could change the automatic >

Re: toolchain requirements for external kernel modules

* Laura Abbott: > I've been experimenting with enabling CONFIG_GCC_PLUGINS in the kernel > since I've heard some people express interest in stackleak (I'm interested > as well). a gcc plugin gets built as an .so file for use during > compilation. This means we need to package this .so file as

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

> Wiadomość napisana przez Neal Gompa w dniu 15.02.2019, o > godz. 12:51: > > On Fri, Feb 15, 2019 at 4:11 AM Zbigniew Jędrzejewski-Szmek > mailto:zbys...@in.waw.pl>> wrote: >> >> On Thu, Feb 14, 2019 at 08:10:09AM -0500, Daniel Walsh wrote: >>> I have opened a Change Request to change the

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

On Fri, Feb 15, 2019 at 2:14 PM Neal Gompa wrote: > > On Fri, Feb 15, 2019 at 7:46 AM Florian Weimer wrote: > > > > * Fabio Valentini: > > > > > On Wed, Feb 13, 2019 at 3:23 PM Florian Weimer wrote: > > >> > > >> * Fabio Valentini: > > >> > > >> > In the past few weeks, it has come up regularly

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

* Hans de Goede [15/02/2019 12:09] : > > And automatic scripts really just should hand it over to the first > co-maintainer > in the list. This inspires two observations (which I'm sure you already know). * There's no such thing as "the first co-maintainer" There are co-maintainers and they

Orphaned rubygem-fakeweb

Hi everybody, rubygem-fakeweb used to be part of Ruby on Rails dependency chain, but it is not anymore. Therefore I am going to orphan the package. The package is not well maintained upstream and there are better maintained packages such as webmock. There package is currently FTBFS.

Re: Retiring pysvn (was Re: Orphaning pysvn (and non-responsive maintainer: ravenoak))

> On 13 Feb 2019, at 13:52, Stephen Gallagher wrote: > > On Tue, Feb 5, 2019 at 10:01 AM Stephen Gallagher wrote: >> >> I've been maintaining this for several years since the main admin >> (ravenoak) vanished from Fedora. I don't use it anymore (and most of >> the world has long since

Re: Review swaps

OK, I think your packages all have reviews now. Would you be willing to do these two in return? They're both re-reviews of previously approved but then retired NodeJS packages. nodejs-is-plain-obj: https://bugzilla.redhat.com/show_bug.cgi?id=1676540 nodejs-event-stream:

Re: Review swaps

On Fri, Feb 15, 2019 at 11:36 AM Tom Hughes wrote: > I've already done those two... Well, then, I owe Jared some reviews. Jared, give me a yell the next time you have packages that need to be reviewed. I'll try to beat Tom to them next time. :-) Regards, -- Jerry James

Re: Review swap: newsboat

On Fri, Feb 15, 2019 at 9:04 AM J. Scheurich wrote: > I would review it (unclear, if i have the rights (i have a fedora > account, but i don't know, if this is sufficent for a offical review)) > in return for white_dune fedora sponsoring... Mufti, don't despair! We're getting there. Let's keep

Removing Atomic Host from Fedora Rawhide

Hello Fedora Atomic Host users, With the switched focus to Fedora CoreOS for the future of our immmutable, container oriented operating systems the last major release of Fedora Atomic Host was Fedora 29. Considering this we are removing the builds for Fedora Atomic Host from rawhide and will

Re: Review swaps

I've already done those two... Tom On 15/02/2019 18:25, Jared K. Smith wrote: OK, I think your packages all have reviews now.  Would you be willing to do these two in return?  They're both re-reviews of previously approved but then retired NodeJS packages. nodejs-is-plain-obj:

Re: Python packages with extras dependencies

> I'd still consider this on case by case basis instead of developing a general > solution, sometimes a simple Recommends works. Sometimes, it's more > complicated. That's fair and makes a lot of sense. I do like the pattern mentioned by Igor as used for Rust packages of using + as a separator

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

On 2/15/19 7:02 AM, Lennart Poettering wrote: > On Fr, 15.02.19 12:55, Zygmunt Krynicki (m...@zygoon.pl) wrote: > >> I’m happy to work on this issue once it becomes „pressing” and once >> the prerequisites are available. If F30 disables v1 entirely and has >> a kernel where we can get device,

Review swap: newsboat

Hi all, I have packaged terminal RSS/Atom reader newsboat [1] for Fedora, and I would like to have it reviewed [2] (ideally before F30 beta). Any volunteers? I offer to do a package review in return -- let me know if you need anything reviewed. Best regards, Jan [1]: https://newsboat.org/ [2]:

[Test-Announce] Proposal to CANCEL: 2019-02-18 Fedora QA Meeting

Hi folks! I'm proposing we cancel the QA meeting on Monday. I think we got through everything pretty well at the last meeting, but if you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. I'm also not expecting to

RFE: fedpkgdiff?

I'm curious to see if anyone else would find this useful... What about a fedpkgdiff as a wrapper around pkgdiff (similar to fedabipkgdiff) but just to see the difference between two packages (either local or from the repos like fedabipkgdiff), specifically differences in: - installed files (not

Re: RFE: fedpkgdiff?

On Fri, Feb 15, 2019, 22:55 Richard Shaw I'm curious to see if anyone else would find this useful... > > What about a fedpkgdiff as a wrapper around pkgdiff (similar to > fedabipkgdiff) but just to see the difference between two packages (either > local or from the repos like fedabipkgdiff),

Re: RFE: fedpkgdiff?

On 15. 02. 19 22:54, Richard Shaw wrote: I'm curious to see if anyone else would find this useful... What about a fedpkgdiff as a wrapper around pkgdiff (similar to fedabipkgdiff) but just to see the difference between two packages (either local or from the repos like fedabipkgdiff),

Re: RFE: fedpkgdiff?

On Fri, Feb 15, 2019 at 4:09 PM Fabio Valentini wrote: > On Fri, Feb 15, 2019, 22:55 Richard Shaw >> I'm curious to see if anyone else would find this useful... >> >> What about a fedpkgdiff as a wrapper around pkgdiff (similar to >> fedabipkgdiff) but just to see the difference between two

[EPEL-devel] Re: Proposed EPEL policy change: Minor release based composes

I would add as a benefit that past experiences have taught us that at times, packages in EPEL may be included in new minor RHEL releases, and would therefore need to be dropped from EPEL. In any case, +1 from me. ___ epel-devel mailing list --

[Bug 1627117] perl-Gtk3-0.034-3.fc30 FTBFS: Undefined subroutine ::Gdk::PIXDATA_HEADER_LENGTH called at /builddir/build/BUILD/Gtk3-0.034/blib/lib/Gtk3.pm line 2119

https://bugzilla.redhat.com/show_bug.cgi?id=1627117 Daniel Berrange changed: What|Removed |Added Status|NEW |CLOSED Resolution|---

[EPEL-devel] Re: Proposed EPEL policy change: Release based package lifetimes

On Fri, 15 Feb 2019 at 09:39, Troy Dawson wrote: > > I want to make sure I'm reading this right. > A packager puts a package into EPEL. > If the user does nothing, that package continues to be in EPEL. > If the user wishes to end support, they sent off and email, compose > one final build (if it

[EPEL-devel] Re: Proposed EPEL policy change: Release based package lifetimes

On Fri, Feb 15, 2019 at 8:34 AM Stephen John Smoogen wrote: > > On Fri, 15 Feb 2019 at 09:39, Troy Dawson wrote: > > > > I want to make sure I'm reading this right. > > A packager puts a package into EPEL. > > If the user does nothing, that package continues to be in EPEL. > > If the user wishes

[EPEL-devel] Re: Proposed EPEL policy change: Release based package lifetimes

On Fri, 15 Feb 2019 at 11:45, Troy Dawson wrote: > > > Yes it does. > Do we want to put anything in about packages that no longer install > due to updates. Whether those updates are in EPEL or RHEL. > An example would be when EPEL7 nodejs goes to nodejs 8 (or 10), > There will be a handful of

sphinx-build conf.py circular dependency

I'm trying to package 'migen': http://www.contrib.andrew.cmu.edu/~somlo/python-migen-rpm/python-migen.spec The sources come with a ./doc directory that uses sphinx-build to generate documentation, and a ./doc/conf.py file which imports the package being built, in order to automatically paste

[EPEL-devel] Re: Proposed EPEL policy change: Minor release based composes

On Fri, Feb 15, 2019 at 09:45:01AM -, Jeroen van Meeuwen wrote: > I would add as a benefit that past experiences have taught us that at > times, packages in EPEL may be included in new minor RHEL releases, and > would therefore need to be dropped from EPEL. In the future, we won't necessarily

Re: sphinx-build conf.py circular dependency

On 15. 02. 19 17:57, Gabriel L. Somlo wrote: I'm trying to package 'migen': http://www.contrib.andrew.cmu.edu/~somlo/python-migen-rpm/python-migen.spec The sources come with a ./doc directory that uses sphinx-build to generate documentation, and a ./doc/conf.py file which imports the package

[EPEL-devel] Re: Proposed EPEL policy change: Release based package lifetimes

I want to make sure I'm reading this right. A packager puts a package into EPEL. If the user does nothing, that package continues to be in EPEL. If the user wishes to end support, they sent off and email, compose one final build (if it can compose), wait for it to land, then send off another

Re: sphinx-build conf.py circular dependency

On 15. 02. 19 18:32, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Feb 15, 2019 at 06:19:10PM +0100, Miro Hrončok wrote: On 15. 02. 19 17:57, Gabriel L. Somlo wrote: I'm trying to package 'migen': http://www.contrib.andrew.cmu.edu/~somlo/python-migen-rpm/python-migen.spec The sources come with

Re: sphinx-build conf.py circular dependency

On Fri, Feb 15, 2019 at 06:19:10PM +0100, Miro Hrončok wrote: > On 15. 02. 19 17:57, Gabriel L. Somlo wrote: > >I'm trying to package 'migen': > > > >http://www.contrib.andrew.cmu.edu/~somlo/python-migen-rpm/python-migen.spec > > > >The sources come with a ./doc directory that uses sphinx-build to

Removing Atomic Host from Fedora Rawhide

Hello Fedora Atomic Host users, With the switched focus to Fedora CoreOS for the future of our immmutable, container oriented operating systems the last major release of Fedora Atomic Host was Fedora 29. Considering this we are removing the builds for Fedora Atomic Host from rawhide and will

Re: sphinx-build conf.py circular dependency

Zbyszek, Miro, Thanks much for your help. I ended up calling sphinx-build-3 directly as per Zbyszek's example. In retrospect, what tripped me up was that pkg_resources.require("migen")[0].version is *not* helped by setting PYTHONPATH, but the "import migen" line further down *is*. I had