Re: F31 System-Wide Change proposal: BuildRequires Generators
Dne 18. 02. 19 v 21:19 Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/BuildRequires_Generators > > = BuildRequires Generators = > > == Summary == > Add possibility to generate build-time dependencies within RPM spec > file and teach RPM and mock how to handle this. > > == Owner == > * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian > Festi]], [[User:msuchy|Miroslav Suchý]] > * Email: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, > miros...@suchy.cz > > == Detailed Description == > For many languages (Rust, Golang, Node.Js, Ruby, Python), While Ruby is mentioned here, I can't imagine it would be of any use for Ruby packages. Ruby packages has nothing like "build requires". They have "development" dependencies, but that is something completely different. These are typically needed to execute test suite and executing test suite is not always easy task. Therefore even gem2rpm currently outputs the development dependencies just as a set of BuilrRequires which are commented out by default. Vít > BuildRequires can be automatically generated. All it takes, run some > special tool which will output dependencies in RPM format. > > Q: How will it work under the hood? > A: When you build RPM, something like this will happen under the hood… > # rpm would perform %prep (which is supposed to abort if some > dependencies missing and print them) > # mock would install those dependencies and resume build > > Q: Will src.rpm contain all generated dependencies? > A: This is not known yet, we'll update page once it is known. > > Q: Does this mean that package builds won't be reproducible anymore? > A: No, as long as you have same buildroot and tool which is generating > BuildRequires is doing so in reproducible manner, it should not affect > reproducibility. > > == Benefit to Fedora == > > Packagers won't have to pre-generate BuildRequires in the spec file > which means it will be always updated (and correct) : > > * Packagers can focus of making their packages better instead of > spending all their packaging time copying BuildRequires from > documentation and third party tools. > * BuildRequires are dropped as soon as they're no longer necessary > * Packages can be easily bumped without requiring a manual BuildRequires > refresh > * BuildRequires and Requires generation can use similar utilities, > making sure that the deps packages declare can also be used for > second-level building. Packages no longer need to declare the deps of > their second and n-th dependencies because someone forgot to declare > them in the correct package. > > == Scope == > * Proposal owners: Implement support for a feature in RPM and mock (if > implemented properly, Koji should just work). Make use of it in Rust > ecosystem. > * Other developers: Maintainers of language stacks are advised to use > this feature. > * Release engineering: [https://pagure.io/releng/issue/8129 #8129] > * Policies and guidelines: Packaging Guidelines need to be updated > with instructions how to use this feature. > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > Packagers and users who use repoquery might be affected (src.rpm might > not contain generated dependencies). > > == How To Test == > TBD. > > == User Experience == > Users won't notice differences. > > == Dependencies == > Required feature needs to be implemented in RPM and mock. > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) Proposal > Owners might still ship feature disabled for Fedora buildsystem but > have it available for end-users, and move full completion to the next > release. > * Contingency deadline: Beta Freeze > * Blocks release? No. > * Blocks product? No. > > == Documentation == > TBD. > > == Release Notes == > TBD. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
APT,Synaptic ... ORPHANED
Due to like-dead upstream and security issue, I orphan these packages: apt synaptic fedora-package-config-apt ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Retire YUM 3
On Fri, 2019-02-01 at 11:23 -0500, Neal Gompa wrote: > RepoView just needs a patch to switch from rpmUtils and yum.comps to > rpm and libcomps Python bindings, which I think I already wrote and > put somewhere. I'll have to dig it out. I need a tool to read repos and compare it , meanwhile I found one bug tracker bug for Fedora to switch over to dnf from yum and yum- utils [1] If you could find this code would be great , I checking your repo meanwhile . Thanks. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1156491 -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
That test 'testvoidarg' succeeds for me (normal termination, no SIGSEGV) on
Fedora 28 and Fedora 29.
Yes, it only seems to affect f30/Rawhide with GCC 9 (though I'm not sure it's
the culprit).
The traceback says:
> 41 QCOMPARE(addedFunc->arguments().count(), 0);
so the suggestion is to check if addedFunc->arguments() is NULL.
'addedFunc' itself is 0 (NULL).
Substituting testvoidarg.cpp.o as compiled by gcc-8.2.1-6.fc28.x86_64 (from the
same source)
gives the same SIGSEGV. So compiling testvoidarg.cpp with gcc-9 is no longer a
suspect.
=
void TestVoidArg::testVoidParsedFunction()
{
const char cppCode[] = "struct A { void a(void); };";
const char xmlCode[] = "\
\
\
";
TestUtil t(cppCode, xmlCode);
AbstractMetaClassList classes = t.builder()->classes();
AbstractMetaClass* classA = classes.findClass("A");
QVERIFY(classA);
const AbstractMetaFunction* addedFunc = classA->findFunction("a");
QCOMPARE(addedFunc->arguments().count(), 0); / line 41
}
=
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity Team (weekly)
Dear all, You are kindly invited to the meeting: Modularity Team (weekly) on 2019-02-26 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Team. More information available at: [Modularity Team Docs](https://docs.pagure.org/modularity/) The agenda for the meeting is available as flagged tickets [in the Modularity repository](https://pagure.io/modularity/issues?status=Open&tags=Meeting). Source: https://apps.fedoraproject.org/calendar/meeting/9443/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Mon, 2019-02-25 at 09:58 -0500, Adam Jackson wrote: > On Fri, 2019-02-22 at 19:59 +, Sérgio wrote: > > Add -fsigned-char fix the build thanks, I still not understood, why > > only ppc64le and GCC 9 > > I can't speak to the gcc9 part, but this would probably have failed > on > aarch64 and s390x as well, you just didn't notice because those > aren't > arches in copr. yes , I could check this on koji , aarch64 and others also failed to build. > C's "char" type is either signed or unsigned by default, it's a > function of the processor-specific ABI. It happens to be signed on > i686 > and x86_64, and unsigned on all the other arches Fedora supports. So: > > > /builddir/build/BUILD/gdcm- > > 2.8.8/Testing/Source/Common/Cxx/TestString2.cxx:29:24: error: > > narrowing conversion of '-1' from 'int' to 'char' [-Wnarrowing] > > This would only trigger on unsigned-char arches, because you can't > represent -1 with an unsigned number. The key was "can't represent -1 with an unsigned number" , I add some sign char to the code [1] and it fix the FTBFS Thanks , [1] https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-fix-narrow.patch > - ajax > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On Mon, Feb 25, 2019 at 7:27 PM John Reiser wrote: > On 2/25/19 4:26 PM, Richard Shaw wrote: > > apiextractor builds but pretty much all the tests fail. I got this from > gdb in a mock chroot but not sure how to get more (debuginfo install in a > chroot?) > > > > (gdb) run > > Starting program: > /builddir/build/BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu/tests/testvoidarg > > Missing separate debuginfos, use: dnf debuginfo-install > glibc-2.29-7.fc30.x86_64 > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib64/libthread_db.so.1". > > * Start testing of TestVoidArg * > > Config: Using QTest library 4.8.7, Qt 4.8.7 > > PASS : TestVoidArg::initTestCase() > > > > > > Program received signal SIGSEGV, Segmentation fault. > > TestVoidArg::testVoidParsedFunction (this=) at > /builddir/build/BUILD/apiextractor-0.10.10/tests/testvoidarg.cpp:41 > > 41QCOMPARE(addedFunc->arguments().count(), 0); > > Missing separate debuginfos, use: dnf debuginfo-install > glib2-2.59.2-1.fc30.x86_64 libgcc-9.0.1-0.4.fc30.x86_64 > libstdc++-9.0.1-0.4.fc30.x86_64 libxml2-2.9.9-2.fc30.x86_64 > libxslt-1.1.32-4.fc30.x86_64 openssl-libs-1.1.1a-2.fc30.x86_64 > pcre-8.43-0.1.RC1.fc30.1.x86_64 qt-4.8.7-44.fc30.x86_64 > > xz-libs-5.2.4-5.fc30.x86_64 zlib-1.2.11-15.fc30.x86_64 > > (gdb) thread apply all bt full > > That test 'testvoidarg' succeeds for me (normal termination, no SIGSEGV) > on Fedora 28 and Fedora 29. > Yes, it only seems to affect f30/Rawhide with GCC 9 (though I'm not sure it's the culprit). > > The traceback says: > > 41QCOMPARE(addedFunc->arguments().count(), 0); > so the suggestion is to check if addedFunc->arguments() is NULL. > Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On 2/25/19 4:26 PM, Richard Shaw wrote: apiextractor builds but pretty much all the tests fail. I got this from gdb in a mock chroot but not sure how to get more (debuginfo install in a chroot?) (gdb) run Starting program: /builddir/build/BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu/tests/testvoidarg Missing separate debuginfos, use: dnf debuginfo-install glibc-2.29-7.fc30.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". * Start testing of TestVoidArg * Config: Using QTest library 4.8.7, Qt 4.8.7 PASS : TestVoidArg::initTestCase() Program received signal SIGSEGV, Segmentation fault. TestVoidArg::testVoidParsedFunction (this=) at /builddir/build/BUILD/apiextractor-0.10.10/tests/testvoidarg.cpp:41 41 QCOMPARE(addedFunc->arguments().count(), 0); Missing separate debuginfos, use: dnf debuginfo-install glib2-2.59.2-1.fc30.x86_64 libgcc-9.0.1-0.4.fc30.x86_64 libstdc++-9.0.1-0.4.fc30.x86_64 libxml2-2.9.9-2.fc30.x86_64 libxslt-1.1.32-4.fc30.x86_64 openssl-libs-1.1.1a-2.fc30.x86_64 pcre-8.43-0.1.RC1.fc30.1.x86_64 qt-4.8.7-44.fc30.x86_64 xz-libs-5.2.4-5.fc30.x86_64 zlib-1.2.11-15.fc30.x86_64 (gdb) thread apply all bt full That test 'testvoidarg' succeeds for me (normal termination, no SIGSEGV) on Fedora 28 and Fedora 29. The traceback says: > 41QCOMPARE(addedFunc->arguments().count(), 0); so the suggestion is to check if addedFunc->arguments() is NULL. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Translating spec to dockerfile for upstream ispc
On 2019-02-23 1:48 p.m., Christoph Junghans wrote:
> On Fri, Feb 22, 2019 at 10:31 PM Luya Tshimbalanga >
> wrote: >> >> Upstream ISPC [0] will need a
dockerfile to reproduce the failure to >> build ispc package in
Fedora[1][2]. Unfortunately, I know very little >> about the Docker
functionality so I will need assistance to do so. > You can do an rpm
build from a spec file within docker with a > dockerfile like this: >
FROM fedora:rawhide > RUN dnf install -y spectool git rpm-build
dnf-plugins-core > RUN git clone
https://src.fedoraproject.org/rpms/ispc.git > WORKDIR ispc > RUN
spectool -g ispc.spec > RUN dnf builddep -y ispc.spec > RUN rpmbuild
-D"_sourcedir ${PWD}" -D"_srcrpmdir ${PWD}" -ba ispc.spec > (you might
need to point git to clone the right spec file.) > > Christoph
Done. Thank you Christoph.
Luya
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
apiextractor FTBFS troubleshooting
apiextractor builds but pretty much all the tests fail. I got this from gdb
in a mock chroot but not sure how to get more (debuginfo install in a
chroot?)
(gdb) run
Starting program:
/builddir/build/BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu/tests/testvoidarg
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.29-7.fc30.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
* Start testing of TestVoidArg *
Config: Using QTest library 4.8.7, Qt 4.8.7
PASS : TestVoidArg::initTestCase()
Program received signal SIGSEGV, Segmentation fault.
TestVoidArg::testVoidParsedFunction (this=) at
/builddir/build/BUILD/apiextractor-0.10.10/tests/testvoidarg.cpp:41
41 QCOMPARE(addedFunc->arguments().count(), 0);
Missing separate debuginfos, use: dnf debuginfo-install
glib2-2.59.2-1.fc30.x86_64 libgcc-9.0.1-0.4.fc30.x86_64
libstdc++-9.0.1-0.4.fc30.x86_64 libxml2-2.9.9-2.fc30.x86_64
libxslt-1.1.32-4.fc30.x86_64 openssl-libs-1.1.1a-2.fc30.x86_64
pcre-8.43-0.1.RC1.fc30.1.x86_64 qt-4.8.7-44.fc30.x86_64
xz-libs-5.2.4-5.fc30.x86_64 zlib-1.2.11-15.fc30.x86_64
(gdb) thread apply all bt full
Thread 1 (Thread 0x7685b2c0 (LWP 45)):
#0 TestVoidArg::testVoidParsedFunction (this=) at
/builddir/build/BUILD/apiextractor-0.10.10/tests/testvoidarg.cpp:41
cppCode = "struct A { void a(void); };"
xmlCode = ""
t = {m_builder = 0x555776e0}
classes = {> = {{p = {static shared_null
= {ref = {_q_value = 85}, alloc = 0, begin = 0, end = 0, sharable = 1,
array = {0x0}}, d = 0x555a2fc0}, d = 0x555a2fc0}}, }
classA =
addedFunc = 0x0
#1 0x77e287e2 in QMetaMethod::invoke(QObject*, Qt::ConnectionType,
QGenericReturnArgument, QGenericArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument)
const () from /lib64/libQtCore.so.4
No symbol table info available.
#2 0x77e29862 in QMetaObject::invokeMethod(QObject*, char const*,
Qt::ConnectionType, QGenericReturnArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument) () from /lib64/libQtCore.so.4
No symbol table info available.
#3 0x77fa792a in ?? () from /lib64/libQtTest.so.4
No symbol table info available.
#4 0x77fa890e in QTest::qExec(QObject*, int, char**) () from
/lib64/libQtTest.so.4
No symbol table info available.
#5 0x684a in main (argc=1, argv=0x7fffdc38) at
/builddir/build/BUILD/apiextractor-0.10.10/tests/testvoidarg.cpp:78
tc = { = {}, static staticMetaObject = {d
= {superdata = 0x77f891a0 , stringdata =
0x80c0 "TestVoidArg", data =
0x8120 , extradata = 0x9b90
}}, static
staticMetaObjectExtraData = {objects = 0x0, static_metacall =
0x7ba0 }}
Any tips appreciated.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
arm-none-eabi-gcc-cs 7.3.0
NOTE: I have emailed the maintainer (mhlavink) on Friday but have not heard
back. Normally I would wait longer but it's FTBFS.
Currently 7.1.0 is in Fedora and I was looking at updating to something
more recent (8.x?) but noticed that there had been a few attempts to build
7.3.0, but only the ppc64le build was failing.
I believe I found a fix for ppc64le failing here:
https://gcc.gnu.org/viewcvs/gcc/branches/gcc-6-branch/libcpp/lex.c?r1=261621&r2=261620&pathrev=261621
Anyone see an issue with this?
I've got a scratch build here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32988860
I also performed a local mock build for Fedora 29 so I can test it out with
my project. For it I added %{?_smp_mflags} to the make lines and it
completed MUCH faster without issue.
I wonder if there was any particular reason it wasn't enabled in the
first place?
If this does indeed fix the build problem, is it OK if I push the patch and
build for Fedora 29->Rawhide?
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora ThinkPad P72 NVMe drive support
On Sat, Feb 23, 2019 at 12:29 AM wrote: > Does Fedora support the Intel 82801 RST (fake)RAID chip used in Lenovo's > newest ThinkPad P72? No F29 installer can see the two 2T SSDs setup as a > RAID1 mirror, either as a /dev/mdN array or individually as /dev/sdX or > /dev/nvmeN. Adam Williamson suggested I put this question to #fedora-devel. > I hope this is the right place. > You didn't mention if you tried scanning for the raid array... I don't have any direct experience but this link for Arch seems good. Might provide some hints... https://medium.com/@pmarrapese/arch-linux-and-intel-rst-fake-raid-cece10b61ac3 Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/minutes for today's FESCo Meeting (2019-02-25)
On Mon, Feb 25, 2019 at 06:45:13PM +0100, Michal Konecny wrote: > > > On 25/02/19 16:04, Zbigniew Jędrzejewski-Szmek wrote: > >Schedule for Friday's FESCo Meeting (2014-10-01) > Just want to point at date above ^ > I missed that one Oh, nothing important happened at that meeting ;) On the one today, on the other hand: Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-02-25/fesco.2019-02-25-15.03.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-02-25/fesco.2019-02-25-15.03.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-02-25/fesco.2019-02-25-15.03.log.html == https://pagure.io/fesco/issue/2090 == AGREED: mboddu's proposal https://pagure.io/fesco/issue/2090#comment-554540 is approved (+7, 0, 0) == https://pagure.io/fesco/issue/2088 == https://paste.fedoraproject.org/paste/W8WBUJsA0Fj3epjfKkSzbA ACTION: bowlofeggs will file an RFE for better error messages from dnf REJECTED: Waiting for one more week (+2, 0, -3) AGREED: Feature is postponed to F31, without accepting or rejecting. We need more information from the Change owners about specific cases that this solves (+6, 0, 0) == https://pagure.io/fesco/issue/2084 == AGREED: Creating a FAS identity that has permissions to upload stuff to the lookaside cache, fork repos and send PRs (including kerberos and all technical things to make it work), but not to push to repos or build packages, is approved (+7, 0, 0) FESCo is concerned that the presented idea of how this automation should work is only applicable to a very limited set of packages and would rather see a focus on automating stuff for greater audience. FESCo is also concerned that moving spec to upstream breaks experience for multiple interested parties. == https://pagure.io/fesco/issue/2027 == https://pagure.io/modularity/working-documents/blob/master/f/lifecycles-upgrades-ownership/lifecycles-general.md https://fpdc.fedoraproject.org/api/v1/ REJECTED: Proposal in its current form is accepted (+2, 2, -3) (discussion to continue in the ticket after a new proposal) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages that will be retired
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, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Full dependencies breakdown at https://churchyard.fedorapeople.org/orphans-2019-02-25.txt Grep it for your FAS name. Package (co)maintainers Status Change OSGi-bundle-ant-task orphan 3 weeks ago RunSnakeRun orphan 6 weeks ago SimplyHTMLmizdebsk, orphan 2 weeks ago aether-connector-okhttp galileo, mizdebsk, orphan2 weeks ago ant akurtakov, jcapik, kdaniel, 2 weeks ago mizdebsk, msrb, orphan ant-antunit mizdebsk, orion, orphan 2 weeks ago ant-contrib davidcl, mizdebsk, orphan2 weeks ago antlr3dchen, lef, mizdebsk,2 weeks ago mjakubicek, orphan, walters antlr4gil, jkastner, lef, mizdebsk,2 weeks ago orphan aopalliance mizdebsk, orphan 2 weeks ago apache-commons-beanutils fnasser, mizdebsk, orphan, 2 weeks ago spike apache-commons-collectionsjcapik, mizdebsk, orphan 2 weeks ago apache-commons-collections4 mizdebsk, orphan 2 weeks ago apache-commons-compress mizdebsk, mkoncek, orphan, 2 weeks ago spike apache-commons-configuration fnasser, mizdebsk, orphan, 2 weeks ago spike apache-commons-csvlef, mizdebsk, orphan, spike 2 weeks ago apache-commons-daemon mizdebsk, orphan, spike 2 weeks ago apache-commons-discovery lkundrak, mizdebsk, orphan, 2 weeks ago spike apache-commons-el fnasser, mizdebsk, orphan, 2 weeks ago spike apache-commons-fileupload jerboaa, mizdebsk, mmraka, 2 weeks ago orphan, spike apache-commons-io mizdebsk, orphan, spike 2 weeks ago apache-commons-jexl mizdebsk, orphan 2 weeks ago apache-commons-jxpath fnasser, mizdebsk, orphan, 2 weeks ago spike apache-commons-lang mizdebsk, orphan, spike 2 weeks ago apache-commons-lang3 mizdebsk, orphan 2 weeks ago apache-commons-loggingkdaniel, mizdebsk, orphan, 2 weeks ago spike apache-commons-netmizdebsk, orphan, spike 2 weeks ago apache-ivymizdebsk, orphan 2 weeks ago apache-james-project lef, mizdebsk, orphan2 weeks ago apache-logging-parent mizdebsk, orphan 2 weeks ago apache-mime4j lef, mizdebsk, orphan2 weeks ago apache-parent mizdebsk, orphan 2 weeks ago apache-ratmizdebsk, orphan 2 weeks ago apache-resource-bundles mizdebsk, orphan 2 weeks ago apiguardian mizdebsk, orphan 2 weeks ago aqute-bnd jcapik, mizdebsk, orphan 2 weeks ago args4jjcapik, mizdebsk, orphan 2 weeks ago atinject kdaniel, mizdebsk, orphan2 weeks ago avalon-framework jerboaa, mizdebsk, orphan2 weeks ago avalon-logkit jerboaa, mizdebsk, orphan2 weeks ago base64coder jcapik, mizdebsk, orphan 2 weeks ago batik jvanek, mizdebsk, orphan 2 weeks ago bcel mizdebsk, orphan 2 weeks ago bea-stax jcapik, mizdebsk, orphan 2 weeks ago beust-jcommander jcapik, jvanek, mizdebsk,2 weeks ago orphan blobbyorphan
Re: Broken dependency for devscripts in f29
Am Sonntag, den 24.02.2019, 19:11 +0100 schrieb Björn 'besser82' Esser: > Am Sonntag, den 24.02.2019, 23:06 +0900 schrieb Mamoru TASAKA: > > Björn 'besser82' Esser wrote on 2019/02/24 21:22: > > > Am Sonntag, den 24.02.2019, 10:39 +0100 schrieb Dridi Boukelmoune: > > > > Hi, > > > > > > > > Somehow this slipped through the cracks: > > > > > > > > > Dependencies resolved. > > > > > > > > > > Problem: cannot install the best update candidate for > > > > > package > > > > > devscripts-2.18.4-1.fc29.x86_64 > > > > >- nothing provides perl(GitLab::API::v4::Constants) needed > > > > > by > > > > > devscripts-2.19.2-3.fc29.x86_64 > > > > > > > > I tried this too but no luck there: > > > > > > > > > $ sudo dnf install 'perl(GitLab::API::v4::Constants)' -- > > > > > enablerepo > > > > > updates-testing > > > > > [...] > > > > > No match for argument: perl(GitLab::API::v4::Constants) > > > > > Error: Unable to find a match > > > > > > > > Dridi > > > > > > Thanks for the catch! This also affects Rawhide and f30. > > > > > > I've already filed a bug [1] about this and submitted the needed > > > dependency chain for review [2,3,4,5,6]. Help with the (almost > > > less > > > then trivial) reviews is appreciated. > > > > > > > > > > Ummm... Can't you fix this broken dependency until the reviews gets > > passed? > > Looks like just killing /usr/bin/salsa (and Salsa.pm and so on) > > resolves the issue for a moment - Actually /usr/bin/salsa did not > > exist > > in devscripts-2.18.9 , which suggests that /usr/bin/salsa script is > > "enhancement" so once killing that script should not hurt. > > > > Regards, > > Mamoru > > The needed dependency chain has been reviewed and is waiting for the > SCM-admin to create the repos and branches. As soon as that happened, > I'll build the packages and push updates, if needed. This should be > at > sometime during tomorrow. > > Thanks, > Björn The needed package dependencies have been built for Rawhide and f28 up to f30. For f29 I've additonally tagged the builds into the buildroot override until the actual update goes stable, so the devscripts package is installable again for Koji builds consuming it. Cheers, Björn signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Beta blocker status mail #1
On Sat, 2019-02-23 at 16:57 -0500, Neal Gompa wrote: > On Sat, Feb 23, 2019 at 4:51 PM Tomasz Kłoczko > wrote: > > On Fri, 22 Feb 2019 at 19:37, Ben Cotton wrote: > > > As we've now reached the branch point, it's time to start weekly > > > blocker status mails. > > > > mdadm does not compile on fc30 > > https://koji.fedoraproject.org/koji/getfile?taskID=32819259&volume=DEFAULT&name=build.log&offset=-4000 > > https://koji.fedoraproject.org/koji/taskinfo?taskID=32819232 > > > > It would be really good if someone would create list of packages which > > build failed on last fc30 MR. > > They did. You missed the announcement: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JLNTP72GAH5PW63PIHCG5NLPDHVTIDRH/ > > Moreover, there's a website to view the failures: > https://kojipkgs.fedoraproject.org/mass-rebuild/f30-need-rebuild.html > > And there's a tracking bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1674516 Also note that FTBFS is not necessarily a blocking issue; if the package isn't critical to anything blocker-related, or it is but the previously built package appears to be *working* fine, then the release isn't blocked. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Retiring pysvn (was Re: Orphaning pysvn (and non-responsive maintainer: ravenoak))
On Mon, Feb 25, 2019 at 1:32 PM Barry Scott wrote: > > > > > On 25 Feb 2019, at 13:07, Stephen Gallagher wrote: > > > > On Tue, Feb 19, 2019 at 1:59 PM Barry Scott wrote: > > > >> Just heard about this. I'm the author of pysvn. > >>libmodulemd > >> I'd be willing to maintain the fedora package of > >> pysvn. What do you need me to do? > >> > >> I am an active user and developer on Fedora and I create and maintain > >> a numbers of RPMs in my work and personal projects. > >> > > > > Thanks for taking this over, Barry! I'll get you added as an admin on > > the pysvn package immediately. I see someone (Kevin?) sponsored you as > > a packager already, so that's good. > > > > I need you to go to https://src.fedoraproject.org/rpms/pysvn and log > > out, then back in. That will update your FAS account with dist-git > > Pagure and I'll be able to make you an admin on that project. Once > > you've done that, please let me know. > > > > Done. Logged in then out. > You are all set. You should have admin access to that repository now. Let me know if you need anything else. Otherwise, I'll remove myself from that package on Friday. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Retiring pysvn (was Re: Orphaning pysvn (and non-responsive maintainer: ravenoak))
> On 25 Feb 2019, at 13:07, Stephen Gallagher wrote: > > On Tue, Feb 19, 2019 at 1:59 PM Barry Scott wrote: > >> Just heard about this. I'm the author of pysvn. >> >> I'd be willing to maintain the fedora package of >> pysvn. What do you need me to do? >> >> I am an active user and developer on Fedora and I create and maintain >> a numbers of RPMs in my work and personal projects. >> > > Thanks for taking this over, Barry! I'll get you added as an admin on > the pysvn package immediately. I see someone (Kevin?) sponsored you as > a packager already, so that's good. > > I need you to go to https://src.fedoraproject.org/rpms/pysvn and log > out, then back in. That will update your FAS account with dist-git > Pagure and I'll be able to make you an admin on that project. Once > you've done that, please let me know. > Done. Logged in then out. Barry ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Schedule for today's FESCo Meeting (2019-02-25)
On 25/02/19 16:04, Zbigniew Jędrzejewski-Szmek wrote: Schedule for Friday's FESCo Meeting (2014-10-01) Just want to point at date above ^ I missed that one Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-10-01 15:00 UTC' Links to all issues below can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #2090 Needs more understanding on retiring packages with security issues .fesco 2090 https://pagure.io/fesco/issue/2090 #2088 Late F30 Change – “dnf --best” as default behavior .fesco 2088 https://pagure.io/fesco/issue/2088 #2084 "Fedora packaging service" & packit ask .fesco 2084 https://pagure.io/fesco/issue/2084 = Open Floor = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Agenda for Tuesday's Modularity Team Meeting (2019-02-26)
Find below a list of topics which are planned to be discussed in the Fedora Modularity Team meeting on Tuesday at 15:00 UTC in #fedora-meeting-3 on irc.freenode.net. To find out when this is in your local time zone, check the Fedora Calendar (if you've set it and are logged in): https://apps.fedoraproject.org/calendar/modularity/#m5249 Alternatively, to convert UTC to your local time zone, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d 'Tuesday 15:00 UTC' Links to all issues below can be found at: https://pagure.io/modularity/report/meeting_agenda = Discussed and Voted = N/A = Followups = #topic #112 Discussion: Module lifecycles #link https://pagure.io/modularity/issue/112 .modularity 112 #link https://pagure.io/fesco/issue/2027 #topic #115 Discussion: Stream branch ownership for packages & modules #link https://pagure.io/modularity/issue/115 .modularity 115 #link https://pagure.io/fesco/issue/2028 = New business = N/A = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/modularity/report/meeting_agenda If you would like to add something to this agenda, you can file a new issue at https://pagure.io/modularity/issues, or bring it up at the end of the meeting during the open floor topic. Note that the meeting is one hour long and issues we don't get around to discussing may be deferred until the following meeting. -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for today's FESCo Meeting (2019-02-25)
Schedule for Friday's FESCo Meeting (2014-10-01) Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-10-01 15:00 UTC' Links to all issues below can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #2090 Needs more understanding on retiring packages with security issues .fesco 2090 https://pagure.io/fesco/issue/2090 #2088 Late F30 Change – “dnf --best” as default behavior .fesco 2088 https://pagure.io/fesco/issue/2088 #2084 "Fedora packaging service" & packit ask .fesco 2084 https://pagure.io/fesco/issue/2084 = Open Floor = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Fri, 2019-02-22 at 19:59 +, Sérgio wrote: > Add -fsigned-char fix the build thanks, I still not understood, why > only ppc64le and GCC 9 I can't speak to the gcc9 part, but this would probably have failed on aarch64 and s390x as well, you just didn't notice because those aren't arches in copr. C's "char" type is either signed or unsigned by default, it's a function of the processor-specific ABI. It happens to be signed on i686 and x86_64, and unsigned on all the other arches Fedora supports. So: > /builddir/build/BUILD/gdcm-2.8.8/Testing/Source/Common/Cxx/TestString2.cxx:29:24: > error: narrowing conversion of '-1' from 'int' to 'char' [-Wnarrowing] This would only trigger on unsigned-char arches, because you can't represent -1 with an unsigned number. - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: Automatic strict inter-package dependencies
On Sun, Feb 24, 2019 at 09:42:10PM -0500, John Harris wrote:
> On Saturday, February 23, 2019 7:21:36 PM EST Richard W.M. Jones wrote:
> > On Mon, Feb 18, 2019 at 08:26:58PM -0500, Neal Gompa wrote:
> >
> > > On Mon, Feb 18, 2019 at 6:31 PM Tom Stellard wrote:
> > >
> > > >
> > > >
> > > > Would there be some way to opt out of this? In some cases,
> > > > %{name}-devel
> > > > Requires only %{name}-libs and not %{name}.
> > > >
> > > >
> > >
> > >
> > > Perhaps it's not obvious, but the idea here is that RPM will "sense"
> > > what the name of the subpackage it depends on is, and generate the
> > > correct strict dependency automatically.
> > >
> > > For example, foo, foo-libs, libfoobaz, and foo-devel exist, built from
> > > foo.spec.
>
> > > foo-devel requires libfoobaz.so.1 (provided by libfoobaz) and
> > > libfoo.so.0 (provided by foo-libs).
> > >
> > > Currently, rpm generates the "libfoobaz.so.1()(64bit)" and
> > > "libfoo.so.0()(64bit)" dependencies and leaves the rest to you. This
> > > will change the behavior so that when it identifies that a subpackage
> > > produced from the spec contains that dependency, it'll be replaced
> > > with a strictly versioned dep on the subpackage. So instead of
> > > "libfoo.so.0()(64bit)", it'll be "foo-libs%{?_isa} =
> > > %{version}-%{release}". And the "libfoobaz.so.1()(64bit)" dependency
> > > would be replaced with "libfoobaz%{?_isa} = %{version}-%{release}".
> >
> >
> > I'm not saying it's right or wrong (but probably it's more "right"):
> > However this does change the actual semantics, I think. I mean,
> > previously "libfoobaz.so.1()(64bit)" might have been satisfied by an
> > older -libs package, or by another package which happens to provide
> > libfoobaz.so.1. I wonder if anything relies on that?
> >
> > Rich.
> >
> >
> > > If there's no requires that matches with a provides in another
> > > subpackage that's built from the spec, rpm would not do anything, and
> > > it'll be exactly as it is now.
> > >
> > > This is merely about optimizing requires across subpackages from the
> > > same source package.
> > >
> > >
> > >
> > > --
> > > 真実はいつも一つ！/ Always, there's only one truth!
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o
> > > rg
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat
> > http://people.redhat.com/~rjones
> > Read my programming and virtualization
> > blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without
> > needing to install any software inside the virtual machine. Supports Linux
> > and Windows. http://people.redhat.com/~rjones/virt-df/
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> I definitely hope there is a way to opt out, as, often, it is not required to
> have the exact same version, so long as the soname has not been bumped. There
> are very few instances that I can think of where an soname bump is not done
> when ABI changes.
>
> Though where I know that to be the case, it's *bad*, and affects many other
> things.. So I can see the reasoning.
I think the thinking is that in case of dependencies between subpackages
of the same package it's easier and safer to simply always update them
in tandem. There might be special cases (e.g. a very large data subpackage)
where it makes sense to allow more freedom, but for the great majority
of cases this kind of flexibility is not necessary. And by doing updates
in tandem, we avoid many issues where one subpackage depends on changes
in another subpackage. In fact, in don't expect changes that are not public
API to be declared in any way.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Retiring pysvn (was Re: Orphaning pysvn (and non-responsive maintainer: ravenoak))
On Tue, Feb 19, 2019 at 1:59 PM Barry Scott wrote: > Just heard about this. I'm the author of pysvn. > > I'd be willing to maintain the fedora package of > pysvn. What do you need me to do? > > I am an active user and developer on Fedora and I create and maintain > a numbers of RPMs in my work and personal projects. > Thanks for taking this over, Barry! I'll get you added as an admin on the pysvn package immediately. I see someone (Kevin?) sponsored you as a packager already, so that's good. I need you to go to https://src.fedoraproject.org/rpms/pysvn and log out, then back in. That will update your FAS account with dist-git Pagure and I'll be able to make you an admin on that project. Once you've done that, please let me know. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Non-responsive maintainer cquad
Hello all, according to the policy [1], I am starting a non-responsive maintainer process to be able to update dependency of one of my packages. I filled a bug several months ago and explicitly asked for ans answer last week [2] without any response. Cedric (in cc) does not look active in Fedora during last year. If you know some other contact, than the email in the FAS, please let me know. Last login in FAS: cquad 2018-04-25 Last action on koji: Sat, 19 Aug 2017 package list entry revoked: gitso in dist-6E-epel by pkgdb Last package update on bodhi: 2017-02-04 06:31:48 on package svgsalamander-1.1.1-1.fc25 Last actions performed according to fedmsg: - jje...@redhat.com updated 'flag.needinfo' on RHBZ#1645865 'Please, update svgsalamander to 1.1.2' on 2019-02-20 09:58:44 () - jje...@redhat.com updated 'flag.needinfo' on RHBZ#1645865 'Please, update svgsalamander to 1.1.2' on 2019-02-20 09:58:44 () - releng updated nothing on RHBZ#1675995 'signpost-core: FTBFS in Fedora rawhide/f...' on 2019-02-11 22:58:50 () - releng updated nothing on RHBZ#1674975 'gitso: FTBFS in Fedora rawhide/f30' on 2019-02-11 19:27:02 () - unofficialmonst...@gmail.com commented on RHBZ#1536356 '[abrt] pulseaudio: pa_bluetooth_discover...' on 2018-12-08 09:10:44 () - bcot...@redhat.com commented on RHBZ#1524586 'CVE-2016-4216 xmpcore: XXE resulting in ...' on 2018-11-27 18:52:24 () - bcot...@redhat.com commented on RHBZ#1417569 'CVE-2017-5617 svgsalamander: Server side...' on 2018-11-27 16:26:00 () - cquad moved to position 876 on the badges leaderboard on 2018-11-21 05:19:24 () - cquad has been awarded the "Adult Frog" badge on 2018-11-21 05:19:13 () - jje...@redhat.com filed a new bug RHBZ#1645865 'Please, update svgsalamander to 1.1.2' on 2018-11-04 14:27:17 () [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1645865 Thanks, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
