Re: Announce: Log Detective - AI tool to analyze build logs failures
On Wed, Jan 17, 2024 at 12:34 Jiri Kyjovsky wrote: > 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 Hello, I'm building a similar project named logjuicer using the following dataset for evaluation: https://github.com/logjuicer/logjuicer-tests How do you store the collected data and is there a schema/library to access it? Cheers, -Tristan signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 37 Boost 1.78 rebuilds starting in a side tag
On Thu, May 05, 2022 at 10:46 Miro Hrončok wrote: > supercollider > CMake Warning: >Ignoring extra path from command line: > "/builddir/build/BUILD/SuperCollider-3.12.2-Source" > CMake Error: The source directory > "/builddir/build/BUILD/SuperCollider-3.12.2-Source/build" does not appear to > contain CMakeLists.txt. > This should be fixed now (had to removed the `mkdir build; pushd build; ...`) for the new cmake macro. Thanks, -Tristan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pagure pull-request email workflow
On Tue, Jul 21, 2020 at 12:25 Tom Hughes via devel wrote: > On 21/07/2020 11:56, Mark Wielaard wrote: > >> Do you have to handle them on that pagure website? Is it possible to >> handle these pull-request through email? Or is there a normal (git) >> command line interface for these? > > Pagure supports the same pull heads are things like github > so yes you can just fetch them and merge them in your local > fepdkg checkout if you want. > > I normally just edit .git/config and add to the origin remote > an extra fetch: > > fetch = +refs/pull/*/head:refs/remotes/origin/pull/* > > then after fetching you can merge origin/pull/NNN. > Also if your project is configured to use Zuul[0], then you can set the `gateit` tag to get the PR merged by CI. [0]: https://fedoraproject.org/wiki/Zuul-based-ci -Tristan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Inactive maintainer - dmsimard
On Mon, Jun 08, 2020 at 09:03 Igor Raits wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Anybody knows new contact of David Moreau Simard ? > Seems that email is not active anymore. Hi Igor, you can join David at m...@dmsimard.com . -Tristan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Defining the future of the packager workflow in Fedora
On Thu, Sep 26, 2019 at 15:49 Pierre-Yves Chibon wrote: > On Thu, Sep 26, 2019 at 03:40:49PM +0200, Miroslav Suchý wrote: >> Dne 26. 09. 19 v 15:10 Pierre-Yves Chibon napsal(a): >> > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote: >> > > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit : >> > > > Here is what the vision we came to and that we would like to discuss: >> > > > >> > > > ○ Every changes to dist-git is done via pull-requests >> > > IMHO Have to stay optional, making this mandatory being a terrible >> > > headache. >> > What makes it a headache? What can we do to not have this be a terrible >> > headache? >> >> I use PRs in Pagure a lot. And the Rebase/Merge functionality is broken most >> of the time. For months. >> Fortunately it is still a git, so when the team agrees, we can merge and >> push PR manually. >> Having PR a mandatory thing (relying on Pagure to do the merge) would be >> PITA for me. > > You'll notice I didn't mention any tools in the proposal. I specifically > didn't > want to limit ourself to our current tooling :) > Before we discuss how we want to implement something let's see if we can agree > on what that thing is :) > Note that git-pull-requests now support pagure. The tool takes care of creating the fork, pushing the local changes and opening the PR: https://github.com/Mergifyio/git-pull-request Regards, -Tristan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Join the new Minimization Team
On Tue, Aug 27, 2019 at 01:22 John Harris wrote: [snip] > No online updates is the exact issue I see with this. That's a security > nightmare. > > If you don't have a package manager there, it simply will not be updated. > It'll be installed once, then either left there forever, un-updated, with > tons > of vulnerabilities piling up. > IIUC the proposal from Christian to use rpm-ostree as a build stage to produce the runtime container, then you can still do online update, but instead of commiting the result of a dnf update, you commit a new rpm-ostree composed rootfs. Regards, -Tristan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Join the new Minimization Team
On Wed, Aug 21, 2019 at 09:13 Colin Walters wrote: > On Wed, Aug 21, 2019, at 7:34 AM, Daniel Walsh wrote: > >> I agree. Entering a container and doing a yum update is an >> Anti-pattern. > > This is a complex discussion - I think we need both. Personally I > live inside a "pet" container using https://github.com/cgwalters/coretoolbox > and I definitely `yum update` inside there, though I do also periodically > destroy it and re-pull. > I also run yum to keep my local runtime updated and I even suggested a new buildah commit option to make this more efficient: https://github.com/containers/buildah/issues/1778 Though this is useful for devel or traditional workstation use-case. It seems like a fedora image should come with the package manager, but perhaps it should only be used as a build stage using an option similar to the --installroot option? Regards, -Tristan > Kubernetes though for sure is about non-pet containers. > >> Buildah and Multi-Stage builds do allow you to eliminate >> these tools, but that is more difficult to do. > > multi-stage is easy and obvious for the case of e.g. Golang and Rust single > compiled binaries, and it's not too hard to do for other compiled languages > (C/C++) as long as you have a notion of `BuildRequires` versus `Requires`. > For interpreted languages though, yeah, not as worthwhile unless you're > pulling in a *lot* of build dependencies (doc tooling?) distinct from your > runtime ones. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Projects in Copr @ discussion.f.o
On Fri, Aug 16, 2019 at 13:31 Miroslav Suchý wrote: > Hi, > I want to soon enable embedded discussion on Copr projects pages. I created: > https://discussion.fedoraproject.org/c/projects-in-copr > There is one downside thou - if you enabled > Preferences -> Emails -> Enable mailing list mode > (which BTW discouraged by Discourse devels) then you are likely receiving a > lots of emails about creating new topics in > this category. > There are two solutions available: > 1) turn off Mailing list mode (or create mail filter) or > 2) go to > https://discussion.fedoraproject.org/c/projects-in-copr > in upper right corner, click on the circle and select "Muted" > This also appears in the "New" link on the discuss top menu. Could the projecs-in-copr be muted by default? Thanks, -Tristan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to consume fedora-messaging?
On Mon, Jun 10, 2019 at 01:24 Igor Gnatenko wrote: > Hello, > > I have been trying to write some script which would listen on > generation of new repository / successful build is tagged in Koji and > do some actions locally. Or basically whenever someone pushes commits, > I want to fetch repo locally. > > I was reading > https://fedora-messaging.readthedocs.io/en/latest/consuming.html, > but it is not very clear to me where I can find list of topics and > what data messages will contain... > Hi Igor, you can find the list of topics and their associated schema here: https://fedora-fedmsg.readthedocs.io/en/latest/topics.html And you can also find samples on this website: https://apps.fedoraproject.org/datagrepper/raw > Bonus point who can tell me how does it know which messages should be > re-queued and how to manipulate that. > It doesn't seems like you have to worry about re-queue when consuming the bus. Regards, -Tristan signature.asc Description: PGP signature ___ 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
python-os-client-config (was Re: Orphaned packages need new maintainers (will be retired in 3 weeks))
On November 30, 2018 1:15 pm, 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, please do so now with a proper > reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life [...] > Affected (co)maintainers: [...] > tdecacqu: python-os-client-config > Thanks Miro for the notice. Not sure how I ended up as (co-)maintainer of python-os-client-config, but it seems like we could remove the package. It has been merged into the openstacksdk project and it is no longer used by most of the openstack projects: http://codesearch.openstack.org/?q=os-client-config=nope=requirements.txt= Regards, -Tristan pgpZR9ywj5oge.pgp Description: PGP signature ___ 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
Self Introduction: Tristan Cacqueray
Dear folks, I've submitted a request for review at https://bugzilla.redhat.com/show_bug.cgi?id=1214840 and I guess this deserve some extra informations... My work nowadays is mostly focused on the OpenStack project, in particular on the security and infrastructure aspect of the beast. And it's the latter that brings me here, as I'd like to see the awesome tools used to manage OpenStack infrastructure be available for fedora user. Long story short, Zuul and Nodepool depends on python-statsd and the requests for review should contains the required things to get that package in the fedora repos. Please let me know if it needs something else. Cheers, Tristan signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
