Announce: Log Detective - AI tool to analyze build logs failures
by Jiri Kyjovsky
Hey, Fedora devs!
Ever find yourself lost in the labyrinth of build logs, desperately seeking
the elusive culprit behind a failed build? Enter Log Detective – your
future personal AI guru dedicated to unravelling the mysteries of build log
failures within the RPM community.
*What is Log Detective?*
Log Detective will be an AI tool for analyzing failed build logs in the RPM
community. We are currently in the early stage of development and plan to
train the AI using real-world data from maintainers, creating a specialized
model for error identification. Thus we created a data collection portal
[1], where you can contribute your failed build logs.
*Why Log Detective?*
Diving into build logs feels like navigating a jungle of thousands of
lines. When a build fails, spotting the glitch easily turns into a
head-scratcher even for pros. "ERROR" in logs doesn't guarantee always a
quick fix, and these errors don't reveal themselves at the log's end.
Untangling this requires a keen understanding of packaging difficulties.
*Help us shape the future of Log Detective!*
We're reaching out to developers like you to contribute by uploading your
recent failed build logs on our website [1] and explaining why the build
failed. Your input is crucial in building the dataset that will train Log
Detective's AI model. By participating, you're playing a key role in
creating a tool to streamline error resolution for the entire RPM
community. Join us in making Fedora even more powerful!
*How to contribute data to Log Detective data collection website?*
Visit log-detective.com [1] and share your recent failed build. We can
fetch the logs from build systems like Copr [2], Koji [3], services like
Packit [4] or arbitrary URL. Highlight the lines in the log associated with
the failure and describe how it can be fixed. The more detailed, the
merrier for our final tool, and the more hints for you and other developers
when your build fails in future.
*Join the Log Detective!*
Drop by our GitHub repository [5] to share your ideas. Let's collaborate to
build a tool that changes the game for handling build log failures.
Log Detective isn't just a tool, it's your AI sidekick for defeating build
log challenges. Be part of the revolution!
Cheers,
The Log Detective Crew
[1] - https://log-detective.com/
[2] - https://copr.fedorainfracloud.org/
[3] - https://koji.fedoraproject.org/
[4] - https://packit.dev/
[5] - https://github.com/fedora-copr/log-detective-website
3 months, 3 weeks
Intend to unretire stgit
by Felix Maurer
Hi,
I intend to get stgit unretired and want to maintain it in the future.
The package has been in Fedora up to f38 but has since been orphaned
and, following that, retired. The reason for orphaning it was lack of
time of the maintainer, especially as stgit got rewritten in Rust and
required significant packaging effort to get all dependencies into
Fedora. The dependencies are now all packaged (thanks to all the
packagers dealing with these numerous Rust dependencies!).
As stgit has been retired for a while, a re-review is needed. I already
created the review request for stgit at [1].
Thanks,
Felix
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2260849
3 months, 3 weeks
SWIG 4.2 Python transition
by Florian Weimer
Quoting CHANGES from SWIG 4.2.0:
“
2023-12-20: wsfulton
#2190 Replace SWIG_Python_str_AsChar with SWIG_PyUnicode_AsUTF8AndSize.
SWIG_Python_str_AsChar has undefined behaviour when Py_LIMITED_API is defined
as it returns a pointer to a string in a PyBytes object that no longer exists.
SWIG_PyUnicode_AsUTF8AndSize is an efficient replacement, but requires a
different API and the caller to decrement the refcount on the intermediate
PyObject in the Py_LIMITED_API < 0x030A0000 implementation. The alternative
would have required copying the returned char * string as was done in a
previous implementation requiring a call to the defunct SWIG_Python_str_DelForPy3
function.
*** POTENTIAL INCOMPATIBILITY ***
”
This function is somewhat widely used:
<https://codesearch.debian.net/search?q=SWIG_Python_str_AsChar&literal=1>
I tried to fix the ldns bindings like this:
diff --git a/contrib/python/ldns_rdf.i b/contrib/python/ldns_rdf.i
index 5d7448fd..60daf1a7 100644
--- a/contrib/python/ldns_rdf.i
+++ b/contrib/python/ldns_rdf.i
@@ -56,7 +56,11 @@
*/
%typemap(arginit, noblock=1) const ldns_rdf *
{
+#if SWIG_VERSION >= 0x040200
+ PyObject *$1_bytes = NULL;
+#else
char *$1_str = NULL;
+#endif
}
/*
@@ -66,11 +70,17 @@
%typemap(in, noblock=1) const ldns_rdf * (void* argp, $1_ltype tmp = 0, int res)
{
if (Python_str_Check($input)) {
+ const char *argstr;
+#if SWIG_VERSION >= 0x040200
+ argstr = SWIG_PyUnicode_AsUTF8AndSize($input, NULL, &$1_bytes);
+#else
$1_str = SWIG_Python_str_AsChar($input);
- if ($1_str == NULL) {
+ argstr = $1_str;
+#endif
+ if (argstr == NULL) {
%argument_fail(SWIG_TypeError, "char *", $symname, $argnum);
}
- tmp = ldns_dname_new_frm_str($1_str);
+ tmp = ldns_dname_new_frm_str(argstr);
if (tmp == NULL) {
%argument_fail(SWIG_TypeError, "char *", $symname, $argnum);
}
@@ -90,10 +100,17 @@
*/
%typemap(freearg, noblock=1) const ldns_rdf *
{
+#if SWIG_VERSION >= 0x040200
+ if ($1_bytes != NULL) {
+ /* Is not NULL only when a conversion form string occurred. */
+ Py_XDECREF($1_bytes);
+ }
+#else
if ($1_str != NULL) {
/* Is not NULL only when a conversion form string occurred. */
SWIG_Python_str_DelForPy3($1_str); /* Is a empty macro for Python < 3. */
}
+#endif
}
%nodefaultctor ldns_struct_rdf; /* No default constructor. */
Submitted upstream as <https://github.com/NLnetLabs/ldns/pull/232>.
Maybe that will get some useful comments; I don't know much about SWIG.
(The core of the change above is the call to
SWIG_PyUnicode_AsUTF8AndSize and Py_XDECREF call for the bytes object.)
In the past, this kind of problem would have just compiled and resulted
in a run-time error when the Python extension module is loaded. In some
cases, issues went completely unnoticed because the Python bindins were
unused. But with GCC 14, it is necessary to fix calls to undeclared
functions.
Thanks,
Florian
3 months, 3 weeks
Self Introduction: Neftali Yagua
by Neftalí Yagua
Dear Community!
My name is Neftalí Yagua, a Software Engineer from Venezuela since 2004,
I'm worked with Linux since 1997, my beginnings with RHEL have been with
RedHat, but I have been using Fedora for about 10 years, and I love it, I
want to be an active part of the community, develop and maintain sources
for Fedora. I would even like to make a distribution based on Fedora.
I am currently working on the development of plugins for Cockpit, to try to
integrate myself and at the same time have some control over the projects.
http://links.neftaliyagua.com/ls/click?upn=lAjBpxZAYTGU0gh6HQsXzgI75bmeb7...
Additionally, I will be collaborating with the translations into Spanish. I
have experience in multiple programming languages.
Please, if you think I can contribute something to a project you are
working on, invite me.
http://links.neftaliyagua.com/ls/click?upn=lAjBpxZAYTGU0gh6HQsXzi95GQNLYu...
http://links.neftaliyagua.com/ls/click?upn=lAjBpxZAYTGU0gh6HQsXzuW-2BqCoh...
http://links.neftaliyagua.com/ls/click?upn=lAjBpxZAYTGU0gh6HQsXzr8QK3Perh...
Linux User: 507122 Ubuntu User: 30642
-- Regards, Neftali Yagua
3 months, 3 weeks
Self Introduction: Jacek Migacz
by Jacek Migacz
Dear Community!
My name is Jacek Migacz; a software engineer from Poland.
I'm currently maintaining curl and emacs on Red Hat Enterprise Linux.
I am eager to learn from the collective wisdom of the community and
contribute in meaningful ways.
--
Regards,
Jacek
3 months, 3 weeks
mingw packaging: equivalent of %cmake_build, %cmake_install macros?
by Eric Smith
I'm trying to add mingw build support to the fmt package spec. I've done
this previously with the pugixml and zipios packages, and submitted the
spec diffs to the package maintainer of those.. Both packages use cmake.
Both in the %build section use %cmake then %cmake_build, and in the
%install section use %cmake_install. As expert neither on cmake nor on
mingw, I'm somewhat baffled as to why there are %cmake_build and
%cmake_install macros, but no corresponding %mingw_cmake_build and
%mingw_cmake_install macros. Is there some equivalent that just happens to
not be obvious to me? What I found worked for both pugixml and zipios was:
original: %cmake; %cmake_build
original install: %cmake_install
added for mingw build: %mingw_cmake (and did not add anything equivalent
to %cmake_build)
added for mingw install: %mingw_make_install; %{?mingw_debug_install_post)
Unfortunately this simple attempt failed for fmt. The %mingw_cmake doesn't
cause an error, but also doesn't build fmt. The attempted
%mingw_make_install results in: "make: *** No rule to make target
'install'. Stop." Perhaps this has to do with the fmt build also using
Ninja, which pugixml and zipios do not.
If anyone can offer advice, it would be much appreciated. I started from
the specs from the packages:
pugixml-1.13-4
zipios-2.2.5.0-7
fmt-10.0.0-3
My modified spec files are at:
http://www.brouhaha.com/~eric/fedora-packaging-test/
Best regards,
Eric
@brouhaha
3 months, 3 weeks
Re: Orphaned packages looking for new maintainers
by Sergio Pascual
El dom, 28 ene 2024 a las 18:06, Maxwell G (<maxwell(a)gtmx.me>) escribió:
>
> Report started at 2024-01-28 16:04:44 UTC
>
> 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.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/<pkgname>
>
> Full report available at:
> https://a.gtmx.me/orphans/orphans.txt
> grep it for your FAS username and follow the dependency chain.
>
> For human readable dependency chains,
> see https://packager-dashboard.fedoraproject.org/
> For all orphaned packages,
> see https://packager-dashboard.fedoraproject.org/orphan
>
> Package (co)maintainers Status Change
> ================================================================================
> 3proxy orphan 3 weeks ago
> applet-window-buttons @kde-sig, orphan 0 weeks ago
> bismuth @kde-sig, orphan 0 weeks ago
> cdsclient @astro-sig, orphan 4 weeks ago
> csmith orphan 4 weeks ago
> drumstick0 orphan, yanqiyu 1 weeks ago
> elpa @scitech_sig, orphan 3 weeks ago
> kpipewire5 @kde-sig, orphan 2 weeks ago
> lightly orphan 0 weeks ago
> php-PHP-CSS-Parser orphan 3 weeks ago
> plasma-bigscreen @kde-sig, orphan 0 weeks ago
> python-GridDataFormats @scitech_sig, orphan 3 weeks ago
> python-compressed-rtf orphan 4 weeks ago
> python-extractcode @python-packagers-sig, orphan 0 weeks ago
> python-flit @epel-packagers-sig, @python- 0 weeks ago
> packagers-sig, orphan, salimma
> python-jupyter-collaboration orphan 2 weeks ago
> python-jupyter-server-fileid orphan 2 weeks ago
> python-jupyter-ydoc orphan 2 weeks ago
> python-kaitaistruct orphan 3 weeks ago
> python-maya @neuro-sig, orphan 5 weeks ago
> python-mmtf @scitech_sig, orphan 3 weeks ago
> python-mrcfile orphan 3 weeks ago
> python-red-black-tree-mod orphan 4 weeks ago
> python-represent orphan 0 weeks ago
> python-y-py @python-packagers-sig, orphan 2 weeks ago
> python-ypy-websocket orphan 2 weeks ago
> qterm orphan 4 weeks ago
> rubygem-hrx jcpunk, orphan, tdawson 5 weeks ago
> rubygem-linked-list jcpunk, orphan, tdawson 5 weeks ago
> rubygem-rubygems-mirror @ruby-packagers-sig, orphan 1 weeks ago
> rust-lib0 @rust-sig, orphan 2 weeks ago
> rust-yrs @rust-sig, orphan 2 weeks ago
> scamp @astro-sig, orphan 4 weeks ago
> sphinxbase @epel-packagers-sig, orphan 0 weeks ago
> tachyon @scitech_sig, orphan 3 weeks ago
> virtme orphan 3 weeks ago
> xdrawchem @scitech_sig, orphan 3 weeks ago
>
I have taken scamp and cdsclient
Regards
3 months, 3 weeks