Re: Virtualization Test Day for F16 and Xen

There are known bugs in FC15/FC16 that have been filled some time ago that folks will sadly run into: 728775, 658387 and 668063 Fortunatly the bugs have patches attached and the files to be modified are shell scripts. Yep, links here:

Updated VIPS available

I am interested in seeing Bugzilla #676945, VIPS package is out of date, addressed before Fedora 15 is released. The reason for my interest is that one of my packages, dmapd, requires the new version of VIPS. The new VIPS provides additional functionality that can be used to efficiently create

Review request/swap: gnupg-pkcs11-scd and spim

I have two packages that need to be reviewed. I'd be willing to review two others in exchange. -- Spec URL: http://www.flyn.org/SRPMS/spim.spec SRPM URL: http://www.flyn.org/SRPMS/spim-9.0.5-1.fc14.src.rpm spim is a

Grubby and Xen

I have been working with a few other Fedora contributors on the Fedora 16 feature XenPvopsDom0, http://fedoraproject.org/wiki/Features/XenPvopsDom0. This feature would provide a robust virtualization alternative based on Xen. Xen is a type-1, hypervisor-based platform and therefore has some

Packaging Graylog2/unpackaged jar dependencies

I am interested in packaging the Graylog2 log analysis platform for Fedora. I have created a number of Fedora packages in the past, but I am a novice when it comes to packaging Java. When I try to build my Graylog2 package, rpmbuild warns me that a number of dependencies are missing from the

Kernel development on Fedora

I am interested in doing some kernel development on Fedora. I am familiar with kernel internals, but I am looking for some tips to help manage the build, compile, and install cycle. Unfortunately, I am developing against the Linux Security Module interface, so my work cannot take the form of a

Re: [fedora-virt] Do we need the Fedora 'virt' mailing list?

>>> One week - do you want to close the list or should I? Dan suggested a >>> method to use here: >>> >>> https://lists.fedoraproject.org/pipermail/virt/2015-September/004295.html >> >> The xen@ one should probably go too. > There's a few xen devs on that mailing list, I figured I'd leave it

Orphaned: sphinxbase, sphinxtrain, and cmusphinx3

I have orphaned three projects, and thus they need a new maintainer: sphinxbase, a common library for CMU Sphinx voice recognition products. sphinxtrain, Carnegie Mellon University's open source acoustic model trainer. It contains the scripts and instructions

Re: Xen / EC2 release criteria proposal

> "The release must boot successfully as Xen DomU with releases providing > a functional, supported Xen Dom0 and widely used cloud providers > utilizing Xen." I am a long time Xen/Fedora user. In fact, I rely on Fedora as my Dom0. I acknowledge that there are not too many of us, and I further

Claim ownership of retired festival package

I would like to take ownership of the festival packages, which was recently retired: https://bugzilla.redhat.com/show_bug.cgi?id=1674883 I had already been working on updating the Festival package to a much newer version: https://bugzilla.redhat.com/show_bug.cgi?id=1457878

Claim ownership of retired pwntools package

I would like to (re)take ownership of the pwntools package that was recently retired: https://bugzilla.redhat.com/show_bug.cgi?id=1701958 Fedora retired the package because pwntools had for some time not supported Python 3. Some of the Python 2 packages on which it depended had themselves been

Take over maintenance of Hugo package

I would like to co-maintain or take over the maintenance of our Hugo package. The package presently does not build, and thus it is at risk of being orphaned: https://bugzilla.redhat.com/show_bug.cgi?id=1799514 -- Mike :wq ___ devel mailing list --

/dev/uinput

/dev/uinput presently bears the permissions 0600, and it is owned by root. Has anyone ever thought about assigning ownership of /dev/uinput to the user associated with the console? It seems it might be appropriate for pam_console to transfer ownership in this way. I am interested in injecting

Re: Xen support dead?

Another Xen-related bug that has continued through a number of releases has to do with the interaction between Xen and SELinux. The SELinux policy prevents xenstored from functioning. See https://bugzilla.redhat.com/show_bug.cgi?id=1720309. I am glad to see movement on BZ #1858364, and I am

Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

> Given that I can halve the base processes RAM set with some hacks I > think that it is fair to say that there are still way too much things > starting by default. > > I have actually been considering doing a Fedora workstation light spin > for budget x86 machines with 1G / 2G of RAM and an eMMC.

Review swap: python-colored-traceback

I have proposed a python-colored-traceback package at: https://bugzilla.redhat.com/show_bug.cgi?id=2033730 Would anyone like to do a review swap? I am anxious to get python-colored-traceback reviewed, because the existing python-pwntools package will require python-colored-traceback

Review request: Go packages required by Hugo

I would like to update Fedora's Hugo package, but the recent versions depend on Go packages not yet in Fedora. I have submitted review requests for each of these: https://bugzilla.redhat.com/show_bug.cgi?id=1998878 https://bugzilla.redhat.com/show_bug.cgi?id=2031226

Packaging software for LulzBot Taz-6 3D printer

I am trying to package the software necessary to operate the LulzBot Taz-6 3D printer. This seems to have been supported in previous versions of Fedora [1], so I am trying to take ownership of retired packages. Some of the dependencies should be broadly useful, like the arduino package. I could

Ownership of Go packages

I would like to take ownership of the following Go packages, which releng recently orphaned: golang-github-bep-godartsass golang-github-disintegration-gift golang-github-evanw-esbuild golang-github-evanw-esbuild-0.8.20 golang-github-getkin-kin-openapi golang-github-rwcarlsen-goexif

Orphaned libdmapsharing

I orphaned the libdmapsharing package. All of the F38 and Rawhide packages that depended on libdmapsharing have moved on to libdmapsharing4. I recommend allowing libdmapsharing to retire in favor of libdmapsharing4. -- Mike :wq ___ devel mailing list

Orphaning golang-github-apache-arrow

I have decided to orphan golang-github-apache-arrow. -- Mike :wq -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Orphaning golang-gocloud

In order to preserve my energy as I maintain hugo and its multitude of Go dependencies, I have decided to deactivate Hugo's deploy feature. This means I can drop the need for golang-gocloud, which I will also orphan. The golang-gocloud package has been hard to maintain for some time. It relies on

Re: Koji: virtual memory exhausted: Cannot allocate memory

>> Building the current version of my opengrm-ngram package on Koji fails >> with the error "virtual memory exhausted: Cannot allocate memory" >> as indicated below. This happens only for i686; all of the other >> architectures build. Is this the fault of my package, or did something >> change at

Koji: virtual memory exhausted: Cannot allocate memory

Building the current version of my opengrm-ngram package on Koji fails with the error "virtual memory exhausted: Cannot allocate memory" as indicated below. This happens only for i686; all of the other architectures build. Is this the fault of my package, or did something change at

unicorn on s390x

I maintain Fedora's unicorn package. This package will not presently build on s390x, and I am not certain why. The problem seems to have to do with 128-bit instructions. I have a tracker bug in Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2223039 I have also added some commentary to a

Re: Unretire request idle and Go packages working through approval

> IMHO, it's helpfull if you don't open an unretirement request releng > ticket until the package has been re-reviewed (if needed). Trying to > keep track of old tickets waiting for reviews to finish is not a good > workflow. It also results in people filing a ticket, told to do the > re-review,

Orphan sphinxbase?

It looks like I should orphan sphinxbase. The upstream project indicates pocketsphinx has subsumed sphinxbase, and it does not appear any other Fedora packages rely on sphinxbase. I dropped pocketsphinx's dependency on sphinxbase when I released version 5.0.0 of the package in May of 2023. I will

Orphaning libdmapsharing

I am going to orphan libdmapsharing. All dependent Fedora packages have moved to libdmapsharing4, which represents the next API. Libdmapsharing4 links against libsoup3, but libdmapsharing does not. Libdmapsharing4 is under active development, but libdmapsharing is not. -- Mike :wq --

Unretire request idle and Go packages working through approval

I would like to unretire golang-github-apex-logs, and Mikel Olasagasti Uranga was kind enough to review and approve my review request [1]. The unretire request has been idle for a while: https://pagure.io/releng/issue/11880 I believe Mikel has been waiting for each package X to hit Rawhide

Re: Kickstart install of Rawhide fails

>>> Anyone else hitting this? >> >> Yes, someone else is, when installing in VirtualBox: >> https://bugzilla.redhat.com/show_bug.cgi?id=2244744 >> >> It's confusing, isn't it? Are you using VirtualBox? > > No - libvirt kvm on EL7 host. Thanks for the bug link, I've chimed in > there. I too am