Fabio Valentini wrote:
>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 - especially for non-leaf
>packages. I don't think fedora as a project has a solution for this
>yet.
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't see
> why we are
The following Fedora EPEL 7 Security updates need testing:
Age URL
199 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a
bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7
182 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d
https://bugzilla.redhat.com/show_bug.cgi?id=1672082
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Inline-0.81-1.fc30 |perl-Inline-0.81-1.fc30
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 tomorrow if not.
- Orion
--
Orion Poplawski
Manager of NWRA
No missing expected images.
Compose FAILS proposed Rawhide gating check!
5 of 47 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
Failed
https://bugzilla.redhat.com/show_bug.cgi?id=1672082
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
Hi,
Georg Sauthoff writes:
[...]
> Yes, I'm asserting this and I already asserted it in my original mail.
Sorry about that, it was a bug in the pcp spec file and how we were
handling pmcd/pmlogger's configuration. Thanks for catching it! I've
submitted a fedora update to fix this and disable
I'm building plplot 5.14.0 for rawhide. This involves a soname bump.
I'll be rebuilding the dependent packages when it's complete:
gdl
psfex
scamp
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell
On 2/12/19 1:02 AM, Jakub Jelinek wrote:
On Mon, Feb 11, 2019 at 07:17:25PM -0700, Orion Poplawski wrote:
Looks like GCC 9 is finally enforcing an OpenMP change:
From https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00628.html
Please see https://gcc.gnu.org/gcc-9/porting_to.html#ompdatasharing
https://bugzilla.redhat.com/show_bug.cgi?id=1676716
Bug ID: 1676716
Summary: perl-Class-Field-0.24 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Class-Field
Keywords: FutureFeature, Triaged
On Monday, 11 February 2019 at 18:12, Paolo Bonzini wrote:
> On 11/02/19 17:57, 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,
Am Dienstag, den 12.02.2019, 16:40 -0500 schrieb Jason Taylor:
>
>
> On Tue, Feb 12, 2019, 16:35 Björn 'besser82' Esser <
> besse...@fedoraproject.org> wrote:
> > > This log has "-mtune=option: not valid". I guess something has
> > changed
> > > here with gcc 9 that the cmake script doesn't
On Tue, Feb 12, 2019, 16:35 Björn 'besser82' Esser <
besse...@fedoraproject.org> wrote:
> > This log has "-mtune=option: not valid". I guess something has changed
> > here with gcc 9 that the cmake script doesn't like?
>
>
> I've tailored a patch for CMakeLists.txt to fix the build [1]. If you
>
On Tue, Feb 12, 2019 at 2:34 PM Chris Murphy wrote:
>
> If grubenv can be change from pre-boot environment, we can't correctly
> determine if boot has succeeded or failed.
s/can/can't
s/change/changed
(grubenv can't be changed in certain custom partitioning cases e.g.
/boot on Btrfs or /boot
On Tue, Feb 12, 2019 at 2:18 PM Chris Murphy wrote:
>
> In the short term it means any features depending on writing to grubenv from
> pre-boot GRUB (as opposed to Linux user space GRUB tools), can only be
> expected on UEFI (grubenv is always on FAT), or if on BIOS only with default
>
> This log has "-mtune=option: not valid". I guess something has changed
> here with gcc 9 that the cmake script doesn't like?
I've tailored a patch for CMakeLists.txt to fix the build [1]. If you
agree, I'll push to SCM (including update to v5.1.0) and build it.
Björn
[1]
12.02.2019, 21:16, "jt" :
> On Tue, 2019-02-12 at 16:13 -0500, jt wrote:
>> On Tue, 2019-02-12 at 21:06 +, Pete Walter wrote:
>> > Looking at the build log, it seems to be checking for 'libpcre =
>> > 8.41', but the build root has 8.43-RC1 which causes the build to
>> > error out.
>> >
>>
12.02.2019, 21:16, "jt" :
> On Tue, 2019-02-12 at 16:13 -0500, jt wrote:
>> On Tue, 2019-02-12 at 21:06 +, Pete Walter wrote:
>> > Looking at the build log, it seems to be checking for 'libpcre =
>> > 8.41', but the build root has 8.43-RC1 which causes the build to
>> > error out.
>> >
>>
On Tue, Feb 12, 2019, 7:10 AM Javier Martinez Canillas
> I see, I would had thought that the advice would had been to use
> grub-editenv create instead. But still grub2-editenv create will only
> prevent removing the symlink, it won't help with the issue of the
> kernelopts variable not being
On Tue, 2019-02-12 at 16:13 -0500, jt wrote:
> On Tue, 2019-02-12 at 21:06 +, Pete Walter wrote:
> > Looking at the build log, it seems to be checking for 'libpcre =
> > 8.41', but the build root has 8.43-RC1 which causes the build to
> > error out.
> >
> > Pete
> >
> > 12.02.2019, 20:43,
On Tue, 2019-02-12 at 21:06 +, Pete Walter wrote:
> Looking at the build log, it seems to be checking for 'libpcre =
> 8.41', but the build root has 8.43-RC1 which causes the build to
> error out.
>
> Pete
>
> 12.02.2019, 20:43, "jt" :
> > Hi All,
> >
> > I am looking at the FTBFS for
Looking at the build log, it seems to be checking for 'libpcre = 8.41', but the
build root has 8.43-RC1 which causes the build to error out.
Pete
12.02.2019, 20:43, "jt" :
> Hi All,
>
> I am looking at the FTBFS for hyperscan[0] and need some assistance.
> From what I can tell it looks like
On 12/02/2019 20:42, jt wrote:
I am looking at the FTBFS for hyperscan[0] and need some assistance.
From what I can tell it looks like this may be related to the --as-
needed linker change.
Why do you think that? The koji log shows that it is failing
because it is asking for pcre 8.41 and
‐‐‐ Original Message ‐‐‐
On Tuesday, February 12, 2019 2:42 PM, jt wrote:
> Hi All,
>
> I am looking at the FTBFS for hyperscan[0] and need some assistance.
> From what I can tell it looks like this may be related to the --as-
> needed linker change.
>
> The reason I say it may be
Hi,
Am 12.02.19 um 18:35 schrieb Ken Dreyer:
> Could someone please help me understand why we have python-cherrypy
> and python3-cherrypy as two separate Fedora packages?
That reason is recorded in the review request for python3-cherrypy:
"Upstream are releasing separate tarballs for Python 2
Hi All,
I am looking at the FTBFS for hyperscan[0] and need some assistance.
From what I can tell it looks like this may be related to the --as-
needed linker change.
The reason I say it may be related to the linking change is I can build
the 5.1.0 release against the fedora-29-x86_64 mock
Hi all,
a new version fedpkg-1.36 is released.
This is mostly a bugfix update with some improvements. Most notable changes
are:
support for flatpack namespace (flatpaks will be added as a separate
namespace in Fedora dist-git)
fedpkg update will work for containers
Other changes,
I no longer use python-rdflib, and I don't have the time to maintain
it, so I've marked it as orphaned.
Dave
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
According to the Fedora 30 schedule[1], the deadline for Changes to be
code complete (i.e. testable enough for beta) is Tuesday 19 February.
At this time, all Changes should be testable and tracker bugs should
be set to the MODIFIED state. For more information on this deadline,
see the wiki[2].
According to the Fedora 30 schedule[1], the deadline for Changes to be
code complete (i.e. testable enough for beta) is Tuesday 19 February.
At this time, all Changes should be testable and tracker bugs should
be set to the MODIFIED state. For more information on this deadline,
see the wiki[2].
Dear all,
You are kindly invited to the meeting:
EPEL Steering Co on 2019-02-13 from 18:00:00 to 19:00:00 GMT
At freenode@fedora-meeting
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. Agenda is in the
Hi python packagers,
Could someone please help me understand why we have python-cherrypy
and python3-cherrypy as two separate Fedora packages?
https://src.fedoraproject.org/rpms/python-cherrypy
https://src.fedoraproject.org/rpms/python3-cherrypy
It seems to me that "python3-cherrypy" should be
https://bugzilla.redhat.com/show_bug.cgi?id=1675620
Petr Pisar changed:
What|Removed |Added
CC||ppi...@redhat.com
Fixed In Version|
Anderson, Charles R wrote:
> On Mon, Feb 04, 2019 at 03:48:59PM -0500, Mohan Boddu wrote:
>> Per the Fedora 30 schedule[1] we started a mass rebuild for Fedora 30
>> on Jan 31st 2019. We did a mass rebuild for Fedora 30 for the changes
>> listed in:
>>
>> https://pagure.io/releng/issue/8086
>>
On Tue, 2019-02-12 at 15:52 +0100, Florian Weimer wrote:
> * Marcel Plch:
>
> > So rather than:
> > "Python extension modules don't need to be linked against libc as
> > they
> > are never actually loaded on their own, but rather from the Python
> > interpreter,"
> > we can say:
> > "Some Python
* Marcel Plch:
> So rather than:
> "Python extension modules don't need to be linked against libc as they
> are never actually loaded on their own, but rather from the Python
> interpreter,"
> we can say:
> "Some Python extension modules don't need to be linked against glibc
> under such
On Tue, 2019-02-12 at 15:35 +0100, Florian Weimer wrote:
> * Marcel Plch:
>
> > On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote
> > > If you take the address of a local variable and pass the
> > > resulting
> > > pointer to another function, the compiler will generate a call to
> > >
* Marcel Plch:
> On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote
>> If you take the address of a local variable and pass the resulting
>> pointer to another function, the compiler will generate a call to
>> __stack_chk_fail, which lives in glibc. At build time, linking
>> against
>>
On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote
> If you take the address of a local variable and pass the resulting
> pointer to another function, the compiler will generate a call to
> __stack_chk_fail, which lives in glibc. At build time, linking
> against
> glibc is required so that
On 12/02/2019 14:10, Javier Martinez Canillas wrote:
I see, I would had thought that the advice would had been to use
grub-editenv create instead. But still grub2-editenv create will only
prevent removing the symlink, it won't help with the issue of the
kernelopts variable not being set.
We
Hi,
comments are in the text:
On 2/11/19 9:17 PM, Stephen Gallagher wrote:
> On Mon, Feb 11, 2019 at 2:24 PM Chris Murphy wrote:
>> On Mon, Feb 11, 2019 at 9:58 AM Stephen Gallagher
>> wrote:
>>> Sorry that it's taken me so long to get back to this.
>>>
>>> I think the feedback on this has
Hello Nicolas,
On Tue, Feb 12, 2019 at 2:58 PM Nicolas Mailhot
wrote:
>
> Le 2019-02-12 13:32, Javier Martinez Canillas a écrit :
> Hi Javier
>
> > I didn't get how it will break the symlink.
>
> You get a "environment block too small" on kernel update
>
> You type "environment block too small"
Le 2019-02-12 13:32, Javier Martinez Canillas a écrit :
Hi Javier
I didn't get how it will break the symlink.
You get a "environment block too small" on kernel update
You type "environment block too small" in google because you want the
update to work
You get some ubuntu advice that says
https://bugzilla.redhat.com/show_bug.cgi?id=1675652
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675651
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
The Fedora Python team has been working on getting a test rebuild of
Python for moving epel-7 to python36 [Thank you very much for this
work.]
https://copr.fedorainfracloud.org/coprs/g/python/epel-python3/monitor/
Out of 282 packages which are compiled with python34, only 35 have
failed to build
https://bugzilla.redhat.com/show_bug.cgi?id=1675650
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675649
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675648
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675647
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675646
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675642
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675641
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
On Mon, Feb 11, 2019 at 8:53 PM Chris Murphy wrote:
>
> On Mon, Feb 11, 2019 at 5:40 AM Nicolas Mailhot
> wrote:
> >
[snip]
> >
> > FYI I had to rescue two EFI rawhide system this week-end borked by grub
> > changes. As far as I could reconstruct:
> >
> > 1. the new grub needs the env file to
https://bugzilla.redhat.com/show_bug.cgi?id=1669119
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1670203
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
Hello Nicolas,
On Mon, Feb 11, 2019 at 1:41 PM Nicolas Mailhot
wrote:
>
> Le 2019-02-10 20:05, Chris Murphy a écrit :
> > On Wed, Feb 6, 2019 at 1:08 AM Javier Martinez Canillas
>
> > Between this feature for F30, and the F29 feature to hide the grub
> > menu which comes with boot success+fail
https://bugzilla.redhat.com/show_bug.cgi?id=1669119
Petr Pisar changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://bugzilla.redhat.com/show_bug.cgi?id=1670203
Petr Pisar changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675639
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675636
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675635
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675640
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1669119
Petr Pisar changed:
What|Removed |Added
Blocks||1674516
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675632
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
Le 2019-02-12 11:43, Adam Samalik a écrit :
I might be missing something here, so excuse me if that's obvious, but
wouldn't this happen without Modularity anyway? I mean, how does
Modularity relate to packages being orphaned? Or is that because they
have been moved out into modules and their
https://bugzilla.redhat.com/show_bug.cgi?id=1675628
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
Hello Chris,
Sorry for the late response but I was on vacation last week.
On Sun, Feb 10, 2019 at 8:06 PM Chris Murphy wrote:
>
> On Wed, Feb 6, 2019 at 1:08 AM Javier Martinez Canillas
> wrote:
> >
> > On Wed, Feb 6, 2019 at 5:28 AM Chris Murphy wrote:
> > >
> > >
https://bugzilla.redhat.com/show_bug.cgi?id=1675630
Daniel Berrange changed:
What|Removed |Added
Depends On|1676474 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1627117
Daniel Berrange changed:
What|Removed |Added
Depends On||1676474
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1675630
Daniel Berrange changed:
What|Removed |Added
Depends On||1676474
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1664038
Petr Pisar changed:
What|Removed |Added
External Bug ID||Github
|
https://bugzilla.redhat.com/show_bug.cgi?id=1675627
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Feb 11, 2019 at 09:19:08AM -0500, Neal Becker wrote:
>> I'm proposing to update to mercurial 4.9 for F30.
>
> What is the effect on those dependent packages? How many need
> adjustments?
>
> Zbyszek
tortoisehg for sure won't run until it is updated,
https://bugzilla.redhat.com/show_bug.cgi?id=1664038
Petr Pisar changed:
What|Removed |Added
Blocks||1674516
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675629
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675626
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1675624
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
It won't help because you didn't take the build dependencies of ant/maven…
On Tue, Feb 12, 2019 at 12:51 PM Fabio Valentini
wrote:
> On Tue, Feb 12, 2019 at 12:16 PM Fabio Valentini
> wrote:
> >
> > On Tue, Feb 12, 2019 at 12:08 PM Miro Hrončok
> wrote:
> > >
> > > On 12. 02. 19 11:46, Fabio
https://bugzilla.redhat.com/show_bug.cgi?id=1675623
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
On 12/02/2019 11:46, Mikolaj Izdebski wrote:
On Tue, Feb 12, 2019 at 11:56 AM Tom Hughes wrote:
Java and everything java related (like ant) is now modular only
and has been orphaned in the non-modular rawhide.
That's totally not true. There are about 1.4k source Java packages,
but there are
https://bugzilla.redhat.com/show_bug.cgi?id=1675622
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
On 12/02/19 10:55 +0100, Jakub Jelinek wrote:
On Tue, Feb 12, 2019 at 09:49:23AM +, Jonathan Wakely wrote:
On that basis, why does gcc-c++ install libgomp and libgfortran?
I think gcc-c++ doesn't require libgfortran, gcc-gfortran does.
Ah yes, sorry. I ran 'mock -r fedora-rawhide-x86_64
On Tue, Feb 12, 2019 at 11:56 AM Tom Hughes wrote:
> Java and everything java related (like ant) is now modular only
> and has been orphaned in the non-modular rawhide.
That's totally not true. There are about 1.4k source Java packages,
but there are less that 200 modular Java source packages.
https://bugzilla.redhat.com/show_bug.cgi?id=1675619
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
On Tue, Feb 12, 2019 at 12:16 PM Fabio Valentini wrote:
>
> On Tue, Feb 12, 2019 at 12:08 PM Miro Hrončok wrote:
> >
> > On 12. 02. 19 11:46, Fabio Valentini wrote:
> > >> (I know anyone can unbreak it by claiming the packages, but that's not
> > >> the point
> > >> here.)
> > >
> > > Miro, am
https://bugzilla.redhat.com/show_bug.cgi?id=1664030
--- Comment #2 from Petr Pisar ---
Debian provided a fix in the bug report at CPAN.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list --
https://bugzilla.redhat.com/show_bug.cgi?id=1675621
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1664030
Petr Pisar changed:
What|Removed |Added
Blocks||1674516
CC|
On Mon, Feb 11, 2019 at 08:08:38PM -0600, Wart wrote:
> As per
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package
>
> ...I will be taking ownership of the rogue package. I was actually the
> maintainer for this package many years
https://bugzilla.redhat.com/show_bug.cgi?id=1627117
--- Comment #2 from Daniel Berrange ---
Upstream fix is
https://gitlab.gnome.org/GNOME/perl-gtk3/commit/88bc49e7a21da0131b10546aa07ebdf98d18a37e
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1675630
Daniel Berrange changed:
What|Removed |Added
Status|NEW |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=1627117
Daniel Berrange changed:
What|Removed |Added
Blocks||1674516
CC|
On Tue, Feb 12, 2019 at 12:15 PM Fabio Valentini
wrote:
> On Tue, Feb 12, 2019 at 12:09 PM Adam Samalik wrote:
> >
> > The Modularity Team works on enabling default modules to be present in
> the traditional buildroot. The work is tracked here:
>
On Tue, Feb 12, 2019 at 12:08 PM Miro Hrončok wrote:
>
> On 12. 02. 19 11:46, Fabio Valentini wrote:
> >> (I know anyone can unbreak it by claiming the packages, but that's not the
> >> point
> >> here.)
> >
> > Miro, am I reading it correctly that the list below "Orphans (rawhide)
> > (not
On Tue, Feb 12, 2019 at 09:19:03AM +, Peter Robinson wrote:
> On Tue, Feb 12, 2019 at 8:49 AM Jan Pazdziora wrote:
> >
> > All of them failed on armv7hl, with some package (for example
> > glibc-2.29-1.fc30.1.armv7hl.rpm) missing in the mock step.
> >
> > How should maintainers proceed in
On Tue, Feb 12, 2019 at 12:09 PM Adam Samalik wrote:
>
> The Modularity Team works on enabling default modules to be present in the
> traditional buildroot. The work is tracked here:
> https://tree.taiga.io/project/modularity-wg/epic/12
>
> We would love to contributions towards that. I'm
https://bugzilla.redhat.com/show_bug.cgi?id=1675634
Jan Pazdziora changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
On Tue, Feb 12, 2019 at 11:54 AM Tom Hughes wrote:
> On 12/02/2019 10:43, Adam Samalik wrote:
>
> > I might be missing something here, so excuse me if that's obvious, but
> > wouldn't this happen without Modularity anyway? I mean, how does
> > Modularity relate to packages being orphaned? Or is
1 - 100 of 145 matches
Mail list logo
