On Fri, 2019-03-15 at 22:27 +, Tomasz Kłoczko wrote:
> On Fri, 15 Mar 2019 at 21:32, Ben Cotton wrote:
> > The Fedora 30 Beta Go/No-Go meeting is next week:
> > https://apps.fedoraproject.org/calendar/Fedora%20release/2019/3/21/#m9491
>
> Still mdadm is not even compiling on current fc30.
> S
On Fri, 15 Mar 2019 23:48:49 +0100, you wrote:
>* Richard W.M. Jones [15/03/2019 20:23] :
>> Is Java being dropped from the distro?
>
>Yes, that's what we were warned about months ago.
Don't think so.
Nothing has been said about dropping Java, and if anything the OpenJDK
packagers have been mor
* Richard W.M. Jones [15/03/2019 20:23] :
>
> These are very important packages. What do we have to do here?
I'm going to repeat this until it sinks in...
If you (this is the generic you, not you specifically) want these
packages to be in the distribution, you need to step up and ask for
maintai
On Fri, 15 Mar 2019 at 21:32, Ben Cotton wrote:
> The Fedora 30 Beta Go/No-Go meeting is next week:
> https://apps.fedoraproject.org/calendar/Fedora%20release/2019/3/21/#m9491
Still mdadm is not even compiling on current fc30.
So no one cares that upcoming fc30 will deliver binaries from fc29?
k
Dear all,
Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 30
Beta Release Readiness meeting. This meeting will be held on Thursday,
2018-03-21 at 19:00 UTC.
We will meet to make sure we are coordinated and ready for the Beta
release of Fedora 30. Please note that this meeting will
The Fedora 30 Beta Go/No-Go meeting is next week:
https://apps.fedoraproject.org/calendar/Fedora%20release/2019/3/21/#m9491
Action summary
Accepted blockers
-
1. https://bugzilla.redhat.com/show_bug.cgi?id=1656509
ACTION: libdnf maintainers to verify if an F29
Dear all,
The Go/No-Go meeting for the Fedora 30 Beta release will be held on
Thursday, 2019-03-21 at 17:00 UTC in #fedora-meeting-1. For more
information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting
View the meeting on Fedocal at:
https://apps.fedoraproject.org/calendar/Fedora%20release
On Fri, Mar 15, 2019 at 12:40:00PM -0400, Todd Zullinger wrote:
> Richard W.M. Jones wrote:
> > On Tue, Mar 12, 2019 at 11:38:47AM +0100, Miro Hrončok wrote:
> >> rjones: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle,
> >> xmvn, plexus-utils
> >
> > I'm unclear what if anything I coul
On 3/13/19 8:41 AM, Neal Gompa wrote:
That said, I think if we want to move the repo files now, we should
also consider making so package installed repo and GPG files are in
/usr/share and that admin additions/overrides can be stored in /etc.
Same goes for vars and other such stuff.
That's more
# F30 Blocker Review meeting
# Date: 2019-03-18
# Time: ** 16:00 ** UTC
# Location: #fedora-blocker-review on irc.freenode.net
Hi folks! We have 2 proposed Beta blockers and 3 proposed Beta FEs
to review, so let's have a Fedora 30 blocker review meeting on Monday!
Remember again that we're at 16:
Hi folks! I'm proposing we cancel the QA meeting on Monday. I think we
got through all the outstanding business last week, 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. Note there
*will* be a blocker rev
> Hey, remember when I said I would keep v8-314 alive? I've changed my mind.
> C) It doesn't build anymore because the giant SConstruct goop it uses is
> not compatible with the current SCons. (and it has not built for quite a
> while now).
> D) I have neither the time nor the motivation to do the
Hi Tom,
What do you suggest to packages that depends on this library, bundle or retire
as well?
Thanks,
Samuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of C
Richard W.M. Jones wrote:
> On Tue, Mar 12, 2019 at 11:38:47AM +0100, Miro Hrončok wrote:
>> rjones: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle,
>> xmvn, plexus-utils
>
> I'm unclear what if anything I could do (apart from maintaining loads
> of Java packages which isn't going to h
On Tue, Mar 12, 2019 at 11:38:47AM +0100, Miro Hrončok wrote:
> rjones: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle,
> xmvn, plexus-utils
I'm unclear what if anything I could do (apart from maintaining loads
of Java packages which isn't going to happen). Is the email saying
that so
On Tue, Mar 12, 2019 at 11:11:01AM +0100, Miro Hrončok wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1659737
>
> Anyone knows how to contact the maintainer?
FWIW we've dropped the python-guestfs (ie. Python 2) bindings in
Fedora 31, and I believe that will stop imagefactory from even
build
On Fri, Mar 15, 2019 at 04:15:58PM +, Richard W.M. Jones wrote:
> On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/HardenedCompiler
>
> I'm not opposing this, but is it possible we could do this without
> breaking clang at the same time?
>
On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/HardenedCompiler
I'm not opposing this, but is it possible we could do this without
breaking clang at the same time?
In the past (and currently) the Fedora compiler flags need some hairy
editing s
Hello,
My name is Christophe de Dinechin, and I’m writing this introduction per the
recommendation here:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers.
I’m interested in becoming the Fedora maintainer for several projects I
created, in order:
1. make-it-quick (https:
Missing expected images:
Atomichost raw-xz x86_64
Atomichost qcow2 x86_64
Failed openQA tests: 3/141 (x86_64), 2/24 (i386), 1/2 (arm)
ID: 364884 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/364884
ID: 364897 Test: i386 Workstation-boot-is
On Fri, Mar 15, 2019 at 3:39 PM John M. Harris, Jr.
wrote:
>
> `rpm` does not care what repositories your system has available, it doesn't
> work with them directly. That name would make no sense.
I guess the rationale behind that was more of a "repositories of rpm
packages" than "repositories u
I'm willing to take it over, as it may come handy for my work with SCLs
in CentOS.
Also I'm planning in the near future to play with it and see if there is
any need for necromancy :)
--
Jan Staněk
Associate Software Engineer, Core Services
Red Hat Czech
jsta...@redhat.com IM: jstanek
signa
Hey, remember when I said I would keep v8-314 alive? I've changed my mind.
Why?
A) It is seriously old. I'm not sure I want to encourage anyone to try to
use it at this point.
B) Upstream v8 looks NOTHING like this package anymore
C) It doesn't build anymore because the giant SConstruct goop it u
`rpm` does not care what repositories your system has available, it doesn't
work with them directly. That name would make no sense.
On March 15, 2019 6:31:40 AM EDT, "Samuel Rakitničan"
wrote:
>> If anything of the like, /etc/dnf.repos.d makes more sense. These
>repos are not
>> necessarily par
> Hi,
> I am curious whether we can move our repo files from
> /etc/yum.repos.d
> to
> /etc/distro.repos.d
>
> In Fedora 31 we are going to wipe away last left overs of YUM, so it really
> does not have sense to keep `yum.repos.d`.
>
> DNF for ages parse config files from:
> {"/etc/yum.repos
On Thursday, 14 March 2019 16.26.06 WET Robert-André Mauchin wrote:
> I don't think that should be the case, the build log at 1688565-R-ggplot2/
> build.log is a short non informative one, while the
> 1688565-R-ggplot2/results/ build.log is the actual detailed build output.
OK. This is not what I
On 3/15/19 12:32 PM, Michal Domonkos wrote:
That said, if we should pick a different name today, "yum" seems like
the most sensible choice. While still far from ideal, it has
stickiness within the Fedora/RHEL community, and is a "trademark",
really.
Yesterday's Updater Modified
:-)
--
Robe
Announcing the creation of a new nightly release validation test event
for Fedora 30 Branched 20190315.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
On Fri, Mar 15, 2019 at 11:32 AM Samuel Rakitničan
wrote:
> Please don't tie the name with the particular software to avoid this issue in
> the future. If you must then I think rpm.repos.d is less likely to avoid this
> issue in the future.
+1
Just like a few others have mentioned in this thre
> On 14 Mar 2019, at 23:57, Felix Schwarz wrote:
>
>
> Am 14.03.19 um 13:08 schrieb Fabio Valentini:
>> I think there is (or at least, there used to be) a section in the packaging
>> guidelines which explicitly mentions that including both .c and .h files in
>> non-devel packages is fine (and
On Fri, Mar 15, 2019 at 10:24 AM Vít Ondruch wrote:
>
> I've been there, keeping Ruby .spec file in sync with upstream
> development, and my decision was always to drop the detailed changelog
> and replace it just with single entry. In the end, in the development
> stream, there are many times men
> If anything of the like, /etc/dnf.repos.d makes more sense. These repos are
> not
> necessarily part of the distro.
Please don't tie the name with the particular software to avoid this issue in
the future. If you must then I think rpm.repos.d is less likely to avoid this
issue in the future.
On Thu, Mar 14, 2019 at 11:56 AM Roberto Ragusa wrote:
> Renaming dnf to yum is IMHO the best option.
> I constantly use the wrong tool when switching between Fedora and Centos,
> and the painful "yum.repos.d" string issue (code + docs) would disappear.
Actually, we're planning [1] to rename the
I've been there, keeping Ruby .spec file in sync with upstream
development, and my decision was always to drop the detailed changelog
and replace it just with single entry. In the end, in the development
stream, there are many times mentioned just updates to some snapshots,
temporary workarounds et
Hi Ruchit!
You can try out this site: https://whatcanidoforfedora.org/ which should
contain some initial pointers in which areas you can help out.
If you have more specific questions, you can drop by in IRC in
#fedora-devel on freenode for example.
Cheers,
Dan
Ruchit Vithani writes:
> Hello
Hello,
For a few months now and in order to help upstreams find bugs and test
new features I have been maintaining in copr development versions of a
couple of my packages, namely pre-release versions of Molsketch and
development snapshots of SciDAVis built against Qt5. At the same time,
I have bee
36 matches
Mail list logo
