devel January 2016

devel@lists.fedoraproject.org

231 participants
286 discussions

Packaging Guidelines for Applications using Git Submodules
by Gerald B. Cox 12 Nov '24

12 Nov '24

I'm trying to figure out the best way to handle the situation where a project decides to use submodules in Git. The archive generated doesn't incorporate the submodule files. I've done some searching on this, and haven't really come up with much. I've reviewed: Packaging:Github <https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#G…> ; but that really doesn't address the submodule issue. I looked through some packages that are currently in the Fedora repository and found where a few folks have rebuilt the tarball and referenced that version as the Source in the spec file; then they put in a comment stating: The source of this package was pulled from upstreams' vcs. Use the following commands to generate the tarball: ... - git clone ... - git submodule init - git submodule update ... This approach is the best that I've found. Any other suggestions? Thanks much!

8 11

Outage Notification - 2009-07-01 01:00 UTC
by Mike McGrath 24 Aug '23

24 Aug '23

There will be an outage starting at 2009-07-01 01:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-07-01 01:00 UTC' Affected Services: Buildsystem CVS / Source Control Unaffected Services: Database DNS Fedora Hosted Fedora People Fedora Talk Mail Mirror System Torrent Translation Services Websites Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1496 Reason for Outage: Final migration step for new cvs server. It will hopefully be offline for only 30-45 minutes. The additional time is for some further tuning if needed and some verification steps. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce

2 1

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 17 Jan '22

17 Jan '22

I have the yarrow's iso files on my HD in a RH9 system. Let's say I want to upgrade selected packages using an "apt-get install" pointing to my iso-mounted files, how do I do it? i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. Then what is the complete procedure to make my apt look into my own HD to upgrade packages. Can anybody redirect me to the correct resource or some literature hanging on the web? Thanks. Assume also that I do not wish to burn CDs! I do not want to use apt-cdrom. Thanks. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg

6 9

pdftk retired?
by Michael J Gruber 08 Sep '21

08 Sep '21

I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael

17 26

git push permission denied
by Neal Becker 10 Feb '21

10 Feb '21

I just had to setup a new machine, and new ssh keys. I visited https://admin.fedoraproject.org/accounts/user/edit/xxxx I chose my new id_rsa.pub to upload. But I get: git push --verbose Pushing to ssh://nbecker@pkgs.fedoraproject.org/mercurial Permission denied (publickey). fatal: The remote end hung up unexpectedly Hints?

4 5

apitrace, bundled libbacktrace
by Sandro Mani 17 Dec '17

17 Dec '17

Hi, apitrace 5.0 bundles libbacktrace, which looks like is living within the gcc sources. libbacktrace is not build as a shared library from the gcc sources, and not packaged. Is it feasible to build libbacktrace as a shared library and ship it in a corresponding package? Or should I rather go for a bundling exception request? Thanks, Sandro

8 9

Xulrunner - intent to remove from Fedora 24
by Martin Stransky 27 Jun '17

27 Jun '17

Hi, does anyone use the xulrunner package? (and gecko-devel actually). Mozilla does not maintain it any more and the XUL as technology is going to be removed/deprecated. I'd like to remove the package from Fedora 24. ma.

21 30

whatever happened to yum + btrfs snapshotting?
by Neal Becker 13 Mar '17

13 Mar '17

Some time back there was discussion of being able to rollback yum updates via btrfs snapshotting. As I recall, it turned out that the default btrfs install was not setup correctly to make this feasible (I had briefly tested it on my machine). I haven't heard anything since - this seems like a great idea. -- -- Those who don't understand recursion are doomed to repeat it

7 7

Validity of i686 as a release blocker
by Josh Boyer 23 Apr '16

23 Apr '16

Hello, Over the past week, we've been dealing with a kernel bug[1] that prevents i686 machines from booting. Help was requested and given, and it has been excellent and most welcome. This email has no reflection on that, and is instead focused on the reality of where i686 stands today. In February[2] we sent out an email highlighting that the kernel team was not going to treat i686 bugs as a priority. Since that time, we have held true to our word and have not focused on fixing i686 bugs at all. It seems that the wider community is also treating i686 similarly. The kernel bug that was made automatic blocker because of existing criteria was present in Fedora since the 4.1-rc6 kernel, which was released May 31. It has been in every boot.iso created since that date. Not a single person reported this issue until last week. That is a timespan of two months. The kernel team has autotesting for i686 kernels, but the environment there does not utilize boot.iso so it did not detect this. The QA team has automated testing for some of this, but nothing for the i686 architecture at all. It is not a priority there either. Perhaps it is time that we evaluate where i686 stands in Fedora more closely. For a starting suggestion, I would recommend that we do not treat it as a release blocking architecture. This is not the same as demotion to secondary architecture status. That has broader implications in both buildsys and ecosystem. My suggestion is narrowly focused so that builds still proceed as today, but if there is something broken for i686 it does not block the release of whatever milestone we are pursuing. (To be clear, I would support a move to secondary arch status for i686, but I am not suggesting it at this time.) Making i686 non-release blocking would actually match reality. None of the Fedora Editions appear at all concerned with i686. Cloud is demoting[3] i686 from its offering. Workstation has been fairly ambivalent about it and recommends x86_64. Server does the same. Given the lack of focus on it, and the fact that the broader community is not testing the development releases for i686, I believe this would be a good first step. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1247382 [2] https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html [3] https://fedorahosted.org/cloud/ticket/106

15 20

OCaml plans on POWER7/POWER8 (ppc64, ppc64le) in Rawhide
by Richard W.M. Jones 05 Mar '16

05 Mar '16

OCaml is a statically-safe programming language derived from ML which compiles to very fast native code. It contains native code backends for most architectures (all Fedora primary & secondary arches except s/390x in fact). Currently Fedora downstream carries two non-upstream backends: For ppc64 (big endian), a backend was written many years ago by David Woodhouse and was upstream for a time, but was dropped when the PlayStation 3 stopped supporting Linux. For ppc64le (little endian / POWER8) IBM's Michel Normand contributed a native code backend last year. The upstream project always carried a ppc (32 bit) backend, but we didn't use it and it's not very interesting for us. https://git.fedorahosted.org/cgit/fedora-ocaml.git/log/?h=fedora-24-4.02 Red Hat and IBM have provided help and loaned equipment to the upstream project, and as a result upstream have now added ppc64 and ppc64le backends. This work was merged at the end of August. These backends were inspired by the Red Hat & IBM work but are not derivatives. For details see: https://github.com/ocaml/ocaml/pull/225 So what I want to do is add the new backends [actually it's a single, combined and extended ppc/ppc64/ppc64le backend] to Fedora Rawhide, and drop our non-upstream backends. I have so far cherry-picked the merge commit on top of our Fedora OCaml tree, and I have dropped the downstream ppc64/ppc64le commits from our tree. (This is not pushed yet so doesn't appear in the git.fedorahosted.org link above.) I have tested it on ppc64le to check that the compiler compiles itself. A scratch build of the compiler with the new backend is here (I reserve the right to make further changes, this is just a preliminary test build): http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2741551 I used this to compile some ocaml-* packages on ppc64le, with -- it has to be said -- mixed results. There are two compiler bugs revealed. This compiler won't be able to compile all the ocaml-* packages on POWER. However because of the depth of dependencies, I cannot easily do scratch builds to find out which packages will be broken. Hence I'd like to do a full rebuild, again, to see what breaks. This *shouldn't affect primary architectures at all*, but will probably leave some broken ocaml-* packages on the ppc64/ppc64le secondary arches. We've actually done two complete rebuilds during the F24 development cycle already, which in a way is good because it means I know how long it should take, and I'm confident that the scripts I use will work again: http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=13a8… So I'm pretty confident the primary arch rebuild will go fine, since it's not affected by any of the above changes - it's basically just a release bump. We don't even need to use a side tag for this because the "old" and "new" packages can be mixed on x86 - they are the same. The plan for ppc64/ppc64le would then be to fix the bugs revealed in the rebuild with upstream help. Any comments? Rich. -- 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

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2016