September 2013 - devel - Fedora Mailing-Lists

by Christian Krause

Hi, according to http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers I'd like to announce that I want to unretire the package gpx-viewer. The package was retired because it didn't build for multiple Fedora releases: https://pkgs.fedoraproject.org/cgit/gpx-viewer.git/tree/dead.package Upstream is not very active, but there are still occasional bug fixes committed: https://launchpad.net/gpx-viewer gpx-viewer has one advantage over the full-featured tools like josm or merkaartor: it can display a GPX track using OpenStreet maps without any setup or configuration. The required review request can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1008701 If someone would like to swap a review, I'd be happy to help, too! Best regards, Christian

10 years, 7 months

2
1
0 / 0

Reminder on how to EOL a package

by Dennis Gilmore

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, As the procedure recently changed a little and many people have gotten it wrong for a long time I wanted to bring to everyones attention the proper procedure to retire a package that is no longer useful. https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life its now one step from the CLI assuming you have a new enough fedpkg installed fedpkg-1.13-1 or newer. many thanks to Till for the implementation. Also please note that you are not to Retire packages for stable Fedora's we have no way to remove them and If you retire it they will be in a weird state where the package will be in the repos and available to install but koji will say its blocked. It will create confusion for both users and fellow developers. So DO NOT DO IT. Thanks Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlI3u8UACgkQkSxm47BaWfftJgCfaVhoSw2iSP26ELw9PunAULqG 3hQAniDG7UIhuadsM6Cm2RDkmVbrowxP =zybx -----END PGP SIGNATURE----- _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

10 years, 7 months

4
3
0 / 0

polkit rules for virt administration

by William

Hi, https://bugzilla.redhat.com/show_bug.cgi?id=957300 Was just wondering if any more discussion or action had been taken with this. Would be good to see included in F20. -- Sincerely, William Brown pgp.mit.edu http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2

10 years, 7 months

2
2
0 / 0

[Test-Announce] Fedora 20 Alpha Release Candidate 3 (RC3) Available Now!

by Andre Robatino

NOTE: The 32- and 64-bit DVDs, the 64-bit Desktop Live, the 32-bit Security Spin, and the 64-bit LXDE and MATE Spins are over their respective size targets. As per the Fedora 20 schedule [1], Fedora 20 Alpha Release Candidate 3 (RC3) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5745#comment:28 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace "dl" with "download-ib01" in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Alpha Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 20 Alpha test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/5745 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-20/f-20-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test _______________________________________________ test-announce mailing list test-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce

10 years, 7 months

1
0
0 / 0

Update notes referring to files within the package

by Kevin Kofler

Hi, lately, I have seen an increasing number of update notes like this: > See [some file in the package] for more information. While done with noble intentions, unfortunately, this is not of much use, because update notes are read BEFORE updating the package, whereas the file being referred to is only available (in the correct version) AFTER installing or updating the package. So please, instead of writing this, either: (a) link to a copy of the file in cgit/gitweb/ViewVC/Trac/…, if available or (b) link to a web page with the news instead, if available or (c) paste the contents of the file into the update notes. (Of course, the all-too-frequent "New upstream release." with no further information is also a VERY unhelpful kind of update notes, so it is not a reasonable alternative.) Thank you for your understanding, Kevin Kofler

10 years, 7 months

1
0
0 / 0

orphaning/retiring perl-Bio-ASN1-EntrezGene

by Alex Lancaster

This package is currently causing broken deps in any case. It's not very useful without perl-bioperl, see my previous post, which has seen been removed: https://lists.fedoraproject.org/pipermail/devel/2012-November/174435.html Hopefully somebody else can pick these packages up (including perl-bioperl), I can help as a co-maintainer, but can't be primary maintainer right now. Alex

10 years, 7 months

1
1
0 / 0

GNOME 3.9.92 megaupdate

by Kalev Lember

Hi all, GNOME 3.9.92 release is this week and we're going to collect all the builds together and file them as a single Bodhi megaupdate for F20. As usual, the spreadsheet for collecting all the builds together is at https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgy... We've also got a separate koji build target that can be used with: $ fedpkg build --target f20-gnome -- Thanks, Kalev

10 years, 7 months

1
0
0 / 0

Fwd: Broken dependencies: python-osmgpsmap

by Richard Shaw

Ok, I've been getting these messages for a while but I'm not the package owner for I didn't worry about it, however, it's been a couple of weeks so I decided to take a look to see how much work it would be. Now I'm really confused... There are two separate packages in Fedora: osm-gps-map python-osmgpsmap Both point to the same upstream URL. The description from upstream of osm-gps-map says it includes python bindings but there is not currently a separate sub-package generated... So what's the deal? Do one of these packages need to be retired? Richard ---------- Forwarded message ---------- From: <buildsys(a)fedoraproject.org> Date: Sun, Aug 11, 2013 at 7:35 AM Subject: Broken dependencies: python-osmgpsmap To: python-osmgpsmap-owner(a)fedoraproject.org python-osmgpsmap has broken dependencies in the rawhide tree: On x86_64: python-osmgpsmap-0.7.3-9.fc20.x86_64 requires libosmgpsmap.so.2()(64bit) On i386: python-osmgpsmap-0.7.3-9.fc20.i686 requires libosmgpsmap.so.2 On armhfp: python-osmgpsmap-0.7.3-9.fc20.armv7hl requires libosmgpsmap.so.2 Please resolve this as soon as possible.

10 years, 7 months

4
18
0 / 0

Reproducible Builds in Fedora

by Dhiru Kholia

Hi, I have been working on having Reproducible Builds in Fedora for some time. At this point, I think I have something demoable. Ensuring Reproducible Builds is a big task and I want your feedback, ideas, code and support. Please see https://github.com/kholia/ReproducibleBuilds for details. I would like to thank Debian and Ubuntu folks for starting similar projects (and inspiring this work). Reproducible Builds =================== It should be possible to reproduce every build of every package in Fedora. We want to be able to show that our binary was the result of our source code from our compiler and nobody added anything along the way. Can we (upstream / vendor) show that one of our rpms was built from the source we ship? It should be possible for the users to verify that the binary matches what the source intended to produce, in an independent fashion. We (the distribution provider) shouldn't be forced to say "Trust Us" to our users at all. Steps Involved ============== * Recording the build environment (DONE) - Koji does this automatically :-) * Re-producing the build environment (DONE) - Retrieve "brootid" (buildrootID) corresponding to the NVR we want to test from Koji (DONE) - Replicate this buildroot (DONE) - Create replica build environment using "Mock" (DONE) * Do re-builds locally using mock (DONE) * Verify new build against upstream (DONE, Steve's script works great) Current State ============= * Packages like git, john and qpdf are 100% reproducible as far as code is concerned :-) Current Challenges ================== See http://tinyurl.com/ReproducibleBuildsProblems * python-epydoc will add timestamps to the HTML file it produces ( needs FIXING). * javadoc will add timestamps to the HTML file it produces (needs FIXING). Links ===== https://wiki.debian.org/ReproducibleBuilds http://fedoraproject.org/wiki/Releases/FeatureBuildId#Unique_build_ID http://blogs.kde.org/2013/06/19/really-source-code-software https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-a... https://trac.torproject.org/projects/tor/ticket/5837 https://trac.torproject.org/projects/tor/ticket/3688 http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/... -- Dhiru

10 years, 7 months

1
0
0 / 0

Dracut HostOnly or ConfigurationOnly?

by Vratislav Podzimek

Hello, everybody, I'd like to know your opinion on one issue we have hit on live installations due to the DracutHostOnly feature [1]. Long story short: 1) Anaconda installs the kernel package 2) installation of the kernel package triggers dracut to generate initrd 3) dracut now generates so called "host-only" initrd, which, among the other things, means, that it contains only one keymap -- the one that was set in /etc/vconsole.conf at the time dracut was triggered to run 4) Anaconda configures the installed system based on the values set during the installation. The actual result is that if users type in their LUKS password with a keyboard layout different from 'us', let's say 'gb' they cannot type the password again on boot, because the initrd has only the 'us' keymap (set by default in the configuration file), even if there is 'vconsole.keymap=gb' as a boot option. There are two basic approaches how to fix this on the installer side: 1) write out keyboard configuration before packages are installed 2) regenerate the initrd at the end of the installation Both these solutions are not ideal from my point of view. And even if one of them is accepted and applied, there would still be the problem with systems, that have an initrd that blocks functionality of boot options (maybe there are more than vconsole.keymap, I don't know). So, is it a right thing to do to generate 3 MB smaller initrd's (the summed up size of all keymaps) not supporting some boot options? Does HostOnly mean the initrd works only with a specific host or that it works only with a specific configuration of a specific host? I understand having firmware for hardware that does not exist in the system might be useless, but not supporting boot with a different configuration options seems to me as a different thing. [1] https://bugzilla.redhat.com/show_bug.cgi?id=994180 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

10 years, 7 months

11
20
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2013