devel May 2020

devel@lists.fedoraproject.org

246 participants
393 discussions

Re: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)
by Bruno Wolff III 22 May '20

22 May '20

Copying me directory was a good idea to get my attention. Fedora list mail goes to another folder and it is easy for me to miss stuff, though I was planning to double check this thread for objections before doing a retire. On Thu, May 21, 2020 at 18:46:14 -0400, Dennis Payne <dulsi(a)identicalsoftware.com> wrote: >The reason for the crashing on startup is that it is not loading the >font. > >/usr/games/vultureseye/fonts/VeraSe.ttf -> /usr/share/fonts/bitstream- >vera/VeraSe.ttf > >/usr/share/fonts/bitstream-vera/VeraSe.ttf does not exist. > >/usr/share/fonts/bitstream-vera-serif-fonts/VeraSe.ttf Thanks for doing this. I wasn't sure how to get to specific threads in gdb and wasn't sure what the error was. I fixed this issue for several other games and can do it for nethack-vulture pretty easily now that I know what the problem is. > >Updating the link allows it to start. I'm against losing games. So I'd >rather keep the current version at the moment. When I get a chance I'll >look into new versions of the program. I'm against losing games as well, but don't find the time to do as good a job on the ones I maintain, as I should. Even getting Vulture's Eye up to 3.67 is going to take more work than I can commit to any time soon. That uses a pretty old version of nethack. While it will likely never be up to date again, since Vulture's Eye upstream looks like it might be dead now, it would be nice to get it closer. I found some indications the game was commercialized on Steam and was probably getting updates as recently as 2017. The code license would allow anyone who had gotten a binary to get source, but the developer wasn't making it generally available. I'm not even sure I can find my 3.67 copy any more. And I have not seen any mention of anyone providing source later than that. If you want to be added as a co-maintainer or take over the package, I'm fine with that. A decision should be made before f33 branches, if there is enough interest to keep it around in spite of its support shortcommings. I'll get the font issue fixed and do new builds for f31, f32 and rawhide. It's a sort of generic fix to work around problems caused by a change in f32's font packaging. A temporary fix was added for f32, but is not going to be kept for f33. The idea is for a simple rebuild to be able to deal with changes in font paths. I'll look harder to see if I can get a copy of 3.67. It isn't available any more from where I got it and I may have lost the copy I had downloaded to evalute a number of years ago.

1 3

Retiring nodejs-marked
by Jared K. Smith 22 May '20

22 May '20

I retired nodejs-marked yesterday, as it was a duplicate of the "marked" package, which wasn't caught at the time I packaged it. -- Jared Smith

1 0

glassfish-hk2 - orphaning event notification
by Alex Scheel 22 May '20

22 May '20

After much trimming, pruning, and hair-pulling by our fearless leader, glassfish-hk2 was determined to be a spurious dependency which Fabio replaced with one line of `sed` magic. Please see: https://pagure.io/stewardship-sig/issue/91 If anyone is interested in taking this package back for whatever reason, feel free to adopt it and claim ownership. However, the Stewardship SIG no longer has use for this package and thus orphaned it. Thanks, Alex

1 0

Fedora-Cloud-31-20200522.0 compose check report
by Fedora compose checker 22 May '20

22 May '20

No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

HEADS UP: libdav1d SONAME bump from .3 to .4
by Igor Raits 22 May '20

22 May '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I'm upgrading dav1d from 0.5.x to 0.7.x that is changing SONAME. There is only one dependent package in Rawhide - libavif which I will take care of. - -- Igor Raits <ignatenkobrain(a)fedoraproject.org> -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7HocQACgkQEV1auJxc Hh4+lQ//aeevBJTlOEc5JlVdGIYPn1khqPMgU3AF4A5dPT3pvw/KprD3qYfMkAhJ 8bozXV4GAMvtnHFXeHxzE7+V2tTt+Pu2Cemch4PFE8TP2fOplYitv9Zc/lvEoSm1 spWKEdvUt2lWo8QOq+1W6y6LOZYYOBx6URceHk52/6beN1U6DNE+e+5OFmIhhxoF GMUSlXypFtTZSQjVJSVWILWXEvuCSa2ux4Dce1IV6fva9Mw/O7CRU592pS0jTdT9 i+uK1oAHCc9EnsBNhXPf/iGP4Dty1wDx/73yoQGNfwV3i9D7CdJ4NgBrGk9gCtap IOlSRx2aqoFuLOhroJx0+61dJCM8djtFkm1DsNn2r0fY8OmE8Q3CzPR5xiGWg+ve BOP0j8wG02pvBPFhVyJrKwX3ZoE4y1zU2PAAglwKJPSyQaVmT0B519XcDMwrYyuP rVFX1xx9pgrVeFodPJdOxYvJc4eqmglbSknhe6mYljwssRniuFMwP35oVRb3IHug xJKC/bCnmYMi4hFzu5BLY34CBYR/ruO8n4KWFZLDseCdGTyyP+rtap/4VvPBoniC 6eaQ/EBJlE04dwC3eNxGtFiwfUrgs5QvZzpZJ4wCyVidMTazzc9uCuFuHFZTu7GV Tu7ik8nT7KUmWMN5idTKJEC1UUekBu8KlKwByWkUsGQFPNOhqAU= =Bx8w -----END PGP SIGNATURE-----

1 1

Fedora-Cloud-32-20200522.0 compose check report
by Fedora compose checker 22 May '20

22 May '20

No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 603163 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/603163 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

wrong info on apps.fedoraproject.org
by Jos de Kloe 22 May '20

22 May '20

Something seems wrong in: https://apps.fedoraproject.org/packages/pyproj The header text and upstream point to pyproject-rpm-macros in stead of pyproj. Does anybody know how to fix this? Jos

2 1

Strange rpm trigger behavior in koji rawhide
by Orion Poplawski 22 May '20

22 May '20

We're trying to track down a problem that only appears in koji and copr, but I can't reproduce locally in mock on my rawhide VM. It's related to file triggers and we're trying to debug with something this: %transfiletriggerin -n texlive-kpathsea -- /usr/share/texlive # %{_bindir}/texhash 2> /dev/null || : # DEBUG, lets see what it does /usr/bin/sh -x %{_bindir}/texhash || : export TEXMF=/usr/share/texlive/texmf-dist export TEXMFCNF=/usr/share/texlive/texmf-dist/web2c export TEXMFCACHE=/var/lib/texmf # %{_bindir}/mtxrun --generate &> /dev/null || : # %{_bindir}/fmtutil-sys --all &> /dev/null || : # DEBUG, lets see what it does %{_bindir}/mtxrun --generate || : %{_bindir}/fmtutil-sys --all || : hoping to see the output in the mock root.log, but I get nothing. One basic question - if texlive-kpathsea is part of the transaction, does the above trigger still fire at the end of the transaction? I see that mock locally and in copr has output like: Running scriptlet: texlive-base-7:20200327-4.fc33~bootstrap.1.x86_6 357/357 But I don't see any "Running triggers" or similar. Are we correct to expect output from triggers? This is causing build failures after the recent texlive update. Any help would be greatly appreciated. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 2

Fedora Data Centre Move - What This Means For You
by Aoife Moloney 21 May '20

21 May '20

# Fedora Data Centre Move - What it means for you? to: devel-announce(a)lists.fedoraproject.org subject: Fedora Data Centre Move - What it means for you? Good Morning, As you may have heard in the past few months, most of the Fedora Infrastructure which is currently hosted in a data-center in Phoenix Arizona (USA) will be moving to a new datacenter in Virgina (USA) in just a few weeks now. While we are doing our best to ensure a continuity of service to the project, there will be some consequences of this move. The main issues will be that for several weeks: - *Fedora's build capacity will be significantly reduced*. - A few applications, not directly related to building Fedora, running in the Fedora Infrastructure will be offline (see link below) Practically, this means that your build will wait longer to find a builder available and as a result the whole build process will feel slower. The builds per say should not be impacted though. As a result, if you know today that you have some important packaging work to do, we invite you to try to prioritize it now if possible. Otherwise, if you have the opportunity to plan this work for after the move is done, it would save some resources for builds that cannot/should not wait (CVEs and alike). In addition, during the move there will be no staging environment. This will directly impact very few people, but from an infrastructure point of view it also means that we try to avoid as much as possible updating applications (for example deploying a new account system or new releases) during that time. To give you some insight on dates*: - The week of June 8th we will be moving services from one data-center to the other, so there will be ongoing outages as resources are moved from one data center to one with diminished capacity. - We are hoping to continue rebuilding the infrastructure in Virgnia the week of June 22nd as shipped hardware arrives at the new facility. - The target deadline to complete the entire move and return to normal capacity in Fedora Infrastructure is July 28th A couple of final notes: - right after the end of the move, there is a mass-rebuild scheduled, so you could use this as an opportunity to let releng do the builds for you if you prepare everything in dist-git. - Please try to avoid pinging nirik or smooge in the coming weeks so they can focus on this delicate exercise, but if you run into them, I'm sure they will appreciate your support or/and some cookies on irc (nirik++ smooge++)! - Please bare with us while we're working on the move as responses to tickets/requests will likely be slower than usual. A list of the applications that will be impacted by the colo move is available at: https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA Thanks in advance for your understanding and help, Aoife * All the dates are subject to changes, going from networking issues, to servers dying because of the move, to a world-wide pandemic changing the working conditions in the data-center, but these are current estimates. _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)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-announce@lists.fedorapr…

4 3

RPM package builds backed by nbdkit
by Richard W.M. Jones 21 May '20

21 May '20

Context: https://bugzilla.redhat.com/show_bug.cgi?id=1837809#c28 https://rwmj.wordpress.com/2020/03/21/new-nbdkit-remote-tmpfs-tmpdisk-plugi… http://libguestfs.org/nbdkit-tmpdisk-plugin.1.html https://github.com/libguestfs/nbdkit/blob/0632acc76bfeb7d70d3eefa42fc842ce6… I did a bit of testing to try to see if this is really feasible, and yes I think it is. Discussion below, experimental results first ... I compiled qt5-qtwebkit from Rawhide dist-git by running the "fedpkg local" command. Version: qt5-qtwebkit-5.212.0-0.46.alpha4.fc33 Host: AMD Ryzen 9 3900X 12-Core Processor Disks: Fast NVME disks, but using dm-crypt and LVM. Compiling qtwebkit normally (baseline): 28m19.921s baseline with nosync enabled: 28m12.67s nbdkit file plugin backed by a local LV 28m53.259s (baseline + 2%) over a local Unix domain socket nbd.ko client (loop mounting) with multi-conn = 4 nbdkit tmpdisk plugin backed by local LV 28m14.151s over a local Unix domain socket nbd.ko client (loop mounting) with multi-conn = 1 [note 1] As you can see there's no appreciable difference in any of the times. Basically they all take the same time, the overhead of nbdkit + loop mounting is not significant. The tmpdisk plugin erases flush/FUA requests (deliberately), which is similar to but architecturally cleaner than nosync IMHO. However nosync makes no difference because it's intended for a different use case which we are not testing here: https://github.com/rpm-software-management/mock/wiki/Feature-nosync Where nbdkit might be useful for Koji builds (we're already using it for some Fedora/RISC-V builds): * Let's you create on-the-fly temporary disks backed by disk or memory. * Could be used remotely, eg. if you have builders with small amounts of storage, but a fast network and a separate storage server. * Could allow you to engineer the crap out of the storage to tune it very specifically for builds (dropping FUAs would only be the start here). Rich. [note 1] tmpdisk doesn't support multi-conn. This is because it serves a different, fresh, temporary to each client, so if a single client connects multiple times they'd see corruption since writes over one connection would not be seen on other connections. We do normally recommend using multi-conn because it can improve performance, although not in these tests. However changing tmpdisk to support multi-conn is architecturally tricky. You'd have to have a way to associate client connections to builds (exportname?) -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
40
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel May 2020