Re: subscription-manager & related packages naming

Dne 10.1.2018 v 21:47 Kevin Howell napsal(a): > Right now, I'm thinking what must be done is: rename > subscription-manager-rhsm to python-rhsm or python2-rhsm or > python3-rhsm per the python naming guidelines. Rename the package to python-rhsm which does not have main package and only two

Re: Rawhide / ruby / SystemStackError / "stack level too deep"

OK I believe this is actually a bug in the nbdkit plugin rather than glibc / Ruby. Apparently you need to call some functions to tell Ruby about the thread stacks. Totally undocumented ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my

Rename of webkitgtk4 to webkit2gtk3

Hi everyone, just a heads-up that we are going to rename the webkitgtk4 package to webkit2gtk3 in the rawhide - please see [0]. I will take care of updating the BR for the packages under gnome-sig myself and for others I will create a PR. $ dnf repoquery --whatrequires webkitgtk4 --arch x86_64

Re: Rawhide / ruby / SystemStackError / "stack level too deep"

On Thu, Jan 11, 2018 at 01:19:41PM +0100, Florian Weimer wrote: > On 01/11/2018 12:42 PM, Richard W.M. Jones wrote: > >If anyone notices Ruby programs which suddenly start to throw stack > >overflow errors (SystemStackError or the error message > >"stack level too deep") but*only* in the latest

Re: SciDAVis and liborigin3 vs liborigin & liborigin2 - bundle or obsolete?

Hello, Alexander. Sorry to bring back an old e-mail, but it seems there were no replies. On Saturday, 26 August 2017 at 22:50, Alexander Ploumistos wrote: [...] > I have checked if there are any packages at the moment that require > liborigin* or liborigin*-devel and I have found none (though I'd

Re: Security updates and batched pushes

On Wed, Jan 10, 2018, at 2:38 PM, Stephen John Smoogen wrote: > > This sounds a lot like the Atomic project and how it does things... Atomic could mean either (rpm)-ostree or Docker/OCI. In the Docker/OCI world search isn't standardized yet AIUI but there's progress on that upstream. I am

Re: Security updates and batched pushes

One followup that should help people understand things: When someone pushes an update to a package that isn't in Atomic Host (or Workstation), *and* one is using rpm-ostree in "pure ostree" mode (i.e. you never ran `rpm-ostree install`), then checking for updates just uses libostree, which like

Re: scotch: packaging a version with 64bit integers

On 11.01.2018 09:25, Dominik 'Rathann' Mierzejewski wrote: Hi, Sandro. On Wednesday, 10 January 2018 at 14:58, Sandro Mani wrote: I've received a request to package a version of scotch with 64bit integers (as opposed to 32bit). I suppose the details are less important, the bottom line is

Re: Security updates and batched pushes

On Wed, Jan 10, 2018 at 2:23 PM, Andrew Lutomirski wrote: >> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi wrote: >> >>> On 01/08/2018 10:53 AM, Kevin Kofler wrote: >>> Kevin Fenzi wrote: Well, if this firefox update was urgent, shouldn't it have been marked

Re: Empty debugsourcefiles.list when building out of source

On Thu, Jan 11, 2018 at 11:21:56AM +0100, Patrick Monnerat wrote: > I also encountered this problem before and I fixed it by respecting the > RPM_OPT_FLAGS. Before cmake, use: > > export CFLAGS="${RPM_OPT_FLAGS}" > export CXXFLAGS="${RPM_OPT_FLAGS}" Is there a place where you see that we must

Re: Empty debugsourcefiles.list when building out of source

On Thu, Jan 11, 2018 at 11:45 AM, David Demelier wrote: > Is there a place where you see that we must use this variable? > > Anyway, it worked, I changed the CMake invocation to: > > cmake ... \ > -DCMAKE_C_FLAGS="${RPM_OPT_FLAGS}" \ >

Re: Empty debugsourcefiles.list when building out of source

On Thu, Jan 11, 2018 at 11:50:50AM +0100, Andrea Musuruane wrote: > Actually you should use the %cmake macro: > https://fedoraproject.org/wiki/Packaging:Cmake Thanks, this is indeed the correct solution. -- David Demelier ___ devel mailing list --

Rawhide / ruby / SystemStackError / "stack level too deep"

If anyone notices Ruby programs which suddenly start to throw stack overflow errors (SystemStackError or the error message "stack level too deep") but *only* in the latest Rawhide (glibc >= 2.26-9000, ruby >= 2.5.0), then I'm interested to hear from you. Rich. -- Richard Jones, Virtualization

Re: Empty debugsourcefiles.list when building out of source

On 01/11/2018 11:45 AM, David Demelier wrote: On Thu, Jan 11, 2018 at 11:21:56AM +0100, Patrick Monnerat wrote: I also encountered this problem before and I fixed it by respecting the RPM_OPT_FLAGS. Before cmake, use: export CFLAGS="${RPM_OPT_FLAGS}" export CXXFLAGS="${RPM_OPT_FLAGS}" Is

Re: F28 System Wide Change: Rename "nobody" user

On Do, 11.01.18 10:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > As a very simple example take a docker host that has been upgraded > > with a fresh container on it. The nobody user is going to differ > > between the two which will at a minimum cause confusion, if not actual > >

Re: HEADS UP - Changes to Ghostscript package in F28

On Wed, Jan 10, 2018 at 7:50 PM, Adam Williamson wrote: > On Wed, 2018-01-10 at 10:45 +0100, Kamil Dudka wrote: > > On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote: > > > The new Ghostscript should be available for trying/testing in Rawhide >

Re: Empty debugsourcefiles.list when building out of source

On Thu, 2018-01-11 at 11:21 +0100, Patrick Monnerat wrote: > I also encountered this problem before and I fixed it by respecting > the  > RPM_OPT_FLAGS. Before cmake, use: > > export CFLAGS="${RPM_OPT_FLAGS}" > export CXXFLAGS="${RPM_OPT_FLAGS}" > > This did the trick. > > Obviously the problem

Re: F28 System Wide Change: Rename "nobody" user

On Thu, Jan 11, 2018 at 10:26:19AM +, James Hogarth wrote: > On 11 January 2018 at 01:41, Zbigniew Jędrzejewski-Szmek > wrote: > > On Wed, Jan 10, 2018 at 10:26:24AM -0500, Nico Kadel-Garcia wrote: > >> On Wed, Jan 10, 2018 at 6:18 AM, Zbigniew Jędrzejewski-Szmek > >>

Re: Empty debugsourcefiles.list when building out of source

On Thu, Jan 11, 2018 at 5:13 AM, David Demelier wrote: > Hello, > > I'm trying to upgrade my OpenRCT 2 package [0] to fedora 27. > > It looks like something changed regarding the generation of debug files > because > I can't get it to build a .rpm anymore. > > I get: > >

Re: Empty debugsourcefiles.list when building out of source

On 01/11/2018 11:13 AM, David Demelier wrote: Hello, I'm trying to upgrade my OpenRCT 2 package [0] to fedora 27. It looks like something changed regarding the generation of debug files because I can't get it to build a .rpm anymore. I get: Processing files:

Re: F28 System Wide Change: Rename "nobody" user

On 11 January 2018 at 01:41, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jan 10, 2018 at 10:26:24AM -0500, Nico Kadel-Garcia wrote: >> On Wed, Jan 10, 2018 at 6:18 AM, Zbigniew Jędrzejewski-Szmek >> wrote: >> > On Wed, Jan 10, 2018 at 11:56:46AM +0100,

Re: Empty debugsourcefiles.list when building out of source

On Thu, Jan 11, 2018 at 05:22:05AM -0500, Nico Kadel-Garcia wrote: > What RPM are you building from? I do rpmbuild -ba OpenRCT2.spec -- David Demelier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: F28 System Wide Change: Rename "nobody" user

On Thu, Jan 11, 2018 at 12:34:54PM +0100, Lennart Poettering wrote: > On Do, 11.01.18 10:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > As a very simple example take a docker host that has been upgraded > > > with a fresh container on it. The nobody user is going to differ > >

Re: Rawhide / ruby / SystemStackError / "stack level too deep"

On 01/11/2018 12:42 PM, Richard W.M. Jones wrote: If anyone notices Ruby programs which suddenly start to throw stack overflow errors (SystemStackError or the error message "stack level too deep") but*only* in the latest Rawhide (glibc >= 2.26-9000, ruby >= 2.5.0), then I'm interested to hear

Empty debugsourcefiles.list when building out of source

Hello, I'm trying to upgrade my OpenRCT 2 package [0] to fedora 27. It looks like something changed regarding the generation of debug files because I can't get it to build a .rpm anymore. I get: Processing files: OpenRCT2-debugsource-0.1.1-1.fc27.x86_64 error: Empty %files file

Re: provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide

On Wednesday, 10 January 2018 at 23:27, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jan 09, 2018 at 08:27:51PM +, Sérgio Basto wrote: [...] > > I need more one help from provenpackager merge and build player [1] > > from what I see to build fawkes, you just need rebuild player. I had > >

Re: scotch: packaging a version with 64bit integers

Hi, Sandro. On Wednesday, 10 January 2018 at 14:58, Sandro Mani wrote: > I've received a request to package a version of scotch with 64bit integers > (as opposed to 32bit). I suppose the details are less important, the bottom > line is > > scotch 32bit: typedef int32_t SCOTCH_Num; > > scotch

Re: SciDAVis and liborigin3 vs liborigin & liborigin2 - bundle or obsolete?

Hello Dominik, On Thu, Jan 11, 2018 at 2:52 PM, Dominik 'Rathann' Mierzejewski wrote: > On Saturday, 26 August 2017 at 22:50, Alexander Ploumistos wrote: > [...] >> I have checked if there are any packages at the moment that require >> liborigin* or liborigin*-devel and I

Re: Rawhide / ruby / SystemStackError / "stack level too deep"

> If anyone notices Ruby programs which suddenly start to throw stack overflow errors (SystemStackError or the error message "stack level too deep") but *only* in the latest Rawhide (glibc >= 2.26-9000, ruby >= 2.5.0), then I'm interested to hear from you. I faced "stack level too deep" when

Re: Making ResultsDB dumps public?

On Wed, Nov 1, 2017 at 7:48 PM, Kevin Fenzi wrote: > On 10/24/2017 03:36 AM, Kamil Paral wrote: > > On Sun, Oct 8, 2017 at 12:14 AM, Kevin Fenzi wrote: > > > >> They should be there starting tomorrow. > >> > > > > > > I still don't see any dumps in there. Is it

Re: F28 System Wide Change: Rename "nobody" user

> And also, at some point in the future once this is implemented and the > new setup has been around for a while, systemd should start emitting a > warning during boot, to notify people that such setups will stop being > supported at some future point. But your average user won't see that. For

Re: Security updates and batched pushes

On Wed, 2018-01-10 at 08:06 -0800, Kevin Fenzi wrote: > On 01/09/2018 02:09 PM, Tim Landscheidt wrote: > > BTW, are there technical reasons why the metadata is updated > > en bloc and not incrementally like for example delta RPMs, > > or is it just that nobody bothered to implement something > >

Re: F28 System Wide Change: Rename "nobody" user

On Thu, Jan 11, 2018 at 3:26 AM, James Hogarth wrote: > Having upgraded and freshly installed systems so different is going to > be messy with supporting users and in many deployed environments... > and it's not even about F26 and F27 -> F28 but what happens on an F29+ >

Orphaned perl-Net-Ping-External, perl-Net-RawIP, python-4Suite-XML

Hello, I have orphaned: - perl-Net-Ping-External (no in-Fedora users it seems) - perl-Net-RawIP (used by sqlninja) - python-4Suite-XML (used by python-amara and testoob) Feel free to take them over. Mirek ___ devel mailing list --

Re: F28 System Wide Change: Rename "nobody" user

On Thu, Jan 11, 2018 at 5:53 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jan 11, 2018 at 10:26:19AM +, James Hogarth wrote: >> I know this may sound fairly nasty in terms of work required to agree >> a solution but I honestly have a strong dislike to taking this >>

Re: F28 System Wide Change: Rename "nobody" user

On Thu, Jan 11, 2018 at 6:57 AM, Zbigniew Jędrzejewski-Szmek wrote: > And also, at some point in the future once this is implemented and the > new setup has been around for a while, systemd should start emitting a > warning during boot, to notify people that such setups will

Re: Empty debugsourcefiles.list when building out of source

On Thu, Jan 11, 2018 at 5:39 AM, David Demelier wrote: > On Thu, Jan 11, 2018 at 05:22:05AM -0500, Nico Kadel-Garcia wrote: >> What RPM are you building from? > > I do rpmbuild -ba OpenRCT2.spec I should have said "SRPM". What you have mentioned there is a .spec file, and

Re: F28 System Wide Change: Rename "nobody" user

On Do, 11.01.18 16:13, Steve Dickson (ste...@redhat.com) wrote: > > This is problematic in a few different ways: > > * 65534:65534 is used by the kernel as the overflow identifier, when > > some UID cannot be represented in the current namespace. This applies > > to both NFS, but probably more

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

> "TD" == Troy Dawson writes: TD> If you have something like that, please change it to something like TD> this. TD> if 0%{?fedora} || 0%{?rhel} > 7 TD>%define with_python3 1 TD> %endif If things work as they have in the past, packages will need to explicitly be

Planned Outage: nuancier - 2018/01/12 10:00 UTC

Planned Outage: apps.fedoraproject.org/nuancier 2018-01-12 10:00 UTC There will be an outage starting at 2018-01-12 10:00 UTC, which will last approximately 30 minutes, To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d

[Test-Announce] Call for testing: kernel 4.14.13-200.fc26 / 4.14.13-300.fc27 - initial Spectre mitigations

Hi folks! Kernel updates for Fedora 26 and Fedora 27 are now available with initial mitigations for both Spectre variants. As the update description states: "This is also the first update to contain some spectre mitigations. Some patches for variant 1 as well as the initial retpoline build for

Re: F28 System Wide Change: Rename "nobody" user

On Thu, Jan 11, 2018 at 11:24:56PM +0100, Lennart Poettering wrote: > I hope you are aware that user id 65534 is used by user namespacing > (i.e. CLONE_NEWUSER) too, and in that context is probably much more > prominently visible to users than in the NFS context. The fact that > the user/group is

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

On 01/11/2018 10:09 PM, Jason L Tibbitts III wrote: TD> If you have something like that, please change it to something like TD> this. TD> if 0%{?fedora} || 0%{?rhel} > 7 TD>%define with_python3 1 TD> %endif If things work as they have in the past, packages will need to explicitly be

[Test-Announce] Re: Call for testing: kernel 4.14.13-200.fc26 / 4.14.13-300.fc27 - initial Spectre mitigations

On Thu, 2018-01-11 at 13:55 -0800, Adam Williamson wrote: > Hi folks! > > Kernel updates for Fedora 26 and Fedora 27 are now available with > initial mitigations for both Spectre variants. As the update > description states: > > "This is also the first update to contain some spectre mitigations.

Re: F28 System Wide Change: Rename "nobody" user

On Thu, 11 Jan 2018, Lennart Poettering wrote: > We are not taking the concept of this user/group away. We are also not > taking the UID/GID assignment 65534 away, either. All we are doing is > assigning it a better name and do so unconditionally, independently of > whether nfsutils is installed

Re: Schedule for Friday's FESCo Meeting (2018-01-12)

On Thu, Jan 11, 2018 at 01:57:55PM -0600, Justin Forbes wrote: > Following is the list of topics that will be discussed in the > FESCo meeting Friday at 16:00UTC in #fedora-meeting on > irc.freenode.net. > > To convert UTC to your local time, take a look at >

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

> "FW" == Florian Weimer writes: FW> It could also be branched into Red Hat Enterprise Linux proper, and FW> in that case, it would be nice to minimize the differences. That would be kind of outside the scope of Fedora, though. Many of us watching from outside would

Python3 will be in next major RHEL release, please adjust %if statements accordingly

Hello, Python3 will be in the next major RHEL release. I don't mean RHEL 7.6, but with numbers higher than 7. There are many, many packages with something like the following if 0%{?fedora} %define with_python3 1 %endif If you have something like that, please change it to something like

Re: F28 System Wide Change: Rename "nobody" user

On 01/10/2018 11:14 AM, Stephen John Smoogen wrote: > On 10 January 2018 at 08:50, Neal Gompa wrote: >> On Wed, Jan 10, 2018 at 5:46 AM, Jan Kurik wrote: > >>> The new mapping for nobody:nobody would be implemented in two redundant >>> ways: >>> *

Re: F28 System Wide Change: Rename "nobody" user

On Thu, 2018-01-11 at 10:19 -0700, Chris Murphy wrote: > On Thu, Jan 11, 2018 at 3:26 AM, James Hogarth > wrote: > > > Having upgraded and freshly installed systems so different is going to > > be messy with supporting users and in many deployed environments... > > and

Re: F28 System Wide Change: Rename "nobody" user

WOW... Why do you guys keep picking on NFS?? :-) On 01/10/2018 05:46 AM, Jan Kurik wrote: > = System Wide Change: Rename "nobody" user = > https://fedoraproject.org/wiki/Changes/RenameNobodyUser > > Change owner(s): > *Zbigniew Jędrzejewski-Szmek > * Lennart Poettering > > Use "nobody:nobody"

/proc/sys/net/core/optmem_max on armv7l

Hello together, I just noticed, there is a difference in the default value of `/proc/sys/net/core/optmem_max` on armv7l: On all arches it is 20480, but on armv7l it is 10240. Is there any specific reason for limiting the maximum ancillary buffer size allowed per socket on this arch? Cheers,

[Test-Announce] Fedora 28 Rawhide 20180111.n.0 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora 28 Rawhide 20180111.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki

Schedule for Friday's FESCo Meeting (2018-01-12)

Following is the list of topics that will be discussed in the FESCo meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2018-01-12 16:00 UTC' Links to all issues below

Re: F28 System Wide Change: Rename "nobody" user

On Thu, Jan 11, 2018 at 1:08 PM, Adam Williamson wrote: > On Thu, 2018-01-11 at 10:19 -0700, Chris Murphy wrote: > > On Thu, Jan 11, 2018 at 3:26 AM, James Hogarth > wrote: > > > > > Having upgraded and freshly installed systems so different

Re: F28 System Wide Change: IBus Unicode Typing

On 01/11/18 09:47, Christopher-san wrote: On Tue, Jan 9, 2018 at 9:08 AM Jan Kurik > wrote: = System Wide Change: IBus Unicode Typing = https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing Change owner(s): * Takao Fujiwara

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

On Thu, 2018-01-11 at 20:53 -0500, Josh Boyer wrote: > Small caveat, nobody said RHEL 8. Troy said the next major version of > RHEL will have python3, that's all. This is where the awkwardness > comes in. I think people can appreciate not being able to talk > publicly about any current or

Fedora Rawhide-20180111.n.0 compose check report

Missing expected images: Atomic qcow2 x86_64 Atomic raw-xz x86_64 Failed openQA tests: 11/129 (x86_64), 5/24 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20180110.n.0): ID: 185438 Test: i386 Workstation-boot-iso install_default URL:

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

> "JB" == Josh Boyer writes: JB> Hm. On the one hand, that's a fair assumption to make. On the JB> other hand, it seems unnecessarily adversarial. I certainly didn't intend it that way; hell, none of that even entered my mind. To flip it around, to be

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

On Thu, Jan 11, 2018 at 4:34 PM, Jason L Tibbitts III wrote: >> "FW" == Florian Weimer writes: > > FW> It could also be branched into Red Hat Enterprise Linux proper, and > FW> in that case, it would be nice to minimize the differences. > > That would

Re: /proc/sys/net/core/optmem_max on armv7l

> I just noticed, there is a difference in the default value of > `/proc/sys/net/core/optmem_max` on armv7l: > > On all arches it is 20480, but on armv7l it is 10240. > > Is there any specific reason for limiting the maximum ancillary buffer > size allowed per socket on this arch? No specific

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

On Thu, Jan 11, 2018 at 8:32 PM, Jason L Tibbitts III wrote: >> "JB" == Josh Boyer writes: > > JB> Hm. On the one hand, that's a fair assumption to make. On the > JB> other hand, it seems unnecessarily adversarial. > > I certainly didn't intend

Re: F28 System Wide Change: IBus Unicode Typing

On 01/11/18 09:47, Christopher-san wrote: On Tue, Jan 9, 2018 at 9:08 AM Jan Kurik > wrote: = System Wide Change: IBus Unicode Typing = https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing Change owner(s): * Takao Fujiwara

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

On 2018-01-11 01:02 PM, Troy Dawson wrote: > Hello, > Python3 will be in the next major RHEL release. I don't mean RHEL > 7.6, but with numbers higher than 7. > There are many, many packages with something like the following > > if 0%{?fedora} >%define with_python3 1 > %endif > > If you

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

On 01/12/2018 06:08 AM, Luya Tshimbalanga wrote: On 2018-01-11 01:02 PM, Troy Dawson wrote: Hello, Python3 will be in the next major RHEL release. I don't mean RHEL 7.6, but with numbers higher than 7. There are many, many packages with something like the following if 0%{?fedora}

[Bug 1528636] Upgrade perl-Task-Weaken to 1.05

https://bugzilla.redhat.com/show_bug.cgi?id=1528636 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED

[Bug 1532524] perl-Data-Dumper-2.161-3.fc26 breaks perl-Catalyst-Runtime tests

https://bugzilla.redhat.com/show_bug.cgi?id=1532524 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In

[Bug 1532524] perl-Data-Dumper-2.161-3.fc26 breaks perl-Catalyst-Runtime tests

https://bugzilla.redhat.com/show_bug.cgi?id=1532524 --- Comment #3 from Fedora Update System --- perl-Data-Dumper-2.161-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c5d739e661 -- You are receiving this

[Bug 1532524] perl-Data-Dumper-2.161-3.fc26 breaks perl-Catalyst-Runtime tests

https://bugzilla.redhat.com/show_bug.cgi?id=1532524 --- Comment #2 from Fedora Update System --- perl-Data-Dumper-2.167-398.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-79f6b5c5fc -- You are receiving this

[Bug 1533513] New: perl-Mail-Box-3.003-2.fc28 FTBFS: Failed test at t/ 501parser-head.t line 47

https://bugzilla.redhat.com/show_bug.cgi?id=1533513 Bug ID: 1533513 Summary: perl-Mail-Box-3.003-2.fc28 FTBFS: Failed test at t/501parser-head.t line 47 Product: Fedora Version: rawhide Component: perl-Mail-Box

[EPEL-devel] Re: Meeting Agenda for 2017-01-03

On 01/03/2018 11:17 AM, Stephen John Smoogen wrote: > 1. Peter Robinson's DTS enablement request > A. What packages require it (chromium etc) > B. Is there a version in CentOS? >i. If not is it possible for it to exist in CentOS? > ii. If not what work would a CentOS version take and how

[EPEL-devel] Fedora EPEL 7 updates-testing report

The following Fedora EPEL 7 Security updates need testing: Age URL 1039 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 dokuwiki-0-0.24.20140929c.el7 801 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f mcollective-2.8.4-1.el7 384

[Bug 1511243] perl-Mail-Message-3.005 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1511243 Petr Pisar changed: What|Removed |Added See Also|

[Bug 1533513] perl-Mail-Box-3.003-2.fc28 FTBFS: Failed test at t/ 501parser-head.t line 47

https://bugzilla.redhat.com/show_bug.cgi?id=1533513 Petr Pisar changed: What|Removed |Added See Also|

[Bug 1533513] perl-Mail-Box-3.003-2.fc28 FTBFS: Failed test at t/ 501parser-head.t line 47

https://bugzilla.redhat.com/show_bug.cgi?id=1533513 Tom "spot" Callaway changed: What|Removed |Added Status|ASSIGNED|CLOSED

[Bug 1511243] perl-Mail-Message-3.005 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1511243 --- Comment #11 from Fedora Update System --- perl-Mail-Box-3.004-1.fc27 perl-Mail-Message-3.005-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d4b2798525

[Bug 1533513] perl-Mail-Box-3.003-2.fc28 FTBFS: Failed test at t/ 501parser-head.t line 47

https://bugzilla.redhat.com/show_bug.cgi?id=1533513 --- Comment #4 from Fedora Update System --- perl-Mail-Box-3.004-1.fc27 perl-Mail-Message-3.005-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d4b2798525 --

[Bug 1533513] perl-Mail-Box-3.003-2.fc28 FTBFS: Failed test at t/ 501parser-head.t line 47

https://bugzilla.redhat.com/show_bug.cgi?id=1533513 --- Comment #3 from Fedora Update System --- perl-Mail-Box-3.004-1.fc27 perl-Mail-Message-3.005-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d4b2798525 --

[Bug 1533513] perl-Mail-Box-3.003-2.fc28 FTBFS: Failed test at t/ 501parser-head.t line 47

https://bugzilla.redhat.com/show_bug.cgi?id=1533513 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED

[389-devel] Re: Improve the demo objects from install

> Hi all, > > It's time that I'm looking at: > https://pagure.io/389-ds-base/issue/49425 > > There are some great reasons to freshen up the default objects we > install. The current design isn't really reflective of modern directory > usage, the aci's are not "great" examples, and it's not a

[Bug 1532524] perl-Data-Dumper-2.161-3.fc26 breaks perl-Catalyst-Runtime tests

https://bugzilla.redhat.com/show_bug.cgi?id=1532524 --- Comment #5 from Fedora Update System --- perl-Data-Dumper-2.161-4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1532524] perl-Data-Dumper-2.161-3.fc26 breaks perl-Catalyst-Runtime tests

https://bugzilla.redhat.com/show_bug.cgi?id=1532524 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA

[EPEL-devel] Fedora EPEL 6 updates-testing report

The following Fedora EPEL 6 Security updates need testing: Age URL 912 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168 rubygem-crack-0.3.2-2.el6 802 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb mcollective-2.8.4-1.el6 774

[389-devel] please review: Ticket 49529 - Fix coverity warnings: invalid dereferences

https://pagure.io/389-ds-base/issue/49529 https://pagure.io/389-ds-base/issue/raw/files/60c50df29914ff67f8d99b1ac717941c6913bb069a6552cf7318f4c49877881d-0001-Ticket-49529-Fix-Coverity-warnings-invalid-deference.patch ___ 389-devel mailing list --

[Bug 1533691] New: perl-Time-HiRes-1.9753 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1533691 Bug ID: 1533691 Summary: perl-Time-HiRes-1.9753 is available Product: Fedora Version: rawhide Component: perl-Time-HiRes Keywords: FutureFeature, Triaged Assignee:

[389-devel] Please review: Improve demo objects for 1.4.0

https://pagure.io/389-ds-base/issue/49425 https://pagure.io/389-ds-base/issue/raw/files/9cb1510fb39a94a62af4a7dbc 8a3f14caea0c10f94e4b13bf51e98f0376f4e5d-0001-Ticket-49425-improve-demo- objects-for-install.patch -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane

[389-devel] Re: Improve the demo objects from install

On Thu, 2018-01-11 at 16:40 +, Brian (bex) Exelbierd wrote: > > Hi all, > > > > It's time that I'm looking at: > > https://pagure.io/389-ds-base/issue/49425 > > > > There are some great reasons to freshen up the default objects we > > install. The current design isn't really reflective of

[Bug 1528482] perl-Mock-Sub-1.08 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1528482 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Mock-Sub-1.08-1.fc27

[Bug 1533691] perl-Time-HiRes-1.9753 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1533691 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In

[389-devel] Re: Improve the demo objects from install

Again a wonderful job William. I always feel proud to work with you and This change surely deserves outstanding support. I am thinking, we can publicize this by doing articles on Fedora Magazine and Commblog. Also, we should be mentioning about this change in one of our diversity presentations to

[Bug 1533691] perl-Time-HiRes-1.9753 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1533691 --- Comment #2 from Fedora Update System --- perl-Time-HiRes-1.9753-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3e0e85d656 -- You are receiving this

[Bug 1533691] perl-Time-HiRes-1.9753 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1533691 --- Comment #3 from Fedora Update System --- perl-Time-HiRes-1.9753-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c8bf5ed3c0 -- You are receiving this

[Bug 1531332] perl-Time-HiRes-1.9752 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1531332 --- Comment #6 from Fedora Update System --- perl-Time-HiRes-1.9753-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c8bf5ed3c0 -- You are receiving this

[Bug 1528842] perl-Time-HiRes-1.9750 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1528842 --- Comment #10 from Fedora Update System --- perl-Time-HiRes-1.9753-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c8bf5ed3c0 -- You are receiving this

[Bug 1530928] perl-Time-HiRes-1.9751 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1530928 --- Comment #6 from Fedora Update System --- perl-Time-HiRes-1.9753-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c8bf5ed3c0 -- You are receiving this