Re: Files missing in RPM database
> I tried to find out which files on my upgraded fc40 installation are not > installed via dnf/rpm. > The list is surprisingly long. > Main reasons are symlinks and directories not defined in the spec file. > A quick check shows that this is also the case with a fresh installation. > > I see three reason for having this clean: > *) Knowing which files comes from installations outside dnf/rpm. >Maybe this is security related? > *) Making some kind of clever backup >(list of RPMs and only additional/changed files) > *) Removal or Upgrade of RPMs/distribution should not left files behind. > > Should this be (slowly) cleaned up or do I see this too strict? I agree with all of your reasons. This clean up process has been going on since Fedora 1. For two early examples, see: https://bugzilla.redhat.com/show_bug.cgi?id=117163 https://bugzilla.redhat.com/show_bug.cgi?id=164498 I don't recall an organized effort at this; perhaps someone else will. -- Mike :wq -- ___ 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: 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 getting the "kernel version list is not available" error when a package listed in my kickstart is not available. I encountered this when trying to install Fedora 39 directly on x86_64 hardware. My bug was #2264240, but I recently concluded the problem was the same as Orion's #2238045. -- Mike :wq -- ___ 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
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: 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: 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 https://koji.fedoraproject.org? > the package (and its build enviroment) has grown. It fails because > 32-bit system means max 4GB of address space for a process and ld runs > as a single process, so it's not uncommon to use all memory for large > C++ projects. Thank you, Dan, for the quick response! It had not occurred to me that the build might be hitting the architectural limit, rather than some lower limit the build system placed on the VM. I decided to disable the i686 build. -- Mike :wq -- ___ 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
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 https://koji.fedoraproject.org? [...] libtool: link: g++ -Wl,--as-needed -std=c++17 -fno-exceptions -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/i686-redhat-linux/14/../../../crti.o /usr/lib/gcc/i686-redhat-linux/14/crtbeginS.o .libs/ngram-absolute.o .libs/ngram-context.o .libs/ngram-count.o .libs/ngram-count-prune.o .libs/ngram-input.o .libs/ngram-kneser-ney.o .libs/ngram-list-prune.o .libs/ngram-make.o .libs/ngram-marginalize.o .libs/ngram-output.o .libs/ngram-shrink.o .libs/util.o -ldl -L/usr/lib/fst -lfst -lgsl -lflexiblas -L/usr/lib/gcc/i686-redhat-linux/14 -L/usr/lib/gcc/i686-redhat-linux/14/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-redhat-linux/14/crtendS.o /usr/lib/gcc/i686-redhat-linux/14/../../../crtn.o -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -flto=auto -g -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,pack-relative-relocs -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,-rpath=/usr/lib/fst -Wl,-soname -Wl,libngram.so.1315 -o .libs/libngram.so.1315.0.0 libtool: link: (cd ".libs" && rm -f "libngram.so.1315" && ln -s "libngram.so.1315.0.0" "libngram.so.1315") libtool: link: (cd ".libs" && rm -f "libngram.so" && ln -s "libngram.so.1315.0.0" "libngram.so") libtool: link: ( cd ".libs" && rm -f "libngram.la" && ln -s "../libngram.la" "libngram.la" ) virtual memory exhausted: Cannot allocate memory [...] https://koji.fedoraproject.org/koji/taskinfo?taskID=113388137 -- Mike :wq -- ___ 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
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 various cloud-provider packages, each of which are fine-grained, difficult to navigate in GitHub, and hard to maintain due to volumes of dependencies. Others have commented on this, both for Go and other languages; see, for example: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/U27BIXM34W52TVUV327XJHD5BRTLZMXM/ and https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/64Q5UZHNFSF6U3CZWKJ72PCQ7NJMCQSZ/#XQM2PG7QKV3TJ4E5X23CVATDN5DPDLFB and https://bugzilla.redhat.com/show_bug.cgi?id=2224119 Does anyone have the will to tackle golang-gocloud and its dependencies? -- Mike :wq -- ___ 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: 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, then when that finishes a long time later, a new ticket is > filed instead of updating the old one. ;( Sorry about that. I learned of my mistake from the comments the crew left therein! > We are also working on automating unretirements... hopefully that will land > soon and you will not need to wait on a manual process anymore. This would be a big deal, thank you! I have been patiently working through 14 Go packages with intermingled dependencies and it is slow going. Speeding up the unretirements and instead waiting only on the reviews would speed things up a lot. -- Mike :wq -- ___ 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
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 before reviewing package Y, which depends on X. After getting through seven Go packages, the following remain waiting for review: golang-github-tj-kinesis: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256315 golang-github-tj-elastic: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256314 golang-github-bep-logg: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256309 golang-github-aphistic-sweet: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256306 golang-github-aphistic-golf: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256305 golang-github-apex-log: https://bugzilla.redhat.com/show_bug.cgi?id=2256303 All of this effort aims at allowing me to package the latest version of Hugo, which adds dependencies faster than I can get them through package approval! [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256304 -- Mike :wq -- ___ 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
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 -- ___ 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
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 orphan sphinxbase soon unless someone indicates I should not. -- Mike :wq -- ___ 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
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 bug upstream: https://github.com/unicorn-engine/unicorn/issues/1840 It seems that Ubuntu's package does build on s390x, but I do not see any patches in their package description that might describe why theirs builds and ours does not: https://packages.ubuntu.com/mantic/libunicorn-dev This leaves me wondering if our s390x build host lacks features present in the Ubuntu one. I know little about s390x, so this is a stab in the dark. Does anyone with s390x experience know what might be going on? -- Mike :wq -- ___ 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
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 use help with two things: (1) package reviewing and (2) help with two of the packages. The following are available for review now: jakarta-commons-httpclient: https://bugzilla.redhat.com/show_bug.cgi?id=2232859 jmdns: https://bugzilla.redhat.com/show_bug.cgi?id=2232860 jsemver: https://bugzilla.redhat.com/show_bug.cgi?id=2232861 python-uranium-lulzbot: https://bugzilla.redhat.com/show_bug.cgi?id=2232862 libarcus-lulzbot: https://bugzilla.redhat.com/show_bug.cgi?id=2232864 CuraEngine-lulzbot: https://bugzilla.redhat.com/show_bug.cgi?id=2232865 cura-lulzbot: https://bugzilla.redhat.com/show_bug.cgi?id=2232866 The dependencies led me to create a COPR repository to aid in the review process: [copr:copr.fedorainfracloud.org:mikep:lulzbot] name=Copr repo for lulzbot owned by mikep baseurl=https://download.copr.fedorainfracloud.org/results/mikep/lulzbot/fedora-$releasever-$basearch/ type=rpm-md skip_if_unavailable=True gpgcheck=1 gpgkey=https://download.copr.fedorainfracloud.org/results/mikep/lulzbot/pubkey.gpg repo_gpgcheck=0 enabled=1 enabled_metadata=1 I could use help with two of the packages: arduino and lulzbot-marlin-firmware. To get the arduino package to build and install, I had to remove some dependencies. First, arduino-builder is deprecated. Does someone know Arduino enough to know if I need to replace this with arduino-cli? (And how?) Second, I removed the dependency on asm2, which I found used deprecated RPM macros such as %add_to_maven_depmap. Could someone take a look at that retired package and suggest how to modernize it towards the newer macros? The lulzbot-marlin-firmware does not build. The build fails with: /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: cannot find ../ArduinoAddons/arduino-1.8.5/packages/ultimachine/hardware/sam/1.6.9-b/variants/archim/libsam_sam3x8e_gcc_rel.a: No such file or directory Does anyone know where libsam_sam3x8e_gcc_rel.a is supposed to come from? [1] https://lulzbot.com/learn/cura-lulzbot-edition-installation-fedora -- Mike :wq ___ 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
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 -- 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
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 golang-gocloud golang-github-azure-amqp-common golang-github-azure-service-bus golang-github-devigned-tab golang-github-shogo82148-shuffle golang-gopkg-neurosnap-sentences-1 golang-gopkg-pipe-2 golang-nhooyr-websocket I am interested in these packages because my Hugo package depends on them. -- Mike :wq ___ 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
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 https://bugzilla.redhat.com/show_bug.cgi?id=2031239 https://bugzilla.redhat.com/show_bug.cgi?id=2031582 https://bugzilla.redhat.com/show_bug.cgi?id=2031583 https://bugzilla.redhat.com/show_bug.cgi?id=2031584 https://bugzilla.redhat.com/show_bug.cgi?id=2031585 https://bugzilla.redhat.com/show_bug.cgi?id=2060710 https://bugzilla.redhat.com/show_bug.cgi?id=2060711 Additionally, I submitted a pull request for golang-github-frankban-quicktest, which is also required by Hugo: https://src.fedoraproject.org/rpms/golang-github-frankban-quicktest/pull-request/1 Would anyone be interested in reviewing these? This is all summarized at: https://bugzilla.redhat.com/show_bug.cgi?id=1930952 -- Mike :wq ___ 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
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 with the release of 4.7.0. -- Mike :wq ___ 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: 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. A better way of documenting this might also be helpful, and would guide paring down the default services. I like much of the GNOME desktop, but I prefer Awesome to GNOME's window manager construct. Sometimes I find it difficult to piece together the services I need (e.g., to support Bluetooth or the ability to run gnome-control-center) while replacing other GNOME parts with Awesome. As with Hans, I happily acknowledge that I am not the common use case. I just think that there might be ways to make things feel a little more modular. -- Mike :wq ___ 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: 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 happy to provide any information necessary to fix this SELinux issue too. -- Mike :wq ___ 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
/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 keyboard and mouse input from software with no other special privileges. My logic is that a user with physical access to the keyboard and mouse ought to be able to inject events through software. Am I missing something? Could something like this be made the default? SELinux could still restrict software at risk of being compromised. -- Mike :wq ___ 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
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 -- 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
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 deprecated and orphanded. The new beta version of pwntools supports Python 3: https://github.com/Gallopsled/pwntools/blob/4.0.0beta0/CHANGELOG.md Here is the new review request: https://bugzilla.redhat.com/show_bug.cgi?id=1785495 -- Mike :wq ___ 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
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 Here is the new review request: https://bugzilla.redhat.com/show_bug.cgi?id=1761236 -- Mike :wq ___ 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: 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 acknowledge that mandatory testing often goes unperformed. The Fedora Xen mailing list is exceedingly low-volume. Michael Young has in the past done a lot of the heavy lifting surrounding Xen support, and I am very grateful for his work. Xen Dom0 is particularly tenuous. Dropping (for a good reason) GRUB's multiboot2 module left Xen unable to boot under EFI [e.g., 1]. All of that said, there are good reasons to choose Xen over KVM. Xen's architecture and full support for libvmi come to mind. (Of course, there are good reasons to choose KVM too.) Perhaps we could go one more release with the status quo to give the Xen/Fedora community a last chance to rally and demonstrate a willingness to perform the necessary testing and maintenance. I suspect we are all quite busy, so we might find ourselves admitting that broader Xen support will be relegated to the standard means of maintenance rather than rising to the status of blockers. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1703872 -- Mike :wq ___ 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
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 necessary for building models for the CMU Sphinx Recognizer. cmusphinx3, CMU's state-of-the-art large vocabulary speech recognition system. The latter two packages will likely need to be updated to newer upstream versions which are compatible with sphinxbase. This will involve discarding or updating a few of the patches used to build the packages. I updated sphinxbase to 5prealpha last August. Here are the outstanding bug reports related to these: https://bugzilla.redhat.com/show_bug.cgi?id=1630840, phinxtrain: Remove (sub)packages from Fedora 30+: python2-sphinxtrain https://bugzilla.redhat.com/show_bug.cgi?id=1630836, cmusphinx3: Remove (sub)packages from Fedora 30+: python2-cmusphinx3 https://bugzilla.redhat.com/show_bug.cgi?id=1676022, sphinxtrain: FTBFS in Fedora rawhide/f30 https://bugzilla.redhat.com/show_bug.cgi?id=1674747, cmusphinx3: FTBFS in Fedora rawhide/f30 https://bugzilla.redhat.com/show_bug.cgi?id=1637176, sphinxtrain not installable in F29 or Rawhide -- Mike :wq ___ 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-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 up to > them. And if they wanted to keep it going, hand off maintenance to them. > Haven't asked yet though I occasionally find the Xen list very useful, mainly because Michael Young is so helpful. For this reason, the Xen list has in the past been a good place to bring up issues that arise as Fedora and Xen are updated. -- Mike :wq -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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 kernel module. I would like to build RPMs because they are convenient to install, and they manage the kernel configuration for me. Put another way, I would like for practical reasons to track the Fedora kernel source RPMs as opposed to the upstream kernel tree. (This will eventually change, but not yet.) However, building RPMs results in a full build each time, slowing down the development cycle. I thought that I could speed this up using rpmbuild's --short-circuit. My idea was to perform an "rpmbuild -bp" once, apply my own changes to the build tree, and then on each compile run "rpmbuild -bc", "-bi", and "-bb". The problem is that the RPM build runs "make mrproper" as part of the %build target. Does anyone know of a good work flow for developing custom kernel code on Fedora in a convenient way? The next best thing I could come up with is to recreate much of the kernel RPM's %build target without the "make mrproper" and other troublesome parts. But this sort of duplicates things that I would rather dynamically track by making use of each kernel RPM. Thank you, -- Mike :wq -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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 package specification (see below). I can build Graylog2 by hand using Maven, but of course this downloads the requisite files to ~/.m2. There is also at least one case of a package in Fedora which is incompatible with the API version Graylog2 expects (okhttp). Isn't this API-versioning mess common in Java? I vaguely recall there are a number of tools to help manage this. How does Fedora expect package managers to deal with this? Is there a way to include these JAR files in the package, or is it necessary to get each of these included as a Fedora package? org.apache.shiro:shiro-core:1.2.3 required by org.graylog2:graylog2-server org.graylog2:syslog4j:0.9.53 required by org.graylog2:graylog2-inputs com.atlassian.ip:atlassian-ip:3.1 required by org.graylog2:graylog2-server org.graylog2:gelfclient:1.2.0 required by org.graylog2:graylog2-server com.github.rholder:guava-retrying:1.0.7 required by org.graylog2:graylog2-server org.apache.kafka:kafka_2.9.2:0.8.1.1 required by org.graylog2:graylog2-radio org.msgpack:msgpack:0.6.11 required by org.graylog2:graylog2-radio io.netty:netty:3.9.8.Final required by org.graylog2:graylog2-shared com.squareup.okhttp:okhttp:2.4.0 required by org.graylog2:graylog2-radio org.graylog2.repackaged:grok:0.1.2-graylog required by org.graylog2:graylog2-server com.typesafe.play:play-cache_2.10:2.3.9 required by org.graylog2:graylog2-rest-client com.rabbitmq:amqp-client:3.5.1 required by org.graylog2:graylog2-radio org.kie:kie-api:6.2.0.Final required by org.graylog2:graylog2-server org.graylog2:jersey-netty:1.5.1 required by org.graylog2:graylog2-radio com.github.joschi:jadconfig:0.11.0 required by org.graylog2:graylog2-radio me.bazhenov.groovy-shell:groovy-shell-server:1.5 required by org.graylog2:graylog2-shared io.dropwizard.metrics:metrics-core:3.1.2 required by org.graylog2:graylog2-radio org.glassfish.hk2.external:javax.inject:2.4.0-b10 required by org.graylog2:graylog2-radio org.mongojack:mongojack:2.3.0 required by org.graylog2:graylog2-server io.dropwizard.metrics:metrics-annotation:3.1.2 required by org.graylog2:graylog2-radio com.sun.jersey:jersey-bundle:1.18.1 required by org.graylog2:graylog2-rest-client org.apache.directory.api:api-all:1.0.0-M29 required by org.graylog2:graylog2-server com.fasterxml.jackson.datatype:jackson-datatype-joda:2.5.3 required by org.graylog2:graylog2-server org.hdrhistogram:HdrHistogram:2.1.4 required by org.graylog2:graylog2-shared com.wordnik:swagger-annotations:1.3.11 required by org.graylog2:graylog2-server com.joestelmach:natty:0.11 required by org.graylog2:graylog2-server com.eaio.uuid:uuid:3.2 required by org.graylog2:graylog2-server com.floreysoft:jmte:3.1.1 required by org.graylog2:graylog2-server com.typesafe.play:play-java_2.10:2.3.9 required by org.graylog2:graylog2-rest-client com.ning:async-http-client:1.8.14 required by org.graylog2:graylog2-rest-client org.drools:drools-compiler:6.2.0.Final required by org.graylog2:graylog2-server io.dropwizard.metrics:metrics-jvm:3.1.2 required by org.graylog2:graylog2-shared io.dropwizard.metrics:metrics-log4j:3.1.2 required by org.graylog2:graylog2-radio io.dropwizard.metrics:metrics-json:3.1.2 required by org.graylog2:graylog2-shared -- Mike :wq -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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: > > https://bugzilla.redhat.com/show_bug.cgi?id=728775 The Fedora update system reports this is fixed in grub2-1.99-6.fc16. > https://bugzilla.redhat.com/show_bug.cgi?id=658387 Peter Jones submitted a new grubby package yesterday. This seems to fix bug #658387 (i.e., new-kernel-pkg creates a Dom0-style grub.cfg entry if /etc/sysconfig/kernel contains "HYPERVISOR=/boot/xen.gz"). I have not yet tested this on Fedora 16. However, I did test on Fedora 15. In this case, bug #668063 is still in effect. That is, grubby creates most of a GRUB record, but the "module initramfs-..." entry is missing. Has anyone yet tested this new grubby package on Fedora 16 yet? Does using GRUB 2 makes #668063 irrelevant? > https://bugzilla.redhat.com/show_bug.cgi?id=668063 I just added some more description to this bug. -- Mike :wq -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 different properties than KVM, et al. One of the integration points we'd like to improve has to do with grubby. As it is hypervisor-based, Xen requires grub to be configured a little differently than bare-metal Linux. In summary, where bare-metal Linux needs: kernel /boot/vmlinuz-... initrd /boot/initramgs-... Xen requires: kernel /boot/xen.gz module /boot/vmlinuz-... module /boot/initramfs-... There are two bugs in Bugzilla related to this: 658387, Patch to allow mbkernel and mbargs to be read from /etc/sysconfig/kernel 668063, Grubby does not handle "template" that uses module keyword properly Is anyone who is a grubby contributor interested in adding these features to grubby to support the XenPvopsDom0 feature? I've provided a patch in bug #658387. Thanks, -- Mike :wq -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 self-contained simulator that runs MIPS32 programs. It reads and executes assembly language programs written for this processor. spim also provides a simple debugger and minimal set of operating system services. -- Spec URL: http://www.flyn.org/SRPMS/gnupg-pkcs11-scd.spec SRPM URL: http://www.flyn.org/SRPMS/gnupg-pkcs11-scd-0.7.2-1.fc15.src.rpm gnupg-pkcs11-scd is a drop-in replacement for the smart-card daemon (scd) shipped with the next-generation GnuPG (gnupg2). The daemon interfaces with smart-cards by using RSA Security Inc.'s PKCS#11 Cryptographic Token Interface. This package allows the use of US DoD smart cards (CAC) with GnuPG. -- Thanks, -- Mike :wq -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 thumbnail images and read existing thumbnails from EXIF metadata. -- Mike :wq -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
