On Thu, 2019-09-19 at 21:56 -0700, Gordon Messmer wrote:
> On 9/19/19 9:28 PM, Adam Williamson wrote:
> > Please note, I'm not sure if you're aware, but it's certainly not the
> > case that Kevin "contribute[s] nothing in return". He's worked on
> > Fedora packaging, especially around KDE, for many
On 9/19/19 9:28 PM, Adam Williamson wrote:
Please note, I'm not sure if you're aware, but it's certainly not the
case that Kevin "contribute[s] nothing in return". He's worked on
Fedora packaging, especially around KDE, for many years.
I was thinking about users in general, in response to Kevi
On Thu, 2019-09-19 at 20:36 -0700, Gordon Messmer wrote:
> On 9/19/19 7:12 AM, Kevin Kofler wrote:
> > It is absolutely not realistic to expect all end users to become package
> > maintainers.
>
> Sure, isn't it also unrealistic to expect to receive a massive library
> of software and contribute
On 9/19/19 7:12 AM, Kevin Kofler wrote:
It is absolutely not realistic to expect all end users to become package
maintainers.
Sure, isn't it also unrealistic to expect to receive a massive library
of software and contribute nothing in return? Do you have an inherent
right to the product of
Once upon a time, Kevin Kofler said:
> Randy Barlow wrote:
> > It is a disservice to our users to provide them with unmaintained
> > packages,
>
> It is a disservice to our users to NOT provide them with unmaintained
> packages. If, as a user, you NEED a package, you would rather have it
> pres
I'll be updating double-coversion in rawhide soon. This involves a
soname bump, but there are very few deps and I'll be rebuilding those.
I did a test build here:
https://copr.fedorainfracloud.org/coprs/orion/double-conversion/builds/
and found no issues related to the update.
--
Orion Popl
On Thu, Sep 19, 2019 at 2:18 PM Kevin Fenzi wrote:
> On 9/19/19 5:26 AM, Kaleb Keithley wrote:
> > Someone with privs please kick it. Thanks
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953
>
> Done. Do note that you can do this too, just untag it from f32-pending
> and tag
We had Java in Fedora long before modules, but not having a Java module would
certainly be the case in that scenario, and that'd be fine. We've been able to
install multiple different Java versions on the same Fedora install for some
time now, something which is not possible with modules.
On Se
On 19. 09. 19 23:29, Kevin Fenzi wrote:
* Stop rawhide composes until we have a branched compose. This may
not
be needed with the change to make rawhide use 'rawhide' and not the
number, but we should consider it if we don't have a compose to avoid
confusion.
Where should I signed this?:)
But n
That wouldn't work, as the systems do not support 64 bit.
On September 19, 2019 8:59:55 PM UTC, Matthew Miller
wrote:
>On Mon, Sep 16, 2019 at 03:19:38PM -0500, Bruno Wolff III wrote:
>> On Mon, Sep 16, 2019 at 13:15:08 -0700,
>> You can crossgrade using dnf. I wrote about it a few weeks ago. Th
On Thu, 19 Sep 2019 at 16:46, Emmanuel Seyman wrote:
>
> * Kevin Kofler [19/09/2019 16:12] :
> >
> > That could have been prevented by policy, but deliberately was not, because
> > the people behind Modularity had exactly this (moving random packages to
> > module-only) as their hidden agenda.
>
>
Randy Barlow wrote:
> It is a disservice to our users to provide them with unmaintained
> packages,
It is a disservice to our users to NOT provide them with unmaintained
packages. If, as a user, you NEED a package, you would rather have it
present but unmaintained than not have it at all!
On 9/18/19 1:41 AM, jkone...@redhat.com wrote:
> Hi Kevin,
> Thanks for the explanation. See my comments below.
...snip...
>> * Stop rawhide composes until we have a branched compose. This may
>> not
>> be needed with the change to make rawhide use 'rawhide' and not the
>> number, but we should c
On Thu, Sep 19, 2019 at 09:42:04AM -0500, Michael Catanzaro wrote:
> So with help from Rishi, we got it working by:
> * Adding a config file [1] into the container.
> * Poking a hole in the flatpak sandbox [2], though this is clearly a
> nasty hack.
> I think this will do for now, though improvemen
On Mon, Sep 16, 2019 at 03:19:38PM -0500, Bruno Wolff III wrote:
> On Mon, Sep 16, 2019 at 13:15:08 -0700,
> You can crossgrade using dnf. I wrote about it a few weeks ago. The
> process worked pretty smoothly for me.
Maybe worth a Fedora Magazine article (with a "not supported" disclaimer)?
--
No missing expected images.
Failed openQA tests: 6/152 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20190918.n.0):
ID: 454715 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/454715
ID: 454727 Test: x86_64 Silverblue-dvd_ostree
OLD: Fedora-31-20190918.n.0
NEW: Fedora-31-20190919.n.1
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 6
Dropped packages:0
Upgraded packages: 44
Downgraded packages: 0
Size of added packages: 1.70 MiB
Size of dropped packages:0 B
Size of
* Kevin Kofler [19/09/2019 16:12] :
>
> That could have been prevented by policy, but deliberately was not, because
> the people behind Modularity had exactly this (moving random packages to
> module-only) as their hidden agenda.
I'm quite certain that forbidding people to move to module-only wo
On Tue, Sep 17, 2019 at 12:30 PM Kevin Fenzi wrote:
>
> On 9/17/19 8:04 AM, Miro Hrončok wrote:
> > On 17. 09. 19 17:00, jkone...@redhat.com wrote:
> >> If that is not doable what about taking last Rawhide compose and mark
> >> that as first compose of newly branched Fedora? The only thing I'm
> >
On 9/18/19 12:02 AM, Miroslav Suchý wrote:
> Dne 17. 09. 19 v 18:28 Kevin Fenzi napsal(a):
>> Branching is not just "oh, make a new compose". There's a ton of
>> steps/work that happens then, including:
>>
>> * Making a new branch on all active rpms
>> * Switching to a new signing key in rawhide.
>
https://fedoraproject.org/wiki/Changes/Django3
== Summary ==
This change is about upgrading {{package|python-django}} to
[https://docs.djangoproject.com/en/3.0/releases/3.0/ version 3.0]. A
compatibility package is not planned (but it is part of the
contingency plan).
== Owner ==
* Name: [[User:c
* John M. Harris, Jr. [17/09/2019 21:27] :
>
> I can provide a link to the vendor's website when I get home.
I'm interested in this.
Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedor
On 9/19/19 5:26 AM, Kaleb Keithley wrote:
> Someone with privs please kick it. Thanks
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953
Done. Do note that you can do this too, just untag it from f32-pending
and tag it again into f32-pending.
And I am again sorry we don't have t
On 9/19/19 3:27 AM, Dave Love wrote:
> Are the aarch64 test systems running on real or emulated hardware? (Is
> there a way to tell?)
You mean the ones listed at
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
?
If so, they are vm's running on real hardware with kvm
Hello,
I would like to take-over the pefile.
Michal Ambroz
-- Původní e-mail --
Od: Othman Madjoudj
Komu: Development discussions related to Fedora
Datum: 15. 9. 2019 3:11:24
Předmět: Orphaning some packages
"Hello,
I'm going to orphan the following packages, reason is cit
libb2-0.98.1 built
On 09/09/19 20:09, Felix Schwarz wrote:
>
> Would you mind pinging me again when the new package is actually built in
> rawhide?
>
> I will run borg's test suite against the new libb2 then. The test suite is
> pretty comprehensive so this should be a good indicator if we need
On Thu, 19 Sep 2019 at 06:28, Dave Love wrote:
>
> Are the aarch64 test systems running on real or emulated hardware? (Is
> there a way to tell?)
>
> I ask because I'm seeing bad numerical results from a test and would
> like to know if I can eliminate qemu as a possible cause -- not that I
> thi
Thank you guys.
Regards
MT
On Thu, Sep 19, 2019 at 3:36 PM Miro Hrončok wrote:
> On 19. 09. 19 15:12, Dan Čermák wrote:
> > In Fedora 30 there is only Sphinx 1.8.4, so you'll have to patch your
> > package to work with an older version of sphinx.
>
> Or stop building the docs on Fedora 30 and on
> > Do you mean a system to test SRPM on aarch64? or a system to test a
> > open source code?
> > Do you mean CI testing system or an aarch64 server for adhoc test?
>
> I don't know why it matters, but I'm testing dynamic micro-architecture
> selection added to a library I've packaged.
Because the
On Wed, 2019-09-18 at 23:24 +0200, Kevin Kofler wrote:
> And if an otherwise maintained package FTBFS, if it does not actually
> need
> any change, I don't see how this is even an issue at all.
FTBFS packages can get CVEs filed against them and then they can be
difficult to fix. There are a few p
Hello,
The logs from the NeuroFedora team meeting on 19th September are below:
- HTML logs:
https://meetbot.fedoraproject.org/fedora-neuro/2019-09-19/neurofedora.2019-09-19-15.00.log.html
- HTML minutes:
https://meetbot.fedoraproject.org/fedora-neuro/2019-09-19/neurofedora.2019-09-19-15.00.
Jun Aruga writes:
> On Thu, Sep 19, 2019 at 12:28 PM Dave Love
> wrote:
>>
>> Are the aarch64 test systems running on real or emulated hardware? (Is
>> there a way to tell?)
>>
>> I ask because I'm seeing bad numerical results from a test and would
>> like to know if I can eliminate qemu as a
Hello,
I would like to claim python-volatility and python-impacket,.
Michal Ambroz
-- Původní e-mail --
Od: Miro Hrončok
Komu: Development discussions related to Fedora , devel-annou...@lists.fedoraproject.org
Datum: 16. 9. 2019 12:01:28
Předmět: Orphaned packages looking for
So with help from Rishi, we got it working by:
* Adding a config file [1] into the container.
* Poking a hole in the flatpak sandbox [2], though this is clearly a
nasty hack.
I think this will do for now, though improvements would be good
[1]
https://gitlab.gnome.org/GNOME/gnome-build-m
Neal Gompa wrote:
> This is true for building locally for i686. You cannot do 32-bit
> development with multilib x86_64 content.
Yes, that is my point. Well, actually, you can do some amount of 32-bit
development with multilib -devel packages, but mock RPM builds require a
complete 32-bit chroot
On 19. 09. 19 15:12, Dan Čermák wrote:
In Fedora 30 there is only Sphinx 1.8.4, so you'll have to patch your
package to work with an older version of sphinx.
Or stop building the docs on Fedora 30 and only build it on Fedora 31+.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
__
On Wed, Sep 18, 2019 at 5:25 PM Kevin Kofler wrote:
>
> Zbigniew Jędrzejewski-Szmek wrote:
> > So... building multilib packages is still very much supported. You cannot
> > *run* a pure-i686 environment, but you can 32 bit development.
>
> You have to configure a slow, non-mirrored repository for
Hi Marek,
Marek Tamaskovic writes:
> Hi,
> I'm maintainer of libcbor package and in fedora 30 has been removed
> python3-sphinx package which is required to build documentation for
> libcbor. I can changa the dependency to python2-sphinx but thats not what I
> really want to do. Another option
python3-sphinx not removed.
Look at
https://koji.fedoraproject.org/koji/packageinfo?packageID=6297
чт, 19 сент. 2019 г. в 16:03, Marek Tamaskovic :
>
> Hi,
> I'm maintainer of libcbor package and in fedora 30 has been removed
> python3-sphinx package which is required to build documentation for l
Hi,
I'm maintainer of libcbor package and in fedora 30 has been removed
python3-sphinx package which is required to build documentation for
libcbor. I can changa the dependency to python2-sphinx but thats not what I
really want to do. Another option is to install sphinx via pip3. However in
build
On 9/19/19 8:25 AM, Nico Kadel-Garcia wrote:
> On Thu, Sep 19, 2019 at 8:11 AM Kalpa Welivitigoda
> wrote:
>> Hi all,
>>
>> Given a kickstart file (flatten) and we intend to make an iso using
>> it, is there a tool or service by which we can estimate the size of
>> the final iso (based on the pac
> I'd suggest that the Modularity team could preapre a list of example
> use cases that will present the strenghts of the modularity.
I just share below my project for me to investigate use cases to
switch a modules stream with Fedora (and RHEL) container and Travis
CI.
It's not general module exa
On 9/18/19 17:41, Petr Pisar wrote:
On 2019-09-18, Kalev Lember wrote:
Hm, did perl get moved to the modular repo? That sounds like it is going
to cause more issues than solve as it's not a leaf package. Why can't it
stay as a regular package?
Perl is still a regular package and until Fedora
> When MySQL 8 is being developed and being packages as module, do you
> build the module for Rawhide only or for all Fedoras?
>
> If you build it for all Fedoras, how do you deal with incompatible
> changes during the MySQL 8 developement. I'm hitting on the Fedora
> Updates Policy that forbids in
On Thu, Sep 19, 2019 at 12:28 PM Dave Love wrote:
>
> Are the aarch64 test systems running on real or emulated hardware? (Is
> there a way to tell?)
>
> I ask because I'm seeing bad numerical results from a test and would
> like to know if I can eliminate qemu as a possible cause -- not that I
>
On 2019-09-19, Michal Schorm wrote:
> While the new major version of the database is being developed, I'd
> love to pack it in Fedora, test it, offer it to the users and provide
> feedback to the upstream, solving the uprising issues with them way
> before the GA.
> Because I want to keep a stable
Someone with privs please kick it. Thanks
https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
On Thu, Sep 19, 2019 at 8:11 AM Kalpa Welivitigoda wrote:
>
> Hi all,
>
> Given a kickstart file (flatten) and we intend to make an iso using
> it, is there a tool or service by which we can estimate the size of
> the final iso (based on the packages defined in the kickstart file)
> before actuall
Hi all,
Given a kickstart file (flatten) and we intend to make an iso using
it, is there a tool or service by which we can estimate the size of
the final iso (based on the packages defined in the kickstart file)
before actually creating the iso?
--
Best Regards,
Kalpa Welivitigoda
http://about.
I'd suggest that the Modularity team could preapre a list of example
use cases that will present the strenghts of the modularity.
I believe, there are currently many examples of packages that took a
path to become only modular and it always created more issues than it
solved.
Let's focus on a simpl
OLD: Fedora-Rawhide-20190918.n.2
NEW: Fedora-Rawhide-20190919.n.0
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 2
Dropped packages:6
Upgraded packages: 68
Downgraded packages: 0
Size of added packages: 1.65 MiB
Size of dropped packages
No missing expected images.
Compose FAILS proposed Rawhide gating check!
4 of 45 required tests failed, 6 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.Wor
Are the aarch64 test systems running on real or emulated hardware? (Is
there a way to tell?)
I ask because I'm seeing bad numerical results from a test and would
like to know if I can eliminate qemu as a possible cause -- not that I
think that's likely.
___
On 18. 09. 19 20:37, Andrew Lutomirski wrote:
I guess that Fedora policy says that I should *not* retire it in stable
branches, so I'll leave it alone there unless someone tells me otherwise.
That is correct, we actually cannot remove a package from an already released
fedora.
You can retire
Hello.
I'm going to orphan python-cassandra-driver. I have zero personal
interest in this package and also comaintainers don't care. Moreover,
cassandra itself is orphaned so it doesn't make sense to keep this
package in Fedora.
Have a nice day.
Lumír
___
55 matches
Mail list logo
