https://bugzilla.redhat.com/show_bug.cgi?id=1612860
Petr Pisar changed:
What|Removed |Added
External Bug ID||CPAN 127685
Version|29
OLD: Fedora-Rawhide-20181117.n.0
NEW: Fedora-Rawhide-20181118.n.0
= SUMMARY =
Added images:4
Dropped images: 0
Added packages: 5
Dropped packages:0
Upgraded packages: 66
Downgraded packages: 0
Size of added packages: 1.67 MiB
Size of dropped packages:0 B
On Mon, Nov 19, 2018 at 6:43 AM Kevin Kofler wrote:
> If you follow exactly this procedure, the set of "the multilib packages
> installed before" will be empty and you will not reproduce the issue at
> hand. Multilib cruft has not been installed by default for years now! (And
> that is a good
Frantisek Zatloukal wrote:
>Install Fedora n-1
>Upgrade to Fedora n (updates-testing disabled)
>Enable updates-testing
>Update to latest packages
>Verify that upgrade and update went fine and that the multilib packages
>installed before are still present
If you follow
The following Fedora EPEL 7 Security updates need testing:
Age URL
162 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a
unrtf-0.21.9-8.el7
113 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a
bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7
Alain Vigne wrote:
> Agree, once the .spec file is opened, it is obvious.
>
> But the list such as :
> https://fedoraproject.org/PackageReviewStatus/NEW.html
> doesn't give you easy access to the info: you have to open the BZ, then
> look for the file (if you are lucky). Worst case is when .spec
https://fedorapeople.org/groups/389ds/ci/nightly/2018/11/19/report-389-ds-base-1.4.0.16-1.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code
On lundi 12 novembre 2018 18:10:47 CET Daiki Ueno wrote:
> Tom Hughes writes:
>
>
> > If it's going to one source rpm producing the same three binary
> > rpms then you are indeed correct.
>
>
> Thank you for the suggestions. Then I will go ahead and retire nss-util
> and nss-softokn source
On Sun, 2018-11-18 at 21:48 +0100, Frantisek Zatloukal wrote:
> We have encountered a bug[0] which seemingly “broke” offline updates after
> systems were upgraded from an older Fedora to Fedora 29 and had some
> multilib packages installed. After the discussion at last week's Release
>
Il giorno ven, 16/11/2018 alle 18.26 +0100, Dario Lesca ha scritto:
> I have fill this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1650289 in which there
> are some useful logs files
>
> If someone have some suggest to resolve this issue without modify the
> .service file of this service
On Sun, 18 Nov 2018 17:19:37 -0500, you wrote:
>But I don't think we should extend the lifecycle on a general basis.
>That's asking for trouble, since it cedes our leadership in the Linux
>platform and destroys our ability to meet our own values.
What leadership would Fedora be ceding by
On Sun, Nov 18, 2018 at 5:30 PM Reindl Harald wrote:
>
> Am 18.11.18 um 23:19 schrieb Neal Gompa:
> > I think it's quite obvious why. No one can really influence what's in
> > CentOS. Red Hat Enterprise Linux itself is developed mostly behind
> > closed doors, after forking a Fedora release.
>
>
On Sun, Nov 18, 2018 at 5:08 PM Orion Poplawski wrote:
>
> On 11/18/18 2:29 PM, Richard W.M. Jones wrote:
> > I'm not for or against a longer Fedora lifecycle, but I think we need
> > a stronger statement of what the problem is we're trying to address.
> >
> > From your email:
> >
> > On Tue,
On 18-11-18 16:29:45, Richard W.M. Jones wrote:
I'm not for or against a longer Fedora lifecycle, but I think we need
a stronger statement of what the problem is we're trying to address.
From your email:
On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:
> But there are some good
On 11/18/18 2:29 PM, Richard W.M. Jones wrote:
I'm not for or against a longer Fedora lifecycle, but I think we need
a stronger statement of what the problem is we're trying to address.
From your email:
On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:
But there are some good
I'm not for or against a longer Fedora lifecycle, but I think we need
a stronger statement of what the problem is we're trying to address.
From your email:
On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:
> But there are some good cases for a longer lifecycle. For one thing,
>
We have encountered a bug[0] which seemingly “broke” offline updates after
systems were upgraded from an older Fedora to Fedora 29 and had some
multilib packages installed. After the discussion at last week's Release
Retrospective meeting, I am proposing some changes to our blocking
criterions in
On 18. 11. 18 19:37, Kevin Fenzi wrote:
On 11/16/18 10:22 AM, Miro Hrončok wrote:
When Fedora 29 was released, the Python Classroom Lab wasn't built.
The problem is now fixed:
https://koji.fedoraproject.org/koji/packageinfo?packageID=23847
However how do i build and release it, so it is
> Being a volunteer doesn't mean to not have any responsibility.
It's grossly unfair to insinuate that being a volunteer is associated with
laziness or a lack of responsibility.
There are a myriad of things that we as packagers do that are completely silent
to the surrounding automation and for
On 11/18/18 1:44 AM, Mattia Verga wrote:
> Il 11/17/18 10:59 PM, Philip Kovacs ha scritto:
>
>> You want to attract packagers, not irritate them.
>
> In my opinion, "irritating" is when a maintainer doesn't reply to bugs that
> users fill in Bugzilla. If they can't found enough time to reply
On 11/17/18 4:09 PM, Orion Poplawski wrote:
> I'm afraid I'm still very unfamiliar with modules, but it does seem like
> this will be very central to how we deliver packages to EPEL-8. My
> initial questions are:
Yeah, I don't know them as well as I can, but can take a stab at
answering based
On 11/16/18 4:07 PM, Stephen John Smoogen wrote:
> On Fri, 16 Nov 2018 at 18:39, Orion Poplawski wrote:
>>
>> What's the plan with epel8 branching? I was fairly happy with needing to
>> request branches manually like with did with epel7. Are we going to use the
>> "epel8" name?
>
> That is the
On 11/16/18 10:22 AM, Miro Hrončok wrote:
> When Fedora 29 was released, the Python Classroom Lab wasn't built.
>
> The problem is now fixed:
>
> https://koji.fedoraproject.org/koji/packageinfo?packageID=23847
>
> However how do i build and release it, so it is listed on:
>
>
On Sun, 18 Nov 2018 at 12:49, Neal Gompa wrote:
>
> On Sun, Nov 18, 2018 at 11:54 AM Jonathan Dieter wrote:
> >
> > On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
> > > Jonathan Dieter wrote:
> > > > My proposal would be to make zchunk the rpm compression format for
> > > > Fedora.
> > >
On Sun, Nov 18, 2018, 18:15 Alain Vigne Agree, once the .spec file is opened, it is obvious.
>
> But the list such as :
> https://fedoraproject.org/PackageReviewStatus/NEW.html
> doesn't give you easy access to the info: you have to open the BZ, then
> look for the file (if you are lucky). Worst
On Sun, Nov 18, 2018 at 11:54 AM Jonathan Dieter wrote:
>
> On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
> > Jonathan Dieter wrote:
> > > My proposal would be to make zchunk the rpm compression format for
> > > Fedora.
> >
> > Given that:
> > 1. zchunk is based on zstd, which is
Agree, once the .spec file is opened, it is obvious.
But the list such as :
https://fedoraproject.org/PackageReviewStatus/NEW.html
doesn't give you easy access to the info: you have to open the BZ, then
look for the file (if you are lucky). Worst case is when .spec file needs
to be extracted
On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
> Jonathan Dieter wrote:
> > My proposal would be to make zchunk the rpm compression format for
> > Fedora.
>
> Given that:
> 1. zchunk is based on zstd, which is typically less efficient in terms of
>compression ratio than xz, depending
Alain Vigne wrote:
> As a new packager, I understand peer-reviewing packages is very important,
> but it takes me (a lot of) time, and I do not have the necessary skills to
> review any kind of packages (Go, Python, Rust, Java, Javascript, Ruby, ...
> you name it)
>
> That is why I can offer to
As a new packager, I understand peer-reviewing packages is very important,
but it takes me (a lot of) time, and I do not have the necessary skills to
review any kind of packages (Go, Python, Rust, Java, Javascript, Ruby, ...
you name it)
That is why I can offer to review packages of C libs, apps,
https://bugzilla.redhat.com/show_bug.cgi?id=1650041
--- Comment #5 from wyonen ---
Thanks again for the analysis and both workarounds!
--
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list --
On Sat, Nov 17, 2018 at 11:47 AM Mattia Verga
wrote:
>
>
> - after three emails without response, orphan their packages and inform
> devel list
>
I'm not sure I'm in favor of automatically orphaning packages. I think it
could "tell" of them to the devel list that way anyone who knows them can
Il 11/17/18 10:59 PM, Philip Kovacs ha scritto:
> You want to attract packagers, not irritate them.
In my opinion, "irritating" is when a maintainer doesn't reply to bugs that
users fill in Bugzilla. If they can't found enough time to reply or change
state of any bug in a six months period,
I'm hoping the Fedora LTS idea will die as quickly as it started.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Hello,
On Sat, 2018-11-17 at 08:10 +, Leigh Scott wrote:
> > On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller
> > >
> > "Canonical Extends Ubuntu 18.04 LTS Linux Support to 10 Years"
> >
> > https://www.serverwatch.com/server-news/canonical-extends-ubuntu-18.04-lt...
> >
> > I just don't
35 matches
Mail list logo
